Asterisk PJSIP_MEDIA_OFFER codec is unchanged or the call fails

Freeze one call and classify the first divergence

Record timestamp and timezone, caller channel, created PJSIP callee, Dial target and options, handler context and arguments, requested media type and list, list read back on the callee, outbound INVITE SDP, response SDP or rejection, selected channel formats and observed media.

Classify the first failure: handler did not run, wrong channel, wrong media type, unexpected list, outbound SDP unchanged, peer rejected the offer, answer selected another permitted format, translation failed, refresh failed, or SIP completed but media was unusable.

Prove which pre-dial handler owned the write

Follow Dial() into the actual caller and callee channels. Lowercase b runs on every created callee before dialing; uppercase B runs on the caller before those channels exist. Confirm the intended lower-case handler entered on the outbound PJSIP channel, executed the write and returned.

When several destinations are dialed, inspect each callee separately. One successful handler log cannot prove that every fork received the same offer.

Compare requested, configured and resolved codec lists

Preserve the PJSIP_MEDIA_OFFER(audio) or video value, the loaded endpoint allow list and all applicable codec-preference fields. Then compare those inputs with the exact codec order and media streams in the outbound SDP.

Do not treat an endpoint allow order as the emitted offer or an emitted offer as the selected answer. Asterisk resolves pending and configured topologies at four control points, and an empty result can stop the call before or during the outbound leg.

Follow rejection and answer on the producing leg

If Asterisk or the peer returns 488 or another final response, retain the complete offer, responder, channel and hangup cause. Move to the focused 488 diagnostic only after proving the leg and offer that were rejected.

If the peer answers with a different codec from the first preference, determine whether that format was still offered and permitted. Answer selection, preference and failure are different outcomes; do not force a single format solely because it was not chosen first.

Separate setup from re-INVITE or UPDATE refresh

For an established call, prove the exact answered channel that received the new list and PJSIP_SEND_SESSION_REFRESH() write. Capture the refresh method, SDP, response, new formats and media continuity. The function does not validate remote format support, so an accepted dialplan write can still produce rejection or lost media.

Do not send repeated refreshes to compensate for an initial offer written on the wrong leg. Preserve each offer-and-answer exchange as its own transaction.

Correct one owner and prove the complete outcome

Correct only the first demonstrated boundary: supported hook, handler case, channel owner, media selector, codec list, endpoint policy, peer capability, codec module, translation path or refresh timing. Preserve the previous dialplan and loaded configuration.

Repeat the same authorized call and confirm handler ownership, outbound offer, answer, selected formats, packets and decoded media in both directions. Remove temporary protocol logging and redact identities and addresses. No PBX, endpoint, channel, offer, answer, refresh, translator, packet or call was inspected or tested.

Trace the explicit refresh after a post-answer media offer

When the offer changes after call setup, follow the PJSIP session-refresh diagnostic through the selected method, offer collision, peer answer and media result.