draft-ietf-sip-manyfolks-resource-04.txt   draft-ietf-sip-manyfolks-resource-05.txt 
Internet Engineering Task Force SIP WG Internet Engineering Task Force SIP WG
Internet Draft G. Camarillo (Editor) Internet Draft G. Camarillo (Editor)
Ericsson Ericsson
W. Marshall (Editor) W. Marshall (Editor)
AT&T AT&T
Jonathan Rosenberg Jonathan Rosenberg
dynamicsoft dynamicsoft
draft-ietf-sip-manyfolks-resource-04.txt draft-ietf-sip-manyfolks-resource-05.txt
February 25, 2002 March 1, 2002
Expires: August, 2002 Expires: September, 2002
Integration of Resource Management and SIP Integration of Resource Management and SIP
STATUS OF THIS MEMO STATUS OF THIS MEMO
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 39 skipping to change at page 1, line 39
material or to cite them other than as "work in progress". material or to cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
To view the list Internet-Draft Shadow Directories, see To view the list Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
This document discusses how network quality of service can be made a This document defines a generic framework for preconditions which is
precondition to establishment of sessions initiated by the Session extensible through IANA registration. This document also discusses
Initiation Protocol (SIP). These preconditions require that the how network quality of service can be made a precondition to
participant reserve network resources before continuing with the establishment of sessions initiated by the Session Initiation
session. We do not define new quality of service reservation Protocol (SIP). These preconditions require that the participant
mechanisms; these preconditions simply require a participant to use reserve network resources before continuing with the session. We do
existing resource reservation mechanisms before beginning the not define new quality of service reservation mechanisms; these
session. preconditions simply require a participant to use existing resource
reservation mechanisms before beginning the session.
Table of Contents
1 Introduction ........................................ 3
2 Terminology ......................................... 3
3 Overview ............................................ 3
4 SDP parameters ...................................... 4
5 Usage of preconditions with offer/answer ............ 7
5.1 Generating an offer ................................. 8
5.1.1 SDP encoding ........................................ 9
5.2 Generating an Answer ................................ 10
6 Suspending and Resuming Session Establishment ....... 12
7 Status Confirmation ................................. 13
8 Refusing an offer ................................... 13
8.1 Rejecting a Media stream ............................ 14
9 Multiple Preconditions per Media Stream ............. 15
10 Option Tag for Preconditions ........................ 15
11 Examples ............................................ 15
11.1 End-to-end Status Type .............................. 16
11.2 Segmented Status Type ............................... 20
11.3 Offer in a SIP response ............................. 21
12 Security Considerations ............................. 24
13 IANA considerations ................................. 24
14 Contributors ........................................ 24
15 Acknowledgments ..................................... 26
16 Authors' Addresses .................................. 26
17 Bibliography ........................................ 27
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
skipping to change at page 2, line 46 skipping to change at page 3, line 46
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 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 quality of
service status. 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
skipping to change at page 3, line 19 skipping to change at page 4, line 19
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 piece of state of a media stream.
stream the same way as the direction attribute or the codecs in use, This is similar to the way the direction attributes, or the codecs in
define other pieces of state. Consequently, we treat these two new use, define other pieces of state. Consequently, we treat these two
variables in the same way as other SDP media attributes are treated new variables in the same way as other SDP media attributes are
in the offer/answer model used by SIP [4]: they are exchanged between treated in the offer/answer model used by SIP [4]: they are exchanged
two user agents using an offer and an answer in order to have a between two user agents using an offer and an answer in order to have
shared view of the status of the session. a 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 is 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 the
B->A direction, but wants A to handle the A->B direction. To indicate B->A direction, but needs A to handle the A->B direction. To indicate
so, B returns a 183 response to A asking A to start resource so, B returns a 183 response to A asking A to start resource
reservation and to warn B as soon as the A->B direction is ready for reservation and to confirm to B as soon as the A->B direction is
the session. A and B both start resource reservation. B finishes ready for the session. A and B both start resource reservation. B
reserving resources in the B->A direction, but does not alert the finishes reserving resources in the B->A direction, but does not
user yet, because network resources in both directions are needed. alert the user yet, because network resources in both directions are
When A finishes reserving resources in the A->B direction, it sends needed. When A finishes reserving resources in the A->B direction, it
an UPDATE to B. B returns a 200 (OK) response for the UPDATE sends an UPDATE [5] to B. B returns a 200 (OK) response for the
indicating that all the preconditions for the session have been met. UPDATE indicating that all the preconditions for the session have
At this point of time, B starts alerting the user, and session been met. At this point of time, B starts alerting the user, and
establishment completes normally. 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" precondition-type = "qos" | token
strength-tag = ("mandatory" | "optional" | "none" strength-tag = ("mandatory" | "optional" | "none"
= | "failure") = | "failure")
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
current status value has the same or a better value than current status value has the same or a better value than
the desired status value, the preconditions are considered the desired status value, the preconditions are considered
to be met. to be met for each stream.
Confirmation status: The desired 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.
skipping to change at page 4, line 49 skipping to change at page 5, line 49
callee can be alerted in case the network fails to meet the callee 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 reflects the status of the access network reservations of
both user agents. The end-to-end status corresponds to the both user agents. The end-to-end status corresponds to the
tag "e2e" defined above and the segmented status to the tag "e2e" defined above and the segmented status to the
tags "local" and "remote". End-to-end status is useful when tags "local" and "remote". End-to-end status is useful when
end-to-end resource reservation mechanisms. The segmented end-to-end resource reservation mechanisms are available.
status is useful when one or both UAs perform resource The segmented status is useful when one or both UAs perform
reservations on their respective access networks. 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 SDP 2-------|
| *** *** | | *** *** |
|--*R*-----------(3) PRACK-------------*R*-->| |--*R*-----------(3) PRACK-------------*R*-->|
| *E* *E* | | *E* *E* |
skipping to change at page 6, line 4 skipping to change at page 7, line 4
| | | |
| | | |
| | | |
|<-----------(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
Note that the use of the segmented status-type does not
prevent bottlenecks in the backbone, only in the access
networks.
Direction tag: The direction tag indicates the direction a Direction tag: The direction tag indicates the direction a
concrete attribute is applicable to. particular attribute (current, desired or confirmation
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 an
offer, "send" is the direction offerer->answerer and "local" is the offer, "send" is the direction offerer->answerer and "local" is the
offerer's access network. In an answer, "send" is the direction 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 the new SDP status parameters in the SIP offer/answer model 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 which
values can our new SDP attributes take in an answer depending on values our new SDP attributes can take in an answer depending on
their value in the offer. 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 the
answerer in the offer. The anwerer uses the information of this answerer in the offer. The anwerer 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
skipping to change at page 7, line 9 skipping to change at page 8, line 14
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 implement a table, referred to as "local status Both user agents MUST maintain local precondition status, which is
table", reflecting the status of the resource reservation. Tables 1 referred to as a "local status table". Tables 1 and 2 show the format
and 2 show the format of this tables for both the end-to-end and the of these tables for both the end-to-end and the segmented status
segmented status types. For the end-to-end status type, the table types. For the end-to-end status type, the table contains two rows;
contains two rows; one for each direction (i.e., send and recv). A one for each direction (i.e., send and recv). A value of "yes" in the
value of "yes" in the "Current" field indicates that resource has "Current" field indicates that resource has been successfully
been successfully reserved in the corresponding direction. "No" reserved in the corresponding direction. "No" indicates that
indicates that resources have not been reserved yet. The "Desired resources have not been reserved yet. The "Desired Strength" field
Strength" field indicates the strength of the preconditions in the indicates the strength of the preconditions in the corresponding
corresponding direction. The table for the segmented status type direction. The table for the segmented status type contains four
contains four rows: both directions in the local access network and rows: both directions in the local access network and in the peer's
in the peer's access network. The meaning of the fields is the same access network. The meaning of the fields is the same as in the end-
as in the end-to-end case. 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
skipping to change at page 7, line 43 skipping to change at page 8, line 48
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:
If the status type of the media line will be segmented, the user
agent generates records with the desired status and the current
status for each direction (send and recv) and each segment (local and
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
agent generates records with the desired status and the current
status for each direction (send and recv) and each segment (local and
remote) independently, as shown in table 2: 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
skipping to change at page 9, line 21 skipping to change at page 10, line 27
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. Mandatory is strength tags: none, optional and mandatory. Mandatory is
skipping to change at page 9, line 43 skipping to change at page 11, line 4
grade. An answerer MAY upgrade the desired strength in any grade. An answerer MAY upgrade the desired strength in any
entry of the transaction status table, but it MUST NOT entry of the transaction status table, but it MUST NOT
downgrade it. Therefore, it is OK to upgrade a row from downgrade it. Therefore, it is OK to upgrade a row from
none to optional, from none to mandatory or from optional none to optional, from none to mandatory or from optional
to mandatory, but not the other way around. to mandatory, but not the 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 the transaction status table and in the local status in the transaction status table and in the local status
table of the answerer have to be compared. Table 3 shows table of the answerer have to be compared. Table 3 shows
the four possible combinations. If both fields have the the four possible combinations. If both fields have the
same value (two first rows of table 3, nothing needs to be same 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 it has local information (e.g., a confirmation of a if it has local information (e.g., a confirmation of a
resource reservation has been received) about that resource reservation has been received) about that
particular current status. If it does, the "Current" field particular current status. If it does, the "Current" field
of the transaction status table is set to "Yes". If the of the transaction status table is set to "Yes". If the
answerer does not have local information about that current answerer does not have local information about that current
status, the "Current" field of the local status table MUST status, the "Current" field of the local status table MUST
be set to "No". be set to "No".
Transaction status table Local status table Transac. status table Local status table New values transac./local
____________________________________________ ____________________________________________________________________
no no no no no/no
yes yes yes yes yes/yes
yes no yes no yes/yes
no yes no yes no/no OR yes/yes
Table 3: Possible values for the "Current" fields Table 3: Possible values for the "Current" fields
Once both tables have been updated an answer is generated following Once both tables have been updated, an answer is generated following
the rules described in Section 5.1.1 and taking into account that the rules described in Section 5.1.1 and taking into account that
"send", "recv", "local" and "remote" tags have to be inverted in the "send", "recv", "local" and "remote" tags have to be inverted in the
answer, as shown in table 4. 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
skipping to change at page 11, line 12 skipping to change at page 12, line 20
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 through 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 A user agent server that receives an offer with preconditions SHOULD
SHOULDNOT alert the user until all the mandatory preconditions are NOT alert the user until all the mandatory preconditions are met;
met; session establishment is suspended until that moment. session establishment is suspended until that moment (e.g., a 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 SIP procedures, the user agent it. In this case, following normal procedures defined in [1] and in
server will provide an offer in a reliable response (1xx or 2xx). The [5], the user agent server will provide an offer in a reliable 1xx
user agent client will send the answer in another SIP request. If the response. The user agent client will send the answer in another SIP
offer and the answer contain preconditions, the user agent client request (i.e., the PRACK for the 1xx). If the offer and the answer
SHOULD NOT alert the user until all the mandatory preconditions in contain preconditions, the user agent server SHOULD NOT alert the
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
initial offer with preconditions, a 180 (Ringing) response
will never be sent, since the user agent server cannot
alert the user until all the preconditions are met.
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 [5], 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 of
all the media lines of the session are met, session establishment 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 SHOULD begin using the new session
Section 10 contains an example of this situation. parameters. Section 11 contains an example of this situation.
7 Status Confirmation 7 Status Confirmation
The qos-confirm-status attribute MAY be used in both offers and The confirm-status attribute MAY be used in both offers and answers.
answers. This attribute represents a threshold for the resource This attribute represents a threshold for the resource reservation.
reservation. When this threshold is reached or surpassed, the user When this threshold is reached or surpassed, the user agent MUST send
agent MUST send an offer to the peer user agent reflecting the new an offer to the peer user agent reflecting the new current status of
current status of the media line. If this threshold is crossed again the media line as soon as allowed by the SIP offer/answer rules. If
(e.g., the network stops providing resources for the media stream), this threshold is crossed again (e.g., the network stops providing
the user agent MUST send a new offer as well. 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.
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 all
the rows with this flag have a value of "yes", the user agent MUST the rows with this flag have a value of "yes", the user agent MUST
send a new offer to the peer. This offer will contain the current send a new offer to the peer. This offer will contain the current
status of resource reservation in the qos-current-status attributes. status of resource reservation in the current-status attributes. If
If later any of the rows with this flag transition to "No", a new later any of the rows with this flag transition to "No", a new offer
offer MUST be sent as well. 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 qos-confirm-status attribute in the offer and the value of the confirm-status attribute in the offer and the offerer
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 an answerer cannot or is not willing to meet the preconditions preconditions in the offer it SHOULD reject the offer by returning a
in the offer it SHOULD reject the offer by returning a 580 580 (Precondition-Failure) response. This response SHOULD contain an
(Precondition-Failure) response. This response SHOULD contain an SDP SDP description indicating which desired status triggered the
description indicating which desired status triggered the failure. failure. The corresponding desired status line MUST use the "failure"
The corresponding desired status line MUST a value of the strength value of the strength tag, as shown in the example below:
tag of "failure", as shown 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
SDP description indicating this type of failure MUST follow the SDP description indicating this type of failure MUST follow the
format for describing media capabilities defined in the SIP format for describing media capabilities defined in the SIP
offer/answer model [4]. offer/answer model [4].
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 came in an INVITE or in an UPDATE request.
skipping to change at page 13, line 28 skipping to change at page 14, line 41
applies here: applies here:
"The UAS MUST ensure that the session description overlaps "The UAS MUST ensure that the session description overlaps
with its previous session description in media formats, with its previous session description in media formats,
transports, other parameters that require support from the transports, other parameters that require support from the
peer. This is to avoid the need for the peer to reject the peer. This is to avoid the need for the peer to reject the
session description. If, however, it is unacceptable to A, session description. If, however, it is unacceptable to A,
A SHOULD generate an answer with a valid session A SHOULD generate an answer with a valid session
description, and then send a BYE to terminate the session." description, and then send a BYE to terminate the session."
9 Option tag for Require and Supported header fields 8.1 Rejecting a Media stream
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
not change this behaviour; streams are still rejected by setting
their port to zero.
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
into consideration to decide whether or not session establishment can
resume.
9 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
10 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 if the Supported header fields. An offerer MUST include this tag in the
offer contains one or more strength tags with the value "mandatory". Require header field if the offer contains one or more strength tags
If all the strength tags in the description are "optional" or "none" with the value "mandatory". If all the strength tags in the
the offerer MUST include this tag either in a Supported header field description are "optional" or "none" the offerer MUST include this
or in a Require header field. It is, however, RECOMMENDED, that the tag either in a Supported header field or in a Require header field.
Supported header field is used in this case. The lack of It is, however, RECOMMENDED, that the Supported header field is used
preconditions in the answer would indicate that the answerer did not in this case. The lack of preconditions in the answer would indicate
support this extension. that the 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 . Therefore, a user agent performed following the rules given in [5]. Therefore, a user agent
including preconditions in the SDP MUST include both "100rel" [6] and including preconditions in the SDP MUST include both "100rel" [7] and
"update" tags in the Require header field. "update" [5] tags in the Require header field.
10 Examples 11 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.
10.1 End-to-end Status Type 11.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: B 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 reservations
in the other direction. B requests confirmation for resource in the other direction. B requests confirmation for resource
reservations in its "recv" direction to the peer user agent A in its reservations in its "recv" direction to the peer user agent A in its
answer. 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 by, B receives RESV messages confirming the
reservation. However, B waits until resources in the other direction reservation. However, B waits until resources in the other direction
as reserved as well since it did not receive any confirmation and the as reserved as well since it did not receive any confirmation and 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:
skipping to change at page 15, line 47 skipping to change at page 18, line 4
a=curr:qos e2e sendrecv a=curr:qos e2e sendrecv
a=des:qos mandatory e2e sendrecv a=des:qos mandatory e2e sendrecv
SDP6 in the ACK (11): SDP6 in the ACK (11):
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=sendrecv a=sendrecv
a=curr:qos e2e sendrecv a=curr:qos e2e sendrecv
a=des:qos mandatory e2e sendrecv a=des:qos mandatory e2e sendrecv
Let's assume that in the middle of the session A wishes to change the
A B A B
| | | |
|-------------(1) INVITE SDP1--------------->| |-------------(1) INVITE SDP1--------------->|
| | | |
|<------(2) 183 Session Progress SDP 2-------| |<------(2) 183 Session Progress SDP 2-------|
| *** *** | | *** *** |
|--*R*-----------(3) PRACK-------------*R*-->| |--*R*-----------(3) PRACK-------------*R*-->|
| *E* *E* | | *E* *E* |
|<-*S*-------(4) 200 OK (PRACK)--------*S*---| |<-*S*-------(4) 200 OK (PRACK)--------*S*---|
skipping to change at page 17, line 4 skipping to change at page 19, line 4
| | | |
| | | |
| | | |
|<-----------(10) 200 OK (INVITE)------------| |<-----------(10) 200 OK (INVITE)------------|
| | | |
|------------------(11) ACK----------------->| |------------------(11) ACK----------------->|
| | | |
| | | |
Figure 2: Example using the end-to-end status type Figure 2: Example using the end-to-end status type
Let's assume that in the middle of the session A wishes to change the
IP address where it is receiving media. Figure 3 shows this scenario. IP address where it is receiving media. Figure 3 shows this scenario.
A B A B
| | | |
|-------------(1) INVITE SDP1--------------->| |-------------(1) INVITE SDP1--------------->|
| | | |
|<------(2) 183 Session Progress SDP 2-------| |<------(2) 183 Session Progress SDP 2-------|
| *** *** | | *** *** |
|--*R*-----------(3) PRACK-------------*R*-->| |--*R*-----------(3) PRACK-------------*R*-->|
skipping to change at page 18, line 6 skipping to change at page 20, line 7
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 it 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 "confirm" tag in its answer. B continues sending SDP2: B includes a "conf" attribute in its answer. B continues
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 confirm a=des:qos mandatory e2e sendrecv
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 preconditions
have been met (current status "sendrecv). It is now when B begins have been met (current status "sendrecv). It is now when B begins
sending media to the new remote IP address (192.0.2.2). sending media to the new remote IP address (192.0.2.2).
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
10.2 Segmented Status Type 11.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: B includes local and remote QoS preconditions in the initial SDP1: B 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:
skipping to change at page 19, line 40 skipping to change at page 21, line 42
B would generate an answer for this offer and place it in the 200 OK B would generate an answer for this offer and place it in the 200 OK
for the UPDATE. 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 response codecs may arrive to the user agent server after the 200 OK response
has been generated. This would mean that the session is established has been generated. This would mean that the session is established
before A has reduced the number of supported codecs. To avoid this before A has reduced the number of supported codecs. To avoid this
situation, the user agent client could wait for the first answer from situation, the user agent client could wait for the first answer from
the user agent before setting its local current status to "sendrecv". the user agent before setting its local current status to "sendrecv".
11 Security Considerations 11.3 Offer in a SIP response
An entity in the middle of two user agents establishing a session may The call flow of figure 5 shows a basic session establishment where
add desired-status attributes making session establishment the initial offer appears in a reliable 1xx response. This example
impossible. It could also modify the content of the current-status uses the end-to-end status type. The SDP descriptions of this example
parameters so that the session is established without meeting the are shown below:
preconditions. Integrity protection can be used to avoid this
attacks.
A B A B
| *** | | *** |
| *R* | | *R* |
| *E* | | *E* |
| *S* | | *S* |
| *E* | | *E* |
| *R* | | *R* |
| *V* | | *V* |
skipping to change at page 20, line 48 skipping to change at page 23, line 4
|<-----------(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
The first INVITE) (1) does not contain a session description.
Therefore, the initial offer is sent by B in a reliable 183 response.
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
"send" direction are available, because it will receive RESV messages
from the network. However, it does not know the status of the
reservations in the other direction. B requests confirmation for
resource reservations in its "recv" direction to the peer user agent
A in its offer.
m=audio 30000 RTP/AVP 0
c=IN IP4 192.0.2.4
a=curr:qos e2e none
a=des:qos mandatory e2e sendrecv
a=conf:qos e2e recv
SDP2: A includes its answer in the PRACK for the 183 response.
m=audio 20000 RTP/AVP 0
c=IN IP4 192.0.2.1
a=curr:qos e2e none
a=des:qos mandatory e2e sendrecv
After having sent the answer, A starts reserving network resources
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.
SDP3: When A receives RESV messages it sends an updated offer (5) to
B:
m=audio 20000 RTP/AVP 0
c=IN IP4 192.0.2.1
a=curr:qos e2e send
a=des:qos mandatory e2e sendrecv
SDP4: B responds with an answer (6) which contains the current status
of the resource reservation (i.e., recv):
m=audio 30000 RTP/AVP 0
c=IN IP4 192.0.2.4
a=curr:qos e2e recv
a=des:qos mandatory e2e sendrecv
As time passes by, B receives RESV messages confirming the
reservation. At this point of time, session establishment resumes and
B returns a 180 (Ringing) response (7).
12 Security Considerations
An entity in the middle of two user agents establishing a session may
add desired-status attributes making session establishment
impossible. It could also modify the content of the current-status
parameters so that the session is established without meeting the
preconditions. Integrity protection can be used to avoid these
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 unathenticated 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 be
authenticated.
12 IANA considerations 13 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 one standard precondition-type related to the Section 4 also defines one standard precondition-type related to the
attributes above: "qos". If in the future it was needed to attributes above: "qos". If in the future it was needed to
standardize further precondition-types, they would need to be defined standardize further precondition-types, they would need to be defined
in a standards track document. in a standards track document. Future precondition-types MUST define
the semantics with respect to the offer/answer model, as this
document defined these semantics for quality of service preconditions
in Section 5.
This document also defines a new SIP status code (580). Its default 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.
13 Contributors This document defines a SIP option tag (precondition) in section 10.
The following persons contributed to early versions of this spec: 14 Contributors
K. K. Ramakrishnan (TeraOptic Networks), Ed Miller (Terayon), Glenn The following persons contributed and were co-authors on earlier
Russell (CableLabs), Burcak Beser (Pacific Broadband Communications), versions of this spec:
Mike Mannette (3Com), Kurt Steinbrenner (3Com), Dave Oran (Cisco),
Flemming Andreasen (Cisco), Michael Ramalho (Cisco), John Pickens K. K. Ramakrishnan (TeraOptic Networks), Ed Miller
(Com21), Poornima Lalwaney (Nokia), Jon Fellows (Copper Mountain (Terayon), Glenn Russell (CableLabs), Burcak Beser (Pacific
A B
| |
|----------------(1) INVITE----------------->|
| |
|<------(2) 183 Session Progress SDP 1-------|
| |
|---------------(3) PRACK SDP 2------------->|
| *** *** |
|<-*R*--------(4) 200 OK (PRACK)-------*R*---|
| *E* *E* |
| *S* *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 5: Example of an initial offer in a 1xx response
Broadband Communications), Mike Mannette (3Com), Kurt
Steinbrenner (3Com), Dave Oran (Cisco), Flemming Andreasen
(Cisco), Michael Ramalho (Cisco), John Pickens (Com21),
Poornima Lalwaney (Nokia), Jon Fellows (Copper Mountain
Networks), Doc Evans (D. R. Evans Consulting), Keith Kelly Networks), Doc Evans (D. R. Evans Consulting), Keith Kelly
(NetSpeak), Adam Roach (dynamicsoft), Dean Willis (dynamicsoft), (NetSpeak), Adam Roach (dynamicsoft), Dean Willis
Steve Donovan (dynamicsoft), Henning Schulzrinne (Columbia (dynamicsoft), Steve Donovan (dynamicsoft), Henning
University). Schulzrinne (Columbia University).
14 Acknowledgments This "manyfolks" draft is the culmination of over two years of work
by many individuals, most are listed here and in the following
acknowledgements section. A special note is due to Flemming
Andreasen, Burcak Beser, Dave Boardman, Bill Guckel, Chuck Kalmanek,
Keith Kelly, Poornima Lalwaney, John Lawser, Bill Marshall, Mike
Mannette, Dave Oran, K.K. Ramakrishnan, Michael Ramalho, Adam Roach,
Jonathan Rosenberg, and Henning Schulzrinne for spearheading the
initial "single Invite" quality of service preconditions work from
previous, non-SIP compatible, "two-stage Invite" proposals. These
"two-stage Invite" proposals had their origins from Distributed Call
Signaling work in PacketCable, which, in turn, had architectural
elements from AT&T's Distributed Open Systems Architecture (DOSA)
work [8].
15 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.
15 Authors' Addresses 16 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 electronic mail: 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 electronic mail: wtm@research.att.com
Jonathan Rosenberg Jonathan Rosenberg
dynamicsoft dynamicsoft
West Orange, NJ 07052 West Orange, NJ 07052
USA USA
electronic mail: jdrosen@dynamicsoft.com electronic mail: jdrosen@dynamicsoft.com
16 Bibliography 17 Bibliography
[1] J. Rosenberg, H. Schulzrinne, et al. , "SIP: Session initiation [1] J. Rosenberg, H. Schulzrinne, et al. , "SIP: Session initiation
protocol," Internet Draft, Internet Engineering Task Force, Feb. protocol," Internet Draft, Internet Engineering Task Force, Feb.
2002. Work in progress. 2002. Work in progress.
[2] M. Handley and V. Jacobson, "SDP: session description protocol," [2] M. Handley and V. Jacobson, "SDP: session description protocol,"
Request for Comments 2327, Internet Engineering Task Force, Apr. Request for Comments 2327, Internet Engineering Task Force, Apr.
1998. 1998.
[3] S. Bradner, "Key words for use in RFCs to indicate requirement [3] S. Bradner, "Key words for use in RFCs to indicate requirement
levels," Request for Comments 2119, Internet Engineering Task Force, levels," Request for Comments 2119, Internet Engineering Task Force,
Mar. 1997. Mar. 1997.
[4] J. Rosenberg and H. Schulzrinne, "An offer/answer model with [4] J. Rosenberg and H. Schulzrinne, "An offer/answer model with
SDP," Internet Draft, Internet Engineering Task Force, Jan. 2002. SDP," Internet Draft, Internet Engineering Task Force, Feb. 2002.
Work in progress. Work in progress.
[5] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: a [5] J. Rosenberg, "The SIP UPDATE method," Internet Draft, Internet
Engineering Task Force, Feb. 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 transport protocol for real-time applications," Request for Comments
1889, Internet Engineering Task Force, Jan. 1996. 1889, Internet Engineering Task Force, Jan. 1996.
[6] J. Rosenberg and H. Schulzrinne, "Reliability of provisional [7] J. Rosenberg and H. Schulzrinne, "Reliability of provisional
responses in SIP," Internet Draft, Internet Engineering Task Force, responses in SIP," Internet Draft, Internet Engineering Task Force,
Sept. 2001. Work in progress. 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 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
 End of changes. 

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