VoIP.infoThe independent guide to business communications.
VoIP.info Guide

Asterisk PJSIP_SEND_SESSION_REFRESH: re-INVITE, UPDATE and media evidence

Initiate one controlled in-dialog media refresh, distinguish re-INVITE from UPDATE, and prove the offer, answer, negotiated state and resulting RTP instead of treating a sent request as success.

Reviewed 2026-10-14Current Asterisk PJSIP_SEND_SESSION_REFRESH, PJSIP_MEDIA_OFFER and CHANNEL documentation plus RFC 3261, RFC 3311 and RFC 3264 reviewed October 14, 2026; the write-only refresh function is documented since Asterisk 13.12.0 and 14.1.0 and can request re-INVITE or UPDATE on an established media session, but installed module state, channel ownership, peer method support, offer and answer, response handling, RTP path and audible result remain deployment specific, and no PBX, module, endpoint, channel, dialog, request, response, SDP body, RTP stream, packet or call was inspected or testedAdvancedDocumentation based · not lab tested

Use the function only on the intended established PJSIP channel

Asterisk documents PJSIP_SEND_SESSION_REFRESH() as a write-only function that immediately asks the PJSIP stack to refresh the media session for the current channel. The documented floors are 13.12.0 and 14.1.0. Confirm the installed full release, loaded chan_pjsip module, current channel technology, channel name, unique ID and dialog before invoking it.

The function is not a global endpoint command and does not target the other bridge leg automatically. Local channels, transfers, queues, conferences and nested dialplan can place execution on a different channel from the leg whose SDP must change. A shared linked ID correlates a call graph but does not make channel state interchangeable.

Choose re-INVITE or UPDATE deliberately

The default invite value sends a re-INVITE; update sends SIP UPDATE. RFC 3261 defines a re-INVITE as a new INVITE inside the existing dialog that can modify the session, while RFC 3311 defines UPDATE for changing session parameters without changing dialog state. These methods have different peer-support and transaction boundaries.

Do not choose UPDATE merely because it sounds lighter. Preserve the peer Allow and Supported evidence, request method, Call-ID, CSeq, route set, SDP body and final response. An accepted method does not by itself prove the requested media description was accepted or put into use.

Stage the intended offer before sending the refresh

Asterisk documents the refresh function as especially useful with PJSIP_MEDIA_OFFER(). That companion function changes the audio or video codecs to offer when a session refresh is sent. Record the prior negotiated media, the exact proposed codec list and media type, then write the offer on the same PJSIP channel before triggering the refresh.

Asterisk warns that the refresh function does not check or enforce the formats supported by the endpoint. An unsupported offer can cause media loss. Endpoint configuration, the current negotiated codec and a dynamically proposed offer are separate evidence; one must not be substituted for another.

Respect offer-answer serialization and glare

RFC 3264 permits a new offer to update a session but prohibits an agent from generating another offer while one it sent is unanswered or while a received offer remains unanswered. RFC 3261 uses 491 Request Pending for overlapping re-INVITE transactions. RFC 3311 similarly requires rejection when a new UPDATE offer collides with an outstanding offer-answer exchange.

Serialize application-triggered refreshes with direct-media changes, hold, transfer, session timers and peer-generated renegotiation. A 491, 500 with Retry-After, timeout or transport failure identifies a transaction boundary; it is not permission to create an unbounded immediate retry loop.

Prove the accepted answer and resulting media separately

RFC 3264 treats offer-answer as an atomic exchange: the answer accepts or rejects each stream and identifies codecs, addresses and ports. Capture the sanitized request SDP, final response SDP, selected media formats, direction attributes and connection addresses. If the offer is rejected, the prior session state remains the comparison baseline.

Then verify RTP and RTCP on the same channel segment in both directions and record the audible or application result. A 2xx response, one codec name or a changed SDP version is not proof that packets followed the expected path, that both directions decoded correctly or that a bridged peer heard useful audio.

Keep manual refreshes separate from timer and topology policy

This function sends an immediate application-triggered refresh. It does not prove the negotiated Session-Expires refresher role, repair a session-timer policy, authorize direct media, move every bridge leg or validate NAT and firewall state. Keep timer expiry, direct-media re-INVITEs, hold and transfer signaling and codec-driven refreshes as independently attributable events.

