RTP Payload Format for the Mixed Excitation Linear Prediction Enhanced (MELPe) Codec
Extracted elements (27)
In the MELPe bitstream, the most significant bits are designated as priority bits intended for greater protection in the underlying communications channel. For IP networks, such additional protection is irrelevant, but bitstreams are presented identically in IP networks for the convenience of interoperable gateway devices.
The alternate encoding names MELP2400, MELP1200, and MELP600 are preserved from early implementations that used these names to indicate both coder type and bitrate before the unified MELP name with 'bitrate' parameter was defined.
The 'ptime' parameter cannot be used to specify the MELPe operating mode because for certain values it is impossible to distinguish the mode (e.g., ptime=68 could mean one 67.5 ms frame or three 22.5 ms frames), requiring the explicit 'bitrate' parameter instead.
Early implementations used MELP2400, MELP1200, and MELP600 media type names to indicate both coder type and bitrate; these names are preserved in the registration. These names have been observed in systems that do not support dynamic frame-rate switching via the 'bitrate' parameter.
All MELPe frames in a single RTP packet MUST be of the same coder bitrate. Dynamic switching between frame rates within an RTP stream is only permitted if supported by both ends and reserved bits are filled in as per Table 7.
Applications SHOULD use one or more appropriate strong security mechanisms when using this RTP payload format, as security is the responsibility of the application using RTP rather than the payload format itself.
Applications that use RTP over UDP SHOULD implement their own congestion control above the UDP layer (RFC 8085) and MAY also implement a transport circuit breaker (RFC 8083).
Frames MUST NOT be split between RTP packets.
If the encoding name 'MELP' is received without a 'bitrate' parameter, the fixed coder bitrate of 2400 MUST be used. The alternate encoding names MELP2400, MELP1200, and MELP600 MUST NOT specify a 'bitrate' parameter.
In the Offer/Answer model, 'bitrate' is a bidirectional parameter and both sides MUST use a common 'bitrate' value or values. The initial bitrate used by both parties SHALL be the first bitrate specified in the answerer response.
It is RECOMMENDED that the number of frames contained within an RTP packet be consistent with the application; for real-time telephony, fewer frames per packet reduces delay, while bandwidth-constrained links may use more frames per packet.
Senders SHOULD NOT include more MELPe frames in a single RTP packet than will fit in the MTU of the RTP transport protocol.
The 'ptime' and 'maxptime' parameters SHALL use the nearest rounded-up ms integer packet duration, corresponding to values 23, 45, 68, 90, 112, 135, 156, and 180 ms for MELPe.
The RTP timestamp MUST be in units of 1/8000 of a second, matching the MELPe codec's 8 kHz sampling rate clock.
A MELPe RTP packet MAY consist of zero or more MELPe coder frames followed by zero or one MELPe comfort noise frame. The number of frames is determined by dividing total payload octets by expected octets per frame (7/11/7), noting the last frame may be a 2-octet comfort noise frame.
A MELPe RTP packet with no coder frame and no comfort noise frame MAY be sent periodically by an endpoint to indicate connectivity by an otherwise idle receiver.
MELPe comfort noise parameters use the MELPe 2400 bps frame structure: msvq[0] (LSF first stage) and gain[1] (second gain) carry actual noise descriptors (preferably averaged from previous frames), while all other parameters are set to 0 and the sync bit alternates.
MELPe media subtypes registered are: MELP (dynamic bitrate via 'bitrate' parameter), MELP2400, MELP1200, and MELP600. All are restricted to transfer via RTP framing only; transport within other framing protocols is not defined.
Packet loss concealment (PLC) for MELPe uses the pitch/voicing parameter encoding: a code value of 3 (bits P0 and P1 set to 1, bits P2-P6 set to 0) signals an erasure. For 1200 or 600 bps frames, the 2400 bps decoder is called three or four times respectively to cover the loss.
IANA has registered four audio media subtypes — MELP, MELP2400, MELP1200, and MELP600 — and added them to the 'RTP Payload Format media types' registry.
The use of VAD (Voice Activity Detection) in MELPe affects bitrate variability; implementors should consult RFC 6562 for guidance on the security considerations of variable bit rate audio with Secure RTP.
This RTP payload format and the MELPe decoder do not exhibit significant non-uniformity in receiver-side computational complexity for packet processing, making denial-of-service attacks via pathological data unlikely. The payload format also contains no active content.
Dynamic bitrate switching uses reserved bits RSVA, RSVB, RSVC in the last octet of each frame: 2400 bps = (0,0,N/A), 1200 bps = (1,0,0), 600 bps = (0,1,N/A), comfort noise = (1,0,1). If bitrate switching is not used, all reserved bits are encoded as 0 by the sender and ignored by the receiver.
The 1200 bps MELPe frame is 81 bits packed into 11 octets (with 7 unused/reserved bits). Bit B_01 is in the LSB of the first byte; the eleventh octet has RSVA, RSVB, RSVC, four RSV0 bits, and B_81.
The 2400 bps MELPe frame is 54 bits packed into 7 octets (with 2 unused/reserved bits RSVA, RSVB). Bit B_01 is placed in the LSB of the first byte with all other bits in sequence; the seventh octet holds bits B_49 to B_54 in its LSBs.
The 600 bps MELPe frame is 54 bits packed into 7 octets (with 2 unused/reserved bits RSVA, RSVB), identical octet layout to the 2400 bps frame but with different bitstream parameter assignments across 6 modes.
The MELPe comfort noise frame is 13 bits (LSF first stage 7 bits + gain second stage 5 bits + 1 SYNC bit) packed into 2 octets with 3 reserved bits (RSVA, RSVB, RSVC) in the MSBs of the second octet.