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

[Bill Talley]

“When RCSS is set to Redirecting Party, the call was routed normally with an untransformed called party.”

I dunno, how did that make you feel?

Sent from an iOS device with very tiny touchscreen input keys.  Please excude my typtos.

> On Sep 21, 2018, at 12:03 PM, Anthony Holloway <avholloway+cisco-voip at gmail.com> wrote:
> 
> "... and was able to replicate your results."
> 
> And how did that make you feel?
> 
>> On Wed, Sep 19, 2018 at 5:21 PM Bill Talley <btalley at gmail.com> wrote:
>> Anthony,
>> 
>> So I just tested this scenario as you've laid out and was able to replicate your results.  That said, I encountered different results testing with internal calls and external inbound calls.
>> 
>> With internal calls like an internal user calling the help desk queue, the redirected call acted in the manner Anthony described when the Redirecting Calling Search Space on the CTI Ports was set to anything but Redirecting Party.  If the RCSS was set to Calling Party or DN Calling Search Space, I encountered the results you've described in which the called party is transformed via the transform masking on the route pattern, then delivered to CUC.  When RCSS is set to Redirecting Party, the call was routed normally with an untransformed called party.
>> 
>> With external inbound calls, the call was treated the way we would expect in that the called number is not transformed and was routed to CUC with the correct called party destination.
>> 
>> The results were the same regardless of whether the route pattern was visible by the CSS of the CTI port or not.
>> 
>> Hope this helps.
>> 
>>> On Tue, Sep 18, 2018 at 5:04 PM Bill Talley <btalley at gmail.com> wrote:
>>> Not yet, just finished a customer install early this morning.  Planning to test it out tomorrow when I get back to my lab.
>>> 
>>> Sent from an iOS device with very tiny touchscreen input keys.  Please excude my typtos.
>>> 
>>>> On Sep 18, 2018, at 4:52 PM, Anthony Holloway <avholloway+cisco-voip at gmail.com> wrote:
>>>> 
>>>> Update: I've been working a TAC case for a few days on this now, and I have not made any progress.  I also posted this scenario in the Advanced Dial Plan WebEx Teams space, but no replies so far.
>>>> 
>>>> Bill, have you tested this out?  Anyone else have some experience with this?
>>>> 
>>>>> On Tue, Sep 11, 2018 at 4:57 PM Anthony Holloway <avholloway+cisco-voip at gmail.com> wrote:
>>>>> I didn't know this, and so I thought I'd share, but who knows, maybe it was common knowledge.
>>>>> 
>>>>> If you use the Call Redirect step in UCCX to send a call directly to a mailbox/call handler in CUC, and thus, your Destination is the VM Pilot, while your target object in CUC is your Called Adddress, like so:
>>>>> 
>>>>> <image.png>
>>>>> 
>>>>> Then either one of two things will happen (only one of them I'm ok with):
>>>>> 
>>>>> 1) If there is a pattern in CUCM for which 1000 will match; say a Route Pattern such as 1XXX which prefixes an 8 and route calls to a 3rd Party PBX, then CUCM will use the Called Number Transformations on this Route Pattern to prefix the 8 on your 1000, and then send the call to CUC with 81000 as the Redir number, and you'll be all messed up.  Actually, you'll just get the opening greeting, but still...grrrr
>>>>> 
>>>>> 2) If there is no pattern in CUCM for which 1000 will match, then CUCM sends the call to CUC, and the redir is 1000 and everything works fine.
>>>>> 
>>>>> I'll let you guess which one I'm ok with, and which one I'm not.
>>>>> 
>>>>> Why in the hell is CUCM performing number transformations on this call flow like that?  It makes no sense.  What am I missing here?
>>>> _______________________________________________
>>>> cisco-voip mailing list
>>>> cisco-voip at puck.nether.net
>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20180921/980add5c/attachment.html>