For Lync and Skype Services, I typically was normalizing ^([2-9]11)$ to +1$ So in the Voice Routes I specify a service filter \+?[2-9]11. And on the “Trunk Configuration | Called number translation rules” I have one for ^\+?([2-9])$ to $1 so the plus gets removed before routing, IF there is a plus. But you do something long enough, you sometimes forget why you do the things you do…
An incident with a client reminded me of the why, Emergency Calling. As you can see from the screenshot below, Emergency Calling will bypass all normalizing rules, so if the Voice Policy’s/Routes are only routing calls based on ^\+\d+ then only calls normalized with a + will route, as was the case with this particular client. VVX phones have a built in function for tagging calls with a Session Priority of Emergency (which can be seen in the CDR), when that is invoked, Normalization is bypassed, and the 911 does not get normalized to +911, thus the call fails because there was no route. 211, 311, 411 they all work because they aren’t Emergency Calls, so they go through the normalization process.
After creating a new Route and PSTN Usage, insert the appropriate filters, update the Outbound Calling Translation rules, good to go again.
New PSTN Route – Pattern: ^\+?[2-9]11 and assign the Appropriate Trunk
Called Number Translation Rule – Services: ^\+?([2-9]11)$ –> $1
In this case, I was able to complete testing of 911 service by using manipulation rules in the AudioCodes gateway, first testing that 811 would redirect to my cell phone, then testing with 911 in the manipulation. Calls routed, CDR’s looked good again, no longer could reproduce the issue, everything is good again.
Screen shot courtesy of: https://channel9.msdn.com/Events/TechEd/NorthAmerica/2012/EXL318