draft-ietf-payload-rtp-sbc-02.txt   draft-ietf-payload-rtp-sbc-03.txt 
Working Group PAYLOAD C. Hoene Working Group PAYLOAD C. Hoene
Internet Draft University of Tuebingen Internet Draft Symonics GmbH
Intended status: Standards Track F. de Bont Intended status: Standards Track F. de Bont
Expires: July 2012 Philips Electronics Expires: January 2013 Philips Electronics
January 4, 2012 July 8, 2012
RTP Payload Format for Bluetooth's SBC Audio Codec RTP Payload Format for Bluetooth's SBC Audio Codec
draft-ietf-payload-rtp-sbc-02 draft-ietf-payload-rtp-sbc-03
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 4, 2012. This Internet-Draft will expire on January 8, 2009.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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 Media Payload Format ................................ 5 3.1. SBC Media Payload Format ............................... 5
3.2. SBC Fragmentation ....................................... 5 3.2. SBC Fragmentation ...................................... 5
3.3. Media Payload Format Header ............................. 6 3.3. Media Payload Format Header ............................ 5
3.4. SBC Frame Structure ..................................... 7 3.4. SBC Frame Structure .................................... 5
3.5. Frame Header ............................................ 7 3.5. Frame Header ........................................... 5
3.6. Remaining Frame Part .................................... 9 3.6. Remaining Frame Part ................................... 8
4. Usage Scenarios .............................................. 9 4. Usage Scenarios ............................................. 8
4.1. Scenario 1: Interconnection of A2DP Devices ............ 10 4.1. Scenario 1: Interconnection of A2DP Devices ............ 8
4.2. Scenario 2: High Quality Interactive Audio Transmissions 10 4.2. Scenario 2: High Quality Interactive Audio Transmissions 9
4.3. Scenario 3: Ensembles performing over a Network ........ 11 4.3. Scenario 3: Ensembles performing over a Network ........ 9
5. Header Usage ................................................ 11 5. Header Usage ............................................... 10
6. Payload Format .............................................. 12 6. Payload Format ............................................. 11
7. Payload Format Parameters ................................... 12 7. Payload Format Parameters .................................. 11
7.1. Media Type Registration for SBC ........................ 13 7.1. Media Type Registration for SBC ....................... 11
7.1.1. Capabilities: A2DP Modes .......................... 14 7.1.1. Capabilities: A2DP Modes ......................... 13
7.1.2. Capabilities: Other Modes ......................... 15 7.1.2. Capabilities: Other Modes ........................ 14
7.2. Mapping to SDP Parameters .............................. 15 7.2. Mapping to SDP Parameters ............................. 14
7.2.1. Offer-Answer Model Considerations ................. 16 7.2.1. Offer-Answer Model Considerations ................ 15
7.2.2. Declarative SDP Considerations .................... 18 7.2.2. Declarative SDP Considerations ................... 17
8. Congestion Control .......................................... 18 8. Congestion Control ......................................... 17
9. Packet Loss Concealment ..................................... 19 9. Packet Loss Concealment .................................... 18
10. Security Considerations .................................... 19 10. Security Considerations ................................... 18
11. IANA Considerations......................................... 20 11. IANA Considerations........................................ 19
12. References ................................................. 21 12. References ................................................ 20
12.1. Normative References .................................. 21 12.1. Normative References ................................. 20
12.2. Informative References ................................ 21 12.2. Informative References ............................... 20
13. Acknowledgments ............................................ 23 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 5, line 28 skipping to change at page 5, line 28
| Bitpool value | 31 | 29 | 53 | 51 | | Bitpool value | 31 | 29 | 53 | 51 |
| Resulting frame length (bytes) | 70 | 66 | 119 | 115 | | Resulting frame length (bytes) | 70 | 66 | 119 | 115 |
| Resulting bit rate (kb/s) | 193 | 198 | 328 | 345 | | Resulting bit rate (kb/s) | 193 | 198 | 328 | 345 |
+--------------------------------+------+------+------+------+ +--------------------------------+------+------+------+------+
+ Other settings: Block length = 16, loudness, subbands = 8 | + Other settings: Block length = 16, loudness, subbands = 8 |
+------------------------------------------------------------+ +------------------------------------------------------------+
Table 1: Recommended sets of SBC parameters in the SRC device as Table 1: Recommended sets of SBC parameters in the SRC device as
given in [A2DPV12] given in [A2DPV12]
3.1. SBC Media Payload Format 3.1. SBC Frame Structure
The A2DP V1.2 specification describes a media payload format, which
is adopted in this document one-to-one without any change. In the
following, for the sake of clarity, the payload format definition is
repeated in the following.
3.2. SBC Fragmentation
The payload MUST consist of one media payload format header
described in Section 3.3 and SBC frames described in Section 3.4.
Either an integral number of SBC frames or one fragment of an SBC
frame can be transmitted:
(a) When the payload contains an integral number of SBC frames
+--------+-----------+----------- -+
| Header | SBC frame | SBC frame ... |
+--------+-----------+----------- -+
(b) When the SBC frame is fragmented
+--------+---------------------------------------+
| Header | First fragment of SBC frame |
+--------+---------------------------------------+
+--------+---------------------------------------+
| Header | Subsequent fragments of the SBC frame |
+--------+---------------------------------------+
A media payload always starts with an 8-bit header, which is placed
before the SBC data.
An SBC frame can be fragmented across several media payloads. All
fragmented packets, except the last one, MUST have the same total
data packet size.
This payload fragmentation CAN be preferred against the
fragmentation mechanisms of lower layers (e.g., IP) because the
packetisation delay and thus the acoustic latency are reduced and
the error robustness is increased because parts of the SBC frame can
be considered for decoding.
3.3. Media Payload Format Header
The following figure shows the format of media payload header, which
consists of one byte.
0 1 2 3 4 5 6 7
+-+-+-+---+-+-+-+-+
|F|S|L|RFA|#frames|
+-+-+-+---+-+-+-+-+
F bit - Set to 1 if the SBC frame is fragmented, otherwise set to 0.
S bit - Set to 1 for the starting packet of a fragmented SBC frame,
otherwise set to 0.
L bit - Set to 1 for the last packet of a fragmented SBC frame,
otherwise set to 0.
RFA - SHOULD be zero, reserved for future addition.
#frames (4 bits) - If the F bit is set to 0, this field indicates
the number of frames contained in this packet. If the F
bit is set to 1, this field indicates the number of
remaining fragments, including the current fragment. Thus
the last counter value MUST be one. For example, if there
are three fragments then the counter has value 3, 2 and 1
for subsequent fragments.
3.4. SBC Frame Structure
An SBC frame consists of a frame header, scale factors, audio An SBC frame consists of a frame header, scale factors, audio
samples, and padding bits. The following diagram shows the general samples, and padding bits. The following diagram shows the general
SBC frame format layout: SBC frame format layout:
+--------------+---------------+---------------+---------+ +--------------+---------------+---------------+---------+
| frame_header | scale_factors | audio_samples | padding | | frame_header | scale_factors | audio_samples | padding |
+--------------+---------------+---------------+---------+ +--------------+---------------+---------------+---------+
The following sections describe the audio format, which consists of The following sections describe the audio format, which consists of
bits stored in a bandwidth-efficient, compact mode. bits stored in a bandwidth-efficient, compact mode.
3.5. 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 9, line 41 skipping to change at page 8, line 28
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 and a RFA.
3.6. 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
enough to support multiple, quite diverse usage scenarios. Thus, it enough to support multiple, quite diverse usage scenarios. Thus, it
might be required to change the behavior of the encoding and might be required to change the behavior of the encoding and
skipping to change at page 12, line 28 skipping to change at page 11, line 21
calculated using the sampling rate and the number of calculated using the sampling rate and the number of
samples per frame per channel. A change in sampling samples per frame per channel. A change in sampling
frequency MUST NOT occur within one media packet. frequency MUST NOT occur within one media packet.
A SBC frame may be fragmented into multiple media packets A SBC frame may be fragmented into multiple media packets
to reduce the packetisation delay. Then, all packets that to reduce the packetisation delay. Then, all packets that
make up a fragmented SBC frame MUST use the same TS. make up a fragmented SBC frame MUST use the same TS.
6. Payload Format 6. Payload Format
The format of the payload MUST follow exactly the description given The format of the payload MUST follow exactly the description given
in appendix B of [A2DPV12] and which is repeated in Section 3. If in Section 4.3.4, "Media Payload Format", of [A2DPV12].
appendix B of [A2DPV12] and the description in Section 3 differ, the
former standard is normative.
If the payload format parameters have been negotiated and a If the payload format parameters have been negotiated and a
restricted set of encoding and decoding modes have been selected, restricted set of encoding and decoding modes have been selected,
than any SBC frame that describes a coding mode that has not been than any SBC frame that describes a coding mode that has not been
chosen MUST be ignored. chosen MUST be ignored.
7. Payload Format Parameters 7. Payload Format Parameters
This section defines the parameters that MAY be used to configure This section defines the parameters that MAY be used to configure
optional features in the SBC payload format over RTP transmission. optional features in the SBC payload format over RTP transmission.
skipping to change at page 20, line 22 skipping to change at page 19, line 11
This payload format and the SBC encoding do not exhibit any large This payload format and the SBC encoding do not exhibit any large
non-uniformity in the receiver-end computational load and thus are non-uniformity in the receiver-end computational load and thus are
unlikely to pose a denial-of-service threat due to the receipt of unlikely to pose a denial-of-service threat due to the receipt of
pathological datagrams. pathological datagrams.
11. IANA Considerations 11. IANA Considerations
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 5.1 and Section 5.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.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
skipping to change at page 24, line 8 skipping to change at page 23, line 8
Funding for this draft has been provided by the University of Funding for this draft has been provided by the University of
Tuebingen within the "Projektfoerderung fuer Tuebingen within the "Projektfoerderung fuer
Nachwuchswissenschaftler". Nachwuchswissenschaftler".
This document was prepared using 2-Word-v2.0.template.dot. This document was prepared using 2-Word-v2.0.template.dot.
Authors' Addresses Authors' Addresses
Christian Hoene Christian Hoene
University of Tuebingen Symonics GmbH
Wilhelm-Schickard-Institute
Sand 13 Sand 13
72076 Tuebingen 72076 Tuebingen
DE DE
Phone: +49 7071 29 70532 Phone: +49 7071 5681300
Email: hoene@uni-tuebingen.de Email: christian.hoene@symonics.com
Frans de Bont Frans de Bont
Philips Electronics Philips Electronics
High Tech Campus 36 High Tech Campus 36
5656 AE Eindhoven 5656 AE Eindhoven
NL NL
Phone: +31 40 2740234 Phone: +31 40 2740234
Email: frans.de.bont@philips.com Email: frans.de.bont@philips.com
 End of changes. 12 change blocks. 
115 lines changed or deleted 43 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/