VoIP QoS Settings – part 2

In part 1, we examined the Layer 2 QoS settings available on most VoIP equipment. In this second part, I will explore the Layer 3 parameters and offer practical suggestions for the values that should be assigned to them. We will briefly look at the history and structure of the ToS and DSCP fields and their place within the DiffServ packet prioritisation model.


I explained in part 1 how Layer 2 data can be tagged with a priority value (sometimes called CoS). The L2 priority value is stored in the 3-bit PCP field of the Ethernet frame and this field is part of an optional 4-byte section loosely referred to as the “VLAN tag”.

Completely separate to this, it is also possible to tag IP packets within Layer 3 in a way that allows routers and switches to recognise that some packets should be given a higher priority than others. The following diagram illustrates how the different mechanisms exist at different layers in the OSI model:

VoIP QoS in the context of OSI Layers

Layer 3 QoS settings

As the above diagram shows, the QoS mechanisms that operate at L3 are DiffServ, DSCP and ToS. These L3 mechanisms have the potential to operate over the Internet thereby giving them a wider reach than L2 (which normally only operates within the scope of a LAN or private network). Theoretically, L3 QoS prioritisation could be applied all the way through to the remote end-point in a VoIP connection. However, in practice you are unlikely to be able to guarantee that routing equipment outside your control will respect the QoS tagging that has been applied to the IP packets.

The ToS field and how it has changed over time

The original design for the L3 Internet Protocol (see RFC 791) defined a standard structure for Internet Datagram Headers that included an 8 bit “Type of Service” (ToS) field. Its purpose was to provide storage for QoS parameters to allow network equipment to prioritise certain traffic at times of high load. Three of the eight bits were set aside for an “IP Precedence” value (very similar to the PCP priority value described in part 1) and a further three bits were designated as facility flags to indicate if a packet had preference for low delay, high throughput or high reliability. The last two bits were reserved for future use.

In 1998 and 2001, new standards were published (see RFC 2474, RFC 2475 and RFC 3168) which redefined the 8-bit ToS field to allow its use for the so-called “Differentiated Services”. The name “ToS” continues to be used today, even though the original interpretation given in RFC 791 has been superseded by the newer Differentiated Services model and the name “DS field” should be used instead. The 8-bit DS field comprises the first 6 bits as a DSCP value and the last 2 bits which are used for “Explicit Congestion Notification” (ECN) data:
The above diagram is copied directly from RFC 3168 which describes ECN.

Differentiated Services and the DSCP value

While the basic concepts are straightforward, the practical implementation – especially the terminology and labelling associated with the Differentiated Services Field – is remarkably confusing. As a VoIP engineer, you probably just want to know what value you should set for one parameter on the VoIP equipment’s setup menus. You don’t want to have to read two articles in Wikipedia and a couple of RFC’s just to be able to set that one value.

Let’s try to unpick the various points of confusion as briefly as possible:

  • DiffServ is a broad term covering the architecture and mechanisms of this particular approach to QoS. There are other models that can be used too – for example IntServ and RSVP.
  • Differentiated Services Code Point (DSCP) is a 6-bit value within an 8-bit field in the IP header.
  • The 8-bit field is sometimes called the ToS or TOS field. It may also be called the DS field or DSF.
  • The first 3 bits of the DSCP field may be referred to as the “Class Selector”. The same bits in the ToS field definition (in RFC791) were assigned to the so-called “IP Precedence” value. Some values relevant to VoIP are shown below.
  • The last 2 bits of the 8-bit field, used for congestion notification, are set dynamically by routers. You can assume 00 whenever you are obliged to explicitly assign a value to them.
  • When specifying a value for DSCP on your VoIP equipment, be careful to check if it expects a 6-bit value or an 8-bit value, if it requires the value to be given in hex or in decimal or as a named constant.

Wow. So what is that last point saying – what do I mean by a “named constant”? The answer comes from the fact 6 bits allows for a lot of different values. The 6 bits can in fact be further sub-divided into elements that describe the Class Selector and the Drop Probability. To make these values more easily readable by humans, they are often described by an abbreviated name indicating the “Per Hop Behaviour”, the Class Selector value and Drop Probability. Here are some examples:

  • AF31 where AF=Assured Forwarding, 3 indicates Class 3 and 1 is the Drop Probability
  • EF Expedited Forwarding – recommended for RTP
  • CS5 Class Selector 5

