Dialogic ControlSwitch CDR User guide

Dialogic® ControlSwitch™ System

CDR Guide

Revision 2.0

Release 5.10.2

July 2015

www.dialogic.com

Copyright and Legal Notice

in writing from Dialogic Corporation at the address provided below.

All contents of this document are furnished for informational use only and are subject to change without notice and do not represent

a commitment on the part of Dialogic Corporation and its affiliates or subsidiaries (“Dialogic”). Reasonable effort is made to ensure

the accuracy of the information contained in the document. However, Dialogic does not warrant the accuracy of this information and

cannot accept responsibility for errors, inaccuracies or omissions that may be contained in this document.

INFORMATION IN THIS DOCUMENT IS PROVIDED IN CONNECTION WITH DIALOGIC® PRODUCTS. NO LICENSE, EXPRESS OR IMPLIED, BY

ESTOPPEL OR OTHERWISE, TO ANY INTELLECTUAL PROPERTY RIGHTS IS GRANTED BY THIS DOCUMENT. EXCEPT AS PROVIDED IN A SIGNED

AGREEMENT BETWEEN YOU AND DIALOGIC, DIALOGIC ASSUMES NO LIABILITY WHATSOEVER, AND DIALOGIC DISCLAIMS ANY EXPRESS OR

IMPLIED WARRANTY, RELATING TO SALE AND/OR USE OF DIALOGIC PRODUCTS INCLUDING LIABILITY OR WARRANTIES RELATING TO FITNESS

FOR A PARTICULAR PURPOSE, MERCHANTABILITY, OR INFRINGEMENT OF ANY INTELLECTUAL PROPERTY RIGHT OF A THIRD PARTY.

Dialogic products are not intended for use in certain safety-affecting situations. Please see http://www.dialogic.com/company/terms-of-

use.aspx for more details.

Due to differing national regulations and approval requirements, certain Dialogic products may be suitable for use only in specific countries,

and thus may not function properly in other countries. You are responsible for ensuring that your use of such products occurs only in the

countries where such use is suitable. For information on specific products, contact Dialogic Corporation at the address indicated below or on

the web at www.dialogic.com.

It is possible that the use or implementation of any one of the concepts, applications, or ideas described in this document, in marketing

collateral produced by or on web pages maintained by Dialogic may infringe one or more patents or other intellectual property rights owned by

third parties. Dialogic does not provide any intellectual property licenses with the sale of Dialogic products other than a license to use such

product in accordance with intellectual property owned or validly licensed by Dialogic and no such licenses are provided except pursuant to a

signed agreement with Dialogic. More detailed information about such intellectual property is available from Dialogic’s legal department at

6700 de la Cote-de-Liesse Road, Suite 100, Borough of Saint-Laurent, Montreal, Quebec, Canada H4T 2B5. Dialogic encourages all users of its

products to procure all necessary intellectual property licenses required to implement any concepts or applications and does not condone or

encourage any intellectual property infringement and disclaims any responsibility related thereto. These intellectual property licenses may

differ from country to country and it is the responsibility of those who develop the concepts or applications to be aware of and comply with

different national license requirements.

Dialogic, Dialogic Pro, Dialogic Blue, Veraz, Brooktrout, Diva, BorderNet, PowerMedia, ControlSwitch, I-Gate, Network Fuel, Mobile Experience

Matters, Video is the New Voice, Making Innovation Thrive, Diastar, Cantata, TruFax, SwitchKit, Eiconcard, NMS Communications, SIPcontrol,

Exnet, EXS, Vision, inCloud9, NaturalAccess and Shiva, among others as well as related logos, are either registered trademarks or trademarks of

Dialogic Corporation and its affiliates or subsidiaries. Dialogic's trademarks may be used publicly only with permission from Dialogic. Such

permission may only be granted by Dialogic’s legal department at 6700 de la Cote-de-Liesse Road, Suite 100, Borough of Saint-Laurent,

Montreal, Quebec, Canada H4T 2B5. Any authorized use of Dialogic's trademarks will be subject to full respect of the trademark guidelines

published by Dialogic from time to time and any use of Dialogic’s trademarks requires proper acknowledgement.

The names of actual companies and products mentioned herein are the trademarks of their respective owners.

This document discusses one or more open source products, systems and/or releases. Dialogic is not responsible for your decision to use open

source in connection with Dialogic products (including without limitation those referred to herein), nor is Dialogic responsible for any present

or future effects such usage might have, including without limitation effects on your products, your business, or your intellectual property

rights..

ControlSwitch (v.5.10.2) CDR Guide

 Dialogic Inc. Proprietary Page 3

Document History

Revision#

Version Date

Comments

1.17.27

Nov. 2012

This version corresponds to 5.9.0.20. The maximum lengths of fields 130

ingress service, 131 egress service, are set to 599, instead of 1000, in

Oracle database. Added parameter CDR_Delimiter_Replace and

CDR_Newline_Replace.

1.17.28

Feb. 2013

This version corresponds to 5.9.0.20. Added explanation on GCR (Global

Call Reference) in fields

1.17.29

