TCP relay is not working (UDP block)

[Wonchul Shin]

I'm trying to TCP relay on WebRTC in business network environment (all UDP blocked, 80, 8080, 443 TCP opened)

But I'm not sure what is the main problem that cannot communicate each other.

It seems to can't allocate. allocation watchdog message is shown repeatedly.

I have add firewall exception for the TURN server with port number 80, 8080, 443.

What is the main problem? Is it network issue? Have I contact to network engineer?

TURN server command:

turn/turnserver-3.2.4.6/bin/turnserver -v -f -a -n -L <IP_ADDR> -X <IP_ADDR>/<IP_ADDR> -p 8080 -u test:test -r test_realm

WebRTC configure:

"iceServers": [

                {

                        "url": "stun:stun.l.google.com:19302"

                },

                {

                        "url": "turn:<IP_ADDR>:8080?transport=tcp",

                        "credential":"test",

                        "username":"test"

                }

TURN Log:

592: handle_udp_packet: New UDP endpoint: local addr 172.31.25.85:8080, remote addr <IP_ADDR>:63807

592: session 000000000000000014: user <>: incoming packet BINDING processed, success

592: IPv4. tcp or tls connected to: <IP_ADDR>:53608

592: session 000000000000000015: user <>: incoming packet message processed, error 401: Unauthorised

592: handle_udp_packet: New UDP endpoint: local addr 172.31.25.85:8080, remote addr <IP_ADDR>:52300

592: session 000000000000000016: user <>: incoming packet BINDING processed, success

592: IPv4. Local relay addr: 172.31.25.85:53287

592: session 000000000000000015: new, username=<test>, lifetime=600

592: session 000000000000000015: user <test>: incoming packet ALLOCATE processed, success

592: session 000000000000000015: user <test>: incoming packet CREATE_PERMISSION processed, success

592: session 000000000000000015: user <test>: incoming packet CREATE_PERMISSION processed, success

602: session 000000000000000014: user <>: incoming packet BINDING processed, success

602: session 000000000000000016: user <>: incoming packet BINDING processed, success

612: session 000000000000000014: user <>: incoming packet BINDING processed, success

612: session 000000000000000016: user <>: incoming packet BINDING processed, success

622: session 000000000000000014: user <>: incoming packet BINDING processed, success

622: session 000000000000000016: user <>: incoming packet BINDING processed, success

632: session 000000000000000014: user <>: incoming packet BINDING processed, success

632: session 000000000000000016: user <>: incoming packet BINDING processed, success

642: session 000000000000000014: user <>: incoming packet BINDING processed, success

652: session 000000000000000014: closed (2nd stage), user <>, local 172.31.25.85:8080, remote <IP_ADDR>:63807, reason: allocation watchdog determined stale session state

652: session 000000000000000016: closed (2nd stage), user <>, local 172.31.25.85:8080, remote <IP_ADDR>:52300, reason: allocation watchdog determined stale session state

652: handle_udp_packet: New UDP endpoint: local addr 172.31.25.85:8080, remote addr <IP_ADDR>:63807

652: session 000000000000000017: user <>: incoming packet BINDING processed, success

662: session 000000000000000017: user <>: incoming packet BINDING processed, success

672: session 000000000000000017: user <>: incoming packet BINDING processed, success

682: session 000000000000000017: user <>: incoming packet BINDING processed, success

692: session 000000000000000017: user <>: incoming packet BINDING processed, success

702: session 000000000000000017: user <>: incoming packet BINDING processed, success

712: session 000000000000000017: closed (2nd stage), user <>, local 172.31.25.85:8080, remote <IP_ADDR>:63807, reason: allocation watchdog determined stale session state

712: handle_udp_packet: New UDP endpoint: local addr 172.31.25.85:8080, remote addr <IP_ADDR>:63807

712: session 000000000000000018: user <>: incoming packet BINDING processed, success

722: session 000000000000000018: user <>: incoming packet BINDING processed, success

732: session 000000000000000018: user <>: incoming packet BINDING processed, success

742: session 000000000000000018: user <>: incoming packet BINDING processed, success

752: session 000000000000000018: user <>: incoming packet BINDING processed, success

762: session 000000000000000018: user <>: incoming packet BINDING processed, success

772: session 000000000000000018: closed (2nd stage), user <>, local 172.31.25.85:8080, remote <IP_ADDR>:63807, reason: allocation watchdog determined stale session state

773: handle_udp_packet: New UDP endpoint: local addr 172.31.25.85:8080, remote addr <IP_ADDR>:63807

773: session 000000000000000019: user <>: incoming packet BINDING processed, success

783: session 000000000000000019: user <>: incoming packet BINDING processed, success

793: session 000000000000000019: user <>: incoming packet BINDING processed, success

803: session 000000000000000019: user <>: incoming packet BINDING processed, success

813: session 000000000000000019: user <>: incoming packet BINDING processed, success

823: session 000000000000000019: user <>: incoming packet BINDING processed, success

833: session 000000000000000019: closed (2nd stage), user <>, local 172.31.25.85:8080, remote <IP_ADDR>:63807, reason: allocation watchdog determined stale session state

833: handle_udp_packet: New UDP endpoint: local addr 172.31.25.85:8080, remote addr <IP_ADDR>:63807

833: session 000000000000000020: user <>: incoming packet BINDING processed, success

843: session 000000000000000020: user <>: incoming packet BINDING processed, success

853: session 000000000000000020: user <>: incoming packet BINDING processed, success

863: session 000000000000000020: user <>: incoming packet BINDING processed, success

873: session 000000000000000020: user <>: incoming packet BINDING processed, success

883: session 000000000000000020: user <>: incoming packet BINDING processed, success

893: session 000000000000000020: closed (2nd stage), user <>, local 172.31.25.85:8080, remote <IP_ADDR>:63807, reason: allocation watchdog determined stale session state

893: handle_udp_packet: New UDP endpoint: local addr 172.31.25.85:8080, remote addr <IP_ADDR>:63807

[Sean Roh]

I tried this before in Windows 7 setup (and you didn't mention about tested environment).

I seemed that Windows doesn't work properly when ALL UDP blocked.

DNS service will be definitely disabled.

By the way, you don't need to specify another STUN server if you already have in-house TURN server. Used that for STUN also.

[Roman Skvirsky]

WebRTC doesn't support TURN TCP 

[Sean Roh]

Relevant: https://groups.google.com/d/msg/discuss-webrtc/bq2tUi_guE4/IgxRfjFnKSQJ

[jean-francois garreau]

I have the same problem here but only with Chrome....

I'm working on a webRTC portal for a private network in my company and after googling a lot, i imagine that my solution is around TCP/ UDP consideration.... So I install for the tests a turn server on a VM on my computer (ubuntu 12.04 and turn server https://code.google.com/p/rfc5766-turn-server). I update the turnserver.conf to disable udp (no-udp and no-udp-relay)

What is strange, is that it works for Firefox but for chrome, it doesn't work, the video / rtcdatachannel, doesn't work at all. I have to turn off the firewall to make it work ! 

Here my webrtc configuration in my application : 

pc_config : webrtcDetectedBrowser === 'firefox' ? {

'iceServers':[

{'url':'stun:23.21.150.121'},

{'url':'turn:MYIPADRESS:3478?transport=tcp', 'username':'_________', 'credential':'_____'}

]

} : {

  'iceServers': [

  {'url': 'stun:stun.l.google.com:19302'},

  {'url':'turn:MYIPADRESS:3478?transport=tcp', 'username':'_________', 'credential':'__________'}

  ]

  },

pc_constraints : {

 'optional': [

   {'DtlsSrtpKeyAgreement': true},

   {'RtpDataChannels': true}

]},

sdpConstraints : {'mandatory': {

 'OfferToReceiveAudio':true,

 'OfferToReceiveVideo':true }

}, 

I'm using Chrome 39 / Firefox 33 and 34 and my computer is under Windows 7 64bits

I have no idea to how to investigate more the problem and how to solve it.... Can someone help me ?

regards

[Justin Uberti]

Does it work when using your server in this page? 

http://googlechrome.github.io/webrtc/samples/web/content/peerconnection/trickle-ice/

[Oleg Moskalenko]

I tested Amazon EC2 instances with rfc5766-turn-server installed and with Coturn installed, in both cases the Trickle ICE page shows valid relay candidates.

[Oleg Moskalenko]

I have a similar problem reported in my forum, when Firefox works fine with a TURN server but Chrome does not:

https://groups.google.com/forum/#!topic/turn-server-project-rfc5766-turn-server/kzZ77Z96s3A

I guess somebody from the Chrome team has to take a look into it (and try different TURN servers).

[Oleg Moskalenko]

I did more testing, to compare Firefox and Chrome. I used my test coturn server 54.188.39.119 with the username ninefingers and password youhavetoberealistic:

On the "trickle ICE" page. Chrome creates only one relay candidate and multiple other candidates, while Firefox creates just two relay candidates:

Chrome:

Time	Component	Type	Foundation	Protocol	Address	Port	Priority
0.001	1	host	2233644208	udp	172.17.17.111	41689	126 | 32542 | 255
0.001	2	host	2233644208	udp	172.17.17.111	41689	126 | 32542 | 255
0.001	1	host	2999745851	udp	192.168.56.1	43247	126 | 32286 | 255
0.001	2	host	2999745851	udp	192.168.56.1	43247	126 | 32286 | 255
0.032	1	srflx	74101252	udp	76.126.9.134	41689	100 | 32542 | 255
0.033	2	srflx	74101252	udp	76.126.9.134	41689	100 | 32542 | 255
0.101	1	host	3416344640	tcp	172.17.17.111	0	90 | 32542 | 255
0.102	2	host	3416344640	tcp	172.17.17.111	0	90 | 32542 | 255
0.102	1	host	4233069003	tcp	192.168.56.1	0	90 | 32286 | 255
0.102	2	host	4233069003	tcp	192.168.56.1	0	90 | 32286 | 255
0.114	1	relay	10079665	udp	54.188.39.119	53528	2 | 32542 | 255
0.114	2	relay	10079665	udp	54.188.39.119	53528	2 | 32542 | 255
9.553	Done

Firefox:

Time Component Type     Foundation      Protocol      Address     Port         Priority 0.036 1 srflx     1 UDP 76.126.9.134     38530 100 | 32767 | 255 0.037 1 relay         2 UDP 54.188.39.119     62768 5 | 32767 | 255 0.072 2 srflx     1 UDP 76.126.9.134     60802 100 | 32767 | 254 0.072 2 relay     2 UDP 54.188.39.119          63457 5 | 32767 | 254 20.103 Done

[Justin Uberti]

If you check the "gather unbundled RTCP candidates", you will get two separate relay candidates, like firefox. 

I did try that address with transport=tcp though and I didn't get any relay candidates. Is it set up for TCP transport?

[jean-francois garreau]

I don't really know what to test but here is my results : 

In each case, the url is turn:192.168.56.101:3478?transport=tcp and I remove stun url from the test

• With udp activate on turnserver.conf 

With Chrome : 

With FireFox : 

• With the flag no-udp and no-udp-relay in turnserver.conf
  

With Chrome

With Firefox : 

[Oleg Moskalenko]

Jistin, yes, it is set for all protocols - udp, tcp, tls, dtls.

[Oleg Moskalenko]

I tried that with server turn:54.188.39.119?transport=tcp and I am seeing UDP relay candidates - both in Firefox and in Chrome Mac OS X versions).

I am behind a very bad hotel Wi-Fi but it is still working.

Oleg

[Oleg Moskalenko]

That's what I am getting with turn:54.188.39.119?transport=tcp

When we are using TCP protocol as as the client-TURN-server protocol, the relay protocol is still UDP (if we are not using TURN TCP relay).
That is why the "protocol" is still "UDP", I guess.

Time	Component	Type	Foundation	Protocol	Address	Port	Priority

0.001	1	host	3753130141	udp	172.16.1.16	55831	126 | 32542 | 255
0.002	2	host	3753130141	udp	172.16.1.16	55243	126 | 32542 | 254
0.102	1	host	2436351085	tcp	172.16.1.16	0	90 | 32542 | 255
0.102	2	host	2436351085	tcp	172.16.1.16	0	90 | 32542 | 254
0.159	1	srflx	1995159368	udp	100.9.93.230	55831	100 | 32542 | 255
0.162	2	srflx	1995159368	udp	100.9.93.230	55243	100 | 32542 | 254
0.999

2

relay

10079665

udp

54.188.39.119

49576	1 | 32542 | 254
1.014

1

relay

10079665

udp

54.188.39.119

50099	1 | 32542 | 255
1.014	Done

[Justin Uberti]

That looks like what I would expect. Note the type preference of '1' for the relay candidates, indicating use of TCP transport for TURN.

[Nazmus Shakeeb]

Chrome doesn't support TURN TCP  ( https://tools.ietf.org/html/rfc6062 ). So TCP relay is only possible when caller and callee both create udp type allocation in the turn server using TCP.

I use the following URL to test TCP relay and Chrome works fine with Eyeball's turnserver. Although I have not tested but it should work fine with google turnserver.

http://54.165.95.20:8008/tcp_relay.html

I have attached tcp_relay.html.

TCP relay can be confirmed by Wiresherk. No need to create UDP block environment to test this as tcp_relay.html only send packet using TCP. 

If UDP blocked environment is created then DNS port 53 should be kept open for UDP.