Cisco ACNS Software Configuration Guide for Locally Managed Deployments, Release 5.2 - Chapter 8: Configuring RTSP Media Services on Standalone Content Engines [Cisco Application and Content Networking System (ACNS) Software]

Table Of Contents

Configuring RTSP Media Services on Standalone Content Engines

Overview of RTSP Streaming and Caching for Standalone Content Engines

About the RealMedia Streaming Media Solution for Standalone Content Engines

About the RTSP Gateway and Backend RTSP Servers

About Live Splitting and Caching VOD Files with RealProxy

About Caching Policies in RealMedia Caching

About Access Control

About RealProxy SMIL File Support

About the RealProxy License Key

Configuring RealProxy Streaming and Caching Services for Standalone Content Engines

Enabling RealProxy on Standalone Content Engines

Configuring the RTSP Gateway for Standalone Content Engines

Default RTSP Gateway Settings

Configuring Basic Settings for the RTSP Gateway

Configuring Advanced Options for the RTSP Gateway

Configuring RTSP Transparent Redirection and RealProxy Transparent Caching

Configuring Direct Proxy Routing and RealMedia Proxy Caching

Configuring RealProxy with the RealSystem Administrator GUI

Verifying RealProxy Configurations for Standalone Content Engines

Scenario 1—Verifying the Configuration for RealMedia VOD Caching

Scenario 2—Verifying the Configuration for RealProxy Live Splitting

Restoring the Default RealProxy Configuration on Standalone Content Engines

Restarting RealProxy on Standalone Content Engines

Disabling RealMedia Caching on Standalone Content Engines

Uninstalling the RealProxy License Key

Displaying RealProxy Statistics for Standalone Content Engines

Configuring RTSP Media Services on Standalone Content Engines

This chapter describes how to configure Real-Time Streaming Protocol (RTSP) streaming and caching services on standalone Content Engines, including how to configure the RTSP gateway that runs on the Content Engine. This chapter contains the following sections:

•Overview of RTSP Streaming and Caching for Standalone Content Engines

•Configuring RealProxy Streaming and Caching Services for Standalone Content Engines

•Verifying RealProxy Configurations for Standalone Content Engines

•Restoring the Default RealProxy Configuration on Standalone Content Engines

•Restarting RealProxy on Standalone Content Engines

•Disabling RealMedia Caching on Standalone Content Engines

•Uninstalling the RealProxy License Key

•Displaying RealProxy Statistics for Standalone Content Engines

For background information about streaming media services, see the "Understanding Some Basic ACNS Streaming Media Concepts" section. For complete syntax and usage information for the CLI commands used in this chapter, refer to the Cisco ACNS Software Command Reference, Release 5.2 publication. For information about how to configure streaming media services for Content Engines that are registered with a Content Distribution Manager, refer to the Cisco ACNS Software Configuration Guide for Centrally Managed Deployments, Release 5.2.

Note All cached RealMedia content is deleted from the Content Engine mediafs cache when you upgrade a Content Engine from any ACNS release to the ACNS Release 5.1.9 or later, or ACNS Release 5.2.1 or later. This happens because the meta file formats have been changed in these releases, affecting the way that the cached RealMedia streaming file is interpreted.

Overview of RTSP Streaming and Caching for Standalone Content Engines

Streaming is a technology that allows content to be accessed or viewed before all the media packets have been received, whereas with caching, the content must be received in its entirety before it can be accessed. Streaming media can be delivered as live content or as on-demand content, such as video on demand (VOD).

Cisco ACNS software supports several types of streaming media solutions, including the Windows Media Technologies (WMT) solution from Microsoft Corporation and the RealMedia solution from RealNetworks, Inc. See Table 1-3 for a list of supported streaming media solutions. The type of streaming media solutions that you can deploy varies based on whether the Content Engine is registered with a Content Distribution Manager or is a standalone Content Engine. With registered Content Engines, all of the solutions listed in Table 1-3 are supported, whereas only the WMT and RealMedia solutions are supported with standalone Content Engines. For example, the RTSP-based Cisco Streaming Engine and Apple QuickTime solutions are not supported on standalone Content Engines.

RTP and RTSP are two Internet standard protocols that are designed for streaming media over the Internet.

•RTP (RFC-1889) is the data transfer protocol for multimedia data over both unicast (TCP and UDP) and multicast.

•RTSP is a standard Internet streaming control protocol (RFC-2326).

RTSP is an application-level protocol that controls the delivery of streaming media data with real-time properties, such as video and audio. RTSP is a text-based protocol, and typically runs over TCP port 554. RTSP acts as a network remote control for multimedia servers and has been widely adopted as a streaming media protocol. Apple QuickTime, RealProxy, and Cisco Streaming Engine are all content distribution methods that use RTSP as the streaming media protocol, and RTP as the data transfer protocol. RealNetworks added proprietary extensions to the standard RTSP protocol (for example, the challenge and response between a RealMedia client and a RealNetworks streaming server).

Support for the IETF standard RTP and RTSP protocols is included as part of ACNS software product, Release 5.1 or later. However, separate licenses are required for the following two streaming media features that can be enabled on a Content Engine that is running ACNS 5.x software:

•The WMT streaming media feature requires a WMT license. For more information about the WMT streaming solution for standalone Content Engines, see the "Configuring WMT Streaming Media Services on Standalone Content Engines" section.

•The RealProxy streaming media feature requires a RealProxy license. For more information on this topic, see the "Configuring RealProxy Streaming and Caching Services for Standalone Content Engines" section.

Note For information about how to configure streaming media services for Content Engines that are registered with a Content Distribution Manager, refer to the Cisco ACNS Software Configuration Guide for Centrally Managed Deployments, Release 5.2.

About the RealMedia Streaming Media Solution for Standalone Content Engines

RealMedia is the streaming media solution from RealNetworks, Inc. RealMedia uses the RealNetworks RTSP protocol (IETF standard RTSP protocol plus proprietary extensions) to deliver streaming media content to RealMedia clients (for example, RealPlayer 8.0 and RealOne players).

RealMedia has two main software components (RealProxy and RealSubscriber). With registered Content Engines, you can enable and run RealProxy and RealSubscriber; however, standalone Content Engines only support RealProxy. You cannot enable and run RealSubscriber on a standalone Content Engine.

The RealProxy software from RealNetworks, Inc., included as a software option in ACNS 5.x software enables you to deploy the following RealMedia services on standalone Content Engines:

•Live splitting (distributing live feeds)

•Streaming video-on-demand (VOD) files in an RTSP-based format

•Caching VOD files

Table 8-1 describes RealMedia supported services for standalone Content Engines.

Table 8-1 RealMedia Streaming and Caching Services Supported for Standalone Content Engines

Service

Description

RealMedia proxy
caching of VOD files

The standalone Content Engine is functioning as a nontransparent proxy server for end users who are using a RealMedia player to request content. After receiving an RTSP request directly from a RealMedia player, the Content Engine retrieves the requested VOD file if it is not already stored in its local cache, stores a copy locally, and sends the requested content to the RealMedia player. See the "Configuring Direct Proxy Routing and RealMedia Proxy Caching" section.

RealMedia transparent
caching of VOD files

The standalone Content Engine is functioning as a transparent proxy server for end users who are using a RealMedia player to request content. After receiving a redirected RTSP request from a WCCP Version 2 router or Layer 4 switch, the Content Engine retrieves the requested content, stores a copy locally, and sends the requested content to the RealMedia player. See the "Configuring RTSP Transparent Redirection and RealProxy Transparent Caching" section.

