Turn-server running on AWS is unresponsive

Question

I am struggling with this issue for nearly a month now, I am able to set up a rfc5766-turn-server( v3.2.3.1) on the EC2 instance without any issue.

When the TURN is listening on 3478, everything works fine, but on port 80, it works most times, but at certain intervals( occurs erratically) it becomes unresponsive, even restarting that process does not change anything. The process that I run parallely on port 3478 doesn't face this issue.

Command for running on port 80:

sudo turnserver -L INTERNAL_IP -X EXTERNAL_IP/INTERNAL_IP -r "someRealm" -a -o --no-udp -u test:test -n -a --no-sslv2 --no-sslv3 -v --cert cert.pem --pkey key.pem  --tls-listening-port 80

Command for running on port 3478:

sudo turnserver -L INTERNAL_IP -X EXTERNAL_IP/INTERNAL_IP -r "someRealm" -a -o --no-udp -u test:test -n -a --no-sslv2 --no-sslv3 -v --cert cert.pem --pkey key.pem  --tls-listening-port 80

I think, the issue is more AWS network related, less on turn server, but then again, I know very little about AWS or TURN servers. Has anyone faced this issue on port 80. I believe running on port 80 is important especially when the peers are behind corprate firewalls which blocks most ports.

logs when it is able to allocate successfully( I have changed internal ip of EC2 by INTERNAL_IP):

342: IPv4. Server relay addr: INTERNAL_IP:0
342: IPv4. Local relay addr: INTERNAL_IP:56216
342: session 000000000000000005: new, username=<test>, lifetime=600
342: session 000000000000000005: user <test>: incoming packet ALLOCATE processed, success
342: session 000000000000000005: user <test>: incoming packet ALLOCATE processed, success
342: session 000000000000000005: user <test>: incoming packet CREATE_PERMISSION processed, success
342: session 000000000000000005: user <test>: incoming packet CREATE_PERMISSION processed, success
343: session 000000000000000005: user <test>: incoming packet CHANNEL_BIND processed, success
343: session 000000000000000005: user <test>: incoming packet CHANNEL_BIND processed, success
353: session 000000000000000005: usage: username=<test>, rp=1039, rb=551685, sp=1009, sb=526100

logs when unresponsive( I noticed that it still shows the connection attempt, one difference being, it shows the IP of peer connecting and not the INTERNAL_IP as in success scenario):

392: IPv4. tcp or tls connected to: SOME_IP:41107
392: session 000000000000000007: user <>: incoming packet message processed, error 401
392: session 000000000000000007: user <>: incoming packet message processed, error 401
392: IPv4. tcp or tls connected to: SOME_IP:41108
392: session 000000000000000008: user <>: incoming packet message processed, error 401
392: session 000000000000000008: user <>: incoming packet message processed, error 401

Answer 1

You don't need to use 80 because of firewall (firewalls only block incoming not outgoing communication)

hope it helped

Answer 2

You didn't mention the TURN transport protocol you are running on the ports, but from the log of your port 3478 showing seems you are using 3478 as for your UDP transport type relay candidates. Hope you are not using port 80 for UDP as well, its might be TCP/TLS. In that case you can check the transport protocol for the allocation request client is sending to TURN server. If client is not using correct transport protocol to request relay candidate you may not get successful allocation response, TCP/TLS control connection can be used to gather UDP relay candidate as a fallback mechanism of RFC-5766 given that the TURN server you are using supports that fallback mechanism, otherwise client/server should have ICE-TCP implementation to get TCP types of relay candidate, but still you should get the error response as unknown protocol. Log printing as error 401 is TURN protocol log? then it means that its having some authentication problem. If EC2 instance is enabled for the correct inbound protocol traffic than you might not get any other problem because of using a EC2 instance, its might related with your TURN server configuration or supports.