SNOM VoIP Phones and ToS/QoS

From RADION OpenLab

A lot of people are asking how to interpret the TOS Value 160 mentioned in the documentation and what to set in order to get 0x18 the value most asterisk config files use. The answer is more tricky than it appeared at first because all links found in the comments and on google are gone and those you can find are really useless, except the new SNOM Knowledgebase [1].

According to SNOM the correct value for RTP/SIP ToS is basically 4 times the decimal value of your desired hex string. In our case (0x18) that would be 96

HEX:0x18=DEC:24 | 24*4=96

You can verify this with help of the table below.

IP Prec IP Prec Bin DSCP Class DSCP Bin DSCP Hex DCSP Dec TOS value (snom)
0 000 Best Effort 000000 0x00 0 0
1 001 CS 1 001000 0x08 8 32
AF11-Low 001010 0x0A 10 40
AF12-Medium 001100 0x0C 12 48
AF13-High 001110 0x0E 14 56
2 010 CS 2 010000 0x10 16 64
AF21-Low 010010 0x12 18 72
AF22-Medium 010100 0x14 20 80
AF23-High 010110 0x16 22 88
3 011 CS 3 011000 0x18 24 96
AF31-Low 011010 0x1A 26 104
AF32-Medium 011100 0x1C 28 112
AF33-High 011110 0x1E 30 120
4 100 CS 4 100000 0x20 32 128
AF41-Low 100010 0x22 34 136
AF42-Medium 100100 0x24 36 144
AF43-High 100110 0x26 38 152
5 101 CS 5 101000 0x28 40 160
Expedited Fwdg 100010 0x2E 46 184

After setting the value to 96 in my SNOM I ran tcpdump and all packets from * TO the 360 were correctly tagged 0x18 whereas all packages FROM the snom to * were tagged 0x60. This clearly is not what the documentation above states. While thinking about brute force probing every value inbetween 0 and 255 I decided to simply put in 24 for a test. Voila. Next tcpdump had all packets to and from the snom tagged 0x18.

Conclusions: As of right now (FW 6.5.2), feed your SNOM the DCSP Dec value of your * DCSP Hex value to have them corresponding.

RADION OpenLAB