Subject: Re: [dispatch] I-D ACTION:draft-sinnreich-sip-web-apis-00.txt

From: "Bernard Aboba" <[email-masked]>
Date: Wed, 3 Feb 2010 12:55:56 -0800

There is considerable work already underway to address some of the issues
raised in this draft.  For example:

1. Work in W3C HTML5 WGs to add native support for audio and video. 
2. Work in IETF "HyBi" WG to make HTTP more suitable for realtime signaling
3. Work in XSF to provide enhanced telephony support within XMPP (e.g.
Jingle ICE, Jingle Transfer, etc.)
4. Work in IETF XMPP WG to revise RFC 3920/3921, address SIP/XMPP interop,
etc. 

Given this, my reading of the document raised several questions:

1.  What problems exist with existing XML over HTTP approaches to signaling
(e.g. XMPP over HTTP w/Jingle)? 
2. What additional work beyond what is already under discussion is necessary
to complete the vision you describe? 

==========================================================
Henry said:

"We have published an I-D on "SIP APIs for Web Communications" and would
appreciate any comments and input.

Here is the link and the announcement:

http://www.ietf.org/internet-drafts/draft-sinnreich-sip-web-apis-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

 Title  : SIP APIs for Communications on the Web
 Author(s) : H. Sinnreich, A. Johnston
 Filename : draft-sinnreich-sip-web-apis-00.txt
 Pages  : 19
 Date  : 2010-1-19
 
   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.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-sinnreich-sip-web-apis-00.txt"

---

From: Henry Sinnreich <[email-masked]>
Date: Wed, 03 Feb 2010 20:02:52 -0600

Hi Bernard,

Thanks for drilling down on some of the issues.

> 2. Work in IETF "HyBi" WG to make HTTP more suitable for realtime signaling

Both confirm we believe our approach, though no SIP-specific functionality
for rendezvous and session initiation  is envisaged, as is the focus in our
I-D. Even less on how to port the very rich SIP voice functionality to
HTML/HTTP.

Such items as support for the SPEEX codec (in the example) in
http://dev.w3.org/html5/spec/Overview.html and for bidirectional HTTP (as
mentioned in our I-D), at http://trac.tools.ietf.org/bof/trac/wiki/HyBi are
really heartening.

> (e.g. XMPP over HTTP w/Jingle)?

No problems at all with XMPP, except sharing the same problem with SIP,
SIMPLE and all the proprietary IM protocols that are dominant in the IM
market (no names mentioned here): Too complex for generalists Web
application developers to afford the time and resources to learn and to use.

Though it would be useful to have similar APIs developed in the IM industry
ported to Web communications as well.

There is no reason not to replace them all with HTTP transport and APIs for
the client and/or server applications.
Section 1.2 Background in our I-D says:
"  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."
(for data only as mentioned elsewhere, and having RTP/UPD as a possible
companion protocol for real-time interactive media).

> to complete the vision you describe?

The biggest work item IMO is replacing the stale and problematic SDP with
metadata as detailed in section 2.3.3 and thus also fixing the
non-compliance of SIP with "UNSAF" RFC 3424. Our I-D deals only with SIP at
this point. Replacing SDP and its consequences for NAT traversal requires
indeed some work, possibly not in scope here.

Much more than SDP codec negotiation (and providing misleading transport
addresses) is required to support adequate user experience, depending on
device capabilities, no matter what screen size, keyboard, mouse, touch
screen, remote control, etc. All this can be far better accomplished using
metadata, as in RFC 5013.

Thanks again for focusing on these issues.

Henry 

On 2/3/10 2:55 PM, "Bernard Aboba" <[email-masked]> wrote:

> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch

---

From: "Bernard Aboba" <[email-masked]>
Date: Wed, 3 Feb 2010 18:52:32 -0800

