More on Globalization

Mark made mention of bypassing the local option in a route list and said he would comback to it in ATC video 28 around minute 55, but I can't find where he came back to it.  Does anyone know, or here is the scenario:

Sites in Seattle, Austin and Amsterdame

If user calls +1 in Seattle or Austin it should use the local route group

If user calls +1 in Amsterdam it should use the Seattle gateway not the local gateway

Mark made it sound like there is a way to have the Route List contain the SLRG and SEA but skip the SLRG when the call is from AMS.

Was I confused?

Comments

  • I'm not sure, I'd have to go back and listen to my own video to recall ;-)

    What is it you are hoping to accomplish, and I'll be glad to help you out with the perfect solution. 



    Kind Regards,

    Mark Snow, CCIE #14073
    (Voice, Security)
    Instructor
    Internetwork Expert, Inc.
    INE Online Community
    INE Blog
    LinkedIn
    Toll Free: 877-224-8987
    Outside US: +1 775 826 4344

    - docendo discitur





    On Aug 8, 2011, at 18:59, Ahochau <[email protected]> wrote:

    Mark made mention of bypassing the local option in a route list and said he would comback to it in ATC video 28 around minute 55, but I can't find where he came back to it.  Does anyone know, or here is the scenario:

    Sites in Seattle, Austin and Amsterdame

    If user calls +1 in Seattle or Austin it should use the local route group

    If user calls +1 in Amsterdam it should use the Seattle gateway not the local gateway

    Mark made it sound like there is a way to have the Route List contain the SLRG and SEA but skip the SLRG when the call is from AMS.

    Was I confused?




    INE - The Industry Leader in CCIE Preparation

    http://www.INE.com



    Subscription information may be found at:

    http://www.ieoc.com/forums/ForumSubscriptions.aspx
  • I'm trying to do TEHO without having to create extra patterns etc.  In the video you made it sound like it was possible to skip the Local Route group in the routes list and go to the next.

    In Amsterdam:

    User dials 90013196021111

    Matches Translation Pattern 900.! replace CSS replace preDot with +

    Matches Route Pattern +1!  in PSTN PT and is sent to LRG

    At this point I would like it to skip the LRG and go to the next RG in the list which would be SEA.

    So far the only thing I have come up with is a separate US-TEHO PT that would have the same +1! pattern and list that before the PSTN PT but this would lead me to have to creat a CSS for each country that would be like NL-Globalized-to-PSTN that would list all other countries TEHO PT except their own.  Although this is possible, it seems cumbersome as the number of countries where there are offices grows.

    It seems like one has to trade the streamlined CSS & PT for globalization to be effective.  I still see the bennefits, but I see risk in handing the keys over to a client that has to ask which application he should, OS Administration or Disaster Recovery use to look at a gateway.  (True story btw) 

  • Hi Ahochau,

     

    Sorry, last night when I responded I wasn't in a location where I could quickly access the video to re-watch it and understand what exactly you were referencing, however I have now had a chance to do just that, and I think I understand why you were confused, thinking that possibly I was implying that there might be a way to accomplish TEHO without having to actually consider additional Route Patterns, but rather just possibly 'skip over' existing GW/Trunks/RGs in a given RL, and use the next GW/Trunk/RG in the list. 

    I apologize for any confusion that audio/text may have caused, however that is not the case. In order to route for TEHO you do have to configure additional Route Patterns. Here is more or less the audio that was spoken in that video at these rough timecodes, and the point I was trying to get to was in that second bit of text, namely that whether you arrive at a GW/Trunk due to TEHO or else due to the primary GW/Trunk in a RG or RL being unavailable, that the egress gateway is fully configured to handle any and all situations to make the digits properly localized for that connected egress carrier.


    55:02 "not necessarily built-in tail-end hopoff routes, I have to account for that we'll take a look at that"

    55:12 "once I get the call to that gateway, I have built-in (egress gateway localization)"

    As for coming back to that TEHO specific topic in the video, I probably should have clarified that a bit more, but I don't believe that I came back to the topic of TEHO in that concept video, but rather did circle back to that topic in one of the Outbound Dial Plan - Demonstration videos, which begin with video 30 and end on video 35.

     

    Hope this helps.



  • That is what I thought, but maybe you had some CCIE magic.  Thanks for the clarification.

Sign In or Register to comment.