Solved: CUCM 8.6 Dropped call transfers involving SIP phones - Page 2

lesliemcgann · ‎02-16-2013

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!

lesliemcgann · ‎02-20-2013

Trying PDF attachments...

Ayodeji Okanlawon · ‎02-20-2013

Thanks I got them. Will update you.

Please rate all useful posts

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

Please rate all useful posts

Ayodeji Okanlawon · ‎02-21-2013

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:492@10.10.10.104:62220;transport=tcp SIP/2.0
Via: SIP/2.0/TCP 10.10.10.195:5060;branch=z9hG4bK23332dbee978
From: <170>;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:492@10.10.10.104:62220;transport=tcp SIP/2.0
Via: SIP/2.0/TCP 10.10.10.195:5060;branch=z9hG4bK233534ffec4a
From: <170>;tag=192115~d8e94532-127d-4dca-bba0-64b1675da032-24378484
To: <492>;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: <492>
From: <170>;tag=192115~d8e94532-127d-4dca-bba0-64b1675da032-24378484
Call-ID: 8738f500-1231f23b-1dc6-c30a0a0a@10.10.10.195
---
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:492@10.10.10.104:62220;transport=tcp SIP/2.0
Via: SIP/2.0/TCP 10.10.10.195:5060;branch=z9hG4bK23366067b8c0
From: <170>;tag=192115~d8e94532-127d-4dca-bba0-64b1675da032-24378484
To: <492>;tag=5B0E9816C2CA6D70F3166FB972EDE4C2
Date: Tue, 19 Feb 2013 21:44:45 GMT
Call-ID: 8738f500-1231f23b-1dc6-c30a0a0a@10.10.10.195
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:492@10.10.10.104:53361;transport=tcp SIP/2.0
Via: SIP/2.0/TCP 10.10.10.195:5060;branch=z9hG4bK22035ecc1fcb
From: <170>;tag=190666~d8e94532-127d-4dca-bba0-64b1675da032-24378214
To: "492" <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:492@10.10.10.104:53361;transport=tcp SIP/2.0
Via: SIP/2.0/TCP 10.10.10.195:5060;branch=z9hG4bK22045bb7f918
From: <170>;tag=190666~d8e94532-127d-4dca-bba0-64b1675da032-24378214
To: "492" <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: <170>;party=calling;screen=yes;privacy=off
Contact: <492>
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: <170>;tag=190666~d8e94532-127d-4dca-bba0-64b1675da032-24378214

Call-ID: 1CCA5149B966DC89AE0F752B8EF86480BC7102DB

CSeq: 103 INVITE

To: "492" <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:170@10.10.10.195:5060;transport=tcp SIP/2.0
Via: SIP/2.0/TCP 10.10.10.104:53361;branch=z9hG4bKa2vdQvR7J9OiMyjU;rport
Contact: <492>
Max-Forwards: 70
From: "492" <492>;tag=97C34E1FB9A11F83DD8D8F5BA4C87C57
Allow: OPTIONS, INVITE, ACK, REFER, CANCEL, BYE, NOTIFY
Supported: replaces, path
User-Agent: Acrobits Softphone Business/2.4.8
To: <170>;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:492@10.10.10.104:61303;transport=tcp SIP/2.0
Via: SIP/2.0/TCP 10.10.10.195:5060;branch=z9hG4bK231a3b24b862
From: <170>;tag=192048~d8e94532-127d-4dca-bba0-64b1675da032-24378472
To: <492>;tag=78FF5BF6C019A55EA020B69BB6A767E2
Date: Tue, 19 Feb 2013 21:24:59 GMT
Call-ID: ca459900-1231eda3-1db9-c30a0a0a@10.10.10.195
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: <491>;party=calling;screen=yes;privacy=off
Contact: <170>
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:491@10.10.10.94:50376;transport=tcp SIP/2.0
Via: SIP/2.0/TCP 10.10.10.195:5060;branch=z9hG4bK231b78d1b56
From: <170>;tag=192046~d8e94532-127d-4dca-bba0-64b1675da032-24378467
To: "491" <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" <492>;party=calling;screen=no;privacy=off
Contact: <491>
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"

