Otto and I had a side-bar and came to a couple conclusions: If your ANI is not showing up properly on the test, then remember to check the RP and RL for transformations and change the transform pattern to match one until the ANI is correct. Probably will take less time to remember that and fiddle a little than try to memorize this mess and try to get it correct the first time.
Or just don't do transformation on the RP or RL and just do them on the xform pattern. We (I) maybe Otto thought of some already are trying to think of scenarios where one would need transformations on the RP/RL AND xform patt. ________________________________________ From: ccie_voice-boun...@onlinestudylist.com [ccie_voice-boun...@onlinestudylist.com] On Behalf Of Jonathan Charles [jonv...@gmail.com] Sent: Saturday, July 18, 2009 11:51 PM To: Vik Malhi Cc: OSL Group; Otto Sanchez Subject: Re: [OSL | CCIE_Voice] Calling Party Tranformation Patterns What we need here is a matrix of what calling party mods where do what and in what combination... I am noticing that if you go thru the translation pattern, you avoid your transformation patterns, and then use Route List mods... On Fri, Jul 17, 2009 at 12:09 PM, Vik Malhi<vma...@ipexpert.com> wrote: > Otto, > > I can only give you my opinion- the docs are weak in this area. > > Firstly- the docs support the notion that digit manipulation is compounded- > the only time they explicitly state one OVERRIDES the other is the RL-RG > overriding the RP. > > It seems to me the weird behavior would be related to the SIP Trunk. The > reason I say this is when manipulation occurs on the RP+RLRG then RLRG > overrides the RP as expected. When manipulation occurs at > RP+RLRG+CGNXformation then the RL is ignored and the RP+CGNXformation is > compounded. > > So for example: > > 1002 calling 911 > RP=911, CGN Prefix=1 > RL=SIPTrunk, CGN Prefix=2 > > When the call is sent to the PSTN the ANI is 21002. RLRG overrides RP. > > When a CGN Transformation Pattern is added and the appropriate CSS is > assigned to the CGN Xformation CSS on the SIP Trunk then... > > 1002 calling 911 > RP=911, CGN Prefix=1 > RL=SIPTrunk, CGN Prefix=2 > SIPTrunk with CGN Xformation CSS=CGN-SIP->pt-cgn-sip > CGN Xformation Pattern=!/pt-cgn-sip, CGN Prefix=3 > > According to the SRND I would expect to see the RLRG override the RP and > then the CGN Xformation compounded to the RLRG. Not so. When the call is > sent to the PSTN the ANI is 311002. I would expect this to be 321002. > > With H323/MGCP at least we have some more consistency- we can always state > that RLRG overrides the RP and when the CGN Xformation CSS is used this > overrides both RP and RLRG. > > It would be nice to see what the behavior is in UCM 7.1 out of interest... > > > > > -- > Vik Malhi – CCIE #13890, CCSI #31584 > Senior Technical Instructor - IPexpert, Inc. > > Telephone: +1.810.326.1444 > Fax: +1.810.454.0130 > Mailto: vma...@ipexpert.com > > > Join our free online support and peer group communities: > http://www.IPexpert.com/communities > IPexpert - The Global Leader in Self-Study, Classroom-Based, Video-On-Demand > and Audio Certification Training Tools for the Cisco CCIE R&S Lab, CCIE > Security Lab, CCIE Service Provider Lab , CCIE Voice Lab and CCIE Storage > Lab Certifications. > > > > > > > > ________________________________ > From: Otto Sanchez <otto.sanc...@daxa.com.ve> > Date: Thu, 16 Jul 2009 22:31:26 -0430 > To: OSL Group <ccie_voice@onlinestudylist.com> > Subject: [OSL | CCIE_Voice] Calling Party Tranformation Patterns > > Hey list, > > According to the UCM SRND the calling party transformation patterns are to > be matched with the result of the transformations performed at the RP/RL > level: > > ********************* > The calling and called party numbers resulting from the digit > transformations configured in the route pattern and/or route lists are then > processed by any Transformation Patterns configured for the devices > contained in the chosen Route Group. > ........ > If you are performing several digit manipulations in a route pattern or a > route group, the order in which the transformations are performed can impact > the resulting calling and called party numbers used for the call. Unified CM > performs the following major types of digit manipulations in the order > indicated: > 1. Discarding digits > 2. Called/calling party transformations > 3. Prefixing digits > 4. Called/calling party transformation patterns > ********************* > > However, this seems not to be the reality at least when a call is routed > through a RP pointing to a RL containing h.323 or mgcp gateways. > Furthermore, the lab 5c PG states (page 204) that "The calling party > transformation pattern match is based on the calling number at the point the > route pattern match took place", so a TP had to be inserted in between the > DN and the RP to transform the calling number and not match the already > created calling transformation pattern, and finally sort out the task 5.4. > > In contrast, when testing with a RP -> RL in which there is a sip-trk, the > results are more close to what the srnd states, i.e the RP calling party > transformation result is matched with the calling party transformation > patters set for the gw; with the exception that calling party > transformations performed on the RL level the results are ignored by the > calling party transformations patterns. So at the end there are mixed > results (at least with the testing I've been doing), and I couldn't come > with a clear conclusion of what should be happening..., > > If the SRND is correct, would the current ucm behavior represent a bug?, if > the PG is right, please kindly explain the process further and give some > docs references in order to get a better understanding, > > Help very appreciated, > > Otto > > > ________________________________ > _______________________________________________ > 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 > > _______________________________________________ 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
