6
FLASH MEDIA SERVER 4.5 CONFIGURATION AND ADMINISTRATION
Deploying the server
Last updated 11/28/2012
Understanding the RTMFP Connectivity test
In some cases, symmetric NATs break peer-to-peer connectivity.
Flash Player can work with most cone NAT configurations and many firewall configurations. (There are some issues
with multiple layers of NAT and lack of “hairpinning” support.) However, symmetric NAT in combination with
certain firewall or NAT cases at the other end blocks the ability to establish a peer-to-peer connection. If one end is a
symmetric NAT with a single IP address, Flash Player cannot connect to peers behind other symmetric NATs or
behind port-restricted cone NATs (or port-restricted firewalls).
If one end of a connection is a symmetric NAT with multiple IP addresses, connections to peers behind other
symmetric NATs or behind address-restricted (and probably port-restricted) cone NATs (or address-restricted or
port-restricted firewalls) are impossible. No matter what Flash Player tries to do to “punch a hole” through the
restricted cone NAT or restricted firewall to let the other peer through, the other end moves to a new address and/or
port number that doesn't match. The hole that was created is no longer applicable.
Configure ports for HTTP streaming
By default, Flash Media Server is configured to listen on port 80. Flash Media Server proxies HTTP traffic to Apache
HTTP Server over port 8134. However, HTTP Dynamic Streaming and HTTP Live Streaming connections can hang
when proxying through the server.
Do not proxy HDS and HLS traffic through Flash Media Server to Apache HTTP Server. Either specify the port
number in the request URL, or configure Apache to use port 80 and configure Flash Media Server not to use port 80.
You do not need to use both techniques.
Specify the port number in request URLs
❖ Connect clients to Apache HTTP Server directly through its own port (the default is port 8134). For example, use
the following request URL:
http://fms.example.com:8134/hds-vod/somefile.f4v.f4m
Can receive from same IP address,
different UDP port number
Indicates whether your firewall is “port restricted”. A port restricted
firewall requires an outbound connection to the same address and
port number before inbound traffic is permitted from that address
and port number. This requirement is true even when previous
traffic was sent to the same address but different port number.
Can receive from different IP address,
different UDP port number
Indicates whether your firewall is “address restricted”. An address
restricted firewall requires that an outbound connection is made to
a new IP address before inbound traffic is permitted from that IP
address.
Can send to different IP address after
server introduction
This value is always be “Yes” if the initial connection can be made.
This test is like opening a new RTMFP connection. If this test fails,
there's a problem with how Flash Player received or treated the
introduction request, or the firewall is unpredictable.
Source IP address is preserved from
original connection
This test means that you have one of the following: a cone NAT, a
symmetric NAT with only one IP address, or a symmetric NAT with
multiple IP addresses but the same address happened to be used
this time. If repeated tests cause the value to change, you have a
symmetric NAT with multiple IP addresses, and sometimes you
happen to use the same address.
Source UDP port number is preserved
from original connection
This test means that you have a cone NAT. If the value is "No", you
have a symmetric NAT.
Test Description