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

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

SIPPING Working Group                        H. Sinnreich/Adobe, editor
Internet Draft                                        A. Johnston/Avaya
                                                           E. Shim/Locus
                                            K. Singh/Columbia University

Intended status: Informational
May 18, 2008
Expires: November 2008



        Simple SIP Usage Scenario for Applications in the Endpoints
                       draft-sinnreich-sip-tools-03


   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/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html"

   This Internet-Draft will expire in October 2008.

   Copyright Notice

      Copyright (C) The IETF Trust (2008).


Abstract





Sinnreich               Expires November 2008                  [Page 1]

Internet-Draft        Simple SIP Usage Scenario                May 2008


   For Internet-centric usage, the number of SIP related standards for
   presence, IM and audio/video communications can be reduced by using
   only the rendezvous and session initiation capabilities of SIP. Such
   'simple SIP' implies (1) using SIP without network based features and
   (2) without emulating the telephone network. Rich applications,
   including telephony features can however be implemented in the
   endpoints. This approach for SIP reduces the number of SIP standards
   to comply with, currently from roughly 100 to about 9. Additional
   application examples and references for NAT traversal and for
   security are also provided.

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
      1.1. The changing nature of voice communications...............3
      1.2. What Is Avoided by the Simple Usage of SIP................4
   2. Minimal Set of References......................................5
      2.1. RFC 3261: "SIP: Session Initiation Protocol"..............5
      2.2. RFC 4566: "SDP: Session Description Protocol".............5
      2.3. RFC 3264: "An Offer/Answer Model with SDP"................6
      2.4. RFC 3840: "Indicating User Agent Capability in SIP".......6
      2.5. RFC 3263: "SIP: Locating SIP Servers".....................6
      2.6. RFC 3856: "A Presence Event Package for SIP"..............6
      2.7. RFC 3863: "Presence Information Data Format (PIDF)".......7
      2.8. RFC 3428: "SIP Extension for Instant Messaging"...........7
      2.9. RFC 4474: "Enhancements for Authenticated Identity Management
      in SIP"........................................................7
   3. SIP Applications in the Endpoints..............................7
   4. NAT Traversal..................................................8
   5. Security Considerations........................................9
      5.1. SIP Security..............................................9
      5.2. Datagram Transport for SIP and Media Security............10
      5.3. ZRTP: Media Path Key Agreement for Secure RTP............10
   6. IANA Considerations...........................................10
   7. Conclusions...................................................10
   8. Acknowledgements..............................................11
   9. Changes from version 02.......................................11
   10. Informative References.......................................11
   Author's Addresses...............................................12




Sinnreich               Expires November 2008                  [Page 2]

Internet-Draft        Simple SIP Usage Scenario                May 2008


1. Introduction

   The Session Initiation Protocol has its origins in Internet
   multimedia conferencing work started in the early 1990's. SIP has
   also been universally embraced by the telecommunications industry,
   most of all due to its flexibility and extensibility to adapt to
   various telecom business models and services. The resulting drawback
   however has been the present complexity of SIP. This complexity is
   documented in "A Hitchhikers' Guide to SIP" [2] where roughly 140 SIP
   standards and Internet-Drafts are discussed or mentioned. See also
   the web site http://rfc3261.net [3] that tracks and displays the
   growth in numbers of SIP related standards. The increased complexity
   of SIP can be avoided by eliminating the traditional telephony
   approach of placing the "intelligence in the network". This is
   possible due to the increasing computing power of user devices and
   the rich applications residing in Internet endpoints. Powerful
   endpoints can thus enable new, simpler usages of SIP that are
   nevertheless standards compliant for basic discovery and session
   initiation. We will refer to this as the Internet-centric approach to
   SIP.



   This approach can be used both in client-server (CS) SIP
   implementations as well as in peer-to-peer (P2P) SIP. Service
   providers and various organizations deploying SIP can minimize the
   cost of the infrastructure by placing SIP based applications in the
   endpoints.

1.1.  The changing nature of voice communications

   Describing the change from voice communications and fax to rich
   Internet multimedia communications is beyond the scope of this memo,
   but one change will be highlighted here: Mixing of rich web based
   applications with voice communications, presence, IM and video. In
   such web based mixed applications, voice may or may not be the
   primary application. The possible usage scenarios of voice on the web
   differ considerably from traditional telephony.

   Rich Internet and web applications may support boundless user choice
   as an alternative to and beyond what is traditionally prepackaged as
   network based communication service plans. In such scenarios,
   applications residing in the endpoints may require only the
   rendezvous and session setup capabilities of SIP.





