Categories

CUC (6) CUCM (26) Jabber (6) Python (2) Routing (3) Solarwinds Orion NPM (4) switching (1) Video (6) voice (2)

Thursday, 17 May 2012

Number plan globalisation (based on the Australian Numbering Plan) - Part 2 The Chuck Norris Route Pattern

Part II of my E.164 globalization on Cisco Unified Call Manager series. In this part, I will discuss and describe the nuts and bolts of making E.164 happen. In part one I have already discussed the why. Cisco has a really good chapter on this topic in their services and features guide:

http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/admin/8_5_1/ccmfeat/fscallpn.htmlhttp://www.cisco.com/en/US/docs/voice_ip_comm/cucm/admin/8_5_1/ccmfeat/fscallpn.html

INBOUND CALLING PARTY NORMALIZATION

1-Incoming calling party normalisation to E.164

OK,  so the first part is the incoming calling party normalisation.  The most appropriate way to apply this, is at a gateway settings level. I am assuming that your provider is sending 10 digits for national and subscriber calls (could be 8 for subscriber calls, so use Q.931 debug to verify)  and 14 for international, so 001144 20 XXXX XXXX for a call from London coming into our gateway in Melbourne (again, check Q.931 because maybe your provider is already presenting +E.164 international calls)

This results in the following gateway incoming party transformations:

Incoming Calling Party Transformation on the gateway


I
2-Incoming calling party localisation
So the next step is localizing the E.164 format back. Remember that the calling party presentations that we have obtained in step 1, are OK if the call will be presented to an oversees user (who can quickly ascertain that the call is international and from a party in Australia) but are not so meaningful for an Australian user who would probably want to see where in Australia the call originated. So, according to the AUNP and using our example location, Melbourne, this localization equates to:2-Incoming Calling Party Localization
Subscriber: [89]XXXXXXX  (8 digits)
National:   0[23478]XXXXXXXX  (10 digits)

Please note that the CngPTP for National Calls includes mobile numbers.

Whatever happens in this step in terms of Digit manipulation is what eventually ends up on the phone screen. IT DOES NOT SHOW UP IN THE CALL HISTORY LOG,  these are two distinctly different things. This because CngPTP are transformations on the terminating device (the IP phone being called). Whereas missed call entities are globalized E.164 numbers rooted in the CUCM DB. Remember, transformation patterns are NOT routable. When a pattern is matched its is not routed to any end device, this is really important to remember.

For localization, I will first create a CSS called CSS_AUS_ANI_XFORM_IN.
And I will apply this to the device pool of the Melbourne phone.

Calling Party Transformation CSS setting in the Device Pool Configuration

Now onto the actual Calling Party Transformation Pattern (CngPTP).


I

Subscriber CngPTP
Obviously, the \+613.[89]XXXXXXX pattern is for Melbourne Metro only. So the CngPTP CSS for Melbourne would need to be different from a CngPTP for Geelong (which would have a \+613.52XXXXXX for subscriber calls)



National/STD CngPTP


I
Please not that in the pattern above, calls from Mobile phones (04XXXXXXXX) are included as well.


OUTBOUND CALLED PARTY NORMALIZATION

1-The magic route pattern +!   used to Globalize


So first of, our magic omnipotent, trillion million times meaner than wannabees Lars Ulrich and James Hetfield together, it is truly the Chuck Norris of Route Patterns: +!


+! route pattern

(The pattern is actually entered as \+! , otherwise CUCM will not accept its entry). Because Class of Control cannot be enforced on a RP level any more, (simply because we have only one RP and thus cannot make any distinction anymore) all phones will have the PT_AUS_OFFNET_E164 partition in their CSS (unless of course certain phones are not allowed to make Off Net calls). As you can also see, this pattern uses RL "RL_LOCAL", which points to the SLRG.


2-Translation Patterns and Class of Control


Now we have a +! pattern that all phones have access to, and which is all that they will get access to. So now we need to make sure that whatever a user dials, is forced to match that pattern. Because you can't expect your users to dial +61385671234 to order a kebab at the shop around the corner, local dialing habits will need to be accommodated, as well (have I said this before? Yes I have; in Part I).

Table below, provides translation pattern coverage of AUNP (well actually it doesn't because numbers such as 1100 Dial before you Dig, directory assistance etc are not in it, so you might want to expand that table, I just couldn't be bothered). It provides coverage for Local, Standard (10 digits), and International  Aim of the TP's below is not only to provide localization from the caller's perspective, but also to force all called party numbers be globalised into E.164  .


Translation Patterns for Globalisationa and to allow class of control


