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