UCCX 8.5 - More numbers in one Trigger

[jaroslav.srytr]

Hi,

I upgraded form UCCX 4.2 to UCCX 8.5

In UCCX 4.2 I had trigger with number 32XX and all works OK. But When I create this trigger in UCCX 8.5, call is rejected and in log I see this error:

14739: Aug 25 17:00:58.086 CEST %MIVR-SS_TEL-7-UNK:CallID: 9, MediaID: 1038/2 AddressCallObserver, Rejecting call, CTI Route Point: 3243 does not exists in route table.

If I create trigger with number 3243, all works fine. But I need route more numbers to one trigger and I can't use Translation Patter in CUCM, because in script I need know original called number.

Thank you for your help.

Regards,

Jaroslav Srytr

[frzhang · Accepted solution]

In CUCM, Service Parameters ->  Cisco CallManager, There is a new
parameter introduced in 8.0, "CTI Use Wildcard Pattern as
calledPartyDN". By default it's set to false. If you are using wildcard
RP, set it to true. So that, when JTAPI queries CUCM for the called
number, it will return the wildcard instead of actual dialed number.

[Anthony Holloway]

So if I upgrade a system that is using wild card triggers today, to 8x tomorrow, it wont work, and there will be no clear indication as to why?  I would most likely need to open a TAC case, or reconfigure my entire UCCX environment to now use individual triggers.  At least the dialed number and called number compatibility within scripting would carry me through, and no script changes would be necessary.

I'm glad I stumbled upon this topic today, as I use wild card triggers a lot in UCCX.

PS  Another thing like this that I ran into: phone service URLs, and using [Internal, External, Both].  I opened a TAC case on that one, and the TAC engineer spent 3 hours troubleshooting it, before I just happened to see this parameter.

Cisco Devs like to shake things up I guess, and keep us all on our toes.

[derek.fraser]

Excellent thread, thanks for the outlines on the topic.  The CCX wildcards are very helpful when pointing multiple remote sites to the same application/script.

I wanted to report my findings running CUCM 8.6.2.22900-9 and CCX Express 8.5.1.11004-25.

First set the CUCM Service Parameter "CTI Use Wildcard Pattern as calledPartyDN" to true.

Then in CUCM xlate the DID in to whatever your virtual range is, 6170009001, 02, etc.

Create the wildcard trigger in CCX 61700090XX, associate to application/script.  If your script is performing logic off DNIS you'll have to use the Dialed Number field in the CCX script "Get Call Contact Info"

Referencing the above example on CCX Express 8.5.1.11004-25 the breakout will be:

"Get Call Contact Info"

Called Number: 61700090XX

Original Called Number: 61700090XX

Dialed Number: 6170009001

As a side note set the Alerting ASCII Name in CCX to some generic text other than the default Trigger/DN number, that way your users won't see 61700090XX in their call history logs.

[Matthieu Frenaux]

Great Post !

I didn't know this Service Parameter.

It has just helped for a customer who is replacing thousands of DID numbers.

With only several Translation Patterns on CUCM, I can redirect every calls on old numbers to a CCX Script. This script reads the Dialed Number, requests a DB to get the new DID number, play the new number and transfert to the new DN.

Many thanks

Matthieu 

[jaroslav.srytr]

Hi,

Thank you for this response, but this is not solution of my problem.

If I set parameter "CTI Use Wildcard Pattern as calledPartyDN“ to true, call is forwarded to application, but problem is, that CUCM set “original called number” field to number of trigger, so application doesn’t work correctly, because hasn’t original called number, but number of trigger.

[Anthony Holloway]

This is normal and expected.  You must use Dialed Number instead of [Original] Called Number.

[jaroslav.srytr]

But there is problem, that if I set "CTI Use Wildcard Pattern as calledPartyDN" to true, dialed number (e.g. 3243) is not in JTAPI signalization:

