965266 - WebRTC channel error

Status: RESOLVED INVALID

(Core :: WebRTC, defect)

Description

[Paul Silaghi, QA [:pauly]]

Attachment: webrtc error.bmp

Open https://apprtc.webrtc.org/
Actual results: Channel error

In browser console:
"This appears to be Firefox" adapter.js:17
"Initializing; room=02071959." main.js:34
"Opening channel." main.js:62
"Requested access to local media with mediaConstraints:
  '{"audio":true,"video":true}'" main.js:141
"Channel opened." main.js:285
"Channel error." main.js:321
1391007047089	Services.HealthReport.HealthReporter	WARN	Saved state file does not exist.

1391007047090	Services.HealthReport.HealthReporter	WARN	No prefs data found.

"User has granted access to local media." main.js:327
"Attaching media stream" adapter.js:69
Error in parsing value for 'width'.  Declaration dropped. apprtc.appspot.com
Error in parsing value for 'height'.  Declaration dropped. apprtc.appspot.com
Error in parsing value for 'left'.  Declaration dropped. apprtc.appspot.com
Error in parsing value for 'top'.  Declaration dropped. apprtc.appspot.com
"Channel error." main.js:321

Comment 1

[Paul Silaghi, QA [:pauly]]

Repro on Win 7, Ubuntu 12.04, Mac OS X 10.8.
This is also reproducible on Google Chrome and on older nightlies like 2013-11-26.
Could this be a site issue ?

Comment 2

[Paul Silaghi, QA [:pauly]]

Attachment: webrtc error.png

Comment 3

[Paul Silaghi, QA [:pauly]]

The strange part is I can't reproduce the problem on FF 26 release.

Comment 4

[Maire Reavy [:mreavy]]

This sounds like a site issue.  We added additional TURN functionality after Fx26, and these messages may be related to a broken TURN server or something.  The fact that Chrome is seeing the same problem is strong evidence that this is a site problem.

Ekr -- Do you want to reach out to the apprtc folks or would like me to?

Comment 5

[Eric Rescorla (:ekr)]

Generally a Channel Error is a problem with app-engine channels. I.e., not a WebRTC
issue, though perhaps a ffox issue.

Comment 6

[Maire Reavy [:mreavy]]

(In reply to Eric Rescorla (:ekr) from comment #5)
> Generally a Channel Error is a problem with app-engine channels. I.e., not a
> WebRTC
> issue, though perhaps a ffox issue.

Any idea why we'd be seeing in Chrome too?

Comment 7

[Eric Rescorla (:ekr)]

Google app engine channels are kind of a mess. So it could just be a bug in app engine.

Comment 8

[Maire Reavy [:mreavy]]

(In reply to Eric Rescorla (:ekr) from comment #7)
> Google app engine channels are kind of a mess. So it could just be a bug in
> app engine.

Since it's happening with both Chrome and Firefox, it seems like it's worth asking Justin.  Do you agree?

Comment 9

[Nils Ohlmeier [:drno]]

I just tried to reproduce between Nightly on MacOSX and (Stable or Nightly) on Windows 7, without any luck. My machines are on the same local network.
As the screenshot shows zero ICE candidates I'm wondering if this this gets triggered in/by certain network environments.

Comment 10

[Nils Ohlmeier [:drno]]

Just a call with Maire via apprtc with a couple of interesting experiences:

Nils: Nightly, Maire: Aurora

1st attempt: Nils provided the apprtc URL and when Maire joined we got the same problem as described above
2nd attempt: Maire provided the apprtc URL and everything worked when Nils joined
3rd attempt: Nils provided again the apprtc URL and everything worked this time when Maire joined

So it is not seem to be 100% reproducible.

What was even more strange was the fact that we got the same error box with "channel error" when we were 30min or so into the call and the call was still running fine at that time. I'm attaching a screenshot of that separately.
But apparently the message from apprtc does not mean much.

Comment 11

[Nils Ohlmeier [:drno]]

Attachment: Channel error in a perfectly fine call

Comment 12

[Paul Silaghi, QA [:pauly]]

(In reply to Nils Ohlmeier [:drno] from comment #10)
> So it is not seem to be 100% reproducible.
Confirmed, I managed to make it work couple of times.

Comment 13

[Paul Silaghi, QA [:pauly]]

Attachment: channel error after a 10 min call

I was having a webrtc call between Ubuntu 13.04 64-bit - Windows XP 32-bit, everything was fine, suddenly after ~ 10 minutes I got (on Ubuntu) the channel error and the call froze.

Comment 14

[Paul Silaghi, QA [:pauly]]

Attachment: channel error - browser console log

Comment 15

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

Channel error is often an issue outside the browser.  Without more info, it's impossible to tell.  NSPR logs can sometimes help (signaling:5,mtransport:5).  Also, now (before you leave the page) open a new tab and check about:webrtc, open the ICE logs there, and then select all and paste it into a file (don't Save Page; that gets you the JS code!)

Comment 16

[Paul Silaghi, QA [:pauly]]

Attachment: NSPR logs.zip

(In reply to Randell Jesup [:jesup] from comment #15)
> NSPR logs can sometimes help (signaling:5,mtransport:5)

Comment 17

[Paul Silaghi, QA [:pauly]]

Attachment: about webrtc.txt

> check about:webrtc, open the ICE logs there, and then select all
> and paste it into a file

Comment 18

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

Not sure if this was the cause of the channel error or not:

ICE(PC:1394789959376893 (id=22 url=https://apprtc.webrtc.org/?r=20636880)): Error on reliable socket. Abandoning.

But I doubt it, since the selected candidates were 192.* UDP addresses.

Nothing in the logs tells me anything useful; I'm guessing this is a failure at the apprtc end.

At this point, everything points to a site/server problem

Comment 19

[u279076]

(In reply to Randell Jesup [:jesup] from comment #18)
> At this point, everything points to a site/server problem

This issue makes it difficult to do the manual spotchecks QA agreed to a while back. What can we do about this? Seems like reliability on third-party infrastructure is the weak link in the chain.

Comment 20

[u279076]

At this point I'm marking this RESOLVED INVALID as there's no new information here pointing this to a bug in Firefox. Please reopen if that information can be provide.

That said, we should really make it a high priority to get some sort of internal test infrastructure running so QA can reliably do A-B Firefox signoffs. I'll investigate that in a separate bug.