Hi Michael, I believe your tests in 7.1(2a) are now more consistent across the gw types than we have seen in the 7.0(1) version, I would summarize them as follow (pretty much the same as PG states): 1.- UCM looks for a cg xform pattern match at the RP level, if there's a match (calling# vs pattern), subsequent calling party xforms performed at RP/RL are irrelevant, otherwise, RP/RL xforms take place, 2.- If you insert a TP in between the DN and RP you can modify how the calling # gets to the RP, hence, avoiding/hitting an existing cg xform pattern. This will allow you to create multiple cg xform patters for the same originating DN, depending on the call destination In contrast, the results are mixed for SIP and H.323/MGCP GWs running with UCM 7.0(1), and we have to keep that in mind unless 7.1(2a) is the version to be rolled out for the lab, Whether the 7.1(2a) results are consistent with the SRND statements, hmm, I still would say they are not, however, the discussion is open, I would like to hear what others may be thinking about this (maybe I'm just missing something obviuos), here's what the srnd says: "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."
Thanks for your input to the list!, Otto ________________________________ De: Michael Ciarfello [mailto:mciarfe...@iplogic.com] Enviado el: mié 22/07/2009 23:49 Para: Otto Sanchez; ccie_voice@onlinestudylist.com Asunto: RE: Calling Party Tranformation Patterns 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