RealProxy live splitting

The Content Engine serves RTSP live streams to all local users (RealMedia players) whose requests are directed to it. The RTSP live streams can be unicast live feeds or multicast live feeds. The Content Engine splits the live feeds into a multicast or unicast to relay the stream to the RealMedia client. Live streams are not files, so cannot be cached, whereas VOD files can be cached. See the "About Live Splitting and Caching VOD Files with RealProxy" section.

Note In ACNS 5.2 software, support for Synchronized Multimedia Integration Language (SMIL) files in RealProxy was added. For more information, see the "About RealProxy SMIL File Support" section.

Table 8-2 describes the RealProxy features and benefits for standalone Content Engines.

Table 8-2 RealProxy Features and Benefits

RealProxy Feature

Description

Benefits

Proxy for RealMedia players
(for example, RealPlayer 8.0
or RealOne players)

RealProxy makes requests for content on behalf of the RealMedia clients.

Manages traffic inside the firewall by coordinating requests for similar content.

Masks end user IP addresses.

Splitting support for
live broadcasts

RealProxy "splits" a single inbound live broadcast feed to multiple RealMedia clients.

Reduces inbound bandwidth usage to a single stream of content during a live event.

Caching of RealSystem G2
and Progressive Network
Audio (PNA) content

RealProxy caches all proxied streaming media traffic from RealNetworks servers. RealProxy caches content locally after authentication with the origin streaming server.

Significantly reduces inbound bandwidth usage by eliminating redundant file transmissions across the network.

Authentication and
accounting

RealProxy authenticates every content request with the origin streaming server before delivering the cached content to the clients.

Retains access to general usage data for the broadcaster.

Appropriately authenticates users.

Guarantees the freshest content for end users.

Aggregate bandwidth
thresholds

RealProxy thresholds allow you to specify the maximum bandwidth for inbound and outbound RTSP traffic (cached content and live content).

Provides control over aggregate bandwidth usage within the network and prevents stress on mission-critical applications.

Proxy routing

RealProxy can tier proxies and manage bandwidth at lower nodes in the network. "Parent" proxies can be chosen based on logical sets of rules on the downstream proxy.

Allows you to proxy route requests, providing an additional level of control.

The Content Engine can be configured to accept transparently redirected content requests as well as traditional proxy-style requests from RealMedia players. The redirection of RTSP traffic to the Content Engine media cache is enabled through the Content Engine GUI or CLI. The RealProxy software is configured with the RealSystem administrator GUI, accessed from the RealProxy window of the Content Engine GUI. (See the "Configuring RealProxy with the RealSystem Administrator GUI" section.)

The RealProxy feature on a standalone Content Engine is licensed software. For more information on this topic, see the "About the RealProxy License Key" section.

About the RTSP Gateway and Backend RTSP Servers

The RTSP gateway is the single point of entry for RTSP messages. The RTSP gateway is automatically enabled and runs on the standalone Content Engine. The RTSP gateway listens on the standard RTSP port (default port 554) and funnels incoming RTSP traffic through it to enforce rules-based implementation and URL filtering of RTSP requests. Based on the properties of the incoming request, including such properties as the client player, final destination, and media file type, the RTSP gateway sends the request to one of the backend RTSP servers that are running on the Content Engine. The RTSP gateway encodes the URL so that the backend RTSP servers know the original URL before unified name space (UNS) translation.

Note The RTSP-based servers that are running on the Content Engine are also referred to as "backend RTSP servers."

On standalone Content Engines that are running ACNS software, Release 5.2 or earlier, RealProxy is the only RTSP-based content distributor (RTSP backend server) that can be enabled on the Content Engine. The RealProxy server uses the RealNetworks RTSP proprietary protocol over RTP to stream RTSP content to RealMedia players to stream RTSP content to RealMedia players.

In contrast, if a Content Engine is part of a device group in an ACNS 5.x environment (that is, the Content Engine is registered with a Content Distribution Manager), then RealSubscriber and Cisco Streaming Engine are also supported as backend RTSP servers that run on the registered Content Engine. For information about how to configure Cisco Streaming Engine and RealSubscriber for registered Content Engines, refer to the Cisco ACNS Software Configuration Guide for Centrally Managed Deployments, Release 5.2.

Each backend RTSP server that is running on the Content Engine performs its own transaction logging. For example, RealProxy uses RealProxy transaction logs. By default, transaction logging is enabled on a Content Engine.

For more information about the RTSP gateway, see the "Configuring the RTSP Gateway for Standalone Content Engines" section.

About Live Splitting and Caching VOD Files with RealProxy

When RealProxy is enabled on a standalone Content Engine, the Content Engine will serve as the stream splitting point for all local users (RealMedia players) whose RealMedia requests is directed to the Content Engine. All subsequent requests to that origin streaming server (the Helix Universal Server) are served by the Content Engine, which splits the stream and serves it to the RealMedia clients.

Figure 8-1 shows how the Content Engine splits one unicast live stream into multiple unicast streams in the local network. Note that when the first client (Client 1) that requested the original stream disconnects from the network, the Content Engine continues to serve the other clients (Client 2 and Client 3) until all clients disconnect from the network.

Figure 8-1 How a Standalone Content Engine Supports Live Splitting

By having the Content Engine perform the live splitting, you potentially save considerable network bandwidth between the client and the origin streaming server, because the Content Engine is closer to the clients.

Note RealProxy cannot cache live broadcasts (also referred to as "live clips" and "live streams") because there is no actual downloadable file to cache. However, RealProxy supports live splitting in order to allow RealMedia clients to "share" the broadcast, thereby saving WAN bandwidth.

When the Content Engine receives a request for a RealMedia VOD file (.rm file) that is not already stored in its local cache, the Content Engine retrieves the requested VOD file from the origin streaming server (the Helix Universal Server), caches the VOD file if RealMedia caching is enabled on the Content Engine, and streams the requested VOD file to the RealMedia client.

In both operations (streaming of VOD files and live splitting), the RealMedia request can be directed to the Content Engine through one of two means:

•Transparent redirection through WCCP Version 2 or Layer 4 switching

•Direct proxy routing (explicitly configuring the RealMedia player proxy settings)

Configuration for both of these operations is the same on the Content Engine and routers; the only difference is the source (a VOD file or a live stream).

All incoming RTSP requests are directed to the RTSP gateway on the Content Engine. The RTSP gateway decides which backend RTSP server on the Content Engine (for example, RealProxy) to direct the request to. For more information about the RTSP gateway, see the "Configuring the RTSP Gateway for Standalone Content Engines" section.

For more information about RealMedia caching for standalone Content Engines, see the "Configuring RealProxy Streaming and Caching Services for Standalone Content Engines" section.

About Caching Policies in RealMedia Caching

In contrast to HTTP caching, caching policies in RealMedia caching are much simpler, because streaming media are mostly large static content. The caching policy in RealMedia caching is straightforward. All responses other than live streams are cacheable (VOD files can be cached), including partial responses. All RealMedia requests result in communication between the Content Engine and the origin streaming server (the Helix Universal Server), even if the request is a cache hit.

By establishing the streaming control session, the Content Engine can verify that its cached content is fresh, and the client can access the content. Because streaming objects are typically very large in size, the overhead of establishing the control session with the server is negligible and does not reduce the bandwidth savings from the cache hits.

Note Live streams are not cached.

About Access Control

If a RealMedia client requests a cached stream, before the client is allowed to play the stream, the RealProxy server that is running on the Content Engine uses the RealNetworks proprietary RTSP protocol to send the request to the origin streaming server (Helix Universal Server) for permission. If the origin streaming server denies the request, the RealMedia client is not allowed to receive the requested stream.

