Closed Bug 1035067 Opened 5 years ago Closed 5 years ago

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

Categories

(Core :: WebRTC, defect, P2, major)

32 Branch
defect

Tracking

()

VERIFIED FIXED
mozilla33
Tracking Status
firefox30 --- wontfix
firefox31 --- wontfix
firefox32 --- verified
firefox33 --- verified
firefox-esr24 --- wontfix
b2g-v2.0 --- fixed
b2g-v2.1 --- fixed

People

(Reporter: rajkumaradass, Assigned: jesup, NeedInfo)

Details

Attachments

(3 files)

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.
Attached file ff_log.txt
about:webrtc log capture for this usecase
Severity: normal → major
Priority: -- → P2
Whiteboard: Webrtc call between FF video+audio enabled user to a FF audio only user results in one way speech path
Confirmed with talky.io

Strongly suspect this is due to the ExpectedTracks stuff used to fire onaddstream once all expected tracks are available.
Assignee: nobody → rjesup
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
OS: Windows 7 → All
Hardware: x86_64 → All
Whiteboard: Webrtc call between FF video+audio enabled user to a FF audio only user results in one way speech path → [webrtc-uplift]
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).
Attachment #8451658 - Flags: review?(ethanhugg)
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
Attachment #8451658 - Flags: review?(ethanhugg) → review+
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).
Keywords: qawanted
 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).
Flags: needinfo?(rajkumaradass)
We also should add a test to mochitest for this.
QA Contact: drno
Thanks, Jesup. 
I shall test with nightly build and let us know the results further.
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.
https://hg.mozilla.org/mozilla-central/rev/667abb03c123
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
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
Attachment #8451658 - Flags: approval-mozilla-beta?
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.
Attachment #8451658 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
QA Whiteboard: [qa+]
Keywords: verifyme
Whiteboard: [webrtc-uplift]
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.
Verified fixed FF 33b7 on http://talky.io/
Status: RESOLVED → VERIFIED
QA Whiteboard: [qa+]
Flags: qe-verify+
Keywords: verifyme
You need to log in before you can comment on or make changes to this bug.