Yes, I understand in the real world the new method has tons of advantages in regards to simplifying the dialplan if designed properly.
But for the LAB the new method in my opinion has far less flexibility. *2 examples:* 1. If I need backup gateways for a route pattern then "standard rl/rg" would not be optimal. 2. If I need different ANI depending on the type of call I am making then Calling party transformations on the gateway would cause issues. So in my mind, for the lab, the more flexible you can be with your dialplan the better. Obviously if requirements force you to use the new method (ie. least amount of RPs), then use the new method. I was just wondering what your or anyone elses thoughts/approach are for the new lab. I appreciate your input. Thank you, Mike Brooks CCIE#16027 (R&S) On Sun, Mar 21, 2010 at 9:18 PM, Otto Sanchez <[email protected]> wrote: > Hi Mike, > > I would get used to the new features and the new way to tackle the dial > plan, as they, in many cases will optimize the call routing configurations, > lets think about your example, if you would have used cd xform patterns, > only one route pattern and rl/ rg would have been used, also think in the > case you had not two but twenty sites and 4 route patterns each..., in this > case I would have used the new approach instead as my life would definitely > be easier, > > Please don't get me wrong as I'm not telling to forget about using the old > approach, just that you should take advantage of the new features and use > them wisely when sitting in the lab as in your daily basis job, > > hth, > > > On Sun, Mar 21, 2010 at 6:16 PM, Mike Brooks <[email protected]> wrote: > >> Thanks Otto. >> >> Yes I would not use standard local route groups if I had the option not >> to, but am exploring methods if forced to use standard local route groups >> based on requirements of the lab. >> >> For call routing what was your approach... old school ..or ....new school >> ? and why ? >> >> Thanks, >> >> Mike Brooks >> CCIE#16027 (R&S) >> >> On Sun, Mar 21, 2010 at 6:34 PM, Otto Sanchez <[email protected]>wrote: >> >>> Hi Mike, >>> >>> If using old school method, I think you wouldn't be using local route >>> group concept as well, right?. In that case you will need two separate RP, >>> two different RL/RG, in which case you can perform manipulations in RG >>> within RL and send the leading 9 only to the h.323 gw, >>> >>> If still want to use one RP and the standard local route group RL without >>> using cd xform patterns, I think the best way to sort this out for the h.323 >>> gw is to perform the manipulation in the incoming dial peer for the h.323 >>> like you mentioned as the srst dialing won't be affectedand will be the same >>> as when dialing from the ucm, also the dial plan will be simpler, >>> >>> If you don't add the leading 9 to the incoming dial peer, you will have >>> to configure two dial peers set for the same dialing and they will overlap >>> with each other, so this option is going to be much more complicated, >>> >>> hth, >>> >>> >>> On Sun, Mar 21, 2010 at 5:19 PM, Mike Brooks <[email protected]> wrote: >>> >>>> ahh..yes very good point... I have been moving away from the "new >>>> school" routing methods lately because of some of the flexibility issues I >>>> have ran into while using it. >>>> >>>> For instance ANI manipulation based on the type of call. >>>> >>>> I do prefer sticking to the "old school" routing method if possible, but >>>> I will play around with the called party transformations on the gateway. >>>> >>>> Thanks Randall !! >>>> >>>> Mike Brooks >>>> CCIE#16027 (R&S) >>>> >>>> >>>> >>>> >>>> >>>> On Sun, Mar 21, 2010 at 5:32 PM, Randall Saborio >>>> <[email protected]>wrote: >>>> >>>>> Mike (sorry, missed to copy the list on first try), >>>>> >>>>> >>>>> You are missing one option, which is the one I like most. >>>>> >>>>> For almost all situations, I would go about using Calling Party >>>>> Transformations and Called Party Transformations. >>>>> >>>>> Since these are device specific, you would make a Called Party >>>>> Transformation that would be used only by the H323 gateway, and there >>>>> prepend a 9. >>>>> >>>>> Then, on the gateway, you would stick with just one set of dial-peers >>>>> which are the same used for SRST. >>>>> >>>>> On Sun, Mar 21, 2010 at 2:39 PM, Mike Brooks <[email protected]>wrote: >>>>> >>>>>> Just want to know how most would handle this type of scenario. It >>>>>> appears there are multiple ways to configure this. >>>>>> >>>>>> >>>>>> 9.[2-9]XXXXXX -> Standard Local RL (must strip predot because HQ is >>>>>> mgcp gw) >>>>>> >>>>>> *HQ Device Pool:* >>>>>> Standard Local Route Group: HQ-MGCP-RG >>>>>> >>>>>> *BR1 Device Pool:* >>>>>> Standard Local Route Group: BR1-H323-RG >>>>>> >>>>>> >>>>>> If either an HQ or BR1 phone makes a local call 9.[2-9]XXXXXX we must >>>>>> strip the 9, regardless of which gateway it goes to because HQs standard >>>>>> local route group is an MGCP gateway. >>>>>> >>>>>> So on the BR1-H323 gateway you have 2 options: >>>>>> >>>>>> 1. make 2 sets of dial-peers with a leading "9" (for SRST) and without >>>>>> a leading "9". >>>>>> >>>>>> 2. on the inbound voip dial-peer preprend a "9" to the called number >>>>>> using a translation pattern. >>>>>> >>>>>> >>>>>> Which option seems to be the best choice and why ? Are there any >>>>>> other options ? >>>>>> >>>>>> Thank you, >>>>>> >>>>>> Mike Brooks >>>>>> CCIE#16027 (R&S) >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> For more information regarding industry leading CCIE Lab training, >>>>>> please visit www.ipexpert.com >>>>>> >>>>>> >>>>> >>>> >>>> _______________________________________________ >>>> For more information regarding industry leading CCIE Lab training, >>>> please visit www.ipexpert.com >>>> >>>> >>> >>> >>> -- >>> Regards, >>> >>> Otto Sanchez >>> CCIE #25592 (Voice) >>> Support Engineer - IPexpert, Inc. >>> URL: http://www.IPexpert.com <http://www.ipexpert.com/> >>> >> >> > > > -- > Regards, > > Otto Sanchez > CCIE #25592 (Voice) > Support Engineer - IPexpert, Inc. > URL: http://www.IPexpert.com <http://www.ipexpert.com/> >
_______________________________________________ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com
