Cisco ACNS Software Caching Configuration Guide, Release 4.2 - Chapter 4: Streaming Media Overview Parameter Settings [Cisco Application and Content Networking System (ACNS) Software]

Table Of Contents

Streaming Media Overview

Understanding Streaming Media Caching

Using the Windows Media Technologies Streaming Solution

WMT Caching Proxy Details

Caching

Variable Bit Rate

Live Splitting

Proxy Authentication

Windows NTLM Authentication

Miscellaneous Features

WMT Incoming Port

Maximum Number of Concurrent Unicast Clients

Maximum Aggregate Bandwidth

Transaction Logging

Error Logging

Statistics

WMT Requirements

Using the RealProxy Streaming Solution

Configuring RealProxy Software

Statistics

Streaming Media Overview

This chapter describes how Windows Media Technology and RealProxy streaming media are supported on the Content Engine. This chapter contains the following sections:

•Understanding Streaming Media Caching

•Using the Windows Media Technologies Streaming Solution

•Using the RealProxy Streaming Solution

Understanding Streaming Media Caching

Streaming media files are files that are sent to the user and played on the user's media player as the files are received from the network. Streaming media files avoid a waiting period for viewing these files because they are immediately available as a continuous stream of data packets. (See Figure 4-1.) This eliminates the need to store large media files for viewing purposes or the need to allocate storage space for these files before playing them.

Figure 4-1 Streaming Media Model with Content Engine as Manual Proxy

In Figure 4-1 both audio and video are being recorded from an event to be distributed later either as video on demand (VOD) or live to a network of users. The encoder software and hardware compress the signal into streamable files, which are then sent to a media file server. This media server in turns delivers the media files on a live or on-demand basis to users with the particular media software on their personal computers or other electronic devices. Note that in this figure the Content Engine is manually configured to be the caching proxy for the users in that particular network.

Table 4-1 lists the different types of streaming media protocols, control channels, the corresponding data format, and transport types supported by ACNS 4.2 software.

Table 4-1 Streaming Media Protocols

Streaming Media Protocol

Control Channel

Data Format

Transport Protocol

Windows Media format

TCP

MMS¹

UDP², TCP, HTTP, IP multicast

RealNetworks media format

TCP

RTSP, PNA³

UDP, TCP, HTTP, IP multicast

¹MMS = Microsoft Media Server.

²UDP = User Datagram Protocol.

³PNA = Progressive Networks Audio.

Using the Windows Media Technologies Streaming Solution

Microsoft Windows Media Technologies (WMT) Version 7.01 is a set of streaming solutions for creating, distributing, and playing back digital media files on the Internet. WMT includes the end user application (Windows Media Player) and the server and distribution application (Windows Media Server). To disseminate live and pre-positioned Windows Media content on a Content Delivery Network (CDN), you need WMT caching proxy and server capabilities on the Content Engine.

This chapter focuses on the WMT caching proxy capabilities of the Content Engine, because the WMT server capabilities are discussed in the Cisco ACNS Software E-CDN Administrator's Guide, Release 4.2.

Note The WMT product is licensed software. To enable the WMT proxy, you must have a license keyword, which is supplied on a certificate shipped with the Content Engine. If you are downloading the ACNS 4.2 software, you can purchase a WMT license though the Cisco.com website.

WMT Caching Proxy Details

The Content Engine acting as a WMT caching proxy supports a basic proxy feature—it accepts incoming WMT streaming requests from clients and acts on behalf of the clients communicating with the origin server. The WMT caching proxy accepts and serves the streaming requests over Microsoft Media Server (MMS) protocol as well as the HTTP protocol. (See Figure 4-2.) MMS is the protocol that WMT uses for communication between players and servers.

When possible, the WMT caching proxy also caches the streaming content and serves the request from the cache instead of the origin server. It accepts transparently intercepted requests (through WCCP or L4 redirect) as well as manual proxy requests (clients configured to use an upstream proxy).

The WMT caching proxy also supports splitting of live streams (that is, it splits a single inbound feed to multiple clients) and multicasting.

Note If a firewall is positioned between a Content Engine acting as a proxy, and a requesting client, make sure that you assign the external IP address of the Content Engine in its configuration.

