Revision: v1.0
Revision Date: 2022-03-22
Prepared By: Generic Audio Working Group
Abstract:
The Common Audio Service (CAS) is used to identify a server supporting the Common Audio Profile (CAP) Acceptor role [1]. If an instance of Coordinated Set Identification Service (CSIS) is included in the CAS definition, CAS identifies that the device is part of a Coordinated Set.
Revision History
Revision Number |
Date (yyyy-mm-dd) |
Comments |
---|---|---|
v1.0 |
2022-03-22 |
Adopted by the Bluetooth SIG Board of Directors. |
Acknowledgments
Name |
Company |
---|---|
Andrew Estrada |
Sony Corporation |
Masahiko Seki |
Sony Corporation |
Akio Tanaka |
Sony Corporation |
Himanshu Bhalla |
Intel Corporation |
Oren Haggai |
Intel Corporation |
Rasmus Abildgren |
Bose Corporation |
Daniel Sisolak |
Bose Corporation |
Tim Reilly |
Bose Corporation |
Michael Rougeux |
Bose Corporation |
Nick Hunn |
GN Hearing A/S |
Chris Church |
Qualcomm Technologies International, Ltd |
Jeff Solum |
Starkey Hearing Technologies |
Georg Dickmann |
Sonova AG |
Frank Yerrace |
Microsoft Corporation |
Asbjørn Sæbø |
Nordic Semiconductor ASA |
Scott Walsh |
Plantronics Inc |
Bjarne Klemmensen |
Demant A/S |
Jonathan Tanner |
Qualcomm Technologies International, Ltd |
Riccardo Cavallari |
WS Audiology Denmark A/S |
Kanji Kerai |
WS Audiology |
Sherry Smith |
Broadcom |
Siegfried Lehmann |
Apple |
Use of this specification is your acknowledgement that you agree to and will comply with the following notices and disclaimers. You are advised to seek appropriate legal, engineering, and other professional advice regarding the use, interpretation, and effect of this specification.
Use of Bluetooth specifications by members of Bluetooth SIG is governed by the membership and other related agreements between Bluetooth SIG and its members, including those agreements posted on Bluetooth SIG’s website located at www.bluetooth.com. Any use of this specification by a member that is not in compliance with the applicable membership and other related agreements is prohibited and, among other things, may result in (i) termination of the applicable agreements and (ii) liability for infringement of the intellectual property rights of Bluetooth SIG and its members. This specification may provide options, because, for example, some products do not implement every portion of the specification. All content within the specification, including notes, appendices, figures, tables, message sequence charts, examples, sample data, and each option identified is intended to be within the bounds of the Scope as defined in the Bluetooth Patent/Copyright License Agreement (“PCLA”). Also, the identification of options for implementing a portion of the specification is intended to provide design flexibility without establishing, for purposes of the PCLA, that any of these options is a “technically reasonable non-infringing alternative.”
Use of this specification by anyone who is not a member of Bluetooth SIG is prohibited and is an infringement of the intellectual property rights of Bluetooth SIG and its members. The furnishing of this specification does not grant any license to any intellectual property of Bluetooth SIG or its members. THIS SPECIFICATION IS PROVIDED “AS IS” AND BLUETOOTH SIG, ITS MEMBERS AND THEIR AFFILIATES MAKE NO REPRESENTATIONS OR WARRANTIES AND DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING ANY WARRANTIES OF MERCHANTABILITY, TITLE, NON-INFRINGEMENT, FITNESS FOR ANY PARTICULAR PURPOSE, OR THAT THE CONTENT OF THIS SPECIFICATION IS FREE OF ERRORS. For the avoidance of doubt, Bluetooth SIG has not made any search or investigation as to third parties that may claim rights in or to any specifications or any intellectual property that may be required to implement any specifications and it disclaims any obligation or duty to do so.
TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, BLUETOOTH SIG, ITS MEMBERS AND THEIR AFFILIATES DISCLAIM ALL LIABILITY ARISING OUT OF OR RELATING TO USE OF THIS SPECIFICATION AND ANY INFORMATION CONTAINED IN THIS SPECIFICATION, INCLUDING LOST REVENUE, PROFITS, DATA OR PROGRAMS, OR BUSINESS INTERRUPTION, OR FOR SPECIAL, INDIRECT, CONSEQUENTIAL, INCIDENTAL OR PUNITIVE DAMAGES, HOWEVER CAUSED AND REGARDLESS OF THE THEORY OF LIABILITY, AND EVEN IF BLUETOOTH SIG, ITS MEMBERS OR THEIR AFFILIATES HAVE BEEN ADVISED OF THE POSSIBILITY OF THE DAMAGES.
Products equipped with Bluetooth wireless technology ("Bluetooth Products") and their combination, operation, use, implementation, and distribution may be subject to regulatory controls under the laws and regulations of numerous countries that regulate products that use wireless non-licensed spectrum. Examples include airline regulations, telecommunications regulations, technology transfer controls, and health and safety regulations. You are solely responsible for complying with all applicable laws and regulations and for obtaining any and all required authorizations, permits, or licenses in connection with your use of this specification and development, manufacture, and distribution of Bluetooth Products. Nothing in this specification provides any information or assistance in connection with complying with applicable laws or regulations or obtaining required authorizations, permits, or licenses.
Bluetooth SIG is not required to adopt any specification or portion thereof. If this specification is not the final version adopted by Bluetooth SIG’s Board of Directors, it may not be adopted. Any specification adopted by Bluetooth SIG’s Board of Directors may be withdrawn, replaced, or modified at any time. Bluetooth SIG reserves the right to change or alter final specifications in accordance with its membership and operating agreements.
Copyright © 2016–2022. All copyrights in the Bluetooth Specifications themselves are owned by Apple Inc., Ericsson AB, Intel Corporation, Lenovo (Singapore) Pte. Ltd., Microsoft Corporation, Nokia Corporation, and Toshiba Corporation. The Bluetooth word mark and logos are owned by Bluetooth SIG, Inc. Other third-party brands and names are the property of their respective owners.
1. Introduction
The Common Audio Service (CAS) allows for the Coordinated Set Identification Service (CSIS) [2] to be an included service where the device is part of a Coordinated Set.
1.1. Language
1.1.1. Language conventions
The Bluetooth SIG has established the following conventions for use of the words shall, must, will, should, may, can, and note in the development of specifications:
shall |
is required to – used to define requirements. |
must |
is used to express: a natural consequence of a previously stated mandatory requirement. OR an indisputable statement of fact (one that is always true regardless of the circumstances). |
will |
it is true that – only used in statements of fact. |
should |
is recommended that – used to indicate that among several possibilities one is recommended as particularly suitable, but not required. |
may |
is permitted to – used to allow options. |
can |
is able to – used to relate statements in a causal manner. |
note |
Text that calls attention to a particular point, requirement, or implication or reminds the reader of a previously mentioned point. It is useful for clarifying text to which the reader ought to pay special attention. It shall not include requirements. A note begins with “Note:” and is set off in a separate paragraph. When interpreting the text, the relevant requirement shall take precedence over the clarification. |
If there is a discrepancy between the information in a figure and the information in other text of the specification, the text prevails. Figures are visual aids including diagrams, message sequence charts (MSCs), tables, examples, sample data, and images. When specification content shows one of many alternatives to satisfy specification requirements, the alternative shown is not intended to limit implementation options. Other acceptable alternatives to satisfy specification requirements may also be possible.
1.1.2. Reserved for Future Use
Where a field in a packet, Protocol Data Unit (PDU), or other data structure is described as "Reserved for Future Use" (irrespective of whether in uppercase or lowercase), the device creating the structure shall set its value to zero unless otherwise specified. Any device receiving or interpreting the structure shall ignore that field; in particular, it shall not reject the structure because of the value of the field.
Where a field, parameter, or other variable object can take a range of values, and some values are described as "Reserved for Future Use," a device sending the object shall not set the object to those values. A device receiving an object with such a value should reject it, and any data structure containing it, as being erroneous; however, this does not apply in a context where the object is described as being ignored or it is specified to ignore unrecognized values.
When a field value is a bit field, unassigned bits can be marked as Reserved for Future Use and shall be set to 0. Implementations that receive a message that contains a Reserved for Future Use bit that is set to 1 shall process the message as if that bit was set to 0, except where specified otherwise.
The acronym RFU is equivalent to Reserved for Future Use.
1.1.3. Prohibited
When a field value is an enumeration, unassigned values can be marked as “Prohibited.” These values shall never be used by an implementation, and any message received that includes a Prohibited value shall be ignored and shall not be processed and shall not be responded to.
Where a field, parameter, or other variable object can take a range of values, and some values are described as “Prohibited,” devices shall not set the object to any of those Prohibited values. A device receiving an object with such a value should reject it, and any data structure containing it, as being erroneous.
“Prohibited” is never abbreviated.
1.2. Table requirements
Requirements in this section are defined as "Mandatory" (M), "Optional" (O), "Excluded" (X), “Not Applicable” (N/A), or "Conditional" (C.n). Conditional statements (C.n) are listed directly below the table in which they appear.
1.3. Conformance
If conformance to this specification is claimed, all capabilities indicated as mandatory for this specification shall be supported in the specified manner (process-mandatory). This also applies for all optional and conditional capabilities for which support is indicated.
1.4. Byte transmission order
All characteristics used with this service shall be transmitted with the least significant octet (LSO) first (i.e., little endian). Where the format is described in tables in this document, the LSO is the first octet in the topmost field of the table; the most significant octet (MSO) is the last octet in the bottommost field of the table.
2. Service
2.1. Service dependencies
CAS depends on CSIS [2].
2.2. Bluetooth Core Specification release compatibility
This specification is compatible with the Bluetooth Core Specification, Version 5.3 [3] or later.
2.3. Transport dependencies
There are no transport-related dependencies for CAS.
2.4. Attribute Profile error codes
This service does not define or reference any Attribute Profile error codes.
2.5. GATT sub-procedure requirements
This service does not require any additional GATT sub-procedures beyond those required by all GATT Servers.
2.6. Declaration
There shall be no more than one CAS instance on a server.
The CAS shall be instantiated as a «Primary Service» and may be included by other services. The service universally unique identifier (UUID) shall be set to «Common Audio Service» as defined in Bluetooth Assigned Numbers [4].
If the device implementing CAS is a member of a Coordinated Set, the CAS instance shall include the CSIS instance that identifies the Coordinated Set as an included service.
The CAS shall include no more than one instance of CSIS.
2.7. Behavior
There is no behavior defined for this service.
3. Service characteristics
There are no characteristics in CAS.
4. SDP interoperability
If this service is exposed over BR/EDR, then it shall have the SDP record as shown in Table 4.1.
Item |
Definition |
Type |
Value |
Status |
---|---|---|---|---|
Service Class ID List |
– |
– |
– |
M |
Service Class #0 |
– |
UUID |
«Common Audio Service» |
M |
Protocol Descriptor List |
– |
Data Element Sequence |
– |
M |
Protocol #0 |
– |
UUID |
L2CAP |
M |
Parameter #0 for Protocol #0 |
Protocol/Service Multiplexer (PSM) |
uint16 |
PSM = ATT |
M |
Protocol #1 |
– |
UUID |
ATT |
M |
Additional Protocol Descriptor List |
– |
Data Element Sequence |
– |
|
Protocol Descriptor List |
– |
Data Element Sequence |
– |
C.1 |
Protocol #0 |
– |
UUID |
L2CAP |
C.1 |
Parameter #0 for Protocol #0 |
PSM |
uint16 |
PSM = EATT |
C.1 |
Protocol #1 |
– |
UUID |
ATT |
C.1 |
BrowseGroupList |
– |
– |
PublicBrowseRoot* |
M |
* PublicBrowseRoot shall be present; however, other browse UUIDs may also be included in the list.
C.1: Mandatory to support if EATT is supported, otherwise Excluded.
5. Acronyms and abbreviations
Acronym/Abbreviation |
Meaning |
---|---|
ATT |
Attribute Protocol |
BR/EDR |
Basic Rate/Enhanced Data Rate |
CAP |
Common Audio Profile |
CAS |
Common Audio Service |
CSIS |
Coordinated Set Identification Service |
EATT |
Enhanced ATT |
GATT |
Generic Attribute Profile |
L2CAP |
Logical Link Control and Adaption Protocol |
LSO |
least significant octet |
MSO |
most significant octet |
PDU |
Protocol Data Unit |
PSM |
Protocol/Service Multiplexer |
RFU |
Reserved for Future Use |
SDP |
Service Discovery Protocol |
UUID |
universally unique identifier |
6. References
[1] Common Audio Profile Specification, Version 1
[2] Coordinated Set Identification Service Specification, Version 1 with Errata Correction 17454
[3] Bluetooth Core Specification, Version 5.3 and later
[4] Bluetooth Assigned Numbers, https://www.bluetooth.com/specifications/assigned-numbers