“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 > <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 >>>> <[email protected]> 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 >>>>> <[email protected]> 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 >>>> [email protected] >>>> https://puck.nether.net/mailman/listinfo/cisco-voip
_______________________________________________ cisco-voip mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-voip