Figure 4-2 Content Engine as Conventional WMT Caching Proxy

Note For MMS over TCP and UDP, the proxy always fetches the stream from a server using TCP (MMST) so that the item cached is reliable and complete for future delivery. Streams requested using HTTP will be fetched using HTTP.

Caching

Caching frequently accessed content closer to the user provides better-quality streams and saves network bandwidth. When the Content Engine acting as proxy fetches the content from the server to be served to the client, it will store the cacheable stream on the media file system (mediafs). The proxy can cache partial streams. When a client requests a part of the stream that has not been cached, the proxy fetches the missing portions from the origin server. Even when there is a cache hit, a connection is maintained with the origin server in order to report client usage statistics, which can be used for accounting and other purposes by the origin server.

To enable WMT caching on the Content Engine, use the wmt cache enable global configuration command. To set the maximum object size for streaming media objects, use the wmt cache max-obj-size command. The range of values is between 1 and 1,000,000 megabytes. The default value is 1024 megabytes.

Streams served from the cache are guaranteed to be fresh because the Content Engine always checks with the origin server, using the appropriate cache parameter settings. When the storage limit is reached, older objects are replaced using an appropriate replacement algorithm to ensure a proper hit ratio. See the "Cache Freshness" section for more information regarding the appropriate cache parameter settings.

The proxy can cache authenticated streams, and on a cache hit, the authentication credentials of the requesting client are revalidated against the origin server before the content is served.

Caching is supported in nontransparent (manual) proxy as well as transparent proxy modes.

Note Caching of Moving Picture Experts Group Layer-3 audio (MP3), waveform audio (WAV), and Audio Video Interleaved (AVI) files over MMS is supported. Windows Media content fetched by a nonstreaming HTTP server (at the request of a Windows Media Player) is not cached. Live streams are not recorded or cached.

Variable Bit Rate

A content provider can create streaming media files at different bit rates to ensure that different clients who have different connections—for example, modem, DSL, or LAN—can handle a particular bit rate of their choice. The WMT caching proxy can cache multiple bit rate or variable bit rate (VBR) files, and based on the bit rate specified by the client, it serves the appropriate stream. Another advantage of creating variable bit rate files is that a single URL is all that must be specified for the delivery of streaming media.

Use the wmt max-bitrate global configuration command to set the maximum streaming bit rate that can be delivered to a requesting client. The range of values is 0 and 2,147,483,647 kilobits per second. The default value is 0 (no bit rate limit).

Live Splitting

The Content Engine splits requests for live streams. That is, a single stream from the origin streaming server is split to serve each client that requested the stream. (See Figure 4-3.) In the case of the WMT caching-enabled Content Engine acting as proxy, when the client requests a publishing point on a server (without specifying an ASF file), then the Content Engine dynamically creates an alias file that references the remote server. All further requests to that station are served by splitting the stream. Note that when the first client (Client 1) that requested the original stream disconnects from the network, the proxy continues to serve the other clients (Client 2 and Client 3), until all clients disconnect from the network.

Figure 4-3 Live Splitting

Live splitting at the proxy is better than at the server, because the proxy is closer to the clients, thereby potentially saving considerable network bandwidth between the client and the origin server.

Note Live splitting is supported for different data packet transport protocols (HTTP, MMS TCP [MMST], MMS UDP [MMSU], and IP multicast).

Proxy Authentication

The WMT-enabled Content Engine supports both basic and NTLM authentication by the origin server. When a client requests content that needs user authentication, the Content Engine acts as an agent, conveying the authentication information to and from the client and server to authenticate the client. Once the client is authenticated, the content is streamed as usual. The authentication is performed for both cached content as well as noncached VOD content.

In the case of basic authentication, the server requests the client's identification in the form of an encoded username and password. If the authentication fails, the client is informed accordingly, in which case the client retries or disconnects. If the authentication is successful, then the streaming media is served to the client. This is supported in manual as well as transparent proxy mode, over both HTTP and MMS.

Windows NTLM Authentication

