SIP 606 Not Acceptable: what it means and how to fix it

Short answer: SIP 606 Not Acceptable means the destination was reached but did not accept parts of the proposed session, such as media, bandwidth or addressing, and indicates that no other endpoint would. It is the global version of 488. The most common cause is a codec or SRTP mismatch. Read the Warning header and compare the SDP offer.

How Monitor treats SIP 606

The reading depends on what should answer the number, which is the question 2N5 answers when it adds each circuit. These are the rules the product applies today, generated from the same function that judges every test call.

What should answer the number	Reading
A greeting or recorded message (the IVR)	Down
A test tone or echo service	Down
Other: it may ring or be answered	Down

What Monitor records for an IVR: The call was refused, and the provider said it would fail everywhere (SIP 606).

A call read as Down alerts nobody on its own: it is repeated 3 times, every 2 minutes, and only 4 failures in a row open an incident, with each call's SIP code and Q.850 cause as evidence for the carrier. At the default pace, every circuit is tested every 15 minutes.

If the carrier returns SIP 606 when 2N5's calling account registers, before any call, the test is monitoring blind: it is a problem on 2N5's side, it does not count against the circuit and it does not alert the customer.

What does SIP 606 mean in practice?

SIP 606 Not Acceptable is a 6xx global failure. Under RFC 3261, the destination’s system was contacted successfully, but some aspects of the session description, such as the requested media, the bandwidth or the addressing style, are not acceptable. It indicates the destination wants to communicate but cannot support the session as described. The response may carry one or more Warning headers explaining why.

What separates it from SIP 488 is scope: a 488 applies only to that destination, while a 606 warns that no other endpoint should accept, and the proxy cancels its pending attempts. In practice, the SIP 606 error is rare on Brazilian trunks. When it appears, it almost always comes from an SBC or a platform configured to refuse the media offer outright.

Common causes in Brazil

• An offer without G.711 A-law (PCMA), the codec of the Brazilian phone network, sent to a carrier SBC (Vivo, Claro, Algar, Embratel or another) that only accepts that codec.
• Encrypted media (RTP/SAVP) offered to a destination that only accepts unencrypted audio, or the other way around.
• An offer with only video, or with a mandatory video stream, to a destination that only handles audio.
• A softphone or phone with Opus or G.722 as its only codecs, talking to an Asterisk, Issabel, FreePBX or 3CX PBX that does not have those codecs on the trunk.
• Bandwidth declared in the SDP above what the destination accepts.

How to troubleshoot

1. Open the call in sngrep and read the Warning in the response, for example Warning: 305 sbc.destino "Incompatible media format".
2. In the INVITE, check the m=audio line and the a=rtpmap lines. Payload 8 is PCMA, 0 is PCMU and 18 is G.729.
3. Check the transport profile on the m=audio line: RTP/AVP is unencrypted audio and RTP/SAVP is SRTP.
4. In Asterisk, Issabel or FreePBX, run pjsip show endpoint <trunk> and check allow and media_encryption (in chan_sip, sip show peer <trunk>). With pjsip set logger on, you can see the full SDP.
5. In 3CX, turn on verbose logging and check the Activity Log for which codecs were offered.
6. Place the call again with only alaw on the trunk. If it completes, adjust the codec list on the phone or the PBX.

What to send your carrier

• The exact date and time with the time zone, for example 2026-10-07 14:32:10 -03:00.
• The calling number (A), the called number (B) and the Call-ID.
• The full SIP/2.0 606 Not Acceptable line and every Warning header.
• The SDP of the INVITE you sent.
• How many calls failed and whether the problem started after a change.
• The pcap file of the capture, if you have one.

Frequently asked questions

What does the Warning header say in a SIP 606?

It explains why the session was not accepted. The three-digit code gives the reason, for example 304 for media type not available, 305 for incompatible media format and 370 for insufficient bandwidth. The quoted text after the server name often adds detail. Without a Warning, compare the SDP you sent with what the destination accepts.

Which Q.850 cause goes with a SIP 606?

Under RFC 3398, it depends on the Warning: the gateway uses Q.850 cause 31 (Normal, unspecified) by default, or cause 65 (Bearer capability not implemented) when the Warning is about bearer capability. No Q.850 cause is converted into a 606 in the other direction; cause 65 becomes a 488.

Does a real test call catch this error?

Yes. A real test call negotiates media with the destination like any other call, so it receives the 606 when the session is refused. When the result counts as a failure, the call is retried before any alert goes out, and the alert is sent by email and SMS.