324026: Aug 30 14:17:37.749 CEST %MIVR-SS_TEL-7-UNK:Call.received() JTAPICallContact[id=33,implId=14331/2,state=STATE_RECEIVED_IDX,inbound=true,App name=mpCR,task=null,session=null,seq num=-1,cn=32XX,dn=32XX,cgn=0225635874,ani=null,dnis=null,clid=null,atype=DIRECT,lrd=null,ocn=32XX,route=RP[num=32XX],OrigProtocolCallRef=00000000000037FB025406D200000000,DestProtocolCallRef=null,TP=null

In application I tried use "Called Number", "Original Called Number", "Dialed Number", "Original Dialed Number", but as I wrote above, dialed number is not presented in JTAPI signalization, so this didn't work.

Solution which works is:

- set "CTI Use Wildcard Pattern as calledPartyDN" to false

- create Route Point with number e.g. 3299

- create phone with number 32XX and set "Forward All" to 3299

- in application use "Original Called Number"

So I use telephone number as Route Point Number and all works fine, but it is very unusual solution.

[tornikezedginidze]

Hello,

I have the same problem with UCCX 8.5.1.10000-37, when used wildcard as Trigger number, can't get Dialed Number correctly, GetCallContactInfo returned wildcard. But with UCCX version 8.5.1.11002-22 it works ok.

It's a bug and here you can see the descripsion:

CSCtk76307

In your log:

324026: Aug 30 14:17:37.749 CEST %MIVR-SS_TEL-7-UNK:Call.received() JTAPICallContact[id=33,implId=14331/2,state=STATE_RECEIVED_IDX,inbound=true,App name=mpCR,task=null,session=null,seq num=-1,cn=32XX,dn=32XX,cgn=0225635874,ani=null,dnis=null,clid=null,atype=DIRECT,lrd=null,ocn=32XX,route=RP[num=32XX],OrigProtocolCallRef=00000000000037FB025406D200000000,DestProtocolCallRef=null,TP=null

dn=32XX will contain correct dialed number after updating UCCX. Eg: 3244. I need to try with updated version too.

[Mohamad Fayed]

Hi Jaroslav,

Wildcard Route Points were unsupported by JTAPI before 8.0, even if they were working fine before, they were not supported by JTAPI.

With 8.0, a service parameter was added to the CUCM, "CTI Use Wildcard Pattern as calledPartyDN". This is by default set to "False", which is the default behavior for applications.

However, this functionality is still unsupported by JTAPI when its set to false.

But, when the service parameter is changed to "True", Wildcard RPs are supported by JTAPI.

The application will see three connections on the call (EX: Caller, 878XX, and 87811), and this is not a valid call scenario for JTAPI, and one of the reasons this change had to be made to support Wildcard RPs.

So, to fully support Wildcard RPs, UCCX should run with the service parameter set to "true" on CUCM, check the API call CiscoCall.getModifiedCalledParty() for the DialedDN, and CiscoCall.getCurrentCalledParty() for the Pattern. This should occur only for the applications when you set the parameter to “True”.

However, I recently advised one of our customers to submit a feature\product enhancement request. FER could be requested to implement the change on the RP level and not globally as a service parameter “if that’s possible to be implemented”, so other CTI applications won’t be affected.

JTAPI interface specifications FYR:

http://wwwin-eng.cisco.com/cgi-bin/edcs/edcs_info?EDCS-702743

This was added in 02/18/2010.

Best regards,

Mohamad Fayed

[James Hawkins]

Thanks frzhang and Mohamad Fayed.

Using wildcard triggers has solved a big problem for me.

Great thread

[paolo bevilacqua]

JTAPI interface specifications FYR:
http://wwwin-eng.cisco.com/cgi-bin/edcs/edcs_info?EDCS-702743
This was added in 02/18/2010.
Best regards,
Mohamad Fayed

For those that wonder... this document is only accessible to cisco employees, and is also 'cisco reserved'.

[Anthony Holloway]

I would like to see a public version of this document. Thanks.

Sent from Cisco Technical Support iPhone App

[Mohamad Fayed]

Paolo, Anthony,

This is indeed Cisco internal link. It was my bad that I added it for external reference. So you can ignore it.

That link contains JTAPI interface specs, roadmap and changes has been made. This change is included there.

Rgrds

[ibodalija]

When you use translation patterns, originally called number info is lost for UCCX purposes (as far as I know).

Thats why I use a workaround.

• Create a virtual phone with DN A
  
• DN A has Forward ALL to DN B
  
• DN B is UCCX trigger
  

The UCCX step ”get call contact info” has an option of fetching “originally called number (i.e. the number A before it was forwarded).

This way, you can have just one UCCX trigger, and still get info you need.

The down side is - that you have to configure dummy phones (and it might look messy if you have a lots of numbers to "translate"), but it works regardless of CUCM/UCCX version.

Take care,

i.