April 2013

Added CDRE application parameter CDR_Checkpoint_After_E_Turn_To_I

2.0

July 2015

Updated for Release 5.10.2

The following two fields have been added to Table 2: iCDR Fields:

 Pre charging vector - iCID

 Pre charging vector - ioi

Refer to www.dialogic.com for product updates and for information about support policies, warranty

information, and service offerings.

ControlSwitch (v.5.10.2) CDR Guide

 Dialogic Inc. Proprietary Page 4

Table of Contents

INTRODUCTION ............................................................................................................................................ 6 1.

1.1 Target Audience .......................................................................................................................................... 6

BAF RECORD ................................................................................................................................................. 7 2.

2.1 Record Format............................................................................................................................................. 7

BAF Record Call Types ............................................................................................................................. 7 2.1.1

Call Type 720 ........................................................................................................................................... 7 2.1.2

Call Type 714 ........................................................................................................................................... 7 2.1.3

Call Type 008 ........................................................................................................................................... 8 2.1.4

Call Type 033 ........................................................................................................................................... 8 2.1.5

2.2 BAF Record Files .......................................................................................................................................... 8

File Creation ............................................................................................................................................ 8 2.2.1

File Naming ............................................................................................................................................. 9 2.2.2

Long Duration Call ................................................................................................................................... 9 2.2.3

File Storage ............................................................................................................................................. 9 2.2.4

File Transmission .................................................................................................................................... 9 2.2.5

CS CDR SPECIFICATIONS .............................................................................................................................. 10 3.

3.1 File Format ................................................................................................................................................ 10

3.2 File Naming Convention ............................................................................................................................ 10

3.3 File Transfer and Storage .......................................................................................................................... 10

iCDR Transfer to Mediation/Billing Platforms....................................................................................... 11 3.3.1

3.4 Record Format........................................................................................................................................... 11

3.5 iCDR Field Description ............................................................................................................................... 11

3.6 iCDR Fields that are XML Strings ............................................................................................................... 23

3.7 Format for Charge Information Field ........................................................................................................ 23

ISUP India .............................................................................................................................................. 23 3.7.1

ISUP Russia ............................................................................................................................................ 24 3.7.2

INAP Prepaid: Furnish Charge Information ........................................................................................... 24 3.7.3

ETSI ISDN Advice of Charge – End of Call (AOC-E) ................................................................................ 24 3.7.4

3.8 Format for Generic Parameter Field ......................................................................................................... 24

P-Asserted-Identity Field in SIP ............................................................................................................. 26 3.8.1

P-Charging-Vector Field in SIP .............................................................................................................. 26 3.8.2

Global Call Reference (GCR) .................................................................................................................. 26 3.8.3

3.9 iCDR Support For Long Duration Calls ....................................................................................................... 27

3.10 Recording Sub-Second Digits for Timestamp Fields in iCDR ..................................................................... 28

3.11 Event Order Field ...................................................................................................................................... 28

3.12 Service Fields ............................................................................................................................................. 29

MAP Optimal Routing ....................................................................................................................... 31 3.12.1

Prompt and Collect ........................................................................................................................... 31 3.12.2

INAP Service ..................................................................................................................................... 31 3.12.3

Set and Bill in Routing Policy ............................................................................................................ 31 3.12.4

3.13 Early Events Field ...................................................................................................................................... 32

ControlSwitch (v.5.10.2) CDR Guide

 Dialogic Inc. Proprietary Page 5

3.14 Calling Card and Collect Call Services. ....................................................................................................... 34

3.15 Release Direction ...................................................................................................................................... 34

3.16 Header and Footer .................................................................................................................................... 35

Data Auditing on iCDR Files by Billing Systems................................................................................. 35 3.16.1

3.17 SS7 Overlap Signaling ................................................................................................................................ 36

3.18 Codec Negotiation ..................................................................................................................................... 36

3.19 Forward Call Indicator ............................................................................................................................... 38

3.20 Backward Call Indicator ............................................................................................................................. 39

3.21 Call Status (Field 7) .................................................................................................................................... 41

3.22 Border Gateway Information .................................................................................................................... 42

3.23 iCDR for INAP Prepaid Calls ....................................................................................................................... 43

Filtering through Field 3, Parent Global Call Id ................................................................................. 43 3.23.1

Data Characteristics of Virtual Half Calls .......................................................................................... 43

3.23.2

Timestamp Fields in Virtual Half Call ................................................................................................ 44 3.23.3

3.24 Packet Statistics Fields and BorderNet 4000 Integration .......................................................................... 44

CONFIGURING EC AND CDRE ....................................................................................................................... 45 4.

4.1 Introduction .............................................................................................................................................. 45

4.2 Event Files and Directories on EC .............................................................................................................. 45

4.3 FTP or SCP? ................................................................................................................................................ 45

4.4 Compressed Event Files ............................................................................................................................ 45

Advantages and Disadvantages of Compressed Event Files ................................................................. 45 4.4.1

Event_File_Compression Configuration on EC and CDRE ..................................................................... 46 4.4.2

