RFC 5686
RTP Payload Format for mU-law EMbedded Codec for Low-delay IP Communication (UEMCLIP) Speech Codec
RTP Payload Format for mU-law EMbedded Codec for Low-delay IP Communication (UEMCLIP) Speech Codec 🎀
okay bestie, the title block first 💅 This is RFC 5686, from the Network Working Group, dated October 2009. The authors are Y. Hiwasaki and H. Ohmuro, both at NTT Corporation. It's a Standards Track doc, and the title block has no Obsoletes or Updates lines, so it doesn't list anything it replaces or changes 🦋
Abstract ✨
okay so this doc describes the RTP payload format for UEMCLIP (mU-law EMbedded Coder for Low-delay IP communication), which is an upgraded version of the ITU-T G.711 speech codec 🌸 The bitstream is scalable and has an embedded u-law bitstream inside it (aka PCMU), so transcoding between narrowband and wideband speech is super handy 💖
Status of This Memo 🌈
this doc is an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 🫶 For the current standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 🍓
Copyright Notice 💜
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
ngl this part is legal stuff, but it matters 🙈 The 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 stood on the publication date. Read those carefully, because they spell out your rights and restrictions for this doc. Code Components pulled out of this doc must include the Simplified BSD License text described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as the BSD License says.
This doc may include material from IETF Documents or IETF Contributions published or publicly available before November 10, 2008. The people controlling the copyright in some of that material may not have given the IETF Trust permission to allow modifications outside the IETF Standards Process. So unless you get an adequate license from those copyright holders, this doc may not be modified outside the IETF Standards Process, and derivative works may not be made outside it either. The only exceptions are formatting it for publication as an RFC or translating it into languages other than English 💅
Table of Contents 🧚
1. Introduction ....................................................2
1.1. Terminology ................................................3
2. Media Format Background .........................................3
3. Payload Format ..................................................5
3.1. RTP Header Usage ...........................................6
3.2. Multiple Frames in an RTP Packet ...........................6
3.3. Payload Data ...............................................7
3.3.1. Main Header .........................................7
3.3.2. Sub-Layer ..........................................10
4. Transcoding between UEMCLIP and G.711 ..........................11
5. Congestion Control Considerations ..............................12
6. Payload Format Parameters ......................................13
6.1. Media Type Registration ...................................13
6.2. Mapping to SDP Parameters .................................14
6.2.1. Mode Specification .................................15
6.3. Offer-Answer Model Considerations .........................16
6.3.1. Offer-Answer Guidelines ............................16
6.3.2. Examples ...........................................17
7. Security Considerations ........................................19
8. IANA Considerations ............................................19
9. References .....................................................19
9.1. Normative References ......................................19
9.2. Informative References ....................................201. Introduction 🦋
this doc is the payload format for sending UEMCLIP-encoded speech (mU-law EMbedded Coder for Low-delay IP communication) over the Real-time Transport Protocol (RTP) [RFC3550] 💖 UEMCLIP is a proprietary codec that improves on u-law ITU-T G.711 [ITU-T-G.711]. It's designed to help the market move smoothly toward the coming wideband communication world, while keeping the media transcoding load very small on existing terminals, which are required to implement G.711 ✨
Here's the thing: codecs usually get negotiated and changed through an SDP exchange 🌸 [RFC3550] also defines general RTP mixer and translator models, where media transcoding might not happen at the node. In those cases, the embedded structure isn't useful. But there are cases where costly transcoding is unavoidable, like commonly deployed Multi-point Control Units (MCUs) that terminate media and RTCP packets [RFC5117], and when narrowband and wideband terminals coexist. This embedded bitstream structure can cut media transcoding down to a simple bitstream truncation 🔥
Section 2 covers the background and basic idea of the media format, and Section 3 has the payload format details. Section 4 talks about transcoding issues with G.711, and Section 5 covers congestion control considerations. Section 6 has the payload format parameters for the UEMCLIP RTP payload format media type registration, plus the SDP mappings. Security considerations are in Section 7 and IANA considerations are in Section 8 🎀
1.1. Terminology 💅
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 [RFC2119] 🫶
2. Media Format Background 🌈
okay the background: UEMCLIP is an enhanced version of u-law ITU-T G.711, also known as PCMU [RFC4856] 👑 It's aimed at Voice over Internet Protocol (VoIP) apps. The main goal is to give a wideband communication platform that's highly interoperable with existing G.711 terminals, and to nudge the market to gradually shift to wideband 💖 In widely deployed multi-point conferencing systems, packets usually go through RTCP-terminating (RTP Control Protocol) MCUs, the "Topo-RTCP-terminating-MCU" from [RFC5117]. Since the G.711 bitstream is embedded in the bitstream, costly media transcoding can be avoided in this case 🦋
This doc doesn't cover the implementation details of the encoder and decoder. It only describes the bitstream format 🧚
Because it's scalable, a UEMCLIP bitstream has a bunch of sub-bitstreams (sub-layers). By picking the right sub-layers, the codec can adapt to these requirements:
- Sampling frequency,
- Number of channels,
- Speech quality, and
- Bit-rate.
The UEMCLIP codec runs on a 20-ms frame and has three sub-coders, as shown in Table 1. The core layer is u-law G.711 at 64 kbit/s, and the other two are quality and bandwidth enhancement layers, each at 16 kbit/s 🍓
+-------+---------------------+----------+--------------------------+
| Layer | Description | Bit-rate | Coding algorithm |
+-------+---------------------+----------+--------------------------+
| a | G.711 core | 64 | u-law PCM |
| | | | |
| b | Lower-band | 16 | Time domain block |
| | enhancement | | quantization |
| | | | |
| c | Higher-band | 16 | MDCT block quantization |
+-------+---------------------+----------+--------------------------+
Table 1: Sub-Layer DescriptionBased on these sub-layers, UEMCLIP works in four modes, as shown in Table 2 💜 Here "Ch" is the number of channels and "Fs" is the sampling frequency in kHz. The current version only supports single-channel operation, but future extensions might add multi-channel capabilities. Modes 2 and 5 are absent. They're reserved for possible future extension to 32 kHz sampling modes. Since the mode definition is expected to grow, any other modes not defined in this table MUST NOT be used, for compatibility and interoperability reasons 🙈
+------+----+----+-------+-------+-------+-------------+------------+
| Mode | Ch | Fs | Layer | Layer | Layer | Bit-rate | Total |
| | | | a | b | c | w/o headers | bit-rate |
| | | | | | | [kbit/s] | [kbit/s] |
+------+----+----+-------+-------+-------+-------------+------------+
| 0 | 1 | 8 | x | - | - | 64 | 67.2 |
| | | | | | | | |
| 1 | 1 | 16 | x | - | x | 80 | 84.0 |
| | | | | | | | |
| 2 | - | - | - | - | - | - | - |
| | | | | | | | |
| 3 | 1 | 8 | x | x | - | 80 | 84.0 |
| | | | | | | | |
| 4 | 1 | 16 | x | x | x | 96 | 100.8 |
| | | | | | | | |
| 5 | - | - | - | - | - | - | - |
+------+----+----+-------+-------+-------+-------------+------------+
Table 2: Mode DescriptionThe UEMCLIP bitstream also has internal headers and other side-information beyond the layer data. So the total bit-rate ends up bigger than the sum of the layers in the table above. The details of the internal headers and auxiliary info are in Section 3.3.1 ✨
Defining the sampling frequency and number of channels doesn't give you one single mode. There can be multiple modes for the same sampling frequency or channel count. The supported modes can differ between implementations, so the sender and the receiver must negotiate which mode to use for transmission 💖
part 1 of 4 is done bestie, part 2 is coming up next 🧚
3. Payload Format ✨
okay so, as an RTP payload, a UEMCLIP bitstream can carry one or more frames 🎀 Here's the layout:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP Header |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| |
| one or more frames of UEMCLIP |
| |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
Figure 1: RTP Payload Formatbestie, the UEMCLIP bitstream is scalable 🦋 which means you can rebuild the signal by decoding only a part of it, and that's so cool. A UEMCLIP frame is a main header (MH) followed by one or more (up to three) sub-layers (SLs) 💅
+--+-------+//-+
|MH| SL #1 |...|
+--+-------+//-+
Figure 2: A UEMCLIP Frame (Bitstream Format)the core layer, which is "Layer a", MUST always be included 👑 It should be noted that the core layer may or may not come right after the MH field, so don't assume it's always next. The decoder MUST always refer to the layer indices for proper decoding, because the sub-layers can show up in any order 🙈
The UEMCLIP bitstream does not explicitly include mode and sampling frequency (Fs). As described before, this information MUST be exchanged while establishing a connection, for example, by means of SDP 🌸
3.1. RTP Header Usage
every RTP packet starts with a fixed RTP header, as explained in [RFC3550]. These are the fields of the fixed header that get special treatment for UEMCLIP streams 🧚
Payload type: Assigning an RTP payload type for this packet format is outside the scope of this document. Still, it's expected that a payload type in the dynamic range shall be assigned.
Timestamp: This encodes the sampling instant of the first speech signal sample in the RTP data packet. For UEMCLIP streams, the RTP timestamp MUST advance based on a clock running at either 8000 or 16000 (Hz). If the audio sampling rate can change during a session, the RTP timestamp rate MUST be equal to the maximum rate (in Hz) given in the mode range (see Section 6.2.1). That means the RTP timestamp rate for the UEMCLIP payload type MUST NOT change during a session 😭 For example, a UEMCLIP stream with 8-kHz audio sampling, where a transition to a 16-kHz audio sampling mode is allowed, must always advance using the 16-kHz clock rate. For a fixed audio sampling mode, the RTP timestamp rate should be either 8 or 16 kHz, depending on the sampling rate.
Marker bit: If the codec is used for applications with discontinuous transmission (DTX, or silence compression), the first packet after a silence period during which packets have not been transmitted contiguously SHOULD have the marker bit in the RTP data header set to one. The marker bit in all other packets MUST be zero. Applications without DTX MUST set the marker bit to zero 🔥
3.2. Multiple Frames in an RTP Packet
a sender can put more than one UEMCLIP frame into a single RTP packet. Senders do have a few extra rules, though 💀
- A single RTP packet SHOULD NOT include more UEMCLIP frames than will fit in the path MTU.
- All frames contained in a single RTP packet MUST be of the same mode.
- Frames MUST NOT be split between RTP packets.
It is RECOMMENDED that the number of frames contained within an RTP packet be consistent with the application. UEMCLIP is built for telephony, where delay really affects quality, so fewer frames per packet for lower delay is the move 📞✨
3.3. Payload Data
in a UEMCLIP bitstream, all numbers are encoded in network byte order 🍓
3.3.1. Main Header
the main header (MH) sits at the top of a frame and is 6 bytes long. Here's what it looks like 🎀
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MX | PC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PC(cont'd) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: UEMCLIP Main Header Format (MH)Mixing information (MX): 8 bits
the mixing information field. It only matters when Topo-RTCP-terminating-MCUs are used to interpret these fields. Check Section 3.3.1.1 for the details of the fields ✨
Packet-loss Concealment information (PC): 40 bits
the packet-loss concealment (PLC) information field. See Section 3.3.1.2 💖
3.3.1.1. Mixing Information Field
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|C|R|V| PW1 |
|1|1|1| |
+-+-+-+-+-+-+-+-+
Figure 4: Mixing Information Field (MX)Check bit #1 (C1): 1 bit
this is the validity flag for V1 and PW1. A "1" means both parameters are valid, and a "0" means the parameters should be ignored. If any of these parameters is invalid, this bit should be set to "0". This flag is mainly for a UEMCLIP-conscious Topo-RTCP-terminating-MCU. It should be set to "0" when upward transcoding from G.711 (see Section 4) 🙌
Reserved bit #1 (R1): 1 bit
this bit should be ignored. Its default is 0.
VAD flag #1 (V1): 1 bit
the voice activity detection flag for the current frame, made for MCU operations. A "1" means the frame is an active (voice) segment, and a "0" means it's an inactive (non-voice) or silent segment. This flag is specifically designed for mixing information. DTX judgment based on this flag is not recommended 🌈
Power #1 (PW1): 5 bits
the signal power code for the current frame. You get it by calculating the root mean square (RMS) of "Layer a" and then encoding that RMS using G.711 u-law [ITU-T-G.711]. Say the encoded RMS is R. Then PW1 = ((~R)>>2) & 0x1F, where "~", ">>", and "&" are the one's complement arithmetic, right SHIFT, and bitwise AND operators, respectively 🧮
3.3.1.2. PLC Information Field
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C|R2 |V| K |U| P1 |U| P2 | PW2 |
|2| |2| |1| |2| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| R3 |
| |
+-+-+-+-+-+-+-+-+
Figure 5: PLC Information Field (PC)Check bit #2 (C2): 1 bit
this is the validity flag for V2, K, U1, P1, U2, P2, and PW2. A "1" means all of these parameters are valid, and a "0" means they should be ignored. If any of them is invalid, this bit should be set to "0". Same deal as C1: this flag should be set to "0" when upward transcoding from G.711 (see Section 4) 🫶
Reserved bits #2 (R2): 2 bits
these bits should be ignored. Their default is 0.
VAD flag #2 (V2): 1 bit
the voice activity detection flag for the current frame, made for packet-loss concealment. It might not match V1 in the mixing information, and it might not be synchronous with the RTP header marker bit. DTX judgment based on this flag is not recommended 👑
Frame indicator (K): 4 bits
this gives the frame offset for U2, P2, and PW2. Carrying speech feature parameters as PLC information in a different frame is a better idea for keeping speech quality up, so this offset tells you which frame those parameters belong to. The value ranges from "0" to "15". If the current frame number is N, then K = N-K means that U2, P2, and PW2 are associated with the frame of N-K. The frame indicator equals the difference in RTP sequence number when one UEMCLIP frame is contained in a single RTP packet 🦋
V/UV flag #1 (U1): 1 bit
the voiced/unvoiced signal indicator for the current frame. A "0" means the frame is a voiced signal segment, and a "1" means it's an unvoiced signal segment 🌸
Pitch lag #1 (P1): 7 bits
the pitch code for the current frame. The actual pitch lag is P1+20 samples at an 8-kHz sampling rate. The pitch lag must be 20 <= pitch length <= 120. Codes between "0x65" and "0x7F" are not used. To get the pitch lag, you can use any pitch estimation method, such as the one in G.711 Appendix I [ITU-T-G.711Appendix1] 🎀
V/UV flag #2 (U2): 1 bit
the voiced/unvoiced signal indicator for the offset frame. A "0" means the frame is a voiced signal segment, and a "1" means it's an unvoiced signal segment. The offset value is defined as K 🧚
Pitch lag #2 (P2): 7 bits
the pitch code for the offset frame. The offset value is defined as K. The calculation is identical to "P1", except it's based on the signal of the offset frame 💜
Power #2 (PW2): 8 bits
the signal power code for the offset frame. The offset value is defined as K 🍓
Reserved bits #3 (R3): 8 bits
these bits should be ignored. The default for all of the bits is "0" 🙈
3.3.2. Sub-Layer 🧚
Okay bestie, the sub-layer (SL) is a little sub-header followed by the layer bitstreams, as you can see in Figure 6 💖. The sub-header tells you where the layer lives and how many bytes it's carrying 🎀.
0 1 2
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 . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+//-+-+-+
|CI |FI |QI |R4 | SB | LD ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+//-+-+-+Figure 6: Sub-Layer Format (SL) 📐
Channel index (CI): 2 bits. This indicates the channel number. For all modes given in Table 2, this should be "0". The detail is given in Table 3 🔥.
Frequency index (FI): 2 bits. This indicates the frequency number. "0" means the layer is in the base frequency band, and a higher number means the layer is in the respective frequency band. The detail is given in Table 3 💅.
Quality index (QI): 2 bits. This indicates the quality layer number. "0" means the layer is in the base layer, and a higher number means the layer is in the respective quality layer. The detail is given in Table 3 ✨.
Reserved #4 (R4): 2 bits. Not used (reserved). The default value is "0" 🫶.
Sub-layer Size (SB): 8 bits. This indicates the byte size of the following sub-layer data 🍓.
Layer Data (LD): SB*8 bits. This is the actual sub-layer data 💜.
For all the layers shown in Table 1, the layer indices are shown in Table 3. Here they are, no cap 👑.
+-------+----+----+----+
| Layer | CI | FI | QI |
+-------+----+----+----+
| a | 0 | 0 | 0 |
| | | | |
| b | 0 | 0 | 1 |
| | | | |
| c | 0 | 1 | 0 |
+-------+----+----+----+Table 3: Layer Indices 🌈
4. Transcoding between UEMCLIP and G.711 🔥
As given in Section 2, the u-law-encoded G.711 bitstream (Layer a) is the core layer of a UEMCLIP bitstream, and it's always embedded. So transcoding from the UEMCLIP bitstream to G.711 doesn't have to go through decoding and re-encoding. Simple extraction would suffice 🦋. However, this does NOT apply to the reverse procedure (transcoding from G.711 to UEMCLIP), because the auxiliary information in the main header (MH) must be assigned separately 🙈.
It should be noted that this media transcoding is useful for a Media Translator (Topo-Media-Translator) or a Point-to-Multipoint Using RTCP Terminating MCU (Topo-RTCP-terminating-MCU) in [RFC5117], and all the requirements apply. This means that a transcoding device of this sort MUST rewrite RTCP packets, together with the RTP media packets 💖.
The transcoding from UEMCLIP to u-law G.711 can be done easily by finding an appropriate sub-layer. Within a frame, the transcoder should look for a sub-layer with a layer index of "0x00". The subsequent LD that has a size of SB*8 bits (UEMCLIP has a 20-ms frame, thus SB=160) is the actual G.711 bitstream data 🧁. It should be noted that the transcoder should not always expect the core layer to be located right after the main header 👀.
The other direction (transcoding from G.711 to UEMCLIP) is not entirely straightforward 😭. Since there are no means to generate enhancement sub-layers, a G.711 bitstream can only be converted to a UEMCLIP Mode 0 bitstream. If the original G.711 bitstream is encoded in A-law, it should first be converted to u-law to become the core layer. Because a UEMCLIP frame size is 20 ms, a u-law-encoded G.711 bitstream MUST be a 160-sample chunk to become a core layer 🎀. For the main header contents, when the UEMCLIP encoder is not available, it should follow these guidelines:
- The check bits for mixing and PLC (C1 and C2) are set to
0. - The reserved bits (R1 to R3) in MH are set to their respective default values.
For the core layer (i.e., u-law G.711 bitstream), it should have the following sub-layer header:
- All CI, FI, QI, and R4 MUST be
0. - Sub-layer size (SB) MUST be
160for a 20-ms frame.
5. Congestion Control Considerations 🌸
The general congestion control considerations for transporting RTP data also apply to UEMCLIP over RTP [RFC3550], as well as any applicable RTP profile like Audio-Visual Profile (AVP) [RFC3551]. Main character energy 👑.
The bandwidth of a UEMCLIP bitstream can be reduced by changing to lower-bit-rate modes. The embedded layer structure of UEMCLIP may help to control congestion when dynamic mode changing (see Section 6.2.1) is available, and the range of modes is obtained by offer-answer negotiation as given in Section 6.3. It should be noted that this involves proper RTCP handling when the bit-rate is modified in an RTP translator or a mixer [RFC3550] 💅.
Packing more frames in each RTP payload can reduce the number of packets sent, and hence the overhead from IP/UDP/RTP headers, at the expense of increased delay and reduced error robustness against packet losses. It should be treated with care, because increased delay means reduced quality 😭✨.
6. Payload Format Parameters 💜
6.1. Media Type Registration 🦋
This registration is done using the template defined in [RFC4288] and following [RFC4855] 🧚.
- Media type name: audio
- Media subtype name: UEMCLIP
- Required parameters:
- Rate: Defines the sampling rate, and it MUST be either 8000 or 16000. See Section 6.2.1 "Mode specification" of RFC 5686 (this RFC) for details 🔥.
- Optional parameters:
- ptime: See RFC 4566 [RFC4566].
- maxptime: See RFC 4566 [RFC4566].
- mode: Indicates the range of dynamically changeable modes during a session. Possible values are a comma-separated list of modes from the supported mode set: 0, 1, 3, and 4. If only one mode is specified, it means that the mode must not be changed during the session. When not specified, the mode transmission defaults to a singular mode as specified in Table 4. See Section 6.2.1 "Mode specification" of RFC 5686 (this RFC) for details 🌈.
- Encoding considerations: This media type is framed and contains binary data. See Section 4.8 of RFC 4288 📦.
- Security considerations: See Section 7 "Security Considerations" of RFC 5686 (this RFC) 🔐.
- Interoperability considerations: This media may be readily transcoded to u-law-encoded ITU-T G.711. See Section 4 "Transcoding between UEMCLIP and G.711" of RFC 5686 (this RFC) 🫶.
- Published specification: RFC 5686 (this RFC) 📜.
- Applications that use this media type: Audio and video streaming and conferencing tools 🎥.
- Additional information: None.
- Intended usage: COMMON.
- Restrictions on usage: This media type depends on RTP framing, and hence is only defined for transfer via RTP 💀.
- Person & email address to contact for further information: Yusuke Hiwasaki <hiwasaki.yusuke@lab.ntt.co.jp> 💌.
- Author: Yusuke Hiwasaki ✍️.
- Change Controller: IETF Audio/Video Transport Working Group, delegated from the IESG 🏛️.
6.2. Mapping to SDP Parameters 🎀
The media types audio/UEMCLIP are mapped to fields in the Session Description Protocol (SDP) [RFC4566] as follows 💖:
- Media name: The
"m="line of SDP MUST be audio. - Encoding name: Registered media subtype name should be used for the
"a=rtpmap"line. - Sampling Frequency: Depending on the mode, clock rate (sampling frequency) specified in
"a=rtpmap"MUST be selected from the ones defined in Table 2. See Section 6.2.1 for details 🔥. - Encoding parameters: Since this is an audio stream, the encoding parameters indicate the number of audio channels, and this SHOULD default to
"1", as selected from the ones defined in Table 2. This is OPTIONAL 🎧. - Packet time: A frame length of any UEMCLIP is 20 ms, thus the argument of
"a=ptime"SHOULD be a multiple of"20". When not listed in SDP, it should also default to the minimum size:"20"⏱️. - UMECLIP specific: Any description specific to UEMCLIP is defined in the Format Specification Parameters (
"a=fmtp"). Each parameter MUST be separated with";", and if any attribute (value) exists, it MUST be defined with"=". For compatibility reasons, any application/terminal MUST ignore any parameters that it does not understand. This is to ensure the upper-compatibility with parameters added in future enhancements. The mode specification should be made here (see Section 6.2.1) 🧠✨.
6.2.1. Mode Specification 🦋
Since the UEMCLIP codec can operate in a number of modes (bit-rates), it is desirable to specify the range of modes at which an encoder or a decoder can operate 🌸. When exchanging SDP messages, an offerer should specify all possible combinations of mode numbers as arguments to "mode=" in the "a=fmtp" line, delimited by commas ",". In case of specifying multiple modes, those SHOULD appear in descending priority order 🍓.
Although UEMCLIP decoders SHOULD accept bitstreams in any modes, an implementation may fail to adapt to dynamic mode changes during a session. For this reason, an application may choose to operate either with one fixed mode or with multiple modes that can be dynamically changed. If the mode is to be fixed and changes are not allowed, this can be indicated by specifying a single mode per payload type 🔒.
The mode numbers that can be specified in a payload type as arguments to "mode" are restricted by a combination of a clock rate and a number of audio channels. This is because SDP binds a payload type to a combination of a sampling frequency and a number of audio channels. Table 4 gives the selectable mode numbers that are attributed with clock rates. When mode specifications are not given at all, a payload type MUST default to a single mode using the default value specified in this table 📊.
+------------+----------+------------------+--------------+
| Clock rate | Channels | Selectable modes | Default mode |
+------------+----------+------------------+--------------+
| 8000 | 1 | 0,3 | 0 |
| | | | |
| 16000 | 1 | 0,1,3,4 | 1 |
+------------+----------+------------------+--------------+Table 4: Default Modes 💜
It should be noted that a mode attributed with a larger sampling frequency (Fs) is not used in conjunction with smaller clock rates specified in "a=rtpmap". This means that Modes 0 and 3 can be specified in a payload type having a clock rate of both 8000 and 16000 in "a=rtpmap", but Modes 1 and 4 cannot be specified with one having a clock rate of 8000 🙅♀️.
6.3. Offer-Answer Model Considerations ✨
6.3.1. Offer-Answer Guidelines 🫶
okay bestie, the offer/answer rules are where things get juicy 💅 first off, the whole SDP exchange MUST follow [RFC3264]. here's the detailed list of what the UEMCLIP payload format means in an offer-answer exchange 🎀
- an offerer SHOULD offer every possible combination of UEMCLIP payload type it can handle, i.e., sampling frequency, channel number, and fmtp parameters, in a preferred order. when the transmission bandwidth is restricted, it MUST be offered in accordance to the restriction.
- when multiple UEMCLIP payload types are offered, it is RECOMMENDED that the answerer select a single UEMCLIP payload type and answer it back.
- in a UEMCLIP payload type, an answerer MUST answer back suitable mode number(s) as a subset of what has been offered. this means there is a symmetry assumption on sent and received streams, and the offerer MUST NOT send in modes that it does not offer. symmetry era 🦋
- in an offering/answering SDP, any fmtp parameters that are not known MUST be ignored. if any unknown/undefined parameters should be offered, an answerer MUST delete the entry from the answer message. ✂️
- a receiver of an SDP message MUST only use specified payload types and modes. when a mode specification is missing, i.e., a mode is not specified at all, the session MUST default to one single mode without mode changes during a session. for this case, the default mode values, as shown in Table 4, MUST be used based on the sampling frequency and number of channels. this table must be looked up only when there are no mode specifications; thus, the offerer/answerer MUST NOT assume that the default modes are always available when it is not in the specified list of modes. do not assume the defaults, bestie 🙈
- when an offered condition does not fit an answerer's capabilities, it naturally MUST NOT answer any of the conditions, and the session MAY proceed to re-INVITE, if possible. if a condition (mode) is decided upon, an offerer and an answerer MUST transmit on this condition. 🔥
6.3.2. Examples ✨
okay so picture this: an offerer wants to dynamically switch between modes (0,1,3, and 4) during a session. the offered SDP could look like this 👑
v=0
o=john 51050101 51050101 IN IP4 offhost.example.com
s=-
c=IN IP4 offhost.example.com
t=0 0
m=audio 5004 RTP/AVP 96
a=rtpmap:96 UEMCLIP/16000/1
a=fmtp:96 mode=4,1,3,0it should be noted that the listed modes appear in the offerer's preference. the first one is the fave 💖
now say the answerer can only operate in Modes 1 and 0, but can dynamically switch between those modes during a session. the answerer MUST delete the entries of Mode 3 and 4, and answer back like this 🥹
v=0
o=lena 549947322 549947322 IN IP4 anshost.example.org
s=-
c=IN IP4 anshost.example.org
t=0 0
m=audio 5004 RTP/AVP 96
a=rtpmap:96 UEMCLIP/16000/1
a=fmtp:96 mode=1,0as a result, both would start communicating in either Mode 1 or 0, and can dynamically switch between those modes during the session. ⭐
on the other hand, when the answerer is capable of communicating either in Modes 1 or 0, and cannot switch between modes during a session, an example of such an answer is as follows 🌸
v=0
o=lena 549947322 549947322 IN IP4 anshost.example.org
s=-
c=IN IP4 anshost.example.org
t=0 0
m=audio 5004 RTP/AVP 96
a=rtpmap:96 UEMCLIP/16000/1
a=fmtp:96 mode=1as a result, both will start communicating in Mode 1. it should be noted that mode change during this session is not allowed because the answerer responded with a single mode, and the answerer selected Mode 1 above Mode 0 according to the offered order. no switching, periodt 🚫
if an offerer does not want a mode change during a session but is capable of receiving either Modes 4 or 1 bitstreams, the SDP should somewhat look like this 🧚
v=0
o=john 51050101 51050101 IN IP4 offhost.example.com
s=-
c=IN IP4 offhost.example.com
t=0 0
m=audio 5004 RTP/AVP 96 97
a=rtpmap:96 UEMCLIP/16000/1
a=fmtp:96 mode=4
a=rtpmap:97 UEMCLIP/16000/1
a=fmtp:97 mode=1and if the answerer prefers to communicate in Mode 1, the answer would be 💜
v=0
o=lena 549947322 549947322 IN IP4 anshost.example.org
s=-
c=IN IP4 anshost.example.org
t=0 0
m=audio 5004 RTP/AVP 97
a=rtpmap:97 UEMCLIP/16000/1
a=fmtp:97 mode=1please note that it is RECOMMENDED to select a single UEMCLIP payload type for answers. one payload type, slay 🍓
the "ptime" attribute is used to denote the desired packetization interval. when not specified, it SHOULD default to 20. since UEMCLIP uses 20-ms frames, ptime values of multiples of 20 imply multiple frames per packet. in the example below, the ptime is set to 60, and this means that the offerer wants to receive 3 frames in each packet. 🦋
v=0
o=kosuke 2890844730 2890844730 IN IP4 anotherhost.example.com
s=-
c=IN IP4 anotherhost.example.com
t=0 0
m=audio 5004 RTP/AVP 96
a=ptime:60
a=rtpmap:96 UEMCLIP/16000/1when mode specification is not present, it should default to a fixed mode, and in this case, Mode 1 (see Section 6.2.1). that's the whole offer-answer tea ☕
7. Security Considerations 🔐
okay bestie, security is serious business so let's be real about it 😭 RTP packets using the payload format defined in this specification are subject to the security considerations discussed in the RTP specification [RFC3550] and any appropriate profiles. this implies that confidentiality of the media streams is achieved by encryption unless the applicable profile specifies other means. 🔒
there's a potential denial-of-service threat for data encoding that uses compression techniques with non-uniform receiver-end computational load. an attacker can inject pathological datagrams into the stream that are complex to decode and cause the receiver output to become overloaded. however, the UEMCLIP covered in this document do not exhibit any significant non-uniformity. phew, no drama here 🙌
another potential threat is memory attacks by illegal layer indices or byte numbers. the implementor of the decoder should always be aware that the indicated numbers may be corrupted and not point to the right sub-layer, and they may force reading beyond the bitstream boundaries. it is advised that a decoder implementation reject layers of such indices. 🚨
8. IANA Considerations 🌈
one new media subtype (audio/UEMCLIP) has been registered by IANA. for details, see Section 6.1. 🎀
9. References 📚
9.1. Normative References
[ITU-T-G.711]International Telecommunications Union, "Pulse code modulation (PCM) of voice frequencies", ITU-T Recommendation G.711, November 1988.[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.[RFC4288]Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005.[RFC4566]Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.[RFC4855]Casner, S., "Media Type Registration of RTP Payload Formats", RFC 4855, February 2007.[RFC4856]Casner, S., "Media Type Registration of Payload Formats in the RTP Profile for Audio and Video Conferences", RFC 4856, February 2007.[RFC5117]Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117, January 2008.
9.2. Informative References
[ITU-T-G.711Appendix1]International Telecommunications Union, "Pulse code modulation (PCM) of voice frequencies, Appendix I: A high quality low-complexity algorithm for packet loss concealment with G.711", ITU-T Recommendation G.711 Appendix I, September 1999.
Authors' Addresses 💌
Yusuke Hiwasaki
NTT Corporation
3-9-11 Midori-cho,
Musashino-shi
Tokyo 180-8585
Japan
Phone: +81(422)59-4815
EMail: hiwasaki.yusuke@lab.ntt.co.jp
Hitoshi Ohmuro
NTT Corporation
3-9-11 Midori-cho,
Musashino-shi
Tokyo 180-8585
Japan
Phone: +81(422)59-2151
EMail: ohmuro.hitoshi@lab.ntt.co.jp📦 where this page comes from
- ietf: rfc5686 2009-10
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms