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

[Anthony Holloway]

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 <btalley at gmail.com> 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 <
> 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=+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/d9483e91/attachment.html>