SIP 488 Not Acceptable Here in VoLTE — Codec Mismatch and QoS Precondition Failure

SIP 488 (“Not Acceptable Here”) is a client error response in RFC 3261 indicating that the SDP offer contained in the INVITE request cannot be accepted by the responding entity. In VoLTE and VoNR deployments, SIP 488 is one of the primary causes of call setup failure and typically maps to one of two distinct root causes: codec negotiation failure or QoS precondition failure.

Distinguishing between these two causes requires reading the full IMS signaling trace — not just the 488 response itself, but the entire INVITE flow including the SDP offer, PRACK/UPDATE exchanges, and any QoS resource indication.

Technical Reference

Root Cause 1: Codec Mismatch in SDP Negotiation

In VoLTE, the SDP (Session Description Protocol) offer in the INVITE lists the codecs the originating UE supports, in preference order. The terminating UE (or network element) must select at least one from this list.

Codec negotiation in VoLTE SDP:

The SDP m=audio line and associated a=rtpmap lines list supported codecs. A typical VoLTE INVITE offer:

m=audio 49152 RTP/AVP 116 104 96 8 0
a=rtpmap:116 AMR-WB/16000
a=rtpmap:104 EVS/16000
a=rtpmap:96 AMR/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000

If the terminating side does not support any of these codec payload types — or if the P-CSCF’s media policy rejects the offer — a 488 is returned. The response typically includes a Warning header specifying the rejected attribute.

Common codec mismatch scenarios:

• The originating UE offers only AMR-WB (wideband) but the terminating operator’s network or IMS interworking gateway is configured for AMR-NB (narrowband) only
• EVS (Enhanced Voice Services, TS 26.441) is offered but the terminating UE or transcoder does not support EVS
• The SDP a=ptime (packetization time) is outside the range accepted by the terminating endpoint
• The SDP offer includes a codec with a missing or malformed a=fmtp line required by the codec specification

Root Cause 2: QoS Precondition Failure

RFC 3312 (Integration of Resource Management and SIP) defines a mechanism where the VoLTE call setup can be conditioned on QoS resource availability. When QoS preconditions are in use (indicated by a=curr:qos and a=des:qos lines in the SDP), the call cannot proceed until the required QoS resources are established at the radio layer.

What the SDP precondition lines look like:

a=curr:qos local none
a=curr:qos remote none
a=des:qos mandatory local sendrecv
a=des:qos mandatory remote sendrecv

The originating P-CSCF requires the UE to confirm via PRACK or UPDATE that the QCI 1 dedicated bearer has been established before allowing the call to ring (183 Session Progress). If the UE cannot establish the GBR bearer (e.g., due to radio congestion, insufficient QCI 1 resource, or eNB QoS enforcement failure), the P-CSCF may send 488 instead of 180 Ringing.

In 5G VoNR, the equivalent is the 5QI 1 GBR bearer (3GPP TS 23.501 §5.7.4, Table 5.7.4-1). The same QoS precondition mechanism applies.

Step-by-Step Field Diagnosis

Step 1 — Locate the INVITE and the 488 response in the SIP signaling log. Note the Via header to identify whether the 488 originates from the P-CSCF, S-CSCF, or the terminating UE. Each hop adds a Via header; the source of the 488 is the entity that generated it, identifiable from the Via stack.

Step 2 — Read the SDP offer in the INVITE. Extract the m=audio, a=rtpmap, and a=fmtp lines. These define exactly what codecs and parameters were proposed.

Step 3 — Check for a Warning header in the 488 response. A Warning header (format: Warning: warn-code warn-agent warn-text) provides the specific reason. Common values include “305 Codec not supported” or “370 QoS precondition not met.”

Step 4 — Check for QoS precondition lines in the SDP. If the SDP contains a=curr:qos and a=des:qos lines, QoS preconditions are active. Then check the PRACK and UPDATE exchange before the 488: did the UE send an UPDATE confirming the bearer is established? If not, the 488 is a QoS precondition failure.

Step 5 — Correlate with the RF KPIs at call setup time. QoS precondition failures are often correlated with degraded RF conditions preventing the QCI 1 bearer establishment. Check RSRP, SINR, and PDSCH BLER during the INVITE/PRACK/UPDATE exchange. Codec mismatches are independent of RF conditions — they occur regardless of signal quality.

What to Capture in the Field

Diagnosing SIP 488 requires simultaneous capture of:

• The full SIP/IMS signaling trace (INVITE, PRACK, UPDATE, 488, ACK flows)
• The IMS QoS bearer establishment events (QCI 1 bearer setup, EPS bearer context)
• The RF KPIs (RSRP, SINR, PDSCH BLER) during the call setup period

Standard Android telephony APIs do not expose IMS/SIP signaling. Capturing the full IMS trace requires DIAG-level access to the modem, which streams IMS OTA packets alongside the NAS and RRC log codes. The SIP INVITE, 488, and all intermediate responses are decoded in the message stream with full headers and SDP body.

Related SIP Codes

• SIP 503 — Service Unavailable (server-side overload, not SDP content issue)
• SIP 480 — Temporarily Unavailable (callee cannot accept the call right now)
• SIP 580 — Precondition Failure (QoS preconditions could not be met, RFC 3312-specific code)
• SIP 486 — Busy Here (callee already in a call)
• SIP 403 — Forbidden (IMS authorization failure, not SDP content)