Streaming Media Supplement sa2150 and sa2250

24
Chapter 3 Understanding Media-IXT and RealNetworks
You must configure the nodes so that:
• the Media-IXT node answers to the advertised name of your RealNetworks streaming content website–
precisely what the origin RealNetworks server would do if your Media-IXT did not exist
• the remap.config file on the Media-IXT host contains the appropriate map and reverse_map rules
• the proxy.config.reverse_proxy.enabled variable in Media-IXT’s records.config file
is set to true
For details about writing remapping rules and other aspects of configuration see “Configuring reverse proxy
caching for RealNetworks” on page 66.
To show how reverse proxy caching works for RealNetworks step by step, we consider an example in which a
user has a web browser with RealPlayer, and is viewing the home page of the website,
www.greatmovies.com
.
Media-IXT is serving that home page because Media-IXT has been configured
to answer to the advertised server name, www.greatmovies.com
.
The action begins when the user clicks on a link for a movie called Epic.
1. The RealPlayer sends an RTSP request containing the URL:
rtsp://greatmovies.com:554/epic.rm/
2. Media-IXT finds the hostname of the origin RealServer in the map rules contained in the remap.config
configuration file.
3. Media-IXT rewrites URLs in the client request, replacing the advertised site name with the hostname of the
origin RealServer.
Our example URL is rewritten:
rtsp://reallygreatmovies.com:554/epic.rm/
4. Media-IXT opens a TCP connection to the origin RealServer at the rewritten URL.
5. Media-IXT determines whether the requested content is in cache, and whether it is fresh.
6. If the content is in cache but stale, or is not in cache, Media-IXT pulls the requested content from the origin
RealServer, and caches the content, while streaming the content to RealPlayer.