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

Unity IP Packet Prioritization is Gone

Since upgrading from Unity 3.1.3 to 4.02, our prioritization of Unity voice streams by marking RTP packets in the UDP range 16384 32767 appears to be no longer functioning. Did Unity change the way it sends the streams at an IP packet level such that watching for and marking IP RTP packets is no longer valid?

New Member

Re: Unity IP Packet Prioritization is Gone

When you install Unity 4.0(2), you also get the 7.0(2) TSP. Starting in the 7.0(1) TSP we do change slightly the DSCP markings of the RTP stream.

Pre 7.0(1), we marked the RTP (over UDP) packets as DSCP 44 (the IP-header TOS octet was 0xB0).

Post 7.0(1), we mark the RTP packets as DSCP 46 (the IP-header TOS octet is 0xB8).

This change was made to comply with the rest of the Cisco AVVID product line, so I'd be surprised if it's causing problems. (Most people were complaining that we did it the old way before.) Is this the specific change that's causing problems for you? If so, you might have to adjust the routers such that they treat DSCP 46 the way they used to treat DSCP 44.

Let me know if you have any questions, or if this isn't what you're seeing.

New Member

Re: Unity IP Packet Prioritization is Gone

Thanks for this information. I was able to get it working again. Apparently, Cisco changed more than the DSCP value because my QoS ACL was scanning/marking Unity voice packets based on the RTP UDP port range and manually marking to DSCP 46. Therefore, the incoming DSCP from the Unity server was overwritten (not "trusted"). This has quit working since Unity must no longer be using RTP UDP in the standard range(?).

At any rate, I have simply trusted the incoming DSCP from the server now that it is correct. It would be nice if there was a better "vehicle" for letting us know when such significant changes are made to QoS mechanisms! It was not obvious in the upgrade documentation.

Thanks again.