draft-ietf-sipcore-reinvite-01.txt   draft-ietf-sipcore-reinvite-02.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: July 23, 2010 ZTE Expires: September 5, 2010 ZTE
January 19, 2010 March 4, 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-01.txt draft-ietf-sipcore-reinvite-02.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 43 skipping to change at page 1, line 43
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 The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 23, 2010. 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
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 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 then
provides an answer in a response to the re-INVITE. A UAC willing to provides an answer in a response to the re-INVITE. A UAC willing to
act as answerer does not include an offer in the re-INVITE. The UAS act as answerer does not include an offer in the re-INVITE. The UAS
then provides an offer in a response to the re-INVITE becoming, thus, then provides an offer in a response to the re-INVITE becoming, thus,
the offerer. 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 implentors regarding how a UAS There has been some confusion among implementors regarding how a UAS
(User Agent Server) should handle re-INVITEs. In particular, (User Agent Server) should handle re-INVITEs. In particular,
implementors requested clarification on which type of response a UAS implementors requested clarification on which type of response a UAS
should generate in different situations. In this document, we should generate in 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.
skipping to change at page 6, line 38 skipping to change at page 6, line 38
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
The UAS is automatically configured to reject video streams. The UAS is automatically configured to reject video streams.
However, the UAS needs to accept the change of the audio stream's However, the UAS needs to accept the change of the audio stream's
remote IP address. Consequently, the UAS returns a 200 (OK) response remote IP address. Consequently, the UAS returns a 200 (OK) response
and sets the port of the video stream to zero in its SDP. and sets the port of the video stream to zero in its SDP.
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 0 RTP/AVP 31 m=video 0 RTP/AVP 31
c=IN IP4 192.0.2.2
In the previous example, the UAS was configured to automatically In the previous example, the UAS was configured to automatically
reject the addition of video streams. The example in Figure 3 reject the addition of video streams. The example in Figure 3
assumes that the UAS requires its user's input in order to accept or assumes that the UAS requires its user's input in order to accept or
reject the addition of a video stream and uses reliable provisional reject the addition of a video stream and uses reliable provisional
responses [RFC3262] (PRACK transactions are not shown for clarity). responses [RFC3262] (PRACK transactions are not shown for clarity).
UAC UAS UAC UAS
| | | |
skipping to change at page 8, line 12 skipping to change at page 8, line 12
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
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 setting the stream. Consequently, the UAS sends an UPDATE request (6) setting
port of the video stream to zero in its SDP. the port of the video stream to zero in its offer.
SDP5: SDP5:
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
The UAS now returns a 200 (OK) response to the re-INVITE. The UAC returns a 200 (OK) response (7) to the UPDATE with the
following answer:
In all the previous examples, the UAC was the offerer in the re- SDP6:
INVITE transaction. Examples with UACs acting as the answerers would m=audio 30000 RTP/AVP 0
be similar. c=IN IP4 192.0.2.2
m=video 0 RTP/AVP 31
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
was the offerer. Examples with UACs acting as the answerers would be
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 (Figure 2 and Figure 3). A UAS can accept
and reject different sets of changes simultaneously (Figure 2) or at and reject different sets of changes simultaneously (Figure 2) or at
different times (Figure 3). different times (Figure 3).
skipping to change at page 9, line 31 skipping to change at page 9, line 40
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 [I-D.ietf-mmusic-ice]), and
any other messages used in the process of meeting the preconditions any other messages used in the process of meeting the preconditions
for a stream are not considered media. for a stream are not considered media.
Normally, a UA receiving media can easily detect when the new
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
process incoming media packets in order to detect whether they use
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 for decides so. During a session establishment, the UAS can wait before
using the media parameters until the callee starts being alerted or using the media parameters until the callee starts being alerted or
until the callee accepts the session. During a session modification, until the callee accepts the session. During a session modification,
the UAS can wait until its user accepts the changes to the session. the UAS can wait until its user accepts the changes to the session.
When dealing with streams where the UAS sends media more or less When dealing with streams where the UAS sends media more or less
continuously, the UAC notices that the new parameters are in use continuously, the UAC notices that the new parameters are in use
because the UAC receives media that uses the new parameters. because the UAC receives media that uses the new parameters.
However, this mechanism does not work with other types of streams. However, this mechanism does not work with other types of streams.
Therefore, it is RECOMMENDED that when a UAS decides to start using Therefore, it is RECOMMENDED that when a UAS decides to start using
the new parameters for a stream for which all mandatory preconditions the new parameters for a stream for which all mandatory preconditions
have been met, the UAS either sends media using the new parameters or have been met, the UAS either sends media using the new parameters or
skipping to change at page 15, line 22 skipping to change at page 15, line 22
continues being inactive. continues being inactive.
SDP3: SDP3:
m=audio 30000 RTP/AVP 0 m=audio 30000 RTP/AVP 0
a=recvonly a=recvonly
m=video 30002 RTP/AVP 31 m=video 30002 RTP/AVP 31
a=inactive a=inactive
The proxy relays the UPDATE request (9) to UA1. The UPDATE request The proxy relays the UPDATE request (9) to UA1. The UPDATE request
(9) arrives at UA1 before the 4xx response (7) that had been (9) arrives at UA1 before the 4xx response (7) that had been
previously sent. UA2 accepts the changes in the UPDATE request and previously sent. UA1 accepts the changes in the UPDATE request and
returns a 200 (OK) response (10) to it . returns a 200 (OK) response (10) to it.
SDP4: m=audio 20000 RTP/AVP 0 a=sendonly m=video 30002 RTP/AVP 31 SDP4:
a=inactive m=audio 20000 RTP/AVP 0
a=sendonly
m=video 30002 RTP/AVP 31
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 a:sendrecv a:sendrecv
v:inactive v:inactive v:inactive v:inactive
skipping to change at page 19, line 18 skipping to change at page 19, line 18
generating a final response), the UAS SHOULD send a request to the generating a final response), the UAS SHOULD send a request to the
UAC using the new remote target (if the UAS does not need to send a UAC using the new remote target (if the UAS does not need to send a
request for other reasons, the UAS can send an UPDATE request). On request for other reasons, the UAS can send an UPDATE request). On
sending a reliable provisional response or a 2xx response to the sending a reliable provisional response or a 2xx response to the
target-refresh request, or a request to the new remote target, the target-refresh request, or a request to the new remote target, the
UAS MUST replace the dialog's remote target URI with the URI from the UAS MUST replace the dialog's remote target URI with the URI from the
Contact header field in the target-refresh request. 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] on any those that use the mechanism defined in RFC 3262 [RFC3262] or any
other SIP-based mechanism that may be specified in the future. other SIP-based mechanism that may be specified in the future.
Other specifications may define ways to send provisional responses Other 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. non-SIP mechanisms are considered unreliable responses.
If instead sending a reliable provisional response or a 2xx response If instead of sending a reliable provisional response or a 2xx
to the target-refresh request, or a request to the new target, the response to the target-refresh request, or a request to the new
UAS generates an error response to the target-refresh request, the target, the UAS generates an error response to the target-refresh
UAS MUST NOT update its dialog's remote target. request, the UAS MUST NOT update its dialog's remote target.
4.5. Race Conditions and Target Refreshes 4.5. Race Conditions and Target Refreshes
SIP provides request ordering by using the Cseq header field. That SIP provides request ordering by using the Cseq header field. That
is, a UAS that receives two requests at roughly the same time can is, a UAS that receives two requests at roughly the same time can
know which one is newer. However, SIP does not provide ordering know which one is newer. However, SIP does not provide ordering
between responses and requests. For example, if a UA receives a 200 between responses and requests. For example, if a UA receives a 200
(OK) response to an UPDATE request and an UPDATE request at roughly (OK) response to an UPDATE request and an UPDATE request at roughly
the same time, the UA cannot know which one was sent last. Since the same time, the UA cannot know which one was sent last. Since
both messages can refresh the remote target, the UA needs to know both messages can refresh the remote target, the UA needs to know
 End of changes. 16 change blocks. 
24 lines changed or deleted 40 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/