- From: Harald Alvestrand <harald@alvestrand.no>
- Date: Tue, 19 Feb 2013 12:34:42 +0100
- To: public-webrtc@w3.org
On 02/19/2013 11:03 AM, Adam Bergkvist wrote: > I did indeed hit the wrong reply button. > > On 2013-02-18 19:26, Martin Thomson wrote: >> That's a good thing. They either reject video outright; or if they >> have local video, they get a=sendonly in their offer or answer. Setting this to false is indeed an important use case for the people who are building audio-only applications, but are interworking with stuff that uses both audio and video. >> >> (Did you intend to send this off-list?) >> >> On 18 February 2013 00:56, Adam Bergkvist >> <adam.bergkvist@ericsson.com> wrote: >>> On 2013-02-14 23:01, Martin Thomson wrote: >>>> >>>> On 14 February 2013 13:39, Harald Alvestrand <harald@alvestrand.no> >>>> wrote: >>>>> >>>>> OfferToReceiveVideo >>>> >>>> >>>> It does say "offer". I always read that into the meaning. >>>> >>>>> Suggested rephrase: >>>>> >>>>> "The default is a non mandatory "true" for an RTCPeerConnection >>>>> that has >>>>> a >>>>> video track in one of its local streams, or has video in either its >>>>> LocalDescription or RemoteDescription, and a non mandatory "false" >>>>> otherwise" >>>> >>>> >>>> I think that's good. "ReceiveVideo" might be a good rename to >>>> accompany this change. >>> >>> >>> What happens if a developer sets this to "false" when it was "true" by >>> default? People might do that. >>> >>> /Adam > >
Received on Tuesday, 19 February 2013 11:35:11 UTC