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)
AbstractThis 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.
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. 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
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). RFC2119]. 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.
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. 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.
--+--------+--------+--------+--------+--------+--------+--------+-- | 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). 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
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. 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]. +-------------+------------------------- | ToC section | speech data section ... +-------------+------------------------- Figure 2: General Payload Format Layout
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.
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.
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.
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 <email@example.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 <firstname.lastname@example.org> Shuaiyu Wang <email@example.com> Magnus Westerlund <firstname.lastname@example.org> Ingemar Johansson <email@example.com> Karl Hellwig <firstname.lastname@example.org> Change controller: IETF Audio/Video Transport working group, delegated from the IESG. 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.
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. 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. 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 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. Section 7.1. 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. 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.
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. [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.
[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>. [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.