Re: Teleco Integrators vs Web Developers vs Browser Implementers

     I wish you good luck (honestly). I did have one question, however: 
how do you know what the "established RTC principles and security 
considerations" are? Part of the problem, as I see it, is that we don't 
have a design document explaining the use-cases that were considered and 
why each design decision was made. We're missing the "design blueprint". 
I believe you're going to find it very hard to design an equivalent API 
without this information.

Gili

On 28/06/2013 8:17 PM, Robin Raymond wrote:
>
> 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