881236 - Can't display video when no audio device is enabled in a WebRTC peer connection

Status: RESOLVED FIXED

(Core :: WebRTC: Audio/Video, defect)

Description

[Peter Nagy]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:23.0) Gecko/20130610 Firefox/23.0 (Nightly/Aurora)
Build ID: 20130610004016

Steps to reproduce:

1. Started a WebRTC video call on https://apprtc.appspot.com/
2. Joined to the meeting with an other participant with only video allowed


Actual results:

After the connection was established no video was displayed at the first participant.


Expected results:

Video was displaying without audio.

Comment 1

[Jason Smith [:jsmith]]

This isn't a WebRTC bug - it's a bug in the apprtc app itself. Apprtc currently requires that both peers use audio/video together at all times or the call will fail per the media constraints specified here:

http://code.google.com/p/webrtc-samples/source/browse/trunk/apprtc/index.html#120

So if one peer only grants access to video, but not audio, the call will fail since the mandatory constraints specified are not met. I double checked that my test app works which doesn't specify these constraints - it appears to work with one odd unrelated UI bug in Desktop Firefox. 

On that regard, I'm closing this as invalid.

Comment 2

[Jason Smith [:jsmith]]

Actually, my analysis above wasn't entirely correct after talking with Adam, although my claim that this is an apprtc bug is still valid. We're getting a JS error when this happens in their code, halting execution:

[09:51:48.405] ReferenceError: event is not defined @ https://apprtc.appspot.com/js/main.js:431

Comment 3

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

I've seen that ReferenceError while apprtc was working. It seems to complain about a keyboard event, and I doubt it is related to AppRTC not working recently.

Comment 4

[Jason Smith [:jsmith]]

Okay, let's keep this open this for more investigation.

FWIW though, I can reproduce this on apprtc on my own machine, but I can't reproduce this on my test app that does something similar to apprtc.

Comment 5

[Jason Smith [:jsmith]]

Too late to fix this on beta, but I did confirm this bug on my machine.

Comment 6

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

Ctangira says he can reproduce this on apprtc as well as with his own app. Myself I'm having trouble making a baseline LAN call with apprtc on Nightly today so I'm unable to confirm.

Note when talking about this that constraints and permissions are different: Constraints are set by the webpage, permissions are set by the user.

Perhaps due to this confusion, I just found the related but different Bug 917980.

Comment 7

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

If neither side allows audio, it appears not to connect.  If one side does, one side appears to connect and the other hangs in "Initializing" on apprtc, but audio does flow in one direction.  This was just a very fast test using two tabs in one browser.  I didn't investigate why or any errors or warnings

Comment 8

[Charith Tangirala]

Found the root cause and here's what's happening in theory:

If Client_1 allows both video and audio, it expects both video and audio from the peer.

Client_1: Start webrtc app and allows both Audio & Video. Creates new room, 0
Server_1: Sets the mExpectedTracks in DOMMediaStream to 0011 (because Client_1 is streaming both A and V).
Client_2: Start webrtc app and allows only Video. Joins existing room = 0.
Server_1: Client_2 starts to send media tracks (only video in this case). So it keep waiting for audio track and never    sends the onaddstream callback.

mExpectedTracks get set here:
http://mxr.mozilla.org/mozilla-central/source/dom/media/MediaManager.h#297
Waits for expected tracks here:
http://mxr.mozilla.org/mozilla-central/source/content/media/DOMMediaStream.cpp#332

Comment 9

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

Ok.  To re-create with pc_test.html:

1. uncheck Use Fake Audio/Video
2. Start
3. Agree to audio+video for the first side
4. Agree to video only for the second.

In the 2nd-side-to-1st-side (local image on left, large image on right) the local image will show, but the remote (large) image will not.

Comment 10

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

ctangira: thanks for tracking this down

I think the problem is that gsmsdp_add_remote_track() is setting audio+video as hints, but we're actually only expecting to receive video and should know this from the SDP negotiation (i.e. the other side set port=0 to reject or set recvonly in response to our sendrecv offer.)  gsmsdp_negotiate_media_lines() knows that the direction is SENDONLY and direction_supported is SENDRECV, so it should know we're not going to get a remote stream for this m= line.

Comment 12

[Robert O'Callahan (:roc) (email my personal email if necessary)]

We should ideally set the expected track types here:
http://lxr.mozilla.org/mozilla-central/source/media/webrtc/signaling/src/peerconnection/PeerConnectionImpl.cpp#400
Do we not know the types at this point?

Comment 13

[Robert O'Callahan (:roc) (email my personal email if necessary)]

If you know the track types there, you should call SetExpectedTracks with the right types before adding the callback.

If you don't know the track types yet there, you should move the callback-adding code to a later point where you do know the types.

Comment 14

[guigs [:guigs] PST (please needinfo me!)]

Is there a priority for this bug?

Comment 15

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

We killed hints...