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

Versions: 00 01 02 03 04 05 06 07 RFC 5638

                                      H. Sinnreich/Adobe, editor
                                               A. Johnston/Avaya
                                               E. Shim/Panasonic
                                                  K. Singh/Adobe
     Internet Draft
     Expires: March 2007                         October 15, 2006



        Lightweight SIP Toolkit for Peer-to-Peer and Basic Client-
                              Server Systems
                    <draft-sinnreich-sip-tools-00.txt>


     Status of this Memo

     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 becomes aware will be disclosed, in
     accordance with Section 6 of 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 April 15, 2007.



     Abstract

     The number of SIP related standards can be significantly
     reduced for various application scenarios by (1) using SIP




      Sinnreich et al.          Expires March 2007          [Page 1]

     Internet-Draft     draft-sinnreich-sip-tools-00.txt  March 2007


     without "network based services" and (2) without emulating the
     telephone network.

     Such an approach reduces the number of SIP related standards
     (as by mid 2006) from roughly 100 to about 11. Core SIP
     interoperability and SIP compliance can be preserved without
     relying on complex server based networks.

     Successful IP communications must also include the relevant
     standards for NAT traversal, some of which are not directly
     related to SIP and also several standards for security. These
     standards are included here as well.



     Conventions used in this document

     Conventions used in this document

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

     Table of Contents


        1.    Introduction.........................................3
        2.    Methodology to Develop Lightweight SIP...............4
           2.1   Updating the use of SIP and SDP...................5
           2.2   Re-using other SIP standards......................6
        3.    Presence and Instant Messaging.......................6
           3.1 Presence............................................6
           3.2 Instant Messaging...................................6
        4.    NAT and Firewall Traversal...........................6
        5.    Security Considerations..............................7
           5.1   Security for SIP Signaling........................7
           5.2   Media Security....................................8
           5.3   Authenticated Identity for SIP....................8
        6.    IANA Considerations..................................8
           7.    Conclusions.......................................8
        8.    Acknowledgements.....................................8
        9.    References...........................................9
           9.1   Normative References..............................9
           9.2   Informative References............................9
        Author's Addresses........................................10
        Intellectual Property Statement...........................12


     Sinnreich et al.          Expires March 2007           [Page 2]

     Internet-Draft     draft-sinnreich-sip-tools-00.txt  March 2007


        Disclaimer of Validity....................................12
        Copyright Statement.......................................12
        Acknowledgment............................................13


       1. Introduction

     SIP standardization was started in the IETF in 1996 in the
     expectation to have a simple and flexible protocol for
     establishing multimedia communication. In the roughly ten years
     that have passed, the SIP family of related protocols has grown
     into approximately 100 RFCs with thousands of pages of
     specifications [12] and an ever increasing number of Internet
     Drafts, many of them about to join and thus increase even more
     the large number of existing RFCs on SIP.

     The common root of the complexity of SIP is (a) the overuse of
     the client server model and the resulting migration of endpoint
     applications, such as voice, presence, IM and video into (b)
     "network based services" trying to emulate the telephone system.

     P2P SIP systems may not need to support many of the network
     based services. And by the nature of P2P systems, their
     architectural difference from client server systems, P2P SIP
     systems may need approaches different from those taken in the
     context of client-server (CS) SIP to realize certain services.

     The emergence of P2P SIP raises the question as to what parts of
     SIP must be used to (1) preserve the core SIP properties, (2)
     preserve basic interoperability with server based SIP systems
     and (3) preserve the advantages of SIP for use in P2P
     communication systems.

     The objective of this memo is to clarify what parts of SIP are
     essential to meet these objectives. We will refer for brevity in
     the following to these essential tools for SIP as "LIGHTWEIGHT
     SIP".

     This memo is not trying to redefine SIP in any sense.

     Also, it is important to note that using the lightweight tools
     for SIP is not a profile of SIP. Furthermore it involves no
     modifications or subtractions to the MUSTs in RFC3261. And it is
     not a subset of the SIP protocol, either. However, it represents
     an attempt to reign in the seemingly endless set of SIP
     extensions which add "network functionality and services" to the
     SIP ecosystem.


     Sinnreich et al.          Expires March 2007           [Page 3]

     Internet-Draft     draft-sinnreich-sip-tools-00.txt  March 2007


     Lightweight SIP separates the SIP discovery and message
     routing functions from the other SIP extensions aimed at
     providing applications in the network. The notion of basic
     CS SIP is understood here as the functions that provide
     only endpoint discovery and SIP message routing for session
     initiation.

     Though Lightweight SIP is targeted primarily for P2P SIP,
     Lightweight SIP is also useful for basic CS SIP systems that
     use the peer-to-peer SIP call control model [13], not to be
     confused with P2P SIP.

     Even complex telephony functions can be accomplished with
     Lightweight SIP, but with the difference that all the complex
     features are endpoint resident. Such applications do not rely
     on any other service in the network except registration and
     proxy, as specified in RFC 3261. Examples of specialized
     telephony applications residing in endpoints are the
     interactive voice response (IVR), the auto-attendant, the
     receptionist workstation and the agent workstation in a
     customer contact center.

        Lightweight SIP is therefore limited to the original intent
        of SIP; establishing sessions between endpoints and leaving
        the applications in the endpoints. Establishing a session
        also includes the negotiation of the session parameters.

       2. Methodology to Develop Lightweight SIP

     The method to develop Lightweight SIP has several parts:

       a. Preserve the basic SIP definitions as per RFC 3261 [2].
       SIP can work with or without servers. The trapezoid model
       in RFC 3261 is only an example. Also, in the trapezoid
       model no attempt is made to provide any specific services
       in the network, since the proxies only act as application
       level message routers. We do not propose any changes to RFC
       3261, to eliminate any methods or headers, error messages,
       etc., since this would carry among other risks the danger
       of losing backward interoperability and lack of
       flexibility.

       b.
