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

Stupid Lync Tricks Part Deux

In keeping with a previous post, I submit this:

Pick a screen, any screen, and share away!

Just be careful about doing “All Monitors” as this could create a serious eye-chart for the far side!

And, just for added ammo, at least one of these displays is a 4k.  Sweet!

YMMV

Lync 2013 Client Update “fixes” Meeting Join Failures

For those of us who are involved with doing Lync on-premise, one of the issues is meeting joins by outside/external invitees who happen to have Lync installed as part of Office, but don’t use it… which results in failing to join the meeting, which results in a help-desk call, which results in a call to us wanting us to “fix it” when nothing is broken.

<sigh>

Well, here is something that explains why this happens, and a recent change to the Lync client that may help resolve this issue with no action on your part.

http://blogs.technet.com/b/scottstu/archive/2014/10/30/lync-2013-now-supports-falling-back-to-the-lync-web-app.aspx

IMHO, this is a great move in the right direction.

Of course, you can always show your customer how to edit each and every meeting invite to include the ?SL=1 suffix…which is a crappy solution at best, but one that works. And then there are various Exchange-based transport rule fixes: however, this fix is a bit clunky in that it will insert a generic string;maybe not the one you want per user.  I had one awesome customer who wrote a custom transport agent that works, sorta…sometimes…and which of you out there has enough time for custom coding work that may or may not be successful.

Sure would be nice if Microsoft would simply put two links in the original meeting invite – so that it looked like this with the obvious link already having the ?SL=1 code entered…

YMMV. 

One Box 365

With the increased interest in Lync Online (part of Office 365, the online Microsoft offering), comes the increased interest in extending Lync 2013 Enterprise Voice to work with Lync Online.  AudioCodes One Box 365 can help you realize that objective in your organization.

Why is this needed?

Lync Online can operate in a split-domain configuration, with some users on-premise and some homed on the O365 tenant, but this is not a requirement. However, if you want to enable your users for Enterprise Voice, then the Lync environment MUST HAVE a Lync 2013 user pool located on-premise or operate in a complete hosted mode. If you don’t want the hosted mode option, then you need to deploy a Lync 2013 pool on-premise to augment your O365 tenant. This option will also require the “E4” license level.  Microsoft says this about O365 Enterprise Voice:

And if you do the hover thing over the little splat, you get this:

So there you go, you can use Office 365, but if you want to include the goodness that is Lync Enterprise Voice, you are needing to deploy Lync 2013 on-premise.  Using the Lync 2013 split-domain model requires setup and configuration on both the internal (or Azure, or both) Active Directory, needs some directory sync between the Office 365 tenant and your internal Active Directory, and also needs at least 2 servers internally, as well as various other servers, devices, and appliances such as SQL, reverse proxy, and telephony gateways.  To get a better idea, take a look at this and this.

And wow, does that sound complicated or what?  For an organization with limited technical resources, this might be a daunting task – and a concept that might well cause a re-think of the O365 idea.

What is One Box 365?

Aimed at supporting 200 users, One Box 365 addresses these concerns by offering the small(er) organization an appliance that has everything except call recording, reverse proxy, and the Web Apps Server (needed for PowerPoint presentations in a web conference) in (wait for it) One Box.  Tricky naming there, eh wot?  Here is the AudioCodes market-speak.

Based on the Mediant 800B Gateway chassis, and delivering all the wonderful packaging of the Mediant 800, One Box 365 has the following pre-installed, and ready to rock with minimal delay:

• Lync Server Standard Edition (Front End, Mediation, Monitoring – and Persistent Chat if you want it)
• Active Directory Connector
• Edge Server
• Gateway/SBC
• A really nice management interface that makes things a lot better than some others I have seen.  A LOT better.

With the Mediant 800 chassis, you can also get FXO and FXS, so your analog devices are covered also.  Connectivity to your telephony solution is pretty much limited only by your imagination.  Being as how AudioCodes has one code base, you get the industry-leading gateway translations as part of the bargain. SIP, TDM, POTS, E1/T1, PRI/BRI, AudioCodes has the connection part covered. I have yet to see a PBX that AudioCodes cannot translate. Here is the official language:

