Early on in testing OCS R1 I did discover that I could route numbers without the + but with R2 this was problematic at times and the best way forward was to strictly follow RFC3699/E.164. I worked for a global company and even though our pilot was only going to be in the US I had to think bigger as this was going to be deployed globally. Lucky there were some common issues people run into that I didn’t have to deal with. Just to name a couple:
-The company was already receiving all DID’s in ten digit format from the service provider in the US.
-The service provider would accept 11 digits in the US and 10 digit routing was in place.
- I was able to simplify call routing in OCS since I was interfacing into CUCM which already had a complex routing plan (no need to recreate the wheel). Routing though CUCM was not my optimal choice but it was my only choice.
-The company used the same service provider for long distance and local calls so there was no need for steering digits.
-Ten digit dial plan was the direction the company was headed anyway so there was no need to do abbreviated dialing or support the abbreviated dial plans of other PBX’s (actually that was more me saying I wasn’t going to do it rather than a team consensus).
So as you can see I was pretty fortunate to not have these obstacles in my way to E.164 heaven. Probably the biggest hurdle in all this was abbreviated dialing. I was trying to keep the dail plan dead simple and keep voice dial plan management at basically zero. Funny thing is not once did I ever hear a complaint of not being able to abbreviate dial another PBX user. I think Telecom can be paralyzed by the thought of people not being able to do abbreviated dialing. But with all the complexities of overlapping dial plans, site codes and everything else, when it is replaced with a better end user experience in my opinion it’s soon forgotten by users.
This was my journey but what if you run into everything I am describing here that I got to avoid. Doug Lawty talks about common dial plan issues here in his blog post.
Although I agree with Doug’s opinion of always sticking to E.164 OCS 2007 R2 doesn’t always make it so easy when you are trying to do direct SIP with non-RFC3699 compliant PBX dial plans. Stripping the + is only part of the puzzle. I avoided just saying PBX’s there because more and more PBX’s are supporting E.164. It just never gets implemented into the dial plan. I am not about to cry foul on you because you have allowed a 9 steering digit into your OCS dial plan because the thought of building 100’s of translation patterns into CUCM fills you with uncertainly. If you’re faced with all these issues sticking with E.164 is challenging and could possibly mean significant changes to otherwise stable enterprise dial plan.
If you were fortunate you may have been able to circumvent the E.164 headache by having a gateway between your OCS and legacy environments but of course if you were trying to do direct SIP this means programing changes into your PBX. The point here is, it isn’t happening in OCS. Well with CS 14 this has changed.
CS 14 Translation Rules
Translation patterns on outbound SIP trunks means that any enterprise should be able to implement E.164 with a lot less pain and all dial plan configuration will be centralized in CS. You also no longer need to add additional routing logic into gatewaysfor E.164.
So now with CS 14 you will be able to deliver a consistent end user experience across your entire enterprise with E.164. Direct SIP trunking to a non-compliant RFC3966 PBX will be easier and will require a lot less changes on the PBX. This means a central place to enable:
-Stripping the +
-Adding 011 to international calls or any other international access code
-Adding steering digits to outbound Long Distance calls to reach legacy trunking
-Adding External access codes
Its not always a internal dial plan that needs these types of requirements. Some service providers may also require removal of the 1 for local dialing in the US.
Tools available for OCS 2007 R2
If you are currently working at implementing OCS 2007 R2 there is a great free online tool available to help with creating the rules for implementation with a gateway for US dial plans. OCS Optimizer is an automated script generator which will generate very compact set of rules you can copy and paste into your OCS Dial Plan in Enterprise Route Helper, and also your PSTN Gateway config file.
This OCS optimizer looks at area code and exchange and generates the appropriate routes using data from http://www.localcallingguide.com/. By adding the external access number it will make building those steering digit legacy rules pretty easy and when there is a change to the free calling area code you entered, it will send you an email to let you know.
Here is an example for the area code 206766 which is here in Seattle I entered a 9 as the external gateway access. For OCS it produced a set of rules for local free calling that looks like this:
^(\+1206(([23456789])))|(\+1425((21[3468])|(22[13678])|(23[3457])|(24[123568])|(25[01456])|(28[12345689])|(29[1568])|(2[07])|(26[049])|(30[1267])|(32[3459])|(35[1248])|(37[2368])|(39[012458])|(3(10|13|18|61|68|69|81|83))|(40[12689])|(41[235679])|(42[0147])|(43[01237])|(44[023459])|(49[125678])|(4[5678])|(58[02467])|(5[2679])|(5(02|03|07|16|18|19|31|33|38|56|57|58))|(60[23568])|(63[5678])|(64[012346789])|(6[5789])|(66[03])|(73[2689])|(74[123456789])|(78[05678])|(79[0359])|(7[027])|(7(53|55|57|61|65|66))|(83[0567])|(88[012359])|(8[012469])|(87[137])|(92[0128])|(94[0134579])|(95[124567])|(97[0347])|(9[1689])|(9(02|06|08|30|36|39))|((336|614|629|712))))|(\+1253((21[4678])|(23[4679])|(24[3569])|(2(61|66|69|70|75|77))|(33[23456])|(39[4578])|(3(50|51|72|73))|(4(78|79|80|86|87))|(56[139])|(65[2367])|(73[3567])|(7[04])|(7(65|66|93|96|97))|(83[3589])|(85[02469])|(8[01])|(8(72|74|76|80|86|87))|(9(31|39|41|45|46))|((205|220|288|293|315|326|347|437|449|458|499|508|518|642|661|670|681|773|785|867|893|929|951|981))|((52|63))))
This in itself is priceless and takes a great deal of work out of doing your dial plan routes for local calls. It also produces a gateway file In this example I selected the generic option.
+1206[2,3,4,5,6,7,8,9]xxxxxx
+142522[0,2,4,5]xxxx
+142523[1,2,8,9]xxxx
+142525[2,7,8,9]xxxx
+142526[1,2,3,5,6,7,8]xxxx
+142529[0,2,3,4,7,9]xxxx
+14252[10,12,44,49]xxxx
+142531[2,4,5,6,7,9]xxxx
+142532[0,1,2,7,8]xxxx
+142533[0,2,3,4,5,7,8,9]xxxx
+142535[0,3,5,6,7,9]xxxx
+14253[03,04,08,74,77,79,85,87,88,96,97,99]xxxx
+14254[05,07,22,23,34,38,41,46]xxxx
+14255[01,08,12,13,14,83,85]xxxx
+14257[10,17,50,54,83,89]xxxx
+14258[70,76,79,86,88]xxxx
+142590[3,5]xxxx
+1425[280,367,418,493,530,551,609,610,622,631,645,669,737,740,760,791,831,923,931,948,953,971]xxxx
…………………..etc.etc.etc
This could also be a AudioCode or Dialogic gateway which produces a easily importable text file in the right format for those gateways. As you can see it does a great job of consolidating the various DID free call ranges.
I had the pleasure of meeting Ken the creator at a recent ignite event in Phoenix. This is a great tool and Ken will be updating this for CS 14 and PowerShell soon so keep an eye out for that. If you have any feedback for their OCS Optimizer tool let Ken know I am sure he would like to hear it.
Preparing for the future
Although this post was mainly based on a new feature in CS 14 I just wanted to talk a little about working with a dial plan to allow a seamless transition form non-compliant to compliant E.164 dial plan in OCS 2007 R2. The main concern with integrating to an existing non-compliant E.164 dial plan is usually outbound dialing. So to prepare for future success building a dial plan that has client side features in E.164 format is probably the most critical.
What does this mean? Putting the Tel URI associated with the user in E.164 format. This will also allow you to place inbound normalization rules on the mediation server that will comply with E.164. The address book on the other hand may be a little different because it will be a lot harder to build rules to suit your desired outbound dialing behavior. The only thing left out is the outbound dialing routes and client normalization rules. I would recommend that you still use the + regardless of what you do outbound just to get users used to it and make dial plan changes easier when you finally jump to E.164. You can strip the + at the Mediation server in OCS R2 if required. If you must pass access codes etc. this is okay just keep in mind of what other areas you are affecting by using these dialing habits and in CS 14 plan to create new translation patterns that will eventaully remove the need to have users use access codes altogether.
I mention the address book because if you have an external access code of 9 as an example now you need to build this logic into your address book as well for phone numbers that aren’t in your organization. Depending on the size of your organization this could be a pretty time consuming task to allow the proper outbound routing to work in conjunction with your address book. There is no real work around for this so be prepared for trial and error.
Last point that is worthy of a mention is getting ready for SIP trunking. Not having a compliant E.164 dial plan could limit your choices or possibly mean a lot of rework so having a plan to progress to E.164 if you think SIP trunking is in your future will be important. Hopefully with CS 14 the decision to do E.164 will now be a no brainer and enterprises will have no issues adopting to a global dial plan.
Comments welcomed.
VoIPNorm
Chris.. Have a question regarding Cisco Translation Pattern
ReplyDeleteWe have Direct SIP trunk going from OCS 2007 R2 Mediation to CUCM 7.1. I have location profile and normalization rules set up for country Finland whose country code is "358" . I have translation Pattern set up on CUCM so that we can make PSTN call. One of translation pattern is not working correctly or I am missing with format especially to dial international number. The Route Translation pattern is [^358]! -> Prefix with "9990". Which according to me, means that if the digits dosen't start with "358" then add 9990 and make international PSTN calls.
This translation pattern is working fine for making international call in few countries but NOT with country code starting with 3, 5, and 8
So for example if I want to dial Shanghai, China Country code "86" it does match the above translation pattern and I can't call from OCS. OR if I dial Mexico then it fails as Mexico country code starts with "5". where as if I dial US OR UK OR India it works fine as it goes to above translation and add prefix make call. I did SIP logs and I am sending correct digits to CUCM but its not matching the translation pattern above. Also I did Cisco dial Analyzer and same result.
Any suggestion, how can I make country code starting with 3,5,8 work with above translation OR what is the correct format?
I am looking into an answer, I will add a comment soon. I think your biggest issue is that [^358]! is to match 3 or 5 or 8 not 358. Routing or translations via exception like you have done can be a tricky practice and at times hard to get right.
ReplyDeleteThanks for your comment. But that's what I have read at almost all articles. Even technet article which lead to lee desmond video says the same thing. They have given an example of Paris.
ReplyDeletehttp://technet.microsoft.com/en-us/library/ee862409.aspx
http://www.leedesmond.com/video/msft/ocs2007r2/directSIP/CCM5-3/CCM5-3.swf
So just to make things clear. I dont see a problem with the technet article as it is using translation pattern based on matching a pattern and not on an exception like your doing. You are not doing the same thing as the technet article proposed in regards to the configuration of the translation patterns. They are matching a pattern and what your doing is matching every pattern except the one starting with 358, or at least that is what you are trying to do.
ReplyDeleteWhat may be a better approach is to have is a translation patterns that work on matching everything else that isn’t 358 and having a translation that matches 358.So having two transaltion patterns. CUCM will work on best match so the more granular match will be taken first. Then everything else will be routed per the translation. The one thing you should be aware is that the translation will keep trying the other translations 10 ten before routing the call. So the first translation could be 358.XXXXXX (whatever the amount of digits) and you could strip the 358 if you wanted to or not do anything to it. And the second one could be [1-9]! or something similar that matches everything and appends your international long distance dialing.
Hope this helps.
Yes it did. Your comments are always helpful. Thanks for your help.
ReplyDeleteNo problem. Translation patterns in CUCM can be a tricky business.
ReplyDeleteWhat may be a better approach is to have is a translation patterns that work on matching everything else .that isn’
ReplyDelete. I think Telecom can be paralyzed by the thought of people not being able to do abbreviated dialing. But with all the complexities of overlapping dial plans, site codes and everything else, when it is replaced with a better end user experience in my opinion it’s soon forgotten by users.
ReplyDelete