Internet Engineering Task Force SIP
Working Group W. MarshallWG Internet Draft AT&T Document: <draft-ietf-sip-manyfolks-resource-03> K. Ramakrishnan TeraOptic Networks E. Miller TerayonG. 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. RoachCamarillo (Editor) Ericsson J.W. Marshall (Editor) AT&T Jonathan Rosenberg D. Willis S. Donovandynamicsoft H. Schulzrinne Columbia University November, 2001draft-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 MemoSTATUS OF THIS MEMO This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026.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- DraftsInternet-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 TheTo view the list ofInternet-Draft Shadow Directories can be accessed atDirectories, 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 establishmentquality 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 QoSquality of service reservation or securitymechanisms; these pre- conditionspreconditions simply require a participant to use existing resource reservation and securitymechanisms before beginning the session. This results in a multi-phase call-setup mechanism, with1 Introduction Some architectures require that at session establishment time, once the resource management protocol interleaved between two phasescallee has been alerted, the chances of call signaling. The objectivea session establishment failure are minimum. One source of suchfailure is the inability to reserve network resources for a mechanismsession. In order to minimize "ghost rings", it is necessary to enable deployment of robust IP Telephony services, by ensuring thatreserve network resources are made availablefor the session before the phone ringscallee is alerted. However, the reservation of network resources frequently requires learning the IP address, port, and session parameters from the participantscallee. 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 toexchange normally causes the Session Initiation Protocol (SIP)"phone to addring", thus introducing a new COMET method, whichchicken-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 usedto confirmintroduce the completionconcept of all pre-conditions bya precondition. A precondition is a set of constraints about the session originator. 2. Conventions usedwhich are introduced in this document SIP Working Group Expiration 5/31/02 2 SIP Extensions for Resource Management November 2001the 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. 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. Advantagesrecipient 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 mustoffer 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 meetgenerates 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 thatotherwise proceed with session establishment. That only occurs when the connectionpreconditions are met. This can be made. Blockingknown through a call after ringing the destination is consideredlocal event (such as a "call defect" and isconfirmation of a very undesirable exception condition. This draft addresses both "QoS-Assured" and "QoS-Enabled" sessions. A "QoS-Assured" session will complete only if allresource reservation), or through a new offer sent by the required resources are availablecaller. This document deals with sessions that use SIP  as signalling protocol and assignedSDP  to describe the parameters of the session. A provider may chooseWe have chosen to block a call when adequate resources for the call are not available. Public policy demands thatinclude the phone system provide adequatequality at least in certain cases: e.g., for emergency communications during timesof disasters. Call blocking enables a provider to meet such requirements. A "QoS-Enabled" session allowsservice preconditions in the endpoints to completeSDP 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 Overview In cases where resources are not available, the originating and/or terminating User Agent might consult with the customerorder to obtain guidance on whether theensure that session should complete. Coordinationestablishment does not take place until certain preconditions are met we distinguish between call signaling and resource management is also needed to prevent fraudtwo different state variables that affect a particular media stream: current status and theftdesired 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 todesired status consists of a threshold for the enhanced QoS associated withcurrent status. Session establishment stops until the telephony service. This coordination, referred to incurrent status reaches or surpasses this draft as "preconditions," require that the participant reserve network resources (or establish a secure media channel) before continuing withthreshold. Once this threshold is reached or surpassed, session establishment resumes. For example, the session. We dofollowing values for current and desired status would not define new QoS reservation or security mechanisms; these pre- conditions simply require a participantallow session establishment to use existing resource reservation and security mechanisms before beginningresume: current status = resources reserved in the session. Insend direction desired status = resources reserved in both (sendrecv) directions On the caseother hand, the values of SIP , this effectively means thatthe "phone won't ring" untilexample 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  or any other end-to-end reservation mechanism (suchtwo state variables define a certain piece of state of a media stream the same way as YESSIR , SIP Working Group Expiration 5/31/02 4 SIP Extensions for Resource Management November 2001the direction attribute or PacketCable's Dynamic Quality of Service (D-QoS) ), and security based on IPSEC . The preconditions can be defined independently for each media stream. The QoS architecturethe 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 (suchsame way as web proxies and SIP servers)other SDP media attributes are not well suited for participationtreated 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 likethe offer/answer model used by SIP servers: they are almost never on the "bearer path" (i.e., the network path the RTP  takes), and since the RTP pathexchanged 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 capablean answer in order to have a shared view of managing QoS forthe media. Keeping QoS out of application signaling also means that there can be a single infrastructure for QoS across all applications. This eliminates duplicationstatus 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 forthe session. Figure 1 shows a wide rangetypical 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. Inthe caseSDP of Internet telephony,the following is an important requirement: Wheninitial INVITE. A calls B, B's phone shoulddoes not ring unless resources have been reserved from A to B, andwant B to A. This couldbe achieved without coupling if A knew B's address, port, and codecs before the telephony signaling took place. However, since telephony signalingalerted until there is used largelynetwork resources reserved in both directions (sendrecv) end-to-end. B agrees to obtainreserve network resources for this information insession 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 neededto handle the A->B direction. To indicate thatso, B returns a security association is needed for the application183 response to execute. To solve both of these problems, we propose an extensionA 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-endstart resource reservation,reservation and (2) success of end- to-end security establishment. We choseto implement these extensions in SDP, rather than SIP  or SAP , since they are fundamentally a media session issue. SIP is session agnostic; information about codecs, ports, and RTP  are outside the scope of SIP. Since it is the media sessions thatwarn B as soon as the reservations and security refer to, SDPA->B direction is the appropriate venue for the extensions. SIP Working Group Expiration 5/31/02 5 SIP Extensionsready for Resource Management November 2001 Furthermore, placement ofthe extensionssession. 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 forthe audio,B->A direction, but does not alert the video (which is less important). Our extensionsuser 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 motivationneeded. When A finishes reserving resources in this work is to meet and possibly exceedthe user expectations and human factors associated with telephony. In this section, we briefly describeA->B direction, it sends an UPDATE to B. B returns a 200 (OK) response for the application requirementsUPDATE indicating that led toall the set of DCS signaling design principles. In its basic implementation, DCS supports a residential telephone service comparable topreconditions for the local telephone services offered today. Somesession 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 provideruser, and session establishment completes normally. 4 SDP parameters We define the endpoints to attempt to use lower bandwidth codecs asfollowing 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 linecurrent status of defense against limitednetwork capacity, and to avoid blocking calls.resources for a particular media stream. Desired status: The system must minimizedesired status attribute carries the post-dial-delay, which ispreconditions for a particular media stream. When the time betweencurrent status value has the user dialingsame or a better value than the last digit and receiving positive confirmation fromdesired status value, the network. This delay mustpreconditions are considered to be short enough that users do not perceivemet. Confirmation status: The desired status attribute carries threshold conditions for a difference with post-dial delay inmedia stream. When the circuit switchedstatus 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 thatnot the callee can be alerted in case the network connectivity no longer exists. Call signaling needs to provide enough informationfails to meet the resource management protocol so as to enable resources to be allocated inpreconditions. 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 allstatus of the componentsend-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 orsegmented status reflects the performancestatus 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 thatthe access network cannot guaranteereservations of both user agents. The end-to-end QoS resources, there are two alternatives: either (1) allow call signalingstatus corresponds to proceed with high probability of excessive delay and packet loss which could impair any interactive real-time communication betweenthe participants, or (2) blocktag "e2e" defined above and the call priorsegmented status to the called party being alerted. When calls are blocked because oftags "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 lackconcrete attribute is applicable to. The values of resources in a particular segmentthe tags "send", "recv", "local" and "remote" represent the point of view of the network, itentity generating the SDP description. In an offer, "send" is highly desirable that such blocking occur beforethe called party picks up. We do expectdirection offerer->answerer and "local" is the endpoints to attempt to use lower bandwidth codecs, thereby avoiding blocking calls, asofferer's access network. In an answer, "send" is the first line of defense against limited network capacity. The call signalingdirection answerer->offerer and resource reservation must be achieved"local" is the answerer's access network. The following example shows these new SDP attributes in suchtwo media lines of a way thatsession 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 increasingnew SDP status parameters in the probability of call defects. This means thatSIP 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 . The generalidea behind the extension is simple. We define two new SDP attributes, "qos" and "security". The "qos" attribute indicates whether end-to-end resource reservationthis model is optional or mandatory, and in which direction (send, recv, or sendrecv). Whento provide a shared view of the attribute indicates mandatory, this means thatsession parameters for both user agents once the participant whoanswer has been received by the offerer. This section describes which values can our new SDP does not proceed with participationattributes take in the session until resource reservation has completedan answer depending on their value in the direction indicated. In this case, "not proceeding" meansoffer. 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 receivedanswerer in the SDP at all. Ifoffer. The anwerer uses the attribute indicatesinformation of this transaction status table to update its local status table. The answerer also updates the transaction status table fields that QoS forwere out of date and returns this table to the stream is optional, thenofferer in the participant proceeds normallyanswer. The offerer can then update its local status table with the session, but should reserve network resourcesinformation received in the direction indicated, if they are capable. Absence of the "qos" attribute meansanswer. 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. Iflocal status tables of both user agents are synchronised. They now have a common view of the ISP'sstatus of the various participants are using differing resource reservation protocols, translation is necessary, butmedia stream. Sessions that involve several media streams implement these tables per media stream. Note, however, that this is done within the network, without knowledgea 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 directionuser agent behavior, not of media flow from the session originatorsoftware. An implementation is free to participants. If "recv", it means reservations should be made intake any approach that replicates the direction of media flow from participantsexternal 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 casestatus of "sendrecv", it means reservations should be made in both directions. Ifthe direction attribute is "sendrecv" but the endpoints only support a single-directionresource reservation protocol, thenreservation. Tables 1 and 2 show the format of this tables for both the originatorend-to-end and participants cooperate to ensurethe agreed precondition is met. SIP Working Group Expiration 5/31/02 7 SIP Extensions for Resource Management November 2001 Insegmented 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 torecv). A value of "yes" in the one above, except"Current" field indicates that a security association should be establishedresource has been successfully reserved in the givencorresponding direction. The details of the security association are"No" indicates that resources have not signaled by SDP; these depend onbeen reserved yet. The "Desired Strength" field indicates the Security Policy Databasestrength of the participant. Either party can include a "confirm" attributepreconditions in the SDP. When the "Confirm" attribute is present, the recipient sends a COMET message to the sender, with SDP attached, tellingcorresponding direction. The table for the segmented status of each precondition as "success" or "failure." Iftype contains four rows: both directions in the "confirm" attribute is presentlocal access network and in the SDP sent bypeer's access network. The meaning of the session originator tofields is the participant (e.g.same as in the SIP INVITE message), thenend-to-end case. Before generating an offer, the participant sendsofferer MUST build a transaction status table with the COMET message tocurrent and the originator. Ifdesired status for each media stream. The different values of the "confirm"strength tag for the desired status attribute is present inhave the SDP sent byfollowing semantics: o None: no resource reservation is needed. o Optional: the recipientuser agents SHOULD try to provide resource reservation, but the originator (e.g. in a SIP response message), then the originator sendssession can continue regardless of whether this provision is possible or not. o Mandatory: the COMET messageuser agents MUST provide resource reservation. Otherwise, session establishment MUST NOT continue. The offerer then decides whether it is going to use the participant. Whenend-to-end status type or the "Confirm" attribute is present in bothsegmented status type. If the SDP sent bystatus type of the session originator tomedia line will be end-to-end, the participant (e.g. inuser agent generates records with the SIP INVITE message),desired status and in the SDP sent by the recipient back tothe originator (e.g.current status for each direction (send and recv) independently, as shown in a SIP response message), the session originator would waittable 1: Direction Current Desired Strength ____________________________________ send no mandatory recv no mandatory Table 1: Table for the COMET message withend-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 combinationstatus type of optional preconditions are not met. The recipient does not wait forthe COMET message frommedia line will be segmented, the originator before sending its COMET message. The "confirm" attribute is typically used ifuser 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 resourcescurrent status for oneeach 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 resourcesno 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, andsegmented status type At the precondition is met. 5. SDP Extension The formattingtime of sending the qos attribute in the Session Description Protocol (SDP) is described byoffer, 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 22.214.171.124 s=SDP Seminar c=IN IP4 126.96.36.199/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 intransaction status table contain the session until resources forsame values. With the audio are reserved from B to A, and a bi-directional security association is established fortransaction status table, the video. B can joinuser agent generates the sessions once these preconditions are met, but should reserve resourcescurrent-status and establish a bi-directional security association forthe whiteboard. 5.2 SDP Allowable Combinations Ifdesired status lines following the recipientsyntax 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 honorend-to-end status type, the precondition(s), it returns a provisional response containing SDP, alonguser 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 inthe INVITE. Table 1 illustratesmedia stream. If the allowed valuesstrength tags for the direction tagboth directions are equal (e.g., both mandatory) in the response. Each row represents a value oftransaction status table, the direction inuser 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 columnthe value inother with the response. An entry of N/A means that this combination is not allowed. A valuetag "recv". The semantics of A->B (B->A) implies thattwo lines with the preconditionsame strength tag, one with a "send" tag and the other with a "recv" tag, is for resources reserved (or security established) from Athe same as one "sendrecv" line. However, in order to B (Bachieve a more compact encoding, we have chosen to A). A value of A<->B means thatmake mandatory the precondition is for resource reservation or security establishment in both directions. The value inlatter format. For the response issegmented 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 forwith the strengthtag in the request"local" and response. A "Y" meansthe 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 valueparticular segment (local or remote) the tags for both directions in the response istransaction status table are equal (e.g., both mandatory), the user agent MUST add one used bydesired 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 illustratestags are different, the allowed values foruser agent MUST include two desired status lines, one with the directiontag in a confirmation message (COMET) sent from the originator to a participant, based on"send" and the value ofother with the directiontag negotiated in"recv". Note that the initial request and response. A "Y" meansrules above apply to the combination is allowed, anddesired 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 valuesuser agent that supports quality of direction in confirmation from A Table 4 illustrates the allowed values forservice but does not intend to use them, adds desired status lines with the directionstrength tag "none". Since this tag can be upgraded in a confirmation message (COMET) sent from the participant tothe originator, based on the value of the direction tag negotiatedanswer, as described in Section 5.2, the initialanswerer can request and response. A "Y" meansquality 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" means2. 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 byrecreates 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 directiontransaction 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 betweenthe user agents.offer. The signaling path for the COMET method isanswerer updates both its local status and the signaling path established as a result oftransaction status table following the call setup. This can be either direct signaling betweenrules below: Desired Strength: We define an absolute ordering for the callingstrength tags: none, optional and called user agents or a signaling path involving SIP proxy servers that were involved inmandatory. Mandatory is the call setuptag with highest grade and added themselves tonone the Record-Route header ontag with lowest grade. An answerer MAY upgrade the initial INVITE message. The precondition information is communicateddesired strength in any entry of the message body, whichtransaction 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". Iffrom 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 copyvalue of those headers, as ifthe response were a 200 OK to"Current" field in the initial request. Since provisional responses MAY contain Record-Routetransaction status table and Contact headers, the COMET request MUST contain Route headers, constructed as specifiedin , ifthe Record-Route headers were present inlocal 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 inanswerer 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 thatsame value (two first rows of the provisional response. The CSeq in this request MUSTtable 3, nothing needs to be larger thanupdated. 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 . In particular, ifthe provisional response contained a tag infield of the To field, this taglocal status table is "No" (third row of table 3), the latter MUST be mirrored inset to "Yes". If the To"Current" field of the COMET. Once the COMET request is created, ittransaction 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 requestlocal status table is retransmitted as specified in . 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 continuesanswerer needs to retransmit the COMET request untilcheck if it receiveshas local information (e.g., a final response. Use of CANCELconfirmation of a COMET is as specified in . 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 extensionsresource reservation has been received) about that particular current status. If it does, the "Current" field of tables 4 and 5 inthe SIP specification. Refertransaction status table is set to Section 6 of  for a description of"Yes". If the content ofanswerer 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 responselocal status table MUST be sent by a UASset to "No". Transaction status table Local status table ____________________________________________ no no yes yes yes no no yes Table 3: Possible values for a COMET request ifthe 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 MUSTanswer 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 ifinverted 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 oanswer, as shown in table 4. Offer Answer ______________ send recv recv send local remote remote local Table 6 Summary4: Values of header fields, P-Z Other request failure (4xx), Server Failure (5xx)tags in offer and Global Failure (6xx) responses MAY be sent foranswers At the COMET Request. 6.3 Message Body Inclusion The COMET request MUSTtime 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 forsame values. Therefore, this answer contains the COMET request governingshared view of the usagestatus of tags, Route and Record-Route, retransmissionthe media line in the current-status attribute and reliability, CSeq incrementingthe negotiated strength and message formatting follow thosedirection tags in  as defined forthe BYE request. A COMET request MAY be cancelled. A UAS receiving a CANCEL for a COMET request SHOULD respond todesired-status attribute. If the COMET with a "487 Request Cancelled" response if a final response has not beenresource reservation mechanism used requires participation of both user agents, the answerer SHOULD start resource reservation after having sent tothe COMETanswer and then behavethe offerer SHOULD start resource reservation as soon as ifthe request were neveranswer is received. 6.5 BehaviorIf participation of SIP Proxythe 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 foranswerer MAY start it before sending the COMET request atanswer. The status of the resource reservation of a proxy are identicalmedia 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 . 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 forduration of the COMET request at a proxy are identical to those for a BYE request as specified in . 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 foruser until all the COMET request at a proxymandatory preconditions are identical to those for a BYEmet; session establishment is suspended until that moment. A user agent server may receive an INVITE request as specifiedwith no offer in . 7. SIP Extension: The 183-Session-Progress Response An additional provisional response is defined byit. In this draft, which is returned by a UAS to convey information not otherwise classified. 7.1 Status Code and Reason Phrase Thecase, following is to be added to Figure 4normal 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 toa 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 aboutuser agent client will send the call progress. The Session Progress response MAY contain a message body.answer in another SIP request. If so, it MUSTthe offer and the answer contain a "Content-Disposition" header indicatingpreconditions, the proper treatment ofuser 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 performuser until all the mandatory preconditions forin the session. 8.1 Status Code and Reason Phrase The followinganswer 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 Extensionssuspended, user agents SHOULD not send any data over any media stream. In the case of RTP , 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 toa new section 7.5.7. 7.5.7 580 Precondition Failure The server was unable to establishmedia line when its local status table has a value of "yes" in all the qos or security association mandated byrows whose strength tag is "mandatory". When the SDP precondition. The Precondition Failure response MUST contain a message body, with Content-Type "application/sdp", givingpreconditions of all the specificsmedia lines of the precondition that couldsession 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 indicatingHowever, 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, Summarythe 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 byan ongoing session need further explanation. Both user agents SHOULD continue using the UAC or UAS. The value "precondition" indicatesold session parameters until all the body part describes QoS and/or securitymandatory preconditions are met. At that SHOULD be established prior tomoment, the start ofuser 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 receivesqos-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 hasthreshold for the value "optional"resource reservation. When this threshold is reached or surpassed, the UASuser agent MUST ignoresend an offer to the message body; if it haspeer user agent reflecting the value "required"new current status of the UAS MUST return 415 (Unsupported Media Type).media line. If the handling parameterthis 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 tagnetwork stops providing resources for Requires and Supported headers This draft definesthe option tag "precondition" for use inmedia stream), the Require and Supported headers . A UAS that supports this extensionuser agent MUST respond to an OPTION request withsend a Supported headernew 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 includestream with a "Require: precondition"flag in an INVITE request if it wants the session initiation to fail ifits local status table. When all the UAS does not supportrows with this feature. A UAC that would respond toflag have a failed session (if due to lackvalue of precondition support) by immediately retrying"yes", the session withoutuser agent MUST send a new offer to the preconditions, SHOULD NOT include this Require tag value. Presence ofpeer. This offer will contain the precondition entriescurrent status of resource reservation in the SDP message body of an INVITE request or response indicates supportqos-current-status attributes. If later any of the rows with this feature. The UAC or UAS MAY in addition includeflag transition to "No", a "Supported: precondition" header in the request or response. 11. SIP Usage Rules 11.1 Overviewnew 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, andanswerer uses the desired directions. The tokenvalue "send" means the directionof media from originator (whichever entity created the SDP) to recipient (whichever entity receivedthe SDPqos-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 isofferer uses the recipient. The roles are reversedvalue of this attribute in the response. A User Agent withanswer. For example, if a user agent receives an active session that desires to changeSDP description with the media flows preparesfollowing 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 foroffer as soon as it reserves resources in its access network ("remote" tag in the re-INVITE describingreceived 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 securitypreconditions forin the revised media flows andoffer 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, andstatus triggered the subsequent message exchanges, are identical to those of an initial INVITE.failure. The recipientcorresponding desired status line MUST a value of the INVITE (UAS) returns a 18x provisional response containing a Content-Dispositionstrength tag of "precondition," and SDP with"failure", as shown in the qos/security attribute for each stream having a precondition. The preconditions in thisexample 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 indicatedformat for describing media capabilities defined in the INVITE. The UAS would typically include a confirmation request in this SDP. Unlike normalSIP processing, the UAS MUST NOT alertoffer/answer model . Using the called user at this point. The UAS now attempts580 (Precondition Failure) status code to reserve the qos resources and establish the security associations. The 18x provisional responserefuse an offer is received by the UAC. If the 18x contained SDP with mandatory qos/security parameters,useful when the UACoffer 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 attemptsprovide 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 requestsa confirmation,UAC generates an initial INVITE without an offer and receives an offer in a COMET message1xx or 2xx response which is sentnot acceptable, it SHOULD respond to this offer with a correctly formed answer and immediately after that party. The COMET message containssend a CANCEL or a BYE. If the success/failure indication for each precondition. Foroffer comes in a precondition with1xx or 2xx response to a direction valuere-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," applies here: "The UAS MUST ensure that the COMET indicates whethersession description overlaps with its previous session description in media formats, transports, other parameters that require support from the senderpeer. This is ableto confirm both directions or only one direction. Upon receipt ofavoid the COMET message,need for the UAC/UAS continues normal SIP call handling. For a UAS this includes alertingpeer 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 . Thissession description. If, however, it is because the 18x contains SDPunacceptable to A, A SHOULD generate an answer with information required for thea valid session originatordescription, and then send a BYE to initiate reservations towardsterminate the participant. 11.2 Behavior of Originator (UAC) The session originator (UAC) MAY include QoSsession." 9 Option tag for Require and security preconditions (includingSupported header fields We define the desired direction)option tag "precondition" for each media flowuse in the SDP sentRequire and Supported header fields. An offerer MUST include this tag if the offer contains one or more strength tags with the INVITE. The tokenvalue "send" means the direction of media from originator (whichever entity created the SDP) to recipient (whichever entity received"mandatory". If all the SDPstrength tags in a SIP message). The token value "recv" meansthe direction of media from recipient to originator. If preconditionsdescription are included in the INVITE request,"optional" or "none" the UACofferer MUST indicate support for reliable provisional responses . If the UAC receives a 18x provisional response withoutinclude this tag either in a Content- Disposition of "precondition," or without SDP,Supported header field or with SDP but without any qos/security preconditionsin any stream, UAC treats it as an indicationa Require header field. It is, however, RECOMMENDED, that the UASSupported header field is unable or unwilling to perform theused in this case. The lack of preconditions requested. As such,in the UAC SHOULD proceed with normal call setup procedures. Ifanswer would indicate that the 18x provisional response contained a Content-Dispositionanswerer 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. Ifanswers to SIP requests and responses is performed following the 18x provisional response withrules given in . Therefore, a user agent including preconditions requested an acknowledgement (using the methods of ),in the UACSDP MUST include an updated SDPboth "100rel"  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 valuesegmented. 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 updatedend-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 receiptdescriptions of the 18x provisional response with preconditions, the UAC MUST initiate the qos reservations and establish the security associations to the bestthis example are shown below: SDP1: B includes end-to-end quality of its capabilities. If the UAC had requested confirmationservice 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 messagecan know when resources in its "send" direction are available, because it will receive RESV messages from the UAS containingnetwork. However, it does not know the success/failurestatus 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, ifthe COMET message indicated successreservations in the "send" direction, and the UAC was also able to meet the preconditionother direction. B requests confirmation for resource reservations in the "send" direction, they combineits "recv" direction to meetthe preconditionpeer 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 ofanswer 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 terminatereservation. However, B waits until resources in the session. Ifother direction as reserved as well since it did not receive any ofconfirmation and the optionalpreconditions cannot be met, the UAC MAY consultstill 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 completecurrent status of the session. When allresource 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 eithermedia stream has been met or have failed,already established, and the SDPA has received from the UAS includeda confirmation request,180 (Ringing) response. Since the UAC MUST send a COMET message todirection of the UAS with SDP. Each preconditionstream 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 ongenerate local operations performed combined withringback, it can put the received COMET message, if any. The session now completes normally, as per . Any SDP included in subsequent requestsmedia stream on hold in SDP4. In this transaction MUST NOT changecase, B would put the agreedmedia definitions (e.g. all linesstream off hold by sending an offer in the SDP description other than200 OK for the precondition lines). 11.3 Behavior of Destination (UAS) On receipt of anINVITE 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, 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 . 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 . 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 SDPmessages for this alternative flow is includedshown 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:mandatory200 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 establisha=des:qos mandatory e2e sendrecv SDP6 in the security associations. The 183-Session-Progress provisional response is sent usingACK (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 mechanismmiddle of . UAC sendsthe appropriate PRACK and UAS responds with a 200-OKsession 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 RingingRinging---------------| | 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 phoneend-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 processesold IP address (192.0.2.1), but it is ready to receive media on the "send" confirmation containednew 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 withits own "send" success, allowsanswer. B continues sending media to the UASold 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 determineB: 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 allthe 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 withcall flow of figure 4 shows a basic session establishment. At this point it alertsestablishment 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 responseis also sent using the reliability mechanism of , resultingindicated in a PRACK message and 200-OK ofthe PRACK. Whenlocal 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 finalpreconditions 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 proxiesA 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 detectsA-law (payload 8). It would send an "on-hook" (requestUPDATE to terminate the call) releasesB possibly before receiving the QoS resources held200 OK for the connection, and sends a SIP BYE message to theINVITE (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 ofsendrecv 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) prepareslocal sendrecv a=des:qos mandatory remote sendrecv B would generate an SDP message bodyanswer 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 reservationsthis offer and security session establishment,place it sends a confirmation to the UACin the form of a COMET message, with each precondition marked in200 OK for the SDP as either success or failure.UPDATE. Note that if UAS was not satisfied withthis last offer/answer to reduce the combinationnumber of successful preconditions, it could instead have responded with 580-Precondition-Failure, and endedsupported codecs may arrive to the INVITE transaction. Ifuser agent server after the UAC200 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 withbeen generated. This would mean that the success/failure results of each precondition attempted by UAC. If UACsession is not satisfied withestablished before A has reduced the combinationnumber of successful preconditions, itsupported codecs. To avoid this situation, the user agent client could instead have sent a CANCEL message. On receipt ofwait for the COMET message, UAS examinesfirst answer from the user agent before setting its local current status to "sendrecv". 11 Security Considerations An entity in the combinationmiddle of satisfied preconditions reported by UAC, and makestwo user agents establishing a final decision whether to proceed withsession 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 inis 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 . Other procedures which the UAC has available to handle multiple simultaneously active transactions (e.g. CANCEL, and BYE) are as given in . 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 about4: Example using the call. The numbersegmented status type An entity performing resource reservations upon reception of messages and the total delay introduced by these messages is kept tounathenticated 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 contentsdenial of theservice attack. Requests with preconditions SHOULD be 12 IANA considerations This document defines three media level SDP containedattributes: 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 accessSection 4. Section 4 also one standard precondition-type related to the content. The security considerations givenattributes above: "qos". If in the SIP specification apply to the COMET method. No additional security considerations specificfuture 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 regardstandardize further precondition-types, they would need to some or all of the specification containedbe defined in thisa 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 24This 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's15 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: firstname.lastname@example.org K. K. Ramakrishnan SIP Working Group Expiration 5/31/02 25 SIP Extensions for Resource Management November 2001 TeraOptic Networks Sunnyvale, CA Email: email@example.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: firstname.lastname@example.org Flemming Andreasen Cisco Edison, NJ Email: email@example.com Michael Ramalho Cisco Wall Township, NJ Email: firstname.lastname@example.org John Pickens Com21 San Jose, CA Email: email@example.com Poornima Lalwaney Nokia San Diego, CA 92121 Email: firstname.lastname@example.org 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: email@example.com Doc Evans D. R. Evans Consulting Boulder, CO 80303 Email: firstname.lastname@example.org Keith Kelly NetSpeak Boca Raton, FL 33587 Email: email@example.com Adam Roach Ericsson Richardson, TX 75081 Email: firstname.lastname@example.orgJonathan Rosenberg dynamicsoft West Orange, NJ 07052 Email:USA electronic mail: email@example.com Dean Willis dynamicsoft West Orange, NJ 07052 Email: firstname.lastname@example.org Steve Donovan dynamicsoft West Orange, NJ 07052 Email: email@example.com Henning Schulzrinne Columbia University New York, NY Email: firstname.lastname@example.org SIP Working Group Expiration 5/31/02 27 SIP Extensions16 Bibliography  J. Rosenberg, H. Schulzrinne, et al. , "SIP: Session initiation protocol," Internet Draft, Internet Engineering Task Force, Feb. 2002. Work in progress.  M. Handley and V. Jacobson, "SDP: session description protocol," Request for Resource Management November 2001Comments 2327, Internet Engineering Task Force, Apr. 1998.  S. Bradner, "Key words for use in RFCs to indicate requirement levels," Request for Comments 2119, Internet Engineering Task Force, Mar. 1997.  J. Rosenberg and H. Schulzrinne, "An offer/answer model with SDP," Internet Draft, Internet Engineering Task Force, Jan. 2002. Work in progress.  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.  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 28PURPOSE. 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.