1295903 - Setting rtcconfig.peerIdentity is broken on webrtc-landing

Status: RESOLVED FIXED

(Core :: WebRTC: Signaling, defect, P1)

Description

[Nils Ohlmeier [:drno]]

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: [e-mail]" which apparently gets emitted by PeerConnection.js.

Identity mochitests appear to be happy.

Comment 1

[Nils Ohlmeier [:drno]]

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?

Comment 2

[Martin Thomson [:mt:]]

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.

Comment 3

[Martin Thomson [:mt:]]

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.

Comment 4

[Nils Ohlmeier [:drno]]

Yes, it works now for me as well. Thanks