draft-ietf-sip-manyfolks-resource-01.txt   draft-ietf-sip-manyfolks-resource-02.txt 
SIP Working Group W. Marshall SIP Working Group W. Marshall
Internet Draft AT&T Internet Draft AT&T
Document: <draft-ietf-sip-manyfolks-resource-01> Document: <draft-ietf-sip-manyfolks-resource-02>
K. Ramakrishnan K. Ramakrishnan
TeraOptic Networks TeraOptic Networks
E. Miller E. Miller
Terayon Terayon
G. Russell G. Russell
CableLabs CableLabs
B. Beser B. Beser
skipping to change at line 56 skipping to change at line 56
S. Donovan S. Donovan
dynamicsoft dynamicsoft
H. Schulzrinne H. Schulzrinne
Columbia University Columbia University
February, 2001 February, 2001
Integration of Resource Management and SIP Integration of Resource Management and SIP
SIP Working Group Expiration 2/28/02 1
SIP Extensions for Resource Management August 2001
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026[1]. all provisions of Section 10 of RFC2026[1].
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Internet-Drafts are draft documents valid for a maximum of Drafts. Internet-Drafts are draft documents valid for a maximum of
six months and may be updated, replaced, or obsoleted by other six months and may be updated, replaced, or obsoleted by other
skipping to change at line 77 skipping to change at line 80
as reference material or to cite them other than as "work in as reference material or to cite them other than as "work in
progress." progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
The distribution of this memo is unlimited. It is filed as <draft- The distribution of this memo is unlimited. It is filed as <draft-
ietf-sip-manyfolks-resource-01.txt>, and expires August 31, 2001. ietf-sip-manyfolks-resource-02.txt>, and expires February 28, 2002.
Please send comments to the authors. Please send comments to the authors.
1. Abstract 1. Abstract
This document discusses how network QoS and security establishment This document discusses how network QoS and security establishment
can be made a precondition to sessions initiated by the Session can be made a precondition to sessions initiated by the Session
Initiation Protocol (SIP), and described by SDP. These preconditions Initiation Protocol (SIP), and described by SDP. These preconditions
require that the participant reserve network resources (or establish require that the participant reserve network resources (or establish
a secure media channel) before continuing with the session. We do a secure media channel) before continuing with the session. We do
not define new QoS reservation or security mechanisms; these pre- not define new QoS reservation or security mechanisms; these pre-
skipping to change at line 103 skipping to change at line 106
signaling. The objective of such a mechanism is to enable deployment signaling. The objective of such a mechanism is to enable deployment
of robust IP Telephony services, by ensuring that resources are made of robust IP Telephony services, by ensuring that resources are made
available before the phone rings and the participants of the call available before the phone rings and the participants of the call
are "invited" to participate. are "invited" to participate.
This document also proposes an extension to the Session Initiation This document also proposes an extension to the Session Initiation
Protocol (SIP) to add a new COMET method, which is used to confirm Protocol (SIP) to add a new COMET method, which is used to confirm
the completion of all pre-conditions by the session originator. the completion of all pre-conditions by the session originator.
2. Conventions used in this document 2. Conventions used in this document
SIP Working Group Expiration 2/28/02 2
SIP Extensions for Resource Management August 2001
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC-2119[4]. this document are to be interpreted as described in RFC-2119[4].
3. Introduction 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.........................12
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......................................................19
12.1 Single Media Call Flow.......................................19
12.2 Multiple Media Call Flow.....................................22
13. Special considerations with Forking Proxies...................23
14. Advantages 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 2/28/02 3
SIP Extensions for Resource Management August 2001
For an Internet Telephony service to be successfully used by a large For an Internet Telephony service to be successfully used by a large
number of subscribers, it must offer few surprises to those number of subscribers, it must offer few surprises to those
accustomed to the behavior of existing telephony services. One accustomed to the behavior of existing telephony services. One
expectation is that of connection quality, implying resources must expectation is that of connection quality, implying resources must
be set aside for each call. be set aside for each call.
A key contribution is a recognition of the need for coordination A key contribution is a recognition of the need for coordination
between call signaling, which controls access to telephony specific between call signaling, which controls access to telephony specific
services, and resource management, which controls access to network- services, and resource management, which controls access to network-
skipping to change at line 163 skipping to change at line 218
a secure media channel) before continuing with the session. We do a secure media channel) before continuing with the session. We do
not define new QoS reservation or security mechanisms; these pre- not define new QoS reservation or security mechanisms; these pre-
conditions simply require a participant to use existing resource conditions simply require a participant to use existing resource
reservation and security mechanisms before beginning the session. reservation and security mechanisms before beginning the session.
In the case of SIP [2], this effectively means that the "phone won't In the case of SIP [2], this effectively means that the "phone won't
ring" until the preconditions are met. These preconditions are ring" until the preconditions are met. These preconditions are
described by new SDP parameters, defined in this document. The described by new SDP parameters, defined in this document. The
parameters can mandate end-to-end QoS reservations based on RSVP [5] parameters can mandate end-to-end QoS reservations based on RSVP [5]
or any other end-to-end reservation mechanism (such as YESSIR [6], or any other end-to-end reservation mechanism (such as YESSIR [6],
SIP Working Group Expiration 2/28/02 4
SIP Extensions for Resource Management August 2001
or PacketCable's Dynamic Quality of Service (D-QoS) [7]), and or PacketCable's Dynamic Quality of Service (D-QoS) [7]), and
security based on IPSEC [8]. The preconditions can be defined security based on IPSEC [8]. The preconditions can be defined
independently for each media stream. independently for each media stream.
The QoS architecture of the Internet separates QoS signaling from The QoS architecture of the Internet separates QoS signaling from
application level signaling. Application layer devices (such as web application level signaling. Application layer devices (such as web
proxies and SIP servers) are not well suited for participation in proxies and SIP servers) are not well suited for participation in
network admission control or QoS management, as this is network admission control or QoS management, as this is
fundamentally a network layer issue, independent of any particular fundamentally a network layer issue, independent of any particular
application. In addition, since application devices like SIP servers application. In addition, since application devices like SIP servers
skipping to change at line 217 skipping to change at line 276
which allows indication of pre-conditions for sessions. These which allows indication of pre-conditions for sessions. These
preconditions indicate that participation in the session should not preconditions indicate that participation in the session should not
proceed until the preconditions are met. The preconditions we define proceed until the preconditions are met. The preconditions we define
are (1) success of end-to-end resource reservation, and (2) success are (1) success of end-to-end resource reservation, and (2) success
of end- to-end security establishment. We chose to implement these of end- to-end security establishment. We chose to implement these
extensions in SDP, rather than SIP [2] or SAP [10], since they are extensions in SDP, rather than SIP [2] or SAP [10], since they are
fundamentally a media session issue. SIP is session agnostic; fundamentally a media session issue. SIP is session agnostic;
information about codecs, ports, and RTP [9] are outside the scope information about codecs, ports, and RTP [9] are outside the scope
of SIP. Since it is the media sessions that the reservations and of SIP. Since it is the media sessions that the reservations and
security refer to, SDP is the appropriate venue for the extensions. security refer to, SDP is the appropriate venue for the extensions.
SIP Working Group Expiration 2/28/02 5
SIP Extensions for Resource Management August 2001
Furthermore, placement of the extensions in SDP rather than SIP or Furthermore, placement of the extensions in SDP rather than SIP or
SAP allows specification of preconditions for individual media SAP allows specification of preconditions for individual media
streams. For example, a multimedia lecture might require reservation streams. For example, a multimedia lecture might require reservation
for the audio, but not the video (which is less important). for the audio, but not the video (which is less important).
Our extensions are completely backward compatible. If a recipient Our extensions are completely backward compatible. If a recipient
does not understand them, normal SIP or SAP processing will occur, does not understand them, normal SIP or SAP processing will occur,
at no penalty of call setup latency. at no penalty of call setup latency.
3.1 Requirements 4.1 Requirements
The basic motivation in this work is to meet and possibly exceed the The basic motivation in this work is to meet and possibly exceed the
user expectations and human factors associated with telephony. user expectations and human factors associated with telephony.
In this section, we briefly describe the application requirements In this section, we briefly describe the application requirements
that led to the set of DCS signaling design principles. In its that led to the set of DCS signaling design principles. In its
basic implementation, DCS supports a residential telephone service basic implementation, DCS supports a residential telephone service
comparable to the local telephone services offered today. Some of comparable to the local telephone services offered today. Some of
the requirements for resource management, in concert with call the requirements for resource management, in concert with call
signaling, are as follows: signaling, are as follows:
The system must minimize call defects. These are situations where The system must minimize call defects. These are situations where
either the call never completes, or an error occurs after the either the call never completes, or an error occurs after the
destination is alerted. Requirements on call defects are typically destination is alerted. Requirements on call defects are typically
far more stringent than call blocking. Note that we expect the far more stringent than call blocking. Note that we expect the
provider and the endpoints to attempt to use lower bandwidth CODECs provider and the endpoints to attempt to use lower bandwidth codecs
as the first line of defense against limited network capacity, and as the first line of defense against limited network capacity, and
to avoid blocking calls. to avoid blocking calls.
The system must minimize the post-dial-delay, which is the time The system must minimize the post-dial-delay, which is the time
between the user dialing the last digit and receiving positive between the user dialing the last digit and receiving positive
confirmation from the network. This delay must be short enough that confirmation from the network. This delay must be short enough that
users do not perceive a difference with post-dial delay in the users do not perceive a difference with post-dial delay in the
circuit switched network or conclude that the network connectivity circuit switched network or conclude that the network connectivity
no longer exists. no longer exists.
Call signaling needs to provide enough information to the resource Call signaling needs to provide enough information to the resource
management protocol so as to enable resources to be allocated in the management protocol so as to enable resources to be allocated in the
network. This typically requires most if not all of the components network. This typically requires most if not all of the components
of a packet classifier (source IP, destination IP, source port, of a packet classifier (source IP, destination IP, source port,
destination port, protocol) to be available for resource allocation. destination port, protocol) to be available for resource allocation.
3.2 Overview 4.2 Overview
For acceptable interactive voice communication it is important to For acceptable interactive voice communication it is important to
achieve end-to-end QoS. The end-to-end QoS assurance implies achieve end-to-end QoS. The end-to-end QoS assurance implies
achieving low packet delay and packet loss. End-to-end packet delay achieving low packet delay and packet loss. End-to-end packet delay
must be small enough that it does not interfere with normal voice must be small enough that it does not interfere with normal voice
conversations. The ITU recommends no greater than 300 ms roundtrip conversations. The ITU recommends no greater than 300 ms roundtrip
delay for telephony service. Packet loss must be small enough to delay for telephony service. Packet loss must be small enough to
not perceptibly impede voice quality or the performance of fax and not perceptibly impede voice quality or the performance of fax and
voice band modems. voice band modems.
SIP Working Group Expiration 2/28/02 6
SIP Extensions for Resource Management August 2001
If it is found that the network cannot guarantee end-to-end QoS If it is found that the network cannot guarantee end-to-end QoS
resources, there are two alternatives: either (1) allow call resources, there are two alternatives: either (1) allow call
signaling to proceed with high probability of excessive delay and signaling to proceed with high probability of excessive delay and
packet loss which could impair any interactive real-time packet loss which could impair any interactive real-time
communication between the participants, or (2) block the call prior communication between the participants, or (2) block the call prior
to the called party being alerted. When calls are blocked because to the called party being alerted. When calls are blocked because
of a lack of resources in a particular segment of the network, it is of a lack of resources in a particular segment of the network, it is
highly desirable that such blocking occur before the called party highly desirable that such blocking occur before the called party
picks up. picks up.
We do expect the endpoints to attempt to use lower bandwidth CODECs, We do expect the endpoints to attempt to use lower bandwidth codecs,
thereby avoiding blocking calls, as the first line of defense thereby avoiding blocking calls, as the first line of defense
against limited network capacity. against limited network capacity.
The call signaling and resource reservation must be achieved in such The call signaling and resource reservation must be achieved in such
a way that the post-dial-delay must be minimized without increasing a way that the post-dial-delay must be minimized without increasing
the probability of call defects. This means that the number of the probability of call defects. This means that the number of
round-trip messages must be kept at an absolute minimum and messages round-trip messages must be kept at an absolute minimum and messages
must be sent directly end-system to end-system if possible. must be sent directly end-system to end-system if possible.
The general idea behind the extension is simple. We define two new The general idea behind the extension is simple. We define two new
skipping to change at line 317 skipping to change at line 383
participants must use, based on support by their service provider. participants must use, based on support by their service provider.
If the ISP's of the various participants are using differing If the ISP's of the various participants are using differing
resource reservation protocols, translation is necessary, but this resource reservation protocols, translation is necessary, but this
is done within the network, without knowledge of the participants. is done within the network, without knowledge of the participants.
The direction attribute indicates in which direction reservations The direction attribute indicates in which direction reservations
should be reserved. If "send", it means reservations should be made should be reserved. If "send", it means reservations should be made
in the direction of media flow from the session originator to in the direction of media flow from the session originator to
participants. If "recv", it means reservations should be made in the participants. If "recv", it means reservations should be made in the
direction of media flow from participants to the session originator. direction of media flow from participants to the session originator.
In the case of "sendrecv", it means reservations should be made in In the case of "sendrecv", it means reservations should be made in
both directions. If the direction attribute is "sendrecv" but the both directions. If the direction attribute is "sendrecv" but the
endpoints only support a single-direction resource reservation endpoints only support a single-direction resource reservation
protocol, then both the originator and participants cooperate to protocol, then both the originator and participants cooperate to
ensure the agreed precondition is met. ensure the agreed precondition is met.
SIP Working Group Expiration 2/28/02 7
SIP Extensions for Resource Management August 2001
In the case of security, the same attributes are defined - In the case of security, the same attributes are defined -
optional/mandatory, and send/recv/sendrecv. Their meaning is optional/mandatory, and send/recv/sendrecv. Their meaning is
identical to the one above, except that a security association identical to the one above, except that a security association
should be established in the given direction. The details of the should be established in the given direction. The details of the
security association are not signaled by SDP; these depend on the security association are not signaled by SDP; these depend on the
Security Policy Database of the participant. Security Policy Database of the participant.
Either party can include a "confirm" attribute in the SDP. When the Either party can include a "confirm" attribute in the SDP. When the
"Confirm" attribute is present, the recipient sends a COMET message "Confirm" attribute is present, the recipient sends a COMET message
to the sender, with SDP attached, telling the status of each to the sender, with SDP attached, telling the status of each
skipping to change at line 363 skipping to change at line 431
The "confirm" attribute is typically used if the direction attribute The "confirm" attribute is typically used if the direction attribute
is "sendrecv" and the originator or participant only supports a is "sendrecv" and the originator or participant only supports a
single-direction resource reservation protocol. In such a case, the single-direction resource reservation protocol. In such a case, the
originator (or participant) would reserve resources for one originator (or participant) would reserve resources for one
direction of media flow, and send a confirmation with a direction direction of media flow, and send a confirmation with a direction
attribute of "send." The participant (or originator) would reserve attribute of "send." The participant (or originator) would reserve
resources for the other direction. On receipt of the COMET message, resources for the other direction. On receipt of the COMET message,
they would know that both directions have been reserved, and the they would know that both directions have been reserved, and the
precondition is met. precondition is met.
4. SDP Extension 5. SDP Extension
The formatting of the qos attribute in the Session Description The formatting of the qos attribute in the Session Description
Protocol (SDP)[3] is described by the following BNF: Protocol (SDP)[3] is described by the following BNF:
qos-attribute = "a=qos:" strength-tag SP direction-tag qos-attribute = "a=qos:" strength-tag SP direction-tag
[SP confirmation-tag] [SP confirmation-tag]
strength-tag = ("mandatory" | "optional" | "success" | strength-tag = ("mandatory" | "optional" | "success" |
"failure") "failure")
direction-tag = ("send" | "recv" | "sendrecv") direction-tag = ("send" | "recv" | "sendrecv")
confirmation-tag = "confirm" confirmation-tag = "confirm"
and the security attribute: and the security attribute:
security-attribute = "a=secure:" SP strength-tag SP direction-tag security-attribute = "a=secure:" SP strength-tag SP direction-tag
SIP Working Group Expiration 2/28/02 8
SIP Extensions for Resource Management August 2001
[SP confirmation-tag] [SP confirmation-tag]
4.1 SDP Example 5.1 SDP Example
The following example shows an SDP description carried in a SIP The following example shows an SDP description carried in a SIP
INVITE message from A to B: INVITE message from A to B:
v=0 v=0
o=mhandley 2890844526 2890842807 IN IP4 126.16.64.4 o=mhandley 2890844526 2890842807 IN IP4 126.16.64.4
s=SDP Seminar s=SDP Seminar
i=A Seminar on the session description protocol i=A Seminar on the session description protocol
u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps
e=mjh@isi.edu (Mark Handley) e=mjh@isi.edu (Mark Handley)
skipping to change at line 409 skipping to change at line 481
a=qos:optional sendrecv a=qos:optional sendrecv
a=secure:optional sendrecv a=secure:optional sendrecv
This SDP indicates that B should not continue its involvement in the This SDP indicates that B should not continue its involvement in the
session until resources for the audio are reserved from B to A, and session until resources for the audio are reserved from B to A, and
a bi-directional security association is established for the video. a bi-directional security association is established for the video.
B can join the sessions once these preconditions are met, but should B can join the sessions once these preconditions are met, but should
reserve resources and establish a bi-directional security reserve resources and establish a bi-directional security
association for the whiteboard. association for the whiteboard.
4.2 SDP Allowable Combinations 5.2 SDP Allowable Combinations
If the recipient of the SDP (e.g. the UAS) is capable and willing to If the recipient of the SDP (e.g. the UAS) is capable and willing to
honor the precondition(s), it returns a provisional response honor the precondition(s), it returns a provisional response
containing SDP, along with the qos/security attributes, for each containing SDP, along with the qos/security attributes, for each
such stream. This SDP MUST be a subset of the preconditions such stream. This SDP MUST be a subset of the preconditions
indicated in the INVITE. indicated in the INVITE.
Table 1 illustrates the allowed values for the direction tag in the Table 1 illustrates the allowed values for the direction tag in the
response. Each row represents a value of the direction in the SIP response. Each row represents a value of the direction in the SIP
INVITE, and each column the value in the response. An entry of N/A INVITE, and each column the value in the response. An entry of N/A
means that this combination is not allowed. A value of A->B (B->A) means that this combination is not allowed. A value of A->B (B->A)
implies that the precondition is for resources reserved (or security implies that the precondition is for resources reserved (or security
established) from A to B (B to A). A value of A<->B means that the established) from A to B (B to A). A value of A<->B means that the
precondition is for resource reservation or security establishment precondition is for resource reservation or security establishment
in both directions. The value in the response is the one used by in both directions. The value in the response is the one used by
both parties. both parties.
SIP Working Group Expiration 2/28/02 9
SIP Extensions for Resource Management August 2001
B: response B: response
A: request send recv sendrecv none A: request send recv sendrecv none
send N/A A->B N/A -- send N/A A->B N/A --
recv B->A N/A N/A -- recv B->A N/A N/A --
sendrecv A<-B B<-A A<->B -- sendrecv A<-B B<-A A<->B --
none -- -- -- -- none -- -- -- --
Table 1: Allowed values of coupling Table 1: Allowed values of coupling
Table 2 illustrates the allowed values for the strength tag in the Table 2 illustrates the allowed values for the strength tag in the
skipping to change at line 479 skipping to change at line 554
originator. originator.
B: confirmation B: confirmation
B: reponse send recv sendrecv B: reponse send recv sendrecv
A->B N Y N A->B N Y N
A<-B Y N N A<-B Y N N
A<->B Y Y Y A<->B Y Y Y
Table 4: Allowed values of direction in confirmation from B Table 4: Allowed values of direction in confirmation from B
5. SIP Extension: The COMET Method SIP Working Group Expiration 2/28/02 10
SIP Extensions for Resource Management August 2001
6. SIP Extension: The COMET Method
The COMET method is used for communicating successful completion of The COMET method is used for communicating successful completion of
preconditions between the user agents. preconditions between the user agents.
The signaling path for the COMET method is the signaling path The signaling path for the COMET method is the signaling path
established as a result of the call setup. This can be either established as a result of the call setup. This can be either
direct signaling between the calling and called user agents or a direct signaling between the calling and called user agents or a
signaling path involving SIP proxy servers that were involved in the signaling path involving SIP proxy servers that were involved in the
call setup and added themselves to the Record-Route header on the call setup and added themselves to the Record-Route header on the
initial INVITE message. initial INVITE message.
skipping to change at line 534 skipping to change at line 612
COMET request when it receives a retransmission of the provisional COMET request when it receives a retransmission of the provisional
response being acknowledged, although doing so does not create a response being acknowledged, although doing so does not create a
protocol error. As with any other non-INVITE request, the UAC protocol error. As with any other non-INVITE request, the UAC
continues to retransmit the COMET request until it receives a final continues to retransmit the COMET request until it receives a final
response. response.
A COMET request MAY be cancelled. However, whilst allowed for A COMET request MAY be cancelled. However, whilst allowed for
purposes of generality, usage of CANCEL with COMET is NOT purposes of generality, usage of CANCEL with COMET is NOT
RECOMMENDED. RECOMMENDED.
5.1 Header Field Support for COMET Method SIP Working Group Expiration 2/28/02 11
SIP Extensions for Resource Management August 2001
6.1 Header Field Support for COMET Method
Tables 3 and 4 are extensions of tables 4 and 5 in the SIP Tables 3 and 4 are extensions of tables 4 and 5 in the SIP
specification[2]. Refer to Section 6 of [2] for a description of specification[2]. Refer to Section 6 of [2] for a description of
the content of the tables. the content of the tables.
5.2 Responses to the COMET Request Method 6.2 Responses to the COMET Request Method
If a server receives a COMET request it MUST send a final response. If a server receives a COMET request it MUST send a final response.
A 200 OK response MUST be sent by a UAS for a COMET request if the A 200 OK response MUST be sent by a UAS for a COMET request if the
COMET request was successfully received for an existing call. COMET request was successfully received for an existing call.
Beyond that, no additional operations are required. Beyond that, no additional operations are required.
A 481 Call Leg/Transaction Does Not Exist message MUST be sent by a A 481 Call Leg/Transaction Does Not Exist message MUST be sent by a
UAS if the COMET request does not match any existing call leg. UAS if the COMET request does not match any existing call leg.
skipping to change at line 577 skipping to change at line 658
Content-Type e * Content-Type e *
CSeq gc m CSeq gc m
Date g o Date g o
Encryption g o Encryption g o
Expires g o Expires g o
From gc m From gc m
Hide R o Hide R o
Max-Forwards R o Max-Forwards R o
Organization g o Organization g o
Table 3 Summary of header fields, A-0 Table 3 Summary of header fields, A-0
SIP Working Group Expiration 2/28/02 12
SIP Extensions for Resource Management August 2001
Header Where COMET Header Where COMET
------ ----- ---- ------ ----- ----
Priority R o Priority R o
Proxy-Authenticate 407 o Proxy-Authenticate 407 o
Proxy-Authorization R o Proxy-Authorization R o
Proxy-Require R o Proxy-Require R o
Require R o Require R o
Retry-After R - Retry-After R -
Retry-After 404,480,486 o Retry-After 404,480,486 o
Retry-After 503 o Retry-After 503 o
skipping to change at line 607 skipping to change at line 692
User-Agent g o User-Agent g o
Via gc(2) m Via gc(2) m
Warning r o Warning r o
WWW-Authenticate 401 o WWW-Authenticate 401 o
Table 4 Summary of header fields, P-Z Table 4 Summary of header fields, P-Z
Other request failure (4xx), Server Failure (5xx) and Global Failure Other request failure (4xx), Server Failure (5xx) and Global Failure
(6xx) responses MAY be sent for the COMET Request. (6xx) responses MAY be sent for the COMET Request.
5.3 Message Body Inclusion 6.3 Message Body Inclusion
The COMET request MUST contain a message body. The COMET request MUST contain a message body, with Content-type
"application/sdp".
5.4 Behavior of SIP User Agents 6.4 Behavior of SIP User Agents
Unless stated otherwise, the protocol rules for the COMET request Unless stated otherwise, the protocol rules for the COMET request
governing the usage of tags, Route and Record-Route, retransmission governing the usage of tags, Route and Record-Route, retransmission
and reliability, CSeq incrementing and message formatting follow and reliability, CSeq incrementing and message formatting follow
those in [2] as defined for the BYE request. those in [2] as defined for the BYE request.
A COMET request MAY be cancelled. A UAS receiving a CANCEL for a A COMET request MAY be cancelled. A UAS receiving a CANCEL for a
COMET request SHOULD respond to the COMET with a "487 Request COMET request SHOULD respond to the COMET with a "487 Request
Cancelled" response if a final response has not been sent to the Cancelled" response if a final response has not been sent to the
COMET and then behave as if the request were never received. COMET and then behave as if the request were never received.
5.5 Behavior of SIP Proxy and Redirect Servers 6.5 Behavior of SIP Proxy and Redirect Servers
5.5.1 Proxy Server 6.5.1 Proxy Server
Unless stated otherwise, the protocol rules for the COMET request at Unless stated otherwise, the protocol rules for the COMET request at
a proxy are identical to those for a BYE request as specified in a proxy are identical to those for a BYE request as specified in
[2]. [2].
5.5.2 Forking Proxy Server SIP Working Group Expiration 2/28/02 13
SIP Extensions for Resource Management August 2001
6.5.2 Forking Proxy Server
Unless stated otherwise, the protocol rules for the COMET request at Unless stated otherwise, the protocol rules for the COMET request at
a proxy are identical to those for a BYE request as specified in a proxy are identical to those for a BYE request as specified in
[2]. [2].
5.5.3 Redirection Server 6.5.3 Redirection Server
Unless stated otherwise, the protocol rules for the COMET request at Unless stated otherwise, the protocol rules for the COMET request at
a proxy are identical to those for a BYE request as specified in a proxy are identical to those for a BYE request as specified in
[2]. [2].
6. SIP Extension: The 183-Session-Progress Response 7. SIP Extension: The 183-Session-Progress Response
An additional provisional response is defined by this draft, which An additional provisional response is defined by this draft, which
is returned by a UAS to convey information not otherwise classified. is returned by a UAS to convey information not otherwise classified.
6.1 Status Code and Reason Phrase 7.1 Status Code and Reason Phrase
The following is to be added to Figure 4 in Section 5.1.1, The following is to be added to Figure 4 in Section 5.1.1,
Informational and success Status codes. Informational and success Status codes.
Informational = "183" ;Session-Progress Informational = "183" ;Session-Progress
6.2 Status Code Definition 7.2 Status Code Definition
The following is to be added to a new section 7.1.5 The following is to be added to a new section 7.1.5
7.1.5 183 Session Progress 7.1.5 183 Session Progress
The 183 (Session Progress) response is used to convey information The 183 (Session Progress) response is used to convey information
about the progress of the call which is not otherwise classified. about the progress of the call which is not otherwise classified.
The Reason-Phrase MAY be used to convey more details about the call The Reason-Phrase MAY be used to convey more details about the call
progress. progress.
The Session Progress response MAY contain a message body. If so, it The Session Progress response MAY contain a message body. If so, it
MUST contain a "Content-Disposition" header indicating the proper MUST contain a "Content-Disposition" header indicating the proper
treatment of the message body. treatment of the message body.
7. SIP Extension: The 580-Precondition-Failure Response 8. SIP Extension: The 580-Precondition-Failure Response
An additional error response is defined by this draft, which is An additional error response is defined by this draft, which is
returned by a UAS if it is unable to perform the mandatory returned by a UAS if it is unable to perform the mandatory
preconditions for the session. preconditions for the session.
7.1 Status Code and Reason Phrase 8.1 Status Code and Reason Phrase
The following is to be added to Figure 8, Server error status codes The following is to be added to Figure 8, Server error status codes
Server-Error = "580" ;Precondition-Failure Server-Error = "580" ;Precondition-Failure
7.2 Status Code Definition 8.2 Status Code Definition
SIP Working Group Expiration 2/28/02 14
SIP Extensions for Resource Management August 2001
The following is to be added to a new section 7.5.7. The following is to be added to a new section 7.5.7.
7.5.7 580 Precondition Failure 7.5.7 580 Precondition Failure
The server was unable to establish the qos or security association The server was unable to establish the qos or security association
mandated by the SDP precondition. mandated by the SDP precondition.
8. SIP Extension: Content-Disposition header The Precondition Failure response MUST contain a message body, with
Content-Type "application/sdp", giving the specifics of the
precondition that could not be met.
9. SIP Extension: Content-Disposition header
An additional entity header is defined by this draft, which is An additional entity header is defined by this draft, which is
returned by a UAS in a provisional response indicating preconditions returned by a UAS in a provisional response indicating preconditions
for the session. for the session.
The following is to be added to Table 3, SIP headers, in Section 3. The following is to be added to Table 3, SIP headers, in Section 3.
Entity-header = Content-Disposition ; Section 6.14a Entity-header = Content-Disposition ; Section 6.14a
The following entry is to be added to Table 4, Summary of header The following entry is to be added to Table 4, Summary of header
skipping to change at line 734 skipping to change at line 830
the start of the session. the start of the session.
The handling parameter, disp-param, describes how the UAC or UAS The handling parameter, disp-param, describes how the UAC or UAS
should react if it receives a message body whose content type or should react if it receives a message body whose content type or
disposition type it does not understand. If the parameter has the disposition type it does not understand. If the parameter has the
value "optional" the UAS MUST ignore the message body; if it has the value "optional" the UAS MUST ignore the message body; if it has the
value "required" the UAS MUST return 415 (Unsupported Media Type). value "required" the UAS MUST return 415 (Unsupported Media Type).
If the handling parameter is missing, the value "required" is to be If the handling parameter is missing, the value "required" is to be
assumed. assumed.
9. Option tag for Requires and Supported headers SIP Working Group Expiration 2/28/02 15
SIP Extensions for Resource Management August 2001
10. Option tag for Requires and Supported headers
This draft defines the option tag "precondition" for use in the This draft defines the option tag "precondition" for use in the
Require and Supported headers [12]. Require and Supported headers [12].
A UAS that supports this extension MUST respond to an OPTION request A UAS that supports this extension MUST respond to an OPTION request
with a Supported header that includes the "precondition" tag. with a Supported header that includes the "precondition" tag.
A UAC MAY include a "Require: precondition" in an INVITE request if A UAC MAY include a "Require: precondition" in an INVITE request if
it wants the session initiation to fail if the UAS does not support it wants the session initiation to fail if the UAS does not support
this feature. this feature.
Presence of the precondition entries in the SDP message body of an Presence of the precondition entries in the SDP message body of an
INVITE request or response indicates support of this feature. The INVITE request or response indicates support of this feature. The
UAC or UAS MAY in addition include a "Supported: precondition" UAC or UAS MAY in addition include a "Supported: precondition"
header in the request or response. header in the request or response.
10. SIP Usage Rules 11. SIP Usage Rules
10.1 Overview 11.1 Overview
The session originator (UAC) prepares an SDP message body for the The session originator (UAC) prepares an SDP message body for the
INVITE describing the desired QoS and security preconditions for INVITE describing the desired QoS and security preconditions for
each media flow, and the desired directions. The token value "send" each media flow, and the desired directions. The token value "send"
means the direction of media from originator (whichever entity means the direction of media from originator (whichever entity
created the SDP) to recipient (whichever entity received the SDP in created the SDP) to recipient (whichever entity received the SDP in
a SIP message), and "recv" is from recipient to originator. In an a SIP message), and "recv" is from recipient to originator. In an
INVITE, the UAC is the originator, and the UAS is the recipient. The INVITE, the UAC is the originator, and the UAS is the recipient. The
roles are reversed in the response. roles are reversed in the response.
The recipient of the INVITE (UAS) returns a 18x provisional response The recipient of the INVITE (UAS) returns a 18x provisional response
containing a Content-Disposition of "precondition," and SDP with the containing a Content-Disposition of "precondition," and SDP with the
qos/security attribute for each stream having a precondition. The qos/security attribute for each stream having a precondition. The
UAS would typically include a confirmation request. This SDP is a preconditions in this SDP (i.e. strength tag and direction tag) are
subset of the preconditions indicated in the INVITE. Unlike normal equal to, or a subset of, the preconditions indicated in the INVITE.
SIP processing, the UAS MUST NOT alert the called user at this The UAS would typically include a confirmation request in this SDP.
point. The UAS now attempts to reserve the qos resources and Unlike normal SIP processing, the UAS MUST NOT alert the called user
establish the security associations. at this point. The UAS now attempts to reserve the qos resources
and establish the security associations.
The 18x provisional response is received by the UAC. If the 18x The 18x provisional response is received by the UAC. If the 18x
contained SDP with mandatory qos/security parameters, the UAC does contained SDP with mandatory qos/security parameters, the UAC does
not let the session proceed until the mandatory preconditions are not let the session proceed until the mandatory preconditions are
met. The UAC attempts to reserve the needed resources and establish met. The UAC attempts to reserve the needed resources and establish
the security associations. the security associations.
If either party requests a confirmation, a COMET message is sent to If either party requests a confirmation, a COMET message is sent to
that party. The COMET message contains the success/failure that party. The COMET message contains the success/failure
indication for each precondition. For a precondition with a indication for each precondition. For a precondition with a
direction value of "sendrecv," the COMET indicates whether the direction value of "sendrecv," the COMET indicates whether the
sender is able to confirm both directions or only one direction. sender is able to confirm both directions or only one direction.
Upon receipt of the COMET message, the UAC/UAS continues normal SIP Upon receipt of the COMET message, the UAC/UAS continues normal SIP
call handling. For a UAS this includes alerting the user and call handling. For a UAS this includes alerting the user and
SIP Working Group Expiration 2/28/02 16
SIP Extensions for Resource Management August 2001
sending a 180-Ringing or 200-OK response. The UAC SIP transaction sending a 180-Ringing or 200-OK response. The UAC SIP transaction
completes normally. completes normally.
Note that this extension requires usage of reliable provisional Note that this extension requires usage of reliable provisional
responses [11]. This is because the 18x contains SDP with responses [11]. This is because the 18x contains SDP with
information required for the session originator to initiate information required for the session originator to initiate
reservations towards the participant. reservations towards the participant.
10.2 Behavior of Originator (UAC) 11.2 Behavior of Originator (UAC)
The session originator (UAC) MAY include QoS and security The session originator (UAC) MAY include QoS and security
preconditions (including the desired direction) for each media flow preconditions (including the desired direction) for each media flow
in the SDP sent with the INVITE. The token value "send" means the in the SDP sent with the INVITE. The token value "send" means the
direction of media from originator (whichever entity created the direction of media from originator (whichever entity created the
SDP) to recipient (whichever entity received the SDP in a SIP SDP) to recipient (whichever entity received the SDP in a SIP
message). The token value "recv" means the direction of media from message). The token value "recv" means the direction of media from
recipient to originator. If preconditions are included in the recipient to originator. If preconditions are included in the
INVITE request, the UAC MUST indicate support for reliable INVITE request, the UAC MUST indicate support for reliable
provisional responses [11]. provisional responses [11].
skipping to change at line 822 skipping to change at line 926
If the 18x provisional response contained a Content-Disposition of If the 18x provisional response contained a Content-Disposition of
"precondition" and contained SDP with mandatory qos/security "precondition" and contained SDP with mandatory qos/security
parameters, the UAC SHOULD NOT let the session proceed until the parameters, the UAC SHOULD NOT let the session proceed until the
mandatory preconditions are met. mandatory preconditions are met.
If the 18x provisional response with preconditions requested an If the 18x provisional response with preconditions requested an
acknowledgement (using the methods of [11]), the UAC MUST include an acknowledgement (using the methods of [11]), the UAC MUST include an
updated SDP in the PRACK if the UAC modified the original SDP based updated SDP in the PRACK if the UAC modified the original SDP based
on the response from the UAS. Such a modification MAY be due to on the response from the UAS. Such a modification MAY be due to
negotiation of compatible CODECs, or MAY be due to negotiation of negotiation of compatible codecs, or MAY be due to negotiation of
mandatory preconditions. If the provisional response received from mandatory preconditions. If the provisional response received from
the UAS is a 180-Ringing, and the direction value of a mandatory the UAS is a 180-Ringing, and the direction value of a mandatory
precondition is "sendrecv," and the UAC uses a one-way QoS mechanism precondition is "sendrecv," and the UAC uses a one-way QoS mechanism
(such as RSVP), the updated SDP in the PRACK SHOULD request a (such as RSVP), the updated SDP in the PRACK SHOULD request a
confirmation from the UAS so that the bi-directional precondition confirmation from the UAS so that the bi-directional precondition
can be satisfied before performing the requested alerting function. can be satisfied before performing the requested alerting function.
Upon receipt of the 18x provisional response with preconditions, the Upon receipt of the 18x provisional response with preconditions, the
UAC MUST initiate the qos reservations and establish the security UAC MUST initiate the qos reservations and establish the security
associations to the best of its capabilities. associations to the best of its capabilities.
If the UAC had requested confirmation in the initial SDP, it MAY If the UAC had requested confirmation in the initial SDP, it MAY
wait for the COMET message from the UAS containing the wait for the COMET message from the UAS containing the
success/failure status of each precondition. The UAC MAY set a success/failure status of each precondition. The UAC MAY set a
local timer to limit the time waiting for preconditions to complete. local timer to limit the time waiting for preconditions to complete.
The UAC SHOULD merge the success/failure status in the COMET message The UAC SHOULD merge the success/failure status in the COMET message
with its local status. For example, if the COMET message indicated with its local status. For example, if the COMET message indicated
SIP Working Group Expiration 2/28/02 17
SIP Extensions for Resource Management August 2001
success in the "send" direction, and the UAC was also able to meet success in the "send" direction, and the UAC was also able to meet
the precondition in the "send" direction, they combine to meet the the precondition in the "send" direction, they combine to meet the
precondition in the "sendrecv" direction. precondition in the "sendrecv" direction.
If any of the mandatory preconditions cannot be met, and a If any of the mandatory preconditions cannot be met, and a
confirmation was not requested by the UAS, the UAC MUST send a confirmation was not requested by the UAS, the UAC MUST send a
CANCEL and terminate the session. If any of the optional CANCEL and terminate the session. If any of the optional
preconditions cannot be met, the UAC MAY consult with the preconditions cannot be met, the UAC MAY consult with the
originating customer for guidance on whether to complete the originating customer for guidance on whether to complete the
session. session.
When all the preconditions have either been met or have failed, and When all the preconditions have either been met or have failed, and
the SDP received from the UAS included a confirmation request, the the SDP received from the UAS included a confirmation request, the
UAC MUST send a COMET message to the UAS with SDP. Each UAC MUST send a COMET message to the UAS with SDP. Each
precondition is updated to indicate success/failure and the precondition is updated to indicate success/failure and the
appropriate direction tag is updated based on local operations appropriate direction tag is updated based on local operations
performed combined with the received COMET message, if any. performed combined with the received COMET message, if any.
The session now completes normally, as per [2]. The session now completes normally, as per [2].
10.3 Behavior of Destination (UAS) 11.3 Behavior of Destination (UAS)
On receipt of an INVITE request containing preconditions, the UAS On receipt of an INVITE request containing preconditions, the UAS
MUST generate a 18x provisional response containing a subset of the MUST generate a 18x provisional response containing a subset of the
preconditions supported by the UAS. In the response, the token preconditions supported by the UAS. In the response, the token
value "send" means the direction of the media from the UAS to the 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 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 the SDP in the initial INVITE. The 18x provisional response MUST
include a Content-Disposition header with parameter "precondition." include a Content-Disposition header with parameter "precondition."
If the "confirm" attribute is present in the SDP received from the If the "confirm" attribute is present in the SDP received from the
UAC, or if the direction tag of a mandatory QoS precondition is UAC, or if the direction tag of a mandatory QoS precondition is
skipping to change at line 894 skipping to change at line 1002
[11]. If the PRACK includes an SDP without any preconditions, the [11]. If the PRACK includes an SDP without any preconditions, the
UAS MAY complete the session without the preconditions, or MAY UAS MAY complete the session without the preconditions, or MAY
reject the INVITE request. reject the INVITE request.
The UAS SHOULD request an acknowledgement to the 18x provisional The UAS SHOULD request an acknowledgement to the 18x provisional
response, using the mechanism of [11]. The UAS SHOULD wait for the response, using the mechanism of [11]. The UAS SHOULD wait for the
PRACK message before initiating resource reservation to allow the PRACK message before initiating resource reservation to allow the
resource reservation to reflect 3-way SDP negotiation, or other resource reservation to reflect 3-way SDP negotiation, or other
information available only through receipt of the PRACK. information available only through receipt of the PRACK.
SIP Working Group Expiration 2/28/02 18
SIP Extensions for Resource Management August 2001
If the INVITE request or PRACK message contained mandatory If the INVITE request or PRACK message contained mandatory
preconditions, or requested a confirmation of preconditions, the UAS preconditions, or requested a confirmation of preconditions, the UAS
MUST NOT alert the called user. MUST NOT alert the called user.
The UAS now attempts to reserve the qos resources and establish the The UAS now attempts to reserve the qos resources and establish the
security associations. The UAS MAY set a local timer to limit the security associations. The UAS MAY set a local timer to limit the
time waiting for preconditions to complete. time waiting for preconditions to complete.
If the UAS is unable to perform any mandatory precondition, and If the UAS is unable to perform any mandatory precondition, and
neither the UAC nor UAS requested a confirmation, the UAS MUST send neither the UAC nor UAS requested a confirmation, the UAS MUST send
skipping to change at line 938 skipping to change at line 1049
that combination indicates a failure for a mandatory precondition, that combination indicates a failure for a mandatory precondition,
the UAS MUST send a 580-Precondition-Failure response to the UAC. 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 Once the preconditions are met, the UAS alerts the user, and the SIP
transaction proceeds normally. transaction proceeds normally.
The UAS MAY send additional 18x provisional responses with Content- The UAS MAY send additional 18x provisional responses with Content-
Disposition of "precondition," and the procedures described above Disposition of "precondition," and the procedures described above
are repeated sequentially for each. are repeated sequentially for each.
11. Examples 12. Examples
11.1 Single Media Call Flow 12.1 Single Media Call Flow
Figure 1 presents a high-level overview of a basic end-point to end- 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 point (UAC-UAS) call flow. This example is appropriate for a
single-media session with a mandatory quality-of-service "sendrecv" single-media session with a mandatory quality-of-service "sendrecv"
precondition, where both the UAC and UAS can only perform a single- precondition, where both the UAC and UAS can only perform a single-
direction ("send") resource reservation. direction ("send") resource reservation.
SIP Working Group Expiration 2/28/02 19
SIP Extensions for Resource Management August 2001
The session originator (UAC) prepares an SDP message body for the The session originator (UAC) prepares an SDP message body for the
INVITE describing the desired QoS and security preconditions for INVITE describing the desired QoS and security preconditions for
each media flow, and the desired direction "sendrecv." This SDP is each media flow, and the desired direction "sendrecv." This SDP is
included in the INVITE message sent through the proxies, and included in the INVITE message sent through the proxies, and
includes an entry "a=qos:mandatory sendrecv." includes an entry "a=qos:mandatory sendrecv."
The recipient of the INVITE (UAS), being willing to perform the The recipient of the INVITE (UAS), being willing to perform the
requested precondition, returns a 183-Session-Progress provisional requested precondition, returns a 183-Session-Progress provisional
response containing SDP, along with the qos/security attribute for response containing SDP, along with the qos/security attribute for
each stream having a precondition. Since the "sendrecv" direction each stream having a precondition. Since the "sendrecv" direction
tag required a cooperative effort of the UAC and UAS, the UAS tag required a cooperative effort of the UAC and UAS, the UAS
requests a confirmation when the preconditions are met, with the SDP requests a confirmation when the preconditions are met, with the SDP
entry "a=qos:mandatory sendrecv confirm." The UAS now attempts to entry "a=qos:mandatory sendrecv confirm." The UAS now attempts to
reserve the qos resources and establish the security associations. reserve the qos resources and establish the security associations.
The 183-Session-Progress provisional response is sent using the The 183-Session-Progress provisional response is sent using the
skipping to change at line 971 skipping to change at line 1086
The 183-Session-Progress provisional response is sent using the The 183-Session-Progress provisional response is sent using the
reliability mechanism of [11]. UAC sends the appropriate PRACK and reliability mechanism of [11]. UAC sends the appropriate PRACK and
UAS responds with a 200-OK to the PRACK. UAS responds with a 200-OK to the PRACK.
The 183-Session-Progress is received by the UAC, and the UAC The 183-Session-Progress is received by the UAC, and the UAC
requests the resources needed in its "send" direction, and requests the resources needed in its "send" direction, and
establishes the security associations. Once the preconditions are establishes the security associations. Once the preconditions are
met, the UAC sends a COMET message as requested by the confirmation met, the UAC sends a COMET message as requested by the confirmation
token. This COMET message contains an entry "a=qos:success send" token. This COMET message contains an entry "a=qos:success send"
SIP Working Group Expiration 2/28/02 20
SIP Extensions for Resource Management August 2001
Originating (UAC) Terminating (UAS) Originating (UAC) Terminating (UAS)
| SIP-Proxy(s) | | SIP-Proxy(s) |
| INVITE | | | INVITE | |
|---------------------->|---------------------->| |---------------------->|---------------------->|
| | | | | |
| 183 w/SDP | 183 w/SDP | | 183 w/SDP | 183 w/SDP |
|<----------------------|<----------------------| |<----------------------|<----------------------|
| | | |
| PRACK | | PRACK |
|---------------------------------------------->| |---------------------------------------------->|
skipping to change at line 1013 skipping to change at line 1132
| User Picks-Up | User Picks-Up
| SIP-Proxy(s) the phone | SIP-Proxy(s) the phone
| | | | | |
| 200 OK | 200 OK | | 200 OK | 200 OK |
|<----------------------|<----------------------| |<----------------------|<----------------------|
| | | | | |
| | | |
| ACK | | ACK |
|---------------------------------------------->| |---------------------------------------------->|
Figure 1: Basic Call FLow Figure 1: Basic Call Flow
The UAS successfully performs its resource reservation, in its The UAS successfully performs its resource reservation, in its
"send" direction, and waits for the COMET message from the UAC. "send" direction, and waits for the COMET message from the UAC.
On receipt of the COMET message, the UAS processes the "send" On receipt of the COMET message, the UAS processes the "send"
confirmation contained in the COMET SDP. The "send" confirmation confirmation contained in the COMET SDP. The "send" confirmation
from the UAC coupled with its own "send" success, allows the UAS to from the UAC coupled with its own "send" success, allows the UAS to
determine that all preconditions have been met. The UAS then determine that all preconditions have been met. The UAS then
continues with session establishment. At this point it alerts the continues with session establishment. At this point it alerts the
user, and sends a 180-Ringing provisional response. This user, and sends a 180-Ringing provisional response. This
SIP Working Group Expiration 2/28/02 21
SIP Extensions for Resource Management August 2001
provisional response is also sent using the reliability mechanism of provisional response is also sent using the reliability mechanism of
[11], resulting in a PRACK message and 200-OK of the PRACK. [11], resulting in a PRACK message and 200-OK of the PRACK.
When the destination party answers, the normal SIP 200-OK final When the destination party answers, the normal SIP 200-OK final
response is sent through the proxies to the originator, and the response is sent through the proxies to the originator, and the
originator responds with an ACK message. originator responds with an ACK message.
Either party can terminate the call. An endpoint that detects an Either party can terminate the call. An endpoint that detects an
"on-hook" (request to terminate the call) releases the QoS resources "on-hook" (request to terminate the call) releases the QoS resources
held for the connection, and sends a SIP BYE message to the remote held for the connection, and sends a SIP BYE message to the remote
endpoint, which is acknowledged with a 200-OK. endpoint, which is acknowledged with a 200-OK.
11.2 Multiple Media Call Flow 12.2 Multiple Media Call Flow
Figure 2 presents a high-level overview of an advanced end-point to 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 end-point (UAC-UAS) call flow. This example is appropriate for a
multiple-media session with some combination of mandatory and multiple-media session with some combination of mandatory and
optional quality-of-service precondition. For example, the optional quality-of-service precondition. For example, the
originator may suggest five media streams, and be willing to originator may suggest five media streams, and be willing to
establish the session if any three of them are satisfied. establish the session if any three of them are satisfied.
The use of reliable provisional responses is assumed, but not shown The use of reliable provisional responses is assumed, but not shown
in this figure. in this figure.
skipping to change at line 1076 skipping to change at line 1199
success/failure results of each precondition attempted by UAC. If success/failure results of each precondition attempted by UAC. If
UAC is not satisfied with the combination of successful UAC is not satisfied with the combination of successful
preconditions, it could instead have sent a CANCEL message. preconditions, it could instead have sent a CANCEL message.
On receipt of the COMET message, UAS examines the combination of On receipt of the COMET message, UAS examines the combination of
satisfied preconditions reported by UAC, and makes a final decision satisfied preconditions reported by UAC, and makes a final decision
whether to proceed with the session. If sufficient preconditions whether to proceed with the session. If sufficient preconditions
are not satisfied, the UAS responds with 580-Precondition-Failure. are not satisfied, the UAS responds with 580-Precondition-Failure.
Otherwise, the session proceeds as in the previous example. Otherwise, the session proceeds as in the previous example.
SIP Working Group Expiration 2/28/02 22
SIP Extensions for Resource Management August 2001
Originating (UAC) Terminating (UAS) Originating (UAC) Terminating (UAS)
| SIP-Proxy(s) | | SIP-Proxy(s) |
| INVITE | | | INVITE | |
|---------------------->|---------------------->| |---------------------->|---------------------->|
| | | | | |
| 183 w/SDP | 183 w/SDP | | 183 w/SDP | 183 w/SDP |
|<----------------------|<----------------------| |<----------------------|<----------------------|
| | | |
| Reservation Reservation | | Reservation Reservation |
===========> <=========== ===========> <===========
skipping to change at line 1116 skipping to change at line 1242
| | | | | |
| 200 OK | 200 OK | | 200 OK | 200 OK |
|<----------------------|<----------------------| |<----------------------|<----------------------|
| | | | | |
| | | |
| ACK | | ACK |
|---------------------------------------------->| |---------------------------------------------->|
Figure 2: Call Flow with negotiation of optional preconditions Figure 2: Call Flow with negotiation of optional preconditions
12. Special considerations with Forking Proxies 13. Special considerations with Forking Proxies
If a proxy along the signaling path between the UAC and UAS forks If a proxy along the signaling path between the UAC and UAS forks
the INVITE request, it results in two or more UASs simultaneously the INVITE request, it results in two or more UASs simultaneously
sending provisional responses with preconditions. The procedures sending provisional responses with preconditions. The procedures
above result in the UAC handling each independently, reserving above result in the UAC handling each independently, reserving
resources and responding with COMET messages as required. resources and responding with COMET messages as required.
This results in multiple resource reservations from the UAC, only This results in multiple resource reservations from the UAC, only
one of which will be utilized for the final session. While one of which will be utilized for the final session. While
functionally correct, this has the unfortunate side-effect of functionally correct, this has the unfortunate side-effect of
increasing the call blocking probability. increasing the call blocking probability.
SIP Working Group Expiration 2/28/02 23
SIP Extensions for Resource Management August 2001
Customized resource allocation protocols may be used by the UAC to Customized resource allocation protocols may be used by the UAC to
reduce this duplicate allocation and prevent excess blocking of reduce this duplicate allocation and prevent excess blocking of
calls. For one such example, see [8]. calls. For one such example, see [8].
13. Advantages of the Proposed Approach 14. Advantages of the Proposed Approach
The use of two-phase call signaling makes it possible for SIP to The use of two-phase call signaling makes it possible for SIP to
meet user expectations that come from the telephony services. meet user expectations that come from the telephony services.
The reservation of resources before the user is alerted makes sure The reservation of resources before the user is alerted makes sure
that the network resources are assured before the destination end- that the network resources are assured before the destination end-
point is informed about the call. point is informed about the call.
The number of messages and the total delay introduced by these The number of messages and the total delay introduced by these
messages is kept to a minimum without sacrificing compatibility with messages is kept to a minimum without sacrificing compatibility with
SIP servers that do not implement preconditions. SIP servers that do not implement preconditions.
14. Security Considerations 15. Security Considerations
If the contents of the SDP contained in the 183-Session-Progress are If the contents of the SDP contained in the 183-Session-Progress are
private then end-to-end encryption of the message body can be used private then end-to-end encryption of the message body can be used
to prevent unauthorized access to the content. to prevent unauthorized access to the content.
The security considerations given in the SIP specification apply to The security considerations given in the SIP specification apply to
the COMET method. No additional security considerations specific to the COMET method. No additional security considerations specific to
the COMET method are necessary. the COMET method are necessary.
15. Notice Regarding Intellectual Property Rights 16. Notice Regarding Intellectual Property Rights
AT&T may seek patent or other intellectual property protection for
some or all of the technologies disclosed in the document. If any
standards arising from this disclosure are or become protected by
one or more patents assigned to AT&T, AT&T intends to disclose those
patents and license them on reasonable and non-discriminatory terms.
Future revisions of this draft may contain additional information
regarding specific intellectual property protection sought or
received.
3COM may seek patent or other intellectual property protection for The IETF has been notified of intellectual property rights claimed
some or all of the technologies disclosed in the document. If any in regard to some or all of the specification contained in this
standards arising from this disclosure are or become protected by document. For more information consult the online list of claimed
one or more patents assigned to 3COM, 3COM intends to disclose those rights.
patents and license them on reasonable and non-discriminatory terms.
Future revisions of this draft may contain additional information
regarding specific intellectual property protection sought or
received.
16. References 17. References
1. Bradner, S., "The Internet Standards Process -- Revision 3", BCP 1. Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996. 9, RFC 2026, October 1996.
2. M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP: 2. M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP:
Session Initiation Protocol," RFC 2543, March 1999. Session Initiation Protocol," RFC 2543, March 1999.
3. M. Handley and V. Jacobson, "SDP: Session Description Protocol," 3. M. Handley and V. Jacobson, "SDP: Session Description Protocol,"
RFC 2327, April 1998. RFC 2327, April 1998.
4. Bradner, S., "Key words for use in RFCs to Indicate Requirement 4. Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997 Levels", BCP 14, RFC 2119, March 1997
5. R. Braden, Ed., L. Zhang, S. Berson, S. Herzog, and S. Jamin, 5. R. Braden, Ed., L. Zhang, S. Berson, S. Herzog, and S. Jamin,
"Resource ReSerVation protocol (RSVP) -- version 1 functional "Resource ReSerVation protocol (RSVP) -- version 1 functional
specification," RFC 2205, September, 1997. specification," RFC 2205, September, 1997.
SIP Working Group Expiration 2/28/02 24
SIP Extensions for Resource Management August 2001
6. P. P. Pan and H. Schulzrinne, "YESSIR: A simple reservation 6. P. P. Pan and H. Schulzrinne, "YESSIR: A simple reservation
mechanism for the Internet," in Proc. International Workshop on mechanism for the Internet," in Proc. International Workshop on
Network and Operating System Support for Digital Audio and Video Network and Operating System Support for Digital Audio and Video
(NOSSDAV), (Cambridge, England), July 1998. Also IBM Research (NOSSDAV), (Cambridge, England), July 1998. Also IBM Research
Technical Report TC20967. Available at Technical Report TC20967. Available at
http://www.cs.columbia.edu/~hgs/papers/Pan98_YESSIR.ps.gz. http://www.cs.columbia.edu/~hgs/papers/Pan98_YESSIR.ps.gz.
7. PacketCable, Dynamic Quality of Service Specification, pkt-sp- 7. PacketCable, Dynamic Quality of Service Specification, pkt-sp-
dqos-i01-991201, December 1, 1999. Available at dqos-i01-991201, December 1, 1999. Available at
http://www.packetcable.com/specs/pkt-sp-dqos-i01-991202.pdf. http://www.packetcable.com/specs/pkt-sp-dqos-i01-991202.pdf.
skipping to change at line 1219 skipping to change at line 1338
Transport Protocol for Real-Time Applications," RFC 1889, January Transport Protocol for Real-Time Applications," RFC 1889, January
1996. 1996.
10. M. Handley, C. Perkins, and E. Whelan, "Session Announcement 10. M. Handley, C. Perkins, and E. Whelan, "Session Announcement
Protocol," RFC2974, October, 2000. Protocol," RFC2974, October, 2000.
11. "Reliability of Provisional Responses in SIP," RFC pending. 11. "Reliability of Provisional Responses in SIP," RFC pending.
12. "The SIP Supported Header," RFC pending. 12. "The SIP Supported Header," RFC pending.
17. Acknowledgments 18. Acknowledgments
The Distributed Call Signaling work in the PacketCable project is The Distributed Call Signaling work in the PacketCable project is
the work of a large number of people, representing many different the work of a large number of people, representing many different
companies. The authors would like to recognize and thank the companies. The authors would like to recognize and thank the
following for their assistance: John Wheeler, Motorola; David following for their assistance: John Wheeler, Motorola; David
Boardman, Daniel Paul, Arris Interactive; Bill Blum, Jay Strater, Boardman, Daniel Paul, Arris Interactive; Bill Blum, Jay Strater,
Jeff Ollis, Clive Holborow, General Instruments; Doug Newlin, Guido Jeff Ollis, Clive Holborow, General Instruments; Doug Newlin, Guido
Schuster, Ikhlaq Sidhu, 3Com; Jiri Matousek, Bay Networks; Farzi Schuster, Ikhlaq Sidhu, 3Com; Jiri Matousek, Bay Networks; Farzi
Khazai, Nortel; John Chapman, Bill Guckel, Cisco; Chuck Kalmanek, Khazai, Nortel; John Chapman, Bill Guckel, Cisco; Chuck Kalmanek,
Doug Nortz, John Lawser, James Cheng, Tung-Hai Hsiao, Partho Mishra, Doug Nortz, John Lawser, James Cheng, Tung-Hai Hsiao, Partho Mishra,
AT&T; Telcordia Technologies; and Lucent Cable Communications. AT&T; Telcordia Technologies; and Lucent Cable Communications.
18. Author's Addresses 19. Author's Addresses
Bill Marshall Bill Marshall
AT&T AT&T
Florham Park, NJ 07932 Florham Park, NJ 07932
Email: wtm@research.att.com Email: wtm@research.att.com
K. K. Ramakrishnan K. K. Ramakrishnan
TeraOptic Networks TeraOptic Networks
Sunnyvale, CA Sunnyvale, CA
Email: kk@teraoptic.com Email: kk@teraoptic.com
SIP Working Group Expiration 2/28/02 25
SIP Extensions for Resource Management August 2001
Ed Miller Ed Miller
Terayon Terayon
Louisville, CO 80027 Louisville, CO 80027
Email: E.Miller@terayon.com Email: E.Miller@terayon.com
Glenn Russell Glenn Russell
CableLabs CableLabs
Louisville, CO 80027 Louisville, CO 80027
Email: G.Russell@Cablelabs.com Email: G.Russell@Cablelabs.com
skipping to change at line 1299 skipping to change at line 1421
Poornima Lalwaney Poornima Lalwaney
Nokia Nokia
San Diego, CA 92121 San Diego, CA 92121
Email: poornima.lalwaney@nokia.com Email: poornima.lalwaney@nokia.com
Jon Fellows Jon Fellows
Copper Mountain Networks Copper Mountain Networks
San Diego, CA 92121 San Diego, CA 92121
Email: jfellows@coppermountain.com Email: jfellows@coppermountain.com
SIP Working Group Expiration 2/28/02 26
SIP Extensions for Resource Management August 2001
Doc Evans Doc Evans
D. R. Evans Consulting D. R. Evans Consulting
Boulder, CO 80303 Boulder, CO 80303
Email: n7dr@arrl.net Email: n7dr@arrl.net
Keith Kelly Keith Kelly
NetSpeak NetSpeak
Boca Raton, FL 33587 Boca Raton, FL 33587
Email: keith@netspeak.com Email: keith@netspeak.com
skipping to change at line 1334 skipping to change at line 1459
Steve Donovan Steve Donovan
dynamicsoft dynamicsoft
West Orange, NJ 07052 West Orange, NJ 07052
Email: sdonovan@dynamicsoft.com Email: sdonovan@dynamicsoft.com
Henning Schulzrinne Henning Schulzrinne
Columbia University Columbia University
New York, NY New York, NY
Email: schulzrinne@cs.columbia.edu Email: schulzrinne@cs.columbia.edu
SIP Working Group Expiration 2/28/02 27
SIP Extensions for Resource Management August 2001
Full Copyright Statement Full Copyright Statement
"Copyright (C) The Internet Society (2000). All Rights Reserved. "Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implmentation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than followed, or as required to translate it into languages other than
English. The limited permissions granted above are perpetual and English. The limited permissions granted above are perpetual and
will not be revoked by the Internet Society or its successors or will not be revoked by the Internet Society or its successors or
assigns. This document and the information contained herein is assigns. This document and the information contained herein is
provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
Expiration Date This memo is filed as <draft-ietf-sip-manyfolks- Expiration Date This memo is filed as <draft-ietf-sip-manyfolks-
resource-01.txt>, and expires August 31, 2001. resource-02.txt>, and expires February 28, 2002.
SIP Working Group Expiration 2/28/02 28
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/