CDR Specification SwyxServer 2011 R2 - swyxdownload.com€¦ · CDR Specification SwyxServer 2011...

Call Detail Record (CDR) Specification of

SwyxServer 2011 R2

Swyx Solutions AG

Joseph-von-Fraunhofer-Str. 13a

44227 Dortmund

CDR Specification SwyxServer 2011 R2

2/16

Contents

1 Overview...............................................................................................................................3

1.1 Introduction to Call Detail Records ...................................................................................... 3

1.2 CDR file format ....................................................................................................................... 3

2 Call Scenarios ......................................................................................................................5

2.1 CDR for an internal call ......................................................................................................... 6

2.2 CDR for an external call over a SwyxLink ........................................................................... 7

2.3 CDR for an external call over a Gateway ............................................................................. 9

2.4 CDR for a call with an involved script ................................................................................ 10

2.5 CDRs during a call transfer ................................................................................................. 12

2.6 CDRs for a sequential group call ......................................................................................... 13

3 Calculation of charging information ...............................................................................14

3.1 Advice of Charge formats..................................................................................................... 15

3.2 AOC in charging units .......................................................................................................... 15

3.3 Advice of charge in currency units ...................................................................................... 15

3.4 Accuracy ................................................................................................................................ 15

3.5 Charging information in Sub-PBXes or ISDN devices ...................................................... 15

3.6 Charging information via SwyxLinks ................................................................................. 16


3/16

1 Overview

1.1 Introduction to Call Detail Records

A Call Detail Record or short CDR is a collection of technical details about a specific call. Such records can

be used to observe the relevant statutory provisions relating to data protection, especially, if you are differen-

tiating between private and business calls. Additionally CDRs are used to generate call statistics for further

reporting, e.g. in call center scenarios.

CDRs can be configured over the server properties under the “Call Detail Records” tab. Among other things it

is possible to configure whether CDRs should be written at all and choose the location where CDRs should be

saved. One option is to save the CDRs into a text file another is to save them into a database. Further options

define how external numbers appear in the text file or database.

1.2 CDR file format

The following table shows an overview of all elements being part of a CDR. Each row of the table describes a

CDR entry with a detailed description.

Name Description

CallId Identification for a call. Each call (each CDR) has a unique number.

OriginationNumber Call originator’s number. For internal calls this is the number the client has specified during call establishment. For external calls via gateway and via link this is the originator’s number in canonical form.

OriginationName Call originator’s name. SwyxServer tries to get the name corresponding to the number by searching for: The client defined name, the SwyxWare user name or the SwyxWare personal/global phonebook name.

CalledNumber Called party number. This is the originally dialed number, even if the call is redirected or picked up by someone else.

CalledName Called party name. SwyxServer tries to determine the name in the same way as for “OriginationName”.

DestinationNumber Number of client who accepted the call. For non-picked-up and non-redirected calls this is the same as “CalledNumber”. Otherwise it de-fines the person who accepted the call.

DestinationName Name corresponding to destination name. SwyxServer tries to deter-mine the name in the same way as for “OriginationName”.

StartDate Start date of the call. This defines the date (dd, MM, yyyy) when Swyx-Server received the call from the client.

StartTime Start date of the call. This defines the time (hh, mm, ss) when Swyx-Server received the call from the client.

ScriptConnectDate Date when a call routing script accepted the call (only incoming calls).

ScriptConnectTime Time when a call routing script accepted the call (only incoming calls).

DeliveredDate Date when a call routing script delivered the call, i.e. when the Con-nectTo() function is called (only incoming calls)1.

DeliveredTime Time when a call routing script delivered the call, i.e. when the Con-nectTo() function is called (only incoming calls)1.

1 SwyxServer applies a CRS to every incoming call. The server default script will be used, if no user defined scripts have been found.


4/16

ConnectDate Date when the called destination accepted the call.

ConnectTime Time when the called destination accepted the call.

EndDate The date when the call was terminated.

EndTime The time when the call was terminated.

Currency Currency of charges. If AOC is “1” and PSTN has signaled charging information with curren-cy, this column contains this currency. If AOC is “1” and PSTN hasn’t signaled charging information this value is the charging unit currency configured within SwyxWare Administra-tion.

