Understanding Field Data in CMRs
This section lists all the fields contained in a diagnostic record. The field definitions include some basic information about the QoS fields, such as jitter and latency.
The topics covered are as follows:
- Fields contained in the CMR
- How to identify the CDR associated with a CMR
Fields Contained in the CMR
Table 7-12 provides information about each field in a CMR. Each record consists of 17 individual fields. The information provided about each field is as follows:
- The field name or the column names from the database record
- The field type
- The field definition
|
Field Name |
Field Type |
Field Definition |
|---|---|---|
|
cdrRecordType |
Numeric |
Specifies the type of this specific record. It is set to CMR record (2). |
|
globalCallId_ClusterID |
Character |
The name assigned to this cluster. It is unique so that if records are collected from multiple clusters, those from a given cluster can be identified. |
|
deviceName |
Character |
The name of the device from the CallManager Administration database. This field contains up to 129 characters. |
|
globalCallID_callManagerId |
Numeric |
Half of the GCID. It represents the ID of the node that controlled the call corresponding to this record. This should be used in conjunction with the second half of the GCID. |
|
globalCallID_callId |
Numeric |
The second half of the GCID. It is a value that starts at 1 and is serially incremented for each GCID. |
|
nodeId |
Numeric |
The ID of the node within the CallManager cluster where the device from which these diagnostics were collected was registered. |
|
callIdentifier |
Numeric |
A call leg ID that identifies to which call leg this record pertains. (This field is also used to map the CMR record back to the CDR record as noted below.) |
|
directoryNum |
Character |
The directory number of the device from which these diagnostics were collected. |
|
directoryNumPartition |
Character |
The partition of the directory number in this record. |
|
dateTimeStamp |
Numeric |
Represents the approximate time that the device went on-hook. The time is put into the record when the device responds to a request for diagnostic information. The value is a GMT value and is the number of seconds since midnight (00:00:00) January 1, 1970. (It is not always the same as the date and time the call was disconnected; it may be a few seconds later.) |
|
numberPacketsSent |
Numeric |
The total number of RTP data packets transmitted by the device since starting transmission on this connection. If the connection mode was "receive only," the value is zero. |
|
numberOctetsSent |
Numeric |
The total number of payload octets (not including header or padding) transmitted in RTP data packets by the device since starting transmission on this connection. If the connection mode was "receive only," the value is zero. |
|
numberPacketsReceived |
Numeric |
The total number of RTP data packets received by the device since starting reception on this connection. If the connection mode was "send only," the value is zero. |
|
numberOctetsReceived |
Numeric |
The total number of payload octets (not including header or padding) received in RTP data packets by the device since starting reception on this connection. If the connection mode was "send only," the value is zero. |
|
numberPacketsLost |
Signed Integer |
The total number of RTP data packets that have been lost since the beginning of data reception on this connection. This number is defined to be the number of packets expected less the number of packets actually received, where the number of packets received includes any that are late or duplicates. Thus, packets that arrive late are not counted as lost, and the loss might be negative if there are duplicates. The number of packets expected is defined to be the extended last sequence number received less the initial sequence number received. If the connection mode was "send only," the value is zero. |
|
jitter |
Numeric |
An estimate of the statistical variance of the RTP data packet interarrival time measured in milliseconds and expressed as an unsigned integer. The interarrival jitter is defined to be the mean deviation (smoothed absolute value) of the difference in packet spacing at the receiver compared to the sender for a pair of packets. If the connection mode was "send only," the value is zero. |
|
latency |
Numeric |
This field is currently unused and will contain a zero. |
|
Pkid |
Character |
Text string that is used by the CDR database to uniquely identify each row in this table. This text string has no meaning to the call itself. |
The fields in Table 7-12 are arranged to facilitate understanding of the data that is available in the CMR. They are not in the same order as the actual database record.
Note
All numeric fields in the CMR data are actually unsigned integers in CallManager. All character fields in CMR data are defined as 50-character fields, except the deviceName field. All character fields are of varying lengths in CallManager.
You can find more information in RFC 1889, including detailed computation algorithms for number of packets lost, jitter, and latency.
How to Identify the CDR Associated with a CMR
You cannot use any set of CDR data fields to guarantee a positive link between CMR and CDR data if you depend on an exact match between corresponding fields. You can, however, figure it out by using the combination of the GCID, call leg IDs, globalCallId_ClusterID, and the date/time fields that exist in each of the records. The globalCallId_ClusterID field was added to make the records unique across multiple clusters. The combination of the GCID fields and the call leg ID is not unique across time on the same cluster because their values are reset whenever a CallManager node is restarted. If you also consider the dateTimeDisconnect field in the CDR and the dateTimeStamp field in the CMR, it will make a positive match. The date/time field in a CMR might not match exactly the date/time of disconnect in the CDR because they are written separately.
Before the CMR can be written, CallManager must request the data for the CMR from the endpoint device. Some time lapse exists during this request cycle, and if the system clock ticks over a second boundary, the times will differ by a second. If the records have the same GCIDs and call leg IDs and the specified date/time values are within a few seconds of each other, the records are definitely related. It takes CallManager more than 20 seconds to come online after a restart, and it usually takes much longer, depending on the number of devices that are in the database for that system. Given that the IDs match, and the time is not off by more than 10 seconds, the records are related to the same call.