Sinnreich               Expires November 2008                  [Page 3]

Internet-Draft        Simple SIP Usage Scenario                May 2008


   Once the applications have established basic communications, it is up
   to them to support available features selected by users. This paper
   is targeted to such scenarios.

1.2.  What Is Avoided by the Simple Usage of SIP

   The simple usage of SIP can be accomplished by avoiding the
   traditional telephony centric approaches to provide, manage and
   charge for services, some examples of which are listed here.

  o Placing any services in the network other than the rendezvous
     function of SIP. Special considerations deserve here servers for
     NAT traversal, such as STUN and TURN relays that are also required
     in the network. We note here that NAT traversal is a basic Internet
     service function for all applications, not necessarily limited to
     SIP and RTP.


  o Avoiding the support of legacy telephony functions, such as
     emulating public telephone switch services and voice-only private
     branch exchanges.

  o Avoiding the support for legacy telephony business models such as
     identifying end user devices for the purpose of differentiated
     charging by type of service or charging for roaming between
     networks.


  o Avoiding policies and the associated policy servers and network
     elements to enforce specific policies for real-time communications.


  o Avoiding design considerations for SIP for compatibility with
     legacy telephony networks, traditional telephony services and their
     various addressing plans. This pushes the responsibility of mapping
     the URI to telephone numbers to edge networks where the IP-PSTN
     gateway functions are performed. Other handling of telephony
     specific functions such as early media are also pushed to edge
     gateway networks.







Sinnreich               Expires November 2008                  [Page 4]

Internet-Draft        Simple SIP Usage Scenario                May 2008


   The list is not exhaustive, but conveys the concept on what to avoid
   in order to making SIP a simpler protocol to understand and to
   implement.

   This approach limits the number of SIP standards to 9 listed in the
   following section as the core for simple SIP. We will refer in the
   following to 'simple SIP' as to what is necessary to only support the
   rendezvous and session setup functions of SIP, support basic presence
   and instant messaging and also support the identity requirements for
   security. Multi-purpose secure transport protocols such as TLS, DTLS
   and ZRTP are not included in this count and are included separately
   in the section on Security Considerations.

   The total number of references has been kept here to a minimum and
   includes other related topics, such as examples for providing
   telephony services in the endpoints, NAT traversal and security. The
   referenced papers are entry points into these knowledge domains and
   no attempt is made for an exhaustive reference list for such SIP
   related topics. Readers interested into a more exhaustive source of
   SIP topics can follow up with the comprehensive list in [2].

2. Minimal Set of References

   Here is the minimal set of references to support the Internet-centric
   approach to SIP outlined above.

2.1. RFC 3261: "SIP: Session Initiation Protocol"

   RFC 3261 [4] is the core specification for SIP. The trapezoid model
   for SIP RFC 3261 is only an example and a use case applicable to two
   service providers featuring an outgoing SIP proxy and an incoming SIP
   proxy in each domain respectively.

   SIP however can also work in peer-to-peer (P2P) communications.

2.2. RFC 4566: "SDP: Session Description Protocol"

   SDP [5] is the standard format for the representation of media
   details, transport addresses and other session data irrespective of
   the protocol used to transport the SDP data. SIP is one of the
   protocols used to transport SDP data, to enable the setting up of
   multimedia communication sessions. Other Internet application
   protocols use SDP as well.






Sinnreich               Expires November 2008                  [Page 5]

Internet-Draft        Simple SIP Usage Scenario                May 2008


2.3. RFC 3264: "An Offer/Answer Model with SDP"

   Though SDP has the capability to describe SIP sessions, how to arrive
   at a common description by two SIP endpoints requires a negotiation
   procedure to agree on common media codecs along with IP addresses and
   ports where the media can be received. This negotiation procedure is
   specified in RFC 3264 [6]. As will be seen in the following on NAT
   traversal, this negotiation is usually considerably complicated due
   to the existence of NAT between the SIP endpoints.

