Subject: [rtcweb] A plea for simplicity, marketability - and... who are we designing RTCWEB for?

From: Dan York <[email-masked]>
Date: Wed, 19 Oct 2011 09:20:18 -0400

Folks,

I need to rant. I've been lurking on this list from the beginning but with a new job I haven't been able to really keep up with the volume of messages... and every time I get ready to reply I find that others like Hadriel, Tim, Neil, Tolga or others have made the points I was going to make... 

But I find myself increasingly frustrated with the ongoing discussions and want to ask a fundamental question:

- WHO ARE WE BUILDING RTCWEB/WEBRTC FOR?

Is it for:

1. Telephony developers who are tired of writing code in traditional languages and want to do things in new web ways;

2. Web developers who want to add real-time comms (as in voice, video and chat) to their existing or new web applications;

3. Both 1 and 2.

If the answer is #1, then I think everything is going along just wonderfully.  We can go ahead and use the SIP/SDP/etc. stuff that we all in the RAI area are all used to and understand just fine.  Heck, let's just all end the discussions about a signalling protocol and agree on SIP... get the browser vendors to agree on baking a SIP UA into their browsers... and call it a day and go have a beer.  Simple. Easy. Done.

And the only people who will ever use it will be people who work for RTC/UC/VoIP vendors and random other programmers who actually care about telephony, etc. 

 But that's okay, because the people who do use it (and their employers) will be really happy and life will be good.

If the answer is #2, then I think we need to step back and ask - 

   HOW DO "WEB DEVELOPERS" REALLY WANT TO WORK?

Here's the thing... in my experience...

    99% OF WEB DEVELOPERS DON'T GIVE A ______ ABOUT TELEPHONY!

Never have.  Never will.  (In fact, I may be understating that. It may actually be 99.99999%.)

If they are with startups, they want to build nice bright shiny objects that people will chase and use.  They want to make the next Twitter or FourSquare or (pick your cool service that everyone salivates over).  If they are with more established companies, they want to create easy-to-use interfaces that expose data or information in new and interesting ways or allow users to interact with their web apps in new and useful ways.

And they want to do all this using the "languages of the web"... JavaScript, PHP, Ruby, Python, etc.

They want "easily consumable" APIs where they can just look at a web page of documentation and understand in a few minutes how they can add functionality to their app using simple REST calls or adding snippets of code to their web page.  Their interaction with telephony is more along these lines:

"Wow, dude, all I have to do is get an authorization token and curl this URL with my token and a phone number and I can create a phone call!"

And the thing is... they can do this **TODAY** with existing proprietary products and services.  You can code it all up in Flex/Flash. You can write it in Java.  You can use Voxeo's Phono.  You could probably do it in Microsoft's Silverlight.  I seem to recall Twilio having a web browser client.  A bunch of the carriers/operators are starting to offer their own ways of doing this.  On any given week there are probably a dozen new startups out there with their own ideas for a new proprietary, locked-in way of doing RTC via web browsers.

Web developers don't *NEED* this RTCWEB/WebRTC work to do real-time communications between browsers. 

It can be done today.  Now.

The drawback is that today you need to have some kind of applet/plugin/extension downloaded to the browser to allow access to the mic and speakers and make the RTC actually work.  So you have to use some Flash or Java or something. AND... you are locked into some particular vendor's way of doing things and are reliant on that vendor being around.

THAT is what RTCWEB can overcome.  Make it so that web developers can easily add RTC to their web apps without requiring any downloads, etc.  Make it do-able in open standards that don't lock developers in to a specific product or vendor.

But if we are targeting "web developers", that is need we need to satisfy... and we need to understand that they *already* have ways to do what we are allowing them to do.

If we come out with something that is so "different" from what "web developers" are used to... that requires someone to, for instance, understand all of what SIP is about... that requires a whole bunch of lines of code, etc.... well...

... the web developers out there will NOT launch an "Occupy RTCWEB" movement claiming that they are the "99% who don't care about telephony"... they will simply... not... use.... RTCWEB!

They will continue to use proprietary products and services because those work in the ways that web developers are used to and they make it simple for a web developer to go add voice, video and chat to a web app.  Sure... they will still require the dreaded plugin/extension, but so be it... the "open standard" way is far too complicated for them to look at.

And all the work and the zillions of hours of writing emails and I-Ds that this group has done will all be for nothing.  Well, not nothing... some of the telephony-centric developers will use them.  But the majority of the web developers out there may not because there are other simpler, easier ways to do what they need to do.

So I go back to the question - who are we building RTCWEB for?

Is the goal to enable the zillions of web developers out to be able to use real-time communications in new and innovative ways?  Or is it solely to make it so that VoIP/UC/RTC vendors can make a softphone in the browser that calls into their call center software?

RTCWEB *can* enable both... but to me it's a question of where the priority is.

The question is - will the RTCWEB/WEBRTC API/protocol/whatever be so simple and easy that web developers will choose to use it over Flash/Phono/Twilio/Java/whatever to add RTC functions to their web apps?

If the answer is yes, we win.  Open standards win. Maybe we upgrade from having a beer to having champagne.

If the answer is no, what are spending all this time for?

</rant>

Dan

-- 
Dan York  [email-masked]
http://www.danyork.com/   skype:danyork
Phone: +1-802-735-1624
Twitter - http://twitter.com/danyork
--------------------------------------------------------
All comments and opinions are entirely my own and have no connection whatsoever to any employer, past or present. Indeed, by tomorrow even I might be disavowing these comments.
--------------------------------------------------------

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 19 Oct 2011 16:03:24 +0200

Dan,

thanks for the rant!

Unfortunately, I'm finding that I agree with almost everything you wrote 
- and STILL find that I see arguments on both sides of the "lowlevel API 
/ ROAP" divide.

On 10/19/11 15:20, Dan York wrote:
> Is the goal to enable the zillions of web developers out to be able to 
> use real-time communications in new and innovative ways?  Or is it 
> solely to make it so that VoIP/UC/RTC vendors can make a softphone in 
> the browser that calls into their call center software?
>
> The question is - will the RTCWEB/WEBRTC API/protocol/whatever be so 
> simple and easy that web developers will choose to use it over 
> Flash/Phono/Twilio/Java/whatever to add RTC functions to their web apps?
>
While I like beer, I'd like there to be champagne :-)

But - in my reading, the "lowlevel API" requires wisdom in both the 
browser and in Javascript about "all the RTC stuff"; the "ROAP" API 
requires wisdom in the browser about the same stuff.

The "lowlevel API" (once it's fully fleshed out) will (presumably) allow 
the Phonos of the world to offer an API as compelling as what they have 
today.

The "ROAP API" hides the complexity in a different way; so far, people 
have argued that everything we have listed as scenarios can be done in a 
ROAP-like fashion, and this API can be offered without requiring the 
assistance of additional libraries.

Do you see a compelling argument that enables you to say that one path 
is better than the other?

                      Harald

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 19 Oct 2011 16:38:45 +0200

2011/10/19 Dan York <[email-masked]>:
> The question is - will the RTCWEB/WEBRTC API/protocol/whatever be so simple
> and easy that web developers will choose to use it over

You miss the fact that RTCweb is a technology, not a JavaScript
library. When RTCweb becomes a reality there will appear thousands of
JavaScript libraries implementing a custom signaling protocol. Web
developers will choose the best one or the easiest one, in the same
way lot of web developers include JQuery library for making JS effects
and manage the DOM in their web pages without knowing aout JQuery
internals.

RTC is about realtime communication. Web is not about communication,
so we cannot expect to build "something" that requires no knowledge or
RTC protocols. Web developers will choose some existing and successful
RTCweb JS library and include it within their web apps. Of course, it
also requires some code in the server, but that will be not so hard,
and 100% feasible using PHP or whatever language.

RTCweb means real integration of VoIP in the WWW world. So VoIP folks
must learn something about WWW and WWW folks must learn something
about VoIP (not too much when RTCweb JS libraries appear). A web
developer has not the right to claim "I want cool new features but I
don't want to learn new stuff".

Take a look to Google Maps (web version). It contains a really complex
JavaScript logic, but the tools are there available for any one (it's
JavaScript and AJAX in the client side, no more) and any developer
could code something similar (having enough knowledge). And I've not
seen a web developer complaining because "doing it is so hard".

Regards.

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

---

From: Wolfgang Beck <[email-masked]>
Date: Wed, 19 Oct 2011 17:12:18 +0200

I agree on all points. My rant in this direction took the form of
http://tools.ietf.org/html/draft-beck-rtcweb-alt-ic-00

Wolfgang Beck

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Wed, 19 Oct 2011 19:43:26 +0200

Hi Dan,

> It can be done today.  Now.

[snip]

Well, lets take Phono as an example. Why can people build cool things with it? Because it's a simple library and developers don't need to do much, right? That's only true because someone (Voxeo in the case of Phono) provides a server for it. Inaki and Jose could very well build a jQuery plugin on top of that jsSIP library which would connect you through *their* OverSIP servers and it would work just as good. A phone in your browser, 10 lines of JS.

Don't get me wrong, I don't want to bring the PSTN dinosaur into web browsers, but I don't want to build another island o devices to which we'll need to gateway later either, because we will.

Regards,

--
Saúl Ibarra Corretgé
AG Projects

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 19 Oct 2011 19:50:47 +0200

> Well, lets take Phono as an example. Why can people build cool things with it? Because it's a simple library and developers don't need to do much, right? That's only true because someone (Voxeo in…

This is an important note. When a web developer uses Phone it's just
using the JS provided by Phono, but it must connect to Phono servers
(that is a product, a service, NOT an open technology).

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

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Wed, 19 Oct 2011 19:57:24 +0200

> (that is a product, a service, NOT an open technology).

That was not my point. My point was that Phono connects to a predefined server, it doesn't really matter if it's open or close, what matters is the fact that a server is provided for the cool stuff to happen.

--
Saúl Ibarra Corretgé
AG Projects

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 19 Oct 2011 11:39:12 -0700

Dan --

Great rant.  However, if I understand you correctly, your concerns relate to the WEBRTC APIs being developed within W3C, not to the work going on in IETF RTCWEB.  Personally, I don't expect the W3C APIs to be used directly by Web developers in most cases.  Rather, I expect developers to use higher level libraries that will, among other things, check for the available browser functionality, enabling applications to run both on browsers that support RTCWEB, as well as ones that do not but support the alternatives you mention.  Given that, I'm not expecting that developers will find RTCWEB any harder to use than the alternatives, because the differences will be abstracted away. 

However, if we are opening the RANT queue, I do have a concern that relates to IETF RTCWEB.  And that is the number of dependencies that are piling up, even for simple scenarios.  Fundamentally, many of the issues we have been talking about arise from the need to support peer-to-peer media.  This is what drives the need for ICE (so recipient can authorize sending of media),  end-to-end security (e.g. to know/authorize where P2P media is going),  and to some extend DoS and congestion control functionality.   While I understand the need for P2P support, we do need to avoid imposing all of these dependencies in simple client/server scenarios.  For example, if all a developer wants to do is send media and signalling down a websocket, many of the concerns arising from P2P media evaporate.  When operating within the "single origin" model, it should be possible to maintain a very high degree of legacy interop, with no requirements for ICE, e2e security, etc.  

From: [email-masked]
Date: Wed, 19 Oct 2011 09:20:18 -0400
To: [email-masked]
Subject: [rtcweb] A plea for simplicity,	marketability - and... who are we designing RTCWEB for?

Folks,

-- 
Dan York  [email-masked]
http://www.danyork.com/   skype:danyork
Phone: +1-802-735-1624
Twitter - http://twitter.com/danyork--------------------------------------------------------All comments and opinions are entirely my own and have no connection whatsoever to any employer, past or present. Indeed, by tomorrow even I might be disavowing these comments.--------------------------------------------------------

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

---

From: "Aaron Clauson" <[email-masked]>
Date: Thu, 20 Oct 2011 09:38:19 +1100

>-----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of Dan York
> <snip>
> </snip>

I thought the point of RTCWeb was so I'd be able to set up a voice call
between my browser and my VoIP Phone :). Something I can't do now with
Flash/Phono/Twilio/javascript-libraries et al at least not without one or
more media and signalling proxies in between. I originally thought RTCWeb
was going to be the bridge between the VoIP and the Web Worlds but I must
say I'm now a bit lost as to what it's about with all the different ideas
flying around at lightspeed.

