Yes, thanks, I just figured this out... It is weird that it is the destination that is doing that, but it seems to make sense and follow the original construct... if this were PSTN, it would be the gateway invoking the transformation pattern, so the final node phone to phone is a phone, so that makes sense...
So, what about the International Escape Character... +? Jonathan On Thu, Jul 23, 2009 at 4:17 PM, Vik Malhi<vma...@ipexpert.com> wrote: > Phones should NOT have use Calling Party Transformation Pattern CSS checked. > -- > Vik Malhi CCIE #13890 > 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: Jonathan Charles <jonv...@gmail.com> >> Date: Thu, 23 Jul 2009 16:04:14 -0500 >> To: Michael Ciarfello <mciarfe...@iplogic.com> >> Cc: OSL Group <ccie_voice@onlinestudylist.com>, Otto Sanchez >> <otto.sanc...@daxa.com.ve> >> Subject: Re: [OSL | CCIE_Voice] Calling Party Tranformation Patterns >> >> This is going to sound dumb, but I think I got the calling party >> transformations figured out, except for retaining the 4-digit ANI >> between sites... how do I do that? >> >> >> J >> >> On Wed, Jul 22, 2009 at 11:19 PM, Michael >> Ciarfello<mciarfe...@iplogic.com> wrote: >>> Here is my testing summary for Route Pattern, Route List and Transformation >>> Pattern transformations. Compared against 7.0(1) and >>> 7.1(2a). We are testing 7.1(2a) to see if behavior changed (if there was a >>> possible "bug" in 7.0(1). >>> >>> The CSS for the xform pattern (HQ_XFORM_CSS) only contained one PT >>> (HQ_XFORM_PT) for the xform pattern. >>> I have a 5-digit dial plan and don't use IPExpert's. Sorry for any intended >>> confusion. I probably should switch back to using theirs. I just wanted a >>> more complex dialplan. My dialplan has conflicting and overlapping numbers >>> (45XXX for HQ, 64XXX for BR1 and 44XXX for BR2) It also follows some real >>> cisco numbers in NYC, San Jose and Tokyo. >>> >>> 7.0(1) SIP: >>> HQ phone 1 (45001) dials 9.19001234567 >>> Prefix digits on the route pattern (111) >>> and prefix digits on the RL (222) >>> Calling Transform Pattern 45XXX with prefix digits 333 >>> PSTN Phone shows 22245001. Doesn't hit the transform pattern and uses the >>> RL transformation (which overwrites the route pattern transformation.) >>> The calling party number in the trace file shows 11145001. >>> So I changed the transform pattern to 11145XXX >>> Now the PSTN phone shows 33311145001. I would intrepret this as the route >>> pattern's prefix got prepended, then the transform pattern matched and >>> prepended the 333 to the resulting transformation of the route pattern. >>> >>> 07/18/2009 01:30:06.202 CCM|SPROC DATransformMatch - matchNumber [11145001] >>> transformCSSPkid [45ece7a3-264c-0e86-4c9a-b7c9f108dfc8] transformationCss >>> [HQ_911_XFORM_PT] patternUsage [15] paternNodeID >>> [42cf1e0b-a2c0-6d54-5067-195be977104a] OutpulsedNum.nd [33311145001] tn [0] >>> pi [1] npi >>> [0]|<CLID::StandAloneCluster><NID::142.6.64.12><LVL::Arbitrary><MASK::0800> >>> >>> ------ >>> 7.0(1) MGCP/H323: >>> BR1 Phone 2 (64002) dials 9.19001234567 >>> Prefix digits on the route pattern (444) >>> and prefix digits on the RL (555) >>> Calling Transform Pattern 64XXX with prefix digits 666 >>> PSTN phone shows 66664002. So this hits the transform pattern. Trace file >>> shows it. >>> >>> 07/18/2009 01:34:39.719 CCM|SPROC DATransformMatch - matchNumber [64002] >>> transformCSSPkid [aca1739f-ec61-1f46-87e1-6bd991d15678] transformationCss >>> [BR1_911_XFORM_PT] patternUsage [15] paternNodeID >>> [795003d7-ea44-9cb8-e450-e41ebca818d3] OutpulsedNum.nd [66664002] tn [0] pi >>> [1] npi >>> [0]|<CLID::StandAloneCluster><NID::142.6.64.12><LVL::Arbitrary><MASK::0800> >>> >>> The calling party number in the trace files shows 44464002. (I didn't paste >>> it) >>> So I changed the transform pattern to 44464XXX >>> Now the PSTN phone shows 55564002. It didn't go through the transform >>> pattern. Becasue there's no patternNodeID??? Anyways, we took the correct >>> RL transformation. >>> >>> 07/18/2009 01:25:32.261 CCM|SPROC DATransformMatch - matchNumber [64002] >>> transformCSSPkid [aca1739f-ec61-1f46-87e1-6bd991d15678] transformationCss >>> [BR1_911_XFORM_PT] patternUsage [2] paternNodeID [] OutpulsedNum.nd >>> [55564002] tn [0] pi [1] npi >>> [0]|<CLID::StandAloneCluster><NID::142.6.64.12><LVL::Arbitrary><MASK::0800> >>> >>> Two different behaviors for two different trunk types. Let's see what >>> 7.1(2a) does. We repeat the experiment. >>> >>> >>> ================== >>> 7.1(2a) SIP: >>> HQ phone 1 (45001) dials 9.19001234567 >>> Prefix digits on the route pattern (111) >>> and prefix digits on the RL (222) >>> Calling Transform Pattern 45XXX with prefix digits 333 >>> PSTN Phone shows 33345001, so uses the transform. >>> The calling party number in the trace files shows 11145001. >>> So I changed the transform pattern to 11145XXX >>> Now the PSTN phone shows 22245001. Skips (didn't match) the xform patt and >>> uses the RL transform >>> 7.1(2a) MGCP/H323: >>> BR1 Phone 2 (64002) dials 9.19001234567 >>> Prefix digits on the route pattern (444) >>> and prefix digits on the RL (555) >>> Calling Transform Pattern 64XXX with prefix digits 666 >>> PSTN phone shows 66664002 >>> The calling party number in the trace files shows 55564002. >>> So I changed the transform pattern to 55564XXX >>> Now the PSTN phone shows 55564002. Skips (didn't match) the xform patt and >>> uses the RL transform >>> So 7.1(2a) seems to make sense and has consistent behavior for different >>> trunk types. >>> ------------- >>> NOW, the translation pattern trick is also different. I didn't document it >>> here for 7.0(1). >>> HQ Phone 1 dialing through the translation pattern trick and the PSTN phone >>> shows 33345001. >>> Trace files showed CallingPartyNumber=11145001, so we change the xform >>> pattern to 11145XXX. The PSTN phone now shows 22245001 >>> If add a prefix (777) on the translation pattern, (xform pattern is back to >>> 45XXX) get 22277745001. >>> Trace files show: >>> 07/23/2009 00:05:38.768 CCM||PretransformCallingPartyNumber=77745001 >>> |CallingPartyNumber=11177745001 >>> Change the xform pattern to 77745XXX get 33377745001 >>> Change the xform pattern to 11177745XXX get 22277745001 >>> Same behavior for BR1's MGCP. >>> Does 7.1(2a) seem consistent with the SRND statements? My brain hurts. >>> >>> ________________________________ >>> From: ccie_voice-boun...@onlinestudylist.com >>> [ccie_voice-boun...@onlinestudylist.com] On Behalf Of Otto Sanchez >>> [otto.sanc...@daxa.com.ve] >>> Sent: Thursday, July 16, 2009 11:01 PM >>> To: 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
