TOS/DSCP marking of SIP/RTP by 3CX Phone System

[suse]

Hello,

Your product looks and works great (extremely simple to set-up compared to other similar solutions), however one thing looks odd to me - why there's no option present to set TOS/DSCP marking of the SIP/CALL ?
I've captured the call with ethereal and SIP/RTP packets are not marked in any way (TOS not set and DSCP value 0x00).
This might present a problem if IP calls are made in distributed LAN , as in VPLS service.
Many hardware VOIP gateways provide an option to mark the originating traffic and thus make it easier for the access-level equipment to classify the VOIP sessions.

 

[Fynskisb16]

I've noticed the same issue. To overcome this issue you can have your switch remark packets that come from the server and also your phones or ATA's. You can match on udp/tcp ports, the ports themselves or even the vlan that the phones are on ( if you have your network setup that way).

If your phones are capable of marking packets, your switches could match on the TOS/DCSP thus giving you LAN QOS.

If you are using a VoIP provider you can mark packets on your router to give priority to the voice traffic.

This all depends on your networking gear.

 

[suse]

Hi Fynskisb16,

I agree, classification & marking can be done at the access/aggregation equipment, but wouldn't it be logical to provide an option in 3CX to set TOS/DSCP and then configure the 3rd party switch to trust the marking (like autoqos voip trust in Cisco) ?
And what if i have a dumb pure L2 device which is not capable to perform classification & marking or is too weak to do it ?
My whole point is about VPLS /E-LAN connected offices - pure L2 setup where the SP can queue traffic according to the already made marking. Unless the 3CX can provide such an option , the viable approach would be putting additional box at the wiring closet level - which means rasing CAPEX for the whole setup

 

[SY]

Could you please describe real benefits of using these features? Which kind of problems can be resolved by using it? It is really interesting!

Thanks for helping us!
Stepan

 

[suse]

hello SY,

Suppose you have a VPLS service / L2VPN connecting your branches. Basically you have an ethernet connection between all your offices/buildings. Although as Fynskisb16 had suggested , you would probably separate your phones from the rest of the network by using a different vlan , you might have other traffic running on the same vlan. As long as you operate within 1Gigabit LAN, your calls probably wouldn't be affected - there's enough bandwidth for every creature. But, probably you would have much lesser links between your branches - meaning congestion comes to play. Obviously you would want to deploy some QOS scheme in order to prioritize the VOIP traffic over other kinds. Most multi-service switches vendors provide the option for COS-aware services - meaning you can send the VOIP marked with high DSCP/TOS and the SP can assign the VOIP to a real-time queue , based on your marking and thus transfer it over the VPLS to its destination. You can mark the VOIP traffic either at the Phone/Server or at the access switch/gateway router.
So , in my opinion , having such an option in 3CX system would be beneficial and eliminate the need for QOS policing in the connecting switch/router.

 

[SY]

hello SY,

Suppose you have a VPLS service / L2VPN connecting your branches. Basically you have an ethernet connection between all your offices/buildings. Although as Fynskisb16 had suggested , you would probably separate your phones from the rest of the network by using a different vlan , you might have other traffic running on the same vlan. As long as you operate within 1Gigabit LAN, your calls probably wouldn't be affected - there's enough bandwidth for every creature. But, probably you would have much lesser links between your branches - meaning congestion comes to play. Obviously you would want to deploy some QOS scheme in order to prioritize the VOIP traffic over other kinds. Most multi-service switches vendors provide the option for COS-aware services - meaning you can send the VOIP marked with high DSCP/TOS and the SP can assign the VOIP to a real-time queue , based on your marking and thus transfer it over the VPLS to its destination. You can mark the VOIP traffic either at the Phone/Server or at the access switch/gateway router.
So , in my opinion , having such an option in 3CX system would be beneficial and eliminate the need for QOS policing in the connecting switch/router.

I'm asking about real benefit. What will happen if other application will mark its own traffic using the same way (or thousands of application?)?

In general, it is interesting if NAT devices will pay attention regarding nature of port mapping. It will be a real benefit! Can it happen in reality?

Thanks,
Stepan

 

[suse]

Stepan,