My own very very humble opinion is that RTCWeb should incorporate RTP (over
UDP & TCP), a codec plugin mechanism and mircophone/speaker/camera
integration and bake it all into the browser. Everything else (signalling,
SDP, easy to use APIs etc. etc.) will be sorted out by smart devs coming up
with javascript libraries.

Aaron

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 19 Oct 2011 18:46:30 -0600

Dan, totally agree, my goal has been able to have a nice little example that shows setting up communications in a browser in simple little HTML / JS example. I'm like how you make calls from the a browser on iphones. You just put a tel URL on your web page and it works. Unfortunately I think that is too simplistic for what we need but I view that as the level of simplicity to strive for.

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 19 Oct 2011 20:13:25 -0600

> However, if we are opening the RANT queue, I do have a concern that relates to IETF RTCWEB.  And that is the number of dependencies that are piling up, even for simple scenarios.  Fundamentally, ma…

Bernard, let me just make sure I have this right. You are proposing all the voice and video going from browser A to browser B should be sent over TCP (via websockets) through the web server?

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 20 Oct 2011 07:32:20 -0700

No, I'm saying that *if* a developer remains within the "single origin" model, that a number of requirements for peer-to-peer operation do not apply. 

Also that the APIs should also enable media to be sent over a websocket to the "single origin" as well as a PeerConnection. 

> Subject: Re: [rtcweb] A plea for simplicity, marketability - and... who are we designing RTCWEB for?
> From: [email-masked]
> Date: Wed, 19 Oct 2011 20:13:25 -0600
> CC: [email-masked]
> To: [email-masked]
> 
>

---

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

2011/10/20 Bernard Aboba <[email-masked]>:
> the APIs should also enable media to be sent over a websocket

WHAT??

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

---

From: "Olle E. Johansson" <[email-masked]>
Date: Thu, 20 Oct 2011 16:45:25 +0200

>> the APIs should also enable media to be sent over a websocket
A more specific question: What are the use cases?

I understand that media over TCP is used in many apps today. While media over websocket over tcp over IP sounds just a bit too much, I am very curious on the use case.

Thanks.
/O

---

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

> I understand that media over TCP is used in many apps today. While media over websocket over tcp over IP sounds just a bit too much, I am very curious on the use case.

There is no use case. WebSocket is NOT designed for carrying media.

WebSocket is designed for sending and receiving *boundary* messages
(with any application content up to the developer) over an existing
TCP connection between client and server, in both directions. When a
WebSocket message arrives to the browser, a JavaScript callback
onmessage(data) is called, so the custom JavaScript code can read it,
parse it and react according.

This stuff is NOT designed for media !

Please read:

http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-17
http://dev.w3.org/html5/websockets/#the-websocket-interface

