From: http://www.ietf.org/id/draft-sinnreich-sip-web-apis-01.txt Title: SIP APIs for Communications on the Web Reference: IETF Network Working Group, Internet Draft 'draft-sinnreich-sip-web-apis' Date: June 21, 2010 Data Tracker: https://datatracker.ietf.org/doc/draft-sinnreich-sip-web-apis/ Tracker Listing: http://ietfreport.isoc.org/idref/draft-sinnreich-sip-web-apis/ Tools: http://tools.ietf.org/html/draft-sinnreich-sip-web-apis-01 (HTML) Diff with version -00: http://tools.ietf.org/rfcdiff?url2=draft-sinnreich-sip-web-apis-01.txt Announced: http://www.ietf.org/mail-archive/web/i-d-announce/current/msg31551.html See also: IETF Session Initiation Protocol (SIP) Working Group http://www.ietf.org/html.charters/sip-charter.html Session Initiation Protocol Status Pages http://tools.ietf.org/wg/sip/ IETF SIP Working Group Discussion List Archives http://www.ietf.org/mail-archive/web/sip/index.html ============================================================================== SIP Core Working Group H. Sinnreich-editor Internet Draft A. Johnston/Avaya Intended status: Informational June 21, 2010 Expires: December 2010 SIP APIs for Communications on the Web draft-sinnreich-sip-web-apis-01 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 December 21, 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 in December 2010 [Page 1] Internet-Draft SIP APIs for Communications on the Web June 2010 Abstract This memo describes a standards based approach to enable web based interactive multimedia communications. The objective is giving web developers the software tools to add communication widgets to web pages. The proposed SIP API does not necessarily require SIP protocol expertise by web developers for basic multimedia communications though it can be extended to port complex VoIP services to the web. The SIP API can also support the transition from network infrastructure based VoIP to rich web based communications. The benefits of the formal REST architecture of the web are extended to real time communications. Only two standard application layer protocols are required: HTTP for signaling data communications such as in SIP and/or XMPP and UDP for real time media transport. We consider replacing SDP with metadata about media, displays and user controls. RTP data functionality can also be moved to the application itself. NAT traversal and other functions are delegated to HIP. Table of Contents 1. Introduction...................................................3 1.1. Motivation................................................3 1.2. Background................................................5 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...7 2.2.1. Rich Internet Application Development................7 2.3. Technical shortcomings of SIP 2.0 to be corrected.........7 2.3.1. SIP 2.0 telephony orientation is not helpful.........8 2.3.2. IP addresses in SIP messages.........................8 2.3.3. NAT traversal in SIP networks........................8 2.3.4. SDP is stale and complex.............................9 2.3.5. SIP 2.0 has no formal architecture such as REST......9 2.3.6. 'Extensible protocol' leads to unbounded complexity..9 2.3.7. SIP network routing protocol is missing.............10 2.3.8. No adequate IDE for SIP 2.0 software for network design and configuration..........................................10 2.3.9. Application interaction.............................10 2.3.10. Concurrency in distributed SIP networks............11 Sinnreich Expires in December 2010 [Page 2] Internet-Draft SIP APIs for Communications on the Web June 2010 2.3.11. SIP 2.0 is used only for VoIP......................11 2.3.12. SIP 2.0 has not kept up with technology............11 3. Options for Web Based Communications..........................12 4. Usage and Requirements of Communications on the Web...........13 4.1. Communications on the Web are for Internet Usage.........13 4.1.1. Applications reside in endpoints of the Internet....13 4.2. Addressing on the Internet...............................14 4.3. Applications and communications in Web feature servers...14 4.4. Sever to server communications...........................14 4.5. Porting core SIP functions to standard XML based API.....14 4.6. Gateway functions to SIP 2.0.............................15 4.7. Absorb useful SDP functions in metadata and replace SDP..15 4.8. Applications using object oriented computing.............16 4.9. Host Identity Protocol (HIP).............................16 4.10. Summary of SIP based Web communications.................17 4.11. Summary of benefits.....................................17 5. Security Considerations.......................................18 6. IANA considerations...........................................18 7. Conclusions...................................................18 8. Acknowledgements..............................................19 9. Informational References......................................19 10. Authors' Addresses...........................................21 1. Introduction 1.1. Motivation Rich Internet Applications (RIA) are based on data only and until now could not support real-time communications, since two protocols are required for interactive voice, video 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, interactive media transport is not implemented in the browser itself, but in some other endpoint application component. 2. A media channel to transport voice and video over UDP, possibly 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 the following objectives: Sinnreich Expires in December 2010 [Page 3] Internet-Draft SIP APIs for Communications on the Web June 2010 . Enabling rich multimedia communications on the web . Support of familiar tools for web developers, without requiring SIP protocol expertise . Extensibility for support of complex VoIP applications . Design for interoperability with and migration from network based VoIP. 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 as well, to the extent of the fixed or mobile device using Internet and W3C standards. Under this assumption, the terms fixed and mobile device applications can be used interchangeably. The memo proposes guidelines for APIs to enable Web application developers to build SIP-alike Web communication applications. The Web communication applications are based on the Web REST architecture [1] and using HTTP [2] transport instead of the network application layer based SIP 2.0 [3] protocol. Note the HTTP 1.1 standard (RFC 2616) also includes the option of compression. No new standards are required. Future versions of this memo may include examples of XML scripts for mapping basic Internet SIP call flows. Though the scope of this memo are SIP-like Web communications, we believe this approach can also be used for other protocols, such as XMPP for example to port existing XMPP applications to the Web. 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 network based systems. The use of RTP [4] for interactive media transport requires a mechanism for the traversal of Network Address Translators (NAT). As one alternative described below, the Host Identity Protocol (HIP) [5] implements NAT traversal, since it is also required in endpoints for Sinnreich Expires in December 2010 [Page 4] Internet-Draft SIP APIs for Communications on the Web June 2010 the IPv4-IPv6 transition, mobility and multi-homing for all types of IP applications - - in our case HTTP and UDP. References: For HTTP, RTP and HIP, instead of previous RFCs, we have provided as reference the Internet-Drafts that are aimed to 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. No references are provided for the well-known XML standards. Note that JSON is another possible alternative to XML, but since XML is already widely used by SIP and XMPP developers, we prefer XML for the SIP APIs. We expect scripting to be part the emerging HTML5 standard as well, to support interactivity in Web documents, but this topic is outside the objective of our memo. 1.2. Background Rich Internet applications (RIA) and real-time interactive applications such as voice, and games act at present as 'ships passing by night'; that is living on different application platforms, sometimes even on different IP networks and not interacting in any way. Users perceive different applications and services. Developer communities are distinct 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 organizations as the signaling protocol for Voice over IP (VoIP), as a replacement for circuit switched telephony in fixed and mobile networks. SIP is almost universally deployed for VoIP provider networks and in private IP networks. As such, SIP has proven to be a uniquely successful protocol in the telecom industry and in large part also over the Internet. Due to the universal deployment of SIP by service providers, we have been careful to chose an approach that can preserve existing SIP based services, albeit with minimal effort in the form of Web communications, should be this desired. The complexity of such services need however not be part of a standard API for Web communications, but just extensions developed whenever it makes business sense. The universal adoption of SIP 2.0 by telephony service providers has proven however to be a mixed blessing, since telephony has become the Sinnreich Expires in December 2010 [Page 5] Internet-Draft SIP APIs for Communications on the Web June 2010 only significant application for SIP. SIP 2.0 developments have been focused mainly to re-engineer traditional telephony services over IP networks. We know of no significant or transformative 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, 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 simple client-server Web model and is also making SIP 2.0 expensive for service providers. Note that in a similar fashion other network application protocols; XMPP [7], 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 our focus here on interactive communications on the Web. In this light, considering SIP and/or XMPP as opposing or matching protocols for communications is not the objective of this memo, since such protocols are very distinct from Web applications. The authors are focused here specifically on SIP, but the same approach can be used also for other network layer application protocols for the data part such as XMPP or for RTP for data about media streams. 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 learning SIP and its associated protocols developed in numerous SIP-related IETF working groups. The accumulated 100's of RFCs [10] and 1,000's of pages of Internet- Drafts migrating into even more RFCs require not only full time Sinnreich Expires in December 2010 [Page 6] Internet-Draft SIP APIs for Communications on the Web June 2010 dedication, but also specialized teams available only to larger telecom infrastructure companies. The learning effort for SIP 2.0 is economically not sustainable except for a small number of experts and precludes SIP from being used by the far more numerous 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 Web developers have proven to be very 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 such as 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 relevant ready-made data service web components or widgets are instant messaging (IM), database access, dynamic graphics, Web mashups for changing data, such as for location and for weather. 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 in the real world however do not require perfection and readers interested only in our approach to integrate RIA and communications on the Web 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 Sinnreich Expires in December 2010 [Page 7] Internet-Draft SIP APIs for Communications on the Web June 2010 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. 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 not reflect at all the evolving modern Internet and mobile communications and is a main motivation for this memo. 2.3.2. 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.3. 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 we are not aware of any published 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], for example using port 80 that is designated for HTTP. This contradicts security Sinnreich Expires in December 2010 [Page 8] Internet-Draft SIP APIs for Communications on the Web June 2010 practices in private IP networks and is not commercially advertised, though deployed in practice, since it most always works. 2.3.4. SDP is stale and complex The Session Description Protocol (SDP), the principal payload of SIP, dates from the early'90s and has been extended in about 40 RFCs. A redesign effort, called SDPng was attempted in the IETF as early as 2002. 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. Its only usefulness, negotiating session data might be better accomplished by using metadata such as the Extensible Metadata Platform (XMP)[12] and [18]. See the Requirements section below. 2.3.5. 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. This is reflected in the SIP-related mailing lists. 2.3.6. '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 standards. Extensibility for SIP must not be confused with formally defined and structured extensibility, such as in XML or in REST. Just defining 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 Sinnreich Expires in December 2010 [Page 9] Internet-Draft SIP APIs for Communications on the Web June 2010 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. 2.3.7. 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, regression testing and configuration of the whole SIP network whenever there is a change in the services or in the service policies. Actually, the deployment of back-to-back User Agents (B2BUA), aka Session Border Controllers (SBC) by telephony service providers makes routing and any architectural approach quite a challenge [13] or outright impossible since there are no standards anywhere for the behavior of SBC. The formal REST architecture will facilitate testing criteria for such and other types of intermediaries. 2.3.8. No adequate IDE for SIP 2.0 software for network design and configuration We know of no SIP integrated development environments (IDE) for SIP network software design 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.9. 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. Sinnreich Expires in December 2010 [Page 10] Internet-Draft SIP APIs for Communications on the Web June 2010 However placing SIP services in the endpoints, client and server and avoiding intermediaries enables developers to test any possible interaction locally during Web application development. 2.3.10. 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 caused by concurrency. We don't know of any commercial design tools to deal with concurrency in SIP networks. 2.3.11. 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 inhibiting SIP 2.0 as a flexible generic application platform. 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 . Bidirectional HTTP (in the IETF hybi WG) . Blogs . Wikis . Web conferencing with desktop and application sharing . Web office and enterprise applications . Social networks for the web and mobile devices Sinnreich Expires in December 2010 [Page 11] Internet-Draft SIP APIs for Communications on the Web June 2010 . Cloud computing may be especially interesting, since no specific SIP functions need to be allocated to specific servers or other network elements. Due to the focus on VoIP telephony, none of these technologies, except P2P have been applied to the benefit of SIP. Note also that the above Web applications are all data based only: Text and graphics, without voice. One cannot help notice that Web based communications and interactive voice/video 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. Using 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 may not remove some of 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, 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 real-time communications on the Web from ground up, to be just another RIA and move interoperability with legacy TDM and VoIP telephony voice networks to gateways at the IP network Sinnreich Expires in December 2010 [Page 12] Internet-Draft SIP APIs for Communications on the Web June 2010 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. An unlimited number of applications can be designed and referenced in REST fashion by unique URIs. Choosing any of the above options depends on the business model of the various VoIP providers. Given 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 interactive Internet communication as just another RIA. 4. Usage and Requirements of Communications on the Web This section contains a short overview of Internet usage, generic requirements and how they can be accomplished. 4.1. Communications on the Web are 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 real-time interactive communications on the Web to mirror the other new or emerging communication scenarios, such as web conferencing or communications over social networks. 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 intermediary 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. Note the business logic for applications may reside in part also on servers, but frequent interaction between the client and servers will Sinnreich Expires in December 2010 [Page 13] Internet-Draft SIP APIs for Communications on the Web June 2010 degrade the user experience and make the system more brittle. Complex business logic in the server is also an obstacle to contributions by innovative independent application developers. 4.2. Addressing on the Internet Web style addressing, HTTP URLs are used throughout, instead of phone numbers. User URIs look like email addresses. Web feature servers that support real-time communications are addressed by URLs. Discovery of and translation of phone numbers to these addresses, if and when required, can be accomplished in PSTN gateways that may use standard DNS lookups and ENUM methodology. 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 servers, such as in Web feature servers or in distributed P2P overlay networks. 4.4. Sever to server communications The core SIP communication model in RFC 3261 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 service providers may provide assistance, if so desired and when invoked by the user. 4.5. Porting core SIP functions to standard 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 or extensions? 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 [25] scripts that replicate the SIP 2.0 messages in Sinnreich Expires in December 2010 [Page 14] Internet-Draft SIP APIs for Communications on the Web June 2010 basic call flows. The resulting SIP XML scripts will be available under a registered XML name space. All Web development tools can work with XML documents and as mentioned there is support for XML scripts in the emerging HTML5 standard. Emulating existing complex SIP network applications as XML scripts can also be done with this approach, though it requires in-depth SIP expertise that Web application developers don't have. We believe most useful application scenarios for Web communications can be implemented with the basic SIP call models as described in RFC 5638 [21] for 'simple SIP'. Only the basic SIP calls must be included in the Internet SIP API best practice. An unlimited number of unique URIs however can identify more complex call flows. This is a key distinction to support the Internet simplicity argument. 4.6. Gateway functions to SIP 2.0 The mapping of SIP 2.0 request-response messages to XML scripts represent a trivial way for building gateway functions that can reside either in RIA user agents (UA) or in Web feature servers. XML scripts can be built using existing, well-deployed SIP call flows [16]. This is incidentally also a more appropriate 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 the core SIP API for a RIA interoperability best practice. 4.7. Absorb useful SDP functions in metadata and replace SDP SIP 2.0 uses the rather stale Session Description Protocol (SDP) developed in the early '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 (is not UNSAF compliant as mentioned); since screen size, multiple screens, 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. Note the metadata Sinnreich Expires in December 2010 [Page 15] Internet-Draft SIP APIs for Communications on the Web June 2010 description must be standards compliant, but different endpoint applications can use it in different ways. Implementation examples are such as in the Open Screen Project [17] and using the proposed Extensible Metadata Platform (MXP) [18]. In gateways, metadata for session negotiation will be used only for Web communications, while keeping the SDP session negotiation 'as is' for SIP 2.0. This suggests the porting of SDP AVT codec profiles to metadata into the application itself. 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 compilers can better insure the high quality code that is a pre-requisite for highly secure applications. 4.9. Host Identity Protocol (HIP) A complete solution for Web communications requires NAT traversal as well. Designers may use STUN/TURN/ICE utilities developed for SIP networks though other options are available as well. HIP is such an option for NAT traversal for UDP packets of interactive media. It is actually our favored option. Another option for UDP or RTP/UDP media packets 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 endpoint in the network. This has been a perennial problem for IP networks and has been solved for endpoints by HIP that separates the network address from the host identity. HIP can support the following features: o Enhanced, VPN-like security o The transition from IPv4 to IPv6 o Mobility o Multi-homing Sinnreich Expires in December 2010 [Page 16] Internet-Draft SIP APIs for Communications on the Web June 2010 o NAT traversal for all network 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 similar utilities to STUN/TURN/ICE that are also used in SIP, though optimized for HIP. 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: email style addressing for users and URLs for Web feature servers. 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 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 [24] o The gateway function to SIP 2.0 networks can reside either in Web feature servers or in the UA itself. 4.11. Summary of benefits The benefits of making interactive communications such as VoIP another component of RIA can be summarized here: o Access to VoIP apps by Web users and by device application developers o VoIP becomes a RIA component Sinnreich Expires in December 2010 [Page 17] Internet-Draft SIP APIs for Communications on the Web June 2010 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 communication security: o Architecture: The security of Web communications are considerably enhanced by the use of the formal REST architecture [22] o Data transport: HTTP 1.1 [20] security is ported to communication signaling security o Media transport: UDP over HIP security enhancement applies, see below 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 foundation for development. 6. IANA considerations This memo has no IANA considerations. No new protocols, extensions or registrars are required. 7. Conclusions Interactive communications such as voice and games are becoming a part of rich Internet applications. This can be accomplished entirely 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 Sinnreich Expires in December 2010 [Page 18] Internet-Draft SIP APIs for Communications on the Web June 2010 o Enable Web application developers to integrate VoIP into Web applications o Give Internet 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, video and other applications. 8. Acknowledgements This second version (01) of the memo has significantly benefited from discussions on the list and in private by Bernard Aboba, Victor Avila, Wolfgang Beck, John Elwell, Adrian Georgescu, Paul Jones, Paul Kyzivat, Peter Musgrave, Henning Schulzrinne, Tom Taylor, Wilhelm Wimmreuter and others. Especially Robert Sparks opened our eyes to the potential of hiding SIP complexity by an adequate API. The authors are indebted to Cullen Jennings and Kundan Singh for a critical review of the initial version 00 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 for helpful discussions that eventually led to the first version of the 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] ''HTTP1.1bis, parts 1-7, Internet-Draft, IETF 2010, work in progress. [3] RFC 3261: ''SIP: Session Initiation Protocol'' by J. Rosenberg et al. IETF, June 2002. Sinnreich Expires in December 2010 [Page 19] Internet-Draft SIP APIs for Communications on the Web June 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 2010, 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 2010, 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] RFC 5853 ''Requirements from SIP Session Border Control Deployments'' by J. Hautakorpi et al., IETF, April 2010. [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 [20] HTTP/1.1, part 7: Authentication by R. Fielding et al. Sinnreich Expires in December 2010 [Page 20] Internet-Draft SIP APIs for Communications on the Web June 2010 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/ [24] Native NAT Traversal Mode for the Host Identity Protocol by A. Keranen and J. Melen. Internet-Draft, I-D: draft-keranen-hip-native- nat-traversal, IETF 2010, work in progress. [25] RFC 3470: ''Guidelines for the Use of Extensible Markup Language (XML) within IETF Protocols'' by S. Hollenbecket al. IETF, January 2003. 10. Authors' Addresses Henry Sinnreich - editor Unaffiliated Email: henry.sinnreich@gmail.com Alan Johnston Avaya Email: alan.b.johnston@gmail.com Sinnreich Expires in December 2010 [Page 21]