Costs Cost of a call. If AOC is “1” and PSTN has signaled complete charging information in currency units, this column contains these signaled charges. If “AOC is “1” and PSTN has signaled charging units only, this column contains the calculated charges as configured within SwyxWare Admin-istration. The value’s decimal separator is the SwyxWare service accounts de-fault decimal separator.

State State of a call Call was terminated…

Initialized …without being in alerting state.

Alerting …whilst being alerted at the destination.

Connected …whilst being connected at the destination.

ConnectedToScript …whilst being connected to a script.

Transferred …whilst being connected after a call transfer.

OnHold …while begin on hold.

PublicAccessPrefix The public access prefix dialed (optional).

LCRProvider This field remains empty.

ProjectNumber The project number dialed (optional).

AOC “1”: Advice of charge received from PSTN. “0”: Costs are calculated by the least cost routing module.

OriginationDevice Device which initiated the call. This is the SwyxGate name for incoming PSTN calls, the link name if call was routed via a link and empty other-wise. Note that SwyxWare Administration may show “(call routing)” during a call, when a call routing script executes a ConnectTo() func-tion.

DestinationDevice Destination device where the call is targeted at. For calls into PSTN this is the SwyxGate used. For external calls to another site this is the name of the link used to route the call. Contains “(call routing)” if the call is accepted by a user’s call routing script, e.g. to play or record a message.

TransferredByNumber Number of user who transferred the call.

TransferredByName Name of user who transferred the call. Empty if call not participated in a call transfer.

TransferredCallId1 CallId of the first participating call in case of a call transfer. TransferredCallId2 CallId of the second participating call in case of a call transfer.

TransferredToCallId Describes that this call has been transferred to the specified CallId.

TransferDate Date of call transfer. Valid for calls which have been transferred.

TransferTime Time of call transfer. Valid for calls which have been transferred.

DisconnectReason DisconnetReason Description

Busy Destination busy.

Reject Destination rejected the call.

NoAnswer Destination did not answer.


5/16

TooLate Another (not the called) device accepted

the call.

UnknownNumber An unknown number was called.

Unreachable

DirectCallImpossible

Destination unreachable.

The Intercom connection could not be

established.

NetworkCongestion PSTN network congestion.

BadFormatAddress

ProceedWithDestinationScript

Address format incorrect.

The call has been forwarded to the call

routing script of another subscriber.

CallRoutingFailed

CallIgnored

Call routing failed, e.g. the call routing

script could not be started.

The call has been ignored by the call

routing script (e.g. if there are several

ISDN devices connected)

PermissionDenied No sufficient permission for the call.

CallDisconnected

CallDeflected

Normal call disconnects.

The call has been manually transferred

without accepting to another subscriber

or a Voicemail.

IncompatibleDestination

SecurityNegotiationFailed

Originator and destination are not com-

patible, e.g. no matching voice codecs.

Caller and destination have incompati-

ble encryption settings (e.g “encryption

mandatory” – “no encryption”)

NumberChanged Destination number in PSTN has

changed.

NoChannelAvailable No SwyxWare channel available.

OriginatorDisconnected Call originator disconnected the call.

CallTransferred

DivertToCallerImpossible

Call has been transferred, Trans-

ferredToCalId links to the resulting

CDR, TransferDate/Time contains the

time when the transfer was initiated.

A Caller cannot divert a call to himself.

SwyxServer handles Call Details Records by means of CDR objects which are created, updated, written and

deleted during a call. CDR handling for different call types is explained in detail in the following sections.

These sections show several CDRs as tables. Empty CDR columns may be omitted for brevity. CDR columns

which are not relevant for the specific scenario may be omitted as well.

2 Call Scenarios The next section focuses on common call scenarios. Every scenario describes the CDR from its creation to its

final state with additional comments to make it easy to follow each step. The following graphic shows the set-

up of the call scenarios with all involved users, servers, gateways and SwyxLinks:


6/16

The setup comprised two SwyxWare servers called SwyxWareA and SwyxWareB, which are connected over

a SwyxLink named SwyxLinkAB. The SwyxWareA has three registered users: AliceA, BobA and CindyA.

The SwyxWareB has one registered user: BobB. The upper suffix in the user names indicates the membership

of this user of the corresponding SwyxWare. DanE is an external user which can be called over the PSTN

with the SwyxGatePSTN. The first scenario is an internal call.

2.1 CDR for an internal call

Consider the following scenario: User AliceA with internal number 100 calls user BobA with internal number

