Read a SIP trace: where to look first
A trace from a busy gateway holds hundreds of messages. Four questions get you to the cause faster than reading from the top.
1. Which messages belong to the call?
Find the INVITE for the number or time in question and note its Call-ID. Every message in that dialog carries it. A gateway or SBC that sits in the middle creates a second call leg with a different Call-ID, so find both legs before drawing conclusions.
2. Who ended it, and with what?
Look for the final response to the INVITE, or the BYE or CANCEL.
- A 4xx response means the far end rejected the request as sent. 404 usually points at the number format, 401, 403 and 407 at authentication or permission, 488 at the media offer.
- A 5xx response means the far end could not process it. 503 often comes from something further downstream.
- A BYE shows which side hung up. The
Reasonheader, when present, carries a cause code such asQ.850;cause=16for normal clearing. - A CANCEL from the caller's side before any answer usually means a timeout or the caller gave up.
3. What did each side offer for media?
Read the SDP in the INVITE and in the answer (the 200 OK, or a 183).
m=audiolists the codecs offered. If the answer shares none, expect a 488 or silence.c=is the address media should be sent to. A private address offered to a public peer is the classic cause of audio in one direction only.a=sendrecv,sendonly,recvonlyandinactiveexplain hold and resume problems.telephone-eventshows whether DTMF was negotiated in the media stream.
4. What is different from a call that works?
Take a working call through the same path and compare the same message in each. Ignore fields that always differ, such as tags and branch values, and look at the request line, the identity headers and the SDP.
Collecting a clean trace on a CUBE
Set service timestamps debug datetime msec and a large logging buffered size, run debug ccsip messages, reproduce one call, then turn debugging off. One call in the buffer is easier to read than fifty.
A signaling trace shows what was agreed. It does not prove audio flowed. For that you need a packet capture.
Where Workbench helps
SIP Trace Analyzer draws the ladder and marks the failure. Call Comparison puts the working and failing calls side by side and highlights the fields that differ.