Re: Cisco 7985 video via CUBE to Tandberg Telepresence Server

Nick Halbert-Lillyman · ‎09-06-2010

We currently have our Cisco Telepresence solution working well via a CUBE to a Tandberg Telepresence server, but we are unable to get a Cisco 7985 working via the CUBE. A CCSIP debug shows a "no sdp" error. This may have something to do with having "sdp passthru" enabled on the CUBE (?) for Telepresence. The SIP trunk from CUCM is just a basic default configuraiton.

The dial peers are also just basic configuaration (no codecs specified) - I've tried with "codec transperant" both on and off on the dial peers.

Any ideas?

Nick Halbert-Lillyman · ‎09-06-2010

I should clarify that it works "audio only"

auppal · ‎09-09-2010

This is a standard deployment for it to work correctly you need to invoke the invia zone i.e. cube and have the following commands

h225 connect-passthru
call start slow
no call sync-rsvp slow-start
h245 tunnel disable
h245 caps mode restricted
h245 passthru all

voice class codec 1
codec preference 1 transparent

voice class media 2
media flow-through

dial-peer voice 2 voip
description *** IP/IP ***
huntstop
voice-class media 2
voice-class codec 1
session target ras
dtmf-relay h245-alphanumeric
no vad

So Usually this config works if it doesnt then send me the following trace and i wil let you know why the negotiation is failing.

deb cch323 all

deb voip ccapi def

deb h225 asn1

deb h225 eve

deb h245 eve

deb ip tcp transaction

deb h245 asn1

deb voip ipip

Thanks

Nick Halbert-Lillyman · ‎09-12-2010

With "media flow through" enabled does that mean the CUBE won't be proxying the media and/or performing address hiding? We need it to act as a proxy between two networks.

Either way I will be trying out the config you've provided - thanks very much.

Nick Halbert-Lillyman · ‎09-21-2010

Can it work without using a gatekeeper - i.e. straight sip-to-sip as per Telepresence?

Currently, we dial into the Tandbeg TP server with a 7985 (using SIP), it connects, then says "Attention: no incoming video data" and disconnects after approx. 10 seconds.

The config we have below works perfectly for Telepresence. I tried removeing the rtp payload types from the dial peers as well as specifying the video and voice codecs (h264 and g77ulaw) but the result was the same. I also added huntstop, no vad and the voice classes as specified in the above config to the dial peers, but same result.

Config:

!

voice service voip

rtp-ssrc multiplex

address-hiding

allow-connections sip to sip

sip

session transport tcp

rel1xx disable

header-passing error-passthru

no update-callerid

midcall-signaling passthru

pass-thru content sdp

!

ccm-manager fax protocol cisco

!

mgcp fax t38 ecm

!

dial-peer voice 1 voip

description dial peer to Callmanager

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

incoming called-number 14...

destination-pattern 14...

dtmf-relay rtp-nte

codec transparent

session target ipv4: [Callmanager IP]

!

dial-peer voice 2 voip

description dial peer to Tandberg TP server

destination-pattern 10..

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

rtp payload-type cisco-codec-aacld 96

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

session protocol sipv2

incoming called-number 10..

session target ipv4:[Telepresence Server IP]

dtmf-relay rtp-nte

codec transparent

!

gateway

timer receive-rtp 1200

Nick Halbert-Lillyman · ‎09-23-2010

I should add that there is a Tandberg VCS between the CUBE and the Tandberg Telepresence Server.

So the call flow is 7985 -> CUCM -> CUBE -> VCS ->Telepresence Server

We managed to get the exact same result with the result with the config below, which is basically the same minus the Telepresence specific config - i.e. connects for a few seconds, says "no incoming video" and disconnects:

voice service voip

address-hiding

allow-connections sip to sip

sip

pass-thru content sdp

!

dial-peer voice 1 voip

description dial peer to Callmanager

session protocol sipv2

incoming called-number 14...

