draft-ietf-sipcore-reinvite-08.txt   rfc6141.txt 
SIPCORE G. Camarillo, Ed. Internet Engineering Task Force (IETF) G. Camarillo, Ed.
Internet-Draft C. Holmberg Request for Comments: 6141 C. Holmberg
Updates: 3261 (if approved) Ericsson Updates: 3261 Ericsson
Intended status: Standards Track Y. Gao Category: Standards Track Y. Gao
Expires: June 22, 2011 ZTE ISSN: 2070-1721 ZTE
December 19, 2010 March 2011
Re-INVITE and Target-refresh Request Handling in the Session Initiation Re-INVITE and Target-Refresh Request Handling
Protocol (SIP) in the Session Initiation Protocol (SIP)
draft-ietf-sipcore-reinvite-08
Abstract Abstract
The procedures for handling SIP re-INVITEs are described in RFC 3261. The procedures for handling SIP re-INVITEs are described in RFC 3261.
Implementation and deployment experience has uncovered a number of Implementation and deployment experience has uncovered a number of
issues with the original documentation, and this document provides issues with the original documentation, and this document provides
additional procedures that update the original specification to additional procedures that update the original specification to
address those issues. In particular, this document defines in which address those issues. In particular, this document defines in which
situations a UAS (User Agent Server) should generate a success situations a UAS (User Agent Server) should generate a success
response and in which situations a UAS should generate an error response and in which situations a UAS should generate an error
response to a re-INVITE. Additionally, this document defines further response to a re-INVITE. Additionally, this document defines further
details of procedures related to target-refresh requests. details of procedures related to target-refresh requests.
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This is an Internet Standards Track document.
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on June 22, 2011. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6141.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2011 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 .....................................................4
3. Changing the Session State During a Re-INVITE . . . . . . . . 4 3. Changing the Session State during a Re-INVITE ...................5
3.1. Background on Re-INVITE Handling by UASs . . . . . . . . . 4 3.1. Background on Re-INVITE Handling by UASs ...................5
3.2. Problems with Error Responses and Already-executed 3.2. Problems with Error Responses and Already Executed Changes .9
Changes . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.3. UAS Behavior ..............................................10
3.3. UAS Behavior . . . . . . . . . . . . . . . . . . . . . . . 9 3.4. UAC Behavior ..............................................11
3.4. UAC Behavior . . . . . . . . . . . . . . . . . . . . . . . 10 3.5. Glare Situations ..........................................11
3.5. Glare Situations . . . . . . . . . . . . . . . . . . . . . 11 3.6. Example of UAS Behavior ...................................12
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 Canceling Re-INVITEs ....................17
3.8. Clarifications on Cancelling Re-INVITEs . . . . . . . . . 16 4. Refreshing a Dialog's Targets ..................................17
4. Refreshing a Dialog's Targets . . . . . . . . . . . . . . . . 16 4.1. Background and Terminology on a Dialog's Targets ..........17
4.1. Background and Terminology on a Dialog's Targets . . . . . 16 4.2. Background on Target-Refresh Requests .....................17
4.2. Background on Target-refresh Requests . . . . . . . . . . 17 4.3. Clarification on the Atomicity of Target-Refresh Requests .18
4.3. Clarification on the Atomicity of Target-Refresh 4.4. UA Updating the Dialog's Local Target in a Request ........19
Requests . . . . . . . . . . . . . . . . . . . . . . . . . 17 4.5. UA Updating the Dialog's Local Target in a Response .......19
4.4. UA Updating the Dialog's Local Target in a Request . . . . 18 4.6. A Request Updating the Dialog's Remote Target .............19
4.5. UA Updating the Dialog's Local Target in a Response . . . 18 4.7. A Response Updating the Dialog's Remote Target ............20
4.6. A Request Updating the Dialog's Remote Target . . . . . . 19 4.8. Race Conditions and Target Refreshes ......................20
4.7. A Response Updating the Dialog's Remote Target . . . . . . 19 4.9. Early Dialogs .............................................21
4.8. Race Conditions and Target Refreshes . . . . . . . . . . . 20 5. A UA Losing Its Contact ........................................21
4.9. Early Dialogs . . . . . . . . . . . . . . . . . . . . . . 20 5.1. Background on Re-INVITE Transaction Routing ...............22
5. A UA Losing its Contact . . . . . . . . . . . . . . . . . . . 21 5.2. Problems with UAs Losing Their Contact ....................22
5.1. Background on re-INVITE Transaction Routing . . . . . . . 21 5.3. UAS Losing Its Contact: UAC Behavior ......................22
5.2. Problems with UAs Losing their Contact . . . . . . . . . . 21 5.4. UAC Losing Its Contact: UAS Behavior ......................23
5.3. UAS Losing its Contact: UAC Behavior . . . . . . . . . . . 22 5.5. UAC Losing Its Contact: UAC Behavior ......................24
5.4. UAC Losing its Contact: UAS Behavior . . . . . . . . . . . 22 6. Security Considerations ........................................24
5.5. UAC Losing its Contact: UAC Behavior . . . . . . . . . . . 23 7. Acknowledgements ...............................................24
6. Security Considerations . . . . . . . . . . . . . . . . . . . 23 8. References .....................................................25
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 8.1. Normative References ......................................25
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24 8.2. Informative References ....................................25
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
change the remote target of a dialog because it is a target refresh change the remote target of a dialog because it is a target refresh
request, as defined in Section 6 of RFC 3261 [RFC3261]. request, as defined in Section 6 of RFC 3261 [RFC3261].
A re-INVITE transaction has an offer/answer [RFC3264] exchange A re-INVITE transaction has an offer/answer [RFC3264] exchange
associated to it. The UAC (User Agent Client) generating a given re- associated with it. The UAC (User Agent Client) generating a given
INVITE can act as the offerer or as the answerer. A UAC willing to re-INVITE can act as the offerer or as the answerer. A UAC willing
act as the offerer includes an offer in the re-INVITE. The UAS (User to act as the offerer includes an offer in the re-INVITE. The UAS
Agent Server) then provides an answer in a response to the re-INVITE. (User Agent Server) then provides an answer in a response to the
A UAC willing to act as answerer does not include an offer in the re- re-INVITE. A UAC willing to act as answerer does not include an
INVITE. The UAS then provides an offer in a response to the re- offer in the re-INVITE. The UAS then provides an offer in a response
INVITE becoming, thus, the offerer. to the re-INVITE becoming, thus, 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 implementors regarding how a UAS There has been some confusion among implementors regarding how a UAS
should handle re-INVITEs. In particular, implementors requested should handle re-INVITEs. In particular, implementors requested
clarification on which type of response a UAS should generate in clarification on which type of response a UAS should generate in
skipping to change at page 4, line 16 skipping to change at page 5, line 5
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. Changing the Session State During a Re-INVITE 3. Changing the Session State during a Re-INVITE
The following sections discuss how to change the state of the session The following sub-sections discuss how to change the state of the
during a re-INVITE transaction. 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 Eventually, a UAS receiving a re-INVITE will need to 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
INVITEs cannot be responded to immediately. re-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 (this section deals with other transactions within the re-INVITE (this section deals with
changes to the session state; target refreshes are discussed in changes to the session state; target refreshes are discussed in
Section 4.2). That is, the session state is the same as before the Section 4.2). That is, the session state is the same as before the
re-INVITE was received. The example in Figure 1 illustrates this re-INVITE was received. The example in Figure 1 illustrates this
point. point.
skipping to change at page 6, line 6 skipping to change at page 6, line 32
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 state is the same as before the re-INVITE was That is, the session state is the same as before the re-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 a Session Description Protocol (SDP) indicating
which were not. The example in Figure 2 illustrates this point. which changes were accepted and which were not. The example in
Figure 2 illustrates this point.
UAC UAS UAC UAS
| | | |
|-------------(1) INVITE SDP1--------------->| |-------------(1) INVITE SDP1--------------->|
| | | |
|<------------(2) 200 OK SDP2----------------| |<------------(2) 200 OK SDP2----------------|
| | | |
|------------------(3) ACK------------------>| |------------------(3) ACK------------------>|
| | | |
| | | |
|-------------(4) INVITE SDP3--------------->| |-------------(4) INVITE SDP3--------------->|
| | | |
|<------------(5) 200 OK SDP4----------------| |<------------(5) 200 OK SDP4----------------|
| | | |
|------------------(6) ACK------------------>| |------------------(6) ACK------------------>|
| | | |
Figure 2: Automatic rejection of a video stream Figure 2: Automatic rejection of a video stream
The UAs perform an offer/answer exchange to establish an audio only The UAs perform an offer/answer exchange to establish an audio-only
session: session:
SDP1: SDP1:
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
SDP2: SDP2:
m=audio 31000 RTP/AVP 0 m=audio 31000 RTP/AVP 0
c=IN IP4 192.0.2.5 c=IN IP4 192.0.2.5
At a later point, the UAC moves to an access that provides a higher- At a later point, the UAC moves to an access that provides a higher
bandwidth. Therefore, the UAC sends a re-INVITE (4) in order to bandwidth. Therefore, the UAC sends a re-INVITE (4) in order to
change the IP address where it receives the audio stream to its new change the IP address where it receives the audio stream to its new
IP address and add a video stream to the session. IP address and add a video stream to the session.
SDP3: SDP3:
m=audio 30000 RTP/AVP 0 m=audio 30000 RTP/AVP 0
c=IN IP4 192.0.2.2 c=IN IP4 192.0.2.2
m=video 30002 RTP/AVP 31 m=video 30002 RTP/AVP 31
c=IN IP4 192.0.2.2 c=IN IP4 192.0.2.2
skipping to change at page 8, line 11 skipping to change at page 8, line 46
| | | |
|------------------(9) ACK------------------>| |------------------(9) ACK------------------>|
| | | |
Figure 3: Manual rejection of a video stream by the user Figure 3: Manual rejection of a video stream by the user
Everything up to (4) is identical to the previous example. In (5), Everything up to (4) is identical to the previous example. In (5),
the UAS accepts the change of the audio stream's remote IP address the UAS accepts the change of the audio stream's remote IP address
but does not accept the video stream yet (it provides a null IP but does not accept the video stream yet (it provides a null IP
address instead of setting the stream to 'inactive' because inactive address instead of setting the stream to 'inactive' because inactive
streams still need to exchange RTCP traffic). streams still need to exchange RTP Control Protocol (RTCP) traffic).
SDP4: SDP4:
m=audio 31000 RTP/AVP 0 m=audio 31000 RTP/AVP 0
c=IN IP4 192.0.2.5 c=IN IP4 192.0.2.5
m=video 31002 RTP/AVP 31 m=video 31002 RTP/AVP 31
c=IN IP4 0.0.0.0 c=IN IP4 0.0.0.0
At a later point, the UAS's user rejects the addition of the video At a later point, the UAS's user rejects the addition of the video
stream. Consequently, the UAS sends an UPDATE request (6) setting stream. Consequently, the UAS sends an UPDATE request (6) setting
the port of the video stream to zero in its offer. the port of the video stream to zero in its offer.
skipping to change at page 8, line 43 skipping to change at page 9, line 29
m=audio 30000 RTP/AVP 0 m=audio 30000 RTP/AVP 0
c=IN IP4 192.0.2.2 c=IN IP4 192.0.2.2
m=video 0 RTP/AVP 31 m=video 0 RTP/AVP 31
The UAS now returns a 200 (OK) response (8) to the re-INVITE. The UAS now returns a 200 (OK) response (8) to the re-INVITE.
In all the previous examples, the UAC of the re-INVITE transaction In all the previous examples, the UAC of the re-INVITE transaction
was the offerer. Examples with UACs acting as the answerers would be was the offerer. Examples with UACs acting as the answerers would be
similar. similar.
3.2. Problems with Error Responses and Already-executed Changes 3.2. Problems with Error Responses and Already Executed Changes
Section 3.1 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 (Figures 2 and 3). A UAS can accept and
and reject different sets of changes simultaneously (Figure 2) or at 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 3.3 and Section 3.4 contain request plus a 2xx response). Sections 3.3 and 3.4 contain the
the normative statements needed to avoid these problems. 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 (e.g., as a result of UPDATE transactions have already been executed (e.g., as a result of UPDATE transactions
or reliable provisional responses) is effectively requesting a change or reliable provisional responses) is effectively requesting a change
in the session state. However, the UAC has no means to reject that in the session state. However, the UAC has no means to reject that
change if it is unable to execute them. That is, if the UAC is change 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 to unable to revert to the pre-re-INVITE state, it will not be able to
communicate this fact to the UAS. communicate this fact to the UAS.
skipping to change at page 9, line 46 skipping to change at page 10, line 30
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, the UAS SHOULD return a 2xx within it have already been executed, 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 UA has sent or received media using the completed successfully or the UA has sent or received media using the
new 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 Interactive Connectivity
messages used in the process of meeting the preconditions for a Establishment (ICE) [RFC5245]), and any other messages used in the
stream are not considered media. process of meeting the preconditions for a 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 new parameters.
The successful completion of an offer/answer exchange without The successful completion of an offer/answer exchange without
preconditions indicates that the new parameters for the media stream preconditions indicates that the new parameters for the media stream
are already considered to be in use. The successful completion of an are already considered to be in use. The successful completion of an
offer/answer exchange with preconditions means something different. offer/answer exchange with preconditions means something different.
The fact that all mandatory preconditions for the stream are met The fact that all mandatory preconditions for the stream are met
indicates that the new parameters for the media stream are ready to indicates that the new parameters for the media stream are ready to
be used. However, they will not actually be used until the UAS be used. However, they will not actually be used until the UAS
decides to use them. During a session establishment, the UAS can decides to use them. During a session establishment, the UAS can
wait before using the media parameters until the callee starts being wait before using the media parameters until the callee starts being
skipping to change at page 10, line 38 skipping to change at page 11, line 19
preconditions have been met, the UAS either sends media using the new preconditions have been met, the UAS either sends media using the new
parameters or sends a new offer where the precondition-related parameters or sends a new offer where the precondition-related
attributes for the stream have been removed. As indicated above, the attributes for the stream have been removed. As indicated above, the
successful completion of an offer/answer exchange without successful completion of an offer/answer exchange without
preconditions indicates that the new parameters for the media stream preconditions indicates that the new parameters for the media stream
are already considered to be in use. are already considered to be in 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
INVITE or UPDATE request in order to make sure that both UAs have a re-INVITE or UPDATE request in order to make sure that both UAs have
common view of the state of the session (the UAC uses the criteria in a common view of the state of the session (the UAC uses the criteria
Section 3.3 in order to decide whether or not changes have been in Section 3.3 in order to decide whether or not changes have been
executed for a particular 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, session parameters in that the UAS may choose to reject. Therefore, session parameters in
the offer/answer exchange SHOULD be as close to those in the pre-re- the offer/answer exchange SHOULD be as close to those in the
INVITE state as possible. pre-re-INVITE state as possible.
3.5. Glare Situations 3.5. Glare Situations
Section 4 of RFC 3264 [RFC3264] defines glare conditions as a user Section 4 of RFC 3264 [RFC3264] defines glare conditions as a user
agent receiving an offer after having sent one but before having agent receiving an offer after having sent one but before having
received an answer to it. That section specifies rules to avoid received an answer to it. That section specifies rules to avoid
glare situations in most cases. When despite following those rules a glare situations in most cases. When, despite following those rules,
glare conditions occurs (as a result of a race condition), it is a glare condition occurs (as a result of a race condition), it is
handled as specified in Sections 14.1 and 14.2 of RFC 3261 [RFC3261]. handled as specified in Sections 14.1 and 14.2 of RFC 3261 [RFC3261].
The UAS returns a 491 (Request Pending) response and the UAC retries The UAS returns a 491 (Request Pending) response and the UAC retries
the offer after a randomly-selected time, which depends on which user the offer after a randomly selected time, which depends on which user
agent is the owner of the Call-ID of the dialog. The rules in RFC agent is the owner of the Call-ID of the dialog. The rules in RFC
3261 [RFC3261] not only cover collisions between re-INVITEs that 3261 [RFC3261] not only cover collisions between re-INVITEs that
contain offers; they cover collisions between two re-INVITEs in contain offers, they cover collisions between two re-INVITEs in
general, even if they do not contain offers. Sections 5.2 and 5.3 of general, even if they do not contain offers. Sections 5.2 and 5.3 of
RFC 3311 [RFC3311] extend those rules to also cover collisions RFC 3311 [RFC3311] extend those rules to also cover collisions
between an UPDATE request carrying an offer and another message between an UPDATE request carrying an offer and another message
(UPDATE, PRACK or INVITE) also carrying an offer. (UPDATE, PRACK, or INVITE) also carrying an offer.
The rules in RFC 3261 [RFC3261] do not cover collisions between an The rules in RFC 3261 [RFC3261] do not cover collisions between an
UPDATE request and a non-2xx final response to a re-INVITE. Since UPDATE request and a non-2xx final response to a re-INVITE. Since
both the UPDATE request and the reliable response could be requesting both the UPDATE request and the reliable response could be requesting
changes to the session state, it would not be clear which changes changes to the session state, it would not be clear which changes
would need to be executed first. However, the procedures discussed would need to be executed first. However, the procedures discussed
in Section 3.4 already cover this type of situation. Therefore, in Section 3.4 already cover this type of situation. Therefore,
there is no need to specify further rules here. there is no need to specify 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
INVITE in order to revert to the pre-re-INVITE state. The example, re-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 shown in Figure 4 assumes that the UAS requires its user's input in
input in order to accept or reject the addition of a video stream and order to accept or reject the addition of a video stream and uses
uses reliable provisional responses [RFC3262] (PRACK transactions are reliable provisional responses [RFC3262] (PRACK transactions are not
not shown for clarity). shown for clarity).
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 12, line 35 skipping to change at page 13, line 5
| | | |
|-------------(9) 200 OK SDP8--------------->| |-------------(9) 200 OK SDP8--------------->|
| | | |
|<--------------(10) 200 OK------------------| |<--------------(10) 200 OK------------------|
| | | |
|-----------------(11) ACK------------------>| |-----------------(11) ACK------------------>|
| | | |
Figure 4: Rejection of a video stream by the user Figure 4: Rejection of a video stream by the user
The UAs perform an offer/answer exchange to establish an audio only The UAs perform an offer/answer exchange to establish an audio-only
session: session:
SDP1: SDP1:
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
SDP2: SDP2:
m=audio 31000 RTP/AVP 0 m=audio 31000 RTP/AVP 0
c=IN IP4 192.0.2.5 c=IN IP4 192.0.2.5
skipping to change at page 13, line 38 skipping to change at page 14, line 5
c=IN IP4 192.0.2.1 c=IN IP4 192.0.2.1
m=video 30002 RTP/AVP 31 m=video 30002 RTP/AVP 31
c=IN IP4 192.0.2.1 c=IN IP4 192.0.2.1
SDP6: SDP6:
m=audio 31000 RTP/AVP 3 m=audio 31000 RTP/AVP 3
c=IN IP4 192.0.2.5 c=IN IP4 192.0.2.5
m=video 31002 RTP/AVP 31 m=video 31002 RTP/AVP 31
c=IN IP4 0.0.0.0 c=IN IP4 0.0.0.0
Yet at a later point, the UAS's user rejects the addition of the Yet, at a later point, the UAS's user rejects the addition of the
video stream. Additionally, the UAS decides to revert to the video stream. Additionally, the UAS decides to revert to the
original audio codec. Consequently, the UAS sends an UPDATE request original audio codec. Consequently, the UAS sends an UPDATE request
(8) setting the port of the video stream to zero and offering the (8) setting the port of the video stream to zero and offering the
original audio codec in its SDP. original audio codec in its SDP.
SDP7: SDP7:
m=audio 31000 RTP/AVP 0 m=audio 31000 RTP/AVP 0
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
skipping to change at page 15, line 33 skipping to change at page 16, line 15
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=recvonly 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
response (7) takes time to arrive to UA1 (e.g., the response may have response (7) takes time to arrive to UA1 (e.g., the response may have
been sent over UDP and the first few retransmissions were lost). In been sent over UDP and the first few retransmissions were lost). In
the meantime, UA2's user decides to put the audio stream on hold. the meantime, UA2's user decides to put the audio stream on hold.
UA2 sends an UPDATE request (8) making the audio stream recvonly. UA2 sends an UPDATE request (8) making the audio stream recvonly.
The video stream, which is inactive, is not modified and, thus, The video stream, which is inactive, is not modified and, thus,
continues being inactive. continues being inactive.
skipping to change at page 16, line 24 skipping to change at page 17, line 7
a=inactive a=inactive
At a later point, the 4xx response (7) finally arrives at UA1. This At a later point, the 4xx response (7) finally arrives at UA1. This
response makes the session return to its pre-re-INVITE state. response makes the session return to its pre-re-INVITE state.
Therefore, for UA1, the audio stream is sendrecv and the video stream Therefore, for UA1, the audio stream is sendrecv and the video stream
is inactive. However, for UA2, the audio stream is recvonly (the is inactive. However, for UA2, the audio stream is recvonly (the
video stream is also inactive). video stream is also inactive).
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.
3.8. Clarifications on Cancelling Re-INVITEs 3.8. Clarifications on Canceling 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
the rules specified in Section 3.3, if the INVITE request was a re- rules specified in Section 3.3, if the INVITE request was a re-INVITE
INVITE and some of its requested changes had already been executed, and some of its requested changes had already been executed, the UAS
the UAS would return a 2xx response instead. would return a 2xx response instead.
4. Refreshing a Dialog's Targets 4. Refreshing a Dialog's Targets
The following sections discuss how to refresh the targets of a The following sections discuss how to refresh the targets of a
dialog. dialog.
4.1. Background and Terminology on a Dialog's Targets 4.1. Background and Terminology on a Dialog's Targets
As described in Section 12 of RFC 3261 [RFC3261], a UA involved in a As described in Section 12 of RFC 3261 [RFC3261], a UA involved in a
dialog keeps a record of the SIP or SIPS URI at which it can dialog keeps a record of the SIP or Session Initiation Protocol
communicate with a specific instance of its peer (this is called the Secure (SIPS) URI at which it can communicate with a specific
"dialog's remote target URI" and is equal to the URI contained in the instance of its peer (this is called the "dialog's remote target URI"
Contact header of requests and responses it receives from the peer). and is equal to the URI contained in the Contact header of requests
This document introduces the complementary concept of the "dialog's and responses it receives from the peer). This document introduces
local target URI", defined as a UA's record of the SIP or SIPS URI at the complementary concept of the "dialog's local target URI", defined
which the peer can communicate with it (equal to the URI contained in as a UA's record of the SIP or SIPS URI at which the peer can
the Contact header of requests and responses it sends to the peer). communicate with it (equal to the URI contained in the Contact header
These terms are complementary because the "dialog's remote target of requests and responses it sends to the peer). These terms are
URI" according to one UA is the "dialog's local target URI" according complementary because the "dialog's remote target URI" according to
to the other UA, and vice-versa. one UA is the "dialog's local target URI" according to the other UA,
and vice versa.
4.2. Background on Target-refresh Requests 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.
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
it MUST replace the dialog's remote target URI with the URI from MUST replace the dialog's remote target URI with the URI from the
the Contact header field in that response, if present." 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.3 specifies new rules for the handling of target- rules. Section 4.3 specifies new rules for the handling 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.3. Clarification on the Atomicity of Target-Refresh Requests 4.3. Clarification on the Atomicity of Target-Refresh Requests
The local and remote targets of a dialog are special types of state The local and remote targets of a dialog are special types of state
information because of their essential role in the exchange of SIP information because of their essential role in the exchange of SIP
messages between UAs in a dialog. A UA involved in a dialog receives 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 the remote target of the dialog from the remote UA. The UA uses the
received remote target to send SIP requests to the remote UA. received remote target to send SIP requests to the remote UA.
The dialog's local target is a piece of state information that is not 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., 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 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 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 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, UA). UAs need to follow the behavior specified in Sections 4.4, 4.5,
Section 4.5, Section 4.6, and Section 4.7 of this specification 4.6, and 4.7 of this specification instead of that specified in RFC
instead of that specified in RFC 3261 [RFC3261], which was discussed 3261 [RFC3261], which was discussed in Section 4.2. The new behavior
in Section 4.2. The new behavior regarding target-refresh requests regarding target-refresh requests implies that a target-refresh
implies that a target-refresh request can, in some cases, update the request can, in some cases, update the remote target even if the
remote target even if the request is responded with a final error request is responded to with a final error response. This means that
response. This means that target-refresh requests are not atomic. target-refresh requests are not atomic.
4.4. UA Updating the Dialog's Local Target in a Request 4.4. UA Updating the Dialog's Local Target in a Request
In order to update its local target, a UA can send a target-refresh In order to update its local target, a UA can send a target-refresh
request. If the UA receives an error response to the target-refresh request. If the UA receives an error response to the target-refresh
request, the remote UA has not updated its remote target. request, the remote UA has not updated its remote target.
This allows UASs to authenticate target-refresh requests (see This allows UASs to authenticate target-refresh requests (see
Section 26.2 of RFC 3261 [RFC3261]). Section 26.2 of RFC 3261 [RFC3261]).
skipping to change at page 20, line 20 skipping to change at page 21, line 7
which one is newer. However, SIP does not provide ordering between which one is newer. However, SIP does not provide ordering between
responses and requests. For example, if a UA receives a 200 (OK) responses and requests. For example, if a UA receives a 200 (OK)
response to an UPDATE request and an UPDATE request at roughly the response to an UPDATE request and an UPDATE request at roughly the
same time, the UA cannot know which one was sent last. Since both same time, the UA cannot know which one was sent last. Since both
messages can refresh the remote target, the UA needs to know which messages can refresh the remote target, the UA needs to know which
message was sent last in order to know which remote target needs to message was sent last in order to know which remote target needs to
be used. be used.
This document specifies the following rule to avoid the situation This document specifies the following rule to avoid the situation
just described. If the protocol allows a UA to use a target-refresh just described. If the protocol allows a UA to use a target-refresh
request at the point in time that UA wishes to refresh its local request at the point in time that the UA wishes to refresh its local
target, the UA MUST use a target-refresh request instead of a target, the UA MUST use a target-refresh request instead of a
response to refresh its local target. This rule implies that a UA response to refresh its local target. This rule implies that a UA
only uses a response (i.e., a reliable provisional response or a 2xx only uses a response (i.e., a reliable provisional response or a 2xx
response to a target-refresh request) to refresh its local target if 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 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 time (e.g., the UAS of an ongoing re-INVITE without support for
UPDATE). UPDATE).
4.9. Early Dialogs 4.9. Early Dialogs
skipping to change at page 20, line 44 skipping to change at page 21, line 31
of RFC 3261 [RFC3261], on receiving a 2xx response to the initial of RFC 3261 [RFC3261], on receiving a 2xx response to the initial
INVITE, the UAC recomputes the whole route set of the dialog, which INVITE, the UAC recomputes the whole route set of the dialog, which
transitions from the "early" state to the "confirmed" state. transitions from the "early" state to the "confirmed" state.
Section 12.1 of RFC 3261 allows unreliable provisional responses to Section 12.1 of RFC 3261 allows unreliable provisional responses to
create early dialogs. However, per the rules given in this section, create early dialogs. However, per the rules given in this section,
unreliable provisional responses cannot refresh the target of a unreliable provisional responses cannot refresh the target of a
dialog. Therefore, the UAC of an initial INVITE transaction will not dialog. Therefore, the UAC of an initial INVITE transaction will not
perform any target refresh as a result of the reception of an perform any target refresh as a result of the reception of an
unreliable provisional response with an updated Contact value on an unreliable provisional response with an updated Contact value on an
(already-established) early dialog. Note also that a given UAS can (already established) early dialog. Note also that a given UAS can
establish additional early dialogs, which can have different targets, establish additional early dialogs, which can have different targets,
by returning additional unreliable provisional responses with by returning additional unreliable provisional responses with
different To tags. different To tags.
5. A UA Losing its Contact 5. A UA Losing Its Contact
The following sections discuss the case where a UA loses its The following sections discuss the case where a UA loses its
transport address during an ongoing re-INVITE transaction. Such a UA transport address during an ongoing re-INVITE transaction. Such a UA
will refresh the dialog's local target so that it reflects its new will refresh the dialog's local target so that it reflects its new
transport address. Note that target refreshes that do not involve transport address. Note that target refreshes that do not involve
changes in the UA's transport address are outside of the scope of changes in the UA's transport address are outside of the scope of
this section. Also, UAs losing their transport address during a non- this section. Also, UAs losing their transport address during a
re-INVITE transaction (e.g., a UA losing its transport address right non-re-INVITE transaction (e.g., a UA losing its transport address
after having sent an UPDATE request before having received a response right after having sent an UPDATE request before having received a
to it) are out of scope as well. response to it) are out of scope as well.
The rules given in this section are also applicable to initial INVITE The rules given in this section are also applicable to initial INVITE
requests that have established early dialogs. 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 sent 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.3) presents some issues because of the fact that re- (see Section 4.3) presents some issues because of the fact that
INVITE transactions can be long lived. As described in Section 5.1, re-INVITE transactions can be long lived. As described in
the way responses to the re-INVITE and ACKs for non-2xx final Section 5.1, the way responses to the re-INVITE and ACKs for non-2xx
responses are routed is fixed once the re-INVITE is sent. The final 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 The following sections describe the errors UAs face when they lose
their transport address during a re-INVITE. On detecting some of their transport address during a re-INVITE. On detecting some of
these errors, UAs following the rules specified in RFC 3261 [RFC3261] these errors, UAs following the rules specified in RFC 3261 [RFC3261]
will terminate the dialog. When the dialog is terminated, the only will terminate the dialog. When the dialog is terminated, the only
option for the UAs is to establish a new dialog. The following option for the UAs is to establish a new dialog. The following
sections change the requirements RFC 3261 [RFC3261] places on UAs sections change the requirements RFC 3261 [RFC3261] places on UAs
when certain errors occur so that the UAs can recover from those when certain errors occur so that the UAs can recover from those
errors. In short, the UAs generate a new re-INVITE transaction to errors. In short, the UAs generate a new re-INVITE transaction to
synchronize both UAs. Note that there are existing UA synchronize both UAs. Note that there are existing UA
implementations deployed that already implement this behavior. implementations deployed that already implement this behavior.
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. Additionally, UAC SHOULD generate a new re- non-2xx final response. Additionally, UAC SHOULD generate a new
INVITE in order to make sure that both UAs have a common view of the re-INVITE in order to make sure that both UAs have a common view of
state of the session. the state of the session.
It is possible that the errors ignored by the UAC were not related 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 to the target refresh operation. If that was the case, the second
re-INVITE would fail and the UAC would terminate the dialog re-INVITE would fail and the UAC would terminate the dialog
because, per the rules above, UACs only ignore errors when they because, per the rules above, UACs only ignore errors when they
accept a target refresh within the re-INVITE. 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
measures. Consequently, proxy servers relaying responses will measures. Consequently, proxy servers relaying responses will
effectively ignore the error. effectively ignore the error.
skipping to change at page 23, line 19 skipping to change at page 24, line 6
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.
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 final response to the re- receives an ACK request after having sent a final response to the
INVITE SHOULD NOT terminate the dialog if the UA has received a new re-INVITE SHOULD NOT terminate the dialog if the UA has received a
re-INVITE with a higher CSeq sequence number than the original one. new re-INVITE with a higher CSeq sequence number than the original
one.
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
INVITE to enter the "Terminated" state. The UAC SHOULD also send a re-INVITE to enter the "Terminated" state. The UAC SHOULD also send
new re-INVITE in order to make sure that both UAs have a common view a new re-INVITE in order to make sure that both UAs have a common
of the state of the session. view 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.
6. 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].
In particular, in order not to reduce the security level for a given In particular, in order not to reduce the security level for a given
session, re-INVITEs and UPDATE requests SHOULD be secured using a session, re-INVITEs and UPDATE requests SHOULD be secured using a
mechanism equivalent to or stronger than the initial INVITE request mechanism equivalent to or stronger than the initial INVITE request
that created the session. For example, if the initial INVITE request that created the session. For example, if the initial INVITE request
was end-to-end integrity protected or encrypted, subsequent re- was end-to-end integrity protected or encrypted, subsequent
INVITEs and UPDATE requests should also be so. re-INVITEs and UPDATE requests should also be so.
7. IANA Considerations
There are no IANA actions associated with this document.
8. Acknowledgements 7. 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.
9. References 8. References
9.1. Normative References 8.1. 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
skipping to change at page 24, line 43 skipping to change at page 25, line 32
with Session Description Protocol (SDP)", RFC 3264, with Session Description Protocol (SDP)", RFC 3264,
June 2002. June 2002.
[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 8.2. Informative References
[RFC4320] Sparks, R., "Actions Addressing Identified Issues with the [RFC4320] Sparks, R., "Actions Addressing Identified Issues with the
Session Initiation Protocol's (SIP) Non-INVITE Session Initiation Protocol's (SIP) Non-INVITE
Transaction", RFC 4320, January 2006. 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
Jorvas 02420 Jorvas 02420
Finland Finland
Email: Gonzalo.Camarillo@ericsson.com EMail: Gonzalo.Camarillo@ericsson.com
Christer Holmberg Christer Holmberg
Ericsson Ericsson
Hirsalantie 11 Hirsalantie 11
Jorvas 02420 Jorvas 02420
Finland Finland
Email: Christer.Holmberg@ericsson.com EMail: Christer.Holmberg@ericsson.com
Yang Gao Yang Gao
ZTE ZTE
China China
Email: gao.yang2@zte.com.cn EMail: gao.yang2@zte.com.cn
 End of changes. 67 change blocks. 
180 lines changed or deleted 172 lines changed or added

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