Unity Connection System Call Handlers ring extension but hangs up upon pickup

[Chadster766]

Unity Connection System Call Handlers ring extension but hangs up upon pickup.

So far Cisco tech support hasn't been able to figure this one out. The Unity system is the 10.5 version.

[Deepak Mehta]

Sounds like codec negotiation issue.

Can you confirm how it is set up SCCP or SIP integration and what is the call flow and phone type.

You can try adding a trasncoder in either to trunk or Port whichever thing you have set up between CUCM and Unity.

[Chadster766]

CUC Port Group settings:

CUCM SIP Trunk to CUC

Cisco phones are 7861 and 7841's.

[Chadster766]

CUCM CTI Route Point for CUC Call Handler 5400:

[Deepak Mehta]

Thanks,so it is SIP integration .

Few things you can try , Either add a transcoder to the Device pool of trunk to overcome any codec issue Or  create a audio codec preference list with g711 highest priority for region between the trunk and phone.sometimes phone can also try to negotiate g722 as well at times which is not supported by unity.

If nothing works then attach CCM trace to see what exactly is going on .thanks

[Chadster766]

Attached is the CCM Trace.

Process used:

1. Ext 1028 calls Vidir call handler 5400
2. User presses key 2 which trigger caller input to "Call Action" "Transfer to alternate contact number" Ext 1000 with supervised transfer and 4 rings
3. Ext 1000 rings
4. User picks up receiver and the call is immediately dropped

*Ext 5600 is the Opening Greeting or CUC itself.

[Deepak Mehta]

 Whille transfferng the call to phone 2- 1000, we see that unity sends a re invite  to  CUCM with attribute inactive and contact ip address as 0.0.0.0 .CUCM sends invite (re-invite) to the phone 1 -1028 with an inactive SDP (a=inactive) to indicate a break in media path.

Later we see that call gets connected to 1000 extersion and CUCM sends  200 ok to unity with codec g711 and phone ip address (172.27.199.116)

Call-ID: 911d6e3ade06426faa10ca9cae34a889@ucm-pub.ciscolocal.com
CSeq: 200 INVITE
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY
Allow-Events: presence, kpml
Supported: replaces
Server: Cisco-CUCM10.5
Call-Info: <urn:x-cisco-remotecc:callinfo>;x-cisco-video-traffic-class=DESKTOP
Supported: X-cisco-srtp-fallback
Supported: Geolocation
P-Asserted-Identity: <sip:1000@172.27.199.11>
Remote-Party-ID: <sip:1000@172.27.199.11>;party=called;screen=yes;privacy=off
Contact: <sip:1000@172.27.199.11:5060;transport=tcp>
Content-Type: application/sdp
Content-Length: 226
v=0
o=CiscoSystemsCCM-SIP 7571 1 IN IP4 172.27.199.11
s=SIP Call
c=IN IP4 172.27.199.116>>>>>>>>>>>>>>>>>>>>>
b=TIAS:64000
b=AS:64
t=0 0
m=audio 18040 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000>>>>>>>>>>>>>>>>
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15

Till now it okay....later we can see CUCM sends reinvites to the phone -1028 to join the extension 1000 and phone responds with send-receive attribute.

================================================

00139312.002 |12:55:18.716 |AppInfo |SIPTcp - wait_SdlReadRsp: Incoming SIP TCP message from 172.27.199.115 on port 49368 index 13 with 1388 bytes:
[22866,NET]
SIP/2.0 200 OK
Via: SIP/2.0/TCP 172.27.199.11:5060;branch=z9hG4bKa0f5d15a0bf
From: <sip:5@172.27.199.11>;tag=7564~1c99d99b-4d8e-200c-ed64-5eee938b17f2-23803484
To: "1028" <sip:1028@172.27.199.11>;tag=dccec1d47e9106e973dbf846-1037814d
Call-ID: dccec1d4-7e91004f-4962229c-63785fab@172.27.199.115
Date: Fri, 10 Jun 2016 17:55:22 GMT
CSeq: 105 INVITE
Server: Cisco-CP7841/10.3.1
Contact: <sip:c724c7d7-2935-9ea4-2d54-e5f25c8e0bf8@172.27.199.115:49368;transport=tcp>
Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,OPTIONS,REFER,REGISTER,UPDATE,SUBSCRIBE,INFO
Remote-Party-ID: "1028" <sip:1028@172.27.199.11>;party=calling;id-type=subscriber;privacy=off;screen=yes
Supported: replaces,join,sdp-anat,norefersub,resource-priority,extended-refer,X-cisco-callinfo,X-cisco-serviceuri,X-cisco-escapecodes,X-cisco-service-control,X-cisco-srtp-fallback,X-cisco-monrec,X-cisco-config,X-cisco-sis-7.0.0,X-cisco-xsi-8.5.1
Allow-Events: kpml,dialog
Content-Length: 353
Content-Type: application/sdp
Content-Disposition: session;handling=optional
v=0
o=Cisco-SIPUA 12756 2 IN IP4 172.27.199.115
s=SIP Call
t=0 0
m=audio 31834 RTP/AVP 9 0 8 116 18 101
c=IN IP4 172.27.199.115
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:116 iLBC/8000
a=fmtp:116 mode=20
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=yes
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

