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.

                           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

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
   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 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 8.2

   Operation of RFC BBBB [2]. This processing
   may determine that the request is acceptable, and therefore the user
   is alerted (or some other appropriate action this extension is taken), or the
   processing may determine that the request cannot be processed further
   without some kind of change.

   In the former case, the UAS generates a reliable provisional response
   [3]. straigthforward. The provisional response establishes caller begins
   with an INVITE transaction, which proceeds normally. Once a dialog is
   established, either early dialog. It
   contains an Allow header listing the methods supported by the server.
   Among them will be the UPDATE method. At any time thereafter, or confirmed, the UAC caller can generate an
   UPDATE method that contains an SDP offer [4] [3] for the purposes of
   updating the session. The response to the UPDATE method contains the
   answer. Similarly, the callee once a dialog is established, the callee can send
   an UPDATE with an offer, and the caller places its answer in the 2xx. 2xx
   to the UPDATE. The Allow header is used to indicate support for the
   UPDATE method. There are additional constraints on when 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, requests service
   used, based on a URI with a scheme not supported by the
   server, mandates an extension not supported by restrictions of the UAS, requests a
   creation offer/answer model.

4 Determining Support for this Extension

   The initiation of soft state with a refresh interval that is too brief, or
   contains a session description that is not acceptable. Rather than
   rejecting the request with operates as specified in RFC BBBB [1].
   However, a 401, 415, 416, 420, 423 or 488 response,
   respectively (these response codes are referred UAC compliant to as repairable
   error responses), 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 can choose compliant to generate this specification receives an INVITE request
   for a new dialog, and generates a 155 (Update
   Requested) reliable provisional response. This response is formatted
   identically to the way
   containing SDP, that response SHOULD contain an Allow header field
   that lists the 401, 415, 416, 420, 423 or 488 would be
   formatted, with UPDATE method. This informs the exception of caller that the status line. When this callee
   is
   received by the UAC, the UAC generates capable of receiving an UPDATE request to "correct"
   whatever problem was reported by the 155 response. Such a request
   might include credentials, omit bodies not acceptable to the UAS, or
   not mandate at any time. An unreliable
   provisional response MAY contain an extension not supported by the UAS. When Allow header listing the UAS
   receives this request, it processes it much like it would UPDATE
   method, and a re-
   INVITE, except that 2xx response SHOULD contain an Allow header listing the
   UPDATE request is answered immediately if
   acceptable, method.

   Responses are processed normally as per RFC BBBB [1], and in the response case
   of reliable provisional responses, according 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 header field into the
   request with a value of update, 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 field in all requests it sends that can initiate a dialog
   (including INVITE and SUBSCRIBE [5]), with the option tag "update".
   This indicates the ability to process the 155 response properly. The
   UA SHOULD also include an Allow header field in the request,
   including the method UPDATE, to indicate its ability to receive an
   UPDATE request.

   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 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
   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
   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
   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, [4]. It is important
   to note that could be used.

   The UAC MAY add any other optional headers for a reliable provisional response will always create an
   early dialog at the UPDATE request, as
   defined in Tables 1 and 2.

   The offer/answer rules UAC. Creation of this dialog is necessary in RFC BBBB apply
   order to the receive UPDATE request.
   Specifically, creates from the UPDATE can only contain callee.

   If the response contains an offer if there are no
   outstanding offers. Since the 155 effectively rejects Allow header containing the offer, value
   "UPDATE", the
   UPDATE can contain a new offer.

   The UPDATE request UAC knows that the callee supports UPDATE, and the UAC
   is then sent according allowed to follow the procedures of Section 12.2.1 of RFC BBBB.

6 5.1.

5 UPDATE Handling

6.1

5.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 Although UPDATE request can contain
   be used on confirmed dialogs, it is RECOMMENDED that a re-INVITE be
   used instead. This is because an offer, and
   the response to the UPDATE would contain needs to be answered
   immediately, ruling out the answer. Of course, 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. Typically, this These rules exist
   to guarantee a consistent view of the session state. 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 if the body, OR

          - The callee generated an
          answer in a reliable provisional response, and the UAC caller 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 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
          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 response, and has received a
          PRACK for that reliable provisional response, has not sent or received other UPDATE
          any requests containing (PRACK or UPDATE) with 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 that it has not
          answered, and has not sent or
          received other any UPDATE requests containing
          offers that have not been answered.

        o If the UPDATE is being sent after the before completion of the
          initial INVITE
          transaction, it cannot be sent if and the callee
          has generated or received offers in a re-INVITE or UPDATE
          which have initial INVITE did 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 contain an offer,
          the timer, rather than a re-
   INVITE.

