- From: Bernard Aboba <Bernard.Aboba@microsoft.com>
- Date: Fri, 14 Apr 2017 21:08:42 +0000
- To: Peter Thatcher <pthatcher@google.com>, Iņaki Baz Castillo <ibc@aliax.net>, "public-webrtc@w3.org" <public-webrtc@w3.org>
Peter said:
"The simulcast solution we were able to fit into the 1.0 time frame was specifically designed such that the browser/client can offer simulcast, but not (necessarily) answer a simulcast offer."
[BA] Here is what JSEP Section 6.2 says:
" In addition, JSEP does not provide a mechanism to handle an incoming
offer requesting simulcast from the JSEP endpoint. This means that
established simulcast streams will continue to work through a
received re-offer, but setting up initial simulcast by way of a
received offer requires out-of-band signaling or SDP inspection.
Future versions of this specification may add additional APIs to
provide direct control."
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()
...
Received on Friday, 14 April 2017 21:09:16 UTC