Status

()

defect
RESOLVED INVALID
6 years ago
6 years ago

People

(Reporter: jsmith, Unassigned)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

STR

1. Go to talky.io and create a room (on machine #1)
2. On machine #2, go to the talky.io room for machine #2

Expected

Call should be established between each peer - video should be seen by each peer.

Actual

The call fails to establish during construction of the peer connection with an error seen below on Nightly/Aurora:

[14:08:47.308] NS_ERROR_UNEXPECTED: Unexpected error @ https://talky.io/talky.0ecfcb9a.js:19385

On release, I'm seeing a NS_ERROR_FAILURE instead here.
This worked in FF 22 and when I opened the "about" dialog and downloaded 23 and ran it again, I'm now seeing the NS_ERROR_FAILURE thing. Anyone know what changed that might have broken this to speed up finding/fixing the issue.
I think I know why. Testing this out on Fx22 shows that talky.io is using a STUN server as a fallback, as TURN is not supported. Fx23 you don't see that fallback being hit, so we're likely making use of the TURN workflow, given that Fx23 adds the ability to use TURN.

This is starting to look like a TURN bug.
ah, ok... this is one area i'd really like to sort out since proper TURN support increases overall perceived reliability of the service dramatically.
Found the TURN server in question - turn:turn.talky.io
Jason or Henrik -- Can one of you get & upload a Wireshark trace of a failed call?
Flags: needinfo?(jsmith)
Posted file Wireshark Trace
Flags: needinfo?(jsmith)
Reproduced on a debug build and saw this in the logs:

System JS : ERROR file:///c:/Users/jsmith/Documents/mozilla-central/obj-i686-pc-mingw32/dist/bin/components/PeerConnection.js:325
                     NS_ERROR_FAILURE: Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [IPeerConnection.initialize]
Posted file NSPR Logs
NSPR logs confirm this is a problem with TURN:

0[260f140]: Couldn't set TURN server for 'PC:69395cb03a0fd9a3'
0[260f140]: [main|PeerConnectionMedia] PeerConnectionMedia.cpp:158: sipcc::PeerConnectionMedia::Init: Failed to set turn servers
0[260f140]: [main|PeerConnectionImpl] PeerConnectionImpl.cpp:619: sipcc::PeerConnectionImpl::Initialize: Couldn't initialize media object
This code uses an invalid TURN servers parameter, because a credential
is not present even though it needs to be supplied:

 {"url": "turn:turn.talky.io"},

http://dev.w3.org/2011/webrtc/editor/webrtc.html#dictionary-rtciceserver-members

From RFC 5766:

"   [RFC5389] specifies an authentication mechanism called the long-term
   credential mechanism.  TURN servers and clients MUST implement this
   mechanism.  The server MUST demand that all requests from the client
   be authenticated using this mechanism, or that a equally strong or
   stronger mechanism for client authentication is used.
"
(In reply to Jason Smith [:jsmith] from comment #9)
> NSPR logs confirm this is a problem with TURN:
> 
> 0[260f140]: Couldn't set TURN server for 'PC:69395cb03a0fd9a3'
> 0[260f140]: [main|PeerConnectionMedia] PeerConnectionMedia.cpp:158:
> sipcc::PeerConnectionMedia::Init: Failed to set turn servers
> 0[260f140]: [main|PeerConnectionImpl] PeerConnectionImpl.cpp:619:
> sipcc::PeerConnectionImpl::Initialize: Couldn't initialize media object

Note:
For further information, turn on mtransport:5 logging
Sounds like then this is a bug then on the developer's side. Although we could potentially keep this open on our side to improve the error output here. Can we throw something better at the developer other than NS_ERROR_FAILURE or NS_ERROR_UNEXPECTED here to say that there was no credentials provided with turn server parameter?
+1 for improved logging to let devs know what's wrong.

Second question, so... what should those configs look like? Even setting the turn server as the fallback and adding the "credential" parameter produced the same error: 

{"url": "stun:stun.l.google.com:19302"},
{"url": "turn:turn.talky.io", "credential": "temp"}

We temporarily tilted up a completely unsecured restund (TURN) server. But i assumed it wouldn't be used unless the first failed. Is that incorrect?

I was surprised to still see the error with the TURN server second.

I'm temporarily disabling the turn server config in production (and just using Google's for now)  since that seems to make things work again in FF23.

Would love some help on how to test/debug turn server issues. Or how to set them up, etc. There's practically no useful info on it available, it seems.
ok, that change is deployed now with no turn servers again... I really want to figure this out, though. Documentation/examples on how to properly do this seems like a big area of weakness in the complete experience of shipping a WebRTC app, IMO.
(In reply to henrik from comment #13)
> +1 for improved logging to let devs know what's wrong.
> 
> Second question, so... what should those configs look like? Even setting the
> turn server as the fallback and adding the "credential" parameter produced
> the same error: 
> 
> {"url": "stun:stun.l.google.com:19302"},
> {"url": "turn:turn.talky.io", "credential": "temp"}

Example here:

http://dxr.mozilla.org/mozilla-central/source/media/webrtc/signaling/src/peerconnection/PeerConnectionImpl.cpp#l422


> We temporarily tilted up a completely unsecured restund (TURN) server. But i
> assumed it wouldn't be used unless the first failed. Is that incorrect?

No, we use them in parallel.

Also this isn't a failure of the server. You're passing in a bogus config
and so the PC ctor is failing.


> I was surprised to still see the error with the TURN server second.
> 
> I'm temporarily disabling the turn server config in production (and just
> using Google's for now)  since that seems to make things work again in FF23.
> 
> Would love some help on how to test/debug turn server issues. Or how to set
> them up, etc. There's practically no useful info on it available, it seems.
Given that this is a bug on the site's side that was fixed, I'm closing this out. I filed bug 903539 to track improving the exception message when a TURN server is used without creds.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.