[Freeswitch-dev] Using TC to prioritise VOIP traffic

Daniel Swarbrick daniel.swarbrick at gmail.com
Sun Mar 2 20:29:55 MSK 2014


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 at freeswitch.org
> http://www.freeswitchsolutions.com
>
> 
> 
>
> Official FreeSWITCH Sites
> http://www.freeswitch.org
> http://wiki.freeswitch.org
> http://www.cluecon.com
>
> FreeSWITCH-dev mailing list
> FreeSWITCH-dev at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
> http://www.freeswitch.org




Join us at ClueCon 2013 Aug 6-8, 2013
More information about the FreeSWITCH-dev mailing list