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

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

On Wed, 7 Nov 2018 at 08:40, Stefan Håkansson LK
<[e-mail]> wrote:
> If this now has changed, and we can have the simulcast receiver send an
> SDP offer that is applied in the browser and things work (perhaps with
> some web app intervention), and we have people interested in
> implementing this, I personally see no reason why that should not be
> pursued.

On of the problems in SDP O/A is the fact that the remote can decide
what the local side should send or stop sending by just sending a blob
to it (a SDP offer or answer), a blob that, due its nature, cannot be
"intercepted" by the JS in the local app to anticipate what it
involves (it's the other way around: first apply whichever unknown
blob you have received from the remote, then realize of what happened
via inspection or via contextless events).

This model is typically argued as a way to get interoperability in
codecs and RTP parameters. But this discussion is going further, since
here we are saying that the remote can send us a blob (that the app
does not know in advance what it means) and enable simulcast in local
side.

In ORTC the remote does NEVER decide what we can send or how we send
it. Assuming capabilities have been exchanged, it's up to the custom
app logic to decide what a peer sends and how it sends that. If you
want to stop receiving the remote video you send a custom JSON to the
server or remote app requesting that. That's friendly. Sending a
secret blob which cannot be managed via JS by the receiver is not
friendly.

So, I want to assume that WebRTC NG will drop SDP and, if so, IMHO it
does not make sense that efforts are spent now in a feature that makes
the dependency on SDP O/A even stronger.

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