Streaming Media Supplement sa2150 and sa2250

26
Chapter 3 Understanding Media-IXT and RealNetworks
Where Media-IXT and the origin RealServers are owned by the same company, a content distribution network
for example, and Media-IXT performs reverse proxy for the server farm, it is possible to fix the problem. For
details see “Configuring reverse proxy for a RealNetworks server farm with a layer 4 switch” on page 67.
Simultaneous forward and reverse proxy caching for RealNetworks
For RealNetworks, Media-IXT can:
• perform forward proxy and reverse proxy simultaneously,
- OR -
• perform forward proxy exclusively.
There is no mechanism for restricting Media-IXT to perform reverse proxy caching exclusively for
RealNetworks content.
Understanding reverse proxy for QuickTime and RealNetworks simultaneously
A single Media-IXT can perform reverse proxy for both RealNetworks and QuickTime origin servers
simultaneously. By adding an optional designator to a reverse proxy mapping rule in the remap.config file,
you can make the rule apply exclusively to either RealNetworks or QuickTime content.
You can do this either through Traffic Manager or by manually editing remap.config.
For the configuration procedure, see “Configuring reverse proxy caching for RealNetworks” on page 66.
Understanding multi-bitrate clips and RealNetworks
Given the situation where an origin server has got a multi-bitrate clip, say a movie encoded for streaming at
three different bitrates (20kbps, 100kbps, and 300kbps), the question arises as to how Media-IXT handles
caching of such a clip.
The answer is that since a RealPlayer client requests only one version (one bitrate) at a time, Media-IXT serves
and caches only that bitrate in response to that request. If the client connection changes (for example, drops from
T1 to 56.6K) while streaming is in progress, Media-IXT stops serving and caching the initial bitrate and
continues at the new one.
So, unlike the origin RealServer, Media-IXT does not cache all the different versions of a clip that make up a
multi-bitrate clip, except in response to requests by RealPlayers.
Understanding hierarchy and RealNetworks
Media-IXT hierarchical deployments support the RTSP protocol only for RealNetworks content. Hierarchical
proxy caching of PNA content is not supported. This is a function of the PNA protocol’s limitations.
In hierarchical deployments, the child proxy maintains an accounting connection to the parent proxy, while the
parent proxy maintains an accounting connection to the origin RealServer.
Understanding Media-IXT hierarchies depends on knowing the answers to two questions:
• Which Media-IXT is to be a child and which is to be a parent?
• Which caches should serve as parents for each child cache?
Configuring Media-IXT for hierarchical proxy caching is done in two stages:
• First, edit the records.config file to enable parent caching on each child cache.
• Then, edit the parent.config file on each child cache to redirect streaming media traffic to specific
parent caches.
Remember, you make no changes on parent caches. All configuration is done on child caches.