Subject: [rtcweb] Why are we asking the wrong questions?

From: Roman Shpount <[email-masked]>
Date: Thu, 20 Oct 2011 11:16:19 -0400

I am sorry for another rant, but it is painful to watch the discussion on
this list. We have a chance to create something great, but instead wasting
our time discussing irrelevant topics.

First irrelevant topic is "We want something that will allow to setup a
media call in 20 lines of JavaScript". If we are looking for something that
will to do this using the right JavaScript library and web server
components, then we will probably achieve this goal. If someone expects to
create something that by adding code at the browser level and no web server
cooperation will setup a call between two arbitrary browsers, then this is a
fool's quest. To setup a call browsers will need a meet point on the public
IP. On one hand we have hundred different ways to implement this using
current technology using a JavaScript library and one or the other server
component. On the other hand we have no standard protocol to implement a
meet point (some might argue for SIP or XMPP) but they do too much and do
not implement meet point functionality too well. If you want something
extremely simple just put a tel (or sip where supported) URL in your HTML.

Second irrelevant topic is PSTN vs some future web technology. We should
stop arguing about supporting or not supporting PSTN connectivity and
tailoring to the needs of some future start up. It is not about PSTN. It is
about supporting currently used call negotiation scenarios. RTC will need to
support all the scenarios actively used right now. Ideally, it should be
able to support future scenarios that we cannot support now due to
offer/answer limitations. Deliberately disabling support for current
applications is misguided not only from the point of view of
interoperability, but from the point of view of disabling future
applications.

As it was said numerous times on this list, there are quite a few examples
of RTC applications currently being used on the web. Their main limitation
is that they are using some sort of proprietary plugin to implement real
time media connections. The goal of this group is to create a set of
recommendations for standard implementation of this functionality. So the
right question would be what is the minimal feature set that needs to be
added to the browser which will allow web developers to create such
applications. Adding convenience APIs or optional functionality can be done
later.
_____________
Roman Shpount

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 20 Oct 2011 17:03:01 +0000

+1
Or rather, in memory of Dennis Ritchie: agree++

-hadriel

On Oct 20, 2011, at 11:16 AM, Roman Shpount wrote:

> I am sorry for another rant, but it is painful to watch the discussion on this list. We have a chance to create something great, but instead wasting our time discussing irrelevant topics.
> 
> First irrelevant topic is "We want something that will allow to setup a media call in 20 lines of JavaScript". If we are looking for something that will to do this using the right JavaScript library and web server components, then we will probably achieve this goal. If someone expects to create something that by adding code at the browser level and no web server cooperation will setup a call between two arbitrary browsers, then this is a fool's quest. To setup a call browsers will need a meet point on the public IP. On one hand we have hundred different ways to implement this using current technology using a JavaScript library and one or the other server component. On the other hand we have no standard protocol to implement a meet point (some might argue for SIP or XMPP) but they do too much and do not implement meet point functionality too well. If you want something extremely simple just put a tel (or sip where supported) URL in your HTML.
> 
> Second irrelevant topic is PSTN vs some future web technology. We should stop arguing about supporting or not supporting PSTN connectivity and tailoring to the needs of some future start up. It is not about PSTN. It is about supporting currently used call negotiation scenarios. RTC will need to support all the scenarios actively used right now. Ideally, it should be able to support future scenarios that we cannot support now due to offer/answer limitations. Deliberately disabling support for current applications is misguided not only from the point of view of interoperability, but from the point of view of disabling future applications.
> 
> As it was said numerous times on this list, there are quite a few examples of RTC applications currently being used on the web. Their main limitation is that they are using some sort of proprietary plugin to implement real time media connections. The goal of this group is to create a set of recommendations for standard implementation of this functionality. So the right question would be what is the minimal feature set that needs to be added to the browser which will allow web developers to create such applications. Adding convenience APIs or optional functionality can be done later. 
> _____________
> Roman Shpount
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Ted Hardie <[email-masked]>
Date: Thu, 20 Oct 2011 11:12:05 -0700

On Thu, Oct 20, 2011 at 8:16 AM, Roman Shpount <[email-masked]> wrote:

> media call in 20 lines of JavaScript".

Perhaps it is time to review some of the drivers of the work here.  One of
the primary issues raised during the lead-up to the BoF was that embedded
interactive audio/video functions which could be achieved with plugins could
not be achieved without them.  Since the plugins varied (both among vendors
and over versions), that created an interoperability problem and hindered
deployment (some people would not download the plugins, others would not
upgrade deployed version, not all plugins were available on all
platforms--the usual litany).

To compete with a plugin, however, it cannot be significantly harder to
write an RTCWeb-capable  application than the equivalent in the popular
plugins.  If it is far more difficult or far less clear how to do it, the
effort fails.