Use a bounded, authorized maintenance path and redact identities and addresses. No PBX, module, endpoint, channel, dialog, request, response, SDP body, RTP stream, packet or call was tested for this guide.

Asterisk dialplan — controlled in-dialog codec refresh
[refresh-controlled]
exten => s,1,NoOp(Refresh current PJSIP channel ${CHANNEL})
 same => n,Set(PJSIP_MEDIA_OFFER(audio)=!all,g722)
 same => n,Set(PJSIP_SEND_SESSION_REFRESH()=invite)
 same => n,Return()

Sources & applicability

Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.

Examples require adaptation to your topology. No live PBX or hardware testing is claimed.

Continue your research

Hub

Asterisk

Understand the programmable PBX and follow the Asterisk 22 LTS documentation baseline.

Explore topic →
Guide · Asterisk 22 LTS

Asterisk PJSIP: understand the configuration objects

Connect endpoint behavior, authentication, contacts and transport without collapsing them into one account setting.

Read guide →
Guide · Asterisk Latest API branch 23 PJSIP_MEDIA_OFFER, PJSIP_SEND_SESSION_REFRESH, Dial and res_pjsip documentation plus current pre-dial, codec-negotiation and codec-module references reviewed October 13, 2026; no Asterisk host, endpoint, channel, dialplan, codec module, offer, answer, refresh, translator, packet, media stream or live call was inspected or tested

Asterisk PJSIP_MEDIA_OFFER: change one outbound codec offer safely

Apply an audio or video offer to the intended outbound PJSIP channel while keeping endpoint policy, pre-dial timing, SDP, answers, translation and later session refreshes independently observable.

Read guide →
Guide · RFC 4028, RFC 3261 and current Asterisk 22 res_pjsip and PJSIP_SEND_SESSION_REFRESH references reviewed October 7, 2026; no Asterisk host, endpoint, trunk, intermediary, dialog, timer, request, response, media stream or live call was inspected or tested

Asterisk PJSIP session timers: endpoint policy, negotiated refresh and expiry

Map Asterisk endpoint timer policy to the Session-Expires, Min-SE and refresher values actually negotiated on each PJSIP call leg.

Read guide →
Guide · RFC 3264 and current Asterisk 22 res_pjsip, NAT, CHANNEL and PJSIP troubleshooting references reviewed October 7, 2026; no Asterisk host, FreePBX system, endpoint, trunk, bridge, NAT device, offer, answer, request, response, packet path, media stream, compatibility, availability or live call was inspected or tested

Asterisk PJSIP direct media: policy, re-INVITE and final RTP path

Separate loaded direct-media policy from the mid-dialog offer/answer and the RTP path that each endpoint actually adopts.

Read guide →
Guide · Current Asterisk 22 res_pjsip and advanced codec-negotiation references plus RFC 3264 reviewed October 7, 2026; no Asterisk host, endpoint, codec module, offer, answer, stream topology, translation path, media packet, resource result, compatibility or live call was inspected or tested

Asterisk PJSIP codec negotiation: four control points, two legs and one resolved topology

Trace incoming offers, outgoing offers, incoming answers and outgoing answers without treating an endpoint allow list as the negotiated result.

Read guide →
Reference · SIP standards; extension support depends on both peers

SDP offer/answer: negotiate one session change at a time

Read codec, address and direction choices as a negotiation rather than two unrelated configuration files.

Read guide →
Troubleshooting · Current Asterisk PJSIP_SEND_SESSION_REFRESH, PJSIP_MEDIA_OFFER and CHANNEL documentation plus RFC 3261, RFC 3311 and RFC 3264 reviewed October 14, 2026; the write-only refresh function is documented since Asterisk 13.12.0 and 14.1.0 and can request re-INVITE or UPDATE on an established media session, but installed module state, channel ownership, peer method support, offer and answer, response handling, RTP path and audible result remain deployment specific, and no PBX, module, endpoint, channel, dialog, request, response, SDP body, RTP stream, packet or call was inspected or tested

Asterisk PJSIP session refresh is rejected or media is lost

Trace the exact channel, method, outstanding offer, request and response SDP, negotiated formats and post-refresh RTP before retrying or changing endpoint policy.

Read guide →