draft-ietf-sip-manyfolks-resource-06.txt   draft-ietf-sip-manyfolks-resource-07.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-06.txt draft-ietf-sip-manyfolks-resource-07.txt
March 25, 2002 April 8, 2002
Expires: September, 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
skipping to change at page 2, line 20 skipping to change at page 2, line 20
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 ....... 12
7 Status Confirmation ................................. 13 7 Status Confirmation ................................. 13
8 Refusing an offer ................................... 14 8 Refusing an offer ................................... 14
8.1 Rejecting a Media Stream ............................ 15 8.1 Rejecting a Media Stream ............................ 15
9 Unknown Precondition Type ........................... 15 9 Unknown Precondition Type ........................... 15
10 Option Tag for Preconditions ........................ 15 10 Option Tag for Preconditions ........................ 16
11 Indicating Capabilities ............................. 16 11 Indicating Capabilities ............................. 16
12 Examples ............................................ 16 12 Examples ............................................ 16
12.1 End-to-end Status Type .............................. 16 12.1 End-to-end Status Type .............................. 17
12.2 Segmented Status Type ............................... 21 12.2 Segmented Status Type ............................... 22
12.3 Offer in a SIP response ............................. 22 12.3 Offer in a SIP response ............................. 23
13 Security Considerations ............................. 26 13 Security Considerations ............................. 26
14 IANA considerations ................................. 26 14 IANA considerations ................................. 26
15 Contributors ........................................ 26 15 Contributors ........................................ 27
16 Acknowledgments ..................................... 27 16 Acknowledgments ..................................... 27
17 Authors' Addresses .................................. 27 17 Authors' Addresses .................................. 28
18 Bibliography ........................................ 28 18 Bibliography ........................................ 28
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
skipping to change at page 4, line 34 skipping to change at page 4, line 34
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 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 needs 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 (Session Progress) response to A asking A to
reservation and to confirm to B as soon as the A->B direction is start resource reservation and to confirm to B as soon as the A->B
ready for the session. A and B both start resource reservation. B direction is ready for the session. A and B both start resource
finishes reserving resources in the B->A direction, but does not reservation. B finishes reserving resources in the B->A direction,
alert the user yet, because network resources in both directions are but does not alert the user yet, because network resources in both
needed. When A finishes reserving resources in the A->B direction, it directions are needed. When A finishes reserving resources in the A-
sends an UPDATE [5] to B. B returns a 200 (OK) response for the >B direction, it sends an UPDATE [5] to B. B returns a 200 (OK)
UPDATE indicating that all the preconditions for the session have response for the UPDATE indicating that all the preconditions for the
been met. At this point of time, B starts alerting the user, and session have been met. At this point of time, B starts alerting the
session establishment completes normally. 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
skipping to change at page 5, line 48 skipping to change at page 6, line 4
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 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
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
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 7, 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
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. end-to-end resource reservation mechanisms are available.
The segmented status is useful when one or both UAs perform The segmented status is useful when one or both UAs perform
resource reservations on their respective access networks. resource reservations on their respective access networks.
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
particular attribute (current, desired or confirmation 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 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.
skipping to change at page 11, line 43 skipping to change at page 11, line 45
account that "send", "recv", "local" and "remote" tags have to be account that "send", "recv", "local" and "remote" tags have to be
inverted in the answer, as shown in table 4. inverted in 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 offer 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
skipping to change at page 12, line 38 skipping to change at page 12, line 39
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 in
[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 a
initial offer with preconditions, a 180 (Ringing) response initial offer with preconditions, a 180 (Ringing) response
will never be sent, since the user agent server cannot with preconditions will never be sent, since the user agent
alert the user until all the preconditions are met. server cannot alert the user until all the preconditions
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, the
SDP (offer or answer) that contains this confirm-status attribute 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.
skipping to change at page 13, line 31 skipping to change at page 13, line 33
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 all
the rows with this flag have a value of "yes", the user agent MUST the rows with this flag have a "Current" value of "yes", the user
send a new offer to the peer. This offer will contain the current agent MUST send a new offer to the peer. This offer will contain the
status of resource reservation in the current-status attributes. If current status of resource reservation in the current-status
later any of the rows with this flag transition to "No", a new offer attributes. If later any of the rows with this flag transition to
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
skipping to change at page 14, line 16 skipping to change at page 14, line 16
(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 the
preconditions in the offer it SHOULD reject the offer by returning a preconditions in the offer it SHOULD reject the offer by returning a
580 (Precondition-Failure) response. This response SHOULD contain an 580 (Precondition-Failure) response.
SDP description indicating which desired status triggered the
failure. The corresponding desired status line MUST use the "failure"
strength-tag, as shown in the example below:
m=audio 20000 RTP/AVP 0
a=des:qos failure e2e send
SDP description indicating this type of failure MUST follow the
format for describing media capabilities defined in the SIP
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.
However, SIP does not provide a means to refuse offers that contained However, SIP does not provide a means to refuse offers that arrived
in a response (1xx or 2xx) to an INVITE. in a response (1xx or 2xx) to an INVITE. If a UAC generates an
initial INVITE without an offer and receives an offer in a 1xx or 2xx
If a UAC generates an initial INVITE without an offer and receives an response which is not acceptable, it SHOULD respond to this offer
offer in a 1xx or 2xx response which is not acceptable, it SHOULD with a correctly formed answer and immediately after that send a
respond to this offer with a correctly formed answer and immediately CANCEL or a BYE.
after that send a CANCEL or a 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 14.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 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."
580 (Precondition Failure) responses and BYE and CANCEL requests
indicating failure to meet certain preconditions SHOULD contain an
SDP description indicating which desired status triggered the
failure. Note that this SDP description is not an offer or an answer,
since it does not lead to the establishment of a session. The format
of such a description is based on the last SDP (an offer or an
answer) received from the remote UA.
For each "m=" line in the last SDP description received, there MUST
be a corresponding "m=" line in the SDP description indicating
failure. This SDP description MUST contain exactly the same number of
"m=" lines as the last SDP description received. The port number of
every "m=" line MUST be set to zero, but the connection address is
arbitrary.
The desired status line corresponding to the precondition that
triggered the failure MUST use the "failure" strength-tag, as shown
in the example below:
m=audio 20000 RTP/AVP 0
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
skipping to change at page 16, line 5 skipping to change at page 16, line 20
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 either in 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 is 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 method, and
consequently, MUST include the "100rel" [7] tag in the Require header consequently, MUST include the "100rel" [7] tag in the Supported
field. header field.
A user agent including preconditions in the SDP SHOULD support the
UPDATE method. If it is supported, an "update" [5] tag MUST be
included in the Require header field.
User agents that use preconditions but do not support
UPDATE can only be used in a limited set of scenarios, such
as the one described in figure 4.
11 Indicating Capabilities 11 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:
skipping to change at page 18, line 18 skipping to change at page 18, line 26
180 (Ringing) response (7). 180 (Ringing) response (7).
Note that now the media stream has been already established, and A Note that now the media stream has been already established, and A
has received a 180 (Ringing) response. Since the direction of the has received a 180 (Ringing) response. Since the direction of the
stream is "sendrecv", A will not generate local ringback, since it stream is "sendrecv", A will not generate local ringback, since it
assumes that it will receive early media over this stream. assumes that it will receive early media over this stream.
However, if B wants A to generate local ringback, it can put the 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 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 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 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: contents of the messages for this alternative flow are shown below:
SDP4 (on hold): SDP4 (on hold):
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=recvonly a=recvonly
a=curr:qos e2e sendrecv a=curr:qos e2e sendrecv
a=des:qos mandatory e2e sendrecv a=des:qos mandatory e2e sendrecv
SDP5 in an UPDATE: SDP5 in an UPDATE:
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=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
SDP6 in the 200 OK for the UPDATE:
m=audio 20000 RTP/AVP 0
c=IN IP4 192.0.2.1
a=sendrecv
a=curr:qos e2e sendrecv
a=des:qos mandatory e2e sendrecv
Let's assume that in the middle of the session A wishes to change the
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*-->|
| *E* *E* | | *E* *E* |
|<-*S*-------(4) 200 OK (PRACK)--------*S*---| |<-*S*-------(4) 200 OK (PRACK)--------*S*---|
skipping to change at page 20, line 4 skipping to change at page 20, 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
SDP6 in the 200 (OK) for the UPDATE:
m=audio 20000 RTP/AVP 0
c=IN IP4 192.0.2.1
a=sendrecv
a=curr:qos e2e sendrecv
a=des:qos mandatory e2e sendrecv
Let's assume that in the middle of the session A wishes to change 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
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):
m=audio 20000 RTP/AVP 0
c=IN IP4 192.0.2.2
a=curr:qos e2e none
a=des:qos mandatory e2e sendrecv
SDP2: B includes a "conf" attribute in its answer. B continues
sending media to the old remote IP address (192.0.2.1)
m=audio 30000 RTP/AVP 0
c=IN IP4 192.0.2.4
a=curr:qos e2e none
a=des:qos mandatory e2e sendrecv
a=conf:qos e2e recv
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.2
a=curr:qos e2e send
a=des:qos mandatory e2e sendrecv
SDP4: B responds with an answer (6) indicating that the preconditions
have been met (current status "sendrecv). It is now when B begins
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 20, line 37 skipping to change at page 21, line 37
|<--------(6) 200 OK (UPDATE) SDP4-----------| |<--------(6) 200 OK (UPDATE) SDP4-----------|
| | | |
|<-----------(7) 200 OK (INVITE)-------------| |<-----------(7) 200 OK (INVITE)-------------|
| | | |
|------------------(8) ACK------------------>| |------------------(8) ACK------------------>|
| | | |
| | | |
Figure 3: Session modification with preconditions Figure 3: Session modification with preconditions
SDP1: A includes an offer in a re-INVITE (1). A continues to receive
media on the old IP address (192.0.2.1), but it is ready to receive
media on the new one as well (192.0.2.2):
m=audio 20000 RTP/AVP 0
c=IN IP4 192.0.2.2
a=curr:qos e2e none
a=des:qos mandatory e2e sendrecv
SDP2: B includes a "conf" attribute in its answer. B continues
sending media to the old remote IP address (192.0.2.1)
m=audio 30000 RTP/AVP 0
c=IN IP4 192.0.2.4
a=curr:qos e2e none
a=des:qos mandatory e2e sendrecv
a=conf:qos e2e recv
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.2
a=curr:qos e2e send
a=des:qos mandatory e2e sendrecv
SDP4: B responds with an answer (6) indicating that the preconditions
have been met (current status "sendrecv). It is now when B begins
sending media to the new remote IP address (192.0.2.2). 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
12.2 Segmented Status Type 12.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
skipping to change at page 22, line 18 skipping to change at page 22, line 37
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 (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)
has been generated. This would mean that the session is established response has been generated. This would mean that the session is
before A has reduced the number of supported codecs. To avoid this established before A has reduced the number of supported codecs. To
situation, the user agent client could wait for the first answer from avoid this situation, the user agent client could wait for the first
the user agent before setting its local current status to "sendrecv". answer from the user agent before setting its local current status to
"sendrecv".
12.3 Offer in a SIP response 12.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 example
are shown below: 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 response. Therefore, the initial offer is sent by B in a reliable 183 (Session
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
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 answer.
m=audio 30000 RTP/AVP 0
c=IN IP4 192.0.2.4
a=curr:qos e2e none
a=des:qos mandatory e2e sendrecv
a=conf:qos e2e recv
SDP2: A includes its answer if the PRACK for the 183 (Session
Progress) 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
A B A B
| *** | | *** |
| *R* | | *R* |
| *E* | | *E* |
| *S* | | *S* |
| *E* | | *E* |
| *R* | | *R* |
| *V* | | *V* |
| *A* | | *A* |
skipping to change at page 25, line 4 skipping to change at page 26, line 4
|<------------(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
"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 answer.
m=audio 30000 RTP/AVP 0
c=IN IP4 192.0.2.4
a=curr:qos e2e none
a=des:qos mandatory e2e sendrecv
a=conf:qos e2e recv
SDP2: A includes its answer if 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 After having sent the answer A starts reserving network resources for
the media stream. When B receives this answer (3) it starts the media stream. When B receives this answer (3) 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.
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
skipping to change at page 28, line 41 skipping to change at page 29, line 22
[6] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: a [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.
[7] 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,
Feb. 2002. Work in progress. Feb. 2002. Work in progress.
[8] C. Kalmanek, W. Marshall, P. Mishra, D. Nortz, and K. K. [8] C. Kalmanek, W. Marshall, P. Mishra, D. Nortz, and K. K.
Ramakrishnan, "DOSA: an architecture for providing robust IP Ramakrishnan, "DOSA: an architecture for providing robust IP
telephony service," in Proceedings of the Conference on Computer telephony service," in
Communications (IEEE Infocom) , (Tel Aviv, Israel), Mar. 2000. 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.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/