Live Demo

See how SIPSymposium reads a SIP trace

Three real-world scenarios that VoIP engineers see every week — analyzed by SIPSymposium with severity-ranked findings and concrete recommendations. No signup needed to view.

These are pre-rendered example outputs. Sign up to run analyses on your own traces.

Endpoint A — PBX (10.0.4.21)
SIP/UDP · 14 messages
14:23:45.103 PBX→Carrier INVITE sip:+15551234567@carrier.example.net SIP/2.0 Call-ID: 8a7f3-2b91-pbx@10.0.4.21 CSeq: 1 INVITE Via: SIP/2.0/UDP 10.0.4.21;branch=z9hG4bK-7d2a From: <sip:+15550009999@pbx.local>;tag=ab12cd To: <sip:+15551234567@carrier.example.net> Contact: <sip:10.0.4.21:5060> Max-Forwards: 70 14:23:45.247 Carrier→PBX SIP/2.0 100 Trying 14:23:46.892 Carrier→PBX SIP/2.0 180 Ringing 14:23:51.318 Carrier→PBX SIP/2.0 200 OK Contact: <sip:carrier-edge-3.example.net:5060> Record-Route: <sip:carrier-edge-3.example.net:5060;lr> [ no ACK observed from PBX ] 14:23:51.818 Carrier→PBX 200 OK retransmit #1 (T1=500ms) 14:23:52.818 Carrier→PBX 200 OK retransmit #2 (1s) 14:23:54.818 Carrier→PBX 200 OK retransmit #3 (2s) 14:23:58.818 Carrier→PBX 200 OK retransmit #4 (4s) 14:24:02.818 Carrier→PBX 200 OK retransmit #5 (4s) 14:24:06.818 Carrier→PBX 200 OK retransmit #6 (4s) 14:24:23.812 Carrier→PBX BYE sip:10.0.4.21:5060 SIP/2.0 Reason: SIP;cause=408;text="ACK Timeout (Timer F)" CSeq: 1 BYE
Analysis findings
3 issues
Calls connect successfully but consistently drop at ~32 seconds. The root cause is a missing ACK after 200 OK, triggering Timer F expiry at the carrier. Outbound signaling never reaches the carrier — almost certainly asymmetric routing or firewall egress for in-dialog requests.
2 Critical
1 Warning
Critical
Missing ACK after 200 OK — Timer F expiry (RFC 3261 §17.2.1)
At 14:23:51.318 the carrier sent 200 OK accepting the INVITE. No ACK was received within the Timer F window of 32 seconds (T1×64 with T1=500ms). The carrier retransmitted 200 OK 6 times using exponential backoff per RFC 3261. At 14:24:23.812 the carrier terminated the dialog with a BYE carrying Reason: SIP;cause=408 — this 32.5-second gap is the diagnostic fingerprint of ACK timeout, not a network or carrier-side failure.
Critical
ACK never leaves the PBX environment — asymmetric routing or firewall egress
The 200 OK arrived via the Record-Route path through carrier-edge-3.example.net. Per RFC 3261 the PBX must send ACK to that Record-Routed target, not the original carrier address. The absence of any ACK in the trace combined with the carrier's continued retransmission indicates the ACK is either:
  • Being sent to the wrong destination (PBX ignoring Record-Route), or
  • Being blocked at the PBX firewall outbound rules for in-dialog requests, or
  • Failing to traverse a NAT pinhole that wasn't established for the egress flow
Warning
Contact header advertises RFC 1918 private address
The PBX's Contact: <sip:10.0.4.21:5060> exposes a private LAN address to the carrier. Even after the ACK routing is fixed, this Contact prevents in-dialog requests from the carrier (re-INVITE, UPDATE, BYE) from reaching the PBX directly — they will rely entirely on the Record-Route path. Recommend an SBC or border element that rewrites Contact to the public-facing address.
Recommendation
Next diagnostic steps
  • Verify firewall egress rules allow outbound UDP/5060 from the PBX subnet to the carrier's signaling network for in-dialog traffic, not just INVITEs.
  • Capture at the public-side interface to confirm whether ACK leaves the PBX environment at all.
  • If ACK is leaving but not arriving, suspect Record-Route handling — verify the PBX honors the Route set when sending in-dialog requests.
