1 Purpose

Wireless headsets are becoming increasingly used in the Enterprise telephony environment. Through freedom to move around the enterprise while being on a call, the wireless headset provides a new set of functionalities and need for expanded interoperability with the desktop telephone.

A traditional corded headset connects to the phone's 4-wire handset interface, sometimes through a headset amplifier. Call control is being managed by the user directly by pressing buttons on the desktop phone. But when wireless headsets are used, the desktop phone may be out of reach and the need for some remote call control functionality is valuable.

This document describes a way of designing a remote call control interface for use between telephones and Jabra / GN Netcom wireless headsets.

Revision History:

Revision Date Change by Description
0.1 23.07.2010 TPE Preliminary draft
0.2 07.09.2010 TPE Comm. Speed changed to 600bits/sec., Added Reject code, Changed INIT code, added ACK code
1.0 14.09.2010 TPE Added Incoming call & Last Number Redial codes. Corrected Hex value for Code 3. Added Error handling.
1.1 13.10.2010 TPE Header corrected. NACK command added. Capability commands added. Collision Management added. Test command added.
1.2 19.10.2010 TPE Changes from internal reviews
1.3 29.03.2011 TPE Initialization description updated. Example section added.
1.4 20.06.2011 TPE Changes from internal review.

1.1 Overview

This document is organized in four sections. The first section describes the hardware and physical interface to desktop phones. The second section describes the signaling protocol options for the interface. Third section describes the command flow when communicating with a headset base. Fourth section describes combined usage of commands.

1.2 Desktop phones

GN Netcom and Jabra headset systems for use in the Enterprise are typically equipped with a desktop base station, which serves as wireless access point, placeholder and charger for the headset. Meanwhile the base station is also the interface to the telephone through two connections, a 4-wire port for voice and an 8-pin auxiliary (AUX) port for call control. The remaining part of this document is concerned with the AUX port.

The AUX interface can be used to:

  • control external devices (i.e. a mechanical hook lifting device)
  • communicate hook switch commands with a telephone (e-hook)

AUX Interface

  • Connector type and orientation
  • Pin-out of connector
  • Signal definition
  • Hardware implementation
  • Electrical characteristics

Hook Interface

  • Jabra UART Mode

2 AUX Interface

Communications to external devices use the AUX connector. The plug type used in the headset base station is an 8 pin modular plug.

2.1 Pin Configuration

Pin No Name Description
1 Pin 1 Internal GNN use only. DO NOT CONNECT.
2 GND GND reference for 7V5 supply.
3 Tx+ Output signaling from Headset AUX port to Phone communications port.
4 Tx- Output signaling from Headset AUX port to Phone communications port.
5 Rx+ Input signaling from Phone communications port to Headset AUX port.
6 Rx- Input signaling from Phone communications port to Headset AUX port.
7 7.5 V Unregulated supply voltage. Maximum current: 100mA
8 Pin 8 Internal GNN use only. DO NOT CONNECT.

The standard hardware implementation is shown in figure below.

Output signal (Tx) and input signal (Rx) are galvanically isolated from the rest of the headset base station (see below diagram).

Isolation is made with opto-couplers why the signal voltage must be evaluated before compliance can be guaranteed.

Diagram shows connection to serial interface. Rx and Tx are named from a headset device point of view and pin numbers match above pin configuration.

2.2 Electrical Interface

Electrical Interface

2.2.1 Example schematic (Low drive capability, <20mA)

Example schematic for connecting AUX port to phone (Low drive capability)

Example schematic for connecting AUX port to phone (Low drive capability)

2.2.2 Example schematic (High drive capability, >20mA)

Example schematic for connecting AUX port to phone (High drive capability)

Example schematic for connecting AUX port to phone (High drive capability)

2.2.3 Signaling Parameters

Name Value Comment
Encoding UART
Baud Rate 600 bits/sec* Bit period = 1666µs, Byte period = 18326µs
Data Bits 8
Parity None
Start Bit 1
Stop Bit 2 To allow for UART with tight timing specs.

*: This is the default speed. Use CAP_SPD function to negotiate speed.

3 Jabra UART

The Jabra UART protocol is a derivative of the DHSG standard, which has been in use for many years in the headset industry. The main differences between the DHSG and the Jabra UART protocols are the absence of Manchester encoding, and the presence of an initialization sequence. Furthermore this document describes the command flow associated with the Jabra UART protocol, a feature that was absent from the original DHSG standard.

