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
