BLUETOOTH® DOC
`
`Prepared By
`Car WG
`
`
`
`Date / Year-Month-Day
`2008-12-18
`E-mail Address
`car-feedback@bluetooth.org
`
`Approved
`
`
`Revision
`V12r00
`
`Document No
`HSP_SPEC
`N.B.
`
`
`HEADSET PROFILE
`
`Abstract:
`This profile defines the requirements for Bluetooth® devices
`necessary to support the Headset use case. The requirements are
`expressed in terms of end-user services, and by defining the features
`and procedures that are required for interoperability between
`Bluetooth devices in the Headset use case.
`
`APPLE 1010
`
`1
`
`

`

`BLUETOOTH SPECIFICATION
`Headset Profile (HSP)
`
`Page 2 of 27
`
`Revision History
`Comments
`Revision Date
`Review draft
`D12r00
`15 August 2005
`D12r01
`13 September 2005 Editorial updates to include 1.2 or Later updates
`D12r02
`30 November 2005
`Editorial updates
`D12r03
`17 August 2007
`Editorial updates to include core spec 2.1+EDR – also address
`HSP errata 350, 368, and 446 (new ID numbers)
`Edits based on discussion during BARB call – removed PARK
`references
`Edits based on BARB review feedback
`30 August 2007
`07 September 2007 More BARB review edits and correct version number
`06 November 2007 More edits from review
`12 November 2007
`Add ESR 01 stuff
`30 November 2007
`TB and LLO comments addressed
`3 December 2007
`New dependency table provided by the SIG
`04 December 2007
`Comments from TWG addressed
`Reviewed for open errata coverage – new ids 114, 140, 215, 221,
`351. Errata 350, 368, and 446 were previously addressed
`Checked ESR 1 coverage.
`BARB final voting draft
`Prepare for publication.
`Adopted by Bluetooth SIG Board of Directors
`
`D12r04
`
`19 August 2007
`
`D12r05
`D12r06
`D12r07
`D12r08
`D12r09
`D12r10
`D12r11
`
`D12r12
`28 January 2008
`D12
`18 December 2008
`V12
`18 December 2008
`Contributors
`Name
`Richard Shaw
`Ken Morley
`Erik Slotboom
`Olof Dellien
`Bailey Cross
`Shridar Rajagopal
`Brian Redding
`Alex Feinman
`Thomas Muller
`Christian Zechlin
`Martin Roter
`Jun’ichi Yoshizawa
`Terry Bourk
`Kanji Kerai
`Burch Seymour
`Len Ott
`
`
`
`
`
`Company
`3Com
`3Com
`Ericsson Mobile Communications AB
`Ericsson Mobile Communications AB
`Intel Corporation
`Intel Corporation
`Motorola
`Motorola
`Nokia Mobile Phones
`Nokia Mobile Phones
`Nokia Mobile Phones
`Toshiba
`QUALCOMM
`Nokia Mobile Phones
`Continental Automotive Systems
`Socket Mobile
`
`18 December 2008
`
`2
`
`

