Subject: [dispatch] SIP APIs for Communications on the Web

From: Henry Sinnreich <[email-masked]>
Date: Tue, 22 Jun 2010 10:29:56 -0500

Following the discussions on the Dispatch list in February and also in
private, we have posted a new version of the I-D:

http://www.ietf.org/id/draft-sinnreich-sip-web-apis-01.txt

The clarifications include such topics as (in no particular order)
* SIP and/or (vs.) XMPP/Jingle
* HTML5 support for application scripts
* Bidirectional HTTP, IETF "HyBi" WG
* Hiding SIP complexity under the right, standards based API
* Drawing the line between basic usage scenarios for a simple API and yet
how to support complex VoIP call flows
* The SIP state machine moves to the business logic in UA and Web feature
servers; which is preferable
* The traffic and time spent with web applications far surpasses the time to
talk on the phone (exceptions)
* Added references for metadata standards to replace SDP
* SDPng was already proposed in the early Œ90s
* Keep only UDP for media transport, RTP data about the media is moved to
the application as well
* New reference for HIP specific NAT traversal utilities.

Please let us know how you feel these and other issues have been addressed.

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.

Thanks,
Henry