Understanding Call Tracker Outputs

Table of ContentsUnderstanding Call Tracker Outputs...............................................................................................................1

Introduction..............................................................................................................................................1Benefits of Call Tracker...........................................................................................................................2.................................................................................................................................................................2

Prerequisites......................................................................................................................................2Hardware and Software Versions......................................................................................................2

Configuration Commands........................................................................................................................2Call Tracker Output.................................................................................................................................3

CALL_RECORD.............................................................................................................................4 MODEM_CALL_REC....................................................................................................................6

Related SNMP MIBs...............................................................................................................................7CISCOCALLTRACKERMIB....................................................................................................8

Related Information.................................................................................................................................9

Cisco Understanding Call Tracker Outputs

i

Understanding Call Tracker Outputs

IntroductionBenefits of Call Tracker

PrerequisitesHardware and Software Versions Configuration CommandsCall Tracker Output

CALL_RECORDMODEM_CALL_RECRelated SNMP MIBs

CISCOCALLTRACKERMIBRelated Information

IntroductionCall Tracker is a subsystem for capturing detailed data on the progress and status of calls, from the time thenetwork access server receives a setup request or allocates a channel, until a call is rejected, terminated, orotherwise disconnected. This data is maintained within the Call Tracker database tables, accessible throughSimple Network Management Protocol (SNMP), Command Line Interface (CLI), or SYSLOG. Sessioninformation for all active calls and calls in the setup state is stored in an active table, while records fordisconnected calls are moved to a history table. Call Tracker is notified of applicable call events by relatedsubsystems such as ISDN, PointtoPoint Protocol (PPP) , Content Switch Module (CSM), Modem, Exec, orTCPClear. SNMP traps are generated at the start of each call, when an entry is created in the active table,and at the end of each call, when an entry is created in the history table. Call Record SYSLOGs are availablethrough configuration which will generate detailed information records for all call terminations. Thisinformation can be sent to SYSLOG servers for permanent storage and future analysis.

The status and diagnostic data is routinely collected from MICA modems is expanded to include newlink statistics for active calls, such as the attempted transmit and receive rates, the maximum andminimum transmit and receive rates, and locally and remotely issued retrains and speedshift counters.This connection data is polled from the modem at userdefined intervals and passed to Call Tracker.

The TCP system has been enhanced to provide additional connection information to Call Tracker,including:

The number and identity of hosts that were attempted before a connection was established, orthe total of failed attempts if no connection was made.

The disconnect reason for active sessions, or the failure reason if the network access serverfailed to connect to a host before timing out.

The source and destination endpoints for active sessions, consisting of the IP addresses andport numbers of the network access server and host.

For more information on CallTracker, refer to the document Call Tracker plus ISDN and AAA Enhancementsfor the Cisco AS5300 and Cisco AS5800.


Benefits of Call Tracker

Makes realtime monitoring of call activity easier and more comprehensive.

Captures data for active and historical call sessions, allowing external applications to access the datausing SNMP, CLI, or SYSLOG.

Provides volume and usage statistics for call management decisions.

Call Tracker is meant to improve and replace the modem callrecord terse feature by providing amore detailed output.

Note: Do not enable both Call Tracker and modem callrecord terse at the same time as they cangenerate similar SYSLOG output resulting in duplicate entries for the same call.

Prerequisites

Before configuring Call Tracker and its associated features, you must complete the following tasks on yournetwork access server:

Configure ISDN and the modems. Refer to the document Configuring an Access Server with PRIs forIncoming Async and ISDN Calls.

Verify that calls can connect to the Network Access Sever (NAS).

Configure SNMP. Refer to the Basic Dial NMS Implementation Guide for more information

Note: This is only needed if you are using Call Tracker through SNMP.

Hardware and Software Versions

The information in this document is based on the software and hardware versions below.

CallTracker was introduced in Cisco IOS Software Release 12.1(3)T.

CallTracker is currently available on the Cisco AS5300, AS5350, AS5400, AS5800 and AS5850platforms.

Use the Software Advisor tool (available to registered customers only) to verify that the Cisco IOS softwareversion and platform you are running supports this feature.

Tip: In the Software Advisor tool, search for the feature named Call Tracker plus ISDN and AAAEnhancements.

