Control Signals
Device integration enables the transfer of control signals between UC Client and Jabra device. The transmission, reception and interpretation of control signals is a decisive factor for consistent system behaviour.
Triggers
Control signals can be triggered by:
- Hardware button presses at the device
- Software button presses in the UC Client GUI
- Automatic actions of either the device or the UC Client
- Device-related operations like changes in boom arm position for selected devices like Jabra Engage 50
The way of transmission depends on the transmitter of the control signal.
Transmission
The transmitter of a control signal determines the circle of recipients.
| Signal Transmitter | Transmission | Description | Example of Application |
|---|---|---|---|
| From Jabra Device to UC Client | Broadcast | The device sends control signals to all UC Clients in the system. | Hardware button press at the device or Hardware Controls. |
| From UC Client to Jabra Device | Direct Adressing | The UC Client sends control signals directly to the device. Other UC Clients in the system do not receive these control signals. | Software button press in UC Client GUI. |
A Jabra device is not able to address a specific UC Client. Consequently, all active UC Clients receive and need to interpret all control signals send by the device.
Interpretation
This interpretation of control signals is often based on assumptions and consequently error-prone.
Reasons are for example:
- UC Clients are not aware of any control signal sent by other UC Clients
- some control signals are ambiguous
The following examples demonstrate the transmission of control signals between UC Clients and Jabra devices for different user actions.
Example A. No Device Integration
UC Client without Device Integration: no connection and no transfer of control signals between device and UC Client.
UC Clients without device integration can not communicate with a device. There is no transfer of control signals between UC Client and device.
You can operate the UC Client only via button presses in software GUI. Hardware button presses do not work.
Example B. Hardware Button Press
A button press in Hardware Controls broadcasts the control signal to all active UC Clients.
A Jabra device is not able to adress a specific UC Client. Instead, it broadcasts control signals to all active UC Clients that use device integration.
Example C. Software Button Press
Software button presses send a control signal directly to a device. This signal is directly addressed, the receiver is defined.
The device, however, may respond with another control signal. This signal is broadcasted to all UC Clients and the receiver is not defined.
Case Description
The use case features:
- A Jabra headset as device
- Three active UC Clients on the same system
- Active Call on UC Client 1
- Call on Hold on UC Client 3
All UC Clients use device integration with USB HID ans Standard Telephony Usage Page. USB HID does not offer any functionality to manage parallel calls.
User actions:
- The user presses a software button in UC Client 1 to end the active call
- UC Client 3 should retain the call on hold. The user does not press any button on UC Client 3.
The following section describes the flow of control signals for this specific use case.
Step 1. Software Button Press sends On-hook Signal
The button press in UC Client 1 sends an On-hook Signal to the device.
Control signals from software button presses are send to the Jabra device directly. The other UC Clients in the system are not aware of this communication
Step 2. Device hangs up Active Call
The device cancels the active call for UC Client 1.
In response to the received On-hook signal, the device hangs up the active call for UC Client 1. This is intentional system behaviour.
Step 3. Device sends On-hook Acknowledgement
The On-hook Acknowledgement is broadcasted to all UC-Clients in the system.
A On-hook Signal send by UC Client 1 triggers an On-hook Acknowledgement send by the device. The On-hook Acknowledgement is broadcasted to all UC Clients in a system.
Each UC Client has to figure out, how to interpret this signal. The interpretation depends on the configuration of each client.
Problem: this control signal is ambiguous. An On-hook Acknowledgement is identical with an On-hook Signal. This leaves room for misinterpretation.
Step 4. UC Client 3 cancels Call on Hold
UC Client 3 hangs up the call on hold for UC Client 3.
The behaviour of UC Clients and their reaction to received control signals is configurable.
A common configuration would cause these actions:
| UC Client | Reaction | Description |
|---|---|---|
| UC Client 1 | No reaction. | UC Client 1 knew that it had send an On-hook Signal earlier. It is expecting an On-hook Acknowledgement in response. |
| UC Client 2 | No reaction. | UC Client 2 has no call. In this context, it does not matter how it interprets this specific control signal. |
| UC Client 3 | Hangs up the call on hold. | UC Client 3 falsely considers the On-hook Acknowledgement as being an On-hook Signal. Reason: UC Client 3 is not aware of the context. UC Client 3 did not receive the initial On-hook Signal sent by UC Client 1 earlier. |
The user did not intend to hang up the call on UC Client 3. This happened automatically by the misinterpretation of a control signal. This is inconsistent system behaviour.
Conclusion
Device integration enables the exchange of control signals between UC Clients and a Jabra device. This is required to use hardware buttons to control the UC Client.
As an unwanted side effect of device integration, UC Clients sometimes receive ambiguous control signals. This affects use cases with two or more active UC Clients on the same system. It is caused by shortcomings of historically grown technical standards.
Please compare the different integration examples in the following section.