Subject: Re: [dispatch] [RTW] Does RTC-WEB need to pick a signaling protocol?

From: Bernard Aboba <[email-masked]>
Date: Sun, 30 Jan 2011 01:00:40 -0800

WARNING: contains banned part

Subject: RE: [RTW] Does RTC-WEB need to pick a signaling protocol?
From: Bernard Aboba <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Date: Sun, 30 Jan 2011 01:00:40 -0800

Just to provide some context for those who may have only recently been
exposed to the realtime web. 

The realtime web is not new -- it has been in operation for more than a
decade, as embodied in commercial services such as Adobe Connect, WebEx,
Live Meeting, etc. which serve millions of users on a daily basis.  The
realtime web is supported on virtually every major browser and web server
platform.  Javascript libraries for signalling are not a "future
development" -- they have been around for a while. 

All that is really new here is the ability to engineer these services
without plugins.  That's important because it will make realtime web
services considerably easier to develop and maintain.  However, the "major
event" occurred during the early 2000s. 

  _____  

Date: Sun, 30 Jan 2011 00:02:59 -0800
From: [email-masked]
To: [email-masked]
CC: [email-masked]; [email-masked]
Subject: Re: [RTW] Does RTC-WEB need to pick a signaling protocol?

I understand the argument and agree that pure http might be the right course
at some point in the future but the fact remains, SIP rules in
communications "today", it will do so for years to come. It might be wise
for us to move forward on a standard that is understood and appreciated by
not only the developer community but also the business community paying the
bills.

Yes, we can build anew atop http, all it takes is time and money. 

An http effort will take a while, I think we all know that. How long did it
take for SIP to displace H.323? I think the unanimous answer is "too long".

We have a standard that exists today, one that we are all very familiar
with, one that works! It would seem a shame not to leverage all we (and our
employers) have invested, which is considerable.

This is a major event in communications, we need to consider this carefully
but we also owe it to "standards" to do it quickly, which has not been the
norm it seems.

Erik Lagerway | hookflash | m. 604.562.8647

On Sat, Jan 29, 2011 at 6:35 AM, Jonathan Rosenberg <[email-masked]>
wrote:

I'm starting a separate thread on this, since I don't want to confound it
with the charter discussion. This is a topic that should be resolved within
the group itself, and here are my thoughts on it.

If one asks the question on whether it is actually NECESSARY to require that
a browser implement something like SIP in order to enable voip natively, the
answer is definitively NO. The browser already provides a tool for
exchanging messaging of arbitrary content between the browser and a server -
its called HTTP (and websockets). Through client-side Javascript that comes
from the server, an application can craft arbitrary protocol messaging of
its own design between the client and the server. As an obvious example, in
order to read mail on Gmail, the browser doesn't need to have an
implementation of IMAP or POP; Gmail's Javascript implements the client side
of a protocol of Google's design, and it talks to a web server which
implements the server side of that protocol. The protocol is then then
carried over HTTP.

As such, if we take our charter here to define only what is truly REQUIRED
of a browser, in order to enable voip without a plugin, then we do NOT need
to pick a signaling protocol. All we need are the things which are truly
impossible or grossly unsuitable for HTTP, and that is the real-time media
path only. There need only be APIs for pushing in, and extracting out, the
data that must be exchanged through HTTP-based signaling - and those are
things like IP addresses and codec selections.

That said, even if one asks the question of whether it is a good idea for us
to pick something, I think the answer is no. The enormous benefit of the web
model is its ability for innovation and velocity. Standardization is not
needed for communications within the domain of the provider; new features
can be developed and deployed as quickly as they can be conceived. This is
something which, despite our best efforts here at IETF over the years, we
have failed to achieve. I think it is critical that we allow web-based voip
to innovate with the same kind of pace we've seen in the web overall.

One of the arguments made on the list about why we should pick something, is
that building their own signaling protocols and messaging is "hard" for a
tiny web developer that just wants to add a bit of voice to their app. In
such a case, I fully expect that within weeks or months of specification and
implementation of RTC-WEB stuff in browsers, smart people will develop
Javascript libraries which do all of this "hard work", along with PHP and
many other server-side libraries with sit on the other side. None of it
requires standardization, and we can let the open source community and the
marketplace innovate on whatever solutions are needed.

Thanks,
Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                   SkypeID: jdrosen
Chief Technology Strategist                    Mobile: +1 (732) 766-2496
Skype                                          SkypeIn: +1 (408) 465-0361
[email-masked]                              http://www.skype.com
[email-masked]                            http://www.jdrosen.net

_______________________________________________
RTC-Web mailing list
[email-masked]
http://www.alvestrand.no/mailman/listinfo/rtc-web

_______________________________________________ RTC-Web mailing list
[email-masked] http://www.alvestrand.no/mailman/listinfo/rtc-web

---

From: Henry Sinnreich <[email-masked]>
Date: Sun, 30 Jan 2011 11:34:16 -0600

If XMPP evangelists can commit not make any more pitches for XMPP, maybe the
evangelists for SIP (count me in) could reciprocate :-)
So, suppose we move on, especially, since application level scripts for both
basic SIP and basic XMPP can be written and published as OS by those who
really want to.

And here we are getting to the key point IMO that both Jonathan and I have
mentioned: Leave the field open to innovation.
While SIP has been focused on telephony, XMPP has been focused on chat rooms
and both, while successful have missed the major innovations on the Web that
have happened since, mostly without any new standards:
* REST 
* P2P RT A/V/IM 
* Web mail 
* Wikis and blogs 
* Social networks 
* Web conferencing 
* Web office apps and enterprise apps
* Cloud services 
* Streaming HTTP and CDNs, etc, etc.

Note that except for P2P RT A/V/IM, mostly basic/core HTTP and HTML
standards were used.
>From this perspective, it is enough to let SIP and XMPP folks publish their
application level scripts and support some mechanism for endpoints to use
either or both if so desired.
The key however is not to shackle innovators with either SIP or XMPP or both
(the worst outcome) as mandatory.

Actually, as mentioned here, is not the W3C supposed to specify the API for
RT-Web? 

Thanks, Henry