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

[Peter Musgrave]

+1

Peter Musgrave

On 2011-01-31, at 10:20 PM, Erik Lagerway wrote:

> 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
> 
> 
> 
> _______________________________________________
> dispatch mailing list
> dispatch at ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch

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