TMAC_AgentDesktop

Issue: Supervisor cannot do silent monitoring or Barge-in for voice call in Agent-Desktop.

Issue Description:

Supervisor tried to do silent monitor/barge-in from Agent desktop can not perform as they can not hear anything in CM hardphone.

Trubleshooting/Initial Analysis:

Steps followed to perform the scenario:

1. Agent A logged into one station (ex: 40005) and Agent B (as a customer) logged into another station (ex:40030)
2. Supervisor also logged into one station (ex:40021)
3. When supervisor performs barge-in he can see below alert message but not able to hear anything from avaya hardphone.

> Please check if the faccodes mentioned in CM and tmacserver/widgets/default.json file matches.

> Please check if the faccodes mentioned in CM and tmacserver/widgets/default.json file matches.

> check for Tmac server logs and find the TSAPI event for makecall.

>> Please verify the settings in CM for station ID’s you are using to test.

Please check the COR value of stations being used to test.

Check for below highlighted values:

Root cause:

>> In COR settings, value for the variable “Can Be A Service Observed?” was set to “n”. In above screenshot we have shown COR value (2) of station 40030.

Resolution/Fix:

1. Please access avaya CM and run below command to check station COR value

Change station 40030

2. If the COR value is 1 (it can be 2 or something as it depends on each station), please run below command:

Change cor 2

3. In COR setting value for the variable “Can Be A Service Observed?” set to “y”.

4. Logout and Re-login to Agent-Desktop and stations and perform the testing. It should work fine.

Thanks,

a) Issue Description:

CIQ widget on Agent Desktop's Supervisor dashboard not showing any data even though items are there in queue for supervisor's team

b) Cause:

TMACDataServer not sending team data to Agent desktop to show on supervisor dashboard widgets

c) Troubleshooting

In order for TMACDataServer to send team data to supervisor dashboard widgets like CIQ and Skill Dashboard, config "Wallboard_SendTeamWallboard" should be enabled in TMAC Server config

<add key="Wallboard_SendTeamWallboard" value="1"/>

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.