Bind 491 to one dialog and one method
RFC 3261 defines 491 when a user agent receives an in-dialog INVITE while an INVITE it sent on the same dialog is still in progress. RFC 3311 extends the offer-overlap handling to UPDATE: an UPDATE containing an offer receives 491 when the UAS has generated an offer in UPDATE, PRACK or INVITE and has not yet received its answer. This is a pending same-dialog change, not evidence that the destination is busy with another telephone call.
Preserve Call-ID, both tags, method, CSeq, branch, SDP direction and the responding address. Find the earlier outstanding offer or INVITE on that exact dialog. On a B2BUA, repeat the analysis on the other call leg rather than assuming the same method, CSeq or timing crossed it unchanged.
Distinguish 491 from the related 500 overlap
The response depends on who already has which transaction or offer pending. RFC 3261 requires 500 with a randomized Retry-After when a UAS receives a second same-dialog INVITE before it has sent the final response to the earlier lower-CSeq INVITE. The cross-direction INVITE collision uses 491. RFC 3311 likewise uses 500 for a second UPDATE before the prior UPDATE receives a final response and for one received offer-overlap direction, while the opposite outstanding-offer direction uses 491.
Do not rewrite every 500 as glare or every 491 as direct media. Reconstruct the ordered messages and offer/answer state first. A rejected change leaves the prior session parameters in force; proposed address, direction or codec values do not become active merely because they appeared in the failed request.
Verify the randomized retry and final state
After 491, RFC 3261 and RFC 3311 specify a randomized retry timer: 2.1 to 4 seconds when the requester owns the dialog Call-ID, or 0 to 2 seconds when it does not. When the timer fires, the user agent retries once only if the session change is still desired. An immediate synchronized retry can recreate the collision, while a BYE may make the change irrelevant.
Record the new re-INVITE or UPDATE transaction, its higher CSeq, the final response and the media state that actually converges. An isolated recovered 491 can be normal protocol recovery; repeated 491s, missing retries or a hold, resume, transfer or refresh that never completes need the focused Asterisk investigation. Preserve a bounded redacted trace instead of a status counter.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- IETF RFC 3261: re-INVITE overlap, 491 and randomized retry ↗
- IETF RFC 3311: UPDATE offer overlap and 491 retry ↗
- IETF RFC 5407: re-INVITE glare and retry examples ↗
- IETF RFC 6141: re-INVITE handling and glare recovery ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.