Re: CTS video through Cube to 9971 doesn't work well

gilbert spoor · ‎06-12-2012

Hi,

I am running a Lab with two CUCM8.6.2 environments and a router acting as CUBE in between.

In one environment I have a video SIP phone (Cisco E20) and a cts-1100 running software 1.9.

in the other environment I have an E20 and a Cisco 9971 video enabled phone.

a cisco 2921 router is configured for the CUBE functionality.

I can call between the two environments without any problem using the E20's audio and video gets relayed by the cube.

But when calling between the CTS-1100 and the E20 or the 9971 in the other environmkent doesn't work well, the E20 doesn't receive video or audio and remains in an answering state, while the CTS receives audio and video from the e20 through the cube (so one way media)

when the CTS calls the E20 that is registered to the same callmanager audio and video work fine.

does anyone know what I'm doing wrong?

Below the config of the router:

version 15.0

service timestamps debug datetime msec

service timestamps log datetime msec

service password-encryption

!

hostname Router

!

boot-start-marker

boot-end-marker

ip source-route

ip cef

!

vlan ifdescr detail

multilink bundle-name authenticated

!

voice-card 0

dspfarm

dsp services dspfarm

!

voice service voip

rtp-ssrc multiplex

address-hiding

allow-connections sip to sip

redirect ip2ip

fax protocol t38 ls-redundancy 0 hs-redundancy 0 fallback none

sip

bind control source-interface Loopback0

bind media source-interface Loopback0

session transport tcp

rel1xx disable

header-passing sip-sip

midcall-signaling passthru

g729 annexb-all

pass-thru content sdp

!

voice class codec 1

codec preference 1 aacld

codec preference 2 g711alaw

codec preference 3 g711ulaw

codec preference 4 g722-64

codec preference 5 g728

!

hw-module pvdm 0/0

!

interface Loopback0

ip address 10.0.0.1 255.255.255.255

!

interface GigabitEthernet0/0

ip address 192.168.222.10 255.255.255.0

duplex auto

speed auto

!

interface GigabitEthernet0/1

ip address 10.1.1.254 255.255.255.0

duplex auto

speed auto

!

interface GigabitEthernet0/2

ip address 10.2.2.254 255.255.255.0

duplex auto

speed auto

!

ip forward-protocol nd

!

no ip http server

ip http secure-server

!

ip route 192.168.255.0 255.255.255.0 192.168.222.254

!

control-plane

!

codec profile 1 aacld

!

codec profile 2 h264

!

codec profile 3 h263+

!

codec profile 4 h263

!

dial-peer voice 1 voip

description cucm1

destination-pattern 1...

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

session protocol sipv2

session target ipv4:10.1.1.1

voice-class codec 1

dtmf-relay rtp-nte

!

dial-peer voice 2 voip

description cucm2

destination-pattern 3...

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

session protocol sipv2

session target ipv4:10.2.2.1

voice-class codec 1

dtmf-relay rtp-nte

!

sip-ua

no remote-party-id

retry invite 2

!

gatekeeper

shutdown

!

Nick Halbert-Lillyman · ‎06-12-2012

Try removing the codec profiles from the dial peers and just having "codec transparent". Make sure your regions on CUCM are allowing the right bandwidth and audio codecs between the endpoint region and trunk region.

For CTS, we had issues with 1.9 via CUBE but 1.8 worked fine.

We also had the following additional configuration on our CUBE:

Voice service voip

fax protocol t38 version 0 ls-redundancy 0 hs-redundancy 0 fallback none

sip

session transport tcp

min-se 500 session-expires 500

reset time expires 183

In addition, we were using the following payload types that differed from yours:

dial peer voice XXX voip

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

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

rtp payload-type cisco-codec-fax-aacld 96

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

I think these should only matter for CTS however.

gilbert spoor · ‎06-13-2012

Hi Nick,

Thank you for your answer.

I tried the suggestions you made, but sadly without result.

I downgraded the cts, removed the codec profile,s added the codec transparent commands and changed the voice dervice sip configuration..

but still the same results.

dial peers now look like this:

dial-peer voice 1 voip
description cucm1
destination-pattern 1...

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:10.1.1.1
dtmf-relay rtp-nte

codec transparent
!
dial-peer voice 2 voip
description cucm2
destination-pattern 3...
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:10.2.2.1
dtmf-relay rtp-nte
codec transparent

Nick Halbert-Lillyman · ‎06-13-2012

The other thing I would try is removing the CUBE from the path (you say you are in a lab so this should be possible right?)

Change the IP address on your SIP trunk on CUCM A to point to CUCM B and visa versa - don't create a new trunk, you want to ensure that everything except the cube being in the way is the same. Test again and see if your issues persist - if they do, I'd look at trunk, region and SIP trunk/SIP trunk security profile settings.

