[Freeswitch-dev] Using TC to prioritise VOIP traffic
Hi, I have been experimenting with the tc command to prioritise VOIP traffic, and I wondered if anyone could check over my script and see if it does what I think it does :) Effectively I want to create 3 queues, one for UDP traffic (RTP) with highest priority, one for SIP traffic (port 5060 TCP) with 2nd highest priority, and finally a 3rd queue for everything else. #Put everything in 3rd queue by default? tc qdisc add dev $DEV root handle 1: prio priomap 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 #Create 3 SFQ queues tc qdisc add dev $DEV parent 1:1 handle 10: sfq limit 3000 tc qdisc add dev $DEV parent 1:2 handle 20: sfq tc qdisc add dev $DEV parent 1:3 handle 30: sfq #Match UDP traffic and put into priority 1 queue ${TC} filter add dev $DEV parent 1: protocol ip prio 1 u32 \ match ip protocol 17 0xff flowid 1:1 #Match SIP traffic and put into priority 2 queue ${TC} filter add dev $DEV parent 1: protocol ip prio 1 u32 \ match ip dport 5060 0xffff flowid 1:2 ${TC} filter add dev $DEV parent 1: protocol ip prio 1 u32 \ match ip sport 5060 0xffff flowid 1:2 I have check the status of the queues, and it seems to be correctly classifying the different packets. But I am not sure whether it is prioritising them correctly or not. Thanks Tom
Tom, Using UDP as the only selection criteria for queue placement is going to be an issue. There are many, many other applications that will directly compete with your bandwidth using UDP. On Sat, Mar 1, 2014 at 11:10 AM, Tom Parrott <tomp@tomp.co.uk> wrote:
Hi,
I have been experimenting with the tc command to prioritise VOIP traffic, and I wondered if anyone could check over my script and see if it does what I think it does :)
Effectively I want to create 3 queues, one for UDP traffic (RTP) with highest priority, one for SIP traffic (port 5060 TCP) with 2nd highest priority, and finally a 3rd queue for everything else.
#Put everything in 3rd queue by default? tc qdisc add dev $DEV root handle 1: prio priomap 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
#Create 3 SFQ queues tc qdisc add dev $DEV parent 1:1 handle 10: sfq limit 3000 tc qdisc add dev $DEV parent 1:2 handle 20: sfq tc qdisc add dev $DEV parent 1:3 handle 30: sfq
#Match UDP traffic and put into priority 1 queue ${TC} filter add dev $DEV parent 1: protocol ip prio 1 u32 \ match ip protocol 17 0xff flowid 1:1
#Match SIP traffic and put into priority 2 queue ${TC} filter add dev $DEV parent 1: protocol ip prio 1 u32 \ match ip dport 5060 0xffff flowid 1:2 ${TC} filter add dev $DEV parent 1: protocol ip prio 1 u32 \ match ip sport 5060 0xffff flowid 1:2
I have check the status of the queues, and it seems to be correctly classifying the different packets.
But I am not sure whether it is prioritising them correctly or not.
Thanks Tom
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-dev mailing list FreeSWITCH-dev@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org
-- Kristian Kielhofner
Hi Tom, The usefulness of limiting RTP bandwidth is debatable. If the bandwidth limit is reached, then random RTP packets from _all_ streams will be dropped, affecting all streams and generally reducing the voice quality for everybody. Most engineers I know tend to be of the opinion that if a network cannot support additional calls (i.e. due to exhausting network capacity), then further incoming calls should be rejected (with e.g. SIP 480). Unless the egress interface is congested (e.g. packets arriving in tx queue faster than they can be encoded onto the wire), prioritizing packets will have no effect - the packets are simply sent in a FIFO manner. This simple fact is often forgotten by people when configuring QoS. In network QoS, it is advantageous to mark packets (DSCP or 802.1p CoS) as close as possible to the source of the packets, and configure the rest of the network to trust that classification. I think you would be better off to simply mark the packets as they leave the egress interface (which can be done simply with iptables), and then configure your switches to use QoS. Many switches nowadays support L3 QoS, so they will look at the DSCP bits and map them to a queue. If your switches only support L2 QoS, you will have to configure your host to be on a tagged switchport (even if just VLAN ID 1), so that you can set the 802.1p class of service bits in the 802.1 VLAN tag. Most IP phones already set DSCP appropriately, depending on whether the packet is media or call control. Again, if your switches only support L2 QoS, then you should also ideally ensure that your phones are on tagged ports. HTH, Daniel On 01/03/14 17:10, Tom Parrott wrote:
Hi,
I have been experimenting with the tc command to prioritise VOIP traffic, and I wondered if anyone could check over my script and see if it does what I think it does :)
Effectively I want to create 3 queues, one for UDP traffic (RTP) with highest priority, one for SIP traffic (port 5060 TCP) with 2nd highest priority, and finally a 3rd queue for everything else.
#Put everything in 3rd queue by default? tc qdisc add dev $DEV root handle 1: prio priomap 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
#Create 3 SFQ queues tc qdisc add dev $DEV parent 1:1 handle 10: sfq limit 3000 tc qdisc add dev $DEV parent 1:2 handle 20: sfq tc qdisc add dev $DEV parent 1:3 handle 30: sfq
#Match UDP traffic and put into priority 1 queue ${TC} filter add dev $DEV parent 1: protocol ip prio 1 u32 \ match ip protocol 17 0xff flowid 1:1
#Match SIP traffic and put into priority 2 queue ${TC} filter add dev $DEV parent 1: protocol ip prio 1 u32 \ match ip dport 5060 0xffff flowid 1:2 ${TC} filter add dev $DEV parent 1: protocol ip prio 1 u32 \ match ip sport 5060 0xffff flowid 1:2
I have check the status of the queues, and it seems to be correctly classifying the different packets.
But I am not sure whether it is prioritising them correctly or not.
Thanks Tom
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-dev mailing list FreeSWITCH-dev@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org
participants (3)
-
Daniel Swarbrick
-
Kristian Kielhofner
-
Tom Parrott