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
