draft-ietf-sip-manyfolks-resource-07.txt   rfc3312.txt 
Internet Engineering Task Force SIP WG Network Working Group G. Camarillo, Ed.
Internet Draft G. Camarillo (Editor) Request for Comments: 3312 Ericsson
Ericsson Category: Standards Track W. Marshall, Ed.
W. Marshall (Editor)
AT&T AT&T
Jonathan Rosenberg J. Rosenberg
dynamicsoft dynamicsoft
draft-ietf-sip-manyfolks-resource-07.txt October 2002
April 8, 2002
Expires: September, 2002
Integration of Resource Management and SIP
STATUS OF THIS MEMO
This document is an Internet-Draft and is in full conformance with Integration of Resource Management
all provisions of Section 10 of RFC2026. and Session Initiation Protocol (SIP)
Internet-Drafts are working documents of the Internet Engineering Status of this Memo
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months This document specifies an Internet standards track protocol for the
and may be updated, replaced, or obsoleted by other documents at any Internet community, and requests discussion and suggestions for
time. It is inappropriate to use Internet-Drafts as reference improvements. Please refer to the current edition of the "Internet
material or to cite them other than as "work in progress". Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
The list of current Internet-Drafts can be accessed at Copyright Notice
http://www.ietf.org/ietf/1id-abstracts.txt
To view the list Internet-Draft Shadow Directories, see Copyright (C) The Internet Society (2002). All Rights Reserved.
http://www.ietf.org/shadow.html.
Abstract Abstract
This document defines a generic framework for preconditions which is This document defines a generic framework for preconditions, which
extensible through IANA registration. This document also discusses are extensible through IANA registration. This document also
how network quality of service can be made a precondition to discusses how network quality of service can be made a precondition
establishment of sessions initiated by the Session Initiation for establishment of sessions initiated by the Session Initiation
Protocol (SIP). These preconditions require that the participant Protocol (SIP). These preconditions require that the participant
reserve network resources before continuing with the session. We do reserve network resources before continuing with the session. We do
not define new quality of service reservation mechanisms; these not define new quality of service reservation mechanisms; these
preconditions simply require a participant to use existing resource preconditions simply require a participant to use existing resource
reservation mechanisms before beginning the session. reservation mechanisms before beginning the session.
Table of Contents Table of Contents
1 Introduction ........................................ 3 1 Introduction ................................................... 2
2 Terminology ......................................... 3 2 Terminology .................................................... 3
3 Overview ............................................ 3 3 Overview ....................................................... 3
4 SDP parameters ...................................... 4 4 SDP parameters ................................................. 4
5 Usage of preconditions with offer/answer ............ 7 5 Usage of preconditions with offer/answer ....................... 7
5.1 Generating an offer ................................. 8 5.1 Generating an offer .......................................... 8
5.1.1 SDP encoding ........................................ 9 5.1.1 SDP encoding ............................................... 9
5.2 Generating an Answer ................................ 10 5.2 Generating an Answer ......................................... 10
6 Suspending and Resuming Session Establishment ....... 12 6 Suspending and Resuming Session Establishment .................. 11
7 Status Confirmation ................................. 13 7 Status Confirmation ............................................ 12
8 Refusing an offer ................................... 14 8 Refusing an offer .............................................. 13
8.1 Rejecting a Media Stream ............................ 15 8.1 Rejecting a Media Stream ..................................... 14
9 Unknown Precondition Type ........................... 15 9 Unknown Precondition Type ...................................... 15
10 Option Tag for Preconditions ........................ 16 10 Multiple Preconditions per Media Stream ....................... 15
11 Indicating Capabilities ............................. 16 11 Option Tag for Preconditions .................................. 16
12 Examples ............................................ 16 12 Indicating Capabilities ....................................... 16
12.1 End-to-end Status Type .............................. 17 13 Examples ...................................................... 16
12.2 Segmented Status Type ............................... 22 13.1 End-to-end Status Type ...................................... 17
12.3 Offer in a SIP response ............................. 23 13.2 Segmented Status Type ....................................... 21
13 Security Considerations ............................. 26 13.3 Offer in a SIP response ..................................... 23
14 IANA considerations ................................. 26 14 Security Considerations ....................................... 26
15 Contributors ........................................ 27 15 IANA Considerations ........................................... 26
16 Acknowledgments ..................................... 27 16 Notice Regarding Intellectual Property Rights ................. 27
17 Authors' Addresses .................................. 28 17 References .................................................... 27
18 Bibliography ........................................ 28 18 Contributors .................................................. 28
19 Acknowledgments ............................................... 28
20 Authors' Addresses ............................................ 29
21 Full Copyright Statement ...................................... 30
1 Introduction 1 Introduction
Some architectures require that at session establishment time, once Some architectures require that at session establishment time, once
the callee has been alerted, the chances of a session establishment the callee has been alerted, the chances of a session establishment
failure are minimum. One source of failure is the inability to failure are minimum. One source of failure is the inability to
reserve network resources for a session. In order to minimize "ghost reserve network resources for a session. In order to minimize "ghost
rings", it is necessary to reserve network resources for the session rings", it is necessary to reserve network resources for the session
before the callee is alerted. However, the reservation of network before the callee is alerted. However, the reservation of network
resources frequently requires learning the IP address, port, and resources frequently requires learning the IP address, port, and
session parameters from the callee. This information is obtained as a session parameters from the callee. This information is obtained as
result of the initial offer/answer exchange carried in SIP. This a result of the initial offer/answer exchange carried in SIP. This
exchange normally causes the "phone to ring", thus introducing a exchange normally causes the "phone to ring", thus introducing a
chicken-and-egg problem: resources cannot be reserved without chicken-and-egg problem: resources cannot be reserved without
performing an initial offer/answer exchange, and the initial performing an initial offer/answer exchange, and the initial
offer/answer exchange can't be done without performing resource offer/answer exchange can't be done without performing resource
reservation. reservation.
The solution is to introduce the concept of a precondition. A The solution is to introduce the concept of a precondition. A
precondition is a set of constraints about the session which are precondition is a set of constraints about the session which are
introduced in the offer. The recipient of the offer generates an introduced in the offer. The recipient of the offer generates an
answer, but does not alert the user or otherwise proceed with session answer, but does not alert the user or otherwise proceed with session
establishment. That only occurs when the preconditions are met. This establishment. That only occurs when the preconditions are met.
can be known through a local event (such as a confirmation of a This can be known through a local event (such as a confirmation of a
resource reservation), or through a new offer sent by the caller. resource reservation), or through a new offer sent by the caller.
This document deals with sessions that use SIP [1] as signalling This document deals with sessions that use SIP [1] as a signalling
protocol and SDP [2] to describe the parameters of the session. protocol and SDP [2] to describe the parameters of the session.
We have chosen to include the quality of service preconditions in the We have chosen to include the quality of service preconditions in the
SDP description rather than in the SIP header because preconditions SDP description rather than in the SIP header because preconditions
are stream specific. are stream specific.
2 Terminology 2 Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [3]. document are to be interpreted as described in BCP 14, RFC 2119 [3].
3 Overview 3 Overview
In order to ensure that session establishment does not take place In order to ensure that session establishment does not take place
until certain preconditions are met we distinguish between two until certain preconditions are met, we distinguish between two
different state variables that affect a particular media stream: different state variables that affect a particular media stream:
current status and desired status. This document defines quality of current status and desired status. This document defines the quality
service status. of service status.
The desired status consists of a threshold for the current status. The desired status consists of a threshold for the current status.
Session establishment stops until the current status reaches or Session establishment stops until the current status reaches or
surpasses this threshold. Once this threshold is reached or surpasses this threshold. Once this threshold is reached or
surpassed, session establishment resumes. surpassed, session establishment resumes.
For example, the following values for current and desired status For example, the following values for current and desired status
would not allow session establishment to resume: would not allow session establishment to resume:
current status = resources reserved in the send direction current status = resources reserved in the send direction
desired status = resources reserved in both (sendrecv) directions desired status = resources reserved in both (sendrecv) directions
On the other hand, the values of the example below would make session On the other hand, the values of the example below would make session
establishment resume: establishment resume:
current status = resources reserved in both (sendrecv) directions current status = resources reserved in both (sendrecv) directions
desired status = resources reserved in the send direction desired status = resources reserved in the send direction
These two state variables define a certain piece of state of a media These two state variables define a certain piece of state of a media
stream the same way as the direction attribute or the codecs in use, stream the same way the direction attribute or the codecs in use
define other pieces of state. Consequently, we treat these two new define other pieces of state. Consequently, we treat these two new
variables in the same way as other SDP media attributes are treated 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 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 two user agents using an offer and an answer in order to have a
shared view of the status of the session. shared view of the status of the session.
Figure 1 shows a typical message exchange between two SIP user agents Figure 1 shows a typical message exchange between two SIP user agents
using preconditions. A includes quality of service preconditions in using preconditions. A includes quality of service preconditions in
the SDP of the initial INVITE. A does not want B to be alerted until the SDP of the initial INVITE. A does not want B to be alerted until
there is network resources reserved in both directions (sendrecv) there are network resources reserved in both directions (sendrecv)
end-to-end. B agrees to reserve network resources for this session end-to-end. B agrees to reserve network resources for this session
before alerting the callee. B will handle resource reservation in the before alerting the callee. B will handle resource reservation in
B->A direction, but needs A to handle the A->B direction. To indicate the B->A direction, but needs A to handle the A->B direction. To
so, B returns a 183 (Session Progress) response to A asking A to indicate so, B returns a 183 (Session Progress) response to A asking
start resource reservation and to confirm to B as soon as the A->B A to start resource reservation and to confirm to B as soon as the
direction is ready for the session. A and B both start resource A->B direction is ready for the session. A and B both start resource
reservation. B finishes reserving resources in the B->A direction, reservation. B finishes reserving resources in the B->A direction,
but does not alert the user yet, because network resources in both but does not alert the user yet, because network resources in both
directions are needed. When A finishes reserving resources in the A- directions are needed. When A finishes reserving resources in the
>B direction, it sends an UPDATE [5] to B. B returns a 200 (OK) A->B direction, it sends an UPDATE [5] to B. B returns a 200 (OK)
response for the UPDATE indicating that all the preconditions for the response for the UPDATE, indicating that all the preconditions for
session have been met. At this point of time, B starts alerting the the session have been met. At this point in time, B starts alerting
user, and session establishment completes normally. the user, and session establishment completes normally.
4 SDP parameters 4 SDP parameters
We define the following media level SDP attributes: We define the following media level SDP attributes:
current-status = "a=curr:" precondition-type current-status = "a=curr:" precondition-type
SP status-type SP direction-tag SP status-type SP direction-tag
desired-status = "a=des:" precondition-type desired-status = "a=des:" precondition-type
SP strength-tag SP status-type SP strength-tag SP status-type
SP direction-tag SP direction-tag
confirm-status = "a=conf:" precondition-type confirm-status = "a=conf:" precondition-type
SP status-type SP direction-tag SP status-type SP direction-tag
precondition-type = "qos" | token precondition-type = "qos" | token
strength-tag = ("mandatory" | "optional" | "none" strength-tag = ("mandatory" | "optional" | "none"
= | "failure" | "unknown") = | "failure" | "unknown")
status-type = ("e2e" | "local" | "remote") status-type = ("e2e" | "local" | "remote")
direction-tag = ("none" | "send" | "recv" | "sendrecv") direction-tag = ("none" | "send" | "recv" | "sendrecv")
Current status: The current status attribute carries the current Current status: The current status attribute carries the current
status of network resources for a particular media stream. status of network resources for a particular media stream.
Desired status: The desired status attribute carries the Desired status: The desired status attribute carries the
preconditions for a particular media stream. When the preconditions for a particular media stream. When the
direction-tag of the current status attribute with a given direction-tag of the current status attribute, with a given
precondition-type/status-type for a particular stream is precondition-type/status-type for a particular stream is
equal to (or better than) the direction-tag of the desired equal to (or better than) the direction-tag of the desired
status attribute with the same precondition-type/status- status attribute with the same precondition-type/status-
type for that stream, then the preconditions are considered type, for that stream, then the preconditions are considered
to be met for that stream. to be met for that stream.
Confirmation status: The confirmation status attribute carries Confirmation status: The confirmation status attribute carries
threshold conditions for a media stream. When the status of threshold conditions for a media stream. When the status of
network resources reach these conditions, the peer user network resources reach these conditions, the peer user
agent will send an update of the session description agent will send an update of the session description
containing an updated current status attribute for this containing an updated current status attribute for this
particular media stream. particular media stream.
Precondition type: This document defines quality of service Precondition type: This document defines quality of service
preconditions. Extensions may define other types of preconditions. Extensions may define other types of
preconditions. preconditions.
Strength tag: The strength-tag indicates whether or not the Strength tag: The strength-tag indicates whether or not the callee
callee can be alerted in case the network fails to meet the can be alerted, in case the network fails to meet the
preconditions. preconditions.
Status type: We define two types of status: end-to-end and Status type: We define two types of status: end-to-end and
segmented. The end-to-end status reflects the status of the segmented. The end-to-end status reflects the status of the
end-to-end reservation of resources. The segmented status end-to-end reservation of resources. The segmented status
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 are available.
The segmented status is useful when one or both UAs perform
resource reservations on their respective access networks.
A B A B
| | | |
|-------------(1) INVITE SDP1--------------->| |-------------(1) INVITE SDP1--------------->|
| | | |
|<------(2) 183 Session Progress SDP 2-------| |<------(2) 183 Session Progress SDP2--------|
| *** *** | | *** *** |
|--*R*-----------(3) PRACK-------------*R*-->| |--*R*-----------(3) PRACK-------------*R*-->|
| *E* *E* | | *E* *E* |
|<-*S*-------(4) 200 OK (PRACK)--------*S*---| |<-*S*-------(4) 200 OK (PRACK)--------*S*---|
| *E* *E* | | *E* *E* |
| *R* *R* | | *R* *R* |
| *V* *V* | | *V* *V* |
| *A* *A* | | *A* *A* |
| *T* *T* | | *T* *T* |
| *I* *I* | | *I* *I* |
| *O* *O* | | *O* *O* |
| *N* *N* | | *N* *N* |
| *** *** | | *** *** |
| *** | | *** |
| *** | | *** |
|-------------(5) UPDATE SDP3--------------->| |-------------(5) UPDATE SDP3--------------->|
| | | |
|<--------(6) 200 OK (UPDATE) SDP4-----------| |<--------(6) 200 OK (UPDATE) SDP4-----------|
| | | |
|<-------------(7) 180 Ringing---------------| |<-------------(7) 180 Ringing---------------|
| | | |
|-----------------(8) PRACK----------------->| |-----------------(8) PRACK----------------->|
| | | |
|<------------(9) 200 OK (PRACK)-------------| |<------------(9) 200 OK (PRACK)-------------|
| | | |
| | | |
| | | |
|<-----------(10) 200 OK (INVITE)------------| |<-----------(10) 200 OK (INVITE)------------|
| | | |
|------------------(11) ACK----------------->| |------------------(11) ACK----------------->|
| | | |
| | | |
Figure 1: Basic session establishment using preconditions Figure 1: Basic session establishment using preconditions
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 are available.
The segmented status is useful when one or both UAs perform
resource reservations on their respective access networks.
Direction tag: The direction-tag indicates the direction a Direction tag: The direction-tag indicates the direction in which
particular attribute (current, desired or confirmation a particular attribute (current, desired or confirmation
status) is applicable to. status) is applicable to.
The values of the tags "send", "recv", "local" and "remote" represent The values of the tags "send", "recv", "local" and "remote" represent
the point of view of the entity generating the SDP description. In an the point of view of the entity generating the SDP description. In
offer, "send" is the direction offerer->answerer and "local" is the an offer, "send" is the direction offerer->answerer and "local" is
offerer's access network. In an answer, "send" is the direction the offerer's access network. In an answer, "send" is the direction
answerer->offerer and "local" is the answerer's access network. answerer->offerer and "local" is the answerer's access network.
The following example shows these new SDP attributes in two media The following example shows these new SDP attributes in two media
lines of a session description: lines of a session description:
m=audio 20000 RTP/AVP 0 m=audio 20000 RTP/AVP 0
a=curr:qos e2e send a=curr:qos e2e send
a=des:qos optional e2e send a=des:qos optional e2e send
a=des:qos mandatory e2e recv a=des:qos mandatory e2e recv
m=audio 20002 RTP/AVP 0 m=audio 20002 RTP/AVP 0
a=curr:qos local sendrecv a=curr:qos local sendrecv
a=curr:qos remote none a=curr:qos remote none
a=des:qos optional local sendrecv a=des:qos optional local sendrecv
a=des:qos mandatory remote sendrecv a=des:qos mandatory remote sendrecv
5 Usage of preconditions with offer/answer 5 Usage of preconditions with offer/answer
Parameter negotiation in SIP is carried out using the offer/answer Parameter negotiation in SIP is carried out using the offer/answer
model described in [4]. The idea behind this model is to provide a model described in [4]. The idea behind this model is to provide a
shared view of the session parameters for both user agents once the shared view of the session parameters for both user agents once the
answer has been received by the offerer. This section describes which answer has been received by the offerer. This section describes
values our new SDP attributes can take in an answer depending on which values our new SDP attributes can take in an answer, depending
their value in the offer. on their value in the offer.
To achieve a shared view of the status of a media stream, we define a 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 model that consists of three tables: both user agents implement a
local status table, and each offer/answer exchange has a transaction local status table, and each offer/answer exchange has a transaction
status table associated to it. The offerer generates 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 status table, identical to its local status table, and sends it to
answerer in the offer. The anwerer uses the information of this the answerer in the offer. The answerer uses the information of this
transaction status table to update its local status table. The transaction status table to update its local status table. The
answerer also updates the transaction status table fields that were answerer also updates the transaction status table fields that were
out of date and returns this table to the offerer in the answer. The 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 offerer can then update its local status table with the information
received in the answer. After this offer/answer exchange, the local received in the answer. After this offer/answer exchange, the local
status tables of both user agents are synchronised. They now have a status tables of both user agents are synchronised. They now have a
common view of the status of the media stream. Sessions that involve common view of the status of the media stream. Sessions that involve
several media streams implement these tables per media stream. Note, several media streams implement these tables per media stream. Note,
however, that this is a model of user agent behavior, not of however, that this is a model of user agent behavior, not of
software. An implementation is free to take any approach that software. An implementation is free to take any approach that
replicates the external behavior this model defines. replicates the external behavior this model defines.
5.1 Generating an offer 5.1 Generating an offer
Both user agents MUST maintain local precondition status, which is Both user agents MUST maintain a local precondition status, which is
referred to as a "local status table". Tables 1 and 2 show the format referred to as a "local status table". Tables 1 and 2 show the
of these tables for both the end-to-end and the segmented status format of these tables for both the end-to-end and the segmented
types. For the end-to-end status type, the table contains two rows; status types. For the end-to-end status type, the table contains two
one for each direction (i.e., send and recv). A value of "yes" in the rows; one for each direction (i.e., send and recv). A value of "yes"
"Current" field indicates that resource has been successfully in the "Current" field indicates the successful reservation of that
reserved in the corresponding direction. "No" indicates that resource in the corresponding direction. "No" indicates that
resources have not been reserved yet. The "Desired Strength" field resources have not been reserved yet. The "Desired Strength" field
indicates the strength of the preconditions in the corresponding indicates the strength of the preconditions in the corresponding
direction. The table for the segmented status type contains four direction. The table for the segmented status type contains four
rows: both directions in the local access network and in the peer's 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- access network. The meaning of the fields is the same as in the
to-end case. end-to-end case.
Before generating an offer, the offerer MUST build a transaction Before generating an offer, the offerer MUST build a transaction
status table with the current and the desired status for each media status table with the current and the desired status, for each media
stream. The different values of the strength-tag for the desired stream. The different values of the strength-tag for the desired
status attribute have the following semantics: status attribute have the following semantics:
o None: no resource reservation is needed. o None: no resource reservation is needed.
o Optional: the user agents SHOULD try to provide resource o Optional: the user agents SHOULD try to provide resource
reservation, but the session can continue regardless of reservation, but the session can continue regardless of whether
whether this provision is possible or not. or not this provision is possible.
o Mandatory: the user agents MUST provide resource reservation. o Mandatory: the user agents MUST provide resource reservation.
Otherwise, session establishment MUST NOT continue. Otherwise, session establishment MUST NOT continue.
The offerer then decides whether it is going to use the end-to-end 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 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 media line will be end-to-end, the user agent generates records with
the desired status and the current status for each direction (send the desired status and the current status for each direction (send
and recv) independently, as shown in table 1: and recv) independently, as shown in table 1:
Direction Current Desired Strength Direction Current Desired Strength
____________________________________ ____________________________________
send no mandatory send no mandatory
recv no mandatory recv no mandatory
Table 1: Table for the end-to-end status type Table 1: Table for the end-to-end status type
If the status type of the media line will be segmented, the user If the status type of the media line will be segmented, the user
agent generates records with the desired status and the current agent generates records with the desired status and the current
status for each direction (send and recv) and each segment (local and status for each direction (send and recv) and each segment (local and
remote) independently, as shown in table 2: remote) independently, as shown in table 2:
Direction Current Desired Strength Direction Current Desired Strength
______________________________________ ______________________________________
local send no none local send no none
local recv no none local recv no none
remote send no optional remote send no optional
remote recv no none remote recv no none
Table 2: Table for the segmented status type Table 2: Table for the segmented status type
At the time of sending the offer, the offerer's local status table At the time of sending the offer, the offerer's local status table
and the transaction status table contain the same values. and the transaction status table contain the same values.
With the transaction status table, the user agent MUST generate the With the transaction status table, the user agent MUST generate the
current-status and the desired status lines following the syntax of current-status and the desired status lines, following the syntax of
Section 4 and the rules described below in Section 5.1.1. Section 4 and the rules described below in Section 5.1.1.
5.1.1 SDP encoding 5.1.1 SDP encoding
For the end-to-end status type, the user agent MUST generate one 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 current status line with the tag "e2e" for the media stream. If the
strength-tags for both directions are equal (e.g., both "mandatory") strength-tags for both directions are equal (e.g., both "mandatory")
in the transaction status table, the user agent MUST add one desired in the transaction status table, the user agent MUST add one desired
status line with the tag "sendrecv". If both tags are different, the status line with the tag "sendrecv". If both tags are different, the
user agent MUST include two desired status lines, one with the tag user agent MUST include two desired status lines, one with the tag
"send" and the other with the tag "recv". "send" and the other with the tag "recv".
The semantics of two lines with the same strength-tag, one The semantics of two lines with the same strength-tag, one with a
with a "send" tag and the other with a "recv" tag, is the "send" tag and the other with a "recv" tag, is the same as one
same as one "sendrecv" line. However, in order to achieve a "sendrecv" line. However, in order to achieve a more compact
more compact encoding, we have chosen to make mandatory the encoding, we have chosen to make the latter format mandatory.
latter format.
For the segmented status type, the user agent MUST generate two For the segmented status type, the user agent MUST generate two
current status lines: one with the tag "local" and the other with the 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 tag "remote". The user agent MUST add one or two desired status
per segment (i.e., local and remote). If for a particular segment lines per segment (i.e., local and remote). If, for a particular
(local or remote) the tags for both directions in the transaction segment (local or remote), the tags for both directions in the
status table are equal (e.g., both "mandatory"), the user agent MUST transaction status table are equal (e.g., both "mandatory"), the user
add one desired status line with the tag "sendrecv". If both tags are agent MUST add one desired status line with the tag "sendrecv". If
different, the user agent MUST include two desired status lines, one both tags are different, the user agent MUST include two desired
with the tag "send" and the other with the tag "recv". status lines, one with the tag "send" and the other with the tag
"recv".
Note that the rules above apply to the desired strength-tag "none" as 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 well. This way, a user agent that supports quality of service but
does not intend to use them, adds desired status lines with the 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 strength-tag "none". Since this tag can be upgraded in the answer,
described in Section 5.2, the answerer can request quality of service as described in Section 5.2, the answerer can request quality of
reservation without a need of another offer/answer exchange. service reservation without a need of another offer/answer exchange.
The example below shows the SDP corresponding to tables 1 and 2. The example below shows the SDP corresponding to tables 1 and 2.
m=audio 20000 RTP/AVP 0 m=audio 20000 RTP/AVP 0
a=curr:qos e2e none a=curr:qos e2e none
a=des:qos mandatory e2e sendrecv a=des:qos mandatory e2e sendrecv
m=audio 20002 RTP/AVP 0 m=audio 20002 RTP/AVP 0
a=curr:qos local none a=curr:qos local none
a=curr:qos remote none a=curr:qos remote none
a=des:qos optional remote send a=des:qos optional remote send
a=des:qos optional local none a=des:qos none remote recv
a=des:qos none local sendrecv
5.2 Generating an Answer 5.2 Generating an Answer
When the answerer receives the offer, it recreates the transaction When the answerer receives the offer, it recreates the transaction
status table using the SDP attributes contained in the offer. The status table using the SDP attributes contained in the offer. The
answerer updates both its local status and the transaction status answerer updates both its local status and the transaction status
table following the rules below: table following the rules below:
Desired Strength: We define an absolute ordering for the Desired Strength: We define an absolute ordering for the
strength-tags: "none", "optional" and "mandatory". strength-tags: "none", "optional" and "mandatory".
"Mandatory" is the tag with highest grade and "none" the "Mandatory" is the tag with the highest grade and "none" the
tag with lowest grade. An answerer MAY upgrade the desired tag with the lowest grade. An answerer MAY upgrade the
strength in any entry of the transaction status table, but desired strength in any entry of the transaction status
it MUST NOT downgrade it. Therefore, it is OK to upgrade a table, but it MUST NOT downgrade it. Therefore, it is OK to
row from "none" to "optional", from "none" to "mandatory" upgrade a row from "none" to "optional", from "none" to
or from "optional" to "mandatory", but not the other way "mandatory", or from "optional" to "mandatory", but not the
around. other way around.
Current Status: For every row, the value of the "Current" field Current Status: For every row, the value of the "Current" field in
in the transaction status table and in the local status the transaction status table, and in the local status table
table of the answerer have to be compared. Table 3 shows of the answerer, have to be compared. Table 3 shows the
the four possible combinations. If both fields have the four possible combinations. If both fields have the same
same value (two first rows of table 3, nothing needs to be value (two first rows of table 3), nothing needs to be
updated. If the "Current" field of the transaction status updated. If the "Current" field of the transaction status
table is "Yes" and the field of the local status table is table is "Yes", and the field of the local status table is
"No" (third row of table 3), the latter MUST be set to "No" (third row of table 3), the latter MUST be set to
"Yes". If the "Current" field of the transaction status "Yes". If the "Current" field of the transaction status
table is "No" and the field of the local status table is table is "No", and the field of the local status table is
"Yes" (forth row of table 3), the answerer needs to check "Yes" (forth row of table 3), the answerer needs to check if
if it has local information (e.g., a confirmation of a it has local information (e.g., a confirmation of a resource
resource reservation has been received) about that reservation has been received) about that particular current
particular current status. If it does, the "Current" field status. If it does, the "Current" field of the transaction
of the transaction status table is set to "Yes". If the status table is set to "Yes". If the answerer does not have
answerer does not have local information about that current local information about that current status, the "Current"
status, the "Current" field of the local status table MUST field of the local status table MUST be set to "No".
be set to "No".
Transac. status table Local status table New values transac./local Transac. status table Local status table New values transac./local
____________________________________________________________________ ____________________________________________________________________
no no no/no no no no/no
yes yes yes/yes yes yes yes/yes
yes no yes/yes yes no yes/yes
no yes depends on local info no yes depends on local info
Table 3: Possible values for the "Current" fields Table 3: Possible values for the "Current" fields
Once both tables have been updated, an answer MUST be generated Once both tables have been updated, an answer MUST be generated
following the rules described in Section 5.1.1 and taking into following the rules described in Section 5.1.1, taking into account
account that "send", "recv", "local" and "remote" tags have to be that "send", "recv", "local" and "remote" tags have to be inverted in
inverted in the answer, as shown in table 4. the answer, as shown in table 4.
Offer Answer Offer Answer
______________ ______________
send recv send recv
recv send recv send
local remote local remote
remote local remote local
Table 4: Values of tags in offers and answers Table 4: Values of tags in offers and answers
At the time the answer is sent, the transaction status table and the At the time the answer is sent, the transaction status table and the
answerer's local status table contain the same values. Therefore, answerer's local status table contain the same values. Therefore,
this answer contains the shared view of the status of the media line this answer contains the shared view of the status of the media line
in the current-status attribute and the negotiated strength and in the current-status attribute and the negotiated strength and
direction-tags in the desired-status attribute. direction-tags in the desired-status attribute.
If the resource reservation mechanism used requires participation of If the resource reservation mechanism used requires participation of
both user agents, the answerer SHOULD start resource reservation both user agents, the answerer SHOULD start resource reservation
after having sent the answer and the offerer SHOULD start resource after having sent the answer and the offerer SHOULD start resource
reservation as soon as the answer is received. If participation of reservation as soon as the answer is received. If participation of
the peer user agent is not needed (e.g., segmented status type), the the peer user agent is not needed (e.g., segmented status type), the
offerer MAY start resource reservation before sending the offer and offerer MAY start resource reservation before sending the offer and
the answerer MAY start it before sending the answer. the answerer MAY start it before sending the answer.
The status of the resource reservation of a media line can change The status of the resource reservation of a media line can change
between two consecutive offer/answer exchanges. Therefore, both user between two consecutive offer/answer exchanges. Therefore, both user
agents MUST keep their local status tables up to date using local agents MUST keep their local status tables up to date, using local
information through the duration of the session. information throughout the duration of the session.
6 Suspending and Resuming Session Establishment 6 Suspending and Resuming Session Establishment
A user agent server that receives an offer with preconditions SHOULD A user agent server that receives an offer with preconditions SHOULD
NOT alert the user until all the mandatory preconditions are met; NOT alert the user until all the mandatory preconditions are met;
session establishment is suspended until that moment (e.g., a PSTN session establishment is suspended until that moment (e.g., a PSTN
gateway reserves resources without sending signalling to the PSTN.) gateway reserves resources without sending signalling to the PSTN.)
A user agent server may receive an INVITE request with no offer in A user agent server may receive an INVITE request with no offer in
it. In this case, following normal procedures defined in [1] and in it. In this case, following normal procedures defined in [1] and
[5], the user agent server will provide an offer in a reliable 1xx [5], the user agent server will provide an offer in a reliable 1xx
response. The user agent client will send the answer in another SIP response. The user agent client will send the answer in another SIP
request (i.e., the PRACK for the 1xx). If the offer and the answer request (i.e., the PRACK for the 1xx). If the offer and the answer
contain preconditions, the user agent server SHOULD NOT alert the contain preconditions, the user agent server SHOULD NOT alert the
user until all the mandatory preconditions in the answer are met. user until all the mandatory preconditions in the answer are met.
Note that in this case, a user agent server providing a Note that in this case, a user agent server providing an
initial offer with preconditions, a 180 (Ringing) response initial offer with preconditions, a 180 (Ringing) response with
with preconditions will never be sent, since the user agent preconditions will never be sent, since the user agent server
server cannot alert the user until all the preconditions cannot alert the user until all the preconditions are met.
are met.
A UAS that is not capable of unilaterally meeting all of the A UAS that is not capable of unilaterally meeting all of the
mandatory preconditions MUST include a confirm-status attribute in mandatory preconditions MUST include a confirm-status attribute in
the SDP (offer or answer) that it sends (see Section 7). Further, the the SDP (offer or answer) that it sends (see Section 7). Further,
SDP (offer or answer) that contains this confirm-status attribute the SDP (offer or answer) that contains this confirm-status attribute
MUST be sent as soon as allowed by the SIP offer/answer rules. MUST be sent as soon as allowed by the SIP offer/answer rules.
While session establishment is suspended, user agents SHOULD not send While session establishment is suspended, user agents SHOULD not send
any data over any media stream. In the case of RTP [6], neither RTP any data over any media stream. In the case of RTP [6], neither RTP
nor RTCP packets are sent. nor RTCP packets are sent.
A user agent server knows that all the preconditions are met for a A user agent server knows that all the preconditions are met for a
media line when its local status table has a value of "yes" in all media line when its local status table has a value of "yes" in all
the rows whose strength-tag is "mandatory". When the preconditions of the rows whose strength-tag is "mandatory". When the preconditions
all the media lines of the session are met, session establishment of all the media lines of the session are met, session establishment
SHOULD resume. SHOULD resume.
For an initial INVITE suspending and resuming session establishment For an initial INVITE, suspending and resuming session establishment
is very intuitive. The callee will not be alerted until all the is very intuitive. The callee will not be alerted until all the
mandatory preconditions are met. However, offers containing mandatory preconditions are met. However, offers containing
preconditions sent in the middle of an ongoing session need further preconditions sent in the middle of an ongoing session need further
explanation. Both user agents SHOULD continue using the old session explanation. Both user agents SHOULD continue using the old session
parameters until all the mandatory preconditions are met. At that parameters until all the mandatory preconditions are met. At that
moment, the user agents can begin using the new session parameters. moment, the user agents can begin using the new session parameters.
Section 12 contains an example of this situation. Section 13 contains an example of this situation.
7 Status Confirmation 7 Status Confirmation
The confirm-status attribute MAY be used in both offers and answers. The confirm-status attribute MAY be used in both offers and answers.
This attribute represents a threshold for the resource reservation. This attribute represents a threshold for the resource reservation.
When this threshold is reached or surpassed, the user agent MUST send 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 an offer to the peer user agent, reflecting the new current status of
the media line as soon as allowed by the SIP offer/answer rules. If the media line as soon as allowed by the SIP offer/answer rules. If
this threshold is crossed again (e.g., the network stops providing this threshold is crossed again (e.g., the network stops providing
resources for the media stream), the user agent MUST send a new offer resources for the media stream), the user agent MUST send a new offer
as well as soon as allowed by the SIP offer/answer rules. as well, as soon as allowed by the SIP offer/answer rules.
If a peer has requested confirmation on a particular stream, an agent If a peer has requested confirmation on a particular stream, an agent
MUST mark that stream with a flag in its local status table. When all MUST mark that stream with a flag in its local status table. When
the rows with this flag have a "Current" value of "yes", the user all the rows with this flag have a "Current" value of "yes", the user
agent MUST send a new offer to the peer. This offer will contain the agent MUST send a new offer to the peer. This offer will contain the
current status of resource reservation in the current-status current status of resource reservation in the current-status
attributes. If later any of the rows with this flag transition to attributes. Later, if any of the rows with this flag transition to
"No", a new offer MUST be sent as well. "No", a new offer MUST be sent as well.
Confirmation attributes are not negotiated. The answerer uses the Confirmation attributes are not negotiated. The answerer uses the
value of the confirm-status attribute in the offer and the offerer value of the confirm-status attribute in the offer, and the offerer
uses the value of this attribute in the answer. uses the value of this attribute in the answer.
For example, if a user agent receives an SDP description with the For example, if a user agent receives an SDP description with the
following attributes: following attributes:
m=audio 20002 RTP/AVP 0 m=audio 20002 RTP/AVP 0
a=curr:qos local none a=curr:qos local none
a=curr:qos remote none a=curr:qos remote none
a=des:qos mandatory local sendrecv a=des:qos mandatory local sendrecv
a=des:qos mandatory remote sendrecv a=des:qos mandatory remote sendrecv
a=conf:qos remote sendrecv a=conf:qos remote sendrecv
It will send an offer as soon as it reserves resources in its access It will send an offer as soon as it reserves resources in its access
network ("remote" tag in the received message) for both directions network ("remote" tag in the received message) for both directions
(sendrecv). (sendrecv).
8 Refusing an offer 8 Refusing an offer
We define a new SIP status code: We define a new SIP status code:
Server-Error = "580" ;Precondition Failure Server-Error = "580" ;Precondition Failure
When a UAS acting as an answerer cannot or is not willing to meet the When a UAS, acting as an answerer, cannot or is not willing to meet
preconditions in the offer it SHOULD reject the offer by returning a the preconditions in the offer, it SHOULD reject the offer by
580 (Precondition-Failure) response. returning a 580 (Precondition-Failure) response.
Using the 580 (Precondition Failure) status code to refuse an offer Using the 580 (Precondition Failure) status code to refuse an offer
is useful when the offer came in an INVITE or in an UPDATE request. is useful when the offer comes in an INVITE or in an UPDATE request.
However, SIP does not provide a means to refuse offers that arrived However, SIP does not provide a means to refuse offers that arrive in
in a response (1xx or 2xx) to an INVITE. If a UAC generates an a response (1xx or 2xx) to an INVITE. If a UAC generates an initial
initial INVITE without an offer and receives an offer in a 1xx or 2xx INVITE without an offer and receives an offer in a 1xx or 2xx
response which is not acceptable, it SHOULD respond to this offer response which is not acceptable, it SHOULD respond to this offer
with a correctly formed answer and immediately after that send a with a correctly formed answer and immediately send a CANCEL or a
CANCEL or a BYE. BYE.
If the offer comes in a 1xx or 2xx response to a re-INVITE, A would If the offer comes in a 1xx or 2xx response to a re-INVITE, A would
not have a way to reject it without terminating the session at the 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] same time. The same recommendation given in Section 15.2 of [1]
applies here: applies here:
"The UAS MUST ensure that the session description overlaps "The UAS MUST ensure that the session description overlaps with
with its previous session description in media formats, its previous session description in media formats, transports,
transports, other parameters that require support from the other parameters that require support from the peer. This is
peer. This is to avoid the need for the peer to reject the to avoid the need for the peer to reject the session
session description. If, however, it is unacceptable to A, description. If, however, it is unacceptable to A, A SHOULD
A SHOULD generate an answer with a valid session generate an answer with a valid session description, and then
description, and then send a BYE to terminate the session." send a BYE to terminate the session."
580 (Precondition Failure) responses and BYE and CANCEL requests 580 (Precondition Failure) responses and BYE and CANCEL requests,
indicating failure to meet certain preconditions SHOULD contain an indicating failure to meet certain preconditions, SHOULD contain an
SDP description indicating which desired status triggered the SDP description, indicating which desired status triggered the
failure. Note that this SDP description is not an offer or an answer, failure. Note that this SDP description is not an offer or an
since it does not lead to the establishment of a session. The format answer, since it does not lead to the establishment of a session.
of such a description is based on the last SDP (an offer or an The format of such a description is based on the last SDP (an offer
answer) received from the remote UA. or an answer) received from the remote UA.
For each "m=" line in the last SDP description received, there MUST For each "m=" line in the last SDP description received, there MUST
be a corresponding "m=" line in the SDP description indicating be a corresponding "m=" line in the SDP description indicating
failure. This SDP description MUST contain exactly the same number of failure. This SDP description MUST contain exactly the same number
"m=" lines as the last SDP description received. The port number of of "m=" lines as the last SDP description received. The port number
every "m=" line MUST be set to zero, but the connection address is of every "m=" line MUST be set to zero, but the connection address is
arbitrary. arbitrary.
The desired status line corresponding to the precondition that The desired status line corresponding to the precondition that
triggered the failure MUST use the "failure" strength-tag, as shown triggered the failure MUST use the "failure" strength-tag, as shown
in the example below: in the example below:
m=audio 20000 RTP/AVP 0 m=audio 20000 RTP/AVP 0
a=des:qos failure e2e send a=des:qos failure e2e send
8.1 Rejecting a Media Stream 8.1 Rejecting a Media Stream
In the offer/answer model when an answerer wishes to reject a media In the offer/answer model, when an answerer wishes to reject a media
stream it sets its port to zero. The presence of preconditions does stream, it sets its port to zero. The presence of preconditions does
not change this behaviour; streams are still rejected by setting not change this behaviour; streams are still rejected by setting
their port to zero. their port to zero.
Both the offerer and the answerer MUST ignore all the preconditions Both the offerer and the answerer MUST ignore all the preconditions
that affect a stream with its port set to zero. They are not taken that affect a stream with its port set to zero. They are not taken
into consideration to decide whether or not session establishment can into consideration to decide whether or not session establishment can
resume. resume.
9 Unknown Precondition Type 9 Unknown Precondition Type
This document defines the "qos" tag for quality of service This document defines the "qos" tag for quality of service
preconditions. New precondition-types defined in the future will have preconditions. New precondition-types defined in the future will
new associated tags. A UA that receives an unknown precondition-type have new associated tags. A UA that receives an unknown
with a "mandatory" strength-tag in an offer MUST refuse the offer precondition-type, with a "mandatory" strength-tag in an offer, MUST
unless the only unknown mandatory preconditions have the "local" tag. refuse the offer unless the only unknown mandatory preconditions have
In this case, the UA does not need to be involved in order to meet the "local" tag. In this case, the UA does not need to be involved
the preconditions. The UA will ask for confirmation of the in order to meet the preconditions. The UA will ask for confirmation
preconditions and, when the confirmation arrives, it will resume of the preconditions and, when the confirmation arrives, it will
session establishment. resume session establishment.
A UA refusing an offer follows the rules described in section 8, but A UA refusing an offer follows the rules described in section 8, but
instead of the tag "failure", it uses the tag "unknown", as shown in instead of the tag "failure", it uses the tag "unknown", as shown in
the example below: the example below:
m=audio 20000 RTP/AVP 0 m=audio 20000 RTP/AVP 0
a=des:foo unknown e2e send a=des:foo unknown e2e send
10 Option Tag for Preconditions 10 Multiple Preconditions per Media Stream
A media stream MAY contain multiple preconditions. Different
preconditions MAY have the same precondition-type and different
status-types (e.g., end to end and segmented quality of service
preconditions) or different precondition-types (this document only
defines the "qos" precondition type, but extensions may define more
precondition-types in the future).
All the preconditions for a media stream MUST be met in order to
resume session establishment. The following example shows a session
description that uses both end-to-end and segmented status-types for
a media stream.
m=audio 20000 RTP/AVP 0
a=curr:qos local none
a=curr:qos remote none
a=des:qos mandatory local sendrecv
a=des:qos mandatory remote sendrecv
a=curr:qos e2e none
a=des:qos optional e2e sendrecv
11 Option Tag for Preconditions
We define the option tag "precondition" for use in the Require and We define the option tag "precondition" for use in the Require and
Supported header fields. An offerer MUST include this tag in the Supported header fields. An offerer MUST include this tag in the
Require header field if the offer contains one or more "mandatory" Require header field if the offer contains one or more "mandatory"
strength-tags. If all the strength-tags in the description are strength-tags. If all the strength-tags in the description are
"optional" or "none" the offerer MUST include this tag either in a "optional" or "none", the offerer MUST include this tag in either a
Supported header field or in a Require header field. It is, however, Supported header field or in a Require header field. It is, however,
RECOMMENDED, that the Supported header field is used in this case. RECOMMENDED that the Supported header field be used in this case.
The lack of preconditions in the answer would indicate that the The lack of preconditions in the answer would indicate that the
answerer did not support this extension. answerer did not support this extension.
The mapping of offers and answers to SIP requests and responses is The mapping of offers and answers to SIP requests and responses is
performed following the rules given in [5]. Therefore, a user agent performed following the rules given in [5]. Therefore, a user agent
including preconditions in the SDP MUST support the PRACK method, and including preconditions in the SDP MUST support the PRACK and UPDATE
consequently, MUST include the "100rel" [7] tag in the Supported methods. Consequently, it MUST include the "100rel" [7] tag in the
header field. Supported header field and SHOULD include an Allow header field with
the "UPDATE" tag [5].
11 Indicating Capabilities 12 Indicating Capabilities
The offer/answer model [4] describes the format of a session The offer/answer model [4] describes the format of a session
description to indicate capabilities. This format is used in description to indicate capabilities. This format is used in
responses to OPTIONS requests. A UA that supports preconditions responses to OPTIONS requests. A UA that supports preconditions
SHOULD add desired status lines indicating the precondition-types SHOULD add desired status lines indicating the precondition-types
supported for each media stream. These lines MUST have the "none" supported for each media stream. These lines MUST have the "none"
strength-tag, as shown in the example below: strength-tag, as shown in the example below:
m=audio 0 RTP/AVP 0 m=audio 0 RTP/AVP 0
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=des:foo none e2e sendrecv a=des:foo none e2e sendrecv
a=des:qos none local sendrecv a=des:qos none local sendrecv
Note that when this document was published, the precondition-type Note that when this document was published, the precondition-type
"foo" has not been registered. It is used here in the session "foo" has not been registered. It is used here in the session
description above to provide an example with multiple precondition- description above to provide an example with multiple precondition-
types. types.
A UA that supports this framework SHOULD add a "precondition" tag to A UA that supports this framework SHOULD add a "precondition" tag to
the Supported header field of its responses to OPTIONS requests. the Supported header field of its responses to OPTIONS requests.
12 Examples 13 Examples
The following examples cover both status types; end-to-end and The following examples cover both status types; end-to-end and
segmented. segmented.
12.1 End-to-end Status Type 13.1 End-to-end Status Type
The call flow of figure 2 shows a basic session establishment using The call flow of Figure 2 shows a basic session establishment using
the end-to-end status type. The SDP descriptions of this example are the end-to-end status type. The SDP descriptions of this example are
shown below: shown below:
SDP1: A includes end-to-end quality of service preconditions in the SDP1: A includes end-to-end quality of service preconditions in the
initial offer. initial offer.
m=audio 20000 RTP/AVP 0 m=audio 20000 RTP/AVP 0
c=IN IP4 192.0.2.1 c=IN IP4 192.0.2.1
a=curr:qos e2e none a=curr:qos e2e none
a=des:qos mandatory e2e sendrecv a=des:qos mandatory e2e sendrecv
SDP2: Since B uses RSVP, it can know when resources in its "send" SDP2: Since B uses RSVP, it can know when resources in its "send"
direction are available, because it will receive RESV messages from direction are available, because it will receive RESV messages from
the network. However, it does not know the status of the reservations the network. However, it does not know the status of the
in the other direction. B requests confirmation for resource reservations in the other direction. B requests confirmation for
reservations in its "recv" direction to the peer user agent A in its resource reservations in its "recv" direction to the peer user agent
answer. A in its answer.
m=audio 30000 RTP/AVP 0 m=audio 30000 RTP/AVP 0
c=IN IP4 192.0.2.4 c=IN IP4 192.0.2.4
a=curr:qos e2e none a=curr:qos e2e none
a=des:qos mandatory e2e sendrecv a=des:qos mandatory e2e sendrecv
a=conf:qos e2e recv a=conf:qos e2e recv
After having sent the answer B starts reserving network resources for After having sent the answer, B starts reserving network resources
the media stream. When A receives this answer (2) it starts for the media stream. When A receives this answer (2), it starts
performing resource reservation as well. Both UAs use RSVP, so A performing resource reservation as well. Both UAs use RSVP, so A
sends PATH messages towards B and B sends PATH messages towards A. sends PATH messages towards B and B sends PATH messages towards A.
As time passes by, B receives RESV messages confirming the As time passes, B receives RESV messages confirming the reservation.
reservation. However, B waits until resources in the other direction However, B waits until resources in the other direction are reserved
are reserved as well since it did not receive any confirmation and as well, since it did not receive any confirmation and the
the preconditions still have not been met. preconditions still have not been met.
SDP3: When A receives RESV messages it sends an updated offer (5) to SDP3: When A receives RESV messages, it sends an updated offer (5) to
B: B:
m=audio 20000 RTP/AVP 0 m=audio 20000 RTP/AVP 0
c=IN IP4 192.0.2.1 c=IN IP4 192.0.2.1
a=curr:qos e2e send a=curr:qos e2e send
a=des:qos mandatory e2e sendrecv a=des:qos mandatory e2e sendrecv
SDP4: B responds with an answer (6) which contains the current status SDP4: B responds with an answer (6) which contains the current status
of the resource reservation (i.e., sendrecv): of the resource reservation (i.e., sendrecv):
m=audio 30000 RTP/AVP 0 m=audio 30000 RTP/AVP 0
c=IN IP4 192.0.2.4 c=IN IP4 192.0.2.4
a=curr:qos e2e sendrecv a=curr:qos e2e sendrecv
a=des:qos mandatory e2e sendrecv a=des:qos mandatory e2e sendrecv
At this point of time, session establishment resumes and B returns a At this point in time, session establishment resumes and B returns a
180 (Ringing) response (7). 180 (Ringing) response (7).
Note that now the media stream has been already established, and A A B
has received a 180 (Ringing) response. Since the direction of the
stream is "sendrecv", A will not generate local ringback, since it
assumes that it will receive early media over this stream.
However, if B wants A to 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 an UPDATE request which would
be sent at the same time as the 200 (OK) for the INVITE (10). The
contents of the messages for this alternative flow are shown below:
SDP4 (on hold):
m=audio 30000 RTP/AVP 0
c=IN IP4 192.0.2.4
a=recvonly
a=curr:qos e2e sendrecv
a=des:qos mandatory e2e sendrecv
SDP5 in an UPDATE:
m=audio 30000 RTP/AVP 0
c=IN IP4 192.0.2.4
a=sendrecv
a=curr:qos e2e sendrecv
a=des:qos mandatory e2e sendrecv
A B
| |
|-------------(1) INVITE SDP1--------------->|
| |
|<------(2) 183 Session Progress SDP 2-------|
| *** *** |
|--*R*-----------(3) PRACK-------------*R*-->|
| *E* *E* |
|<-*S*-------(4) 200 OK (PRACK)--------*S*---|
| *E* *E* |
| *R* *R* |
| *V* *V* |
| *A* *A* |
| *T* *T* |
| *I* *I* |
| *O* *O* |
| *N* *N* |
| *** *** |
| *** |
| *** |
|-------------(5) UPDATE SDP3--------------->|
| |
|<--------(6) 200 OK (UPDATE) SDP4-----------|
| |
|<-------------(7) 180 Ringing---------------|
| |
|-----------------(8) PRACK----------------->|
| |
|<------------(9) 200 OK (PRACK)-------------|
| |
| |
| |
|<-----------(10) 200 OK (INVITE)------------|
| |
|------------------(11) ACK----------------->|
| |
| |
Figure 2: Example using the end-to-end status type | |
SDP6 in the 200 (OK) for the UPDATE: |-------------(1) INVITE SDP1--------------->|
| |
|<------(2) 183 Session Progress SDP2--------|
| *** *** |
|--*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----------------->|
| |
| |
m=audio 20000 RTP/AVP 0 Figure 2: Example using the end-to-end status type
c=IN IP4 192.0.2.1
a=sendrecv
a=curr:qos e2e sendrecv
a=des:qos mandatory e2e sendrecv
Let's assume that in the middle of the session A wishes to change the Let's assume, that in the middle of the session, A wishes to change
IP address where it is receiving media. Figure 3 shows this scenario. the IP address where it is receiving media. Figure 3 shows this
scenario.
SDP1: A includes an offer in a re-INVITE (1). A continues to receive 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 old IP address (192.0.2.1), but is ready to receive
media on the new one as well (192.0.2.2): media on the new one as well (192.0.2.2):
m=audio 20000 RTP/AVP 0 m=audio 20000 RTP/AVP 0
c=IN IP4 192.0.2.2 c=IN IP4 192.0.2.2
a=curr:qos e2e none a=curr:qos e2e none
a=des:qos mandatory e2e sendrecv a=des:qos mandatory e2e sendrecv
SDP2: B includes a "conf" attribute in its answer. B continues SDP2: B includes a "conf" attribute in its answer. B continues
sending media to the old remote IP address (192.0.2.1) sending media to the old remote IP address (192.0.2.1)
m=audio 30000 RTP/AVP 0 m=audio 30000 RTP/AVP 0
c=IN IP4 192.0.2.4 c=IN IP4 192.0.2.4
a=curr:qos e2e none a=curr:qos e2e none
a=des:qos mandatory e2e sendrecv a=des:qos mandatory e2e sendrecv
a=conf:qos e2e recv a=conf:qos e2e recv
SDP3: When A receives RESV messages it sends an updated offer (5) to SDP3: When A receives RESV messages it sends an updated offer (5) to
B: B:
m=audio 20000 RTP/AVP 0 m=audio 20000 RTP/AVP 0
c=IN IP4 192.0.2.2 c=IN IP4 192.0.2.2
a=curr:qos e2e send a=curr:qos e2e send
a=des:qos mandatory e2e sendrecv a=des:qos mandatory e2e sendrecv
SDP4: B responds with an answer (6) indicating that the preconditions SDP4: B responds with an answer (6), indicating that the
have been met (current status "sendrecv). It is now when B begins preconditions have been met (current status "sendrecv). It is now
A B that B begins sending media to the new remote IP address (192.0.2.2).
| | A B
|-------------(1) INVITE SDP1--------------->|
| |
|<------(2) 183 Session Progress SDP 2-------|
| *** *** |
|--*R*-----------(3) PRACK-------------*R*-->|
| *E* *E* |
|<-*S*-------(4) 200 OK (PRACK)--------*S*---|
| *E* *E* |
| *R* *R* |
| *V* *V* |
| *A* *A* |
| *T* *T* |
| *I* *I* |
| *O* *O* |
| *N* *N* |
| *** *** |
| *** |
| *** |
|-------------(5) UPDATE SDP3--------------->|
| |
|<--------(6) 200 OK (UPDATE) SDP4-----------|
| |
|<-----------(7) 200 OK (INVITE)-------------|
| |
|------------------(8) ACK------------------>|
| |
| |
Figure 3: Session modification with preconditions | |
|-------------(1) INVITE SDP1--------------->|
| |
|<------(2) 183 Session Progress SDP2--------|
| *** *** |
|--*R*-----------(3) PRACK-------------*R*-->|
| *E* *E* |
|<-*S*-------(4) 200 OK (PRACK)--------*S*---|
| *E* *E* |
| *R* *R* |
| *V* *V* |
| *A* *A* |
| *T* *T* |
| *I* *I* |
| *O* *O* |
| *N* *N* |
| *** *** |
| *** |
| *** |
|-------------(5) UPDATE SDP3--------------->|
| |
|<--------(6) 200 OK (UPDATE) SDP4-----------|
| |
|<-----------(7) 200 OK (INVITE)-------------|
| |
|------------------(8) ACK------------------>|
| |
| |
sending media to the new remote IP address (192.0.2.2). Figure 3: Session modification with preconditions
m=audio 30000 RTP/AVP 0 m=audio 30000 RTP/AVP 0
c=IN IP4 192.0.2.4 c=IN IP4 192.0.2.4
a=curr:qos e2e sendrecv a=curr:qos e2e sendrecv
a=des:qos mandatory e2e sendrecv a=des:qos mandatory e2e sendrecv
12.2 Segmented Status Type 13.2 Segmented Status Type
The call flow of figure 4 shows a basic session establishment using The call flow of Figure 4 shows a basic session establishment using
the segmented status type. The SDP descriptions of this example are the segmented status type. The SDP descriptions of this example are
shown below: shown below:
SDP1: A includes local and remote QoS preconditions in the initial SDP1: A includes local and remote QoS preconditions in the initial
offer. Before sending the initial offer, A reserves resources in its offer. Before sending the initial offer, A reserves resources in its
access network. This is indicated in the local current status of the access network. This is indicated in the local current status of the
SDP below: SDP below:
m=audio 20000 RTP/AVP 0 8 m=audio 20000 RTP/AVP 0 8
c=IN IP4 192.0.2.1 c=IN IP4 192.0.2.1
a=curr:qos local sendrecv a=curr:qos local sendrecv
a=curr:qos remote none a=curr:qos remote none
a=des:qos mandatory local sendrecv a=des:qos mandatory local sendrecv
a=des:qos mandatory remote sendrecv a=des:qos mandatory remote sendrecv
SDP2: B reserves resources in its access network and, since all the SDP2: B reserves resources in its access network and, since all the
preconditions are met, returns an answer in a 180 (Ringing) response preconditions are met, returns an answer in a 180 (Ringing) response
(3). (3).
m=audio 30000 RTP/AVP 0 8 m=audio 30000 RTP/AVP 0 8
c=IN IP4 192.0.2.4 c=IN IP4 192.0.2.4
a=curr:qos local sendrecv a=curr:qos local sendrecv
a=curr:qos remote sendrecv a=curr:qos remote sendrecv
a=des:qos mandatory local sendrecv a=des:qos mandatory local sendrecv
a=des:qos mandatory remote sendrecv a=des:qos mandatory remote sendrecv
Let's assume that after receiving this response A decides that it Let's assume that after receiving this response, A decides that it
wants to use only PCM u-law (payload 0), as opposed to both PCM u-law wants to use only PCM u-law (payload 0), as opposed to both PCM u-law
and A-law (payload 8). It would send an UPDATE to B possibly before and A-law (payload 8). It would send an UPDATE to B, possibly before
receiving the 200 (OK) for the INVITE (5). The SDP would look like: receiving the 200 (OK) for the INVITE (5). The SDP would look like:
m=audio 20000 RTP/AVP 0 m=audio 20000 RTP/AVP 0
c=IN IP4 192.0.2.1 c=IN IP4 192.0.2.1
a=curr:qos local sendrecv a=curr:qos local sendrecv
a=curr:qos remote sendrecv a=curr:qos remote sendrecv
a=des:qos mandatory local sendrecv a=des:qos mandatory local sendrecv
a=des:qos mandatory remote sendrecv a=des:qos mandatory remote sendrecv
B would generate an answer for this offer and place it in the 200 B would generate an answer for this offer and place it in the 200
(OK) for the UPDATE. (OK) for the UPDATE.
Note that this last offer/answer to reduce the number of supported Note that this last offer/answer to reduce the number of supported
codecs may arrive to the user agent server after the 200 (OK) codecs may arrive to the user agent server after the 200 (OK)
response has been generated. This would mean that the session is response has been generated. This would mean that the session is
established before A has reduced the number of supported codecs. To established before A has reduced the number of supported codecs. To
avoid this situation, the user agent client could wait for the first avoid this situation, the user agent client could wait for the first
answer from the user agent before setting its local current status to answer from the user agent before setting its local current status to
"sendrecv". "sendrecv".
12.3 Offer in a SIP response 13.3 Offer in a SIP response
The call flow of figure 5 shows a basic session establishment where The call flow of Figure 5 shows a basic session establishment where
the initial offer appears in a reliable 1xx response. This example the initial offer appears in a reliable 1xx response. This example
uses the end-to-end status type. The SDP descriptions of this example uses the end-to-end status type. The SDP descriptions of this
are shown below: example are shown below:
The first INVITE) (1) does not contain a session description. The first INVITE (1) does not contain a session description.
Therefore, the initial offer is sent by B in a reliable 183 (Session Therefore, the initial offer is sent by B in a reliable 183 (Session
Progress) response. Progress) response.
SDP1: B includes end-to-end quality of service preconditions in the SDP1: B includes end-to-end quality of service preconditions in the
initial offer. Since B uses RSVP, it can know when resources in its initial offer. Since B uses RSVP, it can know when resources in its
"send" direction are available, because it will receive RESV messages "send" direction are available, because it will receive RESV messages
from the network. However, it does not know the status of the from the network. However, it does not know the status of the
reservations in the other direction. B requests confirmation for reservations in the other direction. B requests confirmation for
resource reservations in its "recv" direction to the peer user agent resource reservations in its "recv" direction, to the peer user agent
A in its answer. A, in its answer.
m=audio 30000 RTP/AVP 0 m=audio 30000 RTP/AVP 0
c=IN IP4 192.0.2.4 c=IN IP4 192.0.2.4
a=curr:qos e2e none a=curr:qos e2e none
a=des:qos mandatory e2e sendrecv a=des:qos mandatory e2e sendrecv
a=conf:qos e2e recv a=conf:qos e2e recv
SDP2: A includes its answer if the PRACK for the 183 (Session SDP2: A includes its answer in the PRACK for the 183 (Session
Progress) response. Progress) response.
m=audio 20000 RTP/AVP 0 m=audio 20000 RTP/AVP 0
c=IN IP4 192.0.2.1 c=IN IP4 192.0.2.1
a=curr:qos e2e none a=curr:qos e2e none
a=des:qos mandatory e2e sendrecv a=des:qos mandatory e2e sendrecv
A B A B
| *** | | *** |
| *R* | | *R* |
| *E* | | *E* |
| *S* | | *S* |
| *E* | | *E* |
| *R* | | *R* |
| *V* | | *V* |
| *A* | | *A* |
| *T* | | *T* |
| *I* | | *I* |
| *O* | | *O* |
| *N* | | *N* |
| *** | | *** |
|-------------(1) INVITE SDP1--------------->| |-------------(1) INVITE SDP1--------------->|
| *** | | *** |
| *R* | | *R* |
| *E* | | *E* |
| *S* | | *S* |
| *E* | | *E* |
| *R* | | *R* |
| *V* | | *V* |
| *A* | | *A* |
| *T* | | *T* |
| *I* | | *I* |
| *O* | | *O* |
| *N* | | *N* |
| *** | | *** |
|<----------(2) 180 Ringing SDP2-------------| |<----------(2) 180 Ringing SDP2-------------|
| | | |
|----------------(3) PRACK------------------>| |----------------(3) PRACK------------------>|
| | | |
|<-----------(4) 200 OK (PRACK)--------------| |<-----------(4) 200 OK (PRACK)--------------|
| | | |
| | | |
|<-----------(5) 200 OK (INVITE)-------------| |<-----------(5) 200 OK (INVITE)-------------|
| | | |
|------------------(6) ACK------------------>| |------------------(6) ACK------------------>|
| | | |
| | | |
Figure 4: Example using the segmented status type Figure 4: Example using the segmented status type
A B A B
| | | |
|----------------(1) INVITE----------------->| |----------------(1) INVITE----------------->|
| | | |
|<------(2) 183 Session Progress SDP 1-------| |<------(2) 183 Session Progress SDP1--------|
| | | |
|---------------(3) PRACK SDP 2------------->| |---------------(3) PRACK SDP2-------------->|
| *** *** | | *** *** |
|<-*R*--------(4) 200 OK (PRACK)-------*R*---| |<-*R*--------(4) 200 OK (PRACK)-------*R*---|
| *E* *E* | | *E* *E* |
| *S* *S* | | *S* *S* |
| *E* *E* | | *E* *E* |
| *R* *R* | | *R* *R* |
| *V* *V* | | *V* *V* |
| *A* *A* | | *A* *A* |
| *T* *T* | | *T* *T* |
| *I* *I* | | *I* *I* |
| *O* *O* | | *O* *O* |
| *N* *N* | | *N* *N* |
| *** *** | | *** *** |
|-------------(5) UPDATE SDP3----------***-->| |-------------(5) UPDATE SDP3----------***-->|
| *** | | *** |
|<--------(6) 200 OK (UPDATE) SDP4-----***---| |<--------(6) 200 OK (UPDATE) SDP4-----***---|
| *** | | *** |
| *** | | *** |
| *** | | *** |
|<-------------(7) 180 Ringing---------------| |<-------------(7) 180 Ringing---------------|
| | | |
|-----------------(8) PRACK----------------->| |-----------------(8) PRACK----------------->|
| | | |
|<------------(9) 200 OK (PRACK)-------------| |<------------(9) 200 OK (PRACK)-------------|
| | | |
| | | |
| | | |
|<-----------(10) 200 OK (INVITE)------------| |<-----------(10) 200 OK (INVITE)------------|
| | | |
|------------------(11) ACK----------------->| |------------------(11) ACK----------------->|
| | | |
Figure 5: Example of an initial offer in a 1xx response Figure 5: Example of an initial offer in a 1xx response
After having sent the answer A starts reserving network resources for
the media stream. When B receives this answer (3) it starts After having sent the answer, A starts reserving network resources
performing resource reservation as well. Both UAs use RSVP, so A for the media stream. When B receives this answer (3), it starts
performing resource reservation as well. Both UAs use RSVP, so A
sends PATH messages towards B and B sends PATH messages towards A. sends PATH messages towards B and B sends PATH messages towards A.
SDP3: When A receives RESV messages it sends an updated offer (5) to SDP3: When A receives RESV messages, it sends an updated offer (5) to
B: B:
m=audio 20000 RTP/AVP 0 m=audio 20000 RTP/AVP 0
c=IN IP4 192.0.2.1 c=IN IP4 192.0.2.1
a=curr:qos e2e send a=curr:qos e2e send
a=des:qos mandatory e2e sendrecv a=des:qos mandatory e2e sendrecv
SDP4: B responds with an answer (6) which contains the current status SDP4: B responds with an answer (6) which contains the current status
of the resource reservation (i.e., recv): of the resource reservation (i.e., recv):
m=audio 30000 RTP/AVP 0 m=audio 30000 RTP/AVP 0
c=IN IP4 192.0.2.4 c=IN IP4 192.0.2.4
a=curr:qos e2e recv a=curr:qos e2e recv
a=des:qos mandatory e2e sendrecv a=des:qos mandatory e2e sendrecv
As time passes by, B receives RESV messages confirming the As time passes, B receives RESV messages confirming the reservation.
reservation. At this point of time, session establishment resumes and At this point in time, session establishment resumes and B returns a
B returns a 180 (Ringing) response (7). 180 (Ringing) response (7).
13 Security Considerations 14 Security Considerations
An entity in the middle of two user agents establishing a session may An entity in the middle of two user agents establishing a session may
add desired-status attributes making session establishment add desired-status attributes making session establishment
impossible. It could also modify the content of the current-status impossible. It could also modify the content of the current-status
parameters so that the session is established without meeting the parameters so that the session is established without meeting the
preconditions. Integrity protection can be used to avoid these preconditions. Integrity protection can be used to avoid these
attacks. attacks.
An entity performing resource reservations upon reception of An entity performing resource reservations upon reception of
unathenticated requests carrying preconditions can be an easy target unauthenticated requests carrying preconditions can be an easy target
for a denial of service attack. Requests with preconditions SHOULD be for a denial of service attack. Requests with preconditions SHOULD
authenticated. be authenticated.
14 IANA considerations 15 IANA Considerations
This document defines three media level SDP attributes: desired- This document defines three media level SDP attributes: desired-
status, current-status and conf-status. Their format is defined in status, current-status and conf-status. Their format is defined in
Section 4. Section 4.
Section 4 also defines one standard precondition-type related to the This document defines a framework for using preconditions with SIP.
attributes above: "qos". If in the future it was needed to Precondition-types to be used with this framework are registered by
standardize further precondition-types, they would need to be defined the IANA when they are published in standards track RFCs. The IANA
in a standards track document. Future precondition-types MUST define Considerations section of the RFC MUST include the following
the semantics with respect to the offer/answer model, as this information, which appears in the IANA registry along with the RFC
document defined these semantics for quality of service preconditions number of the publication.
in Section 5.
This document also defines a new SIP status code (580). Its default o Name of the precondition-type. The name MAY be of any length,
but SHOULD be no more than ten characters long.
o Descriptive text that describes the extension.
The only entry in the registry for the time being is:
Pecondition-Type Reference Description
---------------- --------- -----------
qos RFC 3312 Quality of Service preconditions
This document also defines a new SIP status code (580). Its default
reason phrase (Precondition Failure) is defined in section 8. reason phrase (Precondition Failure) is defined in section 8.
This document defines a SIP option tag (precondition) in section 10. This document defines a SIP option tag (precondition) in section 11.
15 Contributors 16 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.
17 References
[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[2] Handley, M. and V. Jacobson, "SDP: Session Description Protocol",
RFC 2327, April 1998.
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[4] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
Session Description Protocol (SDP)", RFC 3264, June 2002.
[5] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE
Method," RFC 3311, September 2002.
[6] Schulzrinne, S., Casner, S., Frederick, R. and V. Jacobson, "RTP:
A Transport Protocol for Real-Time Applications", RFC 1889,
January 1996.
[7] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional
Responses in Session Initiation Protocol (SIP)", RFC 3262, June
2002.
[8] C. Kalmanek, W. Marshall, P. Mishra, D. Nortz, and K. K.
Ramakrishnan, "DOSA: an architecture for providing robust IP
telephony service," in Proceedings of the Conference on Computer
Communications (IEEE Infocom), (Tel Aviv, Israel), Mar. 2000.
18 Contributors
The following persons contributed and were co-authors on earlier The following persons contributed and were co-authors on earlier
versions of this spec: versions of this spec:
K. K. Ramakrishnan (TeraOptic Networks), Ed Miller K. K. Ramakrishnan (TeraOptic Networks), Ed Miller (Terayon),
(Terayon), Glenn Russell (CableLabs), Burcak Beser (Pacific Glenn Russell (CableLabs), Burcak Beser (Pacific Broadband
Broadband Communications), Mike Mannette (3Com), Kurt Communications), Mike Mannette (3Com), Kurt Steinbrenner (3Com),
Steinbrenner (3Com), Dave Oran (Cisco), Flemming Andreasen Dave Oran (Cisco), Flemming Andreasen (Cisco), Michael Ramalho
(Cisco), Michael Ramalho (Cisco), John Pickens (Com21), (Cisco), John Pickens (Com21), Poornima Lalwaney (Nokia), Jon
Poornima Lalwaney (Nokia), Jon Fellows (Copper Mountain Fellows (Copper Mountain Networks), Doc Evans (D. R. Evans
Networks), Doc Evans (D. R. Evans Consulting), Keith Kelly Consulting), Keith Kelly (NetSpeak), Adam Roach (dynamicsoft),
(NetSpeak), Adam Roach (dynamicsoft), Dean Willis Dean Willis (dynamicsoft), Steve Donovan (dynamicsoft), Henning
(dynamicsoft), Steve Donovan (dynamicsoft), Henning Schulzrinne (Columbia University).
Schulzrinne (Columbia University).
This "manyfolks" draft is the culmination of over two years of work This "manyfolks" document is the culmination of over two years of
by many individuals, most are listed here and in the following work by many individuals, most are listed here and in the following
acknowledgements section. A special note is due to Flemming acknowledgements section. A special note is due to Flemming
Andreasen, Burcak Beser, Dave Boardman, Bill Guckel, Chuck Kalmanek, Andreasen, Burcak Beser, Dave Boardman, Bill Guckel, Chuck Kalmanek,
Keith Kelly, Poornima Lalwaney, John Lawser, Bill Marshall, Mike Keith Kelly, Poornima Lalwaney, John Lawser, Bill Marshall, Mike
Mannette, Dave Oran, K.K. Ramakrishnan, Michael Ramalho, Adam Roach, Mannette, Dave Oran, K.K. Ramakrishnan, Michael Ramalho, Adam Roach,
Jonathan Rosenberg, and Henning Schulzrinne for spearheading the Jonathan Rosenberg, and Henning Schulzrinne for spearheading the
initial "single INVITE" quality of service preconditions work from initial "single INVITE" quality of service preconditions work from
previous, non-SIP compatible, "two-stage Invite" proposals. These previous, non-SIP compatible, "two-stage Invite" proposals. These
"two-stage INVITE" proposals had their origins from Distributed Call "two-stage INVITE" proposals had their origins from Distributed Call
Signaling work in PacketCable, which, in turn, had architectural Signaling work in PacketCable, which, in turn, had architectural
elements from AT&T's Distributed Open Systems Architecture (DOSA) elements from AT&T's Distributed Open Systems Architecture (DOSA)
work [8]. work [8].
16 Acknowledgments 19 Acknowledgments
The Distributed Call Signaling work in the PacketCable project is the The Distributed Call Signaling work in the PacketCable project is the
work of a large number of people, representing many different 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.
Miguel Angel Garcia, Rohan May and Mark Watson provided helpful Miguel Angel Garcia-Martin, Rohan Mahy and Mark Watson provided
comments and suggestions. helpful comments and suggestions.
17 Authors' Addresses 20 Authors' Addresses
Gonzalo Camarillo Gonzalo Camarillo
Ericsson Ericsson
Advanced Signalling Research Lab. Advanced Signalling Research Lab.
FIN-02420 Jorvas FIN-02420 Jorvas
Finland Finland
electronic mail: Gonzalo.Camarillo@ericsson.com
EMail: Gonzalo.Camarillo@ericsson.com
Bill Marshall Bill Marshall
AT&T AT&T
Florham Park, NJ 07932 Florham Park, NJ 07932
USA USA
electronic mail: wtm@research.att.com
EMail: wtm@research.att.com
Jonathan Rosenberg Jonathan Rosenberg
dynamicsoft dynamicsoft
West Orange, NJ 07052 72 Eagle Rock Ave
East Hanover, NJ 07936
USA USA
electronic mail: jdrosen@dynamicsoft.com
18 Bibliography EMail: jdrosen@dynamicsoft.com
[1] J. Rosenberg, H. Schulzrinne, et al. , "SIP: Session initiation
protocol," Internet Draft, Internet Engineering Task Force, Feb.
2002. Work in progress.
[2] M. Handley and V. Jacobson, "SDP: session description protocol,"
Request for Comments 2327, Internet Engineering Task Force, Apr.
1998.
[3] S. Bradner, "Key words for use in RFCs to indicate requirement
levels," Request for Comments 2119, Internet Engineering Task Force,
Mar. 1997.
[4] J. Rosenberg and H. Schulzrinne, "An offer/answer model with
SDP," Internet Draft, Internet Engineering Task Force, Feb. 2002.
Work in progress.
[5] J. Rosenberg, "The SIP UPDATE method," Internet Draft, Internet
Engineering Task Force, Mar. 2002. Work in progress.
[6] 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.
[7] J. Rosenberg and H. Schulzrinne, "Reliability of provisional
responses in SIP," Internet Draft, Internet Engineering Task Force,
Feb. 2002. Work in progress.
[8] C. Kalmanek, W. Marshall, P. Mishra, D. Nortz, and K. K.
Ramakrishnan, "DOSA: an architecture for providing robust IP
telephony service," in
Proceedings of the Conference on Computer Communications (IEEE
Infocom) , (Tel Aviv, Israel), Mar. 2000.
Full Copyright Statement 21 Full Copyright Statement
Copyright (c) The Internet Society (2002). 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 are kind, provided that the above copyright notice and this paragraph 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. English.
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Notice Regarding Intellectual Property Rights Acknowledgement
The IETF has been notified of intellectual property rights claimed in Funding for the RFC Editor function is currently provided by the
regard to some or all of the specification contained in this Internet Society.
document. For more information consult the online list of claimed
rights.
 End of changes. 193 change blocks. 
783 lines changed or deleted 782 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/