Configure ports

When you install Flash Media Server, you can accept the default ports on which Flash Media Server and Flash Media Administration Server listen. You can also enter new ports. The default ports for Flash Media Server are 1935 and 80. The default port for Flash Media Administration Server is 1111.

Port requirements

The following table describes ports on which clients must be able to establish connections to the server:

Port number

Protocol

Transport

Description

1935

RTMP/E

TCP

By default, Flash Player and AIR clients make RTMP connections to Flash Media Server over port 1935 over TCP.

To communicate with Flash Media Server over the RTMP protocol, clients attempt to connect to ports in the following order: 1935, 80 (RTMP), 80 (RTMPT).

1935

RTMFP

UDP

By default, Flash Player and AIR clients make RTMFP connections to Flash Media Server over port 1935 over UDP.

80

RTMP/E, RTMTP, HTTP

TCP

By default, Flash Player and AIR clients that cannot connect to Flash Media Server over port 1935 attempt to tunnel over port 80 (RTMPT).

If Apache is installed and enabled, HTTP requests made over port 80 are proxied to Apache over port 8134.

HTTP Streaming requests to port 80 can hang when proxying to port 8134. Use port 8134 in the request or configure Apache to listen directly on port 80 and configure Flash Media Server not to listen on port 80.

19350-65535

RTMFP

UDP

By default, clients use port 1935 and ports 19350-65535 to communicate with Flash Media Server over the RTMFP protocol. The RTMFP protocol communicates over UDP. Clients connect to the server over 1935 and the server redirects the client to a port between 19350 and 65535.

Allow inbound UDP traffic on 1935 and outbound traffic on ports 19350 - 65535.

Allowing UDP inbound traffic from unknown hosts on ports 19350 - 65535 is optional. Flash Media Server sends a packet out to a new client to redirect it to a port in the range 19350 - 65535. This packet attempts to punch a hole to allow the client traffic back in over the correct port.To use server-side RTMFP NetConnections, allow outbound UDP traffic on all ports.

8134

HTTP

TCP

Flash Media Server proxies HTTP requests to Apache HTTP Server over port 8134.

HTTP Streaming requests to port 80 can hang when proxying to port 8134. Use port 8134 in the request or configure Apache to listen directly on port 80 and configure Flash Media Server not to listen on port 80.

1111

HTTP, RTMP

TCP

By default, Flash Player, AIR, and HTML clients connect to Flash Media Administration Server over port 1111. Clients must specify port 1111 in connection URLs.

Clients cannot access Flash Media Administration Server over RTMPS. As a result, Adobe recommends that you block all external access to port 1111 so that access to the Administration Server is restricted to clients that are inside your firewall.

443

RTMPS

TCP

The default port for RTMPS. RTMPS adheres to SSL standards for secure network connections and enables connections through a TCP socket on a secure port.

Configure IP addresses and ports

Use the fms.ini file to configure the IP addresses and ports on which Flash Media Server listens for requests.

  1. Open rootinstall/conf/fms.ini in a text editor.

  2. Edit the ADAPTOR.HOSTPORT parameter. The default ports are:

    ADAPTOR.HOSTPORT = :1935,80
  3. Save the file and restart the server.

The Adaptor.xml configuration file uses the ADAPTOR.HOSTPORT parameter in the Adaptor/HostPortList/HostPort element:

<HostPort name="edge1" ctl_channel="localhost:19350" rtmfp="${ADAPTOR.HOSTPORT}">${ADAPTOR.HOSTPORT}</HostPort>

See also

Start and stop the server

Add an adaptor

Configure IP addresses and ports for RTMFP