`

`Page 3 of 27
`
`BLUETOOTH SPECIFICATION
`Headset Profile (HSP)
`Disclaimer and Copyright Notice
`The copyright in this specification is owned by the Promoter Members of Bluetooth® Special Interest Group
`(SIG), Inc. (“Bluetooth SIG”). Use of these specifications and any related intellectual property (collectively, the
`“Specification”), is governed by the Promoters Membership Agreement among the Promoter Members and
`Bluetooth SIG (the “Promoters Agreement”), certain membership agreements between Bluetooth SIG and its
`Adopter and Associate Members (the “Membership Agreements”) and the Bluetooth Specification Early
`Adopters Agreements (1.2 Early Adopters Agreements) among Early Adopter members of the unincorporated
`Bluetooth SIG and the Promoter Members (the “Early Adopters Agreement”). Certain rights and obligations of
`the Promoter Members under the Early Adopters Agreements have been assigned to Bluetooth SIG by the
`Promoter Members.
`Use of the Specification by anyone who is not a member of Bluetooth SIG or a party to an Early Adopters
`Agreement (each such person or party, a “Member”), is prohibited. The legal rights and obligations of each
`Member are governed by their applicable Membership Agreement, Early Adopters Agreement or Promoters
`Agreement. No license, express or implied, by estoppel or otherwise, to any intellectual property rights are
`granted herein.
`Any use of the Specification not in compliance with the terms of the applicable Membership Agreement, Early
`Adopters Agreement or Promoters Agreement is prohibited and any such prohibited use may result in
`termination of the applicable Membership Agreement or Early Adopters Agreement and other liability permitted
`by the applicable agreement or by applicable law to Bluetooth SIG or any of its members for patent, copyright
`and/or trademark infringement.
`THE SPECIFICATION IS PROVIDED “AS IS” WITH NO WARRANTIES WHATSOEVER, INCLUDING ANY
`WARRANTY OF MERCHANTABILITY, NONINFRINGEMENT, FITNESS FOR ANY PARTICULAR
`PURPOSE, SATISFACTORY QUALITY, OR REASONABLE SKILL OR CARE, OR ANY WARRANTY
`ARISING OUT OF ANY COURSE OF DEALING, USAGE, TRADE PRACTICE, PROPOSAL,
`SPECIFICATION OR SAMPLE.
`Each Member hereby acknowledges that products equipped with the Bluetooth technology ("Bluetooth
`products") may be subject to various regulatory controls under the laws and regulations of various governments
`worldwide. Such laws and regulatory controls may govern, among other things, the combination, operation,
`use, implementation and distribution of Bluetooth products. Examples of such laws and regulatory controls
`include, but are not limited to, airline regulatory controls, telecommunications regulations, technology transfer
`controls and health and safety regulations. Each Member is solely responsible for the compliance by their
`Bluetooth Products with any such laws and regulations and for obtaining any and all required authorizations,
`permits, or licenses for their Bluetooth products related to such regulations within the applicable jurisdictions.
`Each Member acknowledges that nothing in the Specification provides any information or assistance in
`connection with securing such compliance, authorizations or licenses. NOTHING IN THE SPECIFICATION
`CREATES ANY WARRANTIES, EITHER EXPRESS OR IMPLIED, REGARDING SUCH LAWS OR
`REGULATIONS.
`ALL LIABILITY, INCLUDING LIABILITY FOR INFRINGEMENT OF ANY INTELLECTUAL PROPERTY
`RIGHTS OR FOR NONCOMPLIANCE WITH LAWS, RELATING TO USE OF THE SPECIFICATION IS
`EXPRESSLY DISCLAIMED. BY USE OF THE SPECIFICATION, EACH MEMBER EXPRESSLY WAIVES
`ANY CLAIM AGAINST BLUETOOTH SIG AND ITS PROMOTER MEMBERS RELATED TO USE OF THE
`SPECIFICATION.
`Bluetooth SIG reserve the right to adopt any changes or alterations to the Specification as it deems necessary
`or appropriate.
`Copyright © 2001–2008. Bluetooth® SIG, Inc. All copyrights in the Bluetooth Specifications
`themselves are owned by Ericsson AB, Lenovo, Intel Corporation, Microsoft Corporation, Motorola,
`Inc., Nokia Corporation and Toshiba Corporation. *Other third-party brands and names are the
`property of their respective owners.
`
`18 December 2008
`
`3
`
`

`

`BLUETOOTH SPECIFICATION
`Headset Profile (HSP)
`
`Page 4 of 27
`
`1.1 
`1.2 
`1.3 
`
`1.4 
`
`2.1 
`2.2 
`2.3 
`2.4 
`2.5 
`
`4.1 
`4.2 
`
`4.3 
`4.4 
`4.5 
`4.6 
`
`4.7 
`4.8 
`
`4.9 
`
`5.1 
`5.2 
`5.3 
`5.4 
`5.5 
`
`6.1 
`6.2 
`6.3 
`
`Contents
`1 
`Introduction .................................................................................................................................... 5 
`Scope ......................................................................................................................................... 5 
`Profile Dependencies ................................................................................................................ 5 
`Symbols and Conventions ......................................................................................................... 5 
`1.3.1  Requirement Status Symbols ............................................................................................. 5 
`Signaling Diagram Conventions ................................................................................................ 5 
`Profile Overview ............................................................................................................................. 7 
`Profile stack ............................................................................................................................... 7 
`Configuration and roles ............................................................................................................. 7 
`User requirements and Scenarios ............................................................................................. 8 
`Profile Fundamentals ................................................................................................................. 9 
`Conformance ............................................................................................................................. 9 
`Application Layer ......................................................................................................................... 10 
`Headset Control Interoperability Requirements ....................................................................... 11 
`Introduction .............................................................................................................................. 11 
`Audio Gateway Initiated ACL Connection Establishment ....................................................... 11 
`4.2.1  Using In-Band Ringing ...................................................................................................... 11 
`4.2.2  Using the RING message ................................................................................................. 12 
`Headset Initiated ACL Connection Establishment................................................................... 13 
`Headset Control Following Connection Establishment ........................................................... 14 
`Audio Connection Release ...................................................................................................... 14 
`Audio Connection Transfer ...................................................................................................... 15 
`4.6.1  Audio Connection Transfer from AG to HS ....................................................................... 16 
`4.6.2  Audio Connection Transfer from HS to AG ....................................................................... 16 
`Remote Audio Volume Control ................................................................................................ 16 
`AT Commands and Result Codes ........................................................................................... 18 
`4.8.1  General ............................................................................................................................. 18 
`4.8.2  AT Capabilities Re-used from V.250 ................................................................................. 19 
`4.8.3  Bluetooth-defined AT capabilities ..................................................................................... 19 
`Lower Layer Handling .............................................................................................................. 19 
`4.9.1  Connection Handling ......................................................................................................... 20 
`4.9.1.1  Connection establishment .......................................................................................... 20 
`4.9.1.2  Connection release ..................................................................................................... 20 
`4.9.1.3  Sniff mode .................................................................................................................. 20 
`Serial Port Profile ......................................................................................................................... 21 
`RFCOMM Interoperability Requirements ................................................................................ 21 
`L2CAP Interoperability Requirements ..................................................................................... 21 
`SDP Interoperability Requirements ......................................................................................... 21 
`Link Manager (LM) Interoperability Requirements .................................................................. 22 
`Link Control (LC) Interoperability Requirements ..................................................................... 22 
`5.5.1  Class of Device ................................................................................................................. 22 
`Generic Access Profile ................................................................................................................ 24 
`Modes ...................................................................................................................................... 24 
`Security Aspects ...................................................................................................................... 24 
`Idle Mode Procedures ............................................................................................................. 24 
`References .................................................................................................................................... 25 
`List of Figures .............................................................................................................................. 26 
`List of Tables ................................................................................................................................ 27 
`
`2 
`
`3 
`4 
`
`5 
`
`6 
`
`7 
`8 
`9 
`
`
`18 December 2008
`
`4
`
`

`

`BLUETOOTH SPECIFICATION
`Headset Profile (HSP)
`
`Page 5 of 27
`
`1 Introduction
`1.1 Scope
`This Headset profile defines the protocols and procedures that shall be used by devices
`requiring a full-duplex audio connection combined with minimal device control
`commands. The most common examples of such devices are headsets, personal
`computers, PDAs, and cellular phones, though most cellular phones will prefer to use a
`more advanced profile such as Hands-Free Profile.
`The headset can be wirelessly connected for the purposes of acting as the device’s
`audio input and output mechanism, providing full duplex audio. The headset increases
`the user’s mobility while maintaining call privacy.
`1.2 Profile Dependencies
`The Headset profile is dependent upon both the Serial Port Profile and the Generic
`access profile – details are provided in Serial Port Profile and Generic Access Profile.
`1.3 Symbols and Conventions
`
`1.3.1 Requirement Status Symbols
`In this document, the following symbols are used:
`‘M’ for mandatory to support
`•
`•
`‘O’ for optional to support
`•
`‘X’ for excluded (used for capabilities that may be supported by the unit but shall
`never be used in this use case)
`‘C’ for conditional to support
`•
`‘N/A’ for not applicable (in the given context it is impossible to use this capability)
`•
`Some excluded capabilities are capabilities that, according to the relevant Bluetooth
`specification, are mandatory. These are features that may degrade operation of devices
`in this use case. Therefore, these features shall never be activated while a unit is
`operating as a unit within this use case.
`1.4 Signaling Diagram Conventions
`The following arrows are used in diagrams describing procedures:
`
`18 December 2008
`
`5
`
`

