-
Cisco ACNS Software Configuration Guide for Locally Managed Deployments, Release 5.2
-
Title
-
Preface
-
Chapter 1: Introduction
-
Chapter 2: Understanding the Basics
-
Chapter 3: Getting Started
-
Chapter 4: Deployment Scenarios for Standalone Content Engines
-
Chapter 5: Configuring Transparent Redirection for Standalone Content Engines
-
Chapter 6: Configuring Conventional Caching Services for Standalone Content Engines
-
Chapter 7: Configuring WMT Streaming Media Services on Standalone Content Engines
-
Chapter 8: Configuring RTSP Media Services on Standalone Content Engines
-
Chapter 9: Configuring Content Authentication and Authorization on Standalone Content Engines
-
Chapter 10: Configuring URL Filtering on Standalone Content Engines
-
Chapter 11: Configuring ICAP on Standalone Content Engines
-
Chapter 12: Configuring the Rules Template on Standalone Content Engines
-
Chapter 13: Configuring Primary and Backup Proxy Servers for Standalone Content Engines
-
Chapter 14: Configuring Advanced Transparent Caching Features on Standalone Content Engines
-
Chapter 15: Configuring Additional Network Interfaces and Bandwidth on Standalone Content Engines
-
Chapter 16: Configuring Login Authentication and Authorization on Standalone Content Engines
-
Chapter 17: Configuring AAA Accounting on Standalone Content Engines
-
Chapter 18: Creating and Managing IP Access Control Lists for Standalone Content Engines
-
Chapter 19: Viewing and Modifying TCP Stack Parameters on Standalone Content Engines
-
Chapter 20: Monitoring and Troubleshooting
-
Appendix A: Content Engine GUI Menu Options
-
Appendix B: Reference Material for Standalone Content Engine Deployments
-
Table Of Contents
Configuring WMT Streaming Media Services on Standalone Content Engines
Overview of WMT Streaming and Caching with Standalone Content Engines
About the Components of Windows Media Services
How Standalone Content Engines Process WMT Requests
About Fast Streaming with Windows Media Services 9 Series
About WMT Streaming and Caching Services with Standalone Content Engines
About Caching Policies in WMT Streaming Media Caching
About Proxy Authentication for a WMT-Enabled Content Engine
Configuring WMT Streaming and Caching Services for Standalone Content Engines
Guidelines for Configuring WMT Streaming and Caching Services
About WMT Variable Bit Rate Support
Adding or Removing WMT HTTP Allowed Filename Extensions
Configuring WMT Streaming and Caching Services
Checklist for Configuring WMT Streaming and Caching Services for Standalone Content Engines
Enabling WMT on Standalone Content Engines
Configuring WMT Redirection with Standalone Content Engines
Enabling and Configuring Nontransparent WMT Proxy Caching on Standalone Content Engines
Enabling and Configuring WMT Transparent Caching on Standalone Content Engines
Configuring Outgoing WMT Proxy Servers for Standalone Content Engines
Configuring Standalone Content Engines to Distribute WMT VOD Files
Verifying That Preloading WMT VOD Files Are Cached and Properly Distributed to Clients
Displaying WMT Configurations on Standalone Content Engines
Configuring Fast Start on Standalone Content Engines
Configuring Fast Cache on Standalone Content Engines
Configuring WMT Bandwidth Settings on Standalone Content Engines
Disallowing Specific Client Protocols
Configuring Standalone Content Engines to Deliver WMT Live Streams
Configuring Standalone Content Engines to Multicast Live WMT Streams
Configuring Multicast-In Multicast-Out on Standalone Content Engines
Configuring Unicast-In Multicast-Out on Standalone Content Engines
Defining WMT Multicast Stations and Multicast Schedules on Standalone Content Engines
Starting and Stopping WMT Multicast Stations
Configuring Standalone Content Engines to Unicast Live WMT Streams
Configuring Multicast-In Unicast-Out on Standalone Content Engines
Configuring Unicast-In Unicast-Out on Standalone Content Engines
Configuring the Maximum Number of Concurrent Sessions
Clearing WMT Streams on Standalone Content Engines
Using WMT Transaction Logging with Standalone Content Engines
Log Formats Accepted by Windows Media Services 9
Specifying the Format of the WMT Transaction Logs on Standalone Content Engines
Enabling the Logging of Usernames to the WMT Transaction Log
Using WMT Error Logging with Standalone Content Engines
Logging WMT Client Disconnects
Logging the Clearing of WMT Streams on Standalone Content Engines
Configuring WMT Streaming Media Services on 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 services, including Microsoft Windows Media Technologies (WMT), as well as RealNetworks RealMedia and Apple QuickTime that use the Real-Time Streaming Protocol (RTSP).
This chapter provides an overview of the WMT streaming media services, and describes how to use the Content Engine CLI to configure these services on standalone Content Engines. This chapter contains the following sections:
•
Overview of WMT Streaming and Caching with Standalone Content Engines
•
•
•
•
Note
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.
Overview of WMT Streaming and Caching with Standalone Content Engines
The WMT feature on a standalone Content Engine is licensed software. To enable the licensed WMT feature on a Content Engine, you must have a WMT license key. You must specify a permanent 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 WMT license though the Cisco.com website. You specify the WMT license key as part of enabling the WMT product feature on a standalone Content Engine. See the "Enabling WMT on Standalone Content Engines" section.
ACNS software, Release 5.2 or later, interoperates with the following software:
•
•
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.
About the Components of Windows Media Services
Windows Media Services is Microsoft's set of streaming solutions for creating, distributing, and playing back digital media files on the Internet.
Table 7-1 describes the major components of Windows Media Services 9 Series and Windows Media Services 4.1
A URL that points to a streaming ASF file includes MMS as its protocol, as shown in the following example:
mms://servername/filename.asfWindows Media Services 9 Series is the new Windows Media solutions from Microsoft. With Windows Media Services 9 Series, Microsoft introduced a major change in the streaming protocol. Whereas the earlier versions of the Windows Media Players and servers use the MMS-over-UDP (MMSU) or MMS-over-TCP (MMST) protocol, Windows Media Services 9 Series by default uses a new RTSP-based protocol for streaming. In other words, the streaming protocols used by Windows Media Services 9 players are now:
•
•
•
Note
About the MMS Protocol
MMS is a proprietary protocol designed by Microsoft for streaming media content. The media content format used by Microsoft is called the active streaming format (ASF). MMS protocol is an application-level protocol that runs over UDP, TCP, or HTTP. MMS can also utilize IP multicast in order to broadcast media contents.
The MMS protocol automatically looks for the optimal transport method to deliver the streaming media in the following order:
•
•
•
MMSU is the Microsoft Media Server protocol with transport over UDP. UDP is a connectionless, transport-layer protocol that is ideal for real-time media because it does not guarantee delivery. Although this sounds like a drawback rather than an advantage, it is a characteristic particularly suited for streaming media. Unlike data such as files or e-mail, which must be delivered in their entirety no matter how long the transmission time, the value of streaming media data is constrained by time. If a frame of video is lost, it is worthless because it will not arrive within the correct time frame.
MMST is the Microsoft Media Server protocol with transport over TCP.
WCCP Version 2 supports two redirection services (the MMST service and the MMSU service) that allow you to configure WCCP Version 2 routers to redirect WMT requests transparently to a Content Engine (functioning as a transparent proxy server that is configured to support WMT transparent caching).
The client (the Windows Media Player) attempts to retrieve a file using all of these protocols (MMS-over-UDP [MMSU], MMS-over-TCP [MMST], and MMS-over-HTTP). The general rule is the following:
•
•
•
Because the MMS protocol can also run over HTTP, the Content Engine needs to distinguish MMS requests from regular HTTP requests. The Content Engine accomplishes this by examining the User-Agent header in the request. If the User-Agent is the Windows Media Player, then the Content Engine assumes that it is an MMS request; otherwise, it considers it a regular HTTP request.
Tip
How Standalone Content Engines Process WMT Requests
Standalone Content Engines can receive WMT requests directly from WMT clients, or from WCCP Version 2 routers or Layer 4 CSS switches (through WMT transparent redirection).
The actual protocol used is negotiated between the WMT client and the server. If both the client and the server are Windows Media Services 9 Series, then the RTSP protocol is used if the URL starts with mms://, and the HTTP protocol is used if the URL starts with http://.
In ACNS 5.2 software, MMS-over-HTTP is supported with Windows Media Services 9 Series; MMS-over-RTSP is not currently supported. Because MMS-over-RTSP is not supported by a Content Engine that is running ACNS 5.x software, when the Content Engine receives an MMS request from a client, the Content Engine acts as a Windows Media 4.1 server instead of a Windows Media 9 server. For example, if a Content Engine that is running ACNS 5.2 software receives an MMS request (one beginning with mms://) from the client, the Content Engine acts as a Windows Media 4.1 server and establishes an MMST connection with the origin server.
In the case of MMS-over-HTTP with Widows Media Services 9 Series, a standalone Content Engine that is running ACNS software, Release 5.2 and later, supports the Fast Start and Fast Cache features for preloaded VOD, live-split, and on-demand (cache-hit) content. For more information on these features, see the "Configuring Fast Start on Standalone Content Engines" section and the "Configuring Fast Cache on Standalone Content Engines" section.
Note
In ACNS 5.2 software, the WMT streaming module contains two sets of processes that handle client requests:
•
•
In ACNS 5.2 software, standalone Content Engines use the Fast Start and Fast Cache features to stream live stream-split content or on-demand (cache-hit) content to the client; a Windows Media 9 server cannot stream content to a Content Engine using Fast Start or Fast Cache.
About Fast Streaming with Windows Media Services 9 Series
Windows Media Services 9 Series offers a set of Fast Streaming features that combine streaming, downloading, and caching features for web client acceleration improving the user experience by accelerating delivery of streaming content to the client. In versions earlier than Windows Media Services 9 Series, content was streamed at a constant bit rate to clients.
ACNS 5.2 software supports the following Fast Streaming features: Fast Start, Fast Cache, and Fast Reconnect. This support is for MMS-over-HTTP only; ACNS software does not currently support MMS-over-RTSP.
Table 7-2 lists the Fast Streaming features that are supported by Content Engines that are running ACNS software, Release 5.2 or later.
Table 7-2 Fast Streaming Features Supported by Standalone Content Engines
Fast Start
See the "Configuring Fast Start on Standalone Content Engines" section.
Fast Cache
See the "Configuring Fast Cache on Standalone Content Engines" section.
Fast Reconnect
Enables the Windows Media 9 server to automatically restore client connections (including encoders, distribution servers, and Windows Media Player 9 Series) that are lost during a broadcast because of network conditions. Depending on the type of content (for example, video on demand or a live broadcast), the user may experience a gap in the broadcast. This feature is a client-side feature, so there is no configuration required on the server side (that is, the Content Engine that is functioning as a Windows Media 9 server for the Windows Media Player 9 Series).
Table 7-3 lists the types of content that are supported with the Fast Start and Fast Cache features.
Table 7-3 Fast Start and Fast Cache Support for Standalone Content Engines
Fast Start
Yes
Yes
Fast Cache
Yes
Not applicable
With preloaded VOD files, if the Windows Media 9 server (the Content Engine) determines that the client (Windows Media Player 9 Series) supports the Fast Start and Fast Cache features, it uses the Fast Start and Fast Cache features to send the packets to the clients. Otherwise, the Windows Media 9 server transmits the packets at its regular speed.
With a cache hit, the Windows Media 9 server (the Content Engine) use the Fast Start and Fast Cache features to serve the content when the content is cached or partially cached in its local storage.
With a cache miss, the Windows Media 9 server (the Content Engine) masquerades as a Windows Media Version 7 player and communicates with the remote origin server. Although the origin server supports Fast Start and Fast Cache, the packets must come from the remote server and will still be in the normal pace. After the content is cached on the Content Engine (cache hit or partial hit), the Fast Start and Fast Cache features are supported for MMS-over-HTTP.
With live content, the Windows Media 9 server (the Content Engine) needs to hold the content in its buffer for a few seconds. When the first client requests the live stream, the buffer fills up. This buffer is used to serve Fast Start packets to subsequent clients that request the same stream. Note that the first client does not experience any benefit from the Fast Start feature. However, the first client triggers the process of having data come into the Content Engine's buffer. Subsequent clients who request the same live content will see the benefit of Fast Start when the Content Engine pushes the buffered content to these clients at a faster pace.
Note
About WMT Streaming and Caching Services with Standalone Content Engines
Table 7-4 lists the types of WMT streaming and caching services that are supported with standalone Content Engines that are running ACNS software (Release 5.2 or later).
Table 7-4 WMT Streaming and Caching Services with Standalone Content Engines
WMT proxy caching
The Content Engine receives WMT requests directly from a Windows Media Player. The Content Engine retrieves the requested content if it is not already stored in its local cache, stores a copy locally whenever possible, and sends the requested content to the client. For more information, see the "About WMT Proxy Caching" section.
WMT transparent
cachingThe Content Engine receives WMT requests that are transparently redirected to it by a WCCP Version 2 router or a Layer 4 switch. The Content Engine retrieves the requested content if it is not already stored in its local cache, stores a copy locally whenever possible, and sends the requested content to the client. For more information, see the "About WMT Transparent Caching" section.
Distribution of
WMT live streams
(common)The Content Engine serves WMT live streams to all local users (Windows Media Players) whose WMT traffic it receives. The WMT live streams can be unicast or multicast live feeds. The Content Engine splits the live feeds into multicast or unicast to relay the stream to the WMT client. For more information, see the "About Live Splitting with WMT" section.
Distribution of
preloaded VOD
files (rare)VOD files are preloaded on the Content Engine for on-demand delivery of these files to the Windows Media Players. VOD caching is similar to HTTP caching; however, VOD files are cached in a different file system (mediafs) on the standalone Content Engine.
To configure a standalone Content Engine to distribute VOD files, follow these steps:
1.
2.
About Caching Policies in WMT Streaming Media Caching
In contrast to HTTP caching, caching policies in WMT streaming media caching are much simpler, because streaming media is mostly large static content. The caching policy in WMT caching is straightforward. All responses are cacheable, including partial responses. All WMT requests result in communication between the Content Engine and the origin 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.
About WMT Proxy Caching
If direct proxy routing is being used to direct WMT requests to the standalone Content Engine, then you can configure the Content Engine to support WMT proxy caching. In direct proxy mode, the standalone WMT-enabled Content Engine accepts incoming WMT streaming requests directly from WMT clients (end users who are using the Windows Media Player to request WMT content) and acts on behalf of these clients, communicating with the origin WMT server. This type of caching is referred to as "WMT proxy caching." The Content Engine accepts and serves the streaming requests over MMS as well HTTP. MMS is the protocol that WMT uses for communication between media players and servers. (See Figure 7-1.)
Figure 7-1 WMT Proxy Caching (Direct Proxy Routing)
Note
You can use the Setup utility or the Content Engine CLI to enable and configure WMT proxy caching on a standalone Content Engine that is running ACNS software, Release 5.2 or later.
•
•
About WMT Transparent Caching
If transparent redirection (WCCP or Layer 4 switching) is being used to direct WMT requests to a standalone Content Engine, then you can configure the Content Engine to support WMT transparent caching. In this case, the standalone Content Engine is acting as a transparent proxy server for clients who are requesting WMT content, and the Content Engine is not visible to these clients. After receiving a transparently redirected WMT request, the Content Engine retrieves the requested content if it is not already stored in its local cache, stores a copy locally whenever possible, and sends the requested content to the requester (client media player).
You can use the Setup utility or the Content Engine CLI to enable and configure WMT transparent caching on a standalone Content Engine that is running ACNS software, Release 5.2 or later. If you use the Setup utility, you can only configure the Content Engine to accept redirected WMT requests from WCCP Version 2 routers, whereas if you use the Content Engine CLI, you can configure the Content Engine to accept redirected WMT requests from Layer 4 switches as well as from WCCP Version 2 routers.
For information about how to use the Setup utility to configure WMT transparent caching on a standalone Content Engine, see the "Using the Setup Utility to Configure a Basic Configuration on a Standalone Content Engine" section. For information about how to configure WMT transparent caching on a standalone Content Engine through the Content Engine CLI, see the "Enabling and Configuring WMT Transparent Caching on Standalone Content Engines" section.
About Live Splitting with WMT
The WMT-enabled Content Engine also supports live splitting. By splitting requests for live streams. A single stream from the origin streaming server is split to serve each client that requested the stream. (See Figure 7-2.) If a WMT client requests a publishing point on a remote streaming server without specifying an ASF file, the Content Engine dynamically creates an alias file that references the remote streaming server. All further requests to that remote streaming server are served by having the Content Engine split the stream and serve it to the WMT clients.
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 7-2 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
About Proxy Authentication for a WMT-Enabled Content Engine
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.
The two types of proxy authentication methods are:
•
•
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. NTLM authentication is supported in nontransparent proxy mode (direct proxy routing) 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 (ACLs) enforced by the origin server are automatically enforced by the proxy.
Note
In ACNS software, Release 5.2, pass-through authentication support for WMT requests was added. For more information on this topic, see the "Configuring Pass-Through Authentication for WMT Requests" section.
Configuring WMT Streaming and Caching Services for Standalone Content Engines
This section describes how to configure WMT streaming and caching services for standalone Content Engines. The section covers the following topics:
•
•
See Figure 7-3 and Figure 7-4 for a detailed view on how to configure WMT streaming and caching initially for standalone Content Engines. See the Table 7-5 for a checklist of tasks for configuring these services on a standalone Content Engine.
Guidelines for Configuring WMT Streaming and Caching Services
When configuring WMT streaming and caching services with standalone Content Engines, note the following important points:
•
Note
•
–
–
–
•
About WMT Variable Bit Rate Support
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 choose a particular bit rate. 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 client that is requesting WMT content. The range of values is between 0 and 2,147,483,647 kilobits per second. The default value is 0 (no bit rate limit).
WMT Proxy Server Requirements
The following are requirements for a standalone Content Engine that will be functioning as a WMT proxy server:
•
•
•
•
•
•
Note
If the WMT license key is no longer needed on the Content Engine because the WMT licensed product feature is not needed, you can uninstall the WMT license key by entering the no wmt license-key global configuration command. After a license key is uninstalled on one Content Engine, it can be used on another device if that device supports the WMT license key.
Note
•
•
Adding or Removing WMT HTTP Allowed Filename Extensions
Content Engines use a list of filename extensions to decide whether a type of media file should be served by WMT. Typically, Content Engines are shipped with a default list of filename extensions to be served by WMT. The default list in the Content Engine contains the following file name extensions: asf, none, nsc, wma, and wmv.
Note
Use the wmt http allow extension global configuration command to add filename extensions to this list. Use the no version of this command (no wmt http allow extension) to remove a filename extension from the list.
Note
The following restrictions apply to adding new file extensions to the list:
•
•
•
The following example adds the file extension mp3 to the list of file extensions to be served by WMT:
ContentEngine(config)# wmt http allow extension mp3ContentEngine(config)#You can use the show wmt http allow extension EXEC command to see the file extensions included in the list after you add or delete file extensions.
Tip
In the following example of the show wmt http allow extension EXEC command, the default list of file extension has not been modified:
ContentEngine# show wmt http allow extensionContentEngine#In the following example of the show wmt http allow extension EXEC command, the file extension mp3 has been added to the list of file extensions:
ContentEngine# show wmt http allow extensionWMT mms extensions allowed :asf mp3 none nsc wma wmvContentEngine(config)#Configuring WMT Streaming and Caching Services
This section describes how to use the Content Engine CLI to configure WMT streaming and caching services on a standalone Content Engine. Figure 7-3 and Figure 7-4 provide a detailed view on how to configure WMT streaming and caching initially for standalone Content Engines. Table 7-5 provides a checklist of tasks for configuring these services on a standalone Content Engine.
This section also describes how to perform the necessary configuration changes to the client media players (if direct proxy routing is to be used) and the necessary configuration changes to WCCP Version 2 routers (if WMT redirection will be used).
Note
With the Content Engine CLI, you can configure the Content Engine to accept redirected WMT requests from a WCCP Version 2 router or a Layer 4 switch. For information about how to use the Setup utility to configure WMT caching on a standalone Content Engine, see the "Configuring a Basic Configuration on Standalone Content Engines with the Setup Utility" section.Figure 7-3 Configuring WMT Streaming and Caching Services for Standalone Content Engines (Part 1)
Figure 7-4 Configuring WMT Streaming and Caching Services for Standalone Content Engines (Part 2)
Checklist for Configuring WMT Streaming and Caching Services for Standalone Content Engines
Table 7-5 is a checklist of tasks for configuring WMT 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, as well as how to configure how the WMT requests are routed to this standalone Content Engine.
Note
Table 7-5 Checklist for Configuring WMT Streaming and Caching Services for Standalone Content Engines
1.
Content Engine.a.
b.
specify your Cisco permanent WMT license.c.
See the "Enabling WMT on Standalone Content Engines" section.
2.
routing methods to direct client requests for
WMT content to this standalone Content Engine:–
–
routing or Layer 4 switching)With direct proxy routing, the client WMT media players send their requests directly to this Content Engine (nontransparent forward proxy server). With direct proxy routing, you must point the WMT clients directly to the Content Engine, as described in the "Pointing Windows Media Players Directly to a Standalone Content Engine" 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 WMT transparent redirection, as described in the "Configuring WMT Redirection with Standalone Content Engines" section.
3.
WMT proxy caching on the Content Engine.See the "Enabling and Configuring Nontransparent WMT Proxy Caching on Standalone Content Engines" section.
4.
WMT transparent caching on the Content Engine.See the "Enabling and Configuring WMT Transparent Caching on Standalone Content Engines" section.
5.
that this standalone Content Engine will be
distributing to clients:–
–
For VOD files, see the "Configuring Standalone Content Engines to Distribute WMT VOD Files" section.
For live WMT streams, choose which methods this Content Engine will use to relay live WMT streams to WMT clients:
•
or
•
6.
to WMT clients through multicasting.See the "Configuring Standalone Content Engines to Multicast Live WMT Streams" section.
7.
to WMT clients through unicast.See the following sections in this chapter:
•
•
Enabling WMT on Standalone Content Engines
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 Microsoft WMT licensed product feature on a standalone Content Engine, follow these steps:
Step 1
ContentEngine# show wmt license-agreementStep 2
ContentEngine# configure terminalContentEngine(config)# wmt accept-license-agreementStep 3
ContentEngine(config)# wmt license-key licensekeyAlternatively, accept an evaluation WMT license by using the wmt evaluate global configuration command.
ContentEngine(config)# wmt evaluateStep 4
ContentEngine(config)# wmt enableThe next step is to choose one or more of the following routing methods to direct client requests for WMT content to this standalone Content Engine:
•
•
With direct proxy routing, the client WMT media players send their requests directly to this Content Engine (acting as a nontransparent forward proxy server). For instructions on how to configure Windows Media Player on the end user desktops to point directly to this Content Engine as their proxy server, see the "Pointing Windows Media Players Directly to a Standalone Content Engine" section.
Configuring WMT Redirection with Standalone Content Engines
With WMT transparent redirection, a WCCP Version 2-enabled router or a Layer 4 switch transparently redirects WMT requests to the Content Engine (acting as a transparent proxy server). WMT transparent redirection is used to support WMT transparent caching on a standalone Content Engine. With WMT transparent redirection, you must configure WMT redirection on the WCCP Version 2-enabled routers or the Layer 4 switch as well as on the standalone Content Engine that will receive these redirected WMT requests.
To configure WMT transparent redirection through WCCP Version 2, you must perform both of these tasks:
•
•
The following scenario shows how to use the Content Engine CLI to configure redirection of WMT requests through WCCP Version 2.
This scenario assumes that you have enabled the licensed WMT feature on the standalone Content Engine, as described in the "Enabling WMT on Standalone Content Engines" section.
Step 1
RouterA# configure terminalRouterA(config)# ip wccp version 2Step 2
a.
RouterA(config)# ip wccp 81b.
RouterA(config)# ip wccp 82
Note
Step 3
RouterA(config)# interface type numberThe following shows how to configure the outgoing interface to the Internet as Ethernet 0 on Router A.
RouterA(config)# interface Ethernet 0Step 4
Specify the inbound or outbound interface for the MMST redirection service (the mmst service [service 81]) and MMSU redirection service (the mmsu service [service 82]).
RouterA(config-if)# ip wccp 81 redirect outRouterA(config-if)# ip wccp 82 redirect out
Note
Step 5
a.
ContentEngine(config)# wccp version 2b.
In the following example, there is one WCCP Version 2-enabled router (Router A) associated with router list 1. Router A has an IP addresses of 172.16.25.25.
ContentEngine(config)# wccp router-list 1 172.16.25.25c.
ContentEngine(config)# wccp wmt router-list-num 1Step 6
ContentEngine(config)# transaction-log enable
Tip
Step 7
ContentEngine# copy running-config startup-configStep 8
ContentEngine# show wmtStep 9
Step 10
ContentEngine# show statistics wmt all
Note
After configuring the routers and Content Engine to support WMT redirection through WCCP Version 2, enable and configure WMT transparent caching on the Content Engine, as described in the "Enabling and Configuring WMT Transparent Caching on Standalone Content Engines" section.
To enable transparent redirection through a Layer 4 switch instead of through WCCP, enter the following command.
ContentEngine(config)# wmt l4-switch enableThe wmt l4-switch enable global configuration command enables the Content Engine to receive WMT requests that are transparently redirected to it by a Layer 4 switch (for example, a CSS switch). The Layer 4 switch intercepts the client's request for WMT content and transparently redirect that request to the Content Engine (acting as the WMT proxy server).
Enabling and Configuring Nontransparent WMT Proxy Caching on Standalone Content Engines
With direct proxy routing, the client WMT media players send their requests directly to the Content Engine that is acting as a nontransparent forward proxy server. Direct proxy routing is used to support WMT proxy caching on a Content Engine. By default, WMT proxy caching is enabled, and the Content Engine listens for incoming WMT requests from clients on port 1755. With direct proxy routing, you must point the client WMT media players directly to the Content Engine, as described in the "Pointing Windows Media Players Directly to a Standalone Content Engine" section
To use the Content Engine CLI to enable and configure WMT proxy caching on a standalone Content Engine, follow these steps:
Step 1
ContentEngine(config)# wmt cache enableStep 2
ContentEngine(config)# wmt cache max-obj-size sizeStep 3
ContentEngine(config)# wmt incoming portnumberStep 4
Enabling and Configuring WMT Transparent Caching on Standalone Content Engines
With WCCP routing or Layer 4 switching, you must configure the WCCP Version 2-enabled routers or Layer 4 switches and the Content Engine (transparent proxy server) for WMT transparent redirection, as described in the "Configuring WMT Redirection with Standalone Content Engines" section.
To use the Content Engine CLI to enable and configure WMT transparent caching on a standalone Content Engine, follow these steps:
Step 1
ContentEngine(config)# wmt cache enableStep 2
ContentEngine(config)# wmt cache max-obj-size sizeStep 3
ContentEngine(config)# wccp wmt router-list numberStep 4
ContentEngine(config)# wccp router-list numberIn the following example, there are two WCCP Version 2-enabled routers associated with router list 1. These routers have the IP addresses 172.16.25.25 and 172.16.26.26.
ContentEngine(config)# wccp router-list 1 172.16.25.25 172.16.26.26Step 5
ContentEngine(config)# wccp wmt router-list-num numberStep 6
ContentEngine(config)# wccp version 2Step 7
For more information on this topic, see the next section, "Configuring Outgoing WMT Proxy Servers for Standalone Content Engines."
Configuring Outgoing WMT Proxy Servers for Standalone Content Engines
ACNS 5.x software allows you to specify the external WMT server that the Content Engine should use as its upstream WMT server (outgoing HTTP proxy server for MMS-over-HTTP, or an MMS outgoing server for MMS). The Content Engine contacts the specified HTTP or MMS outgoing proxy server upon a cache miss (that is, if the Content Engine does not have the requested WMT content already stored in its local cache).
Note
You can configure a Content Engine to send all of its MMS cache miss traffic to a specific HTTP or MMS outgoing proxy server without using ICP or WCCP. To configure direct outgoing requests on a standalone Content Engine for all MMS cache miss traffic, use the wmt proxy outgoing global configuration command.
wmt proxy outgoing {http | mms} host {hostname | ip-address} port
where:
•
•
•
•
•
In the following example, a Content Engine at a branch office is configured to use MMS-over-HTTP to send all its WMT cache miss traffic to a central Content Engine at 172.16.30.30 through port 8080.
ContentEngine(config)# wmt proxy outgoing http host 172.16.30.30 8080In the following example, a Content Engine at a branch office is configured to send all its MMS cache miss traffic to a central Content Engine at 172.16.30.31 through port 1700.
ContentEngine(config)# wmt proxy outgoing http host 172.16.30.31 1700In the following example, a Content Engine at a branch office is configured to use MMS instead of MMS-over-HTTP to send all its MMS cache miss traffic to a central Content Engine at 172.16.30.31 through port 1755.
ContentEngine(config)# wmt proxy outgoing mms host 172.16.30.31 1755Configuring Standalone Content Engines to Distribute WMT VOD Files
You can preload WMT video-on-demand (VOD) files on the Content Engine for on-demand delivery of these files to WMT clients. VOD caching is similar to HTTP caching; however, VOD files are cached in a different file system (mediafs) on the standalone Content Engine. WMT transparent caches and WMT proxy caches both support VOD caching.
To configure a standalone Content Engine to distribute VOD files to WMT clients, do the following:
1.
a.
b.
c.
d.
2.
For instructions on how to preload files on a standalone Content Engine, see the "Configuring Content Preloading for Standalone Content Engines" section. For information about how you can verify that the preloaded WMT VOD files are being cached and properly distributed to clients, see the next section, "Verifying That Preloading WMT VOD Files Are Cached and Properly Distributed to Clients."
Verifying That Preloading WMT VOD Files Are Cached and Properly Distributed to Clients
This section describes how you can verify that a standalone Content Engine has stored the preloaded VOD files in its WMT cache, and is distributing these VOD files to WMT clients upon request. This scenario assumes the following:
•
•
This scenario shows how to point to a VOD source and verify that both WMT proxy caching and WMT transparent caching are working properly on the standalone Content Engine.
Step 1
Step 2
Step 3
The specified preloaded video should start playing in the WMT media player on the client's desktop.
Step 4
The protocol should be shown as MMS (UDP). This indicates that the stream is being delivered in a streaming fashion instead of reverting to HTTP, which occurs if the WMT streaming proxy or WMT server is not available.
Step 5
Step 6
Step 7
The following shows how to check the number of WMT packets that were redirected on the router through MMST redirection (service 81):
Router# show ip wccp 81Global WCCP information:Router information:Router Identifier: 10.150.1.3Protocol Version: 2.0Service Identifier: 81Number of Cache Engines: 1Number of routers: 1Total Packets Redirected: 260Redirect access-list: -none-Total Packets Denied Redirect: 0Total Packets Unassigned: 0Group access-list: -none-Total Messages Denied to Group: 0Total Authentication failures: 0Step 8
ContentEngine# show stat wmt savingsContentEngine# show stat wmt requestContentEngine# show stat wmt usageStep 9
ContentEngine# type-tail "/local1/logs/export/working.log"
Displaying WMT Configurations on Standalone Content Engines
To display the current WMT proxy configuration for a standalone Content Engine, use the show wmt proxy EXEC command.ContentEngine# show wmt proxyIncoming Proxy-Mode:Configured proxy mode WMT on port: 1755WMT Transparent Proxy (WCCP):Configured for port: 1755WMT Transparent Proxy (L4 Switch):Not configured.Outgoing MMS-over-HTTP Proxy-Mode:Not configured outgoing MMS-over-HTTP proxy mode.Outgoing MMS Proxy-Mode:Not configured outgoing MMS proxy mode.To display the current WMT configuration for a standalone Content Engine (including the WMT proxy configuration), use the show wmt EXEC command. As the following sample output shows, information about the WMT bandwidth, Microsoft Media Server (MMS), proxy mode configuration, and WMT license information is displayed. If the license-agreement option is included in the command string, the full text of the WMT license agreement is displayed.
ContentEngine# show wmt--------- WMT Server Configurations -----------------WMT version: ce507-001.000WMT is enabledWMT disallowed client protocols: noneWMT end user license agreement acceptedWMT license key not installedWMT evaluation is not enabledWMT outgoing bandwidth configured is 1 Kbits/secWMT incoming bandwidth configured is 15 Kbits/secWMT incoming port: 1755WMT max sessions configured: 1WMT max sessions platform limit: 2500WMT max sessions enforced: 1 sessionsWMT max outgoing bit rate allowed per stream has no limitWMT max incoming bit rate allowed per stream has no limitWMT cache is not enabledWMT cache max-obj-size: 1024 MBWMT cache unique-stream-key is enabledWMT debug level: 0WMT L4 switch is not enabledWMT debug client ip not setWMT debug server ip not setWMT/REAL cache space partition: wmt 70%, real 30%wmt multicast station-configuration mcast_station 224.1.1.1 8080 mms://localhost/media.asfwmt multicast schedule-start mcast_station 0 0 1 1wmt broadcast alias-name wmt source http://abcwmt broadcast alias-name wmt1 source ftp://mms1*WMT Stripping ? from Live URL is not enabledWMT Live-split using streaming engine is enabledWMT Proxy cache using streaming engine is enabledWMT fast-start is enabledWMT fast-start max. bandwidth per player is 3500 (Kbps)WMT fast-cache is enabledWMT fast-cache excelleration factor is 5WMT Extended Transaction Log is not enabledWMT Transaction Log format is Windows Media Services 4.1 logging--------- WMT HTTP Configurations --------------------WMT http extensions allowed:asf none nsc wma wmv mpg--------- WMT Proxy Configurations ------------------Incoming Proxy-Mode:Configured proxy mode WMT on port: 1755WMT Transparent Proxy (WCCP):Configured for port: 1755WMT Transparent Proxy (L4 Switch):Not configured.Outgoing MMS-over-HTTP Proxy-Mode:Not configured outgoing MMS-over-HTTP proxy mode.Outgoing MMS Proxy-Mode:Not configured outgoing MMS proxy mode.Configuring Fast Start on Standalone Content Engines
The Fast Start feature allows the server to push the beginning portions of a stream to the client at the maximum available bandwidth. This reduces the amount of time that is required to fill the player's internal buffer, and reduces the amount of time that users (the WMT clients) need to wait before they can start to view the stream in their player (Windows Media Player 9 Series).
The Windows Media 4.1 server and Windows Media Player Version 4.1 do not support the Fast Start feature.
A media player must fill its internal buffer (the default is 5 seconds) before it starts rendering the video. For example:
•
•
Note
Standalone Content Engines that are running ACNS software, Release 5.2 or later, use the Fast Start feature for preloaded video-on-demand files, cache hits, and live content. This feature is not supported for cache misses and is used only by clients that connect to a unicast stream.
To configure the Fast Start feature on a standalone Content Engine that is running ACNS software, Release 5.2 or later, use the wmt fast-start global configuration command.
wmt fast-start {enable | max-bandwidth number}
Table 7-6 describes the command parameters.
The increased bandwidth that the Fast Start feature initially uses to send data to the player can overburden a network if many players connect to the stream at the same time. Use the wmt fast-start max-bandwidth option to specify the maximum burst bandwidth allowed for a single WMT client.
Configuring Fast Cache on Standalone Content Engines
With the Fast Cache feature, the stream rendering rate is decoupled from the stream delivery rate on the network. This allows a Windows Media 9 server to send the stream content faster than the client's rendering speed. The extra data is then buffered at the Windows Media Player 9 Series client to allow the player to better withstand fluctuations in network bandwidth later on.
Note
A Windows Media 9 server informs a Windows Media Player 9 Series client that it supports the Fast Cache feature. The player then indicates to the server how fast it is for Fast Start and Fast Cache features. When Fast Cache is configured on a Content Engine that is running ACNS software, Release 5.2 or later, the Content Engine uses the smaller value of the following to serve the content to the Windows Media Player 9 Series client:
•
•
Standalone Content Engines that are running ACNS software, Release 5.2 or later, use the Fast Cache feature for preloaded video-on-demand files and for cache hits. The Fast Cache feature is not supported for cache misses, and is not applicable for the delivery of live content.
To enable the Fast Cache feature on a standalone Content Engine that is running ACNS software, Release 5.2 or later, use the wmt fast-proxy-cache enable global configuration command.
Configuring WMT Bandwidth Settings on Standalone Content Engines
To configure WMT bandwidth settings on standalone Content Engines, use the wmt bandwidth incoming bypass-list global configuration command.
wmt bandwidth incoming bypass-list {ip-address | hostname} [ip-address | hostname]
Table 7-7 describes the command parameters.
The increased bandwidth that the Fast Start feature initially uses to send data to the Windows Media Player 9 Series client can overburden a network if many players connect to the stream at the same time. Use the wmt fast-start max-bandwidth number global configuration command to specify the maximum burst bandwidth allowed for a single WMT client. For more information, see the "Configuring Fast Start on Standalone Content Engines" section.
Disallowing Specific Client Protocols
To configure standalone Content Engines to disallow specific WMT client protocols for streaming, use the wmt disallowed-client-protocols global configuration command.
wmt disallowed-client-protocols {HTTP | TCP | UDP}
Table 7-8 describes the command parameters.
Configuring Standalone Content Engines to Deliver WMT Live Streams
Based on the capabilities and limitations of the network, standalone Content Engines can receive live WMT streams and then deliver WMT streaming content through multicast out or unicast out. This section describes how to configure standalone Content Engines to deliver WMT live streams, and includes the following sections:
•
•
Configuring Standalone Content Engines to Multicast Live WMT Streams
You can configure standalone Content Engines to relay live content to WMT clients through multicasting or unicast. This section describes how to configure standalone Content Engines to relay live content through multicasting, as follows:
•
•
•
•
Note
Use the wmt multicast {schedule-start name minute hour day month | station-configuration name dest_addr dest_port media_source [play-forever]} command to enable WMT multicasting for unicast-in multicast-out ("Configuring Unicast-In Multicast-Out on Standalone Content Engines" section) and multicast-in multicast-out ("Configuring Multicast-In Multicast-Out on Standalone Content Engines" section) on a standalone Content Engine.
Tip
For information about how to configure standalone Content Engines to relay live content to clients through unicast, see the "Configuring Standalone Content Engines to Unicast Live WMT Streams" section.
Configuring Multicast-In Multicast-Out on Standalone Content Engines
The multicast-in multicast-out multicast receive feature enables you to receive multicast WMT streams delivered through IP multicasting, and then relay them to end users through another delivery channel (unicast or multicast). The two WMT multicast-out features combined enable you to receive and deliver WMT streaming media content through IP multicasting, and to do conversions from multicast to unicast (and vice versa).
In this multicasting scenario, a description file *.nsc is created that is accessible through multicast-out to clients. This is similar to the unicast-in multicast-out scenario except that the input source is multicast. The clients use this description file to subscribe to the multicast.
To configure a standalone Content Engines to use multicast-in multicast-out to relay live WMT streams to WMT clients, follow these steps:
Step 1
where:
•
•
•
•
•
In the following example, a multicast station named acme is configured and used by the Content Engine as the multicast source file. Its Class D multicast IP address is 233.33.33.34, and the multicast port is 6667. The multicast stream stops playing once the end of the source.nsc file is reached, unless the play-forever option is specified.
ContentEngine(config)# wmt multicast station-configuration acme 233.33.33.34 6667 http://172.16.30.31/source.nscContentEngine(config)#Step 2
ContentEngine# wmt multicast-station start acmeContentEngine#Step 3
Step 4
http://ContentEngineIPaddress/acme.nscStep 5
The WMT media player should receive the MMS media file specified in Step 1.
Configuring Unicast-In Multicast-Out on Standalone Content Engines
The Content Engine supports several different sources for a unicast-in multicast-out stream, otherwise known as stream splitting. A unicast input can be from a video-on-demand (VOD) publishing point, a live unicast publishing point, an encoder, or a streaming media source from a local disk. The ASF header obtained from the unicast input and the parameters used to configure the multicast station are used by the Content Engine to automatically create the multicast description.nsc file. The clients use this easily accessible file to subscribe to the multicast.
Tip
The unicast-in multicast-out multicast delivery feature enables you to distribute streaming media efficiently by allowing different devices on the IP multicast to receive a single stream of media content from the Content Engine simultaneously. This can save significant network bandwidth consumption, because a single stream is sent to many devices, rather than sending a single stream to a single device every time that this stream is requested.
This multicast delivery feature is enabled by setting up a multicast address on the Content Engine to which different devices, configured to receive content from the same channel, can subscribe. The delivering device sends content to the multicast address set up at the Content Engine, from which it becomes available to all subscribed receiving devices.
To configure a standalone Content Engines to use unicast-in multicast-out to relay live WMT streams to WMT clients, follow these steps:
Step 1
ContentEngine(config)# wmt multicast station-configuration test1 239.33.33.33 3333 mms://172.16.30.31/source.asf play-foreverContentEngine(config)#In this example a multicast station named test1 is configured and used by the Content Engine as the multicast source file. Its Class D IP address is 239.33.33.33, and the multicast port is 3333. The play-forever option is used. When the input source.asf file is a VOD file, this option automatically restarts playback of the file from the beginning of the source.asf file once the end of this file has been reached.
Note
Step 2
ContentEngine# wmt multicast-station start test1ContentEngine#Step 3
Step 4
http://ContentEngineIPaddress/test1.nscStep 5
The WMT media player should retrieve the multicast description .nsc file and join the multicast station that is specified in Step 1.
Note
Defining WMT Multicast Stations and Multicast Schedules on Standalone Content Engines
To configure a WMT multicast station on a standalone Content Engine, use the wmt multicast station-configuration global configuration command.
Note
The wmt multicast station-configuration name dest_addr dest_port media_source command specifies a multicast station name, a multicast IP address, port number, and media source for the multicast station created. Each WMT multicast station needs a multicast IP address. You must enter a valid Class D IP address multicast address in the range 224.0.0.0 to 239.255.255.255, except for the reserved IP ranges based on RFC 1700 and related documents as follows:
•
•
•
•
Note
The destination port of the WMT multicast station is specified by the dest_port option. Valid options are 1 through 65535. However, the multicast-enabled network may impose certain restrictions on your choice of port. Normally, port numbers below 1024 should be avoided, but the Content Engine does not enforce any restrictions.
The media_source option determines the source of the multicast. The source can be any valid WMT URL. In other words, if you can play the URL on your Windows Media Player, then you can make this URL the source of your multicast.
The play-forever option configures the stream to loop and restart. The default is to play the stream once and stop.
For example:
ContentEngine(config)# wmt multicast station-configuration acme 239.33.33.33 3333 mms://172.16.30.31/source.asf play-foreverwhere:
•
•
•
•
To configure multicasting schedules for WMT multicast stations, use the wmt multicast schedule-start EXEC command. The schedule-start name minute hour day month option creates a scheduling option to allow the Content Engine to start a multicast at a specified time. The wmt multicast schedule-start EXEC command only works if you have configured a multicast station first, using the wmt multicast station-configuration global configuration command.
wmt multicast {schedule-start name minute hour day month |
station-configuration name dest_addr dest_port media_source [play-forever] [unicast-url url] | time-to-live ttl}Table 7-9 describes the command parameters.
Starting and Stopping WMT Multicast Stations
To start or stop particular WMT multicast stations on a standalone Content Engine, use the wmt multicast-station EXEC command.
wmt {multicast-station {start name | stop name}
Table 7-10 describes the command parameters.
The following examples demonstrate the start and stop options on the multicast station named acme.
ContentEngine# wmt multicast-station start acmeContentEngine# wmt multicast-station stop acmeConfiguring Standalone Content Engines to Unicast Live WMT Streams
You can configure standalone Content Engines to relay live content to WMT clients through multicasting or unicast. This section describes how to configure standalone Content engines to relay live content through unicast, as follows:
•
•
These sections also describe how to configure a WMT broadcast alias on a standalone Content Engine for unicast-out.
For information about how to configure standalone Content Engines to relay live content to clients through multicasting, see the "Configuring Standalone Content Engines to Multicast Live WMT Streams" section.
Configuring Multicast-In Unicast-Out on Standalone Content Engines
The multicast-in unicast-out feature enables you to create a broadcasting publishing point to deliver an incoming stream live to requesting clients using multicast as the source of the streaming media. Use the wmt broadcast {alias-name name source url} global configuration command to configure a multicast-in unicast-out broadcast on a standalone Content Engine. With this command, you create a broadcasting alias to deliver an incoming stream live to requesting clients, using multicast as the source of the streaming media.
In this scenario, a unicast-out publishing point is created to deliver the incoming stream live to requesting clients.
To configure a standalone Content Engines to use multicast-in unicast-out (unicasting out) to relay live WMT streams to WMT clients, follow these steps
Step 1
ContentEngine(config)# wmt broadcast alias-name myunicast source http://172.16.30.31/station.nscContentEngine(config)#In this step a unicast publishing point with the alias name myunicast is configured with a multicast source station.nsc file. This source is a server sending out WMT multicast streams. The source of an alias in the format http://server/file.nsc signals the Content Engine to treat this source as a multicast input source.
Step 2
Step 3
mms://ContentEngineIPaddress/myunicastStep 4
The WMT media player should receive the MMS media source file specified in Step 1. Note that in this scenario an MMS URL is used to access the streaming media, and that only the alias name is specified instead of the *.nsc files as in the multicast-out scenarios.
This converts the multicast stream to unicast and sends it to the requester (the WMT client).
Configuring Unicast-In Unicast-Out on Standalone Content Engines
The unicast-in unicast-out feature provides a point-to-point connection between the client and the Content Engine. The advantage of unicasting when streaming media over a network is that only a single stream needs to be pulled over the network between the origin server and Content Engine, but that stream can be delivered to multiple clients in a nonmulticast environment. A server running Windows Media Services can provide a unicast video stream to multiple clients through a single stream delivered to the Content Engine. Unicast-in unicast-out is typically used to broadcast live events.
In this scenario, unicast-in unicast-out provides a point-to-point connection between the client and the Content Engine. The Content Engine in turn makes a single connection to the media server. Multiple requests for the same stream can be split by the Content Engine so that each client receives a distinct data stream directly from the Content Engine, while the Content Engine maintains its single stream connection to the media server.
The two ways to configure unicast-in unicast-out are:
•
•
To configure a standalone Content Engine to use unicast-in unicast-out (unicast out) to relay live WMT streams to clients, follow these steps:
Step 1
Step 2
Step 3
Step 4
Step 5
<protocol>://server-name:port-num/path/file-namewhere:
•
•
•
•
For example:
mms://wms.company.com/cotvwhere wms.company.com is the name of the Windows Media Server, and cotv is the name used when the broadcast alias is created. The MMS protocol is used to retrieve the stream.
Step 6
Step 7
mms://ContentEngineIPaddress/broadcast1where
•
•
Step 8
The WMT player should receive the MMS media source file specified in Step 5. Note that in this scenario, an MMS URL is used to access the streaming media, and that only the broadcast alias (for example, broadcast1) is specified instead of the *.nsc files in the multicast-out scenarios. This converts the multicast stream to unicast and sends it to the WMT client.
Configuring the Maximum Number of Concurrent Sessions
To configure the maximum number of unicast clients that a standalone Content Engine can support concurrently, use the wmt max-concurrent-sessions global configuration command.
wmt max-concurrent-sessions number
where:
•
•
Clearing WMT Streams on Standalone Content Engines
Three Content Engine CLI commands allow you to clear WMT streams on a standalone Content Engine. Table 7-11 describes these three commands.
In ACNS 5.2 software, the error logs were enhanced to log an error message when WMT streams are cleared and the associated processes are stopped on the Content Engine. For more information, see the "Logging the Clearing of WMT Streams on Standalone Content Engines" section.
Using WMT Multicast Logging
WMT logs are logged to a working log on the local disk in one of the following files, depending upon where the sysfs is mounted on the Content Engine:
•
•
Use the log option of the wmt multicast station-configuration global configuration command to provide a log of multicast statistics to multicast server administrators. These statistics include the multicast IP address, port number, start time, and number of clients, among other things. When configuring this option, you have the choice to provide either a local URL where the multicast logging statistics can be sent, or an external fully qualified server URL that can receive these statistics. In other words, the multicast logging URL option can point to the multicast server itself or to any web server that is capable of processing the posted information from the users who subscribed to the multicast address.
wmt multicast {station-configuration name dest_addr dest_port media_source [log {local | webserver webserver_url}]}where:•
•
•
•
•
•
•
•
The following example displays the multicast logging statistics sent to the multicast server.
10.1.101.2 2003-05-11 13:39:21 - asfm://233.0.4.5:4000 0 30 1 200 {5DC90EEB-CEB1-467C-9F7A-BCF5EEEDE3FF} 10.1.0.3055 en-US - - wmplayer.exe 10.1.0.3055 Windows_2000 10.0.0.2195 Pentium 0 152543 65389 asfm UDP WINDOWS_MEDIA_AUDIO_V2 MICROSOFT_MPEG-4_VIDEO_CODEC_V3 http://172.16.192.91/cisco.nsc - 166245 - 176 0 0 0 0 0 01 0 100 233.0.4.5 - - -The format of the example shown is as follows:
c-ip date time c-dns cs-uri-stem c-starttime x-duration c-rate c-status c-playerid c-playerversion c-playerlanguage cs(User-Agent) cs(Referer) c-hostexe c-hostexever c-os c-osversion c-cpu filelength filesize avgbandwidth protocol transport audiocodec videocodec channelURL sc-bytes c-bytes s-pkts-sent c-pkts-received c-pkts-lost-client c-pkts-lost-net c-pkts-lost-cont-net c-resendreqs c-pkts-recovered-ECC c-pkts-recovered-resent c-buffercount c-totalbuffertime c-quality s-ip s-dns s-totalclients s-cpu-util CE-action CE-bytes UsernameTable 7-12 describes the fields shown in this example.
Using WMT Transaction Logging with Standalone Content Engines
For certain companies, streaming media is a source of revenue and therefore needs to be tracked closely. Because these companies charge their customers to stream on-demand content and live broadcasts, they must rely on logged information to track what content a particular customer viewed, how long they viewed it, and the viewing quality. Consequently, the accuracy and reliability of transaction logging is very important to these companies.
The Windows Media Services 9 Series provides a more robust logging model than Windows Media Services Version 4.1. In ACNS 5.2 software, support for Windows Media Services 9 logging was added.
In ACNS 5.2 software, the following logging formats are supported for WMT transaction logging:
•
•
•
•
Note
The extended versions of the logging formats are extensions to the standard logging format and contain additional fields that are Content-Engine specific (for example, the CE-action field that specifies whether it was a cache hit or miss, and the CE-bytes field that specifies the number of bytes that were sent out from the Content Engine.
The Content Engine's transaction logging format for WMT streaming is consistent with that of the Windows Media Services and the World Wide Web Consortium (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. When transaction logging is enabled, daemons create a separate working.log file in /local1/logs/export for WMT transactions.
All client information in the transaction logs is sent to the origin server by default.
Log Formats Accepted by Windows Media Services 9
Windows Media Players connect to a Windows Media server using the following protocols:
•
•
Depending on the version of the Windows Media Player, logs are sent in different formats, such as text, binary, or Extensible Markup Language (XML). See Table 7-13.
In ACNS 5.2 software, support for Extensible Markup Language (XML) logging for MMS-over-HTTP was added. The posted XML log file from the Windows Media Player to the Content Engine (Windows Media server) can be parsed and saved to the normal WMT transaction logs that are stored on the Content Engine. MMS-over-RTPS (RTSP over Windows Media Services 9) is currently not supported in ACNS software.
Specifying the Format of the WMT Transaction Logs on Standalone Content Engines
In ACNS 5.2 software, the wmt transaction-logs format global configuration command was added.
ContentEngine(config)# wmt transaction-logs format ?extended WMT extended transaction log configurationwms-41 Windows Media Services 4.1 loggingwms-90 Windows Media Services 9.0 loggingTo specify the format for the WMT transaction logs on standalone Content Engines, use the wmt transaction-logs format global configuration command. By default, the standard Windows Media Services 4.1 logging format is used (no Content Engine-specific details are logged).
wmt transaction-logs format {extended {wms-41 | wms-90} | wms-41 | wms-90}
Table 7-14 describes the command parameters.
In order to log the username to the WMT transaction log, you must enable the extended WMT logging feature on the Content Engine by entering the wmt extended transaction-log enable global configuration command. For more information, see the next section, "Enabling the Logging of Usernames to the WMT Transaction Log."
Enabling the Logging of Usernames to the WMT Transaction Log
If the Content Engine is configured to use the extended format of WMT transaction logging and the extended WMT logging feature is enabled, then the Content Engine logs usernames for any authenticated WMT requests. Usernames are logged not only for NTLM authentication but also for Negotiate, Digest, and basic authentication.
Note
By default, the extended WMT logging feature is disabled. If the extended logging format is enabled (using the wmt transaction-logs format extended global configuration command) but the extended WMT logging feature is disabled, the username field in the WMT transaction log will be empty.
To enable the logging of usernames for any authenticated WMT request on standalone Content Engines, follow these steps:
Step 1
Step 2
Content Engine(config)# wmt extended transaction-log enable
Using WMT Error Logging with Standalone Content Engines
In ACNS 5.2 software, WMT error logging was enhanced. More information is now logged about the following events:
•
•
Error logs are in the same format and location as syslogs. The WMT log messages are logged to /local1/errolog/wmt_errorlog.current.
You can configure the Content Engine for WMT error logging by using the debug wmt error EXEC command. This command debugs WMT level 1 functionality.
ContentEngine# debug wmt error ?client-ip Debug request from a specific clientserver-ip Debug request to a specific serverwhere:
•
•
There is also a debug wmt trace EXEC command that debugs WMT level 2 functionality (show error and trace). Content Engine performance is affected when you run the debug wmt trace command. Consequently, we recommend that the debug wmt trace command be used only at the direction of Cisco Systems technical support personnel.
Logging WMT Client Disconnects
When a WMT client is disconnected abruptly, the following information is logged in ACNS software error logs:
•
•
Logging the Clearing of WMT Streams on Standalone Content Engines
In ACNS 5.2 software, the error logs were enhanced to log a message when WMT streams are cleared and the associated processes are stopped on the Content Engine.
See Table 7-11 for a description of the Content Engine CLI commands, which you can use to clear WMT streams on a standalone Content Engine and which result in a message being sent to the error logs.
