Closed Bug 1702163 Opened 4 years ago Closed 4 years ago

RTCPeerConnection constructor throws Uncaught Exception

Categories

(Core :: WebRTC: Networking, defect)

Firefox 87
defect

Tracking

()

RESOLVED INVALID

People

(Reporter: giaesp, Unassigned)

References

Details

Attachments

(1 file, 1 obsolete file)

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.

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.

Group: firefox-core-security → core-security-release
Component: Untriaged → WebRTC: Networking
Flags: needinfo?(giaesp)
Product: Firefox → Core

You're right, it was my mistake to declare this bug as a security sensitive bug.
How can I recategorize this issue?

Flags: needinfo?(giaesp)

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 )

Group: core-security-release
Flags: needinfo?(giaesp)

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

Attached file log.txt-main.6600.moz_log (obsolete) —
Flags: needinfo?(giaesp)

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.

Attachment #9213019 - Attachment is obsolete: true

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?

Flags: needinfo?(giaesp)

Use this webpage https://vcall.visitamiapp.com/?room=666113&token=9902353654 for your checks.
Thank you

Flags: needinfo?(giaesp)

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

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.

Status: UNCONFIRMED → RESOLVED
Closed: 4 years ago
Resolution: --- → INVALID

(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...

Flags: needinfo?(docfaraday)

(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.

Flags: needinfo?(docfaraday)
See Also: → 1529588
See Also: → 1702512
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: