SIP question for Ayodeji - SIP - call drops after unexpected greeting

[Jim Kozlowski]

Deji –

I have a question based on your https://supportforums.cisco.com/discussion/12391651/ask-cisco-vip-troubleshooting-sip-cisco-unified-communications

I have an issue with calling a certain local number. The issue is, we call 1-414-425-7000 from our Milwaukee office, the call flows goes from SCCP phone to CUCM 9.1.2 to CUBE via SIP trunk and out the CUBE to AT&T via SIP. The call is “answered” but its diverted to a “different” voice saying, thank you for calling and promptly disconnects. If we call with our cell phones or house phone, the number is an automatic attendant and it plays the prompts and lets the caller navigate thru the menus.

From watching your presentation I started to look and I noticed they are sending out G729 as default but we are G711 by default and I believe we have our config setup correct on the CUBE to step to G729 if it needs.

I have attached the ccsip messages and voip ccapi inout debugs as well as the config for our cube router. I ran the debug log thru TranslatorX:

Received:

SIP/2.0 200 OKVia: SIP/2.0/UDP 32.252.7.250:5060;branch=z9hG4bK478981390From: "Jim Kozlowski" <sip:4142712400@32.252.7.250>;tag=ECBB3748-65FTo: <sip:14144257000@12.194.131.30>;tag=11422093031507585_c2b06.1.2.1421821008420.0_630388_1283740Call-ID: 2E0B3D42-A6EC11E4-9CBCE235-A94631D5@32.252.7.250CSeq: 101 INVITETimestamp: 1422535804Diversion: <sip:14144257000;phone-context=UnknownUnknown@10.27.35.123;user=phone>;privacy=off;screen=no; reason=unconditionalDiversion: <sip:4257000;phone-context=Test@10.27.35.123;user=phone>;privacy=off;screen=no; reason=unconditionalDiversion: <sip:14144257000;phone-context=UnknownUnknown@10.27.35.123;user=phone>;privacy=off;screen=no; reason=unconditionalSupported: replaces,x-nortel-sipvcAllow: INVITE,ACK,CANCEL,BYE,INFO,PRACKUser-Agent: Nortel CS1000 SIP GW release_7.0 version_ssLinux-7.50.17Server: AVAYA-SM-6.3.4.0.634014Contact: <sip:12.194.131.30:5060;transport=udp>Content-Length: 256Content-Type: application/sdpv=0o=- 848731 1 IN IP4 12.194.131.30s=-c=IN IP4 12.194.131.30t=0 0m=audio 24184 RTP/AVP 0 101 111c=IN IP4 12.194.131.30a=rtpmap:101 telephone-event/8000a=fmtp:101 0-15a=rtpmap:111 X-nt-inforeq/8000a=ptime:20a=maxptime:20a=sendrecv

Source Filename: 4257000.txt

Calling number 4142712400

Called number 14144257000 (we actually just dial 9 for outside and 4257000 since we are in the same area code)

My question is, do you see something wrong that would cause that number to “not work”, although AT&T has reported there is no issue with that number we are calling its working fine. Again, if we call that number from outside the firm, it is working fine. But not for us in our SIP environment.

[Jim Kozlowski]

Here are the 2 files, one is the debug trace and the other is the cube config

[Ayodeji Okanlawon]

Jim,

I have looked at your logs and the ball is firmly in AT and T side. They are disconnecting the call and they are not telling us why,,

Before I get to that I can also see that there are a few anomalies in the way they have implemented their solution..So you need to go back to them in this

When you placed the call, CUBE used the attributes below: codec is G711u..

m=audio 27940 RTP/AVP 0 101

c=IN IP4 32.252.7.250

a=rtpmap:0 PCMU/8000

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-16

a=ptime:20

When AT and T replied and sent a ringing with SDP, codec is also G711u even though they didn’t specify the rtpmap for the codec in their software..(they need to do this)

Received:

SIP/2.0 180 Ringing

Via: SIP/2.0/UDP 32.252.7.250:5060;branch=z9hG4bK478981390From: "Jim Kozlowski" <sip:4142712400@32.252.7.250>;tag=ECBB3748-65F

To: <sip:14144257000@12.194.131.30>;tag=11422093031507585_c2b06.1.2.1421821008420.0_630388_1283740

Call-ID: 2E0B3D42-A6EC11E4-9CBCE235-A94631D5@32.252.7.250

CSeq: 101 INVITETimestamp: 1422535804Session-Expires: 1800Supported: replaces,x-nortel-sipvcAllow: INVITE,ACK,CANCEL,BYE,INFO,PRACK

User-Agent: Nortel CS1000 SIP GW release_7.0 version_ssLinux-7.50.17

Server: AVAYA-SM-6.3.4.0.634014

Contact: <sip:12.194.131.30:5060;transport=udp>

Content-Length: 256Content-Type: application/sdp

v=0

o=- 848731 1 IN IP4 12.194.131.30s=-

c=IN IP4 12.194.131.30

t=0 0

m=audio 24184 RTP/AVP 0 101 111

Here is a potential problem…When they sent the 200OK, they included multiple diversion header. Diversion header is used to forward calls and I don’t know why they are doing this. You need to bring this to their attention. You also need to let them know that when they send a 180 ringing with SDP, the 200 OK with SDP MUST be the same as the 180 ringing. In this case it is not because they have included lots of diversion header in the 200 OK.

Received:

SIP/2.0 200 OK

Via: SIP/2.0/UDP 32.252.7.250:5060;branch=z9hG4bK478981390

From: "Jim Kozlowski" <sip:4142712400@32.252.7.250>;tag=ECBB3748-65F

To: <sip:14144257000@12.194.131.30>;tag=11422093031507585_c2b06.1.2.1421821008420.0_630388_1283740

Call-ID: 2E0B3D42-A6EC11E4-9CBCE235-A94631D5@32.252.7.250

CSeq: 101 INVITE

Timestamp: 1422535804

Diversion: <sip:14144257000;phone-context=UnknownUnknown@10.27.35.123;user=phone>;privacy=off;screen=no; reason=unconditional

Diversion: <sip:4257000;phone-context=Test@10.27.35.123;user=phone>;privacy=off;screen=no; reason=unconditional

Diversion: <sip:14144257000;phone-context=UnknownUnknown@10.27.35.123;user=phone>;privacy=off;screen=no; reason=unconditional

Supported: replaces,x-nortel-sipvcAllow: INVITE,ACK,CANCEL,BYE,INFO,PRACKUser-Agent: Nortel CS1000 SIP GW release_7.0 version_ssLinux-7.50.17

Server: AVAYA-SM-6.3.4.0.634014Contact: <sip:12.194.131.30:5060;transport=udp>Content-Length: 256Content-Type: application/sdpv=0o=- 848731 1 IN IP4 12.194.131.30s=-c=IN IP4 12.194.131.30t=0 0

m=audio 24184 RTP/AVP 0 101 111

c=IN IP4 12.194.131.30

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-15a=rtpmap:111 X-nt-inforeq/8000

a=ptime:20

a=maxptime:20

a=sendrecv

Finally they disconnected the call. So You need to go back and put all this point to them and get them to earn their wages!

[Jim Kozlowski]

Thanks so much Deji for taking time to respond so quickly. I'll go back to AT&T armed with this info. Have a great day!

Was there anything in our setup on the cube config that I could possibly do to address this and put in a work around on our end? We do have a few other issues with AT&T customers calling us when they are on SIP and locked down to g729.

5 stars for you!