Vonage
-
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.
-
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.
-
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