destination-pattern 14...

dtmf-relay rtp-nte

codec transparent

session target ipv4: [Callmanager IP]

huntstop

no vad

!

dial-peer voice 2 voip

description dial peer to Tandberg TP server

destination-pattern 10..

session protocol sipv2

incoming called-number 10..

session target ipv4:[Telepresence Server IP]

dtmf-relay rtp-nte

codec transparent

!

I note that if we remove "passthru content sdp" it won't connect at all.

carunach · ‎09-24-2010

No video could be due to Asymmetric Video RTP payload-type. IOS 15.1(1)T introduced Asymmetric payload type interworking :

http://www.cisco.com/en/US/docs/ios/voice/cube/configuration/guide/vb-gw-sipsip.html#wp1403792

1) What is the IOS version used in CUBE?

2) For the 7985 video call flow, can you please provide "debug ccsip all" and "debug voip ccapi inout" with the following config changes :

voice service voip

sip

asymmetric payload full

no pass-thru content sdp

midcall-signaling passthru

Arun

Nick Halbert-Lillyman · ‎09-27-2010

Hi,

Thanks for the reply. I've performed those changes and attached the debug to this post - thanks.

Nick Halbert-Lillyman · ‎09-27-2010

Sorry - I'll just add that we are running IOS version c3845-adventerprisek9_ivs-mz.124-22.YB6

carunach · ‎09-27-2010

A number of debug outputs are missing in the file. Can you please collect the debugs in the router's logging buffer :

1) Configure the following :

service timestamps debug datetime msec
service sequence
no logging console
no logging monitor
logging buffered 5000000 debug
no logging rate-limit

2) Recreate the problem

3) Then, collect the output by entering :

term len 0

sh log

Arun

Nick Halbert-Lillyman · ‎09-27-2010

Done and attached - cheers

carunach · ‎09-28-2010

TP server sends two m=video lines in the "200 OK" response, CUBE accepts the first m=video and rejects the second one. This is normal. Snip from ACK request sent to VCS

a=ptime:20
m=video 18942 RTP/AVP 112
c=IN IP4 y.y.y.y
a=rtpmap:112 H264/90000
a=fmtp:112 profile-level-id=42000D
m=video 0 RTP/AVP

The TIAS parameter is not passed by CUBE in the "200 OK" SIP response sent to CUCM and in "ACK" request sent to VCS (CSCtc00502 b=TIAS parameter is not passed through CUBE for DO-DO calls). Call Signaling looks fine otherwise. Couple of things that we can do :

1) Configure the following command in the outbound dial-peer 1041 and re-try the call (work-around for TIAS issue)

voice-class sip bandwidth video tias-modifier 2304000 negotiate answer

2) Once the call is connected, check whether the 7985 is transmitting and receiving video rtp packets by pressing the "?" button twice

3) If possible, collect sniffer capture between CUBE and VCS along with the same set of CUBE debugs.

Arun

Nick Halbert-Lillyman · ‎09-28-2010

We are now using a different CUBE for testing purposes (a 2811) and have upgraded the IOS to 151-2.T1 as you previously reccomended.

This has resulted in some improvement - the call now stays connected as audio only, as opposed to disconnecting after around 10 seconds. Pressing the '?' button twice on the 7985 reveals that it's sending video but not recieving. I got someone to check the Telepresence server and VCS and they say they are not recieving video.

I've also implimented the voice-class config change you reccomended, but the problem is the same. I've attached new debugs. I'll try and get a packet capture soon.

Thanks very much for your help!

Nick Halbert-Lillyman · ‎09-28-2010

OK I've performed a packet capture and debug for a call - both are attached.

carunach · ‎09-29-2010

Thanks. With the new version, CUBE is not negotiating the video stream correctly. I will research this further. I think it will be better to track this via a Service Request and then once the analysis / findings are complete, we can post the resolution to this forum. Let me know if you would like me to create a Service request.

Arun