I strongly hope this WG will not waste time in discussions about "RTP
over WebSocket", or it will become surrealist.

Regards.

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

---

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

On Thu, Oct 20, 2011 at 10:45 AM, Olle E. Johansson <[email-masked]> wrote:

> I understand that media over TCP is used in many apps today. While media
> over websocket over tcp over IP sounds just a bit too much, I am very
> curious on the use case.
>
>
I am not sure that he actually meant media over websocket, but single origin
application and media (RTP media sent to the same IP as web app), might
warrant relaxed security requirements. In particular, if RTC client is
sending media to the same IP as a web server providing JavaScript, it can
probably do so without ICE connectivity check without introducing any
security issues. I am not sure how big of the use case this is going to be,
but this can be attractive in some cases (use IP load balancer to send HTTP
requests to one server and RTP port range to a gateway or SBC).
_____________
Roman Shpount

---

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

On Thu, Oct 20, 2011 at 10:52 AM, Iñaki Baz Castillo <[email-masked]> wrote:

> I think it already became surrealist. I now understand why W3C holds
private discussions of the standards.
_____________
Roman Shpount

---

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

> requests to one server and RTP port range to a gateway or SBC).

Yes, that's the WWW vision for any problem to solve:

HTTP/WebSocket protocol for all, port 80 and IP load balancers. There
si no more in WWW minds.

We can do it much better.

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

---

From: "Olle E. Johansson" <[email-masked]>
Date: Thu, 20 Oct 2011 16:56:11 +0200

> There is no use case. WebSocket is NOT designed for carrying media.

Right. But if we want to inject prompts in the call or save media files recorded, would that work? Not realtime.

Bernard - what did you have in mind when you wrote that?

/O

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 20 Oct 2011 08:36:54 -0700

On Thu, Oct 20, 2011 at 7:32 AM, Bernard Aboba
<[email-masked]> wrote:
> No, I'm saying that *if* a developer remains within the "single origin"
> model, that a number of requirements for peer-to-peer operation do not
> apply.
>
> Also that the APIs should also enable media to be sent over a websocket to
> the "single origin" as well as a PeerConnection.
>

I don't think I'm following you're argument. ISTM that there are two
conditions that one
might term "single origin":

1. Alice and Bob are on the same site (e.g., PokerStars) and are
calling each other via P2P media,
2. Alice and Bob are on the same site and are calling each other
via media over WS.

In the first case, I don't see why this would allow us to relax any of
the security
requirements. As long as Alice and Bob are sending media to each other, we still
cannot trust the site to adequately verify consent, so we clearly need
ICE. As for
the need for E2E security, this seems equally important regardless of whether
Alice and Bob share the same site.

In the second case, I agree that you don't need to verify consent because it's
implicit in the WS protocol. (I'm leaving aside the question of whether using WS
this way is advisable), but the need for E2E security seems equal if
not greater,
since in this case the site would have direct access to the media.

-Ekr

---

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

On Thu, Oct 20, 2011 at 11:36 AM, Eric Rescorla <[email-masked]> wrote:

> conditions that one might term "single origin":
>

There is a third condition for the term "single origin": an RTC application
calling a server which provided the JavaScript with RTC application. For
instance if you have an application from a phone service provider or
conferencing app. This application will never setup a P2P call between two
browsers, it is always between provider and the browser, so it can ask for
relaxed security since it only calls its own IP.
_____________
Roman Shpount

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 20 Oct 2011 08:54:55 -0700

> relaxed security since it only calls its own IP.

Unless the browser can directly verify that the target of the media and the
source of the JS are one and the same, then at minimum the consent issues
apply.

-Ekr

---

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

2011/10/20 Roman Shpount <[email-masked]>:
> This application will never setup a P2P call between two browsers, it is
> always between provider and the browser, so it can ask for relaxed security
> since it only calls its own IP.

There is long rationale about this topic in the list. Security cannot
(MUST NOT) be relaxed, never, because just the human can determine
when to allow "relaxed security" (and we don't want that a malicius
site asks the human user "press Accept Relaxed Security and you can
win a car". The browser has no way to determine whether the
destination of *all* the calls is a "trusted" server or not.

Also you are asuming that the media is sent to the same IP of the web
server (in case a RTCweb scenario does not include user2user calls).
This is a too much simplified scenario, and you miss that a DNS A
record can point to N IP's, and you also miss the case in which the
webserver has an IP different than the media server (regardless they
both are located within the same provider infrastucture). The browser
cannot determine it by itself, so security is always a need, and IMHO
it's a bad idea to allow a very corner case in which such security
could be relaxed.

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

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 20 Oct 2011 09:18:50 -0700

> the security requirements. As long as Alice and Bob are sending media to each other, we still
> ICE. As for the need for E2E security, this seems equally important regardless of whether

[BA] I agree.  Where there is P2P media,  ICE is required.
 
> not greater, since in this case the site would have direct access to the media.

[BA] Yes, that was my point.

---

From: Randell Jesup <[email-masked]>
Date: Thu, 20 Oct 2011 13:40:00 -0400

> 2. Alice and Bob are on the same site and are calling each other

I'll add a third: Alice and Bob are on the same site, and are 
participating in a (potentially) multi-person conference run through the 
site, which is acting as a mixer or at least relay.  Media is sent via 
normal PeerConnection channels, encrypted with DTLS-SRTP.  In this 
limited case, each participant is sending media to the same site (*) as 
the JS code is loaded from.

So, the questions here would be
a) can we relax ICE consent checks if the site/app so wishes and
b) should we?

