A few years ago, after realizing the importance of E.164 in formatting phone numbers in OCS, I came across a problem. Our company is in the Toronto area, and the local telephone carrier doesn't accept E.164 formatted phone numbers. Sure, it requires that you dial a 1 for a long distance phone number, but if you dial a 1 for a local number, the carrier rejects the call with the helpful "This is a local number. Please do not dial 1" or something to that effect. To get around this issue, I had formatted any local numbers we stored in Active Directory without the 1, so our users could click to dial without any issue. This worked fine for our users since we had a single mediation server.
However, companies we were federated with couldn't dial the phone numbers, because they were not formatted in E.164. For instance, while setting a user's telephone number in AD as +9052221111 worked fine for other users in our company, when a federated contact tried to use click to dial that number, they would either get a fast busy or would find themselves talking to someone in Turkey (who has the country code 90).
I could see the requirement for using E.164 phone numbers in Active Directory, but I couldn't see a way to get around the carrier limitation of not using a 1 for local calls. Since OCS R2 didn't have any way to manipulate numbers before sending to the PSTN, a media gateway would be required to do the necessary manipulation. We were using an AudioCodes media gateway for our connection to the PSTN, and I knew I could define rules that would strip the 1 when required. A website called Local Calling Guide had a list of all the local prefixes for a given phone number, but since there were 1380 local prefixes for our company's phone number, I didn't see a way of importing these rules into our gateway (the Audiocodes has a 125 rule limit, I hear), let alone manage any changes.
I was resigned to the fact that we wouldn't be able to use true E.164 dialing in our environment and would have to accept the downsides. I had numerous discussions with Clive from Microsoft on this topic. Clive went ahead and created a spreadsheet where you would copy the local dialing rules into one page, and with some Excel trickery and a lot of manual labour, came up with a somewhat optimized ruleset that could be imported into the AudioCodes gateway. It worked like a charm, however, the amount of manual work involved meant there was lots of room for error, and it would be pretty much impossible to detect changes to the ruleset over time. Not only that, modifiying the spreadsheet to work with other gateways such as Dialogic would be problematic at best.
Clive's Excel-based solution got me thinking about a better way to create optimized rules for AudioCodes and Dialogic gateways. After many, many late nights of programming (and I'm not a programmer!), I came up with a VBScript-based HTA program that did a good job of creating an optimized ruleset for any type of gateway I could get my hands on. Later iterations further optimized the logic to the point where the 1380 individual rules for our company's local number got optimized down to 47 rules!
 |
| An old HTA version of the Optimizer |
 |
| The latest version |
Please try it out, and give me any feedback you can!
http://www.LyncOptimizer.com
0 komentar:
Posting Komentar