Real World Globalization



I like the idea of globalizing the dial-plan, but cannot find a way to make it work in this real world scenario, maybe someone wants to take a crack at it.  We will use Portland, OR as the example.  The customer has multiple locations internationally.

1. In Portland the local area codes are 503 and 971

2. 503.765.XXXX is a local call from Portland.  503.856.XXXX is a long distance call from Porland

3. 971.235.XXXX is a local call from Portland.  971.486.XXXX is a long distance call from Portland

4.  If the call is long distance, it must lead with a 1 when it goes to the telco

5. If the call is local it must not not lead with a 1 when it goes to the telco

6.  The client has 2 pri's, one is dedicated to Local calling and one for Long distance.  They have recently signed a contract extension and making changes will be costly.


How do I globalize this without having unmanageable calledd party transformations in cucm?  I'm thinking my option is go globalize the inbound, hold off on the outbound until they have a provider that will accept "+" dialing.


Looking for any suggestions.





  • Ahochau;

         We have a similar situation in our calling area, also with 2 different area codes, some local, some LD, and they also depend on the provider and what rate plans that you have with them.

         So a couple of questions come to mind right off the bat, the first being, do the LD PRI and the Local PRI connect to the same voice gateway?  What digits are the users actually dialing?  Where are you performing the pre-dot strip?  In the CUCM or on the voice gateway?  Are you trying to use click-to-dial to enable this?

         I also would like to know what you mean by the "How do I globalize this...".  Are you talking about the "newer" recommendation in the SRND to allow everything on the phone and restrict by the line?

  • I'm referring to the globalization/localization of the dail plan options that are discussed in the videos which I believe follow the srnd.

    User Dials 9.503.321.4321

    It hits a translation that changes the number to +15033214321

    The translation sends it to the gateway as +15033214321

    The gateway then applies the called party transformation to convert the number back to 5033214321 and away it goes to the PSTN.  This would all be fine if the telco didn't care about the leading 1, but in the scenario they do.

    With the examples given in the ATC videos, it is assumed that any thing that begins with 206 is local to the HQ gateway.  Thus any number coming to the gateway as +1206....... loses the +1 and is sent as a local call.  Perfect threory for a lab or if you are using a ITSP, but there are few traditional carriers that allow you to just send digits down the pipe.  At least only a few that I have worked with.

    I don't think it matters if there is one or 2 gateways, you will have the same problem.  Unless you tell CUCM "These office codes are long distance, and and all the rest do not"  you will have the same problem if the carrier is not willing to just accept the digits and route accordingly.  The best option would be to get a provider that accepts "+" dialing.  But it is always easy for me to spend other people's money.

  • Ahochau;
 apologies, I did not realize you were
    applying this to a specific example in the ATC/WB1, I was referring to a
    real-world example of this.

         The reason that I asked the
    question about the gateway, is that I was trying to understand who was
    making the decision about which PRI to send it out, the local or the
    LD.  If you are sending the same pattern down to the same voice gateway,
    then you could use the translation patterns in the voice gateway to
    filter on the NPA/NXX of the number.  So if they were both sent to the
    same gateway, then you could do a dial-peer with "destination-pattern +1503765...." and send it to S0/0/0:23 which would be your local PRI.  Then, you could take another one and do "destination-pattern +1503856...." and send it to S0/0/1:23, which would be your LD PRI.  However, obviously, this is limiting, time consuming and almost impossible to adequately manage.  So, with that said, it leads into even more questions... :-)

         Are the 2 PRI's from the same carrier? (I dont' think this is really relevant, because they can't respond with which PRI to send the call down, based on digits, but may be if they can "share" the PRI's in some billing magic) Is the voice gateway MGCP or H.323?  Do you have just the CUCM responsible for the translation/transformations, or are you doing translations on the voice gateways as well?

         In your statement "The best option would be to get a provider that accepts "+" dialing.", if these are seperate PRI's, it wont' matter what they are accepting, because you are still responsible for determining the egress path for that call, because you have seperate PRI's for LD and local.

         I don't know how many of these questions are really relevant, because at some point, because you are sending LD to a different destination, something, somewhere, is going to have to maintain a list of what is local and what is LD, by NXX for each of your NPA examples in your first post.  Unfortunately, I can't think of a less tedious way to do this, and I really hope that someone WAY smarter than me will jump in here! *cough* Mark *cough* !!! :-)

  • Right and if I filter on the NPA/NXX then I have to keep track of 1000 NXX options for each area code, and that quickly turns into a nightmare.  And you are correct that something somewhere is going to have to keep track of what is local and what is not, and today we do that by using a "1" on the beginning and if the carrier returns a "You do not need a 1" then the users hang up and dial again.

    I would like to scrap the whole separate circuits for Local and LD because it really isn't cost effective anymore.  When you have SIP providers that are charging less than $0.01/minute.  However, due to contractual obligations it is not possible to switch now.

    I am wondering though if I can specify the type on the translation rule when it converts to +.  If I can, then I would have 2 transforms one +1503! type subscriber and one +1503! type national and that may solve the problem.  I'll post what I find.



  • Checked the called party transforms and can't match on type as well.  If I remember correctly from the videos, once the Type is set, it will pass through until it is set someplace else.  Thus, if I set the type on the 91 translations to "National" and use an h323 gateway where I can match based ont the type National and add the 1 back on the front as comes into the voip dial peer on the router, in theory, it should work.  I'll post the results.

  • OK, that worked as far as I could tell without configuring another gateway and phones. 

    Now, as long as the users are pushing the buttons the call will be routed as intended.  I am defaulting to local since that will be more common. however, if the user dials from missed or placed calls with the "+", they may get the "You must first dial a 1" as I cannot specify national or subscriber on those calls.  I think that would be a minor inconvience.

    Attached is the relevant config and the debugs from the testing.


    !=========  CUCM Config  ================

    !! Partitions:

    !! CSS:
      PDX-Devices: 1-PrimaryExtensions, US-PSTN

    !! Gateway H323:

    !! RouteGroup:

    !! Route List
     Standard Local Route List

    !! Translation Patterns:
        PT: US-PSTN
        CSS: Globalized-to-PSTN
        Called Party Transformatin
          Discard Digits: <None>
          Prefix Digits:

        PT: US-PSTN
        CSS: Globalized-to-PSTN
        Called Party Transformatin
          Discard Digits: PreDot
          Prefix Digits: +
          Type: National
        PT: US-PSTN
        CSS: Globalized-to-PSTN
        Called Party Transformatin
          Discard Digits: PreDot
          Prefix Digits: +
          Type: Subsriber

    !! Route Pattern:
        PT: PSTN
        RouteList: Standard Local Route List
        Discard Digits: PreDot
        prefix Digits 9
        Type: Cisco CallManager  (should carry the type from the translation Rule)

    !==================  Gateway config  ==================

    !! H323 Gateway
      voice translation-rule 1
        rule 1 /^9503/ /91503/ type national national

      voice translation-profile Localize_503
         translate called 1

      dial-peer voice 2 voip
        description **  Default H323 Dial-Peer  **
        translation-profile incoming Localize_503
        incoming called-number .
        dtmf-relay h245-signal rtp-nte

      dial-peer voice 9 pots
        trunkgroup Local
        description **  Outbound to PSTN   **
        destination-pattern 9[2-9]..[2-9]......$
        forward-digits 10

      dial-peer voice 91 pots
        trunkgroup LD
        description **  Outbound to PSTN   **
        destination-pattern 91[2-9]..[2-9]......$
        forward-digits 11

    deb voip dialpeer inout
    deb voip translation

       Calling Number=5000, Called Number=95033602062, Voice-Interface=0x0,
       Timeout=TRUE, Peer Encap Type=ENCAP_VOIP, Peer Search Type=PEER_TYPE_VOICE,
       Peer Info Type=DIALPEER_INFO_SPEECH
       Result=Success(0) after DP_MATCH_INCOMING_DNIS; Incoming Dial-peer=2
       Calling Number=5000, Called Number=95033602062, Voice-Interface=0x0,
       Timeout=TRUE, Peer Encap Type=ENCAP_VOIP, Peer Search Type=PEER_TYPE_VOICE,
       Peer Info Type=DIALPEER_INFO_SPEECH
       Result=Success(0) after DP_MATCH_INCOMING_DNIS; Incoming Dial-peer=2
    //-1/8094071E0800/RXRULE/regxrule_stack_pop_RegXruleNumInfo: stack=0x490ACE48; count=1
    //-1/8094071E0800/RXRULE/regxrule_stack_pop_callinfo_internal: numinfo=0x498CAA6C
    //-1/8094071E0800/RXRULE/regxrule_stack_push_RegXruleNumInfo_internal: stack=0x490ACE48; count=1
    //-1/8094071E0800/RXRULE/regxrule_profile_translate_internal: number=5000 type=unknown plan=unknown numbertype=calling
    //-1/8094071E0800/RXRULE/regxrule_get_RegXrule: Invalid translation ruleset tag=0
    //-1/8094071E0800/RXRULE/regxrule_profile_match_internal: Error: ruleset for calling number not found
    //-1/8094071E0800/RXRULE/regxrule_profile_translate_internal: No match: number=5000 type=unknown plan=unknown
    //-1/8094071E0800/RXRULE/regxrule_profile_translate_internal: number= type=UNKNOWN plan=UNKNOWN numbertype=redirect-called
    //-1/8094071E0800/RXRULE/regxrule_get_RegXrule: Invalid translation ruleset tag=0
    //-1/8094071E0800/RXRULE/regxrule_profile_match_internal: Error: ruleset for redirect-called number not found
    //-1/8094071E0800/RXRULE/regxrule_profile_translate_internal: No match: number= type=UNKNOWN plan=UNKNOWN
    //-1/8094071E0800/RXRULE/regxrule_profile_translate_internal: number=95033602062 type=national plan=unknown numbertype=called
    //-1/8094071E0800/RXRULE/regxrule_profile_match_internal: Matched with rule 1 in ruleset 1
    //-1/8094071E0800/RXRULE/regxrule_profile_match_internal: Matched with rule 1 in ruleset 1
    //-1/8094071E0800/RXRULE/sed_subst: Successful substitution; pattern=95033602062 matchPattern=^9503 replacePattern=91503 replaced pattern=915033602062
    //-1/8094071E0800/RXRULE/regxrule_subst_num_type: Match Type = national, Replace Type = national Input Type = national
    //-1/8094071E0800/RXRULE/regxrule_subst_num_plan: Match Plan = none, Replace Plan = none Input Plan = unknown
    //-1/8094071E0800/RXRULE/regxrule_profile_translate_internal: xlt_number=915033602062 xlt_type=national xlt_plan=unknown
       Calling Number=, Called Number=915033602062, Peer Info Type=DIALPEER_INFO_SPEECH
       Match Rule=DP_MATCH_DEST; Called Number=915033602062
       Result=Success(0) after DP_MATCH_DEST
       List of Matched Outgoing Dial-peer(s):
         1: Dial-peer Tag=91




  • Ahochau;

         This is good, but we have pushed the decision factor back to the user...which may or may not be OK, depending on your political environment.  I know that if I "force" our users to learn how to dial numbers correctly for their area, I get crucified. :-)  However, I personally think that it will take far less configuration, and to be honest, most users should know where they are dialing, whether it is local or LD, because they will generally live in the region and know that some cities are a bit further away.

  • Ahochau;

         First, I agree with you consolidating the lines, and I would seriously investigate the cost delta of contract termination charges, vs. the savings provided by a single carrier with more competative rates.  Of course, this will also depend greatly on the amount of calls placed, as to whether that is an option.

         In regards to your comment above "I am wondering though if I can specify the type on the translation rule
    when it converts to +.  If I can, then I would have 2 transforms one
    +1503! type subscriber and one +1503! type national and that may solve
    the problem.", how are you going to determine which to tag as national and which to tag as local?  They both have the same patterns for matching.  If this goes to the same gateway, then the dial-peers will make the decision, but you still have to maintain the list in the voice gateway via dial-peers.

  • Hey Ahochau,


    Sorry I am late to the conversation, and looks like it has been lively and full of good information thus far.


    I'd like to respond directly to your original thread-starting post:

    As for the breaking out of NPA/NXX's - brother, I feel your pain. I remember having to do this very excersise years ago - not with globalization, but rather with the fact that at the time, the client/city I was working with had overlaid NPA/NXXs that required some NXXs in a given NPA to be dialed 7 digits, and other NXXs in the same NPA to be dialed with 11. 

    Now a question I have for you is this: Before you were thinking about moving over to a globalized dial plan, didn't you already have to perform some sort of NPA/NXX breakout configuration in order just to tell numbers (like you give examples for in your first post) which T1 to route out of?

    If you didn't, then how did you deal with telling which numbers, which T1 to route out of?

  • Yes, so the users dialed 91<number> or 9<Number> and it matched the route pattern.  So the users would get the error if they dialed inccorectly and that is how the issue is resolved.  But when it is globalized, if the user dials 91<number> or 9<Number> it becomes +1<number>.  

    To accomodate this I added the type national on the 91<Number> translation, since the user had dialed it as a national call and type subscriber to the 9<Number> translation so it would put tag it correctly.  On the gateway the the translation rule will help pick the port.

    I am making progress on getting them to change the cirucuits, but the bigger the boat, the longer it takes to turn.  "Until we can put numbers in front of them that say "it will cost you $X to cancel the existing contracts and switch but you will save $x+1 in 2 months," it is a abstract sell and not what I am contracted to do.

  • Of course my next issue is going to be if the local carriers at each site will allow calling numbers to come down the line if they do not belong to that circuit.  I've seen this with some carriers.  Of course the fix for this is to translate the calling number to the main number for the location for all numbers that don't belong to the circuit. 

  • I like your solution a lot.

    The best solution would be if our carriers simply allowed us to always dial 10 digits, and they sorted out the mess properly in their SS7 switches - just like the mobile carriers do.

    In Europe this isn't a problem - if you are within a city or outside of it you can still dial 0xx or 0xxx (their 0 being our 1) and the carrier will route and bill it appropriately.




  • OK...this is meant to be half funny, and half serious, a dig at Cisco perhaps...

         So above, you said "The best solution would be if our carriers simply allowed us to always dial 10 digits", which is funny, because I just got done responding to another post about our constant NANP focus.  IMO, this should really be "The best solution would be if our carriers simply allowed us to always dial E.164...". :-)

         In the next sentence, you went to where I was going, which was the globalizatoin topic, which started this whole conversation.  I do a lot of work overseas, and just in the past year have been doing IPT in sites in China, Germany, Belgium, France, UK, Czech and Brazil, and have learned some very valuable lessons in regards to dial plans and number globalization.  Some of the biggest lessons, are in regards to using NANP focused things like @ and general dialing rules that many US engineers get into the habit of, that don't really work overseas.

         At the end of the day, if we just had SIP everywhere... :-) 

  • No matter the reason you may benefit from white or alternatively yellow page lookup to seek out residential numbers which originated from the area 503. And when you receive calls from a mobile phone it will likely be much harder to discover it, nevertheless with a little luck a good reverse lookup cell phone might take good care of that problem.

    Taken From |

    Once you get unexpected calls that come from that location, its likely they come out of large cities and towns. Having the exact code, the probabilities are higher that you'll determine the caller's personal information. You will make sure to bear in mind all of the loved ones or possibly class mates along with associates who're currently in this particular place beyond doubt.

    Needless to say it is possible to use white or simply yellow page lookup to follow household telephone numbers that can begin with that area code 503. And in the event that you get telephone calls originating from a cell phone it is usually much harder to trace it, however hopefully a really good reverse mobile phone search is likely to fix this trouble.

Sign In or Register to comment.