TURN Server Recommendations

[Bridger Maxwell]

Hi,

I am looking for a TURN server to use on Amazon EC2. I tried out a couple today, and neither one worked. I don't know if the errors were misconfiguration or incompatibility, so I would appreciate if someone could point me to a server they know works.

I tried restund (http://www.creytiv.com/restund.html) and would get the client-side error:

Received TURN message with invalid message integrity, msg_type=259

It looked like this was because the message back from the server was missing the STUN_ATTR_MESSAGE_INTEGRITY attribute.

I tried TurnServer (http://turnserver.sourceforge.net) and got a little more success. I would get spotty audio (no video or datachannel) and then the client would log the following error repeatedly:

Received TURN channel data message with incorrect length, len=130

Thank you in advance for any recommendations! I am also not tied to EC2, if there is a better hosting service.

- Bridger Maxwell

[Justin Uberti]

We have used restund and it has worked well with Chrome (since Chrome 24). 

- Bridger Maxwell

--
 
 
 

[Warren McDonald]

Hi,

the problem with AWS and TURN, is that AWS only provides NAT to instances. For most TURN implementations you need a routed Internet address to the host, NOT via NAT. This is for a few reasons, but mostly as TURN servers replies to ICE use the addresses that they receive the requests on, which end up being generated with the internal NATed address and therefore fail badly.   

There was one TURN solution that I had tried that allowed operation behind NAT, with a config parameter to specify the external address. It did not meet other requirements, so I did not proceed with it.  

There are many virtual server offerings out there, that are not considered true Cloud offerings like AWS, but fit the bill nicely. You only need small CPU and memory, one (or two, for some TURN implementations) real internet addresses and lots of cheap bandwidth. In a multiparty call with good endpoint bandwidth, even if only one party needs TURN all other parties will have to relay to that address through TURN, so this can add up quickly.

As Justin says, Restund is stable and works well. It is a bit lacking documentation and some feature support.

I am currently testing rfc5766turnserver project from http://code.google.com/p/rfc5766-turn-server. It has very complete features and is well documented and the authors are responsive to reported bugs. Of particular note is TLS and DTLS support which will be essential for protection of deployed production servers. Support for TLS in Chrome is (reportedly) imminent.

Cheers,

Warren          

[Justin Uberti]

Yes, I forgot to mention this. 

We modified restund to return the instance public IP (on Google Compute Engine, not AWS) and it works OK.

--
 
 
 

[Ralph Giles]

On 13-01-23 10:15 PM, Justin Uberti wrote:

> We modified restund to return the instance public IP (on Google Compute
> Engine, not AWS) and it works OK.

We applied an extant patch to do the same thing for our stun server,
currently running on AWS.

http://www.powerpbx.ru/blog/wp-content/uploads/stund.patch

-r

[Warren McDonald]

The rfc5766turnserver project has just added support for running behind NAT

"added -X or --external-ip option to define a SINGLE "external" IP address that will be used in XOR-RELAYED-ADDRESS response attribute."

I have not tested this yet, but will very soon.

Cheers,

Warren  

On Wednesday, 23 January 2013 16:50:26 UTC+11, Bridger Maxwell wrote:

[Jesse Ezell]

I'm trying to get rfc5766turnserver running in EC2. Looks like STUN requests are working properly, since I see srflx candidates, but the TURN connections never appear to happen (should be looking for "A" candidates, correct?).

Have ports 3478/24378 TCP/UDP open inbound

Testing with:

turnserver -v -X EXTERNAL_IP -u user:password --no-tls --no-dtls

Any ideas what steps I should take to troubleshoot or what is probably happening?

[Justin Uberti]

"A" candidates?

Note that if stun is sufficient, turn won't ever be used.

--
 
---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.

To unsubscribe from this group, send email to discuss-webrt...@googlegroups.com.

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

[Jesse Ezell]

STUN doesn't appear to be sufficient because the video / audio isn't happening when I put the clients on different networks that can't communicate without TURN. I never see any candidates appear with the TURN server public address in them. The TURN server does appear to be creating connections, but they just get closed.. assuming they aren't actually getting used for some reason. Not sure how to troubleshoot what could be causing the problem.

[Jesse Ezell]

Looking at wireshark shows that the relay addresses are being allocated by the turn server and that the relayed address matches the public IP:

STUN 110 Allocate Success Response XOR-RELAYED-ADDRESS: XXX.XXX.XXX.XXX:51632 XOR-MAPPED-ADDRESS: XXX.XXX.XXX.XXX:56456 lifetime: 596

However, after the allocation I don't see a candidate come through in the client with that address. Enabled chrome logs and tailed the log file, but don't see anything useful for troubleshooting TURN/STUN connections. What's the best way to debug the next steps in the connection process and get a handle on why things are failing?

[Jesse Ezell]

So, got chromium building on my machine and it looks like the packet that rfc5766turnserver returns is failing the hash check when -X is used. Guessing it's on the fcc5766turnserver side, not chrome, but at least that explains what is happening:

!StunMessage::ValidateMessageIntegrity(data, size, hash()))

[Jesse Ezell]

For anyone that runs into a similar problem in the future, it looks like you have to explicitly turn on fingerprinting and message integrity in the turnserver command line or it doesn't add HMACs and fingerprints to relay requests (does it for normal STUN requests though). In any case, this is the command line that did the trick:

turnserver -o -X 23.23.238.173 --no-tls --no-dtls -a -b turnuserdb.conf -f -r myrealm

[Oleg Moskalenko]

Hi Guys,

For those who are using (or going to use) rfc5766turnserver: download the new version, 1.5.2.0, from our site http://code.google.com/p/rfc5766-turn-server/downloads/list . It has several NAT and WebRTC bugs fixed.

Thanks
Oleg

On Wednesday, February 6, 2013 1:35:10 PM UTC-8, Jonathan Ekwempu wrote:

Hi Warren,

It would be interesting to know the outcome of your tests using rfc5766turnserver. I want to install it in AWS VPC and I am going to count a lot on your experience with it. Please don't be irritated if I ask you some basic questions on installation and configuration of STUN/TURN servers. I really do not have any previous knowledge about them. WebRTC made me to start looking into them.

Thanks,

Jonathan Ekwempu

[Warren McDonald]

Thanks Oleg

Warren 

--

 
---
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/groups/opt_out.
 
 

--

Warren McDonald

[Oleg Moskalenko]

We just found more "specifics" (a polite term) in how WebRTC libraries work with STUN and TURN.
I put workarounds in version 1.5.2.1, please download that.

Thanks
Oleg

[Warren McDonald]

Hi Jonathan,

My tests have gone well as far as I can for WebRTC support with Chrome. The more advanced features I was looking for I am not able exercise as Chrome does not support TLS or TCP Transport yet. 

The authentication support is good,with both static configuration available and dynamic support through auth file manipulation. This will come in handy to allow on the fly generation of auth tokens in our web app.

Simple way to tell if you are getting TURN connections is to set log to verbose and then grep for "UDP connection" in the logs. Using tcpdump in the background will also show the UDP relay ports allocated to the peers by IP address.

Cheers,

Warren    

On Thursday, 7 February 2013 08:35:10 UTC+11, Jonathan Ekwempu wrote:

Hi Warren,

It would be interesting to know the outcome of your tests using rfc5766turnserver. I want to install it in AWS VPC and I am going to count a lot on your experience with it. Please don't be irritated if I ask you some basic questions on installation and configuration of STUN/TURN servers. I really do not have any previous knowledge about them. WebRTC made me to start looking into them.

Thanks,

Jonathan Ekwempu

On Monday, January 28, 2013 3:50:42 AM UTC-5, Warren McDonald wrote:

[Oleg Moskalenko]

Hi Keith,

you can try our server, it  supports both FINGERPRINT and operation behind NAT:

http://code.google.com/p/rfc5766-turn-server/

Regards,
Oleg

On Friday, February 22, 2013 2:45:53 AM UTC-8, Keith Wansbrough wrote:

Hi Justin,

You say elsewhere that Chrome requires FINGERPRINT to be turned on, but as far as I can see restund-0.4.2 has no support for FINGERPRINT. Have you made local changes to implement this? Are there any other changes you had to make? We've already made a change to support operation behind a NAT, so we're aware of that one.

Thanks.

--KW 8-)

[Keith Wansbrough]

Thanks Oleg! We did try it, and it works great. Have you thought about integrating with an external user database of usernames and HA(1) values?

We're still interested in trying restund too - we already have it working for STUN, just not TURN.

Cheers,

--KW 8-)

[Oleg Moskalenko]

Hi Keith

we do have the external usernames/keys database in our plans. I cannot say exactly when it will be completed. We are having requests on this functionality, so probably we'll speed it up.

Regards,
Oleg

[Keith Wansbrough]

That's great, thanks.

--KW 8-)

[Justin Uberti]

Oleg, I would be interested to know more about these "specifics" you mention.

We all want things to work consistently and correctly - if you see behavior from Chrome that doesn't seem to match the TURN spec, please file a bug in the WebRTC issue tracker, and cc me.

[Justin Uberti]

Chrome requires FINGERPRINT in the ICE messaging, but FINGERPRINT is not needed in the TURN messaging, as per RFC 5766 (apologies if I was unclear before).

We did not have to make any changes to restund other than to allow the public IP to be specified from the config file.

On Fri, Feb 22, 2013 at 2:45 AM, Keith Wansbrough <kei...@lochan.org> wrote:

Hi Justin,

You say elsewhere that Chrome requires FINGERPRINT to be turned on, but as far as I can see restund-0.4.2 has no support for FINGERPRINT. Have you made local changes to implement this? Are there any other changes you had to make? We've already made a change to support operation behind a NAT, so we're aware of that one.

