Streaming Media Supplement sa2150 and sa2250

54
Chapter 5 Understanding Media-IXT and QuickTime
Beyond simple forward proxy, reverse proxy, and transparency for QuickTime
This section describes scenarios that have special configuration requirements for deployments which stream
QuickTime 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 a designator to a reverse proxy remapping rule in the remap.config file, you can
determine that the rule applies exclusively to either RealNetworks or QuickTime content.
So, for example, you might have these rules, which map your advertised website name of
lotsa.flicks.com to two different origin servers: one for QuickTime, and one for RealNetworks:
map rtsp://lotsa.flicks.com/ rtsp://qtserver.archive.com/ QT
map rtsp://lotsa.flicks.com/ rtsp://rnserver.archive.com/ RNI
You can do this either through Traffic Manager or by manually editing remap.config.
For the configuration procedure, see “Configuring reverse proxy caching for QuickTime” on page 95.
Simultaneous forward and reverse proxy caching for QuickTime
For QuickTime, Media-IXT can:
• perform forward proxy and reverse proxy simultaneously,
- OR -
• perform forward proxy exclusively,
- OR -
• perform reverse proxy exclusively.
To restrict Media-IXT to perform reverse proxy caching exclusively for QuickTime content, edit the
proxy.config.reverse_proxy.enabled configuration variable in records.config.
Understanding multi-bitrate clips and QuickTime
Origin QuickTime servers do not host multi-bitrate clips.
Understanding hierarchy and QuickTime
Hierachical proxy caching for QuickTime is straightforward. On receiving a request for content from a client,
the child Media-IXT checks its cache, and if the content is not fresh or present, checks for that content on a
parent Media-IXT.
To a child Media-IXT, a parent Media-IXT looks like an origin server. So, connections between the child and
parent Media-IXT in a hierarchy are over TCP, while the child Media-IXT streams content to the client
QuickTime player over UDP. The client sends requests to Media-IXT via RTSP, which uses TCP as its
underlying transport protocol.
A child Media-IXT can have one parent Media-IXT for QuickTime content and another, different parent Media-
IXT for RealNetworks content.
This requires use of a designator field in the parent selection rules of the parent.config file.
You can add the field only by manually editing parent.config.