RTMFP connection flow

  1. An RTMFP client connects to a Flash Media Server fmsedge process over UDP port 1935.

    Specify this port in the ADAPTOR.HOSTPORT parameter of the fms.ini file. To change this value, see Configure IP addresses and ports for RTMFP.

    Important: RTMFP and RTMP/E clients use the same port to connect to Flash Media Server. However, RTMFP clients use UDP and RTMP/E clients use TCP.
  2. The fmsedge process redirects the connection to an fmscore process listening on a UDP port in the range 19350-65535.

    Each fmscore process has its own RTMFP listener. Each RTMFP listener binds to one UDP port in the range. When an fmscore process starts, the listener binds to the next available UDP port in the range specified in the Adaptor/RTMFP/Core/HostPortList/HostPort element of the Adaptor.xml configuration file. For example, if there are three fmscore processes, they listen on ports 19350, 19351, and 19352. These ports are called the RTMFP redirect ports or the RTMFP migration ports.

    The number of ports in use depends on the number of fmscore processes in use. The number of fmscore processes in use depends on how application instances are distributed. See Configure how applications are assigned to server processes.

    When the server redirects the client, it sends the client an IP address and port number. If the server is behind a NAT, specify the public IP address of the server in the public attribute of the HostPort element. The server passes this address to the client and the client uses it to connect to the fmscore process.

Configure RTMFP redirect ports

  1. Open rootinstall/conf/_defaultRoot_/Adaptor.xml in a text editor.

  2. Edit the value of the HostPort element. The default ports are as follows:

    <Adaptor> 
        ... 
        <RTMFP> 
            ... 
            <Core> 
                <HostPortList> 
                    <HostPort>:19350-65535</HostPort> 
                </HostPortList> 
            </Core> 
        </RTMFP> 
    </Adaptor>
  3. If the RTMFP adaptor is behind a NAT, specify the in-front-of-NAT IP address that clients connect to in the public attribute of the HostPort element. The following example uses 12.34.56.78 for the in-front-of-NAT IP address:

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

    To redirect the client to an fmscore process, the fmsedge process sends the client an IP address and a port number. The server knows the behind the NAT IP address, but the client can’t connect to that. The client needs to know the in-front-of NAT IP address. To tell the server its in-front-of NAT IP address, specify it in the public attribute.

  4. Save the file and restart the server. See Start and stop the server

About the HostPort element

The value of the HostPort element has the following format:

<value-of-HostPort> := [<host-port-range> [; <host-port-range> [; ... ] ] ] 
<host-port-range> := [<host>][:<port-range>[, <port-range> ] ] 
<port-range> := <start-port>[ - <end-port> ] 

In this example of HostPortList, each core listens to two ports: one port from either host1:2000-2010 or host2:3000-3010 and one port from either host2:5000 or host2:3010-4000 :

<HostPortList> 
    <HostPort public="12.34.56.78:2000-2010">host1:2000-2010; host2:3000-3010</HostPort> 
    <HostPort>host2:5000; host2:3010-4000</HostPort> 
</HostPortList>

Configure a public IP address if the server is behind a NAT

If an RTMFP adaptor is behind a NAT, specify the in-front-of-NAT IP address that clients connect to in the public attribute of the HostPort element:

<HostPort public="<in-front-of-NAT-server-IP>:19350-65535">:19350-65535</HostPort>

If you don't specify the public attribute, the server doesn’t know its in-front-of-NAT-address. The fmsedge process can redirect the client to the correct port (for example, 19351) but it tells the client the behind-NAT address, which the client can't contact.

Each HostPort element can specify a public address that corresponds to the specified port. This is the address that is advertised to clients for the given HostPort. To advertise an address, specify a value for the public attribute of the HostPort element. The public attribute has the same format as the HostPort element. The number of ports specified by the public attribute must equal the number of ports specified by the HostPort element. If the core listens on the n-th port of the HostPort value, the n-th port of the public attribute is advertised as its value.

In this example of HostPortList with a public attribute, if a core listens on host1:1005, its publicly advertised address is host2:4005.

<HostPortList> 
    <HostPort public="host2:4000-5000">host1:1000-2000</HostPort> 
