Hier ein Auszug aus einem Chat mit Adobe Ingenieuren zum Thema UDP Ports:
Question: Companies often ask me what they need to do to their firewall to allow Peer-Assist to work from our Cloud-based service through their firewall. I usually say they need to open port 1935 for UDP and ports 19350-65535 for UDP. Is this correct?
Answer: They need to allow UDP outbound on any port for P2P to work. When clients open direct connections to neighbors in the Group, these will happen over random UDP ports (whatever port number the kernel doles out when the client opened its socket).
Allowing traffic inbound over port 1935 and the high port range only needs to be done at the FMS end of the network (and you should be OK with only opening port 1935 as long as you allow UDP outbound from all these ports). Here as well, if you have any server-side RTMFP NetConnections/NetStreams/NetGroups participating as a peer in a Group you’ll need to allow UDP outbound on any port.
Here’s some more background on what’s going on with the RTMFP port configs at the server end:
The port range, by default 19350-65535, is defined because each FMSCore process that starts up (and the number of these depends on the number of app instances you have running and how they’re configured to distribute across FMSCore processes) has its own dedicated RTMFP listener/adaptor. Assume you have 3 app instances and each is configured to run in its own process; then you’ll have three FMSCore processes running and each will have its own RTMFP listener running. These listeners acquire the next available port from this range as they come online. So in this case, they’ll likely bind 19350, 19351 and 19352 (assuming those ports are available).
When a new client connects to the FMS, it initially is communicating with the FMSEdge process on UDP port 1935, and depending on the app instance the client is trying to connect to, it will be redirected (this is a low-level RTMFP capability, not a traditional RTMP redirect) to the port bound by the RTMFP listener for the FMSCore process hosting the target app instance. As part of this redirect, the RTMFP listener that the client is being redirected to is also notified that a client is being redirected to it, and it sends a packet out toward the client which should be sufficient to punch a hole in the firewall allowing the redirected clients traffic back in over the new port (say, 19351). Once redirected, all RTMFP traffic from this client to the app instance it connected to will happen at port 19351 at the server. The port number in use at the client end will be random, and this is the port that peers will try to talk to it at and it will talk out to them from which is why you want to allow UDP out from any port at the client end because the port it uses isn’t predictable.
Hier ein Link zu einem sehr guten RTMFP Connecivity Checker: http://cc.rtmfp.net/