I think we can (if the app tells us to, since it's "same-origin" and the 
app should know), but I'm a little less certain of the "should".  Is 
there an attack wherein someone could 'host' some JS content (app) on a 
site and use it to attack/DoS that site from multiple places?  It seems 
at least plausible.

-- 
Randell Jesup
[email-masked]

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 20 Oct 2011 20:14:18 +0200

On 10/20/2011 07:40 PM, Randell Jesup wrote:
> participating in a (potentially) multi-person conference run through 
> the site, which is acting as a mixer or at least relay.  Media is sent 
> via normal PeerConnection channels, encrypted with DTLS-SRTP.  In this 
> limited case, each participant is sending media to the same site (*) 
> as the JS code is loaded from.
>
> I think we can (if the app tells us to, since it's "same-origin" and 
> the app should know), but I'm a little less certain of the "should".  
> Is there an attack wherein someone could 'host' some JS content (app) 
> on a site and use it to attack/DoS that site from multiple places?  It 
> seems at least plausible.

My paranoid self comes up with two, and warns me that there may be 
others....

1) if the "site" is in fact a NAT box, AND the attacker is able to get a 
whole TCP port number on that box AND allow incoming connections....

THEN the attacker can "host" a web server at natbox-ip:hisportnumber, 
and freely use the "same site" criterion to get people to DOS other 
users of the same NAT box.

2) if the "site" is identified by domain name, and the attacker owns the 
domain name, and the attacker can dynamically switch between two 
short-TTL A records for the "site"....

THEN the attacker can let the "helper" load up the page and Javascript 
from the attacking site, switch the A record around to point at his 
victim, and have the attack go to the victim's IP address.

I'm sure people with larger experience in paranoia than I have can come 
up with other scenarios. Or possibly come up with a defense against 
these and other threats that is cheaper than ICE.

But until then ..... I don't think we should.

                    Harald

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 20 Oct 2011 11:33:14 -0700

> seems at least plausible.

[BA] Taken to its conclusion, this is an argument for imposing ICE as a requirement for *all* web-based applications. 

There is no evidence that such a requirement is necessary -- and even if it were to be done, it would be almost certainly be ignored (and rightly so) by the developer community. 

There is a line between safely attempting to add new functionality, and attempting to disable existing functionality.  

The former is in scope, the latter is not.

---

From: "Ravindran Parthasarathi" <[email-masked]>
Date: Fri, 21 Oct 2011 17:17:01 +0530

Dan,

I like your rant as a rant from web developer perspective. 

My observation and opinion as a SIP developer is as follows: Your
classification of telephony developers involves SIP developer. The point
to be noted is that nearly 10 years back, IETF has come up with the new
signaling protocol (SIP+SDP) for real-time communication for Internet
which has lot of similarity to HTTP protocol design like
request/response model and also, spelt out explicitly in RFC 3261 (SIP
core RFC) that "SIP is not an extension to HTTP". Please note that SIP
is not designed in legacy telephony (PSTN/SS7) architecture fashion  (by
ITU) but designed based on Internet model wherein UA(endpoint) is
intelligent. After 10 years, now we are interested in real-time
communication using HTTP only.  I have little tough time in digesting
because we could have enhanced HTTP long back to perform real-time
communication or now, we stick to SIP for real-time communication or
now, deprecate SIP and use HTTP based extension as real-time protocol
for future. In fact, I have started the mail to know why "SIP MUST NOT
be used in RTCWEB" for the very  same reason and the answer to the
question is that IETF created another protocol namely websocket +
metadata or long poll HTTP + metadata between browser-webserver which is
a better fit for HTTP (RTCWeb) real time communication. Well , now I'm
asking whether IETF will provide interop between its own real-time
communication deliverables like HTTP  (websocket+metadata) and SIP+SDP
or not? , and also Point 9 of RTCWeb charters mentions the same as "The
group will consider options for interworking with legacy VoIP
equipment."  I like ROAP sort of protocol as an metadata for HTTP for
the same reason which helps for interop by having interworking RFC's.
It would be very bad in case such interop is developer/designer
headache.

Please note that there is no mention of JavaScript, PHP, Ruby, etc in my
mail thread because each of the language/script will have API to
abstract the protocol details.  

Thanks

Partha 

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Dan York
Sent: Wednesday, October 19, 2011 6:50 PM
To: [email-masked]
Subject: [rtcweb] A plea for simplicity,marketability - and... who are
we designing RTCWEB for?

Folks,

I need to rant. I've been lurking on this list from the beginning but
with a new job I haven't been able to really keep up with the volume of
messages... and every time I get ready to reply I find that others like
Hadriel, Tim, Neil, Tolga or others have made the points I was going to
make... 

