Call transfer fails to a specific TFN "Cannot complete transfer"

[rajasekarvs]

Hi - We are running CUCM 8.5.1 SU4, CUBE 2821 runing 15.1(4) M4, with a SIP trunk from Windstream. There`s one specific TFN for which the call fails if attempted transfer to that number. But the same TFN is working fine if called directly. That`s an IVR. When I happen to check the traces , it looks like the CUCM is sending the "BYE" ,exactly after 13 secs with the SIP disconnect cause code "86". (Indicates that the network has received a call identity information  element indicating a suspended call that has in the meantime been  cleared wile suspended ). Not sure what`s happening to this specific number. While investigating the same ,would want to get this out to the forum to check if somebody could have experienced something similar to this.

Attached the logs from both CUCM & CUBE for reference.

Calling #: 8889 / 9017

Called # : 8663637484

[Ayodeji Okanlawon]

Hi,

I looked at the traces you provided. I hope i am looking at the right traces because the calling number from CUCM is 9017 and the called number is...18663637484

From the logs we can see what is going on.....When cucm sends an UPDATE to the CUBE to inform it that the call is now on hold (during the xfer)....Everything broke from here...

+++++CUCM sends an UPDATE to CUBE at 15.15.06+++++

02/12/2013 15:15:06.904 |//SIP/SIPUdp/wait_SdlSPISignal: Outgoing SIP UDP message to 172.16.11.253:[5060]:
[210402,NET]
UPDATE sip:18663637484@172.16.11.253:5060 SIP/2.0
Via: SIP/2.0/UDP 172.16.11.106:5060;branch=z9hG4bK1298d41f4d13d
From: "David Finnegan" <9017>;tag=33851~9f9510a5-f370-4baa-9673-0ddf163429ab-81432224
To: <18663637484>;tag=8E81BEB0-1209
Date: Tue, 12 Feb 2013 20:15:03 GMT
Call-ID: e1234300-11a1a2c7-14c0-6a0b10ac@172.16.11.106
User-Agent: Cisco-CUCM8.5
Max-Forwards: 70
Supported: 100rel,timer,resource-priority,replaces
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY
CSeq: 104 UPDATE
Call-Info: <172.16.11.106:5060>;method="NOTIFY;Event=telephone-event;Duration=500"
Supported: X-cisco-srtp-fallback
Supported: Geolocation
P-Asserted-Identity: "David Finnegan" <9017>
Remote-Party-ID: "David Finnegan" <9017>;party=calling;screen=yes;privacy=off
Contact: <9017>
Content-Type: application/sdp
Content-Length: 220

v=0
o=CiscoSystemsCCM-SIP 2000 2 IN IP4 172.16.11.106
s=SIP Call
c=IN IP4 0.0.0.0

++++++++++ Almost 1 minute after CUCM sends the update, it sends a BYE because it never got an ACK back

for the update+++++++++++++++++

02/12/2013 15:16:05.104 |//SIP/SIPUdp/wait_SdlSPISignal: Outgoing SIP UDP message to 172.16.11.253:[5060]:

[210472,NET]

BYE sip:18663637484@172.16.11.253:5060 SIP/2.0

Via: SIP/2.0/UDP 172.16.11.106:5060;branch=z9hG4bK129a95403fc3b

From: "David Finnegan" <9017>;tag=33851~9f9510a5-f370-4baa-9673-0ddf163429ab-81432224

To: <18663637484>;tag=8E81BEB0-1209

Date: Tue, 12 Feb 2013 20:15:03 GMT

Call-ID:

e1234300-11a1a2c7-14c0-6a0b10ac@172.16.11.106

User-Agent: Cisco-CUCM8.5

Max-Forwards: 70

P-Asserted-Identity: "David Finnegan" <9017>

CSeq: 105 BYE

Reason: Q.850;cause=47

Content-Length: 0

+++++After the CUCM has disconnected the call the CUBE sends an ACK to the update almost 1 minute after the original UPDATE, and reports internal server error++++++++++++++==

02/12/2013 15:16:05.123 |//SIP/SIPUdp/wait_UdpDataInd: Incoming SIP UDP message size 458 from 172.16.11.253:[59817]:

[210473,NET]

SIP/2.0 500 Internal Server Error

Via: SIP/2.0/UDP 172.16.11.106:5060;branch=z9hG4bK1298d41f4d13d

From: "David Finnegan" <9017>;tag=33851~9f9510a5-f370-4baa-9673-0ddf163429ab-81432224

To: <18663637484>;tag=8E81BEB0-1209

Date: Tue, 12 Feb 2013 20:16:05 GMT

Call-ID:

e1234300-11a1a2c7-14c0-6a0b10ac@172.16.11.106

Server: Cisco-SIPGateway/IOS-12.x

CSeq: 104 UPDATE

Allow-Events: telephone-event

Now inbetween that the CUBE tries to send a 200 OK 4 times to CUCM, to which it didnt get an ACK back until about 7s later.

The question is whats going on with the UPDATE....To find out I will suggest you disable PRACK (SEP Rel1XX Options)

Test again and send the logs.

Please rate all useful posts

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

[rajasekarvs]

Hi - Thanks for your reply. I was able to resolve this issue by checking the MTP required option on the SIP trunk to CUBE.

Though, Cisco claims that the MTP would be used on demand & there`s no need to check “MTP required” check box for the versions 5.x & above ,it doesn`t seem to be the case.

I`m yet to compare the logs between the working & not working logs.. Attached the logs after the MTP check on. Please let me know ,if I`m missing anything.

Raj

[Ayodeji Okanlawon]

You have not attached any logs. And Yes I am 100% sure MTP will resolve the issue. The MTP that is invoked dynamically is not in this scenario because CUCM does not think that the call requires an MTP.

Please rate all useful posts

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

[rajasekarvs]

Attachment

[Ayodeji Okanlawon]

Do you have the CUBE logs too?

Please rate all useful posts

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

[Ayodeji Okanlawon]

Raj,

I have looked at the logs and I dont think this the correct logs. The logs in here show unsuccesful calls with a lot of 487 Cancel messages. Please do another test call..send both CUCM and CUBE logs. Please include the time of call

[rajasekarvs]

Sorry, I figured that. Attached the correct logs.

Calling number : 9016

Called number : 8663637484

Transfer Number : 9017

I don`t have the CUBE logs this time, though.

Raj

[Ayodeji Okanlawon]

Raj,

You have sent me the same logs as the previous one. Please send the correct logs

Please rate all useful posts

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