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

["Ravindran Parthasarathi" <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] On Behalf
Of Dan York
Sent: Wednesday, October 19, 2011 6:50 PM
To: [e-mail]
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:

 

- 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  [e-mail]
http://www.danyork.com/   skype:danyork
Phone: [phone]
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.

--------------------------------------------------------