VIVR

Issue description:

After Agent A transfers the chat interaction to Agent B, messages sent from Agent B is not able to display in VIVR page. But agent will be able to read messages sent from customer.

Troubleshooting steps:

1. Check TMAC Server log for texts typed the agent
2. Look for same message in TComm Server log
3. If message present in TComm Server log it confirms that message is sent out of TComm server to VIVR via TComm proxy

Root Cause:

VVIV page checks for agent details in the incoming chat events, if the access role value is missing or empty in agent details then vivr will not be able to display the text message.

Resolution:

Assign the access role to agent in "Role Mapping" tab of OCM User Onboarding module for both the Agent A and Agent B.

Issue Description:- While using the MqApi web url (http://<IP>/mqapi/mqapi/ID/getEncryptedData?input=<plaintext>  for IVR/VIVR Database credential encryption if the plain text has "#" Hash character then the application will ignore the characters post# while encrypting and it may lead to DB connectivity error OR DB lock .

Resolution :- Replace the "#" in PlainText with "%23" while encrypting .

Ex :- for encrypting PlainText key "Adity#a" pass "Adity%23" which passing input in encryption URL

Note:- we can decrypt the encrypted key using below web url call for verification

http://<IP>/mqapi/mqapi/ID/getDecryptedData?input=<EncryptedText>

Issue description: 

Captcha in VIVR application keeps reloading to the same page after captcha has successfully entered

Troubleshooting:

Visual IVR uses livechatsdk which connects to a communication proxy (chatproxy). The initiation of the session and exchange of message from VIVR UI to Chatproxy will be via livechatsdk. When sdk fails to connect / fails to receive the response from chatproxy on time, the session fails. This would lead the VIVR page to reload to captcha page.

Checklist

1. In the browser console network tab verify whether the request to chatproxy is successful
2. Check the chatproxy log for any errors in API method call
3. In the browser console network tab, verify if session stickiness is implemented in the infra load-balancer by monitoring cookies that is used for stickiness configuration.  Ref:  https://docs.tetherfi.com/faqs/load-balancer-with-session-stickiness-configuration-and-troubleshooting/
4. Check for filter settings in tomcat/jboss server configuration.   Look for following filter and expression in configuration (server.xml / standalone.xml)                                                                 <filter-ref name="requestDumperExpression"/>                                                              <expression-filter name="requestDumperExpression" expression="dump-request"/>
5. Remove above two line from the configuration

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.

Requirement: To disable camera/mic/geolocation request during VIVR page load.

Resolution: Set the following key values to "false" in application-config.json

"chatmode":"text"

"audioEnabled": false
"videoEnabled": false

"enableRestriction": false
"enableAVcheck": false

Requirement:

For mapping the Customer Identifier (CIF) in the VIVR URL would require primary reference value (Ex: UCID/ACCOUN_NUMBER/LOAN_ID) into GBL_Interaction_history. So that reporting module can fetch the reference fields and represent in OCM reports such as AVPlayback report etc..

Configuration:

1. Pass the parameter in the URL as query string that is declared in VIVR config.                            Ex: https://nabilbank.tetherfilabs.com:8443/visual-ivr/captcha?intent=main&ucid=110215594558024250&node=75241665-42c4-4170-b3ea-f2f67083afd8
2. The query string should be a variable predefined in "VIVR" custom headers.  The same header needs to be mapped in comm proxy customer json.
3. In TMAC Server --> chatJsonConfig.config file, map the Query string value declared in comm proxy  customer json to TMAC variable. Ex: "node: "CIF". where value of query string "node" will be mapped to "cif". Hence the value of column "CIF" in GBL_Interaction_history table will be the value of "node".

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:

When the customer using the VIVR and opted to agent route. On this Agent Desktop(AD) will open the video screen directly (not escalate to video) wherein the agent can see the self video as well as the customer video. On another hand, the customer will be still on the call queue page of  VIVR i.e. no video screen displayed to him.

Troubleshooting:

• Open VIVR web console screen and open the VIVR configuration object, find the channel configuration. In this double-check the configuration loaded properly as chatmode:video.
• Open the VIVR console and check if the AV signalling is as expected (refer the MediaServer Operational Manul for the signalling sequence)
• Next, Check for the RemoteUserConnected event, the latest event should be for the live agent i.e. in the event data you can see the agent id to differentiate between the chatbot agent id and live agent id.

Cause: 

The configuration in VIVR of 'chatmode' is set to the 'video'. In this scenario, VIVR is initiating video requests to the remote user end using the communication proxy(chat proxy). When VIVR receives the multiple 'RemoteUserConnected' events with different agent ID will cause this scenario.

This is due to the 'AutoCallqueue' in the communication proxy set to 'true' will create duplicate queuing.

Reference:TComm Server queuing same customer session twice

Resolution:

Disabling this configuration from the communication proxy, 'proxyconfig.jsp' page fixed the issue.

At certain video cc solutions, there may be a need for escalating chat sessions or after the IW flow execution to video chat/session. The configuration goes like this,

In vivr/assets/app-config.json set the field "chatmode:video".