Please rate all useful posts

lesliemcgann · ‎02-21-2013

Hi aokanlawon,

Thank you so much for your detailed analysis of all the traces and clear explanation of the likely problem. Also, I have learned a lot from you about interpreting the Cisco trace files!

We will investigate what you suggested, whether the SIP software can be made to accept two inactive SDP messages within the same call. It does sound like the second one is being misinterpreted by SIP as the end of the call instead of ending MoH and being transferred to another party.

I will post back as soon as I have more info.

Ayodeji Okanlawon · ‎02-21-2013

Its my pleasure..we learn along the way, otherwise we have no business been in this field. You are most certainly correct. The SIP phone is treating the second inactive attribute as the end of the call.

Please rate all useful posts

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

Please rate all useful posts

Mark Anthony Pagulayan · ‎08-26-2013

Hello,

I am in the same boat as you guys are and I was wondering if you have come up of a solution that does not require MTP for all SIP calls. Please do let me know.

Regards,

Mark

lesliemcgann · ‎08-27-2013

Hi Mark,

There were two solutions to the problem that each worked for us (not involving MTP):

1) Correct the SIP software, allowing it to accept two inactive SDP messages within a call.

2) Set up a SIP trunk into Cisco such that a different PBX is handling the SIP clients' legs of each call and interfacing with the Cisco PBX on their behalf.

Good luck,

Leslie

shohamshalom · ‎08-28-2013

hi leslie

i have the same issue allso.....

what did u mean in line 2 ?

"Set up a SIP trunk into Cisco such that a different PBX is handling the SIP clients' legs of each call and interfacing with the Cisco PBX on their behalf."

transfer between internal devices ,do not need sip trunk ...

please explain, i m stuck here.....

tk

shoham

Julien Munar · ‎10-09-2013

Hi aokanlawon, after seen your interesting explanation, I would like to get your advise about the same kind of issue I get.

Basically, I'm doing a call cisco to a third party environment.

this is what I get..

14:46:50.091 |//SIP/SIPCdpc(3,74,281707)/ci=144600614/ccbId=35257792/scbId=0/getXCiscoViPRFallbackIDAndDTMFKey: Device type 8, Pstn Fallback is not enabled|3,100,63,1.36454459^192.168.0.15^*

14:46:50.091 |//SIP/SIPCdpc(3,74,281707)/ci=144600614/ccbId=35257792/scbId=0/getDefCcRegister: Secure status=1, mSrtpPresent=0|3,100,63,1.36454459^192.168.0.15^*

14:46:50.091 |//SIP/SIPCdpc(3,74,281707)/ci=144600614/ccbId=35257792/scbId=0/compareAndUpdateMedia: sdpStatus=0, CMEndPointSDP role=1, SIPEndPointSdpRole=2|3,100,63,1.36454459^192.168.0.15^*

14:46:50.091 |//SIP/SIPCdpc(3,74,281707)/ci=144600614/ccbId=35257792/scbId=0/getDefCcRegister: Secure status=1, mSrtpPresent=0|3,100,63,1.36454459^192.168.0.15^*

14:46:50.091 |//SIP/SIPCdpc(3,74,281707)/ci=144600614/ccbId=35257792/scbId=0/handleSIPUACSessionExpires: isMidCall[0], response[200], method[102]|3,100,63,1.36454459^192.168.0.15^*

14:46:50.091 |//SIP/SIPCdpc(3,74,281707)/ci=144600614/ccbId=35257792/scbId=0/parseSessionExpires: refresh_interval[1800], refresher[uas]|3,100,63,1.36454459^192.168.0.15^*

14:46:50.091 |//SIP/SIPCdpc(3,74,281707)/ci=144600614/ccbId=35257792/scbId=0/setSIPSessionExpiresTimer: interval[1768] secs|3,100,63,1.36454459^192.168.0.15^*

