[cisco-voip] UCCX Call Redirect and Called Address Reset

[Bill Talley]

😊

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 <avholloway+cisco-voip at gmail.com> 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=+16515551902PreferredOriginalCalled=+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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20180924/98045cf4/attachment.html>