Streaming Media Supplement sa2150 and sa2250

32
Chapter 3 Understanding Media-IXT and RealNetworks
Network-level firewalls and RealNetworks
The main point to bear in mind when configuring a network-level firewall for use with Media-IXT is that the
ports used by your deployment’s streaming protocols are open.
How RealPlayer uses ports
The RealPlayer uses both the TCP and UDP ports. The player uses the TCP port to:
• initiate a conversation with an external RealServer
• authenticate the player to the server, and
• pass control messages (such as pause or stop) during playback.
The UDP ports carry the incoming stream. Only after the player and RealServer have performed their
authentication routine do the UDP ports begin to carry traffic. Enable the UDP ports for incoming traffic only.
The design parameters of your network determine which approach to firewall configuration is most appropriate
for your deployment. You can:
• Open a range of ports in your firewall for UDP
• Open a range of ports in your firewall for TCP, and instruct players to use TCP for all content; note that this
option degrades playback quality
• Configure your firewall to receive UDP through only one port and instruct players to use UDP with the port
you chose
• Tell users to configure RealPlayer to request that RealServer send all media in HTTP format; note that this
creates more overhead on your network than any of the other options
SOCKS firewalls and RealNetworks
Streaming RealNetworks through a SOCKS firewall is not supported by HP.
Understanding the limitations of RealProxy and of the PNA
protocol
There are a number of cases where limitations of Media-IXT’s RealProxy component, or the obsolete PNA
protocol itself, require awareness on the part of the administrator.
RealProxy does not perform DNS round robin.
In proxy deployments where an origin RealServer farm has
a single name that resolves to multiple addresses, the RealProxy performs an nslookup and connects to only
one of these IP addresses. It does not perform DNS round robin on these addresses. As a result, there is no load
balancing for the server farm.
Some RealServers do not allow Media-IXT to cache their content.
Some RealServer G2 installations
shipped from RealNetworks do not have inktpln, the caching plugin. Others are behind firewalls that do not
permit traffic from inktpln to pass through. These servers do not allow Media-IXT caching of their content,
so all accesses show a “Demand Pass-Through” status in the proxy.log file. This applies to pre-G2
RealServers (versions 5.0 and before).
Latency playing .ram clips with embedded URLs using international character sets.
Media-IXT cannot
cache RTSP or PNA URLs with multi-byte character names. When RTSP or PNA URLs using multi-byte
character sets (international character sets) are embedded in .ram files, these .ram files fall to passthrough
mode. The client experiences high latency during playback of these .ram files.
Cacheability for PNA does not work in deployment using layer 4 transparency.
The cacheability part of
the selective caching feature fails in a deployment using L4 transparency.
Adding a rule of the form
dest_ip=10.10.10.10 action=never-cache