Debugging AWS-hosted Coturn Server - TURN working, STUN seems not to be

Question

Lots of setup information needed, questions coming at the end.
I am hosting a coturn server on an AWS ubuntu instance. I have configured it as follows in turnserver.conf

listening-port=3478
external-ip=(external ip)/(internal ip)
relay-ip=(internal ip)
tls-listening-port=5349
verbose
realm=(realm name)
min-port=10000
max-port=20000
lt-cred-mech
user=(username):(password)

AWS Security Groups: Ports 3478 and 5349 open to TCP and UDP traffic from all ipv4 and ipv6 addresses

I am testing this setup using Trickle ICE

Results

1. Server address = "turn:(public ip):3478/?transport=tcp" with username + credential. This seems to be working from what I can tell.

Client Side

Time    Type    Foundation  Protocol    Address Port    Priority    URL (if present)    relayProtocol (if present)
0.012   host    1419492315  udp e97c311c-26d9-4083-bfd9-bf004d561c76.local  65276   126 | 30 | 255      
0.124   relay   2654650372  udp (external ip)   16106   1 | 31 | 255    turn:(external ip):3478?transport=tcp   tcp
0.137   Done

Server Side

Jan 30 13:32:55 ip-(private ip) turnserver: 28: : session 000000000000000001: new, realm=<(realm name)>, username=<(username)>, lifetime=600
Jan 30 13:32:55 ip-(private ip) turnserver: 28: : session 000000000000000001: realm <(realm name)> user <(username)>: incoming packet ALLOCATE processed, success
Jan 30 13:32:55 ip-(private ip) turnserver: 28: : session 000000000000000001: refreshed, realm=<(realm name)>, username=<(username)>, lifetime=0
Jan 30 13:32:55 ip-(private ip) turnserver: 28: : session 000000000000000001: realm <(realm name)> user <(username)>: incoming packet REFRESH processed, success
Jan 30 13:32:55 ip-(private  ip) turnserver: 28: : session 000000000000000001: TCP socket closed remotely (client ip):43114
Jan 30 13:32:55 ip-(private ip) turnserver: 28: : session 000000000000000001: usage: realm=<(realm name)>, username=<(username)>, rp=3, rb=228, sp=3, sb=288
Jan 30 13:32:55 ip-(private ip) turnserver: 28: : session 000000000000000001: peer usage: realm=<(realm name)>, username=<(username)>, rp=0, rb=0, sp=0, sb=0
Jan 30 13:32:55 ip-(private ip) turnserver: 28: : session 000000000000000001: closed (2nd stage), user <(username)> realm <(realm name)> origin <>, local (internal ip):3478, remote (client ip):43114, reason: TCP connection closed by client (callback)
Jan 30 13:32:55 ip-(private  ip) turnserver: 28: : session 000000000000000001: delete: realm=<(realm name)>, username=<(username)>

2. Server address = "turn:(public ip):3478" with username + credential. I can't tell if this is working or not, a few things seem off.

Client Side

Time    Type    Foundation  Protocol    Address Port    Priority    URL (if present)    relayProtocol (if present)
0.008   host    3474466919  udp e97c311c-26d9-4083-bfd9-bf004d561c76.local  53711   126 | 30 | 255      
0.020   srflx   710326477   udp (client ip) 34426   100 | 30 | 255  stun:(external ip):3478 
0.100   relay   2859376398  udp (external ip)   14926   2 | 31 | 255    turn:(external ip):3478?transport=udp   udp
0.136   Done

The server stun:(external ip):3478 returned an error with code=701: STUN server address is incompatible.
Server Side

Jan 30 13:45:30 ip-(private ip) turnserver: 783: : session 000000000000000002: new, realm=<(realm name)>, username=<(username)>, lifetime=600
Jan 30 13:45:30 ip-(private ip) turnserver: 783: : session 000000000000000002: realm <(realm name)> user <(username)>: incoming packet ALLOCATE processed, success
Jan 30 13:45:30 ip-(private ip) turnserver: 783: : session 000000000000000002: refreshed, realm=<(realm name)>, username=<(username)>, lifetime=0
Jan 30 13:45:30 ip-(private ip) turnserver: 783: : session 000000000000000002: realm <(realm name)> user <(username)>: incoming packet REFRESH processed, success
Jan 30 13:45:31 ip-(private ip) turnserver: 784: : session 000000000000000002: usage: realm=<(realm name)>, username=<(username)>, rp=4, rb=248, sp=4, sb=384
Jan 30 13:45:31 ip-(private ip) turnserver: 784: : session 000000000000000002: peer usage: realm=<(realm name)>, username=<(username)>, rp=0, rb=0, sp=0, sb=0
Jan 30 13:45:31 ip-(private ip) turnserver: 784: : session 000000000000000002: closed (2nd stage), user <(username)> realm <(realm name)> origin <>, local (private ip):3478, remote (client ip):34426, reason: allocation timeout
Jan 30 13:45:31 ip-(private ip) turnserver: 784: : session 000000000000000002: delete: realm=<(realm name)>, username=<(username)>

3. Server address = "stun:(external ip):3478

Client Side

Time    Type    Foundation  Protocol    Address Port    Priority    URL (if present)    relayProtocol (if present)
0.004   host    1256359617  udp e97c311c-26d9-4083-bfd9-bf004d561c76.local  62013   126 | 30 | 255      
0.021   srflx   2080670375  udp (client ip) 38039   100 | 30 | 255  stun:(external ip):3478 
0.127   Done

The server stun:(external ip):3478 returned an error with code=701: STUN server address is incompatible.

Server Side

Jan 30 13:56:08 ip-(private ip) turnserver: 1421: : session 001000000000000001: realm <(realm name)> user <>: incoming packet BINDING processed, success

Questions

1. Why is the behavior different when I add the parameter transport=tcp to the stun address? It seems like leaving it off not only causes the client to attempt to connect to the STUN server (and generate an error); it also yields a different connection close reason (i.e. TCP connection closed by client vs allocation timeout).
2. Should I be specifying transport=tcp? It sort of seems like the TURN server is actually working fine when I include that.
3. What is up with my STUN setup? From what I can glean, it doesn't seem to be working at all.

I've tried changing various aspects of the turnserver.conf with no success

Answer 1

As the trickle-ice page says:

If you test a STUN server, it works if you can gather a candidate with type "srflx". If you test a TURN server, it works if you can gather a candidate with type "relay".

You have those. It further says

Note: errors from onicecandidateerror above are not neccessarily fatal. For example an IPv6 DNS lookup may fail but relay candidates can still be gathered via IPv4.

which is what is happening.

Note that you will also need to open the relayed port range for udp.