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

[Stefan Håkansson LK <[e-mail]>]

On ons, 2018-11-07 at 12:34 +0100, Iñaki Baz Castillo wrote:
> 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. 

I will not defend SDP in any way, but I think that even in 1.0 the
remote end has no control on _what_ is sent - it's the local app and
user (and user agent) that controls what input sources to use for track
data, and what tracks to send. 

An non inspected SDP offer/answer can influence _how_ it is sent, but I
think that is per design - no point in encoding with an encoder that
the remote can't decode etc.