Text Call Detail Records

2011-02-02T13:49:45Z

Krzysztof Drewicz: /* Default values */

Text [[call detail record|call detail records]] (CDR) are saved in a log file on disk.

In order to save disk space and simplify the archiving and backup of CDR log files, this log file is automatically archived (gzipped) and rotated every N seconds, as specified by the system configuration.

The format of the CDR traces is defined by configuration, using variables that are replaced by the Gateway application when writing to the log.
For example, the following variable will be replaced by the called number:
@{CalledNumber}

== Enabling text CDR ==
Text CDR functionality is enabled through the Toolpack Web Portal:
*Go to the '''Gateway->Configuration''' menu.
*Click on the '''Edit''' link of the configuration you wish to enable CDR for.
*Click on '''Use CDR behavior''' to enable the CDR behavior
*Expand the '''CDR Options''' section
*Click on '''Use text CDR''' to enable text-based CDR
*Expand the '''Text CDR parameters''' section
*Configure the '''Text CDR parameters''' the way you want, using the parameters describe below

== Configuration parameters ==

*'''CDR log file path''': Path of the CDR log file, relative to the current working directory of the Gateway application (e.g.[...]/toolpack/setup/12358/apps/gateway).
*'''CDR format (start)''': Format of the text CDR log written at the time the call is answered (or terminated if it was never answered). This format contains variables automatically replaced (see below).
*'''CDR format (update)''': Format of the text CDR log written periodically during call if the CDR option '''Enable periodic CDR update''' is used. This format contains variables automatically replaced (see below).
*'''CDR format (end)''': Format of the text CDR log written at the time the call is terminated. This format contains variables automatically replaced (see below).
*'''Rotation delay in seconds''': Delay, in seconds, at which the log file is rotated and gzipped. A delay of 3600 seconds will make log file rotate every hour, for example. '''NOTE''': This parameter cannot be larger then 86400 seconds (1 day). A value of 0 will be considered as the equivalent of the maximum value.
*'''Max total size of gzipped CDR logs''': Maximum total size (in bytes) of all gzipped log file segments on disk. If ever total size exceeds this limit, older gzipped log files will be deleted. A value of 0 will be considered as unlimited size.

== Available variables ==
The following variables exist and can be used to define the CDR log format:
*@{ApplicationName}: Name of the application that has written this log ("Gateway")
*@{CalledNumber}: Called number
*@{CallingNumber}: Calling number
*@{CallType}: Call type ("Telephony" or "VOIP")
*@{Codec}: Codec used for this call ("G711" for example)
*@{ConnectedTime}: Time where the call was answered (and connected with another leg) (in number of seconds since epoch)
*@{ConnectedTime:format}: Same as @{ConnectedTime} but with custom print format (local time zone), using 'strftime' style, with added support for @m replaced by milliseconds.
Example format: %Y-%m-%d %H:%M:%S.@m -> 2009-09-02 12:16:24.333
*@{ConnectedTimeUtc:format}:Same as @{ConnectedTime:format} but printed in UTC time, rather than local time zone.
*@{EndTime}: Time where the call has started terminating (in number of seconds since epoch).
Note that slightly differs from the @{Timestamp}, since the 'End' CDR trace is printed once the call has finished terminating,
while @{EndTime} reports the time where the call has started terminating (upon hangup for example).
*@{EndTime:format}: Same as @{EndTime} but with custom print format (local time zone), using 'strftime' style, with added support for @m replaced by milliseconds.
Example format: %Y-%m-%d %H:%M:%S.@m -> 2009-09-02 12:16:24.333
*@{EndTimeUtc:format}: Same as @{EndTime:format} but printed in UTC time, rather than local time zone.
*@{LegId}: Unique Id for this leg (32 bits value, but may eventually be upgraded to 64 bits value).
Please note that in current implementation this Id is unique at a given time,
but it can be reused later for subsequent calls. This Id will, however, remain constant
even if there is a HA switchover between any active and standby components of the system.
*@{LinkId}: Unique Id of the link between two call legs (32 bits value, but may eventually be upgraded to 64 bits value).
Please note that in current implementation this Id is unique at a given time, but it can be reused later for subsequent calls.
*@{MediaInfo}: Protocol type dependent information on the call leg.
For TDM (Telephony) calls (SS7 or ISDN): "trunk_name:timeslot_nb".
For VOIP calls (SIP): "codec@ip:port"
*@{NAP}: Name of the NAP this call leg is from
*@{OrginatorName}: Direction of the call:
- "originate" (incoming call leg) - "answer" (outgoing call leg)
*@{Protocol}: Type of protocol used ("SS7", "ISDN", or "SIP")
*@{RemoteIP}: For VOIP calls, IP address of the remote peer for this call leg.
*@{RemotePort}: For VOIP calls, UDP port of the remote peer for this call leg.
*@{SessionId}: Unique call identifier, in the form of 4 values of 32 bits, printed as 4 blocks of 8 hexadecimal charaters separated by a space.
Please note that in current implementation this Id is unique at a given time, but it can be reused later for subsequent calls.
*@{StartTime}: Time where the call was created (in number of seconds since epoch)
*@{StartTime:format}: Same as @{StartTime} but with custom print format (local time zone), using 'strftime' style, with added support for @m replaced by milliseconds.
Example format: %Y-%m-%d %H:%M:%S.@m -> 2009-09-02 12:16:24.333
*@{StartTimeUtc:format}: Same as @{StartTime:format} but printed in UTC time, rather than local time zone.
*@{TerminationCause}: Cause of the call termination, printed as an integer value (refering enum TBCMC_CALL_REASON_CODE)
*@{TerminationCauseString}: Cause of the call termination, printed as an string value
*@{TerminationSource}: Identifies which of the legs has initiated the call termination first: "LocalLeg" or "ConnectedLeg"
*@{TimeslotNumber}: For TDM (Telephony) calls, timeslot number that this call was using for audio.
*@{Timestamp}: Time where this CDR log entry was written.
Note that slightly differs from the @{Timestamp}, since the 'End' CDR trace is printed once the call has finished terminating,
while @{EndTime} reports the time where the call has started terminating (upon hangup for example).
*@{Timestamp:format}: Same as @{Timestamp} but with custom print format (local time zone), using 'strftime' style, with added support for @m replaced by milliseconds.
Example format: %Y-%m-%d %H:%M:%S.@m -> 2009-09-02 12:16:24.333
*@{TimestampUtc:format}: Same as @{Timestamp:format} but printed in UTC time, rather than local time zone.
*@{TrunkName}: For TDM (Telephony) calls, name of the trunk that this call was using for audio.
*@{UserName}: For SIP calls, name of the user.
*@{ChargeIndicator}: For TDM (SS7 and CASR2); received charge indicator in Alert message.

== Redundancy ==

In a redundant Toolpack system with two Gateway applications, the active Gateway application writes the CDR logs.

The analysis of the logs for the purpose of extracting billing information must be done after combining the two logs, sorting the entries by timestamp for example.

It is worth noting that an entry will never be duplicated. It can, however, be lost during transition from active to standby Gateway applications following a system fault. Consequently, a CDR analysis script must thus handle the case where a call answered log does not match any call termination log.

== Default values ==

The default values are as follows:

<br> For the CDR that is printed when the call leg is answered:

@{Timestamp:%Y-%m-%d %H:%M:%S.@m%z},BEG,SessionId='@{SessionId}',LegId='@{LegId}',
StartTime='@{StartTime}',ConnectedTime='@{ConnectedTime}',Calling='@{CallingNumber}',
Called='@{CalledNumber}',NAP='@{NAP}',Protocol='@{Protocol}',Direction='@{OrginatorName}'

(Note: the above is a signle line!)<br>

For the CDR that is printed throught the call at periodic intervals (if this option is enable on the CDR behavior):

@{Timestamp:%Y-%m-%d %H:%M:%S.@m%z}: SessionId='@{SessionId}' LegId='@{LegId}'

For the CDR that is printed when the call leg is terminated:

@{Timestamp:%Y-%m-%d %H:%M:%S.@m%z},END,SessionId='@{SessionId}',LegId='@{LegId}',
StartTime='@{StartTime}',ConnectedTime='@{ConnectedTime}', EndTime='@{EndTime}',
FreedTime='@{Timestamp}',TerminationCause='@{TerminationCauseString}',
Calling='@{CallingNumber}',Called='@{CalledNumber}',NAP='@{NAP}',Direction='@{OrginatorName}'

<br>

(Note: the above is a signle line!)<br>

== Examples ==

For example, one may define a short comma-separated value-based (CSV) CDR log file to minimize disk space requirements:
"@{LegId},@{ConnectedTime},@{EndTime},@{CallingNumber},@{CalledNumber},@{NAP}"

As another example, one may define a XML-based CDR log file:
<cdr_start>
<time timestamp="@{Timestamp}" start_time="@{StartTime}" connect_time="@{ConnectedTime}" end_time="@{EndTime}"/>
<id session_id="@{SessionId}" leg_id="@{LegId}" link_id="@{LinkId}"/>
<number calling="@{CallingNumber}" called="@{CalledNumber}" direction="@{OrginatorName}"/>
<info nap="@{NAP}" protocol="@{Protocol}" called="@{CalledNumber} media="@{MediaInfo}"/>
<termination cause="@{TerminationCauseString}" source="@{TerminationSource}"/>
</cdr_start>

== How to retrieve CDR ==

The CDR log files are located in the directory {Install Directory}/toolpack/setup/12358/apps/gateway/{CDR log file path}. The '{CDR log file path}' is set in the web portal see above.

=== default location ===
*Linux:
** /lib/tb/toolpack/setup/12358/apps/gateway/cdr_logs/
*Windows:
** C:\TelcoBridges\tb\toolpack\setup\12358\apps\gateway\cdr_logs\

There are several ways to fetch those files, here is a short list of most common tools:
* Filezilla (using SFTP)
* scp (for Linux user)

== Notes ==
*This mode of operation is not recommended for [[TMG800]] or [[TMG3200]] with a flash disk. However, the TMG3200 with SATA disk option is OK (use command cat /proc/device-tree/model to identify your device model).
*TelcoBridges does not recommend storing CDR logs via network file systems (NFS or other). We highly recommend writing to a local hard drive and have developed a background script that moves the gzipped log segments for backup or analysis.

TMP6400

2009-12-07T14:19:30Z

Krzysztof Drewicz: /* Available configurations */

[[Image:Tdev 1U Front sml.jpg|thumb|250px|Front view of TMP6400 in 1U form factor ]]
The TelcoBridges [[Tdev]]™ TMP6400 is a high-density computer telephony (CTI) development platform that meets the needs of service providers looking to expand their [[value-added services]] (VAS), providing a cost-effective foundation for introducing new offerings while rapidly scaling to meet the needs of growing subscribers.

[[Image:Tdev 2U Front sml.jpg|thumb|250px|Front view of TMP6400 in 2U form factor ]]

Whether deployed on a wireline, wireless or VOIP network, the TMP6400 delivers seamless voice interoperability across TDM and IP networks. However the TMP6400 builds on those capabilities with an advanced application platform for delivering [[ringback tones|ring-back tones]], [[unified communications]], [[Prepaid & postpaid calling|pre-paid/post-paid calling]], [[conferencing]], [[Fax over IP]] (T.38), [[voicemail]], and other enhanced services to subscribers irrespective of access protocol or device. Leveraging TelcoBridges’ [[Toolpack]]™ software toolkit, and a choice of host deployment platforms, the TMP6400 provides the ability to rapidly develop and deploy applications that tie together real-time communications from the network with stored external data sources to provide unique subscriber-specific services.

[[Image:1U Rear 16T1E1 AC sml.jpg|thumb|250px|Rear view of TMP6400 with support for 16 T1/E1 ]]

Offering the industry-leading highest port density and the lowest operating cost—an average 66% less power consumption than competing products offering similar capacity—the fully field-upgradable Tdev TMP6400 supports the drive by service providers to increase their profitability, while reduce the environmental impact of their network footprint.

== Features & Benefits ==
[[Image:1U Rear DS3 AC sml.jpg |thumb|250px|Rear view of TMP6400 with support for 3 DS3 connections ]]

'''Carrier grade:''' Architected to exacting industry standards, the TMP6400 is designed to meet the need for reliability that service providers and their customers demand. The TMP6400 features a non-blocking architecture providing full availability of call channels and other system resources (IVR, VOIP).

[[Image:1U Rear STM1 AC sml.jpg |thumb|250px|Rear view of TMP6400 with support for 1 STM-1 connection ]]

'''Flexibility:''' A network-agnostic platform, the TMP6400 supports multiple ‘any-to-any’ switching as well as transcoding support for all major wireline, wireless and Internet voice codecs. With separate chipsets for signaling, [[transcoding]] and [[IVR|interactive voice response (IVR)]], the TMP6400 provides true full channel availability.

'''Density:''' Supporting up to 64 T1/E1/J1, 3 DS-3 or 1 STM-1 interfaces for a total of 2048 universal voice channels per unit, the TMP6400 offers significant density in a 1U or 2U form factor. The TMP6400 enables consolidation of multiple devices for signaling, transcoding and IVR into a single box.

'''High availability:''' The TMP6400 features full redundancy with fault-tolerant hardware and software components.

== Available configurations ==

*TMP6410 – 8 x T1/E1/J1
*TMP6412 – 16 x T1/E1/J1
*TMP6414 – 32 x T1/E1/J1
*TMP6416 – 48 x T1/E1/J1
*TMP6418 – 64 x T1/E1/J1
*TMP6420 – 1 x DS-3
*TMP6422 – 2 x DS-3
*TMP6424 – 3 x DS-3
*TMP6430 – 1 x STM-1

Each configuration is available with AC or DC power. Measured consumption of 6402 with 64 E1 on copper is about 1.7 A on -48VDC.

== Related actions ==
*[[Toolpack:Adding a TMP6400|Add a TMP6400 to an existing system]]

== References ==
*[[Media:DATA SHEET TMP6400.pdf|Data sheet]]
*[[Media:TMP6400_Installation_Guide_Issue2.2.pdf|TMP6400 and TMS1600 Installation guide]]
*[[Media:TMP6401_AC_QIG_Issue3.1.pdf|TMP6401 (1U/AC) Quick Installation guide]]
*[[Media:TMP6401_DC_QIG_Issue2.1.pdf|TMP6401 (1U/DC) Quick Installation guide]]
*[[Media:TMP6402_AC_QIG_Issue3.1.pdf|TMP6402 (2U/AC) Quick Installation guide]]
*[[Media:TMP6402_DC_QIG_Issue2.1.pdf|TMP6402 (2U/DC) Quick Installation guide]]
*[[Regulatory compliance]]

[[category:Hardware]]

TBwiki - User contributions [en]

Text Call Detail Records

TMP6400