Re: [rtcweb] JSEP question: How to set up simulcast for server-originated calls?

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

On Sun, 4 Nov 2018 at 09:13, Harald Alvestrand <[e-mail]> wrote:
> In WEBRTC, we have been grappling with the problem of simulcast setup,
> and it seems that we have no obvious API surface that can be used for
> this purpose - creating transceivers (as we do for outgoing) doesn't fit
> the bill, because incoming SDP causes transceivers to be created wihout
> interacting with the API surface.

That's the exact problem: the fact that media parameters are given to
the other party by sharing a blob that the receiver must consume
before it even knows what it contains and, once consumed, it must rely
on "events" fired out of context (cannot correlate the received SDP
blob and peerconnection/stream events generated after consuming it).

And worse, once such a SDP blob is received and blindly consumed,
"things" happen without app knowledge or consent. For example and as
said by Nils, Firefox can conform to simulcast settings on receipt of
a remote SDP offer, but if we think about it, it means that the remote
decides in behalf of us (we cannot decide how to send simulcast but,
instead, the remote can force us to send simulcast as it wishes (and
not how we wish) by just sending us a blob reoffer.

The problem is the SDP as "API surface" as it's been always. IMHO we
shouldn't waste more energies adding more hacks to the current API to
fight the SDP O/A nature and, instead, we should move to a SDP-less
specification ASAP in which the remote party cannot blindly mandate
the local peer what to send at any time.

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