2.4. RFC 3840: "Indicating User Agent Capability in SIP"

   SIP UAs can convey their capability in the Contact header field
   indicating if it can support such as presence, IM, audio, video, if
   the device is fixed or mobile and other such as the endpoint being an
   automaton; voice mail for example. Which SIP methods are supported
   may also be indicated as specified in RFC 3840 [7]. In the CS model,
   SIP registrars can be informed of endpoint capabilities and also
   directly end-to-end.

2.5. RFC 3263: "SIP: Locating SIP Servers"

   RFC 3263 [8] adds key clarifications to the base SIP specification in
   RFC 3261 by specifying how a SIP user agent (UA) or SIP server can
   determine with DNS queries not only the IP addresses of the target
   SIP servers, but also which SIP servers can support UDP or TCP
   transport as required. TCP may be required to support secure SIP
   (SIPS) using TLS transport or when SIP messages are too large to fit
   into UDP packets. Successive DNS queries yield finer grain location
   by providing NAPTR, SRV and A type records. Note that finding a SIP
   server requires these three successive DNS queries.

   Locating SIP servers is also required for P2P SIP when a peer node
   wishes to communicate with a SIP UA outside its own P2P SIP overlay
   network.

2.6. RFC 3856: "A Presence Event Package for SIP"

   RFC 3856 [9] defines the usage of SIP as a presence protocol and
   makes use of the SUBSCRIBE and NOTIFY methods for presence events.
   SIP location services already contain presence information in the
   form of registrations, and as such can be reused to establish
   connectivity for subscriptions and notifications. This can enable
   either endpoints or servers to run rich applications based on
   presence.




Sinnreich               Expires November 2008                  [Page 6]

Internet-Draft        Simple SIP Usage Scenario                May 2008


2.7. RFC 3863: "Presence Information Data Format (PIDF)"

   RFC 3863 [10] defines the Presence Information Data Format (PIDF) and
   the media type "application/pidf+xml" to represent the XML MIME
   entity for PIDF. PIDF is used by SIP to carry presence information.

2.8. RFC 3428: "SIP Extension for Instant Messaging"

   The SIP extension for IM in RFC 3428 [11] consists in the MESSAGE
   method defined here only for the pager model of IM based on the
   assumption that each IM stands alone and conversation exists only in
   the client user interface in the endpoints or perhaps in the user's
   own imagination.

   Message sessions are supported by the Message Session Relay Protocol
   (MSRP) specified in RFC 4975. MSRP has advanced properties, such as
   working with relays that are beyond the scope of simple SIP.

2.9. RFC 4474: "Enhancements for Authenticated Identity Management in
   SIP"

   RFC 4474 [12] defines (1) an identity header and (2) an identity info
   header for SIP requests that carry respectively the signature of the
   issuer over parts of the SIP request and the signed identity
   information. The signature includes the FROM header and the identity
   of the sender. The associated identity info header identifies the
   sender of the SIP request, such as INVITE. The issuer of the
   signature can present their certificate as well. It is assumed the
   issuer may be the domain owner. Strong authentication is thus
   provided for SIP requests. Authentication for SIP responses is not
   defined in this document.

