# Caller Based Routing

## Description:

Caller Based Routing allows the routing of incoming Public Switched Telephone Network (PSTN) calls from specific callers based on the Calling Line Identification (CLI), also known as Caller ID. The incoming call can be mapped as a Allow-List or Deny-List call at the PSTN controller gateway depending on the configuration of Call Service Routing Type for the Caller ID in the Caller Based Routing Service form. For more information on the configuration options, see Caller Based Routing Service.

The following table describes a few routing possibilities using Allow-List and Deny-List types:

Call Service Routing Types
Allow-List | Deny-List
Route calls to a specific Destination Number. For example, calls from an important client can be routed directly to the account manager. | Block calls from specific callers.
Route calls within a geographic region to a specific Destination Number. For example, calls from 613 area code can be routed to Ring Group A, and the calls from 416 area code can be routed to Ring Group B. | Route intrusive calls to the security or legal team.

### Caller Based Routing–Example

The following table describes the routing based on the Caller Based Routing configuration:

Caller ID | Primary Node ID (PNI) | Destination Number | Caller Based Routing Service Type
6135921234 | 599 | 4052920 | Allow-List
6135922122 | 599 | 9999 | Deny-List
8234362340 |  |  | Deny-List

In the above example, the incoming calls are routed as follows:

- 6135921234 is routed to 4052920 regardless of the destination number dialed by the caller.

- 6135922122 is routed to 9999 destination number.

- 8234362340 is blocked depending on the lntercept Handling configuration

### Incoming Call Digit Matching

The matching of the CLI is done from left to right. This enables the Caller Based Routing feature to consider both the country and the area codes. For Allow-List calls, the destination number must be specified and cannot be left blank. In case of Deny-List calls, the destination number is not mandatory and can be left blank. Allow-List calls are routed based on exact or partial match of the caller ID, while the Deny-List calls are routed based only on the exact match of the caller ID.

The Caller Based routing service fails in the following scenarios:

- If there is a conflicting result for Allow-List

- If there is a conflicting result or a partial match for Deny-List

#### Example

The following table describes the match results for the incoming calls when a Deny-List service type is programmed for the Caller ID 613:

Caller ID | Match Result
613 | Exact Match
613-592-2122 | Partial match
1-613-592-2122 | No match

In the above example, the Deny-List routing fails for both 613-592-2122 and 1-613-592-2122 caller IDs.

NOTE

- The administrator must enable the Caller Based Routing Service feature only if the CLI information can be trusted.

- As the Call Based Routing feature can route a call back to the PSTN destination, it could result in toll fraud. The system administrator must ensure proper configuration to protect against toll frauds.

## Conditions and Feature Interactions

- For Deny-List calls, if the destination number is not specified in the Caller Based Routing service form, the call is routed as per the Unassigned Directory Number Intercept Handling configuration.

- This feature impacts the user behavior of Attendants, Telephony and MiTAI applications. These nodes cannot differentiate between a caller in the Deny-List from a regular caller.

- This feature interacts with SMDA applications if Tag Call Identification is configured on the incoming PSTN Station Message Detail Recording (SMDR) record. A call that is in the Deny-List generates an SMDR record and reuses Tag Call field. The reporting is based on the configuration of Tag Call SMD options: Tag Call Reporting and Tag Call Identifier. Calls in the Allow-List generate SMDR records, but are not uniquely identified or tagged in the SMDR records.

- The Call Recognition Service (CRS) feature is used to support the call routing behavior of Allow-List and Deny-List service types. Therefore, this feature is supported on the trunks that delivers calling number, such as: PRI, DASS, BRI, TDM DPNSS, SIP, QSIG, ANI/DNIS delivery trunks, and LS Class.

- When Allow-List and Deny-List service types are programmed along with External Hotdesk User (EHDU) service, the EHDU takes priority over the Allow-List and Deny-List service. If there is a conflict between Allow-List and Deny-List, of if there is a partial match for Deny-List, the result is ignored.

- A call in the Allow-List or Deny-List can be rerouted again based on the destination programmed against the CLI.

- A call in the Allow-List or Deny-List can be forwarded based on the destination programmed against the CLI.

## Programming

1. Trunk Attributes form

- The Caller Based Routing feature must be enabled.

2. Caller Based Routing Service form

- Enter the caller ID of the caller in the Caller ID field.

NOTE: The Caller ID must be unique within the Caller Based Routing Service form.

- To assign a caller as Allow-List or Deny-List type, select the required Service Type against Caller ID.

- For a multi-cluster network, the Primary Node Identifier (PNI) specification is mandatory. To specify the PNI, enter the PNI of the destination number in the PNI field against the Caller ID.

NOTE: For Deny-List service type, if you enter the Primary Node Identifier (PNI) number, the destination cannot be empty.

- To assign a caller as Allow-List or Deny-List type, select the required Service Type against the Caller ID.

## Device Support

Not applicable

## Operation

None

Related Topics

- Intercept Handling

- Tag Call

- Call Routing

- Call Recognition Service

- Call Rerouting

- Call Forwarding

- Station Message Detail Recording (SMDR)

- Malicious Call Tracing