How to test if a TURN server is working?

[Eric Davies]

I'm trying to determine whether the TURN server I've installed ( rfc5766turnserver ) is properly set up. To do so, I have 

• a server hosting my WebRTC application pages, webRTC signalling code, and the TURN server at ip address A,
  
• a Windows 7 box running Chrome Canary at ip address B,
  
• a Windows 7 box running Chrome Canary at ip address C.
  

B and C are on the same subnet.

During normal operation, there is no difficulty establishing a media sharing peer connection between B and C. Audio and video work fine.

To test the TURN server, I use the Windows 7 Firewall on B to block any incoming or outgoing connections to/from C. By my understanding, this should force ICE to use the TURN server because the direct path doesn't work. What actually happens is that the webrtc application thinks it's got a video stream coming in, but no audio/video packets get delivered. 

First question: Is this a valid way to check out the TURN server operation? If not, what would be?

Internal stuff I'm seeing:

  When the firewall rule is enforced,  two additional ice candidate messages get passed each way. The ones received by B look like:

{"type":"candidate","label":0,"id":"audio","candidate":"a=candidate:542695682 1 udp 1845501695 206.116.14.29 60011 typ srflx raddr C rport 60011 generation 0\r\n"}

{"type":"candidate","label":1,"id":"video","candidate":"a=candidate:542695682 1 udp 1845501695 206.116.14.29 60011 typ srflx raddr C rport 60011 generation 0\r\n"}

In chrome's debugging log, there is an intriquing set of lines that look like this (B is 192.168.1.104):

[3564:2428:0110/143454:VERBOSE1:stunport.cc(106)] Binding request timed out from 192.168.1.104:64631 ({28B9ACFD-67AE-4D72-BEA7-F457F4483049}) 

    

   If I enable verbose logging in the TURN server, and then try to establish the connection, I can see a short burst of additional activity (20 and 28 bytes of data) indicating that ICE is actually finding the TURN server, but I don't see the level of activity I'd expect if a stream of audio and video were going through it.

The TURN server comes with test clients which I've already used (running the test client from a different machine than the TURN server itself). The client seems to work fine and you can see intense activity being logged by the TURN server while it is being run.

I saw the similar behavior with the Restund Turn server.

Any thoughts/ideas would be most appreciated.

Eric Davies at Prilogic

[medusade]

I think the TURNS/STUN server is only used to establish the peer-2-peer connection. Once the connection is established, the audio and video data does not go through the server.

medusade

[Eric Davies]

On Sat, Jan 19, 2013 at 4:53 PM, medusade <medu...@cox.net> wrote:

I think the TURNS/STUN server is only used to establish the peer-2-peer connection. Once the connection is established, the audio and video data does not go through the server.

TURN and STUN are very different beasts. STUN operates as you describe, but not TURN. 

TURN servers are relays for when you can't establish a true peer to peer connection. 

From the Wikipedia page for TURN Servers:

While TURN is more robust than STUN in that it can traverse more types of NATs, it is prudent to note that a TURN communication relays the entire communication through the server requiring far more bandwidth than STUN protocol (which typically only resolves the public facing IP address then relays the information to Client and Peer for them to use in direct communication). For this reason, the ICE protocol mandates STUN usage as a first resort, and TURN usage when dealing with symmetric NATs, or other situations where STUN cannot be used.

But thank you in any case, I was beginning to wonder if my post was actually visible :-).

Cheers,

Eric.

medusade

--
 
 
 

--
Eric Davies

250 595-0639

[medusade]

Hi Eric, 

Thanks for the clarification. I wasn't sure that's why I said "I think". Maybe the problem is the STUN is being preferred.   We put a hack into the port server on the C++ app to make it prefer the relay server so recording could be done on the feeds. Again I'm just offering some possible clues to your problem.

medusade

[Harald Alvestrand]

I think srflx are stun candidates not turn. You want candidates with address A in them. They may appear later.

--
 
 
 

[Eric Davies]

The ICE protocol definitely causes the STUN server to be preferred. But your hack, or a variation on it, may be my solution!
    Working inside the browser, I don't have the ability to change the preferences so that stun appears first, and there seems to be a built-in list of stun servers it tries (outside of the ones I can supply), but I can use a network analyzing tool to figure out what stun servers it is using, and then use the fire wall to block them. Then, as long as my second client is on a different NAT, it shouldn't have a choice but to use the turn server. Thank you!!!

Eric.

[Eric Davies]

Hmmm, that sounds logical. I don't think I've seen any though.

[朱汉峰]

It's true for STUN, but not true for TURN, TURN is used to relay the media data, so the data will go through TURN server

[Luis Toro]

srflx candidates are STUN candidates, TURN candidates are relay instead of srflx, your idea to test TURN server may works, but you should remove STUN candidates, i've deployed the rfc5766-turn-server and it's possible to deactivate STUN support on the fly and use only TURN candidates.

I'm going to try to use your firewall idea to test my TURN server.

[Alexandre GOUAILLARD]

I would:

- not provide a stun server

- run turn-rfc5766 in 'nostun' mode

- filter the candidates to remove hosts (and keep only relay).

then, if the call goes through, your installation works.

--

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

For more options, visit https://groups.google.com/d/optout.

--

Alex. Gouaillard, PhD, PhD, MBA

------------------------------------------------------------------------------------

CTO - Temasys Communications, S'pore / Mountain View

President - CoSMo Software, Cambridge, MA

------------------------------------------------------------------------------------

sg.linkedin.com/agouaillard

• 
  

[Bryan Paluch]

To add a bit more to what Alex said. Also try setting just one turn ip/transport at a time. I've had problems with my turn configuration where turn udp would work, but tcp would fail. 

[Kushala Ram]

Hi,

Could you please tell me more about this. As I am new to Turn server and now getting to know the things, as I have faced few issues.

My issue is, I have created a Stun/Turn server of my own, but which live streaming is achieved only through some networks. While others fail.. 

Could you please suggest on this issue.

To unsubscribe from this group and stop receiving emails from it, send an email to discuss...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Kaiduan Xie]

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

Use above site to test your TURN server installation.

Best regards,

/Kaiduan

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/03d751d3-d3cd-47df-ba9b-7b6ba8d6be0d%40googlegroups.com.

--

Founder of Goodstartsoft

https://www.goodstartsoft.com