`

`BLUETOOTH SPECIFICATION
`Headset Profile (HSP)
`
`Page 6 of 27
`
`A
`
`B
`
`Mandatory signal sent by A
`
`Optional signal sent by B
`
`Mandatory procedure initiated by B
`
`Optional procedure initiated by A
`
`Mandatory procedure initiated by either A or B
`
`Figure 1.1: Arrows used in signaling diagrams
`
`18 December 2008
`
`6
`
`

`

`BLUETOOTH SPECIFICATION
`Headset Profile (HSP)
`
`Page 7 of 27
`
`2 Profile Overview
`2.1 Profile stack
`Figure 2.1 shows the protocols and entities used in this profile.
`
`
`
`Figure 2.1: Protocol model
`
`The Controller, HCI, and L2CAP are the OSI layer 1 and 2 Bluetooth protocols.
`RFCOMM is the Bluetooth adaptation of GSM TS 07.10 [5]. SDP is the Bluetooth
`Service Discovery Protocol. Headset Profile and AT CMD are the entities responsible
`for headset specific control signaling, which is AT command based.
`.For the HSP layer in Figure 2.2 the Serial Port Profile is used as a base standard. For
`this protocol, all requirements stated in the Serial Port Profile apply except in those
`cases where this profile explicitly states deviations.
`2.2 Configuration and roles
`The figures below show two typical configurations of devices for which the Headset
`profile is applicable:
`
`18 December 2008
`
`7
`
`

`