About RealProxy SMIL File Support

SMIL is a simple but powerful markup language that allows you to coordinate multiple clips. SMIL also allows you to define how, when, and where you want the multiple clips to be played.

A client browser can automatically launch the media player on the client desktop when the video and presentation material is packaged in a media-index file such as an SMIL file. The browser is typically configured so that the moment it retrieves an SMIL file, it automatically launches the RealMedia player on the client desktop, and passes the SMIL file to the client RealMedia player. Media-index files can contain either relative links to media files or absolute links to media files.

Note The .asx file is used by the WMT streaming solution, and the SMIL file is used by the RealNetwork streaming solution. For more background information on media-index files, see the "How a Client Media Player Issues a Request" section.

SMIL files are used for the following main purposes:

•To describe the overall layout of the SMIL-based presentation.

•To act as the macro meta file for the SMIL-based presentation. Rather than encoding presentations in a single file, SMIL allows content creators to encode pieces of the presentation in separate files and then use SMIL to control the interaction of these separate files. The SMIL file points to the source of the media and data files, as well as the source of the more specific meta files that comprise the SMIL-based presentation.

•To establish the overall timeline of the SMIL-based presentation.

With a SMIL-based presentation, each element in the presentation can be encoded and transmitted separately, with synchronization control. Consequently, content creators can optimize the delivery of their SMIL-based presentations by specifying the least bandwidth-intensive format for transmittal. In addition to reducing the bandwidth requirements, SMIL also expedites the process of editing an SMIL-based presentation after the presentation is completed. For example, a content creator can use SMIL to easily delay the audio track of a completed SMIL-based presentation (for example, have the audio not start for 5 seconds after the presentation begins) without having to edit the actual audio file.

In ACNS 5.2 software, SMIL file support for RealProxy was added. SMIL support is provided under the following conditions:

•Case 1—The SMIL file and its contents are pre-positioned on a registered Content Engine.

•Case 2—The SMIL file and its contents are not pre-positioned on the Content Engine.

•Case 3—The SMIL files have absolute URLs, and each URL is pointing to a different server.

All of the above three cases are supported on Content Engines that meet the following requirements: the Content Engine is running ACNS software, Release 5.2 or later, RealProxy is enabled on the Content Engine, and the Content Engine is registered with a Content Distribution Manager.

Only Cases 2 and 3 are supported on standalone Content Engines (Content Engines that are not registered with a Content Distribution Manager) that meet the following requirements: the Content Engine is running ACNS software, Release 5.2 or later, and RealProxy is enabled on the Content Engine.

About the RealProxy License Key

The RealNetworks, Inc. RealProxy product is licensed software. To activate the licensed RealProxy feature on a standalone Content Engine, you must have a RealProxy license key. You must specify a permanent RealProxy license key that is supplied on a certificate shipped with the Content Engine, or use an evaluation key for a temporary period. If you are downloading ACNS 5.x software, you can purchase a RealProxy license though the Cisco.com website. You specify the RealProxy license key as part of enabling the RealProxy feature on a standalone Content Engine. See the "Enabling RealProxy on Standalone Content Engines" section.

Configuring RealProxy Streaming and Caching Services for Standalone Content Engines

The Content Engine can be configured to accept transparently redirected RTSP requests as well as traditional proxy-style RTSP requests from RealMedia players. RealProxy also supports live splitting and caching of RealMedia VOD files (.rm files).

The Setup utility allows you to enable the licensed RealProxy feature on a standalone Content Engine that is running ACNS software, Release 5.2 or later, and then enable RealMedia proxy caching and RealMedia transparent caching on the Content Engine. With the Setup utility, you can configure the Content Engine to accept redirected RTSP requests from a WCCP Version 2-enabled router. With the Content Engine CLI, you can configure the Content Engine to accept redirected RTSP requests from a WCCP Version 2-enabled router or a Layer 4 switch. RealProxy is configured with the RealSystem administrator GUI, which is accessed from the RealProxy window of the Content Engine GUI. (For information about access the RealSystem administrator GUI, see the "Configuring RealProxy with the RealSystem Administrator GUI" section.)

Note For information about how to use the Setup utility to enable RealMedia caching on a standalone Content Engine, see the "Configuring a Basic Configuration on Standalone Content Engines with the Setup Utility" section.

This section describes how to use configure RealProxy streaming and caching services for a standalone Content Engine through the Content Engine CLI and the RealSystem Administrator GUI. The following topics are described in this section:

•Enabling RealProxy on Standalone Content Engines

•Configuring the RTSP Gateway for Standalone Content Engines

•Configuring RTSP Transparent Redirection and RealProxy Transparent Caching

•Configuring Direct Proxy Routing and RealMedia Proxy Caching

•Configuring RealProxy with the RealSystem Administrator GUI

When configuring RealProxy streaming and caching services with standalone Content Engines, note the following important points:

•In order to support RealMedia transparent caching, WCCP Version 2 must be running on the standalone Content Engine. WCCP Version 2 must also be running on the routers that will be redirecting RTSP requests to the Content Engine.

•You must configure disk space to include mediafs storage with the disk config command before you can run cache streaming media using RealProxy.

The mediafs partitions is mounted on the standalone Content Engine. This is the storage partition that is used to store any RTSP streaming media content that is cached on the Content Engine.

•You have the IP address of the WCCP Version 2-enabled routers if you want to use transparent WCCP redirection.

•You have the IP address of the standalone Content Engine that you want to enable and run RealProxy on.

•You have a RealProxy license key. For information about the RealProxy license, see the "About Live Splitting and Caching VOD Files with RealProxy" section.

•Live broadcasts are live streams and not files, and therefore cannot be cached. However, RealProxy can split live broadcast (live splitting) to conserve network bandwidth. For more information about live splitting, see the "About Live Splitting and Caching VOD Files with RealProxy" section.

Note Content Engines that use a Content Service Switch (CSS) to load balance streaming traffic cannot stream UDP traffic (such as MMSU and RTSPU), because the Content Service Switch does not support UDP traffic.

Figure 8-2 provides a detailed view of how to configure RealProxy streaming and caching initially for standalone Content Engines.

Figure 8-2 Configuring RTSP Streaming and Caching Services for Standalone Content Engines

Table 8-3 is a checklist of tasks for configuring RTSP streaming and caching services for standalone Content Engines that are running ACNS software, Release 5.2 or later. This checklist includes the steps involved in configuring these services on a standalone Content Engine, including the configuration of one or more routing methods to direct RTSP requests to the Content Engine.

Table 8-3 Checklist for Configuring RTSP Streaming and Caching Services for Standalone Content Engines

Task

Additional Information and Instructions

1. Enable the RealProxy feature on the
standalone Content Engine.

a. Accept the RealProxy license agreement.

b. Accept the evaluation RealProxy license, or
specify your Cisco permanent RealProxy license.

c. Enable the licensed RealProxy feature on
the standalone Content Engine.

See the "Enabling RealProxy on Standalone Content Engines" section.

2. If necessary, specify the RTSP gateway settings.

a. If the Content Engine is behind a NAT-enabled
router, you must specify the IP address of the
RTSP gateway (required).

b. You can also change the default basic and
advanced RTSP gateway settings (optional).

See the "Configuring the RTSP Gateway for Standalone Content Engines" section.

3. Configure one or more of the following routing methods
to direct content requests from RealMedia players to the
RTSP gateway on this standalone Content Engine:

–Direct proxy routing (nontransparent)

