Review recurring SIP response patterns
Look for changes in rejection and timeout patterns without treating every code as an incident.
From the blog
Incident & Troubleshooting Notes
Anonymised incident analyses and field notes showing how VoIP and telephony problems were investigated.
Read a SIP failure in message order
Use the complete request and response sequence to interpret a SIP code.
Prepare a SIP response-code change test
Define the expected response and call outcome before changing a SIP route or policy.
Review the layers that carry business calls
Check whether documented voice paths still match active switch, IP, DNS and call-service settings.
Use network layers to narrow a VoIP fault
Compare physical link, addressing, name resolution, signalling and media evidence before changing settings.
Map the voice call path before changing a network layer
Locate the device, network and application handoffs affected by a voice-network change.
What SIP 481 really means—and why a BYE can receive it
A SIP 481 response means the recipient cannot match a request to the dialog or transaction it expects. Use headers, timing and both call legs to find out why.
Why a SIP call drops after about 30 seconds
A repeatable drop near 30 seconds often points to a missing ACK or response-routing problem. Follow the transaction before changing session timers.
Ghost calls and phantom rings: prove what reached the phone
A phone that rings with no real caller may be receiving unsolicited SIP traffic, a PBX call or a local feature event. Capture the signalling before blocking blindly.
Where is the call being transcoded? How to prove it
Compare SDP and RTP on both call legs to establish where a codec changes instead of guessing from a single SIP offer.
Why a secondary DID rings briefly, then reaches carrier voicemail
When a secondary number rings an extension and then diverts to unexpected voicemail, the SIP call flow can identify which system took control.