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

Versions: 00 draft-camarillo-sipcore-reinvite

SIPPING                                                     G. Camarillo
Internet-Draft                                                  Ericsson
Intended status: Informational                             March 3, 2009
Expires: September 4, 2009


      Re-INVITE Handling in the Session Initiation Protocol (SIP)
                draft-camarillo-sipping-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 September 4, 2009.

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
   clarify in which situations a UAS (User Agent Server) should generate
   a success response and in which situations a UAS should generate an



Camarillo               Expires September 4, 2009               [Page 1]


Internet-Draft             Re-INVITE Handling                 March 2009


   error response to a re-INVITE.  Additionally, we clarify issues
   related to target refresh requests.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Background on Re-INVITE Handling by UASs . . . . . . . . . . .  3
   3.  Clarifications on the Target Refresh Procedure . . . . . . . . 11
   4.  UAS Behavior . . . . . . . . . . . . . . . . . . . . . . . . . 11
   5.  UAC Behavior . . . . . . . . . . . . . . . . . . . . . . . . . 12
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
   9.  Normative References . . . . . . . . . . . . . . . . . . . . . 13
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14



































Camarillo               Expires September 4, 2009               [Page 2]


Internet-Draft             Re-INVITE Handling                 March 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.

   OPEN ISSUE: this document is written as an informational document but
   could be turned into a normative document by adding a few normative
   statements if needed.


2.  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 clear 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               Expires September 4, 2009               [Page 3]


Internet-Draft             Re-INVITE Handling                 March 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 wanted to reject all the changes
   requested in the re-INVITE.  That is why generating an error response



Camarillo               Expires September 4, 2009               [Page 4]


Internet-Draft             Re-INVITE Handling                 March 2009


   was appropriate.  However, there are 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 target of the dialog to its new location, change the IP
   address where it receives the audio stream to its new IP address, and
   add a video stream to the session.






Camarillo               Expires September 4, 2009               [Page 5]


Internet-Draft             Re-INVITE Handling                 March 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 remote dialog
   target and 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               Expires September 4, 2009               [Page 6]


Internet-Draft             Re-INVITE Handling                 March 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               Expires September 4, 2009               [Page 7]


Internet-Draft             Re-INVITE Handling                 March 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.  Note that
   if the UAS returned an error response at this point, the media state
   would need to revert to the state before the re-INVITE.  That is,
   even if the change of the IP address of the audio stream had already
   been accepted and executed within the re-INVITE, the audio stream
   would need to go back to the old IP address.  Using an error response
   in this situation has a set of problems, which are discussed in
   Section 4.

   The example in Figure 4 also 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               Expires September 4, 2009               [Page 8]


Internet-Draft             Re-INVITE Handling                 March 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) 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
   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.






Camarillo               Expires September 4, 2009               [Page 9]


Internet-Draft             Re-INVITE Handling                 March 2009


         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
            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




Camarillo               Expires September 4, 2009              [Page 10]


Internet-Draft             Re-INVITE Handling                 March 2009


   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.  Section 4 discusses why the UAS uses an
   UPDATE request (8) and a 200 (OK) response (10) to the re-INVITE
   instead of an error response to the re-INVITE in order to go back to
   the pre-re-INVITE media state.


3.  Clarifications on the Target Refresh Procedure

   Both re-INVITEs and UPDATE [RFC3311] requests are target refresh
   requests for INVITE-initiated dialogs.  There is some confusion
   regarding how target refresh requests are handled within a re-INVITE.
   Section 5.1 of [RFC3311] specifies how to handle UPDATE requests
   within re-INVITEs but does not describe all possible situations in
   detail.  In this section, we clarify those situations that are more
   likely to be unclear from the specification.

   When a UAC sends a re-INVITE refreshing the target of the dialog, the
   UAS needs to start using the new target immediately.  For example, if
   the UAS needs to send an UPDATE request within the re-INVITE, the UAS
   will use the new target.  When the UAS sends a request to the new
   target, it is implicitly accepting the refresh of the target.
   Therefore, as discussed in Section 4, the UAS will respond to the re-
   INVITE with a 200 (OK) response, even if it needs to reject media
   changes in the response's SDP.

   A UAC can send a re-INVITE refreshing the target of the dialog and
   later send an UPDATE request within the re-INVITE refreshing the
   target again.  In this case, a 200 (OK) response to the re-INVITE
   would accept the latest target refresh within the re-INVITE.  That
   is, the target refresh performed by the UPDATE request.


4.  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 performed



Camarillo               Expires September 4, 2009              [Page 11]


Internet-Draft             Re-INVITE Handling                 March 2009


   since the re-INVITE was received.  Such an error response indicates
   that no changes have been made as a result of the re-INVITE or any
   other transaction within it.

   If changes requested by a re-INVITE or any transaction within it have
   already been performed, the UAS should always return a 200 (OK)
   response.  Even if the UAS would like to revert to the pre-INVITE
   state, it would still return a 200 (OK) to the INVITE request.  In
   order to undo changes that were already executed, the UAS uses a new
   offer/answer exchange or a target refresh request.  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.  On the other hand, if the UAS uses an offer or
   a target refresh request to request changes in the session, the UAC
   will able to reject the changes if it is unable to execute them.

   Using an error response to undo already executed changes presents an
   additional problem.  SIP includes rules 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 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.

   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.  See
   [draft-camarillo-sipping-precons-00.txt] for a more-detailed
   discussion on this issue.


5.  UAC Behavior

   The behavior of a UAC communicating with a well-behaved UAS (a UAS
   that follows the guidelines in Section 4 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



Camarillo               Expires September 4, 2009              [Page 12]


Internet-Draft             Re-INVITE Handling                 March 2009


   response to a re-INVITE but cannot revert to the media state before
   the re-INVITE for some reason should perform a new offer/answer
   exchange in order to set the parameters of the session and the dialog
   so that the session can continue.  This new offer/answer exchange
   should contain the minimum set of changes needed to continue the
   session in order to minimize the chances of the UAS rejecting it as
   well.

   If the error response reverted an already executed target refresh,
   the UAC should use a new target refresh request in order to set the
   target to an appropriate value.


6.  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].


7.  IANA Considerations

   There are no IANA actions associated with this document.


8.  Acknowledgements

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


9.  Normative References

   [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.

   [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.



Camarillo               Expires September 4, 2009              [Page 13]


Internet-Draft             Re-INVITE Handling                 March 2009


Author's Address

   Gonzalo Camarillo
   Ericsson
   Hirsalantie 11
   Jorvas  02420
   Finland

   Email: Gonzalo.Camarillo@ericsson.com










































Camarillo               Expires September 4, 2009              [Page 14]


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