CISCO and Polycom integration via CUBE

[filipequintela]

Hey Guys,

I believe this one is a good one.

I'm trying to integrate CISCO and Polycom using a CUBE.

What i got until now is:

1. Calls from CISCO to Polycom are perfectly fine.

2. Calls from Polycom to CISCO needs the intervention of a field engineer to set the correct bitrate bandwidth in order to function.

Item 2 is a big problem since endusers are terrible to understand voice/video concepts.

Also, some Polycom endpoints only works with maximum 64 kbps bitrate. No audio is being stablished on calls with bitrates greater than 64...

I want to have this to work automatically. Without user intervention.

Follow bellow my CUBE configuration.

Really appreciate some help.

[brmeade]

I'm confused on what your actual call flow is?

Something like Cisco IP Phone<->SCCP<->CUCM<->SIP<->CUBE<->Polycom SIP Phone ?

Just mentioning one side is Cisco and one side is Polycom is not enough details as both companies have many different products.

Also, can you collect a "debug ccsip messages" for both types of calls?

[Ayodeji Okanlawon]

Can you send us a debug ccsip messages from the cube?

Please rate all useful posts

"opportunity is a haughty goddess who waste no time with those who are unprepared"

[filipequintela]

Hey Guys,

Here is attached the debug ccsip all:

1. First call we were using 128 kbps and didn't worked.

2. Second call we have used 64 kbps and it worked.

Caller: 93501 - Polycom video endpoint HDX4500

Called: 9219357493 - cisco 6941

and also the CUBE config.

The interesting lines: (entire config is attached)

! Config to be applied on both CUBEs:

! 172.23.124.178
! 172.23.124.241

! Voice translation-rules that will allow only authorized traffic on the CUBEs.

voice translation-rule 10
rule 1 /^921935\(....\)/ /921935\1/ -----> rule for Bay View
rule 2 /^921934\(....\)/ /921823\1/ -----> rule for Cittá
rule 3 /^921933\(....\)/ /921821\1/ -----> rule for EBM
rule 4 /^9\(.......\)/ // ----> exclusion this won't match anything. Reason is that i received a request from Architecture to route calls that are only allowed and restrict others.

voice translation-profile VIDEOINTEGRATION
translate called 10

! Check URI for incomming ip address and if match consider only the dial-peer that has the translation-profile

voice class uri 1001 sip
host ipv4:172.23.182.24   -----------> DMA IP Address

! Inbound dial-peer that has the URI command and the translation profile

dial-peer voice 5003 voip

description VIDEOINTEGRATION

translation-profile outgoing VIDEOINTEGRATION

session protocol sipv2

session transport tcp

incoming called-number .

incoming uri via 1001

voice-class sip pass-thru content sdp

dtmf-relay rtp-nte

codec transparent

no vad

! Create a dial-peer that has a pattern 921

dial-peer voice 401 voip
description VIDEOINTEGRATION SEND TO BAYVIEW
preference 1
max-conn 10
destination-pattern 921.......
session protocol sipv2
session target ipv4:172.24.96.98
dtmf-relay rtp-nte

codec transparent

dial-peer voice 402 voip
description VIDEOINTEGRATION SEND TO BAYVIEW
preference 2
max-conn 10
destination-pattern 921.......
session protocol sipv2
session target ipv4:172.24.96.99
dtmf-relay rtp-nte

codec transparent

! Outgoing dial-peer that has the route to 976.......

dial-peer voice 801 voip

description to VIDEOPOC-TO-BAYVIEW

destination-pattern 976.......

session protocol sipv2

session target ipv4:172.23.182.24

dtmf-relay rtp-nte

codec transparent

! Stuff necessary to have compatibility with non CISCO devices.

voice service voip

  sip

    asymmetric payload full

[Ayodeji Okanlawon]

From the logs,

CUBE doesnt seem to like the media types advertised in the media lines for "m=application" in m-line 3 and 4.

m=application 49190 RTP/SAVP 100

a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:yEx5CIHH6c1lsD771ocBmcdgtHSYuuALrs4jH6Vs|2^31

a=crypto:2 AES_CM_256_HMAC_SHA1_80 inline:rmsGLdS7kDcYS0e3A0E1RtBnf/4NAFc7NVs1vGLkQnFzKE2Erx6yg2hiHpeDCw==|2^31

a=rtpmap:100 H224/4800

a=sendrecv

m=application 40157 UDP/BFCP *

a=floorctrl:c-s

a=setup:actpass

a=connection:new

