Re: Teleco Integrators vs Web Developers vs Browser Implementers

Thanks - and in some ways that's absolutely true about security 
requirements. If we don't have a document that explains each choice 
along the way, things can be overlooked if you try some new approach.

Even though security is obviously really important, the larger issue I'm 
finding is knowing what exactly must be supported use case wise, 
especially in the context of being compatible with legacy/existing 
systems, including all the on-the-wire oddities that can happen, e.g. 
the mapping of streams, tracks, ssrcs, dtls muxing, multitrack payload 
based demuxing, CNAME correlation, video rules, incoming unmapped RTP 
tracks/streams, CNAME/RTP correlation race, SSRC collision, pre-mapping 
requirements, forking, etc.

Sure makes it fun! We'll undoubtedly get some stuff wrong. But hopefully 
the model is right so it's a matter of tweaking the parameters and rules 
to follow.

I can fully appreciate the reasons why the original design went down the 
SDP path. I think most people knew SDP was wonky. Having everything 
described in details in some master blob made the wire easier to 
understand. But that blob makes a horrible programmers interface with 
bad control and with lots of short/long term problems/consequence. I 
think there's a way to fix this API to make it semi-palatable for JS 
developers, make it on-the-wire compatible/understandable and achieve 
the requirement goals specified for WebRTC (even if they are a bit vague 
in some areas still).

We are giving it our best to fix this situation...

-Robin


> cowwoc <mailto:cowwoc@bbs.darktech.org>
> 29 June, 2013 12:26 AM
>
>     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:
>