SIP UPDATE Method (RFC 3311): Modifying Session Parameters Before Call Establishment

Overview

Key takeaways

• UPDATE allows SDP modifications during the early dialog state before a final 2xx response to the initial INVITE is sent.
• Unlike re-INVITE, UPDATE does not alter the dialog's state machine or require a full call setup completion before execution.
• Requires support advertising via the Allow header ('Allow: UPDATE') and typically depends on reliable provisional responses (RFC 3262 / 100rel).
• Proper implementation prevents race conditions like 491 Request Pending during pre-answer session renegotiation.
• UPDATE can be sent by either the User Agent Client (UAC) or User Agent Server (UAS) once an early dialog is established.

Prerequisites

• Fundamental understanding of SIP core concepts (RFC 3261), initial INVITE transactions, and dialog creation.
• Familiarity with the SDP Offer/Answer model (RFC 3264).
• Basic knowledge of reliable provisional responses (RFC 3262 / PRACK).

Guide

1. section #1
   1. Architectural Motivation for RFC 3311 In standard RFC 3261 SIP, modifying an ongoing session requires sending a re-INVITE. However, a re-INVITE can only be issued after the initial INVITE transaction completes with a 2xx final response and an ACK. In modern telecommunication networks, session parameters—such as audio/video codecs, IP/port endpoints, or encryption keys (SRTP)—frequently need to be negotiated while the call is still ringing (the early dialog state). RFC 3311 introduces the UPDATE method to solve this limitation, enabling symmetric offer/answer exchanges before the call is answered without disrupting the pending INVITE state machine.
2. section #2
   2. UPDATE vs. re-INVITE and PRACK It is critical to distinguish UPDATE from both re-INVITE and PRACK (RFC 3262). While PRACK provides reliable transmission of 1xx provisional responses, its capacity to carry SDP offers and answers is limited by strict sequencing rules tied to provisional response acknowledgments. Conversely, re-INVITE updates session state but is strictly blocked until the initial 200 OK / ACK handshakes complete. UPDATE bridges this gap: it carries an SDP offer/answer pair independently of provisional responses, operates in both early and confirmed dialogs, and does not trigger call-state transitions like answer timer resets or ringback generation.
3. section #3
   3. Offer/Answer Execution within Early Dialogs An UPDATE request can be issued by either the UAC or UAS as soon as an early dialog is created (typically via a 1xx provisional response containing a To tag). Both the UPDATE request and its 200 OK response follow standard RFC 3264 Offer/Answer rules. If an UPDATE is sent while an offer/answer exchange is already in progress (for instance, an SDP offer in the INVITE that has not yet received an SDP answer in a provisional response), the receiving endpoint must reject the UPDATE with a 491 (Request Pending) or 500 (Server Internal Error) status code to prevent glare.
   sipcopy

   UPDATE sip:alice@example.com SIP/2.0
   Via: SIP/2.0/UDP 192.168.1.100:5060;branch=z9hG4bK776asdhds
   Max-Forwards: 70
   From: <sip:bob@example.com>;tag=1928301774
   To: <sip:alice@example.com>;tag=a6c85cf
   Call-ID: a84242363241900010x8170
   CSeq: 102 UPDATE
   Contact: <sip:bob@192.168.1.100:5060>
   Accept: application/sdp
   Content-Type: application/sdp
   Content-Length: 218
   
   v=0
   o=bob 2890844527 2890844528 IN IP4 192.168.1.100
   s=-
   c=IN IP4 192.168.1.100
   t=0 0
   m=audio 49170 RTP/AVP 0 101
   a=rtpmap:0 PCMU/8000
   a=rtpmap:101 telephone-event/8000
   a=fmtp:101 0-15
   a=sendrecv

4. section #4
   4. Call Flow Scenario: Early Media Parameter Changes Consider a scenario where an initial INVITE contains an SDP offer specifying G.711. The UAS responds with a 183 Session Progress (with 100rel) establishing an early dialog and sending its SDP answer. Later, an intermediate Session Border Controller (SBC) or the UAC needs to redirect the media stream to a Media Server for ringback tone generation prior to answer. The UAC sends an UPDATE with updated media IP and port parameters. The UAS accepts the update with a 200 OK (UPDATE), routing early media correctly before the final 200 OK (INVITE) is ever sent.
   textcopy

   UAC                                  UAS / SBC
    |                                       |
    |--- INVITE (SDP Offer 1: G.711) ------>|
    |<-- 183 Session Progress (SDP Ans 1) --| (Early Dialog Created)
    |--- PRACK ---------------------------->|
    |<-- 200 OK (PRACK) --------------------|
    |
    |--- UPDATE (SDP Offer 2: IP/Port Change)->|
    |<-- 200 OK (SDP Answer 2) -------------| (Session Updated in Early State)
    |
    |<-- 180 Ringing -----------------------|
    |<-- 200 OK (INVITE) -------------------| (Call Answered)
    |--- ACK ------------------------------>|
    |

5. section #5
   5. Signaling Negotiation and Protocol Headers To safely use UPDATE, User Agents must declare support for the method using the Allow header in initial requests and responses (e.g., 'Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDATE'). If a UAC sends an UPDATE to an endpoint that does not support it, the recipient returns a 405 (Method Not Allowed) status code along with an Allow header indicating its supported methods. Endpoints should also advertise support for '100rel' in the Supported header to ensure reliable early dialog creation, which forms the stable foundation required for UPDATE exchanges.
   sipcopy

   SIP/2.0 183 Session Progress
   Via: SIP/2.0/UDP 192.168.1.100:5060;branch=z9hG4bK776asdhds;received=192.168.1.100
   From: <sip:bob@example.com>;tag=1928301774
   To: <sip:alice@example.com>;tag=a6c85cf
   Call-ID: a84242363241900010x8170
   CSeq: 101 INVITE
   Require: 100rel
   RSeq: 1
   Allow: INVITE, ACK, CANCEL, BYE, OPTIONS, UPDATE, PRACK
   Content-Type: application/sdp
   Content-Length: ...
   
   [SDP Answer]

6. section #6
   6. Common Implementation Pitfalls and Glare Handling A frequent operational issue with UPDATE is glare, occurring when both endpoints issue an UPDATE or when an UPDATE collides with a pending initial INVITE SDP exchange. According to RFC 3311, if an UPDATE is received while another offer/answer transaction is uncompleted, the recipient MUST respond with a 491 (Request Pending). Both UAs must then execute randomized back-off timers (as specified in RFC 3264) before retrying the UPDATE. Designers should also avoid sending an UPDATE immediately prior to call answer, as racing 200 OK (INVITE) and 200 OK (UPDATE) responses can confuse non-compliant SIP stacks.

Further reading

• RFC 3311 - The Session Initiation Protocol (SIP) UPDATE Method
• RFC 3261 - SIP: Session Initiation Protocol
• RFC 3262 - Reliability of Provisional Responses in SIP (100rel/PRACK)
• RFC 3264 - An Offer/Answer Model with the Session Description Protocol (SDP)