-
Cisco ACNS Software Caching and Streaming Configuration Guide, Release 5.1
-
Index
-
Title Page
-
Preface
-
Chapter 1: Introduction
-
Chapter 2: Understanding the Basics
-
Chapter 3: Content Engine Configuration Overview
-
Chapter 4: Transparent Caching
-
Chapter 5: Proxy-Style Caching
-
Chapter 6: Reverse Proxy Caching
-
Chapter 7: Configuring Login Authentication and Authorization
-
Chapter 8: Configuring Content Authentication and Authorization
-
Chapter 9: Configuring a Primary Proxy Server
-
Chapter 10: Configuring Caching Protocols
-
Chapter 11: Configuring Content Service Protocols
-
Chapter 12: Configuring Streaming Media Services
-
Chapter 13: Configuring URL Filtering
-
Chapter 14: Configuring the Rules Template
-
Chapter 15: Creating and Managing IP Access Control Lists
-
Chapter 16: Configuring TCP Stack Parameters
-
Chapter 17: Monitoring and Troubleshooting
-
Appendix A: Content Engine GUI Menu Options
-
Appendix B: Web Cache Communication Protocol Version 1
-
Appendix C: Web Cache Communication Protocol Version 2
-
Table Of Contents
Configuring Streaming Media Services
About Licenses for Streaming Media Services
Live Streaming with the Cisco Streaming Engine
Configuring RTSP Services on a Locally Deployed Content Engine
Configuring and Enabling the Cisco Streaming Engine
Configuring and Enabling RealSubscriber
Configuring and Enabling RealProxy Caching
Enabling Transparent Caching of RTSP Traffic to RealProxy Using WCCP-Enabled Routers
Enabling Conventional Proxy Caching of RTSP Traffic to RealProxy
Configuring WMT Services on a Locally Deployed Content Engine
Adding or Removing WMT MMS Allowed Filename Extensions
Configuring WMT Parameters with CLI Commands
Enabling WMT on a Locally Deployed Content Engine
Configuring WMT Proxy Settings
Enabling Transparent WMT Service Using WCCP-Enabled Routers
Enabling Conventional WMT Proxy Service
Using WMT Broadcast and Multicast CLI Commands
Configuring WMT Multicast Station Schedules
Starting and Stopping WMT Multicast Stations
Configuring Unicast-In Multicast-Out
Configuring Multicast-In Multicast-Out
Configuring Multicast-In Unicast-Out
Configuring Unicast-In Unicast-Out
Configuring Streaming Media Services
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 RealNetworks RealMedia, Microsoft Windows Media Technologies (WMT), and Apple QuickTime.
This chapter describes how to configure these streaming media services on a locally deployed Content Engine. This chapter contains the following sections:
•
Configuring RTSP Services on a Locally Deployed Content Engine
•
Note
For complete syntax and usage information for the CLI commands used in this chapter, refer to the Cisco ACNS Software Command Reference, Release 5.1. For information about how to use the Content Distribution Manager GUI to centrally configure these services on a Content Engine, refer to the Cisco ACNS Software Deployment and Configuration Guide, Release 5.1.
Usage Guidelines
This section provides some usage guidelines regarding the configuration of streaming media services on a locally deployed Content Engine. It includes the following topics:
•
About Licenses for Streaming Media Services
Before enabling licenses for streaming media services on the Content Engine, make sure 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 command to display the system clock. To set the system clock, use the clock set EXEC command.
Note
About RTSP Media Services
Real-Time Streaming Protocol (RTSP) is a standard Internet streaming control protocol (RFC 2326). It is a widely used application-level protocol that controls the delivery of data with real-time properties, such as video and audio. Apple QuickTime, RealNetworks, and the Cisco Streaming Engine use RTSP as a streaming control protocol.
Live Streaming with the Cisco Streaming Engine
ACNS 5.1 software introduces support for handling live streaming content with all kinds of network topologies and deployment scenarios. This feature allows the integration of streaming content from Cisco IP/TV Servers and QuickTime live Broadcast Servers.
Use the rtsp server cisco-streaming-engine broadcast port-list command to define the UDP ports you want the locally deployed Content Engine to use for sending and receiving the streaming content. Use the rtsp server cisco-streaming-engine broadcast id command to define a specific configuration.
Use the rtsp server cisco-streaming-engine broadcast port-list command to define the UDP ports you want the Content Engine to use for sending and receiving the streaming content. Use the rtsp server cisco-streaming-engine broadcast id command to define a specific configuration.
Three different source types are supported and two different destination types, for a total of six different configurations, as shown below:
•
–
–
•
–
–
•
–
–
A UDP source is an external streaming server such as the Cisco IP/TV Broadcast Server that is sending the stream through UDP to the Content Engine. You must correctly configure the streaming server, along with all other necessary component in the network, so that it is sending out the stream regardless of whether a Content Engine or other host is actually tuned into that stream. The UDP source can be unicast or multicast.
When using the destination-udp option of the rtsp server command, the live program proactively sends the stream to the destination using UDP. The stream, in turn, can be accessed by a live program with a UDP source. Currently, only a multicast UDP destination is supported. The UDP destination automatically provides the RTSP request access point as well.
An RTSP source is a fully qualified RTSP URL that references an external streaming server such as a parent Content Engine, which provides the corresponding RTSP request point. When the destination-pull option of the rtsp server command is used, the live program relays its source to a published RTSP program, which can be accessed using an RTSP URL, corresponding to the RTSP source above.
For UDP streams, the HTTP URL provides access to the Session Description Protocol (SDP) file for the stream, which must be published by the external streaming server. In a typical scenario, the external streaming source is sending two streaming tracks (audio and video) to the Content Engine on two different ports.
When the destination is UDP multicast, this automatically provides the RTSP access point.
About the ACNS RTSP Gateway
The ACNS RTSP gateway is not an RTSP-based streaming server. Rather, it is a process running on the Content Engine that accepts an RTSP request and performs the initial RTSP handshake with RTSP-based clients (RealMedia, QuickTime, and so on) on behalf of the RTSP-based streaming servers available on the Content Engine. From information derived from the initial handshake operation, the RTSP gateway queries the URL filtering, rules, authentication, and unified name space (UNS) daemons to determine whether or not the content is pre-positioned.
After successful completion of uniformity checks, the RTSP gateway tunnels the request to the appropriate streaming media server on the Content Engine. It can tunnel the request to the RealServer, RealProxy, or Cisco Streaming Engine on the Content Engine, depending on the requested media type, the media server that is currently enabled, and the player agent that is requesting the content.
After the RTSP gateway tunnels the request to a particular media server and the media server and client negotiate the UDP ports, it 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.
The RTSP gateway daemon listens on the standard RTSP port (default port 554) and funnels incoming RTSP traffic through it to create uniform naming, authentication and authorization, rules-based implementation, and URL filtering. The RTSP gateway is always enabled and cannot be disabled by a command. 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.
•
•
•
•
•
Note
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 RealProxy software is configured with the RealAdministrator GUI, accessed from the RealProxy window of the Content Engine GUI. Detailed configuration, statistics, and reporting of RealProxy status are obtained through the RealAdministrator GUI.
A RealProxy window has been added to the Content Engine management GUI (Figure 12-1). 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 username and password to access this administration window from the Content Engine GUI.
Note
Configuring RTSP Services on a Locally Deployed Content Engine
This section describes how to configure RTSP services on a locally deployed Content Engine. It includes the following topics:
•
•
•
Note
Configuring the RTSP Gateway
To configure the RTSP gateway parameters on a locally deployed Content Engine, use the rtsp {ip-address ip-address | l4-switch enable | port incoming port} command.
Table 12-1 describes these parameters of the rtsp ip-address global configuration command.
To use the CLI to configure RTSP gateway parameters on a locally deployed Content Engine, follow these steps:
Step 1
ContentEngine(config)# rtsp port incoming portnumber
Step 2
ContentEngine(config)# rtsp ip-address ip-addressStep 3
ContentEngine(config)# rtsp l4-switch enable
Configuring and Enabling the Cisco Streaming Engine
ACNS 5.x software includes support for a standard RTSP server, also known as the Cisco Streaming Engine solution, for RTSP streaming media protocol.
Note
To configure Cisco Streaming Engine parameters on a locally deployed Content Engine, use the rtsp server cisco-streaming-engine global configuration command.
rtsp server cisco-streaming-engine {broadcast port-list list-num port-num [port-num] | id id source {source-udp url srce-ip-addr recv-ip-addr recv-port-list-num track-count 1-4 | source-rtsp rtsp-url track-count 1-4} destination destination-pull | destination-udp ttl dest-ip-addr list-num}
Table 12-2 describes the parameters for the rtsp server cisco-streaming-engine command.
Configuration Examples
The following examples illustrate the various scenarios supported using the Cisco Streaming Engine for live streaming support, which is introduced in ACNS 5.1 software.
Example 1
In this example, the source is UDP unicast, with the server proactively streaming content.
ContentEngine2(config)# rtsp server cisco-streaming-engine broadcast port-list 1 21112 21114ContentEngine2(config)# rtsp server cisco-streaming-engine broadcast id p1 source source-udp http://172.19.227.80/17902.sdp 172.19.227.78 0.0.0.0 1 track-count 2 destination destination-udp 1 239.2.2.101 1The ID of the stream is p1. The destination is UDP multicast, which automatically provides the RTSP access point. That is, users can access the stream with: rtsp://ContentEngine2.cisco.com/p1.sdp
Example 2
In this example, the source is a client-initiated RTSP unicast. The destination is UDP multicast, as in the previous example.
ContentEngine1(config)# rtsp server cisco-streaming-engine broadcast port-list 2 22222 22224ContentEngine1(config)# rtsp server cisco-streaming-engine broadcast id p2 source source-rtsp rtsp://172.31.150.162:550/cse_live/ucast/p1.sdp track-count 2 destination destination-udp 2 239.2.2.102 2Example 3
In this example, the source is a push UDP unicast, as in the first example. The destination is a client-initiated RTSP unicast. This configuration is useful in situations where you do not want push UDP streaming to waste network bandwidth.
ContentEngine2(config)# rtsp server cisco-streaming-engine broadcast port-list 3 23332 23334ContentEngine2(config)# rtsp server cisco-streaming-engine broadcast id p3 source source-udp http://172.19.227.80/3861.sdp 172.19.227.78 0.0.0.0 3 track-count 2 destination destination-pullExample 4
In this example, the source is a client-initiated RTSP unicast, which is the same as in the second example. The destination is a client-initiated RTSP unicast.
ContentEngine1(config)# rtsp server cisco-streaming-engine broadcast id p4 source source-rtsp rtsp://172.31.150.162:550/cse_live/ucast/p2.sdp track-count 2 destination destination-pullExample 5
In this example, the source is a proactively streaming UDP multicast and the receiving IP address is a multicast IP address. This means that the Content Engine is receiving the stream from the same external source as in the first example, but the server is now sending a multicast to the network instead of sending a unicast to the Content Engine. The destination is a client-initiated RTSP access point only, as in the third and fourth examples.
ContentEngine2(config)#rtsp server cisco-streaming-engine broadcast port-list 5 25552 25554ContentEngine2(config)#rtsp server cisco-streaming-engine broadcast id p5 source source-udp http://172.19.227.80/17902.sdp 172.19.227.78 239.2.2.240 5 track-count 2 destination destination-pullExample 6
The following example has the same source as in the previous example, but the destination is a proactively streaming multicast over UDP. Of course, the RTSP access point is still provided.
ContentEngine2(config)#rtsp server cisco-streaming-engine broadcast port-list 6 26662 26664ContentEngine2(config)#rtsp server cisco-streaming-engine broadcast id p6 source source-udp http://172.19.227.80/17902.sdp 172.19.227.78 239.2.2.240 6 track-count 2 destination destination-udp 239.2.2.102 2Configuring and Enabling RealSubscriber
ACNS 5.1 software includes RealServer Version 9 as an optional component that is used as a streaming media engine. When RealServer software is configured for subscriber-only mode, it is referred to as RealSubscriber.
To configure RealSubscriber on a locally deployed Content Engine, use the rtsp server real-subscriber global configuration command.
rtsp server real-subscriber {accept-license-agreement | drm {accept-license-agreement | enable | evaluate | license-key keyword}| enable | evaluate | license-key keyword}
Table 12-3 describes the parameters for the rtsp server real-subscriber command.
The following is an example of how to use the CLI to configure RealSubscriber parameters on a locally deployed Content Engine.
Step 1
ContentEngine# show rtsp server real-subscriber license-agreementStep 2
ContentEngine# configureContentEngine(config)# rtsp server real-subscriber enable accept-license-agreementStep 3
ContentEngine(config)# rtsp server real-subscriber license-key licensekeyAlternatively, use the real-subscriber evaluate command to accept a 60-day evaluation license.
ContentEngine(config)# rtsp server real-subscriber evaluateYou can accept a RealSubscriber evaluation license that allows you to use the licensed software for a limited period. The evaluation license can be invoked only once and does not require a license key. The evaluation license allows the licensed program to be enabled for 60 days.
When the preset evaluation time has elapsed, RealSubscriber is automatically disabled. You can purchase a valid license key from Cisco Systems and enter the license key into the configuration at any time during the evaluation period for uninterrupted use of RealSubscriber.
Step 4
ContentEngine(config)# rtsp server real-subscriber enable
Configuring and Enabling RealProxy Caching
RealProxy software is configured using the RealSystem administrator GUI, which is accessed from the RealProxy page of the Content Engine GUI (as described in Step 6 of this section).
To configure and enable RealProxy caching on a locally deployed Content Engine, follow these steps:
Step 1
ContentEngine# show rtsp proxy media-real license-agreementStep 2
ContentEngine# configureContentEngine(config)# rtsp proxy media-real accept-license-agreementStep 3
ContentEngine(config)# rtsp proxy media-real license-key licensekeyAlternatively, use the rtsp proxy media-real evaluate command to accept a 60-day evaluation license.
Step 4
ContentEngine(config)# rtsp ip-address ip-address
Tip
Step 5
ContentEngine(config)# rtsp proxy media-real enableNow that you have enabled RealProxy caching on the Content Engine, you can configure the RTSP parameters required for streaming media connections through RTSP traffic technologies by transparent caching or conventional caching.
Note
Step 6
a.
Note
Figure 12-1 Content Engine Real Proxy WIndow
Note
b.
c.
Figure 12-2 Real System Administrator GUI
Step 7
Enabling Transparent Caching of RTSP Traffic to RealProxy Using WCCP-Enabled Routers
During transparent caching, the user's network traffic flows through the WCCP-enabled router rather than through the Content Engine to access streaming media. To enable transparent redirection of RTSP traffic to the RealProxy server on a locally deployed Content Engine, you need the following:
•
•
•
•
To enable transparent redirection of RTSP traffic to the RealProxy server on a locally deployed Content Engine, follow these steps:
Step 1
Note
Step 2
Router(config)# ip wccp 80Step 3
Router(config)# interface Ethernet 0Step 4
Router(interface)# ip wccp 80 redirect outStep 5
ContentEngine(config)# wccp version 2Step 6
ContentEngine(config)# wccp rtsp router-list 1 172.16.25.25 172.16.26.26Step 7
ContentEngine(config)# wccp rtsp router-list-num 1Step 8
ContentEngine# copy running-config startup-configStep 9
For more information about the RealSystem administrator GUI, click Documentation in the RealSystem administrator GUI.
Enabling Conventional Proxy Caching of RTSP Traffic to RealProxy
During conventional proxy caching, the user's media player is pointed to the Content Engine rather than to a WCCP-enabled router to access streaming media. To configure conventional proxy caching of RTSP on a locally deployed Content Engine, you need the following:
•
•
•
•
To enable conventional proxy caching of RTSP to the RealProxy server on a locally deployed Content Engine, follow these steps:
Step 1
Note
Step 2
ContentEngine# rtsp port incoming portnumberStep 3
a.
b.
c.
d.
e.
f.
g.
h.
Step 4
The RealSystem Administrator Configuration window is shown in Figure 12-2.
RealPlayer is now able to use the Content Engine as a RealProxy server to fetch streaming objects.
Tip
Step 5
ContentEngine# copy running-config startup-config
RealProxy Considerations
Use the following sections to help you configure additional RealProxy features on a locally deployed Content Engine.
Disabling RealMedia Caching
The RealProxy player comes with a streaming media cache of its own for the replication of on-demand content. However, an administrator may wish to disable caching for various reasons:
•
•
•
To prevent caching of all material from all servers and the RealProxy, follow these steps:
Note
Step 1
Step 2
Step 3
Step 4
Step 5
Streaming On-Demand Clips
All on-demand clips are automatically available to the Content Engine. If there is content served by your RealServer that you do not want to be cached, see the "Disabling RealMedia Caching" section.
Unicasting, Splitting, and Multicasting
Live clips are not available to caching software; the RealProxy will still act as a proxy to deliver live broadcasts for clients. RealServer acts as a source for live splitting, and the RealProxy acts as a splitter.
Access Control
If a client requests a cached stream, the RealProxy sends the request to the source RealServer for permission before allowing the client to play the stream. If RealServer denies the request, the RealProxy does not allow the client to receive the stream.
You can block a single RealProxy from caching the material served by your RealServer by creating an access control rule from the RealSystem Administrator GUI that prohibits the IP address of that RealProxy from connecting to your RealServer. You can also restrict access to content based on the number of players and bandwidth.
The RealProxy cannot cache live broadcasts, because no actual downloadable file is there to cache. However, the RealProxy includes an ability to "share" live streams among clients and thus reduce the bandwidth required from a transmitter. RealServer and the RealProxy communicate through live splitting; RealServer is preconfigured to act as a transmitter, and the RealProxy is automatically set up to act as a receiver.
Note
RealProxy Examples
The following example displays RTSP request statistics. The statistics reported are the total number of requests served, the total number of cache hits and misses, the total demand pass-through, and the total number of live connections, either by splitting or by live pass-through.
ContentEngine# show statistics rtsp proxy media-real requestsMedia Cache Statistics - RequestsTotal % of Requests---------------------------------------------------Total Received Requests: 17 -Demand Cache Hit: 11 64.7Demand Cache Miss: 6 35.3Demand Pass-Through: 0 0.0Live Split: 0 0.0Live Pass-Through: 0 0.0The following example displays RTSP savings statistics. In this example, the statistics reported are the total number of requests served, the total number of cache hits and misses, the bytes delivered, and the savings incurred by caching.
ContentEngine# show statistics rtsp proxy media-real savingsMedia Cache Statistics - SavingsRequests Bytes-----------------------------------------------------------Total: 17 16666028Hits: 11 3656524Miss: 6 13009504Savings: 64.7 % 21.9 %ContentEngine#Configuring WMT Services on a Locally Deployed Content Engine
This section describes how to configure WMT services on a locally deployed Content Engine. It includes the following topics:
•
•
•
WMT Usage Guidelines
When configuring WMT streaming media services on a locally deployed Content Engine, note the following:
•
Note
•
Typically, proxy servers fail to serve a request for one of these reasons:
–
–
–
•
•
•
•
Adding or Removing WMT MMS 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.
Use the he wmt mms allow extension global configuration command to add file name extensions to this list. Use the no version of this command (no wmt mms allow extension) to remove a file name extension from the list.
The default list in the Content Engine contains the following file name extensions:
•
•
•
•
•
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 mms allow extension mp3ContentEngine(config)#You can use the show wmt mms allow extension EXEC command to see the file extensions included in the list after you add or delete file extensions.
Tip
This is an example of the show wmt mms allow extension command, where the default list of file extension is not modified:
ContentEngine# show wmt mms allow extensionContentEngine#This is an example of the show wmt mms allow extension command, after adding the file extension mp3 to the list of file extensions:
ContentEngine(config)# show wmt mms allow extensionWMT mms extensions allowed :asf mp3 none nsc wma wmvContentEngine(config)#Configuring WMT Parameters with CLI Commands
Use the wmt global configuration command to configure WMT parameters on a locally deployed Content Engine.
wmt accept-license-agreement
wmt bandwidth incoming bypass-list {ip-address | hostname} [ip-address | hostname]
wmt broadcast {alias-name name source url}
wmt cache {enable | max-obj-size size | unique-stream-key}
wmt disallowed-client-protocols [HTTP] [TCP] [UDP]
wmt enable
wmt evaluate
wmt fast-live-split enable
wmt fast-proxy-cache enable
wmt incoming number
wmt l4-switch enable
wmt license-key key
wmt live-url-stripping enable
wmt max-concurrent-sessions number
wmt mms {allow {extension { file name}}}
wmt multicast {schedule-start name minute hour day month | station-configuration name dest_addr dest_port media_source [log {local | webserver}] [play-forever] [unicast-url url] | time-to-live ttl}
wmt proxy outgoing {http | mms} host {hostname | ip-address} port
Table 12-4 describes the parameters of the wmt global configurations command that is used to configure WMT parameters on a locally deployed Content Engine.
See the following sections in this chapter for information about how to enable WMT, enable transparent redirection of MMS traffic, configure the Content Engine to service WMT clients as a WMT proxy, and enable WMT multicasting.
•
•
•
Enabling WMT on a Locally Deployed Content Engine
To enable WMT on a locally deployed Content Engine, follow these steps.
Note
Step 1
ContentEngine# show wmt license-agreementStep 2
ContentEngine# configureContentEngine(config)# wmt accept-license-agreementStep 3
ContentEngine(config)# wmt license-key licensekeyAlternatively, accept an evaluation license by using the wmt evaluate command.
ContentEngine(config)# wmt evaluateStep 4
ContentEngine(config)# wmt enableYou are now able to configure the WMT parameters required for streaming media connections through WMT by transparent caching or conventional proxy caching.
Note
Configuring WMT Proxy Settings
To configure WMT proxy settings on a locally deployed Content Engine use the wmt global configuration command.
Note
Step 1
ContentEngine(config)# wmt l4-switch enableEnables redirection with a Layer 4 switch, such as a Cisco CSS 11000 series switch.Step 2
ContentEngine(config)# wmt cache max-obj-size sizeStep 3
ContentEngine(config)# wmt proxy outgoing http host {hostname | ip-address} portwhere:
•
•
Step 4
ContentEngine(config)# wmt proxy outgoing mms host {hostname | ip-address} portwhere:
•
•
Enabling Transparent WMT Service Using WCCP-Enabled Routers
During transparent caching, the user's network traffic flows through the WCCP-enabled router rather than through the Content Engine to access streaming media. Before enabling transparent caching, be sure that you have fulfilled the following requirements:
•
•
•
•
To enable transparent redirection of MMS traffic to a locally deployed Content Engine, follow these steps:
Step 1
For more information on how to enable WMT, see the "Enabling WMT on a Locally Deployed Content Engine" section.
Step 2
Router(config)# ip wccp 81Router(config)# ip wccp 82
Note
Step 3
Router(config)# interface Ethernet 0Step 4
Router(interface)# ip wccp 81 redirect outRouter(interface)# ip wccp 82 redirect out
Note
Step 5
ContentEngine(config)# wccp version 2Step 6
ContentEngine(config)# wccp router-list 1 172.16.25.25 172.16.26.26Step 7
ContentEngine(config)# wccp wmt router-list-num 1Step 8
ContentEngine# copy running-config startup-configStep 9
Note
Figure 12-3 WMT Administration Page in Content Engine GUI
Step 10
ContentEngine# show statistics wmt all
Tip
Enabling Conventional WMT Proxy Service
During conventional proxy caching, the user's media player is pointed to the Content Engine rather than to a WCCP-enabled router to access streaming media. Before enabling conventional WMT proxy service, be sure you have fulfilled the following requirements:
•
•
•
•
To configure conventional WMT proxy service, follow these steps:
Step 1
For more information on how to enable WMT, see the "Enabling WMT on a Locally Deployed Content Engine" section.
Step 2
ContentEngine(config)# wmt incoming portnumberStep 3
a.
b.
c.
Figure 12-4 WMT Media Player Network Options Screen
d.
e.
Figure 12-5 Configure Protocol Window in WMT Media Player
f.
g.
h.
i.
Step 4
ContentEngine# copy running-config startup-configStep 5
•
•
Tip
Step 6
ContentEngine# show statistics wmt allThe displayed WMT statistics relate only to objects transported over MMS that were requested by a WMT client.
Note
Configuring WMT Multicasting
Based on the capabilities and limitations of the network, a Content Engine can receive and deliver WMT streaming content through IP multicast in these ways:
•
•
•
•
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.
The multicast-in multicast-out multicast receive feature enables you to receive multicast WMT streams delivered through IP multicasting, 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).
The multicast-in unicast-out scenario 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.
The unicast-in unicast-out scenario 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 client can request a stream that contains either stored or live content.
Note
Using WMT Broadcast and Multicast CLI Commands
Two global configuration CLI commands are needed to configure the Content Engine for the four WMT multicasting scenarios described in this section:
•
•
Note
Using WMT Broadcasting CLI Commands
Use the wmt broadcast {alias-name name source url} command to configure the multicast-in unicast-out broadcast scenario on the 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.
wmt broadcast {alias-name name source url}Using WMT Multicasting CLI Commands
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 the unicast-in multicast-out and multicast-in multicast-out scenarios on the Content Engine.
The station-configuration name dest_addr dest_port media_source option specifies a multicast station name, an IP multicast address, port number, and media source for the multicast station created. Each 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 allowed multicast port range defined by the dest_port option is 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.
ACNS 5.1 software has a new CLI global configuration command to configure the TTL for WMT multicast. Use the wmt multicast time-to-live ttl command to set the value for the TTL between 0 and 255 hops. The default is five hops.
Tip
Configuring WMT Multicast Station Schedules
To configure schedules for WMT multicast stations, use the wmt multicast schedule-start global configuration 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. This option only works if you have configured a multicast station first, using the wmt multicast station-configuration command.
Table 12-5 describes the wmt multicast schedule-start command.
Starting and Stopping WMT Multicast Stations
To start or stop particular WMT multicast stations, use the wmt multicast-station command in EXEC mode.
ContentEngine# wmt {multicast-station {start name | stop name}Table 12-6 describes the multicast station parameters for the wmt command.
The two following examples demonstrate the start and stop options on the multicast station named acme.
ContentEngine# wmt multicast-station start acmeContentEngine# wmt multicast-station stop acme
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 sysf is mounted on the Content Engine:
•
•
Use the wmt multicast log command to provide 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 {schedule-start name minute hour day month | station-configuration name dest_addr dest_port media_source [log {local | webserver}] [play-forever] [unicast-url url] | time-to-live ttl}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 12-7 describes the fields shown in this example.
Configuring Unicast-In Multicast-Out
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
To enable WMT multicasting for unicast-in multicast-out on a locally deployed Content Engine, follow these steps:
Step 1
ContentEngine(config)# wmt multicast station-configuration test1 233.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 233.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 play back 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://CEIPaddress/test1.nscStep 5
The WMT player should retrieve the multicast description .nsc file and join the multicast station that is specified in Step 1.
Note
Configuring Multicast-In Multicast-Out
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 enable WMT multicasting for multicast-in multicast-out on a locally deployed Content Engine, follow these steps:
Step 1
ContentEngine(config)# wmt multicast station-configuration test2 233.33.33.34 6667 mms://172.16.30.31/source.nscContentEngine(config)#In this example, a multicast station named test2 is configured and used by the Content Engine as the multicast source file. Its Class D 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 has been reached, unless the play-forever option is used.
Step 2
ContentEngine# wmt multicast-station start test2ContentEngine#Step 3
Step 4
http://CEIPaddress/test2.nscStep 5
The WMT player should receive the MMS media source specified in Step 1.
Configuring Multicast-In Unicast-Out
In this scenario, a unicast-out publishing point is created to deliver the incoming stream live to requesting clients.
To enable WMT multicasting for multicast-in unicast-out on a locally deployed Content Engine, 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://CEIPaddress/myunicastStep 4
The WMT player should receive the MMS media source 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 in the multicast-out scenarios.
This converts the multicast stream to unicast and sends it to the requesting client.
Configuring Unicast-In Unicast-Out
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 client can request a stream that contains either stored or live content.
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. Those clients can take advantage of the VCR-like controls in the Windows Media Player to pause the stream or to skip backward or forward (in the case of stored content [video on demand]).
There are two ways to configure unicast-in unicast-out:
•
•
To enable WMT services for unicast-in unicast-out on a locally deployed Content Engine, 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://CEIPaddress/broadcast1where
•
•
Step 8
The WMT player should receive the MMS media source 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 requesting client.
Removing the WMT License Key
The no wmt license-key global configuration command can be used to uninstall the WMT license key if it is no longer needed on the device because the WMT licensed product feature is not needed. After a license key is uninstalled on one device, it can be used on another device if that device supports the WMT license key.
Note