In response to
(http://www.ietf.org/mail-archive/web/dispatch/current/msg01291.html )

Henry Sinnreich said:

"No problems at all with XMPP, except sharing the same problem with SIP,
SIMPLE and all the proprietary IM protocols that are dominant in the IM
market (no names mentioned here): Too complex for generalists Web
application developers to afford the time and resources to learn and to
use."

[BA] Despite all the extensions (see http://xmpp.org/extensions/ ), XMPP as
described in RFC 3920bis and 3921bis is not a complex protocol, nor
is it difficult to incorporate XMPP into applications.  

Have you seen the XMPP SDKs that are available?  Some of them (like
SleekXMPP) are incredibly powerful and easy to use.  Chapter 14 of the
O'Reilly book "XMPP: The Definitive Guide" by Peter St. Andre provides an
example
"micro-blogging" application written using SleekXMPP that requires very
little Python code, and is easy to understand even if you don't know
much Python. 

Now that XMPP is a supported platform within the Google cloud platform,
I expect that the situation will only get better.  

Henry said:

"There is no reason not to replace them all with HTTP transport and APIs for
the client and/or server applications."

[BA] Since there are XMPP SDKs available for PHP, Python and any other 
web development environment you might desire, using XMPP over HTTP should
not require much beyond support for BOSH:
http://xmpp.org/extensions/xep-0124.html
http://xmpp.org/extensions/xep-0206.html

Henry said:

"The biggest work item IMO is replacing the stale and problematic SDP with
metadata as detailed in section 2.3.3 and thus also fixing the
non-compliance of SIP with "UNSAF" RFC 3424. Our I-D deals only with SIP at
this point. Replacing SDP and its consequences for NAT traversal requires
indeed some work, possibly not in scope here."

[BA] I'd be interested in your take on the XMPP session description and
codec functionality:

http://xmpp.org/extensions/xep-0167.html
http://xmpp.org/extensions/xep-0266.html
http://xmpp.org/extensions/xep-0181.html
http://xmpp.org/extensions/xep-0176.html

---

From: <[email-masked]>
Date: Thu, 4 Feb 2010 15:56:47 +0100

> 2.1. SIP 2.0 is too expensive for Web application developers
The big question is whether SIP is to blame for this complexity or if it's in the nature of telephony. Web standards are as complex as SIP. Only very few web browsers pass the acid3 test. XML is not the most elegant technology either.

There must be a different reason why so many develop for the web and so few for voice. With Flash, it is already possible to do SIP-like voice/video connections between users. It's rarely used, though. When eBay bought Skype, everybody expected exciting mash-ups. Nothing happened. 

> 4.1.1. Applications reside in endpoints of the Internet
Kind of. The success of Web 2.0 was the success of Javascript; applications run on the endpoint, but are maintained on the server. The user has no choice which javascript applet to use when accessing a web 2.0 site. The site owner can update the applet without having to ask the browser owner for approval.

Wolfgang Beck

Deutsche Telekom Netzproduktion GmbH
Zentrum Technik Einführung
Wolfgang Beck
Heinrich-Hertz-Straße 3-7, 64295 Darmstadt
+49 6151 628 2832 (Tel.)
http://www.telekom.com  

Erleben, was verbindet. 

Deutsche Telekom Netzproduktion GmbH
Aufsichtsrat: Dr. Steffen Roehn (Vorsitzender)
Geschäftsführung: Dr. Bruno Jacobfeuerborn (Vorsitzender), Albert Matheis, Klaus Peren
Handelsregister: Amtsgericht Bonn HRB 14190
Sitz der Gesellschaft: Bonn
USt-IdNr. DE 814645262

---

From: Henry Sinnreich <[email-masked]>
Date: Thu, 04 Feb 2010 09:31:57 -0600

Thanks Wolfgang for raising these interesting issues.

> The big question is whether SIP is to blame for this complexity or if it's in
> the nature of telephony.
My vote goes it's in the nature of traditional telephony. It is arguable how
much traditional telephony is of interest today for new investments however,
given especially for younger users accustomed to Web applications and to
Skype.
Web communications may also lead to much better enabled "call centers".

>Web standards are as complex as SIP.
Very true, but APIs and IDEs completely hide that complexity.
Whatever the reasons (such as market size for developers), there are
zillions of Web applications, and only one major app for SIP: Re-engineering
traditional telephony over IP.

> XML is not the most elegant technology either.
Beauty is in the eye of the beholder :-)
We could think only of XML as a platform independent standard for APIs.
XML is also fully supported in IDE we happen to know, such as Eclipse and
Flash that you also mention. Let us know if have any alternative(s) to XML.

Thanks again,

Henry

On 2/4/10 8:56 AM, "[email-masked]" <[email-masked]> wrote:

> The big question is whether SIP is to blame for this complexity or if it's in
> the nature of telephony. Web standards are as complex as SIP. Only very few
> web browsers pass the acid3 test. XML is not the most elegant technology
> either.
> 
> There must be a different reason why so many develop for the web and so few
> for voice. With Flash, it is already possible to do SIP-like voice/video
> connections between users. It's rarely used, though. When eBay bought Skype,
> everybody expected exciting mash-ups. Nothing happened.
> 
> Kind of. The success of Web 2.0 was the success of Javascript; applications
> run on the endpoint, but are maintained on the server. The user has no choice
> which javascript applet to use when accessing a web 2.0 site. The site owner
> can update the applet without having to ask the browser owner for approval.
> 
> 
> Wolfgang Beck
> 
>

---

From: Henry Sinnreich <[email-masked]>
Date: Thu, 04 Feb 2010 09:56:02 -0600

There is no disagreement here about the merits of XMPP, however this I-D is
focused on SIP APIs and the expertise of the present authors is mainly in
SIP. 

It would be useful to have similar XMPP APIs for Web communications, as well
as APIs from the other dominant IM protocols.

Application developers would thus have a larger choice, depending on the
usage scenario.

> codec functionality
No disagreement here either, though the I-D argues for using metadata
instead of SDP, that goes way beyond codec negotiation. In such applications
as Web conferencing with screen sharing, telepresence for business and the
digital living room, much more platform-specific data needs to be considered
in the application than just codecs.

Screen sharing example: One, two or more screens in an IT customer support
scenario on both ends, with different screen resolutions. Without metadata
the parties will not see the same desired screens.

Thanks again for the good probing questions,

Henry

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 4 Feb 2010 14:29:26 -0500

I think for most of us, voice human-to-human, real-time communication is just a smaller part of the communication universe. The average cell phone user talks for 459 minutes a month (claims http://wiki.answers.com/Q/How_many_minutes_does_the_average_cell_phone_customer_use_per_month), i.e., 15 minutes a day. Most of us spend far more time on other Internet applications. Except for tele marketers and other voice-dependent professions, most of our needs so far tend to be fairly straightforward: reach a person (rather than a device) reliably and cheaply, preferably without disturbing the person accidentally.

Henning