Analyze the main SIP related specifications as
       highlighted in [14] and eliminate all network based
       services residing in servers and various other network
       elements.



     Sinnreich et al.          Expires March 2007           [Page 4]

     Internet-Draft     draft-sinnreich-sip-tools-00.txt  March 2007


       c.
Adopt the NAT traversal techniques developed for SIP.

       d.
Adopt the security techniques developed for SIP and RTP,
       to the extent that they are not dependent on central
       control and on providing network based telephony style
       services.



       2.1  Updating the use of SIP and SDP

     We do not intend to re-write RFC 3261 for Lightweight SIP, but
     to take into account later work in SIP. Examples are:

          . Add items that have been developed in later work on
          SIP, such as the use of "rport" in the Via header and how
          to use the connection data "c=" in the SDP body behind a
          NAT. This information is now used differently as per RFC
          3489bis defining the STUN protocol.

          . Add the offer/answer model with SDP as per RFC 3264
          [3].


          . Add Locating SIP Servers [4].


          . Make TLS mandatory and leave S/MIME optional since it
          has not found as wide acceptance. Note that not making
          S/MIME mandatory does not preclude end-to-end privacy of
          messages in P2P SIP. End-to-end privacy is still possible
          in the single hop P2P SIP architecture.


          . Simplify early media by specifying that User Agents
          accept but do not generate early media. Early media
          functionality is best delegated to IP-PSTN VoIP gateway
          networks.


     Most of the User Agent behavior described in RFC 3261 can be
     re-used in Lightweight SIP, while the proxy behavior should be



     Sinnreich et al.          Expires March 2007           [Page 5]

     Internet-Draft     draft-sinnreich-sip-tools-00.txt  March 2007


     limited to the most basic interoperability between P2P SIP
     nodes and CS SIP systems.

     One key difference between RFC 3261 and P2P SIP systems is the
     replacement of the location database at the back side of SIP
     proxy and registrar servers with the P2P DHT layer as proposed
     in [15].

       2.2 Re-using other SIP standards

     A summary review of the other over roughly 100 SIP related
     standards reveals that they are mostly dedicated to telephony
     style of "services in the network" and therefore are out of
     scope for Lightweight SIP. The only exception is probably RFC
     3840 for indicating user agent capabilities [5], such as for
     various media types and SIP events.

       3. Presence and Instant Messaging

     3.1 Presence

     Subscriptions and notifications for presence based on SIP have
     been defined in [6] and the data format for presence information
     has been defined in [7].

     Rich presence information can be conveyed about the location,
     activity and other data about a user. Presence can also be used
     to integrate applications and communications. Such extended
     applications for presence are however beyond the scope of this
     memo.

     3.2 Instant Messaging

     Instant messaging for SIP is based on the simple extension
     "MESSAGE" defined in [8].

     Interesting activity information can be conveyed in various
     ways, such as the indication of "is typing" [9].

       4. NAT and Firewall Traversal

     While NAT traversal is not strictly speaking a SIP signaling
     property, we believe that any IP communication and application
     is useless without complete NAT traversal capabilities. The
     essential documents for a complete solution for NAT traversal
     for SIP based communications are referenced here.



     Sinnreich et al.          Expires March 2007           [Page 6]

     Internet-Draft     draft-sinnreich-sip-tools-00.txt  March 2007


     A. Requirements for NAT to "behave" [16] for UDP packets.

     B. NAT Traversal for SIP

          1. Updating the Via header information with "rport" for
          symmetric response routing [10].
          2. Connection reuse for "SIP Outbound" [17].


     C. NAT Traversal for RTP/RTCP Media

          1. Symmetric RTP [11]

          2. Simple Traversal Under NAT (STUN) [18]

          3. Media relay function for STUN servers [19]

          4. Interactive Connectivity Establishment (ICE) [20].

     An excellent summary of all the above in the form of deployment
     examples is given in the document on NAT scenarios [21].

          5. Security Considerations

     Security for SIP communications touches on both signaling and
     media. Existing security standards for CS SIP are described
     here. In P2P SIP systems, besides the security for signaling and
     media, the additional security for the P2P layer must also be
     provided. There are however no security standards as yet for P2P
     SIP.

          5.1 Security for SIP Signaling

     SIP secure authentication between the UA and the server is based
     on the digest authentication schema as specified in RFC 3261.
     SIP transport security for confidentiality is based on Transport
     Level Security (TLS) that is also specified in RFC 3261.

     End-to-end SIP security through intermediaries based on S/MIME
     has not found wide application at present, but it MAY be
     implemented in Lightweight SIP. Instead, P2P TLS connections
     SHOULD be used to achieve end-to-end security.






     Sinnreich et al.          Expires March 2007           [Page 7]

     Internet-Draft     draft-sinnreich-sip-tools-00.txt  March 2007


          5.2 Media Security

     End-to-end media security without any dependency on
     intermediaries, such as SIP proxies and certificate authorities
     will be provided using SRTP as per RFC 3711.

     Key management for SRTP is currently an active area of
     discussion and standardization in the IETF.

     The authors favor key management approaches that have no
     reliance on centralized certificate authorities and PKI
     infrastructures. For VoIP, the recommended protocol is ZRTP
     protocol [22]. ZRTP is based on users authenticating themselves
     to each other by voice or video, before activating media
     encryption for the rest of the conversation and for all
     following communications.

          5.3 Authenticated Identity for SIP

     In scenarios where the identity and authentication is required,
     the SIP identity header will be used as described in [23]. In
     P2P systems, the user enrollment server can be the source for
     the authentication service.

          6. IANA Considerations

     There are no IANA considerations associated with this memo.

          7. Conclusions

     We have shown in this document how the number of SIP related
     standards for presence, IM and multimedia communications can be
     reduced by (1) using SIP without network based services and (2)
     without emulating the telephone network. The approach for
     Lightweight SIP reduces the number of SIP related standards (as
     in 2006) from roughly 100 to about 11. Successful IP
     communications must however include a number of standards for
     NAT traversal, some of which are not directly related to SIP.
     The standards for NAT traversal are however referenced here,
     since SIP based communications must traverse NAT.

          8. Acknowledgements

     We would like to thank Wilhelm Wimmreuter for the detailed
     review of the initial draft.




     Sinnreich et al.          Expires March 2007           [Page 8]

     Internet-Draft     draft-sinnreich-sip-tools-00.txt  March 2007


          9. References

          9.1 Normative References

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

     [2] RFC 3261: "SIP: Session Initiation Protocol" by J. Rosenberg
     et al. IETF June 2002.

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

     [4] RFC 3263 "Locating SIP Servers" by J. Rosenberg and H.
     Schulzrinne. IETF, June 2002.

     [5] RFC 3840: "Indicating User Agent Capabilities in SIP" by J.
     Rosenberg, et al. IETF, August 2004.

     [6] RFC 3856: "A Presence Event Package for SIP" by J.
     Rosenberg. IETF, August 2004.

     [7] RFC 3863 "Presence Information Data Format (PIDF)" by H.
     Sugano et al. IETF, August 2004.

     [8] RFC 3428: "SIP Extension for Instant Messaging" by B.
     Campbell et al. IETF, December 2002.

     [9] RFC 3994:  "Indication of Message Composition for Instant
     Messaging" by H. Schulzrinne. IETF, January 2005.

     [10] RFC 3581: "An Extension to SIP for Symmetric Response
     Routing" by J. Rosenberg and H. Schulzrinne. IETF, August 2003.

     [11] RFC xxxx: "Symmetric RTP and RTCP Considered Helpful" by D.
     Wing. IETF, 2006.

     9.2   Informative References

     [12] "VoIP RFC Watch" by Nils Ohlmeier, http://rfc3261.net/.

     [13] "A Call Control and Multi-party usage framework for SIP" by
     R. Mahy et al. <draft-ietf-sipping-cc-framework-06.txt>. Work in
     progress, IETF, March 2006.





     Sinnreich et al.          Expires March 2007           [Page 9]

     Internet-Draft     draft-sinnreich-sip-tools-00.txt  March 2007


     [14] "A Hitchikers' Guide to SIP" by J. Rosenberg. <draft-
     rosenberg-sip-hitchhikers-guide>. Work in progress, IETF,
     February 2006.

     [15] "SIP, P2P and internet Communications" by A. Johnston and
     H. Sinnreich. Work in progress, Internet Draft, IETF, March
     2006.

     [16] "NAT Behavioral Requirements for Unicast UDP" by F. Audet
     and C. Jennings. Work in progress, <draft-ietf-behave-nat-udp>,
     IETF, May 2006.

     [17] "Managing Client Initiated Connections in SIP" by C.
     Jennings and R. Mahy. Work in progress, < draft-ietf-sip-
     outbound>, IETF, June 2006.

     [18] RFC 3489bis: "Simple Traversal Under NAT (STUN)" by J.
     Rosenberg et al. Work in progress, < draft-ietf-behave-
     rfc3489bis> , IETF, July 2006.

     [19] "Obtaining Relay Addresses from Simple Traversal of UDP
     Through NAT (STUN)" by J. Rosenberg, <draft-ietf-behave-turn>.
     Work in progress, IETF, February 2006.

     [20] "Interactive Connectivity Establishment (ICE): A
     Methodology for Network Address Translator (NAT) Traversal for
     Offer/Answer Protocols" by J.Rosenberg. Work in progress,
     <draft-ietf-mmusic-ice>, IETF, August 2006.

     [21] "Best Current Practices for NAT Traversal for SIP" by C.
     Boulton et al. Work in progress, < draft-ietf-sipping-nat-
     scenarios>, IETF, June 2006.

     [22] "ZRTP: Extensions to RTP for Diffie-Hellman Key Agreement
     for SRTP" by P. Zimmermann et al. Work in progress, IETF, March
     2006.

     [23] "Enhancements for Authenticated Identity Management in SIP"
     by J. Peterson and C. Jennings, <draft-ietf-sip-identity>. Work
     in progress, IETF, October 2005.

     Author's Addresses

        Alan Johnston

        Avaya



     Sinnreich et al.          Expires March 2007          [Page 10]

     Internet-Draft     draft-sinnreich-sip-tools-00.txt  March 2007


        211 Mt. Airy Rd.

        Basking Ridge, NJ 07920

        USA

        Email: alan.b.johnston@avaya.com



        Eunsoo Shim

        Panasonic Princeton Laboratory

        Two Research Way, 3rd Floor

        Princeton, NJ  08540, USA

        Email: eunsoo@research.panasonic.com



        Kundan Singh

        Adobe Systems, Inc.

        601 Townsend Street,

        San Francisco, CA 94103, USA

        Email: kundan@adobe.com



        Henry Sinnreich

        Adobe Systems, Inc.

        601 Townsend Street,

        San Francisco, CA 94103, USA

        Email: henrys@adobe.com






     Sinnreich et al.          Expires March 2007          [Page 11]

     Internet-Draft     draft-sinnreich-sip-tools-00.txt  March 2007


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

     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 (2006).  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.



     Sinnreich et al.          Expires March 2007          [Page 12]

     Internet-Draft     draft-sinnreich-sip-tools-00.txt  March 2007


     Acknowledgment

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













































     Sinnreich et al.          Expires March 2007          [Page 13]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/