EC AND CDRE PARAMETERS ........................................................................................................................ 47 5.

5.1 EC Application Parameters ........................................................................................................................ 47

5.2 Group 1 CDRE Application Parameters ..................................................................................................... 47

5.3 Group 2 CDRE Application Parameters ..................................................................................................... 51

5.4 Group 3 CDRE Application Parameters ..................................................................................................... 53

CDRE APPLICATION PARAMETERS QUESTIONNAIRE .................................................................................... 54 6.

6.1 Do you want to have Call Status ‘E’ iCDR? ................................................................................................ 54

Suggested process on handling Call Status ‘E’ iCDR for customers ...................................................... 54 6.1.1

6.2 Will “Account Code” service be deployed? ............................................................................................... 55

6.3 Should a Call_Status ‘E’ iCDR be final? ...................................................................................................... 55

6.4 Should a Call_Status ‘U’ iCDR be final? ..................................................................................................... 55

6.5 Should a Call_Status ‘R’ iCDR be final? ...................................................................................................... 56

6.6 Should a Call_Status ‘K’ iCDR be final? ...................................................................................................... 56

6.7 Should a Call_Status ‘F’ iCDR be final? ...................................................................................................... 56

6.8 Is customer interested in SS7 Generic Parameters? ................................................................................. 57

6.9 Disk Usage Alarms ..................................................................................................................................... 57

6.10 Should CDRE automatically clean up the disk partition containing iCDR files? ........................................ 58

6.11 Set Other Notable Parameters .................................................................................................................. 58

VALUE-NAME MAPPING FOR ICDR FIELDS ................................................................................................... 60 7.

CDR_LOG TABLE IN DATABASE .................................................................................................................... 93 8.

ControlSwitch (v.5.10.2) CDR Guide

 Dialogic Inc. Proprietary Page 6

Introduction 1.

This document provides a functional description of the ControlSwitch Event Collection and CDR

Manager Subsystems, and details the following CDR types:

 BAF. Bellcore AMA Format (BAF

1

).

 iCDR. Dialogic’s proprietary CDR format.

1.1 Target Audience

This document contains information that is confidential to Dialogic. The targeted audience includes

customers and networks partners who are involved in billing-related applications.

1

BAF (Bellcore AMA Format) is a standard developed by Telecordia/Bellcore.

ControlSwitch (v.5.10.2) CDR Guide

 Dialogic Inc. Proprietary Page 7

BAF Record 2.

BAF (Bellcore AMA Format) is a standard developed by Telecordia/Bellcore. It is the most commonly

used billing standard in USA. This section outlines the BAF call types and structure codes generated by

the ControlSwitch. It is intended for a reader with a clear understanding of BAF concepts. Please refer to

GR1100- Core for description of the BAF related terminologies.

2.1 Record Format

ControlSwitch produces BAF records for the following call types.

BAF Record Call Types 2.1.1

The following table lists the BAF record call types:

Call Type

When it is Created

714

When the DN is not toll-free and the call is not a directory assistance call and the

call originated on a DAL/PBX trunk

720

When call is received over connecting network access incoming trunk

008

When the DN is toll-free

033

When call is Directory Assistance

Call Type 720 2.1.2

The BAF record for call type 720 contains one structure with code 0625. This record may contain the

following modules depending on the various services involved in a call.

Code

Module Name

When Created

022

Long Duration

Connection

This module is attached in all continuation CDRs for long duration

calls

028

Additional Digits Dialed

When the dialed number is international and the total number of

digits are more than 10 then the extra digits are stored here

070

ISDN Core

This module is attached if a call is released with a cause code.

164

E.164/X.121 Number

Module

This module is attached when the Calling Party Number (CPN) is

present. The module contains information on CPN

720

LNP Module

Produced when an LNP query is performed by the ControlSwitch to

determine the recipient switch. This module is also produced when

LNP query is performed before the call reached the ControlSwitch as

indicated in JIP.

000

Final Module

Always attached if one of the above module is present

Call Type 714 2.1.3

The BAF record for call type 714 contains one structure with code 0625. This record may contain the

following modules depending on the various services involved in a call.

ControlSwitch (v.5.10.2) CDR Guide

 Dialogic Inc. Proprietary Page 8

Code

Module Name

When Created

022

Long Duration

Connection

This module is attached in all continuation CDRs for long duration

calls

028

Additional Digits Dialed

When the dialed number is international and the total number of

digits are more than 10 then the extra digits are stored here

070

ISDN Core

This module is attached if a call is released with a cause code.

164

E.164/X.121 Number

Module

This module is attached when the Calling Party Number (CPN) is

present. The module contains information on CPN

720

LNP Module

Produced when an LNP query is performed by the ControlSwitch to

determine the recipient switch. This module is also produced when

LNP query is performed before the call reached the ControlSwitch as

indicated in JIP.

000

Final Module

Always attached if one of the above module is present

Call Type 008 2.1.4

The BAF record for call type 008 contains one structure with code 0079. This record may contain the

following modules depending on the various services involved in a call.

Code

Module Name

When Created

720

LNP Module

