Re: Teleco Integrators vs Web Developers vs Browser Implementers

Adrian,

     Help us understand where this is coming from. I understand that 
equipment vendors already need to parse SDP (which is essentially just a 
bunch of key-value pairs) but clearly WebRTC requires them to modify 
their parsing engine as we're introducing new keys and values. So two 
points here:

 1. One option is to replace SDP with an equally-simple mechanism.
 2. Another option is to replace SDP inside WebRTC and ask equipment
    vendors to use a gateway which will convert to SDP. This kind of
    conversion would be very cheap (as compared to a media gateway which
    is very expensive).

     If you could explain (or point to documents that do) the drive 
behind using SDP then it would help us moving forward. We should focus 
on *what* we're trying to accomplish, not *how*.

Thanks,
Gili

On 02/07/2013 9:06 AM, Adrian Georgescu wrote:
> SDP is here to stay for the benefits of network equipment vendors, 
> end-users be damned. Which part of this you do not get?
>
> Stop complaining about SDP usage in WebRTC, it is a lost cause.
>
> Regards,
> Adrian
>
>
> On Jun 29, 2013, at 9:15 AM, piranna@gmail.com 
> <mailto:piranna@gmail.com> wrote:
>
>> 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 
>> <mailto: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 <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:
>>>
>