The Session Initiation Protocol (SIP) UPDATE Method
Extracted elements (18)
For the caller, UPDATE can contain an offer before INVITE completion only if the callee generated an answer in a reliable provisional response and the caller has sent/received answers to all prior offers in PRACK or UPDATE. This preserves a consistent offer/answer state per RFC 3261 Section 13.2.1.
The UPDATE method is necessary because early dialog session modification (e.g., hold on early media) cannot be done with re-INVITE, as re-INVITE changes dialog state which is inappropriate before the initial INVITE completes. UPDATE modifies only session state, leaving dialog state untouched.
UPDATE was created because re-INVITE cannot be used to modify session parameters before the initial INVITE completes. Re-INVITE affects dialog state in addition to session state, making it unsuitable for early dialog modifications such as putting early media on hold.
Proxy processing of the UPDATE request is identical to any other non-INVITE request; no special proxy behavior is required for UPDATE.
A UAC compliant to this specification SHOULD include an Allow header field in the INVITE request listing the UPDATE method to indicate its ability to receive an UPDATE request.
A UAS that receives an UPDATE before generating a final response to a previous UPDATE on the same dialog MUST return a 500 response and MUST include a Retry-After header with a randomly chosen value between 0 and 10 seconds.
If a UA receives a non-2xx final response to an UPDATE, the session parameters MUST remain unchanged, as if no UPDATE had been issued.
If a UAC receives a 491 response to an UPDATE, it SHOULD start a retransmit timer T: 2.1–4 seconds if the UAC owns the Call-ID, or 0–2 seconds if it does not. When the timer fires, the UAC SHOULD retry the UPDATE if the modification is still desired.
If an UPDATE containing an offer is received and the UAS has an outstanding unresolved offer it generated, the UAS MUST reject the UPDATE with 491. If the UAS has received an unanswered offer, it MUST reject with 500 and include Retry-After between 0 and 10 seconds.
Unlike re-INVITE, UPDATE MUST be responded to promptly; the user cannot generally be prompted to approve changes. If the UAS cannot change session parameters without user approval, it SHOULD reject with 504. If the new session description is unacceptable, the UAS may return 488 with a Warning header.
UPDATE is a target refresh request. If a UA uses an UPDATE to modify the remote target while an INVITE transaction is in progress and it is a UAS for that INVITE, it MUST place the same Contact value into the 2xx to the INVITE.
UPDATE MAY be sent for both early and confirmed dialogs and by either caller or callee. However, it is RECOMMENDED that re-INVITE be used instead for confirmed dialogs, because UPDATE must be answered immediately without user approval.
Upon receiving an UPDATE for an existing dialog, a UA MUST check version identifiers (or content) of the session description. If changed, the UAS MUST adjust session parameters and generate an answer in the 2xx response.
When a UAS generates a reliable provisional response containing SDP, that response SHOULD contain an Allow header field listing the UPDATE method. A 2xx response SHOULD also contain an Allow header field listing UPDATE.
UPDATE is a SIP method that allows a UA to update session parameters (via SDP offer/answer) within an early or confirmed dialog without affecting the dialog state itself. It can be sent by either caller or callee.
UPDATE is defined by extending the Method BNF from RFC 3261: UPDATEm = %x55.50.44.41.54.45 (UPDATE in caps). Tables 1 and 2 specify the allowed header fields for UPDATE requests and responses.
This document registers the UPDATE request method in the IANA SIP method registry per Section 27.4 of RFC 3261. Method name: UPDATE; Reason Phrase: Not applicable.
The security considerations for UPDATE are identical to those for re-INVITE. UPDATE MUST be integrity protected and authenticated as coming from the same source as the entity on the other end of the dialog; RFC 3261 mechanisms apply.