CUBE dial-peer marking Telepresence video as EF (instead of CS4)

Michael Honeyman · ‎02-13-2012

I'm not sure if this is better posted here or in the Telepresence community. My question relates to CUBE video features though so I've started here.

Background

I administer a Cisco Telepresence System (CTS) on CUCM 8.5. For external CTS calls we have a CUBE running IOS 15.1(3)T1 that proxies both signalling and media (media flow-thru) between endpoints and a Telepresence Server bridge.

My question relates to dial-peers and DSCP markings.

By default CTS endpoints mark signalling traffic (SIP) as AF31, video traffic as CS4 and voice as EF. We're not running RSVP anywhere but there is per-hop QoS configured throughout the network.

Question

I recently discovered that the CUBE is marking all of the proxied traffic as EF. I tried adjusting the relevant dial-peers to mark video as cs4 (ip qos dscp cs4 video rsvp-none), but this had no effect. The documentation for the dial-peer qos commands indicate that the ip qos dscp [xx] video options only apply if the CUBE is also running CME. But given the CUBE participates in (or at least witnesses) the set-up messages for both audio and video RTP streams, surely it should be able to differentiate?

How can I get the CUBE to mark proxied video traffic as CS4 instead of EF, whilst maintaining the voice RTP as EF?

Relevant config:

voice service voip

rtp-ssrc multiplex

address-hiding

allow-connections sip to sip

sip

rel1xx disable

min-se 500 session-expires 500

no update-callerid

midcall-signaling passthru

pass-thru content sdp

reset timer expires 183

!

dial-peer voice 1 voip

destination-pattern [pattern]

rtp payload-type cisco-codec-fax-ack 111

rtp payload-type cisco-codec-fax-ind 110

rtp payload-type cisco-codec-aacld 96

rtp payload-type cisco-codec-video-h264 112

session protocol sipv2

session target ipv4:[address]

incoming called-number [pattern]

dtmf-relay rtp-nte

codec transparent

ip qos dscp cs4 video rsvp-none

no vad

!

! (dial-peer for other call-legs are the same)

!

Thanks in advance for your help!

Karthik Sivaram · ‎02-29-2012

hi Michael,

Just to comment on this. I just would like to word it differently.

All regular ways of marking and classifying traffic will work on CUBE,

as it is IOS router in this area.

The QoS is not specific to CUBE, it is the IOS feature which is working

on all IOS routes.

But in addition to the LLQ and policy markings we also can use the

dial-peer markings.

So on the dial-peer level we can set the DSCP as:

dial-peer voice 1 voip

...

ip qos dscp ef media <<<<<<<<<<<<<<<

ip qos dscp cs3 signaling

ip qos dscp cs4 video rsvp-none

...

BUT!

Your problem is not setting DSCP for outgoing traffic on CUBE routers,

but how router is treating the RTP it receives.

And for that you need to make sure the DSCP is correct on INCOMING

interface.

And if you would like to re-classify it - you can do that in incoming

interface of CUBE.

Here I am referring to CUBE as the boundary device - so we can say CUBE

has "internal" interface and "external" interface .

Although in your case both part of the networks are under one

administration, CUBE as border element is to do the job of re-marking

and re-classifying the incoming and outgoing traffic.

Hope this helps!

Thanks,

Karthik

.

Michael Honeyman · ‎03-13-2012

Hi Karthik,

Sorry for the delay, my email notifications aren't working for some reason.

The DSCP for RTP (and SIP for that matter) traffic on the ingress to the CUBE is definitely correct. I've verified this by putting an inbound policy-map on the ingress interface that just matches DSCP markings and can see counters for AF31 (SIP), CS4 (Video RTP) and EF (Voice RTP) incrementing. What I see on the egress interface using the same policy map (but outbound) is that only AF31 and EF leave the router.

The CUBE is doing media flow-thru so is proxying both SIP and RTP traffic based on the dial-peers. I can only imagine that when IOS reconstructs the IP headers for the proxied traffic it is not differentiating between RTP voice and RTP video as the configuration suggests it should.

Telepresence multiplexes voice and video streams so that you get one RTP stream with (potentially) multiple voice sessions and one RTP stream with (potentially) multiple video sessions. Perhaps this somewhat non-standard behaviour has something to do with what I'm observing?

The only other thought I've had is that perhaps the QoS markings applied to the newly crafted packet are selected based on the in-bound dial-peer, which perhaps I am not matching correctly. However if that was the case I ought to be seeing AF41 traffic leaving the CUBE as that is the default marking for video.

This one has me stumped! I have another platform that is in pre-production testing to replace the CUBE in question, I will see if it is demonstrating the same behaviour in the coming days.

nick.mueller · ‎04-30-2012

Hi Michael,

Was this ever resolved for you?

NPM

Michael Honeyman · ‎06-22-2012

Hi Nick, I never got to the bottom of it. Oneday I'll find time to troubleshoot it with the TAC. In my present situation though it doesn't really matter that the CUBE is marking all RTP as EF as in the two networks concerned it is treated equally with CS4 / AF41.