`BLUETOOTH SPECIFICATION
`Headset Profile (HSP)
`
`Page 8 of 27
`
`
`
`Cellular phone
`
`Headset
`
`
`Figure 2.2: Headset profile, example with cellular phone
`
`
`
`Laptop or PC
`
`Headset
`
`Figure 2.3: Headset profile, example with personal computer
`
`The following roles are defined for this profile:
`Audio Gateway (AG) – This device acts as either the end point, or a relay, for telephony
`quality audio, which is typically two-way. Exemplary devices acting as Audio Gateways
`are cellular phones and personal computers.
`Headset (HS) – This device provides the Audio Gateway’s remote audio input and
`output mechanism.
`The abbreviations AG and HS are used in the rest of this document to designate these
`roles.
`2.3 User requirements and Scenarios
`The Headset profile defines the protocols and procedures that shall be used by devices
`implementing this use case.
`The following restrictions apply to this profile:
`• The profile mandates CVSD encoding for audio transmitted over the Bluetooth
`SCO link. The resulting audio is monophonic, with a quality that – under normal
`circumstances – will be comparable to standard cellular phone audio quality.
`• Only one audio connection at a time is supported by a single instance of this
`profile.
`
`18 December 2008
`
`8
`
`

`

`Page 9 of 27
`
`BLUETOOTH SPECIFICATION
`Headset Profile (HSP)
`• The AG controls the SCO link establishment and release. The headset directly
`connects (disconnects) the internal audio streams upon SCO link establishment
`(release). All SCO links are, by definition, full duplex.
`• The use of eSCO [3] by co-operating devices is not prohibited, but will not be
`further specified in this profile.1
`• The profile offers only basic interoperability – multi-party call handling at the AG,
`for example, is not specified.
`• The only required HS user interface is a button-press event. The HS can signal
`the AG that the button has been pressed, but the ability to send button-press and
`button-release as two distinct signals is not defined.
`2.4 Profile Fundamentals
`Depending on the underlying core specification version2, an HS may be able to use the
`services of the AG without the creation of a secure connection. It is the implementer’s
`responsibility to enforce security on devices that support authentication and/or
`encryption in the execution of this profile. If baseband authentication and/or encryption
`is desired, the two devices shall create a secure connection, using the authentication
`procedure as described in the Generic Access profile.
`A link must be established before establishing an audio connection. Normally, this
`requires paging of the other device.
`There are no fixed master/slave roles.
`The AG and HS provide serial port emulation by using the serial port profile, which in
`turn uses the RFCOMM protocol. The serial port emulation is used to exchange the
`user data including modem control signals and AT commands and responses. AT
`commands are parsed by the AG and responses are sent to the HS.
`2.5 Conformance
`If conformance to this profile is claimed, all capabilities indicated as mandatory for this
`profile shall be supported in the specified manner (process-mandatory). This also
`applies for all optional and conditional capabilities for which support is indicated. All
`mandatory capabilities, and optional and conditional capabilities for which support is
`indicated, are subject to verification as part of the Bluetooth qualification program.
`
`
`1 Interested parties should refer to the Hands-Free Profile, version 1.5 for a relevant discussion of eSCO.
`2 Core specifications 2.1 and later require secure connections.
`
`18 December 2008
`
`9
`
`

