Vonage



  • I have a linksys vonage router, and I'm having a small problem with the VoipUP queue. I used the traffic shaping wizard, so that created the queue, and I used the default VOIP rule. That rule didn't seem to work(the queue remained empty when I made phone calls, and calls sounded like crap). So I changed the rules like below, but left the queue.

    I assigned the Vonage router a static DHCP ip address(192.168.1.155). Then I could simply change the rules so that anything to/from 192.168.1.155 would go into the VOIP queues. This actually did something, since I could now actually see the queue actually have something in it. It would only go up to 32kb and the calls sounded like crap, but I realised that limit was in the queues themselves, so I changed it to 128kb, and everything is good.

    The problem is that now, an hour after I got everything working, the upload queue pretty much sits at about 32kb, and every 20-30 seconds spikes to 50kb. at first I thought that this maybe just the Vonage router talking back to home for something. But then I unplugged the router, and that queue still sits at 32kb. That shouldn't be( I don't think), since the only rules that I have going to that queue are packets coming from 192.168.1.155. If that device isn't plugged into the network, how can anything be in that queue? The download queue behaves, it is empty until I make a phone call.

    UPDATE: OK, I shut down azureus(bittorrent client) on my computer, and the queue dropped down to 0. Started it back up, and the queue went back up. I don't understand why the packets from azureus are going into the VOIP queue. Truly defeats the purpose of the traffic shaper. The computer's IP is 192.168.1.150, the rule is for 192.168.1.155

    I've attached a screen of the 2 VOIP rules.




  • i am also getting this behavior.  i tried changing the bittorrent rules to say ! voip but then i got errors loading the rules.  right now i am going to try to put the bt rules in the list first to see if that has any effect



  • We just fixed the ! rule problem yesterday.  Look for it in a new release.

    In terms of your p2p app, if you set the rules to match the ip it should not be happening.  Make sure you clear your nat states before doing testing as the shaper is stateful.



  • I have Voicepulse and when I had this issue, it seems that when I made my VoIP traffic shaping rules only include the UDP protocol the issue went away.  Actually, it's really not an issue.  There is TCP traffic that happens between VoIP adapters/routers and the internet.  It's just not actual call traffic, so you don't need to give it a higher priority.



  • just beat me to the punch,  switching it to only prioritize udp packets is a nice workaround on this end as well.
    but we still have an issue here.

    the voip queue says that packets to and from IP addr xxx should only be allocated to it.  the voip queue is picking up packets that are outbound tcp from addresses other than xxx.  i moved the rules a bit in case there was a "first match" issue but it had no difference.



  • we lately changed something with the order the rules are processed. please check out the new version and report back if the problem still exists.



  • I noticed that in the changelog, but I was waiting for a new compile before I tried it:

    Check-in [8475] on branch RELENG_1: MFC 8474 Make shaper first match - fix a months old oversight. (By sullrich)

    Is tht what you're talking about? If it is, then I don't think you guys have put out a new version since then, have you. It's very likely that I'm wrong about that.

    I saw this one too:

    Create ticket #733 : Rule numbering and view of imlicit rules to match hit rules (By anonymous)

    But that was in after 0.96.4



  • That is correct, new versions with that code have not been released.  You will know they are when you see a pink box with the version information listed AFTER the commits show up.

    A new version is coming soon today 0.97



  • I'm not sure if it's the same problem, but I think that there is still something that is wrong. I changed the rule so that it only does UDP traffic, but I'm still not sure if the upload is getting priority, but the download seems to be.

    Normally, both Voip queues stay at 0-1kb/s. When I make a call the queue goes up to around 100kb/s. This is good since at least the right packets are going to the right queues. However, I'm not sure if the VOIP queue is getting priority.

    When I make a call, and I unplug all other computer from my network, so that Vonage has my full pipe, the calls are crystal clear. But then I tried making a call while downloading heavily, and uploading a file via ftp. The quality of the call coming in(download) was still crystal clear, but the quality of the voice going out(upload) was very poor, I could barely hear anything.

    edit: I'm on Version .97 by the way.



  • Remove the traffic shaper wizard, then re-add it to make the changes we made go into affect.

    Make the changes to your queues as needed.



  • ah, thanks.



  • ok, I did that, but it's still choppy. It sounds like it's dropping packets(and since it's voice, it could just be that the packets are getting there out of order).

    The thing that I don't understand is how come when the up AND down pipes are both full, the download comes in perfect, but the upload is choppy. Wouldn't the router have more control over the upload than it would the download?



  • Try unchecking all scheduler options in your VoIP queues.





  • It's been like that. In the last couple versions, it's been the default to have those boxes unchecked.



  • I haven't used the traffic shaper wizard since around .86, I just keep restoring my config file on every new install and backing it up after even the smallest change.  It would take me hours to get traffic shaper rules back to where I have them now with everything I've done to it.  It's even more complicated then when I originally posted it.

    How much bandwidth have you given the VoIP queues as a minimum?

    Mine is set to 256Kb in the Real-time and 300Kb in the upperlimit.  It's always better to over-supply plenty of bandwidth to VoIP.  Voicepulse uses about 90Kb with overhead using the highest quality codec which is G711u.  So I supply it with 2.5 times the bandwidth.

    Make sure you're using the highest quality codec Vonage has and see if that makes a difference.



  • yes, I'm giving it more than enough bandwidth(192kbps, while Vonage needs 90kbps). I have it set at the highest quality from Vonage, but that really shouldn't be an issue since I'm getting perfect sound when I don't have anything else using the pipe.



  • @charincol:

    I haven't used the traffic shaper wizard since around .86, I just keep restoring my config file on every new install and backing it up after even the smallest change.  It would take me hours to get traffic shaper rules back to where I have them now with everything I've done to it.  It's even more complicated then when I originally posted it.

    How much bandwidth have you given the VoIP queues as a minimum?

    Mine is set to 256Kb in the Real-time and 300Kb in the upperlimit.  It's always better to over-supply plenty of bandwidth to VoIP.  Voicepulse uses about 90Kb with overhead using the highest quality codec which is G711u.  So I supply it with 2.5 times the bandwidth.

    Make sure you're using the highest quality codec Vonage has and see if that makes a difference.

    I think you have to recreate your rules. Some versions ago there was an workover in the way the rules are processed and also the way they are generated. You really should try to remove the traffic shaper and run the wizard again. Test the voicequality again then. If it's ok start adding your modifications back again.



  • @ hoba

    Oh, it's not me that is having the trouble with the VoIP voice quality.  Mine seems to be fine for me.  Simpat1zq is the one having voice quality problems when saturating the pipes and then making or receiving calls.  So I was just stating that I hadn't seen what the traffic shaper had for the defaults lately and didn't know that the options I had unchecked from the shaper default rules when I used it back then were now unchecked.  I can see now that I should have clarified that to make more sense.  However, I may just go through the shaper wizard again and rebuild and see if it improves the already great traffic-shaping of pfSense.

    @ simpat1zq

    One thing that I do is always limit my upload speeds on P2P from within the app.  I have a 1M upsteam pipe.  Actual speeds are between 650-840Kb.  So I don't let my P2P upload get any higher than around 550Kb.  I've tried other *NIX firewall distros and others have great traffic shaping but they have a much longer lag before the shaper is fully working.  pfSense seems to have the shortest lag, which is why I use it.



  • One thing is that the VOIP sounds choppy when I'm just upload via ftp. Sure I could also limit that, but then I would have to go around and limit all of my apps, in which case I really wouldn't even need the traffic shaper for VOIP. I thought that with the way I set it up, once the firewall gets a VOIP packet, it essentially stops everything it's doing to make sure that packet gets out first. If that's the case then shouldn't the VOIP call sound perfect even when an ftp session is uploading? I could be wrong about that as I'm sure there's some behind the scenes stuff that I don't understand.



  • Yes, this is how it should workl.  In theory, if your VOIP packets are highest priority, there should never be more than one packet queued in the dsl/cable modem and one on its way out (roughly.)  I'm experiencing the same behavior.  I think there's an underlying shaper problem (don't know if it's in the kernel or elsewhere…)



  • Bill is working on the issues.  Everyone stay calm.



  • @sullrich:

    Bill is working on the issues.  Everyone stay calm.

    Wait for B2 - I just fixed another old bug and have had some reports of better performance already.  There's more coming, but I'm trying to keep those changes out of 1.0.

    –Bill


Log in to reply