1285009 - offerToReceiveAudio and offerToReceiveVideo are ignored when renegotiating

Status: REOPENED

(Core :: WebRTC: Signaling, defect, P3)

Description

[u530816]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36

Steps to reproduce:

Start a webrtc call with audio and video flow in both directions (in other words, all sdp direction lines equal to "sendrecv".  Then, call createOffer with {offerToReceiveAudio: false, offerToReceiveVideo: true}

I'm using the current version of adapter.js, 1.4.0

I've confirmed the problem exists in Firefox 47 (current stable) and 49 (current developer edition).



Actual results:

The direction line for the audio section was "sendrecv" and the direction line for the video section was "sendrecv".


Expected results:

The direction line for the audio section should be "sendonly" and the direction line for the video section should be "sendrecv".

Comment 1

[u554753]

Hi iremmel,

Can you provide us with a test case?

Comment 2

[u554753]

Closing issue due to lack of response. If you feel this issue is still pertinent, please provide the requested info provided in Comment 1. Thanks!

Comment 3

[u530816]

Reopening as I now have a test case

https://gist.github.com/ianwremmel/72f7e1677901b486b30abdd01a91c44f

Currently reproduces in Firefox 52.0.2; test case passes in Chrome.

Comment 4

[Randell Jesup [:jesup] (needinfo me)]

FYI this is the bug paul mentioned

Comment 5

[Nils Ohlmeier [:drno]]

Looking at it...

Comment 6

[Nils Ohlmeier [:drno]]

Interestingly using the offerToReceiveAudio and offerToReceiveVideo with the value 'false' is not covered by the spec (https://www.w3.org/TR/webrtc/#configuration-data-extensions) at all:

  offerToReceiveAudio of type boolean

    When this is given a non-false value, no outgoing track of type "audio" is attached to the PeerConnection, and the existing localDescription (if any) doesn't contain any sendrecv or recv audio media sections, createOffer() will behave as if addTransceiver("audio") had been called once prior to the createOffer() call.

    In all other situations, it will be disregarded.


That sounds to me like we are suppose to ignore all 'false' values.

Comment 7

[Nils Ohlmeier [:drno]]

It looks like Transceivers will give you the desired flexibility to manipulate directions mid-call https://www.w3.org/TR/webrtc/#dom-rtcrtptransceiver-setdirection

As
- the spec does not cover the use case here to do the same via the createOffer options
- Firefox never support the use case of negotiating down an existing sendrecv stream
- we are actively working on adding support for Transceiver (bug 1290948)

I'm inclined to not put the effort in right now to change Firefox behavior, but instead wait for the Transceiver support.

Comment 8

[u530816]

So, is it safe to say that at this point, there's no way to reduce incoming bandwidth used?

Comment 9

[Nils Ohlmeier [:drno]]

(In reply to iremmel from comment #8)
> So, is it safe to say that at this point, there's no way to reduce incoming
> bandwidth used?

Well turning off the remote sender through a renegotiation seems like a pretty brutal solution to reduce bandwidth.
Normally I would expect RTCP to take care of scenarios where too much bandwidth appears to be consumed. Another option might be to use b=TIAS in a re-offer to restrict the remote side.

Comment 10

[u530816]

Fair enough. As a different example, how would you suggest transitioning an audio/video call to audio-only?

Comment 11

[Nils Ohlmeier [:drno]]

(In reply to iremmel from comment #10)
> Fair enough. As a different example, how would you suggest transitioning an
> audio/video call to audio-only?

removeTrack() would be one option.

BTW as this is not related to original bug report any more I think we should take this discussion to the dev-media mailing list instead.

Comment 12

[Cullen Jennings]

@Nils - do you think we need to open any bugs on the spec ?

Comment 13

[Nils Ohlmeier [:drno]]

(In reply to Cullen Jennings from comment #12)
> @Nils - do you think we need to open any bugs on the spec ?

If an endpoint doesn't have enough bandwidth we already have these options available:
- the video stream should scale back via RTCP feedback and changing resolution and/or frame rates
- you can remove your video track via removeTrack(), and then renegotiate to remove video completely to save bandwidth
- the new transceiver.setDirection() will allow you to turn off the remote video (Byron is working on Transceivers)

As I pointed out in comment #6 trying to accomplish this via offer constraints for established call is not covered. Which is probably because the offerToReceive constraints went from being integer to booleans. And permitting them to switch from true to false for a running call would just add another bullet point to the list above.

So I don't think that we need to fix the spec, except if we would want to more explicitly call out that using false in the offer constraints is not supported and you should use something from the things above to accomplish your goal.

Comment 14

[Bulk Bug Changes for mreavy's org]

Mass change P2->P3 to align with new Mozilla triage process.