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

[Anthony Holloway]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20180924/4021b11c/attachment.html>