draft-ietf-sipcore-reinvite-05.txt   draft-ietf-sipcore-reinvite-06.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: January 27, 2011 ZTE Expires: April 8, 2011 ZTE
July 26, 2010 October 5, 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-05.txt draft-ietf-sipcore-reinvite-06.txt
Abstract Abstract
In this document, we clarify the handling of re-INVITEs in SIP. We In this document, we clarify the handling of re-INVITEs in SIP. We
clarify in which situations a UAS (User Agent Server) should generate clarify in which situations a UAS (User Agent Server) should generate
a success response and in which situations a UAS should generate an a success response and in which situations a UAS should generate an
error response to a re-INVITE. Additionally, we clarify issues error response to a re-INVITE. Additionally, we clarify issues
related to target-refresh requests. related to target-refresh requests.
Status of this Memo Status of this Memo
skipping to change at page 1, line 37 skipping to change at page 1, line 37
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 27, 2011. This Internet-Draft will expire on April 8, 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 37 skipping to change at page 2, line 37
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 . . . 19
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 . . . . . . 20
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 . . . . . . . . . . . 22 5.4. UAC Losing its Contact: UAS Behavior . . . . . . . . . . . 23
5.5. UAC Losing its Contact: UAC Behavior . . . . . . . . . . . 23 5.5. UAC Losing its Contact: UAC Behavior . . . . . . . . . . . 23
6. Security Considerations . . . . . . . . . . . . . . . . . . . 23 6. Security Considerations . . . . . . . . . . . . . . . . . . . 24
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 . . . . . . . . . . . . . . . . . . 24 9.2. Informative References . . . . . . . . . . . . . . . . . . 25
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 20, line 28 skipping to change at page 20, line 28
is, a UA that receives two requests at roughly the same time can know is, a UA that receives two requests at roughly the same time can know
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. A UA that wishes to refresh its local target and can just described. If the protocol allows a UA to use a target-refresh
perform such a refresh by sending a target-refresh request at that request at the point in time that UA wishes to refresh its local
point in time SHOULD use a target-refresh request to refresh its target, the UA MUST use a target-refresh request instead of a
local target. This rules implies that a UA only uses a response response to refresh its local target. This rule implies that a UA
(i.e., a reliable provisional response or a 2xx response to a target- only uses a response (i.e., a reliable provisional response or a 2xx
refresh request) to refresh its local target if the UA is unable to response to a target-refresh request) to refresh its local target if
use a target-refresh request at that point in time (e.g., the UAS of the UA is unable to use a target-refresh request at that point in
an ongoing re-INVITE without support for UPDATE). time (e.g., the UAS of an ongoing re-INVITE without support for
UPDATE).
4.9. Early Dialogs 4.9. Early Dialogs
The rules given in this section about which messages can refresh the The rules given in this section about which messages can refresh the
target of a dialog also apply to early dialogs created by an initial target of a dialog also apply to early dialogs created by an initial
INVITE transaction. Additionally, as specified in Section 13.2.2.4 INVITE transaction. Additionally, as specified in Section 13.2.2.4
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.
skipping to change at page 22, line 12 skipping to change at page 22, line 13
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. However, in some option for the UAs is to establish a new dialog. The following
cases, exiting UAs will not terminate the dialog when detecting those sections change the requirements RFC 3261 [RFC3261] places on UAs
errors (despite of the rules in RFC 3261 [RFC3261]). The following when certain errors occur so that the UAs can recover from those
sections describe how to recover from those errors when the dialog errors. In short, the UAs generate a new re-INVITE transaction to
has not been terminated. In short, the UAs generate a new re-INVITE synchronize both UAs. Note that there are existing UA
transaction to synchronize both UAs. 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
 End of changes. 8 change blocks. 
21 lines changed or deleted 22 lines changed or added

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