One document matched: draft-sinnreich-sip-web-apis-01.txt
Differences from draft-sinnreich-sip-web-apis-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-24 03:00:27 |