SIP 488 Not Acceptable Here: what it means and how to fix it

Short answer: SIP 488 Not Acceptable Here means the destination received the INVITE but did not accept the media offer in the SDP. The most common cause is having no codec in common, such as offering only G.729 to a side that accepts G.711 A-law (PCMA). Compare the codecs in the offer with those the trunk accepts and read the Warning header.

How Monitor treats SIP 488

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 phone at the other end cannot use any of the audio formats (codecs) the call offered, so the call could not connect (SIP 488).

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 488 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 488 mean in practice?

SIP 488 Not Acceptable Here has the same meaning as SIP 606, but it applies only to the resource addressed in the Request-URI, so the request may work elsewhere. Put simply: the destination received the INVITE, read the media offer in the SDP and did not accept the codec, the transport profile or some other session detail. The response may carry an SDP with the destination’s capabilities and a Warning header, such as 305 Incompatible media format or 304 Media type not available.

It also shows up mid-call, as a response to a re-INVITE, for example when switching to T.38 fax. Under RFC 3398, a gateway converts the SIP 488 error into a Q.850 cause based on the Warning: cause 31 by default, or cause 65 (Bearer capability not implemented) when the Warning refers to bearer capability. In the other direction, causes 65 and 70 become 488.

Common causes in Brazil

• The PBX offers only G.729 or Opus, and the carrier’s trunk (Vivo, Claro, Algar, Embratel or another) accepts G.711 A-law (PCMA).
• An imported phone or softphone with G.711 µ-law (PCMU) as its only codec, the default in the United States, talking to a trunk that only accepts PCMA.
• An inbound call where the carrier offers only G.729 and Asterisk does not have the codec module, so the PBX itself answers 488.
• Encrypted media: an offer with RTP/SAVP (SRTP) to a trunk that only accepts RTP/AVP, or the other way around.
• A re-INVITE for T.38 fax sent to a destination that does not support T.38.
• A codec change during a transfer or when taking a call off hold, rejected by the SBC mid-call.

How to diagnose it

1. Open the call in sngrep, go into the INVITE and read the m=audio line and the a=rtpmap lines. Payload 8 is PCMA, 0 is PCMU and 18 is G.729.
2. Read the response’s Warning, for example Warning: 305 sbc.carrier "Incompatible media format", and the SDP that came with it, if any.
3. On Asterisk, Issabel or FreePBX, run pjsip show endpoint <trunk> and check the allow line (with chan_sip, sip show peer <trunk>). core show translation shows which codec conversions are available.
4. Compare the profile on the m=audio line: RTP/AVP is unencrypted audio, RTP/SAVP is SRTP. Check the endpoint’s media_encryption option.
5. Run a test with the trunk accepting only alaw. If the call goes through, adjust the codec order.
6. If the 488 comes on a re-INVITE, see what triggered it (T.38, hold, transfer) with pjsip set logger on or, on 3CX, with detailed (Verbose) logging.

What to send the carrier

• Exact date and time with the time zone, for example 2026-10-07 14:32:10 -03:00.
• Calling number (A), destination number (B) and the Call-ID.
• The full SIP/2.0 488 Not Acceptable Here line and the Warning header.
• The SDP of the INVITE sent, with the m=audio and a=rtpmap lines.
• Whether it happened on the initial INVITE or on a re-INVITE, and how many calls failed.
• The pcap file of the capture, if you have one.

Frequently asked questions

Which codec should I use on a SIP trunk in Brazil?

G.711 A-law (PCMA, payload 8) is the codec of the Brazilian phone network and the one carriers accept most widely. Many trunks also accept G.729 to save bandwidth. Keeping PCMA in the trunk's codec list avoids most 488s. Confirm the exact list with the carrier, because each contract may differ.

What is the difference between SIP 488 and SIP 606?

Both say the media offer was not accepted. The 488 applies only to that destination, and the request may work elsewhere. The 606 is a global failure: no other point should accept it, and the proxy stops trying. In practice, the 488 shows up far more often on trunks and PBXs.

Does a real test call catch this error?

Yes. A real test call negotiates media with the destination like any other call, so it gets the 488 when the offer is rejected. When the result counts as a failure, the call is repeated before any alert goes out, and the alert is sent by email and SMS.