About Me

My photo
TsooRad is a blog for John Weber. John was a Skype for Business MVP (2015-2018) - before that, a Lync Server MVP (2010-2014). My day job is titled "Technical Lead, MS UC" - I work with an awesome group of people at CDW, LLC. I focus on collaboration and infrastructure. This means Exchange of all flavors, Skype, LCS/OCS/Lync, Windows, business process, and learning new stuff. I have a variety of interests - some of which may rear their ugly head in this forum. 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. One of these days, I intend to start teaching. The opinions expressed on this blog are mine and mine alone.


CSAnalogDevice Dialing


Analog devices live on.  Face it. There are some states that REQUIRE analog circuits outside of the VOIP configuration.  New Jersey, for instance, requires that elevators be hardwired. 

So, I was doing this project that had a need for analog devices to do things like open gates, be a parking lot phone, and other nefarious duties.  Suffice it to say, we had to put in several 24 port FXS gateways. 

We got them all configured, ran through the requisite new-csanalogdevice and associated all the devices with their respective gateways, assigned (carefully) DIDs, contact objects, and Dial Plans.  You can see some background on how to setup csanalogdevices here.

The desired dialing action was to use a complete 10-digit dial pattern.  No four, no five, and none of that seven digit stuff.  10 digits was the plan moving forward.  During testing, we noticed that we had to dial 11 digits to get the call to complete. 


I immediately went to the configuration of the gateway (AudioCodes MP124) but I found that I already had the “Max Digits in Phone Num” set properly.


As I was performing that useless verification task, I BFO’d on the trace log from the gateway, where we noticed that Lync was refusing the call because there was no normalization!  Huh?

Uh oh

  1. The gateways were sending 10 digits as expected, but LYNC was not accepting them.
  2. The Get-CSAnalogDevice configuration showed that we had assigned a USER Dial Plan to the objects, which was the correct action.
  3. The User Dial Plan had a rule that accepted 10 digits and normalized to e.164.
  4. Therefore the CSAnalogDevice had the right set of rules, was sending the correct number of digits as it was told, but was not working.
  5. The CSAnalogDevice had the correct dial plan assigned, but the CSAnalogDevice did not like the dial plan scope, so the CSAnalogDevice fell back to using the Global Dial Plan ruleset, which did NOT include a 10 digit normalization rule
  6. It turns out that the CSAnalogDevice objects only respect DEFAULT dial plans, not user dial plans.  Our assigned Dial Plan is a user scope dial plan. CSAnalogDevice wants something that can be a default – so pool, site global. 

No, I don’t know why.  I assume it is coding issue, and there is SOME reason that makes no sense to you and me.  I know that you and I consider it a bug, but the developers might well come back with “by design.”  The Lync documentation indicates that a user-level policy will work.  (note that the same documentation indicates that a voice policy needs to be assigned, and I agree, but dang, you can’t make a call without normalization, and the documentation says squatoosh about the dial plan scope level.)

The Fix

The short term fix was to add a 10 digit normalization rule to the Global Dial Plan.  That fixed the analog devices not dialing out correctly. There was joy in Mudville.

For the future, create a site or pool dial plan that has all requisite rules for that site. SBA installations are considered a site for this purpose.

This is current as of the December 2014 Lync 2013 CU.  I hope the SfB release addresses this, but I am not going to hold my breath.  What I intend to do is make sure that every site or pool has a dial plan, and that a user level dial plan is never assigned to a generic device. 


That should hold the barbarians at the gate, eh?


1 comment:

Ricardo said...

"I hope the SfB release addresses this, but I am not going to hold my breath."

Do you have some personal connection into the sfb product group? If yes, you can write him/her a mail telling about the issue. Most probably they dont really care anyway. I have a couple of bugs reported in the past 2-4 years, all of them remained unresolved.

Sfb 2019 July 2019 CU

Script to update sfb 2019 install to enable the new control panel contained in the SfB July 2019 CU. Add-WindowsFeature RSAT-ADDS, Web-Serve...