Internet Engineering Task Force SIP WG Internet Draft J.Rosenberg dynamicsoft draft-ietf-sip-update-00.txt February 16, 2002 Expires: August 2002 The SIP 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 provide SIP level information (such as credentials), but has no impact on the state of a dialog. This is very useful for updating information about a call before the call has been accepted. J.Rosenberg [Page 1] Internet Draft update February 16, 2002 1 Introduction The Session Initiation Protocol (SIP) [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, before the INVITE itself is answered. It is important to 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 cannot be used for this purpose, because the re-INVITE has an impact on the state of the call, 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 a proxy on the call path was attempting to provide 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 is that the caller never has an opportunity to update its request, so that it would then be acceptable to the rejecting party. Even if the rejection is passed upstream immediately, ther can be problems. The rejection of the INVITE will trigger the caller to try again, resulting in a re- invocation of the service at the proxy. That re-invocation will frequently result in undesirable side-effects. In both cases, a solution is needed that allows the caller to provide updated information to the recipients of the request, before a response to the initial request is generated. The UPDATE method, defined here, fulfills that need. It can be 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 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", J.Rosenberg [Page 2] Internet Draft update February 16, 2002 and "OPTIONAL" are to be interpreted as described in RFC 2119 [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, this includes the 401, 415, 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 an INVITE, it includes a Supported tag in the request that contains the option tag "update". This option tag indicates that the UAC understands the mechanisms defined in this specification. When the UAS gets that request, it performs the processing defined in Section XX of [1]. This processing may determine that the request is acceptable, and therefore the user is alerted (or some other appropriate action is taken), or the processing may determine that the request cannot be processed without some kind of change. OPEN ISSUE: do we need an option tag, or does Allow: UPDATE suffice? In the former case, the UAS generates a reliable provisional response [3] that also contains the Supported header with the option tag "update". This indicates to the UAC that the UAS supports this extension, The provisional response also establishes an early dialog. At any time thereafter, the UAC can generate an UPDATE method that contains an SDP offer [4] for the purposes of updating the session. The response to the UPDATE method contains the answer. Similarly, the callee can send an UPDATE with an offer, and the caller places its answer in the 2xx. The UPDATE method can also update other information provided in previous requests, such as a new Call-Info or Alert-Info header. In the latter case, the request might be unacceptable because it does not contain proper credentials, contains content not understood by the UAS, or mandates an extension not supported by the UAS. Rather than rejecting the request with a 401, 415, 420, 423 or 488 response, respectively (these response codes are referred to as repairable error responses), the UAS can choose to generate a 155 (Update Requested) reliable provisional response. This response is formatted J.Rosenberg [Page 3] Internet Draft update February 16, 2002 identically to the way the 401, 415, 420, 423 or 488 would be formatted, with the exception of the status line. When this is received by the UAC, the UAC generates an UPDATE request that believes might be acceptable to the UAS. Such a request might include credentials, omit bodies not acceptable to the UAS, or not mandate an extension not supported by the UAS. When the UAS receives this request, it processes it much like it would a re-INVITE, except that it is answered immediately if acceptable, and the response to the original INVITE is not sent until the call is explicitly answered or rejected. The usage of the 155, instead of rejecting the request, is not needed unless there is a proxy upstream performing a forking application. Therefore, in order to know whether to send a 155 or a final response, the proxy can insert a Require: update header into the request before proxying it. This informs the UAS that it should send a 155 instead of a repairable error response. 5 UA Behavior 5.1 Initiating a Dialog A UAC compliant to this specification SHOULD include a Supported header in all requests it sends that can initiate a dialog, including INVITE or SUBSCRIBE [5], with the option tag "update". This indicates the ability to process the 155 response properly, and to receive UPDATE requests on an early dialog. The UAC MAY include a Require header 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, the procedures in this section are followed. The request is processed according to the rules in Section XXX of RFC BBBB. If the request contains a Supported header with the option tag of "update", and the guidelines in Section XXX would result in the generation of a repairable error response, the processing in Section 5.3.1 is performed. If, on the other hand, the processing of Section XXX of RFC BBBB indicate that the request is generally acceptable, the procedures of Section 5.2.2 are followed. 5.2.1 Requesting an Update J.Rosenberg [Page 4] Internet Draft update February 16, 2002 Instead of generating the repairable error response, a UAS MAY generate a 155 (Update Requested) response code. 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. Alternatively, a Reason header [6] MAY be included in the response, indicating the specific error condition. OPEN ISSUE: This introduces a normative dependency on the Reason header draft. I would rather soften the language, so that there is no specific dependency on that draft. I think the UAC can always use headers to determine what to do, so that the response code is really not needed. The 155 response MUST contain the Require header, with the value of "update". OPEN ISSUE: Require is not strictly needed in the response. 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. 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. 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. If that response contains a session description, that response SHOULD contain a Supported header with the value of "update" to indicate that this extension is understood. 5.3 Processing Provisional Responses J.Rosenberg [Page 5] Internet Draft update February 16, 2002 If the UAC receives a provisional response with tags, 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. 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. Additional processing is applied as described below. If the 155 response contains a WWW-Authenticate header, the UAC SHOULD include a Authorization header in the UPDATE with a response to the challenge. The Authorization header is constructed as described in Section XXX of RFC BBBB. If the 155 response contains a Accept header, the UAC MAY include a body in the UPDATE. That body MUST be with one of the types listed in the Accept header of the 155. Similarly, if the 155 contains a Accept-Encoding header, the UAC MAY apply an encoding to any bodies in the request, but MUST only apply encodings listed in the Accept- Encoding header 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 XXX of RFC OOOO [4]), the UAC MUST include a new offer in the UPDATE. If the 155 response contains a Min-Expires header, the UAC MUST NOT include a Expires header or parameter in the UPDATE with a value less than the value in the Min-Expires header. The UAC MAY add any other optional headers for the UPDATE request, as defined in Table XXX. 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. J.Rosenberg [Page 6] Internet Draft update February 16, 2002 The UPDATE request is then sent according to the procedures of Section XXX 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 XXX 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 XXX 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 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. 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 generated answers for any others 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 has generated or received offers in a re-INVITE or UPDATE which have not been answered. and 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 reliable provisional responses, and has not sent J.Rosenberg [Page 7] Internet Draft update February 16, 2002 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 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 or UPDATE which have not been answered. 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 MUST be rejected with a 487 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 be one of early, confirmed, or non- existent). The UPDATE request is a target refresh request. If the UPDATE matches an existing dialog, it is processed as would any mid-dialog request, as per Section XXX 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 the dialog state (i.e., it does not change if from early to confirmed). Furthermore, in many cases, the session or other application state is also confirmed when the dialog is established. The response to UPDATE does not cause such confirmation either. In the case of INVITE, for example, a 2xx response to an initial INVITE confirms the setup of the call, but a 2xx response to UPDATE does not. As such, an UPDATE MUST generate an immediate final response. If the UPDATE is received after processing of the original request was suspended because a 155 was generated, processing continues as if the repairable error response had actually been sent, and, as above, the UPDATE was the same method as 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, and therefore, J.Rosenberg [Page 8] Internet Draft update February 16, 2002 SHOULD generate a 2xx response immediately once it passes the processing steps in Section XXX of RFC BBBB [processing mid-dialog requests]. Once the application determines what the response to request would have been, for example, acceptance of the call, the original request is responded to with that response code. OPEN ISSUE: The words above don't seem concise enough to properly determine how to respond to UPDATE and the original request. The difficulty is in the attempt to make it method agnostic, and because we lack a concise split of state between SIP itself, and the applications that make use of it. 6.2.1 Specifics for INVITE If the UPDATE is received by the UAS, and it had previously sent a 155, the UPDATE is processed like a re-INVITE. Assuming the steps of Section XXX of RFC BBBB pass, the UPDATE should be responded to with a 2xx response, and then the processing of the original request continues, as if the original request were the same as the UPDATE (excepting the method, of course). This means that the callee is alerted, for example, or media can begin to be sent. The original request can be rejected, of course, if a call screening application decides that the caller is on the block list. 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 is sent), the UPDATE is processed as if it were a new SUBSCRIBE refresh. Specifically, the expiration, acceptable notification formats (from the Accept, Accept-Encoding and Accept-Language headers), and body information are used for the subscription. The UPDATE generates an immediate 2xx response as long as those parameters are acceptable. Once the status of the subscription itself is determined, the original SUBSCRIBE is responded to. For example, if the status is pending, a 202 would be sent to the SUBSCRIBE. 7 Proxy Behavior If a proxy receives a request with a Supported header containing the option tag "update", and the proxy knows it is going to fork the request, either in parallel or in serial, it SHOULD add a Require header to all proxied requests with the option tag "update" if such a header is not already present. For each request which generates a 420 response containing the J.Rosenberg [Page 9] Internet Draft update February 16, 2002 Unsupported header with the value of "update", the proxy MUST generate another branch to the same destination, this time, without the Require header added in. This behavior helps ensure that forking applications work properly, but also provides for backwards compatibility with endpoints which do not support this extension. 8 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 The following extends Table 2 of RFC BBBB for the UPDATE method: The following extends Table 3 of RFC BBBB for UPDATE: 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 Flows TODO 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". J.Rosenberg [Page 10] Internet Draft update February 16, 2002 Header field where proxy UPDATE ____________________________________________ Accept R o Accept 2xx o Accept 415 o Accept-Encoding R o Accept-Encoding 2xx o Accept-Encoding 415 o Accept-Language R o Accept-Language 2xx o Accept-Language 415 o Alert-Info R am o Alert-Info 180 am o Allow R o Allow 2xx o Allow r o Allow 405 o Authentication-Info 2xx o Authorization R o Call-ID c r m Call-Info am o Contact R o Contact 1xx o Contact 2xx o Contact 3xx o Contact 485 o Content-Disposition o Content-Encoding o Content-Language o Content-Length r t Content-Type * CSeq c r m Date a o Error-Info 300-699 o 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 o Table 1: Summary of header fields, A--O J.Rosenberg [Page 11] Internet Draft update February 16, 2002 Header field where proxy UPDATE ____________________________________________________ Priority R a o Proxy-Authenticate 407 m Proxy-Authorization R r o Proxy-Require R acr o RAck R - Record-Route R amr o Record-Route 2xx,401,484 o Reply-To o Require acr o Retry-After 404,413,480,486 o 500,503 o 600,603 o Route R r c RSeq 1xx o Server r o Subject R o Supported R o Supported 2xx o Timestamp o To c(1) r m Unsupported 420 o User-Agent o Via c acmr m Warning r o WWW-Authenticate 401 m Table 2: Summary of header fields, P--Z; (1): copied with possible addition of tag 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 There are no IANA considerations associated with this specification. 13 Author's Addresses Jonathan Rosenberg dynamicsoft 72 Eagle Rock Avenue First Floor East Hanover, NJ 07936 J.Rosenberg [Page 12] Internet Draft update February 16, 2002 email: jdrosen@dynamicsoft.com 14 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 2119, Internet Engineering Task Force, Mar. 1997. [3] J. Rosenberg and H. Schulzrinne, "Reliability of provisional responses in SIP," Internet Draft, Internet Engineering Task Force, Feb. 2002. Work in progress. [4] J. Rosenberg and H. Schulzrinne, "An offer/answer model with SDP," Internet Draft, Internet Engineering Task Force, Jan. 2002. Work in progress. [5] A. Roach, "SIP-specific event notification," Internet Draft, Internet Engineering Task Force, Nov. 2001. Work in progress. [6] H. Schulzrinne, G. Camarillo, and D. Oran, "The reason header field for the session initiation protocol," Internet Draft, Internet Engineering Task Force, Dec. 2001. Work in progress. 15 Non-Normative References [7] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP: session initiation protocol," Request for Comments 2543, Internet Engineering Task Force, Mar. 1999. 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 kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other J.Rosenberg [Page 13] Internet Draft update February 16, 2002 Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. J.Rosenberg [Page 14] Table of Contents 1 Introduction ........................................ 2 2 Terminology ......................................... 2 3 Definitions ......................................... 3 4 Overview of Operation ............................... 3 5 UA Behavior ......................................... 4 5.1 Initiating a Dialog ................................. 4 5.2 Generating a Provisional Response ................... 4 5.2.1 Requesting an Update ................................ 4 5.2.2 Continuing With the Dialog .......................... 5 5.3 Processing Provisional Responses .................... 5 5.3.1 Processing the 155 .................................. 6 6 UPDATE Handling ..................................... 7 6.1 Sending an UPDATE ................................... 7 6.1.1 Specifics for INVITE ................................ 7 6.1.2 Specifics for SUBSCRIBE ............................. 8 6.2 Receiving an UPDATE ................................. 8 6.2.1 Specifics for INVITE ................................ 9 6.2.2 Specifics for SUBSCRIBE ............................. 9 7 Proxy Behavior ...................................... 9 8 Definition of the UPDATE method ..................... 10 9 Definition of the 155 (Update Requested) Response ................................................................ 10 10 Example Call Flows .................................. 10 11 Security Considerations ............................. 10 12 IANA Considerations ................................. 12 13 Author's Addresses .................................. 12 14 Normative References ................................ 13 15 Non-Normative References ............................ 13 EOTOC J.Rosenberg [Page 1]