Back-End Changes
Firstly, I've been steadily moving away from XML for my data sources to a full-fledged SQL back-end. XML was great for the first while, but its been getting difficult to manage. SQL offers much more robust querying, searching and sorting than XML, and opens up all kinds of possibilities for future features. Now, changes and updates only have to be done in the database, and I don't have to touch the web pages.Area Code Improvements
With the change to SQL for back-end databases, I've been able to drastically increase the number of area codes stored for countries like Germany. Germany has thousands of area codes, which would overwhelm the drop-down style of listing area codes I've always done. So for countries like Germany, you now enter the area code, and the Optimizer will show you the available cities from that area code.Extension Extensions
You may notice additional options for extension entry than before. Firstly, I've upped the extension limit from 10 to 20. Secondly, I've added options to create your own rule suffixes for extension ranges. So, if you're creating an extension range for your London, UK head office, you can assign a suffix like "HeadOffice", which will make the resulting normalization/routing rules use UK-London-20-HeadOffice, instead of the default UK-London-20-Internal-1.You may also notice an additional checkbox column for "Single". Sometimes, you may have users with their own DID, but maps to an internal extension that doesn't hold any relation to the DID.
For example, the company president may have a DID of +14165551234, and an internal extension of x200. Your vice president may have a DID of +14165559876 and an extension of x201. Since there is no relationship between the DID and extension, you can't create a blanket normalization rule that will work with both of these.
With the new iteration of the Optimizer, you can easily tell the Optimizer to create individual normalization rule for each of these, simply by entering their DID and extension, and checking the box for Single.
Future updates may include a more Excel-like interface for extension entry that would allow cutting-and-pasting from Excel spreadsheets. If you have the information already in a spreadsheet, it will make data entry MUCH simpler.
Until then, enjoy, and if you have questions or problems, let me know.
I noticed that when I generate the rules for Fort Worth and Dallas TX, I now get two sets of translation rules. Is there a hard limit or recommended limit to the length of a regex in each rule?
ReplyDeleteAlso, is there any negative impact to having more rules? It's easier to correct translation rules when they are broken out by area code instead of having to filter through a very large regex to find the area code then the exchanges.
I have also noticed that there are what appear to be random anchor "^" characters in the regex that is generated. Is this on purpose?
Thank you so much for the tool. It has been a great benefit to me as I learn the in's and outs of Lync.
Yes, there is a 1024 character limit for regex in Lync, so if its any longer, I have to split it into multiple rules. I've looked at breaking out the rules by area code, but that would involve some major tweaking of my process, which I'm not fond of (scared I'll break something).
DeleteThose anchor characters are actually regex NOT. I'm all about minimizing rule length, so if its shorter to use (^258) instead of (1346790), I will.
Glad the Optimizer has been helpful to you!
Ken
I am trying to create a rule set that essentially only sends 7 digits if the call is going to a number within our DID range to prevent 2 trunks being utilized.
ReplyDeleteIn the Extensions Editor I try to start with +1404639 with ranges from 0000-5399. I get an error and it says contact administrator. Please help if possible
I didn't consider cases where an extension range starts with zero, which I probably should have. Until I fix it, you'll have to use a range of 1000-5399 instead.
DeleteHi Ken,
ReplyDeleteWill the optimiser be able to create a normalisation rule to remove (0) from any dialled number?
Yes, the Optimizer has normalization rules to remove the 0 from a dialed number for any country that uses 0 as a prefix code.
DeleteKen