idnits 2.17.1 draft-ietf-avt-rfc4695-bis-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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? -- The draft header indicates that this document obsoletes RFC4695, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors 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.) -- The document date (December 17, 2010) is 4878 days in the past. Is this intentional? 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 6982 -- Looks like a reference, but probably isn't: '8' on line 7072 -- Looks like a reference, but probably isn't: '2' on line 6991 -- Looks like a reference, but probably isn't: '3' on line 7000 -- Looks like a reference, but probably isn't: '4' on line 7004 -- Looks like a reference, but probably isn't: '5' on line 7070 -- Looks like a reference, but probably isn't: '6' on line 7069 -- Looks like a reference, but probably isn't: '7' on line 7063 == Unused Reference: 'RFC4855' is defined on line 7148, but no explicit reference was found in the text -- 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: 4 errors (**), 0 flaws (~~), 3 warnings (==), 19 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 AVT J. Lazzaro 3 Internet-Draft J. Wawrzynek 4 Obsoletes: 4695 (if approved) UC Berkeley 5 Intended status: Standards Track December 17, 2010 6 Expires: June 17, 2011 8 RTP Payload Format for MIDI 10 12 Abstract 14 This memo describes a Real-time Transport Protocol (RTP) payload 15 format for the MIDI (Musical Instrument Digital Interface) command 16 language. The format encodes all commands that may legally appear on 17 a MIDI 1.0 DIN cable. The format is suitable for interactive 18 applications (such as network musical performance) and content- 19 delivery applications (such as file streaming). The format may be 20 used over unicast and multicast UDP and TCP, and it defines tools for 21 graceful recovery from packet loss. Stream behavior, including the 22 MIDI rendering method, may be customized during session setup. The 23 format also serves as a mode for the mpeg4-generic format, to support 24 the MPEG 4 Audio Object Types for General MIDI, Downloadable Sounds 25 Level 2, and Structured Audio. 27 Status of This Memo 29 This Internet-Draft is submitted to IETF in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering Task 33 Force (IETF), its areas, and its working groups. Note that other 34 groups may also distribute working documents as Internet-Drafts. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference material 39 or to cite them other than as "work in progress." 41 The list of current Internet-Drafts can be accessed at 42 http://www.ietf.org/1id-abstracts.html 44 The list of Internet-Draft Shadow Directories can be accessed at 45 http://www.ietf.org/shadow.html 46 This Internet-Draft will expire on June 17, 2011. 48 Copyright Notice 50 Copyright (c) 2010 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal Provisions 54 Relating to IETF Documents (http://trustee.ietf.org/license-info) 55 in effect on the date of publication of this document. Please 56 review these documents carefully, as they describe your rights and 57 restrictions with respect to this document. Code Components 58 extracted from this document must include Simplified BSD License 59 text as described in Section 4.e of the Trust Legal Provisions and 60 are provided without warranty as described in the Simplified BSD 61 License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 67 1.2. Bitfield Conventions . . . . . . . . . . . . . . . . . . . 6 68 2. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . . . 7 69 2.1. RTP Header . . . . . . . . . . . . . . . . . . . . . . . . 7 70 2.2. MIDI Payload . . . . . . . . . . . . . . . . . . . . . . . 12 71 3. MIDI Command Section . . . . . . . . . . . . . . . . . . . . . . 14 72 3.1. Timestamps . . . . . . . . . . . . . . . . . . . . . . . . 15 73 3.2. Command Coding . . . . . . . . . . . . . . . . . . . . . . 17 74 4. The Recovery Journal System . . . . . . . . . . . . . . . . . . . 24 75 5. Recovery Journal Format . . . . . . . . . . . . . . . . . . . . . 26 76 6. Session Description Protocol . . . . . . . . . . . . . . . . . . 30 77 6.1. Session Descriptions for Native Streams . . . . . . . . . 31 78 6.2. Session Descriptions for mpeg4-generic Streams . . . . . . 33 79 6.3. Parameters . . . . . . . . . . . . . . . . . . . . . . . . 35 80 7. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . . . 37 81 8. Congestion Control . . . . . . . . . . . . . . . . . . . . . . . 38 82 9. Security Considerations . . . . . . . . . . . . . . . . . . . . . 39 83 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 40 84 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 40 85 A. The Recovery Journal Channel Chapters . . . . . . . . . . . . . . 41 86 A.1. Recovery Journal Definitions . . . . . . . . . . . . . . . 41 87 A.2. Chapter P: MIDI Program Change . . . . . . . . . . . . . . 46 88 A.3. Chapter C: MIDI Control Change . . . . . . . . . . . . . . 47 89 A.3.1. Log Inclusion Rules . . . . . . . . . . . . . . . . 47 90 A.3.2. Controller Log Format . . . . . . . . . . . . . . . 49 91 A.3.3. Log List Coding Rules . . . . . . . . . . . . . . . 51 92 A.3.4. The Parameter System . . . . . . . . . . . . . . . 54 94 A.4. Chapter M: MIDI Parameter System . . . . . . . . . . . . . 56 95 A.4.1. Log Inclusion Rules . . . . . . . . . . . . . . . . 57 96 A.4.2. Log Coding Rules . . . . . . . . . . . . . . . . . 59 97 A.4.2.1. The Value Tool . . . . . . . . . . . . . . . 60 98 A.4.2.2. The Count Tool . . . . . . . . . . . . . . . 64 99 A.5. Chapter W: MIDI Pitch Wheel . . . . . . . . . . . . . . . 65 100 A.6. Chapter N: MIDI NoteOff and NoteOn . . . . . . . . . . . . 66 101 A.6.1. Header Structure . . . . . . . . . . . . . . . . . 67 102 A.6.2. Note Structures . . . . . . . . . . . . . . . . . . 68 103 A.7. Chapter E: MIDI Note Command Extras . . . . . . . . . . . 70 104 A.7.1. Note Log Format . . . . . . . . . . . . . . . . . . 71 105 A.7.2. Log Inclusion Rules . . . . . . . . . . . . . . . . 71 106 A.8. Chapter T: MIDI Channel Aftertouch . . . . . . . . . . . . 72 107 A.9. Chapter A: MIDI Poly Aftertouch . . . . . . . . . . . . . 73 108 B. The Recovery Journal System Chapters . . . . . . . . . . . . . . 75 109 B.1. System Chapter D: Simple System Commands . . . . . . . . . 75 110 B.1.1. Undefined System Commands . . . . . . . . . . 76 111 B.2. System Chapter V: Active Sense Command . . . . . . . . . . 79 112 B.3. System Chapter Q: Sequencer State Commands . . . . . . . . 80 113 B.3.1. Non-compliant Sequencers . . . . . . . . . . . 82 114 B.4. System Chapter F: MIDI Time Code Tape Position . . . . . . 83 115 B.4.1. Partial Frames . . . . . . . . . . . . . . . . . . 85 116 B.5. System Chapter X: System Exclusive . . . . . . . . . . . . 87 117 B.5.1. Chapter Format . . . . . . . . . . . . . . . . 87 118 B.5.2. Log Inclusion Semantics . . . . . . . . . . . 90 119 B.5.3. TCOUNT and COUNT Fields . . . . . . . . . . . 92 120 C. Session Configuration Tools . . . . . . . . . . . . . . . . . . . 94 121 C.1. Configuration Tools: Stream Subsetting . . . . . . . . . . 95 122 C.2. Configuration Tools: The Journalling System . . . . . . . 99 123 C.2.1. The j_sec Parameter . . . . . . . . . . . . . . . . 100 124 C.2.2. The j_update Parameter . . . . . . . . . . . . . . 101 125 C.2.2.1. The anchor Sending Policy . . . . . . . . . 102 126 C.2.2.2. The closed-loop Sending Policy . . . . . . . 102 127 C.2.2.3. The open-loop Sending Policy . . . . . . . . 106 128 C.2.3. Recovery Journal Chapter Inclusion Parameters . . . 108 129 C.3. Configuration Tools: Timestamp Semantics . . . . . . . . . 113 130 C.3.1. The comex Algorithm . . . . . . . . . . . . . . . . 113 131 C.3.2. The async Algorithm . . . . . . . . . . . . . . . . 114 132 C.3.3. The buffer Algorithm . . . . . . . . . . . . . . . 115 133 C.4. Configuration Tools: Packet Timing Tools . . . . . . . . . 117 134 C.4.1. Packet Duration Tools . . . . . . . . . . . . . . . 117 135 C.4.2. The guardtime Parameter . . . . . . . . . . . . . . 118 136 C.5. Configuration Tools: Stream Description . . . . . . . . . 120 137 C.6. Configuration Tools: MIDI Rendering . . . . . . . . . . . 126 138 C.6.1. The multimode Parameter . . . . . . . . . . . . . . 127 139 C.6.2. Renderer Specification . . . . . . . . . . . . . . 127 140 C.6.3. Renderer Initialization . . . . . . . . . . . . . . 130 141 C.6.4. MIDI Channel Mapping . . . . . . . . . . . . . . . 132 142 C.6.4.1. The smf_info Parameter . . . . . . . . . . . 132 143 C.6.4.2. The smf_inline, smf_url, and smf_cid 144 Parameters . . . . . . . . . . . . . . . . . 134 145 C.6.4.3. The chanmask Parameter . . . . . . . . . . . 135 146 C.6.5. The audio/asc Media Type . . . . . . . . . . . . . 136 147 C.7. Interoperability . . . . . . . . . . . . . . . . . . . . . 138 148 C.7.1. MIDI Content Streaming Applications . . . . . . . . 138 149 C.7.2. MIDI Network Musical Performance Applications . . . 141 150 D. Parameter Syntax Definitions . . . . . . . . . . . . . . . . . . 150 151 E. A MIDI Overview for Networking Specialists . . . . . . . . . . . 157 152 E.1. Commands Types . . . . . . . . . . . . . . . . . . . . . . 159 153 E.2. Running Status . . . . . . . . . . . . . . . . . . . . . . 159 154 E.3. Command Timing . . . . . . . . . . . . . . . . . . . . . . 160 155 E.4. AudioSpecificConfig Templates for MMA Renderers . . . . . 160 156 F. Changes from RFC 4695 . . . . . . . . . . . . . . . . . . . . . . 165 157 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168 158 Normative References . . . . . . . . . . . . . . . . . . . . . 168 159 Informative References . . . . . . . . . . . . . . . . . . . . 169 161 1. Introduction 163 The Internet Engineering Task Force (IETF) has developed a set of 164 focused tools for multimedia networking ([RFC3550] [RFC4566] [RFC3261] 165 [RFC2326]). These tools can be combined in different ways to support a 166 variety of real-time applications over Internet Protocol (IP) networks. 168 For example, a telephony application might use the Session Initiation 169 Protocol (SIP, [RFC3261]) to set up a phone call. Call setup would 170 include negotiations to agree on a common audio codec [RFC3264]. 171 Negotiations would use the Session Description Protocol (SDP, [RFC4566]) 172 to describe candidate codecs. 174 After a call is set up, audio data would flow between the parties using 175 the Real Time Protocol (RTP, [RFC3550]) under any applicable profile 176 (for example, the Audio/Visual Profile (AVP, [RFC3551])). The tools 177 used in this telephony example (SIP, SDP, RTP) might be combined in a 178 different way to support a content streaming application, perhaps in 179 conjunction with other tools, such as the Real Time Streaming Protocol 180 (RTSP, [RFC2326]). 182 The MIDI (Musical Instrument Digital Interface) command language [MIDI] 183 is widely used in musical applications that are analogous to the 184 examples described above. On stage and in the recording studio, MIDI is 185 used for the interactive remote control of musical instruments, an 186 application similar in spirit to telephony. On web pages, Standard MIDI 187 Files (SMFs, [MIDI]) rendered using the General MIDI standard [MIDI] 188 provide a low-bandwidth substitute for audio streaming. 190 This memo is motivated by a simple premise: if MIDI performances could 191 be sent as RTP streams that are managed by IETF session tools, a 192 hybridization of the MIDI and IETF application domains may occur. 194 For example, interoperable MIDI networking may foster network music 195 performance applications, in which a group of musicians, located at 196 different physical locations, interact over a network to perform as they 197 would if they were located in the same room [NMP]. As a second example, 198 the streaming community may begin to use MIDI for low- bitrate audio 199 coding, perhaps in conjunction with normative sound synthesis methods 200 [MPEGSA]. 202 To enable MIDI applications to use RTP, this memo defines an RTP payload 203 format and its media type. Sections 2-5 and Appendices A-B define the 204 RTP payload format. Section 6 and Appendices C-D define the media types 205 identifying the payload format, the parameters needed for configuration, 206 and how the parameters are utilized in SDP. 208 Appendix C also includes interoperability guidelines for the example 209 applications described above: network musical performance using SIP 210 (Appendix C.7.2) and content-streaming using RTSP (Appendix C.7.1). 212 Another potential application area for RTP MIDI is MIDI networking for 213 professional audio equipment and electronic musical instruments. We do 214 not offer interoperability guidelines for this application in this memo. 215 However, RTP MIDI has been designed with stage and studio applications 216 in mind, and we expect that efforts to define a stage and studio 217 framework will rely on RTP MIDI for MIDI transport services. 219 Some applications may require MIDI media delivery at a certain service 220 quality level (latency, jitter, packet loss, etc). RTP itself does not 221 provide service guarantees. However, applications may use lower-layer 222 network protocols to configure the quality of the transport services 223 that RTP uses. These protocols may act to reserve network resources for 224 RTP flows [RFC2205] or may simply direct RTP traffic onto a dedicated 225 "media network" in a local installation. Note that RTP and the MIDI 226 payload format do provide tools that applications may use to achieve the 227 best possible real-time performance at a given service level. 229 This memo normatively defines the syntax and semantics of the MIDI 230 payload format. However, this memo does not define algorithms for 231 sending and receiving packets. An ancillary document [RFC4696] provides 232 informative guidance on algorithms. Supplemental information may be 233 found in related conference publications [NMP] [GRAME]. 235 Throughout this memo, the phrase "native stream" refers to a stream that 236 uses the rtp-midi media type. The phrase "mpeg4-generic stream" refers 237 to a stream that uses the mpeg4-generic media type (in mode rtp-midi) to 238 operate in an MPEG 4 environment [RFC3640]. Section 6 describes this 239 distinction in detail. 241 1.1. Terminology 243 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 244 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 245 document are to be interpreted as described in BCP 14, RFC 2119 246 [RFC2119]. 248 1.2. Bitfield Conventions 250 In this document, the packet bitfields that share a common name often 251 have identical semantics. As most of these bitfields appear in 252 Appendices A-B, we define the common bitfield names in Appendix A.1. 254 However, a few of these common names also appear in the main text of 255 this document. For convenience, we list these definitions below: 257 o R flag bit. R flag bits are reserved for future use. Senders 258 MUST set R bits to 0. Receivers MUST ignore R bit values. 260 o LENGTH field. All fields named LENGTH (as distinct from LEN) 261 code the number of octets in the structure that contains it, 262 including the header it resides in and all hierarchical levels 263 below it. If a structure contains a LENGTH field, a receiver 264 MUST use the LENGTH field value to advance past the structure 265 during parsing, rather than use knowledge about the internal 266 format of the structure. 268 2. Packet Format 270 In this section, we introduce the format of RTP MIDI packets. The 271 description includes some background information on RTP, for the benefit 272 of MIDI implementors new to IETF tools. Implementors should consult 273 [RFC3550] for an authoritative description of RTP. 275 This memo assumes that the reader is familiar with MIDI syntax and 276 semantics. Appendix E provides a MIDI overview, at a level of detail 277 sufficient to understand most of this memo. Implementors should consult 278 [MIDI] for an authoritative description of MIDI. 280 The MIDI payload format maps a MIDI command stream (16 voice channels + 281 systems) onto an RTP stream. An RTP media stream is a sequence of 282 logical packets that share a common format. Each packet consists of two 283 parts: the RTP header and the MIDI payload. Figure 1 shows this format 284 (vertical space delineates the header and payload). 286 We describe RTP packets as "logical" packets to highlight the fact that 287 RTP itself is not a network-layer protocol. Instead, RTP packets are 288 mapped onto network protocols (such as unicast UDP, multicast UDP, or 289 TCP) by an application [ALF]. The interleaved mode of the Real Time 290 Streaming Protocol (RTSP, [RFC2326]) is an example of an RTP mapping to 291 TCP transport, as is [RFC4571]. 293 2.1. RTP Header 295 [RFC3550] provides a complete description of the RTP header fields. In 296 this section, we clarify the role of a few RTP header fields for MIDI 297 applications. All fields are coded in network byte order (big- endian). 299 0 1 2 3 300 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 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 | V |P|X| CC |M| PT | Sequence number | 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 | Timestamp | 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 | SSRC | 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 | MIDI command section ... | 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 | Journal section ... | 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 Figure 1 -- Packet format 317 The behavior of the 1-bit M field depends on the media type of the 318 stream. For native streams, the M bit MUST be set to 1 if the MIDI 319 command section has a non-zero LEN field, and MUST be set to 0 320 otherwise. For mpeg4-generic streams, the M bit MUST be set to 1 for 321 all packets (to conform to [RFC3640]). 323 In an RTP MIDI stream, the 16-bit sequence number field is initialized 324 to a randomly chosen value and is incremented by one (modulo 2^16) for 325 each packet sent in the stream. A related quantity, the 32-bit extended 326 packet sequence number, may be computed by tracking rollovers of the 327 16-bit sequence number. Note that different receivers of the same 328 stream may compute different extended packet sequence numbers, depending 329 on when the receiver joined the session. 331 The 32-bit timestamp field sets the base timestamp value for the packet. 332 The payload codes MIDI command timing relative to this value. The 333 timestamp units are set by the clock rate parameter. For example, if 334 the clock rate has a value of 44100 Hz, two packets whose base timestamp 335 values differ by 2 seconds have RTP timestamp fields that differ by 336 88200. 338 Note that the clock rate parameter is not encoded within each RTP MIDI 339 packet. A receiver of an RTP MIDI stream becomes aware of the clock 340 rate as part of the session setup process. For example, if a session 341 management tool uses the Session Description Protocol (SDP, [RFC4566]) 342 to describe a media session, the clock rate parameter is set using the 343 rtpmap attribute. We show examples of session setup in Section 6. 345 For RTP MIDI streams destined to be rendered into audio, the clock rate 346 SHOULD be an audio sample rate of 32 KHz or higher. This recommendation 347 is due to the sensitivity of human musical perception to small timing 348 errors in musical note sequences, and due to the timbral changes that 349 occur when two near-simultaneous MIDI NoteOns are rendered with a 350 different timing than that desired by the content author due to clock 351 rate quantization. RTP MIDI streams that are not destined for audio 352 rendering (such as MIDI streams that control stage lighting) MAY use a 353 lower clock rate but SHOULD use a clock rate high enough to avoid timing 354 artifacts in the application. 356 For RTP MIDI streams destined to be rendered into audio, the clock rate 357 SHOULD be chosen from rates in common use in professional audio 358 applications or in consumer audio distribution. At the time of this 359 writing, these rates include 32 KHz, 44.1 KHz, 48 KHz, 64 KHz, 88.2 KHz, 360 96 KHz, 176.4 KHz, and 192 KHz. If the RTP MIDI session is a part of a 361 synchronized media session that includes another (non-MIDI) RTP audio 362 stream with a clock rate of 32 KHz or higher, the RTP MIDI stream SHOULD 363 use a clock rate that matches the clock rate of the other audio stream. 364 However, if the RTP MIDI stream is destined to be rendered into audio, 365 the RTP MIDI stream SHOULD NOT use a clock rate lower than 32 KHz, even 366 if this second stream has a clock rate less than 32 KHz. 368 Timestamps of consecutive packets do not necessarily increment at a 369 fixed rate, because RTP MIDI packets are not necessarily sent at a fixed 370 rate. The degree of packet transmission regularity reflects the 371 underlying application dynamics. Interactive applications may vary the 372 packet sending rate to track the gestural rate of a human performer, 373 whereas content-streaming applications may send packets at a fixed rate. 375 Therefore, the timestamps for two sequential RTP packets may be 376 identical, or the second packet may have a timestamp arbitrarily larger 377 than the first packet (modulo 2^32). Section 3 places additional 378 restrictions on the RTP timestamps for two sequential RTP packets, as 379 does the guardtime parameter (Appendix C.4.2). 381 We use the term "media time" to denote the temporal duration of the 382 media coded by an RTP packet. The media time coded by a packet is 383 computed by subtracting the last command timestamp in the MIDI command 384 section from the RTP timestamp (modulo 2^32). If the MIDI list of the 385 MIDI command section of a packet is empty, the media time coded by the 386 packet is 0 ms. Appendix C.4.1 discusses media time issues in detail. 388 We now define RTP session semantics, in the context of sessions 389 specified using the session description protocol [RFC4566]. A session 390 description media line ("m=") specifies an RTP session. An RTP session 391 has an independent space of 2^32 synchronization sources. 392 Synchronization source identifiers are coded in the SSRC header field of 393 RTP session packets. The payload types that may appear in the PT header 394 field of RTP session packets are listed at the end of the media line. 396 Several RTP MIDI streams may appear in an RTP session. Each stream is 397 distinguished by a unique SSRC value and has a unique sequence number 398 and RTP timestamp space. Multiple streams in the RTP session may be 399 sent by a single party. Multiple parties may send streams in the RTP 400 session. An RTP MIDI stream encodes data for a single MIDI command name 401 space (16 voice channels + Systems). 403 Streams in an RTP session may use different payload types, or they may 404 use the same payload type. However, each party may send, at most, one 405 RTP MIDI stream for each payload type mapped to an RTP MIDI payload 406 format in an RTP session. Recall that dynamic binding of payload type 407 numbers in [RFC4566] lets a party map many payload type numbers to the 408 RTP MIDI payload format; thus a party may send many RTP MIDI streams in 409 a single RTP session. Pairs of streams (unicast or multicast) that 410 communicate between two parties in an RTP session and that share a 411 payload type have the same association as a MIDI cable pair that cross- 412 connects two devices in a MIDI 1.0 DIN network. 414 The RTP session architecture described above is efficient in its use of 415 network ports, as one RTP session (using a port pair per party) supports 416 the transport of many MIDI name spaces (16 MIDI channels + systems). We 417 define tools for grouping and labelling MIDI name spaces across streams 418 and sessions in Appendix C.5 of this memo. 420 The RTP header timestamps for each stream in an RTP session have 421 separately and randomly chosen initialization values. Receivers use the 422 timing fields encoded in the RTP control protocol (RTCP, [RFC3550]) 423 sender reports to synchronize the streams sent by a party. The SSRC 424 values for each stream in an RTP session are also separately and 425 randomly chosen, as described in [RFC3550]. Receivers use the CNAME 426 field encoded in RTCP sender reports to verify that streams were sent by 427 the same party, and to detect SSRC collisions, as described in 428 [RFC3550]. 430 In some applications, a receiver renders MIDI commands into audio (or 431 into control actions, such as the rewind of a tape deck or the dimming 432 of stage lights). In other applications, a receiver presents a MIDI 433 stream to software programs via an Application Programmer Interface 434 (API). Appendix C.6 defines session configuration tools to specify what 435 receivers should do with a MIDI command stream. 437 If a multimedia session uses different RTP MIDI streams to send 438 different classes of media, the streams MUST be sent over different RTP 439 sessions. For example, if a multimedia session uses one MIDI stream for 440 audio and a second MIDI stream to control a lighting system, the audio 441 and lighting streams MUST be sent over different RTP sessions, each with 442 its own media line. 444 Session description tools defined in Appendix C.5 let a sending party 445 split a single MIDI name space (16 voice channels + systems) over 446 several RTP MIDI streams. Split transport of a MIDI command stream is a 447 delicate task, because correct command stream reconstruction by a 448 receiver depends on exact timing synchronization across the streams. 450 To support split name spaces, we define the following requirements: 452 o A party MUST NOT send several RTP MIDI streams that share a MIDI 453 name space in the same RTP session. Instead, each stream MUST 454 be sent from a different RTP session. 456 o If several RTP MIDI streams sent by a party share a MIDI name 457 space, all streams MUST use the same SSRC value and MUST use the 458 same randomly chosen RTP timestamp initialization value. 460 These rules let a receiver identify streams that share a MIDI name space 461 (by matching SSRC values) and also let a receiver accurately reconstruct 462 the source MIDI command stream (by using RTP timestamps to interleave 463 commands from the two streams). Care MUST be taken by senders to ensure 464 that SSRC changes due to collisions are reflected in both streams. 465 Receivers MUST regularly examine the RTCP CNAME fields associated with 466 the linked streams, to ensure that the assumed link is legitimate and 467 not the result of an SSRC collision by another sender. 469 Except for the special cases described above, a party may send many RTP 470 MIDI streams in the same session. However, it is sometimes advantageous 471 for two RTP MIDI streams to be sent over different RTP sessions. For 472 example, two streams may need different values for RTP session-level 473 attributes (such as the sendonly and recvonly attributes). As a second 474 example, two RTP sessions may be needed to send two unicast streams in a 475 multimedia session that originate on different computers (with different 476 IP numbers). Two RTP sessions are needed in this case because transport 477 addresses are specified on the RTP-session or multimedia-session level, 478 not on a payload type level. 480 On a final note, in some uses of MIDI, parties send bidirectional 481 traffic to conduct transactions (such as file exchange). These commands 482 were designed to work over MIDI 1.0 DIN cable networks may be configured 483 in a multicast topology, which use pure "party-line" signalling. Thus, 484 if a multimedia session ensures a multicast connection between all 485 parties, bidirectional MIDI commands will work without additional 486 support from the RTP MIDI payload format. 488 2.2. MIDI Payload 490 The payload (Figure 1) MUST begin with the MIDI command section. The 491 MIDI command section codes a (possibly empty) list of timestamped MIDI 492 commands, and provides the essential service of the payload format. 494 The payload MAY also contain a journal section. The journal section 495 provides resiliency by coding the recent history of the stream. A flag 496 in the MIDI command section codes the presence of a journal section in 497 the payload. 499 Section 3 defines the MIDI command section. Sections 4-5 and Appendices 500 A-B define the recovery journal, the default format for the journal 501 section. Here, we describe how these payload sections operate in a 502 stream in an RTP session. 504 The journalling method for a stream is set at the start of a session and 505 MUST NOT be changed thereafter. A stream may be set to use the recovery 506 journal, to use an alternative journal format (none are defined in this 507 memo), or not to use a journal. 509 The default journalling method of a stream is inferred from its 510 transport type. Streams that use unreliable transport (such as UDP) 511 default to using the recovery journal. Streams that use reliable 512 transport (such as TCP) default to not using a journal. Appendix C.2.1 513 defines session configuration tools for overriding these defaults. For 514 all types of transport, a sender MUST transmit an RTP packet stream with 515 consecutive sequence numbers (modulo 2^16). 517 If a stream uses the recovery journal, every payload in the stream MUST 518 include a journal section. If a stream does not use journalling, a 519 journal section MUST NOT appear in a stream payload. If a stream uses 520 an alternative journal format, the specification for the journal format 521 defines an inclusion policy. 523 If a stream is sent over UDP transport, the Maximum Transmission Unit 524 (MTU) of the underlying network limits the practical size of the payload 525 section (for example, an Ethernet MTU is 1500 octets), for applications 526 where predictable and minimal packet transmission latency is critical. 527 A sender SHOULD NOT create RTP MIDI UDP packets whose size exceeds the 528 MTU of the underlying network. Instead, the sender SHOULD take steps to 529 keep the maximum packet size under the MTU limit. 531 These steps may take many forms. The default closed-loop recovery 532 journal sending policy (defined in Appendix C.2.2.2) uses RTP control 533 protocol (RTCP, [RFC3550]) feedback to manage the RTP MIDI packet size. 534 In addition, Section 3.2 and Appendix B.5.2 provide specific tools for 535 managing the size of packets that code MIDI System Exclusive (0xF0) 536 commands. Appendix C.5 defines session configuration tools that may be 537 used to split a dense MIDI name space into several UDP streams (each 538 sent in a different RTP session, per Section 2.1) so that the payload 539 fits comfortably into an MTU. Another option is to use TCP. Section 540 4.3 of [RFC4696] provides non-normative advice for packet size 541 management. 543 3. MIDI Command Section 545 Figure 2 shows the format of the MIDI command section. 547 0 1 2 3 548 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 549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 550 |B|J|Z|P|LEN... | MIDI list ... | 551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 553 Figure 2 -- MIDI command section 555 The MIDI command section begins with a variable-length header. 557 The header field LEN codes the number of octets in the MIDI list that 558 follow the header. If the header flag B is 0, the header is one octet 559 long, and LEN is a 4-bit field, supporting a maximum MIDI list length of 560 15 octets. 562 If B is 1, the header is two octets long, and LEN is a 12-bit field, 563 supporting a maximum MIDI list length of 4095 octets. LEN is coded in 564 network byte order (big-endian): the 4 bits of LEN that appear in the 565 first header octet code the most significant 4 bits of the 12-bit LEN 566 value. 568 A LEN value of 0 is legal, and it codes an empty MIDI list. 570 If the J header bit is set to 1, a journal section MUST appear after the 571 MIDI command section in the payload. If the J header bit is set to 0, 572 the payload MUST NOT contain a journal section. 574 We define the semantics of the P header bit in Section 3.2. 576 If the LEN header field is nonzero, the MIDI list has the structure 577 shown in Figure 3. 579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 580 | Delta Time 0 (1-4 octets long, or 0 octets if Z = 0) | 581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 582 | MIDI Command 0 (1 or more octets long) | 583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 584 | Delta Time 1 (1-4 octets long) | 585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 586 | MIDI Command 1 (1 or more octets long) | 587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 588 | ... | 589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 590 | Delta Time N (1-4 octets long) | 591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 592 | MIDI Command N (0 or more octets long) | 593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 595 Figure 3 -- MIDI list structure 597 If the header flag Z is 1, the MIDI list begins with a complete MIDI 598 command (coded in the MIDI Command 0 field, in Figure 3) preceded by a 599 delta time (coded in the Delta Time 0 field). If Z is 0, the Delta Time 600 0 field is not present in the MIDI list, and the command coded in the 601 MIDI Command 0 field has an implicit delta time of 0. 603 The MIDI list structure may also optionally encode a list of N 604 additional complete MIDI commands, each coded in a MIDI Command K field. 605 Each additional command MUST be preceded by a Delta Time K field, which 606 codes the command's delta time. We discuss exceptions to the "command 607 fields code complete MIDI commands" rule in Section 3.2. 609 The final MIDI command field (i.e., the MIDI Command N field, shown in 610 Figure 3) in the MIDI list MAY be empty. Moreover, a MIDI list MAY 611 consist a single delta time (encoded in the Delta Time 0 field) without 612 an associated command (which would have been encoded in the MIDI Command 613 0 field). These rules enable MIDI coding features that are explained in 614 Section 3.1. We delay the explanations because an understanding of RTP 615 MIDI timestamps is necessary to describe the features. 617 3.1. Timestamps 619 In this section, we describe how RTP MIDI encodes a timestamp for each 620 MIDI list command. Command timestamps have the same units as RTP packet 621 header timestamps (described in Section 2.1 and [RFC3550]). Recall that 622 RTP timestamps have units of seconds, whose scaling is set during 623 session configuration (see Section 6.1 and [RFC4566]). 625 As shown in Figure 3, the MIDI list encodes time using a compact delta- 626 time format. The RTP MIDI delta time syntax is a modified form of the 627 MIDI File delta time syntax [MIDI]. RTP MIDI delta times use 1-4 octet 628 fields to encode 32-bit unsigned integers. Figure 4 shows the encoded 629 and decoded forms of delta times. Note that delta time values may be 630 legally encoded in multiple formats; for example, there are four legal 631 ways to encode the zero delta time (0x00, 0x8000, 0x808000, 0x80808000). 633 RTP MIDI uses delta times to encode a timestamp for each MIDI command. 634 The timestamp for MIDI Command K is the summation (modulo 2^32) of the 635 RTP timestamp and decoded delta times 0 through K. This cumulative 636 coding technique, borrowed from MIDI File delta time coding, is 637 efficient because it reduces the number of multi-octet delta times. 639 All command timestamps in a packet MUST be less than or equal to the RTP 640 timestamp of the next packet in the stream (modulo 2^32). 642 This restriction ensures that a particular RTP MIDI packet in a stream 643 is uniquely responsible for encoding time starting at the moment after 644 the RTP timestamp encoded in the RTP packet header, and ending at the 645 moment before the final command timestamp encoded in the MIDI list. The 646 "moment before" and "moment after" qualifiers acknowledge the "less than 647 or equal" semantics (as opposed to "strictly less than") in the sentence 648 above this paragraph. 650 Note that it is possible to "pad" the end of an RTP MIDI packet with 651 time that is guaranteed to be void of MIDI commands, by setting the 652 "Delta Time N" field of the MIDI list to the end of the void time, and 653 by omitting its corresponding "MIDI Command N" field (a syntactic 654 construction the preamble of Section 3 expressly made legal). 656 In addition, it is possible to code an RTP MIDI packet to express that a 657 period of time in the stream is void of MIDI commands. The RTP 658 timestamp in the header would code the start of the void time. The MIDI 659 list of this packet would consist of a "Delta Time 0" field that coded 660 the end of the void time. No other fields would be present in the MIDI 661 list (a syntactic construction the preamble of Section 3 also expressly 662 made legal). 664 By default, a command timestamp indicates the execution time for the 665 command. The difference between two timestamps indicates the time delay 666 between the execution of the commands. This difference may be zero, 667 coding simultaneous execution. In this memo, we refer to this 668 interpretation of timestamps as "comex" (COMmand EXecution) semantics. 669 We formally define comex semantics in Appendix C.3. 671 The comex interpretation of timestamps works well for transcoding a 672 Standard MIDI File (SMF) into an RTP MIDI stream, as SMFs code a 673 timestamp for each MIDI command stored in the file. To transcode an SMF 674 that uses metric time markers, use the SMF tempo map (encoded in the SMF 675 as meta-events) to convert metric SMF timestamp units into seconds-based 676 RTP timestamp units. 678 The comex interpretation also works well for MIDI hardware controllers 679 that are coding raw sensor data directly onto an RTP MIDI stream. Note 680 that this controller design is preferable to a design that converts raw 681 sensor data into a MIDI 1.0 cable command stream and then transcodes the 682 stream onto an RTP MIDI stream. 684 The comex interpretation of timestamps is usually not the best timestamp 685 interpretation for transcoding a MIDI source that uses implicit command 686 timing (such as MIDI 1.0 DIN cables) into an RTP MIDI stream. Appendix 687 C.3 defines alternatives to comex semantics and describes session 688 configuration tools for selecting the timestamp interpretation semantics 689 for a stream. 691 One-Octet Delta Time: 693 Encoded form: 0ddddddd 694 Decoded form: 00000000 00000000 00000000 0ddddddd 696 Two-Octet Delta Time: 698 Encoded form: 1ccccccc 0ddddddd 699 Decoded form: 00000000 00000000 00cccccc cddddddd 701 Three-Octet Delta Time: 703 Encoded form: 1bbbbbbb 1ccccccc 0ddddddd 704 Decoded form: 00000000 000bbbbb bbcccccc cddddddd 706 Four-Octet Delta Time: 708 Encoded form: 1aaaaaaa 1bbbbbbb 1ccccccc 0ddddddd 709 Decoded form: 0000aaaa aaabbbbb bbcccccc cddddddd 711 Figure 4 -- Decoding delta time formats 713 3.2. Command Coding 715 Each non-empty MIDI Command field in the MIDI list codes one of the MIDI 716 command types that may legally appear on a MIDI 1.0 DIN cable. Standard 717 MIDI File meta-events do not fit this definition and MUST NOT appear in 718 the MIDI list. As a rule, each MIDI Command field codes a complete 719 command, in the binary command format defined in [MIDI]. In the 720 remainder of this section, we describe exceptions to this rule. 722 The first MIDI channel command in the MIDI list MUST include a status 723 octet. Running status coding, as defined in [MIDI], MAY be used for all 724 subsequent MIDI channel commands in the list. As in [MIDI], System 725 Common and System Exclusive messages (0xF0 ... 0xF7) cancel the running 726 status state, but System Real-time messages (0xF8 ... 0xFF) do not 727 affect the running status state. All System commands in the MIDI list 728 MUST include a status octet. 730 As we note above, the first channel command in the MIDI list MUST 731 include a status octet. However, the corresponding command in the 732 original MIDI source data stream might not have a status octet (in this 733 case, the source would be coding the command using running status). If 734 the status octet of the first channel command in the MIDI list does not 735 appear in the source data stream, the P (phantom) header bit MUST be set 736 to 1. In all other cases, the P bit MUST be set to 0. 738 Note that the P bit describes the MIDI source data stream, not the MIDI 739 list encoding; regardless of the state of the P bit, the MIDI list MUST 740 include the status octet. 742 As receivers MUST be able to decode running status, sender implementors 743 should feel free to use running status to improve bandwidth efficiency. 744 However, senders SHOULD NOT introduce timing jitter into an existing 745 MIDI command stream through an inappropriate use or removal of running 746 status coding. This warning primarily applies to senders whose RTP MIDI 747 streams may be transcoded onto a MIDI 1.0 DIN cable [MIDI] by the 748 receiver: both the timestamps and the command coding (running status or 749 not) must comply with the physical restrictions of implicit time coding 750 over a slow serial line. 752 On a MIDI 1.0 DIN cable [MIDI], a System Real-time command may be 753 embedded inside of another "host" MIDI command. This syntactic 754 construction is not supported in the payload format: a MIDI Command 755 field in the MIDI list codes exactly one MIDI command (partially or 756 completely). 758 To encode an embedded System Real-time command, senders MUST extract the 759 command from its host and code it in the MIDI list as a separate 760 command. The host command and System Real-time command SHOULD appear in 761 the same MIDI list. The delta time of the System Real-time command 762 SHOULD result in a command timestamp that encodes the System Real-time 763 command placement in its original embedded position. 765 Two methods are provided for encoding MIDI System Exclusive (SysEx) 766 commands in the MIDI list. A SysEx command may be encoded in a MIDI 767 Command field verbatim: a 0xF0 octet, followed by an arbitrary number of 768 data octets, followed by a 0xF7 octet. 770 Alternatively, a SysEx command may be encoded as multiple segments. The 771 command is divided into two or more SysEx command segments; each segment 772 is encoded in its own MIDI Command field in the MIDI list. 774 The payload format supports segmentation in order to encode SysEx 775 commands that encode information in the temporal pattern of data octets. 776 By encoding these commands as a series of segments, each data octet may 777 be associated with a distinct delta time. Segmentation also supports 778 the coding of large SysEx commands across several packets. 780 To segment a SysEx command, first partition its data octet list into two 781 or more sublists. The last sublist MAY be empty (i.e., contain no 782 octets); all other sublists MUST contain at least one data octet. To 783 complete the segmentation, add the status octets defined in Figure 5 to 784 the head and tail of the first, last, and any "middle" sublists. Figure 785 6 shows example segmentations of a SysEx command. 787 A sender MAY cancel a segmented SysEx command transmission that is in 788 progress, by sending the "cancel" sublist shown in Figure 5. A "cancel" 789 sublist MAY follow a "first" or "middle" sublist in the transmission, 790 but MUST NOT follow a "last" sublist. The cancel MUST be empty (thus, 791 0xF7 0xF4 is the only legal cancel sublist). 793 The cancellation feature is needed because Appendix C.1 defines 794 configuration tools that let session parties exclude certain SysEx 795 commands in the stream. Senders that transcode a MIDI source onto an 796 RTP MIDI stream under these constraints have the responsibility of 797 excluding undesired commands from the RTP MIDI stream. 799 The cancellation feature lets a sender start the transmission of a 800 command before the MIDI source has sent the entire command. If a sender 801 determines that the command whose transmission is in progress should not 802 appear on the RTP stream, it cancels the command. Without a method for 803 cancelling a SysEx command transmission, senders would be forced to use 804 a high-latency store-and-forward approach to transcoding SysEx commands 805 onto RTP MIDI packets, in order to validate each SysEx command before 806 transmission. 808 The recommended receiver reaction to a cancellation depends on the 809 capabilities of the receiver. For example, a sound synthesizer that is 810 directly parsing RTP MIDI packets and rendering them to audio will be 811 aware of the fact that SysEx commands may be cancelled in RTP MIDI. 812 These receivers SHOULD detect a SysEx cancellation in the MIDI list and 813 act as if they had never received the SysEx command. 815 As a second example, a synthesizer may be receiving MIDI data from an 816 RTP MIDI stream via a MIDI DIN cable (or a software API emulation of a 817 MIDI DIN cable). In this case, an RTP-MIDI-aware system receives the 818 RTP MIDI stream and transcodes it onto the MIDI DIN cable (or its 819 emulation). Upon the receipt of the cancel sublist, the RTP-MIDI- aware 820 transcoder might have already sent the first part of the SysEx command 821 on the MIDI DIN cable to the receiver. 823 Unfortunately, the MIDI DIN cable protocol cannot directly code "cancel 824 SysEx in progress" semantics. However, MIDI DIN cable receivers begin 825 SysEx processing after the complete command arrives. The receiver 826 checks to see if it recognizes the command (coded in the first few 827 octets) and then checks to see if the command is the correct length. 828 Thus, in practice, a transcoder can cancel a SysEx command by sending an 829 0xF7 to (prematurely) end the SysEx command -- the receiver will detect 830 the incorrect command length and discard the command. 832 Appendix C.1 defines configuration tools that may be used to prohibit 833 SysEx command cancellation. 835 The relative ordering of SysEx command segments in a MIDI list must 836 match the relative ordering of the sublists in the original SysEx 837 command. By default, commands other than System Real-time MIDI commands 838 MUST NOT appear between SysEx command segments (Appendix C.1 defines 839 configuration tools to change this default, to let other commands types 840 appear between segments). If the command segments of a SysEx command 841 are placed in the MIDI lists of two or more RTP packets, the segment 842 ordering rules apply to the concatenation of all affected MIDI lists. 844 ----------------------------------------------------------- 845 | Sublist Position | Head Status Octet | Tail Status Octet | 846 |-----------------------------------------------------------| 847 | first | 0xF0 | 0xF0 | 848 |-----------------------------------------------------------| 849 | middle | 0xF7 | 0xF0 | 850 |-----------------------------------------------------------| 851 | last | 0xF7 | 0xF7 | 852 |-----------------------------------------------------------| 853 | cancel | 0xF7 | 0xF4 | 854 ----------------------------------------------------------- 856 Figure 5 -- Command segmentation status octets 858 [MIDI] permits 0xF7 octets that are not part of a (0xF0, 0xF7) pair to 859 appear on a MIDI 1.0 DIN cable. Unpaired 0xF7 octets have no semantic 860 meaning in MIDI, apart from cancelling running status. 862 Unpaired 0xF7 octets MUST NOT appear in the MIDI list of the MIDI 863 Command section. We impose this restriction to avoid interference with 864 the command segmentation coding defined in Figure 5. 866 SysEx commands carried on a MIDI 1.0 DIN cable may use the "dropped 867 0xF7" construction [MIDI]. In this coding method, the 0xF7 octet is 868 dropped from the end of the SysEx command, and the status octet of the 869 next MIDI command acts both to terminate the SysEx command and start the 870 next command. To encode this construction in the payload format, follow 871 these steps: 873 o Determine the appropriate delta times for the SysEx command and 874 the command that follows the SysEx command. 876 o Insert the "dropped" 0xF7 octet at the end of the SysEx command, 877 to form the standard SysEx syntax. 879 o Code both commands into the MIDI list using the rules above. 881 o Replace the 0xF7 octet that terminates the verbatim SysEx 882 encoding or the last segment of the segmented SysEx encoding 883 with a 0xF5 octet. This substitution informs the receiver 884 of the original dropped 0xF7 coding. 886 [MIDI] reserves the undefined System Common commands 0xF4 and 0xF5 and 887 the undefined System Real-time commands 0xF9 and 0xFD for future use. 888 By default, undefined commands MUST NOT appear in a MIDI Command field 889 in the MIDI list, with the exception of the 0xF5 octets used to code the 890 "dropped 0xF7" construction and the 0xF4 octets used by SysEx "cancel" 891 sublists. 893 During session configuration, a stream may be customized to transport 894 undefined commands (Appendix C.1). For this case, we now define how 895 senders encode undefined commands in the MIDI list. 897 An undefined System Real-time command MUST be coded using the System 898 Real-time rules. 900 If the undefined System Common commands are put to use in a future 901 version of [MIDI], the command will begin with an 0xF4 or 0xF5 status 902 octet, followed by an arbitrary number of data octets (i.e., zero or 903 more data bytes). To encode these commands, senders MUST terminate the 904 command with an 0xF7 octet and place the modified command into the MIDI 905 Command field. 907 Unfortunately, non-compliant uses of the undefined System Common 908 commands may appear in MIDI implementations. To model these commands, 909 we assume that the command begins with an 0xF4 or 0xF5 status octet, 910 followed by zero or more data octets, followed by zero or more trailing 911 0xF7 status octets. To encode the command, senders MUST first remove 912 all trailing 0xF7 status octets from the command. Then, senders MUST 913 terminate the command with an 0xF7 octet and place the modified command 914 into the MIDI Command field. 916 Note that we include the trailing octets in our model as a cautionary 917 measure: if such commands appeared in a non-compliant use of an 918 undefined System Common command, an RTP MIDI encoding of the command 919 that did not remove trailing octets could be mistaken for an encoding of 920 "middle" or "last" sublist of a segmented SysEx commands (Figure 5) 921 under certain packet loss conditions. 923 Original SysEx command: 925 0xF0 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0xF7 927 A two-segment segmentation: 929 0xF0 0x01 0x02 0x03 0x04 0xF0 931 0xF7 0x05 0x06 0x07 0x08 0xF7 933 A different two-segment segmentation: 935 0xF0 0x01 0xF0 937 0xF7 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0xF7 939 A three-segment segmentation: 941 0xF0 0x01 0x02 0xF0 943 0xF7 0x03 0x04 0xF0 945 0xF7 0x05 0x06 0x07 0x08 0xF7 947 The segmentation with the largest number of segments: 949 0xF0 0x01 0xF0 951 0xF7 0x02 0xF0 953 0xF7 0x03 0xF0 955 0xF7 0x04 0xF0 957 0xF7 0x05 0xF0 959 0xF7 0x06 0xF0 961 0xF7 0x07 0xF0 963 0xF7 0x08 0xF0 965 0xF7 0xF7 967 Figure 6 -- Example segmentations 969 4. The Recovery Journal System 971 The recovery journal is the default resiliency tool for unreliable 972 transport. In this section, we normatively define the roles that 973 senders and receivers play in the recovery journal system. 975 MIDI is a fragile code. A single lost command in a MIDI command stream 976 may produce an artifact in the rendered performance. We normatively 977 classify rendering artifacts into two categories: 979 o Transient artifacts. Transient artifacts produce immediate 980 but short-term glitches in the performance. For example, a lost 981 NoteOn (0x9) command produces a transient artifact: one note 982 fails to play, but the artifact does not extend beyond the end 983 of that note. 985 o Indefinite artifacts. Indefinite artifacts produce long-lasting 986 errors in the rendered performance. For example, a lost NoteOff 987 (0x8) command may produce an indefinite artifact: the note that 988 should have been ended by the lost NoteOff command may sustain 989 indefinitely. As a second example, the loss of a Control Change 990 (0xB) command for controller number 7 (Channel Volume) may 991 produce an indefinite artifact: after the loss, all notes on 992 the channel may play too softly or too loudly. 994 The purpose of the recovery journal system is to satisfy the recovery 995 journal mandate: the MIDI performance rendered from an RTP MIDI stream 996 sent over unreliable transport MUST NOT contain indefinite artifacts. 998 The recovery journal system does not use packet retransmission to 999 satisfy this mandate. Instead, each packet includes a special section, 1000 called the recovery journal. 1002 The recovery journal codes the history of the stream, back to an earlier 1003 packet called the checkpoint packet. The range of coverage for the 1004 journal is called the checkpoint history. The recovery journal codes 1005 the information necessary to recover from the loss of an arbitrary 1006 number of packets in the checkpoint history. Appendix A.1 normatively 1007 defines the checkpoint packet and the checkpoint history. 1009 When a receiver detects a packet loss, it compares its own knowledge 1010 about the history of the stream with the history information coded in 1011 the recovery journal of the packet that ends the loss event. By noting 1012 the differences in these two versions of the past, a receiver is able to 1013 transform all indefinite artifacts in the rendered performance into 1014 transient artifacts, by executing MIDI commands to repair the stream. 1016 We now state the normative role for senders in the recovery journal 1017 system. 1019 Senders prepare a recovery journal for every packet in the stream. In 1020 doing so, senders choose the checkpoint packet identity for the journal. 1021 Senders make this choice by applying a sending policy. Appendix C.2.2 1022 normatively defines three sending policies: "closed- loop", "open-loop", 1023 and "anchor". 1025 By default, senders MUST use the closed-loop sending policy. If the 1026 session description overrides this default policy, by using the 1027 parameter j_update defined in Appendix C.2.2, senders MUST use the 1028 specified policy. 1030 After choosing the checkpoint packet identity for a packet, the sender 1031 creates the recovery journal. By default, this journal MUST conform to 1032 the normative semantics in Section 5 and Appendices A-B in this memo. 1033 In Appendix C.2.3, we define parameters that modify the normative 1034 semantics for recovery journals. If the session description uses these 1035 parameters, the journal created by the sender MUST conform to the 1036 modified semantics. 1038 Next, we state the normative role for receivers in the recovery journal 1039 system. 1041 A receiver MUST detect each RTP sequence number break in a stream. If 1042 the sequence number break is due to a packet loss event (as defined in 1043 [RFC3550]), the receiver MUST repair all indefinite artifacts in the 1044 rendered MIDI performance caused by the loss. If the sequence number 1045 break is due to an out-of-order packet (as defined in [RFC3550]), the 1046 receiver MUST NOT take actions that introduce indefinite artifacts 1047 (ignoring the out-of-order packet is a safe option). 1049 Receivers take special precautions when entering or exiting a session. 1050 A receiver MUST process the first received packet in a stream as if it 1051 were a packet that ends a loss event. Upon exiting a session, a 1052 receiver MUST ensure that the rendered MIDI performance does not end 1053 with indefinite artifacts. 1055 Receivers are under no obligation to perform indefinite artifact repairs 1056 at the moment a packet arrives. A receiver that uses a playout buffer 1057 may choose to wait until the moment of rendering before processing the 1058 recovery journal, as the "lost" packet may be a late packet that arrives 1059 in time to use. 1061 Next, we state the normative role for the creator of the session 1062 description in the recovery journal system. Depending on the 1063 application, the sender, the receivers, and other parties may take part 1064 in creating or approving the session description. 1066 A session description that specifies the default closed-loop sending 1067 policy and the default recovery journal semantics satisfies the recovery 1068 journal mandate. However, these default behaviors may not be 1069 appropriate for all sessions. If the creators of a session description 1070 use the parameters defined in Appendix C.2 to override these defaults, 1071 the creators MUST ensure that the parameters define a system that 1072 satisfies the recovery journal mandate. 1074 Finally, we note that this memo does not specify sender or receiver 1075 recovery journal algorithms. Implementations are free to use any 1076 algorithm that conforms to the requirements in this section. The non- 1077 normative [RFC4696] discusses sender and receiver algorithm design. 1079 5. Recovery Journal Format 1081 This section introduces the structure of the recovery journal and 1082 defines the bitfields of recovery journal headers. Appendices A-B 1083 complete the bitfield definition of the recovery journal. 1085 The recovery journal has a three-level structure: 1087 o Top-level header. 1089 o Channel and system journal headers. These headers encode 1090 recovery information for a single voice channel (channel 1091 journal) or for all systems commands (system journal). 1093 o Chapters. Chapters describe recovery information for a 1094 single MIDI command type. 1096 Figure 7 shows the top-level structure of the recovery journal. The 1097 recovery journals consists of a 3-octet header, followed by an optional 1098 system journal (labeled S-journal in Figure 7) and an optional list of 1099 channel journals. Figure 8 shows the recovery journal header format. 1101 0 1 2 3 1102 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 1103 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1104 | Recovery journal header | S-journal ... | 1105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1106 | Channel journals ... | 1107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1109 Figure 7 -- Top-level recovery journal format 1111 0 1 2 1112 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 1113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1114 |S|Y|A|H|TOTCHAN| Checkpoint Packet Seqnum | 1115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1117 Figure 8 -- Recovery journal header 1119 If the Y header bit is set to 1, the system journal appears in the 1120 recovery journal, directly following the recovery journal header. 1122 If the A header bit is set to 1, the recovery journal ends with a list 1123 of (TOTCHAN + 1) channel journals (the 4-bit TOTCHAN header field is 1124 interpreted as an unsigned integer). 1126 A MIDI channel MAY be represented by (at most) one channel journal in a 1127 recovery journal. Channel journals MUST appear in the recovery journal 1128 in ascending channel-number order. 1130 If A and Y are both zero, the recovery journal only contains its 3- 1131 octet header and is considered to be an "empty" journal. 1133 The S (single-packet loss) bit appears in most recovery journal 1134 structures, including the recovery journal header. The S bit helps 1135 receivers efficiently parse the recovery journal in the common case of 1136 the loss of a single packet. Appendix A.1 defines S bit semantics. 1138 The H bit indicates if MIDI channels in the stream have been configured 1139 to use the enhanced Chapter C encoding (Appendix A.3.3). 1141 By default, the payload format does not use enhanced Chapter C encoding. 1142 In this default case, the H bit MUST be set to 0 for all packets in the 1143 stream. 1145 If the stream has been configured so that controller numbers for one or 1146 more MIDI channels use enhanced Chapter C encoding, the H bit MUST be 1147 set to 1 in all packets in the stream. In Appendix C.2.3, we show how 1148 to configure a stream to use enhanced Chapter C encoding. 1150 The 16-bit Checkpoint Packet Seqnum header field codes the sequence 1151 number of the checkpoint packet for this journal, in network byte order 1152 (big-endian). The choice of the checkpoint packet sets the depth of the 1153 checkpoint history for the journal (defined in Appendix A.1). 1155 Receivers may use the Checkpoint Packet Seqnum field of the packet that 1156 ends a loss event to verify that the journal checkpoint history covers 1157 the entire loss event. The checkpoint history covers the loss event if 1158 the Checkpoint Packet Seqnum field is less than or equal to one plus the 1159 highest RTP sequence number previously received on the stream (modulo 1160 2^16). 1162 0 1 2 3 1163 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 1164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1165 |S| CHAN |H| LENGTH |P|C|M|W|N|E|T|A| Chapters ... | 1166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1168 Figure 9 -- Channel journal format 1170 Figure 9 shows the structure of a channel journal: a 3-octet header, 1171 followed by a list of leaf elements called channel chapters. A channel 1172 journal encodes information about MIDI commands on the MIDI channel 1173 coded by the 4-bit CHAN header field. Note that CHAN uses the same bit 1174 encoding as the channel nibble in MIDI Channel Messages (the cccc field 1175 in Figure E.1 of Appendix E). 1177 The 10-bit LENGTH field codes the length of the channel journal. The 1178 semantics for LENGTH fields are uniform throughout the recovery journal, 1179 and are defined in Appendix A.1. 1181 The third octet of the channel journal header is the Table of Contents 1182 (TOC) of the channel journal. The TOC is a set of bits that encode the 1183 presence of a chapter in the journal. Each chapter contains information 1184 about a certain class of MIDI channel command: 1186 o Chapter P: MIDI Program Change (0xC) 1187 o Chapter C: MIDI Control Change (0xB) 1188 o Chapter M: MIDI Parameter System (part of 0xB) 1189 o Chapter W: MIDI Pitch Wheel (0xE) 1190 o Chapter N: MIDI NoteOff (0x8), NoteOn (0x9) 1191 o Chapter E: MIDI Note Command Extras (0x8, 0x9) 1192 o Chapter T: MIDI Channel Aftertouch (0xD) 1193 o Chapter A: MIDI Poly Aftertouch (0xA) 1195 Chapters appear in a list following the header, in order of their 1196 appearance in the TOC. Appendices A.2-9 describe the bitfield format 1197 for each chapter, and define the conditions under which a chapter type 1198 MUST appear in the recovery journal. If any chapter types are required 1199 for a channel, an associated channel journal MUST appear in the recovery 1200 journal. 1202 The H bit indicates if controller numbers on a MIDI channel have been 1203 configured to use the enhanced Chapter C encoding (Appendix A.3.3). 1205 By default, controller numbers on a MIDI channel do not use enhanced 1206 Chapter C encoding. In this default case, the H bit MUST be set to 0 1207 for all channel journal headers for the channel in the recovery journal, 1208 for all packets in the stream. 1210 However, if at least one controller number for a MIDI channel has been 1211 configured to use the enhanced Chapter C encoding, the H bit for its 1212 channel journal MUST be set to 1, for all packets in the stream. 1214 In Appendix C.2.3, we show how to configure a controller number to use 1215 enhanced Chapter C encoding. 1217 0 1 2 3 1218 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 1219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1220 |S|D|V|Q|F|X| LENGTH | System chapters ... | 1221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1223 Figure 10 -- System journal format 1225 Figure 10 shows the structure of the system journal: a 2-octet header, 1226 followed by a list of system chapters. Each chapter codes information 1227 about a specific class of MIDI Systems command: 1229 o Chapter D: Song Select (0xF3), Tune Request (0xF6), Reset (0xFF), 1230 undefined System commands (0xF4, 0xF5, 0xF9, 0xFD) 1231 o Chapter V: Active Sense (0xFE) 1232 o Chapter Q: Sequencer State (0xF2, 0xF8, 0xF9, 0xFA, 0xFB, 0xFC) 1233 o Chapter F: MTC Tape Position (0xF1, 0xF0 0x7F 0xcc 0x01 0x01) 1234 o Chapter X: System Exclusive (all other 0xF0) 1236 The 10-bit LENGTH field codes the size of the system journal and 1237 conforms to semantics described in Appendix A.1. 1239 The D, V, Q, F, and X header bits form a Table of Contents (TOC) for the 1240 system journal. A TOC bit that is set to 1 codes the presence of a 1241 chapter in the journal. Chapters appear in a list following the header, 1242 in the order of their appearance in the TOC. 1244 Appendix B describes the bitfield format for the system chapters and 1245 defines the conditions under which a chapter type MUST appear in the 1246 recovery journal. If any system chapter type is required to appear in 1247 the recovery journal, the system journal MUST appear in the recovery 1248 journal. 1250 6. Session Description Protocol 1252 RTP does not perform session management. Instead, RTP works together 1253 with session management tools, such as the Session Initiation Protocol 1254 (SIP, [RFC3261]) and the Real Time Streaming Protocol (RTSP, [RFC2326]). 1256 RTP payload formats define media type parameters for use in session 1257 management (for example, this memo defines "rtp-midi" as the media type 1258 for native RTP MIDI streams). 1260 In most cases, session management tools use the media type parameters 1261 via another standard, the Session Description Protocol (SDP, [RFC4566]). 1263 SDP is a textual format for specifying session descriptions. Session 1264 descriptions specify the network transport and media encoding for RTP 1265 sessions. Session management tools coordinate the exchange of session 1266 descriptions between participants ("parties"). 1268 Some session management tools use SDP to negotiate details of media 1269 transport (network addresses, ports, etc.). We refer to this use of SDP 1270 as "negotiated usage". One example of negotiated usage is the 1271 Offer/Answer protocol ([RFC3264] and Appendix C.7.2 in this memo) as 1272 used by SIP. 1274 Other session management tools use SDP to declare the media encoding for 1275 the session but use other techniques to negotiate network transport. We 1276 refer to this use of SDP as "declarative usage". One example of 1277 declarative usage is RTSP ([RFC2326] and Appendix C.7.1 in this memo). 1279 Below, we show session description examples for native (Section 6.1) and 1280 mpeg4-generic (Section 6.2) streams. In Section 6.3, we introduce 1281 session configuration tools that may be used to customize streams. 1283 6.1. Session Descriptions for Native Streams 1285 The session description below defines a unicast UDP RTP session (via a 1286 media ("m=") line) whose sole payload type (96) is mapped to a minimal 1287 native RTP MIDI stream. 1289 v=0 1290 o=lazzaro 2520644554 2838152170 IN IP4 first.example.net 1291 s=Example 1292 t=0 0 1293 m=audio 5004 RTP/AVP 96 1294 c=IN IP4 192.0.2.94 1295 a=rtpmap:96 rtp-midi/44100 1297 The rtpmap attribute line uses the "rtp-midi" media type to specify an 1298 RTP MIDI native stream. The clock rate specified on the rtpmap line (in 1299 the example above, 44100 Hz) sets the scaling for the RTP timestamp 1300 header field (see Section 2.1, and also [RFC3550]). 1302 Note that this document does not specify a default clock rate value for 1303 RTP MIDI. When RTP MIDI is used with SDP, parties MUST use the rtpmap 1304 line to communicate the clock rate. Guidance for selecting the RTP MIDI 1305 clock rate value appears in Section 2.1. 1307 We consider the RTP MIDI stream shown above to be "minimal" because the 1308 session description does not customize the stream with parameters. 1309 Without such customization, a native RTP MIDI stream has these 1310 characteristics: 1312 1. If the stream uses unreliable transport (unicast UDP, multicast 1313 UDP, etc.), the recovery journal system is in use, and the RTP 1314 payload contains both the MIDI command section and the journal 1315 section. If the stream uses reliable transport (such as TCP), 1316 the stream does not use journalling, and the payload contains 1317 only the MIDI command section (Section 2.2). 1319 2. If the stream uses the recovery journal system, the recovery 1320 journal system uses the default sending policy and the default 1321 journal semantics (Section 4). 1323 3. In the MIDI command section of the payload, command timestamps 1324 use the default "comex" semantics (Section 3). 1326 4. The recommended temporal duration ("media time") of an RTP 1327 packet ranges from 0 to 200 ms, and the RTP timestamp 1328 difference between sequential packets in the stream may be 1329 arbitrarily large (Section 2.1). 1331 5. If more than one minimal rtp-midi stream appears in a session, 1332 the MIDI name spaces for these streams are independent: channel 1333 1 in the first stream does not reference the same MIDI channel 1334 as channel 1 in the second stream (see Appendix C.5 for a 1335 discussion of the independence of minimal rtp-midi streams). 1337 6. The rendering method for the stream is not specified. What the 1338 receiver "does" with a minimal native MIDI stream is "out of 1339 scope" of this memo. For example, in content creation 1340 environments, a user may manually configure client software to 1341 render the stream with a specific software package. 1343 As in standard in RTP, RTP sessions managed by SIP are sendrecv by 1344 default (parties send and receive MIDI), and RTP sessions managed by 1345 RTSP are recvonly by default (server sends and client receives). 1347 In sendrecv RTP MIDI sessions for the session description shown above, 1348 the 16 voice channel + systems MIDI name space is unique for each 1349 sender. Thus, in a two-party session, the voice channel 0 sent by one 1350 party is distinct from the voice channel 0 sent by the other party. 1352 This behavior corresponds to what occurs when two MIDI 1.0 DIN devices 1353 are cross-connected with two MIDI cables (one cable routing MIDI Out 1354 from the first device into MIDI In of the second device, a second cable 1355 routing MIDI In from the first device into MIDI Out of the second 1356 device). We define this "association" formally in Section 2.1. 1358 MIDI 1.0 DIN networks may be configured in a "party-line" multicast 1359 topology. For these networks, the MIDI protocol itself provides tools 1360 for addressing specific devices in transactions on a multicast network, 1361 and for device discovery. Thus, apart from providing a 1- to-many 1362 forward path and a many-to-1 reverse path, IETF protocols do not need to 1363 provide any special support for MIDI multicast networking. 1365 6.2. Session Descriptions for mpeg4-generic Streams 1367 An mpeg4-generic [RFC3640] RTP MIDI stream uses an MPEG 4 Audio Object 1368 Type to render MIDI into audio. Three Audio Object Types accept MIDI 1369 input: 1371 o General MIDI (Audio Object Type ID 15), based on the General 1372 MIDI rendering standard [MIDI]. 1374 o Wavetable Synthesis (Audio Object Type ID 14), based on the 1375 Downloadable Sounds Level 2 (DLS 2) rendering standard [DLS2]. 1377 o Main Synthetic (Audio Object Type ID 13), based on Structured 1378 Audio and the programming language SAOL [MPEGSA]. 1380 The primary service of an mpeg4-generic stream is to code Access Units 1381 (AUs). We define the mpeg4-generic RTP MIDI AU as the MIDI payload 1382 shown in Figure 1 of Section 2.1 of this memo: a MIDI command section 1383 optionally followed by a journal section. 1385 Exactly one RTP MIDI AU MUST be mapped to one mpeg4-generic RTP MIDI 1386 packet. The mpeg4-generic options for placing several AUs in an RTP 1387 packet MUST NOT be used with RTP MIDI. The mpeg4-generic options for 1388 fragmenting and interleaving AUs MUST NOT be used with RTP MIDI. The 1389 mpeg4-generic RTP packet payload (Figure 1 in [RFC3640]) MUST contain 1390 empty AU Header and Auxiliary sections. These rules yield mpeg4-generic 1391 packets that are structurally identical to native RTP MIDI packets, an 1392 essential property for the correct operation of the payload format. 1394 The session description that follows defines a unicast UDP RTP session 1395 (via a media ("m=") line) whose sole payload type (96) is mapped to a 1396 minimal mpeg4-generic RTP MIDI stream. This example uses the General 1397 MIDI Audio Object Type under Synthesis Profile @ Level 2. 1399 v=0 1400 o=lazzaro 2520644554 2838152170 IN IP6 first.example.net 1401 s=Example 1402 t=0 0 1403 m=audio 5004 RTP/AVP 96 1404 c=IN IP6 2001:DB80::7F2E:172A:1E24 1405 a=rtpmap:96 mpeg4-generic/44100 1406 a=fmtp:96 streamtype=5; mode=rtp-midi; profile-level-id=12; 1407 config=7A0A0000001A4D546864000000060000000100604D54726B0000 1408 000600FF2F000 1410 (The a=fmtp line has been wrapped to fit the page to accommodate memo 1411 formatting restrictions; it comprises a single line in SDP.) 1413 The fmtp attribute line codes the four parameters (streamtype, mode, 1414 profile-level-id, and config) that are required in all mpeg4-generic 1415 session descriptions [RFC3640]. For RTP MIDI streams, the streamtype 1416 parameter MUST be set to 5, the "mode" parameter MUST be set to "rtp- 1417 midi", and the "profile-level-id" parameter MUST be set to the MPEG-4 1418 Profile Level for the stream. For the Synthesis Profile, legal profile- 1419 level-id values are 11, 12, and 13, coding low (11), medium (12), or 1420 high (13) decoder computational complexity, as defined by MPEG 1421 conformance tests. 1423 In a minimal RTP MIDI session description, the config value MUST be a 1424 hexadecimal encoding [RFC3640] of the AudioSpecificConfig data block 1425 [MPEGAUDIO] for the stream. AudioSpecificConfig encodes the Audio 1426 Object Type for the stream and also encodes initialization data (SAOL 1427 programs, DLS 2 wave tables, etc.). Standard MIDI Files encoded in 1428 AudioSpecificConfig in a minimal session description MUST be ignored by 1429 the receiver. 1431 Receivers determine the rendering algorithm for the session by 1432 interpreting the first 5 bits of AudioSpecificConfig as an unsigned 1433 integer that codes the Audio Object Type. In our example above, the 1434 leading config string nibbles "7A" yield the Audio Object Type 15 1435 (General MIDI). In Appendix E.4, we derive the config string value in 1436 the session description shown above; the starting point of the 1437 derivation is the MPEG bitstreams defined in [MPEGSA] and [MPEGAUDIO]. 1439 We consider the stream to be "minimal" because the session description 1440 does not customize the stream through the use of parameters, other than 1441 the 4 required mpeg4-generic parameters described above. In Section 1442 6.1, we describe the behavior of a minimal native stream, as a numbered 1443 list of characteristics. Items 1-4 on that list also describe the 1444 minimal mpeg4-generic stream, but items 5 and 6 require restatements, as 1445 listed below: 1447 5. If more than one minimal mpeg4-generic stream appears in 1448 a session, each stream uses an independent instance of the 1449 Audio Object Type coded in the config parameter value. 1451 6. A minimal mpeg4-generic stream encodes the AudioSpecificConfig 1452 as an inline hexadecimal constant. If a session description 1453 is sent over UDP, it may be impossible to transport large 1454 AudioSpecificConfig blocks within the Maximum Transmission Size 1455 (MTU) of the underlying network (for Ethernet, the MTU is 1500 1456 octets). In some cases, the AudioSpecificConfig block may 1457 exceed the maximum size of the UDP packet itself. 1459 The comments in Section 6.1 on SIP and RTSP stream directional defaults, 1460 sendrecv MIDI channel usage, and MIDI 1.0 DIN multicast networks also 1461 apply to mpeg4-generic RTP MIDI sessions. 1463 In sendrecv sessions, each party's session description MUST use 1464 identical values for the mpeg4-generic parameters (including the 1465 required streamtype, mode, profile-level-id, and config parameters). As 1466 a consequence, each party uses an identically configured MPEG 4 Audio 1467 Object Type to render MIDI commands into audio. The preamble to 1468 Appendix C discusses a way to create "virtual sendrecv" sessions that do 1469 not have this restriction. 1471 6.3. Parameters 1473 This section introduces parameters for session configuration for RTP 1474 MIDI streams. In session descriptions, parameters modify the semantics 1475 of a payload type. Parameters are specified on an fmtp attribute line. 1476 See the session description example in Section 6.2 for an example of a 1477 fmtp attribute line. 1479 The parameters add features to the minimal streams described in Sections 1480 6.1-2, and support several types of services: 1482 o Stream subsetting. By default, all MIDI commands that 1483 are legal to appear on a MIDI 1.0 DIN cable may appear 1484 in an RTP MIDI stream. The cm_unused parameter overrides 1485 this default by prohibiting certain commands from appearing 1486 in the stream. The cm_used parameter is used in conjunction 1487 with cm_unused, to simplify the specification of complex 1488 exclusion rules. We describe cm_unused and cm_used in 1489 Appendix C.1. 1491 o Journal customization. The j_sec and j_update parameters 1492 configure the use of the journal section. The ch_default, 1493 ch_never, and ch_anchor parameters configure the semantics 1494 of the recovery journal chapters. These parameters are 1495 described in Appendix C.2 and override the default stream 1496 behaviors 1 and 2, listed in Section 6.1 and referenced in 1497 Section 6.2. 1499 o MIDI command timestamp semantics. The tsmode, octpos, 1500 mperiod, and linerate parameters customize the semantics 1501 of timestamps in the MIDI command section. These parameters 1502 let RTP MIDI accurately encode the implicit time coding of 1503 MIDI 1.0 DIN cables. These parameters are described in 1504 Appendix C.3 and override default stream behavior 3, 1505 listed in Section 6.1 and referenced in Section 6.2 1507 o Media time. The rtp_ptime and rtp_maxptime parameters define 1508 the temporal duration ("media time") of an RTP MIDI packet. 1509 The guardtime parameter sets the minimum sending rate of stream 1510 packets. These parameters are described in Appendix C.4 1511 and override default stream behavior 4, listed in Section 6.1 1512 and referenced in Section 6.2. 1514 o Stream description. The musicport parameter labels the 1515 MIDI name space of RTP streams in a multimedia session. 1516 Musicport is described in Appendix C.5. The musicport 1517 parameter overrides default stream behavior 5, in Sections 1518 6.1 and 6.2. 1520 o MIDI rendering. Several parameters specify the MIDI 1521 rendering method of a stream. These parameters are described 1522 in Appendix C.6 and override default stream behavior 6, in 1523 Sections 6.1 and 6.2. 1525 In Appendix C.7, we specify interoperability guidelines for two RTP MIDI 1526 application areas: content-streaming using RTSP (Appendix C.7.1) and 1527 network musical performance using SIP (Appendix C.7.2). 1529 7. Extensibility 1531 The payload format defined in this memo exclusively encodes all commands 1532 that may legally appear on a MIDI 1.0 DIN cable. 1534 Many worthy uses of MIDI over RTP do not fall within the narrow scope of 1535 the payload format. For example, the payload format does not support 1536 the direct transport of Standard MIDI File (SMF) meta-event and metric 1537 timing data. As a second example, the payload format does not define 1538 transport tools for user-defined commands (apart from tools to support 1539 System Exclusive commands [MIDI]). 1541 The payload format does not provide an extension mechanism to support 1542 new features of this nature, by design. Instead, we encourage the 1543 development of new payload formats for specialized musical applications. 1544 The IETF session management tools [RFC3264] [RFC2326] support codec 1545 negotiation, to facilitate the use of new payload formats in a backward- 1546 compatible way. 1548 However, the payload format does provide several extensibility tools, 1549 which we list below: 1551 o Journalling. As described in Appendix C.2, new token 1552 values for the j_sec and j_update parameters may 1553 be defined in IETF standards-track documents. This 1554 mechanism supports the design of new journal formats 1555 and the definition of new journal sending policies. 1557 o Rendering. The payload format may be extended to support 1558 new MIDI renderers (Appendix C.6.2). Certain general aspects 1559 of the RTP MIDI rendering process may also be extended, via 1560 the definition of new token values for the render (Appendix C.6) 1561 and smf_info (Appendix C.6.4.1) parameters. 1563 o Undefined commands. [MIDI] reserves 4 MIDI System commands 1564 for future use (0xF4, 0xF5, 0xF9, 0xFD). If updates 1565 to [MIDI] define the reserved commands, IETF standards-track 1566 documents may be defined to provide resiliency support for 1567 the commands. Opaque LEGAL fields appear in System Chapter 1568 D for this purpose (Appendix B.1.1). 1570 A final form of extensibility involves the inclusion of the payload 1571 format in framework documents. Framework documents describe how to 1572 combine protocols to form a platform for interoperable applications. 1573 For example, a stage and studio framework might define how to use SIP 1574 [RFC3261], RTSP [RFC2326], SDP [RFC4566], and RTP [RFC3550] to support 1575 media networking for professional audio equipment and electronic musical 1576 instruments. 1578 8. Congestion Control 1580 The RTP congestion control requirements defined in [RFC3550] apply to 1581 RTP MIDI sessions, and implementors should carefully read the congestion 1582 control section in [RFC3550]. As noted in [RFC3550], all transport 1583 protocols used on the Internet need to address congestion control in 1584 some way, and RTP is not an exception. 1586 In addition, the congestion control requirements defined in [RFC3551] 1587 applies to RTP MIDI sessions run under applicable profiles. The basic 1588 congestion control requirement defined in [RFC3551] is that RTP sessions 1589 that use UDP transport should monitor packet loss (via RTCP or other 1590 means) to ensure that the RTP stream competes fairly with TCP flows that 1591 share the network. 1593 Finally, RTP MIDI has congestion control issues that are unique for an 1594 audio RTP payload format. In applications such as network musical 1595 performance [NMP], the packet rate is linked to the gestural rate of a 1596 human performer. Senders MUST monitor the MIDI command source for 1597 patterns that result in excessive packet rates and take actions during 1598 RTP transcoding to reduce the RTP packet rate. [RFC4696] offers 1599 implementation guidance on this issue. 1601 9. Security Considerations 1603 Implementors should carefully read the Security Considerations sections 1604 of the RTP [RFC3550], AVP [RFC3551], and other RTP profile documents, as 1605 the issues discussed in these sections directly apply to RTP MIDI 1606 streams. Implementors should also review the Secure Real-time Transport 1607 Protocol (SRTP, [RFC3711]), an RTP profile that addresses the security 1608 issues discussed in [RFC3550] and [RFC3551]. 1610 Here, we discuss security issues that are unique to the RTP MIDI payload 1611 format. 1613 When using RTP MIDI, authentication of incoming RTP and RTCP packets is 1614 RECOMMENDED. Per-packet authentication may be provided by SRTP or by 1615 other means. Without the use of authentication, attackers could forge 1616 MIDI commands into an ongoing stream, damaging speakers and eardrums. 1617 An attacker could also craft RTP and RTCP packets to exploit known bugs 1618 in the client and take effective control of a client machine. 1620 Session management tools (such as SIP [RFC3261]) SHOULD use 1621 authentication during the transport of all session descriptions 1622 containing RTP MIDI media streams. For SIP, the Security Considerations 1623 section in [RFC3261] provides an overview of possible authentication 1624 mechanisms. RTP MIDI session descriptions should use authentication 1625 because the session descriptions may code initialization data using the 1626 parameters described in Appendix C. If an attacker inserts bogus 1627 initialization data into a session description, he can corrupt the 1628 session or forge an client attack. 1630 Session descriptions may also code renderer initialization data by 1631 reference, via the url (Appendix C.6.3) and smf_url (Appendix C.6.4.2) 1632 parameters. If the coded URL is spoofed, both session and client are 1633 open to attack, even if the session description itself is authenticated. 1634 Therefore, URLs specified in url and smf_url parameters SHOULD use 1635 [RFC2818]. 1637 Section 2.1 allows streams sent by a party in two RTP sessions to have 1638 the same SSRC value and the same RTP timestamp initialization value, 1639 under certain circumstances. Normally, these values are randomly chosen 1640 for each stream in a session, to make plaintext guessing harder to do if 1641 the payloads are encrypted. Thus, Section 2.1 weakens this aspect of 1642 RTP security. 1644 10. Acknowledgements 1646 We thank the networking, media compression, and computer music community 1647 members who have commented or contributed to the effort, including Kurt 1648 B, Cynthia Bruyns, Steve Casner, Paul Davis, Robin Davies, Joanne Dow, 1649 Tobias Erichsen, Roni Even, Nicolas Falquet, Dominique Fober, Philippe 1650 Gentric, Michael Godfrey, Chris Grigg, Todd Hager, Alfred Hoenes, Michel 1651 Jullian, Phil Kerr, Young-Kwon Lim, Jessica Little, Jan van der Meer, 1652 Colin Perkins, Charlie Richmond, Herbie Robinson, Larry Rowe, Eric 1653 Scheirer, Dave Singer, Martijn Sipkema, William Stewart, Kent Terry, 1654 Magnus Westerlund, Tom White, Jim Wright, Doug Wyatt, and Giorgio Zoia. 1655 We also thank the members of the San Francisco Bay Area music and audio 1656 community for creating the context for the work, including Don Buchla, 1657 Chris Chafe, Richard Duda, Dan Ellis, Adrian Freed, Ben Gold, Jaron 1658 Lanier, Roger Linn, Richard Lyon, Dana Massie, Max Mathews, Keith 1659 McMillen, Carver Mead, Nelson Morgan, Tom Oberheim, Malcolm Slaney, Dave 1660 Smith, Julius Smith, David Wessel, and Matt Wright. 1662 11. IANA Considerations 1664 This document does not change any of the registrations in RFC 4695. 1665 Therefore, this document does not require any IANA actions, apart from 1666 updating the references to RFC 4695 to point to this document. 1668 A. The Recovery Journal Channel Chapters 1670 A.1. Recovery Journal Definitions 1672 This appendix defines the terminology and the coding idioms that are 1673 used in the recovery journal bitfield descriptions in Section 5 (journal 1674 header structure), Appendices A.2 to A.9 (channel journal chapters) and 1675 Appendices B.1 to B.5 (system journal chapters). 1677 We assume that the recovery journal resides in the journal section of an 1678 RTP packet with sequence number I ("packet I") and that the Checkpoint 1679 Packet Seqnum field in the top-level recovery journal header refers to a 1680 previous packet with sequence number C (an exception is the self- 1681 referential C = I case). Unless stated otherwise, algorithms are 1682 assumed to use modulo 2^16 arithmetic for calculations on 16-bit 1683 sequence numbers and modulo 2^32 arithmetic for calculations on 32-bit 1684 extended sequence numbers. 1686 Several bitfield coding idioms appear throughout the recovery journal 1687 system, with consistent semantics. Most recovery journal elements begin 1688 with an "S" (Single-packet loss) bit. S bits are designed to help 1689 receivers efficiently parse through the recovery journal hierarchy in 1690 the common case of the loss of a single packet. 1692 As a rule, S bits MUST be set to 1. However, an exception applies if a 1693 recovery journal element in packet I encodes data about a command stored 1694 in the MIDI command section of packet I - 1. In this case, the S bit of 1695 the recovery journal element MUST be set to 0. If a recovery journal 1696 element has its S bit set to 0, all higher-level recovery journal 1697 elements that contain it MUST also have S bits that are set to 0, 1698 including the top-level recovery journal header. 1700 Other consistent bitfield coding idioms are described below: 1702 o R flag bit. R flag bits are reserved for future use. Senders 1703 MUST set R bits to 0. Receivers MUST ignore R bit values. 1705 o LENGTH field. All fields named LENGTH (as distinct from LEN) 1706 code the number of octets in the structure that contains it, 1707 including the header it resides in and all hierarchical levels 1708 below it. If a structure contains a LENGTH field, a receiver 1709 MUST use the LENGTH field value to advance past the structure 1710 during parsing, rather than use knowledge about the internal 1711 format of the structure. 1713 We now define normative terms used to describe recovery journal 1714 semantics. 1716 o Checkpoint history. The checkpoint history of a recovery journal 1717 is the concatenation of the MIDI command sections of packets C 1718 through I - 1. The final command in the MIDI command section for 1719 packet I - 1 is considered the most recent command; the first 1720 command in the MIDI command section for packet C is the oldest 1721 command. If command X is less recent than command Y, X is 1722 considered to be "before Y". A checkpoint history with no 1723 commands is considered to be empty. The checkpoint history 1724 never contains the MIDI command section of packet I (the 1725 packet containing the recovery journal), so if C == I, the 1726 checkpoint history is empty by definition. 1728 o Session history. The session history of a recovery journal is 1729 the concatenation of MIDI command sections from the first 1730 packet of the session up to packet I - 1. The definitions of 1731 command recency and history emptiness follow those in the 1732 checkpoint history. The session history never contains the 1733 MIDI command section of packet I, and so the session history of 1734 the first packet in the session is empty by definition. 1736 o Finished/unfinished commands. If all octets of a MIDI command 1737 appear in the session history, the command is defined as being 1738 finished. If some but not all octets of a command appear 1739 in the session history, the command is defined as being unfinished. 1740 Unfinished commands occur if segments of a SysEx command appear 1741 in several RTP packets. For example, if a SysEx command is coded 1742 as 3 segments, with segment 1 in packet K, segment 2 in packet 1743 K + 1, and segment 3 in packet K + 2, the session histories for 1744 packets K + 1 and K + 2 contain unfinished versions of the command. 1745 A session history contains a finished version of a cancelled SysEx 1746 command if the history contains the cancel sublist for the command. 1748 o Reset State commands. Reset State (RS) commands reset 1749 renderers to an initialized "powerup" condition. The 1750 RS commands are: System Reset (0xFF), General MIDI System Enable 1751 (0xF0 0x7E 0xcc 0x09 0x01 0xF7), General MIDI 2 System Enable 1752 (0xF0 0x7E 0xcc 0x09 0x03 0xF7), General MIDI System Disable 1753 (0xF0 0x7E 0xcc 0x09 0x00 0xF7), Turn DLS On (0xF0 0x7E 0xcc 0x0A 1754 0x01 0xF7), and Turn DLS Off (0xF0 0x7E 0xcc 0x0A 0x02 0xF7). 1755 Registrations of subrender parameter token values (Appendix C.6.2) 1756 and IETF standards-track documents MAY specify additional 1757 RS commands. 1759 o Active commands. Active command are MIDI commands that do not 1760 appear before a Reset State command in the session history. 1762 o N-active commands. N-active commands are MIDI commands that do 1763 not appear before one of the following commands in the session 1764 history: MIDI Control Change numbers 123-127 (numbers with All 1765 Notes Off semantics) or 120 (All Sound Off), and any Reset 1766 State command. 1768 o C-active commands. C-active commands are MIDI commands that do 1769 not appear before one of the following commands in the session 1770 history: MIDI Control Change number 121 (Reset All Controllers) 1771 and any Reset State command. 1773 o Oldest-first ordering rule. Several recovery journal chapters 1774 contain a list of elements, where each element is associated 1775 with a MIDI command that appears in the session history. In 1776 most cases, the chapter definition requires that list elements 1777 be ordered in accordance with the "oldest-first ordering rule". 1778 Below, we normatively define this rule: 1780 Elements associated with the most recent command in the session 1781 history coded in the list MUST appear at the end of the list. 1783 Elements associated with the oldest command in the session 1784 history coded in the list MUST appear at the start of the list. 1786 All other list elements MUST be arranged with respect to these 1787 boundary elements, to produce a list ordering that strictly 1788 reflects the relative session history recency of the commands 1789 coded by the elements in the list. 1791 o Parameter system. A MIDI feature that provides two sets of 1792 16,384 parameters to expand the 0-127 controller number space. 1793 The Registered Parameter Names (RPN) system and the Non-Registered 1794 Parameter Names (NRPN) system each provides 16,384 parameters. 1796 o Parameter system transaction. The value of RPNs and NRPNs are 1797 changed by a series of Control Change commands that form a 1798 parameter system transaction. A canonical transaction begins 1799 with two Control Change commands to set the parameter number 1800 (controller numbers 99 and 98 for NRPNs, controller numbers 101 1801 and 100 for RPNs). The transaction continues with an arbitrary 1802 number of Data Entry (controller numbers 6 and 38), Data Increment 1803 (controller number 96), and Data Decrement (controller number 1804 97) Control Change commands to set the parameter value. The 1805 transaction ends with a second pair of (99, 98) or (101, 100) 1806 Control Change commands that specify the null parameter (MSB 1807 value 0x7F, LSB value 0x7F). 1809 Several variants of the canonical transaction sequence are 1810 possible. Most commonly, the terminal pair of (99, 98) or 1811 (101, 100) Control Change commands may specify a parameter 1812 other than the null parameter. In this case, the command 1813 pair terminates the first transaction and starts a second 1814 transaction. The command pair is considered to be a part 1815 of both transactions. This variant is legal and recommended 1816 in [MIDI]. We refer to this variant as a "type 1 variant". 1818 Less commonly, the MSB (99 or 101) or LSB (98 or 100) command 1819 of a (99, 98) or (101, 100) Control Change pair may be omitted. 1821 If the MSB command is omitted, the transaction uses the MSB value 1822 of the most recent C-active Control Change command for controller 1823 number 99 or 101 that appears in the session history. We refer to 1824 this variant as a "type 2 variant". 1826 If the LSB command is omitted, the LSB value 0x00 is assumed. We 1827 refer to this variant as a "type 3 variant". The type 2 and type 3 1828 variants are defined as legal, but are not recommended, in [MIDI]. 1830 System real-time commands may appear at any point during 1831 a transaction (even between octets of individual commands 1832 in the transaction). More generally, [MIDI] does not forbid 1833 the appearance of unrelated MIDI commands during an open 1834 transaction. As a rule, these commands are considered to 1835 be "outside" the transaction and do not affect the status 1836 of the transaction in any way. Exceptions to this rule are 1837 commands whose semantics act to terminate transactions: 1838 Reset State commands, and Control Change (0xB) for controller 1839 number 121 (Reset All Controllers) [RP015]. 1841 o Initiated parameter system transaction. A canonical parameter 1842 system transaction whose (99, 98) or (101, 100) initial Control 1843 Change command pair appears in the session history is considered 1844 to be an initiated parameter system transaction. This definition 1845 also holds for type 1 variants. For type 2 variants (dropped MSB), 1846 a transaction whose initial LSB Control Change command appears in 1847 the session history is an initiated transaction. For type 3 1848 variants (dropped LSB), a transaction is considered to be 1849 initiated if at least one transaction command follows the initial 1850 MSB (99 or 101) Control Change command in the session history. 1851 The completion of a transaction does not nullify its "initiated" 1852 status. 1854 o Session history reference counts. Several recovery journal 1855 chapters include a reference count field, which codes the 1856 total number of commands of a type that appear in the session 1857 history. Examples include the Reset and Tune Request command 1858 logs (Chapter D, Appendix B.1) and the Active Sense command 1859 (Chapter V, Appendix B.2). Upon the detection of a loss event, 1860 reference count fields let a receiver deduce if any instances of 1861 the command have been lost, by comparing the journal reference 1862 count with its own reference count. Thus, a reference count 1863 field makes sense, even for command types in which knowing the 1864 NUMBER of lost commands is irrelevant (as is true with all of 1865 the example commands mentioned above). 1867 The chapter definitions in Appendices A.2 to A.9 and B.1 to B.5 reflect 1868 the default recovery journal behavior. The ch_default, ch_never, and 1869 ch_anchor parameters modify these definitions, as described in Appendix 1870 C.2.3. 1872 The chapter definitions specify if data MUST be present in the journal. 1873 Senders MAY also include non-required data in the journal. This 1874 optional data MUST comply with the normative chapter definition. For 1875 example, if a chapter definition states that a field codes data from the 1876 most recent active command in the session history, the sender MUST NOT 1877 code inactive commands or older commands in the field. 1879 Finally, we note that a channel journal only encodes information about 1880 MIDI commands appearing on the MIDI channel the journal protects. All 1881 references to MIDI commands in Appendices A.2 to A.9 should be read as 1882 "MIDI commands appearing on this channel." 1883 A.2. Chapter P: MIDI Program Change 1885 A channel journal MUST contain Chapter P if an active Program Change 1886 (0xC) command appears in the checkpoint history. Figure A.2.1 shows the 1887 format for Chapter P. 1889 0 1 2 1890 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 1891 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1892 |S| PROGRAM |B| BANK-MSB |X| BANK-LSB | 1893 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1895 Figure A.2.1 -- Chapter P format 1897 The chapter has a fixed size of 24 bits. The PROGRAM field indicates 1898 the data value of the most recent active Program Change command in the 1899 session history. By default, the B, BANK-MSB, X, and BANK-LSB fields 1900 MUST be set to 0. Below, we define exceptions to this default 1901 condition. 1903 If an active Control Change (0xB) command for controller number 0 (Bank 1904 Select MSB) appears before the Program Change command in the session 1905 history, the B bit MUST be set to 1, and the BANK-MSB field MUST code 1906 the data value of the Control Change command. 1908 If B is set to 1, the BANK-LSB field MUST code the data value of the 1909 most recent Control Change command for controller number 32 (Bank Select 1910 LSB) that preceded the Program Change command coded in the PROGRAM field 1911 and followed the Control Change command coded in the BANK-MSB field. If 1912 no such Control Change command exists, the BANK-LSB field MUST be set to 1913 0. 1915 If B is set to 1, and if a Control Change command for controller number 1916 121 (Reset All Controllers) appears in the MIDI stream between the 1917 Control Change command coded by the BANK-MSB field and the Program 1918 Change command coded by the PROGRAM field, the X bit MUST be set to 1. 1920 Note that [RP015] specifies that Reset All Controllers does not reset 1921 the values of controller numbers 0 (Bank Select MSB) and 32 (Bank Select 1922 LSB). Thus, the X bit does not effect how receivers will use the BANK- 1923 LSB and BANK-MSB values when recovering from a lost Program Change 1924 command. The X bit serves to aid recovery in MIDI applications where 1925 controller numbers 0 and 32 are used in a non-standard way. 1927 A.3. Chapter C: MIDI Control Change 1929 Figure A.3.1 shows the format for Chapter C. 1931 0 1 2 3 1932 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 1933 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1934 |S| LEN |S| NUMBER |A| VALUE/ALT |S| NUMBER | 1935 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1936 |A| VALUE/ALT | .... | 1937 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1939 Figure A.3.1 -- Chapter C format 1941 The chapter consists of a 1-octet header, followed by a variable length 1942 list of 2-octet controller logs. The list MUST contain at least one 1943 controller log. The 7-bit LEN field codes the number of controller logs 1944 in the list, minus one. We define the semantics of the controller log 1945 fields in Appendix A.3.2. 1947 A channel journal MUST contain Chapter C if the rules defined in this 1948 appendix require that one or more controller logs appear in the list. 1950 A.3.1. Log Inclusion Rules 1952 A controller log encodes information about a particular Control Change 1953 command in the session history. 1955 In the default use of the payload format, list logs MUST encode 1956 information about the most recent active command in the session history 1957 for a controller number. Logs encoding earlier commands MUST NOT appear 1958 in the list. 1960 Also, as a rule, the list MUST contain a log for the most recent active 1961 command for a controller number that appears in the checkpoint history. 1962 Below, we define exceptions to this rule: 1964 o MIDI streams may transmit 14-bit controller values using paired 1965 Most Significant Byte (MSB, controller numbers 0-31, 99, 101) and 1966 Least Significant Byte (LSB, controller numbers 32-63, 98, 100) 1967 Control Change commands [MIDI]. 1969 If the most recent active Control Change command in the session 1970 history for a 14-bit controller pair uses the MSB number, Chapter 1971 C MAY omit the controller log for the most recent active Control 1972 Change command for the associated LSB number, as the command 1973 ordering makes this LSB value irrelevant. However, this exception 1974 MUST NOT be applied if the sender is not certain that the MIDI 1975 source uses 14-bit semantics for the controller number pair. Note 1976 that some MIDI sources ignore 14-bit controller semantics and use 1977 the LSB controller numbers as independent 7-bit controllers. 1979 o If active Control Change commands for controller numbers 0 (Bank 1980 Select MSB) or 32 (Bank Select LSB) appear in the checkpoint 1981 history, and if the command instances are also coded in the 1982 BANK-MSB and BANK-LSB fields of the Chapter P (Appendix A.2), 1983 Chapter C MAY omit the controller logs for the commands. 1985 o Several controller number pairs are defined to be mutually 1986 exclusive. Controller numbers 124 (Omni Off) and 125 (Omni On) 1987 form a mutually exclusive pair, as do controller numbers 126 1988 (Mono) and 127 (Poly). 1990 If active Control Change commands for one or both members of 1991 a mutually exclusive pair appear in the checkpoint history, a 1992 log for the controller number of the most recent command for the 1993 pair in the checkpoint history MUST appear in the controller list. 1994 However, the list MAY omit the controller log for the most recent 1995 active command for the other number in the pair. 1997 If active Control Change commands for one or both members of a 1998 mutually exclusive pair appear in the session history, and if a 1999 log for the controller number of the most recent command for the 2000 pair does not appear in the controller list, a log for the most 2001 recent command for the other number of the pair MUST NOT appear 2002 in the controller list. 2004 o If an active Control Change command for controller number 121 2005 (Reset All Controllers) appears in the session history, the 2006 controller list MAY omit logs for Control Change commands that 2007 precede the Reset All Controllers command in the session history, 2008 under certain conditions. 2010 Namely, a log MAY be omitted if the sender is certain that a 2011 command stream follows the Reset All Controllers semantics 2012 defined in [RP015], and if the log codes a controller number 2013 for which [RP015] specifies a reset value. 2015 For example, [RP015] specifies that controller number 1 2016 (Modulation Wheel) is reset to the value 0, and thus 2017 a controller log for Modulation Wheel MAY be omitted 2018 from the controller log list. In contrast, [RP015] specifies 2019 that controller number 7 (Channel Volume) is not reset, 2020 and thus a controller log for Channel Volume MUST NOT 2021 be omitted from the controller log list. 2023 o Appendix A.3.4 defines exception rules for the MIDI Parameter 2024 System controller numbers 6, 38, and 96-101. 2026 A.3.2. Controller Log Format 2028 Figure A.3.2 shows the controller log structure of Chapter C. 2030 0 1 2031 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2032 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2033 |S| NUMBER |A| VALUE/ALT | 2034 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2036 Figure A.3.2 -- Chapter C controller log 2038 The 7-bit NUMBER field identifies the controller number of the coded 2039 command. The 7-bit VALUE/ALT field codes recovery information for the 2040 command. The A bit sets the format of the VALUE/ALT field. 2042 A log encodes recovery information using one of the following tools: the 2043 value tool, the toggle tool, or the count tool. 2045 A log uses the value tool if the A bit is set to 0. The value tool 2046 codes the 7-bit data value of a command in the VALUE/ALT field. The 2047 value tool works best for controllers that code a continuous quantity, 2048 such as number 1 (Modulation Wheel). 2050 The A bit is set to 1 to code the toggle or count tool. These tools 2051 work best for controllers that code discrete actions. Figure A.3.3 2052 shows the controller log for these tools. 2054 0 1 2055 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2056 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2057 |S| NUMBER |1|T| ALT | 2058 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2060 Figure A.3.3 -- Controller log for ALT tools 2062 A log uses the toggle tool if the T bit is set to 0. A log uses the 2063 count tool if the T bit is set to 1. Both methods use the 6-bit ALT 2064 field as an unsigned integer. 2066 The toggle tool works best for controllers that act as on/off switches, 2067 such as 64 (Damper Pedal (Sustain)). These controllers code the "off" 2068 state with control values 0-63 and the "on" state with 64-127. 2070 For the toggle tool, the ALT field codes the total number of toggles 2071 (off->on and on->off) due to Control Change commands in the session 2072 history, up to and including a toggle caused by the command coded by the 2073 log. The toggle count includes toggles caused by Control Change 2074 commands for controller number 121 (Reset All Controllers). 2076 Toggle counting is performed modulo 64. The toggle count is reset at 2077 the start of a session, and whenever a Reset State command (Appendix 2078 A.1) appears in the session history. When these reset events occur, the 2079 toggle count for a controller is set to 0 (for controllers whose default 2080 value is 0-63) or 1 (for controllers whose default value is 64-127). 2082 The Damper Pedal (Sustain) controller illustrates the benefits of the 2083 toggle tool over the value tool for switch controllers. As often used 2084 in piano applications, the "on" state of the controller lets notes 2085 resonate, while the "off" state immediately damps notes to silence. The 2086 loss of the "off" command in an "on->off->on" sequence results in 2087 ringing notes that should have been damped silent. The toggle tool lets 2088 receivers detect this lost "off" command, but the value tool does not. 2090 The count tool is conceptually similar to the toggle tool. For the 2091 count tool, the ALT field codes the total number of Control Change 2092 commands in the session history, up to and including the command coded 2093 by the log. Command counting is performed modulo 64. The command count 2094 is set to 0 at the start of the session and is reset to 0 whenever a 2095 Reset State command (Appendix A.1) appears in the session history. 2097 Because the count tool ignores the data value, it is a good match for 2098 controllers whose controller value is ignored, such as number 123 (All 2099 Notes Off). More generally, the count tool may be used to code a 2100 (modulo 64) identification number for a command. 2102 A.3.3. Log List Coding Rules 2104 In this section, we describe the organization of controller logs in the 2105 Chapter C log list. 2107 A log encodes information about a particular Control Change command in 2108 the session history. In most cases, a command SHOULD be coded by a 2109 single tool (and, thus, a single log). If a number is coded with a 2110 single tool and this tool is the count tool, recovery Control Change 2111 commands generated by a receiver SHOULD use the default control value 2112 for the controller. 2114 However, a command MAY be coded by several tool types (and, thus, 2115 several logs, each using a different tool). This technique may improve 2116 recovery performance for controllers with complex semantics, such as 2117 controller number 84 (Portamento Control) or controller number 121 2118 (Reset All Controllers) when used with a non-zero data octet (with the 2119 semantics described in [DLS2]). 2121 If a command is encoded by multiple tools, the logs MUST be placed in 2122 the list in the following order: count tool log (if any), followed by 2123 value tool log (if any), followed by toggle tool log (if any). 2125 The Chapter C log list MUST obey the oldest-first ordering rule (defined 2126 in Appendix A.1). Note that this ordering preserves the information 2127 necessary for the recovery of 14-bit controller values, without 2128 precluding the use of MSB and LSB controller pairs as independent 7-bit 2129 controllers. 2131 In the default use of the payload format, all logs that appear in the 2132 list for a controller number encode information about one Control Change 2133 command -- namely, the most recent active Control Change command in the 2134 session history for the number. 2136 This coding scheme provides good recovery performance for the standard 2137 uses of Control Change commands defined in [MIDI]. However, not all 2138 MIDI applications restrict the use of Control Change commands to those 2139 defined in [MIDI]. 2141 For example, consider the common MIDI encoding of rotary encoders 2142 ("infinite" rotation knobs). The mixing console MIDI convention defined 2143 in [LCP] codes the position of rotary encoders as a series of Control 2144 Change commands. Each command encodes a relative change of knob 2145 position from the last update (expressed as a clockwise or counter- 2146 clockwise knob turning angle). 2148 As the knob position is encoded incrementally over a series of Control 2149 Change commands, the best recovery performance is obtained if the log 2150 list encodes all Control Change commands for encoder controller numbers 2151 that appear in the checkpoint history, not only the most recent command. 2153 To support application areas that use Control Change commands in this 2154 way, Chapter C may be configured to encode information about several 2155 Control Change commands for a controller number. We use the term 2156 "enhanced" to describe this encoding method, which we describe below. 2158 In Appendix C.2.3, we show how to configure a stream to use enhanced 2159 Chapter C encoding for specific controller numbers. In Section 5 in the 2160 main text, we show how the H bits in the recovery journal header (Figure 2161 8) and in the channel journal header (Figure 9) indicate the use of 2162 enhanced Chapter C encoding. 2164 Here, we define how to encode a Chapter C log list that uses the 2165 enhanced encoding method. 2167 Senders that use the enhanced encoding method for a controller number 2168 MUST obey the rules below. These rules let a receiver determine which 2169 logs in the list correspond to lost commands. Note that these rules 2170 override the exceptions listed in Appendix A.3.1. 2172 o If N commands for a controller number are encoded in the list, 2173 the commands MUST be the N most recent commands for the controller 2174 number in the session history. For example, for N = 2, the sender 2175 MUST encode the most recent command and the second most recent 2176 command, not the most recent command and the third most recent 2177 command. 2179 o If a controller number uses enhanced encoding, the encoding 2180 of the least-recent command for the controller number in the 2181 log list MUST include a count tool log. In addition, if 2182 commands are encoded for the controller number whose logs 2183 have S bits set to 0, the encoding of the least-recent 2184 command with S = 0 logs MUST include a count tool log. 2186 The count tool is OPTIONAL for the other commands for the 2187 controller number encoded in the list, as a receiver is 2188 able to efficiently deduce the count tool value for these 2189 commands, for both single-packet and multi-packet loss events. 2191 o The use of the value and toggle tools MUST be identical for all 2192 commands for a controller number encoded in the list. For 2193 example, a value tool log either MUST appear for all commands 2194 for the controller number coded in the list, or alternatively, 2195 value tool logs for the controller number MUST NOT appear in 2196 the list. Likewise, a toggle tool log either MUST appear for 2197 all commands for the controller number coded in the list, or 2198 alternatively, toggle tool logs for the controller number MUST 2199 NOT appear in the list. 2201 o If a command is encoded by multiple tools, the logs MUST be 2202 placed in the list in the following order: count tool log 2203 (if any), followed by value tool log (if any), followed by 2204 toggle tool log (if any). 2206 These rules permit a receiver recovering from a packet loss to use the 2207 count tool log to match the commands encoded in the list with its own 2208 history of the stream, as we describe below. Note that the text below 2209 describes a non-normative algorithm; receivers are free to use any 2210 algorithm to match its history with the log list. 2212 In a typical implementation of the enhanced encoding method, a receiver 2213 computes and stores count, value, and toggle tool data field values for 2214 the most recent Control Change command it has received for a controller 2215 number. 2217 After a loss event, a receiver parses the Chapter C list and processes 2218 list logs for a controller number that uses enhanced encoding as 2219 follows. 2221 The receiver compares the count tool ALT field for the least-recent 2222 command for the controller number in the list against its stored count 2223 data for the controller number, to determine if recovery is necessary 2224 for the command coded in the list. The value and toggle tool logs (if 2225 any) that directly follow the count tool log are associated with this 2226 least-recent command. 2228 To check more-recent commands for the controller, the receiver detects 2229 additional value and/or toggle tool logs for the controller number in 2230 the list and infers count tool data for the command coded by these logs. 2231 This inferred data is used to determine if recovery is necessary for the 2232 command coded by the value and/or toggle tool logs. 2234 In this way, a receiver is able to execute only lost commands, without 2235 executing a command twice. While recovering from a single packet loss, 2236 a receiver may skip through S = 1 logs in the list, as the first S = 0 2237 log for an enhanced controller number is always a count tool log. 2239 Note that the requirements in Appendix C.2.2.2 for protective sender and 2240 receiver actions during session startup for multicast operation are of 2241 particular importance for enhanced encoding, as receivers need to 2242 initialize its count tool data structures with recovery journal data in 2243 order to match commands correctly after a loss event. 2245 Finally, we note in passing that in some applications of rotary 2246 encoders, a good user experience may be possible without the use of 2247 enhanced encoding. These applications are distinguished by visual 2248 feedback of encoding position that is driven by the post-recovery rotary 2249 encoding stream, and relatively low packet loss. In these domains, 2250 recovery performance may be acceptable for rotary encoders if the log 2251 list encodes only the most recent command, if both count and value logs 2252 appear for the command. 2254 A.3.4. The Parameter System 2256 Readers may wish to review the Appendix A.1 definitions of "parameter 2257 system", "parameter system transaction", and "initiated parameter system 2258 transaction" before reading this section. 2260 Parameter system transactions update a MIDI Registered Parameter Number 2261 (RPN) or Non-Registered Parameter Number (NRPN) value. A parameter 2262 system transaction is a sequence of Control Change commands that may use 2263 the following controllers numbers: 2265 o Data Entry MSB (6) 2266 o Data Entry LSB (38) 2267 o Data Increment (96) 2268 o Data Decrement (97) 2269 o Non-Registered Parameter Number (NRPN) LSB (98) 2270 o Non-Registered Parameter Number (NRPN) MSB (99) 2271 o Registered Parameter Number (RPN) LSB (100) 2272 o Registered Parameter Number (RPN) MSB (101) 2274 Control Change commands that are a part of a parameter system 2275 transaction MUST NOT be coded in Chapter C controller logs. Instead, 2276 these commands are coded in Chapter M, the MIDI Parameter chapter 2277 defined in Appendix A.4. 2279 However, Control Change commands that use the listed controllers as 2280 general-purpose controllers (i.e., outside of a parameter system 2281 transaction) MUST NOT be coded in Chapter M. 2283 Instead, the controllers are coded in Chapter C controller logs. The 2284 controller logs follow the coding rules stated in Appendix A.3.2 and 2285 A.3.3. The rules for coding paired LSB and MSB controllers, as defined 2286 in Appendix A.3.1, apply to the pairs (6, 38), (99, 98), and (101, 100) 2287 when coded in Chapter C. 2289 If active Control Change commands for controller numbers 6, 38, or 2290 96-101 appear in the checkpoint history, and these commands are used as 2291 general-purpose controllers, the most recent general-purpose command 2292 instance for these controller numbers MUST appear as entries in the 2293 Chapter C controller list. 2295 MIDI syntax permits a source to use controllers 6, 38, 96, and 97 as 2296 parameter-system controllers and general-purpose controllers in the same 2297 stream. An RTP MIDI sender MUST deduce the role of each Control Change 2298 command for these controller numbers by noting the placement of the 2299 command in the stream and MUST use this information to code the command 2300 in Chapter C or Chapter M, as appropriate. 2302 Specifically, active Control Change commands for controllers 6, 38, 96, 2303 and 97 act in a general-purpose way when 2305 o no active Control Change commands that set an RPN or 2306 NRPN parameter number appear in the session history, or 2308 o the most recent active Control Change commands in the session 2309 history that set an RPN or NRPN parameter number code the null 2310 parameter (MSB value 0x7F, LSB value 0x7F), or 2312 o a Control Change command for controller number 121 (Reset 2313 All Controllers) appears more recently in the session history 2314 than all active Control Change commands that set an RPN or 2315 NRPN parameter number (see [RP015] for details). 2317 Finally, we note that a MIDI source that follows the recommendations of 2318 [MIDI] exclusively uses numbers 98-101 as parameter system controllers. 2319 Alternatively, a MIDI source may exclusively use 98-101 as general- 2320 purpose controllers and lose the ability to perform parameter system 2321 transactions in a stream. 2323 In the language of [MIDI], the general-purpose use of controllers 98-101 2324 constitutes a non-standard controller assignment. As most real-world 2325 MIDI sources use the standard controller assignment for controller 2326 numbers 98-101, an RTP MIDI sender SHOULD assume these controllers act 2327 as parameter system controllers, unless it knows that a MIDI source uses 2328 controller numbers 98-101 in a general-purpose way. 2330 A.4. Chapter M: MIDI Parameter System 2332 Readers may wish to review the Appendix A.1 definitions for "C-active", 2333 "parameter system", "parameter system transaction", and "initiated 2334 parameter system transaction" before reading this appendix. 2336 Chapter M protects parameter system transactions for Registered 2337 Parameter Number (RPN) and Non-Registered Parameter Number (NRPN) 2338 values. Figure A.4.1 shows the format for Chapter M. 2340 0 1 2 3 2341 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 2342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2343 |S|P|E|U|W|Z| LENGTH |Q| PENDING | Log list ... | 2344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2346 Figure A.4.1 -- Top-level Chapter M format 2348 Chapter M begins with a 2-octet header. If the P header bit is set to 2349 1, a 1-octet field follows the header, coding the 7-bit PENDING value 2350 and its associated Q bit. 2352 The 10-bit LENGTH field codes the size of Chapter M and conforms to 2353 semantics described in Appendix A.1. 2355 Chapter M ends with a list of zero or more variable-length parameter 2356 logs. Appendix A.4.2 defines the bitfield format of a parameter log. 2357 Appendix A.4.1 defines the inclusion semantics of the log list. 2359 A channel journal MUST contain Chapter M if the rules defined in 2360 Appendix A.4.1 require that one or more parameter logs appear in the 2361 list. 2363 A channel journal also MUST contain Chapter M if the most recent C- 2364 active Control Change command involved in a parameter system transaction 2365 in the checkpoint history is 2367 o an RPN MSB (101) or NRPN MSB (99) controller, or 2369 o an RPN LSB (100) or NRPN LSB (98) controller that completes the 2370 coding of the null parameter (MSB value 0x7F, LSB value 0x7F). 2372 This rule provides loss protection for partially transmitted parameter 2373 numbers and for the null parameter numbers. 2375 If the most recent C-active Control Change command involved in a 2376 parameter system transaction in the session history is for the RPN MSB 2377 or NRPN MSB controller, the P header bit MUST be set to 1, and the 2378 PENDING field (and its associated Q bit) MUST follow the Chapter M 2379 header. Otherwise, the P header bit MUST be set to 0, and the PENDING 2380 field and Q bit MUST NOT appear in Chapter M. 2382 If PENDING codes an NRPN MSB, the Q bit MUST be set to 1. If PENDING 2383 codes an RPN MSB, the Q bit MUST be set to 0. 2385 The E header bit codes the current transaction state of the MIDI stream. 2386 If E = 1, an initiated transaction is in progress. Below, we define the 2387 rules for setting the E header bit: 2389 o If no C-active parameter system transaction Control Change 2390 commands appear in the session history, the E bit MUST be 2391 set to 0. 2393 o If the P header bit is set to 1, the E bit MUST be set to 0. 2395 o If the most recent C-active parameter system transaction 2396 Control Change command in the session history is for the 2397 NRPN LSB or RPN LSB controller number, and if this command 2398 acts to complete the coding of the null parameter (MSB 2399 value 0x7F, LSB value 0x7F), the E bit MUST be set to 0. 2401 o Otherwise, an initiated transaction is in progress, and the 2402 E bit MUST be set to 1. 2404 The U, W, and Z header bits code properties that are shared by all 2405 parameter logs in the list. If these properties are set, parameter logs 2406 may be coded with improved efficiency (we explain how in A.4.1). 2408 By default, the U, W, and Z bits MUST be set to 0. If all parameter 2409 logs in the list code RPN parameters, the U bit MAY be set to 1. If all 2410 parameter logs in the list code NRPN parameters, the W bit MAY be set to 2411 1. If the parameter numbers of all RPN and NRPN logs in the list lie in 2412 the range 0-127 (and thus have an MSB value of 0), the Z bit MAY be set 2413 to 1. 2415 Note that C-active semantics appear in the preceding paragraphs because 2416 [RP015] specifies that pending Parameter System transactions are closed 2417 by a Control Change command for controller number 121 (Reset All 2418 Controllers). 2420 A.4.1. Log Inclusion Rules 2422 Parameter logs code recovery information for a specific RPN or NRPN 2423 parameter. 2425 A parameter log MUST appear in the list if an active Control Change 2426 command that forms a part of an initiated transaction for the parameter 2427 appears in the checkpoint history. 2429 An exception to this rule applies if the checkpoint history only 2430 contains transaction Control Change commands for controller numbers 2431 98-101 that act to terminate the transaction. In this case, a log for 2432 the parameter MAY be omitted from the list. 2434 A log MAY appear in the list if an active Control Change command that 2435 forms a part of an initiated transaction for the parameter appears in 2436 the session history. Otherwise, a log for the parameter MUST NOT appear 2437 in the list. 2439 Multiple logs for the same RPN or NRPN parameter MUST NOT appear in the 2440 log list. 2442 The parameter log list MUST obey the oldest-first ordering rule (defined 2443 in Appendix A.1), with the phrase "parameter transaction" replacing the 2444 word "command" in the rule definition. 2446 Parameter logs associated with the RPN or NRPN null parameter (LSB = 2447 0x7F, MSB = 0x7F) MUST NOT appear in the log list. Chapter M uses the E 2448 header bit (Figure A.4.1) and the log list ordering rules to code null 2449 parameter semantics. 2451 Note that "active" semantics (rather than "C-active" semantics) appear 2452 in the preceding paragraphs because [RP015] specifies that pending 2453 Parameter System transactions are not reset by a Control Change command 2454 for controller number 121 (Reset All Controllers). However, the rule 2455 that follows uses C-active semantics, because it concerns the protection 2456 of the transaction system itself, and [RP015] specifies that Reset All 2457 Controllers acts to close a transaction in progress. 2459 In most cases, parameter logs for RPN and NRPN parameters that are 2460 assigned to the ch_never parameter (Appendix C.2.3) MAY be omitted from 2461 the list. An exception applies if 2463 o the log codes the most recent initiated transaction 2464 in the session history, and 2466 o a C-active command that forms a part of the transaction 2467 appears in the checkpoint history, and 2469 o the E header bit for the top-level Chapter M header (Figure 2470 A.4.1) is set to 1. 2472 In this case, a log for the parameter MUST appear in the list. This log 2473 informs receivers recovering from a loss that a transaction is in 2474 progress, so that the receiver is able to correctly interpret RPN or 2475 NRPN Control Change commands that follow the loss event. 2477 A.4.2. Log Coding Rules 2479 Figure A.4.2 shows the parameter log structure of Chapter M. 2481 0 1 2 3 2482 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 2483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2484 |S| PNUM-LSB |Q| PNUM-MSB |J|K|L|M|N|T|V|R| Fields ... | 2485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2487 Figure A.4.2 -- Parameter log format 2489 The log begins with a header, whose default size (as shown in Figure 2490 A.4.2) is 3 octets. If the Q header bit is set to 0, the log encodes an 2491 RPN parameter. If Q = 1, the log encodes an NRPN parameter. The 7-bit 2492 PNUM-MSB and PNUM-LSB fields code the parameter number and reflect the 2493 Control Change command data values for controllers 99 and 98 (for NRPNs) 2494 or 101 and 100 (for RPNs). 2496 The J, K, L, M, and N header bits form a Table of Contents (TOC) for the 2497 log and signal the presence of fixed-sized fields that follow the 2498 header. A header bit that is set to 1 codes the presence of a field in 2499 the log. The ordering of fields in the log follows the ordering of the 2500 header bits in the TOC. Appendices A.4.2.1-2 define the fields 2501 associated with each TOC header bit. 2503 The T and V header bits code information about the parameter log but are 2504 not part of the TOC. A set T or V bit does not signal the presence of 2505 any parameter log field. 2507 If the rules in Appendix A.4.1 state that a log for a given parameter 2508 MUST appear in Chapter M, the log MUST code sufficient information to 2509 protect the parameter from the loss of active parameter transaction 2510 Control Change commands in the checkpoint history. 2512 This rule does not apply if the parameter coded by the log is assigned 2513 to the ch_never parameter (Appendix C.2.3). In this case, senders MAY 2514 choose to set the J, K, L, M, and N TOC bits to 0, coding a parameter 2515 log with no fields. 2517 Note that logs to protect parameters that are assigned to ch_never are 2518 REQUIRED under certain conditions (see Appendix A.4.1). The purpose of 2519 the log is to inform receivers recovering from a loss that a transaction 2520 is in progress, so that the receiver is able to correctly interpret RPN 2521 or NRPN Control Change commands that follow the loss event. 2523 Parameter logs provide two tools for parameter protection: the value 2524 tool and the count tool. Depending on the semantics of the parameter, 2525 senders may use either tool, both tools, or neither tool to protect a 2526 given parameter. 2528 The value tool codes information a receiver may use to determine the 2529 current value of an RPN or NRPN parameter. If a parameter log uses the 2530 value tool, the V header bit MUST be set to 1, and the semantics defined 2531 in Appendices A.4.2.1 for setting the J, K, L, and M TOC bits MUST be 2532 followed. If a parameter log does not use the value tool, the V bit 2533 MUST be set to 0, and the J, K, L, and M TOC bits MUST also be set to 0. 2535 The count tool codes the number of transactions for an RPN or NRPN 2536 parameter. If a parameter log uses the count tool, the T header bit 2537 MUST be set to 1, and the semantics defined in Appendices A.4.2.2 for 2538 setting the N TOC bit MUST be followed. If a parameter log does not use 2539 the count tool, the T bit and the N TOC bit MUST be set to 0. 2541 Note that V and T are set if the sender uses value (V) or count (T) tool 2542 for the log on an ongoing basis. Thus, V may be set even if J = K = L = 2543 M = 0, and T may be set even if N = 0. 2545 In many cases, all parameters coded in the log list are of one type (RPN 2546 and NRPN), and all parameter numbers lie in the range 0-127. As 2547 described in Appendix A.4.1, senders MAY signal this condition by 2548 setting the top-level Chapter M header bit Z to 1 (to code the 2549 restricted range) and by setting the U or W bit to 1 (to code the 2550 parameter type). 2552 If the top-level Chapter M header codes Z = 1 and either U = 1 or W = 1, 2553 all logs in the parameter log list MUST use a modified header format. 2554 This modification deletes bits 8-15 of the bitfield shown in Figure 2555 A.4.2, to yield a 2-octet header. The values of the deleted PNUM-MSB 2556 and Q fields may be inferred from the U, W, and Z bit values. 2558 A.4.2.1. The Value Tool 2560 The value tool uses several fields to track the value of an RPN or NRPN 2561 parameter. 2563 The J TOC bit codes the presence of the octet shown in Figure A.4.3 in 2564 the field list. 2566 0 2567 0 1 2 3 4 5 6 7 2568 +-+-+-+-+-+-+-+-+ 2569 |X| ENTRY-MSB | 2570 +-+-+-+-+-+-+-+-+ 2572 Figure A.4.3 -- ENTRY-MSB field 2574 The 7-bit ENTRY-MSB field codes the data value of the most recent active 2575 Control Change command for controller number 6 (Data Entry MSB) in the 2576 session history that appears in a transaction for the log parameter. 2578 The X bit MUST be set to 1 if the command coded by ENTRY-MSB precedes 2579 the most recent Control Change command for controller 121 (Reset All 2580 Controllers) in the session history. Otherwise, the X bit MUST be set 2581 to 0. 2583 A parameter log that uses the value tool MUST include the ENTRY-MSB 2584 field if an active Control Change command for controller number 6 2585 appears in the checkpoint history. 2587 Note that [RP015] specifies that Control Change commands for controller 2588 121 (Reset All Controllers) do not reset RPN and NRPN values, and thus 2589 the X bit would not play a recovery role for MIDI systems that comply 2590 with [RP015]. 2592 However, certain renderers (such as DLS 2 [DLS2]) specify that certain 2593 RPN values are reset for some uses of Reset All Controllers. The X bit 2594 (and other bitfield features of this nature in this appendix) plays a 2595 role in recovery for renderers of this type. 2597 The K TOC bit codes the presence of the octet shown in Figure A.4.4 in 2598 the field list. 2600 0 2601 0 1 2 3 4 5 6 7 2602 +-+-+-+-+-+-+-+-+ 2603 |X| ENTRY-LSB | 2604 +-+-+-+-+-+-+-+-+ 2606 Figure A.4.4 -- ENTRY-LSB field 2608 The 7-bit ENTRY-LSB field codes the data value of the most recent active 2609 Control Change command for controller number 38 (Data Entry LSB) in the 2610 session history that appears in a transaction for the log parameter. 2612 The X bit MUST be set to 1 if the command coded by ENTRY-LSB precedes 2613 the most recent Control Change command for controller 121 (Reset All 2614 Controllers) in the session history. Otherwise, the X bit MUST be set 2615 to 0. 2617 As a rule, a parameter log that uses the value tool MUST include the 2618 ENTRY-LSB field if an active Control Change command for controller 2619 number 38 appears in the checkpoint history. However, the ENTRY-LSB 2620 field MUST NOT appear in a parameter log if the Control Change command 2621 associated with the ENTRY-LSB precedes a Control Change command for 2622 controller number 6 (Data Entry MSB) that appears in a transaction for 2623 the log parameter in the session history. 2625 The L TOC bit codes the presence of the octets shown in Figure A.4.5 in 2626 the field list. 2628 0 1 2629 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2631 |G|X| A-BUTTON | 2632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2634 Figure A.4.5 -- A-BUTTON field 2636 The 14-bit A-BUTTON field codes a count of the number of active Control 2637 Change commands for controller numbers 96 and 97 (Data Increment and 2638 Data Decrement) in the session history that appear in a transaction for 2639 the log parameter. 2641 The M TOC bit codes the presence of the octets shown in Figure A.4.6 in 2642 the field list. 2644 0 1 2645 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2647 |G|R| C-BUTTON | 2648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2650 Figure A.4.6 -- C-BUTTON field 2652 The 14-bit C-BUTTON field has semantics identical to A-BUTTON, except 2653 that Data Increment and Data Decrement Control Change commands that 2654 precede the most recent Control Change command for controller 121 (Reset 2655 All Controllers) in the session history are not counted. 2657 For both A-BUTTON and C-BUTTON, Data Increment and Data Decrement 2658 Control Change commands are not counted if they precede Control Changes 2659 commands for controller numbers 6 (Data Entry MSB) or 38 (Data Entry 2660 LSB) that appear in a transaction for the log parameter in the session 2661 history. 2663 The A-BUTTON and C-BUTTON fields are interpreted as unsigned integers, 2664 and the G bit associated with the field codes the sign of the integer (G 2665 = 0 for positive or zero, G = 1 for negative). 2667 To compute and code the count value, initialize the count value to 0, 2668 add 1 for each qualifying Data Increment command, and subtract 1 for 2669 each qualifying Data Decrement command. After each add or subtract, 2670 limit the count magnitude to 16383. The G bit codes the sign of the 2671 count, and the A-BUTTON or C-BUTTON field codes the count magnitude. 2673 For the A-BUTTON field, if the most recent qualified Data Increment or 2674 Data Decrement command precedes the most recent Control Change command 2675 for controller 121 (Reset All Controllers) in the session history, the X 2676 bit associated with A-BUTTON field MUST be set to 1. Otherwise, the X 2677 bit MUST be set to 0. 2679 A parameter log that uses the value tool MUST include the A-BUTTON and 2680 C-BUTTON fields if an active Control Change command for controller 2681 numbers 96 or 97 appears in the checkpoint history. However, to improve 2682 coding efficiency, this rule has several exceptions: 2684 o If the log includes the A-BUTTON field, and if the X bit of 2685 the A-BUTTON field is set to 1, the C-BUTTON field (and its 2686 associated R and G bits) MAY be omitted from the log. 2688 o If the log includes the A-BUTTON field, and if the A-BUTTON 2689 and C-BUTTON fields (and their associated G bits) code identical 2690 values, the C-BUTTON field (and its associated R and G bits) 2691 MAY be omitted from the log. 2693 A.4.2.2. The Count Tool 2695 The count tool tracks the number of transactions for an RPN or NRPN 2696 parameter. The N TOC bit codes the presence of the octet shown in 2697 Figure A.4.7 in the field list. 2699 0 2700 0 1 2 3 4 5 6 7 2701 +-+-+-+-+-+-+-+-+ 2702 |X| COUNT | 2703 +-+-+-+-+-+-+-+-+ 2705 Figure A.4.7 -- COUNT field 2707 The 7-bit COUNT codes the number of initiated transactions for the log 2708 parameter that appear in the session history. Initiated transactions 2709 are counted if they contain one or more active Control Change commands, 2710 including commands for controllers 98-101 that initiate the parameter 2711 transaction. 2713 If the most recent counted transaction precedes the most recent Control 2714 Change command for controller 121 (Reset All Controllers) in the session 2715 history, the X bit associated with the COUNT field MUST be set to 1. 2716 Otherwise, the X bit MUST be set to 0. 2718 Transaction counting is performed modulo 128. The transaction count is 2719 set to 0 at the start of a session and is reset to 0 whenever a Reset 2720 State command (Appendix A.1) appears in the session history. 2722 A parameter log that uses the count tool MUST include the COUNT field if 2723 an active command that increments the transaction count (modulo 128) 2724 appears in the checkpoint history. 2726 A.5. Chapter W: MIDI Pitch Wheel 2728 A channel journal MUST contain Chapter W if a C-active MIDI Pitch Wheel 2729 (0xE) command appears in the checkpoint history. Figure A.5.1 shows the 2730 format for Chapter W. 2732 0 1 2733 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2734 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2735 |S| FIRST |R| SECOND | 2736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2738 Figure A.5.1 -- Chapter W format 2740 The chapter has a fixed size of 16 bits. The FIRST and SECOND fields 2741 are the 7-bit values of the first and second data octets of the most 2742 recent active Pitch Wheel command in the session history. 2744 Note that Chapter W encodes C-active commands and thus does not encode 2745 active commands that are not C-active (see the second-to-last paragraph 2746 of Appendix A.1 for an explanation of chapter inclusion text in this 2747 regard). 2749 Chapter W does not encode "active but not C-active" commands because 2750 [RP015] declares that Control Change commands for controller number 121 2751 (Reset All Controllers) act to reset the Pitch Wheel value to 0. If 2752 Chapter W encoded "active but not C-active" commands, a repair operation 2753 following a Reset All Controllers command could incorrectly repair the 2754 stream with a stale Pitch Wheel value. 2756 A.6. Chapter N: MIDI NoteOff and NoteOn 2758 In this appendix, we consider NoteOn commands with zero velocity to be 2759 NoteOff commands. Readers may wish to review the Appendix A.1 2760 definition of "N-active commands" before reading this appendix. 2762 Chapter N completely protects note commands in streams that alternate 2763 between NoteOn and NoteOff commands for a particular note number. 2764 However, in rare applications, multiple overlapping NoteOn commands may 2765 appear for a note number. Chapter E, described in Appendix A.7, 2766 augments Chapter N to completely protect these streams. 2768 A channel journal MUST contain Chapter N if an N-active MIDI NoteOn 2769 (0x9) or NoteOff (0x8) command appears in the checkpoint history. 2770 Figure A.6.1 shows the format for Chapter N. 2772 0 1 2 3 2773 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 2774 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2775 |B| LEN | LOW | HIGH |S| NOTENUM |Y| VELOCITY | 2776 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2777 |S| NOTENUM |Y| VELOCITY | .... | 2778 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2779 | OFFBITS | OFFBITS | .... | OFFBITS | 2780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2782 Figure A.6.1 -- Chapter N format 2784 Chapter N consists of a 2-octet header, followed by at least one of the 2785 following data structures: 2787 o A list of note logs to code NoteOn commands. 2788 o A NoteOff bitfield structure to code NoteOff commands. 2790 We define the header bitfield semantics in Appendix A.6.1. We define 2791 the note log semantics and the NoteOff bitfield semantics in Appendix 2792 A.6.2. 2794 If one or more N-active NoteOn or NoteOff commands in the checkpoint 2795 history reference a note number, the note number MUST be coded in either 2796 the note log list or the NoteOff bitfield structure. 2798 The note log list MUST contain an entry for all note numbers whose most 2799 recent checkpoint history appearance is in an N-active NoteOn command. 2800 The NoteOff bitfield structure MUST contain a set bit for all note 2801 numbers whose most recent checkpoint history appearance is in an N- 2802 active NoteOff command. 2804 A note number MUST NOT be coded in both structures. 2806 All note logs and NoteOff bitfield set bits MUST code the most recent N- 2807 active NoteOn or NoteOff reference to a note number in the session 2808 history. 2810 The note log list MUST obey the oldest-first ordering rule (defined in 2811 Appendix A.1). 2813 A.6.1. Header Structure 2815 The header for Chapter N, shown in Figure A.6.2, codes the size of the 2816 note list and bitfield structures. 2818 0 1 2819 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2820 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2821 |B| LEN | LOW | HIGH | 2822 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2824 Figure A.6.2 -- Chapter N header 2826 The LEN field, a 7-bit integer value, codes the number of 2-octet note 2827 logs in the note list. Zero is a valid value for LEN and codes an empty 2828 note list. 2830 The 4-bit LOW and HIGH fields code the number of OFFBITS octets that 2831 follow the note log list. LOW and HIGH are unsigned integer values. If 2832 LOW <= HIGH, there are (HIGH - LOW + 1) OFFBITS octets in the chapter. 2833 The value pairs (LOW = 15, HIGH = 0) and (LOW = 15, HIGH = 1) code an 2834 empty NoteOff bitfield structure (i.e., no OFFBITS octets). Other (LOW 2835 > HIGH) value pairs MUST NOT appear in the header. 2837 The B bit provides S-bit functionality (Appendix A.1) for the NoteOff 2838 bitfield structure. By default, the B bit MUST be set to 1. However, 2839 if the MIDI command section of the previous packet (packet I - 1, with I 2840 as defined in Appendix A.1) includes a NoteOff command for the channel, 2841 the B bit MUST be set to 0. If the B bit is set to 0, the higher-level 2842 recovery journal elements that contain Chapter N MUST have S bits that 2843 are set to 0, including the top-level journal header. 2845 The LEN value of 127 codes a note list length of 127 or 128 note logs, 2846 depending on the values of LOW and HIGH. If LEN = 127, LOW = 15, and 2847 HIGH = 0, the note list holds 128 note logs, and the NoteOff bitfield 2848 structure is empty. For other values of LOW and HIGH, LEN = 127 codes 2849 that the note list contains 127 note logs. In this case, the chapter 2850 has (HIGH - LOW + 1) NoteOff OFFBITS octets if LOW <= HIGH and has no 2851 OFFBITS octets if LOW = 15 and HIGH = 1. 2853 A.6.2. Note Structures 2855 Figure A.6.3 shows the 2-octet note log structure. 2857 0 1 2858 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2859 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2860 |S| NOTENUM |Y| VELOCITY | 2861 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2863 Figure A.6.3 -- Chapter N note log 2865 The 7-bit NOTENUM field codes the note number for the log. A note 2866 number MUST NOT be represented by multiple note logs in the note list. 2868 The 7-bit VELOCITY field codes the velocity value for the most recent N- 2869 active NoteOn command for the note number in the session history. 2870 Multiple overlapping NoteOns for a given note number may be coded using 2871 Chapter E, as discussed in Appendix A.7. 2873 VELOCITY is never zero; NoteOn commands with zero velocity are coded as 2874 NoteOff commands in the NoteOff bitfield structure. 2876 The note log does not code the execution time of the NoteOn command. 2877 However, the Y bit codes a hint from the sender about the NoteOn 2878 execution time. The Y bit codes a recommendation to play (Y = 1) or 2879 skip (Y = 0) the NoteOn command recovered from the note log. See 2880 Section 4.2 of [RFC4696] for non-normative guidance on the use of the Y 2881 bit. 2883 Figure A.6.1 shows the NoteOff bitfield structure, as the list of 2884 OFFBITS octets at the end of the chapter. A NoteOff OFFBITS octet codes 2885 NoteOff information for eight consecutive MIDI note numbers, with the 2886 most-significant bit representing the lowest note number. The most- 2887 significant bit of the first OFFBITS octet codes the note number 8*LOW; 2888 the most-significant bit of the last OFFBITS octet codes the note number 2889 8*HIGH. 2891 A set bit codes a NoteOff command for the note number. In the most 2892 efficient coding for the NoteOff bitfield structure, the first and last 2893 octets of the structure contain at least one set bit. Note that Chapter 2894 N does not code NoteOff velocity data. 2896 Note that in the general case, the recovery journal does not code the 2897 relative placement of a NoteOff command and a Change Control command for 2898 controller 64 (Damper Pedal (Sustain)). In many cases, a receiver 2899 processing a loss event may deduce this relative placement from the 2900 history of the stream and thus determine if a NoteOff note is sustained 2901 by the pedal. If such a determination is not possible, receivers SHOULD 2902 err on the side of silencing pedal sustains, as erroneously sustained 2903 notes may produce unpleasant (albeit transient) artifacts. 2905 A.7. Chapter E: MIDI Note Command Extras 2907 Readers may wish to review the Appendix A.1 definition of "N-active 2908 commands" before reading this appendix. In this appendix, a NoteOn 2909 command with a velocity of 0 is considered to be a NoteOff command with 2910 a release velocity value of 64. 2912 Chapter E encodes recovery information about MIDI NoteOn (0x9) and 2913 NoteOff (0x8) command features that rarely appear in MIDI streams. 2914 Receivers use Chapter E to reduce transient artifacts for streams where 2915 several NoteOn commands appear for a note number without an intervening 2916 NoteOff. Receivers also use Chapter E to reduce transient artifacts for 2917 streams that use NoteOff release velocity. Chapter E supplements the 2918 note information coded in Chapter N (Appendix A.6). 2920 Figure A.7.1 shows the format for Chapter E. 2922 0 1 2 3 2923 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 2924 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2925 |S| LEN |S| NOTENUM |V| COUNT/VEL |S| NOTENUM | 2926 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2927 |V| COUNT/VEL | .... | 2928 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2930 Figure A.7.1 -- Chapter E format 2932 The chapter consists of a 1-octet header, followed by a variable-length 2933 list of 2-octet note logs. Appendix A.7.1 defines the bitfield format 2934 for a note log. 2936 The log list MUST contain at least one note log. The 7-bit LEN header 2937 field codes the number of note logs in the list, minus one. A channel 2938 journal MUST contain Chapter E if the rules defined in this appendix 2939 require that one or more note logs appear in the list. The note log 2940 list MUST obey the oldest-first ordering rule (defined in Appendix A.1). 2942 A.7.1. Note Log Format 2944 Figure A.7.2 reproduces the note log structure of Chapter E. 2946 0 1 2947 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2948 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2949 |S| NOTENUM |V| COUNT/VEL | 2950 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2952 Figure A.7.2 -- Chapter E note log 2954 A note log codes information about the MIDI note number coded by the 2955 7-bit NOTENUM field. The nature of the information depends on the value 2956 of the V flag bit. 2958 If the V bit is set to 1, the COUNT/VEL field codes the release velocity 2959 value for the most recent N-active NoteOff command for the note number 2960 that appears in the session history. 2962 If the V bit is set to 0, the COUNT/VEL field codes a reference count of 2963 the number of NoteOn and NoteOff commands for the note number that 2964 appear in the session history. 2966 The reference count is set to 0 at the start of the session. NoteOn 2967 commands increment the count by 1. NoteOff commands decrement the count 2968 by 1. However, a decrement that generates a negative count value is not 2969 performed. 2971 If the reference count is in the range 0-126, the 7-bit COUNT/VEL field 2972 codes an unsigned integer representation of the count. If the count is 2973 greater than or equal to 127, COUNT/VEL is set to 127. 2975 By default, the count is reset to 0 whenever a Reset State command 2976 (Appendix A.1) appears in the session history, and whenever MIDI Control 2977 Change commands for controller numbers 123-127 (numbers with All Notes 2978 Off semantics) or 120 (All Sound Off) appear in the session history. 2980 A.7.2. Log Inclusion Rules 2982 If the most recent N-active NoteOn or NoteOff command for a note number 2983 in the checkpoint history is a NoteOff command with a release velocity 2984 value other than 64, a note log whose V bit is set to 1 MUST appear in 2985 Chapter E for the note number. 2987 If the most recent N-active NoteOn or NoteOff command for a note number 2988 in the checkpoint history is a NoteOff command, and if the reference 2989 count for the note number is greater than 0, a note log whose V bit is 2990 set to 0 MUST appear in Chapter E for the note number. 2992 If the most recent N-active NoteOn or NoteOff command for a note number 2993 in the checkpoint history is a NoteOn command, and if the reference 2994 count for the note number is greater than 1, a note log whose V bit is 2995 set to 0 MUST appear in Chapter E for the note number. 2997 At most, two note logs MAY appear in Chapter E for a note number: one 2998 log whose V bit is set to 0, and one log whose V bit is set to 1. 3000 Chapter E codes a maximum of 128 note logs. If the log inclusion rules 3001 yield more than 128 REQUIRED logs, note logs whose V bit is set to 1 3002 MUST be dropped from Chapter E in order to reach the 128-log limit. 3003 Note logs whose V bit is set to 0 MUST NOT be dropped. 3005 Most MIDI streams do not use NoteOn and NoteOff commands in ways that 3006 would trigger the log inclusion rules. For these streams, Chapter E 3007 would never be REQUIRED to appear in a channel journal. 3009 The ch_never parameter (Appendix C.2.3) may be used to configure the log 3010 inclusion rules for Chapter E. 3012 A.8. Chapter T: MIDI Channel Aftertouch 3014 A channel journal MUST contain Chapter T if an N-active and C-active 3015 MIDI Channel Aftertouch (0xD) command appears in the checkpoint history. 3016 Figure A.8.1 shows the format for Chapter T. 3018 0 3019 0 1 2 3 4 5 6 7 3020 +-+-+-+-+-+-+-+-+ 3021 |S| PRESSURE | 3022 +-+-+-+-+-+-+-+-+ 3024 Figure A.8.1 -- Chapter T format 3026 The chapter has a fixed size of 8 bits. The 7-bit PRESSURE field holds 3027 the pressure value of the most recent N-active and C-active Channel 3028 Aftertouch command in the session history. 3030 Chapter T only encodes commands that are C-active and N-active. We 3031 define a C-active restriction because [RP015] declares that a Control 3032 Change command for controller 121 (Reset All Controllers) acts to reset 3033 the channel pressure to 0 (see the discussion at the end of Appendix A.5 3034 for a more complete rationale). 3036 We define an N-active restriction on the assumption that aftertouch 3037 commands are linked to note activity, and thus Channel Aftertouch 3038 commands that are not N-active are stale and should not be used to 3039 repair a stream. 3041 A.9. Chapter A: MIDI Poly Aftertouch 3043 A channel journal MUST contain Chapter A if a C-active Poly Aftertouch 3044 (0xA) command appears in the checkpoint history. Figure A.9.1 shows the 3045 format for Chapter A. 3047 0 1 2 3 3048 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 3049 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3050 |S| LEN |S| NOTENUM |X| PRESSURE |S| NOTENUM | 3051 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3052 |X| PRESSURE | .... | 3053 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3055 Figure A.9.1 -- Chapter A format 3057 The chapter consists of a 1-octet header, followed by a variable-length 3058 list of 2-octet note logs. A note log MUST appear for a note number if 3059 a C-active Poly Aftertouch command for the note number appears in the 3060 checkpoint history. A note number MUST NOT be represented by multiple 3061 note logs in the note list. The note log list MUST obey the oldest- 3062 first ordering rule (defined in Appendix A.1). 3064 The 7-bit LEN field codes the number of note logs in the list, minus 3065 one. Figure A.9.2 reproduces the note log structure of Chapter A. 3067 0 1 3068 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 3069 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3070 |S| NOTENUM |X| PRESSURE | 3071 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3073 Figure A.9.2 -- Chapter A note log 3075 The 7-bit PRESSURE field codes the pressure value of the most recent C- 3076 active Poly Aftertouch command in the session history for the MIDI note 3077 number coded in the 7-bit NOTENUM field. 3079 As a rule, the X bit MUST be set to 0. However, the X bit MUST be set 3080 to 1 if the command coded by the log appears before one of the following 3081 commands in the session history: MIDI Control Change numbers 123-127 3082 (numbers with All Notes Off semantics) or 120 (All Sound Off). 3084 We define C-active restrictions for Chapter A because [RP015] declares 3085 that a Control Change command for controller 121 (Reset All Controllers) 3086 acts to reset the polyphonic pressure to 0 (see the discussion at the 3087 end of Appendix A.5 for a more complete rationale). 3089 B. The Recovery Journal System Chapters 3091 B.1. System Chapter D: Simple System Commands 3093 The system journal MUST contain Chapter D if an active MIDI Reset 3094 (0xFF), MIDI Tune Request (0xF6), MIDI Song Select (0xF3), undefined 3095 MIDI System Common (0xF4 and 0xF5), or undefined MIDI System Real-time 3096 (0xF9 and 0xFD) command appears in the checkpoint history. 3098 Figure B.1.1 shows the variable-length format for Chapter D. 3100 0 1 2 3 3101 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 3102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3103 |S|B|G|H|J|K|Y|Z| Command logs ... | 3104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3106 Figure B.1.1 -- System Chapter D format 3108 The chapter consists of a 1-octet header, followed by one or more 3109 command logs. Header flag bits indicate the presence of command logs 3110 for the Reset (B = 1), Tune Request (G = 1), Song Select (H = 1), 3111 undefined System Common 0xF4 (J = 1), undefined System Common 0xF5 (K = 3112 1), undefined System Real-time 0xF9 (Y = 1), or undefined System Real- 3113 time 0xFD (Z = 1) commands. 3115 Command logs appear in a list following the header, in the order that 3116 the flag bits appear in the header. 3118 Figure B.1.2 shows the 1-octet command log format for the Reset and Tune 3119 Request commands. 3121 0 3122 0 1 2 3 4 5 6 7 3123 +-+-+-+-+-+-+-+-+ 3124 |S| COUNT | 3125 +-+-+-+-+-+-+-+-+ 3127 Figure B.1.2 -- Command log for Reset and Tune Request 3129 Chapter D MUST contain the Reset command log if an active Reset command 3130 appears in the checkpoint history. The 7-bit COUNT field codes the 3131 total number of Reset commands (modulo 128) present in the session 3132 history. 3134 Chapter D MUST contain the Tune Request command log if an active Tune 3135 Request command appears in the checkpoint history. The 7-bit COUNT 3136 field codes the total number of Tune Request commands (modulo 128) 3137 present in the session history. 3139 For these commands, the COUNT field acts as a reference count. See the 3140 definition of "session history reference counts" in Appendix A.1 for 3141 more information. 3143 Figure B.1.3 shows the 1-octet command log format for the Song Select 3144 command. 3146 0 3147 0 1 2 3 4 5 6 7 3148 +-+-+-+-+-+-+-+-+ 3149 |S| VALUE | 3150 +-+-+-+-+-+-+-+-+ 3152 Figure B.1.3 -- Song Select command log format 3154 Chapter D MUST contain the Song Select command log if an active Song 3155 Select command appears in the checkpoint history. The 7-bit VALUE field 3156 codes the song number of the most recent active Song Select command in 3157 the session history. 3159 B.1.1. Undefined System Commands 3161 In this section, we define the Chapter D command logs for the undefined 3162 System commands. [MIDI] reserves the undefined System commands 0xF4, 3163 0xF5, 0xF9, and 0xFD for future use. At the time of this writing, any 3164 MIDI command stream that uses these commands is non-compliant with 3165 [MIDI]. However, future versions of [MIDI] may define these commands, 3166 and a few products do use these commands in a non-compliant manner. 3168 Figure B.1.4 shows the variable-length command log format for the 3169 undefined System Common commands (0xF4 and 0xF5). 3171 0 1 2 3 3172 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 3173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3174 |S|C|V|L|DSZ| LENGTH | COUNT | VALUE ... | 3175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3176 | LEGAL ... | 3177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3179 Figure B.1.4 -- Undefined System Common command log format 3181 The command log codes a single command type (0xF4 or 0xF5, not both). 3182 Chapter D MUST contain a command log if an active 0xF4 command appears 3183 in the checkpoint history and MUST contain an independent command log if 3184 an active 0xF5 command appears in the checkpoint history. 3186 A Chapter D Undefined System Common command log consists of a two-octet 3187 header followed by a variable number of data fields. Header flag bits 3188 indicate the presence of the COUNT field (C = 1), the VALUE field (V = 3189 1), and the LEGAL field (L = 1). The 10-bit LENGTH field codes the size 3190 of the command log and conforms to semantics described in Appendix A.1. 3192 The 2-bit DSZ field codes the number of data octets in the command 3193 instance that appears most recently in the session history. If DSZ = 3194 0-2, the command has 0-2 data octets. If DSZ = 3, the command has 3 or 3195 more command data octets. 3197 We now define the default rules for the use of the COUNT, VALUE, and 3198 LEGAL fields. The session configuration tools defined in Appendix C.2.3 3199 may be used to override this behavior. 3201 By default, if the DSZ field is set to 0, the command log MUST include 3202 the COUNT field. The 8-bit COUNT field codes the total number of 3203 commands of the type coded by the log (0xF4 or 0xF5) present in the 3204 session history, modulo 256. 3206 By default, if the DSZ field is set to 1-3, the command log MUST include 3207 the VALUE field. The variable-length VALUE field codes a verbatim copy 3208 the data octets for the most recent use of the command type coded by the 3209 log (0xF4 or 0xF5) in the session history. The most-significant bit of 3210 the final data octet MUST be set to 1, and the most-significant bit of 3211 all other data octets MUST be set to 0. 3213 The LEGAL field is reserved for future use. If an update to [MIDI] 3214 defines the 0xF4 or 0xF5 command, an IETF standards-track document may 3215 define the LEGAL field. Until such a document appears, senders MUST NOT 3216 use the LEGAL field, and receivers MUST use the LENGTH field to skip 3217 over the LEGAL field. The LEGAL field would be defined by the IETF if 3218 the semantics of the new 0xF4 or 0xF5 command could not be protected 3219 from packet loss via the use of the COUNT and VALUE fields. 3221 Figure B.1.5 shows the variable-length command log format for the 3222 undefined System Real-time commands (0xF9 and 0xFD). 3224 0 1 2 3 3225 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 3226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3227 |S|C|L| LENGTH | COUNT | LEGAL ... | 3228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3230 Figure B.1.5 -- Undefined System Real-time command log format 3232 The command log codes a single command type (0xF9 or 0xFD, not both). 3233 Chapter D MUST contain a command log if an active 0xF9 command appears 3234 in the checkpoint history and MUST contain an independent command log if 3235 an active 0xFD command appears in the checkpoint history. 3237 A Chapter D Undefined System Real-time command log consists of a one- 3238 octet header followed by a variable number of data fields. Header flag 3239 bits indicate the presence of the COUNT field (C = 1) and the LEGAL 3240 field (L = 1). The 5-bit LENGTH field codes the size of the command log 3241 and conforms to semantics described in Appendix A.1. 3243 We now define the default rules for the use of the COUNT and LEGAL 3244 fields. The session configuration tools defined in Appendix C.2.3 may 3245 be used to override this behavior. 3247 The 8-bit COUNT field codes the total number of commands of the type 3248 coded by the log present in the session history, modulo 256. By 3249 default, the COUNT field MUST be present in the command log. 3251 The LEGAL field is reserved for future use. If an update to [MIDI] 3252 defines the 0xF9 or 0xFD command, an IETF standards-track document may 3253 define the LEGAL field to protect the command. Until such a document 3254 appears, senders MUST NOT use the LEGAL field, and receivers MUST use 3255 the LENGTH field to skip over the LEGAL field. The LEGAL field would be 3256 defined by the IETF if the semantics of the new 0xF9 or 0xFD command 3257 could not be protected from packet loss via the use of the COUNT field. 3259 Finally, we note that some non-standard uses of the undefined System 3260 Real-time commands act to implement non-compliant variants of the MIDI 3261 sequencer system. In Appendix B.3.1, we describe resiliency tools for 3262 the MIDI sequencer system that provide some protection in this case. 3264 B.2. System Chapter V: Active Sense Command 3266 The system journal MUST contain Chapter V if an active MIDI Active Sense 3267 (0xFE) command appears in the checkpoint history. Figure B.2.1 shows 3268 the format for Chapter V. 3270 0 3271 0 1 2 3 4 5 6 7 3272 +-+-+-+-+-+-+-+-+ 3273 |S| COUNT | 3274 +-+-+-+-+-+-+-+-+ 3276 Figure B.2.1 -- System Chapter V format 3278 The 7-bit COUNT field codes the total number of Active Sense commands 3279 (modulo 128) present in the session history. The COUNT field acts as a 3280 reference count. See the definition of "session history reference 3281 counts" in Appendix A.1 for more information. 3283 B.3. System Chapter Q: Sequencer State Commands 3285 This appendix describes Chapter Q, the system chapter for the MIDI 3286 sequencer commands. 3288 The system journal MUST contain Chapter Q if an active MIDI Song 3289 Position Pointer (0xF2), MIDI Clock (0xF8), MIDI Start (0xFA), MIDI 3290 Continue (0xFB), or MIDI Stop (0xFC) command appears in the checkpoint 3291 history, and if the rules defined in this appendix require a change in 3292 the Chapter Q bitfield contents because of the command appearance. 3294 Figure B.3.1 shows the variable-length format for Chapter Q. 3296 0 1 2 3 3297 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 3298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3299 |S|N|D|C|T| TOP | CLOCK | TIMETOOLS ... | 3300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3301 | ... | 3302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3304 Figure B.3.1 -- System Chapter Q format 3306 Chapter Q consists of a 1-octet header followed by several optional 3307 fields, in the order shown in Figure B.3.1. 3309 Header flag bits signal the presence of the 16-bit CLOCK field (C = 1) 3310 and the 24-bit TIMETOOLS field (T = 1). The 3-bit TOP header field is 3311 interpreted as an unsigned integer, as are CLOCK and TIMETOOLS. We 3312 describe the TIMETOOLS field in Appendix B.3.1. 3314 Chapter Q encodes the most recent state of the sequencer system. 3315 Receivers use the chapter to re-synchronize the sequencer after a packet 3316 loss episode. Chapter fields encode the on/off state of the sequencer, 3317 the current position in the song, and the downbeat. 3319 The N header bit encodes the relative occurrence of the Start, Stop, and 3320 Continue commands in the session history. If an active Start or 3321 Continue command appears most recently, the N bit MUST be set to 1. If 3322 an active Stop appears most recently, or if no active Start, Stop, or 3323 Continue commands appear in the session history, the N bit MUST be set 3324 to 0. 3326 The C header flag, the TOP header field, and the CLOCK field act to code 3327 the current position in the sequence: 3329 o If C = 1, the 3-bit TOP header field and the 16-bit 3330 CLOCK field are combined to form the 19-bit unsigned quantity 3331 65536*TOP + CLOCK. This value encodes the song position 3332 in units of MIDI Clocks (24 clocks per quarter note), 3333 modulo 524288. Note that the maximum song position value 3334 that may be coded by the Song Position Pointer command is 3335 98303 clocks (which may be coded with 17 bits), and that 3336 MIDI-coded songs are generally constructed to avoid durations 3337 longer than this value. However, the 19-bit size may be useful 3338 for real-time applications, such as a drum machine MIDI output 3339 that is sending clock commands for long periods of time. 3341 o If C = 0, the song position is the start of the song. 3342 The C = 0 position is identical to the position coded 3343 by C = 1, TOP = 0, and CLOCK = 0, for the case where 3344 the song position is less than 524288 MIDI clocks. 3345 In certain situations (defined later in this section), 3346 normative text may require the C = 0 or the C = 1, 3347 TOP = 0, CLOCK = 0 encoding of the start of the song. 3349 The C, TOP, and CLOCK fields MUST be set to code the current song 3350 position, for both N = 0 and N = 1 conditions. If C = 0, the TOP field 3351 MUST be set to 0. See [MIDI] for a precise definition of a song 3352 position. 3354 The D header bit encodes information about the downbeat and acts to 3355 qualify the song position coded by the C, TOP, and CLOCK fields. 3357 If the D bit is set to 1, the song position represents the most recent 3358 position in the sequence that has played. If D = 1, the next Clock 3359 command (if N = 1) or the next (Continue, Clock) pair (if N = 0) acts to 3360 increment the song position by one clock, and to play the updated 3361 position. 3363 If the D bit is set to 0, the song position represents a position in the 3364 sequence that has not yet been played. If D = 0, the next Clock command 3365 (if N = 1) or the next (Continue, Clock) pair (if N = 0) acts to play 3366 the point in the song coded by the song position. The song position is 3367 not incremented. 3369 An example of a stream that uses D = 0 coding is one whose most recent 3370 sequence command is a Start or Song Position Pointer command (both N = 1 3371 conditions). However, it is also possible to construct examples where D 3372 = 0 and N = 0. A Start command immediately followed by a Stop command 3373 is coded in Chapter Q by setting C = 0, D = 0, N = 0, TOP = 0. 3375 If N = 1 (coding Start or Continue), D = 0 (coding that the downbeat has 3376 yet to be played), and the song position is at the start of the song, 3377 the C = 0 song position encoding MUST be used if a Start command occurs 3378 more recently than a Continue command in the session history, and the C 3379 = 1, TOP = 0, CLOCK = 0 song position encoding MUST be used if a 3380 Continue command occurs more recently than a Start command in the 3381 session history. 3383 B.3.1. Non-compliant Sequencers 3385 The Chapter Q description in this appendix assumes that the sequencer 3386 system counts off time with Clock commands, as mandated in [MIDI]. 3387 However, a few non-compliant products do not use Clock commands to count 3388 off time, but instead use non-standard methods. 3390 Chapter Q uses the TIMETOOLS field to provide resiliency support for 3391 these non-standard products. By default, the TIMETOOLS field MUST NOT 3392 appear in Chapter Q, and the T header bit MUST be set to 0. The session 3393 configuration tools described in Appendix C.2.3 may be used to select 3394 TIMETOOLS coding. 3396 Figure B.3.2 shows the format of the 24-bit TIMETOOLS field. 3398 0 1 2 3399 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 3400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3401 | TIME | 3402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3404 Figure B.3.2 -- TIMETOOLS format 3406 The TIME field is a 24-bit unsigned integer quantity, with units of 3407 milliseconds. TIME codes an additive correction term for the song 3408 position coded by the TOP, CLOCK, and C fields. TIME is coded in 3409 network byte order (big-endian). 3411 A receiver computes the correct song position by converting TIME into 3412 units of MIDI clocks and adding it to 65536*TOP + CLOCK (assuming C = 3413 1). Alternatively, a receiver may convert 65536*TOP + CLOCK into 3414 milliseconds (assuming C = 1) and add it to TIME. The downbeat (D 3415 header bit) semantics defined in Appendix B.3 apply to the corrected 3416 song position. 3418 B.4. System Chapter F: MIDI Time Code Tape Position 3420 This appendix describes Chapter F, the system chapter for the MIDI Time 3421 Code (MTC) commands. Readers may wish to review the Appendix A.1 3422 definition of "finished/unfinished commands" before reading this 3423 appendix. 3425 The system journal MUST contain Chapter F if an active System Common 3426 Quarter Frame command (0xF1) or an active finished System Exclusive 3427 (Universal Real Time) MTC Full Frame command (F0 7F cc 01 01 hr mn sc fr 3428 F7) appears in the checkpoint history. Otherwise, the system journal 3429 MUST NOT contain Chapter F. 3431 Figure B.4.1 shows the variable-length format for Chapter F. 3433 0 1 2 3 3434 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 3435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3436 |S|C|P|Q|D|POINT| COMPLETE ... | 3437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3438 | ... | PARTIAL ... | 3439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3440 | ... | 3441 +-+-+-+-+-+-+-+-+ 3443 Figure B.4.1 -- System Chapter F format 3445 Chapter F holds information about recent MTC tape positions coded in the 3446 session history. Receivers use Chapter F to re-synchronize the MTC 3447 system after a packet loss episode. 3449 Chapter F consists of a 1-octet header followed by several optional 3450 fields, in the order shown in Figure B.4.1. The C and P header bits 3451 form a Table of Contents (TOC) and signal the presence of the 32-bit 3452 COMPLETE field (C = 1) and the 32-bit PARTIAL field (P = 1). 3454 The Q header bit codes information about the COMPLETE field format. If 3455 Chapter F does not contain a COMPLETE field, Q MUST be set to 0. 3457 The D header bit codes the tape movement direction. If the tape is 3458 moving forward, or if the tape direction is indeterminate, the D bit 3459 MUST be set to 0. If the tape is moving in the reverse direction, the D 3460 bit MUST be set to 1. In most cases, the ordering of commands in the 3461 session history clearly defines the tape direction. However, a few 3462 command sequences have an indeterminate direction (such as a session 3463 history consisting of one Full Frame command). 3465 The 3-bit POINT header field is interpreted as an unsigned integer. 3466 Appendix B.4.1 defines how the POINT field codes information about the 3467 contents of the PARTIAL field. If Chapter F does not contain a PARTIAL 3468 field, POINT MUST be set to 7 (if D = 0) or 0 (if D = 1). 3470 Chapter F MUST include the COMPLETE field if an active finished Full 3471 Frame command appears in the checkpoint history, or if an active Quarter 3472 Frame command that completes the encoding of a frame value appears in 3473 the checkpoint history. 3475 The COMPLETE field encodes the most recent active complete MTC frame 3476 value that appears in the session history. This frame value may take 3477 the form of a series of 8 active Quarter Frame commands (0xF1 0x0n 3478 through 0xF1 0x7n for forward tape movement, 0xF1 0x7n through 0xF1 0x0n 3479 for reverse tape movement) or may take the form of an active finished 3480 Full Frame command. 3482 If the COMPLETE field encodes a Quarter Frame command series, the Q 3483 header bit MUST be set to 1, and the COMPLETE field MUST have the format 3484 shown in Figure B.4.2. The 4-bit fields MT0 through MT7 code the data 3485 (lower) nibble for the Quarter Frame commands for Message Type 0 through 3486 Message Type 7 [MIDI]. These nibbles encode a complete frame value, in 3487 addition to fields reserved for future use by [MIDI]. 3489 0 1 2 3 3490 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 3491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3492 | MT0 | MT1 | MT2 | MT3 | MT4 | MT5 | MT6 | MT7 | 3493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3495 Figure B.4.2 -- COMPLETE field format, Q = 1 3497 In this usage, the frame value encoded in the COMPLETE field MUST be 3498 offset by 2 frames (relative to the frame value encoded in the Quarter 3499 Frame commands) if the frame value codes a 0xF1 0x0n through 0xF1 0x7n 3500 command sequence. This offset compensates for the two-frame latency of 3501 the Quarter Frame encoding for forward tape movement. No offset is 3502 applied if the frame value codes a 0xF1 0x7n through 0xF1 0x0n Quarter 3503 Frame command sequence. 3505 The most recent active complete MTC frame value may alternatively be 3506 encoded by an active finished Full Frame command. In this case, the Q 3507 header bit MUST be set to 0, and the COMPLETE field MUST have format 3508 shown in Figure B.4.3. The HR, MN, SC, and FR fields correspond to the 3509 hr, mn, sc, and fr data octets of the Full Frame command. 3511 0 1 2 3 3512 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 3513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3514 | HR | MN | SC | FR | 3515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3517 Figure B.4.3 -- COMPLETE field format, Q = 0 3519 B.4.1. Partial Frames 3521 The most recent active session history command that encodes MTC frame 3522 value data may be a Quarter Frame command other than a forward-moving 3523 0xF1 0x7n command (which completes a frame value for forward tape 3524 movement) or a reverse-moving 0xF1 0x1n command (which completes a frame 3525 value for reverse tape movement). 3527 We consider this type of Quarter Frame command to be associated with a 3528 partial frame value. The Quarter Frame sequence that defines a partial 3529 frame value MUST either start at Message Type 0 and increment 3530 contiguously to an intermediate Message Type less than 7, or start at 3531 Message Type 7 and decrement contiguously to an intermediate Message 3532 type greater than 0. A Quarter Frame command sequence that does not 3533 follow this pattern is not associated with a partial frame value. 3535 Chapter F MUST include a PARTIAL field if the most recent active command 3536 in the checkpoint history that encodes MTC frame value data is a Quarter 3537 Frame command that is associated with a partial frame value. Otherwise, 3538 Chapter F MUST NOT include a PARTIAL field. 3540 The partial frame value consists of the data (lower) nibbles of the 3541 Quarter Frame command sequence. The PARTIAL field codes the partial 3542 frame value, using the format shown in Figure B.4.2. Message Type 3543 fields that are not associated with a Quarter Frame command MUST be set 3544 to 0. 3546 The POINT header field identifies the Message Type fields in the PARTIAL 3547 field that code valid data. If P = 1, the POINT field MUST encode the 3548 unsigned integer value formed by the lower 3 bits of the upper nibble of 3549 the data value of the most recent active Quarter Frame command in the 3550 session history. If D = 0 and P = 1, POINT MUST take on a value in the 3551 range 0-6. If D = 1 and P = 1, POINT MUST take on a value in the range 3552 1-7. 3554 If D = 0, MT fields (Figure B.4.2) in the inclusive range from 0 up to 3555 and including the POINT value encode the partial frame value. If D = 1, 3556 MT fields in the inclusive range from 7 down to and including the POINT 3557 value encode the partial frame value. Note that, unlike the COMPLETE 3558 field encoding, senders MUST NOT add a 2-frame offset to the partial 3559 frame value encoded in PARTIAL. 3561 For the default semantics, if a recovery journal contains Chapter F, and 3562 if the session history codes a legal [MIDI] series of Quarter Frame and 3563 Full Frame commands, the chapter always contains a COMPLETE or a PARTIAL 3564 field (and may contain both fields). Thus, a one-octet Chapter F (C = P 3565 = 0) always codes the presence of an illegal command sequence in the 3566 session history (under some conditions, the C = 1, P = 0 condition may 3567 also code the presence of an illegal command sequence). The illegal 3568 command sequence conditions are transient in nature and usually indicate 3569 that a Quarter Frame command sequence began with an intermediate Message 3570 Type. 3572 B.5. System Chapter X: System Exclusive 3574 This appendix describes Chapter X, the system chapter for MIDI System 3575 Exclusive (SysEx) commands (0xF0). Readers may wish to review the 3576 Appendix A.1 definition of "finished/unfinished commands" before reading 3577 this appendix. 3579 Chapter X consists of a list of one or more command logs. Each log in 3580 the list codes information about a specific finished or unfinished SysEx 3581 command that appears in the session history. The system journal MUST 3582 contain Chapter X if the rules defined in Appendix B.5.2 require that 3583 one or more logs appear in the list. 3585 The log list is not preceded by a header. Instead, each log implicitly 3586 encodes its own length. Given the length of the N'th list log, the 3587 presence of the (N+1)'th list log may be inferred from the LENGTH field 3588 of the system journal header (Figure 10 in Section 5 of the main text). 3589 The log list MUST obey the oldest-first ordering rule (defined in 3590 Appendix A.1). 3592 B.5.1. Chapter Format 3594 Figure B.5.1 shows the bitfield format for the Chapter X command logs. 3596 0 1 2 3 3597 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 3598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3599 |S|T|C|F|D|L|STA| TCOUNT | COUNT | FIRST ... | 3600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3601 | DATA ... | 3602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3604 Figure B.5.1 -- Chapter X command log format 3606 A Chapter X command log consists of a 1-octet header, followed by the 3607 optional TCOUNT, COUNT, FIRST, and DATA fields. 3609 The T, C, F, and D header bits act as a Table of Contents (TOC) for the 3610 log. If T is set to 1, the 1-octet TCOUNT field appears in the log. If 3611 C is set to 1, the 1-octet COUNT field appears in the log. If F is set 3612 to 1, the variable-length FIRST field appears in the log. If D is set 3613 to 1, the variable-length DATA field appears in the log. 3615 The L header bit sets the coding tool for the log. We define the log 3616 coding tools in Appendix B.5.2. 3618 The STA field codes the status of the command coded by the log. The 3619 2-bit STA value is interpreted as an unsigned integer. If STA is 0, the 3620 log codes an unfinished command. Non-zero STA values code different 3621 classes of finished commands. An STA value of 1 codes a cancelled 3622 command, an STA value of 2 codes a command that uses the "dropped F7" 3623 construction, and an STA value of 3 codes all other finished commands. 3624 Section 3.2 in the main text describes cancelled and "dropped F7" 3625 commands. 3627 The S bit (Appendix A.1) of the first log in the list acts as the S bit 3628 for Chapter X. For the other logs in the list, the S bit refers to the 3629 log itself. The value of the "phantom" S bit associated with the first 3630 log is defined by the following rules: 3632 o If the list codes one log, the phantom S-bit value is 3633 the same as the Chapter X S-bit value. 3635 o If the list codes multiple logs, the phantom S-bit value is 3636 the logical OR of the S-bit value of the first and second 3637 command logs in the list. 3639 In all other respects, the S bit follows the semantics defined in 3640 Appendix A.1. 3642 The FIRST field (present if F = 1) encodes a variable-length unsigned 3643 integer value that sets the coverage of the DATA field. 3645 The FIRST field (present if F = 1) encodes a variable-length unsigned 3646 integer value that specifies which SysEx data bytes are encoded in the 3647 DATA field of the log. The FIRST field consists of an octet whose most- 3648 significant bit is set to 0, optionally preceded by one or more octets 3649 whose most-significant bit is set to 1. The algorithm shown in Figure 3650 B.5.2 decodes this format into an unsigned integer, to yield the value 3651 dec(FIRST). FIRST uses a variable-length encoding because dec(FIRST) 3652 references a data octet in a SysEx command, and a SysEx command may 3653 contain an arbitrary number of data octets. 3655 One-Octet FIRST value: 3657 Encoded form: 0ddddddd 3658 Decoded form: 00000000 00000000 00000000 0ddddddd 3660 Two-Octet FIRST value: 3662 Encoded form: 1ccccccc 0ddddddd 3663 Decoded form: 00000000 00000000 00cccccc cddddddd 3665 Three-Octet FIRST value: 3667 Encoded form: 1bbbbbbb 1ccccccc 0ddddddd 3668 Decoded form: 00000000 000bbbbb bbcccccc cddddddd 3670 Four-Octet FIRST value: 3672 Encoded form: 1aaaaaaa 1bbbbbbb 1ccccccc 0ddddddd 3673 Decoded form: 0000aaaa aaabbbbb bbcccccc cddddddd 3675 Figure B.5.2 -- Decoding FIRST field formats 3677 The DATA field (present if D = 1) encodes a modified version of the data 3678 octets of the SysEx command coded by the log. Status octets MUST NOT be 3679 coded in the DATA field. 3681 If F = 0, the DATA field begins with the first data octet of the SysEx 3682 command and includes all subsequent data octets for the command that 3683 appear in the session history. If F = 1, the DATA field begins with the 3684 (dec(FIRST) + 1)'th data octet of the SysEx command and includes all 3685 subsequent data octets for the command that appear in the session 3686 history. Note that the word "command" in the descriptions above refers 3687 to the original SysEx command as it appears in the source MIDI data 3688 stream, not to a particular MIDI list SysEx command segment. 3690 The length of the DATA field is coded implicitly, using the most- 3691 significant bit of each octet. The most-significant bit of the final 3692 octet of the DATA field MUST be set to 1. The most-significant bit of 3693 all other DATA octets MUST be set to 0. This coding method relies on 3694 the fact that the most-significant bit of a MIDI data octet is 0 by 3695 definition. Apart from this length-coding modification, the DATA field 3696 encodes a verbatim copy of all data octets it encodes. 3698 B.5.2. Log Inclusion Semantics 3700 Chapter X offers two tools to protect SysEx commands: the "recency" tool 3701 and the "list" tool. The tool definitions use the concept of the "SysEx 3702 type" of a command, which we now define. 3704 Each SysEx command instance in a session, excepting MTC Full Frame 3705 commands, is said to have a "SysEx type". Types are used in equality 3706 comparisons: two SysEx commands in a session are said to have "the same 3707 SysEx type" or "different SysEx types". 3709 If efficiency is not a concern, a sender may follow a simple typing 3710 rule: every SysEx command in the session history has a different SysEx 3711 type, and thus no two commands in the session have the same type. 3713 To improve efficiency, senders MAY implement exceptions to this rule. 3714 These exceptions declare that certain sets of SysEx command instances 3715 have the same SysEx type. Any command not covered by an exception 3716 follows the simple rule. We list exceptions below: 3718 o All commands with identical data octet fields (same number of 3719 data octets, same value for each data octet) have the same type. 3720 This rule MUST be applied to all SysEx commands in the session, 3721 or not at all. Note that the implementation of this exception 3722 requires no sender knowledge of the format and semantics of 3723 the SysEx commands in the stream, merely the ability to count 3724 and compare octets. 3726 o Two instances of the same command whose semantics set or report 3727 the value of the same "parameter" have the same type. The 3728 implementation of this exception requires specific knowledge of 3729 the format and semantics of SysEx commands. In practice, a 3730 sender implementation chooses to support this exception for 3731 certain classes of commands (such as the Universal System 3732 Exclusive commands defined in [MIDI]). If a sender supports 3733 this exception for a particular command in a class (for 3734 example, the Universal Real Time System Exclusive message 3735 for Master Volume, F0 F7 cc 04 01 vv vv F7, defined in [MIDI]), 3736 it MUST support the exception to all instances of this 3737 particular command in the session. 3739 We now use this definition of "SysEx type" to define the "recency" tool 3740 and the "list" tool for Chapter X. 3742 By default, the Chapter X log list MUST code sufficient information to 3743 protect the rendered MIDI performance from indefinite artifacts caused 3744 by the loss of all finished or unfinished active SysEx commands that 3745 appear in the checkpoint history (excluding finished MTC Full Frame 3746 commands, which are coded in Chapter F (Appendix B.4)). 3748 To protect a command of a specific SysEx type with the recency tool, 3749 senders MUST code a log in the log list for the most recent finished 3750 active instance of the SysEx type that appears in the checkpoint 3751 history. Additionally, if an unfinished active instance of the SysEx 3752 type appears in the checkpoint history, senders MUST code a log in the 3753 log list for the unfinished command instance. The L header bit of both 3754 command logs MUST be set to 0. 3756 To protect a command of a specific SysEx type with the list tool, 3757 senders MUST code a log in the Chapter X log list for each finished or 3758 unfinished active instance of the SysEx type that appears in the 3759 checkpoint history. The L header bit of list tool command logs MUST be 3760 set to 1. 3762 As a rule, a log REQUIRED by the list or recency tool MUST include a 3763 DATA field that codes all data octets that appear in the checkpoint 3764 history for the SysEx command instance associated with the log. The 3765 FIRST field MAY be used to configure a DATA field that minimally meets 3766 this requirement. 3768 An exception to this rule applies to cancelled commands (defined in 3769 Section 3.2). REQUIRED command logs associated with cancelled commands 3770 MAY be coded with no DATA field. However, if DATA appears in the log, 3771 DATA MUST code all data octets that appear in the checkpoint history for 3772 the command associated with the log. 3774 As defined by the preceding text in this section, by default all 3775 finished or unfinished active SysEx commands that appear in the 3776 checkpoint history (excluding finished MTC Full Frame commands) MUST be 3777 protected by the list tool or the recency tool. 3779 For some MIDI source streams, this default yields a Chapter X whose size 3780 is too large. For example, imagine that a sender begins to transcode a 3781 SysEx command with 10,000 data octets onto a UDP RTP stream "on the 3782 fly", by sending SysEx command segments as soon as data octets are 3783 delivered by the MIDI source. After 1000 octets have been sent, the 3784 expansion of Chapter X yields an RTP packet that is too large to fit in 3785 the Maximum Transmission Unit (MTU) for the stream. 3787 In this situation, if a sender uses the closed-loop sending policy for 3788 SysEx commands, the RTP packet size may always be capped by stalling the 3789 stream. In a stream stall, once the packet reaches a maximum size, the 3790 sender refrains from sending new packets with non-empty MIDI Command 3791 Sections until receiver feedback permits the trimming of Chapter X. If 3792 the stream permits arbitrary commands to appear between SysEx segments 3793 (selectable during configuration using the tools defined in Appendix 3794 C.1), the sender may stall the SysEx segment stream but continue to code 3795 other commands in the MIDI list. 3797 Stalls are a workable but sub-optimal solution to Chapter X size issues. 3798 As an alternative to stalls, senders SHOULD take preemptive action 3799 during session configuration to reduce the anticipated size of Chapter 3800 X, using the methods described below: 3802 o Partitioned transport. Appendix C.5 provides tools 3803 for sending a MIDI name space over several RTP streams. 3804 Senders may use these tools to map a MIDI source 3805 into a low-latency UDP RTP stream (for channel commands 3806 and short SysEx commands) and a reliable [RFC4571] TCP stream 3807 (for bulk-data SysEx commands). The cm_unused and 3808 cm_used parameters (Appendix C.1) may be used to 3809 communicate the nature of the SysEx command partition. 3810 As TCP is reliable, the RTP MIDI TCP stream would not 3811 use the recovery journal. To minimize transmission 3812 latency for short SysEx commands, senders may begin 3813 segmental transmission for all SysEx commands over the 3814 UDP stream and then cancel the UDP transmission of long 3815 commands (using tools described in Section 3.2) and 3816 resend the commands over the TCP stream. 3818 o Selective protection. Journal protection may not be 3819 necessary for all SysEx commands in a stream. The 3820 ch_never parameter (Appendix C.2) may be used to 3821 communicate which SysEx commands are excluded from 3822 Chapter X. 3824 B.5.3. TCOUNT and COUNT Fields 3826 If the T header bit is set to 1, the 8-bit TCOUNT field appears in the 3827 command log. If the C header bit is set to 1, the 8-bit COUNT field 3828 appears in the command log. TCOUNT and COUNT are interpreted as 3829 unsigned integers. 3831 The TCOUNT field codes the total number of SysEx commands of the SysEx 3832 type coded by the log that appear in the session history, at the moment 3833 after the (finished or unfinished) command coded by the log enters the 3834 session history. 3836 The COUNT field codes the total number of SysEx commands that appear in 3837 the session history, excluding commands that are excluded from Chapter X 3838 via the ch_never parameter (Appendix C.2), at the moment after the 3839 (finished or unfinished) command coded by the log enters the session 3840 history. 3842 Command counting for TCOUNT and COUNT uses modulo-256 arithmetic. MTC 3843 Full Frame command instances (Appendix B.4) are included in command 3844 counting if the TCOUNT and COUNT definitions warrant their inclusion, as 3845 are cancelled commands (Section 3.2). 3847 Senders use the TCOUNT and COUNT fields to track the identity and (for 3848 TCOUNT) the sequence position of a command instance. Senders MUST use 3849 the TCOUNT or COUNT fields if identity or sequence information is 3850 necessary to protect the command type coded by the log. 3852 If a sender uses the COUNT field in a session, the final command log in 3853 every Chapter X in the stream MUST code the COUNT field. This rule lets 3854 receivers resynchronize the COUNT value after a packet loss. 3856 C. Session Configuration Tools 3858 In Sections 6.1-2 of the main text, we show session descriptions for 3859 minimal native and mpeg4-generic RTP MIDI streams. Minimal streams lack 3860 the flexibility to support some applications. In this appendix, we 3861 describe how to customize stream behavior through the use of the payload 3862 format parameters. 3864 The appendix begins with 6 sections, each devoted to parameters that 3865 affect a particular aspect of stream behavior: 3867 o Appendix C.1 describes the stream subsetting system 3868 (cm_unused and cm_used). 3870 o Appendix C.2 describes the journalling system (ch_anchor, 3871 ch_default, ch_never, j_sec, j_update). 3873 o Appendix C.3 describes MIDI command timestamp semantics 3874 (linerate, mperiod, octpos, tsmode). 3876 o Appendix C.4 describes the temporal duration ("media time") 3877 of an RTP MIDI packet (guardtime, rtp_maxptime, rtp_ptime). 3879 o Appendix C.5 concerns stream description (musicport). 3881 o Appendix C.6 describes MIDI rendering (chanmask, cid, 3882 inline, multimode, render, rinit, subrender, smf_cid, 3883 smf_info, smf_inline, smf_url, url). 3885 The parameters listed above may optionally appear in session 3886 descriptions of RTP MIDI streams. If these parameters are used in an 3887 SDP session description, the parameters appear on an fmtp attribute 3888 line. This attribute line applies to the payload type associated with 3889 the fmtp line. 3891 The parameters listed above add extra functionality ("features") to 3892 minimal RTP MIDI streams. In Appendix C.7, we show how to use these 3893 features to support two classes of applications: content-streaming using 3894 RTSP (Appendix C.7.1) and network musical performance using SIP 3895 (Appendix C.7.2). 3897 The participants in a multimedia session MUST share a common view of all 3898 of the RTP MIDI streams that appear in an RTP session, as defined by a 3899 single media (m=) line. In some RTP MIDI applications, the "common 3900 view" restriction makes it difficult to use sendrecv streams (all 3901 parties send and receive), as each party has its own requirements. For 3902 example, a two-party network musical performance application may wish to 3903 customize the renderer on each host to match the CPU performance of the 3904 host [NMP]. 3906 We solve this problem by using two RTP MIDI streams -- one sendonly, one 3907 recvonly -- in lieu of one sendrecv stream. The data flows in the two 3908 streams travel in opposite directions, to control receivers configured 3909 to use different renderers. In the third example in Appendix C.5, we 3910 show how the musicport parameter may be used to define virtual sendrecv 3911 streams. 3913 As a general rule, the RTP MIDI protocol does not handle parameter 3914 changes during a session well, because the parameters describe 3915 heavyweight or stateful configuration that is not easily changed once a 3916 session has begun. Thus, parties SHOULD NOT expect that parameter 3917 change requests during a session will be accepted by other parties. 3918 However, implementors SHOULD support in-session parameter changes that 3919 are easy to handle (for example, the guardtime parameter defined in 3920 Appendix C.4) and SHOULD be capable of accepting requests for changes of 3921 those parameters, as received by its session management protocol (for 3922 example, re-offers in SIP [RFC3264]). 3924 Appendix D defines the Augmented Backus-Naur Form (ABNF, [RFC5234]) 3925 syntax for the payload parameters. Section 11 provides information to 3926 the Internet Assigned Numbers Authority (IANA) on the media types and 3927 parameters defined in this document. 3929 Appendix C.6.5 defines the media type "audio/asc", a stored object for 3930 initializing mpeg4-generic renderers. As described in Appendix C.6, the 3931 audio/asc media type is assigned to the "rinit" parameter to specify an 3932 initialization data object for the default mpeg4-generic renderer. Note 3933 that RTP stream semantics are not defined for "audio/asc". Therefore, 3934 the "asc" subtype MUST NOT appear on the rtpmap line of a session 3935 description. 3937 C.1. Configuration Tools: Stream Subsetting 3939 As defined in Section 3.2 in the main text, the MIDI list of an RTP MIDI 3940 packet may encode any MIDI command that may legally appear on a MIDI 1.0 3941 DIN cable. 3943 In this appendix, we define two parameters (cm_unused and cm_used) that 3944 modify this default condition, by excluding certain types of MIDI 3945 commands from the MIDI list of all packets in a stream. For example, if 3946 a multimedia session partitions a MIDI name space into two RTP MIDI 3947 streams, the parameters may be used to define which commands appear in 3948 each stream. 3950 In this appendix, we define a simple language for specifying MIDI 3951 command types. If a command type is assigned to cm_unused, the commands 3952 coded by the string MUST NOT appear in the MIDI list. If a command type 3953 is assigned to cm_used, the commands coded by the string MAY appear in 3954 the MIDI list. 3956 The parameter list may code multiple assignments to cm_used and 3957 cm_unused. Assignments have a cumulative effect and are applied in the 3958 order of appearance in the parameter list. A later assignment of a 3959 command type to the same parameter expands the scope of the earlier 3960 assignment. A later assignment of a command type to the opposite 3961 parameter cancels (partially or completely) the effect of an earlier 3962 assignment. 3964 To initialize the stream subsetting system, "implicit" assignments to 3965 cm_unused and cm_used are processed before processing the actual 3966 assignments that appear in the parameter list. The System Common 3967 undefined commands (0xF4, 0xF5) and the System Real-Time Undefined 3968 commands (0xF9, 0xFD) are implicitly assigned to cm_unused. All other 3969 command types are implicitly assigned to cm_used. 3971 Note that the implicit assignments code the default behavior of an RTP 3972 MIDI stream as defined in Section 3.2 in the main text (namely, that all 3973 commands that may legally appear on a MIDI 1.0 DIN cable may appear in 3974 the stream). Also note that assignments of the System Common undefined 3975 commands (0xF4, 0xF5) apply to the use of these commands in the MIDI 3976 source command stream, not the special use of 0xF4 and 0xF5 in SysEx 3977 segment encoding defined in Section 3.2 in the main text. 3979 As a rule, parameter assignments obey the following syntax (see Appendix 3980 D for ABNF): 3982 = [channel list][field list] 3984 The command-type list is mandatory; the channel and field lists are 3985 optional. 3987 The command-type list specifies the MIDI command types for which the 3988 parameter applies. The command-type list is a concatenated sequence of 3989 one or more of the letters (ABCFGHJKMNPQTVWXYZ). The letters code the 3990 following command types: 3992 o A: Poly Aftertouch (0xA) 3993 o B: System Reset (0xFF) 3994 o C: Control Change (0xB) 3995 o F: System Time Code (0xF1) 3996 o G: System Tune Request (0xF6) 3997 o H: System Song Select (0xF3) 3998 o J: System Common Undefined (0xF4) 3999 o K: System Common Undefined (0xF5) 4000 o N: NoteOff (0x8), NoteOn (0x9) 4001 o P: Program Change (0xC) 4002 o Q: System Sequencer (0xF2, 0xF8, 0xFA, 0xFB, 0xFC) 4003 o T: Channel Aftertouch (0xD) 4004 o V: System Active Sense (0xFE) 4005 o W: Pitch Wheel (0xE) 4006 o X: SysEx (0xF0, 0xF7) 4007 o Y: System Real-Time Undefined (0xF9) 4008 o Z: System Real-Time Undefined (0xFD) 4010 In addition to the letters above, the letter M may also appear in the 4011 command-type list. The letter M refers to the MIDI parameter system 4012 (see definition in Appendix A.1 and in [MIDI]). An assignment of M to 4013 cm_unused codes that no RPN or NRPN transactions may appear in the MIDI 4014 list. 4016 Note that if cm_unused is assigned the letter M, Control Change (0xB) 4017 commands for the controller numbers in the standard controller 4018 assignment might still appear in the MIDI list. For an explanation, see 4019 Appendix A.3.4 for a discussion of the "general-purpose" use of 4020 parameter system controller numbers. 4022 In the text below, rules that apply to "MIDI voice channel commands" 4023 also apply to the letter M. 4025 The letters in the command-type list MUST be uppercase and MUST appear 4026 in alphabetical order. Letters other than (ABCFGHJKMNPQTVWXYZ) that 4027 appear in the list MUST be ignored. 4029 For MIDI voice channel commands, the channel list specifies the MIDI 4030 channels for which the parameter applies. If no channel list is 4031 provided, the parameter applies to all MIDI channels (0-15). The 4032 channel list takes the form of a list of channel numbers (0 through 15) 4033 and dash-separated channel number ranges (i.e., 0-5, 8-12, etc.). Dots 4034 (i.e., "." characters) separate elements in the channel list. 4036 Recall that System commands do not have a MIDI channel associated with 4037 them. Thus, for most command-type letters that code System commands (B, 4038 F, G, H, J, K, Q, V, Y, and Z), the channel list is ignored. 4040 For the command-type letter X, the appearance of certain numbers in the 4041 channel list codes special semantics. 4043 o The digit 0 codes that SysEx "cancel" sublists (Section 4044 3.2 in the main text) MUST NOT appear in the MIDI list. 4046 o The digit 1 codes that cancel sublists MAY appear in the 4047 MIDI list (the default condition). 4049 o The digit 2 codes that commands other than System 4050 Real-time MIDI commands MUST NOT appear between SysEx 4051 command segments in the MIDI list (the default condition). 4053 o The digit 3 codes that any MIDI command type may 4054 appear between SysEx command segments in the MIDI list, 4055 with the exception of the segmented encoding of a second 4056 SysEx command (verbatim SysEx commands are OK). 4058 For command-type X, the channel list MUST NOT contain both digits 0 and 4059 1, and it MUST NOT contain both digits 2 and 3. For command-type X, 4060 channel list numbers other than the numbers defined above are ignored. 4061 If X does not have a channel list, the semantics marked "the default 4062 condition" in the list above apply. 4064 The syntax for field lists in a parameter assignment follows the syntax 4065 for channel lists. If no field list is provided, the parameter applies 4066 to all controller or note numbers. 4068 For command-type C (Control Change), the field list codes the controller 4069 numbers (0-255) for which the parameter applies. 4071 For command-type M (Parameter System), the field list codes the 4072 Registered Parameter Numbers (RPNs) and Non-Registered Parameter Numbers 4073 (NRPNs) for which the parameter applies. The number range 0-16383 4074 specifies RPNs, the number range 16384-32767 specifies NRPNs (16384 4075 corresponds to NRPN 0, 32767 corresponds to NRPN 16383). 4077 For command-types N (NoteOn and NoteOff) and A (Poly Aftertouch), the 4078 field list codes the note numbers for which the parameter applies. 4080 For command-types J and K (System Common Undefined), the field list 4081 consists of a single digit, which specifies the number of data octets 4082 that follow the command octet. 4084 For command-type X (SysEx), the field list codes the number of data 4085 octets that may appear in a SysEx command. Thus, the field list 0-255 4086 specifies SysEx commands with 255 or fewer data octets, the field list 4087 256-4294967295 specifies SysEx commands with more than 255 data octets 4088 but excludes commands with 255 or fewer data octets, and the field list 4089 0 excludes all commands. 4091 A secondary parameter assignment syntax customizes command-type X (see 4092 Appendix D for complete ABNF): 4094 = "__" *( "_" ) "__" 4096 The assignment defines the class of SysEx commands that obeys the 4097 semantics of the assigned parameter. The command class is specified by 4098 listing the permitted values of the first N data octets that follow the 4099 SysEx 0xF0 command octet. Any SysEx command whose first N data octets 4100 match the list is a member of the class. 4102 Each defines a data octet of the command, as a dot-separated 4103 (".") list of one or more hexadecimal constants (such as "7F") or dash- 4104 separated hexadecimal ranges (such as "01-1F"). Underscores ("_") 4105 separate each . Double-underscores ("__") delineate the data 4106 octet list. 4108 Using this syntax, each assignment specifies a single SysEx command 4109 class. Session descriptions may use several assignments to cm_used and 4110 cm_unused to specify complex behaviors. 4112 The example session description below illustrates the use of the stream 4113 subsetting parameters: 4115 v=0 4116 o=lazzaro 2520644554 2838152170 IN IP6 first.example.net 4117 s=Example 4118 t=0 0 4119 m=audio 5004 RTP/AVP 96 4120 c=IN IP6 2001:DB80::7F2E:172A:1E24 4121 a=rtpmap:96 rtp-midi/44100 4122 a=fmtp:96 cm_unused=ACGHJKNMPTVWXYZ; cm_used=__7F_00-7F_01_01__ 4124 The session description configures the stream for use in clock 4125 applications. All voice channels are unused, as are all System Commands 4126 except those used for MIDI Time Code (command-type F, and the Full Frame 4127 SysEx command that is matched by the string assigned to cm_used), the 4128 System Sequencer commands (command-type Q), and System Reset (command- 4129 type B). 4131 C.2. Configuration Tools: The Journalling System 4133 In this appendix, we define the payload format parameters that configure 4134 stream journalling and the recovery journal system. 4136 The j_sec parameter (Appendix C.2.1) sets the journalling method for the 4137 stream. The j_update parameter (Appendix C.2.2) sets the recovery 4138 journal sending policy for the stream. Appendix C.2.2 also defines the 4139 sending policies of the recovery journal system. 4141 Appendix C.2.3 defines several parameters that modify the recovery 4142 journal semantics. These parameters change the default recovery journal 4143 semantics as defined in Section 5 and Appendices A-B. 4145 The journalling method for a stream is set at the start of a session and 4146 MUST NOT be changed thereafter. This requirement forbids changes to the 4147 j_sec parameter once a session has begun. 4149 A related requirement, defined in the appendix sections below, forbids 4150 the acceptance of parameter values that would violate the recovery 4151 journal mandate. In many cases, a change in one of the parameters 4152 defined in this appendix during an ongoing session would result in a 4153 violation of the recovery journal mandate for an implementation; in this 4154 case, the parameter change MUST NOT be accepted. 4156 C.2.1. The j_sec Parameter 4158 Section 2.2 defines the default journalling method for a stream. 4159 Streams that use unreliable transport (such as UDP) default to using the 4160 recovery journal. Streams that use reliable transport (such as TCP) 4161 default to not using a journal. 4163 The parameter j_sec may be used to override this default. This memo 4164 defines two symbolic values for j_sec: "none", to indicate that all 4165 stream payloads MUST NOT contain a journal section, and "recj", to 4166 indicate that all stream payloads MUST contain a journal section that 4167 uses the recovery journal format. 4169 For example, the j_sec parameter might be set to "none" for a UDP stream 4170 that travels between two hosts on a local network that is known to 4171 provide reliable datagram delivery. 4173 The session description below configures a UDP stream that does not use 4174 the recovery journal: 4176 v=0 4177 o=lazzaro 2520644554 2838152170 IN IP4 first.example.net 4178 s=Example 4179 t=0 0 4180 m=audio 5004 RTP/AVP 96 4181 c=IN IP4 192.0.2.94 4182 a=rtpmap:96 rtp-midi/44100 4183 a=fmtp:96 j_sec=none 4185 Other IETF standards-track documents may define alternative journal 4186 formats. These documents MUST define new symbolic values for the j_sec 4187 parameter to signal the use of the format. 4189 Parties MUST NOT accept a j_sec value that violates the recovery journal 4190 mandate (see Section 4 for details). If a session description uses a 4191 j_sec value unknown to the recipient, the recipient MUST NOT accept the 4192 description. 4194 Special j_sec issues arise when sessions are managed by session 4195 management tools (like RTSP, [RFC2326]) that use SDP for "declarative 4196 usage" purposes (see the preamble of Section 6 for details). For these 4197 session management tools, SDP does not code transport details (such as 4198 UDP or TCP) for the session. Instead, server and client negotiate 4199 transport details via other means (for RTSP, the SETUP method). 4201 In this scenario, the use of the j_sec parameter may be ill-advised, as 4202 the creator of the session description may not yet know the transport 4203 type for the session. In this case, the session description SHOULD 4204 configure the journalling system using the parameters defined in the 4205 remainder of Appendix C.2, but it SHOULD NOT use j_sec to set the 4206 journalling status. Recall that if j_sec does not appear in the session 4207 description, the default method for choosing the journalling method is 4208 in effect (no journal for reliable transport, recovery journal for 4209 unreliable transport). 4211 However, in declarative usage situations where the creator of the 4212 session description knows that journalling is always required or never 4213 required, the session description SHOULD use the j_sec parameter. 4215 C.2.2. The j_update Parameter 4217 In Section 4, we use the term "sending policy" to describe the method a 4218 sender uses to choose the checkpoint packet identity for each recovery 4219 journal in a stream. In the sub-sections that follow, we normatively 4220 define three sending policies: anchor, closed-loop, and open-loop. 4222 As stated in Section 4, the default sending policy for a stream is the 4223 closed-loop policy. The j_update parameter may be used to override this 4224 default. 4226 We define three symbolic values for j_update: "anchor", to indicate that 4227 the stream uses the anchor sending policy, "open-loop", to indicate that 4228 the stream uses the open-loop sending policy, and "closed-loop", to 4229 indicate that the stream uses the closed-loop sending policy. See 4230 Appendix C.2.3 for examples session descriptions that use the j_update 4231 parameter. 4233 Parties MUST NOT accept a j_update value that violates the recovery 4234 journal mandate (Section 4). 4236 Other IETF standards-track documents may define additional sending 4237 policies for the recovery journal system. These documents MUST define 4238 new symbolic values for the j_update parameter to signal the use of the 4239 new policy. If a session description uses a j_update value unknown to 4240 the recipient, the recipient MUST NOT accept the description. 4242 C.2.2.1. The anchor Sending Policy 4244 In the anchor policy, the sender uses the first packet in the stream as 4245 the checkpoint packet for all packets in the stream. The anchor policy 4246 satisfies the recovery journal mandate (Section 4), as the checkpoint 4247 history always covers the entire stream. 4249 The anchor policy does not require the use of the RTP control protocol 4250 (RTCP, [RFC3550]) or other feedback from receiver to sender. Senders do 4251 not need to take special actions to ensure that received streams start 4252 up free of artifacts, as the recovery journal always covers the entire 4253 history of the stream. Receivers are relieved of the responsibility of 4254 tracking the changing identity of the checkpoint packet, because the 4255 checkpoint packet never changes. 4257 The main drawback of the anchor policy is bandwidth efficiency. Because 4258 the checkpoint history covers the entire stream, the size of the 4259 recovery journals produced by this policy usually exceeds the journal 4260 size of alternative policies. For single-channel MIDI data streams, the 4261 bandwidth overhead of the anchor policy is often acceptable (see 4262 Appendix A.4 of [NMP]). For dense streams, the closed-loop or open-loop 4263 policies may be more appropriate. 4265 C.2.2.2. The closed-loop Sending Policy 4267 The closed-loop policy is the default policy of the recovery journal 4268 system. For each packet in the stream, the policy lets senders choose 4269 the smallest possible checkpoint history that satisfies the recovery 4270 journal mandate. As smaller checkpoint histories generally yield 4271 smaller recovery journals, the closed-loop policy reduces the bandwidth 4272 of a stream, relative to the anchor policy. 4274 The closed-loop policy relies on feedback from receiver to sender. The 4275 policy assumes that a receiver periodically informs the sender of the 4276 highest sequence number it has seen so far in the stream, coded in the 4277 32-bit extension format defined in [RFC3550]. For RTCP, receivers 4278 transmit this information in the Extended Highest Sequence Number 4279 Received (EHSNR) field of Receiver Reports. RTCP Sender or Receiver 4280 Reports MUST be sent by any participant in a session with closed loop 4281 sending policy, unless another feedback mechanism has been agreed upon. 4283 The sender may safely use receiver sequence number feedback to guide 4284 checkpoint history management, because Section 4 requires that receivers 4285 repair indefinite artifacts whenever a packet loss event occur. 4287 We now normatively define the closed-loop policy. At the moment a 4288 sender prepares an RTP packet for transmission, the sender is aware of R 4289 >= 0 receivers for the stream. Senders may become aware of a receiver 4290 via RTCP traffic from the receiver, via RTP packets from a paired stream 4291 sent by the receiver to the sender, via messages from a session 4292 management tool, or by other means. As receivers join and leave a 4293 session, the value of R changes. 4295 Each known receiver k (1 <= k <= R) is associated with a 32-bit extended 4296 packet sequence number M(k), where the extension reflects the sequence 4297 number rollover count of the sender. 4299 If the sender has received at least one feedback report from receiver k, 4300 M(k) is the most recent report of the highest RTP packet sequence number 4301 seen by the receiver, normalized to reflect the rollover count of the 4302 sender. 4304 If the sender has not received a feedback report from the receiver, M(k) 4305 is the extended sequence number of the last packet the sender 4306 transmitted before it became aware of the receiver. If the sender 4307 became aware of this receiver before it sent the first packet in the 4308 stream, M(k) is the extended sequence number of the first packet in the 4309 stream. 4311 Given this definition of M(), we now state the closed-loop policy. When 4312 preparing a new packet for transmission, a sender MUST choose a 4313 checkpoint packet with extended sequence number N, such that M(k) >= (N 4314 - 1) for all k, 1 <= k <= R, where R >= 1. The policy does not restrict 4315 sender behavior in the R == 0 (no known receivers) case. 4317 Under the closed-loop policy as defined above, a sender may transmit 4318 packets whose checkpoint history is shorter than the session history (as 4319 defined in Appendix A.1). In this event, a new receiver that joins the 4320 stream may experience indefinite artifacts. 4322 For example, if a Control Change (0xB) command for Channel Volume 4323 (controller number 7) was sent early in a stream, and later a new 4324 receiver joins the session, the closed-loop policy may permit all 4325 packets sent to the new receiver to use a checkpoint history that does 4326 not include the Channel Volume Control Change command. As a result, the 4327 new receiver experiences an indefinite artifact, and plays all notes on 4328 a channel too loudly or too softly. 4330 To address this issue, the closed-loop policy states that whenever a 4331 sender becomes aware of a new receiver, the sender MUST determine if the 4332 receiver would be subject to indefinite artifacts under the closed-loop 4333 policy. If so, the sender MUST ensure that the receiver starts the 4334 session free of indefinite artifacts. For example, to solve the Channel 4335 Volume issue described above, the sender may code the current state of 4336 the Channel Volume controller numbers in the recovery journal Chapter C, 4337 until it receives the first RTCP RR report that signals that a packet 4338 containing this Chapter C has been received. 4340 In satisfying this requirement, senders MAY infer the initial MIDI state 4341 of the receiver from the session description. For example, the stream 4342 example in Section 6.2 has the initial state defined in [MIDI] for 4343 General MIDI. 4345 In a unicast RTP session, a receiver may safely assume that the sender 4346 is aware of its presence as a receiver from the first packet sent in the 4347 RTP stream. However, in other types of RTP sessions (multicast, 4348 conference focus, RTP translator/mixer), a receiver is often not able to 4349 determine if the sender is initially aware of its presence as a 4350 receiver. 4352 To address this issue, the closed-loop policy states that if a receiver 4353 participates in a session where it may have access to a stream whose 4354 sender is not aware of the receiver, the receiver MUST take actions to 4355 ensure that its rendered MIDI performance does not contain indefinite 4356 artifacts. These protections will be necessarily incomplete. For 4357 example, a receiver may monitor the Checkpoint Packet Seqnum for 4358 uncovered loss events, and "err on the side of caution" with respect to 4359 handling stuck notes due to lost MIDI NoteOff commands, but the receiver 4360 is not able to compensate for the lack of Channel Volume initialization 4361 data in the recovery journal. 4363 The receiver MUST NOT discontinue these protective actions until it is 4364 certain that the sender is aware of its presence. If a receiver is not 4365 able to ascertain sender awareness, the receiver MUST continue these 4366 protective actions for the duration of the session. 4368 Note that in a multicast session where all parties are expected to send 4369 and receive, the reception of RTCP receiver reports from the sender 4370 about the RTP stream a receiver is multicasting back is evidence of the 4371 sender's awareness that the RTP stream multicast by the sender is being 4372 monitored by the receiver. Receivers may also obtain sender awareness 4373 evidence from session management tools, or by other means. In practice, 4374 ongoing observation of the Checkpoint Packet Seqnum to determine if the 4375 sender is taking actions to prevent loss events for a receiver is a good 4376 indication of sender awareness, as is the sudden appearance of recovery 4377 journal chapters with numerous Control Change controller data that was 4378 not foreshadowed by recent commands coded in the MIDI list shortly after 4379 sending an RTCP RR. 4381 The final set of normative closed-loop policy requirements concerns how 4382 senders and receivers handle unplanned disruptions of RTCP feedback from 4383 a receiver to a sender. By "unplanned", we refer to disruptions that 4384 are not due to the signalled termination of an RTP stream, via an RTCP 4385 BYE or via session management tools. 4387 As defined earlier in this section, the closed-loop policy states that a 4388 sender MUST choose a checkpoint packet with extended sequence number N, 4389 such that M(k) >= (N - 1) for all k, 1 <= k <= R, where R >= 1. If the 4390 sender has received at least one feedback report from receiver k, M(k) 4391 is the most recent report of the highest RTP packet sequence number seen 4392 by the receiver, normalized to reflect the rollover count of the sender. 4394 If this receiver k stops sending feedback to the sender, the M(k) value 4395 used by the sender reflects the last feedback report from the receiver. 4396 As time progresses without feedback from receiver k, this fixed M(k) 4397 value forces the sender to increase the size of the checkpoint history, 4398 and thus increases the bandwidth of the stream. 4400 At some point, the sender may need to take action in order to limit the 4401 bandwidth of the stream. In most envisioned uses of RTP MIDI, long 4402 before this point is reached, the SSRC time-out mechanism defined in 4403 [RFC3550] will remove the uncooperative receiver from the session (note 4404 that the closed-loop policy does not suggest or require any special 4405 sender behavior upon an SSRC time-out, other than the sender actions 4406 related to changing R, described earlier in this section). 4408 However, in rare situations, the bandwidth of the stream (due to a lack 4409 of feedback reports from the sender) may become too large to continue 4410 sending the stream to the receiver before the SSRC time-out occurs for 4411 the receiver. In this case, the closed-loop policy states that the 4412 sender should invoke the SSRC time-out for the receiver early. 4414 We now discuss receiver responsibilities in the case of unplanned 4415 disruptions of RTCP feedback from receiver to sender. 4417 In the unicast case, if a sender invokes the SSRC time-out mechanism for 4418 a receiver, the receiver stops receiving packets from the sender. The 4419 sender behavior imposed by the guardtime parameter (Appendix C.4.2) lets 4420 the receiver conclude that an SSRC time-out has occurred in a reasonable 4421 time period. 4423 In this case of a time-out, a receiver MUST keep sending RTCP feedback, 4424 in order to re-establish the RTP flow from the sender. Unless the 4425 receiver expects a prompt recovery of the RTP flow, the receiver MUST 4426 take actions to ensure that the rendered MIDI performance does not 4427 exhibit "very long transient artifacts" (for example, by silencing 4428 NoteOns to prevent stuck notes) while awaiting reconnection of the flow. 4430 In the multicast case, if a sender invokes the SSRC time-out mechanism 4431 for a receiver, the receiver may continue to receive packets, but the 4432 sender will no longer be using the M(k) feedback from the receiver to 4433 choose each checkpoint packet. If the receiver does not have additional 4434 information that precludes an SSRC time-out (such as RTCP Receiver 4435 Reports from the sender about an RTP stream the receiver is multicasting 4436 back to the sender), the receiver MUST monitor the Checkpoint Packet 4437 Seqnum to detect an SSRC time-out. If an SSRC time-out is detected, the 4438 receiver MUST follow the instructions for SSRC time-outs described for 4439 the unicast case above. 4441 Finally, we note that the closed-loop policy is suitable for use in 4442 RTP/RTCP sessions that use multicast transport. However, aspects of the 4443 closed-loop policy do not scale well to sessions with large numbers of 4444 participants. The sender state scales linearly with the number of 4445 receivers, as the sender needs to track the identity and M(k) value for 4446 each receiver k. The average recovery journal size is not independent 4447 of the number of receivers, as the RTCP reporting interval backoff slows 4448 down the rate of a full update of M(k) values. The backoff algorithm 4449 may also increase the amount of ancillary state used by implementations 4450 of the normative sender and receiver behaviors defined in Section 4. 4452 C.2.2.3. The open-loop Sending Policy 4454 The open-loop policy is suitable for sessions that are not able to 4455 implement the receiver-to-sender feedback required by the closed-loop 4456 policy, and that are also not able to use the anchor policy because of 4457 bandwidth constraints. 4459 The open-loop policy does not place constraints on how a sender chooses 4460 the checkpoint packet for each packet in the stream. In the absence of 4461 such constraints, a receiver may find that the recovery journal in the 4462 packet that ends a loss event has a checkpoint history that does not 4463 cover the entire loss event. We refer to loss events of this type as 4464 uncovered loss events. 4466 To ensure that uncovered loss events do not compromise the recovery 4467 journal mandate, the open-loop policy assigns specific recovery tasks to 4468 senders, receivers, and the creators of session descriptions. The 4469 underlying premise of the open-loop policy is that the indefinite 4470 artifacts produced during uncovered loss events fall into two classes. 4472 One class of artifacts is recoverable indefinite artifacts. Receivers 4473 are able to repair recoverable artifacts that occur during an uncovered 4474 loss event without intervention from the sender, at the potential cost 4475 of unpleasant transient artifacts. 4477 For example, after an uncovered loss event, receivers are able to repair 4478 indefinite artifacts due to NoteOff (0x8) commands that may have 4479 occurred during the loss event, by executing NoteOff commands for all 4480 active NoteOns commands. This action causes a transient artifact (a 4481 sudden silent period in the performance), but ensures that no stuck 4482 notes sound indefinitely. We refer to MIDI commands that are amenable 4483 to repair in this fashion as recoverable MIDI commands. 4485 A second class of artifacts is unrecoverable indefinite artifacts. If 4486 this class of artifact occurs during an uncovered loss event, the 4487 receiver is not able to repair the stream. 4489 For example, after an uncovered loss event, receivers are not able to 4490 repair indefinite artifacts due to Control Change (0xB) Channel Volume 4491 (controller number 7) commands that have occurred during the loss event. 4492 A repair is impossible because the receiver has no way of determining 4493 the data value of a lost Channel Volume command. We refer to MIDI 4494 commands that are fragile in this way as unrecoverable MIDI commands. 4496 The open-loop policy does not specify how to partition the MIDI command 4497 set into recoverable and unrecoverable commands. Instead, it assumes 4498 that the creators of the session descriptions are able to come to 4499 agreement on a suitable recoverable/unrecoverable MIDI command partition 4500 for an application. 4502 Given these definitions, we now state the normative requirements for the 4503 open-loop policy. 4505 In the open-loop policy, the creators of the session description MUST 4506 use the ch_anchor parameter (defined in Appendix C.2.3) to protect all 4507 unrecoverable MIDI command types from indefinite artifacts, or 4508 alternatively MUST use the cm_unused parameter (defined in Appendix C.1) 4509 to exclude the command types from the stream. These options act to 4510 shield command types from artifacts during an uncovered loss event. 4512 In the open-loop policy, receivers MUST examine the Checkpoint Packet 4513 Seqnum field of the recovery journal header after every loss event, to 4514 check if the loss event is an uncovered loss event. Section 5 shows how 4515 to perform this check. If an uncovered loss event has occurred, a 4516 receiver MUST perform indefinite artifact recovery for all MIDI command 4517 types that are not shielded by ch_anchor and cm_unused parameter 4518 assignments in the session description. 4520 The open-loop policy does not place specific constraints on the sender. 4521 However, the open-loop policy works best if the sender manages the size 4522 of the checkpoint history to ensure that uncovered losses occur 4523 infrequently, by taking into account the delay and loss characteristics 4524 of the network. Also, as each checkpoint packet change incurs the risk 4525 of an uncovered loss, senders should only move the checkpoint if it 4526 reduces the size of the journal. 4528 C.2.3. Recovery Journal Chapter Inclusion Parameters 4530 The recovery journal chapter definitions (Appendices A-B) specify under 4531 what conditions a chapter MUST appear in the recovery journal. In most 4532 cases, the definition states that if a certain command appears in the 4533 checkpoint history, a certain chapter type MUST appear in the recovery 4534 journal to protect the command. 4536 In this section, we describe the chapter inclusion parameters. These 4537 parameters modify the conditions under which a chapter appears in the 4538 journal. These parameters are essential to the use of the open-loop 4539 policy (Appendix C.2.2.3) and may also be used to simplify 4540 implementations of the closed-loop (Appendix C.2.2.2) and anchor 4541 (Appendix C.2.2.1) policies. 4543 Each parameter represents a type of chapter inclusion semantics. An 4544 assignment to a parameter declares which chapters (or chapter subsets) 4545 obey the inclusion semantics. We describe the assignment syntax for 4546 these parameters later in this section. 4548 A party MUST NOT accept chapter inclusion parameter values that violate 4549 the recovery journal mandate (Section 4). All assignments of the 4550 subsetting parameters (cm_used and cm_unused) MUST precede the first 4551 assignment of a chapter inclusion parameter in the parameter list. 4553 Below, we normatively define the semantics of the chapter inclusion 4554 parameters. For clarity, we define the action of parameters on complete 4555 chapters. If a parameter is assigned a subset of a chapter, the 4556 definition applies only to the chapter subset. 4558 o ch_never. A chapter assigned to the ch_never parameter MUST 4559 NOT appear in the recovery journal (Appendix A.4.1-2 defines 4560 exceptions to this rule for Chapter M). To signal the exclusion 4561 of a chapter from the journal, an assignment to ch_never MUST 4562 be made, even if the commands coded by the chapter are assigned 4563 to cm_unused. This rule simplifies the handling of commands 4564 types that may be coded in several chapters. 4566 o ch_default. A chapter assigned to the ch_default parameter 4567 MUST follow the default semantics for the chapter, as defined 4568 in Appendices A-B. 4570 o ch_anchor. A chapter assigned to the ch_anchor MUST obey a 4571 modified version of the default chapter semantics. In the 4572 modified semantics, all references to the checkpoint history 4573 are replaced with references to the session history, and all 4574 references to the checkpoint packet are replaced with 4575 references to the first packet sent in the stream. 4577 Parameter assignments obey the following syntax (see Appendix D for 4578 ABNF): 4580 = [channel list][field list] 4582 The chapter list is mandatory; the channel and field lists are optional. 4583 Multiple assignments to parameters have a cumulative effect and are 4584 applied in the order of parameter appearance in a media description. 4586 To determine the semantics of a list of chapter inclusion parameter 4587 assignments, we begin by assuming an implicit assignment of all channel 4588 and system chapters to the ch_default parameter, with the default values 4589 for the channel list and field list for each chapter that are defined 4590 below. 4592 We then interpret the semantics of the actual parameter assignments, 4593 using the rules below. 4595 A later assignment of a chapter to the same parameter expands the scope 4596 of the earlier assignment. In most cases, a later assignment of a 4597 chapter to a different parameter cancels (partially or completely) the 4598 effect of an earlier assignment. 4600 The chapter list specifies the channel or system chapters for which the 4601 parameter applies. The chapter list is a concatenated sequence of one 4602 or more of the letters corresponding to the chapter types 4603 (ACDEFMNPQTVWX). In addition, the list may contain one or more of the 4604 letters for the sub-chapter types (BGHJKYZ) of System Chapter D. 4606 The letters in a chapter list MUST be uppercase and MUST appear in 4607 alphabetical order. Letters other than (ABCDEFGHJKMNPQTVWXYZ) that 4608 appear in the chapter list MUST be ignored. 4610 The channel list specifies the channel journals for which this parameter 4611 applies; if no channel list is provided, the parameter applies to all 4612 channel journals. The channel list takes the form of a list of channel 4613 numbers (0 through 15) and dash-separated channel number ranges (i.e., 4614 0-5, 8-12, etc.). Dots (i.e., "." characters) separate elements in the 4615 channel list. 4617 Several of the systems chapters may be configured to have special 4618 semantics. Configuration occurs by specifying a channel list for the 4619 systems channel, using the coding described below (note that MIDI 4620 Systems commands do not have a "channel", and thus the original purpose 4621 of the channel list does not apply to systems chapters). The expression 4622 "the digit N" in the text below refers to the inclusion of N as a 4623 "channel" in the channel list for a systems chapter. 4625 For the J and K Chapter D sub-chapters (undefined System Common), the 4626 digit 0 codes that the parameter applies to the LEGAL field of the 4627 associated command log (Figure B.1.4 of Appendix B.1), the digit 1 codes 4628 that the parameter applies to the VALUE field of the command log, and 4629 the digit 2 codes that the parameter applies to the COUNT field of the 4630 command log. 4632 For the Y and Z Chapter D sub-chapters (undefined System Real-time), the 4633 digit 0 codes that the parameter applies to the LEGAL field of the 4634 associated command log (Figure B.1.5 of Appendix B.1) and the digit 1 4635 codes that the parameter applies to the COUNT field of the command log. 4637 For Chapter Q (Sequencer State Commands), the digit 0 codes that the 4638 parameter applies to the default Chapter Q definition, which forbids the 4639 TIME field. The digit 1 codes that the parameter applies to the 4640 optional Chapter Q definition, which supports the TIME field. 4642 The syntax for field lists follows the syntax for channel lists. If no 4643 field list is provided, the parameter applies to all controller or note 4644 numbers. For Chapter C, if no field list is provided, the controller 4645 numbers do not use enhanced Chapter C encoding (Appendix A.3.3). 4647 For Chapter C, the field list may take on values in the range 0 to 255. 4648 A field value X in the range 0-127 refers to a controller number X, and 4649 indicates that the controller number does not use enhanced Chapter C 4650 encoding. A field value X in the range 128-255 refers to a controller 4651 number "X minus 128" and indicates the controller number does use the 4652 enhanced Chapter C encoding. 4654 Assignments made to configure the Chapter C encoding method for a 4655 controller number MUST be made to the ch_default or ch_anchor 4656 parameters, as assignments to ch_never act to exclude the number from 4657 the recovery journal (and thus the indicated encoding method is 4658 irrelevant). 4660 A Chapter C field list MUST NOT encode conflicting information about the 4661 enhanced encoding status of a particular controller number. For 4662 example, values 0 and 128 MUST NOT both be coded by a field list. 4664 For Chapter M, the field list codes the Registered Parameter Numbers 4665 (RPNs) and Non-Registered Parameter Numbers (NRPNs) for which the 4666 parameter applies. The number range 0-16383 specifies RPNs, the number 4667 range 16384-32767 specifies NRPNs (16384 corresponds to NRPN 0, 32767 4668 corresponds to NRPN 16383). 4670 For Chapters N and A, the field list codes the note numbers for which 4671 the parameter applies. The note number range specified for Chapter N 4672 also applies to Chapter E. 4674 For Chapter E, the digit 0 codes that the parameter applies to Chapter E 4675 note logs whose V bit is set to 0, and the digit 1 codes that the 4676 parameter applies to note logs whose V bit is set to 1. 4678 For Chapter X, the field list codes the number of data octets that may 4679 appear in a SysEx command that is coded in the chapter. Thus, the field 4680 list 0-255 specifies SysEx commands with 255 or fewer data octets, the 4681 field list 256-4294967295 specifies SysEx commands with more than 255 4682 data octets but excludes commands with 255 or fewer data octets, and the 4683 field list 0 excludes all commands. 4685 A secondary parameter assignment syntax customizes Chapter X (see 4686 Appendix D for complete ABNF): 4688 = "__" *( "_" ) "__" 4690 The assignment defines a class of SysEx commands whose Chapter X coding 4691 obeys the semantics of the assigned parameter. The command class is 4692 specified by listing the permitted values of the first N data octets 4693 that follow the SysEx 0xF0 command octet. Any SysEx command whose first 4694 N data octets match the list is a member of the class. 4696 Each defines a data octet of the command, as a dot-separated 4697 (".") list of one or more hexadecimal constants (such as "7F") or dash- 4698 separated hexadecimal ranges (such as "01-1F"). Underscores ("_") 4699 separate each . Double-underscores ("__") delineate the data 4700 octet list. 4702 Using this syntax, each assignment specifies a single SysEx command 4703 class. Session descriptions may use several assignments to the same (or 4704 different) parameters to specify complex Chapter X behaviors. The 4705 ordering behavior of multiple assignments follows the guidelines for 4706 chapter parameter assignments described earlier in this section. 4708 The example session description below illustrates the use of the chapter 4709 inclusion parameters: 4711 v=0 4712 o=lazzaro 2520644554 2838152170 IN IP6 first.example.net 4713 s=Example 4714 t=0 0 4715 m=audio 5004 RTP/AVP 96 4716 c=IN IP6 2001:DB80::7F2E:172A:1E24 4717 a=rtpmap:96 rtp-midi/44100 4718 a=fmtp:96 j_update=open-loop; cm_unused=ABCFGHJKMQTVWXYZ; 4719 cm_used=__7E_00-7F_09_01.02.03__; 4720 cm_used=__7F_00-7F_04_01.02__; cm_used=C7.64; 4721 ch_never=ABCDEFGHJKMQTVWXYZ; ch_never=4.11-13N; 4722 ch_anchor=P; ch_anchor=C7.64; 4723 ch_anchor=__7E_00-7F_09_01.02.03__; 4724 ch_anchor=__7F_00-7F_04_01.02__ 4726 (The a=fmtp line has been wrapped to fit the page to accommodate 4727 memo formatting restrictions; it comprises a single line in SDP.) 4729 The j_update parameter codes that the stream uses the open-loop policy. 4730 Most MIDI command-types are assigned to cm_unused and thus do not appear 4731 in the stream. As a consequence, the assignments to the first ch_never 4732 parameter reflect that most chapters are not in use. 4734 Chapter N for several MIDI channels is assigned to ch_never. Chapter N 4735 for MIDI channels other than 4, 11, 12, and 13 may appear in the 4736 recovery journal, using the (default) ch_default semantics. In 4737 practice, this assignment pattern would reflect knowledge about a 4738 resilient rendering method in use for the excluded channels. 4740 The MIDI Program Change command and several MIDI Control Change 4741 controller numbers are assigned to ch_anchor. Note that the ordering of 4742 the ch_anchor chapter C assignment after the ch_never command acts to 4743 override the ch_never assignment for the listed controller numbers (7 4744 and 64). 4746 The assignment of command-type X to cm_unused excludes most SysEx 4747 commands from the stream. Exceptions are made for General MIDI System 4748 On/Off commands and for the Master Volume and Balance commands, via the 4749 use of the secondary assignment syntax. The cm_used assignment codes 4750 the exception, and the ch_anchor assignment codes how these commands are 4751 protected in Chapter X. 4753 C.3. Configuration Tools: Timestamp Semantics 4755 The MIDI command section of the payload format consists of a list of 4756 commands, each with an associated timestamp. The semantics of command 4757 timestamps may be set during session configuration, using the parameters 4758 we describe in this section 4760 The parameter "tsmode" specifies the timestamp semantics for a stream. 4761 The parameter takes on one of three token values: "comex", "async", or 4762 "buffer". 4764 The default "comex" value specifies that timestamps code the execution 4765 time for a command (Appendix C.3.1) and supports the accurate 4766 transcoding of Standard MIDI Files (SMFs, [MIDI]). The "comex" value is 4767 also RECOMMENDED for new MIDI user-interface controller designs. The 4768 "async" value specifies an asynchronous timestamp sampling algorithm for 4769 time-of-arrival sources (Appendix C.3.2). The "buffer" value specifies 4770 a synchronous timestamp sampling algorithm (Appendix C.3.3) for time-of- 4771 arrival sources. 4773 Ancillary parameters MAY follow tsmode in a media description. We 4774 define these parameters in Appendices C.3.2-3 below. 4776 C.3.1. The comex Algorithm 4778 The default "comex" (COMmand EXecution) tsmode value specifies the 4779 execution time for the command. With comex, the difference between two 4780 timestamps indicates the time delay between the execution of the 4781 commands. This difference may be zero, coding simultaneous execution. 4783 The comex interpretation of timestamps works well for transcoding a 4784 Standard MIDI File (SMF, [MIDI]) into an RTP MIDI stream, as SMFs code a 4785 timestamp for each MIDI command stored in the file. To transcode an SMF 4786 that uses metric time markers, use the SMF tempo map (encoded in the SMF 4787 as meta-events) to convert metric SMF timestamp units into seconds-based 4788 RTP timestamp units. 4790 New MIDI controller designs (piano keyboard, drum pads, etc.) that 4791 support RTP MIDI and that have direct access to sensor data SHOULD use 4792 comex interpretation for timestamps, so that simultaneous gestural 4793 events may be accurately coded by RTP MIDI. 4795 Comex is a poor choice for transcoding MIDI 1.0 DIN cables [MIDI], for a 4796 reason that we will now explain. A MIDI DIN cable is an asynchronous 4797 serial protocol (320 microseconds per MIDI byte). MIDI commands on a 4798 DIN cable are not tagged with timestamps. Instead, MIDI DIN receivers 4799 infer command timing from the time of arrival of the bytes. Thus, two 4800 two-byte MIDI commands that occur at a source simultaneously are encoded 4801 on a MIDI 1.0 DIN cable with a 640 microsecond time offset. A MIDI DIN 4802 receiver is unable to tell if this time offset existed in the source 4803 performance or is an artifact of the serial speed of the cable. 4804 However, the RTP MIDI comex interpretation of timestamps declares that a 4805 timestamp offset between two commands reflects the timing of the source 4806 performance. 4808 This semantic mismatch is the reason that comex is a poor choice for 4809 transcoding MIDI DIN cables. Note that the choice of the RTP timestamp 4810 rate (Section 6.1-2 in the main text) cannot fix this inaccuracy issue. 4811 In the sections that follow, we describe two alternative timestamp 4812 interpretations ("async" and "buffer") that are a better match to MIDI 4813 1.0 DIN cable timing, and to other MIDI time-of-arrival sources. 4815 The "octpos", "linerate", and "mperiod" ancillary parameters (defined 4816 below) SHOULD NOT be used with comex. 4818 C.3.2. The async Algorithm 4820 The "async" tsmode value specifies the asynchronous sampling of a MIDI 4821 time-of-arrival source. In asynchronous sampling, the moment an octet 4822 is received from a source, it is labelled with a wall-clock time value. 4823 The time value has RTP timestamp units. 4825 The "octpos" ancillary parameter defines how RTP command timestamps are 4826 derived from octet time values. If octpos has the token value "first", 4827 a timestamp codes the time value of the first octet of the command. If 4828 octpos has the token value "last", a timestamp codes the time value of 4829 the last octet of the command. If the octpos parameter does not appear 4830 in the media description, the sender does not know which octet of the 4831 command the timestamp references (for example, the sender may be relying 4832 on an operating system service that does not specify this information). 4834 The octpos semantics refer to the first or last octet of a command as it 4835 appears on a time-of-arrival MIDI source, not as it appears in an RTP 4836 MIDI packet. This distinction is significant because the RTP coding may 4837 contain octets that are not present in the source. For example, the 4838 status octet of the first MIDI command in a packet may have been added 4839 to the MIDI stream during transcoding, to comply with the RTP MIDI 4840 running status requirements (Section 3.2). 4842 The "linerate" ancillary parameter defines the timespan of one MIDI 4843 octet on the transmission medium of the MIDI source to be sampled (such 4844 as a MIDI 1.0 DIN cable). The parameter has units of nanoseconds, and 4845 takes on integral values. For MIDI 1.0 DIN cables, the correct linerate 4846 value is 320000 (this value is also the default value for the 4847 parameter). 4849 We now show a session description example for the async algorithm. 4850 Consider a sender that is transcoding a MIDI 1.0 DIN cable source into 4851 RTP. The sender runs on a computing platform that assigns time values 4852 to every incoming octet of the source, and the sender uses the time 4853 values to label the first octet of each command in the RTP packet. This 4854 session description describes the transcoding: 4856 v=0 4857 o=lazzaro 2520644554 2838152170 IN IP4 first.example.net 4858 s=Example 4859 t=0 0 4860 m=audio 5004 RTP/AVP 96 4861 c=IN IP4 192.0.2.94 4862 a=rtpmap:96 rtp-midi/44100 4863 a=sendonly 4864 a=fmtp:96 tsmode=async; linerate=320000; octpos=first 4866 C.3.3. The buffer Algorithm 4868 The "buffer" tsmode value specifies the synchronous sampling of a MIDI 4869 time-of-arrival source. 4871 In synchronous sampling, octets received from a source are placed in a 4872 holding buffer upon arrival. At periodic intervals, the RTP sender 4873 examines the buffer. The sender removes complete commands from the 4874 buffer and codes those commands in an RTP packet. The command timestamp 4875 codes the moment of buffer examination, expressed in RTP timestamp 4876 units. Note that several commands may have the same timestamp value. 4878 The "mperiod" ancillary parameter defines the nominal periodic sampling 4879 interval. The parameter takes on positive integral values and has RTP 4880 timestamp units. 4882 The "octpos" ancillary parameter, defined in Appendix C.3.1 for 4883 asynchronous sampling, plays a different role in synchronous sampling. 4884 In synchronous sampling, the parameter specifies the timestamp semantics 4885 of a command whose octets span several sampling periods. 4887 If octpos has the token value "first", the timestamp reflects the 4888 arrival period of the first octet of the command. If octpos has the 4889 token value "last", the timestamp reflects the arrival period of the 4890 last octet of the command. The octpos semantics refer to the first or 4891 last octet of the command as it appears on a time-of-arrival source, not 4892 as it appears in the RTP packet. 4894 If the octpos parameter does not appear in the media description, the 4895 timestamp MAY reflect the arrival period of any octet of the command; 4896 senders use this option to signal a lack of knowledge about the timing 4897 details of the buffering process at sub-command granularity. 4899 We now show a session description example for the buffer algorithm. 4900 Consider a sender that is transcoding a MIDI 1.0 DIN cable source into 4901 RTP. The sender runs on a computing platform that places source data 4902 into a buffer upon receipt. The sender polls the buffer 1000 times a 4903 second, extracts all complete commands from the buffer, and places the 4904 commands in an RTP packet. This session description describes the 4905 transcoding: 4907 v=0 4908 o=lazzaro 2520644554 2838152170 IN IP6 first.example.net 4909 s=Example 4910 t=0 0 4911 m=audio 5004 RTP/AVP 96 4912 c=IN IP6 2001:DB80::7F2E:172A:1E24 4913 a=rtpmap:96 rtp-midi/44100 4914 a=sendonly 4915 a=fmtp:96 tsmode=buffer; linerate=320000; octpos=last; mperiod=44 4917 The mperiod value of 44 is derived by dividing the clock rate specified 4918 by the rtpmap attribute (44100 Hz) by the 1000 Hz buffer sampling rate 4919 and rounding to the nearest integer. Command timestamps might not 4920 increment by exact multiples of 44, as the actual sampling period might 4921 not precisely match the nominal mperiod value. 4923 C.4. Configuration Tools: Packet Timing Tools 4925 In this appendix, we describe session configuration tools for 4926 customizing the temporal behavior of MIDI stream packets. 4928 C.4.1. Packet Duration Tools 4930 Senders control the granularity of a stream by setting the temporal 4931 duration ("media time") of the packets in the stream. Short media times 4932 (20 ms or less) often imply an interactive session. Longer media times 4933 (100 ms or more) usually indicate a content streaming session. The RTP 4934 AVP profile [RFC3551] recommends audio packet media times in a range 4935 from 0 to 200 ms. 4937 By default, an RTP receiver dynamically senses the media time of packets 4938 in a stream and chooses the length of its playout buffer to match the 4939 stream. A receiver typically sizes its playout buffer to fit several 4940 audio packets and adjusts the buffer length to reflect the network 4941 jitter and the sender timing fidelity. 4943 Alternatively, the packet media time may be statically set during 4944 session configuration. Session descriptions MAY use the RTP MIDI 4945 parameter "rtp_ptime" to set the recommended media time for a packet. 4946 Session descriptions MAY also use the RTP MIDI parameter "rtp_maxptime" 4947 to set the maximum media time for a packet permitted in a stream. Both 4948 parameters MAY be used together to configure a stream. 4950 The values assigned to the rtp_ptime and rtp_maxptime parameters have 4951 the units of the RTP timestamp for the stream, as set by the rtpmap 4952 attribute (see Section 6.1). Thus, if rtpmap sets the clock rate of a 4953 stream to 44100 Hz, a maximum packet media time of 10 ms is coded by 4954 setting rtp_maxptime=441. As stated in the Appendix C preamble, the 4955 senders and receivers of a stream MUST agree on common values for 4956 rtp_ptime and rtp_maxptime if the parameters appear in the media 4957 description for the stream. 4959 0 ms is a reasonable media time value for MIDI packets and is often used 4960 in low-latency interactive applications. In a packet with a 0 ms media 4961 time, all commands execute at the instant they are coded by the packet 4962 timestamp. The session description below configures all packets in the 4963 stream to have 0 ms media time: 4965 v=0 4966 o=lazzaro 2520644554 2838152170 IN IP4 first.example.net 4967 s=Example 4968 t=0 0 4969 m=audio 5004 RTP/AVP 96 4970 c=IN IP4 192.0.2.94 4971 a=rtpmap:96 rtp-midi/44100 4972 a=fmtp:96 rtp_ptime=0; rtp_maxptime=0 4974 The session attributes ptime and maxptime [RFC4566] MUST NOT be used to 4975 configure an RTP MIDI stream. Sessions MUST use rtp_ptime in lieu of 4976 ptime and MUST use rtp_maxptime in lieu of maxptime. RTP MIDI defines 4977 its own parameters for media time configuration because 0 ms values for 4978 ptime and maxptime are forbidden by [RFC3264] but are essential for 4979 certain applications of RTP MIDI. 4981 See the Appendix C.7 examples for additional discussion about using 4982 rtp_ptime and rtp_maxptime for session configuration. 4984 C.4.2. The guardtime Parameter 4986 RTP permits a sender to stop sending audio packets for an arbitrary 4987 period of time during a session. When sending resumes, the RTP sequence 4988 number series continues unbroken, and the RTP timestamp value reflects 4989 the media time silence gap. 4991 This RTP feature has its roots in telephony, but it is also well matched 4992 to interactive MIDI sessions, as players may fall silent for several 4993 seconds during (or between) songs. 4995 Certain MIDI applications benefit from a slight enhancement to this RTP 4996 feature. In interactive applications, receivers may use on-line network 4997 models to guide heuristics for handling lost and late RTP packets. 4998 These models may work poorly if a sender ceases packet transmission for 4999 long periods of time. 5001 Session descriptions may use the parameter "guardtime" to set a minimum 5002 sending rate for a media session. The value assigned to guardtime codes 5003 the maximum separation time between two sequential packets, as expressed 5004 in RTP timestamp units. 5006 Typical guardtime values are 500-2000 ms. This value range is not a 5007 normative bound, and parties SHOULD be prepared to process values 5008 outside this range. 5010 The congestion control requirements for sender implementations 5011 (described in Section 8 and [RFC3550]) take precedence over the 5012 guardtime parameter. Thus, if the guardtime parameter requests a 5013 minimum sending rate, but sending at this rate would violate the 5014 congestion control requirements, senders MUST ignore the guardtime 5015 parameter value. In this case, senders SHOULD use the lowest minimum 5016 sending rate that satisfies the congestion control requirements. 5018 Below, we show a session description that uses the guardtime parameter. 5020 v=0 5021 o=lazzaro 2520644554 2838152170 IN IP6 first.example.net 5022 s=Example 5023 t=0 0 5024 m=audio 5004 RTP/AVP 96 5025 c=IN IP6 2001:DB80::7F2E:172A:1E24 5026 a=rtpmap:96 rtp-midi/44100 5027 a=fmtp:96 guardtime=44100; rtp_ptime=0; rtp_maxptime=0 5028 C.5. Configuration Tools: Stream Description 5030 As we discussed in Section 2.1, a party may send several RTP MIDI 5031 streams in the same RTP session, and several RTP sessions that carry 5032 MIDI may appear in a multimedia session. 5034 By default, the MIDI name space (16 channels + systems) of each RTP 5035 stream sent by a party in a multimedia session is independent. By 5036 independent, we mean three distinct things: 5038 o If a party sends two RTP MIDI streams (A and B), MIDI voice 5039 channel 0 in stream A is a different "channel 0" than MIDI 5040 voice channel 0 in stream B. 5042 o MIDI voice channel 0 in stream B is not considered to be 5043 "channel 16" of a 32-channel MIDI voice channel space whose 5044 "channel 0" is channel 0 of stream A. 5046 o Streams sent by different parties over different RTP sessions, 5047 or over the same RTP session but with different payload type 5048 numbers, do not share the association that is shared by a MIDI 5049 cable pair that cross-connects two devices in a MIDI 1.0 DIN 5050 network. By default, this association is only held by streams 5051 sent by different parties in the same RTP session that use the 5052 same payload type number. 5054 In this appendix, we show how to express that specific RTP MIDI streams 5055 in a multimedia session are not independent but instead are related in 5056 one of the three ways defined above. We use two tools to express these 5057 relations: 5059 o The musicport parameter. This parameter is assigned a 5060 non-negative integer value between 0 and 4294967295. It 5061 appears in the fmtp lines of payload types. 5063 o The FID grouping attribute [RFC3388] signals that several RTP 5064 sessions in a multimedia session are using the musicport 5065 parameter to express an inter-session relationship. 5067 If a multimedia session has several payload types whose musicport 5068 parameters are assigned the same integer value, streams using these 5069 payload types share an "identity relationship" (including streams that 5070 use the same payload type). Streams in an identity relationship share 5071 two properties: 5073 o Identity relationship streams sent by the same party 5074 target the same MIDI name space. Thus, if streams A 5075 and B share an identity relationship, voice channel 0 5076 in stream A is the same "channel 0" as voice channel 5077 0 in stream B. 5079 o Pairs of identity relationship streams that are sent by 5080 different parties share the association that is shared 5081 by a MIDI cable pair that cross-connects two devices in 5082 a MIDI 1.0 DIN network. 5084 A party MUST NOT send two RTP MIDI streams that share an identity 5085 relationship in the same RTP session. Instead, each stream MUST be in a 5086 separate RTP session. As explained in Section 2.1, this restriction is 5087 necessary to support the RTP MIDI method for the synchronization of 5088 streams that share a MIDI name space. 5090 If a multimedia session has several payload types whose musicport 5091 parameters are assigned sequential values (i.e., i, i+1, ... i+k), the 5092 streams using the payload types share an "ordered relationship". For 5093 example, if payload type A assigns 2 to musicport and payload type B 5094 assigns 3 to musicport, A and B are in an ordered relationship. 5096 Streams in an ordered relationship that are sent by the same party are 5097 considered by renderers to form a single larger MIDI space. For 5098 example, if stream A has a musicport value of 2 and stream B has a 5099 musicport value of 3, MIDI voice channel 0 in stream B is considered to 5100 be voice channel 16 in the larger MIDI space formed by the relationship. 5101 Note that it is possible for streams to participate in both an identity 5102 relationship and an ordered relationship. 5104 We now state several rules for using musicport: 5106 o If streams from several RTP sessions in a multimedia 5107 session use the musicport parameter, the RTP sessions 5108 MUST be grouped using the FID grouping attribute 5109 defined in [RFC3388]. 5111 o An ordered or identity relationship MUST NOT 5112 contain both native RTP MIDI streams and 5113 mpeg4-generic RTP MIDI streams. An exception applies 5114 if a relationship consists of sendonly and recvonly 5115 (but not sendrecv) streams. In this case, the sendonly 5116 streams MUST NOT contain both types of streams, and the 5117 recvonly streams MUST NOT contain both types of streams. 5119 o It is possible to construct identity relationships 5120 that violate the recovery journal mandate (for example, 5121 sending NoteOns for a voice channel on stream A and 5122 NoteOffs for the same voice channel on stream B). 5123 Parties MUST NOT generate (or accept) session 5124 descriptions that exhibit this flaw. 5126 o Other payload formats MAY define musicport media type 5127 parameters. Formats would define these parameters so that 5128 their sessions could be bundled into RTP MIDI name spaces. 5129 The parameter definitions MUST be compatible with the 5130 musicport semantics defined in this appendix. 5132 As a rule, at most one payload type in a relationship may specify a MIDI 5133 renderer. An exception to the rule applies to relationships that 5134 contain sendonly and recvonly streams but no sendrecv streams. In this 5135 case, one sendonly session and one recvonly session may each define a 5136 renderer. 5138 Renderer specification in a relationship may be done using the tools 5139 described in Appendix C.6. These tools work for both native streams and 5140 mpeg4-generic streams. An mpeg4-generic stream that uses the Appendix 5141 C.6 tools MUST set all "config" parameters to the empty string (""). 5143 Alternatively, for mpeg4-generic streams, renderer specification may be 5144 done by setting one "config" parameter in the relationship to the 5145 renderer configuration string, and all other config parameters to the 5146 empty string (""). 5148 We now define sender and receiver rules that apply when a party sends 5149 several streams that target the same MIDI name space. 5151 Senders MAY use the subsetting parameters (Appendix C.1) to predefine 5152 the partitioning of commands between streams, or they MAY use a dynamic 5153 partitioning strategy. 5155 Receivers that merge identity relationship streams into a single MIDI 5156 command stream MUST maintain the structural integrity of the MIDI 5157 commands coded in each stream during the merging process, in the same 5158 way that software that merges traditional MIDI 1.0 DIN cable flows is 5159 responsible for creating a merged command flow compatible with [MIDI]. 5161 Senders MUST partition the name space so that the rendered MIDI 5162 performance does not contain indefinite artifacts (as defined in Section 5163 4). This responsibility holds even if all streams are sent over 5164 reliable transport, as different stream latencies may yield indefinite 5165 artifacts. For example, stuck notes may occur in a performance split 5166 over two TCP streams, if NoteOn commands are sent on one stream and 5167 NoteOff commands are sent on the other. 5169 Senders MUST NOT split a Registered Parameter Name (RPN) or Non- 5170 Registered Parameter Name (NRPN) transaction appearing on a MIDI channel 5171 across multiple identity relationship sessions. Receivers MUST assume 5172 that the RPN/NRPN transactions that appear on different identity 5173 relationship sessions are independent and MUST preserve transactional 5174 integrity during the MIDI merge. 5176 A simple way to safely partition voice channel commands is to place all 5177 MIDI commands for a particular voice channel into the same session. 5178 Safe partitioning of MIDI Systems commands may be more complicated for 5179 sessions that extensively use System Exclusive. 5181 We now show several session description examples that use the musicport 5182 parameter. 5184 Our first session description example shows two RTP MIDI streams that 5185 drive the same General MIDI decoder. The sender partitions MIDI 5186 commands between the streams dynamically. The musicport values indicate 5187 that the streams share an identity relationship. 5189 v=0 5190 o=lazzaro 2520644554 2838152170 IN IP4 first.example.net 5191 s=Example 5192 t=0 0 5193 a=group:FID 1 2 5194 c=IN IP4 192.0.2.94 5195 m=audio 5004 RTP/AVP 96 5196 a=rtpmap:96 mpeg4-generic/44100 5197 a=mid:1 5198 a=fmtp:96 streamtype=5; mode=rtp-midi; profile-level-id=12; 5199 config=7A0A0000001A4D546864000000060000000100604D54726B0 5200 000000600FF2F000; musicport=12 5201 m=audio 5006 RTP/AVP 96 5202 a=rtpmap:96 mpeg4-generic/44100 5203 a=mid:2 5204 a=fmtp:96 streamtype=5; mode=rtp-midi; config=""; profile-level-id=12; 5205 musicport=12 5207 (The a=fmtp lines have been wrapped to fit the page to accommodate 5208 memo formatting restrictions; they comprise single lines in SDP.) 5210 Recall that Section 2.1 defines rules for streams that target the same 5211 MIDI name space. Those rules, implemented in the example above, require 5212 that each stream resides in a separate RTP session, and that the 5213 grouping mechanisms defined in [RFC3388] signal an inter-session 5214 relationship. The "group" and "mid" attribute lines implement this 5215 grouping mechanism. 5217 A variant on this example, whose session description is not shown, would 5218 use two streams in an identity relationship driving the same MIDI 5219 renderer, each with a different transport type. One stream would use 5220 UDP and would be dedicated to real-time messages. A second stream would 5221 use TCP [RFC4571] and would be used for SysEx bulk data messages. 5223 In the next example, two mpeg4-generic streams form an ordered 5224 relationship to drive a Structured Audio decoder with 32 MIDI voice 5225 channels. Both streams reside in the same RTP session. 5227 v=0 5228 o=lazzaro 2520644554 2838152170 IN IP6 first.example.net 5229 s=Example 5230 t=0 0 5231 m=audio 5006 RTP/AVP 96 97 5232 c=IN IP6 2001:DB80::7F2E:172A:1E24 5233 a=rtpmap:96 mpeg4-generic/44100 5234 a=fmtp:96 streamtype=5; mode=rtp-midi; config=""; profile-level-id=13; 5235 musicport=5 5236 a=rtpmap:97 mpeg4-generic/44100 5237 a=fmtp:97 streamtype=5; mode=rtp-midi; config=""; profile-level-id=13; 5238 musicport=6; render=synthetic; rinit="audio/asc"; 5239 url="http://example.com/cardinal.asc"; 5240 cid="azsldkaslkdjqpwojdkmsldkfpe" 5242 (The a=fmtp lines have been wrapped to fit the page to accommodate 5243 memo formatting restrictions; they comprise single lines in SDP.) 5245 The sequential musicport values for the two sessions establish the 5246 ordered relationship. The musicport=5 session maps to Structured Audio 5247 extended channels range 0-15, the musicport=6 session maps to Structured 5248 Audio extended channels range 16-31. 5250 Both config strings are empty. The configuration data is specified by 5251 parameters that appear in the fmtp line of the second media description. 5252 We define this configuration method in Appendix C.6. 5254 The next example shows two RTP MIDI streams (one recvonly, one sendonly) 5255 that form a "virtual sendrecv" session. Each stream resides in a 5256 different RTP session (a requirement because sendonly and recvonly are 5257 RTP session attributes). 5259 v=0 5260 o=lazzaro 2520644554 2838152170 IN IP4 first.example.net 5261 s=Example 5262 t=0 0 5263 a=group:FID 1 2 5264 c=IN IP4 192.0.2.94 5265 m=audio 5004 RTP/AVP 96 5266 a=sendonly 5267 a=rtpmap:96 mpeg4-generic/44100 5268 a=mid:1 5269 a=fmtp:96 streamtype=5; mode=rtp-midi; profile-level-id=12; 5270 config=7A0A0000001A4D546864000000060000000100604D54726B0 5271 000000600FF2F000; musicport=12 5272 m=audio 5006 RTP/AVP 96 5273 a=recvonly 5274 a=rtpmap:96 mpeg4-generic/44100 5275 a=mid:2 5276 a=fmtp:96 streamtype=5; mode=rtp-midi; profile-level-id=12; 5277 config=7A0A0000001A4D546864000000060000000100604D54726B0 5278 000000600FF2F000; musicport=12 5280 (The a=fmtp lines have been wrapped to fit the page to accommodate 5281 memo formatting restrictions; they comprise single lines in SDP.) 5283 To signal the "virtual sendrecv" semantics, the two streams assign 5284 musicport to the same value (12). As defined earlier in this section, 5285 pairs of identity relationship streams that are sent by different 5286 parties share the association that is shared by a MIDI cable pair that 5287 cross-connects two devices in a MIDI 1.0 network. We use the term 5288 "virtual sendrecv" because streams sent by different parties in a true 5289 sendrecv session also have this property. 5291 As discussed in the preamble to Appendix C, the primary advantage of the 5292 virtual sendrecv configuration is that each party can customize the 5293 property of the stream it receives. In the example above, each stream 5294 defines its own "config" string that could customize the rendering 5295 algorithm for each party (in fact, the particular strings shown in this 5296 example are identical, because General MIDI is not a configurable MPEG 4 5297 renderer). 5299 C.6. Configuration Tools: MIDI Rendering 5301 This appendix defines the session configuration tools for rendering. 5303 The "render" parameter specifies a rendering method for a stream. The 5304 parameter is assigned a token value that signals the top-level rendering 5305 class. This memo defines four token values for render: "unknown", 5306 "synthetic", "api", and "null": 5308 o An "unknown" renderer is a renderer whose nature is unspecified. 5309 It is the default renderer for native RTP MIDI streams. 5311 o A "synthetic" renderer transforms the MIDI stream into audio 5312 output (or sometimes into stage lighting changes or other 5313 actions). It is the default renderer for mpeg4-generic 5314 RTP MIDI streams. 5316 o An "api" renderer presents the command stream to applications 5317 via an Application Programmer Interface (API). 5319 o The "null" renderer discards the MIDI stream. 5321 The "null" render value plays special roles during Offer/Answer 5322 negotiations [RFC3264]. A party uses the "null" value in an answer to 5323 reject an offered renderer. Note that rejecting a renderer is 5324 independent from rejecting a payload type (coded by removing the payload 5325 type from a media line) and rejecting a media stream (coded by zeroing 5326 the port of a media line that uses the renderer). 5328 Other render token values MAY be registered with IANA. The token value 5329 MUST adhere to the ABNF for render tokens defined in Appendix D. 5330 Registrations MUST include a complete specification of parameter value 5331 usage, similar in depth to the specifications that appear throughout 5332 Appendix C.6 for "synthetic" and "api" render values. If a party is 5333 offered a session description that uses a render token value that is not 5334 known to the party, the party MUST NOT accept the renderer. Options 5335 include rejecting the renderer (using the "null" value), the payload 5336 type, the media stream, or the session description. 5338 Other parameters MAY follow a render parameter in a parameter list. The 5339 additional parameters act to define the exact nature of the renderer. 5340 For example, the "subrender" parameter (defined in Appendix C.6.2) 5341 specifies the exact nature of the renderer. 5343 Special rules apply to using the render parameter in an mpeg4-generic 5344 stream. We define these rules in Appendix C.6.5. 5346 C.6.1. The multimode Parameter 5348 A media description MAY contain several render parameters. By default, 5349 if a parameter list includes several render parameters, a receiver MUST 5350 choose exactly one renderer from the list to render the stream. The 5351 "multimode" parameter may be used to override this default. We define 5352 two token values for multimode: "one" and "all": 5354 o The default "one" value requests rendering by exactly one of 5355 the listed renderers. 5357 o The "all" value requests the synchronized rendering of the RTP 5358 MIDI stream by all listed renderers, if possible. 5360 If the multimode parameter appears in a parameter list, it MUST appear 5361 before the first render parameter assignment. 5363 Render parameters appear in the parameter list in order of decreasing 5364 priority. A receiver MAY use the priority ordering to decide which 5365 renderer(s) to retain in a session. 5367 If the "offer" in an Offer/Answer-style negotiation [RFC3264] contains a 5368 parameter list with one or more render parameters, the "answer" MUST set 5369 the render parameters of all unchosen renderers to "null". 5371 C.6.2. Renderer Specification 5373 The render parameter (Appendix C.6 preamble) specifies, in a broad 5374 sense, what a renderer does with a MIDI stream. In this appendix, we 5375 describe the "subrender" parameter. The token value assigned to 5376 subrender defines the exact nature of the renderer. Thus, "render" and 5377 "subrender" combine to define a renderer, in the same way as MIME types 5378 and MIME subtypes combine to define a type of media [RFC2045]. 5380 If the subrender parameter is used for a renderer definition, it MUST 5381 appear immediately after the render parameter in the parameter list. At 5382 most one subrender parameter may appear in a renderer definition. 5384 This document defines one value for subrender: the value "default". The 5385 "default" token specifies the use of the default renderer for the stream 5386 type (native or mpeg4-generic). The default renderer for native RTP 5387 MIDI streams is a renderer whose nature is unspecified (see point 6 in 5388 Section 6.1 for details). The default renderer for mpeg4-generic RTP 5389 MIDI streams is an MPEG 4 Audio Object Type whose ID number is 13, 14, 5390 or 15 (see Section 6.2 for details). 5392 If a renderer definition does not use the subrender parameter, the value 5393 "default" is assumed for subrender. 5395 Other subrender token values may be registered with IANA. We now 5396 discuss guidelines for registering subrender values. 5398 A subrender value is registered for a specific stream type (native or 5399 mpeg4-generic) and a specific render value (excluding "null" and 5400 "unknown"). Registrations for mpeg4-generic subrender values are 5401 restricted to new MPEG 4 Audio Object Types that accept MIDI input. The 5402 syntax of the token MUST adhere to the token definition in Appendix D. 5404 For "render=synthetic" renderers, a subrender value registration 5405 specifies an exact method for transforming the MIDI stream into audio 5406 (or sometimes into video or control actions, such as stage lighting). 5407 For standardized renderers, this specification is usually a pointer to a 5408 standards document, perhaps supplemented by RTP-MIDI-specific 5409 information. For commercial products and open-source projects, this 5410 specification usually takes the form of instructions for interfacing the 5411 RTP MIDI stream with the product or project software. A 5412 "render=synthetic" registration MAY specify additional Reset State 5413 commands for the renderer (Appendix A.1). 5415 A "render=api" subrender value registration specifies how an RTP MIDI 5416 stream interfaces with an API (Application Programmers Interface). This 5417 specification is usually a pointer to programmer's documentation for the 5418 API, perhaps supplemented by RTP-MIDI-specific information. 5420 A subrender registration MAY specify an initialization file (referred to 5421 in this document as an initialization data object) for the stream. The 5422 initialization data object MAY be encoded in the parameter list 5423 (verbatim or by reference) using the coding tools defined in Appendix 5424 C.6.3. An initialization data object MUST have a registered [RFC4288] 5425 media type and subtype [RFC2045]. 5427 For "render=synthetic" renderers, the data object usually encodes 5428 initialization data for the renderer (sample files, synthesis patch 5429 parameters, reverberation room impulse responses, etc.). 5431 For "render=api" renderers, the data object usually encodes data about 5432 the stream used by the API (for example, for an RTP MIDI stream 5433 generated by a piano keyboard controller, the manufacturer and model 5434 number of the keyboard, for use in GUI presentation). 5436 Usually, only one initialization object is encoded for a renderer. If a 5437 renderer uses multiple data objects, the correct receiver interpretation 5438 of multiple data objects MUST be defined in the subrender registration. 5440 A subrender value registration may also specify additional parameters, 5441 to appear in the parameter list immediately after subrender. These 5442 parameter names MUST begin with the subrender value, followed by an 5443 underscore ("_"), to avoid name space collisions with future RTP MIDI 5444 parameter names (for example, a parameter "foo_bar" defined for 5445 subrender value "foo"). 5447 We now specify guidelines for interpreting the subrender parameter 5448 during session configuration. 5450 If a party is offered a session description that uses a renderer whose 5451 subrender value is not known to the party, the party MUST NOT accept the 5452 renderer. Options include rejecting the renderer (using the "null" 5453 value), the payload type, the media stream, or the session description. 5455 Receivers MUST be aware of the Reset State commands (Appendix A.1) for 5456 the renderer specified by the subrender parameter and MUST insure that 5457 the renderer does not experience indefinite artifacts due to the 5458 presence (or the loss) of a Reset State command. 5460 C.6.3. Renderer Initialization 5462 If the renderer for a stream uses an initialization data object, an 5463 "rinit" parameter MUST appear in the parameter list immediately after 5464 the "subrender" parameter. If the renderer parameter list does not 5465 include a subrender parameter (recall the semantics for "default" in 5466 Appendix C.6.2), the "rinit" parameter MUST appear immediately after the 5467 "render" parameter. 5469 The value assigned to the rinit parameter MUST be the media type/subtype 5470 [RFC2045] for the initialization data object. If an initialization 5471 object type is registered with several media types, including audio, the 5472 assignment to rinit MUST use the audio media type. 5474 RTP MIDI supports several parameters for encoding initialization data 5475 objects for renderers in the parameter list: "inline", "url", and "cid". 5477 If the "inline", "url", and/or "cid" parameters are used by a renderer, 5478 these parameters MUST immediately follow the "rinit" parameter. 5480 If a "url" parameter appears for a renderer, an "inline" parameter MUST 5481 NOT appear. If an "inline" parameter appears for a renderer, a "url" 5482 parameter MUST NOT appear. However, neither "url" or "inline" is 5483 required to appear. If neither "url" or "inline" parameters follow 5484 "rinit", the "cid" parameter MUST follow "rinit". 5486 The "inline" parameter supports the inline encoding of the data object. 5487 The parameter is assigned a double-quoted Base64 [RFC2045] encoding of 5488 the binary data object, with no line breaks. Appendix E.4 shows an 5489 example that constructs an inline parameter value. 5491 The "url" parameter is assigned a double-quoted string representation of 5492 a Uniform Resource Locator (URL) for the data object. The string MUST 5493 specify either a HyperText Transport Protocol URI (HTTP, [RFC2616]) or 5494 an HTTP over TLS URI (HTTPS, [RFC2818]). The media type/subtype for the 5495 data object SHOULD be specified in the appropriate HTTP or HTTPS 5496 transport header. 5498 The "url" parameter is assigned a double-quoted string representation of 5499 a Uniform Resource Locator (URL) for the data object. The string MUST 5500 specify a HyperText Transport Protocol URL (HTTP, [RFC2616]). HTTP MAY 5501 be used over TCP or MAY be used over a secure network transport, such as 5502 the method described in [RFC2818]. The media type/subtype for the data 5503 object SHOULD be specified in the appropriate HTTP transport header. 5505 The "cid" parameter supports data object caching. The parameter is 5506 assigned a double-quoted string value that encodes a globally unique 5507 identifier for the data object. 5509 A cid parameter MAY immediately follow an inline parameter, in which 5510 case the cid identifier value MUST be associated with the inline data 5511 object. 5513 If a url parameter is present, and if the data object for the URL is 5514 expected to be unchanged for the life of the URL, a cid parameter MAY 5515 immediately follow the url parameter. The cid identifier value MUST be 5516 associated with the data object for the URL. A cid parameter assigned 5517 to the same identifier value SHOULD be specified following the data 5518 object type/subtype in the appropriate HTTP transport header. 5520 If a url parameter is present, and if the data object for the URL is 5521 expected to change during the life of the URL, a cid parameter MUST NOT 5522 follow the url parameter. A receiver interprets the presence of a cid 5523 parameter as an indication that it is safe to use a cached copy of the 5524 url data object; the absence of a cid parameter is an indication that it 5525 is not safe to use a cached copy, as it may change. 5527 Finally, the cid parameter MAY be used without the inline and url 5528 parameters. In this case, the identifier references a local or 5529 distributed catalog of data objects. 5531 In most cases, only one data object is coded in the parameter list for 5532 each renderer. For example, the default renderer for mpeg4-generic 5533 streams uses a single data object (see Appendix C.6.5 for example 5534 usage). 5536 However, a subrender registration MAY permit the use of multiple data 5537 objects for a renderer. If multiple data objects are encoded for a 5538 renderer, each object encoding begins with an "rinit" parameter, 5539 followed by "inline", "url", and/or "cid" parameters. 5541 Initialization data objects MAY encapsulate a Standard MIDI File (SMF). 5542 By default, the SMFs that are encapsulated in a data object MUST be 5543 ignored by an RTP MIDI receiver. We define parameters to override this 5544 default in Appendix C.6.4. 5546 To end this section, we offer guidelines for registering media types for 5547 initialization data objects. These guidelines are in addition to the 5548 information in [RFC4288]. 5550 Some initialization data objects are also capable of encoding MIDI note 5551 information and thus complete audio performances. These objects SHOULD 5552 be registered using the "audio" media type, so that the objects may also 5553 be used for store-and-forward rendering, and "application" media type, 5554 to support editing tools. Initialization objects without note storage, 5555 or initialization objects for non-audio renderers, SHOULD be registered 5556 only for an "application" media type. 5558 C.6.4. MIDI Channel Mapping 5560 In this appendix, we specify how to map MIDI name spaces (16 voice 5561 channels + systems) onto a renderer. 5563 In the general case: 5565 o A session may define an ordered relationship (Appendix C.5) 5566 that presents more than one MIDI name space to a renderer. 5568 o A renderer may accept an arbitrary number of MIDI name spaces, 5569 or it may expect a specific number of MIDI name spaces. 5571 A session description SHOULD provide a compatible MIDI name space to 5572 each renderer in the session. If a receiver detects that a session 5573 description has too many or too few MIDI name spaces for a renderer, 5574 MIDI data from extra stream name spaces MUST be discarded, and extra 5575 renderer name spaces MUST NOT be driven with MIDI data (except as 5576 described in Appendix C.6.4.1, below). 5578 If a parameter list defines several renderers and assigns the "all" 5579 token value to the multimode parameter, the same name space is presented 5580 to each renderer. However, the "chanmask" parameter may be used to mask 5581 out selected voice channels to each renderer. We define "chanmask" and 5582 other MIDI management parameters in the sub-sections below. 5584 C.6.4.1. The smf_info Parameter 5586 The smf_info parameter defines the use of the SMFs encapsulated in 5587 renderer data objects (if any). The smf_info parameter also defines the 5588 use of SMFs coded in the smf_inline, smf_url, and smf_cid parameters 5589 (defined in Appendix C.6.4.2). 5591 The smf_info parameter describes the "render" parameter that most 5592 recently precedes it in the parameter list. The smf_info parameter MUST 5593 NOT appear in parameter lists that do not use the "render" parameter, 5594 and MUST NOT appear before the first use of "render" in the parameter 5595 list. 5597 We define three token values for smf_info: "ignore", "sdp_start", and 5598 "identity": 5600 o The "ignore" value indicates that the SMFs MUST be discarded. 5601 This behavior is the default SMF rendering behavior. 5603 o The "sdp_start" value codes that SMFs MUST be rendered, 5604 and that the rendering MUST begin upon the acceptance of 5605 the session description. If a receiver is offered a session 5606 description with a renderer that uses an smf_info parameter 5607 set to sdp_start, and if the receiver does not support 5608 rendering SMFs, the receiver MUST NOT accept the renderer 5609 associated with the smf_info parameter. Options include 5610 rejecting the renderer (by setting the "render" parameter 5611 to "null"), the payload type, the media stream, or the 5612 entire session description. 5614 o The "identity" value indicates that the SMFs code the identity 5615 of the renderer. The value is meant for use with the 5616 "unknown" renderer (see Appendix C.6 preamble). The MIDI commands 5617 coded in the SMF are informational in nature and MUST NOT be 5618 presented to a renderer for audio presentation. In 5619 typical use, the SMF would use SysEx Identity Reply 5620 commands (F0 7E nn 06 02, as defined in [MIDI]) to identify 5621 devices, and use device-specific SysEx commands to describe 5622 current state of the devices (patch memory contents, etc.). 5624 Other smf_info token values MAY be registered with IANA. The token 5625 value MUST adhere to the ABNF for render tokens defined in Appendix D. 5626 Registrations MUST include a complete specification of parameter usage, 5627 similar in depth to the specifications that appear in this appendix for 5628 "sdp_start" and "identity". 5630 If a party is offered a session description that uses an smf_info 5631 parameter value that is not known to the party, the party MUST NOT 5632 accept the renderer associated with the smf_info parameter. Options 5633 include rejecting the renderer, the payload type, the media stream, or 5634 the entire session description. 5636 We now define the rendering semantics for the "sdp_start" token value in 5637 detail. 5639 The SMFs and RTP MIDI streams in a session description share the same 5640 MIDI name space(s). In the simple case of a single RTP MIDI stream and 5641 a single SMF, the SMF MIDI commands and RTP MIDI commands are merged 5642 into a single name space and presented to the renderer. The indefinite 5643 artifact responsibilities for merged MIDI streams defined in Appendix 5644 C.5 also apply to merging RTP and SMF MIDI data. 5646 If a payload type codes multiple SMFs, the SMF name spaces are presented 5647 as an ordered entity to the renderer. To determine the ordering of SMFs 5648 for a renderer (which SMF is "first", which is "second", etc.), use the 5649 following rules: 5651 o If the renderer uses a single data object, the order of 5652 appearance of the SMFs in the object's internal structure 5653 defines the order of the SMFs (the earliest SMF in the object 5654 is "first", the next SMF in the object is "second", etc.). 5656 o If multiple data objects are encoded for a renderer, the 5657 appearance of each data object in the parameter list 5658 sets the relative order of the SMFs encoded in each 5659 data object (SMFs encoded in parameters that appear 5660 earlier in the list are ordered before SMFs encoded 5661 in parameters that appear later in the list). 5663 o If SMFs are encoded in data objects parameters and in 5664 the parameters defined in C.6.4.2, the relative order 5665 of the data object parameters and C.6.4.2 parameters 5666 in the parameter list sets the relative order of SMFs 5667 (SMFs encoded in parameters that appear earlier in the 5668 list are ordered before SMFs in parameters that appear 5669 later in the list). 5671 Given this ordering of SMFs, we now define the mapping of SMFs to 5672 renderer name spaces. The SMF that appears first for a renderer maps to 5673 the first renderer name space. The SMF that appears second for a 5674 renderer maps to the second renderer name space, etc. If the associated 5675 RTP MIDI streams also form an ordered relationship, the first SMF is 5676 merged with the first name space of the relationship, the second SMF is 5677 merged to the second name space of the relationship, etc. 5679 Unless the streams and the SMFs both use MIDI Time Code, the time offset 5680 between SMF and stream data is unspecified. This restriction limits the 5681 use of SMFs to applications where synchronization is not critical, such 5682 as the transport of System Exclusive commands for renderer 5683 initialization, or human-SMF interactivity. 5685 Finally, we note that each SMF in the sdp_start discussion above encodes 5686 exactly one MIDI name space (16 voice channels + systems). Thus, the 5687 use of the Device Name SMF meta event to specify several MIDI name 5688 spaces in an SMF is not supported for sdp_start. 5690 C.6.4.2. The smf_inline, smf_url, and smf_cid Parameters 5692 In some applications, the renderer data object may not encapsulate SMFs, 5693 but an application may wish to use SMFs in the manner defined in 5694 Appendix C.6.4.1. 5696 The "smf_inline", "smf_url", and "smf_cid" parameters address this 5697 situation. These parameters use the syntax and semantics of the inline, 5698 url, and cid parameters defined in Appendix C.6.3, except that the 5699 encoded data object is an SMF. 5701 The "smf_inline", "smf_url", and "smf_cid" parameters belong to the 5702 "render" parameter that most recently precedes it in the session 5703 description. The "smf_inline", "smf_url", and "smf_cid" parameters MUST 5704 NOT appear in parameter lists that do not use the "render" parameter and 5705 MUST NOT appear before the first use of "render" in the parameter list. 5706 If several "smf_inline", "smf_url", or "smf_cid" parameters appear for a 5707 renderer, the order of the parameters defines the SMF name space 5708 ordering. 5710 C.6.4.3. The chanmask Parameter 5712 The chanmask parameter instructs the renderer to ignore all MIDI voice 5713 commands for certain channel numbers. The parameter value is a 5714 concatenated string of "1" and "0" digits. Each string position maps to 5715 a MIDI voice channel number (system channels may not be masked). A "1" 5716 instructs the renderer to process the voice channel; a "0" instructs the 5717 renderer to ignore the voice channel. 5719 The string length of the chanmask parameter value MUST be 16 (for a 5720 single stream or an identity relationship) or a multiple of 16 (for an 5721 ordered relationship). 5723 The chanmask parameter describes the "render" parameter that most 5724 recently precedes it in the session description; chanmask MUST NOT 5725 appear in parameter lists that do not use the "render" parameter and 5726 MUST NOT appear before the first use of "render" in the parameter list. 5728 The chanmask parameter describes the final MIDI name spaces presented to 5729 the renderer. The SMF and stream components of the MIDI name spaces may 5730 not be independently masked. 5732 If a receiver is offered a session description with a renderer that uses 5733 the chanmask parameter, and if the receiver does not implement the 5734 semantics of the chanmask parameter, the receiver MUST NOT accept the 5735 renderer unless the chanmask parameter value contains only "1"s. 5737 C.6.5. The audio/asc Media Type 5739 In Appendix 11.3, we register the audio/asc media type. The data object 5740 for audio/asc is a binary encoding of the AudioSpecificConfig data block 5741 used to initialize mpeg4-generic streams (Section 6.2 and [MPEGAUDIO]). 5743 An mpeg4-generic parameter list MAY use the render, subrender, and rinit 5744 parameters with the audio/asc media type for renderer configuration. 5745 Several restrictions apply to the use of these parameters in 5746 mpeg4-generic parameter lists: 5748 o An mpeg4-generic media description that uses the render parameter 5749 MUST assign the empty string ("") to the mpeg4-generic "config" 5750 parameter. The use of the streamtype, mode, and profile-level-id 5751 parameters MUST follow the normative text in Section 6.2. 5753 o Sessions that use identity or ordered relationships MUST follow 5754 the mpeg4-generic configuration restrictions in Appendix C.5. 5756 o The render parameter MUST be assigned the value "synthetic", 5757 "unknown", "null", or a render value that has been added to 5758 the IANA repository for use with mpeg4-generic RTP MIDI 5759 streams. The "api" token value for render MUST NOT be used. 5761 o If a subrender parameter is present, it MUST immediately follow 5762 the render parameter, and it MUST be assigned the token value 5763 "default" or assigned a subrender value added to the IANA 5764 repository for use with mpeg4-generic RTP MIDI streams. A 5765 subrender parameter assignment may be left out of the renderer 5766 configuration, in which case the implied value of subrender 5767 is the default value of "default". 5769 o If the render parameter is assigned the value "synthetic" 5770 and the subrender parameter has the value "default" (assigned 5771 or implied), the rinit parameter MUST be assigned the value 5772 "audio/asc", and an AudioSpecificConfig data object MUST be encoded 5773 using the mechanisms defined in C.6.2-3. The AudioSpecificConfig 5774 data MUST encode one of the MPEG 4 Audio Object Types defined for 5775 use with mpeg4-generic in Section 6.2. If the subrender value is 5776 other than "default", refer to the subrender registration 5777 for information on the use of "audio/asc" with the renderer. 5779 o If the render parameter is assigned the value "null" or 5780 "unknown", the data object MAY be omitted. 5782 Several general restrictions apply to the use of the audio/asc media 5783 type in RTP MIDI: 5785 o A native stream MUST NOT assign "audio/asc" to rinit. The 5786 audio/asc media type is not intended to be a general-purpose 5787 container for rendering systems outside of MPEG usage. 5789 o The audio/asc media type defines a stored object type; it does 5790 not define semantics for RTP streams. Thus, audio/asc MUST NOT 5791 appear on an rtpmap line of a session description. 5793 Below, we show session description examples for audio/asc. The session 5794 description below uses the inline parameter to code the 5795 AudioSpecificConfig block for a mpeg4-generic General MIDI stream. We 5796 derive the value assigned to the inline parameter in Appendix E.4. The 5797 subrender token value of "default" is implied by the absence of the 5798 subrender parameter in the parameter list. 5800 v=0 5801 o=lazzaro 2520644554 2838152170 IN IP4 first.example.net 5802 s=Example 5803 t=0 0 5804 m=audio 5004 RTP/AVP 96 5805 c=IN IP4 192.0.2.94 5806 a=rtpmap:96 mpeg4-generic/44100 5807 a=fmtp:96 streamtype=5; mode=rtp-midi; config=""; profile-level-id=12; 5808 render=synthetic; rinit="audio/asc"; 5809 inline="egoAAAAaTVRoZAAAAAYAAAABAGBNVHJrAAAABgD/LwAA" 5811 (The a=fmtp line has been wrapped to fit the page to accommodate 5812 memo formatting restrictions; it comprises a single line in SDP.) 5814 The session description below uses the url parameter to code the 5815 AudioSpecificConfig block for the same General MIDI stream: 5817 v=0 5818 o=lazzaro 2520644554 2838152170 IN IP4 first.example.net 5819 s=Example 5820 t=0 0 5821 m=audio 5004 RTP/AVP 96 5822 c=IN IP4 192.0.2.94 5823 a=rtpmap:96 mpeg4-generic/44100 5824 a=fmtp:96 streamtype=5; mode=rtp-midi; config=""; profile-level-id=12; 5825 render=synthetic; rinit="audio/asc"; url="http://example.net/oski.asc"; 5826 cid="xjflsoeiurvpa09itnvlduihgnvet98pa3w9utnuighbuk" 5828 (The a=fmtp line has been wrapped to fit the page to accommodate 5829 memo formatting restrictions; it comprises a single line in SDP.) 5831 C.7. Interoperability 5833 In this appendix, we define interoperability guidelines for two 5834 application areas: 5836 o MIDI content-streaming applications. RTP MIDI is added to 5837 RTSP-based content-streaming servers, so that viewers may 5838 experience MIDI performances (produced by a specified client- 5839 side renderer) in synchronization with other streams (video, 5840 audio). 5842 o Long-distance network musical performance applications. RTP 5843 MIDI is added to SIP-based voice chat or videoconferencing 5844 programs, as an alternative, or as an addition, to audio and/or 5845 video RTP streams. 5847 For each application, we define a core set of functionality that all 5848 implementations MUST implement. 5850 The applications we address in this section are not an exhaustive list 5851 of potential RTP MIDI uses. We expect framework documents for other 5852 applications to be developed, within the IETF or within other 5853 organizations. We discuss other potential application areas for RTP 5854 MIDI in Section 1 of the main text of this memo. 5856 C.7.1. MIDI Content Streaming Applications 5858 In content-streaming applications, a user invokes an RTSP client to 5859 initiate a request to an RTSP server to view a multimedia session. For 5860 example, clicking on a web page link for an Internet Radio channel 5861 launches an RTSP client that uses the link's RTSP URL to contact the 5862 RTSP server hosting the radio channel. 5864 The content may be pre-recorded (for example, on-demand replay of 5865 yesterday's football game) or "live" (for example, football game 5866 coverage as it occurs), but in either case the user is usually an 5867 "audience member" as opposed to a "participant" (as the user would be in 5868 telephony). 5870 Note that these examples describe the distribution of audio content to 5871 an audience member. The interoperability guidelines in this appendix 5872 address RTP MIDI applications of this nature, not applications such as 5873 the transmission of raw MIDI command streams for use in a professional 5874 environment (recording studio, performance stage, etc.). 5876 In an RTSP session, a client accesses a session description that is 5877 "declared" by the server, either via the RTSP DESCRIBE method, or via 5878 other means, such as HTTP or email. The session description defines the 5879 session from the perspective of the client. For example, if a media 5880 line in the session description contains a non-zero port number, it 5881 encodes the server's preference for the client's port numbers for RTP 5882 and RTCP reception. Once media flow begins, the server sends an RTP 5883 MIDI stream to the client, which renders it for presentation, perhaps in 5884 synchrony with video or other audio streams. 5886 We now define the interoperability text for content-streaming RTSP 5887 applications. 5889 In most cases, server interoperability responsibilities are described in 5890 terms of limits on the "reference" session description a server provides 5891 for a performance if it has no information about the capabilities of the 5892 client. The reference session is a "lowest common denominator" session 5893 that maximizes the odds that a client will be able to view the session. 5894 If a server is aware of the capabilities of the client, the server is 5895 free to provide a session description customized for the client in the 5896 DESCRIBE reply. 5898 Clients MUST support unicast UDP RTP MIDI streams that use the recovery 5899 journal with the closed-loop or the anchor sending policies. Clients 5900 MUST be able to interpret stream subsetting and chapter inclusion 5901 parameters in the session description that qualify the sending policies. 5902 Client support of enhanced Chapter C encoding is OPTIONAL. 5904 The reference session description offered by a server MUST send all RTP 5905 MIDI UDP streams as unicast streams that use the recovery journal and 5906 the closed-loop or anchor sending policies. Servers SHOULD use the 5907 stream subsetting and chapter inclusion parameters in the reference 5908 session description, to simplify the rendering task of the client. 5909 Server support of enhanced Chapter C encoding is OPTIONAL. 5911 Clients and servers MUST support the use of RTSP interleaved mode (a 5912 method for interleaving RTP onto the RTSP TCP transport). 5914 Clients MUST be able to interpret the timestamp semantics signalled by 5915 the "comex" value of the tsmode parameter (i.e., the timestamp semantics 5916 of Standard MIDI Files [MIDI]). Servers MUST use the "comex" value for 5917 the "tsmode" parameter in the reference session description. 5919 Clients MUST be able to process an RTP MIDI stream whose packets encode 5920 an arbitrary temporal duration ("media time"). Thus, in practice, 5921 clients MUST implement a MIDI playout buffer. Clients MUST NOT depend 5922 on the presence of rtp_ptime, rtp_maxtime, and guardtime parameters in 5923 the session description in order to process packets, but they SHOULD be 5924 able to use these parameters to improve packet processing. 5926 Servers SHOULD strive to send RTP MIDI streams in the same way media 5927 servers send conventional audio streams: a sequence of packets that 5928 either all code the same temporal duration (non-normative example: 50 ms 5929 packets) or that code one of an integral number of temporal durations 5930 (non-normative example: 50 ms, 100 ms, 250 ms, or 500 ms packets). 5931 Servers SHOULD encode information about the packetization method in the 5932 rtp_ptime and rtp_maxtime parameters in the session description. 5934 Clients MUST be able to examine the render and subrender parameter, to 5935 determine if a multimedia session uses a renderer it supports. Clients 5936 MUST be able to interpret the default "one" value of the "multimode" 5937 parameter, to identify supported renderers from a list of renderer 5938 descriptions. Clients MUST be able to interpret the musicport 5939 parameter, to the degree that it is relevant to the renderers it 5940 supports. Clients MUST be able to interpret the chanmask parameter. 5942 Clients supporting renderers whose data object (as encoded by a 5943 parameter value for "inline") could exceed 300 octets in size MUST 5944 support the url and cid parameters and thus must implement the HTTP 5945 protocol in addition to RTSP. HTTP over TLS [RFC2818] support for data 5946 objects is OPTIONAL. 5948 Servers MUST specify complete rendering systems for RTP MIDI streams. 5949 Note that a minimal RTP MIDI native stream does not meet this 5950 requirement (Section 6.1), as the rendering method for such streams is 5951 "not specified". 5953 At the time of this memo, the only way for servers to specify a complete 5954 rendering system is to specify an mpeg4-generic RTP MIDI stream in mode 5955 rtp-midi (Section 6.2 and C.6.5). As a consequence, the only rendering 5956 systems that may be presently used are General MIDI [MIDI], DLS 2 5957 [DLS2], or Structured Audio [MPEGSA]. Note that the maximum inline 5958 value for General MIDI is well under 300 octets (and thus clients need 5959 not support the "url" parameter), and that the maximum inline values for 5960 DLS 2 and Structured Audio may be much larger than 300 octets (and thus 5961 clients MUST support the url parameter). 5963 We anticipate that the owners of rendering systems (both standardized 5964 and proprietary) will register subrender parameters for their renderers. 5965 Once registration occurs, native RTP MIDI sessions may use render and 5966 subrender (Appendix C.6.2) to specify complete rendering systems for 5967 RTSP content-streaming multimedia sessions. 5969 Servers MUST NOT use the sdp_start value for the smf_info parameter in 5970 the reference session description, as this use would require that 5971 clients be able to parse and render Standard MIDI Files. 5973 Clients MUST support mpeg4-generic mode rtp-midi General MIDI (GM) 5974 sessions, at a polyphony limited by the hardware capabilities of the 5975 client. This requirement provides a "lowest common denominator" 5976 rendering system for content providers to target. Note that this 5977 requirement does not force implementors of a non-GM renderer (such as 5978 DLS 2 or Structured Audio) to add a second rendering engine. Instead, a 5979 client may satisfy the requirement by including a set of voice patches 5980 that implement the GM instrument set, and using this emulation for 5981 mpeg4-generic GM sessions. 5983 It is RECOMMENDED that servers use General MIDI as the renderer for the 5984 reference session description, because clients are REQUIRED to support 5985 it. We do not require General MIDI as the reference renderer, because 5986 for normative applications it is an inappropriate choice. Servers using 5987 General MIDI as a "lowest common denominator" renderer SHOULD use 5988 Universal Real-Time SysEx MIP messages [SPMIDI] to communicate the 5989 priority of voices to polyphony-limited clients. 5991 C.7.2. MIDI Network Musical Performance Applications 5993 In Internet telephony and videoconferencing applications, parties 5994 interact over an IP network as they would face-to-face. Good user 5995 experiences require low end-to-end audio latency and tight audiovisual 5996 synchronization (for "lip-sync"). The Session Initiation Protocol (SIP, 5997 [RFC3261]) is used for session management. 5999 In this appendix section, we define interoperability guidelines for 6000 using RTP MIDI streams in interactive SIP applications. Our primary 6001 interest is supporting Network Musical Performances (NMP), where 6002 musicians in different locations interact over the network as if they 6003 were in the same room. See [NMP] for background information on NMP, and 6004 see [RFC4696] for a discussion of low-latency RTP MIDI implementation 6005 techniques for NMP. 6007 Note that the goal of NMP applications is telepresence: the parties 6008 should hear audio that is close to what they would hear if they were in 6009 the same room. The interoperability guidelines in this appendix address 6010 RTP MIDI applications of this nature, not applications such as the 6011 transmission of raw MIDI command streams for use in a professional 6012 environment (recording studio, performance stage, etc.). 6014 We focus on session management for two-party unicast sessions that 6015 specify a renderer for RTP MIDI streams. Within this limited scope, the 6016 guidelines defined here are sufficient to let applications interoperate. 6017 We define the REQUIRED capabilities of RTP MIDI senders and receivers in 6018 NMP sessions and define how session descriptions exchanged are used to 6019 set up network musical performance sessions. 6021 SIP lets parties negotiate details of the session, using the 6022 Offer/Answer protocol [RFC3264]. However, RTP MIDI has so many 6023 parameters that "blind" negotiations between two parties using different 6024 applications might not yield a common session configuration. 6026 Thus, we now define a set of capabilities that NMP parties MUST support. 6027 Session description offers whose options lie outside the envelope of 6028 REQUIRED party behavior risk negotiation failure. We also define 6029 session description idioms that the RTP MIDI part of an offer MUST 6030 follow, in order to structure the offer for simpler analysis. 6032 We use the term "offerer" for the party making a SIP offer, and 6033 "answerer" for the party answering the offer. Finally, we note that 6034 unless it is qualified by the adjective "sender" or "receiver", a 6035 statement that a party MUST support X implies that it MUST support X for 6036 both sending and receiving. 6038 If an offerer wishes to define a "sendrecv" RTP MIDI stream, it may use 6039 a true sendrecv session or the "virtual sendrecv" construction described 6040 in the preamble to Appendix C and in Appendix C.5. A true sendrecv 6041 session indicates that the offerer wishes to participate in a session 6042 where both parties use identically configured renderers. A virtual 6043 sendrecv session indicates that the offerer is willing to participate in 6044 a session where the two parties may be using different renderer 6045 configurations. Thus, parties MUST be prepared to see both real and 6046 virtual sendrecv sessions in an offer. 6048 Parties MUST support unicast UDP transport of RTP MIDI streams. These 6049 streams MUST use the recovery journal with the closed-loop or anchor 6050 sending policies. These streams MUST use the stream subsetting and 6051 chapter inclusion parameters to declare the types of MIDI commands that 6052 will be sent on the stream (for sendonly streams) or will be processed 6053 (for recvonly streams), including the size limits on System Exclusive 6054 commands. Support of enhanced Chapter C encoding is OPTIONAL. 6056 Note that both TCP and multicast UDP support are OPTIONAL. We make TCP 6057 OPTIONAL because we expect NMP renderers to rely on data objects 6058 (signalled by "rinit" and associated parameters) for initialization at 6059 the start of the session, and only to use System Exclusive commands for 6060 interactive control during the session. These interactive commands are 6061 small enough to be protected via the recovery journal mechanism of RTP 6062 MIDI UDP streams. 6064 We now discuss timestamps, packet timing, and packet sending algorithms. 6066 Recall that the tsmode parameter controls the semantics of command 6067 timestamps in the MIDI list of RTP packets. 6069 Parties MUST support clock rates of 44.1 kHz, 48 kHz, 88.2 kHz, and 96 6070 kHz. Parties MUST support streams using the "comex", "async", and 6071 "buffer" tsmode values. Recvonly offers MUST offer the default "comex". 6073 Parties MUST support a wide range of packet temporal durations: from 6074 rtp_ptime and rtp_maxptime values of 0, to rtp_ptime and rtp_maxptime 6075 values that code 100 ms. Thus, receivers MUST be able to implement a 6076 playout buffer. 6078 Offers and answers MUST present rtp_ptime, rtp_maxptime, and guardtime 6079 values that support the latency that users would expect in the 6080 application, subject to bandwidth constraints. As senders MUST abide by 6081 values set for these parameters in a session description, a receiver 6082 SHOULD use these values to size its playout buffer to produce the lowest 6083 reliable latency for a session. Implementers should refer to [RFC4696] 6084 for information on packet sending algorithms for latency-sensitive 6085 applications. Parties MUST be able to implement the semantics of the 6086 guardtime parameter, for times from 5 ms to 5000 ms. 6088 We now discuss the use of the render parameter. 6090 Sessions MUST specify complete rendering systems for all RTP MIDI 6091 streams. Note that a minimal RTP MIDI native stream does not meet this 6092 requirement (Section 6.1), as the rendering method for such streams is 6093 "not specified". 6095 At the time this writing, the only way for parties to specify a complete 6096 rendering system is to specify an mpeg4-generic RTP MIDI stream in mode 6097 rtp-midi (Section 6.2 and C.6.5). We anticipate that the owners of 6098 rendering systems (both standardized and proprietary) will register 6099 subrender values for their renderers. Once IANA registration occurs, 6100 native RTP MIDI sessions may use render and subrender (Appendix C.6.2) 6101 to specify complete rendering systems for SIP network musical 6102 performance multimedia sessions. 6104 All parties MUST support General MIDI (GM) sessions, at a polyphony 6105 limited by the hardware capabilities of the party. This requirement 6106 provides a "lowest common denominator" rendering system, without which 6107 practical interoperability will be quite difficult. When using GM, 6108 parties SHOULD use Universal Real-Time SysEx MIP messages [SPMIDI] to 6109 communicate the priority of voices to polyphony-limited clients. 6111 Note that this requirement does not force implementors of a non-GM 6112 renderer (for mpeg4-generic sessions, DLS 2, or Structured Audio) to add 6113 a second rendering engine. Instead, a client may satisfy the 6114 requirement by including a set of voice patches that implement the GM 6115 instrument set, and using this emulation for mpeg4-generic GM sessions. 6116 We require GM support so that an offerer that wishes to maximize 6117 interoperability may do so by offering GM if its preferred renderer is 6118 not accepted by the answerer. 6120 Offerers MUST NOT present several renderers as options in a session 6121 description by listing several payload types on a media line, as Section 6122 2.1 uses this construct to let a party send several RTP MIDI streams in 6123 the same RTP session. 6125 Instead, an offerer wishing to present rendering options SHOULD offer a 6126 single payload type that offers several renderers. In this construct, 6127 the parameter list codes a list of render parameters (each followed by 6128 its support parameters). As discussed in Appendix C.6.1, the order of 6129 renderers in the list declares the offerer's preference. The "unknown" 6130 and "null" values MUST NOT appear in the offer. The answer MUST set all 6131 render values except the desired renderer to "null". Thus, "unknown" 6132 MUST NOT appear in the answer. 6134 We use SHOULD instead of MUST in the first sentence in the paragraph 6135 above, because this technique does not work in all situations (example: 6136 an offerer wishes to offer both mpeg4-generic renderers and native RTP 6137 MIDI renderers as options). In this case, the offerer MUST present a 6138 series of session descriptions, each offering a single renderer, until 6139 the answerer accepts a session description. 6141 Parties MUST support the musicport, chanmask, subrender, rinit, and 6142 inline parameters. Parties supporting renderers whose data object (as 6143 encoded by a parameter value for "inline") could exceed 300 octets in 6144 size MUST support the url and cid parameters and thus must implement the 6145 HTTP protocol. HTTP over TLS [RFC2818] support for data objects is 6146 OPTIONAL. Note that in mpeg4-generic, General MIDI data objects cannot 6147 exceed 300 octets, but DLS 2 and Structured Audio data objects may. 6148 Support for the other rendering parameters (smf_cif, smf_info, 6149 smf_inline, smf_url) is OPTIONAL. 6151 Thus far in this document, our discussion has assumed that the only MIDI 6152 flows that drive a renderer are the network flows described in the 6153 session description. In NMP applications, this assumption would require 6154 two rendering engines: one for local use by a party, a second for the 6155 remote party. 6157 In practice, applications may wish to have both parties share a single 6158 rendering engine. In this case, the session description MUST use a 6159 virtual sendrecv session and MUST use the stream subsetting and chapter 6160 inclusion parameters to allocate which MIDI channels are intended for 6161 use by a party. If two parties are sharing a MIDI channel, the 6162 application MUST ensure that appropriate MIDI merging occurs at the 6163 input to the renderer. 6165 We now discuss the use of (non-MIDI) audio streams in the session. 6167 Audio streams may be used for two purposes: as a "talkback" channel for 6168 parties to converse, or as a way to conduct a performance that includes 6169 MIDI and audio channels. In the latter case, offers MUST use sample 6170 rates and the packet temporal durations for the audio and MIDI streams 6171 that support low-latency synchronized rendering. 6173 We now show an example of an offer/answer exchange in a network musical 6174 performance application (next page). 6176 Below, we show an offer that complies with the interoperability text in 6177 this appendix section. 6179 v=0 6180 o=first 2520644554 2838152170 IN IP4 first.example.net 6181 s=Example 6182 t=0 0 6183 a=group:FID 1 2 6184 c=IN IP4 192.0.2.94 6185 m=audio 16112 RTP/AVP 96 6186 a=recvonly 6187 a=mid:1 6188 a=rtpmap:96 mpeg4-generic/44100 6189 a=fmtp:96 streamtype=5; mode=rtp-midi; config=""; profile-level-id=12; 6190 cm_unused=ABCFGHJKMNPQTVWXYZ; cm_used=2NPTW; 6191 cm_used=2C0.1.7.10.11.64.121.123; cm_used=2M0.1.2; 6192 cm_used=X0-16; ch_never=ABCDEFGHJKMNPQTVWXYZ; 6193 ch_default=2NPTW; ch_default=2C0.1.7.10.11.64.121.123; 6194 ch_default=2M0.1.2; cm_default=X0-16; 6195 rtp_ptime=0; rtp_maxptime=0; guardtime=44100; 6196 musicport=1; render=synthetic; rinit="audio/asc"; 6197 inline="egoAAAAaTVRoZAAAAAYAAAABAGBNVHJrAAAABgD/LwAA" 6198 m=audio 16114 RTP/AVP 96 6199 a=sendonly 6200 a=mid:2 6201 a=rtpmap:96 mpeg4-generic/44100 6202 a=fmtp:96 streamtype=5; mode=rtp-midi; config=""; profile-level-id=12; 6203 cm_unused=ABCFGHJKMNPQTVWXYZ; cm_used=1NPTW; 6204 cm_used=1C0.1.7.10.11.64.121.123; cm_used=1M0.1.2; 6205 cm_used=X0-16; ch_never=ABCDEFGHJKMNPQTVWXYZ; 6206 ch_default=1NPTW; ch_default=1C0.1.7.10.11.64.121.123; 6207 ch_default=1M0.1.2; cm_default=X0-16; 6208 rtp_ptime=0; rtp_maxptime=0; guardtime=44100; 6209 musicport=1; render=synthetic; rinit="audio/asc"; 6210 inline="egoAAAAaTVRoZAAAAAYAAAABAGBNVHJrAAAABgD/LwAA" 6212 (The a=fmtp lines have been wrapped to fit the page to accommodate 6213 memo formatting restrictions; it comprises a single line in SDP.) 6215 The owner line (o=) identifies the session owner as "first". 6217 The session description defines two MIDI streams: a recvonly stream on 6218 which "first" receives a performance, and a sendonly stream that "first" 6219 uses to send a performance. The recvonly port number encodes the ports 6220 on which "first" wishes to receive RTP (16112) and RTCP (16113) media at 6221 IP4 address 192.0.2.94. The sendonly port number encodes the port on 6222 which "first" wishes to receive RTCP for the stream (16115). 6224 The musicport parameters code that the two streams share and identity 6225 relationship and thus form a virtual sendrecv stream. 6227 Both streams are mpeg4-generic RTP MIDI streams that specify a General 6228 MIDI renderer. The stream subsetting parameters code that the recvonly 6229 stream uses MIDI channel 1 exclusively for voice commands, and that the 6230 sendonly stream uses MIDI channel 2 exclusively for voice commands. 6231 This mapping permits the application software to share a single renderer 6232 for local and remote performers. 6234 We now show the answer to the offer. 6236 v=0 6237 o=second 2520644554 2838152170 IN IP4 second.example.net 6238 s=Example 6239 t=0 0 6240 a=group:FID 1 2 6241 c=IN IP4 192.0.2.105 6242 m=audio 5004 RTP/AVP 96 6243 a=sendonly 6244 a=mid:1 6245 a=rtpmap:96 mpeg4-generic/44100 6246 a=fmtp:96 streamtype=5; mode=rtp-midi; config=""; profile-level-id=12; 6247 cm_unused=ABCFGHJKMNPQTVWXYZ; cm_used=2NPTW; 6248 cm_used=2C0.1.7.10.11.64.121.123; cm_used=2M0.1.2; 6249 cm_used=X0-16; ch_never=ABCDEFGHJKMNPQTVWXYZ; 6250 ch_default=2NPTW; ch_default=2C0.1.7.10.11.64.121.123; 6251 ch_default=2M0.1.2; cm_default=X0-16; 6252 rtp_ptime=0; rtp_maxptime=882; guardtime=44100; 6253 musicport=1; render=synthetic; rinit="audio/asc"; 6254 inline="egoAAAAaTVRoZAAAAAYAAAABAGBNVHJrAAAABgD/LwAA" 6255 m=audio 5006 RTP/AVP 96 6256 a=recvonly 6257 a=mid:2 6258 a=rtpmap:96 mpeg4-generic/44100 6259 a=fmtp:96 streamtype=5; mode=rtp-midi; config=""; profile-level-id=12; 6260 cm_unused=ABCFGHJKMNPQTVWXYZ; cm_used=1NPTW; 6261 cm_used=1C0.1.7.10.11.64.121.123; cm_used=1M0.1.2; 6262 cm_used=X0-16; ch_never=ABCDEFGHJKMNPQTVWXYZ; 6263 ch_default=1NPTW; ch_default=1C0.1.7.10.11.64.121.123; 6264 ch_default=1M0.1.2; cm_default=X0-16; 6265 rtp_ptime=0; rtp_maxptime=0; guardtime=88200; 6266 musicport=1; render=synthetic; rinit="audio/asc"; 6267 inline="egoAAAAaTVRoZAAAAAYAAAABAGBNVHJrAAAABgD/LwAA" 6269 (The a=fmtp lines have been wrapped to fit the page to accommodate 6270 memo formatting restrictions; they comprise single lines in SDP.) 6272 The owner line (o=) identifies the session owner as "second". 6274 The port numbers for both media streams are non-zero; thus, "second" has 6275 accepted the session description. The stream marked "sendonly" in the 6276 offer is marked "recvonly" in the answer, and vice versa, coding the 6277 different view of the session held by "session". The IP4 number 6278 (192.0.2.105) and the RTP (5004 and 5006) and RTCP (5005 and 5007) have 6279 been changed by "second" to match its transport wishes. 6281 In addition, "second" has made several parameter changes: rtp_maxptime 6282 for the sendonly stream has been changed to code 2 ms (441 in clock 6283 units), and the guardtime for the recvonly stream has been doubled. As 6284 these parameter modifications request capabilities that are REQUIRED to 6285 be implemented by interoperable parties, "second" can make these changes 6286 with confidence that "first" can abide by them. 6288 D. Parameter Syntax Definitions 6290 In this appendix, we define the syntax for the RTP MIDI media type 6291 parameters in Augmented Backus-Naur Form (ABNF, [RFC5234]). When using 6292 these parameters with SDP, all parameters MUST appear on a single fmtp 6293 attribute line of an RTP MIDI media description. For mpeg4-generic RTP 6294 MIDI streams, this line MUST also include any mpeg4-generic parameters 6295 (usage described in Section 6.2). An fmtp attribute line may be defined 6296 (after [RFC3640]) as: 6298 ; 6299 ; SDP fmtp line definition 6300 ; 6302 fmtp = "a=fmtp:" token SP param-assign 0*(";" SP param-assign) CRLF 6304 where codes the RTP payload type. Note that white space MUST 6305 NOT appear between the "a=fmtp:" and the RTP payload type. 6307 We now define the syntax of the parameters defined in Appendix C. The 6308 definition takes the form of the incremental assembly of the token. See [RFC3640] for the syntax of the mpeg4-generic 6310 parameters discussed in Section 6.2. 6312 ; 6313 ; 6314 ; top-level definition for all parameters 6315 ; 6316 ; 6318 ; 6319 ; Parameters defined in Appendix C.1 6321 param-assign = ("cm_unused=" (([channel-list] command-type 6322 [f-list]) / sysex-data)) 6324 param-assign =/ ("cm_used=" (([channel-list] command-type 6325 [f-list]) / sysex-data)) 6327 ; 6328 ; Parameters defined in Appendix C.2 6330 param-assign =/ ("j_sec=" ("none" / "recj" / ietf-extension)) 6332 param-assign =/ ("j_update=" ("anchor" / "closed-loop" / 6333 "open-loop" / ietf-extension)) 6335 param-assign =/ ("ch_default=" (([channel-list] chapter-list 6336 [f-list]) / sysex-data)) 6338 param-assign =/ ("ch_never=" (([channel-list] chapter-list 6339 [f-list]) / sysex-data)) 6341 param-assign =/ ("ch_anchor=" (([channel-list] chapter-list 6342 [f-list]) / sysex-data)) 6344 ; 6345 ; Parameters defined in Appendix C.3 6347 param-assign =/ ("tsmode=" ("comex" / "async" / "buffer")) 6349 param-assign =/ ("linerate=" nonzero-four-octet) 6351 param-assign =/ ("octpos=" ("first" / "last")) 6353 param-assign =/ ("mperiod=" nonzero-four-octet) 6355 ; 6356 ; Parameter defined in Appendix C.4 6358 param-assign =/ ("guardtime=" nonzero-four-octet) 6360 param-assign =/ ("rtp_ptime=" four-octet) 6362 param-assign =/ ("rtp_maxptime=" four-octet) 6364 ; 6365 ; Parameters defined in Appendix C.5 6367 param-assign =/ ("musicport=" four-octet) 6369 ; 6370 ; Parameters defined in Appendix C.6 6372 param-assign =/ ("chanmask=" 1*( 16(BIT) )) 6374 param-assign =/ ("cid=" DQUOTE cid-block DQUOTE) 6376 param-assign =/ ("inline=" DQUOTE base-64-block DQUOTE) 6378 param-assign =/ ("multimode=" ("all" / "one")) 6380 param-assign =/ ("render=" ("synthetic" / "api" / "null" / 6381 "unknown" / extension)) 6383 param-assign =/ ("rinit=" mime-type "/" mime-subtype) 6385 param-assign =/ ("smf_cid=" DQUOTE cid-block DQUOTE) 6387 param-assign =/ ("smf_info=" ("ignore" / "identity" / 6388 "sdp_start" / extension)) 6390 param-assign =/ ("smf_inline=" DQUOTE base-64-block DQUOTE) 6392 param-assign =/ ("smf_url=" DQUOTE uri-element DQUOTE) 6394 param-assign =/ ("subrender=" ("default" / extension)) 6396 param-assign =/ ("url=" DQUOTE uri-element DQUOTE) 6398 ; 6399 ; list definitions for the cm_ command-type 6400 ; 6402 command-type = [A] [B] [C] [F] [G] [H] [J] [K] [M] 6403 [N] [P] [Q] [T] [V] [W] [X] [Y] [Z] 6405 ; 6406 ; list definitions for the ch_ chapter-list 6407 ; 6409 chapter-list = [A] [B] [C] [D] [E] [F] [G] [H] [J] [K] 6410 [M] [N] [P] [Q] [T] [V] [W] [X] [Y] [Z] 6412 ; 6413 ; list definitions for the channel-list (used in ch_* / cm_* params) 6414 ; 6416 channel-list = midi-chan-element *("." midi-chan-element) 6418 midi-chan-element = midi-chan / midi-chan-range 6420 midi-chan-range = midi-chan "-" midi-chan 6421 ; 6422 ; decimal value of left midi-chan 6423 ; MUST be strictly less than 6424 ; decimal value of right midi-chan 6426 midi-chan = DIGIT / ("1" %x30-35) ; "0" .. "15" 6427 ; 6428 ; list definitions for the ch_ field list (f-list) 6429 ; 6431 f-list = midi-field-element *("." midi-field-element) 6433 midi-field-element = midi-field / midi-field-range 6435 midi-field-range = midi-field "-" midi-field 6436 ; 6437 ; decimal value of left midi-field 6438 ; MUST be strictly less than 6439 ; decimal value of right midi-field 6441 midi-field = four-octet 6442 ; 6443 ; large range accommodates Chapter M 6444 ; RPN (0-16383) and NRPN (16384-32767) 6445 ; parameters, and Chapter X octet sizes. 6447 ; 6448 ; definitions for ch_ sysex-data 6449 ; 6451 sysex-data = "__" h-list *("_" h-list) "__" 6453 h-list = hex-field-element *("." hex-field-element) 6455 hex-field-element = hex-octet / hex-field-range 6457 hex-field-range = hex-octet "-" hex-octet 6458 ; 6459 ; hexadecimal value of left hex-octet 6460 ; MUST be strictly less than hexadecimal 6461 ; value of right hex-octet 6463 hex-octet = %x30-37 U-HEXDIG 6464 ; 6465 ; rewritten special case of hex-octet in [RFC2045] 6466 ; (page 23). 6467 ; note that a-f are not permitted, only A-F. 6468 ; hex-octet values MUST NOT exceed 0x7F. 6470 ; 6471 ; definitions for rinit parameter 6472 ; 6474 mime-type = "audio" / "application" 6475 mime-subtype = token 6476 ; 6477 ; See Appendix C.6.2 for registration 6478 ; requirements for rinit type/subtypes. 6480 ; 6481 ; definitions for base64 encoding 6482 ; copied from [RFC4566] 6483 ; changes from [RFC4566] to improve automatic syntax checking 6484 ; 6486 base-64-block = *base64-unit [base64-pad] 6488 base64-unit = 4(base64-char) 6490 base64-pad = (2(base64-char) "==") / (3(base64-char) "=") 6492 base64-char = %x41-5A / %x61-7A / %x30-39 / "+" / "/" 6493 ; A-Z, a-z, 0-9, "+" and "/" 6495 ; 6496 ; generic rules 6497 ; 6499 ietf-extension = token 6500 ; 6501 ; may only be defined in standards-track RFCs 6503 extension = token 6504 ; 6505 ; may be defined 6506 ; by filing a registration with IANA 6508 nonzero-four-octet = (NZ-DIGIT 0*8(DIGIT)) 6509 / (%x30-33 9(DIGIT)) 6510 / ("4" %x30-31 8(DIGIT)) 6511 / ("42" %x30-38 7(DIGIT)) 6512 / ("429" %x30-33 6(DIGIT)) 6513 / ("4294" %x30-38 5(DIGIT)) 6514 / ("42949" %x30-35 4(DIGIT)) 6515 / ("429496" %x30-36 3(DIGIT)) 6516 / ("4294967" %x30-31 2(DIGIT)) 6517 / ("42949672" %x30-38 (DIGIT)) 6518 / ("429496729" %x30-34) 6519 ; 6520 ; unsigned encoding of non-zero 32-bit value: 6521 ; 1 .. 4294967295 6523 four-octet = "0" / nonzero-four-octet 6524 ; 6525 ; unsigned encoding of 32-bit value: 6526 ; 0 .. 4294967295 6528 uri-element = URI-reference 6529 ; as defined in [RFC3986] 6531 token = 1*token-char 6532 ; copied from [RFC4566] 6534 token-char = %x21 / %x23-27 / %x2A-2B / %x2D-2E / 6535 %x30-39 / %x41-5A / %x5E-7E 6536 ; copied from [RFC4566] 6538 cid-block = 1*cid-char 6540 cid-char = token-char 6541 cid-char =/ "@" 6542 cid-char =/ "," 6543 cid-char =/ ";" 6544 cid-char =/ ":" 6545 cid-char =/ "\" 6546 cid-char =/ "/" 6547 cid-char =/ "[" 6548 cid-char =/ "]" 6549 cid-char =/ "?" 6550 cid-char =/ "=" 6551 ; 6552 ; - add back in the tspecials [RFC2045], except 6553 ; for DQUOTE and the non-email safe ( ) < > 6554 ; - note that the definitions above ensure that 6555 ; cid-block is always enclosed with DQUOTEs 6557 A = %x41 ; uppercase only letters used above 6558 B = %x42 6559 C = %x43 6560 D = %x44 6561 E = %x45 6562 F = %x46 6563 G = %x47 6564 H = %x48 6565 J = %x4A 6566 K = %x4B 6567 M = %x4D 6568 N = %x4E 6569 P = %x50 6570 Q = %x51 6571 T = %x54 6572 V = %x56 6573 W = %x57 6574 X = %x58 6575 Y = %x59 6576 Z = %x5A 6578 NZ-DIGIT = %x31-39 ; non-zero decimal digit 6580 U-HEXDIG = DIGIT / A / B / C / D / E / F 6581 ; variant of HEXDIG [RFC5234] : 6582 ; hexadecimal digit using uppercase A-F only 6584 ; the rules below are from the Core Rules from [RFC5234] 6586 BIT = "0" / "1" 6588 DQUOTE = %x22 ; " (Double Quote) 6590 DIGIT = %x30-39 ; 0-9 6592 ; external references 6593 ; URI-reference: from [RFC3986] 6595 ; 6596 ; End of ABNF 6598 The mpeg4-generic RTP payload [RFC3640] defines a "mode" parameter that 6599 signals the type of MPEG stream in use. We add a new mode value, "rtp- 6600 midi", using the ABNF rule below: 6602 ; 6603 ; mpeg4-generic mode parameter extension 6604 ; 6606 mode =/ "rtp-midi" 6607 ; as described in Section 6.2 of this memo 6609 E. A MIDI Overview for Networking Specialists 6611 This appendix presents an overview of the MIDI standard, for the benefit 6612 of networking specialists new to musical applications. Implementors 6613 should consult [MIDI] for a normative description of MIDI. 6615 Musicians make music by performing a controlled sequence of physical 6616 movements. For example, a pianist plays by coordinating a series of key 6617 presses, key releases, and pedal actions. MIDI represents a musical 6618 performance by encoding these physical gestures as a sequence of MIDI 6619 commands. This high-level musical representation is compact but 6620 fragile: one lost command may be catastrophic to the performance. 6622 MIDI commands have much in common with the machine instructions of a 6623 microprocessor. MIDI commands are defined as binary elements. 6624 Bitfields within a MIDI command have a regular structure and a 6625 specialized purpose. For example, the upper nibble of the first command 6626 octet (the opcode field) codes the command type. MIDI commands may 6627 consist of an arbitrary number of complete octets, but most MIDI 6628 commands are 1, 2, or 3 octets in length. 6630 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 6631 | Channel Voice Messages | Bitfield Pattern | 6632 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 6633 | NoteOff (end a note) | 1000cccc 0nnnnnnn 0vvvvvvv | 6634 |-------------------------------------------------------------| 6635 | NoteOn (start a note) | 1001cccc 0nnnnnnn 0vvvvvvv | 6636 |-------------------------------------------------------------| 6637 | PTouch (Polyphonic Aftertouch) | 1010cccc 0nnnnnnn 0aaaaaaa | 6638 |-------------------------------------------------------------| 6639 | CControl (Controller Change) | 1011cccc 0xxxxxxx 0yyyyyyy | 6640 |-------------------------------------------------------------| 6641 | PChange (Program Change) | 1100cccc 0ppppppp | 6642 |-------------------------------------------------------------| 6643 | CTouch (Channel Aftertouch) | 1101cccc 0aaaaaaa | 6644 |-------------------------------------------------------------| 6645 | PWheel (Pitch Wheel) | 1110cccc 0xxxxxxx 0yyyyyyy | 6646 ------------------------------------------------------------- 6648 Figure E.1 -- MIDI Channel Messages 6650 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 6651 | System Common Messages | Bitfield Pattern | 6652 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 6653 | System Exclusive | 11110000, followed by a | 6654 | | list of 0xxxxxx octets, | 6655 | | followed by 11110111 | 6656 |-------------------------------------------------------------| 6657 | MIDI Time Code Quarter Frame | 11110001 0xxxxxxx | 6658 |-------------------------------------------------------------| 6659 | Song Position Pointer | 11110010 0xxxxxxx 0yyyyyyy | 6660 |-------------------------------------------------------------| 6661 | Song Select | 11110011 0xxxxxxx | 6662 |-------------------------------------------------------------| 6663 | Undefined | 11110100 | 6664 |-------------------------------------------------------------| 6665 | Undefined | 11110101 | 6666 |-------------------------------------------------------------| 6667 | Tune Request | 11110110 | 6668 |-------------------------------------------------------------| 6669 | System Exclusive End Marker | 11110111 | 6670 ------------------------------------------------------------- 6672 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 6673 | System Realtime Messages | Bitfield Pattern | 6674 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 6675 | Clock | 11111000 | 6676 |-------------------------------------------------------------| 6677 | Undefined | 11111001 | 6678 |-------------------------------------------------------------| 6679 | Start | 11111010 | 6680 |-------------------------------------------------------------| 6681 | Continue | 11111011 | 6682 |-------------------------------------------------------------| 6683 | Stop | 11111100 | 6684 |-------------------------------------------------------------| 6685 | Undefined | 11111101 | 6686 |-------------------------------------------------------------| 6687 | Active Sense | 11111110 | 6688 |-------------------------------------------------------------| 6689 | System Reset | 11111111 | 6690 ------------------------------------------------------------- 6692 Figure E.2 -- MIDI System Messages 6694 Figure E.1 and E.2 show the MIDI command family. There are three major 6695 classes of commands: voice commands (opcode field values in the range 6696 0x8 through 0xE), system common commands (opcode field 0xF, commands 6697 0xF0 through 0xF7), and system real-time commands (opcode field 0xF, 6698 commands 0xF8 through 0xFF). Voice commands code the musical gestures 6699 for each timbre in a composition. Systems commands perform functions 6700 that usually affect all voice channels, such as System Reset (0xFF). 6702 E.1. Commands Types 6704 Voice commands execute on one of 16 MIDI channels, as coded by its 4-bit 6705 channel field (field cccc in Figure E.1). In most applications, notes 6706 for different timbres are assigned to different channels. To support 6707 applications that require more than 16 channels, MIDI systems use 6708 several MIDI command streams in parallel, to yield 32, 48, or 64 MIDI 6709 channels. 6711 As an example of a voice command, consider a NoteOn command (opcode 6712 0x9), with binary encoding 1001cccc 0nnnnnnn 0aaaaaaa. This command 6713 signals the start of a musical note on MIDI channel cccc. The note has 6714 a pitch coded by the note number nnnnnnn, and an onset amplitude coded 6715 by note velocity aaaaaaa. 6717 Other voice commands signal the end of notes (NoteOff, opcode 0x8), map 6718 a specific timbre to a MIDI channel (PChange, opcode 0xC), or set the 6719 value of parameters that modulate the timbral quality (all other voice 6720 commands). The exact meaning of most voice channel commands depends on 6721 the rendering algorithms the MIDI receiver uses to generate sound. In 6722 most applications, a MIDI sender has a model (in some sense) of the 6723 rendering method used by the receiver. 6725 System commands perform a variety of global tasks in the stream, 6726 including "sequencer" playback control of pre-recorded MIDI commands 6727 (the Song Position Pointer, Song Select, Clock, Start, Continue, and 6728 Stop messages), SMPTE time code (the MIDI Time Code Quarter Frame 6729 command), and the communication of device-specific data (the System 6730 Exclusive messages). 6732 E.2. Running Status 6734 All MIDI command bitfields share a special structure: the leading bit of 6735 the first octet is set to 1, and the leading bit of all subsequent 6736 octets is set to 0. This structure supports a data compression system, 6737 called running status [MIDI], that improves the coding efficiency of 6738 MIDI. 6740 In running status coding, the first octet of a MIDI voice command may be 6741 dropped if it is identical to the first octet of the previous MIDI voice 6742 command. This rule, in combination with a convention to consider NoteOn 6743 commands with a null third octet as NoteOff commands, supports the 6744 coding of note sequences using two octets per command. 6746 Running status coding is only used for voice commands. The presence of 6747 a system common message in the stream cancels running status mode for 6748 the next voice command. However, system real-time messages do not 6749 cancel running status mode. 6751 E.3. Command Timing 6753 The bitfield formats in Figures E.1 and E.2 do not encode the execution 6754 time for a command. Timing information is not a part of the MIDI 6755 command syntax itself; different applications of the MIDI command 6756 language use different methods to encode timing. 6758 For example, the MIDI command set acts as the transport layer for MIDI 6759 1.0 DIN cables [MIDI]. MIDI cables are short asynchronous serial lines 6760 that facilitate the remote operation of musical instruments and audio 6761 equipment. Timestamps are not sent over a MIDI 1.0 DIN cable. Instead, 6762 the standard uses an implicit "time of arrival" code. Receivers execute 6763 MIDI commands at the moment of arrival. 6765 In contrast, Standard MIDI Files (SMFs, [MIDI]), a file format for 6766 representing complete musical performances, add an explicit timestamp to 6767 each MIDI command, using a delta encoding scheme that is optimized for 6768 statistics of musical performance. SMF timestamps usually code timing 6769 using the metric notation of a musical score. SMF meta-events are used 6770 to add a tempo map to the file, so that score beats may be accurately 6771 converted into units of seconds during rendering. 6773 E.4. AudioSpecificConfig Templates for MMA Renderers 6775 In Section 6.2 and Appendix C.6.5, we describe how session descriptions 6776 include an AudioSpecificConfig data block to specify a MIDI rendering 6777 algorithm for mpeg4-generic RTP MIDI streams. 6779 The bitfield format of AudioSpecificConfig is defined in [MPEGAUDIO]. 6780 StructuredAudioSpecificConfig, a key data structure coded in 6781 AudioSpecificConfig, is defined in [MPEGSA]. 6783 For implementors wishing to specify Structured Audio renderers, a full 6784 understanding of [MPEGSA] and [MPEGAUDIO] is essential. However, many 6785 implementors will limit their rendering options to the two MIDI 6786 Manufacturers Association renderers that may be specified in 6787 AudioSpecificConfig: General MIDI (GM, [MIDI]) and Downloadable Sounds 2 6788 (DLS 2, [DLS2]). 6790 To aid these implementors, we reproduce the AudioSpecificConfig bitfield 6791 formats for a GM renderer and a DLS 2 renderer below. We have checked 6792 these bitfields carefully and believe they are correct. However, we 6793 stress that the material below is informative, and that [MPEGAUDIO] and 6794 [MPEGSA] are the normative definitions for AudioSpecificConfig. 6796 As described in Section 6.2, a minimal mpeg4-generic session description 6797 encodes the AudioSpecificConfig binary bitfield as a hexadecimal string 6798 (whose format is defined in [RFC3640]) that is assigned to the "config" 6799 parameter. As described in Appendix C.6.3, a session description that 6800 uses the render parameter encodes the AudioSpecificConfig binary 6801 bitfield as a Base64-encoded string assigned to the "inline" parameter, 6802 or in the body of an HTTP URL assigned to the "url" parameter. 6804 Below, we show a simplified binary AudioSpecificConfig bitfield format, 6805 suitable for sending and receiving GM and DLS 2 data: 6807 0 1 2 3 6808 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 6809 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6810 | AOTYPE |FREQIDX|CHANNEL|SACNK| FILE_BLK 1 (required) ... | 6811 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6812 |1|SACNK| FILE_BLK 2 (optional) ... | 6813 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6814 | ... |1|SACNK| FILE_BLK N (optional) ... | 6815 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6816 |0|0| (first "0" bit terminates FILE_BLK list) 6817 +-+-+ 6819 Figure E.3 -- Simplified AudioSpecificConfig 6821 The 5-bit AOTYPE field specifies the Audio Object Type as an unsigned 6822 integer. The legal values for use with mpeg4-generic RTP MIDI streams 6823 are "15" (General MIDI), "14" (DLS 2), and "13" (Structured Audio). 6824 Thus, receivers that do not support all three mpeg4-generic renderers 6825 may parse the first 5 bits of an AudioSpecificConfig coded in a session 6826 description and reject sessions that specify unsupported renderers. 6828 The 4-bit FREQIDX field specifies the sampling rate of the renderer. We 6829 show the mapping of FREQIDX values to sampling rates in Figure E.4. 6830 Senders MUST specify a sampling frequency that matches the RTP clock 6831 rate, if possible; if not, senders MUST specify the escape value. 6832 Receivers MUST consult the RTP clock parameter for the true sampling 6833 rate if the escape value is specified. 6835 FREQIDX Sampling Frequency 6837 0x0 96000 6838 0x1 88200 6839 0x2 64000 6840 0x3 48000 6841 0x4 44100 6842 0x5 32000 6843 0x6 24000 6844 0x7 22050 6845 0x8 16000 6846 0x9 12000 6847 0xa 11025 6848 0xb 8000 6849 0xc reserved 6850 0xd reserved 6851 0xe reserved 6852 0xf escape value 6854 Figure E.4 -- FreqIdx encoding 6856 The 4-bit CHANNEL field specifies the number of audio channels for the 6857 renderer. The values 0x1 to 0x5 specify 1 to 5 audio channels; the 6858 value 0x6 specifies 5+1 surround sound, and the value 0x7 specifies 7+1 6859 surround sound. If the rtpmap line in the session description specifies 6860 one of these formats, CHANNEL MUST be set to the corresponding value. 6861 Otherwise, CHANNEL MUST be set to 0x0. 6863 The CHANNEL field is followed by a list of one or more binary file data 6864 blocks. The 3-bit SACNK field (the chunk_type field in class 6865 StructuredAudioSpecificConfig, defined in [MPEGSA]) specifies the type 6866 of each data block. 6868 For General MIDI, only Standard MIDI Files may appear in the list (SACNK 6869 field value 2). For DLS 2, only Standard MIDI Files and DLS 2 RIFF 6870 files (SACNK field value 4) may appear. For both of these file types, 6871 the FILE_BLK field has the format shown in Figure E.5: a 32-bit unsigned 6872 integer value (FILE_LEN) coding the number of bytes in the SMF or RIFF 6873 file, followed by FILE_LEN bytes coding the file data. 6875 0 1 2 3 6876 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 6877 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6878 | FILE_LEN (32-bit, a byte count SMF file or RIFF file) | 6879 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6880 | FILE_DATA (file contents, a list of FILE_LEN bytes) ... | 6881 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6883 Figure E.5 -- The FILE_BLK field format 6885 Note that several files may follow the CHANNEL field. The "1" constant 6886 fields in Figure E.3 code the presence of another file; the "0" constant 6887 field codes the end of the list. The final "0" bit in Figure E.3 codes 6888 the absence of special coding tools (see [MPEGAUDIO] for details). 6889 Senders not using these tools MUST append this "0" bit; receivers that 6890 do not understand these coding tools MUST ignore all data following a 6891 "1" in this position. 6893 The StructuredAudioSpecificConfig bitfield structure requires the 6894 presence of one FILE_BLK. For mpeg4-generic RTP MIDI use of DLS 2, 6895 FILE_BLKs MUST code RIFF files or SMF files. For mpeg4-generic RTP MIDI 6896 use of General MIDI, FILE_BLKs MUST code SMF files. By default, this 6897 SMF will be ignored (Appendix C.6.4.1). In this default case, a GM 6898 StructuredAudioSpecificConfig bitfield SHOULD code a FILE_BLK whose 6899 FILE_LEN is 0, and whose FILE_DATA is empty. 6901 To complete this appendix, we derive the StructuredAudioSpecificConfig 6902 that we use in the General MIDI session examples in this memo. 6903 Referring to Figure E.3, we note that for GM, AOTYPE = 15. Our examples 6904 use a 44,100 Hz sample rate (FREQIDX = 4) and are in mono (CHANNEL = 1). 6905 For GM, a single SMF is encoded (SACNK = 2), using the SMF shown in 6906 Figure E.6 (a 26 byte file). 6908 -------------------------------------------- 6909 | MIDI File =
| 6910 -------------------------------------------- 6912
= 6913 4D 54 68 64 00 00 00 06 00 00 00 01 00 60 6915 = 6916 4D 54 72 6B 00 00 00 04 00 FF 2F 00 6918 Figure E.6 -- SMF file encoded in the example 6920 Placing these constants in binary format into the data structure shown 6921 in Figure E.3 yields the constant shown in Figure E.7. 6923 0 1 2 3 6924 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 6925 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6926 |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| 6927 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6928 |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| 6929 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6930 |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| 6931 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6932 |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| 6933 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6934 |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| 6935 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6936 |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| 6937 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6938 |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| 6939 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6940 |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| 6941 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6942 |0|0| 6943 +-+-+ 6945 Figure E.7 -- AudioSpecificConfig used in GM examples 6947 Expressing this bitfield as an ASCII hexadecimal string yields: 6949 7A0A0000001A4D546864000000060000000100604D54726B0000000600FF2F000 6951 This string is assigned to the "config" parameter in the minimal 6952 mpeg4-generic General MIDI examples in this memo (such as the example in 6953 Section 6.2). Expressing this string in Base64 [RFC2045] yields: 6955 egoAAAAaTVRoZAAAAAYAAAABAGBNVHJrAAAABgD/LwAA 6957 This string is assigned to the "inline" parameter in the General MIDI 6958 example shown in Appendix C.6.5. 6960 F. Changes from RFC 4695 6962 This document fixes errors found in RFC 4695 by reviewers. We thank 6963 Alfred Hoenes and Roni Even for reporting the errors. To our knowledge, 6964 there are no interoperability issues associated with the errors that are 6965 fixed by this document. In this section, we list the error fixes. 6967 In Section 3 of RFC 4695, the bitfield format shown in Figure 3 is 6968 inconsistent with the normative text that (correctly) describes the 6969 bitfield. Specifically, Figure 3 in RFC 4695 incorrectly states the 6970 dependence of the Delta Time 0 field on the Z header bit. Figure 3 in 6971 this document corrects this error. To our knowledge, this error did not 6972 result in incorrect implementations of RFC 4695. 6974 The remaining errors are in Appendices C and D, and concern session 6975 configuration parameters. The numbered list ([1] through [8]) below 6976 describes these errors in detail, in order of appearance in the 6977 document. To our knowledge, there are no interoperability issues 6978 associated with these errors, as implementation activity has so far 6979 focused on an application domain that does not use SDP for session 6980 management. 6982 [1] In Appendix C.1 and Appendix C.2.3 of RFC 4695, an ABNF rule 6983 related to System Chapter X is incorrectly defined as: 6985 = "__" ["_" ] "__" 6987 The correct version of this rule is: 6989 = "__" *( "_" ) "__" 6991 [2] In Appendix C.6.3 of RFC 4695, the URIs permitted to be assigned 6992 to the "url" parameter are not stated clearly. URIs assigned to "url" 6993 MUST specify either HTTP or HTTP over TLS transport protocols. 6995 In Appendix C.7.1 and C.7.2 of RFC 4695, the transport 6996 interoperability requirements for the "url" parameter are not stated 6997 clearly. For both C.7.1 and C.7.2, HTTP is REQUIRED and HTTP over TLS 6998 is OPTIONAL. 7000 [3] Both fmtp lines in both session description examples in Appendix 7001 C.7.2 of RFC 4695 contain instances of the same syntax error (a 7002 missing ";" at a line wrap after a cm_used assignment). 7004 [4] In Appendix D of RFC 4695, all uses of "*ietf-extension" in rules 7005 are in error, and should be replaced with "ietf-extension". Likewise, 7006 all uses of "*extension" are in error, and should be replaced with 7007 "extension". This bug incorrectly lets the null token be assigned to 7008 the j_sec, j_update, render, smf_info, and subrender parameters. 7010 [5] In Appendix D of RFC 4695, the definitions of the 7011 and incorrectly allow lowercase letters to appear in 7012 these strings. The correct definitions of these rules appear below: 7014 command-type = [A] [B] [C] [F] [G] [H] [J] [K] [M] 7015 [N] [P] [Q] [T] [V] [W] [X] [Y] [Z] 7017 chapter-list = [A] [B] [C] [D] [E] [F] [G] [H] [J] [K] 7018 [M] [N] [P] [Q] [T] [V] [W] [X] [Y] [Z] 7020 A = %x41 7021 B = %x42 7022 C = %x43 7023 D = %x44 7024 E = %x45 7025 F = %x46 7026 G = %x47 7027 H = %x48 7028 J = %x4A 7029 K = %x4B 7030 M = %x4D 7031 N = %x4E 7032 P = %x50 7033 Q = %x51 7034 T = %x54 7035 V = %x56 7036 W = %x57 7037 X = %x58 7038 Y = %x59 7039 Z = %x5A 7041 [6] In Appendix D of RFC 4695, the definitions of , 7042 , and are incorrect. The correct 7043 definitions of these rules appear below: 7045 nonzero-four-octet = (NZ-DIGIT 0*8(DIGIT)) 7046 / (%x30-33 9(DIGIT)) 7047 / ("4" %x30-31 8(DIGIT)) 7048 / ("42" %x30-38 7(DIGIT)) 7049 / ("429" %x30-33 6(DIGIT)) 7050 / ("4294" %x30-38 5(DIGIT)) 7051 / ("42949" %x30-35 4(DIGIT)) 7052 / ("429496" %x30-36 3(DIGIT)) 7053 / ("4294967" %x30-31 2(DIGIT)) 7054 / ("42949672" %x30-38 (DIGIT)) 7055 / ("429496729" %x30-34) 7057 four-octet = "0" / nonzero-four-octet 7058 midi-chan = DIGIT / ("1" %x30-35) 7060 DIGIT = %x30-39 7061 NZ-DIGIT = %x31-39 7063 [7] In Appendix D of RFC4695, the rule is 7064 incorrect. The correct definition of this rule appears below. 7066 hex-octet = %x30-37 U-HEXDIG 7067 U-HEXDIG = DIGIT / A / B / C / D / E / F 7069 ; DIGIT as defined in [6] above 7070 ; A, B, C, D, E, F as defined in [5] above 7072 [8] In Appendix D of RFC4695, the rules and 7073 are defined unclearly. The rewritten rules 7074 appear below: 7076 base64-unit = 4(base64-char) 7077 base64-pad = (2(base64-char) "==") / (3(base64-char) "=") 7079 References 7081 Normative References 7083 [MIDI] MIDI Manufacturers Association. "The Complete MIDI 1.0 7084 Detailed Specification", 1996. 7086 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 7087 Jacobson, "RTP: A Transport Protocol for Real-Time 7088 Applications", STD 64, RFC 3550, July 2003. 7090 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 7091 Video Conferences with Minimal Control", STD 65, RFC 7092 3551, July 2003. 7094 [RFC3640] van der Meer, J., Mackie, D., Swaminathan, V., Singer, 7095 D., and P. Gentric, "RTP Payload Format for Transport of 7096 MPEG-4 Elementary Streams", RFC 3640, November 2003. 7098 [MPEGSA] International Standards Organization. "ISO/IEC 14496 7099 MPEG-4", Part 3 (Audio), Subpart 5 (Structured Audio), 7100 2001. 7102 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 7103 Description Protocol", RFC 4566, July 2006. 7105 [MPEGAUDIO] International Standards Organization. "ISO 14496 MPEG- 7106 4", Part 3 (Audio), 2001. 7108 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 7109 Extensions (MIME) Part One: Format of Internet Message 7110 Bodies", RFC 2045, November 1996. 7112 [DLS2] MIDI Manufacturers Association. "The MIDI Downloadable 7113 Sounds Specification", v98.2, 1998. 7115 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 7116 Specifications: ABNF", RFC 5234, January 2008. 7118 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 7119 Requirement Levels", BCP 14, RFC 2119, March 1997. 7121 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 7122 Norrman, "The Secure Real-time Transport Protocol 7123 (SRTP)", RFC 3711, March 2004. 7125 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 7126 with Session Description Protocol (SDP)", RFC 3264, June 7127 2002. 7129 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 7130 Resource Identifier (URI): Generic Syntax", STD 66, RFC 7131 3986, January 2005. 7133 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 7134 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 7135 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 7137 [RFC3388] Camarillo, G., Eriksson, G., Holler, J., and H. 7138 Schulzrinne, "Grouping of Media Lines in the Session 7139 Description Protocol (SDP)", RFC 3388, December 2002. 7141 [RP015] MIDI Manufacturers Association. "Recommended Practice 7142 015 (RP-015): Response to Reset All Controllers", 11/98. 7144 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and 7145 Registration Procedures", BCP 13, RFC 4288, December 7146 2005. 7148 [RFC4855] Casner, S., "MIME Type Registration of RTP 7149 Payload Formats", RFC 4855, February 2007. 7151 Informative References 7153 [NMP] Lazzaro, J. and J. Wawrzynek. "A Case for Network 7154 Musical Performance", 11th International Workshop on 7155 Network and Operating Systems Support for Digital Audio 7156 and Video (NOSSDAV 2001) June 25-26, 2001, Port 7157 Jefferson, New York. 7159 [GRAME] Fober, D., Orlarey, Y. and S. Letz. "Real Time Musical 7160 Events Streaming over Internet", Proceedings of the 7161 International Conference on WEB Delivering of Music 2001, 7162 pages 147-154. 7164 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 7165 A., Peterson, J., Sparks, R., Handley, M., and E. 7166 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 7167 June 2002. 7169 [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time 7170 Streaming Protocol (RTSP)", RFC 2326, April 1998. 7172 [ALF] Clark, D. D. and D. L. Tennenhouse. "Architectural 7173 considerations for a new generation of protocols", 7174 SIGCOMM Symposium on Communications Architectures and 7175 Protocols , (Philadelphia, Pennsylvania), pp. 200--208, 7176 ACM, Sept. 1990. 7178 [RFC4696] Lazzaro, J. and J. Wawrzynek, "An Implementation Guide 7179 for RTP MIDI", RFC 4696, November 2006. 7181 [RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. 7182 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 7183 Functional Specification", RFC 2205, September 1997. 7185 [RFC4571] Lazzaro, J. "Framing Real-time Transport Protocol (RTP) 7186 and RTP Control Protocol (RTCP) Packets over Connection- 7187 Oriented Transport", RFC 4571, July 2006. 7189 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 7191 [SPMIDI] MIDI Manufacturers Association. "Scalable Polyphony 7192 MIDI, Specification and Device Profiles", Document 7193 Version 1.0a, 2002. 7195 [LCP] Apple Computer. "Logic 7 Dedicated Control Surface 7196 Support", Appendix B. Product manual available from 7197 www.apple.com. 7199 Authors' Addresses 7201 John Lazzaro (corresponding author) 7202 UC Berkeley 7203 CS Division 7204 315 Soda Hall 7205 Berkeley CA 94720-1776 7206 EMail: lazzaro@cs.berkeley.edu 7208 John Wawrzynek 7209 UC Berkeley 7210 CS Division 7211 631 Soda Hall 7212 Berkeley CA 94720-1776 7213 EMail: johnw@cs.berkeley.edu 7215 Full Copyright Statement 7217 Copyright (c) 2010 IETF Trust and the persons identified as the 7218 document authors. All rights reserved. 7220 This document is subject to BCP 78 and the IETF Trust's Legal Provisions 7221 Relating to IETF Documents (http://trustee.ietf.org/license-info) 7222 in effect on the date of publication of this document. Please 7223 review these documents carefully, as they describe your rights and 7224 restrictions with respect to this document. Code Components 7225 extracted from this document must include Simplified BSD License 7226 text as described in Section 4.e of the Trust Legal Provisions and 7227 are provided without warranty as described in the Simplified BSD 7228 License. 7230 Copyright (c) 2010 IETF Trust and the persons identified as the 7231 document authors. All rights reserved. 7233 Acknowledgement 7235 Funding for the RFC Editor function is currently provided by the 7236 Internet Society.