Terrible "Send" quality on VOIP Softphones…but ATA's work fine?



  • Hi guys, I am still very new to all this (as anyone whos read my posts will instantly realise hehe). Ive recently switched to Pfsense from an old D-Link router and am still trying to iron out some of the problems.

    Currently my problem is with VOIP Softphones.

    I used to have every computer with its own softphone installed for use at that computer, and then 1 ATA to allow VOIP calls to be made from all the normal phones.

    Now that i have the ATA setup properly (thanks to the invaluable help from these forums, and specifically the suggestion regarding Static Ports) it works fine. Both "inbound" and "outbound" call quality works pretty well. (a bit quiet, but otherwise fine).

    However the problem i am now having (and have been having since i switched to Pfsense) is two-fold:

    A) Only one Softphone can connect at any one time. If Comp A is connected, Comp B cannot. If i turn off the softphone on Comp A, Comp B can now connect.

    B) Regardless of which computer is used to connect with a softphone, the inbound call quality is great (i can hear them fine) but the Outbound quality is crap. Constant complaints people cant hear me, or that it sounds like i am underwater and drowning hehe.

    I am guessing this must be a pfsense issue (specifically me not having it setup properly) as it all used to work pretty well on my old Dlink router.

    If anyone has any suggestions on how to fix either problem it would be very much appreciated, though Problem B is far more important as even if A is solved, the softphones will still be useless until people can understand what im saying. hehe.

    Thanks in advance guys, and if more information is needed, please let me know.

    EDIT: I just disabled Static Port in the Outbound NAT rules….the ATA doenst work, but now multiple Softphones can...
    Is there a way to have Static Port enabled (for the ATA) and still get the softphones working?



  • Enable advanced outbound NAT like you already have/had. Then switch back the default autocreated NAT rule to not use static ports anymore. Hit the plus-icon after you have done so next to this outboundnat rule. It will open this rule for editing and generate a copy if it. Now change the source of that rule to <lan-ip-of-ata>/32 and check static port. Save the rule. now move it on top of the default rule for your lan subnet. Save and apply. Now only the ATA wil use static ports.

    For those who are interested what might the problem of this: Softclients usually have some more logic to detect running through NATs and usually work better under that condition. Your ATA might work better (even without static port) when using an external STUN-Server. However I would give the above described configuration a try. The main issue is the design of the SIP protocol which is not NAT friendly at all. Just like FTP it's one of the worst protocols out there imo.

    Regarding the voip-quality how did you setup the shaper when running through the wizard? What bandwidth did you assign to it? What codec are your users using and how many concurrent calls might be happening at the same time?</lan-ip-of-ata>



  • @hoba:

    Enable advanced outbound NAT like you already have/had. Then switch back the default autocreated NAT rule to not use static ports anymore. Hit the plus-icon after you have done so next to this outboundnat rule. It will open this rule for editing and generate a copy if it. Now change the source of that rule to <lan-ip-of-ata>/32 and check static port. Save the rule. now move it on top of the default rule for your lan subnet. Save and apply. Now only the ATA wil use static ports.

    For those who are interested what might the problem of this: Softclients usually have some more logic to detect running through NATs and usually work better under that condition. Your ATA might work better (even without static port) when using an external STUN-Server. However I would give the above described configuration a try. The main issue is the design of the SIP protocol which is not NAT friendly at all. Just like FTP it's one of the worst protocols out there imo.</lan-ip-of-ata>

    Thanks for the suggestion, ill give it a try.

    Regarding the voip-quality how did you setup the shaper when running through the wizard? What bandwidth did you assign to it? What codec are your users using and how many concurrent calls might be happening at the same time?

    1. I just ticked the "enable VOIP Shaping" option in the wizard
    2. I assigned it a minimum of 96kbit/s (have only got a 1500/256 ADSL1 connection)
    3. Unsure of codec on the softphones as most comps just use the standard Firefly softphone that Freshtel provides.
        However, when i installed a version that works on third party providers, i have tried a variation of both G279 and                G711a as in i have tried both to similar effect.
    4. Usually 2 or 3 concurrent calls max, but even at only 1 call its still crap.



  • When only enabling the vopi shaping with the default mode the packets have to be tagged with the low priority bit in the header. I guess the one device that wiorks does handle this correctly whereas the devices or softphones don't do this. Maybe check your applications/devices if you can enable this. Otherwise you'll have to customize the rules a bit to use ports or IPs for trafficclassification.



  • hmm there doesnt appear to be any option to do that in the softphone.



  • Hi Omega

    Concerning Problem A: this is Consistant NAT (Static Port on PF sense). this parameter causes the session to NOT scramble ports on the Masqueraded interface. nearly all phones i know are using SRC port 5060 as well. this means: ATABOX:5060 -> SIPPROVIDER:5060
    when doing Masuqerading and using static port, this will look like this:  ATABOX:5060 -> PUBIP:5060 -> PROVIDER:5060. when ATABox2 registers, it overwrites the first rule.
    solution: use different src-ports on your clients, or try to live without static ports. as long as you havent problems receiving incomming calls you can disable consistant NAT. or enable it for just the ATA Box…

    Problem B: 96Kbits/s is quite OK for a G711 call when the line isn't busy. if the line is quite busy you'll get 96Kbit anyway, but with a hell of jitter (jitter are packets that are received too early or too late). jitter is quite hard to handle and can lead to poor quality.
    Background: G711 codecs are the orginal Codecs used on the 64kbit ISDN links. add a bit overhead through the OSI and you'll end up in 96kbit. the 64k's on ISDN works fine since the ISDN Line gives you exactely the 64Kbit not more and not less. your call is reserved and nothing else will take your bandwith and delivery time. (eg. constant 2ms from A to B)
    in the funny packet-switched network of the internet, your packets will be delayed and relayed and and and....this causes quite different delivery times ... from 2ms on a idle internet line up to 50ms on a busy one. remember that voip relies on 'just-in-time'-delivery of the underling network. and a stream fo 96kbit reserves you the bandwith, but NOT the latency.!  long talk, short conclusion: i would make 112kbit/s per call with g711 and 96kbit/s for g729. that way you'll get a bit better latency management...
    when you do calls on g729, are you sure that you really use g729??? SIP/SD does a negation for the codec and when the remote side doesnt support g729, forget it :)
    g729 is basically only a specification of ISUP/ITU and as far as i know, there are only a few implementations (also free ones) of that codecs, but the only one that works really fine is the one licensed one of Digium. so unless you using asterisk with this codec or a Hardphone with ceritfied 729, switch back to g711!

    g729 is very very very (!) sensitive to packetloss and jitter. unless your network isn't suitable switch to g711...g711 is anyway better because some SIP/ISDN converters don't have to do transcoding and can send your stream directly to the Timeslot of the E1....

    cheers maldex
    (sorry for mis-spelling...quite in hurry)

    ps, on my embedded 1.01 was a bug in the Shaping wizzard: SRC and DST were switched. do a call and go to status and check the Queues. you should expect to see around 30 (30ms frames) to 50 packets/s (20ms frames) on the VoIP in & out queue. when not, go back and check the Shaper-rules.



  • Okay ill try bumping it up to 128 (dont have 112 as an option) and see how it goes.



  • hmm, with it set like the, the general internet speeds (webpages etc) are insanely slow. Like a saturated dial-up connection. Had to dial it back a bit.

    If i need 128 to assure good quality, and i cant afford to allocate 128 (lest the rest of the net be unusable) maybe this is just an unsolvable problem until i can get ADSL2+ or something.



  • 256Kb up is really small to try and pump even 1 or 2 channels of VOIP traffic and Office surfing though.
    I'd upgrade.

    I'm in the process of setting up VOIP for my companies new office, we are getting a 4Mbit symmetrical connection allocated for VOIP. We are only going to have 6 channels to start and only really need about 640Kbit/s.

    It's a bit of overkill, but we got a good deal. Metrobridge's sales rep lied to me so I made him eat dirt  ;D



  • Will be upgrading as soon as its available in our area. Have been promised "2nd Qtr 2007" for about a year now, so hopefully they live up to their promise.


Log in to reply