draft-ietf-sipcore-reinvite-07.txt   draft-ietf-sipcore-reinvite-08.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: May 23, 2011 ZTE Expires: June 22, 2011 ZTE
November 19, 2010 December 19, 2010
Re-INVITE and Target-refresh Request Handling in the Session Initiation Re-INVITE and Target-refresh Request Handling in the Session Initiation
Protocol (SIP) Protocol (SIP)
draft-ietf-sipcore-reinvite-07 draft-ietf-sipcore-reinvite-08
Abstract Abstract
In this document, we clarify the handling of re-INVITEs in SIP. We The procedures for handling SIP re-INVITEs are described in RFC 3261.
clarify in which situations a UAS (User Agent Server) should generate Implementation and deployment experience has uncovered a number of
a success response and in which situations a UAS should generate an issues with the original documentation, and this document provides
error response to a re-INVITE. Additionally, we clarify issues additional procedures that update the original specification to
related to target-refresh requests. address those issues. In particular, this document defines in which
situations a UAS (User Agent Server) should generate a success
response and in which situations a UAS should generate an error
response to a re-INVITE. Additionally, this document defines further
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 This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 May 23, 2011. This Internet-Draft will expire on June 22, 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
skipping to change at page 2, line 22 skipping to change at page 2, line 26
3. Changing the Session State During a Re-INVITE . . . . . . . . 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. 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 4.3. Clarification on the Atomicity of Target-Refresh
Requests . . . . . . . . . . . . . . . . . . . . . . . . . 18 Requests . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.4. UA Updating the Dialog's Local Target in a Request . . . . 18 4.4. UA Updating the Dialog's Local Target in a Request . . . . 18
4.5. UA Updating the Dialog's Local Target in a Response . . . 19 4.5. UA Updating the Dialog's Local Target in a Response . . . 18
4.6. A Request Updating the Dialog's Remote Target . . . . . . 19 4.6. A Request Updating the Dialog's Remote Target . . . . . . 19
4.7. A Response Updating the Dialog's Remote Target . . . . . . 20 4.7. A Response Updating the Dialog's Remote Target . . . . . . 19
4.8. Race Conditions and Target Refreshes . . . . . . . . . . . 20 4.8. Race Conditions and Target Refreshes . . . . . . . . . . . 20
4.9. Early Dialogs . . . . . . . . . . . . . . . . . . . . . . 20 4.9. Early Dialogs . . . . . . . . . . . . . . . . . . . . . . 20
5. A UA Losing its Contact . . . . . . . . . . . . . . . . . . . 21 5. A UA Losing its Contact . . . . . . . . . . . . . . . . . . . 21
5.1. Background on re-INVITE Transaction Routing . . . . . . . 21 5.1. Background on re-INVITE Transaction Routing . . . . . . . 21
5.2. Problems with UAs Losing their Contact . . . . . . . . . . 21 5.2. Problems with UAs Losing their Contact . . . . . . . . . . 21
5.3. UAS Losing its Contact: UAC Behavior . . . . . . . . . . . 22 5.3. UAS Losing its Contact: UAC Behavior . . . . . . . . . . . 22
5.4. UAC Losing its Contact: UAS Behavior . . . . . . . . . . . 23 5.4. UAC Losing its Contact: UAS Behavior . . . . . . . . . . . 22
5.5. UAC Losing its Contact: UAC Behavior . . . . . . . . . . . 23 5.5. UAC Losing its Contact: UAC Behavior . . . . . . . . . . . 23
6. Security Considerations . . . . . . . . . . . . . . . . . . . 24 6. Security Considerations . . . . . . . . . . . . . . . . . . . 23
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
9.1. Normative References . . . . . . . . . . . . . . . . . . . 24 9.1. Normative References . . . . . . . . . . . . . . . . . . . 24
9.2. Informative References . . . . . . . . . . . . . . . . . . 25 9.2. Informative References . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 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
skipping to change at page 3, line 42 skipping to change at page 3, line 42
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
different situations. In this document, we clarify these issues. different situations. In this document, we clarify these issues.
Additionally, there has also been some confusion among implementors Additionally, there has also been some confusion among implementors
regarding target refresh requests, which include but are not limited regarding target refresh requests, which include but are not limited
to re-INVITEs. In this document, we also clarify the process by to re-INVITEs. In this document, we also clarify the process by
which remote targets are refreshed. which remote targets are refreshed.
Indented passages such as this one are used in this document to
provide additional information and clarifying text. They do not
contain normative protocol behavior.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
UA: User Agent. UA: User Agent.
UAC: User Agent Client. UAC: User Agent Client.
skipping to change at page 10, line 6 skipping to change at page 10, line 6
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 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.
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 so. During a session establishment, the UAS can wait before decides to use them. During a session establishment, the UAS can
using the media parameters until the callee starts being alerted or wait before using the media parameters until the callee starts being
until the callee accepts the session. During a session modification, alerted or until the callee accepts the session. During a session
the UAS can wait until its user accepts the changes to the session. modification, the UAS can wait until its user accepts the changes to
When dealing with streams where the UAS sends media more or less the session. When dealing with streams where the UAS sends media
continuously, the UAC notices that the new parameters are in use more or less continuously, the UAC notices that the new parameters
because the UAC receives media that uses the new parameters. are in use because the UAC receives media that uses the new
However, this mechanism does not work with other types of streams. parameters. However, this mechanism does not work with other types
Therefore, it is RECOMMENDED that when a UAS decides to start using of streams. Therefore, it is RECOMMENDED that when a UAS decides to
the new parameters for a stream for which all mandatory preconditions start using the new parameters for a stream for which all mandatory
have been met, the UAS either sends media using the new parameters or preconditions have been met, the UAS either sends media using the new
sends a new offer where the precondition-related attributes for the parameters or sends a new offer where the precondition-related
stream have been removed. As indicated above, the successful attributes for the stream have been removed. As indicated above, the
completion of an offer/answer exchange without preconditions successful completion of an offer/answer exchange without
indicates that the new parameters for the media stream are already preconditions indicates that the new parameters for the media stream
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
skipping to change at page 14, line 21 skipping to change at page 14, line 21
m=video 0 RTP/AVP 31 m=video 0 RTP/AVP 31
c=IN IP4 192.0.2.1 c=IN IP4 192.0.2.1
The UAS now returns a 200 (OK) response (10) to the re-INVITE. Note The UAS now returns a 200 (OK) response (10) to the re-INVITE. Note
that the media state after this 200 (OK) response is the same as the that the media state after this 200 (OK) response is the same as the
pre-re-INVITE media state. pre-re-INVITE media state.
3.7. Example of UAC Behavior 3.7. Example of UAC Behavior
Figure 5 shows an example of a race condition situation in which the Figure 5 shows an example of a race condition situation in which the
UAs end up with different views of the state of the session. The UAs UAs end up with different views of the state of the session.
in Figure 5 are involved in a session that, just before the message
flows in the figures starts, includes a sendrecv audio stream and an a:sendrecv a:sendrecv
inactive video stream. UA1 sends a re-INVITE (1) requesting to make v:inactive v:inactive
the video stream sendrecv.
UA1 Proxy UA2
| | |
|----(1) INVITE SDP1-->| |
| |----(2) INVITE SDP1-->|
| | |
| |<----(3) 183 SDP2-----| a:sendrecv
a:sendrecv |<----(4) 183 SDP2-----| | v:recvonly
v:sendonly | | |
| |<------(5) 4xx -------|
| |-------(6) ACK ------>| a:sendrecv
| +-(7) 4xx -| | v:inactive
| | |<---(8) UPDATE SDP3---|
|<---(9) UPDATE SDP3---| |
| | | |
a:sendonly |---(10) 200 OK SDP4-->| |
v:inactive | | |---(11) 200 OK SDP4-->| a:recvonly
|<-(7) 4xx -+ | | v:inactive
a:sendrecv |------(12) ACK ------>| |
v:inactive | | |
a: status of the audio stream
v: status of the video stream
Figure 5: Message flow with race condition
The UAs in Figure 5 are involved in a session that, just before the
message flows in the figures starts, includes a sendrecv audio stream
and an inactive video stream. UA1 sends a re-INVITE (1) requesting
to make the video stream sendrecv.
SDP1: SDP1:
m=audio 20000 RTP/AVP 0 m=audio 20000 RTP/AVP 0
a=sendrecv a=sendrecv
m=video 20002 RTP/AVP 31 m=video 20002 RTP/AVP 31
a=sendrecv a=sendrecv
UA2 is configured to automatically accept incoming video streams but UA2 is configured to automatically accept incoming video streams but
to ask for user input before generating an outgoing video stream. to ask for user input before generating an outgoing video stream.
Therefore, UAS2 makes the video stream recvonly by returning a 183 Therefore, UAS2 makes the video stream recvonly by returning a 183
skipping to change at page 16, line 5 skipping to change at page 16, line 22
a=sendonly a=sendonly
m=video 30002 RTP/AVP 31 m=video 30002 RTP/AVP 31
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).
a:sendrecv a:sendrecv
v:inactive v:inactive
UA1 Proxy UA2
| | |
|----(1) INVITE SDP1-->| |
| |----(2) INVITE SDP1-->|
| | |
| |<----(3) 183 SDP2-----| a:sendrecv
a:sendrecv |<----(4) 183 SDP2-----| | v:recvonly
v:sendonly | | |
| |<------(5) 4xx -------|
| |-------(6) ACK ------>| a:sendrecv
| +-(7) 4xx -| | v:inactive
| | |<---(8) UPDATE SDP3---|
|<---(9) UPDATE SDP3---| |
| | | |
a:sendonly |---(10) 200 OK SDP4-->| |
v:inactive | | |---(11) 200 OK SDP4-->| a:recvonly
|<-(7) 4xx -+ | | v:inactive
a:sendrecv |------(12) ACK ------>| |
v:inactive | | |
a: status of the audio stream
v: status of the video stream
Figure 5: Message flow with race condition
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 Cancelling Re-INVITEs
skipping to change at page 17, line 13 skipping to change at page 16, line 48
the UAS would return a 2xx response instead. the UAS 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 stores the dialog's remote target as part of the dialog's dialog keeps a record of the SIP or SIPS URI at which it can
state information the UA keeps. Consequently, each of the two UAs communicate with a specific instance of its peer (this is called the
involved in a dialog store a dialog's remote target. In this "dialog's remote target URI" and is equal to the URI contained in the
document, we define a new term: a dialog's local target. A dialog's Contact header of requests and responses it receives from the peer).
local target is the dialog's remote target the remote UA stores. This document introduces the complementary concept of the "dialog's
Thus, the dialog's local target for a UA is the dialog's remote local target URI", defined as a UA's record of the SIP or SIPS URI at
target for the other UA. Similarly, the dialog's remote target for a which the peer can communicate with it (equal to the URI contained in
UA is the dialog's local target for the other UA. The use of this the Contact header of requests and responses it sends to the peer).
new term is intended to add clarity to the following discussions. These terms are complementary because the "dialog's remote target
URI" according to 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
skipping to change at page 18, line 4 skipping to change at page 17, line 43
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.3 specifies new rules for the handing 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.
 End of changes. 18 change blocks. 
78 lines changed or deleted 89 lines changed or added

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