draft-ietf-sipcore-reinvite-00.txt   draft-ietf-sipcore-reinvite-01.txt 
SIPCORE G. Camarillo, Ed. SIPCORE G. Camarillo, Ed.
Internet-Draft C. Holmberg Internet-Draft C. Holmberg
Updates: 3261 (if approved) Ericsson Updates: 3261 (if approved) Ericsson
Intended status: Standards Track Y. Gao Intended status: Standards Track Y. Gao
Expires: June 13, 2010 ZTE Expires: July 23, 2010 ZTE
December 10, 2009 January 19, 2010
Re-INVITE and Target-refresh Request Handling in the Session Initiation Re-INVITE and Target-refresh Request Handling in the Session Initiation
Protocol (SIP) Protocol (SIP)
draft-ietf-sipcore-reinvite-00.txt draft-ietf-sipcore-reinvite-01.txt
Abstract Abstract
In this document, we clarify the handling of re-INVITEs in SIP. We In this document, we clarify the handling of re-INVITEs in SIP. We
clarify in which situations a UAS (User Agent Server) should generate clarify in which situations a UAS (User Agent Server) should generate
a success response and in which situations a UAS should generate an a success response and in which situations a UAS should generate an
error response to a re-INVITE. Additionally, we clarify issues error response to a re-INVITE. Additionally, we clarify issues
related to target-refresh requests. related to target-refresh requests.
Status of this Memo Status of this Memo
skipping to change at page 1, line 43 skipping to change at page 1, line 43
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
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.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on June 13, 2010. This Internet-Draft will expire on July 23, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Background on Re-INVITE Handling by UASs . . . . . . . . . . . 4 3. Re-INVITE Handling . . . . . . . . . . . . . . . . . . . . . . 4
4. Problems with Error Responses and Already-executed Changes . . 8 3.1. Background on Re-INVITE Handling by UASs . . . . . . . . . 4
5. UAS Behavior . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.2. Problems with Error Responses and Already-executed
6. UAC Behavior . . . . . . . . . . . . . . . . . . . . . . . . . 10 Changes . . . . . . . . . . . . . . . . . . . . . . . . . 8
7. Example of UAS Behavior . . . . . . . . . . . . . . . . . . . 10 3.3. UAS Behavior . . . . . . . . . . . . . . . . . . . . . . . 9
8. Example of UAC Behavior . . . . . . . . . . . . . . . . . . . 13 3.4. UAC Behavior . . . . . . . . . . . . . . . . . . . . . . . 10
9. Clarifications on Cancelling Re-INVITEs . . . . . . . . . . . 15 3.5. Glare Situations . . . . . . . . . . . . . . . . . . . . . 10
10. Background on Target-Refresh Requests . . . . . . . . . . . . 16 3.6. Example of UAS Behavior . . . . . . . . . . . . . . . . . 11
11. Clarification on the Atomicity of Target-Refresh Requests . . 16 3.7. Example of UAC Behavior . . . . . . . . . . . . . . . . . 14
12. UAC Behavior . . . . . . . . . . . . . . . . . . . . . . . . . 17 3.8. Clarifications on Cancelling Re-INVITEs . . . . . . . . . 16
13. UAS Behavior . . . . . . . . . . . . . . . . . . . . . . . . . 17 4. Target-refresh Handling . . . . . . . . . . . . . . . . . . . 17
14. Race Conditions and Target Refreshes . . . . . . . . . . . . . 18 4.1. Background on Target-refresh Requests . . . . . . . . . . 17
15. Background on re-INVITE Transaction Routing . . . . . . . . . 18 4.2. Clarification on the Atomicity of Target-Refresh
16. Problems with UAs Losing their Contact . . . . . . . . . . . . 19 Requests . . . . . . . . . . . . . . . . . . . . . . . . . 17
17. UAS Losing its Contact: UAC Behavior . . . . . . . . . . . . . 19 4.3. UAC Behavior . . . . . . . . . . . . . . . . . . . . . . . 18
18. UAC Losing its Contact: UAS Behavior . . . . . . . . . . . . . 20 4.4. UAS Behavior . . . . . . . . . . . . . . . . . . . . . . . 18
19. UAC Losing its Contact: UAC Behavior . . . . . . . . . . . . . 21 4.5. Race Conditions and Target Refreshes . . . . . . . . . . . 19
20. Security Considerations . . . . . . . . . . . . . . . . . . . 21 5. Re-INVITE Transaction Routing . . . . . . . . . . . . . . . . 20
21. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 5.1. Background on re-INVITE Transaction Routing . . . . . . . 20
22. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 5.2. Problems with UAs Losing their Contact . . . . . . . . . . 20
23. Normative References . . . . . . . . . . . . . . . . . . . . . 21 5.3. UAS Losing its Contact: UAC Behavior . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 5.4. UAC Losing its Contact: UAS Behavior . . . . . . . . . . . 21
5.5. UAC Losing its Contact: UAC Behavior . . . . . . . . . . . 22
6. Security Considerations . . . . . . . . . . . . . . . . . . . 22
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23
9. Normative References . . . . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction 1. Introduction
As discussed in Section 14 of RFC 3261 [RFC3261], an INVITE request As discussed in Section 14 of RFC 3261 [RFC3261], an INVITE request
sent within an existing dialog is known as a re-INVITE. A re-INVITE sent within an existing dialog is known as a re-INVITE. A re-INVITE
is used to modify session parameters, dialog parameters, or both. is used to modify session parameters, dialog parameters, or both.
That is, a single re-INVITE can change both the parameters of its That is, a single re-INVITE can change both the parameters of its
associated session (e.g., changing the IP address where a media associated session (e.g., changing the IP address where a media
stream is received) and the parameters of its associated dialog stream is received) and the parameters of its associated dialog
(e.g., changing the remote target of the dialog). A re-INVITE can (e.g., changing the remote target of the dialog). A re-INVITE can
skipping to change at page 3, line 34 skipping to change at page 3, line 34
the offerer. the offerer.
Certain transactions within a re-INVITE (e.g., UPDATE [RFC3311] Certain transactions within a re-INVITE (e.g., UPDATE [RFC3311]
transactions) can also have offer/answer exchanges associated to transactions) can also have offer/answer exchanges associated to
them. A UA (User Agent) can act as the offerer or the answerer in them. A UA (User Agent) can act as the offerer or the answerer in
any of these transactions regardless of whether the UA was the any of these transactions regardless of whether the UA was the
offerer or the answerer in the umbrella re-INVITE transaction. offerer or the answerer in the umbrella re-INVITE transaction.
There has been some confusion among implentors regarding how a UAS There has been some confusion among implentors regarding how a UAS
(User Agent Server) should handle re-INVITEs. In particular, (User Agent Server) should handle re-INVITEs. In particular,
implementors requested clarifications on which type of response a UAS implementors requested clarification on which type of response a UAS
should generate in different situations. In this document, we should generate in different situations. In this document, we
clarify these issues. clarify these issues.
Additionally, there has also been some confusion among implementors
regarding target refresh requests, which include but are not limited
to re-INVITEs. In this document, we also clarify the process by
which remote targets are refreshed.
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 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
UA: User Agent. UA: User Agent.
UAC: User Agent Client. UAC: User Agent Client.
UAS: User Agent Server. UAS: User Agent Server.
3. Background on Re-INVITE Handling by UASs 3. Re-INVITE Handling
The following sections discuss re-INVITE handling.
3.1. Background on Re-INVITE Handling by UASs
A UAS receiving a re-INVITE will need to, eventually, generate a A UAS receiving a re-INVITE will need to, eventually, generate a
response to it. Some re-INVITEs can be responded to immediately response to it. Some re-INVITEs can be responded to immediately
because their handling does not require user interaction (e.g., because their handling does not require user interaction (e.g.,
changing the IP address where a media stream is received). The changing the IP address where a media stream is received). The
handling of other re-INVITEs requires user interaction (e.g., adding handling of other re-INVITEs requires user interaction (e.g., adding
a video stream to an audio-only session). Therefore, these re- a video stream to an audio-only session). Therefore, these re-
INVITEs cannot be responded to immediately. INVITEs cannot be responded to immediately.
An error response to a re-INVITE has the following semantics. As An error response to a re-INVITE has the following semantics. As
specified in Section 12.2.2 of RFC 3261 [RFC3261], if a re-INVITE is specified in Section 12.2.2 of RFC 3261 [RFC3261], if a re-INVITE is
rejected, no state changes are performed. These state changes rejected, no state changes are performed. These state changes
include state changes associated to the re-INVITE transaction and all include state changes associated to the re-INVITE transaction and all
other transactions within the re-INVITE (target refreshes, which are other transactions within the re-INVITE (target refreshes, which are
discussed in Section 10, are an exception to this rule because in discussed in Section 4.1, are an exception to this rule because in
certain cases they are performed even if the re-INVITE is rejected). certain cases they are performed even if the re-INVITE is rejected).
That is, the session and dialog states are the same as before the re- That is, the session and dialog states are the same as before the re-
INVITE was received. The example in Figure 1 illustrates this point. INVITE was received. The example in Figure 1 illustrates this point.
UAC UAS UAC UAS
| | | |
|-------------(1) INVITE SDP1--------------->| |-------------(1) INVITE SDP1--------------->|
| | | |
|<------------(2) 200 OK SDP2----------------| |<------------(2) 200 OK SDP2----------------|
skipping to change at page 8, line 17 skipping to change at page 8, line 27
c=IN IP4 192.0.2.5 c=IN IP4 192.0.2.5
m=video 0 RTP/AVP 31 m=video 0 RTP/AVP 31
c=IN IP4 0.0.0.0 c=IN IP4 0.0.0.0
The UAS now returns a 200 (OK) response to the re-INVITE. The UAS now returns a 200 (OK) response to the re-INVITE.
In all the previous examples, the UAC was the offerer in the re- In all the previous examples, the UAC was the offerer in the re-
INVITE transaction. Examples with UACs acting as the answerers would INVITE transaction. Examples with UACs acting as the answerers would
be similar. be similar.
4. Problems with Error Responses and Already-executed Changes 3.2. Problems with Error Responses and Already-executed Changes
Section 3 contains examples on how a UAS rejects all the changes Section 3.1 contains examples on how a UAS rejects all the changes
requested in a re-INVITE without executing any of them by returning requested in a re-INVITE without executing any of them by returning
an error response (Figure 1), and how a UAS executes some of the an error response (Figure 1), and how a UAS executes some of the
changes requested in a re-INVITE and rejects some of them by changes requested in a re-INVITE and rejects some of them by
returning a 2xx response (Figure 2 and Figure 3). A UAS can accept returning a 2xx response (Figure 2 and Figure 3). A UAS can accept
and reject different sets of changes simultaneously (Figure 2) or at and reject different sets of changes simultaneously (Figure 2) or at
different times (Figure 3). different times (Figure 3).
The scenario that created confusion among implementors consists of a The scenario that created confusion among implementors consists of a
UAS that receives a re-INVITE, executes some of the changes requested UAS that receives a re-INVITE, executes some of the changes requested
in it, and then wants to reject all those already-executed changes in it, and then wants to reject all those already-executed changes
and revert to the pre-re-INVITE state. Such a UAS may consider and revert to the pre-re-INVITE state. Such a UAS may consider
returning an error response to the re-INVITE (the message flow would returning an error response to the re-INVITE (the message flow would
be similar to the one in Figure 1), or using an UPDATE request to be similar to the one in Figure 1), or using an UPDATE request to
revert to the pre-re-INVITE state and then returning a 2xx response revert to the pre-re-INVITE state and then returning a 2xx response
to the re-INVITE (the message flow would be similar to the one in to the re-INVITE (the message flow would be similar to the one in
Figure 3). This section explains the problems associated with Figure 3). This section explains the problems associated with
returning an error response in these circumstances. In order to returning an error response in these circumstances. In order to
avoid these problems, the UAS should use the latter option (UPDATE avoid these problems, the UAS should use the latter option (UPDATE
request plus a 2xx response). Section 5 and Section 6 contain the request plus a 2xx response). Section 3.3 and Section 3.4 contain
normative statements needed to avoid these problems. the normative statements needed to avoid these problems.
The reason for not using an error response to undo already executed The reason for not using an error response to undo already executed
changes is that an error response to a re-INVITE for which changes changes is that an error response to a re-INVITE for which changes
have already been executed is effectively requesting a change in the have already been executed is effectively requesting a change in the
session or the dialog state. However, the UAC has no means to reject session or the dialog state. However, the UAC has no means to reject
those changes if it is unable to execute them. That is, if the UAC those changes if it is unable to execute them. That is, if the UAC
is unable to revert to the pre-re-INVITE state, it will not be able is unable to revert to the pre-re-INVITE state, it will not be able
to communicate this fact to the UAS. to communicate this fact to the UAS.
Using an error response to undo already executed changes presents an 3.3. UAS Behavior
additional problem. Section 4 of [RFC3264] specifies rules to avoid
glare situations (i.e., to avoid offer/answer collisions in race
conditions). Even when both UAs generate an offer at the same time,
there are rules to determine which one should be processed first.
However, there are no rules to avoid a collision between an offer in
an UPDATE request and an error response for a re-INVITE. Since both
the UPDATE request and the error response would request changes, it
would not be clear which changes would need to be executed first.
This is yet another reason why UASs should not use error responses to
undo already-executed changes.
5. UAS Behavior
UASs should only return an error response to a re-INVITE if no UASs should only return an error response to a re-INVITE if no
changes to the session or to the dialog state have been executed changes to the session or to the dialog state have been executed
since the re-INVITE was received. Such an error response indicates since the re-INVITE was received. Such an error response indicates
that no changes have been executed as a result of the re-INVITE or that no changes have been executed as a result of the re-INVITE or
any other transaction within it. any other transaction within it.
If any of the changes requested in a re-INVITE or in any transaction If any of the changes requested in a re-INVITE or in any transaction
within it have already been executed (with the exception of target within it have already been executed (with the exception of target
refreshes), the UAS MUST always return a 2xx response. refreshes), the UAS SHOULD return a 2xx response.
A change to the session state is considered to have been executed A change to the session state is considered to have been executed if
when the new media parameters are being used. Therefore, a change to an offer/answer without preconditions [RFC4032] for the stream has
a stream subject to preconditions [RFC4032] is considered to have completed successfully or the UAs have exchanged media using the new
been executed when the new media parameters start being used; not parameters. Connection establishment messages (e.g., TCP SYN),
when the preconditions for the stream are met. Connection connectivity checks (e.g., when using ICE [I-D.ietf-mmusic-ice]), and
establishment messages (e.g., TCP SYN) and connectivity checks (e.g., any other messages used in the process of meeting the preconditions
when using ICE [I-D.ietf-mmusic-ice]) are not considered media for a stream are not considered media.
either. A UA considers the new parameters to be in use when it sends
media using them, or when media that uses the new parameters is
received, which should be interpreted as follows. From Section 8.3.1
of RFC 3264 [RFC3264]:
"Received, in this case, means that the media is passed to a media The successful completion of an offer/answer exchange without
sink. This means that if there is a playout buffer, the agent preconditions indicates that the new parameters for the media stream
would continue to listen on the old port until the media on the are already considered to be in use. The successful completion of an
new port reached the top of the playout buffer. At that time, it offer/answer exchange with preconditions means something different.
MAY cease listening for media on the old port." The fact that all mandatory preconditions for the stream are met
indicates that the new parameters for the media stream are ready to
be used. However, they will not actually be used until the UAS
decides so. During a session establishment, the UAS can wait for
using the media parameters until the callee starts being alerted or
until the callee accepts the session. During a session modification,
the UAS can wait until its user accepts the changes to the session.
When dealing with streams where the UAS sends media more or less
continuously, the UAC notices that the new parameters are in use
because the UAC receives media that uses the new parameters.
However, this mechanism does not work with other types of streams.
Therefore, it is RECOMMENDED that when a UAS decides to start using
the new parameters for a stream for which all mandatory preconditions
have been met, the UAS either sends media using the new parameters or
sends a new offer where the precondition-related attributes for the
stream have been removed. As indicated above, the successful
completion of an offer/answer exchange without preconditions
indicates that the new parameters for the media stream are already
considered to be in use.
TODO: RFC3264 assumes media streams that carry media continuously. The point a change to the dialog state is considered to have been
So, it considers that an UA should continue listening to the old port executed depends on the particular dialog parameter being modified.
(i.e., using the old parameters) until it sends media or receives The specifications of different dialog parameters describe when the
media on the new port. However, if two UASs perform an offer/answer new value of the parameter needs to be taken into use.
exchange on a stream that only carries media every now and then, the
UAs will need to be ready to receive media on both the old and the
new port for a long time. Shall we define some type of timeout for
this?
A UAS MUST NOT generate an error response to a re-INVITE if it has
generated a prior offer for which it has not yet received an answer
or a rejection.
6. UAC Behavior 3.4. UAC Behavior
A UAC that receives an error response to a re-INVITE that undoes A UAC that receives an error response to a re-INVITE that undoes
already-executed changes within the re-INVITE may be facing a legacy already-executed changes within the re-INVITE may be facing a legacy
UAS that does not support this specification (i.e., a UAS that does UAS that does not support this specification (i.e., a UAS that does
not follow the guidelines in Section 5). There are certain race not follow the guidelines in Section 3.3). There are also certain
condition situations that get both user agents out of race condition situations that get both user agents out of
synchronization. In order to cope with these race condition synchronization. In order to cope with these race condition
situations, a UAC that receives an error response to a re-INVITE for situations, a UAC that receives an error response to a re-INVITE for
which changes have been already executed SHOULD generate a new re- which changes have been already executed SHOULD generate a new re-
INVITE or UPDATE request in order to make sure that both UAs have a INVITE or UPDATE request in order to make sure that both UAs have a
common view of the state of the session. The purpose of this new common view of the state of the dialog and the session (the UAC uses
offer/answer exchange is to synchronize both UAs, not to request the criteria in Section 3.3 in order to decide whether or not changes
changes that the UAS may choose to reject. Therefore, the session have been executed for the stream). The purpose of this new offer/
parameters in the offer/answer exchange SHOULD be as close as those answer exchange is to synchronize both UAs, not to request changes
in the pre-re-INVITE state as possible. that the UAS may choose to reject. Therefore, the dialog parameters
and the session parameters in the offer/answer exchange SHOULD be as
close as those in the pre-re-INVITE state as possible.
7. Example of UAS Behavior 3.5. Glare Situations
This section contains an example of a UAS that supports this Section 4 of RFC 3264 [RFC3264] specifies rules to avoid and detect
glare situations (i.e., to avoid offer/answer collisions in race
conditions). Section 14.1 of RFC 3261 [RFC3261] specifies general
rules to handle glare situations in SIP. Section 5.1 of RFC 3311
[RFC3311] specifies when UPDATE requests can be sent. The specified
rules include, among other things, procedures to cope with situations
where both UAs generate an offer at the same time. However, there
are no rules to avoid a collision between an offer in an UPDATE
request and an error response to a re-INVITE. Since both the UPDATE
request and the error response could be requesting changes, it would
not be clear which changes would need to be executed first. The
following rules avoid types of glare conditions that were not covered
by previous specifications.
When checking for glare situations, UAs MUST treat the exchange of a
non-2xx final response to a re-INVITE and its corresponding ACK
request as an offer/answer exchange. Consequently, the rules
regarding glare situations applicable to offer/answer exchanges are
also applicable to those exchanges. These rules imply that if the
UAS of a re-INVITE transaction receives and UPDATE request with an
offer after having sent a non-2xx final response to the re-INVITE but
before having received the corresponding ACK request, the UA SHOULD
return a 491 (Request Pending) response to the UPDATE request. If
the UAC of a re-INVITE transaction sends an UPDATE request with an
offer, receives a non-2xx response to the re-INVITE, and then a 2xx
response to the UPDATE request, the UA SHOULD generate a new re-
INVITE or UPDATE request in order to make sure that both UAs have a
common view of the state of the session, as described in Section 3.4.
An UPDATE request without an offer can change dialog parameters. So
can a non-2xx final response to a re-INVITE request or a 2xx response
to an INVITE request (re-INVITE or initial INVITE). However, there
are no rules to avoid a collision between an offerless UPDATE request
and a final response to an INVITE request. The rules in Section 4.5,
which are given in the context of target refreshes, cover these types
of collisions as well. Therefore, there is no need to specify
further rules here.
3.6. Example of UAS Behavior
This section contains an example of a UAS that implements this
specification using an UPDATE request and a 2xx response to a re- specification using an UPDATE request and a 2xx response to a re-
INVITE in order to revert to the pre-re-INVITE state. The example, INVITE in order to revert to the pre-re-INVITE state. The example,
which is shown in Figure 4, assumes that the UAS requires its user's which is shown in Figure 4, assumes that the UAS requires its user's
input in order to accept or reject the addition of a video stream and input in order to accept or reject the addition of a video stream and
uses reliable provisional responses [RFC3262] (PRACK transactions are uses reliable provisional responses [RFC3262] (PRACK transactions are
not shown for clarity). not shown for clarity).
UAC UAS UAC UAS
| | | |
skipping to change at page 13, line 18 skipping to change at page 14, line 18
SDP8: SDP8:
m=audio 30000 RTP/AVP 0 m=audio 30000 RTP/AVP 0
c=IN IP4 192.0.2.1 c=IN IP4 192.0.2.1
m=video 0 RTP/AVP 31 m=video 0 RTP/AVP 31
c=IN IP4 192.0.2.1 c=IN IP4 192.0.2.1
The UAS now returns a 200 (OK) response (10) to the re-INVITE. Note The UAS now returns a 200 (OK) response (10) to the re-INVITE. Note
that the media state after this 200 (OK) response is the same as the that the media state after this 200 (OK) response is the same as the
pre-re-INVITE media state. pre-re-INVITE media state.
8. Example of UAC Behavior 3.7. Example of UAC Behavior
Figure 5 shows an example of a race condition situation in which the Figure 5 shows an example of a race condition situation in which the
UAs end up with different views of the state of the session. The UAs UAs end up with different views of the state of the session. The UAs
in Figure 5 are involved in a session that, just before the message in Figure 5 are involved in a session that, just before the message
flows in the figures starts, includes a sendrecv audio stream and an flows in the figures starts, includes a sendrecv audio stream and an
inactive video stream. UA1 sends a re-INVITE (1) requesting to make inactive video stream. UA1 sends a re-INVITE (1) requesting to make
the video stream sendrecv. the video stream sendrecv.
SDP1: SDP1:
m=audio 20000 RTP/AVP 0 m=audio 20000 RTP/AVP 0
a=sendrecv a=sendrecv
m=video 20002 RTP/AVP 31 m=video 20002 RTP/AVP 31
a=sendrecv a=sendrecv
UA2 is configured to automatically accept incoming video streams but UA2 is configured to automatically accept incoming video streams but
to ask for user input before generating an outgoing video stream. to ask for user input before generating an outgoing video stream.
Therefore, UAS2 makes the video stream sendonly by returning a 183 Therefore, UAS2 makes the video stream recvonly by returning a 183
(Session Progress) response (2). (Session Progress) response (2).
SDP2: SDP2:
m=audio 30000 RTP/AVP 0 m=audio 30000 RTP/AVP 0
a=sendrecv a=sendrecv
m=video 30002 RTP/AVP 31 m=video 30002 RTP/AVP 31
a=sendonly a=recvonly
When asked for input, UA2's user chooses not to have either incoming When asked for input, UA2's user chooses not to have either incoming
or outgoing video. In order to make the video stream inactive, UA2 or outgoing video. In order to make the video stream inactive, UA2
returns a 4xx error response (5) to the re-INVITE. The ACK request returns a 4xx error response (5) to the re-INVITE. The ACK request
(6) for this error response is generated by the proxy between both (6) for this error response is generated by the proxy between both
user agents. Note that this error response undoes already-executed user agents. Note that this error response undoes already-executed
changes. So, UA2 is a legacy UA that does not support this changes. So, UA2 is a legacy UA that does not support this
specification. specification.
The proxy relays the 4xx response (7) towards UA1. However, the 4xx The proxy relays the 4xx response (7) towards UA1. However, the 4xx
skipping to change at page 15, line 43 skipping to change at page 16, line 43
After the message flow in Figure 5, following the recommendations in After the message flow in Figure 5, following the recommendations in
this section, when UA1 received an error response (7) that undid this section, when UA1 received an error response (7) that undid
already-executed changes, UA1 would generate an UPDATE request with already-executed changes, UA1 would generate an UPDATE request with
an SDP reflecting the pre-re-INVITE state (i.e., sendrecv audio and an SDP reflecting the pre-re-INVITE state (i.e., sendrecv audio and
inactive video). UA2 could then return a 200 (OK) response to the inactive video). UA2 could then return a 200 (OK) response to the
UPDATE request making the audio stream recvonly, which is the state UPDATE request making the audio stream recvonly, which is the state
UA2's user had requested. Such an UPDATE transaction would get the UA2's user had requested. Such an UPDATE transaction would get the
UAs back into synchronization. UAs back into synchronization.
9. Clarifications on Cancelling Re-INVITEs 3.8. Clarifications on Cancelling Re-INVITEs
Section 9.2 of RFC 3261 [RFC3261] specifies the behavior of a UAS Section 9.2 of RFC 3261 [RFC3261] specifies the behavior of a UAS
responding to a CANCEL request. Such a UAS responds to the INVITE responding to a CANCEL request. Such a UAS responds to the INVITE
request with a 487 (Request Terminated) at the 'should' level. Per request with a 487 (Request Terminated) at the 'should' level. Per
the rules specified in Section 5, if the INVITE request was a re- the rules specified in Section 3.3, if the INVITE request was a re-
INVITE and some of its requested changes had already been executed, INVITE and some of its requested changes had already been executed,
the UAS would return a 2xx response instead. the UAS would return a 2xx response instead.
10. Background on Target-Refresh Requests 4. Target-refresh Handling
The following sections discuss target-refresh request handling.
4.1. Background on Target-refresh Requests
A target-refresh request is defined as follows in Section 6 of RFC A target-refresh request is defined as follows in Section 6 of RFC
3261 [RFC3261]: 3261 [RFC3261]:
"A target-refresh request sent within a dialog is defined as a "A target-refresh request sent within a dialog is defined as a
request that can modify the remote target of the dialog." request that can modify the remote target of the dialog."
Additionally, 2xx responses to target-refresh requests can also Additionally, 2xx responses to target-refresh requests can also
update the remote target of the dialog.. As discussed in Section update the remote target of the dialog. As discussed in Section 12.2
12.2 of RFC 3261 [RFC3261], re-INVITEs are target-refresh requests. of RFC 3261 [RFC3261], re-INVITEs are target-refresh requests.
RFC 3261 [RFC3261] specifies the behavior of UASs receiving target- RFC 3261 [RFC3261] specifies the behavior of UASs receiving target-
refresh requests and of UACs receiving a 2xx response for a target- refresh requests and of UACs receiving a 2xx response for a target-
refresh request. refresh request.
Section 12.2.2 of RFC 3261 [RFC3261] says: Section 12.2.2 of RFC 3261 [RFC3261] says:
"When a UAS receives a target-refresh request, it MUST replace the "When a UAS receives a target-refresh request, it MUST replace the
dialog's remote target URI with the URI from the Contact header dialog's remote target URI with the URI from the Contact header
field in that request, if present." field in that request, if present."
Section 12.2.1.2 of RFC 3261 [RFC3261] says: Section 12.2.1.2 of RFC 3261 [RFC3261] says:
"When a UAC receives a 2xx response to a target-refresh request, "When a UAC receives a 2xx response to a target-refresh request,
it MUST replace the dialog's remote target URI with the URI from it MUST replace the dialog's remote target URI with the URI from
the Contact header field in that response, if present." the Contact header field in that response, if present."
The fact that re-INVITEs can be long-lived transactions and can have The fact that re-INVITEs can be long-lived transactions and can have
other transactions within them makes it necessary to revise these other transactions within them makes it necessary to revise these
rules. Section 11 specifies new rules for the handing of target- rules. Section 4.2 specifies new rules for the handing of target-
refresh requests. Note that the new rules apply to any target- refresh requests. Note that the new rules apply to any target-
refresh request, not only to re-INVITEs. refresh request, not only to re-INVITEs.
11. Clarification on the Atomicity of Target-Refresh Requests 4.2. Clarification on the Atomicity of Target-Refresh Requests
The remote target of a dialog is a special type of state information The remote target of a dialog is a special type of state information
because of its essential role in the exchange of SIP messages between because of its essential role in the exchange of SIP messages between
UAs in a dialog. A UA involved in a dialog receives the remote UAs in a dialog. A UA involved in a dialog receives the remote
target of the dialog from the remote UA. The UA uses the remote target of the dialog from the remote UA. The UA uses the remote
target to send SIP requests to the remote UA. target to send SIP requests to the remote UA.
The remote target is a piece of state information that is not meant The remote target is a piece of state information that is not meant
to be negotiated. When a UAC changes its address, the UAC simply to be negotiated. When a UAC changes its address, the UAC simply
communicates its new address to the UAS in order to remain reachable communicates its new address to the UAS in order to remain reachable
by the UAS. UAs need to follow the behavior specified in Section 12 by the UAS. UAs need to follow the behavior specified in Section 4.3
and Section 12 instead of that specified in RFC 3261 [RFC3261] and and Section 4.4 of this specification instead of that specified in
discussed in Section 10. The new behavior regarding target-refresh RFC 3261 [RFC3261], which was discussed in Section 4.1. The new
requests implies that a target-refresh request can, in some cases, behavior regarding target-refresh requests implies that a target-
update the remote target even if the request is responded with a refresh request can, in some cases, update the remote target even if
final error response. This means that target-refresh requests are the request is responded with a final error response. This means
not atomic. that target-refresh requests are not atomic.
12. UAC Behavior 4.3. UAC Behavior
Behavior of a UAC after having sent a target-refresh request updating Behavior of a UAC after having sent a target-refresh request updating
the remote target: the remote target:
If the UAC receives an error response to the target-refresh request, If the UAC receives an error response to the target-refresh request,
the UAS has not updated its remote target. the UAS has not updated its remote target.
This allows UASs to authenticate target-refresh requests. This allows UASs to authenticate target-refresh requests.
If the UAC receives a reliable provisional response or a 2xx response If the UAC receives a reliable provisional response or a 2xx response
skipping to change at page 17, line 38 skipping to change at page 18, line 41
If the UAC receives a reliable provisional response or a 2xx response If the UAC receives a reliable provisional response or a 2xx response
to the target-refresh request, the UAC MUST replace the dialog's to the target-refresh request, the UAC MUST replace the dialog's
remote target URI with the URI from the Contact header field in that remote target URI with the URI from the Contact header field in that
response, if present. response, if present.
When interacting with a UACs that does not support reliable When interacting with a UACs that does not support reliable
provisional responses or UPDATE requests, a UAC SHOULD NOT use the provisional responses or UPDATE requests, a UAC SHOULD NOT use the
same target refresh request to refresh the target and to make session same target refresh request to refresh the target and to make session
changes unless the session changes can be trivially accepted by the changes unless the session changes can be trivially accepted by the
UAS (e.g., a change IP address change). Piggybacking a target UAS (e.g., an IP address change). Piggybacking a target refresh with
refresh with more complicated session changes in this situation would more complicated session changes in this situation would make it
make it unnecessarily complicated for the UAS to accept the target unnecessarily complicated for the UAS to accept the target refresh
refresh while rejecting the session changes. while rejecting the session changes.
13. UAS Behavior 4.4. UAS Behavior
Behavior of a UAS after having received a target-refresh request Behavior of a UAS after having received a target-refresh request
updating the remote target: updating the remote target:
If the UAS receives a target-refresh request that has been properly If the UAS receives a target-refresh request that has been properly
authenticated, the UAS SHOULD generate a reliable provisional authenticated, the UAS SHOULD generate a reliable provisional
response or a 2xx response to the target-refresh request. If response or a 2xx response to the target-refresh request. If
generating such responses is not possible (e.g., the UAS does not generating such responses is not possible (e.g., the UAS does not
support reliable provisional responses and needs user input before support reliable provisional responses and needs user input before
generating a final response), the UAS SHOULD send a request to the generating a final response), the UAS SHOULD send a request to the
skipping to change at page 18, line 25 skipping to change at page 19, line 26
Reliable provisional responses in SIP are specified in RFC 3262 Reliable provisional responses in SIP are specified in RFC 3262
[RFC3262]. In this document, reliable provisional responses are [RFC3262]. In this document, reliable provisional responses are
those that use the mechanism defined in RFC 3262 [RFC3262] on any those that use the mechanism defined in RFC 3262 [RFC3262] on any
other SIP-based mechanism that may be specified in the future. other SIP-based mechanism that may be specified in the future.
Other specifications may define ways to send provisional responses Other specifications may define ways to send provisional responses
reliably using non-SIP mechanisms (e.g., using media-level reliably using non-SIP mechanisms (e.g., using media-level
messages to acknowledge the reception of the SIP response). For messages to acknowledge the reception of the SIP response). For
the purposes of this document, provisional responses using those the purposes of this document, provisional responses using those
non-SIP mechanisms are considered unreliable responses. non-SIP mechanisms are considered unreliable responses.
If before sending a reliable provisional response or a 2xx response If instead sending a reliable provisional response or a 2xx response
to the target-refresh request, or a request to the new target, the to the target-refresh request, or a request to the new target, the
UAS generates an error response to the target-refresh request, the UAS generates an error response to the target-refresh request, the
UAS MUST NOT update its dialog's remote target. UAS MUST NOT update its dialog's remote target.
14. Race Conditions and Target Refreshes 4.5. Race Conditions and Target Refreshes
TODO: this is a corner case but we should describe it anyway. A UA SIP provides request ordering by using the Cseq header field. That
that changes its own contact twice in a row may create a race is, a UAS that receives two requests at roughly the same time can
condition if, for example, the first time it refreshes it using a 2xx know which one is newer. However, SIP does not provide ordering
response (to an UPDATE or a re-INVITE) and the second with an UPDATE. between responses and requests. For example, if a UA receives a 200
If the offer/answer glare-avoidance rules do not apply (and they (OK) response to an UPDATE request and an UPDATE request at roughly
don't if there is no offer/answer exchange), the remote UA could the same time, the UA cannot know which one was sent last. Since
receive first the UPDATE and then the 2xx response for the previous both messages can refresh the remote target, the UA needs to know
request. which message was sent last in order to know which remote target
needs to be used.
15. Background on re-INVITE Transaction Routing Some of the procedures discussed in Section 3.5 could avoid these
types of situations. However, they are currently defined only for
SIP messages involved in offer/answer exchanges (e.g., the procedures
do not apply to an UPDATE request that does not carry an offer). The
following rules make those procedures applicable to the race
conditions described above so that UASs can cope with them.
When checking for glare situations, UAs MUST treat every UPDATE
request as if it contained an offer. Additionally, UAs MUST treat
the exchange of a 2xx response to an INVITE request and its
corresponding ACK request as an offer/answer exchange. Consequently,
the rules regarding glare situations applicable to offer/answer
exchanges are also applicable to those exchanges.
5. Re-INVITE Transaction Routing
The following sections discuss re-INVITE transaction routing.
5.1. Background on re-INVITE Transaction Routing
Re-INVITEs are routed using the dialog's route set, which contains Re-INVITEs are routed using the dialog's route set, which contains
all the proxy servers that need to be traversed by requests send all the proxy servers that need to be traversed by requests send
within the dialog. Responses to the re-INVITE are routed using the within the dialog. Responses to the re-INVITE are routed using the
Via entries in the re-INVITE. Via entries in the re-INVITE.
ACK requests for 2xx responses and for non-2xx final responses are ACK requests for 2xx responses and for non-2xx final responses are
generated in different ways. As specified in Sections 14.1 and generated in different ways. As specified in Sections 14.1 and
13.2.1 of RFC 3261 [RFC3261], ACK requests for 2xx responses are 13.2.1 of RFC 3261 [RFC3261], ACK requests for 2xx responses are
generated by the UAC core and are routed using the dialog's route generated by the UAC core and are routed using the dialog's route
set. As specified in Section 17.1.1.2 of RFC 3261 [RFC3261], ACK set. As specified in Section 17.1.1.2 of RFC 3261 [RFC3261], ACK
requests for non-2xx final responses are generated by the INVITE requests for non-2xx final responses are generated by the INVITE
client transaction (i.e., they are generated in a hop-by-hop fashion client transaction (i.e., they are generated in a hop-by-hop fashion
by the proxy servers in the path) and are sent to the same transport by the proxy servers in the path) and are sent to the same transport
address as the re-INVITE. address as the re-INVITE.
16. Problems with UAs Losing their Contact 5.2. Problems with UAs Losing their Contact
Refreshing the dialog's remote target during a re-INVITE transaction Refreshing the dialog's remote target during a re-INVITE transaction
(see Section 11) presents some issues because of the fact that Re- (see Section 4.2) presents some issues because of the fact that Re-
INVITE transactions can be long lived. As described in Section 15, INVITE transactions can be long lived. As described in Section 5.1,
the way responses to the re-INVITE and ACKs for non-2xx final the way responses to the re-INVITE and ACKs for non-2xx final
responses are routed is fixed once the re-INVITE is sent. The responses are routed is fixed once the re-INVITE is sent. The
routing of this messages does not depend on the dialog's route set routing of this messages does not depend on the dialog's route set
and, thus, target refreshes within an ongoing re-INVITE do not affect and, thus, target refreshes within an ongoing re-INVITE do not affect
their routing. A UA that changes its location (i.e., performs a their routing. A UA that changes its location (i.e., performs a
target refresh) but is still reachable at its old location will be target refresh) but is still reachable at its old location will be
able to receive those messages (which will be sent to the old able to receive those messages (which will be sent to the old
location). However, a UA that cannot be reachable at its old location). However, a UA that cannot be reachable at its old
location any longer will not be able to receive them. location any longer will not be able to receive them.
17. UAS Losing its Contact: UAC Behavior 5.3. UAS Losing its Contact: UAC Behavior
When a UAS that moves to a new contact and loses its old contact When a UAS that moves to a new contact and loses its old contact
generates a non-2xx final response to the re-INVITE, it will not be generates a non-2xx final response to the re-INVITE, it will not be
able to receive the ACK request. The entity receiving the response able to receive the ACK request. The entity receiving the response
and, thus, generating the ACK request will either get a transport and, thus, generating the ACK request will either get a transport
error or a timeout error, which, as described in Section 8.1.3.1 of error or a timeout error, which, as described in Section 8.1.3.1 of
RFC 3261 [RFC3261], will be treated as a 503 (Service Unavailable) RFC 3261 [RFC3261], will be treated as a 503 (Service Unavailable)
response and as a 408 (Request Timeout) response, respectively. If response and as a 408 (Request Timeout) response, respectively. If
the sender of the ACK request is a proxy server, it will typically the sender of the ACK request is a proxy server, it will typically
ignore this error. If the sender of the ACK request is the UAC, ignore this error. If the sender of the ACK request is the UAC,
skipping to change at page 20, line 5 skipping to change at page 21, line 20
to (at the "should" level) terminate the dialog by sending a BYE to (at the "should" level) terminate the dialog by sending a BYE
request. However, because of the special properties of ACK requests request. However, because of the special properties of ACK requests
for non-2xx final responses, most existing UACs do not terminate the for non-2xx final responses, most existing UACs do not terminate the
dialog when ACK request fails, which is fortunate. dialog when ACK request fails, which is fortunate.
A UAC that accepts a target refresh within a re-INVITE MUST ignore A UAC that accepts a target refresh within a re-INVITE MUST ignore
transport and timeout errors when generating an ACK request for a transport and timeout errors when generating an ACK request for a
non-2xx final response if the UAC is communicating directly with the non-2xx final response if the UAC is communicating directly with the
UAS (i.e., there are no proxy servers in the dialog's route set). UAS (i.e., there are no proxy servers in the dialog's route set).
18. UAC Losing its Contact: UAS Behavior 5.4. UAC Losing its Contact: UAS Behavior
When a UAC moves to a new contact and loses its old contact, it will When a UAC moves to a new contact and loses its old contact, it will
not be able to receive responses to the re-INVITE. Consequently, it not be able to receive responses to the re-INVITE. Consequently, it
will never generate an ACK request. will never generate an ACK request.
As described in Section 16.9 of RFC 3261 [RFC3261], a proxy server As described in Section 16.9 of RFC 3261 [RFC3261], a proxy server
that gets an error when forwarding a response does not take any that gets an error when forwarding a response does not take any
measurements. Consequently, proxy servers relaying responses will measurements. Consequently, proxy servers relaying responses will
effectively ignore the error. effectively ignore the error.
skipping to change at page 21, line 5 skipping to change at page 22, line 20
accepting the incoming re-INVITE, the remote UA indicates that the accepting the incoming re-INVITE, the remote UA indicates that the
old re-INVITE transaction has already been terminated. old re-INVITE transaction has already been terminated.
A 500 (Server Internal Error) response to the new re-INVITE would A 500 (Server Internal Error) response to the new re-INVITE would
mean that the remote UA was still processing the original re-INVITE. mean that the remote UA was still processing the original re-INVITE.
This may be because the remote UA is a legacy UA that does not This may be because the remote UA is a legacy UA that does not
support this specification. In this situation, the UA SHOULD follow support this specification. In this situation, the UA SHOULD follow
the original recommendation in RFC 3261 [RFC3261] and terminate the the original recommendation in RFC 3261 [RFC3261] and terminate the
dialog. dialog.
19. UAC Losing its Contact: UAC Behavior 5.5. UAC Losing its Contact: UAC Behavior
When a UAC moves to a new contact and loses its old contact, it will When a UAC moves to a new contact and loses its old contact, it will
not be able to receive responses to the re-INVITE. Consequently, it not be able to receive responses to the re-INVITE. Consequently, it
will never generate an ACK request. will never generate an ACK request.
Such a UAC SHOULD generate a CANCEL request to cancel the re-INVITE Such a UAC SHOULD generate a CANCEL request to cancel the re-INVITE
and cause the INVITE client transaction corresponding to the re- and cause the INVITE client transaction corresponding to the re-
INVITE to enter the "Terminated" state. The UAC SHOULD also send a INVITE to enter the "Terminated" state. The UAC SHOULD also send a
new re-INVITE in order to make sure that both UAs have a common view new re-INVITE in order to make sure that both UAs have a common view
of the state of the session. of the state of the session.
Per Section 14.2 of RFC 3261 [RFC3261], the UAS will accept new Per Section 14.2 of RFC 3261 [RFC3261], the UAS will accept new
incoming re-INVITEs as soon as it has generated a final response incoming re-INVITEs as soon as it has generated a final response
to the previous INVITE request, which had a lower CSeq sequence to the previous INVITE request, which had a lower CSeq sequence
number. number.
20. Security Considerations 6. Security Considerations
This document does not introduce any new security issue. It just This document does not introduce any new security issue. It just
clarifies how certain transactions should be handled in SIP. clarifies how certain transactions should be handled in SIP.
Security issues related to re-INVITEs and UPDATE requests are Security issues related to re-INVITEs and UPDATE requests are
discussed in RFC 3261 [RFC3261] and RFC 3311 [RFC3311]. discussed in RFC 3261 [RFC3261] and RFC 3311 [RFC3311].
21. IANA Considerations 7. IANA Considerations
There are no IANA actions associated with this document. There are no IANA actions associated with this document.
22. Acknowledgements 8. Acknowledgements
Paul Kyzivat provided useful ideas on the topics discussed in this Paul Kyzivat provided useful ideas on the topics discussed in this
document. document.
23. Normative References 9. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
[RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of [RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of
 End of changes. 48 change blocks. 
129 lines changed or deleted 204 lines changed or added

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