A selection of ToS “IP Precedence” values and their equivalent Class Selector value:

  • IP Precedence 0 (CS0) Routine or Best Effort – typically used for data
  • IP Precedence 3 (CS3) Flash – used for voice signalling (e.g. SIP)
  • IP Precedence 5 (CS5) Critical – used for RTP

I am not going to attempt to provide a complete list or even a complete explanation of the DSCP values – there is plenty of existing material on the Internet that does this already. However, you may want to try the following links:

Excellent overview of QoS includes a table of DSCP values: http://www.rhyshaden.com/qos.htm

List of commonly used DSCP values as binary, decimal and named constant:

A handy table for converting between DSCP and ToS; giving values in binary, hex and decimal:

What values should be used on VoIP equipment?

A sensible choice for SIP signalling messages is AF31. This requires the ToS field to be set to 0x68 (hex) or 104 (decimal). CS3 is also suitable for SIP.

A sensible choice for RTP and RTCP is EF. This requires the ToS field to be set to 0xB8 (hex) or 184 (decimal)

Unfortunately, different manufacturers require different formats for entry of the data.


On my Linksys devices, the parameters are located in the Line tab in a section entitled “Network Settings” (you need to login as admin and select advanced viewing). The values are described as “SIP ToS/DiffServ” and “RTP ToS/DiffServ” and they encompass the whole 8-bit ToS field. They are entered as Hex values and the defaults are 0x68 for SIP and 0xb8 for RTP, which are equivalent to AF31 for SIP and EF for RTP.


On the Snom 360 the settings are available in the QoS/Security tab of the Advanced settings page. The Layer 3 settings are shown as two “TOS/Diffserv” values, one for RTP and another for SIP. The values are entered as decimal numbers which are internally converted to an 8-bit value for the whole ToS field. The default on the Snom for both SIP and RTP is 160 which is equivalent to 10100000 in binary. To see what DSCP value this equals, you must strip off the last two zeroes (the ECN field), leaving the binary value 101000. From tables we can determine that this binary value is called CS5 when using the named constants.


On the Aastra IP phones, the layer 3 settings are shown on the web GUI within the Network Settings page under the heading “Type of Service DSCP”. The values are entered as decimal numbers, but unlike the previous manufacturers they represent only a 6-bit DSCP field (the 2-bit ECN field is not included). The default values are 26 for SIP and 46 for RTP/RTCP – equivalent to AF31 and EF.


The parameter is called “Layer 3 QoS” and it expects a value, entered as a decimal number, that is equivalent to the 6-bit DSCP field. The default on my GXV3140 is set to 48 which is equivalent to the named constant CS6 – i.e. Class Selector 6. It does not allow different values to be specified for SIP and RTP.

Asterisk settings

In recent versions of Asterisk, you can set the value for the layer 3 DSCP field by editing the sip.conf file. The parameter names refer to the ToS field, but the values you specify are named constants for the DSCP field, so even the developers who work on Asterisk have trouble understanding the terminology! The values are set using the following parameters (here shown with their default values):

tos_sip=cs3                    ; Sets TOS for SIP packets.
tos_audio=ef                   ; Sets TOS for RTP audio packets.
tos_video=af41                 ; Sets TOS for RTP video packets.
tos_text=af41                  ; Sets TOS for RTP text packets.

Further reading

If QoS is to make a difference, it requires a good deal more than just setting the DSCP, ToS or CoS values on the IP telephony device or PBX. If QoS is an important requirement in your VoIP projects, I strongly recommend that you read my follow-up article about QoS in practice. Just click this link to go to the article.

Feedback on this article

Please take a moment to use the coloured voting buttons below to provide some feedback to the author. If you liked the article, great. If it fell a little short of your expectations, please leave a brief comment or send me an email (info (at) smartvox.co.uk) so I know what needs changing. Thanks.

4 thoughts on “VoIP QoS Settings – part 2”

  1. excellent article, I am experiencing the following:
    My Snom 360 has TOS=160, if I make a call monitored by wireshark the TOS=0 , why is this change?


    • Carlos,
      Where are you capturing the packets to view in Wireshark? Are you using the packet capture feature (PCAP Trace) on the Snom phone itself? If not, I would suspect that the TOS field has been overwritten by another piece of network equipment such as a router.

Comments are closed.