One document matched: draft-westerlund-avt-rtp-gsm-hr-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-westerlund-avt-rtp-gsm-hr-00"
ipr="full3978">
<front>
<title abbrev="RTP Payload format for GSM-HR">RTP Payload format for
GSM-HR</title>
<author fullname="Magnus Westerlund" initials="M." surname="Westerlund">
<organization>Ericsson AB</organization>
<address>
<postal>
<street>Farogatan 6</street>
<city>Stockholm</city>
<region></region>
<code>SE-164 80</code>
<country>Sweden</country>
</postal>
<phone>+46 8 719 0000</phone>
<facsimile></facsimile>
<email>magnus.westerlund@ericsson.com</email>
<uri></uri>
</address>
</author>
<author fullname="Karl Hellwig" initials="K." surname="Hellwig">
<organization>Ericsson AB</organization>
<address>
<postal>
<street>Kackertstrasse 7-9</street>
<city>52072 Aachen</city>
<country>Germany</country>
</postal>
<phone>+49 2407 575-2054</phone>
<email>karl.hellwig@ericsson.com</email>
</address>
</author>
<author fullname="Ingemar Johansson" initials="I." surname="Johansson">
<organization>Ericsson AB</organization>
<address>
<postal>
<street>Laboratoriegrand 11</street>
<city>SE-971 28 Lulea</city>
<country>SWEDEN</country>
</postal>
<phone>+46 73 0783289</phone>
<email>ingemar.s.johansson@ericsson.com</email>
</address>
</author>
<date day="24" month="Oct" year="2008" />
<abstract>
<t>This document specifies the RTP payload format for packetization of
the GSM Half-Rate speech codec.</t>
</abstract>
<note title="Requirements Language">
<t>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 <xref
target="RFC2119">RFC 2119</xref>.</t>
</note>
</front>
<middle>
<section title="Introduction">
<t>This document specifies the payload format for packetization of <xref
target="TS46.002">GSM Half Rate (GSM-HR) codec</xref> encoded speech
signals into the Real-time Transport Protocol (RTP) <xref
target="RFC3550"></xref>. The payload format supports transmission of
multiple frames per payload and packet loss robustness methods using
redundancy.</t>
<t>This document starts with conventions, a brief description of the
codec, and the payload formats capabilities. The payload format is
specified in <xref target="sec-payload"></xref>. Examples can be found
in <xref target="sec-examples"></xref>. The media type and its mappings
to SDP, usage in SDP offer/answer is then specified. The document ends
with considerations around congestion control and security.</t>
<t>This document registers a media type (audio/gsm-hr-08) for the
Real-time Transport protocol (RTP) payload format for the GSM-HR codec.
Note: This format is not compatible with the one that was drafted back
in 1999 to 2000 in the Internet drafts: draft-ietf-avt-profile-new-05 to
draft-ietf-avt-profile-new-09. A later version of profile draft was
published as RFC 3551 without any specification of the GSM-HR payload
format. To avoid a possible conflict with this older format, the media
type of the payload format specified in this document has a media type
name that is different from (audio/gsm-hr).</t>
</section>
<section title="Conventions">
<t>This document uses the normal IETF bit-order representation. Bit
fields in figures are read left to right and then down. The left most
bits in each field is the most significant. The numbering starts on 0
and ascends, where bit 0 will be the most significant.</t>
</section>
<section title="GSM Half Rate">
<t>The Global System for Mobile Communication (GSM) network provides
mobile communication services for nearly 3 billion users (status 2008).
The GSM Half Rate Codec (GSM-HR) is one of the speech codecs that are
used in GSM networks. GSM-HR denotes the Half-Rate speech codec as
specified in <xref target="TS46.002"></xref>.</t>
<t>Note: for historical reasons these 46-series specifications are
internally referenced as 06-series. A simple mapping applies, for
example 46.020 is referenced as 06.20 and so on.</t>
<t>The GSM-HR codec has a frame length of 20 ms, with narrowband speech
sampled at 8 kHz, i.e. 160 samples per frame. Each speech frame is
compressed into 112 bits of speech parameters, which is equivalent to a
bit rate of 5.6 kbit/s. Speech pauses are detected by a standardized
Voice Activity Detection (VAD). During speech pauses the transmission of
speech frames is inhibited. Silence Descriptor (SID) frames are
transmitted at the end of a talk spurt and about every 480ms during
speech pauses to allow for a decent Comfort Noise (CN) quality at
receiver side.</t>
<t>The SID frame generation in the GSM radio network is determined by
the GSM mobile station and the GSM radio subsystem. SID frames come
during speech pauses in uplink from the mobile station about every
480ms. In downlink to the mobile station, when they are generated by the
encoder of the GSM radio subsystem, SID frames are sent every 20ms to
the GSM base station, which then picks only one every 480ms for downlink
radio transmission. For other applications, like transport over IP, it
is more appropriate to send the SID frames less often than every 20ms,
but 480 ms may be too sparse. We recommend as a compromise that a GSM-HR
encoder outside of the GSM radio network (i.e. not in the GSM mobile
station and not in the GSM radio subsystem, but for example in the media
gateway of the core network) should generate and send SID frames frames
every 160ms.</t>
</section>
<section title="Payload format Capabilities">
<t>This RTP payload format carries one or more GSM-HR encoded frames,
either full voice or silence descriptor (SID), representing a mono
speech signal. To maintain synchronization or express not sent or lost
frames it has the capability to indicate No_Data frames.</t>
<section anchor="sec-fec" title="Use of Forward Error Correction (FEC)">
<t>Generic forward error correction within RTP is defined, for
example, in RFC 5109 <xref target="RFC5109"></xref>. Audio redundancy
coding is defined in RFC 2198 <xref target="RFC2198"></xref>. Either
scheme can be used to add redundant information to the RTP packet
stream and make it more resilient to packet losses, at the expense of
a higher bit rate. Please see either RFCs for a discussion of the
implications of the higher bit rate to network congestion.</t>
<t>In addition to these media-unaware mechanisms, this memo specifies
an optional to use GSM-HR specific form of audio redundancy coding,
which may be beneficial in terms of packetization overhead.
Conceptually, previously transmitted transport frames are aggregated
together with new ones. A sliding window can be used to group the
frames to be sent in each payload. <xref target="fig-red"></xref>
below shows an example.</t>
<figure anchor="fig-red" title="An example of redundant transmission">
<artwork><![CDATA[--+--------+--------+--------+--------+--------+--------+--------+--
| f(n-2) | f(n-1) | f(n) | f(n+1) | f(n+2) | f(n+3) | f(n+4) |
--+--------+--------+--------+--------+--------+--------+--------+--
<---- p(n-1) ---->
<----- p(n) ----->
<---- p(n+1) ---->
<---- p(n+2) ---->
<---- p(n+3) ---->
<---- p(n+4) ---->
]]></artwork>
</figure>
<t>Here, each frame is retransmitted once in the following RTP payload
packet. f(n-2)...f(n+4) denote a sequence of audio frames, and
p(n-1)...p(n+4) a sequence of payload packets.</t>
<t>The mechanism described does not really require signaling at the
session setup. However, signalling has been defined to allow for the
sender to voluntarily bounding the buffering and delay requirements.
If nothing is signalled the use of this mechanism is allowed and
unbounded. For a certain timestamp, the receiver may receive multiple
copies of a frame containing encoded audio data. The cost of this
scheme is bandwidth and the receiver delay necessary to allow the
redundant copy to arrive.</t>
<t>This redundancy scheme provides a functionality similar to the one
described in RFC 2198, but it works only if both original frames and
redundant representations are GSM-HR frames. When the use of other
media coding schemes is desirable, one has to resort to RFC 2198.</t>
<t>The sender is responsible for selecting an appropriate amount of
redundancy based on feedback about the channel conditions, e.g., in
the RTP Control Protocol (RTCP) <xref target="RFC3550"></xref>
receiver reports. The sender is also responsible for avoiding
congestion, which may be exacerbated by redundancy (see <xref
target="sec-congestion"></xref> for more details).</t>
</section>
<t></t>
</section>
<section anchor="sec-payload" title="Payload format">
<t>The format of the RTP header is specified in <xref
target="RFC3550"></xref>. This payload format uses the fields of the
header in a manner consistent with that specification.</t>
<t>The duration of one speech frame is 20 ms. The sampling frequency is
8kHz, corresponding to 160 speech samples per frame. An RTP packet may
contain multiple frames of encoded speech or SID parameters. Each packet
covers a period of one or more contiguous 20 ms frame intervals. During
silence periods no speech packets are sent, however SID packets are
transmitted every now and then.</t>
<t>To allow for error resiliency through redundant transmission, the
periods covered by multiple packets MAY overlap in time. A receiver MUST
be prepared to receive any speech frame multiple times. A given frame
MUST NOT be encoded as speech frame in one packet and as SID frame or as
No_Data frame in another packet. Furthermore, a given frame MUST NOT be
encoded with different voicing modes in different packets.</t>
<t>The rules regarding maximum payload size given in Section 3.2 of
<xref target="I-D.ietf-tsvwg-udp-guidelines"></xref> SHOULD be
followed.</t>
<section title="RTP Header Usage">
<t>The RTP timestamp corresponds to the sampling instant of the first
sample encoded for the first frame in the packet. The timestamp clock
frequency SHALL be 8000 Hz. The timestamp is also used to recover the
correct decoding order of the frames.</t>
<t>The RTP header marker bit (M) SHALL be set to 1 whenever the first
frame carried in the packet is the first frame in a talkspurt (see
definition of the talkspurt in section 4.1 of <xref
target="RFC3551"></xref>). For all other packets the marker bit SHALL
be set to zero (M=0).</t>
<t>The assignment of an RTP payload type for the format defined in
this memo is outside the scope of this document. The RTP profiles in
use currently mandates binding the payload type dynamically for this
payload format.</t>
<t>The remaining RTP header fields are used as specified in RFC 3550
<xref target="RFC3550"></xref>.</t>
</section>
<section title="Payload Structure">
<t>The complete payload consists of a payload table of contents (ToC)
section, followed by speech data representing one or more speech
frames, SID frames or No_Data frames. The following diagram shows the
general payload format layout:<figure anchor="fig-layout"
title="General payload format layout">
<artwork><![CDATA[ +-------------+-------------------------
| ToC section | speech data section ...
+-------------+-----------------------]]></artwork>
</figure>Each ToC is one octet and corresponds to one speech frame,
the number of ToC’s is thus equal to the number of speech frames
(including SID frames and No_Data frames). Each ToC entry represents a
consecutive speech or SID or No_Data frame. The timestamp value for
ToC entry (and corresponding speech frame data) N within the payload
is (RTP timestamp field + (N-1)*160) mod 2^32 . The format of the ToC
octet is as follows. <figure anchor="fig-toc" title="The TOC element">
<artwork><![CDATA[
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|F| FT |R R R R|
+-+-+-+-+-+-+-+-+
]]></artwork>
</figure></t>
<t><list style="hanging">
<t hangText="F:">Follow flag, 1 denotes that more ToC’s
follow, 0 denotes the last ToC.</t>
<t hangText="R:">Reserved bits, MUST be set to zero and MUST be
ignored by receiver.</t>
<t hangText="FT:">Frame type <figure>
<artwork><![CDATA[ 000 = Good Speech frame
001 = Reserved
010 = Good SID frame
011 = Reserved
100 = Reserved
101 = Reserved
110 = Reserved
111 = No_Data frame]]></artwork>
</figure></t>
</list>The length of the payload data depends on the frame
type:<list style="hanging">
<t hangText="Good Speech frame: ">The 112 speech data bits are put
in 14 octets.</t>
<t hangText="Good SID frame: ">The 33 SID data bits are put in 14
octets, as in case of Speech frames, with the unused 79 bits set
all to “1”.</t>
<t hangText="No data frame: ">Length of payload data is zero
octets.</t>
</list>Frames marked in the GSM radio subsystem as “Bad Speech
frame”, “Bad SID frame” or “No_Data
frame” are not sent in RTP packets in order to save bandwidth.
They are marked as “No_Data frame”, if they occur within
an RTP packet that carries more than one speech frame, SID frame or
No_Data frame.</t>
<section title="Encoding of Speech Frames">
<t>The 112 bits of GSM-HR-coded speech (b1…b112) are defined
in TS 46.020, Annex B <xref target="TS46.020"></xref>, in the order
of occurrence. The first bit (b1) of the first parameter is placed
in bit 0 (the MSB) of the first octet (octet 1) of the payload
field; the second bit is placed in bit 1 of the first octet and so
on. The last bit (b112) is placed in the LSB (bit 7) of octet
14.</t>
</section>
<section title="Encoding of Silence Description Frames">
<t>The GSM-HR Codec applies a specific coding for silence periods in
so called SID frames. The coding of SID frames is based on the
coding of speech frames by using only the first 33 bits for SID
parameters and by setting the remaining 79 bits all to
“1”.</t>
</section>
</section>
<section title="Implementation Considerations">
<t>An application implementing this payload format MUST understand all
the payload parameters that is defined in this specification. Any
mapping of the parameters to a signaling protocol MUST support all
parameters. So an implementation of this payload format in an
application using SDP is required to understand all the payload
parameters in their SDP-mapped form. This requirement ensures that an
implementation always can decide whether it is capable of
communicating when the communicating entities support this version of
the specification.</t>
<section title="Transmission of SID frames">
<t>When using this RTP payload format the sender SHOULD generate and
send SID frames every 160ms, i.e. every 8th frame. Other SID
transmission intervals may occur due to gateways to other systems
that uses other transmission intervals.</t>
</section>
<section title="Receiving Redundant Frames">
<t>The reception of redundant audio frames, i.e. more than one audio
frame from the same source for the same time slot, MUST be supported
by the implementation.</t>
</section>
<section title="Decoding Validation">
<t>If the receiver finds a mismatch between the size of a received
payload and the size indicated by the ToC of the payload, the
receiver SHOULD discard the packet. This is recommended because
decoding a frame parsed from a payload based on erroneous ToC data
could severely degrade the audio quality.</t>
</section>
</section>
</section>
<section anchor="sec-examples" title="Examples">
<t>A few examples to highlight the payload format.</t>
<section title="3 frames">
<t>A basic example of the aggregation of 3 consecutive speech frames
into a single frame.</t>
<figure>
<artwork><![CDATA[
The first 24 bits are ToC fields.
Bit 0 is '1' as another ToC field follow.
Bits 1..3 is 000 = Good speech frame
Bits 4..7 is 0000 = Reserved
Bits 8 is '1' as another ToC field follow.
Bits 9..11 is 000 = Good speech frame
Bits 12..15 is 0000 = Reserved
Bit 16 is '0', no more ToC follows
Bits 17..19 is 000 = Good speech frame
Bits 20..23 is 0000 = Reserved
]]></artwork>
</figure>
<figure>
<artwork><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0 0 0|0 0 0 0|1|0 0 0|0 0 0 0|0|0 0 0|0 0 0 0|b1 b8|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
|b9 Frame 1 b40|
+ +
|b41 b72|
+ +
|b73 b104|
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|b105 b112|b1 b24|
+-+-+-+-+-+-+-+-+ +
|b25 Frame 2 b56|
+ +
|b57 b88|
+ +-+-+-+-+-+-+-+-+
|b89 b112|b1 b8|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
|b9 Frame 3 b40|
+ +
|b41 b72|
+ +
|b73 b104|
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|b105 b112|
+-+-+-+-+-+-+-+-+]]></artwork>
</figure>
</section>
<section title="3 Frames with lost frame in the middle">
<t>An example of payload carrying 3 frames where the middle one is
No_Data, for example due to loss prior to transmission by the RTP
source.<figure>
<artwork><![CDATA[
The first 24 bits are ToC fields.
Bit 0 is '1' as another ToC field follow.
Bits 1..3 is 000 = Good speech frame
Bits 4..7 is 0000 = Reserved
Bits 8 is '1' as another ToC field follow.
Bits 9..11 is 111 = No_Data frame
Bits 12..15 is 0000 = Reserved
Bit 16 is '0', no more ToC follows
Bits 17..19 is 000 = Good speech frame
Bits 20..23 is 0000 = Reserved
]]></artwork>
</figure><figure>
<artwork><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0 0 0|0 0 0 0|1|1 1 1|0 0 0 0|0|0 0 0|0 0 0 0|b1 b8|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
|b9 Frame 1 b40|
+ +
|b41 b72|
+ +
|b73 b104|
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|b105 b112|b1 b24|
+-+-+-+-+-+-+-+-+ +
|b25 Frame 3 b56|
+ +
|b57 b88|
+ +-+-+-+-+-+-+-+-+
|b89 b112|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure></t>
</section>
</section>
<section title="Payload Format Parameters">
<t>This RTP payload format is identified using the media type
"audio/gsm-hr-08", which is registered in accordance with <xref
target="RFC4855"></xref> and using the template of <xref
target="RFC4288"></xref>. Note: Media subtype names are
case-insensitive.</t>
<section anchor="sec-media-type" title="Media Type Definition">
<t>The media type for the GSM-HR codec is allocated from the IETF tree
since GSM-HR is a well know speech codec. This media type registration
covers real-time transfer via RTP. The media subtype name contains
"-08" to avoid potential conflict with any earlier drafts of GSM-HR
RTP payload types that aren't bit compatible.</t>
<t>Note, reception of any unspecified parameter MUST be ignored by the
receiver to ensure that additional parameters can be added in the
future.</t>
<t>Type name: audio</t>
<t>Subtype name: GSM-HR-08</t>
<t>Required parameters: none</t>
<t>Optional parameters: <list style="hanging">
<t hangText="max-red:">The maximum duration in milliseconds that
elapses between the primary (first) transmission of a frame and
any redundant transmission that the sender will use. This
parameter allows a receiver to have a bounded delay when
redundancy is used. Allowed values are between 0 (no redundancy
will be used) and 65535. If the parameter is omitted, no
limitation on the use of redundancy is present.</t>
<t hangText="ptime:">see <xref target="RFC4566"></xref>.</t>
<t hangText="maxptime:">see <xref target="RFC4566"></xref>.</t>
</list></t>
<t>Encoding considerations:<list style="empty">
<t>This media type is framed and binary, see section 4.8 in <xref
target="RFC4288">RFC4288</xref>.</t>
</list></t>
<t>Security considerations: <list style="empty">
<t>See <xref target="sec-sec"></xref> of RFCXXXX.</t>
</list></t>
<t>Interoperability considerations:</t>
<t>Published specification:<list style="empty">
<t>RFC XXXX, 3GPP TS 46.002</t>
</list></t>
<t>Applications that use this media type:<list style="empty">
<t>Real-time audio applications like voice over IP and
teleconference.</t>
</list></t>
<t>Additional information: none</t>
<t>Person & email address to contact for further information:<list
style="empty">
<t>Ingemar Johansson <ingemar.s.johansson@ericsson.com></t>
</list></t>
<t>Intended usage: COMMON</t>
<t>Restrictions on usage:<list style="empty">
<t>This media type depends on RTP framing, and hence is only
defined for transfer via RTP <xref target="RFC3550"></xref>.
Transport within other framing protocols is not defined at this
time.</t>
</list></t>
<t>Author: <list style="empty">
<t>Magnus Westerlund <magnus.westerlund@ericsson.com></t>
<t>Ingemar Johansson <ingemar.s.johansson@ericsson.com></t>
<t>Karl Hellwig <karl.hellwig@ericsson.com></t>
</list></t>
<t>Change controller:<list style="empty">
<t>IETF Audio/Video Transport working group delegated from the
IESG.</t>
</list></t>
</section>
<section title="Mapping to SDP">
<t>The information carried in the media type specification has a
specific mapping to fields in the Session Description Protocol (SDP)
<xref target="RFC4566"></xref>, which is commonly used to describe RTP
sessions. When SDP is used to specify sessions employing the GSM-HR
codec, the mapping is as follows: <list style="symbols">
<t>The media type ("audio") goes in SDP "m=" as the media
name.</t>
<t>The media subtype (payload format name) goes in SDP "a=rtpmap"
as the encoding name. The RTP clock rate in "a=rtpmap" MUST be
8000, and the encoding parameters (number of channels) MUST either
be explicitly set to 1 or omitted, implying a default value of
1.</t>
<t>The parameters "ptime" and "maxptime" go in the SDP "a=ptime"
and "a=maxptime" attributes, respectively.</t>
<t>Any remaining parameters go in the SDP "a=fmtp" attribute by
copying them directly from the media type parameter string as a
semicolon-separated list of parameter=value pairs.</t>
</list></t>
<section title="Offer/Answer Considerations">
<t>The following considerations apply when using SDP Offer-Answer
procedures to negotiate the use of GSM-HR payload in RTP: <list
hangIndent="" style="symbols">
<t>The SDP offerer and answerer MUST generate GSM-HR packets as
described by the offered parameters.</t>
<t>In most cases, the parameters "maxptime" and "ptime" will not
affect interoperability; however, the setting of the parameters
can affect the performance of the application. The SDP offer-
answer handling of the "ptime" parameter is described in <xref
target="RFC3264"></xref>. The "maxptime" parameter MUST be
handled in the same way.</t>
<t>The parameter "max-red" is a stream property parameter. For
sendonly or sendrecv unicast media streams, the parameter
declares the limitation on redundancy that the stream sender
will use. For recvonly streams, it indicates the desired value
for the stream sent to the receiver. The answerer MAY change the
value, but is RECOMMENDED to use the same limitation as the
offer declares. In the case of multicast, the offerer MAY
declare a limitation; this SHALL be answered using the same
value. A media sender using this payload format is RECOMMENDED
to always include the "max-red" parameter. This information is
likely to simplify the media stream handling in the receiver.
This is especially true if no redundancy will be used, in which
case "max-red" is set to 0.</t>
<t>Any unknown media type parameter in an offer SHALL be removed
in the answer.</t>
</list></t>
</section>
<section title="Declarative SDP Considerations">
<t>In declarative usage, like SDP in RTSP <xref
target="RFC2326"></xref> or SAP <xref target="RFC2974"></xref>, the
parameters SHALL be interpreted as follows: <list style="symbols">
<t>The stream property parameter ("max-red") is declarative, and
a participant MUST follow what is declared for the session. In
this case it means that the receiver MUST be prepared to
allocate buffer memory for the given redundancy. Any
transmissions MUST NOT use more redundancy then what has been
declared. More than one configuration may be provided if
necessary by declaring multiple RTP payload types; however, the
number of types should be kept small.</t>
<t>Any "maxptime" and "ptime" values should be selected with
care to ensure that the session's participants can achieve
reasonable performance.</t>
</list></t>
</section>
</section>
</section>
<section title="IANA Considerations">
<t>One media type (audio/gsm-hr-08) has been defined and needs
registration in the media types registry; see <xref
target="sec-media-type"></xref>.</t>
</section>
<section anchor="sec-congestion" title="Congestion Control">
<t>The general congestion control considerations for transporting RTP
data apply; see RTP <xref target="RFC3550"></xref> and any applicable
RTP profile like AVP <xref target="RFC3551"></xref>.</t>
<t>The number of frames encapsulated in each RTP payload highly
influences the overall bandwidth of the RTP stream due to header
overhead constraints. Packetizing more frames in each RTP payload can
reduce the number of packets sent and hence the header overhead, at the
expense of increased delay and reduced error robustness. If forward
error correction (FEC) is used, the amount of FEC-induced redundancy
needs to be regulated such that the use of FEC itself does not cause a
congestion problem.</t>
</section>
<section anchor="sec-sec" title="Security Considerations">
<t>RTP packets using the payload format defined in this specification
are subject to the general security considerations discussed in RTP
<xref target="RFC3550"></xref> and any applicable profile such as AVP
<xref target="RFC3551"></xref> or SAVP <xref target="RFC3711"></xref>.
As this format transports encoded audio, the main security issues
include confidentiality, integrity protection, and data origin
authentication of the audio itself. The payload format itself does not
have any built-in security mechanisms. Any suitable external mechanisms,
such as SRTP <xref target="RFC3711"></xref>, MAY be used.</t>
<t>This payload format and the GSM-HR decoder do not exhibit any
significant non-uniformity in the receiver-side computational complexity
for packet processing, and thus are unlikely to pose a denial-of-service
threat due to the receipt of pathological data. The payload format or
the codec data does not contain any type of active content such as
scripts.</t>
<section title="Confidentiality">
<t>In order to ensure confidentiality of the encoded audio, all audio
data bits MUST be encrypted. There is less need to encrypt the payload
header or the table of contents since they only carry information
about the frame type. This information could also be useful to a third
party, for example, for quality monitoring.</t>
</section>
<section title="Authentication and Integrity">
<t>To authenticate the sender of the audio-stream, an external
mechanism MUST be used. It is RECOMMENDED that such a mechanism
protects both the complete RTP header and the payload (audio and data
bits). Data tampering by a man-in-the-middle attacker could replace
audio content and also result in erroneous depacketization/decoding
that could lower the audio quality.</t>
</section>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>The author would like to thank Xiaodong Duan, Shuaiyu Wang, Rocky
Wang and Ying Zhang for their initial work in this area. Many thanks
also go to Tomas Frankkila, Karl Hellwig for useful input and
comments.</t>
</section>
</middle>
<back>
<references title="Informative References">
<?rfc include='reference.RFC.2198'?>
<?rfc include='reference.RFC.2326'?>
<?rfc include='reference.RFC.2974'?>
<?rfc include='reference.RFC.3711'?>
<?rfc include='reference.RFC.4288'?>
<?rfc include='reference.RFC.4855'?>
<?rfc include='reference.RFC.5109'?>
</references>
<references title="Normative References">
<reference anchor="TS46.002">
<front>
<title>Specification : 3GPP TS 46.002
http://www.3gpp.org/ftp/Specs/archive/46_series/46.002/46002-700.zip</title>
<author fullname="">
<organization>3GPP</organization>
</author>
<date day="1" month="June" year="2007" />
</front>
</reference>
<reference anchor="TS46.020">
<front>
<title>Specification : 3GPP TS 46.020
http://www.3gpp.org/ftp/Specs/archive/46_series/46.002/46020-700.zip</title>
<author fullname="">
<organization>3GPP</organization>
</author>
<date day="1" month="June" year="2007" />
</front>
</reference>
<?rfc include="reference.RFC.2119"?>
<?rfc include='reference.RFC.3264'?>
<?rfc include='reference.RFC.3550'?>
<?rfc include='reference.RFC.3551'?>
<?rfc include='reference.RFC.4566'?>
<?rfc include='reference.I-D.ietf-tsvwg-udp-guidelines'?>
</references>
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-24 05:45:16 |