You can define QOS trust boundaries . This is exactly the reason why most service providers deploy "untrusted" mode for client-side traffic.
But this would not be an issue with VPLS/L2VPN - since you have a full control of your network and can make sure how other apps behave. The service provider can also check for application signature or do some other L3/4 filtering , but we're not discussing metro equipment here.

NAT is also not an issue in VPLS/L2VPN setup - there's no need to translate between addresses in LAN.

 

[archie]

Guys, I promise to dig in all that stuff, and implement it if we'll found it worth of efforts. So, in best case you can expect it in version 4. Just give me a time to finish that version. There's a load of stuff to be done yet.

 

[Fynskisb16]

Sweet. Look forward to the new feature. When is version 4 expected to be released?

 

[archie]

With God's help I hope first beta will be ready in 2 month

 

[SY]

Stepan,

You can define QOS trust boundaries . This is exactly the reason why most service providers deploy "untrusted" mode for client-side traffic.
But this would not be an issue with VPLS/L2VPN - since you have a full control of your network and can make sure how other apps behave. The service provider can also check for application signature or do some other L3/4 filtering , but we're not discussing metro equipment here.

NAT is also not an issue in VPLS/L2VPN setup - there's no need to translate between addresses in LAN.

So... Did you request the PBX to mark its own traffic to simplify management of chaos in network?

In next version we will mark our traffic, but :!:, you will consult other forum members regarding "choppy sound". Do you agree?

P.S. Anyway, thanks a lot for a hint!

 

[suse]

So... Did you request the PBX to mark its own traffic to simplify management of chaos in network?

No, not really. I expect the "IP PBX" to allow the flexibility needed in order to make the VOIP calls work in the best way possible. A part of such flexibility is choice how to mark the VOIP packets. Obviously, VOIP doesn't exist on it's own , otherwise we would get the TDM/Traditional telephony benefits of having dedicated bw for the call and without the headaches of jitter/delay/latency.
Current approach of not marking the packets and saying : "let other 3rd party equipment worry about it" should be revised.
I really do hope we will see an option to mark the VOIP packets in version 4

 

[Anonymous]

So... Did you request the PBX to mark its own traffic to simplify management of chaos in network?

In next version we will mark our traffic, but :!:, you will consult other forum members regarding "choppy sound". Do you agree?

P.S. Anyway, thanks a lot for a hint!

I think it is a good idea to support ToS and QoS packet tagging, mind you both get overrulled by the VLAN tag, but not all of us have that type of config.

VoIP is a typical low latency application and should be makred as high-priority throughout the network, commonly this is done atm using the nic in the 3cx server but that is giving it a false impression.

QoS is a collection of technologies that allows applications to request and receive predictable service levels in terms of bandwidth, latency variations, and delay. So having said that, for VoIP you will look at max loss tolerant of 1% and a MAX one way latency of 200ms also the jitter should not be more than 30ms.

So where we looking at (again the bandwith stuff ) You need a guaranteed priority bandwith of approx 15 - 106kbps. Depending on the overheads for codecs and layer 2 switching.

TOS is not supported by all VSP as with QoS a lot of them support that, the issue is aswell what your devices are able to support.

See it is ok to have tagging within your network but if the edge does not support it than all you do is adding overhead (very small though).

Never the less I fully agree with SUSE it would be good to have 3CX conform with the tagging for TOS and QoS.

Question for SUSE (as you seem to be up the speed with this stuff) has this tagging been changed between IPv4 and IPv6?

Also what QoS are we looking at?
IP QoS or Ethernet QoS.

For those who want to know:
IP QoS allows you to classify traffic based on source address, source port, destination port, port ranges, protocol ID, DSCP, IP Precedence values, routing protocols (RIP, OSPF, BGP or EIGRP), and transport protocols (FTP, http, telnet, SMTP, TFTP, or other user defined TCP or UDP protocol number or range).

With Ethernet QoS you can classify traffic based on Class of Service (CoS), DSCP, and IP Precedence values.

But again, I am a bit rusty on this stuff. So it only food for thought I guess.

Suse, what is your take on this. (I think you already answered that in your posts actually).

 

[SY]

There are really no problems to support it (QoS etc) . I just asked about real benefits and expected level of improvements in comparing to current version of PBX. Let say I asked for description of the test case which will highlights real improvements. It is very clear in theory, but it will be good to have some practical information

