Re: Why is offerToReceiveAudio boolean again?

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.
>
>