How does One Box 365 work?

Well, it uses electricity, but that is a subject for another time.  By syncing with Active Directory, One Box 365 provides the user pool services needed for your on-premise users and connects to your PBX or ITSP SIP trunk.  Simple, yes?  Here are the official deployment types.

Note that you can also deploy One Box 365 as standalone Lync solution.  But, wait!  There is more (like the ubiquitous TV commercial).  You can stack multiple One Box 365 units to achieve pool pairing or support more than 200 users.  Also, I have heard (from the usual “unnamed source”) that larger solution sets that support more than 200 users (with a single appliance) are “coming soon”.

At any rate, One Box 365 takes this deployment model – which is where the smaller business might start questioning the wisdom of using Lync Enterprise Voice with their O365…

and replaces a goodly portion with this:

Much better.

A few notes on my part

Active Directory is in the box.  If you so choose, you can nuke the pre-deployed option and join your existing Active Directory – but that is not for the faint of heart or technically challenged.  But, in my view, possibly a better choice than having the complexity of the “resource forest” model.

The current hardware configurations seem to be limited to a chassis with only 4 FXS ports, I would like to see more FXS (this could just be me), and if you want more than 4 FXS, you will most likely be looking at a MediaPack.

You might think that not having the reverse proxy and the Web Apps Server in the appliance would be a negative, but IMHO, most folks already on Office 365 have a reverse proxy deployed (they might not know it) and I have also seen a trend of users not “presenting” a PowerPoint file – they are sharing their desktop; so the Web Apps Server is not critical  - especially in the One Box 365 target environment.  I also hear – from the same aforementioned “anonymous source” that RP functionality might just be possibly, hopefully, “coming soon.”

Someone with an AudioCodes SBA (Survivable Branch Appliance) might wonder if the Mediant 800B OSN (Open Solution Network) card has enough resources to handle the One Box 365 load.  Fear not!  The regular Mediant 800B SBA OSN is powered by an Intel Atom n2800 at 1.86GHz with a spinning disk, while the One Box 365 OSN is an I7 Gen3 with 8GB RAM and SSD.  Should be more than enough for handling the supported load.

Summary

Office 365 requires a full Lync 2013 pool on-premise to support Lync Enterprise Voice.  The Lync 2013 model is referred to as split-domain (it used to be referred to as hybrid). One Box 365, as part of AudioCodes One Voice provides a single appliance with which to enable your users for Lync Enterprise Voice while keeping your Office 365 environment intact.  One Box 365 offers full integration and native support for all Lync 2013 functionality.  Each One Box 365 appliance will support 200 users, and multiple One Box 365 appliances can be used to achieve pool pairing or supporting bricks of 200 users – while whispers do exist of larger capacities being in the works.

Based on your business requirements, AudioCodes One Box 365 could be the solution for your organization.

As always, YMMV.

#OB365

Jabra Evolve 80 MS UC

I got back from a short conference trip to find a box waiting for me.  The nice folks at Jabra sent me a squeaky new Jabra Evolve 80 MS UC.

Here is the market-speak straight from some professional writer up in Jabraland:

“The Jabra EVOLVE 80 MS Stereo is a professional headset designed to improve concentration and conversations. Premium noise-canceling technology gives you peace to work in the noisy, open office effectively creating a concentration zone around you, so you can stay focused on the job. The speakers are built for style and comfort with leatherette ear cushions, and are specifically designed to reduce office noise. When combined with active noise-canceling technology, you get maximum protection against office noise. The concentration zone is completed with a busy light indicator that signals user availability to colleagues.”

And in the “Optimized for Lync” category: 

“The Jabra EVOLVE 80 MS Stereo is optimized for Microsoft Lync, providing instant “Plug & Play” installation for your headset. The headset works perfectly with your Microsoft Lync, so you can focus on the conversation.”

Blah, blah, blah.  Except that when you ignore the hyperbole, the Jabra Evolve is a very, very nice headset.  Can I go past “seriously nice” and maybe go all the way to the first ever Tsoorad 10/10 award?  No, nothing is perfect.  But I think I can go to 9.9.  Everything claimed by Jabra seems to be backed up with performance.