I'll also tell you what my working CUBE has/doesn't have on it that's different to yours - some of it may not matter, but no harm in trying:

put 'no' infront of all these:

redirect ip2ip, header passing sip to sip, all the DSP/PVDM stuff (no transcoding is needed for this), G729 annex b all

Also:

voice service voip

default rtcp multiplex <---- (pretty sure this will break the E20 to 9971 connection otherwise)

and add the following:

conf t

gateway

timer recieve-rtp 1200

gilbert spoor · ‎06-14-2012

Hi Nick,

Without the cube inbetween it works like a charm.

I changed the config with your suggestions, but the behaviour remains the same.

the E20 remains in answering state when being called by a CTS through the cube.

but if I call it from a cius through the cube it works fine.

weird isn't it?

Michael Boscia · ‎06-15-2012

What is the goal of having the CUBE in the path?

Sent from Cisco Technical Support iPhone App

gilbert spoor · ‎06-18-2012

Hi Michael,

The reason we want to use the cube is because we want to build a Telepresence exchange, connecting different environments to eachother without providing access to eachothers networks.

The Cube should provide the connectivity.

Michael Boscia · ‎06-18-2012

You are correct, the CUBE should do that.

However, the configuration you provided appears to be a CUBE (ENT) config.

To build a TP Exchange, you need CUBE (SP), and that only runs on the ASR. It also has a very different configuration model.

Sent from Cisco Technical Support iPhone App

gilbert spoor · ‎06-18-2012

Hi Michael,

Thank you for the reply,

What is the difference in SP and ENT cubes?

To be honest, I have never heard there is a difference in types of cubes.

gilbert spoor · ‎06-18-2012

Hi Michael,

CTS traffic through a cube(ent) seems to be possible according to this link (was your thread I believe ;-)
https://communities.cisco.com/thread/11428

Or is there something I am missing here?

Michael Boscia · ‎06-18-2012

You're not missing anything, although it is amusing that you referenced a very old thread of mine.

The context of that conversation was how to provide enterprise Telepresence SBC functionality to customers that were uncomfortable allowing direct L3-L5 connectivity between the CUBE (SP) SBC in a TP exchange environment and their CTS units and their TP core infrastructure.

There is a fairly significant difference in CUBE functionality between the SP and ENT product lines.

Without going into detail, the main differences are features and call density.

CUBE (ENT) has a lot of different features and has lower call densities on a per-device basis. As you can probably guess from the name, it is targeted at the enterprise market. You can run CUBE (ENT) on a wide range of ISR chassis. You can even run it on an ASR.

CUBE (SP) has a somewhat smaller featureset, but has vastly increased the call density that a single router can handle. On an ASR-1006 with an ASR1000-ESP40, as long as you can get that much bandwidth to the box, in theory, that module can handle 20 Gbps of bi-directional Telepresence traffic, or 40 Gbps of uni-directional traffic (same number, just depends on how you look at it). Cisco makes smaller ESP modules, that was just an example.

If you're looking to build a TP exchange, CUBE (SP) is the way to go, simply from a call density perspective.

I never really looked at building a service around the CUBE (ENT). Not saying that you can't, but I am not sure that all of the various configuration options that are typically deployed on the CUBE (SP) on ASR are available on the ISR running CUBE (ENT), specifically the multi-VRF configuration, the access/core adjacency model, the call routing configuration....etc....etc......

I've spoken to Nica a few times, and our employers have a very deep relationship already, so we should probably be having this conversation at a much higher level.

gilbert spoor · ‎06-19-2012

Hi Michael,

the exchange we are building won't have that high call density (yet).

It is to connect the one customer to the other customer more like a proof of concept.

so apart from the call density issues, I think it must be possible to build this on ISR platform as well.

the question remains, why it doesn't seem to work on that ISR (ENT) cube.

I'll say Hi to Nica for you ;-)

You're at Orange, right?

Nick Halbert-Lillyman · ‎06-17-2012

Hmm.... the only other thing I would suggest would be to make sure your IOS is on the latest version of 15.X, alternatively try using the latest version of IOS 12.4.x.........

We did have some IOS issues... other than that we had it working with the config I have described above.

gilbert spoor · ‎06-18-2012

ok will try older software.

i already tried 15.0 and 15.2

gilbert spoor · ‎06-25-2012

Well... it wasn't the configuration of the cube.

It seems so that the CTS codec uses the 10.0.0/24 network internally for some internal purposes, so when you configure 10.0.0.1 as the loopback address on the cube router the cts units cannot communicate with them.

I changed the cube loopback address to 10.100.0.1 and it started working like a charm!

thank you all for the support ;-)