Streaming Media Supplement sa2150 and sa2250

23
Chapter 3 Understanding Media-IXT and RealNetworks
1. A RealPlayer client sends a PNA request on port 7070.
2. The layer 4 switch or WCCP2 router intercepts the port 7070 traffic and redirects it to Media-IXT.
3. Media-IXT issues the client a redirect to a port that is dynamically assigned for that particular request.
4. RealPlayer sends the redirected PNA request to the dynamically assigned port.
5. Media-IXT opens an accounting connection to the origin RealServer, dedicating the connection to the client
which sent the request.
6. If the client is allowed access, Media-IXT opens a TCP connection to the origin RealServer.
If not, Media-IXT closes the accounting connection and returns an error to the client; the remaining steps
do not apply in this event.
7. Media-IXT determines whether the requested content is in cache, and whether it is fresh.
8. 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.
If the content is in cache and is fresh, Media-IXT streams the content to RealPlayer and does not need to
pull the content from the origin server.
More about redirects and RealNetworks streaming
We have seen that Media-IXT issues redirects to RealPlayer clients, which then communicate with Media-
IXT’s RealProxy component on port 9231. Communications between a proxy cache and a media player,
including between Media-IXT and RealPlayer, take place at the edge of the network. For communications away
from the edge, where proxy caches communicate with other proxy caches, Media-IXT behaves differently than
it does with RealPlayer. When streaming RealNetworks data to other proxy caches, Media-IXT does not send
redirects; instead, it uses port 1091 for all communications, and, internally, tunnels data between port 1091 and
port 9231.
Understanding reverse proxy caching for RealNetworks
Media-IXT, performing reverse proxy caching for RealNetworks content, opens an accounting connection with
the origin RealServer and serves requests from the Traffic Server cache, just as in forward proxy caching.
What’s special about reverse proxy caching is that the advertised origin server name and the host name of the
origin RealServer are different. The Media-IXT needs to know the origin RealServer name that corresponds to
the advertised server name.
For example, the advertised media server name might be greatmovies.com, and the origin RealServer
might be reallygreatmovies.com. If a client sends a request to greatmovies.com, RealProxy must
open an accounting connection with reallygreatmovies.com.
You must configure Media-IXT to understand the correspondence between advertised server names the origin
RealServer hostnames by editing the remap.config configuration file. See Chapter 7‚ Configuring Media-
IXT for RealNetworks.
Like forward proxy caching, reverse proxy caching of RealNetworks content requires two nodes:
• an origin RealNetworks server, where content resides in the form of .rm or .ra files, or another of the
many file formats RealNetworks supports
• the Media-IXT host
NOTE Reverse proxy is not supported for PNA content. Do not attempt to configure reverse
proxy for PNA content. This section discusses reverse proxy for RTSP only.