SIP Interoperability Troubleshooting Guide: Codecs, DTMF, SIP Headers, and One-Way Audio (15 Common Failures)
A practical SIP interoperability field guide: isolate signaling vs media, read SDP quickly, prove codec/DTMF behavior in pcaps, and fix one-way audio using repeatable symptom → test → fix checklists.
SIP interoperability is rarely “SIP is broken.” In practice, many failures come from mismatched expectations between carriers, SBCs, PBXs, and contact centers across four planes: signaling (SIP), media (RTP), identity (caller ID/forwarding headers), and policy (timers, transports, NAT behavior, security requirements). This guide is a practical workflow and a field checklist: symptom → probable cause → quick test → fix.
SIP interoperability in practice: what “interop” really means
SIP is flexible by design. Two systems can be RFC-aligned yet still disagree on optional behaviors, defaults, or mid-call handling. That’s why “it works with Provider A but not Provider B” is common—behavior is often carrier/vendor-dependent, and networks normalize/enforce different rules.
The four planes that must agree: signaling, media, identity, and policy
Signaling (SIP): INVITE/200 OK/ACK, routing (Via/Route/Record-Route), dialog maintenance (CSeq), authentication, transports (UDP/TCP/TLS).
Media (SDP/RTP): codec offer/answer, RTP IP/port reachability, DTMF method, SRTP requirements (if used), symmetric RTP behavior.
Identity: what the called party sees and what upstream trusts (From, P-Asserted-Identity, Diversion, History-Info, etc.). This often matters most on inbound DIDs and forwarded calls; see global DID setup and porting considerations.
Policy: session timers, early media rules, hold/resume, transfer behavior, NAT/firewall pinholes, SIP ALG interference.
A 60-second diagnostic mindset: is it failing at INVITE, SDP, or RTP?
Call setup fails (no ringing, immediate hangup): focus on SIP responses (4xx/5xx), auth, routing, dial plan, transport/TLS.
Call connects but audio is wrong (one-way, no audio, no DTMF): focus on SDP (c=/m=), RTP reachability, payload types, NAT/firewall/ALG.
Features break mid-call (hold, transfer, IVR DTMF): focus on re-INVITE/UPDATE/REFER behavior and timers.
Before you troubleshoot: collect the minimum evidence
Interop tickets stall when evidence is incomplete. Capture both the SIP ladder (with SDP) and enough RTP to show whether packets were sent/received and where they were sent.
What to capture: SIP ladder + SDP + RTP (pcap) and device/SBC logs
Packet capture from the edge closest to the problem (often the SBC external and internal legs). Include SIP + RTP where feasible.
Call detail/logs from SBC/PBX (cause codes, selected codec, DTMF mode, RTP stats if available).
Time window: commonly at least 10 seconds before INVITE through hangup, plus a few seconds of RTP after answer.
The 5 fields you should always read first
Call-ID (correlate legs and logs).
CSeq (find the latest offer/answer; re-INVITEs matter).
Via / Contact (routing/return path; NAT clues).
SDP c= and m= lines (where RTP is advertised and on which port).
Actual RTP source/destination IP:port (what media actually did on the wire).
How SIP/SDP negotiation works (only what you need to debug interop)
SIP sets up the dialog; SDP negotiates media. The codec list is necessary but not sufficient—SDP also carries parameters that can cause “connects but no media” outcomes even when codec names overlap.
Offer/answer and why both sides can be “correct” and still not talk
Offer (often in INVITE) lists supported codecs/payload types and the RTP address/port to receive media.
Answer (often in 200 OK) selects a codec (or a subset) and returns its own RTP address/port to receive media.
Common failure mode: each side sends RTP to the address/port in the latest SDP it received. If that SDP contains an unroutable/private IP, a blocked port, or a stale media target (after a re-INVITE/UPDATE), you can see no-audio or one-way audio.
Mini SDP example (annotated)
c=IN IP4 198.51.100.10
m=audio 22000 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20c=: the IP address where this side expects to receive RTP for this media section.
m=audio: the media type and UDP port (here 22000) where this side expects to receive RTP, plus the offered payload types.
a=rtpmap ... telephone-event: maps a (often dynamic) payload type to RFC2833/4733 DTMF events; payload number (e.g., 101) is negotiated per call.
a=fmtp: format parameters for a payload type; for telephone-event, 0-15 commonly means digits 0–9 plus related events.
a=ptime: packetization time in milliseconds (e.g., 20ms audio frames per RTP packet), which can be strict or flexible depending on endpoints/carriers.
When re-INVITE/UPDATE matters: hold/resume, transfer, and mid-call changes
Hold often changes SDP direction (e.g., a=sendonly/recvonly/inactive) and/or changes the m= port.
Mid-call NAT changes can require symmetric RTP or media anchoring; otherwise audio can fail after a re-INVITE/UPDATE.
UPDATE vs re-INVITE support varies by product/carrier policy; if one side expects UPDATE for SDP refresh and the other rejects it, media may not update as intended.
Codec negotiation: common failure patterns and fixes
Codec issues can show up as fast-busy, immediate hangup after answer, or “connects but silence,” depending on endpoint behavior and carrier policy when media can’t be decoded.
Mismatch vs incompatibility: overlap can still fail
No overlap: INVITE offers codecs A/B; answer can’t accept any. Often results in 488 Not Acceptable Here (or functionally similar behavior).
Dynamic payload type confusion: for RTP/AVP, dynamic payload numbers (96–127) are locally assigned. If SDP mapping (a=rtpmap) is missing or altered by an intermediary, one side can misinterpret payload 101 (a common DTMF/telephone-event failure pattern).
fmtp/ptime mismatches: the codec matches, but parameters don’t. Some systems are strict about ptime/maxptime or codec fmtp depending on the codec and implementation.
Transcoding vs normalization: when an SBC should rewrite SDP or transcode
SDP normalization (rewrite/strip/limit) is often enough: enforce a known codec order, remove unsupported codecs, align ptime, ensure telephone-event is present.
Transcoding is best treated as a policy choice: it can connect islands with no shared codec, but adds complexity and can introduce quality/latency trade-offs depending on implementation and load.
DTMF interoperability: RFC2833/4733 vs SIP INFO vs in-band
“DTMF not working” is a common interop problem because it breaks IVRs, payments, and contact-center routing. The core issue: the far end must receive DTMF in the method it expects, and your network must preserve it end-to-end.
Decision tree (practical)
Telephone-event (RFC2833/4733): commonly used for SIP trunks and IVRs. DTMF is sent as RTP events. Look for a=rtpmap:101 telephone-event/8000 (payload may vary) and a=fmtp:101 0-15.
SIP INFO: DTMF is carried in SIP messages mid-call. This can work when all intermediaries and endpoints support/allow it, but behavior is often carrier/vendor-dependent and can be blocked by policy or B2BUA handling.
In-band: tones carried inside the audio codec. This is often most reliable with uncompressed codecs (e.g., G.711). It can fail with compression, packet loss, transcoding, or aggressive audio processing.
What “DTMF not working” looks like in SDP/RTP (how to prove it)
Quick test: in the SDP offer/answer, confirm telephone-event is negotiated (present on both sides) and note its payload type.
RTP proof: in a pcap, filter RTP and confirm packets with the telephone-event payload are present when keys are pressed.
SIP INFO proof: check for INFO messages during keypress and whether they get 200 OK (or are rejected/unsupported).
SIP headers that commonly break interop (and what they’re used for)
Headers can break calls indirectly: they affect routing, identity presentation, and policy decisions in carriers/SBCs. Normalization at the SBC is often the practical approach, but results can be carrier/vendor-dependent—validate with test calls for each route/region.
Routing and dialog: Via, Record-Route/Route, Contact
Via: where responses should go. NAT can cause Via to advertise a private address; some devices rely on rport/received parameters to recover.
Contact: where subsequent in-dialog requests should be sent. If Contact contains an unreachable IP/port, mid-call requests (re-INVITE/BYE) may fail, causing dropped calls or “BYE can’t get through” symptoms.
Record-Route/Route: keeps proxies/SBCs in the signaling path. Missing or inconsistent route sets can cause re-INVITEs/REFER to bypass the SBC, which often breaks mid-call features and sometimes media updates.
Caller identity and forwarding: PAI/RPID, Diversion, History-Info
From: user-presented identity; may be rewritten by policy.
P-Asserted-Identity (PAI): trusted network-provided identity (commonly used in SIP trunking). Some carriers require PAI for trusted caller ID; others ignore it or apply different rules.
Remote-Party-ID (RPID): legacy identity header still seen in some interop scenarios.
Diversion / History-Info: call forwarding/redirect history. Misformatting can break forwarded CLI display or routing logic in downstream systems.
The Field Guide: 15 top SIP interoperability failures (symptom → cause → quick test → fix)
Use this as a triage checklist. The “quick test” items are intentionally pcap/log-friendly and vendor-neutral.
Call setup and routing failures
1) Symptom: INVITE gets 401/407 repeatedly.
Probable cause: auth realm/username mismatch; digest not accepted; wrong IP-based auth expectation.
Quick test: confirm Authorization header appears after challenge; check realm and username in logs.
Fix: align auth method (IP auth vs digest), credentials, realm; ensure SBC presents correct source IP if IP-auth is used.2) Symptom: 404/484/488 on outbound calls.
Probable cause: dial plan/URI format mismatch (E.164 vs national), missing “+”, wrong Request-URI domain, codec policy rejects offer (488).
Quick test: inspect Request-URI and To; check response reason; for 488 inspect SDP in INVITE.
Fix: normalize called number format; adjust routing domain; limit codec list to accepted set.3) Symptom: Calls connect then immediately drop (BYE right after 200 OK).
Probable cause: missing ACK (signaling path issue), session timer mismatch, early media expectations, or policy rejecting identity.
Quick test: confirm ACK reaches the answering side; check for 408/481/422/Session-Expires behavior.
Fix: fix routing (Record-Route), adjust session timers (Min-SE/Session-Expires), ensure ACK traversal; normalize identity headers if policy-driven.4) Symptom: Works over UDP but fails over TLS (or vice versa).
Probable cause: transport mismatch; certificate trust/SNI expectations; firewall blocks TCP/TLS ports.
Quick test: confirm SIP transport in Via/Contact; check TLS handshake logs; verify ports reachable. Also review TLS/SRTP and security prerequisites for baseline requirements to validate.5) Symptom: Inbound calls never reach PBX/contact center.
Probable cause: registration/contact wrong, NAT contact not reachable, routing to stale Contact, wrong inbound DID mapping.
Quick test: check REGISTER Contact and expires (if used); verify carrier sends to expected IP/port; review DID mapping logs and any number provisioning steps (see global DID setup and porting considerations).
Fix: use static trunking where possible; ensure correct public Contact; pin signaling through SBC with appropriate Contact rewriting.
Media failures (no audio, one-way audio, early media)
6) Symptom: One-way audio (you hear them, they can’t hear you—or the reverse).
Probable cause: one RTP direction is missing or misrouted (bad SDP, NAT/firewall issue, asymmetric routing), or media is anchored on one leg but not the other.
Quick test: explicitly label directions and verify RTP presence on each leg:
A→B audio missing: do you see RTP leaving A toward B’s SDP target (destination IP:port)? Do you see RTP arriving at B?
B→A audio missing: do you see RTP leaving B toward A’s SDP target? Do you see RTP arriving at A?
Do not assume symmetry—prove RTP transmit/receive separately on both legs (inside and outside SBC if applicable).7) Symptom: No audio both ways but call stays up.
Probable cause: RTP blocked both directions; SRTP mismatch; SDP advertises 0.0.0.0 or wrong interface; ICE attributes unsupported in this path.
Quick test: is any RTP seen on either leg? Does SDP show valid c= address and non-zero m= port? Are there crypto lines (if SRTP is expected)?
Fix: open RTP, anchor media at SBC, align SRTP policy (require/allow/disable) across legs; validate baseline network readiness for VoIP (latency, jitter, packet loss) to avoid chasing signaling when it’s transport.8) Symptom: No ringback / no early media on inbound or outbound calls.
Probable cause: early media blocked (183 with SDP not passed), PRACK/100rel expectations differ, policy forces local ringback.
Quick test: look for 183 Session Progress with SDP; does RTP arrive before 200 OK? Any Require: 100rel / PRACK exchange?
Fix: allow/relay early media; align 100rel/PRACK settings; ensure SBC doesn’t strip 183 SDP when needed.9) Symptom: Audio works, then dies after hold/resume.
Probable cause: re-INVITE changes SDP address/port; firewall pinholes expire; mid-call signaling bypasses SBC due to routing headers.
Quick test: compare SDP before/after hold; verify re-INVITE/UPDATE reaches both sides; check Record-Route/Route set consistency.
Fix: keep SBC in the signaling path (Record-Route), increase NAT binding keepalives, anchor media, refresh pinholes. A reference model helps; see SIP trunking architecture and SBC placement.10) Symptom: Audio clips every few seconds; “robotic” complaints only on some routes.
Probable cause: packet loss/jitter, ptime mismatch (too large for the path), transcoding overload, or QoS not consistently enforced across the WAN.
Quick test: RTP stats (loss, jitter); confirm negotiated ptime; check whether transcoding is engaged; compare across routes/carriers.
Fix: enforce a ptime aligned to your environment (20ms is common but not universal), avoid unnecessary transcoding, validate network readiness for VoIP (latency, jitter, packet loss) and QoS end-to-end.
DTMF and feature failures
11) Symptom: DTMF doesn’t work in IVR, but audio is fine.
Probable cause: wrong DTMF method; telephone-event not negotiated; payload type mismatch; in-band used with compressed codec.
Quick test: in SDP, confirm telephone-event present and agreed; in RTP, confirm events present while pressing keys.
Fix: commonly standardize on RFC2833/4733 for trunks; ensure telephone-event passes end-to-end; use G.711 if forced to in-band.12) Symptom: DTMF works one direction only (agent-to-IVR works, customer-to-IVR fails).
Probable cause: asymmetric DTMF handling on one leg; SBC rewriting only one direction; contact center expects INFO but trunk sends telephone-event (or vice versa).
Quick test: check negotiated DTMF method on both legs; confirm RTP events or INFO appear on the failing direction.
Fix: normalize DTMF method at the SBC and ensure both legs use the same approach (or translate if your SBC supports it).13) Symptom: Blind/attended transfer fails (REFER rejected or call drops).
Probable cause: REFER not supported/allowed; Replaces handling differs; signaling route bypasses SBC mid-call.
Quick test: find REFER in ladder; look for 403/405/481; verify in-dialog requests follow the same route set.
Fix: enable/allow REFER where required; keep SBC in path; consider server-side transfer (PBX/B2BUA) when the far end won’t accept REFER.14) Symptom: Calls drop around a consistent time (e.g., ~15 or ~30 minutes).
Probable cause: session timers (Session-Expires/Min-SE) refresh failing; re-INVITE/UPDATE not delivered; NAT binding timeout for RTP/RTCP.
Quick test: inspect Session-Expires headers; look for refresh re-INVITE/UPDATE and responses; check NAT timeout settings.
Fix: align session timer values and refresher role; ensure refresh messages traverse correctly; add keepalives.15) Symptom: Caller ID is wrong/missing on forwarded calls or inbound DIDs; identity inconsistent across carriers.
Probable cause: PAI/RPID/Diversion/History-Info formatting or policy mismatch; upstream requires trusted identity header and rejects From-based CLI.
Quick test: compare From vs PAI; check Diversion/History-Info presence and syntax; observe carrier response or CLI result.
Fix: define an identity policy: when to pass PAI, when to rewrite From, how to format Diversion/History-Info; test per downstream carrier expectations.
One-way audio deep dive (most searched problem)
“One way audio SIP” is commonly not a SIP problem—it’s an SDP/RTP reachability problem. The fastest isolation is to answer three questions per direction: (1) is RTP being sent, (2) is it being sent to the right IP/port from the peer’s SDP, and (3) is it arriving on the other side?
Fast isolation checklist (pcap-driven)
Step 1: Identify call legs (e.g., PBX↔SBC-internal and SBC-external↔carrier). For a model of where RTP should be anchored, see SIP trunking architecture and SBC placement.
Step 2: In the latest SDP on each leg, write down the media target you should send to: remote c= IP and m=audio port.
Step 3: Verify RTP send and receive separately for each direction:
Direction A→B: do you see RTP leaving A toward B’s advertised IP:port? Do you see RTP arriving at B?
Direction B→A: do you see RTP leaving B toward A’s advertised IP:port? Do you see RTP arriving at A?Step 4: If RTP is seen on one leg but not the other, suspect NAT/firewall/route asymmetry or media anchoring differences. If RTP arrives from a different source IP:port than SDP advertised, symmetric RTP behavior may be required (implementation-dependent).
Step 5: If RTP is sent but not received, test the path: firewall rules, NAT pinholes, and whether the RTP port range is open both directions. Also confirm baseline network readiness for VoIP (latency, jitter, packet loss) so you don’t confuse “blocked” with “too lossy to decode.”
Common culprits (and what to look for)
Wrong advertised IP in SDP (private/unroutable): c= shows 10.x/192.168.x/172.16-31 behind NAT, or an interface not reachable from the peer. Fix often involves SBC SDP rewriting/media anchoring or correct NAT traversal settings on the endpoint.
RTP port range mismatch: endpoint uses ports outside what firewall allows. Fix by constraining RTP port range on PBX/SBC and opening that range end-to-end.
SIP ALG/header/SDP mangling: an ALG rewrites Contact/SDP inconsistently. If you see changing IPs/ports that don’t match your network design, disabling ALG and using a properly placed SBC is commonly more predictable.
Asymmetric NAT / symmetric RTP expectations: the far end sends from a different IP/port than negotiated; without symmetric RTP (or media anchoring), audio can be one-way depending on the receiver’s behavior.
NAT, firewalls, and SIP ALG: where calls most often break
SIP signaling often survives NAT because it is a small number of flows (e.g., UDP 5060/TCP 5060/TLS 5061 depending on deployment). RTP is different: it uses dynamic UDP ports in each direction. That’s why “SIP works but audio doesn’t” is a common pattern.
Practical guidance (with environment caveats)
Prefer an SBC or managed edge to control signaling and anchor/relay media when NAT complexity is high (multi-site, cloud PBX, contact centers, strict firewalls). Design guidance: SIP trunking architecture and SBC placement.
Define and document RTP ranges on every hop (PBX, SBC, firewall). If you can’t constrain RTP, troubleshooting is often slower and less conclusive.
Avoid broken SIP ALGs: many ALGs can change headers/SDP in ways that are hard to predict. If you must use one, validate it with pcaps and mid-call scenarios (hold/transfer), not only a single outbound call.
Security and media encryption: when using TLS/SRTP, confirm expectations for transports, certificates, and crypto suites are aligned; see TLS/SRTP and security prerequisites.
Interoperability testing and acceptance checklist (carrier ↔ SBC ↔ PBX/contact center)
Before declaring a trunk “in production,” run a structured acceptance pack that covers real-world call features and media scenarios. Include multiple routes if you plan to use routing reliability and failover design (because interop can vary by route/carrier partner).
Must-pass call flows checklist
Inbound and outbound calls (multiple destinations, including IVR/contact center queues)
Early media (183 with SDP): ringback and announcements
DTMF to IVR (confirm method and payload)
Hold/resume (re-INVITE/UPDATE)
Transfers (blind and attended) or your chosen transfer method
Long-duration call (validate session timers and NAT bindings)
What to standardize (reduce future interop tickets)
Codec order and whether transcoding is allowed
DTMF method (telephone-event vs INFO vs in-band) and whether translation is permitted
Session timers (Session-Expires/Min-SE) and refresher role
Identity policy: From vs PAI vs Diversion/History-Info handling (especially relevant for inbound DID delivery; see global DID setup and porting considerations).
SDP normalization rules: ptime, payload mappings, SRTP requirements, symmetric RTP behavior
When to escalate (and what to send to another vendor/carrier)
Escalate when you can demonstrate (with evidence) that your side is sending compliant signaling/media to the peer’s advertised targets and the failure occurs beyond your control boundary. For example: the peer advertises an IP:port in SDP but does not listen there; the peer sends no RTP while claiming “media sent”; or a SIP response indicates a network-side policy rejection that you can’t remediate locally.
“Good ticket” checklist (send this up-front)
Timestamps with timezone for each test call (start time, answer time, failure time).
Call-ID (and any provider correlation IDs if present), plus the SIP dialog identifiers if needed.
From/To numbers in a redacted format (example: +1XXXYYY1234 → +44XXXYYY6789) and indicate inbound vs outbound.
SIP ladder for both legs (e.g., PBX↔SBC and SBC↔carrier) including SDP in every offer/answer (INVITE/183/200 OK and any re-INVITE/UPDATE).
RTP stats / flow summary for each direction (A→B and B→A): packet counts, loss (if measured), jitter (if measured), codec/payload observed, and the observed source/destination IP:port.
Topology notes: where the capture was taken (internal/external interface), whether media is anchored/relayed, NAT/firewall context, and any load balancers/proxies in path.
Repro steps: exact dialing pattern, route/trunk used, whether early media/transfer/hold was involved, and how many times reproduced.
Redaction guide (keep it useful)
Keep IPs/ports if possible (they are often the problem). If you must obfuscate, do it consistently (same token for same IP) and preserve public vs private distinctions.
Redact phone numbers by masking middle digits but keeping country code and last 2–4 digits (enough to correlate across systems).
Do not remove SDP; instead redact only user parts if present. SDP c=/m= lines and payload mappings are usually essential to diagnose media issues.
Remove credentials/secrets (Authorization headers, passwords, private keys). If TLS issues are involved, include certificate chain details without private keys.
FAQ
What is SIP interoperability and why do “RFC-compliant” systems still fail?
SIP/SDP includes optional behaviors and multiple valid ways to implement the same outcome. Interop failures commonly come from mismatched defaults (timers, transports), incomplete feature support (UPDATE/REFER), or media reachability issues (SDP/NAT), not necessarily from “SIP being wrong.”
What are the most common causes of one-way audio on a SIP trunk?
Common causes include incorrect SDP c=/m= values (wrong advertised IP/port), blocked RTP port ranges on firewalls, NAT asymmetry/symmetric RTP expectations, and SIP ALG behavior that rewrites headers/SDP inconsistently. Always prove which RTP direction is missing by verifying RTP presence on each leg.
Should I use RFC2833/4733 (telephone-event) or SIP INFO for DTMF over SIP?
Telephone-event is a common trunk-friendly choice for IVRs and contact centers because it stays in the RTP media plane. SIP INFO can work, but only if every hop supports and permits it (often carrier/vendor-dependent). In-band is typically safest only with G.711 and stable media conditions.
Which SIP headers matter most for caller ID and call forwarding?
From affects presentation, but many networks rely on P-Asserted-Identity for trusted caller ID. Diversion and/or History-Info carry forwarding/redirect context. Interop problems happen when formatting or policy expectations differ—normalize at the SBC and verify with inbound/outbound tests, especially for DID scenarios (see global DID setup and porting considerations).
CTA: make SIP interoperability boring (in a good way)
If you’re troubleshooting recurring interop issues between carriers, SBCs, and PBXs/contact centers, the fastest path to stability is consistent normalization and repeatable evidence (SIP+SDP+RTP) per failure. IllyVoIP can help you validate trunk behavior, align codec/DTMF/identity policies, and build an acceptance test pack that reduces escalations once you scale routes/regions and implement routing reliability and failover design.
Compliance note
This article is technical troubleshooting guidance and not legal advice. Caller ID, identity headers, and number presentation may be subject to local telecom rules and carrier policies. Validate your implementation and routing policies with your compliance and carrier requirements for the countries you operate in.
