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

[Erik Lagerway]

Agreed.

*Erik Lagerway | hookflash | m. 604.562.8647 | www.hookflash.com*


On Mon, Jan 31, 2011 at 1:04 PM, Henry Sinnreich
<henry.sinnreich at gmail.com>wrote:

>  >Hmm, not convinced that SIP via JS or remote would perform adequately
> but certainly agree that we need to get on with it.
>
> Could not agree with you more Erik on the need for SIP signaling
> compatibility, was just trying to avoid the “Flash” word :-)
> Which I believe would work not just fine, but also be the best of the
> breed.
> I hope we don’t discuss this here any more however since this list is about
> de jure standards.
>
> The main issue is to avoid the Chronos effect by constraining the API
> standard with the 1990s limitations of SIP and XMPP.
> And also avoid the rat hole of discussing SIP vs. XMPP.
>
> Henry
>
>
>
> On 1/31/11 12:32 PM, "Erik Lagerway" <erik at hookflash.com> wrote:
>
> Hmm, not convinced that SIP via JS or remote would perform adequately but
> certainly agree that we need to get on with it.
>
> -Erik
>
>
> On Mon, Jan 31, 2011 at 8:34 AM, Henry Sinnreich <
> henry.sinnreich at gmail.com> wrote:
>
> +1
>
> > The SIP implementation can live
> > in the JavaScript, up in the web server, in a separate gateway, or any
> > combination thereof.
>
> Or even in a browser add-in, perish the thought :-)
>
> The main point here is to avoid the Chronos effect from SIP and XMPP
> (has to do with avoiding competition from the children by eating them, as
> described in the book "The Master Switch" by Tim Wu).
>
> Thanks, Henry
>
>
> On 1/31/11 10:12 AM, "Matthew Kaufman" <matthew.kaufman at skype.net> wrote:
>
> > On 1/29/2011 6:35 AM, Jonathan Rosenberg wrote:
> >>
> >> 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.
> >
> > Agreed. Consider the case of Gmail (or any other web-based email)
> >
> > Did every web browser on the planet need to be upgraded to speak IMAP or
> > SMTP in order for Gmail to be implemented? No.
> >
> > Does the JavaScript that Gmail sends down to your browser in order to
> > implement its UI need to be standardized among web email platforms? No.
> >
> > Does Google need to use the same JavaScript libraries and PHP back-end
> > that SquirrelMail uses in order to implement a web email application? No.
> >
> > Can Google change that JavaScript tomorrow without breaking
> > interoperability? Yes, and they probably will.
> >
> > But could Gmail be as successful without the worldwide SMTP
> > infrastructure it ties in to? Probably not.
> >
> > I see the same situation here. A web browser with real-time
> > communication capabilities will work in conjunction with a web site that
> > serves up the HTML and JavaScript that makes up the calling application.
> > For some applications, this will be sufficient. For others, one will
> > want to implement SIP or XMPP/Jingle or something else in order to
> > gateway these calls to other networks. The SIP implementation can live
> > in the JavaScript, up in the web server, in a separate gateway, or any
> > combination thereof.
> >
> > Matthew Kaufman
> > _______________________________________________
> > dispatch mailing list
> > dispatch at ietf.org
> > https://www.ietf.org/mailman/listinfo/dispatch
>
>
> _______________________________________________
> RTC-Web mailing list
> RTC-Web at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/rtc-web
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.alvestrand.no/pipermail/rtc-web/attachments/20110131/7bd92340/attachment.html>