draft-ietf-sipcore-reinvite-04.txt   draft-ietf-sipcore-reinvite-05.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: November 9, 2010 ZTE Expires: January 27, 2011 ZTE
May 8, 2010 July 26, 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-04.txt draft-ietf-sipcore-reinvite-05.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 37 skipping to change at page 1, line 37
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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."
This Internet-Draft will expire on November 9, 2010. This Internet-Draft will expire on January 27, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 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 Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Re-INVITE Handling . . . . . . . . . . . . . . . . . . . . . . 4 3. Changing the Session State During a Re-INVITE . . . . . . . . 4
3.1. Background on Re-INVITE Handling by UASs . . . . . . . . . 4 3.1. Background on Re-INVITE Handling by UASs . . . . . . . . . 4
3.2. Problems with Error Responses and Already-executed 3.2. Problems with Error Responses and Already-executed
Changes . . . . . . . . . . . . . . . . . . . . . . . . . 8 Changes . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.3. UAS Behavior . . . . . . . . . . . . . . . . . . . . . . . 9 3.3. UAS Behavior . . . . . . . . . . . . . . . . . . . . . . . 9
3.4. UAC Behavior . . . . . . . . . . . . . . . . . . . . . . . 10 3.4. UAC Behavior . . . . . . . . . . . . . . . . . . . . . . . 10
3.5. Glare Situations . . . . . . . . . . . . . . . . . . . . . 11 3.5. Glare Situations . . . . . . . . . . . . . . . . . . . . . 11
3.6. Example of UAS Behavior . . . . . . . . . . . . . . . . . 11 3.6. Example of UAS Behavior . . . . . . . . . . . . . . . . . 11
3.7. Example of UAC Behavior . . . . . . . . . . . . . . . . . 14 3.7. Example of UAC Behavior . . . . . . . . . . . . . . . . . 14
3.8. Clarifications on Cancelling Re-INVITEs . . . . . . . . . 16 3.8. Clarifications on Cancelling Re-INVITEs . . . . . . . . . 16
4. Target-refresh Handling . . . . . . . . . . . . . . . . . . . 17 4. Refreshing a Dialog's Targets . . . . . . . . . . . . . . . . 17
4.1. Background on Target-refresh Requests . . . . . . . . . . 17 4.1. Background and Terminology on a Dialog's Targets . . . . . 17
4.2. Clarification on the Atomicity of Target-Refresh 4.2. Background on Target-refresh Requests . . . . . . . . . . 17
Requests . . . . . . . . . . . . . . . . . . . . . . . . . 17 4.3. Clarification on the Atomicity of Target-Refresh
4.3. UAC Behavior . . . . . . . . . . . . . . . . . . . . . . . 18 Requests . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.4. UAS Behavior . . . . . . . . . . . . . . . . . . . . . . . 18 4.4. UA Updating the Dialog's Local Target in a Request . . . . 18
4.5. Race Conditions and Target Refreshes . . . . . . . . . . . 19 4.5. UA Updating the Dialog's Local Target in a Response . . . 19
5. Re-INVITE Transaction Routing . . . . . . . . . . . . . . . . 20 4.6. A Request Updating the Dialog's Remote Target . . . . . . 19
5.1. Background on re-INVITE Transaction Routing . . . . . . . 20 4.7. A Response Updating the Dialog's Remote Target . . . . . . 20
5.2. Problems with UAs Losing their Contact . . . . . . . . . . 20 4.8. Race Conditions and Target Refreshes . . . . . . . . . . . 20
5.3. UAS Losing its Contact: UAC Behavior . . . . . . . . . . . 20 4.9. Early Dialogs . . . . . . . . . . . . . . . . . . . . . . 20
5.4. UAC Losing its Contact: UAS Behavior . . . . . . . . . . . 21 5. A UA Losing its Contact . . . . . . . . . . . . . . . . . . . 21
5.5. UAC Losing its Contact: UAC Behavior . . . . . . . . . . . 22 5.1. Background on re-INVITE Transaction Routing . . . . . . . 21
6. Security Considerations . . . . . . . . . . . . . . . . . . . 22 5.2. Problems with UAs Losing their Contact . . . . . . . . . . 21
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 5.3. UAS Losing its Contact: UAC Behavior . . . . . . . . . . . 22
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 5.4. UAC Losing its Contact: UAS Behavior . . . . . . . . . . . 22
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 5.5. UAC Losing its Contact: UAC Behavior . . . . . . . . . . . 23
9.1. Normative References . . . . . . . . . . . . . . . . . . . 23 6. Security Considerations . . . . . . . . . . . . . . . . . . . 23
9.2. Informative References . . . . . . . . . . . . . . . . . . 23 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
9.1. Normative References . . . . . . . . . . . . . . . . . . . 24
9.2. Informative References . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25
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 4, line 12 skipping to change at page 4, line 12
UAC: User Agent Client. UAC: User Agent Client.
UAS: User Agent Server. UAS: User Agent Server.
Note that the terms UAC and UAS are used with respect to an INVITE Note that the terms UAC and UAS are used with respect to an INVITE
or re-INVITE transaction and do not necessarily reflect the role or re-INVITE transaction and do not necessarily reflect the role
of the UA concerned with respect to any other transaction, such as of the UA concerned with respect to any other transaction, such as
an UPDATE transaction occurring within the INVITE transaction. an UPDATE transaction occurring within the INVITE transaction.
3. Re-INVITE Handling 3. Changing the Session State During a Re-INVITE
The following sections discuss re-INVITE handling. The following sections discuss how to change the state of the session
during a re-INVITE transaction.
3.1. Background on Re-INVITE Handling by UASs 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 (this section deals with
discussed in Section 4.1, are an exception to this rule because in changes to the session state; target refreshes are discussed in
certain cases they are performed even if the re-INVITE is rejected). Section 4.2). That is, the session state is the same as before the
That is, the session and dialog states are the same as before the re- re-INVITE was received. The example in Figure 1 illustrates this
INVITE was received. The example in Figure 1 illustrates this point. point.
UAC UAS UAC UAS
| | | |
|-------------(1) INVITE SDP1--------------->| |-------------(1) INVITE SDP1--------------->|
| | | |
|<------------(2) 200 OK SDP2----------------| |<------------(2) 200 OK SDP2----------------|
| | | |
|------------------(3) ACK------------------>| |------------------(3) ACK------------------>|
| | | |
skipping to change at page 5, line 40 skipping to change at page 5, line 40
SDP2: SDP2:
m=audio 31000 RTP/AVP 0 m=audio 31000 RTP/AVP 0
At a later point, the UAC sends a re-INVITE (4) in order to add a At a later point, the UAC sends a re-INVITE (4) in order to add a
video stream to the session. video stream to the session.
SDP3: SDP3:
m=audio 30000 RTP/AVP 0 m=audio 30000 RTP/AVP 0
m=video 30002 RTP/AVP 31 m=video 30002 RTP/AVP 31
The UAS is automatically configured to reject video streams. The UAS is configured to automatically reject video streams.
Consequently, the UAS returns an error response (5). At that point, Consequently, the UAS returns an error response (5). At that point,
the session parameters in use are still those resulting from the the session parameters in use are still those resulting from the
initial offer/answer exchange, which are described by SDP1 and SDP2. initial offer/answer exchange, which are described by SDP1 and SDP2.
That is, the session and dialog states are the same as before the re- That is, the session state is the same as before the re-INVITE was
INVITE was received. received.
In the previous example, the UAS rejected all the changes requested In the previous example, the UAS rejected all the changes requested
in the re-INVITE by returning an error response. However, there are in the re-INVITE by returning an error response. However, there are
situations where a UAS wants to accept some but not all the changes situations where a UAS wants to accept some but not all the changes
requested in a re-INVITE. In these cases, the UAS generates a 200 requested in a re-INVITE. In these cases, the UAS generates a 200
(OK) response with an SDP indicating which changes were accepted and (OK) response with an SDP indicating which changes were accepted and
which were not. The example in Figure 2 illustrates this point. which were not. The example in Figure 2 illustrates this point.
UAC UAS UAC UAS
skipping to change at page 9, line 23 skipping to change at page 9, line 23
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 3.3 and Section 3.4 contain request plus a 2xx response). Section 3.3 and Section 3.4 contain
the 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 (e.g., as a result of UPDATE transactions
session or the dialog state. However, the UAC has no means to reject or reliable provisional responses) is effectively requesting a change
those changes if it is unable to execute them. That is, if the UAC in the session state. However, the UAC has no means to reject that
is unable to revert to the pre-re-INVITE state, it will not be able change if it is unable to execute them. That is, if the UAC is
to communicate this fact to the UAS. unable to revert to the pre-re-INVITE state, it will not be able to
communicate this fact to the UAS.
3.3. UAS Behavior 3.3. 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 state have been executed since the re-INVITE
since the re-INVITE was received. Such an error response indicates was received. Such an error response indicates that no changes have
that no changes have been executed as a result of the re-INVITE or been executed as a result of the re-INVITE or any other transaction
any other transaction within it. 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, the UAS SHOULD return a 2xx
refreshes), the UAS SHOULD return a 2xx response. response.
A change to the session state is considered to have been executed if A change to the session state is considered to have been executed if
an offer/answer without preconditions [RFC4032] for the stream has an offer/answer without preconditions [RFC4032] for the stream has
completed successfully or the UAs have exchanged media using the new completed successfully or the UA has sent or received media using the
parameters. Connection establishment messages (e.g., TCP SYN), new parameters. Connection establishment messages (e.g., TCP SYN),
connectivity checks (e.g., when using ICE [RFC5245]), and any other connectivity checks (e.g., when using ICE [RFC5245]), and any other
messages used in the process of meeting the preconditions for a messages used in the process of meeting the preconditions for a
stream are not considered media. stream are not considered media.
Normally, a UA receiving media can easily detect when the new Normally, a UA receiving media can easily detect when the new
parameters for the media stream are used (e.g,. media is received parameters for the media stream are used (e.g,. media is received
on a new port). However, in some scenarios the UA will have to on a new port). However, in some scenarios the UA will have to
process incoming media packets in order to detect whether they use process incoming media packets in order to detect whether they use
the old or the new parameters. the old or the new parameters.
skipping to change at page 10, line 31 skipping to change at page 10, line 35
However, this mechanism does not work with other types of streams. However, this mechanism does not work with other types of streams.
Therefore, it is RECOMMENDED that when a UAS decides to start using Therefore, it is RECOMMENDED that when a UAS decides to start using
the new parameters for a stream for which all mandatory preconditions the new parameters for a stream for which all mandatory preconditions
have been met, the UAS either sends media using the new parameters or have been met, the UAS either sends media using the new parameters or
sends a new offer where the precondition-related attributes for the sends a new offer where the precondition-related attributes for the
stream have been removed. As indicated above, the successful stream have been removed. As indicated above, the successful
completion of an offer/answer exchange without preconditions completion of an offer/answer exchange without preconditions
indicates that the new parameters for the media stream are already indicates that the new parameters for the media stream are already
considered to be in use. considered to be in use.
The point a change to the dialog state is considered to have been
executed depends on the particular dialog parameter being modified.
The specifications of different dialog parameters describe when the
new value of the parameter needs to be taken into use.
3.4. 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 3.3). There are also certain not follow the guidelines in Section 3.3). There are also certain
race 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 dialog and the session (the UAC uses common view of the state of the session (the UAC uses the criteria in
the criteria in Section 3.3 in order to decide whether or not changes Section 3.3 in order to decide whether or not changes have been
have been executed for the stream). The purpose of this new offer/ executed for a particular stream). The purpose of this new offer/
answer exchange is to synchronize both UAs, not to request changes answer exchange is to synchronize both UAs, not to request changes
that the UAS may choose to reject. Therefore, the dialog parameters that the UAS may choose to reject. Therefore, session parameters in
and the session parameters in the offer/answer exchange SHOULD be as the offer/answer exchange SHOULD be as close to those in the pre-re-
close as those in the pre-re-INVITE state as possible. INVITE state as possible.
3.5. Glare Situations 3.5. Glare Situations
Section 4 of RFC 3264 [RFC3264] specifies rules to avoid and detect Section 4 of RFC 3264 [RFC3264] defines glare conditions as a user
glare situations (i.e., to avoid offer/answer collisions in race agent receiving an offer after having sent one but before having
conditions). Section 14.1 of RFC 3261 [RFC3261] specifies general received an answer to it. That section specifies rules to avoid
rules to handle glare situations in SIP. Section 5.1 of RFC 3311 glare situations in most cases. When despite following those rules a
[RFC3311] specifies when UPDATE requests can be sent. The specified glare conditions occurs (as a result of a race condition), it is
rules include, among other things, procedures to cope with situations handled as specified in Sections 14.1 and 14.2 of RFC 3261 [RFC3261].
where both UAs generate an offer at the same time. However, there The UAS returns a 491 (Request Pending) response and the UAC retries
are no rules to avoid a collision between an offer in an UPDATE the offer after a randomly-selected time, which depends on which user
request and an error response to a re-INVITE. Since both the UPDATE agent is the owner of the Call-ID of the dialog. The rules in RFC
request and the error response could be requesting changes, it would 3261 [RFC3261] not only cover collisions between re-INVITEs that
not be clear which changes would need to be executed first. The contain offers; they cover collisions between two re-INVITEs in
following rules avoid types of glare conditions that were not covered general, even if they do not contain offers. Sections 5.2 and 5.3 of
by previous specifications. RFC 3311 [RFC3311] extend those rules to also cover collisions
between an UPDATE request carrying an offer and another message
When checking for glare situations, UAs MUST treat the exchange of a (UPDATE, PRACK or INVITE) also carrying an offer.
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 The rules in RFC 3261 [RFC3261] do not cover collisions between an
can a non-2xx final response to a re-INVITE request or a 2xx response UPDATE request and a non-2xx final response to a re-INVITE. Since
to an INVITE request (re-INVITE or initial INVITE). However, there both the UPDATE request and the reliable response could be requesting
are no rules to avoid a collision between an offerless UPDATE request changes to the session state, it would not be clear which changes
and a final response to an INVITE request. The rules in Section 4.5, would need to be executed first. However, the procedures discussed
which are given in the context of target refreshes, cover these types in Section 3.4 already cover this type of situation. Therefore,
of collisions as well. Therefore, there is no need to specify there is no need to specify further rules here.
further rules here.
3.6. Example of UAS Behavior 3.6. Example of UAS Behavior
This section contains an example of a UAS that implements this 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).
skipping to change at page 17, line 5 skipping to change at page 17, line 5
3.8. 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 3.3, 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.
4. Target-refresh Handling 4. Refreshing a Dialog's Targets
The following sections discuss target-refresh request handling. The following sections discuss how to refresh the targets of a
dialog.
4.1. Background on Target-refresh Requests 4.1. Background and Terminology on a Dialog's Targets
As described in Section 12 of RFC 3261 [RFC3261], a UA involved in a
dialog stores the dialog's remote target as part of the dialog's
state information the UA keeps. Consequently, each of the two UAs
involved in a dialog store a dialog's remote target. In this
document, we define a new term: a dialog's local target. A dialog's
local target is the dialog's remote target the remote UA stores.
Thus, the dialog's local target for a UA is the dialog's remote
target for the other UA. Similarly, the dialog's remote target for a
UA is the dialog's local target for the other UA. The use of this
new term is intended to add clarity to the following discussions.
4.2. 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 12.2 update the remote target of the dialog. As discussed in Section 12.2
of RFC 3261 [RFC3261], re-INVITEs are target-refresh requests. of RFC 3261 [RFC3261], re-INVITEs are target-refresh requests.
skipping to change at page 17, line 39 skipping to change at page 18, line 4
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 4.2 specifies new rules for the handing of target- rules. Section 4.3 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.
4.2. Clarification on the Atomicity of Target-Refresh Requests 4.3. Clarification on the Atomicity of Target-Refresh Requests
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
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 to send SIP requests to the remote UA.
The remote target is a piece of state information that is not meant The local and remote targets of a dialog are special types of state
to be negotiated. When a UAC changes its address, the UAC simply information because of their essential role in the exchange of SIP
communicates its new address to the UAS in order to remain reachable messages between UAs in a dialog. A UA involved in a dialog receives
by the UAS. UAs need to follow the behavior specified in Section 4.3 the remote target of the dialog from the remote UA. The UA uses the
and Section 4.4 of this specification instead of that specified in received remote target to send SIP requests to the remote UA.
RFC 3261 [RFC3261], which was discussed in Section 4.1. The new
behavior regarding target-refresh requests implies that a target-
refresh request can, in some cases, update the remote target even if
the request is responded with a final error response. This means
that target-refresh requests are not atomic.
4.3. UAC Behavior The dialog's local target is a piece of state information that is not
meant to be negotiated. When a UA changes its local target (i.e.,
the UA changes its IP address), the UA simply communicates its new
local target to the remote UA (e.g., the UA communicates its new IP
address to the remote UA in order to remain reachable by the remote
UA). UAs need to follow the behavior specified in Section 4.4,
Section 4.5, Section 4.6, and Section 4.7 of this specification
instead of that specified in RFC 3261 [RFC3261], which was discussed
in Section 4.2. The new behavior regarding target-refresh requests
implies that a target-refresh request can, in some cases, update the
remote target even if the request is responded with a final error
response. This means that target-refresh requests are not atomic.
Behavior of a UAC after having sent a target-refresh request updating 4.4. UA Updating the Dialog's Local Target in a Request
the remote target:
If the UAC receives an error response to the target-refresh request, In order to update its local target, a UA can send a target-refresh
the UAS has not updated its remote target. request. If the UA receives an error response to the target-refresh
request, the remote UA 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 UA receives a reliable provisional response or a 2xx response
to the target-refresh request, or the UAC receives a request on the to the target-refresh request, or the UA receives an in-dialog
new target, the UAS has updated its remote target. The UAC can request on the new local target, the remote UA has updated its remote
consider the target refresh operation completed. target. The UA can consider the target refresh operation completed.
Even if the target request was a re-INVITE and the final response Even if the target request was a re-INVITE and the final response
to the re-INVITE was an error response, the UAS would not revert to the re-INVITE was an error response, the UAS would not revert
to the pre-re-INVITE remote target. to the pre-re-INVITE remote target.
If the UAC receives a reliable provisional response or a 2xx response A UA SHOULD NOT use the same target refresh request to refresh the
to the target-refresh request, the UAC MUST replace the dialog's target and to make session changes unless the session changes can be
remote target URI with the URI from the Contact header field in that trivially accepted by the remote UA (e.g., an IP address change).
response, if present. Piggybacking a target refresh with more complicated session changes
would make it unnecessarily complicated for the remote UA to accept
the target refresh while rejecting the session changes. Only in case
the target refresh request is a re-INVITE and the UAS supports
reliable provisional response or UPDATE requests, the UAC MAY
piggyback session changes and a target refresh in the same re-INVITE.
When interacting with a UAS that does not support reliable 4.5. UA Updating the Dialog's Local Target in a Response
provisional responses or UPDATE requests, a UAC SHOULD NOT use the
same target refresh request to refresh the target and to make session
changes unless the session changes can be trivially accepted by the
UAS (e.g., an IP address change). Piggybacking a target refresh with
more complicated session changes in this situation would make it
unnecessarily complicated for the UAS to accept the target refresh
while rejecting the session changes.
4.4. UAS Behavior A UA processing an incoming target refresh request can update its
local target by returning a reliable provisional response or a 2xx
response to the target-refresh request. The response needs to
contain the updated local target URI in its Contact header field. On
sending the response, the UA can consider the target refresh
operation completed.
Behavior of a UAS after having received a target-refresh request 4.6. A Request Updating the Dialog's Remote Target
Behavior of a UA 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 UA receives a target-refresh request that has been properly
authenticated, the UAS SHOULD generate a reliable provisional authenticated, the UA SHOULD generate a reliable provisional response
response or a 2xx response to the target-refresh request. If or a 2xx response to the target-refresh request. If generating such
generating such responses is not possible (e.g., the UAS does not responses is not possible (e.g., the UA does not support reliable
support reliable provisional responses and needs user input before provisional responses and needs user input before generating a final
generating a final response), the UAS SHOULD send a request to the response), the UA SHOULD send an in-dialog request to the remote UA
UAC using the new remote target (if the UAS does not need to send a using the new remote target (if the UA does not need to send a
request for other reasons, the UAS can send an UPDATE request). On request for other reasons, the UAS can send an UPDATE request). On
sending a reliable provisional response or a 2xx response to the sending a reliable provisional response or a 2xx response to the
target-refresh request, or a request to the new remote target, the target-refresh request, or a request to the new remote target, the UA
UAS MUST replace the dialog's remote target URI with the URI from the MUST replace the dialog's remote target URI with the URI from the
Contact header field in the target-refresh request. Contact header field in the target-refresh request.
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] or any those that use the mechanism defined in RFC 3262 [RFC3262]. Other
other SIP-based mechanism that may be specified in the future. 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. Note that
non-100 provisional responses are only applicable to INVITE
transactions [RFC4320].
If instead of sending a reliable provisional response or a 2xx If instead of sending a reliable provisional response or a 2xx
response to the target-refresh request, or a request to the new response to the target-refresh request, or a request to the new
target, the UAS generates an error response to the target-refresh target, the UA generates an error response to the target-refresh
request, the UAS MUST NOT update its dialog's remote target. request, the UA MUST NOT update its dialog's remote target.
4.5. Race Conditions and Target Refreshes 4.7. A Response Updating the Dialog's Remote Target
If a UA receives a reliable provisional response or a 2xx response to
a target-refresh request, the UA MUST replace the dialog's remote
target URI with the URI from the Contact header field in that
response, if present.
If a UA receives an unreliable provisional response to a target-
refresh request, the UA MUST NOT refresh the dialog's remote target.
4.8. Race Conditions and Target Refreshes
SIP provides request ordering by using the Cseq header field. That SIP provides request ordering by using the Cseq header field. That
is, a UAS that receives two requests at roughly the same time can is, a UA that receives two requests at roughly the same time can know
know which one is newer. However, SIP does not provide ordering which one is newer. However, SIP does not provide ordering between
between responses and requests. For example, if a UA receives a 200 responses and requests. For example, if a UA receives a 200 (OK)
(OK) response to an UPDATE request and an UPDATE request at roughly response to an UPDATE request and an UPDATE request at roughly the
the same time, the UA cannot know which one was sent last. Since same time, the UA cannot know which one was sent last. Since both
both messages can refresh the remote target, the UA needs to know messages can refresh the remote target, the UA needs to know which
which message was sent last in order to know which remote target message was sent last in order to know which remote target needs to
needs to be used. be used.
Some of the procedures discussed in Section 3.5 could avoid these This document specifies the following rule to avoid the situation
types of situations. However, they are currently defined only for just described. A UA that wishes to refresh its local target and can
SIP messages involved in offer/answer exchanges (e.g., the procedures perform such a refresh by sending a target-refresh request at that
do not apply to an UPDATE request that does not carry an offer). The point in time SHOULD use a target-refresh request to refresh its
following rules make those procedures applicable to the race local target. This rules implies that a UA only uses a response
conditions described above so that UASs can cope with them. (i.e., a reliable provisional response or a 2xx response to a target-
refresh request) to refresh its local target if the UA is unable to
use a target-refresh request at that point in time (e.g., the UAS of
an ongoing re-INVITE without support for UPDATE).
When checking for glare situations, UAs MUST treat every UPDATE 4.9. Early Dialogs
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 rules given in this section about which messages can refresh the
target of a dialog also apply to early dialogs created by an initial
INVITE transaction. Additionally, as specified in Section 13.2.2.4
of RFC 3261 [RFC3261], on receiving a 2xx response to the initial
INVITE, the UAC recomputes the whole route set of the dialog, which
transitions from the "early" state to the "confirmed" state.
The following sections discuss re-INVITE transaction routing. Section 12.1 of RFC 3261 allows unreliable provisional responses to
create early dialogs. However, per the rules given in this section,
unreliable provisional responses cannot refresh the target of a
dialog. Therefore, the UAC of an initial INVITE transaction will not
perform any target refresh as a result of the reception of an
unreliable provisional response with an updated Contact value on an
(already-established) early dialog. Note also that a given UAS can
establish additional early dialogs, which can have different targets,
by returning additional unreliable provisional responses with
different To tags.
5. A UA Losing its Contact
The following sections discuss the case where a UA loses its
transport address during an ongoing re-INVITE transaction. Such a UA
will refresh the dialog's local target so that it reflects its new
transport address. Note that target refreshes that do not involve
changes in the UA's transport address are outside of the scope of
this section. Also, UAs losing their transport address during a non-
re-INVITE transaction (e.g., a UA losing its transport address right
after having sent an UPDATE request before having received a response
to it) are out of scope as well.
The rules given in this section are also applicable to initial INVITE
requests that have established early dialogs.
5.1. Background on 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 sent
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.
5.2. 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 4.2) presents some issues because of the fact that Re- (see Section 4.3) presents some issues because of the fact that re-
INVITE transactions can be long lived. As described in Section 5.1, 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.
The following sections describe the errors UAs face when they lose
their transport address during a re-INVITE. On detecting some of
these errors, UAs following the rules specified in RFC 3261 [RFC3261]
will terminate the dialog. When the dialog is terminated, the only
option for the UAs is to establish a new dialog. However, in some
cases, exiting UAs will not terminate the dialog when detecting those
errors (despite of the rules in RFC 3261 [RFC3261]). The following
sections describe how to recover from those errors when the dialog
has not been terminated. In short, the UAs generate a new re-INVITE
transaction to synchronize both UAs.
5.3. 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,
according to Section 12.2.1.2 of RFC 3261 [RFC3261], it is supposed according to Section 12.2.1.2 of RFC 3261 [RFC3261], it is supposed
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. Additionally, UAC SHOULD generate a new re-
UAS (i.e., there are no proxy servers in the dialog's route set). INVITE in order to make sure that both UAs have a common view of the
state of the session.
It is possible that the errors ignored by the UAC were not related
to the target refresh operation. If that was the case, the second
re-INVITE would fail and the UAC would terminate the dialog
because, per the rules above, UACs only ignore errors when they
accept a target refresh within the re-INVITE.
5.4. 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 measures. Consequently, proxy servers relaying responses will
effectively ignore the error. effectively ignore the error.
If there are no proxy servers in the dialog's route set, the UAS will If there are no proxy servers in the dialog's route set, the UAS will
get an error when sending a non-2xx final response. The UAS core get an error when sending a non-2xx final response. The UAS core
will be notified of the transaction failure, as described in Section will be notified of the transaction failure, as described in Section
17.2.1 of RFC 3261 [RFC3261]. Most existing UASs do not terminate 17.2.1 of RFC 3261 [RFC3261]. Most existing UASs do not terminate
the dialog on encountering this failure, which is fortunate. the dialog on encountering this failure, which is fortunate.
A UAS that accepts a target refresh within a re-INVITE MUST ignore
transport and timeout errors when generating a non-2xx final response
to the re-INVITE if the UAS is communicating directly with the UAC
(i.e., there are no proxy servers in the dialog's route set).
Regardless of the presence or absence of proxy servers in the Regardless of the presence or absence of proxy servers in the
dialog's route set, a UAS generating a 2xx response to the re-INVITE dialog's route set, a UAS generating a 2xx response to the re-INVITE
will never receive an ACK request for it. According to Section 14.2 will never receive an ACK request for it. According to Section 14.2
of RFC 3261 [RFC3261], such a UAS is supposed to (at the "should" of RFC 3261 [RFC3261], such a UAS is supposed to (at the "should"
level) terminate the dialog by sending a BYE request. level) terminate the dialog by sending a BYE request.
A UAS that accepts a target refresh within a re-INVITE and never A UAS that accepts a target refresh within a re-INVITE and never
receives an ACK request after having sent a 2xx response to the re- receives an ACK request after having sent a final response to the re-
INVITE SHOULD NOT terminate the dialog. If the UA has received a new INVITE SHOULD NOT terminate the dialog if the UA has received a new
re-INVITE with a higher CSeq sequence number than the original one, re-INVITE with a higher CSeq sequence number than the original one.
the UA SHOULD just ignore the error. If the UA has not received such
a re-INVITE, UA SHOULD generate a new re-INVITE in order to make sure
that both UAs have a common view of the state of the session.
Note that the UA generates a re-INVITE and not an UPDATE request
because UPDATE requests can be sent within a re-INVITE. By
accepting the incoming re-INVITE, the remote UA indicates that the
old re-INVITE transaction has already been terminated.
A 500 (Server Internal Error) response to the new re-INVITE would
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
support this specification. In this situation, the UA SHOULD follow
the original recommendation in RFC 3261 [RFC3261] and terminate the
dialog.
5.5. 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
skipping to change at page 23, line 39 skipping to change at page 24, line 43
[RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) [RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP)
UPDATE Method", RFC 3311, October 2002. UPDATE Method", RFC 3311, October 2002.
[RFC4032] Camarillo, G. and P. Kyzivat, "Update to the Session [RFC4032] Camarillo, G. and P. Kyzivat, "Update to the Session
Initiation Protocol (SIP) Preconditions Framework", Initiation Protocol (SIP) Preconditions Framework",
RFC 4032, March 2005. RFC 4032, March 2005.
9.2. Informative References 9.2. Informative References
[RFC4320] Sparks, R., "Actions Addressing Identified Issues with the
Session Initiation Protocol's (SIP) Non-INVITE
Transaction", RFC 4320, January 2006.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT) (ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", RFC 5245, Traversal for Offer/Answer Protocols", RFC 5245,
April 2010. April 2010.
Authors' Addresses Authors' Addresses
Gonzalo Camarillo (editor) Gonzalo Camarillo (editor)
Ericsson Ericsson
Hirsalantie 11 Hirsalantie 11
 End of changes. 52 change blocks. 
205 lines changed or deleted 251 lines changed or added

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