draft-ietf-sipcore-reinvite-03.txt   draft-ietf-sipcore-reinvite-04.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: September 5, 2010 ZTE Expires: November 9, 2010 ZTE
March 4, 2010 May 8, 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-03.txt draft-ietf-sipcore-reinvite-04.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
This Internet-Draft is submitted to IETF 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), its areas, and its working groups. Note that Task Force (IETF). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. 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."
The list of current Internet-Drafts can be accessed at This Internet-Draft will expire on November 9, 2010.
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 5, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Re-INVITE Handling . . . . . . . . . . . . . . . . . . . . . . 4 3. Re-INVITE Handling . . . . . . . . . . . . . . . . . . . . . . 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
skipping to change at page 2, line 45 skipping to change at page 2, line 38
4.5. Race Conditions and Target Refreshes . . . . . . . . . . . 19 4.5. Race Conditions and Target Refreshes . . . . . . . . . . . 19
5. Re-INVITE Transaction Routing . . . . . . . . . . . . . . . . 20 5. Re-INVITE Transaction Routing . . . . . . . . . . . . . . . . 20
5.1. Background on re-INVITE Transaction Routing . . . . . . . 20 5.1. Background on re-INVITE Transaction Routing . . . . . . . 20
5.2. Problems with UAs Losing their Contact . . . . . . . . . . 20 5.2. Problems with UAs Losing their Contact . . . . . . . . . . 20
5.3. UAS Losing its Contact: UAC Behavior . . . . . . . . . . . 20 5.3. UAS Losing its Contact: UAC Behavior . . . . . . . . . . . 20
5.4. UAC Losing its Contact: UAS Behavior . . . . . . . . . . . 21 5.4. UAC Losing its Contact: UAS Behavior . . . . . . . . . . . 21
5.5. UAC Losing its Contact: UAC Behavior . . . . . . . . . . . 22 5.5. UAC Losing its Contact: UAC Behavior . . . . . . . . . . . 22
6. Security Considerations . . . . . . . . . . . . . . . . . . . 22 6. Security Considerations . . . . . . . . . . . . . . . . . . . 22
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23
9. Normative References . . . . . . . . . . . . . . . . . . . . . 23 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
9.1. Normative References . . . . . . . . . . . . . . . . . . . 23
9.2. Informative References . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction 1. Introduction
As discussed in Section 14 of RFC 3261 [RFC3261], an INVITE request As discussed in Section 14 of RFC 3261 [RFC3261], an INVITE request
sent within an existing dialog is known as a re-INVITE. A re-INVITE sent within an existing dialog is known as a re-INVITE. A re-INVITE
is used to modify session parameters, dialog parameters, or both. is used to modify session parameters, dialog parameters, or both.
That is, a single re-INVITE can change both the parameters of its That is, a single re-INVITE can change both the parameters of its
associated session (e.g., changing the IP address where a media associated session (e.g., changing the IP address where a media
stream is received) and the parameters of its associated dialog stream is received) and the parameters of its associated dialog
skipping to change at page 9, line 45 skipping to change at page 9, line 45
any other transaction within it. any other transaction within it.
If any of the changes requested in a re-INVITE or in any transaction If any of the changes requested in a re-INVITE or in any transaction
within it have already been executed (with the exception of target within it have already been executed (with the exception of target
refreshes), the UAS SHOULD return a 2xx response. refreshes), the UAS SHOULD return a 2xx response.
A change to the session state is considered to have been executed if A change to the session state is considered to have been executed if
an offer/answer without preconditions [RFC4032] for the stream has an offer/answer without preconditions [RFC4032] for the stream has
completed successfully or the UAs have exchanged media using the new completed successfully or the UAs have exchanged media using the new
parameters. Connection establishment messages (e.g., TCP SYN), parameters. Connection establishment messages (e.g., TCP SYN),
connectivity checks (e.g., when using ICE [I-D.ietf-mmusic-ice]), and connectivity checks (e.g., when using ICE [RFC5245]), and any other
any other messages used in the process of meeting the preconditions messages used in the process of meeting the preconditions for a
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
skipping to change at page 18, line 37 skipping to change at page 18, line 37
Even if the target request was a re-INVITE and the final response Even if the target request was a re-INVITE and the final response
to the re-INVITE was an error response, the UAS would not revert to the re-INVITE was an error response, the UAS would not revert
to the pre-re-INVITE remote target. to the pre-re-INVITE remote target.
If the UAC receives a reliable provisional response or a 2xx response If the UAC receives a reliable provisional response or a 2xx response
to the target-refresh request, the UAC MUST replace the dialog's to the target-refresh request, the UAC MUST replace the dialog's
remote target URI with the URI from the Contact header field in that remote target URI with the URI from the Contact header field in that
response, if present. response, if present.
When interacting with a UACs that does not support reliable When interacting with a UAS that does not support reliable
provisional responses or UPDATE requests, a UAC SHOULD NOT use the provisional responses or UPDATE requests, a UAC SHOULD NOT use the
same target refresh request to refresh the target and to make session same target refresh request to refresh the target and to make session
changes unless the session changes can be trivially accepted by the changes unless the session changes can be trivially accepted by the
UAS (e.g., an IP address change). Piggybacking a target refresh with UAS (e.g., an IP address change). Piggybacking a target refresh with
more complicated session changes in this situation would make it more complicated session changes in this situation would make it
unnecessarily complicated for the UAS to accept the target refresh unnecessarily complicated for the UAS to accept the target refresh
while rejecting the session changes. while rejecting the session changes.
4.4. UAS Behavior 4.4. UAS Behavior
skipping to change at page 23, line 10 skipping to change at page 23, line 10
7. IANA Considerations 7. IANA Considerations
There are no IANA actions associated with this document. There are no IANA actions associated with this document.
8. Acknowledgements 8. Acknowledgements
Paul Kyzivat provided useful ideas on the topics discussed in this Paul Kyzivat provided useful ideas on the topics discussed in this
document. document.
9. Normative References 9. References
9.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 23, line 35 skipping to change at page 23, line 37
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.
[I-D.ietf-mmusic-ice] 9.2. Informative References
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", Traversal for Offer/Answer Protocols", RFC 5245,
draft-ietf-mmusic-ice-19 (work in progress), October 2007. 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
 End of changes. 12 change blocks. 
25 lines changed or deleted 24 lines changed or added

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