the observed results don't make sense given the combinations that do work. if possible, re-run your experiments on the two failed paths to eliminate a transient network issue between AT&T and those other two ISPs.
if those two paths' failures persist, it would be interesting to see results from cc.rtmfp.net from affected clients at AT&T, Time Warner, and Wandering WiFi.
for each distinct ISP in that list, were the tests run from the same client in the same location and same network configuration (including wired or wireless)? or were different routers/end user networks/wifi base stations/computers/etc used between tests that succeeded and tests that failed at the common points (AT&T, TW, Wandering)? different networking equipment may have different NAT/firewall behavior, so for example, a computer at person A's house on AT&T might have a BEHAVEing NAT and RTMFP might work reliably to other ISPs, but person B also on AT&T might have a broken symmetric NAT that can cause problems when communicating with other symmetric or port-restricted cone NATs. depending on whether you performed a test from person A or B's networks, you could get different results even though they're both on AT&T.
I gathered all the data from the places we tested and had them take a screen shot from cc.rtmfp.net. I also asked for their modem and whether they connect wirelesly. Please find the compiled data below. I hope this helps.
this table indicates that there is one user (AT&T in Savannah, GA, at IP address 126.96.36.199) who was having connectivity problems. this user appears to have a symmetric NAT (SOURCE UDP PORT # IS PRESERVED FROM ORIGINAL CONNECTION = NO/RED). symmetric NAT (also known as "defective" IMO) will not work with RTMFP in certain circumstances: specifically where the other end is also a symmetric NAT or is a port-restricted cone NAT.
this user on AT&T had successful connections when communicating with others where their NAT allowed "CAN RECEIVE FROM SAME IP ADDRESS, DIFFERENT UDP PORT NUMBER = YES/GREEN", but did not have successful communication when that field was YELLOW/NO. that field being YELLOW/NO indicates at least a port-restricted cone NAT, which won't work P2P with a symmetric NAT.
these results appear to be caused by this user's router, not by AT&T. other AT&T users with different equipment (that doesn't exhibit symmetric NAT behavior) appear to work.
this user should reconfigure (if possible) or replace his/her defective router.
I will do furthur testing to see if this fixes the issue.