|
|
Streaming media files are files that are sent to the user and played on the user's media player as the files are received from the network. Streaming media files avoid a waiting period for viewing these files because they are immediately available as a continuous stream of data packets. (See Figure 13-1.) This eliminates the need to store large media files for viewing purposes or the need to allocate storage space for these files before playing them.
In Figure 13-1 both audio and video are being recorded from an event to be distributed later either as video on demand (VOD) or live to a network of users. The encoder software and hardware compress the signal into streamable files, which are then sent to a media file server. This media server in turns delivers the media files on a live or on-demand basis to users with the particular media software on their personal computers or other electronic devices. Note that in this figure the Content Engine is manually configured to be the caching proxy for the users in that particular network.
Table 13-1 lists the different types of streaming media protocols, control channels, the corresponding data format, and transport types supported by ACNS 4.1 software.
| Streaming Media Protocol | Control Channel | Data Format | Transport Protocol |
|---|---|---|---|
Windows Media format | TCP | MMS1 | UDP2, TCP, HTTP, IP multicast |
RealNetworks media format | TCP | RTSP, PNA3 | UDP, TCP, HTTP, IP multicast |
| 1MMS = Microsoft Media Server. 2UDP = User Datagram Protocol. 3PNA = Progressive Networks Audio. |
Microsoft Windows Media Technologies (WMT) is a set of streaming solutions for creating, distributing, and playing back digital media files on the Internet. WMT includes the end user application (Windows Media Player) Version 7.01 and the server and distribution application (Windows Media Server). To disseminate live and pre-positioned Windows Media content on a Content Delivery Network (CDN), you need WMT caching proxy and server capabilities on the Content Engine.
 |
