cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
774
Views
0
Helpful
7
Replies

Voice control signaling traffic from a Cisco phone

johnsos
Level 1
Level 1

Silly question I guess but here it goes. What is the purpose for having the RTP and control signaling traffic marked with different markings and then placing the traffic into different queues? What not treat all traffic coming from the phone the same? Help me understand the reason I would place the different traffic types into the separate queues. Thank you for your help in advance. P.S. is there any document that explains why this is done?

4 Accepted Solutions

Accepted Solutions

paolo bevilacqua
Hall of Fame
Hall of Fame

Hi,

technically speaking, media and traffic have different requirements in terms of latency and guaranteed delivery. The first must be treated with highest priority, while for the latter an higher latency is tolerated.

This is why you see the recommendation of putting them in a different queues, so that the LLQ queue is media only and no other traffic competes for it.

This said, in environments where there is little congestion or no congestion at all, you can place media and traffic in the same queue and there will be no difference, in fact you can have no differentiated queues at all.

View solution in original post

To add to the above, the signaling traffic is also typically TCP where RTP is UDP, so you cab afford to loose some signaling packets because it will be re-transmitted, so it does not need to be treated with the highest priority.

Chris

View solution in original post

Hi Johnsos,

I wouldn't be worried at all with signaling and traffic being in the same queue. Remember, these settings are important only for WAN designs where bandwidth is tight and you need to control and monitor your traffic down to the last bit. You also see that there are different philosophies when it comes to certain aspects of QoS. You appear to have diligently made your research already and now is time to go the implementation, to see yourself how things are working in practice.

Good luck!

View solution in original post

Actually Cisco no longer marks the signaling traffic as AF31, as of CCM 4.0 it's been changed to CS3 which is IEEE standard (not sure of the standard number), so as you can see Cisco follows industry standards. Are you positive that Nortel is using CS5? That sound odd...

Chris

View solution in original post

7 Replies 7

paolo bevilacqua
Hall of Fame
Hall of Fame

Hi,

technically speaking, media and traffic have different requirements in terms of latency and guaranteed delivery. The first must be treated with highest priority, while for the latter an higher latency is tolerated.

This is why you see the recommendation of putting them in a different queues, so that the LLQ queue is media only and no other traffic competes for it.

This said, in environments where there is little congestion or no congestion at all, you can place media and traffic in the same queue and there will be no difference, in fact you can have no differentiated queues at all.

To add to the above, the signaling traffic is also typically TCP where RTP is UDP, so you cab afford to loose some signaling packets because it will be re-transmitted, so it does not need to be treated with the highest priority.

Chris

johnsos
Level 1
Level 1

Thanks for your responses. Is there a best practice guideline for ip phone traffic? We do want to differentiate all voice signaling and RTP traffic from other types of data traffic. Our company decided to move toward a Nortel VoIP platform and how Nortel tags the RTP traffic with EF and its signaling traffice with CS5. This is unlike how Cisco does it which tags all RTP with EF and signaling with af31. (Pg 210 of the IP Telephony Self-Study Cisco QOS Exam Cert Guide Sec Ed.) "These settings are based on research from Cisco engineers." I guess I would like to know what they researched and how they came to the conclusions they did. If I don't change the default mappings (which I plan to) both RTP and signaling traffic would end up in the same queue at least for the Nortel phones. Oh yah, the decision to go with Nortel wasn't mine. I wanted Cisco.

:-)

Hi Johnsos,

I wouldn't be worried at all with signaling and traffic being in the same queue. Remember, these settings are important only for WAN designs where bandwidth is tight and you need to control and monitor your traffic down to the last bit. You also see that there are different philosophies when it comes to certain aspects of QoS. You appear to have diligently made your research already and now is time to go the implementation, to see yourself how things are working in practice.

Good luck!

Actually Cisco no longer marks the signaling traffic as AF31, as of CCM 4.0 it's been changed to CS3 which is IEEE standard (not sure of the standard number), so as you can see Cisco follows industry standards. Are you positive that Nortel is using CS5? That sound odd...

Chris

Pg 76 Document Number: 553-3001-160 Document Release: Standard 6.00

Date: November 2006

The Nortel standard DSCP for signaling is decimal 40. The Nortel standard DSCP for voice is decimal 46, based on six bits of an

8-bit field. Two bits are unused. The DSCP is configured in Element Manager.

And I thought that was a bit odd as well. I guess they have to try and be best at something. ;-)

johnsos
Level 1
Level 1

Thank you all for your responses. And all of you have a great and Happy New Year.

Steve