Asterisk re-INVITEs collide during hold or transfer

Prove the collision on the exact Asterisk leg

Capture one authorized call from answer through the failed hold, resume, transfer or refresh. On the affected dialog, retain Call-ID, both tags, method, CSeq, branch, SDP direction and responder. Locate the earlier in-dialog INVITE or unanswered offer that was still pending when the rejected re-INVITE or UPDATE arrived. A 491 reports that pending-request condition; it does not mean the called party was busy on another call.

Asterisk is a back-to-back user agent, so the phone-facing and trunk-facing dialogs have independent identifiers, transactions and offer state. Follow the PJSIP channel on both legs. A counter containing only 491 cannot show which user agent initiated each change, whether a related overlap should instead have produced 500 or which operation remained incomplete.

Measure protocol recovery instead of suppressing the response

RFC 3261 and RFC 3311 use randomized retry windows to desynchronize the two sides: 2.1 to 4 seconds for the dialog Call-ID owner and 0 to 2 seconds for the other participant. Identify who created the Call-ID, verify the outstanding exchange finishes and then find a new re-INVITE or UPDATE transaction with a higher CSeq if the change is still desired.

An isolated 491 followed by a successful retry can be normal recovery. Repeated responses, an immediate same-CSeq transmission, no retry or a media state that never converges need investigation. The rejected request does not activate its proposed address, direction or codec; compare the retained session with the later successful offer and answer.

Correlate the method and offer with the trigger

Compare the trace timestamp with user and Asterisk events. Hold and resume can create an offer; attended transfer can produce closely timed changes; direct-media setup can prompt a re-INVITE soon after answer; connected-line updates may use UPDATE; session refresh and an application-controlled change are other distinct triggers. State which one the messages prove.

Do not label every mid-dialog request as direct media. Compare SDP, Session-Expires, identity headers and the loaded endpoint. An UPDATE without SDP and a re-INVITE moving RTP solve different problems even when either happens near the same button press. Asterisk's direct-media glare setting cannot repair an unrelated peer retry bug or every offer collision.

Inspect the loaded PJSIP controls by purpose

For each Asterisk leg, inspect the loaded endpoint. direct_media controls whether media may flow directly, direct_media_method chooses INVITE or UPDATE for that setup, and direct_media_glare_mitigation can suppress direct-media re-INVITEs in one direction. Asterisk documents none, outgoing and incoming; this setting assigns direct-media initiation ownership and is not a generic SIP retry timer.

Inspect connected_line_method separately. Its invite mode can select UPDATE when the remote Allow header permits it, while explicit update sends UPDATE regardless of that advertised list. Do not copy a method or mitigation direction from another topology. In FreePBX, identify the supported setting owner, apply generated configuration and verify the running endpoint instead of editing generated PJSIP files.

Correct one demonstrated owner and prove convergence

If a peer fails to retry correctly, use its current vendor guidance and firmware path. If two controlled Asterisk peers repeatedly initiate direct media together, assign and document a supported ownership direction for the demonstrated topology. If UPDATE selection is the mismatch, change only the option that owns that request. Evaluate disabling direct media as a design decision, not as proof that it caused every 491.

Repeat the same hold, resume, transfer or refresh in both call directions. Confirm the prior transaction or offer completes, the randomized retry uses a new transaction, the requested state converges, two-way audio continues and hangup succeeds. Then repeat an ordinary call that does not trigger the feature. No PBX, endpoint, provider, direct-media path, retry, offer, transfer, refresh, media path or live call was tested for this guide.

Separate direct-media policy from the glare transaction

The direct-media guide establishes which leg attempted a media move and what SDP it offered. Glare mitigation controls initiation ownership for that path; it does not replace the ordered transaction and offer-state evidence required for a 491 or 500.

Separate an intercepted request from a peer-facing hold re-INVITE

The HOLD_INTERCEPT diagnostic proves whether an authorized consumer later generated a hold action before treating simultaneous SIP refreshes as glare.

Include application-triggered session refreshes in the glare timeline

The PJSIP session-refresh diagnostic identifies manual re-INVITE or UPDATE actions alongside timer, hold, transfer and direct-media transactions.

Place hold passthrough in the transaction timeline

The PJSIP hold diagnostic records the effective channel mode and hold owner before treating a colliding in-dialog request as a generic glare problem.