Note The WMT product is licensed software. To enable the WMT proxy, you must have a license keyword. If you ordered WMT with the CE, a license certificate with the keyword is shipped in the box. If you are downloading the ACNS 4.1 software, you can purchase a WMT license though the Cisco.com website. |
The Content Engine acting as a WMT caching proxy supports a basic proxy feature—it accepts incoming WMT streaming requests from clients and acts on behalf of the clients communicating with the origin server. The WMT caching proxy accepts and serves the streaming requests over Microsoft Media Server (MMS) protocol as well as the HTTP protocol. (See Figure 13-2.) MMS is the protocol that WMT uses for communication between players and servers.
When possible, the WMT caching proxy also caches the streaming content and serves the request from the cache instead of the origin server. It accepts transparently intercepted requests (through WCCP or L4 redirect) as well as manual proxy requests (clients configured to use an upstream proxy).
The WMT caching proxy also supports splitting of live streams (that is, it splits a single inbound feed to multiple clients) and multicasting.
|
Note If a firewall is positioned between a Content Engine acting as a proxy, and a requesting client, make sure that you assign the external IP address of the Content Engine in its configuration. |
|
Note For MMS over TCP and UDP, the proxy always fetches the stream from a server using TCP (MMST) so that the item cached is reliable and complete for future delivery. Streams requested using HTTP will be fetched using HTTP. |
Caching frequently accessed content closer to the user provides better-quality streams and saves network bandwidth. When the proxy fetches the content from the server to be served to the client, it will store the cacheable stream on the media file system (mediafs). The proxy can cache partial streams. When a client requests a part of the stream that has not been cached, the proxy fetches the missing portions from the origin server. Even when there is a cache hit, a connection is maintained with the origin server in order to report client usage statistics, which can be used for accounting and other purposes by the origin server.
Streams served from the cache are guaranteed to be fresh because the Content Engine always checks with the origin server, using the appropriate cache parameters settings. When the storage limit is reached, older objects are replaced using an appropriate replacement algorithm to ensure a proper hit ratio. See the "Cache Freshness" section for more information regarding the appropriate cache parameter settings.
The proxy can cache authenticated streams, and on a cache hit, the authentication credentials of the requesting client are revalidated against the origin server before the content is served.
Caching is supported in nontransparent (manual) proxy as well as transparent proxy modes.
|
Note Caching of Moving Picture Experts Group Layer-3 audio (MP3), waveform audio (WAV), and Audio Video Interleaved (AVI) files over MMS is supported. Windows Media content fetched by a nonstreaming HTTP server (at the request of a Windows Media Player) is not cached. Live streams are not recorded or cached. |
A content provider can create streaming media files at different bit rates to ensure that different clients who have different connections—for example, modem, DSL or LAN—can handle a particular bit rate of their choice. The WMT caching proxy can cache multiple bit rate or variable bit rate (VBR) files, and based on the bit rate specified by the client, it serves the appropriate stream.
Another advantage of creating variable bit rate files is that a single URL is all that must be specified for the delivery of streaming media.
Use the wmt max-bitrate command to configure the maximum bit rate for streaming media delivery.
The Content Engine splits requests for live streams. That is, a single stream from the origin streaming server is split to serve each client that requested the stream. (See Figure 13-3.) In the case of the WMT caching proxy, when the client requests a publishing point on a server (without specifying an ASF file), then the WMT caching proxy 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.
Live splitting at the proxy is better than at the server, because the proxy is closer to the clients, thereby potentially saving considerable network bandwidth between the client and the origin server.
|
Note Live splitting is supported for different data packet transport protocols (HTTP, MMS TCP [MMST], MMS UDP [MMSU], and IP multicast). |
The WMT proxy supports both basic and NTLM authentication by the origin server. When a client requests content that needs user authentication, the proxy acts as an agent, conveying the authentication information to and from the client and server to authenticate the client. Once the client is authenticated, the content is streamed as usual. The authentication is performed for both cached content as well as noncached VOD content.
In the case of basic authentication, the server requests the client's identification in the form of an encoded username and password. If the authentication fails, the client is informed accordingly, in which case the client retries or disconnects. If the authentication is successful, then the streaming media is served to the client. This is supported in manual as well as transparent proxy mode, over both HTTP and MMS.
Windows NTLM is a connection-based challenge-response authentication scheme. In the basic authentication scheme, the proxy transfers the authentication information to and from the client and server, as if the request were coming from the client, until the client is authenticated. On the other hand, because the NTLM protocol authenticates every connection, the proxy cannot arbitrarily create new connections with the origin server. The proxy must reuse connections initiated by the client. Hence, a file is served from the cache only if it is a complete cache hit, that is, the complete file is present on disk. If the file is not a complete hit, then the entire file is fetched from the origin server in the case of NTLM.
This is supported in manual as well as transparent proxy mode, over both HTTP and MMS.
The proxy supports caching and delivery of Digital Rights Management (DRM)-protected Windows Media files. Access control lists enforced by the origin server are automatically enforced by the proxy.
|
Note Filtering based on user identification is also supported. The proxy only supports authentication by the origin server. Proxy authorization, or authentication of the user to use the proxy, will be supported in a future release. Live streams that are split to clients are also authenticated with the origin server in the ACNS 4.1 software. |
This section lists features that are supported by the WMT caching proxy in the ACNS 4.1 software.
The logging format is consistent with that of the Windows Media server and the W3C-compliant log format. A log line is written for every stream accessed by the client. The location of the log is not configurable. These logs can be exported using FTP. All client information in the transaction logs is sent to the origin server by default and cannot be disabled.
The error log consists of the debugging logs written by the application. Error logs are in the same format and location as syslogs.
The WMT proxy needs to maintain key statistics to provide byte savings, number of cache hits and cache misses, number of concurrent streams (according to bandwidth rates), percentage of cache or disk space used, and so forth.
You can view WMT statistics by choosing Reporting > WMT Streaming from the Content Engine GUI. (See Figure 13-4.) You can also use the show statistics wmt all command to view WMT statistics using CLI. (See the "WMT Examples" section.)
Interoperability is the most important requirement for WMT software components. The WMT caching proxy is required to work with all versions of Microsoft Windows Media Player, Windows Media Server, Windows Media Encoder and third-party Windows Media applications.
In order to support transparent proxy mode, you need to have WCCP running on the Content Engine. See the "Enabling Transparent WMT Service Using WCCP-Enabled Routers" section.
To enable WMT on the Content Engine, follow these steps.
|
Note You can only use CLI commands to enable WMT on the Content Engine. |
Step 1 Enter the wmt license-key command to be able to use WMT capabilities on the Content Engine.
507-1(config)# wmt license-key WORD
where WORD is the WMT license shipped with the Content Engine.
Step 2 Accept the license agreement.
507-1(config)# wmt accept-license-agreement
Step 3 Enable the Content Engine with the wmt enable command.
507-1(config)# wmt enable
You are now able to configure the WMT parameters required for streaming media connections through WMT technologies by transparent caching or conventional caching.
|
Note You must configure disk space to include mediafs storage with the disk config command before you can run cache streaming media using WMT. |
During transparent caching, the user's network traffic flows through the WCCP-enabled router rather than the Content Engine to access streaming media.
To enable transparent redirection of WMT traffic to the Content Engine acting as a WMT proxy, follow these steps.
Step 1 On the routers running WCCP Version 2, turn the WCCP feature on for the specified service groups used to redirect WMT traffic to the Content Engine. For more information on router commands, see "Web Cache Communication Protocol Version 2."
router(config)# ip wccp 81
router(config)# ip wccp 82
|
Note MMS works on two transport protocols: TCP and UDP. To perform a WCCP redirect of MMS traffic, the router has to redirect both TCP and UDP traffic. With a router running WCCP Version 2, that means you must enable two WCCP service groups on the router. The standard service group is 81 for TCP and 82 for UDP. |
Step 2 Configure the outbound interfaces to the Internet and enter interface configuration mode. In the following example, the outbound interface is the Ethernet 0 device.
router(config)# interface Ethernet 0
|
Note Although typical router configuration in a branch office scenario involves configuring the outgoing interface, you can also configure the incoming interface on the router for traffic redirection. This depends primarily on the client's network topology. |
Step 3 Enable WCCP redirection to service groups 81 and 82 on the specified interface.
router(interface)# ip wccp 81 redirect out
router(interface)# ip wccp 82 redirect out
Step 4 Set the WCCP Version 2 parameters on the Content Engine.
ContentEngine(config)# wccp version 2
ContentEngine(config)# wccp wmt router-list-num 1
Step 5 Enter the numbered router list that you wish to associate with this service. In the following example, the WCCP Version 2-enabled routers have the IP addresses 172.16.25.25 and 172.16.24.24.
ContentEngine(config)# wccp router-list 1 172.16.25.25 172.16.24.24
Step 6 Enable WMT on the Content Engine. See the "Enabling WMT on the Content Engine" section.
Step 7 Save the new configuration.
ContentEngine# copy running-config startup-config
Step 8 Configure WMT parameters as needed using CLI commands.
|
Note Refer to the Cisco Application and Content Networking Software Command Reference, Release 4.1 for more detailed information on these parameters. Alternatively, you can click the WMT Config button to configure the WMT parameters as needed with the Content Engine GUI. (See Figure 13-4.) |
Step 9 Use the following CLI command to display all WMT statistics once you have started the WMT player:
ContentEngine# show statistics wmt all
|
Note The WMT statistics relate only to objects transported over MMS that were requested by a WMT client. Objects transported over HTTP are counted in the HTTP statistics. Streaming objects requested by other clients or transported over other protocols other than RTSP (for RealPlayer streaming media) bypass the Content Engine. See the "Configuring RealProxy 8.01" section for more information about RTSP streaming and caching with the Content Engine. |
During conventional proxy caching, the user media player is pointed to the Content Engine rather than a WCCP-enabled router to access streaming media.
To configure the Content Engine to service WMT clients with the WMT proxy, follow these steps:
Step 1 Enable WMT on the Content Engine. See the "Enabling WMT on the Content Engine" section.
Step 2 Configure the Content Engine to listen for WMT traffic on a specified port. The standard WMT port is 1755.
ContentEngine(config)# wmt incoming 1755
Step 3 Configure WMT media players to use the Content Engine as the WMT proxy. (See Figure 13-5.)
a. Open the Windows Media Player.
b. Choose Tools > Options.
c. Click the Network tab.
d. Click the Multicast, UDP, TCP and HTTP radio buttons if not selected.
e. Click MMS under Proxy Settings and click Configure. The Configure Protocol Page in WMT Media Player page appears. (See Figure 13-6.)
f. Click Use the following proxy server.
g. Enter the IP address of the Content Engine in the Address field.
h. In the port field, enter the port number that you entered in Step 2.
i. Click OK.
Step 4 Save the new configuration.
ContentEngine# copy running-config startup-config
Step 5 Configure WMT parameters as needed using the CLI commands. Use the wmt ? command to see available configuration options.
ContentEngine(config)#wmt ?
accept-license-agreement Accept license; View by 'show wmt license-agreement'
broadcast Broadcast live configuration.
cache WMT cache config
disallowed-client-protocols Specify disallowed WMT client protocols
enable Enable WMT
evaluate Start/continue 60-day evaluation of WMT.
incoming Configuration for incoming WMT requests
l4-switch Configure layer 4 switch interoperability for WMT.
license-key Required license key for WMT
max-bandwidth Maximum aggregate bandwidth limitation.
max-bitrate Maximum stream bit rate that can be served to a client.
max-concurrent-sessions Maximum number of unicast clients that can be served concurrently.
multicast Multicast configuration and scheduling.
ContentEngine(config)
|
Note Alternatively, you can click the WMT Config button to configure the WMT parameters as needed with the Content Engine GUI. (See Figure 13-4.) |
Step 6 Use the following CLI command to display all WMT statistics once you have started the WMT player:
ContentEngine# show statistics wmt all
|
Note The WMT statistics relate only to objects transported over MMS that were requested by a WMT client. Objects transported over HTTP are counted in the HTTP statistics. Streaming objects requested by other clients or transported over other protocols other than RTSP (for RealPlayer streaming media) bypass the Content Engine. |
Based on the capabilities and limitations of the network, a Content Engine can receive and deliver WMT streaming content through IP multicast in the following three scenarios:
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 with unicast and relays in all fashions.
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.
Two global configuration CLI commands are needed to configure the Content Engine for the WMT multicasting scenarios described:
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 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.
|
Note You must enable WMT on the Content Engine before you can use the wmt multicast and wmt broadcast commands. See the "Enabling WMT on the Content Engine" section for information on the steps needed to enable this feature. |
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 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. |
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.
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.
|
Note You can also configure WMT multicasting parameters with the Content Engine GUI. Click the WMT Config button shown in Figure 13-4 to access these parameters. |
The 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.
To enable WMT multicasting in this scenario, follow these steps:
Step 1 Enable WMT multicasting and configure a multicast station on the Content Engine in global configuration mode with the wmt multicast station-configuration command:
ContentEngine(config)# wmt multicast station-configuration test1 233.33.33.33 3333
mms://sourceIPaddress/source.asf play-forever
ContentEngine(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 is a VOD file, this option automatically restarts from the beginning of the source.asf file once the end of this file has been reached.
|
Note This source file source.asf can be located on any WMT server, including a Windows server, or 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. |
Step 2 Start the multicast using the wmt multicast-station command in EXEC mode.
ContentEngine# wmt multicast-station start test1
ContentEngine#
Step 3 Open your WMT player and choose File > Open URL. Enter the followingURL:
http://CEIPaddress/test1.nsc
Click OK. The WMT player should retrieve the multicast description .nsc file and join the multicast station that is specified in Step 1.
|
Note The use of port 80 is implied in the URL for WMT multicasting. An equivalent URL is http://CEIPaddress:80/test1.nsc. |
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 file to subscribe to the multicast.
To enable WMT multicasting in this scenario with CLI commands follow these steps:
Step 1 Enable WMT multicasting and configure a multicast station on the Content Engine in global configuration mode with the wmt multicast station-configuration command:
ContentEngine(config)# wmt multicast station-configuration test2 233.33.33.34 6667
mms://172.16.30.31/source.nsc
ContentEngine(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 play-once default option is used. This option stops the multicast once the end of the source.nsc file has been reached.
Step 2 Start the multicast with the wmt multicast-station command in EXEC mode.
ContentEngine# wmt multicast-station start test2
ContentEngine#
Step 3 Open your WMT player and choose File > Open URL. Enter the following URL:
http://CEIPaddress/test2.nsc
Click OK. The WMT player should receive the MMS media source specified in Step 1.
In this scenario a unicast-out publishing point is created to deliver the incoming stream live to requesting clients.
To enable WMT multicasting in this scenario with CLI commands follow these steps:
Step 1 Enable WMT multicasting and configure a broadcasting alias on the Content Engine in global configuration mode with the wmt broadcast command:
ContentEngine(config)# wmt broadcast alias-name myunicast source
http://172.16.30.31/station.nsc
ContentEngine(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. A source of an alias in the format of http://server/file.nsc signals the Content Engine to treat this source as a multicast input source.
Step 2 Open your WMT player and choose File > Open URL. Enter the following URL:
mms://CEIPaddress/myunicast
Click OK. 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.
In the following example, the show statistics wmt ? command is used to show the CLI options for displaying statistics monitored by the Content Engine.
ContentEngine(config)# show statistics wmt ?
all Display all Windows Media statistics
bytes Display unicast bytes statistics
errors Display errors statistics
multicast Display multicast statistics
requests Display unicast request statistics
savings Display savings statistics
usage Display current usage statistics
statistics Display statistics by module
The following example displays request statistics. In this example, the statistics reported are the total number of requests served, the type of content (live or VOD), source of content, transport protocol, and the source of content.
ContentEngine# show statistics wmt requests
Unicast Requests Statistics
===========================
Total unicast requests received: 4
-------------------------------------
Total % of Total
Unicast Requests
--------------------------------------------
Total Requests served: 4 100.00%
Total % of Total Requests
---------------------------------------------
By Type of Content
------------------
Live content: 2 50.00%
On-Demand Content: 2 50.00%
By Transport Protocol
---------------------
MMSU: 4 100.00%
MMST: 0 0.00%
HTTP: 0 0.00%
By Source of Content
--------------------
Local: 0 0.00%
Remote MMS: 4 100.00%
Remote HTTP: 0 0.00%
Multicast: 0 0.00%
ContentEngine#
In the following example, all WMT statistics are displayed.
ContentEngine# show statistics wmt all
Unicast Requests Statistics
===========================
Total unicast requests received: 4
-------------------------------------
Total % of Total
Unicast Requests
--------------------------------------------
Total Requests served: 4 100.00%
Total % of Total Requests
---------------------------------------------
By Type of Content
------------------
Live content: 2 50.00%
On-Demand Content: 2 50.00%
By Transport Protocol
---------------------
MMSU: 4 100.00%
MMST: 0 0.00%
HTTP: 0 0.00%
By Source of Content
--------------------
Local: 0 0.00%
Remote MMS: 4 100.00%
Remote HTTP: 0 0.00%
Multicast: 0 0.00%
Unicast Bytes Statistics
========================
Total unicast outgoing bytes: 51089546
---------------------------------
Total % of Total Unicast
Outgoing Bytes
--------------------------------------------
By Type of Content
------------------
Live content: 50721284 99.28%
On-Demand Content: 368262 0.72%
By Transport Protocol
---------------------
MMSU: 51089546 100.00%
MMST: 0 0.00%
HTTP: 0 0.00%
Unicast Savings Statistics
==========================
Total bytes saved: 353256
--------------------------
Total % of Total Bytes
Saved
--------------------------------------------
By Pre-positioned content: 0 0.00%
By Live-splitting: 0 0.00%
By Cache-hit: 353256 100.00%
Total % of Total
Incoming Live Bytes
--------------------------------------------
Live Splitting
--------------
Incoming bytes: 50750993 100.00%
Outgoing bytes: 50721284 100.00%
Bytes saved: 0 0.00%
Total % of Bytes Cache
Total
--------------------------------------------
Caching
-------
Bytes cache-miss: 15006 4.07%
Bytes cache-hit: 353256 95.93%
Bytes cache-total: 368262 100.00%
Bytes cache-bypassed: 0
Total % of Req Cache
Total
--------------------------------------------
Cacheable requests
------------------
Req cache-miss: 0 0.00%
Req cache-hit: 2 100.00%
Req cache-partial-hit: 0 0.00%
Req cache-total: 2 100.00%
Req cache-bypassed: 0
Objects not cached
------------------
Cache bypassed: 0
Exceed max-size: 0
Multicast statistics
====================
Total Multicast Outgoing Bytes: 0
Aggregate Multicast Out Bandwidth (Kbps)
-----------------------------------------------
Current: 0.000
Max: 0.000
Number of Concurrent Active Multicast Sessions
-----------------------------------------------
Current: 0
Max: 0
List of All Configured Multicast Stations
-----------------------------------------------
Total Number of Configured Multicast Stations: 0
Usage Summary
=============
Concurrent Unicast Client Sessions
----------------------------------
Current: 1
Max: 1
Concurrent Active Multicast Sessions
------------------------------------
Current: 0
Max: 0
Concurrent Remote Server Sessions
---------------------------------
Current: 1
Max: 1
Concurrent Unicast Bandwidth (Kbps)
-----------------------------------
Current: 107.125
Max: 107.125
Concurrent Multicast Out Bandwidth (Kbps)
-----------------------------------------
Current: 0.000
Max: 0.000
Concurrent Bandwidth to Remote Servers (Kbps)
---------------------------------------------
Current: 50.343
Max: 107.125
Error Statistics
================
Total request errors: 0
Errors generated by this box
Reach MAX connections: 0
Reach MAX bandwidth: 0
Reach MAX bit rate: 0
MMSU under wccp: 0
MMSU not allowed: 0
MMST not allowed: 0
MMSU/T not allowed: 0
HTTP not allowed: 0
1st tcp pkt error, possible port scan: 0
Illegal url: 0
No socket: 0
Cannot connect: 0
Authentication fail: 0
Remote server error: 0
Client error: 0
Internal error: 0
Local vod file not found: 0
Local vod file header corrupted: 0
Local vod file data corrupted: 0
Unknown error: 0
Errors generated by remote servers
Reach MAX connections: 0
Reach MAX bandwidth: 0
Reach MAX bit rate: 0
Illegal url: 0
Invalid request: 0
No socket: 0
Cannot connect: 0
Connection refused: 0
Access deny: 0
Invalid stream type: 0
Remote server error: 0
Remote timeout: 0
Remote proxy error: 0
File not found: 0
File header corrupted: 0
File data corrupted: 0
Remote unknown error: 0
Authentication Retries from Clients: 0
Posted: Mon Nov 18 11:29:49 PST 2002
Copyright 1989-2000©Cisco Systems Inc.