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

[Slava Borilin]

+1

Slava borilin,
Spirit

----- Reply message -----
От: "Jonathan Rosenberg" <jdrosen at jdrosen.net>
Дата: сб, янв 29, 2011 17:36
Тема: [dispatch] Does RTC-WEB need to pick a signaling protocol?
Кому: "'DISPATCH list'" <dispatch at ietf.org>, "rtc-web at alvestrand.no" <rtc-web at alvestrand.no>

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
jdrosen at skype.net                              http://www.skype.com
jdrosen at jdrosen.net                            http://www.jdrosen.net


_______________________________________________
dispatch mailing list
dispatch at ietf.org
https://www.ietf.org/mailman/listinfo/dispatch