CUCM 8.6 Dropped call transfers involving SIP phones

Question

Hi All,
I am a developer who has been tasked with figuring out why call transfers are being dropped by Cisco CUCM when the original call comes from a SIP phone.  This scenario works:
Cisco phone calls another Cisco phone, which transfers the original call to a SIP phone
These scenarios do not work:
SIP phone calls Cisco phone, which transfers the original call to another Cisco phone
SIP phone calls Cisco phone, which transfers the original call to another SIP phone
I have researched the Call Manager traces to the best of my ability, and I see some info in there that could potentially point to the source of the problem.  I am just unable to understand what the trace means:
10:23:08.672 |//SIP/SIPCdpc(1,74,2342)/ci=24377698/ccbId=175645/scbId=0/active_CcDisconnReq: ccDisconnReq.onBehalfOf=Media : ccDisconnReq.s.sv=2 : ccDisconnReq.c.cv=47 |1,100,63,1.93259^10.10.10.85^*
10:23:08.672 |//SIP/Stack/Info/0x0/sipConstructContainerContext #### Created container=0xb0b42f58|1,100,71,1.1^*^*
10:23:08.672 |//SIP/SIPCdpc(1,74,2342)/ci=24377698/ccbId=175645/scbId=0/appendReasonHdr: appendReasonHdr - Invalid Disconnect Cause(cause=47), No Reason Header Appended|1,100,63,1.93259^10.10.10.85^*
10:23:08.672 |//SIP/SIPCdpc(1,74,2342)/ci=24377698/ccbId=175645/scbId=0/appendRPIDHdrForOriginalCalledParty: SIP device does not Support Orig Dialled Phone nego: 0|1,100,63,1.93259^10.10.10.85^*
I have been wondering whether this could be a codec issue, however the SIP phones we are using are configured with the following codecs:
G711U
G711A
G722
ILBC
GSM
and our SIP software is  also set to accept the first codec offered by the remote side.  It seems from the SIP client logs that G722 is being used as the codec to communicate with the Cisco phones, but perhaps I'm misinterpreting.
I have attached a CUCM trace of a call from a SIP phone (ext. 491) to a Cisco handset (ext. 170) where the Cisco handset attempts to transfer the call to another SIP phone (ext. 492).  The trace snippet shown above is from this log.
I would really appreciate it if someone more experienced with VoIP/SIP/CUCM could take a look and offer any ideas on what the issue might be, and also how we might be able to address it.  I can try to provide more info about our CUCM configuration if needed.
Thanks in advance!

Answer 1

