Simultaneous Use of HFP A2DP and AVRCP - WP - V11 PDF

18 November 2008
Status
Approved
Revision
V11
Document File Name
Simultaneous Use of HFP
A2DP and AVRCP_WP.doc
Document Owner
A/V Working Group
E-mail Address
avv-feedback@bluetooth.org
SIMULTANEOUS USE OF
HFP, A2DP, AND AVRCP
PROFILES
ABSTRACT:
This white paper recommends procedures for use of

HFP, A2DP and AVRCP for different common use
cases.
SIMULTANEOUS USE OF HFP, A2DP, AND AVRCP PROFILES
Revision History
Revision
Date
Description
V10
11 Jan 2007
Approved
Ver.1.1 Rel.01
04 Jun 2007
Changed HQ ring tone issues. Added Metadata Transfer MSCs.
Ver.1.1 Rel.02
06 Jun 2007
Changed/added Metadata Transfer MSCs.
Ver.1.1 Rel.03
08 Jul 2007
Deleted HQ ring tone statements.
Ver.1.1 Rel.04
01 Oct 2007
Typo error corrections and editorial changes

Supporting AVRCP_PAUSE is recommended
PLAY_STATUS issue in AVRCP 1.3 is added
Ver 1.1 Rel 05
05 Oct 2007
Reflects updates from AV WG F2F
Ver 1.1 Rel 06
06 Oct 2007
Final edits before approval
Ver 1.1 Rel 07
29 Nov 2007 Reflects comments from UEG and BARB
Ver 1.1 Rel 08
05 Dec 2007
Including feedback from AV WG members and BARB
Ver 1.1 Rel 09
25 Apr 2008
Final version for Ver 1.1
Ver 1.1 Rel 10
01 July 2008 Updated based on UPF feedback and BARB comments
Ver 1.1 Rel 11
11 Aug 2008 Updated based on AV WG CC the 11th of August
Ver 1.1 Rel 12
02 Sep 2008 Updated based on BARB comments
V11
18 Nov 2008
Contributors
Name
Company
Ash Kapur
Broadcom
Rdiger Mosig
BMS
Gordon Downie
CSR
Akira Miyajima
Denso
Masashi Miura
Denso
Morgan Lindqvist
Ericsson
Baskar Subramanian
Impulsesoft
Ilya Goldberg
Matsushita
Tsuyoshi Okada
Matsushita
Thomas Karlsson
Mecel
David Wiedenheft
Motorola
Ross Bundy
Motorola
Martti Niska
Nokia
Janne Hamalainen
Nokia
Thomas Block
Nokia
Brian Gix
Open Interface
Sbastien Henrio
Parrot
18 November 2008 2
Erik Schylander
Philips
Laurent Meunier
Philips
Scott Walsh
Plantronics
John Larkin
Qualcomm
Terry Bourk
RFMD
Dmitri Toropov
Siemens
Atsushi Ichise
Sony
Masahiko Seki
Sony
Wilhelm Hagg
Sony
Dick de-Jong
SonyEricsson
Patric Lind
SonyEricsson
Sin James
Symbian
Makoto Kobayashi
Toshiba
Makoto Yamashita
Toshiba
Shuichi Sakurai
Toshiba
DISCLAIMER AND COPYRIGHT NOTICE

THIS DOCUMENT IS PROVIDED AS IS WITH NO WARRANTIES WHATSOEVER, INCLUDING ANY WARRANTY OF
MERCHANTABILITY, NONINFRINGEMENT, FITNESS FOR ANY PARTICULAR PURPOSE, OR ANY WARRANTY OTHERWISE
ARISING OUT OF ANY PROPOSAL, SPECIFICATION OR SAMPLE. Any liability, including liability for infringement of any proprietary
rights, relating to use of information in this document is disclaimed. No license, express or implied, by estoppel or otherwise, to any
intellectual property rights are granted herein.
This document is for comment only and is subject to change without notice.
Copyright 20012008 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 November 2008 3
CONTENTS
1 TERMS AND ABBREVIATIONS ........................................................................................................... 7
2 DOCUMENT TERMINOLOGY ............................................................................................................... 8
3 SCOPE
........................................................................................................................................ 9
4 CONFIGURATION AND ROLES ......................................................................................................... 10

4.1 MEDIA PLAYER (MP) ................................................................................................................... 10
4.1.1 RECOMMENDATION ....................................................................................................... 10
4.1.2 MOTIVATION.................................................................................................................... 10
4.2 RENDERING DEVICE (RD)........................................................................................................... 10
4.2.1 RECOMMENDATION ....................................................................................................... 10
4.2.2 MOTIVATION.................................................................................................................... 10
4.3 REMOTE CONTROLLER (RC) ..................................................................................................... 11
4.3.1 RECOMMENDATION ....................................................................................................... 11
4.3.2 MOTIVATION.................................................................................................................... 11
4.4 AUDIO GATEWAY WITH MEDIA PLAYER (AG_MP) ................................................................. 11
4.4.1 RECOMMENDATION ....................................................................................................... 11
4.4.2 MOTIVATION.................................................................................................................... 11
4.5 HANDSFREE WITH RENDERING DEVICE CAPABILITIES (HF_RD) ........................................ 11
4.5.1 RECOMMENDATION ....................................................................................................... 11
4.5.2 MOTIVATION.................................................................................................................... 11
5 RECOMMENDATIONS AND MOTIVATIONS ..................................................................................... 12
6 SCENARIOS ...................................................................................................................................... 18
6.1 USE CASES FOR A2DP/VDP TOGETHER WITH AVRCP.......................................................... 18
6.1.1 AVDTP+AVCTP CONNECTION ESTABLISHMENT....................................................... 18
6.1.1.1 PRE-CONDITIONS ................................................................................................. 18
6.1.1.2 USER ACTIONS ..................................................................................................... 18
6.1.1.3 POST CONDITIONS ............................................................................................... 18
6.1.1.4 RECOMMENDATION ............................................................................................. 18
6.1.1.5 MESSAGE SEQUENCE CHARTS ......................................................................... 18
6.1.2 AVDTP+AVCTP: USE OF SNIFF MODE ......................................................................... 20
6.1.3 AVDTP+AVCTP IN IDLE STATE ..................................................................................... 20
6.1.4 AVDTP+AVCTP CONNECTION RELEASE .................................................................... 20
6.1.4.1 PRE-CONDITIONS ................................................................................................. 20
6.1.4.2 USER ACTIONS ..................................................................................................... 20
6.1.4.3 POST CONDITIONS ............................................................................................... 20
6.1.4.4 RECOMMENDATION ............................................................................................. 20
6.1.5 AVDTP+AVCTP CONNECTION RE-ESTABLISHMENT ................................................ 22
6.1.5.1 RECOMMENDATION ............................................................................................. 22
6.1.6 A2DP/VDP+AVRCP: START OF STREAMING MEDIA .................................................. 22
6.1.6.1 PRE-CONDITIONS ................................................................................................. 22
6.1.6.2 USER ACTIONS ..................................................................................................... 22
6.1.6.3 POST CONDITIONS ............................................................................................... 23
18 November 2008 4
6.1.6.4 RECOMMENDATION ............................................................................................. 23

6.1.7 A2DP/VDP+AVRCP: STOP OF STREAMING MEDIA .................................................... 24
6.1.7.1 PRE-CONDITIONS ................................................................................................. 24
6.1.7.2 USER ACTIONS ..................................................................................................... 24
6.1.7.3 POST CONDITIONS ............................................................................................... 25
6.1.7.4 RECOMMENDATION ............................................................................................. 25
6.1.8 A2DP/VDP+AVRCP HANDLING A PLAYLIST ............................................................... 27
6.1.8.1 PRE-CONDITIONS ................................................................................................. 27
6.1.8.2 USER ACTIONS ..................................................................................................... 27
6.1.8.3 POST CONDITIONS ............................................................................................... 27
6.1.8.4 RECOMMENDATION ............................................................................................. 27
6.1.9 A2DP/VDP+AVRCP CHANGE OF VOLUME .................................................................. 29
6.1.9.1 PRE-CONDITIONS ................................................................................................. 29
6.1.9.2 USER ACTIONS ..................................................................................................... 29
6.1.9.3 POST CONDITIONS ............................................................................................... 29
6.1.9.4 RECOMMENDATION ............................................................................................. 29
6.2 USE CASES FOR HFP + A2DP/VDP + AVRCP........................................................................... 31
6.2.1 HFP+AVDTP+AVCTP CONNECTION ESTABLISHMENT ............................................. 31
6.2.1.1 PRE-CONDITIONS ................................................................................................. 31
6.2.1.2 USER ACTIONS ..................................................................................................... 31
6.2.1.3 POST CONDITIONS ............................................................................................... 31
6.2.1.4 RECOMMENDATION ............................................................................................. 31
6.2.2 HFP+AVDTP+AVCTP: USE OF SNIFF MODE ............................................................... 31
6.2.3 HFP+AVDTP+AVCTP CONNECTION RELEASE ........................................................... 32
6.2.4 HFP+AVDTP+AVCTP CONNECTION RE-ESTABLISHMENT ....................................... 33
6.2.5 HFP+A2DP/VDP+AVRCP INCOMING CALL WHEN LISTENING TO MUSIC FROM
THE SAME DEVICE, NO HQ RING SIGNAL .................................................................. 33
6.2.5.1 PRE-CONDITIONS ................................................................................................. 33
6.2.5.2 USER ACTIONS ..................................................................................................... 34
6.2.5.3 POST CONDITIONS ............................................................................................... 34
6.2.5.4 RECOMMENDATION ............................................................................................. 34
6.2.6 HFP+A2DP/VDP+AVRCP INCOMING CALL WHEN LISTENING TO MUSIC FROM A
THIRD DEVICE, NO HQ RING SIGNAL .......................................................................... 35
6.2.6.1 PRE-CONDITIONS ................................................................................................. 35
6.2.6.2 USER ACTIONS ..................................................................................................... 35
6.2.6.3 POST CONDITIONS ............................................................................................... 35
6.2.6.4 RECOMMENDATION ............................................................................................. 35
6.2.7 HFP+A2DP/VDP+AVRCP OUTGOING CALL WHILE LISTENING TO MUSIC FROM A
THIRD DEVICE ................................................................................................................. 36
6.2.7.1 PRE-CONDITIONS ................................................................................................. 36
6.2.7.2 USER ACTIONS ..................................................................................................... 37
6.2.7.3 POST CONDITIONS ............................................................................................... 37
6.2.7.4 RECOMMENDATION ............................................................................................. 37
6.2.8 HFP+A2DP/VDP+AVRCP OUTGOING CALL WHILE LISTENING TO MUSIC ............. 39
6.2.8.1 PRE-CONDITIONS ................................................................................................. 39
6.2.8.2 USER ACTIONS ..................................................................................................... 39
6.2.8.3 POST CONDITIONS ............................................................................................... 39
18 November 2008 5
6.2.8.4 RECOMMENDATION ............................................................................................. 39

6.2.9 HFP+A2DP/VDP+AVRCP CHANGE OF VOLUME ......................................................... 40
6.2.9.1 PRE-CONDITIONS ................................................................................................. 40
6.2.9.2 USER ACTIONS ..................................................................................................... 40
6.2.9.3 POST CONDITIONS ............................................................................................... 40
6.2.9.4 RECOMMENDATION ............................................................................................. 40
7 MESSAGE SEQUENCE CHART SUB-SCENARIOS ......................................................................... 42
7.1 HALT STREAMING ....................................................................................................................... 42
7.2 RESTORE STREAMING ............................................................................................................... 43
7.3 METADATA TRANSFER .............................................................................................................. 43
8 REFERENCES ..................................................................................................................................... 44
APPENDIX. LIST OF SUPPORTED RECOMMENDATIONS.................................................................... 45
18 November 2008 6
1 Terms and Abbreviations

Terms and Abbreviations
Abbreviation
Term
A2DP
Advanced Audio Distribution Profile
AG
Audio Gateway (as in HFP)
AG_MP
Audio Gateway and Media Player
AVDTP
Audio Video Distribution Transport Protocol
AVRCP
Audio Video Remote Control Profile
GAVDP
Generic Audio/Video Distribution Profile
HF
HandsFree (as in HFP)
HF_RD
HandsFree and Rendering Device
HFP
HandsFree Profile
Inband ring tone
Any audio using (e)SCO for ringing
HQ ring tone
Any audio using A2DP for ringing
MP
Media Player
NA
Not Applicable
RC
Remote Controller
RD
Rendering Device
SNK
Sink (as in A2DP/VDP)
SRC
Source (as in A2DP/VDP)
UI
User Interface
Some possibility for the user to interact with the system. Can be just some buttons
or a more complex UI may be e.g. a display with keyboard or touch screen.
VDP
Video Distribution Profile
18 November 2008 7
2 Document Terminology
The Bluetooth SIG has adopted Section 13.1 of the IEEE Standards Style Manual, which dictates use of the
words ``shall, ``should, ``may, and ``can in the development of documentation, as follows:
The word shall is used to indicate mandatory requirements strictly to be followed in order to conform to the
standard and from which no deviation is permitted (shall equals is required to).
The use of the word must is deprecated and shall not be used when stating mandatory requirements; must is
used only to describe unavoidable situations.
The use of the word will is deprecated and shall not be used when stating mandatory requirements; will is
only used in statements of fact.
The word should is used to indicate that among several possibilities one is recommended as particularly
suitable, without mentioning or excluding others; or that a certain course of action is preferred but not
necessarily required; or that (in the negative form) a certain course of action is deprecated but not prohibited
(should equals is recommended that).
The word may is used to indicate a course of action permissible within the limits of the standard (may equals
is permitted).
The word can is used for statements of possibility and capability, whether material, physical, or causal (can
equals is able to).
18 November 2008 8
3 Scope
This white paper describes how A2DP and AVRCP should be used together and in conjunction with HFP, to
achieve high interoperability in all functions defined in the profiles. The scenarios and the sequences of the
procedures defined in this white paper are not mandatory and there is no requirement from Bluetooth SIG that
they shall be followed.
The A2DP profile should be seen as a way to setup and configure the actual transport of a streaming audio
link, the A2DP profile should not be used to control the applications streaming data for which the AVRCP
profile should be used.
18 November 2008 9
4 Configuration and Roles

4.1 MEDIA PLAYER (MP)
The media player can among other devices be a portable media player (MP3 player, video player or
mobile phone) or a fixed media player (home audio/video system or in-car audio/video system).
4.1.1 RECOMMENDATION
The media player should support the following roles
A2DP and/or VDP SRC
AVRCP 1.3 TG, category 1 and at least supporting PlayStatus and the Play, Pause and Stop
commands.
AVRCP 1.3 CT, category 2 and at least supporting AbsoluteVolume command and reporting
functionality and the Volume Up and Down commands if A2DP SRC is supported.
AVRCP TG, category 2 and at least supporting the Volume Up and Down commands if A2DP SRC is
supported.
4.1.2 MOTIVATION
The media player should support A2DP/VDP SRC role to enable streaming of audio/video to a SNK
device, it should also support the AVRCP TG role to be able to receive incoming Play, Stop and other
commands from the rendering device or the remote controller. Finally it should also support the AVRCP
CT role to be able to send volume up/down commands to the rendering device. The third bullet above is
important since not all rendering devices will have a local volume control or the rendering device, e.g.
loudspeakers, is not in the vicinity of the user.
The reason for the MP to be an AVRCP TG for category 2 is to allow a RC to connect to the MP and send
volume UP/DOWN commands to it.
4.2 RENDERING DEVICE (RD)
The rendering device can among other devices be headphones, loudspeakers, in-car audio systems or a
video display with optional audio capabilities.
The rendering device should support the following roles
A2DP and/or VDP SNK
AVRCP 1.3 CT, category 1, supporting at least the Play, Pause, Stop and GetPlayStatus commands
and the EVENT_PLAYBACK_STATUS_CHANGED notification.
AVRCP 1.3 TG, category 2, supporting at least AbsoluteVolume command and reporting functionality
and the Volume Up and Down commands in case A2DP SNK is supported.
4.2.2 MOTIVATION
The rendering device should support A2DP SNK role to be able to receive audio from a media player.
It should also support the AVRCP CT role to be able to send AVRCP Play, Pause, Stop, Forward, Rewind
GetPlayStatus commands, among others, to the media player. The
EVENT_PLAYBACK_STATUS_CHANGED notification will ensure that the RD knows the play back state
of the media player. Finally it should also support the AVRCP TG role to allow the media player to change
the volume on the rendering device by sending AVRCP volume up/down commands to it.
Rendering devices without user input capabilities, e.g. home audio system loudspeakers, should not
support the AVRCP CT role..
18 November 2008 10
4.3 REMOTE CONTROLLER (RC)

The remote controller can among other devices be a device that only has the functionality of a remote
controller; it can also be a multi functional device that supports other functionality as well. Headphones
can be seen as one example of a multifunctional device.
The remote controller should support the following role
AVRCP 1.3 CT, category 1 supporting at least the Play, Pause, Stop and GetPlayStatus commands
and the EVENT_PLAYBACK_STATUS_CHANGED notification..
AVRCP 1.3 CT, category 2 supporting Volume Up and Down.
4.3.2 MOTIVATION
The remote controller should support the AVRCP CT role to be able to send play, stop, pause, and other
commands to the media player. The EVENT_PLAYBACK_STATUS_CHANGED notification will ensure
that the RC knows the play back state of the media player.
4.4 AUDIO GATEWAY WITH MEDIA PLAYER (AG_MP)
This kind of device has the capabilities defined in the HFP specification for AG (see /1/) and has the
capabilities from 4.1. Typical devices are cellular-phones.
The recommendation is the same as written in 4.1.1.
4.4.2 MOTIVATION
The motivation is the same as written in 4.1.2
4.5 HANDSFREE WITH RENDERING DEVICE CAPABILITIES (HF_RD)
This kind of device has the capabilities defined in the HFP specification for HF (see /1/) and has the
capabilities for a rendering device (see 4.2). Typical devices are headsets or car kits.
The recommendation is the same as written in 4.2.1.
4.5.2 MOTIVATION
The motivation is the same as written in 4.2.2.
18 November 2008 11
5 Recommendations and Motivations

This section summarizes all motivations and recommendations used in the different use cases.
Recommendation 1:
If both AVDTP and AVCTP protocols are supported, then both the AVDTP signaling and AVCTP signaling
connections should be established when the user powers on the device or performs user action to establish a
connection. This applies to RD, RC and MP.
The order of connection establishment should be as in Recommendation 2.
Note: Only devices having AVCTP CT role should create an AVCTP connection
Motivation 1:
If the AVDTP connection is not established, it may happen that an AVRCP_PLAY or play initiated on the MP
does not start streaming but may stream on an internal speaker or wired stereo headsets.
Recommendation 2:
If both AVDTP and AVCTP protocols are being connected, then the order of connection establishment should
be first the AVDTP signaling connection and then the AVCTP signaling connection.
Motivation 2:
If an AVRCP PLAY is received by the MP before an AVDTP connection is established, audio may begin to
play on the MP and will not be streamed to the RD, resulting in the first few seconds being lost or being
rendered at another location (e.g. a built-in speaker on the MP).
Recommendation 3:
It is recommended that sniff mode be used when there is no data exchange on AVDTP and AVCTP links.
Sniff mode should not be entered earlier than 3 seconds after the last transaction on the AVDTP or AVCTP
connection.
Note: The implementer should be aware that other profiles may restrict the use of sniff mode.
Motivation 3:
Entering sniff mode saves power and increases battery time.
Recommendation 4:
Before sending an AVDTP signaling command for which TGAVDP100 applies the link should be unsniffed
unless the sniff interval is less than half TGAVDP100.
Motivation 4:
If the link is in sniff mode and the sniff interval is too large, the response message may time out.
Recommendation 5:
When streaming is active sniff mode may be used only if the sniff parameters are sufficient to allow streaming
throughput with the current media CODEC configuration.
Motivation 5:
Sniff mode in STREAMING state may save power and may improve scatternet interoperability
Recommendation 6:
In IDLE and ACTIVE states the AVDTP and AVCTP signaling connections should not be released until the
device is powered off or by explicit user action. This applies to both RD and MP.
18 November 2008 12
Motivation 6:
If the AVDTP connection is already established when streaming of audio is initiated the time between the
initiation and the time audio is streamed over the Bluetooth link, is minimized since the re-establishment of the
AVDTP/ACL connection can take a long time.
Recommendation 7:
When disconnecting, if both AVCTP and AVDTP connections exist, then they should both be disconnected.
This applies regardless if the connections were created by the local device or remote device. The AVCTP
connection should be disconnected first.
Motivation 7:
Disconnecting the AVCTP connection before the AVDTP connection will ensure that will always be an AVDTP
connection up if the AVCTP connection is available. Also, if the RD disconnects AVDTP signaling link and
sends AVRCP_PLAY the MP may not establish an AVDTP signaling link and start streaming but may route
audio to a different output.
Recommendation 8:
If there is no audio to stream from the MP to the RD silence data patterns should not be sent, instead the
streaming connection should be released or suspended by the MP.
Motivation 8:
If silence data patterns are streamed between the MP and the RD or no data sent but the connection remains
in STREAMING state for a long time the battery lifetime will be significantly reduced.
Recommendation 9:
An automatic re-connection policy can be used to re-connect the signaling connections after link loss. In this
case only the RD side should reconnect. The number of attempts and periodicity are implementation
dependant, but it is recommended to have a relatively small limit on the number of attempts to avoid battery
drainage.
Motivation 9:
Since a link loss is an unexpected behavior for the user, an automatic action of attempting to reconnect
improves the user experience. MP should not try to reconnect to avoid collisions.
Recommendation 10:
To start playback from RD, the AVRCP_PLAY command should be sent to the MP; the RD should not try to
use AVDTP procedures to start playback.
Motivation 10:
Since the MP device has the knowledge what the next song will be, it can decide best what CODEC
parameters have to be configured in RD initiated case. If only GAVDP procedures are used, the MP may
have to reconfigure or release, establish and start with the best CODEC parameters for the next audio track.
Recommendation 11:
If a RD device is not complying with Recommendation 6, it is up to the MP to reestablish the AVDTP
signaling link after an AVRCP_PLAY command has been received.
Motivation 11:
This ensures better interoperability with old headsets, which may disconnect the AVDTP signaling link in case
of timeout period in IDLE state.
Recommendation 12:
If the RD has configured and opened a stream it is also responsible to start the streaming via
GAVDP_START.
Motivation 12:
18 November 2008 13
This ensures that streaming is started as defined in the AVDTP specification (see /2/).
Recommendation 13:
To stop/pause audio from the RD the AVRCP_STOP or AVRCP_PAUSE command should be used. The RD
should not use the AVDTP signaling commands to control the media player.
Note: It is not mandatory for the MP to implement AVRCP_PAUSE, so the RD should send also
AVRCP_STOP if it receives NOT_IMPLEMENTED as a response to AVRCP_PAUSE commend.
AVRCP_STOP should be used to stop audio, not to close the application.
Motivation 13:
The RD should not use AVDTP commands because it has no idea if the source device has other media
sources (for instance notification sounds or other media player applications) and media could end up in other
output (for instance MP local loudspeaker) or not rendered at all.
Recommendation 14:
For both target and controller, AVRCP_PAUSE means pause and AVRCP_PLAY means play.
To restart a stream after an AVRCP_PAUSE the AVRCP_PLAY command should be used.
If MP and RD supports AVRCP 1.3, the RD should send AVRCP_PLAY or AVRCP_PAUSE after getting the
PLAY_STATUS of the MP.
Note: If the RD has only a single button control for pause and play and the MP does not support AVRCP 1.3,
the RD should toggle sending AVRCP_PAUSE and AVRCP_PLAY for each button press on the RD UI.
Note: There are controller devices on the market that do not follow this recommendation. For backwards
compatibility, the target may choose to treat PAUSE as a toggle.
Motivation 14:
The RD should not assume that a pause command followed by another pause command, will lead to a play
state. AVRCP_PLAY is the unambiguous command to start playing.
Recommendation 15:
If a RD requests to play the next song (or any song in the play list) while AVDTP State is
CONFIGURED/OPEN or STREAMING the MP shall check the encoding parameters of the song and may
need to reconfigure the stream or release-establish-start the stream with the best CODEC parameters for the
next song.
Motivation 15:
This ensures better interoperability with older headsets.
Recommendation 16:
If volume is changed on the RD, the RD should not send an AVRCP volume command to the MP device.
Motivation 16:
Sending an AVRCP volume command to the MP may cause the MP to send again an AVRCP volume
command to the RD device which could lead to an endless loop of AVRCP volume commands.
Recommendation 17:
If a device receives an AVRCP volume command, it shall not send back an AVRCP volume command.
Motivation 17:
This will also ensure that endless loop does not happen with existing devices which do not comply with the
recommendation.
Recommendation 18:
18 November 2008 14
The HFP service level connection, AVDTP signaling and AVCTP signaling connections should be established
depending on the actions taken when the user powers on the device, performs user action to establish a
connection, or due to an internal event. This applies to AG_MP and HF_RD.
The order of connection establishment should be HFP service level connection first, AVDTP signaling link
connection next and AVCTP signaling connection last.
Motivation 18:
HFP SLC should be connected first since HFP has the highest priority and should be quickly available e.g. if a
call is incoming or already active. For the order of AVDTP and AVCTP please see Motivation 2).
Recommendation 19:
When it gets an indication of an incoming phone call, the HF_RD should not open an (e)SCO but should rely
on the AG to open the (e)SCO when needed.
Motivation 19:
This allows the AG_MP to configure the (e)SCO according to local preferences.
Recommendation 20:
If any kinds of inband ring tones are enabled, the HF_RD should not produce an out-of-band ringing tone by
itself.
Motivation 20:
This ensures that the user hears the AG_MP generated ringing signal and not a mixture of this one and a
locally generated ring tone
Recommendation 21:
In the case that an HF_RD is connected to both an AG and a different MP, and there is an incoming phone
call while streaming is active, when the HF_RD gets the indication of that call it should automatically pause
the music from the MP by sending AVRCP_PAUSE. After rejecting or finishing the call the HF_RD should
send AVRCP_PLAY to continue streaming.
Note: If the AVRCP_PAUSE is not supported or if the streaming state is remaining, the RD should perform
the GAVDP_Connection_Release procedure.
Motivation 21:
Pausing the stream saves bandwidth. In a scatternet scenario this reduces disturbances. If streaming is
ongoing at the same time as the (e)SCO link is established the AT commands between the RD_HF and
AG_MP may be delayed.
Recommendation 22:
When music is streamed from an AG_MP to an HF_RD, and the AG_MP would like to setup a (e)SCO link
the AG_MP should automatically close or suspend the stream.
Motivation 22:
Closing or suspending the stream saves bandwidth. If streaming is ongoing at the same time as the (e)SCO
link is established the AT commands between the RD_HF and AG_MP may be delayed.
Recommendation 23:
When a stream is suspended or closed by an AG_MP, the stream should be restarted by the AG_MP when it
is ready to do so.
Motivation 23:
The AG_MP knows when the stream should be restarted. This will ensure that there is no race condition in
restarting the stream, or that neither side tries to restart the stream.
Recommendation 24:
18 November 2008 15
In the case that an HF_RD is connected to both an AG and a different MP when a call is detected, and the
HF_RD uses GAVDP_Connection_Release or GAVDP_Suspend to stop the stream, the HF_RD is
responsible to restart the stream after the phone call is ended or rejected.
Motivation 24:
In this scenario, the HF_RD is the device that knows when the stream should be restarted.
Recommendation 25:
An AVRCP volume command should not change the HFP volume level in the HF_RD device.
Motivation 25:
HFP has its own volume level commands. This simplifies the device state machine and avoids problems with
volume levels in different states.
Recommendation 26:
The HFP volume command should not change the volume on A2DP.
Motivation 26:
HFP has its own volume level commands. This simplifies the device state machine and avoids problems with
volume levels in different states.
Recommendation 27:
The SBC stream should always be encoded at maximum level, and any volume adjustments should be done
at the RD after decoding the SBC stream.
Motivation 27:
If the SBC stream is encoded at less than maximum level, and then the volume is increased at the RD, there
will be a loss of precision that can result is lower audio quality.
Recommendation 28:
In a scenario where there is both an Audio and Handsfree connection between the AG_MP and the HF_RD
the HF_RD should assume that the AG_MP will act correctly when an incoming or outgoing call occurs.
Motivation 28:
This will ensure that there are no race conditions in the signaling.
Recommendation 29:
When the AG_MP or the HF_RD receive a disconnect of AVDTP/AVCTP signaling link, or HFP service level
connection, it should not as a result of this, disconnect any remaining connections
Motivation 29:
The local side does not know why the connections were terminated and should hence not act upon it.
NOTE: The reason for the HF_RD to disconnect may be that it is receiving streaming data from a second MP
and does not have the resources to maintain AVCTP and AVDTP connection to two different devices.
Recommendation 30:
If the AG_MP rejects the HFP SLC, the HF_RD should continue with the establishment of AVDTP and
AVCTP connections with the AG_MP.
Motivation 30:
This will ensure that a HF_RD can be used as a RD only device towards an AG_MP device that is configured
not to accept HFP SLC connections.
Recommendation 31:
18 November 2008 16
The media player application on the MP device should be aware of and handle the situation arising from the
fact that the RD may send media player control commands at the same time as the device locally receives
commands via the local UI or via a connected RC device
Motivation 31:
This will ensure that the MP does not go into a wrong state if the user initiates conflicting commands on two
different UI devices at the same time.
Recommendation 32:
The commands sent from the RD should be interpreted as if they were entered locally on the device, as long
as the normal behavior of the MP follows the other recommendations in the WP.
Motivation 32:
This will ensure that the user experience is the same regardless if the MP is controlled locally or using the CT.
Recommendation 33:
If a device uses GAVDP_Suspend to pause/stop the stream, the same device is responsible to send
GAVDP_START.
Motivation 33:
The device suspending a stream knows when it is possible to resume the streaming again.
Recommendation 34:
If the RD performs automatic connection re-establishment according to recommendation 9 and wishes to
resume playback after reconnection it should send the AVRCP Play command. The RD should not try to
establish the media link using the GAVDP Configure/Open/Start procedures
Motivation 34:
Opening the media connection from the RD has no deterministic result and should be avoided.
18 November 2008 17
6 Scenarios
There are separate sections for three-profile scenarios (HFP, A2DP and AVRCP) and for AV-only profiles
scenarios (A2DP and AVRCP).
6.1 USE CASES FOR A2DP/VDP TOGETHER WITH AVRCP
For cases 6.1.1 to 6.1.9 the involved devices are MP and RD.
6.1.1 AVDTP+AVCTP CONNECTION ESTABLISHMENT
6.1.1.1 PRE-CONDITIONS
In Table 1 the pre-conditions for this scenario are listed.
Device
MP
RD
Paired with
RD
MP
AVCTP Signaling Channel established with
AVDTP Signaling Channel established with
AVDTP State
N/A
N/A
Table 1: Pre-conditions: AVDTP+AVCTP Connection Establishment