What I like

The noise cancellation is excellent.  And once you have it enabled (a switch on the bottom of the right ear cup) you can disable it with a press of the toggle switch in the center of the ear cup.  Very nice. 

The hype about the “concentration zone” is no BS.  Comfort is as good, or better than anything else I have used.  The inside of the ear cups did not give me the willies. The microphone boom doesn’t stick way out in front of your face.  Did I say these things are comfortable?

Audio quality is (searching for a superlative) really awesome.  I tried Pandora, real stereo unit, my iPhone, iPad, laptops, workstations.  In each case, the Evolve 80 performed much better than my Bose Quiet Comfort 2.  When connected to something that does two-way communication it just gets better.  The “Listen in” feature is slick.  Having a separate 3.5mm connector built right in is a great idea.

The Jabra busy light concept is … different.  The inline module has a center button, and if you press it, both the module and the headset light up.  This is separate and can be enabled without being in a call.  A virtual hideout.

The Jabra PC suite is nice.  I actually downloaded it and played with it.

What I don’t like

Pushing the inline module mute button does indeed mute. Rotating the microphone boom up mutes also.  I would prefer a button or touch point or something on the boom or ear cup to do the mute.

Weight.  I understand that to get this thing to the high level of goodness that the Evolve 80 does indeed demonstrate, that a certain amount of weight is needed, but I can also see where this might be off-putting to some folks.  When my principal tester (my SO) first put them on, that was the very first comment.  That and the headband pushed into the top of her head.  *I* did not notice the headband issue. This will NOT get in the way of me using this headset – just something to which I will need to accommodate and in no way impedes my previous comment regarding comfort.

Conclusions

The Jabra Evolve 80 is a great awesome wonderful seriously nice piece of work.  You can get one right here.

YMMV

Jabra Goodness

Let’s face it.  The reason there are so many headsets on the market is because everyone’s head is different.  Personally, I like a nice stereo (Binaural to be technically correct) headset that is DECT.  Wireless to the base, USB to the workstation.  Great range.  For those long conference calls this technology can only be beat by not calling in.  I can get up and walk around, get coffee, and get tasks done while monitoring the call.  Using wide-band, my DECT has at least 200 feet of test range.  So, based on this foreknowledge, I played with a few Jabra headsets lately.  Remember that my existing DECT is the gold standard.

Jabra BIZ 2300 USB Duo

Such a title for a simple headset that has great audio quality, excellent comfort, and zero effort plug n pray.  I think the VOLUME was a bit lacking, but cranking up the sound card fixed that.  Adjustable boom mike.  What appears to be pretty good sound canceling.  Folds flat for storage.  Optimized for Lync.  Nice set of workable controls on the inline cord module. Here is the market speak straight from Jabra.

I chose this item for test because it hits right where I work.  As a 50% travel, I live with Lync as my communications center.  On the road, you need some tough stuff; it is going to take a beating.  Take a look at that market-speak, I have to agree with all of it.

Lync

  Oh yes.  Well, I got nothing.  I plugged it in, and it worked.  Perfect. You could not ask for more.  You can get one right here.

Adelante.

Jabra Pro 9465 Duo

Oh Wow.  Here is the market-speak.  I will repeat.  Oh wow.  What a great piece of gear.  Just running through the setup makes you appreciate what went into this great unit.  Right at the moment, the 9465 is playing headset to one of my lab common area phones, doing BT to my iPhone, and is also connected to my lab laptop as the preferred Lync headset.  All at the same time, all seamlessly, all at the same time.  WITH NO READING ON MY PART.  The dedicated reader will know my aversion to reading device documentation (the precept being that the average user will not read the documentation either). From hooking this unit to power, it presented, in color, a walk-through for setup that was PERFECT, and I hooked it to three different devices.  The 9465 even has a “phone home” feature that configures the sound on the base unit based on the deployed environment.  So nice.

The Jabra marketing professionals came up with this:

The PRO 9465 Duo offers the ultimate in connectivity. Specifically designed for executives, managers and other professionals, this headset enables employees to connect with their mobile, desk and softphone, simultaneously. The microphone features advanced noise canceling technology, enabling clear, understandable conversations for your employees and customers.

