10-16-2013 01:50 PM - edited 03-16-2019 07:55 PM
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.
10-16-2013 02:08 PM
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?
10-16-2013 02:10 PM
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"
10-16-2013 02:56 PM
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
10-16-2013 04:44 PM
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"
10-16-2013 04:50 PM
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.
=/
10-16-2013 05:06 PM
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"
10-18-2013 09:39 PM
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.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide