Audio/Video Control Transport Protocol Specification

The Bluetooth® Audio/Video Control Transport Protocol specification, hereafter referred to as AVCTP, describes the transport mechanisms used to exchange messages for controlling Audio and/or Video devices. The actual message contents are defined in the applicable A/V control profiles.

AVCTP is used to transport the command/response messages exchanged for the control of distant A/V devices over point-to-point connections. AVCTP does not describe the format and coding of the command and/or response frames used to control an A/V device; command and/or response format and coding rules are specified by the related control profiles.

The AVCTP transaction model is defined in Section 3, AVCTP Generic Transaction Model.

The Audio/Video Control Transport Protocol (hereafter referred to as AVCTP) defines the binary transactions issued between a pair of Bluetooth devices for audio-video (A/V) function discovery and control.

Figure 2.1. AVCTP as Control Layer between Bluetooth Devices

AVCTP uses point-to-point signaling over connection-oriented L2CAP channels that must first be set up between both devices. L2CAP channels are the most suitable for the support of A/V applications, which require dedicated transport services for A/V content streaming and feature control on the same link.

AVCTP implementations shall be based on the general architecture described in Figure 2.2.

Figure 2.2. AVCTP Stack Architecture

In Figure 2.1 and Figure 2.2, AVCTP is one of the protocol specifications used in the context of audio and video applications. AVCTP specifies the protocol used to transport the control messages (command and response) between compliant devices in A/V applications.

All A/V protocols are specified independently so that a remote controller function may be implemented in a non-streaming device while an A/V streaming device may not support A/V controls. However, this protocol can coexist in the same device with other A/V protocols and should be able to share a common ACL link.

AVCTP transactions are performed when a command message and possible response messages are exchanged between two compliant devices.

The device that initiates an AVCTP transaction by sending a command message is called the controller (CT). The command message is transmitted to the remote device that is called the target (TG) for this transaction. The target returns zero or more responses back to the controller according to the condition of the target or the type of the initiated transaction.

AVCTP transactions require that an ACL link has been initially set up between the pair of devices that interact for the related procedures. AVCTP transactions are performed on connection-oriented channels to be established between the devices: those transactions consist of bi-directional messages transported on this channel.

The L2CAP channels used for AVCTP transactions are set up, configured, and released using standard L2CAP services according to the procedures of [1]. AVCTP provides full L2CAP channel service encapsulation and ensures that only one channel connection per Protocol/Service Multiplexer (PSM) is used for this purpose between peer devices.

In AV devices controls may exist at both sides of connection. For this reason AVCTP shall be able to support both controller and target functionalities at both sides of the connection.

Between two devices, multiple AVCTP connections may exist. Each AVCTP connection has its own L2CAP channel with its unique PSM value. There shall be only one AVCTP connection per PSM per ACL.

PSM values are required for the AVCTP protocol. These values are assigned by the Bluetooth SIG [2].

The controller initiates a transaction by sending a command to the remote device that is the target for this transaction. A complete AVCTP transaction consists of one message containing a command addressed to the target and zero or more messages containing a response returned to the controller by the target. AVCTP neither controls the command/response message sequence nor defines the rules that describe the controller and target behavior; such rules are defined by the control profiles that use the AVCTP transport services.

An example of a basic transaction, in which a target performs an internal action on receipt of a command message and then returns a response, is shown in Figure 3.1.

Figure 3.1. AVCTP Basic Transaction Example

In this specification the leftmost position in the drawings and tables represent the MSB of the corresponding byte or field.

When multiple bit fields are contained in a single byte and represented in a drawing, the more significant (high-order) bits are shown toward the left and the less significant (low-order) bits toward the right.

When drawn vertically multiple-byte fields are represented with the more significant bytes (high order) toward the top and the less significant bytes (low order) toward the bottom; when drawn horizontally the more significant bytes (high order) are represented toward the left and the less significant bytes (low order) toward the right.

In this transaction model the response message is not compelled: whether the target sends back one or more response message depends on the application not on the reliability of the transport. The message service is a transport service that only ensures the integrity of a passed on message. On unreliable ACL links the transmission can fail: in such case it is up to the application to decide about retransmission of the complete message. In other words as the response message is not compelled actual acknowledgment of a command is not supervised by the protocol itself.

The payload size is always adjusted to fit octet boundaries in packet transmission.

Each AVCTP command or response message is transmitted in one or several AVCTP packets that consist of a packet header part and a variable length message information part. As AVCTP packets do not contain length information they rely on the L2CAP packet length field to delimit the transported packets: for this reason each AVCTP packet shall be transported on a single L2CAP packet.

The header part includes a transaction label that uniquely identifies the transaction with a limited scope in the command/response flow and packet type information that provides support for message fragmentation.

The message information part contains the command or response data with a flow direction indicator and profile context information (see Section 6.2).

Each AVCTP command/response message is identified by a transaction label field, which specifies a unique tag for each transaction. The transaction label field is a 4-bit field. All transaction label values are valid and all values shall be accepted by all AVCTP implementations. On the controller and the target side, handling of transaction labels is dependent on the application, and is therefore not defined in this specification. AVCTP uses the transaction label in the destination entity to identify AVCTP packets that belong to the same message: the application shall provide label values that permit differentiation between packets of different messages. Transaction labels are tied to the L2CAP channel, i.e. the same transaction label on different L2CAP channels belongs to different messages.

In the AVCTP transaction model, most command or response messages are transported as payload of a single L2CAP packet. Occasionally large messages need to be fragmented by AVCTP for the transport over more than one L2CAP packet: the number of required L2CAP packets depends on the Maximum Transmission Unit (MTU) the channels have negotiated according to the procedures in [1]. The Packet_Type field (see Section 6.1.2) qualifies each L2CAP packet as either first (Packet_Type=01), continue (Packet_Type=10), or end packet (Packet_Type=11). In the case of a non-fragmented message (see Section 6.1.1), this field (Packet_Type=00) simply indicates that the message fits into a single packet and the number of packets is not inserted in the message.

As AVCTP packets can be transmitted on unreliable ACL connections, the number of packets to be expected at the destination side shall be inserted by the AVCTP sender side in front of the first packet message information. Fragmented messages shall be completely transmitted on the same L2CAP channel. The interleaving of the fragments of different packets is not allowed.

AVCTP is used by applications to convey control messages transparently between applications. Depending on the configuration complexity, different profiles with different usage rules may be supported by controllers and targets. AVCTP uses the concept of a Profile Identifier to allow applications to discriminate messages related to different profiles.

In AVCTP transactions, a Profile Identifier field is used to represent the profile control mechanisms to which the transported message is referring. When a controller application wants to initiate a transaction according to some profile rules, it first selects the appropriate PID value for this profile and passes this value to AVCTP for insertion in front of the command message to be sent (see Section 6.2). If the received PID value is in the supported range, the target decodes the command message according to the related profile rules. In its response the target application shall indicate the received PID value of the matching command in order that the controller can decode the response message using the same rules.

This protocol provides an indication of the type of received message (command or response). As the device may support the dual role of controller and target in the same application, the message type information provides discrimination in command/response flows that relate to the assigned device roles.

As L2CAP supports variable payload length, no additional length information in AVCTP packets is required.

In AVCTP configurations the device that supports the controller functionality is also responsible for initiating the L2CAP channel connections on request of the application. As both sides of the connection may support an active controller or controllers for different profiles all AVCTP implementations shall include a channel management entity to resolve conflicting requests and shall ensure that only one channel is connected between peer entities per PSM value.

By nature control transactions between AV devices are sporadic; therefore a target could presumably request for releasing the channel while it is still in use by a controller application at the remote side or when the channel is still in use for another control profile. This could cause the target to be unresponsive for a while at a next user command because the channel needs to be re-established first by the controller side. Therefore each AVCTP entity is responsible to register/deregister the channel connection usage on a per profile basis locally.

The packet header format depends on the possible fragmentation of the message.

6.1.1. Non-Fragmented AVCTP Message

The following table describes the generic format of an AVCTP message encapsulated in a single L2CAP packet.

Table 6.1. Not-Fragmented AVCTP Packet Format

The Transaction label field (octet 0, bits 7-4) value is provided by the application.

The Packet_type field (octet 0, bits 3 and 2) is set to zero (00) to indicate that the command/response message is transmitted in a single L2CAP packet.

C/R (octet 0, bit 1) indicates whether the message conveys a command frame (0) or a response frame (1). It is provided by the application.

The IPID bit (octet 0, bit 0) is set in a response message to indicate an invalid profile identifier received in the command message of the same transaction; otherwise this bit is set to zero. In command messages this bit is set to zero.

The Profile Identifier (PID) field indicates that the command/response frame is coded according to the rules defined by the identified profile. The value shall be identical to the 16-bits UUID of the service class defined for this profile in the Bluetooth Assigned Numbers document [2].

Figure 6.1 depicts the encapsulation process for Command/Response messages that fit the MTU requirements for transport in a single L2CAP packet.

Figure 6.1. Unfragmented AVCTP Message: Encapsulation

6.1.2. Fragmented AVCTP Message

The following section describes the format of AVCTP packets used to transport AVCTP command/response messages that cannot fit in a single L2CAP packet.

Fragmentation shall occur in the transmitting AVCTP entity to divide a too large message information into AVCTP packets less than or equal to the L2CAP negotiated MTU limit before sending them to the L2CAP layer. Fragmented messages are marked by a specific packet type code in each packet of the sequence. There are three possible types used in fragmented message packets:

• The start packet type for the first packet in the sequence.

• The continue packet type is used for all subsequent packets that are not the last packet in the sequence.

• The end packet type qualifies the last packet in the sequence.

At the receiving side the AVCTP entity reassembles the complete message by identifying packets that belong to the same transaction and by inspecting the type of each packet.

The L2CAP channel guarantees individual AVCTP packet integrity and delivery in the right order, not the integrity of the entire message. As the channel can be unreliable, some AVCTP packets in the sequence can be lost. As the start packet provides the number of AVCTP packets needed to reassemble the complete message, the AVCTP receiving entities shall implement a consistency check and discard any incomplete message.

When an application has a packet to send on a certain AVCTP connection, AVCTP must not begin sending it before it has finished processing a message it is in the middle of sending on that AVCTP connection whether or not it is on a different PID or transaction label. The interleaving of different packet fragments on the same AVCTP connection is not allowed.

The receiver of a fragmented message may allocate the resources for message reassembly based on the start packet length and the number of packets information elements provided by the first packet. For this reason:

• The payload of the L2CAP packets that encapsulate the start and continue packets of a fragmented AVCTP message shall have the same length.

• The payload of the L2CAP packet that encapsulates the end packet of an AVCTP message shall not be larger than the start and continue packets belonging to the same message.

The following tables describe the detailed format for each AVCTP packet type used in fragmented messages.

Table 6.2. Fragmented AVCTP Message Packet Format: Start Packet

Table 6.3. Fragmented AVCTP Message Packet: Continue Packet

Table 6.4. Fragmented AVCTP Message Packet: End Packet

The Transaction label field (octet 0, bits 7-4) value is provided by the application and is replicated by the sender of the message in each packet of the sequence. It is used at the receiver side to identify packets that belong to the same message.

The Packet_ type (octet 0, bits 3 and 2) field qualifies the AVCTP packet as a start (01), continue (10), or end (11) packet.

C/R (octet 0, bit 1) indicates whether the message conveys a command frame (0) or a response frame (1). This field is provided by the application and is present in each packet of the message.

The IPID bit (octet 0, bit 0) is set in a response message to indicate an invalid Profile Identifier received in the command message of the same transaction; otherwise this bit is set to zero. In command messages this bit is set to zero. This field is only present in the start packet of the message.

The Number of AVCTP Packets is present in every start packet (octet 2) to indicate the total number of AVCTP packets that belong to the same message. As the start packet is also counted, this value is always greater than 1.

The RFA field (octet 0, bit 0) replaces the IPID field in continue or end packets. It is reserved for future additions and shall be set to zero (0).

The Profile Identifier (PID) field indicates that the message information part is coded according to the rules defined by the identified profile. The value shall be identical to the 16-bits UUID of the service class defined for this profile in the Bluetooth Assigned Numbers document [2]. This field is only present in the start packet of the message.

The next figure depicts the encapsulation process for Command/Response messages that do not fit within the MTU requirements for transport in a single L2CAP packet.

Figure 6.2. Fragmented AVCTP Message: Encapsulation

The AVCTP message information part consists of a variable length command/response frame.

The format, coding, and usage rules of the command/response frames depend on the PID value indicated by the header. Those requirements are specified in the relevant profile.

Each control profile that mandates AVCTP in a protocol descriptor list has an associated Profile Identifier (PID) for use by compliant devices to exchange AVCTP messages in the context of this profile: actually the PID value refers to the message coding and usage rules used by the indicated profile and shall be set to the Service Class UUID of the relevant profile.

For each discoverable control profile registration of the PID value for use by the local AVCTP transport service is mandatory. A description of the registration service can be found in [1]. Each AVCTP implementation shall provide resources to support the required number of PIDs the local device exposes.

A target AVCTP entity shall not hand down command messages that do not carry a registered PID: in this case AVCTP shall directly return a response message made of the 3-octets packet header with the PID value copied from the command and the IPID bit set to 1. The message shall not contain any response frame data.

Description:

The aim of this primitive is to request an application callback when the selected indication Event occurs. Each profile shall register for being called back separately.

Input Parameters:

Event definitions:

This parameter is provided by the application at AVCT_MessageRec event registration time.

Output Parameters:

Callback Input Parameters:

In order to fulfill the requirements for Channel Management Services (see § 5), the following behavior is expected for the channel establishment:

The following behavior is expected for the channel release: