4 Replies Latest reply on Jul 19, 2010 12:52 AM by Michael Thornburgh

    UPnP support for Flash p2p?

    praveenbm

      Hi all,

       

      I use a wireless router that supports uPnP in my home and I tried to test Stratus and Flash p2p Sample Application (VideoPhone - http://labs.adobe.com/technologies/stratus/samples/). Me and my colleague have the latest flash plugin installed.

       

      I was trying to evaluate Flash player capabilities when it comes to p2p AV chat like skype.

       

      Scenario 1:

       

      I was unable to use VideoPhone in the above setting. I was basically able to connect to Stratus but could not call my colleague. The same thing happened with my colleague when he tried to call me.

       

      In the status tab of the VideoPhone I could see that the app is able to retrieve my colleague's peerID when I call him but times out after that. (I even disabled windows firewall to be sure)

       

      Skype worked flawlessly as expected between us. (Skype has uPnP support to configure the router to forward incoming traffic)

       

      Scenario 2:

       

      All wifi routers come with DMZ setting that basically map the incoming tcp/udp to a particular interface on the network connected to them. When its enabled my laptop works as if it is on a public network.

       

      When i try to use the VideoPhone in this scenario, it works and me and my colleague were able to use the application as said.

       

      Analysis:

       

      Basically flashplayer will be listening on a port for incoming UDP traffic to make p2p possible. But it cannot configure the router to direct UDP traffic on the LAN as it does not support router configuration through uPnP.

       

      I am surprised that such important feature is missing in the implementation of p2p in flash. almost every one uses some form of home network.

       

      Please advise me in this regard.

       

      Thank you.

        • 1. Re: UPnP support for Flash p2p?
          Michael Thornburgh Adobe Employee

          Flash Player does not support UPnP.

           

          i would be interested in seeing your results of the test at http://cc.rtmfp.net

           

          there are only two cases in which UPnP would make any difference for RTMFP communications:

           

             1) your NAT is symmetric by default unless UPnP is used, in which case it becomes a flavor of cone NAT for that translation, AND your colleague is behind a symmetric NAT or port-restricted cone NAT

           

             2) your network topology is double-NATed, you want to communicate with someone beyond your inner NAT but inside your outer NAT, and the outer NAT doesn't do hairpinning

          • 2. Re: UPnP support for Flash p2p?
            praveenbm Level 1

            Here are my results from the cc.rtmp.net

            RTMO CC Test.png

            • 3. Re: UPnP support for Flash p2p?
              praveenbm Level 1

              my colleague is on a computer directly connected to the internet and i am behind a wifi home router connected to the internet with nat and upnp. there is no double nat involved here.

              • 4. Re: UPnP support for Flash p2p?
                Michael Thornburgh Adobe Employee

                the output of CC suggests that your NAT is a "kinda-symmetric* NAT" kind, where perhaps if you use UPnP it is no longer symmetric.

                 

                your colleague must have a port-restricted firewall that is blocking packets coming from you with a different source port than what your colleague expects (since your symmetric NAT has different outbound port translations for each destination endpoint).

                 

                if your colleague didn't have a firewall (or port-restricted cone NAT), you would be able to communicate since the situation would be exactly the same as communication with Stratus (to which you can connect).

                 

                * i say "kinda-symmetric" because *inbound* packets from foreign sources appear to be able to re-use an existing translation ("Can receive from same/different IP address, different UDP port number"), but *outbound* packets get a new translation for each distinct destination (the last "red/no" result).

                1 person found this helpful