</HostPortList>

NAT and firewall traversal

NAT (network address translation) and firewall filtering can block peer-to-peer connections. In an intranet application, in which you have control over the entire network, do the following to ensure that clients can create peer-to-peer connections:

  • Allow UDP traffic through any firewalls

  • Use a NAT or firewall that complies with the NAT implementation recommendations of the IETF BEHAVE working group.

  • Use the TURN proxy support in Flash Player to send traffic to a proxy in a DMZ that can comply with the previous recommendations. See Best practices for real-time collaboration using Flash Media Server.

In an Internet application, the application developer must choose how to handle cases in which a firewall or NAT blocks a direct peer-to-peer connection. To create an application that works for connections that aren’t peer-to-peer, create a protocol fallback to client-server RTMP and/or RTMPT. To create an application that never relays media through the server (even though some clients may not see the media), don’t create a protocol fallback.

Understanding types of NAT

It’s important to understand the different types of NAT behavior:

Cone
Reuses the same address and port when talking to all peers.

Multiple IP address, symmetric
Picks a new address and port when talking to a new peer.

Single IP address, symmetric
Uses the same address but a new port when talking to a new peer.

It’s also important to understand the filtering behaviors of NATs and firewalls:

None
A cone NAT with no filtering is called “full cone”.

Address-restricted
The peer is restricted to talking only to addresses it has talked to already.

Address and port-restricted
The peer is restricted to talking only to addresses and ports it has talked to already.

In addition, some NAT and firewall behaviors aren't easily defined. For example, a NAT could act as a symmetric NAT that preserves port numbers. When it runs out of resources, it could switch and act as a cone NAT.

In another example, a NAT could act as one type of NAT for the first client that connected to a server. It could act as a different type of NAT for the second client that tried to connect to the same server. In this case, a simple analysis can fail to predict whether a client can make a peer-to-peer connection.

Note: A firewall can filter and not be a NAT. A NAT can act as a firewall and have filtering. A firewall may block UDP completely.

RTMFP Connectivity checker

RTMFP inventor Matthew Kaufman hosts a website called RTMFP Connectivity Checker at http://cc.rtmfp.net/. Use this site to try to determine whether a client on a particular network can create a peer-to-peer connection.

If the connection to cc.rtmfp.net has the same properties as the connection to and from the peer, use the results to determine whether a peer-to-peer connection can be formed. The results are not always definitive because, in some cases, the connection does not have the same properties. For example, two peers in the same organization behind the same firewall can have different properties between each other than they each have to http://cc.rtmfp.net.

To test a connection, the client connection must have the same properties as the client you’re testing, and the NAT or firewall must have predictable behavior. The following are the RTMFP Connectivity Checker tests:

Test

Description

Knows public IP address of self

Flash Player has a local address that matches the address that cc.rtmfp.net saw when the connection came in. In this case, there is no address translation.

Public UDP port number same as local UDP port number

Flash Player's idea of which UDP port number it is using matches what http://cc.rtmfp.net saw when the connection came in. In this case, there is no port translation. If this answer and the previous answer are “Yes”, there probably isn’t a NAT (but there may be a firewall).

Can receive from same IP address, same UDP port number

This value is always “Yes”, because if a client couldn't complete this test, it couldn't establish the initial connection.

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.

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

Configure Apache to use port 80 and configure Flash Media Server not to use port 80

  1. Configure Apache to use port 80.

    1. Open rootinstall/Apache2.2/conf in a text editor.

    2. Change the line Listen 8134 to Listen 80.

    3. Restart Apache. See Start and stop the server.

  2. Configure Flash Media Server not to use port 80.

    1. Open rootinstall/conf/fms.ini in a text editor.

    2. Remove 80 from the ADAPTOR.HOSTPORT parameter so the parameter looks like the following:

      ADAPTOR.HOSTPORT = :1935
    3. Restart Flash Media Server. See Start and stop the server.