- From: Taylor Brandstetter via GitHub <sysbot+gh@w3.org>
- Date: Thu, 06 Apr 2017 21:53:17 +0000
- To: public-webrtc-logs@w3.org
The error handling part is what I was most worried about. Going through the error cases in https://github.com/w3c/webrtc-pc/issues/763, the only one that's really relevant is "too many simulcast encodings". For example, suppose the application calls `addTransceiver` with 3 simulcast encodings (as in the example above), and the browser only supports simulcast with VP8/VP9. 1. After the offer/answer exchange is done, H.264 and VP8 are negotiated, with H.264 having a higher priority in the remote description. What happens? I assume the implementation should choose VP8. 2. After the offer/answer exchange is done, *only* H.264 is negotiated. What happens? Is the SRD promise rejected? If so, how does the application recover? I'd suggest that we allow `RTCRtpSender.getParameters` and `setParameters` to be called before `setRemoteDescription`, so the application could turn off the extra encodings (set `active` to `false`) and call `setRemoteDescription` again. Assuming they get an `RTCError` somehow when the promise is rejected. Or, we could have the browser just automatically do this. But then the behavior of `addTransceiver` would be inconsistent with `setParameters`. -- GitHub Notification of comment by taylor-b Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/1073#issuecomment-292335156 using your GitHub account
Received on Thursday, 6 April 2017 21:53:23 UTC