summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc5993.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc5993.txt')
-rw-r--r--doc/rfc/rfc5993.txt1011
1 files changed, 1011 insertions, 0 deletions
diff --git a/doc/rfc/rfc5993.txt b/doc/rfc/rfc5993.txt
new file mode 100644
index 0000000..128f007
--- /dev/null
+++ b/doc/rfc/rfc5993.txt
@@ -0,0 +1,1011 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) X. Duan
+Request for Comments: 5993 S. Wang
+Category: Standards Track China Mobile Communications Corporation
+ISSN: 2070-1721 M. Westerlund
+ K. Hellwig
+ I. Johansson
+ Ericsson AB
+ October 2010
+
+
+ RTP Payload Format for
+ Global System for Mobile Communications Half Rate (GSM-HR)
+
+Abstract
+
+ This document specifies the payload format for packetization of
+ Global System for Mobile Communications Half Rate (GSM-HR) speech
+ codec data into the Real-time Transport Protocol (RTP). The payload
+ format supports transmission of multiple frames per payload and
+ packet loss robustness methods using redundancy.
+
+Status of This Memo
+
+ This is an Internet Standards Track document.
+
+ This document is a product of the Internet Engineering Task Force
+ (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.
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Duan, et al. Standards Track [Page 1]
+
+RFC 5993 RTP Payload Format for GSM-HR October 2010
+
+
+Copyright Notice
+
+ Copyright (c) 2010 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 2. Conventions Used in This Document . . . . . . . . . . . . . . 3
+ 3. GSM Half Rate . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 4. Payload Format Capabilities . . . . . . . . . . . . . . . . . 4
+ 4.1. Use of Forward Error Correction (FEC) . . . . . . . . . . 4
+ 5. Payload Format . . . . . . . . . . . . . . . . . . . . . . . . 5
+ 5.1. RTP Header Usage . . . . . . . . . . . . . . . . . . . . . 6
+ 5.2. Payload Structure . . . . . . . . . . . . . . . . . . . . 6
+ 5.2.1. Encoding of Speech Frames . . . . . . . . . . . . . . 8
+ 5.2.2. Encoding of Silence Description Frames . . . . . . . . 8
+ 5.3. Implementation Considerations . . . . . . . . . . . . . . 8
+ 5.3.1. Transmission of SID Frames . . . . . . . . . . . . . . 8
+ 5.3.2. Receiving Redundant Frames . . . . . . . . . . . . . . 8
+ 5.3.3. Decoding Validation . . . . . . . . . . . . . . . . . 9
+ 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
+ 6.1. 3 Frames . . . . . . . . . . . . . . . . . . . . . . . . . 10
+ 6.2. 3 Frames with Lost Frame in the Middle . . . . . . . . . . 11
+ 7. Payload Format Parameters . . . . . . . . . . . . . . . . . . 11
+ 7.1. Media Type Definition . . . . . . . . . . . . . . . . . . 12
+ 7.2. Mapping to SDP . . . . . . . . . . . . . . . . . . . . . . 13
+ 7.2.1. Offer/Answer Considerations . . . . . . . . . . . . . 14
+ 7.2.2. Declarative SDP Considerations . . . . . . . . . . . . 14
+ 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
+ 9. Congestion Control . . . . . . . . . . . . . . . . . . . . . . 15
+ 10. Security Considerations . . . . . . . . . . . . . . . . . . . 15
+ 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
+ 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
+ 12.1. Normative References . . . . . . . . . . . . . . . . . . . 16
+ 12.2. Informative References . . . . . . . . . . . . . . . . . . 17
+
+
+
+
+
+Duan, et al. Standards Track [Page 2]
+
+RFC 5993 RTP Payload Format for GSM-HR October 2010
+
+
+1. Introduction
+
+ This document specifies the payload format for packetization of GSM
+ Half Rate (GSM-HR) codec [TS46.002] encoded speech signals into the
+ Real-time Transport Protocol (RTP) [RFC3550]. The payload format
+ supports transmission of multiple frames per payload and packet loss
+ robustness methods using redundancy.
+
+ This document starts with conventions, a brief description of the
+ codec, and payload format capabilities. The payload format is
+ specified in Section 5. Examples can be found in Section 6. The
+ media type specification and its mappings to SDP, and considerations
+ when using the Session Description Protocol (SDP) offer/answer
+ 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-
+ time Transport Protocol (RTP) payload format for the GSM-HR codec.
+ Note: This format is not compatible with the one provided back in
+ 1999 to 2000 in early draft versions of what was later published as
+ RFC 3551. RFC 3551 was based on a later version of the Audio-Visual
+ Profile (AVP) draft, which did not provide 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).
+
+2. Conventions Used in This Document
+
+ This document uses the normal IETF bit-order representation. Bit
+ fields in figures are read left to right and then down. The leftmost
+ bit in each field is the most significant. The numbering starts from
+ 0 and ascends, where bit 0 will be the most significant.
+
+ 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].
+
+3. GSM Half Rate
+
+ The Global System for Mobile Communications (GSM) network provides
+ with mobile communication services for nearly 3 billion users
+ (statistics as of 2008). The GSM Half Rate (GSM-HR) codec is one of
+ the speech codecs used in GSM networks. GSM-HR denotes the Half Rate
+ speech codec as specified in [TS46.002].
+
+ 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.
+
+
+
+Duan, et al. Standards Track [Page 3]
+
+RFC 5993 RTP Payload Format for GSM-HR October 2010
+
+
+ The GSM-HR codec has a frame length of 20 ms, with narrowband speech
+ sampled at 8000 Hz, 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 talkspurt and about
+ every 480 ms during speech pauses to allow for a decent comfort noise
+ (CN) quality on the receiver side.
+
+ 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 the uplink from the mobile station about
+ every 480 ms. In the downlink to the mobile station, when they are
+ generated by the encoder of the GSM radio subsystem, SID frames are
+ sent every 20 ms to the GSM base station, which then picks only one
+ every 480 ms for downlink radio transmission. For other
+ applications, like transport over IP, it is more appropriate to send
+ the SID frames less often than every 20 ms, 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 every 160 ms.
+
+4. Payload Format Capabilities
+
+ 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 to indicate unsent or
+ lost frames, it has the capability to indicate No_Data frames.
+
+4.1. Use of Forward Error Correction (FEC)
+
+ Generic forward error correction within RTP is defined, for example,
+ in RFC 5109 [RFC5109]. Audio redundancy coding is defined in RFC
+ 2198 [RFC2198]. 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 RFC for a discussion of the implications of the higher bit
+ rate to network congestion.
+
+ 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. Figure 1 below shows an example.
+
+
+
+
+Duan, et al. Standards Track [Page 4]
+
+RFC 5993 RTP Payload Format for GSM-HR October 2010
+
+
+ --+--------+--------+--------+--------+--------+--------+--------+--
+ | 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) ---->
+
+ Figure 1: An Example of Redundant Transmission
+
+ 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.
+
+ The mechanism described does not really require signaling at the
+ session setup. However, signaling has been defined to allow the
+ sender to voluntarily bound the buffering and delay requirements. If
+ nothing is signaled, the use of this mechanism is allowed and
+ unbounded. For a certain timestamp, the receiver may acquire
+ multiple copies of a frame containing encoded audio data. The cost
+ of this scheme is bandwidth, and the receiver delay is necessary to
+ allow the redundant copy to arrive.
+
+ 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.
+
+ The sender is responsible for selecting an appropriate amount of
+ redundancy, based on feedback regarding the channel conditions, e.g.,
+ in the RTP Control Protocol (RTCP) [RFC3550] receiver reports. The
+ sender is also responsible for avoiding congestion, which may be
+ exacerbated by redundancy (see Section 9 for more details).
+
+5. Payload Format
+
+ The format of the RTP header is specified in [RFC3550]. The payload
+ format described in this document uses the header fields in a manner
+ consistent with that specification.
+
+ The duration of one speech frame is 20 ms. The sampling frequency is
+ 8000 Hz, 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
+
+
+
+
+Duan, et al. Standards Track [Page 5]
+
+RFC 5993 RTP Payload Format for GSM-HR October 2010
+
+
+ 20-ms frame intervals. During silence periods, no speech packets are
+ sent; however, SID packets are transmitted every now and then.
+
+ 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 a speech frame in one packet and as a
+ SID frame or as a No_Data frame in another packet. Furthermore, a
+ given frame MUST NOT be encoded with different voicing modes in
+ different packets.
+
+ The rules regarding maximum payload size given in Section 3.2 of
+ [RFC5405] SHOULD be followed.
+
+5.1. RTP Header Usage
+
+ 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.
+
+ 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 [RFC3551]). For all
+ 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
+ memo is outside the scope of this document. The RTP profiles in use
+ currently mandate binding the payload type dynamically for this
+ payload format.
+
+ The remaining RTP header fields are used as specified in RFC 3550
+ [RFC3550].
+
+5.2. Payload Structure
+
+ 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:
+
+ +-------------+-------------------------
+ | ToC section | speech data section ...
+ +-------------+-------------------------
+
+ Figure 2: General Payload Format Layout
+
+
+
+
+
+Duan, et al. Standards Track [Page 6]
+
+RFC 5993 RTP Payload Format for GSM-HR October 2010
+
+
+ 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
+ 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 element (and corresponding speech frame data)
+ N within the payload is (RTP timestamp field + (N-1)*160) mod 2^32.
+ The format of the ToC element is as follows.
+
+ 0 1 2 3 4 5 6 7
+ +-+-+-+-+-+-+-+-+
+ |F| FT |R R R R|
+ +-+-+-+-+-+-+-+-+
+
+ Figure 3: The TOC Element
+
+ F: Follow flag; 1 denotes that more ToC elements follow; 0 denotes
+ the last ToC element.
+
+ R: Reserved bits; MUST be set to zero, and MUST be ignored by
+ receiver.
+
+ FT: Frame type
+ 000 = Good Speech frame
+ 001 = Reserved
+ 010 = Good SID frame
+ 011 = Reserved
+ 100 = Reserved
+ 101 = Reserved
+ 110 = Reserved
+ 111 = No_Data frame
+
+ 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 SID frame: The 33 SID data bits are put in 14 octets, as in
+ the case of Speech frames, with the unused 79 bits all set to "1".
+
+ No_Data frame: Length of payload data is zero octets.
+
+ 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.
+
+
+
+
+
+
+Duan, et al. Standards Track [Page 7]
+
+RFC 5993 RTP Payload Format for GSM-HR October 2010
+
+
+5.2.1. Encoding of Speech Frames
+
+ The 112 bits of GSM-HR-coded speech (b1...b112) are defined in TS
+ 46.020, Annex B [TS46.020], in their order of occurrence. The first
+ bit (b1) of the first parameter is placed in the most significant bit
+ (MSB) (bit 0) 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 least significant bit (LSB) (bit 7)
+ of octet 14.
+
+5.2.2. Encoding of Silence Description Frames
+
+ 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 all of the remaining 79 bits to "1".
+
+5.3. Implementation Considerations
+
+ An application implementing this payload format MUST understand all
+ the payload parameters that are 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.
+
+5.3.1. Transmission of SID Frames
+
+ When using this RTP payload format, the sender SHOULD generate and
+ send SID frames every 160 ms, i.e., every 8th frame, during silent
+ periods. Other SID transmission intervals may occur due to gateways
+ to other systems that use other transmission intervals.
+
+5.3.2. Receiving Redundant Frames
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+Duan, et al. Standards Track [Page 8]
+
+RFC 5993 RTP Payload Format for GSM-HR October 2010
+
+
+5.3.3. Decoding Validation
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Duan, et al. Standards Track [Page 9]
+
+RFC 5993 RTP Payload Format for GSM-HR October 2010
+
+
+6. Examples
+
+ A few examples below highlight the payload format.
+
+6.1. 3 Frames
+
+ Below is a basic example of the aggregation of 3 consecutive speech
+ frames into a single packet.
+
+ The first 24 bits are ToC elements.
+
+ Bit 0 is '1', as another ToC element follows.
+ Bits 1..3 are 000 = Good speech frame
+ Bits 4..7 are 0000 = Reserved
+ Bit 8 is '1', as another ToC element follows.
+ Bits 9..11 are 000 = Good speech frame
+ Bits 12..15 are 0000 = Reserved
+ Bit 16 is '0'; no more ToC elements follow.
+ Bits 17..19 are 000 = Good speech frame
+ Bits 20..23 are 0000 = Reserved
+
+ 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|
+ +-+-+-+-+-+-+-+-+
+
+
+
+Duan, et al. Standards Track [Page 10]
+
+RFC 5993 RTP Payload Format for GSM-HR October 2010
+
+
+6.2. 3 Frames with Lost Frame in the Middle
+
+ Below is an example of a payload carrying 3 frames, where the middle
+ one is No_Data (for example, due to loss prior to transmission by the
+ RTP source).
+
+ The first 24 bits are ToC elements.
+
+ Bit 0 is '1', as another ToC element follows.
+ Bits 1..3 are 000 = Good speech frame
+ Bits 4..7 are 0000 = Reserved
+ Bit 8 is '1', as another ToC element follows.
+ Bits 9..11 are 111 = No_Data frame
+ Bits 12..15 are 0000 = Reserved
+ Bit 16 is '0'; no more ToC elements follow.
+ Bits 17..19 are 000 = Good speech frame
+ Bits 20..23 are 0000 = Reserved
+
+
+ 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|
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+7. Payload Format Parameters
+
+ This RTP payload format is identified using the media type "audio/
+ GSM-HR-08", which is registered in accordance with [RFC4855] and uses
+ [RFC4288] as a template. Note: Media subtype names are case-
+ insensitive.
+
+
+
+
+
+
+Duan, et al. Standards Track [Page 11]
+
+RFC 5993 RTP Payload Format for GSM-HR October 2010
+
+
+7.1. Media Type Definition
+
+ The media type for the GSM-HR codec is allocated from the IETF tree,
+ since GSM-HR is a well-known speech codec. This media type
+ registration covers real-time transfer via RTP.
+
+ Note: Reception of any unspecified parameter MUST be ignored by the
+ receiver to ensure that additional parameters can be added in the
+ future.
+
+ Type name: audio
+
+ Subtype name: GSM-HR-08
+
+ Required parameters: none
+
+ Optional parameters:
+
+ 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 integers between 0 (no redundancy will be used) and
+ 65535. If the parameter is omitted, no limitation on the use of
+ redundancy is present.
+
+ ptime: See [RFC4566].
+
+ maxptime: See [RFC4566].
+
+ Encoding considerations:
+
+ This media type is framed and binary; see Section 4.8 of RFC 4288
+ [RFC4288].
+
+ Security considerations:
+
+ See Section 10 of RFC 5993.
+
+ Interoperability considerations:
+
+ 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.
+
+
+
+
+
+
+
+Duan, et al. Standards Track [Page 12]
+
+RFC 5993 RTP Payload Format for GSM-HR October 2010
+
+
+ Published specifications:
+
+ RFC 5993, 3GPP TS 46.002
+
+ Applications that use this media type:
+
+ Real-time audio applications like voice over IP and
+ teleconference.
+
+ Additional information: none
+
+ Person & email address to contact for further information:
+
+ Ingemar Johansson <ingemar.s.johansson@ericsson.com>
+
+ Intended usage: COMMON
+
+ Restrictions on usage:
+
+ This media type depends on RTP framing, and hence is only defined
+ for transfer via RTP [RFC3550]. Transport within other framing
+ protocols is not defined at this time.
+
+ Authors:
+
+ Xiaodong Duan <duanxiaodong@chinamobile.com>
+
+ Shuaiyu Wang <wangshuaiyu@chinamobile.com>
+
+ Magnus Westerlund <magnus.westerlund@ericsson.com>
+
+ Ingemar Johansson <ingemar.s.johansson@ericsson.com>
+
+ Karl Hellwig <karl.hellwig@ericsson.com>
+
+ Change controller:
+
+ IETF Audio/Video Transport working group, delegated from the IESG.
+
+7.2. Mapping to SDP
+
+ 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 GSM-HR codec, the mapping
+ is as follows:
+
+ o The media type ("audio") goes in SDP "m=" as the media name.
+
+
+
+Duan, et al. Standards Track [Page 13]
+
+RFC 5993 RTP Payload Format for GSM-HR October 2010
+
+
+ o 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.
+
+ o The parameters "ptime" and "maxptime" go in the SDP "a=ptime" and
+ "a=maxptime" attributes, respectively.
+
+ o 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.
+
+7.2.1. Offer/Answer Considerations
+
+ The following considerations apply when using SDP offer/answer
+ procedures to negotiate the use of GSM-HR payload in RTP:
+
+ o The SDP offerer and answerer MUST generate GSM-HR packets as
+ described by the offered parameters.
+
+ o 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
+ [RFC3264]. The "maxptime" parameter MUST be handled in the same
+ way.
+
+ o 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.
+
+ o Any unknown media type parameter in an offer SHALL be removed in
+ the answer.
+
+7.2.2. Declarative SDP Considerations
+
+ In declarative usage, like SDP in the Real Time Streaming Protocol
+ (RTSP) [RFC2326] or the Session Announcement Protocol (SAP)
+ [RFC2974], the parameters SHALL be interpreted as follows:
+
+
+
+Duan, et al. Standards Track [Page 14]
+
+RFC 5993 RTP Payload Format for GSM-HR October 2010
+
+
+ o 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 than 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.
+
+ o Any "maxptime" and "ptime" values should be selected with care to
+ ensure that the session's participants can achieve reasonable
+ performance.
+
+8. IANA Considerations
+
+ One media type (audio/GSM-HR-08) has been defined, and it has been
+ registered in the media types registry; see Section 7.1.
+
+9. Congestion Control
+
+ The general congestion control considerations for transporting RTP
+ data apply; see RTP [RFC3550] and any applicable RTP profiles, e.g.,
+ "RTP/AVP" [RFC3551].
+
+ 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.
+
+10. Security Considerations
+
+ RTP packets using the payload format defined in this specification
+ are subject to the security considerations discussed in the RTP
+ specification [RFC3550], and in any applicable RTP profile. The main
+ security considerations for the RTP packet carrying the RTP payload
+ format defined within this memo are confidentiality, integrity, and
+ source authenticity. Confidentiality is achieved by encryption of
+ the RTP payload, and integrity of the RTP packets through a suitable
+ cryptographic integrity protection mechanism. A cryptographic system
+ may also allow the authentication of the source of the payload. A
+ suitable security mechanism for this RTP payload format should
+ provide confidentiality, integrity protection, and at least source
+ authentication capable of determining whether or not an RTP packet is
+ from a member of the RTP session.
+
+
+
+Duan, et al. Standards Track [Page 15]
+
+RFC 5993 RTP Payload Format for GSM-HR October 2010
+
+
+ Note that the appropriate mechanism to provide security to RTP and
+ payloads following this may vary. It is dependent on the
+ application, the transport, and the signaling protocol employed.
+ Therefore, a single mechanism is not sufficient, although if
+ suitable, the usage of the Secure Real-time Transport Protocol (SRTP)
+ [RFC3711] is recommended. Other mechanisms that may be used are
+ 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
+ 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; nor
+ does the RTP payload format contain any active content.
+
+11. Acknowledgements
+
+ The authors 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 for useful input and comments.
+
+12. References
+
+12.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
+ with Session Description Protocol (SDP)", RFC 3264,
+ June 2002.
+
+ [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.
+
+ [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
+ Description Protocol", RFC 4566, July 2006.
+
+ [RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage
+ Guidelines for Application Designers", BCP 145, RFC 5405,
+ November 2008.
+
+
+
+
+
+Duan, et al. Standards Track [Page 16]
+
+RFC 5993 RTP Payload Format for GSM-HR October 2010
+
+
+ [TS46.002] 3GPP, "Half rate speech; Half rate speech processing
+ functions", 3GPP TS 46.002, June 2007, <http://
+ www.3gpp.org/ftp/Specs/archive/46_series/46.002/
+ 46002-700.zip>.
+
+ [TS46.020] 3GPP, "Half rate speech; Half rate speech transcoding",
+ 3GPP TS 46.020, June 2007, <http://www.3gpp.org/ftp/
+ Specs/archive/46_series/46.020/46020-700.zip>.
+
+12.2. Informative References
+
+ [RFC2198] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V.,
+ Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse-
+ Parisis, "RTP Payload for Redundant Audio Data",
+ RFC 2198, September 1997.
+
+ [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time
+ Streaming Protocol (RTSP)", RFC 2326, April 1998.
+
+ [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session
+ Announcement Protocol", RFC 2974, October 2000.
+
+ [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
+ Norrman, "The Secure Real-time Transport Protocol
+ (SRTP)", RFC 3711, March 2004.
+
+ [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and
+ Registration Procedures", BCP 13, RFC 4288,
+ December 2005.
+
+ [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
+ Internet Protocol", RFC 4301, December 2005.
+
+ [RFC4855] Casner, S., "Media Type Registration of RTP Payload
+ Formats", RFC 4855, February 2007.
+
+ [RFC5109] Li, A., "RTP Payload Format for Generic Forward Error
+ Correction", RFC 5109, December 2007.
+
+ [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
+ (TLS) Protocol Version 1.2", RFC 5246, August 2008.
+
+
+
+
+
+
+
+
+
+
+Duan, et al. Standards Track [Page 17]
+
+RFC 5993 RTP Payload Format for GSM-HR October 2010
+
+
+Authors' Addresses
+
+ Xiaodong Duan
+ China Mobile Communications Corporation
+ 53A, Xibianmennei Ave., Xuanwu District
+ Beijing, 100053
+ P.R. China
+ EMail: duanxiaodong@chinamobile.com
+
+
+ Shuaiyu Wang
+ China Mobile Communications Corporation
+ 53A, Xibianmennei Ave., Xuanwu District
+ Beijing, 100053
+ P.R. China
+ EMail: wangshuaiyu@chinamobile.com
+
+
+ Magnus Westerlund
+ Ericsson AB
+ Farogatan 6
+ Stockholm, SE-164 80
+ Sweden
+ Phone: +46 8 719 0000
+ EMail: magnus.westerlund@ericsson.com
+
+
+ Karl Hellwig
+ Ericsson AB
+ Ericsson Allee 1
+ 52134 Herzogenrath
+ Germany
+ Phone: +49 2407 575-2054
+ EMail: karl.hellwig@ericsson.com
+
+
+ Ingemar Johansson
+ Ericsson AB
+ Laboratoriegrand 11
+ SE-971 28 Lulea
+ Sweden
+ Phone: +46 73 0783289
+ EMail: ingemar.s.johansson@ericsson.com
+
+
+
+
+
+
+
+
+Duan, et al. Standards Track [Page 18]
+