Thanks.

--KW 8-)

On Wednesday, 23 January 2013 20:58:25 UTC, Justin Uberti wrote:

[Oleg Moskalenko]

Hi Justin

I am not a WebRTC developer, I am just supporting the users who are using our TURN Server with WebRTC. So I fully rely on the users to test it and to deal with WebRTC bugs. I had to fix several things by requests from the users. I remember two things:

1) SOFTWARE attribute appearing in the beginning of the TURN message may cause problems, but this may be a phantom problem.
2) WebRTC client is not able to handle the authorization challenge from STUN server. It requires STUN server to be running in the "public" mode, always. It can handle TURN challenges correctly, but not the STUN challenges. But according to RFC5389, the Binding request may require authentication in the same way as the TURN requests. What I've seen the the wireshark traces from our customers, the WebRTC client simply does not handle this situation. If the same server is used as both STUN and TURN server (as ours) it may be a problem.

Regards,
Oleg

[Justin Uberti]

Thanks for explaining. I will look into #2.

Would be interested to hear more about #1 if you can replicate it. 

[Oleg Moskalenko]

Hi Kai,

error 438 means that the nonce value becomes obsolete and the client must re-authenticate. This is from RFC5389:

 If the response is an error response with an error code of 438 (Stale
   Nonce), the client MUST retry the request, using the new NONCE
   supplied in the 438 (Stale Nonce) response.  This retry MUST also
   include the USERNAME, REALM, and MESSAGE-INTEGRITY.

This is a security feature. It seems like WebRTC client does not support this properly. We can do two things:

1) you can file a bug in WebRTC bug lists.
2) I can make this feature optional in the TURN Server.

Thanks
Oleg

On Tuesday, March 19, 2013 2:11:56 AM UTC-7, Kai wrote:

Hi,

I´m currently using the rfc5766-turn-server to realize a videochat via WebRTC in Googles-Chrome. So the before mentioned tips, regarding the required

realm and authentication helped very much to get this up and running. Thanks.

But unfortunately I ran in a unexpected problem. When the peers got connected via the relay-/turn-server, the connections are breaking down after 18 minutes.

I tried this several times here at work and yesterday also from home, so I´m sure, that this has nothing to do with our network at work.

In the console of the webbrowser I can see that there are new onicecandidate-Events fired, at the moment when the connection get lost.

I´m not able to say, where the cause of this problem really lies (turnserver-, or WebRTC-Implementation in Webbrowser).

I´m using version 1.6.0.1 of the rfc5766-turn-server and disallowed the direct connection between the peers, via firewall rules. So all traffic between

the peers are relayed over the turn-server.

Does anybody had a similar problem, or an idea what the cause of the problem is?

Thanks in advance

Kai

Am Mittwoch, 30. Januar 2013 06:16:13 UTC+1 schrieb Oleg Moskalenko:

That's correct. You have to turn on, explicitly, the authentication and the fingerprinting. Not all TURN environments need them, and both features take the performance toll. The TURN Server is very performance-oriented, so by default those features are off.

Regards,
Oleg

[Justin Uberti]

Please file a bug on this. WebRTC should handle nonce expiration properly. I'm surprised it doesn't, but it was probably never extensively tested.

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

[Oleg Moskalenko]

Kai, please file a bug in WebRTC. In the traces that you sent me, I see that the client is not trying to re-authenticate itself after receiving 438 response.

I'll make this feature optional in the TURN Server. According to RFCs, this extra security may be an optional feature.

Thanks
Oleg

[Kai]

Hi,

reported the bug at https://code.google.com/p/webrtc/issues/detail?id=1520

[Oleg Moskalenko]

"stale-nonce" functionality (enhanced security with 438 error) is optional in rfc5766-turn-server, starting with version 1.6.1.0.
By default, it is OFF.

