Re: [rtcweb] Proposed Plan for Usage of SDP and RTP - Lower level API minus SDP

[Mary Barnes <[e-mail]>]

On Thu, Mar 7, 2013 at 12:42 PM, Eric Rescorla <[e-mail]> wrote:
>
> On Thu, Mar 7, 2013 at 9:56 AM, Mary Barnes <[e-mail]>
> wrote:
>>
>> On Thu, Mar 7, 2013 at 11:43 AM, Martin Thomson
>> <[e-mail]> wrote:
>> > Obviously I (and my employer) agree with these sentiments
>> > wholeheartedly.  Both Robin and Hadriel.
>> >
>> > That doesn't change the fact that a number of people are highly
>> > motivated to protect their investment in SDP offer/answer.  For those
>> > people, the pain that causes everyone else is clearly far less
>> > important than the pain they feel at this moment.  So here we are.
>>
>> [MB] I originally thought that either approach could work.  I did see
>> the value that folks saw in using SDP offer/answer. But after sitting
>> through the interim meeting last month, I am very much of the mindset
>> that using SDP O/A is a bad idea.   I think many of us thought that
>> using the SDP blob would help with interoperability with "legacy" SIP
>> endpoints.  I don't see that now at all.  I think we will end up with
>> a very fragile solution that will be very difficult to extend/modify
>> later if we continue down the SDP O/A path.
>> [/MB]
>>
>
> Hasn't the WG already been asked this question not once but
> twice.
[MB] Yes.  And, some of us have changed our positions based upon the
challenges that the group is facing in getting the current approach
specified and agreed.  I don't disagree that it is not a good thing
that this is being discussed yet again.  [/MB]
>
> 1. In Taipei:
> http://www.ietf.org/proceedings/82/minutes/rtcweb.txt
>
>   Cullen - we need to advise w3c on setting up a media stream.
>   - low-level API - browser implementors were not interested.
>   - mid-level - browser implements SDP negotiation
>   - high-level - browser implements a signal protocol (jingle)
>
>   Hardie - if you agree the state machine should be based on Offer/Answer,
> raise
>   your hand. Count: 31, 3 in jabber room.
>
>   If you do not agree, raise your hand.
>   Count: 4
>
>   Bernard - how can you ask this if you assume ICE, you need Offer/Answer.
>
>   Cullen - could rewrite ICE.
>
>   If there is not enough info, raise your hand
>   Count:  5
>
>   Hardie - Rough consensus in the room and jabber that we will base the
> state machine on SDP OA.
>
>
> 2. When we picked JSEP, which has SDP at its heart.
>
>
>
> And that's just the IETF WG. W3C *also* had a consensus call on
> exactly this point:
> http://lists.w3.org/Archives/Public/public-webrtc/2012Sep/0098.html.
>
> The consensus was for "Alternative 1":
>
>   1) Continue with a design based on the PeerConnection object, using SDP
>   as part of the API, roughly in the style of the current API description.
>
> This happened less than 6 months ago and it wasn't a close thing.
>
> Moreover, there are two shipping--and indeed
> interopable!--implementations (Chrome and Firefox) based on the
> PeerConnection/3264 OA design style (I'll get to Peter's comment about
> JSON in a separate message).
>
> Now, none of this is to say that the WG can't reconsider and come to a
> new decision, but I think that at given the number of times this point
> has been argued and reargued, the bar to that reconsideration has to
> be fairly high (and needs to be jointly taken in IETF and W3C)
> especially since this essentially amounts to a request to burn the
> entire W3C API and start over.
>
> -Ekr
>