14:46:50.091 |//SIP/SIPCdpc(3,74,281707)/ci=144600614/ccbId=35257792/scbId=0/handleSecureRec: enforce srtp flag: 0, remote end srtp support: 0|3,100,63,1.36454459^192.168.0.15^*

14:46:50.091 |//SIP/SIPCdpc(3,74,281707)/ci=144600614/ccbId=35257792/scbId=0/updateCNToCC: identityCngFlag[0x1f], isConnInfoInd[1], ccContactHeader[]|3,100,63,1.36454459^192.168.0.15^*

14:46:50.091 |//SIP/SIPCdpc(3,74,281707)/ci=144600614/ccbId=35257792/scbId=0/handleSIPConnectInd: Exit with state = outCall_200Rcvd|3,100,63,1.36454459^192.168.0.15^*

14:46:50.091 |//SIP/SIPCdpc(3,74,281707)/ci=144600614/ccbId=35257792/scbId=0/setSIPUpdateFlags: mIsUpdateForSignalingAllowed = 1 mIsUpdateForMediaAllowed = 1 mPendingOutgoingUpdate = 0|3,100,63,1.36454459^192.168.0.15^*

14:46:50.098 |//SIP/SIPCdpc(3,74,281707)/ci=144600614/ccbId=35257792/scbId=0/appendReasonHdr: appendReasonHdr - Invalid Disconnect Cause(cause=47), No Reason Header Appended|3,100,63,1.36454459^192.168.0.15^*

14:46:50.098 |//SIP/SIPCdpc(3,74,281707)/ci=144600614/ccbId=35257792/scbId=0/addTransparencyInfo: attaching transparency object|3,100,63,1.36454459^192.168.0.15^*

14:46:50.098 |//SIP/SIPCdpc(3,74,281707)/ci=144600614/ccbId=35257792/scbId=0/appendRPIDHdrForOriginalCalledParty: SIP device does not Support Orig Dialled Phone nego: 0|3,100,63,1.36454459^192.168.0.15^*

14:46:50.098 |//SIP/SIPCdpc(3,74,281707)/ci=144600614/ccbId=35257792/scbId=0/getDefAe: SIPCdpc=281707, nodeId=3, processNumber=73 ci=144600614, branch=0|3,100,63,1.36454459^192.168.0.15^*

14:46:50.098 |MRM::waiting_MrmDeallocateMtpResourceReq- Deallocate received for CI=53993831 count=0|3,100,63,1.36454459^192.168.0.15^*

14:46:50.098 |MRM::waiting_DeallocateMtpResourceReq- ERROR Deallocate received for an unknown Call Identifier Ci = 53993831|3,100,63,1.36454459^192.168.0.15^*

14:46:50.098 |//SIP/SIPHandler/ccbId=0/scbId=0/sip_stop_timer: type=SIP_TIMER_DISCONNECT value=500 retries=10|3,100,63,1.36454459^192.168.0.15^*

14:46:50.098 |//SIP/SIPHandler/ccbId=0/scbId=0/sip_start_timer: type=SIP_TIMER_DISCONNECT value=500 retries=10|3,100,63,1.36454459^192.168.0.15^*

14:46:50.098 |//SIP/SIPUdp/wait_SdlSPISignal: Outgoing SIP UDP message to 192.168.0.15:[5060]:

I've no idea about the root cause...

Ayodeji Okanlawon · ‎10-09-2013

Can you please open another thread. Describe your call flow and the problems you are having. Attach the full CUCM trace including the called and calling number as well as the time of call..

Please rate all useful posts

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

Please rate all useful posts

Julien Munar · ‎10-09-2013

Hello, it's created.

Ayodeji Okanlawon · ‎08-28-2013

Leslie, really glad that my suggestions worked for you. That confirmed that your sip client wasnt interpreting the inactive state properly..Great job getting it corrected..

Please rate all useful posts

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

Please rate all useful posts

lesliemcgann · ‎08-28-2013

Yes, you were absolutely right. Thank you again for all the help!!