Endpoint A — PBX (192.168.1.15)
SIP + RTP · 30s capture
14:11:02.118 PBX→Carrier INVITE sip:+15551112222@carrier.example.net SIP/2.0 Call-ID: 3e9c1-87a4-pbx@192.168.1.15 Contact: <sip:192.168.1.15:5060> Content-Type: application/sdp v=0 o=PBX 12345 12345 IN IP4 192.168.1.15 s=Call c=IN IP4 192.168.1.15 ← private (RFC 1918) address t=0 0 m=audio 16384 RTP/AVP 0 8 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=sendrecv 14:11:02.244 Carrier→PBX SIP/2.0 200 OK Contact: <sip:carrier-media-1.example.net:5060> v=0 o=Carrier 67890 67890 IN IP4 203.0.113.42 c=IN IP4 203.0.113.42 m=audio 10000 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=sendrecv 14:11:02.391 PBX→Carrier ACK ───────────── RTP flow analysis ───────────── 14:11:02.41814:11:32.418 PBX→203.0.113.42:10000 1,500 RTP packets (PCMU, 50pps × 30s) 203.0.113.42→PBX 0 RTP packets received 14:11:32.500 User reports: "I can hear them, they can't hear me" (direction inverted from PBX perspective — PBX hears them, they don't hear PBX)
Analysis findings
3 issues
Classic one-way audio caused by SDP advertising a private IP as the RTP destination. Signaling completes successfully but the carrier cannot route media to 192.168.1.15 across the public internet. The PBX is not aware of its public-facing NAT address.
2 Critical
1 Warning
Critical
One-way RTP — 1,500 packets sent, 0 packets received
Outbound RTP to 203.0.113.42:10000 shows 1,500 packets over 30 seconds, matching the expected G.711µ rate of 50pps. Inbound RTP at the PBX listener (192.168.1.15:16384) shows zero packets. This is unambiguously one-way audio in the carrier→PBX direction.
Critical
SDP c= line advertises private (RFC 1918) IP as the media endpoint
The INVITE's SDP c=IN IP4 192.168.1.15 specifies a private LAN address as the carrier's destination for RTP. The carrier cannot route packets to this address across the public internet — they will be discarded at the first public router. Root cause: the PBX is not configured with its public NAT address and is using its private interface IP in SDP.
Warning
No evidence of carrier-side symmetric RTP latching
Some carriers and SBCs latch onto the source IP:port of inbound RTP and send return traffic there regardless of SDP. The absence of any return RTP suggests this carrier does not latch by default, or the latching window has expired. Latching is not a substitute for correct SDP — Teams Direct Routing, many tier-1 carriers, and a number of cloud SBCs explicitly do not latch.
Recommendation
Fixes in order of preference
  • Configure the PBX with its public IP/NAT address — Asterisk: externaddr / externhost; FreeSWITCH: ext-rtp-ip / ext-sip-ip; FreePBX: NAT settings under SIP Settings.
  • Deploy an SBC or media gateway that performs SDP rewriting and bidirectional RTP relay (rtpengine, RTPProxy, AudioCodes Mediant, Ribbon SWe).
  • Verify the upstream firewall allows inbound UDP on the negotiated RTP port range from the carrier's media network.
Endpoint A — SBC (sbc.contoso.com)
Teams Direct Routing leg
09:42:18.205 SBC→Teams INVITE sip:+15553334444@sip.pstnhub.microsoft.com SIP/2.0 Call-ID: 4f1e8-2c93-sbc@sbc.contoso.com CSeq: 1 INVITE Via: SIP/2.0/TLS sbc.contoso.com:5061;branch=z9hG4bK-9e From: <sip:+15554445555@contoso.com>;tag=user1 To: <sip:+15553334444@sip.pstnhub.microsoft.com> Contact: <sip:sbc.contoso.com:5061;transport=tls> Content-Type: application/sdp v=0 o=- 1 1 IN IP4 sbc.contoso.com c=IN IP4 sbc.contoso.com t=0 0 m=audio 7050 RTP/SAVP 18 8 0 ← payload type 18 = G.729 a=rtpmap:18 G729/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:0 PCMU/8000 a=fmtp:18 annexb=no a=sendrecv 09:42:18.412 Teams→SBC SIP/2.0 488 Not Acceptable Here Reason: Q.850;cause=88;text="Incompatible destination" Warning: 305 sip.pstnhub.microsoft.com "Incompatible codec" Content-Length: 0 09:42:18.518 SBC→Teams ACK ───────────── Pattern across 24h ───────────── Outbound to Teams DR (+15553334444): 94% — 488 Not Acceptable Inbound from Teams DR: 98% — 200 OK / completes
Analysis findings
3 issues
The SBC is offering G.729 as the preferred codec on the Teams Direct Routing leg. Teams DR does not support G.729 on the SIP trunk and is rejecting the offer with 488. The asymmetry (inbound works, outbound fails) is the classic signature.
1 Critical
2 Warning
Critical
Codec offer incompatible with Teams Direct Routing
The SBC's m=audio line lists payload types 18 8 0 — G.729 first, then G.711A and G.711µ. Microsoft Teams Direct Routing accepts only SILK and G.711 (A-law / µ-law) on the SIP trunk leg. G.729 is explicitly not supported, and Teams will reject the entire offer with 488 when G.729 is in the codec list and the SBC is not transcoding upstream. The 488 response includes Warning: 305 "Incompatible codec", which is Microsoft's specific signal for codec rejection.
Warning
SILK not offered — suboptimal call quality even after fix
Teams prefers SILK on the trunk side for its quality-vs-bandwidth profile. The SBC's offer doesn't include SILK at all. Even after removing G.729 and resolving the 488s, calls will fall back to G.711 (64 kbps, no PLC benefit) instead of SILK (typically 24 kbps adaptive, with built-in concealment).
Warning
annexb=no on G.729 — silence suppression disabled
Independent of the codec rejection, the fmtp:18 annexb=no parameter disables G.729 Annex B (VAD/CN). This is unusual for Teams interop configurations and may indicate the SBC's codec profile is configured for a different downstream environment that was carried over without adjustment.
Recommendation
Fixes
  • On the SBC, remove G.729 from the codec list offered toward Teams (audio codec profile / media profile on the Teams gateway).
  • Add SILK if your SBC supports it on the Teams leg — AudioCodes Mediant 7.40+, Ribbon SWe 11.0+, and most modern SBCs support it.
  • If G.729 is required for legacy PBX endpoints on the LAN side, configure SBC transcoding (G.729 ↔ G.711µ or SILK) between the LAN and Teams legs.
  • Verify against the currently-certified SBC firmware list at learn.microsoft.com/microsoftteams/direct-routing-border-controllers.

Now do this with your trace.

SIPSymposium accepts raw SIP, PCAP files, or natural-language scenario descriptions and returns the same analysis depth shown above.