200.

1. AliceA picks up the phone and starts to dial 200. Then the temporary CDR looks like the following:

CallID 1

OriginationNumber “100”

OriginationName “AliceA”

StartDate “30.05.2012”

StartTime “11:11:11”

State “Initialized”

2. If SwyxServer has resolved the dialed number 200 of BobA and is alerting the call, the CDR object is

updated to:

CallID 1



CalledNumber “200”

CalledName “BobA”

DestinationNumber “200”

DestinationName “BobA”



DeliveredDate “30.05.2012”

DeliveredTime “11:11:12”

State “Alerting”

3. If BobA accepts the call, the CDR is updated to:


7/16

CallID 1











ConnectedDate “30.05.2012”

ConnectedTime “11:11:16”

State “Connected”

4. After AliceA disconnects the call to BobA the CDR is updated again and written into the CDR file or

database.

CallID 1











ConnectedDate “30.05.2012”


EndDate “30.05.2012”

EndTime “11:12:00”


DisconnetReason “OriginatorDisconnected”

2.2 CDR for an external call over a SwyxLink

Consider the following scenario: AliceA with internal number 100 and public number +492315666100 calls

BobB with internal number 201 and public number +492314777201 over a SwyxLink named SwyxLinkAB.

The following CDR represents the update flow of server A.

1. AliceA dials the public number +492314777201 of BobB:

CallId 1

OriginationNumber “+492315666100”






8/16


updated to:

CallID 1



CalledNumber “+492314777201”

CalledName “BobB”

DestinationNumber “+492314777201”

DestinationName “BobB”






PublicAccessPrefix “0”

DestinationDevice “SwyxLinkAB”

3. If BobA accepts the call, the CDR is updated to:

CallID 1











ConnectDate “31.05.2012”

ConnectTime “12:00:06”




4. BobB terminates the call and the CDR is updated to:

CallID 1













EndDate “31.05.2012”


9/16

EndTime “12:00:45”




DisconnectReason “CallDisconnected”

It is important to mention that in case AliceA dials the internal number 201 of BobB the final CDR entry

would be:

CallID 1













EndDate “31.05.2012”

EndTime “12:00:45”





Further it is worth to mention, that the CDR on server B hasn’t set a destination device. Instead the origination

device is set to “SwyxLinkAB”.

2.3 CDR for an external call over a Gateway

Consider the following scenario: AliceA with internal number 100 and public number +492314777265 calls

an external user DanE with public number +49231123456 over a gateway named SwyxGatePSTN. DanE ac-

cepts the call and AliceA terminates it.

As this scenario is similar to the previous one, we show directly the final stage of the CDR:

CallID 1




CalledName “DanE”


DestinationName “DanE”







EndDate “31.05.2012”


10/16

EndTime “12:00:45”



DestinationDevice “SwyxGatePSTN”


It is only possible to set the called name and destination name, when the public number of DanE is known.

This means a global or personal phonebook entry for the called number exists.

2.4 CDR for a call with an involved script

Consider the following example: BobA with internal number has a call routing script which accepts the call,

plays a message and tries to deliver the call to his internal client first. If that fails, the script finally tries to

route the call to user CindyA with internal number 300.

1. AliceA picks up the phone and starts to dial 200. Then the temporary CDR looks like the following:

CallId 1







updated to:

CallId 1







ScriptConnectDate “30.05.2012”

ScriptConnectTime “12:11:15”


3. After playing the message, the script reaches a “Connect to original destination” instruction. The

SwyxServer sets the “DeliveredDate” and “DeliveredTime”:

CallId 1













11/16

4. The script continues and tries to deliver the call to CindyA. The DeliveredDate and DeliveredTime

are updated. AliceA remains connected to the script.

CallId 1












5. CindyA accepts the call. The SwyxServer updates the DestinationNumber and DestinationName of

the CDR.

CallId 1






DestinationName “CindyA”










6. AliceA terminates the call.

CallId 1














12/16



EndDate “30.05.2012”

EndTime “12:11:59”


DisconnectReason “OriginatorDisconnected”

2.5 CDRs during a call transfer

1. Consider the following scenario: BobA has a call on hold to AliceA and an active call to CindyA,

which means BobA and CindyA are currently speaking. BobA has initiated both calls. In this state the

CDRs look like the following:

CDR 1 CDR 2

CallID 1 CallID 2

OriginationNumber “200” OriginationNumber “200”

OriginationName “BobA” OriginationName “BobA”

CalledNumber “100” CalledNumber “300”

CalledName “AliceA” CalledName “CindyA”

DestinationNumber “100” DestinationNumber “300”

DestinationName “AliceA” DestinationName “CindyA”

StartTime “15:00:00” StartTime “15:06:00”

ConnectedTime “15:00:05” ConnectedTime “15:06:05”

State “On Hold” State “Connected”

2. After BobA initiated a call transfer: BobA is disconnected. AliceA and CindyA are connected. The

updated CDRs from the initial call from BobA to AliceA and from BobA to Cindy A are:

CDR 1 CDR 2

CallId 1 CallId 2

OriginationNumber “200” OriginationNumber “200”

OriginationName “BobA” OriginationName “BobA”

CalledNumber “100” CalledNumber “300”

CalledName “AliceA” CalledName “CindyA”

DestinationNumber “100” DestinationNumber “300”

DestinationName “AliceA” DestinationName “CindyA”

StartTime “15:00:00” StartTime “15:06:00”

ConnectedTime “15:00:05” ConnectedTime “15:06:05”

State “Transferred” State “Transferred”

TransferredToCallId 3 TransferredToCallId 3

TransferDate “30.05.2012” TransferDate “30.05.2012”

TransferTime “15:06:30” TransferTime “15:06:30”

DisconnectReason “CallTransferred” DisconnectReason “CallTransferred”

3. The new CDR for the call from AliceA to CindyA is:

CDR3

CallId 3




CalledName “CindyA”



13/16





TransferredByNumber “200”

TransferredByName “BobA”

TransferredCallId1 2

TransferredCallId2 1

4. As long as AliceA and CindyA speak, all three CDR objects remain in memory. If the call is discon-

nected (in this case by Cindy A) all three CDRs are written into the CDR file or database:

CDR 1 CDR 2 CDR 3 CallId 1 CallId 2 CallId 3

OriginationNumber “200” OriginationNumber “200” OriginationNumber “100”

OriginationName “BobA” OriginationName “BobA” OriginationName “AliceA”

CalledNumber “100” CalledNumber “300” CalledNumber “300”

CalledName “AliceA” CalledName “CindyA” CalledName “CindyA”

DestinationNumber “100” DestinationNumber “300” DestinationNumber “300”

DestinationName “AliceA” DestinationName “CindyA” DestinationName “CindyA”

StartTime “15:00:00” StartTime “15:06:00” StartTime “15:06:30”

ConnectedTime “15:00:05” ConnectedTime “15:06:05” ConnectedTime “15:06:30”

EndTime “15:06:30” EndTime “15:06:30” EndTime “15:07:00”

State “Transferred” State “Transferred” State “Connected”

TranferredByNumber TranferredByNumber TranferredByNumber “200”

TranferredByName TranferredByName TranferredByName “BobA”

TransferredCallId1 TransferredCallId1 TransferredCallId1 2

TransferredCallId2 TransferredCallId2 TransferredCallId2 1

TransferredToCallId 3 TransferredToCallId 3 TransferredToCallId

TransferDate “30.05.2012” TransferDate “30.05.2012” TransferDate

TransferTime “15:06:30” TransferTime “15:06:30” TransferTime

DisconnectReason “CallTransferred” DisconnectReason “CallTransferred” DisconnectReason “CallDisconnected”

5. It is necessary to keep all three CDR objects for the complete call duration to be able to count call

costs correctly. Having only CDR3 after the transfer would lead to several problems: Call costs may

stem from both sides and each charging event contains the cumulative costs for the call so far. In

countries without charging information from PSTN, charges have to be calculated by analyzing the

call duration and destination. This would be impossible with CDR3 only.

2.6 CDRs for a sequential group call

1. Consider the following scenario: Sequential group “SequentialGroupA” has internal number 400 and

two members: BobA with internal number 200 and CindyA with internal number 300. AliceA calls

SequentialGroupA. The initial CDR is:

CallId 1






2. If SwyxServer has resolved the dialed number 400 of SequentialGroupA and is alerting the call at

BobA, the CDR object is updated to:

CallID 1


14/16




CalledName “SequentialGroupA”






3. BobA doesn’t accept the call, so that the device of CindyA is alerting. CindyA accepts the call:

CallID 1












ConectTime “10:00:15”


4. CindyA terminates call:

CallID 1













EndDate “31.05.2012”

EndTime “10:00:30”



3 Calculation of charging information

This section describes how SwyxWare recognizes charging informations sent via ISDN, processes them and

how they are signaled into Sub-PBXes or ISDN devices connected to SwyxWare. Additionally it explains

how charging informations are forwarded via SwyxLinks.


15/16

3.1 Advice of Charge formats

Charging information (AOC-Advice of Charge) is sent in three different formats:

- AOC-D (AOC-During the call): Describes the charging information sent during a call.

- AOC-E (AOC-At the End of the call): Describes charging information sent at the end of the call.

- AOC-S (AOC-At call Set-up time): Describes charging information sent before and during the set-up

time of the call. This leads to more detailed information.

Currently SwyxWare only supports AOC-D and AOC-E. The type in which the charging information is sent

depends on the provider. Some providers just send them as information elements (IE), other providers send

charging information as display information elements (Display-IE). The SwyxGate is capable to interpret such

display information elements and allows additional adjustments via the export settings of the ISDN port. The

option is named “ChargingFormat”. If a currency value, for example “Fr.”, is set, the charging value will fol-

low. To get detailed information about the charging information format, contact your ISDN provider.

3.2 AOC in charging units

This type of charging information contains a number of charging units. It is the type of AOC the German Tel-

ekom usually sends. To get a display on clients or in the CDRs as currency value, SwyxServer needs to know

how much one charging unit costs. This can be configured within SwyxWare Administration. Open Swyx-

Server properties and select the "Charges" property page to set the charging unit value. Changing this value

has no influence on past calls. The new value of the charging unit will be applied only to the subsequent calls.

Note that these settings are used only for this type of AOC. They are ignored for AOC in currency units.

3.3 AOC in currency units

This type of charging information contains the number of charging units, the value of one unit and the curren-

cy. SwyxServer uses this information to generate the charging display for the clients and CDRs. Usually

Swiss Telecom sends this type of AOC.

3.4 Accuracy

The accuracy of charging information depends on the values your ISDN provider has sent. SwyxServer’s de-

fault is the German Telekom's common ISDN rate. If you have any special rate for your ISDN line SwyxWare

cannot calculate correct values. The rate can be configured via the SwyxWare Administration under the

SwyxServer properties in the Charges tab. Here the rate can be set by manipulating the currency and the cost

per charging unit. Nevertheless, no provider will usually guarantee that charging information signaled via

ISDN would be 100% accurate.

3.5 Charging information in Sub-PBXes or ISDN devices

Charging information will be signaled to another PBX connected to SwyxWare as Sub-PBX or an ISDN de-

vice, i.e. with the ISDN board operating in NT-mode and SwyxWare line configuration set to "ISDN line to

sub-PBX or ISDN device". SwyxWare sends complete AOC-D information elements on the D-channel if such

elements are received from ISDN provider or charging unit settings are configured (for further information

see the SwyxServer manual section 4.4.13 in chapter “The Global Configuration of SwyxServer”).

For PBXes or ISDN devices which cannot handle AOC-D IEs, SwyxGate can be configured to send "display"

information elements instead (Display IE). The value of the DisplayFormat can be defined in the export set-

tings of the ISND port. A printf formatting statement, such as "%s %1.2f", which results in something like

"EUR 1, 23". “%s” is replaced by the currency; “%1.2f” displays the value with one or more digits before the


16/16

decimal separator and exactly two digits afterwards. Note that you cannot change the order. The value “%s”

always has to stay before “%f”. If this value is set, charging information will be always signaled on this line as

"Display" IE. If this value is empty or not present (default) charging information will be signaled on this line

as AOC-D IE.

3.6 Charging information via SwyxLinks

SwyxServer will forward charging information to other sites via a SwyxLink. If a client A on site A dials a

number which is routed via a SwyxLink to site B and a SwyxGate GB on site B into B's PSTN, the charging

information received from SwyxGate GB will be forwarded over the SwyxLink back to client A1.

Date post:	05-Jun-2018
Category:	Documents
Upload:	lamthuy
View:	222 times
Download:	1 times

CDR Specification SwyxServer 2011 R2 - swyxdownload.com€¦ · CDR Specification SwyxServer 2011...

Documents