TMAC_AgentDesktop

Issue: If we change the status to any other aux codes in Agent-Desktop it sets to default status.

Issue Description:

When we log in to Agent-Desktop and try to change the status from “Available” to any other aux codes like Break/Meeting/Logout it sets to “Default”.

Troubleshooting/Initial Analysis:

1. Please check if reason codes are added in Avaya CM.

2. Please check if same configured in OCM> Agent> Agent Aux Codes Module.

3. Please check Avaya CM settings

Execute the following command: display system-parameters features - go to page 14 - Aux Work Reason Code Type to be set to "forced"

Root Cause:

Aux work reason code type in avaya CM was set to “none”

Resolution/Fix:

We must use “forced” value to “Aux Work Reason Code Types” in avaya CM.

Once the changes are made, please restart TMAC service and login to Agent-Desktop.

Issue: Voice tab is not seen instead  Chat tab is seen in Agent-Desktop when voice call is initiated.

Troubleshooting/Analysis:

1. Please make sure you are dialing to proper voice skill configured in Avaya CM.
2. Make sure voice skill is assigned to agent in OCM under skill assignment module.

3. Please check the extension range in Chat Server Config.

4. Check the ANI configured in textchatserverconfig.json and template.config file in TMAC server. Make sure this range is exactly same as that configured in Chat Server Config as point 3. If this value has range of that of incoming voice call ANI, then chat tab would be shown.

Root Cause:
ANI number configured in textchatserverconfig.json and template.config in TMAC server has wrong extension range means it was including voice extension range.
Example:
Voice ANI/VDN: 1000-2000
Chat range: 3000-4000 (as configured in chat server)
Should work fine.

Resolution/Fix:
Mentioning valid chat skill range in textchatserverconfig.json and template.config of TMAC server. We have made sure that voice skill extension range did not lie in chat ANI range.

Issue: when Agent A initiates consult transfer/conference to Agent B from Agent-Desktop , “confirm” button is disabled/greyed out to Agent A after Agent B receives/answers the call.

Issue Description:

Agent A logged into Agent-Desktop with valid LAN ID and station ID and receives call then does consult transfers/conference the call to skill/agent list.

Agent B logged into Agent-Desktop with different LAN ID and station ID. Agent B receives the call. Now, Agent A should be able to see “confirm” button. But here Agent A can not see “confirm” button as it is greyed out. Also UCID receiving is all 0’s from AES.

Troubleshooting/Initial Analysis:

1. Please make sure that agents are using different station ID.
2. Make sure Agent A has received the call.
3. Check for exception/error in TMAC server logs. If so, we need to resolve that.
4. Check for “remote connected” keyword in TMAC server logs.

In above screenshot (example), Agent B (service.nto:1004) receives the call, onconnect event in tmac server then for agent A (2001:1003) says type=TransferRemoteConnected. If we see “TransferRemoteConnected” then there won’t be issue with TMAC server end.

5.Check TMAC server logs for UCID and it should be unique. If we are receiving all 0’s for UCID then something needs to be checked from avaya CM side.

UCID information is received from avaya AES-> CM to our application.

6. Please check for UCID settings in Avaya CM.

Root Cause:

1. UCID receiving all 0’s from Avaya CM end.
2. UCID related settings is not valid in Avaya CM.

Resolution/Fix:

We should have below settings in Avaya CM for UCID.

Post these changes we can restart TMAC server and re-login to Agent-Desktop. Then “confirm” button should be visible and should work fine. Also UCID we are receiving unique id’s.

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".

Issue Description: Signalr Registration fails in TMAC Server with System.EntryPointNotFound Exception in logs as shown below:

Cause: This error occurred because there was a backup file of TMACServerCore.dll present in the TMAC Server

Resolution: verify if there are any duplicate files present in the TMAC Server Folder. Delete it if present and restart the TMAC Server.

Below lines should be printed in TMAC Server logs after service restart indicating successful registration of signalr server URL in TMAC.

Issue Description:

In the 'Active Agents' Section of the Agent Desktop- Supervisor console , the agent names are duplicate meaning there are two records for the same agents.

Cause:

When we see the agents list duplicate , we need to check the TMAC Data Server component which is the data source for the above.

The TMAC Data Server will fetch the logged in agents based on the team id. So we need to check the configuration of the TMAC Data Server component and logs for the same.

When we check the configuration of the TMAC Data Server , template.config and TMC_Data.json . the TMAC end point configured for primary TMAC and secondary TMAC both are pointing to same TMAC.

this caused the fetching the duplicate data set and display the same agent twice.

Resolution:

In case if you find the above cause suitable ; then we can update the configuration as stated below

• Navigate to the TMAC Data Server folder and find the TMC_Data.json
• Find the primary and secondary IP configured in the file, update the secondary IP to the secondary server. If stand-alone setup blank value is the preferred setting.
• Save the File and restart the TMAC Data Server Windows service to reflect the config changes
• Move back to Agent-Desktop Supervisor console once Data Serve is up, then refresh the active agents list

Note: the  config file update depends on what type of configuration you have opted example if you deployed through TMC then the primary and secondary IP will be on the TMC_GlobalData.json. In another case if you opted 'none'/xml configuration mode then configuration file for the above is .exe.config.