A call failed and the CDR does not explain why

The CDR records the outcome of a call; the SIP log records the conversation. When a code alone does not explain a failure, the message flow shows which side said what and when. The SIP Logs Viewer extracts the signalling of one call by its Call-ID and draws it as a ladder diagram.

Symptom

A call failed or behaved oddly, for example dropped after 30 seconds, rang but never connected, or had no audio.
The CDR code is generic, such as 500, 503 or 408, or the call has no CDR at all.
Reports → Calls gives no conclusive Diagnosis.

Quick checks

Look the call up in Reports → Calls first; its card lists every vendor attempt with codes, PDD and who released the call.
Open Call Details and read Release Source, PDD and the SDP Records; many media and timeout problems are visible there.
Make sure the call is recent: SIP logs are rotated after a few days, and old calls cannot be extracted.

Extract the SIP log

The SIP Logs Viewer is available to the root customer.

Find the call in Reports → Call Records (CDRs) or Vendors Call Records and copy its Call-Id from Call Details. For a call without a CDR, take the Call-ID from the caller’s device or PBX.
Click Options → Queue SIP Log Extraction in the row, or Extract SIP Log in the row’s expanded routing view, and confirm. Click Open SIP Logs in the confirmation.
Alternatively open Tools & Debugs → SIP Logs Viewer, enter the Call-Id and a Description under Add Extracting Task, and click Add.
Wait for Status to change from Extracting to Completed. The list refreshes by itself.
Click View Log for the ladder diagram or Get Log to download the raw messages.

Screenshot "troubleshooting/sip-logs-viewer" has not been generated yet — see scripts/screenshots/screens.yml.

Not Found means the log no longer contains the call, usually because the log was rotated, or the Call-ID is wrong. Filter the list with Start Date and End Date; the default is the last week. Delete removes a task you no longer need.

Cause 1: the call never reached the switch

How to confirm: the extraction ends with Not Found for a recent call, and Calls has no record of it.

Fix: the INVITE was lost before the switch. Check the firewall of the switch (System Management → IP Firewall), the customer’s routing towards your IP, and any router with SIP ALG in between. See Devices lose registration or have one-way audio.

Cause 2: the switch rejected the call

How to confirm: the diagram shows the INVITE from the caller and a final response from the switch, with no INVITE towards any vendor. The response code matches a negative internal code in the CDR or an authentication failure.

Fix: follow the code in Calls fail with a SIP error code, and reproduce the call in Test Dialplan with the CLI, CLD and source address from the INVITE.

Cause 3: the vendor rejected or did not answer

How to confirm: the diagram shows INVITEs towards one or more vendor addresses and their responses. A 100 Trying followed by nothing until a CANCEL means the timeouts expired; a quick 403 or 503 comes from the vendor’s side.

Fix: send the vendor the Call-ID, time and their response. Tune Reply Timeout, 1xx Timeout and 2xx Timeout, or move the vendor down in the routing group until it is fixed.

Cause 4: the call connected but media failed

How to confirm: the call reaches 200 OK and ACK but ends with a BYE after about 30 or 60 seconds, or the users report silence. The SDP in the diagram shows private addresses such as 192.168.x.x or codecs that do not match.

Fix: enable Use Media Relay on the connection or the account’s Media Relay Type, check that the relay ports are open in the firewall, and disable SIP ALG on the routers involved. See Media relay.

Still not working?

Collect the following and open a ticket at support.flysip.com:

The Call-ID and the time of the call.
The downloaded SIP log from Get Log.
The account, the CLI and the CLD, and what the caller heard.