582 30 CDR v21

ControlSwitch
Sys. Ver. 5.8.2 Pub. Ver. 1.17.
CDR Document
Contact Information
Veraz Networks Inc. 926 Rock Avenue, Suite 20 San Jose, CA 95131 (408) 750-9400 Revision History Date 09/10/2000 9/10/2008 12/15/2008 Version 1.0 1.16.10 1.17.12 Author(s) SZ SZ SZ Notes Initial version This document corresponds to 5.7.10.40-01. This document corresponds to 5.8.0.0-14. Added field 162 Egress final codec list, and field 163 SEE_ID. This document corresponds to 5.8.1.0-12. Merged in 5.7.10 document 1.16.14. iCDR version label is changed to 5_8_1A. Updated field descriptions for field 31 Egress CPN, 148 Ingress Final Codec List, 160, 161, 162 and 163. Added section 4.4 Compressed Event Files, which discusses how to set parameter Event_File_Compression on both EC and CDRE. This document corresponds to 5.8.2.0-15. iCDR version label is changed to 5_8_2A. Replaced field 3s content by Parent GCid. Updated Table 10 Type of Call, Table 12 Signaling Protocol, and Table 27 Codec. Updated Appendix 2 CDR_LOG Oracle Table. Added section 3.23 on iCDRs for INAP prepaid calls. Split the content of section 3.7 into 3.7.1 and 3.7.2. Added sections 3.7.3, INAP Prepaid: Furnish Charging Info. Incorporated many changes from BMs feedback Corrected error in section 3.23.3, 3.16, and 4.1. This document corresponds to 5.8.2.10-05. Improved explanation on Fields 56 and 57, ingress and egress gateway name. Added Chapter 5 EC and CDRE Application Parameters, and Chapter 6 CDRE Application Parameters Questionaries. Added section 3.12.1 which describes Service Id 36, MAP optimal routing service. Added <Time> in service fields.
07/14/2009
1.17.14
SZ
12/07/2009
1.17.15
SZ
12/15/2010 02/23/2010
1.17.16 1.17.17
SZ SZ
Veraz Networks CDR for ControlSwitch Interconnect 5.8.2
02/23/2010 02/23/2010 07/16/2010 08/25/2010
1.17.18 1.17.19 1.17.20 1.17.21
SZ SZ SZ SZ
This document corresponds to 5.8.2.10-05. Updated Table 24 Calling Party Category. This document corresponds to 5.8.2.20-05. Updated Table 6 Service Id, and added section 3.12.2 for Prompt and Collect service. Updated explanation on parameter Show_SEE_ID_IN_ICDR. This version corresponds to 5.8.2.30-03 Added parameter TG_UTL_DATA_DAYS_KEPT, EC_Data_File_Gap_Min, EC_Data_Gap_Sec_Min. Advice of Charge for ETSI PRI
Proprietary Document of Veraz Networks, Inc. -3-
Veraz Networks CDR for ControlSwitch Interconnect 5.8
Table of Contents
1 2 Introduction ................................................................................................................................. 7 1.1 2.1 Target Audience.................................................................................................................. 7 Record Format .................................................................................................................... 7 2.1.1 2.1.2 2.1.3 2.1.4 2.1.5 2.2 2.2.1 2.2.2 2.2.3 2.2.4 2.2.5 3 3.1 3.2 3.3 3.4 3.5 3.6 3.7 BAF Record Call Types ........................................................................................ 7 Call Type 720........................................................................................................ 7 Call Type 714........................................................................................................ 8 Call Type 008........................................................................................................ 8 Call Type 033........................................................................................................ 8 File Creation.......................................................................................................... 9 File Naming........................................................................................................... 9 Long Duration Call ................................................................................................ 9 File Storage........................................................................................................... 9 File Transmission.................................................................................................. 9 BAF Record.................................................................................................................................. 7
BAF Record Files ................................................................................................................ 9
ControlSwitch CDR Specification............................................................................................ 10 File Format ........................................................................................................................ 10 File Naming Convention.................................................................................................... 10 File Transfer and Storage ................................................................................................. 10 3.3.1 iCDR Transfer to Mediation/Billing Platforms ..................................................... 11 Record Format .................................................................................................................. 11 iCDR Field Description...................................................................................................... 11 iCDR Fields that are XML Strings ..................................................................................... 22 Format for Charge Information Field................................................................................. 23 3.7.1 3.7.2 3.7.3 3.7.4 3.8 3.9 3.10 3.11 3.12 3.12.1 3.12.2 3.13 3.14 3.15 3.16 3.16.1 ISUP India........................................................................................................... 23 ISUP Russia........................................................................................................ 23 INAP Prepaid: Furnish Charge Information ........................................................ 23 ETSI ISDN Advice of Charge End of Call (AOC-E) ......................................... 24
Format for Generic Parameter Field ................................................................................. 24 iCDR Support For Long Duration Calls............................................................................. 25 Recording Sub-Second Digits for Timestamp Fields in iCDR ................................ 27 Event Order Field.................................................................................................... 27 Service Fields ......................................................................................................... 28 MAP Optimal Routing ......................................................................................... 29 Prompt and Collect ............................................................................................. 30 Early Events Field................................................................................................... 30 Calling Card and Collect Call Services................................................................... 31 Release Direction ................................................................................................... 32 Header and Footer.................................................................................................. 33 Data Auditing on iCDR Files by Billing Systems ................................................ 33
3.17 3.18 3.19 3.20 3.21 3.22 3.23 3.23.1 3.23.2 3.23.3 4 4.1 4.2 4.3 4.4
SS7 Overlap Signaling............................................................................................ 34 Codec Negotiation .................................................................................................. 34 Forward Call Indicator............................................................................................. 35 Backward Call Indicator .......................................................................................... 37 Call Status (Field 7) ................................................................................................ 38 Border Gateway Information................................................................................... 39 iCDR for INAP Prepaid Calls .................................................................................. 40 Filtering through Field 3, Parent Global Call Id .................................................. 41 Data Characteristics of Virtual Half Calls............................................................ 41 Timestamp Fields in Virtual Half Call.................................................................. 41
Configuring EC and CDRE ....................................................................................................... 42 Introduction ....................................................................................................................... 42 Event Files and Directories on EC .................................................................................... 42 FTP or SCP?..................................................................................................................... 42 Compressed Event Files ................................................................................................... 42 4.4.1 4.4.2 Advantages and Disadvantages of Compressed Event Files ............................ 42 Configuring parameter Event_File_Compression on EC and CDRE ................. 43
EC and CDRE Application Paramters ..................................................................................... 43 5.1 5.2 5.3 5.4 EC Application Parameters............................................................................................... 43 Group 1 CDRE Application Parameters............................................................................ 45 Group 2 CDRE Application Parameters............................................................................ 50 Group 3 CDRE Application Parameters............................................................................ 53 Do you want to have Call Status E iCDR? ...................................................................... 53 6.1.1 6.2 6.3 6.4 6.5 6.6 6.7 6.8 6.9 6.10 6.11 Suggested process on handling Call Status E iCDR for customers ................. 54 Will Account Code service be deployed? ....................................................................... 54 Should a Call_Status E iCDR be final? ........................................................................... 55 Should a Call_Status U iCDR be final? ........................................................................... 55 Should a Call_Status R iCDR be final? ........................................................................... 55 Should a Call_Status K iCDR be final? ........................................................................... 56 Should a Call_Status F iCDR be final? ........................................................................... 56 Is customer interested in SS7 Generic Parameters?........................................................ 56 Disk Usage Alarms............................................................................................................ 57 Should CDRE automatically clean up the disk partition containing iCDR files?..... 57 Set Other Notable Parameters ............................................................................... 58
CDRE Application Parameters Questionnaire........................................................................ 53 6.1
Appendix 1: Value Name Mapping for iCDR Fields.......................................................................... 58 Appendix 2: CDR_LOG Table in Database........................................................................................ 85
List of Tables
TABLE 1 ICDR DATA TYPE DESCRIPTION ......................................................................................... 11 TABLE 2 ICDR FIELDS ..................................................................................................................... 12 TABLE 3 CDR COMPONENT ENCODING ............................................................................................ 22 TABLE 4 ICDR TIMESTAMP DESCRIPTION ......................................................................................... 22 TABLE 5 TAGS IN EVENT ORDER FIELD AND THE EVENTS THEY REPRESENT ...................................... 27 TABLE 6 SERVICE ID......................................................................................................................... 28 TABLE 7 ATTRIBUTE NAMES AND THEIR CORRESPONDING ICDR FIELDS ............................................. 30 TABLE 8 INGRESS AND EGRESS RELEASE DIRECTION ....................................................................... 32 TABLE 9 RELEASE DIRECTION OF A CALL.......................................................................................... 32 TABLE 10 TYPE OF CALL DEFINITIONS............................................................................................... 58 TABLE 11 NATURE OF ADDRESS OF CALLED PARTY NUMBER ............................................................. 59 TABLE 12 PROTOCOL TYPE .............................................................................................................. 62 TABLE 13 TRUNK GROUP TYPE ........................................................................................................ 67 TABLE 14 OLI ................................................................................................................................. 68 TABLE 15 CARRIER SELECTION IDENTIFIER ....................................................................................... 70 TABLE 16 RELEASE CAUSE.............................................................................................................. 70 TABLE 17 BEARER CAPABILITY ......................................................................................................... 72 TABLE 18 GENERIC NUMBER NATURE OF ADDRESS .......................................................................... 72 TABLE 19 REDIRECTING INDICATOR .................................................................................................. 75 TABLE 20 REDIRECTING REASON...................................................................................................... 75 TABLE 21 ORIGINAL REDIRECTING REASON ...................................................................................... 76 TABLE 22 CLI BLOCKING INDICATOR ................................................................................................. 76 TABLE 23 NETWORK TRANSLATED ADDRESS..................................................................................... 76 TABLE 24 CALLING PARTY CATEGORY .............................................................................................. 76 TABLE 25 CALLED PARTY CATEGORY ............................................................................................... 82 TABLE 26 RELEASE CAUSE LOCATION .............................................................................................. 82 TABLE 27 CODEC ............................................................................................................................. 82 TABLE 28 HLC CHARACTERISTIC IDENTIFICATION.............................................................................. 83 TABLE 29 LLC INFORMATION TRANSFER CAPABILITY ......................................................................... 84 TABLE 30 CALLING PARTY CATEGORY FOR CAS R2......................................................................... 84 TABLE 31 LLC USER INFORMATION LAYER 1 PROTOCOL .................................................................. 84 TABLE 32 COLUMNS IN CDR_LOG TABLE AND THEIR CORRESPONDING ICDR FIELDS ......................... 85
1 Introduction
This document provides a functional description of the ControlSwitch Event Collection and CDR Manager subsystem. Chapter 2 BAF Record describes the ControlSwitch support for the Bellcore AMA format (BAF 1 ). Chapter 3 describes Veraz Networks proprietary CDR format and all the issues related to the CDR files.
1.1
Target Audience
This document contains information that is confidential to Veraz Networks. The targeted audience is: Customers Veraz Networks partners who are involved in billing related applications.
2 BAF Record
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.
2.1.1 BAF Record Call Types

Call Type When it is Created
714 720 008 033
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 When call is received over connecting network access incoming trunk When the DN is toll-free When call is Directory Assistance
2.1.2 Call Type 720

The BAF record for call type 720 contains one structure with code 0625. The BAF record for call type 720 may contain the following modules depending on the various services involved in a call.
Code Module Name When Created
022 028 070 164 720
Long Duration Connection Additional Digits Dialed ISDN Core E.164/X.121 Number Module LNP Module
This module is attached in all continuation CDRs for long duration calls When the dialed number is international and the total number of digits are more than 10 then the extra digits are stored here This module is attached if a call is released with a cause code. This module is attached when the Calling Party Number (CPN) is present. The module contains information on CPN Produced when an LNP query is performed by the Veraz ControlSwitch to determine the recipient switch. This module is also
BAF (Bellcore AMA Format) is a standard developed by Telecordia/Bellcore. Proprietary Document of Veraz Networks, Inc. -7-
000
Final Module
produced when LNP query is performed before the call reached the Veraz ControlSwitch as indicated in JIP. Always attached if one of the above module is present
2.1.3 Call Type 714

022 028 070 164 720
Long Duration Connection Additional Digits Dialed ISDN Core E.164/X.121 Number Module LNP Module
000
Final Module
This module is attached in all continuation CDRs for long duration calls When the dialed number is international and the total number of digits are more than 10 then the extra digits are stored here This module is attached if a call is released with a cause code. This module is attached when the Calling Party Number (CPN) is present. The module contains information on CPN Produced when an LNP query is performed by the Veraz ControlSwitch to determine the recipient switch. This module is also produced when LNP query is performed before the call reached the Veraz ControlSwitch as indicated in JIP. Always attached if one of the above module is present
2.1.4 Call Type 008

720
LNP Module
000
Final Module
Produced when an LNP query is performed by the Veraz ControlSwitch to determine the recipient switch. This module is also produced when LNP query is performed before the call reached the Veraz ControlSwitch as indicated in JIP. Always attached if one of the above module is present
2.1.5 Call Type 033

720
LNP Module
000
Final Module
Produced when an LNP query is performed by the Veraz ControlSwitch to determine the recipient switch. This module is also produced when LNP query is performed before the call reached the Veraz ControlSwitch as indicated in JIP. Always attached if one of the above module is present
2.2
BAF Record Files
2.2.1 File Creation

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.
2.2.2 File Naming

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] File Name Field Coding Sizes and Acceptable Values
Field Size (digits) Encoding and explanation
Source Destination File Sequence Number File Type File Sequence Restart Indicator
6 6 6 2 1
01yyyy, where yyyy uniquely identifies the CDR generator starting from 0001 02yyyy, where yyyy uniquely identifies the Receiving system A monotonically increasing number starting from 1 to 999,999 which then restarts at1 05 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
2.2.3 Long Duration Call

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.
2.2.4 File Storage

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.
2.2.5 File Transmission

CDR Manager is capable of transmitting BAF files to a billing system through TFTP. The CDR Manager initiates transfer of file to the remote system 1 minute after it is created. The CDR Manager then places the transferred file into the Secondary directory after it has successfully transferred that file to billing. The CDR Manager sends files in the same sequence as they are generated.
3 ControlSwitch CDR Specification

3.1 File Format
ControlSwitch uses a Ve raz Networks proprietary format to store call data. This form at 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.8.2.10, the version_number portion is 5_8_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 customers 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.
Proprietary Document of Veraz Networks, Inc. - 10 -
3.3.1 iCDR Transfer to Mediation/Billing Platforms

The billing/Mediation platforms need to pull the iCDR files from the Veraz 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 Veraz ControlSwitch and contains all the billing related data collected by the EC(s). iCDR fields are described in detail in section 3.5 iCDR Field Description. iCDR text stri ng contains only the data values of the fields. Fiel ds are se parated by semi -colon (;). The data values are p resented in an as cending order based on their field i ds (Table 2 i CDR Fields) The type of d ata collected varies depending on the signaling protocols used in a given call. For example, incoming carrie r relate d informatio n such as Ca rrier Identificatio n Cod e, Ca rrier Selection Indi cator are onl y available fo r FG D or Carrier Origination Call s. Co nsequently, iCDR for any specific call will have empty values for some fi elds. Within an iCDR, if a given fields 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 descri ption in this do cument for each complex field. For many iCDR field s, how to popul ate them can be controll ed throu gh CDRE Application Parameters. A complete d escription of these Ap plication Parameters is contain ed in Ch apter 5 EC and CDRE Application Parameters in this document.
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) 149 150 CHAR[180] CHAR[180] See section 3.19 for details See section 3.20 for details.
Ingress Forward Call Indicator Egress Backward Call Indicator
Table 1: iCDR Data Type Description

