05-09-2020 10:17 AM
Hello Recently i have setup a call center with IVR (Auto Attendant ) , My network Scenario is as follows :
PSTN>CUBE>CUCM>CUC ( cisco unity connection) ,
all integrations are successful i can initiate a call from cucm to outside as well as call from outside to cucm ,
how ever when i implemented CUC and forwarded all calls from OUTSIDE to CUC for auto attendant , when i try initiating calls from internal extensions it works normal , however when i initiate a call from external extensions the calls come to ivr and Greeting plays after when i put an input , DTMF input accepted and An audio message will be played wait while i transfer your calls then the calls get disconnected , I'm using cisco isr 4321 for cube and cucm version 12 , all is using SIP Integration
I"m sharing my CUBE Config as well as Debug ccsip calls as well as CUCM Real time monitoring call traces as well as unity connection Trace Logs kindly check and help me to solve the issue
Solved! Go to Solution.
05-11-2020 03:47 AM
Hi,
Looking at the logs, the call is failing from where lots of transfer calls fail, during mid-call signalling negotiation.
Here is the sip ladder:
.
++ when unity attempts to transfer the call, It sends a Re-INVITE to CUCM with a break in media and then CUCM sends this to CUBE with an inactive media ttaribute ++
[95950,NET]
INVITE sip:+93793468868@192.168.15.1:5060;transport=tcp SIP/2.0
Via: SIP/2.0/TCP 192.168.15.30:5060;branch=z9hG4bKef25761ff71
From: <sip:707717717@192.168.15.30>;tag=33583~94f0c294-b08b-49e1-b36d-8b7aef361720-29626782
To: "+93793468868" <sip:+93793468868@192.168.15.1>;tag=9AD71DFD-131C
Date: Sat, 09 May 2020 06:21:05 GMT
Call-ID: BF54A3EE-908F11EA-BD1FDDCD-853FD303@192.168.15.1
Supported: timer,resource-priority,replaces
Cisco-Guid: 3209955270-2425295338-3172589005-2235552515
----
v=0
o=CiscoSystemsCCM-SIP 33583 2 IN IP4 192.168.15.30
s=SIP Call
c=IN IP4 0.0.0.0
b=TIAS:64000
b=AS:80
t=0 0
m=audio 20488 RTP/AVP 0 101
a=ptime:20
a=rtpmap:0 PCMU/8000
a=inactive
++ The CUBE then immediately sends a BYE ++
01152627.003 |10:51:05.432 |AppInfo |SIPTcp - wait_SdlReadRsp: Incoming SIP TCP message from 192.168.15.1 on port 33599 index 95 with 602 bytes:
[95952,NET]
BYE sip:2500@192.168.15.30:5060;transport=tcp SIP/2.0
Via: SIP/2.0/TCP 192.168.15.1:5060;branch=z9hG4bK2E665113A
From: "+93793468868" <sip:+93793468868@192.168.15.1>;tag=9AD71DFD-131C
To: <sip:707717717@192.168.15.30>;tag=33583~94f0c294-b08b-49e1-b36d-8b7aef361720-29626782
Date: Fri, 08 May 2020 18:22:53 GMT
Call-ID: BF54A3EE-908F11EA-BD1FDDCD-853FD303@192.168.15.1
User-Agent: Cisco-SIPGateway/IOS-16.6.4
Max-Forwards: 70
Timestamp: 1588962173
CSeq: 103 BYE
Reason: Q.850;cause=65
Session-ID: d67d5097596d59529241df3bb393afdd;remote=7b342a3e1ac17f0d1442b89fcab33584
Content-Length: 0
It is difficult to know why CUBE is sending BYE without seeing the debug ccsip message but my guess is that this is due to the break in media sent to the ITSP and most likely the BYE is coming from ITSP.
You can enable midcall signalling consumption as follows:
voice service voip
sip
midcall-signaling passthru media-change
Test after making the change and if it doesnt work, then enable
debug ccsip mess.
Test again and send the logs including the call details
05-11-2020 01:21 AM
Can you share the output from "debug ccsip mess" from your CUBE?
05-11-2020 01:56 AM
05-11-2020 03:47 AM
Hi,
Looking at the logs, the call is failing from where lots of transfer calls fail, during mid-call signalling negotiation.
Here is the sip ladder:
.
++ when unity attempts to transfer the call, It sends a Re-INVITE to CUCM with a break in media and then CUCM sends this to CUBE with an inactive media ttaribute ++
[95950,NET]
INVITE sip:+93793468868@192.168.15.1:5060;transport=tcp SIP/2.0
Via: SIP/2.0/TCP 192.168.15.30:5060;branch=z9hG4bKef25761ff71
From: <sip:707717717@192.168.15.30>;tag=33583~94f0c294-b08b-49e1-b36d-8b7aef361720-29626782
To: "+93793468868" <sip:+93793468868@192.168.15.1>;tag=9AD71DFD-131C
Date: Sat, 09 May 2020 06:21:05 GMT
Call-ID: BF54A3EE-908F11EA-BD1FDDCD-853FD303@192.168.15.1
Supported: timer,resource-priority,replaces
Cisco-Guid: 3209955270-2425295338-3172589005-2235552515
----
v=0
o=CiscoSystemsCCM-SIP 33583 2 IN IP4 192.168.15.30
s=SIP Call
c=IN IP4 0.0.0.0
b=TIAS:64000
b=AS:80
t=0 0
m=audio 20488 RTP/AVP 0 101
a=ptime:20
a=rtpmap:0 PCMU/8000
a=inactive
++ The CUBE then immediately sends a BYE ++
01152627.003 |10:51:05.432 |AppInfo |SIPTcp - wait_SdlReadRsp: Incoming SIP TCP message from 192.168.15.1 on port 33599 index 95 with 602 bytes:
[95952,NET]
BYE sip:2500@192.168.15.30:5060;transport=tcp SIP/2.0
Via: SIP/2.0/TCP 192.168.15.1:5060;branch=z9hG4bK2E665113A
From: "+93793468868" <sip:+93793468868@192.168.15.1>;tag=9AD71DFD-131C
To: <sip:707717717@192.168.15.30>;tag=33583~94f0c294-b08b-49e1-b36d-8b7aef361720-29626782
Date: Fri, 08 May 2020 18:22:53 GMT
Call-ID: BF54A3EE-908F11EA-BD1FDDCD-853FD303@192.168.15.1
User-Agent: Cisco-SIPGateway/IOS-16.6.4
Max-Forwards: 70
Timestamp: 1588962173
CSeq: 103 BYE
Reason: Q.850;cause=65
Session-ID: d67d5097596d59529241df3bb393afdd;remote=7b342a3e1ac17f0d1442b89fcab33584
Content-Length: 0
It is difficult to know why CUBE is sending BYE without seeing the debug ccsip message but my guess is that this is due to the break in media sent to the ITSP and most likely the BYE is coming from ITSP.
You can enable midcall signalling consumption as follows:
voice service voip
sip
midcall-signaling passthru media-change
Test after making the change and if it doesnt work, then enable
debug ccsip mess.
Test again and send the logs including the call details
05-11-2020 08:23 PM
Thank you alot Ayodeji Okanlawon , That is what i missed , after applying this
RouterName(conf-voi-serv)#sip
RouterName(conf-serv-sip)#midcall-signaling passthru media change
All started working .
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide