TPP Virtual Assist

Scenario: A customer has logged on to the VIVR page and has opted for the Chat with Us menu. Once the menu was selected, customer has inserted the NRIC and OTP number successfully and waiting to route to live agent. After a few seconds of being in queue, customer receives “Thank you for your patience. Our service representatives are currently engaged” display message.

On TMAC UI, there is an available agent with the correct skill assigned.

Cross-check possibilities

• Set sendteam_wallboard = 1 in template.config>TMAC Server
• Ensure the agent’s chat channel count is 5 [Useronboarding> OCM]

Logs:

Chatbot.log shows the variable1 = -1

The sys.wallboard.stf. prints the Skill number that is configured in the Session_Master.json_approved and chat_rules.json

Findings:

Ensure that the vdn and skills configured in chat_intentmaster.json, chat_rules.json and Session_Master.json_approved correctly, cross check with Avaya what is set on their end.

Chat_intentmaster – should configure the vdn numbers for mainINVEbankSIT and mainINVEcardSIT

Chat_rules – should configure the skill numbers for check card agent availability and check bank agent availability

Session_Master.json_approved – should configure the skill numbers that will be printed in the chatbot logs.

Issue description:

ChatBot not able to receive concurrent chat when VisualIVR is in audio/video mode, Even after having "On Call" state in the valid state list of WorkQueue and TMAC Server configuration.

i.e when the ChatBot is processing one chat, the second chat will be in queue, instead of processing concurrent chat.

Troubleshooting steps:

• Check if audio/video channel is limited to receive concurrent calls in TMAC configuration.

Solution:

• Remove the required channel(audio/video) from "GenericRouter_LimitCallChannels".

Note: If the "On Call" state is not been added in valid state list then refer https://docs.tetherfi.com/faqs/Agent-not-receiving-Concurrent-Calls-(VIVR-Calls)

Issue description:

Agents are not receiving concurrent calls even when the channel count is set to more than three. i.e when the agent is “on Call” the second call will be in queue, instead of call connecting to agent.

However, as soon as the first call gets disconnected and agent goes back to available state, the second call will be connected to agent.

Troubleshooting steps:

• Check if state check is enabled/disabled.
• If State check is enabled then check if the "On Call" state has been added in valid state list of WorkQueue and TMAC Server configuration file.

Solution 1:

• Disable state check for each channels. Key name is "CheckStateForEachChannelEnabled".

Solution 2:

• If state check is enabled then based on the chat mode("textchat","audiochat","videochat") add "On Call" state in the valid state list. Key name is "ValidStateListFor_*". where, * means channel name.

• Also add "On Call" state in the valid state list of TMAC server configuration, Key name is "WorkQueueRouteAgentStateList".

When VIVR is executing the IW flow with help of chatbot, page is on Call queued. The workqueue is trying to assign the flow, however chatbot is not able to execute the flow since its already working on one flow. Here we have add one Aux state to workqueue where it considers to assign the event to chatbot even when it's working on one flow. The workqueue timeout is set in textchat server config, post that vivr is back to captcha page.

In workqueue template.config, we have add the aux state

<add key="ValidStateListFor_textchat" value="Available,On Call"/>

Also check the Agent state of chatbot if 'ACW for each call ' should not be enabled.

Issue: Captcha does not display in the chatbot Security Check page and errors are displayed in the console as shown in below screenshots

Resolution:

Ensure that the fully qualified path of Text Chat Proxy folder is provided as 'overridePath' key value in tetherfichat.js file as highlighted below:

Issue:

The VIVR keeps loading after Remote User Connected Event and do not proceed to the chat bot flow execution.

Description:

When user access the Visual IVR URL to execute the chat bot flow, the bot flow after captcha keeps loading and do not execute the actual bot flow.The above scenario even after the below basic primary checks.

• The chat bot agent logged in to TMAC Server.
• Chat bot agent has the correct skills which T.Comm Server routed to it.
• All the TPPVA(Chat Bot server), T.Comm Server, TMAC Server and IWE are up and running.

Troubleshooting:

• In the Console log of VIVR , we can see that Call Queued , RemoteUserConnected events received.
• Next step, if we trace the session id in TComm Server log, it is routing to correct agent and 'Agent Connected' event from TMAC to the chatbot agent.
• After sometime TComm server received the same event of 'Session start' with same chatbot agent id from TMAC Server. Which result to TComm server result in the Conferencing/Transfer.
• Since the both the agent IDs are same the coonference/transfer fails in TextChat server and hence disconnect the first session established.
• if we troubleshoot further with TMAC Server and ChatBot Server log, we can see that once the incoming chat the TMAC Server routes to the Chat bot server. In the Chatbot server for the session id there are no further process and error 'LoadInteractionClass' (could be other dlls as well).
• which results in TMAC send to resend the agent connect event to TComm server.

Cause:

the error on the chat bot server log as below caused due to the dll called 'chatbotSelfServiceBot.dll' is been blocked by the OS security policy.

Resolution:

Right click on the specific dll blocked and unblock . The restart the Chat Bot server service.

In case if you would like to unblock the multiple dlls at a time , then open the Power shell in administrator mode then execute the below command