But I find myself increasingly frustrated with the ongoing discussions
and want to ask a fundamental question:

Is it for:

1. Telephony developers who are tired of writing code in traditional
languages and want to do things in new web ways;

2. Web developers who want to add real-time comms (as in voice, video
and chat) to their existing or new web applications;

3. Both 1 and 2.

If the answer is #1, then I think everything is going along just
wonderfully.  We can go ahead and use the SIP/SDP/etc. stuff that we all
in the RAI area are all used to and understand just fine.  Heck, let's
just all end the discussions about a signalling protocol and agree on
SIP... get the browser vendors to agree on baking a SIP UA into their
browsers... and call it a day and go have a beer.  Simple. Easy. Done.

And the only people who will ever use it will be people who work for
RTC/UC/VoIP vendors and random other programmers who actually care about
telephony, etc. 

 But that's okay, because the people who do use it (and their employers)
will be really happy and life will be good.

Never have.  Never will.  (In fact, I may be understating that. It may
actually be 99.99999%.)

If they are with startups, they want to build nice bright shiny objects
that people will chase and use.  They want to make the next Twitter or
FourSquare or (pick your cool service that everyone salivates over).  If
they are with more established companies, they want to create
easy-to-use interfaces that expose data or information in new and
interesting ways or allow users to interact with their web apps in new
and useful ways.

And they want to do all this using the "languages of the web"...
JavaScript, PHP, Ruby, Python, etc.

They want "easily consumable" APIs where they can just look at a web
page of documentation and understand in a few minutes how they can add
functionality to their app using simple REST calls or adding snippets of
code to their web page.  Their interaction with telephony is more along
these lines:

"Wow, dude, all I have to do is get an authorization token and curl this
URL with my token and a phone number and I can create a phone call!"

And the thing is... they can do this **TODAY** with existing proprietary
products and services.  You can code it all up in Flex/Flash. You can
write it in Java.  You can use Voxeo's Phono.  You could probably do it
in Microsoft's Silverlight.  I seem to recall Twilio having a web
browser client.  A bunch of the carriers/operators are starting to offer
their own ways of doing this.  On any given week there are probably a
dozen new startups out there with their own ideas for a new proprietary,
locked-in way of doing RTC via web browsers.

Web developers don't *NEED* this RTCWEB/WebRTC work to do real-time
communications between browsers. 

The drawback is that today you need to have some kind of
applet/plugin/extension downloaded to the browser to allow access to the
mic and speakers and make the RTC actually work.  So you have to use
some Flash or Java or something. AND... you are locked into some
particular vendor's way of doing things and are reliant on that vendor
being around.

THAT is what RTCWEB can overcome.  Make it so that web developers can
easily add RTC to their web apps without requiring any downloads, etc.
Make it do-able in open standards that don't lock developers in to a
specific product or vendor.

But if we are targeting "web developers", that is need we need to
satisfy... and we need to understand that they *already* have ways to do
what we are allowing them to do.

If we come out with something that is so "different" from what "web
developers" are used to... that requires someone to, for instance,
understand all of what SIP is about... that requires a whole bunch of
lines of code, etc.... well...

... the web developers out there will NOT launch an "Occupy RTCWEB"
movement claiming that they are the "99% who don't care about
telephony"... they will simply... not... use.... RTCWEB!

They will continue to use proprietary products and services because
those work in the ways that web developers are used to and they make it
simple for a web developer to go add voice, video and chat to a web app.
Sure... they will still require the dreaded plugin/extension, but so be
it... the "open standard" way is far too complicated for them to look
at.

And all the work and the zillions of hours of writing emails and I-Ds
that this group has done will all be for nothing.  Well, not nothing...
some of the telephony-centric developers will use them.  But the
majority of the web developers out there may not because there are other
simpler, easier ways to do what they need to do.

RTCWEB *can* enable both... but to me it's a question of where the
priority is.

If the answer is yes, we win.  Open standards win. Maybe we upgrade from
having a beer to having champagne.

</rant>

Dan

All comments and opinions are entirely my own and have no connection
whatsoever to any employer, past or present. Indeed, by tomorrow even I
might be disavowing these comments.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 21 Oct 2011 13:58:51 +0200

2011/10/21 Ravindran Parthasarathi <[email-masked]>:
> I like ROAP sort of protocol as an metadata for HTTP

ROAP does not define the in-the-wire format of the messages.

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

---

From: Wolfgang Beck <[email-masked]>
Date: Fri, 21 Oct 2011 14:25:32 +0200

Comments inline

On Fri, Oct 21, 2011 at 1:47 PM, Ravindran Parthasarathi
<[email-masked]> wrote:
> ...
> Please note that SIP is not designed in legacy
> telephony (PSTN/SS7) architecture fashion  (by ITU) but designed based on
> Internet model wherein UA(endpoint) is intelligent.
..but we still introduced the BYE request and stateful proxies for
forking.  Both functions could have been done
in the UA..

> After 10 years, now we are interested in real-time communication using HTTP only.
No, not at all. We're interested in UAs that are programmable on the
fly -- like a web browser with javascript --,
so that we don't have to specify a protocol between client and server.
 Jonathan Rosenberg did an