Windows NTLM is a connection-based challenge-response authentication scheme. In the basic authentication scheme, the proxy transfers the authentication information to and from the client and server, as if the request were coming from the client, until the client is authenticated. On the other hand, because the NTLM protocol authenticates every connection, the proxy cannot arbitrarily create new connections with the origin server. The proxy must reuse connections initiated by the client. Hence, a file is served from the cache only if it is a complete cache hit; that is, the complete file is present on disk. If the file is not a complete hit, then the entire file is fetched from the origin server in the case of NTLM. This feature is supported in manual as well as transparent proxy mode, over both HTTP and MMS.

The proxy supports caching and delivery of Digital Rights Management (DRM)-protected Windows Media files. Access control lists enforced by the origin server are automatically enforced by the proxy.

Note Filtering based on user identification is also supported. The proxy only supports authentication by the origin server. Proxy authorization, or authentication of the user to use the proxy, will be supported in a future release. Live streams that are split to clients are also authenticated with the origin server in ACNS 4.2 software.

Miscellaneous Features

This section lists features that are supported by the WMT caching proxy in ACNS 4.2 software.

WMT Incoming Port

The default port number used by the WMT feature on the Content Engine is port 1755. However, this port number can range from 1 to 65535.

Maximum Number of Concurrent Unicast Clients

The maximum number of concurrent unicast clients is 2500. The range is from 1 to 2500 unicast clients.

Maximum Aggregate Bandwidth

The maximum aggregate bandwidth that can be served ranges from 1 to 1,000,000 kilobits per second. The actual maximum aggregate bancwidth depends on the Content Engine platform and on the network configuration.

Transaction Logging

The logging format is consistent with that of the Windows Media server and the W3C-compliant log format. A log line is written for every stream accessed by the client. The location of the log is not configurable. These logs can be exported using FTP. All client information in the transaction logs is sent to the origin server by default.

Error Logging

The error log consists of the debugging logs written by the application. Error logs are in the same format and location as syslogs.

Statistics

The WMT proxy needs to maintain key statistics to provide byte savings, number of cache hits and cache misses, number of concurrent streams (according to bandwidth rates), percentage of cache or disk space used, and so forth.

You can view WMT statistics by choosing Reporting > WMT Streaming from the Content Engine GUI. (See Figure 9-1.) You can also use the show statistics wmt all command to view WMT statistics using the CLI. (See the "WMT Examples" section.)

WMT Requirements

Interoperability is the most important requirement for WMT software components. The WMT caching proxy is required to work with all versions of Microsoft Windows Media Player, Windows Media Server, Windows Media Encoder and third-party Windows Media applications.

In order to support transparent mode, you need to have WCCP running on the Content Engine. See the "Enabling Transparent WMT Service Using WCCP-Enabled Routers" section.

Using the RealProxy Streaming Solution

The RealProxy Version 8.01 software from RealNetworks, Inc., included as a software option to ACNS 4.2 software, supports both live splitting (distributing live feeds) and streaming media caching (on-demand content) in the RTSP-based format.

When performing stream splitting, the RealProxy accepts a live stream from a RealServer and re-serves the stream to multiple requesting RealPlayer clients, thus eliminating multiple connections to the RealServer. The RealServer is preconfigured to act as a RealMedia transmitter and the RealProxy is preconfigured to act as a RealMedia receiver.

Note The RealNetworks, Inc. RealProxy product is licensed software. To activate the RealProxy, you must have a license keyword, which is supplied on a certificate shipped with the Content Engine. If you are downloading the ACNS 4.2 software, you can purchase a RealProxy license through the Cisco.com website.

Streaming media caching provides content on demand. If one user has viewed a cached streaming media file, it can be served to subsequent users without the requirement to connect with the origin server. Live broadcasts are not files and are not cached.

Table 4-2 lists the different types of streaming media protocols, control channels, the corresponding data format, and transport types supported by ACNS 4.2 software.

Table 4-2 Streaming Media Protocols

Streaming Media Protocol

Control Channel

Data Format

Transport Protocol

Windows Media format

TCP

MMS¹

UDP², TCP, HTTP, IP multicast

RealNetworks media format

TCP

RTSP, PNA³

UDP, TCP, HTTP, IP multicast

¹MMS = Microsoft Media Server.

²UDP = User Datagram Protocol.

³PNA = Progressive Networks Audio.

Table 4-3 describes the features and benefits of RealProxy software.

