1035067 - Webrtc call between FF video+audio enabled user to a FF audio only user results in one way speech path

Status: VERIFIED FIXED

(Core :: WebRTC, defect, P2)

Description

[rajkumaradass]

Attachment: [e-mail]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.153 Safari/537.36

Steps to reproduce:

Below is the setup

FF(video+audio enabled) user calls to audio only FF user - results in one way speech path. i.e., The user who has video enabled, does not hear anything from the other side. There's a Gateway involved in this case for signaling as well transcoding. Attached the Offer and answer done on the originating firefox browser. It appears that the audio packets are being received at theoriginating FF user, but it doesn't process and play it. 


Actual results:

 The user who has video enabled, does not hear anything from the other side.


Expected results:

Both way speech path should be there.

Comment 1

[rajkumaradass]

Attachment: ff_log.txt

about:webrtc log capture for this usecase

Comment 2

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

Confirmed with talky.io

Strongly suspect this is due to the ExpectedTracks stuff used to fire onaddstream once all expected tracks are available.

Comment 3

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

Attachment: Don't hint we expect a track if we're not going to receive it

tested and works in basic conditions of offerer has A+V, answerer has A, V, or A+V.  Also tested data_test.html on webrtc_landing (no media streams).

Comment 4

[Ethan Hugg [:ehugg]]

Comment on attachment 8451658 [details] [diff] [review]
Don't hint we expect a track if we're not going to receive it

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

lgtm

Comment 5

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

https://hg.mozilla.org/integration/mozilla-inbound/rev/667abb03c123

Comment 6

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

I've tested, but we'll want verification that the various combinations of 1/2-way audio/video work.  I used talky.io as my testbed, but (some) others should work.  Some may not work for tests, like TokBox or Loop (1-way connections for everything).

Comment 7

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

 rajkumaradass - can you try this fix?  If you're not set up for making builds, you can download tomorrow's Nightly (2014/7/7), or any (green) build made today after ~3pm EDT/noon PDT on https://tbpl.mozilla.org/?tree=Mozilla-Inbound (click on the green 'B' for the type of build you want, go to the build directory, download and install it).

Comment 8

[Nils Ohlmeier [:drno]]

We also should add a test to mochitest for this.

Comment 9

[rajkumaradass]

Thanks, Jesup. 
I shall test with nightly build and let us know the results further.

Comment 10

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

Note: it didn't make the 7/8 nightly (no uplift from inbound to mozilla-central was done, it appears), so you'll have to wait for 7/9 nightly, or use a build downloaded from tbpl-inbound.

Comment 11

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/667abb03c123

Comment 12

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

Comment on attachment 8451658 [details] [diff] [review]
Don't hint we expect a track if we're not going to receive it

Missed asking for Aurora/32 uplift before we switched to 34.

Approval Request Comment
[Feature/regressing bug #]: N/A (forever)

[User impact if declined]: Answers audio-only (or video-only) won't connect properly).  Especially a problem if the receiver has no camera.

[Describe test coverage new/current, TBPL]: no special coverage.  Will look at adding a set of tests for asymmetric answers and uplifting it.  Hand-tested, and in the tree for a month.

I'd be ok with holding approval or making it contingent on added a test

[Risks and why]: Extremely low given the change

[String/UUID change made/needed]: none

Comment 13

[Lawrence Mandel [:lmandel] (use needinfo)]

Comment on attachment 8451658 [details] [diff] [review]
Don't hint we expect a track if we're not going to receive it

I'm going to approve for beta without the tests. As stated, this has been on m-c for 3-4 weeks. We'll get this into beta4, which will give us suitable time for a backout or fix if necessary. I would like to see the tests uplifted, preferably sooner than later so that we don't drop testing for this no video case.

Comment 14

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-beta/rev/b7316976ca8b

Comment 15

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/b7316976ca8b

Comment 16

[Paul Silaghi, QA [:pauly]]

Reproduced in Nightly 2014-07-07 on http://apprtc.webrtc.org/
Verified fixed FF 32b5.
Tested audio+video/audio, audio+video/video, audio/audio, video/video, audio/video.

Comment 17

[Paul Silaghi, QA [:pauly]]

Verified fixed FF 33b7 on http://talky.io/