1009644 - webRTC call fails to establish on /apprtc.appspot.com. one peer has video, other does not

Status: RESOLVED DUPLICATE of bug 998546

(Core :: WebRTC: Networking, defect)

Description

[Brent]

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/34.0.1847.116 Chrome/34.0.1847.116 Safari/537.36

Steps to reproduce:

Using Firefox 29 for Peer 1 and Firefox 28 for Peer 2

Peer 1: connects to https://apprtc.appspot.com/?r=123
Shares camera with page
Peer 2: connects to https://apprtc.appspot.com/?r=123
Selects, no camera


Actual results:

Peer 1: Connecting... bar appears at bottom of page, never updates to Hang up
Peer 2: Connecting ... changes to Hang up button. Displays video from Peer 1


Expected results:

Peer 1 to complete webRTC connecting to Peer 2

Comment 1

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

OS for each?  Also, 28 is now one rev behind Release.

Most likely it's a network/NAT issue.

Can you get about:webrtc logs from both ends, including the logs at the bottom of the page?  (click to show the logs, then right-click - Select All, paste into a file and attach here?  (I'm not sure 28 had very good logging of this, though.)

Also, if you could try either Aurora/31 or Nightly/32 that would help, as we made some important fixes to TURN and ICE support recently.

Thanks

Comment 2

[Brent]

Attachment: Logs from Peer1

Comment 3

[Brent]

Attachment: peer2.logs

Comment 4

[Brent]

Both peers are running on Ubuntu 12.04

I'm not aware of any network setup that could cause the issue. And I am working with webRTC quite frequently at the moment.

Duplicating the scenario within my own application it seems that offerToReceiveVideo and offerToReceiveAudio has to match the added stream (even if both are set to true.)

When Peer 2 has both set to true, but receives a stream without video from peer 1, the onaddstream event is not fired.

I've attached the logs from apprtc.appspot.com

Comment 5

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

Aha.  That's a known issue with onaddstream when denying video.  I'll see if I can dig up the bug #

Comment 6

[Brent]

Hi - a bug number would be very helpful. 

I've done a bit more testing through various scenarios, so perhaps I can add some extra information for the investigation.

I tested a few different combinations of caller / callee with audio and with / without video, and came up with

#	Caller	Callee	Works?
a	Chrome (no video) 	Chrome (no video) 	works
			
bi	Chrome (video) 	Chrome (no video) 	 works
bii	Chrome (no video)	Chrome (video) 	 works
			
ci	FF (no video)  	FF (no video) 	works - with "dynamic" OfferToReceive
			
di	FF (no video)  	FF (video) 	does not work;
dii	FF (video)  	FF (no video) 	works
			
ei	Chrome (video)	ff (video)	works
eii	ff (video)	Chrome (video)	worksFor reference I 
			
There might be another issue here as chrome does not see FF video streams for some reason
fi	Chrome (no video) 	FF (video)     	does not work, in odd ways 
fii	FF (video) 	Chrome (no video)     	does not work;
			
gi	Chrome (video) 	FF (no video)     	works
gii	FF (no video) 	Chrome (video)	works
			
hi	Chrome (no video) 	ff (no video) 	works
hii	ff (no video) 	Chrome (no video) 	works

Comment 7

[Brent]

Bug #998546 is the related bug