Produced when an LNP query is performed by the ControlSwitch to

determine the recipient switch. This module is also produced when

LNP query is performed before the call reached the ControlSwitch as

indicated in JIP.

000

Final Module

Always attached if one of the above module is present

Call Type 033 2.1.5

The BAF record for call type 033 contains one structure with code 0028. This record for call type 033

may contain the following modules depending on the various services involved in a call.

Code

Module Name

When Created

720

LNP Module

Produced when an LNP query is performed by the ControlSwitch to

determine the recipient switch. This module is also produced when

LNP query is performed before the call reached the ControlSwitch as

indicated in JIP.

000

Final Module

Always attached if one of the above module is present

2.2 BAF Record Files

File Creation 2.2.1

The BAF CDR file is contiguously populated. AMA CDRs are not split in multiple files. The CDR Manager

creates a new file and fills it up with BAF CDRs and closes at a configurable interval. The closed file only

contains completed CDRs. At the completion of 1-minute, the file is closed after the last BAF CDRs is

fully written.

ControlSwitch (v.5.10.2) CDR Guide

 Dialogic Inc. Proprietary Page 9

File Naming

2.2.2

Files are named using a period “.” to delimit the various fields:

[source, 6 digits].[destination, 6 digits].[File Sequence Number, 6 digits].[File Type, 2 digits].[File

Sequence Number Restart Indicator, 1 digit]

The following table shows the File Name Field Coding Sizes and their Acceptable Values.

Field

Size (digits)

Encoding and explanation

Source

6

01yyyy, where yyyy uniquely identifies the CDR generator

starting from 0001

Destination

6

02yyyy, where yyyy uniquely identifies the Receiving system

File Sequence Number

6

A monotonically increasing number starting from 1 to

999,999 which then restarts at1

File Type

2

05

File Sequence Restart

Indicator

1

If GS loses track of File Sequence and re-creates a sequence

(the requirement for re-creation below) then this field is

populated to 1, the default when re-creation is not done is 0

Long Duration Call 2.2.3

Following the specification contained in GR-508-CORE, the CDR Manager starts generating BAF CDRs for

long duration calls at the scheduled record generation time of 00:00:00 (or 12 AM) each day. Starting

from 12 AM, CDR Manager will go over each live call, and generate a CDR for the call according to the

specification in GR-508-CORE. If a call has lasted over 24 hours and no CDR was generated before the

scheduled record generation time, then the first CDR will be generated. After the first CDR, a

continuation CDR will be generated after each 24-hour period while the call is still alive, and after the

call is released.

File Storage 2.2.4

When the CDR Manager loses track of File sequence, it re-creates the next file sequence based the

filename of saved CDR files in its system, and generates the next file sequence and marks the File

Sequence Restart Indicator as 1. The CDR files are saved in a directory called Primary. Once a CDR file is

successfully sent to billing (via TFTP) it is moved into the Secondary directory. The operator should

regularly remove files from the secondary directory as disk space becomes full.

File Transmission 2.2.5

CDR Manager is capable of transmitting BAF files to a billing system through TFTP. It initiates transfer of

file to the remote system 1 minute after it is created, and places the transferred file into the Secondary

directory after it has successfully transferred that file to billing. The files are sent in the same sequence

as they are generated.

ControlSwitch (v.5.10.2) CDR Guide

 Dialogic Inc. Proprietary Page 10

iCDR Specifications 3.

3.1 File Format

ControlSwitch uses a proprietary format to store call data. This format is called iCDR. The details about

iCDR record format are described in section 3.4.

An iCDR file contains a set of iCDR records. Each individual CDR is then delimited with an end of line

character to allow the downstream billing system to parse the records.

3.2 File Naming Convention

iCDR files are created with a 1-minute granularity (meaning one new file is made for every chronological

minute). The iCDR files are named as follows:

icdr.version_number.zone_id.cdr_id.timestamp.sequence.new_sequence_indicator.

For ControlSwitch 5.10.2, the version_number portion is “5_10_2A”. The zone_id portion contains the id

of the zone the CDRE is in. A zone is a group of ControlSwitch elements with only one EMS element in

the group, and that EMS element controls all the other elements in the group. The cdr_id portion

contains the id of the CDRE. The timestamp portion has the format <yyyymmddhhmm> that contains

four-digit year value, and two-digit month, day, hour and minutes. The sequence portion is a six-digit

sequence number for iCDR files. The last portion new_sequence_indicator is either zero or one. If

new_sequence_indicator is zero, it means that the sequence portion should be one plus the sequence of

the previous iCDR file, or 000001 if the sequence of the previous iCDR file is 999999. If

new_sequence_indicator is one, it indicates the start of a new sequence and the sequence should be

000001.

The file currently being written to by the CDR Manager will have a “.curr” extension to differentiate it

from older, closed files.

3.3 File Transfer and Storage

The iCDR files are stored in a directory path located in the SUN computer running the CDR Element. The

directory path is:

/cdr/ICDR/primary

The file with iCDR(s) is contiguously populated. An iCDR(s) is not split into multiple files. The CDR