Field Data Type Maximum number of characters of the field Description
WORD32 WORD64 WORD16 ENUM
10 20 5 5
CHAR[L] TIMESTAMP
L 19
Unsigned decimal number Unsigned decimal number Unsigned decimal number Unsigned decimal number There is a table that associates each numeric value to a string, indicating the meaning of the numeric value. Alpha numeric string 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
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 whats in the first column in the above table as the binary field type. Table 2 iCDR Fields
Name Field _id Data Type Description
Zone id Record Sequence Identifier Parent Global Call Identifier
1 2 3
WORD64 WORD64 CHAR[22]
Global Call Identifier Last Received Update Time Stamp Event Order
4 5 6
CHAR[22] TIMESTAMP CHAR[100]
This identifies the ControlSwitch zone that generated this iCDR. This field is always 0. Sequence for this iCDR. This sequence starts from 1, and wraps around to 1 after 9999999. A string of 22 characters that identifies the parent calls 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 calls 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 purpse. See section 3.23 for more detail. A string of 22 characters. Uniquely identifies a call. This is the time when iCDR was last updated. Contains information on what events are collected in this record. See section 3.11 for detail. If you want to replace this field by the old component indicator field (See Table 3), you need to set application parameter
CDR Status Call Type Calling party number Charge Number Called Party Number Nature of Address for Called Party Number Originating Line Information Ingress LRN
7 8 9 10 11 12 13
CHAR[2] ENUM CHAR[24] CHAR[24] CHAR[32] ENUM CHAR[24]
14
CHAR[24]
Ingress Carrier Identifier Code Ingress Carrier Selection Information Ingress Call Control Element ID
15 16
CHAR[24] WORD16
ICDR_FIELD_EVENT_Order to 0 in file cdra.cfg. See section 3.21 for detail. Type of Call Refer to Table 10: Type of Call Definitions. Calling Party Number Charge Number Post Digit Analysis Called Party Number. Nature of address for called party number. See Table 11 for more details 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 14 If the Called Number of an ISUP call was ported before reaching ControlSwitch, this field contains the ported number. Otherwise, the field contains null. Carrier identification code in the incoming call. Carrier Selection Info Received in the incoming signaling
See Table 15 for more details.
17
WORD32
Ingress Trunk Group Protocol Ingress Trunk Group Type Ingress Trunk Group Id Ingress Signal Start Time Stamp Ingress Gateway Id Ingress Card Id Ingress Span Id Ingress Channel Number Ingress D Channel Ingress ISDN Call Reference Number Ingress Create Connection Complete Time Stamp Ingress Address Complete Time Stamp Ingress Call Answer
18 19 20
ENUM ENUM WORD32
Ingress Call Control Element Identifier. This field identifies the Veraz Call Control Element or IP Call Element that was handling the ingress side of this call. Signaling protocol. See Table 12 Trunk group type. See Table 13 The Trunk Group Identifier for the Ingress Trunk. This number is generated by the Veraz EMS when the trunk group was provisioned. See Table 4 for the meaning of this field in the context of various signaling protocols. Gateway number assigned by the Veraz EMS at the time of the Media Gateway provisioning.
21 22 23 24 25 26 27 28
TIMESTAMP WORD32 WORD32 WORD32 WORD32 WORD32 WORD32 TIMESTAMP
D Channel number for ISDN calls Call Reference number for ISDN calls Time Create Connection Acknowledgement is received by CCP from media gateway. See Table 4 for the meaning of this field in the context of various signaling protocols. See Table 4 for the meaning of this field in the
29 30
TIMESTAMP TIMESTAMP
Time Stamp Egress Calling Party Number Terminating Local Routing Number
31 32
CHAR [24] CHAR [24]
context of various signaling protocols. Egress Calling Party Number. Local Routing Number of the Called Number. This number is present only if the dialed number is ported and Veraz ControlSwitch performed a Local Number Portability query to determine the recipient switch of the Dialed number. For Feature Group D Origination Calls, the Carrier Identification Code used in routing the call. See Table 4 for the meaning of this field in the context of various signaling protocols. See Table 4 for the meaning of this field in the context of various signaling protocols. Cause code for Release. See Table 16 Identifies the Egress Call Control Element ID or the Egress IP Call Control Element ID. Signaling protocol. See Table 12 for detail Trunk group type. See Table 13 for detail This number is assigned by the EMS at the time of the provisioning. See Table 4 for the meaning of this field in the context of various signaling protocols. Gateway number Card number Span number Channel number D Channel number for ISDN call Call Reference number for ISDN call Time Create Connection Acknowledgement is received from media gateway See Table 4 for the meaning of this field in the context of various signaling protocols. See Table 4 for the meaning of this field in the context of various signaling protocols. See Table 4 for the meaning of this field in the context of various signaling protocols. See Table 4 for the meaning of this field in the context of various signaling protocols. Cause code for Release. See Table 16 for detail. The time stamp of the last ingress Check Point message. See section 3.9 for detail.
Translated Carrier Identification Code Ingress Call Release Time Stamp Ingress Release Complete Time Stamp Ingress Release Cause Code Egress Call Control Element ID Egress Trunk Protocol Egress Trunk group Type Egress Trunk Group Id Egress Call Start time stamp Egress Gateway_ID Egress Card Id Egress Span Number Egress Channel Number Egress D_Channel Number Egress ISDN Call Reference Egress Create Connection Complete Time Stamp Egress Address complete Time Stamp Egress Call Answer Time Stamp Egress Call Release Time Stamp Egress Release Complete Time Stamp Egress Release Cause Code Last Ingress Check Point Time Stamp
33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48
CHAR [24] TIMESTAMP TIMESTAMP WORD32 WORD32 ENUM ENUM WORD32 TIMESTAMP WORD32 WORD32 WORD32 WORD32 WORD32 WORD16 TIMESTAMP
49 50 51 52 53 54
TIMESTAMP TIMESTAMP TIMESTAMP TIMESTAMP WORD32 TIMESTAMP
Last Egress Check Point Time Stamp Ingress Gateway Name Egress Gateway Name Ingress Trunk Group Name Egress Trunk Group Name Originating Gateway IP address
55 56
TIMESTAMP CHAR [50]
57
CHAR [50]
58 59 60
CHAR [50] CHAR [50] CHAR [23]
Terminating Gateway IP address
61
CHAR [23]
H323 Conference Id
62
CHAR [32]
Ingress Card Port Number Ingress Card Path Number Egress Card Port Number Egress Card Path Number Ingress Trunk Group Number Egress Trunk Group Number Original Dialed Number Original Dialed Number Nature of Address Redirecting Information
63 64 65 66 67 68 69 70
WORD32 WORD32 WORD32 WORD32 WORD32 WORD32 CHAR [32] ENUM
The time stamp of the last egress Check Point message. See section 3.9 for detail 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. 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. The name of the ingress trunk group assigned by user on EMS. The name of the egress trunk group assigned by user on EMS. IP address and port of the originating H323 or SIP gateway outside Veraz 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. IP address and port of the terminating H323 or SIP gateway outside Veraz 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. Conference Id of an H323 Call. It is usually a number expressed in the hexadecimal form with 16 characters. This field is valid only for optical TDM interface on an I Gate 4000 series media gateway. This field is valid only for optical TDM interface on an I Gate 4000 series media gateway. This field is valid only for optical TDM interface on an I Gate 4000 series media gateway. This field is valid only for optical TDM interface on an I Gate 4000 series media gateway. This field contains the Trunk Group number assigned by user through EMS. This field contains the Trunk Group number assigned by user through EMS. Original Dialed Number before Digit Analysis. Nature of Address of the Original Dialed Number. See Table 11. This field is a composite field. It is either Null (empty string) or a string with the format sub field 1sub field 9 The following 9 rows explain the 9 sub fields. Note that for 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. Redirecting Number from ingress side.
71
CHAR [150]
Redirecting Number
71.1
CHAR [24]
Redirecting Number Nature of Address Redirecting Indicator
71.2
ENUM
71.3
ENUM
Nature of Address of the Redirecting Number from ingress side. (see Table 18 ) Redirecting Indicator from ingress side. (see Table 19) Redirecting Reason from ingress side. (see Table 20) Original Called number from the ingress side. Nature of Address of the Original Called Number from the ingress side. (see Table 18 ) Original Redirecting Reason from the ingress side. (see Table 21) Redirection counter from ingress side. The value of this field can be 0 or 1. Value 0 means Allowed. Value 1 means Restricted 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 side. This field may have a meaningful value only when the egress signaling protocol is ANSI ISUP. See Table 17 See Table 17 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. 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> ControlSwitch internal release cause code. Its either an empty string or a string in the format <E>x</E><E>y</E>, where x and y are numbers. ControlSwitch internal release cause code. Its either an empty string or a string in the format <E>x</E><E>y</E>, where x and y are numbers. The Called Number sent out from egress side. Nature of Address of the Egress Called Number. See Table 18 for details. The number on which the phone rang, sent
Redirecting Reason Original Called Number Original Called Number Nature of Address Original Redirecting Reason Redirection Counter Presentation Indicator for Redirecting Number Jurisdiction Parameter from Ingress Jurisdiction Parameter from Egress Ingress trunk bearer capability Egress trunk bearer capability Transit Network Selection Carrier Code Nature of Address of the Calling Party Number
71.4 71.5 71.6
ENUM CHAR [24] ENUM
71.7 71.8 71.9
ENUM WORD32 ENUM
72
CHAR [32]
73
CHAR [32]
74 75 76
ENUM ENUM CHAR [24]
77
Word32
Ingress internal release cause
78
CHAR [60]
Egress internal release cause
79
CHAR [60]
Egress Called Number Nature of Address for egress Called Number Egress Connected
80 81
CHAR[32] ENUM
82
CHAR[24]
Number
Nature of Address for egress Connected Number Presentation Indicator for Calling Party Number Ingress IRI
83
ENUM
84
ENUM
85
WORD16
Egress ORI
86
WORD16
Ingress External Call Id Egress External Call Id Ingress Charge Info Egress Charge Info Incoming Partial Call Indicator Incoming National Forward Call Indicator
87 88 89 90 91 92
CHAR [256] CHAR [256] CHAR[600] CHAR[600] CHAR [24] CHAR [16]
National Forward Call Indicator, CLI blocking indicator National Forward Call Indicator, Network translated address indicator Incoming Last Diverting Line Identity
92.1
ENUM
backward by the called party (could be forwarded earlier). This field is specific to calls using ETSI ISUP or its variants. Nature of Address of the Egress Connected Number. See Table 18 for details. The value of this field can be 0 or 1. Value 0 means Allowed. Value 1 means Restricted The trunk group number in the IRI message received over Inter-Gateway or National Interconnect circuit. This field is ISUP_Singapore specific. The trunk group number in the ORI message received over Inter-Gateway or National Interconnect circuit. This field is ISUP_Singapore specific. The ingress external call id if the ingress signaling protocol is SIP or H323. The egress external call id if the ingress signaling protocol is SIP or H323. XML string. See section 3.7 for detail. XML string. See section 3.7 for detail. Partial Call Indicator from ingress side. This field is hexadecimal printout of a byte array. 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. CLI blocking Indicator of National Forward Call Indicator from ingress side. (see Table 22) Network translated address indicator of National Forward Call Indicator from ingress side. (see Table 23) 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. Digit string of Last Diverting Line Identity from ingress side. Nature of address of Last Diverting Line Identity from ingress side. See Table 18 for detail. This field is a composite field. It is either Null (empty string) or a string in the format
92.2
ENUM
93
CHAR [24]
Last Diverting Line Identity, digits Last Diverting Line Identity, Nature of address J7 specific information
93.1 93.2
CHAR [20] ENUM
94
CHAR [2200]
Ingress Additional Party Category Ingress Charge Area Info Egress Additional Party Category Egress Charge Area Info Carrier Info Transfer Ingress Generic Parameter
94.1 94.2 94.3 94.4 94.5 95
CHAR[150] CHAR[60] CHAR[150] CHAR[60] CHAR[700] CHAR[700]
Egress Generic Parameter
96
CHAR[700]
Ingress Packets Sent Ingress Packets Received Ingress Packets Lost Ingress Packets Transferred Ingress Bytes Sent Ingress Bytes Received Ingress Bytes Lost Ingress Jitter Ingress Latency Egress Packets Sent Egress Packets Received Egress Packets Lost Egress Packets Transferred
97 98 99 100 101 102 103 104 105 106 107 108 109
WORD32 WORD32 WORD32 WORD32 WORD32 WORD32 WORD32 WORD32 WORD32 WORD32 WORD32 WORD32 WORD32
sub field 1sub 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). XML string. Detail is the J7 version of this document. XML string. Detail is the J7 version of this document. XML string. Detail is the J7 version of this document. XML string. Detail is the J7 version of this document. XML string. Detail is the J7 version of this document. This field is populated when there are unusual ISUP parameters that need to be logged in iCDR, or SIP-I parameters are present in SIP signaling, among other scenarios. It can be an XML string or in a customary format. See section 3.8 for detail This field is populated when there are unusual ISUP parameters that need to be logged in iCDR, or SIP-I feature is envoked in a SIP call, among other scenarios. It can be an XML string or in a customary format. See section 3.8 for detail The number of packets sent at the ingress media gateway. The number of packets received at the ingress media gateway. The number of packets lost at the ingress media gateway. The number of packets transferred at the ingress media gateway. The number of bytes sent at the ingress media gateway. The number of bytes received at the ingress media gateway. The number of bytes lost at the ingress media gateway. Measured in millisecond. Measured in millisecond. The number of packets sent at the egress media gateway. The number of packets received at the egress media gateway. The number of packets lost at the egress media gateway. The number of packets transferred at the egress media gateway.
Egress Bytes Sent Egress Bytes Received Egress Bytes Lost Egress Jitter Egress Latency Ingress CIC Egress CIC Retired 117 Retired 118 Ingress local gateway id Egress local gateway id Ingress CAS circuit seizure time Egress CAS circuit seizure time Ingress ZZ code Egress ZZ code Ingress country address type Egress country address type Ingress partition number Egress partition number Ingress calling party category Ingress service Egress service Early events Ingress release cause location Egress release cause location Reverse charge indicator Called party category
110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129
WORD32 WORD32 WORD32 WORD32 WORD32 WORD32 WORD32 WORD32 WORD32 WORD32 WORD32 TIMESTAMP TIMESTAMP CHAR[4] CHAR[4] CHAR[4] CHAR[4] WORD32 WORD32 WORD32
130 131 132 133 134 135 136
CHAR[1000] CHAR[1000] CHAR[8000] WORD32 WORD32 CHAR[1] WORD32
The number of bytes sent at the egress media gateway. The number of bytes received at the egress media gateway. The number of bytes lost at the egress media gateway. Measured in millisecond. Measured in millisecond. Ingress Circuit Identification Code Egress Circuit Identification Code This field is retired. Codec information is in fields 146, 147, and 148. This field is retired. Codec information is in fields 146, 147, and 148. Id of a ControlSwitch logical gateway in H323 or SIP network Id of a ControlSwitch logical gateway in H323 or SIP network Specific for CAS (Channel Associated Signaling) calls Specific for CAS (Channel Associated Signaling) calls Specific for CAS (Channel Associated Signaling) calls Specific for CAS (Channel Associated Signaling) calls Specific for CAS (Channel Associated Signaling) calls Specific for CAS (Channel Associated Signaling) calls Used only in certain customer networks. A prefix extracted from called number. Used only in certain customer networks. A prefix extracted from called number. If field 18 (Ingress Protocol) is CAS_R2_BRAZIL or CAS_R2_MEXICO, see Table 30. Otherwise, see Table 24. See the explanation on service field in section 3.12 See the explanation on service field in section 3.12 See the explanation on early event field in section 3.13. This is an ISUP parameter. See table 26 for detail. This is an ISUP parameter. See table 26 for detail. When the value is Y, it means the called party should be charged for the call, e.g. collect call. This is an ISUP parameter. See table 25 for detail
Call duration
137
WORD32
Ingress Release Direction Egress Release Direction Ingress Answer Time in local time
138 139 140
WORD32 WORD32 TIMESTAMP
This is the duration in seconds. By default, this value is (ingress release time ingress answer time), or (egress release time egress answer time), or (ingress release time egress answer time), or (egress release time ingress answer time), depending on the availability of the fields in the expressions. If case ingress Clear Forward time and/or Clear Back time is available, CDRE would replace the ingress Release time by the minimum among ingress Clear Forward time, ingress Clear Back time and ingress Release time in the above formula. Likewise, if egress Clear Forward time and/or Clear Back time is available, CDRE would replace the egress Release time by the minimum among egress Clear Back time, egress Clear Forward time and egress Release time in the above formula. When application parameter CDR_Subsecond_Digits is set to a positive number in cdra.cfg, this field will have the same subsecond precision as that of field 21 (Ingress Signal Start Time). For example, call duration can be 235.123456, if CDR_Subsecond_Digits is 6. In such a case, the maximum number of all digits of this field will be 10 plus the value of CDR_Subsecond_Digits. See section 3.15 for more detail. See section 3.15 for more detail. Field 30 displays ingress Answer Time in GMT time. This field displays ingress Answer Time in CDR Element local time. This field is null by default. Set Application Parameter CDR_ANM_Local_Time to 1, if one wants this field be populated. See Chapter 5 EC and CDRE Application Parameters for detail. Field 50 displays egress Answer Time in GMT time. This field displays egress Answer Time in CDR Element local time. This field is null by default. Set Application Parameter CDR_ANM_Local_Time to 1, if one wants this field be populated. See Chapter 5 EC and CDRE Application Parameters for detail. Ingress Characteristics Identification of High Layer Compatibility. See Table 28. Egress Characteristics Identification of High Layer Compatibility. See Table 28. Ingress Information Transfer Capability of Low Layer Compatibility. See Table 29 Egress Information Transfer Capability of Low
Egress Answer Time in local time
141
TIMESTAMP
Ingress HLC Characteristics Identification Egress HLC Characteristics Identification Ingress LLC Transfer Capability Egress LLC Transfer
142
WORD32
143
WORD32
144 145
WORD32 WORD32
Capability Ingress Codec History Egress Codec History Ingress Final Codec List Ingress Forward Call Indicator Egress Backward Call Indicator Ingress Clear Forward Time Egress Clear Forward Time Ingress Clear Back Time Egress Clear Back Time Egress calling party category Border Gateway Info Border Gateway Id
146 147 148 149 150 151 152 153
CHAR[2500] CHAR[2500] CHAR[60] CHAR[180] CHAR[180] TIMESTAMP TIMESTAMP TIMESTAMP
Layer Compatibility. See Table 29. See section 3.18 for more detail. See section 3.18 for more detail. See section 3.18 for more detail. See section 3.19 for detail. See section 3.20 for detail. This field is null except when ingress signaling protocol is CAS_2BIT_SL. This field is null except when egress signaling protocol is CAS_2BIT_SL. This field is null except when ingress signaling protocol is CAS_2BIT_SL, CAS_2BIT_SLM, CAS_2BIT_ZSL and CAS_R2_BRAZIL. This field is null except when egress signaling protocol is CAS_2BIT_SL, CAS_2BIT_SLM, CAS_2BIT_ZSL and CAS_R2_BRAZIL. If field 38 (Egress Protocol) is CAS_R2_BRAZIL or CAS_R2_MEXICO, see Table 30. Otherwise, see Table 24. See section 3.22 for detail. If multiple Border Gateways were used in a call, this field is the Id inside the last Border Gateway Address event or Border Gateway Packet Statistics event received on EC. Ingress User Information Layer 1 Protocol of Low Layer Compatibility. See Table 31 Egress User Information Layer 1 Protocol of Low Layer Compatibility. See Table 31 Field 34 displays ingress Release Time in GMT. This field displays ingress Release Time in CDR Element local time. This field and the next field will have empty content by default. In order to see RELEASE time in local time, please set parameter CDR_REL_Local_Time to 1 in cdra.cfg. Field 51 displays egress Release Time in GMT. This field displays egress Release Time in CDR Element local time, if CDR_REL_Local_Time is set to 1 in cdra.cfg. See section 3.18 for more detail. By default, Application Parameter Show_SEE_ID_IN_ICDR is set to 0 in cdra.cfg, which means field 162 is the last iCDR field. Field 163 is created only when Show_SEE_ID_IN_ICDR is set to 1 or 2. If Show_SEE_ID_IN_ICDR is set to 2, this field will contain the Id of the Service Execution Element.
154
TIMESTAMP
155
WORD32
156 157
CHAR[2000] WORD32
Ingress LLC Transfer UILP Egress LLC Transfer UILP Ingress RELEASE Time in local time
158 159 160
WORD32 WORD32 TIMESTAMP
Egress RELEASE Time in local time
161
TIMESTAMP
Egress final codec list SEE ID
162 163
CHAR[60] WORD32
Table 3: CDR Component Encoding

