Used 3.0.2.1 - in a complex network where Google hangout works but WebRTC never worked

[Sprogrammer]

i thought maybe the new release may work (Build 3.0.2.1), but no luck it failed

i am trying to simulate exact configuration how Google Hangout works for all networking scenarios. 

Today i tested following and every-time Google Hangout works but there similar frameworks WebRTC, AppRTC in same networking does not work.

Server: running latest build 3.0.2.1, webRTC server modules, networking is straight public ip (firewall disabled)

Peer 1: Government network, very complicated and restricted zone to remotely access ports (mostly there incoming traffics are ruled)

> Google Hangout works perfectly with Peer 2 on the fly, without any surprise 

> WebRTC, AppRTC with Peer 2 does not work (always fails)

> turnserver receives logs while using WebRTC but unable to make a tcp/udp hole punch for webRTC media transmission

Peer 2: Public IP, networking is straight (firewall disabled)

> Google Hangout works perfectly with Peer 1 on the fly

> WebRTC, AppRTC with Peer 1 does not work (always fails)

> turnserver receives logs while using WebRTC but unable to make a tcp/udp hole punch for webRTC media transmission

Made me very confused now, why in same network, same peer1/2, same browser, Google Hangout simply just works, and on other hand WebRTC (sister of Google Hangout technologies) does not work, even having turnserver

Alternative workout i applied was: http://openvpn.net/index.php/access-server/download-openvpn-as-sw.html , but this is not really Google Hangout way of doing, i think there is still something i am missing to reach the concept of how Google Hangout perfectly working with turnserver + webRTC (unless they are using completely something else)

Any idea how to make the turnserver + webRTC setup, exactly similar to Google Hangout networking breakthrough?

[Sprogrammer]

Is there any way i can tell turnserver to do 100% relay via server. So when webRTC is trying to connect Peer 1 and Peer 2, here turnserver takeover the signaling + media packets and transfer it via turnserver (like proxy or bypass or relay).

So that the packets get delivered via server not straight p2p, just to be sure that at-least it will be slow/latency involved but no failure while trying to interconnect peer1 and peer2.

Thank you

[Oleg Moskalenko]

My understanding is that Google Hangout is a different technology. They do not use p2p, they run it thru their network.

You have to investigate the rules in the restrictive peer to figure out why it is not letting turn server interactions.

Regards,
Oleg

[Oleg Moskalenko]

You can trick the WebRTC ICE process to use the TURN server for all peers. I do not remember how to do that. But you can NOT tell TURN server to be involved - its role is passive. ICE either uses TURN or not, its up to ICE.

 Regards,
Oleg

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

[Sprogrammer]

YES

> Therefore i wrote two samples to have relay by server and in that network it works, how can i do this with our turnserver?

> For example this works but i have no idea how can we do similar with turnserver

Server            : http://paste.ubuntu.com/6507465/

- i ran this in the server where turnserver is running

Client (peer 1) : http://paste.ubuntu.com/6507459/

- i ran this in Government network as peer 1

Client (peer 2) : same as above

- i ran this in my laptop as peer 2

This works to send and receive full-duplex packets but if i can do this with turnserver + webRTC and pjSIP then i think the problem is solved (for my case)

Thank you 

Regards

[Sprogrammer]

In webRTC you can assign it like this which i did for peer1 and peer2 but it did not worked.

for example:

http://centosserver.com:8080/?r=1234&media=video&ts=my.turnserver.com:3478?transport=tcp

ts = username@ turn server : port ? transport = udp or tcp

tp = password of turnserver

I tried this with our turnserver but like i said it did not worked with there network (But Google hangout works with same networking)

Thank you

Regards

[Oleg Moskalenko]

If you want ONLY TURN to be used, then assigning TURN credentials is not enough, you also have to restrict the "direct" peer candidates. In your case probably it is trying to communicate directly to one of the peers. You want both peers to be connected to the TURN server and then their relay endpoints will be communicating "inside" the TURN server.

Regards,
Oleg

[Sprogrammer]

Exactly that is what i am trying actually now, like you have suggested.

In my turnserver i get logs only from Peer 2( my laptop), but Peer 1 is not reaching even.

Peer 2: (my laptop) using TURN to connect TURN server 

Dec  2 06:50:50 localhost turnserver: 315440: handle_udp_packet: New UDP endpoint: local addr 192.168.1.12:3478, remote addr 82.x.x.x:36874

Dec  2 06:50:50 localhost turnserver: 315440: handle_turn_command: user <>: request BINDING processed, error 0

Dec  2 06:51:00 localhost turnserver: 315450: handle_turn_command: user <>: request BINDING processed, error 0

Dec  2 06:51:10 localhost turnserver: 315460: handle_turn_command: user <>: request BINDING processed, error 0

Dec  2 06:51:39 localhost turnserver: 315489: handle_udp_packet: New UDP endpoint: local addr 192.168.1.12:3478, remote addr 82.x.x.x:52942

Dec  2 06:51:39 localhost turnserver: 315489: handle_turn_command: user <>: request BINDING processed, error 0

Dec  2 06:51:49 localhost turnserver: 315499: handle_turn_command: user <>: request BINDING processed, error 0

Dec  2 06:51:50 localhost turnserver: 315500: TURN full connection closed, user <>