`

`BLUETOOTH SPECIFICATION
`Headset Profile (HSP)
`
`Page 10 of 27
`
`3 Application Layer
`This section describes the feature requirements for units complying with the Headset
`Profile.
`
`Table 3.1 shows the feature requirements made by this profile.
`
`
`
`1.
`
`2.
`
`3.
`
`Feature
`
`Incoming audio connection
`
`Outgoing audio connection
`
`Audio connection transfer
`
`Remote audio volume control
`4.
`Table 3.1: Application layer procedures
`
`Support in HS
`
`Support in AG
`
`M
`
`M
`
`M
`
`O
`
`M
`
`O
`
`M
`
`O
`
`In the table above, incoming and outgoing shall be interpreted from the headset (HS)
`point of view.
`Table 3.2 maps each feature to the procedures used for that feature. All procedures are
`mandatory if the feature is supported.
`
`
`
`1.
`
`
`
`2.
`
`
`
`3.
`
`Feature
`
`Procedure
`
`Incoming audio connection
`
`Incoming audio connection establishment
`
`
`
`Audio connection release
`
`Outgoing audio connection
`
`Outgoing audio connection establishment
`
`
`
`Audio connection release
`
`Audio connection transfer
`
`Audio connection transfer
`
`Remote audio volume control Remote audio volume control
`4.
`Table 3.2: Application layer feature to procedure mapping
`
`Ref.
`
`4.2
`
`4.4
`
`4.3
`
`4.4
`
`4.6
`
`4.7
`
`18 December 2008
`
`10
`
`

`

`BLUETOOTH SPECIFICATION
`Headset Profile (HSP)
`
`Page 11 of 27
`
`4 Headset Control Interoperability Requirements
`4.1 Introduction
`The interoperability requirements for the Headset Control entity are completely
`contained in this chapter. Sections 4.2 through Section 4.7 specify the requirements for
`the procedures directly relating to the application layer features.
`Section 4.8 specifies the AT commands and results codes used for signaling purposes.
`Sect ion 4.9 specifies how the layers beneath the Headset Control entity are used to
`establish and release a connection.
`4.2 Audio Gateway Initiated ACL Connection Establishment
`Upon an internal or user generated event, the AG will initiate connection establishment
`(see Section 4.8.1), once the connection is established, there are then two options as
`described in the Sections 4.2.1and Sections 4.2.2. The SCO link establishment can take
`place anytime after the ACL connection establishment.
`
`4.2.1 Using In-Band Ringing
`An in-band ring tone is an audible alert, such as a tone, melody, short music clip, that is
`transmitted by the AG, to the HS, to alert the user of an event; typically an incoming call.
`As shown in Figure 4.1, the AG may generate an in-band ring tone using the SCO
`connection to the HS. The AG decides how to use this SCO connection. When using an
`in-band ring tone, the AG shall not send the RING unsolicited result code to the HS3.
`
`
`3 Please note this behavior differs from the Hands-Free Profile versions 1.0 and 1.5, which do send RING
`when using in-band ring tone notification.
`
`18 December 2008
`
`11
`
`

`

`BLUETOOTH SPECIFICATION
`Headset Profile (HSP)
`
`Page 12 of 27
`
`
`
`Figure 4.1: Incoming audio connection establishment using in-band ring tone
`
`
`
`4.2.2 Using the RING message
`As shown in Figure 4.2, the AG will repeatedly send the RING unsolicited result code to
`the HS for a time period decided by the AG. The RING may be repeated for as long as
`the connection establishment is pending.
`
`18 December 2008
`
`12
`
`

`

`BLUETOOTH SPECIFICATION
`Headset Profile (HSP)
`
`Page 13 of 27
`
`
`
`Figure 4.2 Incoming connection establishment (using RING message)
`
`4.3 Headset Initiated ACL Connection Establishment
`A headset (HS) originated ACL connection is initiated (see Section 4.9) by a user action
`(e.g. pressing a button on the headset). Upon completion of a connection establishment
`that was initiated by pressing the “headset button”, the HS shall send the
`AT+CKPD=200 command to the AG. If the HS connection is initiated by an event other
`than a headset button press, the HS shall not send AT+CKPD=200.
`The AG may initiate a SCO connection after the completion of the ACL connection
`establishment, but before receiving the AT+CKPD=200 command from the HS. This
`may be desirable when the AG is a mobile phone. In all cases, the AG is responsible for
`establishing the SCO link if needed. Further internal actions may be needed on the AG
`to internally establish and/or route the audio stream to the HS4.
`As shown in Figure 4.3, the SCO link connection may be set up prior to receiving the
`AT+CKPD=200 command. If this is not the case, then the SCO link connection shall be
`set up after receiving the AT+CKPD=200 command.
`
`4 For a cellular phone a cellular call may need to be established, e.g. using last dialled number or a
`pre-programmed number. For a personal computer this may relate to VoIP calls or voice
`command/prompt interaction with the computer.
`
`18 December 2008
`
`13
`
`

`

`BLUETOOTH SPECIFICATION
`Headset Profile (HSP)
`
`Page 14 of 27
`
`HS
`
`AG
`
`User initiated action
`
`Connection establishment
`
`Optional SCO link establishment
`
`AT+CKPD=200
`
`OK
`
`SCO link establishment
`
`Figure 4.3: Audio connection establishment
`
`4.4 Headset Control Following Connection Establishment
`While a headset profile connection exists between AG and HS, and upon the receipt of
`a user initiated action (for example, button press) on the HS, the HS shall send the
`AT+CKPD=200 command to the AG. The action performed by the AG on receipt of the
`AT+CKPD=200 command is implementation dependent. The actions performed by the
`AG may be dictated by the state the AG is in at the time it received the command.
`4.5 Audio Connection Release
`
`
`HS
`
`AG
`
`User initiated action
`
`AT+CKPD=200
`
`OK
`
`SCO link release
`
`Connection release
`
`Figure 4.4: Audio connection release – HS initiated
`
`
`
`18 December 2008
`
`14
`
`

