Who hung up first the call?
This question sometimes arises in companies that handle calls, and, for example, there are some complaints from customers that employee of your company, not listening to them, hang up. If you have a modern call center, it probably has the required report. But if such a report is available, then it will contain the necessary information only if the call was not transferred outside the call center. Usually, the call center does not have information on calls that have been transferred from it, for example, to company managers. If you need to have information on who first hung up on all calls and you are using Cisco Unified Communications Manager (CUCM) as your telephone system, we can suggest using Tariscope, which will allow you to get the information you need.
Tariscope system receives CDR and CMR from CUCM and allows you to analyze them in the views for calls.
To have information on who completed the call first, you need to specify in the Tariscope settings for CUCM that all CDR fields are saved, as shown in Figure 1.
Figure 1
It should be borne in mind that this will require additional disk space and the Tariscope database can quickly reach the limit if you use Microsoft SQL Server Express edition.
The usual view for calls in Tariscope does not have a field for displaying information on who first hung up. There is only information on the call termination cause code. But the relevant information can be found in the detailed information, which contains all the CDR fields. If you are interested in data on some individual calls, select them in the view and click on the Record Details icon on the toolbar. If you are interested in information on all calls, then click on the Details of all records icon. The call detail view can be displayed instead of the main view, or in a separate view, depending on what the user chooses. An example of a record detail view is shown in Figure 2.
Figure 2
As with the usual call view, this view allows you to select only those fields of interest for analysis. To identify who hung up first, analyze the origCause_value and destCause_value fields, which are highlighted in the figure. A value of 0 in the fields means which the party originated the call (origCause_value) or the party that received the call (destCause_value) hung up first. In this case, in the opposite field contains the value of 16 for normal call termination. For more information on call termination cause codes, see the article.
But this view may not always be convenient, because it does not contain information about the subscriber, which is in the usual view for calls. In Tariscope it is possible to combine the necessary information on the view of call details with the usual view for calls. A typical call view contains a large set of fields that are not used for each of the phone systems that are supported. Let us, for example, display the name of Number A or Number B, depending on which subscriber with Number A or Number B initiated the end of the conversation, in the field intended for the project code.
To do this, you need to execute the following SQL query:
ALTER VIEW dbo.viCalls as SELECT C.ID, PBXID, NodeID, RecType, CallDirection, CallType, Originator, OriginatorAuxId, Terminator, TerminatorAuxId, CONVERT(datetime2(0), CallDateTime) AS CallDateTime, CallSeconds, AccessCode, OriginalDialnumber, Dialnumber, OriginalCLID, CLID, DNIS, RingTimeSeconds, HoldTimeSeconds, ReleaseCause, NoAnswerReasonID, AuthCode, (CASE WHEN CCM.destCause_value = 0 THEN (CASE WHEN CCM.origCause_value = 0 THEN '' ELSE 'Number A' END) ELSE (CASE WHEN CCM.origCause_value = 0 THEN 'Number B' ELSE '' END) END) as ProjectCode, FromAbonentID, FromAbonentPlaneID, ToAbonentID, ToAbonentPlaneID, FromTelephoneID, ToTelephoneID, CategoryID, ParentCallID, Tarif, Cost, Cost2, FromDepartmentID, FromDepartment, ToDepartmentID, ToDepartment, FromTelephone, ToTelephone, CONVERT(datetime2(0), EndDateTime) AS EndDateTime, CallDate, CONVERT(datetime2(0), CallTime) AS CallTime, CallDuration, CallDurationDays, RingTime, HoldTime, NumberA, NumberB, FromAbonent, ToAbonent, ISNULL(ISNULL(FromAbonent, FromTelephone), NumberA) AS CallingParty,
ISNULL(ISNULL(ToAbonent, ToTelephone), NumberB) AS CalledParty
FROM dbo.viCallsInternal AS C
left join dbo.CallsCCM as CCM on C.ID = CCM.CallID
GO
The part of the SQL query that was added is highlighted in red.
This query can be executed by selecting in the menu: Additional options → SQL- queries and placing the above query, as shown in Figure 3.
Figure 3
Click the Execute button.
That is all there is to it. Then create a new view or add the Project code field to an existing call view. After that, the view will be like as shown in Figure 4.
Figure 4
As you can see in this figure, information is displayed on the party of the call that first hung up. Since we used the Project Code field to display this information, the previous column heading remains. It can be changed to anything, for example, "Who hung up". To do this, in Windows Explorer, find the file that corresponds to this view. The view files are located in the folder: ...\SoftPI\Tariscope\Views\[user name]\,
where [user name] is the Tariscope use name who created this view.
In the files of the view for which you want to change the name of the Project Code column, find the tags of <DisplayName>Project code</ DisplayName> that are located after the tags of <FullName>ProjectCode</ FullName> and replace the value in the <DisplayName> tag, for example "Who hung up". After that, refresh the view and it will be as shown in Figure 5.
Figure 5
If necessary, you can create reports that will contain this information, but this is a topic for another article.
Tariscope and Cisco Unified Communications Manager
Benefits of Tariscope to collect and analyze CDR and CMR from CUCM
Control of call quality for CUCM using Tariscope
Tariscope configuration to use the restriction feature with CUCM
Creation of report forms for CUCM
- Details
Deep integration of Tariscope and 3CX
Tariscope, a call accounting and billing system by SoftPI, has a deep integration with 3CX.
Tariscope provides:
- a collection of CDR,
- receiving the real-time call data,
- an import of subscribers' parameters,
- Call Queue Information from 3CX
This allows you to have a complete picture of calls that were made through 3CX.
Tariscope can manage 3CX allowing you:
- to drop calls the cost of that is more than a specific value,
- to reject outgoing calls to the specific destinations,
- to reject outgoing calls from extensions that are absent in Tariscope,
- to reject outgoing calls without authorization codes,
- to reject calls from subscribers who have a balance less than a specific value.
This will allow you to control the budget for phone calls and prevent fraud.
All other functions of Tariscope, see on the site.
Download and test Tariscope for free.
- Details
Processing CDR from CUCM in Tariscope
The Tariscope system (SoftPI) allows you to collect and process data about the calls made through different telephone systems, including a voice equipment of Cisco Systems, such as Cisco Unified Communications Manager (CUCM).
Contents
Benefits of Tariscope to analyse CDR from CUCM
CDR configuration in CUCM
Tariscope configuration to process CDR, CMR files
Data analysis
Control of the call quality
Creation of specific report form
Telephone budget management
Testing and purchase of Tariscope
References
Benefits of Tariscope to analyse CDR from CUCM
You can find benefits of Tariscope to analyse CDR from CUCM in the article.
CDR configuration in CUCM
When Cisco Unified Communications Manager places or receives a call, the system generates a CDR record when the call terminates. The system writes the CDR to a flat file (text file) [1].
CDR file has the following filename format:
tag_clusterId_nodeId_datetime_seqNumber where:
- tag – Identifies the type of file, either CDR or CMR (Call Management Record).
- clusterId – Identifies the cluster or server where the Cisco Unified Communications Manager database resides.
- nodeId – Identifies the node.
- datetime - Indicates UTC time when the file was created. The yyyymmddhhmm format is used.
- seqNumber – Specifies the sequence number of the file.
Here are some examples of such file names:
cdr_StandAloneCluster_01_201409111456_55
cmr_StandAloneCluster_01_201409111456_237
CUCM can send CDR files to up to three billing servers via FTP/SFTP. The CDR Repository Manager service executes this function. How to configure general parameters of CDR Repository Manager you can find in the Section "CDR Repository Manager → Set up general parameters" [2].
To set up sending of CDR files to a specific billing server, perform the steps described in the Section "CDR Repository Manager → Set up application billing server" [2].
Next, you must configure CDR parameters. To do this, open Cisco Unified Communications Manager Administration and choose System → Enterprise Parameters.
The CDR File Time Interval parameter specifies the time interval for collecting CDR data. For example, if this value is set to 1, each file will contain 1 minute of CDR data (CDRs and CMRs, if enabled). The external billing server and CAR database will not receive the data in each file until the interval has expired, so consider how quickly you want access to the CDR data when you decide what interval to set for this parameter. For example, setting this parameter to 60 means that each file will contain 60 minutes worth of data, but that data will not be available until the 60-minute period has elapsed, and the records are written to the CAR database and the CDR files are sent to the configured billing servers. The default value equals 1. The minimum value specifies 1, and the maximum value specifies 1440. [2]
And finally, you should configure CDR service. To do this, open Cisco Unified Communications Manager Administration and choose System → Service Parameters [3]. Choose the Advanced button to display the complete list of Service Parameters. The following list of service parameters can affect CDR/CMR records:
• System Parameters
- CDR Enabled Flag - This parameter determines whether CDRs are generated. Valid values specify True (CDRs are generated) or False (CDRs are not generated). For this required field, the default value specifies False. Enable this parameter on all servers.
- CDR Log Calls With Zero Duration Flag - This parameter enables or disables the logging of CDRs for calls which were never connected or which lasted less than 1 second. Cisco Unified Communications Manager logs unsuccessful calls (calls that result in reorder, such as might occur because of a forwarding directive failure or calls that attempt to go through a busy trunk) regardless of this flag setting. This represents a required field. The default value specifies False.
• Clusterwide Parameters (Device - General)
- Call Diagnostics Enabled - This parameter determines whether the system generates call management records (CMRs), also called diagnostic records. Valid values specify Disabled (do not generate CMRs), Enabled Only When CDR Enabled Flag is True (generate CMRs only when the CDR Enabled Flag service parameter is set to True), or Enabled Regardless of CDR Enabled Flag (generates CMRs without regard to the setting in the CDR Enabled Flag service parameter). This represents a required field. The default value specifies Disabled.
- Display FAC in CDR - This parameter determines whether the Forced Authorization Code (FAC) that is associated with the call displays in the CDR. Valid values specify True (display authorization code in CDRs) or False (do not display authorization code in CDRs) for this required field. The default value specifies False.
- Show Line Group Member DN in finalCalledPartyNumber CDR Field - This parameter determines whether the finalCalledPartyNumber field in CDRs shows the directory number (DN) of the line group member who answered the call or the hunt pilot DN. V alid values specify True (the finalCalledPartyNumber in CDRs will show the DN of the phone that answered the call) or False (the finalCalledPartyNumber in CDRs will show the hunt pilot DN). This parameter applies only to basic calls that are routed through a hunt list without feature interaction such as transfer, conference, call park, and so on. If a feature is involved in the call, the hunt pilot DN will show in the finalCalledPartyNumber field regardless of the setting in this parameter. This parameter does not apply to Cisco Unified Communications Manager Attendant Console. The default value for this required field specifies False.
• Clusterwide Parameters (Device - Phone)
- Add Incoming Number Prefix to CDR - This parameter determines whether Cisco Unified Communications Manager adds the incoming prefix (as specified in the National Number Prefix, International Number Prefix, Subscriber Number Prefix, and Unknown Number Prefix service parameters) to the calling party number in the CDRs for that call. If the prefix is applied on the inbound side of that call, it always will be added to the calling party number in the CDRs for the call, even if this parameter is set to False. If the prefix is applied on the outbound side, the prefix will be added to the calling party number in the CDR(s) for that call, only if this parameter is set to True. If the destination of the call is a gateway, Cisco Unified Communications Manager will not add the prefix to the CDRs even if this parameter is enabled. This parameter applies cluster wide. The default value for this required field specifies False.
Tariscope configuration to process CDR and CMR files
Below we consider only the specific Tariscope configuration to work with CUCM. The description of all other settings you can find in the "Tariscope 4.5. Administrator's Guide".
You can configure Tariscope after the first start using the Equipment creation wizard or you can use the wizard at any other time by selecting in the Tariscope menu: Communications nodes → Equipment creation wizard. At the same time you can set the telephone system settings selecting the desired telecommunications node → Equipment → Equipment management. To add CUCM, click on the Add icon on the toolbar. In the appeared New eqiupment window, enter a telephone system name, for example, CUCM. The Edit CUCM page is displayed. The description of the page, see in the article. In the Equipment list, select the Cisco CallManager item and click on the Advanced settings button located on the left side of the list. The Advanced settings window appears as shown in Figure 1.
Figure 1
CDR format of CUCM contains hundreds of different fields. Some of the fields are not used to call rating. They are complementary. Therefore, by default, only those fields, which are used for call rating, are processed, and saved in the Tariscope database. In order to all fields of CDR file are processed and saved in the Tariscope database, turn on the Save all fields switch. It should be borne in mind that the storage of all fields requires more disk space.
To correctly detect the internal and external telephone numbers, you should use a numbering plan. To do this, turn on the Use numbering plan for internal numbers detection switch.
If you use a numbering plan, but you do not want to handle calls that do not belong to the numbering plan, turn on the Skip calls outside the numbering plan switch. This saves the disk space and increases the productivity.
If you do not want to process information about unanswered calls, turn on the Ignore unanswered calls switch.
To account the authorization codes, turn on the Save prefix as auth code if matching pattern switch, and enter a pattern, which will be used to define the authorization codes.
If you have more than one partition in CUCM, turn on the Enable partitions switch. This allows to correctly define a subscriber who made the call.
If you need to use the outpuledCalledPartyNumber field from CDR as the dialed number, turn on the Using outpuledCalledPartyNumber as dialed number switch.
Click Save to keep settings.
If you use partitions, and extension numbers are not unique in CUCM, you must specify the partition along with the extension number for each subscriber. To do this, from the Subscribers page, choose the desired subscriber and click on the Edit icon on the toolbar. The page with the subscriber data is opened. Click on the button located near the Auxiliary identifiers box. The Auxiliary identifiers table appears. Click on the Add icon on the toolbar. The New auxiliary identifier window appears. An example of the window is shown in Figure 2.
Figure 2
In the Auxiliary identifier textbox, enter the extension number and the partition using the folowing format: [extension number]@[partition]. For example: 1234@old_city, where 1234 is an extension number and old_city is a partition. Click Save.
This setting allows Tariscope to correctly detect a subscriber when it processes CDR data.
The Tariscope Observer services are used to collect CDR data from telephone systems in the Tariscope system. You should create a new Tariscope Observer profile for CUCM. In the Tariscope menu, select Data Collection/Observer → Observer management. The Data Collection/Observer page apeears. Click on the Add icon on the toolbar and in the appeared New Observer window, enter a service name in the Name box. For example, CUCM Observer. Click Save. Then, click Settings. The Tariscope Observer configuration page appears, an example of which is shown Figure 3.
Figure 3
For CUCM, you can select one of the following sources depending on which source you want to use:
- FTP server.
- SFTP server.
- Folders/file.
To use the FTP server included in Tariscope, in the window shown in Figure 2, in the Data source list, select the FTP server item and click on the Data source configuration button. The Data source configuration window appears.
In the Port box, type IP port of the FTP server. This port should be used in an FTP client of CUCM. By default: 21.
In the Login box, type a login name. In the Password box, type a password, which the FTP client will be used to connect to the FTP server.
In the Local folder box, type the path to the folder where the FTP client will write CDR files.
If necessary, in the File mask box, specify a template, which is used to select the required files in a folder. The default pattern is "*", which provides a choice of all the files in the folder.
If there is no need to keep the downloaded files in the folder, turn on the Don't store the downloaded files switch.
To keep the settings, click Done.
When you plan to use the SFTP server in Tariscope, select the SFTP server item and click on the Data source configuration button. The Data source configuration window appears. All settings of the window are the same as for the FTP server.
When you plan to use a third-party FTP or SFTP server, in the Data source list, select the Folder/file item and click on the Data source configuration button. The Data source configuration window appears. The description of the window, see in the article.
Strat the Tariscope Observer. It will begin to collect and process CDR data from CUCM.
Data analysis
The main Tariscope purpose is an analysis of call information, creating reports on calls, billing, etc. Since the processed data from all types of telephone systems in Tariscope are reduced to one view, there are no features on filtering, sorting, reporting for CUCM in comparison with other types of telephone systems.
These features are performed in the calls views. To create a call view, in the Tariscope menu, select Views → Views list. For a description of creating a new view for calls, see the article.
An example of the call view of the Tariscope program with the processed data from the CUCM is shown in Figure 4.
Figure 4
The Tariscope view allows you to set a list of the desired fields and their order, to filter data using different ways, to group data on the specific fields, etc.
Some calls may consist of a few records, for example, for call transfer. In this case, if you set the focus on one of these records and click on the Show related records icon on the toolbar (Figure 5), Tariscope select all rows which are related to this call.
Figure 5
This feature makes easy to analyze calls consisted of several stages.
In addition, to CUCM as well as for several other PBXs, which have a wide range of CDR fields, there is the ability to handle all CDR fields and save them in the Tariscope database. It can be useful if you need to analyze some CDR fields from CUCM which are absent in the usual call view. In this case, select the desired rows in the call view and click on the Records details icon on the toolbar. The menu appears that contains two items:
- in current window. The detailed records are displayed on this page.
- in a new window. The detailed records are displayed on the new tab of the browser.
An example of the view with the detailed records in shown in Figure 6.
Figure 6
The view contains the toolbar. If you click on the Header on the left icon, the table will change the form and it will be as shown in Figure 7.
Figure 7
The view allows you also to search, filter data, and export the table in the external file (PDF, Excel, Text, CSV). If you need, you can create a report form which will contain only the required fields for the desired period or for other filter conditions. The Tariscope Tasks service can automatically generate this report by schedule.
If you want to analyze the telephone traffic, you should select the View list, select the desired veiw or views, and click on the Traffic calculation icon on the toolbar. The Traffic calculation window appears where you should specify views, data of which will use for calculation, gateways, period, and beginning of the period. As a result, you will get a chart that displays the traffic. An example of the page is shown in Figure 8.
Figure 8
For a complete analysis of CDR data, we recommend to create the desired report form using Report Designer or Microsoft SQL Server Report Builder. How to create a specific report form for CUCM in the Report Designer you can find in the article.
Control of call quality
Tariscope can collect and processes Call Management Records (CMRs) that contain information about the quality of audio and video streams, and it can generate a number of reports with CMR data.
To learn more about this Tariscope feature, read the article.
Creation of report forms for CUCM
Tariscope allows users to create reports to analyze all the data contained in the CDR files. How do it you can find in the article.
Telephone budget management
Tariscope not only allows you to account all calls of each employee, department, customer, but it provides a full control over the expenditure of finance on telephone calls. Tariscope allows you to set a money or time limit on phone calls for each subscriber or a subscriber group. When the limit is exhausted, Tariscope sends commands to CUCM, which restricts, for example, long-distance calls until the end of the limit period. At the beginning of next limit period the restriction will be automatically cleared. Thus the company can clearly execute the planned costs on telephone calls, and if necessary, to reduce them. To use this ability, the Tariscope license must contains the restriction feature.
Testing and purchase of Tariscope
Download and try Tariscope with your CUCM. It is a free.
You can purchase Tariscope by a variety of ways:
- Contact directly to the SoftPI
- Contact to the company's partners in your country.
- Buy online from the page.
References
1. Call Detail Records Administration Guide for Cisco Unified Communications Manager, Release 12.5(1).
2. Cisco Unified Serviceability Administration Guide, Release 11.5(1).
3. Cisco Unified CDR Analysis and Reporting Administration Guide, Release 12.5(1).
Links
Download and test Tariscope
Benefits of Tariscope to collect and analyze CDR and CMR from CUCM
Control of call quality for CUCM using Tariscope
Tariscope configuration to use the restriction feature with CUCM
Creation of report forms for CUCM
- Details
Features of the Tariscope configuration to collect CDR from 3CX
Tariscope (SoftPI) allows you to collect, process and analyze the call information from different telephone systems including 3CX (3CX Phone System) of different versions. Tariscope provides a huge number of benefits to work with 3CX. You can see a list of the benefits on the page.
On the whole, the Tariscope configuration for 3CX is the same as for other PBXs and you can find out this in “Tariscope 4.6. Administration guide”.
We only consider the features of the configuration that are peculiar to 3CX.
Choice of 3CX in Tariscope. Configuration of main parameters
A choice of PBX type, from which Tariscope will collect and process CDR data, can be executed both a stage of the initial configuration and stage of the specific configuration.
If you perform the Tariscope initial configuration, you should choose the 3CX Phone System item in the Equipment list on the Step 3.
If you want to configure Tariscope independently, follow the steps in the article. Then, follow the steps in the article.
Connection to 3CX
The Tariscope Observer service is used to collect CDR data in the Tariscope system. You should create a new profile to collect data from 3CX. On the Tariscope Observer configuration page, in the list, click on the here link and select the 3CX item.
3CX can use three way to pass CDR in a billing system:
- A file in a folder. The file can contain all calls or it can be generated for each call.
- 3CX CDR service works as a TCP server.
- 3CX CDR service works as a TCP client.
For first option, Tariscope Observer select the Folder and file item in the Data source list. Then, follow the steps of the article.
For second option, Tariscope Observer select the TCP client item in the Data source list. Then, follow the steps of the article.
For third option, Tariscope Observer select the TCP server item in the Data source list. Then, follow the steps of the article.
Online monitoring of calls
Tariscope allows you to monitor calls in the real time. For this, you should have a Tariscope license with the restriction feature, select the Monitor active calls check box during the configuration, and execute the configuration as mentioned above.
Tariscope Observer has the Active calls page that allows you to monitor calls in the real time. An example of the Active calls page is shown in Figure 1.
Figure 1
The page displays calls that are executed at the current time or that have been completed less than one minute ago. Each call is presented in two lines for Outgoing and Incoming call legs in the table.
The table contains the following fields:
- Call ID. Displays a call identifier.
- ID. Displays an identifier of the call leg.
- Start time. Display date and time of call in the call leg.
- Direction. Displays a direction of the call leg. There are two types of directions: Outgoing and Incoming. An Outgoing direction is applied for each call leg, where the NumberA field shows the telephone number of the caller. An Incoming direction is applied for each call leg, where the NumberA field shows the telephone number of the called subscriber.
- Status. Displays a status of the call leg.
- NumberА. For internal calls, this field displays the phone number of calling subscriber for the Outgoing call leg and the phone number of called subscriber for the Incoming call leg. For external outgoing calls, this field shows the extension number of calling subscriber for the Outgoing call leg and the number of gateway in the Incoming call leg.
- NumberB. For internal calls, this field displays the phone number of called subscriber for the Outgoing call leg and the phone number of calling subscriber for the Incoming leg. For external outgoing calls, this field displays the dialed number for both call legs.
- Connect time. Displays the date and time of the connection of the call leg.
- Disconnect time. Displays the date and time of the disconnection of the call leg.
- Duration. Displays the current duration of the call in the call leg.
- Cost. Displays the current cost of the call.
- Subscriber. Displays a subscriber name from the Tariscope database.
- To place. Displays a city name, mobile operator or owner of a specific telephone number when the outgoing call is executed.
- Duration left. If a limit is set for the subscriber balance, this field displays how long the current call can be lasted.
A Tariscope user can customize the list of desired fields. To do this, right-click on the title of the table of Active calls. Menu appears as shown in Figure 2.
Figure 2
Select the desired fields.
Data of the Active calls table can be sorted by any field. This can be Duration, Cost, or To place. If necessary, the data in the table can be grouped on any field.
To quickly understand a call status, a specific font color is used:
- blue color is used when a call is in dialing status,
- green color is used when a call has been answered,
- gray color is used when a call was finished.
For a call, which has less than 10 seconds before the automatic disconnection will be executed, when a subscriber’s balance will reach the limit value, a red background is used. Remind that the automatic disconnection is possible, if the Tariscope license had been purchased with the restriction feature and you made the appropriate configuration of the software.
Tariscope configuration to use the restriction feature
The restriction feature allows the Tariscope administrator to set the restriction to the specific type of calls for a subscriber, group of subscribers, route or gateway. Any restriction can be set in the money or time duration. The restriction is set to the month, week or day. The specified type of calls is defined by a call category. See more information about the restriction feature on the page.
To configure Tariscope with restriction feature you should perform the following steps:
- Activate the restriction feature.
- Create categories that correspond to the specific call types, for which restrictions will be set.
- Specify the call categories for phone codes.
- Create restriction classes.
- Specify limits for subscribers.
- Specify a period of restriction action.
Restriction feature implementation
In the configuration tree of the Tariscope program, select the All nodes branch. The Tariscope program will be as shown in Figure 3.
Figure 3
In the Control expenses (limiting) list, select any value other than No control that corresponds to parameters of the license. To save changes, click on the Save icon on the toolbar.
Creation of categories
The categories are used to select a specific call types which you want to restrict. The categories are tied to particular telephone codes.
How to create a new category see in the article.
Assigning categories to telephone codes
To assign a category to a specific phone code, move to the Providers and rates configuration page → a specific provider → Outgoing or Incoming → Destination codes or Destinations table. Select the codes that should belong to a category. Using the feature of multiple replacement, set a desired category. Repeat these actions for other telephone codes for which you need to set another category of calls.
Creation of restriction classes
In the configuration tree of Tariscope, select All nodes → a desired node → Equipment items → a desired telephone system → Restriction classes. The Tariscope program will be as shown in Figure 4.
Figure 4
The following concepts are used for this configuration page.
Class of service (COS). This is an identifier that is used by a telephone system to determine rights to execute calls in different areas or countries. COS is passed to the restriction script, which uses it in the process of execution. The format and value of COS are depended on the type of PBX. COS is not used for 3CX Phone System. Don’t specify the parameter.
Call category. This is a parameter that is assigned to each call by Tariscope in accordance with the direction of the call. One of purposes of the categories is to define a type of telephone traffic, which should be considered to set the restrictions. A list of categories can be obtained from the Categories configuration page.
Restriction group. This is a set of rules, according to which a class of service is selected. A list of the restriction groups is common to all PBXs of a communication node. But the elements of the group and their corresponding classes of service are tied to a particular PBX. You must create at least two elements of the restriction group. For example, one element includes the class of service that permits phone calls, and another element that prohibits such calls. Groups of restrictions are tied to the subscribers.
The Restriction classes configuration page allows you to configure COS for each combination of available categories of calls. In the simplest case, each group of classes contains two elements: "everything is enabled" with a selection of All categories and "everything is disabled" when no categories were selected. If you want to restrict the various categories of calls individually, you need to create the elements of restriction group with all possible combinations of categories and corresponding COS. Tariscope automatically selects an element that is suitable for the current status of the subscriber restrictions, and pass it to the script.
You can assign any name for each group and element.
Setting of a limit for subscribers
In the configuration tree, select your telecommunications node → Subscribers. Select a desired subscriber for which you wish to set restrictions and click on the Edit icon on the toolbar. On the toolbar of the appeared window, click on the Details button. The window appears as shown in Figure 5.
Figure 5
Click on the Add button. The Category credit window appears as shown in Figure 6.
Figure 6
In the Category list, select a category for which you will set the restriction.
In the Restrict type list, select a desired restriction type: Money or time (Seconds).
In the Restriction class list, select a required class.
In the Credit box, specify a value of credit (limit) in time or money depending on the previous selection. In case of money, the credit is set in the main currency that was set in Tariscope. The time period is set in the seconds.
Click OK.
If you need to set restrictions for other call categories, repeat the above steps for these categories.
Repeat the above steps for other subscribers for which you need to set restrictions.
The action period of the restriction feature
The action period of the restriction feature is specified when configuring the Tariscope Observer service. In the configuration tree, select the Data collection/Observer branch → a service that collects CDR data from 3CX Phone System → Configuration. The window will be as shown in Figure 7.
Figure 7
Click on the Scripts button and in the Tariscope Observer scripts window, select the Subscriber COS change item (Figure 8).
Figure 8
In the Unrestricted interval list, select a desired interval. It is a period when a restriction can be set. This interval will apply after the first date of clearing restrictions.
The list contains the following options:
- every day,
- every week,
- every month,
- every year.
In the Next auto unrestricted date box, set the date when the next reset of the restrictions will be executed automatically. Click OK. Then, to save parameters of the Observer service, click on the Save icon on the toolbar (Figure 7).
Detailed description of some Tariscope features
Automatically addition of subscribers’ data from 3CX database
This feature allows to automatically create subscribers in the Tariscope database. At the beginning of a call, Tariscope checks the extension, from which call is made, in the Tariscope database. If the extension is absent, Tariscope downloads parameters of the subscriber from 3CX Phone System.
This feature greatly simplifies an administration by allowing the PBX administrator to automatically enter subscribers' data.
This feature cannot be used simultaneously with the feature of Drop calls from unknown extensions.
To implement this feature, in the 3CX parser configuration window (Figure 3.12.1.1), select the Monitor active calls check box and the Automatically create subscribers from 3CX database check box.
Synchronization of subscribers' data
The feature provides an automatic synchronization of subscribers' data of Tariscope database with appropriate data of 3CX Phone System. Tariscope synchronizes the following data: a subscriber name, extension, and Email address. At the beginning of each call, Tariscope verifies the parameters of the subscriber making the call with appropriate data of 3CX Phone System. If these data are somewhat different, Tariscope synchronizes its database with data of 3CX Phone System. The feature allows the administrator to change subscriber's data only in 3CX Phone System.
You can use the feature together with the feature of Automatically create subscribers from 3CX database.
To implement this feature in the 3CX parser configuration window (Figure 3.12.1.1), select the Monitor active calls check box and the Automatically synchronize a subscriber name, extension and email from 3CX database check box.
Disconnection of calls based on the account state
This feature can be used in the Tariscope Provider edition only. The feature works as follows. At the beginning of a call, Tariscope calculates a call duration when the account state will reach the specified value, for example, 0. As soon as this moment comes, Tariscope disconnects the call. All new attempts to execute calls that are rated will be dropped. But the subscriber can make calls to destinations that are not rated, for example, internal calls. After the subscriber replenishes the account state and this information appears in Tariscope database, Tariscope allows the subscriber to make calls.
To implement this feature:
- in the 3CX parser configuration window (Figure 3.12.1.1), select the Monitor active calls check box,
- in the main.xml file, set a value of 'true' in tags: <LimitSubscribersByBalance>true</LimitSubscribersByBalance>
- specify a value of customer balance when the feature will be applied in the tags: <BalanceThreshold>0</BalanceThreshold>
Disconnection of calls from unknown extension
The feature allows you to combat fraud. You can prohibit all calls made from extensions that are absent in the Tariscope database. To do this, in the 3CX parser configuration window (Figure 3.12.1.1), select the Monitor active calls check box and the Drop calls from unknown extensions check box.
This feature cannot be used simultaneously with the feature of Automatically addition of subscribers’ data from 3CX database.
Disconnection of long calls
You can set a threshold for call duration. If call duration reaches the threshold, Tariscope executes a disconnection of such call. To implement this feature:
- in the 3CX parser configuration window (Figure 3.12.1.1), select the Monitor active calls check box,
- specify a value of threshold (in seconds) for call duration in the tags: <DropCallDurationThreshold>0</DropCallDurationThreshold>
The value of 0 means that calls do not have a limit on the duration.
Disconnection of expensive calls
You can set a threshold for call cost. If call cost reaches the threshold, Tariscope executes a disconnection of such call. To implement this feature:
- in the 3CX parser configuration window (Figure 3.12.1.1), select the Monitor active calls check box,
- specify a value of threshold for call cost in the tags: <DropCallCostThreshold>0</DropCallCostThreshold>
The value of 0 means that calls do not have a limit on the cost.
Disconnection of calls on pattern
Tariscope allows you to disconnect calls that make to specific telephone numbers.
To implement this feature:
- in the 3CX parser configuration window (Figure 3.12.1.1), select the Monitor active calls check box,
- specify a template for telephone codes that should drop in the tags: <DropCallRulesNumberPattern>*</DropCallRulesNumberPattern>.
The value of '*' means that there are no prohibited telephone numbers.
- Details
Call Termination Cause Codes of CUCM, CME, and CUBE
Tariscope is a call accounting and billing system that provides many different features to analyze calls information. Tariscope is a Web application; therefore, it is available on a desktop PC, laptop, and smartphone.
Tariscope contains many features for analysis of call termination cause codes from Cisco Unified Communications Manager (CUCM), Cisco Call Manager Express (CME), and Cisco Unified Border Element (CUBE):
- The display of call termination cause codes in the calls views.
- The report generation on the call termination cause codes.
- The display information on the specific call termination cause codes on the Tariscope dashboard.
- Immediate sending of messages to the administrator by certain codes immediately after receiving CDR.
Let us consider these options.
The display of the codes in the calls views
The Tariscope views for calls provide the output of many CDR fields. There is the Release cause field among them. You can see an example of the view in Figure 1.
Figure 1
The Tariscope calls view allows a user:
- To select records with required codes.
- To sort information.
- To group data by the release cause.
- To get information on the original CDR data.
The user can select the desired records in the calls view and get the view that contains all original records of CDR. The example of the view is shown in Figure 2.
Figure 2
The Tariscope user can create the view that display calls information only for the specific call termination cause codes, for example, for today. An example of such settings is shown in Figure 3.
Figure 3
If you want to know how many calls made with each termination code type, you should apply the grouping in the view. Figure 4 shows the example of the grouping by the Release cause field. The view contains only two field, because it is enough to apply grouping. If you need, you can sort the table with the grouping data.
Figure 4
Any view can be exported to the external file. Supported the following file types:
- Excel.
- HTML.
- CSV.
- PDF.
The report generation
In addition to receiving a report by exporting a view, you can create a report that can contain both the text and graphical data. How to create the report with information on the call termination cause codes you can find in the article.
You can initialize the report generation manually or use the automatic scheduled report generation. In the latter case the Tariscope Tasks service is used. The service can generate reports by schedule and send it to the specific email addresses. And you will always be up to date on call termination codes.
Monitor the termination codes on the dashboard
Tariscope contains the dashboard that includes a large set of widgets. You can easily install a widget that, for example, will display information, for example, by completion codes 41 and 47 in the last minute. An example of the widget is shown in Figure 5.
Figure 5
In the widget, you can set a list of the fields that you wish.
Immediate sending of messages
If you need to get information about a call with the specific termination cause code immediately after Tariscope receives such call record, Tariscope help you to solve this task. You should create the script that will be executed after each call processing. The example of the similar script is described in the article. Let us know if you need our help in the script creation. You should bind the script to the New call event as shown in Figure 6.
Figure 6
Let us know if you have any other suggestions for analyzing call termination codes.
You can try Tariscope. It is a free. Download the Tariscope trial.
The tables of codes from the Cisco document are shown below.
Table 1. Call Termination Cause Codes
Code
|
Description
|
---|---|
0 | No error |
1 | Unallocated (unassigned) number |
2 | No route to specified transit network (national use) |
3 | No route to destination |
4 | Send special information tone |
5 | Misdialed trunk prefix (national use) |
6 | Channel unacceptable |
7 | Call awarded and being delivered in an established channel |
8 | Preemption |
9 | Preemption—circuit reserved for reuse |
16 | Normal call clearing |
17 | User busy |
18 | No user responding |
19 | No answer from user (user alerted) |
20 | Subscriber absent |
21 | Call rejected |
22 | Number changed |
26 | Non-selected user clearing |
27 | Destination out of order |
28 | Invalid number format (address incomplete) |
29 | Facility rejected |
30 | Response to STATUS ENQUIRY |
31 | Normal, unspecified |
34 | No circuit/channel available |
38 | Network out of order |
39 | Permanent frame mode connection out of service |
40 | Permanent frame mode connection operational |
41 | Temporary failure |
42 | Switching equipment congestion |
43 | Access information discarded |
44 | Requested circuit/channel not available |
46 | Precedence call blocked |
47 | Resource unavailable, unspecified |
49 | Quality of Service not available |
50 | Requested facility not subscribed |
53 | Service operation violated |
54 | Incoming calls barred |
55 | Incoming calls barred within Closed User Group (CUG) |
57 | Bearer capability not authorized |
58 | Bearer capability not presently available |
62 | Inconsistency in designated outgoing access information and subscriber class |
63 | Service or option not available, unspecified |
65 | Bearer capability not implemented |
66 | Channel type not implemented |
69 | Requested facility not implemented |
70 | Only restricted digital information bearer capability is available (national use) |
79 | Service or option not implemented, unspecified |
81 | Invalid call reference value |
82 | Identified channel does not exist |
83 | A suspended call exists, but this call identity does not |
84 | Call identity in use |
85 | No call suspended |
86 | Call having the requested call identity has been cleared |
87 | User not member of CUG (Closed User Group) |
88 | Incompatible destination |
90 | Destination number missing and DC not subscribed |
91 | Invalid transit network selection (national use) |
95 | Invalid message, unspecified |
96 | Mandatory information element is missing |
97 | Message type nonexistent or not implemented |
98 | Message is not compatible with the call state, or the message type is nonexistent or not implemented |
99 | An information element or parameter does not exist or is not implemented |
100 | Invalid information element contents |
101 | The message is not compatible with the call state |
102 | Call terminated when timer expired; a recovery routine executed to recover from the error |
103 | Parameter nonexistent or not implemented - passed on (national use) |
110 | Message with unrecognized parameter discarded |
111 | Protocol error, unspecified |
122 | Precedence Level Exceeded |
123 | Device not Preemptable |
125 | Out of bandwidth (Cisco specific) |
126 | Call split (Cisco specific) |
127 | Interworking, unspecified |
129 | Precedence out of bandwidth |
131 | Call Control Discovery PSTN Failover (Cisco specific) |
132 | IME QOS Fallback (Cisco specific) |
133 | PSTN Fallback locate Call Error (Cisco specific) |
134 | PSTN Fallback wait for DTMF Timeout (Cisco specific) |
135 | IME Failed Connection Timed out (Cisco specific) |
136 | IME Failed not enrolled (Cisco specific) |
137 | IME Failed socket error (Cisco specific) |
138 | IME Failed domain blacklisted (Cisco specific) |
139 | IME Failed prefix blacklisted (Cisco specific) |
140 | IME Failed expired ticket (Cisco specific) |
141 | IME Failed remote no matching route (Cisco specific) |
142 | IME Failed remote unregistered (Cisco specific) |
143 | IME Failed remote IME disabled (Cisco specific) |
144 | IME Failed remote invalid IME trunk URI (Cisco specific) |
145 | IME Failed remote URI not E164 (Cisco specific) |
146 | IME Failed remote called number not available (Cisco specific) |
147 | IME Failed Invalid Ticket (Cisco specific) |
148 | IME Failed unknown (Cisco specific) |
Table 2. Cisco-Specific Call Termination Cause Codes
Decimal Value Code
|
Hex
|
Description
|
---|---|---|
262144 | 0x40000 | Conference Full (was 124) |
393216 | 0x60000 | Call split (was 126) This code applies when a call terminates during a transfer operation because it was split off and terminated (was not part of the final transferred call). This code can help you to determine which calls terminated as part of a feature operation. |
458752 | 0x70000 | Conference drop any party/Conference drop last party (was 128) |
16777257 | 0x1000029 | CCM_SIP_400_BAD_REQUEST |
33554453 | 0x2000015 | CCM_SIP_401_UNAUTHORIZED |
50331669 | 0x3000015 | CCM_SIP_402_PAYMENT_REQUIRED |
67108885 | 0x4000015 | CCM_SIP_403_FORBIDDEN |
83886081 | 0x5000001 | CCM_SIP_404_NOT_FOUND |
100663359 | 0x600003F | CCM_SIP_405_METHOD_NOT_ALLOWED |
117440591 | 0x700004F | CCM_SIP_406_NOT_ACCEPTABLE |
134217749 | 0x8000015 | CCM_SIP_407_PROXY_AUTHENTICATION_REQUIRED |
150995046 | 0x9000066 | CCM_SIP_408_REQUEST_TIMEOUT |
184549398 | 0xB000016 | CCM_SIP__410_GONE |
201326719 | 0xC00007F | CCM_SIP_411_LENGTH_REQUIRED |
234881151 | 0xE00007F | CCM_SIP_413_REQUEST_ENTITY_TOO_LONG |
251658367 | 0xF00007F | CCM_SIP_414_REQUEST_URI_TOO_LONG |
268435535 | 0x1000004F | CCM_SIP_415_UNSUPPORTED_MEDIA_TYPE |
285212799 | 0x1100007F | CCM_SIP_416_UNSUPPORTED_URI_SCHEME |
83886207 | 0x1500007F | CCM_SIP_420_BAD_EXTENSION |
369098879 | 0x1600007F | CCM_SIP_421_EXTENSION_REQUIRED |
402653311 | 0x1800007F | CCM_SIP_423_INTERVAL_TOO_BRIEF |
419430421 | 0x19000015 | CCM_SIP_424_BAD_LOCA TION_INFO |
1073741842 | 0x40000012 | CCM_SIP_480_TEMPORARILY_UNAVAILABLE |
1090519081 | 0x41000029 | CCM_SIP_481_CALL_LEG_DOES_NOT_EXIST |
1107296281 | 0x42000019 | CCM_SIP_482_LOOP_DETECTED = 0x42000000 + EXCHANGE_ROUTING_ERROR |
1124073497 | 0x43000019 | CCM_SIP_483_TOO_MANY_HOOPS |
1140850716 | 0x4400001C | CCM_SIP_484_ADDRESS_INCOMPLETE |
1157627905 | 0x45000001 | CCM_SIP_485_AMBIGUOUS |
1174405137 | 0x46000011 | CCM_SIP_486_BUSY_HERE |
1191182367 | 0x4700001F | CCM_SIP_487_REQUEST_TERMINATED |
1207959583 | 0x4800001F | CCM_SIP_488_NOT_ACCEPTABLE_HERE |
1258291217 | 0x4B000011 | CCM_SIP_491_REQUEST_PENDING |
1291845649 | 0x4D000011 | CCM_SIP_493_UNDECIPHERABLE |
1409286185 | 0x54000029 | CCM_SIP_500_SERVER_INTERNAL_ERROR |
1442840614 | 0x56000026 | CCM_SIP_502_BAD_GATEWAY |
1459617833 | 0x57000029 | CCM_SIP_503_SERVICE_UNAVAILABLE |
2801795135 | 0xA700003F | CCM_SIP_503_SERVICE_UNAVAILABLE_SER_OPTION_NOAV |
1476395110 | 0x58000066 | CCM_SIP__504_SERVER_TIME_OUT |
1493172351 | 0x5900007F | CCM_SIP_505_SIP_VERSION_NOT_SUPPORTED |
1509949567 | 0x5A00007F | CCM_SIP_513_MESSAGE_TOO_LARGE |
2701131793 | 0xA1000011 | CCM_SIP_600_BUSY_EVERYWHERE |
2717909013 | 0xA2000015 | CCM_SIP_603_DECLINE |
2734686209 | 0xA3000001 | CCM_SIP_604_DOES_NOT_EXIST_ANYWHERE |
2751463455 | 0xA400001F | CCM_SIP_606_NOT_ACCEPTABLE |
Links
Download and test Tariscope
Benefits of Tariscope to collect and analyze CDR and CMR from CUCM
Control of call quality for CUCM using Tariscope
Tariscope configuration to use the restriction feature with CUCM
Creation of report forms for CUCM
- Details