cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3856
Views
15
Helpful
4
Replies

Cisco CUBE Disconnect Cause (CC) : 65

Ferdous Pirzad
Level 1
Level 1

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 

1 Accepted Solution

Accepted Solutions

Ayodeji Okanlawon
VIP Alumni
VIP Alumni

 

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:

.xfer.PNG

 

++ 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

 

 

Please rate all useful posts

View solution in original post

4 Replies 4

TONY SMITH
Spotlight
Spotlight

Can you share the output from "debug ccsip mess" from your CUBE?

sudaggar
Cisco Employee
Cisco Employee
checked CCM traces and port status monitor logs, calls are reaching to CUC and DTMF also recognized in CUC.

could you please provide what is configured in call greeting (Call treatment) in CUC.

Is it sending call back to CUCM, and then to other extension in CUCM?
How many CUCM nodes are there in cluster?

Also please share working call CUCM traces (from all nodes set to detailed) and CUC port status monitor logs.

Ayodeji Okanlawon
VIP Alumni
VIP Alumni

 

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:

.xfer.PNG

 

++ 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

 

 

Please rate all useful posts

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 .