AACC 6.4 SP15: Collected digits are incorrect when played back to caller

Doc ID    SOLN287050
Version:    1.0
Status:    Published
Published date:    08 Apr 2016
Author:   
Matthew Whittard
 

Details

When callers enter their phone number the playback heard was, ‘The number you have entered was 123’ when the caller had actually entered their 10 digit number. Customer had created the script but could not get the playback and validation to work as desired.

Problem Clarification

Inbound caller waiting in queue are offered a call back from AACC scripting. The aacc script collects the ten digits that the caller has entered and then validates digits entered. If the digits collected are valid, the details are playback to the customer to accept or enter another number. The criteria was that a ten digit validation check must be performed prior to playing back the number to the caller. A valid number is ten digits in length and must start with leading digit zero. Once validated and the caller accepts this as the correct number to perform a call back the number must then be written to an external database by AACC. The customer’s third party application will then perform a data dip and collect the details in order to present the agent with an outbound call to return the customers enquiry. This customer is on a AACC 6.4 SP 15 SIP solution using AMS for call playback and call anchoring located in Australia.

Cause

When using c_sip_digits_int_cv to collect leading zero it is an invalid integer and is not allowed as described in Orchestration Designer document in Table 24 Page 232 Leading Zero Allowed is NO. Below is an extract of the TFE log when using c_sip_digits_int_cv The playback to the caller is 123 as this is the default value assign in CCMA scripting variables for c_sip_digits_int_cv. Even though the TFE log shows the full ten digits being collected starting with zero it is invalid STYPE - Short PushOp pushing Stype value = 123 - Data being return and subsequently played back to the caller 2016-03-24 16:20:01.733 0 TRACE [Scheduler] Num Treatment Params = 8 2016-03-24 16:20:01.733 0 TRACE [Scheduler] [00] Name: prompttoplay, Value: CBA_VG_NoCLI 2016-03-24 16:20:01.733 0 TRACE [Scheduler] [01] Name: vxmlfrom, Value: [email protected] 2016-03-24 16:20:01.733 0 TRACE [Scheduler] [02] Name: vxmlto, Value: [email protected] 2016-03-24 16:20:01.733 0 TRACE [Scheduler] [03] Name: notypeahead, Value: false 2016-03-24 16:20:01.733 0 TRACE [Scheduler] [04] Name: numberofdigits, Value: 10 2016-03-24 16:20:01.733 0 TRACE [Scheduler] [05] Name: termchar, Value: # 2016-03-24 16:20:01.733 0 TRACE [Scheduler] [06] Name: interdigittimeout, Value: 10 2016-03-24 16:20:01.733 0 TRACE [Scheduler] [07] Name: RETURNS, Value: true 2016-03-24 16:20:01.733 0 TRACE [Scheduler] Return Parameters ----------------- 2016-03-24 16:20:01.733 0 TRACE [Scheduler] Num Return Params = 1 2016-03-24 16:20:01.733 0 TRACE [Scheduler] [00] Name: c_sip_digits_int_cv, Value: 0246278016, Type: STYPE - Short, VarId: 131 2016-03-24 16:20:01.733 0 TRACE [Scheduler] *********** SIP IVR DATA Display End *********** 2016-03-24 16:20:01.733 0 DEBUG [Scheduler] CPCall::IVRComplete(): CallId = 0037366000 2016-03-24 16:20:01.733 0 DEBUG [Scheduler] CPCall::IVRComplete(): UnLocking Call in ASM, CallId = 0037366000 2016-03-24 16:20:01.733 0 DEBUG [Scheduler] IvrReturnData::getReturnParamValue(): 0 = 0246278016 2016-03-24 16:20:01.733 0 DEBUG [Scheduler] CPCall::IVRComplete(): Sending the returned data to EB. 2016-03-24 16:20:01.733 0 DEBUG [Scheduler] IvrReturnData::getReturnParamValue(): 0 = 0246278016  Digits entered by caller are correct 2016-03-24 16:20:01.733 0 DEBUG [Scheduler] SDMEventLogger::LogDigitsCollectionCompleted(): before send(p_MessageLogger) - CallId = 0037366000 2016-03-24 16:20:01.733 0 DEBUG [Scheduler] NISDM_clThread::sendMessage(): Message Added to Queue 2016-03-24 16:20:01.733 0 DEBUG [Scheduler] SDMEventLogger::LogDigitsCollectionCompleted(): after send(p_MessageLogger) - CallId = 0037366000 2016-03-24 16:20:01.733 0 DEBUG [TSM_Event] [0037366000] TSM Event (0x0245) - PRIM_UNLOCK_CALL_RESP 2016-03-24 16:20:01.733 0 TRC_2 [TSM_Event] NITSM_clThread::updateBurstTsmCount(): burstTsmCount= 2 2016-03-24 16:20:01.733 0 DEBUG [Scheduler] SDMEventLogger::LogGiveIVRCompleted(): before send(p_MessageLogger) - CallId = 0037366000 2016-03-24 16:20:01.733 0 TRACE [SDMLogger] NISDM_clThread::threadFun(): before ComProxy->Send... 2016-03-24 16:20:01.733 0 DEBUG [Scheduler] NISDM_clThread::sendMessage(): Message Added to Queue 2016-03-24 16:20:01.733 0 DEBUG [Scheduler] SDMEventLogger::LogGiveIVRCompleted(): after send(p_MessageLogger) - CallId = 0037366000 2016-03-24 16:20:01.733 0 DEBUG [Scheduler] [0037366000]CPCall::checkEventHandler(): Event = 6, Result = 1, Event Handler = 1, EH Present? = 0, CallState = CNTL_READY 2016-03-24 16:20:01.733 0 DEBUG [Scheduler] CPCall::checkEventHandler() - Event is not handled by Event Handler, callid=0037366000 2016-03-24 16:20:01.733 0 DEBUG [Scheduler] executeNextCall(): FC_LEV_0 - Re-execute CallId (0037366000) 2016-03-24 16:20:01.733 0 TRACE [Scheduler] ExecMach::startExec(): CallId = 0037366000 2016-03-24 16:20:01.733 0 TRACE [Scheduler] [0037366000] PushOp pushing Stype value = 123 2016-03-24 16:20:01.733 0 TRACE [Scheduler] [0037366000] PushOp pushing Stype value = 1 2016-03-24 16:20:01.733 0 TRACE [Scheduler] [0037366000] UnaryMinusOp 2016-03-24 16:20:01.733 0 TRACE [Scheduler] [0037366000] UnaryMinusOp - data = 1 2016-03-24 16:20:01.733 0 TRACE [Scheduler] [0037366000] EqualToOp (stack) = NO (-1 = 123) 2016-03-24 16:20:01.733 0 TRACE [Scheduler] [0037366000] BranchIfFalseOp -- BRANCH IF FALSE (PC = 0x48) 2016-03-24 16:20:01.733 16 TRACE [Scheduler] [0037366000] PushOp pushing Stype value = 123

