RTP Payload Format for MIDI
obsoleted by
- rfc-6295 — RTP Payload Format for MIDI
Extracted elements (30)
SysEx command cancellation is provided because session configuration tools may exclude certain SysEx commands from a stream; cancellation lets a sender start transmission before the full command arrives and abort it without a high-latency store-and-forward design. Without it, senders would be forced to buffer entire SysEx commands before transmitting.
The default 'comex' (COMmand EXecution) timestamp semantics treat each timestamp as the command execution time. This works well for transcoding Standard MIDI Files and for hardware controllers coding raw sensor data, but is usually not optimal for sources with implicit MIDI 1.0 DIN cable timing.
The payload format does not provide a general extension mechanism by design; instead, new payload formats are encouraged for specialized musical applications. IETF session management tools (RFC 3264, RFC 2326) support codec negotiation to enable backward-compatible use of new formats.
Streams that use unreliable transport (UDP) default to using the recovery journal; streams using reliable transport (TCP) default to no journal. These defaults may be overridden at session setup via the j_sec parameter. For all transport types, senders MUST transmit packets with consecutive sequence numbers (modulo 2^16).
When a MIDI 1.0 DIN cable uses 'dropped 0xF7' SysEx encoding, senders MUST reconstruct the canonical form (insert the dropped 0xF7), then substitute a 0xF5 octet at the terminal position to signal the original dropped-byte coding to the receiver.
A receiver MUST process the first received packet in a stream as if it were a packet that ends a loss event. Upon exiting a session, a receiver MUST ensure that the rendered MIDI performance does not end with indefinite artifacts.
A sender SHOULD NOT create RTP MIDI UDP packets whose size exceeds the MTU of the underlying network. Management tools include the closed-loop sending policy (using RTCP feedback), SysEx segmentation controls, name-space splitting via session tools, and TCP transport.
All command timestamps in a packet MUST be less than or equal to the RTP timestamp of the next packet in the stream (modulo 2^32). This ensures each RTP MIDI packet is uniquely responsible for encoding a contiguous time window.
By default, senders MUST use the closed-loop sending policy for the recovery journal. A receiver MUST detect each RTP sequence number break; on packet loss, it MUST repair all indefinite artifacts. On out-of-order packets, the receiver MUST NOT take actions that introduce indefinite artifacts.
For mpeg4-generic RTP MIDI streams, exactly one RTP MIDI AU MUST be mapped to one mpeg4-generic RTP packet; options for multiple AUs per packet, fragmentation, and interleaving MUST NOT be used. The mpeg4-generic streamtype parameter MUST be 5 and mode MUST be 'rtp-midi'.
For RTP MIDI streams destined to be rendered into audio, the clock rate SHOULD be an audio sample rate of 32 KHz or higher, due to human musical perception sensitivity to small timing errors and timbral changes from clock quantization. The rtpmap attribute line MUST communicate the clock rate; no default is specified.
For split MIDI name spaces, a party MUST NOT send several RTP MIDI streams sharing a name space in the same RTP session; each MUST be sent from a different RTP session. All such streams MUST use the same SSRC value and the same randomly chosen RTP timestamp initialization value.
If a stream uses the recovery journal, every payload MUST include a journal section. If a stream does not use journalling, a journal section MUST NOT appear. The journalling method for a stream is set at session start and MUST NOT be changed thereafter.
If different RTP MIDI streams in a multimedia session send different classes of media (e.g., audio vs. lighting control), the streams MUST be sent over different RTP sessions, each with its own media line.
R flag bits (reserved) MUST be set to 0 by senders and MUST be ignored by receivers. LENGTH fields code the number of octets in the containing structure including its own header; receivers MUST use LENGTH to advance past a structure rather than relying on knowledge of its internal format.
Senders MUST monitor the MIDI command source for patterns that result in excessive packet rates and take actions during RTP transcoding to reduce the RTP packet rate, as required by RFC 3550 congestion control. RTP MIDI sessions using UDP SHOULD monitor packet loss via RTCP.
Standard MIDI File meta-events MUST NOT appear in the MIDI list. By default, undefined System commands (0xF4, 0xF5, 0xF9, 0xFD) MUST NOT appear in a MIDI Command field except for 0xF5 used in the 'dropped 0xF7' construction and 0xF4 used by SysEx cancel sublists.
The first MIDI channel command in the MIDI list MUST include a status octet. Running status (as defined in MIDI) MAY be used for all subsequent channel commands. All System commands in the MIDI list MUST include a status octet.
The M bit MUST be set to 1 for native streams if the MIDI command section has a non-zero LEN field, and MUST be set to 0 otherwise. For mpeg4-generic streams, the M bit MUST be set to 1 for all packets to conform to RFC 3640.
The recovery journal mandate requires that the MIDI performance rendered from an RTP MIDI stream sent over unreliable transport MUST NOT contain indefinite artifacts (e.g., stuck notes, wrong volume level). The recovery journal achieves this without packet retransmission by coding stream history back to a checkpoint packet.
Unpaired 0xF7 octets MUST NOT appear in the MIDI list of the MIDI Command section, to avoid interference with the command segmentation coding. A sender MAY cancel a segmented SysEx transmission in progress but MUST NOT send a cancel after a 'last' sublist.
An RTP MIDI packet consists of an RTP header followed by a MIDI payload. The MIDI payload MUST begin with the MIDI command section (a possibly empty list of timestamped MIDI commands) and MAY also contain a journal section that provides resiliency by coding the recent history of the stream.
SysEx commands may be encoded verbatim or as multiple segments across MIDI Command fields. Segmentation uses status octets to mark first (0xF0/0xF0), middle (0xF7/0xF0), last (0xF7/0xF7), and cancel (0xF7/0xF4) sublists, enabling per-octet timestamps and cross-packet SysEx transport.
This document registers three media types: 'audio/rtp-midi' for native RTP MIDI streams, mode 'rtp-midi' for the 'audio/mpeg4-generic' media type to support MPEG 4 Audio Object Types (General MIDI, DLS 2, Structured Audio), and 'audio/asc' for AudioSpecificConfig data.
Implementors must read the Security Considerations of RFC 3550 (RTP), RFC 3551 (AVP), and other applicable RTP profile documents, as those issues directly apply to RTP MIDI streams. The Secure Real-time Transport Protocol (SRTP) should also be reviewed for protecting MIDI streams in hostile network environments.
A channel journal is a 3-octet header (S flag, 4-bit CHAN, H flag, 10-bit LENGTH, and a Table of Contents byte with bits P/C/M/W/N/E/T/A for the eight chapter types) followed by chapter data in TOC order.
A system journal is a 2-octet header (S flag, D/V/Q/F/X TOC bits, 10-bit LENGTH) followed by system chapters: D (Song Select, Tune Request, Reset, undefined commands), V (Active Sense), Q (Sequencer State), F (MTC Tape Position), X (System Exclusive).
Delta times in the MIDI list use a 1-4 octet variable-length encoding (modified MIDI File format): the high bit of each octet is a continuation flag, and the low 7 bits carry data. The resulting decoded values are 32-bit unsigned integers; multiple encodings of the same value (e.g., four legal encodings of zero) are all legal.
The MIDI command section begins with a variable-length header containing flags B, J, Z, P and a LEN field. If B=0, the header is 1 octet and LEN is 4 bits (max MIDI list of 15 octets); if B=1, the header is 2 octets and LEN is 12 bits (max 4095 octets), encoded big-endian.
The recovery journal top-level header is 3 octets containing flags S (single-packet loss), Y (system journal present), A (channel journals present), H (enhanced Chapter C encoding), TOTCHAN (4-bit count of channel journals minus 1), and a 16-bit Checkpoint Packet Seqnum in big-endian order.