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

[Bernard Aboba]

One approach is to tunnel the signaling protocol over HTTP.   This requires
support for bi-directional communications, such as can be provided by BOSH,
or Websockets.   In these architectures the web client communicates via HTTP
with a "Connection Manager"  which  encapsulates/decapsulates the signaling
messages and routes them appropriately on the backend. 

 

To provide interoperability, specifications for encapsulation of signaling
messages within HTTP are required.  Examples include:

 

XEP-0124 <http://xmpp.org/extensions/xep-0124.html> : Bidirectional-streams
Over Synchronous HTTP (BOSH)

XEP-0206 <http://xmpp.org/extensions/xep-0206.html> :  XMPP over BOSH

An XMPP Sub-protocol for Websocket
<http://tools.ietf.org/html/draft-moffitt-xmpp-over-websocket> 

 

Information on BOSH implementations can be found here:

http://xmpp.org/about-xmpp/technology-overview/bosh/#impl

 

From: rtc-web-bounces at alvestrand.no [mailto:rtc-web-bounces at alvestrand.no]
On Behalf Of Markus.Isomaki at nokia.com
Sent: Sunday, January 30, 2011 2:45 PM
To: bernard_aboba at hotmail.com; richard at shockey.us; erik at hookflash.com;
jonathan.rosenberg at skype.net
Cc: rtc-web at alvestrand.no; dispatch at ietf.org
Subject: Re: [RTW] [dispatch] Does RTC-WEB need to pick a signaling
protocol?

 

Hi,

 

I pretty much agree with what Bernard and Johathan Rosenberg have said.

 

There are just a couple of issues I would like to understand better:

-          I suppose these Javascript libraries can be cached on the browser
and need not be downloaded every time the application/site is accessed?
(These are probably a common practices in Javascript and Browsers but are
good to clarify in this discussion.)

-          It may be easy for a web developer to use the client side
Javascript library, but I believe the challenge may be bigger on the server
side, where scalability etc. become issues. How about the server side, is
there something ready-made for that? I suppose the Javascript on the browser
can't necessarily connect to vanilla SIP or XMPP servers but some
HTTP/WebSocket/TLS tunneling and connection management magic is needed,
especially when dealing with HTTP intermediaries. (But presumably the same
issues would be faced if we "picked" SIP or XMPP.)

 

Markus

 

 

From: rtc-web-bounces at alvestrand.no [mailto:rtc-web-bounces at alvestrand.no]
On Behalf Of ext Bernard Aboba
Sent: 30 January, 2011 07:35
To: Richard Shockey; erik at hookflash.com; jonathan.rosenberg at skype.net
Cc: rtc-web at alvestrand.no; dispatch at ietf.org
Subject: Re: [RTW] [dispatch] Does RTC-WEB need to pick a signaling
protocol?

 

> Duh ... what are we abandoning 10 years of work?

The web is a "generative" platform that supports not just protocols, but
also execution of code.   This enables the platform to be extended in a
virtually infinite number of ways, including the development of Javascript
signaling APIs, without needing to add yet more core code to the browser.
This is the preferred approach unless it can be shown that something
*absolutely* must be natively supported (as was discussed at the workshop,
STUN/TURN authorization for peer-to-peer media is probably an example of
something that *does* need to be native). 

As an example of what is possible, there is an excellent Javascript library
for XMPP (strophe, see http://code.stanziq.com/strophe/).   Poking around,
it would appear that there are a number of Javascript libraries that claim
to provide support for SIP (such as http://phono.com/), although I have no
idea of their usefulness. 

Given the generality and power of the web platform and the ease with which
sophisticated signaling libraries can be implemented today, the bar for
getting additional code into any browser is going to be quite high.  If you
doubt this,  ask the build-master of your favorite browser for the
requirements for checkin of a complete SIP stack :) 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.alvestrand.no/pipermail/rtc-web/attachments/20110130/b4901ef5/attachment.html>