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.

2015/05/08

CSAnalogDevice Dialing

Scenario

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. 

Troubleshooting

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.

image

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. 

image

That should hold the barbarians at the gate, eh?

YMMV

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.

test 02 Feb

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