6.1.1.2 USER ACTIONS
The following bullets describe the steps that the user takes to connect the devices.
From RD: User powers up the RD and if UI allows, initiates a connection to the MP.
From MP: Depending on the user interface available on the MP the user takes the necessary action to
connect to the RD. If the MP has a GUI, it might be that a device discovery is executed and a list of
devices is shown. The user may select a device to which he wants to connect.
6.1.1.3 POST CONDITIONS
Device
MP
RD
Paired with
RD
MP
RD
MP
RD
MP
AVDTP State
IDLE
IDLE
Table 2: Post-conditions; AVDTP+AVCTP Connection Establishment

6.1.1.4 RECOMMENDATION
See Recommendation 1 and Recommendation 2 from section 5.
6.1.1.5 MESSAGE SEQUENCE CHARTS
If the connection is set up the order should follow the figures.
18 November 2008 18
Figure 1: Connection establishment initiated by MP
:MP
:RD
User takes action to

connect to MP
device discovery and service query is made to check the
supported features
AVDTP signalling link establisment
AVCTP siganlling link establisment
Figure 2: Connection establishment initiated by RD
18 November 2008 19
6.1.2 AVDTP+AVCTP: USE OF SNIFF MODE

See Recommendation 3, Recommendation 4, Recommendation 5 and Recommendation 9 from
section 5.
6.1.3 AVDTP+AVCTP IN IDLE STATE

See Recommendation 6 from section 5.
6.1.4 AVDTP+AVCTP CONNECTION RELEASE

In Table 3, the pre-conditions for this scenario are listed.
Device
MP
RD
Paired with
RD
MP
RD
MP
RD
MP
AVDTP State
Any state
Any state
Table 3: Pre-conditions: AVDTP+AVCTP Connection Establishment

The following bullet describes the steps the user takes to disconnect the devices.
From RD or MP: User powers off the device or uses the UI to disconnect the ACL or takes some other
action which leads to termination of the AVDTP/AVCTP connections.
Device
MP
RD
Paired with
RD
MP
AVDTP State
N/A
N/A
Table 4: Post-conditions; AVDTP+AVCTP Connection Establishment

The AVDTP and AVCTP signaling connections should not be released until the device is powered off
or by explicit user action. This applies to both SNK and SRC role.
The disconnection should be in the order shown the following figures.
18 November 2008 20
:AG_MP
:HF_RD
AVDTP signalling link established

User selects to
disconnect device
If OPEN/STREAMING state
GAVDP_Connection_Release( )
endif
AVCTP signalling link disconnect
AVDTP signalling link disconnect
Figure 3: AVDTP+AVCTP Connection Release initiated by MP
18 November 2008 21
:AG_MP
:HF_RD

User selects to
disconnect device
If OPEN/STREAMING
endif
Figure 4: AVDTP+AVCTP Connection Release initiated by RD

6.1.5 AVDTP+AVCTP CONNECTION RE-ESTABLISHMENT
6.1.6 A2DP/VDP+AVRCP: START OF STREAMING MEDIA

Device
MP
RD
Paired with
RD
MP
RD
MP
RD
MP
AVDTP State
IDLE / OPEN
IDLE / OPEN
Table 5: Pre-conditions: A2DP/VDP+AVRCP Start

Playback is started.
18 November 2008 22
Example:
From RD: The user uses the UI to START the playback.
From MP: Depending on the UI, the user may select from a list and presses a play button.
Device
MP
RD
Paired with
RD
MP
RD
MP
RD
MP
AVDTP State
STREAMING
STREAMING
Table 6: Post-conditions; A2DP/VDP+AVRCP Start

See Recommendation 10, Recommendation 11 and Recommendation 12 from section 5.
MP
RD
AVCTP signaling link established

AVDTP in IDLE/OPEN state
User presses play
IF AVDTP in IDLE state

GAVDP_Connection_Establishment()
ENDIF
GAVDP_Start_Streaming()
metadata transfer
Figure 5: Play Initiated by MP
18 November 2008 23
Figure 6: Play initiated initiated by RD

6.1.7 A2DP/VDP+AVRCP: STOP OF STREAMING MEDIA
Device
MP
RD
Paired with
RD
MP
RD
MP
RD
MP
AVDTP State
STREAMING
STREAMING
Table 7: Pre-conditions: AVRCP+AVDTP Stop

Playback is stopped.
Example:
From RD or MP: The user uses the UI to STOP or PAUSE the playback.
Note: This use case does not apply if there are any sources remaining playing media (mixing).
Streaming may continue if other application in the MP are sending music over Bluetooth link.
18 November 2008 24

Device
MP
RD
Paired with
RD
MP
RD
MP
RD
MP
AVDTP State
IDLE/
OPEN
IDLE/
OPEN
Table 8: Post-conditions; AVRCP+AVDTP Stop

Figure 7: Stop Initiated by MP
18 November 2008 25
:MP
:RD
AVCTP signalling link established

AVDTP in STREAMING state
User
presses stop
or pause
AVRCP stop/pause
stop/pause response
GAVDP_Connection_Release( ) or
GAVDP_Suspend()
Figure 8: Play initiated by RD
18 November 2008 26
6.1.8 A2DP/VDP+AVRCP HANDLING A PLAYLIST

Device
MP
RD
RC
Paired with
RD, RC
MP
MP
RD
MP
RD
MP
AVDTP State
IDLE or
STREAMING
IDLE or
STREAMING
N/A
Table 9: Pre-conditions; A2DP/VDP+AVRCP Handling a Playlist

The following bullets describe the use case scenario with user actions to start or skip audio track from
any device.
Note: The actions done on the RC device can also be done from the RD device.
> User presses play on MP, RD or RC.
> On MP, song end reached and next song started automatically.
> User presses next on MP, RD or RC.
Device
MP
RD
RC
Paired with
RD, RC
MP
MP
RD, RC
MP
MP
RD
MP
AVDTP State
STREAMING
STREAMING
N/A
Table 10: Post-conditions; A2DP/VDP+AVRCP Handling a Playlist

See Recommendation 15: from section 5.
18 November 2008 27

:RC
:MP
:RD
AVDTP state = IDLE
AVCTP signalling link establisment

AVRCP_Play
GAVDP_Connection_Establishment( )
GAVDP_Start_Streaming( )
metadata transfer
The audio stream ends and the next audio stream is

played automatically
Note: If the stream configuration
is the same the 3 procedures
can be omitted.
metadata transfer
The user presses
skip forward
AVRCP_Forward
Note: If the stream configuration
is the same the 3 procedures
can be omitted.
metadata transfer
Figure 9: A2DP/VDP+AVRCP Handling a Playlist
18 November 2008 28
6.1.9 A2DP/VDP+AVRCP CHANGE OF VOLUME

Device
MP
RD
RC
Paired with
RD, RC
MP
MP
RD, RC
MP
MP
RD
MP
AVDTP State
Any
Any
N/A
Table 11: Pre-conditions; A2DP/VDP+AVRCP Change of volume

The following bullet describe the steps that the user takes to increase the volume in the headset.
> From MP or RC: The user changes the volume either on the MP or RC.
Device
MP
RD
RC
Paired with
RD, RC
MP
MP
RD, RC
MP
MP
RD
MP
AVDTP State
Any
Any
N/A
Table 12: Post-conditions; A2DP/VDP+AVRCP Change of volume

Figure 10: A2DP/VDP+AVRCP Change of volume initiated from MP
18 November 2008 29
:RC
: MP
: RD
AVCTP signalling link established

AVDTP state = Any
AVRCP _ VolumeUp / Down

AVRCP _ VolumeUp / Down
volume increased
or decreased
Figure 11: A2DP/VDP+AVRCP Change of volume initiated from RC

The volume command from RC is forwarded by MP to the RD, which leads to a volume increase or
decrease in RD.
18 November 2008 30
6.2 USE CASES FOR HFP + A2DP/VDP + AVRCP

6.2.1 HFP+AVDTP+AVCTP CONNECTION ESTABLISHMENT
The recommendation from 6.1.1 applies but HFP connection should be established first.
Device
AG_MP
HF_RD
Paired with
HF_RD
AG_MP
HFP service level connection established with
AVDTP State
N/A
N/A
Table 13: Pre-conditions; HFP+AVDTP+AVCTP Connection Establishment

The following bullets describe the steps that the user takes to connect the devices.
> From HF_RD: User selects to connect to the AG_MP using UI (this may also be just a power up
of the HF_RD).
> From MP: Depending on the user interface available on the AG_MP the user takes the
necessary action to connect to the HF_RD. If the AG_MP has a GUI, it might be that a device
discovery is executed and a list of devices is shown. The user may select a device to which he
wants to connect.
Device
AG_MP
HF_RD
Paired with
HF_RD
AG_MP
HF_RD
AG_MP
HF_RD
AG_MP
HF_RD
AG_MP
AVDTP State
IDLE
IDLE
Table 14: Post-conditions; HFP+AVDTP+AVCTP Connection Establishment

Except for the requirement that HFP service level connection should be created first the same as
described in chapter 6.1.1.5 applies.
6.2.2 HFP+AVDTP+AVCTP: USE OF SNIFF MODE

The rules from 6.1.2 AVDTP+AVCTP: applies.
18 November 2008 31
6.2.3 HFP+AVDTP+AVCTP CONNECTION RELEASE

The same as in 6.1.4 applies but HFP connection should be disconnected last.
The order of disconnecting should be AVCTP, AVDTP, HFP SLC.
:AG_MP
:HF_RD

User selects to
disconnect device
If OPEN/STREAMING state
endif
HFP service level disconnect
Figure 12: HFP+AVDTP+AVCTP Connection Release initiated from AG_MP
18 November 2008 32
:AG_MP
:HF_RD

User selects to
disconnect device
If OPEN/STREAMING
endif
HFP service level disconnect
Figure 13: HFP+AVDTP+AVCTP Connection Release initiated from HF_RD

6.2.4 HFP+AVDTP+AVCTP CONNECTION RE-ESTABLISHMENT
The recommendation and motivation from 6.1.5 applies. For HFP behavior please see /1/.
6.2.5 HFP+A2DP/VDP+AVRCP INCOMING CALL WHEN LISTENING TO MUSIC FROM THE SAME
DEVICE, NO HQ RING SIGNAL
This use case is applicable if the AG_MP:
is unable to support streaming and (e)SCO simultaneously, or
does not desire to support streaming and (e)SCO simultaneously.
Device
AG_MP
HF_RD
Paired with
HF_RD
AG_MP
HF_RD
AG_MP
HF_RD
AG_MP
AVDTP State
STREAMING
STREAMING
18 November 2008 33
Table 15: Pre-conditions; HFP+A2DP/VDP+AVRCP Incoming call when listening to music FROM the same device,
no HQ ring signal
The following bullet describe the steps that the user takes during incoming call.
> From HF_RD or AG_MP
During streaming a call comes in and the user accepts and later on ends the call or rejects the call
(Possible call procedures are listed in /1/ - ringing, call accept, reject etc.).
Device
AG_MP
HF_RD
Paired with
HF_RD
AG_MP
HF_RD
AG_MP
HF_RD
AG_MP
AVDTP State during call
IDLE or
SUSPENDED
IDLE or
SUSPENDED
AVDTP State after call
STREAMING
STREAMING
Table 16: Post-conditions; HFP+A2DP/VDP+AVRCP Incoming call when listening to music FROM the same
device, no HQ ring signal
Figure 14: HFP+A2DP/VDP+AVRCP Incoming call when listening to music FROM the same device, no HQ ring
signal
18 November 2008 34
For the sub-scenarios halt streaming see 7.1 and for restore streaming see 7.2.
6.2.6 HFP+A2DP/VDP+AVRCP INCOMING CALL WHEN LISTENING TO MUSIC FROM A THIRD