While I usually decry marketing types as overblown hyperbole (is that redundant?  can you have overblown exaggeration), in this case, I quoted it so that you can see what I don’t want to take the time typing.  And I agree with the content and intent.  ‘Nuff said. 

Lync

Seamless.  Plugged it in and it worked.  What a great piece of gear. I like it, I like it, I like it. You can get one right here.

Jabra Pro 930

Here is the market-speak.  According to Jabra, the Pro 930 is “…Designed for PC based telephony and Unified Communications systems…A professional, wireless headset optimized for Microsoft OC and Lync.”

DECT, with great range.  Excellent audio quality.  I tried this one because it comes with the ear-hook-thingy that gets rid of the headache-making single ear head band.  Ouch, I hate those.  I hate them even more than I hate one-ear setups.  But, being the even-handed type that I am, I figured I would at least try it before I dissed it.

Following the assembly instructions proved to be my only out for assembly – I failed at figuring it out.  Admittedly, I did not try to hard; maybe a few minutes before I decided that it had to be a press-fit, and then I read the documentation before I broke something.

As a personal note, I did not like the one ear angle of dangle when I had it up and running and actually using it.  It just did not feel “right.”  I tried doing the wiggle and reposition techniques, but in the end, I never got comfortable with being only on one ear.

Lync

Hooked right up and started working.  What more could you ask for?

Summary

All three of these Jabra units are solid, top-of-the-pack choices.  You could do a lot worse.  Solid design, high quality build, great feel, excellent performance.  Jabra even has some spiffy software you can download to keep things easily configured and the base unit firmware updated.

YMMV.

Lync 2013 Edge Hairpin

Many thanks go to Chard Johnston (AudioCodes), and Jeremy Silber (CDW)

Scenario

The project was Lync 2013 Enterprise, two sites, full HA, DR, and call recording using AudioCodes SmartTap. The edges in both sites were DNSLB.

The Symptoms

Once we started making more than a few calls to external numbers, we noticed that the SmartTap was not recording as expected.  This caused a few calls to the helpful AudioCodes support engineers.  It turns out that SmartTap does a little call-redirection magic, and captures all the necessary traffic to record both sides of a phone call from the edge servers.  And when one user lands on Edge1 and the other user lands on Edge2, we start seeing calls failing.

We were also failing regular calls between Lync users that used the Edge servers.  Same symptoms.  Calls would start, then fail when the time came to establish media.  Needless to say, this was not good.

Interestingly, this problem has been around for bit.  Jeremy Silber has an excellent article that outlines the problem, the cause, and the fix in explicit detail.  Even better, if you talk to Jeremy (I happen to have direct access) he can translate the contents of that blog into English!  Highly recommended reading. Having it translated to English so that either of my brain cells could comprehend was priceless.  Firewall rules had been through the change order process at least a month ago, so we thought we were good there.  All previous testing had been good.  But we had not tested voice/video yet.

What is going on here?

I had a heck of time getting those firewall rules in, not at the technical level, but at the explaining the “why” in English.  So to get my skills up to speed, I discussed the issue (and the fix) with Chard Johnston of AudioCodes – seeing as how he was buried in trying to get SmartTap working correctly.  After I showed Chard the hairpin requirement – see previous reference to Jeremy Silber – Chard went to Microsoft using his channels.  Apparently this discussion went on for a bit. Chard came back and created the following diagrams.

 

 

Why is this needed?  Well, if you look back at Jeremy’s blog, you will see that the candidate pairs that are exchanged between the users don’t have FQDN, they have IP.  And, done correctly, the IP will be that of the EXTERNAL PUBLIC IP of the AV service per edge.  So, the firewall must allow traffic from one public IP to simply hairpin back to the other edge public IP.

Remember that while SmartTap highlighted the issue, it was a firewall configuration that was the real culprit.  If we look at the reference article in the Lync 2013 documentation, we don’t find the requirement for the Edge server AV service to talk to the other edge pool server AV service via the public IP address.  Once you know the requirement exists, the information is there if you read between the lines a bit.

