UCCX 8.5 - More numbers in one Trigger

Unanswered Question
Aug 25th, 2011

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

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Average Rating: 5 (6 ratings)
frzhang Thu, 08/25/2011 - 09:23
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 Thu, 08/25/2011 - 09:46

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.

jaroslav.srytr Mon, 08/29/2011 - 09:46

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 Mon, 08/29/2011 - 12:39

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

jaroslav.srytr Tue, 08/30/2011 - 05:40

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 Tue, 12/20/2011 - 09:30

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.

mfayed Wed, 08/31/2011 - 00:41

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 Wed, 02/08/2012 - 04:21

Thanks frzhang and Mohamad Fayed.

Using wildcard triggers has solved a big problem for me.

Great thread

Anthony Holloway Tue, 07/10/2012 - 05:24

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

Sent from Cisco Technical Support iPhone App

mfayed Tue, 07/10/2012 - 06:13

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 Tue, 11/06/2012 - 07:24

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.

Anthony Holloway Tue, 11/06/2012 - 07:52

ibodalija wrote:

The down side is - that you have to configure dummy phones...

Why?  You can have Active DN's in CUCM that are not on phones.  Besides, that wastes DLU's (or whatever Cisco is calling them today).  If anything, create CTI Route Points, as that makes much more sense for "routing" calls to UCCX.  And they don't cost anything in licensing.

Anthony Holloway

Please use the star ratings to help drive great content to the top of searches.

ibodalija Wed, 11/07/2012 - 06:30

You are absolutely right. I totally forgot about adding DN's on top of CTI route point! This is much neater than my workaround.

However regarding my not-so-neat workaround -> dummy phones don't consume DLU's (or whatever they are in V9) because those phones are never in registered status.

Cheers,

i.

Anthony Holloway Wed, 11/07/2012 - 10:14

ibodalija wrote:

...dummy phones don't consume DLU's...in V9...because those phones are never in registered status.

The more you know.

Anthony Holloway

Please use the star ratings to help drive great content to the top of searches.

Actions

Login or Register to take actions

This Discussion

Posted August 25, 2011 at 9:05 AM
Stats:
Replies:15 Avg. Rating:5
Views:3975 Votes:0
Shares:0
Tags: uccx8.5
+

Related Content

Discussions Leaderboard