Aspect ACD corrupting Variables

boyd.lynn · ‎09-30-2008

All,

We are using a NAM to pre-route calls to an Aspect ACD using Translation Routes. The calls are delivered to agent desktops and we are testing with CTIOS Agent Desktop. Unfortunately the Call Variables are being corrupted by the ACD. We use commas in Variable2 and the Aspect is treating these as delimiters and overwriting the other Variables 3-5. This is because the Aspect is using Contact Server and is configured to treat commas as delimiters.

Is there anyway of stopping the Aspect from overwriting the Variables. This can be done on Avaya and Meridian switched by using the /PIM command.

Cheers

Boyd

Riccardo Bua · ‎09-30-2008

Hi Boyd,

yes you could prevent the ACD from overriding the variables the same way, adding the switch in Configuration Manager see chapter 3.1 http://www.cisco.com/en/US/docs/voice_ip_comm/cust_contact/contact_center/icm_enterprise/acd_supplements/aspctacd.pdf

Regards,

Riccardo

PS Please rate useful posts accordingly

boyd.lynn · ‎09-30-2008

Hi Riccardo,

I have looked at the ACD supplement and cannot see anyway of stopping the Variables from being overwritten.

Our "Call Control Variable Map" is

/rte %d=dn /arr %d =dnis.

I would have thought that this meant that only Variable4/d is passed between the ACD and ICM during an Adjunct Route Request. However we see Variables3,4, and 5 being modified by the ACD.

Regards

Boyd

Riccardo Bua · ‎10-01-2008

Hi again Boyd,

it might be several things here, just as a shot in the dark, are you sure those variables info are not coming on a previous translation route for the same call?

Once the variables got set you need eventually a transfer to another CCT to reset them.

Try also this as a test:

Set OPC registry flag

"DontTranslationRouteConfiguredDNs" to work around scenario. The Registry Value when set to 1 tells OPC to ignore translation routing

calls for Route Request that are associated with a configured DialedNumber. This implies the dialed numbers used to perform the

Translation Route (i.e. RTEXXX) cannot be a configured DialedNumber in the ICM data base (which is OK).

The thing you need to make sure of before setting this registry flag is that the value for the "subtypes" specified in the CCTs to perform the Translation Route is not configured as a Dialed Number in the ICM Data

Base.

Regards,

Riccardo

boyd.lynn · ‎10-03-2008

Riccardo,

We did some more testing last nigh OOHs. Our findings are below.

1. The DNIS for the translations routes are not configured as DialedNumbers.

2. The values in the CallControlVariable Map don't seem to have any effect. We have /arr %d=dnis but even if this is removed the translation routes still works. Also Variables3-5 will always get modified if there are commas in Variable2 even though they are not mentioned in the CallControlVariabel Map.

3. We tried /pim nnnnnnnnn as used on the Avaya and Meridian but this command is not recognised by the Aspect pim.

Our routing scenario is as follows.

The SS7 Network makes a Route Request and the call is delivered via a translation route to CCT 903 on the Aspect. An Adjunct Route Request is performed in CCT903 and the call is delivered to the CCT matching the label returned from the PG. At no point are Variables3-5 send back to the ICM in either CCT.

If we could change the Field Separator on the Aspect the problem would be resolved but the documentation says that we have to use comma for Contact Server.

Regards

Boyd

Riccardo Bua · ‎10-03-2008

Thanks Boyd,

was Aspect involved in this discussion? I would suggest raising a TAC SR to keep track of all this and see the suitable options from a product/configuration prospective.

Regards,

Riccardo