Re: Enabling simulcast in the answer

2017-04-14 23:08 GMT+02:00 Bernard Aboba <Bernard.Aboba@microsoft.com>:
> Based on the above, I would not expect the browser to create a simulcast-sending transceiver automatically as a result of calling setRemoteDescription().  Instead, I would expect the Promise to be rejected with an RTCError (hopefully one which will indicate what went wrong).
>
> Would it be helpful to provide more detail on the suggested workaround?  For example:
>          1. Application parses the Offer SDP.
>          2. Application calls addTransceiver(init) with sendEncodings based on the Offer SDP simulcast parameters.
>          3. Application calls createOffer() and setLocalDescription()

Well, testing right now with Firefox Nightly (note that Firefox still
implements draft simulcast 03):

1) The server sends an offer with a m=video a=recvonly containing:

  a=simulcast: recv rid=1,2
  a=rid:1 recv
  a=rid:2 recv

2) In Firefox, call setRemoteDescription(offer), then createAnswer(),
then mangle the generated SDP answer by adding:

  a=simulcast: send rid=1,2
  a=rid:1 send
  a=rid:2 send

3) Call setLocalDescription(answer) with the mangled answer.

It works :)

Firefox sends two streams with different SSRCs and the corresponding
RID extension.


I don't understand your steps above since, as I say, it's the server
the one generating the offer. May be you meant "3. Application calls
createAnswer() and setLocalDescription()"?

Anyhow, I've not yet played with transceivers so don't know how
Firefox would behave.


NOTE: Related issue (fixed in fact) reported in Firefox regarding
simulcast in received offer:

https://bugzilla.mozilla.org/show_bug.cgi?id=1344556

-- 
Iñaki Baz Castillo
<ibc@aliax.net>

Received on Friday, 14 April 2017 21:43:27 UTC