Configuration CommandsThis section includes the various commands needed to activate Call Tracker.

calltracker enable


This command enables Call Tracker on the NAS.

calltracker callrecord [quiet]The information provided can be gathered by SNMP and SYSLOG from the call history table of Call Tracker.The terse option generates a brief set of callrecords containing a subset of the data stored within Call Trackerused primarily to manage calls. The verbose option generates a complete set of callrecords containing all ofthe data stored within Call Tracker used primarily to debug calls. With the quiet option, the call record is sentonly to configured SYSLOG server and not to the console. The recommended configuration is:

calltracker callrecord verbose quiet

Note: Call Tracker does not report immediately after a call has disconnected. Because of this, it is importantto configure the history buffer large enough to make sure the data is kept so that it can be reported. CallTracker does not report immediately because it is not a high priority process and, as such, has to wait forsufficient CPU to be available, so it can be up to one minute before it does report. To configure the historybuffer (the maximum number of call entries stored in the Call Tracker history table) you can use the followingcommand:

calltracker history maxsize number

Here, number is the maximum call entries to store in the Call Tracker history table. The valid range is from 0through ten times the max DS0 supported on given platform. A value of 0 prevents any history from beingsaved.

The best configuration for the buffer size is to work out how many calls (maximum) can be received over aone minute period. This should take into account call length , type of call (ISDN is shorter than modem).Also, should a configuration error or hardware failure occur, a higher call rate may happen. Onerecommendation which you could use is four times the number of ports on the platform (4*number of ports).

Use one of the following commands in global configuration mode to configure Call Tracker to give outmodem detail records:

modem linkinfo poll time seconds

or

spe linkinfo poll modem seconds

These commands set the polling interval at which link statistics for active calls are retrieved from the modem.The modem linkinfo poll time command consumes a significant amount of memory, approximately 500bytes for each MICA modem call. Use this command only if you require the specific data that it collects.

The recommended poll time value is 320 seconds.

For more information, refer to the document Call Tracker plus ISDN and AAA Enhancements for the CiscoAS5300 and Cisco AS5800

Call Tracker OutputCall Tracker output is split in the following records


Name Information descriptionCALL_RECORD Generic data shared among all call

categories.

MODEM_CALL_RECORD Overall modem call information.MODEM_LINE_CALL_REC Modem transport and physical layer

information (for indepth debuggingpurposes).

MODEM_INFO_CALL_REC Modem status information (for indepthdebugging purposes).

MODEM_NEG_CALL_REC Client host negotiation information (forindepth debugging purposes).

Note: Records referring to the same call start with same unique value in parameter ct_hndl.

The parameters of the first two records are discussed in more detail below.

CALL_RECORD

Name Information descriptionaccount id Accounting ID of the connection. If no accounting is

configured then a zero (0) is returned.auth How long (in seconds) the connection took to authenticate.

If no authentication is configured this remains 0. Ifauthentication is unsuccessful this number also appears tobe zero.

called Number which was called in order the call to arrive on thehost. This information is only available if passed via thetelecoms network in use.

calling CLI of the call made. This information is only available ifpassed via the telecoms network in use.

category Category the call fell under, such that it could be one of thefollowing IsdnSync, modem or other. There are otherpossible values, however these are the most common.

conn How long the call took to be accepted at the physical layer.This is determined, for example, from the Dchannelresponse time if using Primary Rate Interface (PRI) ISDN.

ct_hndl Unique identifier given to all calls received onto the host.This is reset upon bootup to zero and increments for everycall. If this number wraps only unused numbers are used,thus every call on the host maintains separation.If a SNMP trap is generated it also contains this uniquenumber.

disc code Why the call was disconnected. This is usually quiteaccurate, such that a client and host disconnection areseparated.

disc subsys Which procedure caused the connection to be disconnected.


Even if the remote host or a timeout causes thedisconnection the same reason maybe given, for exampleCSM (Call Switching Module), as it causes thedisconnection.

disc text Text version of disc code. This string is the one to use foran understandable answer for disconnection.

DS0slot/cntr/chan

Which channel of which controller in which slot the callarrive on. This data can be invaluable for debugging failedor troublesome calls.

initrx/txbrate

Initial bit rate for transmit and receive for the connection. Ifthe connection does not use a Digital Signal Processor(DSP), such as ISDN, then the bit rate of the channel in useis returned. This would be for example 64000/64000 for anE1 channel and 56000/56000 for a T1 channel.

ip IP address associated with the call. If no successfulnegotiation was accomplished, then an address of 0.0.0.0 isreturned.

mask Subnet mask associated with the call. If no successfulnegotiation was accomplished, then an address of 0.0.0.0 isreturned.

origin Origin of the call. Currently there are only two possiblevalues, originated and answer. However, at some stage,CallBack may be supported.

phys How long (in seconds) the call was only at the physicallayer. This is usually very short for ISDN type calls , astrainup and negotiation are much faster than analogue.Once a service is running on the call, the timer stops.

resource

slot/portSlot and port of the resource used. This may not berestricted to a modem port, that is, a voice could bereturned.

rx/tx chars Number of characters received and transmitted by the hostmodem. It should be noted that this figure also includes anyauthentication characters and so will not match theinterface counters.

service What kind of service the connect made. If PPP wasrunning, PPP is returned , if the call did not mature to thelevel of a service then 'None' is returned. Another possiblereturn is 'Exec'.

setup Date and time the call connected to the host. No timezoneinformation is given, so any processing must be assumed tobe from 0 hour (GMT), unless otherwise known.

srvc How long (in seconds) it took before a service was runningon the call. The timescale returned by this attribute areusually the same as 'phys' in that they are much shorter forISDN as for analogue.

time How long the connection was established. The time is from


the initial setup to the tear down.userid username associated with the connection. The userid is

returned is returned even if the did not authenticatecorrectly , but did present it as a valid setup.

Example:

08:27:06.229: %CALLTRKR6CALL_RECORD: ct_hndl=162, service=MP, origin=Answer, category=Modem, DS0 slot/port/ds1/chan=3/0/0/30, called=9876543210, calling=0123456789, resource slot/port=1/49, userid=(n/a), ip=217.107.46.28, mask=217.107.46.28, account id=425, setup=07/11/2002 08:22:20, conn=0.01, phys=22.57, service=23.68, authen=23.68, initrx/tx brate=26400/30667, rx/tx chars=982/420, time=279.70, disc subsys=CSM, disc code=0x2, disc text=Received an unexpected onhook event

MODEM_CALL_REC

Name Information descriptioncomp: atmp Compression protocol attempted first.comp: last Compression protocol in use before the call was terminated.comp: supp Compression protocol which could have been supported on

the connection.

ct_hndl Unique identifier given to all calls received onto the host.This is reset upon bootup to zero and increments for everycall. If this number wraps only unused numbers are used,thus every call on the host maintains separation.If a SNMP trap is generated, it also contains this uniquenumber.

disc reason Why the call was terminated. This is not a text string but areturn code. For more information see:

MICA Disconnect reasons NextPort Disconnect reasons

ec: rx bad Number of received EC frames which were considered bad.ec: rx/tx Number of transmitted and received error correction frames.prot: attempt Error correction protocol the client attempted upon initial

connection. This could be the same as 'prot: last', but maynot be.

prot: last Which error correction protocol was in use before the callterminated. This information could be used to help diagnoseEC protocol problems at either the client or host side.

retr: fail Number of retrains that failed.retr: local Number of retrains initiated locally.retr: remote Number of retrains which initiated by the other side.rx/tx brate:desired client

Transmit and receive bit rate that the client wished tomaintain. This may not always be the bit rate that the hostreports, as the host may not train up or down toaccommodate.


rx/tx brate:desired host

Transmit and receive bit rate that the host wished tomaintain.

rx/tx brate:high

Highest transmit and receive bit rate of the connectionencountered for the duration of the call.

rx/tx brate:last

Transmit and receive bit rate of the connection before thecall was terminated.

rx/tx brate:low

Lowest transmit and receive bit rate of the connectionencountered for the duration of the call.

rx/tx chars Number of transmitted and received characters by theconnection. Even if the connection did not completelycorrectly this number will increase.

snr Signal to noise ratio of the received signal.speedshift:fail

Number of speed shifts which failed.

speedshift:local up/down

