Get Familiar with Manipulating the Caller-ID Information

3 steps to identify and configure the right elements

In this week’s post, “Get Familiar with Manipulating the Caller-ID Information,” learn the 3 steps to configure the outbound Caller-ID Information to the Avaya Core systems Communications Manager and IP Office through their respective configuration elements.

In my years working with the different type of trunk technologies and Service Providers, arranging and manipulating outbound Caller-ID Information, I have had my fair share of success and issues which at time lead to angry customers and reluctant telecom engineers claiming that the issue existed with my equipment.

Here, I help you determine ways to test some of the Avaya Core systems including Communications Manager and IP Office systems to successfully configure the outbound Caller-ID Information by following these 3 steps.

• 1.- Collect and Confirm
• 2.- Verify and Test
• 3.- Routing decisions

1.- Collect and confirm

In this phase, you are sitting with the site administrator to understand how they would like the outbound caller-ID configured. With this information in hand, it is time to contact the Service Provider to confirm the outbound CID is allowed to be transmitted from the Avaya Core systems to the caller’s destination.

2.- Verify and test

Before you apply any changes to the Avaya Core , it is important to create a single entry to allow you to test from a single location.

Avaya Aura CM – Depending on the Trunk-Group Features and  Service-Type-Options, you must configure the Public Unknown Tables to match the Caller-ID information requested by the Site Administrator.

Avaya IP Office – This system can use either shortcodes or User URI to send the caller-ID information depending the Line type implemented.

3.- Routing decisions

There are some Pros and Cons when having the Avaya Core Solution decide which numbers to send as the Caller-ID.

Cons

Dial Emergency – This feature needs to be configured by location. You have to ensure the Local Authorities have that specific number registered in their system displaying the correct business address.

Send Name – The Avaya Core system is not able to send Names only telephone numbers.

System Configuration Limitations – As you add new users to the system, this might also result adding new table entries. In some cases you can add wildcards to help solve this issue.

Remote Call Forward – EC-500 in CM and Twinning in IP Office, are the two most used features with Remote Call Forwarding. The Avaya Core solution can send the Caller’s information out to the Twinned or EC-500 station. This feature requires the Service Provider to allow the calls to be presented. This is also true when using SIP Trunks route through SBCs, as forking can become an issue by flagging these type of calls as malicious through enforced Toll Fraud Rules.

Pros

Dial Emergency – For those Remote Workers, this feature helps the Avaya System Administrator configure each individual number with its location number, helping the local authorities match the business address and avoiding confusion when calling them. It is a good idea ask the Service Provider if they support Emergency Call Routing.

Configuration Flexibility – You can have each station send their DID Number as their Caller-ID. This is helpful if you have to release the Main Receptionist by directing call backs to internal extensions.

Location Based Numbers – Assign range of DIDs to specific locations and use them as the outbound Caller-ID for site identification.

Communications Manager – The station can be configured through the Extension Emergency Location with a Call Back Number (CBN) functionality in conjunction with both Public-Unknown and the Incoming-Call-Handling-Treatment tables.

The Remote Worker will send the DID Number to the PSAP (Public Safety Answering Point)  911 Operator. IP-Network-Maps Emergency Location information will be sent if no DID is configured. Another consideration when implementing RFC with SIP trunks is to know when to configure IP-NR with the FQDN information for that specific location.

IP Office – User shortcodes can be configured to send local registered numbers to allow the local authorities to be dispatched to the Remote Worker’s address. It is important to know the IP Office system forces the Incoming Routing Table number if no number is specified in the shortcodes’ Telephone Number field.

Question

Can you tell us which features of the trunk group in CM could help us send caller-ID information? – Or if you are an IP Office technician, besides the System and User Shortcodes, where can we configure the Caller-ID?