Now, because we no longer have RP's available to enforce class of control (CSS), it will need to be done on a TP level. I am assuming 4 calling permission classes:  
  1. Emergency and Local   (CSS_LOCAL)
  2. Emergency, Local and Standard   (CSS_STD)
  3. Emergency, Local, Standard and International (CSS_INTL)
  4. Emergency, Local, Standard, International and Premium (CSS_PREM)
For this I have put all TP's in their relevant partitions. Additionally, all phones are allowed to make On Net calls. Nothing special about this, same class of control as you would normally apply on a Route Pattern basis, but no applied to Translation patterns.

There is one flaw in this approach, and I let you sit on it for a while, if you have picked it up, well, you must be a nerd. It has to do with our missed call log and enforcing Class of Control on those numbers. As you will remember all missed/received calls have the +E.164 format (seeing they were dictated by the Incoming Calling party settings on the CUCM gateway). These could be subscriber, national, or international calls. Now, if we don't cover them off, then any user in the CSS CSS_STD, would still be able to make international calls. This because a user dialing, for instance, +44 20 1122 3344, from the missed call history, would have a match on our +! RP. The  same would applies for a Melbourne user with the local calling privileges only i.e. CSS_LOCAL, with a missed call from +61781122334. So TP's will need to be put into place to allow Class of Control enforcing, for E.164 formatted called numbers. The last 2 patterns in the table above, cover these missed call history numbers.


I have added a +613[89]XXXXXXX pattern for all Melbourne local calls in its own partition, and this will need to be reflected throughout the deployment, based on a phones location. For example in Geelong you could have a +61352XXXXXX pattern for local calls in PT_PSTN_GEE_LOCAL in CSS_LOCAL_GEE.

3-Called Party Transformation Patterns (cdPTP)

The Patterns used in the table above, can be re-used to create these CdPTP's. 
Because we have already enforced Class of Control and assuming carrier requirements in terms of the presented number are the same throughout Australia, or any country that is being considered for that matter, we will re use the same Called Party Transformation CSS.  PT_AUS_DNIS_XFORM_OUT and CSS_AUS_DNIS_XFORM_OUT and re-apply this to all gateways in the deployment.  



Calling Party Transformation CSS on Gateway page
This would lead to the following CdPTP, in this case for National calls:


So a national call to +0391122334 is now transformed into 0391122334 and send out the PSTN, most likely using an IOS pots dial-peer, or a voip dial-peer. 


