How to read a SIP trace and identify why a call fails

Start with the question the trace needs to answer#

The most common mistake in SIP analysis is not overlooking a single header. It starts earlier: someone opens a PCAP or sngrep, scrolls through hundreds of messages and looks for “something strange” without defining the symptom. Failed setup, disconnection after 30 seconds and one-way audio each need different evidence.

Before analysis, record four details:

• who initiates the call and which number they dial,
• the time of the problem and its time zone,
• the observed result: no ringing, an error, silence, disconnection or incorrect caller ID,
• the expected result.

This short definition limits scope and separates signalling from media. “A calls B, B answers, A cannot hear B” leads to SDP and RTP analysis. “A calls B, but the carrier returns 403” primarily requires reviewing routing, identity and carrier policy.

Establish dialog boundaries: Call-ID, tags and transactions#

The initial reference point is usually Call-ID. It gathers messages belonging to a dialog, but is not a universal identifier for an entire business call. A transfer, B2BUA, another bridge or an outbound carrier leg may create a new dialog and Call-ID.

A useful Wireshark filter is:

sip.Call-ID == "przykladowe-call-id@pbx.example"

Then inspect:

1. the first INVITE,
2. provisional responses 100, 180 or 183,
3. the final response,
4. ACK,
5. any re-INVITE or UPDATE,
6. termination: BYE, CANCEL or an error response.

Tags in From and To help identify the dialog. The branch parameter in Via identifies a transaction. CSeq indicates the method sequence within the dialog. Together they distinguish retransmission of the same request from a new negotiation.

Read the flow left to right, but compare both legs#

With a PBX, SBC or B2BUA, a call has at least two legs. A message received from a phone need not be sent unchanged to the carrier. The system can modify the Request-URI, domain, identity, SDP, codec order, privacy headers or forwarding information.

Compare input and output at each important stage:

If the error appears only on the outgoing leg, investigate the dialplan, SIP profile, header translation or gateway configuration. If the incorrect value already arrives from the device, assess provisioning or client logic.

Interpret responses in their transaction context#

A response code starts the investigation; it does not finish it. 404 Not Found can mean an absent destination number, an incompatible numbering format or the wrong tenant. 403 Forbidden may arise from identity policy, authorisation, class of service, a limit or fraud protection. 488 Not Acceptable Here often points towards SDP and codecs, but can concern other session parameters.

A practical sequence:

• identify which device generated the response,
• read Reason, the status text and any carrier-specific headers,
• check whether the PBX rewrote the code before passing it to the caller,
• compare a working call to the same destination,
• establish whether the issue is constant or depends on the number, user, gateway or time of day.

200 OK does not end diagnosis. It confirms successful completion of the INVITE transaction, but the call may still have broken media, an incorrect RTP direction or a session timeout that disconnects it.

Check routing and identity#

In the first INVITE, inspect at least:

• Request-URI,
• To and From,
• P-Asserted-Identity or P-Preferred-Identity,
• Diversion and History-Info for forwarded calls,
• Route and Record-Route,
• Max-Forwards,
• carrier- or tenant-specific headers.

Do not assume From is the carrier's only identity source. In many integrations, the carrier authorises the number using PAI while From remains the value presented to the user. Diversion is often important for forwarded calls too.

Watch number formats. The same number may appear as 0048..., +48..., a national format or a local format. If the dialplan normalises one leg but the carrier rule expects another format, the error can look like a carrier issue even though local translation caused it.

Move to SDP after confirming signalling#

SDP describes the media plan. The main fields are:

c=IN IP4 203.0.113.20
m=audio 24578 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=sendrecv

Check the address in c=, port in m=audio, transport profile, payload types, rtpmap mappings, sendrecv/sendonly/recvonly/inactive direction and DTMF parameters. WebRTC adds ICE, a DTLS fingerprint and candidates.

Compare the offer and answer. The answer should contain a common codec and a genuinely reachable media address. If the PBX anchors media, both endpoints should send RTP to it rather than directly to the other endpoint's private address.

Connect SIP to RTP and event timing#

When signalling looks correct, inspect RTP. In Wireshark, use Telephony → RTP → RTP Streams or filters for the selected addresses and ports. Ask:

• do packets flow in both directions,
• do source and destination match SDP,
• does the stream start after answer,
• are sequence numbers and timestamps continuous,
• is there loss, jitter or an SSRC change,
• does a firewall or NAT change the direction after a few seconds?

Timing matters. Disconnection at exactly 30–32 seconds often points to a missing ACK or failure of another in-dialog request to arrive. Disconnection at a specified Session-Expires leads to the refresher and re-INVITE/UPDATE. No audio from the outset more often indicates SDP, RTP routing or ACLs.

Compare a good call with a bad call#

For intermittent issues, compare working and failing examples with the most similar parameters possible. Do not compare only message order. List differences in:

• nodes and IP addresses,
• the selected gateway,
• number format,
• identity headers,
• SDP order and contents,
• the final codec,
• intervals between messages,
• termination reason,
• RTP directions and statistics.

A difference need not be the cause. A different gateway is a lead, but you still need to establish which property changes the outcome: routing, ACL, codec, headers or availability.

Finish with a verifiable RCA#

A good RCA separates facts, conclusions and actions. For example:

• Fact: the carrier returned 403 after receiving PAI containing an extension number.
• Fact: in a working call, PAI contains the assigned DID.
• Conclusion: identity transformation was not applied to the forwarded path.
• Correction: use a consistent PAI rule for direct and forwarded calls.
• Verification: repeat both scenarios and confirm PAI and the carrier response.
• Prevention: add a regression test or configuration check for new tenants.

This is more useful than “a header problem”. It supports implementing, verifying and preventing recurrence of the change.

SIP trace analysis checklist#

1. Define the symptom and expected outcome.
2. Collect the Call-ID and related dialogs.
3. Identify who generated each response.
4. Compare incoming and outgoing legs.
5. Verify routing, numbering and identity.
6. Analyse the SDP offer/answer.
7. Check RTP and time correlation.
8. Compare good and bad calls.
9. Express the RCA as facts, cause, correction and test.
10. Save evidence after the change is deployed.