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

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

Stefan Håkansson LK:
>
> I agree to the above - signaling is entirely up to the application. I'm sorry if my
> message gave another impression. But we need to define the format of the
> "blobs" (if we call them that) that browser A produces so that they can be
> plumbed into browser B and things work. 

No we don't. In fact that is exactly what we should mean when we say "signaling is entirely up to the application".

There is no reason why Browser A must produce something a serialized blob that can be stuffed directly into an API at Browser B. And in fact, doing so means that your two browsers are very likely doing things you don't expect... because instead of your JavaScript application saying "do this" to each, it is saying "do whatever this blob that was generated by code I don't control *means to you* (even if that meaning is subtly different than what it meant to the sender)". And then if you want to influence that you have either the pointy sticks called constraints or editing of the blob as your only remaining avenues of control.

Worse, because this now carries the explicit assumption that the two browsers are negotiating directly between each other's code (and really *not* expecting anything in the middle to mess with those blobs), you need a whole set of semantics on top of this to ensure that the browsers converge on something that works without their JavaScript app helping them. That brings in RFC3264-style Offer/Answer (which is not the only way to do it, but the one that was chosen). This then means that if you instead are trying to use the "blob" interface for direct manipulation, you are fighting against what may be an entirely incompatible state machine inside the browser.

> So far the assumption has been
> that those blobs are SDP descriptions, and my point is that changing that to
> something else may cost us more than we gain.

We need to provide the browser with an *API*. And that API should allow the JavaScript developer to directly influence what is happening. Preferably without the browser fighting its developer by trying to run the offer-answer state machine itself. Getting hung up on being able to pass blobs back and forth is now and has always been the whole problem.

Matthew Kaufman