EasyUC
English
Aurora

Choose appearance

4.8.7

Diagnostics & monitoring

Narrow down a call problem: procedure step by step

From the reported problem through call list, call diagnostics and call analysis to a documented finding.

EasyUC · Version 4.8.7

In EasyUC: EasyUC Cisco → Reporting → Nutzung & Erreichbarkeit → Calls; Logs → Call Diagnostics / Call Analysis

What it is for

"The call at 10:42 did not get through." Most fault reports start like this or similarly. This chapter describes a fixed procedure for turning such a report into a documented finding: which call it was, how it ended, where it failed and what the evidence is.

EasyUC offers several tools for this. The call list shows finished calls from the CDRs. Call diagnostics fetches the SIP flow of a known call from the traces. Call analysis pulls all calls of a period, including those that were never completed. Live Calls shows what is in progress right now. For Teams calls over the integrated SBC there is the call history.

Time is decisive. The CUCM traces are overwritten after a few hours. Therefore start the investigation on the same day if possible.

Prerequisites

  • Role ROLE_APP_CALL_DIAGNOSTICS. It includes read access to the call list.
  • The CDR import of the CUCM connection is running.
  • On the CUCM, Cisco CallManager uses trace level Detailed with Enable SIP Call Processing Trace.
  • From the person reporting: the time as exactly as possible, their own number, the number of the other party, the direction of the call and what they heard or saw.
  • For calls through a CUBE: debug capture switched on at the CUBE if you want to see the leg to the provider.

Step by step: record the report

  1. Ask for the time and expect an inaccuracy of a few minutes.
  2. Note the number of the caller and the dialled number in the form in which it was dialled.
  3. Clarify the direction: external to internal, internal to external or internal.
  4. Ask what the person noticed: busy tone, ringback without an answer, announcement, silence, immediate disconnect or disconnect during the conversation.
  5. Ask whether the problem occurred once or can be reproduced.
  6. In EasyUC, select the CUCM connection the call went through in the header.

Step by step: find the call

  1. Open Reporting → Nutzung & Erreichbarkeit → Calls.
  2. Narrow the period to a few minutes before and after the stated time and search for one of the two numbers.
  3. If the call is in the list, click Analyze in its row and start the call diagnosis. Continue in the next section.
  4. If the call is not in the list, open Logs → Call Analysis.
  5. Choose the period, for example Custom period with 15 minutes around the stated time, and both data sources.
  6. Under Filters (optional), enter the known Number and click Pull calls.
  7. Search the call list of the run for the number. Calls with the source SIP only are calls that the CUCM did not write to the CDRs.
  8. If you find nothing there either, the call did not reach the CUCM. Then continue looking at the gateway, at the CUBE or with the provider.

Step by step: evaluate the call

  1. Read the Result of the call: answered, busy, no answer, rejected, unreachable, abandoned by caller or failed.
  2. Read the Causes of both sides and Ended by.
  3. Compare Dialled and Reached. If they differ, read the Redirect chain.
  4. Open the call flow. Find the first red response and establish which lane it comes from.
  5. Click this response and the INVITE before it. Read destination number, sender and SDP.
  6. For complaints about audio quality, open the Media / quality tab in call analysis and read codec, packet loss, jitter and MOS.
  7. On the Devices tab, open the phone or user involved to check its configuration.
  8. Export the evidence: in call diagnostics SIP messages (text) and Download SVG, in call analysis Export → Everything (JSON).

Fields and options: which tool for what

Field / actionMeaning and use
Call list (Reporting)Finished calls from the CDRs with time, numbers, duration and cause. The first place to look when time and number are known. Calls appear only after the CDR interval of the CUCM and the import.
Call diagnosticsSIP flow of a single, known call from the traces of all CallManager nodes. Time window one second to 30 minutes.
Call analysisAll calls of a period from CDRs and traces, including calls that were not completed or are still in progress. With call flow up to 60 minutes, CDRs only up to 24 hours.
Live CallsCalls in progress in the cluster. Suitable when the problem can be reproduced.
CURRI logsShows whether a rule rejected or redirected the call. Call diagnostics can be started directly from there.
Call history in the Teams tenantSIP ladder diagram per Teams call over the integrated SBC.
CUBE debug captureAdds the leg between CUBE and provider to the flow.
Registration historyShows whether the destination device was registered at the time of the call.

Fields and options: typical findings

Field / actionMeaning and use
Busy although nobody is on a call486 comes from the CUCM without an INVITE to the destination: the busy trigger of the line is reached, often because of a held or stuck call. Check the busy trigger and Live Calls.
External call does not arriveNo call in CDRs and traces: it did not reach the CUCM. 404 from the CUCM: the number arrives in a format that matches no pattern. Read the destination number in the INVITE.
Outbound external call fails immediately503 or 403 from the lane of the trunk: trunk faulty, channels in use or calling number not permitted.
It rings, but nobody picks up180 Ringing, then CANCEL from the caller or a forwarding. Not a technical error. Check the ring time and call forward no answer.
Call ends up at the wrong destinationDialled and Reached differ. The redirect chain names who redirected.
No audio or audio in one direction onlySignalling complete with 200 OK and ACK. Compare the SDP of both sides. The error is in the media path: firewall, routing or NAT.
Disconnect after fixed timesBYE after the same duration every time: a session timer or a firewall ends the connection. Read the gaps in the time column.
Poor audio qualityQuality Fair or Poor with packet loss or jitter. Check the network path of the reporting device.

Check the result and narrow down errors

  • A finding is complete when it contains five items: time and numbers of the call, result, cause, the place in the flow with the decisive message and the exported evidence.
  • The call is older than two hours and the diagnosis finds no messages: the traces have been overwritten on the CUCM. The CDRs remain available and provide result and cause, but no call flow.
  • The call list does not show the call yet: the CDRs arrive with a delay. Call analysis with the traces source shows it immediately.
  • Several calls match time and number: compare devices and duration. Call diagnostics lists Other matching calls.
  • The call flow is missing for a device with SCCP or on an analogue port: for these devices there are only CDRs.
  • If the problem can be reproduced, do so and start the call diagnosis directly afterwards. For calls through the CUBE, switch on its debug capture beforehand.
  • Pass exports on only to the intended recipient. They contain phone numbers and device names. Credentials and keys are removed.

Related chapters