RFC 3311 The Session Initiation Protocol (SIP) UPDATE Method UPDATE allows a client to update parameters of a session (such as the set of media streams and their codecs) but has no impact on the state of a dialog. But unlike re-INVITE, it can be sent before the initial INVITE has been completed. This makes it very useful for updating session parameters within early dialogs. Because re-INVITE may have an impact both on the state of session and dialog. But while early dialog, the dialog hasn't confirmed. So UPDATE is used to only modify the session state under that condition. Although UPDATE can be used on confirmed dialogs, it is RECOMMENDED that a re-INVITE be used instead. This is because an UPDATE needs to be answered immediately, ruling out the possibility of user approval. Such approval will frequently be needed, and is possible with a re- INVITE. 1 Overview of Operation Once a dialog is established, either early or confirmed, the caller or the callee can generate an UPDATE method that contains an SDP offer for the purposes of updating the session. The Allow header field is used to indicate support for the UPDATE method. There are additional constraints on when UPDATE can be used, based on the restrictions of the offer/answer model. 2 Determining Support for UPDATE Both to caller and callee, creation of early dialog is necessary in order to receive UPDATE requests. UAC SHOULD include an Allow header field in the INVITE request, listing the method UPDATE, to indicate its ability to receive an UPDATE request. When UAC receives an INVITE request for a new dialog, and generates a reliable provisional response containing SDP, that response SHOULD contain an Allow header field that lists the UPDATE method. An unreliable provisional response MAY contain an Allow header field listing the UPDATE method, and a 2xx response SHOULD contain an Allow header field listing the UPDATE method. 3 UPDATE Handling 3.1 Offer/Answer Model 3.1.1 for the Caller o The UPDATE can be sent with an offer in early dialog, only after the offer in initial INVITE has been answered in a reliable provisional response, and there is no pending offers on the both side of caller and callee. o The UPDATE can be sent with an offer in early dialog, only after the offer in a reliable provisional response has been answered in corresponding PRACK, and there is no pending offers on the both side of caller and callee. o The UPDATE can be sent with an offer in confirmed dialog, only if there isn't anying pending offers in a re-INVITE or UPDATE. 3.1.2 for the Callee o The UPDATE can be sent with an offer in early dialog, only after the offer in initial INVITE has been answered in a realiable provisional response, and has received a PRACK for that reliable provisional response, and there is no pending offers on the both side of caller and callee. o The UPDATE can be sent with an offer in early dialog, only after the offer in reliable provisional response has been answered in corresponding PRACK, and there is no pending offers on the both side of caller and callee. o The UPDATE can be sent with an offer in confirmed dialog, only if there isn't anying pending offers in a re-INVITE or UPDATE. 3.2 Sending an UPDATE The UPDATE request is constructed as would any other request within an existing dialog. It MAY be sent for both early and confirmed dialogs, and MAY be sent by either caller or callee. UPDATE is a target refresh request. A UAS for INVITE transaction MUST place the same value into the Contact header field of the 2xx to the INVITE that it placed into the UPDATE request or response. 3.3 Receiving an UPDATE The UPDATE is processed as any other mid-dialog target refresh request. Unlike a re-INVITE, the UPDATE MUST be responded to promptly, and therefore the user cannot generally be prompted to approve the session changes. 3.3.1 2xx response If a UA receives an UPDATE for an existing dialog, it MUST check any version identifiers in the session description or, if there are no version identifiers, the content of the session description to see if it has changed. If the session description has changed, the UAS MUST adjust the session parameters accordingly and generate an answer in the 2xx response. 3.3.2 488 Not Acceptable Here If the new session description is not acceptable, the UAS can reject it by returning a 488 (Not Acceptable Here) response for the UPDATE. This response SHOULD include a Warning header field. 3.3.3 491 Request Pending If an UPDATE is received which contains an offer, and the UAS has generated an offer (in an UPDATE, PRACK or INVITE) to which it has not yet received an answer, the UAS MUST reject the UPDATE with a 491 response. 3.3.4 500 Server Internal Error If has received an offer and hasn't answered yet, the UAS MUST reject any consequent UPDATE with 500 response, and MUST include a Retry- After header filed with a randomly chosen value between 0 and 10 seconds. 3.3.5 504 Server Timeout If the UAS cannot change the session parameters without prompting the user, it SHOULD reject the request with a 504 response. 3.4 Processing the UPDATE Response Processing of the UPDATE response at the UAC follows the rules in Section 12.2.1.2 of RFC 3261 [1] for a target refresh request. If a UA receives a non-2xx final response to a UPDATE, the session parameters MUST remain unchanged, as if no UPDATE had been issued. Note that, as stated in Section 12.2.1 of RFC 3261 [1], if the non- 2xx final response is a 481 (Call/Transaction Does Not Exist), or a 408 (Request Timeout), or no response at all is received for the UPDATE (that is, a timeout is returned by the UPDATE client transaction), the UAC will terminate the dialog. If a UAC receives a 491 response to a UPDATE, it SHOULD start a timer with a value T chosen as follows: 1. If the UAC is the owner of the Call-ID of the dialog ID (meaning it generated the value), T has a randomly chosen value between 2.1 and 4 seconds in units of 10 ms. 2. If the UAC is not the owner of the Call-ID of the dialog ID, T has a randomly chosen value between 0 and 2 seconds in units of 10 ms. When the timer fires, the UAC SHOULD attempt the UPDATE once more, if it still desires for that session modification to take place. For example, if the call was already hung up with a BYE, the UPDATE would not take place. 4 Proxy Behavior Same as non-INVITE request.ake place. For example, if the call was already hung up with a BYE, the UPDATE would not take place. 4 Proxy Behavior Same as non-INVITE request.request.ake place. For example, if the call was already hung up with a BYE, the UPDATE would not take place. 4 Proxy Behavior Same as non-INVITE request.