RTCPeerConnection constructor throws Uncaught Exception
Categories
(Core :: WebRTC: Networking, defect)
Tracking
()
People
(Reporter: giaesp, Unassigned)
References
Details
Attachments
(1 file, 1 obsolete file)
4.60 MB,
text/plain
|
Details |
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 11_2_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/89.0.4389.90 Safari/537.36
Steps to reproduce:
I initialize an RTCPeerConnection in my js code:
var servers = {'iceServers': [{'urls': 'stun:stun.l.google.com:19302'}]};
this.localPeerConnection = new RTCPeerConnection(servers);
Please note it works on Firefox 86 (and Chrome and Edge). It doesn't work starting from Firefox 87.
Initializing an empty RTCPeerConnection doesn't generate the exception, but I can't use setConfiguration() method (https://developer.mozilla.org/en-US/docs/Web/API/RTCPeerConnection/setConfiguration) because it has not been released yet.
Actual results:
Uncaught Exception { name: "NS_ERROR_UNEXPECTED", message: "", result: 2147549183, ... }
WebRTC video call doesn't start.
Expected results:
WebRTC video call should start.
Comment 1•4 years ago
|
||
Did you intend to mark this as a security sensitive bug that needs to be hidden from people? It doesn't look like a security issue to me, and it'll interfere with other people seeing the report and helping to triage/fix it.
You're right, it was my mistake to declare this bug as a security sensitive bug.
How can I recategorize this issue?
Comment 3•4 years ago
|
||
I've removed the security flag.
I'll add that I cannot reproduce the issue on our nightly development builds, or 88 beta, or a nightly build from when 87 release branched.
Have you tried a clean Firefox profile? ( https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles )
Comment 4•4 years ago
|
||
No luck reproducing on nightly or release either. We might be able to get a better idea of what is happening with some logging. Can you run firefox with the following environment variable set?
MOZ_LOG=signaling:5,PeerConnectionImpl:5,jsep:5
I've tested this behavior on different machines, different OS and different Firefox releases.
I've tested with clean profile too with no luck: always the same Uncaught exception on Firefox 87+ (tested on Firefox Developer Edition 88.0b5 too).
A further note: I had the same beahvior using Jitsi (https://meet.jit.si/), but no exceptions in console. It's just not starting the video session.
Take a look at the log file attached.
Comment 8•4 years ago
|
||
So, these log files seem to contain lots of necko logging (nsSocketTransport, nsHttp, nsHostResolver, etc), but nothing from signaling, PeerConnectionImpl, or jsep.
If this is super reproducible for you across OS/machine, that hints that there's some subtlety in the JS code you're executing that is not captured in the description; could you boil this down to a jsfiddle (or similar) that you can share with us?
Use this webpage https://vcall.visitamiapp.com/?room=666113&token=9902353654 for your checks.
Thank you
Comment 10•4 years ago
|
||
We don't like the port 123; we block a bunch of known ports for security reasons. Please just use the standard stun (3478) and stuns (5349) ports.
https://searchfox.org/mozilla-central/source/netwerk/base/nsIOService.cpp#138
Reporter | ||
Comment 11•4 years ago
|
||
Thank you very much Byron.
I've restored the standard ports for TURN and STUN and all seems working fine now.
I'll made further testing in these days.
Updated•4 years ago
|
Comment 12•4 years ago
|
||
(In reply to Byron Campen [:bwc] from comment #10)
We don't like the port 123; we block a bunch of known ports for security reasons. Please just use the standard stun (3478) and stuns (5349) ports.
https://searchfox.org/mozilla-central/source/netwerk/base/nsIOService.cpp#138
Would it be worth having a separate bug to improve the error reporting? AIUI we shouldn't really be exposing NS_ERROR_UNEXPECTED
to the web and should use a DOM error instead, and a custom message indicating the port is blocked might also help people resolve issues faster than heading to bugzilla...
Comment 13•4 years ago
|
||
(In reply to :Gijs (he/him) from comment #12)
(In reply to Byron Campen [:bwc] from comment #10)
We don't like the port 123; we block a bunch of known ports for security reasons. Please just use the standard stun (3478) and stuns (5349) ports.
https://searchfox.org/mozilla-central/source/netwerk/base/nsIOService.cpp#138
Would it be worth having a separate bug to improve the error reporting? AIUI we shouldn't really be exposing
NS_ERROR_UNEXPECTED
to the web and should use a DOM error instead, and a custom message indicating the port is blocked might also help people resolve issues faster than heading to bugzilla...
That would be bug 1529588.
Description
•