the most important thing is it's mms.cfg, not mm.cfg. be sure you have the file in the correct location for your platform (for example, on the Mac it's "/Library/Application Support/Macromedia/mms.cfg"). this file is only read when Flash Player starts up. you may need to quit your web browser and restart it to ensure the file has been re-read.

if RTMFPTURNProxy is defined in your mms.cfg file, then Flash Player will attempt to open a connection to the TURN proxy when you create a NetConnection and connect it to an RTMFP URI, so if you have it configured correctly you should see traffic immediately. the TURN proxy then becomes an additional, remote interface for the NetConnection (in addition to your local IPv4 and IPv6 network interfaces). connections to the server and to peers are tried simultaneously through all available interfaces. typically, if a local interface can work, it will win the race. if they can't work, then the TURN interface will probably succeed eventually. Flash Player 10.0 adds an extra delay to the TURN interface to try to give more of a chance for the local interface(s) to work. however, we've found this behavior to mostly be undesirable, so the artificial delay may be changed or removed in a future release.

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

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.

I solved the bugs: magic cookie was tested and created in reversed order, and code made assumption that channelbind call was done, but Flash uses Send and Data Indications. Everything works perfect now.

And of course my next question now is: is there any other way we can configure the proxy name sowhere is the api? I haven't found it, and you haven't suggested it, but still want to give it a try.

We now have to bother end users as well as their IT support. It would be ideal if we could fully control this from the app.

I'm using Resiprocate 1.6 and I set RTMFPTURN proxy, and I changed ReturnConfig.cxx mAuthenticationMode(LogTermPassword) to NoAuthentication because I found that flash player support draft-08 without authentication, but I still kept getting "WARNING | 20100908-102816.647 | reTurnServer | RETURN | 3081141136 | RequestHandler.cxx:480 | Turn allocate request without authentication. Sending 401.". From mms.cfg I only can set the RTMFPproxy, I don't know how I can set username("test") from flash. Thanks a lot.

I tried to modify the requestHandler.cxx to set the username and password, now when my flex app connects to reTurn, it won't give me that error. But I got new error "Segmentation fault" from ./reTurnServer x.x.x.x 3478 5349 x.x.x.x 3479 when flash app connected to it