SIP 606 Not Acceptable: Causes and Fixes

SIP error 606 Not Acceptable means the far end was reached and wants to communicate, but cannot support the session you described — the media, bandwidth, or addressing style in your SDP offer. It is a 6xx global failure: no endpoint for that user will accept the same offer, so re-routing the call will not help. The fix lives in your INVITE, not in your route — most often in the codec list.

That makes 606 one of the more honest codes in SIP: it tells you the problem is on your side of the wire, and it tells you not to waste failover attempts on it. What follows works from the RFC 3261 definition through the scope line that separates 606 from its far more common sibling 488, then into a triage path from code to cause to fix. For the full code-by-code breakdown of what your trunk returns and why, see our SIP response codes reference.

What a 606 is telling you

RFC 3261 defines 606 Not Acceptable narrowly: the user’s agent was contacted successfully, but some aspect of the session description — “the requested media, bandwidth, or addressing style” — was not acceptable. The user wishes to communicate but cannot adequately support the session described in your offer.

Two details in the RFC matter for diagnosis. First, a 606 MAY carry a Warning header listing reasons the session cannot be supported — this is your best diagnostic clue, so capture it. Second, the response MAY carry a message body describing the media capabilities the far end does support (application/sdp by default), which hands you the fix directly when present.

What a 606 is not: a refusal of the call itself. That is SIP 603, where the far end (or, since March 25, 2026, a blocking analytics engine using 603+) declines to participate at all. A 606 endpoint is willing — it just cannot do anything with the media you offered. Different problem, different fix, different post.

It is also not 406 Not Acceptable. Despite the identical reason phrase, 406 is about the acceptability of the request body itself relative to the Accept header — a corner of SIP that rarely matters on trunks. On a voice trunk, “not acceptable” almost always means the SDP, and that means 606 or 488.

Is it a 606 or a 488? Scope decides everything

488 Not Acceptable Here has, per RFC 3261, “the same meaning as 606” — the session description was not acceptable — but it applies only to the specific resource addressed by the Request-URI, and the request may succeed elsewhere. The reason is identical; the scope is not:

• 488 — this endpoint or this hop cannot take your offer. Another route, another gateway, or a re-INVITE elsewhere might work.
• 606 — global. The far end is asserting that no endpoint for this user will accept this session description. Do not re-route; fix the offer.

In practice, trunk equipment emits 488 far more often than 606. When you do see a genuine 606, treat it as a stronger signal: the network is telling you failover is pointless and the SDP itself is the defect. Either way, the causes and the fixes below are the same — the codes differ only in whether trying another path is worth anything.

One operational note that follows directly from the 6xx class semantics: do not configure your dialer or SBC to auto-retry or route-advance on 606. A 6xx response is definitive information about the user, not about a route. Retries burn attempts and skew your ASR without ever completing a call.

The triage path: from code to cause

Work it in order — each step either identifies the cause or narrows it.

1. Confirm the code and where it came from. Check whether the response is a 606 or a 488, and whether it originated at the far endpoint or an intermediate hop. A 488 from your carrier’s edge is a this-hop negotiation problem; a 606 is an end-to-end offer problem.
2. Read the Warning header. RFC 3261 defines warning codes for exactly this situation — 304 (media type not available), 305 (incompatible media format), 306 (attribute not understood) among them. If the response carries a capabilities body, you now have the far end’s supported media in hand.
3. Diff your offer against the far end. Pull the INVITE’s SDP and compare line by line: the m= lines (are you offering video or T.38 to an audio-only endpoint?), the codec payload list, any b= bandwidth attributes, and the addressing in c=. The mismatch is in one of those lines.
4. Check the blast radius. One destination rejecting you points at that endpoint’s capabilities. Every call on a trunk drawing 606/488 points at your trunk’s codec or media configuration — start with the trunk configuration rather than the far end.

Fixes by cause

Codec mismatch — the usual suspect. Your offered codec list has no overlap with what the far end supports: the classic case is a G.729-only offer hitting a G.711-only trunk. Fix by aligning the codec lists on both ends or enabling transcoding at your PBX or SBC. If you are choosing what to offer, the trade-offs are covered in our G.711 vs G.729 codec comparison — on a wholesale trunk, leading with G.711u is the safe default.

Media-type mismatch. Offering a video stream or a T.38 fax stream to an endpoint that only does audio. Fix by stripping the unsupported m= line from the offer, or configuring your system to mark it optional rather than required.

Bandwidth or addressing constraints. The RFC names these explicitly: b= bandwidth limits the far end cannot honor, or addressing in the offer the far end cannot reach — IP-version and media-address issues in c= fall here. Fix by removing the constraint or correcting the media address your system advertises.

Encryption mismatch. An offer that requires SRTP landing on an endpoint that only does plain RTP (or the reverse) can also produce a not-acceptable rejection. If your trunk recently changed its media security policy and 606/488 responses started at the same time, check there first.

After each change, re-test with a single call and confirm the code is gone before restoring full traffic — a fixed codec list with a still-broken media address just moves you from one 606 to another.

Frequently asked questions

SIPNEX provisions its SIP trunks with G.711u as the primary codec plus G.711a and G.729 support — the configuration that makes 606 and 488 rejections rare in the first place — and holds a direct FCC carrier license behind it. If a route is throwing not-acceptable responses and you want a second pair of eyes on the SDP, talk to our engineers or review the trunk setup walkthrough before your next test call.