CUBE configuration not functioning

[Levent Ozturk]

Hi,

I have configured a 2921 to act as a border element between an XTM machine (using SIP) and a call center (3rd party SIP).

XTM<------sip------>CUBE<-------sip-------->CALL CENTER

This setup is only used for calls that are originated from the xtm and destined to the call center.

I am not able to place a successful call. When i check the debugs i can see that the codec is succesfully negotiated, the incoming and outgoing dialpeer is matched correctly but for some reason the call does not get connected. Can somebody help me on this, am i missing some configuration?

I have attached the running config and debugs taken during the call tests. ("debug ccsip all" and "debug voice dialpeer")

In the debug: XTM IP:172.16.1.53,  CALL CENTER IP: 172.30.252.17

Thanks,

Levent

[Ayodeji Okanlawon · Accepted solution]

The reason the call is disconnected is due to toll fraud prevention feature in new IOS

SIP/2.0 403 Forbidden

Via: SIP/2.0/UDP 172.16.1.53:5701;branch=z9hG4bKa54b876a-313a-4a2b-8715-651946cab7d1;rport

From: "xtm_xtmtst01";tag=gtqepifg

To: <7777>;tag=40DB3C-150D

Date: Mon, 11 Mar 2013 10:24:01 GMT

Call-ID: deywfcxyuibwkneepflkrtxrugbxmgdkiqnwsddwtjuxwewlfc

CSeq: 1 INVITE

Allow-Events: telephone-eventS

erver: Cisco-SIPGateway/IOS-15.3.1.T

Reason: Q.850;cause=21

Content-Length: 0

The IP address of the XTM, 172.16.1.53 and 172.16.1.180 is not in the Trustedt list of the gateway..To resolve this configure the following:

conf t

voice service voip

ip address trusted list

ipv4 172.16.1.53 255.255.255.255

ipv4 172.16.1.180 255.255.255.255

Test again, send only debugs ccsip  messages

Please rate all useful posts

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

[Levent Ozturk]

Hi, thanks for the info. I have made the change and were able to progress. Now I can see the 200 OK message but for some reason the call disconnects afterwards.

I am attaching the ccsip debugs and the latest config.

Thanks for your time in advance.

[Ayodeji Okanlawon]

I looked at the debugs and I can see that the other end 172.16.1.53 does not respond to the 200 OK sent by the CUBE on 172.16.1.180..

You should check on that device and see whats happening? Did the 200 OK arrive there, why is it not responding

Please rate all useful posts

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

[daniel.bloom]

It looks like some of the debugs are missing so we don't actually see the whole call trace. In future try just using the "debug ccsip messages" debug. However as stated above the Cisco cube router is sending multiple 200 OK messages and doesn't get a response.

Sent from Cisco Technical Support iPhone App

[amansin74]

Get to know what your thrid party SIP is using.. Early offer/Early media/ delay offer etc..

Match it with configuration on Cisco Gateways and CUBE.

Also, try to get logs from your third party SIP call center... Every application should be able to create SIP Traces. Check in those traces if dicconnect cause is there.

Regards,

[Levent Ozturk]

I now have the SIP traces and as far as I see the 3rd party SIP device (XTM) sends a BYE message because of codec incompetency. (we were told that it supports only G711A but it seems the negotiation is made for G711U). Can you please have a look and share your opinions.

Thanks,

Levent

[daniel.bloom]

Your attached packet trace actually shows a call that was up for 14 seconds and looks like it contained audio in both directions. See attached SIP ladder for call trace. What was the issue experienced on this call?

[Levent Ozturk]

Thanks Daniel, I have also gone under Telephony--> VOIP Calls, decoded and listened to the call. I just hear voice from the call center end. I will re-test on Monday and let you know.

Thanks,

Levent

[daniel.bloom]

I can see RTP packets coming from 172.16.1.53 (XTM) to 172.16.1.180 (CUBE) however these streams do not contain any audio when decoded with wireshark. Are you able to capture packets anywhere from the XTM server back towards the calling device to see why there is no audio in these packets?

[Levent Ozturk]

I had to wait for a new test but now the issue is fixed: Daniel, as you mentioned the RTP was enabled for both directions but the microphone on the XTM client was defected! That was the reason of the weird graphic in wireshark for the media traffic coming from the XTM. We have changed the microphone and successfully made a call. So it seems adding the IP's under trusted list actually was the major change that made the setup work.

Thanks for your time.