SIP 488

SIP 488 Not Acceptable Here in Asterisk

A 488 means the two sides could not agree on how to carry the media. Nine times out of ten that is a codec mismatch, but SRTP and T.38 produce an identical response, so the log is what tells them apart.

What it looks like in the log

[2026-08-17 09:14:23] VERBOSE[24815] res_pjsip_logger.c: <--- Received SIP response (1123 bytes) --->
SIP/2.0 488 Not Acceptable Here
Via: SIP/2.0/UDP 41.72.10.8:5060;branch=z9hG4bKPj8f2a1c
From: <sip:12025550118@pbx.example.net>;tag=39b1c7
To: <sip:12025550143@sip.provider.net>;tag=as5d21f0
CSeq: 8834 INVITE

What it means

488 is the callee's way of saying "I understood the request, but not here, not like this". In practice it is almost always a response to your INVITE's SDP offer: the far end looked at the codecs, transport and crypto you offered, found nothing it was willing to use, and rejected the session rather than negotiating down.

It is worth being precise about who sent it. A 488 received by Asterisk means the far end refused your offer. A 488 sent by Asterisk means your endpoint or trunk offered something the PBX is not configured to allow - a different problem with a different fix, and the direction is the first thing to read off the log.

Most common causes

  1. 01Codec mismatch

    The most common cause by far. Your trunk offers ulaw and alaw, the provider only accepts G.729, and neither side will transcode. Asterisk will not silently pick a codec it was not told it could use, so an allow line that omits the one codec the far end wants produces a 488 on every call.

  2. 02SRTP required on one side only

    If the endpoint has media_encryption=sdes and the trunk does not (or the reverse), the offer carries RTP/SAVP where the far end expects RTP/AVP. The transport line, not the codec list, is what gets rejected. This one is easy to misdiagnose as a codec problem because the symptom is identical.

  3. 03T.38 re-INVITE refused

    A fax call that starts in audio and re-INVITEs to T.38 gets a 488 back when the far end does not do T.38. The call was already up, so the log shows a working call that dies mid-fax rather than a failed setup.

  4. 04Direct media with incompatible endpoints

    With direct_media=yes, Asterisk steps out of the media path and the two endpoints negotiate with each other. Two devices with no codec in common will 488 each other even though both negotiated with Asterisk successfully.

  5. 05A ptime or sample-rate the far end will not take

    Rarer, but real: an offer of G.722 at a packetisation the far end does not support, or an ptime attribute outside its accepted range, is refused with the same 488.

How to tell which one it is

The answer is in the SDP bodies, and you need both of them. Find the INVITE that Asterisk sent and list the m=audio line and every a=rtpmap under it. That is what you offered. Then check the transport token on the m= line: RTP/AVP is plain, RTP/SAVP means you asked for SRTP.

If the offered codec list and the trunk's configured allow list differ, the config is not what you think it is - a codec set in the endpoint but not the trunk, or an allow=all that was overridden by a later disallow, will show up here as an offer that does not match the file you have been reading.

How to fix it

Related failures