- From: Taylor Brandstetter via GitHub <sysbot+gh@w3.org>
- Date: Thu, 13 Jul 2017 17:50:22 +0000
- To: public-webrtc-logs@w3.org
Let me clarify. There are two classes of use cases I see for `offerToReceive`: 1. The endpoint wants to offer to receive media, but doesn't have media to send. `offerToReceive` is the only way to force audio/video m= sections to be generated in this case. 2. The endpoint wants to manipulate the direction attribute of the "m=" section, because it's dealing with a SIP endpoint. 1 is something I'd expect almost _every_ sufficiently robust application to be using; if the endpoint doesn't have a webcam, it probably still wants to be able to receive video. In the call where we decided to add `offerToReceive` to the legacy section, this was the motivation. 2 is more corner casey, and we could tell these applications "use the transceiver API". Supporting use cases that involve SIP endpoints is why we introduced the transceiver API in the first place... -- GitHub Notification of comment by taylor-b Please view or discuss this issue at https://github.com/w3c/webrtc-pc/pull/1466#issuecomment-315152732 using your GitHub account
Received on Thursday, 13 July 2017 17:50:28 UTC