Troubleshoot IP phone call drops

[jprovine@uic.edu]

I am currently on

Cisco Unified CM Administration

System version: 11.5.1.14900-11

I have a user who says that during a webex cisco conference call and at other times she will get dropped of the call. What is the best method to troubleshoot to see what is causing the issue?

[Jaime Valencia]

Determine the call flow and start gathering traces, debugs logs to review them.

If this is a common occurrence, then have the user let you know when he'll place a call to enable debugs/logs to review and gather information related to what might be causing the issue.

[jprovine@uic.edu]

I did contact the user and asked for the most recent incident, time and date. Then I collected the logs using Cisco unified real-time monitor and open it up in translatorX and searched for the call in question.  I found this in the BYE section

CSeq: 102 BYE
Reason: Q.850;cause=41

Is there a way to get more information about what caused those? Is there anything else I should be looking at?

[TONY SMITH]

I normally start by taking whatever debug is easiest, to see which end initiated the drop.  However make sure you have a clear description from the user, for example if they lose audio are they hanging up the call as a result.

[jprovine@uic.edu]

what debug do you consider the easiest to collect? what tools do you use?

[TONY SMITH]

Easiest debug is partly personal, partly depends on the context.  If the calls are external then the first question is whether it's a service provider issue, or a CUCM/Gateway issue.  So I'd start with a debug on the gateway.  If it look like the call is being dropped by CUCM then move onto CUCM traces.  Dropped by the provider, raise it with them.

In your example that cause code indicates a fault elsewhere.  What device is actually sending the BYE, and where is it being sent?

[jprovine@uic.edu]

I am new to phones so where to I find who is sending the bye?

[TONY SMITH]

OK we need to know a bit more about your design.  You collected some traces, from where?  And something within that trace sent a "BYE".  Do you even know that was part of the failed call?

[jprovine@uic.edu]

not exactly sure what you want to know about my design but I downloaded the call manager logs using cisco unified real time monitoring tool 11.5 and then imported the information in to TranslatorX and searched for the webex call with the users number according to the day and time she gave me. In that information there was a bye about every 25-30 minutes during that webex call.The purpose of this post was to get information on how to gather and interpret the information in order to tell why the call is dropping, again I am very new  to this

[TONY SMITH]

The point is that all you're giving us is a description of the fault, and the fact that some unspecified device sent a BYE to some other unspecified device with a cause code indicating a remote fault.  That's not much to go on.  Maybe as a start post up a screenshot of the call flow diagram from TranslatorX.

[jprovine@uic.edu]

here is the snip of the tranx information for the bye 

[TONY SMITH]

Can you please show the whole trace, either screenshot the diagram or post the debugs.  Whichever is easier.  All that screenshot tells us is that "something" sent that BYE to "something else" as a result of an error reported by "yet another thing"

[lior look]

Further to Tony, click on the diagram button and share a screenshot of the sip dialog for the specific call..

First, it is important that we first know the topology.

usually reason code 41 point of network failure.