Internet Engineering Task Force                                   SIP Working Group                               W. Marshall WG
Internet Draft                                  AT&T
Document: <draft-ietf-sip-manyfolks-resource-03>
                                                K. Ramakrishnan
                                                TeraOptic Networks

                                                E. Miller
                                                Terayon                                     G. Russell
                                                CableLabs

                                                B. Beser
                                                Pacific Broadband

                                                M. Mannette
                                                K. Steinbrenner
                                                3Com

                                                D. Oran
                                                F. Andreasen
                                                M. Ramalho
                                                Cisco

                                                J. Pickens
                                                Com21

                                                P. Lalwaney
                                                Nokia

                                                J. Fellows
                                                Copper Mountain Networks

                                                D. Evans
                                                D. R. Evans Consulting

                                                K. Kelly
                                                NetSpeak

                                                A. Roach Camarillo (Editor)
                                                                Ericsson

                                                J.
                                                    W. Marshall (Editor)
                                                                    AT&T
                                                      Jonathan Rosenberg
                                                D. Willis
                                                S. Donovan
                                                             dynamicsoft

                                                H. Schulzrinne
                                                Columbia University

                                                November, 2001
draft-ietf-sip-manyfolks-resource-04.txt
February 25, 2002
Expires: August, 2002

               Integration of Resource Management and SIP

       SIP Working Group       Expiration 5/31/02                      1
                SIP Extensions for Resource Management   November 2001

Status of this Memo

STATUS OF THIS MEMO

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026[1]. 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 Internet-Drafts as reference
   material or to cite them other than as "work in
   progress." progress".

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The

   To view the list of Internet-Draft Shadow Directories can be accessed at Directories, see
   http://www.ietf.org/shadow.html.

   The distribution of this memo is unlimited.  It is filed as <draft-
   ietf-sip-manyfolks-resource-03.txt>, and expires May 31, 2002.
   Please send comments to the authors.

1.

Abstract

   This document discusses how network QoS and security establishment quality of service can be made a
   precondition to establishment of sessions initiated by the Session
   Initiation Protocol (SIP), and described by SDP. (SIP). These preconditions require that the
   participant reserve network resources (or establish
   a secure media channel) before continuing with the
   session. We do not define new QoS quality of service reservation or security
   mechanisms; these pre-
   conditions preconditions simply require a participant to use
   existing resource reservation and security mechanisms before beginning the
   session.

   This results in a multi-phase call-setup mechanism, with

1 Introduction

   Some architectures require that at session establishment time, once
   the
   resource management protocol interleaved between two phases callee has been alerted, the chances of call
   signaling. The objective a session establishment
   failure are minimum. One source of such failure is the inability to
   reserve network resources for a mechanism session. In order to minimize "ghost
   rings", it is necessary to enable deployment
   of robust IP Telephony services, by ensuring that reserve network resources are made
   available for the session
   before the phone rings callee is alerted. However, the reservation of network
   resources frequently requires learning the IP address, port, and
   session parameters from the participants callee. This information is obtained as a
   result of the call
   are "invited" to participate. initial offer/answer exchange carried in SIP. This document also proposes an extension to
   exchange normally causes the Session Initiation
   Protocol (SIP) "phone to add ring", thus introducing a new COMET method, which
   chicken-and-egg problem: resources cannot be reserved without
   performing an initial offer/answer exchange, and the initial
   offer/answer exchange can't be done without performing resource
   reservation.

   The solution is used to confirm introduce the completion concept of all pre-conditions by a precondition. A
   precondition is a set of constraints about the session originator.

2. Conventions used which are
   introduced in this document

       SIP Working Group       Expiration 5/31/02                      2
                SIP Extensions for Resource Management   November 2001 the offer. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in
   this document are to be interpreted as described in RFC-2119[4].

3. Table of Contents

   Status of this Memo................................................2
   1. Abstract........................................................2
   2. Conventions used in this document...............................2
   3. Table of Contents...............................................3
   4. Introduction....................................................3
   4.1 Requirements...................................................6
   4.2 Overview.......................................................6
   5. SDP Extension...................................................8
   5.1 SDP Example....................................................9
   5.2 SDP Allowable Combinations.....................................9
   6. SIP Extension: The COMET Method................................11
   6.1 Header Field Support for COMET Method.........................11
   6.2 Responses to the COMET Request Method.........................12
   6.3 Message Body Inclusion........................................13
   6.4 Behavior of SIP User Agents...................................13
   6.5 Behavior of SIP Proxy and Redirect Servers....................13
   6.5.1 Proxy Server................................................13
   6.5.2 Forking Proxy Server........................................14
   6.5.3 Redirection Server..........................................14
   7. SIP Extension: The 183-Session-Progress Response...............14
   7.1 Status Code and Reason Phrase.................................14
   7.2 Status Code Definition........................................14
   8. SIP Extension: The 580-Precondition-Failure Response...........14
   8.1 Status Code and Reason Phrase.................................14
   8.2 Status Code Definition........................................14
   9. SIP Extension: Content-Disposition header......................15
   10. Option tag for Requires and Supported headers.................16
   11. SIP Usage Rules...............................................16
   11.1 Overview.....................................................16
   11.2 Behavior of Originator (UAC).................................17
   11.3 Behavior of Destination (UAS)................................18
   12. Examples......................................................20
   12.1 Single Media Call Flow.......................................20
   12.2 Multiple Media Call Flow.....................................22
   13. Special considerations with Forking Proxies...................23
   14. Advantages recipient of the Proposed Approach...........................24
   15. Security Considerations.......................................24
   16. Notice Regarding Intellectual Property Rights.................24
   17. References....................................................24
   18. Acknowledgments...............................................25
   19. Author's Addresses............................................25
   Full Copyright Statement..........................................28

4. Introduction

       SIP Working Group       Expiration 5/31/02                      3
                SIP Extensions for Resource Management   November 2001

   For an Internet Telephony service to be successfully used by a large
   number of subscribers, it must offer few surprises to those
   accustomed to the behavior of existing telephony services.  One
   expectation is that of connection quality, implying resources must
   be set aside for each call.

   A key contribution is a recognition of the need for coordination
   between call signaling, which controls access to telephony specific
   services, and resource management, which controls access to network-
   layer resources. This coordination is designed to meet generates an
   answer, but does not alert the user
   expectations and human factors associated with telephony.

   While customers may expect, during times of heavy load, to receive a
   "fast busy" or an announcement saying "all circuits are busy now,"
   the general expectation is that once the destination phone rings
   that otherwise proceed with session
   establishment. That only occurs when the connection preconditions are met. This
   can be made.  Blocking known through a call after ringing the
   destination is considered local event (such as a "call defect" and is confirmation of a very undesirable
   exception condition.

   This draft addresses both "QoS-Assured" and "QoS-Enabled" sessions.
   A "QoS-Assured" session will complete only if all
   resource reservation), or through a new offer sent by the required
   resources are available caller.

   This document deals with sessions that use SIP [1] as signalling
   protocol and assigned SDP [2] to describe the parameters of the session.  A provider may
   choose

   We have chosen to block a call when adequate resources for the call are not
   available. Public policy demands that include the phone system provide
   adequate quality at least in certain cases: e.g., for emergency
   communications during times of disasters.  Call blocking enables a
   provider to meet such requirements.

   A "QoS-Enabled" session allows service preconditions in the endpoints to complete
   SDP description rather than in the session
   establishment either with or without the desired resources.  Such
   session will use dedicated resources if available, SIP header because preconditions
   are stream specific.

2 Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and use a best-
   effort connection as an alternative if resources can not "OPTIONAL" in this
   document are to be
   dedicated. interpreted as described in RFC 2119 [3].