Manager creates a new file and fills it up with iCDRs and closes it every minute, by default. At the

completion of the 1-minute interval, the file is closed after the last iCDR is fully written. The maximum

amount of time the CDR Manager keeps an iCDR file open is configurable.

It is assumed that billing system will periodically poll the iCDR storage location and get iCDR files when

available, through FTP. When the billing system has completed the transfer of closed iCDR files, it can

either delete them or move them to the directory /cdr/ICDR/secondary. We recommend customer’s

backup the iCDR files in /cdr/ICDR/secondary and then delete them periodically in order to prevent the

disks from being filled up. CDR Element will keep creating new iCDR files in /cdr/ICDR/primary directory,

and NOT move or remove any iCDR files in either /cdr/ICDR/primary or /cdr/ICDR/secondary directories.

It is up to the user to make sure there is ALWAYS sufficient free disk space on the disk where directory

/cdr/ICDR is located.

ControlSwitch (v.5.10.2) CDR Guide

 Dialogic Inc. Proprietary Page 11

iCDR Transfer to Mediation/Billing Platforms

3.3.1

The billing/Mediation platforms need to pull the iCDR files from the CDR Element platform. The

following is a sample implementation of such iCDR transfer application using File Transfer Protocol

utility (FTP).

1. Open an FTP session with the computer that contains iCDR files using IP address, username and

password.

2. Get a list of files at directory: /cdr/ICDR/primary.

3. Loop through the list of files. For each file in the list, if the file name ends with “.curr”, ignore it.

Otherwise first use GET command to retrieve the file, and then use MOVE command to move the

file to directory: /cdr/ICDR/secondary.

4. Repeat the process by going back to step 2.

3.4 Record Format

iCDR is a generic record that is designed to support billing for all the call types/services supported by the

ControlSwitch and contains all the billing related data collected by the EC(s). iCDR fields are described in

detail iCDR Field Description.

iCDR text string contains only the data values of the fields. Fields are separated by semi-colon (;). The

data values are presented in an ascending order based on their field ids (Table 2)

The type of data collected varies depending on the signaling protocols used in a given call. For example,

incoming carrier related information such as Carrier Identification Code, Carrier Selection Indicator are

only available for FGD or Carrier Origination Calls. Consequently, iCDR for any specific call will have

empty values for some fields. Within an iCDR, if a given field’s data value is empty or null, then only the

field separator (semi-colon) is inserted.

Certain field may contain a group of data structured in a hierarchy. Such fields are called complex fields

and they are presented in XML format. There is a detailed description in this document for each

complex field.

For many iCDR fields, how to populate them can be controlled through CDRE Application Parameters. A

complete description of these Application Parameters is contained in the EC and CDRE Parameters.

3.5 iCDR Field Description

This section outlines:

 iCDR Field Type (Table 1)

 Fields included in the iCDR (Table 2)

 Encoding of iCDR Fields (Table 3 to Table 16)

Field Type

Max. Chars

Type

Reference

Ingress Forward Call Indicator

149

CHAR[180]

See Forward Call Indicator

Egress Backward Call Indicator

150

CHAR[180]

See Backward Call Indicator

Field Data Type

Max. # of chars

Description

WORD32

10

Unsigned decimal number

WORD64

20

Unsigned decimal number

ControlSwitch (v.5.10.2) CDR Guide

 Dialogic Inc. Proprietary Page 12

WORD16

5

Unsigned decimal number

ENUM

5

Unsigned decimal number. There is a table that associates each numeric

value to a string, indicating the meaning of the numeric value.

CHAR[L]

L

Alpha numeric string

TIMESTAMP

19

A string with the following format:

YYYY-MM-DD+HH:MI:SS

YYYY - 4 digit Year

MM – 2 digit Month

DD – 2 digit Date

HH – 2 digit hour

MI – 2 digit minute

SS – 2 digit seconds

Table 1: iCDR Data Type Description

All fields in iCDR record are presented in a readable format. If a field has Data Type CHAR[22], it means

the field is a string of up to 22 characters. If you need to write a parser for iCDR, we suggest you use

what’s in the first column in the above table as the binary field type.

Name

Field-id

Data Type

Description

Zone id

1

WORD64

This identifies the ControlSwitch zone that generated this

iCDR. This field is always 0.

Record Sequence

Identifier

2

WORD64

Sequence for this iCDR. This sequence starts from 1, and

wraps around to 1 after 9999999.

Parent Global Call

Identifier

3

CHAR[22]

A string of 22 characters that identifies the “parent call”’s

Global Call Identifier. This field is populated only if the call is

either the “parent call” or a “child call” in a INAP prepaid call

scenario. In the iCDR for the “parent call”, the value in this

field would be identical to the value in the Global Call

Identifier field. In the iCDR for the “child call”, this field

would contain the parent call’s Global Call Identifier, which

would be different from the value in the Global Call

Identifier field. This field is used to correlate several

independent iCDR for billing purpose. See “Data

Characteristics of Virtual Half Calls” section for more detail.

Global Call Identifier

4

CHAR[22]

A string of 22 characters. Uniquely identifies a call.

Last Received Update

Time Stamp

5

TIMESTAMP

This is the time when iCDR was last updated.

Event Order

6

CHAR[100]

Contains information on what events are collected in this

record. See the “Event Order Field” section for detail. If you

want to replace this field by the old “component indicator”

field (See Table 3), you need to set application parameter

“ICDR_FIELD_EVENT_Order” to 0 in file cdra.cfg.

CDR Status

7

CHAR[2]

See the “Call Status (Field 7)” section for detail.

Call Type

8

ENUM

Type of Call (Table 10).

Calling party number

9

CHAR[24]

Calling Party Number

Charge Number

10

CHAR[24]

Charge Number

ControlSwitch (v.5.10.2) CDR Guide

 Dialogic Inc. Proprietary Page 13

Called Party Number

11

CHAR[32]

Post Digit Analysis Called Party Number.

Nature of Address for

Called Party Number

12

ENUM

Nature of address for called party number, see Table 11

Originating Line

Information

13

CHAR[24]

OLI in incoming IAM for SS7 originating calls or 0 (Identified

Line) for non-ISUP originating calls. This field is for ANSI ISUP

only. See Table 13: Trunk Group Type

Ingress LRN

14

CHAR[24]

If the Called Number of an incoming call was ported before

reaching ControlSwitch, this field contains the ported

number. Otherwise, the field contains null.

Ingress Carrier

Identifier Code

15

CHAR[24]

Carrier identification code in the incoming call.

Ingress Carrier

Selection Information

16

WORD16

Carrier Selection Info Received in the incoming signaling. See

Table 14 for more details.

Ingress Call Control

Element ID

17

WORD32

Ingress Call Control Element Identifier. This field identifies

the Call Control Element or IP Call Element that was

handling the ingress side of this call.

Ingress Trunk Group

Protocol

18

ENUM

Signaling protocol, see Table 12.

Ingress Trunk Group

Type

19

ENUM

Trunk group type, see Table 13

Ingress Trunk Group Id

20

WORD32

The Trunk Group Identifier for the Ingress Trunk. This

number is generated by the EMS when the trunk group was

provisioned.

Ingress Signal Start

Time Stamp

21

TIMESTAMP

See Table 4 for the meaning of this field in the context of

various signaling protocols.

Ingress Gateway Id

22

WORD32

Gateway number assigned by the EMS at the time of the

Media Gateway provisioning.

Ingress Card Id

23

WORD32

Ingress Span Id

24

WORD32

Ingress Channel

Number

25

WORD32

Ingress D Channel

26

WORD32

D Channel number for ISDN calls

Ingress ISDN Call

Reference Number

27

WORD32

Call Reference number for ISDN calls

Ingress Create

Connection Complete

Time Stamp

28

TIMESTAMP

Time Create Connection Acknowledgement is received by

CCP from media gateway.

Ingress Address

Complete Time Stamp

29

TIMESTAMP

See Table 4 for the meaning of this field in the context of

various signaling protocols.

Ingress Call Answer

Time Stamp

30

TIMESTAMP

See Table 4 for the meaning of this field in the context of

various signaling protocols.

Egress Calling Party

Number

31

CHAR [24]

Egress Calling Party Number.

ControlSwitch (v.5.10.2) CDR Guide

 Dialogic Inc. Proprietary Page 14

Terminating Local

Routing Number

32

CHAR [24]

Local Routing Number of the Called Number. This number is

present only if the dialed number is ported and

ControlSwitch performed a Local Number Portability query

to determine the recipient switch of the Dialed number.

Translated Carrier

Identification Code

33

CHAR [24]

For Feature Group D Origination Calls, the Carrier

Identification Code used in routing the call.

Ingress Call Release

Time Stamp

34

TIMESTAMP

See Table 4 for the meaning of this field in the context of

various signaling protocols.

Ingress Release

Complete Time Stamp

35

TIMESTAMP

See Table 4 for the meaning of this field in the context of

various signaling protocols.

Ingress Release Cause

Code

36

WORD32

Cause code for Release. See Table 16

Egress Call Control

Element ID

37

WORD32

Identifies the Egress Call Control Element ID or the Egress IP

Call Control Element ID.

Egress Trunk Protocol

38

ENUM

Signaling protocol. See Table 12 for detail

Egress Trunk group

Type

39

ENUM

Trunk group type. See Table 13 for detail

Egress Trunk Group Id

40

WORD32

This number is assigned by the EMS at the time of the

provisioning.

Egress Call Start time

stamp

41

TIMESTAMP

See Table 4 for the meaning of this field in the context of

various signaling protocols.

Egress Gateway_ID

42

WORD32

Gateway number

Egress Card Id

43

WORD32

Card number

Egress Span Number

44

WORD32

Span number

Egress Channel

Number

45

WORD32

Channel number

Egress D_Channel

Number

46

WORD32

D Channel number for ISDN call

Egress ISDN Call

Reference

47

WORD16

Call Reference number for ISDN call

Egress Create

Connection Complete

Time Stamp

48

TIMESTAMP

