SIP Signaling From the Wire Up: Part 12 of 12
This is the reference post. Every section starts with a symptom, the thing the user or administrator is reporting, and works through the most likely SIP level causes, what you'd see in a trace, and where to look. If you're reading this at 10 PM while troubleshooting a ticket, jump straight to the symptom that matches and work from there.
One way audio
Symptom: The call connects. One party can hear the other, but not vice versa.
Most likely cause: NAT traversal failure. This is the single most common SIP problem in existence, and we covered it extensively in post 6.
What to look for in the trace: Pull the SDP from both the INVITE and the 200 OK. Check the c= lines. If either one contains a private IP address (10.x, 172.16 through 172.31, 192.168.x) and the other party is on a different network, that's your answer. The private address is unreachable from the remote end, so RTP in one direction has nowhere to go.
Also check whether SIP ALG is modifying the SDP. Capture on both sides of the router and compare. If the SDP changes as it passes through the NAT device, ALG is active and may be rewriting addresses incorrectly.
Less common causes:
- Firewall blocking RTP in one direction. RTP typically uses UDP on a range of high ports (often 10000 through 20000). If a firewall allows outbound UDP but blocks inbound UDP on those ports, only one direction of audio will work.
- Asymmetric routing. The SIP signaling takes one path and the RTP takes another, and the return path for RTP is blocked.
- Codec mismatch on one direction. Rare, but possible if one side is sending with a codec the other side didn't negotiate.
Fix: Disable SIP ALG on the router. Configure STUN on the phones or PBX. Ensure the firewall allows bidirectional UDP traffic on the RTP port range. If an SBC is available, use it.
No audio in either direction
Symptom: The call connects (both parties see the call as active on their phone displays), but neither party can hear anything. Complete silence.
Most likely cause: Same NAT and firewall issues as one way audio, but affecting both directions. This happens when both endpoints are behind NAT devices that aren't handling RTP correctly, or when a firewall is blocking all RTP traffic.
What to look for in the trace: Same SDP checks as one way audio, but verify both sides. If both c= lines show private addresses and both parties are on different networks, neither direction of RTP will work.
Also check for an RTP/SRTP mismatch. If one side negotiated SRTP (m=audio 49170 RTP/SAVP) and the other side negotiated plain RTP (m=audio 3456 RTP/AVP), the two sides are speaking different protocols. The encrypted side can't decode the unencrypted stream, and vice versa. In the SDP, look at the transport protocol on the m= line. Both sides need to match.
Another possibility: The c= line is set to 0.0.0.0. Some older hold implementations use this address, and a bug or misconfiguration might cause it to appear in the initial call setup SDP. An address of 0.0.0.0 means "don't send me any media," so both sides obey and nobody hears anything.
Calls dropping after exactly 30 seconds
Symptom: The call connects and audio works, but the call is automatically disconnected after approximately 30 seconds. The timing is very consistent. (For a deeper look at this specific issue, see Calls Dropping After a Set Time.)
Most likely cause: The ACK for the 200 OK never reached the callee. When the callee's phone sends a 200 OK to an INVITE, it starts a retransmission timer. If it doesn't receive an ACK within a certain period (which is typically around 32 seconds, based on the 64*T1 retransmission timeout for 2xx responses to INVITE per RFC 3261 Section 13.3.1.4), it assumes the 200 OK was never received and tears down the call.
What to look for in the trace: Capture on the callee's side. You should see the 200 OK being sent, then retransmitted several times at increasing intervals, and then a BYE after the timer expires. If the ACK isn't appearing in the capture at the callee's end, something is blocking it. Check the proxy or SBC in between. The ACK might be routed differently than the original INVITE (since ACK for 2xx responses can be sent directly end to end rather than through the proxy), and a firewall might block the direct path.
Another possibility: SIP session timers. If the call has session timer headers (Session-Expires, Min-SE), both sides agree to periodically refresh the session with a re-INVITE or UPDATE. If the refresh fails (the re-INVITE is blocked or the response is lost), the session timer expires and the call drops. The timing would match the Session-Expires value in the headers, which might or might not be 30 seconds (common values are 90, 1800, or 3600 seconds).
Phone shows "not registered" or calls go straight to voicemail
Symptom: The phone doesn't ring for incoming calls. The display may show a registration error, or it may appear normal while incoming calls go to voicemail or get a "user not available" message.
Most likely cause: Registration failure. The phone either can't register at all or its registration has expired without being renewed.
What to look for in the trace: Filter for REGISTER messages from the phone's IP. You should see the registration sequence: REGISTER, 401, REGISTER with Authorization, 200 OK. If you see REGISTER going out but no response coming back, the messages aren't reaching the server or the responses aren't reaching the phone. Firewall or routing issue.
If you see the 401 challenge/response cycle repeating without ever getting a 200 OK, the credentials are wrong. Compare the username in the Authorization header against what's configured on the server.
If registration appears to succeed (you see a 200 OK) but the phone still can't receive calls, the problem might be a stale NAT mapping. The phone registered successfully, the server recorded the Contact address, but the NAT mapping between the phone's private address and its public address has expired. When the server tries to route an inbound call to the Contact address, the NAT device has no mapping for that traffic and drops it. Look at the time between registrations and compare it against the NAT device's UDP timeout. If the registration interval is longer than the NAT timeout, reduce the registration interval or enable SIP keep alives.
Also check DNS. If the phone is configured with a domain name for the registrar and DNS resolution is failing, no REGISTER will be sent at all. The phone's own logs (not the SIP trace) will show a DNS error in this case.
Call connects but immediately disconnects
Symptom: The phone rings, the callee answers, and the call drops within a second or two. Sometimes the callee hears a brief click before silence.
Most likely cause: The 200 OK from the callee triggered a process on the proxy or SBC that immediately terminated the call. This can happen due to a routing loop where the INVITE is being forwarded back to the originator, a policy rejection at a proxy that happens post-answer, or a TLS handshake failure on a downstream leg.
What to look for in the trace: Find the 200 OK and then look at what immediately follows. If there's a BYE within seconds of the 200 OK, check who sent the BYE and why. If the proxy sent it, the proxy's logs will typically explain the reason (loop detected, policy violation, license limit reached).
Also check for a 408 timeout on a related transaction. Some PBX systems set up multiple legs simultaneously (for example, ringing the desk phone and the mobile app at the same time). If one leg answers but the PBX can't properly cancel the other leg, it might tear down the whole call.
Echo or feedback
Symptom: One or both parties hear their own voice echoed back with a slight delay, or there's a hollow, reverberant quality to the audio.
What this has to do with SIP: Echo is primarily an audio path problem, not a signaling problem, but the SDP negotiation can contribute.
If the negotiated codec has a long packetization time (check a=ptime in the SDP), echo becomes more noticeable because each audio frame covers a longer duration and the jitter buffer adds more delay. Longer delay means the echo return path is longer, which makes echo more perceptible. Reducing ptime from 30 to 20 milliseconds can help.
If the call traverses a gateway between VoIP and the traditional phone network, the gateway's echo cancellation might be insufficient. Hybrid echo occurs at the 2-wire to 4-wire conversion point in the PSTN, and if the gateway's echo canceller isn't properly calibrated, the echo leaks through to the VoIP side.
Acoustic echo is caused by audio from the phone's speaker being picked up by its microphone, which is entirely a hardware problem. Speakerphones are the worst offenders. The SDP can't cause or fix this.
What to check in the trace: The codec and ptime negotiated in SDP. If one side is using a ptime of 30 or higher, try reducing it. If the call goes through a PSTN gateway, the gateway's echo cancellation settings are the more likely culprit than anything in the SIP signaling.
Caller ID not displaying correctly
Symptom: The callee sees the wrong caller ID, no caller ID, or "unknown" instead of the expected name and number.
What to look for in the trace: SIP carries caller identity in multiple places, and different systems look at different headers:
From header is the basic SIP identity. This is what the calling phone sets, and it can be set to anything. Many PBX systems allow administrative control over the From header on outbound trunk calls.
P-Asserted-Identity is an identity asserted by a trusted intermediary. The SIP trunk provider or PBX adds this header to attest that the caller identity has been verified. Some carriers use this for caller ID display.
Remote-Party-ID is an older header that serves a similar purpose to P-Asserted-Identity. Some systems still use it.
From: "Main Office" <sip:[email protected]>;tag=as1234
P-Asserted-Identity: <sip:[email protected]>
Remote-Party-ID: <sip:[email protected]>;screen=yes;party=calling
If the outbound caller ID is wrong, check what your PBX is putting in the From header and the P-Asserted-Identity header (if present). If the PBX is sending the right number but the far end sees something different, the SIP trunk provider's SBC might be overriding it with whatever number is on file for your account. Contact the trunk provider and verify what caller ID they're configured to present for your trunk.
For inbound calls where caller ID isn't showing, check the From header in the incoming INVITE. If the From contains just a number (no display name), the callee's phone might display just the number. Caller name (CNAM) lookup is a separate process from SIP and is handled by the terminating carrier or a CNAM database lookup. The name you see (or don't see) for incoming calls is often not in the SIP message at all.
Transfers failing
Symptom: When a user tries to transfer a call, the transfer fails. The original caller might get disconnected, or the transfer might not complete and the caller stays connected to the original agent.
What to look for in the trace: Find the REFER message. If there's no REFER in the trace, the phone isn't sending one, which could be a phone configuration issue or the phone doesn't support REFER.
If the REFER is sent, look for the response. A 202 Accepted means the transfer is being attempted. A 405 Method Not Allowed means the receiving end doesn't support REFER. A 403 means the transfer was rejected by policy.
After the 202, look for NOTIFY messages. These report the progress of the transfer. The NOTIFY body contains a SIP response code indicating what happened when the transferred party tried to connect to the transfer target. A NOTIFY containing "SIP/2.0 200 OK" means the transfer succeeded. A NOTIFY containing "SIP/2.0 486 Busy" means the transfer target was busy. A NOTIFY containing "SIP/2.0 408 Request Timeout" means the transfer target didn't answer.
If the REFER and NOTIFY sequence looks correct but the call still drops, the issue might be in the Replaces header for attended transfers. The Replaces header tells the transfer target which existing call leg to replace. If the Replaces header is malformed or the target doesn't support it, the transfer fails even though the SIP mechanics appeared to work.
Transfers across different PBX platforms or through SBCs that don't properly relay REFER are a common pain point. If you're seeing consistent transfer failures between two specific systems, it's likely an interoperability issue with how those systems handle REFER and Replaces.
Call quality degrades at specific times
Symptom: Calls work fine in the morning but develop choppy audio, delays, or dropouts in the afternoon.
This is typically not a SIP problem. The SIP signaling for a call established at 9 AM and a call established at 3 PM looks identical. The difference is in the network conditions when the RTP audio is flowing. This is an ISP congestion issue, a local network saturation issue, or a QoS configuration issue, all of which are covered in the other blog series.
However, there's one SIP adjacent thing to check. If your PBX is transcoding (converting between codecs on different call legs), heavy call volume during peak hours increases the transcoding load on the PBX. A PBX that handles 10 transcoded calls fine in the morning might struggle with 40 at peak. Check the PBX's CPU usage during the problem periods and compare the codecs on the internal versus trunk SDP to see if transcoding is involved.
Where to go from here
If you've made it through this entire series, you now have a working understanding of SIP signaling from the protocol fundamentals through practical troubleshooting. You can read a SIP message, follow a call flow, understand registration, SDP negotiation, NAT traversal, and the security model. You know what tools to use and what to look for when something breaks.
The next step is practice. The next time a call has a problem, capture the traffic. If the capture feels overwhelming, Reading a SIP Trace Without Losing Your Mind covers how to filter out the keep-alive noise and isolate the one call that matters. Look at the SIP messages, or upload a capture to the SIP call stories tool for a plain-English breakdown of what happened. Compare what you see against what you now know a normal call looks like. Each real world problem you work through reinforces the concepts and builds pattern recognition that makes you faster at finding the root cause.
SIP is a deep protocol with a lot of extensions, edge cases, and vendor specific behaviors that go beyond what any single series can cover. But the fundamentals covered here are the foundation that everything else builds on, and they'll serve you well in the vast majority of real world troubleshooting situations.
This is the final post in the SIP Signaling From the Wire Up series. If you're looking for more foundational VoIP knowledge, the VoIP From the Ground Up series covers voice technology from the basics. If your investigation points to the internet connection as the problem, the Getting the Internet Right series covers business internet selection and evaluation.
Share
Want to know when we publish new articles? Sign up for updates