Port number
Last updated on
Apr 27, 2021
When you install Adobe Media Server, you can accept the default ports on which Adobe Media Server and Adobe Media Administration Server listen. You can also enter new ports. The default ports for Adobe Media Server are 1935 and 80. The default port for Adobe Media Administration Server is 1111.
Adobe Media Server installation instructions are available in the help articles linked at https://helpx.adobe.com/adobe-media-server/install/topics.html.
[adobebyline]To test which ports a client can connect to on a Adobe
Media Server hosted by Stefan Richter of FlashComGuru, see FlashComGuru Port Tester.[/adobebyline]
[adobebyline]To test which ports a client can connect to on your own Adobe Media Server, use a port tester developed and hosted by Jake Hilton. [/adobebyline]
Port requirements
The following table describes ports on which clients must be able to establish connections to the server:
|
|
Protocol |
Transport |
Description |
|
1935 |
RTMP/E |
TCP |
By default, Flash Player and AIR clients make RTMP connections to Adobe Media Server over port 1935 over TCP. To communicate with Adobe 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 Adobe Media Server over port 1935 over UDP. |
|
80 |
RTMP/E, RTMTP, HTTP |
TCP |
By default, Flash Player and AIR clients that cannot connect to Adobe 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 Adobe 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 Adobe 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. Adobe 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 |
Adobe 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 Adobe Media Server not to listen on port 80. |
|
1111 |
HTTP, RTMP |
TCP |
By default, Flash Player, AIR, and HTML clients connect to Adobe Media Administration Server over port 1111. Clients must specify port 1111 in connection URLs. Clients cannot access Adobe 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 ams.ini file to configure the IP addresses and ports on which Adobe Media Server listens for requests.
-
Open rootinstall/conf/ams.ini in a text editor.
Note:By default, Adobe Media Server installs to C:\Program Files\Adobe\Adobe Media Server 5. The documentation refers to this directory as rootinstall.
-
Edit the ADAPTOR.HOSTPORT parameter. The default ports are:
ADAPTOR.HOSTPORT = :1935,80
-
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>
Configure IP addresses and ports for RTMFP
RTMFP connection flow
-
An RTMFP client connects to a Adobe Media Server amsedge process over UDP port 1935.
Specify this port in the ADAPTOR.HOSTPORT parameter of the ams.ini file. To change this value, see Configure IP addresses and ports for RTMFP.
Note:RTMFP and RTMP/E clients use the same port to connect to Adobe Media Server. However, RTMFP clients use UDP and RTMP/E clients use TCP.
-
The amsedge process redirects the connection to an amscore process listening on a UDP port in the range 19350-65535.
Each amscore process has its own RTMFP listener. Each RTMFP listener binds to one UDP port in the range. When an amscore 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 amscore 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 amscore processes in use. The number of amscore 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 amscore process.
Configure RTMFP redirect ports
-
Open rootinstall/conf/_defaultRoot_/Adaptor.xml in a text editor.
-
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> -
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 amscore process, the amsedge 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.
-
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 amsedge 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 Adobe 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, Apache HTTP Server listens on port 80. RTMPT traffic is proxied to AMS on port 1935.
HTTP Dynamic Streaming and HTTP Live Streaming connections can hang when proxying through the server. Do not proxy HDS and HLS traffic through Adobe Media Server to Apache HTTP Server. You can also explicitly specify the port number in the request URL.
Adobe MAX
The Creativity Conference
Oct 14–16 Miami Beach and online
Adobe MAX
The Creativity Conference
Oct 14–16 Miami Beach and online