5 Replies Latest reply on Jun 21, 2013 2:56 AM by flmmaas

    Is fallback to rtmfp via server a valid approach?

    flmmaas

      Hi,

       

      We are in the process of moving from Cirrus to own FMS 5 server ( upgraded from 3.5 ).

      Would love to reap UDP related benefits even in case we have to fallback to server due to NAT issues.

      I see this work in general, however, one client is behind a symmetric NAT, hence cannot connect peer-to-peer, but also is he not able to connect to server using rtmfp.

      I tested the fallback by closing down UDP in the firewall between peers, but didn't test specifically with symmetric NAT routers.

      Is this expected behaviour?

      I didn't expect a relationship between the NAT hole punching capability and the use of UDP as a streaming protocol.

      The VideoMeeting sample app does fallback to rtmp, as we had it before ( on 3.5 ), be we were hoping for the lower UDP related latency by using rtmfp instead.

      Do you think this is a valid approach?

       

      The cc.rtmfp.net server show this result:

      rtmfp.png

       

      Kind regards,

      Frans Maas

        • 1. Re: Is fallback to rtmfp via server a valid approach?
          Michael Thornburgh Adobe Employee

          most likely you're having trouble connecting to your FMS because your FMS is behind a NAT.  if you're running at Amazon AWS then you're definitely behind a NAT.  FMS must be configured to know about its own translation in order for clients behind symmetric NATs to be able to connect.  this is because the initial connection from the client to FMS is to the "fmsedge", which redirects to an "fms core" process.  the edge process needs to know the translated address of the core in order to get the client (when behind a symmetric NAT or a port-restricted cone NAT or common firewalls) connected.

           

          you configure the translation in the RTMFP section of the Adaptor.xml FMS config file.

          • 2. Re: Is fallback to rtmfp via server a valid approach?
            flmmaas Level 1

            Hi Mark,

             

            Thanks for your answer.

            I have read the RTMFP section in my Adapter.xml file forward and backward, but I have no clue how to configure the translation you refer to.

             

            Two specs that comes close are:

            <ForwardIHelloMode>rhello</ForwardIHelloMode>

            and

            <Core>
              <HostPortList>

            <HostPort>:19350-65535</HostPort>

              </HostPortList>
            </Core>

             

            Please hold my hand, Thanks!

            Frans

            • 3. Re: Is fallback to rtmfp via server a valid approach?
              Michael Thornburgh Adobe Employee

              it is the HostPortList section.  the comments in that section should explain it to you.  in particular, look at the example at the end using the "public" attribute. that's exactly your situation (where the "public" address is different than the local address).

               

              if your public address is 192.0.2.5, and the ports are mapped directly (so public port 19350 is mapped to local port 19350), then the entry might look like

               

              ...

                  <HostPortList>

                     <HostPort public="192.0.2.5:19350-65535">:19350-65535</HostPort>

                  </HostPortList>

              ...

               

              if you need more help than that, you should probably ask in the FMS forums.

              • 4. Re: Is fallback to rtmfp via server a valid approach?
                flmmaas Level 1

                Thanks Michael, I see what you mean.

                • 5. Re: Is fallback to rtmfp via server a valid approach?
                  flmmaas Level 1

                  My service provider has confirmed that the server is not NATted, but servers have public ip addresses.

                  Nevertheless, the servers do have MULTIPLE public addresses:

                   

                  Public rtmfp-core addresses for listener _defaultRoot_ are: 127.0.0.1:19352;46.22.183.161:19352;46.22.183.163:19352;46.22.183.164:19352

                   

                  After the change that you suggested it is now:

                  Public rtmfp-core addresses for listener _defaultRoot_ are: 46.22.183.164:19350

                   

                  The address used by clients for the FMS server is 46.22.183.164.

                   

                  Can you comment on this?

                   

                  Meanwhile waiting for my client to confirm whether it does now work, or not.