SIP 488 Not Acceptable Here: SDP and Codec Troubleshooting

A 488 is an offer/answer investigation

488 Not Acceptable Here commonly indicates that the responding endpoint cannot accept some aspect of the proposed session. Compare the actual SDP offer with the answer or rejection context: media type, RTP profile, payload mapping, encryption requirement, address family and direction attributes. Do not solve it by enabling every codec.

Working offer and answer

v=0
o=asterisk 3100 3100 IN IP4 198.51.100.20
s=Example offer
c=IN IP4 198.51.100.20
t=0 0
m=audio 14000 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=sendrecv

v=0
o=peer 4100 4100 IN IP4 203.0.113.10
s=Example answer
c=IN IP4 203.0.113.10
t=0 0
m=audio 18000 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=sendrecv

The answer retains payload 0, so PCMU is the common voice format. Payload 101 remains telephone-event in both messages. The answer may reduce the offered set; it must not invent an incompatible mapping for the same dynamic payload. The negotiated destination is the answer’s c= address and m=audio port for media sent by the offerer.

Broken codec and encryption examples

m=audio 14000 RTP/AVP 111
a=rtpmap:111 opus/48000/2
# Peer supports only PCMU/PCMA; no common codec.

m=audio 14000 RTP/SAVP 0
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:REDACTED
# Peer expects RTP/AVP, or requires a different keying method.

SIP/2.0 488 Not Acceptable Here
Call-ID: call-488-001@example.com
CSeq: 101 INVITE
Reason: SIP;cause=488;text="No compatible media"

A profile mismatch such as RTP/AVP versus RTP/SAVP is not merely a codec problem. Likewise, TLS signaling does not guarantee compatible SRTP. Preserve the response source and any SDP body because an intermediary can reject before the final endpoint.

Inspect Asterisk capability and selected endpoint

sudo asterisk -rx "core show codecs audio"
sudo asterisk -rx "module show like codec"
sudo asterisk -rx "pjsip show endpoint carrier-endpoint"
sudo asterisk -rx "pjsip show channelstats"

Allow: (ulaw|alaw)
Media Encryption: no
Direct Media: false
# Illustrative endpoint fields; labels vary by version.

Installed translation capability is not the same as endpoint allow policy. Confirm the actual endpoint selected for the call, then compare its allowed formats with the outgoing SDP. Transcoding adds CPU and quality considerations; enable it only under an approved media policy.

Preserve offer/answer evidence

pjsip set logger on
# place one controlled call and note Call-ID
pjsip set logger off
sudo tcpdump -ni any host 203.0.113.10 and port 5060 -s 0 -w /tmp/call-488.pcap

For UDP signaling, the pcap should contain the INVITE body and 488 response. For TLS, rely on authorized Asterisk message logging rather than disabling TLS. Compare the last offer sent to the hop that generated the 488, not an earlier leg’s SDP.

488 diagnostic matrix

Verify correction and media

After a single controlled change, confirm the peer returns a valid answer, the common payload mapping is identical, ACK completes the dialog and packets flow both ways using the negotiated codec and encryption profile. Listen for intelligible audio and test DTMF separately. A 200 OK with malformed or unreachable SDP is not a successful media result.

Rollback

Restore the prior endpoint codec and encryption policy if the change fails or violates the approved interconnection profile. Reload only the relevant configuration in a controlled window, disable logging and delete temporary captures under policy. Do not leave broad codec sets or optimistic encryption enabled as a troubleshooting residue.

Related engineering resources

Review negotiation across multiple call legs

A B2BUA creates separate offer/answer exchanges on each leg. Do not compare the inbound endpoint’s SDP directly with the upstream response and assume Asterisk forwarded it unchanged. Record the channel selected on each leg, formats read and written, transcoding availability, and the exact offer transmitted toward the hop that returned 488. A valid inbound offer can still produce an incompatible outbound offer because endpoint policy differs.

Early offers, delayed offers and re-INVITEs also change which message carries SDP. Confirm whether the rejected transaction was the initial INVITE, an UPDATE or a re-INVITE. If media worked before the rejection, compare session-version values, direction attributes and encryption changes. Roll back the one endpoint policy that produced the divergence rather than widening codecs globally.

Audit payload numbers and attributes

Static payload numbers such as 0 for PCMU and 8 for PCMA have standardized meanings in the RTP profile; dynamic numbers require the associated a=rtpmap. Compare clock rate and channel count, not just codec names. Telephone-event is DTMF transport and cannot serve as the only overlapping voice format. Inspect fmtp parameters when the codec requires them.

Direction attributes such as sendrecv, sendonly, recvonly or inactive can explain apparent one-way media even with compatible codecs. A rejected stream may use port zero. For encrypted media, compare RTP profile plus crypto or fingerprint/keying attributes. Record each mismatch explicitly before modifying endpoint policy.

Security impact of media changes

Adding codecs expands processing and negotiation surface; disabling SRTP changes confidentiality; enabling direct media changes the packet trust boundary. Treat each as a reviewed design change, not a harmless test. Use one controlled endpoint override where supported, verify the exact offer, and restore the approved policy after isolation.