<div dir="ltr">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.<div><br></div><div>*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.</div></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Sep 24, 2018 at 2:53 PM Bill Talley <<a href="mailto:btalley@gmail.com">btalley@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto">😊<div><br></div><div>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?</div><div><br></div><div>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. <br><br><div id="m_-2730233968876681079AppleMailSignature" dir="ltr"><p style="margin:0px;font-stretch:normal;font-size:12px;line-height:normal;font-family:Helvetica"><span style="font-size:12pt">Sent from an iOS device with very tiny touchscreen input keys. Please excude my typtos.</span></p></div><div dir="ltr"><br>On Sep 24, 2018, at 2:01 PM, Anthony Holloway <<a href="mailto:avholloway+cisco-voip@gmail.com" target="_blank">avholloway+cisco-voip@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">Damn! You played a Reverse card on me! Well played.<div><br></div><div>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.</div><div><br></div><div>I did some testing with the Redirect CSS setting on the CTI Ports as well, and here are some findings.</div><div><br></div><div>I have three phone numbers in this test:<br></div><div><ul><li>+16515551901 is my IP Phone<br></li><li>+16515551902 is my VM Pilot (Call Redirect Destination)<br></li><li>+16515551903 is my Voice Mailbox (Call Redirect Reset Called Address to)<br></li></ul><div>I have two Partitions in this test:</div></div><div><ul><li><b>calling</b> has my IP Phone and my VM Pilot</li><li><b>port</b> has my CTI Port<br><br>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).</li></ul></div><div>I have two CSSs in this test:</div><div><ul><li><b>calling</b> CSS which can only reach <b>calling</b> PT (on my calling device (my phone))<br></li><li><b>port</b> CSS which can only reach <b>port</b> PT (on my CTI Port)<br></li></ul></div><div><b>Example call with CTI Port Redirect CSS set to Calling Party (uses my phone CSS to reach VM pilot and called address)</b><br></div><div><div><font face="monospace, monospace">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")</font></div><div><span style="font-family:monospace,monospace">27900093.007 |11:10:33.852 |AppInfo |Digit analysis: analysis results</span> <font face="monospace, monospace"><br></font></div><div><br></div><div><font face="monospace, monospace">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")</font></div></div><div><font face="monospace, monospace"><div>27900103.013 |11:10:33.853 |AppInfo |Digit analysis: analysis results</div></font></div><div><br></div><div><b>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)</b><br></div><div><div><font face="monospace, monospace">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")</font></div><div><span style="font-family:monospace,monospace">28020535</span><font face="monospace, monospace">.007 |11:13:51.421 |AppInfo |Digit analysis: potentialMatches=NoPotentialMatchesExist</font> <font face="monospace, monospace"><br></font></div><div><br></div><div><font face="monospace, monospace">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")</font></div></div><div><span style="font-family:monospace,monospace">28020548</span><font face="monospace, monospace">.007 |11:13:51.422 |AppInfo |Digit analysis: potentialMatches=NoPotentialMatchesExist<br></font></div><div><br></div><div>Note that, I did not test the Redirect CSS setting of DN Calling Search Space, because the documentation says it's deprecated.<br></div><div><br></div><div>Also note the order of DA: first its for the mailbox (Call Redirect Called Address), then the DA for the VM pilot happens second. <br></div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div><b>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</b></div><div><div><font face="monospace, monospace">79624786.000 |13:30:03.172 |SdlSig |<span style="background-color:rgb(244,204,204)">CtiLineCallRedirectReq</span> |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 <span style="background-color:rgb(255,242,204)">DestAddr=+16515551902</span><span style="background-color:rgb(217,234,211)">PreferredOriginalCalled=+16515551903</span> RedirectReason=0 ModifiedCalling Num= ModifiedCallingType=0 FAC= CMC=</font></div></div><div><br></div><div>In that one line we see that the <span style="background-color:rgb(255,242,204)">DestAddr</span> is the VM Pilot and the <span style="background-color:rgb(217,234,211)">PreferredOriginalCalled</span> 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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div></div></div></div></div></div></div></div></div></div></div></div>
</div></blockquote></div></div></blockquote></div>