DSS were approached to solve a custom problem. A contact centre made use of an audio mixing device at the call takers desk (the Omnitronics DX64). This device gave the operative the ability to listen to multiple audio inputs including telephone, two way radio and television. The DX64 enabled the audio inputs to be presented to a single device; the operators headset.
The DX64 also provides the ability to record telephone input. This functionality however relied on a relay to advise it when a call was in progress (relay open) or not (relay closed).
The customer was upgrading their traditional Alcatel-Lucent PBX to enable a VoIP network. This move however meant also the decommission of the solution which triggered the DX64 relay. This was previously a module that sat between the agents digital handset and the DX64. The replacement VoIP handsets did not provide the same capability.
DSS proposed, designed, developed and delivered a custom server-side service listening to Alcatel switch events and sending on/off events to a network of WebRelay devices which in turn activate the DX64 relay on each agent's desktop.
At DSS, we take the 'Dependable' part of our name pretty seriously. And this particular customer required a very reliable service. So, we spared no effort in the design and build of the solution.
We broke the problem in to three parts:
The client executes an authentication module, starts a session with the Alcatel server, retrieves current state for each agent's desktop, enqueues this to the message queue for processing, then subscribes to receive related telephony events from now on.
The client was designed to enable continual operation regardless of server, network or client issues. To date it has run seamlessly without restart for close to 1 year.
The system provides an extremely flexible configuration file based error handling capability. System administrators can configure the solution to move back to any one of these modules based on individual issues. So, if required, the solution can re-subscribe, restart the current session then resubscribe, or authenticate again and continue from the beginning. Also, if individual errors may work under retry scenarios these can also be configured followed by max retry failure next steps.
The customer did not want the overhead of managing a separate messaging system, however the solution needed to be flexible enough to cater to 10, 100 or more agents. We implemented an internal messaging queue while exposing a range of suitable configuration items. These enable us and the client's support area to tweak important aspects of the solution as they expand their network. Settings such as maximum queue depth as well as thread pool settings for the pool of worker threads spawned to handle incoming events.
This component runs a configured count of worker threads to handle events taken from the message queue. Each thread has the task of determining whether the event represents that the state of the associated agent's relay has changed. If it has changed, the thread addresses the relay across the network and requests it to turn on or off. The thread waits for a successful response. If no successful response is received it will retry a configured count of times before emailing the support desk of the problematic relay device and then discarding the event.
If you have a problem that seems too hard to solve right now, get in touch with us and we will be happy to have a chat about possible solutions. We're always excited by new challenges and while small we have a great network of partners who are always happy to work collaboratively to achieve an outcome.