One of the last things that needs to be taken care of, is pattern transformation when dialing from phone history, remember that these all have +E164 notation. (Remember I said that CngPTP's do NOT change the CUCM DB and will therefore not change the call history!!). Therefore, I want to bring this back to the original 10 digits for national and 8 digits for subscriber. So I will need to add 2 more CdPTPs. So for subscriber calls I would add a pattern \+613.[89]XXXXXXXX and I would DD=Predot and prefix 0. In summary, I would end up with the following CdPTP's:
















CdPTP summary

So I guess open for discussion at this stage, is should I replace all, but the last 2 (in table above) to CdPTP +!, this would strip just the + off all called parties, except for National and Subscriber calls (where I would strip +, the country code and the national code for a subscriber call). i will look into this further and edit this post accordingly. I am inclined to strip the + sign of all called party numbers before sending it out. This would result in called party numbers with a prefixed 0 for subscriber, national, and international calls. This would further reduce the number of CdPTP, but more importantly it will simplify the the gateway configuration. Let me explain.


With the approach of sending a prefixed 0 in all called party numbers (so both  from localized calls as well as calls from the missed call history) to the IOS gateway, it will allow for very simple dial peer configuration (a 0T pattern would suffice for all PSTN outbound calls). Furthermore, it will allow the same dialing habits in SRST mode (and let's face it fall back should be transparent for a user), without doubling up the amount of dial peers. So that same 0T pattern could still function in SRST mode for all outbound PSTN calls. Alternatively a hybrid solution is possible whereby a +T destination pattern,  on the IOS gateway, is added as a catch all. For instance when a call to Germany is made by hitting the Dial soft key from a missed call log (so in +E.164 format) to +492011223344, it would go through a TP, to enforce Class of service, if it passes, it is still the same +E.164 number. I would now prefer to have a +.! CngPTP in place that would strip + and would prefix the international access code 00011 and then have it match 0T destination pattern. You could choose however, not to have the +.! CngPTP and pass the unchanged +E.164 number onto the IOS gateway and have it match a +T destination pattern.This +! destination pattern could then also be used on an SRST phone when a users decides to opt for +E.164 dialing, not a bad idea either.

Now the other thing i haven't mentioned yet (well, since part I anyway) and you should have probably realized by now, is that AAR is gonna be a doddle to set up. Once you have fully compatible E.164 dial plan and all the external phone number masks are in E.164 formats, there is no need to additional AAR group prefix configuration.  

Tail End Hop Off (TEHO) will be a hell of a lot easier as well, especially when international calls can be handed over to their respective geographically local gateways. For instance handing off all calls for Sydney (the other Australian city) to the local gateway is as simple as adding a +612XXXXXXXX pattern and pointing it to the Sydney gateway (NOT USING SLRG's), easy as that! 


Happy to year your feedback.


I think my next post will be a bit shorter and on an easier topic such as Frame relay DLCI's.  And that's all I've gotta say about that one






















8 comments:

  1. This comment has been removed by the author.

    ReplyDelete
  2. very good work and well explained, one thing that i am wondering is what about the dialed number being displayed as +0XXXXXXXXXX once it hits the TP, how do you get around stripping the +? the cdPTP will take care of what is sent to the GW and strip the plus, BUT this has no effect on what is displayed on the phone. If you have an answer or want to discus this further you can email me at howyegettinon@gmail.com

    ReplyDelete
  3. Good point. I have changed the post to reflect that Translation patterns produce full E164 results (see XLS output in the post). this means that there are no more +0XXXXXXXX patterns, used for the sole purpose of matching +!, so thanks for pointing that out to me.

    ReplyDelete
  4. Thanks for your reply, this wasn’t quite what i was talking about. if you have a look at this video you will see what i mean https://www.youtube.com/watch?v=tIKJCkP2cic&feature=youtu.be so when users are dialling out to a local number say 95454433 it shows on screen +5454433. So how can we achieve this utilizing only the \+! RP to show 5454433 on screen. Called Party Xformation do not affect what is displayed on the phone even if you are stripping the plus to send to provider. So this only leaves us with TP and RP to manipulate the display. how can this be achieved without changing \+! to \+.!
    Thanks in advance

    ReplyDelete
  5. Hi Dennis.

    I have set this up in my lab and I have calls routing, however, one problem I have is that after I have matched the translation pattern and globalised an national call to E.164, because of the highly ambiguous nature of the \+! route pattern, it takes a long for the timeout on the route pattern as it does not know how many digits to expect. Is there a way to resolve this apart from fiddling with the timeout settings in service parameters?

    Any points gratefully received.

    ReplyDelete
  6. We are going to deploy E.164 call routing for CUCM 10.5.2. We will cover whole APAC region for our deployment. Before going ahead with E.164 routing, i want to know below things-

    1. Do i need separate translation pattern and called party number transformation for outbound E.164 calls per site ? To make it more clear if i have 10 sites for AUS country then do i need around 4*10 =40 Translation pattern and around 40 called party number transformation for outbound calls ? I know that we just need \+! route patten for each country but i am not sure if we need more than 4-5 translation pattern per country .

    2. If our Service provider is supporting +E.164 format then i think there is no need to create localization support for outbound calls as our Service provider understand + E.164 format . Correct ?

    3. Is there any issue while creating E.164 support for Single SIP trunk ? We are going to deploy ACME session border controller as SIP SBC.

    ReplyDelete
  7. Mate, i cant fully comment on your set up because i dont have all the information, but lets see if I can answer as best as I can

    1. Do i need separate translation pattern and called party number transformation for outbound E.164 calls per site ? To make it more clear if i have 10 sites for AUS country then do i need around 4*10 =40 Translation pattern and around 40 called party number transformation for outbound calls ? I know that we just need \+! route patten for each country but i am not sure if we need more than 4-5 translation pattern per country .

    probably not, so for instance Australia, if you have a user that dial 002XXXXXXXX to dial an number with in sydney/NSW, then essentailly you would like to translate that to \+612XXXXXXXX, by means of a called party translation. So 00.[234789]XXXXXXXX discard digit predot, prefix +61 would trannslate most of the australian numbering plan and could be applied to any of your 10 australian sites.

    2. If our Service provider is supporting +E.164 format then i think there is no need to create localization support for outbound calls as our Service provider understand + E.164 format . Correct ?

    There is no certainty here, until you try it out, but very likely yes

    3. Is there any issue while creating E.164 support for Single SIP trunk ? We are going to deploy ACME session border controller as SIP SBC.

    not that I can see, basically you will need one outbound dial peer supporting e.164, catching all patterns that start with a +

    ReplyDelete
  8. Thanks Dennis for answers. Much appreciate your work !!

    ReplyDelete