Overview
This document will step you through the process of Integrating the Avaya IP Office with a SIP Trunk to the Connect Platform. This will cover the following
- Avaya IP Office SIP Trunk Configuration
- Avaya IP Office Short Codes
- Avaya IP Office Incoming Call Routes
- Avaya User Requirements
- Connect SIP Trunk Configuration
- Connect Dial Translations
Building the Connect SIP Trunk
Before we add the Avaya IP Office Trunk and set up the routing to and from the Connect Platform we need to establish connectivity between the systems. Let's build a SIP Trunk to the Avaya IP Office in Connect using the following steps.
Navigate to SIP Trunks in the portal and Click “Add SIP Trunk”. Note this may require elevated permissions.
Now fill in the fields using the example below.
| Name | DNS Name (Preferred) but could be Public IP |
| Description | Interconnect to IPO |
| SIP User | Domain+Date or Generate a Username |
| SIP Password | Pre Populated |
Under the Dial Planning & Limits we want to make sure we set appropriate limits to allow the customers to use the trunks but do not leave it unlimited. It's Very Important that you leave the Dial Translation set to the domain. Otherwise, the changes we make below will not work properly.
Click Add and now there is a trunk built to the IP Office.
Building The Avaya IP Office SIP Trunk
Attached below is the XML Template for the trunk Import.
Avaya IP Office Trunk Import XML
Important!
The "Local Domain Name" field will need to be changed to the Avaya's DNS or Public IP of the system you are working on. It should be set to what you put in the “Name” field of the Connect Trunk. The SIP Registration will also need to be set up with the settings configured on Connect Trunk.
Calls from the Connect Platform can come from any of the Core Servers so in order to handle those calls, The Avaya Platform must be able to communicate to each core.
Requirements on allowing this communication through a firewall must be met, please review the network requirements document Persona Connect: Network Requirements Table of Contents
How will the users on Avaya call the Persona Connect Users?
Option 1: Leading Digit
You could build the users on the Avaya Platform and forward each user to the Persona Connect Extension and route those calls over the SIP Trunk, In most cases, the extensions may be the same so you will need to come up with a leading digit. ( This allows the users on Avaya to still see all users in the contacts directory and just press the name to call them)
Avaya Short Code Setup
The Short Codes in Avaya is going to route your calls to the Connect platform. Typically you would build a short code with a leading digit like below.
| Code | Feature | Telephone Number | Line Group |
| 7XXXX | Dial Number | N | 800 |
This allows you to forward users to 7XXXX (Where XXXX is their extension number) and this will drop the 7 and just send the extension over that line group for Persona Connect to route on the domain.
Option 2: Separate Extension Range's
Build a route for the extensions on the Connect Platform in the Short Codes to route the call directly over the SIP Trunk without a leading digit. (The downside of this is that the users on the Avaya Platform will need to know the other user's extensions, They won't show up in the directory if they are not users.)
Avaya Short Code Setup
You could also build shortcodes that match the extension number but the user on the Avaya must be removed. The user will always take precedence over a system shortcode. Doing this will remove the user from any directory lists in the Avaya or speed dial buttons. If this is not acceptable then you will want to use option 1 above.
Once the user is deleted you can build a short code like the below.
| Code | Feature | Telephone Number | Line Group |
| 2254 | Dial Number | 2254 | 800 |
Or Wildcard a Range
| Code | Feature | Telephone Number | Line Group |
| 22XX | Dial Number | 22N | 800 |
Option 3: Speed Dial List
Using the System Speed Dial List
You could also delete the users from the system and build in an entry to Avaya's system speed dial list. This could contain the user's extension with a leading digit in it so that you may build a wildcard to handle the routing. Your short code would look the same as option 1 (Shown Below), Then you would add a speed dial entry to send the call to the extension with the leading digit.
Avaya Short Code Setup
| Code | Feature | Telephone Number | Line Group |
| 7XXXX | Dial Number | N | 800 |
Avaya Incoming Call Routes
The Incoming Call Routes are required on the Avaya Platform as Persona Connect will be pushing 4,5,6 and in some cases 10 Digit numbers back to the IP Office SIP Trunk. We use the period in the destination to just have the IP Office redial those digits and use its internal routing to determine where they go.
The 10X route has a 91 in front of the period so that we prefix what Persona Connect sent us with those digits to hit ARS. Change the leading digit if you would like to push another Caller ID or follow another route. Here are some examples
IP Office Incoming Call Routes | |||
| NUMBER | DESTINATION | Line Group | DESCRIPTION |
| XXX | . | 800 | Inbound 3 Digit Dialing, Period redials the digits for the IP Office to route |
| XXXX | . | 800 | Inbound 4 Digit Dialing, Period redials the digits for the IP Office to route |
| XXXXX | . | 800 | Inbound 5 Digit Dialing, Period redials the digits for the IP Office to route |
| XXXXXXXXXX | 91. | 800 | This route allows 10 digit dialing over the Interconnect trunks but this is only needed if you are pushing calls through the Avaya and not the Connect Platform |
Avaya User Changes
If the users are not going to be using the Avaya Platform and they would like to remove them from the desks and just use the Connect Platform to take all calls then we can use Forwarding Unconditional to Short Codes that will send the calls to the Persona Connect Platform. We have found that this may cause caller ID to be incorrect on calls that have been answered by the IP Office and transferred to user that is forwarded. Use twinning instead and this will show the original caller ID to Connect. You will also need to to turn off voicemail on the IP Office user account unless you would like messages to stay on the Avaya platform.
This is typically the best option so both systems show all users for each contact dialing. The presence between the systems will not work.
How will the users on Persona Connect dial the IP Office Users?
This can be accomplished in a few different ways. Here are a couple of examples
NOTE: Dial Translations in the Persona Connect portal are not accessible from the main portal and require's a service ticket to be opened in order to have these created.
Option 1: Create Users for Avaya Extensions
Build the users on the Connect Platform and forward each user to the Avaya Extension, In most cases, the extensions may be the same so you will need to come up with a leading digit. ( This allows the users on Connect to see all users in the contacts and just press the name to call them)
Example of Dial Translation for forwarding users to Avaya Extensions with a leading digit.
Here we have a leading digit of a 1, Then 4 digits starting with a 2. So when 12XXX is dialed it strips the 1 off in the Destination User Translation and sends the call to the connection.
NOTE: The ! removes the digit
This dial translation allows you to build all the users on the Connect Platform and then forward the ones still on the Avaya system to their Avaya Extension with a 1 in front to match the route above. This again is useful so the users on the Connect Platform can still see and call the Avaya Users by using the contacts list.
Option 2: Build Dial Translations
Build a route for the extensions on the Avaya platform in the dial translations to route the call directly to Avaya without a leading digit. (The downside of this is that in most cases you have to build multiple dial translations to accomplish this.
Here is an example of what one of those dial translations would look like for a single user still on the Avaya platform.
Here we have sip:2254@* as the destination. This translation will match if 2254 is dialed from a device. If you are going to forward a user to 2254 and expect it to match this rule you will need to remove the "sip:" in front of 2254 as that only match's if dialed from a device.
Before you build this however you should consider building this the other way around. Which system has more users staying on it?
With this dial translation we are building a route for each user on the Avaya but what if most of the users are on the Avaya and you only have a few on Connect? In this scenario, we would want to wildcard everything to the Avaya and build specific matches for the Connect Extensions to stay on the platform.
Here is what that looks like. First the Wildcard to the Avaya
This rule sends anything 2XXX Dialed to the connection alleg.allegianttelcom.com (Our IP Office in this case)
Now I have a user 2254 that needs to be on Connect and not follow this rule. We just need to be more specific on that one and it will match the more specific rule.
This rule is more specific than the wildcard above when I dial 2254 so it will match and instead of sending it to the IP Office Connection, it will chain to the reseller dial translation and eventually match the extension dialing in the Cloud PBX Features dial translation rules.
Using Connect as the Service Provider
The above setup outlines how to connect the two systems together and build a dialing plan for users to call between systems. However you could also use the Connect Domain as a way to provide inbound and outbound calling to the Avaya System.
Benefits
- Inbound and Outbound Call Traces
- Call Recording
- Toll Fraud Mitigation
- Easy Migration Path
Outbound Calls
The Avaya System we will need to push all outbound calls from the Avaya IP Office to the Connect SIP Trunk that has already been tested and used for internal dialing. In order to do this you will want to point your ARS Tables so that they are pointing to the Trunk Group assigned to the Connect Trunk.
Inbound Calls
Calls coming inbound to Connect that are going to route to a destination on the Avaya IP Office should be pointed directly to the Avaya IP Office using the SIP Trunk option in the Phone Number Inventory.
You could route the call to a user on Connect and do some forwarding and if there is a use case that requires that then feel free to build it that way, However if there is no need this will only make the complexity of the integration harder to troubleshoot.