[pfSense Support] naive prioritization of VoIP?
I’m trying to make sure VoIP has the best possible quality for a small amount of effort. I still don’t understand QoS, even the wizard is baffling to me – for whatever reason QoS is a layer my brain just doesn’t want to accept. What I’ve done in the past on other firewalls is a trivial “priority” setting: without configuring any queues, buckets, shapers, etc., I would simply create a rule matching SIP traffic (either by port, by NBAR-ish/L7 application or by IP address) and set the “priority” to “high”. I really have no idea what that does under the hood, whether on FortiNet, Cisco, or PaloAlto. Is there anything that simple that I can do under pfSense? Thanks, -Adam Thompson athom...@athompso.net
Re: [pfSense Support] naive prioritization of VoIP?
I've had great luck with VoIP and pfSense. To be clear, there's no such thing as 'real' end-to-end guarantee of quality of service unless you're talking about MPLS or similar technologies. What you want is called 'traffic shaping' For ordinary people with ordinary connections, the idea is as follows: PART 1 - Starve the pipe! You must utilize your internet connection below its maximum 'guaranteed' throughput, otherwise you will have no control over the upstream buffers (see buffer bloat), and your real-time application, VoIP or otherwise will suffer. In VoIP, that means that packets will either not arrive, or arrive so late as to exceed the VoIP UA's jitter buffer, and will result in subjective quality factors, technically referred to as Shitty quality (Drops, stutters, etc). PART 2 - Prioritize your real-time packets! Now that your pipe is VERY SLIGHTLY underutilized, you have left yourself the ability to instantly insert the VERY NEXT VoIP packet into your data stream if one should happen to arrive (the very NEXT VoIP packet is the one you have to be preemptively ready for). When that packet arrives, the 'shaper' immediately adjusts TX/RX rates to CONTINUE to keep the pipe slightly underutilized. This is why you need to know your up/downstream speeds to configure your traffic shaper. All of the NON real-time stuff can be put 'in line'. All of that lower-priority stuff essentially must 'wait in line' to get IN or OUT, at that magic rate JUST UNDER the maximum rate to keep the pipe CONSTANTLY SLIGHTLY UNDERUTILIZED. Naturally VoIP packets gets to go to the front of the line in inbound or outbound queue. That's pretty much it. The 'starve the pipe' business is why it's not as simple as Simply prioritizing Voip PFSense makes it quite simple however. Just measure your link speed at something like speedtest.speakeasy.net. Walk through the traffic shaper wizard specifiying that VoIP gets top priority, whether that's the internal IP address (or alias) of your VoIP ATA, Astrisk server or VoIP telephone. Good luck -Karl On 6/2/2011 4:03 PM, Adam Thompson wrote: I’m trying to make sure VoIP has the best possible quality for a small amount of effort. I still don’t understand QoS, even the wizard is baffling to me – for whatever reason QoS is a layer my brain just doesn’t want to accept. What I’ve done in the past on other firewalls is a trivial “priority” setting: without configuring any queues, buckets, shapers, etc., I would simply create a rule matching SIP traffic (either by port, by NBAR-ish/L7 application or by IP address) and set the “priority” to “high”. I really have no idea what that does under the hood, whether on FortiNet, Cisco, or PaloAlto. Is there anything that simple that I can do under pfSense? Thanks, -Adam Thompson athom...@athompso.net mailto:athom...@athompso.net - To unsubscribe, e-mail: support-unsubscr...@pfsense.com For additional commands, e-mail: support-h...@pfsense.com Commercial support available - https://portal.pfsense.org
Re: [pfSense Support] naive prioritization of VoIP?
This begs the question of what, exactly do all those other firewalls DO when I set priority. ...speaking of VoIP, does anyone know if the FreeSwitch packages are ever getting updated? Or if the -dev version really is following HEAD? -Adam karlf...@gmail.com wrote: I've had great luck with VoIP and pfSense. To be clear, there's no such thing as 'real' end-to-end guarantee of quality of service unless you're talking about MPLS or similar technologies. What you want is called 'traffic shaping' For ordinary people with ordinary connections, the idea is as follows: PART 1 - Starve the pipe! You must utilize your internet connection below its maximum 'guaranteed' throughput, otherwise you will have no control over the upstream buffers (see buffer bloat), and your real-time application, VoIP or otherwise will suffer. In VoIP, that means that packets will either not arrive, or arrive so late as to exceed the VoIP UA's jitter buffer, and will result in subjective quality factors, technically referred to as Shitty quality (Drops, stutters, etc). PART 2 - Prioritize your real-time packets! Now that your pipe is VERY SLIGHTLY underutilized, you have left yourself the ability to instantly insert the VERY NEXT VoIP packet into your data stream if one should happen to arrive (the very NEXT VoIP packet is the one you have to be preemptively ready for). When that packet arrives, the 'shaper' immediately adjusts TX/RX rates to CONTINUE to keep the pipe slightly underutilized. This is why you need to know your up/downstream speeds to configure your traffic shaper. All of the NON real-time stuff can be put 'in line'. All of that lower-priority stuff essentially must 'wait in line' to get IN or OUT, at that magic rate JUST UNDER the maximum rate to keep the pipe CONSTANTLY SLIGHTLY UNDERUTILIZED. Naturally VoIP packets gets to go to the front of the line in inbound or outbound queue. That's pretty much it. The 'starve the pipe' business is why it's not as simple as Simply prioritizing Voip PFSense makes it quite simple however. Just measure your link speed at something like speedtest.speakeasy.net. Walk through the traffic shaper wizard specifiying that VoIP gets top priority, whether that's the internal IP address (or alias) of your VoIP ATA, Astrisk server or VoIP telephone. Good luck -Karl On 6/2/2011 4:03 PM, Adam Thompson wrote: I’m trying to make sure VoIP has the best possible quality for a small amount of effort. I still don’t understand QoS, even the wizard is baffling to me – for whatever reason QoS is a layer my brain just doesn’t want to accept. What I’ve done in the past on other firewalls is a trivial “priority” setting: without configuring any queues, buckets, shapers, etc., I would simply create a rule matching SIP traffic (either by port, by NBAR-ish/L7 application or by IP address) and set the “priority” to “high”. I really have no idea what that does under the hood, whether on FortiNet, Cisco, or PaloAlto. Is there anything that simple that I can do under pfSense? Thanks, -Adam Thompson athom...@athompso.net mailto:athom...@athompso.net - To unsubscribe, e-mail: support-unsubscr...@pfsense.com For additional commands, e-mail: support-h...@pfsense.com Commercial support available - https://portal.pfsense.org
Re: [pfSense Support] naive prioritization of VoIP?
On Thu, Jun 2, 2011 at 6:12 PM, Adam Thompson athom...@athompso.net wrote: This begs the question of what, exactly do all those other firewalls DO when I set priority. It varies, but generally there's more to it than setting priority. You need link speed as well as you need the firewall do to the queuing and never hit any queuing on your modem or elsewhere outside your control, otherwise priority is useless as you're just going to blast traffic out to be queued where your ISP is rate limiting you. ...speaking of VoIP, does anyone know if the FreeSwitch packages are ever getting updated? It won't be, it's going to be replaced with FusionPBX, the successor to our Freeswitch package. Mark Crane created it, then moved on to FusionPBX, and will be creating a package for it to replace the Freeswitch package at some point (not sure of his exact plans). - To unsubscribe, e-mail: support-unsubscr...@pfsense.com For additional commands, e-mail: support-h...@pfsense.com Commercial support available - https://portal.pfsense.org