Oleg

[Kai Schreyer]

Hi Oleg,

I am currently running a Videochat with 3 peers and your rfc5766-turn-server in version 1.6.1.0. All peers cannot communicate with each other directly. So all WebRTC traffic is routed through the TURN-Server.

The session runs now for 30 Minutes, without any problems.

Great work. Thanks a lot for "stale-nonce" configuration option.

Regards Kai

[Oleg Moskalenko]

Kai, I just found serious authentication error in 1.6.1.0, I fixed it in 1.6.1.1.

Oleg

[Tom]

Hey Oleg,

I'm trying to install turnserver on a debian system and getting the following error, any thoughts?

turnadmin: error while loading shared libraries: libevent-2.0.so.5: cannot open shared object file: No such file or directory

I've installed libevent and configure/make/install etc. I get this error when running turnadmin or turnserver after building.

Cheers!

[Oleg Moskalenko]

Hi Tom

the error actually says all you need: there is no dynamic libraries path to the libevent in your system. You have to set LD_LIBRARY_PATH environment variable before starting the server. You can do it either in your system /etc files, or in a script (see for example examples/scripts/secure_relay.sh script). You have to add /usr/local/lib to LD_LIBRARY_PATH.

Regards,
Oleg

[Kai Schreyer]

Hi Oleg,

tested version 1.6.1.3 with my standard config (Videochat with 3 peers, which cannot communicate with each other directly) for 1 hour.

Everything worked smoothly.

Kai

[Oleg Moskalenko]

Hi Keith,

we added support of PostgreSQL as the external database for the users. See our latest version 1.7.0.0. The database usage is well documented in the INSTALL and README files, and script examples are provided.

Now, lots of users can be handled :)

http://code.google.com/p/rfc5766-turn-server/

Regards,
Oleg

On Sunday, February 24, 2013 2:36:01 PM UTC-8, Keith Wansbrough wrote:

[Keith Wansbrough]

Thanks Oleg - that's great!

Cheers,

--KW 8-)

[Jonathan Ekwempu]

Oleg, any plans to support other databases and in particular MySQL? You are doing a great job building rfc5766-turn-server. Keep it up.

Jonathan

[Oleg Moskalenko]

Thanks, Jonathan.

We definitely would like to add MySQL support but this is not in the very urgent plans. Modern days PostgreSQL works pretty well for the purpose - it is simple, it is everywhere, SQL-compliant and the performance is pretty good. Also, everything in the project has BSD license, MySQL has a different license. If there will be many MySQL requests, we may speed up MySQL support, but it will take some time.

Regards,
Oleg

[Ken Smith]

And just to complicate your life a bit more (sorry!) - any chance of Windows support?

Ken Smith
Cell: 425-443-2359
Email: smit...@gmail.com

Blog: http://blog.wouldbetheologian.com/

[Jonathan Ekwempu]

Oleg, thanks for your response. Some of us already have user and authentication information already residing in MySql and running in the cloud (some companies do). It would not be wise to switch servers (additional cost etc) just to run a TURN server. Anyway, the final decision is yours.

Thanks,

Jonathan

[Takahiro Ichihashi]

+1 for MySQL support. Anyway thanks for great work, Oleg.

2013/3/25 Jonathan Ekwempu <onyi...@gmail.com>

[Oleg Moskalenko]

Thanks for the input, Jonathan. I'll see what I can do.

Regards,
Oleg

--
 
---
You received this message because you are subscribed to a topic in the Google Groups "discuss-webrtc" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/discuss-webrtc/ukNUoHeWm2I/unsubscribe?hl=en.
To unsubscribe from this group and all its topics, send an email to discuss-webrt...@googlegroups.com.

[Oleg Moskalenko]

Yeah, this does not make it any simpler :)

I can say only two things at the moment:

1) If any developer(s) would like to step into the project to "own" the Windows support - that would be awesome.

2) The easiest way to run a "toy" TURN server under Windows is:

              - install a Virtual environment (like VMWare or Virtual Box).

              - set a Virtual machine with an OS comfortable for you (Ubuntu, Debian, CentOS, PC-BSD, etc). You can even download a preset Solaris machine for Virtual Box (the same company makes them both).

              - install necessary tools (libevent and openssl, optionally PostgreSQL). The easiest OSs for those tools installation would be Ubuntu 12.04 and PC-BSD/FreeBSD 9 (they have the exact necessary native packages), I recommend them for novice *NIX users, for virtual environment for TURN server.

              - download and install TURN server.

              - configure TURN server.

