Seemingly problems connecting PC-Android using a custom WebRTC implementation (PC-PC works fine)

[Kenneth Thorman]

Hi

Let me start by saying that I have had this problem for a while, and to be honest I have not been able to make much headway in solving this at all

I have previous posted on the WebRTC forums since I initially thought this might have something to do with our implementation (which it still might).

Yesterday I was running comparison between Google Chrome in debug mode (libjingle) PC-PC vs PC-Android and that ended up indicating the following error 

[11492:8252:0107/220147:VERBOSE1:stunport.cc(106)] Binding request timed out from 169.254.154.191:51923 ({0F22F5ED-380A-4F49-9CDA-237128F00B7A})
[11492:8252:0107/220147:VERBOSE1:stunport.cc(106)] Binding request timed out from 192.168.163.1:51925 ({BEF7559D-5AE8-4D88-B439-EA6B59252B34})

And WebRTC developer brav...@webrtc.org stated

It seems that PC and Android devices are not under same network and TURN server doesn't do its job. Please double check it.

As far as I know both the tablet(s)/phone(s) (from now on named - devices) are on the same WIFI network as the PC's (there is only one isolated network and that is the one all devices and PC's are using). No mobile network is involved.

On one AWS server the code/site is working fine but on the primary server it does not work (PC-device).

Servers (code was identical on both servers when testing):

PC-PC: OK, PC-device: NOT OK

http://meeting.appinux.com/index2.html

PC-PC: OK, PC-device: OK

http://appinux.hp.af.cm/

Attaching turnserver logs for both connection attempts (PC-PC, PC-device - and for both a previous version of the turnserver and the latest version - currently running 3.2.1.4)

Any help pinpointing what seems to be wrong here would be greatly appreciated.

Thank you in advance

Regards

Kenneth Thorman

Previous background on this problem.

Seemingly PC -> Android webrtc interop problems across platforms - Google Groups

Issue 2664 - webrtc - Seemingly PC -> Android webrtc interop problems across platforms - Web-based real-time communication - Google Project Hosting

[Oleg Moskalenko]

I checked the turnserver logs and everything looks fine. I suppose that something is wrong with the android TURN libraries or with the WiFi network setup.

One strange thing that I noticed in all logs is that the allocations are done with UDP, but there are some attempts from 176.* address over TCP - and it is immediately getting closed.

You can run the wireshark to sniff the packets between the TURN server and the mobile devices and see what is going on.

Regards,
Oleg

[Oleg Moskalenko]

Also, I do not know which routers you are using in your home network, but the cheap home routers are really tricky. I personally observed a situation when WiFi devices on the same network could not access or even ping each other, having consecutive IP addresses. The wired connections are fine; but the WiFi connections may be awful. My experience is that the cheap routers are set to connect the devices to the outside world, but connecting the local devices between themselves is their least priority and they do not do that very well.

When you are using an outside STUN & TURN server, the devices may discover that they are on the same network and they may try to connect directly. But as I said, that direct connectivity quite often fails over the WiFi or it works very unreliably. That is my experience. In this case you can try to force them to work thru the TURN server, by ICE settings, it may help.

[Kenneth Thorman]

Actually, right now I am sitting at home on a cheap router, but that is only due to the fact that it is way past office working hours really :).

I am trying to troubleshoot this problem since this is occurring for clients using this site as well. So I am trying to figure out what is happening, and I found that I can now also reproduce this.

But on another identical (at least WebRTC signaling code / node.js wise) site the PC-Android is working just fine.

I am sure it is my lack of fully comprehending how all the pieces are fitting together, but this really has me running in circles.

Regards

Kenneth

[Kenneth Thorman]

What threw me off track and starting to look into the STUN/TURN server might be the culprit is that the Chrome debug logs seemed to indicate that there was a problem connecting to the STUN server.

And maybe STUN/TURN is indeed not at all relevant in pinning down the problem - just grasping at straws here.

Regards

Kenneth

[Alexandre GOUAILLARD]

in similar context our workaround was to force TURN only connection on a second attempt if a first, unconstrained, attempt would fail. It happens that host or srflx candidates are being tested ok by chrome but actually do not result in a connection (for a myriad of reasons attached to network devices in between). Just filtering the candidate "type" field either at gathering (in onIceCandidate), or at reception (addIceCandidate) does the trick.

note that there is/was a limit to the number of candidate generated, so if you have too many network interfaces, and too many options (multiple stun + multiple turn), candidates for some options will not be generated. The same code, on the same networks can suddenly fail in a computer that has a different number of network cards.

https://code.google.com/p/webrtc/issues/detail?id=1680

HTH

--
You received this message because you are subscribed to the Google Groups "TURN Server project rfc5766-turn-server" group.
To unsubscribe from this group and stop receiving emails from it, send an email to turn-server-project-rfc57...@googlegroups.com.
To post to this group, send email to turn-server-project...@googlegroups.com.
Visit this group at http://groups.google.com/group/turn-server-project-rfc5766-turn-server.
For more options, visit https://groups.google.com/groups/opt_out.