3. SIP Applications in the Endpoints

   Although the present adoption of SIP is mainly due to telephony
   applications, its roots are in the Web and it has initial similarity
   to HTTP. As a result, SIP may play other roles in adequately powerful
   endpoints (their power keeps increasing with Moore's law). SIP based
   multimedia communications may be linked with various other rich
   applications. Either some non-SIP application or the communication
   feature may be perceived as the primary usage in some cases. An
   example is mixing SIP based real-time communications with some web
   content of high interest to the user. It is a matter of judgment if
   the web content or the associated communication capability is more
   important or if the mix of both is most attractive.




Sinnreich               Expires November 2008                  [Page 7]

Internet-Draft        Simple SIP Usage Scenario                May 2008


   For new usages of SIP we believe avoiding the complexity of the
   traditional telephony model "intelligence in the network" is an
   essential requirement for such mixed applications. This is the main
   driver for writing this memo.

   SIP applications in the endpoints can however accomplish most
   telephony functions as well. This has been well documented in SIP
   related work in the IETF, such as:

  o "A Call Control and Multi-party usage framework for SIP" [13]
     presents an ample assortment of telephony applications where the
     call control resides in the participating endpoints that use the
     peer-to-peer feature invocation model.


  o "SIP Service Examples" [14] contain a vast collection of SIP call
     flows for traditional telephony that require no network support for
     the respective features. The peer-to-peer design and principles are
     based on the above paper on multiparty call control. The SIP
     service examples are extremely useful, since they illustrate in
     detail the concepts and applications supported by the core simple
     SIP references and go beyond that by also illustrating traditional
     telephony services.


   In conclusion, SIP applications in the endpoints can support both a
   mix of real-time communications with new rich Internet applications
   and traditional telephony features as well.

4. NAT Traversal

   SIP devices behind one or more NAT are at present the rule rather
   than the exception. In consequence, IETF contributors to SIP related
   work have published a wealth of information on various tools in the
   arsenal required to solve the difficult problem of NAT traversal for
   SIP signaling and RTP media streams.

  1. "Best Current Practices for NAT Traversal for SIP" [15] is a
     comprehensive summary of the use of the various tools, most
     prominent being STUN, TURN and ICE. This document provides a
     definitive set of 'Best Common Practices' to demonstrate the
     traversal of SIP and its associated media through NAT devices.




Sinnreich               Expires November 2008                  [Page 8]

Internet-Draft        Simple SIP Usage Scenario                May 2008


   As mentioned above, emerging communication models on the Internet may
   include a mix of SIP and non-SIP applications. A general, non-SIP
   specific approach for NAT traversal is therefore required. Other
   proposals such as NICE, generic for non-SIP, and "D-ICE" for RTSP
   streaming media have been proposed. This approach is based on
   somewhat different NAT traversal techniques for different application
   protocols.

  2. Another approach for NAT traversal that is generic and applicable
     for all applications is to deploy the Host Identity Protocol (HIP)
     and solve NAT traversal only once, at the HIP level for all
     application protocols. HIP may be supported in the endpoints only
     without any changes in the Internet routing infrastructure. HIP has
     many other useful features such as the support for mobility, for
     multihoming, and compatibility with IPv6 that are beyond the scope
     of this paper. NAT traversal for HIP is just as complex as it is
     for SIP and it may use ICE techniques as well. "Basic HIP
     Extensions for Traversal of Network Address Translators and
     Firewalls" [16] provides an extensive coverage of the use of HIP
     for NAT traversal.

5.  Security Considerations

   All protocols discussed in this paper have their own specific
   security considerations that MUST be considered. These are not
   repeated here.

   The special security considerations however for SIP signaling
   security and RTP media security are discussed here.


5.1. SIP Security
   SIP security has two main parts: Transport security and identity.



o Transport security for SIP is specified in RFC 3261. Secure SIP has
  the notation SIPS in the request URI and uses TLS over TCP. Note that
  SIP over UDP cannot be secured in this way. Transport security works
  only hop by hop. Specifying SIPS does not provide an absolute
  assurance that some hops on the path may not use non-secure TCP
  transport. Specifying SIPS requires therefore the user to trust all




Sinnreich               Expires November 2008                  [Page 9]

Internet-Draft        Simple SIP Usage Scenario                May 2008


  the intermediate proxies, and does not provide end-to-end user
  encryption.


o RFC 4474: "Enhancements for Authenticated Identity Management in SIP"
  mentioned previously specifies the use of certificates for secure
  identification of the parties involved in SIP signaling requests.

5.2. Datagram Transport for SIP and Media Security
   The Datagram Transport Layer Security specified in RFC 4347 [17] is a
   comprehensive security solution both for SIP datagrams as well for
   RTP media. DTL has wide applicability for other applications that
   require UDP transport. DTLS has been designed to have maximum
   commonality with TLS yet does not require TLS transport and works
   over UDP.


5.3. ZRTP: Media Path Key Agreement for Secure RTP
   ZRTP [18] provides RTP media security without depending on SIP
   signaling, though it can use authentication obtained by SIP signaling
   as well. ZRTP does not require any Public Key Infrastructure (PKI).
   ZRT uses normal RTP/AVP profiles for codec payload descriptions. ZRTP
   works over UPD since it is designed to provide security for real-time
   media flows.

6. IANA Considerations

   There are no IANA considerations associated with this memo.

7. Conclusions

   Rich Internet applications may include real time communication usage
   scenarios that differ from the traditional telephony services for
   voice. For Internet-centric usage, the number of SIP related
   standards for presence, IM and multimedia communications can be
   reduced by using only the rendezvous and session initiation
   capabilities of SIP. Such 'simple SIP' implies (1) using SIP without
   network based features and (2) without emulating the telephone
   network. Rich applications, including telephony features can however
   be implemented in the endpoints. This approach for SIP reduces the
   number of SIP related standards, currently from roughly 100 to about
   9. Successful IP communications must however include solutions for
   NAT traversal which are referenced here as well.




Sinnreich               Expires November 2008                 [Page 10]

Internet-Draft        Simple SIP Usage Scenario                May 2008


8. Acknowledgements

   We would like to thank Wilhelm Wimmreuter for the detailed review of
   the initial draft and to Arjun Roychaudhury for the comments
   regarding the need for a definition of network based services.

   This document was prepared using 2-Word-v2.0.template.dot.

9.  Changes from version 02

   The text has been rewritten and is based on the presentation to the
   SIPPING WG at the 71 IETF.

10. Informative References

   Since this is an informative memo, we provide no list of mandatory
   SIP related standards, but only an informative list of SIP related
   standards and Internet-Drafts that serve us for the purpose of a
   simple toolkit for SIP.

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

   [2] "A Hitchhiker's Guide to the Session Initiation Protocol (SIP)"
   by J. Rosenberg. Internet-Draft, IETF February 2008. Work in
   progress.

   [3] "VoIP RFC Watch by Nils Ohlmeier". Web site that is tracking the
   number and pages of SIP related standards at http://rfc3261.net/"

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

   [5] RFC 4566: "SDP: Session Description Protocol" by M. Handley et
   al. IETF, July 2006.

   [6] RFC 3264: "An Offer/Answer Model with the Session Description
   Protocol (SDP)" by J. Rosenberg et al. IETF, June 2002.

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

   [8] RFC 3263: "SIP: Locating SIP Servers" by J. Rosenberg et al.
   IETF, June 2002.

   [9] RFC 3856: "A Presence Event Package for the Session Initiation
   Protocol" by J. Rosenberg. IETF, August 2004.


Sinnreich               Expires November 2008                 [Page 11]

Internet-Draft        Simple SIP Usage Scenario                May 2008


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

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

   [12] RFC 4474: "Enhancement for Authenticated Identity Management in
   the Session Initiation Protocol (SIP)" by J. Peterson et al. IETF,
   August 2006.

   [13] "A Call Control and Multi-party usage framework for the Session
   Initiation Protocol (SIP)" by R. Mahy et al. Internet-Draft. IETF
   April 2008, work in progress.

   [14] "Session Initiation Protocol Service Examples" by A. Johnston et
   al., Internet-Draft. IETF, February 2008. Work in progress.

   [15] "Best Current Practices for NAT Traversal for SIP" by C. Boulton
   et al., IETF, April 2008. Internet-Draft. Work in progress.

   [16] "Basic HIP Extensions for Traversal of Network Address
   Translators and Firewalls" by M. Komu et al. Internet-Draft, IETF,
   February 2008. Work in progress.

   [17] "RFC 4347: "Datagram Transport layer Security" by E. Rescorla et
   al. IETF, April 2006.

   [18] "ZRTP: Media Path Key Agreement for Secure RTP" by P. Zimmermann
   et al. Internet-Draft, IETF, March 2008. Work in progress.

Author's Addresses

   Henry Sinnreich

   Adobe Systems, Inc.

   601 Townsend Street,

   San Francisco, CA 94103, USA

   Email: henrys@adobe.com



   Alan B. Johnston

   Avaya


Sinnreich               Expires November 2008                 [Page 12]

Internet-Draft        Simple SIP Usage Scenario                May 2008


   Saint Louis, MO, USA

   Email: alan@sipstation.com



   Eunsoo Shim

   Locus Telecommunications, Inc.
   111 Sylvan Avenue
   Englewood Cliffs, NJ 07632 USA
   Email: eunsooshim@gmail.com



   Kundan Singh

   Columbia University Alumni

   660 King Street, #359

   San Francisco, CA 94107, USA

   Email: kundansingh_99@yahoo.com


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

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

   "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, THE
   IETF TRUST 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".

Intellectual Property




Sinnreich               Expires November 2008                 [Page 13]

Internet-Draft        Simple SIP Usage Scenario                May 2008


     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.

Acknowledgment

      Funding for the RFC Editor function is provided by the IETF

      Administrative Support Activity (IASA).






















Sinnreich               Expires November 2008                 [Page 14]


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