How you achieve that simplicity may still be up for debate, but I don't
think the goal is wrong.   If you do, I am curious why continuing along the
plugin path is not simply the right answer for your goals.

regards,

Ted

PS.  In a spirit of openness, I freely admit to having concerns that the
"1000s of JS libraries" vision will either fail to emerge, fail to be
maintained, or will result in sufficient confusion among app writers that it
fails the "far less clear how to do it" test.  To avoid that, I think you
have to standardize the JS libraries' base capabilities in a way that makes
it just as simple to put the base capabilities into the browser--with the
resulting advantages in download power and energy already described, not to
mention the system simplicity issues Harald raises, and with which I agree.
But that issue (standard library functions versus standard browser
functions) is less important than the goal: make it dead simple to include
interactive audio and video functionality in a web page/app *without a
plugin*.

---

From: Roman Shpount <[email-masked]>
Date: Thu, 20 Oct 2011 14:37:52 -0400

> interactive audio and video functionality in a web page/app *without a
I think I do not quite agree about "dead simple". "Dead simple" is not the
goal, the goal is simple as possible without jeopardizing the functionality.
As I mentioned before, adding "tel:" or "skype:" or "sip:" URL to a document
is already dead simple, but does not get you much.

The good way to develop such APIs is to develop a minimal set of primitives
that will allow the desired functionality. If from application building
experience a set of operations emerge that are complex to implement, but
often used, add them as convenience API functions. Starting from convenience
API usually gets you to a point were you get an API with 10 different ways
of doing almost the same thing (see sound APIs in Linux or Timers in
Windows).

Standard signaling protocol is a convenience feature for RTC. It is heavily
dependent on the matching server component. It replicates functionality that
is already available and requirements for it are unclear.
_____________
Roman Shpount

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 20 Oct 2011 22:09:25 +0200

> is already available and requirements for it are unclear.

Hi Roman, could you please check this short document and specify which
"signaling protocol" (of the three appearing in the document) you
mean?:

  http://dev.sipdoc.net/projects/oversip/wiki/RTCweb_Signaling_Components

Thanks a lot.

PS: I suggest all the WG to avoid the term "TRCweb signaling protocol"
because it's confussing given the different fragments of RTCweb in
which something related to "signaling" exists.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Roman Shpount <[email-masked]>
Date: Thu, 20 Oct 2011 16:47:26 -0400

On Thu, Oct 20, 2011 at 4:09 PM, Iñaki Baz Castillo <[email-masked]> wrote:

> This document is under password protection and I cannot access it.

P.S. I suggest to stop redefine standard terms for the sake of the working
group. Signaling protocol is defined in
http://en.wikipedia.org/wiki/Signaling_protocol and is something like SIP --
definition of data interactions over a wire. A set of JavaScript methods is
not a signaling protocol -- it is an API. State machine that describes these
JavaScript methods is still part of the API specification. In my personal
opinion, there are should be no "signaling protocols" in RTC. Trying to say
that JavaScript definitions is some type protocol is just trying to discuss
something which out of scope of this group and belongs to W3C.
_____________
Roman Shpount

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 20 Oct 2011 22:59:50 +0200

> This document is under password protection and I cannot access it.

Hi Roman, it's not under password protection. But the web has no
favicon and the document root has no index permission, so when your
browser requests the "standard" favicon icon it finds a 401 response.
That's a bug of some web browsers. Please just press "cancel" when
user:passwd is requested.

> definition of data interactions over a wire.

The document I've written is more that just the definition of
"signaling protocol".

>  A set of JavaScript methods is
> opinion,

I can agree with this. The important point here is that all the WG
agrees with the term to use in each case.

> there are should be no "signaling protocols" in RTC.

In your previous comment you said:

  "Standard signaling protocol is a convenience feature for RTC."

Could you please clarify if you are in favour of mandating the
in-the-wire signaling protocol or not?

Thanks a lot.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Roman Shpount <[email-masked]>
Date: Thu, 20 Oct 2011 17:07:00 -0400

On Thu, Oct 20, 2011 at 4:59 PM, Iñaki Baz Castillo <[email-masked]> wrote:

> I am saying that it is a convenience feature that provides little useful
functionality apart from a few corner cases and is extremly hard to define.
because of this I am against it.
_____________
Roman Shpount

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 20 Oct 2011 23:20:45 +0200

>  http://dev.sipdoc.net/projects/oversip/wiki/RTCweb_Signaling_Components

Sorry, the correct link is:

http://public.aliax.net/RTCweb_Signaling_Components.html

-- 
Iñaki Baz Castillo
<[email-masked]>