Company Wide Speed Dial in OCS

As OCS becomes more popular we find more companies deploying it with diverse needs.  During a recent deployment I worked with a client that had over 100 speed dial numbers for various partner companies that they regularly dialed.  Each speed dial was a 3 digit number starting with a # (pound/hash symbol), some of the numbers translated to 10 digit dials, others only 6 digits with 4 more digits dialed by the user added to the end.  As this was in place with the existing PBX it was important to bring this functionality to OCS as well.  After discussing the requirements with the client I used my lab to verify the solution was feasible and consistent to their request.  A few minutes of tweaking the normalization rules and I had a plan.

I started with the companies “Location Profile” (in the OCS Snap-in Right click Forest>Properties>Voice Properties), for this example it will be HQ.ocsguy.local:

I clicked “Edit” on the HQ Location Profile and clicked “Add” to create my first rule.  For this rule we are going to convert “#100” to +513-555-1212:

For the “regular expression” field we are going to enter “^\#100$”.  Next we enter our “Translation pattern”:

Next we enter our speed dial in the “Sample dialed number” field and verify the “Translated number” is what we are expecting to see:

Once we have verified our output is what we want it to be we can “OK” out and now we see our new rule at the bottom of the list:

This took care of part of the speed dial needs, converting #100 to 513-555-1212, but we also wanted to take a 3 digit speed dial and add 4 more digits it to it to complete a 10 digit dial.  For example, we will take #101 followed by any 4 digits and convert it to 614-123-XXXX where the XXXX will be the last 4 digits dialed by the client.

Again we start with the “Add” button and fill out the new rule:

This took care of part of the speed dial needs, converting #100 to 513-555-1212, but we also wanted to take a 3 digit speed dial and add 4 more digits it to it to complete a 10 digit dial.  For example, we will take #101 followed by any 4 digits and convert it to 614-123-XXXX where the XXXX will be the last 4 digits dialed by the client.

Again we start with the “Add” button and fill out the new rule:

Our “Phone pattern regular expression” will be “^\#101(\d{4})$”.  So this seems a bit tricky, but we can break the pattern down:

^\#101 – this section of the pattern means if the user dials “#101”, easy enough.  Next we see:

(\d{4})$ – this section of the pattern means capture the next 4 digits only.

Now we just have to take the #101 and the trailing 4 digits and convert it into a phone number, to do this we configure our “Translation pattern regular expression”

Now we can break down the “Translation pattern” field:

We start with +614123 – this means exactly what it looks like, dial: +614-123

$1 – this means take the string of text captured above and append it to “+614-123”.

Here is what that pattern looks like when we dial #1019999 

In my next article I will cover an expanded version of this scenario where the use of speed dials is the only way certain users can call long distance.

 Now that we have the 2 speed dial scenarios covered we just need to arrange our rules top to bottom so the most restrictive rules are first with the catch all rules (if they are in use) at the bottom:

In my next article I will cover an expanded version of this scenario where the use of speed dials is the only way certain users can call long distance.

About Kevin Peters

My name is Kevin Peters.
This entry was posted in Uncategorized and tagged , , , , , , . Bookmark the permalink.

4 Responses to Company Wide Speed Dial in OCS

  1. Mitch says:

    Neat trick , but it kinda flies backwards against the new world of UC ,don’t ya think?. Remembering speed dial codes is a bit out of date. Wouldn’t a better option be to have static webpage with alphabetized tel: URI
    Much easier to naviagate than a 2page printout of speed numbers pasted to the side of your monitor!

  2. Kevin Peters says:

    Mitch,

    Although I don’t personally dig this trick and wouldn’t utilize it over things like Outlook contacts, the reason for the article was to showcase a way to make OCS do what the existing PBX was doing. It’s not always about what wiz-bang-wow feature you can provide (although those are great), sometimes you just have to give the users what they have used for the last 10 years and already know.

    In this scenario most departments only utilized a few of these speed dials each, and they used them a lot so they were memorized. When we put the new system in we wanted to provide the users with all of their current comforts such as these speed dials so they wouldn’t be instantly against the new system. The great part about OCS is it will do many useful things but you can choose what amount of that functionality you want to advertise to the users. As time goes on at this deployment (now 1 week old) we will be doing more advanced user training including things like using contacts in outlook and clicking on phone numbers on intranet/internet pages. For now we were able to give the 300 or so users at this company a phone system that worked exactly the way they were used to it working. Many of the more advanced users are already utilizng more features, but we didn’t want to scare them with too much to fast.

    Sometimes we IT people get wrapped up in all the new features and forget that there are hundreds of people who just need to pick up the phone and have it work the way it always has. Our job as consultants, engineers, help desk staff, network admins and the like is to provide a service to those users that allows them to do their job.

    Thanks for the input on the article!

    -kp

  3. Jeff Schertz says:

    An alternative method would be to utilize the Address Book Normalization file to hold these translation patterns instead, assuming that the speed dial numbers are only keyed-in the the OC client. This would support dialing the short patterns but leave them out of the EV rule-base as having over 100 translation patterns. Ideally you would put the more commonly used E.164 patterns at the top so that the speed-dial patterns are not parsed during every inbound or outbound call that the Mediation server would have to normalize.

  4. Kevin Peters says:

    Hi Jeff,

    Thanks for your input! For the scenario this article was originally written based on the clients do not use OC to make calls so we can’t utilize the method you mention above, but it is a good scenario for when OC is used for dialing. The order of the patterns is a good suggestion as well and definitely something I watched for when configuring. Thanks again for you input!

    -kp

Leave a comment