About Me

My photo
This is a blog for John Weber. One of my joys in life is helping others get ahead in life. Content here will be focused on that from this date forward. John was a Skype for Business MVP (2015-2018) - before that, a Lync Server MVP (2010-2014). I used to write a variety of articles (https://tsoorad.blogspot.com) on technical issues with a smattering of other interests. I have a variety of certifications dating back to Novell CNE and working up through the Microsoft MCP stack to MCITP multiple times. FWIW, I am on my third career - ex-USMC, retired US Army. I have a fancy MBA. The opinions expressed on this blog are mine and mine alone.

2014/12/22

Lync analog device off hook dial (AutoDial)

Do you want your analog devices to dial out to the world? Do you need to have your analog device do off-hook dialing?

Both of these issues came up on a recent project.  If you are using 3PIP/OIP phones such as Polycom VVX or AudioCodes HD4xx, then fellow MVP Anthony Caragol has an outline for you.  But what about that phone in the parking lot?  Or the phone at the security fence?  Or the elevator?  Or the emergency phone in some other secure area?  Or maybe you have a door system that needs to dial just one number when a user takes the phone off hook?

We have outlined two different requirements here, and outside of using a Lync Optimized phone, the analog solution is the same, with a twist to make the device work to the outside world (outside of Lync).

First you will need a gateway.  For this exercise, I used an AudioCodes MediaPack MP118, and then validated the solution against an AudioCodes Mediant 800 E-SBC with FXS ports.  In this article, I will show the MP118 configuration.  I tested the solution using my Tsoorad.net lab, an Intelepeer SIP trunk, and I used two el cheapo AT&T 210 analog phones that I purchased at the local bodega.

The purpose of the gateway is to connect the analog phone device to the system and then transcode the analog device to SIP codecs for use with Lync.  The gateway needed some tweaking to get the connections to work – notably, I not only wanted the device to work with Lync, I wanted the devices to be able to call one another in case your (example) elevator needed to call the security desk which for some reason was still on analog. 

And once I got past that hurdle, I then wanted the analog device to be able to call anywhere allowed by a voice policy, to include the off-hook dialing being able to contact a third-party security provider if necessary.

Setup

So, here are the elements needed:

  • an analog phone or phones
  • a media gateway of some description
  • Lync voice policy
  • Lync analog device configuration
  • Some method of connecting Lync Server to your PSTN provider (I used a SIP trunk as mentioned above via an SBC)

Here is how it looks:

image

Configuration Tasks

This is what it takes, configuration-wise, to accomplish our goals:

Determine what LineURI the analog phones will use, and if you are going to assign full numbers to the analog ports or just an extension.  I am doing 4 digit extensions.  My two analog devices will be +19992349011 (port 1) and +19992349012 (port 2).  Then get a valid IP for the gateway.  I will be using 1.1.1.9 for the MP118.

  • Setup analog devices on MP118 per port
  • Configure Proxy set zero for “prefer routing table”
  • Setup/Configure off hook dials to specific number
  • Configure analog call analog digits to dial 12
  • Setup MP118 on Lync as PSTN Gateway
  • PSTN Usage, Route, Trunk configuration
  • Configure Lync to call analog device
  • PSTN Gateway, PSTN Usage, Route, Trunk configuration
  • Configure csanalogdevice to allow off hook dials to a public number

Let’s dive in.  I will be grouping the Lync tasks together and grouping the MP tasks together as well.  The Lync environment can already call the world, so nothing is needed there.

MP118 setup

After you get the gateway plugged in to power, connected to your switch, and hook the phones up to it, the MP118 should look something like this.

image

Note:  in AudioCodes-land, at each screen, if you make a change, you need to “Submit” the change, or you will have a nice surprise later – namely, your change won’t be there like you think it should be.

Open up VOIP | Control Network | Proxy Sets Table, and modify Proxy Set ID 0 (that is zero).  You can see my pool name listed there, and the options to get the MP to respect the DSN load balancing.  Note the port assignment tacked onto the end of the FQDN.  If you don’t do that, you won’t get very far.  My method is going to leave the IP Group Table undefined.

image

Here is the SIP definitions that match my Lync environment.  Note that OOBE for the MP is to have 5060 where you see 5068.  Again, if your Lync is using 5068 (the default) for Mediation Server, then you will need to change these to match, or again, you won’t get very far.

Under SIP Definitions | Proxy & Registration, note that we are using the default proxy, but to get the analog ports to talk to each other (a bit later) we will change this a bit now, If we want to route all calls, even intra-gateway calls, to Lync, then leave this alone, or, you can set the “Prefer Routing Table” to “yes” now. If you set this, Lync will not know about the intra-gateway calls – meaning there will be no CDR for the calls in the monitoring database.

image

Moving to GW and IP to IP | Hunt Group, here are the ports defined, and you can see where I am using 4 digit extensions.

image

I think my Hunt Group Settings are the default…

image

Now look at the Tel to IP Routing.  The “Dest IP Group ID” of ‘-1’ means use the internal default.  Which is the default Proxy Set 0 because we defined a Proxy Set 0.  So, now you know why we told the MP to prefer the routing table…which is right here.

image

If you don’t do this, the MP will route ALL calls up into Lync.  If you route all the calls up into Lync, then Lync will need to be told to send SOME calls back to the MP  - so it can get to the other defined ports on the Media Pack. This might be the desired behavior if you have a need to get a record of all calls – necessary in some compliance environments.  A little bit later, we are going to be doing a configuration with Lync that will allow this loop-back routing, and if you decide to go that way, you can do away with the “prefer routing table.”

In the IP to Hunt Group Routing table, we need to tell the MP to accept incoming SIP invites from Lync:

image

You are remembering to click on those pesky submit buttons, yes?

OK.  Almost done with the MP setup.  Go to the Analog Gateway | Automatic Dialing settings.  Here we are telling the gateway that if Port 1 goes off hook, then wait 5 seconds and proceed to dial 800-468-7827.

image

And lastly, let’s get the analog phones to dial 12 digits so they can call out for pizza.  You can find the “Max digits in Phone Num” field in the “DTMF and Supplementary | DTMF & Dialing”

image

You can still dial just 4 digits, but you will have to wait for the 4 seconds defined in the “Inter Digit Timeout (sec) parameter before the gateway will stop expecting more digits and move forward.

OK, the MP is done.  Click on that Burn button up at the top and let’s move on to the Lync 2013 configuration.

Lync 2013 Setup/Configuration

You will need to define the MP as a PSTN gateway in Lync.  Without going into the grisly details shown in the hyperlink, here is my Topology Builder for Tsoorad.net:

image

After you get that defined and published, open up the Lync Control Panel and go to the Voice Routing tab.  We are going to need a few things, like normalization rules, a route definition, and a calling rule on the trunk so that Lync only sends 4 digits to the gateway.  We could define the gateway ports as full 11 digits, which would do away with the need for the called party translation, but I like to be difficult.

Here is the normalization rule that takes 4 digits that start with 90 and makes it into e.164 format:

image

Now we need to have a route.

image

and assign that route pattern to our 1.1.1.9 trunk/gateway, and make sure the local PSTN usage is associated so the route/trunk becomes an active component.

image

Moving over to the trunk configuration, we need to create a called number translation rule so that the trunk strips the e.164 down to just the four digits that gateway is expecting. You might need to create the trunk.  In my case I made a trunk at the pool level, and it looks like this:

image

image

and the called number rule looks like this:

image

At this point, Lync can call the media pack gateway ports, the gateway ports can call Lync, or each other and all is good in the universe.  But we still want the media pack gateway port to be able to go off-hook and call an outside party, right?  The reason it cannot do that now is that Lync does not know just who that user at 9011 or 9012 is, or whether or not that user is allowed to make calls to anywhere.

To get an analog device to accomplish this dialing behavior, Lync needs to have some definition.  Enter the cmdlet new-csanalogdevice.  I will wait whilst you catch up on your reading.

Now, that wasn’t too bad.  There won’t be a quiz, but just to give you a flavor of the test that COULD occur, here is my two analog devices defined in TsooRad.net:

image

Note that I defined the common name, LineURI, and maybe more importantly, the DisplayName and DisplayNumber – because once you do this, things start displaying like this in all your other clients.  I also made a point of defining a SIPAddress – otherwise you get a contact object with a GUID as a SIP address.  Not so hot.

Dialing 9011 in a Lync client shows that the call is being sent to “MP118-1” and your trace logs will show the same.

image

Big note

I started off this exercise using tel:+19992349011;ext=9011 format.  But empirically, the media pack gateway did not like getting the ext= format – it could not find a match for that.  I don’t know why.  What I do know is that once I removed the ext= format, calls went through as expected.

These two CsAnalogDevice definitions are showing no VoicePolicy and no VoiceRoutingPolicy.  Remember that we have things defined at the site level?  Well, these CsAnalogDevices will now act just like a real user.  The absence of a defined user policy will result in the object getting the automatic site settings for Voice Policy.  Because I have this set to allow all my critical test users to make any call they want, the analog devices can make any call they want also.  You may want to think through the implications of that for your environment and make appropriate changes. 

These analog device definitions are also what will perform the call loop-back function mentioned earlier.  If you need to have all your calls logged for compliance, leave off the “prefer routing table” mentioned earlier, and the gateway will send the call destined (for example) from port 1 to port 2 out to Lync.  Lync will perform a reverse number lookup, find the last four matching our 9012 definition, and place a call to that 9012.  Our PSTN usage in the default voice policy will allow passing the call to a route, in our case the 1.1.1.9 trunk, the trunk will strip the call down to four digits and send it.  When the call lands on the gateway, the gateway will look at the hunt group, find the 9012 number assigned to port 2 and connect the call.  Wala!

Summary

We wanted analog phones connected to Lync, make calls to other analog devices on the same gateway, call other Lync devices, call out to the world, and do automatic dialing as needed.  By making some judicious changes to the gateway defaults, and create some specific configurations inside of Lync 2013, we have accomplished our goals.

Footnote

This configuration may or may not meet licensing requirements vis-à-vis AudioCodes Lync Analog Device licensing.  It may also not meet some of the “best practice” recommendations that insist that Media Pack gateways always be connected to an Enhanced Gateway.  This is because some of the fancy features for Lync phones won’t work; however, my phones don’t seem to have transfer or conference call buttons, so I am not missing anything in the way of features.  You should check with your AudioCodes retailer to confirm your licensing level.

Mea Culpa

I am sure that there are many folks out in Lync-land that could do this setup in their sleep; those folks are brighter than me.  I had to consult Jeremy Silber (CDW) and Karan Mehta (AudioCodes).

YMMV

No comments:

test 02 Feb

this is a test it’s only a test this should be a picture