In the end, the requested firewall rules were not implemented correctly, so we had some one-way conversations going, and some quick adjustments by the firewall team had everything ironed out.

YMMV.

Lync 2013 SIP trunk with a twist

Scenario

Maybe like me, you have a split environment with an Lync 2013 EE pool, with a Lync 2013 SE, and you want to get a SIP trunk installed so that you can play with pilot Dial in Conferencing and maybe some light Enterprise Voice?  The guidance on direct SIP trunks is to stand up a separate Lync 2013 Mediation Server.  You can read up on that right here.  The mediation server “strong recommendation” is here.   Be that as it may, you might decide that it would be a more efficient usage of resources, especially for a pilot, to use the Lync 2013 SE as your mediation server.  And using a internet-based SIP trunk provider will get you the most bang for the buck albeit at the expense (maybe) of reliability.  I personally have had great results using internet-based SIP trunks, YMMV.

After reading up a bit, you realize that you are going to need a non-routable IP added to the Lync 2013 SE to make things work.  Why would you need that?  In my case, the internal subnetting and security was such that the SE needed another subnet to work with – security would not allow an unsecure connection ( a SIP Trunk straight to a production network server with no SBC on-premises).

How to

As luck would have it, Intelepeer – for a wide variety of reasons, my first choice for net new SIP trunks in an environment – was willing to work on a semi-custom plan to get our pilot up and running.  SIP trunks in Lync 2013 did not change much since Lync 2010, so we can use this guide from MVP Brian Ricks to get the basics accomplished.  Another MVP, Curtis Johnstone, has another SIP trunk article that is well worth reading.

Before you start though, what about that need for a mediation server?  In our scenario, we need to arrange for another NIC/IP on that SE so the mediation server can have a separate subnet.

This blog entry from Norway will walk you through what to do for the second NIC/IP needed. The sharp-eyed reader will note that the NIC setup looks like an external interface for a Lync Edge server.  Moving forward, you will need make up some firewall rules to get the requisite SIP call setup (TCP) and media flow (UDP) between your new mediation server NIC and the service up in SIP trunk land.  Depending on the firewall, you may want to double check to make sure that the NAT you setup is taking your mediation server traffic and sending it out the correct address.

While you may not have an SBC on-premises, you can be assured that the SIP trunk provider is going to have one, and that SBC will not communicate with an IP that is doesn’t have defined in the trunk setup.  I strongly recommend creating a group in your firewall, and restricting your SIP trunk traffic (that leaves your firewall) to only communicate with the provider.  1:1 NAT may not be possible on your firewall (why I cannot imagine, but there you go) so that is something you may want to consider before getting started.

Here is what we need:

The Results

Right out of the box, setup using the given guidance, outbound calls work, but would never disconnect if/when the called party hung up.  Inbound calls just failed. Turns out that there were two things, one Lync and one Intelepeer.

Lync

Based on this bit of Lync 2013 documentation, the “Centralized media processing” needs clearing.  In our case, Intelepeer is using TCP on one IP and UDP on two others.  Hence, clear the box.  In this case, we were also doing no encryption and Intelepeer basically told me that support for “Refer” ain’t there yet.

Intelepeer

On the Intelepeer side, their SBC was looking into the packets, finding the IP of the outside of SE/Mediation server (10.10.10.62) and trying to send SIP signaling traffic to that IP.  Obviously, that would not work.  At any rate, the Intelepeer engineer (a most helpful fellow) twiddled some bit on his end, and wala! Instant telephony in and out.  Fabulous.

Conclusions

If you need a path through a network maze, you can come up with one.  In this case, we needed to allow for the Security Mavens to have their (understandable in this case) way, and still be able to provide Lync with a SIP trunk to pilot Dial-in Conferencing and EV.  Total time that involved actual network and Lync hands-on touching?  Maybe two hours total over several weeks.

YMMV

Duplicate IP error

Just ran into a little something I have not seen in a long time. Building edge servers with Windows Server 2012R2 and the external NIC kept coming up as duplicate address. Doing all the cross checking showed that the server had only two interfaces and that they were configured properly. Turns out that this little gem from 2008 R2 days is still valid:

