SIP Core Working Group H. Sinnreich-editor Internet Draft A. Johnston/Avaya Intended status: Informational January 19, 2010 Expires: July 2010 SIP APIs for Communications on the Web draft-sinnreich-sip-web-apis-00 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This document may not be modified, and derivative works of it may not be created, except to publish it as an RFC and to translate it into languages other than English. 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 July 29, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Sinnreich Expires July 29, 2010 [Page 1] Internet-Draft SIP APIs for Communications on the Web January 2010 Abstract Interactive communications are becoming part of rich Internet applications (RIA). This can be accomplished entirely by using Web technology and developing it as an Internet standard. Voice over IP (VoIP) features developed for Session Initiation Protocol (SIP 2.0) can be preserved in rich multimedia communications and applications on the web. Hyper Text Transport Protocol (HTTP) is used for control and signaling data and RTP for interactive media transport respectively. No other network application protocols are required. Web, fixed and mobile device application development tools can thus be used to include components and widgets for Internet presence, Instant Messaging (IM), voice and video. This opens Internet communications, including voice to application developers and will also enhance the user experience with real-time Web and mobile communications. Usage scenarios include service providers, private IP networks, device application developers and media companies providing a mix of integrated communications, applications and media. This memo argues for the development and standardization of Application Programming Interfaces (APIs) to allow the benefits of SIP to be used by Rich Internet Applications (RIA), for fixed and mobile devices. Table of Contents 1. Introduction...................................................3 1.1. Motivation................................................3 1.2. Background................................................4 2. Problems with SIP 2.0..........................................6 2.1. SIP 2.0 is too expensive for Web application developers...6 2.2. Platform APIs cannot hide the multipliers of complexity...6 2.2.1. Rich Internet Application Development................6 2.3. Technical shortcomings of SIP 2.0 to be corrected.........7 2.3.1. IP addresses in SIP messages.........................7 2.3.2. NAT traversal in SIP networks........................7 2.3.3. SDP is stale and complex.............................8 2.3.4. SIP 2.0 has no formal architecture such as REST......8 2.3.5. 'Extensible protocol' leads to unbounded complexity..8 2.3.6. SIP network routing protocol is missing..............9 2.3.7. No adequate IDE for SIP 2.0 networks.................9 2.3.8. Application interaction..............................9 2.3.9. Concurrency in distributed SIP networks..............9 2.3.10. SIP 2.0 is used only for VoIP......................10 2.3.11. SIP 2.0 telephony orientation is not helpful.......10 2.3.12. SIP 2.0 has not kept up with technology............10 Sinnreich Expires 29, 2010 [Page 2] Internet-Draft SIP APIs for Communications on the Web January 2010 3. Options for Web Based Communications..........................11 4. Usage and Requirements of Voice on the Web....................12 4.1. Voice on the Web is for Internet Usage...................12 4.1.1. Applications reside in endpoints of the Internet....12 4.2. Addressing on the Internet...............................12 4.3. Applications and communications in Web feature servers...12 4.4. Sever to server communications...........................13 4.5. Porting core SIP functions to standards XML based API....13 4.6. Gateway functions to SIP 2.0.............................13 4.7. Session initiation using metadata........................14 4.8. Applications using object oriented computing.............14 4.9. Host Identity Protocol (HIP).............................14 4.10. Summary of SIP based Web communications.................15 4.11. Summary of benefits.....................................16 5. Security Considerations.......................................16 6. IANA considerations...........................................16 7. Conclusions...................................................16 8. Acknowledgements..............................................17 9. Informational References......................................17 10. Authors' Addresses...........................................19 1. Introduction 1.1. Motivation Rich Internet Applications (RIA) are based on data only and until now could not support interactive voice communications, since two protocols are required for interactive voice and other interactive applications such as games: 1. A data (signaling) channel, such as provided by SIP or HTTP. Note all browser-based applications use the reliable and secure transport of HTTP and HTTPS over TCP and TLS respectively, but such data transport is not optimal for real-time interactive media such as voice and video communications. As a result, media such as voice is not implemented in the browser itself, but in some other endpoint application. 2. A media channel to transport voice and video, such as the Real Time Protocol (RTP) over UDP. This is the other protocol required for real-time interactive applications on the Web. This memo is motivated by two related objectives: . To add interactive voice and video communications to web pages. Sinnreich Expires 29, 2010 [Page 3] Internet-Draft SIP APIs for Communications on the Web January 2010 . To use typical Web development tools to also serve to develop interactive, real-time communication applications and thus make them accessible to the large community of Web developers; single individuals or small creative teams. Innovative real-time applications can thus be enabled that include communications, games and real-time control. Note that APIs and advanced web application development platforms can hide the fact that part of a web application runs in the browser and part on the "desktop", the native platform itself. This can support the hiding of both the data transport and media transport complexities from the Web application developer [23]. APIs and Integrated Development Environments (IDEs) for fixed and mobile device application development also hide the complexity of the underlying device and network protocols, so the pertinent SIP APIs proposed here may be applicable here as well, to the extent of the mobile device using Internet and W3C standards. Under this assumption, the terms Web applications, fixed and mobile device applications can be used here interchangeably. The memo is formulated from the standards perspective of developing a SIP-alike standard, but based on the Web REST architecture [1] and using HTTP [2] transport instead of SIP 2.0 [3]. The memo assumes some initial acquaintance of the reader with both SIP 2.0 and the REST architecture for the Web. We also encourage some reflections on the differences between the REST architecture and SIP 2.0 based systems. The use of RTP [4] for interactive media transport requires a mechanism for the traversal of Network Address Translators (NAT). As one option described below, NAT traversal is implemented by the Host Identity Protocol (HIP) [5], since it is also required in endpoints for the IPv4-IPv6 transition, mobility and multi-homing for all types of applications. References: For HTTP, RTP and HIP, instead of previous RFCs we have provided as reference the Internet-Drafts that will replace them based on long term, worldwide deployment experience. For SIP 2.0, the present work in the SIP Core [6] WG is targeted to produce an update. 1.2. Background Rich Internet applications (RIA) and interactive applications such as voice, and games act at present as 'ships passing by night'; that is living on different application platforms and not interacting in any way. Users perceive different applications and services. Developer Sinnreich Expires 29, 2010 [Page 4] Internet-Draft SIP APIs for Communications on the Web January 2010 communities are different for voice and for Web applications. Probably most problematic is the lack of seamless integration of RIA and interactive communications. The Session Initiation Protocol (SIP) has been defined in the IETF starting in the late '90s and has been adopted practically by all telecommunications standards organizations and mobile telephony consortiums as the signaling protocol for Voice over IP (VoIP), as a replacement for circuit switched telephony in fixed and mobile networks. SIP is also deployed in most VoIP services. As such, SIP has proven to be a uniquely successful protocol in the telecom industry and in large part also over the Internet. The universal adoption of SIP 2.0 by telephony service providers has proven however to be a mixed blessing, since telephony has become the only significant application for SIP. SIP 2.0 developments have been focused mainly to re-engineer traditional telephony services over IP networks. We know no significant new Internet applications resulting from SIP 2.0. Since the telephony model was already well developed when SIP was defined, no innovation was required to develop VoIP based on SIP 2.0. Traditional telecom infrastructure vendors are placing voice applications (also known as 'services' in the telecom industry) in the "SIP network", that is in numerous dedicated servers and other network elements, as in traditional telephony. The resulting complexity and interdependency across numerous network elements has proven to hinder innovation that is possible in the endpoints and is also making SIP 2.0 expensive for service providers. Moving from application protocols to applications Note that in a similar fashion other network application protocols; XMPP [7] or MSRP [8], and RTSP [9] have also one single significant application each: IM chat and network media player respectively. This is due to the '90s view that new Internet apps require new protocols. The advent of RIA has made this view obsolete at present, given the seemingly boundless number of new rich Internet applications using just HTTP as the only standard network application layer protocol. The use of HTTP has even been extended to streaming media transport, but this is not in our focus here on interactive communications. Sinnreich Expires 29, 2010 [Page 5] Internet-Draft SIP APIs for Communications on the Web January 2010 2. Problems with SIP 2.0 2.1. SIP 2.0 is too expensive for Web application developers The main problem with SIP 2.0 and its related work in the IETF is not of technical but of economic nature: Web application developers are focused on their applications and have no resources to dedicate to SIP and its associated protocols developed in numerous SIP-related IETF working groups. The accumulated 100's of RFCs and 1,000's of pages of Internet-Drafts developing into even more RFCs require not only full time dedication, but also specialized teams available only to larger telecom infrastructure companies. The learning effort for SIP 2.0 is economically not sustainable and precludes SIP from being used by Web application developers. Note that gateways have been built to link RIA to SIP based communications by teams having both SIP and RIA expertise. We consider this however a noteworthy exception and not easily accessible to the large number of Web developers. 2.2. Platform APIs cannot hide the multipliers of complexity Note that hiding SIP 2.0 complexity by product APIs is not a viable option, since there is a multiplication effect for APIs for diverse operating systems, computing platforms and SIP extensions resulting in countless API flavors. Especially mobile devices that increasingly are dominant for voice communications are built on a large number of different platforms. 2.2.1. Rich Internet Application Development By contrast, Web developers have proven to be so innovative in large part by completely ignoring network protocols and network features. Web developers can build their applications based on one single transport application layer protocol: HTTP 1.1. Even the knowledge of HTTP by application developers is not required, since Web software development tools and platform APIs hide it rather well. Platform APIs and Integrated development environments (IDE) hide the HTTP API's under a set of graphic oriented tools and ready-made Web data services components or widgets. Examples of ready-made data service components are instant messaging (IM), database access and Web mashups. Sinnreich Expires 29, 2010 [Page 6] Internet-Draft SIP APIs for Communications on the Web January 2010 2.3. Technical shortcomings of SIP 2.0 to be corrected This section is written for engineers familiar with SIP and interested in more perfection. Successful protocols however do not require perfection and readers interested only in our approach to integrate RIA and communications can skip directly to section 3. Large-scale deployment of SIP and the parallel developments on the Web have revealed in hindsight a number of technical shortcomings, some of which are reviewed here. These shortcomings have not prevented SIP 2.0 from achieving global deployment for telephony and also to ensure a large degree of interoperability, even for more complex telephony features. The shortcomings are mentioned here only because they do not need to be carried over to real-time communication enabled Web applications. 2.3.1. IP addresses in SIP messages The Session Description Protocol (SDP) payload in SIP contains the IP address and port for each receiving media component, such as voice, video, presence and text messaging. This is in contradiction to the "UNSAF" RFC 3424 that specifies no IP addresses must be used inside protocol messages, since NAT and other intermediaries will modify IP addresses and ports seen on the other side of the NAT or other intermediary. The use of IP addresses in SIP messages having an SDP payload requires additional complex techniques for NAT traversal by voice and other media. From the perspective of RFC 3424, SIP 2.0 and its SDP payload has a broken protocol design that has not yet been corrected. 2.3.2. NAT traversal in SIP networks NAT traversal in SIP networks requires the use of additional, rather complex utilities: STUN, TURN and ICE. Even these utilities do not provide a 100% guarantee for NAT traversal in multi-NAT scenarios. As of today there are no deployment statistics of the percentage of success for NAT traversal, the handling of so-called hairpin scenarios and measured data for additional delay introduced by the large number of messages belonging to the NAT traversal utilities. A fallback technique for NAT traversal is some form of tunneling of VoIP through designated Well Known Port Numbers [11], such as using port 80 that is designated for HTTP. This contradicts security practices in private IP networks and is not commercially advertised, though deployed in practice, since it most always works. Sinnreich Expires 29, 2010 [Page 7] Internet-Draft SIP APIs for Communications on the Web January 2010 2.3.3. SDP is stale and complex The Session Description Protocol (SDP), the principal payload of SIP, dates from the late '90s and has been extended in about 40 RFCs. SDP carries the IP addresses and ports that cause the NAT traversal problems and also carries 'dead' lines of code that are not used in SIP. It's only usefulness; negotiating session data might be better accomplished by using metadata1 such as the Extensible Metadata Platform (XMP), see the Requirements section below. 2.3.4. SIP 2.0 has no formal architecture such as REST A formal description of the architectural style for the Web was published in 2000 and is known as the Representational State Transfer (REST). HTTP 1.1 is based on REST. SIP systems have no similar formal architecture, though much of the initial SIP design was based on HTTP. SIP networks may be composed of many network elements whose behavior must be specified on a case-by- case basis and requires a level of knowledge not widely available in the industry. There is no common or widely accepted knowledge base for architecting SIP networks. The resources closest to a knowledge base are the huge mail discussion archives for the various SIP- related working groups in the IETF. On many critical topics these discussions have not come to closure as of today as illustrated by the SIP-related Working Group mailing lists. 2.3.5. 'Extensible protocol' leads to unbounded complexity RFC 4485 provides guidelines for extending SIP 2.0 without however defining a formal structure and what the limits may be for the resulting number of extensions and the resulting unbounded complexity of SIP 2.0. Extensibility for SIP must not be confused with formally defined and structured extensibility, such as in XML or in REST. Adding new SIP extensions to existing code is the opposite of software development practice where strong version control is a prerequisite for quality software development. As a consequence of lack of versioning for SIP, no applicable versioning tools for developers have been published for SIP as a protocol and its extensions. This comment is written with the mindset that SIP extensions should be have been based on public pseudo code and reference implementations. Other telecom standards organizations and consortiums have also added extensions that have however not been accepted by the IETF, but they have practically added even more to the complexity and lack of a formal structure for SIP. Sinnreich Expires 29, 2010 [Page 8] Internet-Draft SIP APIs for Communications on the Web January 2010 2.3.6. SIP network routing protocol is missing SIP based client-server VoIP networks don't have an IP-like routing protocol, in the sense that any new network element discovers its neighbors and builds routing tables without human intervention, such as is known in IP networks and in P2P overlay networks as well. The lack of a SIP 2.0 routing protocol requires manual re-engineering and regression testing of the whole SIP network whenever there is change in the services supported or in the service policies. Actually, the deployment of back-to-back User Agents (B2BUA), aka Session Border Controllers by telephony service providers makes routing and any architectural approach quite a challenge [13] or outright impossible since there are no standards for the behavior of B2BUA. The formal REST architecture will facilitate testing criteria for such and other types of intermediaries. 2.3.7. No adequate IDE for SIP 2.0 networks We know of no SIP integrated development environments (IDE) for SIP network development and testing tools, similar to those developed for Web client-server applications that not only support application development, but also support fine-tuning of performance and bandwidth consumption by simulating both the client and the server in the same testing instance. One possible reason is the smaller population of SIP developers vs. Web application developers, not enough to make a business case for SIP IDE. 2.3.8. Application interaction The interaction of applications in telephony is a complex topic and a framework has been published for SIP application interaction in RFC 5629. No design tools are available to avoid interaction in a predictable manner in SIP 2.0 networks. However placing SIP services in the endpoints enable developers to test any possible interaction locally during development. 2.3.9. Concurrency in distributed SIP networks Concurrency in computer networks in general is still a research topic. Concurrency of processes in SIP networks is still a research topic as well. Examples of concurrency problems in SIP networks are race conditions described in RFC 5407, forking scenarios with early media and network based application interactions. Sinnreich Expires 29, 2010 [Page 9] Internet-Draft SIP APIs for Communications on the Web January 2010 We don't know of any commercial design tools to deal with concurrency in SIP networks. 2.3.10. SIP 2.0 is used only for VoIP We know no significant applications for SIP 2.0 other than traditional telephony re-engineering for VoIP at present. This focus has contributed to avoiding SIP 2.0 as a flexible generic application platform. 2.3.11. SIP 2.0 telephony orientation is not helpful Though RFC 4485 clearly states that SIP was not designed to emulate telephony such as in the PSTN and ISDN telephone networks, most of the SIP related IETF work and most SIP 2.0 RFCs are doing exactly that: Supporting legacy telephone models and services, only changing the network to IP. The legacy telephony orientation of SIP 2.0 does however not reflect at all the evolving modern Internet and mobile communications and is a main motivation for this memo. 2.3.12. SIP 2.0 has not kept up with technology After SIP was defined in the late '90s, significant new communication applications have been invented on the Internet. Note that most of them either did not require any new network layer application protocols or use proprietary protocols: . Peer-to-peer networks . Streaming media over p2p or over streaming HTTP . Blogs . Wikis . Web conferencing, desktop and application sharing . Web office and enterprise applications with associated communications . Social networks for the web and mobile device . Cloud computing may be especially interesting, since no specific SIP functions need to be allocated to specific servers or other network elements. Sinnreich Expires 29, 2010 [Page 10] Internet-Draft SIP APIs for Communications on the Web January 2010 Due to the focus on VoIP telephony, none of these technologies, except P2P have been applied to the benefit of SIP. Note also that these are all data based only: Text and graphics, without voice. One cannot help notice that web based communications and voice need each other in a complete applications and communications portfolio. 3. Options for Web Based Communications The main options for Internet Voice standards range from using SIP 2.0 VoIP 'as is' to an all RIA based approach. The options considered here are: 1. Use SIP 2.0 'as is' and fix interoperability problems by testing and perfecting SIP 2.0, such as organized by the SIP Forum in the SIP interoperability testing (SIPit) events. This activity has been highly successful, mostly for telephony, even for more complex features of SIP 2.0. The complexity of SIP 2.0 may however always leave some corner cases where interoperability cannot be insured. Use SIP 'as is' does not support integration with RIA and does not remove the technical flaws discussed here. 2. Follow the IETF standards work in the SIP Core working group where most of the core SIP 2.0 specifications are harmonized, based on the large operational experience with SIP 2.0. This approach does not support integration with RIA and does not remove the technical issues discussed here in section 2.3 either, such as IP address/port in messages (not compliant with 'UNSAF') and stale SDP. 3. Use just 'simple SIP' as described in RFC 5638 until the SIP Core Working Group finishes its task. 'Simple SIP' facilitates the partial integration of RIA and VoIP in the endpoints, but still exposes Web developers to the complexity of SIP 2.0, though to a much lesser degree. 'Simple SIP' avoids to a large degree the telephony orientation of SIP 2.0 but does not remove the technical flaws of SIP 2.0. 4. Redesign Voice on the Web from ground up, to be just another RIA and move interoperability with legacy TDM and VoIP telephony voice to gateways at the IP network edge. The gateway function, see below, can be either network based or placed in endpoints that can support such interoperability. This approach, described here in the memo meets both objectives of complete integration of VoIP with RIA and also avoids the technical flaws of SIP 2.0. Sinnreich Expires 29, 2010 [Page 11] Internet-Draft SIP APIs for Communications on the Web January 2010 Choosing any of the above options depends on the business model of the various VoIP providers. Given however the change of communications and applications enabled by the Internet, there should be enough interest to flexibly mix and match voice and RIA without any constraints. This memo is therefore focused on option number 4: Redesigning Internet voice as just another RIA. 4. Usage and Requirements of Voice on the Web This section contains a short overview of Internet usage, generic requirements and how they can be accomplished. 4.1. Voice on the Web is for Internet Usage Signaling data for interactive communications must be designed for Internet usage and be integrated in a seamless manner with other RIA. This will enable Communications on the Web standards to mirror the new emerging communication scenarios. 4.1.1. Applications reside in endpoints of the Internet Communication applications reside in endpoints, using either the basic client-server (as opposed to complex SIP networks with many network elements) or the peer-to-peer model. This gives easy access to innovative application developers and is another confirmation of the End-to-End Principle and to the Simplicity Arguments of the Internet as articulated in RFC 1958 [14] and RFC 3439 [15] respectively. These principles explain in our opinion the advantage of the Internet architecture over traditional telecommunication networks and their recent reincarnations over IP. 4.2. Addressing on the Internet Web style addressing, HTTP URLs are used throughout, instead of phone numbers. User URLs look like email addresses. Discovery of and translation to phone numbers, if and when required, is accomplished in telephony gateways acting as multi-user VoIP or PSTN endpoints. 4.3. Applications and communications in Web feature servers Some very few, but essential communication functions, such as for rendezvous, location data and voice mail can reside in specialized Sinnreich Expires 29, 2010 [Page 12] Internet-Draft SIP APIs for Communications on the Web January 2010 servers, such as in Web feature servers or in distributed P2P overlay networks. 4.4. Sever to server communications The core SIP communication model between users in different domains is based on an outgoing server where the caller is registered and an incoming server where the called party is registered. This function can be easily accomplished between Web feature servers using symmetrical HTTP data transport. Internet users have complete control in selecting their application and communications portfolio, no matter who provides the various applications. This portfolio is resident and accessible from the endpoint, though various service providers may provide assistance only. Complete applications portfolios reside in endpoints and are under instant user control. 4.5. Porting core SIP functions to standards XML based API After porting SIP transport to HTTP, the problem remains how to preserve the core SIP request-response messages as a standard and still avoid a dedicated network application layer protocol? It is well known that platform dependent APIs are not as long lived as protocols are. The answer consists in porting the main SIP 2.0 request-response messages to XML pages that replicate the SIP 2.0 messages in various call flows. The resulting SIP XML documents will be available under a registered XML name space. All Web development tools can work with XML documents. 4.6. Gateway functions to SIP 2.0 The mapping of SIP 2.0 request-response messages to XML documents represent a trivial way for building gateway functions that can reside either in RIA user agents (UA) or in Web feature servers. XML documents can be built using existing SIP well deployed call flows [16]. This is incidentally also a better method for making SIP an "extensible" protocol; since entities that desire extended functionality can easily define their own private namespaces for other XML based SIP messages, without burdening the proposed base for core SIP API for RIA standard. Sinnreich Expires 29, 2010 [Page 13] Internet-Draft SIP APIs for Communications on the Web January 2010 4.7. Session initiation using metadata SIP 2.0 uses the rather stale Session Description Protocol (SDP) developed in the mid to late '90s for describing and negotiating session data. At present, the use of metadata can accomplish these functions in a more comprehensive way and also better support device independence. Metadata can also convey other device capabilities besides the codec and transport address; since screen size and screen technology, audio, as well as user input (keyboard, touch screen, remote control) can be also used to maximize user experience. User experience cannot be as well supported with SDP. SIP UA configuration can thus be automatically adapted to any device, ranging from small mobile devices to large telepresence or to home entertainment systems. Implementation examples are such as in the Open Screen Project [17] and using the proposed Extensible Metadata Platform (MXP) [18]. Metadata for session negotiation will be used only for SIP 3.0, while keeping the SDP session negotiation 'as is' for SIP 2.0. 4.8. Applications using object oriented computing Application design and structure is recommended to use object- oriented programming (OOP) [19] designed to support both the business logic and the user interface. OOP and their interpreters can better insure the high quality code that is a pre-requisite for high security applications. 4.9. Host Identity Protocol (HIP) As mentioned, HIP is one option for NAT traversal for UDP packets of interactive media such as voice and video. It is actually our favored option. Another applicable option for RTP/UDP media packets associated with HTTP data is tunneling of the media through well known ports, such as port 80 used for HTTP itself. As mentioned however, tunneling using well know ports allocated for other Internet protocols is not acceptable for security and private IP network management reasons. Background to HIP: From the IP network perspective, the IP address is both an address for routing IP packets and also the name or identity of the "host" endpoint in the network. This has been a perennial problem for IP networks and has been solved for endpoints by HIP that separates the address from the identity. HIP can support the following features: Sinnreich Expires 29, 2010 [Page 14] Internet-Draft SIP APIs for Communications on the Web January 2010 o Enhanced, VPN-like security o The transition from IPv4 to IPv6 o Mobility o Multi-homing o NAT traversal for all application layer protocols. HIP has its origin in the so-called User Space VPN and resides only in endpoints. HIP is the most cost effective solution for NAT traversal since it has all the other benefits listed here as well. By the use of HIP, the function of NAT traversal is not any more the responsibility of the SIP system. Note that HIP uses for NAT traversal the same utilities STUN/TURN/ICE that are also used in SIP, though adapted for HIP. But as mentioned, the NAT traversal benefits all application layer network protocols, since they reside over HIP in the IP protocol stack. 4.10. Summary of SIP based Web communications The propose Web based communications architecture for SIP augments SIP 2.0 in the following: o The communications architecture is REST based o Web style addressing is used throughout o HTTP 1.1 replaces SIP 2.0 data transport o SIP 2.0 requests and response messages are represented by standardized XML documents o SIP feature server functions are placed in Web feature servers o User agents (UA) are enabled for both RIA and communications o NAT traversal is delegated to HIP o The gateway function to SIP 2.0 networks can reside either in Web feature servers or in the UA. Sinnreich Expires 29, 2010 [Page 15] Internet-Draft SIP APIs for Communications on the Web January 2010 4.11. Summary of benefits The benefits of making voice another component of RIA can be summarized here: o Access to VoIP apps by Web and device application developers o VoIP becomes a RIA component o RIA development tools can be used for VoIP o VoIP can be delivered over HTTP-oriented content distribution networks (CDN) as well. 5. Security Considerations Several components come into play for Web based voice security: o Architecture: The security of REST based voice communications will be considerably enhanced by the use of the formal REST architecture [22]. o Data transport: HTTP 1.1 [20] security is ported to voice signaling security. o Media transport: RTP security applies. o Application security: The benefits of strong OOP development tools used for Web applications will be ported to Internet voice applications as well. o Security enhanced by HIP: VPN-style enhanced security over the network applies as well. We don't exclude the discovery of new vulnerability scenarios during large-scale deployment, though the above components provide solid multi-layer security as a starting point for development. 6. IANA considerations This memo has no IANA considerations. 7. Conclusions Interactive communications such as voice and games are becoming a part of rich Internet applications. This can be accomplished entirely Sinnreich Expires 29, 2010 [Page 16] Internet-Draft SIP APIs for Communications on the Web January 2010 by using existing Web standards and Web development tools. This approach will support: o The full integration of rich Internet applications with voice and other real-time interactive applications o Enable application developers to integrate VoIP o Give Internet voice communications the benefit of the formal REST architecture o Re-use existing Web and device software development platforms for enhanced user experience, security and resilience for voice applications. 8. Acknowledgements The authors are indebted to Cullen Jennings and Kundan Singh for a critical review that has helped us focus on the direction of the SIP API and fix a number of issues. We would also like to thank Bernard Aboba, Eric Burger, David Jared, Danielle Deibler and Robert Sparks to helpful discussions that eventually led to this memo. This document was prepared using 2-Word-v2.0.template.dot. 9. Informational References All references here are informative in this version of the memo. For brevity, only references pertinent to this memo are given, while well-known Internet standards are sometimes mentioned only in the body of the memo. [1] Representational State Transfer (REST)" by R.T. Fielding, Ph.D. Dissertation, UCI 2000, http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.ht m [2] "HTTP/1.1bis, parts 1-7, Internet-Draft, IETF 2009, work in progress. [3] RFC 3261: "SIP: Session Initiation Protocol" by J. Rosenberg et al. IETF, June 2002. Sinnreich Expires 29, 2010 [Page 17] Internet-Draft SIP APIs for Communications on the Web January 2010 [4] RFC 3550: "RTP: A Transport Protocol for Real-Time Applications" by H. Schulzrinne and S. Casner. IETF, July 2003. [5] "Host Identity Protocol" by R. Moskowitz et al. Internet-Draft, IETF 2009, work in progress. [6] The IETF SIPCore WG charter is at http://www.ietf.org/dyn/wg/charter/sipcore-charter.html [7] "Extensible Messaging and Presence Protocol (XMPP): Core" by P. Saint-Andre. Internet-Draft, IETF November 2009, work in progress. [8] RFC 4975: "The Message Session Relay Protocol (MSRP)" by B. Campbell et al. IETF, September 2007. [9] RFC 2326: "Real Time Streaming Protocol (RTSP)" by H. Schulzrinne et al. IETF, April 1998. [10] VoIP RFC Watch: http://rfc3261.net/ [11] IANA Port Numbers: http://www.iana.org/assignments/port-numbers [12] Dublin Core Metadata Initiative: http://dublincore.org/documents/2008/08/04/dc-html/ [13] "Requirements for SIP Session Border Control Deployments" by J. Hautakorpi et al., I-D.draft-ietf-sipping-sbc-funcs, IETF, January 2009. [14] RFC 1958: "Architectural Principles of the Internet" by B. Carpenter, Internet Architecture Board (IAB), June 1996. [15] RFC 3439: "Some Internet Architectural Guidelines and Philosophy" by R. Bush and D. Meyer", IETF, December 2009. [16] RFC 5359: "Session Initiation Protocol Service Examples" by A. Johnston. IETF, October 2008. [17] "The Open Screen Project": http://www.openscreenproject.org [18] Extensible Metadata Platform: http://en.wikipedia.org/wiki/Extensible_Metadata_Platform [19] Object Oriented Programming: http://en.wikipedia.org/wiki/Object- oriented_programming#OOP_languages Sinnreich Expires 29, 2010 [Page 18] Internet-Draft SIP APIs for Communications on the Web January 2010 [20] HTTP/1.1, part 7: Authentication by R. Fielding et all. I-D.draft-ietf-httpbis-p7-auth, HTTPbis WG, IETF October 2009, work in progress. [21] RFC 5638: "Simple SIP Usage Scenario for Applications in the Endpoints" by H. Sinnreich et al. IETF, September 2009. [22] A detailed discussion of REST security can be found at http://www.vordel.com/downloads/rsa_conf_2006.pdf [23] Adobe AIR Developer Center, http://www.adobe.com/devnet/air/ 10. Authors' Addresses Henry Sinnreich - editor Unaffiliated Email: henry.sinnreich@gmail.com Alan Johnston Avaya Email: alan.b.johnston@gmail.com Sinnreich Expires 29, 2010 [Page 19]