–Transparent redirection (WCCP Version 2 routing or
Layer 4 switching)

With direct proxy routing, the RealMedia client players (for example, RealPlayer or RealOne player) send their content requests directly to this Content Engine (acting as a nontransparent forward proxy server). With direct proxy routing, you must point the RealMedia clients directly to the Content Engine. See the "Configuring Direct Proxy Routing and RealMedia Proxy Caching" section.

With WCCP routing or Layer 4 switching, you must configure the WCCP routers or Layer 4 switches and the Content Engine (transparent proxy server) for RTSP transparent redirection. See the "Configuring RTSP Transparent Redirection and RealProxy Transparent Caching" section.

4. Use the RealSystem administrator GUI to configure
RealProxy (for example, configure live splitting
with RealProxy).

Tip Live broadcasts are live streams are not files;
therefore, they cannot be cached. However,
RealProxy can split live broadcasts (live splitting)
to conserve network bandwidth.

See the "Configuring RealProxy with the RealSystem Administrator GUI" section.

Enabling RealProxy on Standalone Content Engines

The RealNetworks, Inc. RealProxy product is licensed software. To activate the licensed RealProxy feature on a standalone Content Engine, you must have a RealProxy license key. For more information about the RealProxy license, see the "About the RealProxy License Key" section.

Before enabling licenses for streaming media services on a Content Engine, make sure that your Content Engine clock and calendar settings are correct; otherwise, you will see an error message and the services will fail to install. Use the show clock EXEC command to display the system clock. To set the system clock, use the clock set EXEC command.

To use the Content Engine CLI to enable the licensed RealProxy feature on a standalone Content Engine, follow these steps:

Step 1 Enter the show rtsp proxy media-real license-agreement EXEC command to view the RealProxy license agreement.
ContentEngine# show rtsp proxy media-real license-agreement
Step 2 After reading the license agreement, enter global configuration mode and accept the license agreement.
ContentEngine# configure terminal
ContentEngine(config)# rtsp proxy media-real accept-license-agreement
Step 3 Enter your Cisco license key for the licensed RealProxy feature.
ContentEngine(config)# rtsp proxy media-real license-key licensekey
Alternatively, accept an evaluation RealProxy license by specifying the rtsp proxy media-real evaluate global configuration command.
ContentEngine(config)# rtsp proxy media-real evaluate
Step 4 Turn on the licensed RealProxy feature on this Content Engine with the rtsp proxy media-real enable global configuration command.
ContentEngine(config)# rtsp proxy media-real enable
Note For information about uninstalling the RealProxy license on standalone Content Engines, see the "Uninstalling the RealProxy License Key" section.

The next step is to specify the RTSP gateway settings, if necessary. Because the RTSP gateway is automatically enabled on the Content Engine with a default configuration (see Table 8-4), you only need to change the default RTSP gateway settings in the following situations:

•If the Content Engine is behind a NAT-enabled router, you must specify the IP address of the RTSP gateway. By default, there is no IP address specified for the RTSP gateway.

•If you want to change any of the default settings, including the port that the RTSP gateway is to listen on for incoming requests (port 554 is the default).

For information about how to change the default RTSP gateway settings, see the "Configuring the RTSP Gateway for Standalone Content Engines" section.

Otherwise, the next step is to configure one or more of the following routing methods to direct content requests from RealMedia players to this standalone Content Engine:

•Direct proxy routing (nontransparent)

With direct proxy routing, the RealMedia players send their requests directly to this Content Engine (nontransparent forward proxy server). For instructions on how to configure a RealMedia player on the end user desktops to point directly to this Content Engine as its proxy server, see the "Pointing RealMedia Players Directly to a Standalone Content Engine" section.

•WCCP routing or Layer 4 switch (RTSP transparent redirection)

By default, Layer 4 switching is not enabled and WCCP transparent redirection is not configured on the RTSP gateway. (See Table 8-4.) To enable transparent redirection of RTSP requests through Layer 4 switching or WCCP Version 2, complete the process described in the "Configuring RTSP Transparent Redirection and RealProxy Transparent Caching" section.

Configuring the RTSP Gateway for Standalone Content Engines

The RTSP gateway is a process that runs on the Content Engine. The RTSP gateway accepts an RTSP request and performs the initial RTSP handshake with RTSP-based clients (for example, RealMedia clients) on behalf of the backend RTSP servers (for example, the RealProxy server) that are running on the Content Engine.

After successful completion of uniformity checks, the RTSP gateway tunnels the request to the appropriate backend RTSP server that is running on the Content Engine. The RTSP gateway can tunnel the request to RealProxy, RealSubscriber, or the Cisco Streaming Engine on the Content Engine, depending on the requested media type, the backend RTSP servers that is currently enabled on the Content Engine, and the media player that is requesting the content.

Note For standalone Content Engines, RealProxy is the only backend RTSP server that can be enabled on the Content Engine. For Content Engines that are registered with a Content Distribution Manager, you can also enable RealSubscriber and Cisco Streaming Engine as backend RTSP servers that run on the Content Engine.

After the RTSP gateway tunnels the request to a particular backend RTSP server that is running on the Content Engine and the backend server and the client negotiate the UDP ports, the RTSP gateway continues with RTSP message passing (SETUP). When the RTSP client issues a PLAY request, the streaming server starts streaming the data to the client over UDP.

Based on the properties of the incoming request, including such properties as user agent, final destination, and media file type, the RTSP gateway performs the following tasks with standalone Content Engines.

•Forwards the incoming request to the appropriate backend RTSP server (the RealProxy server) that is running on the Content Engine

•Redirects the incoming request

•Rejects the incoming request

If the Content Engine is registered with a Content Distribution Manager, the RTSP gateway also redirects the incoming requests to other content distributors (for example, RealSubscriber or Cisco Streaming Engine) that are configured on the Content Engine.

Network Address Translation (NAT) is designed for IP address simplification and conservation because it enables private IP internetworks that use nonregistered IP addresses to connect to the Internet. NAT operates on a router, usually connecting two networks together, and translates the private addresses in the internal network into legal addresses before packets are forwarded onto another network. As part of this functionality, NAT can be configured to advertise only one address for the entire network to the outside world. This provides additional security, effectively hiding the entire internal network from the world behind that address. NAT has the dual functionality of security and address conservation, and is typically implemented in remote access environments.

Note If the Content Engine is behind a NAT-enabled router, you must specify the IP address of the RTSP gateway that is running on the Content Engine. By default, no IP address is specified.

Default RTSP Gateway Settings

The RTSP gateway is automatically enabled on the Content Engine, and cannot be disabled with a command. Table 8-4 lists the default settings for the RTSP gateway.

Table 8-4 Default Settings for the RTSP Gateway

RTSP Gateway Setting

Default Setting

IP address of RTSP gateway

Not specified

Incoming RTSP port

Port 554

Incoming RTSP request rate

40 requests per second

Layer 4 switching

Not enabled

WCCP transparent interception

Not configured

Maximum initial setup delay

10 seconds

Maximum request rate

40 requests per second

Configuring Basic Settings for the RTSP Gateway

By default, the RTSP gateway is always enabled on a Content Engine, and cannot be disabled by entering a CLI command. As Table 8-4 shows, the RTSP gateway has a set of default settings. You only need to change these default settings under the following conditions:

•You want to configure the RTSP gateway to listen for incoming RTSP requests on a port other than the default port (port 554).

•The Content Engine is behind a NAT-enabled router. In this case, you must specify the IP address of the RTSP gateway. By default, an IP address for the RTSP gateway is not specified.

To configure the basic settings for the RTSP gateway on a standalone Content Engine, use the rtsp global configuration commands.

rtsp {ip-address rtsp-gateway-ip-address | L4-switch enable | port incoming port} command.

Table 8-5 describes the command parameters.

Table 8-5 Parameters for the rtsp Command

Parameter

Description

ip-address

Configures the IP address of the RTPS gateway.

rtsp-gateway-
ip-address

IP address of the RTSP gateway that is running on the Content Engine. By default, no IP address is specified.

L4-switch

Configures Layer 4 switch interoperability with RTSP.

enable

Enables Layer 4 switch interoperability with RTSP.

port

Configures the RTSP gateway port.

incoming

Configures the port on which the RTSP gateway listens for incoming RTSP requests.

port

Port number on which the RTSP gateway is to listen for incoming RTSP requests. You can specify a single incoming port number. The port number can be from 1 to 65535. The default is port 554.

To configure the basic RTSP gateway parameters on a standalone Content Engine, follow these steps:

Step 1 Enter the rtsp port incoming port-number global configuration command to specify the incoming port (the port on which the RTSP gateway is to listen for incoming RTSP requests).
ContentEngine(config)# rtsp port incoming port-number
Step 2 Enter the rtsp ip-address ip-address global configuration command to specify the IP address of the RTSP gateway.
ContentEngine(config)# rtsp ip-address rtsp-gateway-ip-address
Step 3 Configure transparent redirection of RTSP requests through WCCP Version 2 or Layer 4 switching.

For more information, see the "Configuring RTSP Transparent Redirection and RealProxy Transparent Caching" section.

Configuring Advanced Options for the RTSP Gateway

If the Content Engine is running ACNS software, Release 5.2 or later, you can use the rtsp advanced global configuration command to configure the following three advanced options for the RTSP gateway:

•Bypass gateway

•Maximum initial setup delay

•Maximum request rate

rtsp advanced {bypass-gateway media-real | max-initial-setup-delay time_delay |
max-request-rate number}

Table 8-6 describes the command parameters.

Table 8-6 Parameters for the rtsp advanced CLI Command

Parameter

Description

advanced

Configures the advanced options for the RTSP gateway that is running on the Content Engine.

bypass-gateway

Sets the bypass gateway feature that enables the specified types of RTSP requests (for example, RealMedia requests) to bypass the RTSP gateway.

media-real

Specifies that the RTSP gateway is to bypass RealProxy requests. Because RealProxy is the only RTSP-based back end server that can be enabled on a standalone Content Engine, this option is the only bypass-gateway option that is valid for standalone Content Engines. However, if the Content Engine is registered with a Content Distribution Manager, you can specify the following additional options for Content Engines because the Cisco Streaming Engine and RealSubscriber are supported as RTSP-based backend servers: the bypass-gateway cisco-streaming-engine option and the bypass-gateway real-subscriber option.

max-initial-setup-
delay

Sets the maximum delay that is allowed between the TCP accept and the first RTSP message from the client. The unit of measurement is seconds. The default is 10 seconds.

time_delay

Maximum time delay allowed in seconds (0-2147483647). The default value is 10 seconds.

max-request-
rate

Sets the maximum number of incoming requests per second that the RTSP gateway allows.

number

Maximum number of incoming requests per second that the RTSP gateway allows. The default value is 40 requests per second.

Configuring RTSP Transparent Redirection and RealProxy Transparent Caching

If transparent redirection through WCCP Version 2 or Layer 4 switching is being used to direct content requests from RealMedia clients to a standalone Content Engine, you can configure the Content Engine to support RealMedia transparent caching for VOD files. In this case, the standalone Content Engine is acting as a transparent proxy server for the end users who are using RealMedia players to request streaming media content. After receiving a transparently redirected RTSP request, the Content Engine retrieves the requested content from the origin streaming server if it is not already stored in its local cache, stores a copy locally whenever possible (VOD files can be cached but not live streams), and sends the requested content to the requester (RealMedia player).

The Content Engine listens for redirected RTSP requests on the standard RTSP port (default port 554). To intercept RTSP traffic on multiple ports, you must configure a dynamic WCCP service (services 90 to 97). For information about configuring a dynamic WCCP service, see the "Configuring Standalone Content Engines to Support User-Defined WCCP Services" section.

With RTSP transparent redirection, a Layer 4 switch or WCCP Version 2-enabled router redirects RTSP requests to the Content Engine (acting as a transparent proxy server). RTSP transparent redirection is used to support RealMedia transparent caching on a standalone Content Engine.

To enable transparent redirection of RTSP requests through Layer 4 switching, enter the rtsp L4-switch enable global configuration command. After you enter the command, a message appears indicating that Layer 4 switching for RTSP has been enabled on the Content Engine:
ContentEngine(config)# rtsp L4-switch enable
Turn on l4 switch
To configure RTSP transparent redirection through WCCP Version 2, you must perform these tasks:

•Configure RTSP redirection on the WCCP Version 2 routers that will support this RTSP streaming service.

•Configure RTSP redirection on the standalone Content Engine that will be receiving these transparently redirected RTSP requests.

The RTSP redirection service (service 80) is a WCCP Version 2 standard media caching service. This service permits WCCP Version 2-enabled routers to redirect RTSP client requests transparently to a single port (port 554) on a Content Engine. After receiving a redirected RTSP request, the Content Engines checks if whether it has a cached copy of the requested content. If it has, the Content Engine sends the RealMedia client the requested content. Otherwise, the Content Engine retrieves the requested content from the origin streaming server, caches a copy locally if RealMedia transparent caching is enabled on the Content Engine, and sends the client the requested content.

Note To configure RTSP transparent redirection on multiple ports, you must configure a user-defined WCCP service (services 90 to 97) on the WCCP Version 2-enabled routers and the Content Engine. For more information about configuring such WCCP services, see the "Configuring Standalone Content Engines to Support User-Defined WCCP Services" section.

The following scenario shows how to configure the WCCP Version 2 RTSP redirection service (service 80) on a standalone Content Engine and a router with WCCP Version 2, and enable RealProxy transparent caching on the Content Engine. This scenario assumes that you have enabled the licensed RealProxy feature on the standalone Content Engine, as described in the "Enabling RealProxy on Standalone Content Engines" section.

To configure RTSP transparent redirection (the rtsp service [service 80]) and RealProxy transparent caching for standalone Content Engines, follow these steps:

Step 1 Turn on WCCP Version 2 on the router. (WCCP Version 1 does not support the RTSP redirection service [service 80].)
Router# configure terminal
Router(config)# ip wccp version 2
Step 2 Turn on the RTSP redirection service (service 80) on the WCCP Version 2-enabled router.
Router(config)# ip wccp 80
Step 3 Specify the interface on which the RTSP redirection service will run.
Router(config)# interface type number
The following shows how to configure the router to run the RTSP redirection service on the Fast Ethernet interface.
Router(config)# interface fastEthernet 0/0
Step 4 Configure the router to use the outbound interface for the RTSP redirection service.
Router(config-if)# ip wccp 80 redirect out
Note Although typical router configuration in a branch office scenario involves configuring the outgoing interface, you can also configure the incoming interface on the router for traffic redirection (using the ip wccp service number redirect in interface configuration command) if the router supports the redirection in feature.
Step 5 End the configuration session on the router.
Router(config-if)# end
Step 6 Enable RTSP redirection through WCCP on the standalone Content Engine. This is the Content Engine that will act as the transparent proxy server for redirected RTSP requests from these WCCP Version 2-enabled routers.

a. Create the numbered router list that you want to associate with the RTSP redirection service (service 80).

In the following example, there is a single WCCP Version 2-enabled router associated with router list 1. This router has an IP address of 10.1.3.1.
ContentEngine(config)# wccp router-list 1 10.1.3.1
b. Enable the router list (router list 1) that you just created in the previous step (Step a.).
ContentEngine(config)# wccp rtsp router-list-num 1
WCCP configuration for RTSP succeeded. Please remember to configure WCCP service 80 on 
the corresponding router.
You have already configured the RTSP redirection service (service 80) on the corresponding router (the router with an IP address of 10.1.1.1) in Step 2 through Step 5 of this procedure.

c. Enable WCCP Version 2 on the Content Engine that will accept redirected RTSP requests from the WCCP Version 2-enabled routers that are listed in router list 1.
ContentEngine(config)# wccp version 2
Step 7 If transaction logging is not currently enabled on the Content Engine, enable it.
ContentEngine(config)# transaction-log enable
Step 8 Save the new configuration on the Content Engine.
ContentEngine# copy running-config startup-config
Step 9 Enter the show wccp services EXEC command to display the list of WCCP services that are currently configured on Content Engine A. Check whether the RTSP redirection service (service 80) is listed.

The partial sample output that is shown below indicates that this WCCP service is now enabled on the Content Engine, along with the FTP service and the web-cache service. For a descriptive list of the supported WCCP services, see Table B-3.
ContentEngineA# show wccp services
Services configured on this Content Engine
        Web Cache
        RTSP
        FTP
ContentEngine#
Step 10 Enter the show rtsp EXEC command to verify that WCCP transparent redirection is now enabled on the Content Engine.
ContentEngine# show rtsp
Step 11 If necessary, specify the RTSP gateway settings.

a. If the Content Engine is behind a NAT-enabled router, you must specify the IP address of the RTSP gateway (required).

b. You can also change the default basic and advanced RTSP gateway settings (if you wish).

For more information, see the "Configuring the RTSP Gateway for Standalone Content Engines" section.

Step 12 After configuring the routers and Content Engine to support RTSP redirection through WCCP Version 2, you can configure RealMedia transparent caching on the Content Engine.

a. If you have not enabled the RealProxy product feature on the Content Engine, enter the rtsp proxy media-real enable global configuration command.
ContentEngine(config)# rtsp proxy media-real enable
b. Use the RealSystem administrator GUI to configure RealProxy (for example, for live splitting). For more information, see the "Configuring RealProxy with the RealSystem Administrator GUI" section.

For an example of how to verify whether RealMedia transparent caching is working properly for standalone Content Engines, see the "Scenario 1—Verifying the Configuration for RealMedia VOD Caching" section.

Configuring Direct Proxy Routing and RealMedia Proxy Caching

If direct proxy routing is being used to direct content requests from RealMedia players directly to the standalone Content Engine, then you can configure the Content Engine to support RealMedia proxy caching for VOD files. With RealMedia proxy caching, the standalone Content Engine is functioning as a nontransparent proxy server for the RealMedia players. After receiving a content request directly from a RealMedia player (for example, a RealPlayer or RealOne player), the Content Engine retrieves the requested VOD file from the origin streaming server if it is not already stored in its local cache, stores a copy locally, and sends the requested streaming media content to the RealMedia player.

The following scenario assumes that you have enabled the licensed RealProxy feature on the standalone Content Engine, as described in the "Enabling RealProxy on Standalone Content Engines" section.

To use the Content Engine CLI to configure RealMedia proxy caching on a standalone Content Engine, follow these steps:

Step 1 Configure the RealMedia players to send their requests directly to this Content Engine.

By default, the RTSP gateway on the Content Engine listens for incoming RTSP requests on port 554. If you entered the rtsp port incoming port-number global configuration command to specify another port as the incoming RTSP port (for instance, you configured the RTSP gateway to listen on port 575 instead of port 554), you must configure the RealMedia players to send their requests directly to the configured RTSP incoming port. For more information, see the "Pointing RealMedia Players Directly to a Standalone Content Engine" section.

Note If a firewall is positioned between a Content Engine and a requesting client, make sure that you specify the external IP address of the Content Engine as the proxy server when you configure the RealMedia proxy settings on client desktops. See the "Pointing RealMedia Players Directly to a Standalone Content Engine" section.

Step 2 Use the RealSystem administrator GUI to configure RealProxy (for example, for live splitting) on the Content Engine.

For more information, see the next section, "Configuring RealProxy with the RealSystem Administrator GUI."

Configuring RealProxy with the RealSystem Administrator GUI

RealProxy is a licensed product from RealNetworks, Inc. You use the Setup utility or the Content Engine CLI to enable the licensed RealProxy feature on a standalone Content Engine. You can also use the Setup utility or the Content Engine CLI to enable RealMedia proxy caching and RealMedia transparent caching on a standalone Content Engine after RealProxy has been enabled on the Content Engine. However, you perform RealProxy configuration through the RealNetworks RealSystem administrator GUI.

To access the RealSystem administrator GUI, follow these steps:

Step 1 From the Content Engine GUI, choose Caching > Real Proxy. The Content Engine RealProxy window appears. (See Figure 8-3.)

Note To access the Content Engine GUI, enter the Content Engine IP address in secure mode and append the default port number 8003 as the URL address in your browser of choice. For example, enter https://ContentEngineIPaddress:8003 as the URL.

Figure 8-3 Content Engine RealProxy WIndow

Note The ADMIN button only appears in the Content Engine RealProxy window if the RealProxy software has been installed and enabled on the Content Engine.

Step 2 In the Content Engine RealProxy window, click the ADMIN button.

Step 3 Use admin as the default username and diamond as the password to access the RealSystem administration GUI from the Content Engine RealProxy window. The main window for the RealSystem administrator GUI (see Figure 8-4) appears.

Figure 8-4 RealSystem Administrator GUI

Step 4 Use the RealSystem administrator GUI to configure the licensed RealProxy feature on this Content Engine. For example, use this GUI to configure RealProxy live splitting and caching of VOD files.

After configuring RealProxy, you should verify that the RealProxy configuration is working properly. For some examples of how to verify the RealProxy configurations for live splitting and VOD caching, see the next section, "Verifying RealProxy Configurations for Standalone Content Engines."

Verifying RealProxy Configurations for Standalone Content Engines

This section provides two sample scenarios of how to verify the configuration of RealProxy on standalone Content Engines:

•Scenario 1—Verifying the Configuration for RealMedia VOD Caching

•Scenario 2—Verifying the Configuration for RealProxy Live Splitting

Scenario 1—Verifying the Configuration for RealMedia VOD Caching

This sample scenario shows how to verify the configuration of the RealMedia transparent caching service on a standalone Content Engine. This scenario assumes the following:

•RealProxy has been enabled on the Content Engine. (See the "Enabling RealProxy on Standalone Content Engines" section.)

•There is a single standalone Content Engine (Content Engine A) that has WCCP Version 2 enabled on it.

•There is a single WCCP Version 2-enabled router (Router A) that is configured to redirect content requests from RealMedia players to Content Engine A (transparent proxy server).

•The RealMedia transparent caching service is enabled on Content Engine A, and Content Engine A is configured to accept redirected RTSP requests from Router A.

•The RealMedia players (in this case, RealPlayer) on Client A and Client B are not configured to point directly to Content Engine A.

•Client A and Client B are on the same subnet.

Verify that the RealMedia transparent caching service (RealMedia transparent caching through WCCP Version 2) is working properly, as follows:

