draft-ietf-sip-manyfolks-resource-03.txt   draft-ietf-sip-manyfolks-resource-04.txt 
SIP Working Group W. Marshall Internet Engineering Task Force SIP WG
Internet Draft AT&T Internet Draft G. Camarillo (Editor)
Document: <draft-ietf-sip-manyfolks-resource-03>
K. Ramakrishnan
TeraOptic Networks
E. Miller
Terayon
G. Russell
CableLabs
B. Beser
Pacific Broadband
M. Mannette
K. Steinbrenner
3Com
D. Oran
F. Andreasen
M. Ramalho
Cisco
J. Pickens
Com21
P. Lalwaney
Nokia
J. Fellows
Copper Mountain Networks
D. Evans
D. R. Evans Consulting
K. Kelly
NetSpeak
A. Roach
Ericsson Ericsson
W. Marshall (Editor)
J. Rosenberg AT&T
D. Willis Jonathan Rosenberg
S. Donovan
dynamicsoft dynamicsoft
draft-ietf-sip-manyfolks-resource-04.txt
H. Schulzrinne February 25, 2002
Columbia University Expires: August, 2002
November, 2001
Integration of Resource Management and SIP Integration of Resource Management and SIP
SIP Working Group Expiration 5/31/02 1 STATUS OF THIS MEMO
SIP Extensions for Resource Management November 2001
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.
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.
six months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet- Drafts Internet-Drafts are draft documents valid for a maximum of six months
as reference material or to cite them other than as "work in and may be updated, replaced, or obsoleted by other documents at any
progress." time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at 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 To view the list Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
The distribution of this memo is unlimited. It is filed as <draft- Abstract
ietf-sip-manyfolks-resource-03.txt>, and expires May 31, 2002.
Please send comments to the authors.
1. Abstract
This document discusses how network QoS and security establishment
can be made a precondition to sessions initiated by the Session
Initiation Protocol (SIP), and described by SDP. These preconditions
require that the participant reserve network resources (or establish
a secure media channel) before continuing with the session. We do
not define new QoS reservation or security mechanisms; these pre-
conditions simply require a participant to use existing resource
reservation and security mechanisms before beginning the session.
This results in a multi-phase call-setup mechanism, with the
resource management protocol interleaved between two phases of call
signaling. The objective of such a mechanism is to enable deployment
of robust IP Telephony services, by ensuring that resources are made
available before the phone rings and the participants of the call
are "invited" to participate.
This document also proposes an extension to the Session Initiation
Protocol (SIP) to add a new COMET method, which is used to confirm
the completion of all pre-conditions by the session originator.
2. Conventions used in this document
SIP Working Group Expiration 5/31/02 2
SIP Extensions for Resource Management November 2001
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC-2119[4].
3. Table of Contents
Status of this Memo................................................2
1. Abstract........................................................2
2. Conventions used in this document...............................2
3. Table of Contents...............................................3
4. Introduction....................................................3
4.1 Requirements...................................................6
4.2 Overview.......................................................6
5. SDP Extension...................................................8
5.1 SDP Example....................................................9
5.2 SDP Allowable Combinations.....................................9
6. SIP Extension: The COMET Method................................11
6.1 Header Field Support for COMET Method.........................11
6.2 Responses to the COMET Request Method.........................12
6.3 Message Body Inclusion........................................13
6.4 Behavior of SIP User Agents...................................13
6.5 Behavior of SIP Proxy and Redirect Servers....................13
6.5.1 Proxy Server................................................13
6.5.2 Forking Proxy Server........................................14
6.5.3 Redirection Server..........................................14
7. SIP Extension: The 183-Session-Progress Response...............14
7.1 Status Code and Reason Phrase.................................14
7.2 Status Code Definition........................................14
8. SIP Extension: The 580-Precondition-Failure Response...........14
8.1 Status Code and Reason Phrase.................................14
8.2 Status Code Definition........................................14
9. SIP Extension: Content-Disposition header......................15
10. Option tag for Requires and Supported headers.................16
11. SIP Usage Rules...............................................16
11.1 Overview.....................................................16
11.2 Behavior of Originator (UAC).................................17
11.3 Behavior of Destination (UAS)................................18
12. Examples......................................................20
12.1 Single Media Call Flow.......................................20
12.2 Multiple Media Call Flow.....................................22
13. Special considerations with Forking Proxies...................23
14. Advantages of the Proposed Approach...........................24
15. Security Considerations.......................................24
16. Notice Regarding Intellectual Property Rights.................24
17. References....................................................24
18. Acknowledgments...............................................25
19. Author's Addresses............................................25
Full Copyright Statement..........................................28
4. Introduction
SIP Working Group Expiration 5/31/02 3
SIP Extensions for Resource Management November 2001
For an Internet Telephony service to be successfully used by a large
number of subscribers, it must offer few surprises to those
accustomed to the behavior of existing telephony services. One
expectation is that of connection quality, implying resources must
be set aside for each call.
A key contribution is a recognition of the need for coordination
between call signaling, which controls access to telephony specific
services, and resource management, which controls access to network-
layer resources. This coordination is designed to meet the user
expectations and human factors associated with telephony.
While customers may expect, during times of heavy load, to receive a
"fast busy" or an announcement saying "all circuits are busy now,"
the general expectation is that once the destination phone rings
that the connection can be made. Blocking a call after ringing the
destination is considered a "call defect" and is a very undesirable
exception condition.
This draft addresses both "QoS-Assured" and "QoS-Enabled" sessions.
A "QoS-Assured" session will complete only if all the required
resources are available and assigned to the session. A provider may
choose to block a call when adequate resources for the call are not
available. Public policy demands that the phone system provide
adequate quality at least in certain cases: e.g., for emergency
communications during times of disasters. Call blocking enables a
provider to meet such requirements.
A "QoS-Enabled" session allows the endpoints to complete the session
establishment either with or without the desired resources. Such
session will use dedicated resources if available, and use a best-
effort connection as an alternative if resources can not be
dedicated. In cases where resources are not available, the
originating and/or terminating User Agent might consult with the
customer to obtain guidance on whether the session should complete.
Coordination between call signaling and resource management is also
needed to prevent fraud and theft of service. The coordination
between call-signaling and QoS setup protocols ensures that users
are authenticated and authorized before receiving access to the
enhanced QoS associated with the telephony service.
This coordination, referred to in this draft as "preconditions,"
require that the participant reserve network resources (or establish
a secure media channel) before continuing with the session. We do
not define new QoS reservation or security mechanisms; these pre-
conditions simply require a participant to use existing resource
reservation and security mechanisms before beginning the session.
In the case of SIP [2], this effectively means that the "phone won't
ring" until the preconditions are met. These preconditions are
described by new SDP parameters, defined in this document. The
parameters can mandate end-to-end QoS reservations based on RSVP [5]
or any other end-to-end reservation mechanism (such as YESSIR [6],
SIP Working Group Expiration 5/31/02 4
SIP Extensions for Resource Management November 2001
or PacketCable's Dynamic Quality of Service (D-QoS) [7]), and
security based on IPSEC [8]. The preconditions can be defined
independently for each media stream.
The QoS architecture of the Internet separates QoS signaling from
application level signaling. Application layer devices (such as web
proxies and SIP servers) are not well suited for participation in
network admission control or QoS management, as this is
fundamentally a network layer issue, independent of any particular
application. In addition, since application devices like SIP servers
are almost never on the "bearer path" (i.e., the network path the
RTP [9] takes), and since the RTP path and signaling paths can be
completely different (even traversing different autonomous systems),
these application servers are generally not capable of managing QoS
for the media. Keeping QoS out of application signaling also means
that there can be a single infrastructure for QoS across all
applications. This eliminates duplication of functionality, reducing
management and equipment costs. It also means that new applications,
with their own unique QoS requirements, can be easily supported.
This loose coupling works very well for a wide range of
applications. For example, in an interactive game, one can establish
the game using an application signaling protocol, and then later on
use RSVP to reserve network resources. The separation is also
effective for applications which have no explicit signaling.
However, certain applications may require tighter coupling. In the
case of Internet telephony, the following is an important
requirement:
When A calls B, B's phone should not ring unless resources
have been reserved from A to B, and B to A.
This could be achieved without coupling if A knew B's address, port,
and codecs before the telephony signaling took place. However, since
telephony signaling is used largely to obtain this information in
the first place, the coupling cannot be avoided.
A similar model exists for security. Rather than inventing new
security mechanisms for each new application, common security tools
(such as IPSEC) can be used across all applications. As with QoS, a
means in application level protocols is needed to indicate that a
security association is needed for the application to execute.
To solve both of these problems, we propose an extension to SDP
which allows indication of pre-conditions for sessions. These
preconditions indicate that participation in the session should not
proceed until the preconditions are met. The preconditions we define
are (1) success of end-to-end resource reservation, and (2) success
of end- to-end security establishment. We chose to implement these
extensions in SDP, rather than SIP [2] or SAP [10], since they are
fundamentally a media session issue. SIP is session agnostic;
information about codecs, ports, and RTP [9] are outside the scope
of SIP. Since it is the media sessions that the reservations and
security refer to, SDP is the appropriate venue for the extensions.
SIP Working Group Expiration 5/31/02 5
SIP Extensions for Resource Management November 2001
Furthermore, placement of the extensions in SDP rather than SIP or
SAP allows specification of preconditions for individual media
streams. For example, a multimedia lecture might require reservation
for the audio, but not the video (which is less important).
Our extensions are completely backward compatible. If a recipient
does not understand them, normal SIP or SAP processing will occur,
at no penalty of call setup latency.
4.1 Requirements
The basic motivation in this work is to meet and possibly exceed the
user expectations and human factors associated with telephony.
In this section, we briefly describe the application requirements
that led to the set of DCS signaling design principles. In its
basic implementation, DCS supports a residential telephone service
comparable to the local telephone services offered today. Some of
the requirements for resource management, in concert with call
signaling, are as follows:
The system must minimize call defects. These are situations where
either the call never completes, or an error occurs after the
destination is alerted. Requirements on call defects are typically
far more stringent than call blocking. Note that we expect the
provider and the endpoints to attempt to use lower bandwidth codecs
as the first line of defense against limited network capacity, and
to avoid blocking calls.
The system must minimize the post-dial-delay, which is the time
between the user dialing the last digit and receiving positive
confirmation from the network. This delay must be short enough that
users do not perceive a difference with post-dial delay in the
circuit switched network or conclude that the network connectivity
no longer exists.
Call signaling needs to provide enough information to the resource
management protocol so as to enable resources to be allocated in the
network. This typically requires most if not all of the components
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. The ITU recommends no greater than 300 ms roundtrip
delay for telephony service. Packet loss must be small enough to
not perceptibly impede voice quality or the performance of fax and
voice band modems.
SIP Working Group Expiration 5/31/02 6
SIP Extensions for Resource Management November 2001
If it is found that the network cannot guarantee end-to-end QoS
resources, there are two alternatives: either (1) allow call
signaling to proceed with high probability of excessive delay and
packet loss which could impair any interactive real-time
communication between the participants, or (2) block the call prior
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
highly desirable that such blocking occur before the called party
picks up.
We do expect the endpoints to attempt to use lower bandwidth codecs,
thereby avoiding blocking calls, as the first line of defense
against limited network capacity.
The call signaling and resource reservation must be achieved in such
a way that the post-dial-delay must be minimized without increasing
the probability of call defects. This means that 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.
The general idea behind the extension is simple. We define two new
SDP attributes, "qos" and "security". The "qos" attribute indicates
whether end-to-end resource reservation is optional or mandatory,
and in which direction (send, recv, or sendrecv). When the attribute
indicates mandatory, this means that the participant who has
received the SDP does not proceed with participation in the session
until resource reservation has completed in the direction indicated.
In this case, "not proceeding" means that the participant behaves as
if they had not received the SDP at all. If the attribute indicates
that QoS for the stream is optional, then the participant proceeds
normally with the session, but should reserve network resources in
the direction indicated, if they are capable. Absence of the "qos"
attribute means the participant reserves resources for this stream,
and proceeds normally with the session. This behavior is the normal
behavior for SDP.
Resource reservation takes place using whatever protocols
participants must use, based on support by their service provider.
If the ISP's of the various participants are using differing
resource reservation protocols, translation is necessary, but this
is done within the network, without knowledge of the participants.
The direction attribute indicates in which direction reservations
should be reserved. If "send", it means reservations should be made
in the direction of media flow from the session originator to
participants. If "recv", it means reservations should be made in the
direction of media flow from participants to the session originator.
In the case of "sendrecv", it means reservations should be made in
both directions. If the direction attribute is "sendrecv" but the
endpoints only support a single-direction resource reservation
protocol, then both the originator and participants cooperate to
ensure the agreed precondition is met.
SIP Working Group Expiration 5/31/02 7
SIP Extensions for Resource Management November 2001
In the case of security, the same attributes are defined -
optional/mandatory, and send/recv/sendrecv. Their meaning is
identical to the one above, except that a security association
should be established in the given direction. The details of the
security association are not signaled by SDP; these depend on the
Security Policy Database of the participant.
Either party can include a "confirm" attribute in the SDP. When the
"Confirm" attribute is present, the recipient sends a COMET message
to the sender, with SDP attached, telling the status of each
precondition as "success" or "failure." If the "confirm" attribute
is present in the SDP sent by the session originator to the
participant (e.g. in the SIP INVITE message), then the participant
sends the COMET message to the originator. If the "confirm"
attribute is present in the SDP sent by the recipient to the
originator (e.g. in a SIP response message), then the originator
sends the COMET message to the participant.
When the "Confirm" attribute is present in both the SDP sent by the
session originator to the participant (e.g. in the SIP INVITE
message), and in the SDP sent by the recipient back to the
originator (e.g. in a SIP response message), the session originator
would wait for the COMET message with the success/failure
notification before responding with a COMET message, and responds
instead with a CANCEL if a mandatory precondition is not met, or if
a sufficient combination of optional preconditions are not met. The
recipient does not wait for the COMET message from the originator
before sending its COMET message.
The "confirm" attribute is typically used if the direction attribute
is "sendrecv" and the originator or participant only supports a
single-direction resource reservation protocol. In such a case, the
originator (or participant) would reserve resources for one
direction of media flow, and send a confirmation with a direction
attribute of "send." The participant (or originator) would reserve
resources for the other direction. On receipt of the COMET message,
they would know that both directions have been reserved, and the
precondition is met.
5. SDP Extension
The formatting of the qos attribute in the Session Description
Protocol (SDP)[3] is described by 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"
and the security attribute:
security-attribute = "a=secure:" SP strength-tag SP direction-tag
SIP Working Group Expiration 5/31/02 8
SIP Extensions for Resource Management November 2001
[SP confirmation-tag]
5.1 SDP Example
The following example shows an SDP description carried in a SIP
INVITE message from A to B:
v=0
o=mhandley 2890844526 2890842807 IN IP4 126.16.64.4
s=SDP Seminar
c=IN IP4 224.2.17.12/127
t=2873397496 2873404696
m=audio 49170 RTP/AVP 0
a=qos:mandatory recv confirm
m=video 51372 RTP/AVP 31
a=secure:mandatory sendrecv
m=application 32416 udp wb
a=orient:portrait
a=qos:optional sendrecv
a=secure:optional sendrecv
This SDP indicates that B should not continue its involvement in the
session until resources for the audio are reserved from B to A, and
a bi-directional security association is established for the video.
B can join the sessions once these preconditions are met, but should
reserve resources and establish a bi-directional security
association for the whiteboard.
5.2 SDP Allowable Combinations
If the recipient of the SDP (e.g. the UAS) is capable and willing to
honor the precondition(s), it returns a provisional response
containing SDP, along with the qos/security attributes, for each
such stream. This SDP MUST be a subset of the preconditions
indicated in the INVITE.
Table 1 illustrates the allowed values for the direction tag in the
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
means that this combination is not allowed. A value of A->B (B->A)
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
precondition is for resource reservation or security establishment
in both directions. The value in the response is the one used by
both parties.
SIP Working Group Expiration 5/31/02 9
SIP Extensions for Resource Management November 2001
B: response
A: request send recv sendrecv none
send N/A A->B N/A --
recv B->A N/A N/A --
sendrecv A<-B B<-A A<->B --
none -- -- -- --
Table 1: Allowed values of coupling
Table 2 illustrates the allowed values for the strength tag in the
request and response. A "Y" means the combination is allowed, and a
"N" means it is not. The value in the response is the one used by
both parties.
B: response
A: request mandatory optional none
mandatory Y Y Y
optional N Y Y
none N N Y
Table 2: Allowed values of strength parameter
Table 3 illustrates the allowed values for the direction tag in a
confirmation message (COMET) sent from the originator to a
participant, based on the value of the direction tag negotiated in
the initial request and response. A "Y" means the combination is
allowed, and a "N" means it is not and SHOULD be ignored by the
participant.
A: confirmation
B: reponse send recv sendrecv
A->B Y N N
A<-B N Y N
A<->B Y Y Y
Table 3: Allowed values of direction in confirmation from A
Table 4 illustrates the allowed values for the direction tag in a
confirmation message (COMET) sent from the participant to the
originator, based on the value of the direction tag negotiated in
the initial request and response. A "Y" means the combination is
allowed, and a "N" means it is not and SHOULD be ignored by the
originator.
B: confirmation
B: reponse send recv sendrecv
A->B N Y N
A<-B Y N N
A<->B Y Y Y
Table 4: Allowed values of direction 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 This document discusses how network quality of service can be made a
preconditions between the user agents. precondition to establishment of sessions initiated by the Session
Initiation Protocol (SIP). These preconditions require that the
participant reserve network resources before continuing with the
session. We do not define new quality of service reservation
mechanisms; these preconditions simply require a participant to use
existing resource reservation mechanisms before beginning the
session.
The signaling path for the COMET method is the signaling path 1 Introduction
established as a result of the call setup. This can be either
direct signaling between the calling and called user agents or a
signaling path involving SIP proxy servers that were involved in the
call setup and added themselves to the Record-Route header on the
initial INVITE message.
The precondition information is communicated in the message body, Some architectures require that at session establishment time, once
which MUST contain an SDP. For every agreed precondition, the the callee has been alerted, the chances of a session establishment
strength-tag MUST indicate "success" or "failure". failure are minimum. One source of failure is the inability to
reserve network resources for a session. In order to minimize "ghost
rings", it is necessary to reserve network resources for the session
before the callee is alerted. However, the reservation of network
resources frequently requires learning the IP address, port, and
session parameters from the callee. This information is obtained as a
result of the initial offer/answer exchange carried in SIP. This
exchange normally causes the "phone to ring", thus introducing a
chicken-and-egg problem: resources cannot be reserved without
performing an initial offer/answer exchange, and the initial
offer/answer exchange can't be done without performing resource
reservation.
If the initial request contained Record-Route headers, the The solution is to introduce the concept of a precondition. A
provisional response MUST contain a copy of those headers, as if the precondition is a set of constraints about the session which are
response were a 200 OK to the initial request. Since provisional introduced in the offer. The recipient of the offer generates an
responses MAY contain Record-Route and Contact headers, the COMET answer, but does not alert the user or otherwise proceed with session
request MUST contain Route headers, constructed as specified in [2], establishment. That only occurs when the preconditions are met. This
if the Record-Route headers were present in the provisional can be known through a local event (such as a confirmation of a
response. resource reservation), or through a new offer sent by the caller.
A UAC MUST NOT insert a Route header into a COMET request if no This document deals with sessions that use SIP [1] as signalling
Record-Route header was present in the response. protocol and SDP [2] to describe the parameters of the session.
If the initial request was sent with credentials, the COMET request We have chosen to include the quality of service preconditions in the
SHOULD contain those credentials as well. SDP description rather than in the SIP header because preconditions
are stream specific.
The Call-ID in the COMET MUST match that of the provisional 2 Terminology
response. The CSeq in this request MUST be larger than the last
request sent by this UAC for this call leg. The To, From, and Via
headers MUST be present, and MUST be constructed as they would be
for a re-INVITE or BYE as specified in [2]. In particular, if the
provisional response contained a tag in the To field, this tag MUST
be mirrored in the To field of the COMET.
Once the COMET request is created, it is sent by the UAC. It is sent The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
as would any other non-INVITE request for a call. In particular, "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
when sent over UDP, the COMET request is retransmitted as specified document are to be interpreted as described in RFC 2119 [3].
in [2]. Note that a UAC SHOULD NOT retransmit the COMET request
when it receives a retransmission of the provisional response being
acknowledged, although doing so does not create a protocol error. As
with any other non-INVITE request, the UAC continues to retransmit
the COMET request until it receives a final response.
Use of CANCEL of a COMET is as specified in [2]. 3 Overview
6.1 Header Field Support for COMET Method In order to ensure that session establishment does not take place
until certain preconditions are met we distinguish between two
different state variables that affect a particular media stream:
current status and desired status. This document defines quality of
service status.
SIP Working Group Expiration 5/31/02 11 The desired status consists of a threshold for the current status.
SIP Extensions for Resource Management November 2001 Session establishment stops until the current status reaches or
surpasses this threshold. Once this threshold is reached or
surpassed, session establishment resumes.
Tables 5 and 6 are extensions of tables 4 and 5 in the SIP For example, the following values for current and desired status
specification[2]. Refer to Section 6 of [2] for a description of would not allow session establishment to resume:
the content of the tables.
6.2 Responses to the COMET Request Method current status = resources reserved in the send direction
desired status = resources reserved in both (sendrecv) directions
If a server receives a COMET request it MUST send a final response. On the other hand, the values of the example below would make session
establishment resume:
A 200 OK response MUST be sent by a UAS for a COMET request if the current status = resources reserved in both (sendrecv) directions
COMET request was successfully received for an existing call. desired status = resources reserved in the send direction
Beyond that, no additional operations are required.
A 481 Call Leg/Transaction Does Not Exist message MUST be sent by a These two state variables define a certain piece of state of a media
UAS if the COMET request does not match any existing call leg. stream the same way as the direction attribute or the codecs in use,
define other pieces of state. Consequently, we treat these two new
variables in the same way as other SDP media attributes are treated
in the offer/answer model used by SIP [4]: they are exchanged between
two user agents using an offer and an answer in order to have a
shared view of the status of the session.
Header Where COMET Figure 1 shows a typical message exchange between two SIP user agents
------ ----- ---- using preconditions. A includes quality of service preconditions in
Accept R o the SDP of the initial INVITE. A does not want B to be alerted until
Accept-Encoding R o there is network resources reserved in both directions (sendrecv)
Accept-Language R o end-to-end. B agrees to reserve network resources for this session
Allow 200 - before alerting the callee. B will handle resource reservation in the
Allow 405 o B->A direction, but wants A to handle the A->B direction. To indicate
Authorization R o so, B returns a 183 response to A asking A to start resource
Call-ID gc m reservation and to warn B as soon as the A->B direction is ready for
Contact R o the session. A and B both start resource reservation. B finishes
Contact 1xx - reserving resources in the B->A direction, but does not alert the
Contact 2xx - user yet, because network resources in both directions are needed.
Contact 3xx - When A finishes reserving resources in the A->B direction, it sends
Contact 485 - an UPDATE to B. B returns a 200 (OK) response for the UPDATE
Content-Encoding e o indicating that all the preconditions for the session have been met.
Content-Length e o At this point of time, B starts alerting the user, and session
Content-Type e * establishment completes normally.
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 4 SDP parameters
SIP Extensions for Resource Management November 2001
Header Where COMET We define the following media level SDP attributes:
------ ----- ----
Priority R -
Proxy-Authenticate 407 o
Proxy-Authorization R o
Proxy-Require R o
Record-Route R o
Record-Route 2xx o
Require R o
Response-Key R o
Retry-After R -
Retry-After 404,480,486 o
Retry-After 503 o
Retry-After 600,603 o
Route R o
Server r o
Subject R o
Timestamp g o
To gc(1) m
Unsupported 420 o
User-Agent g o
Via gc(2) m
Warning r o
WWW-Authenticate 401 o
Table 6 Summary of header fields, P-Z 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")
Other request failure (4xx), Server Failure (5xx) and Global Failure Current status: The current status attribute carries the current
(6xx) responses MAY be sent for the COMET Request. status of network resources for a particular media stream.
6.3 Message Body Inclusion Desired status: The desired status attribute carries the
preconditions for a particular media stream. When the
current status value has the same or a better value than
the desired status value, the preconditions are considered
to be met.
The COMET request MUST contain a message body, with Content-type Confirmation status: The desired status attribute carries
"application/sdp". threshold conditions for a media stream. When the status of
network resources reach these conditions, the peer user
agent will send an update of the session description
containing an updated current status attribute for this
particular media stream.
6.4 Behavior of SIP User Agents Precondition type: This document defines quality of service
preconditions. Extensions may define other types of
preconditions.
Unless stated otherwise, the protocol rules for the COMET request Strength tag: The strength tag indicates whether or not the
governing the usage of tags, Route and Record-Route, retransmission callee can be alerted in case the network fails to meet the
and reliability, CSeq incrementing and message formatting follow preconditions.
those in [2] as defined for the BYE request.
A COMET request MAY be cancelled. A UAS receiving a CANCEL for a Status type: We define two types of status: end-to-end and
COMET request SHOULD respond to the COMET with a "487 Request segmented. The end-to-end status reflects the status of the
Cancelled" response if a final response has not been sent to the end-to-end reservation of resources. The segmented status
COMET and then behave as if the request were never received. reflects the status of the access network reservations of
both user agents. The end-to-end status corresponds to the
tag "e2e" defined above and the segmented status to the
tags "local" and "remote". End-to-end status is useful when
end-to-end resource reservation mechanisms. The segmented
status is useful when one or both UAs perform resource
reservations on their respective access networks.
6.5 Behavior of SIP Proxy and Redirect Servers A B
6.5.1 Proxy Server | |
|-------------(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----------------->|
| |
| |
Unless stated otherwise, the protocol rules for the COMET request at Figure 1: Basic session establishment using preconditions
a proxy are identical to those for a BYE request as specified in Direction tag: The direction tag indicates the direction a
[2]. concrete attribute is applicable to.
SIP Working Group Expiration 5/31/02 13 The values of the tags "send", "recv", "local" and "remote" represent
SIP Extensions for Resource Management November 2001 the point of view of the entity generating the SDP description. In an
offer, "send" is the direction offerer->answerer and "local" is the
offerer's access network. In an answer, "send" is the direction
answerer->offerer and "local" is the answerer's access network.
6.5.2 Forking Proxy Server The following example shows these new SDP attributes in two media
lines of a session description:
Unless stated otherwise, the protocol rules for the COMET request at m=audio 20000 RTP/AVP 0
a proxy are identical to those for a BYE request as specified in a=curr:qos e2e send
[2]. 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
6.5.3 Redirection Server 5 Usage of the new SDP status parameters in the SIP offer/answer model
Unless stated otherwise, the protocol rules for the COMET request at Parameter negotiation in SIP is carried out using the offer answer
a proxy are identical to those for a BYE request as specified in model described in [4]. The idea behind this model is to provide a
[2]. shared view of the session parameters for both user agents once the
answer has been received by the offerer. This section describes which
values can our new SDP attributes take in an answer depending on
their value in the offer.
7. SIP Extension: The 183-Session-Progress Response 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
answerer in the offer. The anwerer uses the information of this
transaction status table to update its local status table. The
answerer also updates the transaction status table fields that were
out of date and returns this table to the offerer in the answer. The
offerer can then update its local status table with the information
received in the answer. After this offer/answer exchange, the local
status tables of both user agents are synchronised. They now have a
common view of the status of the media stream. Sessions that involve
several media streams implement these tables per media stream. Note,
however, that this is a model of user agent behavior, not of
software. An implementation is free to take any approach that
replicates the external behavior this model defines.
An additional provisional response is defined by this draft, which 5.1 Generating an offer
is returned by a UAS to convey information not otherwise classified.
7.1 Status Code and Reason Phrase Both user agents MUST implement a table, referred to as "local status
table", reflecting the status of the resource reservation. Tables 1
and 2 show the format of this tables for both the end-to-end and the
segmented status types. For the end-to-end status type, the table
contains two rows; one for each direction (i.e., send and recv). A
value of "yes" in the "Current" field indicates that resource has
been successfully reserved in the corresponding direction. "No"
indicates that resources have not been reserved yet. The "Desired
Strength" field indicates the strength of the preconditions in the
corresponding direction. The table for the segmented status type
contains four rows: both directions in the local access network and
in the peer's access network. The meaning of the fields is the same
as in the end-to-end case.
The following is to be added to Figure 4 in Section 5.1.1, Before generating an offer, the offerer MUST build a transaction
Informational and success Status codes. status table with the current and the desired status for each media
stream. The different values of the strength tag for the desired
status attribute have the following semantics:
Informational = "183" ;Session-Progress o None: no resource reservation is needed.
7.2 Status Code Definition o Optional: the user agents SHOULD try to provide resource
reservation, but the session can continue regardless of
whether this provision is possible or not.
The following is to be added to a new section 7.1.5 o Mandatory: the user agents MUST provide resource reservation.
Otherwise, session establishment MUST NOT continue.
7.1.5 183 Session Progress The offerer then decides whether it is going to use the end-to-end
status type or the segmented status type. If the status type of the
media line will be end-to-end, the user agent generates records with
the desired status and the current status for each direction (send
and recv) independently, as shown in table 1:
The 183 (Session Progress) response is used to convey information Direction Current Desired Strength
about the progress of the call which is not otherwise classified. ____________________________________
The Reason-Phrase MAY be used to convey more details about the call send no mandatory
progress. recv no mandatory
The Session Progress response MAY contain a message body. If so, it Table 1: Table for the end-to-end status type
MUST contain a "Content-Disposition" header indicating the proper If the status type of the media line will be segmented, the user
treatment of the message body. agent generates records with the desired status and the current
status for each direction (send and recv) and each segment (local and
remote) independently, as shown in table 2:
8. SIP Extension: The 580-Precondition-Failure Response Direction Current Desired Strength
______________________________________
local send no none
local recv no none
remote send no optional
remote recv no none
An additional error response is defined by this draft, which is Table 2: Table for the segmented status type
returned by a UAS if it is unable to perform the mandatory
preconditions for the session.
8.1 Status Code and Reason Phrase At the time of sending the offer, the offerer's local status table
and the transaction status table contain the same values.
The following is to be added to Figure 8, Server error status codes With the transaction status table, the user agent generates the
current-status and the desired status lines following the syntax of
Section 4 and the rules described below in Section 5.1.1.
Server-Error = "580" ;Precondition-Failure 5.1.1 SDP encoding
8.2 Status Code Definition For the end-to-end status type, the user agent MUST generate one
current status line with the tag "e2e" for the media stream. If the
strength tags for both directions are equal (e.g., both mandatory) in
the transaction status table, the user agent MUST add one desired
status line with the tag "sendrecv". If both tags are different, the
user agent MUST include two desired status lines, one with the tag
"send" and the other with the tag "recv".
SIP Working Group Expiration 5/31/02 14 The semantics of two lines with the same strength tag, one
SIP Extensions for Resource Management November 2001 with a "send" tag and the other with a "recv" tag, is the
same as one "sendrecv" line. However, in order to achieve a
more compact encoding, we have chosen to make mandatory the
latter format.
The following is to be added to a new section 7.5.7. For the segmented status type, the user agent MUST generate two
current status lines: one with the tag "local" and the 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 particular segment
(local or remote) the tags for both directions in the transaction
status table are equal (e.g., both mandatory), the user agent MUST
add one desired status line with the tag "sendrecv". If both tags are
different, the user agent MUST include two desired status lines, one
with the tag "send" and the other with the tag "recv".
7.5.7 580 Precondition Failure Note that the rules above apply to the desired strength tag "none" as
well. This way, a user agent that supports quality of service but
does not intend to use them, adds desired status lines with the
strength tag "none". Since this tag can be upgraded in the answer, as
described in Section 5.2, the answerer can request quality of service
reservation without a need of another offer/answer exchange.
The server was unable to establish the qos or security association The example below shows the SDP corresponding to tables 1 and 2.
mandated by the SDP precondition.
The Precondition Failure response MUST contain a message body, with m=audio 20000 RTP/AVP 0
Content-Type "application/sdp", giving the specifics of the a=curr:qos e2e none
precondition that could not be met. 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
9. SIP Extension: Content-Disposition header 5.2 Generating an Answer
An additional entity header is defined by this draft, which is When the answerer receives the offer, it recreates the transaction
returned by a UAS in a provisional response indicating preconditions status table using the SDP attributes contained in the offer. The
for the session. answerer updates both its local status and the transaction status
table following the rules below:
The following is to be added to Table 3, SIP headers, in Section 3. Desired Strength: We define an absolute ordering for the
strength tags: none, optional and mandatory. Mandatory is
the tag with highest grade and none the tag with lowest
grade. An answerer MAY upgrade the desired strength in any
entry of the transaction status table, but it MUST NOT
downgrade it. Therefore, it is OK to upgrade a row from
none to optional, from none to mandatory or from optional
to mandatory, but not the other way around.
Entity-header = Content-Disposition ; Section 6.14a Current Status: For every row, the value of the "Current" field
in the transaction status table and in the local status
table of the answerer have to be compared. Table 3 shows
the four possible combinations. If both fields have the
same value (two first rows of table 3, nothing needs to be
updated. If the "Current" field of the transaction status
table is "Yes" and the field of the local status table is
"No" (third row of table 3), the latter MUST be set to
"Yes". If the "Current" field of the transaction status
table is "No" and the field of the local status table is
"Yes" (forth row of table 3), the answerer needs to check
if it has local information (e.g., a confirmation of a
resource reservation has been received) about that
particular current status. If it does, the "Current" field
of the transaction status table is set to "Yes". If the
answerer does not have local information about that current
status, the "Current" field of the local status table MUST
be set to "No".
The following entry is to be added to Table 4, Summary of header Transaction status table Local status table
fields, A-O, in Section 6. ____________________________________________
no no
yes yes
yes no
no yes
where enc e-e ACK BYE CAN INV OPT REG Table 3: Possible values for the "Current" fields
Content-Disposition e e o o - o o o
The following is to be added to a new section after 6.14. Once both tables have been updated an answer is generated following
the rules described in Section 5.1.1 and taking into account that
"send", "recv", "local" and "remote" tags have to be inverted in the
answer, as shown in table 4.
6.14a Content-Disposition Offer Answer
______________
send recv
recv send
local remote
remote local
Content-disposition = "Content-Disposition" ":" Table 4: Values of tags in offer and answers
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 At the time the answer is sent, the transaction status table and the
is to be interpreted by the UAC or UAS. answerer's local status table contain the same values. Therefore,
this answer contains the shared view of the status of the media line
in the current-status attribute and the negotiated strength and
direction tags in the desired-status attribute.
The value "precondition" indicates the body part describes QoS If the resource reservation mechanism used requires participation of
and/or security preconditions that SHOULD be established prior to both user agents, the answerer SHOULD start resource reservation
the start of the session. after having sent the answer and the offerer SHOULD start resource
reservation as soon as the answer is received. If participation of
the peer user agent is not needed (e.g., segmented status type), the
offerer MAY start resource reservation before sending the offer and
the answerer MAY start it before sending the answer.
The handling parameter, disp-param, describes how the UAC or UAS The status of the resource reservation of a media line can change
should react if it receives a message body whose content type or between two consecutive offer/answer exchanges. Therefore, both user
disposition type it does not understand. If the parameter has the agents MUST keep their local status tables up to date using local
value "optional" the UAS MUST ignore the message body; if it has the information through the duration of the session.
value "required" the UAS MUST return 415 (Unsupported Media Type).
If the handling parameter is missing, the value "required" is to be
assumed.
SIP Working Group Expiration 5/31/02 15 6 Suspending and Resuming Session Establishment
SIP Extensions for Resource Management November 2001
10. Option tag for Requires and Supported headers A user agent server that receives an offer with preconditions
SHOULDNOT alert the user until all the mandatory preconditions are
met; session establishment is suspended until that moment.
This draft defines the option tag "precondition" for use in the A user agent server may receive an INVITE request with no offer in
Require and Supported headers [12]. it. In this case, following normal SIP procedures, the user agent
server will provide an offer in a reliable response (1xx or 2xx). The
user agent client will send the answer in another SIP request. If the
offer and the answer contain preconditions, the user agent client
SHOULD NOT alert the user until all the mandatory preconditions in
the answer are met.
A UAS that supports this extension MUST respond to an OPTION request While session establishment is suspended, user agents SHOULD not send
with a Supported header that includes the "precondition" tag. any data over any media stream. In the case of RTP [5], neither RTP
nor RTCP packets are sent.
A UAC MAY include a "Require: precondition" in an INVITE request if A user agent server knows that all the preconditions are met for a
it wants the session initiation to fail if the UAS does not support media line when its local status table has a value of "yes" in all
this feature. A UAC that would respond to a failed session (if due the rows whose strength tag is "mandatory". When the preconditions of
to lack of precondition support) by immediately retrying the session all the media lines of the session are met, session establishment
without the preconditions, SHOULD NOT include this Require tag SHOULD resume.
value.
Presence of the precondition entries in the SDP message body of an For an initial INVITE suspending and resuming session establishment
INVITE request or response indicates support of this feature. The is very intuitive. The callee will not be alerted until all the
UAC or UAS MAY in addition include a "Supported: precondition" mandatory preconditions are met. However, offers containing
header in the request or response. preconditions sent in the middle of an ongoing session need further
explanation. Both user agents SHOULD continue using the old session
parameters until all the mandatory preconditions are met. At that
moment, the user agents can begin using the new session parameters.
Section 10 contains an example of this situation.
11. SIP Usage Rules 7 Status Confirmation
11.1 Overview The qos-confirm-status attribute MAY be used in both offers and
answers. This attribute represents a threshold for the resource
reservation. When this threshold is reached or surpassed, the user
agent MUST send an offer to the peer user agent reflecting the new
current status of the media line. If this threshold is crossed again
(e.g., the network stops providing resources for the media stream),
the user agent MUST send a new offer as well.
The session originator (UAC) prepares an SDP message body for the If a peer has requested confirmation on a particular stream, an agent
INVITE describing the desired QoS and security preconditions for MUST mark that stream with a flag in its local status table. When all
each media flow, and the desired directions. The token value "send" the rows with this flag have a value of "yes", the user agent MUST
means the direction of media from originator (whichever entity send a new offer to the peer. This offer will contain the current
created the SDP) to recipient (whichever entity received the SDP in status of resource reservation in the qos-current-status attributes.
a SIP message), and "recv" is from recipient to originator. In an If later any of the rows with this flag transition to "No", a new
INVITE, the UAC is the originator, and the UAS is the recipient. The offer MUST be sent as well.
roles are reversed in the response.
A User Agent with an active session that desires to change the media Confirmation attributes are not negotiated. The answerer uses the
flows prepares an SDP message body for the re-INVITE describing the value of the qos-confirm-status attribute in the offer and the
desired QoS and security preconditions for the revised media flows offerer uses the value of this attribute in the answer.
and the desired directions. The procedures for the re-INVITE, and
the subsequent message exchanges, are identical to those of an
initial INVITE.
The recipient of the INVITE (UAS) returns a 18x provisional response For example, if a user agent receives an SDP description with the
containing a Content-Disposition of "precondition," and SDP with the following attributes:
qos/security attribute for each stream having a precondition. The
preconditions in this SDP (i.e. strength tag and direction tag) are
equal to, or a subset of, the preconditions indicated in the INVITE.
The UAS would typically include a confirmation request in this SDP.
Unlike normal SIP processing, the UAS MUST NOT alert the called user
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 m=audio 20002 RTP/AVP 0
contained SDP with mandatory qos/security parameters, the UAC does a=curr:qos local none
not let the session proceed until the mandatory preconditions are a=curr:qos remote none
a=des:qos mandatory local sendrecv
a=des:qos mandatory remote sendrecv
a=conf:qos remote sendrecv
SIP Working Group Expiration 5/31/02 16 It will send an offer as soon as it reserves resources in its access
SIP Extensions for Resource Management November 2001 network ("remote" tag in the received message) for both directions
(sendrecv).
met. The UAC attempts to reserve the needed resources and establish 8 Refusing an offer
the security associations.
If either party requests a confirmation, a COMET message is sent to We define a new SIP status code:
that party. The COMET message contains the success/failure
indication for each precondition. For a precondition with a
direction value of "sendrecv," the COMET indicates whether the
sender is able to confirm both directions or only one direction.
Upon receipt of the COMET message, the UAC/UAS continues normal SIP
call handling. For a UAS this includes alerting 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 Server-Error = "580" ;Precondition Failure
responses [11]. This is because the 18x contains SDP with
information required for the session originator to initiate
reservations towards the participant.
11.2 Behavior of Originator (UAC) When an answerer cannot or is not willing to meet the preconditions
in the offer it SHOULD reject the offer by returning a 580
(Precondition-Failure) response. This response SHOULD contain an SDP
description indicating which desired status triggered the failure.
The corresponding desired status line MUST a value of the strength
tag of "failure", as shown in the example below:
The session originator (UAC) MAY include QoS and security m=audio 20000 RTP/AVP 0
preconditions (including the desired direction) for each media flow a=des:qos failure e2e send
in the SDP sent with the INVITE. The token value "send" means the
direction of media from originator (whichever entity created the
SDP) to recipient (whichever entity received the SDP in a SIP
message). The token value "recv" means the direction of media from
recipient to originator. If preconditions are included in the
INVITE request, the UAC MUST indicate support for reliable
provisional responses [11].
If the UAC receives a 18x provisional response without a Content- SDP description indicating this type of failure MUST follow the
Disposition of "precondition," or without SDP, or with SDP but format for describing media capabilities defined in the SIP
without any qos/security preconditions in any stream, UAC treats it offer/answer model [4].
as an indication that the UAS is unable or unwilling to perform the
preconditions requested. As such, the UAC SHOULD proceed with normal
call setup procedures.
If the 18x provisional response contained a Content-Disposition of Using the 580 (Precondition Failure) status code to refuse an offer
"precondition" and contained SDP with mandatory qos/security is useful when the offer came in an INVITE or in an UPDATE request.
parameters, the UAC SHOULD NOT let the session proceed until the However, SIP does not provide a means to refuse offers that contained
mandatory preconditions are met. in a response (1xx or 2xx) to an INVITE.
If the 18x provisional response with preconditions requested an If a UAC generates an initial INVITE without an offer and receives an
acknowledgement (using the methods of [11]), the UAC MUST include an offer in a 1xx or 2xx response which is not acceptable, it SHOULD
updated SDP in the PRACK if the UAC modified the original SDP based respond to this offer with a correctly formed answer and immediately
on the response from the UAS. Such a modification MAY be due to after that send a CANCEL or a BYE.
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, and the direction value of a mandatory
precondition is "sendrecv," and the UAC uses a one-way QoS mechanism
(such as RSVP), the updated 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 If the offer comes in a 1xx or 2xx response to a re-INVITE, A would
SIP Extensions for Resource Management November 2001 not have a way to reject it without terminating the session at the
same time. The same recommendation given in Section 14.2 of [1]
applies here:
Upon receipt of the 18x provisional response with preconditions, the "The UAS MUST ensure that the session description overlaps
UAC MUST initiate the qos reservations and establish the security with its previous session description in media formats,
associations to the best of its capabilities. transports, other parameters that require support from the
peer. This is to avoid the need for the peer to reject the
session description. If, however, it is unacceptable to A,
A SHOULD generate an answer with a valid session
description, and then send a BYE to terminate the session."
If the UAC had requested confirmation in the initial SDP, it MAY 9 Option tag for Require and Supported header fields
wait for the COMET message from the UAS containing the
success/failure status of each precondition. The UAC MAY set a
local timer to limit the time waiting for preconditions to complete.
The UAC SHOULD merge the success/failure status in the COMET message
with its local status. For example, if the COMET message indicated
success in the "send" direction, and the UAC was also able to meet
the precondition in the "send" direction, they combine to meet the
precondition in the "sendrecv" direction.
If any of the mandatory preconditions cannot be met, and a We define the option tag "precondition" for use in the Require and
confirmation was not requested by the UAS, the UAC MUST send a Supported header fields. An offerer MUST include this tag if the
CANCEL and terminate the session. If any of the optional offer contains one or more strength tags with the value "mandatory".
preconditions cannot be met, the UAC MAY consult with the If all the strength tags in the description are "optional" or "none"
originating customer for guidance on whether to complete the the offerer MUST include this tag either in a Supported header field
session. or in a Require header field. It is, however, RECOMMENDED, that the
Supported header field is used in this case. The lack of
preconditions in the answer would indicate that the answerer did not
support this extension.
When all the preconditions have either been met or have failed, and The mapping of offers and answers to SIP requests and responses is
the SDP received from the UAS included a confirmation request, the performed following the rules given in . Therefore, a user agent
UAC MUST send a COMET message to the UAS with SDP. Each including preconditions in the SDP MUST include both "100rel" [6] and
precondition is updated to indicate success/failure and the "update" tags in the Require header field.
appropriate direction tag is updated based on local operations
performed combined with the received COMET message, if any.
The session now completes normally, as per [2]. Any SDP included in 10 Examples
subsequent requests in this transaction MUST NOT change the agreed
media definitions (e.g. all lines in the SDP description other than
the precondition lines).
11.3 Behavior of Destination (UAS) The following examples cover both status types; end-to-end and
segmented.
On receipt of an INVITE request containing preconditions, the UAS 10.1 End-to-end Status Type
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 The call flow of figure 2 shows a basic session establishment using
indicate support for reliable provisional responses[11], the UAS MAY the end-to-end status type. The SDP descriptions of this example are
include preconditions in a 18x provisional response to the INVITE. shown below:
SIP Working Group Expiration 5/31/02 18 SDP1: B includes end-to-end quality of service preconditions in the
SIP Extensions for Resource Management November 2001 initial offer.
The 18x provisional response MUST include a Content-Disposition m=audio 20000 RTP/AVP 0
header with the parameter "precondition." The 18x provisional c=IN IP4 192.0.2.1
response MUST request an acknowledgement using the mechanism of a=curr:qos e2e none
[11]. If the PRACK includes an SDP without any preconditions, the a=des:qos mandatory e2e sendrecv
UAS MAY complete the session without the preconditions, or MAY
reject the INVITE request.
The UAS SHOULD request an acknowledgement to the 18x provisional SDP2: Since B uses RSVP, it can know when resources in its "send"
response, using the mechanism of [11]. The UAS SHOULD wait for the direction are available, because it will receive RESV messages from
PRACK message before initiating resource reservation to allow the the network. However, it does not know the status of the reservations
resource reservation to reflect 3-way SDP negotiation, or other in the other direction. B requests confirmation for resource
information available only through receipt of the PRACK. reservations in its "recv" direction to the peer user agent A in its
answer.
If the INVITE request or PRACK message contained mandatory m=audio 30000 RTP/AVP 0
preconditions, or requested a confirmation of preconditions, the UAS c=IN IP4 192.0.2.4
MUST NOT alert the called user. a=curr:qos e2e none
a=des:qos mandatory e2e sendrecv
a=conf:qos e2e recv
The UAS now attempts to reserve the qos resources and establish the After having sent the answer B starts reserving network resources for
security associations. The UAS MAY set a local timer to limit the the media stream. When A receives this answer (2) it starts
time waiting for preconditions to complete. performing resource reservation as well. Both UAs use RSVP, so A
sends PATH messages towards B and B sends PATH messages towards A.
If the UAS is unable to perform any mandatory precondition, and As time passes by, B receives RESV messages confirming the
neither the UAC nor UAS requested a confirmation, the UAS MUST send reservation. However, B waits until resources in the other direction
a 580-Precondition-Failure response to the UAC. If the UAS is as reserved as well since it did not receive any confirmation and the
unable to perform any optional precondition, it MAY consult with the preconditions still have not been met.
customer to obtain guidance regarding completion of the session.
When processing of all preconditions is complete, if a precondition SDP3: When A receives RESV messages it sends an updated offer (5) to
in the SDP specified a confirmation request, the UAS MUST send a B:
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 m=audio 20000 RTP/AVP 0
response SDP, it SHOULD wait for the COMET message from the c=IN IP4 192.0.2.1
originator containing the success/failure indication of each a=curr:qos e2e send
precondition from the originator's point of view. The a=des:qos mandatory e2e sendrecv
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 SDP4: B responds with an answer (6) which contains the current status
transaction proceeds normally. of the resource reservation (i.e., sendrecv):
SIP Working Group Expiration 5/31/02 19 m=audio 30000 RTP/AVP 0
SIP Extensions for Resource Management November 2001 c=IN IP4 192.0.2.4
a=curr:qos e2e sendrecv
a=des:qos mandatory e2e sendrecv
The UAS MAY send additional 18x provisional responses with Content- At this point of time, session establishment resumes and B returns a
Disposition of "precondition," and the procedures described above 180 (Ringing) response (7).
are repeated sequentially for each.
Any SDP included in subsequent requests and responses in this Note that now the media stream has been already established, and A
transaction MUST NOT change the agreed media definitions (e.g. all has received a 180 (Ringing) response. Since the direction of the
lines in the SDP description other than the precondition lines). stream is "sendrecv", A will not generate local ringback, since it
assumes that it will receive early media over this stream.
12. Examples However, if B wants A to generate local ringback, it can put the
media stream on hold in SDP4. In this case, B would put the media
stream off hold by sending an offer in the 200 OK for the INVITE (8).
The contents of the messages for this alternative flow is shown
below:
12.1 Single Media Call Flow SDP4 (on hold):
Figure 1 presents a high-level overview of a basic end-point to end- m=audio 30000 RTP/AVP 0
point (UAC-UAS) call flow. This example is appropriate for a c=IN IP4 192.0.2.4
single-media session with a mandatory quality-of-service "sendrecv" a=recvonly
precondition, where both the UAC and UAS can only perform a single- a=curr:qos e2e sendrecv
direction ("send") resource reservation. a=des:qos mandatory e2e sendrecv
The session originator (UAC) prepares an SDP message body for the SDP5 in the 200 OK (10):
INVITE describing the desired QoS and security preconditions for
each media flow, and the desired direction "sendrecv." This SDP is
included 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 m=audio 30000 RTP/AVP 0
requested precondition, returns a 183-Session-Progress provisional c=IN IP4 192.0.2.4
response containing SDP, along with the qos/security attribute for a=sendrecv
each stream having a precondition. Since the "sendrecv" direction a=curr:qos e2e sendrecv
tag required a cooperative effort of the UAC and UAS, the UAS a=des:qos mandatory e2e sendrecv
requests a confirmation when the preconditions are met, with the SDP
entry "a=qos:mandatory sendrecv confirm." The UAS now attempts to
reserve the qos resources and establish the security associations.
The 183-Session-Progress provisional response is sent using the SDP6 in the ACK (11):
reliability mechanism of [11]. UAC sends the appropriate PRACK and
UAS responds with a 200-OK to the PRACK.
The 183-Session-Progress is received by the UAC, and the UAC m=audio 20000 RTP/AVP 0
requests the resources needed in its "send" direction, and c=IN IP4 192.0.2.1
establishes the security associations. Once the preconditions are a=sendrecv
met, the UAC sends a COMET message as requested by the confirmation a=curr:qos e2e sendrecv
token. This COMET message contains an entry "a=qos:success send" a=des:qos mandatory e2e sendrecv
SIP Working Group Expiration 5/31/02 20 Let's assume that in the middle of the session A wishes to change the
SIP Extensions for Resource Management November 2001 A B
Originating (UAC) Terminating (UAS)
| SIP-Proxy(s) |
| INVITE | |
|---------------------->|---------------------->|
| | |
| 183 w/SDP | 183 w/SDP |
|<----------------------|<----------------------|
| | | |
| PRACK | |-------------(1) INVITE SDP1--------------->|
|---------------------------------------------->|
| 200 OK (of PRACK) |
|<----------------------------------------------|
| Reservation Reservation |
===========> <===========
| | | |
|<------(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--------------->|
| | | |
| COMET | |<--------(6) 200 OK (UPDATE) SDP4-----------|
|---------------------------------------------->|
| 200 OK (of COMET) |
|<----------------------------------------------|
|
|
| SIP-Proxy(s) User Alerted
| | |
| 180 Ringing | 180 Ringing |
|<----------------------|<----------------------|
| | | |
| PRACK | |<-------------(7) 180 Ringing---------------|
|---------------------------------------------->| | |
| 200 OK (of PRACK) | |-----------------(8) PRACK----------------->|
|<----------------------------------------------| | |
|<------------(9) 200 OK (PRACK)-------------|
| |
| |
| |
|<-----------(10) 200 OK (INVITE)------------|
| |
|------------------(11) ACK----------------->|
| | | |
| User Picks-Up
| SIP-Proxy(s) the phone
| | |
| 200 OK | 200 OK |
|<----------------------|<----------------------|
| | |
| | | |
| ACK |
|---------------------------------------------->|
Figure 1: Basic Call Flow
The UAS successfully performs its resource reservation, in its
"send" direction, and waits for the COMET message from the UAC.
On receipt of the COMET message, the UAS processes the "send"
confirmation contained in the COMET SDP. The "send" confirmation
from the UAC coupled with its own "send" success, allows the UAS to
determine that all preconditions have been met. The UAS then
continues with session establishment. At this point it alerts the
SIP Working Group Expiration 5/31/02 21
SIP Extensions for Resource Management November 2001
user, and sends a 180-Ringing provisional response. This
provisional response is also sent using the reliability mechanism of
[11], resulting in a PRACK message and 200-OK of the PRACK.
When the destination party answers, the normal SIP 200-OK final
response is sent through the proxies to the originator, and the
originator responds with an ACK message.
Either party can terminate the call. An endpoint that detects an
"on-hook" (request to terminate the call) releases the QoS resources
held for the connection, and sends a SIP BYE message to the remote
endpoint, which is acknowledged with a 200-OK.
12.2 Multiple Media Call Flow
Figure 2 presents a high-level overview of an advanced end-point to
end-point (UAC-UAS) call flow. This example is appropriate for a
multiple-media session with some combination of mandatory and
optional quality-of-service precondition. For example, the
originator may suggest five media streams, and be willing to
establish the session if any three of them are satisfied.
The use of reliable provisional responses is assumed, but not shown
in this figure.
The session originator (UAC) prepares an SDP message body for the
INVITE describing the desired QoS and security preconditions for
each media flow, and the desired directions. UAC also requests
confirmation of the preconditions. The UAS receiving the INVITE
message responds with 183-Session-Progress, as in the previous
example.
When the UAS has completed the resource reservations and security
session establishment, it sends a confirmation to the UAC in the
form of a COMET message, with each precondition marked in the SDP as
either success or failure. Note that if UAS was not satisfied with
the combination of successful preconditions, it could instead have
responded with 580-Precondition-Failure, and ended the INVITE
transaction.
If the UAC has satisfied its preconditions, and is satisfied with
the preconditions achieved by the UAS, it responds with the COMET
message. The COMET message contains the SDP with the
success/failure results of each precondition attempted by UAC. If
UAC is not satisfied with the combination of successful
preconditions, it could instead have sent a CANCEL message.
On receipt of the COMET message, UAS examines the combination of Figure 2: Example using the end-to-end status type
satisfied preconditions reported by UAC, and makes a final decision IP address where it is receiving media. Figure 3 shows this scenario.
whether to proceed with the session. If sufficient preconditions
are not satisfied, the UAS responds with 580-Precondition-Failure.
Otherwise, the session proceeds as in the previous example.
SIP Working Group Expiration 5/31/02 22 A B
SIP Extensions for Resource Management November 2001
Originating (UAC) Terminating (UAS)
| SIP-Proxy(s) |
| INVITE | |
|---------------------->|---------------------->|
| | |
| 183 w/SDP | 183 w/SDP |
|<----------------------|<----------------------|
| | | |
| Reservation Reservation | |-------------(1) INVITE SDP1--------------->|
===========> <===========
| | | |
| COMET | |<------(2) 183 Session Progress SDP 2-------|
|<----------------------------------------------| | *** *** |
| 200 OK (of COMET) | |--*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--------------->|
| | | |
| COMET | |<--------(6) 200 OK (UPDATE) SDP4-----------|
|---------------------------------------------->|
| 200 OK (of COMET) |
|<----------------------------------------------|
|
|
| SIP-Proxy(s) User Alerted
| | |
| 180 Ringing | 180 Ringing |
|<----------------------|<----------------------|
| | | |
|<-----------(7) 200 OK (INVITE)-------------|
| |
|------------------(8) ACK------------------>|
| | | |
| User Picks-Up
| SIP-Proxy(s) the phone
| | |
| 200 OK | 200 OK |
|<----------------------|<----------------------|
| | |
| | | |
| ACK |
|---------------------------------------------->|
Figure 2: Call Flow with negotiation of optional preconditions Figure 3: Session modification with preconditions
13. Special considerations with Forking Proxies SDP1: A includes an offer in a re-INVITE (1). A continues to receive
media on the old IP address (192.0.2.1), but it is ready to receive
media on the new one as well (192.0.2.2):
If a proxy along the signaling path between the UAC and UAS forks m=audio 20000 RTP/AVP 0
the INVITE request, it results in two or more UASs simultaneously c=IN IP4 192.0.2.2
sending provisional responses with preconditions. The procedures a=curr:qos e2e none
above result in the UAC handling each independently, reserving a=des:qos mandatory e2e sendrecv
resources and responding with COMET messages as required.
This results in multiple resource reservations from the UAC, only SDP2: B includes a "confirm" tag in its answer. B continues sending
one of which will be utilized for the final session. While media to the old remote IP address (192.0.2.1)
functionally correct, this has the unfortunate side-effect of
increasing the call blocking probability.
SIP Working Group Expiration 5/31/02 23 m=audio 30000 RTP/AVP 0
SIP Extensions for Resource Management November 2001 c=IN IP4 192.0.2.4
a=curr:qos e2e none
a=des:qos mandatory e2e sendrecv confirm
Customized resource allocation protocols may be used by the UAC to SDP3: When A receives RESV messages it sends an updated offer (5) to
reduce this duplicate allocation and prevent excess blocking of B:
calls. For one such example, see [8].
Other procedures which the UAC has available to handle multiple m=audio 20000 RTP/AVP 0
simultaneously active transactions (e.g. CANCEL, and BYE) are as c=IN IP4 192.0.2.2
given in [2]. a=curr:qos e2e send
a=des:qos mandatory e2e sendrecv
14. Advantages of the Proposed Approach SDP4: B responds with an answer (6) indicating that the preconditions
have been met (current status "sendrecv). It is now when B begins
sending media to the new remote IP address (192.0.2.2).
The use of two-phase call signaling makes it possible for SIP to m=audio 30000 RTP/AVP 0
meet user expectations that come from the telephony services. c=IN IP4 192.0.2.4
a=curr:qos e2e sendrecv
a=des:qos mandatory e2e sendrecv
The reservation of resources before the user is alerted makes sure 10.2 Segmented Status Type
that the network resources are assured before the destination end-
point is informed about the call.
The number of messages and the total delay introduced by these The call flow of figure 4 shows a basic session establishment using
messages is kept to a minimum without sacrificing compatibility with the segmented status type. The SDP descriptions of this example are
SIP servers that do not implement preconditions. shown below:
15. Security Considerations SDP1: B includes local and remote QoS preconditions in the initial
offer. Before sending the initial offer, A reserves resources in its
access network. This is indicated in the local current status of the
SDP below:
If the contents of the SDP contained in the 183-Session-Progress are m=audio 20000 RTP/AVP 0 8
private then end-to-end encryption of the message body can be used c=IN IP4 192.0.2.1
to prevent unauthorized access to the content. a=curr:qos local sendrecv
a=curr:qos remote none
a=des:qos mandatory local sendrecv
a=des:qos mandatory remote sendrecv
The security considerations given in the SIP specification apply to SDP2: B reserves resources in its access network and, since all the
the COMET method. No additional security considerations specific to preconditions are met, returns an answer in a 180 (Ringing) response
the COMET method are necessary. (3).
16. Notice Regarding Intellectual Property Rights 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
The IETF has been notified of intellectual property rights claimed Let's assume that after receiving this response A decides that it
in regard to some or all of the specification contained in this wants to use only PCM u-law (payload 0), as opposed to both PCM u-law
document. For more information consult the online list of claimed and A-law (payload 8). It would send an UPDATE to B possibly before
rights. receiving the 200 OK for the INVITE (5). The SDP would look like:
17. References m=audio 20000 RTP/AVP 0
c=IN IP4 192.0.2.1
a=curr:qos local sendrecv
a=curr:qos remote sendrecv
a=des:qos mandatory local sendrecv
a=des:qos mandatory remote sendrecv
1. Bradner, S., "The Internet Standards Process -- Revision 3", BCP B would generate an answer for this offer and place it in the 200 OK
9, RFC 2026, October 1996. for the UPDATE.
2. M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP: Note that this last offer/answer to reduce the number of supported
Session Initiation Protocol," RFC 2543, March 1999. codecs may arrive to the user agent server after the 200 OK response
has been generated. This would mean that the session is established
before A has reduced the number of supported codecs. To avoid this
situation, the user agent client could wait for the first answer from
the user agent before setting its local current status to "sendrecv".
3. M. Handley and V. Jacobson, "SDP: Session Description Protocol," 11 Security Considerations
RFC 2327, April 1998.
4. Bradner, S., "Key words for use in RFCs to Indicate Requirement An entity in the middle of two user agents establishing a session may
Levels", BCP 14, RFC 2119, March 1997 add desired-status attributes making session establishment
impossible. It could also modify the content of the current-status
parameters so that the session is established without meeting the
preconditions. Integrity protection can be used to avoid this
attacks.
SIP Working Group Expiration 5/31/02 24 A B
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 | *R* |
specification," RFC 2205, September, 1997. | *E* |
| *S* |
| *E* |
| *R* |
| *V* |
| *A* |
| *T* |
| *I* |
| *O* |
| *N* |
| *** |
|-------------(1) INVITE SDP1--------------->|
| *** |
| *R* |
| *E* |
| *S* |
| *E* |
| *R* |
| *V* |
| *A* |
| *T* |
| *I* |
| *O* |
| *N* |
| *** |
|<----------(2) 180 Ringing SDP2-------------|
| |
|----------------(3) PRACK------------------>|
| |
|<-----------(4) 200 OK (PRACK)--------------|
| |
| |
|<-----------(5) 200 OK (INVITE)-------------|
| |
|------------------(6) ACK------------------>|
| |
| |
6. P. P. Pan and H. Schulzrinne, "YESSIR: A simple reservation Figure 4: Example using the segmented status type
mechanism for the Internet," 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- An entity performing resource reservations upon reception of
dqos-i01-991201, December 1, 1999. Available at unathenticated requests carrying preconditions can be an easy target
http://www.packetcable.com/specs/pkt-sp-dqos-i01-991202.pdf. for a denial of service attack. Requests with preconditions SHOULD be
8. S. Kent and R. Atkinson, "Security architecture for the internet 12 IANA considerations
protocol," RFC 2401, November 1998.
9. H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: a This document defines three media level SDP attributes: desired-
Transport Protocol for Real-Time Applications," RFC 1889, January status, current-status and conf-status. Their format is defined in
1996. Section 4.
10. M. Handley, C. Perkins, and E. Whelan, "Session Announcement Section 4 also one standard precondition-type related to the
Protocol," RFC2974, October, 2000. attributes above: "qos". If in the future it was needed to
standardize further precondition-types, they would need to be defined
in a standards track document.
11. "Reliability of Provisional Responses in SIP," RFC pending. This document also defines a new SIP status code (580). Its default
reason phrase (Precondition Failure) is defined in section 8.
12. "The SIP Supported Header," RFC pending. 13 Contributors
18. Acknowledgments The following persons contributed to early versions of this spec:
The Distributed Call Signaling work in the PacketCable project is K. K. Ramakrishnan (TeraOptic Networks), Ed Miller (Terayon), Glenn
the work of a large number of people, representing many different 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. 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 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.
19. Author's Addresses 15 Authors' Addresses
Gonzalo Camarillo
Ericsson
Advanced Signalling Research Lab.
FIN-02420 Jorvas
Finland
electronic mail: Gonzalo.Camarillo@ericsson.com
Bill Marshall Bill Marshall
AT&T AT&T
Florham Park, NJ 07932 Florham Park, NJ 07932
Email: wtm@research.att.com USA
electronic mail: wtm@research.att.com
K. K. Ramakrishnan
SIP Working Group Expiration 5/31/02 25
SIP Extensions for Resource Management November 2001
TeraOptic Networks
Sunnyvale, CA
Email: kk@teraoptic.com
Ed Miller
Terayon
Louisville, CO 80027
Email: E.Miller@terayon.com
Glenn Russell
CableLabs
Louisville, CO 80027
Email: G.Russell@Cablelabs.com
Burcak Beser
Pacific Broadband Communications
San Jose, CA
Email: Burcak@pacband.com
Mike Mannette
3Com
Rolling Meadows, IL 60008
Email: Michael_Mannette@3com.com
Kurt Steinbrenner
3Com
Rolling Meadows, IL 60008
Email: Kurt_Steinbrenner@3com.com
Dave Oran
Cisco
Acton, MA 01720
Email: oran@cisco.com
Flemming Andreasen
Cisco
Edison, NJ
Email: fandreas@cisco.com
Michael Ramalho
Cisco
Wall Township, NJ
Email: mramalho@cisco.com
John Pickens
Com21
San Jose, CA
Email: jpickens@com21.com
Poornima Lalwaney
Nokia
San Diego, CA 92121
Email: poornima.lalwaney@nokia.com
SIP Working Group Expiration 5/31/02 26
SIP Extensions for Resource Management November 2001
Jon Fellows
Copper Mountain Networks
San Diego, CA 92121
Email: jfellows@coppermountain.com
Doc Evans
D. R. Evans Consulting
Boulder, CO 80303
Email: n7dr@arrl.net
Keith Kelly
NetSpeak
Boca Raton, FL 33587
Email: keith@netspeak.com
Adam Roach
Ericsson
Richardson, TX 75081
Email: adam.roach@ericsson.com
Jonathan Rosenberg Jonathan Rosenberg
dynamicsoft dynamicsoft
West Orange, NJ 07052 West Orange, NJ 07052
Email: jdrosen@dynamicsoft.com USA
electronic mail: jdrosen@dynamicsoft.com
Dean Willis 16 Bibliography
dynamicsoft
West Orange, NJ 07052
Email: dwillis@dynamicsoft.com
Steve Donovan [1] J. Rosenberg, H. Schulzrinne, et al. , "SIP: Session initiation
dynamicsoft protocol," Internet Draft, Internet Engineering Task Force, Feb.
West Orange, NJ 07052 2002. Work in progress.
Email: sdonovan@dynamicsoft.com
Henning Schulzrinne [2] M. Handley and V. Jacobson, "SDP: session description protocol,"
Columbia University Request for Comments 2327, Internet Engineering Task Force, Apr.
New York, NY 1998.
Email: schulzrinne@cs.columbia.edu
SIP Working Group Expiration 5/31/02 27 [3] S. Bradner, "Key words for use in RFCs to indicate requirement
SIP Extensions for Resource Management November 2001 levels," Request for Comments 2119, Internet Engineering Task Force,
Mar. 1997.
[4] J. Rosenberg and H. Schulzrinne, "An offer/answer model with
SDP," Internet Draft, Internet Engineering Task Force, Jan. 2002.
Work in progress.
[5] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: a
transport protocol for real-time applications," Request for Comments
1889, Internet Engineering Task Force, Jan. 1996.
[6] J. Rosenberg and H. Schulzrinne, "Reliability of provisional
responses in SIP," Internet Draft, Internet Engineering Task Force,
Sept. 2001. Work in progress.
Full Copyright Statement Full Copyright Statement
"Copyright (C) The Internet Society (2000). All Rights Reserved. Copyright (c) The Internet Society (2002). 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 implementation 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
are included on all such copies and derivative works. However, this 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.
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- The limited permissions granted above are perpetual and will not be
resource-03.txt>, and expires May 31, 2002. revoked by the Internet Society or its successors or assigns.
SIP Working Group Expiration 5/31/02 28 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.
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.
 End of changes. 

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