Re: Teleco Integrators vs Web Developers vs Browser Implementers

It has been said always that SDP was choosed so WebRTC would be compatible
with current VoIP devices and software, so you could make calls from your
browser without needing a proxy. Problem is, that WebRTC has evolve a lot
adding a lot of features (panswer SDP message, new codecs...) that make
them incompatible with legacy VoIP systems so they should upgrade their
firmware or build a proxy anyway, so the main reason to use SDP has
dissapeared some time ago.
El 29/06/2013 07:19, "Robin Raymond" <robin@hookflash.com> escribió:

>
> 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 <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:
>
>