Streaming Media Supplement sa2150 and sa2250

49
This chapter assumes that you understand the elements of a proxy caching deployment, which are explained
in Chapter 2‚ Media-IXT Deployment Scenarios.
In this chapter, we explain feature implementation for QuickTime media streaming.
We discuss each possible element of a deployment in turn, following the same order as the previous chapters:
• “Understanding forward proxy, reverse proxy, and transparency for QuickTime” below
• “Understanding multi-bitrate clips and QuickTime” on page 54
• “Understanding hierarchy and QuickTime” on page 54
• “Understanding live passthrough, live splitting, and hierarchical live splitting for QuickTime” on page 55
• “Understanding clustering and QuickTime” on page 55
• “Understanding VIP failover and QuickTime” on page 55
• “Understanding selective caching and QuickTime” on page 56
• “Understanding CDS preload and QuickTime” on page 56
• “Understanding authentication and QuickTime” on page 56
Understanding forward proxy, reverse proxy, and
transparency for QuickTime
While all on-demand content is cacheable by default, the QuickTime server administrator can specify which
content on the server is non-cacheable.
Normally, requests for QuickTime content are ultimately directed to Media-IXT’s port 1091:
• in explicit deployments, client QuickTime players are configured to send requests to port 1091 on Media-
IXT.
• in transparent deployments, client QuickTime players send requests to Media-IXT’s port 554, the normal
port for RTSP traffic.
QuickTime’s usual file extensions are:
• .sdp for live QuickTime content
• .mov for on-demand QuickTime content
Use of RTSP by both QuickTime and RealNetworks
Both QuickTime Players and RealPlayers use RTSP for control commands. There are several consequences of
this fact.
In transparent proxy caching deployments, Media-IXT may receive RTSP traffic from both QuickTime players
and Real Players. RTSP traffic comes in on port 554, which Media-IXT’s ARM module redirects internally to
port 1091. Media-IXT then distinguishes between RTSP requests that originate from QuickTime players and
those that originate from RealPlayers. Media-IXT then issues redirects to RealPlayer clients, so that they then
connect to Media-IXT’s RealProxy component on port 9231.
Although QuickTime Players and RealPlayers both use RTSP for control commands, they use different
encoding schemes, so a RealPlayer cannot play QuickTime content. Neither can a QuickTime player play
RealNetworks content.
5 Understanding Media-IXT and QuickTime