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]