Table 4-3 RealProxy Features and Benefits

RealProxy Feature

Description

Benefits

Proxy for RealPlayer 8.01

The RealProxy makes requests for content on behalf of client RealPlayer users.

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

•Masks end user IP addresses.

Splitting support for live broadcasts

The RealProxy "splits" a single inbound live broadcast feed to multiple client RealPlayers. See the "Live Splitting" section of the Configuring Windows Media Technologies Streaming Media Caching chapter for more information on live-splitting.

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

•Improves RealPlayer quality of experience.

Caching of RealSystem G2 and PNA (progressive network Audio) content.

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

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

Authentication/accounting

The RealProxy authenticates every content request with the origin RealNetworks server before delivering the cached content to the client.

•Broadcaster retains access to general usage data.

•Users are appropriately authenticated.

•End users are guaranteed the freshest content.

Aggregate bandwidth thresholds

Setting thresholds caps inbound and outbound bandwidth to the RealProxy.

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

Proxy routing

The 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 network administrators to proxy route requests, providing an additional level of control.

Note For an overview of streaming media technology, see the "Understanding Streaming Media Caching" section. For information on how to enable WMT streaming on the Content Engine, see the "Enabling WMT on the Content Engine" section.

Configuring RealProxy Software

The Content Engine can be configured to accept transparently redirected RTSP requests as well as traditional proxy-style RTSP requests from RealPlayer client software. The redirection of RTSP traffic to the Content Engine media cache is enabled with the Content Engine CLI. The RealProxy software is configured with the RealAdministrator GUI, accessed from the RealProxy page of the Content Engine management GUI.

Detailed configuration, statistics, and reporting of RealProxy status are obtained through the RealAdministrator GUI. Table 4-4 lists RealProxy-related CLI commands.

A RealProxy page has been added to the Content Engine management GUI. See the "Enabling RealProxy on the Content Engine" section. The Admin button is active on the Content Engine Management GUI when the RealProxy software is installed and enabled. You will be provided with a default user and password to access this administration page from the Content Engine GUI.

Note You must configure disk space to include mediafs storage with the disk config command before you can run RTSP traffic through the Content Engine.

Table 4-4 RealProxy-Related CLI Commands

CLI Command

Function

rtsp proxy incoming ports

Specifies the ports on which to listen for RTSP proxy-style requests.

rtsp proxy l4-switch enable

Enables redirection with a Layer 4 switch, such as a Cisco CSS 11000 series switch.

rtsp proxy media-real enable

Enables the RealProxy.

rtsp proxy media-real ip-address ipaddress

Specifies the IP address of the RealProxy.

rtsp proxy media-real license-key keyword

Specifies the license keyword to unlock the RealProxy software.

wccp media-cache . . .

Registers the Content Engine for WCCP RTSP redirection services with the router.

Use the rtsp proxy global configuration command to configure the Content Engine to accept redirected RTSP traffic from either a Layer 4-enabled switch or a WCCP-enabled router, or to configure the Content Engine as a media proxy to receive RTSP proxy-style requests from RealPlayer clients. RTSP requests not from RealPlayer clients are directed to the specified origin server.

The wccp media-cache global configuration command registers the Content Engine with WCCP Version 2-enabled routers that can transparently redirect RTSP traffic to the Content Engine.

The rtsp proxy l4-switch global configuration command enables the configuration of Layer 4 switch interoperability for media caching using RTSP.

The RTSP proxy redirector listens to port 554 traffic or any other port configured to listen to this traffic, and if the player is a RealPlayer, it redirects the RTSP request to use the RealProxy for RealMedia traffic. Traffic that is not supported (for instance, QuickTime) is bypassed by the Content Engine.

Statistics

Use the following CLI commands to display RealProxy statistics. In ACNS 4.2 software, only requests and savings statistics are supported. See the "RealProxy Examples" section for sample outputs of the show statistics command.
ContentEngine# show statistics mediacache real requests
ContentEngine# show statistics mediacache real savings
Note The mediacache real statistics relate only to objects transported over RTSP that were requested by a RealPlayer client. Objects transported over HTTP are counted in the HTTP statistics. Streaming objects requested by other clients or transported over other protocols other than MMS bypass the Content Engine.