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

[Erik Lagerway <[e-mail]>]

+1

We feel that a lower level API that does not include SDP, and a layer built
on top (perhaps in a JS library) to manage SDP + offer/answer would solve
this issue for everyone. That would ensure legacy compatibility and give us
future stuff we would know we are going to need.

http://lists.w3.org/Archives/Public/public-webrtc/2012Feb/0198.html <- btw,
this went nowhere in the W3C so it seems the buck stops here

/erik

*Erik Lagerway <http://ca.linkedin.com/in/lagerway> |
*Hookflash<http://hookflash.com>
* | 1 (855) Hookflash ext. 2 | Twitter <http://twitter.com/elagerway> | WebRTC
Blog <http://webrtc.is> *
****


On Thu, Mar 7, 2013 at 10:51 AM, Mary Barnes <[e-mail]>wrote:

> 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
> >
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>