New issue
Advanced search Search tips
Note: Color blocks (like █ or █) mean that a user may not be available. Tooltip shows the reason.

Issue 720543 link

Starred by 3 users
Status: Assigned
Owner:
hbos@chromium.org
Cc:
█ deadbeef@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug

Blocked on:
issue 799030


Sign in to add a comment

offerToReceiveAudio/offerToReceiveVideo not working for createAnswer

Project Member Reported by deadbeef@chromium.org, May 10 2017 
Without the transceiver API, these are the only ways to force a "sendonly" or "inactive" answer without SDP munging.

It appears they're just neglected by ConvertAnswerOptionsToWebrtcAnswerOptions.

Comment 1 by deadbeef@chromium.org, May 10 2017

Cc: deadbeef@chromium.org
Owner: ----
Status: Untriaged (was: Started)
Oh, they're also not stored in blink::WebRTCAnswerOptions. So this is a slightly larger change than I thought.

You could also make the argument that we shouldn't expose this functionality in Chrome since it's nonstandard; the standard says that only "true" values for offerToReceiveAudio/offerToReceiveVideo should have an effect: https://www.w3.org/TR/webrtc/#dom-rtcofferoptions-offertoreceiveaudio

Comment 2 by guidou@chromium.org, May 12 2017

Owner: guidou@chromium.org
Status: Assigned (was: Untriaged)

Comment 3 by guidou@chromium.org, Mar 14 2018

Owner: hbos@chromium.org

Comment 4 by hbos@chromium.org, Mar 14 2018 

So this is obsolete when we have Unified Plan?

Comment 5 by deadbeef@chromium.org, Mar 14 2018 

Correct. With Unified Plan you can change the direction through RTCRtpTransceiver.direction.

Comment 6 by hbos@chromium.org, Mar 15 2018

Blockedon: 799030
►

Sign in to add a comment