Re: Teleco Integrators vs Web Developers vs Browser Implementers

We would ask that hold off judgement until you read the proposal when 
it's ready.

We do appreciate your concerns about proposing an alternative and the 
amount of effort to get to this point by the various working groups, 
which is why it is being done with care. We are passionate about WebRTC 
and we have expert JavaScript and RTC people working together to ensure 
a good marriage between the RTC world and the JS world (at least what is 
possible given the underlaying technologies and real-world scenarios 
requirements).

As outlined in the raymond-rtcweb-webrtc-js-obj-api-rationale draft, we 
feel the current WebRTC API has serious flaws (short term and long 
term). Certainly some points can be argued but the overall arguments are 
sound/justified and we feel the new API about to be proposed will be a 
significant step in the right direction and it is not an attempt to 
"burn it all down and start over". None of us want this.

Obviously anything we produce will need to be vetted like any other API, 
but we will have a solid starting point and have the advantage of the 
hindsight of all these previous discussions and insights. We are working 
off the established RTC principles and security considerations, 
including with the understanding that browsers are not trust worthy sources.

As all drafts go through revisions, I do not feel it's appropriate that 
a bar be set to be 100% perfect in the first drafting. Having said that, 
we will not "hand wave" over the details and tough problems.Nor are we 
are not proposing reversing positions on the minimal transport 
technologies chosen at all (except SDP of course). The new API will take 
into account the feature requirements as of the latest RTCWEB draft 
available. What we are proposing will work on the wire, in a sensible 
and predictable manner.

Please stay tuned (and hopefully with an open mind). It won't be long to 
come.

-Robin



> Ted Hardie <mailto:ted.ietf@gmail.com>
> 28 June, 2013 7:10 PM
> On Fri, Jun 28, 2013 at 3:02 PM, Roman Shpount <roman@telurix.com 
> <mailto:roman@telurix.com>> wrote:
>
>      The functionality I need to implement (as a developer or as
>     teleco or as implementer) is to capture audio or video and send it
>     to the remote party. Or alternatively I want to receive audio or
>     video from remote party and play it out locally.
>
>
> For what it's worth, the high level abstraction you put forward is 
> pretty much what I believe the rtcweb group sees as the problem 
> space:  plumb a local media source or application data stream so that 
> it is played out/used locally or sent across a network to a peer, who 
> must then be able to use it in a way understood by the application.
>
> But, as the case is so often, there are many details, and some have 
> them have devilled us a long while.   Making sure you are talking to 
> someone who is willing to listen, for example, involved using the ICE 
> mechanisms to establish consent freshness.   That may well mean we 
> have to use ICE even when IPv6 or un-natted candidate addresses are 
> available.   The local media source's output must be encoded in a way 
> so that it is understood by the entity playing it out; that either 
> means picking a single method for that encoding, setting up a 
> negotiation mechanism, or losing some significant period of time.  
> That's given rise to long discussions of codec licensing.  Sending out 
> the stream to a remote party necessarily involves putting the results 
> of the encoding into a series of packets on the wire in a format that 
> is sufficiently likely to get past NATs and Firewalls (possibly with 
> the help of ICE) that the application works.  That got us RTP over UDP 
> and RTCP, which incidentally got us at least a vague promise that we'd 
> be able to handle the worst effects of congestion (but also caused us 
> to set up a working group to find something better).  The list of 
> details engendered by those choices is, in other words,  almost as 
> long and equally equal devilling.
>
> Another devilment in all of this is that we are not building a system 
> where we expect independent applications to be the primary users of 
> the protocol stack; we need to make sure that we are building for a 
> case where a downloaded application in a browser context does not 
> exceed the limits placed on it by that context.  It's a fundamental 
> part of the model that the JavaScript application is not as trusted 
> part of the system as the browser; it may be malicious and that case 
> must be handled well.
>
> Forgive my going off on what may seem like a tangent here, since none 
> of the issues I mention relate directly to offer/answer or the use of 
> SDP.  But you appear to be about to propose an alternative API than 
> the one the group has built up over many months.  If you do so, please 
> make sure that it doesn't hand wave away the real implications of the 
> system we're building.   It's very easy in a situation like this to 
> reconstruct a piece of the system that you don't like to better suit 
> your use cases or tastes, but there is a very real risk that doing so 
> may miss one of the other aspects of the system. There have been 
> systems other than SDP/offer-answer that have used RTP (SAP being an 
> early one), but at some level getting the API to the browser is only 
> half the battle.  If what it expresses can't be sensibly sent across 
> the wire by a browser without reinventing that wheel, we are no better 
> off and potentially a great deal worse off.
>
> Wearing neither hats nor company swag,
>
> Ted