Internet Engineering Task Force SIP WG Internet Draft J. Rosenberg dynamicsoft [-draft-ietf-sip-update-01.txt March 1,-] {+draft-ietf-sip-update-02.txt April 30,+} 2002 Expires: [-September-] {+October+} 2002 The [-SIP-] {+Session Initiation Protocol+} UPDATE Method STATUS OF THIS MEMO This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt To view the list Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. Abstract This specification defines the new UPDATE method for the Session Initiation Protocol (SIP). UPDATE allows a client to update parameters of a session (such as the set of media streams and their [-codecs), or update SIP level information (such as credentials),-] {+codecs)+} but has no impact on the state of a dialog. [-This-] {+In that sense, it+} is [-very useful for updating information about-] {+like+} a [-call-] {+re-INVITE, but can be sent+} before the [-call-] {+initial INVITE+} has [-been accepted.-] {+completed. This makes it very useful for updating session parameters within early dialogs.+} J. Rosenberg [Page 1] Internet Draft update [-March 1,-] {+April 30,+} 2002 Table of Contents 1 Introduction ........................................ 3 2 Terminology ......................................... [-4-] 3 [-Definitions ......................................... 4 4-] {+3+} Overview of Operation ............................... {+3 4 Determining Support for this Extension ..............+} 4 5 [-UA Behavior ......................................... 5 5.1 Initiating a Dialog ................................. 5 5.2 Generating a Provisional Response ................... 5 5.2.1 Requesting an Update ................................ 6 5.2.2 Continuing With the Dialog .......................... 6 5.3 Processing Provisional Responses .................... 6 5.3.1 Processing the 155 .................................. 7 6-] UPDATE Handling ..................................... [-8 6.1-] {+4 5.1+} Sending an UPDATE ................................... [-8 6.1.1 Specifics for INVITE ................................ 8 6.1.2 Specifics for SUBSCRIBE ............................. 9 6.2-] {+4 5.2+} Receiving an UPDATE ................................. [-9 6.2.1 Specifics for INVITE ................................ 10 6.2.2 Specifics for SUBSCRIBE ............................. 11 7-] {+6 5.3 Processing the UPDATE Response ...................... 6 6+} Proxy Behavior ...................................... [-11 8-] {+7 7+} Definition of the UPDATE method ..................... [-11 9 Definition of the 155 (Update Requested) Response ................................................................ 13 10-] {+7 8+} Example Call Flow ................................... [-13 11-] {+7 9+} Security Considerations ............................. [-14 12-] {+11 10+} IANA Considerations ................................. [-14 12.1 update Option Tag ................................... 14 12.2 UPDATE Request Method ............................... 14 12.3 155 Response Code ................................... 16 13-] {+11 11+} Acknowledgements .................................... [-16 14-] {+11 12+} Author's Addresses .................................. [-16 15-] {+11 13+} Normative References ................................ [-16 16-] {+11 14+} Informative References .............................. [-17-] {+12+} J. Rosenberg [Page 2] Internet Draft update [-March 1,-] {+April 30,+} 2002 1 Introduction (Note to RFC Editor: replace all instances of BBBB in this specification with the RFC number of draft-ietf-sip-rfc2543bis, all all instances of OOOO with the RFC number of draft-ietf-mmusic-sdp- offer-answer) The Session Initiation Protocol (SIP) [-[2]-] {+[1]+} defines the INVITE method for the initiation and modification of sessions. However, this method actually affects two important pieces of state. It impacts the session (the media streams SIP sets up) and also the dialog (the state that SIP itself defines). While this is reasonable in many cases, there are important scenarios where [-it-] this coupling causes complications. The primary difficulty is when aspects of the session need to be modified before the initial INVITE has been answered. An example of this situation is "early media", a condition where the session is established, for the purpose of conveying progress of the call, {+but+} before the INVITE itself is accepted. It is important [-to-] {+that either caller or callee+} be able to modify the characteristics of that session (putting the early media on hold, for example), before the call is answered. However, a [-re- INVITE-] {+re-INVITE+} cannot be used for this purpose, because the re-INVITE has an impact on the state of the dialog, in addition to the session. [-Another difficulty is when an INVITE is rejected, not because the call is declined, but because some aspect of the request was not acceptable, and-] {+As+} a [-proxy on the call path was attempting to provide-] {+result,+} a [-service that requires forking. That rejection won't be forwarded upstream by the proxy unless all other branches reject the request. That may never happen. The result-] {+solution+} is {+needed+} that {+allows+} the caller [-never has an opportunity to update its request-] {+or callee+} to [-make it acceptable-] {+provide updated session information before a final response+} to the [-rejecting party. Even if the rejection-] {+initial INVITE request+} is [-passed upstream immediately, there-] {+generated. The UPDATE method, defined here, fulfills that need. It+} can be [-problems. The rejection of the INVITE will trigger the caller to try again, resulting in a re-invocation of the forking service at the proxy. That re-invocation will frequently result in undesirable side-effects. These two problems have been referred to by the SIP community as the "Heterogeneous Error Response Forking Problem", or HERFP. In both cases, a solution is needed that allows the caller to provide updated information to the recipients of the request, before a final response to the initial request is generated. The UPDATE method, defined here, fulfills that need. It can be sent by-] {+sent by+} a UA within a dialog (early or confirmed), to update either session parameters [-or SIP information,-] without impacting the dialog state itself. [-This specification also defines the 155 (Update Requested) response, which can be used by the UAS to inform the UAC of a condition that prevents J. Rosenberg [Page 3] Internet Draft update March 1, 2002 it from processing the request, but which can be corrected with an UPDATE.-] 2 Terminology In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [-[1]-] {+[2]+} and indicate requirement levels for compliant SIP implementations. 3 [-Definitions Repairable Error Response: An error response in the 4xx class which indicates that the request was unacceptable for some reason which can be repaired by automated processing at the UAC. For the 4xx response codes defined in RFC BBBB [2], this includes the 401, 415, 416, 420, 423 and 488 responses. However, SIP extensions can define additional error codes with this property, and those are covered by this specification. 4-] Overview of Operation [-When a UAC sends-] {+Operation of this extension is straigthforward. The caller begins with+} an [-INVITE, it includes-] {+INVITE transaction, which proceeds normally. Once+} a [-Supported tag in-] {+dialog is established, either early or confirmed,+} the [-request-] {+caller can generate an UPDATE method+} that contains {+an SDP offer [3] for+} the [-option tag "update". This option tag indicates that-] {+purposes of updating+} the [-UAC understands-] {+session. The response to+} the [-mechanisms defined in this specification. When-] {+UPDATE method contains+} the [-UAS gets that request, it performs-] {+answer. Similarly, once a dialog is established,+} the [-processing defined-] {+callee can send J. Rosenberg [Page 3] Internet Draft update April 30, 2002 an UPDATE with an offer, and the caller places its answer+} in [-Section 8.2 of RFC BBBB [2]. This processing may determine that-] the [-request is acceptable, and therefore-] {+2xx to+} the [-user is alerted (or some other appropriate action-] {+UPDATE. The Allow header+} is [-taken), or the processing may determine that-] {+used to indicate support for+} the [-request cannot-] {+UPDATE method. There are additional constraints on when UPDATE can+} be [-processed further without some kind-] {+used, based on the restrictions+} of [-change. In-] the [-former case,-] {+offer/answer model. 4 Determining Support for this Extension The initiation of a session operates as specified in RFC BBBB [1]. However, a UAC compliant to this specification SHOULD also include an Allow header field in the request, listing+} the {+method UPDATE, to indicate its ability to receive an UPDATE request. When a+} UAS {+compliant to this specification receives an INVITE request for a new dialog, and+} generates a reliable provisional response [-[3]. The provisional-] {+containing SDP, that+} response [-establishes an early dialog. It contains-] {+SHOULD contain+} an Allow header [-listing-] {+field that lists+} the [-methods supported by-] {+UPDATE method. This informs+} the [-server. Among them will be-] {+caller that+} the {+callee is capable of receiving an+} UPDATE [-method. At-] {+request at+} any [-time thereafter,-] {+time. An unreliable provisional response MAY contain an Allow header listing+} the [-UAC can generate-] {+UPDATE method, and a 2xx response SHOULD contain+} an {+Allow header listing the+} UPDATE [-method-] {+method. Responses are processed normally as per RFC BBBB [1], and in the case of reliable provisional responses, according to [4]. It is important to note+} that [-contains-] {+a reliable provisional response will always create+} an [-SDP offer [4] for-] {+early dialog at+} the [-purposes-] {+UAC. Creation+} of [-updating the session. The response-] {+this dialog is necessary in order+} to [-the-] {+receive+} UPDATE [-method-] {+creates from the callee. If the response+} contains {+an Allow header containing+} the [-answer. Similarly,-] {+value "UPDATE", the UAC knows that+} the callee [-can send an UPDATE with an offer,-] {+supports UPDATE,+} and the [-caller places its answer in-] {+UAC is allowed to follow+} the [-2xx.-] {+procedures of Section 5.1. 5 UPDATE Handling 5.1 Sending an UPDATE+} The UPDATE [-method can also update other information provided in previous requests, such-] {+request is constructed+} as [-a new Call-Info or Alert-Info header. In the latter case, the-] {+would any other+} request [-might-] {+within an existing dialog, as described in Section 12.2.1 of RFC BBBB. It MAY+} be [-unacceptable because it does not contain proper credentials, contains content not understood by the UAS, requests service-] {+sent for both early and confirmed dialogs. Although UPDATE can be used+} on {+confirmed dialogs, it is RECOMMENDED that+} a [-URI with a scheme not supported by the server, mandates-] {+re-INVITE be used instead. This is because+} an [-extension not supported by-] {+UPDATE needs to be answered immediately, ruling out+} the [-UAS, requests-] {+possibility of user approval. Such approval will frequently needed, and is possible with+} a {+re-INVITE. The UAC MAY add optional headers for the UPDATE request, as defined in Tables 1 and 2. The rules for inclusion of offers and answers in SIP messages as defined in Section 13.2.1 of RFC BBBB still apply. These rules exist+} J. Rosenberg [Page 4] Internet Draft update [-March 1,-] {+April 30,+} 2002 [-creation of soft state with a refresh interval that is too brief, or contains-] {+to guarantee+} a {+consistent view of the+} session [-description that-] {+state. This means that, for the caller: o If the UPDATE+} is [-not acceptable. Rather than rejecting-] {+being sent before completion of+} the [-request with a 401, 415, 416, 420, 423 or 488 response, respectively (these response codes are referred to as repairable error responses),-] {+initial INVITE transaction, and+} the [-UAS-] {+initial INVITE contained an offer, the UPDATE+} can [-choose to generate-] {+contain an offer if the callee generated an answer in+} a [-155 (Update Requested)-] reliable provisional [-response. This response is formatted identically to the way-] {+response, and+} the [-401, 415, 416, 420, 423-] {+caller has received answers to any other offers it sent in either PRACK+} or [-488 would be formatted, with-] {+UPDATE, and has generated answers for any offers it received in an UPDATE from+} the [-exception of-] {+callee. o If+} the [-status line. When this-] {+UPDATE+} is [-received by-] {+being sent before completion of+} the [-UAC,-] {+initial INVITE transaction, and+} the [-UAC generates-] {+initial INVITE did not contain+} an [-UPDATE request to "correct" whatever problem was reported by-] {+offer,+} the [-155 response. Such a request might include credentials, omit bodies not acceptable to-] {+UPDATE can contain an offer if+} the [-UAS, or not mandate-] {+callee generated+} an [-extension not supported by-] {+offer in a reliable provisional response, and+} the [-UAS. When-] {+UAC generated an answer in+} the [-UAS receives this request,-] {+corresponding PRACK. Of course,+} it [-processes-] {+can't send an UPDATE if+} it [-much like-] {+has not received answers to any other offers+} it [-would a re- INVITE, except that the-] {+sent in either PRACK or UPDATE, or has not generated answers for any other offers it received in an+} UPDATE [-request is answered immediately if acceptable, and-] {+from+} the [-response to-] {+callee. o If+} the [-original INVITE-] {+UPDATE+} is [-not-] {+being+} sent [-until-] {+after+} the [-call is explicitly answered or rejected. The usage-] {+completion+} of the [-155, instead of rejecting-] {+initial INVITE transaction, it cannot be sent if+} the [-request, is not needed unless there is a proxy upstream performing a forking application. Therefore,-] {+caller has generated or received offers+} in [-order to know whether to send-] a [-155-] {+re-INVITE+} or [-a final response,-] {+UPDATE which have not been answered. and for+} the [-proxy can insert a Require header field into-] {+callee: o If+} the [-request with a value of update,-] {+UPDATE is being sent+} before [-proxying it. This informs-] the [-UAS that it should send a 155 instead-] {+completion+} of [-a repairable error response. 5 UA Behavior 5.1 Initiating a Dialog A UAC compliant to this specification SHOULD include a Supported header field in all requests it sends that can initiate a dialog (including-] {+the+} INVITE {+transaction,+} and [-SUBSCRIBE [5]), with the option tag "update". This indicates the ability to process-] the [-155 response properly. The UA SHOULD also include-] {+initial INVITE contained+} an [-Allow header field in-] {+offer,+} the [-request, including-] {+UPDATE cannot be sent unless+} the [-method UPDATE, to indicate its ability to receive-] {+callee has generated+} an [-UPDATE request. The UAC MAY include a Require header-] {+answer+} in [-the request, with the option tag "update", if it insists that the UAS generate a 155 response code instead of an error response for all repairable error responses. 5.2 Generating a Provisional Response When a UAS compliant to this specification receives a request that can initiate a dialog, the procedures in this section are followed. The request is processed according to the rules in Section 8.2 of RFC BBBB. If the request contains a Supported header field with the option tag of "update", and the guidelines in Section 8.2 of RFC BBBB J. Rosenberg [Page 5] Internet Draft update March 1, 2002 would result in the generation of a repairable error response, the processing in Section 5.2.1 is performed instead of sending the error response. If, on the other hand, the processing of Section 8.2 of RFC BBBB indicates that the request is generally acceptable, the procedures of Section 5.2.2 are followed. 5.2.1 Requesting an Update Instead of generating the repairable error response, a UAS MAY generate a 155 (Update Requested) response. If the request contains a Require header with the value of "update", the UAS MUST generate the 155 (Update Requested) instead of the repairable error response. The 155 is generated exactly as the corresponding repairable error response would be generated. The only difference is that the status line has the response code of 155. The UAC will be able to infer the particular reason for rejection from the headers in the response. The 155 response MUST contain the Require header, with the value of "update". The 155 response MUST be sent reliably, using the reliability of provisional responses extension to SIP [3]. Once the response is sent, the UAS starts a timer. The timer SHOULD be equal to at least T1*64 seconds (T1 is defined in Section 17.1.1.1 of RFC BBBB [2]. This timer indicates how long the UAS is willing to wait for the update before terminating the transaction. During this time, the UAS MUST NOT perform application layer processing of the request (alert the user, send media, etc.). Processing of the request is effectively suspended. However, the UAS MUST still process a CANCEL request for that transaction, should one arrive. If the timer fires before receipt of an UPDATE request on the dialog, the UAS MUST generate the repairable error response. If an UPDATE is received before the timer fires, processing continues in Section 6.2. 5.2.2 Continuing With the Dialog If the request was acceptable, the UAS MAY generate a provisional response. That response SHOULD contain an Allow header field that includes the UPDATE method. This informs the caller that the callee is capable of receiving an UPDATE request at any time. 5.3 Processing Provisional Responses If the UAC receives a provisional response with a tag in the To J. Rosenberg [Page 6] Internet Draft update March 1, 2002 field, and that response contains a Supported header with the value of "update", or the response is a 155, the UAC MUST create an early dialog. Creation of early dialogs is a MAY in RFC BBBB. This extension increases the strength to MUST. This is necessary to receive incoming UPDATE requests from the callee. If the response is a 155, the UAC follows the processing of Section 5.3.1. Otherwise, the response is processed normally. The requestor can generate an UPDATE request within the dialog, as described in Section 6.1. 5.3.1 Processing the 155 The 155 provisional response indicates to the UAC that the request it generated was not acceptable, and that a modification of the request in some way may make the request acceptable. That modification is performed with an UPDATE request, sent as a mid-dialog request. Additional processing beyond that specified in Section 12.2.1 of RFC BBBB [2] is applied as described below. If the 155 response contains a WWW-Authenticate header, the UAC SHOULD include an Authorization header in the UPDATE with a response to the challenge. The Authorization header is constructed as described in Section 22 of RFC BBBB. If the 155 response contains an Accept header field, the UAC MAY include a body in the UPDATE. That body MUST be with one of the types listed in the Accept header field of the 155. Similarly, if the 155 contains an Accept-Encoding header field, the UAC MAY apply an encoding to any bodies in the request, but MUST only apply encodings listed in the Accept-Encoding header field of the 155. Finally, if the 155 contains an Accept-Language header field, the UAC MAY place a body into the request, but it MUST be in a language listed in the Accept-Language header field of the 155. If the 155 response contains a Unsupported header, the UAC MUST NOT include a Require header in the UPDATE listing any option tags present in the Unsupported header from the 155. If the 155 response contains a description of media capabilities in the body (for example, an SDP formatted according to Section 9 of RFC OOOO [4]), the UAC MUST include a new offer in the UPDATE. This will be the case when the repairable error response was 488. If the 155 response contains a Min-Expires header, the UAC MUST NOT J. Rosenberg [Page 7] Internet Draft update March 1, 2002 include a Expires header or parameter in the UPDATE with a value less than the value in the Min-Expires header. It is possible that the request was not acceptable, but repairable, for some reason which cannot be ascertained from headers in the 155. A proxy MAY use other means to make such a determination. For example, if a future extension defined a header which conveyed a reason code in the 155, that could be used. The UAC MAY add any other optional headers for the UPDATE request, as defined in Tables 1 and 2. The offer/answer rules in RFC BBBB apply to the UPDATE request. Specifically, the UPDATE can only contain an offer if there are no outstanding offers. Since the 155 effectively rejects the offer, the UPDATE can contain a new offer. The UPDATE request is then sent according to the procedures of Section 12.2.1 of RFC BBBB. 6 UPDATE Handling 6.1 Sending an UPDATE The UPDATE request is constructed as would any other request within an existing dialog, as described in Section 12.2.1 of RFC BBBB. It MAY be sent for both early and confirmed dialogs. 6.1.1 Specifics for INVITE In the case of INVITE, the UPDATE request can contain an offer, and the response to the UPDATE would contain the answer. Of course, the rules for inclusion of offers and answers in SIP messages as defined in Section 13.2.1 of RFC BBBB still apply. Typically, this means that, for the caller: o If the UPDATE is being sent before completion of the initial INVITE transaction, and the initial INVITE contained an offer, the UPDATE can contain an offer if: - The callee rejected the offer by sending a 155 with a description of capabilities in the body, OR - The callee generated an answer in a reliable provisional response, and the UAC has received answers to any other offers it sent in either PRACK or UPDATE, and has generated answers for any offers it received in an UPDATE from the callee. J. Rosenberg [Page 8] Internet Draft update March 1, 2002 o If the UPDATE is being sent before completion of the initial INVITE transaction, and the initial INVITE did not contain an offer, the UPDATE can contain an offer if the callee generated an offer in a reliable provisional response, and the UAC generated an answer in the corresponding PRACK. Of course, it can't send an UPDATE if it has not received answers to any other offers it sent in either PRACK or UPDATE, or has not generated answers for any other offers it received in an UPDATE from the callee. o If the UPDATE is being sent after the completion of the initial INVITE transaction, it cannot be sent if the caller-] {+a reliable provisional response,+} has [-generated or-] received [-offers in-] a [-re-INVITE or UPDATE which have not been answered. and-] {+PRACK+} for [-the callee: o If the UPDATE is being sent before the completion of the INVITE transaction, and the initial INVITE contained an offer, the UPDATE cannot be sent unless the callee has generated an answer in a-] {+that+} reliable provisional response, [-and-] has not [-sent or received other UPDATE requests containing offers that have not been answered. o If the UPDATE is being sent before completion of the INVITE transaction, and the initial INVITE did not contain an offer, the UPDATE can contain an offer unless the callee has sent or-] received [-other UPDATE-] {+any+} requests [-containing offers that have not been answered. o If the UPDATE is being sent after the completion of the initial INVITE transaction, it cannot be sent if the callee has generated or received offers in a re-INVITE-] {+(PRACK+} or [-UPDATE which have not been answered. If the response to the UPDATE is a 491, the UAC SHOULD follow the processing in Section 4.1 of RFC BBBB for 491 processing, except that the UPDATE is retried on expiration of the timer, rather than a re- INVITE. 6.1.2 Specifics for SUBSCRIBE An UPDATE request MUST NOT be sent for SUBSCRIBE unless a SUBSCRIBE request has generated a 155 response. 6.2 Receiving an UPDATE If an UPDATE is received which does not match an existing dialog, it J. Rosenberg [Page 9] Internet Draft update March 1, 2002 MUST be rejected-] {+UPDATE)+} with [-a 481 response. When a UAS receives an UPDATE request, it is being asked to update aspects of the session or other application state, but not the dialog state itself (which will either be early or confirmed). The-] {+offers that it has not answered, and has not sent any+} UPDATE [-request is a target refresh request.-] {+requests containing offers that have not been answered. o+} If the UPDATE [-matches an existing dialog, it-] is [-processed as would any mid-dialog request, as per Section 12.2.2-] {+being sent before completion+} of [-RFC BBBB. Furthermore, its processing then follows the method-specific behavior as if the UPDATE had the same method as-] the [-request which created the dialog. However, the response to UPDATE does not result in a change to-] {+INVITE transaction, and+} the [-dialog state (i.e., it does-] {+initial INVITE did+} not [-change it from early to confirmed). Furthermore, in many cases, the session or other application state is also confirmed when-] {+contain an offer,+} the [-dialog is established. The response to-] UPDATE [-does not cause such confirmation either. In-] {+cannot be sent unless+} the [-case of INVITE, for example, a 2xx response to-] {+callee has sent+} an [-initial INVITE confirms the setup of the call, but-] {+offer in+} a [-2xx response to UPDATE does not. As such, an UPDATE MUST generate an immediate final response. If the UPDATE is-] {+reliable provisional response,+} received [-after processing of the original request was suspended because-] {+an answer in+} a [-155 was generated, processing continues as if the repairable error response had actually been sent, and, as above, the-] {+PRACK, and has not received any+} UPDATE [-was the same method as-] {+requests with offers+} that [-request. However, as described above, the final response to UPDATE does not change the state of the dialog, nor does-] it [-confirm any application state,-] {+has not answered,+} and [-therefore, SHOULD generate a 2xx response immediately once it passes the processing steps in Section 12.2.2 of RFC BBBB. Once the application determines what the response to request would have been, for example, an acceptance of the call, the original request is responded to with-] {+has not sent any UPDATE requests containing offers+} that [-response code. 6.2.1 Specifics for INVITE-] {+have not been answered. o+} If the UPDATE is [-received by-] {+being sent after+} the [-UAS, and-] {+completion of the initial INVITE transaction,+} it [-had previously-] {+cannot be+} sent [-a 155,-] {+if+} the {+callee has generated or received offers in a re-INVITE or UPDATE J. Rosenberg [Page 5] Internet Draft update April 30, 2002 which have not been answered. 5.2 Receiving an UPDATE The+} UPDATE is processed [-like a re-INVITE. Assuming-] {+as any other mid-dialog request, as described in Section 12.2.2 of RFC BBBB [1]. If+} the [-steps-] {+request is generally acceptable, processing continues as described below. This processing is nearly identical to that+} of Section 14.2 of RFC BBBB [-pass,-] {+[1], generalized for+} the {+case of UPDATE. A UAS that receives an+} UPDATE [-SHOULD be responded-] {+before it has generated a final response+} to [-with-] a [-2xx response, and then-] {+previous UPDATE or INVITE on+} the [-processing of-] {+same dialog MUST return a 500 response to+} the [-original request continues, as if-] {+new UPDATE, and MUST include a Retry- After field with a Retry-After header field with a randomly chosen value between 0 and 10 seconds. If an UPDATE is received that contains an offer, and+} the [-original request were-] {+UAS has generated an offer (in an UPDATE, PRACK or INVITE) to which it has not yet received an answer,+} the [-same as-] {+UAS MUST reject+} the UPDATE [-(excepting-] {+with a 491 response. If a UA receives an UPDATE for an existing dialog, it MUST check any version identifiers in+} the [-method,-] {+session description or, if there are no version identifiers, the content+} of [-course). This means that-] the [-callee is alerted, for example, or media can begin-] {+session description+} to [-be sent. The original request can be rejected, of course,-] {+see+} if [-a call screening application decides that-] {+it has changed. If+} the [-caller is on-] {+session description has changed,+} the [-block list. Of course, if-] {+UAS MUST adjust+} the [-UPDATE itself is not acceptable (for example, invalid credentials), it MAY be rejeced with-] {+session parameters accordingly and generate an answer in+} the [-appropriate error-] {+2xx+} response. [-A 155 response to-] {+However, unlike a re-INVITE,+} the UPDATE MUST [-NOT-] be [-sent. J. Rosenberg [Page 10] Internet Draft update March 1, 2002 If an UPDATE is received that contains an offer,-] {+responded to promptly,+} and {+therefore+} the [-UAS has generated an offer (presumably in an UPDATE of its own)-] {+user cannot generally be prompted+} to [-which it has not yet received an answer,-] {+approve the session changes. If+} the UAS [-MUST-] {+cannot change the session parameters without prompting the user, it SHOULD+} reject the [-UPDATE-] {+request+} with a [-491-] {+504+} response. [-6.2.2 Specifics for SUBSCRIBE-] If [-an UPDATE is received before-] the [-original SUBSCRIBE is responded to (which should only occur if a 155-] {+new session description+} is [-sent),-] {+not acceptable,+} the [-UPDATE is processed as if-] {+UAS can reject+} it [-were-] {+by returning+} a [-new SUBSCRIBE refresh. Specifically, the expiration, acceptable notification formats (from the Accept, Accept-Encoding and Accept-Language headers), and body information are used-] {+488 (Not Acceptable Here) response+} for the [-subscription. The UPDATE generates an immediate 2xx-] {+UPDATE. This+} response [-as long as those parameters are acceptable. Once-] {+SHOULD include a Warning header field. 5.3 Processing+} the [-status-] {+UPDATE Response Processing+} of the [-subscription itself is determined, the original SUBSCRIBE is responded to. For example, if-] {+UPDATE response at+} the [-status-] {+UAC+} is [-pending, a 202 would be sent-] {+nearly identical+} to the [-SUBSCRIBE. 7 Proxy Behavior-] {+rules in Section 14.1 of RFC BBBB [1], but generalized for UPDATE.+} If a [-proxy-] {+UA+} receives a [-request with-] {+non-2xx final response to+} a [-Supported header containing-] {+UPDATE,+} the [-option tag "update", and-] {+session parameters MUST remain unchanged, as if no UPDATE had been issued. Note that, as stated in Section 12.2.1 of RFC BBBB [1], if+} the [-proxy knows it-] {+non- 2xx final response+} is [-going to fork the request, either in parallel-] {+a 481 (Call/Transaction Does Not Exist),+} or [-in serial,-] {+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. J. Rosenberg [Page 6] Internet Draft update April 30, 2002 If a UAC receives a 491 response to a UPDATE,+} it SHOULD [-add-] {+start+} a [-Require header to all proxied requests-] {+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 [-option tag "update" if such-] {+value), T has+} a [-header-] {+randomly chosen value between 2.1 and 4 seconds in units of 10 ms. 2. If the UAC+} is not [-already present. For each request which generates a 420 response containing-] the [-Unsupported header with-] {+owner of the Call-ID of+} the {+dialog ID, T has a randomly chosen+} value of [-"update",-] {+between 0 and 2 seconds in units of 10 ms. When+} the [-proxy MUST generate another branch to-] {+timer fires,+} the [-same destination, this time, without-] {+UAC SHOULD attempt+} the [-Require header added in. This behavior helps ensure that forking applications work properly, but also provides-] {+UPDATE once more, if it still desires+} for [-backwards compatibility-] {+that session modification to take place. For example, if the call was already hung up+} with [-endpoints which do-] {+a BYE, the UPDATE would+} not [-support this extension. 8-] {+take place. 6 Proxy Behavior Proxy processing of the UPDATE request is identical to any other non-INVITE request. 7+} Definition of the UPDATE method The semantics of the UPDATE method are described in detail above. This extension adds another value to the Method BNF described in RFC BBBB: UPDATEm = %x55.50.44.41.54.45 ; UPDATE in caps Method = INVITEm / ACKm / OPTIONSm / BYEm / CANCELm / REGISTERm / UPDATEm / extension-method [-J. Rosenberg [Page 11] Internet Draft update March 1, 2002 The following-] {+Table 1+} extends Table 2 of RFC BBBB for the UPDATE [-method:-] {+method. Table 2 updates Table 3 of RFC BBBB for the UPDATE method. 8 Example Call Flow This section presents an example call flow using the UPDATE method. The flow is shown in Figure 1. The caller sends an initial INVITE (1) which contains an offer. The callee generates a 180 response (2) with an answer to that offer. With the completion of an offer/answer J. Rosenberg [Page 7] Internet Draft update April 30, 2002+} Header field where proxy UPDATE ____________________________________________ Accept R o Accept 2xx o Accept 415 [-o-] {+c+} Accept-Encoding R o Accept-Encoding 2xx o Accept-Encoding 415 [-o-] {+c+} Accept-Language R o Accept-Language 2xx o Accept-Language 415 [-o Alert-Info R am o-] {+c+} Alert-Info [-180 am o-] {+-+} Allow R o Allow 2xx o Allow r o Allow 405 [-o-] {+m Allow-Events (1) -+} Authentication-Info 2xx o Authorization R o Call-ID c r m Call-Info [-am-] {+ar+} o Contact R [-o-] {+m+} Contact 1xx o Contact 2xx [-o-] {+m+} Contact 3xx {+d+} o Contact 485 o Content-Disposition o Content-Encoding o Content-Language o Content-Length [-r-] {+ar+} t Content-Type * CSeq c r m Date a o Error-Info 300-699 {+a+} o {+Event (1) -+} Expires [-o-] {+-+} From c r m In-Reply-To [-R o-] {+-+} Max-Forwards R amr m Min-Expires [-423 o-] {+-+} MIME-Version o Organization [-am-] {+ar+} o Table 1: Summary of header fields, A--O {+; (1) defined in [5],+} J. Rosenberg [Page [-12]-] {+8]+} Internet Draft update [-March 1,-] {+April 30,+} 2002 [-The following extends Table 3 of RFC BBBB for UPDATE:-] Header field where proxy UPDATE ____________________________________________________ Priority [-R a o-] {+-+} Proxy-Authenticate 407 {+ar+} m {+Proxy-Authenticate 401 ar o+} Proxy-Authorization R [-r-] {+dr+} o Proxy-Require R [-acr-] {+ar+} o RAck R - Record-Route R [-amr-] {+ar+} o Record-Route [-2xx,401,484-] {+2xx,18x mr+} o Reply-To [-o-] {+-+} Require [-acr o-] {+ar c+} Retry-After 404,413,480,486 o 500,503 o 600,603 o Route R [-r-] {+adr+} c RSeq [-1xx o-] {+- -+} Server r o Subject [-R o-] {+- - Subscription-State (1) -+} Supported R o Supported 2xx o Timestamp o To [-c(1)-] {+c+} r m Unsupported 420 [-o-] {+m+} User-Agent o Via [-c acmr-] {+R amr m Via rc dr+} m Warning r o WWW-Authenticate 401 {+ar+} m {+WWW-Authenticate 407 ar o+} Table 2: Summary of header fields, [-P--Z; (1): copied with possible addition of tag 9 Definition of the 155 (Update Requested) Response The semantics of the 155 (Update Requested) response code are defined above. The default reason phrase is "Update Requested". 10 Example Call Flow This section presents an example call flow using the UPDATE method. The flow is shown in Figure 1. The caller sends an initial INVITE (1) which contains an offer. The callee generates a 180 response (2) with an answer to that offer. With the completion of an offer/answer-] {+P--Z+} exchange, the session is established, although the dialog is still in [-J. Rosenberg [Page 13] Internet Draft update March 1, 2002-] the early state. The caller generates a PRACK (3) to acknowledge the 180, and the PRACK is answered with a 200 OK (4). The caller decides to update some aspect of the session - to put it on hold, for example. So, they generate an UPDATE request (5) with a new offer. This offer is answered in the 200 response to the UPDATE (6). Shortly thereafter, the callee decides to update some aspect of the [-session, so it generates an UPDATE request (7) with an offer, and the answer is sent in the 200 response (8). Finally, the callee answers the call, resulting in a 200 OK response to the INVITE (9), and then an ACK (10). Neither the 200 OK to the INVITE, nor the ACK, will contain SDP. 11 Security Considerations This specification describes a condition under which a UAS would receive a request that is unauthenticated, and maintain state for processing that request, for a duration of 32 seconds. This introduces a potential denial-of-service attack. Implementations SHOULD restrict the number of transactions which are pending with a 155 to a small number. Subsequent unauthenticated requests SHOULD then be rejected with a 401, even if a Require header is present with the option tag "update". These guidelines imply that the usage of 155 for unauthenticated requests is useful primarily for single user devices, which typically have only a few transactions outstanding a time in general. 12 IANA Considerations This document serves as a registration of the update option tag, the UPDATE request method, and the 155 response code. 12.1 update Option Tag As per Section 27.1 of RFC BBBB [2], this specification serves as a registration for the SIP option tag "update". The information to be added to the registry is: Name of the Option Tag: The name of-] {+session, so it generates an UPDATE request (7) with an offer, and+} the [-option tag-] {+answer+} is [-"update". Descriptive Text: Support for-] {+sent in+} the [-update extension implies-] {+200 response (8). Finally,+} the [-ability to generate and receive-] {+callee answers the call, resulting in+} a [-155 (Update Requested) provisional-] {+200 OK+} response [-as an alternative-] to [-sending-] {+the INVITE (9), and then+} an [-equivalent repairable error response. 12.2 UPDATE Request Method As per Section 27.4 of RFC BBBB [2], this specification serves as a-] {+ACK (10). Neither the 200 OK to the INVITE, nor the ACK, will contain SDP.+} J. Rosenberg [Page [-14]-] {+9]+} Internet Draft update [-March 1,-] {+April 30,+} 2002 Caller Callee | | | | |(1) INVITE with offer 1 | |---------------------------->| | | | | |(2) 180 with answer 1 | |<----------------------------| | | | | |(3) PRACK | |---------------------------->| | | | | |(4) 200 PRACK | |<----------------------------| | | | | |(5) UPDATE with offer 2 | |---------------------------->| | | | | |(6) 200 UPDATE with answer 2 | |<----------------------------| | | | | |(7) UPDATE with offer 3 | |<----------------------------| | | | | |(8) 200 UPDATE with answer 3 | |---------------------------->| | | | | |(9) 200 INVITE | |<----------------------------| | | | | |(10) ACK | |---------------------------->| | | | | | | | | Figure 1: UPDATE Call Flow J. Rosenberg [Page [-15]-] {+10]+} Internet Draft update [-March 1,-] {+April 30,+} 2002 [-registration-] {+9 Security Considerations The security considerations+} for [-the SIP-] UPDATE [-request method. The information-] {+are identical+} to {+those for re-INVITE. It is important that the UPDATE+} be [-added to-] {+integrity protected and authenticated as coming from+} the [-registry is: RFC Number: This specification serves-] {+same source+} as the {+entity on the other end of the dialog.+} RFC {+BBBB [1] discusses security mechanisms+} for [-registering the UPDATE request method. Method Name: UPDATE Reason Phrase: Not applicable. 12.3 155 Response Code-] {+achieving these functions. 10 IANA Considerations+} As per Section 27.4 of RFC BBBB [-[2],-] {+[1],+} this specification serves as a registration for the SIP UPDATE request method. The information to be added to the registry is: RFC Number: This specification serves as the RFC for registering the [-155 response code. Response Code: 155 Default-] {+UPDATE request method. Method Name: UPDATE+} Reason Phrase: [-Update Requested 13-] {+Not applicable. 11+} Acknowledgements The author would like to thank {+Jo Hornsby, Markus Isomaki,+} Rohan [-Mahy-] {+Mahy,+} and [-Markus Isomaki-] {+Bob Penfield+} for their comments. [-14-] {+12+} Author's Addresses Jonathan Rosenberg dynamicsoft 72 Eagle Rock Avenue First Floor East Hanover, NJ 07936 email: jdrosen@dynamicsoft.com [-15-] {+13+} Normative References [1] {+J. Rosenberg, H. Schulzrinne, et al. , "SIP: Session initiation protocol," Internet Draft, Internet Engineering Task Force, Feb. 2002. Work in progress. [2]+} S. Bradner, "Key words for use in RFCs to indicate requirement levels," [-Request for Comments-] {+RFC+} 2119, Internet Engineering Task Force, Mar. 1997. [-[2]-] {+[3]+} J. [-Rosenberg,-] {+Rosenberg and+} H. Schulzrinne, [-et al. , "SIP: Session initiation protocol," Internet Draft, Internet Engineering Task Force, Feb.-] {+"An offer/answer model with+} J. Rosenberg [Page [-16]-] {+11]+} Internet Draft update [-March 1,-] {+April 30,+} 2002 [-2002. Work in progress. [3] J. Rosenberg and H. Schulzrinne, "Reliability of provisional responses in SIP,"-] {+SDP,"+} Internet Draft, Internet Engineering Task Force, Feb. 2002. Work in progress. [4] J. Rosenberg and H. Schulzrinne, [-"An offer/answer model with SDP,"-] {+"Reliability of provisional responses in SIP,"+} Internet Draft, Internet Engineering Task Force, Feb. 2002. Work in progress. [5] A. [-Roach et al. ,-] {+Roach,+} "SIP-specific event notification," Internet Draft, Internet Engineering Task Force, [-Feb.-] {+Mar.+} 2002. Work in progress. [-16-] {+14+} Informative References Full Copyright Statement Copyright (c) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any k