Dec  2 06:51:59 localhost turnserver: 315509: handle_turn_command: user <>: request BINDING processed, error 0

Peer 1: (the problem) also using same like peer 2 TURN client to connect same TURN server for the server internal relay

> But i do not see any log of Peer 1 is coming to the server

> Meaning that either turn is disabled by Government networking rules? 

or only 3478 is blocked by there networking? 

or UDP is not allowed?

in webRTC transport=tcp i used i also tried udp but in both case peer 1 is always unable to reach turnserver (i have no logs of peer 1 coming to turn server)

Thank you

Regards

[Sprogrammer]

YES - you are excellent mind blowing. Indeed the Government network end point, is not allowing to reach my turn server ip/dns. But Government network end point is allowing to reach Google Hangout ip/dns subnets while tracing the packets of Google Hangout.

that means the problem is TURN server and client works but because Google is giant, there IP's could be in auto white list so by default it was working.

I will ask the ICT people at 8AM or 9AM to enable my dns/ip in there firewall / white zone and then will retest it and keep you posted.

Thank you so much

Best regards

[Oleg Moskalenko]

It can be either of the things listed by you.

You can try two things:

1) Run TURN server on ports 80 or 443. May be it will help.

2) Try to use a client that makes HTTP CONNECT thru HTTP proxy and then uses the connection to communicate with the TURN server (I do not know where you can get such a client).

Regards,
Oleg

[Sprogrammer]

OK

So, i wanted to keep 3478 also alive, and jack those 2 extra ports on it something like this:

#!/bin/bash

## 1) Run TURN server on ports 80 or 443. May be it will help.

pgrep -f socat | xargs kill -9;

(socat TCP-LISTEN:443,fork TCP:localhost:3478) &

(socat TCP-LISTEN:80,fork TCP:localhost:3478) &

## 2) Try to use a client that makes HTTP CONNECT thru HTTP proxy and then uses the connection to communicate with the TURN server (I do not know where you can get such a client).

# maybe browser proxy module straight > to the turnserver port

#while :

#do

#  echo 'http ping' | nc turnserver 80 -w 1

#  sleep 1

#done

[Oleg Moskalenko]

You can just use the aux-server option of the TURN server, like this:

$ turnserver ... -aux-server=1.2.3.4:80 -aux-server=1.2.3.4:443

Oleg

[Sprogrammer]

Weird tried with BASH and also with --aux-server=80 --aux-server=443 but, Still Peer 2 (my laptop can reach 443), Peer 1 (the problem, still cant reach 443)

Peer 1: has no issue to connect 80 or 443 or 3478

28: handle_udp_packet: New UDP endpoint: local addr 192.168.1.12:443, remote addr 82.x.x.x:40943
28: handle_turn_command: user <>: request BINDING processed, error 0
38: handle_turn_command: user <>: request BINDING processed, error 0
48: handle_turn_command: user <>: request BINDING processed, error 0

Peer 2: 

a) by this way peer 2 is able to connect

turnserver$ nc -l 7777
peer2$ telnet turnserver 7777
connected

b) by this way peer 2 is able to connect

peer2$ curl "http://turnserver:443/ping"

i can see turn server have logs from peer 2

7: IPv4. tcp or tls connected to: 212.x.x.x:19053
7: IPv4. tcp or tls connected to: 212.x.x.x:5594

c) by this way peer 2 unable to connect

google-chrome "http://turnserver:8080/?r=turntest&media=video&ts=turnserver:443?transport=tcp"

by this way i do not see any logs in trunserver (it could be that UDP blocked issue or something else which i have no idea at all)

thank you

Regards

[Oleg Moskalenko]

This string looks weird:

"http://turnserver:8080/?r=turntest&media=video&ts=turnserver:443?transport=tcp"




I see both 8080 and 443 ports here...



[Sprogrammer]

8080 = webRTC server running on that port / tcp protocol (to parse the html, javascript, css, python threads), webserver such as apache or google app engine
443   = telling webRTC, please use turnserver on port 443 tcp or udp to follow the turn protocol

for example execute:
Peer 1: 

$ google-chrome "http://turnserver:8080/?r=turntest&media=video&ts=turnserver:443?transport=tcp"

Peer 2: 
$ google-chrome "http://turnserver:8080/?r=turntest&media=video&ts=turnserver:443?transport=tcp"

then in turnserver logs i can see Peer 2 is connected, same way expecting Peer 1 also in turnserver with following logs which is not happening

1000: handle_udp_packet: New UDP endpoint: local addr 192.168.1.12:443, remote addr 82.x.x.x:42949
1000: handle_turn_command: user <>: request BINDING processed, error 0
1010: handle_turn_command: user <>: request BINDING processed, error 0
1020: handle_turn_command: user <>: request BINDING processed, error 0
1034: TURN full connection closed, user <>
1060: TURN full connection closed, user <>

[Oleg Moskalenko]

I have to warn you that reading your logs I see that actually Peer2 is also NOT connected. Peer2 sends STUN Binding requests but I see no traces of the TURN requests.

That probably means one of two things:

1) ICE decides that two peers can be connected directly, without TURN server.

2) As Peer2 cannot reach the TURN server even with STUN request, the ICE gives up and never tries the TURN server.

So, you have to discuss with the IT guys of Peer1 network the connectivity issue.

Regards,
Oleg