W3C home > Mailing lists > Public > public-webrtc@w3.org > April 2017

Re: Why is offerToReceiveAudio boolean again?

From: Taylor Brandstetter <deadbeef@google.com>
Date: Tue, 18 Apr 2017 15:45:52 -0700
Message-ID: <CAK35n0a6YiaOUCEYeN3S2+YV2pYSdM6_TeV7CJkPwa5qZiucwQ@mail.gmail.com>
To: Philipp Hancke <fippo@goodadvice.pages.de>
Cc: public-webrtc@w3.org
It doesn't prohibit that, but as currently specified it wouldn't do
anything. Only "non-false values" have an effect; "In all other situations,
it will be disregarded."

On Tue, Apr 18, 2017 at 1:20 PM, Philipp Hancke <fippo@goodadvice.pages.de>
wrote:

>
>
> Am 18.04.2017 um 00:12 schrieb Taylor Brandstetter:
>
>> As I recall, this decision was made because it's only being kept around as
>> a "legacy interface extension", and a boolean is all Chrome implemented.
>> So
>> it wasn't worth the effort to specify more complex behavior (which used to
>> be described in JSEP, before things became transceiver-based).
>>
>
> does the spec prohibit this?
>         pc.addTrack(someaudiotrack)
>         pc.addTrack(anotheraudiotrack)
>         pc.createOffer({offerToReceiveAudio: false})
>
> It seems that without the legacy addStream API this legacy interface
> extension makes little sense since if one uses addTrack one can set the
> direction of the transceiver.
>
>
Received on Tuesday, 18 April 2017 22:46:25 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:50 UTC