`

`BLUETOOTH SPECIFICATION
`Headset Profile (HSP)
`HS
`
`Page 15 of 27
`
`AG
`
`Internal event/user initiated action
`
`SCO link release
`
`Connection release
`
`Figure 4.5: Audio connection release – AG initiated
`
`The AG may release the Audio connection (SCO) upon an internal event in the AG or
`after the AG receives an indication of a user initiated action (e.g. button press) from the
`AG or HS.
`The HS may initiate an Audio connection (SCO) release in circumstances such as
`power-down event while an Audio connection (SCO) is established.
`Irrespective of the initiating side, the AG is responsible for releasing the profile’s serial
`port (RFCOMM) connection (see Section 4.9.1.2).
`4.6 Audio Connection Transfer
`An audio connection can be transferred from AG to HS or from HS to AG. The
`connection is transferred to the device initiating the transfer.
`
`18 December 2008
`
`15
`
`

`

`BLUETOOTH SPECIFICATION
`Headset Profile (HSP)
`
`Page 16 of 27
`
`4.6.1 Audio Connection Transfer from AG to HS
`The audio connection transfer from AG to HS is initiated by a user action on the HS
`side. To effect this transfer, the HS shall send the AT+CKPD=200 command to the AG.
`
`HS
`
`AG
`
`User initiated action
`
`Connection establishment
`
`AT+CKPD=200
`
`OK
`
`SCO link establishment
`
`Figure 4.2: Audio connection transfer from AG to HS
`
`
`
`4.6.2 Audio Connection Transfer from HS to AG
`The audio connection transfer from HS to AG is initiated by a user action on the AG.
`This user action shall result in the AG releasing the SCO connection.
`HS
`
`AG
`
`Ongoing audio connection
`
`User initiated action
`
`SCO link release
`
`Figure 4.3: Audio connection transfer from HS to AG
`
`4.7 Remote Audio Volume Control
`The AG can control the gain of the microphone or speaker of the HS by sending
`unsolicited result codes +VGM or +VGS respectively. There is no restriction on the
`number or order of these result codes. Support for remote audio volume control is
`
`18 December 2008
`
`16
`
`

`

`BLUETOOTH SPECIFICATION
`Headset Profile (HSP)
`optional, so an implementation may support none, either, or both of the controls for
`microphone volume and speaker volume.
`
`Page 17 of 27
`
`HS
`
`AG
`
`Ongoing audio connection
`
`+VGM=13
`
`+VGS=5
`
`set microphone gain
`
`set speaker gain
`
`Figure 4.4: Audio volume control – example flow
`
`Both the speaker and microphone gain are represented as parameter to the +VGS and
`+VGM, on a scale from 0 to 15. The values are absolute values, relating to a particular
`(implementation-dependent) volume level controlled by the HS.
`The HS may store the VGS and VGM settings at connection release. At connection
`establishment, the HS may restore the previous settings using the AT commands
`AT+VGS and AT+VGM. In case physical mechanisms (buttons, dials etc.) means are
`implemented on the HS to control the volume levels, the HS shall also use the AT
`commands AT+VGS and AT+VGM to inform the AG of any changes in the volume
`levels.
`
`18 December 2008
`
`17
`
`

`

