SDP Offer/Answer Checker
Compare an SDP offer and answer
the way RFC 3264 does
Paste the offer and the answer — or the whole INVITE and 200 OK — and get the negotiation checked: rejected media, codec intersection, direction pairing, ptime, RTP/AVP vs SAVP, SRTP suites, DTMF payload type, private addresses. Deterministic, free, nothing stored.
No account · nothing stored · no AI call
What it checks
The RFC 3264 rules, plus the mismatches that break calls anyway
The first group are protocol violations. The second group are legal negotiations that still produce a 488, one-way audio or dead DTMF on real equipment.
| Check | What a failure means |
|---|---|
m= count and order | The answer must carry exactly one m= per offered m=, in the same order. A missing line is a malformed answer, not a rejection. |
port 0 | The answerer rejected that media stream. For the only audio stream this is a dead call; for video or a second stream it may be intended. |
codec intersection | No payload in common means no media; a codec in the answer that was not offered violates the subset rule and some stacks drop it. |
direction pairing | sendonly must be answered recvonly or inactive; the reverse likewise. A wrong pairing is the classic hold-that-never-resumes and one-way-audio case. |
transport | RTP/AVP offered and RTP/SAVP answered (or the reverse) is a 488 waiting to happen; the two sides do not agree on whether media is encrypted. |
SRTP crypto suite | Both sides secure but no common a=crypto suite: the key exchange fails and media is silent. |
ptime | 20 ms offered, 30 ms answered. Legal, but some gateways transcode, some drop frames, and jitter buffers misbehave. |
telephone-event PT | Different dynamic payload types for RFC 4733 events on each side. Legal under RFC 3264; strict stacks ignore the unexpected PT and DTMF dies. |
rtcp-mux | Offered but not answered: RTCP falls back to port+1, which a firewall tuned for mux will drop. |
c= address | An RFC 1918 address in either c= line, or 0.0.0.0. Media is sent somewhere the other side cannot reach unless an SBC rewrites it. |
Where it leads
Three symptoms this check explains
Each has a guide for the full diagnosis, including the parts that are not in the SDP.
488 Not Acceptable Here
The callee rejected the offer. Compare the failing offer against an SDP that same device normally answers with to see which rule it refuses. SIP 488 guide → · Codec negotiation →
One-way audio
Signalling completes, one side hears nothing. Usually a private
c= address or a direction pairing that never returned to sendrecv. One-way audio guide → · NAT traversal →DTMF not working
IVRs stop responding after an SBC or trunk change. The telephone-event payload type no longer matches on both legs. DTMF guide → · SRTP and TLS →
FAQ
SDP offer/answer questions
What the checker covers, what it does not, and where your SDP goes.
What does an SDP offer/answer checker do?
It applies the RFC 3264 rules to an SDP offer and the answer it received: one answer
m= line per offer m= line in the same order, port 0 for rejected media, answer codecs a subset of the offer, valid direction pairings (sendonly is answered recvonly, and so on), matching transport (RTP/AVP, RTP/SAVP, UDP/TLS/RTP/SAVPF), and matching SRTP crypto suites. It also flags the practical mismatches that break calls without violating the RFC: ptime asymmetry, different telephone-event payload types, rtcp-mux only on one side, and RFC 1918 connection addresses.Can I paste the whole INVITE and 200 OK instead of just the SDP?
Yes. Paste the complete SIP messages; the SDP body is extracted from each. Pasting the full messages is usually easier because that is what a trace gives you.
Why did I get SIP 488 Not Acceptable Here?
488 means the far end rejected the SDP offer at that endpoint. The usual causes are no common codec, a transport the callee does not support (SRTP offered to a plain RTP device or the reverse), a T.38 re-INVITE to a gateway without fax support, or a direction or ptime the callee refuses. If you have the offer that triggered the 488 and the SDP the callee normally sends in a 200 OK, compare them here to see which rule fails. The 488 guide covers the rest.
What causes one-way audio when the SDP looks fine?
Most often an RFC 1918 private address in the
c= line or the Contact header: the far side sends media to an address it cannot reach. The checker flags private connection addresses on either side. Direction pairing problems (an answer that stays sendonly or inactive) are the other common cause and are flagged as well.Is my SDP stored?
No. The comparison runs on the SIPSymposium MCP endpoint as a deterministic function; the text is parsed, the result is returned, and nothing is kept. No AI model is involved and no account is needed. The same tool is available inside Claude, Cursor or VS Code through the SIPSymposium MCP server.
The SDP is half the story.
Timers, retransmissions, auth loops, NAT behaviour and what happened on the other legs are in the trace, not the SDP. The analyzer reads all of it.