Author; Korneel Bullens , Senior Customer Engineering Architect, Skype for Business
References;
Planning for Cloud Connector Edition - https://technet.microsoft.com/en-us/library/mt605227.aspx
Configuring Cloud Connector Edition - https://technet.microsoft.com/en-us/library/mt605228.aspx
Hardware Used;
· Audiocodes Mediant 800 with integrated OSN
· OSN Hardware
o 32 gb of memory
o Core I7 5859EQ
o Dual network connections
o 512 GB SSD
Prerequisites;
· Cloud Connector minimum Edition installed and working
· Office 365 configured
· Connection between PBX and Cloud Connector Edition via Gateway (in this example we use a Mediant 800)
· A client machine that allows the user to sign in and place/receive calls.
· Working routes on the gateway between the PBX and the Mediant
Environment
Internal IP Addresses
| Ip Address | Host | Subnet Mask | Gateway | DNS Server |
| 172.16.50.150 | CCE OSN | 255.255.255.0 | 172.16.50.250 | 172.16.50.1 |
| 172.16.50.151 | CMS | 255.255.255.0 | 172.16.50.250 | 172.16.50.1 |
| 172.16.50.152 | Edge | 255.255.255.0 | 172.16.50.250 | 172.16.50.1 |
| 172.16.50.153 | Mediation | 255.255.255.0 | 172.16.50.250 | 172.16.50.1 |
| 172.16.50.154 | DC | 255.255.255.0 | 172.16.50.250 | 172.16.50.1 |
| 172.16.50.155 | BaseVMIP | 255.255.255.0 | 172.16.50.250 | 172.16.50.1 |
| 172.16.50.156 | Gateway | 255.255.255.0 | 172.16.50.250 | 172.16.50.1 |
External Ip Addresses
| Ip Address | Host | Subnet Mask | Gateway | DNS Server | External DNS Name |
| 185.92.71.252 | Edge | 255.255.255.248 | 185.92.71.249 | 172.16.50.1 | Ap.korneel.nl |
Users
| Name | Username | SIP Address | External Phone Number (Phone Number) | IP Phone |
| Korneel Bullens | Kbullens | kbullens@korneel.nl | +31305001484 | 12345 |
| Thomas Binder | TBinder | Tbinder@korneel.nl | +31305001485 | 54321 |
In AD, the users are configured with the External Phone Number as their Phone Number, and the IP Phone Number in the Ip Phone Field.
Domains in use
Korneelb.onmicrosoft.com as the tenant
Korneel.nl as the SIP domain
Additional Servers
Domain Controller
ADFS Server that also runs AADSync
Preparing the environment
In our lab, we have connected a desk phone to port FXS1, with the phone number of 12345. This phone will simulate an existing short digit dialing desk phone. The FXS port could also have been a PRI connected to a PBX.
The Scenario
Korneel is using Skype for Business with Cloud Connector Edition. Cloud Connector Edition is connected to the legacy PBX using a Mediant 800. Thomas has not yet been migrated. The PBX is still using Short Digit Dialing. Some users have been migrated to Cloud PBX, some have not.
Users that have been migrated still need to be able to dial users that have not. We will configure the Mediant 800 in such a way, so that it performs an AD Lookup (LDAP Query) to replace the E164 TEL URI in the invite and the from when dialing from Cloud Connector Edition to the PBX with the Extensions\Short Digits of the User, and the other way around.
In example;
Korneel is dialing Thomas, using the E164 number (+31305001485). Reverse Number Lookup is performed by Skype for Business Online, and if Thomas has not been enabled, Reverse Number lookup will fail and will redirect the call on premises. The call then reaches the Mediant, the Mediant performs an LDAP query and will match the E164 number to the phone number in AD. It will then replace it with the IP Phone Number. It will do the same with the from number, so that the extension for callback will match.
When Thomas wants to call Korneel, he dials Korneels extension. The PBX no longer knows this extension and sends this to the Mediant. The Mediant performs an AD lookup, and replaces the To and From number with E164 numbers, making sure the call succeeds.
Configuring the Mediant 800
Enabling AD Lookup
On the Domain Controller, in the OU Users, create a new user called “LDAP”. Make sure the login name is LDAP and set a password.
Then proceed to log in to the gateway for the next step
In the gateway, under VOIP, go to Services, LDAP, LDAP Server Groups.
Note : if you don’t see the services group, you should enable the Advanced View in the top of the screen.
Create a new group, and save the group
In my example I’ve called the group DC01.
Go to LDAP Configuration Table and add a new line.
In my example, I’m using the Voice Network Interface, and my DC (that is connected to ADFS, NOT the CCE DC, has the ip of 172,.16.50.1.) Please note that you must put the user account’s full Distinguished Name in; you can find this under the advanced tab in the users properties in AD.
After this configuration, it should say “LDAP Connected” on the bottom of the screen;
In that same screen, click on LDAP Servers Search Based DNs
Create a new search DN, and make sure this DN is the OU that includes your users, in my case it is “users”
Now that we know where to look for the users, we also need to enable the rules. This is done under VoIP>Gateway>Routing>Gateway Routing Policy. Edit (or create) the default policy and set the LDAP Servers Group Name to the LDAP Servers group name you have created before.
Now that the Mediant can perform LDAP lookups and apply rules, it’s time to create the rules;
Number Manipulation Rules
Go to VoIP>Services>LDAP>Call Setup Rules.
What we want to do is if a call comes in, we take a look at the destination number, match this to a number in AD, then replace it with a different number from AD. For example, if a call goes from CCE to the PBX, the incoming source and destination number will be E164. The PBX will not understand this since it needs extensions. Therefore, we will create a rule that will look at the destination number, match that to the telephoneNumber field in AD and replace it with the ipPhone Field in AD. We do the same thing for the Source Phone Number. This will require 2 rules and we can group them together as one rule set. We will also need to do something similar the other way around (ipPhone to telephoneNumber) for calls from the PBX to Cloud Connector. We will create these 2 rules and group them under another rule set.
The following rules must be created;
Note : Default Values have been omitted from this table. Action Type is always “Modify”
|
Rules Set ID
|
Attributes To Query
|
Attributes To Get
|
Condition
|
Action Subject
|
Action Value
|
|
1 |
'ipPhone=' + param.call.dst.user |
telephoneNumber |
ldap.attr.telephoneNumber exists |
param.call.dst.user |
ldap.attr.telephoneNumber |
|
1 |
'ipPhone=' + param.call.src.user |
telephoneNumber |
ldap.attr.telephoneNumber exists |
param.call.src.user |
ldap.attr.telephoneNumber |
|
2 |
'telephoneNumber=' + param.call.dst.user |
ipPhone |
ldap.attr.ipPhone exists |
param.call.dst.user |
ldap.attr.ipPhone |
|
2 |
'telephoneNumber=' + param.call.src.user |
ipPhone |
ldap.attr.ipPhone exists |
param.call.src.user |
ldap.attr.ipPhone |
After configuration your rule set should look like this:
Before we continue, let’s take a quick look at what is actually happening inside these rule sets.
If we look at the first rule, what this does, is that if the rule is applied, it queries the “IpPhone” field in AD with the value of param.call.dst.user, which is an internal Audiocodes variable, which holds the value of the phone number of the destination. In our case, this rule would be applied to a call from the PBX to Cloud Connector so it would contain the destinations user extension, as dialed by the user on the PBX. If we get a match, we then get the attribute “telephoneNumber” from that object\user. We then put that value in the variable ldap.attr.telephoneNumber. In the Action Subject, we specify that we want to change the param.call.dst.user, which still holds our variable for the destination's user phone number, and we modify that with the action value ldap.attr.telephoneNumber, which holds the objects telephone number which is in our case the E164 number.
Once the configuration is complete, rule set 1 is now capable of replacing the value in the IPPhone Field with the telephoneNumber field, and rule set 2 is capable of replacing the value in the telephoneNumber Field with the value in the IpPhone Field. Since we put the PBX Extension in the ipPhone Field and the E164 number in the telephoneNumber field, we can now interchange the numbers between CCE and the PBX.
Applying the rules to Routes
Since we have the 2 rule sets active now, they can be applied to the routes. Under VoIP>Gateway>Routing you will find Tel to Ip Routing (PBX to SfB) and IP to Trunk Group Routing (SfB to PBX.
In our LDAP rules, rule set 1 was capable of replacing extensions with E164 so this applied to the Tel to IP Routing. Open up Tel to Ip Routing and edit the Route that enables PBX to SfB Routing. Under “Action” change the “Call Setup Rules Set ID” to “1”.
Save this, and open up IP to Trunk Group Routing. Since Rule Set 2 enabled the replacing of the E164 number with the Extension, we now need to apply rule set 2 to this route.
Open the appropriate route(s) and now under Action, apply Call Setup Rules Set ID 2.
Now that the setup is complete, don’t forget to press the “Burn” button on top of the screen to save the configuration.
Testing the Rules
Now that the rules have been applied, we are testing them by placing a call from Thomas’ Phone to Korneel’s SfB Client.
On the phone, we dial 12345. In the Audiocodes gateway, we see the following;
And on the SfB client the call is correctly identified as coming from Thomas.
Additional Notes:
Please note that the LDAP rules are only applied after matching a voice route. You cannot create a voice route that matches a phone number AFTER the LDAP rule.
If a phone number is assigned to a user in Skype for Business, reverse number lookup will prevent the number being routed to the gateway.