A practical SIP trunk troubleshooting checklist

Calls are dropping. Or one-way audio. Or registration is fine but calls fail with 503. Sound familiar?

Here’s the checklist I work through, in order, when a SIP trunk between two carriers misbehaves.

1. Confirm the symptom

Before touching anything, get clarity:

• Is it 100% of calls or a subset?
• Is it inbound, outbound, or both?
• Did anything change recently — config, routing, peering, certificates?

The answer to these three usually narrows the problem to one layer.

2. Check signaling at the border

Capture SIP on the SBC. Tools I reach for:

• sngrep for live SIP visualization on Linux
• tshark -i any -Y sip for filtered captures
• The SBC’s own call trace (Genband, Audiocodes, etc.)

Look for: which side sends the BYE/CANCEL/4xx/5xx, where the timer expires, and whether INVITE/200 OK/ACK match up.

3. Walk the codec path

One-way audio is almost always RTP, not SIP:

• Are both sides advertising compatible codecs in SDP?
• Is the public IP/port in c= and m= correct, or are you seeing private addresses leak?
• Is the SBC doing media anchoring, or are you trusting the far end?

4. SS7/SMSC interconnect, if applicable

If the trunk hands off to a TDM/SS7 leg, you have to look at the cause codes too. ISUP cause 16 (normal clearing) tells you very little; cause 41 (temporary failure) and cause 102 (recovery on timer expiry) are the ones that usually point at the real problem.

5. Capacity and CAC

Before blaming the network, confirm the trunk isn’t simply hitting concurrent-call limits. Carriers love to throttle quietly.

---

If your specific scenario doesn’t fit this template, post it to the Community page with the SIP capture and I’ll have a look.