idnits 2.17.1 draft-ietf-avt-rfc4695-bis-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 7594. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 7605. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 7612. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 7618. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 6 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 7671 -- Looks like a reference, but probably isn't: '2' on line 7680 -- Looks like a reference, but probably isn't: '3' on line 7689 -- Looks like a reference, but probably isn't: '4' on line 7759 -- Looks like a reference, but probably isn't: '5' on line 7758 -- Looks like a reference, but probably isn't: '6' on line 7752 -- Looks like a reference, but probably isn't: '7' on line 7761 -- Possible downref: Non-RFC (?) normative reference: ref. 'MIDI' -- Possible downref: Non-RFC (?) normative reference: ref. 'MPEGSA' ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) -- Possible downref: Non-RFC (?) normative reference: ref. 'MPEGAUDIO' -- Possible downref: Non-RFC (?) normative reference: ref. 'DLS2' ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 3388 (Obsoleted by RFC 5888) -- Possible downref: Non-RFC (?) normative reference: ref. 'RP015' ** Obsolete normative reference: RFC 4288 (Obsoleted by RFC 6838) -- Obsolete informational reference (is this intentional?): RFC 2326 (Obsoleted by RFC 7826) -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 22 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT J. Lazzaro 3 August 6, 2008 J. Wawrzynek 4 Expires: February 6, 2009 UC Berkeley 5 Intended Status: Proposed Standard 7 RTP Payload Format for MIDI 9 11 Status of This Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware have 15 been or will be disclosed, and any of which he or she becomes aware 16 will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering Task 19 Force (IETF), its areas, and its working groups. Note that other 20 groups may also distribute working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference material 25 or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/1id-abstracts.html 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html 33 This Internet-Draft will expire on February 6, 2009. 35 Copyright (C) The IETF Trust (2008). 37 Abstract 39 This memo describes a Real-time Transport Protocol (RTP) payload 40 format for the MIDI (Musical Instrument Digital Interface) command 41 language. The format encodes all commands that may legally appear on 42 a MIDI 1.0 DIN cable. The format is suitable for interactive 43 applications (such as network musical performance) and content- 44 delivery applications (such as file streaming). The format may be 45 used over unicast and multicast UDP and TCP, and it defines tools for 46 graceful recovery from packet loss. Stream behavior, including the 47 MIDI rendering method, may be customized during session setup. The 48 format also serves as a mode for the mpeg4-generic format, to support 49 the MPEG 4 Audio Object Types for General MIDI, Downloadable Sounds 50 Level 2, and Structured Audio. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 5 55 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 56 1.2. Bitfield Conventions . . . . . . . . . . . . . . . . . . . 6 57 2. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . . . 7 58 2.1. RTP Header . . . . . . . . . . . . . . . . . . . . . . . . 7 59 2.2. MIDI Payload . . . . . . . . . . . . . . . . . . . . . . . 12 60 3. MIDI Command Section . . . . . . . . . . . . . . . . . . . . . . 14 61 3.1. Timestamps . . . . . . . . . . . . . . . . . . . . . . . . 15 62 3.2. Command Coding . . . . . . . . . . . . . . . . . . . . . . 17 63 4. The Recovery Journal System . . . . . . . . . . . . . . . . . . . 24 64 5. Recovery Journal Format . . . . . . . . . . . . . . . . . . . . . 26 65 6. Session Description Protocol . . . . . . . . . . . . . . . . . . 30 66 6.1. Session Descriptions for Native Streams . . . . . . . . . 31 67 6.2. Session Descriptions for mpeg4-generic Streams . . . . . . 33 68 6.3. Parameters . . . . . . . . . . . . . . . . . . . . . . . . 35 69 7. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . . . 37 70 8. Congestion Control . . . . . . . . . . . . . . . . . . . . . . . 38 71 9. Security Considerations . . . . . . . . . . . . . . . . . . . . . 39 72 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 40 73 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 40 74 11.1. rtp-midi Media Type Registration . . . . . . . . . . . . 41 75 11.1.1. Repository Request for "audio/rtp-midi" . . . . . 43 76 11.2. mpeg4-generic Media Type Registration . . . . . . . . . . 45 77 11.2.1. Repository Request for Mode rtp-midi for 78 mpeg4-generic . . . . . . . . . . . . . . . . . . 48 79 11.3. asc Media Type Registration . . . . . . . . . . . . . . . 49 80 A. The Recovery Journal Channel Chapters . . . . . . . . . . . . . . 52 81 A.1. Recovery Journal Definitions . . . . . . . . . . . . . . . 52 82 A.2. Chapter P: MIDI Program Change . . . . . . . . . . . . . . 57 83 A.3. Chapter C: MIDI Control Change . . . . . . . . . . . . . . 58 84 A.3.1. Log Inclusion Rules . . . . . . . . . . . . . . . . 58 85 A.3.2. Controller Log Format . . . . . . . . . . . . . . . 60 86 A.3.3. Log List Coding Rules . . . . . . . . . . . . . . . 62 87 A.3.4. The Parameter System . . . . . . . . . . . . . . . 65 88 A.4. Chapter M: MIDI Parameter System . . . . . . . . . . . . . 67 89 A.4.1. Log Inclusion Rules . . . . . . . . . . . . . . . . 68 90 A.4.2. Log Coding Rules . . . . . . . . . . . . . . . . . 70 91 A.4.2.1. The Value Tool . . . . . . . . . . . . . . . 71 92 A.4.2.2. The Count Tool . . . . . . . . . . . . . . . 75 93 A.5. Chapter W: MIDI Pitch Wheel . . . . . . . . . . . . . . . 76 94 A.6. Chapter N: MIDI NoteOff and NoteOn . . . . . . . . . . . . 77 95 A.6.1. Header Structure . . . . . . . . . . . . . . . . . 78 96 A.6.2. Note Structures . . . . . . . . . . . . . . . . . . 79 97 A.7. Chapter E: MIDI Note Command Extras . . . . . . . . . . . 81 98 A.7.1. Note Log Format . . . . . . . . . . . . . . . . . . 82 99 A.7.2. Log Inclusion Rules . . . . . . . . . . . . . . . . 82 100 A.8. Chapter T: MIDI Channel Aftertouch . . . . . . . . . . . . 83 101 A.9. Chapter A: MIDI Poly Aftertouch . . . . . . . . . . . . . 84 102 B. The Recovery Journal System Chapters . . . . . . . . . . . . . . 86 103 B.1. System Chapter D: Simple System Commands . . . . . . . . . 86 104 B.1.1. Undefined System Commands . . . . . . . . . . 87 105 B.2. System Chapter V: Active Sense Command . . . . . . . . . . 90 106 B.3. System Chapter Q: Sequencer State Commands . . . . . . . . 91 107 B.3.1. Non-compliant Sequencers . . . . . . . . . . . 93 108 B.4. System Chapter F: MIDI Time Code Tape Position . . . . . . 94 109 B.4.1. Partial Frames . . . . . . . . . . . . . . . . . . 96 110 B.5. System Chapter X: System Exclusive . . . . . . . . . . . . 98 111 B.5.1. Chapter Format . . . . . . . . . . . . . . . . 98 112 B.5.2. Log Inclusion Semantics . . . . . . . . . . . 101 113 B.5.3. TCOUNT and COUNT Fields . . . . . . . . . . . 103 114 C. Session Configuration Tools . . . . . . . . . . . . . . . . . . . 105 115 C.1. Configuration Tools: Stream Subsetting . . . . . . . . . . 106 116 C.2. Configuration Tools: The Journalling System . . . . . . . 110 117 C.2.1. The j_sec Parameter . . . . . . . . . . . . . . . . 111 118 C.2.2. The j_update Parameter . . . . . . . . . . . . . . 112 119 C.2.2.1. The anchor Sending Policy . . . . . . . . . 113 120 C.2.2.2. The closed-loop Sending Policy . . . . . . . 113 121 C.2.2.3. The open-loop Sending Policy . . . . . . . . 117 122 C.2.3. Recovery Journal Chapter Inclusion Parameters . . . 119 123 C.3. Configuration Tools: Timestamp Semantics . . . . . . . . . 124 124 C.3.1. The comex Algorithm . . . . . . . . . . . . . . . . 124 125 C.3.2. The async Algorithm . . . . . . . . . . . . . . . . 125 126 C.3.3. The buffer Algorithm . . . . . . . . . . . . . . . 126 127 C.4. Configuration Tools: Packet Timing Tools . . . . . . . . . 128 128 C.4.1. Packet Duration Tools . . . . . . . . . . . . . . . 128 129 C.4.2. The guardtime Parameter . . . . . . . . . . . . . . 129 130 C.5. Configuration Tools: Stream Description . . . . . . . . . 131 131 C.6. Configuration Tools: MIDI Rendering . . . . . . . . . . . 137 132 C.6.1. The multimode Parameter . . . . . . . . . . . . . . 138 133 C.6.2. Renderer Specification . . . . . . . . . . . . . . 138 134 C.6.3. Renderer Initialization . . . . . . . . . . . . . . 141 135 C.6.4. MIDI Channel Mapping . . . . . . . . . . . . . . . 143 136 C.6.4.1. The smf_info Parameter . . . . . . . . . . . 143 137 C.6.4.2. The smf_inline, smf_url, and smf_cid 138 Parameters . . . . . . . . . . . . . . . . . 145 139 C.6.4.3. The chanmask Parameter . . . . . . . . . . . 146 140 C.6.5. The audio/asc Media Type . . . . . . . . . . . . . 147 141 C.7. Interoperability . . . . . . . . . . . . . . . . . . . . . 149 142 C.7.1. MIDI Content Streaming Applications . . . . . . . 149 143 C.7.2. MIDI Network Musical Performance Applications . . . 152 144 D. Parameter Syntax Definitions . . . . . . . . . . . . . . . . . . 161 145 E. A MIDI Overview for Networking Specialists . . . . . . . . . . . 168 146 E.1. Commands Types . . . . . . . . . . . . . . . . . . . . . . 170 147 E.2. Running Status . . . . . . . . . . . . . . . . . . . . . . 170 148 E.3. Command Timing . . . . . . . . . . . . . . . . . . . . . . 171 149 E.4. AudioSpecificConfig Templates for MMA Renderers . . . . . 171 150 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176 151 Normative References . . . . . . . . . . . . . . . . . . . . . 176 152 Informative References . . . . . . . . . . . . . . . . . . . . 177 153 Change Log for . . . . . . . . . 181 154 1. Introduction 156 The Internet Engineering Task Force (IETF) has developed a set of 157 focused tools for multimedia networking ([RFC3550] [RFC4566] [RFC3261] 158 [RFC2326]). These tools can be combined in different ways to support a 159 variety of real-time applications over Internet Protocol (IP) networks. 161 For example, a telephony application might use the Session Initiation 162 Protocol (SIP, [RFC3261]) to set up a phone call. Call setup would 163 include negotiations to agree on a common audio codec [RFC3264]. 164 Negotiations would use the Session Description Protocol (SDP, [RFC4566]) 165 to describe candidate codecs. 167 After a call is set up, audio data would flow between the parties using 168 the Real Time Protocol (RTP, [RFC3550]) under any applicable profile 169 (for example, the Audio/Visual Profile (AVP, [RFC3551])). The tools 170 used in this telephony example (SIP, SDP, RTP) might be combined in a 171 different way to support a content streaming application, perhaps in 172 conjunction with other tools, such as the Real Time Streaming Protocol 173 (RTSP, [RFC2326]). 175 The MIDI (Musical Instrument Digital Interface) command language [MIDI] 176 is widely used in musical applications that are analogous to the 177 examples described above. On stage and in the recording studio, MIDI is 178 used for the interactive remote control of musical instruments, an 179 application similar in spirit to telephony. On web pages, Standard MIDI 180 Files (SMFs, [MIDI]) rendered using the General MIDI standard [MIDI] 181 provide a low-bandwidth substitute for audio streaming. 183 This memo is motivated by a simple premise: if MIDI performances could 184 be sent as RTP streams that are managed by IETF session tools, a 185 hybridization of the MIDI and IETF application domains may occur. 187 For example, interoperable MIDI networking may foster network music 188 performance applications, in which a group of musicians, located at 189 different physical locations, interact over a network to perform as they 190 would if they were located in the same room [NMP]. As a second example, 191 the streaming community may begin to use MIDI for low- bitrate audio 192 coding, perhaps in conjunction with normative sound synthesis methods 193 [MPEGSA]. 195 To enable MIDI applications to use RTP, this memo defines an RTP payload 196 format and its media type. Sections 2-5 and Appendices A-B define the 197 RTP payload format. Section 6 and Appendices C-D define the media types 198 identifying the payload format, the parameters needed for configuration, 199 and how the parameters are utilized in SDP. 201 Appendix C also includes interoperability guidelines for the example 202 applications described above: network musical performance using SIP 203 (Appendix C.7.2) and content-streaming using RTSP (Appendix C.7.1). 205 Another potential application area for RTP MIDI is MIDI networking for 206 professional audio equipment and electronic musical instruments. We do 207 not offer interoperability guidelines for this application in this memo. 208 However, RTP MIDI has been designed with stage and studio applications 209 in mind, and we expect that efforts to define a stage and studio 210 framework will rely on RTP MIDI for MIDI transport services. 212 Some applications may require MIDI media delivery at a certain service 213 quality level (latency, jitter, packet loss, etc). RTP itself does not 214 provide service guarantees. However, applications may use lower-layer 215 network protocols to configure the quality of the transport services 216 that RTP uses. These protocols may act to reserve network resources for 217 RTP flows [RFC2205] or may simply direct RTP traffic onto a dedicated 218 "media network" in a local installation. Note that RTP and the MIDI 219 payload format do provide tools that applications may use to achieve the 220 best possible real-time performance at a given service level. 222 This memo normatively defines the syntax and semantics of the MIDI 223 payload format. However, this memo does not define algorithms for 224 sending and receiving packets. An ancillary document [RFC4696] provides 225 informative guidance on algorithms. Supplemental information may be 226 found in related conference publications [NMP] [GRAME]. 228 Throughout this memo, the phrase "native stream" refers to a stream that 229 uses the rtp-midi media type. The phrase "mpeg4-generic stream" refers 230 to a stream that uses the mpeg4-generic media type (in mode rtp-midi) to 231 operate in an MPEG 4 environment [RFC3640]. Section 6 describes this 232 distinction in detail. 234 1.1. Terminology 236 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 237 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 238 document are to be interpreted as described in BCP 14, RFC 2119 239 [RFC2119]. 241 1.2. Bitfield Conventions 243 In this document, the packet bitfields that share a common name often 244 have identical semantics. As most of these bitfields appear in 245 Appendices A-B, we define the common bitfield names in Appendix A.1. 247 However, a few of these common names also appear in the main text of 248 this document. For convenience, we list these definitions below: 250 o R flag bit. R flag bits are reserved for future use. Senders 251 MUST set R bits to 0. Receivers MUST ignore R bit values. 253 o LENGTH field. All fields named LENGTH (as distinct from LEN) 254 code the number of octets in the structure that contains it, 255 including the header it resides in and all hierarchical levels 256 below it. If a structure contains a LENGTH field, a receiver 257 MUST use the LENGTH field value to advance past the structure 258 during parsing, rather than use knowledge about the internal 259 format of the structure. 261 2. Packet Format 263 In this section, we introduce the format of RTP MIDI packets. The 264 description includes some background information on RTP, for the benefit 265 of MIDI implementors new to IETF tools. Implementors should consult 266 [RFC3550] for an authoritative description of RTP. 268 This memo assumes that the reader is familiar with MIDI syntax and 269 semantics. Appendix E provides a MIDI overview, at a level of detail 270 sufficient to understand most of this memo. Implementors should consult 271 [MIDI] for an authoritative description of MIDI. 273 The MIDI payload format maps a MIDI command stream (16 voice channels + 274 systems) onto an RTP stream. An RTP media stream is a sequence of 275 logical packets that share a common format. Each packet consists of two 276 parts: the RTP header and the MIDI payload. Figure 1 shows this format 277 (vertical space delineates the header and payload). 279 We describe RTP packets as "logical" packets to highlight the fact that 280 RTP itself is not a network-layer protocol. Instead, RTP packets are 281 mapped onto network protocols (such as unicast UDP, multicast UDP, or 282 TCP) by an application [ALF]. The interleaved mode of the Real Time 283 Streaming Protocol (RTSP, [RFC2326]) is an example of an RTP mapping to 284 TCP transport, as is [RFC4571]. 286 2.1. RTP Header 288 [RFC3550] provides a complete description of the RTP header fields. In 289 this section, we clarify the role of a few RTP header fields for MIDI 290 applications. All fields are coded in network byte order (big- endian). 292 0 1 2 3 293 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 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | V |P|X| CC |M| PT | Sequence number | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | Timestamp | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | SSRC | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 | MIDI command section ... | 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 | Journal section ... | 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 Figure 1 -- Packet format 310 The behavior of the 1-bit M field depends on the media type of the 311 stream. For native streams, the M bit MUST be set to 1 if the MIDI 312 command section has a non-zero LEN field, and MUST be set to 0 313 otherwise. For mpeg4-generic streams, the M bit MUST be set to 1 for 314 all packets (to conform to [RFC3640]). 316 In an RTP MIDI stream, the 16-bit sequence number field is initialized 317 to a randomly chosen value and is incremented by one (modulo 2^16) for 318 each packet sent in the stream. A related quantity, the 32-bit extended 319 packet sequence number, may be computed by tracking rollovers of the 320 16-bit sequence number. Note that different receivers of the same 321 stream may compute different extended packet sequence numbers, depending 322 on when the receiver joined the session. 324 The 32-bit timestamp field sets the base timestamp value for the packet. 325 The payload codes MIDI command timing relative to this value. The 326 timestamp units are set by the clock rate parameter. For example, if 327 the clock rate has a value of 44100 Hz, two packets whose base timestamp 328 values differ by 2 seconds have RTP timestamp fields that differ by 329 88200. 331 Note that the clock rate parameter is not encoded within each RTP MIDI 332 packet. A receiver of an RTP MIDI stream becomes aware of the clock 333 rate as part of the session setup process. For example, if a session 334 management tool uses the Session Description Protocol (SDP, [RFC4566]) 335 to describe a media session, the clock rate parameter is set using the 336 rtpmap attribute. We show examples of session setup in Section 6. 338 For RTP MIDI streams destined to be rendered into audio, the clock rate 339 SHOULD be an audio sample rate of 32 KHz or higher. This recommendation 340 is due to the sensitivity of human musical perception to small timing 341 errors in musical note sequences, and due to the timbral changes that 342 occur when two near-simultaneous MIDI NoteOns are rendered with a 343 different timing than that desired by the content author due to clock 344 rate quantization. RTP MIDI streams that are not destined for audio 345 rendering (such as MIDI streams that control stage lighting) MAY use a 346 lower clock rate but SHOULD use a clock rate high enough to avoid timing 347 artifacts in the application. 349 For RTP MIDI streams destined to be rendered into audio, the clock rate 350 SHOULD be chosen from rates in common use in professional audio 351 applications or in consumer audio distribution. At the time of this 352 writing, these rates include 32 KHz, 44.1 KHz, 48 KHz, 64 KHz, 88.2 KHz, 353 96 KHz, 176.4 KHz, and 192 KHz. If the RTP MIDI session is a part of a 354 synchronized media session that includes another (non-MIDI) RTP audio 355 stream with a clock rate of 32 KHz or higher, the RTP MIDI stream SHOULD 356 use a clock rate that matches the clock rate of the other audio stream. 357 However, if the RTP MIDI stream is destined to be rendered into audio, 358 the RTP MIDI stream SHOULD NOT use a clock rate lower than 32 KHz, even 359 if this second stream has a clock rate less than 32 KHz. 361 Timestamps of consecutive packets do not necessarily increment at a 362 fixed rate, because RTP MIDI packets are not necessarily sent at a fixed 363 rate. The degree of packet transmission regularity reflects the 364 underlying application dynamics. Interactive applications may vary the 365 packet sending rate to track the gestural rate of a human performer, 366 whereas content-streaming applications may send packets at a fixed rate. 368 Therefore, the timestamps for two sequential RTP packets may be 369 identical, or the second packet may have a timestamp arbitrarily larger 370 than the first packet (modulo 2^32). Section 3 places additional 371 restrictions on the RTP timestamps for two sequential RTP packets, as 372 does the guardtime parameter (Appendix C.4.2). 374 We use the term "media time" to denote the temporal duration of the 375 media coded by an RTP packet. The media time coded by a packet is 376 computed by subtracting the last command timestamp in the MIDI command 377 section from the RTP timestamp (modulo 2^32). If the MIDI list of the 378 MIDI command section of a packet is empty, the media time coded by the 379 packet is 0 ms. Appendix C.4.1 discusses media time issues in detail. 381 We now define RTP session semantics, in the context of sessions 382 specified using the session description protocol [RFC4566]. A session 383 description media line ("m=") specifies an RTP session. An RTP session 384 has an independent space of 2^32 synchronization sources. 385 Synchronization source identifiers are coded in the SSRC header field of 386 RTP session packets. The payload types that may appear in the PT header 387 field of RTP session packets are listed at the end of the media line. 389 Several RTP MIDI streams may appear in an RTP session. Each stream is 390 distinguished by a unique SSRC value and has a unique sequence number 391 and RTP timestamp space. Multiple streams in the RTP session may be 392 sent by a single party. Multiple parties may send streams in the RTP 393 session. An RTP MIDI stream encodes data for a single MIDI command name 394 space (16 voice channels + Systems). 396 Streams in an RTP session may use different payload types, or they may 397 use the same payload type. However, each party may send, at most, one 398 RTP MIDI stream for each payload type mapped to an RTP MIDI payload 399 format in an RTP session. Recall that dynamic binding of payload type 400 numbers in [RFC4566] lets a party map many payload type numbers to the 401 RTP MIDI payload format; thus a party may send many RTP MIDI streams in 402 a single RTP session. Pairs of streams (unicast or multicast) that 403 communicate between two parties in an RTP session and that share a 404 payload type have the same association as a MIDI cable pair that cross- 405 connects two devices in a MIDI 1.0 DIN network. 407 The RTP session architecture described above is efficient in its use of 408 network ports, as one RTP session (using a port pair per party) supports 409 the transport of many MIDI name spaces (16 MIDI channels + systems). We 410 define tools for grouping and labelling MIDI name spaces across streams 411 and sessions in Appendix C.5 of this memo. 413 The RTP header timestamps for each stream in an RTP session have 414 separately and randomly chosen initialization values. Receivers use the 415 timing fields encoded in the RTP control protocol (RTCP, [RFC3550]) 416 sender reports to synchronize the streams sent by a party. The SSRC 417 values for each stream in an RTP session are also separately and 418 randomly chosen, as described in [RFC3550]. Receivers use the CNAME 419 field encoded in RTCP sender reports to verify that streams were sent by 420 the same party, and to detect SSRC collisions, as described in 421 [RFC3550]. 423 In some applications, a receiver renders MIDI commands into audio (or 424 into control actions, such as the rewind of a tape deck or the dimming 425 of stage lights). In other applications, a receiver presents a MIDI 426 stream to software programs via an Application Programmer Interface 427 (API). Appendix C.6 defines session configuration tools to specify what 428 receivers should do with a MIDI command stream. 430 If a multimedia session uses different RTP MIDI streams to send 431 different classes of media, the streams MUST be sent over different RTP 432 sessions. For example, if a multimedia session uses one MIDI stream for 433 audio and a second MIDI stream to control a lighting system, the audio 434 and lighting streams MUST be sent over different RTP sessions, each with 435 its own media line. 437 Session description tools defined in Appendix C.5 let a sending party 438 split a single MIDI name space (16 voice channels + systems) over 439 several RTP MIDI streams. Split transport of a MIDI command stream is a 440 delicate task, because correct command stream reconstruction by a 441 receiver depends on exact timing synchronization across the streams. 443 To support split name spaces, we define the following requirements: 445 o A party MUST NOT send several RTP MIDI streams that share a MIDI 446 name space in the same RTP session. Instead, each stream MUST 447 be sent from a different RTP session. 449 o If several RTP MIDI streams sent by a party share a MIDI name 450 space, all streams MUST use the same SSRC value and MUST use the 451 same randomly chosen RTP timestamp initialization value. 453 These rules let a receiver identify streams that share a MIDI name space 454 (by matching SSRC values) and also let a receiver accurately reconstruct 455 the source MIDI command stream (by using RTP timestamps to interleave 456 commands from the two streams). Care MUST be taken by senders to ensure 457 that SSRC changes due to collisions are reflected in both streams. 458 Receivers MUST regularly examine the RTCP CNAME fields associated with 459 the linked streams, to ensure that the assumed link is legitimate and 460 not the result of an SSRC collision by another sender. 462 Except for the special cases described above, a party may send many RTP 463 MIDI streams in the same session. However, it is sometimes advantageous 464 for two RTP MIDI streams to be sent over different RTP sessions. For 465 example, two streams may need different values for RTP session-level 466 attributes (such as the sendonly and recvonly attributes). As a second 467 example, two RTP sessions may be needed to send two unicast streams in a 468 multimedia session that originate on different computers (with different 469 IP numbers). Two RTP sessions are needed in this case because transport 470 addresses are specified on the RTP-session or multimedia-session level, 471 not on a payload type level. 473 On a final note, in some uses of MIDI, parties send bidirectional 474 traffic to conduct transactions (such as file exchange). These commands 475 were designed to work over MIDI 1.0 DIN cable networks may be configured 476 in a multicast topology, which use pure "party-line" signalling. Thus, 477 if a multimedia session ensures a multicast connection between all 478 parties, bidirectional MIDI commands will work without additional 479 support from the RTP MIDI payload format. 481 2.2. MIDI Payload 483 The payload (Figure 1) MUST begin with the MIDI command section. The 484 MIDI command section codes a (possibly empty) list of timestamped MIDI 485 commands, and provides the essential service of the payload format. 487 The payload MAY also contain a journal section. The journal section 488 provides resiliency by coding the recent history of the stream. A flag 489 in the MIDI command section codes the presence of a journal section in 490 the payload. 492 Section 3 defines the MIDI command section. Sections 4-5 and Appendices 493 A-B define the recovery journal, the default format for the journal 494 section. Here, we describe how these payload sections operate in a 495 stream in an RTP session. 497 The journalling method for a stream is set at the start of a session and 498 MUST NOT be changed thereafter. A stream may be set to use the recovery 499 journal, to use an alternative journal format (none are defined in this 500 memo), or not to use a journal. 502 The default journalling method of a stream is inferred from its 503 transport type. Streams that use unreliable transport (such as UDP) 504 default to using the recovery journal. Streams that use reliable 505 transport (such as TCP) default to not using a journal. Appendix C.2.1 506 defines session configuration tools for overriding these defaults. For 507 all types of transport, a sender MUST transmit an RTP packet stream with 508 consecutive sequence numbers (modulo 2^16). 510 If a stream uses the recovery journal, every payload in the stream MUST 511 include a journal section. If a stream does not use journalling, a 512 journal section MUST NOT appear in a stream payload. If a stream uses 513 an alternative journal format, the specification for the journal format 514 defines an inclusion policy. 516 If a stream is sent over UDP transport, the Maximum Transmission Unit 517 (MTU) of the underlying network limits the practical size of the payload 518 section (for example, an Ethernet MTU is 1500 octets), for applications 519 where predictable and minimal packet transmission latency is critical. 520 A sender SHOULD NOT create RTP MIDI UDP packets whose size exceeds the 521 MTU of the underlying network. Instead, the sender SHOULD take steps to 522 keep the maximum packet size under the MTU limit. 524 These steps may take many forms. The default closed-loop recovery 525 journal sending policy (defined in Appendix C.2.2.2) uses RTP control 526 protocol (RTCP, [RFC3550]) feedback to manage the RTP MIDI packet size. 527 In addition, Section 3.2 and Appendix B.5.2 provide specific tools for 528 managing the size of packets that code MIDI System Exclusive (0xF0) 529 commands. Appendix C.5 defines session configuration tools that may be 530 used to split a dense MIDI name space into several UDP streams (each 531 sent in a different RTP session, per Section 2.1) so that the payload 532 fits comfortably into an MTU. Another option is to use TCP. Section 533 4.3 of [RFC4696] provides non-normative advice for packet size 534 management. 536 3. MIDI Command Section 538 Figure 2 shows the format of the MIDI command section. 540 0 1 2 3 541 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 542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 543 |B|J|Z|P|LEN... | MIDI list ... | 544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 546 Figure 2 -- MIDI command section 548 The MIDI command section begins with a variable-length header. 550 The header field LEN codes the number of octets in the MIDI list that 551 follow the header. If the header flag B is 0, the header is one octet 552 long, and LEN is a 4-bit field, supporting a maximum MIDI list length of 553 15 octets. 555 If B is 1, the header is two octets long, and LEN is a 12-bit field, 556 supporting a maximum MIDI list length of 4095 octets. LEN is coded in 557 network byte order (big-endian): the 4 bits of LEN that appear in the 558 first header octet code the most significant 4 bits of the 12-bit LEN 559 value. 561 A LEN value of 0 is legal, and it codes an empty MIDI list. 563 If the J header bit is set to 1, a journal section MUST appear after the 564 MIDI command section in the payload. If the J header bit is set to 0, 565 the payload MUST NOT contain a journal section. 567 We define the semantics of the P header bit in Section 3.2. 569 If the LEN header field is nonzero, the MIDI list has the structure 570 shown in Figure 3. 572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 573 | Delta Time 0 (1-4 octets long, or 0 octets if Z = 1) | 574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 575 | MIDI Command 0 (1 or more octets long) | 576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 577 | Delta Time 1 (1-4 octets long) | 578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 579 | MIDI Command 1 (1 or more octets long) | 580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 581 | ... | 582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 583 | Delta Time N (1-4 octets long) | 584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 585 | MIDI Command N (0 or more octets long) | 586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 588 Figure 3 -- MIDI list structure 590 If the header flag Z is 1, the MIDI list begins with a complete MIDI 591 command (coded in the MIDI Command 0 field, in Figure 3) preceded by a 592 delta time (coded in the Delta Time 0 field). If Z is 0, the Delta Time 593 0 field is not present in the MIDI list, and the command coded in the 594 MIDI Command 0 field has an implicit delta time of 0. 596 The MIDI list structure may also optionally encode a list of N 597 additional complete MIDI commands, each coded in a MIDI Command K field. 598 Each additional command MUST be preceded by a Delta Time K field, which 599 codes the command's delta time. We discuss exceptions to the "command 600 fields code complete MIDI commands" rule in Section 3.2. 602 The final MIDI command field (i.e., the MIDI Command N field, shown in 603 Figure 3) in the MIDI list MAY be empty. Moreover, a MIDI list MAY 604 consist a single delta time (encoded in the Delta Time 0 field) without 605 an associated command (which would have been encoded in the MIDI Command 606 0 field). These rules enable MIDI coding features that are explained in 607 Section 3.1. We delay the explanations because an understanding of RTP 608 MIDI timestamps is necessary to describe the features. 610 3.1. Timestamps 612 In this section, we describe how RTP MIDI encodes a timestamp for each 613 MIDI list command. Command timestamps have the same units as RTP packet 614 header timestamps (described in Section 2.1 and [RFC3550]). Recall that 615 RTP timestamps have units of seconds, whose scaling is set during 616 session configuration (see Section 6.1 and [RFC4566]). 618 As shown in Figure 3, the MIDI list encodes time using a compact delta- 619 time format. The RTP MIDI delta time syntax is a modified form of the 620 MIDI File delta time syntax [MIDI]. RTP MIDI delta times use 1-4 octet 621 fields to encode 32-bit unsigned integers. Figure 4 shows the encoded 622 and decoded forms of delta times. Note that delta time values may be 623 legally encoded in multiple formats; for example, there are four legal 624 ways to encode the zero delta time (0x00, 0x8000, 0x808000, 0x80808000). 626 RTP MIDI uses delta times to encode a timestamp for each MIDI command. 627 The timestamp for MIDI Command K is the summation (modulo 2^32) of the 628 RTP timestamp and decoded delta times 0 through K. This cumulative 629 coding technique, borrowed from MIDI File delta time coding, is 630 efficient because it reduces the number of multi-octet delta times. 632 All command timestamps in a packet MUST be less than or equal to the RTP 633 timestamp of the next packet in the stream (modulo 2^32). 635 This restriction ensures that a particular RTP MIDI packet in a stream 636 is uniquely responsible for encoding time starting at the moment after 637 the RTP timestamp encoded in the RTP packet header, and ending at the 638 moment before the final command timestamp encoded in the MIDI list. The 639 "moment before" and "moment after" qualifiers acknowledge the "less than 640 or equal" semantics (as opposed to "strictly less than") in the sentence 641 above this paragraph. 643 Note that it is possible to "pad" the end of an RTP MIDI packet with 644 time that is guaranteed to be void of MIDI commands, by setting the 645 "Delta Time N" field of the MIDI list to the end of the void time, and 646 by omitting its corresponding "MIDI Command N" field (a syntactic 647 construction the preamble of Section 3 expressly made legal). 649 In addition, it is possible to code an RTP MIDI packet to express that a 650 period of time in the stream is void of MIDI commands. The RTP 651 timestamp in the header would code the start of the void time. The MIDI 652 list of this packet would consist of a "Delta Time 0" field that coded 653 the end of the void time. No other fields would be present in the MIDI 654 list (a syntactic construction the preamble of Section 3 also expressly 655 made legal). 657 By default, a command timestamp indicates the execution time for the 658 command. The difference between two timestamps indicates the time delay 659 between the execution of the commands. This difference may be zero, 660 coding simultaneous execution. In this memo, we refer to this 661 interpretation of timestamps as "comex" (COMmand EXecution) semantics. 662 We formally define comex semantics in Appendix C.3. 664 The comex interpretation of timestamps works well for transcoding a 665 Standard MIDI File (SMF) into an RTP MIDI stream, as SMFs code a 666 timestamp for each MIDI command stored in the file. To transcode an SMF 667 that uses metric time markers, use the SMF tempo map (encoded in the SMF 668 as meta-events) to convert metric SMF timestamp units into seconds-based 669 RTP timestamp units. 671 The comex interpretation also works well for MIDI hardware controllers 672 that are coding raw sensor data directly onto an RTP MIDI stream. Note 673 that this controller design is preferable to a design that converts raw 674 sensor data into a MIDI 1.0 cable command stream and then transcodes the 675 stream onto an RTP MIDI stream. 677 The comex interpretation of timestamps is usually not the best timestamp 678 interpretation for transcoding a MIDI source that uses implicit command 679 timing (such as MIDI 1.0 DIN cables) into an RTP MIDI stream. Appendix 680 C.3 defines alternatives to comex semantics and describes session 681 configuration tools for selecting the timestamp interpretation semantics 682 for a stream. 684 One-Octet Delta Time: 686 Encoded form: 0ddddddd 687 Decoded form: 00000000 00000000 00000000 0ddddddd 689 Two-Octet Delta Time: 691 Encoded form: 1ccccccc 0ddddddd 692 Decoded form: 00000000 00000000 00cccccc cddddddd 694 Three-Octet Delta Time: 696 Encoded form: 1bbbbbbb 1ccccccc 0ddddddd 697 Decoded form: 00000000 000bbbbb bbcccccc cddddddd 699 Four-Octet Delta Time: 701 Encoded form: 1aaaaaaa 1bbbbbbb 1ccccccc 0ddddddd 702 Decoded form: 0000aaaa aaabbbbb bbcccccc cddddddd 704 Figure 4 -- Decoding delta time formats 706 3.2. Command Coding 708 Each non-empty MIDI Command field in the MIDI list codes one of the MIDI 709 command types that may legally appear on a MIDI 1.0 DIN cable. Standard 710 MIDI File meta-events do not fit this definition and MUST NOT appear in 711 the MIDI list. As a rule, each MIDI Command field codes a complete 712 command, in the binary command format defined in [MIDI]. In the 713 remainder of this section, we describe exceptions to this rule. 715 The first MIDI channel command in the MIDI list MUST include a status 716 octet. Running status coding, as defined in [MIDI], MAY be used for all 717 subsequent MIDI channel commands in the list. As in [MIDI], System 718 Common and System Exclusive messages (0xF0 ... 0xF7) cancel the running 719 status state, but System Real-time messages (0xF8 ... 0xFF) do not 720 affect the running status state. All System commands in the MIDI list 721 MUST include a status octet. 723 As we note above, the first channel command in the MIDI list MUST 724 include a status octet. However, the corresponding command in the 725 original MIDI source data stream might not have a status octet (in this 726 case, the source would be coding the command using running status). If 727 the status octet of the first channel command in the MIDI list does not 728 appear in the source data stream, the P (phantom) header bit MUST be set 729 to 1. In all other cases, the P bit MUST be set to 0. 731 Note that the P bit describes the MIDI source data stream, not the MIDI 732 list encoding; regardless of the state of the P bit, the MIDI list MUST 733 include the status octet. 735 As receivers MUST be able to decode running status, sender implementors 736 should feel free to use running status to improve bandwidth efficiency. 737 However, senders SHOULD NOT introduce timing jitter into an existing 738 MIDI command stream through an inappropriate use or removal of running 739 status coding. This warning primarily applies to senders whose RTP MIDI 740 streams may be transcoded onto a MIDI 1.0 DIN cable [MIDI] by the 741 receiver: both the timestamps and the command coding (running status or 742 not) must comply with the physical restrictions of implicit time coding 743 over a slow serial line. 745 On a MIDI 1.0 DIN cable [MIDI], a System Real-time command may be 746 embedded inside of another "host" MIDI command. This syntactic 747 construction is not supported in the payload format: a MIDI Command 748 field in the MIDI list codes exactly one MIDI command (partially or 749 completely). 751 To encode an embedded System Real-time command, senders MUST extract the 752 command from its host and code it in the MIDI list as a separate 753 command. The host command and System Real-time command SHOULD appear in 754 the same MIDI list. The delta time of the System Real-time command 755 SHOULD result in a command timestamp that encodes the System Real-time 756 command placement in its original embedded position. 758 Two methods are provided for encoding MIDI System Exclusive (SysEx) 759 commands in the MIDI list. A SysEx command may be encoded in a MIDI 760 Command field verbatim: a 0xF0 octet, followed by an arbitrary number of 761 data octets, followed by a 0xF7 octet. 763 Alternatively, a SysEx command may be encoded as multiple segments. The 764 command is divided into two or more SysEx command segments; each segment 765 is encoded in its own MIDI Command field in the MIDI list. 767 The payload format supports segmentation in order to encode SysEx 768 commands that encode information in the temporal pattern of data octets. 769 By encoding these commands as a series of segments, each data octet may 770 be associated with a distinct delta time. Segmentation also supports 771 the coding of large SysEx commands across several packets. 773 To segment a SysEx command, first partition its data octet list into two 774 or more sublists. The last sublist MAY be empty (i.e., contain no 775 octets); all other sublists MUST contain at least one data octet. To 776 complete the segmentation, add the status octets defined in Figure 5 to 777 the head and tail of the first, last, and any "middle" sublists. Figure 778 6 shows example segmentations of a SysEx command. 780 A sender MAY cancel a segmented SysEx command transmission that is in 781 progress, by sending the "cancel" sublist shown in Figure 5. A "cancel" 782 sublist MAY follow a "first" or "middle" sublist in the transmission, 783 but MUST NOT follow a "last" sublist. The cancel MUST be empty (thus, 784 0xF7 0xF4 is the only legal cancel sublist). 786 The cancellation feature is needed because Appendix C.1 defines 787 configuration tools that let session parties exclude certain SysEx 788 commands in the stream. Senders that transcode a MIDI source onto an 789 RTP MIDI stream under these constraints have the responsibility of 790 excluding undesired commands from the RTP MIDI stream. 792 The cancellation feature lets a sender start the transmission of a 793 command before the MIDI source has sent the entire command. If a sender 794 determines that the command whose transmission is in progress should not 795 appear on the RTP stream, it cancels the command. Without a method for 796 cancelling a SysEx command transmission, senders would be forced to use 797 a high-latency store-and-forward approach to transcoding SysEx commands 798 onto RTP MIDI packets, in order to validate each SysEx command before 799 transmission. 801 The recommended receiver reaction to a cancellation depends on the 802 capabilities of the receiver. For example, a sound synthesizer that is 803 directly parsing RTP MIDI packets and rendering them to audio will be 804 aware of the fact that SysEx commands may be cancelled in RTP MIDI. 805 These receivers SHOULD detect a SysEx cancellation in the MIDI list and 806 act as if they had never received the SysEx command. 808 As a second example, a synthesizer may be receiving MIDI data from an 809 RTP MIDI stream via a MIDI DIN cable (or a software API emulation of a 810 MIDI DIN cable). In this case, an RTP-MIDI-aware system receives the 811 RTP MIDI stream and transcodes it onto the MIDI DIN cable (or its 812 emulation). Upon the receipt of the cancel sublist, the RTP-MIDI- aware 813 transcoder might have already sent the first part of the SysEx command 814 on the MIDI DIN cable to the receiver. 816 Unfortunately, the MIDI DIN cable protocol cannot directly code "cancel 817 SysEx in progress" semantics. However, MIDI DIN cable receivers begin 818 SysEx processing after the complete command arrives. The receiver 819 checks to see if it recognizes the command (coded in the first few 820 octets) and then checks to see if the command is the correct length. 821 Thus, in practice, a transcoder can cancel a SysEx command by sending an 822 0xF7 to (prematurely) end the SysEx command -- the receiver will detect 823 the incorrect command length and discard the command. 825 Appendix C.1 defines configuration tools that may be used to prohibit 826 SysEx command cancellation. 828 The relative ordering of SysEx command segments in a MIDI list must 829 match the relative ordering of the sublists in the original SysEx 830 command. By default, commands other than System Real-time MIDI commands 831 MUST NOT appear between SysEx command segments (Appendix C.1 defines 832 configuration tools to change this default, to let other commands types 833 appear between segments). If the command segments of a SysEx command 834 are placed in the MIDI lists of two or more RTP packets, the segment 835 ordering rules apply to the concatenation of all affected MIDI lists. 837 ----------------------------------------------------------- 838 | Sublist Position | Head Status Octet | Tail Status Octet | 839 |-----------------------------------------------------------| 840 | first | 0xF0 | 0xF0 | 841 |-----------------------------------------------------------| 842 | middle | 0xF7 | 0xF0 | 843 |-----------------------------------------------------------| 844 | last | 0xF7 | 0xF7 | 845 |-----------------------------------------------------------| 846 | cancel | 0xF7 | 0xF4 | 847 ----------------------------------------------------------- 849 Figure 5 -- Command segmentation status octets 851 [MIDI] permits 0xF7 octets that are not part of a (0xF0, 0xF7) pair to 852 appear on a MIDI 1.0 DIN cable. Unpaired 0xF7 octets have no semantic 853 meaning in MIDI, apart from cancelling running status. 855 Unpaired 0xF7 octets MUST NOT appear in the MIDI list of the MIDI 856 Command section. We impose this restriction to avoid interference with 857 the command segmentation coding defined in Figure 5. 859 SysEx commands carried on a MIDI 1.0 DIN cable may use the "dropped 860 0xF7" construction [MIDI]. In this coding method, the 0xF7 octet is 861 dropped from the end of the SysEx command, and the status octet of the 862 next MIDI command acts both to terminate the SysEx command and start the 863 next command. To encode this construction in the payload format, follow 864 these steps: 866 o Determine the appropriate delta times for the SysEx command and 867 the command that follows the SysEx command. 869 o Insert the "dropped" 0xF7 octet at the end of the SysEx command, 870 to form the standard SysEx syntax. 872 o Code both commands into the MIDI list using the rules above. 874 o Replace the 0xF7 octet that terminates the verbatim SysEx 875 encoding or the last segment of the segmented SysEx encoding 876 with a 0xF5 octet. This substitution informs the receiver 877 of the original dropped 0xF7 coding. 879 [MIDI] reserves the undefined System Common commands 0xF4 and 0xF5 and 880 the undefined System Real-time commands 0xF9 and 0xFD for future use. 881 By default, undefined commands MUST NOT appear in a MIDI Command field 882 in the MIDI list, with the exception of the 0xF5 octets used to code the 883 "dropped 0xF7" construction and the 0xF4 octets used by SysEx "cancel" 884 sublists. 886 During session configuration, a stream may be customized to transport 887 undefined commands (Appendix C.1). For this case, we now define how 888 senders encode undefined commands in the MIDI list. 890 An undefined System Real-time command MUST be coded using the System 891 Real-time rules. 893 If the undefined System Common commands are put to use in a future 894 version of [MIDI], the command will begin with an 0xF4 or 0xF5 status 895 octet, followed by an arbitrary number of data octets (i.e., zero or 896 more data bytes). To encode these commands, senders MUST terminate the 897 command with an 0xF7 octet and place the modified command into the MIDI 898 Command field. 900 Unfortunately, non-compliant uses of the undefined System Common 901 commands may appear in MIDI implementations. To model these commands, 902 we assume that the command begins with an 0xF4 or 0xF5 status octet, 903 followed by zero or more data octets, followed by zero or more trailing 904 0xF7 status octets. To encode the command, senders MUST first remove 905 all trailing 0xF7 status octets from the command. Then, senders MUST 906 terminate the command with an 0xF7 octet and place the modified command 907 into the MIDI Command field. 909 Note that we include the trailing octets in our model as a cautionary 910 measure: if such commands appeared in a non-compliant use of an 911 undefined System Common command, an RTP MIDI encoding of the command 912 that did not remove trailing octets could be mistaken for an encoding of 913 "middle" or "last" sublist of a segmented SysEx commands (Figure 5) 914 under certain packet loss conditions. 916 Original SysEx command: 918 0xF0 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0xF7 920 A two-segment segmentation: 922 0xF0 0x01 0x02 0x03 0x04 0xF0 924 0xF7 0x05 0x06 0x07 0x08 0xF7 926 A different two-segment segmentation: 928 0xF0 0x01 0xF0 930 0xF7 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0xF7 932 A three-segment segmentation: 934 0xF0 0x01 0x02 0xF0 936 0xF7 0x03 0x04 0xF0 938 0xF7 0x05 0x06 0x07 0x08 0xF7 940 The segmentation with the largest number of segments: 942 0xF0 0x01 0xF0 944 0xF7 0x02 0xF0 946 0xF7 0x03 0xF0 948 0xF7 0x04 0xF0 950 0xF7 0x05 0xF0 952 0xF7 0x06 0xF0 954 0xF7 0x07 0xF0 956 0xF7 0x08 0xF0 958 0xF7 0xF7 960 Figure 6 -- Example segmentations 962 4. The Recovery Journal System 964 The recovery journal is the default resiliency tool for unreliable 965 transport. In this section, we normatively define the roles that 966 senders and receivers play in the recovery journal system. 968 MIDI is a fragile code. A single lost command in a MIDI command stream 969 may produce an artifact in the rendered performance. We normatively 970 classify rendering artifacts into two categories: 972 o Transient artifacts. Transient artifacts produce immediate 973 but short-term glitches in the performance. For example, a lost 974 NoteOn (0x9) command produces a transient artifact: one note 975 fails to play, but the artifact does not extend beyond the end 976 of that note. 978 o Indefinite artifacts. Indefinite artifacts produce long-lasting 979 errors in the rendered performance. For example, a lost NoteOff 980 (0x8) command may produce an indefinite artifact: the note that 981 should have been ended by the lost NoteOff command may sustain 982 indefinitely. As a second example, the loss of a Control Change 983 (0xB) command for controller number 7 (Channel Volume) may 984 produce an indefinite artifact: after the loss, all notes on 985 the channel may play too softly or too loudly. 987 The purpose of the recovery journal system is to satisfy the recovery 988 journal mandate: the MIDI performance rendered from an RTP MIDI stream 989 sent over unreliable transport MUST NOT contain indefinite artifacts. 991 The recovery journal system does not use packet retransmission to 992 satisfy this mandate. Instead, each packet includes a special section, 993 called the recovery journal. 995 The recovery journal codes the history of the stream, back to an earlier 996 packet called the checkpoint packet. The range of coverage for the 997 journal is called the checkpoint history. The recovery journal codes 998 the information necessary to recover from the loss of an arbitrary 999 number of packets in the checkpoint history. Appendix A.1 normatively 1000 defines the checkpoint packet and the checkpoint history. 1002 When a receiver detects a packet loss, it compares its own knowledge 1003 about the history of the stream with the history information coded in 1004 the recovery journal of the packet that ends the loss event. By noting 1005 the differences in these two versions of the past, a receiver is able to 1006 transform all indefinite artifacts in the rendered performance into 1007 transient artifacts, by executing MIDI commands to repair the stream. 1009 We now state the normative role for senders in the recovery journal 1010 system. 1012 Senders prepare a recovery journal for every packet in the stream. In 1013 doing so, senders choose the checkpoint packet identity for the journal. 1014 Senders make this choice by applying a sending policy. Appendix C.2.2 1015 normatively defines three sending policies: "closed- loop", "open-loop", 1016 and "anchor". 1018 By default, senders MUST use the closed-loop sending policy. If the 1019 session description overrides this default policy, by using the 1020 parameter j_update defined in Appendix C.2.2, senders MUST use the 1021 specified policy. 1023 After choosing the checkpoint packet identity for a packet, the sender 1024 creates the recovery journal. By default, this journal MUST conform to 1025 the normative semantics in Section 5 and Appendices A-B in this memo. 1026 In Appendix C.2.3, we define parameters that modify the normative 1027 semantics for recovery journals. If the session description uses these 1028 parameters, the journal created by the sender MUST conform to the 1029 modified semantics. 1031 Next, we state the normative role for receivers in the recovery journal 1032 system. 1034 A receiver MUST detect each RTP sequence number break in a stream. If 1035 the sequence number break is due to a packet loss event (as defined in 1036 [RFC3550]), the receiver MUST repair all indefinite artifacts in the 1037 rendered MIDI performance caused by the loss. If the sequence number 1038 break is due to an out-of-order packet (as defined in [RFC3550]), the 1039 receiver MUST NOT take actions that introduce indefinite artifacts 1040 (ignoring the out-of-order packet is a safe option). 1042 Receivers take special precautions when entering or exiting a session. 1043 A receiver MUST process the first received packet in a stream as if it 1044 were a packet that ends a loss event. Upon exiting a session, a 1045 receiver MUST ensure that the rendered MIDI performance does not end 1046 with indefinite artifacts. 1048 Receivers are under no obligation to perform indefinite artifact repairs 1049 at the moment a packet arrives. A receiver that uses a playout buffer 1050 may choose to wait until the moment of rendering before processing the 1051 recovery journal, as the "lost" packet may be a late packet that arrives 1052 in time to use. 1054 Next, we state the normative role for the creator of the session 1055 description in the recovery journal system. Depending on the 1056 application, the sender, the receivers, and other parties may take part 1057 in creating or approving the session description. 1059 A session description that specifies the default closed-loop sending 1060 policy and the default recovery journal semantics satisfies the recovery 1061 journal mandate. However, these default behaviors may not be 1062 appropriate for all sessions. If the creators of a session description 1063 use the parameters defined in Appendix C.2 to override these defaults, 1064 the creators MUST ensure that the parameters define a system that 1065 satisfies the recovery journal mandate. 1067 Finally, we note that this memo does not specify sender or receiver 1068 recovery journal algorithms. Implementations are free to use any 1069 algorithm that conforms to the requirements in this section. The non- 1070 normative [RFC4696] discusses sender and receiver algorithm design. 1072 5. Recovery Journal Format 1074 This section introduces the structure of the recovery journal and 1075 defines the bitfields of recovery journal headers. Appendices A-B 1076 complete the bitfield definition of the recovery journal. 1078 The recovery journal has a three-level structure: 1080 o Top-level header. 1082 o Channel and system journal headers. These headers encode 1083 recovery information for a single voice channel (channel 1084 journal) or for all systems commands (system journal). 1086 o Chapters. Chapters describe recovery information for a 1087 single MIDI command type. 1089 Figure 7 shows the top-level structure of the recovery journal. The 1090 recovery journals consists of a 3-octet header, followed by an optional 1091 system journal (labeled S-journal in Figure 7) and an optional list of 1092 channel journals. Figure 8 shows the recovery journal header format. 1094 0 1 2 3 1095 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 1096 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1097 | Recovery journal header | S-journal ... | 1098 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1099 | Channel journals ... | 1100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1102 Figure 7 -- Top-level recovery journal format 1104 0 1 2 1105 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 1106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1107 |S|Y|A|H|TOTCHAN| Checkpoint Packet Seqnum | 1108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1110 Figure 8 -- Recovery journal header 1112 If the Y header bit is set to 1, the system journal appears in the 1113 recovery journal, directly following the recovery journal header. 1115 If the A header bit is set to 1, the recovery journal ends with a list 1116 of (TOTCHAN + 1) channel journals (the 4-bit TOTCHAN header field is 1117 interpreted as an unsigned integer). 1119 A MIDI channel MAY be represented by (at most) one channel journal in a 1120 recovery journal. Channel journals MUST appear in the recovery journal 1121 in ascending channel-number order. 1123 If A and Y are both zero, the recovery journal only contains its 3- 1124 octet header and is considered to be an "empty" journal. 1126 The S (single-packet loss) bit appears in most recovery journal 1127 structures, including the recovery journal header. The S bit helps 1128 receivers efficiently parse the recovery journal in the common case of 1129 the loss of a single packet. Appendix A.1 defines S bit semantics. 1131 The H bit indicates if MIDI channels in the stream have been configured 1132 to use the enhanced Chapter C encoding (Appendix A.3.3). 1134 By default, the payload format does not use enhanced Chapter C encoding. 1135 In this default case, the H bit MUST be set to 0 for all packets in the 1136 stream. 1138 If the stream has been configured so that controller numbers for one or 1139 more MIDI channels use enhanced Chapter C encoding, the H bit MUST be 1140 set to 1 in all packets in the stream. In Appendix C.2.3, we show how 1141 to configure a stream to use enhanced Chapter C encoding. 1143 The 16-bit Checkpoint Packet Seqnum header field codes the sequence 1144 number of the checkpoint packet for this journal, in network byte order 1145 (big-endian). The choice of the checkpoint packet sets the depth of the 1146 checkpoint history for the journal (defined in Appendix A.1). 1148 Receivers may use the Checkpoint Packet Seqnum field of the packet that 1149 ends a loss event to verify that the journal checkpoint history covers 1150 the entire loss event. The checkpoint history covers the loss event if 1151 the Checkpoint Packet Seqnum field is less than or equal to one plus the 1152 highest RTP sequence number previously received on the stream (modulo 1153 2^16). 1155 0 1 2 3 1156 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 1157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1158 |S| CHAN |H| LENGTH |P|C|M|W|N|E|T|A| Chapters ... | 1159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1161 Figure 9 -- Channel journal format 1163 Figure 9 shows the structure of a channel journal: a 3-octet header, 1164 followed by a list of leaf elements called channel chapters. A channel 1165 journal encodes information about MIDI commands on the MIDI channel 1166 coded by the 4-bit CHAN header field. Note that CHAN uses the same bit 1167 encoding as the channel nibble in MIDI Channel Messages (the cccc field 1168 in Figure E.1 of Appendix E). 1170 The 10-bit LENGTH field codes the length of the channel journal. The 1171 semantics for LENGTH fields are uniform throughout the recovery journal, 1172 and are defined in Appendix A.1. 1174 The third octet of the channel journal header is the Table of Contents 1175 (TOC) of the channel journal. The TOC is a set of bits that encode the 1176 presence of a chapter in the journal. Each chapter contains information 1177 about a certain class of MIDI channel command: 1179 o Chapter P: MIDI Program Change (0xC) 1180 o Chapter C: MIDI Control Change (0xB) 1181 o Chapter M: MIDI Parameter System (part of 0xB) 1182 o Chapter W: MIDI Pitch Wheel (0xE) 1183 o Chapter N: MIDI NoteOff (0x8), NoteOn (0x9) 1184 o Chapter E: MIDI Note Command Extras (0x8, 0x9) 1185 o Chapter T: MIDI Channel Aftertouch (0xD) 1186 o Chapter A: MIDI Poly Aftertouch (0xA) 1188 Chapters appear in a list following the header, in order of their 1189 appearance in the TOC. Appendices A.2-9 describe the bitfield format 1190 for each chapter, and define the conditions under which a chapter type 1191 MUST appear in the recovery journal. If any chapter types are required 1192 for a channel, an associated channel journal MUST appear in the recovery 1193 journal. 1195 The H bit indicates if controller numbers on a MIDI channel have been 1196 configured to use the enhanced Chapter C encoding (Appendix A.3.3). 1198 By default, controller numbers on a MIDI channel do not use enhanced 1199 Chapter C encoding. In this default case, the H bit MUST be set to 0 1200 for all channel journal headers for the channel in the recovery journal, 1201 for all packets in the stream. 1203 However, if at least one controller number for a MIDI channel has been 1204 configured to use the enhanced Chapter C encoding, the H bit for its 1205 channel journal MUST be set to 1, for all packets in the stream. 1207 In Appendix C.2.3, we show how to configure a controller number to use 1208 enhanced Chapter C encoding. 1210 0 1 2 3 1211 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 1212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1213 |S|D|V|Q|F|X| LENGTH | System chapters ... | 1214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1216 Figure 10 -- System journal format 1218 Figure 10 shows the structure of the system journal: a 2-octet header, 1219 followed by a list of system chapters. Each chapter codes information 1220 about a specific class of MIDI Systems command: 1222 o Chapter D: Song Select (0xF3), Tune Request (0xF6), Reset (0xFF), 1223 undefined System commands (0xF4, 0xF5, 0xF9, 0xFD) 1224 o Chapter V: Active Sense (0xFE) 1225 o Chapter Q: Sequencer State (0xF2, 0xF8, 0xF9, 0xFA, 0xFB, 0xFC) 1226 o Chapter F: MTC Tape Position (0xF1, 0xF0 0x7F 0xcc 0x01 0x01) 1227 o Chapter X: System Exclusive (all other 0xF0) 1229 The 10-bit LENGTH field codes the size of the system journal and 1230 conforms to semantics described in Appendix A.1. 1232 The D, V, Q, F, and X header bits form a Table of Contents (TOC) for the 1233 system journal. A TOC bit that is set to 1 codes the presence of a 1234 chapter in the journal. Chapters appear in a list following the header, 1235 in the order of their appearance in the TOC. 1237 Appendix B describes the bitfield format for the system chapters and 1238 defines the conditions under which a chapter type MUST appear in the 1239 recovery journal. If any system chapter type is required to appear in 1240 the recovery journal, the system journal MUST appear in the recovery 1241 journal. 1243 6. Session Description Protocol 1245 RTP does not perform session management. Instead, RTP works together 1246 with session management tools, such as the Session Initiation Protocol 1247 (SIP, [RFC3261]) and the Real Time Streaming Protocol (RTSP, [RFC2326]). 1249 RTP payload formats define media type parameters for use in session 1250 management (for example, this memo defines "rtp-midi" as the media type 1251 for native RTP MIDI streams). 1253 In most cases, session management tools use the media type parameters 1254 via another standard, the Session Description Protocol (SDP, [RFC4566]). 1256 SDP is a textual format for specifying session descriptions. Session 1257 descriptions specify the network transport and media encoding for RTP 1258 sessions. Session management tools coordinate the exchange of session 1259 descriptions between participants ("parties"). 1261 Some session management tools use SDP to negotiate details of media 1262 transport (network addresses, ports, etc.). We refer to this use of SDP 1263 as "negotiated usage". One example of negotiated usage is the 1264 Offer/Answer protocol ([RFC3264] and Appendix C.7.2 in this memo) as 1265 used by SIP. 1267 Other session management tools use SDP to declare the media encoding for 1268 the session but use other techniques to negotiate network transport. We 1269 refer to this use of SDP as "declarative usage". One example of 1270 declarative usage is RTSP ([RFC2326] and Appendix C.7.1 in this memo). 1272 Below, we show session description examples for native (Section 6.1) and 1273 mpeg4-generic (Section 6.2) streams. In Section 6.3, we introduce 1274 session configuration tools that may be used to customize streams. 1276 6.1. Session Descriptions for Native Streams 1278 The session description below defines a unicast UDP RTP session (via a 1279 media ("m=") line) whose sole payload type (96) is mapped to a minimal 1280 native RTP MIDI stream. 1282 v=0 1283 o=lazzaro 2520644554 2838152170 IN IP4 first.example.net 1284 s=Example 1285 t=0 0 1286 m=audio 5004 RTP/AVP 96 1287 c=IN IP4 192.0.2.94 1288 a=rtpmap:96 rtp-midi/44100 1290 The rtpmap attribute line uses the "rtp-midi" media type to specify an 1291 RTP MIDI native stream. The clock rate specified on the rtpmap line (in 1292 the example above, 44100 Hz) sets the scaling for the RTP timestamp 1293 header field (see Section 2.1, and also [RFC3550]). 1295 Note that this document does not specify a default clock rate value for 1296 RTP MIDI. When RTP MIDI is used with SDP, parties MUST use the rtpmap 1297 line to communicate the clock rate. Guidance for selecting the RTP MIDI 1298 clock rate value appears in Section 2.1. 1300 We consider the RTP MIDI stream shown above to be "minimal" because the 1301 session description does not customize the stream with parameters. 1302 Without such customization, a native RTP MIDI stream has these 1303 characteristics: 1305 1. If the stream uses unreliable transport (unicast UDP, multicast 1306 UDP, etc.), the recovery journal system is in use, and the RTP 1307 payload contains both the MIDI command section and the journal 1308 section. If the stream uses reliable transport (such as TCP), 1309 the stream does not use journalling, and the payload contains 1310 only the MIDI command section (Section 2.2). 1312 2. If the stream uses the recovery journal system, the recovery 1313 journal system uses the default sending policy and the default 1314 journal semantics (Section 4). 1316 3. In the MIDI command section of the payload, command timestamps 1317 use the default "comex" semantics (Section 3). 1319 4. The recommended temporal duration ("media time") of an RTP 1320 packet ranges from 0 to 200 ms, and the RTP timestamp 1321 difference between sequential packets in the stream may be 1322 arbitrarily large (Section 2.1). 1324 5. If more than one minimal rtp-midi stream appears in a session, 1325 the MIDI name spaces for these streams are independent: channel 1326 1 in the first stream does not reference the same MIDI channel 1327 as channel 1 in the second stream (see Appendix C.5 for a 1328 discussion of the independence of minimal rtp-midi streams). 1330 6. The rendering method for the stream is not specified. What the 1331 receiver "does" with a minimal native MIDI stream is "out of 1332 scope" of this memo. For example, in content creation 1333 environments, a user may manually configure client software to 1334 render the stream with a specific software package. 1336 As in standard in RTP, RTP sessions managed by SIP are sendrecv by 1337 default (parties send and receive MIDI), and RTP sessions managed by 1338 RTSP are recvonly by default (server sends and client receives). 1340 In sendrecv RTP MIDI sessions for the session description shown above, 1341 the 16 voice channel + systems MIDI name space is unique for each 1342 sender. Thus, in a two-party session, the voice channel 0 sent by one 1343 party is distinct from the voice channel 0 sent by the other party. 1345 This behavior corresponds to what occurs when two MIDI 1.0 DIN devices 1346 are cross-connected with two MIDI cables (one cable routing MIDI Out 1347 from the first device into MIDI In of the second device, a second cable 1348 routing MIDI In from the first device into MIDI Out of the second 1349 device). We define this "association" formally in Section 2.1. 1351 MIDI 1.0 DIN networks may be configured in a "party-line" multicast 1352 topology. For these networks, the MIDI protocol itself provides tools 1353 for addressing specific devices in transactions on a multicast network, 1354 and for device discovery. Thus, apart from providing a 1- to-many 1355 forward path and a many-to-1 reverse path, IETF protocols do not need to 1356 provide any special support for MIDI multicast networking. 1358 6.2. Session Descriptions for mpeg4-generic Streams 1360 An mpeg4-generic [RFC3640] RTP MIDI stream uses an MPEG 4 Audio Object 1361 Type to render MIDI into audio. Three Audio Object Types accept MIDI 1362 input: 1364 o General MIDI (Audio Object Type ID 15), based on the General 1365 MIDI rendering standard [MIDI]. 1367 o Wavetable Synthesis (Audio Object Type ID 14), based on the 1368 Downloadable Sounds Level 2 (DLS 2) rendering standard [DLS2]. 1370 o Main Synthetic (Audio Object Type ID 13), based on Structured 1371 Audio and the programming language SAOL [MPEGSA]. 1373 The primary service of an mpeg4-generic stream is to code Access Units 1374 (AUs). We define the mpeg4-generic RTP MIDI AU as the MIDI payload 1375 shown in Figure 1 of Section 2.1 of this memo: a MIDI command section 1376 optionally followed by a journal section. 1378 Exactly one RTP MIDI AU MUST be mapped to one mpeg4-generic RTP MIDI 1379 packet. The mpeg4-generic options for placing several AUs in an RTP 1380 packet MUST NOT be used with RTP MIDI. The mpeg4-generic options for 1381 fragmenting and interleaving AUs MUST NOT be used with RTP MIDI. The 1382 mpeg4-generic RTP packet payload (Figure 1 in [RFC3640]) MUST contain 1383 empty AU Header and Auxiliary sections. These rules yield mpeg4-generic 1384 packets that are structurally identical to native RTP MIDI packets, an 1385 essential property for the correct operation of the payload format. 1387 The session description that follows defines a unicast UDP RTP session 1388 (via a media ("m=") line) whose sole payload type (96) is mapped to a 1389 minimal mpeg4-generic RTP MIDI stream. This example uses the General 1390 MIDI Audio Object Type under Synthesis Profile @ Level 2. 1392 v=0 1393 o=lazzaro 2520644554 2838152170 IN IP6 first.example.net 1394 s=Example 1395 t=0 0 1396 m=audio 5004 RTP/AVP 96 1397 c=IN IP6 2001:DB80::7F2E:172A:1E24 1398 a=rtpmap:96 mpeg4-generic/44100 1399 a=fmtp:96 streamtype=5; mode=rtp-midi; profile-level-id=12; 1400 config=7A0A0000001A4D546864000000060000000100604D54726B0000 1401 000600FF2F000 1403 (The a=fmtp line has been wrapped to fit the page to accommodate memo 1404 formatting restrictions; it comprises a single line in SDP.) 1406 The fmtp attribute line codes the four parameters (streamtype, mode, 1407 profile-level-id, and config) that are required in all mpeg4-generic 1408 session descriptions [RFC3640]. For RTP MIDI streams, the streamtype 1409 parameter MUST be set to 5, the "mode" parameter MUST be set to "rtp- 1410 midi", and the "profile-level-id" parameter MUST be set to the MPEG-4 1411 Profile Level for the stream. For the Synthesis Profile, legal profile- 1412 level-id values are 11, 12, and 13, coding low (11), medium (12), or 1413 high (13) decoder computational complexity, as defined by MPEG 1414 conformance tests. 1416 In a minimal RTP MIDI session description, the config value MUST be a 1417 hexadecimal encoding [RFC3640] of the AudioSpecificConfig data block 1418 [MPEGAUDIO] for the stream. AudioSpecificConfig encodes the Audio 1419 Object Type for the stream and also encodes initialization data (SAOL 1420 programs, DLS 2 wave tables, etc.). Standard MIDI Files encoded in 1421 AudioSpecificConfig in a minimal session description MUST be ignored by 1422 the receiver. 1424 Receivers determine the rendering algorithm for the session by 1425 interpreting the first 5 bits of AudioSpecificConfig as an unsigned 1426 integer that codes the Audio Object Type. In our example above, the 1427 leading config string nibbles "7A" yield the Audio Object Type 15 1428 (General MIDI). In Appendix E.4, we derive the config string value in 1429 the session description shown above; the starting point of the 1430 derivation is the MPEG bitstreams defined in [MPEGSA] and [MPEGAUDIO]. 1432 We consider the stream to be "minimal" because the session description 1433 does not customize the stream through the use of parameters, other than 1434 the 4 required mpeg4-generic parameters described above. In Section 1435 6.1, we describe the behavior of a minimal native stream, as a numbered 1436 list of characteristics. Items 1-4 on that list also describe the 1437 minimal mpeg4-generic stream, but items 5 and 6 require restatements, as 1438 listed below: 1440 5. If more than one minimal mpeg4-generic stream appears in 1441 a session, each stream uses an independent instance of the 1442 Audio Object Type coded in the config parameter value. 1444 6. A minimal mpeg4-generic stream encodes the AudioSpecificConfig 1445 as an inline hexadecimal constant. If a session description 1446 is sent over UDP, it may be impossible to transport large 1447 AudioSpecificConfig blocks within the Maximum Transmission Size 1448 (MTU) of the underlying network (for Ethernet, the MTU is 1500 1449 octets). In some cases, the AudioSpecificConfig block may 1450 exceed the maximum size of the UDP packet itself. 1452 The comments in Section 6.1 on SIP and RTSP stream directional defaults, 1453 sendrecv MIDI channel usage, and MIDI 1.0 DIN multicast networks also 1454 apply to mpeg4-generic RTP MIDI sessions. 1456 In sendrecv sessions, each party's session description MUST use 1457 identical values for the mpeg4-generic parameters (including the 1458 required streamtype, mode, profile-level-id, and config parameters). As 1459 a consequence, each party uses an identically configured MPEG 4 Audio 1460 Object Type to render MIDI commands into audio. The preamble to 1461 Appendix C discusses a way to create "virtual sendrecv" sessions that do 1462 not have this restriction. 1464 6.3. Parameters 1466 This section introduces parameters for session configuration for RTP 1467 MIDI streams. In session descriptions, parameters modify the semantics 1468 of a payload type. Parameters are specified on an fmtp attribute line. 1469 See the session description example in Section 6.2 for an example of a 1470 fmtp attribute line. 1472 The parameters add features to the minimal streams described in Sections 1473 6.1-2, and support several types of services: 1475 o Stream subsetting. By default, all MIDI commands that 1476 are legal to appear on a MIDI 1.0 DIN cable may appear 1477 in an RTP MIDI stream. The cm_unused parameter overrides 1478 this default by prohibiting certain commands from appearing 1479 in the stream. The cm_used parameter is used in conjunction 1480 with cm_unused, to simplify the specification of complex 1481 exclusion rules. We describe cm_unused and cm_used in 1482 Appendix C.1. 1484 o Journal customization. The j_sec and j_update parameters 1485 configure the use of the journal section. The ch_default, 1486 ch_never, and ch_anchor parameters configure the semantics 1487 of the recovery journal chapters. These parameters are 1488 described in Appendix C.2 and override the default stream 1489 behaviors 1 and 2, listed in Section 6.1 and referenced in 1490 Section 6.2. 1492 o MIDI command timestamp semantics. The tsmode, octpos, 1493 mperiod, and linerate parameters customize the semantics 1494 of timestamps in the MIDI command section. These parameters 1495 let RTP MIDI accurately encode the implicit time coding of 1496 MIDI 1.0 DIN cables. These parameters are described in 1497 Appendix C.3 and override default stream behavior 3, 1498 listed in Section 6.1 and referenced in Section 6.2 1500 o Media time. The rtp_ptime and rtp_maxptime parameters define 1501 the temporal duration ("media time") of an RTP MIDI packet. 1502 The guardtime parameter sets the minimum sending rate of stream 1503 packets. These parameters are described in Appendix C.4 1504 and override default stream behavior 4, listed in Section 6.1 1505 and referenced in Section 6.2. 1507 o Stream description. The musicport parameter labels the 1508 MIDI name space of RTP streams in a multimedia session. 1509 Musicport is described in Appendix C.5. The musicport 1510 parameter overrides default stream behavior 5, in Sections 1511 6.1 and 6.2. 1513 o MIDI rendering. Several parameters specify the MIDI 1514 rendering method of a stream. These parameters are described 1515 in Appendix C.6 and override default stream behavior 6, in 1516 Sections 6.1 and 6.2. 1518 In Appendix C.7, we specify interoperability guidelines for two RTP MIDI 1519 application areas: content-streaming using RTSP (Appendix C.7.1) and 1520 network musical performance using SIP (Appendix C.7.2). 1522 7. Extensibility 1524 The payload format defined in this memo exclusively encodes all commands 1525 that may legally appear on a MIDI 1.0 DIN cable. 1527 Many worthy uses of MIDI over RTP do not fall within the narrow scope of 1528 the payload format. For example, the payload format does not support 1529 the direct transport of Standard MIDI File (SMF) meta-event and metric 1530 timing data. As a second example, the payload format does not define 1531 transport tools for user-defined commands (apart from tools to support 1532 System Exclusive commands [MIDI]). 1534 The payload format does not provide an extension mechanism to support 1535 new features of this nature, by design. Instead, we encourage the 1536 development of new payload formats for specialized musical applications. 1537 The IETF session management tools [RFC3264] [RFC2326] support codec 1538 negotiation, to facilitate the use of new payload formats in a backward- 1539 compatible way. 1541 However, the payload format does provide several extensibility tools, 1542 which we list below: 1544 o Journalling. As described in Appendix C.2, new token 1545 values for the j_sec and j_update parameters may 1546 be defined in IETF standards-track documents. This 1547 mechanism supports the design of new journal formats 1548 and the definition of new journal sending policies. 1550 o Rendering. The payload format may be extended to support 1551 new MIDI renderers (Appendix C.6.2). Certain general aspects 1552 of the RTP MIDI rendering process may also be extended, via 1553 the definition of new token values for the render (Appendix C.6) 1554 and smf_info (Appendix C.6.4.1) parameters. 1556 o Undefined commands. [MIDI] reserves 4 MIDI System commands 1557 for future use (0xF4, 0xF5, 0xF9, 0xFD). If updates 1558 to [MIDI] define the reserved commands, IETF standards-track 1559 documents may be defined to provide resiliency support for 1560 the commands. Opaque LEGAL fields appear in System Chapter 1561 D for this purpose (Appendix B.1.1). 1563 A final form of extensibility involves the inclusion of the payload 1564 format in framework documents. Framework documents describe how to 1565 combine protocols to form a platform for interoperable applications. 1566 For example, a stage and studio framework might define how to use SIP 1567 [RFC3261], RTSP [RFC2326], SDP [RFC4566], and RTP [RFC3550] to support 1568 media networking for professional audio equipment and electronic musical 1569 instruments. 1571 8. Congestion Control 1573 The RTP congestion control requirements defined in [RFC3550] apply to 1574 RTP MIDI sessions, and implementors should carefully read the congestion 1575 control section in [RFC3550]. As noted in [RFC3550], all transport 1576 protocols used on the Internet need to address congestion control in 1577 some way, and RTP is not an exception. 1579 In addition, the congestion control requirements defined in [RFC3551] 1580 applies to RTP MIDI sessions run under applicable profiles. The basic 1581 congestion control requirement defined in [RFC3551] is that RTP sessions 1582 that use UDP transport should monitor packet loss (via RTCP or other 1583 means) to ensure that the RTP stream competes fairly with TCP flows that 1584 share the network. 1586 Finally, RTP MIDI has congestion control issues that are unique for an 1587 audio RTP payload format. In applications such as network musical 1588 performance [NMP], the packet rate is linked to the gestural rate of a 1589 human performer. Senders MUST monitor the MIDI command source for 1590 patterns that result in excessive packet rates and take actions during 1591 RTP transcoding to reduce the RTP packet rate. [RFC4696] offers 1592 implementation guidance on this issue. 1594 9. Security Considerations 1596 Implementors should carefully read the Security Considerations sections 1597 of the RTP [RFC3550], AVP [RFC3551], and other RTP profile documents, as 1598 the issues discussed in these sections directly apply to RTP MIDI 1599 streams. Implementors should also review the Secure Real-time Transport 1600 Protocol (SRTP, [RFC3711]), an RTP profile that addresses the security 1601 issues discussed in [RFC3550] and [RFC3551]. 1603 Here, we discuss security issues that are unique to the RTP MIDI payload 1604 format. 1606 When using RTP MIDI, authentication of incoming RTP and RTCP packets is 1607 RECOMMENDED. Per-packet authentication may be provided by SRTP or by 1608 other means. Without the use of authentication, attackers could forge 1609 MIDI commands into an ongoing stream, damaging speakers and eardrums. 1610 An attacker could also craft RTP and RTCP packets to exploit known bugs 1611 in the client and take effective control of a client machine. 1613 Session management tools (such as SIP [RFC3261]) SHOULD use 1614 authentication during the transport of all session descriptions 1615 containing RTP MIDI media streams. For SIP, the Security Considerations 1616 section in [RFC3261] provides an overview of possible authentication 1617 mechanisms. RTP MIDI session descriptions should use authentication 1618 because the session descriptions may code initialization data using the 1619 parameters described in Appendix C. If an attacker inserts bogus 1620 initialization data into a session description, he can corrupt the 1621 session or forge an client attack. 1623 Session descriptions may also code renderer initialization data by 1624 reference, via the url (Appendix C.6.3) and smf_url (Appendix C.6.4.2) 1625 parameters. If the coded URL is spoofed, both session and client are 1626 open to attack, even if the session description itself is authenticated. 1627 Therefore, URLs specified in url and smf_url parameters SHOULD use 1628 [RFC2818]. 1630 Section 2.1 allows streams sent by a party in two RTP sessions to have 1631 the same SSRC value and the same RTP timestamp initialization value, 1632 under certain circumstances. Normally, these values are randomly chosen 1633 for each stream in a session, to make plaintext guessing harder to do if 1634 the payloads are encrypted. Thus, Section 2.1 weakens this aspect of 1635 RTP security. 1637 10. Acknowledgements 1639 We thank the networking, media compression, and computer music community 1640 members who have commented or contributed to the effort, including Kurt 1641 B, Cynthia Bruyns, Steve Casner, Paul Davis, Robin Davies, Joanne Dow, 1642 Tobias Erichsen, Nicolas Falquet, Dominique Fober, Philippe Gentric, 1643 Michael Godfrey, Chris Grigg, Todd Hager, Alfred Hoenes, Michel Jullian, 1644 Phil Kerr, Young-Kwon Lim, Jessica Little, Jan van der Meer, Colin 1645 Perkins, Charlie Richmond, Herbie Robinson, Larry Rowe, Eric Scheirer, 1646 Dave Singer, Martijn Sipkema, William Stewart, Kent Terry, Magnus 1647 Westerlund, Tom White, Jim Wright, Doug Wyatt, and Giorgio Zoia. We 1648 also thank the members of the San Francisco Bay Area music and audio 1649 community for creating the context for the work, including Don Buchla, 1650 Chris Chafe, Richard Duda, Dan Ellis, Adrian Freed, Ben Gold, Jaron 1651 Lanier, Roger Linn, Richard Lyon, Dana Massie, Max Mathews, Keith 1652 McMillen, Carver Mead, Nelson Morgan, Tom Oberheim, Malcolm Slaney, Dave 1653 Smith, Julius Smith, David Wessel, and Matt Wright. 1655 11. IANA Considerations 1657 This section makes a series of requests to IANA. The IANA has completed 1658 registration/assignments of the below requests. 1660 The sub-sections that follow hold the actual, detailed requests. All 1661 registrations in this section are in the IETF tree and follow the rules 1662 of [RFC4288] and [RFC4855], as appropriate. 1664 In Section 11.1, we request the registration of a new media type: 1665 "audio/rtp-midi". Paired with this request is a request for a 1666 repository for new values for several parameters associated with 1667 "audio/rtp-midi". We request this repository in Section 11.1.1. 1669 In Section 11.2, we request the registration of a new value ("rtp- 1670 midi") for the "mode" parameter of the "mpeg4-generic" media type. The 1671 "mpeg4-generic" media type is defined in [RFC3640], and [RFC3640] 1672 defines a repository for the "mode" parameter. However, we believe we 1673 are the first to request the registration of a "mode" value, so we 1674 believe the registry for "mode" has not yet been created by IANA. 1676 Paired with our "mode" parameter value request for "mpeg4-generic" is a 1677 request for a repository for new values for several parameters we have 1678 defined for use with the "rtp-midi" mode value. We request this 1679 repository in Section 11.2.1. 1681 In Section 11.3, we request the registration of a new media type: 1682 "audio/asc". No repository request is associated with this request. 1684 11.1. rtp-midi Media Type Registration 1686 This section requests the registration of the "rtp-midi" subtype for the 1687 "audio" media type. We request the registration of the parameters 1688 listed in the "optional parameters" section below (both the "non- 1689 extensible parameters" and the "extensible parameters" lists). We also 1690 request the creation of repositories for the "extensible parameters"; 1691 the details of this request appear in Section 11.1.1, below. 1693 Media type name: 1695 audio 1697 Subtype name: 1699 rtp-midi 1701 Required parameters: 1703 rate: The RTP timestamp clock rate. See Sections 2.1 and 6.1 1704 for usage details. 1706 Optional parameters: 1708 Non-extensible parameters: 1710 ch_anchor: See Appendix C.2.3 for usage details. 1711 ch_default: See Appendix C.2.3 for usage details. 1712 ch_never: See Appendix C.2.3 for usage details. 1713 cm_unused: See Appendix C.1 for usage details. 1714 cm_used: See Appendix C.1 for usage details. 1715 chanmask: See Appendix C.6.4.3 for usage details. 1716 cid: See Appendix C.6.3 for usage details. 1717 guardtime: See Appendix C.4.2 for usage details. 1718 inline: See Appendix C.6.3 for usage details. 1719 linerate: See Appendix C.3 for usage details. 1720 mperiod: See Appendix C.3 for usage details. 1721 multimode: See Appendix C.6.1 for usage details. 1722 musicport: See Appendix C.5 for usage details. 1723 octpos: See Appendix C.3 for usage details. 1724 rinit: See Appendix C.6.3 for usage details. 1725 rtp_maxptime: See Appendix C.4.1 for usage details. 1726 rtp_ptime: See Appendix C.4.1 for usage details. 1728 smf_cid: See Appendix C.6.4.2 for usage details. 1729 smf_inline: See Appendix C.6.4.2 for usage details. 1730 smf_url: See Appendix C.6.4.2 for usage details. 1731 tsmode: See Appendix C.3 for usage details. 1732 url: See Appendix C.6.3 for usage details. 1734 Extensible parameters: 1736 j_sec: See Appendix C.2.1 for usage details. See 1737 Section 11.1.1 for repository details. 1738 j_update: See Appendix C.2.2 for usage details. See 1739 Section 11.1.1 for repository details. 1740 render: See Appendix C.6 for usage details. See 1741 Section 11.1.1 for repository details. 1742 subrender: See Appendix C.6.2 for usage details. See 1743 Section 11.1.1 for repository details. 1744 smf_info: See Appendix C.6.4.1 for usage details. See 1745 Section 11.1.1 for repository details. 1747 Encoding considerations: 1749 The format for this type is framed and binary. 1751 Restrictions on usage: 1753 This type is only defined for real-time transfers of MIDI 1754 streams via RTP. Stored-file semantics for rtp-midi may 1755 be defined in the future. 1757 Security considerations: 1759 See Section 9 of this memo. 1761 Interoperability considerations: 1763 None. 1765 Published specification: 1767 This memo and [MIDI] serve as the normative specification. In 1768 addition, references [NMP], [GRAME], and [RFC4696] provide 1769 non-normative implementation guidance. 1771 Applications that use this media type: 1773 Audio content-creation hardware, such as MIDI controller piano 1774 keyboards and MIDI audio synthesizers. Audio content-creation 1775 software, such as music sequencers, digital audio workstations, 1776 and soft synthesizers. Computer operating systems, for network 1777 support of MIDI Application Programmer Interfaces. Content 1778 distribution servers and terminals may use this media type for 1779 low bit-rate music coding. 1781 Additional information: 1783 None. 1785 Person & email address to contact for further information: 1787 John Lazzaro 1789 Intended usage: 1791 COMMON. 1793 Author: 1795 John Lazzaro 1797 Change controller: 1799 IETF Audio/Video Transport Working Group delegated 1800 from the IESG. 1802 11.1.1. Repository Request for "audio/rtp-midi" 1804 For the "rtp-midi" subtype, we request the creation of repositories for 1805 extensions to the following parameters (which are those listed as 1806 "extensible parameters" in Section 11.1). 1808 j_sec: 1810 Registrations for this repository may only occur 1811 via an IETF standards-track document. Appendix C.2.1 1812 of this memo describes appropriate registrations for this 1813 repository. 1815 Initial values for this repository appear below: 1817 "none": Defined in Appendix C.2.1 of this memo. 1818 "recj": Defined in Appendix C.2.1 of this memo. 1820 j_update: 1822 Registrations for this repository may only occur 1823 via an IETF standards-track document. Appendix C.2.2 1824 of this memo describes appropriate registrations for this 1825 repository. 1827 Initial values for this repository appear below: 1829 "anchor": Defined in Appendix C.2.2 of this memo. 1830 "open-loop": Defined in Appendix C.2.2 of this memo. 1831 "closed-loop": Defined in Appendix C.2.2 of this memo. 1833 render: 1835 Registrations for this repository MUST include a 1836 specification of the usage of the proposed value. 1837 See text in the preamble of Appendix C.6 for details 1838 (the paragraph that begins "Other render token ..."). 1840 Initial values for this repository appear below: 1842 "unknown": Defined in Appendix C.6 of this memo. 1843 "synthetic": Defined in Appendix C.6 of this memo. 1844 "api": Defined in Appendix C.6 of this memo. 1845 "null": Defined in Appendix C.6 of this memo. 1847 subrender: 1849 Registrations for this repository MUST include a 1850 specification of the usage of the proposed value. 1851 See text Appendix C.6.2 for details (the paragraph 1852 that begins "Other subrender token ..."). 1854 Initial values for this repository appear below: 1856 "default": Defined in Appendix C.6.2 of this memo. 1858 smf_info: 1860 Registrations for this repository MUST include a 1861 specification of the usage of the proposed value. 1862 See text in Appendix C.6.4.1 for details (the 1863 paragraph that begins "Other smf_info token ..."). 1865 Initial values for this repository appear below: 1867 "ignore": Defined in Appendix C.6.4.1 of this memo. 1868 "sdp_start": Defined in Appendix C.6.4.1 of this memo. 1869 "identity": Defined in Appendix C.6.4.1 of this memo. 1871 11.2. mpeg4-generic Media Type Registration 1873 This section requests the registration of the "rtp-midi" value for the 1874 "mode" parameter of the "mpeg4-generic" media type. The "mpeg4- 1875 generic" media type is defined in [RFC3640], and [RFC3640] defines a 1876 repository for the "mode" parameter. We are registering mode rtp- midi 1877 to support the MPEG Audio codecs [MPEGSA] that use MIDI. 1879 In conjunction with this registration request, we request the 1880 registration of the parameters listed in the "optional parameters" 1881 section below (both the "non-extensible parameters" and the "extensible 1882 parameters" lists). We also request the creation of repositories for 1883 the "extensible parameters"; the details of this request appear in 1884 Appendix 11.2.1, below. 1886 Media type name: 1888 audio 1890 Subtype name: 1892 mpeg4-generic 1894 Required parameters: 1896 The "mode" parameter is required by [RFC3640]. [RFC3640] requests 1897 a repository for "mode", so that new values for mode 1898 may be added. We request that the value "rtp-midi" be 1899 added to the "mode" repository. 1901 In mode rtp-midi, the mpeg4-generic parameter rate is 1902 a required parameter. Rate specifies the RTP timestamp 1903 clock rate. See Sections 2.1 and 6.2 for usage details 1904 of rate in mode rtp-midi. 1906 Optional parameters: 1908 We request registration of the following parameters 1909 for use in mode rtp-midi for mpeg4-generic. 1911 Non-extensible parameters: 1913 ch_anchor: See Appendix C.2.3 for usage details. 1914 ch_default: See Appendix C.2.3 for usage details. 1915 ch_never: See Appendix C.2.3 for usage details. 1916 cm_unused: See Appendix C.1 for usage details. 1917 cm_used: See Appendix C.1 for usage details. 1918 chanmask: See Appendix C.6.4.3 for usage details. 1919 cid: See Appendix C.6.3 for usage details. 1920 guardtime: See Appendix C.4.2 for usage details. 1921 inline: See Appendix C.6.3 for usage details. 1922 linerate: See Appendix C.3 for usage details. 1923 mperiod: See Appendix C.3 for usage details. 1924 multimode: See Appendix C.6.1 for usage details. 1925 musicport: See Appendix C.5 for usage details. 1926 octpos: See Appendix C.3 for usage details. 1927 rinit: See Appendix C.6.3 for usage details. 1928 rtp_maxptime: See Appendix C.4.1 for usage details. 1929 rtp_ptime: See Appendix C.4.1 for usage details. 1930 smf_cid: See Appendix C.6.4.2 for usage details. 1931 smf_inline: See Appendix C.6.4.2 for usage details. 1932 smf_url: See Appendix C.6.4.2 for usage details. 1933 tsmode: See Appendix C.3 for usage details. 1934 url: See Appendix C.6.3 for usage details. 1936 Extensible parameters: 1938 j_sec: See Appendix C.2.1 for usage details. See 1939 Section 11.2.1 for repository details. 1940 j_update: See Appendix C.2.2 for usage details. See 1941 Section 11.2.1 for repository details. 1942 render: See Appendix C.6 for usage details. See 1943 Section 11.2.1 for repository details. 1944 subrender: See Appendix C.6.2 for usage details. See 1945 Section 11.2.1 for repository details. 1946 smf_info: See Appendix C.6.4.1 for usage details. See 1947 Section 11.2.1 for repository details. 1949 Encoding considerations: 1951 The format for this type is framed and binary. 1953 Restrictions on usage: 1955 Only defined for real-time transfers of audio/mpeg4-generic 1956 RTP streams with mode=rtp-midi. 1958 Security considerations: 1960 See Section 9 of this memo. 1962 Interoperability considerations: 1964 Except for the marker bit (Section 2.1), the packet formats 1965 for audio/rtp-midi and audio/mpeg4-generic (mode rtp-midi) 1966 are identical. The formats differ in use: audio/mpeg4-generic 1967 is for MPEG work, and audio/rtp-midi is for all other work. 1969 Published specification: 1971 This memo, [MIDI], and [MPEGSA] are the normative references. 1972 In addition, references [NMP], [GRAME], and [RFC4696] provide 1973 non-normative implementation guidance. 1975 Applications that use this media type: 1977 MPEG 4 servers and terminals that support [MPEGSA]. 1979 Additional information: 1981 None. 1983 Person & email address to contact for further information: 1985 John Lazzaro 1987 Intended usage: 1989 COMMON. 1991 Author: 1993 John Lazzaro 1995 Change controller: 1997 IETF Audio/Video Transport Working Group delegated 1998 from the IESG. 2000 11.2.1. Repository Request for Mode rtp-midi for mpeg4-generic 2002 For mode rtp-midi of the mpeg4-generic subtype, we request the creation 2003 of repositories for extensions to the following parameters (which are 2004 those listed as "extensible parameters" in Section 11.2). 2006 j_sec: 2008 Registrations for this repository may only occur 2009 via an IETF standards-track document. Appendix C.2.1 2010 of this memo describes appropriate registrations for this 2011 repository. 2013 Initial values for this repository appear below: 2015 "none": Defined in Appendix C.2.1 of this memo. 2016 "recj": Defined in Appendix C.2.1 of this memo. 2018 j_update: 2020 Registrations for this repository may only occur 2021 via an IETF standards-track document. Appendix C.2.2 2022 of this memo describes appropriate registrations for this 2023 repository. 2025 Initial values for this repository appear below: 2027 "anchor": Defined in Appendix C.2.2 of this memo. 2028 "open-loop": Defined in Appendix C.2.2 of this memo. 2029 "closed-loop": Defined in Appendix C.2.2 of this memo. 2031 render: 2033 Registrations for this repository MUST include a 2034 specification of the usage of the proposed value. 2035 See text in the preamble of Appendix C.6 for details 2036 (the paragraph that begins "Other render token ..."). 2038 Initial values for this repository appear below: 2040 "unknown": Defined in Appendix C.6 of this memo. 2041 "synthetic": Defined in Appendix C.6 of this memo. 2042 "null": Defined in Appendix C.6 of this memo. 2044 subrender: 2046 Registrations for this repository MUST include a 2047 specification of the usage of the proposed value. 2048 See text in Appendix C.6.2 for details (the paragraph 2049 that begins "Other subrender token ..." and 2050 subsequent paragraphs). Note that the text in 2051 Appendix C.6.2 contains restrictions on subrender 2052 registrations for mpeg4-generic ("Registrations 2053 for mpeg4-generic subrender values ..."). 2055 Initial values for this repository appear below: 2057 "default": Defined in Appendix C.6.2 of this memo. 2059 smf_info: 2061 Registrations for this repository MUST include a 2062 specification of the usage of the proposed value. 2063 See text in Appendix C.6.4.1 for details (the 2064 paragraph that begins "Other smf_info token ..."). 2066 Initial values for this repository appear below: 2068 "ignore": Defined in Appendix C.6.4.1 of this memo. 2069 "sdp_start": Defined in Appendix C.6.4.1 of this memo. 2070 "identity": Defined in Appendix C.6.4.1 of this memo. 2072 11.3. asc Media Type Registration 2074 This section registers "asc" as a subtype for the "audio" media type. 2075 We register this subtype to support the remote transfer of the "config" 2076 parameter of the mpeg4-generic media type [RFC3640] when it is used with 2077 mpeg4-generic mode rtp-midi (registered in Appendix 11.2 above). We 2078 explain the mechanics of using "audio/asc" to set the config parameter 2079 in Section 6.2 and Appendix C.6.5 of this document. 2081 Note that this registration is a new subtype registration and is not an 2082 addition to a repository defined by MPEG-related memos (such as 2083 [RFC3640]). Also note that this request for "audio/asc" does not 2084 register parameters, and does not request the creation of a repository. 2086 Media type name: 2088 audio 2090 Subtype name: 2092 asc 2094 Required parameters: 2096 None. 2098 Optional parameters: 2100 None. 2102 Encoding considerations: 2104 The native form of the data object is binary data, 2105 zero-padded to an octet boundary. 2107 Restrictions on usage: 2109 This type is only defined for data object (stored file) 2110 transfer. The most common transports for the type are 2111 HTTP and SMTP. 2113 Security considerations: 2115 See Section 9 of this memo. 2117 Interoperability considerations: 2119 None. 2121 Published specification: 2123 The audio/asc data object is the AudioSpecificConfig 2124 binary data structure, which is normatively defined in [MPEGAUDIO]. 2126 Applications that use this media type: 2128 MPEG 4 Audio servers and terminals that support 2129 audio/mpeg4-generic RTP streams for mode rtp-midi. 2131 Additional information: 2133 None. 2135 Person & email address to contact for further information: 2137 John Lazzaro 2139 Intended usage: 2141 COMMON. 2143 Author: 2145 John Lazzaro 2147 Change controller: 2149 IETF Audio/Video Transport Working Group delegated 2150 from the IESG. 2152 A. The Recovery Journal Channel Chapters 2154 A.1. Recovery Journal Definitions 2156 This appendix defines the terminology and the coding idioms that are 2157 used in the recovery journal bitfield descriptions in Section 5 (journal 2158 header structure), Appendices A.2 to A.9 (channel journal chapters) and 2159 Appendices B.1 to B.5 (system journal chapters). 2161 We assume that the recovery journal resides in the journal section of an 2162 RTP packet with sequence number I ("packet I") and that the Checkpoint 2163 Packet Seqnum field in the top-level recovery journal header refers to a 2164 previous packet with sequence number C (an exception is the self- 2165 referential C = I case). Unless stated otherwise, algorithms are 2166 assumed to use modulo 2^16 arithmetic for calculations on 16-bit 2167 sequence numbers and modulo 2^32 arithmetic for calculations on 32-bit 2168 extended sequence numbers. 2170 Several bitfield coding idioms appear throughout the recovery journal 2171 system, with consistent semantics. Most recovery journal elements begin 2172 with an "S" (Single-packet loss) bit. S bits are designed to help 2173 receivers efficiently parse through the recovery journal hierarchy in 2174 the common case of the loss of a single packet. 2176 As a rule, S bits MUST be set to 1. However, an exception applies if a 2177 recovery journal element in packet I encodes data about a command stored 2178 in the MIDI command section of packet I - 1. In this case, the S bit of 2179 the recovery journal element MUST be set to 0. If a recovery journal 2180 element has its S bit set to 0, all higher-level recovery journal 2181 elements that contain it MUST also have S bits that are set to 0, 2182 including the top-level recovery journal header. 2184 Other consistent bitfield coding idioms are described below: 2186 o R flag bit. R flag bits are reserved for future use. Senders 2187 MUST set R bits to 0. Receivers MUST ignore R bit values. 2189 o LENGTH field. All fields named LENGTH (as distinct from LEN) 2190 code the number of octets in the structure that contains it, 2191 including the header it resides in and all hierarchical levels 2192 below it. If a structure contains a LENGTH field, a receiver 2193 MUST use the LENGTH field value to advance past the structure 2194 during parsing, rather than use knowledge about the internal 2195 format of the structure. 2197 We now define normative terms used to describe recovery journal 2198 semantics. 2200 o Checkpoint history. The checkpoint history of a recovery journal 2201 is the concatenation of the MIDI command sections of packets C 2202 through I - 1. The final command in the MIDI command section for 2203 packet I - 1 is considered the most recent command; the first 2204 command in the MIDI command section for packet C is the oldest 2205 command. If command X is less recent than command Y, X is 2206 considered to be "before Y". A checkpoint history with no 2207 commands is considered to be empty. The checkpoint history 2208 never contains the MIDI command section of packet I (the 2209 packet containing the recovery journal), so if C == I, the 2210 checkpoint history is empty by definition. 2212 o Session history. The session history of a recovery journal is 2213 the concatenation of MIDI command sections from the first 2214 packet of the session up to packet I - 1. The definitions of 2215 command recency and history emptiness follow those in the 2216 checkpoint history. The session history never contains the 2217 MIDI command section of packet I, and so the session history of 2218 the first packet in the session is empty by definition. 2220 o Finished/unfinished commands. If all octets of a MIDI command 2221 appear in the session history, the command is defined as being 2222 finished. If some but not all octets of a command appear 2223 in the session history, the command is defined as being unfinished. 2224 Unfinished commands occur if segments of a SysEx command appear 2225 in several RTP packets. For example, if a SysEx command is coded 2226 as 3 segments, with segment 1 in packet K, segment 2 in packet 2227 K + 1, and segment 3 in packet K + 2, the session histories for 2228 packets K + 1 and K + 2 contain unfinished versions of the command. 2229 A session history contains a finished version of a cancelled SysEx 2230 command if the history contains the cancel sublist for the command. 2232 o Reset State commands. Reset State (RS) commands reset 2233 renderers to an initialized "powerup" condition. The 2234 RS commands are: System Reset (0xFF), General MIDI System Enable 2235 (0xF0 0x7E 0xcc 0x09 0x01 0xF7), General MIDI 2 System Enable 2236 (0xF0 0x7E 0xcc 0x09 0x03 0xF7), General MIDI System Disable 2237 (0xF0 0x7E 0xcc 0x09 0x00 0xF7), Turn DLS On (0xF0 0x7E 0xcc 0x0A 2238 0x01 0xF7), and Turn DLS Off (0xF0 0x7E 0xcc 0x0A 0x02 0xF7). 2239 Registrations of subrender parameter token values (Appendix C.6.2) 2240 and IETF standards-track documents MAY specify additional 2241 RS commands. 2243 o Active commands. Active command are MIDI commands that do not 2244 appear before a Reset State command in the session history. 2246 o N-active commands. N-active commands are MIDI commands that do 2247 not appear before one of the following commands in the session 2248 history: MIDI Control Change numbers 123-127 (numbers with All 2249 Notes Off semantics) or 120 (All Sound Off), and any Reset 2250 State command. 2252 o C-active commands. C-active commands are MIDI commands that do 2253 not appear before one of the following commands in the session 2254 history: MIDI Control Change number 121 (Reset All Controllers) 2255 and any Reset State command. 2257 o Oldest-first ordering rule. Several recovery journal chapters 2258 contain a list of elements, where each element is associated 2259 with a MIDI command that appears in the session history. In 2260 most cases, the chapter definition requires that list elements 2261 be ordered in accordance with the "oldest-first ordering rule". 2262 Below, we normatively define this rule: 2264 Elements associated with the most recent command in the session 2265 history coded in the list MUST appear at the end of the list. 2267 Elements associated with the oldest command in the session 2268 history coded in the list MUST appear at the start of the list. 2270 All other list elements MUST be arranged with respect to these 2271 boundary elements, to produce a list ordering that strictly 2272 reflects the relative session history recency of the commands 2273 coded by the elements in the list. 2275 o Parameter system. A MIDI feature that provides two sets of 2276 16,384 parameters to expand the 0-127 controller number space. 2277 The Registered Parameter Names (RPN) system and the Non-Registered 2278 Parameter Names (NRPN) system each provides 16,384 parameters. 2280 o Parameter system transaction. The value of RPNs and NRPNs are 2281 changed by a series of Control Change commands that form a 2282 parameter system transaction. A canonical transaction begins 2283 with two Control Change commands to set the parameter number 2284 (controller numbers 99 and 98 for NRPNs, controller numbers 101 2285 and 100 for RPNs). The transaction continues with an arbitrary 2286 number of Data Entry (controller numbers 6 and 38), Data Increment 2287 (controller number 96), and Data Decrement (controller number 2288 97) Control Change commands to set the parameter value. The 2289 transaction ends with a second pair of (99, 98) or (101, 100) 2290 Control Change commands that specify the null parameter (MSB 2291 value 0x7F, LSB value 0x7F). 2293 Several variants of the canonical transaction sequence are 2294 possible. Most commonly, the terminal pair of (99, 98) or 2295 (101, 100) Control Change commands may specify a parameter 2296 other than the null parameter. In this case, the command 2297 pair terminates the first transaction and starts a second 2298 transaction. The command pair is considered to be a part 2299 of both transactions. This variant is legal and recommended 2300 in [MIDI]. We refer to this variant as a "type 1 variant". 2302 Less commonly, the MSB (99 or 101) or LSB (98 or 100) command 2303 of a (99, 98) or (101, 100) Control Change pair may be omitted. 2305 If the MSB command is omitted, the transaction uses the MSB value 2306 of the most recent C-active Control Change command for controller 2307 number 99 or 101 that appears in the session history. We refer to 2308 this variant as a "type 2 variant". 2310 If the LSB command is omitted, the LSB value 0x00 is assumed. We 2311 refer to this variant as a "type 3 variant". The type 2 and type 3 2312 variants are defined as legal, but are not recommended, in [MIDI]. 2314 System real-time commands may appear at any point during 2315 a transaction (even between octets of individual commands 2316 in the transaction). More generally, [MIDI] does not forbid 2317 the appearance of unrelated MIDI commands during an open 2318 transaction. As a rule, these commands are considered to 2319 be "outside" the transaction and do not affect the status 2320 of the transaction in any way. Exceptions to this rule are 2321 commands whose semantics act to terminate transactions: 2322 Reset State commands, and Control Change (0xB) for controller 2323 number 121 (Reset All Controllers) [RP015]. 2325 o Initiated parameter system transaction. A canonical parameter 2326 system transaction whose (99, 98) or (101, 100) initial Control 2327 Change command pair appears in the session history is considered 2328 to be an initiated parameter system transaction. This definition 2329 also holds for type 1 variants. For type 2 variants (dropped MSB), 2330 a transaction whose initial LSB Control Change command appears in 2331 the session history is an initiated transaction. For type 3 2332 variants (dropped LSB), a transaction is considered to be 2333 initiated if at least one transaction command follows the initial 2334 MSB (99 or 101) Control Change command in the session history. 2335 The completion of a transaction does not nullify its "initiated" 2336 status. 2338 o Session history reference counts. Several recovery journal 2339 chapters include a reference count field, which codes the 2340 total number of commands of a type that appear in the session 2341 history. Examples include the Reset and Tune Request command 2342 logs (Chapter D, Appendix B.1) and the Active Sense command 2343 (Chapter V, Appendix B.2). Upon the detection of a loss event, 2344 reference count fields let a receiver deduce if any instances of 2345 the command have been lost, by comparing the journal reference 2346 count with its own reference count. Thus, a reference count 2347 field makes sense, even for command types in which knowing the 2348 NUMBER of lost commands is irrelevant (as is true with all of 2349 the example commands mentioned above). 2351 The chapter definitions in Appendices A.2 to A.9 and B.1 to B.5 reflect 2352 the default recovery journal behavior. The ch_default, ch_never, and 2353 ch_anchor parameters modify these definitions, as described in Appendix 2354 C.2.3. 2356 The chapter definitions specify if data MUST be present in the journal. 2357 Senders MAY also include non-required data in the journal. This 2358 optional data MUST comply with the normative chapter definition. For 2359 example, if a chapter definition states that a field codes data from the 2360 most recent active command in the session history, the sender MUST NOT 2361 code inactive commands or older commands in the field. 2363 Finally, we note that a channel journal only encodes information about 2364 MIDI commands appearing on the MIDI channel the journal protects. All 2365 references to MIDI commands in Appendices A.2 to A.9 should be read as 2366 "MIDI commands appearing on this channel." 2367 A.2. Chapter P: MIDI Program Change 2369 A channel journal MUST contain Chapter P if an active Program Change 2370 (0xC) command appears in the checkpoint history. Figure A.2.1 shows the 2371 format for Chapter P. 2373 0 1 2 2374 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 2375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2376 |S| PROGRAM |B| BANK-MSB |X| BANK-LSB | 2377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2379 Figure A.2.1 -- Chapter P format 2381 The chapter has a fixed size of 24 bits. The PROGRAM field indicates 2382 the data value of the most recent active Program Change command in the 2383 session history. By default, the B, BANK-MSB, X, and BANK-LSB fields 2384 MUST be set to 0. Below, we define exceptions to this default 2385 condition. 2387 If an active Control Change (0xB) command for controller number 0 (Bank 2388 Select MSB) appears before the Program Change command in the session 2389 history, the B bit MUST be set to 1, and the BANK-MSB field MUST code 2390 the data value of the Control Change command. 2392 If B is set to 1, the BANK-LSB field MUST code the data value of the 2393 most recent Control Change command for controller number 32 (Bank Select 2394 LSB) that preceded the Program Change command coded in the PROGRAM field 2395 and followed the Control Change command coded in the BANK-MSB field. If 2396 no such Control Change command exists, the BANK-LSB field MUST be set to 2397 0. 2399 If B is set to 1, and if a Control Change command for controller number 2400 121 (Reset All Controllers) appears in the MIDI stream between the 2401 Control Change command coded by the BANK-MSB field and the Program 2402 Change command coded by the PROGRAM field, the X bit MUST be set to 1. 2404 Note that [RP015] specifies that Reset All Controllers does not reset 2405 the values of controller numbers 0 (Bank Select MSB) and 32 (Bank Select 2406 LSB). Thus, the X bit does not effect how receivers will use the BANK- 2407 LSB and BANK-MSB values when recovering from a lost Program Change 2408 command. The X bit serves to aid recovery in MIDI applications where 2409 controller numbers 0 and 32 are used in a non-standard way. 2411 A.3. Chapter C: MIDI Control Change 2413 Figure A.3.1 shows the format for Chapter C. 2415 0 1 2 3 2416 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 8 0 1 2417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2418 |S| LEN |S| NUMBER |A| VALUE/ALT |S| NUMBER | 2419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2420 |A| VALUE/ALT | .... | 2421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2423 Figure A.3.1 -- Chapter C format 2425 The chapter consists of a 1-octet header, followed by a variable length 2426 list of 2-octet controller logs. The list MUST contain at least one 2427 controller log. The 7-bit LEN field codes the number of controller logs 2428 in the list, minus one. We define the semantics of the controller log 2429 fields in Appendix A.3.2. 2431 A channel journal MUST contain Chapter C if the rules defined in this 2432 appendix require that one or more controller logs appear in the list. 2434 A.3.1. Log Inclusion Rules 2436 A controller log encodes information about a particular Control Change 2437 command in the session history. 2439 In the default use of the payload format, list logs MUST encode 2440 information about the most recent active command in the session history 2441 for a controller number. Logs encoding earlier commands MUST NOT appear 2442 in the list. 2444 Also, as a rule, the list MUST contain a log for the most recent active 2445 command for a controller number that appears in the checkpoint history. 2446 Below, we define exceptions to this rule: 2448 o MIDI streams may transmit 14-bit controller values using paired 2449 Most Significant Byte (MSB, controller numbers 0-31, 99, 101) and 2450 Least Significant Byte (LSB, controller numbers 32-63, 98, 100) 2451 Control Change commands [MIDI]. 2453 If the most recent active Control Change command in the session 2454 history for a 14-bit controller pair uses the MSB number, Chapter 2455 C MAY omit the controller log for the most recent active Control 2456 Change command for the associated LSB number, as the command 2457 ordering makes this LSB value irrelevant. However, this exception 2458 MUST NOT be applied if the sender is not certain that the MIDI 2459 source uses 14-bit semantics for the controller number pair. Note 2460 that some MIDI sources ignore 14-bit controller semantics and use 2461 the LSB controller numbers as independent 7-bit controllers. 2463 o If active Control Change commands for controller numbers 0 (Bank 2464 Select MSB) or 32 (Bank Select LSB) appear in the checkpoint 2465 history, and if the command instances are also coded in the 2466 BANK-MSB and BANK-LSB fields of the Chapter P (Appendix A.2), 2467 Chapter C MAY omit the controller logs for the commands. 2469 o Several controller number pairs are defined to be mutually 2470 exclusive. Controller numbers 124 (Omni Off) and 125 (Omni On) 2471 form a mutually exclusive pair, as do controller numbers 126 2472 (Mono) and 127 (Poly). 2474 If active Control Change commands for one or both members of 2475 a mutually exclusive pair appear in the checkpoint history, a 2476 log for the controller number of the most recent command for the 2477 pair in the checkpoint history MUST appear in the controller list. 2478 However, the list MAY omit the controller log for the most recent 2479 active command for the other number in the pair. 2481 If active Control Change commands for one or both members of a 2482 mutually exclusive pair appear in the session history, and if a 2483 log for the controller number of the most recent command for the 2484 pair does not appear in the controller list, a log for the most 2485 recent command for the other number of the pair MUST NOT appear 2486 in the controller list. 2488 o If an active Control Change command for controller number 121 2489 (Reset All Controllers) appears in the session history, the 2490 controller list MAY omit logs for Control Change commands that 2491 precede the Reset All Controllers command in the session history, 2492 under certain conditions. 2494 Namely, a log MAY be omitted if the sender is certain that a 2495 command stream follows the Reset All Controllers semantics 2496 defined in [RP015], and if the log codes a controller number 2497 for which [RP015] specifies a reset value. 2499 For example, [RP015] specifies that controller number 1 2500 (Modulation Wheel) is reset to the value 0, and thus 2501 a controller log for Modulation Wheel MAY be omitted 2502 from the controller log list. In contrast, [RP015] specifies 2503 that controller number 7 (Channel Volume) is not reset, 2504 and thus a controller log for Channel Volume MUST NOT 2505 be omitted from the controller log list. 2507 o Appendix A.3.4 defines exception rules for the MIDI Parameter 2508 System controller numbers 6, 38, and 96-101. 2510 A.3.2. Controller Log Format 2512 Figure A.3.2 shows the controller log structure of Chapter C. 2514 0 1 2515 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2517 |S| NUMBER |A| VALUE/ALT | 2518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2520 Figure A.3.2 -- Chapter C controller log 2522 The 7-bit NUMBER field identifies the controller number of the coded 2523 command. The 7-bit VALUE/ALT field codes recovery information for the 2524 command. The A bit sets the format of the VALUE/ALT field. 2526 A log encodes recovery information using one of the following tools: the 2527 value tool, the toggle tool, or the count tool. 2529 A log uses the value tool if the A bit is set to 0. The value tool 2530 codes the 7-bit data value of a command in the VALUE/ALT field. The 2531 value tool works best for controllers that code a continuous quantity, 2532 such as number 1 (Modulation Wheel). 2534 The A bit is set to 1 to code the toggle or count tool. These tools 2535 work best for controllers that code discrete actions. Figure A.3.3 2536 shows the controller log for these tools. 2538 0 1 2539 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2541 |S| NUMBER |1|T| ALT | 2542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2544 Figure A.3.3 -- Controller log for ALT tools 2546 A log uses the toggle tool if the T bit is set to 0. A log uses the 2547 count tool if the T bit is set to 1. Both methods use the 6-bit ALT 2548 field as an unsigned integer. 2550 The toggle tool works best for controllers that act as on/off switches, 2551 such as 64 (Damper Pedal (Sustain)). These controllers code the "off" 2552 state with control values 0-63 and the "on" state with 64-127. 2554 For the toggle tool, the ALT field codes the total number of toggles 2555 (off->on and on->off) due to Control Change commands in the session 2556 history, up to and including a toggle caused by the command coded by the 2557 log. The toggle count includes toggles caused by Control Change 2558 commands for controller number 121 (Reset All Controllers). 2560 Toggle counting is performed modulo 64. The toggle count is reset at 2561 the start of a session, and whenever a Reset State command (Appendix 2562 A.1) appears in the session history. When these reset events occur, the 2563 toggle count for a controller is set to 0 (for controllers whose default 2564 value is 0-63) or 1 (for controllers whose default value is 64-127). 2566 The Damper Pedal (Sustain) controller illustrates the benefits of the 2567 toggle tool over the value tool for switch controllers. As often used 2568 in piano applications, the "on" state of the controller lets notes 2569 resonate, while the "off" state immediately damps notes to silence. The 2570 loss of the "off" command in an "on->off->on" sequence results in 2571 ringing notes that should have been damped silent. The toggle tool lets 2572 receivers detect this lost "off" command, but the value tool does not. 2574 The count tool is conceptually similar to the toggle tool. For the 2575 count tool, the ALT field codes the total number of Control Change 2576 commands in the session history, up to and including the command coded 2577 by the log. Command counting is performed modulo 64. The command count 2578 is set to 0 at the start of the session and is reset to 0 whenever a 2579 Reset State command (Appendix A.1) appears in the session history. 2581 Because the count tool ignores the data value, it is a good match for 2582 controllers whose controller value is ignored, such as number 123 (All 2583 Notes Off). More generally, the count tool may be used to code a 2584 (modulo 64) identification number for a command. 2586 A.3.3. Log List Coding Rules 2588 In this section, we describe the organization of controller logs in the 2589 Chapter C log list. 2591 A log encodes information about a particular Control Change command in 2592 the session history. In most cases, a command SHOULD be coded by a 2593 single tool (and, thus, a single log). If a number is coded with a 2594 single tool and this tool is the count tool, recovery Control Change 2595 commands generated by a receiver SHOULD use the default control value 2596 for the controller. 2598 However, a command MAY be coded by several tool types (and, thus, 2599 several logs, each using a different tool). This technique may improve 2600 recovery performance for controllers with complex semantics, such as 2601 controller number 84 (Portamento Control) or controller number 121 2602 (Reset All Controllers) when used with a non-zero data octet (with the 2603 semantics described in [DLS2]). 2605 If a command is encoded by multiple tools, the logs MUST be placed in 2606 the list in the following order: count tool log (if any), followed by 2607 value tool log (if any), followed by toggle tool log (if any). 2609 The Chapter C log list MUST obey the oldest-first ordering rule (defined 2610 in Appendix A.1). Note that this ordering preserves the information 2611 necessary for the recovery of 14-bit controller values, without 2612 precluding the use of MSB and LSB controller pairs as independent 7-bit 2613 controllers. 2615 In the default use of the payload format, all logs that appear in the 2616 list for a controller number encode information about one Control Change 2617 command -- namely, the most recent active Control Change command in the 2618 session history for the number. 2620 This coding scheme provides good recovery performance for the standard 2621 uses of Control Change commands defined in [MIDI]. However, not all 2622 MIDI applications restrict the use of Control Change commands to those 2623 defined in [MIDI]. 2625 For example, consider the common MIDI encoding of rotary encoders 2626 ("infinite" rotation knobs). The mixing console MIDI convention defined 2627 in [LCP] codes the position of rotary encoders as a series of Control 2628 Change commands. Each command encodes a relative change of knob 2629 position from the last update (expressed as a clockwise or counter- 2630 clockwise knob turning angle). 2632 As the knob position is encoded incrementally over a series of Control 2633 Change commands, the best recovery performance is obtained if the log 2634 list encodes all Control Change commands for encoder controller numbers 2635 that appear in the checkpoint history, not only the most recent command. 2637 To support application areas that use Control Change commands in this 2638 way, Chapter C may be configured to encode information about several 2639 Control Change commands for a controller number. We use the term 2640 "enhanced" to describe this encoding method, which we describe below. 2642 In Appendix C.2.3, we show how to configure a stream to use enhanced 2643 Chapter C encoding for specific controller numbers. In Section 5 in the 2644 main text, we show how the H bits in the recovery journal header (Figure 2645 8) and in the channel journal header (Figure 9) indicate the use of 2646 enhanced Chapter C encoding. 2648 Here, we define how to encode a Chapter C log list that uses the 2649 enhanced encoding method. 2651 Senders that use the enhanced encoding method for a controller number 2652 MUST obey the rules below. These rules let a receiver determine which 2653 logs in the list correspond to lost commands. Note that these rules 2654 override the exceptions listed in Appendix A.3.1. 2656 o If N commands for a controller number are encoded in the list, 2657 the commands MUST be the N most recent commands for the controller 2658 number in the session history. For example, for N = 2, the sender 2659 MUST encode the most recent command and the second most recent 2660 command, not the most recent command and the third most recent 2661 command. 2663 o If a controller number uses enhanced encoding, the encoding 2664 of the least-recent command for the controller number in the 2665 log list MUST include a count tool log. In addition, if 2666 commands are encoded for the controller number whose logs 2667 have S bits set to 0, the encoding of the least-recent 2668 command with S = 0 logs MUST include a count tool log. 2670 The count tool is OPTIONAL for the other commands for the 2671 controller number encoded in the list, as a receiver is 2672 able to efficiently deduce the count tool value for these 2673 commands, for both single-packet and multi-packet loss events. 2675 o The use of the value and toggle tools MUST be identical for all 2676 commands for a controller number encoded in the list. For 2677 example, a value tool log either MUST appear for all commands 2678 for the controller number coded in the list, or alternatively, 2679 value tool logs for the controller number MUST NOT appear in 2680 the list. Likewise, a toggle tool log either MUST appear for 2681 all commands for the controller number coded in the list, or 2682 alternatively, toggle tool logs for the controller number MUST 2683 NOT appear in the list. 2685 o If a command is encoded by multiple tools, the logs MUST be 2686 placed in the list in the following order: count tool log 2687 (if any), followed by value tool log (if any), followed by 2688 toggle tool log (if any). 2690 These rules permit a receiver recovering from a packet loss to use the 2691 count tool log to match the commands encoded in the list with its own 2692 history of the stream, as we describe below. Note that the text below 2693 describes a non-normative algorithm; receivers are free to use any 2694 algorithm to match its history with the log list. 2696 In a typical implementation of the enhanced encoding method, a receiver 2697 computes and stores count, value, and toggle tool data field values for 2698 the most recent Control Change command it has received for a controller 2699 number. 2701 After a loss event, a receiver parses the Chapter C list and processes 2702 list logs for a controller number that uses enhanced encoding as 2703 follows. 2705 The receiver compares the count tool ALT field for the least-recent 2706 command for the controller number in the list against its stored count 2707 data for the controller number, to determine if recovery is necessary 2708 for the command coded in the list. The value and toggle tool logs (if 2709 any) that directly follow the count tool log are associated with this 2710 least-recent command. 2712 To check more-recent commands for the controller, the receiver detects 2713 additional value and/or toggle tool logs for the controller number in 2714 the list and infers count tool data for the command coded by these logs. 2715 This inferred data is used to determine if recovery is necessary for the 2716 command coded by the value and/or toggle tool logs. 2718 In this way, a receiver is able to execute only lost commands, without 2719 executing a command twice. While recovering from a single packet loss, 2720 a receiver may skip through S = 1 logs in the list, as the first S = 0 2721 log for an enhanced controller number is always a count tool log. 2723 Note that the requirements in Appendix C.2.2.2 for protective sender and 2724 receiver actions during session startup for multicast operation are of 2725 particular importance for enhanced encoding, as receivers need to 2726 initialize its count tool data structures with recovery journal data in 2727 order to match commands correctly after a loss event. 2729 Finally, we note in passing that in some applications of rotary 2730 encoders, a good user experience may be possible without the use of 2731 enhanced encoding. These applications are distinguished by visual 2732 feedback of encoding position that is driven by the post-recovery rotary 2733 encoding stream, and relatively low packet loss. In these domains, 2734 recovery performance may be acceptable for rotary encoders if the log 2735 list encodes only the most recent command, if both count and value logs 2736 appear for the command. 2738 A.3.4. The Parameter System 2740 Readers may wish to review the Appendix A.1 definitions of "parameter 2741 system", "parameter system transaction", and "initiated parameter system 2742 transaction" before reading this section. 2744 Parameter system transactions update a MIDI Registered Parameter Number 2745 (RPN) or Non-Registered Parameter Number (NRPN) value. A parameter 2746 system transaction is a sequence of Control Change commands that may use 2747 the following controllers numbers: 2749 o Data Entry MSB (6) 2750 o Data Entry LSB (38) 2751 o Data Increment (96) 2752 o Data Decrement (97) 2753 o Non-Registered Parameter Number (NRPN) LSB (98) 2754 o Non-Registered Parameter Number (NRPN) MSB (99) 2755 o Registered Parameter Number (RPN) LSB (100) 2756 o Registered Parameter Number (RPN) MSB (101) 2758 Control Change commands that are a part of a parameter system 2759 transaction MUST NOT be coded in Chapter C controller logs. Instead, 2760 these commands are coded in Chapter M, the MIDI Parameter chapter 2761 defined in Appendix A.4. 2763 However, Control Change commands that use the listed controllers as 2764 general-purpose controllers (i.e., outside of a parameter system 2765 transaction) MUST NOT be coded in Chapter M. 2767 Instead, the controllers are coded in Chapter C controller logs. The 2768 controller logs follow the coding rules stated in Appendix A.3.2 and 2769 A.3.3. The rules for coding paired LSB and MSB controllers, as defined 2770 in Appendix A.3.1, apply to the pairs (6, 38), (99, 98), and (101, 100) 2771 when coded in Chapter C. 2773 If active Control Change commands for controller numbers 6, 38, or 2774 96-101 appear in the checkpoint history, and these commands are used as 2775 general-purpose controllers, the most recent general-purpose command 2776 instance for these controller numbers MUST appear as entries in the 2777 Chapter C controller list. 2779 MIDI syntax permits a source to use controllers 6, 38, 96, and 97 as 2780 parameter-system controllers and general-purpose controllers in the same 2781 stream. An RTP MIDI sender MUST deduce the role of each Control Change 2782 command for these controller numbers by noting the placement of the 2783 command in the stream and MUST use this information to code the command 2784 in Chapter C or Chapter M, as appropriate. 2786 Specifically, active Control Change commands for controllers 6, 38, 96, 2787 and 97 act in a general-purpose way when 2789 o no active Control Change commands that set an RPN or 2790 NRPN parameter number appear in the session history, or 2792 o the most recent active Control Change commands in the session 2793 history that set an RPN or NRPN parameter number code the null 2794 parameter (MSB value 0x7F, LSB value 0x7F), or 2796 o a Control Change command for controller number 121 (Reset 2797 All Controllers) appears more recently in the session history 2798 than all active Control Change commands that set an RPN or 2799 NRPN parameter number (see [RP015] for details). 2801 Finally, we note that a MIDI source that follows the recommendations of 2802 [MIDI] exclusively uses numbers 98-101 as parameter system controllers. 2803 Alternatively, a MIDI source may exclusively use 98-101 as general- 2804 purpose controllers and lose the ability to perform parameter system 2805 transactions in a stream. 2807 In the language of [MIDI], the general-purpose use of controllers 98-101 2808 constitutes a non-standard controller assignment. As most real-world 2809 MIDI sources use the standard controller assignment for controller 2810 numbers 98-101, an RTP MIDI sender SHOULD assume these controllers act 2811 as parameter system controllers, unless it knows that a MIDI source uses 2812 controller numbers 98-101 in a general-purpose way. 2814 A.4. Chapter M: MIDI Parameter System 2816 Readers may wish to review the Appendix A.1 definitions for "C-active", 2817 "parameter system", "parameter system transaction", and "initiated 2818 parameter system transaction" before reading this appendix. 2820 Chapter M protects parameter system transactions for Registered 2821 Parameter Number (RPN) and Non-Registered Parameter Number (NRPN) 2822 values. Figure A.4.1 shows the format for Chapter M. 2824 0 1 2 3 2825 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 2826 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2827 |S|P|E|U|W|Z| LENGTH |Q| PENDING | Log list ... | 2828 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2830 Figure A.4.1 -- Top-level Chapter M format 2832 Chapter M begins with a 2-octet header. If the P header bit is set to 2833 1, a 1-octet field follows the header, coding the 7-bit PENDING value 2834 and its associated Q bit. 2836 The 10-bit LENGTH field codes the size of Chapter M and conforms to 2837 semantics described in Appendix A.1. 2839 Chapter M ends with a list of zero or more variable-length parameter 2840 logs. Appendix A.4.2 defines the bitfield format of a parameter log. 2841 Appendix A.4.1 defines the inclusion semantics of the log list. 2843 A channel journal MUST contain Chapter M if the rules defined in 2844 Appendix A.4.1 require that one or more parameter logs appear in the 2845 list. 2847 A channel journal also MUST contain Chapter M if the most recent C- 2848 active Control Change command involved in a parameter system transaction 2849 in the checkpoint history is 2851 o an RPN MSB (101) or NRPN MSB (99) controller, or 2853 o an RPN LSB (100) or NRPN LSB (98) controller that completes the 2854 coding of the null parameter (MSB value 0x7F, LSB value 0x7F). 2856 This rule provides loss protection for partially transmitted parameter 2857 numbers and for the null parameter numbers. 2859 If the most recent C-active Control Change command involved in a 2860 parameter system transaction in the session history is for the RPN MSB 2861 or NRPN MSB controller, the P header bit MUST be set to 1, and the 2862 PENDING field (and its associated Q bit) MUST follow the Chapter M 2863 header. Otherwise, the P header bit MUST be set to 0, and the PENDING 2864 field and Q bit MUST NOT appear in Chapter M. 2866 If PENDING codes an NRPN MSB, the Q bit MUST be set to 1. If PENDING 2867 codes an RPN MSB, the Q bit MUST be set to 0. 2869 The E header bit codes the current transaction state of the MIDI stream. 2870 If E = 1, an initiated transaction is in progress. Below, we define the 2871 rules for setting the E header bit: 2873 o If no C-active parameter system transaction Control Change 2874 commands appear in the session history, the E bit MUST be 2875 set to 0. 2877 o If the P header bit is set to 1, the E bit MUST be set to 0. 2879 o If the most recent C-active parameter system transaction 2880 Control Change command in the session history is for the 2881 NRPN LSB or RPN LSB controller number, and if this command 2882 acts to complete the coding of the null parameter (MSB 2883 value 0x7F, LSB value 0x7F), the E bit MUST be set to 0. 2885 o Otherwise, an initiated transaction is in progress, and the 2886 E bit MUST be set to 1. 2888 The U, W, and Z header bits code properties that are shared by all 2889 parameter logs in the list. If these properties are set, parameter logs 2890 may be coded with improved efficiency (we explain how in A.4.1). 2892 By default, the U, W, and Z bits MUST be set to 0. If all parameter 2893 logs in the list code RPN parameters, the U bit MAY be set to 1. If all 2894 parameter logs in the list code NRPN parameters, the W bit MAY be set to 2895 1. If the parameter numbers of all RPN and NRPN logs in the list lie in 2896 the range 0-127 (and thus have an MSB value of 0), the Z bit MAY be set 2897 to 1. 2899 Note that C-active semantics appear in the preceding paragraphs because 2900 [RP015] specifies that pending Parameter System transactions are closed 2901 by a Control Change command for controller number 121 (Reset All 2902 Controllers). 2904 A.4.1. Log Inclusion Rules 2906 Parameter logs code recovery information for a specific RPN or NRPN 2907 parameter. 2909 A parameter log MUST appear in the list if an active Control Change 2910 command that forms a part of an initiated transaction for the parameter 2911 appears in the checkpoint history. 2913 An exception to this rule applies if the checkpoint history only 2914 contains transaction Control Change commands for controller numbers 2915 98-101 that act to terminate the transaction. In this case, a log for 2916 the parameter MAY be omitted from the list. 2918 A log MAY appear in the list if an active Control Change command that 2919 forms a part of an initiated transaction for the parameter appears in 2920 the session history. Otherwise, a log for the parameter MUST NOT appear 2921 in the list. 2923 Multiple logs for the same RPN or NRPN parameter MUST NOT appear in the 2924 log list. 2926 The parameter log list MUST obey the oldest-first ordering rule (defined 2927 in Appendix A.1), with the phrase "parameter transaction" replacing the 2928 word "command" in the rule definition. 2930 Parameter logs associated with the RPN or NRPN null parameter (LSB = 2931 0x7F, MSB = 0x7F) MUST NOT appear in the log list. Chapter M uses the E 2932 header bit (Figure A.4.1) and the log list ordering rules to code null 2933 parameter semantics. 2935 Note that "active" semantics (rather than "C-active" semantics) appear 2936 in the preceding paragraphs because [RP015] specifies that pending 2937 Parameter System transactions are not reset by a Control Change command 2938 for controller number 121 (Reset All Controllers). However, the rule 2939 that follows uses C-active semantics, because it concerns the protection 2940 of the transaction system itself, and [RP015] specifies that Reset All 2941 Controllers acts to close a transaction in progress. 2943 In most cases, parameter logs for RPN and NRPN parameters that are 2944 assigned to the ch_never parameter (Appendix C.2.3) MAY be omitted from 2945 the list. An exception applies if 2947 o the log codes the most recent initiated transaction 2948 in the session history, and 2950 o a C-active command that forms a part of the transaction 2951 appears in the checkpoint history, and 2953 o the E header bit for the top-level Chapter M header (Figure 2954 A.4.1) is set to 1. 2956 In this case, a log for the parameter MUST appear in the list. This log 2957 informs receivers recovering from a loss that a transaction is in 2958 progress, so that the receiver is able to correctly interpret RPN or 2959 NRPN Control Change commands that follow the loss event. 2961 A.4.2. Log Coding Rules 2963 Figure A.4.2 shows the parameter log structure of Chapter M. 2965 0 1 2 3 2966 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 8 0 1 2967 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2968 |S| PNUM-LSB |Q| PNUM-MSB |J|K|L|M|N|T|V|R| Fields ... | 2969 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2971 Figure A.4.2 -- Parameter log format 2973 The log begins with a header, whose default size (as shown in Figure 2974 A.4.2) is 3 octets. If the Q header bit is set to 0, the log encodes an 2975 RPN parameter. If Q = 1, the log encodes an NRPN parameter. The 7-bit 2976 PNUM-MSB and PNUM-LSB fields code the parameter number and reflect the 2977 Control Change command data values for controllers 99 and 98 (for NRPNs) 2978 or 101 and 100 (for RPNs). 2980 The J, K, L, M, and N header bits form a Table of Contents (TOC) for the 2981 log and signal the presence of fixed-sized fields that follow the 2982 header. A header bit that is set to 1 codes the presence of a field in 2983 the log. The ordering of fields in the log follows the ordering of the 2984 header bits in the TOC. Appendices A.4.2.1-2 define the fields 2985 associated with each TOC header bit. 2987 The T and V header bits code information about the parameter log but are 2988 not part of the TOC. A set T or V bit does not signal the presence of 2989 any parameter log field. 2991 If the rules in Appendix A.4.1 state that a log for a given parameter 2992 MUST appear in Chapter M, the log MUST code sufficient information to 2993 protect the parameter from the loss of active parameter transaction 2994 Control Change commands in the checkpoint history. 2996 This rule does not apply if the parameter coded by the log is assigned 2997 to the ch_never parameter (Appendix C.2.3). In this case, senders MAY 2998 choose to set the J, K, L, M, and N TOC bits to 0, coding a parameter 2999 log with no fields. 3001 Note that logs to protect parameters that are assigned to ch_never are 3002 REQUIRED under certain conditions (see Appendix A.4.1). The purpose of 3003 the log is to inform receivers recovering from a loss that a transaction 3004 is in progress, so that the receiver is able to correctly interpret RPN 3005 or NRPN Control Change commands that follow the loss event. 3007 Parameter logs provide two tools for parameter protection: the value 3008 tool and the count tool. Depending on the semantics of the parameter, 3009 senders may use either tool, both tools, or neither tool to protect a 3010 given parameter. 3012 The value tool codes information a receiver may use to determine the 3013 current value of an RPN or NRPN parameter. If a parameter log uses the 3014 value tool, the V header bit MUST be set to 1, and the semantics defined 3015 in Appendices A.4.2.1 for setting the J, K, L, and M TOC bits MUST be 3016 followed. If a parameter log does not use the value tool, the V bit 3017 MUST be set to 0, and the J, K, L, and M TOC bits MUST also be set to 0. 3019 The count tool codes the number of transactions for an RPN or NRPN 3020 parameter. If a parameter log uses the count tool, the T header bit 3021 MUST be set to 1, and the semantics defined in Appendices A.4.2.2 for 3022 setting the N TOC bit MUST be followed. If a parameter log does not use 3023 the count tool, the T bit and the N TOC bit MUST be set to 0. 3025 Note that V and T are set if the sender uses value (V) or count (T) tool 3026 for the log on an ongoing basis. Thus, V may be set even if J = K = L = 3027 M = 0, and T may be set even if N = 0. 3029 In many cases, all parameters coded in the log list are of one type (RPN 3030 and NRPN), and all parameter numbers lie in the range 0-127. As 3031 described in Appendix A.4.1, senders MAY signal this condition by 3032 setting the top-level Chapter M header bit Z to 1 (to code the 3033 restricted range) and by setting the U or W bit to 1 (to code the 3034 parameter type). 3036 If the top-level Chapter M header codes Z = 1 and either U = 1 or W = 1, 3037 all logs in the parameter log list MUST use a modified header format. 3038 This modification deletes bits 8-15 of the bitfield shown in Figure 3039 A.4.2, to yield a 2-octet header. The values of the deleted PNUM-MSB 3040 and Q fields may be inferred from the U, W, and Z bit values. 3042 A.4.2.1. The Value Tool 3044 The value tool uses several fields to track the value of an RPN or NRPN 3045 parameter. 3047 The J TOC bit codes the presence of the octet shown in Figure A.4.3 in 3048 the field list. 3050 0 3051 0 1 2 3 4 5 6 7 3052 +-+-+-+-+-+-+-+-+ 3053 |X| ENTRY-MSB | 3054 +-+-+-+-+-+-+-+-+ 3056 Figure A.4.3 -- ENTRY-MSB field 3058 The 7-bit ENTRY-MSB field codes the data value of the most recent active 3059 Control Change command for controller number 6 (Data Entry MSB) in the 3060 session history that appears in a transaction for the log parameter. 3062 The X bit MUST be set to 1 if the command coded by ENTRY-MSB precedes 3063 the most recent Control Change command for controller 121 (Reset All 3064 Controllers) in the session history. Otherwise, the X bit MUST be set 3065 to 0. 3067 A parameter log that uses the value tool MUST include the ENTRY-MSB 3068 field if an active Control Change command for controller number 6 3069 appears in the checkpoint history. 3071 Note that [RP015] specifies that Control Change commands for controller 3072 121 (Reset All Controllers) do not reset RPN and NRPN values, and thus 3073 the X bit would not play a recovery role for MIDI systems that comply 3074 with [RP015]. 3076 However, certain renderers (such as DLS 2 [DLS2]) specify that certain 3077 RPN values are reset for some uses of Reset All Controllers. The X bit 3078 (and other bitfield features of this nature in this appendix) plays a 3079 role in recovery for renderers of this type. 3081 The K TOC bit codes the presence of the octet shown in Figure A.4.4 in 3082 the field list. 3084 0 3085 0 1 2 3 4 5 6 7 3086 +-+-+-+-+-+-+-+-+ 3087 |X| ENTRY-LSB | 3088 +-+-+-+-+-+-+-+-+ 3090 Figure A.4.4 -- ENTRY-LSB field 3092 The 7-bit ENTRY-LSB field codes the data value of the most recent active 3093 Control Change command for controller number 38 (Data Entry LSB) in the 3094 session history that appears in a transaction for the log parameter. 3096 The X bit MUST be set to 1 if the command coded by ENTRY-LSB precedes 3097 the most recent Control Change command for controller 121 (Reset All 3098 Controllers) in the session history. Otherwise, the X bit MUST be set 3099 to 0. 3101 As a rule, a parameter log that uses the value tool MUST include the 3102 ENTRY-LSB field if an active Control Change command for controller 3103 number 38 appears in the checkpoint history. However, the ENTRY-LSB 3104 field MUST NOT appear in a parameter log if the Control Change command 3105 associated with the ENTRY-LSB precedes a Control Change command for 3106 controller number 6 (Data Entry MSB) that appears in a transaction for 3107 the log parameter in the session history. 3109 The L TOC bit codes the presence of the octets shown in Figure A.4.5 in 3110 the field list. 3112 0 1 3113 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 3114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3115 |G|X| A-BUTTON | 3116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3118 Figure A.4.5 -- A-BUTTON field 3120 The 14-bit A-BUTTON field codes a count of the number of active Control 3121 Change commands for controller numbers 96 and 97 (Data Increment and 3122 Data Decrement) in the session history that appear in a transaction for 3123 the log parameter. 3125 The M TOC bit codes the presence of the octets shown in Figure A.4.6 in 3126 the field list. 3128 0 1 3129 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 3130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3131 |G|R| C-BUTTON | 3132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3134 Figure A.4.6 -- C-BUTTON field 3136 The 14-bit C-BUTTON field has semantics identical to A-BUTTON, except 3137 that Data Increment and Data Decrement Control Change commands that 3138 precede the most recent Control Change command for controller 121 (Reset 3139 All Controllers) in the session history are not counted. 3141 For both A-BUTTON and C-BUTTON, Data Increment and Data Decrement 3142 Control Change commands are not counted if they precede Control Changes 3143 commands for controller numbers 6 (Data Entry MSB) or 38 (Data Entry 3144 LSB) that appear in a transaction for the log parameter in the session 3145 history. 3147 The A-BUTTON and C-BUTTON fields are interpreted as unsigned integers, 3148 and the G bit associated with the field codes the sign of the integer (G 3149 = 0 for positive or zero, G = 1 for negative). 3151 To compute and code the count value, initialize the count value to 0, 3152 add 1 for each qualifying Data Increment command, and subtract 1 for 3153 each qualifying Data Decrement command. After each add or subtract, 3154 limit the count magnitude to 16383. The G bit codes the sign of the 3155 count, and the A-BUTTON or C-BUTTON field codes the count magnitude. 3157 For the A-BUTTON field, if the most recent qualified Data Increment or 3158 Data Decrement command precedes the most recent Control Change command 3159 for controller 121 (Reset All Controllers) in the session history, the X 3160 bit associated with A-BUTTON field MUST be set to 1. Otherwise, the X 3161 bit MUST be set to 0. 3163 A parameter log that uses the value tool MUST include the A-BUTTON and 3164 C-BUTTON fields if an active Control Change command for controller 3165 numbers 96 or 97 appears in the checkpoint history. However, to improve 3166 coding efficiency, this rule has several exceptions: 3168 o If the log includes the A-BUTTON field, and if the X bit of 3169 the A-BUTTON field is set to 1, the C-BUTTON field (and its 3170 associated R and G bits) MAY be omitted from the log. 3172 o If the log includes the A-BUTTON field, and if the A-BUTTON 3173 and C-BUTTON fields (and their associated G bits) code identical 3174 values, the C-BUTTON field (and its associated R and G bits) 3175 MAY be omitted from the log. 3177 A.4.2.2. The Count Tool 3179 The count tool tracks the number of transactions for an RPN or NRPN 3180 parameter. The N TOC bit codes the presence of the octet shown in 3181 Figure A.4.7 in the field list. 3183 0 3184 0 1 2 3 4 5 6 7 3185 +-+-+-+-+-+-+-+-+ 3186 |X| COUNT | 3187 +-+-+-+-+-+-+-+-+ 3189 Figure A.4.7 -- COUNT field 3191 The 7-bit COUNT codes the number of initiated transactions for the log 3192 parameter that appear in the session history. Initiated transactions 3193 are counted if they contain one or more active Control Change commands, 3194 including commands for controllers 98-101 that initiate the parameter 3195 transaction. 3197 If the most recent counted transaction precedes the most recent Control 3198 Change command for controller 121 (Reset All Controllers) in the session 3199 history, the X bit associated with the COUNT field MUST be set to 1. 3200 Otherwise, the X bit MUST be set to 0. 3202 Transaction counting is performed modulo 128. The transaction count is 3203 set to 0 at the start of a session and is reset to 0 whenever a Reset 3204 State command (Appendix A.1) appears in the session history. 3206 A parameter log that uses the count tool MUST include the COUNT field if 3207 an active command that increments the transaction count (modulo 128) 3208 appears in the checkpoint history. 3210 A.5. Chapter W: MIDI Pitch Wheel 3212 A channel journal MUST contain Chapter W if a C-active MIDI Pitch Wheel 3213 (0xE) command appears in the checkpoint history. Figure A.5.1 shows the 3214 format for Chapter W. 3216 0 1 3217 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 3218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3219 |S| FIRST |R| SECOND | 3220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3222 Figure A.5.1 -- Chapter W format 3224 The chapter has a fixed size of 16 bits. The FIRST and SECOND fields 3225 are the 7-bit values of the first and second data octets of the most 3226 recent active Pitch Wheel command in the session history. 3228 Note that Chapter W encodes C-active commands and thus does not encode 3229 active commands that are not C-active (see the second-to-last paragraph 3230 of Appendix A.1 for an explanation of chapter inclusion text in this 3231 regard). 3233 Chapter W does not encode "active but not C-active" commands because 3234 [RP015] declares that Control Change commands for controller number 121 3235 (Reset All Controllers) act to reset the Pitch Wheel value to 0. If 3236 Chapter W encoded "active but not C-active" commands, a repair operation 3237 following a Reset All Controllers command could incorrectly repair the 3238 stream with a stale Pitch Wheel value. 3240 A.6. Chapter N: MIDI NoteOff and NoteOn 3242 In this appendix, we consider NoteOn commands with zero velocity to be 3243 NoteOff commands. Readers may wish to review the Appendix A.1 3244 definition of "N-active commands" before reading this appendix. 3246 Chapter N completely protects note commands in streams that alternate 3247 between NoteOn and NoteOff commands for a particular note number. 3248 However, in rare applications, multiple overlapping NoteOn commands may 3249 appear for a note number. Chapter E, described in Appendix A.7, 3250 augments Chapter N to completely protect these streams. 3252 A channel journal MUST contain Chapter N if an N-active MIDI NoteOn 3253 (0x9) or NoteOff (0x8) command appears in the checkpoint history. 3254 Figure A.6.1 shows the format for Chapter N. 3256 0 1 2 3 3257 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 8 0 1 3258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3259 |B| LEN | LOW | HIGH |S| NOTENUM |Y| VELOCITY | 3260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3261 |S| NOTENUM |Y| VELOCITY | .... | 3262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3263 | OFFBITS | OFFBITS | .... | OFFBITS | 3264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3266 Figure A.6.1 -- Chapter N format 3268 Chapter N consists of a 2-octet header, followed by at least one of the 3269 following data structures: 3271 o A list of note logs to code NoteOn commands. 3272 o A NoteOff bitfield structure to code NoteOff commands. 3274 We define the header bitfield semantics in Appendix A.6.1. We define 3275 the note log semantics and the NoteOff bitfield semantics in Appendix 3276 A.6.2. 3278 If one or more N-active NoteOn or NoteOff commands in the checkpoint 3279 history reference a note number, the note number MUST be coded in either 3280 the note log list or the NoteOff bitfield structure. 3282 The note log list MUST contain an entry for all note numbers whose most 3283 recent checkpoint history appearance is in an N-active NoteOn command. 3284 The NoteOff bitfield structure MUST contain a set bit for all note 3285 numbers whose most recent checkpoint history appearance is in an N- 3286 active NoteOff command. 3288 A note number MUST NOT be coded in both structures. 3290 All note logs and NoteOff bitfield set bits MUST code the most recent N- 3291 active NoteOn or NoteOff reference to a note number in the session 3292 history. 3294 The note log list MUST obey the oldest-first ordering rule (defined in 3295 Appendix A.1). 3297 A.6.1. Header Structure 3299 The header for Chapter N, shown in Figure A.6.2, codes the size of the 3300 note list and bitfield structures. 3302 0 1 3303 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 3304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3305 |B| LEN | LOW | HIGH | 3306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3308 Figure A.6.2 -- Chapter N header 3310 The LEN field, a 7-bit integer value, codes the number of 2-octet note 3311 logs in the note list. Zero is a valid value for LEN and codes an empty 3312 note list. 3314 The 4-bit LOW and HIGH fields code the number of OFFBITS octets that 3315 follow the note log list. LOW and HIGH are unsigned integer values. If 3316 LOW <= HIGH, there are (HIGH - LOW + 1) OFFBITS octets in the chapter. 3317 The value pairs (LOW = 15, HIGH = 0) and (LOW = 15, HIGH = 1) code an 3318 empty NoteOff bitfield structure (i.e., no OFFBITS octets). Other (LOW 3319 > HIGH) value pairs MUST NOT appear in the header. 3321 The B bit provides S-bit functionality (Appendix A.1) for the NoteOff 3322 bitfield structure. By default, the B bit MUST be set to 1. However, 3323 if the MIDI command section of the previous packet (packet I - 1, with I 3324 as defined in Appendix A.1) includes a NoteOff command for the channel, 3325 the B bit MUST be set to 0. If the B bit is set to 0, the higher-level 3326 recovery journal elements that contain Chapter N MUST have S bits that 3327 are set to 0, including the top-level journal header. 3329 The LEN value of 127 codes a note list length of 127 or 128 note logs, 3330 depending on the values of LOW and HIGH. If LEN = 127, LOW = 15, and 3331 HIGH = 0, the note list holds 128 note logs, and the NoteOff bitfield 3332 structure is empty. For other values of LOW and HIGH, LEN = 127 codes 3333 that the note list contains 127 note logs. In this case, the chapter 3334 has (HIGH - LOW + 1) NoteOff OFFBITS octets if LOW <= HIGH and has no 3335 OFFBITS octets if LOW = 15 and HIGH = 1. 3337 A.6.2. Note Structures 3339 Figure A.6.3 shows the 2-octet note log structure. 3341 0 1 3342 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 3343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3344 |S| NOTENUM |Y| VELOCITY | 3345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3347 Figure A.6.3 -- Chapter N note log 3349 The 7-bit NOTENUM field codes the note number for the log. A note 3350 number MUST NOT be represented by multiple note logs in the note list. 3352 The 7-bit VELOCITY field codes the velocity value for the most recent N- 3353 active NoteOn command for the note number in the session history. 3354 Multiple overlapping NoteOns for a given note number may be coded using 3355 Chapter E, as discussed in Appendix A.7. 3357 VELOCITY is never zero; NoteOn commands with zero velocity are coded as 3358 NoteOff commands in the NoteOff bitfield structure. 3360 The note log does not code the execution time of the NoteOn command. 3361 However, the Y bit codes a hint from the sender about the NoteOn 3362 execution time. The Y bit codes a recommendation to play (Y = 1) or 3363 skip (Y = 0) the NoteOn command recovered from the note log. See 3364 Section 4.2 of [RFC4696] for non-normative guidance on the use of the Y 3365 bit. 3367 Figure A.6.1 shows the NoteOff bitfield structure, as the list of 3368 OFFBITS octets at the end of the chapter. A NoteOff OFFBITS octet codes 3369 NoteOff information for eight consecutive MIDI note numbers, with the 3370 most-significant bit representing the lowest note number. The most- 3371 significant bit of the first OFFBITS octet codes the note number 8*LOW; 3372 the most-significant bit of the last OFFBITS octet codes the note number 3373 8*HIGH. 3375 A set bit codes a NoteOff command for the note number. In the most 3376 efficient coding for the NoteOff bitfield structure, the first and last 3377 octets of the structure contain at least one set bit. Note that Chapter 3378 N does not code NoteOff velocity data. 3380 Note that in the general case, the recovery journal does not code the 3381 relative placement of a NoteOff command and a Change Control command for 3382 controller 64 (Damper Pedal (Sustain)). In many cases, a receiver 3383 processing a loss event may deduce this relative placement from the 3384 history of the stream and thus determine if a NoteOff note is sustained 3385 by the pedal. If such a determination is not possible, receivers SHOULD 3386 err on the side of silencing pedal sustains, as erroneously sustained 3387 notes may produce unpleasant (albeit transient) artifacts. 3389 A.7. Chapter E: MIDI Note Command Extras 3391 Readers may wish to review the Appendix A.1 definition of "N-active 3392 commands" before reading this appendix. In this appendix, a NoteOn 3393 command with a velocity of 0 is considered to be a NoteOff command with 3394 a release velocity value of 64. 3396 Chapter E encodes recovery information about MIDI NoteOn (0x9) and 3397 NoteOff (0x8) command features that rarely appear in MIDI streams. 3398 Receivers use Chapter E to reduce transient artifacts for streams where 3399 several NoteOn commands appear for a note number without an intervening 3400 NoteOff. Receivers also use Chapter E to reduce transient artifacts for 3401 streams that use NoteOff release velocity. Chapter E supplements the 3402 note information coded in Chapter N (Appendix A.6). 3404 Figure A.7.1 shows the format for Chapter E. 3406 0 1 2 3 3407 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 8 0 1 3408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3409 |S| LEN |S| NOTENUM |V| COUNT/VEL |S| NOTENUM | 3410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3411 |V| COUNT/VEL | .... | 3412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3414 Figure A.7.1 -- Chapter E format 3416 The chapter consists of a 1-octet header, followed by a variable-length 3417 list of 2-octet note logs. Appendix A.7.1 defines the bitfield format 3418 for a note log. 3420 The log list MUST contain at least one note log. The 7-bit LEN header 3421 field codes the number of note logs in the list, minus one. A channel 3422 journal MUST contain Chapter E if the rules defined in this appendix 3423 require that one or more note logs appear in the list. The note log 3424 list MUST obey the oldest-first ordering rule (defined in Appendix A.1). 3426 A.7.1. Note Log Format 3428 Figure A.7.2 reproduces the note log structure of Chapter E. 3430 0 1 3431 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 3432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3433 |S| NOTENUM |V| COUNT/VEL | 3434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3436 Figure A.7.2 -- Chapter E note log 3438 A note log codes information about the MIDI note number coded by the 3439 7-bit NOTENUM field. The nature of the information depends on the value 3440 of the V flag bit. 3442 If the V bit is set to 1, the COUNT/VEL field codes the release velocity 3443 value for the most recent N-active NoteOff command for the note number 3444 that appears in the session history. 3446 If the V bit is set to 0, the COUNT/VEL field codes a reference count of 3447 the number of NoteOn and NoteOff commands for the note number that 3448 appear in the session history. 3450 The reference count is set to 0 at the start of the session. NoteOn 3451 commands increment the count by 1. NoteOff commands decrement the count 3452 by 1. However, a decrement that generates a negative count value is not 3453 performed. 3455 If the reference count is in the range 0-126, the 7-bit COUNT/VEL field 3456 codes an unsigned integer representation of the count. If the count is 3457 greater than or equal to 127, COUNT/VEL is set to 127. 3459 By default, the count is reset to 0 whenever a Reset State command 3460 (Appendix A.1) appears in the session history, and whenever MIDI Control 3461 Change commands for controller numbers 123-127 (numbers with All Notes 3462 Off semantics) or 120 (All Sound Off) appear in the session history. 3464 A.7.2. Log Inclusion Rules 3466 If the most recent N-active NoteOn or NoteOff command for a note number 3467 in the checkpoint history is a NoteOff command with a release velocity 3468 value other than 64, a note log whose V bit is set to 1 MUST appear in 3469 Chapter E for the note number. 3471 If the most recent N-active NoteOn or NoteOff command for a note number 3472 in the checkpoint history is a NoteOff command, and if the reference 3473 count for the note number is greater than 0, a note log whose V bit is 3474 set to 0 MUST appear in Chapter E for the note number. 3476 If the most recent N-active NoteOn or NoteOff command for a note number 3477 in the checkpoint history is a NoteOn command, and if the reference 3478 count for the note number is greater than 1, a note log whose V bit is 3479 set to 0 MUST appear in Chapter E for the note number. 3481 At most, two note logs MAY appear in Chapter E for a note number: one 3482 log whose V bit is set to 0, and one log whose V bit is set to 1. 3484 Chapter E codes a maximum of 128 note logs. If the log inclusion rules 3485 yield more than 128 REQUIRED logs, note logs whose V bit is set to 1 3486 MUST be dropped from Chapter E in order to reach the 128-log limit. 3487 Note logs whose V bit is set to 0 MUST NOT be dropped. 3489 Most MIDI streams do not use NoteOn and NoteOff commands in ways that 3490 would trigger the log inclusion rules. For these streams, Chapter E 3491 would never be REQUIRED to appear in a channel journal. 3493 The ch_never parameter (Appendix C.2.3) may be used to configure the log 3494 inclusion rules for Chapter E. 3496 A.8. Chapter T: MIDI Channel Aftertouch 3498 A channel journal MUST contain Chapter T if an N-active and C-active 3499 MIDI Channel Aftertouch (0xD) command appears in the checkpoint history. 3500 Figure A.8.1 shows the format for Chapter T. 3502 0 3503 0 1 2 3 4 5 6 7 3504 +-+-+-+-+-+-+-+-+ 3505 |S| PRESSURE | 3506 +-+-+-+-+-+-+-+-+ 3508 Figure A.8.1 -- Chapter T format 3510 The chapter has a fixed size of 8 bits. The 7-bit PRESSURE field holds 3511 the pressure value of the most recent N-active and C-active Channel 3512 Aftertouch command in the session history. 3514 Chapter T only encodes commands that are C-active and N-active. We 3515 define a C-active restriction because [RP015] declares that a Control 3516 Change command for controller 121 (Reset All Controllers) acts to reset 3517 the channel pressure to 0 (see the discussion at the end of Appendix A.5 3518 for a more complete rationale). 3520 We define an N-active restriction on the assumption that aftertouch 3521 commands are linked to note activity, and thus Channel Aftertouch 3522 commands that are not N-active are stale and should not be used to 3523 repair a stream. 3525 A.9. Chapter A: MIDI Poly Aftertouch 3527 A channel journal MUST contain Chapter A if a C-active Poly Aftertouch 3528 (0xA) command appears in the checkpoint history. Figure A.9.1 shows the 3529 format for Chapter A. 3531 0 1 2 3 3532 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 8 0 1 3533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3534 |S| LEN |S| NOTENUM |X| PRESSURE |S| NOTENUM | 3535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3536 |X| PRESSURE | .... | 3537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3539 Figure A.9.1 -- Chapter A format 3541 The chapter consists of a 1-octet header, followed by a variable-length 3542 list of 2-octet note logs. A note log MUST appear for a note number if 3543 a C-active Poly Aftertouch command for the note number appears in the 3544 checkpoint history. A note number MUST NOT be represented by multiple 3545 note logs in the note list. The note log list MUST obey the oldest- 3546 first ordering rule (defined in Appendix A.1). 3548 The 7-bit LEN field codes the number of note logs in the list, minus 3549 one. Figure A.9.2 reproduces the note log structure of Chapter A. 3551 0 1 3552 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 3553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3554 |S| NOTENUM |X| PRESSURE | 3555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3557 Figure A.9.2 -- Chapter A note log 3559 The 7-bit PRESSURE field codes the pressure value of the most recent C- 3560 active Poly Aftertouch command in the session history for the MIDI note 3561 number coded in the 7-bit NOTENUM field. 3563 As a rule, the X bit MUST be set to 0. However, the X bit MUST be set 3564 to 1 if the command coded by the log appears before one of the following 3565 commands in the session history: MIDI Control Change numbers 123-127 3566 (numbers with All Notes Off semantics) or 120 (All Sound Off). 3568 We define C-active restrictions for Chapter A because [RP015] declares 3569 that a Control Change command for controller 121 (Reset All Controllers) 3570 acts to reset the polyphonic pressure to 0 (see the discussion at the 3571 end of Appendix A.5 for a more complete rationale). 3573 B. The Recovery Journal System Chapters 3575 B.1. System Chapter D: Simple System Commands 3577 The system journal MUST contain Chapter D if an active MIDI Reset 3578 (0xFF), MIDI Tune Request (0xF6), MIDI Song Select (0xF3), undefined 3579 MIDI System Common (0xF4 and 0xF5), or undefined MIDI System Real-time 3580 (0xF9 and 0xFD) command appears in the checkpoint history. 3582 Figure B.1.1 shows the variable-length format for Chapter D. 3584 0 1 2 3 3585 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 3586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3587 |S|B|G|H|J|K|Y|Z| Command logs ... | 3588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3590 Figure B.1.1 -- System Chapter D format 3592 The chapter consists of a 1-octet header, followed by one or more 3593 command logs. Header flag bits indicate the presence of command logs 3594 for the Reset (B = 1), Tune Request (G = 1), Song Select (H = 1), 3595 undefined System Common 0xF4 (J = 1), undefined System Common 0xF5 (K = 3596 1), undefined System Real-time 0xF9 (Y = 1), or undefined System Real- 3597 time 0xFD (Z = 1) commands. 3599 Command logs appear in a list following the header, in the order that 3600 the flag bits appear in the header. 3602 Figure B.1.2 shows the 1-octet command log format for the Reset and Tune 3603 Request commands. 3605 0 3606 0 1 2 3 4 5 6 7 3607 +-+-+-+-+-+-+-+-+ 3608 |S| COUNT | 3609 +-+-+-+-+-+-+-+-+ 3611 Figure B.1.2 -- Command log for Reset and Tune Request 3613 Chapter D MUST contain the Reset command log if an active Reset command 3614 appears in the checkpoint history. The 7-bit COUNT field codes the 3615 total number of Reset commands (modulo 128) present in the session 3616 history. 3618 Chapter D MUST contain the Tune Request command log if an active Tune 3619 Request command appears in the checkpoint history. The 7-bit COUNT 3620 field codes the total number of Tune Request commands (modulo 128) 3621 present in the session history. 3623 For these commands, the COUNT field acts as a reference count. See the 3624 definition of "session history reference counts" in Appendix A.1 for 3625 more information. 3627 Figure B.1.3 shows the 1-octet command log format for the Song Select 3628 command. 3630 0 3631 0 1 2 3 4 5 6 7 3632 +-+-+-+-+-+-+-+-+ 3633 |S| VALUE | 3634 +-+-+-+-+-+-+-+-+ 3636 Figure B.1.3 -- Song Select command log format 3638 Chapter D MUST contain the Song Select command log if an active Song 3639 Select command appears in the checkpoint history. The 7-bit VALUE field 3640 codes the song number of the most recent active Song Select command in 3641 the session history. 3643 B.1.1. Undefined System Commands 3645 In this section, we define the Chapter D command logs for the undefined 3646 System commands. [MIDI] reserves the undefined System commands 0xF4, 3647 0xF5, 0xF9, and 0xFD for future use. At the time of this writing, any 3648 MIDI command stream that uses these commands is non-compliant with 3649 [MIDI]. However, future versions of [MIDI] may define these commands, 3650 and a few products do use these commands in a non-compliant manner. 3652 Figure B.1.4 shows the variable-length command log format for the 3653 undefined System Common commands (0xF4 and 0xF5). 3655 0 1 2 3 3656 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 3657 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3658 |S|C|V|L|DSZ| LENGTH | COUNT | VALUE ... | 3659 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3660 | LEGAL ... | 3661 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3663 Figure B.1.4 -- Undefined System Common command log format 3665 The command log codes a single command type (0xF4 or 0xF5, not both). 3666 Chapter D MUST contain a command log if an active 0xF4 command appears 3667 in the checkpoint history and MUST contain an independent command log if 3668 an active 0xF5 command appears in the checkpoint history. 3670 A Chapter D Undefined System Common command log consists of a two-octet 3671 header followed by a variable number of data fields. Header flag bits 3672 indicate the presence of the COUNT field (C = 1), the VALUE field (V = 3673 1), and the LEGAL field (L = 1). The 10-bit LENGTH field codes the size 3674 of the command log and conforms to semantics described in Appendix A.1. 3676 The 2-bit DSZ field codes the number of data octets in the command 3677 instance that appears most recently in the session history. If DSZ = 3678 0-2, the command has 0-2 data octets. If DSZ = 3, the command has 3 or 3679 more command data octets. 3681 We now define the default rules for the use of the COUNT, VALUE, and 3682 LEGAL fields. The session configuration tools defined in Appendix C.2.3 3683 may be used to override this behavior. 3685 By default, if the DSZ field is set to 0, the command log MUST include 3686 the COUNT field. The 8-bit COUNT field codes the total number of 3687 commands of the type coded by the log (0xF4 or 0xF5) present in the 3688 session history, modulo 256. 3690 By default, if the DSZ field is set to 1-3, the command log MUST include 3691 the VALUE field. The variable-length VALUE field codes a verbatim copy 3692 the data octets for the most recent use of the command type coded by the 3693 log (0xF4 or 0xF5) in the session history. The most-significant bit of 3694 the final data octet MUST be set to 1, and the most-significant bit of 3695 all other data octets MUST be set to 0. 3697 The LEGAL field is reserved for future use. If an update to [MIDI] 3698 defines the 0xF4 or 0xF5 command, an IETF standards-track document may 3699 define the LEGAL field. Until such a document appears, senders MUST NOT 3700 use the LEGAL field, and receivers MUST use the LENGTH field to skip 3701 over the LEGAL field. The LEGAL field would be defined by the IETF if 3702 the semantics of the new 0xF4 or 0xF5 command could not be protected 3703 from packet loss via the use of the COUNT and VALUE fields. 3705 Figure B.1.5 shows the variable-length command log format for the 3706 undefined System Real-time commands (0xF9 and 0xFD). 3708 0 1 2 3 3709 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 3710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3711 |S|C|L| LENGTH | COUNT | LEGAL ... | 3712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3714 Figure B.1.5 -- Undefined System Real-time command log format 3716 The command log codes a single command type (0xF9 or 0xFD, not both). 3717 Chapter D MUST contain a command log if an active 0xF9 command appears 3718 in the checkpoint history and MUST contain an independent command log if 3719 an active 0xFD command appears in the checkpoint history. 3721 A Chapter D Undefined System Real-time command log consists of a one- 3722 octet header followed by a variable number of data fields. Header flag 3723 bits indicate the presence of the COUNT field (C = 1) and the LEGAL 3724 field (L = 1). The 5-bit LENGTH field codes the size of the command log 3725 and conforms to semantics described in Appendix A.1. 3727 We now define the default rules for the use of the COUNT and LEGAL 3728 fields. The session configuration tools defined in Appendix C.2.3 may 3729 be used to override this behavior. 3731 The 8-bit COUNT field codes the total number of commands of the type 3732 coded by the log present in the session history, modulo 256. By 3733 default, the COUNT field MUST be present in the command log. 3735 The LEGAL field is reserved for future use. If an update to [MIDI] 3736 defines the 0xF9 or 0xFD command, an IETF standards-track document may 3737 define the LEGAL field to protect the command. Until such a document 3738 appears, senders MUST NOT use the LEGAL field, and receivers MUST use 3739 the LENGTH field to skip over the LEGAL field. The LEGAL field would be 3740 defined by the IETF if the semantics of the new 0xF9 or 0xFD command 3741 could not be protected from packet loss via the use of the COUNT field. 3743 Finally, we note that some non-standard uses of the undefined System 3744 Real-time commands act to implement non-compliant variants of the MIDI 3745 sequencer system. In Appendix B.3.1, we describe resiliency tools for 3746 the MIDI sequencer system that provide some protection in this case. 3748 B.2. System Chapter V: Active Sense Command 3750 The system journal MUST contain Chapter V if an active MIDI Active Sense 3751 (0xFE) command appears in the checkpoint history. Figure B.2.1 shows 3752 the format for Chapter V. 3754 0 3755 0 1 2 3 4 5 6 7 3756 +-+-+-+-+-+-+-+-+ 3757 |S| COUNT | 3758 +-+-+-+-+-+-+-+-+ 3760 Figure B.2.1 -- System Chapter V format 3762 The 7-bit COUNT field codes the total number of Active Sense commands 3763 (modulo 128) present in the session history. The COUNT field acts as a 3764 reference count. See the definition of "session history reference 3765 counts" in Appendix A.1 for more information. 3767 B.3. System Chapter Q: Sequencer State Commands 3769 This appendix describes Chapter Q, the system chapter for the MIDI 3770 sequencer commands. 3772 The system journal MUST contain Chapter Q if an active MIDI Song 3773 Position Pointer (0xF2), MIDI Clock (0xF8), MIDI Start (0xFA), MIDI 3774 Continue (0xFB), or MIDI Stop (0xFC) command appears in the checkpoint 3775 history, and if the rules defined in this appendix require a change in 3776 the Chapter Q bitfield contents because of the command appearance. 3778 Figure B.3.1 shows the variable-length format for Chapter Q. 3780 0 1 2 3 3781 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 3782 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3783 |S|N|D|C|T| TOP | CLOCK | TIMETOOLS ... | 3784 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3785 | ... | 3786 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3788 Figure B.3.1 -- System Chapter Q format 3790 Chapter Q consists of a 1-octet header followed by several optional 3791 fields, in the order shown in Figure B.3.1. 3793 Header flag bits signal the presence of the 16-bit CLOCK field (C = 1) 3794 and the 24-bit TIMETOOLS field (T = 1). The 3-bit TOP header field is 3795 interpreted as an unsigned integer, as are CLOCK and TIMETOOLS. We 3796 describe the TIMETOOLS field in Appendix B.3.1. 3798 Chapter Q encodes the most recent state of the sequencer system. 3799 Receivers use the chapter to re-synchronize the sequencer after a packet 3800 loss episode. Chapter fields encode the on/off state of the sequencer, 3801 the current position in the song, and the downbeat. 3803 The N header bit encodes the relative occurrence of the Start, Stop, and 3804 Continue commands in the session history. If an active Start or 3805 Continue command appears most recently, the N bit MUST be set to 1. If 3806 an active Stop appears most recently, or if no active Start, Stop, or 3807 Continue commands appear in the session history, the N bit MUST be set 3808 to 0. 3810 The C header flag, the TOP header field, and the CLOCK field act to code 3811 the current position in the sequence: 3813 o If C = 1, the 3-bit TOP header field and the 16-bit 3814 CLOCK field are combined to form the 19-bit unsigned quantity 3815 65536*TOP + CLOCK. This value encodes the song position 3816 in units of MIDI Clocks (24 clocks per quarter note), 3817 modulo 524288. Note that the maximum song position value 3818 that may be coded by the Song Position Pointer command is 3819 98303 clocks (which may be coded with 17 bits), and that 3820 MIDI-coded songs are generally constructed to avoid durations 3821 longer than this value. However, the 19-bit size may be useful 3822 for real-time applications, such as a drum machine MIDI output 3823 that is sending clock commands for long periods of time. 3825 o If C = 0, the song position is the start of the song. 3826 The C = 0 position is identical to the position coded 3827 by C = 1, TOP = 0, and CLOCK = 0, for the case where 3828 the song position is less than 524288 MIDI clocks. 3829 In certain situations (defined later in this section), 3830 normative text may require the C = 0 or the C = 1, 3831 TOP = 0, CLOCK = 0 encoding of the start of the song. 3833 The C, TOP, and CLOCK fields MUST be set to code the current song 3834 position, for both N = 0 and N = 1 conditions. If C = 0, the TOP field 3835 MUST be set to 0. See [MIDI] for a precise definition of a song 3836 position. 3838 The D header bit encodes information about the downbeat and acts to 3839 qualify the song position coded by the C, TOP, and CLOCK fields. 3841 If the D bit is set to 1, the song position represents the most recent 3842 position in the sequence that has played. If D = 1, the next Clock 3843 command (if N = 1) or the next (Continue, Clock) pair (if N = 0) acts to 3844 increment the song position by one clock, and to play the updated 3845 position. 3847 If the D bit is set to 0, the song position represents a position in the 3848 sequence that has not yet been played. If D = 0, the next Clock command 3849 (if N = 1) or the next (Continue, Clock) pair (if N = 0) acts to play 3850 the point in the song coded by the song position. The song position is 3851 not incremented. 3853 An example of a stream that uses D = 0 coding is one whose most recent 3854 sequence command is a Start or Song Position Pointer command (both N = 1 3855 conditions). However, it is also possible to construct examples where D 3856 = 0 and N = 0. A Start command immediately followed by a Stop command 3857 is coded in Chapter Q by setting C = 0, D = 0, N = 0, TOP = 0. 3859 If N = 1 (coding Start or Continue), D = 0 (coding that the downbeat has 3860 yet to be played), and the song position is at the start of the song, 3861 the C = 0 song position encoding MUST be used if a Start command occurs 3862 more recently than a Continue command in the session history, and the C 3863 = 1, TOP = 0, CLOCK = 0 song position encoding MUST be used if a 3864 Continue command occurs more recently than a Start command in the 3865 session history. 3867 B.3.1. Non-compliant Sequencers 3869 The Chapter Q description in this appendix assumes that the sequencer 3870 system counts off time with Clock commands, as mandated in [MIDI]. 3871 However, a few non-compliant products do not use Clock commands to count 3872 off time, but instead use non-standard methods. 3874 Chapter Q uses the TIMETOOLS field to provide resiliency support for 3875 these non-standard products. By default, the TIMETOOLS field MUST NOT 3876 appear in Chapter Q, and the T header bit MUST be set to 0. The session 3877 configuration tools described in Appendix C.2.3 may be used to select 3878 TIMETOOLS coding. 3880 Figure B.3.2 shows the format of the 24-bit TIMETOOLS field. 3882 0 1 2 3883 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 3884 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3885 | TIME | 3886 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3888 Figure B.3.2 -- TIMETOOLS format 3890 The TIME field is a 24-bit unsigned integer quantity, with units of 3891 milliseconds. TIME codes an additive correction term for the song 3892 position coded by the TOP, CLOCK, and C fields. TIME is coded in 3893 network byte order (big-endian). 3895 A receiver computes the correct song position by converting TIME into 3896 units of MIDI clocks and adding it to 65536*TOP + CLOCK (assuming C = 3897 1). Alternatively, a receiver may convert 65536*TOP + CLOCK into 3898 milliseconds (assuming C = 1) and add it to TIME. The downbeat (D 3899 header bit) semantics defined in Appendix B.3 apply to the corrected 3900 song position. 3902 B.4. System Chapter F: MIDI Time Code Tape Position 3904 This appendix describes Chapter F, the system chapter for the MIDI Time 3905 Code (MTC) commands. Readers may wish to review the Appendix A.1 3906 definition of "finished/unfinished commands" before reading this 3907 appendix. 3909 The system journal MUST contain Chapter F if an active System Common 3910 Quarter Frame command (0xF1) or an active finished System Exclusive 3911 (Universal Real Time) MTC Full Frame command (F0 7F cc 01 01 hr mn sc fr 3912 F7) appears in the checkpoint history. Otherwise, the system journal 3913 MUST NOT contain Chapter F. 3915 Figure B.4.1 shows the variable-length format for Chapter F. 3917 0 1 2 3 3918 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 3919 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3920 |S|C|P|Q|D|POINT| COMPLETE ... | 3921 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3922 | ... | PARTIAL ... | 3923 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3924 | ... | 3925 +-+-+-+-+-+-+-+-+ 3927 Figure B.4.1 -- System Chapter F format 3929 Chapter F holds information about recent MTC tape positions coded in the 3930 session history. Receivers use Chapter F to re-synchronize the MTC 3931 system after a packet loss episode. 3933 Chapter F consists of a 1-octet header followed by several optional 3934 fields, in the order shown in Figure B.4.1. The C and P header bits 3935 form a Table of Contents (TOC) and signal the presence of the 32-bit 3936 COMPLETE field (C = 1) and the 32-bit PARTIAL field (P = 1). 3938 The Q header bit codes information about the COMPLETE field format. If 3939 Chapter F does not contain a COMPLETE field, Q MUST be set to 0. 3941 The D header bit codes the tape movement direction. If the tape is 3942 moving forward, or if the tape direction is indeterminate, the D bit 3943 MUST be set to 0. If the tape is moving in the reverse direction, the D 3944 bit MUST be set to 1. In most cases, the ordering of commands in the 3945 session history clearly defines the tape direction. However, a few 3946 command sequences have an indeterminate direction (such as a session 3947 history consisting of one Full Frame command). 3949 The 3-bit POINT header field is interpreted as an unsigned integer. 3950 Appendix B.4.1 defines how the POINT field codes information about the 3951 contents of the PARTIAL field. If Chapter F does not contain a PARTIAL 3952 field, POINT MUST be set to 7 (if D = 0) or 0 (if D = 1). 3954 Chapter F MUST include the COMPLETE field if an active finished Full 3955 Frame command appears in the checkpoint history, or if an active Quarter 3956 Frame command that completes the encoding of a frame value appears in 3957 the checkpoint history. 3959 The COMPLETE field encodes the most recent active complete MTC frame 3960 value that appears in the session history. This frame value may take 3961 the form of a series of 8 active Quarter Frame commands (0xF1 0x0n 3962 through 0xF1 0x7n for forward tape movement, 0xF1 0x7n through 0xF1 0x0n 3963 for reverse tape movement) or may take the form of an active finished 3964 Full Frame command. 3966 If the COMPLETE field encodes a Quarter Frame command series, the Q 3967 header bit MUST be set to 1, and the COMPLETE field MUST have the format 3968 shown in Figure B.4.2. The 4-bit fields MT0 through MT7 code the data 3969 (lower) nibble for the Quarter Frame commands for Message Type 0 through 3970 Message Type 7 [MIDI]. These nibbles encode a complete frame value, in 3971 addition to fields reserved for future use by [MIDI]. 3973 0 1 2 3 3974 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 3975 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3976 | MT0 | MT1 | MT2 | MT3 | MT4 | MT5 | MT6 | MT7 | 3977 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3979 Figure B.4.2 -- COMPLETE field format, Q = 1 3981 In this usage, the frame value encoded in the COMPLETE field MUST be 3982 offset by 2 frames (relative to the frame value encoded in the Quarter 3983 Frame commands) if the frame value codes a 0xF1 0x0n through 0xF1 0x7n 3984 command sequence. This offset compensates for the two-frame latency of 3985 the Quarter Frame encoding for forward tape movement. No offset is 3986 applied if the frame value codes a 0xF1 0x7n through 0xF1 0x0n Quarter 3987 Frame command sequence. 3989 The most recent active complete MTC frame value may alternatively be 3990 encoded by an active finished Full Frame command. In this case, the Q 3991 header bit MUST be set to 0, and the COMPLETE field MUST have format 3992 shown in Figure B.4.3. The HR, MN, SC, and FR fields correspond to the 3993 hr, mn, sc, and fr data octets of the Full Frame command. 3995 0 1 2 3 3996 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 3997 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3998 | HR | MN | SC | FR | 3999 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4001 Figure B.4.3 -- COMPLETE field format, Q = 0 4003 B.4.1. Partial Frames 4005 The most recent active session history command that encodes MTC frame 4006 value data may be a Quarter Frame command other than a forward-moving 4007 0xF1 0x7n command (which completes a frame value for forward tape 4008 movement) or a reverse-moving 0xF1 0x1n command (which completes a frame 4009 value for reverse tape movement). 4011 We consider this type of Quarter Frame command to be associated with a 4012 partial frame value. The Quarter Frame sequence that defines a partial 4013 frame value MUST either start at Message Type 0 and increment 4014 contiguously to an intermediate Message Type less than 7, or start at 4015 Message Type 7 and decrement contiguously to an intermediate Message 4016 type greater than 0. A Quarter Frame command sequence that does not 4017 follow this pattern is not associated with a partial frame value. 4019 Chapter F MUST include a PARTIAL field if the most recent active command 4020 in the checkpoint history that encodes MTC frame value data is a Quarter 4021 Frame command that is associated with a partial frame value. Otherwise, 4022 Chapter F MUST NOT include a PARTIAL field. 4024 The partial frame value consists of the data (lower) nibbles of the 4025 Quarter Frame command sequence. The PARTIAL field codes the partial 4026 frame value, using the format shown in Figure B.4.2. Message Type 4027 fields that are not associated with a Quarter Frame command MUST be set 4028 to 0. 4030 The POINT header field identifies the Message Type fields in the PARTIAL 4031 field that code valid data. If P = 1, the POINT field MUST encode the 4032 unsigned integer value formed by the lower 3 bits of the upper nibble of 4033 the data value of the most recent active Quarter Frame command in the 4034 session history. If D = 0 and P = 1, POINT MUST take on a value in the 4035 range 0-6. If D = 1 and P = 1, POINT MUST take on a value in the range 4036 1-7. 4038 If D = 0, MT fields (Figure B.4.2) in the inclusive range from 0 up to 4039 and including the POINT value encode the partial frame value. If D = 1, 4040 MT fields in the inclusive range from 7 down to and including the POINT 4041 value encode the partial frame value. Note that, unlike the COMPLETE 4042 field encoding, senders MUST NOT add a 2-frame offset to the partial 4043 frame value encoded in PARTIAL. 4045 For the default semantics, if a recovery journal contains Chapter F, and 4046 if the session history codes a legal [MIDI] series of Quarter Frame and 4047 Full Frame commands, the chapter always contains a COMPLETE or a PARTIAL 4048 field (and may contain both fields). Thus, a one-octet Chapter F (C = P 4049 = 0) always codes the presence of an illegal command sequence in the 4050 session history (under some conditions, the C = 1, P = 0 condition may 4051 also code the presence of an illegal command sequence). The illegal 4052 command sequence conditions are transient in nature and usually indicate 4053 that a Quarter Frame command sequence began with an intermediate Message 4054 Type. 4056 B.5. System Chapter X: System Exclusive 4058 This appendix describes Chapter X, the system chapter for MIDI System 4059 Exclusive (SysEx) commands (0xF0). Readers may wish to review the 4060 Appendix A.1 definition of "finished/unfinished commands" before reading 4061 this appendix. 4063 Chapter X consists of a list of one or more command logs. Each log in 4064 the list codes information about a specific finished or unfinished SysEx 4065 command that appears in the session history. The system journal MUST 4066 contain Chapter X if the rules defined in Appendix B.5.2 require that 4067 one or more logs appear in the list. 4069 The log list is not preceded by a header. Instead, each log implicitly 4070 encodes its own length. Given the length of the N'th list log, the 4071 presence of the (N+1)'th list log may be inferred from the LENGTH field 4072 of the system journal header (Figure 10 in Section 5 of the main text). 4073 The log list MUST obey the oldest-first ordering rule (defined in 4074 Appendix A.1). 4076 B.5.1. Chapter Format 4078 Figure B.5.1 shows the bitfield format for the Chapter X command logs. 4080 0 1 2 3 4081 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 4082 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4083 |S|T|C|F|D|L|STA| TCOUNT | COUNT | FIRST ... | 4084 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4085 | DATA ... | 4086 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4088 Figure B.5.1 -- Chapter X command log format 4090 A Chapter X command log consists of a 1-octet header, followed by the 4091 optional TCOUNT, COUNT, FIRST, and DATA fields. 4093 The T, C, F, and D header bits act as a Table of Contents (TOC) for the 4094 log. If T is set to 1, the 1-octet TCOUNT field appears in the log. If 4095 C is set to 1, the 1-octet COUNT field appears in the log. If F is set 4096 to 1, the variable-length FIRST field appears in the log. If D is set 4097 to 1, the variable-length DATA field appears in the log. 4099 The L header bit sets the coding tool for the log. We define the log 4100 coding tools in Appendix B.5.2. 4102 The STA field codes the status of the command coded by the log. The 4103 2-bit STA value is interpreted as an unsigned integer. If STA is 0, the 4104 log codes an unfinished command. Non-zero STA values code different 4105 classes of finished commands. An STA value of 1 codes a cancelled 4106 command, an STA value of 2 codes a command that uses the "dropped F7" 4107 construction, and an STA value of 3 codes all other finished commands. 4108 Section 3.2 in the main text describes cancelled and "dropped F7" 4109 commands. 4111 The S bit (Appendix A.1) of the first log in the list acts as the S bit 4112 for Chapter X. For the other logs in the list, the S bit refers to the 4113 log itself. The value of the "phantom" S bit associated with the first 4114 log is defined by the following rules: 4116 o If the list codes one log, the phantom S-bit value is 4117 the same as the Chapter X S-bit value. 4119 o If the list codes multiple logs, the phantom S-bit value is 4120 the logical OR of the S-bit value of the first and second 4121 command logs in the list. 4123 In all other respects, the S bit follows the semantics defined in 4124 Appendix A.1. 4126 The FIRST field (present if F = 1) encodes a variable-length unsigned 4127 integer value that sets the coverage of the DATA field. 4129 The FIRST field (present if F = 1) encodes a variable-length unsigned 4130 integer value that specifies which SysEx data bytes are encoded in the 4131 DATA field of the log. The FIRST field consists of an octet whose most- 4132 significant bit is set to 0, optionally preceded by one or more octets 4133 whose most-significant bit is set to 1. The algorithm shown in Figure 4134 B.5.2 decodes this format into an unsigned integer, to yield the value 4135 dec(FIRST). FIRST uses a variable-length encoding because dec(FIRST) 4136 references a data octet in a SysEx command, and a SysEx command may 4137 contain an arbitrary number of data octets. 4139 One-Octet FIRST value: 4141 Encoded form: 0ddddddd 4142 Decoded form: 00000000 00000000 00000000 0ddddddd 4144 Two-Octet FIRST value: 4146 Encoded form: 1ccccccc 0ddddddd 4147 Decoded form: 00000000 00000000 00cccccc cddddddd 4149 Three-Octet FIRST value: 4151 Encoded form: 1bbbbbbb 1ccccccc 0ddddddd 4152 Decoded form: 00000000 000bbbbb bbcccccc cddddddd 4154 Four-Octet FIRST value: 4156 Encoded form: 1aaaaaaa 1bbbbbbb 1ccccccc 0ddddddd 4157 Decoded form: 0000aaaa aaabbbbb bbcccccc cddddddd 4159 Figure B.5.2 -- Decoding FIRST field formats 4161 The DATA field (present if D = 1) encodes a modified version of the data 4162 octets of the SysEx command coded by the log. Status octets MUST NOT be 4163 coded in the DATA field. 4165 If F = 0, the DATA field begins with the first data octet of the SysEx 4166 command and includes all subsequent data octets for the command that 4167 appear in the session history. If F = 1, the DATA field begins with the 4168 (dec(FIRST) + 1)'th data octet of the SysEx command and includes all 4169 subsequent data octets for the command that appear in the session 4170 history. Note that the word "command" in the descriptions above refers 4171 to the original SysEx command as it appears in the source MIDI data 4172 stream, not to a particular MIDI list SysEx command segment. 4174 The length of the DATA field is coded implicitly, using the most- 4175 significant bit of each octet. The most-significant bit of the final 4176 octet of the DATA field MUST be set to 1. The most-significant bit of 4177 all other DATA octets MUST be set to 0. This coding method relies on 4178 the fact that the most-significant bit of a MIDI data octet is 0 by 4179 definition. Apart from this length-coding modification, the DATA field 4180 encodes a verbatim copy of all data octets it encodes. 4182 B.5.2. Log Inclusion Semantics 4184 Chapter X offers two tools to protect SysEx commands: the "recency" tool 4185 and the "list" tool. The tool definitions use the concept of the "SysEx 4186 type" of a command, which we now define. 4188 Each SysEx command instance in a session, excepting MTC Full Frame 4189 commands, is said to have a "SysEx type". Types are used in equality 4190 comparisons: two SysEx commands in a session are said to have "the same 4191 SysEx type" or "different SysEx types". 4193 If efficiency is not a concern, a sender may follow a simple typing 4194 rule: every SysEx command in the session history has a different SysEx 4195 type, and thus no two commands in the session have the same type. 4197 To improve efficiency, senders MAY implement exceptions to this rule. 4198 These exceptions declare that certain sets of SysEx command instances 4199 have the same SysEx type. Any command not covered by an exception 4200 follows the simple rule. We list exceptions below: 4202 o All commands with identical data octet fields (same number of 4203 data octets, same value for each data octet) have the same type. 4204 This rule MUST be applied to all SysEx commands in the session, 4205 or not at all. Note that the implementation of this exception 4206 requires no sender knowledge of the format and semantics of 4207 the SysEx commands in the stream, merely the ability to count 4208 and compare octets. 4210 o Two instances of the same command whose semantics set or report 4211 the value of the same "parameter" have the same type. The 4212 implementation of this exception requires specific knowledge of 4213 the format and semantics of SysEx commands. In practice, a 4214 sender implementation chooses to support this exception for 4215 certain classes of commands (such as the Universal System 4216 Exclusive commands defined in [MIDI]). If a sender supports 4217 this exception for a particular command in a class (for 4218 example, the Universal Real Time System Exclusive message 4219 for Master Volume, F0 F7 cc 04 01 vv vv F7, defined in [MIDI]), 4220 it MUST support the exception to all instances of this 4221 particular command in the session. 4223 We now use this definition of "SysEx type" to define the "recency" tool 4224 and the "list" tool for Chapter X. 4226 By default, the Chapter X log list MUST code sufficient information to 4227 protect the rendered MIDI performance from indefinite artifacts caused 4228 by the loss of all finished or unfinished active SysEx commands that 4229 appear in the checkpoint history (excluding finished MTC Full Frame 4230 commands, which are coded in Chapter F (Appendix B.4)). 4232 To protect a command of a specific SysEx type with the recency tool, 4233 senders MUST code a log in the log list for the most recent finished 4234 active instance of the SysEx type that appears in the checkpoint 4235 history. Additionally, if an unfinished active instance of the SysEx 4236 type appears in the checkpoint history, senders MUST code a log in the 4237 log list for the unfinished command instance. The L header bit of both 4238 command logs MUST be set to 0. 4240 To protect a command of a specific SysEx type with the list tool, 4241 senders MUST code a log in the Chapter X log list for each finished or 4242 unfinished active instance of the SysEx type that appears in the 4243 checkpoint history. The L header bit of list tool command logs MUST be 4244 set to 1. 4246 As a rule, a log REQUIRED by the list or recency tool MUST include a 4247 DATA field that codes all data octets that appear in the checkpoint 4248 history for the SysEx command instance associated with the log. The 4249 FIRST field MAY be used to configure a DATA field that minimally meets 4250 this requirement. 4252 An exception to this rule applies to cancelled commands (defined in 4253 Section 3.2). REQUIRED command logs associated with cancelled commands 4254 MAY be coded with no DATA field. However, if DATA appears in the log, 4255 DATA MUST code all data octets that appear in the checkpoint history for 4256 the command associated with the log. 4258 As defined by the preceding text in this section, by default all 4259 finished or unfinished active SysEx commands that appear in the 4260 checkpoint history (excluding finished MTC Full Frame commands) MUST be 4261 protected by the list tool or the recency tool. 4263 For some MIDI source streams, this default yields a Chapter X whose size 4264 is too large. For example, imagine that a sender begins to transcode a 4265 SysEx command with 10,000 data octets onto a UDP RTP stream "on the 4266 fly", by sending SysEx command segments as soon as data octets are 4267 delivered by the MIDI source. After 1000 octets have been sent, the 4268 expansion of Chapter X yields an RTP packet that is too large to fit in 4269 the Maximum Transmission Unit (MTU) for the stream. 4271 In this situation, if a sender uses the closed-loop sending policy for 4272 SysEx commands, the RTP packet size may always be capped by stalling the 4273 stream. In a stream stall, once the packet reaches a maximum size, the 4274 sender refrains from sending new packets with non-empty MIDI Command 4275 Sections until receiver feedback permits the trimming of Chapter X. If 4276 the stream permits arbitrary commands to appear between SysEx segments 4277 (selectable during configuration using the tools defined in Appendix 4278 C.1), the sender may stall the SysEx segment stream but continue to code 4279 other commands in the MIDI list. 4281 Stalls are a workable but sub-optimal solution to Chapter X size issues. 4282 As an alternative to stalls, senders SHOULD take preemptive action 4283 during session configuration to reduce the anticipated size of Chapter 4284 X, using the methods described below: 4286 o Partitioned transport. Appendix C.5 provides tools 4287 for sending a MIDI name space over several RTP streams. 4288 Senders may use these tools to map a MIDI source 4289 into a low-latency UDP RTP stream (for channel commands 4290 and short SysEx commands) and a reliable [RFC4571] TCP stream 4291 (for bulk-data SysEx commands). The cm_unused and 4292 cm_used parameters (Appendix C.1) may be used to 4293 communicate the nature of the SysEx command partition. 4294 As TCP is reliable, the RTP MIDI TCP stream would not 4295 use the recovery journal. To minimize transmission 4296 latency for short SysEx commands, senders may begin 4297 segmental transmission for all SysEx commands over the 4298 UDP stream and then cancel the UDP transmission of long 4299 commands (using tools described in Section 3.2) and 4300 resend the commands over the TCP stream. 4302 o Selective protection. Journal protection may not be 4303 necessary for all SysEx commands in a stream. The 4304 ch_never parameter (Appendix C.2) may be used to 4305 communicate which SysEx commands are excluded from 4306 Chapter X. 4308 B.5.3. TCOUNT and COUNT Fields 4310 If the T header bit is set to 1, the 8-bit TCOUNT field appears in the 4311 command log. If the C header bit is set to 1, the 8-bit COUNT field 4312 appears in the command log. TCOUNT and COUNT are interpreted as 4313 unsigned integers. 4315 The TCOUNT field codes the total number of SysEx commands of the SysEx 4316 type coded by the log that appear in the session history, at the moment 4317 after the (finished or unfinished) command coded by the log enters the 4318 session history. 4320 The COUNT field codes the total number of SysEx commands that appear in 4321 the session history, excluding commands that are excluded from Chapter X 4322 via the ch_never parameter (Appendix C.2), at the moment after the 4323 (finished or unfinished) command coded by the log enters the session 4324 history. 4326 Command counting for TCOUNT and COUNT uses modulo-256 arithmetic. MTC 4327 Full Frame command instances (Appendix B.4) are included in command 4328 counting if the TCOUNT and COUNT definitions warrant their inclusion, as 4329 are cancelled commands (Section 3.2). 4331 Senders use the TCOUNT and COUNT fields to track the identity and (for 4332 TCOUNT) the sequence position of a command instance. Senders MUST use 4333 the TCOUNT or COUNT fields if identity or sequence information is 4334 necessary to protect the command type coded by the log. 4336 If a sender uses the COUNT field in a session, the final command log in 4337 every Chapter X in the stream MUST code the COUNT field. This rule lets 4338 receivers resynchronize the COUNT value after a packet loss. 4340 C. Session Configuration Tools 4342 In Sections 6.1-2 of the main text, we show session descriptions for 4343 minimal native and mpeg4-generic RTP MIDI streams. Minimal streams lack 4344 the flexibility to support some applications. In this appendix, we 4345 describe how to customize stream behavior through the use of the payload 4346 format parameters. 4348 The appendix begins with 6 sections, each devoted to parameters that 4349 affect a particular aspect of stream behavior: 4351 o Appendix C.1 describes the stream subsetting system 4352 (cm_unused and cm_used). 4354 o Appendix C.2 describes the journalling system (ch_anchor, 4355 ch_default, ch_never, j_sec, j_update). 4357 o Appendix C.3 describes MIDI command timestamp semantics 4358 (linerate, mperiod, octpos, tsmode). 4360 o Appendix C.4 describes the temporal duration ("media time") 4361 of an RTP MIDI packet (guardtime, rtp_maxptime, rtp_ptime). 4363 o Appendix C.5 concerns stream description (musicport). 4365 o Appendix C.6 describes MIDI rendering (chanmask, cid, 4366 inline, multimode, render, rinit, subrender, smf_cid, 4367 smf_info, smf_inline, smf_url, url). 4369 The parameters listed above may optionally appear in session 4370 descriptions of RTP MIDI streams. If these parameters are used in an 4371 SDP session description, the parameters appear on an fmtp attribute 4372 line. This attribute line applies to the payload type associated with 4373 the fmtp line. 4375 The parameters listed above add extra functionality ("features") to 4376 minimal RTP MIDI streams. In Appendix C.7, we show how to use these 4377 features to support two classes of applications: content-streaming using 4378 RTSP (Appendix C.7.1) and network musical performance using SIP 4379 (Appendix C.7.2). 4381 The participants in a multimedia session MUST share a common view of all 4382 of the RTP MIDI streams that appear in an RTP session, as defined by a 4383 single media (m=) line. In some RTP MIDI applications, the "common 4384 view" restriction makes it difficult to use sendrecv streams (all 4385 parties send and receive), as each party has its own requirements. For 4386 example, a two-party network musical performance application may wish to 4387 customize the renderer on each host to match the CPU performance of the 4388 host [NMP]. 4390 We solve this problem by using two RTP MIDI streams -- one sendonly, one 4391 recvonly -- in lieu of one sendrecv stream. The data flows in the two 4392 streams travel in opposite directions, to control receivers configured 4393 to use different renderers. In the third example in Appendix C.5, we 4394 show how the musicport parameter may be used to define virtual sendrecv 4395 streams. 4397 As a general rule, the RTP MIDI protocol does not handle parameter 4398 changes during a session well, because the parameters describe 4399 heavyweight or stateful configuration that is not easily changed once a 4400 session has begun. Thus, parties SHOULD NOT expect that parameter 4401 change requests during a session will be accepted by other parties. 4402 However, implementors SHOULD support in-session parameter changes that 4403 are easy to handle (for example, the guardtime parameter defined in 4404 Appendix C.4) and SHOULD be capable of accepting requests for changes of 4405 those parameters, as received by its session management protocol (for 4406 example, re-offers in SIP [RFC3264]). 4408 Appendix D defines the Augmented Backus-Naur Form (ABNF, [RFC5234]) 4409 syntax for the payload parameters. Section 11 provides information to 4410 the Internet Assigned Numbers Authority (IANA) on the media types and 4411 parameters defined in this document. 4413 Appendix C.6.5 defines the media type "audio/asc", a stored object for 4414 initializing mpeg4-generic renderers. As described in Appendix C.6, the 4415 audio/asc media type is assigned to the "rinit" parameter to specify an 4416 initialization data object for the default mpeg4-generic renderer. Note 4417 that RTP stream semantics are not defined for "audio/asc". Therefore, 4418 the "asc" subtype MUST NOT appear on the rtpmap line of a session 4419 description. 4421 C.1. Configuration Tools: Stream Subsetting 4423 As defined in Section 3.2 in the main text, the MIDI list of an RTP MIDI 4424 packet may encode any MIDI command that may legally appear on a MIDI 1.0 4425 DIN cable. 4427 In this appendix, we define two parameters (cm_unused and cm_used) that 4428 modify this default condition, by excluding certain types of MIDI 4429 commands from the MIDI list of all packets in a stream. For example, if 4430 a multimedia session partitions a MIDI name space into two RTP MIDI 4431 streams, the parameters may be used to define which commands appear in 4432 each stream. 4434 In this appendix, we define a simple language for specifying MIDI 4435 command types. If a command type is assigned to cm_unused, the commands 4436 coded by the string MUST NOT appear in the MIDI list. If a command type 4437 is assigned to cm_used, the commands coded by the string MAY appear in 4438 the MIDI list. 4440 The parameter list may code multiple assignments to cm_used and 4441 cm_unused. Assignments have a cumulative effect and are applied in the 4442 order of appearance in the parameter list. A later assignment of a 4443 command type to the same parameter expands the scope of the earlier 4444 assignment. A later assignment of a command type to the opposite 4445 parameter cancels (partially or completely) the effect of an earlier 4446 assignment. 4448 To initialize the stream subsetting system, "implicit" assignments to 4449 cm_unused and cm_used are processed before processing the actual 4450 assignments that appear in the parameter list. The System Common 4451 undefined commands (0xF4, 0xF5) and the System Real-Time Undefined 4452 commands (0xF9, 0xFD) are implicitly assigned to cm_unused. All other 4453 command types are implicitly assigned to cm_used. 4455 Note that the implicit assignments code the default behavior of an RTP 4456 MIDI stream as defined in Section 3.2 in the main text (namely, that all 4457 commands that may legally appear on a MIDI 1.0 DIN cable may appear in 4458 the stream). Also note that assignments of the System Common undefined 4459 commands (0xF4, 0xF5) apply to the use of these commands in the MIDI 4460 source command stream, not the special use of 0xF4 and 0xF5 in SysEx 4461 segment encoding defined in Section 3.2 in the main text. 4463 As a rule, parameter assignments obey the following syntax (see Appendix 4464 D for ABNF): 4466 = [channel list][field list] 4468 The command-type list is mandatory; the channel and field lists are 4469 optional. 4471 The command-type list specifies the MIDI command types for which the 4472 parameter applies. The command-type list is a concatenated sequence of 4473 one or more of the letters (ABCFGHJKMNPQTVWXYZ). The letters code the 4474 following command types: 4476 o A: Poly Aftertouch (0xA) 4477 o B: System Reset (0xFF) 4478 o C: Control Change (0xB) 4479 o F: System Time Code (0xF1) 4480 o G: System Tune Request (0xF6) 4481 o H: System Song Select (0xF3) 4482 o J: System Common Undefined (0xF4) 4483 o K: System Common Undefined (0xF5) 4484 o N: NoteOff (0x8), NoteOn (0x9) 4485 o P: Program Change (0xC) 4486 o Q: System Sequencer (0xF2, 0xF8, 0xFA, 0xFB, 0xFC) 4487 o T: Channel Aftertouch (0xD) 4488 o V: System Active Sense (0xFE) 4489 o W: Pitch Wheel (0xE) 4490 o X: SysEx (0xF0, 0xF7) 4491 o Y: System Real-Time Undefined (0xF9) 4492 o Z: System Real-Time Undefined (0xFD) 4494 In addition to the letters above, the letter M may also appear in the 4495 command-type list. The letter M refers to the MIDI parameter system 4496 (see definition in Appendix A.1 and in [MIDI]). An assignment of M to 4497 cm_unused codes that no RPN or NRPN transactions may appear in the MIDI 4498 list. 4500 Note that if cm_unused is assigned the letter M, Control Change (0xB) 4501 commands for the controller numbers in the standard controller 4502 assignment might still appear in the MIDI list. For an explanation, see 4503 Appendix A.3.4 for a discussion of the "general-purpose" use of 4504 parameter system controller numbers. 4506 In the text below, rules that apply to "MIDI voice channel commands" 4507 also apply to the letter M. 4509 The letters in the command-type list MUST be uppercase and MUST appear 4510 in alphabetical order. Letters other than (ABCFGHJKMNPQTVWXYZ) that 4511 appear in the list MUST be ignored. 4513 For MIDI voice channel commands, the channel list specifies the MIDI 4514 channels for which the parameter applies. If no channel list is 4515 provided, the parameter applies to all MIDI channels (0-15). The 4516 channel list takes the form of a list of channel numbers (0 through 15) 4517 and dash-separated channel number ranges (i.e., 0-5, 8-12, etc.). Dots 4518 (i.e., "." characters) separate elements in the channel list. 4520 Recall that System commands do not have a MIDI channel associated with 4521 them. Thus, for most command-type letters that code System commands (B, 4522 F, G, H, J, K, Q, V, Y, and Z), the channel list is ignored. 4524 For the command-type letter X, the appearance of certain numbers in the 4525 channel list codes special semantics. 4527 o The digit 0 codes that SysEx "cancel" sublists (Section 4528 3.2 in the main text) MUST NOT appear in the MIDI list. 4530 o The digit 1 codes that cancel sublists MAY appear in the 4531 MIDI list (the default condition). 4533 o The digit 2 codes that commands other than System 4534 Real-time MIDI commands MUST NOT appear between SysEx 4535 command segments in the MIDI list (the default condition). 4537 o The digit 3 codes that any MIDI command type may 4538 appear between SysEx command segments in the MIDI list, 4539 with the exception of the segmented encoding of a second 4540 SysEx command (verbatim SysEx commands are OK). 4542 For command-type X, the channel list MUST NOT contain both digits 0 and 4543 1, and it MUST NOT contain both digits 2 and 3. For command-type X, 4544 channel list numbers other than the numbers defined above are ignored. 4545 If X does not have a channel list, the semantics marked "the default 4546 condition" in the list above apply. 4548 The syntax for field lists in a parameter assignment follows the syntax 4549 for channel lists. If no field list is provided, the parameter applies 4550 to all controller or note numbers. 4552 For command-type C (Control Change), the field list codes the controller 4553 numbers (0-255) for which the parameter applies. 4555 For command-type M (Parameter System), the field list codes the 4556 Registered Parameter Numbers (RPNs) and Non-Registered Parameter Numbers 4557 (NRPNs) for which the parameter applies. The number range 0-16383 4558 specifies RPNs, the number range 16384-32767 specifies NRPNs (16384 4559 corresponds to NRPN 0, 32767 corresponds to NRPN 16383). 4561 For command-types N (NoteOn and NoteOff) and A (Poly Aftertouch), the 4562 field list codes the note numbers for which the parameter applies. 4564 For command-types J and K (System Common Undefined), the field list 4565 consists of a single digit, which specifies the number of data octets 4566 that follow the command octet. 4568 For command-type X (SysEx), the field list codes the number of data 4569 octets that may appear in a SysEx command. Thus, the field list 0-255 4570 specifies SysEx commands with 255 or fewer data octets, the field list 4571 256-4294967295 specifies SysEx commands with more than 255 data octets 4572 but excludes commands with 255 or fewer data octets, and the field list 4573 0 excludes all commands. 4575 A secondary parameter assignment syntax customizes command-type X (see 4576 Appendix D for complete ABNF): 4578 = "__" *( "_" ) "__" 4580 The assignment defines the class of SysEx commands that obeys the 4581 semantics of the assigned parameter. The command class is specified by 4582 listing the permitted values of the first N data octets that follow the 4583 SysEx 0xF0 command octet. Any SysEx command whose first N data octets 4584 match the list is a member of the class. 4586 Each defines a data octet of the command, as a dot-separated 4587 (".") list of one or more hexadecimal constants (such as "7F") or dash- 4588 separated hexadecimal ranges (such as "01-1F"). Underscores ("_") 4589 separate each . Double-underscores ("__") delineate the data 4590 octet list. 4592 Using this syntax, each assignment specifies a single SysEx command 4593 class. Session descriptions may use several assignments to cm_used and 4594 cm_unused to specify complex behaviors. 4596 The example session description below illustrates the use of the stream 4597 subsetting parameters: 4599 v=0 4600 o=lazzaro 2520644554 2838152170 IN IP6 first.example.net 4601 s=Example 4602 t=0 0 4603 m=audio 5004 RTP/AVP 96 4604 c=IN IP6 2001:DB80::7F2E:172A:1E24 4605 a=rtpmap:96 rtp-midi/44100 4606 a=fmtp:96 cm_unused=ACGHJKNMPTVWXYZ; cm_used=__7F_00-7F_01_01__ 4608 The session description configures the stream for use in clock 4609 applications. All voice channels are unused, as are all System Commands 4610 except those used for MIDI Time Code (command-type F, and the Full Frame 4611 SysEx command that is matched by the string assigned to cm_used), the 4612 System Sequencer commands (command-type Q), and System Reset (command- 4613 type B). 4615 C.2. Configuration Tools: The Journalling System 4617 In this appendix, we define the payload format parameters that configure 4618 stream journalling and the recovery journal system. 4620 The j_sec parameter (Appendix C.2.1) sets the journalling method for the 4621 stream. The j_update parameter (Appendix C.2.2) sets the recovery 4622 journal sending policy for the stream. Appendix C.2.2 also defines the 4623 sending policies of the recovery journal system. 4625 Appendix C.2.3 defines several parameters that modify the recovery 4626 journal semantics. These parameters change the default recovery journal 4627 semantics as defined in Section 5 and Appendices A-B. 4629 The journalling method for a stream is set at the start of a session and 4630 MUST NOT be changed thereafter. This requirement forbids changes to the 4631 j_sec parameter once a session has begun. 4633 A related requirement, defined in the appendix sections below, forbids 4634 the acceptance of parameter values that would violate the recovery 4635 journal mandate. In many cases, a change in one of the parameters 4636 defined in this appendix during an ongoing session would result in a 4637 violation of the recovery journal mandate for an implementation; in this 4638 case, the parameter change MUST NOT be accepted. 4640 C.2.1. The j_sec Parameter 4642 Section 2.2 defines the default journalling method for a stream. 4643 Streams that use unreliable transport (such as UDP) default to using the 4644 recovery journal. Streams that use reliable transport (such as TCP) 4645 default to not using a journal. 4647 The parameter j_sec may be used to override this default. This memo 4648 defines two symbolic values for j_sec: "none", to indicate that all 4649 stream payloads MUST NOT contain a journal section, and "recj", to 4650 indicate that all stream payloads MUST contain a journal section that 4651 uses the recovery journal format. 4653 For example, the j_sec parameter might be set to "none" for a UDP stream 4654 that travels between two hosts on a local network that is known to 4655 provide reliable datagram delivery. 4657 The session description below configures a UDP stream that does not use 4658 the recovery journal: 4660 v=0 4661 o=lazzaro 2520644554 2838152170 IN IP4 first.example.net 4662 s=Example 4663 t=0 0 4664 m=audio 5004 RTP/AVP 96 4665 c=IN IP4 192.0.2.94 4666 a=rtpmap:96 rtp-midi/44100 4667 a=fmtp:96 j_sec=none 4669 Other IETF standards-track documents may define alternative journal 4670 formats. These documents MUST define new symbolic values for the j_sec 4671 parameter to signal the use of the format. 4673 Parties MUST NOT accept a j_sec value that violates the recovery journal 4674 mandate (see Section 4 for details). If a session description uses a 4675 j_sec value unknown to the recipient, the recipient MUST NOT accept the 4676 description. 4678 Special j_sec issues arise when sessions are managed by session 4679 management tools (like RTSP, [RFC2326]) that use SDP for "declarative 4680 usage" purposes (see the preamble of Section 6 for details). For these 4681 session management tools, SDP does not code transport details (such as 4682 UDP or TCP) for the session. Instead, server and client negotiate 4683 transport details via other means (for RTSP, the SETUP method). 4685 In this scenario, the use of the j_sec parameter may be ill-advised, as 4686 the creator of the session description may not yet know the transport 4687 type for the session. In this case, the session description SHOULD 4688 configure the journalling system using the parameters defined in the 4689 remainder of Appendix C.2, but it SHOULD NOT use j_sec to set the 4690 journalling status. Recall that if j_sec does not appear in the session 4691 description, the default method for choosing the journalling method is 4692 in effect (no journal for reliable transport, recovery journal for 4693 unreliable transport). 4695 However, in declarative usage situations where the creator of the 4696 session description knows that journalling is always required or never 4697 required, the session description SHOULD use the j_sec parameter. 4699 C.2.2. The j_update Parameter 4701 In Section 4, we use the term "sending policy" to describe the method a 4702 sender uses to choose the checkpoint packet identity for each recovery 4703 journal in a stream. In the sub-sections that follow, we normatively 4704 define three sending policies: anchor, closed-loop, and open-loop. 4706 As stated in Section 4, the default sending policy for a stream is the 4707 closed-loop policy. The j_update parameter may be used to override this 4708 default. 4710 We define three symbolic values for j_update: "anchor", to indicate that 4711 the stream uses the anchor sending policy, "open-loop", to indicate that 4712 the stream uses the open-loop sending policy, and "closed-loop", to 4713 indicate that the stream uses the closed-loop sending policy. See 4714 Appendix C.2.3 for examples session descriptions that use the j_update 4715 parameter. 4717 Parties MUST NOT accept a j_update value that violates the recovery 4718 journal mandate (Section 4). 4720 Other IETF standards-track documents may define additional sending 4721 policies for the recovery journal system. These documents MUST define 4722 new symbolic values for the j_update parameter to signal the use of the 4723 new policy. If a session description uses a j_update value unknown to 4724 the recipient, the recipient MUST NOT accept the description. 4726 C.2.2.1. The anchor Sending Policy 4728 In the anchor policy, the sender uses the first packet in the stream as 4729 the checkpoint packet for all packets in the stream. The anchor policy 4730 satisfies the recovery journal mandate (Section 4), as the checkpoint 4731 history always covers the entire stream. 4733 The anchor policy does not require the use of the RTP control protocol 4734 (RTCP, [RFC3550]) or other feedback from receiver to sender. Senders do 4735 not need to take special actions to ensure that received streams start 4736 up free of artifacts, as the recovery journal always covers the entire 4737 history of the stream. Receivers are relieved of the responsibility of 4738 tracking the changing identity of the checkpoint packet, because the 4739 checkpoint packet never changes. 4741 The main drawback of the anchor policy is bandwidth efficiency. Because 4742 the checkpoint history covers the entire stream, the size of the 4743 recovery journals produced by this policy usually exceeds the journal 4744 size of alternative policies. For single-channel MIDI data streams, the 4745 bandwidth overhead of the anchor policy is often acceptable (see 4746 Appendix A.4 of [NMP]). For dense streams, the closed-loop or open-loop 4747 policies may be more appropriate. 4749 C.2.2.2. The closed-loop Sending Policy 4751 The closed-loop policy is the default policy of the recovery journal 4752 system. For each packet in the stream, the policy lets senders choose 4753 the smallest possible checkpoint history that satisfies the recovery 4754 journal mandate. As smaller checkpoint histories generally yield 4755 smaller recovery journals, the closed-loop policy reduces the bandwidth 4756 of a stream, relative to the anchor policy. 4758 The closed-loop policy relies on feedback from receiver to sender. The 4759 policy assumes that a receiver periodically informs the sender of the 4760 highest sequence number it has seen so far in the stream, coded in the 4761 32-bit extension format defined in [RFC3550]. For RTCP, receivers 4762 transmit this information in the Extended Highest Sequence Number 4763 Received (EHSNR) field of Receiver Reports. RTCP Sender or Receiver 4764 Reports MUST be sent by any participant in a session with closed loop 4765 sending policy, unless another feedback mechanism has been agreed upon. 4767 The sender may safely use receiver sequence number feedback to guide 4768 checkpoint history management, because Section 4 requires that receivers 4769 repair indefinite artifacts whenever a packet loss event occur. 4771 We now normatively define the closed-loop policy. At the moment a 4772 sender prepares an RTP packet for transmission, the sender is aware of R 4773 >= 0 receivers for the stream. Senders may become aware of a receiver 4774 via RTCP traffic from the receiver, via RTP packets from a paired stream 4775 sent by the receiver to the sender, via messages from a session 4776 management tool, or by other means. As receivers join and leave a 4777 session, the value of R changes. 4779 Each known receiver k (1 <= k <= R) is associated with a 32-bit extended 4780 packet sequence number M(k), where the extension reflects the sequence 4781 number rollover count of the sender. 4783 If the sender has received at least one feedback report from receiver k, 4784 M(k) is the most recent report of the highest RTP packet sequence number 4785 seen by the receiver, normalized to reflect the rollover count of the 4786 sender. 4788 If the sender has not received a feedback report from the receiver, M(k) 4789 is the extended sequence number of the last packet the sender 4790 transmitted before it became aware of the receiver. If the sender 4791 became aware of this receiver before it sent the first packet in the 4792 stream, M(k) is the extended sequence number of the first packet in the 4793 stream. 4795 Given this definition of M(), we now state the closed-loop policy. When 4796 preparing a new packet for transmission, a sender MUST choose a 4797 checkpoint packet with extended sequence number N, such that M(k) >= (N 4798 - 1) for all k, 1 <= k <= R, where R >= 1. The policy does not restrict 4799 sender behavior in the R == 0 (no known receivers) case. 4801 Under the closed-loop policy as defined above, a sender may transmit 4802 packets whose checkpoint history is shorter than the session history (as 4803 defined in Appendix A.1). In this event, a new receiver that joins the 4804 stream may experience indefinite artifacts. 4806 For example, if a Control Change (0xB) command for Channel Volume 4807 (controller number 7) was sent early in a stream, and later a new 4808 receiver joins the session, the closed-loop policy may permit all 4809 packets sent to the new receiver to use a checkpoint history that does 4810 not include the Channel Volume Control Change command. As a result, the 4811 new receiver experiences an indefinite artifact, and plays all notes on 4812 a channel too loudly or too softly. 4814 To address this issue, the closed-loop policy states that whenever a 4815 sender becomes aware of a new receiver, the sender MUST determine if the 4816 receiver would be subject to indefinite artifacts under the closed-loop 4817 policy. If so, the sender MUST ensure that the receiver starts the 4818 session free of indefinite artifacts. For example, to solve the Channel 4819 Volume issue described above, the sender may code the current state of 4820 the Channel Volume controller numbers in the recovery journal Chapter C, 4821 until it receives the first RTCP RR report that signals that a packet 4822 containing this Chapter C has been received. 4824 In satisfying this requirement, senders MAY infer the initial MIDI state 4825 of the receiver from the session description. For example, the stream 4826 example in Section 6.2 has the initial state defined in [MIDI] for 4827 General MIDI. 4829 In a unicast RTP session, a receiver may safely assume that the sender 4830 is aware of its presence as a receiver from the first packet sent in the 4831 RTP stream. However, in other types of RTP sessions (multicast, 4832 conference focus, RTP translator/mixer), a receiver is often not able to 4833 determine if the sender is initially aware of its presence as a 4834 receiver. 4836 To address this issue, the closed-loop policy states that if a receiver 4837 participates in a session where it may have access to a stream whose 4838 sender is not aware of the receiver, the receiver MUST take actions to 4839 ensure that its rendered MIDI performance does not contain indefinite 4840 artifacts. These protections will be necessarily incomplete. For 4841 example, a receiver may monitor the Checkpoint Packet Seqnum for 4842 uncovered loss events, and "err on the side of caution" with respect to 4843 handling stuck notes due to lost MIDI NoteOff commands, but the receiver 4844 is not able to compensate for the lack of Channel Volume initialization 4845 data in the recovery journal. 4847 The receiver MUST NOT discontinue these protective actions until it is 4848 certain that the sender is aware of its presence. If a receiver is not 4849 able to ascertain sender awareness, the receiver MUST continue these 4850 protective actions for the duration of the session. 4852 Note that in a multicast session where all parties are expected to send 4853 and receive, the reception of RTCP receiver reports from the sender 4854 about the RTP stream a receiver is multicasting back is evidence of the 4855 sender's awareness that the RTP stream multicast by the sender is being 4856 monitored by the receiver. Receivers may also obtain sender awareness 4857 evidence from session management tools, or by other means. In practice, 4858 ongoing observation of the Checkpoint Packet Seqnum to determine if the 4859 sender is taking actions to prevent loss events for a receiver is a good 4860 indication of sender awareness, as is the sudden appearance of recovery 4861 journal chapters with numerous Control Change controller data that was 4862 not foreshadowed by recent commands coded in the MIDI list shortly after 4863 sending an RTCP RR. 4865 The final set of normative closed-loop policy requirements concerns how 4866 senders and receivers handle unplanned disruptions of RTCP feedback from 4867 a receiver to a sender. By "unplanned", we refer to disruptions that 4868 are not due to the signalled termination of an RTP stream, via an RTCP 4869 BYE or via session management tools. 4871 As defined earlier in this section, the closed-loop policy states that a 4872 sender MUST choose a checkpoint packet with extended sequence number N, 4873 such that M(k) >= (N - 1) for all k, 1 <= k <= R, where R >= 1. If the 4874 sender has received at least one feedback report from receiver k, M(k) 4875 is the most recent report of the highest RTP packet sequence number seen 4876 by the receiver, normalized to reflect the rollover count of the sender. 4878 If this receiver k stops sending feedback to the sender, the M(k) value 4879 used by the sender reflects the last feedback report from the receiver. 4880 As time progresses without feedback from receiver k, this fixed M(k) 4881 value forces the sender to increase the size of the checkpoint history, 4882 and thus increases the bandwidth of the stream. 4884 At some point, the sender may need to take action in order to limit the 4885 bandwidth of the stream. In most envisioned uses of RTP MIDI, long 4886 before this point is reached, the SSRC time-out mechanism defined in 4887 [RFC3550] will remove the uncooperative receiver from the session (note 4888 that the closed-loop policy does not suggest or require any special 4889 sender behavior upon an SSRC time-out, other than the sender actions 4890 related to changing R, described earlier in this section). 4892 However, in rare situations, the bandwidth of the stream (due to a lack 4893 of feedback reports from the sender) may become too large to continue 4894 sending the stream to the receiver before the SSRC time-out occurs for 4895 the receiver. In this case, the closed-loop policy states that the 4896 sender should invoke the SSRC time-out for the receiver early. 4898 We now discuss receiver responsibilities in the case of unplanned 4899 disruptions of RTCP feedback from receiver to sender. 4901 In the unicast case, if a sender invokes the SSRC time-out mechanism for 4902 a receiver, the receiver stops receiving packets from the sender. The 4903 sender behavior imposed by the guardtime parameter (Appendix C.4.2) lets 4904 the receiver conclude that an SSRC time-out has occurred in a reasonable 4905 time period. 4907 In this case of a time-out, a receiver MUST keep sending RTCP feedback, 4908 in order to re-establish the RTP flow from the sender. Unless the 4909 receiver expects a prompt recovery of the RTP flow, the receiver MUST 4910 take actions to ensure that the rendered MIDI performance does not 4911 exhibit "very long transient artifacts" (for example, by silencing 4912 NoteOns to prevent stuck notes) while awaiting reconnection of the flow. 4914 In the multicast case, if a sender invokes the SSRC time-out mechanism 4915 for a receiver, the receiver may continue to receive packets, but the 4916 sender will no longer be using the M(k) feedback from the receiver to 4917 choose each checkpoint packet. If the receiver does not have additional 4918 information that precludes an SSRC time-out (such as RTCP Receiver 4919 Reports from the sender about an RTP stream the receiver is multicasting 4920 back to the sender), the receiver MUST monitor the Checkpoint Packet 4921 Seqnum to detect an SSRC time-out. If an SSRC time-out is detected, the 4922 receiver MUST follow the instructions for SSRC time-outs described for 4923 the unicast case above. 4925 Finally, we note that the closed-loop policy is suitable for use in 4926 RTP/RTCP sessions that use multicast transport. However, aspects of the 4927 closed-loop policy do not scale well to sessions with large numbers of 4928 participants. The sender state scales linearly with the number of 4929 receivers, as the sender needs to track the identity and M(k) value for 4930 each receiver k. The average recovery journal size is not independent 4931 of the number of receivers, as the RTCP reporting interval backoff slows 4932 down the rate of a full update of M(k) values. The backoff algorithm 4933 may also increase the amount of ancillary state used by implementations 4934 of the normative sender and receiver behaviors defined in Section 4. 4936 C.2.2.3. The open-loop Sending Policy 4938 The open-loop policy is suitable for sessions that are not able to 4939 implement the receiver-to-sender feedback required by the closed-loop 4940 policy, and that are also not able to use the anchor policy because of 4941 bandwidth constraints. 4943 The open-loop policy does not place constraints on how a sender chooses 4944 the checkpoint packet for each packet in the stream. In the absence of 4945 such constraints, a receiver may find that the recovery journal in the 4946 packet that ends a loss event has a checkpoint history that does not 4947 cover the entire loss event. We refer to loss events of this type as 4948 uncovered loss events. 4950 To ensure that uncovered loss events do not compromise the recovery 4951 journal mandate, the open-loop policy assigns specific recovery tasks to 4952 senders, receivers, and the creators of session descriptions. The 4953 underlying premise of the open-loop policy is that the indefinite 4954 artifacts produced during uncovered loss events fall into two classes. 4956 One class of artifacts is recoverable indefinite artifacts. Receivers 4957 are able to repair recoverable artifacts that occur during an uncovered 4958 loss event without intervention from the sender, at the potential cost 4959 of unpleasant transient artifacts. 4961 For example, after an uncovered loss event, receivers are able to repair 4962 indefinite artifacts due to NoteOff (0x8) commands that may have 4963 occurred during the loss event, by executing NoteOff commands for all 4964 active NoteOns commands. This action causes a transient artifact (a 4965 sudden silent period in the performance), but ensures that no stuck 4966 notes sound indefinitely. We refer to MIDI commands that are amenable 4967 to repair in this fashion as recoverable MIDI commands. 4969 A second class of artifacts is unrecoverable indefinite artifacts. If 4970 this class of artifact occurs during an uncovered loss event, the 4971 receiver is not able to repair the stream. 4973 For example, after an uncovered loss event, receivers are not able to 4974 repair indefinite artifacts due to Control Change (0xB) Channel Volume 4975 (controller number 7) commands that have occurred during the loss event. 4976 A repair is impossible because the receiver has no way of determining 4977 the data value of a lost Channel Volume command. We refer to MIDI 4978 commands that are fragile in this way as unrecoverable MIDI commands. 4980 The open-loop policy does not specify how to partition the MIDI command 4981 set into recoverable and unrecoverable commands. Instead, it assumes 4982 that the creators of the session descriptions are able to come to 4983 agreement on a suitable recoverable/unrecoverable MIDI command partition 4984 for an application. 4986 Given these definitions, we now state the normative requirements for the 4987 open-loop policy. 4989 In the open-loop policy, the creators of the session description MUST 4990 use the ch_anchor parameter (defined in Appendix C.2.3) to protect all 4991 unrecoverable MIDI command types from indefinite artifacts, or 4992 alternatively MUST use the cm_unused parameter (defined in Appendix C.1) 4993 to exclude the command types from the stream. These options act to 4994 shield command types from artifacts during an uncovered loss event. 4996 In the open-loop policy, receivers MUST examine the Checkpoint Packet 4997 Seqnum field of the recovery journal header after every loss event, to 4998 check if the loss event is an uncovered loss event. Section 5 shows how 4999 to perform this check. If an uncovered loss event has occurred, a 5000 receiver MUST perform indefinite artifact recovery for all MIDI command 5001 types that are not shielded by ch_anchor and cm_unused parameter 5002 assignments in the session description. 5004 The open-loop policy does not place specific constraints on the sender. 5005 However, the open-loop policy works best if the sender manages the size 5006 of the checkpoint history to ensure that uncovered losses occur 5007 infrequently, by taking into account the delay and loss characteristics 5008 of the network. Also, as each checkpoint packet change incurs the risk 5009 of an uncovered loss, senders should only move the checkpoint if it 5010 reduces the size of the journal. 5012 C.2.3. Recovery Journal Chapter Inclusion Parameters 5014 The recovery journal chapter definitions (Appendices A-B) specify under 5015 what conditions a chapter MUST appear in the recovery journal. In most 5016 cases, the definition states that if a certain command appears in the 5017 checkpoint history, a certain chapter type MUST appear in the recovery 5018 journal to protect the command. 5020 In this section, we describe the chapter inclusion parameters. These 5021 parameters modify the conditions under which a chapter appears in the 5022 journal. These parameters are essential to the use of the open-loop 5023 policy (Appendix C.2.2.3) and may also be used to simplify 5024 implementations of the closed-loop (Appendix C.2.2.2) and anchor 5025 (Appendix C.2.2.1) policies. 5027 Each parameter represents a type of chapter inclusion semantics. An 5028 assignment to a parameter declares which chapters (or chapter subsets) 5029 obey the inclusion semantics. We describe the assignment syntax for 5030 these parameters later in this section. 5032 A party MUST NOT accept chapter inclusion parameter values that violate 5033 the recovery journal mandate (Section 4). All assignments of the 5034 subsetting parameters (cm_used and cm_unused) MUST precede the first 5035 assignment of a chapter inclusion parameter in the parameter list. 5037 Below, we normatively define the semantics of the chapter inclusion 5038 parameters. For clarity, we define the action of parameters on complete 5039 chapters. If a parameter is assigned a subset of a chapter, the 5040 definition applies only to the chapter subset. 5042 o ch_never. A chapter assigned to the ch_never parameter MUST 5043 NOT appear in the recovery journal (Appendix A.4.1-2 defines 5044 exceptions to this rule for Chapter M). To signal the exclusion 5045 of a chapter from the journal, an assignment to ch_never MUST 5046 be made, even if the commands coded by the chapter are assigned 5047 to cm_unused. This rule simplifies the handling of commands 5048 types that may be coded in several chapters. 5050 o ch_default. A chapter assigned to the ch_default parameter 5051 MUST follow the default semantics for the chapter, as defined 5052 in Appendices A-B. 5054 o ch_anchor. A chapter assigned to the ch_anchor MUST obey a 5055 modified version of the default chapter semantics. In the 5056 modified semantics, all references to the checkpoint history 5057 are replaced with references to the session history, and all 5058 references to the checkpoint packet are replaced with 5059 references to the first packet sent in the stream. 5061 Parameter assignments obey the following syntax (see Appendix D for 5062 ABNF): 5064 = [channel list][field list] 5066 The chapter list is mandatory; the channel and field lists are optional. 5067 Multiple assignments to parameters have a cumulative effect and are 5068 applied in the order of parameter appearance in a media description. 5070 To determine the semantics of a list of chapter inclusion parameter 5071 assignments, we begin by assuming an implicit assignment of all channel 5072 and system chapters to the ch_default parameter, with the default values 5073 for the channel list and field list for each chapter that are defined 5074 below. 5076 We then interpret the semantics of the actual parameter assignments, 5077 using the rules below. 5079 A later assignment of a chapter to the same parameter expands the scope 5080 of the earlier assignment. In most cases, a later assignment of a 5081 chapter to a different parameter cancels (partially or completely) the 5082 effect of an earlier assignment. 5084 The chapter list specifies the channel or system chapters for which the 5085 parameter applies. The chapter list is a concatenated sequence of one 5086 or more of the letters corresponding to the chapter types 5087 (ACDEFMNPQTVWX). In addition, the list may contain one or more of the 5088 letters for the sub-chapter types (BGHJKYZ) of System Chapter D. 5090 The letters in a chapter list MUST be uppercase and MUST appear in 5091 alphabetical order. Letters other than (ABCDEFGHJKMNPQTVWXYZ) that 5092 appear in the chapter list MUST be ignored. 5094 The channel list specifies the channel journals for which this parameter 5095 applies; if no channel list is provided, the parameter applies to all 5096 channel journals. The channel list takes the form of a list of channel 5097 numbers (0 through 15) and dash-separated channel number ranges (i.e., 5098 0-5, 8-12, etc.). Dots (i.e., "." characters) separate elements in the 5099 channel list. 5101 Several of the systems chapters may be configured to have special 5102 semantics. Configuration occurs by specifying a channel list for the 5103 systems channel, using the coding described below (note that MIDI 5104 Systems commands do not have a "channel", and thus the original purpose 5105 of the channel list does not apply to systems chapters). The expression 5106 "the digit N" in the text below refers to the inclusion of N as a 5107 "channel" in the channel list for a systems chapter. 5109 For the J and K Chapter D sub-chapters (undefined System Common), the 5110 digit 0 codes that the parameter applies to the LEGAL field of the 5111 associated command log (Figure B.1.4 of Appendix B.1), the digit 1 codes 5112 that the parameter applies to the VALUE field of the command log, and 5113 the digit 2 codes that the parameter applies to the COUNT field of the 5114 command log. 5116 For the Y and Z Chapter D sub-chapters (undefined System Real-time), the 5117 digit 0 codes that the parameter applies to the LEGAL field of the 5118 associated command log (Figure B.1.5 of Appendix B.1) and the digit 1 5119 codes that the parameter applies to the COUNT field of the command log. 5121 For Chapter Q (Sequencer State Commands), the digit 0 codes that the 5122 parameter applies to the default Chapter Q definition, which forbids the 5123 TIME field. The digit 1 codes that the parameter applies to the 5124 optional Chapter Q definition, which supports the TIME field. 5126 The syntax for field lists follows the syntax for channel lists. If no 5127 field list is provided, the parameter applies to all controller or note 5128 numbers. For Chapter C, if no field list is provided, the controller 5129 numbers do not use enhanced Chapter C encoding (Appendix A.3.3). 5131 For Chapter C, the field list may take on values in the range 0 to 255. 5132 A field value X in the range 0-127 refers to a controller number X, and 5133 indicates that the controller number does not use enhanced Chapter C 5134 encoding. A field value X in the range 128-255 refers to a controller 5135 number "X minus 128" and indicates the controller number does use the 5136 enhanced Chapter C encoding. 5138 Assignments made to configure the Chapter C encoding method for a 5139 controller number MUST be made to the ch_default or ch_anchor 5140 parameters, as assignments to ch_never act to exclude the number from 5141 the recovery journal (and thus the indicated encoding method is 5142 irrelevant). 5144 A Chapter C field list MUST NOT encode conflicting information about the 5145 enhanced encoding status of a particular controller number. For 5146 example, values 0 and 128 MUST NOT both be coded by a field list. 5148 For Chapter M, the field list codes the Registered Parameter Numbers 5149 (RPNs) and Non-Registered Parameter Numbers (NRPNs) for which the 5150 parameter applies. The number range 0-16383 specifies RPNs, the number 5151 range 16384-32767 specifies NRPNs (16384 corresponds to NRPN 0, 32767 5152 corresponds to NRPN 16383). 5154 For Chapters N and A, the field list codes the note numbers for which 5155 the parameter applies. The note number range specified for Chapter N 5156 also applies to Chapter E. 5158 For Chapter E, the digit 0 codes that the parameter applies to Chapter E 5159 note logs whose V bit is set to 0, and the digit 1 codes that the 5160 parameter applies to note logs whose V bit is set to 1. 5162 For Chapter X, the field list codes the number of data octets that may 5163 appear in a SysEx command that is coded in the chapter. Thus, the field 5164 list 0-255 specifies SysEx commands with 255 or fewer data octets, the 5165 field list 256-4294967295 specifies SysEx commands with more than 255 5166 data octets but excludes commands with 255 or fewer data octets, and the 5167 field list 0 excludes all commands. 5169 A secondary parameter assignment syntax customizes Chapter X (see 5170 Appendix D for complete ABNF): 5172 = "__" *( "_" ) "__" 5174 The assignment defines a class of SysEx commands whose Chapter X coding 5175 obeys the semantics of the assigned parameter. The command class is 5176 specified by listing the permitted values of the first N data octets 5177 that follow the SysEx 0xF0 command octet. Any SysEx command whose first 5178 N data octets match the list is a member of the class. 5180 Each defines a data octet of the command, as a dot-separated 5181 (".") list of one or more hexadecimal constants (such as "7F") or dash- 5182 separated hexadecimal ranges (such as "01-1F"). Underscores ("_") 5183 separate each . Double-underscores ("__") delineate the data 5184 octet list. 5186 Using this syntax, each assignment specifies a single SysEx command 5187 class. Session descriptions may use several assignments to the same (or 5188 different) parameters to specify complex Chapter X behaviors. The 5189 ordering behavior of multiple assignments follows the guidelines for 5190 chapter parameter assignments described earlier in this section. 5192 The example session description below illustrates the use of the chapter 5193 inclusion parameters: 5195 v=0 5196 o=lazzaro 2520644554 2838152170 IN IP6 first.example.net 5197 s=Example 5198 t=0 0 5199 m=audio 5004 RTP/AVP 96 5200 c=IN IP6 2001:DB80::7F2E:172A:1E24 5201 a=rtpmap:96 rtp-midi/44100 5202 a=fmtp:96 j_update=open-loop; cm_unused=ABCFGHJKMQTVWXYZ; 5203 cm_used=__7E_00-7F_09_01.02.03__; 5204 cm_used=__7F_00-7F_04_01.02__; cm_used=C7.64; 5205 ch_never=ABCDEFGHJKMQTVWXYZ; ch_never=4.11-13N; 5206 ch_anchor=P; ch_anchor=C7.64; 5207 ch_anchor=__7E_00-7F_09_01.02.03__; 5208 ch_anchor=__7F_00-7F_04_01.02__ 5210 (The a=fmtp line has been wrapped to fit the page to accommodate 5211 memo formatting restrictions; it comprises a single line in SDP.) 5213 The j_update parameter codes that the stream uses the open-loop policy. 5214 Most MIDI command-types are assigned to cm_unused and thus do not appear 5215 in the stream. As a consequence, the assignments to the first ch_never 5216 parameter reflect that most chapters are not in use. 5218 Chapter N for several MIDI channels is assigned to ch_never. Chapter N 5219 for MIDI channels other than 4, 11, 12, and 13 may appear in the 5220 recovery journal, using the (default) ch_default semantics. In 5221 practice, this assignment pattern would reflect knowledge about a 5222 resilient rendering method in use for the excluded channels. 5224 The MIDI Program Change command and several MIDI Control Change 5225 controller numbers are assigned to ch_anchor. Note that the ordering of 5226 the ch_anchor chapter C assignment after the ch_never command acts to 5227 override the ch_never assignment for the listed controller numbers (7 5228 and 64). 5230 The assignment of command-type X to cm_unused excludes most SysEx 5231 commands from the stream. Exceptions are made for General MIDI System 5232 On/Off commands and for the Master Volume and Balance commands, via the 5233 use of the secondary assignment syntax. The cm_used assignment codes 5234 the exception, and the ch_anchor assignment codes how these commands are 5235 protected in Chapter X. 5237 C.3. Configuration Tools: Timestamp Semantics 5239 The MIDI command section of the payload format consists of a list of 5240 commands, each with an associated timestamp. The semantics of command 5241 timestamps may be set during session configuration, using the parameters 5242 we describe in this section 5244 The parameter "tsmode" specifies the timestamp semantics for a stream. 5245 The parameter takes on one of three token values: "comex", "async", or 5246 "buffer". 5248 The default "comex" value specifies that timestamps code the execution 5249 time for a command (Appendix C.3.1) and supports the accurate 5250 transcoding of Standard MIDI Files (SMFs, [MIDI]). The "comex" value is 5251 also RECOMMENDED for new MIDI user-interface controller designs. The 5252 "async" value specifies an asynchronous timestamp sampling algorithm for 5253 time-of-arrival sources (Appendix C.3.2). The "buffer" value specifies 5254 a synchronous timestamp sampling algorithm (Appendix C.3.3) for time-of- 5255 arrival sources. 5257 Ancillary parameters MAY follow tsmode in a media description. We 5258 define these parameters in Appendices C.3.2-3 below. 5260 C.3.1. The comex Algorithm 5262 The default "comex" (COMmand EXecution) tsmode value specifies the 5263 execution time for the command. With comex, the difference between two 5264 timestamps indicates the time delay between the execution of the 5265 commands. This difference may be zero, coding simultaneous execution. 5267 The comex interpretation of timestamps works well for transcoding a 5268 Standard MIDI File (SMF, [MIDI]) into an RTP MIDI stream, as SMFs code a 5269 timestamp for each MIDI command stored in the file. To transcode an SMF 5270 that uses metric time markers, use the SMF tempo map (encoded in the SMF 5271 as meta-events) to convert metric SMF timestamp units into seconds-based 5272 RTP timestamp units. 5274 New MIDI controller designs (piano keyboard, drum pads, etc.) that 5275 support RTP MIDI and that have direct access to sensor data SHOULD use 5276 comex interpretation for timestamps, so that simultaneous gestural 5277 events may be accurately coded by RTP MIDI. 5279 Comex is a poor choice for transcoding MIDI 1.0 DIN cables [MIDI], for a 5280 reason that we will now explain. A MIDI DIN cable is an asynchronous 5281 serial protocol (320 microseconds per MIDI byte). MIDI commands on a 5282 DIN cable are not tagged with timestamps. Instead, MIDI DIN receivers 5283 infer command timing from the time of arrival of the bytes. Thus, two 5284 two-byte MIDI commands that occur at a source simultaneously are encoded 5285 on a MIDI 1.0 DIN cable with a 640 microsecond time offset. A MIDI DIN 5286 receiver is unable to tell if this time offset existed in the source 5287 performance or is an artifact of the serial speed of the cable. 5288 However, the RTP MIDI comex interpretation of timestamps declares that a 5289 timestamp offset between two commands reflects the timing of the source 5290 performance. 5292 This semantic mismatch is the reason that comex is a poor choice for 5293 transcoding MIDI DIN cables. Note that the choice of the RTP timestamp 5294 rate (Section 6.1-2 in the main text) cannot fix this inaccuracy issue. 5295 In the sections that follow, we describe two alternative timestamp 5296 interpretations ("async" and "buffer") that are a better match to MIDI 5297 1.0 DIN cable timing, and to other MIDI time-of-arrival sources. 5299 The "octpos", "linerate", and "mperiod" ancillary parameters (defined 5300 below) SHOULD NOT be used with comex. 5302 C.3.2. The async Algorithm 5304 The "async" tsmode value specifies the asynchronous sampling of a MIDI 5305 time-of-arrival source. In asynchronous sampling, the moment an octet 5306 is received from a source, it is labelled with a wall-clock time value. 5307 The time value has RTP timestamp units. 5309 The "octpos" ancillary parameter defines how RTP command timestamps are 5310 derived from octet time values. If octpos has the token value "first", 5311 a timestamp codes the time value of the first octet of the command. If 5312 octpos has the token value "last", a timestamp codes the time value of 5313 the last octet of the command. If the octpos parameter does not appear 5314 in the media description, the sender does not know which octet of the 5315 command the timestamp references (for example, the sender may be relying 5316 on an operating system service that does not specify this information). 5318 The octpos semantics refer to the first or last octet of a command as it 5319 appears on a time-of-arrival MIDI source, not as it appears in an RTP 5320 MIDI packet. This distinction is significant because the RTP coding may 5321 contain octets that are not present in the source. For example, the 5322 status octet of the first MIDI command in a packet may have been added 5323 to the MIDI stream during transcoding, to comply with the RTP MIDI 5324 running status requirements (Section 3.2). 5326 The "linerate" ancillary parameter defines the timespan of one MIDI 5327 octet on the transmission medium of the MIDI source to be sampled (such 5328 as a MIDI 1.0 DIN cable). The parameter has units of nanoseconds, and 5329 takes on integral values. For MIDI 1.0 DIN cables, the correct linerate 5330 value is 320000 (this value is also the default value for the 5331 parameter). 5333 We now show a session description example for the async algorithm. 5334 Consider a sender that is transcoding a MIDI 1.0 DIN cable source into 5335 RTP. The sender runs on a computing platform that assigns time values 5336 to every incoming octet of the source, and the sender uses the time 5337 values to label the first octet of each command in the RTP packet. This 5338 session description describes the transcoding: 5340 v=0 5341 o=lazzaro 2520644554 2838152170 IN IP4 first.example.net 5342 s=Example 5343 t=0 0 5344 m=audio 5004 RTP/AVP 96 5345 c=IN IP4 192.0.2.94 5346 a=rtpmap:96 rtp-midi/44100 5347 a=sendonly 5348 a=fmtp:96 tsmode=async; linerate=320000; octpos=first 5350 C.3.3. The buffer Algorithm 5352 The "buffer" tsmode value specifies the synchronous sampling of a MIDI 5353 time-of-arrival source. 5355 In synchronous sampling, octets received from a source are placed in a 5356 holding buffer upon arrival. At periodic intervals, the RTP sender 5357 examines the buffer. The sender removes complete commands from the 5358 buffer and codes those commands in an RTP packet. The command timestamp 5359 codes the moment of buffer examination, expressed in RTP timestamp 5360 units. Note that several commands may have the same timestamp value. 5362 The "mperiod" ancillary parameter defines the nominal periodic sampling 5363 interval. The parameter takes on positive integral values and has RTP 5364 timestamp units. 5366 The "octpos" ancillary parameter, defined in Appendix C.3.1 for 5367 asynchronous sampling, plays a different role in synchronous sampling. 5368 In synchronous sampling, the parameter specifies the timestamp semantics 5369 of a command whose octets span several sampling periods. 5371 If octpos has the token value "first", the timestamp reflects the 5372 arrival period of the first octet of the command. If octpos has the 5373 token value "last", the timestamp reflects the arrival period of the 5374 last octet of the command. The octpos semantics refer to the first or 5375 last octet of the command as it appears on a time-of-arrival source, not 5376 as it appears in the RTP packet. 5378 If the octpos parameter does not appear in the media description, the 5379 timestamp MAY reflect the arrival period of any octet of the command; 5380 senders use this option to signal a lack of knowledge about the timing 5381 details of the buffering process at sub-command granularity. 5383 We now show a session description example for the buffer algorithm. 5384 Consider a sender that is transcoding a MIDI 1.0 DIN cable source into 5385 RTP. The sender runs on a computing platform that places source data 5386 into a buffer upon receipt. The sender polls the buffer 1000 times a 5387 second, extracts all complete commands from the buffer, and places the 5388 commands in an RTP packet. This session description describes the 5389 transcoding: 5391 v=0 5392 o=lazzaro 2520644554 2838152170 IN IP6 first.example.net 5393 s=Example 5394 t=0 0 5395 m=audio 5004 RTP/AVP 96 5396 c=IN IP6 2001:DB80::7F2E:172A:1E24 5397 a=rtpmap:96 rtp-midi/44100 5398 a=sendonly 5399 a=fmtp:96 tsmode=buffer; linerate=320000; octpos=last; mperiod=44 5401 The mperiod value of 44 is derived by dividing the clock rate specified 5402 by the rtpmap attribute (44100 Hz) by the 1000 Hz buffer sampling rate 5403 and rounding to the nearest integer. Command timestamps might not 5404 increment by exact multiples of 44, as the actual sampling period might 5405 not precisely match the nominal mperiod value. 5407 C.4. Configuration Tools: Packet Timing Tools 5409 In this appendix, we describe session configuration tools for 5410 customizing the temporal behavior of MIDI stream packets. 5412 C.4.1. Packet Duration Tools 5414 Senders control the granularity of a stream by setting the temporal 5415 duration ("media time") of the packets in the stream. Short media times 5416 (20 ms or less) often imply an interactive session. Longer media times 5417 (100 ms or more) usually indicate a content streaming session. The RTP 5418 AVP profile [RFC3551] recommends audio packet media times in a range 5419 from 0 to 200 ms. 5421 By default, an RTP receiver dynamically senses the media time of packets 5422 in a stream and chooses the length of its playout buffer to match the 5423 stream. A receiver typically sizes its playout buffer to fit several 5424 audio packets and adjusts the buffer length to reflect the network 5425 jitter and the sender timing fidelity. 5427 Alternatively, the packet media time may be statically set during 5428 session configuration. Session descriptions MAY use the RTP MIDI 5429 parameter "rtp_ptime" to set the recommended media time for a packet. 5430 Session descriptions MAY also use the RTP MIDI parameter "rtp_maxptime" 5431 to set the maximum media time for a packet permitted in a stream. Both 5432 parameters MAY be used together to configure a stream. 5434 The values assigned to the rtp_ptime and rtp_maxptime parameters have 5435 the units of the RTP timestamp for the stream, as set by the rtpmap 5436 attribute (see Section 6.1). Thus, if rtpmap sets the clock rate of a 5437 stream to 44100 Hz, a maximum packet media time of 10 ms is coded by 5438 setting rtp_maxptime=441. As stated in the Appendix C preamble, the 5439 senders and receivers of a stream MUST agree on common values for 5440 rtp_ptime and rtp_maxptime if the parameters appear in the media 5441 description for the stream. 5443 0 ms is a reasonable media time value for MIDI packets and is often used 5444 in low-latency interactive applications. In a packet with a 0 ms media 5445 time, all commands execute at the instant they are coded by the packet 5446 timestamp. The session description below configures all packets in the 5447 stream to have 0 ms media time: 5449 v=0 5450 o=lazzaro 2520644554 2838152170 IN IP4 first.example.net 5451 s=Example 5452 t=0 0 5453 m=audio 5004 RTP/AVP 96 5454 c=IN IP4 192.0.2.94 5455 a=rtpmap:96 rtp-midi/44100 5456 a=fmtp:96 rtp_ptime=0; rtp_maxptime=0 5458 The session attributes ptime and maxptime [RFC4566] MUST NOT be used to 5459 configure an RTP MIDI stream. Sessions MUST use rtp_ptime in lieu of 5460 ptime and MUST use rtp_maxptime in lieu of maxptime. RTP MIDI defines 5461 its own parameters for media time configuration because 0 ms values for 5462 ptime and maxptime are forbidden by [RFC3264] but are essential for 5463 certain applications of RTP MIDI. 5465 See the Appendix C.7 examples for additional discussion about using 5466 rtp_ptime and rtp_maxptime for session configuration. 5468 C.4.2. The guardtime Parameter 5470 RTP permits a sender to stop sending audio packets for an arbitrary 5471 period of time during a session. When sending resumes, the RTP sequence 5472 number series continues unbroken, and the RTP timestamp value reflects 5473 the media time silence gap. 5475 This RTP feature has its roots in telephony, but it is also well matched 5476 to interactive MIDI sessions, as players may fall silent for several 5477 seconds during (or between) songs. 5479 Certain MIDI applications benefit from a slight enhancement to this RTP 5480 feature. In interactive applications, receivers may use on-line network 5481 models to guide heuristics for handling lost and late RTP packets. 5482 These models may work poorly if a sender ceases packet transmission for 5483 long periods of time. 5485 Session descriptions may use the parameter "guardtime" to set a minimum 5486 sending rate for a media session. The value assigned to guardtime codes 5487 the maximum separation time between two sequential packets, as expressed 5488 in RTP timestamp units. 5490 Typical guardtime values are 500-2000 ms. This value range is not a 5491 normative bound, and parties SHOULD be prepared to process values 5492 outside this range. 5494 The congestion control requirements for sender implementations 5495 (described in Section 8 and [RFC3550]) take precedence over the 5496 guardtime parameter. Thus, if the guardtime parameter requests a 5497 minimum sending rate, but sending at this rate would violate the 5498 congestion control requirements, senders MUST ignore the guardtime 5499 parameter value. In this case, senders SHOULD use the lowest minimum 5500 sending rate that satisfies the congestion control requirements. 5502 Below, we show a session description that uses the guardtime parameter. 5504 v=0 5505 o=lazzaro 2520644554 2838152170 IN IP6 first.example.net 5506 s=Example 5507 t=0 0 5508 m=audio 5004 RTP/AVP 96 5509 c=IN IP6 2001:DB80::7F2E:172A:1E24 5510 a=rtpmap:96 rtp-midi/44100 5511 a=fmtp:96 guardtime=44100; rtp_ptime=0; rtp_maxptime=0 5512 C.5. Configuration Tools: Stream Description 5514 As we discussed in Section 2.1, a party may send several RTP MIDI 5515 streams in the same RTP session, and several RTP sessions that carry 5516 MIDI may appear in a multimedia session. 5518 By default, the MIDI name space (16 channels + systems) of each RTP 5519 stream sent by a party in a multimedia session is independent. By 5520 independent, we mean three distinct things: 5522 o If a party sends two RTP MIDI streams (A and B), MIDI voice 5523 channel 0 in stream A is a different "channel 0" than MIDI 5524 voice channel 0 in stream B. 5526 o MIDI voice channel 0 in stream B is not considered to be 5527 "channel 16" of a 32-channel MIDI voice channel space whose 5528 "channel 0" is channel 0 of stream A. 5530 o Streams sent by different parties over different RTP sessions, 5531 or over the same RTP session but with different payload type 5532 numbers, do not share the association that is shared by a MIDI 5533 cable pair that cross-connects two devices in a MIDI 1.0 DIN 5534 network. By default, this association is only held by streams 5535 sent by different parties in the same RTP session that use the 5536 same payload type number. 5538 In this appendix, we show how to express that specific RTP MIDI streams 5539 in a multimedia session are not independent but instead are related in 5540 one of the three ways defined above. We use two tools to express these 5541 relations: 5543 o The musicport parameter. This parameter is assigned a 5544 non-negative integer value between 0 and 4294967295. It 5545 appears in the fmtp lines of payload types. 5547 o The FID grouping attribute [RFC3388] signals that several RTP 5548 sessions in a multimedia session are using the musicport 5549 parameter to express an inter-session relationship. 5551 If a multimedia session has several payload types whose musicport 5552 parameters are assigned the same integer value, streams using these 5553 payload types share an "identity relationship" (including streams that 5554 use the same payload type). Streams in an identity relationship share 5555 two properties: 5557 o Identity relationship streams sent by the same party 5558 target the same MIDI name space. Thus, if streams A 5559 and B share an identity relationship, voice channel 0 5560 in stream A is the same "channel 0" as voice channel 5561 0 in stream B. 5563 o Pairs of identity relationship streams that are sent by 5564 different parties share the association that is shared 5565 by a MIDI cable pair that cross-connects two devices in 5566 a MIDI 1.0 DIN network. 5568 A party MUST NOT send two RTP MIDI streams that share an identity 5569 relationship in the same RTP session. Instead, each stream MUST be in a 5570 separate RTP session. As explained in Section 2.1, this restriction is 5571 necessary to support the RTP MIDI method for the synchronization of 5572 streams that share a MIDI name space. 5574 If a multimedia session has several payload types whose musicport 5575 parameters are assigned sequential values (i.e., i, i+1, ... i+k), the 5576 streams using the payload types share an "ordered relationship". For 5577 example, if payload type A assigns 2 to musicport and payload type B 5578 assigns 3 to musicport, A and B are in an ordered relationship. 5580 Streams in an ordered relationship that are sent by the same party are 5581 considered by renderers to form a single larger MIDI space. For 5582 example, if stream A has a musicport value of 2 and stream B has a 5583 musicport value of 3, MIDI voice channel 0 in stream B is considered to 5584 be voice channel 16 in the larger MIDI space formed by the relationship. 5585 Note that it is possible for streams to participate in both an identity 5586 relationship and an ordered relationship. 5588 We now state several rules for using musicport: 5590 o If streams from several RTP sessions in a multimedia 5591 session use the musicport parameter, the RTP sessions 5592 MUST be grouped using the FID grouping attribute 5593 defined in [RFC3388]. 5595 o An ordered or identity relationship MUST NOT 5596 contain both native RTP MIDI streams and 5597 mpeg4-generic RTP MIDI streams. An exception applies 5598 if a relationship consists of sendonly and recvonly 5599 (but not sendrecv) streams. In this case, the sendonly 5600 streams MUST NOT contain both types of streams, and the 5601 recvonly streams MUST NOT contain both types of streams. 5603 o It is possible to construct identity relationships 5604 that violate the recovery journal mandate (for example, 5605 sending NoteOns for a voice channel on stream A and 5606 NoteOffs for the same voice channel on stream B). 5607 Parties MUST NOT generate (or accept) session 5608 descriptions that exhibit this flaw. 5610 o Other payload formats MAY define musicport media type 5611 parameters. Formats would define these parameters so that 5612 their sessions could be bundled into RTP MIDI name spaces. 5613 The parameter definitions MUST be compatible with the 5614 musicport semantics defined in this appendix. 5616 As a rule, at most one payload type in a relationship may specify a MIDI 5617 renderer. An exception to the rule applies to relationships that 5618 contain sendonly and recvonly streams but no sendrecv streams. In this 5619 case, one sendonly session and one recvonly session may each define a 5620 renderer. 5622 Renderer specification in a relationship may be done using the tools 5623 described in Appendix C.6. These tools work for both native streams and 5624 mpeg4-generic streams. An mpeg4-generic stream that uses the Appendix 5625 C.6 tools MUST set all "config" parameters to the empty string (""). 5627 Alternatively, for mpeg4-generic streams, renderer specification may be 5628 done by setting one "config" parameter in the relationship to the 5629 renderer configuration string, and all other config parameters to the 5630 empty string (""). 5632 We now define sender and receiver rules that apply when a party sends 5633 several streams that target the same MIDI name space. 5635 Senders MAY use the subsetting parameters (Appendix C.1) to predefine 5636 the partitioning of commands between streams, or they MAY use a dynamic 5637 partitioning strategy. 5639 Receivers that merge identity relationship streams into a single MIDI 5640 command stream MUST maintain the structural integrity of the MIDI 5641 commands coded in each stream during the merging process, in the same 5642 way that software that merges traditional MIDI 1.0 DIN cable flows is 5643 responsible for creating a merged command flow compatible with [MIDI]. 5645 Senders MUST partition the name space so that the rendered MIDI 5646 performance does not contain indefinite artifacts (as defined in Section 5647 4). This responsibility holds even if all streams are sent over 5648 reliable transport, as different stream latencies may yield indefinite 5649 artifacts. For example, stuck notes may occur in a performance split 5650 over two TCP streams, if NoteOn commands are sent on one stream and 5651 NoteOff commands are sent on the other. 5653 Senders MUST NOT split a Registered Parameter Name (RPN) or Non- 5654 Registered Parameter Name (NRPN) transaction appearing on a MIDI channel 5655 across multiple identity relationship sessions. Receivers MUST assume 5656 that the RPN/NRPN transactions that appear on different identity 5657 relationship sessions are independent and MUST preserve transactional 5658 integrity during the MIDI merge. 5660 A simple way to safely partition voice channel commands is to place all 5661 MIDI commands for a particular voice channel into the same session. 5662 Safe partitioning of MIDI Systems commands may be more complicated for 5663 sessions that extensively use System Exclusive. 5665 We now show several session description examples that use the musicport 5666 parameter. 5668 Our first session description example shows two RTP MIDI streams that 5669 drive the same General MIDI decoder. The sender partitions MIDI 5670 commands between the streams dynamically. The musicport values indicate 5671 that the streams share an identity relationship. 5673 v=0 5674 o=lazzaro 2520644554 2838152170 IN IP4 first.example.net 5675 s=Example 5676 t=0 0 5677 a=group:FID 1 2 5678 c=IN IP4 192.0.2.94 5679 m=audio 5004 RTP/AVP 96 5680 a=rtpmap:96 mpeg4-generic/44100 5681 a=mid:1 5682 a=fmtp:96 streamtype=5; mode=rtp-midi; profile-level-id=12; 5683 config=7A0A0000001A4D546864000000060000000100604D54726B0 5684 000000600FF2F000; musicport=12 5685 m=audio 5006 RTP/AVP 96 5686 a=rtpmap:96 mpeg4-generic/44100 5687 a=mid:2 5688 a=fmtp:96 streamtype=5; mode=rtp-midi; config=""; profile-level-id=12; 5689 musicport=12 5691 (The a=fmtp lines have been wrapped to fit the page to accommodate 5692 memo formatting restrictions; they comprise single lines in SDP.) 5694 Recall that Section 2.1 defines rules for streams that target the same 5695 MIDI name space. Those rules, implemented in the example above, require 5696 that each stream resides in a separate RTP session, and that the 5697 grouping mechanisms defined in [RFC3388] signal an inter-session 5698 relationship. The "group" and "mid" attribute lines implement this 5699 grouping mechanism. 5701 A variant on this example, whose session description is not shown, would 5702 use two streams in an identity relationship driving the same MIDI 5703 renderer, each with a different transport type. One stream would use 5704 UDP and would be dedicated to real-time messages. A second stream would 5705 use TCP [RFC4571] and would be used for SysEx bulk data messages. 5707 In the next example, two mpeg4-generic streams form an ordered 5708 relationship to drive a Structured Audio decoder with 32 MIDI voice 5709 channels. Both streams reside in the same RTP session. 5711 v=0 5712 o=lazzaro 2520644554 2838152170 IN IP6 first.example.net 5713 s=Example 5714 t=0 0 5715 m=audio 5006 RTP/AVP 96 97 5716 c=IN IP6 2001:DB80::7F2E:172A:1E24 5717 a=rtpmap:96 mpeg4-generic/44100 5718 a=fmtp:96 streamtype=5; mode=rtp-midi; config=""; profile-level-id=13; 5719 musicport=5 5720 a=rtpmap:97 mpeg4-generic/44100 5721 a=fmtp:97 streamtype=5; mode=rtp-midi; config=""; profile-level-id=13; 5722 musicport=6; render=synthetic; rinit="audio/asc"; 5723 url="http://example.com/cardinal.asc"; 5724 cid="azsldkaslkdjqpwojdkmsldkfpe" 5726 (The a=fmtp lines have been wrapped to fit the page to accommodate 5727 memo formatting restrictions; they comprise single lines in SDP.) 5729 The sequential musicport values for the two sessions establish the 5730 ordered relationship. The musicport=5 session maps to Structured Audio 5731 extended channels range 0-15, the musicport=6 session maps to Structured 5732 Audio extended channels range 16-31. 5734 Both config strings are empty. The configuration data is specified by 5735 parameters that appear in the fmtp line of the second media description. 5736 We define this configuration method in Appendix C.6. 5738 The next example shows two RTP MIDI streams (one recvonly, one sendonly) 5739 that form a "virtual sendrecv" session. Each stream resides in a 5740 different RTP session (a requirement because sendonly and recvonly are 5741 RTP session attributes). 5743 v=0 5744 o=lazzaro 2520644554 2838152170 IN IP4 first.example.net 5745 s=Example 5746 t=0 0 5747 a=group:FID 1 2 5748 c=IN IP4 192.0.2.94 5749 m=audio 5004 RTP/AVP 96 5750 a=sendonly 5751 a=rtpmap:96 mpeg4-generic/44100 5752 a=mid:1 5753 a=fmtp:96 streamtype=5; mode=rtp-midi; profile-level-id=12; 5754 config=7A0A0000001A4D546864000000060000000100604D54726B0 5755 000000600FF2F000; musicport=12 5756 m=audio 5006 RTP/AVP 96 5757 a=recvonly 5758 a=rtpmap:96 mpeg4-generic/44100 5759 a=mid:2 5760 a=fmtp:96 streamtype=5; mode=rtp-midi; profile-level-id=12; 5761 config=7A0A0000001A4D546864000000060000000100604D54726B0 5762 000000600FF2F000; musicport=12 5764 (The a=fmtp lines have been wrapped to fit the page to accommodate 5765 memo formatting restrictions; they comprise single lines in SDP.) 5767 To signal the "virtual sendrecv" semantics, the two streams assign 5768 musicport to the same value (12). As defined earlier in this section, 5769 pairs of identity relationship streams that are sent by different 5770 parties share the association that is shared by a MIDI cable pair that 5771 cross-connects two devices in a MIDI 1.0 network. We use the term 5772 "virtual sendrecv" because streams sent by different parties in a true 5773 sendrecv session also have this property. 5775 As discussed in the preamble to Appendix C, the primary advantage of the 5776 virtual sendrecv configuration is that each party can customize the 5777 property of the stream it receives. In the example above, each stream 5778 defines its own "config" string that could customize the rendering 5779 algorithm for each party (in fact, the particular strings shown in this 5780 example are identical, because General MIDI is not a configurable MPEG 4 5781 renderer). 5783 C.6. Configuration Tools: MIDI Rendering 5785 This appendix defines the session configuration tools for rendering. 5787 The "render" parameter specifies a rendering method for a stream. The 5788 parameter is assigned a token value that signals the top-level rendering 5789 class. This memo defines four token values for render: "unknown", 5790 "synthetic", "api", and "null": 5792 o An "unknown" renderer is a renderer whose nature is unspecified. 5793 It is the default renderer for native RTP MIDI streams. 5795 o A "synthetic" renderer transforms the MIDI stream into audio 5796 output (or sometimes into stage lighting changes or other 5797 actions). It is the default renderer for mpeg4-generic 5798 RTP MIDI streams. 5800 o An "api" renderer presents the command stream to applications 5801 via an Application Programmer Interface (API). 5803 o The "null" renderer discards the MIDI stream. 5805 The "null" render value plays special roles during Offer/Answer 5806 negotiations [RFC3264]. A party uses the "null" value in an answer to 5807 reject an offered renderer. Note that rejecting a renderer is 5808 independent from rejecting a payload type (coded by removing the payload 5809 type from a media line) and rejecting a media stream (coded by zeroing 5810 the port of a media line that uses the renderer). 5812 Other render token values MAY be registered with IANA. The token value 5813 MUST adhere to the ABNF for render tokens defined in Appendix D. 5814 Registrations MUST include a complete specification of parameter value 5815 usage, similar in depth to the specifications that appear throughout 5816 Appendix C.6 for "synthetic" and "api" render values. If a party is 5817 offered a session description that uses a render token value that is not 5818 known to the party, the party MUST NOT accept the renderer. Options 5819 include rejecting the renderer (using the "null" value), the payload 5820 type, the media stream, or the session description. 5822 Other parameters MAY follow a render parameter in a parameter list. The 5823 additional parameters act to define the exact nature of the renderer. 5824 For example, the "subrender" parameter (defined in Appendix C.6.2) 5825 specifies the exact nature of the renderer. 5827 Special rules apply to using the render parameter in an mpeg4-generic 5828 stream. We define these rules in Appendix C.6.5. 5830 C.6.1. The multimode Parameter 5832 A media description MAY contain several render parameters. By default, 5833 if a parameter list includes several render parameters, a receiver MUST 5834 choose exactly one renderer from the list to render the stream. The 5835 "multimode" parameter may be used to override this default. We define 5836 two token values for multimode: "one" and "all": 5838 o The default "one" value requests rendering by exactly one of 5839 the listed renderers. 5841 o The "all" value requests the synchronized rendering of the RTP 5842 MIDI stream by all listed renderers, if possible. 5844 If the multimode parameter appears in a parameter list, it MUST appear 5845 before the first render parameter assignment. 5847 Render parameters appear in the parameter list in order of decreasing 5848 priority. A receiver MAY use the priority ordering to decide which 5849 renderer(s) to retain in a session. 5851 If the "offer" in an Offer/Answer-style negotiation [RFC3264] contains a 5852 parameter list with one or more render parameters, the "answer" MUST set 5853 the render parameters of all unchosen renderers to "null". 5855 C.6.2. Renderer Specification 5857 The render parameter (Appendix C.6 preamble) specifies, in a broad 5858 sense, what a renderer does with a MIDI stream. In this appendix, we 5859 describe the "subrender" parameter. The token value assigned to 5860 subrender defines the exact nature of the renderer. Thus, "render" and 5861 "subrender" combine to define a renderer, in the same way as MIME types 5862 and MIME subtypes combine to define a type of media [RFC2045]. 5864 If the subrender parameter is used for a renderer definition, it MUST 5865 appear immediately after the render parameter in the parameter list. At 5866 most one subrender parameter may appear in a renderer definition. 5868 This document defines one value for subrender: the value "default". The 5869 "default" token specifies the use of the default renderer for the stream 5870 type (native or mpeg4-generic). The default renderer for native RTP 5871 MIDI streams is a renderer whose nature is unspecified (see point 6 in 5872 Section 6.1 for details). The default renderer for mpeg4-generic RTP 5873 MIDI streams is an MPEG 4 Audio Object Type whose ID number is 13, 14, 5874 or 15 (see Section 6.2 for details). 5876 If a renderer definition does not use the subrender parameter, the value 5877 "default" is assumed for subrender. 5879 Other subrender token values may be registered with IANA. We now 5880 discuss guidelines for registering subrender values. 5882 A subrender value is registered for a specific stream type (native or 5883 mpeg4-generic) and a specific render value (excluding "null" and 5884 "unknown"). Registrations for mpeg4-generic subrender values are 5885 restricted to new MPEG 4 Audio Object Types that accept MIDI input. The 5886 syntax of the token MUST adhere to the token definition in Appendix D. 5888 For "render=synthetic" renderers, a subrender value registration 5889 specifies an exact method for transforming the MIDI stream into audio 5890 (or sometimes into video or control actions, such as stage lighting). 5891 For standardized renderers, this specification is usually a pointer to a 5892 standards document, perhaps supplemented by RTP-MIDI-specific 5893 information. For commercial products and open-source projects, this 5894 specification usually takes the form of instructions for interfacing the 5895 RTP MIDI stream with the product or project software. A 5896 "render=synthetic" registration MAY specify additional Reset State 5897 commands for the renderer (Appendix A.1). 5899 A "render=api" subrender value registration specifies how an RTP MIDI 5900 stream interfaces with an API (Application Programmers Interface). This 5901 specification is usually a pointer to programmer's documentation for the 5902 API, perhaps supplemented by RTP-MIDI-specific information. 5904 A subrender registration MAY specify an initialization file (referred to 5905 in this document as an initialization data object) for the stream. The 5906 initialization data object MAY be encoded in the parameter list 5907 (verbatim or by reference) using the coding tools defined in Appendix 5908 C.6.3. An initialization data object MUST have a registered [RFC4288] 5909 media type and subtype [RFC2045]. 5911 For "render=synthetic" renderers, the data object usually encodes 5912 initialization data for the renderer (sample files, synthesis patch 5913 parameters, reverberation room impulse responses, etc.). 5915 For "render=api" renderers, the data object usually encodes data about 5916 the stream used by the API (for example, for an RTP MIDI stream 5917 generated by a piano keyboard controller, the manufacturer and model 5918 number of the keyboard, for use in GUI presentation). 5920 Usually, only one initialization object is encoded for a renderer. If a 5921 renderer uses multiple data objects, the correct receiver interpretation 5922 of multiple data objects MUST be defined in the subrender registration. 5924 A subrender value registration may also specify additional parameters, 5925 to appear in the parameter list immediately after subrender. These 5926 parameter names MUST begin with the subrender value, followed by an 5927 underscore ("_"), to avoid name space collisions with future RTP MIDI 5928 parameter names (for example, a parameter "foo_bar" defined for 5929 subrender value "foo"). 5931 We now specify guidelines for interpreting the subrender parameter 5932 during session configuration. 5934 If a party is offered a session description that uses a renderer whose 5935 subrender value is not known to the party, the party MUST NOT accept the 5936 renderer. Options include rejecting the renderer (using the "null" 5937 value), the payload type, the media stream, or the session description. 5939 Receivers MUST be aware of the Reset State commands (Appendix A.1) for 5940 the renderer specified by the subrender parameter and MUST insure that 5941 the renderer does not experience indefinite artifacts due to the 5942 presence (or the loss) of a Reset State command. 5944 C.6.3. Renderer Initialization 5946 If the renderer for a stream uses an initialization data object, an 5947 "rinit" parameter MUST appear in the parameter list immediately after 5948 the "subrender" parameter. If the renderer parameter list does not 5949 include a subrender parameter (recall the semantics for "default" in 5950 Appendix C.6.2), the "rinit" parameter MUST appear immediately after the 5951 "render" parameter. 5953 The value assigned to the rinit parameter MUST be the media type/subtype 5954 [RFC2045] for the initialization data object. If an initialization 5955 object type is registered with several media types, including audio, the 5956 assignment to rinit MUST use the audio media type. 5958 RTP MIDI supports several parameters for encoding initialization data 5959 objects for renderers in the parameter list: "inline", "url", and "cid". 5961 If the "inline", "url", and/or "cid" parameters are used by a renderer, 5962 these parameters MUST immediately follow the "rinit" parameter. 5964 If a "url" parameter appears for a renderer, an "inline" parameter MUST 5965 NOT appear. If an "inline" parameter appears for a renderer, a "url" 5966 parameter MUST NOT appear. However, neither "url" or "inline" is 5967 required to appear. If neither "url" or "inline" parameters follow 5968 "rinit", the "cid" parameter MUST follow "rinit". 5970 The "inline" parameter supports the inline encoding of the data object. 5971 The parameter is assigned a double-quoted Base64 [RFC2045] encoding of 5972 the binary data object, with no line breaks. Appendix E.4 shows an 5973 example that constructs an inline parameter value. 5975 The "url" parameter is assigned a double-quoted string representation of 5976 a Uniform Resource Locator (URL) for the data object. The string MUST 5977 specify either a HyperText Transport Protocol URI (HTTP, [RFC2616]) or 5978 an HTTP over TLS URI (HTTPS, [RFC2818]). The media type/subtype for the 5979 data object SHOULD be specified in the appropriate HTTP or HTTPS 5980 transport header. 5982 The "url" parameter is assigned a double-quoted string representation of 5983 a Uniform Resource Locator (URL) for the data object. The string MUST 5984 specify a HyperText Transport Protocol URL (HTTP, [RFC2616]). HTTP MAY 5985 be used over TCP or MAY be used over a secure network transport, such as 5986 the method described in [RFC2818]. The media type/subtype for the data 5987 object SHOULD be specified in the appropriate HTTP transport header. 5989 The "cid" parameter supports data object caching. The parameter is 5990 assigned a double-quoted string value that encodes a globally unique 5991 identifier for the data object. 5993 A cid parameter MAY immediately follow an inline parameter, in which 5994 case the cid identifier value MUST be associated with the inline data 5995 object. 5997 If a url parameter is present, and if the data object for the URL is 5998 expected to be unchanged for the life of the URL, a cid parameter MAY 5999 immediately follow the url parameter. The cid identifier value MUST be 6000 associated with the data object for the URL. A cid parameter assigned 6001 to the same identifier value SHOULD be specified following the data 6002 object type/subtype in the appropriate HTTP transport header. 6004 If a url parameter is present, and if the data object for the URL is 6005 expected to change during the life of the URL, a cid parameter MUST NOT 6006 follow the url parameter. A receiver interprets the presence of a cid 6007 parameter as an indication that it is safe to use a cached copy of the 6008 url data object; the absence of a cid parameter is an indication that it 6009 is not safe to use a cached copy, as it may change. 6011 Finally, the cid parameter MAY be used without the inline and url 6012 parameters. In this case, the identifier references a local or 6013 distributed catalog of data objects. 6015 In most cases, only one data object is coded in the parameter list for 6016 each renderer. For example, the default renderer for mpeg4-generic 6017 streams uses a single data object (see Appendix C.6.5 for example 6018 usage). 6020 However, a subrender registration MAY permit the use of multiple data 6021 objects for a renderer. If multiple data objects are encoded for a 6022 renderer, each object encoding begins with an "rinit" parameter, 6023 followed by "inline", "url", and/or "cid" parameters. 6025 Initialization data objects MAY encapsulate a Standard MIDI File (SMF). 6026 By default, the SMFs that are encapsulated in a data object MUST be 6027 ignored by an RTP MIDI receiver. We define parameters to override this 6028 default in Appendix C.6.4. 6030 To end this section, we offer guidelines for registering media types for 6031 initialization data objects. These guidelines are in addition to the 6032 information in [RFC4288]. 6034 Some initialization data objects are also capable of encoding MIDI note 6035 information and thus complete audio performances. These objects SHOULD 6036 be registered using the "audio" media type, so that the objects may also 6037 be used for store-and-forward rendering, and "application" media type, 6038 to support editing tools. Initialization objects without note storage, 6039 or initialization objects for non-audio renderers, SHOULD be registered 6040 only for an "application" media type. 6042 C.6.4. MIDI Channel Mapping 6044 In this appendix, we specify how to map MIDI name spaces (16 voice 6045 channels + systems) onto a renderer. 6047 In the general case: 6049 o A session may define an ordered relationship (Appendix C.5) 6050 that presents more than one MIDI name space to a renderer. 6052 o A renderer may accept an arbitrary number of MIDI name spaces, 6053 or it may expect a specific number of MIDI name spaces. 6055 A session description SHOULD provide a compatible MIDI name space to 6056 each renderer in the session. If a receiver detects that a session 6057 description has too many or too few MIDI name spaces for a renderer, 6058 MIDI data from extra stream name spaces MUST be discarded, and extra 6059 renderer name spaces MUST NOT be driven with MIDI data (except as 6060 described in Appendix C.6.4.1, below). 6062 If a parameter list defines several renderers and assigns the "all" 6063 token value to the multimode parameter, the same name space is presented 6064 to each renderer. However, the "chanmask" parameter may be used to mask 6065 out selected voice channels to each renderer. We define "chanmask" and 6066 other MIDI management parameters in the sub-sections below. 6068 C.6.4.1. The smf_info Parameter 6070 The smf_info parameter defines the use of the SMFs encapsulated in 6071 renderer data objects (if any). The smf_info parameter also defines the 6072 use of SMFs coded in the smf_inline, smf_url, and smf_cid parameters 6073 (defined in Appendix C.6.4.2). 6075 The smf_info parameter describes the "render" parameter that most 6076 recently precedes it in the parameter list. The smf_info parameter MUST 6077 NOT appear in parameter lists that do not use the "render" parameter, 6078 and MUST NOT appear before the first use of "render" in the parameter 6079 list. 6081 We define three token values for smf_info: "ignore", "sdp_start", and 6082 "identity": 6084 o The "ignore" value indicates that the SMFs MUST be discarded. 6085 This behavior is the default SMF rendering behavior. 6087 o The "sdp_start" value codes that SMFs MUST be rendered, 6088 and that the rendering MUST begin upon the acceptance of 6089 the session description. If a receiver is offered a session 6090 description with a renderer that uses an smf_info parameter 6091 set to sdp_start, and if the receiver does not support 6092 rendering SMFs, the receiver MUST NOT accept the renderer 6093 associated with the smf_info parameter. Options include 6094 rejecting the renderer (by setting the "render" parameter 6095 to "null"), the payload type, the media stream, or the 6096 entire session description. 6098 o The "identity" value indicates that the SMFs code the identity 6099 of the renderer. The value is meant for use with the 6100 "unknown" renderer (see Appendix C.6 preamble). The MIDI commands 6101 coded in the SMF are informational in nature and MUST NOT be 6102 presented to a renderer for audio presentation. In 6103 typical use, the SMF would use SysEx Identity Reply 6104 commands (F0 7E nn 06 02, as defined in [MIDI]) to identify 6105 devices, and use device-specific SysEx commands to describe 6106 current state of the devices (patch memory contents, etc.). 6108 Other smf_info token values MAY be registered with IANA. The token 6109 value MUST adhere to the ABNF for render tokens defined in Appendix D. 6110 Registrations MUST include a complete specification of parameter usage, 6111 similar in depth to the specifications that appear in this appendix for 6112 "sdp_start" and "identity". 6114 If a party is offered a session description that uses an smf_info 6115 parameter value that is not known to the party, the party MUST NOT 6116 accept the renderer associated with the smf_info parameter. Options 6117 include rejecting the renderer, the payload type, the media stream, or 6118 the entire session description. 6120 We now define the rendering semantics for the "sdp_start" token value in 6121 detail. 6123 The SMFs and RTP MIDI streams in a session description share the same 6124 MIDI name space(s). In the simple case of a single RTP MIDI stream and 6125 a single SMF, the SMF MIDI commands and RTP MIDI commands are merged 6126 into a single name space and presented to the renderer. The indefinite 6127 artifact responsibilities for merged MIDI streams defined in Appendix 6128 C.5 also apply to merging RTP and SMF MIDI data. 6130 If a payload type codes multiple SMFs, the SMF name spaces are presented 6131 as an ordered entity to the renderer. To determine the ordering of SMFs 6132 for a renderer (which SMF is "first", which is "second", etc.), use the 6133 following rules: 6135 o If the renderer uses a single data object, the order of 6136 appearance of the SMFs in the object's internal structure 6137 defines the order of the SMFs (the earliest SMF in the object 6138 is "first", the next SMF in the object is "second", etc.). 6140 o If multiple data objects are encoded for a renderer, the 6141 appearance of each data object in the parameter list 6142 sets the relative order of the SMFs encoded in each 6143 data object (SMFs encoded in parameters that appear 6144 earlier in the list are ordered before SMFs encoded 6145 in parameters that appear later in the list). 6147 o If SMFs are encoded in data objects parameters and in 6148 the parameters defined in C.6.4.2, the relative order 6149 of the data object parameters and C.6.4.2 parameters 6150 in the parameter list sets the relative order of SMFs 6151 (SMFs encoded in parameters that appear earlier in the 6152 list are ordered before SMFs in parameters that appear 6153 later in the list). 6155 Given this ordering of SMFs, we now define the mapping of SMFs to 6156 renderer name spaces. The SMF that appears first for a renderer maps to 6157 the first renderer name space. The SMF that appears second for a 6158 renderer maps to the second renderer name space, etc. If the associated 6159 RTP MIDI streams also form an ordered relationship, the first SMF is 6160 merged with the first name space of the relationship, the second SMF is 6161 merged to the second name space of the relationship, etc. 6163 Unless the streams and the SMFs both use MIDI Time Code, the time offset 6164 between SMF and stream data is unspecified. This restriction limits the 6165 use of SMFs to applications where synchronization is not critical, such 6166 as the transport of System Exclusive commands for renderer 6167 initialization, or human-SMF interactivity. 6169 Finally, we note that each SMF in the sdp_start discussion above encodes 6170 exactly one MIDI name space (16 voice channels + systems). Thus, the 6171 use of the Device Name SMF meta event to specify several MIDI name 6172 spaces in an SMF is not supported for sdp_start. 6174 C.6.4.2. The smf_inline, smf_url, and smf_cid Parameters 6176 In some applications, the renderer data object may not encapsulate SMFs, 6177 but an application may wish to use SMFs in the manner defined in 6178 Appendix C.6.4.1. 6180 The "smf_inline", "smf_url", and "smf_cid" parameters address this 6181 situation. These parameters use the syntax and semantics of the inline, 6182 url, and cid parameters defined in Appendix C.6.3, except that the 6183 encoded data object is an SMF. 6185 The "smf_inline", "smf_url", and "smf_cid" parameters belong to the 6186 "render" parameter that most recently precedes it in the session 6187 description. The "smf_inline", "smf_url", and "smf_cid" parameters MUST 6188 NOT appear in parameter lists that do not use the "render" parameter and 6189 MUST NOT appear before the first use of "render" in the parameter list. 6190 If several "smf_inline", "smf_url", or "smf_cid" parameters appear for a 6191 renderer, the order of the parameters defines the SMF name space 6192 ordering. 6194 C.6.4.3. The chanmask Parameter 6196 The chanmask parameter instructs the renderer to ignore all MIDI voice 6197 commands for certain channel numbers. The parameter value is a 6198 concatenated string of "1" and "0" digits. Each string position maps to 6199 a MIDI voice channel number (system channels may not be masked). A "1" 6200 instructs the renderer to process the voice channel; a "0" instructs the 6201 renderer to ignore the voice channel. 6203 The string length of the chanmask parameter value MUST be 16 (for a 6204 single stream or an identity relationship) or a multiple of 16 (for an 6205 ordered relationship). 6207 The chanmask parameter describes the "render" parameter that most 6208 recently precedes it in the session description; chanmask MUST NOT 6209 appear in parameter lists that do not use the "render" parameter and 6210 MUST NOT appear before the first use of "render" in the parameter list. 6212 The chanmask parameter describes the final MIDI name spaces presented to 6213 the renderer. The SMF and stream components of the MIDI name spaces may 6214 not be independently masked. 6216 If a receiver is offered a session description with a renderer that uses 6217 the chanmask parameter, and if the receiver does not implement the 6218 semantics of the chanmask parameter, the receiver MUST NOT accept the 6219 renderer unless the chanmask parameter value contains only "1"s. 6221 C.6.5. The audio/asc Media Type 6223 In Appendix 11.3, we register the audio/asc media type. The data object 6224 for audio/asc is a binary encoding of the AudioSpecificConfig data block 6225 used to initialize mpeg4-generic streams (Section 6.2 and [MPEGAUDIO]). 6227 An mpeg4-generic parameter list MAY use the render, subrender, and rinit 6228 parameters with the audio/asc media type for renderer configuration. 6229 Several restrictions apply to the use of these parameters in 6230 mpeg4-generic parameter lists: 6232 o An mpeg4-generic media description that uses the render parameter 6233 MUST assign the empty string ("") to the mpeg4-generic "config" 6234 parameter. The use of the streamtype, mode, and profile-level-id 6235 parameters MUST follow the normative text in Section 6.2. 6237 o Sessions that use identity or ordered relationships MUST follow 6238 the mpeg4-generic configuration restrictions in Appendix C.5. 6240 o The render parameter MUST be assigned the value "synthetic", 6241 "unknown", "null", or a render value that has been added to 6242 the IANA repository for use with mpeg4-generic RTP MIDI 6243 streams. The "api" token value for render MUST NOT be used. 6245 o If a subrender parameter is present, it MUST immediately follow 6246 the render parameter, and it MUST be assigned the token value 6247 "default" or assigned a subrender value added to the IANA 6248 repository for use with mpeg4-generic RTP MIDI streams. A 6249 subrender parameter assignment may be left out of the renderer 6250 configuration, in which case the implied value of subrender 6251 is the default value of "default". 6253 o If the render parameter is assigned the value "synthetic" 6254 and the subrender parameter has the value "default" (assigned 6255 or implied), the rinit parameter MUST be assigned the value 6256 "audio/asc", and an AudioSpecificConfig data object MUST be encoded 6257 using the mechanisms defined in C.6.2-3. The AudioSpecificConfig 6258 data MUST encode one of the MPEG 4 Audio Object Types defined for 6259 use with mpeg4-generic in Section 6.2. If the subrender value is 6260 other than "default", refer to the subrender registration 6261 for information on the use of "audio/asc" with the renderer. 6263 o If the render parameter is assigned the value "null" or 6264 "unknown", the data object MAY be omitted. 6266 Several general restrictions apply to the use of the audio/asc media 6267 type in RTP MIDI: 6269 o A native stream MUST NOT assign "audio/asc" to rinit. The 6270 audio/asc media type is not intended to be a general-purpose 6271 container for rendering systems outside of MPEG usage. 6273 o The audio/asc media type defines a stored object type; it does 6274 not define semantics for RTP streams. Thus, audio/asc MUST NOT 6275 appear on an rtpmap line of a session description. 6277 Below, we show session description examples for audio/asc. The session 6278 description below uses the inline parameter to code the 6279 AudioSpecificConfig block for a mpeg4-generic General MIDI stream. We 6280 derive the value assigned to the inline parameter in Appendix E.4. The 6281 subrender token value of "default" is implied by the absence of the 6282 subrender parameter in the parameter list. 6284 v=0 6285 o=lazzaro 2520644554 2838152170 IN IP4 first.example.net 6286 s=Example 6287 t=0 0 6288 m=audio 5004 RTP/AVP 96 6289 c=IN IP4 192.0.2.94 6290 a=rtpmap:96 mpeg4-generic/44100 6291 a=fmtp:96 streamtype=5; mode=rtp-midi; config=""; profile-level-id=12; 6292 render=synthetic; rinit="audio/asc"; 6293 inline="egoAAAAaTVRoZAAAAAYAAAABAGBNVHJrAAAABgD/LwAA" 6295 (The a=fmtp line has been wrapped to fit the page to accommodate 6296 memo formatting restrictions; it comprises a single line in SDP.) 6298 The session description below uses the url parameter to code the 6299 AudioSpecificConfig block for the same General MIDI stream: 6301 v=0 6302 o=lazzaro 2520644554 2838152170 IN IP4 first.example.net 6303 s=Example 6304 t=0 0 6305 m=audio 5004 RTP/AVP 96 6306 c=IN IP4 192.0.2.94 6307 a=rtpmap:96 mpeg4-generic/44100 6308 a=fmtp:96 streamtype=5; mode=rtp-midi; config=""; profile-level-id=12; 6309 render=synthetic; rinit="audio/asc"; url="http://example.net/oski.asc"; 6310 cid="xjflsoeiurvpa09itnvlduihgnvet98pa3w9utnuighbuk" 6312 (The a=fmtp line has been wrapped to fit the page to accommodate 6313 memo formatting restrictions; it comprises a single line in SDP.) 6315 C.7. Interoperability 6317 In this appendix, we define interoperability guidelines for two 6318 application areas: 6320 o MIDI content-streaming applications. RTP MIDI is added to 6321 RTSP-based content-streaming servers, so that viewers may 6322 experience MIDI performances (produced by a specified client- 6323 side renderer) in synchronization with other streams (video, 6324 audio). 6326 o Long-distance network musical performance applications. RTP 6327 MIDI is added to SIP-based voice chat or videoconferencing 6328 programs, as an alternative, or as an addition, to audio and/or 6329 video RTP streams. 6331 For each application, we define a core set of functionality that all 6332 implementations MUST implement. 6334 The applications we address in this section are not an exhaustive list 6335 of potential RTP MIDI uses. We expect framework documents for other 6336 applications to be developed, within the IETF or within other 6337 organizations. We discuss other potential application areas for RTP 6338 MIDI in Section 1 of the main text of this memo. 6340 C.7.1. MIDI Content Streaming Applications 6342 In content-streaming applications, a user invokes an RTSP client to 6343 initiate a request to an RTSP server to view a multimedia session. For 6344 example, clicking on a web page link for an Internet Radio channel 6345 launches an RTSP client that uses the link's RTSP URL to contact the 6346 RTSP server hosting the radio channel. 6348 The content may be pre-recorded (for example, on-demand replay of 6349 yesterday's football game) or "live" (for example, football game 6350 coverage as it occurs), but in either case the user is usually an 6351 "audience member" as opposed to a "participant" (as the user would be in 6352 telephony). 6354 Note that these examples describe the distribution of audio content to 6355 an audience member. The interoperability guidelines in this appendix 6356 address RTP MIDI applications of this nature, not applications such as 6357 the transmission of raw MIDI command streams for use in a professional 6358 environment (recording studio, performance stage, etc.). 6360 In an RTSP session, a client accesses a session description that is 6361 "declared" by the server, either via the RTSP DESCRIBE method, or via 6362 other means, such as HTTP or email. The session description defines the 6363 session from the perspective of the client. For example, if a media 6364 line in the session description contains a non-zero port number, it 6365 encodes the server's preference for the client's port numbers for RTP 6366 and RTCP reception. Once media flow begins, the server sends an RTP 6367 MIDI stream to the client, which renders it for presentation, perhaps in 6368 synchrony with video or other audio streams. 6370 We now define the interoperability text for content-streaming RTSP 6371 applications. 6373 In most cases, server interoperability responsibilities are described in 6374 terms of limits on the "reference" session description a server provides 6375 for a performance if it has no information about the capabilities of the 6376 client. The reference session is a "lowest common denominator" session 6377 that maximizes the odds that a client will be able to view the session. 6378 If a server is aware of the capabilities of the client, the server is 6379 free to provide a session description customized for the client in the 6380 DESCRIBE reply. 6382 Clients MUST support unicast UDP RTP MIDI streams that use the recovery 6383 journal with the closed-loop or the anchor sending policies. Clients 6384 MUST be able to interpret stream subsetting and chapter inclusion 6385 parameters in the session description that qualify the sending policies. 6386 Client support of enhanced Chapter C encoding is OPTIONAL. 6388 The reference session description offered by a server MUST send all RTP 6389 MIDI UDP streams as unicast streams that use the recovery journal and 6390 the closed-loop or anchor sending policies. Servers SHOULD use the 6391 stream subsetting and chapter inclusion parameters in the reference 6392 session description, to simplify the rendering task of the client. 6393 Server support of enhanced Chapter C encoding is OPTIONAL. 6395 Clients and servers MUST support the use of RTSP interleaved mode (a 6396 method for interleaving RTP onto the RTSP TCP transport). 6398 Clients MUST be able to interpret the timestamp semantics signalled by 6399 the "comex" value of the tsmode parameter (i.e., the timestamp semantics 6400 of Standard MIDI Files [MIDI]). Servers MUST use the "comex" value for 6401 the "tsmode" parameter in the reference session description. 6403 Clients MUST be able to process an RTP MIDI stream whose packets encode 6404 an arbitrary temporal duration ("media time"). Thus, in practice, 6405 clients MUST implement a MIDI playout buffer. Clients MUST NOT depend 6406 on the presence of rtp_ptime, rtp_maxtime, and guardtime parameters in 6407 the session description in order to process packets, but they SHOULD be 6408 able to use these parameters to improve packet processing. 6410 Servers SHOULD strive to send RTP MIDI streams in the same way media 6411 servers send conventional audio streams: a sequence of packets that 6412 either all code the same temporal duration (non-normative example: 50 ms 6413 packets) or that code one of an integral number of temporal durations 6414 (non-normative example: 50 ms, 100 ms, 250 ms, or 500 ms packets). 6415 Servers SHOULD encode information about the packetization method in the 6416 rtp_ptime and rtp_maxtime parameters in the session description. 6418 Clients MUST be able to examine the render and subrender parameter, to 6419 determine if a multimedia session uses a renderer it supports. Clients 6420 MUST be able to interpret the default "one" value of the "multimode" 6421 parameter, to identify supported renderers from a list of renderer 6422 descriptions. Clients MUST be able to interpret the musicport 6423 parameter, to the degree that it is relevant to the renderers it 6424 supports. Clients MUST be able to interpret the chanmask parameter. 6426 Clients supporting renderers whose data object (as encoded by a 6427 parameter value for "inline") could exceed 300 octets in size MUST 6428 support the url and cid parameters and thus must implement the HTTP 6429 protocol in addition to RTSP. HTTP over TLS [RFC2818] support for data 6430 objects is OPTIONAL. 6432 Servers MUST specify complete rendering systems for RTP MIDI streams. 6433 Note that a minimal RTP MIDI native stream does not meet this 6434 requirement (Section 6.1), as the rendering method for such streams is 6435 "not specified". 6437 At the time of this memo, the only way for servers to specify a complete 6438 rendering system is to specify an mpeg4-generic RTP MIDI stream in mode 6439 rtp-midi (Section 6.2 and C.6.5). As a consequence, the only rendering 6440 systems that may be presently used are General MIDI [MIDI], DLS 2 6441 [DLS2], or Structured Audio [MPEGSA]. Note that the maximum inline 6442 value for General MIDI is well under 300 octets (and thus clients need 6443 not support the "url" parameter), and that the maximum inline values for 6444 DLS 2 and Structured Audio may be much larger than 300 octets (and thus 6445 clients MUST support the url parameter). 6447 We anticipate that the owners of rendering systems (both standardized 6448 and proprietary) will register subrender parameters for their renderers. 6449 Once registration occurs, native RTP MIDI sessions may use render and 6450 subrender (Appendix C.6.2) to specify complete rendering systems for 6451 RTSP content-streaming multimedia sessions. 6453 Servers MUST NOT use the sdp_start value for the smf_info parameter in 6454 the reference session description, as this use would require that 6455 clients be able to parse and render Standard MIDI Files. 6457 Clients MUST support mpeg4-generic mode rtp-midi General MIDI (GM) 6458 sessions, at a polyphony limited by the hardware capabilities of the 6459 client. This requirement provides a "lowest common denominator" 6460 rendering system for content providers to target. Note that this 6461 requirement does not force implementors of a non-GM renderer (such as 6462 DLS 2 or Structured Audio) to add a second rendering engine. Instead, a 6463 client may satisfy the requirement by including a set of voice patches 6464 that implement the GM instrument set, and using this emulation for 6465 mpeg4-generic GM sessions. 6467 It is RECOMMENDED that servers use General MIDI as the renderer for the 6468 reference session description, because clients are REQUIRED to support 6469 it. We do not require General MIDI as the reference renderer, because 6470 for normative applications it is an inappropriate choice. Servers using 6471 General MIDI as a "lowest common denominator" renderer SHOULD use 6472 Universal Real-Time SysEx MIP messages [SPMIDI] to communicate the 6473 priority of voices to polyphony-limited clients. 6475 C.7.2. MIDI Network Musical Performance Applications 6477 In Internet telephony and videoconferencing applications, parties 6478 interact over an IP network as they would face-to-face. Good user 6479 experiences require low end-to-end audio latency and tight audiovisual 6480 synchronization (for "lip-sync"). The Session Initiation Protocol (SIP, 6481 [RFC3261]) is used for session management. 6483 In this appendix section, we define interoperability guidelines for 6484 using RTP MIDI streams in interactive SIP applications. Our primary 6485 interest is supporting Network Musical Performances (NMP), where 6486 musicians in different locations interact over the network as if they 6487 were in the same room. See [NMP] for background information on NMP, and 6488 see [RFC4696] for a discussion of low-latency RTP MIDI implementation 6489 techniques for NMP. 6491 Note that the goal of NMP applications is telepresence: the parties 6492 should hear audio that is close to what they would hear if they were in 6493 the same room. The interoperability guidelines in this appendix address 6494 RTP MIDI applications of this nature, not applications such as the 6495 transmission of raw MIDI command streams for use in a professional 6496 environment (recording studio, performance stage, etc.). 6498 We focus on session management for two-party unicast sessions that 6499 specify a renderer for RTP MIDI streams. Within this limited scope, the 6500 guidelines defined here are sufficient to let applications interoperate. 6501 We define the REQUIRED capabilities of RTP MIDI senders and receivers in 6502 NMP sessions and define how session descriptions exchanged are used to 6503 set up network musical performance sessions. 6505 SIP lets parties negotiate details of the session, using the 6506 Offer/Answer protocol [RFC3264]. However, RTP MIDI has so many 6507 parameters that "blind" negotiations between two parties using different 6508 applications might not yield a common session configuration. 6510 Thus, we now define a set of capabilities that NMP parties MUST support. 6511 Session description offers whose options lie outside the envelope of 6512 REQUIRED party behavior risk negotiation failure. We also define 6513 session description idioms that the RTP MIDI part of an offer MUST 6514 follow, in order to structure the offer for simpler analysis. 6516 We use the term "offerer" for the party making a SIP offer, and 6517 "answerer" for the party answering the offer. Finally, we note that 6518 unless it is qualified by the adjective "sender" or "receiver", a 6519 statement that a party MUST support X implies that it MUST support X for 6520 both sending and receiving. 6522 If an offerer wishes to define a "sendrecv" RTP MIDI stream, it may use 6523 a true sendrecv session or the "virtual sendrecv" construction described 6524 in the preamble to Appendix C and in Appendix C.5. A true sendrecv 6525 session indicates that the offerer wishes to participate in a session 6526 where both parties use identically configured renderers. A virtual 6527 sendrecv session indicates that the offerer is willing to participate in 6528 a session where the two parties may be using different renderer 6529 configurations. Thus, parties MUST be prepared to see both real and 6530 virtual sendrecv sessions in an offer. 6532 Parties MUST support unicast UDP transport of RTP MIDI streams. These 6533 streams MUST use the recovery journal with the closed-loop or anchor 6534 sending policies. These streams MUST use the stream subsetting and 6535 chapter inclusion parameters to declare the types of MIDI commands that 6536 will be sent on the stream (for sendonly streams) or will be processed 6537 (for recvonly streams), including the size limits on System Exclusive 6538 commands. Support of enhanced Chapter C encoding is OPTIONAL. 6540 Note that both TCP and multicast UDP support are OPTIONAL. We make TCP 6541 OPTIONAL because we expect NMP renderers to rely on data objects 6542 (signalled by "rinit" and associated parameters) for initialization at 6543 the start of the session, and only to use System Exclusive commands for 6544 interactive control during the session. These interactive commands are 6545 small enough to be protected via the recovery journal mechanism of RTP 6546 MIDI UDP streams. 6548 We now discuss timestamps, packet timing, and packet sending algorithms. 6550 Recall that the tsmode parameter controls the semantics of command 6551 timestamps in the MIDI list of RTP packets. 6553 Parties MUST support clock rates of 44.1 kHz, 48 kHz, 88.2 kHz, and 96 6554 kHz. Parties MUST support streams using the "comex", "async", and 6555 "buffer" tsmode values. Recvonly offers MUST offer the default "comex". 6557 Parties MUST support a wide range of packet temporal durations: from 6558 rtp_ptime and rtp_maxptime values of 0, to rtp_ptime and rtp_maxptime 6559 values that code 100 ms. Thus, receivers MUST be able to implement a 6560 playout buffer. 6562 Offers and answers MUST present rtp_ptime, rtp_maxptime, and guardtime 6563 values that support the latency that users would expect in the 6564 application, subject to bandwidth constraints. As senders MUST abide by 6565 values set for these parameters in a session description, a receiver 6566 SHOULD use these values to size its playout buffer to produce the lowest 6567 reliable latency for a session. Implementers should refer to [RFC4696] 6568 for information on packet sending algorithms for latency-sensitive 6569 applications. Parties MUST be able to implement the semantics of the 6570 guardtime parameter, for times from 5 ms to 5000 ms. 6572 We now discuss the use of the render parameter. 6574 Sessions MUST specify complete rendering systems for all RTP MIDI 6575 streams. Note that a minimal RTP MIDI native stream does not meet this 6576 requirement (Section 6.1), as the rendering method for such streams is 6577 "not specified". 6579 At the time this writing, the only way for parties to specify a complete 6580 rendering system is to specify an mpeg4-generic RTP MIDI stream in mode 6581 rtp-midi (Section 6.2 and C.6.5). We anticipate that the owners of 6582 rendering systems (both standardized and proprietary) will register 6583 subrender values for their renderers. Once IANA registration occurs, 6584 native RTP MIDI sessions may use render and subrender (Appendix C.6.2) 6585 to specify complete rendering systems for SIP network musical 6586 performance multimedia sessions. 6588 All parties MUST support General MIDI (GM) sessions, at a polyphony 6589 limited by the hardware capabilities of the party. This requirement 6590 provides a "lowest common denominator" rendering system, without which 6591 practical interoperability will be quite difficult. When using GM, 6592 parties SHOULD use Universal Real-Time SysEx MIP messages [SPMIDI] to 6593 communicate the priority of voices to polyphony-limited clients. 6595 Note that this requirement does not force implementors of a non-GM 6596 renderer (for mpeg4-generic sessions, DLS 2, or Structured Audio) to add 6597 a second rendering engine. Instead, a client may satisfy the 6598 requirement by including a set of voice patches that implement the GM 6599 instrument set, and using this emulation for mpeg4-generic GM sessions. 6600 We require GM support so that an offerer that wishes to maximize 6601 interoperability may do so by offering GM if its preferred renderer is 6602 not accepted by the answerer. 6604 Offerers MUST NOT present several renderers as options in a session 6605 description by listing several payload types on a media line, as Section 6606 2.1 uses this construct to let a party send several RTP MIDI streams in 6607 the same RTP session. 6609 Instead, an offerer wishing to present rendering options SHOULD offer a 6610 single payload type that offers several renderers. In this construct, 6611 the parameter list codes a list of render parameters (each followed by 6612 its support parameters). As discussed in Appendix C.6.1, the order of 6613 renderers in the list declares the offerer's preference. The "unknown" 6614 and "null" values MUST NOT appear in the offer. The answer MUST set all 6615 render values except the desired renderer to "null". Thus, "unknown" 6616 MUST NOT appear in the answer. 6618 We use SHOULD instead of MUST in the first sentence in the paragraph 6619 above, because this technique does not work in all situations (example: 6620 an offerer wishes to offer both mpeg4-generic renderers and native RTP 6621 MIDI renderers as options). In this case, the offerer MUST present a 6622 series of session descriptions, each offering a single renderer, until 6623 the answerer accepts a session description. 6625 Parties MUST support the musicport, chanmask, subrender, rinit, and 6626 inline parameters. Parties supporting renderers whose data object (as 6627 encoded by a parameter value for "inline") could exceed 300 octets in 6628 size MUST support the url and cid parameters and thus must implement the 6629 HTTP protocol. HTTP over TLS [RFC2818] support for data objects is 6630 OPTIONAL. Note that in mpeg4-generic, General MIDI data objects cannot 6631 exceed 300 octets, but DLS 2 and Structured Audio data objects may. 6632 Support for the other rendering parameters (smf_cif, smf_info, 6633 smf_inline, smf_url) is OPTIONAL. 6635 Thus far in this document, our discussion has assumed that the only MIDI 6636 flows that drive a renderer are the network flows described in the 6637 session description. In NMP applications, this assumption would require 6638 two rendering engines: one for local use by a party, a second for the 6639 remote party. 6641 In practice, applications may wish to have both parties share a single 6642 rendering engine. In this case, the session description MUST use a 6643 virtual sendrecv session and MUST use the stream subsetting and chapter 6644 inclusion parameters to allocate which MIDI channels are intended for 6645 use by a party. If two parties are sharing a MIDI channel, the 6646 application MUST ensure that appropriate MIDI merging occurs at the 6647 input to the renderer. 6649 We now discuss the use of (non-MIDI) audio streams in the session. 6651 Audio streams may be used for two purposes: as a "talkback" channel for 6652 parties to converse, or as a way to conduct a performance that includes 6653 MIDI and audio channels. In the latter case, offers MUST use sample 6654 rates and the packet temporal durations for the audio and MIDI streams 6655 that support low-latency synchronized rendering. 6657 We now show an example of an offer/answer exchange in a network musical 6658 performance application (next page). 6660 Below, we show an offer that complies with the interoperability text in 6661 this appendix section. 6663 v=0 6664 o=first 2520644554 2838152170 IN IP4 first.example.net 6665 s=Example 6666 t=0 0 6667 a=group:FID 1 2 6668 c=IN IP4 192.0.2.94 6669 m=audio 16112 RTP/AVP 96 6670 a=recvonly 6671 a=mid:1 6672 a=rtpmap:96 mpeg4-generic/44100 6673 a=fmtp:96 streamtype=5; mode=rtp-midi; config=""; profile-level-id=12; 6674 cm_unused=ABCFGHJKMNPQTVWXYZ; cm_used=2NPTW; 6675 cm_used=2C0.1.7.10.11.64.121.123; cm_used=2M0.1.2; 6676 cm_used=X0-16; ch_never=ABCDEFGHJKMNPQTVWXYZ; 6677 ch_default=2NPTW; ch_default=2C0.1.7.10.11.64.121.123; 6678 ch_default=2M0.1.2; cm_default=X0-16; 6679 rtp_ptime=0; rtp_maxptime=0; guardtime=44100; 6680 musicport=1; render=synthetic; rinit="audio/asc"; 6681 inline="egoAAAAaTVRoZAAAAAYAAAABAGBNVHJrAAAABgD/LwAA" 6682 m=audio 16114 RTP/AVP 96 6683 a=sendonly 6684 a=mid:2 6685 a=rtpmap:96 mpeg4-generic/44100 6686 a=fmtp:96 streamtype=5; mode=rtp-midi; config=""; profile-level-id=12; 6687 cm_unused=ABCFGHJKMNPQTVWXYZ; cm_used=1NPTW; 6688 cm_used=1C0.1.7.10.11.64.121.123; cm_used=1M0.1.2; 6689 cm_used=X0-16; ch_never=ABCDEFGHJKMNPQTVWXYZ; 6690 ch_default=1NPTW; ch_default=1C0.1.7.10.11.64.121.123; 6691 ch_default=1M0.1.2; cm_default=X0-16; 6692 rtp_ptime=0; rtp_maxptime=0; guardtime=44100; 6693 musicport=1; render=synthetic; rinit="audio/asc"; 6694 inline="egoAAAAaTVRoZAAAAAYAAAABAGBNVHJrAAAABgD/LwAA" 6696 (The a=fmtp lines have been wrapped to fit the page to accommodate 6697 memo formatting restrictions; it comprises a single line in SDP.) 6699 The owner line (o=) identifies the session owner as "first". 6701 The session description defines two MIDI streams: a recvonly stream on 6702 which "first" receives a performance, and a sendonly stream that "first" 6703 uses to send a performance. The recvonly port number encodes the ports 6704 on which "first" wishes to receive RTP (16112) and RTCP (16113) media at 6705 IP4 address 192.0.2.94. The sendonly port number encodes the port on 6706 which "first" wishes to receive RTCP for the stream (16115). 6708 The musicport parameters code that the two streams share and identity 6709 relationship and thus form a virtual sendrecv stream. 6711 Both streams are mpeg4-generic RTP MIDI streams that specify a General 6712 MIDI renderer. The stream subsetting parameters code that the recvonly 6713 stream uses MIDI channel 1 exclusively for voice commands, and that the 6714 sendonly stream uses MIDI channel 2 exclusively for voice commands. 6715 This mapping permits the application software to share a single renderer 6716 for local and remote performers. 6718 We now show the answer to the offer. 6720 v=0 6721 o=second 2520644554 2838152170 IN IP4 second.example.net 6722 s=Example 6723 t=0 0 6724 a=group:FID 1 2 6725 c=IN IP4 192.0.2.105 6726 m=audio 5004 RTP/AVP 96 6727 a=sendonly 6728 a=mid:1 6729 a=rtpmap:96 mpeg4-generic/44100 6730 a=fmtp:96 streamtype=5; mode=rtp-midi; config=""; profile-level-id=12; 6731 cm_unused=ABCFGHJKMNPQTVWXYZ; cm_used=2NPTW; 6732 cm_used=2C0.1.7.10.11.64.121.123; cm_used=2M0.1.2; 6733 cm_used=X0-16; ch_never=ABCDEFGHJKMNPQTVWXYZ; 6734 ch_default=2NPTW; ch_default=2C0.1.7.10.11.64.121.123; 6735 ch_default=2M0.1.2; cm_default=X0-16; 6736 rtp_ptime=0; rtp_maxptime=882; guardtime=44100; 6737 musicport=1; render=synthetic; rinit="audio/asc"; 6738 inline="egoAAAAaTVRoZAAAAAYAAAABAGBNVHJrAAAABgD/LwAA" 6739 m=audio 5006 RTP/AVP 96 6740 a=recvonly 6741 a=mid:2 6742 a=rtpmap:96 mpeg4-generic/44100 6743 a=fmtp:96 streamtype=5; mode=rtp-midi; config=""; profile-level-id=12; 6744 cm_unused=ABCFGHJKMNPQTVWXYZ; cm_used=1NPTW; 6745 cm_used=1C0.1.7.10.11.64.121.123; cm_used=1M0.1.2; 6746 cm_used=X0-16; ch_never=ABCDEFGHJKMNPQTVWXYZ; 6747 ch_default=1NPTW; ch_default=1C0.1.7.10.11.64.121.123; 6748 ch_default=1M0.1.2; cm_default=X0-16; 6749 rtp_ptime=0; rtp_maxptime=0; guardtime=88200; 6750 musicport=1; render=synthetic; rinit="audio/asc"; 6751 inline="egoAAAAaTVRoZAAAAAYAAAABAGBNVHJrAAAABgD/LwAA" 6753 (The a=fmtp lines have been wrapped to fit the page to accommodate 6754 memo formatting restrictions; they comprise single lines in SDP.) 6756 The owner line (o=) identifies the session owner as "second". 6758 The port numbers for both media streams are non-zero; thus, "second" has 6759 accepted the session description. The stream marked "sendonly" in the 6760 offer is marked "recvonly" in the answer, and vice versa, coding the 6761 different view of the session held by "session". The IP4 number 6762 (192.0.2.105) and the RTP (5004 and 5006) and RTCP (5005 and 5007) have 6763 been changed by "second" to match its transport wishes. 6765 In addition, "second" has made several parameter changes: rtp_maxptime 6766 for the sendonly stream has been changed to code 2 ms (441 in clock 6767 units), and the guardtime for the recvonly stream has been doubled. As 6768 these parameter modifications request capabilities that are REQUIRED to 6769 be implemented by interoperable parties, "second" can make these changes 6770 with confidence that "first" can abide by them. 6772 D. Parameter Syntax Definitions 6774 In this appendix, we define the syntax for the RTP MIDI media type 6775 parameters in Augmented Backus-Naur Form (ABNF, [RFC5234]). When using 6776 these parameters with SDP, all parameters MUST appear on a single fmtp 6777 attribute line of an RTP MIDI media description. For mpeg4-generic RTP 6778 MIDI streams, this line MUST also include any mpeg4-generic parameters 6779 (usage described in Section 6.2). An fmtp attribute line may be defined 6780 (after [RFC3640]) as: 6782 ; 6783 ; SDP fmtp line definition 6784 ; 6786 fmtp = "a=fmtp:" token SP param-assign 0*(";" SP param-assign) CRLF 6788 where codes the RTP payload type. Note that white space MUST 6789 NOT appear between the "a=fmtp:" and the RTP payload type. 6791 We now define the syntax of the parameters defined in Appendix C. The 6792 definition takes the form of the incremental assembly of the token. See [RFC3640] for the syntax of the mpeg4-generic 6794 parameters discussed in Section 6.2. 6796 ; 6797 ; 6798 ; top-level definition for all parameters 6799 ; 6800 ; 6802 ; 6803 ; Parameters defined in Appendix C.1 6805 param-assign = ("cm_unused=" (([channel-list] command-type 6806 [f-list]) / sysex-data)) 6808 param-assign =/ ("cm_used=" (([channel-list] command-type 6809 [f-list]) / sysex-data)) 6811 ; 6812 ; Parameters defined in Appendix C.2 6814 param-assign =/ ("j_sec=" ("none" / "recj" / ietf-extension)) 6816 param-assign =/ ("j_update=" ("anchor" / "closed-loop" / 6817 "open-loop" / ietf-extension)) 6819 param-assign =/ ("ch_default=" (([channel-list] chapter-list 6820 [f-list]) / sysex-data)) 6822 param-assign =/ ("ch_never=" (([channel-list] chapter-list 6823 [f-list]) / sysex-data)) 6825 param-assign =/ ("ch_anchor=" (([channel-list] chapter-list 6826 [f-list]) / sysex-data)) 6828 ; 6829 ; Parameters defined in Appendix C.3 6831 param-assign =/ ("tsmode=" ("comex" / "async" / "buffer")) 6833 param-assign =/ ("linerate=" nonzero-four-octet) 6835 param-assign =/ ("octpos=" ("first" / "last")) 6837 param-assign =/ ("mperiod=" nonzero-four-octet) 6839 ; 6840 ; Parameter defined in Appendix C.4 6842 param-assign =/ ("guardtime=" nonzero-four-octet) 6844 param-assign =/ ("rtp_ptime=" four-octet) 6846 param-assign =/ ("rtp_maxptime=" four-octet) 6848 ; 6849 ; Parameters defined in Appendix C.5 6851 param-assign =/ ("musicport=" four-octet) 6853 ; 6854 ; Parameters defined in Appendix C.6 6856 param-assign =/ ("chanmask=" 1*( 16(BIT) )) 6858 param-assign =/ ("cid=" DQUOTE cid-block DQUOTE) 6860 param-assign =/ ("inline=" DQUOTE base-64-block DQUOTE) 6862 param-assign =/ ("multimode=" ("all" / "one")) 6864 param-assign =/ ("render=" ("synthetic" / "api" / "null" / 6865 "unknown" / extension)) 6867 param-assign =/ ("rinit=" mime-type "/" mime-subtype) 6869 param-assign =/ ("smf_cid=" DQUOTE cid-block DQUOTE) 6871 param-assign =/ ("smf_info=" ("ignore" / "identity" / 6872 "sdp_start" / extension)) 6874 param-assign =/ ("smf_inline=" DQUOTE base-64-block DQUOTE) 6876 param-assign =/ ("smf_url=" DQUOTE uri-element DQUOTE) 6878 param-assign =/ ("subrender=" ("default" / extension)) 6880 param-assign =/ ("url=" DQUOTE uri-element DQUOTE) 6882 ; 6883 ; list definitions for the cm_ command-type 6884 ; 6886 command-type = [A] [B] [C] [F] [G] [H] [J] [K] [M] 6887 [N] [P] [Q] [T] [V] [W] [X] [Y] [Z] 6889 ; 6890 ; list definitions for the ch_ chapter-list 6891 ; 6893 chapter-list = [A] [B] [C] [D] [E] [F] [G] [H] [J] [K] 6894 [M] [N] [P] [Q] [T] [V] [W] [X] [Y] [Z] 6896 ; 6897 ; list definitions for the channel-list (used in ch_* / cm_* params) 6898 ; 6900 channel-list = midi-chan-element *("." midi-chan-element) 6902 midi-chan-element = midi-chan / midi-chan-range 6904 midi-chan-range = midi-chan "-" midi-chan 6905 ; 6906 ; decimal value of left midi-chan 6907 ; MUST be strictly less than 6908 ; decimal value of right midi-chan 6910 midi-chan = DIGIT / ("1" %x30-35) ; "0" .. "15" 6911 ; 6912 ; list definitions for the ch_ field list (f-list) 6913 ; 6915 f-list = midi-field-element *("." midi-field-element) 6917 midi-field-element = midi-field / midi-field-range 6919 midi-field-range = midi-field "-" midi-field 6920 ; 6921 ; decimal value of left midi-field 6922 ; MUST be strictly less than 6923 ; decimal value of right midi-field 6925 midi-field = four-octet 6926 ; 6927 ; large range accommodates Chapter M 6928 ; RPN (0-16383) and NRPN (16384-32767) 6929 ; parameters, and Chapter X octet sizes. 6931 ; 6932 ; definitions for ch_ sysex-data 6933 ; 6935 sysex-data = "__" h-list *("_" h-list) "__" 6937 h-list = hex-field-element *("." hex-field-element) 6939 hex-field-element = hex-octet / hex-field-range 6941 hex-field-range = hex-octet "-" hex-octet 6942 ; 6943 ; hexadecimal value of left hex-octet 6944 ; MUST be strictly less than hexadecimal 6945 ; value of right hex-octet 6947 hex-octet = %x30-37 U-HEXDIG 6948 ; 6949 ; rewritten special case of hex-octet in [RFC2045] 6950 ; (page 23). 6951 ; note that a-f are not permitted, only A-F. 6952 ; hex-octet values MUST NOT exceed 0x7F. 6954 ; 6955 ; definitions for rinit parameter 6956 ; 6958 mime-type = "audio" / "application" 6959 mime-subtype = token 6960 ; 6961 ; See Appendix C.6.2 for registration 6962 ; requirements for rinit type/subtypes. 6964 ; 6965 ; definitions for base64 encoding 6966 ; copied from [RFC4566] 6967 ; changes from [RFC4566] to improve automatic syntax checking 6968 ; 6970 base-64-block = *base64-unit [base64-pad] 6972 base64-unit = 4(base64-char) 6974 base64-pad = (2(base64-char) "==") / (3(base64-char) "=") 6976 base64-char = %x41-5A / %x61-7A / %x30-39 / "+" / "/" 6977 ; A-Z, a-z, 0-9, "+" and "/" 6979 ; 6980 ; generic rules 6981 ; 6983 ietf-extension = token 6984 ; 6985 ; may only be defined in standards-track RFCs 6987 extension = token 6988 ; 6989 ; may be defined 6990 ; by filing a registration with IANA 6992 nonzero-four-octet = (NZ-DIGIT 0*8(DIGIT)) 6993 / (%x30-33 9(DIGIT)) 6994 / ("4" %x30-31 8(DIGIT)) 6995 / ("42" %x30-38 7(DIGIT)) 6996 / ("429" %x30-33 6(DIGIT)) 6997 / ("4294" %x30-38 5(DIGIT)) 6998 / ("42949" %x30-35 4(DIGIT)) 6999 / ("429496" %x30-36 3(DIGIT)) 7000 / ("4294967" %x30-31 2(DIGIT)) 7001 / ("42949672" %x30-38 (DIGIT)) 7002 / ("429496729" %x30-34) 7003 ; 7004 ; unsigned encoding of non-zero 32-bit value: 7005 ; 1 .. 4294967295 7007 four-octet = "0" / nonzero-four-octet 7008 ; 7009 ; unsigned encoding of 32-bit value: 7010 ; 0 .. 4294967295 7012 uri-element = URI-reference 7013 ; as defined in [RFC3986] 7015 token = 1*token-char 7016 ; copied from [RFC4566] 7018 token-char = %x21 / %x23-27 / %x2A-2B / %x2D-2E / 7019 %x30-39 / %x41-5A / %x5E-7E 7020 ; copied from [RFC4566] 7022 cid-block = 1*cid-char 7024 cid-char = token-char 7025 cid-char =/ "@" 7026 cid-char =/ "," 7027 cid-char =/ ";" 7028 cid-char =/ ":" 7029 cid-char =/ "\" 7030 cid-char =/ "/" 7031 cid-char =/ "[" 7032 cid-char =/ "]" 7033 cid-char =/ "?" 7034 cid-char =/ "=" 7035 ; 7036 ; - add back in the tspecials [RFC2045], except 7037 ; for DQUOTE and the non-email safe ( ) < > 7038 ; - note that the definitions above ensure that 7039 ; cid-block is always enclosed with DQUOTEs 7041 A = %x41 ; uppercase only letters used above 7042 B = %x42 7043 C = %x43 7044 D = %x44 7045 E = %x45 7046 F = %x46 7047 G = %x47 7048 H = %x48 7049 J = %x4A 7050 K = %x4B 7051 M = %x4D 7052 N = %x4E 7053 P = %x50 7054 Q = %x51 7055 T = %x54 7056 V = %x56 7057 W = %x57 7058 X = %x58 7059 Y = %x59 7060 Z = %x5A 7062 NZ-DIGIT = %x31-39 ; non-zero decimal digit 7064 U-HEXDIG = DIGIT / A / B / C / D / E / F 7065 ; variant of HEXDIG [RFC5234] : 7066 ; hexadecimal digit using uppercase A-F only 7068 ; the rules below are from the Core Rules from [RFC5234] 7070 BIT = "0" / "1" 7072 DQUOTE = %x22 ; " (Double Quote) 7074 DIGIT = %x30-39 ; 0-9 7076 ; external references 7077 ; URI-reference: from [RFC3986] 7079 ; 7080 ; End of ABNF 7082 The mpeg4-generic RTP payload [RFC3640] defines a "mode" parameter that 7083 signals the type of MPEG stream in use. We add a new mode value, "rtp- 7084 midi", using the ABNF rule below: 7086 ; 7087 ; mpeg4-generic mode parameter extension 7088 ; 7090 mode =/ "rtp-midi" 7091 ; as described in Section 6.2 of this memo 7093 E. A MIDI Overview for Networking Specialists 7095 This appendix presents an overview of the MIDI standard, for the benefit 7096 of networking specialists new to musical applications. Implementors 7097 should consult [MIDI] for a normative description of MIDI. 7099 Musicians make music by performing a controlled sequence of physical 7100 movements. For example, a pianist plays by coordinating a series of key 7101 presses, key releases, and pedal actions. MIDI represents a musical 7102 performance by encoding these physical gestures as a sequence of MIDI 7103 commands. This high-level musical representation is compact but 7104 fragile: one lost command may be catastrophic to the performance. 7106 MIDI commands have much in common with the machine instructions of a 7107 microprocessor. MIDI commands are defined as binary elements. 7108 Bitfields within a MIDI command have a regular structure and a 7109 specialized purpose. For example, the upper nibble of the first command 7110 octet (the opcode field) codes the command type. MIDI commands may 7111 consist of an arbitrary number of complete octets, but most MIDI 7112 commands are 1, 2, or 3 octets in length. 7114 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 7115 | Channel Voice Messages | Bitfield Pattern | 7116 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 7117 | NoteOff (end a note) | 1000cccc 0nnnnnnn 0vvvvvvv | 7118 |-------------------------------------------------------------| 7119 | NoteOn (start a note) | 1001cccc 0nnnnnnn 0vvvvvvv | 7120 |-------------------------------------------------------------| 7121 | PTouch (Polyphonic Aftertouch) | 1010cccc 0nnnnnnn 0aaaaaaa | 7122 |-------------------------------------------------------------| 7123 | CControl (Controller Change) | 1011cccc 0xxxxxxx 0yyyyyyy | 7124 |-------------------------------------------------------------| 7125 | PChange (Program Change) | 1100cccc 0ppppppp | 7126 |-------------------------------------------------------------| 7127 | CTouch (Channel Aftertouch) | 1101cccc 0aaaaaaa | 7128 |-------------------------------------------------------------| 7129 | PWheel (Pitch Wheel) | 1110cccc 0xxxxxxx 0yyyyyyy | 7130 ------------------------------------------------------------- 7132 Figure E.1 -- MIDI Channel Messages 7134 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 7135 | System Common Messages | Bitfield Pattern | 7136 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 7137 | System Exclusive | 11110000, followed by a | 7138 | | list of 0xxxxxx octets, | 7139 | | followed by 11110111 | 7140 |-------------------------------------------------------------| 7141 | MIDI Time Code Quarter Frame | 11110001 0xxxxxxx | 7142 |-------------------------------------------------------------| 7143 | Song Position Pointer | 11110010 0xxxxxxx 0yyyyyyy | 7144 |-------------------------------------------------------------| 7145 | Song Select | 11110011 0xxxxxxx | 7146 |-------------------------------------------------------------| 7147 | Undefined | 11110100 | 7148 |-------------------------------------------------------------| 7149 | Undefined | 11110101 | 7150 |-------------------------------------------------------------| 7151 | Tune Request | 11110110 | 7152 |-------------------------------------------------------------| 7153 | System Exclusive End Marker | 11110111 | 7154 ------------------------------------------------------------- 7156 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 7157 | System Realtime Messages | Bitfield Pattern | 7158 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 7159 | Clock | 11111000 | 7160 |-------------------------------------------------------------| 7161 | Undefined | 11111001 | 7162 |-------------------------------------------------------------| 7163 | Start | 11111010 | 7164 |-------------------------------------------------------------| 7165 | Continue | 11111011 | 7166 |-------------------------------------------------------------| 7167 | Stop | 11111100 | 7168 |-------------------------------------------------------------| 7169 | Undefined | 11111101 | 7170 |-------------------------------------------------------------| 7171 | Active Sense | 11111110 | 7172 |-------------------------------------------------------------| 7173 | System Reset | 11111111 | 7174 ------------------------------------------------------------- 7176 Figure E.2 -- MIDI System Messages 7178 Figure E.1 and E.2 show the MIDI command family. There are three major 7179 classes of commands: voice commands (opcode field values in the range 7180 0x8 through 0xE), system common commands (opcode field 0xF, commands 7181 0xF0 through 0xF7), and system real-time commands (opcode field 0xF, 7182 commands 0xF8 through 0xFF). Voice commands code the musical gestures 7183 for each timbre in a composition. Systems commands perform functions 7184 that usually affect all voice channels, such as System Reset (0xFF). 7186 E.1. Commands Types 7188 Voice commands execute on one of 16 MIDI channels, as coded by its 4-bit 7189 channel field (field cccc in Figure E.1). In most applications, notes 7190 for different timbres are assigned to different channels. To support 7191 applications that require more than 16 channels, MIDI systems use 7192 several MIDI command streams in parallel, to yield 32, 48, or 64 MIDI 7193 channels. 7195 As an example of a voice command, consider a NoteOn command (opcode 7196 0x9), with binary encoding 1001cccc 0nnnnnnn 0aaaaaaa. This command 7197 signals the start of a musical note on MIDI channel cccc. The note has 7198 a pitch coded by the note number nnnnnnn, and an onset amplitude coded 7199 by note velocity aaaaaaa. 7201 Other voice commands signal the end of notes (NoteOff, opcode 0x8), map 7202 a specific timbre to a MIDI channel (PChange, opcode 0xC), or set the 7203 value of parameters that modulate the timbral quality (all other voice 7204 commands). The exact meaning of most voice channel commands depends on 7205 the rendering algorithms the MIDI receiver uses to generate sound. In 7206 most applications, a MIDI sender has a model (in some sense) of the 7207 rendering method used by the receiver. 7209 System commands perform a variety of global tasks in the stream, 7210 including "sequencer" playback control of pre-recorded MIDI commands 7211 (the Song Position Pointer, Song Select, Clock, Start, Continue, and 7212 Stop messages), SMPTE time code (the MIDI Time Code Quarter Frame 7213 command), and the communication of device-specific data (the System 7214 Exclusive messages). 7216 E.2. Running Status 7218 All MIDI command bitfields share a special structure: the leading bit of 7219 the first octet is set to 1, and the leading bit of all subsequent 7220 octets is set to 0. This structure supports a data compression system, 7221 called running status [MIDI], that improves the coding efficiency of 7222 MIDI. 7224 In running status coding, the first octet of a MIDI voice command may be 7225 dropped if it is identical to the first octet of the previous MIDI voice 7226 command. This rule, in combination with a convention to consider NoteOn 7227 commands with a null third octet as NoteOff commands, supports the 7228 coding of note sequences using two octets per command. 7230 Running status coding is only used for voice commands. The presence of 7231 a system common message in the stream cancels running status mode for 7232 the next voice command. However, system real-time messages do not 7233 cancel running status mode. 7235 E.3. Command Timing 7237 The bitfield formats in Figures E.1 and E.2 do not encode the execution 7238 time for a command. Timing information is not a part of the MIDI 7239 command syntax itself; different applications of the MIDI command 7240 language use different methods to encode timing. 7242 For example, the MIDI command set acts as the transport layer for MIDI 7243 1.0 DIN cables [MIDI]. MIDI cables are short asynchronous serial lines 7244 that facilitate the remote operation of musical instruments and audio 7245 equipment. Timestamps are not sent over a MIDI 1.0 DIN cable. Instead, 7246 the standard uses an implicit "time of arrival" code. Receivers execute 7247 MIDI commands at the moment of arrival. 7249 In contrast, Standard MIDI Files (SMFs, [MIDI]), a file format for 7250 representing complete musical performances, add an explicit timestamp to 7251 each MIDI command, using a delta encoding scheme that is optimized for 7252 statistics of musical performance. SMF timestamps usually code timing 7253 using the metric notation of a musical score. SMF meta-events are used 7254 to add a tempo map to the file, so that score beats may be accurately 7255 converted into units of seconds during rendering. 7257 E.4. AudioSpecificConfig Templates for MMA Renderers 7259 In Section 6.2 and Appendix C.6.5, we describe how session descriptions 7260 include an AudioSpecificConfig data block to specify a MIDI rendering 7261 algorithm for mpeg4-generic RTP MIDI streams. 7263 The bitfield format of AudioSpecificConfig is defined in [MPEGAUDIO]. 7264 StructuredAudioSpecificConfig, a key data structure coded in 7265 AudioSpecificConfig, is defined in [MPEGSA]. 7267 For implementors wishing to specify Structured Audio renderers, a full 7268 understanding of [MPEGSA] and [MPEGAUDIO] is essential. However, many 7269 implementors will limit their rendering options to the two MIDI 7270 Manufacturers Association renderers that may be specified in 7271 AudioSpecificConfig: General MIDI (GM, [MIDI]) and Downloadable Sounds 2 7272 (DLS 2, [DLS2]). 7274 To aid these implementors, we reproduce the AudioSpecificConfig bitfield 7275 formats for a GM renderer and a DLS 2 renderer below. We have checked 7276 these bitfields carefully and believe they are correct. However, we 7277 stress that the material below is informative, and that [MPEGAUDIO] and 7278 [MPEGSA] are the normative definitions for AudioSpecificConfig. 7280 As described in Section 6.2, a minimal mpeg4-generic session description 7281 encodes the AudioSpecificConfig binary bitfield as a hexadecimal string 7282 (whose format is defined in [RFC3640]) that is assigned to the "config" 7283 parameter. As described in Appendix C.6.3, a session description that 7284 uses the render parameter encodes the AudioSpecificConfig binary 7285 bitfield as a Base64-encoded string assigned to the "inline" parameter, 7286 or in the body of an HTTP URL assigned to the "url" parameter. 7288 Below, we show a simplified binary AudioSpecificConfig bitfield format, 7289 suitable for sending and receiving GM and DLS 2 data: 7291 0 1 2 3 7292 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 7293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7294 | AOTYPE |FREQIDX|CHANNEL|SACNK| FILE_BLK 1 (required) ... | 7295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7296 |1|SACNK| FILE_BLK 2 (optional) ... | 7297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7298 | ... |1|SACNK| FILE_BLK N (optional) ... | 7299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7300 |0|0| (first "0" bit terminates FILE_BLK list) 7301 +-+-+ 7303 Figure E.3 -- Simplified AudioSpecificConfig 7305 The 5-bit AOTYPE field specifies the Audio Object Type as an unsigned 7306 integer. The legal values for use with mpeg4-generic RTP MIDI streams 7307 are "15" (General MIDI), "14" (DLS 2), and "13" (Structured Audio). 7308 Thus, receivers that do not support all three mpeg4-generic renderers 7309 may parse the first 5 bits of an AudioSpecificConfig coded in a session 7310 description and reject sessions that specify unsupported renderers. 7312 The 4-bit FREQIDX field specifies the sampling rate of the renderer. We 7313 show the mapping of FREQIDX values to sampling rates in Figure E.4. 7314 Senders MUST specify a sampling frequency that matches the RTP clock 7315 rate, if possible; if not, senders MUST specify the escape value. 7316 Receivers MUST consult the RTP clock parameter for the true sampling 7317 rate if the escape value is specified. 7319 FREQIDX Sampling Frequency 7321 0x0 96000 7322 0x1 88200 7323 0x2 64000 7324 0x3 48000 7325 0x4 44100 7326 0x5 32000 7327 0x6 24000 7328 0x7 22050 7329 0x8 16000 7330 0x9 12000 7331 0xa 11025 7332 0xb 8000 7333 0xc reserved 7334 0xd reserved 7335 0xe reserved 7336 0xf escape value 7338 Figure E.4 -- FreqIdx encoding 7340 The 4-bit CHANNEL field specifies the number of audio channels for the 7341 renderer. The values 0x1 to 0x5 specify 1 to 5 audio channels; the 7342 value 0x6 specifies 5+1 surround sound, and the value 0x7 specifies 7+1 7343 surround sound. If the rtpmap line in the session description specifies 7344 one of these formats, CHANNEL MUST be set to the corresponding value. 7345 Otherwise, CHANNEL MUST be set to 0x0. 7347 The CHANNEL field is followed by a list of one or more binary file data 7348 blocks. The 3-bit SACNK field (the chunk_type field in class 7349 StructuredAudioSpecificConfig, defined in [MPEGSA]) specifies the type 7350 of each data block. 7352 For General MIDI, only Standard MIDI Files may appear in the list (SACNK 7353 field value 2). For DLS 2, only Standard MIDI Files and DLS 2 RIFF 7354 files (SACNK field value 4) may appear. For both of these file types, 7355 the FILE_BLK field has the format shown in Figure E.5: a 32-bit unsigned 7356 integer value (FILE_LEN) coding the number of bytes in the SMF or RIFF 7357 file, followed by FILE_LEN bytes coding the file data. 7359 0 1 2 3 7360 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 7361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7362 | FILE_LEN (32-bit, a byte count SMF file or RIFF file) | 7363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7364 | FILE_DATA (file contents, a list of FILE_LEN bytes) ... | 7365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7367 Figure E.5 -- The FILE_BLK field format 7369 Note that several files may follow the CHANNEL field. The "1" constant 7370 fields in Figure E.3 code the presence of another file; the "0" constant 7371 field codes the end of the list. The final "0" bit in Figure E.3 codes 7372 the absence of special coding tools (see [MPEGAUDIO] for details). 7373 Senders not using these tools MUST append this "0" bit; receivers that 7374 do not understand these coding tools MUST ignore all data following a 7375 "1" in this position. 7377 The StructuredAudioSpecificConfig bitfield structure requires the 7378 presence of one FILE_BLK. For mpeg4-generic RTP MIDI use of DLS 2, 7379 FILE_BLKs MUST code RIFF files or SMF files. For mpeg4-generic RTP MIDI 7380 use of General MIDI, FILE_BLKs MUST code SMF files. By default, this 7381 SMF will be ignored (Appendix C.6.4.1). In this default case, a GM 7382 StructuredAudioSpecificConfig bitfield SHOULD code a FILE_BLK whose 7383 FILE_LEN is 0, and whose FILE_DATA is empty. 7385 To complete this appendix, we derive the StructuredAudioSpecificConfig 7386 that we use in the General MIDI session examples in this memo. 7387 Referring to Figure E.3, we note that for GM, AOTYPE = 15. Our examples 7388 use a 44,100 Hz sample rate (FREQIDX = 4) and are in mono (CHANNEL = 1). 7389 For GM, a single SMF is encoded (SACNK = 2), using the SMF shown in 7390 Figure E.6 (a 26 byte file). 7392 -------------------------------------------- 7393 | MIDI File =
| 7394 -------------------------------------------- 7396
= 7397 4D 54 68 64 00 00 00 06 00 00 00 01 00 60 7399 = 7400 4D 54 72 6B 00 00 00 04 00 FF 2F 00 7402 Figure E.6 -- SMF file encoded in the example 7404 Placing these constants in binary format into the data structure shown 7405 in Figure E.3 yields the constant shown in Figure E.7. 7407 0 1 2 3 7408 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 7409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7410 |0 1 1 1 1|0 1 0 0|0 0 0 1|0 1 0|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| 7411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7412 |0 0 0 0 0 0 0 0 0 0 0 1 1 0 1 0|0 1 0 0|1 1 0 1|0 1 0 1|0 1 0 0| 7413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7414 |0 1 1 0|1 0 0 0|0 1 1 0|0 1 0 0|0 0 0 0|0 0 0 0|0 0 0 0|0 0 0 0| 7415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7416 |0 0 0 0|0 0 0 0|0 0 0 0|0 1 1 0|0 0 0 0|0 0 0 0|0 0 0 0|0 0 0 0| 7417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7418 |0 0 0 0|0 0 0 0|0 0 0 0|0 0 0 1|0 0 0 0|0 0 0 0|0 1 1 0|0 0 0 0| 7419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7420 |0 1 0 0|1 1 0 1|0 1 0 1|0 1 0 0|0 1 1 1|0 0 1 0|0 1 1 0|1 0 1 1| 7421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7422 |0 0 0 0|0 0 0 0|0 0 0 0|0 0 0 0|0 0 0 0|0 0 0 0|0 0 0 0|0 1 1 0| 7423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7424 |0 0 0 0|0 0 0 0|1 1 1 1|1 1 1 1|0 0 1 0|1 1 1 1|0 0 0 0|0 0 0 0| 7425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7426 |0|0| 7427 +-+-+ 7429 Figure E.7 -- AudioSpecificConfig used in GM examples 7431 Expressing this bitfield as an ASCII hexadecimal string yields: 7433 7A0A0000001A4D546864000000060000000100604D54726B0000000600FF2F000 7435 This string is assigned to the "config" parameter in the minimal 7436 mpeg4-generic General MIDI examples in this memo (such as the example in 7437 Section 6.2). Expressing this string in Base64 [RFC2045] yields: 7439 egoAAAAaTVRoZAAAAAYAAAABAGBNVHJrAAAABgD/LwAA 7441 This string is assigned to the "inline" parameter in the General MIDI 7442 example shown in Appendix C.6.5. 7444 References 7446 Normative References 7448 [MIDI] MIDI Manufacturers Association. "The Complete MIDI 1.0 7449 Detailed Specification", 1996. 7451 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 7452 Jacobson, "RTP: A Transport Protocol for Real-Time 7453 Applications", STD 64, RFC 3550, July 2003. 7455 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 7456 Video Conferences with Minimal Control", STD 65, RFC 7457 3551, July 2003. 7459 [RFC3640] van der Meer, J., Mackie, D., Swaminathan, V., Singer, 7460 D., and P. Gentric, "RTP Payload Format for Transport of 7461 MPEG-4 Elementary Streams", RFC 3640, November 2003. 7463 [MPEGSA] International Standards Organization. "ISO/IEC 14496 7464 MPEG-4", Part 3 (Audio), Subpart 5 (Structured Audio), 7465 2001. 7467 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 7468 Description Protocol", RFC 4566, July 2006. 7470 [MPEGAUDIO] International Standards Organization. "ISO 14496 MPEG- 7471 4", Part 3 (Audio), 2001. 7473 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 7474 Extensions (MIME) Part One: Format of Internet Message 7475 Bodies", RFC 2045, November 1996. 7477 [DLS2] MIDI Manufacturers Association. "The MIDI Downloadable 7478 Sounds Specification", v98.2, 1998. 7480 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 7481 Specifications: ABNF", RFC 5234, January 2008. 7483 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 7484 Requirement Levels", BCP 14, RFC 2119, March 1997. 7486 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 7487 Norrman, "The Secure Real-time Transport Protocol 7488 (SRTP)", RFC 3711, March 2004. 7490 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 7491 with Session Description Protocol (SDP)", RFC 3264, June 7492 2002. 7494 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 7495 Resource Identifier (URI): Generic Syntax", STD 66, RFC 7496 3986, January 2005. 7498 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 7499 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 7500 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 7502 [RFC3388] Camarillo, G., Eriksson, G., Holler, J., and H. 7503 Schulzrinne, "Grouping of Media Lines in the Session 7504 Description Protocol (SDP)", RFC 3388, December 2002. 7506 [RP015] MIDI Manufacturers Association. "Recommended Practice 7507 015 (RP-015): Response to Reset All Controllers", 11/98. 7509 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and 7510 Registration Procedures", BCP 13, RFC 4288, December 7511 2005. 7513 [RFC4855] Casner, S., "MIME Type Registration of RTP 7514 Payload Formats", RFC 4855, February 2007. 7516 Informative References 7518 [NMP] Lazzaro, J. and J. Wawrzynek. "A Case for Network 7519 Musical Performance", 11th International Workshop on 7520 Network and Operating Systems Support for Digital Audio 7521 and Video (NOSSDAV 2001) June 25-26, 2001, Port 7522 Jefferson, New York. 7524 [GRAME] Fober, D., Orlarey, Y. and S. Letz. "Real Time Musical 7525 Events Streaming over Internet", Proceedings of the 7526 International Conference on WEB Delivering of Music 2001, 7527 pages 147-154. 7529 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 7530 A., Peterson, J., Sparks, R., Handley, M., and E. 7531 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 7532 June 2002. 7534 [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time 7535 Streaming Protocol (RTSP)", RFC 2326, April 1998. 7537 [ALF] Clark, D. D. and D. L. Tennenhouse. "Architectural 7538 considerations for a new generation of protocols", 7539 SIGCOMM Symposium on Communications Architectures and 7540 Protocols , (Philadelphia, Pennsylvania), pp. 200--208, 7541 ACM, Sept. 1990. 7543 [RFC4696] Lazzaro, J. and J. Wawrzynek, "An Implementation Guide 7544 for RTP MIDI", RFC 4696, November 2006. 7546 [RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. 7547 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 7548 Functional Specification", RFC 2205, September 1997. 7550 [RFC4571] Lazzaro, J. "Framing Real-time Transport Protocol (RTP) 7551 and RTP Control Protocol (RTCP) Packets over Connection- 7552 Oriented Transport", RFC 4571, July 2006. 7554 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 7556 [SPMIDI] MIDI Manufacturers Association. "Scalable Polyphony 7557 MIDI, Specification and Device Profiles", Document 7558 Version 1.0a, 2002. 7560 [LCP] Apple Computer. "Logic 7 Dedicated Control Surface 7561 Support", Appendix B. Product manual available from 7562 www.apple.com. 7564 Authors' Addresses 7566 John Lazzaro (corresponding author) 7567 UC Berkeley 7568 CS Division 7569 315 Soda Hall 7570 Berkeley CA 94720-1776 7571 EMail: lazzaro@cs.berkeley.edu 7573 John Wawrzynek 7574 UC Berkeley 7575 CS Division 7576 631 Soda Hall 7577 Berkeley CA 94720-1776 7578 EMail: johnw@cs.berkeley.edu 7580 Full Copyright Statement 7582 Copyright (C) The IETF Trust (2008). 7584 This document is subject to the rights, licenses and restrictions 7585 contained in BCP 78, and except as set forth therein, the authors retain 7586 all their rights. 7588 This document and the information contained herein are provided on an 7589 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 7590 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 7591 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 7592 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 7593 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 7594 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 7596 Intellectual Property 7598 The IETF takes no position regarding the validity or scope of any 7599 Intellectual Property Rights or other rights that might be claimed to 7600 pertain to the implementation or use of the technology described in this 7601 document or the extent to which any license under such rights might or 7602 might not be available; nor does it represent that it has made any 7603 independent effort to identify any such rights. Information on the 7604 procedures with respect to rights in RFC documents can be found in BCP 7605 78 and BCP 79. 7607 Copies of IPR disclosures made to the IETF Secretariat and any 7608 assurances of licenses to be made available, or the result of an attempt 7609 made to obtain a general license or permission for the use of such 7610 proprietary rights by implementers or users of this specification can be 7611 obtained from the IETF on-line IPR repository at 7612 http://www.ietf.org/ipr. 7614 The IETF invites any interested party to bring to its attention any 7615 copyrights, patents or patent applications, or other proprietary rights 7616 that may cover technology that may be required to implement this 7617 standard. Please address the information to the IETF at ietf- 7618 ipr@ietf.org. 7620 Acknowledgement 7622 Funding for the RFC Editor function is currently provided by the 7623 Internet Society. 7625 Change Log for 7627 This I-D is a modified version of RFC 4695. For every error found to 7628 date in RFC 4695, the I-D has been modified to fix the error. 7630 Below, we list the errors found in RFC 4695 that are most likely to 7631 confuse implementors. The fixes to Appendix D ABNF errors listed 7632 below are presented without comments; see Appendix D to see the 7633 commented rule in context. The list below includes the fixes for all 7634 normative errors; most fixes for other types of errors are not listed. 7635 However, the I-D itself contains fixes for all known errors. 7637 -- 7639 03.txt & 04.txt changes: 7641 No errata has been reported for RFC 4695 in the past year. 7642 Apart from updates in the document name and expiration dates, 7643 03.txt and 04.txt contains no changes from 02.txt 7645 -- 7647 02.txt changes: 7649 No errata has been reported for RFC 4695 in the past six months. 7650 Apart from updates in the document name and expiration dates, 7651 02.txt contains no changes from 01.txt 7653 -- 7655 01.txt changes: 7657 A typo was fixed in the Appendix D ABNF. P and Q are now 7658 correctly defined as: 7660 P = %x50 7661 Q = %x51 7663 Thanks to Alfred Hoenes for these changes. 7665 -- 7667 00.txt changes: 7669 Thanks to Alfred Hoenes for these changes. 7671 [1] In Appendix C.1 and Appendix C.2.3 of RFC 4695, an ABNF rule 7672 related to System Chapter X is incorrectly defined as: 7674 = "__" ["_" ] "__" 7676 The correct version of this rule is: 7678 = "__" *( "_" ) "__" 7680 [2] In Appendix C.6.3 of RFC 4695, the URIs permitted to be assigned 7681 to the "url" parameter are not stated clearly. URIs assigned to "url" 7682 MUST specify either HTTP or HTTP over TLS transport protocols. 7684 In Appendix C.7.1 and C.7.2 of RFC 4695, the transport 7685 interoperability requirements for the "url" parameter are not stated 7686 clearly. For both C.7.1 and C.7.2, HTTP is REQUIRED and HTTP over TLS 7687 is OPTIONAL. 7689 [3] Both fmtp lines in both session description examples in Appendix 7690 C.7.2 of RFC 4695 contain instances of the same syntax error (a 7691 missing ";" at a line wrap after "cm_used=2M0.1.2"). 7693 [4] In Appendix D of RFC 4695, all uses of "*ietf-extension" in rules 7694 are in error, and should be replaced with "ietf-extension". Likewise, 7695 all uses of "*extension" are in error, and should be replaced with 7696 "extension". This bug incorrectly lets the null token be assigned to 7697 the j_sec, j_update, render, smf_info, and subrender parameters. 7699 [5] In Appendix D of RFC 4695, the definitions of the 7700 and incorrectly allow lowercase letters to appear in 7701 these strings. The correct definitions of these rules appear below: 7703 command-type = [A] [B] [C] [F] [G] [H] [J] [K] [M] 7704 [N] [P] [Q] [T] [V] [W] [X] [Y] [Z] 7706 chapter-list = [A] [B] [C] [D] [E] [F] [G] [H] [J] [K] 7707 [M] [N] [P] [Q] [T] [V] [W] [X] [Y] [Z] 7709 A = %x41 7710 B = %x42 7711 C = %x43 7712 D = %x44 7713 E = %x45 7714 F = %x46 7715 G = %x47 7716 H = %x48 7717 J = %x4A 7718 K = %x4B 7719 M = %x4D 7720 N = %x4E 7721 P = %x50 ; correct as shown, these values were 7722 Q = %x51 ; incorrect in the -00.txt I-D version 7723 T = %x54 7724 V = %x56 7725 W = %x57 7726 X = %x58 7727 Y = %x59 7728 Z = %x5A 7730 [5] In Appendix D of RFC 4695, the definitions of the , 7731 , and are incorrect. The correct 7732 definitions of these rules appear below: 7734 nonzero-four-octet = (NZ-DIGIT 0*8(DIGIT)) 7735 / (%x30-33 9(DIGIT)) 7736 / ("4" %x30-31 8(DIGIT)) 7737 / ("42" %x30-38 7(DIGIT)) 7738 / ("429" %x30-33 6(DIGIT)) 7739 / ("4294" %x30-38 5(DIGIT)) 7740 / ("42949" %x30-35 4(DIGIT)) 7741 / ("429496" %x30-36 3(DIGIT)) 7742 / ("4294967" %x30-31 2(DIGIT)) 7743 / ("42949672" %x30-38 (DIGIT)) 7744 / ("429496729" %x30-34) 7746 four-octet = "0" / nonzero-four-octet 7747 midi-chan = DIGIT / ("1" %x30-35) 7749 DIGIT = %x30-39 7750 NZ-DIGIT = %x31-39 7752 [6] In Appendix D of RFC4695, the rule is 7753 incorrect. The correct definition of this rule appears below. 7755 hex-octet = %x30-37 U-HEXDIG 7756 U-HEXDIG = DIGIT / A / B / C / D / E / F 7758 ; DIGIT as defined in [5] above 7759 ; A, B, C, D, E, F as defined in [4] above 7761 [7] In Appendix D of RFC4695, the rules and 7762 are defined unclearly. The rewritten rules 7763 appear below: 7765 base64-unit = 4(base64-char) 7766 base64-pad = (2(base64-char) "==") / (3(base64-char) "=") 7768 ---