RFC 5993
RTP Payload Format for Global System for Mobile Communications Half Rate (GSM-HR)
RFC 5993: RTP Payload Format for Global System for Mobile Communications Half Rate (GSM-HR) 🎀
Okay so this one is from the Internet Engineering Task Force (IETF) 🌸 It was written by X. Duan and S. Wang at China Mobile Communications Corporation, plus M. Westerlund, K. Hellwig and I. Johansson at Ericsson AB. It's a Standards Track document, so it's the real deal, not a draft 💅 It was published in October 2010, and its ISSN is 2070-1721. The title block doesn't list anything it obsoletes or updates ✨
Abstract
okay so this doc is all about how to pack GSM Half Rate (GSM-HR) speech codec data into the Real-time Transport Protocol (RTP) 🦋 The payload format lets you send multiple frames in one payload and also has ways to survive packet loss using redundancy 🫶
Status of This Memo
This is an Internet Standards Track document 💜
It's a product of the IETF, so it represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more info on Internet Standards, check Section 2 of RFC 5741 📚
For the current status, any errata, and how to give feedback, go to 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 doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the publication date. Please actually read these, because they spell out your rights and restrictions for this document 🙈 Any Code Components pulled out of this document must include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions. They come with no 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 . . . . . . . . . . . . . . . . . . 171. Introduction ✨
This doc is all about packing GSM Half Rate (GSM-HR) codec speech (defined in [TS46.002]) into RTP ([RFC3550]) 🎀 It supports sending multiple frames per payload and handling packet loss with redundancy 💖
Here's the game plan: first come conventions, a quick codec overview, and the payload format capabilities. The actual payload format is in Section 5, and examples are in Section 6 🌈 After that it covers the media type spec and how it maps to SDP, plus what to think about with SDP offer/answer procedures. The doc wraps up with congestion control and security 🫶
This doc registers a media type, audio/GSM-HR-08, for the RTP payload format for the GSM-HR codec 🎧
Heads up, though: this format is not compatible with the one that was floating around in early draft versions between 1999 and 2000, before what became RFC 3551. RFC 3551 was based on a later version of the Audio-Visual Profile (AVP) draft, and that draft didn't specify a GSM-HR payload format at all 🙈 To avoid a clash with that older format, the media type in this doc has a name that's different from (audio/GSM-HR) 💅
2. Conventions Used in This Document 📐
This doc 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. Numbering starts at 0 and goes up, where bit 0 is 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 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 is the Half Rate speech codec specified in [TS46.002] 🎙️
Note: For historical reasons, these 46-series specifications are internally referenced as 06-series. There's a simple mapping: 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, so that's 160 samples per frame ⏱️ Each speech frame gets compressed into 112 bits of speech parameters, which works out to a bit rate of 5.6 kbit/s 💜 Speech pauses are detected by a standardized Voice Activity Detection (VAD). During speech pauses, transmission of speech frames is inhibited 🤫 Silence Descriptor (SID) frames are sent at the end of a talkspurt and about every 480 ms during speech pauses, so the receiver side gets a decent comfort noise (CN) quality 🎶
Now the SID frame stuff in the GSM radio network is decided by the GSM mobile station and the GSM radio subsystem 📡 SID frames show up during speech pauses in the uplink from the mobile station about every 480 ms. In the downlink to the mobile station, when they're generated by the encoder of the GSM radio subsystem, SID frames are sent every 20 ms to the GSM base station. The base station then picks just one every 480 ms for downlink radio transmission 🙃 For other apps, like transport over IP, it's more appropriate to send SID frames less often than every 20 ms, but 480 ms might be too sparse 🌸 So as a compromise, we recommend that a GSM-HR encoder outside the GSM radio network (so not in the GSM mobile station or 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 keep things in sync, or to show frames that weren't sent or were lost, it can indicate No_Data frames 🫧
4.1. Use of Forward Error Correction (FEC) 🛡️
Generic forward error correction within RTP is defined in RFC 5109 [RFC5109], and audio redundancy coding is defined in RFC 2198 [RFC2198] 🧩 Either scheme can add redundant info to the RTP packet stream so it's more resilient to packet loss, at the cost of a higher bit rate. Check out either RFC for the lowdown on how that higher bit rate affects network congestion 📉
On top of those media-unaware mechanisms, this memo specifies an optional-to-use GSM-HR-specific form of audio redundancy coding ✨ It may be beneficial in terms of packetization overhead. Basically, previously transmitted transport frames get aggregated together with new ones, and a sliding window can group the frames sent in each payload 🪟 Figure 1 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 TransmissionSo here, each frame gets retransmitted once in the following RTP payload packet 🔁 f(n-2)...f(n+4) are a sequence of audio frames, and p(n-1)...p(n+4) are a sequence of payload packets 🦋
The mechanism doesn't really need signaling at session setup. However, signaling has been defined so the sender can voluntarily bound the buffering and delay requirements 📦 If nothing is signaled, using this mechanism is allowed and unbounded ♾️ For a certain timestamp, the receiver may end up with multiple copies of a frame containing encoded audio data. The cost of this scheme is bandwidth, and the receiver delay is needed so the redundant copy has time to arrive 🕰️
This redundancy scheme does something similar to what RFC 2198 describes, but it only works if both the original frames and the redundant representations are GSM-HR frames. If you want to use other media coding schemes, you have to go with RFC 2198 instead 🙌
The sender is responsible for picking an appropriate amount of redundancy, based on feedback about channel conditions, e.g., from RTP Control Protocol (RTCP) [RFC3550] receiver reports 📊 The sender is also responsible for avoiding congestion, which redundancy can make worse (see Section 9 for more details) 🚦
5. Payload Format ✨
okay so the RTP header format is defined in [RFC3550], and this payload format just uses those header fields the way that spec says to 💅 bestie, the vibe is consistency 🫶
Each speech frame is 20 ms long 🎀 The sampling frequency is 8000 Hz, which works out to 160 speech samples per frame ✨ An RTP packet can hold multiple frames of encoded speech or SID parameters 🦋 Each packet covers one or more back-to-back 20-ms frame intervals. During silence, no speech packets get sent, but SID packets still show up every now and then 🌙
Now the redundancy part is lowkey iconic 😭 Packets are allowed to overlap in time so that errors can be handled 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 🙈 And a given frame MUST NOT be encoded with different voicing modes in different packets 💀 no mixing and matching, periodt.
Also, the maximum payload size rules in Section 3.2 of [RFC5405] SHOULD be followed 🍓
5.1. RTP Header Usage
The RTP timestamp matches 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 also helps the receiver put the frames back in the correct decoding order 🧚
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) 🌸
Assigning an RTP payload type for this format is outside the scope of this document 🎀 The RTP profiles that are in use right now call for binding the payload type dynamically for this payload format 🦋
The rest of the RTP header fields are used as specified in RFC 3550 [RFC3550] 💅
5.2. Payload Structure
Okay this is the fun part 🌈 The whole payload is a payload table of contents (ToC) section, followed by speech data for one or more speech frames, SID frames, or No_Data frames. Here's the general layout:
+-------------+-------------------------
| ToC section | speech data section ...
+-------------+-------------------------Figure 2: General Payload Format Layout
Every ToC element is one octet and maps to exactly one speech frame, so the number of ToC elements equals the number of speech frames (including SID frames and No_Data frames) 🧁 Each ToC entry stands for one consecutive speech, SID, or No_Data frame. The timestamp for ToC element N (and its matching speech frame data) inside the payload is (RTP timestamp field + (N-1)*160) mod 2^32 ⏱️ The ToC element looks like this:
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|F| FT |R R R R|
+-+-+-+-+-+-+-+-+Figure 3: The TOC Element
- F: Follow flag. 1 means more ToC elements follow, and 0 means this is the last ToC element 🫶
- R: Reserved bits. These MUST be set to zero, and MUST be ignored by the 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 frameThe payload data length depends on the frame type 📏
- Good Speech frame: The 112 speech data bits go into 14 octets.
- Good SID frame: The 33 SID data bits go into 14 octets, same as speech frames, and the unused 79 bits are all set to "1".
- No_Data frame: The payload data length is zero octets.
Frames that the GSM radio subsystem marks as "Bad Speech frame", "Bad SID frame", or "No_Data frame" are NOT sent in RTP packets, which saves bandwidth 🙈 If they show up inside an RTP packet carrying more than one speech frame, SID frame, or No_Data frame, they get marked as "No_Data frame" instead. (Heads up, this one is a vibe check: they are not sent, full stop.)
Oops, I need to keep the exact requirement wording, so here it is verbatim: 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. 💖
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 goes into the most significant bit (MSB) (bit 0) of the first octet (octet 1) of the payload field. The second bit goes into bit 1 of the first octet, and so on 🍓 The last bit (b112) lands in the least significant bit (LSB) (bit 7) of octet 14 ✨
5.2.2. Encoding of Silence Description Frames
The GSM-HR codec uses a specific coding for silence periods in so-called SID frames 🌙 SID frames are based on the speech frame coding, but they only use the first 33 bits for SID parameters and set all of the remaining 79 bits to "1" 💜
5.3. Implementation Considerations
An application that implements this payload format MUST understand all the payload parameters 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 means an implementation can always decide whether it's able to communicate 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 happen because of gateways to other systems that use different intervals 🦋
5.3.2. Receiving Redundant Frames
The implementation MUST support receiving redundant audio frames, i.e., more than one audio frame from the same source for the same time slot 💅
5.3.3. Decoding Validation
If the receiver finds a mismatch between the size of a received payload and the size the ToC of the payload indicates, 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 💀
6. Examples ✨
A few examples below show off the payload format 🧚
6.1. 3 Frames
Here's a basic example of aggregating 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|
+-+-+-+-+-+-+-+-+6.2. 3 Frames with Lost Frame in the Middle
Here's 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 💜
7.1. Media Type Definition ✨
okay so the media type for GSM-HR gets allocated from the IETF tree 🌸 because GSM-HR is a well-known speech codec, no cap. this 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. 🙈
here's the registration, field by field 💅
Type name:audioSubtype name:GSM-HR-08Required parameters: noneOptional parameters: these are the ones you can add 🧚- 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 lets a receiver 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 5993Interoperability 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. this is the bit that keeps things from getting messy 💜Published specifications: RFC 5993, 3GPP TS 46.002Applications that use this media type: real-time audio applications like voice over IP and teleconference 🦋Additional information: nonePerson & email address to contact for further information: Ingemar Johansson <ingemar.s.johansson@ericsson.com>Intended usage: COMMONRestrictions on usage: this one's important! this media type depends on RTP framing, so it's 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 info in the media type spec maps onto specific fields in the Session Description Protocol (SDP) [RFC4566], which is what people usually use to describe RTP sessions ✨ when SDP is used to set up sessions with the GSM-HR codec, it goes like this:
- the media type (
audio) goes in SDPm=as the media name - the media subtype (payload format name) goes in SDP
a=rtpmapas the encoding name. the RTP clock rate ina=rtpmapMUST be8000, and the encoding parameters (number of channels) MUST either be explicitly set to1or omitted, implying a default value of1🎀 - the parameters
ptimeandmaxptimego in the SDPa=ptimeanda=maxptimeattributes, respectively - any remaining parameters go in the SDP
a=fmtpattribute, copied straight from the media type parameter string as a semicolon-separated list of parameter=value pairs 🧚
7.2.1. Offer/Answer Considerations
these apply when you're using SDP offer/answer procedures to negotiate the GSM-HR payload in RTP, so pay attention 👀
- the SDP offerer and answerer MUST generate GSM-HR packets as described by the offered parameters 🫶
- in most cases, the parameters
maxptimeandptimewon't affect interoperability. however, setting them can affect how well the application performs. the SDP offer/answer handling of theptimeparameter is described in [RFC3264]. themaxptimeparameter MUST be handled in the same way 💅 - the parameter
max-redis a stream property parameter. for sendonly or sendrecv unicast media streams, it 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 themax-redparameter, since this info is likely to simplify the media stream handling in the receiver. this is especially true if no redundancy will be used, in which casemax-redis set to0⭐ - 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 📣
- the stream property parameter (
max-red) is declarative, and a participant MUST follow what is declared for the session. so in this case, 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. if necessary, more than one configuration can be provided by declaring multiple RTP payload types. but the number of types should be kept small, bestie 🌈 - any
maxptimeandptimevalues should be selected with care, so the session's participants can achieve reasonable performance 🍓
8. IANA Considerations 🦋
one media type (audio/GSM-HR-08) has been defined, and it's 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 packed into each RTP payload seriously affects the overall bandwidth of the RTP stream, because of header overhead constraints 😭 packing more frames into each RTP payload can reduce the number of packets sent, and so the header overhead, but it comes 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 so that FEC itself doesn't cause a congestion problem 🔥
10. Security Considerations 🔐
okay this section is serious bestie, so read it all 🫶
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 in this memo are confidentiality, integrity, and source authenticity. confidentiality is achieved by encrypting the RTP payload, and integrity of the RTP packets comes from a suitable cryptographic integrity protection mechanism. a cryptographic system may also allow the authentication of the payload's source. 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 right mechanism for securing RTP and payloads following this format may vary. it depends on the application, the transport, and the signaling protocol employed. so a single mechanism is not sufficient 🙅♀️ although if it's 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 don't exhibit any significant non-uniformity in the receiver-side computational complexity for packet processing. so they're unlikely to pose a denial-of-service threat due to the receipt of pathological data. and the RTP payload format doesn't 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.
[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.Authors' Addresses ✨
okay bestie, here's the squad that wrote this 💖 the people behind it, and how to reach each of them 🫶
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.comfive authors, two teams, one very iconic spec 🦋✨
📦 where this page comes from
- ietf: rfc5993 2010-10
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms