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

[Peter Thatcher <[e-mail]>]

On Wed, Jun 19, 2013 at 9:10 AM, Iñaki Baz Castillo <[e-mail]> wrote:

> Hi Peter, for now just some comments (I agree that more use cases and
> other considerations must be provided):
>
>
>
>
> >> 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,
>
>
> IMHO that is not entirely true.
>
> First of all, whichever the signaling protocol is, it must accomplish
> with SDP O/A semantics (since it must carry a SDP and receive a SDP to
> establish the communication).
>

API calls must use the SDP O/A, but what goes on the wire doesn't have to
be.  With enough SDP hackery, you can do whatever you want over the wire,
including not use O/A semantics.


>
> Second: Indeed the current spec does not mandate what should be sent
> in the wire. In practice that means we can use SIP over WebSocket,
> XMPP/Jingle over HTTP, or whatever. But in practice it also means that
> we must send a SDP in the wire. The SDP blob string can be
> hex-encoded/escaped/mangled/whatever by the JS app, but the SDP blob
> string generated by PeerConnection-A should arrive to
> PeerConnection-B.


A sufficiently smart chunk of JS could call
setLocalDescription/setRemoteDescription with SDP that it completely
created itself, and send whatever it wants over the wire.


> And since such a SDP is generated by the WebRTC
> stack and passed to the JS as an unmanageable blob string, the JS app
> cannot properly deal with it.
>

The JS parse the SDP from createOffer/createAnswer, get the info it needs,
make decisions and then serialize different SDP back down in
setLocalDescription/setRemoteDescription.  It's terribly ugly, but it works.


> So, currently WebRTC does not mandate the signaling protocol
> in-the-wire, but it does mandate the media signaling protocol
> in-the-wire (you need to pass a working SDP to the remote, sure),
> something that constrains the signaling protocol itself.
>

It does not mandate SDP over the wire.  It's possible to write a JS app
that gets everything working with no SDP on the wire.  It's anything but
pretty, but it works.




> 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.

> Ok, this is all about the API :)

>> 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.

> Ok, IMHO nobody is still requesting a specific JS API but just
> describing the features and capabilities such an API must provide. The
> "similar to native WebRTC API" is just a comment to help understanding
> what we mean, but of course each browser is free to implement its
> native API(s) as it prefers so the "JS wrapper" concept does not make
> sense.

But you can't say "similar to native WebRTC API" because no such thing
exists.  You can't be similar to something that 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.

> You are right.



>> 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.

> Can I first send my codecs list, then (once the peer notifies me
> codecs compatibility) send the codecs preference order, then my ICE
> candidates and later (not just when ICE process terminates) signal the
> peer a "OK" message so we both start the multimedia audio/video/data
> communication, all of this with the current API?

I think so, yes.

> (I mean without parsing the SDP blob and splitting it into blob
fragments).

Maybe... I don't know for sure.  But generally, anything beyond the most
basic uses of the API requires at least some SDP hackery, and advanced uses
require a lot.


Best regards.




--
Iñaki Baz Castillo
<[e-mail]>