Step 1 From the Client A desktop, use RealPlayer to request a RealMedia streaming video file (.rm file).

a. From the RealPlayer menu, choose File > Open URL.

b. Specify a URL that points to a RealMedia streaming video file (for example, rtsp://origin-streaming-server-ip-address/gm1_real_02_00500.rm).

Note Request the video file more than once. The origin streaming server from which you are requesting content (for example, the .rm video files) must be on a different subnet than Client A and Client B, so that the RealPlayer requests from these client desktops are routed to Router A.

The requested video file should start playing in RealPlayer on Client A.

Step 2 Check the statistics on RealPlayer.

a. From RealPlayer, choose Tools > Playback Statistics.

b. In RealPlayer, click the Streams tab to bring it to the front.

c. In the Streams tab, check whether UDP is shown as the transport protocol that is being used. If UDP is shown as the transport protocol, this indicates that the stream is being delivered to RealPlayer in a streaming fashion instead of reverting to HTTP when the streaming proxy or server is not available.

Step 3 From the Client A desktop, use RealPlayer to replay the same streaming video file that you just requested.

Step 4 Check the number of redirected RTSP packets on the WCCP-enabled router. Sample output is shown below.
Router# show ip wccp 80
Global WCCP information:
    Router information:
        Router Identifier:                   10.1.3.1
        Protocol Version:                    2.0
    Service Identifier: 80
        Number of Cache Engines:             1
        Number of routers:                   1
        Total Packets Redirected:            6
        Redirect access-list:                -none-
        Total Packets Denied Redirect:       0
        Total Packets Unassigned:            0
        Group access-list:                   -none-
        Total Messages Denied to Group:      0
        Total Authentication failures:       0
Step 5 Check the RealMedia caching statistics on the Content Engine.

a. From Content Engine A, enter the show statistics rtsp proxy media-real savings EXEC command to display the RealMedia caching saving statistics for this Content Engine.
ContentEngine# show statistics rtsp proxy media-real savings
             Media Cache Statistics - Savings
                        Requests                          Bytes
         -----------------------------------------------------------
  Total:                      17                       16666028
   Hits:                      11                        3656524
   Miss:                       6                       13009504
Savings:                    64.7 %                         21.9 %
b. From Content Engine A, enter the show statistics rtsp proxy media-real requests EXEC command to display the number of RealMedia requests that this Content Engine has received. See the sample output below. Verify that the Content Engine is processing RealMedia requests.
ContentEngine# show statistics rtsp proxy media-real requests
                  Media Cache Statistics - Requests
                                                Total             % of Requests
                            ---------------------------------------------------
     Total Received Requests:                      17                         -
            Demand Cache Hit:                      11                      64.7
           Demand Cache Miss:                       6                      35.3
         Demand Pass-Through:                       0                       0.0
                  Live Split:                       0                       0.0
           Live Pass-Through:                       0                       0.0
Step 6 From the Client B desktop, use RealPlayer to request the same video file that you requested earlier from the Client A desktop.

This will allow you to check whether Content Engine A is storing a copy of the requested VOD in its local cache instead of retrieving the video file again from the origin streaming server.

•The number of cache hits displayed in the output of the show statistics rtsp proxy media-real savings command should increase as you use RealPlayer on Client B to request the same video file that you just requested from RealPlayer on Client A.

•The number of RealMedia requests displayed in the output of the show statistics rtsp proxy media-real requests command should increase as you use RealPlayer on Client B to request the same VOD file that you just requested from Client A.

Step 7 On Router A, open a console or Telnet session.

Step 8 On Router A, enter the show ip wccp 80 EXEC command to display statistics and status information for the rtsp service (service 80) for Router A.

The statistics should show a number greater than 0 for packets redirected.

Step 9 Verify that packets are being redirected to Content Engine A from Router A.

•If Router A shows that there are packets being redirected to Content Engine A, then RealMedia transparent caching (transparent redirection of RTSP requests through WCCP transparent redirection) is operating properly on Content Engine A and Router A.

•If Router A shows that no packets are being redirected to Content Engine A, then RealMedia transparent caching is not operating properly. In this case, you should troubleshoot the problems with your configuration of the rtsp service. The following are some examples of how to do this.

–From Content Engine A, enter the show wccp services EXEC command to display the list of WCCP services that are currently configured on Content Engine A. Verify that the rtsp service (service 80) is listed. Partial sample output is shown below.
ContentEngineA# show wccp services
Services configured on this Content Engine
        Web Cache
        RTSP
        FTP
ContentEngine#
–From Content Engine A, enter the show wccp routers EXEC command to display a list of WCCP-enabled routers that recognize Content Engine A. Check the command output to determine if Router A is on the list of WCCP-enabled routers that recognizes Content Engine A. Partial sample output is shown below.
ContentEngineA# show wccp routers
Routers Seeing this Content Engine
                Router Id          Sent To
                10.0.0.0         10.1.1.1
        Routers not Seeing this Cache Engine
                10.1.1.1
        Routers Notified of but not Configured
                -NONE-
–From Content Engine A, enter the show wccp gre EXEC command to display WCCP generic routing encapsulation (GRE) packet-related information for Content Engine A. Check the command output to view the number of redirected packets that Content Engine A has rejected and accepted. Verify that the number of accepted packets is increasing as you continue to request VOD files that are on streaming servers that are on different subnets than the requesting client (RealPlayer on the Client A and B desktops).
ContentEngineA# show wccp gre
Step 10 You can also use the RealSystem administrator GUI to monitor RealProxy statistics when RealMedia clients are connected.

a. From the Content Engine GUI, choose Caching > Real Proxy. The Content Engine RealProxy window appears. (See Figure 8-3.)

b. Click the Admin button.

c. When asked, enter the username and password. The default username is admin. The default password is diamond. After entering a valid username and password, the RealSystem Administrator main window appears. (See Figure 8-4.)

d. Use the RealSystem Administrator GUI to monitor RealProxy statistics for the RealMedia requests that are being serviced by RealProxy on this Content Engine.

Step 11 By default, transaction logging is enabled on the Content Engine. Verify that the RealMedia transactions that are being serviced by this Content Engine are being tracked in the RealProxy transaction log.
ContentEngine# type-tail /local1/logs/real-proxy/rproxy-transaction-log-filename
Depending upon where the sysfs is mounted, RealProxy logs are logged to a working log on the local disk in one of these files:

•/local1/logs/real-proxy/working.log

•/local2/logs/real-proxy/working.log

You can specify the interval at which the working log should be cleared by moving the data to an archive log. The archive log files are located on the local disk in the /local1/logs/ or /local2/logs/ directory depending upon where the sysfs is mounted.

Because multiple archive files are saved, the filename includes the time stamp when the file was archived. Because the files can be exported to an FTP/SFTP server, the filename also contains the IP address of this Content Engine. For more information about using transaction logs, see the "Using ACNS Software Transaction Logs" section.

Step 12 Check the system log file for RealProxy error messages.

RealProxy generates error messages and writes them to the RealProxy log file. These error messages are captured by ACNS software and passed to the system log file. To view the syslog, enter the following command:
ContentEngine# type-tail syslog.txt
See Table 20-17 for correspondence between the RealProxy error codes and corresponding syslog 
priority levels. For more information about system logging, see the "Using the System Logging 
Feature" section.
Scenario 2—Verifying the Configuration for RealProxy Live Splitting

This sample scenario shows how to verify the configuration for RealProxy live splitting (live splitting through RealProxy and a WCCP Version 2-enabled router) on a standalone Content Engine. When RealProxy is enabled on a standalone Content Engine, the Content Engine serves as the stream splitting point for all local users (RealMedia players) whose RealMedia traffic is directed to the Content Engine. All further requests to that origin streaming server are served by the Content Engine, which splits the stream and serves it to the RealMedia clients. Live broadcasts (live streams) are not files and therefore cannot be cached. For more background information about RealProxy live splitting, see the "About Live Splitting and Caching VOD Files with RealProxy" section.

In this scenario, the RealMedia players on the Client A, B, and C desktops are configured to point to a live stream that is set up to play continuously. WCCP Version 2 is used to redirect the request for this live stream to the Content Engine. A WCCP Version 2-enabled router transparently intercepts the request for the live stream, and redirects the request to the Content Engine (Content Engine A) that is running RealProxy.

This scenario assumes the following:

•RealProxy is enabled on Content Engine A. (See the "Enabling RealProxy on Standalone Content Engines" section.)

•WCCP Version 2 is also enabled on Content Engine A.

•There is a single WCCP Version 2-enabled router (Router A) that is configured to redirect content requests from RealMedia players to Content Engine A (transparent proxy server).

•The RealMedia players (in this case, RealPlayer) on Clients A, B, and C are not configured to point directly to Content Engine A.

•Clients A, B, and C are on the same subnet.

Verify that RealProxy live splitting is working properly, as follows:

Step 1 Create a live stream on an origin streaming server (a Helix Universal Server) that supports the RealNetworks proprietary RTSP protocol.

Use either an encoder or the Simulated Live Transfer Agent (SLTA) tool.

SLTA is a Helix Universal Server utility to stream a prerecorded clip as if it were a live event.

The origin streaming server (Helix Universal Server) on which you are creating the live stream should be on a different subnet from that of Clients A, B, and C so that the RealMedia requests from these clients are routed to Router A.

Step 2 From the Client A desktop, use RealPlayer to request the live stream (live event).

a. From the RealPlayer menu, choose File > Open URL.

b. Specify a live event alias (for example, rtsp://origin-streaming-server-ip-address/broadcast/live).

The requested live event should start playing in RealPlayer on Client A.

Step 3 From the Client B and Client C desktops, use RealPlayer to request the same live stream that you requested earlier with RealPlayer on the Client A desktop.

Step 4 Use the same verification process that is described in the "Scenario 1—Verifying the Configuration for RealMedia VOD Caching" section to verify the following:

•The WCCP-enabled router (Router A) is redirecting the RealPlayer requests for live streams to the Content Engine A.

•Content Engine A is serving the live streams with bandwidth savings to Client A and Client B.

•Transactions related to these live streams (for example, which clients are viewing this particular live event, and the length of time that the client viewed this live event) are being logged in the RealProxy transaction log on Content Engine A.

For example:

a. Open a console or Telnet session on Router A. On Router A, enter the show ip wccp 80 EXEC command to display statistics and status information for the RTSP redirection service (service 80) for Router A. The statistics should show a number greater than 0 for packets redirected.

b. From Content Engine A, enter the show statistics rtsp proxy media-real requests EXEC command to display the number of RealMedia requests that Content Engine A has received. The statistic should show a number greater than 0 for live split requests.

Restoring the Default RealProxy Configuration on Standalone Content Engines

On standalone Content Engines, RealProxy is enabled through the Content Engine CLI or through the Setup utility. To change the RealProxy default configuration, you must use the RealNetworks RealSystem administrator GUI, which you can access from the Content Engine GUI. However, you can use the Content Engine CLI to restore the RealProxy default configuration file on a standalone Content Engine.

To restore the RealProxy default configuration on a standalone Content Engine, follow these steps:

Step 1 Enter the rtsp real-proxy default-configuration EXEC command, and enter yes when asked if you want to proceed (see below).
ContentEngine# rtsp real-proxy default-configuration
User would lose the current real proxy configuration. Do you want to proceed? [yes/no] yes
Restart Real Proxy to load the restored configuration file.
Step 2 Restart RealProxy on the Content Engine to load the restored configuration file.
For more information, see the "Restarting RealProxy on Standalone Content Engines" section.
Note For information on how to access the RealSystem administrator GUI from the Content Engine GUI, see the "Configuring RealProxy with the RealSystem Administrator GUI" section.

Restarting RealProxy on Standalone Content Engines

To restart RealProxy on a standalone Content Engine, follow these steps:

Step 1 Stop RealProxy on the Content Engine.
ContentEngine(config)# no rtsp proxy media-real enable
Step 2 Restart RealProxy on the Content Engine.
ContentEngine(config)# rtsp proxy media-real enable
Disabling RealMedia Caching on Standalone Content Engines

To disable RealMedia caching on a standalone Content Engine, follow these steps:

Step 1 Access the RealSystem Administrator GUI window by clicking the Admin button in the RealProxy window of the Content Engine GUI. (See Figure 8-3.) (You must enable the RealProxy before you can access the Admin button in this window.)

Note The administrator, usernames, and all associated passwords configured on the Content Engine are not the same as the ones contained in the RealProxy authentication database. Therefore, not all Content Engine users have access to the RealSystem Administrator GUI.

Step 2 Choose Configure > Cache.

Step 3 In the Enable Caching field, choose No.

Step 4 Click Apply.

Step 5 Stop RealProxy on the Content Engine.
ContentEngine(config)# no rtsp proxy media-real enable
Step 6 Restart RealProxy on the Content Engine.
ContentEngine(config)# rtsp proxy media-real enable
Uninstalling the RealProxy License Key

If the RealProxy license key is no longer needed on the Content Engine because the licensed RealProxy feature is not needed, you can uninstall the RealProxy license key by entering the no rtsp rpoxy media-real license-key global configuration command. After a license key is uninstalled on one Content Engine, it can be used on another Content Engine if that Content Engine supports the licensed RealProxy feature.

Note The licensed RealProxy feature must be disabled using the no rtsp proxy media-real enable command before uninstalling the RealProxy license key on a standalone Content Engine.

Displaying RealProxy Statistics for Standalone Content Engines

You can use the show statistics rtsp proxy media-real EXEC commands to display RealProxy statistics for standalone Content Engines. The displayed statistics relate only to objects transported over RTSP that were requested by a RealMedia client. Objects transported over HTTP are counted in the HTTP statistics. Streaming objects requested by other clients or transported over protocols other than MMS bypass the Content Engine.
ContentEngine# show statistics rtsp proxy media-real requests
                  Media Cache Statistics - Requests
                                                Total             % of Requests
                            ---------------------------------------------------
     Total Received Requests:                       0                         -
            Demand Cache Hit:                       0                       0.0
           Demand Cache Miss:                       0                       0.0
         Demand Pass-Through:                       0                       0.0
                  Live Split:                       0                       0.0
           Live Pass-Through:                       0                       0.0
ContentEngine# show statistics rtsp proxy media-real savings
             Media Cache Statistics - Savings
                        Requests                          Bytes
         -----------------------------------------------------------
  Total:                       0                              0
   Hits:                       0                              0
   Miss:                       0                              0
Savings:                     0.0 %                          0.0 %
You can also obtain detailed configuration, statistics, and reporting of RealProxy status through the RealNetworks RealSystems administrator GUI. The Content Engine GUI has a RealProxy window (Figure 8-3). The ADMIN button is active in the Content Engine Management GUI when RealProxy is installed and enabled on the Content Engine. You will be provided with a default username and password to access this administrator window from the Content Engine GUI. For more information, see the "Configuring RealProxy with the RealSystem Administrator GUI" section.