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

[Eric Rescorla <[e-mail]>]

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.

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