Time Create Connection Acknowledgement is received from

media gateway

Egress Address

complete Time Stamp

49

TIMESTAMP

See Table 4 for the meaning of this field in the context of

various signaling protocols.

Egress Call Answer

Time Stamp

50

TIMESTAMP

See Table 4 for the meaning of this field in the context of

various signaling protocols.

Egress Call Release

Time Stamp

51

TIMESTAMP

See Table 4 for the meaning of this field in the context of

various signaling protocols.

Egress Release

Complete Time Stamp

52

TIMESTAMP

See Table 4 for the meaning of this field in the context of

various signaling protocols.

Egress Release Cause

Code

53

WORD32

Cause code for Release. See Table 16 for detail.

ControlSwitch (v.5.10.2) CDR Guide

 Dialogic Inc. Proprietary Page 15

Last Ingress Check

Point Time Stamp

54

TIMESTAMP

The time stamp of the last ingress Check Point message. See

the “iCDR Support for Long Duration Calls” section for detail.

Last Egress Check Point

Time Stamp

55

TIMESTAMP

The time stamp of the last egress Check Point message. See

the “iCDR Support for Long Duration Calls” section for

detail.

Ingress Gateway Name

56

CHAR [50]

If the ingress protocol is H323 or SIP, this field contains the

name of the ingress local media gateway. This field is not

populated otherwise.

Egress Gateway Name

57

CHAR [50]

If the egress protocol is H323 or SIP, this field contains the

name of the egress local media gateway. This field is not

populated otherwise.

Ingress Trunk Group

Name

58

CHAR [50]

The name of the ingress trunk group assigned by user on

EMS.

Egress Trunk Group

Name

59

CHAR [50]

The name of the egress trunk group assigned by user on

EMS.

Originating Gateway IP

address

60

CHAR [23]

IP address and port of the originating H323 or SIP gateway

outside ControlSwitch. This field is null if the ingress

signaling protocol is not H323 or SIP. This field has the form

“IP_address:Port_number”, for example “10.11.12.13:2750”.

Terminating Gateway

IP address

61

CHAR [23]

IP address and port of the terminating H323 or SIP gateway

outside ControlSwitch. This field is null if the egress

signaling protocol is not H323 or SIP. This field has the same

form as in field 60.

H323 Conference Id

62

CHAR [32]

Conference Id of an H323 Call. It is usually a number

expressed in the hexadecimal form with 16 characters.

Ingress Card Port

Number

63

WORD32

This field is valid only for optical TDM interface on an I Gate

4000 series media gateway.

Ingress Card Path

Number

64

WORD32

This field is valid only for optical TDM interface on an I Gate

4000 series media gateway.

Egress Card Port

Number

65

WORD32

This field is valid only for optical TDM interface on an I Gate

4000 series media gateway.

Egress Card Path

Number

66

WORD32

This field is valid only for optical TDM interface on an I Gate

4000 series media gateway.

Ingress Trunk Group

Number

67

WORD32

This field contains the Trunk Group number assigned by user

through EMS.

Egress Trunk Group

Number

68

WORD32

This field contains the Trunk Group number assigned by user

through EMS.

Original Dialed

Number

69

CHAR [32]

Original Dialed Number before Digit Analysis.

Original Dialed

Number Nature of

Address

70

ENUM

Nature of Address of the Original Dialed Number. See Table

11.

Redirecting

Information

71

CHAR [150]

This field is a composite field. It is either Null (empty string)

or a string with the format

sub field 1…sub field 9

The following 9 rows explain the 9 sub fields. Note that for

ControlSwitch (v.5.10.2) CDR Guide

 Dialogic Inc. Proprietary Page 16

the sub fields, the field ids are 71.1, …, 71.9. This field may

have a non-empty value only when the ingress signaling

protocol is a version of ISUP, PRI or SIP.

Redirecting Number

71.1

CHAR [24]

Redirecting Number from ingress side.

Redirecting Number

Nature of Address

71.2

ENUM

Nature of Address of the Redirecting Number from ingress

side. (see Table 17: Bearer Capability

)

Redirecting Indicator

71.3

ENUM

Redirecting Indicator from ingress side. (see Table 18:

Generic Number Nature of Address

)

Redirecting Reason

71.4

ENUM

Redirecting Reason from ingress side, see Table 20)

Original Called Number

71.5

CHAR [24]

Original Called number from the ingress side.

Original Called Number

Nature of Address

71.6

ENUM

Nature of Address of the Original Called Number from the

ingress side. (see Table 17: Bearer Capability

)

Original Redirecting

Reason

71.7

ENUM

Original Redirecting Reason from the ingress side. (see Table

20)

Redirection Counter

71.8

WORD32

Redirection counter from ingress side.

Presentation Indicator

for Redirecting

Number

71.9

ENUM

The value of this field can be 0 or 1. Value 0 means

“Allowed”. Value 1 means “Restricted”

Jurisdiction Parameter

from Ingress

72

CHAR [32]

Jurisdiction Parameter from ingress side. This field may have

a meaningful value only when the ingress signaling protocol

