draft-ietf-sipcore-reinvite-06.txt   draft-ietf-sipcore-reinvite-07.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: April 8, 2011 ZTE Expires: May 23, 2011 ZTE
October 5, 2010 November 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-06.txt draft-ietf-sipcore-reinvite-07
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 April 8, 2011. This Internet-Draft will expire on May 23, 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 3, line 20 skipping to change at page 3, line 20
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 to it. The UAC (User Agent Client) generating a given re-
INVITE can act as the offerer or as the answerer. A UAC willing to INVITE can act as the offerer or as the answerer. A UAC willing to
act as the offerer includes an offer in the re-INVITE. The UAS then act as the offerer includes an offer in the re-INVITE. The UAS (User
provides an answer in a response to the re-INVITE. A UAC willing to Agent Server) then provides an answer in a response to the re-INVITE.
act as answerer does not include an offer in the re-INVITE. The UAS A UAC willing to act as answerer does not include an offer in the re-
then provides an offer in a response to the re-INVITE becoming, thus, INVITE. The UAS then provides an offer in a response to the re-
the offerer. 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
(User Agent Server) should handle re-INVITEs. In particular, should handle re-INVITEs. In particular, implementors requested
implementors requested clarification on which type of response a UAS clarification on which type of response a UAS should generate in
should generate in different situations. In this document, we different situations. In this document, we clarify these issues.
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.
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
skipping to change at page 8, line 5 skipping to change at page 8, line 5
| | | |
|<------------(6) UPDATE SDP5----------------| |<------------(6) UPDATE SDP5----------------|
| | | |
|-------------(7) 200 OK SDP6--------------->| |-------------(7) 200 OK SDP6--------------->|
| | | |
|<---------------(8) 200 OK------------------| |<---------------(8) 200 OK------------------|
| | | |
|------------------(9) ACK------------------>| |------------------(9) ACK------------------>|
| | | |
Figure 3: 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 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
skipping to change at page 18, line 35 skipping to change at page 18, line 35
implies that a target-refresh request can, in some cases, update the implies that a target-refresh request can, in some cases, update the
remote target even if the request is responded with a final error remote target even if the request is responded with a final error
response. This means that target-refresh requests are not atomic. response. This means that 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. This allows UASs to authenticate target-refresh requests (see
Section 26.2 of RFC 3261 [RFC3261]).
If the UA receives a reliable provisional response or a 2xx response If the UA receives a reliable provisional response or a 2xx response
to the target-refresh request, or the UA receives an in-dialog to the target-refresh request, or the UA receives an in-dialog
request on the new local target, the remote UA has updated its remote request on the new local target, the remote UA has updated its remote
target. The UA can consider the target refresh operation completed. target. The UA can consider the target refresh operation completed.
Even if the target request was a re-INVITE and the final response Even if the target request was a re-INVITE and the final response
to the re-INVITE was an error response, the UAS would not revert to the re-INVITE was an error response, the UAS would not revert
to the pre-re-INVITE remote target. to the pre-re-INVITE remote target.
skipping to change at page 19, line 23 skipping to change at page 19, line 24
contain the updated local target URI in its Contact header field. On contain the updated local target URI in its Contact header field. On
sending the response, the UA can consider the target refresh sending the response, the UA can consider the target refresh
operation completed. operation completed.
4.6. A Request Updating the Dialog's Remote Target 4.6. A Request Updating the Dialog's Remote Target
Behavior of a UA after having received a target-refresh request Behavior of a UA after having received a target-refresh request
updating the remote target: updating the remote target:
If the UA receives a target-refresh request that has been properly If the UA receives a target-refresh request that has been properly
authenticated, the UA SHOULD generate a reliable provisional response authenticated (see Section 26.2 of RFC 3261 [RFC3261]), the UA SHOULD
or a 2xx response to the target-refresh request. If generating such generate a reliable provisional response or a 2xx response to the
responses is not possible (e.g., the UA does not support reliable target-refresh request. If generating such responses is not possible
provisional responses and needs user input before generating a final (e.g., the UA does not support reliable provisional responses and
response), the UA SHOULD send an in-dialog request to the remote UA needs user input before generating a final response), the UA SHOULD
using the new remote target (if the UA does not need to send a send an in-dialog request to the remote UA using the new remote
request for other reasons, the UAS can send an UPDATE request). On target (if the UA does not need to send a request for other reasons,
sending a reliable provisional response or a 2xx response to the the UAS can send an UPDATE request). On sending a reliable
target-refresh request, or a request to the new remote target, the UA provisional response or a 2xx response to the target-refresh request,
MUST replace the dialog's remote target URI with the URI from the or a request to the new remote target, the UA MUST replace the
Contact header field in the target-refresh request. dialog's remote target URI with the URI from the Contact header field
in the target-refresh request.
Reliable provisional responses in SIP are specified in RFC 3262 Reliable provisional responses in SIP are specified in RFC 3262
[RFC3262]. In this document, reliable provisional responses are [RFC3262]. In this document, reliable provisional responses are
those that use the mechanism defined in RFC 3262 [RFC3262]. Other those that use the mechanism defined in RFC 3262 [RFC3262]. Other
specifications may define ways to send provisional responses specifications may define ways to send provisional responses
reliably using non-SIP mechanisms (e.g., using media-level reliably using non-SIP mechanisms (e.g., using media-level
messages to acknowledge the reception of the SIP response). For messages to acknowledge the reception of the SIP response). For
the purposes of this document, provisional responses using those the purposes of this document, provisional responses using those
non-SIP mechanisms are considered unreliable responses. Note that non-SIP mechanisms are considered unreliable responses. Note that
non-100 provisional responses are only applicable to INVITE non-100 provisional responses are only applicable to INVITE
skipping to change at page 24, line 12 skipping to change at page 24, line 12
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
session, re-INVITEs and UPDATE requests SHOULD be secured using a
mechanism equivalent to or stronger than 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-
INVITEs and UPDATE requests should also be so.
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. References 9. References
 End of changes. 9 change blocks. 
26 lines changed or deleted 34 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/