August 16, 2011 at 14:01Customer Response Solutions: extension dialing
At work, the task appeared to implement dialing to internal numbers of the organization. We use Cisco CallManager 4.2 as the IP PBX, and Customer Response Solutions 4.0 (IPCC) is used for the call center. To write the script, we used the Cisco Customer Response Solutions Editor, which comes with CRS. The script from the editor’s delivery package - aa.aef is taken as the basis.
At the moment, the script is very simple and does not contain any voice greetings, processing various events (like a busy signal, an incorrectly dialed number). In the future, I plan to improve it to a full-fledged script with greetings, requests, and all possible “foolish” checks. Now I will describe in detail how to make extension dialing.
We start the editor and create a new script.
Let's create two variables: one for storing the number, the other for the request. The query u will be empty, because the dialog requires the presence of this parameter in the settings.
Now you need to add event handlers for the incoming call. Here's a script like this:
Let's go through the main elements in order. The first Start statement is present in all scripts by default and means the beginning. The next two accept the challenge. The following Get Digit String function allows you to receive dialed numbers from the subscriber. It needs to be configured. After dragging it from the object panel into the body of the script, right-click on it and select Properties . On the first tab, Generalin the Result Digit String list, select the intNum variable . Next, on the Prompt tab, in the Prompt list, select the prompt variable . On the Input tab, you can configure the settings for receiving numbers from the subscriber. I left everything by default. And finally, on the Filter tab, you need to set the number of digits that will be expected from the subscriber. I set the number 4 in the Input Length field , since I have a four-digit internal numbering plan.
Since while we take into account that the user entered everything correctly, we add the Call Redirect function to the Successful condition. This function will redirect the call to the number entered by the subscriber. It also needs to be configured. In the Call Redirect properties, in the Destination field, select the intNum variable .
Add the Set Contact Info function to the Successful condition of the Call Redirect function . Click on it with the right mouse button and in the Attributes tab opposite the Handled parameter select - Marked - . After we add the End operator . This will mark the caller’s call as “processed” and end the session. At the end of the script, add Terminate and End
. This completes the script. We save it to disk, after which we upload it to the CRS server.
Open the CRS admin panel, select Script Management .
Before us is a list of scripts present in the system. You need to add your own, just created. Click the Upload New Scripts link .
Select the saved script and click the Upload button . Now that the script is uploaded, you need to create an application. An application in CRS defines the script used by JTAPI to process calls, and also sets the initial parameters for the script, if any.
Select the item Application Management .
We see the list of available applications in the system:
Click Add a New Application . In the window that appears in the list, select Cisco Script Application.
We call the application as we like more. I called it CityToInternal. Description - write something that will allow you to remember in the future why this application is. ID - the system sets it automatically, but you can change it, for example, to 666, if this is not already taken by another application. Maximum number of sessions - the maximum number of calls simultaneously processed by the application. Script - select a script, in my case CTI.aef. Click Update .
Now you need to create Media Termination Dialog Group . Media groups are needed for interacting with subscribers, namely for processing DTMF tones.
Select the item Cisco media .
We get a list of groups. Click Add a New CMT Dialog Control Group .
On the page that appears, set the Description field (something to identify the group) and Maximum Number Of Channels (in my case 10). In fact, for all applications, you can create one group for 100 channels, for example. But I preferred to separate them.
Click Add and the group has been added (in my screenshot, Update, because I have screened an already created group).
Now select the JTAPI item and left click on the JTAPI Call Control Group. You need to create a call control group. This group will create the required number of CTI ports to which the call will be forwarded to the subscriber and the application and our script will be activated from it already.
Click Add a New JTAPI Call Control Group .
Fill in the fields. Group ID - the system fills in automatically, but again you can put anything except for those already used. Description - description of the group, put something recognizable. Often, Description fields are used to display items in settings lists instead of IDs. Number of CTI ports - I set 10, this is the number of CTI ports that will be created. Starting directory number- for this group you will need 10 numbers and here you need to specify the number of the first port (in my case 9980). These numbers should not be assigned to subscribers or Hunt groups. Device name prefix - prefix for naming CTI ports. Device pool - chose Default. Media resource group list - select your primary MRGL. Display - a description of the CTI ports, in fact, what will be displayed next to the number on the phone’s screen (Alerting name) when the CTI calls you. Click Add .
Now you need to create a trigger. A trigger is a certain number that a subscriber will dial to gain access to our application. The same item JTAPI , select left JTAPI Triggers. We see the list of triggers in the system.
Click Add a New JTAPI Trigger .
Directory number - the number on which our application will be activated. I’ll clarify, I have a 7-digit city number. These numbers get to CCM from the router to which the PRI stream arrives via dial-peer voip. In your case, it can be anything - an internal number or any other number that gets to CCM. Application name - select the application (in my case CityToInternal). Maximum number of sessions - the maximum number of sessions, set 10. Call control group - call control group (JTAPI Call control group). Primary dialog group- media group (Media Termination Dialog Group). Device Name and Description - are set automatically based on Prefix (DN) + Directory Number, but you can change them for yourself. Click Add and you're done.
The dial-peer on my voice-gateway is as follows: 1.2.3.4 is the Cisco CallManager IP address. Now you can check the application by calling the number specified in the JTAPI trigger. That's all for now. I hope my article will be useful to you.
At the moment, the script is very simple and does not contain any voice greetings, processing various events (like a busy signal, an incorrectly dialed number). In the future, I plan to improve it to a full-fledged script with greetings, requests, and all possible “foolish” checks. Now I will describe in detail how to make extension dialing.
Script writing
We start the editor and create a new script.
Let's create two variables: one for storing the number, the other for the request. The query u will be empty, because the dialog requires the presence of this parameter in the settings.
Now you need to add event handlers for the incoming call. Here's a script like this:
Let's go through the main elements in order. The first Start statement is present in all scripts by default and means the beginning. The next two accept the challenge. The following Get Digit String function allows you to receive dialed numbers from the subscriber. It needs to be configured. After dragging it from the object panel into the body of the script, right-click on it and select Properties . On the first tab, Generalin the Result Digit String list, select the intNum variable . Next, on the Prompt tab, in the Prompt list, select the prompt variable . On the Input tab, you can configure the settings for receiving numbers from the subscriber. I left everything by default. And finally, on the Filter tab, you need to set the number of digits that will be expected from the subscriber. I set the number 4 in the Input Length field , since I have a four-digit internal numbering plan.
Since while we take into account that the user entered everything correctly, we add the Call Redirect function to the Successful condition. This function will redirect the call to the number entered by the subscriber. It also needs to be configured. In the Call Redirect properties, in the Destination field, select the intNum variable .
Add the Set Contact Info function to the Successful condition of the Call Redirect function . Click on it with the right mouse button and in the Attributes tab opposite the Handled parameter select - Marked - . After we add the End operator . This will mark the caller’s call as “processed” and end the session. At the end of the script, add Terminate and End
. This completes the script. We save it to disk, after which we upload it to the CRS server.
CRS setup
Open the CRS admin panel, select Script Management .
Before us is a list of scripts present in the system. You need to add your own, just created. Click the Upload New Scripts link .
Select the saved script and click the Upload button . Now that the script is uploaded, you need to create an application. An application in CRS defines the script used by JTAPI to process calls, and also sets the initial parameters for the script, if any.
Select the item Application Management .
We see the list of available applications in the system:
Click Add a New Application . In the window that appears in the list, select Cisco Script Application.
We call the application as we like more. I called it CityToInternal. Description - write something that will allow you to remember in the future why this application is. ID - the system sets it automatically, but you can change it, for example, to 666, if this is not already taken by another application. Maximum number of sessions - the maximum number of calls simultaneously processed by the application. Script - select a script, in my case CTI.aef. Click Update .
Now you need to create Media Termination Dialog Group . Media groups are needed for interacting with subscribers, namely for processing DTMF tones.
Select the item Cisco media .
We get a list of groups. Click Add a New CMT Dialog Control Group .
On the page that appears, set the Description field (something to identify the group) and Maximum Number Of Channels (in my case 10). In fact, for all applications, you can create one group for 100 channels, for example. But I preferred to separate them.
Click Add and the group has been added (in my screenshot, Update, because I have screened an already created group).
Now select the JTAPI item and left click on the JTAPI Call Control Group. You need to create a call control group. This group will create the required number of CTI ports to which the call will be forwarded to the subscriber and the application and our script will be activated from it already.
Click Add a New JTAPI Call Control Group .
Fill in the fields. Group ID - the system fills in automatically, but again you can put anything except for those already used. Description - description of the group, put something recognizable. Often, Description fields are used to display items in settings lists instead of IDs. Number of CTI ports - I set 10, this is the number of CTI ports that will be created. Starting directory number- for this group you will need 10 numbers and here you need to specify the number of the first port (in my case 9980). These numbers should not be assigned to subscribers or Hunt groups. Device name prefix - prefix for naming CTI ports. Device pool - chose Default. Media resource group list - select your primary MRGL. Display - a description of the CTI ports, in fact, what will be displayed next to the number on the phone’s screen (Alerting name) when the CTI calls you. Click Add .
Now you need to create a trigger. A trigger is a certain number that a subscriber will dial to gain access to our application. The same item JTAPI , select left JTAPI Triggers. We see the list of triggers in the system.
Click Add a New JTAPI Trigger .
Directory number - the number on which our application will be activated. I’ll clarify, I have a 7-digit city number. These numbers get to CCM from the router to which the PRI stream arrives via dial-peer voip. In your case, it can be anything - an internal number or any other number that gets to CCM. Application name - select the application (in my case CityToInternal). Maximum number of sessions - the maximum number of sessions, set 10. Call control group - call control group (JTAPI Call control group). Primary dialog group- media group (Media Termination Dialog Group). Device Name and Description - are set automatically based on Prefix (DN) + Directory Number, but you can change them for yourself. Click Add and you're done.
Router configuration
The dial-peer on my voice-gateway is as follows: 1.2.3.4 is the Cisco CallManager IP address. Now you can check the application by calling the number specified in the JTAPI trigger. That's all for now. I hope my article will be useful to you.
dial-peer voice 254 voip
description === 1234567 ===
destination-pattern 1234567
session target ipv4:1.2.3.4
dtmf-relay h245-signal h245-alphanumeric
codec g711ulaw