draft-ietf-avt-rtp-gsm-hr-03.txt   rfc5993.txt 
Network Working Group X. Duan Internet Engineering Task Force (IETF) X. Duan
Internet-Draft S. Wang Request for Comments: 5993 S. Wang
Intended status: Standards Track China Mobile Communications Category: Standards Track China Mobile Communications Corporation
Expires: July 25, 2010 Corporation ISSN: 2070-1721 M. Westerlund
M. Westerlund
K. Hellwig K. Hellwig
I. Johansson I. Johansson
Ericsson AB Ericsson AB
January 21, 2010 October 2010
RTP Payload format for GSM-HR RTP Payload Format for
draft-ietf-avt-rtp-gsm-hr-03 Global System for Mobile Communications Half Rate (GSM-HR)
Abstract Abstract
This document specifies the payload format for packetization of the This document specifies the payload format for packetization of
GSM Half-Rate speech codec data into the Real-time Transport Protocol Global System for Mobile Communications Half Rate (GSM-HR) speech
(RTP). The payload format supports transmission of multiple frames codec data into the Real-time Transport Protocol (RTP). The payload
per payload and packet loss robustness methods using redundancy. format supports transmission of multiple frames per payload and
packet loss robustness methods using redundancy.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and 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 Status of This Memo
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 This is an Internet Standards Track document.
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at This document is a product of the Internet Engineering Task Force
http://www.ietf.org/shadow.html. (IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on July 25, 2010. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc5993.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions Used in This Document . . . . . . . . . . . . . . 3
3. GSM Half Rate . . . . . . . . . . . . . . . . . . . . . . . . 3 3. GSM Half Rate . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Payload format Capabilities . . . . . . . . . . . . . . . . . 4 4. Payload Format Capabilities . . . . . . . . . . . . . . . . . 4
4.1. Use of Forward Error Correction (FEC) . . . . . . . . . . 4 4.1. Use of Forward Error Correction (FEC) . . . . . . . . . . 4
5. Payload format . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Payload Format . . . . . . . . . . . . . . . . . . . . . . . . 5
5.1. RTP Header Usage . . . . . . . . . . . . . . . . . . . . . 6 5.1. RTP Header Usage . . . . . . . . . . . . . . . . . . . . . 6
5.2. Payload Structure . . . . . . . . . . . . . . . . . . . . 6 5.2. Payload Structure . . . . . . . . . . . . . . . . . . . . 6
5.2.1. Encoding of Speech Frames . . . . . . . . . . . . . . 8 5.2.1. Encoding of Speech Frames . . . . . . . . . . . . . . 8
5.2.2. Encoding of Silence Description Frames . . . . . . . . 8 5.2.2. Encoding of Silence Description Frames . . . . . . . . 8
5.3. Implementation Considerations . . . . . . . . . . . . . . 8 5.3. Implementation Considerations . . . . . . . . . . . . . . 8
5.3.1. Transmission of SID frames . . . . . . . . . . . . . . 8 5.3.1. Transmission of SID Frames . . . . . . . . . . . . . . 8
5.3.2. Receiving Redundant Frames . . . . . . . . . . . . . . 8 5.3.2. Receiving Redundant Frames . . . . . . . . . . . . . . 8
5.3.3. Decoding Validation . . . . . . . . . . . . . . . . . 8 5.3.3. Decoding Validation . . . . . . . . . . . . . . . . . 9
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.1. 3 frames . . . . . . . . . . . . . . . . . . . . . . . . . 9 6.1. 3 Frames . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.2. 3 Frames with lost frame in the middle . . . . . . . . . . 10 6.2. 3 Frames with Lost Frame in the Middle . . . . . . . . . . 11
7. Payload Format Parameters . . . . . . . . . . . . . . . . . . 10 7. Payload Format Parameters . . . . . . . . . . . . . . . . . . 11
7.1. Media Type Definition . . . . . . . . . . . . . . . . . . 11 7.1. Media Type Definition . . . . . . . . . . . . . . . . . . 12
7.2. Mapping to SDP . . . . . . . . . . . . . . . . . . . . . . 12 7.2. Mapping to SDP . . . . . . . . . . . . . . . . . . . . . . 13
7.2.1. Offer/Answer Considerations . . . . . . . . . . . . . 13 7.2.1. Offer/Answer Considerations . . . . . . . . . . . . . 14
7.2.2. Declarative SDP Considerations . . . . . . . . . . . . 13 7.2.2. Declarative SDP Considerations . . . . . . . . . . . . 14
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
9. Congestion Control . . . . . . . . . . . . . . . . . . . . . . 14 9. Congestion Control . . . . . . . . . . . . . . . . . . . . . . 15
10. Security Considerations . . . . . . . . . . . . . . . . . . . 14 10. Security Considerations . . . . . . . . . . . . . . . . . . . 15
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
12.1. Normative References . . . . . . . . . . . . . . . . . . . 15 12.1. Normative References . . . . . . . . . . . . . . . . . . . 16
12.2. Informative References . . . . . . . . . . . . . . . . . . 16 12.2. Informative References . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
This document specifies the payload format for packetization of GSM This document specifies the payload format for packetization of GSM
Half Rate (GSM-HR) codec [TS46.002] encoded speech signals into the Half Rate (GSM-HR) codec [TS46.002] encoded speech signals into the
Real-time Transport Protocol (RTP) [RFC3550]. The payload format Real-time Transport Protocol (RTP) [RFC3550]. The payload format
supports transmission of multiple frames per payload and packet loss supports transmission of multiple frames per payload and packet loss
robustness methods using redundancy. robustness methods using redundancy.
This document starts with conventions, a brief description of the This document starts with conventions, a brief description of the
codec, and the payload formats capabilities. The payload format is codec, and payload format capabilities. The payload format is
specified in Section 5. Examples can be found in Section 6. The specified in Section 5. Examples can be found in Section 6. The
media type and its mappings to SDP, usage in SDP offer/answer is then media type specification and its mappings to SDP, and considerations
specified. The document ends with considerations around congestion when using the Session Description Protocol (SDP) offer/answer
control and security. procedures are then specified. The document ends with considerations
related to congestion control and security.
This document registers a media type (audio/gsm-hr-08) for the Real- This document registers a media type (audio/GSM-HR-08) for the Real-
time Transport protocol (RTP) payload format for the GSM-HR codec. time Transport Protocol (RTP) payload format for the GSM-HR codec.
Note: This format is not compatible with the one that was drafted Note: This format is not compatible with the one provided back in
back in 1999 to 2000 in the Internet drafts: 1999 to 2000 in early draft versions of what was later published as
draft-ietf-avt-profile-new-05 to draft-ietf-avt-profile-new-09. A RFC 3551. RFC 3551 was based on a later version of the Audio-Visual
later version of the AVP profile draft was published as RFC 3551 Profile (AVP) draft, which did not provide any specification of the
without any specification of the GSM-HR payload format. To avoid a GSM-HR payload format. To avoid a possible conflict with this older
possible conflict with this older format, the media type of the format, the media type of the payload format specified in this
payload format specified in this document has a media type name that document has a media type name that is different from (audio/GSM-HR).
is different from (audio/gsm-hr).
2. Conventions 2. Conventions Used in This Document
This document uses the normal IETF bit-order representation. Bit This document uses the normal IETF bit-order representation. Bit
fields in figures are read left to right and then down. The left fields in figures are read left to right and then down. The leftmost
most bit in each field is the most significant. The numbering starts bit in each field is the most significant. The numbering starts from
from 0 and ascends, where bit 0 will be the most significant. 0 and ascends, where bit 0 will be the most significant.
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].
3. GSM Half Rate 3. GSM Half Rate
The Global System for Mobile Communication (GSM) network provides The Global System for Mobile Communications (GSM) network provides
with mobile communication services for nearly 3 billion users (status with mobile communication services for nearly 3 billion users
2008). The GSM Half Rate Codec (GSM-HR) is one of the speech codecs (statistics as of 2008). The GSM Half Rate (GSM-HR) codec is one of
that are used in GSM networks. GSM-HR denotes the Half-Rate speech the speech codecs used in GSM networks. GSM-HR denotes the Half Rate
codec as specified in [TS46.002]. speech codec as specified in [TS46.002].
Note: for historical reasons these 46-series specifications are Note: For historical reasons, these 46-series specifications are
internally referenced as 06-series. A simple mapping applies, for internally referenced as 06-series. A simple mapping applies; for
example 46.020 is referenced as 06.20 and so on. example, 46.020 is referenced as 06.20, and so on.
The GSM-HR codec has a frame length of 20 ms, with narrowband speech 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 sampled at 8000 Hz, i.e., 160 samples per frame. Each speech frame
compressed into 112 bits of speech parameters, which is equivalent to is compressed into 112 bits of speech parameters, which is equivalent
a bit rate of 5.6 kbit/s. Speech pauses are detected by a to a bit rate of 5.6 kbit/s. Speech pauses are detected by a
standardized Voice Activity Detection (VAD). During speech pauses standardized Voice Activity Detection (VAD). During speech pauses,
the transmission of speech frames is inhibited. Silence Descriptor the transmission of speech frames is inhibited. Silence Descriptor
(SID) frames are transmitted at the end of a talk spurt and about (SID) frames are transmitted at the end of a talkspurt and about
every 480ms during speech pauses to allow for a decent Comfort Noise every 480 ms during speech pauses to allow for a decent comfort noise
(CN) quality at receiver side. (CN) quality on the receiver side.
The SID frame generation in the GSM radio network is determined by The SID frame generation in the GSM radio network is determined by
the GSM mobile station and the GSM radio subsystem. SID frames come the GSM mobile station and the GSM radio subsystem. SID frames come
during speech pauses in uplink from the mobile station about every during speech pauses in the uplink from the mobile station about
480ms. In downlink to the mobile station, when they are generated by every 480 ms. In the downlink to the mobile station, when they are
the encoder of the GSM radio subsystem, SID frames are sent every generated by the encoder of the GSM radio subsystem, SID frames are
20ms to the GSM base station, which then picks only one every 480ms sent every 20 ms to the GSM base station, which then picks only one
for downlink radio transmission. For other applications, like every 480 ms for downlink radio transmission. For other
transport over IP, it is more appropriate to send the SID frames less applications, like transport over IP, it is more appropriate to send
often than every 20ms, but 480 ms may be too sparse. We recommend as the SID frames less often than every 20 ms, but 480 ms may be too
a compromise that a GSM-HR encoder outside of the GSM radio network sparse. We recommend as a compromise that a GSM-HR encoder outside
(i.e. not in the GSM mobile station and not in the GSM radio of the GSM radio network (i.e., not in the GSM mobile station and not
subsystem, but for example in the media gateway of the core network) in the GSM radio subsystem, but, for example, in the media gateway of
should generate and send SID frames every 160ms. the core network) should generate and send SID frames every 160 ms.
4. Payload format Capabilities 4. Payload Format Capabilities
This RTP payload format carries one or more GSM-HR encoded frames, This RTP payload format carries one or more GSM-HR encoded frames --
either full voice or silence descriptor (SID), representing a mono either full voice or silence descriptor (SID) -- representing a mono
speech signal. To maintain synchronization or express not sent or speech signal. To maintain synchronization or to indicate unsent or
lost frames it has the capability to indicate No_Data frames. lost frames, it has the capability to indicate No_Data frames.
4.1. Use of Forward Error Correction (FEC) 4.1. Use of Forward Error Correction (FEC)
Generic forward error correction within RTP is defined, for example, Generic forward error correction within RTP is defined, for example,
in RFC 5109 [RFC5109]. Audio redundancy coding is defined in RFC in RFC 5109 [RFC5109]. Audio redundancy coding is defined in RFC
2198 [RFC2198]. Either scheme can be used to add redundant 2198 [RFC2198]. Either scheme can be used to add redundant
information to the RTP packet stream and make it more resilient to information to the RTP packet stream and make it more resilient to
packet losses, at the expense of a higher bit rate. Please see packet losses, at the expense of a higher bit rate. Please see
either RFCs for a discussion of the implications of the higher bit either RFC for a discussion of the implications of the higher bit
rate to network congestion. rate to network congestion.
In addition to these media-unaware mechanisms, this memo specifies an In addition to these media-unaware mechanisms, this memo specifies an
optional to use GSM-HR specific form of audio redundancy coding, optional-to-use GSM-HR-specific form of audio redundancy coding,
which may be beneficial in terms of packetization overhead. which may be beneficial in terms of packetization overhead.
Conceptually, previously transmitted transport frames are aggregated Conceptually, previously transmitted transport frames are aggregated
together with new ones. A sliding window can be used to group the together with new ones. A sliding window can be used to group the
frames to be sent in each payload. Figure 1 below shows an example. frames to be sent in each payload. Figure 1 below shows an example.
--+--------+--------+--------+--------+--------+--------+--------+-- --+--------+--------+--------+--------+--------+--------+--------+--
| f(n-2) | f(n-1) | f(n) | f(n+1) | f(n+2) | f(n+3) | f(n+4) | | 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-1) ---->
<----- p(n) -----> <----- p(n) ----->
<---- p(n+1) ----> <---- p(n+1) ---->
<---- p(n+2) ----> <---- p(n+2) ---->
<---- p(n+3) ----> <---- p(n+3) ---->
<---- p(n+4) ----> <---- p(n+4) ---->
skipping to change at page 5, line 19 skipping to change at page 5, line 16
| f(n-2) | f(n-1) | f(n) | f(n+1) | f(n+2) | f(n+3) | f(n+4) | | 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-1) ---->
<----- p(n) -----> <----- p(n) ----->
<---- p(n+1) ----> <---- p(n+1) ---->
<---- p(n+2) ----> <---- p(n+2) ---->
<---- p(n+3) ----> <---- p(n+3) ---->
<---- p(n+4) ----> <---- p(n+4) ---->
Figure 1: An example of redundant transmission Figure 1: An Example of Redundant Transmission
Here, each frame is retransmitted once in the following RTP payload 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- packet. f(n-2)...f(n+4) denote a sequence of audio frames, and
1)...p(n+4) a sequence of payload packets. p(n-1)...p(n+4) a sequence of payload packets.
The mechanism described does not really require signaling at the The mechanism described does not really require signaling at the
session setup. However, signalling has been defined to allow for the session setup. However, signaling has been defined to allow the
sender to voluntarily bounding the buffering and delay requirements. sender to voluntarily bound the buffering and delay requirements. If
If nothing is signalled the use of this mechanism is allowed and nothing is signaled, the use of this mechanism is allowed and
unbounded. For a certain timestamp, the receiver may receive unbounded. For a certain timestamp, the receiver may acquire
multiple copies of a frame containing encoded audio data. The cost multiple copies of a frame containing encoded audio data. The cost
of this scheme is bandwidth and the receiver delay necessary to allow of this scheme is bandwidth, and the receiver delay is necessary to
the redundant copy to arrive. allow the redundant copy to arrive.
This redundancy scheme provides a functionality similar to the one This redundancy scheme provides a functionality similar to the one
described in RFC 2198, but it works only if both original frames and described in RFC 2198, but it works only if both original frames and
redundant representations are GSM-HR frames. When the use of other redundant representations are GSM-HR frames. When the use of other
media coding schemes is desirable, one has to resort to RFC 2198. media coding schemes is desirable, one has to resort to RFC 2198.
The sender is responsible for selecting an appropriate amount of The sender is responsible for selecting an appropriate amount of
redundancy based on feedback about the channel conditions, e.g., in redundancy, based on feedback regarding the channel conditions, e.g.,
the RTP Control Protocol (RTCP) [RFC3550] receiver reports. The in the RTP Control Protocol (RTCP) [RFC3550] receiver reports. The
sender is also responsible for avoiding congestion, which may be sender is also responsible for avoiding congestion, which may be
exacerbated by redundancy (see Section 9 for more details). exacerbated by redundancy (see Section 9 for more details).
5. Payload format 5. Payload Format
The format of the RTP header is specified in [RFC3550]. This payload The format of the RTP header is specified in [RFC3550]. The payload
format uses the fields of the header in a manner consistent with that format described in this document uses the header fields in a manner
specification. consistent with that specification.
The duration of one speech frame is 20 ms. The sampling frequency is The duration of one speech frame is 20 ms. The sampling frequency is
8kHz, corresponding to 160 speech samples per frame. An RTP packet 8000 Hz, corresponding to 160 speech samples per frame. An RTP
may contain multiple frames of encoded speech or SID parameters. packet may contain multiple frames of encoded speech or SID
Each packet covers a period of one or more contiguous 20 ms frame parameters. Each packet covers a period of one or more contiguous
intervals. During silence periods no speech packets are sent, 20-ms frame intervals. During silence periods, no speech packets are
however SID packets are transmitted every now and then. sent; however, SID packets are transmitted every now and then.
To allow for error resiliency through redundant transmission, the To allow for error resiliency through redundant transmission, the
periods covered by multiple packets MAY overlap in time. A receiver periods covered by multiple packets MAY overlap in time. A receiver
MUST be prepared to receive any speech frame multiple times. A given 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 MUST NOT be encoded as a speech frame in one packet and as a
frame or as No_Data frame in another packet. Furthermore, a given SID frame or as a No_Data frame in another packet. Furthermore, a
frame MUST NOT be encoded with different voicing modes in different given frame MUST NOT be encoded with different voicing modes in
packets. different packets.
The rules regarding maximum payload size given in Section 3.2 of The rules regarding maximum payload size given in Section 3.2 of
[RFC5405] SHOULD be followed. [RFC5405] SHOULD be followed.
5.1. RTP Header Usage 5.1. RTP Header Usage
The RTP timestamp corresponds to the sampling instant of the first The RTP timestamp corresponds to the sampling instant of the first
sample encoded for the first frame in the packet. The timestamp sample encoded for the first frame in the packet. The timestamp
clock frequency SHALL be 8000 Hz. The timestamp is also used to clock frequency SHALL be 8000 Hz. The timestamp is also used to
recover the correct decoding order of the frames. recover the correct decoding order of the frames.
The RTP header marker bit (M) SHALL be set to 1 whenever the first 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 frame carried in the packet is the first frame in a talkspurt (see
definition of the talkspurt in section 4.1 of [RFC3551]). For all definition of the talkspurt in Section 4.1 of [RFC3551]). For all
other packets the marker bit SHALL be set to zero (M=0). other packets, the marker bit SHALL be set to zero (M=0).
The assignment of an RTP payload type for the format defined in this 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 memo is outside the scope of this document. The RTP profiles in use
currently mandates binding the payload type dynamically for this currently mandate binding the payload type dynamically for this
payload format. payload format.
The remaining RTP header fields are used as specified in RFC 3550 The remaining RTP header fields are used as specified in RFC 3550
[RFC3550]. [RFC3550].
5.2. Payload Structure 5.2. Payload Structure
The complete payload consists of a payload table of contents (ToC) The complete payload consists of a payload table of contents (ToC)
section, followed by speech data representing one or more speech section, followed by speech data representing one or more speech
frames, SID frames or No_Data frames. The following diagram shows frames, SID frames, or No_Data frames. The following diagram shows
the general payload format layout: the general payload format layout:
+-------------+------------------------- +-------------+-------------------------
| ToC section | speech data section ... | ToC section | speech data section ...
+-------------+----------------------- +-------------+-------------------------
Figure 2: General payload format layout Figure 2: General Payload Format Layout
Each ToC element is one octet and corresponds to one speech frame, Each ToC element is one octet and corresponds to one speech frame;
the number of ToC elements is thus equal to the number of speech the number of ToC elements is thus equal to the number of speech
frames (including SID frames and No_Data frames). Each ToC entry frames (including SID frames and No_Data frames). Each ToC entry
represents a consecutive speech or SID or No_Data frame. The represents a consecutive speech or SID or No_Data frame. The
timestamp value for ToC element (and corresponding speech frame data) timestamp value for ToC element (and corresponding speech frame data)
N within the payload is (RTP timestamp field + (N-1)*160) mod 2^32 . N within the payload is (RTP timestamp field + (N-1)*160) mod 2^32.
The format of the ToC element is as follows. The format of the ToC element is as follows.
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|F| FT |R R R R| |F| FT |R R R R|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Figure 3: The TOC element Figure 3: The TOC Element
F: Follow flag, 1 denotes that more ToC elements follow, 0 denotes F: Follow flag; 1 denotes that more ToC elements follow; 0 denotes
the last ToC element. the last ToC element.
R: Reserved bits, MUST be set to zero and MUST be ignored by R: Reserved bits; MUST be set to zero, and MUST be ignored by
receiver. receiver.
FT: Frame type FT: Frame type
000 = Good Speech frame 000 = Good Speech frame
001 = Reserved 001 = Reserved
010 = Good SID frame 010 = Good SID frame
011 = Reserved 011 = Reserved
100 = Reserved 100 = Reserved
101 = Reserved 101 = Reserved
110 = Reserved 110 = Reserved
111 = No_Data frame 111 = No_Data frame
The length of the payload data depends on the frame type: The length of the payload data depends on the frame type:
Good Speech frame: The 112 speech data bits are put in 14 octets. Good Speech frame: The 112 speech data bits are put in 14 octets.
Good SID frame: The 33 SID data bits are put in 14 octets, as in 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". the case of Speech frames, with the unused 79 bits all set to "1".
No data frame: Length of payload data is zero octets. No_Data frame: Length of payload data is zero octets.
Frames marked in the GSM radio subsystem as "Bad Speech frame", "Bad 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 SID frame", or "No_Data frame" are not sent in RTP packets, in order
save bandwidth. They are marked as "No_Data frame", if they occur 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 within an RTP packet that carries more than one speech frame, SID
frame or No_Data frame. frame, or No_Data frame.
5.2.1. Encoding of Speech Frames 5.2.1. Encoding of Speech Frames
The 112 bits of GSM-HR-coded speech (b1...b112) are defined in TS The 112 bits of GSM-HR-coded speech (b1...b112) are defined in TS
46.020, Annex B [TS46.020], in the order of occurrence. The first 46.020, Annex B [TS46.020], in their order of occurrence. The first
bit (b1) of the first parameter is placed in bit 0 (the MSB) of the bit (b1) of the first parameter is placed in the most significant bit
first octet (octet 1) of the payload field; the second bit is placed (MSB) (bit 0) of the first octet (octet 1) of the payload field; the
in bit 1 of the first octet and so on. The last bit (b112) is placed second bit is placed in bit 1 of the first octet; and so on. The
in the LSB (bit 7) of octet 14. last bit (b112) is placed in the least significant bit (LSB) (bit 7)
of octet 14.
5.2.2. Encoding of Silence Description Frames 5.2.2. Encoding of Silence Description Frames
The GSM-HR Codec applies a specific coding for silence periods in so 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 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 of speech frames by using only the first 33 bits for SID parameters
and by setting the remaining 79 bits all to "1". and by setting all of the remaining 79 bits to "1".
5.3. Implementation Considerations 5.3. Implementation Considerations
An application implementing this payload format MUST understand all An application implementing this payload format MUST understand all
the payload parameters that is defined in this specification. Any the payload parameters that are defined in this specification. Any
mapping of the parameters to a signaling protocol MUST support all mapping of the parameters to a signaling protocol MUST support all
parameters. So an implementation of this payload format in an parameters. So an implementation of this payload format in an
application using SDP is required to understand all the payload application using SDP is required to understand all the payload
parameters in their SDP-mapped form. This requirement ensures that parameters in their SDP-mapped form. This requirement ensures that
an implementation always can decide whether it is capable of an implementation always can decide whether it is capable of
communicating when the communicating entities support this version of communicating when the communicating entities support this version of
the specification. the specification.
5.3.1. Transmission of SID frames 5.3.1. Transmission of SID Frames
When using this RTP payload format the sender SHOULD generate and When using this RTP payload format, the sender SHOULD generate and
send SID frames every 160ms, i.e. every 8th frame, during silent send SID frames every 160 ms, i.e., every 8th frame, during silent
periods. Other SID transmission intervals may occur due to gateways periods. Other SID transmission intervals may occur due to gateways
to other systems that uses other transmission intervals. to other systems that use other transmission intervals.
5.3.2. Receiving Redundant Frames 5.3.2. Receiving Redundant Frames
The reception of redundant audio frames, i.e. more than one audio 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 frame from the same source for the same time slot, MUST be supported
by the implementation. by the implementation.
5.3.3. Decoding Validation 5.3.3. Decoding Validation
If the receiver finds a mismatch between the size of a received If the receiver finds a mismatch between the size of a received
payload and the size indicated by the ToC of the payload, the payload and the size indicated by the ToC of the payload, the
receiver SHOULD discard the packet. This is recommended because receiver SHOULD discard the packet. This is recommended, because
decoding a frame parsed from a payload based on erroneous ToC data decoding a frame parsed from a payload based on erroneous ToC data
could severely degrade the audio quality. could severely degrade the audio quality.
6. Examples 6. Examples
A few examples to highlight the payload format. A few examples below highlight the payload format.
6.1. 3 frames 6.1. 3 Frames
A basic example of the aggregation of 3 consecutive speech frames Below is a basic example of the aggregation of 3 consecutive speech
into a single frame. frames into a single packet.
The first 24 bits are ToC elements. The first 24 bits are ToC elements.
Bit 0 is '1' as another ToC element follow.
Bits 1..3 is 000 = Good speech frame Bit 0 is '1', as another ToC element follows.
Bits 4..7 is 0000 = Reserved Bits 1..3 are 000 = Good speech frame
Bits 8 is '1' as another ToC element follow. Bits 4..7 are 0000 = Reserved
Bits 9..11 is 000 = Good speech frame Bit 8 is '1', as another ToC element follows.
Bits 12..15 is 0000 = Reserved Bits 9..11 are 000 = Good speech frame
Bit 16 is '0', no more ToC element follows Bits 12..15 are 0000 = Reserved
Bits 17..19 is 000 = Good speech frame Bit 16 is '0'; no more ToC elements follow.
Bits 20..23 is 0000 = Reserved Bits 17..19 are 000 = Good speech frame
Bits 20..23 are 0000 = Reserved
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|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| |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| |b9 Frame 1 b40|
+ + + +
|b41 b72| |b41 b72|
+ + + +
skipping to change at page 10, line 5 skipping to change at page 11, line 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
|b9 Frame 3 b40| |b9 Frame 3 b40|
+ + + +
|b41 b72| |b41 b72|
+ + + +
|b73 b104| |b73 b104|
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|b105 b112| |b105 b112|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
6.2. 3 Frames with lost frame in the middle 6.2. 3 Frames with Lost Frame in the Middle
An example of payload carrying 3 frames where the middle one is Below is an example of a payload carrying 3 frames, where the middle
No_Data, for example due to loss prior to transmission by the RTP one is No_Data (for example, due to loss prior to transmission by the
source. RTP source).
The first 24 bits are ToC elements. The first 24 bits are ToC elements.
Bit 0 is '1' as another ToC element follow.
Bits 1..3 is 000 = Good speech frame Bit 0 is '1', as another ToC element follows.
Bits 4..7 is 0000 = Reserved Bits 1..3 are 000 = Good speech frame
Bits 8 is '1' as another ToC element follow. Bits 4..7 are 0000 = Reserved
Bits 9..11 is 111 = No_Data frame Bit 8 is '1', as another ToC element follows.
Bits 12..15 is 0000 = Reserved Bits 9..11 are 111 = No_Data frame
Bit 16 is '0', no more ToC element follows Bits 12..15 are 0000 = Reserved
Bits 17..19 is 000 = Good speech frame Bit 16 is '0'; no more ToC elements follow.
Bits 20..23 is 0000 = Reserved Bits 17..19 are 000 = Good speech frame
Bits 20..23 are 0000 = Reserved
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|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| |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| |b9 Frame 1 b40|
+ + + +
|b41 b72| |b41 b72|
+ + + +
skipping to change at page 10, line 45 skipping to change at page 11, line 46
|b25 Frame 3 b56| |b25 Frame 3 b56|
+ + + +
|b57 b88| |b57 b88|
+ +-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+
|b89 b112| |b89 b112|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
7. Payload Format Parameters 7. Payload Format Parameters
This RTP payload format is identified using the media type "audio/ This RTP payload format is identified using the media type "audio/
gsm-hr-08", which is registered in accordance with [RFC4855] and GSM-HR-08", which is registered in accordance with [RFC4855] and uses
using the template of [RFC4288]. Note: Media subtype names are case- [RFC4288] as a template. Note: Media subtype names are case-
insensitive. insensitive.
7.1. Media Type Definition 7.1. Media Type Definition
The media type for the GSM-HR codec is allocated from the IETF tree 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 since GSM-HR is a well-known speech codec. This media type
registration covers real-time transfer via RTP. The media subtype registration covers real-time transfer via RTP.
name contains "-08" to avoid potential conflict with any earlier
drafts of GSM-HR RTP payload types that aren't bit compatible.
Note, reception of any unspecified parameter MUST be ignored by the Note: Reception of any unspecified parameter MUST be ignored by the
receiver to ensure that additional parameters can be added in the receiver to ensure that additional parameters can be added in the
future. future.
Type name: audio Type name: audio
Subtype name: GSM-HR-08 Subtype name: GSM-HR-08
Required parameters: none Required parameters: none
Optional parameters: Optional parameters:
max-red: The maximum duration in milliseconds that elapses between max-red: The maximum duration in milliseconds that elapses between
the primary (first) transmission of a frame and any redundant the primary (first) transmission of a frame and any redundant
transmission that the sender will use. This parameter allows a transmission that the sender will use. This parameter allows a
receiver to have a bounded delay when redundancy is used. Allowed receiver to have a bounded delay when redundancy is used. Allowed
values are integers between 0 (no redundancy will be used) and values are integers between 0 (no redundancy will be used) and
65535. If the parameter is omitted, no limitation on the use of 65535. If the parameter is omitted, no limitation on the use of
redundancy is present. redundancy is present.
ptime: see [RFC4566]. ptime: See [RFC4566].
maxptime: see [RFC4566]. maxptime: See [RFC4566].
Encoding considerations: Encoding considerations:
This media type is framed and binary, see section 4.8 in RFC4288 This media type is framed and binary; see Section 4.8 of RFC 4288
[RFC4288]. [RFC4288].
Security considerations: Security considerations:
See Section 10 of RFCXXXX. See Section 10 of RFC 5993.
Interoperability considerations: Interoperability considerations:
Published specification: 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.
RFC XXXX, 3GPP TS 46.002 Published specifications:
RFC 5993, 3GPP TS 46.002
Applications that use this media type: Applications that use this media type:
Real-time audio applications like voice over IP and Real-time audio applications like voice over IP and
teleconference. teleconference.
Additional information: none Additional information: none
Person & email address to contact for further information: Person & email address to contact for further information:
Ingemar Johansson <ingemar.s.johansson@ericsson.com> Ingemar Johansson <ingemar.s.johansson@ericsson.com>
Intended usage: COMMON Intended usage: COMMON
Restrictions on usage: Restrictions on usage:
This media type depends on RTP framing, and hence is only defined This media type depends on RTP framing, and hence is only defined
for transfer via RTP [RFC3550]. Transport within other framing for transfer via RTP [RFC3550]. Transport within other framing
protocols is not defined at this time. protocols is not defined at this time.
Author: Authors:
Xiaodong Duan <duanxiaodong@chinamobile.com> Xiaodong Duan <duanxiaodong@chinamobile.com>
Shuaiyu Wang <wangshuaiyu@chinamobile.com> Shuaiyu Wang <wangshuaiyu@chinamobile.com>
Magnus Westerlund <magnus.westerlund@ericsson.com> Magnus Westerlund <magnus.westerlund@ericsson.com>
Ingemar Johansson <ingemar.s.johansson@ericsson.com> Ingemar Johansson <ingemar.s.johansson@ericsson.com>
Karl Hellwig <karl.hellwig@ericsson.com> Karl Hellwig <karl.hellwig@ericsson.com>
Change controller: Change controller:
IETF Audio/Video Transport working group delegated from the IESG. IETF Audio/Video Transport working group, delegated from the IESG.
7.2. Mapping to SDP 7.2. Mapping to SDP
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 GSM-HR codec, the mapping is used to specify sessions employing the GSM-HR codec, the mapping
is as follows: is 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.
skipping to change at page 13, line 14 skipping to change at page 14, line 19
o The parameters "ptime" and "maxptime" go in the SDP "a=ptime" and o The parameters "ptime" and "maxptime" go in the SDP "a=ptime" and
"a=maxptime" attributes, respectively. "a=maxptime" attributes, respectively.
o Any remaining parameters go in the SDP "a=fmtp" attribute by o Any remaining parameters go in the SDP "a=fmtp" attribute by
copying them directly from the media type parameter string as a copying them directly from the media type parameter string as a
semicolon-separated list of parameter=value pairs. semicolon-separated list of parameter=value pairs.
7.2.1. Offer/Answer Considerations 7.2.1. Offer/Answer Considerations
The following considerations apply when using SDP Offer-Answer The following considerations apply when using SDP offer/answer
procedures to negotiate the use of GSM-HR payload in RTP: procedures to negotiate the use of GSM-HR payload in RTP:
o The SDP offerer and answerer MUST generate GSM-HR packets as o The SDP offerer and answerer MUST generate GSM-HR packets as
described by the offered parameters. described by the offered parameters.
o In most cases, the parameters "maxptime" and "ptime" will not o In most cases, the parameters "maxptime" and "ptime" will not
affect interoperability; however, the setting of the parameters affect interoperability; however, the setting of the parameters
can affect the performance of the application. The SDP offer- can affect the performance of the application. The SDP offer/
answer handling of the "ptime" parameter is described in answer handling of the "ptime" parameter is described in
[RFC3264]. The "maxptime" parameter MUST be handled in the same [RFC3264]. The "maxptime" parameter MUST be handled in the same
way. way.
o The parameter "max-red" is a stream property parameter. For o The parameter "max-red" is a stream property parameter. For
sendonly or sendrecv unicast media streams, the parameter declares sendonly or sendrecv unicast media streams, the parameter declares
the limitation on redundancy that the stream sender will use. For the limitation on redundancy that the stream sender will use. For
recvonly streams, it indicates the desired value for the stream recvonly streams, it indicates the desired value for the stream
sent to the receiver. The answerer MAY change the value, but is sent to the receiver. The answerer MAY change the value, but is
RECOMMENDED to use the same limitation as the offer declares. In RECOMMENDED to use the same limitation as the offer declares. In
skipping to change at page 13, line 45 skipping to change at page 14, line 50
payload format is RECOMMENDED to always include the "max-red" payload format is RECOMMENDED to always include the "max-red"
parameter. This information is likely to simplify the media parameter. This information is likely to simplify the media
stream handling in the receiver. This is especially true if no stream handling in the receiver. This is especially true if no
redundancy will be used, in which case "max-red" is set to 0. redundancy will be used, in which case "max-red" is set to 0.
o Any unknown media type parameter in an offer SHALL be removed in o Any unknown media type parameter in an offer SHALL be removed in
the answer. the answer.
7.2.2. Declarative SDP Considerations 7.2.2. Declarative SDP Considerations
In declarative usage, like SDP in RTSP [RFC2326] or SAP [RFC2974], In declarative usage, like SDP in the Real Time Streaming Protocol
the parameters SHALL be interpreted as follows: (RTSP) [RFC2326] or the Session Announcement Protocol (SAP)
[RFC2974], the parameters SHALL be interpreted as follows:
o The stream property parameter ("max-red") is declarative, and a o The stream property parameter ("max-red") is declarative, and a
participant MUST follow what is declared for the session. In this participant MUST follow what is declared for the session. In this
case it means that the receiver MUST be prepared to allocate case, it means that the receiver MUST be prepared to allocate
buffer memory for the given redundancy. Any transmissions MUST buffer memory for the given redundancy. Any transmissions MUST
NOT use more redundancy then what has been declared. More than NOT use more redundancy than what has been declared. More than
one configuration may be provided if necessary by declaring one configuration may be provided if necessary by declaring
multiple RTP payload types; however, the number of types should be multiple RTP payload types; however, the number of types should be
kept small. kept small.
o Any "maxptime" and "ptime" values should be selected with care to o Any "maxptime" and "ptime" values should be selected with care to
ensure that the session's participants can achieve reasonable ensure that the session's participants can achieve reasonable
performance. performance.
8. IANA Considerations 8. IANA Considerations
One media type (audio/gsm-hr-08) has been defined and needs One media type (audio/GSM-HR-08) has been defined, and it has been
registration in the media types registry; see Section 7.1. registered in the media types registry; see Section 7.1.
9. Congestion Control 9. Congestion Control
The general congestion control considerations for transporting RTP The general congestion control considerations for transporting RTP
data apply; see RTP [RFC3550] and any applicable RTP profile like AVP data apply; see RTP [RFC3550] and any applicable RTP profiles, e.g.,
[RFC3551]. "RTP/AVP" [RFC3551].
The number of frames encapsulated in each RTP payload highly The number of frames encapsulated in each RTP payload highly
influences the overall bandwidth of the RTP stream due to header influences the overall bandwidth of the RTP stream due to header
overhead constraints. Packetizing more frames in each RTP payload overhead constraints. Packetizing more frames in each RTP payload
can reduce the number of packets sent and hence the header overhead, can reduce the number of packets sent and hence the header overhead,
at the expense of increased delay and reduced error robustness. If at the expense of increased delay and reduced error robustness. If
forward error correction (FEC) is used, the amount of FEC-induced forward error correction (FEC) is used, the amount of FEC-induced
redundancy needs to be regulated such that the use of FEC itself does redundancy needs to be regulated such that the use of FEC itself does
not cause a congestion problem. not cause a congestion problem.
10. Security Considerations 10. Security Considerations
RTP packets using the payload format defined in this specification RTP packets using the payload format defined in this specification
are subject to the security considerations discussed in the RTP are subject to the security considerations discussed in the RTP
specification [RFC3550] , and in any applicable RTP profile. The specification [RFC3550], and in any applicable RTP profile. The main
main security considerations for the RTP packet carrying the RTP security considerations for the RTP packet carrying the RTP payload
payload format defined within this memo are confidentiality, format defined within this memo are confidentiality, integrity, and
integrity and source authenticity. Confidentiality is achieved by source authenticity. Confidentiality is achieved by encryption of
encryption of the RTP payload. Integrity of the RTP packets through the RTP payload, and integrity of the RTP packets through a suitable
suitable cryptographic integrity protection mechanism. Cryptographic cryptographic integrity protection mechanism. A cryptographic system
system may also allow the authentication of the source of the may also allow the authentication of the source of the payload. A
payload. A suitable security mechanism for this RTP payload format suitable security mechanism for this RTP payload format should
should provide confidentiality, integrity protection and at least provide confidentiality, integrity protection, and at least source
source authentication capable of determining if an RTP packet is from authentication capable of determining whether or not an RTP packet is
a member of the RTP session or not. from a member of the RTP session.
Note that the appropriate mechanism to provide security to RTP and Note that the appropriate mechanism to provide security to RTP and
payloads following this memo may vary. It is dependent on the payloads following this may vary. It is dependent on the
application, the transport, and the signalling protocol employed. application, the transport, and the signaling protocol employed.
Therefore a single mechanism is not sufficient, although if suitable Therefore, a single mechanism is not sufficient, although if
the usage of SRTP [RFC3711] is recommended. Other mechanism that may suitable, the usage of the Secure Real-time Transport Protocol (SRTP)
be used are IPsec [RFC4301] and TLS [RFC5246] (RTP over TCP), but [RFC3711] is recommended. Other mechanisms that may be used are
also other alternatives may exist. IPsec [RFC4301] and Transport Layer Security (TLS) [RFC5246] (e.g.,
for RTP over TCP), but other alternatives may also exist.
This RTP payload format and its media decoder do not exhibit any This RTP payload format and its media decoder do not exhibit any
significant non-uniformity in the receiver-side computational significant non-uniformity in the receiver-side computational
complexity for packet processing, and thus are unlikely to pose a complexity for packet processing, and thus are unlikely to pose a
denial-of-service threat due to the receipt of pathological data. denial-of-service threat due to the receipt of pathological data; nor
Nor does the RTP payload format contain any active content. does the RTP payload format contain any active content.
11. Acknowledgements 11. Acknowledgements
The author would like to thank Xiaodong Duan, Shuaiyu Wang, Rocky The authors would like to thank Xiaodong Duan, Shuaiyu Wang, Rocky
Wang and Ying Zhang for their initial work in this area. Many thanks Wang, and Ying Zhang for their initial work in this area. Many
also go to Tomas Frankkila for useful input and comments. thanks also go to Tomas Frankkila for useful input and comments.
12. References 12. References
12.1. Normative References 12.1. Normative References
[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 H. Schulzrinne, "An Offer/Answer Model [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, with 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 S. Casner, "RTP Profile for Audio and [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and
Video Conferences with Minimal Control", STD 65, RFC 3551, Video Conferences with Minimal Control", STD 65,
July 2003. RFC 3551, July 2003.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006. Description Protocol", RFC 4566, July 2006.
[RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines [RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage
for Application Designers", BCP 145, RFC 5405, Guidelines for Application Designers", BCP 145, RFC 5405,
November 2008. November 2008.
[TS46.002] [TS46.002] 3GPP, "Half rate speech; Half rate speech processing
3GPP, "Specification : 3GPP TS 46.002 http://www.3gpp.org/ functions", 3GPP TS 46.002, June 2007, <http://
ftp/Specs/archive/46_series/46.002/46002-700.zip", www.3gpp.org/ftp/Specs/archive/46_series/46.002/
June 2007. 46002-700.zip>.
[TS46.020] [TS46.020] 3GPP, "Half rate speech; Half rate speech transcoding",
3GPP, "Specification : 3GPP TS 46.020 http://www.3gpp.org/ 3GPP TS 46.020, June 2007, <http://www.3gpp.org/ftp/
ftp/Specs/archive/46_series/46.002/46020-700.zip", Specs/archive/46_series/46.020/46020-700.zip>.
June 2007.
12.2. Informative References 12.2. Informative References
[RFC2198] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., [RFC2198] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V.,
Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse- Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse-
Parisis, "RTP Payload for Redundant Audio Data", RFC 2198, Parisis, "RTP Payload for Redundant Audio Data",
September 1997. RFC 2198, September 1997.
[RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time
Streaming Protocol (RTSP)", RFC 2326, April 1998. Streaming Protocol (RTSP)", RFC 2326, April 1998.
[RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session
Announcement Protocol", RFC 2974, October 2000. Announcement Protocol", RFC 2974, October 2000.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", Norrman, "The Secure Real-time Transport Protocol
RFC 3711, March 2004. (SRTP)", RFC 3711, March 2004.
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and
Registration Procedures", BCP 13, RFC 4288, December 2005. Registration Procedures", BCP 13, RFC 4288,
December 2005.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005. Internet Protocol", RFC 4301, December 2005.
[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.
[RFC5109] Li, A., "RTP Payload Format for Generic Forward Error [RFC5109] Li, A., "RTP Payload Format for Generic Forward Error
Correction", RFC 5109, December 2007. Correction", RFC 5109, December 2007.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
Authors' Addresses Authors' Addresses
Xiaodong Duan Xiaodong Duan
China Mobile Communications Corporation China Mobile Communications Corporation
53A, Xibianmennei Ave., Xuanwu District 53A, Xibianmennei Ave., Xuanwu District
Beijing, 100053 Beijing, 100053
P.R. China P.R. China
EMail: duanxiaodong@chinamobile.com
Phone:
Fax:
Email: duanxiaodong@chinamobile.com
URI:
Shuaiyu Wang Shuaiyu Wang
China Mobile Communications Corporation China Mobile Communications Corporation
53A, Xibianmennei Ave., Xuanwu District 53A, Xibianmennei Ave., Xuanwu District
Beijing, 100053 Beijing, 100053
P.R. China P.R. China
EMail: wangshuaiyu@chinamobile.com
Phone:
Fax:
Email: wangshuaiyu@chinamobile.com
URI:
Magnus Westerlund Magnus Westerlund
Ericsson AB Ericsson AB
Farogatan 6 Farogatan 6
Stockholm, SE-164 80 Stockholm, SE-164 80
Sweden Sweden
Phone: +46 8 719 0000 Phone: +46 8 719 0000
Fax: EMail: magnus.westerlund@ericsson.com
Email: magnus.westerlund@ericsson.com
URI:
Karl Hellwig Karl Hellwig
Ericsson AB Ericsson AB
Kackertstrasse 7-9 Ericsson Allee 1
52072 Aachen 52134 Herzogenrath
Germany Germany
Phone: +49 2407 575-2054 Phone: +49 2407 575-2054
Email: karl.hellwig@ericsson.com EMail: karl.hellwig@ericsson.com
Ingemar Johansson Ingemar Johansson
Ericsson AB Ericsson AB
Laboratoriegrand 11 Laboratoriegrand 11
SE-971 28 Lulea SE-971 28 Lulea
SWEDEN Sweden
Phone: +46 73 0783289 Phone: +46 73 0783289
Email: ingemar.s.johansson@ericsson.com EMail: ingemar.s.johansson@ericsson.com
 End of changes. 119 change blocks. 
299 lines changed or deleted 285 lines changed or added

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