`BLUETOOTH SPECIFICATION
`Headset Profile (HSP)
`
`Page 18 of 27
`
`HS
`
`AG
`
`Connection establishment
`
`AT+VGS=6
`
`OK
`
`AT+VGM=5
`
`OK
`
`AT+VGS=7
`
`Local action to set
`speaker volume
`
`Figure 4.5: Volume level synchronization – example flow
`
`4.8 AT Commands and Result Codes
`
`4.8.1 General
`The command line termination character shall be carriage return (IA5 0/13). The
`response formatting character shall be line feed (IA5 0/10). The AG shall not echo
`command characters5. The AG shall transmit result codes, using the verbose (rather
`than numeric) format.
`The format for a command from the HS to the AG is thus:
` AT<cmd>=<value><cr>
`If the command is processed successfully, the resulting response from the AG to the HS
`is:
` <cr><lf>OK<cr><lf>
`If the command is not processed successfully, or is not recognized, the resulting
`response from the AG to the HS is:
` <cr><lf>ERROR<cr><lf>
`The format for an unsolicited result code (such as RING) from the AG to the HS is:
` <cr><lf><result code><cr><lf>
`
`
`5 1This is the opposite of the default recommended by V.250
`
`18 December 2008
`
`18
`
`

`

`BLUETOOTH SPECIFICATION
`Headset Profile (HSP)
`4.8.2 AT Capabilities Re-used from V.250
`The mandatory set of AT commands and unsolicited result codes are indicated in Table
`4.1.
`
`Page 19 of 27
`
`AT capability
`RING – See note 1
`Headset button press
`
`Syntax
`RING
`+CKPD=200
`
`Description
`The Incoming call indication of V.250 [1], Section 6.3.4.
`Command issued by HS to indicate that the button has been
`pressed
`
`Table 4.1: Mandatory AT capabilities
`Note 1: Mandatory for HS to support RING, optional for AG
`
`4.8.3 Bluetooth-defined AT capabilities
`Optionally, the AT capabilities as indicated in Table 4.2 may be supported.
`
`Speaker gain
`
`Microphone
`gain level report
`
`Speaker gain
`level indication
`report
`
`Description
`AT capability Syntax
`Microphone
`+VGM=<gain > Unsolicited result code issued by the AG to
`gain
`set the microphone gain of the HS. <gain>
`is a decimal numeric constant, relating to a
`particular (implementation- dependent)
`volume level controlled by the HS.
`+VGS=<gain> Unsolicited result code issued by the AG to
`set the speaker gain of the HS. <gain> is a
`decimal numeric constant, relating to a
`particular (implementation-dependent)
`volume level controlled by the HS.
`+VGM=<gain > Command issued by the HS to report the
`current microphone gain level setting to the
`AG. <gain> is a decimal numeric constant,
`relating to a particular (implementation-
`dependent) volume level controlled by the
`HS.
`+VGS=<gain> Command issued by the HS to report the
`<gain>: 0-15
`current speaker gain level setting to the AG.
`<gain> is a decimal numeric constant,
`relating to a particular (implementation-
`dependent) volume level controlled by the
`HS.
`Table 4.2: Optional AT capabilities
`4.9 Lower Layer Handling
`This section describes how the layers below the Headset Control entity are used to
`establish and release a connection.
`
`Values
`<gain>: 0-15
`
`<gain>: 0-15
`
`<gain>: 0-15
`
`18 December 2008
`
`19
`
`

`

`BLUETOOTH SPECIFICATION
`Headset Profile (HSP)
`4.9.1 Connection Handling
`
`Page 20 of 27
`
`4.9.1.1 Connection establishment
`Either the HS or the AG may initiate connection establishment. If there is no RFCOMM
`session between the AG and the HS, the initiating device shall first initialize RFCOMM.
`Connection establishment shall be performed as described in Section 7.3 of GAP and
`Section 3 of SPP.
`
`4.9.1.2 Connection release
`When the audio connection is released, the profile’s serial port (RFCOMM) connection
`may be released as well.
`Since it is possible that multiple profiles are active between the two devices, the
`Headset Profile should not initiate an ACL level disconnection, that action should be left
`to a lower layer that can determine when it is appropriate to disconnect the physical link.
`
`4.9.1.3 Sniff mode
`The use of sniff mode is recommended6 for devices that need to reduce power
`consumption whi