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

Versions: (draft-camarillo-mmusic-connection-precon) 00 01

MMUSIC Working Group                                        G. Camarillo
Internet-Draft                                                  Ericsson
Expires: June 2, 2005                                   December 2, 2004


    Connection-Establishment Preconditions in the Session Initiation
                             Protocol (SIP)
               draft-ietf-mmusic-connection-precon-01.txt

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of section 3 of RFC 3667.  By submitting this Internet-Draft, each
   author represents that any applicable patent or other IPR claims of
   which he or she is aware have been or will be disclosed, and any of
   which he or she become aware will be disclosed, in accordance with
   RFC 3668.

   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 June 2, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2004).

Abstract

   This document defines the connection-establishment precondition type
   for the SIP preconditions framework.  Connection-establishment
   preconditions are met when a transport connection (e.g., a TCP
   connection) is successfully established between two endpoints.






Camarillo                 Expires June 2, 2005                  [Page 1]


Internet-Draft    Connection-Establishment Preconditions   December 2004


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Precondition Tag . . . . . . . . . . . . . . . . . . . . . . .  3
   4.  Status Type  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   5.  Direction Tag  . . . . . . . . . . . . . . . . . . . . . . . .  3
   6.  Precondition Strength  . . . . . . . . . . . . . . . . . . . .  4
   7.  Suspending and Resuming Session Establishment  . . . . . . . .  4
   8.  Example  . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . .  6
   10.   IANA Considerations  . . . . . . . . . . . . . . . . . . . .  6
   11.   Normative References . . . . . . . . . . . . . . . . . . . .  6
       Author's Address . . . . . . . . . . . . . . . . . . . . . . .  7
       Intellectual Property and Copyright Statements . . . . . . . .  8




































Camarillo                 Expires June 2, 2005                  [Page 2]


Internet-Draft    Connection-Establishment Preconditions   December 2004


1.  Introduction

   RFC 3312 [3] defines a framework for preconditions for SIP  [2],
   which is updated by [5].  This document defines a new precondition
   type for that framework: connection-establishment preconditions.

   UAs (User Agents) use connection-establishment preconditions when
   they need to know whether a transport connection (e.g., a TCP
   connection) has been established successfully and is ready to carry
   user data.

   We define the connection-establishment precondition type following
   the guidelines provided in [5] to extend the SIP preconditions
   framework.

2.  Terminology

   In this document, the key words "MUST", "MUST NOT", "REQUIRED",
   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
   RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
   described in BCP 14, RFC 2119 [1] and indicate requirement levels for
   compliant implementations.

3.  Precondition Tag

   The precondition tag associated with the connection-establishment
   preconditions is "conn".  This precondition tag is registered with
   the IANA in Section 10.

4.  Status Type

   RFC 3312 [3] defines two status types, end-to-end and segmented, but
   only the end-to-end status type applies to connection-establishment
   preconditions.  So, connection-establishment preconditions MUST use
   the end-to-end status type and MUST NOT use the segmented status
   type.

5.  Direction Tag

   RFC 3312 [3] defines four direction tags: none, send, recv, and
   sendrecv.  Once a transport connection is established, they indicate
   in which directions the connection can carry user data.  For example,
   a successfully-established TCP connection (i.e., in ESTABLISHED
   statate) would have an associated direction tag of sendrecv because
   it can carry data in both directions.






Camarillo                 Expires June 2, 2005                  [Page 3]


Internet-Draft    Connection-Establishment Preconditions   December 2004


6.  Precondition Strength

   RFC 3312 [3] defines optional and mandatory preconditions, but only
   mandatory preconditions apply to connection-establishment
   preconditions.  So, connection-establishment preconditions MUST NOT
   use optional preconditions.

7.  Suspending and Resuming Session Establishment

   According to [5], documents defining new precondition types need to
   describe the behavior of UAs from the moment session establishment is
   suspended due to a set of preconditions until is resumed when these
   preconditions are met.

   While session establishment is suspended due to
   connection-establishment preconditions, user agents SHOULD not send
   any user data over the media streams affected by the preconditions.
   Additionally, the UAS (User Agent Server) SHOULD NOT alert the called
   user.

   Offers with connection-establishment preconditions in re-INVITEs or
   UPDATEs follow the rules given in Section 6 of RFC 3312 [3].

      Both user agents SHOULD continue using the old session parameters
      until all the mandatory preconditions are met.  At that moment,
      the user agents can begin using the new session parameters.

