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.

Database Information

In openUC / sipXecs 4.6 and prior all CDR information is stored in Postgres.

All the information regarding call events is aggregated in the call_state_events table

On every node where proxy runs, a postgres db server runs too and there are saved all call events processed by that node. There is another process named sipXcallresolver (ruby based) and is started by the CDR service that aggregates all call events from all proxy nodes and saves then in SIPXCDR database - call_state_events table on primary node.
The sipXcallresolver performs another aggregation based on data from call_state_events table and creates CDRs records for history, and saves them in the same database - SIPXCDR, in cdrs table

Additional Information

Configuring Call Detail Records: Configuring Call Detail Recording (CDR)

...

Some more good information:  CDR Extras

Postgres Row Breakdown

Here is a breakdown of the rows:

1.  call_id -                            This is a unique identifier for each call, should be used to filter out duplicates records from the csv file

2. from_tag -           A            A system identifier

3. to_tag -               A  A system identifier

4. caller_aor -            This This is the call originator

5. callee_aor          This is the terminating number

...

   5 | "Test User" <sip:2949@sipx.sipfoundry.org>       | <sip:919703106641@sipx.sipfoundry.org;user=phone>  | 2011-05-03 19:39:40.689 |                                     | 2011-05-03 19:39:40.919 |                    | F           |            403 | Forbidden                     |

...

Call State Events Table

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)