Streaming Media Supplement sa2150 and sa2250

21
Chapter 3 Understanding Media-IXT and RealNetworks
For transparent PNA, clients can use any RealPlayer software; for transparent RTSP, clients must use
RealPlayer version 6.0 or later (that is, RealPlayer G2).
For an explanation of transparency devices (layer 4 switches and WCCP2 routers) see Chapter 2‚ Media-IXT
Deployment Scenarios.
Transparent, forward proxy caching for the HTTP, FTP and NNTP protocols is described in the HP Cache
Server Appliance Administrator Guide. For RTSP and PNA, transparent, forward proxy caching works a little
differently.
The relevant Media-IXT components are:
• the Traffic Server cache
• the Adaptive Redirection Module (ARM)
• RealProxy
Meanwhile, the origin RealNetworks server:
• must be RealServer G2 with
inktpln
, the cache plugin, installed
These are the relationships between Media-IXT’s components, the origin RealServer, and RealPlayer:
• Traffic Server’s role is caching and transparent readdressing.
• RealProxy, together with plugins from HP ?? and RealNetworks, handles proxying.
• As in explicit forward proxy caching, RealProxy opens an accounting connection with the origin RealServer
during every client-cache transaction.
• RealPlayers, like QuickTime players, use RTSP as the control protocol, so they direct RTSP requests to port
554.
• With transparency enabled, Media-IXT tunnels RealNetworks traffic from port 554 to its RealNetworks
RTSP port, which is port 9231.
Here is how forward, transparent proxy caching for RTSP plays out step by step:
1. A RealPlayer client sends an RTSP request addressed to the origin RealServer on port 554.
2. The layer 4 switch or WCCP2 router intercepts the port 554 traffic and redirects it to Media-IXT at port
1091.
3. If the RTSP request comes from a RealPlayer, Media-IXT issues the client a redirect to port 9231.
(If the request is from a QuickTime player, Media-IXT continues to communicate with the client on port
1091.)
4. RealPlayer sends the redirected RTSP request to Media-IXT on port 9231.
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.
7. If not, Media-IXT closes the accounting connection and returns an error to the client; the remaining steps
do not apply in this event.
8. Media-IXT determines whether the requested content is in cache, and whether it is fresh.
9. 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.
Media-IXT streams content to the RealPlayer client. Figures 9 and 10, below and on the next page, show
RealNetworks forward, transparent proxy caching.