Leslie, so here is what I found from the traces....
To understand the difference we need to understand how cucm performs call transfers from a sccp signalling point and a sip signalling point
SCCP
When the transfer key is pressed
1. CUCM sends a CloseReceiveChannel and StopMediaTransmission to the IP phone involved in active media (referenced by the callids)
NB, here CUCM updates the call state on the phone to a call state of 8 which is "Hold"
2.CUCM tells the held party to listen MOH from MOH server
3.CUCM establishes newcall leg with the intended transfered destination..Once this call is connected
4.CUCM receives a new Transfer instruction from the transferring phone to connect the held party
5..CUCM sends a CloseReceiveChannel between the held phone and MOH server (to tear down the media)
6. Next CUCM sends a CloseReceiveChannel and StopMediaTransmission to the transfering party & transfered party to remove Xferring party from call
7. finally CUCM sends OpenReceiveChannel between the original called party and the transfered party..and call is done
For SIP signalling. when the first transfer key is pressed
1. CUCM sends invite (re-invite) with an inactive SDP (a=inactive) to indicate a break in media path
2. CUCM sends a Delayed offer to insert MOH or to resume Media stream
NB: CUCM expects a sendrecv offer with SDP to the DO. (NB:if cucm gets an inactive offer SDP in the 200 OK instead of providing a send-recv offer SDP, the media path remains in an inactive state and causes calls to dropcall will drop),CUCM sends an ACK with sendonly to the 200 OK
3.CUCM establishes newcall leg with the intended transfered destination..Once this call is connected
4.CUCM receives a new Transfer instruction from the transferring phone to connect the held party
5. Next CUCM sends a re-invite with an inactive SDP to indicate a break in media path to MOH (in attempt to complete transfer)
6.Next CUCM sends an inactive SDP to indicate a break in media path between transfering party & transfered party to remove Xferring party from call
7. Next CUCM sends a DO re-invite to connect the transfered party. The far end then sends 200 OK with the required SDP to connect the call
Now having explained all of these, we need to look at where the call is failing for SIP-----SCCP----SIP calls without MTP
lets look at succesful SCCP-----SCCP-----SIP without MTP
Point 4 above
++++++++Extension 170 presses the transfer button to connect the two calls (Callid=24378483)+++++++++++++
(0003395) SoftKeyEvent softKeyEvent=4(Trnsfer) lineInstance=1 callReference=24378483
Point 5 above
++++Next CUCM closed the media between extension 160 and MOH server callid=24378480(this is the only active call on this callid)+++
(0003396) CloseReceiveChannel conferenceID=24378480 passThruPartyID=16777845.  myIP: IpAddr.type:0 ipv4Addr:0x0a0a0a89(10.10.10.137)
Point 6 Above
+++++Next cucm closes the call between extension 170 and 490 callid=(24378483)++++++++
(0003395) CloseReceiveChannel conferenceID=24378483 passThruPartyID=16777847.  myIP: IpAddr.type:0 ipv4Addr:0x0a0a0a8b(10.10.10.139)
(0003395) StopMediaTransmission conferenceID=24378483 passThruPartyID=16777847.  myIP: IpAddr.type:0 ipv4Addr:0x0a0a0a8b(10.10.10.139)
Point 6 above for the sip side (since the destination is SIP, to tear down media to SCCP phone, so as to connect the caller to the xfered party)
+++++++Next CUCM sends a re-invite with a=inactive SDP to the sip phone ++++++++++++
//SIP/SIPTcp/wait_SdlSPISignal: Outgoing SIP TCP message to 10.10.10.104 on port 62220 index 1890
[885626,NET]
INVITE sip:[email protected]:62220;transport=tcp SIP/2.0
Via: SIP/2.0/TCP 10.10.10.195:5060;branch=z9hG4bK23332dbee978
From: ;tag=192115~d8e94532-127d-4dca-bba0-64b1675da032-24378484
o=CiscoSystemsCCM-SIP 192115 2 IN IP4 10.10.10.195
s=SIP Call
c=IN IP4 0.0.0.0
m=audio 24560 RTP/AVP 9 101
a=rtpmap:9 G722/8000
a=ptime:20
a=inactive-----------------------------------------------------Inactive
Still part of Point 6 for SIP signalling
++++++++++++Next sip phone responds with a 200 OK recevonly SDP +++++++++++++++++++
//SIP/SIPTcp/wait_SdlReadRsp: Incoming SIP TCP message from 10.10.10.104 on port 62220 index 1890 with 683 bytes:
[885628,NET]
SIP/2.0 200 OK
v=0
o=- 18077 11099 IN IP4 10.10.10.104
s=yasdjip
c=IN IP4 10.10.10.104
t=0 0
a=ptime:20
a=recvonly-------------------------------------a=recvonly
Finally Point 7 above..
+++++++++++++=Next cucm sends a DO re-invite to extension 492-sip phone++++++++++
//SIP/SIPTcp/wait_SdlSPISignal: Outgoing SIP TCP message to 10.10.10.104 on port 62220 index 1890
[885630,NET]
INVITE sip:[email protected]:62220;transport=tcp SIP/2.0
Via: SIP/2.0/TCP 10.10.10.195:5060;branch=z9hG4bK233534ffec4a
From: ;tag=192115~d8e94532-127d-4dca-bba0-64b1675da032-24378484
To: ;tag=5B0E9816C2CA6D70F3166FB972EDE4C2
+++++++Next we get a 200 OK from sip phone with sdp=sendrecv+++++++++=
/SIP/SIPTcp/wait_SdlReadRsp: Incoming SIP TCP message from 10.10.10.104 on port 62220 index 1890 with 683 bytes:
[885634,NET]
SIP/2.0 200 OK
Via: SIP/2.0/TCP 10.10.10.195:5060;branch=z9hG4bK233534ffec4a
Contact:
From: ;tag=192115~d8e94532-127d-4dca-bba0-64b1675da032-24378484
Call-ID: [email protected]
v=0
o=- 18077 11099 IN IP4 10.10.10.104
s=yasdjip
c=IN IP4 10.10.10.104
t=0 0
m=audio 16574 RTP/AVP 9 101
a=rtpmap:101 TELEPHONE-EVENT/8000
a=fmtp:101 0-15
a=ptime:20
a=sendrecv
+Now CUCM sends an OpenReceiveChannel and start media xmission to sccp phone (callid=24378480) with media parameters of sip phone++++++
(0003396) OpenReceiveChannel conferenceID=24378480 passThruPartyID=16777848 millisecondPacketSize=20 compressionType=6(Media_Payload_G722_64k) RFC2833PayloadType=101 qualifierIn=? sourceIpAddr=IpAddr.type:0 ipAddr:0x0a0a0a68000000000000000000000000(10.10.10.104). myIP: IpAddr.type:0 ipv4Addr:0x0a0a0a89(10.10.10.137)
(0003396) startMediaTransmission conferenceID=24378480 passThruPartyID=16777848 remoteIpAddress=IpAddr.type:0 ipAddr:0x0a0a0a68000000000000000000000000(10.10.10.104)
remotePortNumber=16574 milliSecondPacketSize=20 compressType=6(Media_Payload_G722_64k) RFC2833PayloadType=101 qualifierOut=?. myIP: IpAddr.type:0 ipv4Addr:0x0a0a0a89(10.10.10.137)
+++++++++++=Next Phone sends its ACK+++++++++++++++
(0003396) OpenReceiveChannelAck Status=0, IpAddr=IpAddr.type:0 ipAddr:0x0a0a0a89000000000000000000000000(10.10.10.137), Port=20352, PartyID=16777848
+++++++++++=Next CUCM sends ACK to 200 OK from SIP Phone+++++++++++
//SIP/SIPTcp/wait_SdlSPISignal: Outgoing SIP TCP message to 10.10.10.104 on port 62220 index 1890
[885635,NET]
ACK sip:[email protected]:62220;transport=tcp SIP/2.0
Via: SIP/2.0/TCP 10.10.10.195:5060;branch=z9hG4bK23366067b8c0
From: ;tag=192115~d8e94532-127d-4dca-bba0-64b1675da032-24378484
To: ;tag=5B0E9816C2CA6D70F3166FB972EDE4C2
Date: Tue, 19 Feb 2013 21:44:45 GMT
Call-ID: [email protected]
Max-Forwards: 70
CSeq: 103 ACK
Allow-Events: presence
Content-Type: application/sdp
Content-Length: 237
v=0
o=CiscoSystemsCCM-SIP 192115 3 IN IP4 10.10.10.195
s=SIP Call
c=IN IP4 10.10.10.137
b=TIAS:64000
b=AS:64
t=0 0
m=audio 20352 RTP/AVP 9 101
a=rtpmap:9 G722/8000
a=ptime:20
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
Now at this point all is well...and the call is connected....
Now here is where the call is failing on the SIP-SCCP-SIP call without MTP
From Point 2 above, CUCM sends a DO to insert MOH, and then gets response, then sends an ACK to 200 Ok back to SIP Phone..
//SIP/SIPTcp/wait_SdlSPISignal: Outgoing SIP TCP message to 10.10.10.104 on port 53361 index 1810
[881160,NET]
ACK sip:[email protected]:53361;transport=tcp SIP/2.0
Via: SIP/2.0/TCP 10.10.10.195:5060;branch=z9hG4bK22035ecc1fcb
From: ;tag=190666~d8e94532-127d-4dca-bba0-64b1675da032-24378214
To: "492" ;tag=97C34E1FB9A11F83DD8D8F5BA4C87C57
Date: Tue, 19 Feb 2013 17:38:50 GMT
Call-ID: 1CCA5149B966DC89AE0F752B8EF86480BC7102DB
Max-Forwards: 70
CSeq: 102 ACK
o=CiscoSystemsCCM-SIP 190666 3 IN IP4 10.10.10.195
s=SIP Call
c=IN IP4 10.10.10.195---------------------------------------IP address of MOH server
t=0 0
m=audio 4000 RTP/AVP 0--------------------------------MOH port 4000
a=rtpmap:0 PCMU/8000
a=ptime:20
a=sendonly---------------------------------------------------------sendonly
+++++NOW Point 6 above (SIP) CUCM sends a=inactive to break media path to MOH server to connect caller and xfered party++++++
//SIP/SIPTcp/wait_SdlSPISignal: Outgoing SIP TCP message to 10.10.10.104 on port 53361 index 1810
[881161,NET]
INVITE sip:[email protected]:53361;transport=tcp SIP/2.0
Via: SIP/2.0/TCP 10.10.10.195:5060;branch=z9hG4bK22045bb7f918
From: ;tag=190666~d8e94532-127d-4dca-bba0-64b1675da032-24378214
To: "492" ;tag=97C34E1FB9A11F83DD8D8F5BA4C87C57
Date: Tue, 19 Feb 2013 17:39:04 GMT
Call-ID: 1CCA5149B966DC89AE0F752B8EF86480BC7102DB
Supported: timer,resource-priority,replaces
Min-SE:  1800
User-Agent: Cisco-CUCM8.6
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY
CSeq: 103 INVITE
Max-Forwards: 70
Expires: 180
Allow-Events: presence
Remote-Party-ID: ;party=calling;screen=yes;privacy=off
Contact:
Content-Type: application/sdp
Content-Length: 164
v=0
o=CiscoSystemsCCM-SIP 190666 4 IN IP4 10.10.10.195
s=SIP Call
c=IN IP4 0.0.0.0--------------------------------------------------------------------Media IP is 0.0.0.0
t=0 0
m=audio 4000 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=ptime:20
a=inactive---------------------------------------------------------------------media inactive
At this point, we should get a response back from the sip phone...
and here is what we got..
++Trying which is expected++++
//SIP/SIPTcp/wait_SdlReadRsp: Incoming SIP TCP message from 10.10.10.104 on port 53361 index 1810 with 331 bytes:
[881162,NET]
SIP/2.0 100 Trying
Via: SIP/2.0/TCP 10.10.10.195:5060;branch=z9hG4bK22045bb7f918
From: ;tag=190666~d8e94532-127d-4dca-bba0-64b1675da032-24378214
Call-ID: 1CCA5149B966DC89AE0F752B8EF86480BC7102DB
CSeq: 103 INVITE
To: "492" ;tag=97C34E1FB9A11F83DD8D8F5BA4C87C57
Content-Length: 0
++++++++Then we get a BYE+++++++++++++++
/SIP/SIPTcp/wait_SdlReadRsp: Incoming SIP TCP message from 10.10.10.104 on port 53361 index 1810 with 576 bytes:
[881163,NET]
BYE sip:[email protected]:5060;transport=tcp SIP/2.0
Via: SIP/2.0/TCP 10.10.10.104:53361;branch=z9hG4bKa2vdQvR7J9OiMyjU;rport
Contact:
Max-Forwards: 70
From: "492" ;tag=97C34E1FB9A11F83DD8D8F5BA4C87C57
Allow: OPTIONS, INVITE, ACK, REFER, CANCEL, BYE, NOTIFY
Supported: replaces, path
User-Agent: Acrobits Softphone Business/2.4.8
To: ;tag=190666~d8e94532-127d-4dca-bba0-64b1675da032-24378214
Call-ID: 1CCA5149B966DC89AE0F752B8EF86480BC7102DB
CSeq: 3 BYE
Content-Length: 0
So this is the root cause of the problem. Your SIP phone does not know how to respond to multiple media break between it and the MOH server.
The difference between this and the succesful SCCP-SIP--SCCP, is that the held party was a sccp phone, hence the sip phone only has to process one a=inactive SDP message, where as in the SIP-SCCP-SIP, the help party was sip, so the sip phone has to process two a=inactive SDP messages
Now what is the difference when MTP is involved! A Big difference. MTP stays in the media path. So there is never a break in media and no inactive SDP attribute is sent. The flow looks like below:
for the initial call...The SIP phone sends its media to MTP and likewise the SCCP phone
SIP------Media------MTP------------Media-------SCCP Phone
When the new destination is dialled and transfer is commited,
SIP-------------media----MTP--------media---------MTP
The final invoite sent to connect 492 and 491 has MTP as the IP address to connect Media to.
++++++++Ivite to 492 ++++++++++++++
INVITE sip:[email protected]:61303;transport=tcp SIP/2.0
Via: SIP/2.0/TCP 10.10.10.195:5060;branch=z9hG4bK231a3b24b862
From: ;tag=192048~d8e94532-127d-4dca-bba0-64b1675da032-24378472
To: ;tag=78FF5BF6C019A55EA020B69BB6A767E2
Date: Tue, 19 Feb 2013 21:24:59 GMT
Call-ID: [email protected]
Supported: timer,resource-priority,replaces
Min-SE:  1800
User-Agent: Cisco-CUCM8.6
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY
CSeq: 102 INVITE
Max-Forwards: 70
Expires: 180
Allow-Events: presence
Remote-Party-ID: ;party=calling;screen=yes;privacy=off
Contact:
Content-Type: application/sdp
Content-Length: 214
v=0
o=CiscoSystemsCCM-SIP 192048 1 IN IP4 10.10.10.195
s=SIP Call
c=IN IP4 10.10.10.195---------------------------------------------------------------the MTP ip address
t=0 0
m=audio 25038 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=ptime:20
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
+++++++Invite to 491 +++++++++++++++++
//SIP/SIPTcp/wait_SdlSPISignal: Outgoing SIP TCP message to 10.10.10.94 on port 50376 index 1887
[885429,NET]
INVITE sip:[email protected]:50376;transport=tcp SIP/2.0
Via: SIP/2.0/TCP 10.10.10.195:5060;branch=z9hG4bK231b78d1b56
From: ;tag=192046~d8e94532-127d-4dca-bba0-64b1675da032-24378467
To: "491" ;tag=F13CE94DE942C47680356A647DC7F916
Date: Tue, 19 Feb 2013 21:24:59 GMT
Call-ID: AE7045FFB2D8D9C28D54651473A14A5D41B5B93C
Supported: timer,resource-priority,replaces
Min-SE:  1800
User-Agent: Cisco-CUCM8.6
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY
CSeq: 101 INVITE
Max-Forwards: 70
Expires: 180
Allow-Events: presence
Remote-Party-ID: "Leslie2" ;party=calling;screen=no;privacy=off
Contact:
Content-Type: application/sdp
Content-Length: 237
v=0
o=CiscoSystemsCCM-SIP 192046 1 IN IP4 10.10.10.195
s=SIP Call
c=IN IP4 10.10.10.195----------------------------------------MTP
b=TIAS:64000
b=AS:64
t=0 0
m=audio 25030 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=ptime:20
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
Wao! That was a long one isnt it...It was fun too.
So now you can look at your sip phones and see if they can accept two inactive sdp messages within the same call. That way you can remove MTP. otherwise you will have MTP involved in every single call involving a sip phone, even if they do not involve transfers
Please rate all useful posts
"opportunity is a haughty goddess who waste no time with those who are unprepared"