Versions Compared

Old Version 1

changes.mady.by.user Former user

Saved on

compared with

New Version Current

changes.mady.by.user Former user

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 5.3

...

Section

Architecture

Call Detail Recording is included as part of the Management Role bundle of sipXecs and is enabled by default. Roles, sometimes referred to as bundles, are pre-configured and cannot be modified. The Management role, by definition, can only operate on the master(primary) server.
The diagram below provides a high-level view of CDR (service is known internally as CallResolver) and its interactions with Configuration Management.

Configuration

Configuration requirements for CDR are very minimal and can be found in the Configuration management under the System/Servers/Services/CDR.
General settings (i.e. those most likely to be modified) are normally displayed while Advanced settings are only shown when the 'Show Advanced Settings' action (in the upper right hand side of the settings page) is selected.

General settings:
  • Enable Call Detail Records (default checked)
    This setting determines whether or not to monitor call activity and record details in CDR records. This parameter is best left enabled(checked).
  • Purge aged records daily (default checked)
    Purging of records from the database is done to conserve disk space as well as to remove old records which are no longer required. This setting is to enable/disable whether or not to check on a daily basis for old records to be deleted.
  • Purge age for CDRs (default 185 days which is approximately 6 months)
    If purging of old records is selected, this parameter indicates the maximum age(in days) that the records will be kept. Records that are older than this value will be deleted from the database.
  • Logging Level (default NOTICE)
    _The logging level typically does not need to be changed. If a CDR issue occurs and is reproducible, it is often recommended to set the logging level to DEBUG, reproduce the issue and generate a snapshot to be submitted when a problem is to be reported.
Advanced settings:
  • All General settings.
  • Purge age for CSEs (Call State Events)
    Configuration options page is found under Calling / Configuration / Call Detail Records (CDRs). By default CSE / CDR recording is disabled. In order to enable it, check the first three checkboxes shown below. The first screenshot shows typical settings and the second screenshot adds advanced settings.

Navigating to CDR Service

CDR Service Settings

Note: Modifications to these parameters will require a restart of CDR and the Proxy Service. Service interruption is typically between 5 and 10 seconds and no in-process calls are affected.

...

  1. Run pg_ctl as the user "postgres" to tell PostgreSQL to reload the configuration (i.e. >pg_ctl reload -D /var/lib/pgsql/data) No service disruption
  2. Restart the PostgreSQL service (i.e. >service postgresql restart) Service disruption
Recorded call events

SIPXCDR database stores all call events occured during the process of establishing a call. Every call event is saved in the call_state_events table

Analysis

Column event_type holds the event type sent
R - Call Request
T - Transfer call Event
S - Call Established Event
F - Call failed event
E - Normal End Call event

Below is an example with call_state_events table entries given from_url and to_url values. These applies when we try to place a call using a 3PCC

Example:
when from = user1, to = user1 status=R we know that user1 phone is ringing
when from = user1, to = user1 status=S we know that user1 picked up the phone
when from = user1, to = user2 status=R we know that user2 phone started ringing
when from = user1, to = user2 status=S we know that user2 answered the phone

Failure situations:
when from = user1, to = user1, status=F we know that user1 rejected the call
when from = user1, to = user2, status=E we know that user2 rejected the call (if there is no call established event (S) before, we know that user2 never answered the call and rejected it instead. If there is an (S) status event before, then user2 normally ended the call)