A SIP 488 response means the receiving system cannot accept something in the session offer. SIP 488 not acceptable here troubleshooting starts with the call signaling, not the assumption that audio is broken. The usual focus is the Session Description Protocol (SDP), which describes media, codecs, ports, and related capabilities.
This response can appear between a phone and FreePBX, between a PBX and a carrier, or between two providers. A careful trace shows which device sent the 488 and what the rejected offer contained. That distinction prevents random codec changes and helps preserve working calls.
What a SIP 488 response actually means
SIP status code 488 means “Not Acceptable Here.” It is a session-level response. The receiving endpoint understood the request but could not support the proposed media conditions for that dialog.
In practice, the endpoint may reject every offered codec, an incompatible media profile, an unsupported transport, or an unusable media description. The exact reason depends on the endpoint and its logs. A 488 does not identify one universal fault.
Signaling and audio are different paths. SIP messages establish and control a call. RTP, or Real-time Transport Protocol, carries the audio after negotiation. If the call reaches an answer but has no audio, investigate media flow separately. A 488 usually prevents acceptable media negotiation before normal audio begins.
- Signaling failure: the call setup receives a 488 before the session is accepted.
- Media failure: the call connects, but RTP is missing, blocked, or misdirected.
- Mixed symptoms: a provider may reject one offer, then another attempt may connect with different media details.
For a related signaling method, compare this process with the trace approach in SIP 408 request timeout troubleshooting. A 408 usually points toward a missing response, while a 488 indicates an explicit rejection.
Start SIP 488 not acceptable here troubleshooting with one failed call
For repeatable SIP 488 not acceptable here troubleshooting, capture one reproducible failure before changing configuration. Record the time, direction, numbers, extension, trunk, and whether the call came from an internal phone, external carrier, or application.
Next, identify the sender and recipient of the 488. A carrier response suggests a trunk offer or interoperability issue. A FreePBX response may point to endpoint capabilities, codec policy, or media settings. The same numeric response can have different causes at different hops.
Use a SIP trace or packet capture when possible. In Asterisk, administrators commonly use the available SIP diagnostic tools for the signaling technology in use. The exact command depends on whether the system uses PJSIP or the older chan_sip channel driver, so confirm the platform before running commands.
Look for the request that carries an SDP body. Usually, this is an INVITE or a response containing an offer. Then find the 488 and compare it with the offer. Preserve the trace securely because phone numbers, addresses, and authentication-related details may appear in it.
- Find the initial INVITE and its SDP.
- List the offered audio codecs and payload types.
- Check the media address, port, transport, and profile.
- Locate the 488 response and its warning or reason text, if present.
- Repeat the test through another route only after saving the first evidence.
The official Asterisk documentation provides reference material for endpoint configuration, SIP behavior, RTP, and diagnostic concepts. Use it alongside the exact Asterisk and FreePBX versions in the environment.
Read the SDP offer before changing codecs
SDP is a text description inside a SIP message. The m=audio line identifies an audio media section, its port, transport profile, and offered payload types. The a=rtpmap lines map payload types to codecs and clock rates.
For example, an offer may list G.711 μ-law, G.711 A-law, G.729, Opus, or telephone-event. Do not assume every named codec is available on every endpoint. Licensing, firmware, region, and PBX modules can affect actual support.
Compare these items carefully:
- Codec overlap: does the endpoint support at least one offered codec?
- Payload mapping: do dynamic payload numbers match the associated
rtpmaplines? - Packetization: does the offer use a packetization mode the endpoint accepts?
- DTMF events: are telephone-event formats compatible with the call path?
- Media profile: does the endpoint expect ordinary RTP or a secure variant?
- Addressing: is the media address usable from the other side of the call?
Codec order matters in some systems, but it does not create compatibility by itself. The first codec is only useful when both sides support it and the provider permits it. Avoid enabling every available codec as a test. Broad offers can expose additional interoperability problems.
Check endpoint media capabilities and settings
When one extension fails, inspect that endpoint before changing the entire trunk. Compare it with a working extension using the same route. Note the phone model, software version, transport, encryption settings, and assigned codec policy.
A phone may advertise a codec that the PBX does not permit. Conversely, the PBX may send an offer containing codecs that the phone cannot decode. Provisioning templates can also override settings made on the device itself.
Useful endpoint comparisons
- Test the failing phone against another extension on the same network.
- Test the same extension from a known-good softphone, if permitted.
- Compare the endpoint’s allowed codecs with the extension or endpoint object.
- Check whether one side requires encryption while the other lacks it.
- Confirm that the device uses the intended transport and signaling technology.
If internal calls work but a carrier call fails, the endpoint may still be healthy. The failure can occur when the PBX creates a second SDP offer for the trunk. Trace both call legs rather than treating the phone’s successful internal call as proof of trunk compatibility.
Also distinguish a codec issue from a media-routing issue. A phone that connects and produces silence may have an RTP path problem. A phone that receives a 488 before answer has a negotiation problem to solve first. For connected calls with absent audio, see the guide to ringback followed by no audio.
Trace FreePBX and trunk interoperability
Trunk interoperability problems often appear when each side follows a slightly different interpretation of the offer. The carrier may require a narrow codec set. It may reject an offer containing only unsupported codecs, an unexpected media profile, or a format it cannot bridge.
Review the trunk’s codec settings, but check the provider’s current requirements first. Do not copy settings from another carrier. Two trunks can use SIP while requiring different codecs, encryption, packetization, or offer behavior.
Then inspect how FreePBX selects the trunk and builds the outbound call. Confirm the route, trunk sequence, endpoint identity, and any custom PJSIP settings. A setting at the extension, endpoint, trunk, or global level may influence the final offer.
For a controlled test, allow only the codec or small codec group that both sides document as supported. Make one change, place one test call, and save the resulting trace. If the test works, compare the accepted SDP with the rejected SDP. If it fails, restore the prior configuration before trying another hypothesis.
NAT can complicate the picture, but it should not become the default explanation for every 488. Network address translation changes how private and public addresses appear across a router. The Cloudflare overview of NAT explains that basic behavior. A bad media address often causes no audio after answer, while a provider may still issue 488 when it validates the offer itself.
Use a safe test sequence
Apply the smallest change that tests the leading hypothesis. A practical sequence looks like this:
- Confirm the failing call direction and the exact 488 sender.
- Capture the offer, response, and any provider reason text.
- Compare offered codecs with the endpoint and trunk’s documented capabilities.
- Check SDP media profile, packetization, DTMF, address, and port details.
- Test one codec policy or endpoint setting at a time.
- Retest internal, inbound, and outbound paths separately.
- Review the new trace and record the accepted media result.
Keep a rollback note for each change. Trunk edits can affect every caller, not just the reported extension. Schedule tests when a failed call will not disrupt a busy operation, and avoid changing several endpoints during the same test window.
Do not treat a successful call as complete proof. Confirm that the call connects in both directions, audio works, DTMF behaves as expected, and the provider accepts the intended caller and destination patterns. If the route later fails again, the saved trace gives you a useful comparison.
Common mistakes that prolong a 488 investigation
One mistake is changing codecs before finding the response source. That can hide the original condition and affect unrelated calls. Another is testing only one endpoint. A single phone may have stale provisioning or a narrower capability set.
People also confuse RTP problems with SIP negotiation. Packet loss, blocked UDP ports, or an incorrect NAT address usually deserve a media-flow investigation after the call connects. They do not automatically explain a pre-answer 488.
Finally, avoid reading a generic log line as a complete diagnosis. Provider messages can be brief, and PBX logs may omit the remote reason. The SDP and packet direction often provide the stronger evidence.
When professional help is appropriate
SIP 488 not acceptable here troubleshooting becomes more complex when the call crosses several providers, uses encrypted signaling, or behaves differently across regions. Remote assistance from Tech Rescue Ops LLC can help collect a limited trace, compare SDP on each call leg, and plan a reversible trunk or endpoint change. Share timestamps and sanitized traces whenever possible, and protect credentials before sending diagnostics.