I can't change it, because I need that pattern for calls that we do send that way. So, I need my cake, and to be able to eat it too. As a work around, I am just creating one off DNs for the patterns in question*. In the real world, it's not 1XXX, rather, this is an environment which thought +E164 formatting was a monolithic approach to numbering plans, and therefore all non-DIDs follow the format +1NPA555XXXX. When I use this non-DID pattern for the purpose of sending calls from UCCX to a Voice Enabled Directory handler, it's matching the +1.651[2-9]XXXXXX Route Pattern for PSTN local calls. From UCCX, we also send calls to the PSTN, and that's why I cannot just remove the pattern, else it breaks our ability to call the PSTN.
*I'm also considering creating a +1651555XXXX pattern, which does nothing to the digits, and will cover all non-DID, but I'm unsure at the moment the scope of impact this will have, as opposed to just creating one-off patterns. On Mon, Sep 24, 2018 at 2:53 PM Bill Talley <[email protected]> wrote: > 😊 > > Maybe I’m oversimplifying the work around (having not seen your > environment), but could you not just set your redirect CSS to one that > doesn’t have visibility of the 1XXX route pattern? > > FWIW, I have agreed with your assessment 100%. It makes no sense at all > why CCM is performing DA/DM on dialed numbers while also ignoring routing > info. It would make a little more sense if the call was matching the route > pattern due to use of the redirect css and routing the call out the route > list/gateway, but with it ONLY modifying called party info, that’s crazy as > hell. > > Sent from an iOS device with very tiny touchscreen input keys. Please > excude my typtos. > > On Sep 24, 2018, at 2:01 PM, Anthony Holloway < > [email protected]> wrote: > > Damn! You played a Reverse card on me! Well played. > > Well, here's how it made me feel. You were just testing the use of > different CSSs, which caused a difference in Digit Analysis. You didn't > provide any logs to review, but I assume you have a different CSS on each > of the: CTI Port, VGW, and IP Phone; as most designs would call for. > > I did some testing with the Redirect CSS setting on the CTI Ports as well, > and here are some findings. > > I have three phone numbers in this test: > > - +16515551901 is my IP Phone > - +16515551902 is my VM Pilot (Call Redirect Destination) > - +16515551903 is my Voice Mailbox (Call Redirect Reset Called Address > to) > > I have two Partitions in this test: > > - *calling* has my IP Phone and my VM Pilot > - *port* has my CTI Port > > Note that I do not have a pattern even built to match the voice > mailbox, so it should go to CUC unmolested (which it does). > > I have two CSSs in this test: > > - *calling* CSS which can only reach *calling* PT (on my calling > device (my phone)) > - *port* CSS which can only reach *port* PT (on my CTI Port) > > *Example call with CTI Port Redirect CSS set to Calling Party (uses my > phone CSS to reach VM pilot and called address)* > 27900093.006 |11:10:33.852 |AppInfo |Digit analysis: > match(pi="1",fqcn="+16515551901", cn="+16515551901", plv="5", > pss="calling", TodFilteredPss="calling", dd="+16515551903",dac="1") > 27900093.007 |11:10:33.852 |AppInfo |Digit analysis: analysis results > > 27900103.012 |11:10:33.853 |AppInfo |Digit analysis: match(pi="1", > fqcn="+16515551901", cn="+16515551901",plv="5", pss="calling", > TodFilteredPss="calling", dd="+16515551902",dac="1") > 27900103.013 |11:10:33.853 |AppInfo |Digit analysis: analysis results > > *Example call with CTI Port Redirect CSS set to Redirect Party (uses CTI > Port CSS to try and reach, but fails, the VM pilot and called address)* > 28020535.006 |11:13:51.421 |AppInfo |Digit analysis: > match(pi="1",fqcn="+16515551901", cn="+16515551901", plv="5", pss="port", > TodFilteredPss="port", dd="+16515551903",dac="1") > 28020535.007 |11:13:51.421 |AppInfo |Digit analysis: > potentialMatches=NoPotentialMatchesExist > > 28020548.006 |11:13:51.422 |AppInfo |Digit analysis: > match(pi="1",fqcn="+16515551901", cn="+16515551901", plv="5", pss="port", > TodFilteredPss="port", dd="+16515551902",dac="1") > 28020548.007 |11:13:51.422 |AppInfo |Digit analysis: > potentialMatches=NoPotentialMatchesExist > > Note that, I did not test the Redirect CSS setting of DN Calling Search > Space, because the documentation says it's deprecated. > > Also note the order of DA: first its for the mailbox (Call Redirect Called > Address), then the DA for the VM pilot happens second. > > Also note that, I don't have to place an inbound call from outside, since > the calling CSS would just be used on my VGW, as opposed to my phone in > these tests. It doesn't matter what the calling device is, just what its > CSS is. > > Further, the only time an OffNet or OnNet determination is needed, is when > forwarding on the CTI Route Point, I.e., Call Forward Busy Internal vs > External. I'm not testing that, so, we can skip it for now. > > Ok, so what did this simple test show me? Well, it shows the actual > impact of changing the setting on the CTI Ports' Redirect CSS: Calling > Party and Redirect Party, and how that changes the Partition Search Space > (PSS) used in DA, which affects the Call Redirect Called Address, as that > DA is performed before the DA for the Call Redirect Destination. I already > know that it's Partitions and Calling Search Spaces which dictate which and > how patterns are matched, that was never the issue. The issue is with CUCM > performing DA on, *and* manipulating the Called Address, when I was trying > to call the VM pilot, not the Called Address. And changing the CSS/PT is > not an option for me right now, since the pattern we're hitting for DA on > the Called Address is a pattern that I actually need UCCX to see. > > *From a CTI Manager perspective (different test call, so timestamps are > later), you can see how CTI manager receives the Call Redirect request from > UCCX* > 79624786.000 |13:30:03.172 |SdlSig |CtiLineCallRedirectReq |ready > |CTIDeviceLineMgr(3,200,25,1) |CTIHandler(3,200,22,1461) > |3,200,13,1468.359280^172.16.B.C^* |[R:N-H:0,N:0,L:0,V:0,Z:0,D:0] > AsyncResponse=279506 CH=3|53896065 LH=3|54438 OriginalCalled=2 > mUnconditionalRedirect=0 DestAddr=+16515551902 > PreferredOriginalCalled=+16515551903 RedirectReason=0 ModifiedCalling > Num= ModifiedCallingType=0 FAC= CMC= > > In that one line we see that the DestAddr is the VM Pilot and the > PreferredOriginalCalled is the mailbox. So perhaps CUCM could be coded > to not perform DA on CTI PreferredOriginalCalled fields, or perhaps UCCX > can be coded to send the call to CUCM differently. I'd be ok with either, > as long as the Called Address wasn't being sent through DA, as there's no > point, and works counter intuitive to how the rest of CUCM works. > > FWIW, I opened a TAC case, and was told it's working as designed. So, I > lost that battle, and I just have to engineer around this feature. > > Disclaimer: I compiled this reply over the span of a few hours, and made a > lot of edits before sending. I hope I didn't make any editing mistakes, > but if I did, I'll reply with corrections. > >
_______________________________________________ cisco-voip mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-voip
