Network Working Group - AVT C. Hoene
Internet Draft University of Tuebingen
Intended status: Standards Track F. de Bont
Expires: April 2009 Philips Electronics
October 21, 2008
RTP Payload Format for Bluetooth's SBC audio codec
draft-hoene-avt-rtp-sbc-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that
any applicable patent or other IPR claims of which he or she is
aware have been or will be disclosed, and any of which he or she
becomes aware will be disclosed, in accordance with Section 6 of
BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on April 21, 2009.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract
This document specifies a Real-time Transport Protocol (RTP) payload
format to be used for the low complexity subband codec (SBC), which
is the mandatory audio codec of the Advanced Audio Distribution
Profile (A2DP) Specification written by the Bluetooth(r) Special
Hoene et al. Expires April 21, 2009 [Page 1]
Internet-Draft RTP Payload Format for SBC October 2008
Interest Group (SIG). The payload format is designed to be able to
interoperate with existing Bluetooth A2DP devices, to provide high
streaming audio quality, interactive audio transmission over the
internet, and ultra-low delay coding for jam sessions on the
internet. This document contains also a media type registration which
specifies the use of the RTP payload format.
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [RFC2119].
The following acronyms are used in this document:
A2DP - Audio Distribution Profile
AAC - Advanced Audio Coding
ATRAC - Adaptive Transform Acoustic Coding
DCCP - Datagram Congestion Control Protocol
MP3 - MPEG-1 Audio Layer 3
SBC - SubBand Codec
SIG - Special Interest Group
Table of Contents
1. Introduction ................................................ 3
2. Background .................................................. 3
3. Usage Scenarios ............................................. 5
3.1. Scenario 1: Interconnection of A2DP devices ............ 5
3.2. Scenario 2: High quality interactive audio transmissions 6
3.3. Scenario 3: Ensembles performing over a network ........ 6
4. Header Usage ................................................ 7
5. Payload Format .............................................. 7
5.1. Media payload format header ............................ 8
5.2. SBC Frame Structure .................................... 9
5.3. Frame header ........................................... 9
5.4. Remaining frame........................................ 11
6. Payload Format Parameters .................................. 12
6.1. SBC Media Type Registration ........................... 12
6.1.1. Capabilities ..................................... 13
6.2. Mapping to SDP Parameters ............................. 14
6.2.1. Offer-Answer Model Considerations ................ 15
6.2.2. Declarative SDP Considerations ................... 16
7. Congestion Control ......................................... 16
8. Packet loss concealment .................................... 17
9. Security Considerations .................................... 17
10. IANA Considerations........................................ 18
Hoene et al. Expires April 21, 2009 [Page 2]
Internet-Draft RTP Payload Format for SBC October 2008
11. References ................................................ 19
11.1. Normative References ................................. 19
11.2. Informative References ............................... 19
Author's Addresses ............................................ 21
Intellectual Property Statement ............................... 21
Disclaimer of Validity ........................................ 22
1. Introduction
The Bluetooth(r) Special Interest Group (SIG) specifies in the
Advanced Audio Distribution Profile (A2DP) [A2DPV12] a mono and
stereo high quality audio subband codec (SBC). This document
specifies the payload format for the encapsulation of SBC encoded
audio frames into the Real-time Transport Protocol (RTP).
SBC has a low computational complexity at modest compression rates.
Its bit rate can be controlled widely. Recommended operational modes
range from 127 to 345 kb/s, for mono and stereo audio signals. SBC's
algorithmic delay can be as low as 16 samples making it ideal for
ensembles playing music over the network requiring ultra low acoustic
delays.
2. Background
The A2DP specification is intended for streaming of music content to
headphones, headsets, or speakers over Bluetooth wireless channels.
A2DP supports multiple audio coding including MP3, AAC, ATRAC, which
are all non-mandatory. To ensure interoperability, the SBC codec has
been specified, which shall be included into all A2DP Bluetooth
devices.
The SBC is a low complexity subband codec based on earlier work
presented in [Bon95]. It has a moderate compression ratio. The SBC
encoder has filter banks splitting the audio signal into 4 or 8
subbands. Then the codec decides with how many bits each subband is
encoded and finally quantizes the subband signals blockwise. An SBC
frame can have different block sizes. The size of a block can be 4,
8, 12 or 16. Both decoder and encoder shall support all four block
sizes.
SBC can operate at four different sampling frequencies. The sampling
frequency can be selected from a set of 16, 32, 44.1, and 48 kHz. It
is mandatory that each SBC decoder can operate at the frequencies
44.1 and 48 kHz. Each SBC encoder shall work at least at a sampling
rate of 44.1 or 48 kHz.
Hoene et al. Expires April 21, 2009 [Page 3]
Internet-Draft RTP Payload Format for SBC October 2008
Four channel modes are supported, which are mono, dual channel,
stereo, and joint-stereo. The decoder shall support all four of them;
the encoder shall support mono and at least one additional mode.
SBC can use four or eight subbands. The decoder shall support both;
the encoder shall support at least 8 subbands.
The bit allocation modes of SBC can be either based on signal to
noise ratio or on loudness. The decoder shall support both modes; the
encoder shall support at least the loudness mode.
The SBC encoder reduces one block to a given number of bits. The bit-
pool variable defines how many bits are used per block. A2DP devices
define the range of valid bit-pool values by providing minimum and
maximum bit-pool values. The bit-pool values shall range from 2 to
250 but shall not be larger than number of subbands times 16 for the
mono and dual and times 32 for the stereo and joint-stereo channel
modes.
SBC encoders inside A2DP devices may be capable of changing the bit-
pool parameter dynamically during the encoding process.
The decoder shall support all possible bit-pool values that do not
result in excess of maximum bit rate, which is 320kb/s for mono and
512kb/s for two-channel modes. The encoder is required to support at
least one possible bit-pool value. The A2DP specification recommends
the encoding parameters given in Table 1.
Hoene et al. Expires April 21, 2009 [Page 4]
Internet-Draft RTP Payload Format for SBC October 2008
+------------------------------------------------------------+
| SBC encoder settings at Medium Quality |
+--------------------------------+-------------+-------------+
| | Mono | Joint Stereo|
| Sampling frequency (kHz) | 44.1 | 48 | 44.1 | 48 |
| Bitpool value | 19 | 18 | 35 | 33 |
| Resulting frame length (bytes) | 46 | 44 | 83 | 79 |
| Resulting bit rate (kb/s) | 127 | 132 | 229 | 237 |
+--------------------------------+------+------+------+------+
| SBC encoder settings at High Quality |
+--------------------------------+-------------+-------------+
| | Mono | Joint Stereo|
| Sampling frequency (kHz) | 44.1 | 48 | 44.1 | 48 |
| Bitpool value | 31 | 29 | 53 | 51 |
| Resulting frame length (bytes) | 70 | 66 | 119 | 115 |
| Resulting bit rate (kb/s) | 193 | 198 | 328 | 345 |
+--------------------------------+------+------+------+------+
+ Other settings: Block length = 16, loudness, subbands = 8 |
+------------------------------------------------------------+
Table 1: Recommended sets of SBC parameters in the SRC device as
given in [A2DP]
The A2DP V1.2 specification describes a media payload format, which
we adopt one-to-one without any change in this document.
3. Usage Scenarios
As compared to many other encoding schemes, the SBC is general enough
to support multiple, quite diverse usage scenarios. Thus, it might be
required to change the behavior of the encoding and transmission to
achieve a good performance for a given usage scenario. Thus, we
enlist three main scenarios and describe their quality requirements
and their impact on the encoding and transmission.
3.1. Scenario 1: Interconnection of A2DP devices
In this scenario it is intended to interconnect Bluetooth A2DP
devices. RTP frames generated by an A2DP device can be transmitted
directly via this RTP profile. Vice versa, an A2DP device should be
able to receive the RTP profile by default. Thus, the payload format
describe in this RFC MUST be fully interoperable with any A2DP
device.
The transmission between two A2DP devices has a constant frame rate
with a sender-controlled bit rate. It is not anticipated that the
transmission is adapted to congestion and bandwidth variation.
Hoene et al. Expires April 21, 2009 [Page 5]
Internet-Draft RTP Payload Format for SBC October 2008
3.2. Scenario 2: High quality interactive audio transmissions
In the second scenario we consider a telephone call having a very
good audio quality at modest acoustic one-way latencies ranging from
50 and 150 ms [ITUG107], so that music can be listened over the
telephone while two persons talk together interactively.
In addition, the reliability of the audio transmission should be
high, even in cases of low and varying bandwidth.
This second scenario assumes that the SBC transmission is used on top
of a transport protocol that implements a congestion control
algorithm. Using the SBC encoding, the sampling, bit, and frame rates
should be controlled to cope with congestion. For example, if the
available transmission bandwidth is too low to allow SBC to transmit
audio at a high quality, the application can lower the sampling, bit,
or frame rate of the stream at the cost of higher algorithmic delay
or a degraded audio quality. In this case, changing the sampling or
frame rate may cause a short acoustic artifact because SBC's internal
filters must be reset.
The A2DP media format does not allow a dynamic change of the encoding
parameters beside the bit-pool value. The encoding parameters can
only be altered with the "Change Parameters" procedure, which is
defined in [GAVDPV12]. Such a change will cause a hearable
interruption and thus shall be avoided.
If an application using RTP wants to switch between different sets of
encoding parameters, then these set of parameter CAN be either
negotiate beforehand (as described in Section 6.2. ) or an
renegotiation similar to the "Change Parameters" procedure CAN take
place. An application MUST NOT change the sampling frequency, block
length, encoding mode or the number of subbands within one RTP
session having the same RTP payload identifier.
3.3. Scenario 3: Ensembles performing over a network
In some usage scenarios, users want to act simultaneously and not
just interactively. For example, if persons sing in a chorus, if
musicians jam, or if e-sportsmen play computer games in a team
together, they need to acoustically communicate.
In these scenarios, the latency requirements are much harder than for
interactive usages. For example, if two musicians are placed more
than 10 meters apart, they can hardly keep synchronized. Empirical
studies [Gurevich2004] have shown that if ensembles playing over
Hoene et al. Expires April 21, 2009 [Page 6]
Internet-Draft RTP Payload Format for SBC October 2008
networks, the optimal acoustic latency is around 11.5 ms with
targeted range from 10 to 25 ms.
To fulfill such requirements, it might be necessary to further reduce
the algorithmic coding delay by varying the block length parameter.
The default value of the block length parameter is chosen such that
the coding efficiency is maximized. For example, at 44.1 kHz and
using 8 subbands and a block length of 16, the algorithmic delay is
4.72 ms (208 samples). The value of the block length parameter can be
decreased, at the expense of a higher bit rate or lower quality, to
lower the latency to fulfill the very stringent latency requirements
of this scenario.
4. Header Usage
The format of the RTP header is specified in [RFC3550]. The payload
format defined in this document uses the fields of the header in a
manner fully consistent with that specification.
marker (M): In accordance with [A2DPV12] the marker bit MUST be set
to zero.
payload type (PT): The assignment of an RTP payload type for this
packet format is outside the scope of the document, and
will not be specified here. It is expected that the RTP
profile under which this payload format is being used will
assign a payload type for this codec or specify that the
payload type is to be bound dynamically (see Section 6.2).
timestamp (TS): The RTP timestamp clock frequency MUST be the same as
the sampling frequency, which has been negotiated for the
current RTP session (see Section 6.2). If a media payload
consists of multiple SBC frames, the TS of the media packet
header represents the TS of the first SBC frame. The TS of
the following SBC frames MUST be calculated using the
sampling rate and the number of samples per frame per
channel. A change in sampling frequency MUST NOT occur
within one media packet.
A SBC frame may be fragmented into multiple media packets
to reduce the packetisation delay. Then, all packets that
make up a fragmented SBC frame MUST use the same TS.
5. Payload Format
The format of the payload MUST follow exactly the description given
in the appendix of [A2DPV12]. In the following, for the sake of
clarity, we repeat the payload format definition.
Hoene et al. Expires April 21, 2009 [Page 7]
Internet-Draft RTP Payload Format for SBC October 2008
The payload MUST consist of one media payload format header described
in Section 5.2 and SBC frames described in Section 5.3. 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.
The 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.
5.1. 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.
Hoene et al. Expires April 21, 2009 [Page 8]
Internet-Draft RTP Payload Format for SBC October 2008
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.
5.2. SBC Frame Structure
The complete SBC frame consists of a frame header, scale factors,
audio samplings, and padding bits. The following diagram shows the
general SBC frame format layout:
+--------------+---------------+---------------+---------+
| frame_header | scale_factors | audio_samples | padding |
+--------------+---------------+---------------+---------+
The following sections describe the audio format, which consists of
bits stored in a bandwidth-efficient, compact mode.
5.3. Frame header
The frame header consists of fields defined in [A2DPV12], which are
SYNCWORD, SAMPLING_FREQUENCY, BLOCKS, CHANNEL_MODE,
ALLOCATION_METHOD, SUBBANDS, BITPOOL, CRC_CHECK, optionally JOIN bit
fields and a RFA. The layout of the first four bytes of the frame
header is given in the following table.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SYNCWORD |SF.|BL.|CM.|A|S|BITPOOL |CRC_CHECK |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Legend: SF.=SAMPLING FREQUENCY, BL.=BLOCKS, CM.=CHANNEL_MODE,
A.=ALLOCATION_METHOD, S.=SUBBANDS
SYNCWORD (8 bits): The first field is the 8 bit synchronization word,
which is always set to 156.
Hoene et al. Expires April 21, 2009 [Page 9]
Internet-Draft RTP Payload Format for SBC October 2008
SAMPLING_FREQUENCY (2 bits): The sampling frequency field indicates
with which sampling frequency the SBC frame has been
encoded. The table below specifies the corresponding
sampling frequencies for the bit patterns. The sampling
frequency MUST NOT be changed without changing the payload
type, too.
+--------------------+----------------+
| SAMPLING_FREQUENCY | sampling |
| bit 0 1 | frequency (Hz) |
+--------------------+----------------+
| 0 0 | 16000 |
| 0 1 | 32000 |
| 1 0 | 44100 |
| 1 1 | 48000 |
+--------------------+----------------+
BLOCKS (2 bits): It indicates the block size with which the stream
has been encoded. The block size is selected conforming to
the table below. The block size MUST NOT be changed without
changing the payload type, too.
+---------+-----------+
| BLOCKS | Number of |
| bit 0 1 | blocks |
+---------+-----------+
| 0 0 | 4 |
| 0 1 | 8 |
| 1 0 | 12 |
| 1 1 | 16 |
+---------+-----------+
CHANNEL_MODE (2 bits): These two bits indicate with which channel
mode the frame has been encoded. The number of channels
depends on this information. The channel mode MUST NOT be
changed without changing the payload type, too.
+--------------+--------------+-----------+
| CHANNEL_MODE | channel mode | number of |
| bit 0 1 | | channels |
+--------------+--------------+-----------+
| 0 0 | MONO | 1 |
| 0 1 | DUAL_CHANNEL | 2 |
| 1 0 | STEREO | 2 |
| 1 1 | JOINT_STEREO | 2 |
+--------------+--------------+-----------+
Hoene et al. Expires April 21, 2009 [Page 10]
Internet-Draft RTP Payload Format for SBC October 2008
ALLOCATION_METHOD (1 bit): This bit indicates how the bit pool is
allocated to different subbands. Either it is based on the
loudness of the sub band signal or on the signal to noise
ratio. The allocation method MUST NOT be changed without
changing the payload type, too.
+-------------------+------------+
| ALLOCATION_METHOD | allocation |
| bit 0 | method |
+-------------------+------------+
| 0 | LOUDNESS |
| 1 | SNR |
+-------------------+------------+
SUBBANDS (1 bit): This bit indicates the number of subbands with
which the frame has been encoded. The number of subband
MUST NOT be changed without changing the payload type, too.
+----------+-----------+
| SUBBANDS | number of |
| bit 0 | subbands |
+----------+-----------+
| 0 | 4 |
| 1 | 8 |
+----------+-----------+
BITPOOL (8 bits): This unsigned integer indicates the size of the bit
allocation pool that has been used for encoding the current
block. The value of the bit-pool field MUST not exceed 16
times the number of subbands for the MONO and DUAL_CHANNEL
channel modes and 32 times the number of subbands for the
STEREO and JOINT_STEREO channel modes. The bitpool value
MAY change from SBC frame to the next. In addition, the
bitpool value MUST be restricted such that it does not
result in excess of maximum bit rate, which is 320kb/s for
mono and 512kb/s for two-channel modes.
The remaining part of the header consists of CRC_CHECK, optionally
JOIN bit fields and a RFA.
5.4. Remaining frame
The remaining part of the frame includes scale factors and audio
sample data, which are processed by the codec as described in
[A2DPV12].
Hoene et al. Expires April 21, 2009 [Page 11]
Internet-Draft RTP Payload Format for SBC October 2008
6. Payload Format Parameters
This section defines the parameters that MAY be used to configure
optional features in the SBC payload format over RTP transmission.
The parameters are defined here as part of the media subtype
registrations for the SBC. A mapping of the parameters into the
Session Description Protocol (SDP) [RFC4566] is also provided 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
appropriate format used with that control protocol.
6.1. SBC Media Type Registration
[Note to RFC Editor: Please replace all occurrences of RFC XXXX by
the RFC number assigned to this document]
This registration is done using the template defined in [RFC4288] and
following [RFC4855].
MIME media type name: audio
MIME subtype name: SBC
Required parameters: none
Optional parameters:
Capabilities: A hexadecimal representation of an octet string that
expresses the capabilities of the encoder and/or the
decoder. Possible values are a comma-separated list of four
unsigned octets: Octet1, Octet2, Octet3, and Octet4. These
four octets share the same meaning as those defined in
Section 4.3.2 of [A2DPV12] repeated in the following
Section 5.1.1. If this optional parameter is omitted, all
coding modes MUST be supported.
Encoding considerations: This media type is framed and contains
binary data; see Section 4.8 of RFC 4288.
Security considerations: See Section 9 of RFC XXXX
Interoperability considerations: none
Published specification: RFC XXXX
Hoene et al. Expires April 21, 2009 [Page 12]
Internet-Draft RTP Payload Format for SBC October 2008
Applications which use this media type: Audio and video conferencing
tools, distributed orchestras
Additional information: none
Person & email address to contact for further information: Christian
Hoene, hoene@uni-tuebingen.org
Intended usage: COMMON
Restrictions on usage: none
Author: Christian Hoene, Frans de Bont
Change controller: IETF Audio/Video Transport working group delegated
from the IESG
6.1.1. Capabilities
The capabilities of the encoder and decoder are describes with four
octets (1 to 4) as defined in Section 4.3.2 of [A2DPV12]. The meaning
of the bits and the octets are described in the following.
o Octet 1: Bit 0 (aka 2^7): If one, then the sampling frequency
16000 Hz is supported.
o Octet 1: Bit 1: If one, then the sampling frequency 32000 Hz is
supported.
o Octet 1: Bit 2: If one, then the sampling frequency 44100 Hz is
supported.
o Octet 1: Bit 3: If one, then the sampling frequency 48000 Hz is
supported.
o Octet 1: Bit 4: If one, then the channel mode MONO is supported.
o Octet 1: Bit 5: If one, then the channel mode DUAL_CHANNEL 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
JOINT_STEREO is supported.
o Octet 2: Bit 0: If one, the block length can be 4.
Hoene et al. Expires April 21, 2009 [Page 13]
Internet-Draft RTP Payload Format for SBC October 2008
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 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 5: If one, the number of subband can be 8.
o Octet 2: Bit 6: If one, the allocation mode based on signal to
noise ratio is supported.
o Octet 2: Bit 7: If one, the allocation mode based on loudness is
supported.
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
than the maximal bit-pool value.
o Octet 4: Unsigned integer: The maximal bit-pool value that the
device supports MUST be equal or lower than 250.
6.2. Mapping to SDP Parameters
The information carried in the media type specification has a
specific mapping to fields in the Session Description Protocol (SDP)
[RFC4566], which is commonly used to describe RTP sessions. When SDP
is used to specify sessions employing the SBC codec, the mapping is
as follows:
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
name.
o The RTP <clock rate> in "a=rtpmap" MUST be set to the highest
supported sampling frequency. It MUST be identical to the highest
of the sampling frequencies that are specified by the Octet1 and
Bit 0 to 3 in the following capabilities parameter.
o The RTP <encoding parameters> in "a=rtpmap" specifies the number
of audio channels: 2 for stereo material (see RFC 2327 [5]) and 1
for mono. It MUST be identical to the maximal number of channels
given in Octet 1 and Bit 4 to 7 in the following capabilities
parameter.
Hoene et al. Expires April 21, 2009 [Page 14]
Internet-Draft RTP Payload Format for SBC October 2008
o The parameter "capabilities" goes in the SDP "a=fmtp" by copying
its four octets.
6.2.1. Offer-Answer Model Considerations
The Bluetooth standard [AVDTPV12] describes how an A2DP source and an
A2DP sink negotiate their capabilities. Prior to the establishment of
the audio stream, one A2DP device can query the service capabilities
of the other device using the "Get Capabilities Procedure". In any
case, the coding mode is set using the "Set Configuration" procedure.
Only after a successful configuration, the stream connection can be
established.
In addition to the Bluetooth negotiation procedure, the SDP
negotiation MUST NOT agree on one single configuration but CAN agree
that multiple configuration modes, which are identified by different
payload type values, are supported.
The following considerations apply when using SDP offer-answer
procedures [RFC3264] to negotiate the use of SBC payload in RTP:
o The "capabilities" parameter is bi-directional, i.e., the
restricted mode set applies to media both to be received and sent
by the declaring entity. If the capabilities were supplied in the
offer, the answerer MUST return either the same mode-set or a
subset of this mode-set. If no capabilities were supplied in the
offer, the answerer MAY return capabilities to restrict the
possible modes. In any case, the capabilities in the answer then
apply for both offerer and answerer. The offerer MUST NOT send
frames of a mode that has been removed by the answerer.
o Any unknown parameter in an offer MUST be ignored by the receiver
and MUST NOT be included in the answer.
Below are some example parts of SDP offer-answer exchanges.
o Example 1
Offer: SBC all modes
m=audio 54874 RTP/AVP 96
a=rtpmap:96 SBC/48000/2
a=fmtp:96 capabilities=FF,FF,02,FA
Hoene et al. Expires April 21, 2009 [Page 15]
Internet-Draft RTP Payload Format for SBC October 2008
o Answer: 48 kHz, JOINT_STEREO, 16 blocks, 8 subbands, LOUDNESS
m=audio 59452 RTP/AVP 96
a=rtpmap:96 SBC/48000/2
a=fmtp:96 capabilities=11,15,02,FA; Example 2
Offer: SBC all modes
m=audio 54874 RTP/AVP 96
a=rtpmap:96 SBC/48000/2
a=fmtp:96 capabilities=FF,FF,02,FA
Answer: wants 44.1 kHz, mono mode, 16 blocks, 8 subbands,
LOUDNESS, bit-pool value set to 19
m=audio 59452 RTP/AVP 96
a=rtpmap:96 SBC/44100/1
a=fmtp:96 capabilities=28,15,13,13
o Example 3
Offer: SBC 48 kHz, mono or joint stereo, 8 subbands, loudness
allocation method.
m=audio 54874 RTP/AVP 96
a=rtpmap:96 SBC/48000/2
a=fmtp:96 capabilities=19,F5,02,FA
Answer: accepted m=audio 59452 RTP/AVP 96
a=rtpmap:96 SBC/48000/2
a=fmtp:96 capabilities=19,F5,02,FA
6.2.2. Declarative SDP Considerations
For declarative use of SDP nothing specific is defined for this
payload format. The configuration given by the SDP MUST be used when
sending and/or receiving media in the session.
7. Congestion Control
One Bluetooth links, bandwidth can be reserved and thus the A2DP
specification does not consider any kind of congestion control.
However, congestion control is an important issue for any usage in
non-dedicated networks such as the Internet. Thus, congestion control
for RTP MUST be used in accordance with [RFC3550] and any appropriate
profile (for example, [RFC3551]). An additional requirement if best-
effort service is being used is: users of this payload format MUST
monitor packet loss to ensure that the packet loss rate is within
acceptable parameters.
Reducing the session bandwidth is possible by one or more of the
following means, which all will have negative impact to the users'
experience as he can notice a higher latency or a degraded audio
quality. The selection of the following means depends on current
usage scenario, the congestion control protocol, and the perceptual
Hoene et al. Expires April 21, 2009 [Page 16]
Internet-Draft RTP Payload Format for SBC October 2008
assessment of the audio transmission and is not subject of this
specification.
1. If the packet loss rate is very high, the session shall be
terminated because the quality of the audio transmission is too
bad to be useful [Widmer2002].
2. If the bandwidth shall be reduced, then the bit-pool value can be
reduced, so that the frames get smaller or the mono mode can be
selected.
3. If the bandwidth and frame rate shall be reduced, the sampling
rate can be lowered [Boutremans2004,Hoene2005].
4. If the gross bandwidth and the frame rate shall be reduced, more
blocks can be put into one SBC frame and more SBC frames can be
placed in one RTP payload.
Because the SBC encoding can be tuned with many parameters, it is
especially useful for rate adaptive transport protocols such as DCCP
[RFC4340] or TCP [RFC4571].
8. Packet loss concealment
In order to cope with packet losses, the SBC decoder SHOULD be
extended by a packet loss concealment algorithm. The packet loss
concealment algorithm SHOULD provide a good audio quality in case of
losses. Otherwise, the congestion control algorithm can not trade off
well the quality impairment due to packet losses versus the quality
impairment caused by different encoding modes. It is RECOMMENDED that
at a least the reserve order replicated pitch periods (RORPP)
algorithm as defined in [ITUG711A1] or any other with a better
algorithm used. If this requirement is not meet, then the congestion
control cannot predict the impact of packet loss on the audio quality
and thus will not be able to control the encoding parameters
optimally.
9. Security Considerations
RTP packets using the payload format defined in this specification
are subject to the general security considerations discussed in the
RTP specification [RFC3550] and any appropriate profile (for example,
[RFC3551]).
As this format transports encoded speech/audio, the main security
issues include confidentiality, integrity protection, and
authentication of the speech/audio itself. The payload format itself
Hoene et al. Expires April 21, 2009 [Page 17]
Internet-Draft RTP Payload Format for SBC October 2008
does not have any built-in security mechanisms. Any suitable
external mechanisms, such as SRTP [RFC3711], MAY be used.
This payload format and the SBC encoding do not exhibit any large
non-uniformity in the receiver-end computational load and thus are
unlikely to pose a denial-of-service threat due to the receipt of
pathological datagrams.
10. IANA Considerations
It is requested that one new media subtype (audio/SBC) and two
optional parameters for this media subtype ("capabilities" and
"usage") are registered by IANA, see Section 5.1 and Section 5.2.
Hoene et al. Expires April 21, 2009 [Page 18]
Internet-Draft RTP Payload Format for SBC October 2008
11. References
11.1. Normative References
[A2DPV12] Bluetooth SIG, "Advanced Audio Distribution Profile",
Speficiation, Audio Video WG, adopted specification,
revision V12, April 16th, 2007.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and
Video Conferences with Minimal Control", STD 65, RFC 3551,
July 2003.
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and
Registration Procedures", BCP 13, RFC 4288, December 2005.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer
Modelwith Session Description Protocol (SDP)", RFC 3264,
June 2002.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[RFC4855] Casner, S., "Media Type Registration of RTP Payload
Formats", RFC 4855, February 2007.
[ITUG711A1] ITU Recommendation G.711 Appendix I, "A high quality low-
complexity algorithm for packet loss concealment with
G.711", September 1999.
11.2. Informative References
[AVDTPV12] Bluetooth SIG, "Audio/Video Distribution Transport
Protocol Specification", Audio Video WG, adopted
specification, revision V12, April 16th, 2007.
[Bon1995] F. de Bont, M. Groenewegen and W. Oomen, "A High Quality
Audio-Coding System at 128 kb/s", 98th AES Convention,
Febr. 25 - 28, 1995.
Hoene et al. Expires April 21, 2009 [Page 19]
Internet-Draft RTP Payload Format for SBC October 2008
[Boutremans2004] C. Boutremans, J.-Y. Le Boudec and J. Widmer, "End-
to-end congestion control for tcp-friendly flows with
variable packet size," ACM Computer Communication Review,
Vol. 31, Nr. 2, pp. 137-151, 2004.
[GAVDPV12] Bluetooth SIG, "Generic Audio/Video Distribution Profile,"
Audio Video WG, adopted specification, revision V12, April
16th, 2007.
[Gurevich2004] M. Gurevich, C. Chafe, G. Leslie and S. Tyan,
"Simulation of Networked Ensemble Performance with Varying
Time Delays: Characterization of Ensemble Accuracy,"
Proceedings of the 2004 International Computer Music
Conference, Miami, USA, 2004.
[Hoene2005] Christian Hoene, Holger Karl, and Adam Wolisz, "A
perceptual quality model intended adaptive VoIP
applications," International Journal of Communication
Systems, Wiley, August 2005.
[ITUG107] ITU-T G.107, "The E-model, a computational model for use in
transmission planning," ITU-T Recommendation G.107, May
2000.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004.
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion
Control Protocol (DCCP)", RFC 4340, March 2006.
[RFC4571] J. Lazzaro, "Framing Real-time Transport Protocol (RTP) and
RTP Control Protocol (RTCP) Packets over Connection-
Oriented Transport,", RFC4571, July 2006.
[Widmer2002] J. Widmer, M. Mauve, and J. P. Damm, "Probabilistic
congestion control for non-adaptable flows," In 12th
International Workshop on Network and Operating Systems
Support for Digital Audio and Video (NOSSDAV), Miami, FL,
USA, May 2002.
Hoene et al. Expires April 21, 2009 [Page 20]
Internet-Draft RTP Payload Format for SBC October 2008
Author's Addresses
Christian Hoene
University of Tuebingen
Wilhelm-Schickard-Institute
Sand 13
72076 Tuebingen
DE
Phone: +49 7071 29 70532
Email: hoene@uni-tuebingen.org
Frans de Bont
Philips Electronics
High Tech Campus 5
5656 AE Eindhoven,
NL
Phone: +31 40 2740234
Email: frans.de.bont@philips.com
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Hoene et al. Expires April 21, 2009 [Page 21]
Internet-Draft RTP Payload Format for SBC October 2008
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
Acknowledgment
Funding for this draft has been provided by the University of
Tuebingen within the Nachwuchswissenschaftler program.
Hoene et al. Expires April 21, 2009 [Page 22]