in the log, i see entries that look like (trimming some stuff out):
Received stun message: 104 bytes
stun magic cookie not found.
Turn Remote Address = 76.74.170.78:10000
Successfully parsed StunMessage: STUN Indication: Send, id 1111804880114189070411418907041-17104569751
TurnAllocation sendDataToPeer: clientLocal=[UDP 0.0.0.0:3478] clientRemote=[UDP 84.27.132.206:51033] requested=[UDP 0.0.0.0:49152] peerAddress=[UDP 76.74.170.78:10000]
this is a TURN send indication, which makes a UDP packet get sent. in this case, it's sending to 76.74.170.78:10000. as of TURN draft 8, sending a packet like this is supposed to enable a return permission, so that packets coming from that "peer address" will be allowed back to the TURN client. however, almost immediately after this send indication in the log file, you'll see
Read 52 bytes from udp relay socket (76.74.170.78:10000):
sendDataToClient RemotePeer info not found - discarding data: clientLocal=[UDP 0.0.0.0:3478] clientRemote=[UDP 84.27.132.206:51033] requested=[UDP 0.0.0.0:49152] peerAddress=[UDP 76.74.170.78:10000]
so even though it just sent data to that address and is getting back a reply, AND it can look up the TURN client, it doesn't think it's seen anything from that address before, so it discards this packet rather than relaying it to the client (Flash Player).
that and complaining about "stun magic cookie not found" is bogus. i'm looking at the source code and a packet dump right now, and we're sending the "STUN magic cookie" from RFC 5389 (0x2112a442 in network byte order) just as it was defined for TURN draft 8.
it feels like there are bugs in that TURN server.
-mike
