Freeze one refresh transaction and one media segment
Record timestamp and timezone, full Asterisk version, module inventory, dialplan revision, channel name, unique ID, linked ID, bridge peer, endpoint, dialog Call-ID, chosen invite or update value, prior negotiated SDP, staged media offer, emitted request, response, and RTP result. Classify the first mismatch as wrong channel, unavailable function, invalid timing, unsupported method, outstanding offer, rejected SDP, accepted-but-different answer, address or port error, codec failure or unrelated later media change.
Do not begin by alternating methods or repeatedly sending refreshes. That destroys the transaction sequence and can create glare that was absent from the original symptom.
Prove channel ownership and established-session timing
Confirm the dialplan runs on the PJSIP channel whose session should change and that the relevant dialog and media session are established. Compare ${CHANNEL} and PJSIP channel metadata with the request Call-ID and bridge topology. If the logic ran on a Local-channel half, caller leg, transferred replacement or conference control channel, correct that ownership boundary first.
An empty expansion, no emitted request or a channel-technology error is earlier evidence than peer codec policy. Preserve the application and Asterisk log result before changing SDP settings.
Separate method support from offer-answer collision
For UPDATE, prove peer method support and the exact final response. For re-INVITE, check whether another INVITE transaction is active in either direction. A 491 response identifies request-pending glare; RFC 3311 also describes 500 plus Retry-After for overlapping UPDATE transactions and 491 when another offer remains unanswered.
Correlate session-timer, direct-media, hold, transfer and peer-generated requests around the same CSeq sequence. Correct serialization and use protocol-directed retry timing; do not mask a persistent ownership or policy problem with an immediate loop.
Compare the intended offer with the peer answer
Preserve the full sanitized SDP rather than a single codec label. Compare session version, media lines, payload numbers, rtpmap and fmtp attributes, direction, connection address and port. Asterisk explicitly warns that the refresh function does not enforce endpoint format support, so a locally staged codec can be rejected or answered differently.
A 488 or another final rejection keeps the previous session as the expected baseline. A 2xx with a different compatible subset may be valid but does not prove the application achieved its intended codec or topology change.
Trace media after the signaling result
After a successful offer-answer exchange, compare both RTP directions before and after the refresh: selected payload type, source and destination address, packet arrival, RTCP where available, decoder state and audible or application result. Look for a private or stale SDP address, unopened firewall pinhole, direct-media transition, symmetric-RTP learning change or unsupported negotiated format.
Signaling acceptance and media success are separate. One-way packets, counters on the wrong leg or a codec name in SDP do not establish end-to-end audio.
Correct one owner and repeat bounded controls
Correct only the demonstrated boundary: channel placement, execution timing, method selection, offer serialization, codec list, address or port policy, NAT state, firewall handling or endpoint compatibility. Repeat the same call once with the intended refresh and once without it, preserving the prior media state, signaling sequence, answer and RTP outcome.
Remove temporary protocol logging and retain only redacted evidence. Do not weaken codec, topology or security policy merely to obtain a 2xx response. No PBX, module, endpoint, channel, dialog, request, response, SDP body, RTP stream, packet or call was inspected or tested for this diagnostic.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- Asterisk PJSIP_SEND_SESSION_REFRESH dialplan function ↗
- Asterisk 22 PJSIP_SEND_SESSION_REFRESH reference ↗
- Asterisk PJSIP_MEDIA_OFFER dialplan function ↗
- 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.