Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

New Member

Priority handling of IP encapsulated voice packets

Guys.<br>Here's a real screemer of a question from a client.<br>It relates to Unity and Ciso IP connection.<br><br>" What will guarantee the priority of the encapsulated voice packets over standard data traffic? "<br><br>Any ideas much appreciated.<br><br><br>


Re: Priority handling of IP encapsulated voice packets

This is really a question you should ask Cisco, but I will do my best to answer it.

The Cisco wave driver sets the TOS field in the IP header to 0xB0 for audio packets coming from Unity. The Cisco phones also set this value on audio packets they send.

Routers often give higher priority to packets with this value set. You should talk to Cisco about the QOS capabilities of the routers in your topology.

Aaron Belcher
Software Engineer
Active Voice


Re: Priority handling of IP encapsulated voice packets

Just a thank you to both for that info.
It will help tremendously in reponse to the client.
It might make them even think i "know" something!


Re: Priority handling of IP encapsulated voice packets

Packet voice is carried in an RTP stream over UDP. Cisco's VOIP and telephony solutions use UDP ports from 16384 to 32767 for this traffic. The prioritization method depends on the WAN technology used; generally, it's some sort of IP RTP PRIORITY command. For instance, for frame relay, a map class is created and applied to the frame relay interface of a router. The class may have a command similar to the following:

frame-relay ip rtp priority 16384 16383 64

This prioritizes rtp traffic with UDP port starting at 16384 and continuing upward an additional 16383 (I don't know why they didn't just let you specify the high end of the range but that's the way they did it). In this case, the third argument indicates that 64kbps of the traffic is subject to this prioritization. Any additional voice traffic will be subject to the same best-effort treatment as everything else (a rudimentary call admission mechanism). The prioritization is absolute so this could keep data traffic from being passed if the priority bandwidth is set too high for voice. Anyway, there are a bunch of ways to do this but this is the general idea. Hope it helps.