Firewalls may present communications problems to Helix Universal Server. This chapter helps you to find solutions to these problems. It first provides background on firewalls and network protocols. It then recommends ways to work with firewalls to give viewers the best possible streaming media experience. Finally, it lists the communications ports that RealNetworks components use.
A firewall is a software program or device that monitors, and sometimes controls, all transmissions between an organization's internal network and the Internet. However large the network, a firewall is typically deployed on the network's edge to prevent inappropriate access to data behind the firewall. The firewall ensures that all communication in both directions conforms to an organization's security policy.
Firewall technologies are configurable. You can limit communication by direction, IP address, protocol, ports, or numerous other combinations. Firewalls positioned between your Helix Universal Server and other computers may cause communication failures if the firewall does not allow for the types of communication Helix Universal Server requires. These other computers may be media clients or servers set up as encoders or receivers.
If you have access to the firewall, you can configure it to enable the ports, protocols, and addresses that optimize Helix Universal Server communication. In some cases, however, your organization's security policy may prevent optimal streaming. For example, if a client is behind a firewall that permits only one-way, outbound access to the Internet, that client would not efficiently receive clips streamed by Helix Universal Server over the Internet. This is because the client needs to establish a two-way connection to achieve optimal streaming results.
A protocol is a language that computers use when communicating over a network. The Transmission Control Protocol/Internet Protocolcommonly called TCP/IPencompasses a suite of protocols upon which the Internet is built. TCP/IP protocols work on a layering principal, in which each layer is assigned a specific network task.
For communication to occur, a source computer sends a message from its highest network layer to its lowest. The lowest network layer at the source forwards the message over the network. When the message arrives at the destination computer, it must pass through the exact same layers, but in reverse order.
Each network layer uses specific protocols to perform its task. Packets passed down from upper layers are tucked inside lower layer packets. This is called encapsulation. By encapsulating packets, a layer can handle its responsibilities without understanding the preceding layer. Through this layering scheme, a destination layer on one computer receives exactly the same object sent by the corresponding source layer on another computer.
For example, an application such as a Web browser packages data, such as a Web page request made over HTTP, at the application layer, passing it to the lower transport layer. There, the HTTP request packets are bundled into TCP packets that are then delivered to destination Web server. When the Web server receives the source TCP packets, it strips off the TCP shells, and bumps the HTTP message up to the destination computer's application layer. This layer, in turn, delivers to the HTTP-based request to the Web server.
|Note: Network layering is a complex topic. This section omits discussion of additional layers required to deliver packets over a network, focusing instead on the transport and application layers, and the protocols relevant to streaming media for each.|
All transport-layer protocols transfer data between hosts. The transport-layer protocol in use can greatly affect the quality of the stream received. There are two main transport protocols used on IP networks: TCP and UDP. Helix Universal Server utilizes both of these protocols, and the choice of protocol is generally negotiated automatically by the servers and clients involved.
Helix Universal Server can use TCP in a number of ways. Because TCP offers a single channel for bi-directional communication, Helix Universal Server uses it as a control channel to communicate with clients about passwords and user commands such as pause and fast-forward. The TCP protocol also guarantees delivery of packets, and has built-in congestion control that helps to provide reliable communication.
On the down side, TCP responds slowly to changing network conditions, and creates network overhead through its error checking facility. For this reason, TCP is best suited for delivering low-bandwidth material like passwords or user commands. In some cases, TCP can facilitate communication through a firewall. For example, firewalls that block UDP traffic between Helix Universal Server and its clients may permit TCP connections.
Helix Universal Server uses UDP packets to deliver data to client software on its data channel. Client software sends UDP-based requests to Helix Universal Server when packets on the data channel have not arrived. Because the transport does not consume as much network overhead, it can deliver packets faster than TCP.
Because video and audio data typically consume large amounts of bandwidth, it makes the most sense to use UDP to deliver streaming media. For this reason, Helix Universal Server uses UDP as the default for transmitter-to- receiver communication. With Helix Producer, you can set up the encoder to act as a transmitter. You therefore can, and should, use a UDP connection to deliver live feeds from the encoder.
Helix Universal Server uses four application-layer protocols to deliver streaming media to clients: RTSP, PNA, MMS, and HTTP. The following table summarizes their use.
|RealOne Player, RealPlayer, QuickTime Player||RTSP||TCP and UDP, or TCP only|
|Windows Media Player||MMS||TCP and UDP, or TCP only|
|RealPlayer 5 and earlier||PNA||TCP and UDP, or TCP only|
|Windows Media Player, for streaming media and protocol roll-over||HTTP||TCP only|
|RealOne Player and RealPlayer, for HTTP cloaking||HTTP||TCP only|
A standards-based protocol designed for serving multimedia presentations, RTSP is very useful for large-scale broadcasting. Only RTSP can deliver SureStream files with multiple bit-rate encoding. SMIL, RealText, and RealPix also require RTSP. RTSP uses TCP for player control messages, and UDP for video and audio data. RTSP can also use TCP to deliver data, but this is not recommended. Use RTSP with RTSP-compatible players such as RealOne Player, RealPlayer, and QuickTime Player.
PNA is a proprietary protocol used in earlier RealNetworks client software versions. PNA is supported in the current Helix Universal Server for compatibility with older RealNetworks clients (RealPlayer 5 and earlier). PNA uses TCP for player control messages, and UDP for audio data. PNA can also use TCP to deliver data, but this is not recommended.
The PNA protocol uses |
The MMS protocol is designed specifically for serving multimedia presentations. Although it is not standards-based, you can use it to broadcast live or on-demand Windows Media clips to Windows Media Player. MMS uses TCP for player control messages, and UDP for video and audio data. MMS can also use TCP to deliver data, but this is not recommended.
HTTP is typically used for Web pages. With Helix Universal Server, HTTP is used to display Helix Administrator pages and HTML-based documentation. It is also used for requesting metafiles that point client software to streaming media content. HTTP may also be used in HTTP cloaking, which is a method of delivering streaming media to clients behind firewalls that restrict streaming media protocols.
|Note: Helix Universal Server also uses HTTP to transport live Windows Media streams from Windows Media Encoder to Helix Universal Server.|
All Internet data is delivered in IP packets. But just as TCP or UDP can wrap a control protocol for streaming media, IP packets can wrap data packets in formats designed to deliver streaming media data. Helix Universal Server can use both of the following packet formats.
When Helix Universal Server communicates to a RealNetworks client such as RealOne Player over RTSP, it uses RDT as the packet format. A proprietary format, RDT allows the use of RealMedia features such as SureStream.
RTP is a standards-based packet format designed as the companion to the RTSP protocol. QuickTime Player, for example, uses RTP as its packet format. Helix Universal Server fully supports RTP, and shifts to RTP automatically when streaming to an RTP-based client such as QuickTime Player. RealNetworks clients such as RealOne Player also support RTP, using this format when receiving data from RTSP/RTP servers.
The following table describes how firewalls affect Helix Universal Server features.
|Feature||Effect of a Firewall|
|On-Demand Streaming||Issues that clients may have in connecting to on-demand streams are described in "Streaming to Client Software Behind Firewalls".|
|Live Unicasting||Clients connect to live broadcasts in the same way they connect to on-demand streams. However, the encoder that supplies Helix Universal Server with its live data may not be able to connect to Helix Universal Server if a firewall exists between the encoder and Helix Universal Server. See "Working With An Encoder, Receiver, or Proxy".|
|Splitting||Working with receivers that are located on the other side of a firewall requires special consideration. Chapter 9 covers this issue.|
|Multicasting||Multicasts usually take place within an intranet, where broadcasts are not travelling outside a firewall. If a multicast is occurring through a firewall, the firewall must be specially configured to allow multicast traffic.|
|Helix Universal Proxy||Helix Universal Proxy connects to your Helix Universal Server just as any other client would.|
|Access Control, and Reporting||When a firewall exists between a client and Helix Universal Server, the IP address that appears in the access log's
|Authentication||Requests by Helix Universal Server for authentication information (either from the user or the client software) is delivered over the control channel. If a firewall prevents the control channel connection, Helix Universal Server cannot authenticate the request and therefore will not deliver it.|
|ISP Hosting||If there is a firewall between users and the location where they are to store their content for hosting, they may not be able to send their clips to Helix Universal Server.|
One of the first decisions to make about deploying Helix Universal Server is where it should live on your network. If you are streaming content only to clients inside your organization, typically it is best to locate your Helix Universal Server inside the firewall. This requires no special configuration for Helix Universal Server or the firewall. Clients on the Internet side of the firewall, however, most likely will not be able to access your Helix Universal Server.
If you need to stream content to clients on the Internet, it's better not to locate Helix Universal Server behind a firewall. For optimal streaming, Helix Universal Server needs to use streaming protocols, and to process incoming and outgoing UDP connections on a variety of ports. Although you may be able to change your organization's security policy to enable optimal communication, this may hamper the effectiveness of the firewall.
The best solution may be to create a perimeter network, sometimes known as a De-Militarized Zone (DMZ), and move Helix Universal Server there. In this scenario, you fortify the connection between main and perimeter networks, but allow a less stringent security policy in the perimeter. This keeps the main network secure, while maintaining optimal connections from the Internet to your Helix Universal Server.
In some organizations, the only choice is to place Helix Universal Server behind the firewall, and then stream media through the firewall. If this is your situation, you must configure your firewall to enable optimal communication with Helix Universal Server and other computers. If not, communication may be substandard or even impossible.
The following sections describe the requirements for optimal communication in various situations. They will help you to decide what types of traffic to allow through your firewall. The section "Default Ports" lists the specific ports that Helix Universal Server uses to communicate with other computers. Keep in mind that the values listed there are defaults, many of which can be changed to suit your needs.
Helix Universal Server enables you to limit the number of ports used for incoming UDP packets from clients such as RealOne Player. The client sends these packets to acknowledge data reception, and to request a resend of lost packets. Although a firewall can accept all incoming UDP communication, network administrators often hesitate to leave open a large number of UDP ports. Service quality degrades, though, if Helix Universal Server cannot receive these packets. To solve this problem, Helix Universal Server can redirect replies from all clients to a few UDP ports, thus limiting the number of open UDP ports.
|For More Information: For instructions on how to set up this feature, see "Changing Port Assignments".|
Firewalls are not the only type of technology that can affect where you place Helix Universal Server. You might also need to place a cluster of Helix Universal Servers behind a virtual IP address. Although this network topology is possible, its implementation may have unintended consequences for RTSP traffic behind a restrictive firewall.
A typical IP address resolves to a single server. A virtual IP address, on the other hand, resolves to a cluster of servers, typically through a hardware switch. Consider the case of a cluster of servers set behind a hardware switch, with all servers sharing the same content, but configured with unique, private IP addresses. In this scenario, only the hardware switch is assigned a public IP address. It receives all public communication, passing each request to a host in the cluster, based on load.
A problem arises from the combination of public and private IP addresses. If a firewall blocks streaming media protocols, the client communicates through HTTP cloaking. In most cases, this effectively bypasses firewall security, which typically allows HTTP traffic to pass. The section "HTTP Cloaking" discusses this strategy in detail. For now, it is important only to grasp that for cloaking to work, the client must be able to make two HTTP connections to the same Helix Universal Server.
When a client uses HTTP cloaking, Helix Universal Server replies to the initial HTTP connection with its actual IP address, and not the virtual IP of the cluster. This allows the client to circumvent the hardware switch, and establish its second HTTP connection directly with the Helix Universal Server handling the request. But if that server uses a private IP address, the client cannot make the second, necessary connection, and HTTP cloaking fails.
There are two ways to resolve the virtual addressing problem:
If neither of these solutions is possible, some RTSP clients outside of highly restrictive firewalls may not be able to access your content.
Once you have placed Helix Universal Server in relation to your firewall, you need to consider the placement of other servers. These servers might be other Helix Universal Servers set up as receivers or relays, or they may be computers running encoding or media proxy software. Generally, the same rules and limitations discussed in the preceding sections apply to placing these types of servers as well. If possible, place other encoders or receivers in the perimeter network along with Helix Universal Server. If that's not possible, solutions depend largely on the type of server you're considering.
This section assumes that you've placed Helix Universal Server behind your firewall, and have taken steps to ensure optimal communication with encoders outside your firewall. Even if your firewall is optimally configured, another organization's firewall may cause problems.
Suppose that another organization broadcasts a live feed to your Helix Universal Server from behind their own restrictive firewall. The best solution is to contact that organization and have them move their encoder from behind the firewall. Alternatively, you could agree with that organization to open the required network paths. If neither of the preceding solutions is feasible, you can attempt an encoder connection using TCP.
When Windows Media Encoder sends a live Windows Media broadcast, the only protocol option is HTTP, which uses TCP. In these cases, Helix Universal Server pulls the live feed from the encoder. Contact the administrator of the Windows Media Encoder for the HTTP port number to pull from. Helix Universal Server receives the live feed on its default HTTP port.
By default, receivers and Helix Universal Servers use UDP to communicate. An option is available for them to use TCP instead. If the receiver is behind a firewall, you should move the receiver to the perimeter network. If this is not possible, change the transport protocol used for transmitter-to-receiver communication to TCP as described in Chapter 9, "Transmitters and Receivers".
Helix Universal Proxy servers commonly work behind a firewall. In this respect, a Helix Universal Server-to-Helix Universal Proxy connection behaves like a Helix Universal Server-to-client connection, except for HTTP communication. Helix Universal Proxy first tries to connect with RTSP using UDP for data transport. If the firewall prohibits UDP connections, Helix Universal Proxy tries RTSP, using TCP for data transport. Helix Universal Proxy has no option for HTTP delivery. Thus, if the firewall prohibits RTSP, Helix Universal Proxy will not be able to proxy streams on behalf of clients.
This section describes how client technologies communicate to Helix Universal Server when the streaming media viewer resides behind a firewall. It provides suggestions for setting up Helix Universal Server to accommodate client connection features.
Helix Universal Server uses two connections, known as channels, to communicate with clients:
Helix Universal Server uses this channel for communication with the client. Over this channel, Helix Universal Server requests and receives passwords, and clients send instructions such as fast-forward, pause, and stop.
At the transport layer, most media players, including RealOne Player, can work around situations in which the first communication fails because the player resides behind a firewall that blocks the preferred protocol. The primary strategy involves shifting automatically to protocols and delivery methods that aren't blocked. Typically, the client shifts the control channel to the less efficient TCP, which is less likely to be blocked than UDP.
If the control connection is established, the client then negotiates the data channel. Optimally, the data channel will use the more efficient UDP transport. If the stream is live, some client software, including RealOne Player, attempts to set up a UDP multicast first. If this method fails, the client next attempts UDP unicast. And if that fails, the client uses the established control channel for data. In short, the client tries to set up the most optimal data delivery method, relying on the control connection as a last resort.
|For More Information: Unicasting and multicasting are described in Chapter 7 and Chapter 8, respectively.|
Some firewalls restrict streaming media protocols like RTSP or MMS, and the client cannot establish the control connection. In these cases, the client and server disguise streaming media traffic as HTTP, a solution known as HTTP cloaking. Because most firewalls allow HTTP traffic, this solution circumvents the communication problem. However, HTTP is not designed for streaming media, and the user does not get the highest quality stream.
The HTTP cloaking method must also work around limitations in the HTTP
protocol. For example, RTSP clients use two HTTP streams to connect to a
single Helix Universal Server. Because the client initiates both streams, the
client firewall typically allows these connections as outgoing HTTP traffic.
The first connection uses the HTTP
GET method, the standard means for a
browser to request a Web page. At the receiving end, Helix Universal Server
strips off the HTTP disguise, using the encapsulated RTSP information to
determine what information to send the client.
Helix Universal Server must then wait for the second HTTP connection from
the same client to proceed with streaming the media. This second connection
uses the HTTP
POST method, the standard means for a Web server to send data
to a browser. Once both of these client-initiated streams are established, the
client and Helix Universal Server can pass RTSP packets in two directions,
through a firewall that blocks RTSP.
For HTTP cloaking to work, the client must connect to Helix Universal Server's HTTP port. It has no problem if Helix Universal Server uses the well- known port 80 for HTTP. But problems can arise if Helix Universal Server uses a different HTTP port. Even if the client knows which port to use, the client will not be able to connect if its firewall restricts outgoing HTTP traffic to port 80.
For this reason, RealNetworks recommends setting the HTTP port on Helix Universal Server to port 80. This configuration offers the widest possible support of all types of player software. If this is not possible, RealOne Player and RealPlayer 8 can often discover the Helix Universal Server HTTP port, and will be able to connect to the HTTP port as long as a firewall does not block their outbound communication. Not all players can do this, however.
|For More Information: When you install Helix Universal Server and a Web server on the same machine, you need to take certain precautions before assigning port 80 to Helix Universal Server. For more information, see "Web Servers and Helix Universal Server".|
Port hinting offers a solution for Helix Universal Servers that cannot use default port values. It allows Helix Universal Server to send the port numbers in use to RealOne Player and RealPlayer 8 when you launch clips using the Ramgen utility. This feature is turned on by default. Content creators can also define ports to try on the Helix Universal Server machine when defining Ram files.
|For More Information: See "Handling Communication through Nonstandard Ports" for more information about these features.|
The following section will help you to decide which ports to open on your firewall. If you do not want to open all the ports listed, refer to the detailed information at http://service.real.com/firewall.
The following tables list the default ports that Helix Universal Server uses to communicate with media clients and other server.
|listen on||554||TCP||control channel for RTSP requests (data channel also, if TCP was requested)|
|listen on||7070||TCP||control channel for PNA requests (data channel also, if TCP was requested)|
|listen on||HTTP Port||TCP||HTTP requests, and RTSP, MMS and PNA cloaked through HTTP|
|listen on||1755||TCP, UDP||TCP control channel for MMS requests (data channel also, if TCP was requested); UDP resend requests by MMS|
|listen on||34445-34459||UDP||RDT/RTP client replies for UDP resends, etc.|
|send to||1024-5000||UDP||MMS media packet delivery|
|send to||1-65000||Multicast||MMS multicast media packet delivery|
|send to||6970-32000||UDP||data channel|
|listen on||Admin Port||TCP||connections to Helix Administrator|
|listen on||9090||TCP||Server Monitor traffic|
|listen on||554||TCP||media distribution requests|
|listen on||Admin Port||TCP||license subscriber initiation request|
|listen on||4321||TCP||license distribution accounting channel|
|listen on||2030||TCP or UDP||data channel for pull splitting requests|
|send to||30001 -30020||TCP or UDP||live data distribution|
|listen on||4040||TCP||control channel for RealProducer version 6 and 6.1 connections|
|listen on||6970-32000||UDP||data channel for RealProducer 6 and 6.1|
|listen on||4040||TCP||data channel for RealProducer 6.1 connections, if TCP was selected|
|listen on||5050||TCP||control channel for pre-G2 encoder connections|
|listen on||50001-50050||TCP or UDP||media packet reception from Helix Producer 9 in account-based transmitter mode|
|listen on||HTTP Port||TCP||negotiate transmitter settings for Helix Producer 9 in account-based transmitter mode|
|listen on||HTTP port||TCP||HTTP connection to Windows Media Encoder (Helix Universal Server pulls the stream)|
|listen on||554||TCP||control channel for RTSP requests to Helix Universal Server|
|listen on||554||TCP or UDP||Helix Universal Proxy live requests|
|listen on||554||TCP||Helix Universal Proxy cache requests|
In addition to the values shown in the follow table, a receiver will use all the values described in "Helix Universal Server Default Ports" if it is also serving its own content (separate from splitting).
|listen on||554||TCP||RTSP requests from RealOne Player|
|send to||2030||TCP or UDP||pull splitting requests|
|listen on||30001 -30020||TCP or UDP||push splitting requests|
The following tables list the default ports used by Helix Universal Proxy.
|listen on||7070||TCP||PNA proxy requests|
|listen on||554||TCP||RTSP proxy requests|
|send to||6970-32000||UDP||data channel|
|send to||554||TCP||control channel for RTSP requests|
|send to||3030||TCP or UDP||data and control channel for pull splitting requests|
|send to||7070||TCP||control channel for PNA requests|
|send to||7802||TCP||cache requests to Helix Universal Server|
|send to||7878||TCP||cache requests to Helix Universal Server|
|send to||9090||TCP||Server Monitor traffic|
|listen on||Admin Port||TCP||Helix Administrator|
With Helix Producer 9, you can set up the encoder to function in different ways. The two Helix Producer methods of communicating documented in the following tables are legacy mode and account-based transmitter mode. When Helix Producer uses newer encoding methods, it imitates a transmitter. If you have set up Helix Producer to function this way, use the ports and protocols listed in "Helix Universal Server Default Ports".
|listen on||80||HTTP||Helix Producer initiation requests in account-based mode|
|send to||50001-50050||TCP or UDP||media packet reception from Helix Producer in account-based mode|
In RealProducer G2 (version 6) and later, you can instruct RealProducer to use TCP for the data connection. UDP is the preferred method, as it results in a better user experience, but TCP may be necessary if there is a firewall between the encoder and the Helix Universal Server. If you do opt to use TCP, port 4040 will be used for both the control channel and the data channel.
|send to||4040||TCP||control channel|
|send to||6970-32000||UDP||data channel if UDP is selected for the Helix Universal Server connection (the actual port number is not configurable)|
|send to||4040||TCP||data channel if TCP is selected for the Helix Universal Server connection|
|Note: RealProducer 5 and earlier use a TCP data and control channel sent on port 5050.|
The following table lists the communications ports used by RealOne Player, RealPlayer 6-8, Windows Media Player, and QuickTime Player. In addition to the settings listed below, RealOne Player inherits proxy settings (if they exist) from the default browser, although users can turn off this feature from the RealOne Player Preferences menu.
When Helix Universal Server receives a control channel request, it directs the data to the port number specified by the client. RealOne Player and RealPlayer choose UDP for the data channel, and indicate a data channel port number between 6970 and 32000. Windows Media Player also chooses UDP, and indicates a data channel port number between 1024-5000. If the client chooses TCP for the data channel, Helix Universal Server uses the same port number for both the control channel and the data channel.
|send to||554||TCP||control channel for RTSP requests (data channel also, if TCP was requested)|
|send to||7070||TCP||control channel for PNA requests (data channel also, if TCP was requested)|
|send to||HTTP Port||TCP||HTTP requests, and RTSP, MMS and PNA cloaked with HTTP|
|send to||1755||TCP, UDP||TCP control channel for MMS requests (data channel also, if TCP was requested); UDP resend requests by MMS|
|send to||34445-34459||UDP||RDT/RTP UDP resend requests|
|listen on||1024-5000||UDP||MMS media packet delivery|
|listen on||1-65000||Multicast||MMS multicast media packet delivery|
|listen on||6970-32000||UDP||data channel|
Versions of RealPlayer earlier than RealPlayer G2, use the following ports.
|send to||7070||TCP||control channel for PNA requests; data channel, if TCP was requested|
|send to||80||TCP||control channel; data channel, if HTTP cloaking or HTTP streaming is used|
|listen on||6970 - 6999||UDP||data channel (not configurable)|
© 2002 RealNetworks, Inc. All rights reserved.
For more information, visit RealNetworks
Click here if the Table of Contents frame is not visible at the left side of your screen.