HID Device Diagnostic
What a user needs to run through to collect signals from HID headsets to determine success or generate a proper ticket to get that device added to the verified list.
Feature Toggle by SupportXima support will need to enable the WEBRTC_HEADSET_CALL_CONTROL feature toggle. Request this in a ticket if you do not see the settings referenced in the article below.
The diagnostic tool is designed to test the signals the HID device send through the browser during a variety of actions. The goal is to capture a proper answer/hangup command but also to ensure any other actions (mute, volume up, etc) do not accidentally disconnect the call.
Have the agent who has the device connected to the PC via usb take the following steps:
- Have the agent first log into their CCAC
- Add the following slug to the CCAC URL:
/headset-diagnostics
Example https://TENANT NAME. xima.cloud/ccagent/en/headset-diagnostics - The agent may remain in DND during this test
- The agent will see the diagnostic tool. They should select "Connect my headset"
- Select the HID device from the list presented in the browser pop-up
- If the device is not listed in the browser-pop, Xima cannot use it and the diagnostic cannot continue. The site's IT team will need to determine why the agent's browser does not recognize the device
- Select "Use" next to the now listed device to move on
- Answer the 2 questions about the connection method and use of the product client software.
- Select "Start the test"
- The expected steps:
Step # Task Purpose 1 Do nothing. Wait for the tool to advance to step 2 automatically This step is listening for any constant signals that are coming from the device even if you are not doing anything. Such passive "noise" could result in auto-answers and disconnects if present and not accounted for. 2 Press the button on your headset that is intended to answer the call We need the signal sent for the answer button. 3 Press the answer button again as we simulate a call. NOTE: you may not hear the call but click answer anyways We need the signal sent for the answer button when a (fake) call is being offered 4 Stand the microphone arm straight up, and keep it there until we ask you to move it back. Some devices send a signal when the mic arm is in the full upright position. This is a common method for muting. Xima needs to know what signal it sends and ensure it doesn't get used as an answer/disconnect command. 5 Lower the mic arm back down Similar to #4, we need to make sure any "unmute" signals do not trigger an answer or disconnect action.. 6 Press the mute button (if present). This would be a button and not the action of moving the mic arm. Capturing the signal for a mute action so we can ensure it does not trigger an answer or disconnect action.. 7 Press the mute button (if present) to unmute. Capturing the signal for an unmute action so we can ensure it does not trigger an answer or disconnect action.. 8 Press the volume up button Capturing the signal so we ensure it does not trigger an answer or disconnect action. 9 Press the volume down button Capturing the signal so we ensure it does not trigger an answer or disconnect action. 10 Press the hangup button (usually the same as the answer button) to end the simulated call We need the signal sent for the disconnect action. 11 Stand the microphone arm straight up, and keep it there. This has a dual purpose as it's detecting any signal for when the mic arm is lifted when not on a call AND prepares the agent for the next step. 12 While the mic arm remains in the upright position, press the answer button Sometimes the signal that comes through when the button is pressed when the mic arm is up differs from when the arm is down 13 Lower the arm back down and press the button one more time Sometimes the signal that comes through when the arm has been lowered and the button is pressed differs. - Once you've reached the end, you will need to "Download result file" . This file will need to be shared with Xima support for engineering review. NOTE: If you question your actions and selections during any of the steps, it is better to start over then to submit a log and explain any testing concerns.
- If all applicable actions registered a recognizable/usable signal, the turn around time for adding the device to the verified list and a hotfix build may take 2-4 weeks once presented to development.
Updated about 14 hours ago
