Setting rtcconfig.peerIdentity is broken on webrtc-landing

RESOLVED FIXED

Status

()

Core
WebRTC: Signaling
P1
normal
Rank:
19
RESOLVED FIXED
a year ago
a year ago

People

(Reporter: drno, Unassigned)

Tracking

48 Branch
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

a year ago
When I got to http://mozilla.github.io/webrtc-landing/pc_test.html and enter values into the "User A Name" and/or "User B Name" boxes the call does not get established.

PeerIdentity properly reports the identity in the log as long as know user names are provisioned. Setting the user names appears to result in peerIdentity getting set in the RTCConfig of the PeerConnections.

From looking at mtransport logs it looks like the second PC still creates an answer, but then something closes PC2. I have not been able to figure out where that close() request is coming from.
On some occasions I saw the following log line appear on the developer console: "IncompatibleSessionDescriptionError: Peer Identity mismatch, expected: alice@martinthomson.github.io" which apparently gets emitted by PeerConnection.js.

Identity mochitests appear to be happy.
(Reporter)

Updated

a year ago
backlog: --- → webrtc/webaudio+
Rank: 19
(Reporter)

Comment 1

a year ago
I think the PeerConnection closing is simply the PeerIdenity verification failing and then closing the PC. Martin can you take a look at what is going on here? Or if not any pointers on where to start digging for the error?
Flags: needinfo?(martin.thomson)
I've just spent ages looking into this.  An unmodified windows build crashes on startup.  Spent ages with mozconfig files trying to work out what was going on.

In the end, I remembered that idp.js was never hooked up to pay attention to the username hint.  Therefore, it generates a random name even when you tell it that it's supposed to do something else.  That causes the connection to fail.

What is new here, and what took ages to track down, is that there is something different about the way we treat cross-compartment exceptions.  That's causing the whole error-reporting system to flake out completely.  I've started work on an idp that pays attention to names, but it's frustrating when errors are all opaque and useless.

I'll keep poking.
Flags: needinfo?(martin.thomson)
Nils, does the page work now?  It does for me.

BTW, if the error is reported using `code.message || code`, then you won't get the mysterious "Failure {}" message.
Flags: needinfo?(drno)
(Reporter)

Comment 4

a year ago
Yes, it works now for me as well. Thanks
Status: NEW → RESOLVED
Last Resolved: a year ago
Flags: needinfo?(drno)
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.