902615 - Cannot make calls on talky.io

Status: RESOLVED INVALID

(Core :: WebRTC, defect)

Description

[Jason Smith [:jsmith]]

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.

Comment 1

[henrik]

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.

Comment 2

[Jason Smith [:jsmith]]

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.

Comment 3

[henrik]

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.

Comment 4

[Jason Smith [:jsmith]]

Found the TURN server in question - turn:turn.talky.io

Comment 5

[Maire Reavy [:mreavy]]

Jason or Henrik -- Can one of you get & upload a Wireshark trace of a failed call?

Comment 6

[Jason Smith [:jsmith]]

Attachment: Wireshark Trace

Comment 7

[Jason Smith [: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]

Comment 8

[Jason Smith [:jsmith]]

Attachment: NSPR Logs

Comment 9

[Jason Smith [:jsmith]]

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

Comment 10

[Eric Rescorla (:ekr)]

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

Comment 11

[Eric Rescorla (:ekr)]

(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

Comment 12

[Jason Smith [:jsmith]]

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?

Comment 13

[henrik]

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

Comment 14

[henrik]

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.

Comment 15

[Eric Rescorla (:ekr)]

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

Comment 16

[Jason Smith [:jsmith]]

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.