Table Of Contents
Configuring Streaming Media Services
Licensing and Enabling Streaming Servers
Using the Real-Time Streaming Protocol Gateway
Configuring the RTSP Gateway
Enabling RealProxy
Enabling RealSubscriber
Enabling the Cisco Streaming Engine
Using Windows Media Technologies
Enabling WMT
Configuring WMT Proxy Settings
About Fast Start
About Fast Cache
Configuring WMT Live Splitting for Unicast and Multicast Transmissions
Live Stream Splitting Scenarios
Configuring Unicast-In Multicast-Out
Configuring Multicast-In Multicast-Out
Configuring Multicast-In Unicast-Out
Configuring Unicast-In Unicast-Out
Configuring WMT Station Schedules
Configuring Weighted Load Balancing for Live Stream Splitting
Related CLI Commands
Configuring Bandwidth Settings for Content Services
Configuring Content Services Default and Maximum Bandwidth Settings
Configuring Scheduled Bandwidth Settings
Displaying a Graphical Representation of the Content Service Bandwidth Settings
Configuring the WMT Incoming Bandwidth Bypass List
Configuring Streaming Media Services
Streaming media services enable the delivery of digital media directly to the end user from a point of origin such as an origin server, encoder, or Content Engine cache. Streaming media can be delivered as live content or it can be delivered 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), Apple QuickTime, and Cisco Streaming Engine.
This chapter discusses these supported streaming media services and explains how to enable these services on Content Engines in your ACNS network. This chapter contains the following sections:
•
Licensing and Enabling Streaming Servers
•
Using the Real-Time Streaming Protocol Gateway
•
Using Windows Media Technologies
•
Configuring Weighted Load Balancing for Live Stream Splitting
•
Configuring Bandwidth Settings for Content Services
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.
Licensing and Enabling Streaming Servers
In order for your ACNS network devices to be able to serve streaming media, you must tell the ACNS network that a particular streaming media service is present, and you must accept a licence agreement for each type of media service that you intend to use. Media services available in ACNS 5.x software include Windows Media Server, RealProxy, RealSubscriber, and multicast client.
Note
Cisco Streaming Engine does not require a separate license agreement.
You can accept license agreements at the device level or at the device group level. As soon as any license agreement has been accepted for any device or device group, the acceptance is applied to all devices that are currently registered to the Content Distribution Manager and to all devices that register in the future.
When a Content Distribution Manager is upgraded to ACNS 5.2 software, the Content Distribution Manager will apply any accepted license agreements from the previous ACNS software release to all registered devices in the network. If in a previous ACNS 5.x Release, you accepted a particular licence agreement on some, but not all, devices, any device for which the license was not accepted prior to the Content Distribution Manager upgrade will have its license agreement accepted automatically.
Note
You cannot remove a license agreement once it has been accepted. If there is a particular media type that you do not want to serve through your ACNS network, you need to disable the corresponding media player so that your ACNS network devices do not attempt to serve that media type.
Using the media player mappings in the manifest file, you can customize your content type mappings from MIME content types or file extensions to configured media players. See the "Working with Manifest Files" section for more information on configuring manifest files.
Note
Modifying the configuration of any media players causes any ACNS network devices running that media player software to restart and register the configuration change. Depending on the number and location of devices that restart following a media player configuration change, you may experience a temporary interruption in service for the time it takes your devices to come back online—usually a few minutes.
Before enabling licenses for streaming media services, make sure that the clock and calendar settings on the ACNS network device 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.
Using the Real-Time Streaming Protocol Gateway
The 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.
The RTSP gateway is a process running on the Content Engine that accepts an RTSP request and performs the initial RTSP contact 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 request operation, the RTSP gateway queries the URL filtering, rules, authentication, and unified name space (UNS) agents to determine whether or not the content is pre-positioned.
Note
Pre-positioned content requests are only accepted and served on the RTSP gateway (for both RealMedia and the Cisco Streaming Engine) default port number 554. If the default RTSP port number is changed to any other port number on the Content Engine while the Content Engine is waiting for RTSP pre-positioned content from the origin server, the Content Engine will be unable to serve the content.
The RTSP gateway is always enabled and cannot be disabled. Based on the properties of the incoming request, including such properties as user agent, final destination, and media file type, the RTSP gateway performs these tasks:
•
Forwards the incoming request to the RealProxy that resides on the same Content Engine as the RTSP gateway
•
Forwards the incoming request to the RealSubscriber that resides on the same Content Engine as the RTSP gateway
•
Forwards the incoming request to the Cisco Streaming Engine
•
Redirects the incoming request
•
Rejects the incoming request
To fulfill a client RTSP request for non-pre-positioned content, a Content Engine (CE1) forwards the request to the origin server. If the request is transparently intercepted by another Content Engine (CE2) on its way to the origin server, and the content is not pre-positioned on CE2, then the RTSP gateway application on CE2 issues an RTSP redirect response and adds a bypass entry in the WCCP bypass list.
The Content Engine can be configured to accept transparently redirected RTSP requests as well as traditional proxy-style RTSP requests from RealProxy client software. The RealProxy software is configured with the RealAdministrator GUI, accessed from the RealProxy window of the Content Engine management GUI. Detailed configuration, statistics, and reporting of RealProxy status are obtained through the RealAdministrator GUI.
To access the Content Engine management GUI from the Content Distribution Manager, choose Devices > Devices. Click the Edit icon next to the name of the Content Engine that you want to configure, and click the Run CE Cache GUI icon in the task bar. See the "Configuring the Content Engine GUI for Secure or Nonsecure Access" section on page 12-38.
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
You must configure disk space to include mediafs storage with the disk config EXEC command before you can run streaming media using RealProxy.
Configuring the RTSP Gateway
To configure RTSP gateway parameters, follow these steps:
Step 1
From the Content Distribution Manager GUI, choose Devices > Device Groups. If you have created device groups, the Device Group window appears. (Alternatively, choose Devices > Devices.)
Note
RTSP gateway parameters can be configured for individual Content Engines or for device groups. This procedure describes the steps for configuring RTSP gateway parameters for a device group.
Step 2
Click the Edit icon next to the name of the device group that you want to configure. The Contents pane appears on the left.
Step 3
From the Contents pane, choose Streaming/Caching > RTSP Gateway. The RTSP Gateway Settings window appears. (See Figure 9-1.) Table 9-1 describes the fields in this window and provides the corresponding CLI commands.
Figure 9-1 RTSP Gateway Settings Window
Step 4
Check the Enable check box so that you can configure the RTSP gateway settings. Unchecking this box does not disable RTSP.
Step 5
In the Incoming Port field, enter the port number used by the RTSP proxy to receive requests.
Step 6
In the IP-Address field, enter the IP address of the RTSP gateway. This is usually the Content Engine that is serving the requested content.
Step 7
Check the Enable L4 Switch Support check box to enable redirection using a Layer 4 switch.
Step 8
In the Maximum Initial Setup Delay field, specify the maximum delay allowed (in seconds) between TCP accept and the first RTSP message from the client. The default is 10 seconds.
Step 9
In the Maximum Request Rate field, specify the maximum number of incoming requests per second that the RTSP gateway allows. The default is 40 requests per second.
Table 9-1 RTSP Gateway Settings
GUI Parameter
|
Function
|
CLI Command
|
Incoming Port
|
Specifies the ports on which to listen for RTSP requests.
|
rtsp ports
|
IP-Address
|
Specifies the IP address of the RTSP gateway.
|
rtsp ip-address
|
Layer 4 Switch Support
|
Enables redirection with a Layer 4 switch, such as a Cisco CSS Series switch.
|
rtsp l4-switch enable
|
Maximum Initial Setup Delay
|
Maximum delay allowed (in seconds) between TCP accept and the first RTSP message from the client.
|
rtsp advanced max-initial-setup-delay seconds
|
Maximum Request Rate
|
Maximum number of incoming requests per second that the RTSP gateway allows.
|
rtsp advanced max-request-rate seconds
|
Enabling RealProxy
RealProxy is a licensed software program that requires the purchase of a license from Cisco. To enable this licensed software program, you must perform the following tasks:
•
Accept the license agreement.
•
Enter your Cisco license key or accept an evaluation license.
•
Enable the software program.
Before enabling licenses for streaming media services, make sure that the clock and calendar settings on the ACNS network device 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.
Note
RealProxy software is configured using the RealSystem administrator GUI, which is accessed from the RealProxy page of the Content Engine management GUI. To access the Content Engine management GUI from the Content Distribution Manager, choose Devices > Devices. Click the Edit icon next to the name of the Content Engine that you want to configure and click the Run CE Cache GUI icon in the taskbar.
To enable RealProxy for the devices in your ACNS network, follow these steps:
Step 1
From the Content Distribution Manager GUI, choose Devices > Device Groups. The Device Groups window appears. (Alternatively, choose Devices > Devices.)
Step 2
Click the Edit icon next to the name of the device group (or Content Engine) that you want to configure. The Contents pane appears on the left.
Step 3
From the Contents pane, choose Streaming/Caching > Real Networks > Real Proxy License.
The Real Proxy License Agreement window appears if you have not previously read and accepted the license agreement for any device or device group in the network. After you have read and accepted the terms of this agreement, check the Accept License check box at the bottom of this window and click Submit. The page refreshes itself, and the Real Proxy License Settings window appears. (See Figure 9-2.)
Note
Accepting the RealProxy license agreement for any Content Engine or device group enables the RealProxy license for all the devices in the network.
Figure 9-2 Real Proxy License Settings for Device Group Window
Note
The RealProxy License Settings for Content Engine window (Devices > Devices) does not list all the Content Engine models. It has one License Key field for the particular Content Engine that you chose.
Step 4
Check the Enable check box to activate the RealProxy license.
Step 5
To obtain a permanent license, enter a license key number in the field next to the Content Engine model which corresponds to the license key that you purchased.
Note
Because license keys are model-specific, the License Settings for Device Group window allows you to enter a license key for each model type in the group. This window is populated with input fields for each model type known to the Content Distribution Manager, even if there are no Content Engines of that type in the network. (The License Settings window for device groups reports the count for each Content Engine model in the device group and reports 0 [zero] if there are no devices of a particular type in the group.) This allows you to enter a license key for a device before it is registered. A field for an unknown device license key allows you to enter a license key for a Content Engine model type that is unknown to the Content Distribution Manager.
Alternatively, check the Evaluate check box to use a temporary 60-day license.
Step 6
Check the Validate check box to validate the license key that you entered.
Step 7
Click Submit to save the settings.
Enabling RealSubscriber
ACNS 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 called RealSubscriber. RealSubscriber is a licensed software program that requires the purchase of a license from Cisco. To enable this licensed software program, you must perform the following tasks:
•
Accept the license agreement.
•
Enter your Cisco license key or accept an evaluation license.
•
Enable the software program.
To enable RealSubscriber for the devices in your ACNS network, follow these steps:
Step 1
From the Content Distribution Manager GUI, choose Devices > Device Groups. The Device Groups window appears. (Alternatively, choose Devices > Devices.)
Step 2
Click the Edit icon next to the device group (or Content Engine) that you want to configure. The Contents pane appears on the left.
Step 3
Choose Streaming/Caching > Real Networks > Real Subscriber License.
The Real Subscriber License Agreement window appears if you have not previously read and accepted this license agreement for any device or device group in the network. After you have read and accepted the terms of this agreement, you must check the Accept License check box at the bottom of this window and click Submit. The page refreshes itself, and the Real Subscriber License Settings window appears. (See Figure 9-3.)
Note
Accepting the Real Subscriber License Agreement for any Content Engine or device group enables the Real Subscriber License for all the devices in the network.
Figure 9-3 RealSubscriber License Settings for Device Group Window
Note
The RealSubscriber License Settings for Content Engine window (Devices > Devices) does not list all the Content Engine models. It has one License Key field for the particular Content Engine that you chose.
Step 4
Check the Enable check box to activate a RealSubscriber license.
Step 5
To obtain a permanent license, enter a license key number in the field next to the Content Engine model which corresponds to the license key that you purchased.
Note
Because license keys are model-specific, the License Settings for Device Group window allows you to enter a license key for each model type in the group. This window is populated with input fields for each model type known to the Content Distribution Manager, even if there are no Content Engines of that type in the network. (The License Settings window for device groups reports the count for each Content Engine model in the device group and reports 0 [zero] if there are no devices of a particular type in the group.) This allows you to enter a license key for a device before it is registered. A field for an unknown device license key allows you to enter a license key for a Content Engine model type that is unknown to the Content Distribution Manager.
Alternatively, check the Evaluate check box to use a temporary 60-day license.
Step 6
Check the Validate check box to validate the license key that you entered.
Step 7
Click Submit to save the settings.
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
You do not need a license to use the Cisco Streaming Engine to deliver RTSP streaming media.
To configure Cisco Streaming Engine parameters, follow these steps:
Step 1
From the Content Distribution Manager GUI, choose Devices > Devices. The Devices window appears.
Step 2
Click the Edit icon next to the Content Engine that you want to configure. The Contents pane appears on the left.
Step 3
From the Contents pane, choose Streaming/Caching > Cisco Streaming Engine. (See Figure 9-4.)
Figure 9-4 Cisco Streaming Engine Settings Window
Step 4
Check the Enable check box to allow use of the Cisco Streaming Engine for RTSP streaming media delivery.
Step 5
Click Submit to save the settings.
Step 6
To override the device group settings applied to the device with the factory default settings, click the Override Group Settings with Defaults icon in the taskbar. This icon appears only if you have applied the device group settings to the Content Engine.
Using Windows Media Technologies
Microsoft Windows Media Technologies (WMT) is a set of streaming solutions for creating, distributing, and playing back digital media files across the Internet. WMT includes the following applications:
•
Windows Media Player—End user application
•
Windows Media Server—Server and distribution application
•
Windows Media Encoder—Encodes media files for distribution
•
Windows Media Codec—Compression algorithm applied to live or on-demand content
•
Window Media Rights Manager (WMRM)—Encrypts content and manages user privileges
Note
ACNS 5.1 software interoperates with WMT Version 9 Windows Media Player, Windows Media Encoder, Windows Media Codec, and Windows Media Server; however, the Content Engine does not provide the full functionality of Windows Media Server Version 9 and so cannot fully replace the server in this release.
ACNS 5.2 software supports the following:
•
WMT Version 9 live streaming from a Windows Media Encoder over a Microsoft Media Server (MMS)
•
Serving files encoded with the Version 9 codec
•
Streaming live or on-demand content to Windows Media Player Version 9
ACNS 5.2 software does not support serving a WMT file over RTP or RTSP, or authenticating against Windows Media Server Version 9 before serving a file.
Note
When you are using a Content Router for request redirection, pre-positioned WMT content requests can only be accepted and served on the WMT default port number 1755. If the default WMT port number is changed to any other port number on the Content Engine while the Content Engine is waiting for WMT pre-positioned content from the origin server, the Content Engine will be unable to serve the content.
Enabling WMT
To disseminate live and pre-positioned Windows Media content on an ACNS network, WMT caching proxy and server capabilities must be enabled on the Content Engine. WMT services is a licensed software program that requires the purchase of a license from Cisco. To enable this licensed software program, you must perform the following tasks:
•
Accept the license agreement.
•
Enter your Cisco license key or accept an evaluation license.
•
Enable the software program.
Note
You must configure disk space to include mediafs storage with the disk config EXEC command before you can run streaming media using WMT.
To enable WMT services for the devices in your ACNS network, follow these steps:
Step 1
From the Content Distribution Manager GUI, choose Devices > Device Groups. The Device Groups window appears. (Alternatively, choose Devices > Devices.)
Step 2
Click the Edit icon next to the device group (or Content Engine) that you want to configure. The Contents pane appears on the left.
Step 3
From the Contents pane, choose Streaming/Caching > WMT > License.
The WMT License Agreement for Content Engine window appears if you have not previously read and accepted this license agreement for any device or device group in the network. After you have read and accepted the terms of this agreement, check the Accept License check box at the bottom of this window and click Submit. The page refreshes itself, and the WMT License Settings window appears. (See Figure 9-5.)
Note
Accepting the WMT License Agreement for any Content Engine or device group enables the WMT License for all the devices in the network.
Figure 9-5 WMT License Settings Window
Note
The WMT License Settings for Content Engine window (Devices > Devices) does not list all the Content Engine models. It has one License Key field for the particular Content Engine that you chose.
Step 4
Check the Enable WMT Services check box to enable WMT.
Step 5
Check the Enable WMT Proxy check box to enable WMT caching proxy functionality.
Step 6
To obtain a permanent license, enter a license key number in the field next to the Content Engine model which corresponds to the license key that you purchased.
Note
Because license keys are model-specific, the License Settings for Device Group window allows you to enter a license key for each model type in the group. This window is populated with input fields for each model type known to the Content Distribution Manager, even if there are no Content Engines of that type in the network. (The License Settings window for device groups reports the count for each Content Engine model in the device group and reports 0 [zero] if there are no devices of a particular type in the group.) This allows you to enter a license key for a device before it is registered. A field for an unknown device license key allows you to enter a license key for a Content Engine model type that is unknown to the Content Distribution Manager.
Alternatively, check the Evaluate check box to use a temporary 60-day license.
Step 7
Check the Validate check box to validate the license key that you entered.
Step 8
To apply default settings click the Apply Defaults icon in the taskbar. The Reset button returns settings to the most recently saved settings.
Step 9
Click Submit to save the settings.
Configuring WMT Proxy Settings
The Content Engine acting as a WMT proxy supports a basic proxy feature—it accepts incoming WMT streaming requests from clients and acts on behalf of the clients communicating with an origin server. The WMT proxy accepts and serves streaming requests over the Microsoft Media Server (MMS) protocol as well as the HTTP protocol. (See Figure 9-6.) MMS is the protocol that WMT uses for communication between media players and servers.
Figure 9-6 Content Engine as Conventional WMT Caching Proxy
When possible, the WMT proxy also caches streaming content and serves the request from the Content Engine cache instead of from the origin server. It accepts transparently intercepted requests (through WCCP or Layer 4 [L4] redirect) as well as manual proxy requests (clients configured to use an upstream proxy).
The WMT proxy also supports multicasting and splitting of live streams (that is, it splits a single inbound feed to multiple clients).
Note
For MMS over TCP and UDP, the proxy always fetches the stream from a server using TCP (MMST), so that the item cached is reliable and complete for future delivery. Streams requested using HTTP will be fetched using HTTP.
To configure WMT proxy settings parameters, follow these steps:
Step 1
From the Content Distribution Manager GUI, choose Devices > Devices.
Step 2
Click the Edit icon next to the Content Engine that you want to configure. The Contents pane appears on the left.
Step 3
From the Contents pane, choose Streaming/Caching > WMT > General Settings. The WMT General Settings window appears. (See Figure 9-7 and Figure 9-8.) Table 9-2 describes the fields in this window and provides the corresponding CLI global configuration commands.
Figure 9-7 WMT Settings Window—WMT Proxy Settings
Step 4
Under the WMT Proxy Settings heading, check the Enable L4 Switch Support check box to enable redirection using a Layer 4 switch.
Step 5
Check the Enforce Max Object Size check box to allow the maximum size for an object to be cached.
Step 6
Enter a value (in megabytes) in the Max Object Size field. The range is from 1 to 1000000. The default value is 1024 megabytes.
Step 7
Check the Enable Outgoing HTTP Proxy check box to configure the outgoing MMS over HTTP proxy. Then enter the host name or IP address and the port number of the outgoing proxy. The port number range is 1 to 65535.
Step 8
Check the Enable Outgoing MMS Proxy check box to configure the outgoing MMS proxy. Then enter the host name or IP address and the port number of the outgoing proxy. The port number range is 1 to 65535.
Step 9
Check the Enable WMT Cache Optimization check box to enable caching performance improvement of the WMT proxy.
Step 10
Under the WMT General Settings heading, disable WMT traffic as desired.
•
Check the Disable HTTP WMT Traffic check box to disallow HTTP WMT traffic (streaming over http://).
•
Check the Disable TCP WMT Traffic check box to disallow TCP WMT traffic (mmst://).
•
Check the Disable UDP WMT Traffic check box to disallow UDP WMT traffic (mmsu://).
Step 11
In the Port to handle WMT Traffic field, enter the port number used by WMT to receive requests. The default port number used for WMT traffic is 1755.
Step 12
Specify the maximum number of concurrent sessions in the Maximum Concurrent Connections field. The default value is 3000 sessions.
Step 13
Check the Enforce Maximum Outgoing Bitrate check box to allow use of the maximum bit rate allowed for serving content.
Step 14
Specify the maximum bit rate allowed (in kilobytes per second) in the Maximum Outgoing Bitrate field.
Step 15
Check the Enforce Maximum Incoming Bitrate check box to allow use of the maximum incoming bit rate allowed for receiving content.
Step 16
Specify the maximum bit rate allowed (in kilobytes per second) in the Maximum Incoming Bitrate field. (See Figure 9-8.)
Figure 9-8 WMT Settings Window—WMT General Settings
Step 17
Check the Enable Live URL Stripping check box to remove personalization information from the URL before using it for live splitting.
Step 18
Check the Use Unique Stream Key check box to allow the content to be identified by a unique identifier instead of a URL string. This feature is enabled by default.
Normally, a caching proxy uses the URL string as the content identifier, so that a cache hit occurs when the request URL matches the content URL. This is often unreliable, because some websites use dynamically generated URLs, which create different URL strings for the same content. When the URL string is used as the content identifier in this case, the likelihood of a cache hit is reduced.
The unique stream key produces an identifier that is based on domain name, file size, bit rate, and other content-specific properties. This identifier is almost always unique for a piece of content. Using the unique stream key feature increases the likelihood of a cache hit.
Step 19
Check the Enable Fast Live Split check box to enable performance improvement for WMT proxy live splitting. This feature is an extension to the performance improvement for the WMT proxy.
Step 20
Check the Enable Mms Allowed Extensions check box to make is possible to add to or delete from the list of permitted filename extensions.
The default list of filename extensions includes asf, none, nsc, wma, and wmv. The "none" filename extension has been included to enable the Content Engine to serve files without filename extensions, such as live encoder URLs. The nsc filename extension is used for multicast media files.
Step 21
Specify the list of allowable extensions for MMS in the Mms Allowed Extensions field. The default extensions are automatically entered in this list.
Step 22
To enable the Fast Start feature, check the Enable Fast Start Feature check box. (See the "About Fast Start" section.)
Step 23
In the Fast Start Max Bandwidth field, enter a value in kbps to limit the speed at which the client can receive data at the fast start stage. The range is 1-65535.
Step 24
To enable the Fast Cache feature, check the Enable Fast Cache check box. (See the "About Fast Cache" section.)
Step 25
In the Fast Cache Max Delivery Rate field, enter a value to limit the total bandwidth that a client can consume as fast cached data. The range is 1-65535.
The value is the number multiplied by the normal bit rate of the file. For example, if the file is encoded as 100 kbps and the maximum delivery rate for fast caching is configured as 5, the maximum playback speed would be 500 kilobits per second.
Step 26
Under WMT Multicast Settings, enter the number of hops to live for multicast WMT packets. The default is 5 hops. The range is 0 to 255 hops.
For clients that are many router hops away from Content Engines functioning as multicast stations, the requested content is sometimes not delivered even though the delivering device has sent the content to the multicast address configured on the Content Engine. In such cases, configure a larger number of hops to allow a longer Time To Live for multicast packets being delivered to the Content Engine.
Step 27
Click Submit to save the settings.
Table 9-2 WMT General Settings Window
GUI Parameter
|
Description
|
CLI Command
|
WMT Proxy Settings
|
|
|
Enable L4 Switch Support
|
Enables redirection with a Layer 4 switch, such as a Cisco CSS 11000 series switch.
|
wmt l4-switch enable
|
Enforce Max Object Size
|
Enforces use of the maximum object size.
|
|
Max Object Size (MB)
|
Specifies the maximum allowable size of streaming media objects in megabytes (MB).
|
wmt cache max-obj-size
|
Enable Outgoing HTTP Proxy
|
Enables the use of outgoing MMS-over-HTTP.
|
wmt proxy outgoing http
|
Host Name
|
Host name or IP address of the outgoing HTTP proxy.
|
wmt proxy outgoing hostname
|
Port
|
Port of the outgoing proxy (the standard port is 1755).
|
wmt proxy outgoing ipaddress port
|
Enable Outgoing MMS Proxy
|
Enables use of outgoing MMS.
|
wmt proxy outgoing mms
|
Host Name
|
Host name or IP address of the outgoing MMS proxy.
|
wmt proxy outgoing mms hostname
|
Port
|
Port of the outgoing proxy.
|
wmt proxy outgoing mms ipaddress port
|
Enable WMT Cache Optimization
|
Enables caching performance improvement of the WMT proxy.
|
wmt accelerate proxy-cache enable
|
WMT General Settings
|
|
|
Disable HTTP WMT Traffic
|
Disallows HTTP (streaming over http://).
|
wmt disallowed-client-protocols HTTP
|
Disable TCP WMT traffic
|
Disallows TCP (mmst://).
|
wmt disallowed-client-protocols TCP
|
Disable UDP WMT Traffic
|
Disallows UDP (mmsu://).
|
wmt disallowed-client-protocols UDP
|
Port to handle WMT Traffic
|
Port number used by WMT to receive requests, (1-65535). If a particular port is not specified, port 1755 is used as the default.
|
wmt incoming port_num
|
Maximum Concurrent Connections
|
Maximum number of unicast clients that can be served. The range depends on the physical limitations of the platform. The default value is 2500.
|
wmt max-concurrent-sessions num
|
Enforce Maximum Outgoing Bitrate
|
Enforces the maximum stream bit rate that can be served.
|
—
|
Maximum Outgoing Bitrate (kbps)
|
Maximum streaming bit rate that can be served. The range is 0 to 2147483647 kbps. There is no default value.
|
bitrate wmt outgoing max_bitrate
|
Enforce Maximum Incoming Bitrate
|
Enforces the maximum incoming bit rate for receiving content.
|
—
|
Maximum Incoming Bitrate (kbps)
|
Maximum streaming bit rate that can be received.
|
bitrate wmt incoming max_bitrate
|
Enable Live URL Stripping
|
Removes personalization information from the URL before using it for live splitting.
|
wmt live-url-stripping enable
|
Use Unique Stream Key
|
Allows the use of a content-specific unique identifier as the cache key rather than the URL string itself.
|
wmt cache unique-stream-key
|
Enable Fast Live Split
|
Enables performance improvements in live splitting for the WMT proxy.
|
wmt accelerate live-split enable
|
Enable Mms Allowed Extensions
|
Lets you add or remove permitted MMS extensions.
|
—
|
Mms Allowed Extensions
|
List of allowable extensions for MMS.
You can add or delete filename extensions from this list with the following restrictions:
• Each extension must be alphanumeric, with the first character in the extension being an alphabetic character.
• You cannot have more than 10 characters in a filename extension.
• You cannot add more than 20 filename extensions to the allowed list.
|
wmt allow extension mms
|
Enable Fast Start Feature
|
Enables Fast Start for MMS over HTTP only. (No RTSP support.)
|
wmt fast-start enable
|
Fast Start Max Bandwidth
|
Maximum bandwidth allowed per player when Fast Start is used to serve packets to this player.
|
wmt fast-start max-bandwidth kbits
|
Enable Fast Cache
|
Enables Fast Cache for MMS over HTTP only. (No RTSP support.)
|
wmt fast-cache enable
|
Fast Cache Max Delivery Rate
|
Maximum delivery rate allowed per player when Fast Cache is used to deliver packets to this player.
|
fast-cache-max-delivery-rate num
|
WMT Multicast Settings
|
|
|
Number of hops to live
|
Number of hops to live for multicast WMT packets. The default is 5 hops. The range is 0 to 255 hops.
|
wmt multicast time-to-live ttl
|
About Fast Start
Windows Media Player must buffer a certain amount of data before it can start rendering content. If clients are using Windows Media Player for Windows XP or a later version of the player, you can use Fast Start to provide data directly to the buffer at speeds higher than the bit rate of the content requested. This enables users to start receiving content more quickly. After the initial buffer requirement is fulfilled, on-demand and broadcast content streams at the bit rate defined by the content stream format.
Using Fast Start enables users to have a better experience when playing back the content. Users can fast-forward and rewind content without additional delay and rebuffering. A Windows Media Player that connects through broadband networks starts playing the content more quickly, making the experience much more like viewing a television program or listening to a radio broadcast. Users notice that server-side playlists streaming from your publishing point switch smoothly and seamlessly between content items. Additionally, the prebuffering of data makes the Windows Media Player resistant to playback errors due to lost packets or other network issues.
The increased bandwidth that the Fast Start feature initially uses to send data to the Windows Media Player can overburden a network if many players connect to the stream at the same time. To reduce the risk of network congestion caused by the Fast Start feature, you can limit the amount of bandwidth the Fast Start feature uses to stream to each player.
The Fast Start feature is only used by clients that connect to a unicast stream.
About Fast Cache
When used with the Windows Media Player 9 Series, Fast Cache provides a way to stream content to clients faster than the data rate specified by the stream format. For example, using Fast Cache, the server can transmit a 128-kilobit per second (kbps) stream at 700 kbps. The stream is still rendered in Windows Media Player at the specified data rate, but the client is able to buffer a much larger portion of the content before rendering it. This allows the client to handle variable network conditions without a perceptible impact on the playback quality of either on-demand or broadcast content.
This ability is useful in the following situations:
•
When the available network bandwidth of the client exceeds the required bandwidth of the content; for example, clients that use a cable modem, Digital Subscriber Line (DSL) connection, or corporate intranets
•
When the network connectivity is intermittent or has high latency; for example, wireless networks
•
When the quality of the content received is of paramount importance; for example, businesses that provide pay-per-view movies
Configuring WMT Live Splitting for Unicast and Multicast Transmissions
Splitting is a method of sending live data transmissions across the Internet to a proxy edge device. The live stream is then fanned out to multiple downstream clients using unicast or multicast. (See Figure 9-9.)
The WMT-enabled Content Engine acts as a proxy for the streaming server or broadcast server and replicates the stream to local users. Splitting the stream at the Content Engine proxy is better than splitting it at the server, because the proxy is closer to the clients, thereby potentially saving considerable network bandwidth between the client and the server.
Figure 9-9 Live Splitting
When a client requests a publishing point on a server (without specifying an ASF file), then the Content Engine dynamically creates an alias file that references the remote server. All further requests to that station are served by splitting the stream. Note that when the first client (Client 1) that requested the original stream disconnects from the network, the proxy continues to serve the other clients (Client 2 and Client 3), until all clients disconnect from the network.
Note
Live splitting is supported for different data packet transport protocols (HTTP, MMS TCP [MMST], MMS UDP [MMSU], and IP multicast).
Live Stream Splitting Scenarios
Based on the capabilities and limitations of the network, a Content Engine can receive and deliver WMT streaming content through IP multicast or unicast transmissions in the following four combinations:
•
Unicast-In Multicast-Out
•
Multicast-In Multicast-Out
•
Multicast-In Unicast-Out
•
Unicast-In Unicast-Out
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).
Note
You must accept a WMT license and enable WMT on the Content Engine and device groups before you can enable WMT multicasting in your ACNS 5.x network. See the "Enabling WMT" section.
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:
•
224.0.0.0 to 224.0.6.255
•
224.0.13.0 to 224.0.13.255
•
224.1.0.0 to 224.2.255.255
•
232.0.0.0 to 232.255.255.255
Note
You must choose a multicast IP address that does not conflict internally within the same multicast-enabled network configuration. This multicast IP address is not related to the IP address of the Content Engine. (See the "Unusable IP Multicast Addresses" section.)
The allowed multicast port range 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.
Note
If a live stream is interrupted on the server side, you must stop the multicast station and then restart the same station to resume live multicasting.
Configuring Unicast-In Multicast-Out
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, 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 enable WMT services for unicast-in multicast-out, follow these steps:
Step 1
From the Content Distribution Manager GUI, choose Devices > Devices.
Step 2
Click the Edit icon next to the Content Engine that you want to configure. The Contents pane appears on the left.
Step 3
From the Contents pane, choose Streaming/Caching > WMT > Multicast Stations. The WMT Multicast Station for Content Engine window appears.
Step 4
In the Aggregate Settings section, the Yes radio button is chosen by default, which means that the broadcast aliases created for the Content Engine as well as associated device groups are displayed and applied. Alternatively, click the No radio button to apply the settings of the Content Engine only.
Step 5
Click the Create New WMT Multicast Stations icon. The Creating New WMT Station for Content Engine window appears. (See Figure 9-10.)
Figure 9-10 WMT Multicast Station Configuration
Step 6
Under the WMT Station heading, enter a name for the multicast station in the Station Name field.
Step 7
In the Address field, enter a Class D IP address to be used as the multicast station IP address.
Step 8
In the Port field, enter the port number to be used by this station.
Step 9
In the Media field, enter the source of the WMT streaming media.
Step 10
Check the Repeat Forever check box if you want this source to play the media files without interruption. Otherwise, the multicast stream stops playing when the end of the source.nsc file is reached.
In the example in Figure 9-10, a multicast station named Multicast Station 1 is configured and used by the Content Engine as the multicast source. Its Class D IP address is 233.33.33.333, and the multicast port is 3333.
Note
This source file source.asf can be located on any WMT server, including a Windows server, or on the Content Engine. In the case of the Content Engine, pre-positioned media files should be stored in the /local1/wmt_vod directory. In this scenario, the media source is represented by mms://CEIPaddress/wmt_vod/source.asf, where CEIPaddress is the IP address of the Content Engine.
Step 11
In the Unicast URL field, enter the URL to allow unicast live splitting for clients who cannot be reached by multicast.
For viewers who are unable to receive WMT multicast streams or for virtual private network (VPN) users who are not accessible to multicasting, the unicast published URL can be used for unicast live splitting. The WMT player will fall back to unicast in the event of multicast failure. The unicast published URL is made available inside the multicast description metafile (.nsc) to viewers for automatic fallback to unicast live streaming. The unicast URL serves as a backup URL if the request is not intercepted by the ACNS network, when the ACNS network is unable to route multicast streams, or when the client is unable to receive multicast streams.
Step 12
Under the WMT Multicast Logging Settings heading, enable multicast logging.
•
Check the Enable WMT Multicast Logging check box to enable the Content Engine to collect statistics regarding the multicast stream using the .nsc file.
A WMT server supports a large number of media players for a particular stream during multicast, providing scalability without overloading the server. When WMT multicast logging is enabled, you can also receive feedback on certain statistical data, such as the number of times that buffering occurred while the stream was played, the number of packets lost during transmission, the browser type used when the WMT media player is embedded in a browser, and the protocol used to access the stream. These details are helpful for business analysts and program creators to learn about the effectiveness of the program multicast statistics. The media player obtains the IP address and port to monitor for content. When the stream stops playing, the WMT player automatically collects and sends the statistics to the multicast logging URL using the HTTP POST request method. You can choose to specify the URL to which Windows media transaction log files must be sent.
•
Alternatively, check the Enable Local Multicast Logging check box and enter a URL in the Multicast Logging URL field to allow WMT Media Players to send multicast statistics to the WMT server configured on the Content Engine.
Step 13
Click Submit to save the settings.
Step 14
Open your Windows Media Player and choose File > Open URL. Enter the following URL:
http://CEIPaddress/MulticastStation1.nsc
Note
The source file for streaming can be located on any WMT server, including a Windows server, or on the Content Engine. In the case of the Content Engine, pre-positioned media files must be stored in the /local1/wmt_vod directory. In this case, the source of the media file is represented by the URL mms://ceIpAddress/wmt_vod/asf_file.
Step 15
Click OK. The Windows Media Player should retrieve the multicast description .nsc file and join the multicast station that was specified in Step 6.
Note
The use of port 80 is implied in the URL for WMT multicasting. An equivalent URL is http://CEIPaddress:80/test1.nsc.
Configuring Multicast-In Multicast-Out
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).
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 services for multicast-in multicast-out, follow these steps:
Step 1
From the Content Distribution Manager GUI, choose Devices > Devices.
Step 2
Click the Edit icon next to the Content Engine that you want to configure. The Contents pane appears on the left.
Step 3
From the Contents pane, choose Streaming/Caching > WMT > Multicast Stations. The WMT Multicast Station for Content Engine window appears.
Step 4
In the Aggregate Settings section, the Yes radio button is chosen by default, which means that the broadcast aliases created for the Content Engine as well as associated device groups are displayed and applied. Alternatively, click the No radio button to apply the settings of the Content Engine only.
Step 5
Click the Create New Multicast Station icon. The Creating New WMT Station for Content Engine window appears. (See Figure 9-11.)
Figure 9-11 WMT Multicast Station Configuration
Step 6
In the Station Name field, enter a name for the multicast station.
Step 7
In the Address field, enter a Class D IP address to be used as the multicast station IP address.
Step 8
In the Port field, enter the port number to be used by this station.
Step 9
In the Media field, enter the filename of the multicast source*.nsc file.
Step 10
Check the Repeat Forever check box if you want this source to play the media files without interruption. Otherwise, the multicast stream stops playing when the end of the source*.nsc file is reached.
In this example, a multicast station named Multicast Station 2 is configured and used by the Content Engine as the multicast source. Its Class D IP address is 233.33.33.34, and the multicast port is 3334.
Note
This source file source.nsc can be located on any WMT server, including a Windows server, or on the Content Engine. In the case of the Content Engine, pre-positioned media files should be stored in the /local1/wmt_vod directory. In this scenario, the media source is represented by mms://CEIPaddress/wmt_vod/source.asf, where CEIPaddress is the IP address of the Content Engine.
Step 11
In the Unicast URL field, enter the URL to allow unicast live splitting for clients who cannot be reached by multicast.
For viewers who are unable to receive WMT multicast streams or for VPN users who are not accessible to multicasting, the unicast published URL can be used for unicast live splitting. The WMT player will fall back to unicast in the event of multicast failure. The unicast published URL is made available inside the multicast description metafile (.nsc) to viewers for automatic fallback to unicast live streaming. The unicast URL serves as a backup URL if the request is not intercepted by the ACNS network, when it is unable to route multicast or when the client is unable to receive multicast streams.
Step 12
Under WMT Multicast Logging Settings, enable multicast logging.
•
Check the Enable WMT Multicast Logging check box to enable the Content Engine to collect statistics regarding the multicast stream using the .nsc file.
A WMT server supports a large number of media players for a particular stream during multicast, providing scalability without overloading the server. When WMT multicast logging is enabled, you can also receive feedback on certain statistical data, such as the number of times that buffering occurred while the stream was played, the number of packets lost during transmission, the browser type used when the WMT media player is embedded in a browser, and the protocol used to access the stream. These details are helpful for business analysts and program creators to learn about the effectiveness of the program multicast statistics. The media player obtains the IP address and port to monitor for content. When the stream stops playing, the WMT player automatically collects and sends the statistics to the multicast logging URL using the HTTP POST request method. You can choose to specify the URL to which Windows media transaction log files must be sent.
•
Alternatively, check the Enable Local Multicast Logging check box to allow WMT media players to send multicast statistics to the WMT server configured on the Content Engine.
Step 13
In the Multicast Logging URL field, enter the URL of the WMT server to which the multicast statistics need to be sent, using the HTTP POST request method. You need to explicitly specify the URL, in case the WMT server is configured on any WMT server other than the Content Engine.
Step 14
Click Submit to save the settings.
Step 15
Open your Windows Media Player and choose File > Open URL. Enter the following URL:
http://CEIPaddress/MulticastStation2.nsc
Note
The source file for streaming can be located on any WMT server, including a Windows server, or on the Content Engine. In the case of the Content engine, pre-positioned media files must be stored in the /local1/wmt_vod directory. In this case, the source of the media file is represented by the URL, mms://ceIpAddress/wmt_vod/nsc_file.
Step 16
Click OK. The Windows Media Player should retrieve the multicast description .nsc file and join the multicast station that was specified in Step 6.
Note
The use of port 80 is implied in the URL for WMT multicasting. An equivalent URL is http://CEIPaddress:80/test1.nsc.
Configuring Multicast-In Unicast-Out
The multicast-in unicast-out configuration enables you 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 multicast stream live to requesting clients by converting the multicast stream to unicast.
To enable WMT services for multicast-in unicast-out, follow these steps:
Step 1
From the Content Distribution Manager GUI, choose Devices > Devices.
Step 2
Click the Edit icon next to the Content Engine that you want to configure. The Contents pane appears on the left.
Step 3
From the Contents pane, choose Streaming/Caching > WMT > Broadcast Alias. The WMT Broadcast Alias for Content Engine window appears.
Step 4
In the Aggregate Settings section, the Yes radio button is chosen by default, which means that the broadcast aliases created for the Content Engine as well as associated device groups are displayed and applied. Alternatively, click the No radio button to apply the settings of the Content Engine only.
Step 5
Click the Create New WMT Broadcast Aliases icon. The Creating New WMT Broadcast Alias for Content Engine window appears. (See Figure 9-12.)
Figure 9-12 WMT Broadcast Alias Window—Multicast-In Unicast-Out Configuration
Step 6
In the Broadcast Alias field, enter an alias for the source URL or station name to be used for the broadcast.
When a broadcast alias is configured, a client makes a request to the Content Engine as if it were the Windows Media Server, and the Content Engine checks to see whether the incoming stream is present. If it is, then the Content Engine joins the stream and splits it to the new client. If the request is the first client request for this stream, the Content Engine sends the request out to the server and then serves it to the new client.
For example, in Figure 9-12 a unicast publishing point with the alias name broadcast1 is configured.
Step 7
In the Source URL field, enter the URL of the station to be used for the broadcast. For example:
http://172.16.30.21/station.nsc
In this example, the multicast source URL contains the file station.nsc. A source URL in the format http://server/file.nsc tells the Content Engine that the input source is sending out WMT multicast streams.
Step 8
Click Submit to save the settings.
Step 9
Open your Windows Media Player and choose File > Open URL. Enter the following URL:
mms://CEIPaddress/broadcast1
where CEIPaddress is the IP address or domain name of the Content Engine, and broadcast1 is the alias name used in Step 6.
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 requesting client.
Step 10
Click OK. The Windows Media Player should receive content from the multicast source specified in Step 7.
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 distributed 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:
•
By live splitting without any configuration. In this case, the Content Engine acts as a proxy. When clients request the same unicast URL, the Content Engine proxy automatically splits the stream from the source to the clients.
•
By configuring the Content Engine with a broadcast alias. In this case, a client makes the request to the Content Engine as if it were the Windows Media Server, and the Content Engine checks to see whether the incoming stream is present. If it is, then the Content Engine joins the stream and splits it to the new client. If the request is the first client request for this stream, the Content Engine sends the request out to the server and then serves it to the new client.
To enable WMT services for unicast-in unicast-out by configuring the Content Engine with a broadcast alias, follow these steps:
Step 1
From the Content Distribution Manager GUI, choose Devices > Devices.
Step 2
Click the Edit icon next to the Content Engine that you want to configure. The Contents pane appears on the left.
Step 3
From the Contents pane, choose Streaming/Caching > WMT > Broadcast Alias. The WMT Broadcast Alias for Content Engine window appears.
Step 4
In the Aggregate Settings section, the Yes radio button is chosen by default, which means that the broadcast aliases created for the Content Engine and associated device groups are displayed and applied. Alternatively, click the No radio button to apply the settings of the Content Engine only.
Step 5
Click the Create New WMT Broadcast Alias icon. The Creating New WMT Broadcast Alias for Content Engine window appears. (See Figure 9-13.)
Figure 9-13 WMT Broadcast Alias Window—Unicast-In Unicast-Out Configuration
Step 6
In the Broadcast Alias field, enter an alias name for the source URL.
For example, in Figure 9-13 a unicast publishing point with the alias name cotv is configured.
Step 7
In the Source URL field, enter the source URL of the content to be used for the transmission. For example:
mms://wms.company.com/cotv
where 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 8
Click Submit to save the settings.
Step 9
Open your Windows Media Player and choose File > Open URL. Enter the following URL:
mms://CEIPaddress/cotv
where CEIPaddress is the IP address or domain name of the Content Engine, and cotv is the alias name used in Step 6.
Step 10
Click OK. The Windows Media Player should receive content from the unicast source specified in Step 7.
Configuring WMT Station Schedules
To configure WMT station schedules for the Content Engine, follow these steps:
Step 1
Choose Devices > Devices. The Content Engine window appears.
Step 2
Click the Edit icon next to the Content Engine whose station schedule you want to set. The Contents pane appears on the left.
Step 3
From the Contents pane, choose Streaming/Caching > WMT > Multicast Station Schedules. The WMT Multicast Station Schedule for Content Engine window appears.
Step 4
Click the Create New WMT Station Schedule icon. The Creating New WMT Station Schedule for Content Engine window appears.
Step 5
Choose a multicast station from the Station Name drop-down list.
Step 6
Enter the month (1-12) that you want the schedule to start in the Month field.
Step 7
Enter the day (1-31) that you want the schedule to start in the Day field.
Step 8
Enter hour (0-23) that you want the schedule to start in the Hour field.
Step 9
Enter the minute (0-59) that you want the schedule to start in the Minute field.
Step 10
Click Submit to save the settings.
Configuring Weighted Load Balancing for Live Stream Splitting
The live stream routing (LSR) application, running on each Content Engine, establishes the splitting tree route for live streaming URLs from the home Content Engine to the root Content Engine. Each live streaming URL belongs to a channel in the ACNS network.
The LSR application gathers a list of all Content Engines that are on the location path from the home Content Engine to the root Content Engine that are subscribed to the channel. Then, it builds a Content Engine path by selecting one Content Engine from each location on the location path. This Content Engine path is called live splitting path for this particular URL from this Content Engine.
This path is encoded in a special URL format and is sent to the next hop Content Engine on the path. The next hop Content Engine decodes the special URL and looks for its next hop. It then sends a request to its next hop and so on, until the root Content Engine is finally reached.
The LSR application obtains a matrix of Content Engines from the channel routing library for each channel that contains the URL. The matrix contains an ordered list for each location on the path from the home Content Engine to the root Content Engine. Each ordered list is composed of a number of Content Engines within the location that are assigned to the specified channel.
On receiving the matrix, the LSR application selects one Content Engine from each ordered list, forming a path from the home Content Engine to the root Content Engine. This path is used for live streaming URLs. The LSR application selects Content Engines from the list in the same order that they are listed. A Content Engine in the middle of the list is selected only after all preceding Content Engines have failed.
Because the LSR application always selects one Content Engine from the ordered list, when there are many different live streaming URLs, the load within one location is randomly distributed among all assigned Content Engines. Content Engines of different capacities (such as the CE-7325 and the CE-565) have an equal probability of being selected as the splitting Content Engine on the location path.
With a weighted load balancing scheme, users can influence the order in which Content Engines are listed. By adjusting the live split load weight, you can influence the probability of one Content Engine receiving live stream splitting traffic over another Content Engine in much the same way that you can influence location leader and forwarder selections for channel routing by assigning weight and priority values.
When the channel routing application generates the ordered list of Content Engines for each location, the load weight assigned to one Content Engine is compared against the weights of other Content Engines in the same location. The Content Engines are then ordered so that the Content Engine with the higher load weight has a greater probability of being ordered at the beginning of the list.
The weight is a probabilistic value; therefore, it is possible for a Content Engine with a lower weight to be at the beginning of the list, while a Content Engine with a higher weight could be at the end of the list. Weighted load balancing is mainly useful when there are multiple live stream URLs.
See also, the "Configuring Location Leader Preference and Forwarder Selection Probability" section and the "Configuring the Forwarder Lookup Level" section.
To configure the live split load weight for a Content Engine, follow these steps:
Step 1
Choose Devices > Devices. The Devices window appears, listing all the device types configured in the ACNS network.
Step 2
Click the Edit icon next to the Content Engine for which you want to specify the relative probability that a Content Engine is likely to receive live stream splitting traffic as compared to other Content Engines. The Modifying Content Engines window appears.
Step 3
In the Contents pane, choose Streaming/Caching > Live Splitting. The Live Splitting Settings for Content Engine window appears.
Step 4
Under the Live Splitting Settings section, to specify the relative probability of a Content Engine being selected as a live stream splitter, perform one of the following:
•
Click the Weighted radio button to associate a weight with the Content Engine being selected for live stream splitting for any URL.
•
Click and drag the Weighted slider control across the calibrated ruler to adjust the probability of live stream splitter selection. The range is 1 to 20. The default weight value is 1. The value corresponding to the position of the slider is displayed in the field next to it. The higher the weight, the higher the probability of the Content Engine being chosen as a live stream splitter.
•
Click the Last Resort radio button to specify that the Content Engine should not be selected as a live stream splitter unless there is no other Content Engine in the location subscribed to the channel, or all other Content Engines assigned to the channel in the same location have failed. This setting is associated with a weight of 0.
•
Click the Never Use radio button to specify that the Content Engine should never be selected as a live stream splitter in any case. This setting is associated with a weight of -1.
Step 5
In the Content Engines in Location section, view information about other Content Engines that are assigned to the same location. This information is displayed in a standard table format with columns for Content Engine, Status, Model, Software Version, and Live Splitting Probability.
Step 6
Click Submit to save the settings. A "Click Submit to Save" message appears in red next to the Current Settings line when there are pending changes to be saved. You can also revert to the previously configured settings by clicking Reset. The Reset button is visible only when you have applied default or group settings to change the current device settings but have not yet submitted the changes.
If you try to leave this window without saving the modified settings, a warning dialog box prompts you to submit the changes. This dialog box only appears if you are using the Internet Explorer browser.
Related CLI Commands
The live splitting probability configured for the Content Engine can be viewed using the show distribution channels command. However, this parameter can be configured only using the Content Distribution Manager GUI for each Content Engine. Default values are assumed if you do not manually configure this parameter.
The show distribution location live-load-weight command displays the live-load-weight value of Content Engines that are assigned to the channel within the location.
Configuring Bandwidth Settings for Content Services
Bandwidth settings for content services control the amount of bandwidth that each content service uses to stream content to users.
Content services bandwidth includes bandwidth allocation for WMT, RealProxy, RealServer, and Cisco Streaming Engine services. WMT bandwidth settings apply to WMT streaming of live, cached, and pre-positioned content. RealServer bandwidth settings apply to RealServer streaming of pre-positioned and live content that has been specified in the manifest file for a channel. RealProxy bandwidth settings apply to RealProxy streaming of cached and live content that has not been specified in the manifest file for a channel. Cisco Streaming Engine bandwidth settings apply to the standard RTSP server streaming of pre-positioned content only.
For each type of bandwidth, you can specify the amount of bandwidth to be used for a particular time interval. This is called scheduled bandwidth. Default bandwidth is the amount of bandwidth associated with each content services type when there is no scheduled bandwidth. When a Content Engine is a member of a device group, and if the default bandwidth is specified for that Content Engine, that bandwidth setting overrides the settings at the device group level. However, if there are no settings defined for a Content Engine, the device group settings become applicable for the Content Engine. When a Content Engine is a member of multiple device groups, the settings of the device group that have been most recently modified are used.
Maximum bandwidth specifies the upper limit beyond which any specified bandwidth is not allowed. The total bandwidth configured for all content services must not exceed the bandwidth limits specified for a particular Content Engine model. In addition, the license keys configured for WMT further restrict the maximum bandwidth, which must be less than the allowable maximum bandwidth for each Content Engine model.
Configuring Content Services Default and Maximum Bandwidth Settings
To configure content services default and maximum bandwidth settings, follow these steps:
Step 1
Choose Devices > Devices. The Devices window appears.
Step 2
Click the Edit icon next to the name of the Content Engine that you want to view. The Modifying Content Engine window appears.
Step 3
In the Contents pane, choose Streaming/Caching > Default and Maximum Bandwidth. The Default and Maximum Bandwidth for Content Engine window appears.
Step 4
For WMT Incoming, in the Default Bandwidth field, specify the amount of default bandwidth, in kbps, allowed for incoming WMT traffic from end users. In the Max Bandwidth field, specify the maximum bandwidth, in kbps, permitted by the system license.
Step 5
For WMT Outgoing, in the Default Bandwidth field, specify the amount of default bandwidth, in kbps, allowed for outgoing WMT traffic from Content Engines. In the Max Bandwidth field, specify the maximum bandwidth, in kbps, permitted by the system license.
Step 6
For Real Proxy Incoming, in the Default Bandwidth field, specify the amount of default bandwidth, in kbps, allowed for incoming RealProxy traffic from end users. In the Max Bandwidth field, specify the maximum bandwidth, in kbps, permitted by the system license. RealProxy traffic refers to RealMedia traffic that has been cached in response to requests from end users.
Step 7
For Real Proxy Outgoing, in the Default Bandwidth field, specify the amount of default bandwidth, in kbps, allowed for outgoing RealProxy traffic from Content Engines. In the Max Bandwidth field, specify the maximum bandwidth, in kbps, permitted by the system license.
Step 8
For Real Server, in the Default Bandwidth field, specify the amount of default bandwidth, in kbps, for streaming RealServer traffic to end users. In the Max Bandwidth field, specify the maximum bandwidth, in kbps, permitted by the system license. RealServer traffic refers to RealMedia content that has been pre-positioned.
Step 9
For Cisco Streaming Engine, in the Default Bandwidth field, specify the amount of default bandwidth, in kbps, allowed for the Cisco Streaming Engine to stream content to end users. In the Max Bandwidth field, specify the maximum bandwidth, in kbps, permitted by the system license.
Step 10
For HTTP, in the Default Bandwidth field, specify the amount of default bandwidth, in kbps, associated with HTTP traffic. In the Max Bandwidth field, specify the maximum allowed bandwidth, in kbps, to handle HTTP requests.
Step 11
Click Submit to save your settings. A "Click Submit to Save" message appears in red next to the current settings when there are pending changes to be saved after you have applied default and device group settings. You can also revert to the previously configured window settings by clicking Reset. The Reset button is visible only when you apply default or group settings to change the current device settings but the settings have not yet been submitted.
Note
For other operations that you can perform using the icons in the taskbar, see Table 2-3, "Content Distribution Manager GUI Icons."
To configure content services default and maximum bandwidth settings from the CLI, use the following global configuration command:
bandwidth {real-proxy {incoming kbits | outgoing kbits} | real-server kbits | wmt {incoming kbits | outgoing kbits} | cisco-streaming-engine kbits | http kbits} {default | max-bandwidth}
Configuring Scheduled Bandwidth Settings
To configure scheduled bandwidth settings for content services, follow these steps:
Step 1
From the Content Distribution Manager GUI, choose Devices > Devices.
Step 2
Click the Edit icon next to the name of the Content Engine that you want to configure. The Contents pane appears on the left.
Step 3
From the Contents pane, choose Streaming/Caching > Scheduled Bandwidth. The Bandwidth Schedule for Content Engine window appears.
Step 4
In Aggregate Settings, the Yes radio button is chosen by default, which means that the bandwidth configurations of the Content Engine as well as the device groups to which it is assigned are displayed and applied. Click the No radio button if you want to apply and view the bandwidth settings of the Content Engine only.
Step 5
Click the Create New Bandwidth Schedule icon. The Create New Content Service Bandwidth Settings window appears. (See Figure 9-14.) Table 9-3 describes each field displayed in this window.
Figure 9-14 Create New Content Service Bandwidth Settings Window
Step 6
In the Bandwidth Configuration section, choose a bandwidth type from the Bandwidth Type drop-down list.
Step 7
In the Bandwidth Rate field, specify the bandwidth rate allowed in kbps.
Step 8
Under the Bandwidth Time Settings headings, the current time is displayed in UTC. For Time Selection, enter the start time and end time for bandwidth usage (in hh:mm) in the appropriate fields.
Note
For a schedule from 8:00 p.m. to 8:00 a.m., the administrator must configure two schedules in order to span the two days; one from 8:00 p.m. to 11:59 p.m. (2000 to 2359) and another from 12:00 a.m. to 8:00 a.m. (0000 to 0800).
Step 9
Click the Use Specific days radio button to specify whether the bandwidth settings apply for an entire week or for specific days of the week. Check the appropriate check boxes to denote the days on which the configured settings apply.
Step 10
Alternatively, click the Specific day range radio button to choose a starting day of the week and an ending day of the week for the bandwidth configurations.
Step 11
Click Submit to save your settings.
Table 9-3 Streaming Bandwidth Configuration Settings
GUI Parameter
|
Function
|
CLI Command
|
Bandwidth Type
|
WMT Incoming is for incoming WMT streaming content requests from end users.
WMT Outgoing is for outgoing WMT media from Content Engines.
Real Proxy Incoming is for incoming RealProxy traffic from end users.
Real Proxy Outgoing is for outgoing RealProxy traffic from Content Engines.
Real Server is for streaming RealMedia pre-positioned content to end users.
Cisco Streaming Engine is for streaming content in response to RTSP requests from end users
HTTP is for sending content in response to HTTP requests from end users
|
bandwidth {real-proxy {incoming kbits | outgoing kbits} | real-server kbits | wmt {incoming kbits | outgoing kbits} | cisco-streaming-engine kbits | http kbits} {start-time weekday time end-time weekday time}
|
Bandwidth Rate
|
Maximum amount of bandwidth you want to allow in kilobits per second.
|
Start Time
|
Time of day for the bandwidth rate setting to start, using a 24-hour clock in local time (hh:mm).
|
End Time
|
Time of day for the bandwidth rate setting to end (hh:mm).
|
Use specific days
|
Days of the week on which configured bandwidth settings apply.
• Full Week—Specifies that the bandwidth settings are applicable for an entire week
• Sun, Mon, Tue, Wed, Thu, Fri, and Sat—Specifies the days of the week on which the bandwidth settings apply
|
Specific day range
|
Range of days of the week on which configured bandwidth settings apply.
• Start day—Day of the week to start for allowable bandwidth
• End day—Day of the week to end for allowable bandwidth
|
You can configure scheduled bandwidth settings with overlapping timings. When you use the aggregate method of device and device group configuration, it is possible that the list of settings configured for devices and device groups might have overlapping schedules. However, you cannot configure bandwidths of the same type with overlapping bandwidth settings. This configuration is permissible only for bandwidths of different types.
For example, assume that a Content Engine is associated with a device group and two bandwidth configurations have been configured—one, a WMT incoming bandwidth with a schedule from 1300 to 1500 on Mondays and at a rate of 20 Mbps for the Content Engine, and another, a RealProxy outgoing bandwidth with a schedule from 1200 to 1700 on Mondays and at a rate of 20 Mbps for the device group. In this case, the configurations are successful because the bandwidth types are different. Assuming the same scenario, if you attempt to configure a WMT incoming bandwidth for the device with time settings that overlap those of the Content Engine, the configuration will fail.
The actual bandwidth settings might result in a large number of overlapping settings. As a result of such complex configurations, you might want to view a pictorial display of the allowable bandwidth settings against the days of the week. For this purpose, you can view a graph that represents the content services bandwidth settings. (See the next section, "Displaying a Graphical Representation of the Content Service Bandwidth Settings.")
When the Aggregate Settings Yes radio button is chosen, the bandwidth settings that have been previously configured for device groups to which the Content Engine belongs cannot be modified or deleted in the Content Service Bandwidth Settings for Content Engine window. In other words, you can only view the bandwidth configurations created for the device groups.
Displaying a Graphical Representation of the Content Service Bandwidth Settings
You can view a graphical representation of the bandwidth settings for content services configured on a Content Engine. The vertical axis of the graph represents the amount of bandwidth in kbps, and the horizontal axis represents the days of the week. The units shown on the vertical axis are determined dynamically based on the bandwidth rate for a particular bandwidth type. The units shown on the horizontal axis represent 24 hours per each day of the week. Each type of bandwidth is represented by a unique color. A legend at the bottom of the graph maps colors to the corresponding bandwidth type.
To view the graph that displays the content services bandwidth, follow these steps:
Step 1
Choose Devices > Devices. The Devices window appears.
Step 2
Click the Edit icon next to the desired Content Engine. The Modifying Content Engine window appears.
Step 3
In the Contents pane, choose Streaming/Caching > Default and Maximum Bandwidth. The Default and Maximum Bandwidth Settings for Content Engine window appears.
Step 4
Click the Display Graph icon in the taskbar. The Content Service Bandwidth for Content Engine popup window appears, displaying the bandwidth configuration graph. (See Figure 9-15.)
Click a view option in the text at the top of the window to view the graph by bandwidth type, detailed or composite view, or days of the week. Table 9-4 describes the view options.
Figure 9-15 Content Services Bandwidth Graph

Table 9-4 Viewing Options for Content Services Bandwidth Graph
Option
|
Description
|
View specific servers
|
Displays the bandwidth settings for the corresponding bandwidth type (server) selected
|
WMT In
|
Displays the bandwidth settings for incoming WMT traffic.
|
WMT Out
|
Displays the bandwidth settings for outgoing WMT traffic.
|
Real Proxy In
|
Displays the bandwidth settings for incoming RealProxy traffic.
|
Real Proxy Out
|
Displays the bandwidth settings for outgoing RealProxy traffic.
|
Real Server
|
Displays the bandwidth settings for RealServer traffic.
|
Cisco Streaming Engine
|
Displays the bandwidth settings for Cisco Streaming Engine pre-positioned content.
|
HTTP
|
Displays the bandwidth settings for HTTP requests.
|
All Servers
|
Displays a consolidated view of all configured bandwidth types. This is the default view and is combined with the Full Week view.
|
View mode
|
Displays detailed and composite bandwidth settings.
|
Show Detailed Bandwidth/Show Effective Bandwidth
|
Toggles between the two options:
Show Detailed Bandwidth—Displays detailed bandwidth settings for the Content Engine and its associated device groups. The bandwidth settings of the device and device groups are shown in different colors for easy identification.
Show Effective Bandwidth—Displays the composite (aggregate) bandwidth settings for the Content Engine and its associated device groups.
|
Show Aggregate View/Show Non-Aggregate View
|
Toggles between the two options:
Show Aggregate View—Displays the bandwidth settings configured for the corresponding device groups.
Non-Aggregate View—Displays the bandwidth settings configured for the Content Engine.
|
View by day
|
Displays the bandwidth settings for a particular day or all days of the week.
|
Sun, Mon, Tues, Wed, Thurs, Fri, Sat
|
Displays the bandwidth settings for the corresponding day of the week.
|
Full Week
|
Displays the bandwidth settings for the entire week This is the default view and is combined with the All Servers view.
|
Step 5
Click Refresh to display the latest bandwidth settings.
Step 6
Click Close once you have finished viewing the settings.
Configuring the WMT Incoming Bandwidth Bypass List
Incoming bandwidth refers to the bandwidth between a local Content Engine and the origin server. When the Content Engine is configured for WMT proxy services, incoming bandwidth usage for video-on-demand (VOD) content is unpredictable. This is because the consumption of incoming bandwidth for VOD content can be triggered arbitrarily by an end user requesting the content. If the VOD content is not found in the Content Engine cache, a cache miss occurs, and the WMT proxy has to fetch the content from the origin server. The Content Engine administrator cannot predict the incoming bandwidth usage for such events. Thus, a large number of cache miss VOD requests can totally consume incoming bandwidth.
The WMT incoming bandwidth bypass configuration allows the administrator to configure a list of hosts that will bypass the incoming bandwidth limitation. Content from a source that is listed as a host in this configuration is allowed to bypass the incoming bandwidth check for broadcast alias or multicast station content. This is particularly useful when the administrator wants to configure a broadcast alias or multicast station for a mission-critical live event, such as a message from the company CEO.
To configure the list of hosts for bypassing incoming bandwidth limits, follow these steps:
Step 1
In the Content Distribution Manager GUI, Choose Devices > Devices. The Devices window appears.
Step 2
Click the Edit icon next to the desired Content Engine. The Modifying Content Engine window appears with the Contents pane on the left.
Step 3
In the Contents pane, choose Streaming/Caching > Local Content Services. The Local Content Services Settings for Content Engine window appears.
Step 4
In the WMT BW Incoming Bypass List field, enter the IP addresses or the host names of the hosts for which you wish to bypass the incoming bandwidth check. Separate each entry with a space.
Step 5
Click Submit to save the settings. A "Click Submit to Save" message appears in red next to the Current Settings when there are pending changes to be saved after you have applied default of device group settings. To revert to the previously configured window settings, click Reset. The Reset button is visible only after you change the current device settings and before you click Submit.
Note
You can configure a maximum of four hosts in the WMT BW incoming bypass list. An error message appears if you try to configure more.