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

Anthony Holloway avholloway+cisco-voip at gmail.com
Fri Sep 21 12:03:47 EDT 2018


"... 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/ef9686c3/attachment.html>


More information about the cisco-voip mailing list