Number of speed shitfs initiated locally.

speedshift:remoteup/down

Number of speed shitfs which initiated by the other side.

sq Quality of the received signal.std: attempt Connection standard the client attempted.std: init Connection standard initially by the client modem. This

may not be the same as initially attempted, as the client mayfail before a full attempted is made.

std: last Connection standard is use before the call was terminated. Itcould, for example, be 'v34+' or 'V90'.

time(sec) How long the call lasted. This is always returned regardlessof the outcome of trainup or authentication.

v90: client Type of the V.90 client modem.v90: fail V.90 failure.v90: stat Status of V90 before the call was terminated.Example:

08:27:06.229: %CALLTRKR6MODEM_CALL_REC: ct_hndl=162, prot: last=LAPM, attempt=LAPM, comp: last=V.42bisBoth, atmp= V.42bisRX V.42bisTX, std: last=V.90, attempt=V.90, init=V.90, snr=37, sq=6, rx/tx: chars=982/420, ec: rx/tx=46/9, rx bad=0, rx/tx brate: last=26400/30667, low=26400/30667, high=26400/32000, desiredclient=0/26400, desiredhost=32000/28800, retr: local=0, remote=0, fail=0, speedshift: local up/down=0/0, remote up/down=0/2, fail=0, v90: stat=Success, client=Unknown, fail=None, time(sec)=258, disc reason=0x220

Related SNMP MIBsName Information descriptionRFC1406MIB Link state transition


CISCOCALLTRACKERMIB Calltracker informationCISCOMODEMMGMTMIB Modem management informationCISCOPOPMGMTMIB DS0 informationRefer to the Cisco MIB Navigator for more information on MIBs.

For more information on using SNMP Traps refer to the document Cisco IOS SNMP Traps Supported andHow to Configure Them.

CISCOCALLTRACKERMIB

When a call is received by the host, and Call Tracker is configured to send SNMP traps to a host, then thistrap is sent:

Name Information description1.3.6.1.4.1.9.9.9991.1.2.3.1.2 The object ID (OID) of the trap.

.x The ct_hndl assigned to the call.=

Timeticks: (119447) 0:19:54.47 The uptime of the router when the callarrived.

Example:

Mar 12 06:27:00 localhost snmptrapd[28977]: 172.22.35.14: 1.3.6.1.4.1.9.9.9991.1.2.3.1.2.1 = Timeticks: (119447) 0:19:54.47

This trap came from the host 172.22.35.14 and the ct_hndl assigned to the call is 1. Using the ct_hndl, it ispossible to poll further information from the active table as described in the SNMP section. The uptime of thehost when the call arrived was Timeticks: (119447) 0:19:54.47.

When a call is released by or from the system and Call Tracker is configured to send SNMP traps to a host,then this trap is sent.

Name Information description1.3.6.1.4.1.9.9.9991.1.3.8.1.2 The OID of the trap

.x The ct_hndl assigned to the call when it wasactive

=

Gauge: 1 The entry assigned to the call in the historytable.

Example:

Mar 12 06:27:21 localhost snmptrapd[28977]: 172.22.35.14:


1.3.6.1.4.1.9.9.9991.1.3.8.1.2.1 = Gauge: 1

This trap came from the host 172.22.35.14. The original ct_hndl number in this case is 1, and also the entry inthe history table (value returned) is 1. These numbers should always be the same, but this cannot beguaranteed. You can use the number returned to get any further information about the call from the historytable as described in the SNMP section.

Related InformationCall Tracker plus ISDN and AAA Enhancements for the Cisco AS5300 and Cisco AS5800 Basic Dial NMS Implementation Guide Cisco MIB Navigator Cisco IOS SNMP Traps Supported and How to Configure Them Access Technology Support Pages

All contents are Copyright 19922002 Cisco Systems, Inc. All rights reserved. Important Notices and Privacy Statement.


Table of ContentsUnderstanding Call Tracker OutputsIntroductionBenefits of Call TrackerPrerequisitesHardware and Software Versions

Configuration CommandsCall Tracker Output CALL_RECORD MODEM_CALL_REC

Related SNMP MIBsCISCO-CALL-TRACKER-MIB

Related Information

Documents

Understanding Call Tracker Outputs