http://social.technet.microsoft.com/forums/windowsserver/en-US/d7bda315-6366-4e0a-bdcf-dc875ff6963e/win-2008-r2-servers-will-not-connect-to-network-says-duplicate-ip

The firewall doing the NAT to the public IP was ASA. The registry change for disabling gratuitous ARP fixed all of the my edges.

This might be of interest also:  http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1028373

YMMV

Frontier FIOS and static IP

Background

About four months ago, I made the decision to extend my lab, Tsoorad.net, out to the larger world of the internet.  I have several reasons for wanting to do this; most of them selfish, but a surprising number of them are for client testing purposes.  I need/want to implement a full SBC for a SIP trunk, which leads to needing a SIP trunk, et cetera.  So for this exercise I need more than one (1) static IP.  I could probably figure out a way to futz with ports per service and get something worked up, but I want to be able to duplicate customer scenarios.  Internally I have plenty of network.  Externally, I need a static IP configuration.  And with needing at least three IP externally, the logical choice (see how I justified all that?) a /29 seemed to be a good fit.

Enter Frontier FIOS

I have been a fan of FIOS since the halcyon days of Verizon replacing my DSL with fiber to my house.  Awesome.  None of the crap that you put up with if you use cable.  I don’t share my bandwidth with the rest of the neighborhood.  Nice and consistent on the speeds up and down.  And the 15/5 package is more than sufficient for my 2 person internal domain and my lab domain. 

But, it turns out that FIOS has this ONT thing (Optical Network Thingy)(actually, Optical Network Terminal) mounted to the side of the house.  Which leads us to the The Problem.

The Problem

On the Frontier side, the sales folks sold me.  I know, I should have been smarter.  I should have known.  Sales types around the world have a mantra:  “yes yes yes, please sign here” and they are compensated on their ability to get the signature.  I get it.  But I hate misinformation. 

Knowing that I was going to need at least three of the /29 workable, asked the obvious (and brilliant) question: “Will the Frontier supplied router be able to handle a /29 or will I need my own firewall/router?”  I should have heard the alarm bells go off when I had to explain what a /29 was and why I was asking the firewall/router question.  But, I was assured, by someone who assured me that they worked on the business provisioning side of things, that the router supplied on the install would handle the requisite services.

NOT!

When the Frontier install tech showed up onsite, he expressed his doubts.  But, armed with the knowledge (however faulty) of the sales professional, we moved forward.  The actual connection part was easy.  When I first moved in, I had the technician run Cat5 from the ONT to the internal drop.  There are pluses and minuses to this approach.  But seeing how I could care less about the TV service (I use a popular satellite vendor), using an Ethernet drop versus coax was a no brainer.  As it turns out, a necessary one as we shall see.

Firstly, if you have coax to your local demarc, then you will need to use the Frontier-supplied router/modem.  The Frontier-supplied unit, an Actiontec MI424WR, certainly LOOKED like it should handle things.  In the network definition section in the setup, there is a place to put in IP’s, and it would take the full definition complete with mask and gateway.  But, we could not get more than one address working.  At one point we had a second address working, but it abruptly quit after a few hours.  For reasons we shall see, this was caused by the ONT and in the end, had the Frontier Tier 1 non-help desk been more informed and less script-driven, I might still be using the ActionTec.  You see, the problem, while it appeared with the original Frontier-supplied router, might not definitely indicate that the ActionTec won’t work.  However (on the flip side) I did have a longish chat with an Actiontec “engineer” who blithely told me that their router would only do 1:1 static NATs, and not dynamic 1:M NAT.  I am also not sure if the Actiontec would be able to do 1:1 AND 1:M NAT at the same time.  I suppose that particular test will be done at some point in the future when I am snowed in or can’t sleep at 0230.

Adelante!

Next, having proved over and over that we could get all 5 IPs working off a switch on five different pieces of gear, and all at the same time, we started looking at how the network was delivered from the Frontier side of things.

<Cue creepy techno-vibe music from CSI with lots of tracert, pathping, and telnetting with multiple interfaces on different machines for configuring the various firewalls and other appliances>

