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

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 29 Jan 2011 09:35:52 -0500

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

---

From: Adam Roach <[email-masked]>
Date: Sat, 29 Jan 2011 09:38:48 -0600

On 1/29/11 8:35 AM, Jonathan Rosenberg wrote:
> it with the charter discussion. This is a topic that should be 
> resolved within the group itself

I have a number of thoughts on this topic also, but I don't think this 
(DISPATCH) is the forum for them. I'd like for these conversations to 
take place, though, so I want it to be clear in the charter that we 
aren't precluded from choosing one path over the other.

Is it fair to characterize your statement that "this is a topic that 
should be resolved within the group itself" to support leaving the 
charter open enough to support any consensus conclusion that discussion 
may reach?

/a

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 29 Jan 2011 11:21:29 -0500

Absolutely. I agree this debate should be resolved in the group, and the
charter should specify that this question (whether or not we need to
specify a protocol, and then if so, what it is) is in scope. I send some
proposed text for charter wording along these lines.

Of course, that doesn't mean we cannot start the debate early. And 
indeed, since we have, I chimed in ;)

-Jonathan R.

---

From: Erik Lagerway <[email-masked]>
Date: Sat, 29 Jan 2011 09:34:57 -0800

SIP, for various reasons, is the right choice IMO.

My 2 bits outside of dispatch:
http://www.alvestrand.no/pipermail/rtc-web/2011-January/000312.html

On 2011-01-29, at 8:18 AM, "Rosenberg, Jonathan" <[email-masked]
 > wrote:

> -----Original Message-----
> From: [email-masked] [mailto:rtc-web-
> [email-masked]]
> On Behalf Of Adam Roach
> Sent: Saturday, January 29, 2011 10:39 AM
> To: Jonathan Rosenberg
> Cc: [email-masked]; 'DISPATCH list'
> Subject: Re: [RTW] [dispatch] Does RTC-WEB need to pick a signaling
> protocol?
>
> _______________________________________________
> 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: "Rosenberg, Jonathan" <[email-masked]>
Date: Sat, 29 Jan 2011 17:18:00 +0100 (CET)

Of course, that doesn't mean we cannot start the debate early. And indeed,
since we have, I chimed in ;)

-Jonathan R.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Adam Roach
Sent: Saturday, January 29, 2011 10:39 AM
To: Jonathan Rosenberg
Cc: [email-masked]; 'DISPATCH list'
Subject: Re: [RTW] [dispatch] Does RTC-WEB need to pick a signaling
protocol?

/a

---

From: "Richard Shockey" <[email-masked]>
Date: Sat, 29 Jan 2011 21:04:40 -0500

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

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Erik Lagerway
Sent: Saturday, January 29, 2011 12:35 PM
To: Rosenberg, Jonathan
Cc: [email-masked]; DISPATCH list
Subject: Re: [dispatch] [RTW] Does RTC-WEB need to pick a signaling
protocol?

On 2011-01-29, at 8:18 AM, "Rosenberg, Jonathan"
<[email-masked]

_______________________________________________
dispatch mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dispatch

---

From: Bernard Aboba <[email-masked]>
Date: Sat, 29 Jan 2011 21:35:12 -0800

> 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 :)

---

From: Erik Lagerway <[email-masked]>
Date: Sat, 29 Jan 2011 22:59:19 -0800

I understand your position Jonathan and agree that it 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. I think they, as will everyone  
else that owns a SIP endpoint, will appreciate that sentiment.

Yes, we can build anew atop http, all it takes is time and money,  
money is running in shirt supply. It would be nice if we could get it  
working for those who spent hard earned dollars on SIP, sooner rather  
than later.

An http effort will take a while, we have a standard, one that you are  
very familiar with, let's use that.

-Erik

On 2011-01-29, 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.
>
> 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.
>
> 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.
> --

---

From: Erik Lagerway <[email-masked]>
Date: Sun, 30 Jan 2011 00:02:59 -0800

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.
>
> 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.
> --

---

From: <[email-masked]>
Date: Sun, 30 Jan 2011 22:45:04 +0000

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: [email-masked] [mailto:[email-masked]] On Behalf Of ext Bernard Aboba
Sent: 30 January, 2011 07:35
To: Richard Shockey; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [RTW] [dispatch] Does RTC-WEB need to pick a signaling protocol?

---

From: Bernard Aboba <[email-masked]>
Date: Sun, 30 Jan 2011 22:50:10 -0800

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: [email-masked] [mailto:[email-masked]]
On Behalf Of [email-masked]
Sent: Sunday, January 30, 2011 2:45 PM
To: [email-masked]; [email-masked]; [email-masked];
[email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [RTW] [dispatch] Does RTC-WEB need to pick a signaling
protocol?

Hi,

-          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

On Behalf Of ext Bernard Aboba

> 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 :)

---

From: Matthew Kaufman <[email-masked]>
Date: Mon, 31 Jan 2011 08:12:25 -0800

On 1/29/2011 6:35 AM, Jonathan Rosenberg wrote:
> 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. 
> 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

---

From: Henry Sinnreich <[email-masked]>
Date: Mon, 31 Jan 2011 10:34:31 -0600

+1

> The SIP implementation can live

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

---

From: Erik Lagerway <[email-masked]>
Date: Mon, 31 Jan 2011 10:32:08 -0800

Hmm, not convinced that SIP via JS or remote would perform adequately but
certainly agree that we need to get on with it.

-Erik

---

From: Henry Sinnreich <[email-masked]>
Date: Mon, 31 Jan 2011 15:04:44 -0600

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" <[email-masked]> wrote:

> On Mon, Jan 31, 2011 at 8:34 AM, Henry Sinnreich <[email-masked]>
> wrote:
>> +1
>>

---

From: Erik Lagerway <[email-masked]>
Date: Mon, 31 Jan 2011 13:20:44 -0800

Agreed.

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

On Mon, Jan 31, 2011 at 1:04 PM, Henry Sinnreich
<[email-masked]>wrote:

>  >Hmm, not convinced that SIP via JS or remote would perform adequately
> but certainly agree that we need to get on with it.
>
> compatibility, was just trying to avoid the “Flash” word :-)
> I hope we don’t discuss this here any more however since this list is about
> de jure standards.
>
> On Mon, Jan 31, 2011 at 8:34 AM, Henry Sinnreich <
> [email-masked]> wrote:
>
> +1
>

---

From: Peter Musgrave <[email-masked]>
Date: Tue, 1 Feb 2011 04:58:30 +0100

+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 <[email-masked]> 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 :-)
> 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.
> 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 <[email-masked]> wrote:
> +1
>