Re: Teleco Integrators vs Web Developers vs Browser Implementers

Eric,

     Thanks for the clarification. Those are good points.

Gili

On 02/07/2013 10:38 AM, Eric Rescorla wrote:
>
>
>
> On Tue, Jul 2, 2013 at 7:14 AM, cowwoc <cowwoc@bbs.darktech.org 
> <mailto: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
>>     <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:
>>>>
>>
>
>