Back to the Frontier Tier 1 non-help folks who (reading from their script) had me retest everything again, and then proclaimed that I had a DNS issue.  <sigh>

Over and over this went.  Then it turns out that the network technician who was advising the Tier 1 person was reading from the standard, world-wide network engineer script that goes something like this:  “Everything is good here.  You have a problem.”  And the idiot user (me in the case) is not allowed to speak directly to the actual network technician – so you have this wonderfully frustrating back ‘n forth between the idiot (me), the non-support Tier 1 person, and the network technician who blindly insists that all of their gear is provisioned correctly.  Because I was asking for support for something that was not common to their network, this entire effort failed because I was off script.

This went on for several months.  In that time I tried, in order of implementation, the following firewalls:  Cisco PIX 515e, Cisco ASA 5520, Cisco ASA 5505.  Nuttin’!  All this time, each time I called for some more non-help to be told how everything was peachy on their end, but gees, maybe you could clear your ARP tables please, I was told how the issue had to be on my gear being misconfigured.  Now, I am not in any fashion a Cisco ASA expert.  But I have some knowledge.  So when it came to about 1/2 way through the 5520 efforts and for ALL of the 5505 efforts, I trotted out the hired guns.  Namely a completely certified (he is really out there) Cisco dood – who lives and breathes Cisco security as his primary job.

As a side note, this guy was awesome.  But clearly, in the end, he was clearly puzzled as to why what works for the rest of the civilized world refused to work for the TsoorRad environment.  And he did this several times.  We had nothing wrong.  My network is solid.

The Fix Begins

At about this time, I am starting to doubt my sanity.  Stupid thing should be working but it is not.  I think that I have eliminated any possible error on my side – Yet Frontier network techs still insisted that there was nothing wrong on their end.  However, if you read some of the material to be found online which I magnanimously have provided here:

http://www.dslreports.com/forum/r23683580-Does-the-ONT-have-its-own-IP-address

http://www.dslreports.com/forum/r27214458-Number-of-internet-IPs-on-FIOS-

http://www.dslreports.com/forum/r27022337-Cisco-ASA-5505-with-FiOS-Multiple-IPs-WORKING

http://www.dslreports.com/forum/r21956488-northeast-Proxy-ARP-with-FIOS-business-static-IP

http://www.dslreports.com/faq/verizonfios/3.0_Networking#16077

…you can see that I am NOT the only one.  However, in defense of fairness, in some of the research the firewalls were called into question.  So, I will try one last time.  I purchased a NetGear FVS318G.  Same results as before.  I then discovered a piece of the Frontier website that allowed me to find email addresses for executives in my area.  So I fired up my email and sent a politely worded notice of my dissatisfaction.  Several.  But the first one got serious attention.  So the buck does stop somewhere. 

So now I have Frontier calling me, managers, technicians, and technician supervisors all have been told to fix this.  About time.  But guess what?  The network team on their side is still insisting that their configuration is perfect.  Here is a little blurb of the back-n-forth:

“…the ONT cannot (empirically) deliver the entire /29 all at one time to one device such as a firewall.  This is not acceptable. 

It would appear that something in the ONT is not able to send the entire /29 block to one device.  I have now used 4 different firewalls, ranging from bottom end business class (netgear fvs318g) to industry standard business class firewalls (PIX 515E, ASA 5520, ASA 5505) and they all do the same thing – specifically, the devices work just fine on one IP address, but the ONT fails to deliver the entire block to the single device.

I think that the ball is back in Frontier’s court.  Something must be able to be done to the ONT to bridge my entire /29 to the Ethernet so that what I paid for, namely business class service, is actually delivered to me.  Bridge the ONT, tell the ONT to handle multiple IP’s, upgrade the firmware on the ONT to do this, SOMETHING…”

The Fix is IN

As it turns out, the ONT not being able to deliver all the addresses was the issue all along.  While I cannot get direct information as what EXACTLY was done, my service now works with a complete /29.  Somebody up in Frontier-land did something to either the ONT (several folks did several things, all very hush-hush) and then an upper-level regional engineer did something to the upstream router (from my service perspective) and magically the NetGear FVS318 is cranking on all five cylinders.  I cannot verify the regional engineer thing, it was only mentioned once, and then when I enquired about it again the subject was changed very quickly.