3 Overview

   In cases where resources are not available, the
   originating and/or terminating User Agent might consult with the
   customer order to obtain guidance on whether the ensure that session should complete.

   Coordination establishment does not take place
   until certain preconditions are met we distinguish between call signaling and resource management is also
   needed to prevent fraud two
   different state variables that affect a particular media stream:
   current status and theft desired status. This document defines quality of service.
   service status.

   The coordination
   between call-signaling and QoS setup protocols ensures that users
   are authenticated and authorized before receiving access to desired status consists of a threshold for the
   enhanced QoS associated with current status.
   Session establishment stops until the telephony service.

   This coordination, referred to in current status reaches or
   surpasses this draft as "preconditions,"
   require that the participant reserve network resources (or establish
   a secure media channel) before continuing with threshold. Once this threshold is reached or
   surpassed, session establishment resumes.

   For example, the session. We do following values for current and desired status
   would not define new QoS reservation or security mechanisms; these pre-
   conditions simply require a participant allow session establishment to use existing resource
   reservation and security mechanisms before beginning resume:

     current status = resources reserved in the session.

   In send direction
     desired status = resources reserved in both (sendrecv) directions

   On the case other hand, the values of SIP [2], this effectively means that the "phone won't
   ring" until example below would make session
   establishment resume:

     current status = resources reserved in both (sendrecv) directions
     desired status = resources reserved in the preconditions are met. send direction

   These preconditions are
   described by new SDP parameters, defined in this document. The
   parameters can mandate end-to-end QoS reservations based on RSVP [5]
   or any other end-to-end reservation mechanism (such two state variables define a certain piece of state of a media
   stream the same way as YESSIR [6],

       SIP Working Group       Expiration 5/31/02                      4
                SIP Extensions for Resource Management   November 2001 the direction attribute or PacketCable's Dynamic Quality of Service (D-QoS) [7]), and
   security based on IPSEC [8]. The preconditions can be defined
   independently for each media stream.

   The QoS architecture the codecs in use,
   define other pieces of state. Consequently, we treat these two new
   variables in the Internet separates QoS signaling from
   application level signaling. Application layer devices (such same way as web
   proxies and SIP servers) other SDP media attributes are not well suited for participation treated
   in
   network admission control or QoS management, as this is
   fundamentally a network layer issue, independent of any particular
   application. In addition, since application devices like the offer/answer model used by SIP servers [4]: they are almost never on the "bearer path" (i.e., the network path the
   RTP [9] takes), and since the RTP path exchanged between
   two user agents using an offer and signaling paths can be
   completely different (even traversing different autonomous systems),
   these application servers are generally not capable an answer in order to have a
   shared view of managing QoS
   for the media. Keeping QoS out of application signaling also means
   that there can be a single infrastructure for QoS across all
   applications. This eliminates duplication status of functionality, reducing
   management and equipment costs. It also means that new applications,
   with their own unique QoS requirements, can be easily supported.

   This loose coupling works very well for the session.

   Figure 1 shows a wide range typical message exchange between two SIP user agents
   using preconditions. A includes quality of
   applications. For example, service preconditions in an interactive game, one can establish
   the game using an application signaling protocol, and then later on
   use RSVP to reserve network resources. The separation is also
   effective for applications which have no explicit signaling.
   However, certain applications may require tighter coupling. In
   the
   case SDP of Internet telephony, the following is an important
   requirement:

       When initial INVITE. A calls B, B's phone should does not ring unless resources
       have been reserved from A to B, and want B to A.

   This could be achieved without coupling if A knew B's address, port,
   and codecs before the telephony signaling took place. However, since
   telephony signaling alerted until
   there is used largely network resources reserved in both directions (sendrecv)
   end-to-end. B agrees to obtain reserve network resources for this information in session
   before alerting the first place, callee. B will handle resource reservation in the coupling cannot be avoided.
   B->A direction, but wants A similar model exists for security. Rather than inventing new
   security mechanisms for each new application, common security tools
   (such as IPSEC) can be used across all applications. As with QoS, a
   means in application level protocols is needed to handle the A->B direction. To indicate that
   so, B returns a
   security association is needed for the application 183 response to execute.

   To solve both of these problems, we propose an extension A asking A to SDP
   which allows indication of pre-conditions for sessions. These
   preconditions indicate that participation in the session should not
   proceed until the preconditions are met. The preconditions we define
   are (1) success of end-to-end start resource reservation,
   reservation and (2) success
   of end- to-end security establishment. We chose to implement these
   extensions in SDP, rather than SIP [2] or SAP [10], since they are
   fundamentally a media session issue. SIP is session agnostic;
   information about codecs, ports, and RTP [9] are outside the scope
   of SIP. Since it is the media sessions that warn B as soon as the reservations and
   security refer to, SDP A->B direction is the appropriate venue for the extensions.

       SIP Working Group       Expiration 5/31/02                      5
                SIP Extensions ready for Resource Management   November 2001

   Furthermore, placement of
   the extensions session. A and B both start resource reservation. B finishes
   reserving resources in SDP rather than SIP or
   SAP allows specification of preconditions for individual media
   streams. For example, a multimedia lecture might require reservation
   for the audio, B->A direction, but does not alert the video (which is less important).

   Our extensions
   user yet, because network resources in both directions are completely backward compatible. If a recipient
   does not understand them, normal SIP or SAP processing will occur,
   at no penalty of call setup latency.

4.1 Requirements

   The basic motivation needed.
   When A finishes reserving resources in this work is to meet and possibly exceed the
   user expectations and human factors associated with telephony.

   In this section, we briefly describe A->B direction, it sends
   an UPDATE to B. B returns a 200 (OK) response for the application requirements UPDATE
   indicating that led to all the set of DCS signaling design principles.  In its
   basic implementation, DCS supports a residential telephone service
   comparable to preconditions for the local telephone services offered today. Some session have been met.
   At this point of time, B starts alerting the requirements for resource management, in concert with call
   signaling, are as follows:

   The system must minimize call defects.  These are situations where
   either the call never completes, or an error occurs after the
   destination is alerted.  Requirements on call defects are typically
   far more stringent than call blocking.  Note that we expect the
   provider user, and session
   establishment completes normally.

4 SDP parameters

   We define the endpoints to attempt to use lower bandwidth codecs
   as following media level SDP attributes:

        current-status     = "a=curr:" precondition-type
                           = SP status-type SP direction-tag
        desired-status     = "a=des:" precondition-type
                           = SP strength-tag SP status-type
                           = SP direction-tag
        confirm-status     = "a=conf:" precondition-type
                           = SP status-type SP direction-tag
        precondition-type  = "qos"
        strength-tag       = ("mandatory" | "optional" | "none"
                           = | "failure")
        status-type        = ("e2e" | "local" | "remote")
        direction-tag      = ("none" | "send" | "recv" | "sendrecv")

        Current status: The current status attribute carries the first line current
             status of defense against limited network capacity, and
   to avoid blocking calls. resources for a particular media stream.

        Desired status: The system must minimize desired status attribute carries the post-dial-delay, which is
             preconditions for a particular media stream. When the time
   between
             current status value has the user dialing same or a better value than
             the last digit and receiving positive
   confirmation from desired status value, the network.  This delay must preconditions are considered
             to be short enough that
   users do not perceive met.

        Confirmation status: The desired status attribute carries
             threshold conditions for a difference with post-dial delay in media stream. When the
   circuit switched status of
             network resources reach these conditions, the peer user
             agent will send an update of the session description
             containing an updated current status attribute for this
             particular media stream.

        Precondition type: This document defines quality of service
             preconditions. Extensions may define other types of
             preconditions.

        Strength tag: The strength tag indicates whether or conclude that not the
             callee can be alerted in case the network connectivity
   no longer exists.

   Call signaling needs to provide enough information fails to meet the resource
   management protocol so as to enable resources to be allocated in
             preconditions.

        Status type: We define two types of status: end-to-end and
             segmented. The end-to-end status reflects the
   network.  This typically requires most if not all status of the components
             end-to-end reservation of a packet classifier (source IP, destination IP, source port,
   destination port, protocol) to be available for resource allocation.

4.2 Overview

   For acceptable interactive voice communication it is important to
   achieve end-to-end QoS. The end-to-end QoS assurance implies
   achieving low packet delay and packet loss. End-to-end packet delay
   must be small enough that it does not interfere with normal voice
   conversations. resources. The ITU recommends no greater than 300 ms roundtrip
   delay for telephony service.  Packet loss must be small enough to
   not perceptibly impede voice quality or segmented status
             reflects the performance status of fax and
   voice band modems.

       SIP Working Group       Expiration 5/31/02                      6
                SIP Extensions for Resource Management   November 2001

   If it is found that the access network cannot guarantee reservations of
             both user agents. The end-to-end QoS
   resources, there are two alternatives: either (1) allow call
   signaling status corresponds to proceed with high probability of excessive delay and
   packet loss which could impair any interactive real-time
   communication between the participants, or (2) block
             tag "e2e" defined above and the call prior segmented status to the called party being alerted.  When calls are blocked because
   of
             tags "local" and "remote". End-to-end status is useful when
             end-to-end resource reservation mechanisms. The segmented
             status is useful when one or both UAs perform resource
             reservations on their respective access networks.

          A                                            B

          |                                            |
          |-------------(1) INVITE SDP1--------------->|
          |                                            |
          |<------(2) 183 Session Progress SDP 2-------|
          |  ***                                 ***   |
          |--*R*-----------(3) PRACK-------------*R*-->|
          |  *E*                                 *E*   |
          |<-*S*-------(4) 200 OK (PRACK)--------*S*---|
          |  *E*                                 *E*   |
          |  *R*                                 *R*   |
          |  *V*                                 *V*   |
          |  *A*                                 *A*   |
          |  *T*                                 *T*   |
          |  *I*                                 *I*   |
          |  *O*                                 *O*   |
          |  *N*                                 *N*   |
          |  ***                                 ***   |
          |  ***                                       |
          |  ***                                       |
          |-------------(5) UPDATE SDP3--------------->|
          |                                            |
          |<--------(6) 200 OK (UPDATE) SDP4-----------|
          |                                            |
          |<-------------(7) 180 Ringing---------------|
          |                                            |
          |-----------------(8) PRACK----------------->|
          |                                            |
          |<------------(9) 200 OK (PRACK)-------------|
          |                                            |
          |                                            |
          |                                            |
          |<-----------(10) 200 OK (INVITE)------------|
          |                                            |
          |------------------(11) ACK----------------->|
          |                                            |
          |                                            |

   Figure 1: Basic session establishment using preconditions
        Direction tag: The direction tag indicates the direction a lack
             concrete attribute is applicable to.

   The values of resources in a particular segment the tags "send", "recv", "local" and "remote" represent
   the point of view of the network, it entity generating the SDP description. In an
   offer, "send" is
   highly desirable that such blocking occur before the called party
   picks up.

   We do expect direction offerer->answerer and "local" is the endpoints to attempt to use lower bandwidth codecs,
   thereby avoiding blocking calls, as
   offerer's access network. In an answer, "send" is the first line of defense
   against limited network capacity.

   The call signaling direction
   answerer->offerer and resource reservation must be achieved "local" is the answerer's access network.

   The following example shows these new SDP attributes in such two media
   lines of a way that session description:

          m=audio 20000 RTP/AVP 0
          a=curr:qos e2e send
          a=des:qos optional e2e send
          a=des:qos mandatory e2e recv
          m=audio 20002 RTP/AVP 0
          a=curr:qos local sendrecv
          a=curr:qos remote none
          a=des:qos optional local sendrecv
          a=des:qos mandatory remote sendrecv

5 Usage of the post-dial-delay must be minimized without increasing new SDP status parameters in the probability of call defects. This means that SIP offer/answer model

   Parameter negotiation in SIP is carried out using the number of
   round-trip messages must be kept at an absolute minimum and messages
   must be sent directly end-system to end-system if possible. offer answer
   model described in [4]. The general idea behind the extension is simple. We define two new
   SDP attributes, "qos" and "security". The "qos" attribute indicates
   whether end-to-end resource reservation this model is optional or mandatory,
   and in which direction (send, recv, or sendrecv). When to provide a
   shared view of the attribute
   indicates mandatory, this means that session parameters for both user agents once the participant who
   answer has been received by the offerer. This section describes which
   values can our new SDP does not proceed with participation attributes take in the session
   until resource reservation has completed an answer depending on
   their value in the direction indicated.
   In this case, "not proceeding" means offer.

   To achieve a shared view of the status of a media stream, we define a
   model that consists of three tables: both user agents implement a
   local status table, and each offer/answer exchange has a transaction
   status table associated to it. The offerer generates a transaction
   status table identical to its local status table and sends it to the participant behaves as
   if they had not received
   answerer in the SDP at all. If offer. The anwerer uses the attribute indicates information of this
   transaction status table to update its local status table. The
   answerer also updates the transaction status table fields that QoS for were
   out of date and returns this table to the stream is optional, then offerer in the participant proceeds
   normally answer. The
   offerer can then update its local status table with the session, but should reserve network resources information
   received in the direction indicated, if they are capable. Absence of the "qos"
   attribute means answer. After this offer/answer exchange, the participant reserves resources for this stream,
   and proceeds normally with the session. This behavior is the normal
   behavior for SDP.

   Resource reservation takes place using whatever protocols
   participants must use, based on support by their service provider.
   If local
   status tables of both user agents are synchronised. They now have a
   common view of the ISP's status of the various participants are using differing
   resource reservation protocols, translation is necessary, but media stream. Sessions that involve
   several media streams implement these tables per media stream. Note,
   however, that this is done within the network, without knowledge a model of the participants.

   The direction attribute indicates in which direction reservations
   should be reserved. If "send", it means reservations should be made
   in the direction user agent behavior, not of media flow from the session originator
   software. An implementation is free to
   participants. If "recv", it means reservations should be made in take any approach that
   replicates the
   direction of media flow from participants external behavior this model defines.

5.1 Generating an offer

   Both user agents MUST implement a table, referred to as "local status
   table", reflecting the session originator.
   In the case status of "sendrecv", it means reservations should be made in
   both directions.  If the direction attribute is "sendrecv" but the
   endpoints only support a single-direction resource reservation
   protocol, then reservation. Tables 1
   and 2 show the format of this tables for both the originator end-to-end and participants cooperate to
   ensure the agreed precondition is met.

       SIP Working Group       Expiration 5/31/02                      7
                SIP Extensions for Resource Management   November 2001

   In
   segmented status types. For the case of security, end-to-end status type, the same attributes are defined -
   optional/mandatory, table
   contains two rows; one for each direction (i.e., send and send/recv/sendrecv. Their meaning is
   identical to recv). A
   value of "yes" in the one above, except "Current" field indicates that a security association
   should be established resource has
   been successfully reserved in the given corresponding direction. The details of the
   security association are "No"
   indicates that resources have not signaled by SDP; these depend on been reserved yet. The "Desired
   Strength" field indicates the
   Security Policy Database strength of the participant.

   Either party can include a "confirm" attribute preconditions in the SDP.  When the
   "Confirm" attribute is present, the recipient sends a COMET message
   to the sender, with SDP attached, telling
   corresponding direction. The table for the segmented status of each
   precondition as "success" or "failure."  If type
   contains four rows: both directions in the "confirm" attribute
   is present local access network and
   in the SDP sent by peer's access network. The meaning of the session originator to fields is the
   participant (e.g. same
   as in the SIP INVITE message), then end-to-end case.

   Before generating an offer, the participant
   sends offerer MUST build a transaction
   status table with the COMET message to current and the originator.  If desired status for each media
   stream. The different values of the "confirm" strength tag for the desired
   status attribute is present in have the SDP sent by following semantics:

        o None: no resource reservation is needed.

        o Optional: the recipient user agents SHOULD try to provide resource
          reservation, but the
   originator (e.g. in a SIP response message), then the originator
   sends session can continue regardless of
          whether this provision is possible or not.

        o Mandatory: the COMET message user agents MUST provide resource reservation.
          Otherwise, session establishment MUST NOT continue.

   The offerer then decides whether it is going to use the participant.

   When end-to-end
   status type or the "Confirm" attribute is present in both segmented status type. If the SDP sent by status type of the
   session originator to
   media line will be end-to-end, the participant (e.g. in user agent generates records with
   the SIP INVITE
   message), desired status and in the SDP sent by the recipient back to the
   originator (e.g. current status for each direction (send
   and recv) independently, as shown in a SIP response message), the session originator
   would wait table 1:

                   Direction  Current  Desired Strength
                   ____________________________________
                     send       no        mandatory
                     recv       no        mandatory

   Table 1: Table for the COMET message with end-to-end status type
   If the success/failure
   notification before responding with a COMET message, and responds
   instead with a CANCEL if a mandatory precondition is not met, or if
   a sufficient combination status type of optional preconditions are not met.  The
   recipient does not wait for the COMET message from media line will be segmented, the originator
   before sending its COMET message.

   The "confirm" attribute is typically used if user
   agent generates records with the direction attribute
   is "sendrecv" desired status and the originator or participant only supports a
   single-direction resource reservation protocol.  In such a case, the
   originator (or participant) would reserve resources current
   status for one each direction of media flow, (send and recv) and each segment (local and
   remote) independently, as shown in table 2:

                   Direction   Current  Desired Strength
                  ______________________________________
                  local send a confirmation with a direction
   attribute of "send."  The participant (or originator) would reserve
   resources     no           none
                  local recv     no           none
                  remote send    no         optional
                  remote recv    no           none

   Table 2: Table for the other direction.  On receipt of the COMET message,
   they would know that both directions have been reserved, and segmented status type

   At the
   precondition is met.

5. SDP Extension

   The formatting time of sending the qos attribute in the Session Description
   Protocol (SDP)[3] is described by offer, the following BNF:

      qos-attribute    = "a=qos:" strength-tag SP direction-tag
                                [SP confirmation-tag]
      strength-tag     = ("mandatory" | "optional" | "success" |
                                "failure")
      direction-tag    = ("send" | "recv" | "sendrecv")
      confirmation-tag = "confirm" offerer's local status table
   and the security attribute:

      security-attribute = "a=secure:" SP strength-tag SP direction-tag

       SIP Working Group       Expiration 5/31/02                      8
                SIP Extensions for Resource Management   November 2001

                                [SP confirmation-tag]

5.1 SDP Example

   The following example shows an SDP description carried in a SIP
   INVITE message from A to B:

           v=0
           o=mhandley 2890844526 2890842807 IN IP4 126.16.64.4
           s=SDP Seminar
           c=IN IP4 224.2.17.12/127
           t=2873397496 2873404696
           m=audio 49170 RTP/AVP 0
           a=qos:mandatory recv confirm
           m=video 51372 RTP/AVP 31
           a=secure:mandatory sendrecv
           m=application 32416 udp wb
           a=orient:portrait
           a=qos:optional sendrecv
           a=secure:optional sendrecv

   This SDP indicates that B should not continue its involvement in transaction status table contain the
   session until resources for same values.

   With the audio are reserved from B to A, and
   a bi-directional security association is established for transaction status table, the video.
   B can join user agent generates the sessions once these preconditions are met, but should
   reserve resources
   current-status and establish a bi-directional security
   association for the whiteboard.

5.2 SDP Allowable Combinations

   If desired status lines following the recipient syntax of
   Section 4 and the rules described below in Section 5.1.1.

5.1.1 SDP (e.g. encoding

   For the UAS) is capable and willing to
   honor end-to-end status type, the precondition(s), it returns a provisional response
   containing SDP, along user agent MUST generate one
   current status line with the qos/security attributes, tag "e2e" for each
   such stream. This SDP MUST be a subset of the preconditions
   indicated in the INVITE.

   Table 1 illustrates media stream. If the allowed values
   strength tags for the direction tag both directions are equal (e.g., both mandatory) in
   the
   response. Each row represents a value of transaction status table, the direction in user agent MUST add one desired
   status line with the SIP
   INVITE, tag "sendrecv". If both tags are different, the
   user agent MUST include two desired status lines, one with the tag
   "send" and each column the value in other with the response. An entry of N/A
   means that this combination is not allowed. A value tag "recv".

        The semantics of A->B (B->A)
   implies that two lines with the precondition same strength tag, one
        with a "send" tag and the other with a "recv" tag, is for resources reserved (or security
   established) from A the
        same as one "sendrecv" line. However, in order to B (B achieve a
        more compact encoding, we have chosen to A). A value of A<->B means that make mandatory the
   precondition is for resource reservation or security establishment
   in both directions. The value in
        latter format.

   For the response is segmented status type, the user agent MUST generate two
   current status lines: one used by
   both parties.

       SIP Working Group       Expiration 5/31/02                      9
                SIP Extensions for Resource Management   November 2001

                                B: response
           A: request     send       recv  sendrecv  none
           send           N/A        A->B    N/A      --
           recv           B->A       N/A     N/A      --
           sendrecv       A<-B       B<-A   A<->B     --
           none            --         --      --      --

                Table 1: Allowed values of coupling

   Table 2 illustrates the allowed values for with the strength tag in the
   request "local" and response. A "Y" means the combination is allowed, other with the
   tag "remote". The user agent MUST add one or two desired status lines
   per segment (i.e., local and remote). If for a
   "N" means it is not. The value particular segment
   (local or remote) the tags for both directions in the response is transaction
   status table are equal (e.g., both mandatory), the user agent MUST
   add one used by desired status line with the tag "sendrecv". If both parties.

                                B: response
           A: request   mandatory     optional  none
           mandatory        Y            Y       Y
           optional         N            Y       Y
           none             N            N       Y

                Table 2: Allowed values of strength parameter

   Table 3 illustrates tags are
   different, the allowed values for user agent MUST include two desired status lines, one
   with the direction tag in a
   confirmation message (COMET) sent from the originator to a
   participant, based on "send" and the value of other with the direction tag negotiated in "recv".

   Note that the initial request and response.  A "Y" means rules above apply to the combination is
   allowed, and desired strength tag "none" as
   well. This way, a "N" means it is not and SHOULD be ignored by the
   participant.

                         A: confirmation
           B: reponse  send   recv   sendrecv
           A->B         Y       N       N
           A<-B         N       Y       N
           A<->B        Y       Y       Y

        Table 3: Allowed values user agent that supports quality of direction in confirmation from A

   Table 4 illustrates the allowed values for service but
   does not intend to use them, adds desired status lines with the direction
   strength tag "none". Since this tag can be upgraded in a
   confirmation message (COMET) sent from the participant to the
   originator, based on the value of the direction tag negotiated answer, as
   described in Section 5.2, the initial answerer can request and response.  A "Y" means quality of service
   reservation without a need of another offer/answer exchange.

   The example below shows the combination is
   allowed, SDP corresponding to tables 1 and a "N" means 2.

          m=audio 20000 RTP/AVP 0
          a=curr:qos e2e none
          a=des:qos mandatory e2e sendrecv
          m=audio 20002 RTP/AVP 0
          a=curr:qos local none
          a=curr:qos remote none
          a=des:qos optional remote send
          a=des:qos optional local none

5.2 Generating an Answer

   When the answerer receives the offer, it is not and SHOULD be ignored by recreates the
   originator.

                         B: confirmation
           B: reponse  send   recv   sendrecv
           A->B         N       Y       N
           A<-B         Y       N       N
           A<->B        Y       Y       Y

        Table 4: Allowed values of direction transaction
   status table using the SDP attributes contained in confirmation from B

      SIP Working Group       Expiration 5/31/02                      10
                SIP Extensions for Resource Management   November 2001

6. SIP Extension: The COMET Method

   The COMET method is used for communicating successful completion of
   preconditions between the user agents. offer. The signaling path for the COMET method is
   answerer updates both its local status and the signaling path
   established as a result of transaction status
   table following the call setup.  This can be either
   direct signaling between rules below:

        Desired Strength: We define an absolute ordering for the calling
             strength tags: none, optional and called user agents or a
   signaling path involving SIP proxy servers that were involved in mandatory. Mandatory is
             the
   call setup tag with highest grade and added themselves to none the Record-Route header on tag with lowest
             grade. An answerer MAY upgrade the
   initial INVITE message.

   The precondition information is communicated desired strength in any
             entry of the message body,
   which transaction status table, but it MUST contain an SDP.  For every agreed precondition, the
   strength-tag MUST indicate "success" NOT
             downgrade it. Therefore, it is OK to upgrade a row from
             none to optional, from none to mandatory or "failure".

   If from optional
             to mandatory, but not the initial request contained Record-Route headers, other way around.

        Current Status: For every row, the
   provisional response MUST contain a copy value of those headers, as if the
   response were a 200 OK to "Current" field
             in the initial request. Since provisional
   responses MAY contain Record-Route transaction status table and Contact headers, the COMET
   request MUST contain Route headers, constructed as specified in [2],
   if the Record-Route headers were present in local status
             table of the provisional
   response.

   A UAC MUST NOT insert a Route header into a COMET request if no
   Record-Route header was present in answerer have to be compared. Table 3 shows
             the response. four possible combinations. If both fields have the initial request was sent with credentials, the COMET request
   SHOULD contain those credentials as well.

   The Call-ID in the COMET MUST match that
             same value (two first rows of the provisional
   response. The CSeq in this request MUST table 3, nothing needs to be larger than
             updated. If the last
   request sent by this UAC for this call leg. The To, From, and Via
   headers MUST be present, "Current" field of the transaction status
             table is "Yes" and MUST be constructed as they would be
   for a re-INVITE or BYE as specified in [2]. In particular, if the
   provisional response contained a tag in field of the To field, this tag local status table is
             "No" (third row of table 3), the latter MUST be mirrored in set to
             "Yes". If the To "Current" field of the COMET.

   Once the COMET request is created, it transaction status
             table is sent by "No" and the UAC. It is sent
   as would any other non-INVITE request for a call. In particular,
   when sent over UDP, field of the COMET request local status table is retransmitted as specified
   in [2].  Note that a UAC SHOULD NOT retransmit the COMET request
   when it receives a retransmission
             "Yes" (forth row of table 3), the provisional response being
   acknowledged, although doing so does not create a protocol error. As
   with any other non-INVITE request, the UAC continues answerer needs to retransmit
   the COMET request until check
             if it receives has local information (e.g., a final response.

   Use of CANCEL confirmation of a COMET is as specified in [2].

6.1 Header Field Support for COMET Method

      SIP Working Group       Expiration 5/31/02                      11
                SIP Extensions for Resource Management   November 2001

   Tables 5 and 6 are extensions
             resource reservation has been received) about that
             particular current status. If it does, the "Current" field
             of tables 4 and 5 in the SIP
   specification[2].  Refer transaction status table is set to Section 6 of [2] for a description of "Yes". If the content of
             answerer does not have local information about that current
             status, the tables.

6.2 Responses to "Current" field of the COMET Request Method

   If a server receives a COMET request it MUST send a final response.

   A 200 OK response local status table MUST
             be sent by a UAS set to "No".

               Transaction status table  Local status table
               ____________________________________________
                          no                     no
                         yes                    yes
                         yes                     no
                          no                    yes

   Table 3: Possible values for a COMET request if the
   COMET request was successfully received for "Current" fields

   Once both tables have been updated an existing call.
   Beyond that, no additional operations are required.

   A 481 Call Leg/Transaction Does Not Exist message MUST answer is generated following
   the rules described in Section 5.1.1 and taking into account that
   "send", "recv", "local" and "remote" tags have to be sent by a
   UAS if inverted in the COMET request does not match any existing call leg.

             Header                    Where    COMET
             ------                    -----    ----
             Accept                      R       o
             Accept-Encoding             R       o
             Accept-Language             R       o
             Allow                      200      -
             Allow                      405      o
             Authorization               R       o
             Call-ID                    gc       m
             Contact                     R       o
             Contact                    1xx      -
             Contact                    2xx      -
             Contact                    3xx      -
             Contact                    485      -
             Content-Encoding            e       o
             Content-Length              e       o
             Content-Type                e       *
             CSeq                       gc       m
             Date                        g       o
             Encryption                  g       o
             Expires                     g       o
             From                       gc       m
             Hide                        R       o
             Max-Forwards                R       o
             Organization                g       o
             Table 5 Summary of header fields, A-0

      SIP Working Group       Expiration 5/31/02                      12
                SIP Extensions for Resource Management   November 2001

             Header                    Where    COMET
             ------                    -----    ----
             Priority                    R       -
             Proxy-Authenticate         407      o
             Proxy-Authorization         R       o
             Proxy-Require               R       o
             Record-Route                R       o
             Record-Route               2xx      o
             Require                     R       o
             Response-Key                R       o
             Retry-After                 R       -
             Retry-After            404,480,486  o
             Retry-After                503      o
             Retry-After              600,603    o
             Route                       R       o
             Server                      r       o
             Subject                     R       o
             Timestamp                   g       o
             To                        gc(1)     m
             Unsupported                420      o
             User-Agent                  g       o
             Via                       gc(2)     m
             Warning                     r       o
             WWW-Authenticate           401      o
   answer, as shown in table 4.

                              Offer   Answer
                              ______________
                               send    recv
                               recv    send
                              local   remote
                              remote  local

   Table 6 Summary 4: Values of header fields, P-Z

   Other request failure (4xx), Server Failure (5xx) tags in offer and Global Failure
   (6xx) responses MAY be sent for answers

   At the COMET Request.

6.3 Message Body Inclusion

   The COMET request MUST time the answer is sent, the transaction status table and the
   answerer's local status table contain a message body, with Content-type
   "application/sdp".

6.4 Behavior of SIP User Agents

   Unless stated otherwise, the protocol rules for same values. Therefore,
   this answer contains the COMET request
   governing shared view of the usage status of tags, Route and Record-Route, retransmission the media line
   in the current-status attribute and reliability, CSeq incrementing the negotiated strength and message formatting follow
   those
   direction tags in [2] as defined for the BYE request.

   A COMET request MAY be cancelled.  A UAS receiving a CANCEL for a
   COMET request SHOULD respond to desired-status attribute.

   If the COMET with a "487 Request
   Cancelled" response if a final response has not been resource reservation mechanism used requires participation of
   both user agents, the answerer SHOULD start resource reservation
   after having sent to the
   COMET answer and then behave the offerer SHOULD start resource
   reservation as soon as if the request were never answer is received.

6.5 Behavior If participation of SIP Proxy
   the peer user agent is not needed (e.g., segmented status type), the
   offerer MAY start resource reservation before sending the offer and Redirect Servers

6.5.1 Proxy Server

   Unless stated otherwise,
   the protocol rules for answerer MAY start it before sending the COMET request at answer.

   The status of the resource reservation of a proxy are identical media line can change
   between two consecutive offer/answer exchanges. Therefore, both user
   agents MUST keep their local status tables up to those for a BYE request as specified in
   [2].

      SIP Working Group       Expiration 5/31/02                      13
                SIP Extensions for Resource Management   November 2001

6.5.2 Forking Proxy Server

   Unless stated otherwise, date using local
   information through the protocol rules for duration of the COMET request at
   a proxy are identical to those for a BYE request as specified in
   [2].

6.5.3 Redirection Server

   Unless stated otherwise, session.

6 Suspending and Resuming Session Establishment

   A user agent server that receives an offer with preconditions
   SHOULDNOT alert the protocol rules for user until all the COMET request at
   a proxy mandatory preconditions are identical to those for a BYE
   met; session establishment is suspended until that moment.

   A user agent server may receive an INVITE request as specified with no offer in
   [2].

7. SIP Extension: The 183-Session-Progress Response

   An additional provisional response is defined by
   it. In this draft, which
   is returned by a UAS to convey information not otherwise classified.

7.1 Status Code and Reason Phrase

   The case, following is to be added to Figure 4 normal SIP procedures, the user agent
   server will provide an offer in Section 5.1.1,
   Informational and success Status codes.

        Informational = "183"  ;Session-Progress

7.2 Status Code Definition

   The following is to be added to a new section 7.1.5

   7.1.5 183 Session Progress

   The 183 (Session Progress) reliable response is used to convey information
   about the progress of the call which is not otherwise classified. (1xx or 2xx). The Reason-Phrase MAY be used to convey more details about
   user agent client will send the call
   progress.

   The Session Progress response MAY contain a message body. answer in another SIP request. If so, it
   MUST the
   offer and the answer contain a "Content-Disposition" header indicating preconditions, the proper
   treatment of user agent client
   SHOULD NOT alert the message body.

8. SIP Extension: The 580-Precondition-Failure Response

   An additional error response is defined by this draft, which is
   returned by a UAS if it is unable to perform user until all the mandatory preconditions for in
   the session.

8.1 Status Code and Reason Phrase

   The following answer are met.

   While session establishment is to be added to Figure 8, Server error status codes

        Server-Error =  "580"  ;Precondition-Failure

8.2 Status Code Definition

      SIP Working Group       Expiration 5/31/02                      14
                SIP Extensions suspended, user agents SHOULD not send
   any data over any media stream. In the case of RTP [5], neither RTP
   nor RTCP packets are sent.

   A user agent server knows that all the preconditions are met for Resource Management   November 2001

   The following is to be added to a new section 7.5.7.

   7.5.7 580 Precondition Failure

   The server was unable to establish
   media line when its local status table has a value of "yes" in all
   the qos or security association
   mandated by rows whose strength tag is "mandatory". When the SDP precondition.

   The Precondition Failure response MUST contain a message body, with
   Content-Type "application/sdp", giving preconditions of
   all the specifics media lines of the
   precondition that could session are met, session establishment
   SHOULD resume.

   For an initial INVITE suspending and resuming session establishment
   is very intuitive. The callee will not be alerted until all the
   mandatory preconditions are met.

9. SIP Extension: Content-Disposition header

   An additional entity header is defined by this draft, which is
   returned by a UAS in a provisional response indicating However, offers containing
   preconditions
   for the session.

   The following is to be added to Table 3, SIP headers, sent in Section 3.

        Entity-header   = Content-Disposition   ; Section 6.14a

   The following entry is to be added to Table 4, Summary the middle of header
   fields, A-O, in Section 6.

                                where  enc e-e  ACK BYE CAN INV OPT REG
        Content-Disposition       e         e    o   o   -   o   o   o

   The following is to be added to a new section after 6.14.

   6.14a Content-Disposition

        Content-disposition  = "Content-Disposition" ":"
                                Disposition-type *( ";" disp-param)
        Disposition-type     = "precondition" | disp-extension-token
        Disp-extension-token = token
        Disp-param           = "handling" "=" "optional" | "required"
                                | other-handling
        Other-handling       = token

   The Content-Disposition header field describes how the message body
   is to be interpreted by an ongoing session need further
   explanation. Both user agents SHOULD continue using the UAC or UAS.

   The value "precondition" indicates old session
   parameters until all the body part describes QoS
   and/or security mandatory preconditions are met. At that SHOULD be established prior to
   moment, the start of user agents can begin using the session. new session parameters.
   Section 10 contains an example of this situation.

7 Status Confirmation

   The handling parameter, disp-param, describes how the UAC or UAS
   should react if it receives qos-confirm-status attribute MAY be used in both offers and
   answers. This attribute represents a message body whose content type or
   disposition type it does not understand.  If the parameter has threshold for the
   value "optional" resource
   reservation. When this threshold is reached or surpassed, the UAS user
   agent MUST ignore send an offer to the message body; if it has peer user agent reflecting the
   value "required" new
   current status of the UAS MUST return 415 (Unsupported Media Type). media line. If the handling parameter this threshold is missing, crossed again
   (e.g., the value "required" is to be
   assumed.

      SIP Working Group       Expiration 5/31/02                      15
                SIP Extensions for Resource Management   November 2001

10. Option tag network stops providing resources for Requires and Supported headers

   This draft defines the option tag "precondition" for use in media stream),
   the
   Require and Supported headers [12].

   A UAS that supports this extension user agent MUST respond to an OPTION request
   with send a Supported header new offer as well.

   If a peer has requested confirmation on a particular stream, an agent
   MUST mark that includes the "precondition" tag.

   A UAC MAY include stream with a "Require: precondition" flag in an INVITE request if
   it wants the session initiation to fail if its local status table. When all
   the UAS does not support rows with this feature.  A UAC that would respond to flag have a failed session (if due
   to lack value of precondition support) by immediately retrying "yes", the session
   without user agent MUST
   send a new offer to the preconditions, SHOULD NOT include this Require tag
   value.

   Presence of peer. This offer will contain the precondition entries current
   status of resource reservation in the SDP message body of an
   INVITE request or response indicates support qos-current-status attributes.
   If later any of the rows with this feature.  The
   UAC or UAS MAY in addition include flag transition to "No", a "Supported: precondition"
   header in the request or response.

11. SIP Usage Rules

11.1 Overview new
   offer MUST be sent as well.

   Confirmation attributes are not negotiated. The session originator (UAC) prepares an SDP message body for the
   INVITE describing the desired QoS and security preconditions for
   each media flow, and answerer uses the desired directions. The token
   value "send"
   means the direction of media from originator (whichever entity
   created the SDP) to recipient (whichever entity received the SDP qos-confirm-status attribute in
   a SIP message), and "recv" is from recipient to originator. In an
   INVITE, the UAC is the originator, offer and the UAS is
   offerer uses the recipient. The
   roles are reversed value of this attribute in the response.

   A User Agent with answer.

   For example, if a user agent receives an active session that desires to change SDP description with the media
   flows prepares
   following attributes:

          m=audio 20002 RTP/AVP 0
          a=curr:qos local none
          a=curr:qos remote none
          a=des:qos mandatory local sendrecv
          a=des:qos mandatory remote sendrecv
          a=conf:qos remote sendrecv

   It will send an SDP message body for offer as soon as it reserves resources in its access
   network ("remote" tag in the re-INVITE describing received message) for both directions
   (sendrecv).

8 Refusing an offer

   We define a new SIP status code:

          Server-Error =  "580"  ;Precondition Failure

   When an answerer cannot or is not willing to meet the
   desired QoS and security preconditions for
   in the revised media flows
   and offer it SHOULD reject the offer by returning a 580
   (Precondition-Failure) response. This response SHOULD contain an SDP
   description indicating which desired directions.  The procedures for the re-INVITE, and status triggered the subsequent message exchanges, are identical to those of an
   initial INVITE. failure.
   The recipient corresponding desired status line MUST a value of the INVITE (UAS) returns a 18x provisional response
   containing a Content-Disposition strength
   tag of "precondition," and SDP with "failure", as shown in the
   qos/security attribute for each stream having a precondition.  The
   preconditions in this example below:

          m=audio 20000 RTP/AVP 0
          a=des:qos failure e2e send

   SDP (i.e. strength tag and direction tag) are
   equal to, or a subset of, description indicating this type of failure MUST follow the preconditions indicated
   format for describing media capabilities defined in the INVITE.
   The UAS would typically include a confirmation request in this SDP.
   Unlike normal SIP processing, the UAS MUST NOT alert
   offer/answer model [4].

   Using the called user
   at this point.  The UAS now attempts 580 (Precondition Failure) status code to reserve the qos resources
   and establish the security associations.

   The 18x provisional response refuse an offer
   is received by the UAC. If the 18x
   contained SDP with mandatory qos/security parameters, useful when the UAC offer came in an INVITE or in an UPDATE request.
   However, SIP does not let the session proceed until the mandatory preconditions are

      SIP Working Group       Expiration 5/31/02                      16
                SIP Extensions for Resource Management   November 2001

   met.  The UAC attempts provide a means to reserve the needed resources and establish
   the security associations. refuse offers that contained
   in a response (1xx or 2xx) to an INVITE.

   If either party requests a confirmation, UAC generates an initial INVITE without an offer and receives an
   offer in a COMET message 1xx or 2xx response which is sent not acceptable, it SHOULD
   respond to this offer with a correctly formed answer and immediately
   after that party.  The COMET message contains send a CANCEL or a BYE.

   If the success/failure
   indication for each precondition. For offer comes in a precondition with 1xx or 2xx response to a
   direction value re-INVITE, A would
   not have a way to reject it without terminating the session at the
   same time. The same recommendation given in Section 14.2 of "sendrecv," [1]
   applies here:

        "The UAS MUST ensure that the COMET indicates whether session description overlaps
        with its previous session description in media formats,
        transports, other parameters that require support from the
   sender
        peer. This is able to confirm both directions or only one direction.
   Upon receipt of avoid the COMET message, need for the UAC/UAS continues normal SIP
   call handling.  For a UAS this includes alerting peer to reject the user and
   sending a 180-Ringing or 200-OK response.  The UAC SIP transaction
   completes normally.

   Note that this extension requires usage of reliable provisional
   responses [11]. This
        session description. If, however, it is because the 18x contains SDP unacceptable to A,
        A SHOULD generate an answer with
   information required for the a valid session originator
        description, and then send a BYE to initiate
   reservations towards terminate the participant.

11.2 Behavior of Originator (UAC)

   The session originator (UAC) MAY include QoS session."

9 Option tag for Require and security
   preconditions (including Supported header fields

   We define the desired direction) option tag "precondition" for each media flow use in the SDP sent Require and
   Supported header fields. An offerer MUST include this tag if the
   offer contains one or more strength tags with the INVITE. The token value "send" means the
   direction of media from originator (whichever entity created the
   SDP) to recipient (whichever entity received "mandatory".
   If all the SDP strength tags in a SIP
   message).  The token value "recv" means the direction of media from
   recipient to originator.  If preconditions description are included in the
   INVITE request, "optional" or "none"
   the UAC offerer MUST indicate support for reliable
   provisional responses [11].

   If the UAC receives a 18x provisional response without include this tag either in a Content-
   Disposition of "precondition," or without SDP, Supported header field
   or with SDP but
   without any qos/security preconditions in any stream, UAC treats it
   as an indication a Require header field. It is, however, RECOMMENDED, that the UAS
   Supported header field is unable or unwilling to perform the used in this case. The lack of
   preconditions requested. As such, in the UAC SHOULD proceed with normal
   call setup procedures.

   If answer would indicate that the 18x provisional response contained a Content-Disposition answerer did not
   support this extension.

   The mapping of
   "precondition" offers and contained SDP with mandatory qos/security
   parameters, the UAC SHOULD NOT let the session proceed until the
   mandatory preconditions are met.

   If answers to SIP requests and responses is
   performed following the 18x provisional response with rules given in . Therefore, a user agent
   including preconditions requested an
   acknowledgement (using the methods of [11]), in the UAC SDP MUST include an
   updated SDP both "100rel" [6] and
   "update"  tags in the PRACK if the UAC modified the original SDP based
   on the response from the UAS.  Such a modification MAY be due to
   negotiation of compatible codecs, or MAY be due to negotiation of
   mandatory preconditions.  If the provisional response received from
   the UAS is a 180-Ringing, Require header field.

10 Examples

   The following examples cover both status types; end-to-end and the direction value
   segmented.

10.1 End-to-end Status Type

   The call flow of figure 2 shows a mandatory
   precondition is "sendrecv," and the UAC uses a one-way QoS mechanism
   (such as RSVP), basic session establishment using
   the updated end-to-end status type. The SDP in the PRACK SHOULD request a
   confirmation from the UAS so that the bi-directional precondition
   can be satisfied before performing the requested alerting function.

      SIP Working Group       Expiration 5/31/02                      17
                SIP Extensions for Resource Management   November 2001

   Upon receipt descriptions of the 18x provisional response with preconditions, the
   UAC MUST initiate the qos reservations and establish the security
   associations to the best this example are
   shown below:

   SDP1: B includes end-to-end quality of its capabilities.

   If the UAC had requested confirmation service preconditions in the
   initial SDP, offer.

          m=audio 20000 RTP/AVP 0
          c=IN IP4 192.0.2.1
          a=curr:qos e2e none
          a=des:qos mandatory e2e sendrecv

   SDP2: Since B uses RSVP, it MAY
   wait for the COMET message can know when resources in its "send"
   direction are available, because it will receive RESV messages from
   the UAS containing network. However, it does not know the
   success/failure status of each precondition.  The UAC MAY set a
   local timer to limit the time waiting for preconditions to complete.
   The UAC SHOULD merge the success/failure status in the COMET message
   with its local status.  For example, if the COMET message indicated
   success reservations
   in the "send" direction, and the UAC was also able to meet
   the precondition other direction. B requests confirmation for resource
   reservations in the "send" direction, they combine its "recv" direction to meet the
   precondition peer user agent A in its
   answer.

          m=audio 30000 RTP/AVP 0
          c=IN IP4 192.0.2.4
          a=curr:qos e2e none
          a=des:qos mandatory e2e sendrecv
          a=conf:qos e2e recv

   After having sent the "sendrecv" direction.

   If any of answer B starts reserving network resources for
   the mandatory preconditions cannot be met, media stream. When A receives this answer (2) it starts
   performing resource reservation as well. Both UAs use RSVP, so A
   sends PATH messages towards B and a
   confirmation was not requested by the UAS, B sends PATH messages towards A.

   As time passes by, B receives RESV messages confirming the UAC MUST send a
   CANCEL and terminate
   reservation. However, B waits until resources in the session.  If other direction
   as reserved as well since it did not receive any of confirmation and the optional
   preconditions cannot be met, the UAC MAY consult still have not been met.

   SDP3: When A receives RESV messages it sends an updated offer (5) to
   B:

          m=audio 20000 RTP/AVP 0
          c=IN IP4 192.0.2.1
          a=curr:qos e2e send
          a=des:qos mandatory e2e sendrecv

   SDP4: B responds with an answer (6) which contains the
   originating customer for guidance on whether to complete current status
   of the
   session.

   When all resource reservation (i.e., sendrecv):

          m=audio 30000 RTP/AVP 0
          c=IN IP4 192.0.2.4
          a=curr:qos e2e sendrecv
          a=des:qos mandatory e2e sendrecv

   At this point of time, session establishment resumes and B returns a
   180 (Ringing) response (7).

   Note that now the preconditions have either media stream has been met or have failed, already established, and
   the SDP A
   has received from the UAS included a confirmation request, 180 (Ringing) response. Since the
   UAC MUST send a COMET message to direction of the UAS with SDP.  Each
   precondition
   stream is updated "sendrecv", A will not generate local ringback, since it
   assumes that it will receive early media over this stream.

   However, if B wants A to indicate success/failure and the
   appropriate direction tag is updated based on generate local operations
   performed combined with ringback, it can put the received COMET message, if any.

   The session now completes normally, as per [2].  Any SDP included in
   subsequent requests
   media stream on hold in SDP4. In this transaction MUST NOT change case, B would put the agreed media definitions (e.g. all lines
   stream off hold by sending an offer in the SDP description other than 200 OK for the precondition lines).

11.3 Behavior of Destination (UAS)

   On receipt of an INVITE request containing preconditions, (8).
   The contents of the UAS
   MUST generate a 18x provisional response containing a subset of the
   preconditions supported by the UAS.  In the response, the token
   value "send" means the direction of the media from the UAS to the
   UAC, and "recv" is from the UAC to the UAS.  This is reversed from
   the SDP in the initial INVITE.  The 18x provisional response MUST
   include a Content-Disposition header with parameter "precondition."
   If the "confirm" attribute is present in the SDP received from the
   UAC, or if the direction tag of a mandatory QoS precondition is
   "sendrecv" and the UAS only supports a one-way QoS reservation
   scheme (e.g. RSVP), then the UAS SHOULD include a "confirm"
   attribute. If the UAS is able to satisfy the preconditions
   immediately, and no confirmation is requested by the UAC, then a
   180-Ringing response is appropriate.  Otherwise a 183-Session-
   Progress response SHOULD be used.

   If the INVITE request did not contain any preconditions, but did
   indicate support for reliable provisional responses[11], the UAS MAY
   include preconditions in a 18x provisional response to the INVITE.

      SIP Working Group       Expiration 5/31/02                      18
                SIP Extensions for Resource Management   November 2001

   The 18x provisional response MUST include a Content-Disposition
   header with the parameter "precondition." The 18x provisional
   response MUST request an acknowledgement using the mechanism of
   [11].  If the PRACK includes an SDP without any preconditions, the
   UAS MAY complete the session without the preconditions, or MAY
   reject the INVITE request.

   The UAS SHOULD request an acknowledgement to the 18x provisional
   response, using the mechanism of [11].  The UAS SHOULD wait for the
   PRACK message before initiating resource reservation to allow the
   resource reservation to reflect 3-way SDP negotiation, or other
   information available only through receipt of the PRACK.

   If the INVITE request or PRACK message contained mandatory
   preconditions, or requested a confirmation of preconditions, the UAS
   MUST NOT alert the called user.

   The UAS now attempts to reserve the qos resources and establish the
   security associations.  The UAS MAY set a local timer to limit the
   time waiting for preconditions to complete.

   If the UAS is unable to perform any mandatory precondition, and
   neither the UAC nor UAS requested a confirmation, the UAS MUST send
   a 580-Precondition-Failure response to the UAC.  If the UAS is
   unable to perform any optional precondition, it MAY consult with the
   customer to obtain guidance regarding completion of the session.

   When processing of all preconditions is complete, if a precondition
   in the SDP specified a confirmation request, the UAS MUST send a
   COMET message to the UAC containing SDP, along with the qos/security
   result of success/failure for each precondition.  If the direction
   tag of the precondition was "sendrecv" but the UAS was only able to
   ensure "send" or "recv," the direction tag in the COMET MUST only
   indicate what the UAS ensures.  The Request-URI, call-leg
   identification, and other headers of this COMET message are to be
   constructed identically to a BYE.

   If the UAS had requested confirmation of a precondition in the
   response SDP, it SHOULD wait for the COMET message from the
   originator containing the success/failure indication of each
   precondition from the originator's point of view.  The
   success/failure indications in the COMET message from the UAC SHOULD
   be combined with the local status to determine the overall
   success/failure of the precondition.  For example, if the COMET
   message indicated success in the "send" direction, and the UAS was
   also able to meet the precondition in the "send" direction, they
   combine to meet the precondition in the "sendrecv" direction.  If
   that combination indicates a failure for a mandatory precondition,
   the UAS MUST send a 580-Precondition-Failure response to the UAC.

   Once the preconditions are met, the UAS alerts the user, and the SIP
   transaction proceeds normally.

      SIP Working Group       Expiration 5/31/02                      19
                SIP Extensions for Resource Management   November 2001

   The UAS MAY send additional 18x provisional responses with Content-
   Disposition of "precondition," and the procedures described above
   are repeated sequentially for each.

   Any SDP included in subsequent requests and responses in this
   transaction MUST NOT change the agreed media definitions (e.g. all
   lines in the SDP description other than the precondition lines).

12. Examples

12.1 Single Media Call Flow

   Figure 1 presents a high-level overview of a basic end-point to end-
   point (UAC-UAS) call flow.  This example is appropriate for a
   single-media session with a mandatory quality-of-service "sendrecv"
   precondition, where both the UAC and UAS can only perform a single-
   direction ("send") resource reservation.

   The session originator (UAC) prepares an SDP message body for the
   INVITE describing the desired QoS and security preconditions for
   each media flow, and the desired direction "sendrecv." This SDP messages for this alternative flow is
   included shown
   below:

   SDP4 (on hold):

          m=audio 30000 RTP/AVP 0
          c=IN IP4 192.0.2.4
          a=recvonly
          a=curr:qos e2e sendrecv
          a=des:qos mandatory e2e sendrecv

   SDP5 in the INVITE message sent through the proxies, and
   includes an entry "a=qos:mandatory sendrecv."

   The recipient of the INVITE (UAS), being willing to perform the
   requested precondition, returns a 183-Session-Progress provisional
   response containing SDP, along with the qos/security attribute for
   each stream having a precondition.  Since the "sendrecv" direction
   tag required a cooperative effort of the UAC and UAS, the UAS
   requests a confirmation when the preconditions are met, with the SDP
   entry "a=qos:mandatory 200 OK (10):

          m=audio 30000 RTP/AVP 0
          c=IN IP4 192.0.2.4
          a=sendrecv
          a=curr:qos e2e sendrecv confirm."  The UAS now attempts to
   reserve the qos resources and establish
          a=des:qos mandatory e2e sendrecv

   SDP6 in the security associations.

   The 183-Session-Progress provisional response is sent using ACK (11):

          m=audio 20000 RTP/AVP 0
          c=IN IP4 192.0.2.1
          a=sendrecv
          a=curr:qos e2e sendrecv
          a=des:qos mandatory e2e sendrecv

   Let's assume that in the
   reliability mechanism middle of [11].  UAC sends the appropriate PRACK and
   UAS responds with a 200-OK session A wishes to change the PRACK.

   The 183-Session-Progress is received by the UAC, and the UAC
   requests the resources needed in its "send" direction, and
   establishes the security associations. Once the preconditions are
   met, the UAC sends a COMET message as requested by the confirmation
   token.  This COMET message contains an entry "a=qos:success send"

      SIP Working Group       Expiration 5/31/02                      20
                SIP Extensions for Resource Management   November 2001

   Originating (UAC)                            Terminating (UAS)
        |                  SIP-Proxy(s)
          A                                            B

          |                                            |
          |-------------(1) INVITE SDP1--------------->|
          |                                            |
        |---------------------->|---------------------->|
          |<------(2) 183 Session Progress SDP 2-------|
          |  ***                                 ***   |
          |--*R*-----------(3) PRACK-------------*R*-->|
          |  *E*                                 *E*   |       183 w/SDP
          |<-*S*-------(4) 200 OK (PRACK)--------*S*---|
          |       183 w/SDP  *E*                                 *E*   |
        |<----------------------|<----------------------|
          |  *R*                                 *R*   |
          |                       PRACK  *V*                                 *V*   |
        |---------------------------------------------->|
          |               200 OK (of PRACK)  *A*                                 *A*   |
        |<----------------------------------------------|
          | Reservation                       Reservation  *T*                                 *T*   |
         ===========>                       <===========
          |  *I*                                 *I*   |
          |  *O*                                 *O*   |
          |               COMET  *N*                                 *N*   |
        |---------------------------------------------->|
          |               200 OK (of COMET)  ***                                 ***   |
        |<----------------------------------------------|
          |  ***                                       |
          |                  SIP-Proxy(s)         User Alerted  ***                                       |
          |-------------(5) UPDATE SDP3--------------->|
          |                                            |
          |<--------(6) 200 OK (UPDATE) SDP4-----------|
          |                                            |
          |<-------------(7) 180 Ringing Ringing---------------|
          |       180 Ringing                                            |
        |<----------------------|<----------------------|
          |-----------------(8) PRACK----------------->|
          |                                            |
          |<------------(9) 200 OK (PRACK)-------------|
          |                                            |
          |                       PRACK                                            |
        |---------------------------------------------->|
          |                                            |
          |<-----------(10) 200 OK (of PRACK) (INVITE)------------|
          |                                            |
        |<----------------------------------------------|
          |------------------(11) ACK----------------->|
          |                                            |
          |                                       User Picks-Up                                            |                  SIP-Proxy(s)

   Figure 2: Example using the phone end-to-end status type
   IP address where it is receiving media. Figure 3 shows this scenario.

          A                                            B

          |                                            |
          |-------------(1) INVITE SDP1--------------->|
          |                                            |
          |<------(2) 183 Session Progress SDP 2-------|
          |  ***                                 ***   |
          |--*R*-----------(3) PRACK-------------*R*-->|
          |  *E*                                 *E*   |
          |<-*S*-------(4) 200 OK (PRACK)--------*S*---|
          |  *E*                                 *E*   |
          |  *R*                                 *R*   |
          |  *V*                                 *V*   |
          |  *A*                                 *A*   |
          |  *T*                                 *T*   |
          |  *I*                                 *I*   |
          |  *O*                                 *O*   |
          |  *N*                                 *N*   |
          |  ***                                 ***   |
          |  ***                                       |
          |  ***                                       |
          |-------------(5) UPDATE SDP3--------------->|
          |                                            |
          |<--------(6) 200 OK (UPDATE) SDP4-----------|
          |
        |<----------------------|<----------------------|                                            |
          |<-----------(7) 200 OK (INVITE)-------------|
          |                                            |
          |------------------(8) ACK------------------>|
          |                                            |
          |                       ACK                                            |
        |---------------------------------------------->|

   Figure 1: Basic Call Flow

   The UAS successfully performs its resource reservation, 3: Session modification with preconditions

   SDP1: A includes an offer in its
   "send" direction, and waits for the COMET message from the UAC.

   On receipt of the COMET message, a re-INVITE (1). A continues to receive
   media on the UAS processes old IP address (192.0.2.1), but it is ready to receive
   media on the "send"
   confirmation contained new one as well (192.0.2.2):

          m=audio 20000 RTP/AVP 0
          c=IN IP4 192.0.2.2
          a=curr:qos e2e none
          a=des:qos mandatory e2e sendrecv

   SDP2: B includes a "confirm" tag in the COMET SDP.  The "send" confirmation
   from the UAC coupled with its own "send" success, allows answer. B continues sending
   media to the UAS old remote IP address (192.0.2.1)

          m=audio 30000 RTP/AVP 0
          c=IN IP4 192.0.2.4
          a=curr:qos e2e none
          a=des:qos mandatory e2e sendrecv confirm

   SDP3: When A receives RESV messages it sends an updated offer (5) to
   determine
   B:

          m=audio 20000 RTP/AVP 0
          c=IN IP4 192.0.2.2
          a=curr:qos e2e send
          a=des:qos mandatory e2e sendrecv

   SDP4: B responds with an answer (6) indicating that all the preconditions
   have been met. met (current status "sendrecv). It is now when B begins
   sending media to the new remote IP address (192.0.2.2).

          m=audio 30000 RTP/AVP 0
          c=IN IP4 192.0.2.4
          a=curr:qos e2e sendrecv
          a=des:qos mandatory e2e sendrecv

10.2 Segmented Status Type

   The UAS then
   continues with call flow of figure 4 shows a basic session establishment.  At this point it alerts establishment using
   the

      SIP Working Group       Expiration 5/31/02                      21
                SIP Extensions for Resource Management   November 2001

   user, segmented status type. The SDP descriptions of this example are
   shown below:

   SDP1: B includes local and sends a 180-Ringing provisional response. remote QoS preconditions in the initial
   offer. Before sending the initial offer, A reserves resources in its
   access network. This
   provisional response is also sent using the reliability mechanism of
   [11], resulting indicated in a PRACK message and 200-OK of the PRACK.

   When local current status of the destination party answers,
   SDP below:

          m=audio 20000 RTP/AVP 0 8
          c=IN IP4 192.0.2.1
          a=curr:qos local sendrecv
          a=curr:qos remote none
          a=des:qos mandatory local sendrecv
          a=des:qos mandatory remote sendrecv

   SDP2: B reserves resources in its access network and, since all the normal SIP 200-OK final
   preconditions are met, returns an answer in a 180 (Ringing) response
   (3).

          m=audio 30000 RTP/AVP 0 8
          c=IN IP4 192.0.2.4
          a=curr:qos local sendrecv
          a=curr:qos remote sendrecv
          a=des:qos mandatory local sendrecv
          a=des:qos mandatory remote sendrecv

   Let's assume that after receiving this response is sent through the proxies A decides that it
   wants to the originator, use only PCM u-law (payload 0), as opposed to both PCM u-law
   and the
   originator responds with an ACK message.

   Either party can terminate the call.  An endpoint that detects A-law (payload 8). It would send an
   "on-hook" (request UPDATE to terminate the call) releases B possibly before
   receiving the QoS resources
   held 200 OK for the connection, and sends a SIP BYE message to the INVITE (5). The SDP would look like:

          m=audio 20000 RTP/AVP 0
          c=IN IP4 192.0.2.1
          a=curr:qos local sendrecv
          a=curr:qos remote
   endpoint, which is acknowledged with a 200-OK.

12.2 Multiple Media Call Flow

   Figure 2 presents a high-level overview of an advanced end-point to
   end-point (UAC-UAS) call flow.  This example is appropriate for a
   multiple-media session with some combination of sendrecv
          a=des:qos mandatory and
   optional quality-of-service precondition.  For example, the
   originator may suggest five media streams, and be willing to
   establish the session if any three of them are satisfied.

   The use of reliable provisional responses is assumed, but not shown
   in this figure.

   The session originator (UAC) prepares local sendrecv
          a=des:qos mandatory remote sendrecv

   B would generate an SDP message body answer for the
   INVITE describing the desired QoS and security preconditions for
   each media flow, and the desired directions. UAC also requests
   confirmation of the preconditions.  The UAS receiving the INVITE
   message responds with 183-Session-Progress, as in the previous
   example.

   When the UAS has completed the resource reservations this offer and security
   session establishment, place it sends a confirmation to the UAC in the
   form of a COMET message, with each precondition marked in 200 OK
   for the SDP as
   either success or failure. UPDATE.

   Note that if UAS was not satisfied with this last offer/answer to reduce the combination number of successful preconditions, it could instead have
   responded with 580-Precondition-Failure, and ended supported
   codecs may arrive to the INVITE
   transaction.

   If user agent server after the UAC 200 OK response
   has satisfied its preconditions, and is satisfied with
   the preconditions achieved by the UAS, it responds with the COMET
   message.  The COMET message contains the SDP with been generated. This would mean that the
   success/failure results of each precondition attempted by UAC.  If
   UAC session is not satisfied with established
   before A has reduced the combination number of successful
   preconditions, it supported codecs. To avoid this
   situation, the user agent client could instead have sent a CANCEL message.

   On receipt of wait for the COMET message, UAS examines first answer from
   the user agent before setting its local current status to "sendrecv".

11 Security Considerations

   An entity in the combination middle of
   satisfied preconditions reported by UAC, and makes two user agents establishing a final decision
   whether to proceed with session may
   add desired-status attributes making session establishment
   impossible. It could also modify the session.  If sufficient preconditions
   are not satisfied, content of the UAS responds with 580-Precondition-Failure.
   Otherwise, current-status
   parameters so that the session proceeds as in is established without meeting the previous example.

      SIP Working Group       Expiration 5/31/02                      22
                SIP Extensions for Resource Management   November 2001

   Originating (UAC)                            Terminating (UAS)
   preconditions. Integrity protection can be used to avoid this
   attacks.

          A                                            B

          |                  SIP-Proxy(s) ***                                        |
          |  INVITE *R*                                        |
          |
        |---------------------->|---------------------->| *E*                                        |
          | *S*                                        |
          |       183 w/SDP *E*                                        |       183 w/SDP
          |
        |<----------------------|<----------------------| *R*                                        |
          | *V*                                        | Reservation                       Reservation
          |
         ===========>                       <=========== *A*                                        |
          | *T*                                        |               COMET
          |
        |<----------------------------------------------| *I*                                        |               200 OK (of COMET)
          |
        |---------------------------------------------->| *O*                                        |
          | *N*                                        |               COMET
          |
        |---------------------------------------------->| ***                                        |               200 OK (of COMET)
          |-------------(1) INVITE SDP1--------------->|
          |
        |<----------------------------------------------|                                     ***    |
          |                                     *R*    |                  SIP-Proxy(s)         User Alerted
          |                                     *E*    |
          |                                     *S*    |       180 Ringing
          |       180 Ringing                                     *E*    |
        |<----------------------|<----------------------|
          |                                     *R*    |
          |                                     *V*    |
          |                                       User Picks-Up                                     *A*    |                  SIP-Proxy(s)         the phone
          |                                     *T*    |
          |                                     *I*    |       200 OK
          |                                     *O*    |
          |                                     *N*    |
          |                                     ***    |
          |<----------(2) 180 Ringing SDP2-------------|
          |                                            |
          |----------------(3) PRACK------------------>|
          |                                            |
          |<-----------(4) 200 OK (PRACK)--------------|
          |                                            |
        |<----------------------|<----------------------|
          |                                            |
          |<-----------(5) 200 OK (INVITE)-------------|
          |                                            |
          |------------------(6) ACK------------------>|
          |                                            |
          |                       ACK                                            |
        |---------------------------------------------->|

   Figure 2: Call Flow with negotiation of optional preconditions

13. Special considerations with Forking Proxies

   If a proxy along the signaling path between the UAC and UAS forks
   the INVITE request, it results in two or more UASs simultaneously
   sending provisional responses with preconditions.  The procedures
   above result in the UAC handling each independently, reserving
   resources and responding with COMET messages as required.

   This results in multiple resource reservations from the UAC, only
   one of which will be utilized for the final session.  While
   functionally correct, this has the unfortunate side-effect of
   increasing the call blocking probability.

      SIP Working Group       Expiration 5/31/02                      23
                SIP Extensions for Resource Management   November 2001

   Customized resource allocation protocols may be used by the UAC to
   reduce this duplicate allocation and prevent excess blocking of
   calls.  For one such example, see [8].

   Other procedures which the UAC has available to handle multiple
   simultaneously active transactions (e.g. CANCEL, and BYE) are as
   given in [2].

14. Advantages of the Proposed Approach

   The use of two-phase call signaling makes it possible for SIP to
   meet user expectations that come from the telephony services.

   The reservation of resources before the user is alerted makes sure
   that the network resources are assured before the destination end-
   point is informed about 4: Example using the call.

   The number segmented status type

   An entity performing resource reservations upon reception of messages and the total delay introduced by these
   messages is kept to
   unathenticated requests carrying preconditions can be an easy target
   for a minimum without sacrificing compatibility with
   SIP servers that do not implement preconditions.

15. Security Considerations

   If the contents denial of the service attack. Requests with preconditions SHOULD be

12 IANA considerations

   This document defines three media level SDP contained attributes: desired-
   status, current-status and conf-status. Their format is defined in the 183-Session-Progress are
   private then end-to-end encryption of the message body can be used
   to prevent unauthorized access
   Section 4.

   Section 4 also one standard precondition-type related to the content.

   The security considerations given
   attributes above: "qos". If in the SIP specification apply to
   the COMET method.  No additional security considerations specific future it was needed to
   the COMET method are necessary.

16. Notice Regarding Intellectual Property Rights

   The IETF has been notified of intellectual property rights claimed
   in regard
   standardize further precondition-types, they would need to some or all of the specification contained be defined
   in this a standards track document.  For more information consult the online list of claimed
   rights.

17. References

   1. Bradner, S., "The Internet Standards Process -- Revision 3", BCP
     9, RFC 2026, October 1996.

   2. M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP:
     Session Initiation Protocol," RFC 2543, March 1999.

   3. M. Handley and V. Jacobson, "SDP: Session Description Protocol,"
     RFC 2327, April 1998.

   4. Bradner, S., "Key words for use in RFCs to Indicate Requirement
     Levels", BCP 14, RFC 2119, March 1997

      SIP Working Group       Expiration 5/31/02                      24

   This document also defines a new SIP Extensions for Resource Management   November 2001

   5. R. Braden, Ed., L. Zhang, S. Berson, S. Herzog, and S. Jamin,
     "Resource ReSerVation protocol (RSVP) -- version 1 functional
     specification," RFC 2205, September, 1997.

   6. P. P. Pan and H. Schulzrinne, "YESSIR: A simple reservation
     mechanism for the Internet," status code (580). Its default
   reason phrase (Precondition Failure) is defined in Proc. International Workshop on
     Network and Operating System Support for Digital Audio and Video
     (NOSSDAV), (Cambridge, England), July 1998.  Also IBM Research
     Technical Report TC20967.  Available at
     http://www.cs.columbia.edu/~hgs/papers/Pan98_YESSIR.ps.gz.

   7. PacketCable, Dynamic Quality of Service Specification, pkt-sp-
     dqos-i01-991201, December 1, 1999.  Available at
     http://www.packetcable.com/specs/pkt-sp-dqos-i01-991202.pdf. section 8. S. Kent and R. Atkinson, "Security architecture for the internet
     protocol," RFC 2401, November 1998.

   9. H. Schulzrinne, S. Casner,

13 Contributors

   The following persons contributed to early versions of this spec:

   K. K. Ramakrishnan (TeraOptic Networks), Ed Miller (Terayon), Glenn
   Russell (CableLabs), Burcak Beser (Pacific Broadband Communications),
   Mike Mannette (3Com), Kurt Steinbrenner (3Com), Dave Oran (Cisco),
   Flemming Andreasen (Cisco), Michael Ramalho (Cisco), John Pickens
   (Com21), Poornima Lalwaney (Nokia), Jon Fellows (Copper Mountain
   Networks), Doc Evans (D. R. Frederick, and V. Jacobson, "RTP: a
     Transport Protocol for Real-Time Applications," RFC 1889, January
     1996.

   10.  M. Handley, C. Perkins, and E. Whelan, "Session Announcement
     Protocol," RFC2974, October, 2000.

   11.  "Reliability of Provisional Responses in SIP," RFC pending.

   12.  "The SIP Supported Header,"  RFC pending.

18. Evans Consulting), Keith Kelly
   (NetSpeak), Adam Roach (dynamicsoft), Dean Willis (dynamicsoft),
   Steve Donovan (dynamicsoft), Henning Schulzrinne (Columbia
   University).

14 Acknowledgments

   The Distributed Call Signaling work in the PacketCable project is the
   work of a large number of people, representing many different
   companies. The authors would like to recognize and thank the
   following for their assistance: John Wheeler, Motorola; David
   Boardman, Daniel Paul, Arris Interactive; Bill Blum, Jay Strater,
   Jeff Ollis, Clive Holborow, General Instruments; Doug Newlin, Guido
   Schuster, Ikhlaq Sidhu, 3Com; Jiri Matousek, Bay Networks; Farzi
   Khazai, Nortel; John Chapman, Bill Guckel, Cisco; Chuck Kalmanek,
   Doug Nortz, John Lawser, James Cheng, Tung-Hai Hsiao, Partho Mishra,
   AT&T; Telcordia Technologies; and Lucent Cable Communications.

19. Author's

15 Authors' Addresses

   Gonzalo Camarillo
   Ericsson
   Advanced Signalling Research Lab.
   FIN-02420 Jorvas
   Finland
   electronic mail:  Gonzalo.Camarillo@ericsson.com

   Bill Marshall
   AT&T
   Florham Park, NJ 07932
   Email:
   USA
   electronic mail:  wtm@research.att.com

   K. K. Ramakrishnan

      SIP Working Group       Expiration 5/31/02                      25
                SIP Extensions for Resource Management   November 2001

   TeraOptic Networks
   Sunnyvale, CA
   Email: kk@teraoptic.com

   Ed Miller
   Terayon
   Louisville, CO  80027
   Email: E.Miller@terayon.com

   Glenn Russell
   CableLabs
   Louisville, CO  80027
   Email: G.Russell@Cablelabs.com

   Burcak Beser
   Pacific Broadband Communications
   San Jose, CA
   Email: Burcak@pacband.com

   Mike Mannette
   3Com
   Rolling Meadows, IL  60008
   Email: Michael_Mannette@3com.com

   Kurt Steinbrenner
   3Com
   Rolling Meadows, IL  60008
   Email: Kurt_Steinbrenner@3com.com

   Dave Oran
   Cisco
   Acton, MA  01720
   Email: oran@cisco.com

   Flemming Andreasen
   Cisco
   Edison, NJ
   Email: fandreas@cisco.com

   Michael Ramalho
   Cisco
   Wall Township, NJ
   Email: mramalho@cisco.com

   John Pickens
   Com21
   San Jose, CA
   Email: jpickens@com21.com

   Poornima Lalwaney
   Nokia
   San Diego, CA  92121
   Email: poornima.lalwaney@nokia.com

      SIP Working Group       Expiration 5/31/02                      26
                SIP Extensions for Resource Management   November 2001

   Jon Fellows
   Copper Mountain Networks
   San Diego, CA  92121
   Email: jfellows@coppermountain.com

   Doc Evans
   D. R. Evans Consulting
   Boulder, CO  80303
   Email: n7dr@arrl.net

   Keith Kelly
   NetSpeak
   Boca Raton, FL  33587
   Email: keith@netspeak.com

   Adam Roach
   Ericsson
   Richardson, TX  75081
   Email: adam.roach@ericsson.com

   Jonathan Rosenberg
   dynamicsoft
   West Orange, NJ 07052
   Email:
   USA
   electronic mail:  jdrosen@dynamicsoft.com

   Dean Willis
   dynamicsoft
   West Orange, NJ  07052
   Email: dwillis@dynamicsoft.com

   Steve Donovan
   dynamicsoft
   West Orange, NJ  07052
   Email: sdonovan@dynamicsoft.com

   Henning Schulzrinne
   Columbia University
   New York, NY
   Email: schulzrinne@cs.columbia.edu

      SIP Working Group       Expiration 5/31/02                      27
                SIP Extensions

16 Bibliography

   [1] J. Rosenberg, H. Schulzrinne, et al.  , "SIP: Session initiation
   protocol," Internet Draft, Internet Engineering Task Force, Feb.
   2002.  Work in progress.

   [2] M. Handley and V. Jacobson, "SDP: session description protocol,"
   Request for Resource Management   November 2001 Comments 2327, Internet Engineering Task Force, Apr.
   1998.

   [3] S. Bradner, "Key words for use in RFCs to indicate requirement
   levels," Request for Comments 2119, Internet Engineering Task Force,
   Mar. 1997.

   [4] J. Rosenberg and H. Schulzrinne, "An offer/answer model with
   SDP," Internet Draft, Internet Engineering Task Force, Jan. 2002.
   Work in progress.

   [5] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: a
   transport protocol for real-time applications," Request for Comments
   1889, Internet Engineering Task Force, Jan. 1996.

   [6] J. Rosenberg and H. Schulzrinne, "Reliability of provisional
   responses in SIP," Internet Draft, Internet Engineering Task Force,
   Sept. 2001.  Work in progress.

   Full Copyright Statement

   "Copyright (C)

   Copyright (c) The Internet Society (2000). (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."

   Expiration Date This memo is filed as <draft-ietf-sip-manyfolks-
   resource-03.txt>, and expires May 31, 2002.

      SIP Working Group       Expiration 5/31/02                      28 PURPOSE.

   Notice Regarding Intellectual Property Rights

   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.