is ANSI ISUP.

Jurisdiction Parameter

from Egress

73

CHAR [32]

Jurisdiction Parameter from egress side. This field may have

a meaningful value only when the egress signaling protocol

is ANSI ISUP.

Ingress trunk bearer

capability

74

ENUM

See Table 17

Egress trunk bearer

capability

75

ENUM

See Table 17

Transit Network

Selection Carrier Code

76

CHAR [24]

Transit Network Selection Carrier Code from ingress side.

This field may have a non-empty value only when the ingress

signaling protocol is a version of ISUP.

Nature of Address of

the Calling Party

Number

77

Word32

See Table 18. By default, the content is Nature of address of

CPN. If Application Parameter CDR_CPN_NOA_In_Pres is set

to 0, the content is “<S>Presentation

Number</S><E>NOA</E>”

Ingress internal release

cause

78

CHAR [60]

ControlSwitch internal release cause code. It’s either an

empty string or a string in the format “<E>x</E><E>y</E>”,

where x and y are numbers.

Egress internal release

cause

79

CHAR [60]

ControlSwitch internal release cause code. It’s either an

empty string or a string in the format “<E>x</E><E>y</E>”,

where x and y are numbers.

Egress Called Number

80

CHAR[32]

The Called Number sent out from egress side.

ControlSwitch (v.5.10.2) CDR Guide

 Dialogic Inc. Proprietary Page 17

Nature of Address for

egress Called Number

81

ENUM

Nature of Address of the Egress Called Number. See Table

17: Bearer Capability

for details.

Egress Connected

Number

82

CHAR[24]

The number on which the phone rang, sent backward by the

called party (could be forwarded earlier). This field is specific

to calls using ETSI ISUP or its variants.

Nature of Address for

egress Connected

Number

83

ENUM

Nature of Address of the Egress Connected Number. See

Table 17: Bearer Capability

for details.

Presentation Indicator

for Calling Party

Number

84

ENUM

The value of this field can be 0 or 1.

Value 0 means “Allowed”. Value 1 means “Restricted”

Ingress IRI

85

WORD16

The trunk group number in the IRI message received over

Inter-Gateway or National Inter-connect circuit. This field is

ISUP_Singapore specific.

Egress ORI

86

WORD32

The trunk group number in the ORI message received over

Inter-Gateway or National Inter-connect circuit. This field is

ISUP_Singapore specific.

Ingress External Call Id

87

CHAR [256]

The ingress external call id if the ingress signaling protocol is

SIP or H323.

Egress External Call Id

88

CHAR [256]

The egress external call id if the ingress signaling protocol is

SIP or H323.

Ingress Charge Info

89

CHAR[600]

XML string.

Egress Charge Info

90

CHAR[600]

XML string.

Incoming Partial Call

Indicator

91

CHAR [24]

Partial Call Indicator from ingress side. This field is

hexadecimal printout of a byte array.

Incoming National

Forward Call Indicator

92

CHAR [16]

This field is a composite field. It is either Null (empty string)

or a string with the format

<E>sub field 1</E><E>sub field 2</E>

The following 2 rows explain the 2 sub fields. This field may

have a non-empty value only when the ingress signaling

protocol is ISUP_UK.

National Forward Call

Indicator, CLI blocking

indicator

92.1

ENUM

CLI blocking Indicator of National Forward Call Indicator from

ingress side. (see Table 21: Original Redirecting Reason

)

National Forward Call

Indicator, Network

translated address

indicator

92.2

ENUM

Network translated address indicator of National Forward

Call Indicator from ingress side. (see Table 23)

Incoming Last Diverting

Line Identity

93

CHAR [24]

This field is a composite field. It is either Null (empty string)

or a string with the format

<S>sub field 1</S><E>sub field 2</E>

The following 2 rows explain the 2 sub fields. This field may

have a non-empty value only when the ingress signaling

protocol is ISUP_UK.

Last Diverting Line

93.1

CHAR [20]

Digit string of Last Diverting Line Identity from ingress side.

ControlSwitch (v.5.10.2) CDR Guide

 Dialogic Inc. Proprietary Page 18

Identity, digits

Last Diverting Line

Identity, Nature of

address

93.2

ENUM

Nature of address of Last Diverting Line Identity from ingress

side. See Table 17: Bearer Capability

for detail.

J7 specific information

94

CHAR [2200]

This field is a composite field. It is either Null (empty string)

or a string in the format

sub field 1…sub field 5

The following 5 rows explain the 8 sub fields. Note that for

the sub fields, the field ids are 90.1, …, 90.5. This field may

have a non-empty value only when either the ingress or

egress signaling protocol is 12 (ISUP_J7_NTT) or 13

(ISUP_J7_TTC).

Ingress Additional

Party Category

94.1

CHAR[150]

XML string. Detail is the J7 version of this document.

Ingress Charge Area

Info

94.2

CHAR[60]

XML string. Detail is the J7 version of this document.

Egress Additional Party

Dialogic ControlSwitch CDR User guide

Dialogic ControlSwitch CDR User guide

Related papers

Other documents