dir -Path [application folder path] -Recurse | Unblock-File

Issue Description:

In chatbot scenarios while agent node get executed for queue transfer, VIVR can be configured to show the item Queue Position in the WorkQueue. The UI displaying the count may appear stuck in refresh  mode.

Resolution: 

1. Verifty Chatbot (TPPVA) configuration for WorkQueue connections.
2. Verify whether in template.config "EnableQueuePositionInfromer" flag is set to 1.

Issue Description:

Chatbot IW Flow disconnection at Module node.

Procedure:

1. Add created module name in template.config file of TPPVA
2. Add module name in ModuleEngineUrls.json file of TPPVA
3. Restart TPPVA

a)  Issue Description: 

During an IVR call, the customer may request for a deflect to digital option. The IVR then generates a Chatbot URL with the voice call UCID in query string and sends the URL to customer's mobile phone via SMS.

When the customer opens the Chatbot URL, customer gets connected to TPPVA via TComm proxy and TComm server. And the TPPVA has to check if the link is still valid and if not valid, then customer should get notified. If that does not happen, then it is considered as an issue.

b) Cause

When connected to TPPVA, there are few checks to be done:

1. Is the link expired
   1. TPPVA gets the time of the voice call from IVR_Call_History table based on the UCID
   2. TPPVA has a configuration to find the link expiry time (SessionValidForInMins)
   3. TPPVA checks if the link is expired, and if yes, then sends a message to customer and ends the chat. The message to send to customer is read from "ErrorMessageFile" (a json file path in config) - key->"InvalidSession"
2. Is the UCID already used:
   1. TPPVA allows the usage of each UCID only once.
   2. To check the repetitive usage of sessions ID within 15 minutes intervals, we use a variable in UserSessionValidator.dll. It is a List of UCIDs which are already used by a user. When the user connects to TPPVA for the first time, we add the UCID to this List variable. However, we do not sync this List variable data with other TPPVA servers.
   3. When the user comes in a second time, we check for the UCID in the List variable and decide to block or proceed. But, If the user gets connected to a different TPPVA on the second try, we will not have the UCID in the List, and we allow the user to proceed.

c) Troubleshooting

Few more configuration variables used and their meaning:

ValidateSession - When set to "0", session validation will be totally disabled

ValidateCif - When set to "1", TPPVA checks if the CIF is present in chat user data. If not present, an error message sent to customer

ValidateUcid - When set to "1", validates if the link with this UCID already expired.

AllowUcidOnlyOnce - When set to "1", one UCID will be allowed only once in one TPPVA server.

ErrorMessageFile  - path to a JSON file with a key/value data with error messages to be sent to customer when session validation fails.

verify the WQ app config <add key="ValidStateListFor_textchat" value="Available,On Call" />
In OCM check the number of tabs configure for TPPVA agent. After making change restart TPPVA.

a) Issue Description

TPPVA logs show the following error

ERROR AMACWeb_Proxy.TmacConnector - EndpointNotFoundExceptionOccured:System.ServiceModel.EndpointNotFoundException: There was no endpoint listening at http://ip:port/TMACServer/ that could accept the message. This is often caused by an incorrect address or SOAP action. See InnerException, if present, for more details. ---> System.Net.WebException: The remote server returned an error: (404) Not Found.

b) Cause

TPPVA is not able to connect to TMAC Server.

c) Troubleshooting

1. Ensure TMAC Server service is up and running. If not, start the TMAC Server service. Once it’s started, open its endpoint in a browser to verify service description comes up.
2. Ensure TMAC Server endpoint is correctly mentioned in TPPVA config (key "chatbot.conf.tmacserver1") as shown in the below screenshot. This should match the endpoint given for TMAC Server in TMAC Server config.
3. 

a) Issue Description

TPPVA logs keep showing the following debug log repeatedly

b) Cause

TPPVA is not able to connect to IW Interpreter to process a incoming chat request.

c) Troubleshooting

1. Ensure Tomcat service in which IWInterpreter is deployed is running successfully.
2. Ensure IWInterpreter application is correctly installed on Tomcat. You can verify this by inputting url "http://<ip>:<port>/IWInterpreterWebApp/restServices/CheckStatus" in browser. ip and port should be replaced with ip and port on which tomcat is running. It should show success as shown in below screenshot
3. 
4. Ensure Correct endpoint of IWInterpreter is mentioned in TPPVA config as shown in below screenshot (Key "chatbot.conf.iwurl1")
5. 

a) Issue Description

TPPVA logs keep showing the following debug log repeatedly

b) Cause

TPPVA is not able to connect to Self Service Layer Interpreter to process Self Service module required as per Chat Flow.

c) Troubleshooting

1. Ensure Tomcat service in which Self Service Layeris deployed is running successfully.
2. Ensure Self Service Layer application is correctly installed on Tomcat. You can verify this by inputting url "http://<ip>:<port>/VirtualAgentSelfServiceLayer/" in browser. ip and port should be replaced with ip and port on which tomcat is running. It should show success as shown in below screenshot
3. 
4. Ensure Correct endpoint of Self Service Layer is mentioned in TPPVA config as shown in below screenshot (Key "chatbot.conf.selfservice1")
5.