enlightening presentation at one of the past plenaries.

When do we need a standardized protocol? We need one if two parties on
the same network layer were implemented
by different vendors.

This is true for RTP (at least if we stick to the P2P media dogma).
Browsers of different vendors must interoperate.

It might be true for SDP's functionality. If we implement it deep in
the browser, it must be standardized. The problem with SDP is, that it
relies on some other protocol for transport and has some very specific
requirements on that protocol. If we can make sure that all parties
involved in a call use the same JS client, we can get away without
standardization.

At the layer of call signaling messages are ultimately exchanged
between two JS clients running on browsers. If we have different JS
clients here, we need a standardized protocol between them. With
trapezoid interconnection, we can hide this to some extent by doing
protocol translations between JS client A / RTCWEB Server A and Server
B / JS client B. Some
information will get lost in translation.

But as browsers can load JS on the fly,  user A could simply point her
browser to Server B and use the same client as user B. Now all
components at the signaling layer are provided by a single vendor and
no standardized protocol is required. There is no loss of information
as there are no protocol translators.

Wolfgang Beck

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 21 Oct 2011 14:41:18 +0200

> as there are no protocol translators.

I agree with this approach, but it also leaves the door open (that's
important) to two different websites A and B implementing different
client-server protocols to interoperate in case they agree on another
protocol X between their servers and they build a protocol translator
in each side. That's up to them (like a custom federation).

This will be always possible but we cannot mandate or influence on it.
WWW will decide (as it always does). Time to time. The important point
here (IMHO) is to leave the door open for innovation, as much as
possible. WWW is untamable.

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

---

From: Randell Jesup <[email-masked]>
Date: Fri, 21 Oct 2011 14:28:53 -0400

> as there are no protocol translators.

This is the rough equivalent to saying "instead of exchanging email in a 
standard format, and letting people use whatever client/webmail-client 
they want to read it; if you want to read an email from a gmail user you 
should log into gmail using their interface; from an aol user log into 
AOL and their interface, etc.  Oh, and history, phonebooks, etc would 
all be separate."  Yes, it avoids standard 'federation' formats and 
conversions, but...

-- 
Randell Jesup
[email-masked]

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 21 Oct 2011 21:04:49 +0200

2011/10/21 Randell Jesup <[email-masked]>:
> This is the rough equivalent to saying "instead of exchanging email in a standard format, and letting people use whatever client/webmail-client they want to read it; if you want to read an email from a gmail user you should log into gmail using their interface; from an aol user log into AOL and their interface, etc.

This is because SMTP is a successful protocol that exists from long
time ago and allows each user to have a globaly reachable
identificator (a mailto: URI). Will RTCweb define an unique
identificator for each user in the world? Not at all. RTCweb will be
implemented by independent websites, so each website decides the
identificator grammar of its users. Please don't try to make analogy
between SMTP and RTCweb because it's not the same.

If I cannot make a VoIP call from my SIP client to a Gtalk user
(without using a protocol gateway), why should we define that a
Facebook user should be able to make a RTCweb call to a Twitter user
without requiring a protocol gateway?

At this point, I think we should have some folks from WWW world in
this WG. They could give us some lessons about how WWW works and stop
us thinking as telcos (remember that telcos have never succedeed in
the web, we are like a bull in a china shop).

> Oh, and history, phonebooks, etc would all be separate.

RTCweb is not a generic and personal phone in the browser, so there is
no "phonebook" concept here. Don't you realize that you are clearly
thinking as a telco now? :)

More stuf:

- When you press the "I like" button of Facebook in an external page,
such link points to Facebook servers.

- When you want to write something in Twitter (regardless you use the
Twitter website or any Twitter desktop/mobile client) you are
connecting to Twitter servers.

- When a website includes an embedded Youtube video, such video is
loaded from Youtube servers, not from the website in which it's
embedded.

This is the History of WWW and the reason of its success:
- NO standards (others than HTTP, HTML and JavaScript).
- Do whatever you want without reading IETF specs.
- Innovate without deep knowledge.

Said that, mandating the format in the wire is the key of no-success.
Even more: mandating anything apart from the RTCweb JS API and the
RTP/ICE design is the key of no-success. I'm pretty sure of that.

Cheers.

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

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 21 Oct 2011 21:17:45 +0200

2011/10/21 Iñaki Baz Castillo <[email-masked]>:
> this WG

(not too many, or we would end sending RTP on top of HTTP and having
to map the ~400 SIP response codes into "Answered", "No Answered" and
"I like").

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

---

From: Matthew Kaufman <[email-masked]>
Date: Fri, 21 Oct 2011 16:27:58 -0700

On 10/21/2011 11:28 AM, Randell Jesup wrote:
>
> This is the rough equivalent to saying "instead of exchanging email in 
> a standard format, and letting people use whatever 
> client/webmail-client they want to read it; if you want to read an 
> email from a gmail user you should log into gmail using their 
> interface; from an aol user log into AOL and their interface, etc.  
> Oh, and history, phonebooks, etc would all be separate."  Yes, it 
> avoids standard 'federation' formats and conversions, but...
>
>

