928777 - WebRTC peer connection requiring TURN does not actually work

Status: RESOLVED WORKSFORME

(Core :: WebRTC, defect)

Description

[Matthew Robertson]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.101 Safari/537.36

Steps to reproduce:

- Use two computers, both running Firefox stable (v24.0)
- connect computers to networks that would require a TURN server to form an RtcPeerconnection (I had one tethered to a 3g cell phone network)
- navigate to https://apprtc.appspot.com with one computer
- in the second computer navigate to the apprtc room url created by the first


Actual results:

Both computers transition transition to the active call UI, but do not show the remote peer's video stream.


Expected results:

1. If Firefox ships a working TURN implementation, then the webrtc call peer connection should form successfully by using apprtc's relay server and each user should be able to view their remote peer's video stream.

2. If Firefox does not ships a working TURN implementation, then the peer connection's "iceConnectionState" should transition to "failed" and the apprtc UI should show a message indicating the peer connection failed to form.

Comment 1

[Eric Rescorla (:ekr)]

Firefox 24 does not support TURN.

Are you sure that we're not updating the ice connection state? I just looked
through the apprtc code and I am not sure that it generates a failure in this
case. Have you tried a failed connection with Chrome?

Comment 2

[Matthew Robertson]

You are right, it actually just displays the "connecting" message on chrome if I supply a bunk turn server.

In any case, for some reason when firefox fails to form a connection the peerconnection.iceConnectionState still transitions to "connected" and the apprtc UI "transitionsToActive" which suggests the peerconnection.onaddstream callback is firing.

See the attached screenshot. I am not in a properly connected call because the TURN server could not be used to connect to my peer but the apprtc UI has transitioned to its active state. Also you can see in the infoDiv that the iceConnectionState is connected.

PS you can display this info div in apprtc by entering this line of code into your web console:

`document.getElementById('infoDiv').style.display = 'block'`

Comment 3

[Matthew Robertson]

Attachment: Screen grab of a failed apprtc call in firefox with the peerconnection.iceConnectionState === 'connected'

Comment 4

[daniel]

Debian wheezy is still carrying Firefox (iceweasel) 24 and it appears to have trouble like this too.  Just tested now on 24.7.0esr-1~deb7u1

I then tested on a Debian jessie system with Firefox / iceweasel 29.0.1 and the call is setup correctly using TURN.  Package version 29.0.1-2

Both tests were made using https://freephonebox.net
- JSCommunicator commit 50874df076c615f3487ff3fbc1ebe0c07c4acbf1
- JsSIP Debian package 0.4.0.20140212.1-1 (based on develop branch of JsSIP)

On the Firefox 24 test, JsSIP does correctly log the ICE setup failure:

[16:48:21.635] "Sat Aug 16 2014 16:48:21 GMT+0200 (CEST) | jssip.rtcsession.rtcmediahandler | ICE connection state changed to "failed""

and this suggests to me that Firefox 24 does know that ICE failed but the application (JsSIP in this case) has tried to proceed anyway.  I haven't looked closely enough to work out whether JsSIP tried to proceed because of some misinformation it received from the browser or because it simply doesn't know how to handle this situation.

What I did notice is that this particular JsSIP version is not sending ICE candidates back to the caller in a 183 response.  It alerts the callee as soon as it receives the INVITE, then it sends a 200 with candidates when the callee answers.  This appears to be wrong.  Here is what happens:

caller sends INVITE with local candidates and no TURN candidates
JsSIP sends back 180
JsSIP alerts callee
callee clicks to answer
JsSIP sends 200 with candidates back to caller

What should be happening:

caller sends INVITE with local candidates and no TURN candidates
JsSIP sends back 183 with candidates
browsers make connectivity checks
if checks fail, caller should see error and callee should not even know anything happened
JsSIP sends back 180
JsSIP alerts callee
callee clicks to answer
JsSIP sends 200 with confirmed candidates back to caller

So, if the JavaScript application is behaving like this then the user will have the type of experience that ICE is meant to avoid, but it is not a fault in the ICE implementation, it is a fault in the JavaScript application.