Reading any SIP failure
Four habits that shorten most investigations, whatever the code turns out to be.
The status code says who gave up, not why
A final response is a verdict, and the evidence is upstream of it. The useful message is nearly always the last request before the failure — the offer that could not be answered, the INVITE nobody replied to, the re-INVITE that changed something. Read backwards from the code, not forwards.
Work out which box actually generated the response
A 4xx that your SBC produced locally and a 4xx it relayed from the carrier are
completely different faults with the same three digits. Compare the Via stack on the
response with the one on the request, look at whether the response carries the far
end's User-Agent or Server header, and check whether the
timing is plausible for a round trip to the network at all. A rejection that comes
back in two milliseconds did not travel anywhere.
Absence of packets is evidence
Silence has a shape. Six retransmissions and nothing back means the far end never saw the request or could not answer it; a prompt 100 Trying followed by three minutes of nothing means it did see it and got stuck. Both are hard facts, and neither one is visible if you only read the messages that exist.
Signalling success is not media success
200 OK and ACK prove the two ends agreed on a description of the media. They prove nothing about whether a single RTP packet made it. When the complaint is audio, the SIP is context and the media is the case.
hiccup does this pass over a capture for you: it pairs the two legs across the B2BUA, collapses retransmissions into one row with a reason attached, and names the box that made the decision. Self-hosted, free for individual users.
upload a trace