The Jabra UART interface communicates through the AUX port which is widely supported by wireless GN Netcom headset devices.

The Jabra UART protocol is NOT compatible with the DHSG protocol.

3.1 Command Definitions

Different commands are defined depending if you are telephone device or headset device.

3.1.1 Telephone Commands

Commands from the telephone are sent as described below.

CMD Level Code Hex Definition Description
001 INIT 21 Initialization Inform the headset device about presence
001 BEL 07 Initialization acknowledge Confirms the request for initialization
001 1 EE Ringer Inform headset device about incoming call. Headset injects ringtone.
001 2 DD Call active ID that line is active
001 3 BB Call inactive ID that line is inactive
001 4 37 Mute active ID that Mute is active
001 5 2F Mute inactive ID that Mute is inactive
001 ACK 06 Acknowledge Confirm receipt of valid command
001 NACK 15 Not Acknowledged Command not received correctly
001 STX 02 Start Of Text Indicates start of byte package
001 ETX 03 End Of Text Indicates end of byte package
001 CAP_ID 22 Capabilities, identification Initiates exchange of identification information
001 CAP_FW 23 Capabilities, Firmware rel. Initiates exchange of Firmware release information
001 CAP_CMD 24 Capabilities, Command level Initiates exchange of Command level information
001 CAP_SPD 25 Capabilities, Speed Initiates exchange of communication speed information
001 CAP_RES 26 Capabilities, Reserved Initiates exchange of reserved bytes information
001 TEST 55 Test Test whether the other party is able to communicate
002 Incoming call 69 Incoming call Inform headset device that a call is coming. Headset opens audio channel. Phone injects ringtone.

3.1.2 Headset commands

Commands from the headset device are described below.

CMD Level Code Hex Definition Description
001 INIT 21 Initialization Inform the telephone device about presence
001 BEL 07 Initialization acknowledge Confirms the request for initialization
001 1 EE On hook “Handset replaced” pressed from headset
001 2 DD Off hook “Handset lifted” pressed from headset
001 3 BB Mute On Mute activated from headset
001 4 37 Mute Off Mute de-activated from headset
001 REJECT 65 Reject call Reject incoming call
001 ACK 06 Acknowledge Confirm receipt of valid command
001 NACK 15 Not Acknowledged Command not received correctly
001 STX 02 Start Of Text Indicates start of byte package
001 ETX 03 End Of Text Indicates end of byte package
001 CAP_ID 22 Capabilities, identification Initiates exchange of identification information
001 CAP_FW 23 Capabilities, Firmware rel. Initiates exchange of Firmware release information
001 CAP_CMD 24 Capabilities, Command level Initiates exchange of Command level information
001 CAP_SPD 25 Capabilities, Speed Initiates exchange of communication speed information
001 CAP_RES 26 Capabilities, Reserved Initiates exchange of reserved bytes information
001 TEST 55 Test Test whether the other party is able to communicate
002 Last Number Redial 73 Dial last number Instruct the phone to dial the last dialed number

3.2 Command structure

The commands are sent using the Protocol Parameter scheme shown below.

3.3 Protocol Parameters

Name Value Comment
Retries 3 Maximum
Timeouts: - -
Phone→HS 150ms Any command requiring a response
HS→Phone 400ms Any command requiring a response
Init re-try timeout (Phone) 10 s After maximum number of retries
Init re-try timeout (HS) 12 s After maximum number of retries
SPD Guard time 10ms After Speed change completion
Phone Poll Interval 10 s Standard Poll interval
HS Poll Timeout 12 s If Phone Poll is not received

3.4 Command format

Command format

3.5 Command format continued

Command format

3.6 Error handling

Both the phone and the headset must ignore invalid state transitions, e.g. back to back on hook/call inactive commands, but still respond with the proper sequence. Undefined/Unknown commands must always be responded with NACK. If a NACK is received upon sending a correct command, a maximum of 3 retries is permitted. If the maximum number of retries is reached, the procedure for No Response (section 4.3.3.) should be initiated.

Further descriptions of error handling scenarios can be found in section 4.3

3.7 Initialization

Initialization can only occur in idle state, or when next idle state is reached. E.g. if the headset power cycles while a phone call is in progress, the phone should delay the initialization until the phone call has ended.

If initialization is desired during an active call, it is the responsibility of the phone to bring the headset into the present state.

3.8 Polling strategy

