Cloud Connector Edition; Interop with Short Digit Dialing


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

clip_image002

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

Korneel11

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.

Korneel2

 

After this configuration, it should say “LDAP Connected” on the bottom of the screen;

Korneel3

 

In that same screen, click on LDAP Servers Search Based DNs

Korneel4

 

Create a new search DN, and make sure this DN is the OU that includes your users, in my case it is “users”

Korneel5

 

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.

Korneel6

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:

Korneel1

 

 

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”.

Korneel7

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;

Korneel8

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.

 

Comments (0)

Skip to main content