![]() Īnother tool that would perhaps be useful would be ntop. Using something like STG and/or MRTG for long-term stats and with short period values is invaluable in locating problems.Įven better would be something like Wireshark and watching total throughput on the WAN would be even better. That will tell you, with fairly high granularity if the _instantaneous_ bandwidth is too high. You need to run something like STG with a single second update polling SNMP on a managed switch. If BW becomes a problem, you'll notice very poor call quality before you notice drops, typically.Ģ) You have no idea about fairly instantaneous bandwidth issues. It could be your bandwidth, but I'd guess not. Dropping some percentage of calls with them is completely unsurprising. I'm not saying that to knock them, but it's simply the truth. Unless you have some way to guarantee packet delivery and such all the way to an end point, then you have no guarantees about anything.ġ) Callcentric and voip.ms are exceedinly cheap and somewhat unreliable SIP providers. I'm marking my OUTBOUND VoIP packets on the prerouting chain on the ether1-local-master interface, based on the source ip matching my internal PBX. Just to clarify, I'm marking my INBOUND VoIP packets based on their source ip address matching either of my VoIP providers POPs, and i'm doing this on the 'prerouting' chain on the 'ether0-gateway' interface. ![]() I think we're safe to say that it's not the router / ISP bandwidth that is the dropped-calls issue. In no case, however, did my test calls drop. It sounds fine when only one person is doing the bandwidth testing. The outbound audio is still a little choppy when doing two charter-bandwidth tests (totally maxing our connection), even when I mark the priority of the packet as it comes into the ether1-local-master interface. I know that 'filter close to source' is always the best approach, so wouldn't I want to tell INCOMING voip traffic it has a higher priority when I first see it on the gateway interface? (as opposed to waiting till it's heading out the -local-master interface) Using the INTERNET port makes me use TOS for outbound and the using our VOIP Providers IP for inbound, and is a little more complicated. Using the internal one would enable to to make the mangle rules using only the IP address of the PBX. I'm not sure if it would be smarter to apply them to the INTERNET port, or to the INTERNAL port. The other approach (would this be smarter?) is to apply the mangle rules to the ether1-local-master, and set the IP addresses to that of my internal PBX? I also modifed the OUT mangle rules so that they were TOS = 46 and TOS != 46. address for my SIP provider address (as captured with TORCH during active calls). , substituting 'ether3' for 'ether0-gateway', and the 192. I've set it up like the example at the bottom of
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |