Scroll export button | ||||||||
---|---|---|---|---|---|---|---|---|
|
Info |
---|
The following Admin Guide describes how to bypass ACL Restricted Calls by means of PINs. Credated: March 2018 Permalink: https://wildix.atlassian.net/wiki/x/rBrOAQ |
Table of Contents
Introduction
Restricted dialing is a feature that is supported via ACL and User Permissions. This feature may often be applied to phones that are in common areas or in conference rooms. It may also be applied to normal user phones for blocking international calls as an example.
However, the ability to bypass these dialing restrictions can be configured whereby a user enters his PIN and the system allows dialing to destinations based upon the permissions of his PIN.
In practice, the call flow would be as follows:
User dials a number that is restricted on this phone (for example, international number)
User is prompted for his PIN since the call is not allowed from this phone normally
User enters his PIN and if allowed based upon the entered PIN, the system routes the call to the restricted destination
Note |
---|
Note: it is possible to have PINs with different permission levels, so the PIN for a sales assistant has different permissions than the sales manager's in regards to allowed dialing destinations. |
Configuring PIN Bypass for ACL Restricted Calls
In the normal user diaplan you will build all of the possible matches that meet your needs. This will include local, national, international, etc.
Examples:
*If a user dials 01 + 10 digits, the PBX should remove the 01, add a 52 and send 52 + 10 digit
*If a user dials 00+ number, PBX should strip the 00 and send “number”
*if a user dials 1 + 10 digits treat it as local for US and will strip the 1 and send 10 digit
For each of these entries you will assign a call class of local, national, international, etc. This is done on the dial trunk application as shown below. Notice the Class assignment as National in the example.
Each user in the system is allowed or not allowed to call destination numbers based on these classes. This is done via the Group that the user is assigned to. The following screenshot is an example of these permissions (User - Groups config). So, essentially, for each dialed pattern there is an assigned class and then users are either allowed or not allowed to call the classes as desired.
For more information on ACL (access control list) and permissions see the following document:https://confluence.wildix.com/x/eQaIAQ ACL rules and Call classes management - Admin Guide.
Bypassing Restrictions Based On PIN
Let us take the case where there is a conference room phone that is setup to not allow national or international calling. This phone is “local only” dialing. However, the business wants to allow users to override the restrictions via entering a PIN. In such a case, if a user calls an international number from this restricted conference room phone, they would be prompted to enter a PIN. If they enter a valid PIN, the call is then routed to a new dialplan rather than being rejected. In this new dialplan, routes for all allowed destinations can be configured. Each user can have their own PIN, allowing the administrator to setup different restrictions for individual users or groups of users.
To configure this, the administrator would do the following:
- Allow a PIN entry in case the user dials something that is not allowed from the phone
Notice in the screenshot below that there is a dial trunk step, followed by a “Jump to” step. If the dial trunk step fails due to restrictions, the “Jump to” application sends the call to a new dialplan called PINS.
In the PINS dialplan, the administrator will configure the collection of the PIN in the default entry. The call being sent to this dialplan had some destination number associated with it. Let us say for example that the user dialed an international number. An international dialed number would match the defaul entry in this dialplan since the other entries are not a match. The user would now be prompted for a PIN via the “Play sound and wait for digits entry and the system would wait for 4 seconds for that pin. Once the user has entered the pin, the system will check in this same dialplan for a match of the pin. In the example below, valid pins are 1234, 2345, 5555 and 9876.
There is one other part of the screenshot above that is important. It is the “Set myNum ${CALLERID(dnid)}” application. This step is SAVING the originally called number (user dialed destination number; not the pin). This is necessary since once the user dials their pin, the system will now try to match on the pin and not on the originally dialed destination number. So for now we simply save it off so that we can use it later. More description of this momentarily.
Now we must route the call based upon the permissions for the valid pin that has been entered. To do this, the administrator configures each pin as shown below. Notice the “Jump to” application that sends the call to IntlBypass for pin 1234 but to NationalBypass for pin 2345. Also make special note of the number that is being sent to the destination diaplan. It is our SAVED value of myNum. In this context, we use ${myNum} to reference the value of that variable.
Now the call will route via the specified dialplan with the originally dialed destination number!
The only configuration left at this point is to have a dialplan that matches anything that this user should be allowed to dial. Importantly, the administrator would NOT define matches for anything that this pin should NOT be able to dial, thus mapping the pin to a list of dialable patterns. The following screenshot shows a simple example of an entry in this “final” dialplan:
There is one more thing that is important to point out for this configuration. It is the “class” that is set on the call in this final dialplan. You want to set this class to something that all users can dial! This is because if you route the call to this final dialplan and mark it as something like “international” as it’s class, you may in fact end up restricting the user from making the call (because as you remember, the call is originated from a phone that does not have permission to call international). So, the suggestion would be to use a class of something like “Internal”. If desired, a specific unused call class could be configured here such as “Premium4”. In this way the administrator could view calls that used ACL Pin Bypass. This could be done from the CDR View in collaboration since Call Class is one of the fields that is recorded in the CDR.
Macrosuite divider macro | ||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
...