Solution

Even though in the same table 24 STRING data type are shown as leading zero not allowed, string call variables will allow leading digit zero. This is a documentation error and will be corrected. The solution is to capture the leading first digit as String type as the country code for this customer (Australia) is all leading digit zero followed by 9 additional digits. AACC scripting can not perform digit verification when using strings so the other 9 digits are collected in integer and evaluated. Work around solution:- To overcome these problem the AACC script was modified and the leading digit is now collected into c_sip_digits_str_cv instead, then the other 9 digits are collected into c_sip_digits_int_cv. Since the first announcement plays to the caller ‘Please enter your phone number including area code’ the prompttoplay for c_sip_digits_int_cv still must be fulfilled so a 3 seconds blank silent recording is used. Digit length is not readily available in AACC scripting only upper and lower values can be evaluated. The second lowest digit in Australia is 2 for Sydney and highest 8 is Western Australia, therefore AACC evaluates the last 9 digits. If the caller enters less than 9 digits then this is seen as false and does not playback the number. IF (c_sip_digits_int_cv > 200000000) AND (c_sip_digits_int_cv < 899999999) The script also checks to make sure the leading digit 0 is entered first by the caller by using string match. If any other number is entered as the first number this is seen as false and asked the caller to re-renter the number again.

Avaya -- Proprietary. Use pursuant to the terms of your signed agreement or Avaya policy