Table Of Contents
Release Notes for Cisco ACNS Software, Release 5.5.3
Software Component Versions Supported in ACNS Software
New Features in the ACNS 5.5.3 Software
Design Limitation for ACNS Object Transfers
Windows Media Transaction Log Forwarding in ACNS 5.5
Protocol Support for Windows Media Streaming Has Changed
MMS Configurations are Removed on Upgrade
Multicast Station NSC Reference URL Configurations in a Mixed Network
Using Mixed Versions of Windows Media Server
Windows Media Managed Live Programs
Windows Media Services Streaming Media Acquisition
WCCP Transparent Redirection for MMS
Using Windows Media Encoder or Mixed Versions of Windows Media Player
Windows Media Services License Key Interoperability Issues
Content Distribution Manager Interoperability Issues
RAM Requirements for ACNS 5.5 Software and Websense 5.5 Software
Websense Issues When Downgrading to the ACNS 5.0 Software or ACNS 5.1 Software
Media File System Issues When Downgrading to ACNS 5.0 Software
SmartFilter Issues When Upgrading or Downgrading to Another ACNS Software Release
Interoperability with ICAP Vendors
Maximum File Size Supported for ICAP Processing
Matrix of Supported Caching, Filtering, and Authentication Methods
Open Caveats—ACNS 5.5.3 Software
Resolved Caveats—ACNS 5.5.3 Software
Obtaining Documentation, Obtaining Support, and Security Guidelines
Release Notes for Cisco ACNS Software, Release 5.5.3
June 20, 2006
ACNS Release 5.5.3
Revised: March 5, 2007
Note
The most current Cisco documentation for released products is available on Cisco.com.
Contents
This release note contains information about the Cisco Application and Content Networking System (ACNS) 5.5.3 software. This release note describe the following topics:
•
•
Introduction
The ACNS software combines the technologies of demand-pull caching and pre-positioning for accelerated delivery of web applications, objects, files, and streaming media; the ACNS software runs on Cisco Content Engines, Content Distribution Manager, and Content Router hardware platforms, as well as Cisco Wide Area Application Engine appliances.
This release note is intended for administrators who will be configuring, monitoring, and managing devices that are running the ACNS 5.5.3 software. This release note describes the new product features, the supported hardware, and the open and resolved caveats regarding the ACNS 5.5.3 software release.
System Requirements
Table 1 shows the hardware platforms supported in each ACNS software release. An "X" indicates that the software supports the hardware models listed in that row.
Note
Software Component Versions Supported in ACNS Software
Table 2 describes which SmartFilter and Websense versions are supported in the ACNS software releases.
Table 2 Component Versions Supported in ACNS Software Releases
ACNS 5.2.1
Version 4.0.1
Version 5.2
ACNS 5.3.x
Version 4.0.1
Version 5.2
ACNS 5.4.1
Version 4.0.1
Version 5.5.21
ACNS 5.5.1
Version 4.0.1
Version 5.5.2
ACNS 5.5.3
Version 4.0.1
Version 5.5.2
1 The integrated Websense Enterprise software Version 5.5 in the ACNS software requires a minimum of 512 MB of RAM. We recommend that you upgrade the RAM on your device to 512 MB or greater, or move your integrated Websense server to another device that has at least 512 MB of RAM. When additional Websense components are enabled (such as the Network Agent), the ACNS software requires a minimum of 1 GB of RAM.
Note
New and Changed Information
This section describes new and changed features in the ACNS 5.5.3 software release.
New Features in the ACNS 5.5.3 Software
The ACNS 5.5.3 software supports the ACNS 5.5.x Windows Media Services 100 MB licence key for the Network Modules that run ACNS software. (For a list of hardware models supported, see Table 1. For more information about license key issues in the ACNS 5.5.x software, see the "Windows Media Services License Key Interoperability Issues" section.)
Design Limitation for ACNS Object Transfers
By design, ACNS software does not handle the transfer of objects larger than 2 GB. When an object transfer reaches the 2-GB limit, the Content Engine closes the connection to both the client and the server.
Operating Considerations
This section describes information regarding the ACNS 5.5.x software. It includes the following sections:
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Windows Media Transaction Log Forwarding in ACNS 5.5
Windows Media transaction logs are forwarded to a Windows Media Server or an upstream Content Engine only if log forwarding is enabled on both the Content Engine (by using the wmt advanced server log-forwarding enable global configuration command, which is enabled by default) and the Windows Media Server 9 (using the WMS Client logging plugin, which disabled by default). Log forwarding is supported for the RTSP protocol only.
To enable log forwarding on the Windows Media Server Version 9, follow these steps:
Step 1
Step 2
Step 3
Step 4
Step 5
Protocol Support for Windows Media Streaming Has Changed
ACNS 5.5.x software no longer supports the MMS protocol for acquiring or distributing Windows Media content between servers. If you are using MMS-based streaming, you must migrate to RTSP-based streaming or HTTP-based streaming before you upgrade to the ACNS 5.5 software release. (See the Cisco ACNS Software Upgrade and Maintenance Guide, Release 5.x publication for the ACNS 5.5 release.)
MMS Configurations are Removed on Upgrade
Because the MMS protocol is no longer supported in ACNS 5.5.1 or later releases, command options in the Content Engine CLI and Content Distribution Manager GUI that configure the MMS protocol have been removed. If you have these command options configured in an earlier ACNS release, and then you upgrade to ACNS 5.5.1 or later, the MMS configurations are removed. If you downgrade to an earlier release, the MMS configurations are not restored.
You must plan to save your configurations before you upgrade your software to ACNS 5.5.x, if you want to restore MMS configurations after a downgrade.
The Content Distribution Manager automatically creates a database backup file, which you can find in the CLI root directory with a filename similar to the following:
cms-db-03-13-2006-08-30.dumpThe filename contains the date and time that the backup was made. In the example, 03-13-2006 is the date and 8:30 is the time that this data was saved. We recommend that you export a copy of the database backup file before you upgrade your Content Distribution Manager or Content Engines to ACNS 5.5 software.
Note
Multicast Station NSC Reference URL Configurations in a Mixed Network
If you are using a Content Distribution Manager that is running a release prior to ACNS 5.5 (such as ACNS 5.3.x or ACNS 5.4.x) and you are using it to manage Content Engines that are running ACNS 5.5 software, the Content Distribution Manager does not recognize the nsc-reference option of the wmt multicast station-configuration global configuration command. This option is new to the ACNS 5.5.1 release.
If you configure an ACNS 5.5 Content Engine using the wmt multicast station-configuration command without configuring the nsc-reference option, the configuration can be successfully managed by the Content Distribution Manager.
If you configure an ACNS 5.5 Content Engine using the wmt multicast station-configuration command and the nsc-reference option, the configuration is not recognized by the Content Distribution Manager.
If you configured an ACNS 5.5 Content Engine using the wmt multicast station-configuration command without configuring the nsc-reference option, and later you attempt to modify the configuration by adding an NSC reference URL for this station from the Content Engine CLI, the lower version Content Distribution Manager removes the multicast station during the next management system update.
Using Mixed Versions of Windows Media Server
Windows Media Server prior to Version 9.x does not support RTSP, so you cannot use an RTSP source URL with older versions of Windows Media Server. If you have Windows Media Servers in your ACNS network that do not support RTSP, you must use HTTP as the source URL for Windows Media streaming.
Windows Media Managed Live Programs
In ACNS releases prior to ACNS 5.5, MMST was the protocol used for communications between Content Engines for managed live programs. In the ACNS 5.5 release, the protocol for communication between Content Engines has changed to RTSPT. If you are using ACNS 5.5 software on some Content Engines and are using earlier versions of software on other Content Engines in your network, Windows Media managed live programs will fail because the ACNS 5.5 Content Engine will not be able to communicate with ACNS 5.4 or 5.3 Content Engines. If you are migrating to ACNS 5.5 software, you must upgrade all the Content Engines in the Windows Media live channel to ACNS 5.5 software for successful delivery of managed live programs.
HTTP unicast delivery (Unicast in-Unicast out) to the client is not supported for managed live streaming; only RTSP URLs are supported. In the Live Source URL field in the Content Distribution Manager GUI (Services > Video > Programs > Live Streaming), you can have an HTTP or RTSP URL, but in the Unicast URL Reference field and in the Customized URL field only RTSP URLs are allowed.
If MMS is configured in the Live Streaming window (Services > Video > Programs > Live Streaming) before the upgrade, the configuration remains the same after the upgrade to ACNS 5.5 software; however, you cannot modify the source URLs in this window without changing the protocol from MMS to one of the supported protocols in ACNS 5.5 software.
The Content Distribution Manager GUI returns an error message if you try to modify the settings in this window when the MMS protocol is included from a previous release.
Windows Media Services Streaming Media Acquisition
In prior releases, ACNS software supported Content Engine acquisition of Windows Media streaming content. In ACNS 5.5 software, the Content Engine cannot acquire and pre-position Windows Media streaming content.
If an MMS URL is specified as the source URL for a content item in the Channel Content window (Services > Web > Channels > Channel Content) before the upgrade, the configuration remains the same after the upgrade to ACNS 5.5 software; however, you cannot modify the content items in this window until you change the protocol of the URL from MMS to one of the supported protocols in ACNS 5.5 software.
The Content Distribution Manager GUI returns an error message if you try to modify the settings in this window when the MMS protocol is included from a previous release.
WCCP Transparent Redirection for MMS
In the ACNS 5.5 release, WCCP Service 81 and Service 82 for MMS redirection are still valid. If your network is set up for WCCP redirection for MMS, and an MMS request is redirected to the Content Engine, the Content Engine accepts the request and immediately closes the connection. This operation forces the Windows Media client to rollover to RTSP or HTTP to serve the stream.
Note
Using Windows Media Encoder or Mixed Versions of Windows Media Player
HTTP is supported for communications between Windows Media Player and the Windows Media Encoder or between a Content Engine and the Windows Media Player; however, it is not supported for communications between Content Engines.
HTTP is the only mode of data delivery supported by Windows Media Encoders. RTSP is not supported by Windows Media Encoders. ACNS software supports live streams that have Windows Media Encoders as their source. Support for HTTP allows Content Engines to communicate with the Windows Media Encoder.
If Windows Media Player Version 9, or a later version, issues an explicit mmst:// or mmsu:// URL request, the ACNS 5.5 software sends an error message and will not play the stream. If a request contains an mms:// URL, the player uses RTSP or HTTP instead.
When connecting to a publishing point using the MMS protocol, a rollover method is used to obtain the best connection. When a URL in Windows Media Player Version 9, or a later release, specifies an MMS URL (mms://), the Windows Media Player attempts to use the following protocols for media delivery, in the order shown:
1.
2.
3.
4.
5.
Note
Windows Media Services License Key Interoperability Issues
Licenses purchased for Windows Media Services (WMS) in the ACNS 5.5 software and later releases are not supported in ACNS 5.4.x software or earlier releases. However, a Content Distribution Manager running ACNS 5.4 software can configure licenses for both ACNS 5.4 and ACNS 5.5 devices.
One caveat is that an ACNS 5.4 Content Distribution Manager cannot correctly validate ACNS 5.5 license keys. Because the license keys in ACNS 5.5 software are new, they are not recognized by earlier software versions. When you attempt to run a validation check on an ACNS 5.5 WMS license key from the ACNS 5.4 Content Distribution Manager GUI, you will receive an error message stating that you have entered the key incorrectly. (License key validation is optional in the Content Distribution Manager GUI.) (See Table 3.)
You should not attempt to validate ACNS 5.5 license keys with an ACNS 5.4 Content Distribution Manager. You, however, can submit the license key and successfully configure the WMS license for the ACNS 5.5 release from an ACNS 5.4 Content Distribution Manager. To verify that WMT is enabled on a Content Engine in this situation, use the show wmt EXEC command.
If you attempt to configure an ACNS 5.5 (or later release) WMS license key on an appliance that is running ACNS 5.4 software or an earlier release, the license key will fail, and Windows Media Services will not be enabled on that appliance. This failure is logged and can be viewed from Devices > Device Monitoring > Logs in the Content Distribution Manager GUI.
If you have a mixture of ACNS 5.4 and ACNS 5.5 devices in your network and you want to configure licenses by device groups, we recommend that you group devices in the Content Distribution Manager separately by software release in order to avoid an issue with license incompatibility.
Note
Content Distribution Manager Interoperability Issues
A Content Distribution Manager running ACNS 5.4 software can provide a centralized interface for configuring and managing ACNS networks in which some or all of the Content Engines are running ACNS 5.5 software.
A Content Distribution Manager running ACNS 5.5 software can provide a centralized interface for configuring and managing ACNS networks in which all of the Content Engines are running ACNS 5.5 software only. (See Table 4.)
If you are migrating your network to the ACNS 5.5 release, observe the following requirements:
•
•
•
•
RAM Requirements for ACNS 5.5 Software and Websense 5.5 Software
The integrated Websense Enterprise software Version 5.5 in the ACNS 5.5 software requires a minimum of 512 MB of RAM. We recommend that you upgrade the RAM on your device to 512 MB or greater, or move your integrated Websense server to another device that has at least 512 MB of RAM.
When you install or activate additional Websense components for the intergrated Websense server, the ACNS Software requires a minimum of 1GB of RAM.
Websense Issues When Downgrading to the ACNS 5.0 Software or ACNS 5.1 Software
If the local (internal) Websense server is enabled on the Content Engine and you downgrade from the ACNS 5.2.x software to either ACNS 5.0 software or ACNS 5.1 software, the WebsenseEnterprise directory is removed from the Content Engine and the local Websense server stops working. The ACNS 5.2.x software does not generate an error message indicating that the WebsenseEnterprise directory has been removed.
However, in the ACNS 5.3.1 software and later releases, the following error message is displayed to notify you about this Websense downgrade issue:
WARNING:Websense does not support downgradeHence removing /local/local1/WebsenseEnterpriseWebsense will stop working after copy ftp installTo avoid this problem when downgrading from the ACNS 5.3.x or ACNS 5.2.x software to either ACNS 5.1.x software or ACNS 5.0.x software, follow these steps:
Step 1
Step 2
Step 3
Media File System Issues When Downgrading to ACNS 5.0 Software
If you have configured the media file system (mediafs) with the ACNS 5.1 software and later releases, and then downgrade to the ACNS 5.0 software, the mediafs disk space assignment is lost and reverts to the ACNS network file system (cdnfs) disk space. (The mediafs is used for on-demand content that is fetched through the two streaming protocols [RTSP and WMT]. The cdnfs is used for pre-positioned content in the ACNS network.)
This situation occurs because of a design change that was implemented in the ACNS 5.1 software. Because the ACNS 5.0 software is not compatible with this change, the disk space becomes assigned to cdnfs instead of mediafs. To work around this problem, follow these steps:
1.
Use the Content Distribution Manager GUI for Content Engines that are registered with a Content Distribution Manager. Use the Content Engine GUI for standalone Content Engines (Content Engines that are not registered with a Content Distribution Manager and are being managed through the Content Engine GUI or CLI).
2.
SmartFilter Issues When Upgrading or Downgrading to Another ACNS Software Release
When you upgrade or downgrade the Content Engine to a different release of the ACNS software, if there is a difference in the SmartFilter plug-in version, the SmartFilter database and configuration files are deleted and default configurations are loaded. This change occurs because the configuration details might be changed with each new version of SmartFilter software. After each upgrade or downgrade of the SmartFilter plug-in, a fresh database has to be downloaded from the SmartFilter Administration Console to the Content Engine.
Note
ICAP Services
The Internet Content Adaptation Protocol (ICAP) is an open standards protocol for content adaptation, typically at the network edge. Content adaptation includes virus scanning, content translation, content filtering, content insertion, and other ways of improving the value of content to end users. ICAP specifies how a Content Engine, acting as an HTTP proxy server, can communicate with an external device that is acting as an ICAP server, which filters and adapts the requested content.
ICAP provides two content-processing modes for HTTP services. These modes define the transactions that can occur between a Content Engine acting as an ICAP client and an ICAP server. The two modes are as follows:
•
•
Interoperability with ICAP Vendors
The following is a complete list of the ICAP vendors that have been certified to interoperate with the Content Engine:
•
•
ICAP Performance
With the respmod vectoring point, which is used by virus-scanning Internet Content Adaptation Protocol (ICAP) vendors, the performance of the Content Engine model CE-7305 will be 300 transactions per second.
With the reqmod-precache vectoring point, which is used by URL filtering ICAP vendors, the performance of the Content Engine model CE-7305 will drop 20 percent from the rated performance.
Note
Maximum File Size Supported for ICAP Processing
For ACNS 5.4.x software and later, the maximum file size that is supported in the ACNS software is 2 GB. Files that exceed this size limit are not supported for ICAP processing.
For releases prior to ACNS 5.4.x software, the maximum file size that is supported in the ACNS software in pass-through mode is 2 GB. Files that exceed this size limit are not supported for ICAP processing.
Matrix of Supported Caching, Filtering, and Authentication Methods
Table 5 lists the caching, filtering, and authentication methods supported by Content Engines that are running the ACNS 5.5.x software. An asterisk (*) indicates that a feature is supported for that particular protocol.
Caveats
This section lists and describes the new, open, and resolved Severity 1, 2, and 3 caveats in the ACNS 5.5.3 software. Caveats describe unexpected behavior in the ACNS 5.5.3 software. Severity 1 caveats are the most serious; Severity 2 caveats are less serious. Severity 3 caveats are moderate caveats.
Open Caveats—ACNS 5.5.3 Software
This section lists caveats that have not been resolved in the ACNS 5.5.3 software release. The open caveats are grouped into the following categories:
Windows Media Open Caveats
•
Symptom: Windows Media Technologies (WMT) is enabled with no media file system (mediafs) after you downgrade from the ACNS 5.1b300 software to the ACNS 5.0.7b8 software.
Condition: This problem occurs if you upgrade from the ACNS 5.0.7b8 to the ACNS 5.1bx software, configure the disk, and then downgrade to the ACNS 5.0.7b4 software.
Workaround: Reconfigure the disk with a mediafs partition and reload the software.
•
Symptom: Camiant server request validation fails for live content when the URL is requested again.
Condition: This problem occurs when the .asx URL is requested again without the browser cache being cleared.
Workaround: Clear the browser cache after every request.
•
Symptom: The RTSP request fails.
Condition: This problem occurs when the publishing point on a Windows Media server is a URL to source content published on a Content Engine, and the Windows Media server is requesting the content using an RTSPU URL (rtspu://).
Workaround: For the above configuration, Microsoft recommends using RTSPT as the protocol for the URL to the remote source (rtspt://).
•
Symptom: The IXIA Windows Media load tool client does not interoperate with ACNS 5.5.x WMT using RTSP.
Condition: IXIA Windows Media load tool clients are not compatible with the ACNS 5.5.x software because the ACNS 5.5.x software does not start sending RTP packets until after it receives the RTSP SET_PARAMETER logconnectstats. The problem does not occur with Windows Media Players because Windows Media Players send the connectstats.
Workaround: There is no known workaround.
•
Symptom: The RTSPU disallowed counter, in the output of the sh stat wmt error command, does not get incremented when RTSPU is disallowed on the Content Engine. However, the RTSPU request will be blocked.
Condition: This problem occurs with some versions of Windows Media Players 9 and 10.
Workaround: There is no known workaround.
•
Symptom: The live splitting statistics in the output of the show statistics wmt savings command do not get incremented for broadcast-alias requests.
Condition: This problem occurs only when the broadcast alias is configured with a VoD or a proxy source.
Workaround: There is no known workaround.
•
Symptom: Windows Media Player displays "Attempting to reconnect" when playing server-side playlists that contain multi-bit-rate (MBR) streams using RTSP.
Condition: When playing a server-side playlist using RTSP, the Windows Media Player requests an MBR stream switch because of insufficient bandwidth and then later requests the next entry in the server-side-playlist.
Workaround: Start the play again.
•
Symptom: More outgoing bandwidth is consumed than expected.
Condition: Usually, outgoing bandwidth is calculated with consideration for Fast Cache (FC), since data is sent at a higher rate if FC is enabled on the client and on the Content Engine. Since FC is supported only for cache-hit cases, the outgoing bandwidth should be calculated with consideration for FC for cache hit cases only. However, the outgoing bandwidth is calculated with consideration for FC even for cache-miss cases. The bandwidth allocation is reset as soon as playback ends for that stream.
Workaround: There is no known workaround.
•
Symptom: Outgoing bytes are not getting incremented in a timely fashion.
Condition: Outgoing byte statistics are incremented in the CLI only when control events (such as pauses or stops) occur on active streams. This condition occurs during VoD, proxy, or live playback for Windows Media streams.
Workaround: Click any control event, such as pause, and then view the bytes being incremented by using the show statistics wmt bytes outgoing EXEC command.
•
Symptom: The remote HTTP source counter increments for the multicast-in source.
Condition: When a multicast-in source is used for a broadcast alias in the Content Engine, then the By Source of Content field in the show statistics wmt requests command output shows the remote HTTP counter incrementing instead of the multicast counter. This condition is seen in the ACNS 5.5.x software.
Workaround: There is no known workaround.
•
Symptom: The max-obj-size limiting has failed.
Condition: This problem occurs when the max-obj-size is limited and a request is given to the Content Engine.
Workaround: There is no known workaround.
•
Symptom: The Duration field in the show statistics wmt streamstat command output shows a large value for some of the streams.
Condition: This condition occurs in the ACNS 5.5.x software under stress conditions.
Workaround: There is no known workaround.
•
Symptom: Even when a multicast station is removed from the Content Engine, the Current field of the Number of Concurrent Active Multicast Sessions section in the show statistics wmt multicast command output shows a value. The field is not cleared even after you enter the clear statistics wmt command.
Condition: This condition can occur when a multicast station is stopped and removed from the Content Engine.
Workaround: There is no known workaround.
•
Symptom: The incoming bandwidth does not restrict the multicast source.
Condition: This condition occurs when an RTSP source is directed to the multicast station.
Workaround: An HTTP source can be used for the multicast station.
•
Symptom: The outgoing bytes keep incrementing.
Condition: When a multicast station is started and stopped quickly 10 times or more, the Outgoing Bytes field of the show statistics wmt multicast command keeps incrementing even though multicasting is stopped. Also, the Aggregate Multicast-out Bandwidth field is not cleared until the WMT program is restarted.
Workaround: Avoid rapid multiple starts and stops during a WMT multicast program.
•
Symptom: The Windows Media Player stays in the buffering state.
Condition: A stream encoded with video only is played using RTSPU (that is, either the URL is rtspu:// or the URL is rtsp://), and the player advanced statistics indicate that the protocol in use is RTSP (UDP).
Workaround: Use the RTSPT protocol as the protocol for the URL (rtspt://).
•
Symptom: The CE-510, CE-510A, CE-565, and CE-565A platforms go into an inaccessible state during a live split.
Condition: This problem occurs when Windows Media Players request a live stream encoded with multiple bit rates using RTSP (UDP) and not all players are requesting the same bit rate. This problem occurs when the network has high latency and there are increased numbers of RTSP-UDP retransmission requests showing in the player advanced statistics field.
This problem can occur in a few minutes or after many hours, depending on the network conditions, the number of bit rates encoded in the live stream, the number of bit rates requested by the clients, and the number of clients requesting the stream.
This problem has been seen in the ACNS 5.3, ACNS 5.4, and ACNS 5.5 software releases.
This problem has not been seen on any other platforms or if the player uses RTSP (TCP).
Workaround: Reload the Content Engine. Use RTSP (TCP) instead of RTSP (UDP) in the live-split condition.
•
Symptom: The Windows Media Player stays in the buffering state and then disconnects.
Condition: In a very high-latency network (>100 ms), when playback is over RTSP (UDP) for a multi-bit-rate stream, retransmission requests can lag behind and cause this problem.
Workaround: Try the file stream again. Try to alleviate the latency problem. Use rtspt:// in the URL.
•
Symptom: The Windows Media Player plays the stream without a problem. However, the show statistics wmt streamstat command shows that the bandwidth consumption is 0 (zero) and that the stream is in the TEARDOWN state. Also, the bandwidth used by this stream is not counted in the bandwidth consumption statistics, even though the bandwidth is being used. After the user stops playing the stream, no further impact is seen.
Condition: This problem occurs during a long play of pre-positioned content when RTSP is the transport protocol for a multi-bit-rate file, and the Windows Media Player requests multiple stream switches between the bit rates.
Workaround: There is no known workaround.
•
Symptom: The Windows Media Player attempts to reconnect to the stream.
Condition: This problem occurs occasionally when control events such as fast-forward, fast-reverse, or seek are executed on the Windows Media Player for VoD or proxy content playback using MMS-over-HTTP.
Workaround: The Windows Media Player recovers from the error automatically, and there is no disruption in the playback except for a momentary break when the player reconnects to the stream.
•
See CSCse14195.
•
Symptom: The Content Engine sends a 500 error message to one of the clients during a live split of a managed live unicast program.
Condition: This error occurs when the source for the program is a SSPL.
Workaround: If the client receives a 500 error message, send a new request.
•
Symptom: A core file has been seen while running stress testing for server-side play lists (SSPL) with multi-bit-rate (MBR) live content.
Condition: A core file was seen during stress testing of SSPL and MBR live.
Workaround: There is no known workaround.
•
Symptom: The cache-hit counter in the output of the wmt statistics command does not increment.
Condition: There are no specific conditions for this problem.
Workaround: There is no known workaround.
•
See CSCse09222.
•
Symptom: The incoming bandwidth usage statistics for broadcast server-side-playlists continue to increment.
Condition: This problem is seen when there are more than 100 requests for a server-side-playlist that switches streams every 1 minute. This condition is not seen for a lower number of requests.
Workaround: There is no known workaround.
•
Symptom: The RTSP cache-hit playback fails in an outgoing proxy scenario if the URL contains a query string.
Condition: This problem occurs only for URLs of the form rtsp://hostname/filename?name=value in a cache-hit scenario. It will not be seen if the URLs are of the form rtsp://hostname/publishing_point_name/filename?name=value.
Workaround: There is no known workaround.
•
Symptom: The incoming bandwidth usage statistics (viewed by using the show statistics wmt usage command) are incremented for every stream switch made by the live stream. The Content Engine also continues to pull old bit rate selections of the live stream and new bit rate selections, in anticipation of the need to split the stream for new clients requesting the older bit rate selection.
Condition: This condition occurs when the user is playing back a multi-bit-rate live stream, and the Windows Media Player selects different stream selections during the playback period.
Workaround: There is no known workaround.
•
Symptom: The Windows Media Player goes into the buffering state and hangs.
Condition: This problem occurs during a multicast-in and multicast-out play forever program after the end of the first loop.
Workaround: There is no known workaround.
•
Symptom: The Windows Media Player enters the waiting state after a play/pause/play sequence of control events. This problem is seen only when the HTTP protocol is used for a live publishing point hosted on the Windows Media Server.
Note
Condition: This problem occurs when pause and play is used for a live publishing point from Windows Media Server.
Workaround: Instead of using the live publishing point on the Windows Media Server as the source stream, use Windows Media Encoder as the source for the live program.
•
Symptom: The Windows Media Player attempts to reconnect when it reaches an end of stream (EOS) of the broadcast alias.
Condition: This condition occurs only when a multicast stream is used as the source for the broadcast alias in the Content Engine.
Workaround: There is no known workaround.
•
Symptom: The URL signature validation fails for a Camiant server RTSP request.
Condition: This problem occurs when you enter the clear stat all or clear stat wmt command. The next Camiant server RTSP request will fail.
Workaround: Reconfigure one url-signature key ID after you clear the statistics, to ensure that further requests are validated correctly.
•
Symptom: Windows Media RTSP does not work.
Condition: This problem occurs when the user configures ports 5004 and 5005 for another application.
Workaround: Use ports other than 5004 and 5005 for other applications, and allow 5004 and 5005 to be used by Windows Media RTSP.
•
Symptom: The Content Engine appears to be in a hung state and does not respond to ping, Telnet, or to requests.
Condition: This condition occurs when a Content Engine receives 200 live-splitting requests for a combination of fast-switching server-side playlists that have streams switching every 1 minute and that have their multi-bit-rate encoder source encoded with 8 different bit rates.
Workaround: Stop incoming requests from clients. If the software does not recover, reload the Content Engine.
•
Symptom: The Content Distribution Manager GUI accepts a bandwidth rate that is greater than 180 Mbps for the CE-590. If you enter a value that is greater than 180 Mbps, the CLI will fail in the CE-590, and the configuration will be removed from the GUI the next time that the Content Distribution Manager requests a full device statistics update from the CE-590 Content Engine.
Condition: This problem occurs when the value entered in the Bandwidth Rate field in the Modifying Content Service Bandwidth Settings for Content Engine window (Devices > Applications > Bandwidth Schedules) is greater than 180 Mbps for the CE-590.
Workaround: The bandwidth rate for the CE-590 should not exceed 180 Mbps. Use a value from 0 to 180 Mbps.
Further Problem Description: The CE-590 models have a platform limit of 180 Mbps but the GUI accepts a value up to 250 Mbps.
Other Open Caveats
•
Symptom: Content cannot be acquired using strong authentication from secure origin servers that use certificates from nonstandard certificate authorities (CAs). If strong authentication was chosen for content acquisitions from such a site, the acquirer error statistics will contain a 401 (Unauthorized) error code, and the acquirer error log contains the following error message:
Strong Cert Authentication rejects certificate due to error: ssl error codeCondition: This problem occurs if the origin server uses a certificate that is not known as a standard certificate to the ACNS software acquirer. For content acquisition from secure sites over HTTPS using strong authentication, only sites with certificates from standard certificate authorities are supported.
Note
Workaround: Use one of these workarounds:
–
–
•
Symptom: When a Content Engine model CE-565 is attached to a Storage Array SA-7 device, if too large a cache file system (cfs) partition is configured, and a combined streaming and caching workload is used, then a lower HTTP performance is observed.
Condition: This problem occurs when the CE-565 has Windows Media Technologies (WMT) enabled, a combined streaming and caching workload is used, and the Content Engine is attached to an SA-7 device.
Note
Workaround: Allocate less space to the cfs if a Storage Array is attached to the Content Engine.
•
Symptom: The Content Distribution Manager only checks if coverage zone files refer to invalid Content Engines after there is a fresh import. When there is a configuration change that can cause already imported coverage zone files to refer to invalid Content Engines, the Content Distribution Manager does not check or display the correct error message until the next fresh import.
Condition: This problem occurs if there is a coverage zone configuration change that causes already-imported coverage zone files to refer to invalid Content Engines.
Workaround: There is no known workaround.
•
Symptom: The Content Engine stops spoofing the client IP address and uses its own IP address to fetch content from the origin server.
Condition: The http l4-switch spoof-client-ip enable global configuration command turns on IP spoofing on a Content Engine that is functioning as a caching engine. When a rule action use-server global configuration command is used, the Content Engine stops spoofing the client IP address and instead uses its own IP address to fetch the content.
Workaround: Remove the rule configurations.
•
Symptom: The network management system (NMS) host does not know where SNMP traps are coming from.
Condition: This problem occurs if there are two interfaces and you configure interface redundancy using both interfaces. You must use a dummy address for the physical addresses. You then configure a real address that floats between the two interfaces. If you then configure SNMP traps, the traps are being sourced from the dummy address and not the routable address. Therefore, the NMS host does not know where the trap is coming from.
Workaround: Configure the Content Engine to generate SNMP version 2c type trap messages. Because the SNMP version 2c trap message does not contain the IP address of the SNMP agent, the NMS software will use the source IP address of the UDP message to identify the address of the SNMP agent.
•
Symptom: Even though you entered the url-filter wmt bad-sites-deny global configuration command on the Content Engine, the Content Engine is not filtering requests for content that is pre-positioned in its wmt_vod directory.
Condition: This problem occurs in the following situation:
a.
b.
c.
Workaround: Configure the bad site list using mmst://127.0.0.1/wmt_vod/file.asf instead of mmst://Content Engine IP address/wmt_vod/file.asf.
•
Symptom: A WMT live stream in a managed live event environment is accessible for a period longer than the scheduled duration.
Condition: This problem occurs only with WMT live programs that have unicast access enabled. In this situation, streams can be accessible for up to 24 hours after the last playtime of the event if "Auto Delete" is set to true or can be accessible indefinitely if "Auto Delete" is set to false.
Workaround: Control the live-stream source through the schedule for the event. Typically, this process involves starting and stopping the WMT encoder.
•
Symptom: The content replication status can show an incorrect manifest item count.
Condition: This problem can occur if too many channels share the same content (for example, if over 100 channels share the same 30 files in each channel). Even though all 100 channels should show the 30 files that were acquired and distributed, it takes an extended period (days) before the correct manifest item count is displayed.
Workaround: Reduce the number of channels that share the same contents.
•
Symptom: The CPU usage on the Content Engine hits a peak of 100 percent.
Condition: This problem can occur if the internal (local) Websense server is enabled on the NM-CE-BP models.
Workaround: There is no known workaround.
•
Symptom: If you specify foo as a folder URL in the manifest file, and there is a single item redirection from foo to foo/ by the web server, the ACNS acquirer fails to process such redirections and generates a 716 error message. If you are using the quick crawl tool in the Channel Content window, some of the files also report 716 error messages.
Condition: This problem occurs if you are using the quick crawl tool and there is a single item redirect from foo to foo/. However, if foo is a link from a crawl job, single item redirections from foo to foo/ are allowed.
Workaround: Specify foo/ in the manifest file, or specify a crawl job instead of using the quick crawl tool.
•
Symptom: Microsoft NT LAN Manager (NTLM) authentication fails and the pop-up window is displayed again.
Condition: This problem occurs if NTLM authentication is being used and the specified domain name is longer than 50 characters.
Workaround: For NTLM authentication, use a domain controller (DC) that has a domain name shorter than 35 characters.
•
Symptom: Channel routing causes loops for several Content Engines.
Condition: This problem can occur if there are Content Engines that are running the ACNS 5.1.x software or earlier, and these Content Engines are registered with a Content Distribution Manager that is running the ACNS 5.2.x software.
Workaround: Upgrade the Content Engines to the ACNS 5.2.x software. Currently, a Content Distribution Manager that is running the ACNS 5.2.x software does not propagate some configuration changes to Content Engines that are running an ACNS software release earlier than the ACNS 5.2.x software. Therefore, Content Engines that are running the ACNS 5.1.x software or earlier, may not recognize that the root Content Engine was changed from one Content Engine to another. Consequently, routing loops can develop within the system.
•
Symptom: The CMS service on the Content Distribution Manager cannot start and fails to create the CMS database backup file.
Condition: This problem can occur if the ACNS network configuration is very large (for example, with 2000 configured Content Engines) and the sysfs partition is 2 GB or less.
Workaround: Create a sysfs partition that is greater than 2 GB.
•
Symptom: Microsoft NT LAN Manager (NTLM) authentication occurs even though you disabled it on the Content Engine.
Condition: This problem occurs very rarely. In very rare situations, even though you entered the no ntlm server enable global configuration command to disable NTLM proxy authentication on the Content Engine, NTLM proxy authentication is still not turned off. In such cases, NTLM authentication can still occur, although the output of the show running EXEC command shows that the NTLM server is not enabled on the Content Engine.
Workaround: Enter the no ntlm server enable global configuration command again on the Content Engine.
•
Symptom: The ICAP service is enabled on the Content Engine, but the Content Engine is unable to retrieve the content.
Condition: This problem can occur if the Content Engine is running the ACNS 5.x software, and you configure two or more ICAP services to subscribe to the same vectoring point (the response modification [RESPMOD] vectoring point).
Workaround: There is no known workaround.
•
Symptom: A cleanup of the sysfs partition removes all pre-positioned RealMedia contents from the /local1/real_vod/ directory on the Content Engine.
Condition: This problem occurs if the sysfs partition is saturated because of the population of content in the real_vod directory.
Workaround: There is no known workaround.
•
Symptom: The WCCP cache farm (a cluster of Content Engines that are running WCCP) is formed using the assignment method even though you specified the mask-assignment assign-method- strict option when configuring the WCCP service.
Condition: This problem occurs if the WCCP cache farm is associated with Cisco routers instead of switches.
Workaround: There is no known workaround. Mask assignment was only designed for Catalyst 6500 series switches and is not supported by Cisco routers.
•
Symptom: The stream scheduler in the edge Content Engine retrieves stale Session Description Protocol (SDP) information from its forwarder and stores it in its local1/cse_live/ucast folder if the encoding is modified through IP/TV Program Manager. All further RTSP requests are served with this stale SDP content.
Condition: This problem occurs if the stream scheduler retrieves stale SDP information from its forwarder because the program has been edited and the encoding changed for a program. This situation occurs if the Content Distribution Manager notification at the edge Content Engine triggers the stream scheduler before the same occurs at the root Content Engine. Consequently, the edge Content Engine obtains the SDP content from its forwarder, which is valid content at that moment.
Workaround: Reload the Content Engine.
•
The Content Engine becomes unresponsive, and it takes a long time for commands to be executed.
Condition: This problem occurs when the load that is running on the Content Engine is almost as high as the maximum permissible load for a Content Engine, and you then enable ICAP (especially with request modification [REQMOD] transactions). This situation causes the Content Engine to go into an overload state and not recover easily.
Workaround: The load on the Content Engine with ICAP enabled (for the response modification [respmod] transactions) should be kept to 50 percent of the load that it can handle without ICAP.
•
Symptom: A URL in the Synchronized Multimedia Integration Language (SMIL) file that has the "repeatCount" value set, may not be requested as many times as specified by the "repeatCount" setting.
Condition: This problem occurs only when RealPlayer Version 10 is used. The player exhibits the same behavior whether or not there is a Content Engine between the client and the origin server.
Workaround: Use RealOne player instead of RealPlayer Version 10, or request the SMIL file again. The URL will be played at least once in the player.
•
Symptom: An HTTP 1.0 request that is received by the Content Engine from a client web browser is sent as an HTTP 1.1 request by the Content Engine to the origin server.
Condition: This problem occurs only when the ICAP service is enabled on the Content Engine.
Workaround: There is no known workaround.
•
Symptom: The cache process on the Content Engine restarts.
Condition: This problem occurs if a large volume of HTTPS and FTP traffic is being directed to the Content Engine, which is operating in transparent mode.
Workaround: There is no known workaround.
•
Symptom: Even though you entered a write memory command, after an immediate reload, a prompt appears that the configuration has been changed.
Condition: This problem occurs if the following conditions are met:
–
–
–
–
Workaround: Note that ACNS functionality is not affected if this problem occurs. However, if a prompt appears stating that the configuration has been changed, enter yes to save the configuration.
•
Symptom: Unicast access to a live program does not work.
Condition: This problem occurs only when you use special characters ("?" and "#") in the unicast reference URL.
Workaround: To publish a live event, use URLs that do not contain special characters.
•
Symptom: The Content Engine reboots suddenly when you are performing database maintenance.
Condition: The problem can occur because of a platform issue in the power supply of the device.
Workaround: Properly trim the power supply of the Content Engine.
•
Symptom: The proxy autoconfiguration file is missing from the Content Engine after you switch from group settings to device settings, and then switch back to group settings.
Condition: This problem ca
Guest