DEVICE, NO HQ RING SIGNAL
This use case is applicable if the HF_RD:
is unable to support streaming and (e)SCO simultaneously, or
does not desire to support streaming and (e)SCO simultaneously.
Device
AG_MP
HF_RD
MP
Paired with
HF_RD
AG_MP, MP
HF_RD
HFP service level connection established

with
HF_RD
AG_MP
[HF_RD]
[AG_MP], MP
HF_RD
NA
MP
HF_RD
AVDTP State
NA
STREAMING
STREAMING
Table 17: Pre-conditions; HFP+A2DP/VDP+AVRCP Incoming call when listening to music from a third device, no
HQ ring signal
Note: [] means that the connection is optional.
The bullets below describe the use case scenario including the steps that the user takes to do the call
handling.
From HF_RD or AG_MP:
Streaming to HF_RD from 3rd device is active
A call comes in.
Streaming is paused from the HF_RD.
Possible call procedures listed in /1/ are performed (ringing, call accept, reject etc.).
When call is finished or rejected streaming from 3rd device should be continued.
Device
AG_MP
HF_RD
MP
Paired with
HF_RD
AG_MP, MP
HF_RD
HFP service level connection

established with
HF_RD
AG_MP
AVCTP Signaling Channel established

with
[HF_RD]
[AG_MP], MP
HF_RD
AVDTP Signaling Channel established

with
NA
MP
HF_RD
AVDTP State after call
NA
STREAMING
STREAMING
AVDTP State during call
NA
IDLE
IDLE
Table 18: Post-conditions; HFP+A2DP/VDP+AVRCP Incoming call when listening to music from a third device, no
HQ ring signal
18 November 2008 35

AG_MP
MP
HF_RD
HFP service level connection available

AVDTP in state STREAMING
AVCTP signaling link available
incoming call
or
call creation
CIEV(callsetup=1)
AVRCP pause
AVRCP pause response
RING(ALERT)
add (e)SCO
halt streaming
accept (e)SCO
GAVDP_Connection_Release()
call handling,
accept or rejected, do call and hangup
close (e)SCO
response can be before

or after release. Halt
streaming may occur or
not.
AVRCP play
AVRCP play response
metadata transfer
Figure 15: HFP+A2DP/VDP+AVRCP Incoming call when listening to music from a third device, no HQ ring
signal
6.2.7 HFP+A2DP/VDP+AVRCP OUTGOING CALL WHILE LISTENING TO MUSIC FROM A THIRD
DEVICE
This scenario is mostly the same as 6.2.6 except that incoming call is replaced by outgoing call.
See 6.2.6.1.
18 November 2008 36

The following bullets describe the use case scenario including the steps that the user takes to do the
call handling.
From HF_RD or AG_MP:
> Streaming to HF_RD from 3rd device is active
> A call is created on AG.
> Streaming is paused from the HF_RD.
> Possible call procedures listed in /1/ are performed (ringing, call accept, reject etc.).
> When call is finished or rejected streaming from 3rd device should be continued.
See 6.2.6.3
AG
HF_RD
MP
User creates call
AVDTP in state STREAMING,

AVCTP signalling link available
+CIEV:<callsetup>,2
AVRCP pause
request for (e)SCO
Subscenario: halt streaming
accept (e)SCO
+CIEV:<callsetup>,3
+CIEV:<call>,1
either device ends call
+CIEV:<callsetup>,0
response can be
before or after
release. Halt
streaming may
occure or not.
call ongoing
+CIEV:<call>,0
close (e)SCO
AVRCP play
AVRCP play response
metadata transfer
Figure 16: HFP+A2DP/VDP+AVRCP Outgoing call while listening to music from a third device (AG initiated)
18 November 2008 37
AG_MP
MP
HF_RD

AVCTP signaling link available
User creates call
AVRCP pause
CIEV can come before or

after halt streaming
procedure
halt streaming
ATD<digits>
OK
+CIEV:<callsetup>,2
Can come before or after

halt streaming and SCO
GAVDP_Connection_Release()
RING(ALERT)
request for (e)SCO
accept (e)SCO
+CIEV:<callsetup>,3
+CIEV:<call>,1
response can be before

or after release. Halt
streaming may occur or
not.
+CIEV:<callsetup>,0
call ongoing
+CIEV:<call>,0
close (e)SCO
AVRCP play
AVRCP play response
metadata transfer
Figure 17: HFP+A2DP/VDP+AVRCP Outgoing call while listening to music from a third device (HF_RD
initiated)
18 November 2008 38
6.2.8 HFP+A2DP/VDP+AVRCP OUTGOING CALL WHILE LISTENING TO MUSIC

An outgoing call is handled similarly to an incoming call, please see 6.2.5.
See 6.2.5.1.
The following bullet describe the steps that the user takes during an incoming call.
From HF_RD or AG_MP
During streaming a call is established by the user. The remote user accepts and later on ends the call
or rejects the call (Possible call procedures are listed in /1/ - ringing, call accept, reject etc.).
See 6.2.5.3.
AG_MP
HF_RD
HFP service level connection available,

User
creates
call
CIEV:<callsetup>,2

procedure
request for (e)SCO

accept (e)SCO
CIEV:<callsetup>,3
CIEV:<call>,1
CIEV:<callsetup>,0
CIEV:<call>,0
close (e)SCO
Subscenario: restore streaming
Figure 18: HFP+A2DP/VDP+AVRCP Outgoing call while listening to music (AG_MP initiated)
18 November 2008 39
AG_MP
HF_RD
HFP service level connection available,

ATD<digits>
OK
CIEV:<callsetup>,2
User
creates
call
procedure
request for (e)SCO

accept (e)SCO
CIEV:<callsetup>,3
CIEV:<call>,1
CIEV:<callsetup>,0
CIEV:<call>,0
close (e)SCO
Subscenario: restore streaming
Figure 19: HFP+A2DP/VDP+AVRCP Outgoing call while listening to music (HF_RD initiated)
6.2.9 HFP+A2DP/VDP+AVRCP CHANGE OF VOLUME
The pre-conditions are the same as stated in 6.1.9.1. In addition a HFP service level connection
between AG_MP and HF_RD has been established.
The user actions are the same as stated in 6.1.9.2.
The post-conditions are the same as stated in 6.1.9.3. In addition a HFP service level connection
between AG_MP and HF_RD has been established.
The recommendations are the same as stated in 6.1.9.4.
18 November 2008 40

