Status

()

Core
WebRTC
RESOLVED INVALID
5 years ago
4 years ago

People

(Reporter: pauly, Unassigned)

Tracking

Trunk
x86_64
Windows 7
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(6 attachments, 1 obsolete attachment)

(Reporter)

Description

5 years ago
Created attachment 8367333 [details]
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
(Reporter)

Comment 1

5 years ago
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 ?
Flags: needinfo?(rjesup)
(Reporter)

Comment 2

5 years ago
Created attachment 8367335 [details]
webrtc error.png
Attachment #8367333 - Attachment is obsolete: true
(Reporter)

Comment 3

5 years ago
The strange part is I can't reproduce the problem on FF 26 release.
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?
Flags: needinfo?(rjesup) → needinfo?(ekr)

Comment 5

5 years ago
Generally a Channel Error is a problem with app-engine channels. I.e., not a WebRTC
issue, though perhaps a ffox issue.
Flags: needinfo?(ekr)
(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

5 years ago
Google app engine channels are kind of a mess. So it could just be a bug in app engine.
(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?
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.
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.
Created attachment 8367587 [details]
Channel error in a perfectly fine call
(Reporter)

Comment 12

5 years ago
(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.
(Reporter)

Comment 13

4 years ago
Created attachment 8390504 [details]
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.
(Reporter)

Comment 14

4 years ago
Created attachment 8390506 [details]
channel error - browser console log
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!)
Flags: needinfo?(paul.silaghi)
(Reporter)

Comment 16

4 years ago
Created attachment 8391125 [details]
NSPR logs.zip

(In reply to Randell Jesup [:jesup] from comment #15)
> NSPR logs can sometimes help (signaling:5,mtransport:5)
Flags: needinfo?(paul.silaghi)
(Reporter)

Comment 17

4 years ago
Created attachment 8391128 [details]
about webrtc.txt

> check about:webrtc, open the ICE logs there, and then select all
> and paste it into a file
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
(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.
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.
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.