[Kenneth Thorman]

Hi Oleg and Alexandre 

The problem seems to have been resolved and although I am not able to pinpoint what the problem was, I am going to document what we did to solve it, so it might help other people in the same situation.

Alexandres posting pointed me in the direction that eventually solved this, but not as we expected on the turn server but in stead on the WebRTC signaling server.

The signaling server is a rather simple node.js script that basically just reflects messages from one participant to the other during the webrtc signaling phase, based on a shared roomid.

There is no additional logic in the node.js script and all is in the browser side javascript. The transmission is done using websockets (socket.io).

We tried moving the code around for the webrtc signaling server, and once we moved it to a new server everything suddenly started working. The old server was hosted in a hosting center (Hyper-V virtualization server and the guest OS was CentOS) the new server was located on AWS with AmazonLinux. The node.js package was the same version and the code on the node.js server and in the browser was identical. The TURN server was not changed at all.

So summarizing:

Client configuration is the same (both PC and Android)

TURN server is the same

Moving the WebRTC signaling server fixed the problem.

Thank you very much for the assistance and help form the people on these forums.

If anyone have any thoughts on what might have cased this, I am very interested.

Regards

Kenneth Thorman

To unsubscribe from this group and stop receiving emails from it, send an email to turn-server-project-rfc5766-turn-server+unsubscribe@googlegroups.com.
To post to this group, send email to turn-server-project-rfc5766-turn-...@googlegroups.com.

[Oleg Moskalenko]

The only idea that I have is that the Amazon AWS is built around Citrix products (Xen Server, etc). Citrix is the same company where the TURN server originated from :) may be those solutions just work well together :)

[Sprogrammer]

PC-Android: Just tested now. 2 scenario worked:

1) RTC signaling in Public dedicated server with no nat location ( http://www.heartinternet.co.uk/vps )

   Turnserver also in the same server + same network with no nat

Or

2) RTC signaling in Public dedicated server with no nat location ( http://www.heartinternet.co.uk/vps )

    Turnserver not in same server and same network (for instance my office network)

[Sprogrammer]

@Kenneth Thorman: Its not a Android libraries issue and its not Chrome browser issue i have tested it to confirm.

My suspects are now:

- The problem is my DrayTek Vigor 2920 router or my ISP giving me public ip which needed to be tunneled for wAN and then have public IP, i think ISP itself causing the NAT issue to me 

- Completely networking issue specially Public IP terms

Correct me if i am wrong. Thank you it was nice discussion.

On Tuesday, January 14, 2014 11:11:20 AM UTC+1, Kenneth Thorman wrote:

[Kenneth Thorman]

I though I have located the problem several times and one of the most promising candidates where the DTLS certificate caching in Chrome.

https://code.google.com/p/webrtc/issues/detail?id=2619

This was also commented by one of the WebRTC/Chrome developers on one of the other threads. My challenge was that the suggested workaround did not work for me.

After we have move the signaling server from one server to another it now works and this is the strange part since it was during signaling it broke down it was not able to fully establish the peer-peer connection.

We have created the following list now whenever we encounter problems between Android/PC chrome

How to know if you have DTLS certificate issues

2 different PCs on the same network, one PC can connect to the Android Chrome in a meeting, another cannot.

Both PCs used to work, now one of them don't.

This should have been resolve in M32 or M34 of Chrome, but will still be an issue in older versions as far as I know

Running the test on your custom webrtc site has stopped working but if you try apprtc it is likely to work.

To make sure that you do not have DTLS issues in Chrome

1. Try to clear the full browser cache in Chrome on PC

2. test again 

3. if not working uninstall chrome

4. restart pc 

5. test again

6. if this is not working then make a connection between Firefox on PC with Chrome on Android (this will most likely work)

7. close the room

8. join a new meeting between PC Chrome and Android Chrome (this is now likely to work)

But this is not the full answer to why it did not work for me before and now it does, but more than likely more than one issue that was causing several symptoms.

Currently this is working for me - after moving the WebRTC signaling server and following the list above.

If you are behind a restrictive firewall the webrtc and signaling javascript should first try to use the STUN protocol as an ICE candidate and if this fails then it should fall back to TURN, which should handle most network and firewall configurations I think.

I even think that your configuration should work, basically as long as you can make a connection from your PC to a given website, then you should be able connect to the TURN server.

Some FW admins are very restrictive even on outbound connections so they block all ports except 53 (DNS), 80(HTTP), 443(HTTPS), but as far as I understand even this you can configure the TURN server to handle.

I short, I am not really sure I can offer any advice that would help you, I am short on knowledge in this field myself, I am afraid.

Good luck.

Regards

Kenneth