SIPPING Working Group                                       G. Camarillo
Internet-Draft                                                  Ericsson
Expires: January 6, 2005                                    July 8, 2004


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

Status of this Memo

   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed,
   and any of which I 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 January 6, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2004). All Rights Reserved.

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 January 6, 2005                 [Page 1]

 
Internet-Draft    Connection-Establishment Preconditions       July 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.   Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
   9.   Security Considerations  . . . . . . . . . . . . . . . . . . . 4
   10.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 4
   11.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
   11.1   Normative References . . . . . . . . . . . . . . . . . . . . 5
   11.2   Informational References . . . . . . . . . . . . . . . . . . 5
        Author's Address . . . . . . . . . . . . . . . . . . . . . . . 5
        Intellectual Property and Copyright Statements . . . . . . . . 6


































Camarillo               Expires January 6, 2005                 [Page 2]

 
Internet-Draft    Connection-Establishment Preconditions       July 2004


.  Introduction

   RFC 3312 [3] defines a framework for preconditions for SIP  [2],
   which is updated by [4]. 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 [4] to extend the SIP preconditions
   framework.

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

.  Precondition Tag

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

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

.  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 would have an associated
   direction tag of sendrecv because it can carry data in both
   directions.






Camarillo               Expires January 6, 2005                 [Page 3]

 
Internet-Draft    Connection-Establishment Preconditions       July 2004


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

.  Suspending and Resuming Session Establishment

   According to [4], 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 any media stream. 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.

.  Examples

   TBD


   m=audio 20000 RTP/AVP 0
   a=curr:conn e2e none
   a=des:conn mandatory e2e sendrecv


.  Security Considerations

   TBD.

.  IANA Considerations

   TBD.

.  References






Camarillo               Expires January 6, 2005                 [Page 4]

 
Internet-Draft    Connection-Establishment Preconditions       July 2004


11.1  Normative References

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

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

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

   []  Camarillo, G., "Interactions of Preconditions with Session
        Mobility in the Session  Initiation Protocol (SIP)",
        draft-ietf-sip-rfc3312-update-00 (work in progress), November
        2003.

11.2  Informational References


Author's Address

   Gonzalo Camarillo
   Ericsson
   Hirsalantie 11
   Jorvas  02420
   Finland

   EMail: Gonzalo.Camarillo@ericsson.com





















Camarillo               Expires January 6, 2005                 [Page 5]

 
Internet-Draft    Connection-Establishment Preconditions       July 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 IETF's procedures with respect to rights in IETF 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 January 6, 2005                 [Page 6]