WebRTC - offerToReceiveVideo option seemingly ignored if getUserMedia stream is only microphone

RESOLVED INVALID

Status

()

Core
WebRTC
RESOLVED INVALID
3 years ago
3 years ago

People

(Reporter: simon.tolham, Unassigned)

Tracking

33 Branch
x86_64
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

3 years ago
User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/37.0.2031.2 Safari/537.36

Steps to reproduce:

1) Only have microphone plugged in with no camera.
2) Call getUserMedia and get stream. This should only have a single audio track.
3) Add stream to peer connection.
4) Call createOffer on peer connection with following constraints:

{'mandatory': {
                      'offerToReceiveAudio': true,
                      'offerToReceiveVideo': true }

Also worth mentioning that with neither a microphone nor video camera then the generated SDP is correct - includes both m=audio and m=video lines.


Actual results:

Generated SDP does not contain m=video description:

v=0
o=Mozilla-SIPUA-33.0 23173 0 IN IP4 0.0.0.0
s=SIP Call
t=0 0
a=ice-ufrag:60d07af8
a=ice-pwd:510292bab47c00db1baf9278864c4f08
a=fingerprint:sha-256 C5:D5:40:FF:EF:71:F6:C5:BA:0F:C3:8E:C5:FB:E1:31:99:EE:7C:51:51:ED:93:36:10:14:D2:CC:78:EC:A0:AF
m=audio 54488 RTP/SAVPF 109 0 8 101
c=IN IP4 172.16.4.138
a=rtpmap:109 opus/48000/2
a=ptime:20
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=setup:actpass
a=candidate:0 1 UDP 2122252543 172.16.4.138 54488 typ host
a=candidate:0 2 UDP 2122252542 172.16.4.138 41007 typ host
a=rtcp-mux


Expected results:

SDP should contain additional m=video description (a=recvonly)
(Reporter)

Comment 1

3 years ago
Firefox user agent:
"Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:33.0) Gecko/20100101 Firefox/33.0"

Updated

3 years ago
Component: Untriaged → WebRTC
Product: Firefox → Core
(Reporter)

Comment 2

3 years ago
This has been seen a few times by our customers now - please can someone update / confirm that they are able to reproduce?
I modified pc_test.html to swap the createoffer constraints to true (from false), and if I start an audio-only call (checkbox), I see no m=video lines in the SDP.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(docfaraday)

Comment 4

3 years ago
Can reproduce on opentokrtc, but not talky.io (talky.io also uses datachannel, which may factor into it). $5 says this is a sipcc bug.
We need receive-only tests in the tree to cover this.
(In reply to Jan-Ivar Bruaroey [:jib] from comment #5)
> We need receive-only tests in the tree to cover this.

We do have recv-only tests in the tree: test_peerConnection_offerRequiresReceive*.html
But these tests are broken, because the answerer offer no media at all, so in the answer all m-lines get set to inactive. And we have a bug for that: bug 997572.

I did not touch bug 997572 recently, because bug 1091242 has a fix for the inactive part in it.
Depends on: 997572
Created attachment 8525022 [details] [diff] [review]
bug_1094258_test.patch

Here an initial test case which reproduces the problem.

Interestingly the problem only appears if 'mandatory' is used. If the recvonly options are passed in just as options everything works as expected.
(Reporter)

Comment 8

3 years ago
(In reply to Nils Ohlmeier [:drno] from comment #7)
> Interestingly the problem only appears if 'mandatory' is used. If the
> recvonly options are passed in just as options everything works as expected.
Thanks Nils. Please can you give an example of this workaround?
Summary: WebRTC - offerToReceiveVideo constraint seemingly ignored if getUserMedia stream is only microphone → WebRTC - offerToReceiveVideo option seemingly ignored if getUserMedia stream is only microphone
Comment on attachment 8525022 [details] [diff] [review]
bug_1094258_test.patch

Review of attachment 8525022 [details] [diff] [review]:
-----------------------------------------------------------------

::: dom/media/tests/mochitest/test_peerConnection_audioOnly_requireReceiveVideoAudio.html
@@ +21,5 @@
> +    test.setMediaConstraints([{audio: true, video: false}],
> +                             [{audio: true, video: true}]);
> +    test.setOfferOptions({'mandatory': {
> +      offerToReceiveVideo: true,
> +      offerToReceiveAudio: true

This is incorrect. You're tripping up on the recent spec change (see URL).

The old syntax was:

  { mandatory: { OfferToReceiveVideo: true, OfferToReceiveAudio: true }

The new syntax is:

  { offerToReceiveVideo: true, offerToReceiveAudio: true }

Notice the difference in case ('o' vs 'O') and the absence of mandatory.
(In reply to Jan-Ivar Bruaroey [:jib] from comment #9)
> This is incorrect. You're tripping up on the recent spec change (see URL).

Well this is exactly the syntax Simon reported initially in this bug.
 
> The old syntax was:
> 
>   { mandatory: { OfferToReceiveVideo: true, OfferToReceiveAudio: true }
> 
> The new syntax is:
> 
>   { offerToReceiveVideo: true, offerToReceiveAudio: true }
> 
> Notice the difference in case ('o' vs 'O') and the absence of mandatory.

So then this problem only appears if you combine old and new constraints.

I just verified that my test with the corrected constraints properly creates a SDP with m=video and recvonly in it.
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → WORKSFORME
(In reply to Nils Ohlmeier [:drno] from comment #10)
> Well this is exactly the syntax Simon reported initially in this bug.

Yes, I think this should be closed as invalid. We know what the problem was and it was pilot error.
Resolution: WORKSFORME → INVALID

Updated

3 years ago
Flags: needinfo?(docfaraday)
You need to log in before you can comment on or make changes to this bug.