Start with two PJSIP legs and four control points
Asterisk is a back-to-back user agent. The caller negotiates with its Asterisk channel, the core connects that channel to another, and the called-side channel negotiates with the destination. Even with direct media, the initial codec lists are not one end-to-end endpoint exchange.
Asterisk documents four endpoint controls: incoming offer before the first leg reaches the core, outgoing offer before the second leg is sent, incoming answer before the second leg returns to the core, and outgoing answer before the first leg receives its answer. Capture the offer and answer on each leg and keep their Call-ID, direction and endpoint policy separate.
Separate configured, pending and resolved lists
At each control point, Asterisk reconciles a pending topology with a configured one. prefer chooses which list supplies ordering; operation selects union, intersection or one side; keep retains all results or only the first. transcode is meaningful while offers are processed and is ignored for answers.
An endpoint's allow order is configured input, not proof of the sent offer or selected codec. Preserve the loaded endpoint, pending list and resolved list for the exact control point before changing an order or pruning formats.
Read the documented defaults in their own direction
Asterisk 22 lists incoming-offer defaults of pending preference, intersection, all results and transcoding allowed. Outgoing offers default to pending preference, union, all results and transcoding allowed. Incoming and outgoing answers default to pending preference, intersection and all results. These defaults do different work because their pending and configured topologies are different.
Do not copy one compact preference string into all four fields or rely on an older example without checking the loaded branch. preferred_codec_only is another endpoint control and should not be treated as a synonym for every keep:first decision across both legs.
Keep transcoding policy separate from translator availability
Allowing transcoding permits the negotiation process to continue across otherwise different audio lists; it does not create a codec module, license, encoder, decoder, capacity budget or usable translation path. Inspect core show translation on the running system and retain the installed module and resource evidence separately.
Asterisk's capability documentation keeps audio translation distinct from video pass-through. A format appearing in a capability list or SDP does not establish that Asterisk can translate it, that the peer accepts its parameters, or that the resulting media has usable quality.
Treat answers and renegotiation as bounded evidence
RFC 3264 binds an answer to one offer and constrains the accepted media streams and formats. A later re-INVITE or UPDATE creates another offer/answer exchange; it does not retroactively change what the first answer selected. Empty re-INVITEs and Asterisk's versioned all_codecs_on_empty_reinvite control require their own trace.
Preserve media type, RTP profile, payload mapping, clock rate, format parameters, direction and protection attributes. A shared codec label alone does not prove that the complete media description is compatible.
Diagnose 488 at the leg that produced it
Use the focused 488 diagnostic to establish which user agent rejected which offer. If Asterisk returned 488 before creating the outgoing channel, inspect the incoming-offer resolution. If a provider or device returned 488 to Asterisk's outbound request, inspect the outgoing-offer result and that peer's response.
Correct one evidenced boundary, retest the same authorized flow and confirm the final answer, selected codec, bidirectional packets, decoded audio and normal hangup separately. No codec, translator, endpoint, provider, packet path or call was tested for this guide.
Place a dialplan offer override at the outbound-channel boundary
The PJSIP_MEDIA_OFFER guide adds channel ownership and pre-dial timing to the four codec-negotiation control points. A written list is an input, not proof of emitted SDP or the selected answer.
Prove post-answer codec changes with offer, answer and RTP
Use the PJSIP_SEND_SESSION_REFRESH guide when a codec offer is changed after call setup; a staged format list or 2xx response alone is not the negotiated media result.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- Asterisk 22 res_pjsip endpoint reference ↗
- Asterisk PJSIP advanced codec negotiation ↗
- Asterisk codec modules and translation paths ↗
- Asterisk audio and video capabilities ↗
- RFC 3264: SDP offer/answer model ↗
- Asterisk PJSIP_MEDIA_OFFER function ↗
- Asterisk PJSIP_SEND_SESSION_REFRESH function ↗
- Asterisk pre-dial handlers ↗
- Asterisk Dial application ↗
- Asterisk res_pjsip endpoint reference ↗
- Asterisk 22 PJSIP_SEND_SESSION_REFRESH reference ↗
- Asterisk CHANNEL dialplan function ↗
- RFC 3261: SIP ↗
- RFC 3311: SIP UPDATE method ↗
- RFC 3264: SDP offer/answer model ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.