|
|
This chapter introduces the Cisco UGCA and presents the following topics:
Cisco UGCA uses call characteristic data to detect service-affecting degradations in call-connection success and call quality, and assists in pinpointing root causes. Data in the form of syslog messages is collected and stored on database servers. A commercial Web browser client allows the user to create, edit, view, run, and export reports for analysis. The application analyzes call detail records (CDRs) that contain the call characteristics.
 |
Note Cisco UGCA is not an element management system (EMS) for Cisco AS5000 series platforms. Rather,
it is an application that complements such products as Cisco Universal Gateway Manager (UGM). If you
require an EMS, refer to Cisco UGM product information at the following URL: http://www.cisco.com/univercd/cc/td/doc/product/rtrmgmt/ugm/ |
Cisco UGCA provides call characteristic reports that classify historical calls by metrics that indicate call quality. If a large percentage of calls fail or have poor quality, the user can generate call-connection reports according to resources and characteristics to determine if the problems are associated with a particular trunk, a modem or universal port, a calling or called prefix (an NPA-NXX number in North America), a service type, or other characteristics. Reports can be run on call volume, call duration, call disconnect reason, Tx/Rx bytes, Tx/Rx rates, modulation type, modem retrains, signal-to-noise ratio, signal quality, and call connection time. A relational database holds the raw data in a documented schema that can be queried.
Table 1-1 lists the gateways and Cisco IOS releases that Cisco UGCA supports. The application requires Cisco IOS Call Tracker (also known as Cisco Call Tracker), which is available on all Cisco AS5000 series platforms since Cisco IOS Release 12.1(3)T. Cisco UGCA supports reports on data collected in Cisco IOS Call Tracker call records and modem call records. (See Role of Cisco IOS Call Tracker.)
|
Note Refer to the release notes for this product for any known issues specific to a given release. |
For supporting documentation, go to the following URLs:
http://www.cisco.com/univercd/cc/td/doc/product/access/acs_serv/5300/index.htm
http://www.cisco.com/univercd/cc/td/doc/product/access/acs_serv/as5350/index.htm
http://www.cisco.com/univercd/cc/td/doc/product/access/acs_serv/as5400/index.htm
http://www.cisco.com/univercd/cc/td/doc/product/access/acs_serv/as5800/index.htm
http://www.cisco.com/univercd/cc/td/doc/product/access/acs_serv/as5850/index.htm
Figure 1-1 illustrates the client-server architecture of Cisco UGCA. The client is a commercial Web browser. The Cisco IOS Call Tracker feature (see Role of Cisco IOS Call Tracker) is used to obtain syslog messages from the gateways in the managed network. Both call records and modem call records from the syslog messages are then parsed and loaded into the database as call data records (CDRs), by means of a utility known as CDR Loader.
|
Note Version 1.0(1) of Cisco UGCA supports only Microsoft Internet Explorer as the client browser and Sun Solaris as the backend operating system. See Prerequisites. |
Table 1-2 summarizes basic Cisco UGCA configuration, installation, maintenance, and troubleshooting tasks discussed in this user guide.
Table 1-2 Basic Cisco UGCA Tasks
Other tasks, such as working with reports and administering user passwords and access privileges, are discussed in the online help within the application.
This section lists and describes the basic report types supplied with the application, followed by useful preconfigured report specifications for call volume and modem call volume. All report types report by DS1 or modem slot/port for any specific gateway or set of gateways. The export function exports each item in a report result. By default, a variety of items are marked up for each CDR (call detail record).
There are three major components to the report processing within Cisco UGCA:
A template for a report specification. Report types define the basic structure of a report, and are predefined with the shipped product.
A named persistent definition of a query, which produces a report result when invoked. Every report has a name, a description, a definition of a query, and a time-coverage parameter associated with it. Report specifications can be run one or more times.
The result of a single invocation of a report specification. Report results are stored as XML documents, with name and contents identifying the report type and the time of invocation, along with the results. Results can be single numbers (scalar values) or tables.
Although the report types are static, the report specifications that are generated from them are not. The report specifications supplied with the product are a set of useful specifications that can cover a wide range of needs. You can copy and edit existing report specifications to meet local requirements, as well as create new ones.
This section presents the following topics:
Table 1-3 lists, in alphabetic order, the basic report types supported by Cisco UGCA, along with descriptions.
|
Note For a technical discussion of how modem and nonmodem report types are differentiated, see How Modem and Nonmodem Report Types Are Differentiated. |
Table 1-3 Report Types Supplied by Cisco UGCA
| Report Type | Description |
|---|---|
Average, minimum, maximum, and sum of call durations. The report uses duration buckets to group calls by user-configurable duration intervals. |
|
Total number of calls and percentage, with breakdown by type of service and modulation type. Type of service includes PPP, multilink PPP, L2TP, tcpClear, and other. For details, see CallVolume Report Specifications. |
|
Average, minimum, maximum, and sum of call durations. The report uses duration buckets to group calls by user-configurable duration intervals. |
|
Total number of calls and percentage with breakdown by type of service and modulation type. Type of service includes PPP, multilink PPP, L2TP, tcpClear, and other. For details, see ModemCallVolume Report Specifications. |
|
Average, minimum, and maximum number of local and remote retrains and retrain failures. |
|
Raw selection of all columns from a join2 of call_record, modem_call_rec, and markup CDR tables. Attributes to specify conditions are subsets of the above columns. No groupings are available. |
|
Average, minimum, and maximum average connection, physical layer steady-state, service establishment, and user-validation times. |
|
Average, minimum, and maximum number of characters transmitted and received. |
|
Average, minimum, maximum, and final receive and transmit rates. |
|
Raw selection of all columns from a join of call_record and markup CDR tables. Attributes to specify conditions are subsets of the above columns. No groupings are available. |
|
Average, minimum, and maximum average connection, physical layer steady-state, service establishment, and user-validation times. |
|
Average, minimum, and maximum number of characters transmitted and received. |
|
Average, maximum, and minimum initial and final receive and transmit rates. |
| 1CallDuration and TxRxChars appear in both call_record and modem_call_rec. The values used depend on which report type—modem or nonmodem—is selected. See How Modem and Nonmodem Report Types Are Differentiated.
2Join means an inner join, which combines records from two tables whenever there are matching values in a common field. |
Table 1-4 lists, in alphabetical order, the CallVolume report specifications supplied by Cisco UGCA, along with descriptions.
|
Note The following are preconfigured examples judged to be useful. Users are encouraged to tailor them to the local environment. |
Table 1-4 CallVolume Report Specifications Supplied by Cisco UGCA
Table 1-5 lists, in alphabetic order, the basic ModemCallVolume distribution report specifications supplied by Cisco UGCA, along with descriptions. All distributions are by number and percentage of calls.
|
Note The following are preconfigured examples judged to be useful. Users are encouraged to tailor them to the local environment. |
Table 1-5 ModemCallVolume Report Specifications Supplied by Cisco UGCA
The use of markup facilitates reporting on data aspects that are not immediately available from the raw data. By default, Cisco UGCA provides markup for the following call-related data aspects in each CDR, listed in alphabetic order:
For the criteria that are used to mark up each of these aspects, refer to "Cisco UGCA Markup: markup.xml and call_record.discid."
Generally speaking, nonmodem report types are of interest when one is looking at the basic characteristics of all call types, whereas modem report types provide in-depth characteristics specific to modem calls.
The differences between, for example, ServiceTime and ModemServiceTime report types, are two-fold, as discussed below. (The same principle applies to CallDuration and ModemCallDuration, CallVolume and ModemCallVolume, and so on.)
The first difference concerns the scope of the data going into the query. The second report runs over an "inner join" operation with modem call records. (An inner join combines records from two tables whenever there are matching values in a common field.) The number of records (and therefore results) is less than the total number of call records. For example, ISDN data calls do not have entries in a modem_call_rec table. The modem report narrows the scope of data passed into the report query, limiting the data to what is relevant to modem calls only.
The second difference concerns the definition of the report specification, that is, the number of modem-specific fields (attributes) in modem_call_rec that are selected for possible conditions and grouping. In this case, a modem report widens the scope of available fields, thus increasing the breadth of the resulting table. This is because modem calls have more fields (all the columns in modem_call_rec) that are irrelevant to nonmodem calls.
The export function exports each item in the report result. The export file format is as follows:
For every call that is terminated, the gateway sends one record—a Cisco IOS Call Tracker call record—to the configured logging host through the syslog logging protocol. If the call is a modem call, the gateway sends another record—a Cisco IOS Call Tracker modem record—to the logging host. The CDR Loader component of Cisco UGCA reads the syslog file, then parses the call record and modem call record and loads them into the database.
Both Cisco IOS Call Tracker and syslog logging must first be enabled on the gateways. See Enable Cisco IOS Call Tracker and syslog on the Gateways.
For additional information about Cisco IOS Call Tracker, refer to Understanding Call Tracker Outputs at the following URL:
http://www.cisco.com/warp/public/471/calltracker_view.html
The above document provides useful links to the following documents that are useful in troubleshooting disconnect reason codes (cause codes) for MICA and NextPort modems:
http://www.cisco.com/warp/public/76/mica-states-drs.html
http://www.cisco.com/warp/public/471/np_disc_code.html
Posted: Thu Mar 27 17:18:26 PST 2003
All contents are Copyright © 1992--2002 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.
