cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2228
Views
5
Helpful
9
Replies

Call drop issue

Bharath
Level 1
Level 1

Hi,

 

We are observing call drop issue for multiple calls. And from CDR report we found that the dest_cause_value as 16 which confirms the call was ended at agent extension.

 

Also from CM traces we could see that the BYE request was initiated from CM and cause code as 16 which is a normal disconnect.

 

Please suggest on identifying the root cause.

 

To: 4166265165 <sip:4166265165@10.1.16.30:5060>;tag=ds1672d189
Date: Thu, 23 Nov 2017 14:45:11 GMT
Call-ID: D9E88C0000010000000969A00B102E0A-151144830741157515@10.1.16.30
User-Agent: Cisco-CUCM9.1
Max-Forwards: 70
CSeq: 101 BYE
Reason: Q.850;cause=16
Content-Length: 0
image001.pngimage002.png
9 Replies 9

geoff
Level 10
Level 10

Is there a time lag here between the call being established and the BYE? Is the agent releasing the call? Check the TCD table for CallDisposition = 52.

 

Or are you saying that some calls simply do not get established correctly, and you see the BYE almost immediately?

 

Regards,
Geoff

Hi Geoff,

 

I couldn't see any time lag between call establishment and the bye signal.

 

Below is the TCD output where i could see disposition as 13. Here the agent picked the call after ring and the call disconnected abruptly.

 

It would help if you can provide all the logs especially cucm and cvp logs. Please include the call details. 

Please rate all useful posts

Please find the below call details,

 

Calling number : 4166265165 

DateTime : Nov 23, 2017 09:22:30 AM 

Called Number : 2996

Call GUID : B1AB5E0000010000000969330B102E0A

 

I studied these log files yesterday, and again this morning and could not reach a conclusion. All we can see is that 2s after answering a BYE is sent. It appears to originate from CVP. A mystery.

 

Regards,

Geoff

Bharath,

 

This call is been disconnected by CUCM. This is why I asked for the CUCM logs so we know what is going on. ( we can also see this from the SIP ladder of translatorX you posted)

Here is my analysis of the call..

 

1. ++ SIP leg to connect the agent leg ++
210683000: 10.1.16.30: Nov 23 2017 09:22:30.643 -0500: %_Connection-7-com.dynamicsoft.DsLibs.DsUALibs.DsSipLlApi.Connection:  Sending Message (NB): INVITE sip:2996@CAN.cucm.st.com;transport=tcp SIP/2.0
Via: SIP/2.0/TCP 10.1.16.30:5060;branch=z9hG4bKyMMfJnUR7AESmbb3BkSZ9g~~3736808
Max-Forwards: 64
To: <sip:2996@CAN.cucm.st.com;transport=tcp>
From: 4166265165 <sip:4166265165@10.1.16.30:5060>;tag=dsa061d95
Call-ID: B1AB5E0000010000000969330B102E0A-151144695064357349@10.1.16.30
CSeq: 1 INVITE
Content-Length: 0
Contact: <sip:4166265165@10.1.16.30:5060;transport=tcp>
Expires: 25
User-Agent: CVP 9.0 (1) Build-670
---
Cisco-Guid: 2980797952-0000065536-0000616755-0185609738
----

2. +++ Agent answers call and CUCM sends 200 OK at 9:22:36 +++

210683046: 10.1.16.30: Nov 23 2017 09:22:36.228 -0500: %_Connection-7-com.dynamicsoft.DsLibs.DsUALibs.DsSipLlApi.Connection:  Composed Message:
SIP/2.0 200 OK
Via: SIP/2.0/TCP 10.1.16.30:5060;branch=z9hG4bKyMMfJnUR7AESmbb3BkSZ9g~~3736808
From: 4166265165 <sip:4166265165@10.1.16.30:5060>;tag=dsa061d95
To: <sip:2996@CAN.cucm.st.com;transport=tcp>;tag=14232678~193b144b-2817-4b16-b865-a18cded75b0f-64729727
Date: Thu, 23 Nov 2017 14:22:30 GMT
Call-ID: B1AB5E0000010000000969330B102E0A-151144695064357349@10.1.16.30
CSeq: 1 INVITE
--
Session-Expires:  86400;refresher=uas
Require:  timer
P-Asserted-Identity: "Keisha Matthews-Downing" <sip:2996@10.46.16.12>
----

v=0
o=CiscoSystemsCCM-SIP 14232678 1 IN IP4 10.46.16.12
s=SIP Call
c=IN IP4 192.168.1.39
---

3. ++  CVP sends re-INVITE to PSTN caller to connect agent ++

INVITE sip:4166265165@10.46.16.11:5060 SIP/2.0
Via: SIP/2.0/TCP 10.1.16.30:5060;branch=z9hG4bKyMMfJnUR7AESmbb3BkSZ9g~~3736810
Max-Forwards: 70
To: <sip:4166265165@10.46.16.11>;tag=16374478~193b144b-2817-4b16-b865-a18cded75b0f-44890606
From: <sip:6526@10.1.16.30>;tag=ds1884d924
CSeq: 2 INVITE
Content-Length: 408
Contact: <sip:10.1.16.30:5060;transport=udp>
Allow-Events: presence
Remote-Party-ID: \"Keisha Matthews-Downing\" <sip:2996@10.46.16.12>;party=called;screen=yes;privacy=off
Content-Type: application/sdp
v=0
o=CiscoSystemsCCM-SIP 14232678 1 IN IP4 10.46.16.12
s=SIP Call
c=IN IP4 192.168.1.39
Call-ID: b1ab5e00-a161d995-c85b4-b102e0a@10.46.16.11

