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

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

On Mon, 5 Nov 2018 at 13:22, Sergio Garcia Murillo
<[e-mail]> wrote:
> Not sure if you are responding to  Harald or to me.  If it is to me, my
> "do nothing" proposal to enable simulcast when the offer is sent by the
> SFU (just in case anyone wants to do it):
>
> -SFU sends an offer with all the available streams/tracks (no simulcast
> m-line)
> -Browser reply with recvonly on all m-lines
> -Browsers reoffer with an additional m-line (sendonly?) with simulcast
> -SFU answers
>
> No change to the spec at the cost of an additional round trip. Note that
> this is almost the same case than if the browser sends and initial offer
> with simulcast, sfu answers with recvonly, and then re-offers with all
> the available streams/track.
>
> Also, note that many of SFU devs (at minimum Iñaki and me)  are not even
> sending SDP on the wire but doing renegotiations locally.

Ok, let me clarify:

Of course your approach would work, and also mine (signal server
desired recv simulcast by other means but SDP before the client
joins), but I strongly believe that people wishing to enable simulcast
in clients by just receiving an offer from the server is because they
have a fixed architecture in which the server sends the offer, expect
a "full featured" answer and that's all. Probably their servers do not
allow receiving reoffers from clients (you know the pain of managing
both send and recv streams within a single m= section when you want to
control sending/receiving codecs, etc).

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