[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-camarillo-sipping-reinvite) 00 01 draft-ietf-sipcore-reinvite

SIPCORE                                                     G. Camarillo
Internet-Draft                                               C. Holmberg
Updates: 3261 (if approved)                                     Ericsson
Intended status: Standards Track                                  Y. Gao
Expires: January 7, 2010                                             ZTE
                                                            July 6, 2009


      Re-INVITE Handling in the Session Initiation Protocol (SIP)
                draft-camarillo-sipcore-reinvite-00.txt

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   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 January 7, 2010.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Abstract

   In this document, we clarify the handling of re-INVITEs in SIP.  We



Camarillo, et al.        Expires January 7, 2010                [Page 1]


Internet-Draft          Re-INVITE Handling in SIP              July 2009


   clarify 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, we clarify issues
   related to target refresh requests.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Background on Re-INVITE Handling by UASs . . . . . . . . . . .  3
   4.  Problems with Error Responses and Already-executed Changes . .  8
   5.  UAS Behavior . . . . . . . . . . . . . . . . . . . . . . . . .  9
   6.  UAC Behavior . . . . . . . . . . . . . . . . . . . . . . . . .  9
   7.  Clarifications on Cancelling Re-INVITEs  . . . . . . . . . . . 10
   8.  Background on Target Refresh Requests  . . . . . . . . . . . . 10
   9.  Clarifications on Target Refresh Requests  . . . . . . . . . . 10
   10. Example  . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
   11. Security Considerations  . . . . . . . . . . . . . . . . . . . 13
   12. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
   13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
   14. Normative References . . . . . . . . . . . . . . . . . . . . . 14
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14




























Camarillo, et al.        Expires January 7, 2010                [Page 2]


Internet-Draft          Re-INVITE Handling in SIP              July 2009