+++++++++++++++++++++++++++++++++++++++++

After this point we see CUCM sending reinvite to unity to connect reestablish the media with phone 1

however CUCM receives m-inactive still from the untiy

SIP/2.0 200 OK
From: <sip:1028@172.27.199.11>;tag=7566~1c99d99b-4d8e-200c-ed64-5eee938b17f2-23803487
To: <sip:5600@ucn1.ciscolocal.com>;tag=11abbc7433ca4847a3467651437bf379
Via: SIP/2.0/TCP 172.27.199.11:5060;branch=z9hG4bKa0e6f23e795
Contact: <sip:5600@172.27.199.12:5060;transport=tcp>
Expires: 180
Call-ID: 7932c580-75a1ff00-749-bc71bac@172.27.199.11
CSeq: 106 INVITE
Allow-Events: kpml
Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,OPTIONS,REFER,REGISTER,SUBSCRIBE
Content-Length: 232
Content-Type: application/sdp
v=0
o=CiscoSystemsUCXN 997464866 997464869 IN IP4 172.27.199.12
s=No Subject
c=IN IP4 0.0.0.0
t=0 0
m=audio 19308 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=ptime:20
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=inactive>>>>>>>>>>>>>>>>>>>>

with media -Inactive at this point there sis break in media again and CUCM sends the ACK to the phone .Afterwards we see a bye message from  unity.

So CUCM should receive attribute-sendreceive to establish the media path again

=====================================================

00139348.001 |12:55:18.719 |AppInfo |SIPTcp - wait_SdlSPISignal: Outgoing SIP TCP message to 172.27.199.115 on port 49368 index 13
[22867,NET]
ACK sip:c724c7d7-2935-9ea4-2d54-e5f25c8e0bf8@172.27.199.115:49368;transport=tcp SIP/2.0
Via: SIP/2.0/TCP 172.27.199.11:5060;branch=z9hG4bKa102ce8b1af
From: <sip:5@172.27.199.11>;tag=7564~1c99d99b-4d8e-200c-ed64-5eee938b17f2-23803484
To: "1028" <sip:1028@172.27.199.11>;tag=dccec1d47e9106e973dbf846-1037814d
Date: Fri, 10 Jun 2016 17:55:18 GMT
Call-ID: dccec1d4-7e91004f-4962229c-63785fab@172.27.199.115
User-Agent: Cisco-CUCM10.5
Max-Forwards: 70
CSeq: 105 ACK
Allow-Events: presence
Content-Type: application/sdp
Content-Length: 238
v=0
o=CiscoSystemsCCM-SIP 7564 4 IN IP4 172.27.199.11
s=SIP Call
c=IN IP4 0.0.0.0
b=TIAS:0
b=AS:0
t=0 0
m=audio 19308 RTP/AVP 0 101
a=ptime:20
a=rtpmap:0 PCMU/8000
a=inactive>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15

+++++++++++++++++++++++++++

Unity is sending a bye

+++++++++++++++++++++

00139362.002 |12:55:18.939 |AppInfo |SIPTcp - wait_SdlReadRsp: Incoming SIP TCP message from 172.27.199.12 on port 41055 index 380 with 532 bytes:
[22871,NET]
BYE sip:1000@172.27.199.11:5060;transport=tcp SIP/2.0
From: sip:5600@172.27.199.12:5060;tag=232f4b06301a431daf7b48d42d320316
To: sip:1000@ucm-pub.ciscolocal.com;tag=7571~1c99d99b-4d8e-200c-ed64-5eee938b17f2-23803488
Via: SIP/2.0/TCP 172.27.199.12:5060;branch=z9hG4bK0087944b01e9405fb218656d461895c5
Max-Forwards: 70
User-Agent: Cisco-UnityConnection/8.5
Call-ID: 911d6e3ade06426faa10ca9cae34a889@ucm-pub.ciscolocal.com
CSeq: 202 BYE
Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,OPTIONS,REFER,REGISTER,SUBSCRIBE
Content-Length: 0

+++++++++++++++++++++++++++++++++++++++++++++++++++++

You can try to check option early offer insert MTP is needed on SIP trunk and reset otherwise you can check MTP required and then test.

In this way media -inactive attribute will never be sent and MTP will stay in media path.thanks

[Chadster766]

Thanks for trying to figure this one out :-) I did the Early Offer MTP and Require MTP but no luck.

I found the solution. It's probably so simple that's way TAC and forum Pros missed it. Some CSS info was needed for the CUC SIP Trunk.

[Deepak Mehta · Accepted solution]

Thanks, may be I will test this in the LAB myself. 

Because if CSS is missing then call should not even reach out to the extension. 

[Chadster766]

I wish the call handler didn't ring the extension then it would have been an easier troubleshoot :-)

[Deepak Mehta]

lol indeed my friend..!! That would have saved some our time:).this was nasty one for me as I was no where close otherwise we are always close enough if not on target.

[Jaime Valencia]

Seems a bit unlikely, unless you changed the codec list to be used, but usually that is related to codec issues.