The message sequence charts are the same as shown in 6.1.9.5.
18 November 2008 41
7 Message Sequence chart Sub-scenarios

In the following message sequence chart some procedures of the GAVDP specification are used. For the
specific content of the procedures, please see the GAVDP specification.
Note: The INT and ACP roles in MSC of sub-scenarios are not to be confused with the corresponding roles in
the underlying L2CAP layer.
7.1 HALT STREAMING
Figure 20: Sub-scenario halt streaming

Even if ACP supports SUSPEND, it shall be prepared that GAVDP_Connection_Release is used
since AVDTP_SUSPEND is not a mandatory command.
18 November 2008 42
7.2 RESTORE STREAMING
Figure 21: Sub-scenario restore streaming

If streaming was halted with GAVDP_Connection_Release it depends on the source implementation, how the
stream is continued (e.g. last position or next song or ...).
7.3 METADATA TRANSFER
Figure 22: Sub-scenario metadata transfer
18 November 2008 43
8 References
References
Item
Title
/1/
HFP specification 1.5 (HFP_1.5_SPEC_V10) from www.bluetooth.org
/2/
AVDTP specification 1.0 or later from www.bluetooth.org
/3/
A2DP specification 1.0 or later from www.bluetooth.org
/4/
AVCTP specification 1.0 or later from www.bluetooth.org
/5/
AVRCP specification 1.0 or later from www.bluetooth.org
/6/
VDP specification 1.0 or later from www.bluetooth.org
/7/
GAVDP specification 1.0 or later from www.bluetooth.org
18 November 2008 44
Appendix. List of Supported Recommendations

The following table may be used to communicate which recommendations from this White Paper are
supported in a certain product. It may for example voluntarily be attached to a Bluetooth device listing on
qualweb or be used in communications between companies.
The Support column may also be used to provide any additional useful information on the support of a certain
recommendation in a product in textual form.
Product Name:
[insert your product name here]
QD ID /QP ID
[insert ID here]
Support (y, n,
comment)
Role
Media Player
Rendering Device
Remote Controller
Audio Gateway with Media Player
Handsfree with Rendering Device Capabilities
Recomme
ndation
Title
Signaling channel establishment point of time
AVDTP before AVCTP
Sniff mode
Unsniff before AVDTP signaling
Sniff during Streaming
Signaling channel release point of time
AVCTP and AVDTP disconnection
No silence data pattern streaming
Re-connect after link loss
10
Start Playback
11
AVDTP reestablishment after AVRCP_PLAY
12
GAVDP_START responsibility
13
Media Player control over AVRCP
14
AVRCP_PAUSE relation to AVRCP_PLAY
15
Codec configuration for new track
16
No AVRCP volume command from RD
17
No sending back of AVRCP volume command
18
HFP, AVDTP and AVCTP connection order
Support (y, n,
comment)
18 November 2008 45
19
HF_RD should not open (e)SCO
20
HF_PRD should not generate ring signal
21
Incoming call from AG while streaming from separate MP
22
Stream handling before (e)SCO establishment
23
Stream restart by AG_MP
24
Restart streaming from MP after call from separate AG
25
Volume relationship AVRCP -> HFP
26
Volume relationship HFP -> AVRCP
27
SBC stream encoded volume level
28
AG_MP responsibility in call handling
29
AVDTP/AVCTP/HFP disconnect conditions
30
AVDTP/AVCTP connect without HFP
31
Coexistence AVRCP with local user action on MP
32
Identity AVRCP with local user action on MP
33
Restart streaming from MP after RD suspends
18 November 2008 46

Simultaneous Use of HFP A2DP and AVRCP - WP - V11 PDF

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Simultaneous Use of HFP A2DP and AVRCP - WP - V11 PDF

Transféré par

Droits d'auteur :

Formats disponibles

18 November 2008

This white paper recommends procedures for use of

SIMULTANEOUS USE OF HFP, A2DP, AND AVRCP PROFILES

Changed HQ ring tone issues. Added Metadata Transfer MSCs.

Changed/added Metadata Transfer MSCs.

Deleted HQ ring tone statements.

Typo error corrections and editorial changes

Ver 1.1 Rel 05

Reflects updates from AV WG F2F

Ver 1.1 Rel 06

Final edits before approval

Ver 1.1 Rel 07

29 Nov 2007 Reflects comments from UEG and BARB

Ver 1.1 Rel 08

Including feedback from AV WG members and BARB

Ver 1.1 Rel 09

Final version for Ver 1.1

Ver 1.1 Rel 10

01 July 2008 Updated based on UPF feedback and BARB comments

Ver 1.1 Rel 11

11 Aug 2008 Updated based on AV WG CC the 11th of August

Ver 1.1 Rel 12

02 Sep 2008 Updated based on BARB comments

SIMULTANEOUS USE OF HFP, A2DP, AND AVRCP PROFILES

DISCLAIMER AND COPYRIGHT NOTICE

SIMULTANEOUS USE OF HFP, A2DP, AND AVRCP PROFILES

4 CONFIGURATION AND ROLES ......................................................................................................... 10

SIMULTANEOUS USE OF HFP, A2DP, AND AVRCP PROFILES

6.1.6.4 RECOMMENDATION ............................................................................................. 23

SIMULTANEOUS USE OF HFP, A2DP, AND AVRCP PROFILES

6.2.8.4 RECOMMENDATION ............................................................................................. 39

SIMULTANEOUS USE OF HFP, A2DP, AND AVRCP PROFILES

1 Terms and Abbreviations

Advanced Audio Distribution Profile

Audio Gateway (as in HFP)

Audio Gateway and Media Player

Audio Video Distribution Transport Protocol

Audio Video Remote Control Profile

Generic Audio/Video Distribution Profile

HandsFree (as in HFP)

HandsFree and Rendering Device

Inband ring tone

Any audio using (e)SCO for ringing

Any audio using A2DP for ringing

Sink (as in A2DP/VDP)

Source (as in A2DP/VDP)

Video Distribution Profile

SIMULTANEOUS USE OF HFP, A2DP, AND AVRCP PROFILES

SIMULTANEOUS USE OF HFP, A2DP, AND AVRCP PROFILES

SIMULTANEOUS USE OF HFP, A2DP, AND AVRCP PROFILES

4 Configuration and Roles

SIMULTANEOUS USE OF HFP, A2DP, AND AVRCP PROFILES

4.3 REMOTE CONTROLLER (RC)

SIMULTANEOUS USE OF HFP, A2DP, AND AVRCP PROFILES

5 Recommendations and Motivations

SIMULTANEOUS USE OF HFP, A2DP, AND AVRCP PROFILES

SIMULTANEOUS USE OF HFP, A2DP, AND AVRCP PROFILES

SIMULTANEOUS USE OF HFP, A2DP, AND AVRCP PROFILES

SIMULTANEOUS USE OF HFP, A2DP, AND AVRCP PROFILES

SIMULTANEOUS USE OF HFP, A2DP, AND AVRCP PROFILES

SIMULTANEOUS USE OF HFP, A2DP, AND AVRCP PROFILES

AVCTP Signaling Channel established with

AVDTP Signaling Channel established with