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

["Matthew Kaufman (SKYPE)" <[e-mail]>]

All of what you say below is true, but this is entirely backwards from how web page authors are supposed to interact with the browser.

Imagine if displaying JPEG images in the page were equally possible, if you wanted to munge a bunch of strings, but otherwise you were out of luck.

Matthew Kaufman

(Sent from my iPhone)

On Jun 19, 2013, at 9:41 AM, "Peter Thatcher" <[e-mail]<mailto:[e-mail]>> wrote:




On Wed, Jun 19, 2013 at 9:10 AM, Iñaki Baz Castillo <[e-mail]<mailto:[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]<mailto:[e-mail]>>

_______________________________________________
rtcweb mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/rtcweb