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:

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.

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.

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.

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.

I think my Hunt Group Settings are the default…

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.

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:

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.

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”

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:

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:

Now we need to have a route.

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.

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:

and the called number rule looks like this:

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:

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.

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

Lync Conferencing Cost Analysis

I think that I can confidently say that 100% of my Lync deployments (and most of the OCS deployments) contained the concept of using Lync web conferencing; most times with dial-in conferencing.  The idea is that the organization can save money by replacing an existing solution.  But most times, the organization has little or no idea how much, and why, they can realize savings.

So, here is some real data to digest, tear apart a little, and see what and where we can generate some savings.  This data comes from a company of about 3500 users.  So keep that in mind as we work along.  A smaller organization will have smaller numbers, larger organizations will have larger numbers.  I have customers whose conferencing minutes run in excess of 7 figures each month, and they don’t just squeak over 1 million, they run in the several million per month. 

A bit farther down, I make a fairly broad assumption that our imaginary organization could implement Lync for $60K.  Before you poo-poo that number, do some math on your own for an Enterprise Pool of three Front End servers, two edges, a SQL server, a Web Access Server, and we’ll be nice and assume load balancers can be used for Reverse Proxy and that the load balancer already exists.  Go ahead and do some figuring.  Make sure you pony up for about 160 hours of consulting, because you will actually save money doing that also.

Because not everyone will have the same cost basis for things like hardware, software, labor, services, and a whole range of stuff, we are going to ignore those concepts in this analysis, and just focus on service replacement and cost avoidance as it applies to the usage of the services, not what is costs to put the services into place.   We will use a flat cost assumption down below to represent this cost category.

Let’s Begin

So first we need to understand the data. I did not just dream this stuff up; I got this data from a real life deployment, with real life users, doing real life tasks.  I used Lync’s monitoring server and related reports to generate a summary of conferencing data over a 30 day period.

and

Based on the data given for a one month period, and then comparing the data with the report descriptions for Conference Summary Report in Lync Server 2013 and PSTN Conference Summary Report in Lync Server 2013 we can reach several conclusions.  Before we talk about conclusions, we will wait while you complete the reading.

First off, the PSTN usage reports appear to be a subset of the Conferencing data on one hand, but then appear to be totally separate data on second look.  For instance, both reports have a column for “Total A/V Conference minutes.  For the Conference Summary Report, this value is 85,572, for the PSTN report, this value is 72,135.  OK, so PSTN appears to be a subset of Conference Summary.  But wait, maybe not!  In your reading assignment up above, note that both reports have this data, and that both describe the data to be the same.  Should this be the case, then we could expect both reports to have identical data, yes?

Name	Can you sort on this item?	Description
Total A/V conference participant minutes	No	Total amount of audio/visual participant time. For example, if one participant spent five minutes in an A/V conference and another participant spent three minutes in the same conference, the total A/V conference participant time would be eight minutes.

But such is not the outcome we see.  In fact, the two fields differ, in our data set, by over 28,000 minutes.  The difference is to large to be dismissed as a rounding error; clearly, there is a separate set of data being represented, OR, the descriptions for each report are wrong.  Digging in a bit deeper, we can find two days where the data indicates that the PSTN report reflects those conferences that INCLUDED PSTN connections; therefore; the number in the PSTN report are, in some cases, the same as the Conferencing Summary, and in other cases are just PSTN minutes.  Confusing, but there you go.  But still, understanding the layout of the data enables us (finally) to make some (semi-) educated judgments on what the data means for our business cost and how your organization can save money by using Lync for conferencing.

OK, here is the data in question, and yes, it is an eye-chart:

 

What’s the big deal?

Conferencing hosts charge per subscription, per connection, and for the minutes per user. This means that when someone creates a conference they need a subscription that allows them as a user to create the conference, then each user who connects to the conference incurs a connection charge, and then the clock starts on everyone, individually.

Per user charges run all across the board, so we won’t attempt to quantify that; suffice it to say that it can run from zero to about $0.30.  A 10 person conference just cost $3.00.  And per user minutes can run relatively cheap to 5-10 cents per minute.  Clearly there is money to be made, or saved.

After consulting with my friends at Intelepeer, I think you could get the per minute cost down to $0.015 per minute.  And if you go with a toll free number on a negotiated plan of some sort, you may just be paying for the minutes.  Seeing as how most organizations already have a SIP trunk in place to provide the PSTN connection, we can ignore that cost as well because the cost is already sunk to provide regular calling services.

We can see from the data that a majority of the conference minutes (208k of 314k) were PSTN minutes.  Maybe some user training would result in more Lync conference joins to avoid those minutes, eh?  But still, if we have a $0.02 per minute rate for each participant, and assuming a $0.05 rate from a popular provider plan, we just saved $6265.08 this month.  We will wait whilst you break out your calculator to confirm my math.  Over the year, assuming our numbers are the mean rate, we are talking $75K for the year.  Nothing to roll your eyes at. 

Connection fees are something else.  And not having hard numbers from providers makes a tough analysis.  But we can make a few broad conclusions based on the data set.  Assuming a mid-pack connection charge of $0.15, our sample data just saved us 21,637 connection charges for a nifty $3245.55 and keeping with the mean stance, $38K for the year.

And what of the subscriber charges?  Conference hosts usually charge an additional fee to allow your users to be conference organizers.  This charge depends on the plan.  Our sample data shows 201 unique conference organizers.  I have no idea what those charges might be per negotiated plan – suffice it to say that you need to know that a typical plan is audio only, doing video and having a web conference service on top will cost you more. Here is a typical audio only plan layout – web and video will schlank you for more. You can also see that I have been conservative in my cost numbers.

The larger your organization, the more likely you are to be able to get around the “per organizer” fees, so for our purposes, we will ignore that cost argument because we know how great everyone is at negotiating separate contracts.  But for talking points, those 201 users could easily cost about $19/month each, another $3819 per month; $45k for the year.

Conclusion

We did ignore the costs associated with servers, licensing, and connections.  And if you use a service provider to help you develop your architecture and design your Lync environment there will some other costs.  So let’s make the assumption that $60k will get you your servers and licensing and a friendly, knowledgeable Lync consultant to figure out your environment and get everything installed and configured.  We will assume that existing infrastructure will provide VM resources, storage, data connections, load balancers, and firewall protection.

Our sample data showed some 314K usage minutes of which 208K were PSTN.  Based on some rudimentary number crunching, I think we determined that our sample organization can save $45k in subscriber fees, $38k in connection fees, and $75k in per minute fees.  Saving $158,000 a year ($13,166/month) is nothing to ignore.

Remember that we did not price out anything but audio conferencing. My $60k figure would get you audio, video, and web conferencing. You may rightly assume that someone needs to keep this thing operational – a hidden cost that is hard to quantify.  In my experience, I think that doing Lync administration is maybe a .25 FTE, depending on the size of the deployment. So, being really generous, and hoping to sabotage my own ROI results, we will call that .25 FTE as being equal to $25k.  That will run our first year costs for Lync all the way up to $85,000.

Depending on your install base for Lync, the ROI for installing Lync 2013 just for conferencing alone might be less than 12 months.  In our example, and using our assumptions, the ROI is 6.5 months.  Using Lync as your conferencing solution has the prospect of allowing your organization to avoid some significant costs.

Have you done your own research?  Do you have your own data?

YMMV