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

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

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

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




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



>> 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 mean without parsing the SDP blob and splitting it into blob fragments).



Best regards.




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