[cisco-voip] UCCX Script redirect

Ed Leatherman ealeatherman at gmail.com
Mon Jun 13 15:17:43 EDT 2016


I ran across this a few weeks ago and ended up sorting through it the way
Anthony describes - that seems like such a strange default behavior to me
on the CTI RP. I swear I thought it was NOT like that some time back (UCCX
3 or 4?) because I distinctly remember doing my best to make sure no one
could call those CTI ports directly - but never had to deal with that
additional setting on the RP. I didn't find it explained all that well
either in the docs.

On Mon, Jun 13, 2016 at 10:35 AM, Anthony Holloway <
avholloway+cisco-voip at gmail.com> wrote:

> On a related topic of CSS/PT for UCCX that a lot of people miss, is that
> you don't need to add your UCCX CTI Port's DN PT to your device CSSs (E..g,
> gateways and phones)....IF....you set it up right.  Here's how...
>
> Put your CTI Port DNs in a partition labeled something like
> UCCX-Private-PT, or UCCX-Restricted-PT, or even
> UCCX-Needs-A-New-Script-Editor-PT.  The point is, you can name it whatever
> you want.
>
> Then create a CSS for your CTI Route Points, that will house this new UCCX
> PT for your CTI Port's DNs.  Again, name it whatever you like:
> "UCCX-Can-Has-Precision-Routing-Queues-CSS."  Now, here's the most
> important step, you have to switch the setting "Calling Search Space for
> Redirect" on the CTI Route Point from "Default Calling Search Space" to
> "Route Point Address Search Space."
>
> This will allow you to do two things:
>
> 1) Remove the possibility of someone dialing a CTI Port Directly, which
> shouldn't do any harm really, but come on, let's just stop it from even
> being possible, because who knows what might happen?
>
> 2) Use whatever numbering plan and number range you wish, as it will never
> conflict with the rest of your Enterprise Numbering Plan or Dial Plan, as
> the CTI Route Point will only ever need to reach the CTI Ports, and no
> where else.  Who here has ever dealt with trying to fit Non-DID DNs into a
> +E164 plan and ended up with something like: +11000003201 as the CTI Port
> DN?
>
>
> Note that this has nothing to do with how you redirect calls off of CTI
> Ports as in the original question.  That is separate and can be handled in
> one of two ways:
>
> 1) The way Brian mentioned, which is the default, and that is to use the
> configured CSS on the CTI ports to route calls
>
> 2) Change the CTI Port CSS "Redirect Calling Search Space" from "Redirect
> Party" (aka the CTI Ports) to "Calling Party" (aka the device which made
> the call into UCCX; for PSTN callers this is your gateway/trunk).
>
> It should be obvious that "Calling Party" only works if there is a calling
> party.  This will not work if you have an HTTP triggered application which
> places an outbound call.  Therefore, use your port groups wisely.
>
>
> On Thu, Jun 9, 2016 at 3:59 PM, Brian Meade <bmeade90 at vt.edu> wrote:
>
>> It uses the CSS of the CTI Ports for these redirects.  I usually put
>> these type of specific UCCX redirect route patterns in one of my UCCX
>> partitions to fix these kinds of things.
>>
>> On Thu, Jun 9, 2016 at 4:52 PM, Aaron Banks <amichaelbanks at hotmail.com>
>> wrote:
>>
>>> I'm having a little trouble with a script redirect.  The redirect works
>>> fine, but the call is being sent to a PRI instead of a SIP trunk.  How it
>>> works is the call comes in over the SIP trunk to a RP and then is sent to
>>> UCCX script with a couple of options.  Selecting either option sends the
>>> call to a DID outside of the enterprise.  I have put in a route pattern
>>> that is an exact match to one of the options selected in the IVR.  My
>>> question is - do I have a pattern matching problem or is the CSS of the CTI
>>> port being used (which, if true, I know exactly what the problem is).  I
>>> had the redirect CSS on the trigger set to be the route point, but that
>>> clearly is not working.
>>>
>>>
>>> Any comments, suggestions, mild criticism appreciated.
>>>
>>>
>>> Aaron
>>>
>>> _______________________________________________
>>> cisco-voip mailing list
>>> cisco-voip at puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>
>>>
>>
>> _______________________________________________
>> cisco-voip mailing list
>> cisco-voip at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>>
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>


-- 
Ed Leatherman
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20160613/fa631bae/attachment.html>


More information about the cisco-voip mailing list