Cisco Acano X-series 開発者ガイド

The "recordIndex” can be used to detemine whether the Meeting Server has received
duplicate records.

Note: If you have multiple cdr receivers then the “recordIndex” value can differ for the same
record for different receivers.

This description assumes you only have one receiver. The “recordIndex” within a “<record>”
items determines the sequence of records, starting at “1” for the first record that the Call
Bridge generates, and increasing by 1 for each new record sent. This “recordIndex” value
allows a CDR receiver to determine whether it has received duplicate records; the
combination of session GUID value and recordIndex is unique. The Call Bridgee re-sends
any CDRs for which it had not received a positive acknowledgement from the receiver (a
“200 OK” HTTP response). If a receiver sends such a positive response but that response is
not successfully received by the Call Bridge, the receiver may receive duplicate records – the
“recordIndex” allows the receiver to detect this and not process the 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 include a numeric "numPreceedingRecordsMissing" value in the
"<record>" tag. This signals to the remote receiver that this number of records
(immediately preceding the record in whose header it appears) have been discarded and
are no longer available. A CDR receiver should not see a discontinuity in the “recordIndex”
sequence even in the presence of a non-zero value for “numPreceedingRecordsMissing”.

The record types are described briefly in Table 1 below, and in more detail in

.

Table 1: Overview of Record Types

Record type

Description

callStart

This record is generated when a call is either created or first instantiated from a
coSpace. The record contains the call’s ID, its name, and the ID of any
associated coSpace.

callEnd

This record is generated when a call ends, and typically will be seen after the
last call leg for the call has disconnected. The record contains the call ID, which
should match a call ID in an earlier callStart record, and summary values for the
call, such as the maximum number of call legs that were ever simultaneously
active within the call.

callLegStart

This record is generated when a call leg is first created, because of an incoming
connection, an outgoing call leg being established, or the user of a Cisco
Meeting App connecting to a coSpace. The record contains the call leg ID, the
remote party type (a SIP connection or a Cisco Meeting App device), the remote
party “name” (for instance their SIP URI) and, if meaningful, whether the call leg
was incoming or outgoing.