ct 16 20:33:02 UTC: //2022/FD02230288A1/SIP/Info/sipSPIValidateConnectionAddress: Dest port = 49190

SIP: (2022) Attribute mid, level 3 instance 1 not found.

Oct 16 20:33:02 UTC: //2022/FD02230288A1/SIP/Info/sipSPIValidateStreamAddrType: stream:3, Mode : 1

Oct 16 20:33:02 UTC: //2022/FD02230288A1/SIP/Info/resolve_media_ip_address_to_bind: Media already bound, use existing source_media_ip_addr

Oct 16 20:33:02 UTC: //2022/FD02230288A1/SIP/Media/sipSPISetMediaSrcAddr: Media src addr for stream 3 = 172.23.124.186

Oct 16 20:33:02 UTC: //2022/FD02230288A1/SIP/Error/sipSPIDoMediaNegotiation: Ignoring unsupported media type (2) in media line 3

Oct 16 20:33:02 UTC: //2022/FD02230288A1/SIP/Info/sipSPIValidateConnectionAddress: Dest port = 40157

BRVIX5VALEVG003#SIP: (2022) Attribute mid, level 4 instance 1 not found.

Oct 16 20:33:02 UTC: //2022/FD02230288A1/SIP/Info/sipSPIValidateStreamAddrType: stream:4, Mode : 1

Oct 16 20:33:02 UTC: //2022/FD02230288A1/SIP/Info/resolve_media_ip_address_to_bind: Media already bound, use existing source_media_ip_addr

Oct 16 20:33:02 UTC: //2022/FD02230288A1/SIP/Media/sipSPISetMediaSrcAddr: Media src addr for stream 4 = 172.23.124.186

Oct 16 20:33:02 UTC: //2022/FD02230288A1/SIP/Error/sipSPIDoMediaNegotiation: Ignoring unsupported media type (2) in media line 4

Oct 16 20:33:02 UTC: //2022/FD02230288A1/SIP/Error/sipSPIDoMediaNegotiation:

no valid fax or audio streams

Oct 16 20:33:02 UTC: //2022/FD02230288A1/SIP/Error/sipSPIHandleInviteMedia: Media Negotiation failed for an incoming call

Oct 16 20:33:02 UTC: //2022/FD02230288A1/SIP/Info/ccsip_set_cc_cause_for_spi_err: Categorized cause:65, category:278

Oct 16 20:33:02 UTC: //-1/xxxxxxxxxxxx/SIP/Info/ccsip_set_release_source_for_peer: ownCallId[2022], src[6]

Oct 16 20:33:02 UTC: //2022/FD02230288A1/SIP/Info/sipSPIContinueNewMsgInvite: ccsip_api_call_setup_ind returned: SIP_UNACCEPTABLE_MEDIA_ERR

Oct 16 20:33:02 UTC: //2022/FD02230288A1/SIP/Error/sipSPIContinueNewMsgInvite: Unacceptable media indicated for INVITE

Oct 16 20:33:02 UTC: //2022/FD02230288A1/SIP/Info/ccsip_set_cc_cause_for_spi_err: Categorized cause:65, category:278

The issue lies here..

Can you post a trace of a working call? When you say you set the bit rate to 64k. What do you mean? Is that the payload used on a video codec or ???

Please rate all useful posts

"opportunity is a haughty goddess who waste no time with those who are unprepared"

[filipequintela]

on the same trace there's a call which is working.

same caller and called number.

On the polycom codec there's some settings where you can specify which bandwidth to use on the call. When i do set this to 64 kbps the call completes perfectly fine. audio both sides!

have tried diferent setups on the incomming dial-peer but till now nothing...... i'm bit frustated.

=/

[Ayodeji Okanlawon]

The trace for the working call has only one m=application line and doesnt have the m-line with generic BFCP..

m=application 49196 RTP/SAVP 100

a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:WiPpzgkcagvZtG8Y7s30ApFqzafkY5C2jKvKHrS5|2^31

a=crypto:2 AES_CM_256_HMAC_SHA1_80 inline:fW10KOrCIDb95XDvcu9ORAqjTXasCR32CFZS/6x2q3TETa3wH1DVzbdc7C9LFw==|2^31

a=rtpmap:100 H224/4800

a=sendrecv

Thats all the application m-lines it has. The failed call has two m-lines for application

Please rate all useful posts

"opportunity is a haughty goddess who waste no time with those who are unprepared"

[Jorge Armijo]

Did you try using content Pass-through?

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

HTH

--
Jorge Armijo

Please remember to rate helpful responses and identify helpful or correct answers.