Thanks,
Stepan

 

[suse]

Question for SUSE (as you seem to be up the speed with this stuff) has this tagging been changed between IPv4 and IPv6?

Hello itfarmer,

I'll try to give a very rough answer - IPv6 includes standardised support for QoS.

QoS instructions are included in the IPv6 packet header. Basically , there're 2 new IPv6 QoS Fields :

a. Traffic Class
b. Flow Label

Flow Label - used to identify packets belonging to an individual QoS flow. Potentially , it allows for routers to allocate the necessary amount of bandwidth to those packets. However, there is always a difference between theory and implementation.
Traffic Class - The traffic class field may be used to set specific precedence or DSCP values. These values are used in the exact same way as in IPv4. Example for potential benefits - the packet body can be encrypted, but QoS will still function because the header portion containing the QoS instructions is not encrypted. This will make it possible to send streaming audio and video over the Internet with IPSec encryption, but in a manner that guarantees adequate bandwidth for real-time playback. Once again , real-world implementation is yet to be seen.

Also what QoS are we looking at?
IP QoS or Ethernet QoS.

Suse, what is your take on this. (I think you already answered that in your posts actually).

In my initial post , I was referring to the Ethernet QoS - classification & queuing based on TOS/DSCP marking.
The reason behind this is pretty clear - pure ethernet services are on the rise , we're bound to see many more L2VPN/VPLS at the enterprise level.
Also, L2 QoS means less processing power - no need for CPU handling .
Consider also transport systems which deploy additional encapsulation - then you would have to base your classification & queuing only on the the ethernet layer marking.

The "right" model for QoS deployment will probably involve both IP QoS and Ethernet QoS - really depends on the network topology and equipment specs.

 

[suse]

Let say I asked for description of the test case which will highlights real improvements. It is very clear in theory, but it will be good to have some practical information

Thanks,
Stepan

erm.. you might want take a look at Ixia - Triple Play QoS Functional Test
Quoting the results part :

... shows that the VoIP MOS estimate drops from a high of 4.4 down to a low of 1.0, while the Video MLR changes from 0 to an average of 400 media packets/second when QoS is changed from enabled to disabled.

Although , the aforementioned test is a simulation , it gives a pretty good impression of to which extent proper QoS handling affects VOIP.
From my personal experience, there're countless stories when complaints about "one way hearing / disconnections / etc " turned out to be the fault of NO-QoS / Improper use of QoS / bad network design.
Hope it answers your question

 

[SY]

Let say I asked for description of the test case which will highlights real improvements. It is very clear in theory, but it will be good to have some practical information

Thanks,
Stepan

erm.. you might want take a look at Ixia - Triple Play QoS Functional Test
Quoting the results part :

... shows that the VoIP MOS estimate drops from a high of 4.4 down to a low of 1.0, while the Video MLR changes from 0 to an average of 400 media packets/second when QoS is changed from enabled to disabled.

Although , the aforementioned test is a simulation , it gives a pretty good impression of to which extent proper QoS handling affects VOIP.
From my personal experience, there're countless stories when complaints about "one way hearing / disconnections / etc " turned out to be the fault of NO-QoS / Improper use of QoS / bad network design.
Hope it answers your question

Not all people know how to manage NAT, I think, less number of people know about QoS management. Most of problems related exact to "bad network design" or absence of its management. (sure, some problems is related to PBX implementation ) So QoS will just additional "small potion of healing" for such cases.

 

[nathan]

It would be great to see DSCP marking as an option. The routers I am using lately all support bandwidth allocation based on DSCP amongst other things so it would be very handy.

Nathan

 

[alicic]

But the Routers more often do not trust IP phones for traffic marking so anyhow they will remove marked bits. What is imortant to make shaping and marking at Router level or LAN switch before traffic traverse WAN liong. It is the best method.

 

[SY]

Version 5 supports TOS marking for RTP streams if call is in proxy or transcoding mode. In bypass mode it is up to devices. It is experimental option.
name: msRTPTOS
section: [Network]
file: 3CXPhoneSystem.ini
values: 0-63 all other values is the same as 0 (default)
Please inform if it works. It is really up to gateway to ignore it or take it into account.

Regards