Cisco Acano X-series 開発者ガイド
Cisco Meeting Server Release 2.0 : CDR Guide
8
3 Record Types
CDRs are sent in XML as one or more "<record>" items within a parent "<records>" element.
Each record has an associated "type" value that identifies what it describes, and determines
which fields and attributes should be expected within it.
Each record has an associated "type" value that identifies what it describes, and determines
which fields and attributes should be expected within it.
The encompassing “<records>” element includes:
n
a “session” value that takes the form of a GUID that is unique for that session. The session
GUID is created when the Call Bridge restarts; it will be the same for all active CDR receivers
for a given running Call Bridge instance, but changes when that Call Bridge restarts. It is used
by a receiving device to determine that the records it is receiving are being sent from the
same session on the same device.
GUID is created when the Call Bridge restarts; it will be the same for all active CDR receivers
for a given running Call Bridge instance, but changes when that Call Bridge restarts. It is used
by a receiving device to determine that the records it is receiving are being sent from the
same session on the same device.
n
a Call Bridge GUID if the Call Bridge is in a cluster. This identifies which Call Bridge in a cluster
is sending the record. This remains the same across all restarts of the system. Note that it is
not present in unclustered deployments. The Call Bridge GUID is the same as in the
/callBridges API object.
is sending the record. This remains the same across all restarts of the system. Note that it is
not present in unclustered deployments. The Call Bridge GUID is the same as in the
/callBridges API object.
The “<record>” items includes:
n
a time value at which the record was generated on the Meeting Server. This timestamp is in
RFC 3339 / ISO 8601 format, for instance “2014-02-28T16:03:25Z” for 4:03pm on 28
February 2014). Currently, the Meeting Server always supplies these times in UTC.
RFC 3339 / ISO 8601 format, for instance “2014-02-28T16:03:25Z” for 4:03pm on 28
February 2014). Currently, the Meeting Server always supplies these times in UTC.
n
the “correlatorIndex” that increments by 1 for each new record. Note: the combination of
"session GUID" and "correlatorIndex" uniquely identifies a record across all receivers,
enabling the receiver to determine whether it has received duplicate records.
"session GUID" and "correlatorIndex" uniquely identifies a record across all receivers,
enabling the receiver to determine whether it has received duplicate records.
The “correlatorIndex” starts at “0” for the first record that the Call Bridge generates after
booting up. The “correlatorIndex” for a record is the same across all CDR receivers. Hence
for a receiver that is configured sometime after the Call Bridge has booted, the first record it
receives may not be index 0.
booting up. The “correlatorIndex” for a record is the same across all CDR receivers. Hence
for a receiver that is configured sometime after the Call Bridge has booted, the first record it
receives may not be index 0.
When a receiver successfully receives a record, it needs to send a “200 OK” HTTP response
to the Call Bridge, the Call Bridge then sends the next set of records to the receiver. If the
“200 OK” HTTP response is not successfully received by the Call Bridge, then the Call Bridge
will resend the records resulting in the receiver receiving duplicate records.
to the Call Bridge, the Call Bridge then sends the next set of records to the receiver. If the
“200 OK” HTTP response is not successfully received by the Call Bridge, then the Call Bridge
will resend the records resulting in the receiver receiving duplicate records.
If a remote receiver has been unavailable for a period of time such that the Meeting Server
has not been able to store all of the generated records internally, records pushed to the
remote receiver will show a gap in the “correlatorIndex”.
has not been able to store all of the generated records internally, records pushed to the
remote receiver will show a gap in the “correlatorIndex”.
n
the "recordIndex” has been replaced by the “correlatorIndex”. The "recordIndex” is now
deprecated and may be removed in future releases.
deprecated and may be removed in future releases.
For completeness, the following describes how to use the "recordIndex”.
3 Record Types