Testing TURN Relay

[Jo Yum]

I installed coturn (TURN/STUN server) on a Linux server with a public IP. The coturn server is working properly, according to the diagnostic scripts that come with it.

Then I tried to test coturn over the Internet, through it's public IP (say 1.2.3.4:3478), from browsers on different computers, but on the same subnet (192.168.1/24).

To begin testing, I did this to see what would happen:

var pc_config = {'iceServers': [

{'url': 'stun:0.0.0.0:0'}, 

{'url': 'turn:0.0.0.0:0?transport=udp','credential':''}

]};

No error messages, and the browsers connect perfectly, with good audio/video streams both ways.

This happens with two Chrome or two Firefox browsers. So apparently, WebRTC browsers don't need a STUN server, (let alone a TURN server), when the browsers are on the same subnet.

Then I did this to test coturn in STUN mode only:

var pc_config = {'iceServers': [

{'url': 'stun:1.2.3.4:3478'} // 1.2.3.4 is not the real IP!

]};

The connection worked again, but I can't tell if coturn was being used or not. Its log file doesn't show anything to suggest it was used.

To force the TURN relay, someone suggested filtering the candidates' sdp for the sub-string "typ relay" and using only those candidates. The problem is, there aren't any "typ relay" candidates to pick from.

Another idea was to put the two browsers on different subnets, even though both subnets are connected to the same ISP network. I haven't tried that yet.

Is there a practical way to test the TURN relay over the Internet, from two browsers connected to the same ISP network?

Thank you.

[Philipp Hancke]

Use http://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/

-- if you get relay candidates when testing only a TURN server, your TURN server is reachable and authentication worked. If you don't, you'll have to use wireshark and the turn server logs to figure out the issue.

(h/t jansson :-))

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/5e6422ce-5de2-43c8-b702-c8e213984f6d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jo Yum]

The tickle-ice tool running on Chrome collects these candidates when no TURN/STUN server is provided:

Time Component Type Foundation Protocol Address Port Priority

0.006 1 host 1019731727 udp 192.168.1.104 5956 126 | 32542 | 255

0.022 2 host 1019731727 udp 192.168.1.104 5957 126 | 32542 | 254

0.105 1 host 1917068287 tcp 192.168.1.104 0 90 | 32542 | 255

0.105 2 host 1917068287 tcp 192.168.1.104 0 90 | 32542 | 254

0.156 Done

Started turnserver with this command (not the real IP):

turnserver -V -z -L 1.2.3.4

The -z flag enables anonymous access. The -V flag is for verbose log output.

Added my coturn TURN server to tickle-ice (not the real IP):

turn:1.2.3.4:3478

No candidates are gathered in "relay" mode.

In "all" mode, the same candidates are gathered as when no TURN/STUN server is provided (see the above table.)

Any ideas how to get coturn working, or how to diagnose the problem?

Thank you

[Jo Yum]

On Thursday, June 18, 2015 at 12:15:42 PM UTC-8, Philipp Hancke wrote:

Use http://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/

-- if you get relay candidates when testing only a TURN server, your TURN server is reachable and authentication worked. If you don't, you'll have to use wireshark and the turn server logs to figure out the issue.

(h/t jansson :-))

Hi Philipp,

I don't get relay candidates when testing only my TURN server. 

I have Wireshark traces. What am I looking for in the Wireshark traces?

What am I looking for in the TURN server logs?

Thank you

[Jo Yum]

To Philipp, or anyone else,

Using tcpdump on my Linux server where coturn is running, I traced the STUN/TURN requests arriving at coturn port 3478, from Trickle-ICE on Chrome.

See: http://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/

This is the Wireshark trace of those requests:

No. Time Source Destination Protocol Length Info

1 0.000000 5.6.7.8 1.2.3.4 STUN 62 Binding Request

2 0.000290 5.6.7.8 1.2.3.4 STUN 62 Binding Request

3 0.047414 5.6.7.8 1.2.3.4 STUN 70 Allocate Request UDP

4 0.047580 5.6.7.8 1.2.3.4 STUN 70 Allocate Request UDP

5 0.097650 5.6.7.8 1.2.3.4 STUN 62 Binding Request

6 0.099869 5.6.7.8 1.2.3.4 STUN 62 Binding Request

7 0.147398 5.6.7.8 1.2.3.4 STUN 70 Allocate Request UDP

8 0.147613 5.6.7.8 1.2.3.4 STUN 70 Allocate Request UDP

9 0.297656 5.6.7.8 1.2.3.4 STUN 62 Binding Request

10 0.299877 5.6.7.8 1.2.3.4 STUN 62 Binding Request

11 0.350324 5.6.7.8 1.2.3.4 STUN 70 Allocate Request UDP

...

[snip]

...

37 9.552835 5.6.7.8 1.2.3.4 STUN 62 Binding Request

I changed the IP's and domain names in these listings, but the real IP's and domain names are correct.

I'm starting coturn like this:

turnserver -c /opt/coturn/turnserver-4.4.5.2/examples/etc/turntest3.conf

The config file (turntest3.conf) contains this:

listening-port=3478

tls-listening-port=5349

listening-ip=1.2.3.4

relay-ip=1.2.3.9

external-ip=1.2.3.4

#relay-threads=10

#fingerprint

lt-cred-mech

user=u:0

cert=/etc/nginx/ssl/example.com.crt

pkey=/etc/nginx/ssl/example.com.key

#mobility

verbose

realm=example.com

netstat commands on the Linux server, show how coturn is listening for STUN/TURN requests:

netstat -a | grep 'stun'

tcp        0      0 example.com:stun             *:*                         LISTEN

tcp        0      0 example.com:stuns            *:*                         LISTEN

udp        0      0 example.com:stuns            *:*

udp        0      0 example.com:stuns            *:*

udp        0      0 example.com:stuns            *:*

udp        0      0 example.com:stuns            *:*

udp        0      0 example.com:stun             *:*

udp        0      0 example.com:stun             *:*

udp        0      0 example.com:stun             *:*

udp        0      0 example.com:stun             *:*

netstat -a | grep '3478'

sctp                example.com:3478                                         LISTEN

netstat -a | grep '5349'

sctp                example.com:5349                                         LISTEN

Does the above mean that coturn is not listening for UDP? And if so, how do I fix that?

Why aren't the WebRTC TURN requests from Trickle-ICE answered by coturn?

Thank you.

[Nazmus Shakeeb]

>>Does the above mean that coturn is not listening for UDP? And if so, how do I fix that?

No. "udp        0      0 example.com:stun" means that someone is listening on STUN UDP port.

>>Why aren't the WebRTC TURN requests from Trickle-ICE answered by coturn? 

You can see coturn's log to get the answer. May be coturn is not receiving your request. 

Can you please add the output of the following command. ( you can replace your IP with a fake one but don't make other changes )

netstat -nap | grep 3478 

 

[Jo Yum]

Sorted. The Linux server ports were blocked for output !

Nazmus, "netstat -nap | grep 3478" --> all bindings owned by turnserver

Thank you !