If using Polling strategy to obtain information whether the other party is still present, and able to send/receive commands, a 10 second polling interval should be used from the phone side.

If no polling strategy is applied from the phone side, the 'HS Poll Timeout' will run out, and send a poll towards the phone.

3.9 Capability packages description

Capability packets are groups of bytes identifying various characteristics of each party. This allows the devices to adjust various settings internal to the devices, in order to obtain the best possible degree of plug-and-play functionality to the customer.

3.9.1 Capabilities, Identification packet

The Identification packet contains 3 bytes of information. The Vendor ID(VID) byte, the Device ID(DID) byte & the Model ID(MID) byte. To obtain entries in the byte tables, please contact Jabra HQ / Strategic Alliances office, for immediate attention.

Example of an Identification packet transmission:

STX(02h)   | VID(e.g.: 01h)   | DID(e.g.:01h)   | MID(e.g.:01h)   | ETX(03h)

This example translates to a 'Jabra PRO9470' device'

Please refer to the 'Jabra UART VID table' document, for identifying VID's for Jabra devices.

3.9.2 Capabilities, Firmware packet

The Firmware packet contains 3 bytes of information. The 'Major' release byte, the 'Minor' release byte and the 'Build' byte.

Example of a Firmware packet transmission:

STX(02h)   | Major (e.g.: 01h)   | Minor(e.g.:21h)   | Build(e.g.:55h)   | ETX(03h)

This example translates to Firmware release 01.33.85

3.9.3 Capabilities, Command level packet

The Command level packet contains 1 byte of information. This byte refers to the number of commands supported by the device. Please refer to the first columns of tables 3.1.1 & 3.1.2 for information on what command level you should use. Example of a Command level packet transmission:

STX(02h)   | CMD-level(e.g.: 02h)   | ETX(03h)

This example translates to a command level supporting all of the command mentioned in the specification. Command level 02h is the level supported by this release.

3.9.4 Capabilities, Speed level packet

The Speed level packet contains 1 byte of information. This byte refers to the speed of the UART. When information has been exchanged between the two parties, the lowest denominator is the speed that will be used.

Example of a Speed level packet transmission:

| | | | | | ------------- | ------------- | ------------- | | STX(02h)   | | SPD(e.g.: 01h)   | | ETX(03h) |

This example translates to a speed of 600bits/sec.

Please refer to section 4.1.5 for a detailed description of the speed change procedure.

Speed table
SPD byte value Speed (bits/sec) Conditions
01 600
02 1200
03 2400

3.9.5 Capabilities, Reserved packet

The Reserved packet contains 3 bytes of information. These bytes are reserved for future use. Please use 0's for all 3 bytes.

Example of a Reserved packet transmission:

STX(02h)   | RES1(00h)   | RES2(00h)   | RES3(00h)   | ETX(03h)

This example is the correct way to use the reserved bytes

4 Command flow specification

4.1 Initialization incl. capabilities packages

Initialization incl. capabilities packages

4.1.1 Initialization at Power On

Initialization at Power On

4.1.2 Capabilities information, Identification

Capabilities information, Identification

4.1.3 Capabilities information, Firmware release

Capabilities information, Firmware release

4.1.4 Capabilities information, Command level

Capabilities information, Command level

4.1.5 Capabilities information, Speed

Capabilities information, Speed

4.1.6 Capabilities information, Reserved

Capabilities information, Reserved

4.2 Standard Telephony functions

4.2.1 Incoming call, accepted

Incoming call, accepted

4.2.2 Incoming call, rejected

Incoming call, rejected

4.2.3 Outgoing call

Outgoing call

4.2.4 Terminate call

Terminate call

4.2.5 Mute

Mute

4.2.6 Last Number Redial

Last Number Redial

4.3 Protocol Management

4.3.1 Command not understood

Command not understood

4.3.2 Collision Management {Byte-level)

Collision Management {Byte-level)

4.3.3 No Response (unplugged cable etc.)

No Response (unplugged cable etc.)

4.3.4 Transmission Test

Transmission Test

5 Usage examples

This section contains examples of combined command usage

5.1 Byte collision

Byte collision

5.2 Initialization re-try (Phone)

Initialization re-try (Phone)

5.3 Initialization re-try (Headset)

Initialization re-try (Headset)

5.4 Call Waiting

Call Waiting

5.5 Polling

Polling

5.6 Cable un-plugged (with polling)

Cable un-plugged (with polling)

5.7 Cable re-plugged

Cable re-plugged