Bit Description
0 1 2 3 5 6 10 16 17 18 19 21 22 26
Signals whether the ingress setup message is received. Signals whether the ingress connect answer message is received. Signals whether the ingress release message is received. Signals whether an ingress charge message is received. If this message is not received, field 89 will be null. Signals whether an ingress checkpoint message is received. If this bit is set to 1 then the call is a long duration call. Signals whether an ingress packet statistics message is received. If this message is not received, fields 97 to 105 will be null. Signals whether an ingress generic message is received. Signals whether the egress setup message is received. Signals whether the egress connect answer message is received. Signals whether the egress release message is received. Signals whether an egress charge message is received. If this message is not received, field 90 will be null. Signals whether an egress checkpoint message is received. If this bit is set to 1 then the call is a long duration call. Signals whether an egress packet statistics message is received. If this message is not received, fields 106 to 114 will be null. Signals whether an egress generic message is received.
Table 4 iCDR Timestamp Description

Time Stamp (ingress and egress) Signal Start Address Complete Call Answer Release Release Complete Related Protocol Messages ISUP IAM ACM ANM REL RLC PRI SETUP Alerting Connect Disconnect/Release RLC H323 Setup Alerting Connect REL RLC CAS SUP NA ANS REL RLC
3.6
iCDR Fields that are XML Strings
Every iCDR field that is described as an XML string means that if one put the field content in the indicated location in the following document, the result would be a true XML document. <?XML version = 1.0> <!DOCTYPE DOCUMENT [ <!ELEMENT DOCUMENT (G|B|N|S|R)*>
<!ELEMENT G (B|N|S|R)*>
<!ELEMENT B (#PCDATA)>
<!ELEMENT N (#PCDATA)> <!ELEMENT S (#PCDATA)> <!ELEMENT R (#PCDATA)> <!ATTLIST G I CDATA #REQUIRED> // generic parameter <!ATTLIST B I CDATA #REQUIRED> // Boolean type <!ATTLIST N I CDATA #REQUIRED> // number type <!ATTLIST S I CDATA #REQUIRED> // string type <!ATTLIST R I CDATA #REQUIRED> // byte array or raw type ]> <DOCUMENT> field content </DOCUMENT>
3.7
Format for Charge Information Field
This field is an XML string containing many sub fields.
3.7.1 ISUP India

If the signaling protocol is ISUP India, the format is as below. All sub fields are underlined. <G N=TariffIndicator> Present <N> PeriodicChargeRateInSeconds </N> <N> PeriodicChargeRateInMilliSeconds </N> <N> AdditionalInfo </N> <N> ChargeUnitsOnAnswer </N> <N> ConcessionTariffIndicator </N> <N> UnitsPerChargeDuration </N> </G>
3.7.2 ISUP Russia

If the signaling protocol is ISUP Russia, the format is:
<G> N=BillingZone>
<N> Total </N> <R> Billing Zone </R> </G>
3.7.3 INAP Prepaid: Furnish Charge Information

If the signaling protocol is VIRTUAL, and the call is an INAP prepa id call, this field would contain the content of the last Furnish Charging Information message received from INAP. A sample of this fields content is as follows: <FCI P80="01ab" P81="141373779901ffff" P82="051809201201ffffff" P83="258972" P84="2001ffff"/>; In the above example, the Furnish Charging Information message contains 5 parameters: Parameter Id 80 81 82 83 84 Parameter Name BillingType BillingNumber Access Code/Total Pulses Country Code Service Key
3.7.4 ETSI ISDN Advice of Charge End of Call (AOC-E)

For an ETSI PRI call, if AOC Charge units were computed and shared towards network, the value is stored in Charge Information field. A sample of this fields content is as follows: <TrfMsg><AOC Protocol="PRI-AOC-E" ChargeUnits="170"/></TrfMsg> In the above example, entity TrfMsg stands for Tariff Message.
3.8
Format for Generic Parameter Field
This field can contain the uncommon data that are in various international variants of SS7 ISUP messages. It can also contain other parameters in calls that do not involve ISUP. The data is presented as a sequence of Generic Parameters. A Generic Parameter can be a simple Generic Parameter or a complex Generic Parameter. A simple Generic Parameter has a parameter id, parameter type (Boolean, number, string, raw bytes), and a value. A complex Generic Parameter contains a parameter id, and a sequence of Info Elements. Each Info Element consists of an Info Element Id, Info Element Type (Boolean, number, string, raw bytes), and a value.
Parameter or Info Element Type Example Explanation
1 2 3 4
1 21 Dallas \0F\0A\01\02\80
Boolean type. Value 1 means yes, value 0 means no Number type. String type. Raw bytes type.
By default, each simple generic parameter or info element is displayed in the format: [ Parameter Id | Info Element Id | Type | Value ] If you would like to see Generic Parameters displayed in XML format, set application parameter CDRM_Parameter GenericParam_To_XML=1 In /opt/IPVRcdr/cdra.cfg and restart CDRE. A typical generic parameter is displayed as in the following example: [10032||4|i b\FCsi Freitag habe ich zeit kannst du\01\00\0A0449111140\00][10052||3|Dallas] [17251|20015|2|1] The generic parameter in the above example consists of 2 simple generic parameters and 1 info element:
Parameter Id Info Element Id Type Value
10032 10052
4 (raw bytes) 3 (string)
i b\FCsi Freitag habe ich zeit kannst du\01\00\0A0449111140\00 Dallas
17251
20015
2 (number)
When displaying a simple generic parameter of type 4 or an info element of type 4, CDRE displays each byte according to this rule: If the byte has a value between 32 and 126, the byte is displayed as an ASCII character. Otherwise, the byte is displayed as back slash \ followed by 2 hexadecimal digits. This is the default behavior. By setting application parameter CDRM_Parameter CDR_GenericMsgData_Flex_Print=0 In /opt/IPVRcdr/cdra.cfg and restart CDRE, CDRE will display all bytes in a type 4 generic parameter as back slash \ followed by 2 hexadecimal digits. The XML format of generic parameter employs 5 XML tags:
Tag Example Explanation
R N S B G
<R I=1032> i b\FCsi Freitag </R> <N I=103>243</N> <S I=105>Dallas</S> 1 <G I=109><N I=203>53</N></G>
A simple generic parameter of type Raw Bytes A simple generic parameter of type Number A simple generic parameter of type String A simple generic parameter of type Boolean A generic parameter with one info element of type Number
For instance, a generic parameter GP1 (parameter id=121, decoded=0, byte array value=12AB34CD) is stored as <R I=121>12AB34CD</R> An example of a complex generic parameter is generic parameter GP2 (parameter id=122, decoded=1, info element 1 (i.e. id=21, type=number, value=200), info element 2 (i.e. id=22, type=string, value=Dallas)) is stored as <G I=122><N I=21>200</N><S I=22>Dallas</S></G> A generic parameter field contains the DOCUMENT portion of an XML document in the form of the above DTD, without the beginning <DOCUMENT> and ending </DOCUMENT>. For example, if the field contains GP1 and GP2, the field content will be: <R I=121>12AB34CD</R><G I=122><N I=21>200</N><S I=22>Dallas</S></G> For data type Raw Bytes, the info element value is a hexadecimal print out of a byte array. Each byte in the byte array occupies two hexadecimal digits.
3.9
iCDR Support For Long Duration Calls
For Calls that ended less than 10 minutes after setting up, only one iCDR will be generated. The iCDR records will be generated approximately 20 seconds after the call is finished. Veraz CDR Element will generate intermediate iCDRs on regular intervals for all calls lasting longer than 10 minutes.
For calls that last longer than 10 minutes and but less than 1 hour, around 10 minutes after the call started, an intermediate iCDR will be generated with value I (meaning In Progress) in the Call_Status field. At approximately 20 seconds after the call is ended, a final iCDR will be generated. For calls that last longer than one hour, an intermediate iCDR with value I in the Call_Status field will be generated every one hour till the call ends. The period in which I iCDR are generated is configurable. This will be discussed at the end of this section. For example: Let us consider a long duration call that lasts for 2 hours. In this case, CDRE will generate four iCDRs for the call: The second iCDR will be created after 1 hour and 10 min.
Call Start Here
The first iCDR will be created after 10 min.
The third iCDR will be created after 2 hours and 10 min.
The fourth and final iCDR will be created after the completion of the call (2.5 hours later)
The Table given below shows the values in four specific iCDR fields in four iCDRs for the call. To give a clear demonstration, we assume the call started at 1/1/2001, 1AM.
iCDR Call Status Last Ingress Check Point Last Egress Check Point Release Time Remarks
First
I (In Progress) I (In Progress) I (In Progress) S (Success)
NULL
NULL
NULL
Second
2001-01-01, 2AM 2001-01-01, 3AM 2001-01-01, 3AM
2001-01-01, 2AM 2001-01-01, 3AM 2001-01-01, 3AM
NULL
Third
NULL
Fourth
2001-01-01, 3:30 AM
This is the first iCDR generated at 10 min after the call started. This is the second iCDR generated at 1 hour and 10 minutes after the call started. This is the third iCDR generated at 2 hours and 10 minutes after the call started. This is the final iCDR generated around 20 seconds after the call is released.
By default, CDRE writes a new iCDR every hour as long as the long duration call is still on going. This one-hour period is called Checkpoint Timer Period. A customer can adjust the length of the checkpoint timer period by setting the parameter Long_Duration_Call_Timer to his desired value on EMS GUI. To do that, one needs to click on the Application Parameters item on the
Administration menu in EMS GUI. If you set Long_Duration_Call_Timer to value k, it means that the ControlSwitch will wait for k hours before generating the next checkpoint message for a live call. Hence, the regular time gap between consecutive iCDRs for a long duration call will be k hours.
3.10 Recording Sub-Second Digits for Timestamp Fields in iCDR

A customer can turn on an optional feature that records sub-second in all timestamp fields except the field update time (field 5) in iCDR. To turn this feature on, one needs to add the following line at the end of the configuration file /opt/IPVRcdr/cdra.cfg on the CDRE host: CDRM_Parameter CDR_Subsecond_Digits=1
The new value will take effect only after CDRE is restarted from EMS. The range of the parameter CDR_Subsecond_Digits is from 0 to 6, with default value 0. When this parameter is set to a value k that is greater than zero, CDRE will record all timestamp fields (except field 5) with k decimal digits following the second part, e.g. 2002-09-15+08:09:10.1 if k = 1. When this optional feature is turned on, the timestamp fields in Oracle database will not have sub-second data, and users will not see sub-second part in a timestamp field on CDR GUI. CDRE truncates timestamp values of all timestamp fields in accordance to the value of the parameter CDR_Subsecond_Digits. CDRE never rounds up regardless of the value of CDR_Subsecond_Digits.
3.11 Event Order Field

The Event Order field (field id 6) in iCDR indicates the events that are included in the iCDR record. An example of an Event Order field is oS1+S2+C3oC4+R5+P6oR7oP8. In Event Order field, each event is represented by a character or a character string called Tag. The following table shows the tags and the names of the corresponding events. Table 5 Tags in Event Order field and the Events they represent
Tag in Event Order field S C Con R Cpt Chg P G Svc SqA BGm BGs Event Name Call Setup Connect Answer (generated when ANM or REL is received) Connect (generated when CRCX or MDCX response comes in) Release Check point Charge Packet statistics Generic message Service Subsequent Address (generated in SS7 overlap signaling) Border Gateway Map Border Gateway Packet Statistics
Inside an Event Order field, there is always a character before each tag and a number after each tag. The character before a tag is either o for origination or + for termination. The number after a tag indicates the order in which the event is received by CDRE. For example, an Event Order field with value oS1+S2+C3oC4+R5+P6oR7oP8 means that the iCDR contains data collected from eight different events on the call, and the events are originating call setup, terminating call setup, terminating connect answer, originating connect answer, terminating release, terminating packet statistics, originating release, and originating packet statistics, in that order.
3.12 Service Fields

Service field records the services that are involved in a call. Examples of services include account code and/or PIN based authentications. There is an ingress service field and an egress service field. Data in both fields are in XML format. We will use an example to show the format for the service fields.
<SVC ID=3 SUCC=1 ACNT=123456 PIN=123ert><Time>2010-0102+10:11:12.456</Time></SVC>
We have the SVC entity that means a service. SVC entities have at least two attributes: ID and SUCC. ID shows the numeric id of the service. SUCC can have value 1 or 0, indicating whether the service was completed successfully or not. Attribute ACNT shows account code. Attribute PIN shows personal identification number. Both attributes are sequence of digits a user entered for authentication or authorization before making a call.
In the SVC entity, the ID attribute can take values from the following table.
Table 6 Service Id
Service Id 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 Meaning NO SERVICE CALL BLOCKING CALL FORWARDING ANONYMOUS CALL BLOCKING CALLER ID ORIGINATION CALL SCREENING CALL WAITING NO CALLER ID CALL WAITING CALLER ID CALL BLOCKING SELECTIVE ACCEPTANCE SPECIAL CALL FORWARDING CALL RETURN CANCEL CALL RETURN CALLERID SELECTIVE BLOCKING CALLERID COMPLETE BLOCKING CALL FORWARDING BUSY CALL FORWARDING NO ANSWER CALL TRANSFER BUSY REDIAL CALL HOLD CANCEL ABSOLUTE CALL FORWARD CANCEL CALL FORWARD BUSY CANCEL CALL FORWARD NO ANSWER CANCEL ANONYMOUS CALL BLOCKING SPEED CALL 8 PROGRAMMING SPEED CALL 8 ACTIVATING SPEED CALL 30 PROGRAMMING SPEED CALL 30 ACTIVATING CANCEL BUSY REDIAL THREE PARTY CALL RTALK PENNY PHONE TEST CALL Proprietary Document of Veraz Networks, Inc. - 28 -
32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50
INAP R CALL BY CALL R TALK NO OPERATOR SPARE 35 MAP Optimal Routing Prompt and Collect SPARE 38 SPARE 39 SPARE 40 SPARE 41 SPARE 42 SPARE 43 SPARE 44 SPARE 45 SPARE 46 SPARE 47 R TALK GERMANY R CALL BY CALL GERMANY PENNY PHONE GERMANY
3.12.1 MAP Optimal Routing

When MAP Optimal Routing service is deployed, an XML entity that looks like the following: <SVC ID="36" SUCC="1" SvcNode="491" SvcCat="BASIC_OR" TCAPSE="651" CdP_IMSI="112 66 50"><Time>2010-01-05+10:11:12.456</Time></SVC>
Will be present in the service field. Here are the explanations of the attributes in the entity: Attribute short name SvcNode SvcCat Attribute full name Service Node Id Service Category Explanation The possible values are: BASIC Basic GMSC service TCAPSE CdP_IMSI TCAPSE Id Called party IMSI BASIC_OR GMSC service supporting Optimal Routing ECF Early call forwarding LCFI Late call forwarding interrogation LCF Late call forwarding (without forwarding interrogation)
When ControlSwitch receives an RCH request and the forwarding interrogation is not required. The service category will be LCF.
3.12.2 Prompt and Collect

When Prompt and Collect service is deployed, an XML entity that looks like the following: <SVC ID="37" SUCC="1" Digits="1126650"><Time>2010-0105+10:11:12.456</Time></SVC>
Will be present in the service field. The value in attribute Digits would contain the digits that were collected from the calling party.
3.13 Early Events Field

With the addition of early events iCDR field, ControlSwitch has a means to record a complete picture of a call that went through multiple routing attempts. For example, depending on how routing policies are set, ControlSwitch may determine that there are 3 routes to complete a call. In that case, if the first route turned out unsuccessful, ControlSwitch will attempt to complete the call on the second route. If the second route has some problem, ControlSwitch will attempt to complete the call on the third route. If the third route has some problem, ControlSwitch will release the call with an unsuccessful cause code. In this example, each routing attempt has its own call setup event, connect answer event, and call release event. All iCDR fields except early events field, is called collectively the main part of iCDR. Most of the fields in iCDR are either about the origination (or ingress) half of the call or the termination (or egress) half of the call. So the main part of iCDR contains 2 half call records. A half call record contains the data consolidated from one ingress call leg or one egress call leg. More specifically, a half call record contains a combination of call setup, connect answer, and release events from one call leg. The early events field is organized to contain a sequence of half call records as shown in the following example: <N N="Num_HC">2</N><G N="HC" Dir="E" EvtOdr="+S2+C4+R5" Cce="5" Sig="0" TG="6" DN="16501230936" Phy_Chan="10-18-2-0-1-3" CIC="4002" IAM="200403-16+18:46:51" ACM="2004-03-16+18:46:51" REL="2004-03-16+18:46:51" Cause="47" Int_Cause="<E>4</E><E>0</E>" TG_Type="1" TG_Name="4kPRO-TGISUP(4000-8000)" Bearer="0"></G><G N="HC" Dir="E" EvtOdr="+S7+C10+R9" Cce="5" Sig="0" TG="30" DN="16501230936" Phy_Chan="2-18-1-0-11-6" CIC="246" IAM="2004-03-16+18:46:51" ACM="2004-03-16+18:46:51" REL="200403-16+18:46:52" Cause="34" Int_Cause="<E>4</E><E>0</E>" TG_Type="1" TG_Name="4KPRO-TG3(241-284)" GW_Name="100" Bearer="0"></G> In the above sample early events field, the entity <N N="Num_HC">2</N> says that the number of half call records is 2, indicating the early_events field contains 2 half-call records. Each half call record starts with <G N="HC" and ends with </G>. In between, the data about the half call are shown as attributes and values. For example, Dir="E" means direction is egress, and TG="6" means trunk group id is 6. If you dont see an expected attribute, it means the value of that attribute is Null. For example, if you dont see attribute ANM, e.g. something like ANM=2002-02-03+12:13:14, it means the attribute ANM, Answer Time Field in this case, is null. The event order attribute EvtOdr="+S2+C4+R5" indicates the events that are included in the half call record, in the same way as the event order field in iCDR. So, EvtOdr="+S2+C4+R5" means
that the half call record contains data collected from the 2nd, 4th, and 5th events of the call, and the events are terminating call setup, terminating connect answer, and terminating release, respectively. The
following is a table of attributes names and the corresponding iCDR field names. Table 7 Attribute Names and their Corresponding iCDR fields
Attribute Name Dir EvtOdr Cce Sig DN TG Phy_Chan D_Chan Call_Ref CIC Call_Type IAM ACM ANM REL Cause Int_Cause TG_Type TG_Name GW_IP GW_Name Codec Bearer IRI ORI Local_GW Redir_Num Ext_Call_Id H323_Conf ZZ Code Cntry_Adr_Type CAS_CC CLid
Corresponding iCDR field name Direction. Value I means origination, E means termination Event order CCE id Signaling protocol Called number Trunk group id Physical channel, the numbers are gateway, card, card port, card path, span, channel id, respectively D Channel Call reference Circuit identification number Call type IAM time ACM time ANM time REL time Release cause code Internal release cause code Trunk group type Trunk group name IP and port of external H323 or SIP gateway Gateway name Codec Bearer capability Incoming Route Id (Singapore ISUP) Outgoing Route Id (Singapore ISUP) Local gateway id Redirecting number External call id H323 conference id Country Address Type CAS circuit seizure time Call Leg Id
Corresponding ICDR field id 17, 37 18, 38 11 20, 40 22-25, 42-45, 63-66 26, 46 27, 47 115, 116 8 21, 41 29, 49 30, 50 34, 51 36, 53 78, 79 19, 39 58, 59 60, 61 56, 57 148, 162 74, 75 85 86 119, 120 71.1 87, 88 62 123, 124 125, 126 121, 122
If the early_events field in an iCDR contains a half call record with Sig=251, then the half call record is the record of an Announcement service during the course of the call. If a customer does not want to save the events from early routing attempts in iCDR, he can do so by setting application parameter ICDR_Save_Old_Event to 0 in cdra.cfg and restarting CDRE.
3.14 Calling Card and Collect Call Services.

For Calling Card type of services, iCDR field 131 egress service will contain an SVC XML entity with ID=30. Except the last termination call, all previous termination half calls are recorded in the early events field. For Collect Call type of services, iCDR field 131 egress service will contain an SVC XML entity with ID=29. We will illustrate this field using three sample cases: Case 1: A successful collect call In this case, the field will look like:
<SVC ID="29" SUCC="1"><OPTR>0</OPTR><DN>14087509531</DN><SEQ>123</SEQ> <TIME>2005-06-02+13:14:15</TIME></SVC>.
Attribute SUCC can have value 1 or 0. SUCC=1 means that the called party accepted the Collect Call. SUCC=0 means that the called party declined the Collect Call. The entity named OPTR contains a number in its content. If the OPTR content is 1, it means the call had operator assistance. If the OPTR content is 0, it means the call did not have operator assistance. Entity named TIME contains the time the called party accepted the Collect Call request. Case 2: First call attempt was unsuccessful, but the second attempt was successful In this case the field will look like:
<SVC ID="29" SUCC="0"><OPTR>0</OPTR><DN>14087509531</DN><SEQ>123</SEQ> <TIME></TIME></SVC><SVC ID="29" SUCC="1"><OPTR>0</OPTR><DN>14087509541</DN> <SEQ>124</SEQ><TIME>2005-06-22+13:15:15</TIME></SVC>
Case 3: First call attempt was unsuccessful, and the second attempt was also unsuccessful In this case the field will look like:
<SVC ID="29" SUCC="0"><OPTR>0</OPTR><DN>14087509531</DN><SEQ>123</SEQ> <TIME></TIME></SVC><SVC ID="29" SUCC="0"><OPTR>0</OPTR><DN>14087509541</DN> <SEQ>124</SEQ><TIME></TIME></SVC>
In addition, for Collect Calls, iCDR field 135 reverse charge indicator will have value Y. A complete list of service types and ids can be found in Table 6 Service Id.
3.15 Release Direction

Fields Ingress Release Redirection (field 138) and Egress Release Direction (field 139) can take the following values: Table 8 Ingress and Egress Release Direction
Value 0 1 Mapped string Unknown Internal Meaning Direction is unknown. The call was released because something happened in the half call, ingress or egress. For example, Bearer Capability did not match Congestion detected in ControlSwitch elements Continuity Test failure If this value appears in I_rel_direction, it means that either a Release Request came from the egress half call, or the ingress media gateway had a problem which caused the ingress half call to release. Vice-versa if this value appears in E_rel_direction. If this value appears in I_rel_direction, it means a Release Request came from the Calling Party in the ingress half call. If this value appears in E_rel_direction, it means a Release Request came from the Called Party in the egress half call.
Remote Half call
Network Initiated
Depending on the values in the two fields, we can draw some conclusions on how a call was ended.
Table 9 Release Direction of a Call

Ingress Release Direction Network Initiated Remote Half Call Network Initiated Internal Egress Release Direction Remote Half Call Network Initiated Network Initiated Remote Half Call Conclusion Calling party released the call first. Called party released the call first. Both parties released the call at the same time. A problem is encountered at the ingress Call Control
Remote Half Call Remote Half Call
Internal Remote Half Call
Element which caused the call to be released A problem is encountered at the egress Call Control Element which caused the call to be released Either the ingress media gateway or the egress media gateway encountered a problem.
3.16 Header and Footer

iCDR files can have a header and footer. By default, iCDR file does not contain header and footer. If header and footer are desired, one needs to set the application parameter CDRM_Parameter ICDR_File_Header=1 in configuration file /opt/IPVRcdr/cdra.cfg. After setting the parameter to 1, one needs to shutdown and restart CDR Element for the parameter to take effect. An example of the header looks like this: <VerazCDRHeader version=5_8_2A cdr_id=1> <FileName>icdr.5_8_2A.0.1.201001290200.010536.0</FileName> </VerazCDRHeader> Keep in mind that in iCDR file, the above three lines are in one line. An example of the footer looks like this: <VerazCDRFooter cdr_count=40 open_seconds=60> <FileName>icdr.5_8_2A.0.1.201001290200.010536.0</FileName> <CheckSum>1309fee004cdfdc9</CheckSum> </VerazCDRFooter> Keep in mind that in iCDR file, the above four lines are in one line. The cdr_count attribute shows h ow many iCDRs a re contained in the file. Th e CheckSum entity contains the hexadecimal value of an 8-byte checksum of the whole file excluding the header and the footer.
3.16.1 Data Auditing on iCDR Files by Billing Systems

A billing system that processes iCDR can use the cdr_count and the checksum in iCDR file footer to detect net work transport problems occurring when iCDR files were transmitted from CDRE to the billing system. In addition, the second field in every iCDR is the Record Sequence field. The Record Sequence is maintained across iCDR files. A billing syst em can use the Record Sequence to find out whether there is a loss of iCDRs. The File Se quence contained in th e iCDR file name is a sequence separate from the Record Sequence. A billing system can use the File Sequence to detect loss of iCDR files. If an iCDR file is renamed for some reason, the billi ng systems can al ways locate the Fil eName tag i n the header of a n iCDR file to find out the origin al iCDR file nam e, and h ence find out the File Sequence of the iCDR file.
3.17 SS7 Overlap Signaling

If the signaling protocol is ISUP_C7 or its variant, an IAM message can be received and sent out when the Called Party Number is not complete. The complete Called Party Number may come in a SAM (Subsequent Address Message) later. If such a call failed before the last SAM was received, the iCDR field 69 Original Dialed Number would contain an incomplete number. If for testing or other reasons, a user wants to know whether field 69 contains an incomplete number, he needs to set an application parameter as follows: CDRM_Parameter CDR_DN_Incomplete_Char=+ in /opt/IPVRcdr/cdra.cfg. With the above sample setting, an iCDR with + character at the end of field 69 means CDRE didnt receive the SAM message with complete Called Party Number. By default, iCDR shows no indication for incomplete number in field 69. The setting of parameter CDR_DN_Incomplete_Char would affect field 11 (Post DA Called Party Number) and field 80 (Egress Called Party Number) in the same way.
3.18 Codec Negotiation

CDRE will maintain CODEC negotiation history on both Ingress and egress sides for each call. The codec history will be recorded in XML format in iCDR. CDRE also records a history of final codecs, which will be discussed in detail at the end of this section. For a simple call, the Ingress Codec History field may contain an XML string like the following:
<MPH> <Leg Dir="I" LgId="9322574373959237733"> <Msg Type="Loc" Action="Pro" Time="2008-08-15+15:19:09"> <Param CList="5, 7, 22, 20" Ptime="10, 10"></Param></Msg> <Msg Type="Loc" Action="Acp" Time="2008-08-15+15:19:09"> <Param CList="5" Ptime="20, 20"></Param></Msg></Leg> <Leg Dir="I" LgId="9322574373959237733"> <Msg Type="Fin" Action="Pro" Time="2008-08-15+15:19:09"> <Param="5" Ptime="20, 20"></Param></Msg></Leg> </MPH>
For a simple call, the Egress Codec History field may contain an XML string like the following:
<MPH> <Leg Dir="E" LgId="7007607617258258475"> <Msg Type="Loc" Action="Pro" Time="2008-08-15+16:24:35"> <Param CList="5" Ptime="10, 10"></Param></Msg> <Msg Type="Loc" Action="Acp" Time="2008-08-15+16:24:35"> <Param CList="5" Ptime="20, 20"></Param></Msg></Leg> </MPH>
In the XML string, the root entity MPH stands for Media Parameter History, which contains one or more Leg entities. A Leg entity has two attributes: Dir, meaning direction; and LgId, meaning call Leg Id. Dir can be I, meaning ingress, or E, meaning egress. Inside Leg entity, there can be one or more Msg entities. A Msg entity has three attributes: Type, Action, Time. Type is a string indicating the source of the media parameters, as indicated by the following table: Message Type
Type Value Description
Net Loc Fin
Media parameters received from the network Initial media parameters locally configured Final media parameters after negotiation with remote media
Action is a st ring in dicating the rel ationship of the list to a gate way, as defin ed in the follo wing table: Message Action
Action Value Description
Pro Acp Rec
Proposed media parameters sent to a media gateway Accepted media parameters received from a media gateway Received media parameters from network
Time is the send or received time depending on the value in the Action attribute. Timestamp is in the YYYY-MM-DD+HH:MI:SS format. A Msg entity can contain one or more Param entities. A Param entity can have several attributes. Attribute CList means Codec List. CList is often a list of codecs sepa rated by comma. Table 26 indicates how different codecs are represented. Attribute PTime means Packet Time. PTime is often a list of two numbers. Below is an example of a Param entity:
<Param CList="1, 2, 3" Ptime="10, 10">
In the above example, the code list is 1, 2, 3, which corresponds to codecs G723, G729 and GSM according to Table 27. By default, the application parameter CDR_Media_Param_Option is set to 1, which means only accepted (Action=Acp) media parameters list is stored on the CDRE Oracle database, as well as in iCDR. If a user sets the application parameter CDR_Media_Param_Option to 0 in cdra.cfg file, CDRE will put nothing in the Ingress Media Parameter History and Egress Media Parameter History fields in iCDR and Oracle database. If the user sets the application parameter CDR_Media_Param_Option to 3, CDRE will put the accepted part of media parameters history in Oracle database, and put the entire media parameters history, including the proposed part, in iCDR. The length of media parameters history for both egress and ingress is 600 characters in database. Anything above 600 will be truncated. Field 148 and 162 are Ingress and Egress Final Codec List. This is a list of final codecs that were chosen after negotiations. Final Codec List contains a string of final codecs as in the following example: "03,00,22,00," The first 2 characters is a number indicating the size of the list, or the number of Final codecs. Subsequent numbers separated with comma are the final codecs adopted after each round of negotiation. The above example showed a final codec list with 3 codec negotiations. At first the two parties used G711 for a voice conversation. Then the two parties used T38 (fax) to fax a document. Then the two parties used G711 for one more voice conversation. At most 18 final codec negotiations can be recorded during the course of a call. CDR will truncate anything after the first 18 codec settings in the Final Codec List field. The content of Final Codec List field cannot be changed by application parameter.
3.19 Forward Call Indicator

The Forward Call Indicator field has the following format:
<Present><Call Indicator><End-to-End Method><Interworking Indicator><Segmentation><ISUP Indicator><ISUP Preference><ISDN Access><SCCP Method><Translated Called Number Indicator><Query On Release Capability><Spare 2><NPSI Present><Query On Release Present> An example of this field looks like this: <1><1><0><0><0><1><0><0><0><0><0><0><0><0> The 14 subfields are all recorded as numbers. The following table lists the names, types, and possible values and their meanings for the 14 subfields:
Subfield Id
Subfield Name
Subfield Type
Value
Meaning
1 2 3
Present Call Indicator End to End Method
Boolean Number Number
4 5 6 7
Interworking Indicator Segmentation ISUP Indicator ISUP Preference
Number Number Number Number
8 9
ISDN Access SCCP Method
Number Number
10
Translated Called Number Indicator
Number
0 1 0 1 0 1 2 3 0 1 0 1 0 1 0 1 2 0 1 0 1 2 3 0 1 2 3 4 5 6 7 8
Not present Present National Call International Call No end-to-end method Pass along method SCCP method Pass along and SCCP method No interworking encountered Interworking encountered No indication Info received ISUP not used all the way ISUP used all the way Preferred Not required Required Origination access non ISDN Origination access ISDN No indication Connectionless Connection oriented Connectionless and connection oriented Not translated Translated Dip done not translated Translated called number NPSI 0 Translated called number NPSI 4 Translated called number NPSI 5 Translated called number NPSI 6 Translated called number NPSI 7 Translated called number NPSI 8
11
Query On Release Capability Spare 2 NPSI Present Query On Release Present
Number
9 10 11 12 13 14 15 0 1
Translated called number NPSI 9 Translated called number NPSI 10 Translated called number NPSI 11 Translated called number NPSI 12 Translated called number NPSI 13 Translated called number NPSI 14 Translated called number NPSI 15 Not capable Is capable Not used Not present Present Not present Present
12 13 14
Number Boolean Boolean
0 1 0 1
3.20 Backward Call Indicator

The Backward Call Indicator field has the following format: <Present><Charge Indicator><Called Party Status><Called Party Category><End-to-End Method><Interworking Indicator><Segmentation><ISUP Indicator><Hold Indicator><ISDN Access><Echo Control Indicator><SCCP Method> An example of this field looks like this: <1><1><0><1><0><0><0><0><0><1><0><0> The 12 subfields are all recorded as numbers. The following table lists the names, types, and possible values and their meanings for the 12 subfields:
Subfield Id Subfield Name Subfield Type Value Meaning
1 2
Present Charge Indicator
Boolean Number
Called Party Status
Number
Called Party Category
Number
End to End Method
Number
0 1 0 1 2 3 0 1 2 3 0 1 2 3 0 1
Not present Present No indication No charge Charge Spare No indication Subscriber free Connect when free Excessive delay No indication Ordinary subscriber Payphone subscriber Spare No end-to-end method Pass along method
6 7 8 9 10 11 12
Interworking Indicator Segmentation ISUP Indicator Hold Indicator ISDN Access Echo Control SCCP Method
Number Number Number Number Number Number Number
2 3 0 1 0 1 0 1 0 1 0 1 0 1 0 1 2 3
SCCP method Pass along and SCCP method No interworking encountered Interworking encountered No indication Info received ISUP not used all the way ISUP used all the way Not required Required Termination access non ISDN Termination access ISDN In half echo control device not included In half echo control device included No indication Connectionless Connection oriented Connectionless and connection oriented
3.21 Call Status (Field 7)

This field contains a single letter. The possible values and their meanings are as follows:
Value Final Explanation
S I F
Y N N
U R
N N
The called party answered the call and the call is finished. The call is in progress or is a long duration call. CDR manager combines a Release event with the Setup of a live call with a different GCid. This could happen in case there is a fail over of a Call Control Element or IP Call Element during the lifetime of a certain type of call. The call is unsuccessful. The reason could be that the called party didnt answer the call, or circuit is busy, , etc. CDR manager did not receive ingress or egress Release for this call, and CDR manager found that at least one voice channel used by this call is carrying a new call later. If the ingress channel is carrying a new call later, then field I_rel_t will contain the starting time of the new call and I_rlc_t will be null. If the egress channel is carrying a new call later, then field e_rel_t will contain the starting time of the new call and e_rlc_t will be null. CDR manager did not receive ingress or egress Release, and did not receive Checkpoint event at least 5 minutes after a checkpoint period has expired. A checkpoint period is 1 hour by default.
The column Final indicates whether an iCDR with given call status can be classified as final call record. An S iCDR is final, meaning CDRE will not write another iCDR for the same call. By
default, iCDR with call status F, U, R, K are not final. This means CDRE can write another iCDR for the same call if new data for the call is received after the iCDR was written. If parameter CDR_Drop_Event_After_F is set to 1 in file cdra.cfg, CDRE will NOT write another iCDR for those calls for which CDRE wrote an iCDR with call status F already. Parameters CDR_Drop_Event_After_U, CDR_Drop_Event_After_R, and CDR_Drop_Event_After_K work similarly. If CDRE application parameter CDR_Produce_E is set to 1, CDRE may create iCDR with call status E. In this case, the meaning of S will be slightly different, although all other call status values and their meanings will remain the same. When parameter CDR_Produce_E is set to 1, the meanings of S and E are as follows:
Value Final Explanation
The called party answered the call, the call is finished, and the iCDR already contains data from the following 6 basic events: ingress CallSetup, ConnectAnswer, Release, and egress CallSetup, ConnectAnswer, Release. The called party answered the call and the call is finished. However, the iCDR does not contain all of the 6 basic events: ingress CallSetup, ConnectAnswer, Release, egress CallSetup, ConnectAnswer, Release. The iCDR does contain at least one CallSetup, at least one ConnectAnswer, and at least one Release event. At least one of the Answer time is available, and at least one of the Release time is available in iCDRs with call status E.
In the case parameter CDR_Produce_E is set to 1, call status S is still final. By default, call status E is not final. One can make E final by setting CDR_Drop_Event_After_E to 1 in file cdra.cfg. Customer should consult with a Veraz Networks Professional Service Engineer concerning the setting of any application parameter on CDRE.
3.22 Border Gateway Information

Field 156, Border Gateway Info, is an XML string. An example of this string is as follows: <BGH> <BG IP="0.0.0.5:2470" SendT="2008-08-02+08:33:45.4" ID="15" SesId="0" Name="TGW_1"></BG> <STAT IP="0.0.0.5:2470" SendT="2008-08-02+08:33:52.1" ID="15" SesId="0"> <In Sent="18" Rec="0" Drop="0" DropWB="0" Jitt="0" Lat="0"></In> <Out Sent="2" Rec="0" Drop="0" DropWB="0" Jitt="1" Lat="1"></Out> <MAP> <IAdr RTP="0.0.0.2:6000" RTCP="0.0.0.2:6001" T38="0.0.0.0:0" LaRTP="0.0.0.0:0" LaRTCP="0.0.0.0:0" LaT38="0.0.0.0:0"></IAdr> <EAdr RTP="0.0.0.5:20920" RTCP="0.0.0.5:20921" T38="0.0.0.0:0" LaRTP="0.0.0.0:0" LaRTCP="0.0.0.0:0" LaT38="0.0.0.0:0"> </EAdr> </MAP> </STAT> </BGH>
The XML entity names and attribute names are explained in the following table:
Name Entity or Attribute Explanation
BGH BG IP Name SesId SendT MAP IAdr EAdr LaRTCP LaRTP LaT38 RTCP RTP T38 STAT In Out Drop DropWB Jitt Lat Rec Sent
E E A A A A E E E A A A A A A E E E A A A A A A
Border Gateway History. This entity contains one or more BG entities. Border Gateway. This entity contains entities MAP and STAT, and has the following 3 attributes. IP address of the border gateway Name of the border gateway Session Id Send Time MAP entity contains two entities: IAdr and EAdr. Ingress Addresses Egress Addresses. Both IAdr and EAdr have the following 6 attributes. Latch RTCP IP address and port Latch RTP IP address and port Latch T38 IP address and port RTCP IP address and port RTP IP address and port T38 IP address and port Packet Statistics. This entity contains entities In and Out. Packet Statistics on the incoming side. Packet Statistics on the outgoing side. Both In and Out entities have the following 6 attributes. Number of packets dropped Number of packets dropped with bandwidth Jitter Latency Number of packets received Number of packets sent
3.23 iCDR for INAP Prepaid Calls

A typical INAP prepaid call scenario is as follows: Calling party A makes an inbound call into ControlSwitch. After inquiring an INAP server, ControlSwitch directs the call to an IVR (Interactive Voice Response system), where A can enter a called number for party B. After receiving Called Number B from INAP server, ControlSwitch creates an outbound call to Called Party B and connect A with B. After talking with B, party A may re-originate a new call to Called Party C, again through INAP and IVR. After talking with C, A hangs up. In the above typical scenario, ControlSwitch would generate three iCDRs. The contents of the 3 iCDRs can be categorized as follows: iCDR 1 2 3 Ingress half data Data of the ingress half call originated by Calling Party A Data for the virtual ingress half call originated from INAP Data for the virtual ingress half call Egress half data Data of the virtual egress half call terminated at INAP. Data for the egress half call to Called Party B Data for the egress half call to Called Party
originated from INAP
3.23.1 Filtering through Field 3, Parent Global Call Id

In all three iCDRs, field 3, Parent Global Call Id, would be populated with the Global Call Id of the first iCDR. The first iCDR is referred to as parent call. The other two iCDR are referred to as child calls. Consequently, if one wants to see all iCDRs related to a particular INAP prepaid call, he can simply filter iCDRs by specifying a particular Parent Global Call Id. In ControlSwitch CDR GUI, one can supply a particular Parent Global Call Id in filtering.
3.23.2 Data Characteristics of Virtual Half Calls

The data in all the virtual half call fields, including virtual ingress and virtual egress, have the following characteristics: 1. The value of the signaling protocol field, field 18 or field 38, will be 262, meaning VIRTUAL. This is a new value in the Signaling Protocol table. 2. The value of the Call Control Element Id, field 17 or field 37, will be the element id of the SEE (Service Execution Element) which interacts with INAP for this call. 3. Physical resource fields, such Trunk Group id, Gateway Id, Card Id, Span Id, Channel Id, CIC, are all NULL. 4. If ControlSwitch received Furnish Charging Info message from INAP, the content of Furnish Charging Info is recorded in field 89 (Ingress Charge Info) or field 90 (Egress Charge Info), depending on whether ingress half or egress half is Virtual. See section 3.7.3 for more detail on Furnish Charging Info.
3.23.3 Timestamp Fields in Virtual Half Call

The meaning of the timestamp fields in Virtual half calls is as follows: iCDR field id 21 29 30 34 35 41 49 50 51 52 iCDR field name Ingress IAM time Ingress ACM time Ingress ANM time Ingress REL time Ingress RLC time Egress IAM time Egress ACM time Egress ANM time Egress REL time Egress RLC time Meaning Time CONNECT (destination) is received from INAP Time ACM is received. Time ANM is received. Time ERBCSM (origination Disconnect) is sent to INAP. The value of this field will always be identical to field 35. Time INITIAL DP was sent to INAP. The value of this field will always be identical to field 41. Time the first egress ANM is received at INAP. Time TCAP END is sent or received. The value of this field will always be identical to field 51.
4 Configuring EC and CDRE 4.1 Introduction

ControlSwitch allows multiple ECs. ECs are gr ouped in pairs to provid e redundancy. For larg escale deployment, multiple pairs of ECs ca n be used to sha re the load of coll ecting and storing event data. ControlSwitch allows multiple CDREs (CDR Element), to share the load of pro cessing event data and creating iCDRs. There is no pairing between CDREs, because iCDRs can be reconstructed from event files on ECs in case a disaster happened on a CDRE. The disks on a CDRE are protected through disk mirroring or a combination of disk mirroring and RAID. User is required to a ssign an EC a nd a CDRE to elements such CCP and ICE in Cont rolSwitch EMS. Assume CCP1 and CCP2 are p aired, and EC1 and EC2 a re paired. When a use r assigns EC1 and CDRE1 to CCP1 on EMS, for example, it means that: 1. Between CCP1 and CCP2, the active CCP will send all events to both EC1 and EC2. 2. All events for calls that originated from CCP1 or CCP2 will be routed to CDRE1. 3. CDRE1 will get all event s for calls t hat originated from CCP 1 or CCP2, including terminating e vents for th ese calls. Co nsequently, CDRE 1 will create a complete re cord for these calls that inclu de terminating l egs and early routing attempts sh ould re-routing occurred.
4.2 Event Files and Directories on EC

EC sort the events by the destination CDRE. If there is only one CDRE, EC would sto re all event files at /eventdata/cdre1/notsent directory. The CDRE would fetch event files at that location, and move the file to /eventdata/cdre1/sent directory after the fetch is finished. When there are multi ple CDREs, CDRE 1 and CDRE 2 fo r exampl e, ea ch EC wo uld sto re th e events for CDRE 1 in /ev entdata/cdre1/notsent di rectory, and store the eve nts for CDRE 2 in /eventdata/cdre2/notsent directory.
4.3 FTP or SCP?

A user can specify whether CDRE sho uld use FTP or SCP to fetch event files from ECs. User can d o this b y setting the appli cation p arameter Eve nt_Use_Scp. Be default CDRE u ses F TP. The detailed information on how to set this pa rameter is in do cument EC and CDRE Application Parameters.
4.4 Compressed Event Files

The events files req uire a lot of disk space and the g eneral setup requires a disk array for fa ster and effici ent writes. EC has the ability to com press event files before writin g it on di sk. This feature has to be used in conjunction with a CDRE that is able to process compressed event files.
4.4.1 Advantages and Disadvantages of Compressed Event Files

Advantages:
1. Disk usage on EC is red uced dra stically by about 90% - At 60 roughly 1.6 MB which gets reduced to ~100 KB approximately. 2. Reduced I/O wait on both EC and CDRE.
cps event file size is
3. Reduced bandwidth usage when transferring event files from the ECs to the CDREs. Disadvantages: 1. CPU utilization increased on EC and CDRE. 2. Higher disk fragmentation on EC.
4.4.2 Configuring parameter Event_File_Compression on EC and CDRE

Both EC an d CDRE have an application parameter named Event_File_Compression, which can be set to 0 or 1. By default, it is set to 0 on both EC and CDRE. For EC to generate compressed event files, you need to set Event_File_Compression to 1 in ceca.cfg on EC, and restart the EC element through EMS. For CDRE to proce ss com pressed and unco mpressed e vent files, you need to set Event_File_Compression to 1 in cdra.cfg on CDRE, and restart the CDRE through EMS. Acceptable combinations for the settings of Event_File_Compression parameter on EC and CDRE are: Event_File_Compression EC (ceca.cfg) CDRE (cdra.cfg) 0 0 0 1 1 0 1 1 Acceptable Yes Yes No Yes
Before changing the para meter on the EC, make su re that the paramete r is se t correctly on the CDRE acco rding to the table above. If the comp ression featur e h as bee n turn ed on (optio n 4), and you need to turn it off, follow the steps below: 1. Set Event_File_Compression to 0 on EC. Re start the EC. Make a n ote of the time (t1). 2. DO NO T ch ange Event_File_Compression on the CDRE to 0 until CDRE ha s completed processing all the event files until time t1 + 20 minutes (to be on the safe side). 3. Once files h ave been p rocessed, set Event_File_Compression to 0 and resta CDRE. 4. Always make sure that the CDRE shutdown was completed successfully. rt
5 EC and CDRE Application Parameters 5.1 EC Application Parameters

EC application para meters are define d in /opt /IPVRec/ceca.cfg. To change the setting of a parameter, you need to shutdo wn EC, add the new setting in ceca.cfg, and resta rt EC. Certai n
parameters can be changed dynamically, i.e. can be changed through a debug port on EC while EC is running. The following EC application parameters affect how EC operates and need to be set carefully.
Parameter Name Clean_Disk_Frequency Clean_Disk_Save_Hour Congestion_Minutes
Default Value 120 72 60
Explanation EC clea ns u p se nt dire ctory every this many seconds EC re moves f iles in sent directo ry that are older than this many hours. EC raises conge stion al arm if there are mo re than thi s m any minute s of data i n not sent directory. EC keeps an event file open for maximum of this many seconds. EC makes sure all event files have si ze not over this limit in bytes. When disk usag e on partition / eventdata reaches this percentage, EC starts removing old event files in sent di rectory regardless of Clean_Disk_Save_Hour until the u sage d rops below this perce ntage. When di sk u sage re aches this p ercentage, EC will rai se an Alarm that says: Stops writing to disk, and starts ba cking up events in memo ry. When disk usag e drop ped bel ow thi s percentage, EC will clear the Alarm, and resume writing events to disk automatically. EC raises free disk space low alarm if usage of disk pa rtition contai ning /eventdata crosse d this percentage. By default, EC write event files uncompressed. If this parameter is set to 1, EC will generate event files that are comp ressed. For co mpressed event files, the file name is li ke this: event.5_8_2A.4.20091214203955.1.571328.0 The ne w event file name contai ns 2 more characters i nserted after the 4 th period. 1. Means the event file is compre ssed. 0. Means the event file in not compressed.
Actual Value
Data_File_Total_Sec Data_File_Size_Max Disk_Usage_High
5 15000000 95
Disk_Usage_Watermark
80
Event_File_Compression
Send_Data_To_ERS
If this parameter is set to 0, EC will n ot write data files for ERS con sumption. By default, EC writes data files for ERS consumption.
5.2 Group 1 CDRE Application Parameters

CDRE appli cation parameters are defined in /opt/IPVRcdr/cdra.cf g. To change the setting of a parameter, you nee d to shutdo wn CDRE, add the new setting i n cd ra.cfg, a nd re start CDRE. Certain parameters can be changed dynamically, i.e. while CDRE is running. The CDRE application parameters are divided into 2 groups: Group 1 2 Explanation Parameters that affect how iCDR is written Parameters that affect how CDR Element operates.
Here are the Group 1 CDRE application parameters: Parameter Name CDR_Adjust_Duration Default Value 1 Explanation Value 1 means CDRE will check whether I_acm_t, I_anm_t are late r than e_rel_t, and set i_acm_t, i_anm_t to null if true. CDRE will al so check whether e_acm_t, e_anm_t are later than I_rel_t, and set it to null if it true. Value 0 means CDRE will do none of the above. CDR_Adjust_REL_T 1 If this parameter is set to 1, CDRE will check whether a Release time is earlier than the Answer on the same leg. If so, CDRE will set the Release time t o be the same as the Answer time. If this parameter is set to 0, CDRE will do none of the above. CDR_ANM_Local_Time 0 If this parameter is set to 1, CDRE will po pulate two field s 140 (In gress Answer Ti me in local time) and 141 (Egress Answer Time in local time) i n iCDR. If this param eter is set to 0, fields 140 and 141 will be empty. CDR_Call_Duration_Option 2 Value 0 me ans the call_duration field is calcul ated by I_rel_t I_anm_t if the two fields are available, and is Null otherwise. Value 1 me ans the call_duration field is ca lculated by E_rel _t E_anm_t if the two fiel ds are available, and is Null otherwise. Value 2 me ans the call_duration Actual Value
field is calcul ated by I_rel_t I_anm_t if the above 2 fields a re available, or by E_rel_t E_anm_t if the above 2 field s are availabl e, or by E_rel_t I_anm_t if the above 2 fields a re available, or by I_rel_t E_anm_t if the above 2 fields are available, or null. CDR_Check_Digit 1 If this field is set to 0, CDRE will not check digit in fields such CPN, CN, DN, etc. The foll owing 5 parameters ta ke effect only when this parameter is 1. By default, if a characte rs value is less than 32 (the spa ce characte r), it is replaced by 32. If the chara cters valu e is g reater th an 12 6 (ch aracter ~ ), it is replaced by ~. If the characte r is se micolon, it is replaced by comma. User can cha nge the above behavior by adju sting t he follo wing 5 parameters. CDR_Check_Digit_A If a digit is less than CDR_Check_Digit_A, CDRE will replace the digit by the value of the followin g parameter CDR_Check_Digit_AR.
CDR_Check_Digit_AR CDR_Check_Digit_BR
B If a digit is semicolon, C DRE will replace the digit by the value of this parameter. If a digit is gre ater t han this parameter, CDRE will replace the digit by the value of the following para meter CDR_Check_Digit_CR.
CDR_Check_Digit_C
CDR_Check_Digit_CR CDR_DN_Incomplete_Char
~ 0 In the event of SS7 Subsequent Address Messag e wa s mi ssing, CDRE will append this character to Dialed Number field if the Called Numbe r is incomplete. By default, CDRE d oes n ot append a nything. Fo r de bug o r othe r purposes, you can set this to +. If this parameter is 1, CDRE will not generate ano ther iCDR after gene rating an iCDR with c all_status= E for the same call. If this parameter is 1, CDRE will not generate ano ther iCDR after gene rating an iCDR with c all_status= F for the
CDR_Drop_Event_After_E
CDR_Drop_Event_After_F
same call. CDR_Drop_Event_After_K 0 If this parameter is 1, CDRE will not generate ano ther iCDR after gene rating an iCDR with c all_status= K for the same call. If this parameter is 1, CDRE will not generate ano ther iCDR after gene rating an iCDR with call_ status= R fo r th e same call. If this parameter is 1, CDRE will not generate ano ther iCDR after gene rating an iCDR with call_ status= U fo r th e same call. This p arameter set s the max strin g length in early_ events column in Oracle for iCDR. This parameter can not be over 3999. This p arameter set s the max strin g length for early_events field in iCDR. If this parameter is 1, CDRE will fill REL time field with send time if it finds REL time fi eld is empt y in Rel ease events. If CDRE receiv es a Phy sical Channel Id with gat eway id > CDR_Gateway_Max, then CDRE treat the Physical Channel Id as NULL. Value 1 m eans CDRE will write iCDR fields 95 and 96 if some SS7 international variant sp ecific paramete rs are used during the setup of the call. Value 0 means fields 95 and 96 will be empty. CDR_GenericMsgData_Flex_ Print 1 Value 0 mean s wh en writing generic pa rameter o r inf o elem ent o f type Byte Ar ray, a byte array like 66 , 111, 110, 110 will b e written a s \42\6F\6E\6E, using th e hexade cimal values of each byte. Value 1 means a byte will be displayed as a character if it falls in the range of pri ntable cha racters in ASCII table, and di splayed a s \ followed by hexadecimal value otherwise. For the example above, the byte array will be written as Bonn.
CDR_Drop_Event_After_R
CDR_Drop_Event_After_U
CDR_Early_Events_Length
3996
CDR_Early_Events_Length_M ax CDR_Fill_REL_T
8000 1
CDR_Gateway_Max
100000 0
CDR_Proc_GenericMsgData
CDR_Media_Param_Option
If this parameter is set to 1, CDRE would only record the Accepted media parameters, such codec, in iCDR. If this parameter is set to 0, CDRE would not reco rd media parameters i n iCDR. If this parameter is set to 3, CDRE would record all media param eters in iCDR.
CDR_Produce_E
If this parameter is set to 0, CDRE will not generate iCDR with call_status=E. If this parameter is set to 1, CDRE will generate iCDR with call_status=E if the call is successful but CDRE does not have all 6 basi c events: ingress and egress S etup, Co nnnectAnswer, Release, by default. When this parameter is set to 1, the criterion u sed by CDRE in setting call_status=S can be regulated by user through pa rameter ICDR_ S_Min_Msgs. See the explan ation fo r ICDR_S_Min_Msgs for more detail.
CDR_REL_Local_Time
If this parameter is set to 1, CDRE will po pulate two field s 160 (In gress Release Time in local time) and 16 1 (Egress Rele ase Ti me in local time) in iCDR. If this param eter is set to 0, fields 160 and 161 will be empty.
CDR_Subsecond_Digits
User ca n set this parameter between 0 and 6. If positi ve, CDRE wil l write CDR_Subs econd_Digits many subsecond di gits in all tim estamp field s in iCDR. For example, if this parameter is set 3 then all timestamp fields will be accurate up to 0.001 second.
CDR_Success_On_I_ANM
Value 0 means CDRE will set call_status field to U, or unsuccessful, if Ingress ANM time is avai lable, Egress ANM time is null, and the co ntent of parameter Service_Acco unt_Code appeared in I_Service field. Value 1 means CDRE will set
call_status field to S, or succe ss, if that case. Set this value to 0 if Account Code Service is a deployed service. Check_Generic_Data 0 If this param eter is 1, CDRE will check wheth er the re i s semi-colon ; i n the XmlString field in events se nt by ICE and CCE, and repl ace semi -colon b y \3B, the h exadecimal v alue of semicolon. If this param eter is 1, CDRE will record po st Digit Analysi s value in CN field. If this param eter is 1, CDRE will record post Digit Analysi s value in CPN field. GenericMessageData h as an attribute na med Lo gable. By default, CDRE wou ld not log data in GenericMessageData in which L ogable is Fals e. If y ou s et this parameter to 0, CDRE would log Gen ericMessageData in iCDR even when Logable=False. If this parameter is set to 1, CDRE will write he ader and footer in each iCDR file. CDRE insert this chara cter before the port in field 60 (Ori ginating Gateway IP Address) and field 6 1 (Terminatin g Gateway IP Address). If this parameter is 0, CDRE will not write anythi ng in field 132 (Earl y Events). CDRE will in sert this value in the zone_id field in iCDR. The value need s to be a number. This is a nu mber. Wh en written in binary form, each bit rep resents a particular ev ent. See T able 3: CDR component encodin g i n the iCDR documentation for what ea ch bit me ans. See explan ation of CDR_Pro duce_E how this parameter is used. If this parameter is set 1, CDRE wil l drop those ICE call set up events in which TG name field is empty or gateway name field is empty.
CN_UsePostDA
CPN_UsePostDA
GenericMessage_Check_Log able
ICDR_File_Header
ICDR_IP_Port_Separator
ICDR_Save_Old_Event
ICDR_Zone_Id
ICDR_S_Min_Msgs
0x7007
ICE_Message_Check
Log_Sip_Generic_Data
For SIP calls, CDRE may receive an XML stri ng, whi ch contain s data regarding whethe r SIP-I feature is triggered. By default, CDRE logs thi s XML string in iCDR. If you dont want to log this data i n iCDR, set this pa rameter to 0. By default, CDRE does not c reate field 163 in iCDR. If this parameter is set to 1, CDRE will create a n empty field 163. If this p arameter is set to 2, CDRE will create field 163 and put SEE id in it.
Show_SEE_ID_IN_ICDR

Group 2 CDRE Application Parameters affect how CDR Element operates.
Parameter Name db_cleanup_time
Default Value 04:04
Explanation This parameter specifies the time a t which to start the daily cle anup of Oracle database. In this field, the time is in local time if PartitionGMT= 0, othe rwise, it is G MT time. A change in this param eter will take effect only a fter you re boot the CDRE box. Note that thi s pa rameter doe s not have CDRM_Parameter in front of it.
Actual Value
days_back
This parameter specifies the number of days CDRE should keep data in Oracle database. A change in this param eter will take effect only a fter you re boot the CDRE box. Note that thi s pa rameter doe s not have CDRM_Parameter in front of it. The minimum and maximum value of this parameter are 1 and 6 respectively. If this param eter i s in creased, m ake sure the re i s enou gh disk spa ce for t he Oracle data on the CDRE host.
CDR_Disk_Clean_Path1
"/cdr/ICD R/primary "
If this parameter is set to a valid directory, CDRE will d o cleanu p on th e iCDR files in this directory so that the disk usage does not go beyond 96%. When this parameter is set to a valid directory, CDRE woul d pe riodically ch eck the disk ca pacity of the disk partit ion containing thi s di rectory, a nd remove 20 oldest files if the free di sk spa ce of the disk pa rtition drop ped b elow 2% an d if there is at least 40 files in the directory. At cust omer sit e, plea se set t his parameter to the directo ry where fetched iCDR files reside, for example, CDRM_Parameter CDR_Disk_Clean_Path1=/cdr/ICDR/ secondary Set this param eter to null: CDRM_Parameter CDR_Disk_Clean_Path1= if custom er has hi s o wn disk cleanup procedure for removing old iCDR files.
CDR_Disk_Clean_Path2
If this para meter is set to a valid directory, CDRE will d o cleanu p on th e iCDR files in this directory so that the disk usage does not go beyond 96%. Be default, among two pa ired EC s, CDRE tre at one of them Active, one of them Standb y. CDRE w ould not pr ocess data from the Standby EC unless it finds a gap in data on the Active EC. If you want CDRE to pro cess all events from the Standby EC as well as the Acti ve EC, set this parameter to 1. In this setting, CDRE pe rformance will be impa cted. Therefore, do not set thi s parameter to 1 permanently. If CDRE finds the send time of the first event s in two consecutive event file s from the pri mary EC are apart by more than EC_Data_File _Gap_Min se conds, CDRE will try to retrieve event files from the standby EC in order to fill in the gap. If CDRE finds a gap in the event sequences of two con secutive eve nts from a Network Element, CDRE will try to fill in the gap by fetching events from t he
EC_All_Active
EC_Data_File_Gap_Min
15
EC_Data_Gap_Sec_Min
standby EC only wh en th e differe nce in send time o n the two ev ents i s at le ast EC_Data_Gap_Sec_Min seconds. Event_Use_Scp 0 Value 0 mea ns CDRE wil l use FTP to retrieve files from E C. Value 1 means CDRE will use rcp to retrieve files from EC. Value 2 means CDRE will use scp to retrieve files from EC. If the disk u sage of th e disk partition containing /cdr is over ICDR_Disk_Clean_Max in perce ntage, CDRE will remove old iCDR files until the disk u sage i s bel ow ICDR_Disk_Clean_Max in percentage. This param eter is not used if parameters CDR_ Disk_Clean_Path1 a nd CDR_Disk_Clean_Path2 are set to null. At cust omer sit e, plea se set t his parameter to 92%, because di sk fragmentation may ren der a disk p artition useless even thoug h di sk usa ge i s o nly 95%. ICDR_File_Frequency ICDR_File_Size_Max 60 100 CDRE will keep an iCDR file open for this maximum number of seconds This p arameter specifies th e maximum size of iCDR files in megabytes. CDRE wi ll c reate a n ew i CDR file when the si ze i s about to exceed it s limit o r when the time reaches its limit, whichever comes first.
ICDR_Disk_Clean_Max
96
ICDR_Seq_Wrap_Around Long_Duration_Alarm_Typ e
9999999 0 Default valu e 0 means that all Long Duration Alarm s rai sed by CDRE will be stateful alarm s, which m eans the alarms will be in t he Current Alarms screen in EM S until CDRE send in Cl ear Alarms. Value 1 means that all Long Duration Alarms rai sed by CDRE will be stateless alarms, whi ch mean s the alarm s are informational and will not be in the Current Alarms screen in EMS.
Long_Duration_Alarm_On_ Channel
Default valu e 1 means that CDRE will raise Long Duration Call Alarm on the incoming T DM cha nnel t he call uses. Value 0 means that CDRE will raise Long Duration Call Alarm on the incomin g trunk group the call uses. If the parameter were
set to 0, two long duratio n calls o n the same trunk g roup may result in only on e alarm in EMS alarm screen. PartitionGMT 1 Value 0 mea ns CDRE will switch t o new d atabase partition s start at midnig ht Local time. Value 1 means CDRE will do that at midnight GMT time. If CDRE normal shut do wn can not complete before this se conds, CDRE wil l exit itself. On Sola ris 5.10, Op en SSH i s installed automatically. If you installe d our own version of SSH, CDRE would use our own version of SSH by default. If you prefer to use Ope n SSH, set this parameter to 1.
Shut_Down_Timeout_Sec
600
SSH_Use_Open_SSH

Group 3 CDRE Application Parameters are set in Oracle database on CDRE. Parameter Name TG_UTL_DATA_DAYS_K EPT Default Value 7 Explanation CDRE removes data in tables TG_utilization_summary and Span_utilization_summary that is more than TG_UTL_DATA_DAYS_KEPT days old daily. To change this value, one needs to run SQL statements such as update application_parameters set parameter_value=10 where parameter_name= TG_UTL_DATA_DAYS_KEPT; commit; through SQLPlus. Actual Value
6 CDRE Application Parameters Questionnaire 6.1 Do you want to have Call Status E iCDR?
Parameter Possible values Default Question Your answer How to set CDR_Produce_E 0 (No) or 1 (Yes). 1 Do you want to have call status E iCDR? If your answer is yes, then set this parameter to 1. Otherwise set it to 0.
parameter Meaning of 1
The benefit of setting this parameter to 1 are: 1. This will make successful calls into twp groups: Call status S group, meaning all essential data are available, and call status E group: meaning the rest. 2. If parameter CDR_Drop_Event_After_E is set to 0, it is possible that CDRE may write a call status S iCDR after writing a call status E iCDR for the same call. Draw back of setting this parameter to 1: The billing system that processes iCDR needs to have a procedure in dealing with the call status E iCDRs.
6.1.1 Suggested process on handling Call Status E iCDR for customers

On the handling of call status E iCDRs, we suggest the following procedure for customers billing system. To help explaining the suggested process, we assumed that the billing system uses relational database. 1. Assume the billing system put iCDRs into a table, say CDR_Table, in a relational database, customer can add column COUNTED of type Boolean to CDR_Table. By default, COUNTED is set to False for all rows. 2. Customer can add a unique index on the GCId column in CDR_Table. 3. When a row with call_status=S is inserted into CDR_Table, customer to do the billing on such a CDR right away and set COUNTED to True on it. 4. When a row with other call status is inserted into CDR_Table, customer should set COUNTED to False. 5. While trying to insert a Veraz iCDR into CDR_Table, if there is a row with the same GCId already, check whether COUNTED is True in the row. If the existing row has COUNTED=True, drop the new iCDR. If the existing row has COUNTED=False, overwrite the row by the new iCDR, and proceed to Step 3 or Step 4 as if the row is newly inserted. Periodically, (every hour, or everyday, for instance), customer can select out the rows in CDR_Table where call_status=E and COUNTED is False and the value in UPDATE_TIME (This is a field in Veraz iCDR) is at least 2 hours earlier than the UPDATE_TIME in the most recent Veraz iCDR, do billing on such rows, and set COUNTED to True on such rows.
6.2 Will Account Code service be deployed?

In Account Code Service, a caller is directed to a media server and is asked to enter an Account Code for authentication and authorization. If the authentication or authorization fails, the call is released. In such a case, CDRE would set the Call_Status to U (Unsuccessful) although the ingress Answer event was sent to the caller so that the caller can hear the service announcement and can enter the account code through keys or voice. Parameter Possible values Default Question Your answer How to set parameter Meaning of 1 CDR_Success_On_I_ANM 0 (No) or 1 (Yes). 0 Is Account Code service deployed, or will be deployed? If your answer is yes, set CDR_Success_On_I_ANM to 0. Otherwise set it to 1. Value 1 means that if CDRE received a valid ingress Answer time for a call, then CDRE will set Call_Status to S or E regardless whether
Meaning of 0
egress Answer time is available for the call. This parameter works in the case where CDRE received a valid ingress Answer time for a call, but egress Answer time is not available. In such a case, if field 130 (Ingress Service Info) indicates Account Code service was deployed for the call, then CDRE will set Call_Status to U (Unsuccessful), otherwise, CDRE will set Call_Status to S or E.
6.3 Should a Call_Status E iCDR be final?

An iCDR is Final means that CDRE will not write another iCDR for the same GCid. All iCDRs with Call_Status S are final. Parameter Possible values Default Question Your answer How to set parameter Meaning of 1 Meaning of 0 CDR_Drop_Event_After_E 0 (No) or 1 (Yes). 0 Should a Call_Status E iCDR be final? If your answer is yes, then set this parameter to 1. Otherwise set it to 0. After writing a Call_Status=E iCDR, CDRE will not write another iCDR for the same GCid, even if new event for the call is received. After writing a Call_Status=E iCDR, CDRE may write another iCDR for the same GCid with Call_Status S if new event for the call is received and the new data warrants a change in Call_Status.
6.4 Should a Call_Status U iCDR be final?

Parameter Possible values Default Question Your answer How to set parameter Meaning of 1 Meaning of 0 CDR_Drop_Event_After_U 0 (No) or 1 (Yes). 0 Should a Call_Status U iCDR be final? If your answer is yes, then set this parameter to 1. Otherwise set it to 0. After writing a Call_Status=U iCDR, CDRE will not write another iCDR for the same GCid, even if new event for the call is received. After writing a Call_Status=U iCDR, CDRE may write another iCDR for the same GCid with a different Call_Status if new event for the call is received and the new data warrants a change in Call_Status.
6.5 Should a Call_Status R iCDR be final?

Parameter Possible values Default Question Your answer How to set parameter CDR_Drop_Event_After_R 0 (No) or 1 (Yes). 0 Should a Call_Status R iCDR be final? If your answer is yes, then set this parameter to 1. Otherwise set it to 0.
Meaning of 1 Meaning of 0
After writing a Call_Status=R iCDR, CDRE will not write another iCDR for the same GCid, even if new event for the call is received. After writing a Call_Status=R iCDR, CDRE may write another iCDR for the same GCid with a different Call_Status if new event for the call is received and the new data warrants a change in Call_Status.
6.6 Should a Call_Status K iCDR be final?

Parameter Possible values Default Question Your answer How to set parameter Meaning of 1 Meaning of 0 CDR_Drop_Event_After_K 0 (No) or 1 (Yes). 0 Should a Call_Status K iCDR be final? If your answer is yes, then set this parameter to 1. Otherwise set it to 0. After writing a Call_Status=K iCDR, CDRE will not write another iCDR for the same GCid, even if new event for the call is received. After writing a Call_Status=K iCDR, CDRE may write another iCDR for the same GCid with a different Call_Status if new event for the call is received and the new data warrants a change in Call_Status.
6.7 Should a Call_Status F iCDR be final?

Parameter Possible values Default Question Your answer How to set parameter Meaning of 1 Meaning of 0 CDR_Drop_Event_After_F 0 (No) or 1 (Yes). 0 Should a Call_Status F iCDR be final? If your answer is yes, then set this parameter to 1. Otherwise set it to 0. After writing a Call_Status=F iCDR, CDRE will not write another iCDR for the same GCid, even if new event for the call is received. After writing a Call_Status=F iCDR, CDRE may write another iCDR for the same GCid with a different Call_Status if new event for the call is received and the new data warrants a change in Call_Status.
6.8 Is customer interested in SS7 Generic Parameters?

In many SS7 national variants, carriers sometimes put country specific or customer specific data in SS7 Generic Parameters. ControlSwitch offers customers the ability to insert, remove, and change the generic parameters through XML scripts. Such generic parameters can also be logged in iCDR if customer desires. For more detail, please see section 3.8 in Veraz CDR document Parameter Possible values Default Question Your answer CDR_Proc_GenericMsgData 0 (No) or 1 (Yes). 1 Is customer interested in the data in SS7 Generic Parameters?
How to set parameter Meaning of 1 Meaning of 0
If your answer is yes, then set this parameter to 1. Otherwise set it to 0. Populate fields 95 (Ingress Generic Parameters) and 96 (Egress Generic Parameters) when the data is available. Do not populate fields 95 (Ingress Generic Parameters) and 96 (Egress Generic Parameters).
6.9 Disk Usage Alarms

CDRE may raise and clear the following Alarms. Alarm Name CDR_ICDR_DISK_THRESHOLD CDR_ICDR_DISK_SPACE Sample Content The disk space usage in partition /cdr reached 80% percent. The disk usage in the partition containing /cdr reached 96% percent. CDR Element will suspend processing until the disk usage drops below 96% percent. The disk usage in the partition containing /u02 reached 96% percent. CDR Element will suspend processing until the disk usage drops below 96% percent.
CDR_DATABASE_DISK_SPACE
The threshold for Alarm CDR_ICDR_DISK_THRESHOLD is set in the EMS GUI screen CDR Manager. By default, the threshold is 80%. One can change the threshold by giving a value in the Water Mark field in the CDR Manager screen. The threshold for Alarm CDR_ICDR_DISK_SPACE is set through parameter ICDR_Disk_Clean_Max in the configuration file /opt/IPVRcdr/cdra.cfg on the CDRE. The parameter is explained in section 5.3. The threshold for Alarm CDR_DATABASE_DISK_SPACE is also set through parameter ICDR_Disk_Clean_Max in the configuration file /opt/IPVRcdr/cdra.cfg on the CDRE.
6.10 Should CDRE automatically clean up the disk partition containing iCDR files?
CDRE has the ability to maintain the disk usage level not going over a threshold for the /cdr partition by periodically checking and removing old iCDR files. More specifically, CDRE checks the disk usage level for the disk partition mounted at /cdr every 10 minutes. If CDRE finds that the disk usage percentage is over ICDR_Disk_Clean_Max (default is 98%), CDRE will keep removing old iCDR files in CDR_Disk_Clean_Path1 (if it is set to a valid directory) and CDR_Disk_Clean_Path2 (if it is set to a valid directory) until the disk usage percentage drops below ICDR_Disk_Clean_Max. Parameter Possible values Default Question CDR_Disk_Clean_Pat CDR_Disk_Clean_Pat ICDR_Disk_Clean_M h1 h2 ax Any directory Any directory 2-99 /cdr/ICDR/primary null 98 Should CDRE automatically clean up the disk partition containing iCDR
Your answer How to set parameter
files? If your answer is yes, you should set CDR_Disk_Clean_Path1 to /cdr/ICDR/secondary, set CDR_Disk_Clean_Path2 to null, and set ICDR_Disk_Clean_Max to 90. If your answer is no, set CDR_Disk_Clean_Path1 to null, and set CDR_Disk_Clean_Path2 to null.
6.11 Set Other Notable Parameters

On the following parameters, please see the explanations in section 5.2 and 5.3 for further details. Parameter Name CDR_ANM_Local_Time CDR_Call_Duration_Option CDR_Check_Digit CDR_Subsecond_Digits
CN_UsePostDA
CPN_UsePostDA ICDR_Save_Old_Event db_cleanup_time days_back Event_Use_Scp ICDR_File_Header ICDR_File_Frequency ICDR_Seq_Wrap_Around
Possible values 0 or 1 02 0 or 1 0-6 0 or 1 0 or 1 0 or 1 hh:mm 1-6 0 or 1 0 or 1 15 - 300 9999 - 999999999
Default 0 2 1 0 0 0 1 04:04 3 0 0 60 9999999
Your choice
Appendix 1: Value Name Mapping for iCDR Fields

Table 10: Type of Call Definitions
ENUM VALUE Description
0 1 2 3 4 5 7 8 9 10 11
Unknown Local Long Distance International Operator Emergency Local Toll Operator Local Toll Operator Long Distance Operator International Service Code
12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 50
Nine Hundreds VPN Five Hundreds Transit 0ther Carrier Chosen Toll Free Test Call Incoming Outgoing Operator Toll Intra Zone 1 Inter Zone 1 Collect Call Operator Services Long Distance Special Services Value Added Services Donation Services Value Added Services Entertainment Priority
Table 11 Nature of Address of Called Party Number

Value Description
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22
Unknown Subscriber Not Available Or Not Provided National International Ani Of The Called Party Subscriber Ani Of The Called Party Not Included Ani Of The Called Party National Spare_8 Spare_9 Spare_10 Spare_11 Spare_12 Spare_13 Spare_14 Spare_15 Spare_16 Spare_17 Spare_18 Spare_19 Spare_20 Spare_21 Spare_22
23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68
Spare_23 Spare_24 Spare_25 Spare_26 Spare_27 Spare_28 Spare_29 Spare_30 Spare_31 Spare_32 Spare_33 Spare_34 Spare_35 Spare_36 Spare_37 Spare_38 Spare_39 Spare_40 Spare_41 Spare_42 Spare_43 Spare_44 Spare_45 Spare_46 Spare_47 Spare_48 Spare_49 Spare_50 Spare_51 Spare_52 Spare_53 Spare_54 Spare_55 Spare_56 Spare_57 Spare_58 Spare_59 Spare_60 Spare_61 Spare_62 Spare_63 Spare_64 Spare_65 Spare_66 Spare_67 Spare_68
69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114
Spare_69 Spare_70 Spare_71 Spare_72 Spare_73 Spare_74 Spare_75 Spare_76 Spare_77 Spare_78 Spare_79 Spare_80 Spare_81 Spare_82 Spare_83 Spare_84 Spare_85 Spare_86 Spare_87 Spare_88 Spare_89 Spare_90 Spare_91 Spare_92 Spare_93 Spare_94 Spare_95 Spare_96 Spare_97 Spare_98 Spare_99 Spare_100 Spare_101 Spare_102 Spare_103 Spare_104 Spare_105 Spare_106 Spare_107 Spare_108 Spare_109 Spare_110 Spare_111 Reserved For National Use _112 Subscriber Number Operator requested National Number Operator Requested
115 116 117 118 119 120 121 122 123 124 125 126 127 65535 Table 12 Protocol Type
Values
International Number Operator Requested No Address Present Operator Requested No Address Present Zero Cut Through 950 call Test Line Reserved For National Use 120 Reserved For National Use 121 Reserved For National Use 122 Reserved For National Use 123 Reserved For National Use 124 Reserved For National Use 125 Reserved For National Use 126 Spare_127 Not Set
Description
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27
ISUP_ANSI PRI_NI_2 MGCP CAS_MF CAS_DTMF CAS_BPBX Invalid ISUP_C7 PRI_ETSI H323 ISUP_UK ISUP_SG PRI_NI_2PLUS ISUP_J7_NTT ISUP_J7_TTC SIP MGCP_NAS QSIG ISUP_INDIA ISUP_FRANCE ISUP_GERMANY ISUP_HOLLAND ISUP_ROMANIA ISUP_RUSSIA ISUP_PANAMA ISUP_ARGENTINA ISUP_CHILE ISUP_PARAGUAY
28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73
ISUP_MEXICO ISUP_BRAZIL ISUP_VENEZUELA ISUP_PUERTARICO ISUP_NICARAGUA ISUP_PERU ISUP_SURINAME ISUP_DOMINICANREPUBLIC ISUP_AFGHANISTAN ISUP_ALBANIA ISUP_ALGERIA ISUP_ANDORRA ISUP_ANGOLA ISUP_ANTIGUA_BERBUDA ISUP_ARMENIA ISUP_AUSTRALIA ISUP_AUSTRIA ISUP_AZERBAIJAN ISUP_BAHAMAS ISUP_BAHRAIN ISUP_BANGLADESH ISUP_BARBADOS ISUP_BELARUS ISUP_BELGIUM ISUP_BELIZE ISUP_BENIN ISUP_BHUTAN ISUP_BOLIVIA ISUP_BOSNIA ISUP_BOTSWANA ISUP_BRUNEI ISUP_BULGARIA ISUP_BURKINAFASO ISUP_BURUNDI ISUP_CAMBODIA ISUP_CAMEROON ISUP_CANADA ISUP_CAPEVERDE ISUP_CENTRALAFRICANREPUBLIC ISUP_CHAD ISUP_CHINA ISUP_COLOMBIA ISUP_COMOROS ISUP_CONGO ISUP_CONGODMR ISUP_COSTARICA
74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119
ISUP_COTEDLVOIRE ISUP_CROATIA ISUP_CUBA ISUP_CYPRUS ISUP_CZECHREPUBLIC ISUP_DENMARK ISUP_DJIBOUTI ISUP_EASTTIMOR ISUP_ECUADOR ISUP_EGYPT ISUP_ELSALVADOR ISUP_EQUATORIALGUINEA ISUP_ERITREA ISUP_ESTONIA ISUP_ETHIOPIA ISUP_FIJI ISUP_FINLAND ISUP_GABON ISUP_GAMBIA ISUP_GEORGIA ISUP_GHANA ISUP_GREECE ISUP_GRENADA ISUP_GUATEMALA ISUP_GUINEA ISUP_GUINEABISSAU ISUP_GUYANA ISUP_HAITI ISUP_HONDURAS ISUP_HUNGARY ISUP_ICELAND ISUP_INDONESIA ISUP_IRAN ISUP_IRAQ ISUP_IRELAND ISUP_ISRAEL ISUP_ITALY ISUP_JAMAICA ISUP_JAPAN ISUP_JORDAN ISUP_KAZAKHSTAN ISUP_KENYA ISUP_KIRIBATI ISUP_NORTHKOREA ISUP_SOUTHKOREA ISUP_KUWAIT
120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165
ISUP_KYRGYZSTAN ISUP_LAOS ISUP_LATVIA ISUP_LEBANON ISUP_LESOTHO ISUP_LIBERIA ISUP_LIBYA ISUP_LIECHTENSTEIN ISUP_LITHUANIA ISUP_LUXEMBOURG ISUP_MACEDONIA ISUP_MADAGASCAR ISUP_MALAWI ISUP_MALAYSIA ISUP_MALDIVES ISUP_MALI ISUP_MALTA ISUP_MARSHALL_ISLANDS ISUP_MAURITANIA ISUP_MAURITIUS ISUP_MICRONESIA ISUP_MOLDOVA ISUP_MONACO ISUP_MONGOLIA ISUP_MOROCCO ISUP_MOZAMBIQUE ISUP_MYANMAR ISUP_NAMIBIA ISUP_NAURU ISUP_NEPAL ISUP_NETHERLANDS ISUP_NEWZEALAND ISUP_NIGER ISUP_NIGERIA ISUP_NORWAY ISUP_OMAN ISUP_PAKISTAN ISUP_PALAU ISUP_PAPUANEWGUINEA ISUP_PHILIPPINES ISUP_POLAND ISUP_PORTUGAL ISUP_QATAR ISUP_RWANDA ISUP_SAINTKITTSNEVIS ISUP_SAINTLUCIA
166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 220 221 222
ISUP_SAINTVINCENTGRENADINES ISUP_SAMOA ISUP_SANMARINO ISUP_SAOTOMEPRINCIPE ISUP_SAUDIARABIA ISUP_SENEGAL ISUP_SERBIAMONTENEGRO ISUP_SEYCHELLES ISUP_SIERRALEONE ISUP_SINGAPORE ISUP_SLOVAKIA ISUP_SOLOMONISLANDS ISUP_SOMALIA ISUP_SOUTHAFRICA ISUP_SPAIN ISUP_SRILANKA ISUP_SUDAN ISUP_SWAIZILAND ISUP_SWEDEN ISUP_SWITZERLAND ISUP_SYRIA ISUP_TAIWAN ISUP_TAJIKISTAN ISUP_THAILAND ISUP_TOGO ISUP_TONGA ISUP_TRINIDADTOBAGO ISUP_TUNISIA ISUP_TURKEY ISUP_TURKENISTAN ISUP_TUVALU ISUP_UGANDA ISUP_UKRAINE ISUP_UAE ISUP_URUGUAY ISUP_UZBEKISTAN ISUP_VANUATU ISUP_VATICANCITY ISUP_VIETNAM ISUP_YEMEN ISUP_ZAMBIA ISUP_ZIMBABWE ISUP_ETSI_V1 ISUP_SPARE_220 ISUP_HK ISUP_SPARE_222
223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 Table 13 Trunk Group Type
Values
ISUP_SPARE_223 ISUP_SPARE_224 ISUP_SPARE_225 ISUP_SPARE_226 ISUP_SPARE_227 ISUP_SPARE_228 ISUP_SPARE_229 ISUP_SPARE_230 ISUP_SPARE_231 ISUP_SPARE_232 ISUP_SPARE_233 ISUP_SPARE_234 ISUP_SPARE_235 ISUP_SPARE_236 ISUP_SPARE_237 ISUP_SPARE_238 ISUP_SPARE_239 ISUP_SPARE_240 IPP0 IPP1 IPP2 IPP3 IPP4 IPP5 IPP6 IPP7 IPP8 IPP9 MGCP_PKTCABLE_BAU MGCP_PKTCABLE_AAU CAS_FGD OSP CAS_2BIT_SL CAS_2BIT_ZSL CAS_2BIT_SLZSL CAS_2BIT_SLM CAS_2BIT_TOLL CAS_R2_BRAZIL CAS_R2_MEXICO VIRTUAL
Description
0 1
Unknown Normal (ISUP)

2 3 Table 14 OLI
Values
DAL (PRI) IP (H323 or SIP)
Description
O 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40
Identified Line Multi Party ANI Failure Unavailable Unassigned_3 Unassigned_4 Unassigned_5 Hotel No Room Identification Coin Less Hospital Inmate Inter lata Restricted Unassigned_9 TestCall Unassigned_11 NotAssignable_ConflictWithIntOutpulsingCode_12 NotAssignable_ConflictWithIntOutpulsingCode_13 NotAssignable_ConflictWithIntOutpulsingCode_14 NotAssignable_ConflictWithIntOutpulsingCode_15 NotAssignable_ConflictWithIntOutpulsingCode_16 NotAssignable_ConflictWithIntOutpulsingCode_17 NotAssignable_ConflictWithIntOutpulsingCode_18 NotAssignable_ConflictWithIntOutpulsingCode_19 AIOD_ListedDN Unassigned_21 Unassigned_22 CoinOrNonCoinIdentifiedLine EightHundredServiceCall TollFreeTranslatedToPotsFromAnyPayStation Unassigned_26 CoinLine Unassigned_28 PrisonInmateService Intercept_Blank Intercept_Special Intercept_Regular Unassigned_33 TelcoOperatorHandledCall Unassigned_35 Unassigned_36 Unassigned_37 Unassigned_38 Unassigned_39 UnrestrictedUse_LocallyDeterminedByCarrier_40
41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86
UnrestrictedUse_LocallyDeterminedByCarrier_41 UnrestrictedUse_LocallyDeterminedByCarrier_42 UnrestrictedUse_LocallyDeterminedByCarrier_43 UnrestrictedUse_LocallyDeterminedByCarrier_44 UnrestrictedUse_LocallyDeterminedByCarrier_45 UnrestrictedUse_LocallyDeterminedByCarrier_46 UnrestrictedUse_LocallyDeterminedByCarrier_47 UnrestrictedUse_LocallyDeterminedByCarrier_48 UnrestrictedUse_LocallyDeterminedByCarrier_49 Unassigned_50 Unassigned_51 OutWats Unassigned_53 Unassigned_54 Unassigned_55 Unassigned_56 Unassigned_57 Unassigned_58 Unassigned_59 TRS_UnrestrictedLine CellularType1_CellularCarrierIdentified CellularType2_MobileDnIdentified CellularServiceRoaming Unassigned_64 Unassigned_65 TRS_HotelMotel TRS_RestrictedLine InterLataRestrictedHotelLine Unassigned_69 PrivatePayStation Unassigned_71 Unassigned_72 Unassigned_73 Unassigned_74 Unassigned_75 Unassigned_76 Unassigned_77 InterLataRestrictedCoinless Unassigned_79 Unassigned_80 Unassigned_81 Unassigned_82 Unassigned_83 Unassigned_84 Unassigned_85 Unassigned_86
87 88 89 90 91 92 93 94 95 96 97 98 99 Table 15 Carrier Selection Identifier 0 1 2 3 4 5 6 Table 16 Release Cause 1 2 3 4 5 6 7 8 9 14 15 16 17 18 19 20 21 22 24 25
Unassigned_87 Unassigned_88 Unassigned_89 Unassigned_90 Unassigned_91 Unassigned_92 PrivateVirtualNetwork Unassigned_94 TestCall_95 Unassigned_96 Unassigned_97 Unassigned_98 Unassigned_99
No Indication Carrier Id Presubscribed And Not Input By Clg Pty Carrier Id Presubscribed And Input By Clg Pty Carrier Id Pre Subscribed Input By Clg Pty Undetermined Carrier Id Not Presubscribed And Input By Clg Pty Carrier Id Selected By Input Of Clg Pty Carrier Id Selected By A Network Operator
Unallocated NoRouteToSpecifiedTransitNetwork NoRouteToDestination SendSpecialInformationTone MisdialledTrunkPrefix ChannelUnacceptable CallAwardedBeingDelivered Preemption PreemptionCircuitReservedForReuse QueryOnRelease Spare_15 NormalRelease UserBusy NoUserResponding NoAnswerFromUser SubscriberAbsent CallRejected NumberChanged NumberUnassigned ExchangeRoutingError
26 27 28 29 30 31 34 35 38 39 40 41 42 43 44 46 47 49 50 52 53 54 55 57 58 59 60 62 63 65 66 69 70 79 81 82 83 84 85 86 87 88 90 91 92 95
NonSelectedUserClearing DestinationOutOfOrder InvalidNumberFormat FacilityRejected ResponseToStatusEnquiry NormalUnspecified NoCircuitAvailable CallQueued NetworkOutOfOrder PermanentFrameModeConnectionOOS PermanentFrameModeOperational TemporaryFailure SwitchingEquipmentCongestion AccessInformationDiscarded RequestedChannelCircuitUnavailable PrecedenceCallBlocked ResourceUnavailableUnspecified QualityOfServiceUnavailable RequestedFacilityNotSubscribed OutgoingCallsBarred OutgoingCallsBarredWithinCUG IncomingCallsBarred IncomingCallsBarredWithinCUG BearerCapabilityNotAuthorized BearerCapabilityNotPresentlyAvailable CallRestricted TerminalCallRedirectionRejected InconsistencyInDesignatedOutgoingaccessInformationAndSubsciberClass ServiceOptionNotAvailableUnspecified BearerCapabilityNotImplemented ChannelTypeNotImplemented RequestedFacilityNotImplemented OnlyRestricteddigitalInforBearerCapAvailable ServiceOrOptionNotImplementedUnspecified InvalidCallReferenceValue IdentifiedChannelDoesNotExist SuspendedCallExistsIdentityDoesNot CallIdentityInUse NoCallSuspended CallWithReqIdentityCleared UserNotMemberOfCUG IncompatibleDestination NonExistentCUG InvalidTransitNetworkselection InvalidFacilityParameter InvalidMessageUnspecified
96 97 98 99 100 101 102 103 110 111 112 113 114 126 127 256 257 258 Table 17 Bearer Capability 0 1 2 3 4 5 6 7 8 9 10 11
MandatoryInformationElementMissing MessageTypeNonExistentOrNotImplemented MsgNotCompatibleWithStateOrNotImplemented InformationElementParameterNonexistenNotImplemented InvalidInforElemContents MsgNotCompatibleWithState RecoveryOnTimerExpiry ParameterNotImplementedPassedOn MsgWithUnrecognizedParamDiscarded ProtocolErrorUnspecified ProtocolDescriminatorError BearerServiceNotAvailable EndToEndInfoTransferImpossible EnteringConversationMode InterworkingUnspecified InvalidVceType CallServiceNotSupported FailureResponse
Speech Audio3_1Khz UnrestrictedDigitalInfo RestrictedDigitalInfo UnrestrictedDigitalInfoWithTonesAndAnnc Audio_7Khz Unrestricted_64Kbps Unrestricted_2x64Kbps Unrestricted_384Kbps Unrestricted_1536Kbps Unrestricted_1920Kbps Invalid
Table 18 Generic Number Nature of Address

Value Description
0 1 2 3 4 5 6 7 8
Unknown Subscriber NotAvailableOrNotProvided National International AniOfTheCalledParty_Subscriber AniOfTheCalledParty_NotIncluded AniOfTheCalledParty_National Spare_8

9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54
55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100
101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127
Spare_101 Spare_102 Spare_103 Spare_104 Spare_105 Spare_106 Spare_107 Spare_108 Spare_109 Spare_110 Spare_111 ReservedForNationalUse_112 Subscriber Number Operator requested National Number Operator Requested International Number Operator Requested No Address Present Operator Requested No Address Present Zero Cut Through Nine_Five_Zero_Call Test Line ReservedForNationalUse_120 ReservedForNationalUse_121 ReservedForNationalUse_122 ReservedForNationalUse_123 ReservedForNationalUse_124 ReservedForNationalUse_125 ReservedForNationalUse_126 Spare_127
Table 19 Redirecting Indicator 0 1 2 3 4 5 6 NoRedirection CallRerouted CallReroutedRedirectionInfoRestr CallForwarded CallFwdRedirectionInfoRestr CallReroutedRedirectionNumRestr CallFwdRedirectionNumRestr
Table 20 Redirecting Reason 0 1 2 3 4 Unknown UserBusy NoReply Unconditional DeflectionDuringAlerting

5 6 15
DeflectionImmediateResponse MobileSubscriberNotReachable NoLastInstanceOfRedirection
Table 21 Original Redirecting Reason 0 1 2 3 4 Unknown UserBusy NoReply Unconditional Deflection
Table 22 CLI Blocking Indicator 0 1 NoInformation Available
Table 23 Network Translated Address 0 1 NoInformation Translated
Table 24 Calling Party Category

Values Description
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
Unknown OperatorFrench OperatorEnglish OperatorGerman OperatorRussian OperatorSpanish OperatorSpare1 OperatorSpare2 OperatorSpare3 NationalOperator OrdinarySubscriber PrioritySubscriber DataCall TestCall Emergency PayPhone Spare_16 Spare_17 Spare_18 Spare_19 Spare_20 Spare_21
22 23 24
25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65
Spare_22 Spare_23 For ISUP Brazil or CAS R2 Brazil, this means Prepaid. For other signaling protocols, this means Spare_24 Spare_25 Spare_26 Spare_27 Spare_28 Spare_29 Spare_30 Spare_31 Spare_32 Spare_33 Spare_34 Spare_35 Spare_36 Spare_37 Spare_38 Spare_39 Spare_40 Spare_41 Spare_42 Spare_43 Spare_44 Spare_45 Spare_46 Spare_47 Spare_48 Spare_49 Spare_50 Spare_51 Spare_52 Spare_53 Spare_54 Spare_55 Spare_56 Spare_57 Spare_58 Spare_59 Spare_60 Spare_61 Spare_62 Spare_63 Spare_64 Spare_65
66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111
112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157
158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203
204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249
Spare_204 Spare_205 Spare_206 Spare_207 Spare_208 Spare_209 Spare_210 Spare_211 Spare_212 Spare_213 Spare_214 Spare_215 Spare_216 Spare_217 Spare_218 Spare_219 Spare_220 Spare_221 Spare_222 Spare_223 ReservedForNationalUse_224 ReservedForNationalUse_225 ReservedForNationalUse_226 ReservedForNationalUse_227 ReservedForNationalUse_228 ReservedForNationalUse_229 ReservedForNationalUse_230 ReservedForNationalUse_231 ReservedForNationalUse_232 ReservedForNationalUse_233 ReservedForNationalUse_234 ReservedForNationalUse_235 ReservedForNationalUse_236 ReservedForNationalUse_237 ReservedForNationalUse_238 ReservedForNationalUse_239 ReservedForNationalUse_240 ReservedForNationalUse_241 ReservedForNationalUse_242 ReservedForNationalUse_243 ReservedForNationalUse_244 ReservedForNationalUse_245 ReservedForNationalUse_246 ReservedForNationalUse_247 ReservedForNationalUse_248 ReservedForNationalUse_249
250 251 252 253 254 255 Table 25 Called Party Category 0 1 2 3
ReservedForNationalUse_250 ReservedForNationalUse_251 ReservedForNationalUse_252 ReservedForNationalUse_253 ReservedForNationalUse_254 Spare_255
No Indication Ordinary subscriber Payphone subscriber For ISUP Brazil or CAS R2 Brazil, this means Prepaid. For other signaling protocols, this means Spare
Table 26 Release Cause Location 0 1 2 3 4 5 6 7 10 User Local private network Local local network Transit network Remote local network Remote private network Local interface International network Network beyond inter-working pt
Table 27 Codec 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 G711 G723 G729 GSM G726A G711A G729A G711U G723AR53 G723AR63 G723R53 G723R63 G723R32 G729B G729AB
15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
Invalid G726R16 G726R24 G726R40 G728R16 CCD Any T38 GSM_EFR AMR_12_20 AMR_10_20 AMR_7_95 AMR_7_40 AMR_6_70 AMR_5_90 AMR_5_15 AMR_4_75
Table 28 HLC Characteristic Identification

Value Meaning
0 1 2 3 4 33 36 40 49 50 51 53 56 65 66 94 95 96 97 98 99 100 101 102 103
Reserved Telephony Reserved 2 Reserved 3 Facsimile Group 2 Or 3 Facsimile Group 4 Class I Facsimile Service Group 4 Classes II and III Services 1 Services 2 Syntax Based Videotex International Videotex Interworking Via Gateways Or Interworking Units Telex Service Message Handling Systems OSI Application FTAM Application Reserved For Maintenance Reserved For Management Video Telephony Video Conferencing Audio Graphic Conferencing Reserved For Audio Visual Service 1 Reserved For Audio Visual Service 2 Reserved For Audio Visual Service 3 Reserved For Audio Visual Service 4 Reserved For Audio Visual Service 5
104 105 106 107 108 109 110 111 255 256
Multimedia Services Reserved For Audio Visual Service 6 Reserved For Audio Visual Service 7 Reserved For Audio Visual Service 8 Reserved For Audio Visual Service 9 Reserved For Audio Visual Service 10 Reserved For Audio Visual Service 11 Reserved For Audio Visual Service 12 Reserved Invalid
Table 29 LLC Information Transfer Capability

Value Meaning
0 8 9 16 17 24 25 32
Speech Unrestricted Digital Information Restricted Digital Information Audio 3 1 KHz Unrestricted Digital Information With Tones Announcements Video Reserved Invalid
Table 30 Calling Party Category for CAS R2

Values Description
0 1 2 3 4 5 6 7 8 11
Unknown OrdinarySubscriber SubscriberSpecialRate MaintainenceEquip PayphoneLocal Operator DataCommEquip PayphoneLongDistance CollectCall ForwardedCall
Table 31 LLC User Information Layer 1 Protocol

Value Meaning
1 2 3 4 5 6
ITUTStandardizedRateAdaptionV110_I460_X30 G711ULaw G711ALaw G721 H221AndH242 H223AndH245

7 8 9 10
NonITUTStandardizedRateAdaption ITUTStandardizedRateAdaptionV120 ITUTStandardizedRateAdaptionX31 Invalid
Appendix 2: CDR_LOG Table in Database

CDRE has an Oracle database. The CDR_Log table in the database contains the last few days of the most recent call data. The following table describes the columns in CDR_Log table.
Table 32 Columns in CDR_Log table and their corresponding iCDR fields

Column Name Data Type Corresponding ICDR Field Name ICDR Field id
Zone_id Cdr_seq Gc_id Update_t Component partition Event_order Call_status R_Call_Type CPN CN DN Addr_Nature I_OLI I_LRN I_carrier_ic I_carrier_si I_cce_id I_protocol I_tg_type I_tg_id I_iam_t I_gateway I_card I_span I_channel I_d_channel
number number Varchar2(32) date NUMBER NUMBER VARCHAR2(100) VARCHAR2[2] NUMBER VARCHAR2[24] VARCHAR2[24] VARCHAR2[32] NUMBER VARCHAR2[24] VARCHAR2[24] VARCHAR2[24] NUMBER NUMBER NUMBER NUMBER NUMBER DATE NUMBER NUMBER NUMBER NUMBER NUMBER
Zone id Record Sequence Identifier Global Call Identifier Last Received Update Time Stamp CDR Component Indicator No correspondence in iCDR See the explanation on iCDR fields CDR Status Call Type Calling party number Charge Number Called Party Number Nature of Address for Called Party Number Originating Line Information Ingress LRN Ingress Carrier Identifier Code Ingress Carrier Selection Information Ingress Call Control Element ID Ingress Trunk Group Protocol Ingress Trunk Group Type Ingress Trunk Group Id Ingress Signal Start Time Stamp Ingress Gateway Id Ingress Card Id Ingress Span Id Ingress Channel Number Ingress D Channel
1 2 4 5
6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26
I_call_ref I_cc_t I_acm_t I_anm_t R_tn R_lrn R_carrier_ic I_rel_t I_rlc_t I_rel_cause E_cce_id E_protocol E_tg_type E_tg_id E_setup_t E_gateway E_card E_span E_channel E_d_channel E_call_ref E_cc_t E_acm_t E_anm_t E_rel_t E_rlc_t E_rel_cause Cp_earliest Cp_last I_gateway_name E_gateway_name I_tg_name E_tg_name I_gw_ip E_gw_ip H323_conf_id I_card_port I_card_path E_card_port E_card_path E_tg_number E_tg_number I_orig_dn I_orig_dn_addr_nature
NUMBER DATE DATE DATE CHAR [24] CHAR [24] CHAR [24] DATE DATE NUMBER NUMBER NUMBER NUMBER NUMBER DATE NUMBER NUMBER NUMBER NUMBER NUMBER NUMBER DATE DATE DATE DATE DATE NUMBER DATE DATE CHAR [50] CHAR [50] CHAR [50] CHAR [50] CHAR [24] CHAR [24] CHAR [32] NUMBER NUMBER NUMBER NUMBER NUMBER NUMBER CHAR [32] NUMBER
Ingress ISDN Call Reference Number Ingress Create Connection Complete Time Stamp Ingress Address complete Time Stamp Ingress Call Answer Time Stamp Egress Calling Party Number. Terminating LRN Translated Carrier IC Ingress Call Release Time Stamp Ingress Release Complete Time Stamp Ingress Release Cause Code Egress Call Control Element ID Egress Trunk Protocol Egress Trunk group Type Egress Trunk Group Id Egress Call Start time stamp Egress Gateway_ID Egress Card Id Egress Span Number Egress Channel Number Egress D_Channel Number Egress ISDN Call Reference Egress Create Connection Complete Time Stamp Egress Address complete Time Stamp Egress Call Answer Time Stamp Egress Call Release Time Stamp Egress Release Complete Time Stamp Egress Release Cause Code Last Ingress Check Point Time Stamp Last Egress Check Point Time Stamp Ingress Gateway Name Egress Gateway Name Ingress Trunk Group Name Egress Trunk Group Name Originating Gateway IP address Terminating Gateway IP address H323 Conference Id Ingress Card Port Number Ingress Card Path Number Egress Card Port Number Egress Card Path Number Ingress Trunk Group Number Egress Trunk Group Number Original Dialed Number Original Dialed Number Nature of Address
27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70
I_redir_n I_redir_n_addr_nature I_redir_ind I_redir_reason I_redir_orig_n I_redir_orig_n_addr_nat ure I_redir_orig_reason I_redir_counter I_redir_n_pi I_jip E_jip I_bearer E_bearer I_tns_carrier_c I_presentation_n
CHAR [24] NUMBER NUMBER NUMBER CHAR [24] NUMBER NUMBER NUMBER NUMBER CHAR [32] CHAR [32] NUMBER NUMBER CHAR [24] CHAR [24]
Redirecting Information Redirecting Number Redirecting Number Nature of Address Redirecting Indicator Redirecting Reason Original Called Number Original Called Number Nature of Address Original Redirecting Reason Redirection Counter Presentation Indicator for Redirecting Number Jurisdiction Parameter from Ingress Jurisdiction Parameter from Egress Ingress trunk bearer capability Egress trunk bearer capability Transit Network Selection Carrier Code 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</EC> Ingress internal release cause Egress internal release cause Egress Called Number Nature of Address for egress Called Number Egress Connected Number Nature of Address for egress Connected Number Presentation Indicator for Calling Party Number Ingress IRI Egress ORI Ingress External Call Id Egress External Call Id Ingress Charge Info Egress Charge Info Incoming Partial Call Indicator Incoming National Forward Call Indicator Incoming Last Diverting Line Identity J7 specific information Ingress Additional Party Category Ingress Charge Area Info Ingress Calling Party Category Ingress Forward Call Indicator Egress Additional Party Category
71 71.1 71.2 71.3 71.4 71.5 71.6 71.7 71.8 71.9 72 73 74 75 76 77
I_int_rel_cause E_int_rel_cause E_dn E_dn_noa E_conn_n E_conn_n_noa Cpn_pi I_IRI E_ORI I_ext_call_id E_ext_call_id I_charge E_charge I_partialcli I_nationalfci I_last_div_line_id J7 specific information I_add_party_cat I_charge_area_info I_calling_party_cat I_fwd_call_ind E_add_party_cat
CHAR [16] CHAR [16] VARCHAR2[32] NUMBER VARCHAR2[24] NUMBER NUMBER NUMBER NUMBER CHAR [256] CHAR [256] VARCHAR2[600] VARCHAR2[600] CHAR [24] CHAR [16] CHAR [24] CHAR [2200] VARCHAR2[150] VARCHAR2[60] VARCHAR2[10] VARCHAR2[180] VARCHAR2[150]
78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 94.1 94.2 129 149 94.3
E_charge_area_info E_bkwd_call_ind Carrier_info_xfer I_generic E_generic I_packet_sent I_packet_received I_packet_lost I_packet_transferred I_byte_sent I_byte_received I_byte_lost I_jitter I_latency E_packet_sent E_packet_received E_packet_lost E_packet_transferred E_byte_sent E_byte_received E_byte_lost E_jitter E_latency I_CIC E_CIC I_codec E_codec I_local_gw_id E_local_gw_id I_cas_cc_t E_cas_cc_t I_zzcode E_zzcode I_country_adr_type E_country_adr_type I_part E_part I_service E_service Early_events
VARCHAR2[60] VARCHAR2[180] VARCHAR2[700] VARCHAR2[700] VARCHAR2[700] NUMBER NUMBER NUMBER NUMBER NUMBER NUMBER NUMBER NUMBER NUMBER NUMBER NUMBER NUMBER NUMBER NUMBER NUMBER NUMBER NUMBER NUMBER NUMBER NUMBER NUMBER NUMBER NUMBER NUMBER TIMESTAMP TIMESTAMP VARCHAR(4) VARCHAR(4) VARCHAR(4) VARCHAR(4) NUMBER NUMBER VARCHAR(1000) VARCHAR(1000) VARCHAR(4000)
Egress Charge Area Info Egress Backward Call Indicator Carrier Info Transfer Ingress Generic Parameter Egress Generic Parameter Ingress Packets Sent Ingress Packets Received Ingress Packets Lost Ingress Packets Transferred Ingress Bytes Sent Ingress Bytes Received Ingress Bytes Lost Ingress Jitter Ingress Latency Egress Packets Sent Egress Packets Received Egress Packets Lost Egress Packets Transferred Egress Bytes Sent Egress Bytes Received Egress Bytes Lost Egress Jitter Egress Latency Circuit Identification Code Circuit Identification Code
Logical gateway inside a ControlSwitch in a H323 or SIP network Logical gateway inside a ControlSwitch in a H323 or SIP network
94.4 150 94.5 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 130 131 132
Specific for CAS calls Specific for CAS calls Specific for CAS calls Specific for CAS calls Used only in certain customers network. A prefix extracted from called number. Used only in certain customers network. A prefix extracted from called number. See the explanation on service field in section 3.12 See the explanation on service field in section 3.12 See the explanation on early event field in section 3.13
I_cause_loc E_cause_loc Reverse_charge_ind E_called_party_cat Call_duration_cust I_rel_direction E_rel_direction I_hlc_char_id E_hlc_char_id I_llc_trans_cap E_llc_trans_cap I_codec_history E_codec_history I_final_codec_list E_final_codec_list I_Clear_Forward_t E_Clear_Forward_t I_Clear_Back_t E_Clear_Back_t Egress calling party category Border Gateway Info Border Gateway Id I_llc_trans_uilp E_llc_trans_uilp SEE_ID Parent_gcid Packets_sent Packets_received Packets_lost Packets_transferred bytes_sent bytes_received bytes_lost
NUMBER NUMBER CHAR[1] NUMBER NUMBER NUMBER NUMBER NUMBER NUMBER NUMBER NUMBER VARCHAR(600) VARCHAR(600) VARCHAR(60) VARCHAR(60) TIMESTAMP TIMESTAMP TIMESTAMP TIMESTAMP WORD32 CHAR[2000] WORD32 NUMBER NUMBER NUMBER Varchar2(32) NUMBER NUMBER NUMBER NUMBER NUMBER NUMBER NUMBER
See the explanation on iCDR fields See the explanation on iCDR fields See the explanation on iCDR fields See the explanation on iCDR fields See the explanation on iCDR fields See the explanation on iCDR fields See the explanation on iCDR fields See the explanation on iCDR fields See the explanation on iCDR fields See the explanation on iCDR fields See the explanation on iCDR fields Ingress codec history. For more detail, see section 3.18 Egress codec history. For more detail, see section 3.18 Ingress Final Codec Negotiation list. For more detail, see section 3.18 Egress Final Codec Negotiation list. For more detail, see section 3.18 See the explanation on iCDR field See the explanation on iCDR field See the explanation on iCDR field See the explanation on iCDR field See the explanation on iCDR field See the explanation on iCDR field See the explanation on iCDR field See the explanation on iCDR fields See the explanation on iCDR fields See the explanation on iCDR field Parent Global Call Identifier Unused column has no corresponding iCDR field. Unused column has no corresponding iCDR field. Unused column has no corresponding iCDR field. Unused column has no corresponding iCDR field. Unused column has no corresponding iCDR field. Unused column has no corresponding iCDR field. Unused column has no corresponding iCDR field.
133 134 135 136 137 138 139 142 143 144 145 146 147 148 162 151 152 153 154 155 156 157 158 159 163 3

582 30 CDR v21

Diunggah oleh

Informasi Dokumen

Deskripsi Asli:

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

582 30 CDR v21

Diunggah oleh

Hak Cipta:

Format Tersedia

ControlSwitch

Sys. Ver. 5.8.2 Pub. Ver. 1.17.

Veraz Networks CDR for ControlSwitch Interconnect 5.8.2

02/23/2010 02/23/2010 07/16/2010 08/25/2010

1.17.18 1.17.19 1.17.20 1.17.21

Proprietary Document of Veraz Networks, Inc. -3-

Veraz Networks CDR for ControlSwitch Interconnect 5.8

BAF Record Files ................................................................................................................ 9

Veraz Networks CDR for ControlSwitch Interconnect 5.8.2

CDRE Application Parameters Questionnaire........................................................................ 53 6.1

Proprietary Document of Veraz Networks, Inc. -5-

Veraz Networks CDR for ControlSwitch Interconnect 5.8

Proprietary Document of Veraz Networks, Inc. -6-

Veraz Networks CDR for ControlSwitch Interconnect 5.8.2

ControlSwitch produces BAF records for the following call types.

2.1.1 BAF Record Call Types

714 720 008 033

2.1.2 Call Type 720

022 028 070 164 720

Veraz Networks CDR for ControlSwitch Interconnect 5.8

2.1.3 Call Type 714

022 028 070 164 720

2.1.4 Call Type 008

2.1.5 Call Type 033

Proprietary Document of Veraz Networks, Inc. -8-

Veraz Networks CDR for ControlSwitch Interconnect 5.8.2

BAF Record Files

2.2.1 File Creation

2.2.2 File Naming

2.2.3 Long Duration Call

2.2.4 File Storage

2.2.5 File Transmission

Veraz Networks CDR for ControlSwitch Interconnect 5.8

3 ControlSwitch CDR Specification

File Naming Convention

File Transfer and Storage

Proprietary Document of Veraz Networks, Inc. - 10 -

Veraz Networks CDR for ControlSwitch Interconnect 5.8.2

3.3.1 iCDR Transfer to Mediation/Billing Platforms

iCDR Field Description

Ingress Forward Call Indicator Egress Backward Call Indicator

Table 1: iCDR Data Type Description

Proprietary Document of Veraz Networks, Inc. - 11 -

Veraz Networks CDR for ControlSwitch Interconnect 5.8

WORD32 WORD64 WORD16 ENUM

Zone id Record Sequence Identifier Parent Global Call Identifier

WORD64 WORD64 CHAR[22]

CHAR[22] TIMESTAMP CHAR[100]

Proprietary Document of Veraz Networks, Inc. - 12 -

Veraz Networks CDR for ControlSwitch Interconnect 5.8.2

CHAR[2] ENUM CHAR[24] CHAR[24] CHAR[32] ENUM CHAR[24]

ENUM ENUM WORD32

TIMESTAMP WORD32 WORD32 WORD32 WORD32 WORD32 WORD32 TIMESTAMP

Proprietary Document of Veraz Networks, Inc. - 13 -

Veraz Networks CDR for ControlSwitch Interconnect 5.8

CHAR [24] CHAR [24]

TIMESTAMP TIMESTAMP TIMESTAMP TIMESTAMP WORD32 TIMESTAMP

Proprietary Document of Veraz Networks, Inc. - 14 -

Veraz Networks CDR for ControlSwitch Interconnect 5.8.2

TIMESTAMP CHAR [50]

CHAR [50] CHAR [50] CHAR [23]

Terminating Gateway IP address