1.  Introduction

   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
   is used to modify session parameters, dialog parameters, or both.
   That is, a single re-INVITE can change both the parameters of its
   associated session (e.g., changing the IP address where a media
   stream is received) and the parameters of its associated dialog
   (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
   request, as defined in Section 6 of RFC 3261 [RFC3261].

   There has been some confusion among implentors regarding how a UAS
   (User Agent Server) should handle re-INVITEs.  In particular,
   implementors requested clarifications on which type of response a UAS
   should generate in different situations.  In this document, we
   clarify these issues.


2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

   UAC: User Agent Client.

   UAS: User Agent Server.


3.  Background on Re-INVITE Handling by UASs

   A UAS receiving a re-INVITE will need to, eventually, generate a
   response to it.  Some re-INVITEs can be responded to immediately
   because their handling does not require user interaction (e.g.,
   changing the IP address where a media stream is received).  The
   handling of other re-INVITEs requires user interaction (e.g., adding
   a video stream to an audio-only session).  Therefore, these re-
   INVITEs cannot be responded to immediately.

   An error response to a re-INVITE has the following semantics.  As
   specified in Section 12.2.2 of RFC 3261 [RFC3261], if a re-INVITE is
   rejected, none of the state changes requested by the re-INVITE are
   performed.  The example in Figure 1 illustrates this point.







Camarillo, et al.        Expires January 7, 2010                [Page 3]


Internet-Draft          Re-INVITE Handling in SIP              July 2009


                 UAC                                          UAS

                  |                                            |
                  |-------------(1) INVITE SDP1--------------->|
                  |                                            |
                  |<------------(2) 200 OK SDP2----------------|
                  |                                            |
                  |------------------(3) ACK------------------>|
                  |                                            |
                  |                                            |
                  |-------------(4) INVITE SDP3--------------->|
                  |                                            |
                  |<-----------------(5) 6xx-------------------|
                  |                                            |
                  |------------------(6) ACK------------------>|
                  |                                            |



                    Figure 1: Rejection of a re-INVITE

   The UAs perform an offer/answer exchange to establish an audio-only
   session:


         SDP1:
            m=audio 30000 RTP/AVP 0

         SDP2:
            m=audio 31000 RTP/AVP 0

   At a later point, the UAC sends a re-INVITE (4) in order to add a
   video stream to the session.


         SDP3:
            m=audio 30000 RTP/AVP 0
            m=video 30002 RTP/AVP 31

   The UAS is automatically configured to reject video streams.
   Consequently, the UAS returns an error response (5).  At that point,
   the session parameters in use are still those resulting from the
   initial offer/answer exchange, which are described by SDP1 and SDP2.
   That is, the session and dialog states are the same as before the re-
   INVITE was received.

   In the previous example, the UAS rejected all the changes requested
   in the re-INVITE by returning an error response.  However, there are



Camarillo, et al.        Expires January 7, 2010                [Page 4]


Internet-Draft          Re-INVITE Handling in SIP              July 2009


   situations where a UAS wants to accept some but not all the changes
   requested in a re-INVITE.  In these cases, the UAS generates a 200
   (OK) response with an SDP indicating which changes were accepted and
   which were not.  The example in Figure 2 illustrates this point.



                 UAC                                          UAS

                  |                                            |
                  |-------------(1) INVITE SDP1--------------->|
                  |                                            |
                  |<------------(2) 200 OK SDP2----------------|
                  |                                            |
                  |------------------(3) ACK------------------>|
                  |                                            |
                  |                                            |
                  |-------------(4) INVITE SDP3--------------->|
                  |                                            |
                  |<------------(5) 200 OK SDP4----------------|
                  |                                            |
                  |------------------(6) ACK------------------>|
                  |                                            |


              Figure 2: Automatic rejection of a video stream

   The UAs perform an offer/answer exchange to establish an audio only
   session:


         SDP1:
            m=audio 30000 RTP/AVP 0
            c=IN IP4 192.0.2.1

         SDP2:
            m=audio 31000 RTP/AVP 0
            c=IN IP4 192.0.2.5

   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
   change the IP address where it receives the audio stream to its new
   IP address, and add a video stream to the session.








Camarillo, et al.        Expires January 7, 2010                [Page 5]


Internet-Draft          Re-INVITE Handling in SIP              July 2009


         SDP3:
            m=audio 30000 RTP/AVP 0
            c=IN IP4 192.0.2.2
            m=video 30002 RTP/AVP 31
            c=IN IP4 192.0.2.2

   The UAS is automatically configured to reject video streams.
   However, the UAS needs to accept the change of the audio stream's
   remote IP address.  Consequently, the UAS returns a 200 (OK) response
   and sets the port of the video stream to zero in its SDP.


         SDP4:
            m=audio 31000 RTP/AVP 0
            c=IN IP4 192.0.2.5
            m=video 0 RTP/AVP 31
            c=IN IP4 192.0.2.2

   In the previous example, the UAS was configured to automatically
   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
   reject the addition of a video stream and uses reliable provisional
   responses [RFC3262] (PRACK transactions are not shown for clarity).




























Camarillo, et al.        Expires January 7, 2010                [Page 6]


Internet-Draft          Re-INVITE Handling in SIP              July 2009


                 UAC                                          UAS

                  |                                            |
                  |-------------(1) INVITE SDP1--------------->|
                  |                                            |
                  |<------------(2) 200 OK SDP2----------------|
                  |                                            |
                  |------------------(3) ACK------------------>|
                  |                                            |
                  |                                            |
                  |-------------(4) INVITE SDP3--------------->|
                  |                                            |
                  |<----(5) 183 Session Progress SDP4----------|
                  |                                            |
                  |                                            |
                  |<------------(6) UPDATE SDP5----------------|
                  |                                            |
                  |-------------(7) 200 OK SDP6--------------->|
                  |                                            |
                  |<---------------(8) 200 OK------------------|
                  |                                            |
                  |------------------(9) ACK------------------>|
                  |                                            |


             Figure 3: Rejection of a video stream by the user

   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
   but does not accept the video stream yet (it provides a null IP
   address instead of setting the stream to 'inactive' because inactive
   streams still need to exchange RTCP traffic).


         SDP4:
            m=audio 31000 RTP/AVP 0
            c=IN IP4 192.0.2.5
            m=video 31002 RTP/AVP 31
            c=IN IP4 0.0.0.0

   At a later point, the UAS's user rejects the addition of the video
   stream.  Consequently, the UAS sends an UPDATE request setting the
   port of the video stream to zero in its SDP.








Camarillo, et al.        Expires January 7, 2010                [Page 7]


Internet-Draft          Re-INVITE Handling in SIP              July 2009


         SDP5:
            m=audio 31000 RTP/AVP 0
            c=IN IP4 192.0.2.5
            m=video 0 RTP/AVP 31
            c=IN IP4 0.0.0.0

   The UAS now returns a 200 (OK) response to the re-INVITE.


4.  Problems with Error Responses and Already-executed Changes

   Section 3 contains examples on how a UAS rejects all the changes
   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
   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
   and reject different sets of changes simultaneously ((Figure 2) or at
   different times (Figure 3).

   The scenario that created confusion among implementors consist of a
   UAS that receives a re-INVITE, executes some of the changes requested
   in it, and then wants to reject all those already-executed changes
   and revert to the pre-re-INVITE state.  Such a UAS may consider
   returning an error response to the re-INVITE (the message flow would
   be similar to the one in Figure 1), or using an UPDATE request to
   revert to the pre-re-INVITE state and then returning a 2xx response
   to the re-INVITE (the message flow would be similar to the one in
   Figure 3).  This section explains the problems associated with
   returning an error response in these circumstances.  In order to
   avoid these problems, the UAS should use the latter option (UPDATE
   request plus a 2xx response).  Section 5 and Section 6 contain the
   normative statements needed to avoid these problems.

   The reason for not using an error response to undo already executed
   changes is that an error response to a re-INVITE for which changes
   have already been executed is effectively requesting a change in the
   session or the dialog state.  However, the UAC has no means to reject
   those changes if it is unable to execute them.  That is, if the UAC
   is unable to revert to the pre-re-INVITE state, it will not be able
   to communicate this fact to the UAS.

   Using an error response to undo already executed changes presents an
   additional problem.  Section 4 of [RFC3264] specifies rules to avoid
   glare situations (i.e., to avoid offer/answer collisions in race
   conditions).  Even when both UAs generate an offer at the same time,
   there are rules to determine which one should be processed first.
   However, there are no rules to avoid a collision between an offer in
   an UPDATE request and an error response for a re-INVITE.  Since both



Camarillo, et al.        Expires January 7, 2010                [Page 8]


Internet-Draft          Re-INVITE Handling in SIP              July 2009


   the UPDATE request and the error response would request changes, it
   would not be clear which changes would need to be executed first.
   This is yet another reason why UASs should not use error responses to
   undo already-executed changes.


5.  UAS Behavior

   UASs should only return an error response to a re-INVITE if no
   changes to the session or to the dialog state have been executed
   since the re-INVITE was received.  Such an error response indicates
   that no changes have been executed as a result of the re-INVITE or
   any other transaction within it.

   If any of the changes requested in a re-INVITE or in any transaction
   within it have already been executed, the UAS MUST always return a
   2xx response.

   A change to the session state is considered to have been executed
   when the new media parameters are being used.  Therefore, a change to
   a stream subject to preconditions [RFC4032] is considered to have
   been executed when the new media parameters start being used; not
   when the preconditions for the stream are met.  Unsurprisingly, the
   UAS considers the new parameters to be in use when it actually starts
   using them.  As described in Section 8.3.1 of RFC 3264 [RFC3264], the
   UAC considers the new parameters to be in use when media is received
   in the new port, which should be interpreted as follows:

      Received, in this case, means that the media is passed to a media
      sink.  This means that if there is a playout buffer, the agent
      would continue to listen on the old port until the media on the
      new port reached the top of the playout buffer.  At that time, it
      MAY cease listening for media on the old port.


6.  UAC Behavior

   The behavior of a UAC communicating with a UAS that supports this
   specification (i.e., a UAS that follows the guidelines in Section 5)
   is straight forward.  However, a UAC may face a legacy UAS that uses
   an error response to undo already-executed changes within a re-
   INVITE.

   In order to cope with this type of UAS, a UAC that receives an error
   response to a re-INVITE for which changes have been already executed
   SHOULD generate a new re-INVITE or UPDATE request in order to make
   sure that both UAs have a common view of the state of the session.
   The purpose of this new offer/answer exchange is to synchronize both



Camarillo, et al.        Expires January 7, 2010                [Page 9]


Internet-Draft          Re-INVITE Handling in SIP              July 2009


   UAs, not to request changes that the UAS may choose to reject.
   Therefore, the session parameters in the offer/answer exchange SHOULD
   be as close as those in the pre-re-INVITE state as possible.


7.  Clarifications on Cancelling Re-INVITEs

   Section 9.2 of RFC 3261 [RFC3261] specifies the behavior of a UAS
   responding to a CANCEL request as follows:

      If the original request was an INVITE, the UAS SHOULD immediately
      respond to the INVITE with a 487 (Request Terminated).

   Per the rules specified in Section 5, if the INVITE request was a re-
   INVITE and some of its requested changes had already been executed,
   the UAS would return a 2xx response instead.


8.  Background on Target Refresh Requests

   A target refresh request is defined as follows in Section 6 of RFC
   3261 [RFC3261]:

      A target refresh request sent within a dialog is defined as a
      request that can modify the remote target of the dialog.

   On receiving a target refresh request, a UAS updates the remote
   target of the dialog immediately, as specified in Section 12.2.2 of
   RFC 3261 [RFC3261]:

      When a UAS receives a target refresh request, it MUST replace the
      dialog's remote target URI with the URI from the Contact header
      field in that request, if present.

   On receiving a 2xx response for a target refresh request, a UAC
   updates the remote target of the dialog immediately, as specified in
   Section 12.2.1.2 of RFC 3261 [RFC3261]:

      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 the
      Contact header field in that response, if present.


9.  Clarifications on Target Refresh Requests

   On receiving a target refresh request with an updated remote target,
   a UAS updates the remote target of the dialog immediately.  This
   update represents the execution of a state change.  Therefore,



Camarillo, et al.        Expires January 7, 2010               [Page 10]


Internet-Draft          Re-INVITE Handling in SIP              July 2009


   following the rules in Section 5, UASs always return 2xx responses to
   target refresh requests that update the remote target.


10.  Example

   This section contains an example of a UAS that supports this
   specification using an UPDATE request and a 2xx response to a re-
   INVITE in order to revert to the pre-re-INVITE state.  The example,
   which is shown in Figure 4, 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 responses [RFC3262] (PRACK transactions are
   not shown for clarity).



                 UAC                                          UAS

                  |                                            |
                  |-------------(1) INVITE SDP1--------------->|
                  |                                            |
                  |<------------(2) 200 OK SDP2----------------|
                  |                                            |
                  |------------------(3) ACK------------------>|
                  |                                            |
                  |                                            |
                  |-------------(4) INVITE SDP3--------------->|
                  |                                            |
                  |<----(5) 183 Session Progress SDP4----------|
                  |                                            |
                  |-------------(6) UPDATE SDP5--------------->|
                  |                                            |
                  |<------------(7) 200 OK SDP6----------------|
                  |                                            |
                  |                                            |
                  |<------------(8) UPDATE SDP7----------------|
                  |                                            |
                  |-------------(9) 200 OK SDP8--------------->|
                  |                                            |
                  |<--------------(10) 200 OK------------------|
                  |                                            |
                  |-----------------(11) ACK------------------>|
                  |                                            |


             Figure 4: Rejection of a video stream by the user

   The UAs perform an offer/answer exchange to establish an audio only



Camarillo, et al.        Expires January 7, 2010               [Page 11]


Internet-Draft          Re-INVITE Handling in SIP              July 2009


   session:


         SDP1:
            m=audio 30000 RTP/AVP 0
            c=IN IP4 192.0.2.1

         SDP2:
            m=audio 31000 RTP/AVP 0
            c=IN IP4 192.0.2.5

   At a later point, the UAC sends a re-INVITE (4) in order to add a new
   codec to the audio stream and to add a video stream to the session.


         SDP3:
            m=audio 30000 RTP/AVP 0 3
            c=IN IP4 192.0.2.1
            m=video 30002 RTP/AVP 31
            c=IN IP4 192.0.2.1

   In (5), the UAS accepts the addition of the audio codec but does not
   accept the video stream yet (it provides a null IP address instead of
   setting the stream to 'inactive' because inactive streams still need
   to exchange RTCP traffic).


         SDP4:
            m=audio 31000 RTP/AVP 0 3
            c=IN IP4 192.0.2.5
            m=video 31002 RTP/AVP 31
            c=IN IP4 0.0.0.0

   At a later point, the UAC sends an UPDATE request (6) to remove the
   original audio codec from the audio stream (the UAC could have also
   used the PRACK to (5) to request this change).


         SDP5:
            m=audio 30000 RTP/AVP 3
            c=IN IP4 192.0.2.1
            m=video 30002 RTP/AVP 31
            c=IN IP4 192.0.2.1

         SDP6:
            m=audio 31000 RTP/AVP 3
            c=IN IP4 192.0.2.5
            m=video 31002 RTP/AVP 31



Camarillo, et al.        Expires January 7, 2010               [Page 12]


Internet-Draft          Re-INVITE Handling in SIP              July 2009


            c=IN IP4 0.0.0.0

   Yet at a later point, the UAS's user rejects the addition of the
   video stream.  Additionally, the UAS decides to revert to the
   original audio codec.  Consequently, the UAS sends an UPDATE request
   (8) setting the port of the video stream to zero and offering the
   original audio codec in its SDP.


         SDP7:
            m=audio 31000 RTP/AVP 0
            c=IN IP4 192.0.2.5
            m=video 0 RTP/AVP 31
            c=IN IP4 0.0.0.0

   The UAC accepts the change in the audio codec in its 200 (OK)
   response (9) to the UPDATE request.


         SDP5:
            m=audio 30000 RTP/AVP 0
            c=IN IP4 192.0.2.1
            m=video 0 RTP/AVP 31
            c=IN IP4 192.0.2.1

   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
   pre-re-INVITE media state.


11.  Security Considerations

   This document does not introduce any new security issue.  Security
   issues related to re-INVITEs and UPDATE requests are discussed in RFC
   3261 [RFC3261] and RFC 3311 [RFC3311].


12.  IANA Considerations

   There are no IANA actions associated with this document.


13.  Acknowledgements

   Paul Kyzivat, Christer Holmberg, and Yang Gao provided useful ideas
   on the topics discussed in this document.





Camarillo, et al.        Expires January 7, 2010               [Page 13]


Internet-Draft          Re-INVITE Handling in SIP              July 2009


14.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
              A., Peterson, J., Sparks, R., Handley, M., and E.
              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
              June 2002.

   [RFC3262]  Rosenberg, J. and H. Schulzrinne, "Reliability of
              Provisional Responses in Session Initiation Protocol
              (SIP)", RFC 3262, June 2002.

   [RFC3264]  Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
              with Session Description Protocol (SDP)", RFC 3264,
              June 2002.

   [RFC3311]  Rosenberg, J., "The Session Initiation Protocol (SIP)
              UPDATE Method", RFC 3311, October 2002.

   [RFC4032]  Camarillo, G. and P. Kyzivat, "Update to the Session
              Initiation Protocol (SIP) Preconditions Framework",
              RFC 4032, March 2005.


Authors' Addresses

   Gonzalo Camarillo
   Ericsson
   Hirsalantie 11
   Jorvas  02420
   Finland

   Email: Gonzalo.Camarillo@ericsson.com


   Christer Holmberg
   Ericsson
   Hirsalantie 11
   Jorvas  02420
   Finland

   Email: Christer.Holmberg@ericsson.com







Camarillo, et al.        Expires January 7, 2010               [Page 14]


Internet-Draft          Re-INVITE Handling in SIP              July 2009


   Yang Gao
   ZTE
   China

   Email: gao.yang2@zte.com.cn














































Camarillo, et al.        Expires January 7, 2010               [Page 15]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/