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

CollabPlane engineering notes

A 488 response rejects the session description, not the call. The far end understood the request and could reach the user. It could not accept the media that was offered.

Read the offer first

Open the INVITE that received the 488 and read its SDP. The answer is almost always in three lines:

• m=audio gives the transport and the codecs offered, by payload number.
• a=rtpmap names each codec.
• a=crypto is present when the offer is for encrypted media.

Some devices add a Warning header to the 488. Code 304 means a media type is not available and 305 means an incompatible media format.

The common causes

• No codec in common. The offer lists only codecs the far end will not accept. On Cisco IOS-XE, a VoIP dial-peer with no codec configured offers G.729 only, which a carrier or cloud service that expects G.711 will refuse.
• The wrong dial-peer matched. The codec list you configured is on a different dial-peer from the one the call used. Check the match before changing the codec.
• Encrypted against unencrypted. The offer uses RTP/SAVP and the far end accepts only RTP/AVP, or the reverse.
• A change in the middle of the call. A re-INVITE for hold, a transfer, video or a switch to T.38 fax can be refused with 488 while the original call was fine. Compare the re-INVITE with the first INVITE.
• An address family the far end does not use. An IPv6 address offered to an IPv4-only peer.

Fix it at the right place

1. Confirm which dial-peer or trunk profile handled the call.
2. Compare its codec list and encryption setting with what the far end publishes as supported.
3. Change the offer to include a shared codec, or enable transcoding where you need two different codecs to coexist.
4. Place the call again and read the new offer. Do not assume the change took effect.

If one call through the same trunk works and another gets a 488, put the two INVITEs side by side. The difference is in the SDP.

Where Workbench helps

Call Comparison shows a working and a failing call message by message and highlights the SDP fields that differ. Dial-Peer Lens shows which dial-peer each call matched.