draft-ietf-payload-rtp-sbc-05.txt   draft-ietf-payload-rtp-sbc-06.txt 
Working Group PAYLOAD C. Hoene Working Group PAYLOAD C. Hoene
Internet Draft Symonics GmbH Internet Draft Symonics GmbH
Intended status: Standards Track F. de Bont Intended status: Standards Track F. de Bont
Expires: January 2014 Philips Electronics Expires: February 2014 Philips Electronics
July 3, 2013 August 26, 2013
RTP Payload Format for Bluetooth's SBC Audio Codec RTP Payload Format for Bluetooth's SBC Audio Codec
draft-ietf-payload-rtp-sbc-05 draft-ietf-payload-rtp-sbc-06
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 32 skipping to change at page 1, line 32
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress." reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on July 3, 2013. This Internet-Draft will expire on February 26, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 22 skipping to change at page 2, line 22
Profile (A2DP) Specification written by the Bluetooth(r) Special Profile (A2DP) Specification written by the Bluetooth(r) Special
Interest Group (SIG). The payload format is designed to be able to Interest Group (SIG). The payload format is designed to be able to
interoperate with existing Bluetooth A2DP devices, to provide high interoperate with existing Bluetooth A2DP devices, to provide high
streaming audio quality, interactive audio transmission over the streaming audio quality, interactive audio transmission over the
internet, and ultra-low delay coding for jam sessions on the internet, and ultra-low delay coding for jam sessions on the
internet. This document contains also a media type registration internet. This document contains also a media type registration
which specifies the use of the RTP payload format. which specifies the use of the RTP payload format.
Table of Contents Table of Contents
1. Introduction .................................................. 3 1. Introduction...................................................3
2. Conventions used in this Document ............................. 3 2. Conventions used in this Document..............................3
3. Background .................................................... 3 3. Background.....................................................3
3.1. SBC Frame Structure ...................................... 5 3.1. SBC Frame Structure.......................................5
3.2. Frame Header ............................................. 5 3.2. Frame Header..............................................5
3.3. Remaining Frame Part .................................... 8 3.3. Remaining Frame Part......................................8
4. Usage Scenarios ............................................... 8 4. Usage Scenarios................................................8
4.1. Scenario 1: Interconnection of A2DP Devices .............. 8 4.1. Scenario 1: Interconnection of A2DP Devices...............8
4.2. Scenario 2: High Quality Interactive Audio Transmissions . 9 4.2. Scenario 2: High Quality Interactive Audio Transmissions..9
4.3. Scenario 3: Ensembles performing over a Network .......... 9 4.3. Scenario 3: Ensembles performing over a Network...........9
5. Header Usage ................................................. 10 5. Header Usage..................................................10
6. Payload Format ............................................... 11 6. Payload Format................................................11
7. Payload Format Parameters .................................... 11 7. Payload Format Parameters.....................................11
7.1. Media Type Registration for SBC ......................... 11 7.1. Media Type Registration for SBC..........................11
7.1.1. Capabilities: A2DP Modes ........................... 13 7.1.1. Capabilities: A2DP Modes............................13
7.1.2. Capabilities: Other Modes .......................... 14 7.1.2. Capabilities: Other Modes...........................14
7.2. Mapping to SDP Parameters ............................... 14 7.2. Mapping to SDP Parameters................................14
7.2.1. Offer-Answer Model Considerations .................. 15 7.2.1. Offer-Answer Model Considerations...................15
7.2.2. Declarative SDP Considerations ..................... 17 7.2.2. Declarative SDP Considerations......................17
8. Congestion Control ........................................... 17 8. Congestion Control............................................17
9. Packet Loss Concealment ...................................... 18 9. Packet Loss Concealment.......................................18
10. Security Considerations ..................................... 18 10. Security Considerations......................................18
11. IANA Considerations ......................................... 19 11. IANA Considerations..........................................19
12. References .................................................. 20 12. References...................................................20
12.1. Normative References ................................... 20 12.1. Normative References....................................20
12.2. Informative References ................................. 20 12.2. Informative References..................................20
13. Acknowledgments ............................................. 22 13. Acknowledgments..............................................22
1. Introduction 1. Introduction
The Bluetooth(r) Special Interest Group (SIG) specifies in the The Bluetooth(r) Special Interest Group (SIG) specifies in the
Advanced Audio Distribution Profile (A2DP) [A2DPV12] a mono and Advanced Audio Distribution Profile (A2DP) [A2DPV12] a mono and
stereo high quality audio subband codec (SBC). This document stereo high quality audio subband codec (SBC). This document
specifies the payload format for the encapsulation of SBC encoded specifies the payload format for the encapsulation of SBC encoded
audio frames into the Real-time Transport Protocol (RTP). audio frames into the Real-time Transport Protocol (RTP).
SBC has a low computational complexity at modest compression rates. SBC has a low computational complexity at modest compression rates.
skipping to change at page 3, line 28 skipping to change at page 3, line 28
acoustic delays. acoustic delays.
2. Conventions used in this Document 2. Conventions used in this Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [RFC2119]. document are to be interpreted as described in RFC-2119 [RFC2119].
The following acronyms are used in this document: The following acronyms are used in this document:
A2DP - Audio Distribution Profile A2DP - Audio Distribution Profile
AAC - Advanced Audio Coding AAC - Advanced Audio Coding
ATRAC - Adaptive Transform Acoustic Coding ATRAC - Adaptive Transform Acoustic Coding
DCCP - Datagram Congestion Control Protocol DCCP - Datagram Congestion Control Protocol
MP3 - MPEG-1 Audio Layer 3 MP3 - MPEG-1 Audio Layer 3
SBC - SubBand Codec RFA - Reserved for Future Additions
SIG - Special Interest Group SBC - SubBand Codec
SIG - Special Interest Group
3. Background 3. Background
The A2DP specification [A2DPV12] is intended for streaming of music The A2DP specification [A2DPV12] is intended for streaming of music
content to headphones, headsets, or speakers over Bluetooth wireless content to headphones, headsets, or speakers over Bluetooth wireless
channels. A2DP supports multiple audio coding including MP3, AAC, channels. A2DP supports multiple audio coding including MP3, AAC,
ATRAC, which are all non-mandatory. To ensure interoperability, the ATRAC, which are all non-mandatory. To ensure interoperability, the
SBC codec has been specified, in appendix B of the A2DP SBC codec has been specified, in appendix B of the A2DP
specification, which shall be included into all A2DP Bluetooth specification, which shall be included into all A2DP Bluetooth
devices. devices.
skipping to change at page 6, line 6 skipping to change at page 6, line 6
3.2. Frame Header 3.2. Frame Header
The frame header consists of fields defined in [A2DPV12], which are The frame header consists of fields defined in [A2DPV12], which are
SYNCWORD, SAMPLING_FREQUENCY, BLOCKS, CHANNEL_MODE, SYNCWORD, SAMPLING_FREQUENCY, BLOCKS, CHANNEL_MODE,
ALLOCATION_METHOD, SUBBANDS, BITPOOL, CRC_CHECK, optionally JOIN bit ALLOCATION_METHOD, SUBBANDS, BITPOOL, CRC_CHECK, optionally JOIN bit
fields and a RFA. The layout of the first four bytes of the frame fields and a RFA. The layout of the first four bytes of the frame
header is given in the following table. header is given in the following table.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SYNCWORD |SF.|BL.|CM.|A|S|BITPOOL |CRC_CHECK | | SYNCWORD |SF.|BL.|CM.|A|S|BITPOOL |CRC_CHECK |JOIN |R|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Legend: SF.=SAMPLING FREQUENCY, BL.=BLOCKS, CM.=CHANNEL_MODE, Legend: SF.=SAMPLING FREQUENCY, BL.=BLOCKS, CM.=CHANNEL_MODE,
A.=ALLOCATION_METHOD, S.=SUBBANDS A.=ALLOCATION_METHOD, S.=SUBBANDS, R.=RFA
SYNCWORD (8 bits): The first field is the 8 bit synchronization SYNCWORD (8 bits): The first field is the 8 bit synchronization
word, which is always set to 156. word, which is always set to 156.
SAMPLING_FREQUENCY (2 bits): The sampling frequency field indicates SAMPLING_FREQUENCY (2 bits): The sampling frequency field indicates
with which sampling frequency the SBC frame has been with which sampling frequency the SBC frame has been
encoded. The table below specifies the corresponding encoded. The table below specifies the corresponding
sampling frequencies for the bit patterns. The sampling sampling frequencies for the bit patterns. The sampling
frequency MUST NOT be changed without changing the payload frequency MUST NOT be changed without changing the payload
type, too. type, too.
skipping to change at page 8, line 25 skipping to change at page 8, line 25
current block. The value of the bit-pool field MUST NOT current block. The value of the bit-pool field MUST NOT
exceed 16 times the number of subbands for the MONO and exceed 16 times the number of subbands for the MONO and
DUAL_CHANNEL channel modes and 32 times the number of DUAL_CHANNEL channel modes and 32 times the number of
subbands for the STEREO and JOINT_STEREO channel modes. subbands for the STEREO and JOINT_STEREO channel modes.
The bitpool value MAY change from SBC frame to the next. The bitpool value MAY change from SBC frame to the next.
In addition, the bitpool value MUST be restricted such In addition, the bitpool value MUST be restricted such
that it does not result in excess of maximum bit rate, that it does not result in excess of maximum bit rate,
which is 320kb/s for mono and 512kb/s for two-channel which is 320kb/s for mono and 512kb/s for two-channel
modes. modes.
The remaining part of the header consists of CRC_CHECK, optionally The remaining part of the header consists of CRC_CHECK, optionally
JOIN bit fields and a RFA. JOIN bit fields, to indicate in which subbands joint stereo has been
used, and a RFA bit.
3.3. Remaining Frame Part 3.3. Remaining Frame Part
The remaining part of the frame includes scale factors and audio The remaining part of the frame includes scale factors and audio
sample data, which are processed by the codec as described in sample data, which are processed by the codec as described in
[A2DPV12]. [A2DPV12].
4. Usage Scenarios 4. Usage Scenarios
As compared to many other encoding schemes, the SBC codec is general As compared to many other encoding schemes, the SBC codec is general
skipping to change at page 11, line 45 skipping to change at page 11, line 45
the Session Description Protocol (SDP) [RFC4566] is also provided the Session Description Protocol (SDP) [RFC4566] is also provided
for those applications that use SDP. In control protocols that do for those applications that use SDP. In control protocols that do
not use MIME or SDP, the media type parameters must be mapped to the not use MIME or SDP, the media type parameters must be mapped to the
appropriate format used with that control protocol. appropriate format used with that control protocol.
7.1. Media Type Registration for SBC 7.1. Media Type Registration for SBC
[Note to RFC Editor: Please replace all occurrences of RFC XXXX by [Note to RFC Editor: Please replace all occurrences of RFC XXXX by
the RFC number assigned to this document] the RFC number assigned to this document]
This registration is done using the template defined in [RFC4288] This registration is done using the template defined in [RFC6838]
and following [RFC4855]. and following [RFC4855].
Media type name: audio Media type name: audio
Subtype name: SBC Subtype name: SBC
Required parameters: Required parameters:
Rate: The RTP timestamp clock rate. See Section 5 for usage Rate: The RTP timestamp clock rate. See Section 5 for usage
details. details.
skipping to change at page 12, line 24 skipping to change at page 12, line 24
used, this parameter can be omitted. used, this parameter can be omitted.
Capabilities: The capabilities of the encoder and decoder are Capabilities: The capabilities of the encoder and decoder are
described by a parameter string that MUST start with an described by a parameter string that MUST start with an
octet written as two hexadecimal digits. This octet is octet written as two hexadecimal digits. This octet is
called VERSION and MUST be identical to the SYNCWORD called VERSION and MUST be identical to the SYNCWORD
that will be used in the SBC frames. It is used to that will be used in the SBC frames. It is used to
distinguish different negotiation procedures. distinguish different negotiation procedures.
The interpretation of the following characters depends The interpretation of the following characters depends
on the value of the VERSION octet. Refer to Section on the value of the VERSION octet. Refer to Section
7.1.1. and Section 7.1.2. to find a description. 7.1.1. and Section 7.1.2. to find a description. The
default value of this parameter is "9C,27,FF,02,FA".
Encoding considerations: This media type is framed and contains Encoding considerations: This media type is framed and contains
binary data; see Section 4.8 of RFC 4288. binary data; see Section 4.8 of RFC 6838.
Security considerations: See Section 9 of RFC XXXX Security considerations: See Section 9 of RFC XXXX
Interoperability considerations: none Interoperability considerations: none
Published specification: RFC XXXX Published specification: RFC XXXX
Applications which use this media type: Audio and video conferencing Applications which use this media type: Audio and video conferencing
tools, distributed orchestras tools, distributed orchestras
skipping to change at page 13, line 21 skipping to change at page 13, line 21
separated hexadecimal octets. These four octets called Octet 1, 2, separated hexadecimal octets. These four octets called Octet 1, 2,
3, and 4 share a similar meaning as those defined in Section 4.3.2 3, and 4 share a similar meaning as those defined in Section 4.3.2
of [A2DPV12]. However, because sampling frequency and number of of [A2DPV12]. However, because sampling frequency and number of
channels are already given in the SDP parameter "a=rtpmap", bit 0 up channels are already given in the SDP parameter "a=rtpmap", bit 0 up
to and including bit 3 of Octet 1 MUST BE ignored if received. The to and including bit 3 of Octet 1 MUST BE ignored if received. The
meaning of the bits and the octets are described in the following meaning of the bits and the octets are described in the following
enumeration. The bit numbering follows the network bit order having enumeration. The bit numbering follows the network bit order having
the highest bit first. the highest bit first.
o Octet 1: Bit 0 (aka 2^7): If one, then the sampling frequency o Octet 1: Bit 0 (aka 2^7): If one, then the sampling frequency
16000 Hz is supported (ignored during SDP negotiations but SHOULD 16000 Hz is supported (ignored during SDP negotiations but SHOULD
be set if the clock rate is 16000 and MUST be cleared otherwise). be set if the clock rate is 16000 and MUST be cleared otherwise).
o Octet 1: Bit 1: If one, then the sampling frequency 32000 Hz is o Octet 1: Bit 1: If one, then the sampling frequency 32000 Hz is
supported (ignored during SDP negotiations but SHOULD be set if supported (ignored during SDP negotiations but SHOULD be set if
the clock rate is 32000 and MUST be cleared otherwise). the clock rate is 32000 and MUST be cleared otherwise).
o Octet 1: Bit 2: If one, then the sampling frequency 44100 Hz is o Octet 1: Bit 2: If one, then the sampling frequency 44100 Hz is
supported (ignored during SDP negotiations but SHOULD be set if supported (ignored during SDP negotiations but SHOULD be set if
the clock rate is 44100 and MUST be cleared otherwise). the clock rate is 44100 and MUST be cleared otherwise).
o Octet 1: Bit 3: If one, then the sampling frequency 48000 Hz is o Octet 1: Bit 3: If one, then the sampling frequency 48000 Hz is
supported (ignored during SDP negotiations but SHOULD be set if supported (ignored during SDP negotiations but SHOULD be set if
the clock rate is 48000 and MUST be cleared otherwise). the clock rate is 48000 and MUST be cleared otherwise).
o Octet 1: Bit 4: If one, then the channel mode MONO is supported o Octet 1: Bit 4: If one, then the channel mode MONO is supported
(ignored during SDP negotiations but SHOULD be set if the number (ignored during SDP negotiations but SHOULD be set if the number
of channels is one and MUST be cleared otherwise). of channels is one and MUST be cleared otherwise).
o Octet 1: Bit 5: If one, then the channel mode DUAL_CHANNEL is o Octet 1: Bit 5: If one, then the channel mode DUAL_CHANNEL is
supported (*). supported (*).
o Octet 1: Bit 6: If one, then the channel mode STEREO is supported o Octet 1: Bit 6: If one, then the channel mode STEREO is supported
(*). (*).
o Octet 1: Bit 7 (aka 2^0): If one, then the channel mode o Octet 1: Bit 7 (aka 2^0): If one, then the channel mode
JOINT_STEREO is supported (*). JOINT_STEREO is supported (*).
o Octet 2: Bit 0: If one, the block length can be 4. o Octet 2: Bit 0: If one, the block length can be 4.
o Octet 2: Bit 1: If one, the block length can be 8. o Octet 2: Bit 1: If one, the block length can be 8.
o Octet 2: Bit 2: If one, the block length can be 12. o Octet 2: Bit 2: If one, the block length can be 12.
o Octet 2: Bit 3: If one, the block length can be 16. o Octet 2: Bit 3: If one, the block length can be 16.
o Octet 2: Bit 4: If one, the number of subband can be 4. o Octet 2: Bit 4: If one, the number of subband can be 4.
o Octet 2: Bit 5: If one, the number of subband can be 8. o Octet 2: Bit 5: If one, the number of subband can be 8.
o Octet 2: Bit 6: If one, the allocation mode based on signal to o Octet 2: Bit 6: If one, the allocation mode based on signal to
noise ratio is supported. noise ratio is supported.
o Octet 2: Bit 7: If one, the allocation mode based on loudness is o Octet 2: Bit 7: If one, the allocation mode based on loudness is
supported. supported.
o Octet 3: Unsigned integer: The minimal bit-pool value that the o Octet 3: Unsigned integer: The minimal bit-pool value that the
device supports. MUST be larger or equal than 2 and less or equal device supports. MUST be larger or equal than 2 and less or equal
than the maximal bit-pool value. than the maximal bit-pool value.
o Octet 4: Unsigned integer: The maximal bit-pool value that the o Octet 4: Unsigned integer: The maximal bit-pool value that the
device supports MUST be equal or lower than 250. device supports MUST be equal or lower than 250.
(*) At least one of the bits 5, 6 or 7 of Octet 1 MUST be set if the (*) At least one of the bits 5, 6 or 7 of Octet 1 MUST be set if the
number of channels is set to two in the SDP parameter "a=rtpmap". number of channels is set to two in the SDP parameter "a=rtpmap".
7.1.2. Capabilities: Other Modes 7.1.2. Capabilities: Other Modes
If the value of the VERSION octet is not equal to a known SYNCWORD If the value of the VERSION octet is not equal to a known SYNCWORD
value, then the capabilities MUST be ignored. value, then the capabilities MUST be ignored.
7.2. Mapping to SDP Parameters 7.2. Mapping to SDP Parameters
The information carried in the media type specification has a The information carried in the media type specification has a
specific mapping to fields in the Session Description Protocol (SDP) specific mapping to fields in the Session Description Protocol (SDP)
[RFC4566], which is commonly used to describe RTP sessions. When SDP [RFC4566], which is commonly used to describe RTP sessions. When SDP
is used to specify sessions employing the SBC codec, the mapping is is used to specify sessions employing the SBC codec, the mapping is
as follows: as follows:
o The media type ("audio") goes in SDP "m=" as the media name. o The media type ("audio") goes in SDP "m=" as the media name.
o The media subtype ("SBC") goes in SDP "a=rtpmap" as the encoding o The media subtype ("SBC") goes in SDP "a=rtpmap" as the encoding
name. name.
o The required parameter "rate" goes in SDP "a=rtpmap" as the RTP o The required parameter "rate" goes in SDP "a=rtpmap" as the RTP
<clock rate>. <clock rate>.
o The optional parameter "channels", if present, goes in SDP as the o The optional parameter "channels", if present, goes in SDP as the
"a=rtpmap" RTP <encoding parameters>. "a=rtpmap" RTP <encoding parameters>.
o The optional parameter "capabilities", if present, goes in the SDP o The optional parameter "capabilities", if present, goes in the SDP
"a=fmtp" by the capabilities description as described in Section "a=fmtp" by the capabilities description as described in Section
7.1. 7.1.
7.2.1. Offer-Answer Model Considerations 7.2.1. Offer-Answer Model Considerations
The Bluetooth standard document [AVDTPV12] describes how an A2DP The Bluetooth standard document [AVDTPV12] describes how an A2DP
source and an A2DP sink negotiate their capabilities. Prior to the source and an A2DP sink negotiate their capabilities. Prior to the
establishment of the audio stream, one A2DP device can query the establishment of the audio stream, one A2DP device can query the
service capabilities of the other device using the "Get Capabilities service capabilities of the other device using the "Get Capabilities
Procedure". In any case, the coding mode is set using the "Set Procedure". In any case, the coding mode is set using the "Set
Configuration" procedure. Only after a successful configuration, the Configuration" procedure. Only after a successful configuration, the
stream connection can be established. stream connection can be established.
In addition to the Bluetooth negotiation procedure, the SDP In addition to the Bluetooth negotiation procedure, the SDP
negotiation MUST NOT agree on one single configuration but CAN agree negotiation MUST NOT agree on one single configuration but CAN agree
that multiple configuration modes, which are identified by different that multiple configuration modes, which are identified by different
payload type values, are supported. payload type values, are supported.
The following considerations apply when using SDP offer-answer The following considerations apply when using SDP offer-answer
procedures [RFC3264] to negotiate the use of SBC payload in RTP: procedures [RFC3264] to negotiate the use of SBC payload in RTP:
o The "capabilities" parameter is bi-directional, i.e., the o The "capabilities" parameter is symmetric, i.e., the restricted
restricted mode set applies to media both to be received and sent mode set applies to media both to be received and sent by the
by the declaring entity. If the capabilities were supplied in the declaring entity. If the capabilities were supplied in the offer,
offer, the answerer MUST return either the same mode-set or a the answerer MUST return either the same mode-set or a subset of
subset of this mode-set. If no capabilities were supplied in the this mode-set. If no capabilities were supplied in the offer, the
offer, the answerer MAY return capabilities to restrict the answerer MAY return capabilities to restrict the possible modes.
possible modes. In any case, the capabilities in the answer then In any case, the capabilities in the answer then apply for both
apply for both offerer and answerer. The offerer MUST NOT send offerer and answerer. The offerer MUST NOT send frames of a mode
frames of a mode that has been removed by the answerer. The that has been removed by the answerer. The negotiation is finished
negotiation is finished if the offerer and the answerer have if the offerer and the answerer have agreed upon explicit
agreed upon explicit capabilities for each payload type number. capabilities for each payload type number. The number of blocks
The number of blocks and subbands and the kind of allocation and subbands and the kind of allocation method and channel mode
method and channel mode MUST have been negotiated unambiguously. MUST have been negotiated unambiguously.
o Any unknown parameter in an offer MUST be ignored by the receiver o Any unknown parameter in an offer MUST be ignored by the receiver
and MUST NOT be included in the answer. and MUST NOT be included in the answer.
Below are some example parts of SDP offer-answer exchanges. Below are some example parts of SDP offer-answer exchanges.
o Example 1 o Example 1
Offer: SBC all A2DP modes Offer: SBC all A2DP modes
m=audio 54874 RTP/AVP 96 m=audio 54874 RTP/AVP 96
a=rtpmap:96 SBC/48000/2 a=rtpmap:96 SBC/48000/2
a=fmtp:96 capabilities=9C,17,FF,02,FA a=fmtp:96 capabilities=9C,17,FF,02,FA
m=audio 54874 RTP/AVP 97 m=audio 54874 RTP/AVP 97
a=rtpmap:97 SBC/48000 a=rtpmap:97 SBC/48000
a=fmtp:97 capabilities=9C,18,FF,02,FA a=fmtp:97 capabilities=9C,18,FF,02,FA
m=audio 54874 RTP/AVP 98 m=audio 54874 RTP/AVP 98
a=rtpmap:98 SBC/44100/2 a=rtpmap:98 SBC/44100/2
a=fmtp:98 capabilities=9C,27,FF,02,FA a=fmtp:98 capabilities=9C,27,FF,02,FA
m=audio 54874 RTP/AVP 99 m=audio 54874 RTP/AVP 99
a=rtpmap:99 SBC/44100 a=rtpmap:99 SBC/44100
a=fmtp:99 capabilities=9C,28,FF,02,FA a=fmtp:99 capabilities=9C,28,FF,02,FA
m=audio 54874 RTP/AVP 100 m=audio 54874 RTP/AVP 100
a=rtpmap:100 SBC/32000/2 a=rtpmap:100 SBC/32000/2
a=fmtp:101 capabilities=9C,47,FF,02,FA a=fmtp:101 capabilities=9C,47,FF,02,FA
m=audio 54874 RTP/AVP 102 m=audio 54874 RTP/AVP 102
a=rtpmap:102 SBC/32000 a=rtpmap:102 SBC/32000
a=fmtp:102 capabilities=9C,48,FF,02,FA a=fmtp:102 capabilities=9C,48,FF,02,FA
m=audio 54874 RTP/AVP 103 m=audio 54874 RTP/AVP 103
a=rtpmap:103 SBC/16000/2 a=rtpmap:103 SBC/16000/2
a=fmtp:103 capabilities=9C,87,FF,02,FA a=fmtp:103 capabilities=9C,87,FF,02,FA
m=audio 54874 RTP/AVP 104 m=audio 54874 RTP/AVP 104
a=rtpmap:104 SBC/48000 a=rtpmap:104 SBC/48000
a=fmtp:104 capabilities=9C,88,FF,02,FA a=fmtp:104 capabilities=9C,88,FF,02,FA
Answer: 48 kHz, JOINT_STEREO, 16 blocks, 8 subbands, LOUDNESS Answer: 48 kHz, JOINT_STEREO, 16 blocks, 8 subbands, LOUDNESS
m=audio 59452 RTP/AVP 96 m=audio 59452 RTP/AVP 96
a=rtpmap:96 SBC/48000/2 a=rtpmap:96 SBC/48000/2
a=fmtp:96 capabilities=9C,11,15,02,FA a=fmtp:96 capabilities=9C,11,15,02,FA
o Example 2 o Example 2
Offer: The A2DP SBC 48 kHz modes with mono or joint stereo, 8 Offer: The A2DP SBC 48 kHz modes with mono or joint stereo, 8
subbands, loudness allocation method. In addition an unknown mode subbands, loudness allocation method. In addition an unknown mode
called AD is offered. called AD is offered.
m=audio 54874 RTP/AVP 96 m=audio 54874 RTP/AVP 96
a=rtpmap:96 SBC/48000/2 a=rtpmap:96 SBC/48000/2
a=fmtp:96 capabilities=9C,11,F5,02,FA a=fmtp:96 capabilities=9C,11,F5,02,FA
m=audio 54874 RTP/AVP 97 m=audio 54874 RTP/AVP 97
a=rtpmap:97 SBC/48000/1 a=rtpmap:97 SBC/48000/1
a=fmtp:97 capabilities=9C, 18,F5,02,FA a=fmtp:97 capabilities=9C, 18,F5,02,FA
m=audio 54874 RTP/AVP 98 m=audio 54874 RTP/AVP 98
a=rtpmap:98 SBC/16000/1 a=rtpmap:98 SBC/16000/1
a=fmtp:98 capabilities=AD a=fmtp:98 capabilities=AD
Answer: both A2DP modes are accepted but the unknown mode AD is Answer: both A2DP modes are accepted but the unknown mode AD is
ignored. ignored.
m=audio 59452 RTP/AVP 96 m=audio 59452 RTP/AVP 96
a=rtpmap:96 SBC/48000/2 a=rtpmap:96 SBC/48000/2
a=fmtp:96 capabilities=9C,11,F5,02,FA a=fmtp:96 capabilities=9C,11,F5,02,FA
m=audio 59452 RTP/AVP 9 m=audio 59452 RTP/AVP 9
a=rtpmap:97 SBC/48000/1 a=rtpmap:97 SBC/48000/1
a=fmtp:97 capabilities=9C,18,F5,02,FA a=fmtp:97 capabilities=9C,18,F5,02,FA
7.2.2. Declarative SDP Considerations 7.2.2. Declarative SDP Considerations
For declarative use of SDP nothing specific is defined for this For declarative use of SDP nothing specific is defined for this
payload format. The configuration given by the SDP MUST be used when payload format. The configuration given by the SDP MUST be used when
sending and/or receiving media in the session. sending and/or receiving media in the session.
8. Congestion Control 8. Congestion Control
One Bluetooth links, bandwidth can be reserved and thus the A2DP One Bluetooth links, bandwidth can be reserved and thus the A2DP
skipping to change at page 20, line 11 skipping to change at page 20, line 11
It is requested that one new media subtype (audio/SBC) and one It is requested that one new media subtype (audio/SBC) and one
optional parameter for this media subtype ("capabilities") are optional parameter for this media subtype ("capabilities") are
registered by IANA, see Section 7.1 and Section 7.2. registered by IANA, see Section 7.1 and Section 7.2.
12. References 12. References
12.1. Normative References 12.1. Normative References
[A2DPV12] Bluetooth SIG, "Advanced Audio Distribution Profile", [A2DPV12] Bluetooth SIG, "Advanced Audio Distribution Profile",
Audio Video WG, adopted specification, revision V1.2, Audio Video WG, adopted specification, revision V1.2,
April 16th, 2007. April 16th, 2007,
<https://www.bluetooth.org/docman/handlers/DownloadDoc.ash
x?doc_id=66605>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3264] Rosenberg, J. and Schulzrinne, H., "An Offer/Answer [RFC3264] Rosenberg, J. and Schulzrinne, H., "An Offer/Answer
Modelwith Session Description Protocol (SDP)", RFC 3264, Modelwith Session Description Protocol (SDP)", RFC 3264,
June 2002. June 2002.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003. Applications", STD 64, RFC 3550, July 2003.
[RFC3551] Schulzrinne, H. and Casner, S., "RTP Profile for Audio and [RFC3551] Schulzrinne, H. and Casner, S., "RTP Profile for Audio and
Video Conferences with Minimal Control", STD 65, RFC 3551, Video Conferences with Minimal Control", STD 65, RFC 3551,
July 2003. July 2003.
[RFC4288] Freed, N. and Klensin, J., "Media Type Specifications and [RFC4566] Handley, M., Jacobson, V., and Perkins, C., "SDP: Session
Registration Procedures", BCP 13, RFC 4288, December 2005.
[RFC4566] Handley, M., Jacobson, V., and Perkins, C., "SDP: Session
Description Protocol", RFC 4566, July 2006. Description Protocol", RFC 4566, July 2006.
[RFC4855] Casner, S., "Media Type Registration of RTP Payload [RFC4855] Casner, S., "Media Type Registration of RTP Payload
Formats", RFC 4855, February 2007. Formats", RFC 4855, February 2007.
[RFC6838] Freed, N., Klensin, J.and Hansen, T., "Media Type
Specifications and Registration Procedures", BCP 13, RFC
6838, January 2013.
12.2. Informative References 12.2. Informative References
[AVDTPV12] Bluetooth SIG, "Audio/Video Distribution Transport [AVDTPV12] Bluetooth SIG, "Audio/Video Distribution Transport
Protocol Specification", Audio Video WG, adopted Protocol Specification", Audio Video WG, adopted
specification, revision V12, April 16th, 2007. specification, revision V12, April 16th, 2007.
[Bon1995] de Bont, F., Groenewegen, M., and Oomen, W., "A High [Bon1995] de Bont, F., Groenewegen, M., and Oomen, W., "A High
Quality Audio-Coding System at 128 kb/s", 98th AES Quality Audio-Coding System at 128 kb/s", 98th AES
Convention, February 25 - 28, 1995. Convention, February 25 - 28, 1995.
 End of changes. 39 change blocks. 
135 lines changed or deleted 142 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/