4. +++ PSTN gateway sends 200 OK to re-INVITE +++

200 OK
Via: SIP/2.0/TCP 10.1.16.30:5060;branch=z9hG4bKyMMfJnUR7AESmbb3BkSZ9g~~3736810
To: <sip:4166265165@10.46.16.11>;tag=16374478~193b144b-2817-4b16-b865-a18cded75b0f-44890606
From: <sip:6526@10.1.16.30>;tag=ds1884d924
---
Content-Type: application/sdp
v=0
o=CiscoSystemsCCM-SIP 16374478 3 IN IP4 10.46.16.11
s=SIP Call
c=IN IP4 10.46.1.250
--
m=audio 26548 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=ptime:20
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
Call-ID: b1ab5e00-a161d995-c85b4-b102e0a@10.46.16.11

5. +++ CVP sends ACK to CUCM to connect agent to PSTN caller +++

B1AB5E0000010000000969330B102E0A-151144695064357349 - [OUTBOUND]: Updated by : CALLGUID = B1AB5E0000010000000969330B102E0A LEGID = b1ab5e00-a161d995-c85b4-b102e0a - [INBOUND]: with event type REINV_ACCEPTED  

ACK sip:2996@10.46.16.12:5060;transport=tcp SIP/2.0
Max-Forwards: 70
To: <sip:2996@CAN.cucm.st.com;transport=tcp>;tag=14232678~193b144b-2817-4b16-b865-a18cded75b0f-64729727
From: 4166265165 <sip:4166265165@10.1.16.30:5060>;tag=dsa061d95
Call-ID: B1AB5E0000010000000969330B102E0A-151144695064357349@10.1.16.30
---
c=IN IP4 10.46.1.250
b=TIAS:64000
b=AS:64
t=0 0
m=audio 26548 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
--

6. ++ CVP sends ACK to PSTN gateway to complete the re-INVITE ++

ACK sip:4166265165@10.46.16.11:5060 SIP/2.0
Via: SIP/2.0/TCP 10.1.16.30:5060;branch=z9hG4bKyMMfJnUR7AESmbb3BkSZ9g~~3736812
Max-Forwards: 70
To: <sip:4166265165@10.46.16.11>;tag=16374478~193b144b-2817-4b16-b865-a18cded75b0f-44890606
From: <sip:6526@10.1.16.30>;tag=ds1884d924
CSeq: 2 ACK
Content-Length: 0
Contact: <sip:10.1.16.30:5060;transport=udp>
Allow-Events: presence
Call-ID: b1ab5e00-a161d995-c85b4-b102e0a@10.46.16.11

7. ++ two secs after the call was connected at 9:22.38 . CUCM sent the BYE +++

210683488: 10.1.16.30: Nov 23 2017 09:22:38.318 -0500: %_Connection-7-com.dynamicsoft.DsLibs.DsUALibs.DsSipLlApi.Connection:  Composed Message:
BYE sip:4166265165@10.1.16.30:5060;transport=tcp SIP/2.0
Via: SIP/2.0/TCP 10.46.16.12:5060;branch=z9hG4bK5c8a9b7a891522
From: <sip:2996@CAN.cucm.st.com;transport=tcp>;tag=14232678~193b144b-2817-4b16-b865-a18cded75b0f-64729727
To: 4166265165 <sip:4166265165@10.1.16.30:5060>;tag=dsa061d95
Date: Thu, 23 Nov 2017 14:22:36 GMT
Call-ID: B1AB5E0000010000000969330B102E0A-151144695064357349@10.1.16.30
User-Agent: Cisco-CUCM9.1
Max-Forwards: 70
CSeq: 101 BYE
Reason: Q.850;cause=16
Content-Length: 0

 

Please collect CUCM logs, so we know why CUCM is ending the call.

Please rate all useful posts

Excellent analysis. Thank you.

 

Regards,

Geoff

geoff
Level 10
Level 10
  • Are the calls that fail queuing for some moments in CVP or are they being sent to a ready agent immediately?
  • Are calls that fail all coming in on the same DN (or set of DNs) that are caught by the same dial peer?
  • What percentage of calls that get sent to agents are the calls that fail?
  • Is there something noteworthy about the phones of agents where the call fails?
  • Can you see any commonality on the failed calls?

 

Regards,
Geoff

Geoff,

 

Please find the commands inline.

 

  • Are the calls that fail queuing for some moments in CVP or are they being sent to a ready agent immediately? Yes calls were routed to agent and was able to answer the call as well. However call got disconnected withing few secs.
  • Are calls that fail all coming in on the same DN (or set of DNs) that are caught by the same dial peer? Only few calls are failing rest of them are working fine.
  • What percentage of calls that get sent to agents are the calls that fail?
  • Is there something noteworthy about the phones of agents where the call fails? We could find any issue with the phone. All agents are using same model.
  • Can you see any commonality on the failed calls? It seems calls coming from 4166265165 are failing the most. Almost 4-5 calls within 30 min.

Regards,

Bharath M