Here is what Frontier told me was the issue:

“Our Gateway Router sends out an ARP request every 6 hours or so to see if the same MAC address is still using an IP address.  It sends it out on 0.0.0.0 and if it does not get a reply, it shuts down that IP addresses' ability to get online.  The reason this happens is because many firewalls identify an incoming request on 0.0.0.0 as an attack.  So the Firewall sees it and then discards the packet.  The discarded packet never gets back to the Gateway Router, so the Gateway Router in essence says: don't let this IP address get online, I cannot verify the Mac Address.

At the time you were experiencing this problem, we were introducing a new optical network terminal (ONT) into our network; Calix.  It operates much different that the way the Alcatel Lucent system operated.  We plan on exclusively using the Calix ONTs for small business customers where it has been added, which is about 95% complete in the Oregon FiOS markets.”

Conclusions

1. Remember the Actiontec that did two addresses but then quit?  IF the ONT is configured correctly, maybe, just maybe the Actiontec CAN handle a /29 like the original sales person stated?
2. The ASA is a multi-talented device.  Dang did I learn a lot.  But in the end, not able to work for me.  My buck-twenty NetGear POS is working just fine.  Complete with SIP trunk.
3. Frontier has assured me that the process has been changed as any business-class (fixed IP) service will require the new Calix ONT (mentioned above).
4. Sales types are a necessary evil.  Business doesn’t work without them.  Caveat Emptor.  Be educated for yourself.  I don’t know if I could have done anything different, but I will be thinking about it for future actions.
5. When I got ahold of the correct layer of responsibility inside of Frontier, things went very smoothly, and I was treated much differently.  Like maybe I knew just a little of what I said.
6. Network technicians need to learn to look a tad past the CLI on their screen and stop assuming that “everything” is correct on their side of things.

In the end, I am happy, but I sure wish this had not taken so long to resolve.

YMMV

Lync Mirror RPC Server is unavailable

Don’t ask me why, I just know what I did to work around it.

Situation

I was engaged in establishing a database mirror for a new monitoring database for an established Lync 2013 CU4 EE pool.  When it came time to publish the topology and install the new databases, the mirror refused to instantiate with an error of:

An error occurred: "System.Runtime.InteropServices.COMException" "The RPC server is unavailable. (Exception from HRESULT: 0x800706BA

Lovely, eh wot?

The Fix

The SQL server version for all three servers in question is SQL 2012 SP1. I went through the usual routine of checking the services, the firewall rules, the rights and permissions on the SQL primary, mirror, and FSW.  All of that looked as it should.  Here is a good outline for you to follow should you need it.

What fixed it for me?  We turned off the firewall for all interfaces on all three SQL servers.  I know, but don’t ask me.  After the successful mirror activity, we turned the firewalls back on for all interfaces on all three SQL servers and everything seems to be happy.

Go figure.

YMMV

SharePoint Foundation compatible application could not found

 

Do you get these zippy error messages when you try to open a document in SharePoint (or should I say non-SharePoint?) and are thoroughly confused as to why it worked the other day but not today?

I got these errors today, so off to UofB and UofG to find an answer.  Searching on the phrase “edit document requires foundation” or “The document could not be opened for editing. A Microsoft SharePoint Foundation compatible application could not be found to edit the document” which were two of the other error messages I got resulted in a boatload of links both MS forum and other locations. 

These links were full of advice - all of which failed.  Towards the end of my search I found a spot that mentioned doing a full repair.  I thought  - “maybe, but I just (stupidly) ran Windows Update the other day and ran about 30 updates in – which included a bunch of Office 2013 updates” and the last part convinced me that I had nothing to lose.  So off I went and did a repair.

Voila!  My sacred OneNote file is now able to open and sync and be edited.  WHY? 

I don’t know what caused this, but I suspect, as it was working a while ago, that the updates the other day borked things up somehow. If it matters, I am running win8.1x64, Office 2013 x64, and a variety of other crap that is both Microsoft and other vendors both x86 and x64.

YMMV