Lync for all its cleverness has one or two minor, transient shortcomings. There, I’ve said it.
One of these is the ambiguity of the message provided to a user when they try to call a number that’s barred by their Voice Policy: “Call was not completed or has ended”.
Clicking the error link doesn’t really add a lot of value: “reference error ID 403”.
OK, so you and I know that “403” means the call was unauthorised and can put 2 and 2 together, but hello?? The user community??
The “fix” is a simple one. All we need is to add a basic gateway (like the NET Tenor) to the mix, then add it as a “gateway of last resort” to all our voice policies. When it gets the call, it discards the digits dialled, turns the call around and feeds it back to Exchange to play a more user-friendly “the number you have dialled is not available from your phone/extension/user account” Recorded Voice Announcement (RVA). You could use a Response Group for this instead if you prefer to keep the traffic off Exchange.
Here’s how to do it:
1. Add the Tenor to your topology
The Tenor doesn’t support TLS, so just add it as a TCP gateway, associate it to your Mediation Server, and Publish.
2. Add the Tenor as the ‘gateway of last resort’ to your voice policy
(Actually, this step should be last if you’re implementing this in a working system, but as I’m working in the lab I can get away with building it in this order).
Here I’ve added a new PSTN Usage to my “Aust-Wide” policy, so it’ll get the call when I try to dial an international number:
Here’s the Route entry for it: match everything.
Test your logic is good at this point with Lync’s “Test Voice Routing”:
By this stage if you enable tracing on the Tenor you might see your “barred” calls are now being routed to it, and the failure message changes from “Call was not completed or has ended” to “The server cannot forward the call. Please try again” or “The call could not be completed. Please try again later”, depending upon the state of the Tenor’s config.
If you DON’T see the calls making it to the Tenor, you’ll need to restart the Mediation Service. Trace the calls on Lync, and if you see an error message saying “Gateway peer in outbound call is not found in topology document” then that’s going to be your fix.
3. Configure the Tenor – SIP Signalling & TCP
Make sure you have the usual SIP Signalling group settings correct:
… and var_config file set to enable TCP:
4. Configure the Tenor – Number and Routing Tables
These are the new bits added with the Tenor’s “108 Routing”, as per my earlier post on the subject. Note that if your Tenor ISN’T enabled for 108 routing you won’t be able to implement this configuration – specifically the tromboning of the call from SIP to SIP.
Right-click to create a new Number Table:
Give it a name: less than 31 characters and nothing too funky.
Select your new table and click the button to Add the number translation. Here we trap EVERYTHING and turn it into the number we’ve allocated for the UM AA, which in the Lab here is my pseudo-legitimate “+612700012xx” range:
Strangely, even though var_config is set to prepend a “+”, we still need to add it to the destination number here.
Now select Routing and click the button to Add a new entry here:
In this screen-shot we’re saying: if the call originates from a SIP source and the called number matches anything in our ‘re-route all’ number table, change the called number as per the table, make no change to the caller’s number (as per the “unspecified”), and route it out to UA101 – which sends it off back to Lync.
When you’ve saved it, it’ll go into the table looking like this:
If you don’t want to devote the Tenor to just this purpose, here you can add some other entries, perhaps for FXO lines or FXS devices connected to it. Just make sure those are ordered in the table above our wildcard re-route, otherwise calls will never get to them.
5. Add the AA to UM
And make sure you don’t put any spaces in the AA name, or it won’t work! You’ll get Event ID 1021 showing in Exchange. [Current as at Exchange 2010, SP1, CU5].
6. Add the new AA to Lync as well
C:\Program Files\Common Files\Microsoft Lync Server 2010\Support\OcsUmUtil.exe
With the above active, my previously unsuccessful call to the US is answered by the AA/RVA and played an appropriate message. You could give the caller the option to press a button & be re-routed to the Attendant for them to place the call on the caller’s behalf.
Astute readers might realise that this “barred number RVA” is a little imprecise – it’ll also be sent calls if the normal gateway is offline or otherwise rejects the call. That’s actually a good thing. Here you can use Exchange’s Telephone User Interface (TUI) to dial-in and change the greeting on the AA so it advises of the outage and indicates an estimated restoration time. Hopefully this message will prevent the flood of complaints from reaching the Helpdesk, leaving you to focus on fault restoration.
Oh, and if you’re worried for the call-carrying capacity of the Tenor for this task, don’t be. The smallest AF Tenor will support up to 20 simultaneous calls, with the AX and BX/DX catering for 30 and 60 respectively.
Finally, you can also use this concept to deliberately block an individual PSTN number (or range of numbers), playing a message to indicate that and why the destination is not permissible. Just add the routing entries as applicable, and create different Number Tables in the Tenor to trap the specific numbers and send them to unique Auto-Attendants – or any other internal destination of your choice!
*And for trivia buffs, +1 (212) 976 2727 in my screen-captures was every Aussie phone technician’s overseas test number back in the 1980s. Alas it’s no longer in service, but back then it was one of several numbers for Dial-An-Orgasm. Your call was answered by a lovely lady who seemed to be enjoying your vast presence to the point of shortness of breath, accompanied by lots of moaning and a big screaming crescendo. All in 60 seconds, and ending with an entreaty to call again next week. Just like in the real world.