Re: Teleco Integrators vs Web Developers vs Browser Implementers

On Tue, Jul 2, 2013 at 7:14 AM, cowwoc <cowwoc@bbs.darktech.org> wrote:

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


This seems incorrect in at least two respects:

1. The SDP mechanisms are enhancements motivated by WebRTC, so
they are designed to be backward compatible (though obviously older
peers won't get any benefit). So, equipment vendors aren't required
to modify their endpoints in order to get any interop and the new
feature adds can be done incrementally.

2. Most of the work (BUNDLE, trickle, etc.) is generally applicable
improvements, so the vendors are going to want to make these
improvements anyway, even for non-WebRTC systems.


Conversely, even if we were to discard SDP entirely at the interface to
WebRTC, we would still need to specify SDP representations of these
concepts in order to allow sensible interop of these features with SDP-using
systems on the other end. For instance, if WebRTC implementations are
to use trickle ICE and get that when they interoperate with SIP systems,
then trickle ICE needs to be added to SDP.

-Ekr








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