SIP 491 Request Pending

1. What SIP 491 means

SIP 491 Request Pending is defined in RFC 3261 section 14.1. It is sent in response to a re-INVITE when there is already another re-INVITE pending in the same dialog and the receiver has not yet sent its final response to the first one.

491 only applies to re-INVITEs (also called mid-dialog INVITEs) — INVITEs sent inside an established call to renegotiate the session. Initial INVITEs that establish a dialog do not get 491; they get other responses depending on what the dialog is doing.

Common reasons for re-INVITE include hold/unhold, codec change, media bypass triggers, transfer attempts, and SDP refresh. Any of these on both sides simultaneously can produce 491.

2. Glare and the re-INVITE collision

Glare is the SIP term for two re-INVITEs crossing in flight. Both endpoints decide to renegotiate at almost the same moment. Each sends a re-INVITE without knowing the other has done the same. The result: each side receives an unexpected re-INVITE while expecting a response to its own.

Without a defined resolution, both sides would either reject the other's re-INVITE or attempt to apply both, leading to inconsistent media state. RFC 3261 defines 491 plus a retry timer to resolve the collision deterministically.

3. How RFC 3261 resolves glare

The endpoint that receives 491 must wait a randomized time interval before retrying its re-INVITE. The interval depends on which side of the dialog the endpoint is on:

• UAC (the side that originally initiated the dialog): wait a random number of milliseconds between 2.1 and 4.0 seconds
• UAS (the side that originally received the dialog): wait a random number of milliseconds between 0 and 2.0 seconds

The asymmetric ranges mean the UAS retries first and almost always wins the second round, after which the UAC's re-INVITE arrives at a clear dialog state and succeeds. The randomization prevents lockstep retry collisions if both sides have similar timer behavior.

If 491 keeps repeating, one of the endpoints is not honoring the retry timer correctly, or an intermediary is interfering with the timing.

4. Common causes of repeated 491

5. SBCs and the glare retry timer

SBCs sit in the middle of dialogs as B2BUAs (back-to-back user agents). That means they have their own re-INVITE state on each leg, independent of the endpoints. A 491 on the inside leg and a 491 on the outside leg are separate events, and the SBC must handle each according to RFC 3261 timing.

Two common SBC misbehaviors lead to repeating 491:

• Pass-through 491: The SBC forwards 491 from one side to the other instead of buffering and retrying locally. The endpoint then has to deal with glare on what should be a single-leg dialog from its perspective. This often confuses endpoints that don't expect 491 from a server they treat as the call origin.
• Synchronized retries: The SBC and the endpoint both pick retry intervals from the same range, removing the asymmetric resolution. The collision repeats indefinitely until one side gives up.

If 491 loops appear only with traffic through a specific SBC, audit the SBC's re-INVITE handling and consider disabling features (codec switching, media anchoring) that issue extra re-INVITEs during call setup.

6. Diagnosing 491 from a SIP trace

491 in a healthy SIP environment should be rare and self-resolving. When investigating 491, check:

• Is it a single 491 followed by success? That is normal glare resolution. No action needed.
• Are 491s repeating in a loop? Indicates one or both sides are not honoring the retry timer or are picking the wrong range.
• How long between the 491 and the retry? The retry must be at least 0 to 4 seconds depending on UAC/UAS role. Retries faster than 100ms or slower than 4 seconds are anomalous.
• What triggered the original re-INVITE? Hold, codec change, media anchor — each has different fix paths. Check the SDP a=sendrecv/sendonly/inactive lines and codec list to identify which.
• Are both sides sending re-INVITE for the same reason? If both endpoints simultaneously send re-INVITE for a hold action, one of them is probably misinterpreting the other side's request.
• CSeq progression: CSeq must increment for each new re-INVITE attempt. Reused CSeqs cause receiver confusion.

Frequently asked questions

What does SIP 491 Request Pending mean?

SIP 491 Request Pending means a re-INVITE arrived while another re-INVITE was already pending on the same dialog. This is called glare — both sides of a call tried to renegotiate the session at the same time. RFC 3261 defines a randomized retry timer to resolve the collision automatically. A single 491 followed by a successful retry is normal.

Is SIP 491 a problem?

A single 491 followed by a successful retry is not a problem — it is the protocol working as designed to resolve glare. Repeated 491 responses without resolution indicate a real issue, usually a SIP stack that does not honor the retry timer correctly, both endpoints picking the same retry range, or an SBC that issues conflicting re-INVITEs.

How long should an endpoint wait after receiving SIP 491?

RFC 3261 requires UACs (the side that originally sent the initial INVITE) to wait a random time between 2.1 and 4.0 seconds before retrying. UASs (the side that originally received the initial INVITE) wait between 0 and 2.0 seconds. The asymmetric ranges ensure the UAS retries first, clearing the dialog state for the UAC's retry to succeed.