8.  Example

   The following example uses connection-establishment preconditions.
   Both UAs use a radio access network that does not allow them to send
   any data (not even a TCP SYN) until a radio bearer has been setup for
   the connection.  Figure 1 shows the message flow of this example (the
   PRACK transaction has been omitted for clarity):


              A                                    B
              |  INVITE                            |
              |  a=curr:conn e2e none              |
              |  a=des:conn mandatory e2e sendrecv |
              |  a=setup:holdconn                  |
              |----------------------------------->|
              |                                    |
              |  183 Session Progress              |
              |  a=curr:conn e2e none              |
              |  a=des:conn mandatory e2e sendrecv |
              |  a=setup:holdconn                  |
              |<-----------------------------------|



Camarillo                 Expires June 2, 2005                  [Page 4]


Internet-Draft    Connection-Establishment Preconditions   December 2004


              |                                    |
              |  UPDATE                            |
              |  a=curr:conn e2e none              |
              |  a=des:conn mandatory e2e sendrecv |
    A's radio |  a=setup:actpass                   |
    bearer is +----------------------------------->|
    up        |                                    |
              |  200 OK                            |
              |  a=curr:conn e2e none              |
              |  a=des:conn mandatory e2e sendrecv |
              |  a=setup:active                    |
              |<-----------------------------------|
              |                                    |
              |                                    |
              |                                    |
              |                                    | B's radio
              |<---TCP Connection Establishment--->+ bearer is up
              |                                    | B sends TCP SYN
              |                                    |
              |                                    |
              |  180 Ringing                       | TCP connection
              |<-----------------------------------+ is up
              |                                    | B alerts the user
              |                                    |

         Figure 1: Message flow with two types of preconditions

   A sends an INVITE requesting connection-establishment preconditions.
   The setup attribute in the offer is set to holdconn because A cannot
   send or receive any data before setting up a radio bearer for the
   connection.

   B agrees to use connection-establishment preconditions by sending a
   183 (Session Progress) response.  The setup attribute in the answer
   is also set to holdconn because B, like A, cannot send or receive any
   data before setting up a radio bearer for the connection.

   When A's radio bearer is ready, A sends an UPDATE to B with a setup
   attribute with a value of actpass.  This attribute indicates that A
   can perform an active or a passive TCP open.  A is letting B choose
   which endpoint will initiate the connection.

   Since B's radio bearer is not ready yet, B chooses to be the one
   initiating the connection and indicates so with a setup attribute
   with a value of active.  At a later point, when B's radio bearer is
   ready, B initiates the TCP connection towards A.

   Once the TCP connection is established successfully, B alerts the



Camarillo                 Expires June 2, 2005                  [Page 5]


Internet-Draft    Connection-Establishment Preconditions   December 2004


   callee and sends a 180 (Ringing) response.

9.  Security Considerations

   An attacker adding preconditions to a session description or
   modifying existing preconditions could keep sessions from being
   established.  An attacker removing preconditions from a session
   description could force sessions to be established without meeting
   mandatory preconditions.

   It is thus strongly RECOMMENDED that integrity protection be applied
   to the SDP session descriptions.  S/MIME [4] is the natural choice to
   provide such end-to-end integrity protection, as described in RFC
   3261 [2].

10.  IANA Considerations

   This document defines a new precondition type:
   connection-establishment.  It needs to be registered by the IANA
   under the registry for Precondition Types used with SIP.


   Pecondition-Type  Description                             Reference
   ----------------  -----------------------------------     ---------
   conn              Connection-establishment preconditions  [RFCXXXX]


11  Normative References

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

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

   [3]  Camarillo, G., Marshall, W. and J. Rosenberg, "Integration of
        Resource Management and Session Initiation Protocol (SIP)", RFC
        3312, October 2002.

   [4]  Peterson, J., "S/MIME Advanced Encryption Standard (AES)
        Requirement for the Session Initiation Protocol (SIP)", RFC
        3853, July 2004.

   [5]  Camarillo, G., "Update to the Session Initiation Protocol (SIP)
        Preconditions Framework", draft-ietf-sip-rfc3312-update-03 (work
        in progress), September 2004.




Camarillo                 Expires June 2, 2005                  [Page 6]


Internet-Draft    Connection-Establishment Preconditions   December 2004


Author's Address

   Gonzalo Camarillo
   Ericsson
   Hirsalantie 11
   Jorvas  02420
   Finland

   EMail: Gonzalo.Camarillo@ericsson.com










































Camarillo                 Expires June 2, 2005                  [Page 7]


Internet-Draft    Connection-Establishment Preconditions   December 2004


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Copyright Statement

   Copyright (C) The Internet Society (2004).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Camarillo                 Expires June 2, 2005                  [Page 8]


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