Cisco Cisco Meeting Server 2000 开发者指南
Cisco Meeting Server Release 2.0 : CDR Guide
6
2 General Mechanism
CDRs are sent out by the Meeting Server over HTTP or HTTPS as a series of XML documents.
When new records are generated, a connection is made to the receiving system and the
receiving system should expect to receive one or multiple records on this connection. When the
Meeting Server has successfully sent a group of records to the receiver, those records are no
longer stored by the Meeting Server, and responsibility for their long-term storage then moves
to the receiving device. The Meeting Server considers the records to have been successfully
sent to the receiver if the HTTP or HTTPS connection has been successfully established, the
XML record data has been sent by the Meeting Server, and the receiver has acknowledged the
data with a "200 OK" HTTP response.
When new records are generated, a connection is made to the receiving system and the
receiving system should expect to receive one or multiple records on this connection. When the
Meeting Server has successfully sent a group of records to the receiver, those records are no
longer stored by the Meeting Server, and responsibility for their long-term storage then moves
to the receiving device. The Meeting Server considers the records to have been successfully
sent to the receiver if the HTTP or HTTPS connection has been successfully established, the
XML record data has been sent by the Meeting Server, and the receiver has acknowledged the
data with a "200 OK" HTTP response.
The Call Bridge supports keepalive connections to allow it to send multiple (batches of) records
on one TCP or TLS connection to a receiver.
on one TCP or TLS connection to a receiver.
Note: In scalable and resilient deployments where multiple Call Bridges act as a single entity,
each Call Bridge provides CDRs for the call legs that it is running. Each CDR identifies the
coSpace ID for the call leg. Then if a call is hosted over more than one Call Bridge, you can
identify the same call on different Call Bridges by the same coSpace ID.
each Call Bridge provides CDRs for the call legs that it is running. Each CDR identifies the
coSpace ID for the call leg. Then if a call is hosted over more than one Call Bridge, you can
identify the same call on different Call Bridges by the same coSpace ID.
2.1 Configuring the Recipient Devices
Note: The list of CDR receivers is held locally to an individual call bridge, it is not stored in the
database shared between clustered call bridges.
database shared between clustered call bridges.
You can use either the Web Admin Interface or the API to configure the CDR receivers.
2.1.1 Using the Web Admin Interface to configure the CDR receivers
To configure the recipient of the CDRs:
1. Open the Web Admin Interface.
2. Go to Configure > CDR settings.
3. In the CDR Receiver Settings section, for each receiver, enter the receiver’s HTTP or HTTPS
URI (see
).
2.1.2 Using the API to configure the CDR receivers
Use the following API objects to enable up to two CDR receivers to be configured for the
Meeting Server:
Meeting Server:
2 General Mechanism