6 Replies Latest reply on Nov 21, 2011 3:01 PM by Michael Thornburgh

    Request: http://cc.rtmfp.net/ source code


      Hi there,


      I'd like to inform my user about possible router problems just like http://cc.rtmfp.net/ does. I think it's for the best interest of Stratus if this functionality would be available to everyone and thus request the source code to be made public.


      Thanks in advance.




        • 1. Re: Request: http://cc.rtmfp.net/ source code
          Michael Thornburgh Adobe Employee

          there are two parts to the Connectivity Checker: the CC service/server and the client SWF.


          we can't give out the source code to the server at this time, as that includes a complete implementation of RTMFP.


          the client SWF just displays the results calculated by the server, and is very boring. instead of giving out the source code (which i'd have to get approval for) i'll just tell you that for a good time, make an RTMFP NetConnection to "rtmfp://cc.rtmfp.net/" and watch for NetStatusEvent.NET_STATUS code "NetConnection.ConnectivityCheck.Results".  do a thorough inspection of that event's info object.


          for example:



            private function NetStatusHandler(e:NetStatusEvent):void






                  Transcript("Event: " + e.info.code + " info:\n  ");

                  for(var i:String in e.info)

                    Transcript(i + ": " + e.info[i].toString() + "\n  ");






          (where function "Transcript()" prints something to a text box for you to see, or something)
          also look for e.info.motd on the NetConnection.Connect.Success event.
          note that the output of CC can be diagnostic, but it can't predict with 100% accuracy whether P2P connections will work (or fail).  there are several P2P scenarios it can't test for (like both peers behind the same firewall).  furthermore, connections to CC work slightly differently than to Stratus, so it's occasionally possible that a connection to CC will succeed but a connection to Stratus will not.
          • 2. Re: Request: http://cc.rtmfp.net/ source code
            tmedema Level 1

            Thanks Michael. Very helpful.

            • 3. Re: Request: http://cc.rtmfp.net/ source code

              i used code below for testing red light at cc.rtmfp.net.


              is it enough?


              var  nc:NetConnection;

              nc = new NetConnection();
              nc.addEventListener(NetStatusEvent.NET_STATUS, NetStatusHandler);


              function NetStatusHandler(e:NetStatusEvent):void{
                  var cc_passed:Boolean = true ;
                  if (e.info.code == "NetConnection.ConnectivityCheck.Results") {
                      if (!(e.info.receiveSameAddressSamePortAllowed)) {
                          cc_passed = false ;
                      if (e.info.sendAfterIntroductionAllowed) {
                          if (!(e.info.sendAfterIntroductionPreservesSourceAddress)) {
                              cc_passed = false ;
                          if (!(e.info.sendAfterIntroductionPreservesSourcePort)) {
                              cc_passed = false ;
                      } else {
                          cc_passed = false ;

              • 4. Re: Request: http://cc.rtmfp.net/ source code
                Michael Thornburgh Adobe Employee

                as i mentioned, the results from CC aren't 100% definitive, and the situation is more subtle and complicated than you probably realize.  whether or not the source address or port is preserved after an introduction is relevant depending on the kind of NAT or firewall the peer with which you want to communicate has.  you can't use the results from CC on just one computer to know whether or not it will be able to carry out any specific P2P communication.


                unless you thoroughly understand what these results imply, i strongly suggest you don't make any automatic decision based on a report from CC.


                in general, CC's report should be treated as diagnostic, not predictive.


                finally, CC isn't set up to handle a massive load of users like Stratus is.  please don't connect to it every time you make a connection to Stratus, and please disconnect as soon as you receive the report.


                for an excellent treatment of the different kinds of NATs out there and an introduction of how to interpret the a CC report, please see



                • 5. Re: Request: http://cc.rtmfp.net/ source code
                  gpulier Level 1

                  I know this an old thread but we have quite a few customers that are setting up FMS servers behind their firewalls and occasionally encounter rtmfp issues.  Having them goto cc.rtmfp.net is not helpfull since we are not concerned with the behavior of the connection between them and a server on the Internet.  Is there anyway Adobe can reconsider releasing the server-side code to the cc.rtmfp.net test?  Without it, troubleshooting internal rtmfp issues is quite challenging.  For instance, we have customers that are having mostly successfull rtmfp connections from different offices but once in a while they encounter an office (or computer) that seems to be connecting but not streaming peer-assist video or not connecting at all, etc...  Of course we can always goto the IT department and ask them to investigate the status of UDP traffic rules between certain locations but these requests can take months.  A tester could get to the bottom of the issue in seconds.

                  • 6. Re: Request: http://cc.rtmfp.net/ source code
                    Michael Thornburgh Adobe Employee

                    cc.rtmfp.net is a highly specialized, purpose-built RTMFP application, and is not an FMS application. it takes advantage of RTMFP protocol-level behavior to effectively do STUN, only from the server end instead of the client end.


                    the source code to this tool unfortunately can't be released without all of the RTMFP source code, which is not currently public. the service requires 3 IP addresses with 4 UDP ports to perform its tests. as such it is relatively complicated to configure and deploy, being approximately on par with deploying your own STUN server.


                    your own STUN server and STUN client would be able to give you the same diagnostic information. the only real advantage to the RTMFP connectivity checker is the "client" part is "Flash Player", so it's just in your browser already.