Such an environment would support at least 10 or 20 video chats, more if the VM is properly configured on a powerful desktop.

For the real server systems, *NIX hopefully is not a problem for anybody these days. But I still would love to see "native" Windows support. We just do not have resources for that. If anybody wants to jump in, you are very welcome.

Oleg

--
 
---
You received this message because you are subscribed to a topic in the Google Groups "discuss-webrtc" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/discuss-webrtc/ukNUoHeWm2I/unsubscribe?hl=en.
To unsubscribe from this group and all its topics, send an email to discuss-webrt...@googlegroups.com.

[Oleg Moskalenko]

What you guys think about ODBC support ? We can add ODBC support and then any database can be used. MySQL has Connect/ODBC for that purpose. Would it be enough or a "native" MySQL support is totally necessary ? I just like to know the opinions.

Thanks
Oleg

[Jonathan Ekwempu]

Hi Oleg,

Most Java developers will prefer a Type 4 JDBC driver support. ODBC is not for a thin client. That said, what I would suggest is that you just offer database support and the user will decide whether to us JDBC or ODBC to access the database. JDBC and ODBC are just drivers.

Thanks,

Jonathan Ekwempu

[Oleg Moskalenko]

Jonathan, of course I understand what JDBC and ODBC are for. I mean server-side ODBC support. I can provide ODBC support in the TURN server, so the system administrator will have to install the appropriate ODBC driver for the particular database, and set the connection string - in the TURN server system. Then the TURN server will be able to use that database.

[Oleg Moskalenko]

As there were many requests on MySQL support, we added native support for MySQL in build 1.7.1.0. We now support both PostgreSQL and MySQL.

Option --sql-userdb="..." is used as connection string for PostgreSQL.

Option --mysql-userdb="..." is used as connection string for MySQL.

Regards,
Oleg
http://code.google.com/p/rfc5766-turn-server/

On Monday, March 25, 2013 9:14:39 AM UTC-7, ultravistor wrote:

[Oleg Moskalenko]

Pran, I answered in a separate thread.

On Friday, March 29, 2013 10:09:51 AM UTC-7, Pran Haran wrote:

Hi Oleg,

Are there any performance numbers available for the Turnserver application? For example how many relay clients can be supported in a specific EC2 VM type?

Pran

[Gili T.]

Note, on Windows you are supposed to add the path (/usr/local/bin in my case) to the PATH variable. I hope this helps others (I kept on looking for ldconfig which doesn't exist for cygwin).

Gili

[Oleg Moskalenko]

Lots of information about this TURN server is on this forum:

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

Oleg

[Sudheerkumar M]

Hi Oleg,

we are facing the similar issue too.

we have the #stale-nonce=600 flag commented but not removed from the conf file.
This issue happens only in the relay case and when the client (device) goes into an idle state. Any inputs, please?

On Tuesday, March 19, 2013 at 9:59:21 PM UTC+5:30, Oleg Moskalenko wrote:

Hi Kai,

error 438 means that the nonce value becomes obsolete and the client must re-authenticate. This is from RFC5389:

 If the response is an error response with an error code of 438 (Stale
   Nonce), the client MUST retry the request, using the new NONCE
   supplied in the 438 (Stale Nonce) response.  This retry MUST also
   include the USERNAME, REALM, and MESSAGE-INTEGRITY.

This is a security feature. It seems like WebRTC client does not support this properly. We can do two things:

1) you can file a bug in WebRTC bug lists.
2) I can make this feature optional in the TURN Server.

Thanks

Oleg

On Wednesday, 23 January 2013 16:50:26 UTC+11, Bridger Maxwell wrote:

Hi,

I am looking for a TURN server to use on Amazon EC2. I tried out a couple today, and neither one worked. I don't know if the errors were misconfiguration or incompatibility, so I would appreciate if someone could point me to a server they know works.

I tried restund (http://www.creytiv.com/restund.html) and would get the client-side error:

Received TURN message with invalid message integrity, msg_type=259

It looked like this was because the message back from the server was missing the STUN_ATTR_MESSAGE_INTEGRITY attribute.

I tried TurnServer (http://turnserver.sourceforge.net) and got a little more success. I would get spotty audio (no video or datachannel) and then the client would log the following error repeatedly:

Received TURN channel data message with incorrect length, len=130

Thank you in advance for any recommendations! I am also not tied to EC2, if there is a better hosting service.

- Bridger Maxwell

--
 

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.

To unsubscribe from this group, send email to discuss-webrt...@googlegroups.com.