SIP 488 is a media negotiation failure — the server rejected your SDP offer. It's almost always a codec mismatch, but SRTP conflicts, ptime disagreements, and ICE configuration issues can also trigger it. Here's how to tell them apart and fix each one.
SIP 488 Not Acceptable Here is defined in RFC 3261 Section 21.4.22 and extended by RFC 3264 (the offer/answer model). It means the UAS received and understood the INVITE but could not accept the SDP offer within it.
Unlike a 503 (server problem) or 404 (user not found), a 488 is specifically about the media description in the SDP body. The signaling is fine — the server knows who you're calling and is reachable — but it can't agree on how to send the audio or video.
The response should include a Warning header with a three-digit warning code that hints at the specific problem, though many implementations omit this.
In this example the INVITE offered PCMU, PCMA, and G.729. The 488 with Warning 304 tells you the remote end has no codec in common with your offer. The next step is to look at what codecs the remote end supports — often found in a prior REGISTER or OPTIONS response.
The m= line defines the media type, port, transport protocol, and payload type numbers. Make sure both sides use the same transport protocol — RTP/AVP for unencrypted, RTP/SAVP for SRTP with SDES, UDP/TLS/RTP/SAVPF for DTLS-SRTP.
Payload types 0–95 are statically assigned (0=PCMU, 8=PCMA, 9=G722, 18=G729). Payload types 96–127 are dynamic and must be mapped via a=rtpmap lines. If both sides list payload type 101 but one maps it to telephone-event and the other to something else, you have a conflict.
For SRTP with SDES, look for a=crypto: lines. For DTLS-SRTP, look for a=fingerprint: and a=setup: lines. If one side has these and the other doesn't, that's your 488.
Warning codes in a 488 response: 300 = incompatible network address, 301 = incompatible network format, 302 = incompatible transport protocol, 303 = incompatible bandwidth, 304 = media format incompatible.
No common codec: Add PCMU (payload 0) to your codec list as a guaranteed fallback. Check your PBX or gateway codec configuration and ensure both endpoints share at least one codec. On Asterisk, check allow= lines in sip.conf or pjsip.conf. On FreeSWITCH, check <codec-prefs> in the profile.
SRTP/RTP mismatch: Decide on a transport standard and enforce it consistently. If your network requires SRTP, ensure all endpoints support it. If you have legacy endpoints that only support RTP/AVP, configure your SBC to transcode the SRTP at the boundary. Never mix SRTP and RTP/AVP in the same call leg without transcoding.
Ptime mismatch: Set ptime to 20ms on both endpoints — this is the universal default. If you need non-standard ptime for bandwidth reasons, verify both endpoints explicitly support it before deploying.
ICE mismatch: For WebRTC-to-SIP bridging, use a media gateway or SBC that handles ICE termination on the WebRTC side and presents standard RTP to the SIP side. Don't try to send ICE-based SDP directly to a traditional SIP endpoint.
Missing telephone-event: Add a=rtpmap:101 telephone-event/8000 and a=fmtp:101 0-16 to your SDP offer. Ensure payload type 101 is included in the m=audio line's payload list.
In practice, many implementations use 488 when they should use 606, so don't rely on this distinction for diagnosis — focus on the SDP content instead.
Paste your SIP trace into SIPSymposium and get the exact mismatch identified in seconds — codec comparison, SRTP conflict detection, ptime analysis, and ICE compatibility check all in one report.
Paste both sides of the SDP negotiation into SIPSymposium. The analyzer compares offer and answer, identifies the specific incompatibility, and tells you exactly what to change on which endpoint.