|
|
|
This section describes known issues and suggests workarounds.
CA Performance Center versions 2.0 and 2.1 support only one UC Monitor data source. Support for up to four UC Monitor data sources is expected in a future release of CA Performance Center.
The views in the Unified Communications Dashboards in CA Performance Center impose no limit to the size of a query. You can query a time frame as large or as small as you want. However, performance of these views is adversely affected by query results that are larger than the amount supported by reports in the UC Monitor management console. UC Monitor reports support a maximum of 10 million calls per month. For more information, see the topic "Managing the UC Monitor Database" in the online help or the CA Unified Communications Monitor Administrator Guide.
The Call Quality Breakdown view fails with the following error:
The given key was not present in the dictionary.
The view is available from the Enterprise, Unified Communications, and VoIP dashboards.
Contact CA Support for assistance in resolving this issue.
In CA Performance Center versions 2.0 and 2.1, the pie chart can disappear from the Call Quality Breakdown view in the Unified Communications dashboard in the following situation:
Workaround: Reload the view from the Dashboards menu in CA Performance Center. Then select your date and time options again.
The Midstream Details table identifies the ingress and egress interfaces associated with a medianet-enabled router. Each interface is associated with an ifIndex. If a change to a router’s configuration associates the ifIndex with a different interface, the table is updated to reflect the new interface name. The new interface name may not be the name that you originally associated with the call.
Workaround: None. The inaccurate data is replaced as older midstream data is purged.
For Cisco’s initial support for medianet, the jitter and max jitter values can be high and inaccurate for streams with codecs that use a non-default clock rate. Basically, the router has to assume a certain clock rate. If the clock rate does not match the rate that the codec needs, the resulting jitter calculations are incorrect.
Workaround: Configure IOS to be aware of the clock rate by codec and RTP payload type. Identify the audio and video applications on your network, including the associated codecs, RTP payload types, and clock rates. For more information, see the Cisco document titled Cisco IOS Media Monitoring Command Reference. In the document, search for “clock-rate (policy RTP).”
In our testing, these phones returned incorrect latency values. We have reported this issue to Cisco.
Medianet data can indicate whether a call is a video call or an audio call. If this information is not available from medianet data, UC Monitor bases the call type on the observed bandwidth of the call. Calls with lower bandwidth are classified as audio. Therefore, the number of audio calls listed in reports can be higher than actual. When troubleshooting a call, try filtering by audio media rather than video to find a particular call.
UC Monitor limits call duration to 12 hours. After 12 hours, UC Monitor stops monitoring the call and reports call metrics in the management console. The call duration is inaccurate because the call was not completed. In addition, if the call continues longer than 12 hours, UC Monitor may begin monitoring the call again, with a new origination time.
During automatic database maintenance, the first time that abandoned call data is purged can substantially increase the maintenance period. The purging of three to four million abandoned calls can take 30 minutes more than usual. During a large manual purge of abandoned call data, the management console can time out, although the purge operation continues to run.
If you registered UC Monitor as a data source for CA Performance Center, you can include medianet-enabled devices (midstream devices) in groups. In the Add Device List in CA Performance Center, midstream devices are identified with a type of “Other.” However, if another registered data source has also discovered the device, the device can appear in the Add Device List as a “Router” type.
Logging in to UC Monitor can fail in the following circumstance, although drill-down from CA Performance Center is successful:
Upgrading to UC Monitor 3.3 or later includes an upgrade to SSO version 7.0, which will not override any changes to the SSO configuration. At this point, SSO is improperly configured and UC Monitor will not allow direct logins.
Workarounds:
Note: You cannot perform this workaround after upgrading.
In our testing, we found the following issues:
When short calls are consecutive in environments that reuse ports, such as Avaya environments, UC Monitor may not be able to correlate call legs, including medianet streams, to their respective calls.
The Unified Communications Dashboard page in CA NetQoS Performance Center times out without fully rendering the views when the UC Monitor database contains at least ten million calls and a one-week or longer interval is selected.
Workaround: Split some of the UC Monitor data views into two custom CA Performance Center reports. For example, create a custom report named “Performance” to include the Worst Locations and Worst Phones views. Then, create another report named “Volume” to contain the rest of the views that are associated with the Capacity Planning reports. With fewer views, the dashboard is rendered successfully.
Occasionally, two navigation links do not appear after a Cisco or Avaya call server is discovered:
Workaround: Log out from the management console, and then log back in. If the navigation items are not displayed, edit and save (but do not change) the role for the current user account. The menu items appear the next time that the page is refreshed.
When you add a collector in a Cisco or Avaya environment, a few identifying items are not displayed immediately, such as the collector version and available license values.
Workaround: Click the Update Status button and then reload the collector.
During our tests of calls that passed through an Avaya voice gateway, we saw that maximum jitter values reported in the Call Watch Details report were lower than the average jitter values. After some investigation, we reported this issue to Avaya.
In our testing, we occasionally observed abnormally high values for jitter buffer loss. We determined that the spike in values occurs when there is a mismatch in voice activity detection (VAD) settings between the call server and the gateway. During periods of silence in the conversation, the phone can interpret 0 packets received as 100 percent concealment, which is then factored into the jitter buffer loss total.
Not all Microsoft endpoints that send end-of-call quality reports identify the payload for the inbound call stream. UC Monitor can identify the codec for an inbound stream only when one of the two conversing parties reports the necessary payload information.
The Cisco Unified Personal Communicator sometimes uses the same RTP port for calls. Therefore, if successive gateway calls are made to or from the same CUPC within 5 minutes, UC Monitor may not correlate the call quality statistics correctly.
The default setting in report views is to refresh the browser window every 60 seconds so that new collected data is reflected in the charts. The refresh can be troublesome because it also scrolls the page back to the top.
Workaround: Use the OPTIONS menu on the report page to disable auto-refresh. Then press F5 to refresh the page every few minutes.
When a monitored call is too short to contain enough data for every call quality metric, the call can appear in reports with only a MOS value.
Workaround: Do not try to analyze data from calls with a duration of less than 30 seconds.
| Copyright © 2012 CA. All rights reserved. |
|