Re-INVITE vs UPDATE

1. What each method does

Both re-INVITE and UPDATE modify an established SIP session. They differ in three key ways:

The most important practical difference is that UPDATE works in early dialogs (before answer) while re-INVITE does not. This matters for negotiating session parameters during ringing — for example, codec changes that need to take effect before the user picks up.

2. Re-INVITE in detail

Re-INVITE is a regular INVITE sent within an established dialog. It carries the same Call-ID and From-tag as the original, plus the To-tag established at confirmation. The CSeq increments.

Re-INVITE follows the full INVITE transaction lifecycle:

1. Re-INVITE sent with new SDP
2. Recipient may send 1xx provisional responses
3. Recipient sends 2xx with new SDP (or rejects with 4xx/5xx/6xx)
4. Sender sends ACK
5. New session parameters take effect

The most common uses of re-INVITE:

• Hold and unhold: Send re-INVITE with a=sendonly (or a=inactive) for hold; a=sendrecv for unhold
• Codec change: Renegotiate the codec list in SDP
• Media bypass: Switch from media anchored at SBC to direct media between endpoints
• Session refresh: Per RFC 4028 session timers, periodic re-INVITE keeps the dialog alive

If the recipient rejects re-INVITE, the dialog continues with the previous parameters. Failure of a re-INVITE does not terminate the call.

3. UPDATE in detail

UPDATE is similar to re-INVITE but designed specifically for cases where re-INVITE is not appropriate. RFC 3311 introduced it to solve two problems with re-INVITE:

Problem 1: re-INVITE not allowed in early dialogs

Before answer, the original INVITE transaction is still pending. Sending another INVITE for the same dialog would be ambiguous — is it a re-INVITE or a duplicate? RFC 3261 forbids re-INVITE in early dialogs. UPDATE works in early dialogs because it is a different transaction that does not conflict.

Problem 2: re-INVITE requires reliable provisional responses to be safe

If a re-INVITE could be sent in early dialogs, the response would have to be reliable (PRACK) to know it was received. UPDATE sidesteps this by being its own transaction with its own response.

UPDATE flow

1. UPDATE sent with new SDP
2. Recipient sends 200 OK with new SDP (or 4xx/5xx/6xx for rejection)
3. No ACK required
4. New parameters take effect

UPDATE is shorter and simpler than re-INVITE. The lack of ACK and provisional responses means it is faster, with less risk of mid-update interruption.

4. Choosing between them

The decision tree:

Use UPDATE when

• You need to modify session parameters before the call is answered (early dialog)
• The session refresh is small (timer refresh per RFC 4028)
• You want to avoid the full INVITE transaction overhead
• Both endpoints advertise UPDATE in their Allow header

Use re-INVITE when

• The session is in confirmed state and needs renegotiation
• The change is significant (codec change, media path change)
• You need provisional responses during the change (PRACK with 100rel)
• Endpoint compatibility with UPDATE is uncertain

RFC 4028 (session timers) recommends UPDATE if both sides support it for refresh, falling back to re-INVITE if not. This is one of the cleanest examples of UPDATE's intended use.

5. Interoperability and support gaps

UPDATE is not as universally supported as re-INVITE. The reasons are historical: re-INVITE was in RFC 3261 from the start, while UPDATE was added later in RFC 3311. Implementations from before UPDATE was widely adopted may not support it.

Endpoints advertise UPDATE support via the Allow header. Sending UPDATE to an endpoint that does not list it in Allow risks 405 Method Not Allowed. The fix is to fall back to re-INVITE.

Common interop issues:

6. Diagnosing re-INVITE/UPDATE in a trace

What to look for in a trace involving session changes:

• Allow header: Each side's INVITE and 200 OK should list supported methods. If UPDATE is not in Allow, sending it is wrong.
• Method used in mid-dialog change: Identify whether re-INVITE or UPDATE is being used. If re-INVITE in an early dialog, that is incorrect.
• SDP changes: Compare SDP before and after to understand what is changing — codec, media direction, IP/port, etc.
• 491 Request Pending: Indicates glare. See the 491 Request Pending guide for resolution.
• 405 Method Not Allowed in response to UPDATE: The recipient does not support UPDATE despite (or contrary to) what the Allow header indicated.
• Session timer Refresher header: If RFC 4028 session timers are negotiated, the Refresher header indicates which side is responsible for refresh. The chosen method (re-INVITE or UPDATE) for refresh should match Allow capabilities.

Frequently asked questions

What is the difference between SIP re-INVITE and UPDATE?

Re-INVITE is a full INVITE transaction sent within an established dialog. It works in confirmed dialogs only and requires ACK. UPDATE was defined in RFC 3311 to allow session parameter changes in both early and confirmed dialogs without requiring ACK. UPDATE is faster and works before call answer, but is not as universally supported as re-INVITE.

When should I use UPDATE instead of re-INVITE?

Use UPDATE when modifying session parameters before the call is answered (in an early dialog), for session timer refresh per RFC 4028, or when you want a lighter transaction without ACK overhead. Use re-INVITE when the dialog is confirmed and you need full provisional response support, when endpoint UPDATE support is uncertain, or for significant changes like media path switches that benefit from PRACK.

Can SIP re-INVITE be used in early dialogs?

No. RFC 3261 forbids re-INVITE in early dialogs because the original INVITE transaction is still pending and a second INVITE for the same dialog would be ambiguous. UPDATE was specifically added in RFC 3311 to allow session parameter changes in early dialogs. If you need to renegotiate codecs or media before the call is answered, use UPDATE.