idnits 2.17.1 draft-ietf-payload-rfc4695-bis-02.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 7, 2011) is 4796 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) -- 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 2818 (Obsoleted by RFC 9110) -- 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 4695 (Obsoleted by RFC 6295) Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 8 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 March 7, 2011 6 Expires: September 7, 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. This document obsoletes RFC 4695. 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 September 7, 2011. 48 Copyright Notice 50 Copyright (c) 2011 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 . . . . . . . . . . . . . . . . . . . 7 68 2. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . . . 7 69 2.1. RTP Header . . . . . . . . . . . . . . . . . . . . . . . . 8 70 2.2. MIDI Payload . . . . . . . . . . . . . . . . . . . . . . . 12 71 3. MIDI Command Section . . . . . . . . . . . . . . . . . . . . . . 13 72 3.1. Timestamps . . . . . . . . . . . . . . . . . . . . . . . . 14 73 3.2. Command Coding . . . . . . . . . . . . . . . . . . . . . . 17 74 4. The Recovery Journal System . . . . . . . . . . . . . . . . . . . 23 75 5. Recovery Journal Format . . . . . . . . . . . . . . . . . . . . . 25 76 6. Session Description Protocol . . . . . . . . . . . . . . . . . . 29 77 6.1. Session Descriptions for Native Streams . . . . . . . . . 30 78 6.2. Session Descriptions for mpeg4-generic Streams . . . . . . 32 79 6.3. Parameters . . . . . . . . . . . . . . . . . . . . . . . . 34 80 7. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . . . 36 81 8. Congestion Control . . . . . . . . . . . . . . . . . . . . . . . 37 82 9. Security Considerations . . . . . . . . . . . . . . . . . . . . . 38 83 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 39 84 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 39 85 12. Changes from RFC 4695 . . . . . . . . . . . . . . . . . . . . . 51 86 A. The Recovery Journal Channel Chapters . . . . . . . . . . . . . . 54 87 A.1. Recovery Journal Definitions . . . . . . . . . . . . . . . 54 88 A.2. Chapter P: MIDI Program Change . . . . . . . . . . . . . . 59 89 A.3. Chapter C: MIDI Control Change . . . . . . . . . . . . . . 60 90 A.3.1. Log Inclusion Rules . . . . . . . . . . . . . . . . 60 91 A.3.2. Controller Log Format . . . . . . . . . . . . . . . 62 92 A.3.3. Log List Coding Rules . . . . . . . . . . . . . . . 64 93 A.3.4. The Parameter System . . . . . . . . . . . . . . . 67 94 A.4. Chapter M: MIDI Parameter System . . . . . . . . . . . . . 69 95 A.4.1. Log Inclusion Rules . . . . . . . . . . . . . . . . 70 96 A.4.2. Log Coding Rules . . . . . . . . . . . . . . . . . 72 97 A.4.2.1. The Value Tool . . . . . . . . . . . . . . . 73 98 A.4.2.2. The Count Tool . . . . . . . . . . . . . . . 77 99 A.5. Chapter W: MIDI Pitch Wheel . . . . . . . . . . . . . . . 78 100 A.6. Chapter N: MIDI NoteOff and NoteOn . . . . . . . . . . . . 79 101 A.6.1. Header Structure . . . . . . . . . . . . . . . . . 80 102 A.6.2. Note Structures . . . . . . . . . . . . . . . . . . 81 103 A.7. Chapter E: MIDI Note Command Extras . . . . . . . . . . . 83 104 A.7.1. Note Log Format . . . . . . . . . . . . . . . . . . 84 105 A.7.2. Log Inclusion Rules . . . . . . . . . . . . . . . . 84 106 A.8. Chapter T: MIDI Channel Aftertouch . . . . . . . . . . . . 85 107 A.9. Chapter A: MIDI Poly Aftertouch . . . . . . . . . . . . . 86 108 B. The Recovery Journal System Chapters . . . . . . . . . . . . . . 88 109 B.1. System Chapter D: Simple System Commands . . . . . . . . . 88 110 B.1.1. Undefined System Commands . . . . . . . . . . 89 111 B.2. System Chapter V: Active Sense Command . . . . . . . . . . 92 112 B.3. System Chapter Q: Sequencer State Commands . . . . . . . . 93 113 B.3.1. Non-compliant Sequencers . . . . . . . . . . . 95 114 B.4. System Chapter F: MIDI Time Code Tape Position . . . . . . 96 115 B.4.1. Partial Frames . . . . . . . . . . . . . . . . . . 98 116 B.5. System Chapter X: System Exclusive . . . . . . . . . . . . 100 117 B.5.1. Chapter Format . . . . . . . . . . . . . . . . 100 118 B.5.2. Log Inclusion Semantics . . . . . . . . . . . 103 119 B.5.3. TCOUNT and COUNT Fields . . . . . . . . . . . 105 120 C. Session Configuration Tools . . . . . . . . . . . . . . . . . . . 107 121 C.1. Configuration Tools: Stream Subsetting . . . . . . . . . . 108 122 C.2. Configuration Tools: The Journalling System . . . . . . . 112 123 C.2.1. The j_sec Parameter . . . . . . . . . . . . . . . . 113 124 C.2.2. The j_update Parameter . . . . . . . . . . . . . . 114 125 C.2.2.1. The anchor Sending Policy . . . . . . . . . 115 126 C.2.2.2. The closed-loop Sending Policy . . . . . . . 115 127 C.2.2.3. The open-loop Sending Policy . . . . . . . . 119 128 C.2.3. Recovery Journal Chapter Inclusion Parameters . . . 121 129 C.3. Configuration Tools: Timestamp Semantics . . . . . . . . . 126 130 C.3.1. The comex Algorithm . . . . . . . . . . . . . . . . 126 131 C.3.2. The async Algorithm . . . . . . . . . . . . . . . . 127 132 C.3.3. The buffer Algorithm . . . . . . . . . . . . . . . 128 133 C.4. Configuration Tools: Packet Timing Tools . . . . . . . . . 130 134 C.4.1. Packet Duration Tools . . . . . . . . . . . . . . . 130 135 C.4.2. The guardtime Parameter . . . . . . . . . . . . . . 131 136 C.5. Configuration Tools: Stream Description . . . . . . . . . 133 137 C.6. Configuration Tools: MIDI Rendering . . . . . . . . . . . 139 138 C.6.1. The multimode Parameter . . . . . . . . . . . . . . 140 139 C.6.2. Renderer Specification . . . . . . . . . . . . . . 140 140 C.6.3. Renderer Initialization . . . . . . . . . . . . . . 143 141 C.6.4. MIDI Channel Mapping . . . . . . . . . . . . . . . 144 142 C.6.4.1. The smf_info Parameter . . . . . . . . . . . 145 143 C.6.4.2. The smf_inline, smf_url, and smf_cid 144 Parameters . . . . . . . . . . . . . . . . . 147 145 C.6.4.3. The chanmask Parameter . . . . . . . . . . . 148 146 C.6.5. The audio/asc Media Type . . . . . . . . . . . . . 149 147 C.7. Interoperability . . . . . . . . . . . . . . . . . . . . . 151 148 C.7.1. MIDI Content Streaming Applications . . . . . . . . 151 149 C.7.2. MIDI Network Musical Performance Applications . . . 154 150 D. Parameter Syntax Definitions . . . . . . . . . . . . . . . . . . 163 151 E. A MIDI Overview for Networking Specialists . . . . . . . . . . . 170 152 E.1. Commands Types . . . . . . . . . . . . . . . . . . . . . . 172 153 E.2. Running Status . . . . . . . . . . . . . . . . . . . . . . 172 154 E.3. Command Timing . . . . . . . . . . . . . . . . . . . . . . 173 155 E.4. AudioSpecificConfig Templates for MMA Renderers . . . . . 173 156 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178 157 Normative References . . . . . . . . . . . . . . . . . . . . . 178 158 Informative References . . . . . . . . . . . . . . . . . . . . 179 160 1. Introduction 162 This document obsoletes [RFC4695]. 164 The Internet Engineering Task Force (IETF) has developed a set of 165 focused tools for multimedia networking ([RFC3550] [RFC4566] [RFC3261] 166 [RFC2326]). These tools can be combined in different ways to support a 167 variety of real-time applications over Internet Protocol (IP) networks. 169 For example, a telephony application might use the Session Initiation 170 Protocol (SIP, [RFC3261]) to set up a phone call. Call setup would 171 include negotiations to agree on a common audio codec [RFC3264]. 172 Negotiations would use the Session Description Protocol (SDP, [RFC4566]) 173 to describe candidate codecs. 175 After a call is set up, audio data would flow between the parties using 176 the Real Time Protocol (RTP, [RFC3550]) under any applicable profile 177 (for example, the Audio/Visual Profile (AVP, [RFC3551])). The tools 178 used in this telephony example (SIP, SDP, RTP) might be combined in a 179 different way to support a content streaming application, perhaps in 180 conjunction with other tools, such as the Real Time Streaming Protocol 181 (RTSP, [RFC2326]). 183 The MIDI (Musical Instrument Digital Interface) command language [MIDI] 184 is widely used in musical applications that are analogous to the 185 examples described above. On stage and in the recording studio, MIDI is 186 used for the interactive remote control of musical instruments, an 187 application similar in spirit to telephony. On web pages, Standard MIDI 188 Files (SMFs, [MIDI]) rendered using the General MIDI standard [MIDI] 189 provide a low-bandwidth substitute for audio streaming. 191 [RFC4695] was motivated by a simple premise: if MIDI performances could 192 be sent as RTP streams that are managed by IETF session tools, a 193 hybridization of the MIDI and IETF application domains might occur. 195 For example, interoperable MIDI networking might foster network music 196 performance applications, in which a group of musicians, located at 197 different physical locations, interact over a network to perform as they 198 would if they were located in the same room [NMP]. As a second example, 199 the streaming community might begin to use MIDI for low- bitrate audio 200 coding, perhaps in conjunction with normative sound synthesis methods 201 [MPEGSA]. 203 Five years after [RFC4695], these applications have not yet reached the 204 mainstream. However, experiments in academia and industry continue. 205 This memo, which obsoletes [RFC4695] and fixes minor errata (see Section 206 12), has been written in service of these experiments. 208 To enable MIDI applications to use RTP, this memo defines an RTP payload 209 format and its media type. Sections 2-5 and Appendices A-B define the 210 RTP payload format. Section 6 and Appendices C-D define the media types 211 identifying the payload format, the parameters needed for configuration, 212 and how the parameters are utilized in SDP. 214 Appendix C also includes interoperability guidelines for the example 215 applications described above: network musical performance using SIP 216 (Appendix C.7.2) and content-streaming using RTSP (Appendix C.7.1). 218 Another potential application area for RTP MIDI is MIDI networking for 219 professional audio equipment and electronic musical instruments. We do 220 not offer interoperability guidelines for this application in this memo. 221 However, RTP MIDI has been designed with stage and studio applications 222 in mind, and we expect that efforts to define a stage and studio 223 framework will rely on RTP MIDI for MIDI transport services. 225 Some applications may require MIDI media delivery at a certain service 226 quality level (latency, jitter, packet loss, etc). RTP itself does not 227 provide service guarantees. However, applications may use lower-layer 228 network protocols to configure the quality of the transport services 229 that RTP uses. These protocols may act to reserve network resources for 230 RTP flows [RFC2205] or may simply direct RTP traffic onto a dedicated 231 "media network" in a local installation. Note that RTP and the MIDI 232 payload format do provide tools that applications may use to achieve the 233 best possible real-time performance at a given service level. 235 This memo normatively defines the syntax and semantics of the MIDI 236 payload format. However, this memo does not define algorithms for 237 sending and receiving packets. An ancillary document [RFC4696] provides 238 informative guidance on algorithms. Supplemental information may be 239 found in related conference publications [NMP] [GRAME]. 241 Throughout this memo, the phrase "native stream" refers to a stream that 242 uses the rtp-midi media type. The phrase "mpeg4-generic stream" refers 243 to a stream that uses the mpeg4-generic media type (in mode rtp-midi) to 244 operate in an MPEG 4 environment [RFC3640]. Section 6 describes this 245 distinction in detail. 247 1.1. Terminology 249 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 250 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 251 document are to be interpreted as described in BCP 14, RFC 2119 252 [RFC2119]. 254 1.2. Bitfield Conventions 256 Several bitfield coding idioms are used in this document. As most of 257 these idioms only appear in Appendices A-B, we define them in Appendix 258 A.1. 260 However, a few of these idioms also appear in the main text of this 261 document. For convenience, we describe them below: 263 o R flag bit. R flag bits are reserved for future use. Senders 264 MUST set R bits to 0. Receivers MUST ignore R bit values. 266 o LENGTH field. All fields named LENGTH (as distinct from LEN) 267 code the number of octets in the structure that contains it, 268 including the header it resides in and all hierarchical levels 269 below it. If a structure contains a LENGTH field, a receiver 270 MUST use the LENGTH field value to advance past the structure 271 during parsing, rather than use knowledge about the internal 272 format of the structure. 274 2. Packet Format 276 In this section, we introduce the format of RTP MIDI packets. The 277 description includes some background information on RTP, for the benefit 278 of MIDI implementors new to IETF tools. Implementors should consult 279 [RFC3550] for an authoritative description of RTP. 281 This memo assumes that the reader is familiar with MIDI syntax and 282 semantics. Appendix E provides a MIDI overview, at a level of detail 283 sufficient to understand most of this memo. Implementors should consult 284 [MIDI] for an authoritative description of MIDI. 286 The MIDI payload format maps a MIDI command stream (16 voice channels + 287 systems) onto an RTP stream. An RTP media stream is a sequence of 288 logical packets that share a common format. Each packet consists of two 289 parts: the RTP header and the MIDI payload. Figure 1 shows this format 290 (vertical space delineates the header and payload). 292 We describe RTP packets as "logical" packets to highlight the fact that 293 RTP itself is not a network-layer protocol. Instead, RTP packets are 294 mapped onto network protocols (such as unicast UDP, multicast UDP, or 295 TCP) by an application [ALF]. The interleaved mode of the Real Time 296 Streaming Protocol (RTSP, [RFC2326]) is an example of an RTP mapping to 297 TCP transport, as is [RFC4571]. 299 2.1. RTP Header 301 [RFC3550] provides a complete description of the RTP header fields. In 302 this section, we clarify the role of a few RTP header fields for MIDI 303 applications. All fields are coded in network byte order (big- endian). 305 0 1 2 3 306 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 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 | V |P|X| CC |M| PT | Sequence number | 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 | Timestamp | 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 | SSRC | 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 | MIDI command section ... | 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 | Journal section ... | 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 Figure 1 -- Packet format 323 The behavior of the 1-bit M field depends on the media type of the 324 stream. For native streams, the M bit MUST be set to 1 if the MIDI 325 command section has a non-zero LEN field, and MUST be set to 0 326 otherwise. For mpeg4-generic streams, the M bit MUST be set to 1 for 327 all packets (to conform to [RFC3640]). 329 In an RTP MIDI stream, the 16-bit sequence number field is initialized 330 to a randomly chosen value and is incremented by one (modulo 2^16) for 331 each packet sent in the stream. A related quantity, the 32-bit extended 332 packet sequence number, may be computed by tracking rollovers of the 333 16-bit sequence number. Note that different receivers of the same 334 stream may compute different extended packet sequence numbers, depending 335 on when the receiver joined the session. 337 The 32-bit timestamp field sets the base timestamp value for the packet. 338 The payload codes MIDI command timing relative to this value. The 339 timestamp units are set by the clock rate parameter. For example, if 340 the clock rate has a value of 44100 Hz, two packets whose base timestamp 341 values differ by 2 seconds have RTP timestamp fields that differ by 342 88200. 344 Note that the clock rate parameter is not encoded within each RTP MIDI 345 packet. A receiver of an RTP MIDI stream becomes aware of the clock 346 rate as part of the session setup process. For example, if a session 347 management tool uses the Session Description Protocol (SDP, [RFC4566]) 348 to describe a media session, the clock rate parameter is set using the 349 rtpmap attribute. We show examples of session setup in Section 6. 351 For RTP MIDI streams destined to be rendered into audio, the clock rate 352 SHOULD be an audio sample rate of 32 KHz or higher. This recommendation 353 is due to the sensitivity of human musical perception to small timing 354 errors in musical note sequences, and due to the timbral changes that 355 occur when two near-simultaneous MIDI NoteOns are rendered with a 356 different timing than that desired by the content author due to clock 357 rate quantization. RTP MIDI streams that are not destined for audio 358 rendering (such as MIDI streams that control stage lighting) MAY use a 359 lower clock rate but SHOULD use a clock rate high enough to avoid timing 360 artifacts in the application. 362 For RTP MIDI streams destined to be rendered into audio, the clock rate 363 SHOULD be chosen from rates in common use in professional audio 364 applications or in consumer audio distribution. At the time of this 365 writing, these rates include 32 KHz, 44.1 KHz, 48 KHz, 64 KHz, 88.2 KHz, 366 96 KHz, 176.4 KHz, and 192 KHz. If the RTP MIDI session is a part of a 367 synchronized media session that includes another (non-MIDI) RTP audio 368 stream with a clock rate of 32 KHz or higher, the RTP MIDI stream SHOULD 369 use a clock rate that matches the clock rate of the other audio stream. 370 However, if the RTP MIDI stream is destined to be rendered into audio, 371 the RTP MIDI stream SHOULD NOT use a clock rate lower than 32 KHz, even 372 if this second stream has a clock rate less than 32 KHz. 374 Timestamps of consecutive packets do not necessarily increment at a 375 fixed rate, because RTP MIDI packets are not necessarily sent at a fixed 376 rate. The degree of packet transmission regularity reflects the 377 underlying application dynamics. Interactive applications may vary the 378 packet sending rate to track the gestural rate of a human performer, 379 whereas content-streaming applications may send packets at a fixed rate. 381 Therefore, the timestamps for two sequential RTP packets may be 382 identical, or the second packet may have a timestamp arbitrarily larger 383 than the first packet (modulo 2^32). Section 3 places additional 384 restrictions on the RTP timestamps for two sequential RTP packets, as 385 does the guardtime parameter (Appendix C.4.2). 387 We use the term "media time" to denote the temporal duration of the 388 media coded by an RTP packet. The media time coded by a packet is 389 computed by subtracting the last command timestamp in the MIDI command 390 section from the RTP timestamp (modulo 2^32). If the MIDI list of the 391 MIDI command section of a packet is empty, the media time coded by the 392 packet is 0 ms. Appendix C.4.1 discusses media time issues in detail. 394 We now define RTP session semantics, in the context of sessions 395 specified using the session description protocol [RFC4566]. A session 396 description media line ("m=") specifies an RTP session. An RTP session 397 has an independent space of 2^32 synchronization sources. 398 Synchronization source identifiers are coded in the SSRC header field of 399 RTP session packets. The payload types that may appear in the PT header 400 field of RTP session packets are listed at the end of the media line. 402 Several RTP MIDI streams may appear in an RTP session. Each stream is 403 distinguished by a unique SSRC value and has a unique sequence number 404 and RTP timestamp space. Multiple streams in the RTP session may be 405 sent by a single party. Multiple parties may send streams in the RTP 406 session. An RTP MIDI stream encodes data for a single MIDI command name 407 space (16 voice channels + Systems). 409 Streams in an RTP session may use different payload types, or they may 410 use the same payload type. However, each party may send, at most, one 411 RTP MIDI stream for each payload type mapped to an RTP MIDI payload 412 format in an RTP session. Recall that dynamic binding of payload type 413 numbers in [RFC4566] lets a party map many payload type numbers to the 414 RTP MIDI payload format; thus a party may send many RTP MIDI streams in 415 a single RTP session. Pairs of streams (unicast or multicast) that 416 communicate between two parties in an RTP session and that share a 417 payload type have the same association as a MIDI cable pair that cross- 418 connects two devices in a MIDI 1.0 DIN network. 420 The RTP session architecture described above is efficient in its use of 421 network ports, as one RTP session (using a port pair per party) supports 422 the transport of many MIDI name spaces (16 MIDI channels + systems). We 423 define tools for grouping and labelling MIDI name spaces across streams 424 and sessions in Appendix C.5 of this memo. 426 The RTP header timestamps for each stream in an RTP session have 427 separately and randomly chosen initialization values. Receivers use the 428 timing fields encoded in the RTP control protocol (RTCP, [RFC3550]) 429 sender reports to synchronize the streams sent by a party. The SSRC 430 values for each stream in an RTP session are also separately and 431 randomly chosen, as described in [RFC3550]. Receivers use the CNAME 432 field encoded in RTCP sender reports to verify that streams were sent by 433 the same party, and to detect SSRC collisions, as described in 434 [RFC3550]. 436 In some applications, a receiver renders MIDI commands into audio (or 437 into control actions, such as the rewind of a tape deck or the dimming 438 of stage lights). In other applications, a receiver presents a MIDI 439 stream to software programs via an Application Programmer Interface 440 (API). Appendix C.6 defines session configuration tools to specify what 441 receivers should do with a MIDI command stream. 443 If a multimedia session uses different RTP MIDI streams to send 444 different classes of media, the streams MUST be sent over different RTP 445 sessions. For example, if a multimedia session uses one MIDI stream for 446 audio and a second MIDI stream to control a lighting system, the audio 447 and lighting streams MUST be sent over different RTP sessions, each with 448 its own media line. 450 Session description tools defined in Appendix C.5 let a sending party 451 split a single MIDI name space (16 voice channels + systems) over 452 several RTP MIDI streams. Split transport of a MIDI command stream is a 453 delicate task, because correct command stream reconstruction by a 454 receiver depends on exact timing synchronization across the streams. 456 To support split name spaces, we define the following requirements: 458 o A party MUST NOT send several RTP MIDI streams that share a MIDI 459 name space in the same RTP session. Instead, each stream MUST 460 be sent from a different RTP session. 462 o If several RTP MIDI streams sent by a party share a MIDI name 463 space, all streams MUST use the same SSRC value and MUST use the 464 same randomly chosen RTP timestamp initialization value. 466 These rules let a receiver identify streams that share a MIDI name space 467 (by matching SSRC values) and also let a receiver accurately reconstruct 468 the source MIDI command stream (by using RTP timestamps to interleave 469 commands from the two streams). Care MUST be taken by senders to ensure 470 that SSRC changes due to collisions are reflected in both streams. 471 Receivers MUST regularly examine the RTCP CNAME fields associated with 472 the linked streams, to ensure that the assumed link is legitimate and 473 not the result of an SSRC collision by another sender. 475 Except for the special cases described above, a party may send many RTP 476 MIDI streams in the same session. However, it is sometimes advantageous 477 for two RTP MIDI streams to be sent over different RTP sessions. For 478 example, two streams may need different values for RTP session-level 479 attributes (such as the sendonly and recvonly attributes). As a second 480 example, two RTP sessions may be needed to send two unicast streams in a 481 multimedia session that originate on different computers (with different 482 IP numbers). Two RTP sessions are needed in this case because transport 483 addresses are specified on the RTP-session or multimedia-session level, 484 not on a payload type level. 486 On a final note, in some uses of MIDI, parties send bidirectional 487 traffic to conduct transactions (such as file exchange). These commands 488 were designed to work over MIDI 1.0 DIN cable networks may be configured 489 in a multicast topology, which use pure "party-line" signalling. Thus, 490 if a multimedia session ensures a multicast connection between all 491 parties, bidirectional MIDI commands will work without additional 492 support from the RTP MIDI payload format. 494 2.2. MIDI Payload 496 The payload (Figure 1) MUST begin with the MIDI command section. The 497 MIDI command section codes a (possibly empty) list of timestamped MIDI 498 commands, and provides the essential service of the payload format. 500 The payload MAY also contain a journal section. The journal section 501 provides resiliency by coding the recent history of the stream. A flag 502 in the MIDI command section codes the presence of a journal section in 503 the payload. 505 Section 3 defines the MIDI command section. Sections 4-5 and Appendices 506 A-B define the recovery journal, the default format for the journal 507 section. Here, we describe how these payload sections operate in a 508 stream in an RTP session. 510 The journalling method for a stream is set at the start of a session and 511 MUST NOT be changed thereafter. A stream may be set to use the recovery 512 journal, to use an alternative journal format (none are defined in this 513 memo), or not to use a journal. 515 The default journalling method of a stream is inferred from its 516 transport type. Streams that use unreliable transport (such as UDP) 517 default to using the recovery journal. Streams that use reliable 518 transport (such as TCP) default to not using a journal. Appendix C.2.1 519 defines session configuration tools for overriding these defaults. For 520 all types of transport, a sender MUST transmit an RTP packet stream with 521 consecutive sequence numbers (modulo 2^16). 523 If a stream uses the recovery journal, every payload in the stream MUST 524 include a journal section. If a stream does not use journalling, a 525 journal section MUST NOT appear in a stream payload. If a stream uses 526 an alternative journal format, the specification for the journal format 527 defines an inclusion policy. 529 If a stream is sent over UDP transport, the Maximum Transmission Unit 530 (MTU) of the underlying network limits the practical size of the payload 531 section (for example, an Ethernet MTU is 1500 octets), for applications 532 where predictable and minimal packet transmission latency is critical. 533 A sender SHOULD NOT create RTP MIDI UDP packets whose size exceeds the 534 MTU of the underlying network. Instead, the sender SHOULD take steps to 535 keep the maximum packet size under the MTU limit. 537 These steps may take many forms. The default closed-loop recovery 538 journal sending policy (defined in Appendix C.2.2.2) uses RTP control 539 protocol (RTCP, [RFC3550]) feedback to manage the RTP MIDI packet size. 540 In addition, Section 3.2 and Appendix B.5.2 provide specific tools for 541 managing the size of packets that code MIDI System Exclusive (0xF0) 542 commands. Appendix C.5 defines session configuration tools that may be 543 used to split a dense MIDI name space into several UDP streams (each 544 sent in a different RTP session, per Section 2.1) so that the payload 545 fits comfortably into an MTU. Another option is to use TCP. Section 546 4.3 of [RFC4696] provides non-normative advice for packet size 547 management. 549 3. MIDI Command Section 551 Figure 2 shows the format of the MIDI command section. 553 0 1 2 3 554 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 555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 556 |B|J|Z|P|LEN... | MIDI list ... | 557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 559 Figure 2 -- MIDI command section 561 The MIDI command section begins with a variable-length header. 563 The header field LEN codes the number of octets in the MIDI list that 564 follow the header. If the header flag B is 0, the header is one octet 565 long, and LEN is a 4-bit field, supporting a maximum MIDI list length of 566 15 octets. 568 If B is 1, the header is two octets long, and LEN is a 12-bit field, 569 supporting a maximum MIDI list length of 4095 octets. LEN is coded in 570 network byte order (big-endian): the 4 bits of LEN that appear in the 571 first header octet code the most significant 4 bits of the 12-bit LEN 572 value. 574 A LEN value of 0 is legal, and it codes an empty MIDI list. 576 If the J header bit is set to 1, a journal section MUST appear after the 577 MIDI command section in the payload. If the J header bit is set to 0, 578 the payload MUST NOT contain a journal section. 580 We define the semantics of the P header bit in Section 3.2. 582 If the LEN header field is nonzero, the MIDI list has the structure 583 shown in Figure 3. 585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 586 | Delta Time 0 (1-4 octets long, or 0 octets if Z = 0) | 587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 588 | MIDI Command 0 (1 or more octets long) | 589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 590 | Delta Time 1 (1-4 octets long) | 591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 592 | MIDI Command 1 (1 or more octets long) | 593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 594 | ... | 595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 596 | Delta Time N (1-4 octets long) | 597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 598 | MIDI Command N (0 or more octets long) | 599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 601 Figure 3 -- MIDI list structure 603 If the header flag Z is 1, the MIDI list begins with a complete MIDI 604 command (coded in the MIDI Command 0 field, in Figure 3) preceded by a 605 delta time (coded in the Delta Time 0 field). If Z is 0, the Delta Time 606 0 field is not present in the MIDI list, and the command coded in the 607 MIDI Command 0 field has an implicit delta time of 0. 609 The MIDI list structure may also optionally encode a list of N 610 additional complete MIDI commands, each coded in a MIDI Command K field. 611 Each additional command MUST be preceded by a Delta Time K field, which 612 codes the command's delta time. We discuss exceptions to the "command 613 fields code complete MIDI commands" rule in Section 3.2. 615 The final MIDI command field (i.e., the MIDI Command N field, shown in 616 Figure 3) in the MIDI list MAY be empty. Moreover, a MIDI list MAY 617 consist a single delta time (encoded in the Delta Time 0 field) without 618 an associated command (which would have been encoded in the MIDI Command 619 0 field). These rules enable MIDI coding features that are explained in 620 Section 3.1. We delay the explanations because an understanding of RTP 621 MIDI timestamps is necessary to describe the features. 623 3.1. Timestamps 625 In this section, we describe how RTP MIDI encodes a timestamp for each 626 MIDI list command. Command timestamps have the same units as RTP packet 627 header timestamps (described in Section 2.1 and [RFC3550]). Recall that 628 RTP timestamps have units of seconds, whose scaling is set during 629 session configuration (see Section 6.1 and [RFC4566]). 631 As shown in Figure 3, the MIDI list encodes time using a compact delta- 632 time format. The RTP MIDI delta time syntax is a modified form of the 633 MIDI File delta time syntax [MIDI]. RTP MIDI delta times use 1-4 octet 634 fields to encode 32-bit unsigned integers. Figure 4 shows the encoded 635 and decoded forms of delta times. Note that delta time values may be 636 legally encoded in multiple formats; for example, there are four legal 637 ways to encode the zero delta time (0x00, 0x8000, 0x808000, 0x80808000). 639 RTP MIDI uses delta times to encode a timestamp for each MIDI command. 640 The timestamp for MIDI Command K is the summation (modulo 2^32) of the 641 RTP timestamp and decoded delta times 0 through K. This cumulative 642 coding technique, borrowed from MIDI File delta time coding, is 643 efficient because it reduces the number of multi-octet delta times. 645 All command timestamps in a packet MUST be less than or equal to the RTP 646 timestamp of the next packet in the stream (modulo 2^32). 648 This restriction ensures that a particular RTP MIDI packet in a stream 649 is uniquely responsible for encoding time starting at the moment after 650 the RTP timestamp encoded in the RTP packet header, and ending at the 651 moment before the final command timestamp encoded in the MIDI list. The 652 "moment before" and "moment after" qualifiers acknowledge the "less than 653 or equal" semantics (as opposed to "strictly less than") in the sentence 654 above this paragraph. 656 Note that it is possible to "pad" the end of an RTP MIDI packet with 657 time that is guaranteed to be void of MIDI commands, by setting the 658 "Delta Time N" field of the MIDI list to the end of the void time, and 659 by omitting its corresponding "MIDI Command N" field (a syntactic 660 construction the preamble of Section 3 expressly made legal). 662 In addition, it is possible to code an RTP MIDI packet to express that a 663 period of time in the stream is void of MIDI commands. The RTP 664 timestamp in the header would code the start of the void time. The MIDI 665 list of this packet would consist of a "Delta Time 0" field that coded 666 the end of the void time. No other fields would be present in the MIDI 667 list (a syntactic construction the preamble of Section 3 also expressly 668 made legal). 670 By default, a command timestamp indicates the execution time for the 671 command. The difference between two timestamps indicates the time delay 672 between the execution of the commands. This difference may be zero, 673 coding simultaneous execution. In this memo, we refer to this 674 interpretation of timestamps as "comex" (COMmand EXecution) semantics. 675 We formally define comex semantics in Appendix C.3. 677 The comex interpretation of timestamps works well for transcoding a 678 Standard MIDI File (SMF) into an RTP MIDI stream, as SMFs code a 679 timestamp for each MIDI command stored in the file. To transcode an SMF 680 that uses metric time markers, use the SMF tempo map (encoded in the SMF 681 as meta-events) to convert metric SMF timestamp units into seconds-based 682 RTP timestamp units. 684 The comex interpretation also works well for MIDI hardware controllers 685 that are coding raw sensor data directly onto an RTP MIDI stream. Note 686 that this controller design is preferable to a design that converts raw 687 sensor data into a MIDI 1.0 cable command stream and then transcodes the 688 stream onto an RTP MIDI stream. 690 The comex interpretation of timestamps is usually not the best timestamp 691 interpretation for transcoding a MIDI source that uses implicit command 692 timing (such as MIDI 1.0 DIN cables) into an RTP MIDI stream. Appendix 693 C.3 defines alternatives to comex semantics and describes session 694 configuration tools for selecting the timestamp interpretation semantics 695 for a stream. 697 One-Octet Delta Time: 699 Encoded form: 0ddddddd 700 Decoded form: 00000000 00000000 00000000 0ddddddd 702 Two-Octet Delta Time: 704 Encoded form: 1ccccccc 0ddddddd 705 Decoded form: 00000000 00000000 00cccccc cddddddd 707 Three-Octet Delta Time: 709 Encoded form: 1bbbbbbb 1ccccccc 0ddddddd 710 Decoded form: 00000000 000bbbbb bbcccccc cddddddd 712 Four-Octet Delta Time: 714 Encoded form: 1aaaaaaa 1bbbbbbb 1ccccccc 0ddddddd 715 Decoded form: 0000aaaa aaabbbbb bbcccccc cddddddd 717 Figure 4 -- Decoding delta time formats 719 3.2. Command Coding 721 Each non-empty MIDI Command field in the MIDI list codes one of the MIDI 722 command types that may legally appear on a MIDI 1.0 DIN cable. Standard 723 MIDI File meta-events do not fit this definition and MUST NOT appear in 724 the MIDI list. As a rule, each MIDI Command field codes a complete 725 command, in the binary command format defined in [MIDI]. In the 726 remainder of this section, we describe exceptions to this rule. 728 The first MIDI channel command in the MIDI list MUST include a status 729 octet. Running status coding, as defined in [MIDI], MAY be used for all 730 subsequent MIDI channel commands in the list. As in [MIDI], System 731 Common and System Exclusive messages (0xF0 ... 0xF7) cancel the running 732 status state, but System Real-time messages (0xF8 ... 0xFF) do not 733 affect the running status state. All System commands in the MIDI list 734 MUST include a status octet. 736 As we note above, the first channel command in the MIDI list MUST 737 include a status octet. However, the corresponding command in the 738 original MIDI source data stream might not have a status octet (in this 739 case, the source would be coding the command using running status). If 740 the status octet of the first channel command in the MIDI list does not 741 appear in the source data stream, the P (phantom) header bit MUST be set 742 to 1. In all other cases, the P bit MUST be set to 0. 744 Note that the P bit describes the MIDI source data stream, not the MIDI 745 list encoding; regardless of the state of the P bit, the MIDI list MUST 746 include the status octet. 748 As receivers MUST be able to decode running status, sender implementors 749 should feel free to use running status to improve bandwidth efficiency. 750 However, senders SHOULD NOT introduce timing jitter into an existing 751 MIDI command stream through an inappropriate use or removal of running 752 status coding. This warning primarily applies to senders whose RTP MIDI 753 streams may be transcoded onto a MIDI 1.0 DIN cable [MIDI] by the 754 receiver: both the timestamps and the command coding (running status or 755 not) must comply with the physical restrictions of implicit time coding 756 over a slow serial line. 758 On a MIDI 1.0 DIN cable [MIDI], a System Real-time command may be 759 embedded inside of another "host" MIDI command. This syntactic 760 construction is not supported in the payload format: a MIDI Command 761 field in the MIDI list codes exactly one MIDI command (partially or 762 completely). 764 To encode an embedded System Real-time command, senders MUST extract the 765 command from its host and code it in the MIDI list as a separate 766 command. The host command and System Real-time command SHOULD appear in 767 the same MIDI list. The delta time of the System Real-time command 768 SHOULD result in a command timestamp that encodes the System Real-time 769 command placement in its original embedded position. 771 Two methods are provided for encoding MIDI System Exclusive (SysEx) 772 commands in the MIDI list. A SysEx command may be encoded in a MIDI 773 Command field verbatim: a 0xF0 octet, followed by an arbitrary number of 774 data octets, followed by a 0xF7 octet. 776 Alternatively, a SysEx command may be encoded as multiple segments. The 777 command is divided into two or more SysEx command segments; each segment 778 is encoded in its own MIDI Command field in the MIDI list. 780 The payload format supports segmentation in order to encode SysEx 781 commands that encode information in the temporal pattern of data octets. 782 By encoding these commands as a series of segments, each data octet may 783 be associated with a distinct delta time. Segmentation also supports 784 the coding of large SysEx commands across several packets. 786 To segment a SysEx command, first partition its data octet list into two 787 or more sublists. The last sublist MAY be empty (i.e., contain no 788 octets); all other sublists MUST contain at least one data octet. To 789 complete the segmentation, add the status octets defined in Figure 5 to 790 the head and tail of the first, last, and any "middle" sublists. Figure 791 6 shows example segmentations of a SysEx command. 793 A sender MAY cancel a segmented SysEx command transmission that is in 794 progress, by sending the "cancel" sublist shown in Figure 5. A "cancel" 795 sublist MAY follow a "first" or "middle" sublist in the transmission, 796 but MUST NOT follow a "last" sublist. The cancel MUST be empty (thus, 797 0xF7 0xF4 is the only legal cancel sublist). 799 The cancellation feature is needed because Appendix C.1 defines 800 configuration tools that let session parties exclude certain SysEx 801 commands in the stream. Senders that transcode a MIDI source onto an 802 RTP MIDI stream under these constraints have the responsibility of 803 excluding undesired commands from the RTP MIDI stream. 805 The cancellation feature lets a sender start the transmission of a 806 command before the MIDI source has sent the entire command. If a sender 807 determines that the command whose transmission is in progress should not 808 appear on the RTP stream, it cancels the command. Without a method for 809 cancelling a SysEx command transmission, senders would be forced to use 810 a high-latency store-and-forward approach to transcoding SysEx commands 811 onto RTP MIDI packets, in order to validate each SysEx command before 812 transmission. 814 The recommended receiver reaction to a cancellation depends on the 815 capabilities of the receiver. For example, a sound synthesizer that is 816 directly parsing RTP MIDI packets and rendering them to audio will be 817 aware of the fact that SysEx commands may be cancelled in RTP MIDI. 818 These receivers SHOULD detect a SysEx cancellation in the MIDI list and 819 act as if they had never received the SysEx command. 821 As a second example, a synthesizer may be receiving MIDI data from an 822 RTP MIDI stream via a MIDI DIN cable (or a software API emulation of a 823 MIDI DIN cable). In this case, an RTP-MIDI-aware system receives the 824 RTP MIDI stream and transcodes it onto the MIDI DIN cable (or its 825 emulation). Upon the receipt of the cancel sublist, the RTP-MIDI- aware 826 transcoder might have already sent the first part of the SysEx command 827 on the MIDI DIN cable to the receiver. 829 Unfortunately, the MIDI DIN cable protocol cannot directly code "cancel 830 SysEx in progress" semantics. However, MIDI DIN cable receivers begin 831 SysEx processing after the complete command arrives. The receiver 832 checks to see if it recognizes the command (coded in the first few 833 octets) and then checks to see if the command is the correct length. 834 Thus, in practice, a transcoder can cancel a SysEx command by sending an 835 0xF7 to (prematurely) end the SysEx command -- the receiver will detect 836 the incorrect command length and discard the command. 838 Appendix C.1 defines configuration tools that may be used to prohibit 839 SysEx command cancellation. 841 The relative ordering of SysEx command segments in a MIDI list must 842 match the relative ordering of the sublists in the original SysEx 843 command. By default, commands other than System Real-time MIDI commands 844 MUST NOT appear between SysEx command segments (Appendix C.1 defines 845 configuration tools to change this default, to let other commands types 846 appear between segments). If the command segments of a SysEx command 847 are placed in the MIDI lists of two or more RTP packets, the segment 848 ordering rules apply to the concatenation of all affected MIDI lists. 850 ----------------------------------------------------------- 851 | Sublist Position | Head Status Octet | Tail Status Octet | 852 |-----------------------------------------------------------| 853 | first | 0xF0 | 0xF0 | 854 |-----------------------------------------------------------| 855 | middle | 0xF7 | 0xF0 | 856 |-----------------------------------------------------------| 857 | last | 0xF7 | 0xF7 | 858 |-----------------------------------------------------------| 859 | cancel | 0xF7 | 0xF4 | 860 ----------------------------------------------------------- 862 Figure 5 -- Command segmentation status octets 864 [MIDI] permits 0xF7 octets that are not part of a (0xF0, 0xF7) pair to 865 appear on a MIDI 1.0 DIN cable. Unpaired 0xF7 octets have no semantic 866 meaning in MIDI, apart from cancelling running status. 868 Unpaired 0xF7 octets MUST NOT appear in the MIDI list of the MIDI 869 Command section. We impose this restriction to avoid interference with 870 the command segmentation coding defined in Figure 5. 872 SysEx commands carried on a MIDI 1.0 DIN cable may use the "dropped 873 0xF7" construction [MIDI]. In this coding method, the 0xF7 octet is 874 dropped from the end of the SysEx command, and the status octet of the 875 next MIDI command acts both to terminate the SysEx command and start the 876 next command. To encode this construction in the payload format, follow 877 these steps: 879 o Determine the appropriate delta times for the SysEx command and 880 the command that follows the SysEx command. 882 o Insert the "dropped" 0xF7 octet at the end of the SysEx command, 883 to form the standard SysEx syntax. 885 o Code both commands into the MIDI list using the rules above. 887 o Replace the 0xF7 octet that terminates the verbatim SysEx 888 encoding or the last segment of the segmented SysEx encoding 889 with a 0xF5 octet. This substitution informs the receiver 890 of the original dropped 0xF7 coding. 892 [MIDI] reserves the undefined System Common commands 0xF4 and 0xF5 and 893 the undefined System Real-time commands 0xF9 and 0xFD for future use. 894 By default, undefined commands MUST NOT appear in a MIDI Command field 895 in the MIDI list, with the exception of the 0xF5 octets used to code the 896 "dropped 0xF7" construction and the 0xF4 octets used by SysEx "cancel" 897 sublists. 899 During session configuration, a stream may be customized to transport 900 undefined commands (Appendix C.1). For this case, we now define how 901 senders encode undefined commands in the MIDI list. 903 An undefined System Real-time command MUST be coded using the System 904 Real-time rules. 906 If the undefined System Common commands are put to use in a future 907 version of [MIDI], the command will begin with an 0xF4 or 0xF5 status 908 octet, followed by an arbitrary number of data octets (i.e., zero or 909 more data bytes). To encode these commands, senders MUST terminate the 910 command with an 0xF7 octet and place the modified command into the MIDI 911 Command field. 913 Unfortunately, non-compliant uses of the undefined System Common 914 commands may appear in MIDI implementations. To model these commands, 915 we assume that the command begins with an 0xF4 or 0xF5 status octet, 916 followed by zero or more data octets, followed by zero or more trailing 917 0xF7 status octets. To encode the command, senders MUST first remove 918 all trailing 0xF7 status octets from the command. Then, senders MUST 919 terminate the command with an 0xF7 octet and place the modified command 920 into the MIDI Command field. 922 Note that we include the trailing octets in our model as a cautionary 923 measure: if such commands appeared in a non-compliant use of an 924 undefined System Common command, an RTP MIDI encoding of the command 925 that did not remove trailing octets could be mistaken for an encoding of 926 "middle" or "last" sublist of a segmented SysEx commands (Figure 5) 927 under certain packet loss conditions. 929 Original SysEx command: 931 0xF0 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0xF7 933 A two-segment segmentation: 935 0xF0 0x01 0x02 0x03 0x04 0xF0 937 0xF7 0x05 0x06 0x07 0x08 0xF7 939 A different two-segment segmentation: 941 0xF0 0x01 0xF0 943 0xF7 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0xF7 945 A three-segment segmentation: 947 0xF0 0x01 0x02 0xF0 949 0xF7 0x03 0x04 0xF0 951 0xF7 0x05 0x06 0x07 0x08 0xF7 953 The segmentation with the largest number of segments: 955 0xF0 0x01 0xF0 957 0xF7 0x02 0xF0 959 0xF7 0x03 0xF0 961 0xF7 0x04 0xF0 963 0xF7 0x05 0xF0 965 0xF7 0x06 0xF0 967 0xF7 0x07 0xF0 969 0xF7 0x08 0xF0 971 0xF7 0xF7 973 Figure 6 -- Example segmentations 975 4. The Recovery Journal System 977 The recovery journal is the default resiliency tool for unreliable 978 transport. In this section, we normatively define the roles that 979 senders and receivers play in the recovery journal system. 981 MIDI is a fragile code. A single lost command in a MIDI command stream 982 may produce an artifact in the rendered performance. We normatively 983 classify rendering artifacts into two categories: 985 o Transient artifacts. Transient artifacts produce immediate 986 but short-term glitches in the performance. For example, a lost 987 NoteOn (0x9) command produces a transient artifact: one note 988 fails to play, but the artifact does not extend beyond the end 989 of that note. 991 o Indefinite artifacts. Indefinite artifacts produce long-lasting 992 errors in the rendered performance. For example, a lost NoteOff 993 (0x8) command may produce an indefinite artifact: the note that 994 should have been ended by the lost NoteOff command may sustain 995 indefinitely. As a second example, the loss of a Control Change 996 (0xB) command for controller number 7 (Channel Volume) may 997 produce an indefinite artifact: after the loss, all notes on 998 the channel may play too softly or too loudly. 1000 The purpose of the recovery journal system is to satisfy the recovery 1001 journal mandate: the MIDI performance rendered from an RTP MIDI stream 1002 sent over unreliable transport MUST NOT contain indefinite artifacts. 1004 The recovery journal system does not use packet retransmission to 1005 satisfy this mandate. Instead, each packet includes a special section, 1006 called the recovery journal. 1008 The recovery journal codes the history of the stream, back to an earlier 1009 packet called the checkpoint packet. The range of coverage for the 1010 journal is called the checkpoint history. The recovery journal codes 1011 the information necessary to recover from the loss of an arbitrary 1012 number of packets in the checkpoint history. Appendix A.1 normatively 1013 defines the checkpoint packet and the checkpoint history. 1015 When a receiver detects a packet loss, it compares its own knowledge 1016 about the history of the stream with the history information coded in 1017 the recovery journal of the packet that ends the loss event. By noting 1018 the differences in these two versions of the past, a receiver is able to 1019 transform all indefinite artifacts in the rendered performance into 1020 transient artifacts, by executing MIDI commands to repair the stream. 1022 We now state the normative role for senders in the recovery journal 1023 system. 1025 Senders prepare a recovery journal for every packet in the stream. In 1026 doing so, senders choose the checkpoint packet identity for the journal. 1027 Senders make this choice by applying a sending policy. Appendix C.2.2 1028 normatively defines three sending policies: "closed- loop", "open-loop", 1029 and "anchor". 1031 By default, senders MUST use the closed-loop sending policy. If the 1032 session description overrides this default policy, by using the 1033 parameter j_update defined in Appendix C.2.2, senders MUST use the 1034 specified policy. 1036 After choosing the checkpoint packet identity for a packet, the sender 1037 creates the recovery journal. By default, this journal MUST conform to 1038 the normative semantics in Section 5 and Appendices A-B in this memo. 1039 In Appendix C.2.3, we define parameters that modify the normative 1040 semantics for recovery journals. If the session description uses these 1041 parameters, the journal created by the sender MUST conform to the 1042 modified semantics. 1044 Next, we state the normative role for receivers in the recovery journal 1045 system. 1047 A receiver MUST detect each RTP sequence number break in a stream. If 1048 the sequence number break is due to a packet loss event (as defined in 1049 [RFC3550]), the receiver MUST repair all indefinite artifacts in the 1050 rendered MIDI performance caused by the loss. If the sequence number 1051 break is due to an out-of-order packet (as defined in [RFC3550]), the 1052 receiver MUST NOT take actions that introduce indefinite artifacts 1053 (ignoring the out-of-order packet is a safe option). 1055 Receivers take special precautions when entering or exiting a session. 1056 A receiver MUST process the first received packet in a stream as if it 1057 were a packet that ends a loss event. Upon exiting a session, a 1058 receiver MUST ensure that the rendered MIDI performance does not end 1059 with indefinite artifacts. 1061 Receivers are under no obligation to perform indefinite artifact repairs 1062 at the moment a packet arrives. A receiver that uses a playout buffer 1063 may choose to wait until the moment of rendering before processing the 1064 recovery journal, as the "lost" packet may be a late packet that arrives 1065 in time to use. 1067 Next, we state the normative role for the creator of the session 1068 description in the recovery journal system. Depending on the 1069 application, the sender, the receivers, and other parties may take part 1070 in creating or approving the session description. 1072 A session description that specifies the default closed-loop sending 1073 policy and the default recovery journal semantics satisfies the recovery 1074 journal mandate. However, these default behaviors may not be 1075 appropriate for all sessions. If the creators of a session description 1076 use the parameters defined in Appendix C.2 to override these defaults, 1077 the creators MUST ensure that the parameters define a system that 1078 satisfies the recovery journal mandate. 1080 Finally, we note that this memo does not specify sender or receiver 1081 recovery journal algorithms. Implementations are free to use any 1082 algorithm that conforms to the requirements in this section. The non- 1083 normative [RFC4696] discusses sender and receiver algorithm design. 1085 5. Recovery Journal Format 1087 This section introduces the structure of the recovery journal and 1088 defines the bitfields of recovery journal headers. Appendices A-B 1089 complete the bitfield definition of the recovery journal. 1091 The recovery journal has a three-level structure: 1093 o Top-level header. 1095 o Channel and system journal headers. These headers encode 1096 recovery information for a single voice channel (channel 1097 journal) or for all systems commands (system journal). 1099 o Chapters. Chapters describe recovery information for a 1100 single MIDI command type. 1102 Figure 7 shows the top-level structure of the recovery journal. The 1103 recovery journals consists of a 3-octet header, followed by an optional 1104 system journal (labeled S-journal in Figure 7) and an optional list of 1105 channel journals. Figure 8 shows the recovery journal header format. 1107 0 1 2 3 1108 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 1109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1110 | Recovery journal header | S-journal ... | 1111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1112 | Channel journals ... | 1113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1115 Figure 7 -- Top-level recovery journal format 1117 0 1 2 1118 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 1119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1120 |S|Y|A|H|TOTCHAN| Checkpoint Packet Seqnum | 1121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1123 Figure 8 -- Recovery journal header 1125 If the Y header bit is set to 1, the system journal appears in the 1126 recovery journal, directly following the recovery journal header. 1128 If the A header bit is set to 1, the recovery journal ends with a list 1129 of (TOTCHAN + 1) channel journals (the 4-bit TOTCHAN header field is 1130 interpreted as an unsigned integer). 1132 A MIDI channel MAY be represented by (at most) one channel journal in a 1133 recovery journal. Channel journals MUST appear in the recovery journal 1134 in ascending channel-number order. 1136 If A and Y are both zero, the recovery journal only contains its 3- 1137 octet header and is considered to be an "empty" journal. 1139 The S (single-packet loss) bit appears in most recovery journal 1140 structures, including the recovery journal header. The S bit helps 1141 receivers efficiently parse the recovery journal in the common case of 1142 the loss of a single packet. Appendix A.1 defines S bit semantics. 1144 The H bit indicates if MIDI channels in the stream have been configured 1145 to use the enhanced Chapter C encoding (Appendix A.3.3). 1147 By default, the payload format does not use enhanced Chapter C encoding. 1148 In this default case, the H bit MUST be set to 0 for all packets in the 1149 stream. 1151 If the stream has been configured so that controller numbers for one or 1152 more MIDI channels use enhanced Chapter C encoding, the H bit MUST be 1153 set to 1 in all packets in the stream. In Appendix C.2.3, we show how 1154 to configure a stream to use enhanced Chapter C encoding. 1156 The 16-bit Checkpoint Packet Seqnum header field codes the sequence 1157 number of the checkpoint packet for this journal, in network byte order 1158 (big-endian). The choice of the checkpoint packet sets the depth of the 1159 checkpoint history for the journal (defined in Appendix A.1). 1161 Receivers may use the Checkpoint Packet Seqnum field of the packet that 1162 ends a loss event to verify that the journal checkpoint history covers 1163 the entire loss event. The checkpoint history covers the loss event if 1164 the Checkpoint Packet Seqnum field is less than or equal to one plus the 1165 highest RTP sequence number previously received on the stream (modulo 1166 2^16). 1168 0 1 2 3 1169 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 1170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1171 |S| CHAN |H| LENGTH |P|C|M|W|N|E|T|A| Chapters ... | 1172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1174 Figure 9 -- Channel journal format 1176 Figure 9 shows the structure of a channel journal: a 3-octet header, 1177 followed by a list of leaf elements called channel chapters. A channel 1178 journal encodes information about MIDI commands on the MIDI channel 1179 coded by the 4-bit CHAN header field. Note that CHAN uses the same bit 1180 encoding as the channel nibble in MIDI Channel Messages (the cccc field 1181 in Figure E.1 of Appendix E). 1183 The 10-bit LENGTH field codes the length of the channel journal. The 1184 semantics for LENGTH fields are uniform throughout the recovery journal, 1185 and are defined in Appendix A.1. 1187 The third octet of the channel journal header is the Table of Contents 1188 (TOC) of the channel journal. The TOC is a set of bits that encode the 1189 presence of a chapter in the journal. Each chapter contains information 1190 about a certain class of MIDI channel command: 1192 o Chapter P: MIDI Program Change (0xC) 1193 o Chapter C: MIDI Control Change (0xB) 1194 o Chapter M: MIDI Parameter System (part of 0xB) 1195 o Chapter W: MIDI Pitch Wheel (0xE) 1196 o Chapter N: MIDI NoteOff (0x8), NoteOn (0x9) 1197 o Chapter E: MIDI Note Command Extras (0x8, 0x9) 1198 o Chapter T: MIDI Channel Aftertouch (0xD) 1199 o Chapter A: MIDI Poly Aftertouch (0xA) 1201 Chapters appear in a list following the header, in order of their 1202 appearance in the TOC. Appendices A.2-9 describe the bitfield format 1203 for each chapter, and define the conditions under which a chapter type 1204 MUST appear in the recovery journal. If any chapter types are required 1205 for a channel, an associated channel journal MUST appear in the recovery 1206 journal. 1208 The H bit indicates if controller numbers on a MIDI channel have been 1209 configured to use the enhanced Chapter C encoding (Appendix A.3.3). 1211 By default, controller numbers on a MIDI channel do not use enhanced 1212 Chapter C encoding. In this default case, the H bit MUST be set to 0 1213 for all channel journal headers for the channel in the recovery journal, 1214 for all packets in the stream. 1216 However, if at least one controller number for a MIDI channel has been 1217 configured to use the enhanced Chapter C encoding, the H bit for its 1218 channel journal MUST be set to 1, for all packets in the stream. 1220 In Appendix C.2.3, we show how to configure a controller number to use 1221 enhanced Chapter C encoding. 1223 0 1 2 3 1224 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 1225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1226 |S|D|V|Q|F|X| LENGTH | System chapters ... | 1227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1229 Figure 10 -- System journal format 1231 Figure 10 shows the structure of the system journal: a 2-octet header, 1232 followed by a list of system chapters. Each chapter codes information 1233 about a specific class of MIDI Systems command: 1235 o Chapter D: Song Select (0xF3), Tune Request (0xF6), Reset (0xFF), 1236 undefined System commands (0xF4, 0xF5, 0xF9, 0xFD) 1237 o Chapter V: Active Sense (0xFE) 1238 o Chapter Q: Sequencer State (0xF2, 0xF8, 0xF9, 0xFA, 0xFB, 0xFC) 1239 o Chapter F: MTC Tape Position (0xF1, 0xF0 0x7F 0xcc 0x01 0x01) 1240 o Chapter X: System Exclusive (all other 0xF0) 1242 The 10-bit LENGTH field codes the size of the system journal and 1243 conforms to semantics described in Appendix A.1. 1245 The D, V, Q, F, and X header bits form a Table of Contents (TOC) for the 1246 system journal. A TOC bit that is set to 1 codes the presence of a 1247 chapter in the journal. Chapters appear in a list following the header, 1248 in the order of their appearance in the TOC. 1250 Appendix B describes the bitfield format for the system chapters and 1251 defines the conditions under which a chapter type MUST appear in the 1252 recovery journal. If any system chapter type is required to appear in 1253 the recovery journal, the system journal MUST appear in the recovery 1254 journal. 1256 6. Session Description Protocol 1258 RTP does not perform session management. Instead, RTP works together 1259 with session management tools, such as the Session Initiation Protocol 1260 (SIP, [RFC3261]) and the Real Time Streaming Protocol (RTSP, [RFC2326]). 1262 RTP payload formats define media type parameters for use in session 1263 management (for example, this memo defines "rtp-midi" as the media type 1264 for native RTP MIDI streams). 1266 In most cases, session management tools use the media type parameters 1267 via another standard, the Session Description Protocol (SDP, [RFC4566]). 1269 SDP is a textual format for specifying session descriptions. Session 1270 descriptions specify the network transport and media encoding for RTP 1271 sessions. Session management tools coordinate the exchange of session 1272 descriptions between participants ("parties"). 1274 Some session management tools use SDP to negotiate details of media 1275 transport (network addresses, ports, etc.). We refer to this use of SDP 1276 as "negotiated usage". One example of negotiated usage is the 1277 Offer/Answer protocol ([RFC3264] and Appendix C.7.2 in this memo) as 1278 used by SIP. 1280 Other session management tools use SDP to declare the media encoding for 1281 the session but use other techniques to negotiate network transport. We 1282 refer to this use of SDP as "declarative usage". One example of 1283 declarative usage is RTSP ([RFC2326] and Appendix C.7.1 in this memo). 1285 Below, we show session description examples for native (Section 6.1) and 1286 mpeg4-generic (Section 6.2) streams. In Section 6.3, we introduce 1287 session configuration tools that may be used to customize streams. 1289 6.1. Session Descriptions for Native Streams 1291 The session description below defines a unicast UDP RTP session (via a 1292 media ("m=") line) whose sole payload type (96) is mapped to a minimal 1293 native RTP MIDI stream. 1295 v=0 1296 o=lazzaro 2520644554 2838152170 IN IP4 first.example.net 1297 s=Example 1298 t=0 0 1299 m=audio 5004 RTP/AVP 96 1300 c=IN IP4 192.0.2.94 1301 a=rtpmap:96 rtp-midi/44100 1303 The rtpmap attribute line uses the "rtp-midi" media type to specify an 1304 RTP MIDI native stream. The clock rate specified on the rtpmap line (in 1305 the example above, 44100 Hz) sets the scaling for the RTP timestamp 1306 header field (see Section 2.1, and also [RFC3550]). 1308 Note that this document does not specify a default clock rate value for 1309 RTP MIDI. When RTP MIDI is used with SDP, parties MUST use the rtpmap 1310 line to communicate the clock rate. Guidance for selecting the RTP MIDI 1311 clock rate value appears in Section 2.1. 1313 We consider the RTP MIDI stream shown above to be "minimal" because the 1314 session description does not customize the stream with parameters. 1315 Without such customization, a native RTP MIDI stream has these 1316 characteristics: 1318 1. If the stream uses unreliable transport (unicast UDP, multicast 1319 UDP, etc.), the recovery journal system is in use, and the RTP 1320 payload contains both the MIDI command section and the journal 1321 section. If the stream uses reliable transport (such as TCP), 1322 the stream does not use journalling, and the payload contains 1323 only the MIDI command section (Section 2.2). 1325 2. If the stream uses the recovery journal system, the recovery 1326 journal system uses the default sending policy and the default 1327 journal semantics (Section 4). 1329 3. In the MIDI command section of the payload, command timestamps 1330 use the default "comex" semantics (Section 3). 1332 4. The recommended temporal duration ("media time") of an RTP 1333 packet ranges from 0 to 200 ms, and the RTP timestamp 1334 difference between sequential packets in the stream may be 1335 arbitrarily large (Section 2.1). 1337 5. If more than one minimal rtp-midi stream appears in a session, 1338 the MIDI name spaces for these streams are independent: channel 1339 1 in the first stream does not reference the same MIDI channel 1340 as channel 1 in the second stream (see Appendix C.5 for a 1341 discussion of the independence of minimal rtp-midi streams). 1343 6. The rendering method for the stream is not specified. What the 1344 receiver "does" with a minimal native MIDI stream is "out of 1345 scope" of this memo. For example, in content creation 1346 environments, a user may manually configure client software to 1347 render the stream with a specific software package. 1349 As in standard in RTP, RTP sessions managed by SIP are sendrecv by 1350 default (parties send and receive MIDI), and RTP sessions managed by 1351 RTSP are recvonly by default (server sends and client receives). 1353 In sendrecv RTP MIDI sessions for the session description shown above, 1354 the 16 voice channel + systems MIDI name space is unique for each 1355 sender. Thus, in a two-party session, the voice channel 0 sent by one 1356 party is distinct from the voice channel 0 sent by the other party. 1358 This behavior corresponds to what occurs when two MIDI 1.0 DIN devices 1359 are cross-connected with two MIDI cables (one cable routing MIDI Out 1360 from the first device into MIDI In of the second device, a second cable 1361 routing MIDI In from the first device into MIDI Out of the second 1362 device). We define this "association" formally in Section 2.1. 1364 MIDI 1.0 DIN networks may be configured in a "party-line" multicast 1365 topology. For these networks, the MIDI protocol itself provides tools 1366 for addressing specific devices in transactions on a multicast network, 1367 and for device discovery. Thus, apart from providing a 1- to-many 1368 forward path and a many-to-1 reverse path, IETF protocols do not need to 1369 provide any special support for MIDI multicast networking. 1371 6.2. Session Descriptions for mpeg4-generic Streams 1373 An mpeg4-generic [RFC3640] RTP MIDI stream uses an MPEG 4 Audio Object 1374 Type to render MIDI into audio. Three Audio Object Types accept MIDI 1375 input: 1377 o General MIDI (Audio Object Type ID 15), based on the General 1378 MIDI rendering standard [MIDI]. 1380 o Wavetable Synthesis (Audio Object Type ID 14), based on the 1381 Downloadable Sounds Level 2 (DLS 2) rendering standard [DLS2]. 1383 o Main Synthetic (Audio Object Type ID 13), based on Structured 1384 Audio and the programming language SAOL [MPEGSA]. 1386 The primary service of an mpeg4-generic stream is to code Access Units 1387 (AUs). We define the mpeg4-generic RTP MIDI AU as the MIDI payload 1388 shown in Figure 1 of Section 2.1 of this memo: a MIDI command section 1389 optionally followed by a journal section. 1391 Exactly one RTP MIDI AU MUST be mapped to one mpeg4-generic RTP MIDI 1392 packet. The mpeg4-generic options for placing several AUs in an RTP 1393 packet MUST NOT be used with RTP MIDI. The mpeg4-generic options for 1394 fragmenting and interleaving AUs MUST NOT be used with RTP MIDI. The 1395 mpeg4-generic RTP packet payload (Figure 1 in [RFC3640]) MUST contain 1396 empty AU Header and Auxiliary sections. These rules yield mpeg4-generic 1397 packets that are structurally identical to native RTP MIDI packets, an 1398 essential property for the correct operation of the payload format. 1400 The session description that follows defines a unicast UDP RTP session 1401 (via a media ("m=") line) whose sole payload type (96) is mapped to a 1402 minimal mpeg4-generic RTP MIDI stream. This example uses the General 1403 MIDI Audio Object Type under Synthesis Profile @ Level 2. 1405 v=0 1406 o=lazzaro 2520644554 2838152170 IN IP6 first.example.net 1407 s=Example 1408 t=0 0 1409 m=audio 5004 RTP/AVP 96 1410 c=IN IP6 2001:DB8::7F2E:172A:1E24 1411 a=rtpmap:96 mpeg4-generic/44100 1412 a=fmtp:96 streamtype=5; mode=rtp-midi; profile-level-id=12; 1413 config=7A0A0000001A4D546864000000060000000100604D54726B0000 1414 000600FF2F000 1416 (The a=fmtp line has been wrapped to fit the page to accommodate memo 1417 formatting restrictions; it comprises a single line in SDP.) 1419 The fmtp attribute line codes the four parameters (streamtype, mode, 1420 profile-level-id, and config) that are required in all mpeg4-generic 1421 session descriptions [RFC3640]. For RTP MIDI streams, the streamtype 1422 parameter MUST be set to 5, the "mode" parameter MUST be set to "rtp- 1423 midi", and the "profile-level-id" parameter MUST be set to the MPEG-4 1424 Profile Level for the stream. For the Synthesis Profile, legal profile- 1425 level-id values are 11, 12, and 13, coding low (11), medium (12), or 1426 high (13) decoder computational complexity, as defined by MPEG 1427 conformance tests. 1429 In a minimal RTP MIDI session description, the config value MUST be a 1430 hexadecimal encoding [RFC3640] of the AudioSpecificConfig data block 1431 [MPEGAUDIO] for the stream. AudioSpecificConfig encodes the Audio 1432 Object Type for the stream and also encodes initialization data (SAOL 1433 programs, DLS 2 wave tables, etc.). Standard MIDI Files encoded in 1434 AudioSpecificConfig in a minimal session description MUST be ignored by 1435 the receiver. 1437 Receivers determine the rendering algorithm for the session by 1438 interpreting the first 5 bits of AudioSpecificConfig as an unsigned 1439 integer that codes the Audio Object Type. In our example above, the 1440 leading config string nibbles "7A" yield the Audio Object Type 15 1441 (General MIDI). In Appendix E.4, we derive the config string value in 1442 the session description shown above; the starting point of the 1443 derivation is the MPEG bitstreams defined in [MPEGSA] and [MPEGAUDIO]. 1445 We consider the stream to be "minimal" because the session description 1446 does not customize the stream through the use of parameters, other than 1447 the 4 required mpeg4-generic parameters described above. In Section 1448 6.1, we describe the behavior of a minimal native stream, as a numbered 1449 list of characteristics. Items 1-4 on that list also describe the 1450 minimal mpeg4-generic stream, but items 5 and 6 require restatements, as 1451 listed below: 1453 5. If more than one minimal mpeg4-generic stream appears in 1454 a session, each stream uses an independent instance of the 1455 Audio Object Type coded in the config parameter value. 1457 6. A minimal mpeg4-generic stream encodes the AudioSpecificConfig 1458 as an inline hexadecimal constant. If a session description 1459 is sent over UDP, it may be impossible to transport large 1460 AudioSpecificConfig blocks within the Maximum Transmission Size 1461 (MTU) of the underlying network (for Ethernet, the MTU is 1500 1462 octets). In some cases, the AudioSpecificConfig block may 1463 exceed the maximum size of the UDP packet itself. 1465 The comments in Section 6.1 on SIP and RTSP stream directional defaults, 1466 sendrecv MIDI channel usage, and MIDI 1.0 DIN multicast networks also 1467 apply to mpeg4-generic RTP MIDI sessions. 1469 In sendrecv sessions, each party's session description MUST use 1470 identical values for the mpeg4-generic parameters (including the 1471 required streamtype, mode, profile-level-id, and config parameters). As 1472 a consequence, each party uses an identically configured MPEG 4 Audio 1473 Object Type to render MIDI commands into audio. The preamble to 1474 Appendix C discusses a way to create "virtual sendrecv" sessions that do 1475 not have this restriction. 1477 6.3. Parameters 1479 This section introduces parameters for session configuration for RTP 1480 MIDI streams. In session descriptions, parameters modify the semantics 1481 of a payload type. Parameters are specified on an fmtp attribute line. 1482 See the session description example in Section 6.2 for an example of a 1483 fmtp attribute line. 1485 The parameters add features to the minimal streams described in Sections 1486 6.1-2, and support several types of services: 1488 o Stream subsetting. By default, all MIDI commands that 1489 are legal to appear on a MIDI 1.0 DIN cable may appear 1490 in an RTP MIDI stream. The cm_unused parameter overrides 1491 this default by prohibiting certain commands from appearing 1492 in the stream. The cm_used parameter is used in conjunction 1493 with cm_unused, to simplify the specification of complex 1494 exclusion rules. We describe cm_unused and cm_used in 1495 Appendix C.1. 1497 o Journal customization. The j_sec and j_update parameters 1498 configure the use of the journal section. The ch_default, 1499 ch_never, and ch_anchor parameters configure the semantics 1500 of the recovery journal chapters. These parameters are 1501 described in Appendix C.2 and override the default stream 1502 behaviors 1 and 2, listed in Section 6.1 and referenced in 1503 Section 6.2. 1505 o MIDI command timestamp semantics. The tsmode, octpos, 1506 mperiod, and linerate parameters customize the semantics 1507 of timestamps in the MIDI command section. These parameters 1508 let RTP MIDI accurately encode the implicit time coding of 1509 MIDI 1.0 DIN cables. These parameters are described in 1510 Appendix C.3 and override default stream behavior 3, 1511 listed in Section 6.1 and referenced in Section 6.2 1513 o Media time. The rtp_ptime and rtp_maxptime parameters define 1514 the temporal duration ("media time") of an RTP MIDI packet. 1515 The guardtime parameter sets the minimum sending rate of stream 1516 packets. These parameters are described in Appendix C.4 1517 and override default stream behavior 4, listed in Section 6.1 1518 and referenced in Section 6.2. 1520 o Stream description. The musicport parameter labels the 1521 MIDI name space of RTP streams in a multimedia session. 1522 Musicport is described in Appendix C.5. The musicport 1523 parameter overrides default stream behavior 5, in Sections 1524 6.1 and 6.2. 1526 o MIDI rendering. Several parameters specify the MIDI 1527 rendering method of a stream. These parameters are described 1528 in Appendix C.6 and override default stream behavior 6, in 1529 Sections 6.1 and 6.2. 1531 In Appendix C.7, we specify interoperability guidelines for two RTP MIDI 1532 application areas: content-streaming using RTSP (Appendix C.7.1) and 1533 network musical performance using SIP (Appendix C.7.2). 1535 7. Extensibility 1537 The payload format defined in this memo exclusively encodes all commands 1538 that may legally appear on a MIDI 1.0 DIN cable. 1540 Many worthy uses of MIDI over RTP do not fall within the narrow scope of 1541 the payload format. For example, the payload format does not support 1542 the direct transport of Standard MIDI File (SMF) meta-event and metric 1543 timing data. As a second example, the payload format does not define 1544 transport tools for user-defined commands (apart from tools to support 1545 System Exclusive commands [MIDI]). 1547 The payload format does not provide an extension mechanism to support 1548 new features of this nature, by design. Instead, we encourage the 1549 development of new payload formats for specialized musical applications. 1550 The IETF session management tools [RFC3264] [RFC2326] support codec 1551 negotiation, to facilitate the use of new payload formats in a backward- 1552 compatible way. 1554 However, the payload format does provide several extensibility tools, 1555 which we list below: 1557 o Journalling. As described in Appendix C.2, new token 1558 values for the j_sec and j_update parameters may 1559 be defined in IETF standards-track documents. This 1560 mechanism supports the design of new journal formats 1561 and the definition of new journal sending policies. 1563 o Rendering. The payload format may be extended to support 1564 new MIDI renderers (Appendix C.6.2). Certain general aspects 1565 of the RTP MIDI rendering process may also be extended, via 1566 the definition of new token values for the render (Appendix C.6) 1567 and smf_info (Appendix C.6.4.1) parameters. 1569 o Undefined commands. [MIDI] reserves 4 MIDI System commands 1570 for future use (0xF4, 0xF5, 0xF9, 0xFD). If updates 1571 to [MIDI] define the reserved commands, IETF standards-track 1572 documents may be defined to provide resiliency support for 1573 the commands. Opaque LEGAL fields appear in System Chapter 1574 D for this purpose (Appendix B.1.1). 1576 A final form of extensibility involves the inclusion of the payload 1577 format in framework documents. Framework documents describe how to 1578 combine protocols to form a platform for interoperable applications. 1579 For example, a stage and studio framework might define how to use SIP 1580 [RFC3261], RTSP [RFC2326], SDP [RFC4566], and RTP [RFC3550] to support 1581 media networking for professional audio equipment and electronic musical 1582 instruments. 1584 8. Congestion Control 1586 The RTP congestion control requirements defined in [RFC3550] apply to 1587 RTP MIDI sessions, and implementors should carefully read the congestion 1588 control section in [RFC3550]. As noted in [RFC3550], all transport 1589 protocols used on the Internet need to address congestion control in 1590 some way, and RTP is not an exception. 1592 In addition, the congestion control requirements defined in [RFC3551] 1593 applies to RTP MIDI sessions run under applicable profiles. The basic 1594 congestion control requirement defined in [RFC3551] is that RTP sessions 1595 that use UDP transport should monitor packet loss (via RTCP or other 1596 means) to ensure that the RTP stream competes fairly with TCP flows that 1597 share the network. 1599 Finally, RTP MIDI has congestion control issues that are unique for an 1600 audio RTP payload format. In applications such as network musical 1601 performance [NMP], the packet rate is linked to the gestural rate of a 1602 human performer. Senders MUST monitor the MIDI command source for 1603 patterns that result in excessive packet rates and take actions during 1604 RTP transcoding to reduce the RTP packet rate. [RFC4696] offers 1605 implementation guidance on this issue. 1607 9. Security Considerations 1609 Implementors should carefully read the Security Considerations sections 1610 of the RTP [RFC3550], AVP [RFC3551], and other RTP profile documents, as 1611 the issues discussed in these sections directly apply to RTP MIDI 1612 streams. Implementors should also review the Secure Real-time Transport 1613 Protocol (SRTP, [RFC3711]), an RTP profile that addresses the security 1614 issues discussed in [RFC3550] and [RFC3551]. 1616 Here, we discuss security issues that are unique to the RTP MIDI payload 1617 format. 1619 When using RTP MIDI, authentication of incoming RTP and RTCP packets is 1620 RECOMMENDED. Per-packet authentication may be provided by SRTP or by 1621 other means. Without the use of authentication, attackers could forge 1622 MIDI commands into an ongoing stream, damaging speakers and eardrums. 1623 An attacker could also craft RTP and RTCP packets to exploit known bugs 1624 in the client and take effective control of a client machine. 1626 Session management tools (such as SIP [RFC3261]) SHOULD use 1627 authentication during the transport of all session descriptions 1628 containing RTP MIDI media streams. For SIP, the Security Considerations 1629 section in [RFC3261] provides an overview of possible authentication 1630 mechanisms. RTP MIDI session descriptions should use authentication 1631 because the session descriptions may code initialization data using the 1632 parameters described in Appendix C. If an attacker inserts bogus 1633 initialization data into a session description, he can corrupt the 1634 session or forge an client attack. 1636 Session descriptions may also code renderer initialization data by 1637 reference, via the url (Appendix C.6.3) and smf_url (Appendix C.6.4.2) 1638 parameters. If the coded URL is spoofed, both session and client are 1639 open to attack, even if the session description itself is authenticated. 1640 Therefore, URLs specified in url and smf_url parameters SHOULD use 1641 [RFC2818]. 1643 Section 2.1 allows streams sent by a party in two RTP sessions to have 1644 the same SSRC value and the same RTP timestamp initialization value, 1645 under certain circumstances. Normally, these values are randomly chosen 1646 for each stream in a session, to make plaintext guessing harder to do if 1647 the payloads are encrypted. Thus, Section 2.1 weakens this aspect of 1648 RTP security. 1650 10. Acknowledgements 1652 We thank the networking, media compression, and computer music community 1653 members who have commented or contributed to the effort, including Kurt 1654 B, Cynthia Bruyns, Steve Casner, Paul Davis, Robin Davies, Joanne Dow, 1655 Tobias Erichsen, Roni Even, Nicolas Falquet, Adrian Farrel, Dominique 1656 Fober, Philippe Gentric, Michael Godfrey, Chris Grigg, Todd Hager, 1657 Alfred Hoenes, Russ Housley, Michel Jullian, Phil Kerr, Young-Kwon Lim, 1658 Jessica Little, Jan van der Meer, Alexey Melnikov, Colin Perkins, 1659 Charlie Richmond, Herbie Robinson, Dan Romascanu, Larry Rowe, Eric 1660 Scheirer, Dave Singer, Martijn Sipkema, Robert Sparks, William Stewart, 1661 Kent Terry, Sean Turner, Magnus Westerlund, Tom White, Jim Wright, Doug 1662 Wyatt, and Giorgio Zoia. We also thank the members of the San Francisco 1663 Bay Area music and audio community for creating the context for the 1664 work, including Don Buchla, Chris Chafe, Richard Duda, Dan Ellis, Adrian 1665 Freed, Ben Gold, Jaron Lanier, Roger Linn, Richard Lyon, Dana Massie, 1666 Max Mathews, Keith McMillen, Carver Mead, Nelson Morgan, Tom Oberheim, 1667 Malcolm Slaney, Dave Smith, Julius Smith, David Wessel, and Matt Wright. 1669 11. IANA Considerations 1671 The bulk of this section is a verbatim reproduction of the IANA 1672 considerations which appear in Section 11 of [RFC4695]. Preceding this 1673 reproduction, we list several issues concerning this memo which are 1674 related to the IANA considerations, as follows: 1676 o All existing IANA references to [RFC4695] should be deleted, 1677 and replaced with references to this memo. In addition, a 1678 reference to this memo should be added to audio/mpeg4-generic 1679 MIME type registration. 1681 o In Section 11.3, a sentence has been added to the Encoding 1682 Considerations asc Media Type Registration: "Disk files that 1683 store this data object use the file extension ".acn"". 1685 The reproduction of the [RFC4695] IANA considerations section appears 1686 directly below. 1688 This section makes a series of requests to IANA. The IANA has completed 1689 registration/assignments of the below requests. 1691 The sub-sections that follow hold the actual, detailed requests. All 1692 registrations in this section are in the IETF tree and follow the rules 1693 of [RFC4288] and [RFC4855], as appropriate. 1695 In Section 11.1, we request the registration of a new media type: 1697 "audio/rtp-midi". Paired with this request is a request for a 1698 repository for new values for several parameters associated with 1699 "audio/rtp-midi". We request this repository in Section 11.1.1. 1701 In Section 11.2, we request the registration of a new value ("rtp- 1702 midi") for the "mode" parameter of the "mpeg4-generic" media type. The 1703 "mpeg4-generic" media type is defined in [RFC3640], and [RFC3640] 1704 defines a repository for the "mode" parameter. However, we believe we 1705 are the first to request the registration of a "mode" value, so we 1706 believe the registry for "mode" has not yet been created by IANA. 1708 Paired with our "mode" parameter value request for "mpeg4-generic" is a 1709 request for a repository for new values for several parameters we have 1710 defined for use with the "rtp-midi" mode value. We request this 1711 repository in Section 11.2.1. 1713 In Section 11.3, we request the registration of a new media type: 1714 "audio/asc". No repository request is associated with this request. 1716 11.1. rtp-midi Media Type Registration 1718 This section requests the registration of the "rtp-midi" subtype for the 1719 "audio" media type. We request the registration of the parameters 1720 listed in the "optional parameters" section below (both the "non- 1721 extensible parameters" and the "extensible parameters" lists). We also 1722 request the creation of repositories for the "extensible parameters"; 1723 the details of this request appear in Section 11.1.1, below. 1725 Media type name: 1727 audio 1729 Subtype name: 1731 rtp-midi 1733 Required parameters: 1735 rate: The RTP timestamp clock rate. See Sections 2.1 and 6.1 1736 for usage details. 1738 Optional parameters: 1740 Non-extensible parameters: 1742 ch_anchor: See Appendix C.2.3 for usage details. 1743 ch_default: See Appendix C.2.3 for usage details. 1744 ch_never: See Appendix C.2.3 for usage details. 1745 cm_unused: See Appendix C.1 for usage details. 1746 cm_used: See Appendix C.1 for usage details. 1747 chanmask: See Appendix C.6.4.3 for usage details. 1748 cid: See Appendix C.6.3 for usage details. 1749 guardtime: See Appendix C.4.2 for usage details. 1750 inline: See Appendix C.6.3 for usage details. 1751 linerate: See Appendix C.3 for usage details. 1752 mperiod: See Appendix C.3 for usage details. 1753 multimode: See Appendix C.6.1 for usage details. 1754 musicport: See Appendix C.5 for usage details. 1755 octpos: See Appendix C.3 for usage details. 1756 rinit: See Appendix C.6.3 for usage details. 1757 rtp_maxptime: See Appendix C.4.1 for usage details. 1758 rtp_ptime: See Appendix C.4.1 for usage details. 1759 smf_cid: See Appendix C.6.4.2 for usage details. 1760 smf_inline: See Appendix C.6.4.2 for usage details. 1761 smf_url: See Appendix C.6.4.2 for usage details. 1762 tsmode: See Appendix C.3 for usage details. 1763 url: See Appendix C.6.3 for usage details. 1765 Extensible parameters: 1767 j_sec: See Appendix C.2.1 for usage details. See 1768 Section 11.1.1 for repository details. 1769 j_update: See Appendix C.2.2 for usage details. See 1770 Section 11.1.1 for repository details. 1771 render: See Appendix C.6 for usage details. See 1772 Section 11.1.1 for repository details. 1773 subrender: See Appendix C.6.2 for usage details. See 1774 Section 11.1.1 for repository details. 1775 smf_info: See Appendix C.6.4.1 for usage details. See 1776 Section 11.1.1 for repository details. 1778 Encoding considerations: 1780 The format for this type is framed and binary. 1782 Restrictions on usage: 1784 This type is only defined for real-time transfers of MIDI 1785 streams via RTP. Stored-file semantics for rtp-midi may 1786 be defined in the future. 1788 Security considerations: 1790 See Section 9 of this memo. 1792 Interoperability considerations: 1794 None. 1796 Published specification: 1798 This memo and [MIDI] serve as the normative specification. In 1799 addition, references [NMP], [GRAME], and [RFC4696] provide 1800 non-normative implementation guidance. 1802 Applications that use this media type: 1804 Audio content-creation hardware, such as MIDI controller piano 1805 keyboards and MIDI audio synthesizers. Audio content-creation 1806 software, such as music sequencers, digital audio workstations, 1807 and soft synthesizers. Computer operating systems, for network 1808 support of MIDI Application Programmer Interfaces. Content 1809 distribution servers and terminals may use this media type for 1810 low bit-rate music coding. 1812 Additional information: 1814 None. 1816 Person & email address to contact for further information: 1818 John Lazzaro 1820 Intended usage: 1822 COMMON. 1824 Author: 1826 John Lazzaro 1828 Change controller: 1830 IETF Audio/Video Transport Working Group delegated 1831 from the IESG. 1833 11.1.1. Repository Request for "audio/rtp-midi" 1835 For the "rtp-midi" subtype, we request the creation of repositories for 1836 extensions to the following parameters (which are those listed as 1837 "extensible parameters" in Section 11.1). 1839 j_sec: 1841 Registrations for this repository may only occur 1842 via an IETF standards-track document. Appendix C.2.1 1843 of this memo describes appropriate registrations for this 1844 repository. 1846 Initial values for this repository appear below: 1848 "none": Defined in Appendix C.2.1 of this memo. 1849 "recj": Defined in Appendix C.2.1 of this memo. 1851 j_update: 1853 Registrations for this repository may only occur 1854 via an IETF standards-track document. Appendix C.2.2 1855 of this memo describes appropriate registrations for this 1856 repository. 1858 Initial values for this repository appear below: 1860 "anchor": Defined in Appendix C.2.2 of this memo. 1861 "open-loop": Defined in Appendix C.2.2 of this memo. 1862 "closed-loop": Defined in Appendix C.2.2 of this memo. 1864 render: 1866 Registrations for this repository MUST include a 1867 specification of the usage of the proposed value. 1868 See text in the preamble of Appendix C.6 for details 1869 (the paragraph that begins "Other render token ..."). 1871 Initial values for this repository appear below: 1873 "unknown": Defined in Appendix C.6 of this memo. 1874 "synthetic": Defined in Appendix C.6 of this memo. 1875 "api": Defined in Appendix C.6 of this memo. 1876 "null": Defined in Appendix C.6 of this memo. 1878 subrender: 1880 Registrations for this repository MUST include a 1881 specification of the usage of the proposed value. 1882 See text Appendix C.6.2 for details (the paragraph 1883 that begins "Other subrender token ..."). 1885 Initial values for this repository appear below: 1887 "default": Defined in Appendix C.6.2 of this memo. 1889 smf_info: 1891 Registrations for this repository MUST include a 1892 specification of the usage of the proposed value. 1893 See text in Appendix C.6.4.1 for details (the 1894 paragraph that begins "Other smf_info token ..."). 1896 Initial values for this repository appear below: 1898 "ignore": Defined in Appendix C.6.4.1 of this memo. 1899 "sdp_start": Defined in Appendix C.6.4.1 of this memo. 1900 "identity": Defined in Appendix C.6.4.1 of this memo. 1902 11.2. mpeg4-generic Media Type Registration 1904 This section requests the registration of the "rtp-midi" value for the 1905 "mode" parameter of the "mpeg4-generic" media type. The "mpeg4- 1906 generic" media type is defined in [RFC3640], and [RFC3640] defines a 1907 repository for the "mode" parameter. We are registering mode rtp- midi 1908 to support the MPEG Audio codecs [MPEGSA] that use MIDI. 1910 In conjunction with this registration request, we request the 1911 registration of the parameters listed in the "optional parameters" 1912 section below (both the "non-extensible parameters" and the "extensible 1913 parameters" lists). We also request the creation of repositories for 1914 the "extensible parameters"; the details of this request appear in 1915 Appendix 11.2.1, below. 1917 Media type name: 1919 audio 1921 Subtype name: 1923 mpeg4-generic 1925 Required parameters: 1927 The "mode" parameter is required by [RFC3640]. [RFC3640] requests 1928 a repository for "mode", so that new values for mode 1929 may be added. We request that the value "rtp-midi" be 1930 added to the "mode" repository. 1932 In mode rtp-midi, the mpeg4-generic parameter rate is 1933 a required parameter. Rate specifies the RTP timestamp 1934 clock rate. See Sections 2.1 and 6.2 for usage details 1935 of rate in mode rtp-midi. 1937 Optional parameters: 1939 We request registration of the following parameters 1940 for use in mode rtp-midi for mpeg4-generic. 1942 Non-extensible parameters: 1944 ch_anchor: See Appendix C.2.3 for usage details. 1945 ch_default: See Appendix C.2.3 for usage details. 1946 ch_never: See Appendix C.2.3 for usage details. 1947 cm_unused: See Appendix C.1 for usage details. 1948 cm_used: See Appendix C.1 for usage details. 1949 chanmask: See Appendix C.6.4.3 for usage details. 1950 cid: See Appendix C.6.3 for usage details. 1951 guardtime: See Appendix C.4.2 for usage details. 1952 inline: See Appendix C.6.3 for usage details. 1953 linerate: See Appendix C.3 for usage details. 1954 mperiod: See Appendix C.3 for usage details. 1955 multimode: See Appendix C.6.1 for usage details. 1956 musicport: See Appendix C.5 for usage details. 1957 octpos: See Appendix C.3 for usage details. 1958 rinit: See Appendix C.6.3 for usage details. 1959 rtp_maxptime: See Appendix C.4.1 for usage details. 1960 rtp_ptime: See Appendix C.4.1 for usage details. 1961 smf_cid: See Appendix C.6.4.2 for usage details. 1962 smf_inline: See Appendix C.6.4.2 for usage details. 1964 smf_url: See Appendix C.6.4.2 for usage details. 1965 tsmode: See Appendix C.3 for usage details. 1966 url: See Appendix C.6.3 for usage details. 1968 Extensible parameters: 1970 j_sec: See Appendix C.2.1 for usage details. See 1971 Section 11.2.1 for repository details. 1972 j_update: See Appendix C.2.2 for usage details. See 1973 Section 11.2.1 for repository details. 1974 render: See Appendix C.6 for usage details. See 1975 Section 11.2.1 for repository details. 1976 subrender: See Appendix C.6.2 for usage details. See 1977 Section 11.2.1 for repository details. 1978 smf_info: See Appendix C.6.4.1 for usage details. See 1979 Section 11.2.1 for repository details. 1981 Encoding considerations: 1983 The format for this type is framed and binary. 1985 Restrictions on usage: 1987 Only defined for real-time transfers of audio/mpeg4-generic 1988 RTP streams with mode=rtp-midi. 1990 Security considerations: 1992 See Section 9 of this memo. 1994 Interoperability considerations: 1996 Except for the marker bit (Section 2.1), the packet formats 1997 for audio/rtp-midi and audio/mpeg4-generic (mode rtp-midi) 1998 are identical. The formats differ in use: audio/mpeg4-generic 1999 is for MPEG work, and audio/rtp-midi is for all other work. 2001 Published specification: 2003 This memo, [MIDI], and [MPEGSA] are the normative references. 2004 In addition, references [NMP], [GRAME], and [RFC4696] provide 2005 non-normative implementation guidance. 2007 Applications that use this media type: 2009 MPEG 4 servers and terminals that support [MPEGSA]. 2011 Additional information: 2013 None. 2015 Person & email address to contact for further information: 2017 John Lazzaro 2019 Intended usage: 2021 COMMON. 2023 Author: 2025 John Lazzaro 2027 Change controller: 2029 IETF Audio/Video Transport Working Group delegated 2030 from the IESG. 2032 11.2.1. Repository Request for Mode rtp-midi for mpeg4-generic 2034 For mode rtp-midi of the mpeg4-generic subtype, we request the creation 2035 of repositories for extensions to the following parameters (which are 2036 those listed as "extensible parameters" in Section 11.2). 2038 j_sec: 2040 Registrations for this repository may only occur 2041 via an IETF standards-track document. Appendix C.2.1 2042 of this memo describes appropriate registrations for this 2043 repository. 2045 Initial values for this repository appear below: 2047 "none": Defined in Appendix C.2.1 of this memo. 2049 "recj": Defined in Appendix C.2.1 of this memo. 2051 j_update: 2053 Registrations for this repository may only occur 2054 via an IETF standards-track document. Appendix C.2.2 2055 of this memo describes appropriate registrations for this 2056 repository. 2058 Initial values for this repository appear below: 2060 "anchor": Defined in Appendix C.2.2 of this memo. 2061 "open-loop": Defined in Appendix C.2.2 of this memo. 2062 "closed-loop": Defined in Appendix C.2.2 of this memo. 2064 render: 2066 Registrations for this repository MUST include a 2067 specification of the usage of the proposed value. 2068 See text in the preamble of Appendix C.6 for details 2069 (the paragraph that begins "Other render token ..."). 2071 Initial values for this repository appear below: 2073 "unknown": Defined in Appendix C.6 of this memo. 2074 "synthetic": Defined in Appendix C.6 of this memo. 2075 "null": Defined in Appendix C.6 of this memo. 2077 subrender: 2079 Registrations for this repository MUST include a 2080 specification of the usage of the proposed value. 2081 See text in Appendix C.6.2 for details (the paragraph 2082 that begins "Other subrender token ..." and 2083 subsequent paragraphs). Note that the text in 2084 Appendix C.6.2 contains restrictions on subrender 2085 registrations for mpeg4-generic ("Registrations 2086 for mpeg4-generic subrender values ..."). 2088 Initial values for this repository appear below: 2090 "default": Defined in Appendix C.6.2 of this memo. 2092 smf_info: 2094 Registrations for this repository MUST include a 2095 specification of the usage of the proposed value. 2096 See text in Appendix C.6.4.1 for details (the 2097 paragraph that begins "Other smf_info token ..."). 2099 Initial values for this repository appear below: 2101 "ignore": Defined in Appendix C.6.4.1 of this memo. 2102 "sdp_start": Defined in Appendix C.6.4.1 of this memo. 2103 "identity": Defined in Appendix C.6.4.1 of this memo. 2105 11.3. asc Media Type Registration 2107 This section registers "asc" as a subtype for the "audio" media type. 2108 We register this subtype to support the remote transfer of the "config" 2109 parameter of the mpeg4-generic media type [RFC3640] when it is used with 2110 mpeg4-generic mode rtp-midi (registered in Appendix 11.2 above). We 2111 explain the mechanics of using "audio/asc" to set the config parameter 2112 in Section 6.2 and Appendix C.6.5 of this document. 2114 Note that this registration is a new subtype registration and is not an 2115 addition to a repository defined by MPEG-related memos (such as 2116 [RFC3640]). Also note that this request for "audio/asc" does not 2117 register parameters, and does not request the creation of a repository. 2119 Media type name: 2121 audio 2123 Subtype name: 2125 asc 2127 Required parameters: 2129 None. 2131 Optional parameters: 2133 None. 2135 Encoding considerations: 2137 The native form of the data object is binary data, 2138 zero-padded to an octet boundary. Disk files that 2139 store this data object use the file extension ".acn". 2141 Restrictions on usage: 2143 This type is only defined for data object (stored file) 2144 transfer. The most common transports for the type are 2145 HTTP and SMTP. 2147 Security considerations: 2149 See Section 9 of this memo. 2151 Interoperability considerations: 2153 None. 2155 Published specification: 2157 The audio/asc data object is the AudioSpecificConfig 2158 binary data structure, which is normatively defined in [MPEGAUDIO]. 2160 Applications that use this media type: 2162 MPEG 4 Audio servers and terminals that support 2163 audio/mpeg4-generic RTP streams for mode rtp-midi. 2165 Additional information: 2167 None. 2169 Person & email address to contact for further information: 2171 John Lazzaro 2173 Intended usage: 2175 COMMON. 2177 Author: 2179 John Lazzaro 2181 Change controller: 2183 IETF Audio/Video Transport Working Group delegated 2184 from the IESG. 2186 12. Changes from RFC 4695 2188 This document fixes errors found in RFC 4695 by reviewers. We thank 2189 Alfred Hoenes, Roni Even, and Alexey Melnikov for reporting the errors. 2190 To our knowledge, there are no interoperability issues associated with 2191 the errors that are fixed by this document. In this section, we list 2192 the error fixes. 2194 In Section 3 of RFC 4695, the bitfield format shown in Figure 3 is 2195 inconsistent with the normative text that (correctly) describes the 2196 bitfield. Specifically, Figure 3 in RFC 4695 incorrectly states the 2197 dependence of the Delta Time 0 field on the Z header bit. Figure 3 in 2198 this document corrects this error. To our knowledge, this error did not 2199 result in incorrect implementations of RFC 4695. 2201 The remaining errors are in Appendices C and D, and concern session 2202 configuration parameters. The numbered list ((1) through (8)) below 2203 describes these errors in detail, in order of appearance in the 2204 document. To our knowledge, there are no interoperability issues 2205 associated with these errors, as implementation activity has so far 2206 focused on an application domain that does not use SDP for session 2207 management. 2209 (1) In Appendix C.1 and Appendix C.2.3 of RFC 4695, an ABNF rule 2210 related to System Chapter X is incorrectly defined as: 2212 = "__" ["_" ] "__" 2214 The correct version of this rule is: 2216 = "__" *( "_" ) "__" 2218 (2) In Appendix C.6.3 of RFC 4695, the URIs permitted to be assigned 2219 to the "url" parameter are not stated clearly. URIs assigned to "url" 2220 MUST specify either HTTP or HTTP over TLS transport protocols. 2222 In Appendix C.7.1 and C.7.2 of RFC 4695, the transport 2223 interoperability requirements for the "url" parameter are not stated 2224 clearly. For both C.7.1 and C.7.2, HTTP is REQUIRED and HTTP over TLS 2225 is OPTIONAL. 2227 (3) In Appendix C.6.5, the filename extension ".acn" has been defined 2228 for use with AudioSpecificConfig. 2230 (4) Both fmtp lines in both session description examples in Appendix 2231 C.7.2 of RFC 4695 contain instances of the same syntax error (a 2232 missing ";" at a line wrap after a cm_used assignment). 2234 (5) In Appendix D of RFC 4695, all uses of "*ietf-extension" in rules 2235 are in error, and should be replaced with "ietf-extension". Likewise, 2236 all uses of "*extension" are in error, and should be replaced with 2237 "extension". This bug incorrectly lets the null token be assigned to 2238 the j_sec, j_update, render, smf_info, and subrender parameters. 2240 (6) In Appendix D of RFC 4695, the definitions of the 2241 and incorrectly allow lowercase letters to appear in 2242 these strings. The correct definitions of these rules appear below: 2244 command-type = [A] [B] [C] [F] [G] [H] [J] [K] [M] 2245 [N] [P] [Q] [T] [V] [W] [X] [Y] [Z] 2247 chapter-list = [A] [B] [C] [D] [E] [F] [G] [H] [J] [K] 2248 [M] [N] [P] [Q] [T] [V] [W] [X] [Y] [Z] 2250 A = %x41 2251 B = %x42 2252 C = %x43 2253 D = %x44 2254 E = %x45 2255 F = %x46 2256 G = %x47 2257 H = %x48 2258 J = %x4A 2259 K = %x4B 2260 M = %x4D 2261 N = %x4E 2262 P = %x50 2263 Q = %x51 2264 T = %x54 2265 V = %x56 2266 W = %x57 2267 X = %x58 2268 Y = %x59 2269 Z = %x5A 2271 (7) In Appendix D of RFC 4695, the definitions of , 2272 , and are incorrect. The correct 2273 definitions of these rules appear below: 2275 nonzero-four-octet = (NZ-DIGIT 0*8(DIGIT)) 2276 / (%x31-33 9(DIGIT)) 2277 / ("4" %x30-31 8(DIGIT)) 2278 / ("42" %x30-38 7(DIGIT)) 2279 / ("429" %x30-33 6(DIGIT)) 2280 / ("4294" %x30-38 5(DIGIT)) 2281 / ("42949" %x30-35 4(DIGIT)) 2282 / ("429496" %x30-36 3(DIGIT)) 2283 / ("4294967" %x30-31 2(DIGIT)) 2284 / ("42949672" %x30-38 (DIGIT)) 2285 / ("429496729" %x30-34) 2287 four-octet = "0" / nonzero-four-octet 2288 midi-chan = DIGIT / ("1" %x30-35) 2290 DIGIT = %x30-39 2291 NZ-DIGIT = %x31-39 2293 (8) In Appendix D of RFC4695, the rule is 2294 incorrect. The correct definition of this rule appears below. 2296 hex-octet = %x30-37 U-HEXDIG 2297 U-HEXDIG = DIGIT / A / B / C / D / E / F 2299 ; DIGIT as defined in (6) above 2300 ; A, B, C, D, E, F as defined in (5) above 2302 (9) In Appendix D, the rule now points to the 2303 rule in [RFC4288]. 2305 (10) In Appendix D of RFC4695, the rules and 2306 are defined unclearly. The rewritten rules 2307 appear below: 2309 base64-unit = 4(base64-char) 2310 base64-pad = (2(base64-char) "==") / (3(base64-char) "=") 2312 A. The Recovery Journal Channel Chapters 2314 A.1. Recovery Journal Definitions 2316 This appendix defines the terminology and the coding idioms that are 2317 used in the recovery journal bitfield descriptions in Section 5 (journal 2318 header structure), Appendices A.2 to A.9 (channel journal chapters) and 2319 Appendices B.1 to B.5 (system journal chapters). 2321 We assume that the recovery journal resides in the journal section of an 2322 RTP packet with sequence number I ("packet I") and that the Checkpoint 2323 Packet Seqnum field in the top-level recovery journal header refers to a 2324 previous packet with sequence number C (an exception is the self- 2325 referential C = I case). Unless stated otherwise, algorithms are 2326 assumed to use modulo 2^16 arithmetic for calculations on 16-bit 2327 sequence numbers and modulo 2^32 arithmetic for calculations on 32-bit 2328 extended sequence numbers. 2330 Several bitfield coding idioms appear throughout the recovery journal 2331 system, with consistent semantics. Most recovery journal elements begin 2332 with an "S" (Single-packet loss) bit. S bits are designed to help 2333 receivers efficiently parse through the recovery journal hierarchy in 2334 the common case of the loss of a single packet. 2336 As a rule, S bits MUST be set to 1. However, an exception applies if a 2337 recovery journal element in packet I encodes data about a command stored 2338 in the MIDI command section of packet I - 1. In this case, the S bit of 2339 the recovery journal element MUST be set to 0. If a recovery journal 2340 element has its S bit set to 0, all higher-level recovery journal 2341 elements that contain it MUST also have S bits that are set to 0, 2342 including the top-level recovery journal header. 2344 Other consistent bitfield coding idioms are described below: 2346 o R flag bit. R flag bits are reserved for future use. Senders 2347 MUST set R bits to 0. Receivers MUST ignore R bit values. 2349 o LENGTH field. All fields named LENGTH (as distinct from LEN) 2350 code the number of octets in the structure that contains it, 2351 including the header it resides in and all hierarchical levels 2352 below it. If a structure contains a LENGTH field, a receiver 2353 MUST use the LENGTH field value to advance past the structure 2354 during parsing, rather than use knowledge about the internal 2355 format of the structure. 2357 We now define normative terms used to describe recovery journal 2358 semantics. 2360 o Checkpoint history. The checkpoint history of a recovery journal 2361 is the concatenation of the MIDI command sections of packets C 2362 through I - 1. The final command in the MIDI command section for 2363 packet I - 1 is considered the most recent command; the first 2364 command in the MIDI command section for packet C is the oldest 2365 command. If command X is less recent than command Y, X is 2366 considered to be "before Y". A checkpoint history with no 2367 commands is considered to be empty. The checkpoint history 2368 never contains the MIDI command section of packet I (the 2369 packet containing the recovery journal), so if C == I, the 2370 checkpoint history is empty by definition. 2372 o Session history. The session history of a recovery journal is 2373 the concatenation of MIDI command sections from the first 2374 packet of the session up to packet I - 1. The definitions of 2375 command recency and history emptiness follow those in the 2376 checkpoint history. The session history never contains the 2377 MIDI command section of packet I, and so the session history of 2378 the first packet in the session is empty by definition. 2380 o Finished/unfinished commands. If all octets of a MIDI command 2381 appear in the session history, the command is defined as being 2382 finished. If some but not all octets of a command appear 2383 in the session history, the command is defined as being unfinished. 2384 Unfinished commands occur if segments of a SysEx command appear 2385 in several RTP packets. For example, if a SysEx command is coded 2386 as 3 segments, with segment 1 in packet K, segment 2 in packet 2387 K + 1, and segment 3 in packet K + 2, the session histories for 2388 packets K + 1 and K + 2 contain unfinished versions of the command. 2389 A session history contains a finished version of a cancelled SysEx 2390 command if the history contains the cancel sublist for the command. 2392 o Reset State commands. Reset State (RS) commands reset 2393 renderers to an initialized "powerup" condition. The 2394 RS commands are: System Reset (0xFF), General MIDI System Enable 2395 (0xF0 0x7E 0xcc 0x09 0x01 0xF7), General MIDI 2 System Enable 2396 (0xF0 0x7E 0xcc 0x09 0x03 0xF7), General MIDI System Disable 2397 (0xF0 0x7E 0xcc 0x09 0x00 0xF7), Turn DLS On (0xF0 0x7E 0xcc 0x0A 2398 0x01 0xF7), and Turn DLS Off (0xF0 0x7E 0xcc 0x0A 0x02 0xF7). 2399 Registrations of subrender parameter token values (Appendix C.6.2) 2400 and IETF standards-track documents MAY specify additional 2401 RS commands. 2403 o Active commands. Active command are MIDI commands that do not 2404 appear before a Reset State command in the session history. 2406 o N-active commands. N-active commands are MIDI commands that do 2407 not appear before one of the following commands in the session 2408 history: MIDI Control Change numbers 123-127 (numbers with All 2409 Notes Off semantics) or 120 (All Sound Off), and any Reset 2410 State command. 2412 o C-active commands. C-active commands are MIDI commands that do 2413 not appear before one of the following commands in the session 2414 history: MIDI Control Change number 121 (Reset All Controllers) 2415 and any Reset State command. 2417 o Oldest-first ordering rule. Several recovery journal chapters 2418 contain a list of elements, where each element is associated 2419 with a MIDI command that appears in the session history. In 2420 most cases, the chapter definition requires that list elements 2421 be ordered in accordance with the "oldest-first ordering rule". 2422 Below, we normatively define this rule: 2424 Elements associated with the most recent command in the session 2425 history coded in the list MUST appear at the end of the list. 2427 Elements associated with the oldest command in the session 2428 history coded in the list MUST appear at the start of the list. 2430 All other list elements MUST be arranged with respect to these 2431 boundary elements, to produce a list ordering that strictly 2432 reflects the relative session history recency of the commands 2433 coded by the elements in the list. 2435 o Parameter system. A MIDI feature that provides two sets of 2436 16,384 parameters to expand the 0-127 controller number space. 2437 The Registered Parameter Names (RPN) system and the Non-Registered 2438 Parameter Names (NRPN) system each provides 16,384 parameters. 2440 o Parameter system transaction. The value of RPNs and NRPNs are 2441 changed by a series of Control Change commands that form a 2442 parameter system transaction. A canonical transaction begins 2443 with two Control Change commands to set the parameter number 2444 (controller numbers 99 and 98 for NRPNs, controller numbers 101 2445 and 100 for RPNs). The transaction continues with an arbitrary 2446 number of Data Entry (controller numbers 6 and 38), Data Increment 2447 (controller number 96), and Data Decrement (controller number 2448 97) Control Change commands to set the parameter value. The 2449 transaction ends with a second pair of (99, 98) or (101, 100) 2450 Control Change commands that specify the null parameter (MSB 2451 value 0x7F, LSB value 0x7F). 2453 Several variants of the canonical transaction sequence are 2454 possible. Most commonly, the terminal pair of (99, 98) or 2455 (101, 100) Control Change commands may specify a parameter 2456 other than the null parameter. In this case, the command 2457 pair terminates the first transaction and starts a second 2458 transaction. The command pair is considered to be a part 2459 of both transactions. This variant is legal and recommended 2460 in [MIDI]. We refer to this variant as a "type 1 variant". 2462 Less commonly, the MSB (99 or 101) or LSB (98 or 100) command 2463 of a (99, 98) or (101, 100) Control Change pair may be omitted. 2465 If the MSB command is omitted, the transaction uses the MSB value 2466 of the most recent C-active Control Change command for controller 2467 number 99 or 101 that appears in the session history. We refer to 2468 this variant as a "type 2 variant". 2470 If the LSB command is omitted, the LSB value 0x00 is assumed. We 2471 refer to this variant as a "type 3 variant". The type 2 and type 3 2472 variants are defined as legal, but are not recommended, in [MIDI]. 2474 System real-time commands may appear at any point during 2475 a transaction (even between octets of individual commands 2476 in the transaction). More generally, [MIDI] does not forbid 2477 the appearance of unrelated MIDI commands during an open 2478 transaction. As a rule, these commands are considered to 2479 be "outside" the transaction and do not affect the status 2480 of the transaction in any way. Exceptions to this rule are 2481 commands whose semantics act to terminate transactions: 2482 Reset State commands, and Control Change (0xB) for controller 2483 number 121 (Reset All Controllers) [RP015]. 2485 o Initiated parameter system transaction. A canonical parameter 2486 system transaction whose (99, 98) or (101, 100) initial Control 2487 Change command pair appears in the session history is considered 2488 to be an initiated parameter system transaction. This definition 2489 also holds for type 1 variants. For type 2 variants (dropped MSB), 2490 a transaction whose initial LSB Control Change command appears in 2491 the session history is an initiated transaction. For type 3 2492 variants (dropped LSB), a transaction is considered to be 2493 initiated if at least one transaction command follows the initial 2494 MSB (99 or 101) Control Change command in the session history. 2495 The completion of a transaction does not nullify its "initiated" 2496 status. 2498 o Session history reference counts. Several recovery journal 2499 chapters include a reference count field, which codes the 2500 total number of commands of a type that appear in the session 2501 history. Examples include the Reset and Tune Request command 2502 logs (Chapter D, Appendix B.1) and the Active Sense command 2503 (Chapter V, Appendix B.2). Upon the detection of a loss event, 2504 reference count fields let a receiver deduce if any instances of 2505 the command have been lost, by comparing the journal reference 2506 count with its own reference count. Thus, a reference count 2507 field makes sense, even for command types in which knowing the 2508 NUMBER of lost commands is irrelevant (as is true with all of 2509 the example commands mentioned above). 2511 The chapter definitions in Appendices A.2 to A.9 and B.1 to B.5 reflect 2512 the default recovery journal behavior. The ch_default, ch_never, and 2513 ch_anchor parameters modify these definitions, as described in Appendix 2514 C.2.3. 2516 The chapter definitions specify if data MUST be present in the journal. 2517 Senders MAY also include non-required data in the journal. This 2518 optional data MUST comply with the normative chapter definition. For 2519 example, if a chapter definition states that a field codes data from the 2520 most recent active command in the session history, the sender MUST NOT 2521 code inactive commands or older commands in the field. 2523 Finally, we note that a channel journal only encodes information about 2524 MIDI commands appearing on the MIDI channel the journal protects. All 2525 references to MIDI commands in Appendices A.2 to A.9 should be read as 2526 "MIDI commands appearing on this channel." 2527 A.2. Chapter P: MIDI Program Change 2529 A channel journal MUST contain Chapter P if an active Program Change 2530 (0xC) command appears in the checkpoint history. Figure A.2.1 shows the 2531 format for Chapter P. 2533 0 1 2 2534 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 2535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2536 |S| PROGRAM |B| BANK-MSB |X| BANK-LSB | 2537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2539 Figure A.2.1 -- Chapter P format 2541 The chapter has a fixed size of 24 bits. The PROGRAM field indicates 2542 the data value of the most recent active Program Change command in the 2543 session history. By default, the B, BANK-MSB, X, and BANK-LSB fields 2544 MUST be set to 0. Below, we define exceptions to this default 2545 condition. 2547 If an active Control Change (0xB) command for controller number 0 (Bank 2548 Select MSB) appears before the Program Change command in the session 2549 history, the B bit MUST be set to 1, and the BANK-MSB field MUST code 2550 the data value of the Control Change command. 2552 If B is set to 1, the BANK-LSB field MUST code the data value of the 2553 most recent Control Change command for controller number 32 (Bank Select 2554 LSB) that preceded the Program Change command coded in the PROGRAM field 2555 and followed the Control Change command coded in the BANK-MSB field. If 2556 no such Control Change command exists, the BANK-LSB field MUST be set to 2557 0. 2559 If B is set to 1, and if a Control Change command for controller number 2560 121 (Reset All Controllers) appears in the MIDI stream between the 2561 Control Change command coded by the BANK-MSB field and the Program 2562 Change command coded by the PROGRAM field, the X bit MUST be set to 1. 2564 Note that [RP015] specifies that Reset All Controllers does not reset 2565 the values of controller numbers 0 (Bank Select MSB) and 32 (Bank Select 2566 LSB). Thus, the X bit does not effect how receivers will use the BANK- 2567 LSB and BANK-MSB values when recovering from a lost Program Change 2568 command. The X bit serves to aid recovery in MIDI applications where 2569 controller numbers 0 and 32 are used in a non-standard way. 2571 A.3. Chapter C: MIDI Control Change 2573 Figure A.3.1 shows the format for Chapter C. 2575 0 1 2 3 2576 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 2577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2578 |S| LEN |S| NUMBER |A| VALUE/ALT |S| NUMBER | 2579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2580 |A| VALUE/ALT | .... | 2581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2583 Figure A.3.1 -- Chapter C format 2585 The chapter consists of a 1-octet header, followed by a variable length 2586 list of 2-octet controller logs. The list MUST contain at least one 2587 controller log. The 7-bit LEN field codes the number of controller logs 2588 in the list, minus one. We define the semantics of the controller log 2589 fields in Appendix A.3.2. 2591 A channel journal MUST contain Chapter C if the rules defined in this 2592 appendix require that one or more controller logs appear in the list. 2594 A.3.1. Log Inclusion Rules 2596 A controller log encodes information about a particular Control Change 2597 command in the session history. 2599 In the default use of the payload format, list logs MUST encode 2600 information about the most recent active command in the session history 2601 for a controller number. Logs encoding earlier commands MUST NOT appear 2602 in the list. 2604 Also, as a rule, the list MUST contain a log for the most recent active 2605 command for a controller number that appears in the checkpoint history. 2606 Below, we define exceptions to this rule: 2608 o MIDI streams may transmit 14-bit controller values using paired 2609 Most Significant Byte (MSB, controller numbers 0-31, 99, 101) and 2610 Least Significant Byte (LSB, controller numbers 32-63, 98, 100) 2611 Control Change commands [MIDI]. 2613 If the most recent active Control Change command in the session 2614 history for a 14-bit controller pair uses the MSB number, Chapter 2615 C MAY omit the controller log for the most recent active Control 2616 Change command for the associated LSB number, as the command 2617 ordering makes this LSB value irrelevant. However, this exception 2618 MUST NOT be applied if the sender is not certain that the MIDI 2619 source uses 14-bit semantics for the controller number pair. Note 2620 that some MIDI sources ignore 14-bit controller semantics and use 2621 the LSB controller numbers as independent 7-bit controllers. 2623 o If active Control Change commands for controller numbers 0 (Bank 2624 Select MSB) or 32 (Bank Select LSB) appear in the checkpoint 2625 history, and if the command instances are also coded in the 2626 BANK-MSB and BANK-LSB fields of the Chapter P (Appendix A.2), 2627 Chapter C MAY omit the controller logs for the commands. 2629 o Several controller number pairs are defined to be mutually 2630 exclusive. Controller numbers 124 (Omni Off) and 125 (Omni On) 2631 form a mutually exclusive pair, as do controller numbers 126 2632 (Mono) and 127 (Poly). 2634 If active Control Change commands for one or both members of 2635 a mutually exclusive pair appear in the checkpoint history, a 2636 log for the controller number of the most recent command for the 2637 pair in the checkpoint history MUST appear in the controller list. 2638 However, the list MAY omit the controller log for the most recent 2639 active command for the other number in the pair. 2641 If active Control Change commands for one or both members of a 2642 mutually exclusive pair appear in the session history, and if a 2643 log for the controller number of the most recent command for the 2644 pair does not appear in the controller list, a log for the most 2645 recent command for the other number of the pair MUST NOT appear 2646 in the controller list. 2648 o If an active Control Change command for controller number 121 2649 (Reset All Controllers) appears in the session history, the 2650 controller list MAY omit logs for Control Change commands that 2651 precede the Reset All Controllers command in the session history, 2652 under certain conditions. 2654 Namely, a log MAY be omitted if the sender is certain that a 2655 command stream follows the Reset All Controllers semantics 2656 defined in [RP015], and if the log codes a controller number 2657 for which [RP015] specifies a reset value. 2659 For example, [RP015] specifies that controller number 1 2660 (Modulation Wheel) is reset to the value 0, and thus 2661 a controller log for Modulation Wheel MAY be omitted 2662 from the controller log list. In contrast, [RP015] specifies 2663 that controller number 7 (Channel Volume) is not reset, 2664 and thus a controller log for Channel Volume MUST NOT 2665 be omitted from the controller log list. 2667 o Appendix A.3.4 defines exception rules for the MIDI Parameter 2668 System controller numbers 6, 38, and 96-101. 2670 A.3.2. Controller Log Format 2672 Figure A.3.2 shows the controller log structure of Chapter C. 2674 0 1 2675 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2677 |S| NUMBER |A| VALUE/ALT | 2678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2680 Figure A.3.2 -- Chapter C controller log 2682 The 7-bit NUMBER field identifies the controller number of the coded 2683 command. The 7-bit VALUE/ALT field codes recovery information for the 2684 command. The A bit sets the format of the VALUE/ALT field. 2686 A log encodes recovery information using one of the following tools: the 2687 value tool, the toggle tool, or the count tool. 2689 A log uses the value tool if the A bit is set to 0. The value tool 2690 codes the 7-bit data value of a command in the VALUE/ALT field. The 2691 value tool works best for controllers that code a continuous quantity, 2692 such as number 1 (Modulation Wheel). 2694 The A bit is set to 1 to code the toggle or count tool. These tools 2695 work best for controllers that code discrete actions. Figure A.3.3 2696 shows the controller log for these tools. 2698 0 1 2699 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2700 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2701 |S| NUMBER |1|T| ALT | 2702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2704 Figure A.3.3 -- Controller log for ALT tools 2706 A log uses the toggle tool if the T bit is set to 0. A log uses the 2707 count tool if the T bit is set to 1. Both methods use the 6-bit ALT 2708 field as an unsigned integer. 2710 The toggle tool works best for controllers that act as on/off switches, 2711 such as 64 (Damper Pedal (Sustain)). These controllers code the "off" 2712 state with control values 0-63 and the "on" state with 64-127. 2714 For the toggle tool, the ALT field codes the total number of toggles 2715 (off->on and on->off) due to Control Change commands in the session 2716 history, up to and including a toggle caused by the command coded by the 2717 log. The toggle count includes toggles caused by Control Change 2718 commands for controller number 121 (Reset All Controllers). 2720 Toggle counting is performed modulo 64. The toggle count is reset at 2721 the start of a session, and whenever a Reset State command (Appendix 2722 A.1) appears in the session history. When these reset events occur, the 2723 toggle count for a controller is set to 0 (for controllers whose default 2724 value is 0-63) or 1 (for controllers whose default value is 64-127). 2726 The Damper Pedal (Sustain) controller illustrates the benefits of the 2727 toggle tool over the value tool for switch controllers. As often used 2728 in piano applications, the "on" state of the controller lets notes 2729 resonate, while the "off" state immediately damps notes to silence. The 2730 loss of the "off" command in an "on->off->on" sequence results in 2731 ringing notes that should have been damped silent. The toggle tool lets 2732 receivers detect this lost "off" command, but the value tool does not. 2734 The count tool is conceptually similar to the toggle tool. For the 2735 count tool, the ALT field codes the total number of Control Change 2736 commands in the session history, up to and including the command coded 2737 by the log. Command counting is performed modulo 64. The command count 2738 is set to 0 at the start of the session and is reset to 0 whenever a 2739 Reset State command (Appendix A.1) appears in the session history. 2741 Because the count tool ignores the data value, it is a good match for 2742 controllers whose controller value is ignored, such as number 123 (All 2743 Notes Off). More generally, the count tool may be used to code a 2744 (modulo 64) identification number for a command. 2746 A.3.3. Log List Coding Rules 2748 In this section, we describe the organization of controller logs in the 2749 Chapter C log list. 2751 A log encodes information about a particular Control Change command in 2752 the session history. In most cases, a command SHOULD be coded by a 2753 single tool (and, thus, a single log). If a number is coded with a 2754 single tool and this tool is the count tool, recovery Control Change 2755 commands generated by a receiver SHOULD use the default control value 2756 for the controller. 2758 However, a command MAY be coded by several tool types (and, thus, 2759 several logs, each using a different tool). This technique may improve 2760 recovery performance for controllers with complex semantics, such as 2761 controller number 84 (Portamento Control) or controller number 121 2762 (Reset All Controllers) when used with a non-zero data octet (with the 2763 semantics described in [DLS2]). 2765 If a command is encoded by multiple tools, the logs MUST be placed in 2766 the list in the following order: count tool log (if any), followed by 2767 value tool log (if any), followed by toggle tool log (if any). 2769 The Chapter C log list MUST obey the oldest-first ordering rule (defined 2770 in Appendix A.1). Note that this ordering preserves the information 2771 necessary for the recovery of 14-bit controller values, without 2772 precluding the use of MSB and LSB controller pairs as independent 7-bit 2773 controllers. 2775 In the default use of the payload format, all logs that appear in the 2776 list for a controller number encode information about one Control Change 2777 command -- namely, the most recent active Control Change command in the 2778 session history for the number. 2780 This coding scheme provides good recovery performance for the standard 2781 uses of Control Change commands defined in [MIDI]. However, not all 2782 MIDI applications restrict the use of Control Change commands to those 2783 defined in [MIDI]. 2785 For example, consider the common MIDI encoding of rotary encoders 2786 ("infinite" rotation knobs). The mixing console MIDI convention defined 2787 in [LCP] codes the position of rotary encoders as a series of Control 2788 Change commands. Each command encodes a relative change of knob 2789 position from the last update (expressed as a clockwise or counter- 2790 clockwise knob turning angle). 2792 As the knob position is encoded incrementally over a series of Control 2793 Change commands, the best recovery performance is obtained if the log 2794 list encodes all Control Change commands for encoder controller numbers 2795 that appear in the checkpoint history, not only the most recent command. 2797 To support application areas that use Control Change commands in this 2798 way, Chapter C may be configured to encode information about several 2799 Control Change commands for a controller number. We use the term 2800 "enhanced" to describe this encoding method, which we describe below. 2802 In Appendix C.2.3, we show how to configure a stream to use enhanced 2803 Chapter C encoding for specific controller numbers. In Section 5 in the 2804 main text, we show how the H bits in the recovery journal header (Figure 2805 8) and in the channel journal header (Figure 9) indicate the use of 2806 enhanced Chapter C encoding. 2808 Here, we define how to encode a Chapter C log list that uses the 2809 enhanced encoding method. 2811 Senders that use the enhanced encoding method for a controller number 2812 MUST obey the rules below. These rules let a receiver determine which 2813 logs in the list correspond to lost commands. Note that these rules 2814 override the exceptions listed in Appendix A.3.1. 2816 o If N commands for a controller number are encoded in the list, 2817 the commands MUST be the N most recent commands for the controller 2818 number in the session history. For example, for N = 2, the sender 2819 MUST encode the most recent command and the second most recent 2820 command, not the most recent command and the third most recent 2821 command. 2823 o If a controller number uses enhanced encoding, the encoding 2824 of the least-recent command for the controller number in the 2825 log list MUST include a count tool log. In addition, if 2826 commands are encoded for the controller number whose logs 2827 have S bits set to 0, the encoding of the least-recent 2828 command with S = 0 logs MUST include a count tool log. 2830 The count tool is OPTIONAL for the other commands for the 2831 controller number encoded in the list, as a receiver is 2832 able to efficiently deduce the count tool value for these 2833 commands, for both single-packet and multi-packet loss events. 2835 o The use of the value and toggle tools MUST be identical for all 2836 commands for a controller number encoded in the list. For 2837 example, a value tool log either MUST appear for all commands 2838 for the controller number coded in the list, or alternatively, 2839 value tool logs for the controller number MUST NOT appear in 2840 the list. Likewise, a toggle tool log either MUST appear for 2841 all commands for the controller number coded in the list, or 2842 alternatively, toggle tool logs for the controller number MUST 2843 NOT appear in the list. 2845 o If a command is encoded by multiple tools, the logs MUST be 2846 placed in the list in the following order: count tool log 2847 (if any), followed by value tool log (if any), followed by 2848 toggle tool log (if any). 2850 These rules permit a receiver recovering from a packet loss to use the 2851 count tool log to match the commands encoded in the list with its own 2852 history of the stream, as we describe below. Note that the text below 2853 describes a non-normative algorithm; receivers are free to use any 2854 algorithm to match its history with the log list. 2856 In a typical implementation of the enhanced encoding method, a receiver 2857 computes and stores count, value, and toggle tool data field values for 2858 the most recent Control Change command it has received for a controller 2859 number. 2861 After a loss event, a receiver parses the Chapter C list and processes 2862 list logs for a controller number that uses enhanced encoding as 2863 follows. 2865 The receiver compares the count tool ALT field for the least-recent 2866 command for the controller number in the list against its stored count 2867 data for the controller number, to determine if recovery is necessary 2868 for the command coded in the list. The value and toggle tool logs (if 2869 any) that directly follow the count tool log are associated with this 2870 least-recent command. 2872 To check more-recent commands for the controller, the receiver detects 2873 additional value and/or toggle tool logs for the controller number in 2874 the list and infers count tool data for the command coded by these logs. 2875 This inferred data is used to determine if recovery is necessary for the 2876 command coded by the value and/or toggle tool logs. 2878 In this way, a receiver is able to execute only lost commands, without 2879 executing a command twice. While recovering from a single packet loss, 2880 a receiver may skip through S = 1 logs in the list, as the first S = 0 2881 log for an enhanced controller number is always a count tool log. 2883 Note that the requirements in Appendix C.2.2.2 for protective sender and 2884 receiver actions during session startup for multicast operation are of 2885 particular importance for enhanced encoding, as receivers need to 2886 initialize its count tool data structures with recovery journal data in 2887 order to match commands correctly after a loss event. 2889 Finally, we note in passing that in some applications of rotary 2890 encoders, a good user experience may be possible without the use of 2891 enhanced encoding. These applications are distinguished by visual 2892 feedback of encoding position that is driven by the post-recovery rotary 2893 encoding stream, and relatively low packet loss. In these domains, 2894 recovery performance may be acceptable for rotary encoders if the log 2895 list encodes only the most recent command, if both count and value logs 2896 appear for the command. 2898 A.3.4. The Parameter System 2900 Readers may wish to review the Appendix A.1 definitions of "parameter 2901 system", "parameter system transaction", and "initiated parameter system 2902 transaction" before reading this section. 2904 Parameter system transactions update a MIDI Registered Parameter Number 2905 (RPN) or Non-Registered Parameter Number (NRPN) value. A parameter 2906 system transaction is a sequence of Control Change commands that may use 2907 the following controllers numbers: 2909 o Data Entry MSB (6) 2910 o Data Entry LSB (38) 2911 o Data Increment (96) 2912 o Data Decrement (97) 2913 o Non-Registered Parameter Number (NRPN) LSB (98) 2914 o Non-Registered Parameter Number (NRPN) MSB (99) 2915 o Registered Parameter Number (RPN) LSB (100) 2916 o Registered Parameter Number (RPN) MSB (101) 2918 Control Change commands that are a part of a parameter system 2919 transaction MUST NOT be coded in Chapter C controller logs. Instead, 2920 these commands are coded in Chapter M, the MIDI Parameter chapter 2921 defined in Appendix A.4. 2923 However, Control Change commands that use the listed controllers as 2924 general-purpose controllers (i.e., outside of a parameter system 2925 transaction) MUST NOT be coded in Chapter M. 2927 Instead, the controllers are coded in Chapter C controller logs. The 2928 controller logs follow the coding rules stated in Appendix A.3.2 and 2929 A.3.3. The rules for coding paired LSB and MSB controllers, as defined 2930 in Appendix A.3.1, apply to the pairs (6, 38), (99, 98), and (101, 100) 2931 when coded in Chapter C. 2933 If active Control Change commands for controller numbers 6, 38, or 2934 96-101 appear in the checkpoint history, and these commands are used as 2935 general-purpose controllers, the most recent general-purpose command 2936 instance for these controller numbers MUST appear as entries in the 2937 Chapter C controller list. 2939 MIDI syntax permits a source to use controllers 6, 38, 96, and 97 as 2940 parameter-system controllers and general-purpose controllers in the same 2941 stream. An RTP MIDI sender MUST deduce the role of each Control Change 2942 command for these controller numbers by noting the placement of the 2943 command in the stream and MUST use this information to code the command 2944 in Chapter C or Chapter M, as appropriate. 2946 Specifically, active Control Change commands for controllers 6, 38, 96, 2947 and 97 act in a general-purpose way when 2949 o no active Control Change commands that set an RPN or 2950 NRPN parameter number appear in the session history, or 2952 o the most recent active Control Change commands in the session 2953 history that set an RPN or NRPN parameter number code the null 2954 parameter (MSB value 0x7F, LSB value 0x7F), or 2956 o a Control Change command for controller number 121 (Reset 2957 All Controllers) appears more recently in the session history 2958 than all active Control Change commands that set an RPN or 2959 NRPN parameter number (see [RP015] for details). 2961 Finally, we note that a MIDI source that follows the recommendations of 2962 [MIDI] exclusively uses numbers 98-101 as parameter system controllers. 2963 Alternatively, a MIDI source may exclusively use 98-101 as general- 2964 purpose controllers and lose the ability to perform parameter system 2965 transactions in a stream. 2967 In the language of [MIDI], the general-purpose use of controllers 98-101 2968 constitutes a non-standard controller assignment. As most real-world 2969 MIDI sources use the standard controller assignment for controller 2970 numbers 98-101, an RTP MIDI sender SHOULD assume these controllers act 2971 as parameter system controllers, unless it knows that a MIDI source uses 2972 controller numbers 98-101 in a general-purpose way. 2974 A.4. Chapter M: MIDI Parameter System 2976 Readers may wish to review the Appendix A.1 definitions for "C-active", 2977 "parameter system", "parameter system transaction", and "initiated 2978 parameter system transaction" before reading this appendix. 2980 Chapter M protects parameter system transactions for Registered 2981 Parameter Number (RPN) and Non-Registered Parameter Number (NRPN) 2982 values. Figure A.4.1 shows the format for Chapter M. 2984 0 1 2 3 2985 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 2986 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2987 |S|P|E|U|W|Z| LENGTH |Q| PENDING | Log list ... | 2988 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2990 Figure A.4.1 -- Top-level Chapter M format 2992 Chapter M begins with a 2-octet header. If the P header bit is set to 2993 1, a 1-octet field follows the header, coding the 7-bit PENDING value 2994 and its associated Q bit. 2996 The 10-bit LENGTH field codes the size of Chapter M and conforms to 2997 semantics described in Appendix A.1. 2999 Chapter M ends with a list of zero or more variable-length parameter 3000 logs. Appendix A.4.2 defines the bitfield format of a parameter log. 3001 Appendix A.4.1 defines the inclusion semantics of the log list. 3003 A channel journal MUST contain Chapter M if the rules defined in 3004 Appendix A.4.1 require that one or more parameter logs appear in the 3005 list. 3007 A channel journal also MUST contain Chapter M if the most recent C- 3008 active Control Change command involved in a parameter system transaction 3009 in the checkpoint history is 3011 o an RPN MSB (101) or NRPN MSB (99) controller, or 3013 o an RPN LSB (100) or NRPN LSB (98) controller that completes the 3014 coding of the null parameter (MSB value 0x7F, LSB value 0x7F). 3016 This rule provides loss protection for partially transmitted parameter 3017 numbers and for the null parameter numbers. 3019 If the most recent C-active Control Change command involved in a 3020 parameter system transaction in the session history is for the RPN MSB 3021 or NRPN MSB controller, the P header bit MUST be set to 1, and the 3022 PENDING field (and its associated Q bit) MUST follow the Chapter M 3023 header. Otherwise, the P header bit MUST be set to 0, and the PENDING 3024 field and Q bit MUST NOT appear in Chapter M. 3026 If PENDING codes an NRPN MSB, the Q bit MUST be set to 1. If PENDING 3027 codes an RPN MSB, the Q bit MUST be set to 0. 3029 The E header bit codes the current transaction state of the MIDI stream. 3030 If E = 1, an initiated transaction is in progress. Below, we define the 3031 rules for setting the E header bit: 3033 o If no C-active parameter system transaction Control Change 3034 commands appear in the session history, the E bit MUST be 3035 set to 0. 3037 o If the P header bit is set to 1, the E bit MUST be set to 0. 3039 o If the most recent C-active parameter system transaction 3040 Control Change command in the session history is for the 3041 NRPN LSB or RPN LSB controller number, and if this command 3042 acts to complete the coding of the null parameter (MSB 3043 value 0x7F, LSB value 0x7F), the E bit MUST be set to 0. 3045 o Otherwise, an initiated transaction is in progress, and the 3046 E bit MUST be set to 1. 3048 The U, W, and Z header bits code properties that are shared by all 3049 parameter logs in the list. If these properties are set, parameter logs 3050 may be coded with improved efficiency (we explain how in A.4.1). 3052 By default, the U, W, and Z bits MUST be set to 0. If all parameter 3053 logs in the list code RPN parameters, the U bit MAY be set to 1. If all 3054 parameter logs in the list code NRPN parameters, the W bit MAY be set to 3055 1. If the parameter numbers of all RPN and NRPN logs in the list lie in 3056 the range 0-127 (and thus have an MSB value of 0), the Z bit MAY be set 3057 to 1. 3059 Note that C-active semantics appear in the preceding paragraphs because 3060 [RP015] specifies that pending Parameter System transactions are closed 3061 by a Control Change command for controller number 121 (Reset All 3062 Controllers). 3064 A.4.1. Log Inclusion Rules 3066 Parameter logs code recovery information for a specific RPN or NRPN 3067 parameter. 3069 A parameter log MUST appear in the list if an active Control Change 3070 command that forms a part of an initiated transaction for the parameter 3071 appears in the checkpoint history. 3073 An exception to this rule applies if the checkpoint history only 3074 contains transaction Control Change commands for controller numbers 3075 98-101 that act to terminate the transaction. In this case, a log for 3076 the parameter MAY be omitted from the list. 3078 A log MAY appear in the list if an active Control Change command that 3079 forms a part of an initiated transaction for the parameter appears in 3080 the session history. Otherwise, a log for the parameter MUST NOT appear 3081 in the list. 3083 Multiple logs for the same RPN or NRPN parameter MUST NOT appear in the 3084 log list. 3086 The parameter log list MUST obey the oldest-first ordering rule (defined 3087 in Appendix A.1), with the phrase "parameter transaction" replacing the 3088 word "command" in the rule definition. 3090 Parameter logs associated with the RPN or NRPN null parameter (LSB = 3091 0x7F, MSB = 0x7F) MUST NOT appear in the log list. Chapter M uses the E 3092 header bit (Figure A.4.1) and the log list ordering rules to code null 3093 parameter semantics. 3095 Note that "active" semantics (rather than "C-active" semantics) appear 3096 in the preceding paragraphs because [RP015] specifies that pending 3097 Parameter System transactions are not reset by a Control Change command 3098 for controller number 121 (Reset All Controllers). However, the rule 3099 that follows uses C-active semantics, because it concerns the protection 3100 of the transaction system itself, and [RP015] specifies that Reset All 3101 Controllers acts to close a transaction in progress. 3103 In most cases, parameter logs for RPN and NRPN parameters that are 3104 assigned to the ch_never parameter (Appendix C.2.3) MAY be omitted from 3105 the list. An exception applies if 3107 o the log codes the most recent initiated transaction 3108 in the session history, and 3110 o a C-active command that forms a part of the transaction 3111 appears in the checkpoint history, and 3113 o the E header bit for the top-level Chapter M header (Figure 3114 A.4.1) is set to 1. 3116 In this case, a log for the parameter MUST appear in the list. This log 3117 informs receivers recovering from a loss that a transaction is in 3118 progress, so that the receiver is able to correctly interpret RPN or 3119 NRPN Control Change commands that follow the loss event. 3121 A.4.2. Log Coding Rules 3123 Figure A.4.2 shows the parameter log structure of Chapter M. 3125 0 1 2 3 3126 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 3127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3128 |S| PNUM-LSB |Q| PNUM-MSB |J|K|L|M|N|T|V|R| Fields ... | 3129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3131 Figure A.4.2 -- Parameter log format 3133 The log begins with a header, whose default size (as shown in Figure 3134 A.4.2) is 3 octets. If the Q header bit is set to 0, the log encodes an 3135 RPN parameter. If Q = 1, the log encodes an NRPN parameter. The 7-bit 3136 PNUM-MSB and PNUM-LSB fields code the parameter number and reflect the 3137 Control Change command data values for controllers 99 and 98 (for NRPNs) 3138 or 101 and 100 (for RPNs). 3140 The J, K, L, M, and N header bits form a Table of Contents (TOC) for the 3141 log and signal the presence of fixed-sized fields that follow the 3142 header. A header bit that is set to 1 codes the presence of a field in 3143 the log. The ordering of fields in the log follows the ordering of the 3144 header bits in the TOC. Appendices A.4.2.1-2 define the fields 3145 associated with each TOC header bit. 3147 The T and V header bits code information about the parameter log but are 3148 not part of the TOC. A set T or V bit does not signal the presence of 3149 any parameter log field. 3151 If the rules in Appendix A.4.1 state that a log for a given parameter 3152 MUST appear in Chapter M, the log MUST code sufficient information to 3153 protect the parameter from the loss of active parameter transaction 3154 Control Change commands in the checkpoint history. 3156 This rule does not apply if the parameter coded by the log is assigned 3157 to the ch_never parameter (Appendix C.2.3). In this case, senders MAY 3158 choose to set the J, K, L, M, and N TOC bits to 0, coding a parameter 3159 log with no fields. 3161 Note that logs to protect parameters that are assigned to ch_never are 3162 REQUIRED under certain conditions (see Appendix A.4.1). The purpose of 3163 the log is to inform receivers recovering from a loss that a transaction 3164 is in progress, so that the receiver is able to correctly interpret RPN 3165 or NRPN Control Change commands that follow the loss event. 3167 Parameter logs provide two tools for parameter protection: the value 3168 tool and the count tool. Depending on the semantics of the parameter, 3169 senders may use either tool, both tools, or neither tool to protect a 3170 given parameter. 3172 The value tool codes information a receiver may use to determine the 3173 current value of an RPN or NRPN parameter. If a parameter log uses the 3174 value tool, the V header bit MUST be set to 1, and the semantics defined 3175 in Appendices A.4.2.1 for setting the J, K, L, and M TOC bits MUST be 3176 followed. If a parameter log does not use the value tool, the V bit 3177 MUST be set to 0, and the J, K, L, and M TOC bits MUST also be set to 0. 3179 The count tool codes the number of transactions for an RPN or NRPN 3180 parameter. If a parameter log uses the count tool, the T header bit 3181 MUST be set to 1, and the semantics defined in Appendices A.4.2.2 for 3182 setting the N TOC bit MUST be followed. If a parameter log does not use 3183 the count tool, the T bit and the N TOC bit MUST be set to 0. 3185 Note that V and T are set if the sender uses value (V) or count (T) tool 3186 for the log on an ongoing basis. Thus, V may be set even if J = K = L = 3187 M = 0, and T may be set even if N = 0. 3189 In many cases, all parameters coded in the log list are of one type (RPN 3190 and NRPN), and all parameter numbers lie in the range 0-127. As 3191 described in Appendix A.4.1, senders MAY signal this condition by 3192 setting the top-level Chapter M header bit Z to 1 (to code the 3193 restricted range) and by setting the U or W bit to 1 (to code the 3194 parameter type). 3196 If the top-level Chapter M header codes Z = 1 and either U = 1 or W = 1, 3197 all logs in the parameter log list MUST use a modified header format. 3198 This modification deletes bits 8-15 of the bitfield shown in Figure 3199 A.4.2, to yield a 2-octet header. The values of the deleted PNUM-MSB 3200 and Q fields may be inferred from the U, W, and Z bit values. 3202 A.4.2.1. The Value Tool 3204 The value tool uses several fields to track the value of an RPN or NRPN 3205 parameter. 3207 The J TOC bit codes the presence of the octet shown in Figure A.4.3 in 3208 the field list. 3210 0 3211 0 1 2 3 4 5 6 7 3212 +-+-+-+-+-+-+-+-+ 3213 |X| ENTRY-MSB | 3214 +-+-+-+-+-+-+-+-+ 3216 Figure A.4.3 -- ENTRY-MSB field 3218 The 7-bit ENTRY-MSB field codes the data value of the most recent active 3219 Control Change command for controller number 6 (Data Entry MSB) in the 3220 session history that appears in a transaction for the log parameter. 3222 The X bit MUST be set to 1 if the command coded by ENTRY-MSB precedes 3223 the most recent Control Change command for controller 121 (Reset All 3224 Controllers) in the session history. Otherwise, the X bit MUST be set 3225 to 0. 3227 A parameter log that uses the value tool MUST include the ENTRY-MSB 3228 field if an active Control Change command for controller number 6 3229 appears in the checkpoint history. 3231 Note that [RP015] specifies that Control Change commands for controller 3232 121 (Reset All Controllers) do not reset RPN and NRPN values, and thus 3233 the X bit would not play a recovery role for MIDI systems that comply 3234 with [RP015]. 3236 However, certain renderers (such as DLS 2 [DLS2]) specify that certain 3237 RPN values are reset for some uses of Reset All Controllers. The X bit 3238 (and other bitfield features of this nature in this appendix) plays a 3239 role in recovery for renderers of this type. 3241 The K TOC bit codes the presence of the octet shown in Figure A.4.4 in 3242 the field list. 3244 0 3245 0 1 2 3 4 5 6 7 3246 +-+-+-+-+-+-+-+-+ 3247 |X| ENTRY-LSB | 3248 +-+-+-+-+-+-+-+-+ 3250 Figure A.4.4 -- ENTRY-LSB field 3252 The 7-bit ENTRY-LSB field codes the data value of the most recent active 3253 Control Change command for controller number 38 (Data Entry LSB) in the 3254 session history that appears in a transaction for the log parameter. 3256 The X bit MUST be set to 1 if the command coded by ENTRY-LSB precedes 3257 the most recent Control Change command for controller 121 (Reset All 3258 Controllers) in the session history. Otherwise, the X bit MUST be set 3259 to 0. 3261 As a rule, a parameter log that uses the value tool MUST include the 3262 ENTRY-LSB field if an active Control Change command for controller 3263 number 38 appears in the checkpoint history. However, the ENTRY-LSB 3264 field MUST NOT appear in a parameter log if the Control Change command 3265 associated with the ENTRY-LSB precedes a Control Change command for 3266 controller number 6 (Data Entry MSB) that appears in a transaction for 3267 the log parameter in the session history. 3269 The L TOC bit codes the presence of the octets shown in Figure A.4.5 in 3270 the field list. 3272 0 1 3273 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 3274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3275 |G|X| A-BUTTON | 3276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3278 Figure A.4.5 -- A-BUTTON field 3280 The 14-bit A-BUTTON field codes a count of the number of active Control 3281 Change commands for controller numbers 96 and 97 (Data Increment and 3282 Data Decrement) in the session history that appear in a transaction for 3283 the log parameter. 3285 The M TOC bit codes the presence of the octets shown in Figure A.4.6 in 3286 the field list. 3288 0 1 3289 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 3290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3291 |G|R| C-BUTTON | 3292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3294 Figure A.4.6 -- C-BUTTON field 3296 The 14-bit C-BUTTON field has semantics identical to A-BUTTON, except 3297 that Data Increment and Data Decrement Control Change commands that 3298 precede the most recent Control Change command for controller 121 (Reset 3299 All Controllers) in the session history are not counted. 3301 For both A-BUTTON and C-BUTTON, Data Increment and Data Decrement 3302 Control Change commands are not counted if they precede Control Changes 3303 commands for controller numbers 6 (Data Entry MSB) or 38 (Data Entry 3304 LSB) that appear in a transaction for the log parameter in the session 3305 history. 3307 The A-BUTTON and C-BUTTON fields are interpreted as unsigned integers, 3308 and the G bit associated with the field codes the sign of the integer (G 3309 = 0 for positive or zero, G = 1 for negative). 3311 To compute and code the count value, initialize the count value to 0, 3312 add 1 for each qualifying Data Increment command, and subtract 1 for 3313 each qualifying Data Decrement command. After each add or subtract, 3314 limit the count magnitude to 16383. The G bit codes the sign of the 3315 count, and the A-BUTTON or C-BUTTON field codes the count magnitude. 3317 For the A-BUTTON field, if the most recent qualified Data Increment or 3318 Data Decrement command precedes the most recent Control Change command 3319 for controller 121 (Reset All Controllers) in the session history, the X 3320 bit associated with A-BUTTON field MUST be set to 1. Otherwise, the X 3321 bit MUST be set to 0. 3323 A parameter log that uses the value tool MUST include the A-BUTTON and 3324 C-BUTTON fields if an active Control Change command for controller 3325 numbers 96 or 97 appears in the checkpoint history. However, to improve 3326 coding efficiency, this rule has several exceptions: 3328 o If the log includes the A-BUTTON field, and if the X bit of 3329 the A-BUTTON field is set to 1, the C-BUTTON field (and its 3330 associated R and G bits) MAY be omitted from the log. 3332 o If the log includes the A-BUTTON field, and if the A-BUTTON 3333 and C-BUTTON fields (and their associated G bits) code identical 3334 values, the C-BUTTON field (and its associated R and G bits) 3335 MAY be omitted from the log. 3337 A.4.2.2. The Count Tool 3339 The count tool tracks the number of transactions for an RPN or NRPN 3340 parameter. The N TOC bit codes the presence of the octet shown in 3341 Figure A.4.7 in the field list. 3343 0 3344 0 1 2 3 4 5 6 7 3345 +-+-+-+-+-+-+-+-+ 3346 |X| COUNT | 3347 +-+-+-+-+-+-+-+-+ 3349 Figure A.4.7 -- COUNT field 3351 The 7-bit COUNT codes the number of initiated transactions for the log 3352 parameter that appear in the session history. Initiated transactions 3353 are counted if they contain one or more active Control Change commands, 3354 including commands for controllers 98-101 that initiate the parameter 3355 transaction. 3357 If the most recent counted transaction precedes the most recent Control 3358 Change command for controller 121 (Reset All Controllers) in the session 3359 history, the X bit associated with the COUNT field MUST be set to 1. 3360 Otherwise, the X bit MUST be set to 0. 3362 Transaction counting is performed modulo 128. The transaction count is 3363 set to 0 at the start of a session and is reset to 0 whenever a Reset 3364 State command (Appendix A.1) appears in the session history. 3366 A parameter log that uses the count tool MUST include the COUNT field if 3367 an active command that increments the transaction count (modulo 128) 3368 appears in the checkpoint history. 3370 A.5. Chapter W: MIDI Pitch Wheel 3372 A channel journal MUST contain Chapter W if a C-active MIDI Pitch Wheel 3373 (0xE) command appears in the checkpoint history. Figure A.5.1 shows the 3374 format for Chapter W. 3376 0 1 3377 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 3378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3379 |S| FIRST |R| SECOND | 3380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3382 Figure A.5.1 -- Chapter W format 3384 The chapter has a fixed size of 16 bits. The FIRST and SECOND fields 3385 are the 7-bit values of the first and second data octets of the most 3386 recent active Pitch Wheel command in the session history. 3388 Note that Chapter W encodes C-active commands and thus does not encode 3389 active commands that are not C-active (see the second-to-last paragraph 3390 of Appendix A.1 for an explanation of chapter inclusion text in this 3391 regard). 3393 Chapter W does not encode "active but not C-active" commands because 3394 [RP015] declares that Control Change commands for controller number 121 3395 (Reset All Controllers) act to reset the Pitch Wheel value to 0. If 3396 Chapter W encoded "active but not C-active" commands, a repair operation 3397 following a Reset All Controllers command could incorrectly repair the 3398 stream with a stale Pitch Wheel value. 3400 A.6. Chapter N: MIDI NoteOff and NoteOn 3402 In this appendix, we consider NoteOn commands with zero velocity to be 3403 NoteOff commands. Readers may wish to review the Appendix A.1 3404 definition of "N-active commands" before reading this appendix. 3406 Chapter N completely protects note commands in streams that alternate 3407 between NoteOn and NoteOff commands for a particular note number. 3408 However, in rare applications, multiple overlapping NoteOn commands may 3409 appear for a note number. Chapter E, described in Appendix A.7, 3410 augments Chapter N to completely protect these streams. 3412 A channel journal MUST contain Chapter N if an N-active MIDI NoteOn 3413 (0x9) or NoteOff (0x8) command appears in the checkpoint history. 3414 Figure A.6.1 shows the format for Chapter N. 3416 0 1 2 3 3417 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 3418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3419 |B| LEN | LOW | HIGH |S| NOTENUM |Y| VELOCITY | 3420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3421 |S| NOTENUM |Y| VELOCITY | .... | 3422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3423 | OFFBITS | OFFBITS | .... | OFFBITS | 3424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3426 Figure A.6.1 -- Chapter N format 3428 Chapter N consists of a 2-octet header, followed by at least one of the 3429 following data structures: 3431 o A list of note logs to code NoteOn commands. 3432 o A NoteOff bitfield structure to code NoteOff commands. 3434 We define the header bitfield semantics in Appendix A.6.1. We define 3435 the note log semantics and the NoteOff bitfield semantics in Appendix 3436 A.6.2. 3438 If one or more N-active NoteOn or NoteOff commands in the checkpoint 3439 history reference a note number, the note number MUST be coded in either 3440 the note log list or the NoteOff bitfield structure. 3442 The note log list MUST contain an entry for all note numbers whose most 3443 recent checkpoint history appearance is in an N-active NoteOn command. 3444 The NoteOff bitfield structure MUST contain a set bit for all note 3445 numbers whose most recent checkpoint history appearance is in an N- 3446 active NoteOff command. 3448 A note number MUST NOT be coded in both structures. 3450 All note logs and NoteOff bitfield set bits MUST code the most recent N- 3451 active NoteOn or NoteOff reference to a note number in the session 3452 history. 3454 The note log list MUST obey the oldest-first ordering rule (defined in 3455 Appendix A.1). 3457 A.6.1. Header Structure 3459 The header for Chapter N, shown in Figure A.6.2, codes the size of the 3460 note list and bitfield structures. 3462 0 1 3463 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 3464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3465 |B| LEN | LOW | HIGH | 3466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3468 Figure A.6.2 -- Chapter N header 3470 The LEN field, a 7-bit integer value, codes the number of 2-octet note 3471 logs in the note list. Zero is a valid value for LEN and codes an empty 3472 note list. 3474 The 4-bit LOW and HIGH fields code the number of OFFBITS octets that 3475 follow the note log list. LOW and HIGH are unsigned integer values. If 3476 LOW <= HIGH, there are (HIGH - LOW + 1) OFFBITS octets in the chapter. 3477 The value pairs (LOW = 15, HIGH = 0) and (LOW = 15, HIGH = 1) code an 3478 empty NoteOff bitfield structure (i.e., no OFFBITS octets). Other (LOW 3479 > HIGH) value pairs MUST NOT appear in the header. 3481 The B bit provides S-bit functionality (Appendix A.1) for the NoteOff 3482 bitfield structure. By default, the B bit MUST be set to 1. However, 3483 if the MIDI command section of the previous packet (packet I - 1, with I 3484 as defined in Appendix A.1) includes a NoteOff command for the channel, 3485 the B bit MUST be set to 0. If the B bit is set to 0, the higher-level 3486 recovery journal elements that contain Chapter N MUST have S bits that 3487 are set to 0, including the top-level journal header. 3489 The LEN value of 127 codes a note list length of 127 or 128 note logs, 3490 depending on the values of LOW and HIGH. If LEN = 127, LOW = 15, and 3491 HIGH = 0, the note list holds 128 note logs, and the NoteOff bitfield 3492 structure is empty. For other values of LOW and HIGH, LEN = 127 codes 3493 that the note list contains 127 note logs. In this case, the chapter 3494 has (HIGH - LOW + 1) NoteOff OFFBITS octets if LOW <= HIGH and has no 3495 OFFBITS octets if LOW = 15 and HIGH = 1. 3497 A.6.2. Note Structures 3499 Figure A.6.3 shows the 2-octet note log structure. 3501 0 1 3502 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 3503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3504 |S| NOTENUM |Y| VELOCITY | 3505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3507 Figure A.6.3 -- Chapter N note log 3509 The 7-bit NOTENUM field codes the note number for the log. A note 3510 number MUST NOT be represented by multiple note logs in the note list. 3512 The 7-bit VELOCITY field codes the velocity value for the most recent N- 3513 active NoteOn command for the note number in the session history. 3514 Multiple overlapping NoteOns for a given note number may be coded using 3515 Chapter E, as discussed in Appendix A.7. 3517 VELOCITY is never zero; NoteOn commands with zero velocity are coded as 3518 NoteOff commands in the NoteOff bitfield structure. 3520 The note log does not code the execution time of the NoteOn command. 3521 However, the Y bit codes a hint from the sender about the NoteOn 3522 execution time. The Y bit codes a recommendation to play (Y = 1) or 3523 skip (Y = 0) the NoteOn command recovered from the note log. See 3524 Section 4.2 of [RFC4696] for non-normative guidance on the use of the Y 3525 bit. 3527 Figure A.6.1 shows the NoteOff bitfield structure, as the list of 3528 OFFBITS octets at the end of the chapter. A NoteOff OFFBITS octet codes 3529 NoteOff information for eight consecutive MIDI note numbers, with the 3530 most-significant bit representing the lowest note number. The most- 3531 significant bit of the first OFFBITS octet codes the note number 8*LOW; 3532 the most-significant bit of the last OFFBITS octet codes the note number 3533 8*HIGH. 3535 A set bit codes a NoteOff command for the note number. In the most 3536 efficient coding for the NoteOff bitfield structure, the first and last 3537 octets of the structure contain at least one set bit. Note that Chapter 3538 N does not code NoteOff velocity data. 3540 Note that in the general case, the recovery journal does not code the 3541 relative placement of a NoteOff command and a Change Control command for 3542 controller 64 (Damper Pedal (Sustain)). In many cases, a receiver 3543 processing a loss event may deduce this relative placement from the 3544 history of the stream and thus determine if a NoteOff note is sustained 3545 by the pedal. If such a determination is not possible, receivers SHOULD 3546 err on the side of silencing pedal sustains, as erroneously sustained 3547 notes may produce unpleasant (albeit transient) artifacts. 3549 A.7. Chapter E: MIDI Note Command Extras 3551 Readers may wish to review the Appendix A.1 definition of "N-active 3552 commands" before reading this appendix. In this appendix, a NoteOn 3553 command with a velocity of 0 is considered to be a NoteOff command with 3554 a release velocity value of 64. 3556 Chapter E encodes recovery information about MIDI NoteOn (0x9) and 3557 NoteOff (0x8) command features that rarely appear in MIDI streams. 3558 Receivers use Chapter E to reduce transient artifacts for streams where 3559 several NoteOn commands appear for a note number without an intervening 3560 NoteOff. Receivers also use Chapter E to reduce transient artifacts for 3561 streams that use NoteOff release velocity. Chapter E supplements the 3562 note information coded in Chapter N (Appendix A.6). 3564 Figure A.7.1 shows the format for Chapter E. 3566 0 1 2 3 3567 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 3568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3569 |S| LEN |S| NOTENUM |V| COUNT/VEL |S| NOTENUM | 3570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3571 |V| COUNT/VEL | .... | 3572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3574 Figure A.7.1 -- Chapter E format 3576 The chapter consists of a 1-octet header, followed by a variable-length 3577 list of 2-octet note logs. Appendix A.7.1 defines the bitfield format 3578 for a note log. 3580 The log list MUST contain at least one note log. The 7-bit LEN header 3581 field codes the number of note logs in the list, minus one. A channel 3582 journal MUST contain Chapter E if the rules defined in this appendix 3583 require that one or more note logs appear in the list. The note log 3584 list MUST obey the oldest-first ordering rule (defined in Appendix A.1). 3586 A.7.1. Note Log Format 3588 Figure A.7.2 reproduces the note log structure of Chapter E. 3590 0 1 3591 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 3592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3593 |S| NOTENUM |V| COUNT/VEL | 3594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3596 Figure A.7.2 -- Chapter E note log 3598 A note log codes information about the MIDI note number coded by the 3599 7-bit NOTENUM field. The nature of the information depends on the value 3600 of the V flag bit. 3602 If the V bit is set to 1, the COUNT/VEL field codes the release velocity 3603 value for the most recent N-active NoteOff command for the note number 3604 that appears in the session history. 3606 If the V bit is set to 0, the COUNT/VEL field codes a reference count of 3607 the number of NoteOn and NoteOff commands for the note number that 3608 appear in the session history. 3610 The reference count is set to 0 at the start of the session. NoteOn 3611 commands increment the count by 1. NoteOff commands decrement the count 3612 by 1. However, a decrement that generates a negative count value is not 3613 performed. 3615 If the reference count is in the range 0-126, the 7-bit COUNT/VEL field 3616 codes an unsigned integer representation of the count. If the count is 3617 greater than or equal to 127, COUNT/VEL is set to 127. 3619 By default, the count is reset to 0 whenever a Reset State command 3620 (Appendix A.1) appears in the session history, and whenever MIDI Control 3621 Change commands for controller numbers 123-127 (numbers with All Notes 3622 Off semantics) or 120 (All Sound Off) appear in the session history. 3624 A.7.2. Log Inclusion Rules 3626 If the most recent N-active NoteOn or NoteOff command for a note number 3627 in the checkpoint history is a NoteOff command with a release velocity 3628 value other than 64, a note log whose V bit is set to 1 MUST appear in 3629 Chapter E for the note number. 3631 If the most recent N-active NoteOn or NoteOff command for a note number 3632 in the checkpoint history is a NoteOff command, and if the reference 3633 count for the note number is greater than 0, a note log whose V bit is 3634 set to 0 MUST appear in Chapter E for the note number. 3636 If the most recent N-active NoteOn or NoteOff command for a note number 3637 in the checkpoint history is a NoteOn command, and if the reference 3638 count for the note number is greater than 1, a note log whose V bit is 3639 set to 0 MUST appear in Chapter E for the note number. 3641 At most, two note logs MAY appear in Chapter E for a note number: one 3642 log whose V bit is set to 0, and one log whose V bit is set to 1. 3644 Chapter E codes a maximum of 128 note logs. If the log inclusion rules 3645 yield more than 128 REQUIRED logs, note logs whose V bit is set to 1 3646 MUST be dropped from Chapter E in order to reach the 128-log limit. 3647 Note logs whose V bit is set to 0 MUST NOT be dropped. 3649 Most MIDI streams do not use NoteOn and NoteOff commands in ways that 3650 would trigger the log inclusion rules. For these streams, Chapter E 3651 would never be REQUIRED to appear in a channel journal. 3653 The ch_never parameter (Appendix C.2.3) may be used to configure the log 3654 inclusion rules for Chapter E. 3656 A.8. Chapter T: MIDI Channel Aftertouch 3658 A channel journal MUST contain Chapter T if an N-active and C-active 3659 MIDI Channel Aftertouch (0xD) command appears in the checkpoint history. 3660 Figure A.8.1 shows the format for Chapter T. 3662 0 3663 0 1 2 3 4 5 6 7 3664 +-+-+-+-+-+-+-+-+ 3665 |S| PRESSURE | 3666 +-+-+-+-+-+-+-+-+ 3668 Figure A.8.1 -- Chapter T format 3670 The chapter has a fixed size of 8 bits. The 7-bit PRESSURE field holds 3671 the pressure value of the most recent N-active and C-active Channel 3672 Aftertouch command in the session history. 3674 Chapter T only encodes commands that are C-active and N-active. We 3675 define a C-active restriction because [RP015] declares that a Control 3676 Change command for controller 121 (Reset All Controllers) acts to reset 3677 the channel pressure to 0 (see the discussion at the end of Appendix A.5 3678 for a more complete rationale). 3680 We define an N-active restriction on the assumption that aftertouch 3681 commands are linked to note activity, and thus Channel Aftertouch 3682 commands that are not N-active are stale and should not be used to 3683 repair a stream. 3685 A.9. Chapter A: MIDI Poly Aftertouch 3687 A channel journal MUST contain Chapter A if a C-active Poly Aftertouch 3688 (0xA) command appears in the checkpoint history. Figure A.9.1 shows the 3689 format for Chapter A. 3691 0 1 2 3 3692 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 3693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3694 |S| LEN |S| NOTENUM |X| PRESSURE |S| NOTENUM | 3695 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3696 |X| PRESSURE | .... | 3697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3699 Figure A.9.1 -- Chapter A format 3701 The chapter consists of a 1-octet header, followed by a variable-length 3702 list of 2-octet note logs. A note log MUST appear for a note number if 3703 a C-active Poly Aftertouch command for the note number appears in the 3704 checkpoint history. A note number MUST NOT be represented by multiple 3705 note logs in the note list. The note log list MUST obey the oldest- 3706 first ordering rule (defined in Appendix A.1). 3708 The 7-bit LEN field codes the number of note logs in the list, minus 3709 one. Figure A.9.2 reproduces the note log structure of Chapter A. 3711 0 1 3712 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 3713 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3714 |S| NOTENUM |X| PRESSURE | 3715 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3717 Figure A.9.2 -- Chapter A note log 3719 The 7-bit PRESSURE field codes the pressure value of the most recent C- 3720 active Poly Aftertouch command in the session history for the MIDI note 3721 number coded in the 7-bit NOTENUM field. 3723 As a rule, the X bit MUST be set to 0. However, the X bit MUST be set 3724 to 1 if the command coded by the log appears before one of the following 3725 commands in the session history: MIDI Control Change numbers 123-127 3726 (numbers with All Notes Off semantics) or 120 (All Sound Off). 3728 We define C-active restrictions for Chapter A because [RP015] declares 3729 that a Control Change command for controller 121 (Reset All Controllers) 3730 acts to reset the polyphonic pressure to 0 (see the discussion at the 3731 end of Appendix A.5 for a more complete rationale). 3733 B. The Recovery Journal System Chapters 3735 B.1. System Chapter D: Simple System Commands 3737 The system journal MUST contain Chapter D if an active MIDI Reset 3738 (0xFF), MIDI Tune Request (0xF6), MIDI Song Select (0xF3), undefined 3739 MIDI System Common (0xF4 and 0xF5), or undefined MIDI System Real-time 3740 (0xF9 and 0xFD) command appears in the checkpoint history. 3742 Figure B.1.1 shows the variable-length format for Chapter D. 3744 0 1 2 3 3745 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 3746 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3747 |S|B|G|H|J|K|Y|Z| Command logs ... | 3748 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3750 Figure B.1.1 -- System Chapter D format 3752 The chapter consists of a 1-octet header, followed by one or more 3753 command logs. Header flag bits indicate the presence of command logs 3754 for the Reset (B = 1), Tune Request (G = 1), Song Select (H = 1), 3755 undefined System Common 0xF4 (J = 1), undefined System Common 0xF5 (K = 3756 1), undefined System Real-time 0xF9 (Y = 1), or undefined System Real- 3757 time 0xFD (Z = 1) commands. 3759 Command logs appear in a list following the header, in the order that 3760 the flag bits appear in the header. 3762 Figure B.1.2 shows the 1-octet command log format for the Reset and Tune 3763 Request commands. 3765 0 3766 0 1 2 3 4 5 6 7 3767 +-+-+-+-+-+-+-+-+ 3768 |S| COUNT | 3769 +-+-+-+-+-+-+-+-+ 3771 Figure B.1.2 -- Command log for Reset and Tune Request 3773 Chapter D MUST contain the Reset command log if an active Reset command 3774 appears in the checkpoint history. The 7-bit COUNT field codes the 3775 total number of Reset commands (modulo 128) present in the session 3776 history. 3778 Chapter D MUST contain the Tune Request command log if an active Tune 3779 Request command appears in the checkpoint history. The 7-bit COUNT 3780 field codes the total number of Tune Request commands (modulo 128) 3781 present in the session history. 3783 For these commands, the COUNT field acts as a reference count. See the 3784 definition of "session history reference counts" in Appendix A.1 for 3785 more information. 3787 Figure B.1.3 shows the 1-octet command log format for the Song Select 3788 command. 3790 0 3791 0 1 2 3 4 5 6 7 3792 +-+-+-+-+-+-+-+-+ 3793 |S| VALUE | 3794 +-+-+-+-+-+-+-+-+ 3796 Figure B.1.3 -- Song Select command log format 3798 Chapter D MUST contain the Song Select command log if an active Song 3799 Select command appears in the checkpoint history. The 7-bit VALUE field 3800 codes the song number of the most recent active Song Select command in 3801 the session history. 3803 B.1.1. Undefined System Commands 3805 In this section, we define the Chapter D command logs for the undefined 3806 System commands. [MIDI] reserves the undefined System commands 0xF4, 3807 0xF5, 0xF9, and 0xFD for future use. At the time of this writing, any 3808 MIDI command stream that uses these commands is non-compliant with 3809 [MIDI]. However, future versions of [MIDI] may define these commands, 3810 and a few products do use these commands in a non-compliant manner. 3812 Figure B.1.4 shows the variable-length command log format for the 3813 undefined System Common commands (0xF4 and 0xF5). 3815 0 1 2 3 3816 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 3817 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3818 |S|C|V|L|DSZ| LENGTH | COUNT | VALUE ... | 3819 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3820 | LEGAL ... | 3821 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3823 Figure B.1.4 -- Undefined System Common command log format 3825 The command log codes a single command type (0xF4 or 0xF5, not both). 3826 Chapter D MUST contain a command log if an active 0xF4 command appears 3827 in the checkpoint history and MUST contain an independent command log if 3828 an active 0xF5 command appears in the checkpoint history. 3830 A Chapter D Undefined System Common command log consists of a two-octet 3831 header followed by a variable number of data fields. Header flag bits 3832 indicate the presence of the COUNT field (C = 1), the VALUE field (V = 3833 1), and the LEGAL field (L = 1). The 10-bit LENGTH field codes the size 3834 of the command log and conforms to semantics described in Appendix A.1. 3836 The 2-bit DSZ field codes the number of data octets in the command 3837 instance that appears most recently in the session history. If DSZ = 3838 0-2, the command has 0-2 data octets. If DSZ = 3, the command has 3 or 3839 more command data octets. 3841 We now define the default rules for the use of the COUNT, VALUE, and 3842 LEGAL fields. The session configuration tools defined in Appendix C.2.3 3843 may be used to override this behavior. 3845 By default, if the DSZ field is set to 0, the command log MUST include 3846 the COUNT field. The 8-bit COUNT field codes the total number of 3847 commands of the type coded by the log (0xF4 or 0xF5) present in the 3848 session history, modulo 256. 3850 By default, if the DSZ field is set to 1-3, the command log MUST include 3851 the VALUE field. The variable-length VALUE field codes a verbatim copy 3852 the data octets for the most recent use of the command type coded by the 3853 log (0xF4 or 0xF5) in the session history. The most-significant bit of 3854 the final data octet MUST be set to 1, and the most-significant bit of 3855 all other data octets MUST be set to 0. 3857 The LEGAL field is reserved for future use. If an update to [MIDI] 3858 defines the 0xF4 or 0xF5 command, an IETF standards-track document may 3859 define the LEGAL field. Until such a document appears, senders MUST NOT 3860 use the LEGAL field, and receivers MUST use the LENGTH field to skip 3861 over the LEGAL field. The LEGAL field would be defined by the IETF if 3862 the semantics of the new 0xF4 or 0xF5 command could not be protected 3863 from packet loss via the use of the COUNT and VALUE fields. 3865 Figure B.1.5 shows the variable-length command log format for the 3866 undefined System Real-time commands (0xF9 and 0xFD). 3868 0 1 2 3 3869 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 3870 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3871 |S|C|L| LENGTH | COUNT | LEGAL ... | 3872 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3874 Figure B.1.5 -- Undefined System Real-time command log format 3876 The command log codes a single command type (0xF9 or 0xFD, not both). 3877 Chapter D MUST contain a command log if an active 0xF9 command appears 3878 in the checkpoint history and MUST contain an independent command log if 3879 an active 0xFD command appears in the checkpoint history. 3881 A Chapter D Undefined System Real-time command log consists of a one- 3882 octet header followed by a variable number of data fields. Header flag 3883 bits indicate the presence of the COUNT field (C = 1) and the LEGAL 3884 field (L = 1). The 5-bit LENGTH field codes the size of the command log 3885 and conforms to semantics described in Appendix A.1. 3887 We now define the default rules for the use of the COUNT and LEGAL 3888 fields. The session configuration tools defined in Appendix C.2.3 may 3889 be used to override this behavior. 3891 The 8-bit COUNT field codes the total number of commands of the type 3892 coded by the log present in the session history, modulo 256. By 3893 default, the COUNT field MUST be present in the command log. 3895 The LEGAL field is reserved for future use. If an update to [MIDI] 3896 defines the 0xF9 or 0xFD command, an IETF standards-track document may 3897 define the LEGAL field to protect the command. Until such a document 3898 appears, senders MUST NOT use the LEGAL field, and receivers MUST use 3899 the LENGTH field to skip over the LEGAL field. The LEGAL field would be 3900 defined by the IETF if the semantics of the new 0xF9 or 0xFD command 3901 could not be protected from packet loss via the use of the COUNT field. 3903 Finally, we note that some non-standard uses of the undefined System 3904 Real-time commands act to implement non-compliant variants of the MIDI 3905 sequencer system. In Appendix B.3.1, we describe resiliency tools for 3906 the MIDI sequencer system that provide some protection in this case. 3908 B.2. System Chapter V: Active Sense Command 3910 The system journal MUST contain Chapter V if an active MIDI Active Sense 3911 (0xFE) command appears in the checkpoint history. Figure B.2.1 shows 3912 the format for Chapter V. 3914 0 3915 0 1 2 3 4 5 6 7 3916 +-+-+-+-+-+-+-+-+ 3917 |S| COUNT | 3918 +-+-+-+-+-+-+-+-+ 3920 Figure B.2.1 -- System Chapter V format 3922 The 7-bit COUNT field codes the total number of Active Sense commands 3923 (modulo 128) present in the session history. The COUNT field acts as a 3924 reference count. See the definition of "session history reference 3925 counts" in Appendix A.1 for more information. 3927 B.3. System Chapter Q: Sequencer State Commands 3929 This appendix describes Chapter Q, the system chapter for the MIDI 3930 sequencer commands. 3932 The system journal MUST contain Chapter Q if an active MIDI Song 3933 Position Pointer (0xF2), MIDI Clock (0xF8), MIDI Start (0xFA), MIDI 3934 Continue (0xFB), or MIDI Stop (0xFC) command appears in the checkpoint 3935 history, and if the rules defined in this appendix require a change in 3936 the Chapter Q bitfield contents because of the command appearance. 3938 Figure B.3.1 shows the variable-length format for Chapter Q. 3940 0 1 2 3 3941 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 3942 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3943 |S|N|D|C|T| TOP | CLOCK | TIMETOOLS ... | 3944 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3945 | ... | 3946 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3948 Figure B.3.1 -- System Chapter Q format 3950 Chapter Q consists of a 1-octet header followed by several optional 3951 fields, in the order shown in Figure B.3.1. 3953 Header flag bits signal the presence of the 16-bit CLOCK field (C = 1) 3954 and the 24-bit TIMETOOLS field (T = 1). The 3-bit TOP header field is 3955 interpreted as an unsigned integer, as are CLOCK and TIMETOOLS. We 3956 describe the TIMETOOLS field in Appendix B.3.1. 3958 Chapter Q encodes the most recent state of the sequencer system. 3959 Receivers use the chapter to re-synchronize the sequencer after a packet 3960 loss episode. Chapter fields encode the on/off state of the sequencer, 3961 the current position in the song, and the downbeat. 3963 The N header bit encodes the relative occurrence of the Start, Stop, and 3964 Continue commands in the session history. If an active Start or 3965 Continue command appears most recently, the N bit MUST be set to 1. If 3966 an active Stop appears most recently, or if no active Start, Stop, or 3967 Continue commands appear in the session history, the N bit MUST be set 3968 to 0. 3970 The C header flag, the TOP header field, and the CLOCK field act to code 3971 the current position in the sequence: 3973 o If C = 1, the 3-bit TOP header field and the 16-bit 3974 CLOCK field are combined to form the 19-bit unsigned quantity 3975 65536*TOP + CLOCK. This value encodes the song position 3976 in units of MIDI Clocks (24 clocks per quarter note), 3977 modulo 524288. Note that the maximum song position value 3978 that may be coded by the Song Position Pointer command is 3979 98303 clocks (which may be coded with 17 bits), and that 3980 MIDI-coded songs are generally constructed to avoid durations 3981 longer than this value. However, the 19-bit size may be useful 3982 for real-time applications, such as a drum machine MIDI output 3983 that is sending clock commands for long periods of time. 3985 o If C = 0, the song position is the start of the song. 3986 The C = 0 position is identical to the position coded 3987 by C = 1, TOP = 0, and CLOCK = 0, for the case where 3988 the song position is less than 524288 MIDI clocks. 3989 In certain situations (defined later in this section), 3990 normative text may require the C = 0 or the C = 1, 3991 TOP = 0, CLOCK = 0 encoding of the start of the song. 3993 The C, TOP, and CLOCK fields MUST be set to code the current song 3994 position, for both N = 0 and N = 1 conditions. If C = 0, the TOP field 3995 MUST be set to 0. See [MIDI] for a precise definition of a song 3996 position. 3998 The D header bit encodes information about the downbeat and acts to 3999 qualify the song position coded by the C, TOP, and CLOCK fields. 4001 If the D bit is set to 1, the song position represents the most recent 4002 position in the sequence that has played. If D = 1, the next Clock 4003 command (if N = 1) or the next (Continue, Clock) pair (if N = 0) acts to 4004 increment the song position by one clock, and to play the updated 4005 position. 4007 If the D bit is set to 0, the song position represents a position in the 4008 sequence that has not yet been played. If D = 0, the next Clock command 4009 (if N = 1) or the next (Continue, Clock) pair (if N = 0) acts to play 4010 the point in the song coded by the song position. The song position is 4011 not incremented. 4013 An example of a stream that uses D = 0 coding is one whose most recent 4014 sequence command is a Start or Song Position Pointer command (both N = 1 4015 conditions). However, it is also possible to construct examples where D 4016 = 0 and N = 0. A Start command immediately followed by a Stop command 4017 is coded in Chapter Q by setting C = 0, D = 0, N = 0, TOP = 0. 4019 If N = 1 (coding Start or Continue), D = 0 (coding that the downbeat has 4020 yet to be played), and the song position is at the start of the song, 4021 the C = 0 song position encoding MUST be used if a Start command occurs 4022 more recently than a Continue command in the session history, and the C 4023 = 1, TOP = 0, CLOCK = 0 song position encoding MUST be used if a 4024 Continue command occurs more recently than a Start command in the 4025 session history. 4027 B.3.1. Non-compliant Sequencers 4029 The Chapter Q description in this appendix assumes that the sequencer 4030 system counts off time with Clock commands, as mandated in [MIDI]. 4031 However, a few non-compliant products do not use Clock commands to count 4032 off time, but instead use non-standard methods. 4034 Chapter Q uses the TIMETOOLS field to provide resiliency support for 4035 these non-standard products. By default, the TIMETOOLS field MUST NOT 4036 appear in Chapter Q, and the T header bit MUST be set to 0. The session 4037 configuration tools described in Appendix C.2.3 may be used to select 4038 TIMETOOLS coding. 4040 Figure B.3.2 shows the format of the 24-bit TIMETOOLS field. 4042 0 1 2 4043 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4044 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4045 | TIME | 4046 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4048 Figure B.3.2 -- TIMETOOLS format 4050 The TIME field is a 24-bit unsigned integer quantity, with units of 4051 milliseconds. TIME codes an additive correction term for the song 4052 position coded by the TOP, CLOCK, and C fields. TIME is coded in 4053 network byte order (big-endian). 4055 A receiver computes the correct song position by converting TIME into 4056 units of MIDI clocks and adding it to 65536*TOP + CLOCK (assuming C = 4057 1). Alternatively, a receiver may convert 65536*TOP + CLOCK into 4058 milliseconds (assuming C = 1) and add it to TIME. The downbeat (D 4059 header bit) semantics defined in Appendix B.3 apply to the corrected 4060 song position. 4062 B.4. System Chapter F: MIDI Time Code Tape Position 4064 This appendix describes Chapter F, the system chapter for the MIDI Time 4065 Code (MTC) commands. Readers may wish to review the Appendix A.1 4066 definition of "finished/unfinished commands" before reading this 4067 appendix. 4069 The system journal MUST contain Chapter F if an active System Common 4070 Quarter Frame command (0xF1) or an active finished System Exclusive 4071 (Universal Real Time) MTC Full Frame command (F0 7F cc 01 01 hr mn sc fr 4072 F7) appears in the checkpoint history. Otherwise, the system journal 4073 MUST NOT contain Chapter F. 4075 Figure B.4.1 shows the variable-length format for Chapter F. 4077 0 1 2 3 4078 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 4079 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4080 |S|C|P|Q|D|POINT| COMPLETE ... | 4081 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4082 | ... | PARTIAL ... | 4083 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4084 | ... | 4085 +-+-+-+-+-+-+-+-+ 4087 Figure B.4.1 -- System Chapter F format 4089 Chapter F holds information about recent MTC tape positions coded in the 4090 session history. Receivers use Chapter F to re-synchronize the MTC 4091 system after a packet loss episode. 4093 Chapter F consists of a 1-octet header followed by several optional 4094 fields, in the order shown in Figure B.4.1. The C and P header bits 4095 form a Table of Contents (TOC) and signal the presence of the 32-bit 4096 COMPLETE field (C = 1) and the 32-bit PARTIAL field (P = 1). 4098 The Q header bit codes information about the COMPLETE field format. If 4099 Chapter F does not contain a COMPLETE field, Q MUST be set to 0. 4101 The D header bit codes the tape movement direction. If the tape is 4102 moving forward, or if the tape direction is indeterminate, the D bit 4103 MUST be set to 0. If the tape is moving in the reverse direction, the D 4104 bit MUST be set to 1. In most cases, the ordering of commands in the 4105 session history clearly defines the tape direction. However, a few 4106 command sequences have an indeterminate direction (such as a session 4107 history consisting of one Full Frame command). 4109 The 3-bit POINT header field is interpreted as an unsigned integer. 4110 Appendix B.4.1 defines how the POINT field codes information about the 4111 contents of the PARTIAL field. If Chapter F does not contain a PARTIAL 4112 field, POINT MUST be set to 7 (if D = 0) or 0 (if D = 1). 4114 Chapter F MUST include the COMPLETE field if an active finished Full 4115 Frame command appears in the checkpoint history, or if an active Quarter 4116 Frame command that completes the encoding of a frame value appears in 4117 the checkpoint history. 4119 The COMPLETE field encodes the most recent active complete MTC frame 4120 value that appears in the session history. This frame value may take 4121 the form of a series of 8 active Quarter Frame commands (0xF1 0x0n 4122 through 0xF1 0x7n for forward tape movement, 0xF1 0x7n through 0xF1 0x0n 4123 for reverse tape movement) or may take the form of an active finished 4124 Full Frame command. 4126 If the COMPLETE field encodes a Quarter Frame command series, the Q 4127 header bit MUST be set to 1, and the COMPLETE field MUST have the format 4128 shown in Figure B.4.2. The 4-bit fields MT0 through MT7 code the data 4129 (lower) nibble for the Quarter Frame commands for Message Type 0 through 4130 Message Type 7 [MIDI]. These nibbles encode a complete frame value, in 4131 addition to fields reserved for future use by [MIDI]. 4133 0 1 2 3 4134 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 4135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4136 | MT0 | MT1 | MT2 | MT3 | MT4 | MT5 | MT6 | MT7 | 4137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4139 Figure B.4.2 -- COMPLETE field format, Q = 1 4141 In this usage, the frame value encoded in the COMPLETE field MUST be 4142 offset by 2 frames (relative to the frame value encoded in the Quarter 4143 Frame commands) if the frame value codes a 0xF1 0x0n through 0xF1 0x7n 4144 command sequence. This offset compensates for the two-frame latency of 4145 the Quarter Frame encoding for forward tape movement. No offset is 4146 applied if the frame value codes a 0xF1 0x7n through 0xF1 0x0n Quarter 4147 Frame command sequence. 4149 The most recent active complete MTC frame value may alternatively be 4150 encoded by an active finished Full Frame command. In this case, the Q 4151 header bit MUST be set to 0, and the COMPLETE field MUST have format 4152 shown in Figure B.4.3. The HR, MN, SC, and FR fields correspond to the 4153 hr, mn, sc, and fr data octets of the Full Frame command. 4155 0 1 2 3 4156 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 4157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4158 | HR | MN | SC | FR | 4159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4161 Figure B.4.3 -- COMPLETE field format, Q = 0 4163 B.4.1. Partial Frames 4165 The most recent active session history command that encodes MTC frame 4166 value data may be a Quarter Frame command other than a forward-moving 4167 0xF1 0x7n command (which completes a frame value for forward tape 4168 movement) or a reverse-moving 0xF1 0x1n command (which completes a frame 4169 value for reverse tape movement). 4171 We consider this type of Quarter Frame command to be associated with a 4172 partial frame value. The Quarter Frame sequence that defines a partial 4173 frame value MUST either start at Message Type 0 and increment 4174 contiguously to an intermediate Message Type less than 7, or start at 4175 Message Type 7 and decrement contiguously to an intermediate Message 4176 type greater than 0. A Quarter Frame command sequence that does not 4177 follow this pattern is not associated with a partial frame value. 4179 Chapter F MUST include a PARTIAL field if the most recent active command 4180 in the checkpoint history that encodes MTC frame value data is a Quarter 4181 Frame command that is associated with a partial frame value. Otherwise, 4182 Chapter F MUST NOT include a PARTIAL field. 4184 The partial frame value consists of the data (lower) nibbles of the 4185 Quarter Frame command sequence. The PARTIAL field codes the partial 4186 frame value, using the format shown in Figure B.4.2. Message Type 4187 fields that are not associated with a Quarter Frame command MUST be set 4188 to 0. 4190 The POINT header field identifies the Message Type fields in the PARTIAL 4191 field that code valid data. If P = 1, the POINT field MUST encode the 4192 unsigned integer value formed by the lower 3 bits of the upper nibble of 4193 the data value of the most recent active Quarter Frame command in the 4194 session history. If D = 0 and P = 1, POINT MUST take on a value in the 4195 range 0-6. If D = 1 and P = 1, POINT MUST take on a value in the range 4196 1-7. 4198 If D = 0, MT fields (Figure B.4.2) in the inclusive range from 0 up to 4199 and including the POINT value encode the partial frame value. If D = 1, 4200 MT fields in the inclusive range from 7 down to and including the POINT 4201 value encode the partial frame value. Note that, unlike the COMPLETE 4202 field encoding, senders MUST NOT add a 2-frame offset to the partial 4203 frame value encoded in PARTIAL. 4205 For the default semantics, if a recovery journal contains Chapter F, and 4206 if the session history codes a legal [MIDI] series of Quarter Frame and 4207 Full Frame commands, the chapter always contains a COMPLETE or a PARTIAL 4208 field (and may contain both fields). Thus, a one-octet Chapter F (C = P 4209 = 0) always codes the presence of an illegal command sequence in the 4210 session history (under some conditions, the C = 1, P = 0 condition may 4211 also code the presence of an illegal command sequence). The illegal 4212 command sequence conditions are transient in nature and usually indicate 4213 that a Quarter Frame command sequence began with an intermediate Message 4214 Type. 4216 B.5. System Chapter X: System Exclusive 4218 This appendix describes Chapter X, the system chapter for MIDI System 4219 Exclusive (SysEx) commands (0xF0). Readers may wish to review the 4220 Appendix A.1 definition of "finished/unfinished commands" before reading 4221 this appendix. 4223 Chapter X consists of a list of one or more command logs. Each log in 4224 the list codes information about a specific finished or unfinished SysEx 4225 command that appears in the session history. The system journal MUST 4226 contain Chapter X if the rules defined in Appendix B.5.2 require that 4227 one or more logs appear in the list. 4229 The log list is not preceded by a header. Instead, each log implicitly 4230 encodes its own length. Given the length of the N'th list log, the 4231 presence of the (N+1)'th list log may be inferred from the LENGTH field 4232 of the system journal header (Figure 10 in Section 5 of the main text). 4233 The log list MUST obey the oldest-first ordering rule (defined in 4234 Appendix A.1). 4236 B.5.1. Chapter Format 4238 Figure B.5.1 shows the bitfield format for the Chapter X command logs. 4240 0 1 2 3 4241 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 4242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4243 |S|T|C|F|D|L|STA| TCOUNT | COUNT | FIRST ... | 4244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4245 | DATA ... | 4246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4248 Figure B.5.1 -- Chapter X command log format 4250 A Chapter X command log consists of a 1-octet header, followed by the 4251 optional TCOUNT, COUNT, FIRST, and DATA fields. 4253 The T, C, F, and D header bits act as a Table of Contents (TOC) for the 4254 log. If T is set to 1, the 1-octet TCOUNT field appears in the log. If 4255 C is set to 1, the 1-octet COUNT field appears in the log. If F is set 4256 to 1, the variable-length FIRST field appears in the log. If D is set 4257 to 1, the variable-length DATA field appears in the log. 4259 The L header bit sets the coding tool for the log. We define the log 4260 coding tools in Appendix B.5.2. 4262 The STA field codes the status of the command coded by the log. The 4263 2-bit STA value is interpreted as an unsigned integer. If STA is 0, the 4264 log codes an unfinished command. Non-zero STA values code different 4265 classes of finished commands. An STA value of 1 codes a cancelled 4266 command, an STA value of 2 codes a command that uses the "dropped F7" 4267 construction, and an STA value of 3 codes all other finished commands. 4268 Section 3.2 in the main text describes cancelled and "dropped F7" 4269 commands. 4271 The S bit (Appendix A.1) of the first log in the list acts as the S bit 4272 for Chapter X. For the other logs in the list, the S bit refers to the 4273 log itself. The value of the "phantom" S bit associated with the first 4274 log is defined by the following rules: 4276 o If the list codes one log, the phantom S-bit value is 4277 the same as the Chapter X S-bit value. 4279 o If the list codes multiple logs, the phantom S-bit value is 4280 the logical OR of the S-bit value of the first and second 4281 command logs in the list. 4283 In all other respects, the S bit follows the semantics defined in 4284 Appendix A.1. 4286 The FIRST field (present if F = 1) encodes a variable-length unsigned 4287 integer value that sets the coverage of the DATA field. 4289 The FIRST field (present if F = 1) encodes a variable-length unsigned 4290 integer value that specifies which SysEx data bytes are encoded in the 4291 DATA field of the log. The FIRST field consists of an octet whose most- 4292 significant bit is set to 0, optionally preceded by one or more octets 4293 whose most-significant bit is set to 1. The algorithm shown in Figure 4294 B.5.2 decodes this format into an unsigned integer, to yield the value 4295 dec(FIRST). FIRST uses a variable-length encoding because dec(FIRST) 4296 references a data octet in a SysEx command, and a SysEx command may 4297 contain an arbitrary number of data octets. 4299 One-Octet FIRST value: 4301 Encoded form: 0ddddddd 4302 Decoded form: 00000000 00000000 00000000 0ddddddd 4304 Two-Octet FIRST value: 4306 Encoded form: 1ccccccc 0ddddddd 4307 Decoded form: 00000000 00000000 00cccccc cddddddd 4309 Three-Octet FIRST value: 4311 Encoded form: 1bbbbbbb 1ccccccc 0ddddddd 4312 Decoded form: 00000000 000bbbbb bbcccccc cddddddd 4314 Four-Octet FIRST value: 4316 Encoded form: 1aaaaaaa 1bbbbbbb 1ccccccc 0ddddddd 4317 Decoded form: 0000aaaa aaabbbbb bbcccccc cddddddd 4319 Figure B.5.2 -- Decoding FIRST field formats 4321 The DATA field (present if D = 1) encodes a modified version of the data 4322 octets of the SysEx command coded by the log. Status octets MUST NOT be 4323 coded in the DATA field. 4325 If F = 0, the DATA field begins with the first data octet of the SysEx 4326 command and includes all subsequent data octets for the command that 4327 appear in the session history. If F = 1, the DATA field begins with the 4328 (dec(FIRST) + 1)'th data octet of the SysEx command and includes all 4329 subsequent data octets for the command that appear in the session 4330 history. Note that the word "command" in the descriptions above refers 4331 to the original SysEx command as it appears in the source MIDI data 4332 stream, not to a particular MIDI list SysEx command segment. 4334 The length of the DATA field is coded implicitly, using the most- 4335 significant bit of each octet. The most-significant bit of the final 4336 octet of the DATA field MUST be set to 1. The most-significant bit of 4337 all other DATA octets MUST be set to 0. This coding method relies on 4338 the fact that the most-significant bit of a MIDI data octet is 0 by 4339 definition. Apart from this length-coding modification, the DATA field 4340 encodes a verbatim copy of all data octets it encodes. 4342 B.5.2. Log Inclusion Semantics 4344 Chapter X offers two tools to protect SysEx commands: the "recency" tool 4345 and the "list" tool. The tool definitions use the concept of the "SysEx 4346 type" of a command, which we now define. 4348 Each SysEx command instance in a session, excepting MTC Full Frame 4349 commands, is said to have a "SysEx type". Types are used in equality 4350 comparisons: two SysEx commands in a session are said to have "the same 4351 SysEx type" or "different SysEx types". 4353 If efficiency is not a concern, a sender may follow a simple typing 4354 rule: every SysEx command in the session history has a different SysEx 4355 type, and thus no two commands in the session have the same type. 4357 To improve efficiency, senders MAY implement exceptions to this rule. 4358 These exceptions declare that certain sets of SysEx command instances 4359 have the same SysEx type. Any command not covered by an exception 4360 follows the simple rule. We list exceptions below: 4362 o All commands with identical data octet fields (same number of 4363 data octets, same value for each data octet) have the same type. 4364 This rule MUST be applied to all SysEx commands in the session, 4365 or not at all. Note that the implementation of this exception 4366 requires no sender knowledge of the format and semantics of 4367 the SysEx commands in the stream, merely the ability to count 4368 and compare octets. 4370 o Two instances of the same command whose semantics set or report 4371 the value of the same "parameter" have the same type. The 4372 implementation of this exception requires specific knowledge of 4373 the format and semantics of SysEx commands. In practice, a 4374 sender implementation chooses to support this exception for 4375 certain classes of commands (such as the Universal System 4376 Exclusive commands defined in [MIDI]). If a sender supports 4377 this exception for a particular command in a class (for 4378 example, the Universal Real Time System Exclusive message 4379 for Master Volume, F0 F7 cc 04 01 vv vv F7, defined in [MIDI]), 4380 it MUST support the exception to all instances of this 4381 particular command in the session. 4383 We now use this definition of "SysEx type" to define the "recency" tool 4384 and the "list" tool for Chapter X. 4386 By default, the Chapter X log list MUST code sufficient information to 4387 protect the rendered MIDI performance from indefinite artifacts caused 4388 by the loss of all finished or unfinished active SysEx commands that 4389 appear in the checkpoint history (excluding finished MTC Full Frame 4390 commands, which are coded in Chapter F (Appendix B.4)). 4392 To protect a command of a specific SysEx type with the recency tool, 4393 senders MUST code a log in the log list for the most recent finished 4394 active instance of the SysEx type that appears in the checkpoint 4395 history. Additionally, if an unfinished active instance of the SysEx 4396 type appears in the checkpoint history, senders MUST code a log in the 4397 log list for the unfinished command instance. The L header bit of both 4398 command logs MUST be set to 0. 4400 To protect a command of a specific SysEx type with the list tool, 4401 senders MUST code a log in the Chapter X log list for each finished or 4402 unfinished active instance of the SysEx type that appears in the 4403 checkpoint history. The L header bit of list tool command logs MUST be 4404 set to 1. 4406 As a rule, a log REQUIRED by the list or recency tool MUST include a 4407 DATA field that codes all data octets that appear in the checkpoint 4408 history for the SysEx command instance associated with the log. The 4409 FIRST field MAY be used to configure a DATA field that minimally meets 4410 this requirement. 4412 An exception to this rule applies to cancelled commands (defined in 4413 Section 3.2). REQUIRED command logs associated with cancelled commands 4414 MAY be coded with no DATA field. However, if DATA appears in the log, 4415 DATA MUST code all data octets that appear in the checkpoint history for 4416 the command associated with the log. 4418 As defined by the preceding text in this section, by default all 4419 finished or unfinished active SysEx commands that appear in the 4420 checkpoint history (excluding finished MTC Full Frame commands) MUST be 4421 protected by the list tool or the recency tool. 4423 For some MIDI source streams, this default yields a Chapter X whose size 4424 is too large. For example, imagine that a sender begins to transcode a 4425 SysEx command with 10,000 data octets onto a UDP RTP stream "on the 4426 fly", by sending SysEx command segments as soon as data octets are 4427 delivered by the MIDI source. After 1000 octets have been sent, the 4428 expansion of Chapter X yields an RTP packet that is too large to fit in 4429 the Maximum Transmission Unit (MTU) for the stream. 4431 In this situation, if a sender uses the closed-loop sending policy for 4432 SysEx commands, the RTP packet size may always be capped by stalling the 4433 stream. In a stream stall, once the packet reaches a maximum size, the 4434 sender refrains from sending new packets with non-empty MIDI Command 4435 Sections until receiver feedback permits the trimming of Chapter X. If 4436 the stream permits arbitrary commands to appear between SysEx segments 4437 (selectable during configuration using the tools defined in Appendix 4438 C.1), the sender may stall the SysEx segment stream but continue to code 4439 other commands in the MIDI list. 4441 Stalls are a workable but sub-optimal solution to Chapter X size issues. 4442 As an alternative to stalls, senders SHOULD take preemptive action 4443 during session configuration to reduce the anticipated size of Chapter 4444 X, using the methods described below: 4446 o Partitioned transport. Appendix C.5 provides tools 4447 for sending a MIDI name space over several RTP streams. 4448 Senders may use these tools to map a MIDI source 4449 into a low-latency UDP RTP stream (for channel commands 4450 and short SysEx commands) and a reliable [RFC4571] TCP stream 4451 (for bulk-data SysEx commands). The cm_unused and 4452 cm_used parameters (Appendix C.1) may be used to 4453 communicate the nature of the SysEx command partition. 4454 As TCP is reliable, the RTP MIDI TCP stream would not 4455 use the recovery journal. To minimize transmission 4456 latency for short SysEx commands, senders may begin 4457 segmental transmission for all SysEx commands over the 4458 UDP stream and then cancel the UDP transmission of long 4459 commands (using tools described in Section 3.2) and 4460 resend the commands over the TCP stream. 4462 o Selective protection. Journal protection may not be 4463 necessary for all SysEx commands in a stream. The 4464 ch_never parameter (Appendix C.2) may be used to 4465 communicate which SysEx commands are excluded from 4466 Chapter X. 4468 B.5.3. TCOUNT and COUNT Fields 4470 If the T header bit is set to 1, the 8-bit TCOUNT field appears in the 4471 command log. If the C header bit is set to 1, the 8-bit COUNT field 4472 appears in the command log. TCOUNT and COUNT are interpreted as 4473 unsigned integers. 4475 The TCOUNT field codes the total number of SysEx commands of the SysEx 4476 type coded by the log that appear in the session history, at the moment 4477 after the (finished or unfinished) command coded by the log enters the 4478 session history. 4480 The COUNT field codes the total number of SysEx commands that appear in 4481 the session history, excluding commands that are excluded from Chapter X 4482 via the ch_never parameter (Appendix C.2), at the moment after the 4483 (finished or unfinished) command coded by the log enters the session 4484 history. 4486 Command counting for TCOUNT and COUNT uses modulo-256 arithmetic. MTC 4487 Full Frame command instances (Appendix B.4) are included in command 4488 counting if the TCOUNT and COUNT definitions warrant their inclusion, as 4489 are cancelled commands (Section 3.2). 4491 Senders use the TCOUNT and COUNT fields to track the identity and (for 4492 TCOUNT) the sequence position of a command instance. Senders MUST use 4493 the TCOUNT or COUNT fields if identity or sequence information is 4494 necessary to protect the command type coded by the log. 4496 If a sender uses the COUNT field in a session, the final command log in 4497 every Chapter X in the stream MUST code the COUNT field. This rule lets 4498 receivers resynchronize the COUNT value after a packet loss. 4500 C. Session Configuration Tools 4502 In Sections 6.1-2 of the main text, we show session descriptions for 4503 minimal native and mpeg4-generic RTP MIDI streams. Minimal streams lack 4504 the flexibility to support some applications. In this appendix, we 4505 describe how to customize stream behavior through the use of the payload 4506 format parameters. 4508 The appendix begins with 6 sections, each devoted to parameters that 4509 affect a particular aspect of stream behavior: 4511 o Appendix C.1 describes the stream subsetting system 4512 (cm_unused and cm_used). 4514 o Appendix C.2 describes the journalling system (ch_anchor, 4515 ch_default, ch_never, j_sec, j_update). 4517 o Appendix C.3 describes MIDI command timestamp semantics 4518 (linerate, mperiod, octpos, tsmode). 4520 o Appendix C.4 describes the temporal duration ("media time") 4521 of an RTP MIDI packet (guardtime, rtp_maxptime, rtp_ptime). 4523 o Appendix C.5 concerns stream description (musicport). 4525 o Appendix C.6 describes MIDI rendering (chanmask, cid, 4526 inline, multimode, render, rinit, subrender, smf_cid, 4527 smf_info, smf_inline, smf_url, url). 4529 The parameters listed above may optionally appear in session 4530 descriptions of RTP MIDI streams. If these parameters are used in an 4531 SDP session description, the parameters appear on an fmtp attribute 4532 line. This attribute line applies to the payload type associated with 4533 the fmtp line. 4535 The parameters listed above add extra functionality ("features") to 4536 minimal RTP MIDI streams. In Appendix C.7, we show how to use these 4537 features to support two classes of applications: content-streaming using 4538 RTSP (Appendix C.7.1) and network musical performance using SIP 4539 (Appendix C.7.2). 4541 The participants in a multimedia session MUST share a common view of all 4542 of the RTP MIDI streams that appear in an RTP session, as defined by a 4543 single media (m=) line. In some RTP MIDI applications, the "common 4544 view" restriction makes it difficult to use sendrecv streams (all 4545 parties send and receive), as each party has its own requirements. For 4546 example, a two-party network musical performance application may wish to 4547 customize the renderer on each host to match the CPU performance of the 4548 host [NMP]. 4550 We solve this problem by using two RTP MIDI streams -- one sendonly, one 4551 recvonly -- in lieu of one sendrecv stream. The data flows in the two 4552 streams travel in opposite directions, to control receivers configured 4553 to use different renderers. In the third example in Appendix C.5, we 4554 show how the musicport parameter may be used to define virtual sendrecv 4555 streams. 4557 As a general rule, the RTP MIDI protocol does not handle parameter 4558 changes during a session well, because the parameters describe 4559 heavyweight or stateful configuration that is not easily changed once a 4560 session has begun. Thus, parties SHOULD NOT expect that parameter 4561 change requests during a session will be accepted by other parties. 4562 However, implementors SHOULD support in-session parameter changes that 4563 are easy to handle (for example, the guardtime parameter defined in 4564 Appendix C.4) and SHOULD be capable of accepting requests for changes of 4565 those parameters, as received by its session management protocol (for 4566 example, re-offers in SIP [RFC3264]). 4568 Appendix D defines the Augmented Backus-Naur Form (ABNF, [RFC5234]) 4569 syntax for the payload parameters. Section 11 provides information to 4570 the Internet Assigned Numbers Authority (IANA) on the media types and 4571 parameters defined in this document. 4573 Appendix C.6.5 defines the media type "audio/asc", a stored object for 4574 initializing mpeg4-generic renderers. As described in Appendix C.6, the 4575 audio/asc media type is assigned to the "rinit" parameter to specify an 4576 initialization data object for the default mpeg4-generic renderer. Note 4577 that RTP stream semantics are not defined for "audio/asc". Therefore, 4578 the "asc" subtype MUST NOT appear on the rtpmap line of a session 4579 description. 4581 C.1. Configuration Tools: Stream Subsetting 4583 As defined in Section 3.2 in the main text, the MIDI list of an RTP MIDI 4584 packet may encode any MIDI command that may legally appear on a MIDI 1.0 4585 DIN cable. 4587 In this appendix, we define two parameters (cm_unused and cm_used) that 4588 modify this default condition, by excluding certain types of MIDI 4589 commands from the MIDI list of all packets in a stream. For example, if 4590 a multimedia session partitions a MIDI name space into two RTP MIDI 4591 streams, the parameters may be used to define which commands appear in 4592 each stream. 4594 In this appendix, we define a simple language for specifying MIDI 4595 command types. If a command type is assigned to cm_unused, the commands 4596 coded by the string MUST NOT appear in the MIDI list. If a command type 4597 is assigned to cm_used, the commands coded by the string MAY appear in 4598 the MIDI list. 4600 The parameter list may code multiple assignments to cm_used and 4601 cm_unused. Assignments have a cumulative effect and are applied in the 4602 order of appearance in the parameter list. A later assignment of a 4603 command type to the same parameter expands the scope of the earlier 4604 assignment. A later assignment of a command type to the opposite 4605 parameter cancels (partially or completely) the effect of an earlier 4606 assignment. 4608 To initialize the stream subsetting system, "implicit" assignments to 4609 cm_unused and cm_used are processed before processing the actual 4610 assignments that appear in the parameter list. The System Common 4611 undefined commands (0xF4, 0xF5) and the System Real-Time Undefined 4612 commands (0xF9, 0xFD) are implicitly assigned to cm_unused. All other 4613 command types are implicitly assigned to cm_used. 4615 Note that the implicit assignments code the default behavior of an RTP 4616 MIDI stream as defined in Section 3.2 in the main text (namely, that all 4617 commands that may legally appear on a MIDI 1.0 DIN cable may appear in 4618 the stream). Also note that assignments of the System Common undefined 4619 commands (0xF4, 0xF5) apply to the use of these commands in the MIDI 4620 source command stream, not the special use of 0xF4 and 0xF5 in SysEx 4621 segment encoding defined in Section 3.2 in the main text. 4623 As a rule, parameter assignments obey the following syntax (see Appendix 4624 D for ABNF): 4626 = [channel list][field list] 4628 The command-type list is mandatory; the channel and field lists are 4629 optional. 4631 The command-type list specifies the MIDI command types for which the 4632 parameter applies. The command-type list is a concatenated sequence of 4633 one or more of the letters (ABCFGHJKMNPQTVWXYZ). The letters code the 4634 following command types: 4636 o A: Poly Aftertouch (0xA) 4637 o B: System Reset (0xFF) 4638 o C: Control Change (0xB) 4639 o F: System Time Code (0xF1) 4640 o G: System Tune Request (0xF6) 4641 o H: System Song Select (0xF3) 4642 o J: System Common Undefined (0xF4) 4643 o K: System Common Undefined (0xF5) 4644 o N: NoteOff (0x8), NoteOn (0x9) 4645 o P: Program Change (0xC) 4646 o Q: System Sequencer (0xF2, 0xF8, 0xFA, 0xFB, 0xFC) 4647 o T: Channel Aftertouch (0xD) 4648 o V: System Active Sense (0xFE) 4649 o W: Pitch Wheel (0xE) 4650 o X: SysEx (0xF0, 0xF7) 4651 o Y: System Real-Time Undefined (0xF9) 4652 o Z: System Real-Time Undefined (0xFD) 4654 In addition to the letters above, the letter M may also appear in the 4655 command-type list. The letter M refers to the MIDI parameter system 4656 (see definition in Appendix A.1 and in [MIDI]). An assignment of M to 4657 cm_unused codes that no RPN or NRPN transactions may appear in the MIDI 4658 list. 4660 Note that if cm_unused is assigned the letter M, Control Change (0xB) 4661 commands for the controller numbers in the standard controller 4662 assignment might still appear in the MIDI list. For an explanation, see 4663 Appendix A.3.4 for a discussion of the "general-purpose" use of 4664 parameter system controller numbers. 4666 In the text below, rules that apply to "MIDI voice channel commands" 4667 also apply to the letter M. 4669 The letters in the command-type list MUST be uppercase and MUST appear 4670 in alphabetical order. Letters other than (ABCFGHJKMNPQTVWXYZ) that 4671 appear in the list MUST be ignored. 4673 For MIDI voice channel commands, the channel list specifies the MIDI 4674 channels for which the parameter applies. If no channel list is 4675 provided, the parameter applies to all MIDI channels (0-15). The 4676 channel list takes the form of a list of channel numbers (0 through 15) 4677 and dash-separated channel number ranges (i.e., 0-5, 8-12, etc.). Dots 4678 (i.e., "." characters) separate elements in the channel list. 4680 Recall that System commands do not have a MIDI channel associated with 4681 them. Thus, for most command-type letters that code System commands (B, 4682 F, G, H, J, K, Q, V, Y, and Z), the channel list is ignored. 4684 For the command-type letter X, the appearance of certain numbers in the 4685 channel list codes special semantics. 4687 o The digit 0 codes that SysEx "cancel" sublists (Section 4688 3.2 in the main text) MUST NOT appear in the MIDI list. 4690 o The digit 1 codes that cancel sublists MAY appear in the 4691 MIDI list (the default condition). 4693 o The digit 2 codes that commands other than System 4694 Real-time MIDI commands MUST NOT appear between SysEx 4695 command segments in the MIDI list (the default condition). 4697 o The digit 3 codes that any MIDI command type may 4698 appear between SysEx command segments in the MIDI list, 4699 with the exception of the segmented encoding of a second 4700 SysEx command (verbatim SysEx commands are OK). 4702 For command-type X, the channel list MUST NOT contain both digits 0 and 4703 1, and it MUST NOT contain both digits 2 and 3. For command-type X, 4704 channel list numbers other than the numbers defined above are ignored. 4705 If X does not have a channel list, the semantics marked "the default 4706 condition" in the list above apply. 4708 The syntax for field lists in a parameter assignment follows the syntax 4709 for channel lists. If no field list is provided, the parameter applies 4710 to all controller or note numbers. 4712 For command-type C (Control Change), the field list codes the controller 4713 numbers (0-255) for which the parameter applies. 4715 For command-type M (Parameter System), the field list codes the 4716 Registered Parameter Numbers (RPNs) and Non-Registered Parameter Numbers 4717 (NRPNs) for which the parameter applies. The number range 0-16383 4718 specifies RPNs, the number range 16384-32767 specifies NRPNs (16384 4719 corresponds to NRPN 0, 32767 corresponds to NRPN 16383). 4721 For command-types N (NoteOn and NoteOff) and A (Poly Aftertouch), the 4722 field list codes the note numbers for which the parameter applies. 4724 For command-types J and K (System Common Undefined), the field list 4725 consists of a single digit, which specifies the number of data octets 4726 that follow the command octet. 4728 For command-type X (SysEx), the field list codes the number of data 4729 octets that may appear in a SysEx command. Thus, the field list 0-255 4730 specifies SysEx commands with 255 or fewer data octets, the field list 4731 256-4294967295 specifies SysEx commands with more than 255 data octets 4732 but excludes commands with 255 or fewer data octets, and the field list 4733 0 excludes all commands. 4735 A secondary parameter assignment syntax customizes command-type X (see 4736 Appendix D for complete ABNF): 4738 = "__" *( "_" ) "__" 4740 The assignment defines the class of SysEx commands that obeys the 4741 semantics of the assigned parameter. The command class is specified by 4742 listing the permitted values of the first N data octets that follow the 4743 SysEx 0xF0 command octet. Any SysEx command whose first N data octets 4744 match the list is a member of the class. 4746 Each defines a data octet of the command, as a dot-separated 4747 (".") list of one or more hexadecimal constants (such as "7F") or dash- 4748 separated hexadecimal ranges (such as "01-1F"). Underscores ("_") 4749 separate each . Double-underscores ("__") delineate the data 4750 octet list. 4752 Using this syntax, each assignment specifies a single SysEx command 4753 class. Session descriptions may use several assignments to cm_used and 4754 cm_unused to specify complex behaviors. 4756 The example session description below illustrates the use of the stream 4757 subsetting parameters: 4759 v=0 4760 o=lazzaro 2520644554 2838152170 IN IP6 first.example.net 4761 s=Example 4762 t=0 0 4763 m=audio 5004 RTP/AVP 96 4764 c=IN IP6 2001:DB8::7F2E:172A:1E24 4765 a=rtpmap:96 rtp-midi/44100 4766 a=fmtp:96 cm_unused=ACGHJKNMPTVWXYZ; cm_used=__7F_00-7F_01_01__ 4768 The session description configures the stream for use in clock 4769 applications. All voice channels are unused, as are all System Commands 4770 except those used for MIDI Time Code (command-type F, and the Full Frame 4771 SysEx command that is matched by the string assigned to cm_used), the 4772 System Sequencer commands (command-type Q), and System Reset (command- 4773 type B). 4775 C.2. Configuration Tools: The Journalling System 4777 In this appendix, we define the payload format parameters that configure 4778 stream journalling and the recovery journal system. 4780 The j_sec parameter (Appendix C.2.1) sets the journalling method for the 4781 stream. The j_update parameter (Appendix C.2.2) sets the recovery 4782 journal sending policy for the stream. Appendix C.2.2 also defines the 4783 sending policies of the recovery journal system. 4785 Appendix C.2.3 defines several parameters that modify the recovery 4786 journal semantics. These parameters change the default recovery journal 4787 semantics as defined in Section 5 and Appendices A-B. 4789 The journalling method for a stream is set at the start of a session and 4790 MUST NOT be changed thereafter. This requirement forbids changes to the 4791 j_sec parameter once a session has begun. 4793 A related requirement, defined in the appendix sections below, forbids 4794 the acceptance of parameter values that would violate the recovery 4795 journal mandate. In many cases, a change in one of the parameters 4796 defined in this appendix during an ongoing session would result in a 4797 violation of the recovery journal mandate for an implementation; in this 4798 case, the parameter change MUST NOT be accepted. 4800 C.2.1. The j_sec Parameter 4802 Section 2.2 defines the default journalling method for a stream. 4803 Streams that use unreliable transport (such as UDP) default to using the 4804 recovery journal. Streams that use reliable transport (such as TCP) 4805 default to not using a journal. 4807 The parameter j_sec may be used to override this default. This memo 4808 defines two symbolic values for j_sec: "none", to indicate that all 4809 stream payloads MUST NOT contain a journal section, and "recj", to 4810 indicate that all stream payloads MUST contain a journal section that 4811 uses the recovery journal format. 4813 For example, the j_sec parameter might be set to "none" for a UDP stream 4814 that travels between two hosts on a local network that is known to 4815 provide reliable datagram delivery. 4817 The session description below configures a UDP stream that does not use 4818 the recovery journal: 4820 v=0 4821 o=lazzaro 2520644554 2838152170 IN IP4 first.example.net 4822 s=Example 4823 t=0 0 4824 m=audio 5004 RTP/AVP 96 4825 c=IN IP4 192.0.2.94 4826 a=rtpmap:96 rtp-midi/44100 4827 a=fmtp:96 j_sec=none 4829 Other IETF standards-track documents may define alternative journal 4830 formats. These documents MUST define new symbolic values for the j_sec 4831 parameter to signal the use of the format. 4833 Parties MUST NOT accept a j_sec value that violates the recovery journal 4834 mandate (see Section 4 for details). If a session description uses a 4835 j_sec value unknown to the recipient, the recipient MUST NOT accept the 4836 description. 4838 Special j_sec issues arise when sessions are managed by session 4839 management tools (like RTSP, [RFC2326]) that use SDP for "declarative 4840 usage" purposes (see the preamble of Section 6 for details). For these 4841 session management tools, SDP does not code transport details (such as 4842 UDP or TCP) for the session. Instead, server and client negotiate 4843 transport details via other means (for RTSP, the SETUP method). 4845 In this scenario, the use of the j_sec parameter may be ill-advised, as 4846 the creator of the session description may not yet know the transport 4847 type for the session. In this case, the session description SHOULD 4848 configure the journalling system using the parameters defined in the 4849 remainder of Appendix C.2, but it SHOULD NOT use j_sec to set the 4850 journalling status. Recall that if j_sec does not appear in the session 4851 description, the default method for choosing the journalling method is 4852 in effect (no journal for reliable transport, recovery journal for 4853 unreliable transport). 4855 However, in declarative usage situations where the creator of the 4856 session description knows that journalling is always required or never 4857 required, the session description SHOULD use the j_sec parameter. 4859 C.2.2. The j_update Parameter 4861 In Section 4, we use the term "sending policy" to describe the method a 4862 sender uses to choose the checkpoint packet identity for each recovery 4863 journal in a stream. In the sub-sections that follow, we normatively 4864 define three sending policies: anchor, closed-loop, and open-loop. 4866 As stated in Section 4, the default sending policy for a stream is the 4867 closed-loop policy. The j_update parameter may be used to override this 4868 default. 4870 We define three symbolic values for j_update: "anchor", to indicate that 4871 the stream uses the anchor sending policy, "open-loop", to indicate that 4872 the stream uses the open-loop sending policy, and "closed-loop", to 4873 indicate that the stream uses the closed-loop sending policy. See 4874 Appendix C.2.3 for examples session descriptions that use the j_update 4875 parameter. 4877 Parties MUST NOT accept a j_update value that violates the recovery 4878 journal mandate (Section 4). 4880 Other IETF standards-track documents may define additional sending 4881 policies for the recovery journal system. These documents MUST define 4882 new symbolic values for the j_update parameter to signal the use of the 4883 new policy. If a session description uses a j_update value unknown to 4884 the recipient, the recipient MUST NOT accept the description. 4886 C.2.2.1. The anchor Sending Policy 4888 In the anchor policy, the sender uses the first packet in the stream as 4889 the checkpoint packet for all packets in the stream. The anchor policy 4890 satisfies the recovery journal mandate (Section 4), as the checkpoint 4891 history always covers the entire stream. 4893 The anchor policy does not require the use of the RTP control protocol 4894 (RTCP, [RFC3550]) or other feedback from receiver to sender. Senders do 4895 not need to take special actions to ensure that received streams start 4896 up free of artifacts, as the recovery journal always covers the entire 4897 history of the stream. Receivers are relieved of the responsibility of 4898 tracking the changing identity of the checkpoint packet, because the 4899 checkpoint packet never changes. 4901 The main drawback of the anchor policy is bandwidth efficiency. Because 4902 the checkpoint history covers the entire stream, the size of the 4903 recovery journals produced by this policy usually exceeds the journal 4904 size of alternative policies. For single-channel MIDI data streams, the 4905 bandwidth overhead of the anchor policy is often acceptable (see 4906 Appendix A.4 of [NMP]). For dense streams, the closed-loop or open-loop 4907 policies may be more appropriate. 4909 C.2.2.2. The closed-loop Sending Policy 4911 The closed-loop policy is the default policy of the recovery journal 4912 system. For each packet in the stream, the policy lets senders choose 4913 the smallest possible checkpoint history that satisfies the recovery 4914 journal mandate. As smaller checkpoint histories generally yield 4915 smaller recovery journals, the closed-loop policy reduces the bandwidth 4916 of a stream, relative to the anchor policy. 4918 The closed-loop policy relies on feedback from receiver to sender. The 4919 policy assumes that a receiver periodically informs the sender of the 4920 highest sequence number it has seen so far in the stream, coded in the 4921 32-bit extension format defined in [RFC3550]. For RTCP, receivers 4922 transmit this information in the Extended Highest Sequence Number 4923 Received (EHSNR) field of Receiver Reports. RTCP Sender or Receiver 4924 Reports MUST be sent by any participant in a session with closed loop 4925 sending policy, unless another feedback mechanism has been agreed upon. 4927 The sender may safely use receiver sequence number feedback to guide 4928 checkpoint history management, because Section 4 requires that receivers 4929 repair indefinite artifacts whenever a packet loss event occur. 4931 We now normatively define the closed-loop policy. At the moment a 4932 sender prepares an RTP packet for transmission, the sender is aware of R 4933 >= 0 receivers for the stream. Senders may become aware of a receiver 4934 via RTCP traffic from the receiver, via RTP packets from a paired stream 4935 sent by the receiver to the sender, via messages from a session 4936 management tool, or by other means. As receivers join and leave a 4937 session, the value of R changes. 4939 Each known receiver k (1 <= k <= R) is associated with a 32-bit extended 4940 packet sequence number M(k), where the extension reflects the sequence 4941 number rollover count of the sender. 4943 If the sender has received at least one feedback report from receiver k, 4944 M(k) is the most recent report of the highest RTP packet sequence number 4945 seen by the receiver, normalized to reflect the rollover count of the 4946 sender. 4948 If the sender has not received a feedback report from the receiver, M(k) 4949 is the extended sequence number of the last packet the sender 4950 transmitted before it became aware of the receiver. If the sender 4951 became aware of this receiver before it sent the first packet in the 4952 stream, M(k) is the extended sequence number of the first packet in the 4953 stream. 4955 Given this definition of M(), we now state the closed-loop policy. When 4956 preparing a new packet for transmission, a sender MUST choose a 4957 checkpoint packet with extended sequence number N, such that M(k) >= (N 4958 - 1) for all k, 1 <= k <= R, where R >= 1. The policy does not restrict 4959 sender behavior in the R == 0 (no known receivers) case. 4961 Under the closed-loop policy as defined above, a sender may transmit 4962 packets whose checkpoint history is shorter than the session history (as 4963 defined in Appendix A.1). In this event, a new receiver that joins the 4964 stream may experience indefinite artifacts. 4966 For example, if a Control Change (0xB) command for Channel Volume 4967 (controller number 7) was sent early in a stream, and later a new 4968 receiver joins the session, the closed-loop policy may permit all 4969 packets sent to the new receiver to use a checkpoint history that does 4970 not include the Channel Volume Control Change command. As a result, the 4971 new receiver experiences an indefinite artifact, and plays all notes on 4972 a channel too loudly or too softly. 4974 To address this issue, the closed-loop policy states that whenever a 4975 sender becomes aware of a new receiver, the sender MUST determine if the 4976 receiver would be subject to indefinite artifacts under the closed-loop 4977 policy. If so, the sender MUST ensure that the receiver starts the 4978 session free of indefinite artifacts. For example, to solve the Channel 4979 Volume issue described above, the sender may code the current state of 4980 the Channel Volume controller numbers in the recovery journal Chapter C, 4981 until it receives the first RTCP RR report that signals that a packet 4982 containing this Chapter C has been received. 4984 In satisfying this requirement, senders MAY infer the initial MIDI state 4985 of the receiver from the session description. For example, the stream 4986 example in Section 6.2 has the initial state defined in [MIDI] for 4987 General MIDI. 4989 In a unicast RTP session, a receiver may safely assume that the sender 4990 is aware of its presence as a receiver from the first packet sent in the 4991 RTP stream. However, in other types of RTP sessions (multicast, 4992 conference focus, RTP translator/mixer), a receiver is often not able to 4993 determine if the sender is initially aware of its presence as a 4994 receiver. 4996 To address this issue, the closed-loop policy states that if a receiver 4997 participates in a session where it may have access to a stream whose 4998 sender is not aware of the receiver, the receiver MUST take actions to 4999 ensure that its rendered MIDI performance does not contain indefinite 5000 artifacts. These protections will be necessarily incomplete. For 5001 example, a receiver may monitor the Checkpoint Packet Seqnum for 5002 uncovered loss events, and "err on the side of caution" with respect to 5003 handling stuck notes due to lost MIDI NoteOff commands, but the receiver 5004 is not able to compensate for the lack of Channel Volume initialization 5005 data in the recovery journal. 5007 The receiver MUST NOT discontinue these protective actions until it is 5008 certain that the sender is aware of its presence. If a receiver is not 5009 able to ascertain sender awareness, the receiver MUST continue these 5010 protective actions for the duration of the session. 5012 Note that in a multicast session where all parties are expected to send 5013 and receive, the reception of RTCP receiver reports from the sender 5014 about the RTP stream a receiver is multicasting back is evidence of the 5015 sender's awareness that the RTP stream multicast by the sender is being 5016 monitored by the receiver. Receivers may also obtain sender awareness 5017 evidence from session management tools, or by other means. In practice, 5018 ongoing observation of the Checkpoint Packet Seqnum to determine if the 5019 sender is taking actions to prevent loss events for a receiver is a good 5020 indication of sender awareness, as is the sudden appearance of recovery 5021 journal chapters with numerous Control Change controller data that was 5022 not foreshadowed by recent commands coded in the MIDI list shortly after 5023 sending an RTCP RR. 5025 The final set of normative closed-loop policy requirements concerns how 5026 senders and receivers handle unplanned disruptions of RTCP feedback from 5027 a receiver to a sender. By "unplanned", we refer to disruptions that 5028 are not due to the signalled termination of an RTP stream, via an RTCP 5029 BYE or via session management tools. 5031 As defined earlier in this section, the closed-loop policy states that a 5032 sender MUST choose a checkpoint packet with extended sequence number N, 5033 such that M(k) >= (N - 1) for all k, 1 <= k <= R, where R >= 1. If the 5034 sender has received at least one feedback report from receiver k, M(k) 5035 is the most recent report of the highest RTP packet sequence number seen 5036 by the receiver, normalized to reflect the rollover count of the sender. 5038 If this receiver k stops sending feedback to the sender, the M(k) value 5039 used by the sender reflects the last feedback report from the receiver. 5040 As time progresses without feedback from receiver k, this fixed M(k) 5041 value forces the sender to increase the size of the checkpoint history, 5042 and thus increases the bandwidth of the stream. 5044 At some point, the sender may need to take action in order to limit the 5045 bandwidth of the stream. In most envisioned uses of RTP MIDI, long 5046 before this point is reached, the SSRC time-out mechanism defined in 5047 [RFC3550] will remove the uncooperative receiver from the session (note 5048 that the closed-loop policy does not suggest or require any special 5049 sender behavior upon an SSRC time-out, other than the sender actions 5050 related to changing R, described earlier in this section). 5052 However, in rare situations, the bandwidth of the stream (due to a lack 5053 of feedback reports from the sender) may become too large to continue 5054 sending the stream to the receiver before the SSRC time-out occurs for 5055 the receiver. In this case, the closed-loop policy states that the 5056 sender should invoke the SSRC time-out for the receiver early. 5058 We now discuss receiver responsibilities in the case of unplanned 5059 disruptions of RTCP feedback from receiver to sender. 5061 In the unicast case, if a sender invokes the SSRC time-out mechanism for 5062 a receiver, the receiver stops receiving packets from the sender. The 5063 sender behavior imposed by the guardtime parameter (Appendix C.4.2) lets 5064 the receiver conclude that an SSRC time-out has occurred in a reasonable 5065 time period. 5067 In this case of a time-out, a receiver MUST keep sending RTCP feedback, 5068 in order to re-establish the RTP flow from the sender. Unless the 5069 receiver expects a prompt recovery of the RTP flow, the receiver MUST 5070 take actions to ensure that the rendered MIDI performance does not 5071 exhibit "very long transient artifacts" (for example, by silencing 5072 NoteOns to prevent stuck notes) while awaiting reconnection of the flow. 5074 In the multicast case, if a sender invokes the SSRC time-out mechanism 5075 for a receiver, the receiver may continue to receive packets, but the 5076 sender will no longer be using the M(k) feedback from the receiver to 5077 choose each checkpoint packet. If the receiver does not have additional 5078 information that precludes an SSRC time-out (such as RTCP Receiver 5079 Reports from the sender about an RTP stream the receiver is multicasting 5080 back to the sender), the receiver MUST monitor the Checkpoint Packet 5081 Seqnum to detect an SSRC time-out. If an SSRC time-out is detected, the 5082 receiver MUST follow the instructions for SSRC time-outs described for 5083 the unicast case above. 5085 Finally, we note that the closed-loop policy is suitable for use in 5086 RTP/RTCP sessions that use multicast transport. However, aspects of the 5087 closed-loop policy do not scale well to sessions with large numbers of 5088 participants. The sender state scales linearly with the number of 5089 receivers, as the sender needs to track the identity and M(k) value for 5090 each receiver k. The average recovery journal size is not independent 5091 of the number of receivers, as the RTCP reporting interval backoff slows 5092 down the rate of a full update of M(k) values. The backoff algorithm 5093 may also increase the amount of ancillary state used by implementations 5094 of the normative sender and receiver behaviors defined in Section 4. 5096 C.2.2.3. The open-loop Sending Policy 5098 The open-loop policy is suitable for sessions that are not able to 5099 implement the receiver-to-sender feedback required by the closed-loop 5100 policy, and that are also not able to use the anchor policy because of 5101 bandwidth constraints. 5103 The open-loop policy does not place constraints on how a sender chooses 5104 the checkpoint packet for each packet in the stream. In the absence of 5105 such constraints, a receiver may find that the recovery journal in the 5106 packet that ends a loss event has a checkpoint history that does not 5107 cover the entire loss event. We refer to loss events of this type as 5108 uncovered loss events. 5110 To ensure that uncovered loss events do not compromise the recovery 5111 journal mandate, the open-loop policy assigns specific recovery tasks to 5112 senders, receivers, and the creators of session descriptions. The 5113 underlying premise of the open-loop policy is that the indefinite 5114 artifacts produced during uncovered loss events fall into two classes. 5116 One class of artifacts is recoverable indefinite artifacts. Receivers 5117 are able to repair recoverable artifacts that occur during an uncovered 5118 loss event without intervention from the sender, at the potential cost 5119 of unpleasant transient artifacts. 5121 For example, after an uncovered loss event, receivers are able to repair 5122 indefinite artifacts due to NoteOff (0x8) commands that may have 5123 occurred during the loss event, by executing NoteOff commands for all 5124 active NoteOns commands. This action causes a transient artifact (a 5125 sudden silent period in the performance), but ensures that no stuck 5126 notes sound indefinitely. We refer to MIDI commands that are amenable 5127 to repair in this fashion as recoverable MIDI commands. 5129 A second class of artifacts is unrecoverable indefinite artifacts. If 5130 this class of artifact occurs during an uncovered loss event, the 5131 receiver is not able to repair the stream. 5133 For example, after an uncovered loss event, receivers are not able to 5134 repair indefinite artifacts due to Control Change (0xB) Channel Volume 5135 (controller number 7) commands that have occurred during the loss event. 5136 A repair is impossible because the receiver has no way of determining 5137 the data value of a lost Channel Volume command. We refer to MIDI 5138 commands that are fragile in this way as unrecoverable MIDI commands. 5140 The open-loop policy does not specify how to partition the MIDI command 5141 set into recoverable and unrecoverable commands. Instead, it assumes 5142 that the creators of the session descriptions are able to come to 5143 agreement on a suitable recoverable/unrecoverable MIDI command partition 5144 for an application. 5146 Given these definitions, we now state the normative requirements for the 5147 open-loop policy. 5149 In the open-loop policy, the creators of the session description MUST 5150 use the ch_anchor parameter (defined in Appendix C.2.3) to protect all 5151 unrecoverable MIDI command types from indefinite artifacts, or 5152 alternatively MUST use the cm_unused parameter (defined in Appendix C.1) 5153 to exclude the command types from the stream. These options act to 5154 shield command types from artifacts during an uncovered loss event. 5156 In the open-loop policy, receivers MUST examine the Checkpoint Packet 5157 Seqnum field of the recovery journal header after every loss event, to 5158 check if the loss event is an uncovered loss event. Section 5 shows how 5159 to perform this check. If an uncovered loss event has occurred, a 5160 receiver MUST perform indefinite artifact recovery for all MIDI command 5161 types that are not shielded by ch_anchor and cm_unused parameter 5162 assignments in the session description. 5164 The open-loop policy does not place specific constraints on the sender. 5165 However, the open-loop policy works best if the sender manages the size 5166 of the checkpoint history to ensure that uncovered losses occur 5167 infrequently, by taking into account the delay and loss characteristics 5168 of the network. Also, as each checkpoint packet change incurs the risk 5169 of an uncovered loss, senders should only move the checkpoint if it 5170 reduces the size of the journal. 5172 C.2.3. Recovery Journal Chapter Inclusion Parameters 5174 The recovery journal chapter definitions (Appendices A-B) specify under 5175 what conditions a chapter MUST appear in the recovery journal. In most 5176 cases, the definition states that if a certain command appears in the 5177 checkpoint history, a certain chapter type MUST appear in the recovery 5178 journal to protect the command. 5180 In this section, we describe the chapter inclusion parameters. These 5181 parameters modify the conditions under which a chapter appears in the 5182 journal. These parameters are essential to the use of the open-loop 5183 policy (Appendix C.2.2.3) and may also be used to simplify 5184 implementations of the closed-loop (Appendix C.2.2.2) and anchor 5185 (Appendix C.2.2.1) policies. 5187 Each parameter represents a type of chapter inclusion semantics. An 5188 assignment to a parameter declares which chapters (or chapter subsets) 5189 obey the inclusion semantics. We describe the assignment syntax for 5190 these parameters later in this section. 5192 A party MUST NOT accept chapter inclusion parameter values that violate 5193 the recovery journal mandate (Section 4). All assignments of the 5194 subsetting parameters (cm_used and cm_unused) MUST precede the first 5195 assignment of a chapter inclusion parameter in the parameter list. 5197 Below, we normatively define the semantics of the chapter inclusion 5198 parameters. For clarity, we define the action of parameters on complete 5199 chapters. If a parameter is assigned a subset of a chapter, the 5200 definition applies only to the chapter subset. 5202 o ch_never. A chapter assigned to the ch_never parameter MUST 5203 NOT appear in the recovery journal (Appendix A.4.1-2 defines 5204 exceptions to this rule for Chapter M). To signal the exclusion 5205 of a chapter from the journal, an assignment to ch_never MUST 5206 be made, even if the commands coded by the chapter are assigned 5207 to cm_unused. This rule simplifies the handling of commands 5208 types that may be coded in several chapters. 5210 o ch_default. A chapter assigned to the ch_default parameter 5211 MUST follow the default semantics for the chapter, as defined 5212 in Appendices A-B. 5214 o ch_anchor. A chapter assigned to the ch_anchor MUST obey a 5215 modified version of the default chapter semantics. In the 5216 modified semantics, all references to the checkpoint history 5217 are replaced with references to the session history, and all 5218 references to the checkpoint packet are replaced with 5219 references to the first packet sent in the stream. 5221 Parameter assignments obey the following syntax (see Appendix D for 5222 ABNF): 5224 = [channel list][field list] 5226 The chapter list is mandatory; the channel and field lists are optional. 5227 Multiple assignments to parameters have a cumulative effect and are 5228 applied in the order of parameter appearance in a media description. 5230 To determine the semantics of a list of chapter inclusion parameter 5231 assignments, we begin by assuming an implicit assignment of all channel 5232 and system chapters to the ch_default parameter, with the default values 5233 for the channel list and field list for each chapter that are defined 5234 below. 5236 We then interpret the semantics of the actual parameter assignments, 5237 using the rules below. 5239 A later assignment of a chapter to the same parameter expands the scope 5240 of the earlier assignment. In most cases, a later assignment of a 5241 chapter to a different parameter cancels (partially or completely) the 5242 effect of an earlier assignment. 5244 The chapter list specifies the channel or system chapters for which the 5245 parameter applies. The chapter list is a concatenated sequence of one 5246 or more of the letters corresponding to the chapter types 5247 (ACDEFMNPQTVWX). In addition, the list may contain one or more of the 5248 letters for the sub-chapter types (BGHJKYZ) of System Chapter D. 5250 The letters in a chapter list MUST be uppercase and MUST appear in 5251 alphabetical order. Letters other than (ABCDEFGHJKMNPQTVWXYZ) that 5252 appear in the chapter list MUST be ignored. 5254 The channel list specifies the channel journals for which this parameter 5255 applies; if no channel list is provided, the parameter applies to all 5256 channel journals. The channel list takes the form of a list of channel 5257 numbers (0 through 15) and dash-separated channel number ranges (i.e., 5258 0-5, 8-12, etc.). Dots (i.e., "." characters) separate elements in the 5259 channel list. 5261 Several of the systems chapters may be configured to have special 5262 semantics. Configuration occurs by specifying a channel list for the 5263 systems channel, using the coding described below (note that MIDI 5264 Systems commands do not have a "channel", and thus the original purpose 5265 of the channel list does not apply to systems chapters). The expression 5266 "the digit N" in the text below refers to the inclusion of N as a 5267 "channel" in the channel list for a systems chapter. 5269 For the J and K Chapter D sub-chapters (undefined System Common), the 5270 digit 0 codes that the parameter applies to the LEGAL field of the 5271 associated command log (Figure B.1.4 of Appendix B.1), the digit 1 codes 5272 that the parameter applies to the VALUE field of the command log, and 5273 the digit 2 codes that the parameter applies to the COUNT field of the 5274 command log. 5276 For the Y and Z Chapter D sub-chapters (undefined System Real-time), the 5277 digit 0 codes that the parameter applies to the LEGAL field of the 5278 associated command log (Figure B.1.5 of Appendix B.1) and the digit 1 5279 codes that the parameter applies to the COUNT field of the command log. 5281 For Chapter Q (Sequencer State Commands), the digit 0 codes that the 5282 parameter applies to the default Chapter Q definition, which forbids the 5283 TIME field. The digit 1 codes that the parameter applies to the 5284 optional Chapter Q definition, which supports the TIME field. 5286 The syntax for field lists follows the syntax for channel lists. If no 5287 field list is provided, the parameter applies to all controller or note 5288 numbers. For Chapter C, if no field list is provided, the controller 5289 numbers do not use enhanced Chapter C encoding (Appendix A.3.3). 5291 For Chapter C, the field list may take on values in the range 0 to 255. 5292 A field value X in the range 0-127 refers to a controller number X, and 5293 indicates that the controller number does not use enhanced Chapter C 5294 encoding. A field value X in the range 128-255 refers to a controller 5295 number "X minus 128" and indicates the controller number does use the 5296 enhanced Chapter C encoding. 5298 Assignments made to configure the Chapter C encoding method for a 5299 controller number MUST be made to the ch_default or ch_anchor 5300 parameters, as assignments to ch_never act to exclude the number from 5301 the recovery journal (and thus the indicated encoding method is 5302 irrelevant). 5304 A Chapter C field list MUST NOT encode conflicting information about the 5305 enhanced encoding status of a particular controller number. For 5306 example, values 0 and 128 MUST NOT both be coded by a field list. 5308 For Chapter M, the field list codes the Registered Parameter Numbers 5309 (RPNs) and Non-Registered Parameter Numbers (NRPNs) for which the 5310 parameter applies. The number range 0-16383 specifies RPNs, the number 5311 range 16384-32767 specifies NRPNs (16384 corresponds to NRPN 0, 32767 5312 corresponds to NRPN 16383). 5314 For Chapters N and A, the field list codes the note numbers for which 5315 the parameter applies. The note number range specified for Chapter N 5316 also applies to Chapter E. 5318 For Chapter E, the digit 0 codes that the parameter applies to Chapter E 5319 note logs whose V bit is set to 0, and the digit 1 codes that the 5320 parameter applies to note logs whose V bit is set to 1. 5322 For Chapter X, the field list codes the number of data octets that may 5323 appear in a SysEx command that is coded in the chapter. Thus, the field 5324 list 0-255 specifies SysEx commands with 255 or fewer data octets, the 5325 field list 256-4294967295 specifies SysEx commands with more than 255 5326 data octets but excludes commands with 255 or fewer data octets, and the 5327 field list 0 excludes all commands. 5329 A secondary parameter assignment syntax customizes Chapter X (see 5330 Appendix D for complete ABNF): 5332 = "__" *( "_" ) "__" 5334 The assignment defines a class of SysEx commands whose Chapter X coding 5335 obeys the semantics of the assigned parameter. The command class is 5336 specified by listing the permitted values of the first N data octets 5337 that follow the SysEx 0xF0 command octet. Any SysEx command whose first 5338 N data octets match the list is a member of the class. 5340 Each defines a data octet of the command, as a dot-separated 5341 (".") list of one or more hexadecimal constants (such as "7F") or dash- 5342 separated hexadecimal ranges (such as "01-1F"). Underscores ("_") 5343 separate each . Double-underscores ("__") delineate the data 5344 octet list. 5346 Using this syntax, each assignment specifies a single SysEx command 5347 class. Session descriptions may use several assignments to the same (or 5348 different) parameters to specify complex Chapter X behaviors. The 5349 ordering behavior of multiple assignments follows the guidelines for 5350 chapter parameter assignments described earlier in this section. 5352 The example session description below illustrates the use of the chapter 5353 inclusion parameters: 5355 v=0 5356 o=lazzaro 2520644554 2838152170 IN IP6 first.example.net 5357 s=Example 5358 t=0 0 5359 m=audio 5004 RTP/AVP 96 5360 c=IN IP6 2001:DB8::7F2E:172A:1E24 5361 a=rtpmap:96 rtp-midi/44100 5362 a=fmtp:96 j_update=open-loop; cm_unused=ABCFGHJKMQTVWXYZ; 5363 cm_used=__7E_00-7F_09_01.02.03__; 5364 cm_used=__7F_00-7F_04_01.02__; cm_used=C7.64; 5365 ch_never=ABCDEFGHJKMQTVWXYZ; ch_never=4.11-13N; 5366 ch_anchor=P; ch_anchor=C7.64; 5367 ch_anchor=__7E_00-7F_09_01.02.03__; 5368 ch_anchor=__7F_00-7F_04_01.02__ 5370 (The a=fmtp line has been wrapped to fit the page to accommodate 5371 memo formatting restrictions; it comprises a single line in SDP.) 5373 The j_update parameter codes that the stream uses the open-loop policy. 5374 Most MIDI command-types are assigned to cm_unused and thus do not appear 5375 in the stream. As a consequence, the assignments to the first ch_never 5376 parameter reflect that most chapters are not in use. 5378 Chapter N for several MIDI channels is assigned to ch_never. Chapter N 5379 for MIDI channels other than 4, 11, 12, and 13 may appear in the 5380 recovery journal, using the (default) ch_default semantics. In 5381 practice, this assignment pattern would reflect knowledge about a 5382 resilient rendering method in use for the excluded channels. 5384 The MIDI Program Change command and several MIDI Control Change 5385 controller numbers are assigned to ch_anchor. Note that the ordering of 5386 the ch_anchor chapter C assignment after the ch_never command acts to 5387 override the ch_never assignment for the listed controller numbers (7 5388 and 64). 5390 The assignment of command-type X to cm_unused excludes most SysEx 5391 commands from the stream. Exceptions are made for General MIDI System 5392 On/Off commands and for the Master Volume and Balance commands, via the 5393 use of the secondary assignment syntax. The cm_used assignment codes 5394 the exception, and the ch_anchor assignment codes how these commands are 5395 protected in Chapter X. 5397 C.3. Configuration Tools: Timestamp Semantics 5399 The MIDI command section of the payload format consists of a list of 5400 commands, each with an associated timestamp. The semantics of command 5401 timestamps may be set during session configuration, using the parameters 5402 we describe in this section 5404 The parameter "tsmode" specifies the timestamp semantics for a stream. 5405 The parameter takes on one of three token values: "comex", "async", or 5406 "buffer". 5408 The default "comex" value specifies that timestamps code the execution 5409 time for a command (Appendix C.3.1) and supports the accurate 5410 transcoding of Standard MIDI Files (SMFs, [MIDI]). The "comex" value is 5411 also RECOMMENDED for new MIDI user-interface controller designs. The 5412 "async" value specifies an asynchronous timestamp sampling algorithm for 5413 time-of-arrival sources (Appendix C.3.2). The "buffer" value specifies 5414 a synchronous timestamp sampling algorithm (Appendix C.3.3) for time-of- 5415 arrival sources. 5417 Ancillary parameters MAY follow tsmode in a media description. We 5418 define these parameters in Appendices C.3.2-3 below. 5420 C.3.1. The comex Algorithm 5422 The default "comex" (COMmand EXecution) tsmode value specifies the 5423 execution time for the command. With comex, the difference between two 5424 timestamps indicates the time delay between the execution of the 5425 commands. This difference may be zero, coding simultaneous execution. 5427 The comex interpretation of timestamps works well for transcoding a 5428 Standard MIDI File (SMF, [MIDI]) into an RTP MIDI stream, as SMFs code a 5429 timestamp for each MIDI command stored in the file. To transcode an SMF 5430 that uses metric time markers, use the SMF tempo map (encoded in the SMF 5431 as meta-events) to convert metric SMF timestamp units into seconds-based 5432 RTP timestamp units. 5434 New MIDI controller designs (piano keyboard, drum pads, etc.) that 5435 support RTP MIDI and that have direct access to sensor data SHOULD use 5436 comex interpretation for timestamps, so that simultaneous gestural 5437 events may be accurately coded by RTP MIDI. 5439 Comex is a poor choice for transcoding MIDI 1.0 DIN cables [MIDI], for a 5440 reason that we will now explain. A MIDI DIN cable is an asynchronous 5441 serial protocol (320 microseconds per MIDI byte). MIDI commands on a 5442 DIN cable are not tagged with timestamps. Instead, MIDI DIN receivers 5443 infer command timing from the time of arrival of the bytes. Thus, two 5444 two-byte MIDI commands that occur at a source simultaneously are encoded 5445 on a MIDI 1.0 DIN cable with a 640 microsecond time offset. A MIDI DIN 5446 receiver is unable to tell if this time offset existed in the source 5447 performance or is an artifact of the serial speed of the cable. 5448 However, the RTP MIDI comex interpretation of timestamps declares that a 5449 timestamp offset between two commands reflects the timing of the source 5450 performance. 5452 This semantic mismatch is the reason that comex is a poor choice for 5453 transcoding MIDI DIN cables. Note that the choice of the RTP timestamp 5454 rate (Section 6.1-2 in the main text) cannot fix this inaccuracy issue. 5455 In the sections that follow, we describe two alternative timestamp 5456 interpretations ("async" and "buffer") that are a better match to MIDI 5457 1.0 DIN cable timing, and to other MIDI time-of-arrival sources. 5459 The "octpos", "linerate", and "mperiod" ancillary parameters (defined 5460 below) SHOULD NOT be used with comex. 5462 C.3.2. The async Algorithm 5464 The "async" tsmode value specifies the asynchronous sampling of a MIDI 5465 time-of-arrival source. In asynchronous sampling, the moment an octet 5466 is received from a source, it is labelled with a wall-clock time value. 5467 The time value has RTP timestamp units. 5469 The "octpos" ancillary parameter defines how RTP command timestamps are 5470 derived from octet time values. If octpos has the token value "first", 5471 a timestamp codes the time value of the first octet of the command. If 5472 octpos has the token value "last", a timestamp codes the time value of 5473 the last octet of the command. If the octpos parameter does not appear 5474 in the media description, the sender does not know which octet of the 5475 command the timestamp references (for example, the sender may be relying 5476 on an operating system service that does not specify this information). 5478 The octpos semantics refer to the first or last octet of a command as it 5479 appears on a time-of-arrival MIDI source, not as it appears in an RTP 5480 MIDI packet. This distinction is significant because the RTP coding may 5481 contain octets that are not present in the source. For example, the 5482 status octet of the first MIDI command in a packet may have been added 5483 to the MIDI stream during transcoding, to comply with the RTP MIDI 5484 running status requirements (Section 3.2). 5486 The "linerate" ancillary parameter defines the timespan of one MIDI 5487 octet on the transmission medium of the MIDI source to be sampled (such 5488 as a MIDI 1.0 DIN cable). The parameter has units of nanoseconds, and 5489 takes on integral values. For MIDI 1.0 DIN cables, the correct linerate 5490 value is 320000 (this value is also the default value for the 5491 parameter). 5493 We now show a session description example for the async algorithm. 5494 Consider a sender that is transcoding a MIDI 1.0 DIN cable source into 5495 RTP. The sender runs on a computing platform that assigns time values 5496 to every incoming octet of the source, and the sender uses the time 5497 values to label the first octet of each command in the RTP packet. This 5498 session description describes the transcoding: 5500 v=0 5501 o=lazzaro 2520644554 2838152170 IN IP4 first.example.net 5502 s=Example 5503 t=0 0 5504 m=audio 5004 RTP/AVP 96 5505 c=IN IP4 192.0.2.94 5506 a=rtpmap:96 rtp-midi/44100 5507 a=sendonly 5508 a=fmtp:96 tsmode=async; linerate=320000; octpos=first 5510 C.3.3. The buffer Algorithm 5512 The "buffer" tsmode value specifies the synchronous sampling of a MIDI 5513 time-of-arrival source. 5515 In synchronous sampling, octets received from a source are placed in a 5516 holding buffer upon arrival. At periodic intervals, the RTP sender 5517 examines the buffer. The sender removes complete commands from the 5518 buffer and codes those commands in an RTP packet. The command timestamp 5519 codes the moment of buffer examination, expressed in RTP timestamp 5520 units. Note that several commands may have the same timestamp value. 5522 The "mperiod" ancillary parameter defines the nominal periodic sampling 5523 interval. The parameter takes on positive integral values and has RTP 5524 timestamp units. 5526 The "octpos" ancillary parameter, defined in Appendix C.3.1 for 5527 asynchronous sampling, plays a different role in synchronous sampling. 5528 In synchronous sampling, the parameter specifies the timestamp semantics 5529 of a command whose octets span several sampling periods. 5531 If octpos has the token value "first", the timestamp reflects the 5532 arrival period of the first octet of the command. If octpos has the 5533 token value "last", the timestamp reflects the arrival period of the 5534 last octet of the command. The octpos semantics refer to the first or 5535 last octet of the command as it appears on a time-of-arrival source, not 5536 as it appears in the RTP packet. 5538 If the octpos parameter does not appear in the media description, the 5539 timestamp MAY reflect the arrival period of any octet of the command; 5540 senders use this option to signal a lack of knowledge about the timing 5541 details of the buffering process at sub-command granularity. 5543 We now show a session description example for the buffer algorithm. 5544 Consider a sender that is transcoding a MIDI 1.0 DIN cable source into 5545 RTP. The sender runs on a computing platform that places source data 5546 into a buffer upon receipt. The sender polls the buffer 1000 times a 5547 second, extracts all complete commands from the buffer, and places the 5548 commands in an RTP packet. This session description describes the 5549 transcoding: 5551 v=0 5552 o=lazzaro 2520644554 2838152170 IN IP6 first.example.net 5553 s=Example 5554 t=0 0 5555 m=audio 5004 RTP/AVP 96 5556 c=IN IP6 2001:DB8::7F2E:172A:1E24 5557 a=rtpmap:96 rtp-midi/44100 5558 a=sendonly 5559 a=fmtp:96 tsmode=buffer; linerate=320000; octpos=last; mperiod=44 5561 The mperiod value of 44 is derived by dividing the clock rate specified 5562 by the rtpmap attribute (44100 Hz) by the 1000 Hz buffer sampling rate 5563 and rounding to the nearest integer. Command timestamps might not 5564 increment by exact multiples of 44, as the actual sampling period might 5565 not precisely match the nominal mperiod value. 5567 C.4. Configuration Tools: Packet Timing Tools 5569 In this appendix, we describe session configuration tools for 5570 customizing the temporal behavior of MIDI stream packets. 5572 C.4.1. Packet Duration Tools 5574 Senders control the granularity of a stream by setting the temporal 5575 duration ("media time") of the packets in the stream. Short media times 5576 (20 ms or less) often imply an interactive session. Longer media times 5577 (100 ms or more) usually indicate a content streaming session. The RTP 5578 AVP profile [RFC3551] recommends audio packet media times in a range 5579 from 0 to 200 ms. 5581 By default, an RTP receiver dynamically senses the media time of packets 5582 in a stream and chooses the length of its playout buffer to match the 5583 stream. A receiver typically sizes its playout buffer to fit several 5584 audio packets and adjusts the buffer length to reflect the network 5585 jitter and the sender timing fidelity. 5587 Alternatively, the packet media time may be statically set during 5588 session configuration. Session descriptions MAY use the RTP MIDI 5589 parameter "rtp_ptime" to set the recommended media time for a packet. 5590 Session descriptions MAY also use the RTP MIDI parameter "rtp_maxptime" 5591 to set the maximum media time for a packet permitted in a stream. Both 5592 parameters MAY be used together to configure a stream. 5594 The values assigned to the rtp_ptime and rtp_maxptime parameters have 5595 the units of the RTP timestamp for the stream, as set by the rtpmap 5596 attribute (see Section 6.1). Thus, if rtpmap sets the clock rate of a 5597 stream to 44100 Hz, a maximum packet media time of 10 ms is coded by 5598 setting rtp_maxptime=441. As stated in the Appendix C preamble, the 5599 senders and receivers of a stream MUST agree on common values for 5600 rtp_ptime and rtp_maxptime if the parameters appear in the media 5601 description for the stream. 5603 0 ms is a reasonable media time value for MIDI packets and is often used 5604 in low-latency interactive applications. In a packet with a 0 ms media 5605 time, all commands execute at the instant they are coded by the packet 5606 timestamp. The session description below configures all packets in the 5607 stream to have 0 ms media time: 5609 v=0 5610 o=lazzaro 2520644554 2838152170 IN IP4 first.example.net 5611 s=Example 5612 t=0 0 5613 m=audio 5004 RTP/AVP 96 5614 c=IN IP4 192.0.2.94 5615 a=rtpmap:96 rtp-midi/44100 5616 a=fmtp:96 rtp_ptime=0; rtp_maxptime=0 5618 The session attributes ptime and maxptime [RFC4566] MUST NOT be used to 5619 configure an RTP MIDI stream. Sessions MUST use rtp_ptime in lieu of 5620 ptime and MUST use rtp_maxptime in lieu of maxptime. RTP MIDI defines 5621 its own parameters for media time configuration because 0 ms values for 5622 ptime and maxptime are forbidden by [RFC3264] but are essential for 5623 certain applications of RTP MIDI. 5625 See the Appendix C.7 examples for additional discussion about using 5626 rtp_ptime and rtp_maxptime for session configuration. 5628 C.4.2. The guardtime Parameter 5630 RTP permits a sender to stop sending audio packets for an arbitrary 5631 period of time during a session. When sending resumes, the RTP sequence 5632 number series continues unbroken, and the RTP timestamp value reflects 5633 the media time silence gap. 5635 This RTP feature has its roots in telephony, but it is also well matched 5636 to interactive MIDI sessions, as players may fall silent for several 5637 seconds during (or between) songs. 5639 Certain MIDI applications benefit from a slight enhancement to this RTP 5640 feature. In interactive applications, receivers may use on-line network 5641 models to guide heuristics for handling lost and late RTP packets. 5642 These models may work poorly if a sender ceases packet transmission for 5643 long periods of time. 5645 Session descriptions may use the parameter "guardtime" to set a minimum 5646 sending rate for a media session. The value assigned to guardtime codes 5647 the maximum separation time between two sequential packets, as expressed 5648 in RTP timestamp units. 5650 Typical guardtime values are 500-2000 ms. This value range is not a 5651 normative bound, and parties SHOULD be prepared to process values 5652 outside this range. 5654 The congestion control requirements for sender implementations 5655 (described in Section 8 and [RFC3550]) take precedence over the 5656 guardtime parameter. Thus, if the guardtime parameter requests a 5657 minimum sending rate, but sending at this rate would violate the 5658 congestion control requirements, senders MUST ignore the guardtime 5659 parameter value. In this case, senders SHOULD use the lowest minimum 5660 sending rate that satisfies the congestion control requirements. 5662 Below, we show a session description that uses the guardtime parameter. 5664 v=0 5665 o=lazzaro 2520644554 2838152170 IN IP6 first.example.net 5666 s=Example 5667 t=0 0 5668 m=audio 5004 RTP/AVP 96 5669 c=IN IP6 2001:DB8::7F2E:172A:1E24 5670 a=rtpmap:96 rtp-midi/44100 5671 a=fmtp:96 guardtime=44100; rtp_ptime=0; rtp_maxptime=0 5672 C.5. Configuration Tools: Stream Description 5674 As we discussed in Section 2.1, a party may send several RTP MIDI 5675 streams in the same RTP session, and several RTP sessions that carry 5676 MIDI may appear in a multimedia session. 5678 By default, the MIDI name space (16 channels + systems) of each RTP 5679 stream sent by a party in a multimedia session is independent. By 5680 independent, we mean three distinct things: 5682 o If a party sends two RTP MIDI streams (A and B), MIDI voice 5683 channel 0 in stream A is a different "channel 0" than MIDI 5684 voice channel 0 in stream B. 5686 o MIDI voice channel 0 in stream B is not considered to be 5687 "channel 16" of a 32-channel MIDI voice channel space whose 5688 "channel 0" is channel 0 of stream A. 5690 o Streams sent by different parties over different RTP sessions, 5691 or over the same RTP session but with different payload type 5692 numbers, do not share the association that is shared by a MIDI 5693 cable pair that cross-connects two devices in a MIDI 1.0 DIN 5694 network. By default, this association is only held by streams 5695 sent by different parties in the same RTP session that use the 5696 same payload type number. 5698 In this appendix, we show how to express that specific RTP MIDI streams 5699 in a multimedia session are not independent but instead are related in 5700 one of the three ways defined above. We use two tools to express these 5701 relations: 5703 o The musicport parameter. This parameter is assigned a 5704 non-negative integer value between 0 and 4294967295. It 5705 appears in the fmtp lines of payload types. 5707 o The FID grouping attribute [RFC5888] signals that several RTP 5708 sessions in a multimedia session are using the musicport 5709 parameter to express an inter-session relationship. 5711 If a multimedia session has several payload types whose musicport 5712 parameters are assigned the same integer value, streams using these 5713 payload types share an "identity relationship" (including streams that 5714 use the same payload type). Streams in an identity relationship share 5715 two properties: 5717 o Identity relationship streams sent by the same party 5718 target the same MIDI name space. Thus, if streams A 5719 and B share an identity relationship, voice channel 0 5720 in stream A is the same "channel 0" as voice channel 5721 0 in stream B. 5723 o Pairs of identity relationship streams that are sent by 5724 different parties share the association that is shared 5725 by a MIDI cable pair that cross-connects two devices in 5726 a MIDI 1.0 DIN network. 5728 A party MUST NOT send two RTP MIDI streams that share an identity 5729 relationship in the same RTP session. Instead, each stream MUST be in a 5730 separate RTP session. As explained in Section 2.1, this restriction is 5731 necessary to support the RTP MIDI method for the synchronization of 5732 streams that share a MIDI name space. 5734 If a multimedia session has several payload types whose musicport 5735 parameters are assigned sequential values (i.e., i, i+1, ... i+k), the 5736 streams using the payload types share an "ordered relationship". For 5737 example, if payload type A assigns 2 to musicport and payload type B 5738 assigns 3 to musicport, A and B are in an ordered relationship. 5740 Streams in an ordered relationship that are sent by the same party are 5741 considered by renderers to form a single larger MIDI space. For 5742 example, if stream A has a musicport value of 2 and stream B has a 5743 musicport value of 3, MIDI voice channel 0 in stream B is considered to 5744 be voice channel 16 in the larger MIDI space formed by the relationship. 5745 Note that it is possible for streams to participate in both an identity 5746 relationship and an ordered relationship. 5748 We now state several rules for using musicport: 5750 o If streams from several RTP sessions in a multimedia 5751 session use the musicport parameter, the RTP sessions 5752 MUST be grouped using the FID grouping attribute 5753 defined in [RFC5888]. 5755 o An ordered or identity relationship MUST NOT 5756 contain both native RTP MIDI streams and 5757 mpeg4-generic RTP MIDI streams. An exception applies 5758 if a relationship consists of sendonly and recvonly 5759 (but not sendrecv) streams. In this case, the sendonly 5760 streams MUST NOT contain both types of streams, and the 5761 recvonly streams MUST NOT contain both types of streams. 5763 o It is possible to construct identity relationships 5764 that violate the recovery journal mandate (for example, 5765 sending NoteOns for a voice channel on stream A and 5766 NoteOffs for the same voice channel on stream B). 5767 Parties MUST NOT generate (or accept) session 5768 descriptions that exhibit this flaw. 5770 o Other payload formats MAY define musicport media type 5771 parameters. Formats would define these parameters so that 5772 their sessions could be bundled into RTP MIDI name spaces. 5773 The parameter definitions MUST be compatible with the 5774 musicport semantics defined in this appendix. 5776 As a rule, at most one payload type in a relationship may specify a MIDI 5777 renderer. An exception to the rule applies to relationships that 5778 contain sendonly and recvonly streams but no sendrecv streams. In this 5779 case, one sendonly session and one recvonly session may each define a 5780 renderer. 5782 Renderer specification in a relationship may be done using the tools 5783 described in Appendix C.6. These tools work for both native streams and 5784 mpeg4-generic streams. An mpeg4-generic stream that uses the Appendix 5785 C.6 tools MUST set all "config" parameters to the empty string (""). 5787 Alternatively, for mpeg4-generic streams, renderer specification may be 5788 done by setting one "config" parameter in the relationship to the 5789 renderer configuration string, and all other config parameters to the 5790 empty string (""). 5792 We now define sender and receiver rules that apply when a party sends 5793 several streams that target the same MIDI name space. 5795 Senders MAY use the subsetting parameters (Appendix C.1) to predefine 5796 the partitioning of commands between streams, or they MAY use a dynamic 5797 partitioning strategy. 5799 Receivers that merge identity relationship streams into a single MIDI 5800 command stream MUST maintain the structural integrity of the MIDI 5801 commands coded in each stream during the merging process, in the same 5802 way that software that merges traditional MIDI 1.0 DIN cable flows is 5803 responsible for creating a merged command flow compatible with [MIDI]. 5805 Senders MUST partition the name space so that the rendered MIDI 5806 performance does not contain indefinite artifacts (as defined in Section 5807 4). This responsibility holds even if all streams are sent over 5808 reliable transport, as different stream latencies may yield indefinite 5809 artifacts. For example, stuck notes may occur in a performance split 5810 over two TCP streams, if NoteOn commands are sent on one stream and 5811 NoteOff commands are sent on the other. 5813 Senders MUST NOT split a Registered Parameter Name (RPN) or Non- 5814 Registered Parameter Name (NRPN) transaction appearing on a MIDI channel 5815 across multiple identity relationship sessions. Receivers MUST assume 5816 that the RPN/NRPN transactions that appear on different identity 5817 relationship sessions are independent and MUST preserve transactional 5818 integrity during the MIDI merge. 5820 A simple way to safely partition voice channel commands is to place all 5821 MIDI commands for a particular voice channel into the same session. 5822 Safe partitioning of MIDI Systems commands may be more complicated for 5823 sessions that extensively use System Exclusive. 5825 We now show several session description examples that use the musicport 5826 parameter. 5828 Our first session description example shows two RTP MIDI streams that 5829 drive the same General MIDI decoder. The sender partitions MIDI 5830 commands between the streams dynamically. The musicport values indicate 5831 that the streams share an identity relationship. 5833 v=0 5834 o=lazzaro 2520644554 2838152170 IN IP4 first.example.net 5835 s=Example 5836 t=0 0 5837 a=group:FID 1 2 5838 c=IN IP4 192.0.2.94 5839 m=audio 5004 RTP/AVP 96 5840 a=rtpmap:96 mpeg4-generic/44100 5841 a=mid:1 5842 a=fmtp:96 streamtype=5; mode=rtp-midi; profile-level-id=12; 5843 config=7A0A0000001A4D546864000000060000000100604D54726B0 5844 000000600FF2F000; musicport=12 5845 m=audio 5006 RTP/AVP 96 5846 a=rtpmap:96 mpeg4-generic/44100 5847 a=mid:2 5848 a=fmtp:96 streamtype=5; mode=rtp-midi; config=""; profile-level-id=12; 5849 musicport=12 5851 (The a=fmtp lines have been wrapped to fit the page to accommodate 5852 memo formatting restrictions; they comprise single lines in SDP.) 5854 Recall that Section 2.1 defines rules for streams that target the same 5855 MIDI name space. Those rules, implemented in the example above, require 5856 that each stream resides in a separate RTP session, and that the 5857 grouping mechanisms defined in [RFC5888] signal an inter-session 5858 relationship. The "group" and "mid" attribute lines implement this 5859 grouping mechanism. 5861 A variant on this example, whose session description is not shown, would 5862 use two streams in an identity relationship driving the same MIDI 5863 renderer, each with a different transport type. One stream would use 5864 UDP and would be dedicated to real-time messages. A second stream would 5865 use TCP [RFC4571] and would be used for SysEx bulk data messages. 5867 In the next example, two mpeg4-generic streams form an ordered 5868 relationship to drive a Structured Audio decoder with 32 MIDI voice 5869 channels. Both streams reside in the same RTP session. 5871 v=0 5872 o=lazzaro 2520644554 2838152170 IN IP6 first.example.net 5873 s=Example 5874 t=0 0 5875 m=audio 5006 RTP/AVP 96 97 5876 c=IN IP6 2001:DB8::7F2E:172A:1E24 5877 a=rtpmap:96 mpeg4-generic/44100 5878 a=fmtp:96 streamtype=5; mode=rtp-midi; config=""; profile-level-id=13; 5879 musicport=5 5880 a=rtpmap:97 mpeg4-generic/44100 5881 a=fmtp:97 streamtype=5; mode=rtp-midi; config=""; profile-level-id=13; 5882 musicport=6; render=synthetic; rinit="audio/asc"; 5883 url="http://example.com/cardinal.asc"; 5884 cid="azsldkaslkdjqpwojdkmsldkfpe" 5886 (The a=fmtp lines have been wrapped to fit the page to accommodate 5887 memo formatting restrictions; they comprise single lines in SDP.) 5889 The sequential musicport values for the two sessions establish the 5890 ordered relationship. The musicport=5 session maps to Structured Audio 5891 extended channels range 0-15, the musicport=6 session maps to Structured 5892 Audio extended channels range 16-31. 5894 Both config strings are empty. The configuration data is specified by 5895 parameters that appear in the fmtp line of the second media description. 5896 We define this configuration method in Appendix C.6. 5898 The next example shows two RTP MIDI streams (one recvonly, one sendonly) 5899 that form a "virtual sendrecv" session. Each stream resides in a 5900 different RTP session (a requirement because sendonly and recvonly are 5901 RTP session attributes). 5903 v=0 5904 o=lazzaro 2520644554 2838152170 IN IP4 first.example.net 5905 s=Example 5906 t=0 0 5907 a=group:FID 1 2 5908 c=IN IP4 192.0.2.94 5909 m=audio 5004 RTP/AVP 96 5910 a=sendonly 5911 a=rtpmap:96 mpeg4-generic/44100 5912 a=mid:1 5913 a=fmtp:96 streamtype=5; mode=rtp-midi; profile-level-id=12; 5914 config=7A0A0000001A4D546864000000060000000100604D54726B0 5915 000000600FF2F000; musicport=12 5916 m=audio 5006 RTP/AVP 96 5917 a=recvonly 5918 a=rtpmap:96 mpeg4-generic/44100 5919 a=mid:2 5920 a=fmtp:96 streamtype=5; mode=rtp-midi; profile-level-id=12; 5921 config=7A0A0000001A4D546864000000060000000100604D54726B0 5922 000000600FF2F000; musicport=12 5924 (The a=fmtp lines have been wrapped to fit the page to accommodate 5925 memo formatting restrictions; they comprise single lines in SDP.) 5927 To signal the "virtual sendrecv" semantics, the two streams assign 5928 musicport to the same value (12). As defined earlier in this section, 5929 pairs of identity relationship streams that are sent by different 5930 parties share the association that is shared by a MIDI cable pair that 5931 cross-connects two devices in a MIDI 1.0 network. We use the term 5932 "virtual sendrecv" because streams sent by different parties in a true 5933 sendrecv session also have this property. 5935 As discussed in the preamble to Appendix C, the primary advantage of the 5936 virtual sendrecv configuration is that each party can customize the 5937 property of the stream it receives. In the example above, each stream 5938 defines its own "config" string that could customize the rendering 5939 algorithm for each party (in fact, the particular strings shown in this 5940 example are identical, because General MIDI is not a configurable MPEG 4 5941 renderer). 5943 C.6. Configuration Tools: MIDI Rendering 5945 This appendix defines the session configuration tools for rendering. 5947 The "render" parameter specifies a rendering method for a stream. The 5948 parameter is assigned a token value that signals the top-level rendering 5949 class. This memo defines four token values for render: "unknown", 5950 "synthetic", "api", and "null": 5952 o An "unknown" renderer is a renderer whose nature is unspecified. 5953 It is the default renderer for native RTP MIDI streams. 5955 o A "synthetic" renderer transforms the MIDI stream into audio 5956 output (or sometimes into stage lighting changes or other 5957 actions). It is the default renderer for mpeg4-generic 5958 RTP MIDI streams. 5960 o An "api" renderer presents the command stream to applications 5961 via an Application Programmer Interface (API). 5963 o The "null" renderer discards the MIDI stream. 5965 The "null" render value plays special roles during Offer/Answer 5966 negotiations [RFC3264]. A party uses the "null" value in an answer to 5967 reject an offered renderer. Note that rejecting a renderer is 5968 independent from rejecting a payload type (coded by removing the payload 5969 type from a media line) and rejecting a media stream (coded by zeroing 5970 the port of a media line that uses the renderer). 5972 Other render token values MAY be registered with IANA. The token value 5973 MUST adhere to the ABNF for render tokens defined in Appendix D. 5974 Registrations MUST include a complete specification of parameter value 5975 usage, similar in depth to the specifications that appear throughout 5976 Appendix C.6 for "synthetic" and "api" render values. If a party is 5977 offered a session description that uses a render token value that is not 5978 known to the party, the party MUST NOT accept the renderer. Options 5979 include rejecting the renderer (using the "null" value), the payload 5980 type, the media stream, or the session description. 5982 Other parameters MAY follow a render parameter in a parameter list. The 5983 additional parameters act to define the exact nature of the renderer. 5984 For example, the "subrender" parameter (defined in Appendix C.6.2) 5985 specifies the exact nature of the renderer. 5987 Special rules apply to using the render parameter in an mpeg4-generic 5988 stream. We define these rules in Appendix C.6.5. 5990 C.6.1. The multimode Parameter 5992 A media description MAY contain several render parameters. By default, 5993 if a parameter list includes several render parameters, a receiver MUST 5994 choose exactly one renderer from the list to render the stream. The 5995 "multimode" parameter may be used to override this default. We define 5996 two token values for multimode: "one" and "all": 5998 o The default "one" value requests rendering by exactly one of 5999 the listed renderers. 6001 o The "all" value requests the synchronized rendering of the RTP 6002 MIDI stream by all listed renderers, if possible. 6004 If the multimode parameter appears in a parameter list, it MUST appear 6005 before the first render parameter assignment. 6007 Render parameters appear in the parameter list in order of decreasing 6008 priority. A receiver MAY use the priority ordering to decide which 6009 renderer(s) to retain in a session. 6011 If the "offer" in an Offer/Answer-style negotiation [RFC3264] contains a 6012 parameter list with one or more render parameters, the "answer" MUST set 6013 the render parameters of all unchosen renderers to "null". 6015 C.6.2. Renderer Specification 6017 The render parameter (Appendix C.6 preamble) specifies, in a broad 6018 sense, what a renderer does with a MIDI stream. In this appendix, we 6019 describe the "subrender" parameter. The token value assigned to 6020 subrender defines the exact nature of the renderer. Thus, "render" and 6021 "subrender" combine to define a renderer, in the same way as MIME types 6022 and MIME subtypes combine to define a type of media [RFC2045]. 6024 If the subrender parameter is used for a renderer definition, it MUST 6025 appear immediately after the render parameter in the parameter list. At 6026 most one subrender parameter may appear in a renderer definition. 6028 This document defines one value for subrender: the value "default". The 6029 "default" token specifies the use of the default renderer for the stream 6030 type (native or mpeg4-generic). The default renderer for native RTP 6031 MIDI streams is a renderer whose nature is unspecified (see point 6 in 6032 Section 6.1 for details). The default renderer for mpeg4-generic RTP 6033 MIDI streams is an MPEG 4 Audio Object Type whose ID number is 13, 14, 6034 or 15 (see Section 6.2 for details). 6036 If a renderer definition does not use the subrender parameter, the value 6037 "default" is assumed for subrender. 6039 Other subrender token values may be registered with IANA. We now 6040 discuss guidelines for registering subrender values. 6042 A subrender value is registered for a specific stream type (native or 6043 mpeg4-generic) and a specific render value (excluding "null" and 6044 "unknown"). Registrations for mpeg4-generic subrender values are 6045 restricted to new MPEG 4 Audio Object Types that accept MIDI input. The 6046 syntax of the token MUST adhere to the token definition in Appendix D. 6048 For "render=synthetic" renderers, a subrender value registration 6049 specifies an exact method for transforming the MIDI stream into audio 6050 (or sometimes into video or control actions, such as stage lighting). 6051 For standardized renderers, this specification is usually a pointer to a 6052 standards document, perhaps supplemented by RTP-MIDI-specific 6053 information. For commercial products and open-source projects, this 6054 specification usually takes the form of instructions for interfacing the 6055 RTP MIDI stream with the product or project software. A 6056 "render=synthetic" registration MAY specify additional Reset State 6057 commands for the renderer (Appendix A.1). 6059 A "render=api" subrender value registration specifies how an RTP MIDI 6060 stream interfaces with an API (Application Programmers Interface). This 6061 specification is usually a pointer to programmer's documentation for the 6062 API, perhaps supplemented by RTP-MIDI-specific information. 6064 A subrender registration MAY specify an initialization file (referred to 6065 in this document as an initialization data object) for the stream. The 6066 initialization data object MAY be encoded in the parameter list 6067 (verbatim or by reference) using the coding tools defined in Appendix 6068 C.6.3. An initialization data object MUST have a registered [RFC4288] 6069 media type and subtype [RFC2045]. 6071 For "render=synthetic" renderers, the data object usually encodes 6072 initialization data for the renderer (sample files, synthesis patch 6073 parameters, reverberation room impulse responses, etc.). 6075 For "render=api" renderers, the data object usually encodes data about 6076 the stream used by the API (for example, for an RTP MIDI stream 6077 generated by a piano keyboard controller, the manufacturer and model 6078 number of the keyboard, for use in GUI presentation). 6080 Usually, only one initialization object is encoded for a renderer. If a 6081 renderer uses multiple data objects, the correct receiver interpretation 6082 of multiple data objects MUST be defined in the subrender registration. 6084 A subrender value registration may also specify additional parameters, 6085 to appear in the parameter list immediately after subrender. These 6086 parameter names MUST begin with the subrender value, followed by an 6087 underscore ("_"), to avoid name space collisions with future RTP MIDI 6088 parameter names (for example, a parameter "foo_bar" defined for 6089 subrender value "foo"). 6091 We now specify guidelines for interpreting the subrender parameter 6092 during session configuration. 6094 If a party is offered a session description that uses a renderer whose 6095 subrender value is not known to the party, the party MUST NOT accept the 6096 renderer. Options include rejecting the renderer (using the "null" 6097 value), the payload type, the media stream, or the session description. 6099 Receivers MUST be aware of the Reset State commands (Appendix A.1) for 6100 the renderer specified by the subrender parameter and MUST insure that 6101 the renderer does not experience indefinite artifacts due to the 6102 presence (or the loss) of a Reset State command. 6104 C.6.3. Renderer Initialization 6106 If the renderer for a stream uses an initialization data object, an 6107 "rinit" parameter MUST appear in the parameter list immediately after 6108 the "subrender" parameter. If the renderer parameter list does not 6109 include a subrender parameter (recall the semantics for "default" in 6110 Appendix C.6.2), the "rinit" parameter MUST appear immediately after the 6111 "render" parameter. 6113 The value assigned to the rinit parameter MUST be the media type/subtype 6114 [RFC2045] for the initialization data object. If an initialization 6115 object type is registered with several media types, including audio, the 6116 assignment to rinit MUST use the audio media type. 6118 RTP MIDI supports several parameters for encoding initialization data 6119 objects for renderers in the parameter list: "inline", "url", and "cid". 6121 If the "inline", "url", and/or "cid" parameters are used by a renderer, 6122 these parameters MUST immediately follow the "rinit" parameter. 6124 If a "url" parameter appears for a renderer, an "inline" parameter MUST 6125 NOT appear. If an "inline" parameter appears for a renderer, a "url" 6126 parameter MUST NOT appear. However, neither "url" or "inline" is 6127 required to appear. If neither "url" or "inline" parameters follow 6128 "rinit", the "cid" parameter MUST follow "rinit". 6130 The "inline" parameter supports the inline encoding of the data object. 6131 The parameter is assigned a double-quoted Base64 [RFC2045] encoding of 6132 the binary data object, with no line breaks. Appendix E.4 shows an 6133 example that constructs an inline parameter value. 6135 The "url" parameter is assigned a double-quoted string representation of 6136 a Uniform Resource Locator (URL) for the data object. The string MUST 6137 specify either a HyperText Transport Protocol URI (HTTP, [RFC2616]) or 6138 an HTTP over TLS URI (HTTPS, [RFC2818]). The media type/subtype for the 6139 data object SHOULD be specified in the appropriate HTTP or HTTPS 6140 transport header. 6142 The "cid" parameter supports data object caching. The parameter is 6143 assigned a double-quoted string value that encodes a globally unique 6144 identifier for the data object. 6146 A cid parameter MAY immediately follow an inline parameter, in which 6147 case the cid identifier value MUST be associated with the inline data 6148 object. 6150 If a url parameter is present, and if the data object for the URL is 6151 expected to be unchanged for the life of the URL, a cid parameter MAY 6152 immediately follow the url parameter. The cid identifier value MUST be 6153 associated with the data object for the URL. A cid parameter assigned 6154 to the same identifier value SHOULD be specified following the data 6155 object type/subtype in the appropriate HTTP transport header. 6157 If a url parameter is present, and if the data object for the URL is 6158 expected to change during the life of the URL, a cid parameter MUST NOT 6159 follow the url parameter. A receiver interprets the presence of a cid 6160 parameter as an indication that it is safe to use a cached copy of the 6161 url data object; the absence of a cid parameter is an indication that it 6162 is not safe to use a cached copy, as it may change. 6164 Finally, the cid parameter MAY be used without the inline and url 6165 parameters. In this case, the identifier references a local or 6166 distributed catalog of data objects. 6168 In most cases, only one data object is coded in the parameter list for 6169 each renderer. For example, the default renderer for mpeg4-generic 6170 streams uses a single data object (see Appendix C.6.5 for example 6171 usage). 6173 However, a subrender registration MAY permit the use of multiple data 6174 objects for a renderer. If multiple data objects are encoded for a 6175 renderer, each object encoding begins with an "rinit" parameter, 6176 followed by "inline", "url", and/or "cid" parameters. 6178 Initialization data objects MAY encapsulate a Standard MIDI File (SMF). 6179 By default, the SMFs that are encapsulated in a data object MUST be 6180 ignored by an RTP MIDI receiver. We define parameters to override this 6181 default in Appendix C.6.4. 6183 To end this section, we offer guidelines for registering media types for 6184 initialization data objects. These guidelines are in addition to the 6185 information in [RFC4288]. 6187 Some initialization data objects are also capable of encoding MIDI note 6188 information and thus complete audio performances. These objects SHOULD 6189 be registered using the "audio" media type, so that the objects may also 6190 be used for store-and-forward rendering, and "application" media type, 6191 to support editing tools. Initialization objects without note storage, 6192 or initialization objects for non-audio renderers, SHOULD be registered 6193 only for an "application" media type. 6195 C.6.4. MIDI Channel Mapping 6197 In this appendix, we specify how to map MIDI name spaces (16 voice 6198 channels + systems) onto a renderer. 6200 In the general case: 6202 o A session may define an ordered relationship (Appendix C.5) 6203 that presents more than one MIDI name space to a renderer. 6205 o A renderer may accept an arbitrary number of MIDI name spaces, 6206 or it may expect a specific number of MIDI name spaces. 6208 A session description SHOULD provide a compatible MIDI name space to 6209 each renderer in the session. If a receiver detects that a session 6210 description has too many or too few MIDI name spaces for a renderer, 6211 MIDI data from extra stream name spaces MUST be discarded, and extra 6212 renderer name spaces MUST NOT be driven with MIDI data (except as 6213 described in Appendix C.6.4.1, below). 6215 If a parameter list defines several renderers and assigns the "all" 6216 token value to the multimode parameter, the same name space is presented 6217 to each renderer. However, the "chanmask" parameter may be used to mask 6218 out selected voice channels to each renderer. We define "chanmask" and 6219 other MIDI management parameters in the sub-sections below. 6221 C.6.4.1. The smf_info Parameter 6223 The smf_info parameter defines the use of the SMFs encapsulated in 6224 renderer data objects (if any). The smf_info parameter also defines the 6225 use of SMFs coded in the smf_inline, smf_url, and smf_cid parameters 6226 (defined in Appendix C.6.4.2). 6228 The smf_info parameter describes the "render" parameter that most 6229 recently precedes it in the parameter list. The smf_info parameter MUST 6230 NOT appear in parameter lists that do not use the "render" parameter, 6231 and MUST NOT appear before the first use of "render" in the parameter 6232 list. 6234 We define three token values for smf_info: "ignore", "sdp_start", and 6235 "identity": 6237 o The "ignore" value indicates that the SMFs MUST be discarded. 6238 This behavior is the default SMF rendering behavior. 6240 o The "sdp_start" value codes that SMFs MUST be rendered, 6241 and that the rendering MUST begin upon the acceptance of 6242 the session description. If a receiver is offered a session 6243 description with a renderer that uses an smf_info parameter 6244 set to sdp_start, and if the receiver does not support 6245 rendering SMFs, the receiver MUST NOT accept the renderer 6246 associated with the smf_info parameter. Options include 6247 rejecting the renderer (by setting the "render" parameter 6248 to "null"), the payload type, the media stream, or the 6249 entire session description. 6251 o The "identity" value indicates that the SMFs code the identity 6252 of the renderer. The value is meant for use with the 6253 "unknown" renderer (see Appendix C.6 preamble). The MIDI commands 6254 coded in the SMF are informational in nature and MUST NOT be 6255 presented to a renderer for audio presentation. In 6256 typical use, the SMF would use SysEx Identity Reply 6257 commands (F0 7E nn 06 02, as defined in [MIDI]) to identify 6258 devices, and use device-specific SysEx commands to describe 6259 current state of the devices (patch memory contents, etc.). 6261 Other smf_info token values MAY be registered with IANA. The token 6262 value MUST adhere to the ABNF for render tokens defined in Appendix D. 6263 Registrations MUST include a complete specification of parameter usage, 6264 similar in depth to the specifications that appear in this appendix for 6265 "sdp_start" and "identity". 6267 If a party is offered a session description that uses an smf_info 6268 parameter value that is not known to the party, the party MUST NOT 6269 accept the renderer associated with the smf_info parameter. Options 6270 include rejecting the renderer, the payload type, the media stream, or 6271 the entire session description. 6273 We now define the rendering semantics for the "sdp_start" token value in 6274 detail. 6276 The SMFs and RTP MIDI streams in a session description share the same 6277 MIDI name space(s). In the simple case of a single RTP MIDI stream and 6278 a single SMF, the SMF MIDI commands and RTP MIDI commands are merged 6279 into a single name space and presented to the renderer. The indefinite 6280 artifact responsibilities for merged MIDI streams defined in Appendix 6281 C.5 also apply to merging RTP and SMF MIDI data. 6283 If a payload type codes multiple SMFs, the SMF name spaces are presented 6284 as an ordered entity to the renderer. To determine the ordering of SMFs 6285 for a renderer (which SMF is "first", which is "second", etc.), use the 6286 following rules: 6288 o If the renderer uses a single data object, the order of 6289 appearance of the SMFs in the object's internal structure 6290 defines the order of the SMFs (the earliest SMF in the object 6291 is "first", the next SMF in the object is "second", etc.). 6293 o If multiple data objects are encoded for a renderer, the 6294 appearance of each data object in the parameter list 6295 sets the relative order of the SMFs encoded in each 6296 data object (SMFs encoded in parameters that appear 6297 earlier in the list are ordered before SMFs encoded 6298 in parameters that appear later in the list). 6300 o If SMFs are encoded in data objects parameters and in 6301 the parameters defined in C.6.4.2, the relative order 6302 of the data object parameters and C.6.4.2 parameters 6303 in the parameter list sets the relative order of SMFs 6304 (SMFs encoded in parameters that appear earlier in the 6305 list are ordered before SMFs in parameters that appear 6306 later in the list). 6308 Given this ordering of SMFs, we now define the mapping of SMFs to 6309 renderer name spaces. The SMF that appears first for a renderer maps to 6310 the first renderer name space. The SMF that appears second for a 6311 renderer maps to the second renderer name space, etc. If the associated 6312 RTP MIDI streams also form an ordered relationship, the first SMF is 6313 merged with the first name space of the relationship, the second SMF is 6314 merged to the second name space of the relationship, etc. 6316 Unless the streams and the SMFs both use MIDI Time Code, the time offset 6317 between SMF and stream data is unspecified. This restriction limits the 6318 use of SMFs to applications where synchronization is not critical, such 6319 as the transport of System Exclusive commands for renderer 6320 initialization, or human-SMF interactivity. 6322 Finally, we note that each SMF in the sdp_start discussion above encodes 6323 exactly one MIDI name space (16 voice channels + systems). Thus, the 6324 use of the Device Name SMF meta event to specify several MIDI name 6325 spaces in an SMF is not supported for sdp_start. 6327 C.6.4.2. The smf_inline, smf_url, and smf_cid Parameters 6329 In some applications, the renderer data object may not encapsulate SMFs, 6330 but an application may wish to use SMFs in the manner defined in 6331 Appendix C.6.4.1. 6333 The "smf_inline", "smf_url", and "smf_cid" parameters address this 6334 situation. These parameters use the syntax and semantics of the inline, 6335 url, and cid parameters defined in Appendix C.6.3, except that the 6336 encoded data object is an SMF. 6338 The "smf_inline", "smf_url", and "smf_cid" parameters belong to the 6339 "render" parameter that most recently precedes it in the session 6340 description. The "smf_inline", "smf_url", and "smf_cid" parameters MUST 6341 NOT appear in parameter lists that do not use the "render" parameter and 6342 MUST NOT appear before the first use of "render" in the parameter list. 6343 If several "smf_inline", "smf_url", or "smf_cid" parameters appear for a 6344 renderer, the order of the parameters defines the SMF name space 6345 ordering. 6347 C.6.4.3. The chanmask Parameter 6349 The chanmask parameter instructs the renderer to ignore all MIDI voice 6350 commands for certain channel numbers. The parameter value is a 6351 concatenated string of "1" and "0" digits. Each string position maps to 6352 a MIDI voice channel number (system channels may not be masked). A "1" 6353 instructs the renderer to process the voice channel; a "0" instructs the 6354 renderer to ignore the voice channel. 6356 The string length of the chanmask parameter value MUST be 16 (for a 6357 single stream or an identity relationship) or a multiple of 16 (for an 6358 ordered relationship). 6360 The chanmask parameter describes the "render" parameter that most 6361 recently precedes it in the session description; chanmask MUST NOT 6362 appear in parameter lists that do not use the "render" parameter and 6363 MUST NOT appear before the first use of "render" in the parameter list. 6365 The chanmask parameter describes the final MIDI name spaces presented to 6366 the renderer. The SMF and stream components of the MIDI name spaces may 6367 not be independently masked. 6369 If a receiver is offered a session description with a renderer that uses 6370 the chanmask parameter, and if the receiver does not implement the 6371 semantics of the chanmask parameter, the receiver MUST NOT accept the 6372 renderer unless the chanmask parameter value contains only "1"s. 6374 C.6.5. The audio/asc Media Type 6376 In Appendix 11.3, we register the audio/asc media type. The data object 6377 for audio/asc is a binary encoding of the AudioSpecificConfig data block 6378 used to initialize mpeg4-generic streams (Section 6.2 and [MPEGAUDIO]). 6379 Disk files that store this data object use the file extension ".acn". 6381 An mpeg4-generic parameter list MAY use the render, subrender, and rinit 6382 parameters with the audio/asc media type for renderer configuration. 6383 Several restrictions apply to the use of these parameters in 6384 mpeg4-generic parameter lists: 6386 o An mpeg4-generic media description that uses the render parameter 6387 MUST assign the empty string ("") to the mpeg4-generic "config" 6388 parameter. The use of the streamtype, mode, and profile-level-id 6389 parameters MUST follow the normative text in Section 6.2. 6391 o Sessions that use identity or ordered relationships MUST follow 6392 the mpeg4-generic configuration restrictions in Appendix C.5. 6394 o The render parameter MUST be assigned the value "synthetic", 6395 "unknown", "null", or a render value that has been added to 6396 the IANA repository for use with mpeg4-generic RTP MIDI 6397 streams. The "api" token value for render MUST NOT be used. 6399 o If a subrender parameter is present, it MUST immediately follow 6400 the render parameter, and it MUST be assigned the token value 6401 "default" or assigned a subrender value added to the IANA 6402 repository for use with mpeg4-generic RTP MIDI streams. A 6403 subrender parameter assignment may be left out of the renderer 6404 configuration, in which case the implied value of subrender 6405 is the default value of "default". 6407 o If the render parameter is assigned the value "synthetic" 6408 and the subrender parameter has the value "default" (assigned 6409 or implied), the rinit parameter MUST be assigned the value 6410 "audio/asc", and an AudioSpecificConfig data object MUST be encoded 6411 using the mechanisms defined in C.6.2-3. The AudioSpecificConfig 6412 data MUST encode one of the MPEG 4 Audio Object Types defined for 6413 use with mpeg4-generic in Section 6.2. If the subrender value is 6414 other than "default", refer to the subrender registration 6415 for information on the use of "audio/asc" with the renderer. 6417 o If the render parameter is assigned the value "null" or 6418 "unknown", the data object MAY be omitted. 6420 Several general restrictions apply to the use of the audio/asc media 6421 type in RTP MIDI: 6423 o A native stream MUST NOT assign "audio/asc" to rinit. The 6424 audio/asc media type is not intended to be a general-purpose 6425 container for rendering systems outside of MPEG usage. 6427 o The audio/asc media type defines a stored object type; it does 6428 not define semantics for RTP streams. Thus, audio/asc MUST NOT 6429 appear on an rtpmap line of a session description. 6431 Below, we show session description examples for audio/asc. The session 6432 description below uses the inline parameter to code the 6433 AudioSpecificConfig block for a mpeg4-generic General MIDI stream. We 6434 derive the value assigned to the inline parameter in Appendix E.4. The 6435 subrender token value of "default" is implied by the absence of the 6436 subrender parameter in the parameter list. 6438 v=0 6439 o=lazzaro 2520644554 2838152170 IN IP4 first.example.net 6440 s=Example 6441 t=0 0 6442 m=audio 5004 RTP/AVP 96 6443 c=IN IP4 192.0.2.94 6444 a=rtpmap:96 mpeg4-generic/44100 6445 a=fmtp:96 streamtype=5; mode=rtp-midi; config=""; profile-level-id=12; 6446 render=synthetic; rinit="audio/asc"; 6447 inline="egoAAAAaTVRoZAAAAAYAAAABAGBNVHJrAAAABgD/LwAA" 6449 (The a=fmtp line has been wrapped to fit the page to accommodate 6450 memo formatting restrictions; it comprises a single line in SDP.) 6452 The session description below uses the url parameter to code the 6453 AudioSpecificConfig block for the same General MIDI stream: 6455 v=0 6456 o=lazzaro 2520644554 2838152170 IN IP4 first.example.net 6457 s=Example 6458 t=0 0 6459 m=audio 5004 RTP/AVP 96 6460 c=IN IP4 192.0.2.94 6461 a=rtpmap:96 mpeg4-generic/44100 6462 a=fmtp:96 streamtype=5; mode=rtp-midi; config=""; profile-level-id=12; 6463 render=synthetic; rinit="audio/asc"; url="http://example.net/oski.asc"; 6464 cid="xjflsoeiurvpa09itnvlduihgnvet98pa3w9utnuighbuk" 6466 (The a=fmtp line has been wrapped to fit the page to accommodate 6467 memo formatting restrictions; it comprises a single line in SDP.) 6469 C.7. Interoperability 6471 In this appendix, we define interoperability guidelines for two 6472 application areas: 6474 o MIDI content-streaming applications. RTP MIDI is added to 6475 RTSP-based content-streaming servers, so that viewers may 6476 experience MIDI performances (produced by a specified client- 6477 side renderer) in synchronization with other streams (video, 6478 audio). 6480 o Long-distance network musical performance applications. RTP 6481 MIDI is added to SIP-based voice chat or videoconferencing 6482 programs, as an alternative, or as an addition, to audio and/or 6483 video RTP streams. 6485 For each application, we define a core set of functionality that all 6486 implementations MUST implement. 6488 The applications we address in this section are not an exhaustive list 6489 of potential RTP MIDI uses. We expect framework documents for other 6490 applications to be developed, within the IETF or within other 6491 organizations. We discuss other potential application areas for RTP 6492 MIDI in Section 1 of the main text of this memo. 6494 C.7.1. MIDI Content Streaming Applications 6496 In content-streaming applications, a user invokes an RTSP client to 6497 initiate a request to an RTSP server to view a multimedia session. For 6498 example, clicking on a web page link for an Internet Radio channel 6499 launches an RTSP client that uses the link's RTSP URL to contact the 6500 RTSP server hosting the radio channel. 6502 The content may be pre-recorded (for example, on-demand replay of 6503 yesterday's football game) or "live" (for example, football game 6504 coverage as it occurs), but in either case the user is usually an 6505 "audience member" as opposed to a "participant" (as the user would be in 6506 telephony). 6508 Note that these examples describe the distribution of audio content to 6509 an audience member. The interoperability guidelines in this appendix 6510 address RTP MIDI applications of this nature, not applications such as 6511 the transmission of raw MIDI command streams for use in a professional 6512 environment (recording studio, performance stage, etc.). 6514 In an RTSP session, a client accesses a session description that is 6515 "declared" by the server, either via the RTSP DESCRIBE method, or via 6516 other means, such as HTTP or email. The session description defines the 6517 session from the perspective of the client. For example, if a media 6518 line in the session description contains a non-zero port number, it 6519 encodes the server's preference for the client's port numbers for RTP 6520 and RTCP reception. Once media flow begins, the server sends an RTP 6521 MIDI stream to the client, which renders it for presentation, perhaps in 6522 synchrony with video or other audio streams. 6524 We now define the interoperability text for content-streaming RTSP 6525 applications. 6527 In most cases, server interoperability responsibilities are described in 6528 terms of limits on the "reference" session description a server provides 6529 for a performance if it has no information about the capabilities of the 6530 client. The reference session is a "lowest common denominator" session 6531 that maximizes the odds that a client will be able to view the session. 6532 If a server is aware of the capabilities of the client, the server is 6533 free to provide a session description customized for the client in the 6534 DESCRIBE reply. 6536 Clients MUST support unicast UDP RTP MIDI streams that use the recovery 6537 journal with the closed-loop or the anchor sending policies. Clients 6538 MUST be able to interpret stream subsetting and chapter inclusion 6539 parameters in the session description that qualify the sending policies. 6540 Client support of enhanced Chapter C encoding is OPTIONAL. 6542 The reference session description offered by a server MUST send all RTP 6543 MIDI UDP streams as unicast streams that use the recovery journal and 6544 the closed-loop or anchor sending policies. Servers SHOULD use the 6545 stream subsetting and chapter inclusion parameters in the reference 6546 session description, to simplify the rendering task of the client. 6547 Server support of enhanced Chapter C encoding is OPTIONAL. 6549 Clients and servers MUST support the use of RTSP interleaved mode (a 6550 method for interleaving RTP onto the RTSP TCP transport). 6552 Clients MUST be able to interpret the timestamp semantics signalled by 6553 the "comex" value of the tsmode parameter (i.e., the timestamp semantics 6554 of Standard MIDI Files [MIDI]). Servers MUST use the "comex" value for 6555 the "tsmode" parameter in the reference session description. 6557 Clients MUST be able to process an RTP MIDI stream whose packets encode 6558 an arbitrary temporal duration ("media time"). Thus, in practice, 6559 clients MUST implement a MIDI playout buffer. Clients MUST NOT depend 6560 on the presence of rtp_ptime, rtp_maxtime, and guardtime parameters in 6561 the session description in order to process packets, but they SHOULD be 6562 able to use these parameters to improve packet processing. 6564 Servers SHOULD strive to send RTP MIDI streams in the same way media 6565 servers send conventional audio streams: a sequence of packets that 6566 either all code the same temporal duration (non-normative example: 50 ms 6567 packets) or that code one of an integral number of temporal durations 6568 (non-normative example: 50 ms, 100 ms, 250 ms, or 500 ms packets). 6569 Servers SHOULD encode information about the packetization method in the 6570 rtp_ptime and rtp_maxtime parameters in the session description. 6572 Clients MUST be able to examine the render and subrender parameter, to 6573 determine if a multimedia session uses a renderer it supports. Clients 6574 MUST be able to interpret the default "one" value of the "multimode" 6575 parameter, to identify supported renderers from a list of renderer 6576 descriptions. Clients MUST be able to interpret the musicport 6577 parameter, to the degree that it is relevant to the renderers it 6578 supports. Clients MUST be able to interpret the chanmask parameter. 6580 Clients supporting renderers whose data object (as encoded by a 6581 parameter value for "inline") could exceed 300 octets in size MUST 6582 support the url and cid parameters and thus must implement the HTTP 6583 protocol in addition to RTSP. HTTP over TLS [RFC2818] support for data 6584 objects is OPTIONAL. 6586 Servers MUST specify complete rendering systems for RTP MIDI streams. 6587 Note that a minimal RTP MIDI native stream does not meet this 6588 requirement (Section 6.1), as the rendering method for such streams is 6589 "not specified". 6591 At the time of this memo, the only way for servers to specify a complete 6592 rendering system is to specify an mpeg4-generic RTP MIDI stream in mode 6593 rtp-midi (Section 6.2 and C.6.5). As a consequence, the only rendering 6594 systems that may be presently used are General MIDI [MIDI], DLS 2 6595 [DLS2], or Structured Audio [MPEGSA]. Note that the maximum inline 6596 value for General MIDI is well under 300 octets (and thus clients need 6597 not support the "url" parameter), and that the maximum inline values for 6598 DLS 2 and Structured Audio may be much larger than 300 octets (and thus 6599 clients MUST support the url parameter). 6601 We anticipate that the owners of rendering systems (both standardized 6602 and proprietary) will register subrender parameters for their renderers. 6603 Once registration occurs, native RTP MIDI sessions may use render and 6604 subrender (Appendix C.6.2) to specify complete rendering systems for 6605 RTSP content-streaming multimedia sessions. 6607 Servers MUST NOT use the sdp_start value for the smf_info parameter in 6608 the reference session description, as this use would require that 6609 clients be able to parse and render Standard MIDI Files. 6611 Clients MUST support mpeg4-generic mode rtp-midi General MIDI (GM) 6612 sessions, at a polyphony limited by the hardware capabilities of the 6613 client. This requirement provides a "lowest common denominator" 6614 rendering system for content providers to target. Note that this 6615 requirement does not force implementors of a non-GM renderer (such as 6616 DLS 2 or Structured Audio) to add a second rendering engine. Instead, a 6617 client may satisfy the requirement by including a set of voice patches 6618 that implement the GM instrument set, and using this emulation for 6619 mpeg4-generic GM sessions. 6621 It is RECOMMENDED that servers use General MIDI as the renderer for the 6622 reference session description, because clients are REQUIRED to support 6623 it. We do not require General MIDI as the reference renderer, because 6624 for normative applications it is an inappropriate choice. Servers using 6625 General MIDI as a "lowest common denominator" renderer SHOULD use 6626 Universal Real-Time SysEx MIP messages [SPMIDI] to communicate the 6627 priority of voices to polyphony-limited clients. 6629 C.7.2. MIDI Network Musical Performance Applications 6631 In Internet telephony and videoconferencing applications, parties 6632 interact over an IP network as they would face-to-face. Good user 6633 experiences require low end-to-end audio latency and tight audiovisual 6634 synchronization (for "lip-sync"). The Session Initiation Protocol (SIP, 6635 [RFC3261]) is used for session management. 6637 In this appendix section, we define interoperability guidelines for 6638 using RTP MIDI streams in interactive SIP applications. Our primary 6639 interest is supporting Network Musical Performances (NMP), where 6640 musicians in different locations interact over the network as if they 6641 were in the same room. See [NMP] for background information on NMP, and 6642 see [RFC4696] for a discussion of low-latency RTP MIDI implementation 6643 techniques for NMP. 6645 Note that the goal of NMP applications is telepresence: the parties 6646 should hear audio that is close to what they would hear if they were in 6647 the same room. The interoperability guidelines in this appendix address 6648 RTP MIDI applications of this nature, not applications such as the 6649 transmission of raw MIDI command streams for use in a professional 6650 environment (recording studio, performance stage, etc.). 6652 We focus on session management for two-party unicast sessions that 6653 specify a renderer for RTP MIDI streams. Within this limited scope, the 6654 guidelines defined here are sufficient to let applications interoperate. 6655 We define the REQUIRED capabilities of RTP MIDI senders and receivers in 6656 NMP sessions and define how session descriptions exchanged are used to 6657 set up network musical performance sessions. 6659 SIP lets parties negotiate details of the session, using the 6660 Offer/Answer protocol [RFC3264]. However, RTP MIDI has so many 6661 parameters that "blind" negotiations between two parties using different 6662 applications might not yield a common session configuration. 6664 Thus, we now define a set of capabilities that NMP parties MUST support. 6665 Session description offers whose options lie outside the envelope of 6666 REQUIRED party behavior risk negotiation failure. We also define 6667 session description idioms that the RTP MIDI part of an offer MUST 6668 follow, in order to structure the offer for simpler analysis. 6670 We use the term "offerer" for the party making a SIP offer, and 6671 "answerer" for the party answering the offer. Finally, we note that 6672 unless it is qualified by the adjective "sender" or "receiver", a 6673 statement that a party MUST support X implies that it MUST support X for 6674 both sending and receiving. 6676 If an offerer wishes to define a "sendrecv" RTP MIDI stream, it may use 6677 a true sendrecv session or the "virtual sendrecv" construction described 6678 in the preamble to Appendix C and in Appendix C.5. A true sendrecv 6679 session indicates that the offerer wishes to participate in a session 6680 where both parties use identically configured renderers. A virtual 6681 sendrecv session indicates that the offerer is willing to participate in 6682 a session where the two parties may be using different renderer 6683 configurations. Thus, parties MUST be prepared to see both real and 6684 virtual sendrecv sessions in an offer. 6686 Parties MUST support unicast UDP transport of RTP MIDI streams. These 6687 streams MUST use the recovery journal with the closed-loop or anchor 6688 sending policies. These streams MUST use the stream subsetting and 6689 chapter inclusion parameters to declare the types of MIDI commands that 6690 will be sent on the stream (for sendonly streams) or will be processed 6691 (for recvonly streams), including the size limits on System Exclusive 6692 commands. Support of enhanced Chapter C encoding is OPTIONAL. 6694 Note that both TCP and multicast UDP support are OPTIONAL. We make TCP 6695 OPTIONAL because we expect NMP renderers to rely on data objects 6696 (signalled by "rinit" and associated parameters) for initialization at 6697 the start of the session, and only to use System Exclusive commands for 6698 interactive control during the session. These interactive commands are 6699 small enough to be protected via the recovery journal mechanism of RTP 6700 MIDI UDP streams. 6702 We now discuss timestamps, packet timing, and packet sending algorithms. 6704 Recall that the tsmode parameter controls the semantics of command 6705 timestamps in the MIDI list of RTP packets. 6707 Parties MUST support clock rates of 44.1 kHz, 48 kHz, 88.2 kHz, and 96 6708 kHz. Parties MUST support streams using the "comex", "async", and 6709 "buffer" tsmode values. Recvonly offers MUST offer the default "comex". 6711 Parties MUST support a wide range of packet temporal durations: from 6712 rtp_ptime and rtp_maxptime values of 0, to rtp_ptime and rtp_maxptime 6713 values that code 100 ms. Thus, receivers MUST be able to implement a 6714 playout buffer. 6716 Offers and answers MUST present rtp_ptime, rtp_maxptime, and guardtime 6717 values that support the latency that users would expect in the 6718 application, subject to bandwidth constraints. As senders MUST abide by 6719 values set for these parameters in a session description, a receiver 6720 SHOULD use these values to size its playout buffer to produce the lowest 6721 reliable latency for a session. Implementors should refer to [RFC4696] 6722 for information on packet sending algorithms for latency-sensitive 6723 applications. Parties MUST be able to implement the semantics of the 6724 guardtime parameter, for times from 5 ms to 5000 ms. 6726 We now discuss the use of the render parameter. 6728 Sessions MUST specify complete rendering systems for all RTP MIDI 6729 streams. Note that a minimal RTP MIDI native stream does not meet this 6730 requirement (Section 6.1), as the rendering method for such streams is 6731 "not specified". 6733 At the time this writing, the only way for parties to specify a complete 6734 rendering system is to specify an mpeg4-generic RTP MIDI stream in mode 6735 rtp-midi (Section 6.2 and C.6.5). We anticipate that the owners of 6736 rendering systems (both standardized and proprietary) will register 6737 subrender values for their renderers. Once IANA registration occurs, 6738 native RTP MIDI sessions may use render and subrender (Appendix C.6.2) 6739 to specify complete rendering systems for SIP network musical 6740 performance multimedia sessions. 6742 All parties MUST support General MIDI (GM) sessions, at a polyphony 6743 limited by the hardware capabilities of the party. This requirement 6744 provides a "lowest common denominator" rendering system, without which 6745 practical interoperability will be quite difficult. When using GM, 6746 parties SHOULD use Universal Real-Time SysEx MIP messages [SPMIDI] to 6747 communicate the priority of voices to polyphony-limited clients. 6749 Note that this requirement does not force implementors of a non-GM 6750 renderer (for mpeg4-generic sessions, DLS 2, or Structured Audio) to add 6751 a second rendering engine. Instead, a client may satisfy the 6752 requirement by including a set of voice patches that implement the GM 6753 instrument set, and using this emulation for mpeg4-generic GM sessions. 6754 We require GM support so that an offerer that wishes to maximize 6755 interoperability may do so by offering GM if its preferred renderer is 6756 not accepted by the answerer. 6758 Offerers MUST NOT present several renderers as options in a session 6759 description by listing several payload types on a media line, as Section 6760 2.1 uses this construct to let a party send several RTP MIDI streams in 6761 the same RTP session. 6763 Instead, an offerer wishing to present rendering options SHOULD offer a 6764 single payload type that offers several renderers. In this construct, 6765 the parameter list codes a list of render parameters (each followed by 6766 its support parameters). As discussed in Appendix C.6.1, the order of 6767 renderers in the list declares the offerer's preference. The "unknown" 6768 and "null" values MUST NOT appear in the offer. The answer MUST set all 6769 render values except the desired renderer to "null". Thus, "unknown" 6770 MUST NOT appear in the answer. 6772 We use SHOULD instead of MUST in the first sentence in the paragraph 6773 above, because this technique does not work in all situations (example: 6774 an offerer wishes to offer both mpeg4-generic renderers and native RTP 6775 MIDI renderers as options). In this case, the offerer MUST present a 6776 series of session descriptions, each offering a single renderer, until 6777 the answerer accepts a session description. 6779 Parties MUST support the musicport, chanmask, subrender, rinit, and 6780 inline parameters. Parties supporting renderers whose data object (as 6781 encoded by a parameter value for "inline") could exceed 300 octets in 6782 size MUST support the url and cid parameters and thus must implement the 6783 HTTP protocol. HTTP over TLS [RFC2818] support for data objects is 6784 OPTIONAL. Note that in mpeg4-generic, General MIDI data objects cannot 6785 exceed 300 octets, but DLS 2 and Structured Audio data objects may. 6786 Support for the other rendering parameters (smf_cif, smf_info, 6787 smf_inline, smf_url) is OPTIONAL. 6789 Thus far in this document, our discussion has assumed that the only MIDI 6790 flows that drive a renderer are the network flows described in the 6791 session description. In NMP applications, this assumption would require 6792 two rendering engines: one for local use by a party, a second for the 6793 remote party. 6795 In practice, applications may wish to have both parties share a single 6796 rendering engine. In this case, the session description MUST use a 6797 virtual sendrecv session and MUST use the stream subsetting and chapter 6798 inclusion parameters to allocate which MIDI channels are intended for 6799 use by a party. If two parties are sharing a MIDI channel, the 6800 application MUST ensure that appropriate MIDI merging occurs at the 6801 input to the renderer. 6803 We now discuss the use of (non-MIDI) audio streams in the session. 6805 Audio streams may be used for two purposes: as a "talkback" channel for 6806 parties to converse, or as a way to conduct a performance that includes 6807 MIDI and audio channels. In the latter case, offers MUST use sample 6808 rates and the packet temporal durations for the audio and MIDI streams 6809 that support low-latency synchronized rendering. 6811 We now show an example of an offer/answer exchange in a network musical 6812 performance application (next page). 6814 Below, we show an offer that complies with the interoperability text in 6815 this appendix section. 6817 v=0 6818 o=first 2520644554 2838152170 IN IP4 first.example.net 6819 s=Example 6820 t=0 0 6821 a=group:FID 1 2 6822 c=IN IP4 192.0.2.94 6823 m=audio 16112 RTP/AVP 96 6824 a=recvonly 6825 a=mid:1 6826 a=rtpmap:96 mpeg4-generic/44100 6827 a=fmtp:96 streamtype=5; mode=rtp-midi; config=""; profile-level-id=12; 6828 cm_unused=ABCFGHJKMNPQTVWXYZ; cm_used=2NPTW; 6829 cm_used=2C0.1.7.10.11.64.121.123; cm_used=2M0.1.2; 6830 cm_used=X0-16; ch_never=ABCDEFGHJKMNPQTVWXYZ; 6831 ch_default=2NPTW; ch_default=2C0.1.7.10.11.64.121.123; 6832 ch_default=2M0.1.2; cm_default=X0-16; 6833 rtp_ptime=0; rtp_maxptime=0; guardtime=44100; 6834 musicport=1; render=synthetic; rinit="audio/asc"; 6835 inline="egoAAAAaTVRoZAAAAAYAAAABAGBNVHJrAAAABgD/LwAA" 6836 m=audio 16114 RTP/AVP 96 6837 a=sendonly 6838 a=mid:2 6839 a=rtpmap:96 mpeg4-generic/44100 6840 a=fmtp:96 streamtype=5; mode=rtp-midi; config=""; profile-level-id=12; 6841 cm_unused=ABCFGHJKMNPQTVWXYZ; cm_used=1NPTW; 6842 cm_used=1C0.1.7.10.11.64.121.123; cm_used=1M0.1.2; 6843 cm_used=X0-16; ch_never=ABCDEFGHJKMNPQTVWXYZ; 6844 ch_default=1NPTW; ch_default=1C0.1.7.10.11.64.121.123; 6845 ch_default=1M0.1.2; cm_default=X0-16; 6846 rtp_ptime=0; rtp_maxptime=0; guardtime=44100; 6847 musicport=1; render=synthetic; rinit="audio/asc"; 6848 inline="egoAAAAaTVRoZAAAAAYAAAABAGBNVHJrAAAABgD/LwAA" 6850 (The a=fmtp lines have been wrapped to fit the page to accommodate 6851 memo formatting restrictions; it comprises a single line in SDP.) 6853 The owner line (o=) identifies the session owner as "first". 6855 The session description defines two MIDI streams: a recvonly stream on 6856 which "first" receives a performance, and a sendonly stream that "first" 6857 uses to send a performance. The recvonly port number encodes the ports 6858 on which "first" wishes to receive RTP (16112) and RTCP (16113) media at 6859 IP4 address 192.0.2.94. The sendonly port number encodes the port on 6860 which "first" wishes to receive RTCP for the stream (16115). 6862 The musicport parameters code that the two streams share and identity 6863 relationship and thus form a virtual sendrecv stream. 6865 Both streams are mpeg4-generic RTP MIDI streams that specify a General 6866 MIDI renderer. The stream subsetting parameters code that the recvonly 6867 stream uses MIDI channel 1 exclusively for voice commands, and that the 6868 sendonly stream uses MIDI channel 2 exclusively for voice commands. 6869 This mapping permits the application software to share a single renderer 6870 for local and remote performers. 6872 We now show the answer to the offer. 6874 v=0 6875 o=second 2520644554 2838152170 IN IP4 second.example.net 6876 s=Example 6877 t=0 0 6878 a=group:FID 1 2 6879 c=IN IP4 192.0.2.105 6880 m=audio 5004 RTP/AVP 96 6881 a=sendonly 6882 a=mid:1 6883 a=rtpmap:96 mpeg4-generic/44100 6884 a=fmtp:96 streamtype=5; mode=rtp-midi; config=""; profile-level-id=12; 6885 cm_unused=ABCFGHJKMNPQTVWXYZ; cm_used=2NPTW; 6886 cm_used=2C0.1.7.10.11.64.121.123; cm_used=2M0.1.2; 6887 cm_used=X0-16; ch_never=ABCDEFGHJKMNPQTVWXYZ; 6888 ch_default=2NPTW; ch_default=2C0.1.7.10.11.64.121.123; 6889 ch_default=2M0.1.2; cm_default=X0-16; 6890 rtp_ptime=0; rtp_maxptime=882; guardtime=44100; 6891 musicport=1; render=synthetic; rinit="audio/asc"; 6892 inline="egoAAAAaTVRoZAAAAAYAAAABAGBNVHJrAAAABgD/LwAA" 6893 m=audio 5006 RTP/AVP 96 6894 a=recvonly 6895 a=mid:2 6896 a=rtpmap:96 mpeg4-generic/44100 6897 a=fmtp:96 streamtype=5; mode=rtp-midi; config=""; profile-level-id=12; 6898 cm_unused=ABCFGHJKMNPQTVWXYZ; cm_used=1NPTW; 6899 cm_used=1C0.1.7.10.11.64.121.123; cm_used=1M0.1.2; 6900 cm_used=X0-16; ch_never=ABCDEFGHJKMNPQTVWXYZ; 6901 ch_default=1NPTW; ch_default=1C0.1.7.10.11.64.121.123; 6902 ch_default=1M0.1.2; cm_default=X0-16; 6903 rtp_ptime=0; rtp_maxptime=0; guardtime=88200; 6904 musicport=1; render=synthetic; rinit="audio/asc"; 6905 inline="egoAAAAaTVRoZAAAAAYAAAABAGBNVHJrAAAABgD/LwAA" 6907 (The a=fmtp lines have been wrapped to fit the page to accommodate 6908 memo formatting restrictions; they comprise single lines in SDP.) 6910 The owner line (o=) identifies the session owner as "second". 6912 The port numbers for both media streams are non-zero; thus, "second" has 6913 accepted the session description. The stream marked "sendonly" in the 6914 offer is marked "recvonly" in the answer, and vice versa, coding the 6915 different view of the session held by "session". The IP4 number 6916 (192.0.2.105) and the RTP (5004 and 5006) and RTCP (5005 and 5007) have 6917 been changed by "second" to match its transport wishes. 6919 In addition, "second" has made several parameter changes: rtp_maxptime 6920 for the sendonly stream has been changed to code 2 ms (441 in clock 6921 units), and the guardtime for the recvonly stream has been doubled. As 6922 these parameter modifications request capabilities that are REQUIRED to 6923 be implemented by interoperable parties, "second" can make these changes 6924 with confidence that "first" can abide by them. 6926 D. Parameter Syntax Definitions 6928 In this appendix, we define the syntax for the RTP MIDI media type 6929 parameters in Augmented Backus-Naur Form (ABNF, [RFC5234]). When using 6930 these parameters with SDP, all parameters MUST appear on a single fmtp 6931 attribute line of an RTP MIDI media description. For mpeg4-generic RTP 6932 MIDI streams, this line MUST also include any mpeg4-generic parameters 6933 (usage described in Section 6.2). An fmtp attribute line may be defined 6934 (after [RFC3640]) as: 6936 ; 6937 ; SDP fmtp line definition 6938 ; 6940 fmtp = "a=fmtp:" token SP param-assign 0*(";" SP param-assign) CRLF 6942 where codes the RTP payload type. Note that white space MUST 6943 NOT appear between the "a=fmtp:" and the RTP payload type. 6945 We now define the syntax of the parameters defined in Appendix C. The 6946 definition takes the form of the incremental assembly of the token. See [RFC3640] for the syntax of the mpeg4-generic 6948 parameters discussed in Section 6.2. 6950 ; 6951 ; 6952 ; top-level definition for all parameters 6953 ; 6954 ; 6956 ; 6957 ; Parameters defined in Appendix C.1 6959 param-assign = ("cm_unused=" (([channel-list] command-type 6960 [f-list]) / sysex-data)) 6962 param-assign =/ ("cm_used=" (([channel-list] command-type 6963 [f-list]) / sysex-data)) 6965 ; 6966 ; Parameters defined in Appendix C.2 6968 param-assign =/ ("j_sec=" ("none" / "recj" / ietf-extension)) 6970 param-assign =/ ("j_update=" ("anchor" / "closed-loop" / 6971 "open-loop" / ietf-extension)) 6973 param-assign =/ ("ch_default=" (([channel-list] chapter-list 6974 [f-list]) / sysex-data)) 6976 param-assign =/ ("ch_never=" (([channel-list] chapter-list 6977 [f-list]) / sysex-data)) 6979 param-assign =/ ("ch_anchor=" (([channel-list] chapter-list 6980 [f-list]) / sysex-data)) 6982 ; 6983 ; Parameters defined in Appendix C.3 6985 param-assign =/ ("tsmode=" ("comex" / "async" / "buffer")) 6987 param-assign =/ ("linerate=" nonzero-four-octet) 6989 param-assign =/ ("octpos=" ("first" / "last")) 6991 param-assign =/ ("mperiod=" nonzero-four-octet) 6993 ; 6994 ; Parameter defined in Appendix C.4 6996 param-assign =/ ("guardtime=" nonzero-four-octet) 6998 param-assign =/ ("rtp_ptime=" four-octet) 7000 param-assign =/ ("rtp_maxptime=" four-octet) 7002 ; 7003 ; Parameters defined in Appendix C.5 7005 param-assign =/ ("musicport=" four-octet) 7007 ; 7008 ; Parameters defined in Appendix C.6 7010 param-assign =/ ("chanmask=" 1*( 16(BIT) )) 7012 param-assign =/ ("cid=" DQUOTE cid-block DQUOTE) 7014 param-assign =/ ("inline=" DQUOTE base-64-block DQUOTE) 7016 param-assign =/ ("multimode=" ("all" / "one")) 7018 param-assign =/ ("render=" ("synthetic" / "api" / "null" / 7019 "unknown" / extension)) 7021 param-assign =/ ("rinit=" mime-type "/" mime-subtype) 7023 param-assign =/ ("smf_cid=" DQUOTE cid-block DQUOTE) 7025 param-assign =/ ("smf_info=" ("ignore" / "identity" / 7026 "sdp_start" / extension)) 7028 param-assign =/ ("smf_inline=" DQUOTE base-64-block DQUOTE) 7030 param-assign =/ ("smf_url=" DQUOTE uri-element DQUOTE) 7032 param-assign =/ ("subrender=" ("default" / extension)) 7034 param-assign =/ ("url=" DQUOTE uri-element DQUOTE) 7036 ; 7037 ; list definitions for the cm_ command-type 7038 ; 7040 command-type = [A] [B] [C] [F] [G] [H] [J] [K] [M] 7041 [N] [P] [Q] [T] [V] [W] [X] [Y] [Z] 7043 ; 7044 ; list definitions for the ch_ chapter-list 7045 ; 7047 chapter-list = [A] [B] [C] [D] [E] [F] [G] [H] [J] [K] 7048 [M] [N] [P] [Q] [T] [V] [W] [X] [Y] [Z] 7050 ; 7051 ; list definitions for the channel-list (used in ch_* / cm_* params) 7052 ; 7054 channel-list = midi-chan-element *("." midi-chan-element) 7056 midi-chan-element = midi-chan / midi-chan-range 7058 midi-chan-range = midi-chan "-" midi-chan 7059 ; 7060 ; decimal value of left midi-chan 7061 ; MUST be strictly less than 7062 ; decimal value of right midi-chan 7064 midi-chan = DIGIT / ("1" %x30-35) ; "0" .. "15" 7065 ; 7066 ; list definitions for the ch_ field list (f-list) 7067 ; 7069 f-list = midi-field-element *("." midi-field-element) 7071 midi-field-element = midi-field / midi-field-range 7073 midi-field-range = midi-field "-" midi-field 7074 ; 7075 ; decimal value of left midi-field 7076 ; MUST be strictly less than 7077 ; decimal value of right midi-field 7079 midi-field = four-octet 7080 ; 7081 ; large range accommodates Chapter M 7082 ; RPN (0-16383) and NRPN (16384-32767) 7083 ; parameters, and Chapter X octet sizes. 7085 ; 7086 ; definitions for ch_ sysex-data 7087 ; 7089 sysex-data = "__" h-list *("_" h-list) "__" 7091 h-list = hex-field-element *("." hex-field-element) 7093 hex-field-element = hex-octet / hex-field-range 7095 hex-field-range = hex-octet "-" hex-octet 7096 ; 7097 ; hexadecimal value of left hex-octet 7098 ; MUST be strictly less than hexadecimal 7099 ; value of right hex-octet 7101 hex-octet = %x30-37 U-HEXDIG 7102 ; 7103 ; rewritten special case of hex-octet in [RFC2045] 7104 ; (page 23). 7105 ; note that a-f are not permitted, only A-F. 7106 ; hex-octet values MUST NOT exceed 0x7F. 7108 ; 7109 ; definitions for rinit parameter 7110 ; 7112 mime-type = "audio" / "application" 7113 mime-subtype = subtype-name 7114 ; 7115 ; See Appendix C.6.2 for registration 7116 ; requirements for rinit type/subtypes. 7117 ; 7118 ; subtype-name is defined in [RFC4288], 7119 ; Section 4.2. 7121 ; 7122 ; definitions for base64 encoding 7123 ; copied from [RFC4566] 7124 ; changes from [RFC4566] to improve automatic syntax checking 7125 ; 7127 base-64-block = *base64-unit [base64-pad] 7129 base64-unit = 4(base64-char) 7131 base64-pad = (2(base64-char) "==") / (3(base64-char) "=") 7133 base64-char = %x41-5A / %x61-7A / %x30-39 / "+" / "/" 7134 ; A-Z, a-z, 0-9, "+" and "/" 7136 ; 7137 ; generic rules 7138 ; 7140 ietf-extension = token 7141 ; 7142 ; may only be defined in standards-track RFCs 7144 extension = token 7145 ; 7146 ; may be defined 7147 ; by filing a registration with IANA 7149 nonzero-four-octet = (NZ-DIGIT 0*8(DIGIT)) 7150 / (%x31-33 9(DIGIT)) 7151 / ("4" %x30-31 8(DIGIT)) 7152 / ("42" %x30-38 7(DIGIT)) 7153 / ("429" %x30-33 6(DIGIT)) 7154 / ("4294" %x30-38 5(DIGIT)) 7155 / ("42949" %x30-35 4(DIGIT)) 7156 / ("429496" %x30-36 3(DIGIT)) 7157 / ("4294967" %x30-31 2(DIGIT)) 7158 / ("42949672" %x30-38 (DIGIT)) 7159 / ("429496729" %x30-34) 7160 ; 7161 ; unsigned encoding of non-zero 32-bit value: 7162 ; 1 .. 4294967295 7164 four-octet = "0" / nonzero-four-octet 7165 ; 7166 ; unsigned encoding of 32-bit value: 7167 ; 0 .. 4294967295 7169 uri-element = URI-reference 7170 ; as defined in [RFC3986] 7172 token = 1*token-char 7173 ; copied from [RFC4566] 7175 token-char = %x21 / %x23-27 / %x2A-2B / %x2D-2E / 7176 %x30-39 / %x41-5A / %x5E-7E 7177 ; copied from [RFC4566] 7179 cid-block = 1*cid-char 7181 cid-char = token-char 7182 cid-char =/ "@" 7183 cid-char =/ "," 7184 cid-char =/ ";" 7185 cid-char =/ ":" 7186 cid-char =/ "\" 7187 cid-char =/ "/" 7188 cid-char =/ "[" 7189 cid-char =/ "]" 7190 cid-char =/ "?" 7191 cid-char =/ "=" 7192 ; 7193 ; - add back in the tspecials [RFC2045], except 7194 ; for DQUOTE and the non-email safe ( ) < > 7195 ; - note that the definitions above ensure that 7196 ; cid-block is always enclosed with DQUOTEs 7198 A = %x41 ; uppercase only letters used above 7199 B = %x42 7200 C = %x43 7201 D = %x44 7202 E = %x45 7203 F = %x46 7204 G = %x47 7205 H = %x48 7206 J = %x4A 7207 K = %x4B 7208 M = %x4D 7209 N = %x4E 7210 P = %x50 7211 Q = %x51 7212 T = %x54 7213 V = %x56 7214 W = %x57 7215 X = %x58 7216 Y = %x59 7217 Z = %x5A 7219 NZ-DIGIT = %x31-39 ; non-zero decimal digit 7221 U-HEXDIG = DIGIT / A / B / C / D / E / F 7222 ; variant of HEXDIG [RFC5234] : 7223 ; hexadecimal digit using uppercase A-F only 7225 ; the rules below are from the Core Rules from [RFC5234] 7227 BIT = "0" / "1" 7229 DQUOTE = %x22 ; " (Double Quote) 7231 DIGIT = %x30-39 ; 0-9 7233 ; external references 7234 ; URI-reference: from [RFC3986] 7235 ; subtype-name: from [RFC4288] 7237 ; 7238 ; End of ABNF 7240 The mpeg4-generic RTP payload [RFC3640] defines a "mode" parameter that 7241 signals the type of MPEG stream in use. We add a new mode value, "rtp- 7242 midi", using the ABNF rule below: 7244 ; 7245 ; mpeg4-generic mode parameter extension 7246 ; 7248 mode =/ "rtp-midi" 7249 ; as described in Section 6.2 of this memo 7251 E. A MIDI Overview for Networking Specialists 7253 This appendix presents an overview of the MIDI standard, for the benefit 7254 of networking specialists new to musical applications. Implementors 7255 should consult [MIDI] for a normative description of MIDI. 7257 Musicians make music by performing a controlled sequence of physical 7258 movements. For example, a pianist plays by coordinating a series of key 7259 presses, key releases, and pedal actions. MIDI represents a musical 7260 performance by encoding these physical gestures as a sequence of MIDI 7261 commands. This high-level musical representation is compact but 7262 fragile: one lost command may be catastrophic to the performance. 7264 MIDI commands have much in common with the machine instructions of a 7265 microprocessor. MIDI commands are defined as binary elements. 7266 Bitfields within a MIDI command have a regular structure and a 7267 specialized purpose. For example, the upper nibble of the first command 7268 octet (the opcode field) codes the command type. MIDI commands may 7269 consist of an arbitrary number of complete octets, but most MIDI 7270 commands are 1, 2, or 3 octets in length. 7272 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 7273 | Channel Voice Messages | Bitfield Pattern | 7274 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 7275 | NoteOff (end a note) | 1000cccc 0nnnnnnn 0vvvvvvv | 7276 |-------------------------------------------------------------| 7277 | NoteOn (start a note) | 1001cccc 0nnnnnnn 0vvvvvvv | 7278 |-------------------------------------------------------------| 7279 | PTouch (Polyphonic Aftertouch) | 1010cccc 0nnnnnnn 0aaaaaaa | 7280 |-------------------------------------------------------------| 7281 | CControl (Controller Change) | 1011cccc 0xxxxxxx 0yyyyyyy | 7282 |-------------------------------------------------------------| 7283 | PChange (Program Change) | 1100cccc 0ppppppp | 7284 |-------------------------------------------------------------| 7285 | CTouch (Channel Aftertouch) | 1101cccc 0aaaaaaa | 7286 |-------------------------------------------------------------| 7287 | PWheel (Pitch Wheel) | 1110cccc 0xxxxxxx 0yyyyyyy | 7288 ------------------------------------------------------------- 7290 Figure E.1 -- MIDI Channel Messages 7292 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 7293 | System Common Messages | Bitfield Pattern | 7294 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 7295 | System Exclusive | 11110000, followed by a | 7296 | | list of 0xxxxxx octets, | 7297 | | followed by 11110111 | 7298 |-------------------------------------------------------------| 7299 | MIDI Time Code Quarter Frame | 11110001 0xxxxxxx | 7300 |-------------------------------------------------------------| 7301 | Song Position Pointer | 11110010 0xxxxxxx 0yyyyyyy | 7302 |-------------------------------------------------------------| 7303 | Song Select | 11110011 0xxxxxxx | 7304 |-------------------------------------------------------------| 7305 | Undefined | 11110100 | 7306 |-------------------------------------------------------------| 7307 | Undefined | 11110101 | 7308 |-------------------------------------------------------------| 7309 | Tune Request | 11110110 | 7310 |-------------------------------------------------------------| 7311 | System Exclusive End Marker | 11110111 | 7312 ------------------------------------------------------------- 7314 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 7315 | System Realtime Messages | Bitfield Pattern | 7316 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 7317 | Clock | 11111000 | 7318 |-------------------------------------------------------------| 7319 | Undefined | 11111001 | 7320 |-------------------------------------------------------------| 7321 | Start | 11111010 | 7322 |-------------------------------------------------------------| 7323 | Continue | 11111011 | 7324 |-------------------------------------------------------------| 7325 | Stop | 11111100 | 7326 |-------------------------------------------------------------| 7327 | Undefined | 11111101 | 7328 |-------------------------------------------------------------| 7329 | Active Sense | 11111110 | 7330 |-------------------------------------------------------------| 7331 | System Reset | 11111111 | 7332 ------------------------------------------------------------- 7334 Figure E.2 -- MIDI System Messages 7336 Figure E.1 and E.2 show the MIDI command family. There are three major 7337 classes of commands: voice commands (opcode field values in the range 7338 0x8 through 0xE), system common commands (opcode field 0xF, commands 7339 0xF0 through 0xF7), and system real-time commands (opcode field 0xF, 7340 commands 0xF8 through 0xFF). Voice commands code the musical gestures 7341 for each timbre in a composition. Systems commands perform functions 7342 that usually affect all voice channels, such as System Reset (0xFF). 7344 E.1. Commands Types 7346 Voice commands execute on one of 16 MIDI channels, as coded by its 4-bit 7347 channel field (field cccc in Figure E.1). In most applications, notes 7348 for different timbres are assigned to different channels. To support 7349 applications that require more than 16 channels, MIDI systems use 7350 several MIDI command streams in parallel, to yield 32, 48, or 64 MIDI 7351 channels. 7353 As an example of a voice command, consider a NoteOn command (opcode 7354 0x9), with binary encoding 1001cccc 0nnnnnnn 0aaaaaaa. This command 7355 signals the start of a musical note on MIDI channel cccc. The note has 7356 a pitch coded by the note number nnnnnnn, and an onset amplitude coded 7357 by note velocity aaaaaaa. 7359 Other voice commands signal the end of notes (NoteOff, opcode 0x8), map 7360 a specific timbre to a MIDI channel (PChange, opcode 0xC), or set the 7361 value of parameters that modulate the timbral quality (all other voice 7362 commands). The exact meaning of most voice channel commands depends on 7363 the rendering algorithms the MIDI receiver uses to generate sound. In 7364 most applications, a MIDI sender has a model (in some sense) of the 7365 rendering method used by the receiver. 7367 System commands perform a variety of global tasks in the stream, 7368 including "sequencer" playback control of pre-recorded MIDI commands 7369 (the Song Position Pointer, Song Select, Clock, Start, Continue, and 7370 Stop messages), SMPTE time code (the MIDI Time Code Quarter Frame 7371 command), and the communication of device-specific data (the System 7372 Exclusive messages). 7374 E.2. Running Status 7376 All MIDI command bitfields share a special structure: the leading bit of 7377 the first octet is set to 1, and the leading bit of all subsequent 7378 octets is set to 0. This structure supports a data compression system, 7379 called running status [MIDI], that improves the coding efficiency of 7380 MIDI. 7382 In running status coding, the first octet of a MIDI voice command may be 7383 dropped if it is identical to the first octet of the previous MIDI voice 7384 command. This rule, in combination with a convention to consider NoteOn 7385 commands with a null third octet as NoteOff commands, supports the 7386 coding of note sequences using two octets per command. 7388 Running status coding is only used for voice commands. The presence of 7389 a system common message in the stream cancels running status mode for 7390 the next voice command. However, system real-time messages do not 7391 cancel running status mode. 7393 E.3. Command Timing 7395 The bitfield formats in Figures E.1 and E.2 do not encode the execution 7396 time for a command. Timing information is not a part of the MIDI 7397 command syntax itself; different applications of the MIDI command 7398 language use different methods to encode timing. 7400 For example, the MIDI command set acts as the transport layer for MIDI 7401 1.0 DIN cables [MIDI]. MIDI cables are short asynchronous serial lines 7402 that facilitate the remote operation of musical instruments and audio 7403 equipment. Timestamps are not sent over a MIDI 1.0 DIN cable. Instead, 7404 the standard uses an implicit "time of arrival" code. Receivers execute 7405 MIDI commands at the moment of arrival. 7407 In contrast, Standard MIDI Files (SMFs, [MIDI]), a file format for 7408 representing complete musical performances, add an explicit timestamp to 7409 each MIDI command, using a delta encoding scheme that is optimized for 7410 statistics of musical performance. SMF timestamps usually code timing 7411 using the metric notation of a musical score. SMF meta-events are used 7412 to add a tempo map to the file, so that score beats may be accurately 7413 converted into units of seconds during rendering. 7415 E.4. AudioSpecificConfig Templates for MMA Renderers 7417 In Section 6.2 and Appendix C.6.5, we describe how session descriptions 7418 include an AudioSpecificConfig data block to specify a MIDI rendering 7419 algorithm for mpeg4-generic RTP MIDI streams. 7421 The bitfield format of AudioSpecificConfig is defined in [MPEGAUDIO]. 7422 StructuredAudioSpecificConfig, a key data structure coded in 7423 AudioSpecificConfig, is defined in [MPEGSA]. 7425 For implementors wishing to specify Structured Audio renderers, a full 7426 understanding of [MPEGSA] and [MPEGAUDIO] is essential. However, many 7427 implementors will limit their rendering options to the two MIDI 7428 Manufacturers Association renderers that may be specified in 7429 AudioSpecificConfig: General MIDI (GM, [MIDI]) and Downloadable Sounds 2 7430 (DLS 2, [DLS2]). 7432 To aid these implementors, we reproduce the AudioSpecificConfig bitfield 7433 formats for a GM renderer and a DLS 2 renderer below. We have checked 7434 these bitfields carefully and believe they are correct. However, we 7435 stress that the material below is informative, and that [MPEGAUDIO] and 7436 [MPEGSA] are the normative definitions for AudioSpecificConfig. 7438 As described in Section 6.2, a minimal mpeg4-generic session description 7439 encodes the AudioSpecificConfig binary bitfield as a hexadecimal string 7440 (whose format is defined in [RFC3640]) that is assigned to the "config" 7441 parameter. As described in Appendix C.6.3, a session description that 7442 uses the render parameter encodes the AudioSpecificConfig binary 7443 bitfield as a Base64-encoded string assigned to the "inline" parameter, 7444 or in the body of an HTTP URL assigned to the "url" parameter. 7446 Below, we show a simplified binary AudioSpecificConfig bitfield format, 7447 suitable for sending and receiving GM and DLS 2 data: 7449 0 1 2 3 7450 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 7451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7452 | AOTYPE |FREQIDX|CHANNEL|SACNK| FILE_BLK 1 (required) ... | 7453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7454 |1|SACNK| FILE_BLK 2 (optional) ... | 7455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7456 | ... |1|SACNK| FILE_BLK N (optional) ... | 7457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7458 |0|0| (first "0" bit terminates FILE_BLK list) 7459 +-+-+ 7461 Figure E.3 -- Simplified AudioSpecificConfig 7463 The 5-bit AOTYPE field specifies the Audio Object Type as an unsigned 7464 integer. The legal values for use with mpeg4-generic RTP MIDI streams 7465 are "15" (General MIDI), "14" (DLS 2), and "13" (Structured Audio). 7466 Thus, receivers that do not support all three mpeg4-generic renderers 7467 may parse the first 5 bits of an AudioSpecificConfig coded in a session 7468 description and reject sessions that specify unsupported renderers. 7470 The 4-bit FREQIDX field specifies the sampling rate of the renderer. We 7471 show the mapping of FREQIDX values to sampling rates in Figure E.4. 7472 Senders MUST specify a sampling frequency that matches the RTP clock 7473 rate, if possible; if not, senders MUST specify the escape value. 7474 Receivers MUST consult the RTP clock parameter for the true sampling 7475 rate if the escape value is specified. 7477 FREQIDX Sampling Frequency 7479 0x0 96000 7480 0x1 88200 7481 0x2 64000 7482 0x3 48000 7483 0x4 44100 7484 0x5 32000 7485 0x6 24000 7486 0x7 22050 7487 0x8 16000 7488 0x9 12000 7489 0xa 11025 7490 0xb 8000 7491 0xc reserved 7492 0xd reserved 7493 0xe reserved 7494 0xf escape value 7496 Figure E.4 -- FreqIdx encoding 7498 The 4-bit CHANNEL field specifies the number of audio channels for the 7499 renderer. The values 0x1 to 0x5 specify 1 to 5 audio channels; the 7500 value 0x6 specifies 5+1 surround sound, and the value 0x7 specifies 7+1 7501 surround sound. If the rtpmap line in the session description specifies 7502 one of these formats, CHANNEL MUST be set to the corresponding value. 7503 Otherwise, CHANNEL MUST be set to 0x0. 7505 The CHANNEL field is followed by a list of one or more binary file data 7506 blocks. The 3-bit SACNK field (the chunk_type field in class 7507 StructuredAudioSpecificConfig, defined in [MPEGSA]) specifies the type 7508 of each data block. 7510 For General MIDI, only Standard MIDI Files may appear in the list (SACNK 7511 field value 2). For DLS 2, only Standard MIDI Files and DLS 2 RIFF 7512 files (SACNK field value 4) may appear. For both of these file types, 7513 the FILE_BLK field has the format shown in Figure E.5: a 32-bit unsigned 7514 integer value (FILE_LEN) coding the number of bytes in the SMF or RIFF 7515 file, followed by FILE_LEN bytes coding the file data. 7517 0 1 2 3 7518 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 7519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7520 | FILE_LEN (32-bit, a byte count SMF file or RIFF file) | 7521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7522 | FILE_DATA (file contents, a list of FILE_LEN bytes) ... | 7523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7525 Figure E.5 -- The FILE_BLK field format 7527 Note that several files may follow the CHANNEL field. The "1" constant 7528 fields in Figure E.3 code the presence of another file; the "0" constant 7529 field codes the end of the list. The final "0" bit in Figure E.3 codes 7530 the absence of special coding tools (see [MPEGAUDIO] for details). 7531 Senders not using these tools MUST append this "0" bit; receivers that 7532 do not understand these coding tools MUST ignore all data following a 7533 "1" in this position. 7535 The StructuredAudioSpecificConfig bitfield structure requires the 7536 presence of one FILE_BLK. For mpeg4-generic RTP MIDI use of DLS 2, 7537 FILE_BLKs MUST code RIFF files or SMF files. For mpeg4-generic RTP MIDI 7538 use of General MIDI, FILE_BLKs MUST code SMF files. By default, this 7539 SMF will be ignored (Appendix C.6.4.1). In this default case, a GM 7540 StructuredAudioSpecificConfig bitfield SHOULD code a FILE_BLK whose 7541 FILE_LEN is 0, and whose FILE_DATA is empty. 7543 To complete this appendix, we derive the StructuredAudioSpecificConfig 7544 that we use in the General MIDI session examples in this memo. 7545 Referring to Figure E.3, we note that for GM, AOTYPE = 15. Our examples 7546 use a 44,100 Hz sample rate (FREQIDX = 4) and are in mono (CHANNEL = 1). 7547 For GM, a single SMF is encoded (SACNK = 2), using the SMF shown in 7548 Figure E.6 (a 26 byte file). 7550 -------------------------------------------- 7551 | MIDI File =
| 7552 -------------------------------------------- 7554
= 7555 4D 54 68 64 00 00 00 06 00 00 00 01 00 60 7557 = 7558 4D 54 72 6B 00 00 00 04 00 FF 2F 00 7560 Figure E.6 -- SMF file encoded in the example 7562 Placing these constants in binary format into the data structure shown 7563 in Figure E.3 yields the constant shown in Figure E.7. 7565 0 1 2 3 7566 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 7567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7568 |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| 7569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7570 |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| 7571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7572 |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| 7573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7574 |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| 7575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7576 |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| 7577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7578 |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| 7579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7580 |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| 7581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7582 |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| 7583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7584 |0|0| 7585 +-+-+ 7587 Figure E.7 -- AudioSpecificConfig used in GM examples 7589 Expressing this bitfield as an ASCII hexadecimal string yields: 7591 7A0A0000001A4D546864000000060000000100604D54726B0000000600FF2F000 7593 This string is assigned to the "config" parameter in the minimal 7594 mpeg4-generic General MIDI examples in this memo (such as the example in 7595 Section 6.2). Expressing this string in Base64 [RFC2045] yields: 7597 egoAAAAaTVRoZAAAAAYAAAABAGBNVHJrAAAABgD/LwAA 7599 This string is assigned to the "inline" parameter in the General MIDI 7600 example shown in Appendix C.6.5. 7602 References 7604 Normative References 7606 [MIDI] MIDI Manufacturers Association. "The Complete MIDI 1.0 7607 Detailed Specification", 1996. 7609 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 7610 Jacobson, "RTP: A Transport Protocol for Real-Time 7611 Applications", STD 64, RFC 3550, July 2003. 7613 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 7614 Video Conferences with Minimal Control", STD 65, RFC 7615 3551, July 2003. 7617 [RFC3640] van der Meer, J., Mackie, D., Swaminathan, V., Singer, 7618 D., and P. Gentric, "RTP Payload Format for Transport of 7619 MPEG-4 Elementary Streams", RFC 3640, November 2003. 7621 [MPEGSA] International Standards Organization. "ISO/IEC 14496 7622 MPEG-4", Part 3 (Audio), Subpart 5 (Structured Audio), 7623 2001. 7625 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 7626 Description Protocol", RFC 4566, July 2006. 7628 [MPEGAUDIO] International Standards Organization. "ISO 14496 MPEG- 7629 4", Part 3 (Audio), 2001. 7631 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 7632 Extensions (MIME) Part One: Format of Internet Message 7633 Bodies", RFC 2045, November 1996. 7635 [DLS2] MIDI Manufacturers Association. "The MIDI Downloadable 7636 Sounds Specification", v98.2, 1998. 7638 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 7639 Specifications: ABNF", RFC 5234, January 2008. 7641 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 7642 Requirement Levels", BCP 14, RFC 2119, March 1997. 7644 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 7645 Norrman, "The Secure Real-time Transport Protocol 7646 (SRTP)", RFC 3711, March 2004. 7648 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 7649 with Session Description Protocol (SDP)", RFC 3264, June 7650 2002. 7652 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 7653 Resource Identifier (URI): Generic Syntax", STD 66, RFC 7654 3986, January 2005. 7656 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 7657 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 7658 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 7660 [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session 7661 Description Protocol (SDP) Grouping Framework", 7662 RFC 5888, June 2010. 7664 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 7666 [RP015] MIDI Manufacturers Association. "Recommended Practice 7667 015 (RP-015): Response to Reset All Controllers", 11/98. 7669 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and 7670 Registration Procedures", BCP 13, RFC 4288, December 7671 2005. 7673 [RFC4855] Casner, S., "MIME Type Registration of RTP 7674 Payload Formats", RFC 4855, February 2007. 7676 Informative References 7678 [NMP] Lazzaro, J. and J. Wawrzynek. "A Case for Network 7679 Musical Performance", 11th International Workshop on 7680 Network and Operating Systems Support for Digital Audio 7681 and Video (NOSSDAV 2001) June 25-26, 2001, Port 7682 Jefferson, New York. 7684 [GRAME] Fober, D., Orlarey, Y. and S. Letz. "Real Time Musical 7685 Events Streaming over Internet", Proceedings of the 7686 International Conference on WEB Delivering of Music 2001, 7687 pages 147-154. 7689 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 7690 A., Peterson, J., Sparks, R., Handley, M., and E. 7691 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 7692 June 2002. 7694 [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time 7695 Streaming Protocol (RTSP)", RFC 2326, April 1998. 7697 [ALF] Clark, D. D. and D. L. Tennenhouse. "Architectural 7698 considerations for a new generation of protocols", 7699 SIGCOMM Symposium on Communications Architectures and 7700 Protocols , (Philadelphia, Pennsylvania), pp. 200--208, 7701 ACM, Sept. 1990. 7703 [RFC4695] Lazzaro, J. and J. Wawrzynek, "RTP Payload Format for 7704 MIDI", RFC 4695, November 2006. 7706 [RFC4696] Lazzaro, J. and J. Wawrzynek, "An Implementation Guide 7707 for RTP MIDI", RFC 4696, November 2006. 7709 [RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. 7710 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 7711 Functional Specification", RFC 2205, September 1997. 7713 [RFC4571] Lazzaro, J. "Framing Real-time Transport Protocol (RTP) 7714 and RTP Control Protocol (RTCP) Packets over Connection- 7715 Oriented Transport", RFC 4571, July 2006. 7717 [SPMIDI] MIDI Manufacturers Association. "Scalable Polyphony 7718 MIDI, Specification and Device Profiles", Document 7719 Version 1.0a, 2002. 7721 [LCP] Apple Computer. "Logic 7 Dedicated Control Surface 7722 Support", Appendix B. Product manual available from 7723 www.apple.com. 7725 Authors' Addresses 7727 John Lazzaro (corresponding author) 7728 UC Berkeley 7729 CS Division 7730 315 Soda Hall 7731 Berkeley CA 94720-1776 7732 EMail: lazzaro@cs.berkeley.edu 7734 John Wawrzynek 7735 UC Berkeley 7736 CS Division 7737 631 Soda Hall 7738 Berkeley CA 94720-1776 7739 EMail: johnw@cs.berkeley.edu 7741 Full Copyright Statement 7743 Copyright (c) 2011 IETF Trust and the persons identified as the 7744 document authors. All rights reserved. 7746 This document is subject to BCP 78 and the IETF Trust's Legal Provisions 7747 Relating to IETF Documents (http://trustee.ietf.org/license-info) 7748 in effect on the date of publication of this document. Please 7749 review these documents carefully, as they describe your rights and 7750 restrictions with respect to this document. Code Components 7751 extracted from this document must include Simplified BSD License 7752 text as described in Section 4.e of the Trust Legal Provisions and 7753 are provided without warranty as described in the Simplified BSD 7754 License. 7756 Copyright (c) 2011 IETF Trust and the persons identified as the 7757 document authors. All rights reserved. 7759 Acknowledgement 7761 Funding for the RFC Editor function is currently provided by the 7762 Internet Society.