6.1.2 Specifics for SUBSCRIBE

   An UPDATE request MUST NOT cannot be sent for SUBSCRIBE unless a SUBSCRIBE
   request the callee has generated a 155 response.

6.2 Receiving an UPDATE

   If sent an UPDATE is offer
          in a reliable provisional response, received which does not match an existing dialog, it
   MUST be rejected with a 481 response.

   When answer in a UAS receives an UPDATE request, it is being asked to update
   aspects of the session or other application state, but
          PRACK, and has not the dialog
   state itself (which will either be early or confirmed). The UPDATE
   request is a target refresh request.

   If the UPDATE matches an existing dialog, it is processed as would received any mid-dialog request, as per Section 12.2.2 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 requests with offers
          that it 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 has 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 answered, and has not sent any UPDATE MUST generate an immediate final response. requests
          containing offers that have not been answered.

        o If the UPDATE is received being sent after processing the completion of the original request
   was suspended because a 155 was generated, processing continues as
          initial INVITE transaction, it cannot be sent if the repairable error response had actually callee
          has generated or received offers in a re-INVITE or UPDATE
          which have not been sent, and, as above,
   the answered.

5.2 Receiving an UPDATE was the same method

   The UPDATE is processed as that request. However, any other mid-dialog request, 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,
   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, BBBB [1]. If the original request is responded generally
   acceptable, processing continues as described below. This processing
   is nearly identical to with that response code.

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 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 the processing of the original request
   continues, as if the original request were the same as the previous 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 INVITE on the block list.

   Of course, if the UPDATE itself is not acceptable (for example,
   invalid credentials), it MAY be rejeced with the appropriate error
   response. A 155 same dialog MUST
   return a 500 response to the UPDATE new UPDATE, and MUST NOT be sent. 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 UAS has
   generated an offer (presumably in (in an UPDATE of its own) UPDATE, PRACK or INVITE) to which it has
   not yet received an answer, the UAS MUST reject the UPDATE with a 491
   response.

6.2.2 Specifics for SUBSCRIBE

   If a UA receives an UPDATE is received before for an existing dialog, it MUST check any
   version identifiers in the original SUBSCRIBE is responded session description or, if there are no
   version identifiers, the content of the session description to (which should only occur 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. However, unlike a 155 is sent), re-INVITE, the UPDATE is
   processed as if MUST be
   responded to promptly, and therefore the user cannot generally be
   prompted to approve the session changes. If the UAS cannot change the
   session parameters without prompting the user, it were SHOULD reject the
   request with a 504 response. If the new SUBSCRIBE refresh. Specifically, the
   expiration, acceptable notification formats (from session description is not
   acceptable, the Accept,
   Accept-Encoding and Accept-Language headers), and body information
   are used UAS can reject it by returning a 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, UPDATE response at the original SUBSCRIBE UAC is
   responded to. For example, nearly identical to
   the rules in Section 14.1 of RFC BBBB [1], but generalized for
   UPDATE.

   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 BBBB [1], if the status non-
   2xx final response is pending, a 202 would be
   sent to 481 (Call/Transaction Does Not Exist), or a
   408 (Request Timeout), or no response at all is received for the SUBSCRIBE.

7 Proxy Behavior
   UPDATE (that is, a timeout is returned by the UPDATE client
   transaction), the UAC will terminate the dialog.

   If a proxy UAC receives a request 491 response to a UPDATE, it SHOULD start a timer
   with a Supported header containing the
   option tag "update", and value T chosen as follows:

        1.   If the proxy knows it UAC is going to fork the
   request, either in parallel or in serial, owner of the Call-ID of the dialog ID
             (meaning it SHOULD add a Require
   header to all proxied requests with 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
   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
               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
   The following extends Table 3 of RFC BBBB for UPDATE: ; (1) defined in [5],
           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
   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 response to the registry is:

        Name of UPDATE (6). Shortly
   thereafter, the Option Tag: The name callee decides to update some aspect of the option tag session,
   so it generates an UPDATE request (7) with an offer, and the 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.

       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
   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] S. Bradner, "Key words for use in RFCs to indicate requirement
   levels," Request for Comments 2119, Internet Engineering Task Force,
   Mar. 1997.

   [2] 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," RFC 2119, Internet Engineering Task Force, Mar. 1997.

   [3] J. Rosenberg and H. Schulzrinne, "Reliability of provisional
   responses in SIP," "An offer/answer model with
   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
   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
   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.

   The IETF has been notified of intellectual property rights claimed in
   regard to some or all of the specification contained in this
   document. For more information consult the online list of claimed
   rights.