Of course this is exactly what the various walled-garden websites of the 
world (see Facebook for a prime example) want to happen. That email was 
already widely federated isn't a feature for them at all.

Matthew Kaufman

---

From: Harald Alvestrand <[email-masked]>
Date: Sun, 23 Oct 2011 09:32:52 +0200

On 10/21/2011 09:04 PM, Iñaki Baz Castillo wrote:
> 2011/10/21 Randell Jesup<[email-masked]>:
> identificator (a mailto: URI).
Note (speaking as an emai veteran): These are 3 points (successful, 
existed for a long time, and allows a globally reachable ID). As of 
~1992, I don't believe that any of them were uncontroversial.
It took a lot of engineering work to get to where they were obvious truths.
>   Will RTCweb define an unique
RTCWEB won't, but SIP and XMPP already have. If people deploy 
applications that implement SIP or XMPP on top of RTCWEB, one of them 
might eventually turn out to be "obvious" in the same way.

That's a hope of many, but far from the only use case for RTCWEB.

---

From: Wolfgang Beck <[email-masked]>
Date: Mon, 24 Oct 2011 09:45:59 +0200

On Fri, Oct 21, 2011 at 8:28 PM, Randell Jesup <[email-masked]> wrote:
> standard format, and letting people use whatever client/webmail-client they
> want to read it; if you want to read an email from a gmail user you should
> log into gmail using their interface; from an aol user log into AOL and
> their interface, etc.  Oh, and history, phonebooks, etc would all be
> separate."  Yes, it avoids standard 'federation' formats and conversions,
> but...
Phonebooks aren't a problem. They're called 'Bookmarks' in my browser.
Call history doesn't look impossible to me as well. You can either
just use the browser's
history or setup some bookmarking web site that keeps track of your calls.

I used to defend Usenet using all of your arguments. The Web has won.

Wolfgang

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 24 Oct 2011 12:38:30 +0200

> history or setup some bookmarking web site that keeps track of your calls.

Hi Wolfgang. When you send a text message via Facebook or via Twitter,
can you check later all those messages *together* in some "messages
history" section within your browser? If the answer is not (and it is
not), why do you expect that it should be different for calls?

Also, what do you expect such "call history" to show you? In case you
make an audio call in Facebook its entry in the call-history list
would display your Facebook id as originator and the receiver Facebook
user as destination. But in case you join a web game in which RTCweb
is used for *automatically* receive audio from other gamers, what do
you expect the entry in the call-history to display?

Also the fact that your browser has received a RTCweb audio call from
a web game does not mean that you can make an outgoing call to the
caller (the website could be designed in a way that just calls from
server to clients make sense). It could occur that such incoming call
from the web game has not an "originator" (as such information is up
to the website). Nobody is mandating that a RTCweb call MUST contains
a "From" and a "To". RTC-Web is not SIP and it is not about legacy
telephony, neither it's designed to be an Skype on the web.

> I used to defend Usenet using all of your arguments. The Web has won.

IMHO I'm defending the Web model.

Regards.

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

---

From: Wolfgang Beck <[email-masked]>
Date: Mon, 24 Oct 2011 13:33:10 +0200

> not), why do you expect that it should be different for calls?
Sure with text message it is difficult to have a local history. But it
is different for voice/video calls.
Very few phones routinely store the entire call. A browser
implementation could do this, just like
it provides bookmark and browsing history functions.

> you expect the entry in the call-history to display?
My point was to show Randell that the single server model can provide
phone book and call history
functions if you need this. Either through the browser itself or
through some extra web site.

Even the trapezoid model can't guarantee that a phone book/call
history will always work
as expected. If a caller decides to suppress her caller ID, you'll
just see that someone unknown called.
If you call some company's number you can't be sure that you will be
connected to the same phone that
you reached during your last call.

If we stick to the trapezoid model, the intra-server protocol will be
a serious barrier to innovation. If you need something that doesn't
translate well to and from SIP, it won't work between your different
JS applications. Tunneling a protocol through SIP just shifts the
problem to this new protocol, which would need to be standardized as
well.

Wolfgang

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 24 Oct 2011 16:20:49 +0200

2011/10/24 Wolfgang Beck <[email-masked]>:
> If a caller decides to suppress her caller ID, you'll

Why are you assuming that a RTCweb call has always a caller ID?

Imagine a web game. A visitor enters the web and automatically
receives an audio "call" from the website. The user is prompted
"website mygame.com is attempting to establish an audio call with you,
do you accept?". The user presses OK and is entered into a multiconf
with all the web users. There is NO need at all for having a
"caller-id" in this kind of call. Again I insist that RTC-Web should
not be designed *just* to cover the use cases of current VoIP
protocols.

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

---

From: Wolfgang Beck <[email-masked]>
Date: Mon, 24 Oct 2011 17:38:48 +0200

> Why are you assuming that a RTCweb call has always a caller ID?
I do not assume this. I was referring to Randell's question about
phone books and call lists which are only useful
if you have some kind of caller id. But of course there are many
scenarios where you don't have one.

Wolfgang