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.

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?

YMMV