Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened

I put some comments inline, but I'd like to offer a few suggestinos to all
of those in the "SDP Rebellion" fighting the "SDP Empire":

- A clear, succinct description of what you need and why is a lot more
useful and will lead to more progress than long rants about what you hate
an why.

- The WG usually likes use cases.  Do you have any real world uses cases
that the current API doesn't provider, or that makes painful?

- It would be helpful to minimize the diff to the current API that you
need.  Saying "blow up everything and do it how I want" is hard do swallow
(witness comment 22).  Saying "here's a small change that would relieve a
lot of pain" might make more progress (although even not's clear if even
that's possible).

On Wed, Jun 19, 2013 at 1:38 AM, Iñaki Baz Castillo <ibc@aliax.net> wrote:

> 2013/6/19 Christer Holmberg <christer.holmberg@ericsson.com>:
> > We need to be very clear what we talk about, or some people are always
> going
> > to be confused :)
> >
> > So, AFAIK, the discussion is about SDP O/A usage in the API, only in the
> > API, and nowhere but the API.
> >
> > Whatever people us on the wire is outside the scope.
>
>
> Hi Christer,
>
> I do not dare to summarize what we request in a single response, and I
> don't want to say something that "I didn't want to say" ;)
>
> IMHO this thread clearly describes what we request, i.e. in these exact
> mails:
>
> - http://www.ietf.org/mail-archive/web/rtcweb/current/msg07895.html
> - http://www.ietf.org/mail-archive/web/rtcweb/current/msg07896.html
> - http://www.ietf.org/mail-archive/web/rtcweb/current/msg07899.html
>
>
> My "non-normative" summary:
>
> I don't think that the discussion is just about "SDP O/A usage in the
> API". We don't want a replacement for SDP, nor a new representation of
> SDP, nor to deal with blob strings between the JS layer and the WebRTC
> layer.

Please at least agree with Christer that this is about the API, not about
the signalling wire format.  The API already allows whatever signalling
wire format you want, and everything you mention from here on out is just
the API.  So please just say to Christer "yes, this is all about the API".
 It will make the rest of the discussion much more clear.

> In short we want something like a JS wrapper of the native
> WebRTC API,

I work on the WebRTC implementation in Chrome, and I don't know what you
mean by "native WebRTC API".  Such a thing does not really exist.  The
implementation has three different layers of abstraction, each of which you
might be referring to, but none of them which will give you what you want.
 The highest level uses SDP.  The lowest level gives you media bits, but no
ICE, SRTP, DTLS, or SCTP.  The middle layer gives you all those things
without SDP, but it still uses an abstract offer/answer for transport and
RTP setup (and even has a Jingle implementation on top of that).  None of
those give you what you want.  The "native WebRTC API" that you want to
wrap doesn't exist.

to directly manage media/transport parameters and media
> streams without having to pass a monolithic and unmanageable SDP blob
> between the JS and the WebRTC layer.

That boils down to "the same power of the current API, without going
through SDP".  I think that's a clear requirement.  So why don't you just
say that?  Would save everyone a lot of reading and misunderstanding.

calls to get the required media parameters, the JS can send them to
> the remote peer in the way it prefers (which may be via a SDP created
> by the JS app, or via an AJAX request for sending codecs/media-types
> info followed by a WebSocket connection for sending ICE candidates one
> by one, or serialized in JSON via a previously open DataChannel
> session... or whatever mechanism available in the Web and browsers).
>
>
You already have that.

> For sure, other participants in this thread can improve/fix my "summary".
>
> Please. re-read the 3 links above, IMHO they should clearly describe
> what we are requesting for :)
>
>
> Best regards.
>
>
>
> --
> Iñaki Baz Castillo
> <ibc@aliax.net>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>