idnits 2.17.1 draft-ietf-avt-rtp-midi-format-15.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 7567. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 7539. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 7546. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 7552. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. == There are 7 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'RFC3550' on line 7646 looks like a reference -- Missing reference section? 'SDP' on line 7630 looks like a reference -- Missing reference section? 'RFC3261' on line 7481 looks like a reference -- Missing reference section? 'RFC2326' on line 7485 looks like a reference -- Missing reference section? 'RFC3264' on line 7444 looks like a reference -- Missing reference section? 'RFC3551' on line 7412 looks like a reference -- Missing reference section? 'MIDI' on line 7405 looks like a reference -- Missing reference section? 'NMP' on line 7472 looks like a reference -- Missing reference section? 'MPEGSA' on line 7419 looks like a reference -- Missing reference section? 'RFC2205' on line 7496 looks like a reference -- Missing reference section? 'GUIDE' on line 7493 looks like a reference -- Missing reference section? 'GRAME' on line 7477 looks like a reference -- Missing reference section? 'RFC3640' on line 7415 looks like a reference -- Missing reference section? 'RFC2119' on line 7437 looks like a reference -- Missing reference section? 'ALF' on line 7488 looks like a reference -- Missing reference section? 'CONTRANS' on line 7502 looks like a reference -- Missing reference section? 'DLS2' on line 7431 looks like a reference -- Missing reference section? 'MPEGAUDIO' on line 7425 looks like a reference -- Missing reference section? 'RP015' on line 7461 looks like a reference -- Missing reference section? 'LCP' on line 7511 looks like a reference -- Missing reference section? 'RFC2234' on line 7434 looks like a reference -- Missing reference section? 'RFC3388' on line 7457 looks like a reference -- Missing reference section? 'RFC2045' on line 7428 looks like a reference -- Missing reference section? 'MTYPE' on line 7464 looks like a reference -- Missing reference section? 'RFC2616' on line 7453 looks like a reference -- Missing reference section? 'RFC2818' on line 7506 looks like a reference -- Missing reference section? 'RFC2048' on line 7499 looks like a reference -- Missing reference section? 'SPMIDI' on line 7508 looks like a reference -- Missing reference section? 'RFC2396' on line 7447 looks like a reference -- Missing reference section? 'RFC2732' on line 7450 looks like a reference -- Missing reference section? 'RFC3711' on line 7440 looks like a reference -- Missing reference section? 'RFC3555' on line 7467 looks like a reference -- Missing reference section? '1' on line 7583 looks like a reference -- Missing reference section? '2' on line 7588 looks like a reference -- Missing reference section? '3' on line 7593 looks like a reference -- Missing reference section? '4' on line 7614 looks like a reference -- Missing reference section? '5' on line 7621 looks like a reference -- Missing reference section? '6' on line 7625 looks like a reference -- Missing reference section? '7' on line 7635 looks like a reference Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 47 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT J. Lazzaro 3 January 23, 2006 J. Wawrzynek 4 Expires: July 23, 2006 UC Berkeley 6 RTP Payload Format for MIDI 8 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware have 14 been or will be disclosed, and any of which he or she becomes aware 15 will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that other 19 groups may also distribute working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on July 23, 2006. 34 Abstract 36 This memo describes an RTP payload format for the MIDI command 37 language. The format encodes all commands that may legally appear 38 on a MIDI 1.0 DIN cable. The format is suitable for interactive 39 applications (such as network musical performance) and 40 content-delivery applications (such as file streaming). The format 41 may be used over unicast and multicast UDP as well as TCP, and 42 defines tools for graceful recovery from packet loss. Stream 43 behavior, including the MIDI rendering method, may be customized 44 during session setup. The format also serves as a mode for the 45 mpeg4-generic format, to support the MPEG 4 Audio Object Types for 46 General MIDI, Downloadable Sounds Level 2, and Structured Audio. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 5 51 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 6 52 1.2 Bitfield Conventions . . . . . . . . . . . . . . . . . . . 6 53 2. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . . . 7 54 2.1 RTP Header . . . . . . . . . . . . . . . . . . . . . . . . 7 55 2.2 MIDI Payload . . . . . . . . . . . . . . . . . . . . . . . 12 56 3. MIDI Command Section . . . . . . . . . . . . . . . . . . . . . . 14 57 3.1 Timestamps . . . . . . . . . . . . . . . . . . . . . . . . 15 58 3.2 Command Coding . . . . . . . . . . . . . . . . . . . . . . 17 59 4. The Recovery Journal System . . . . . . . . . . . . . . . . . . . 24 60 5. Recovery Journal Format . . . . . . . . . . . . . . . . . . . . . 26 61 6. Session Description Protocol . . . . . . . . . . . . . . . . . . 30 62 6.1 Session Descriptions for Native Streams . . . . . . . . . . 31 63 6.2 Session Descriptions for mpeg4-generic Streams . . . . . . 33 64 6.3 Parameters . . . . . . . . . . . . . . . . . . . . . . . . 35 65 7. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . . . 37 66 8. Congestion Control . . . . . . . . . . . . . . . . . . . . . . . 38 67 A. The Recovery Journal Channel Chapters . . . . . . . . . . . . . . 39 68 A.1 Recovery Journal Definitions . . . . . . . . . . . . . . . 39 69 A.2 Chapter P: MIDI Program Change . . . . . . . . . . . . . . 44 70 A.3 Chapter C: MIDI Control Change . . . . . . . . . . . . . . 45 71 A.3.1 Log Inclusion Rules . . . . . . . . . . . . . . . . 45 72 A.3.2 Controller Log Format . . . . . . . . . . . . . . . 47 73 A.3.3 Log List Coding Rules . . . . . . . . . . . . . . . 49 74 A.3.4 The Parameter System . . . . . . . . . . . . . . . . 52 75 A.4 Chapter M: MIDI Parameter System . . . . . . . . . . . . . 54 76 A.4.1 Log Inclusion Rules . . . . . . . . . . . . . . . . 55 77 A.4.2 Log Coding Rules . . . . . . . . . . . . . . . . . . 57 78 A.4.2.1 The Value Tool . . . . . . . . . . . . . . . 58 79 A.4.2.2 The Count Tool . . . . . . . . . . . . . . . 62 81 A.5 Chapter W: MIDI Pitch Wheel . . . . . . . . . . . . . . . . 63 82 A.6 Chapter N: MIDI NoteOff and NoteOn . . . . . . . . . . . . 64 83 A.6.1 Header Structure . . . . . . . . . . . . . . . . . . 65 84 A.6.2 Note Structures . . . . . . . . . . . . . . . . . . 66 85 A.7 Chapter E: MIDI Note Command Extras . . . . . . . . . . . . 68 86 A.7.1 Note Log Format . . . . . . . . . . . . . . . . . . 69 87 A.7.2 Log Inclusion Rules . . . . . . . . . . . . . . . . 69 88 A.8 Chapter T: MIDI Channel Aftertouch . . . . . . . . . . . . 70 89 A.9 Chapter A: MIDI Poly Aftertouch . . . . . . . . . . . . . . 71 90 B. The Recovery Journal System Chapters . . . . . . . . . . . . . . 73 91 B.1 System Chapter D: Simple System Commands . . . . . . . . . 73 92 B.1.1 Undefined System Commands . . . . . . . . . . . 74 93 B.2 System Chapter V: Active Sense Command . . . . . . . . . . 77 94 B.3 System Chapter Q: Sequencer State Commands . . . . . . . . 78 95 B.3.1 Non-compliant Sequencers . . . . . . . . . . . 80 96 B.4 System Chapter F: MIDI Time Code . . . . . . . . . . . . . 81 97 B.4.1 Partial Frames . . . . . . . . . . . . . . . . . . 83 98 B.5 System Chapter X: System Exclusive . . . . . . . . . . . . 85 99 B.5.1 Chapter Format . . . . . . . . . . . . . . . . 85 100 B.5.2 Log Inclusion Semantics . . . . . . . . . . . . 88 101 B.5.3 TCOUNT and COUNT fields . . . . . . . . . . . . 90 102 C. Session Configuration Tools . . . . . . . . . . . . . . . . . . . 92 103 C.1 Stream Subsetting . . . . . . . . . . . . . . . . . . . . . 93 104 C.2 The Journalling System . . . . . . . . . . . . . . . . . . 97 105 C.2.1 The j_sec Parameter . . . . . . . . . . . . . . . . 98 106 C.2.2 The j_update Parameter . . . . . . . . . . . . . . . 99 107 C.2.2.1 The anchor Sending Policy . . . . . . . . . . 100 108 C.2.2.2 The closed-loop Sending Policy . . . . . . . 100 109 C.2.2.3 The open-loop Sending Policy . . . . . . . . 104 110 C.2.3 Chapter Inclusion Parameters . . . . . . . . . . . . 106 111 C.3 Timestamp Semantics . . . . . . . . . . . . . . . . . . . . 111 112 C.3.1 The comex Algorithm . . . . . . . . . . . . . . . . 111 113 C.3.2 The async Algorithm . . . . . . . . . . . . . . . . 112 114 C.3.3 The buffer Algorithm . . . . . . . . . . . . . . . . 113 115 C.4 Packet Timing Tools . . . . . . . . . . . . . . . . . . . . 115 116 C.4.1 Packet Duration Tools . . . . . . . . . . . . . . . 115 117 C.4.2 The guardtime Parameter . . . . . . . . . . . . . . 116 118 C.5 Stream Description . . . . . . . . . . . . . . . . . . . . 118 119 C.6 MIDI Rendering . . . . . . . . . . . . . . . . . . . . . . 124 120 C.6.1 The multimode Parameter . . . . . . . . . . . . . . 125 121 C.6.2 Renderer Specification . . . . . . . . . . . . . . . 125 122 C.6.3 Renderer Initialization . . . . . . . . . . . . . . 128 123 C.6.4 MIDI Channel Mapping . . . . . . . . . . . . . . . . 129 124 C.6.4.1 smf_info . . . . . . . . . . . . . . . . . . 130 125 C.6.4.2 smf_inline, smf_url, smf_cid . . . . . . . . 132 126 C.6.4.3 chanmask . . . . . . . . . . . . . . . . . . 133 127 C.6.5 The audio/asc Media Type . . . . . . . . . . . . . . 134 128 C.7 Interoperability . . . . . . . . . . . . . . . . . . . . . 136 129 C.7.1 Content streaming . . . . . . . . . . . . . . . . . 136 130 C.7.2 Network musical performance . . . . . . . . . . . . 139 131 D. Parameter Syntax Definitions . . . . . . . . . . . . . . . . . . 148 132 E. A MIDI Overview for Networking Specialists . . . . . . . . . . . 154 133 E.1 Commands Types . . . . . . . . . . . . . . . . . . . . . . 156 134 E.2 Running Status . . . . . . . . . . . . . . . . . . . . . . 156 135 E.3 Command Timing . . . . . . . . . . . . . . . . . . . . . . 157 136 E.4 AudioSpecificConfig templates for MMA renderers . . . . . . 157 137 F. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 162 138 G. Security Considerations . . . . . . . . . . . . . . . . . . . . . 163 139 H. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . . 164 140 H.1 rtp-midi Media Type Registration . . . . . . . . . . . . . 164 141 H.1.1 Repository request . . . . . . . . . . . . . . . . . 167 142 H.2 mpeg4-generic Media Type Registration . . . . . . . . . . . 168 143 H.2.1 Repository request . . . . . . . . . . . . . . . . . 171 144 H.3 asc Media Type Registration . . . . . . . . . . . . . . . . 173 145 I. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 175 146 I.1 Normative References . . . . . . . . . . . . . . . . . . . 175 147 I.2 Informative References . . . . . . . . . . . . . . . . . . 176 148 J. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 178 149 K. Intellectual Property Rights Statement . . . . . . . . . . . . . 178 150 L. Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 178 151 N. Change Log for . . . . . 180 152 1. Introduction 154 The Internet Engineering Task Force (IETF) has developed a set of 155 focused tools for multimedia networking ([RFC3550] [SDP] [RFC3261] 156 [RFC2326]). These tools can be combined in different ways to support a 157 variety of real-time applications over Internet Protocol (IP) networks. 159 For example, a telephony application might use the Session Initiation 160 Protocol (SIP, [RFC3261]) to set up a phone call. Call setup would 161 include negotiations to agree on a common audio codec [RFC3264]. 162 Negotiations would use the Session Description Protocol (SDP, [SDP]) to 163 describe candidate codecs. 165 After a call is set up, audio data would flow between the parties using 166 the Real Time Protocol (RTP, [RFC3550]) under any applicable profile 167 (for example, the Audio/Visual Profile (AVP, [RFC3551])). The tools 168 used in this telephony example (SIP, SDP, RTP) might be combined in a 169 different way to support a content streaming application, perhaps in 170 conjunction with other tools (such as the Real Time Streaming Protocol 171 (RTSP, [RFC2326])). 173 The MIDI command language [MIDI] is widely used in musical applications 174 that are analogous to the examples described above. On stage and in the 175 recording studio, MIDI is used for the interactive remote control of 176 musical instruments, an application similar in spirit to telephony. On 177 web pages, Standard MIDI Files (SMFs, [MIDI]) rendered using the General 178 MIDI standard [MIDI] provide a low-bandwidth substitute for audio 179 streaming. 181 This memo is motivated by a simple premise: if MIDI performances could 182 be sent as RTP streams that are managed by IETF session tools, a 183 hybridization of the MIDI and IETF application domains may occur. 185 For example, interoperable MIDI networking may foster network music 186 performance applications, in which a group of musicians, located at 187 different physical locations, interact over a network to perform as they 188 would if located in the same room [NMP]. As a second example, the 189 streaming community may begin to use MIDI for low-bitrate audio coding, 190 perhaps in conjunction with normative sound synthesis methods [MPEGSA]. 192 To enable MIDI applications using RTP, this memo defines an RTP payload 193 format and its media type. Sections 2-5 and Appendices A-B define the 194 RTP payload format. Section 6 and Appendices C-D define the media types 195 identifying the payload format, the parameters needed for configuration, 196 and how the parameters are utilized in SDP. 198 Appendix C also includes interoperability guidelines for the example 199 applications described above: network musical performance using SIP 200 (Appendix C.7.2) and content-streaming using RTSP (Appendix C.7.1). 202 Another potential application area for RTP MIDI is MIDI networking for 203 professional audio equipment and electronic musical instruments. We do 204 not offer interoperability guidelines for this application in this memo. 205 However, RTP MIDI has been designed with stage and studio applications 206 in mind, and we expect that efforts to define a stage and studio 207 framework will rely on RTP MIDI for MIDI transport services. 209 Some applications may require MIDI media delivery at a certain service 210 quality level (latency, jitter, packet loss, etc). RTP itself does not 211 provide service guarantees. However, applications may use lower-layer 212 network protocols to configure the quality of the transport services 213 that RTP uses. These protocols may act to reserve network resources for 214 RTP flows [RFC2205], or may simply direct RTP traffic onto a dedicated 215 "media network" in a local installation. Note that RTP and the MIDI 216 payload format do provide tools that applications may use to achieve the 217 best possible real-time performance at a given service level. 219 This memo normatively defines the syntax and semantics of the MIDI 220 payload format. However, this memo does not define algorithms for 221 sending and receiving packets. An ancillary document [GUIDE] provides 222 informative guidance on algorithms. Supplemental information may be 223 found in related conference publications [NMP] [GRAME]. 225 Throughout this memo, the phrase "native stream" refers to a stream that 226 uses the rtp-midi media type. The phrase "mpeg4-generic stream" refers 227 to a stream that uses the mpeg4-generic media type (in mode rtp-midi) to 228 operate in an MPEG 4 environment [RFC3640]. Section 6 describes this 229 distinction in detail. 231 1.1 Terminology 233 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 234 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 235 document are to be interpreted as described in BCP 14, RFC 2119 236 [RFC2119]. 238 1.2 Bitfield Conventions 240 The packet bitfields in this document that share a common name often 241 have identical semantics. As most of these bitfields appear in 242 Appendices A-B, we define the common bitfield names in Appendix A.1. 244 However, a few of these common names also appear in the main text of 245 this document. For convenience, we list these definitions below: 247 o R flag bit. R flag bits are reserved for future use. Senders 248 MUST set R bits to 0. Receivers MUST ignore R bit values. 250 o LENGTH field. All fields named LENGTH (as distinct from LEN) 251 code the number of octets in the structure that contains it, 252 including the header it resides in and all hierarchical levels 253 below it. If a structure contains a LENGTH field, a receiver 254 MUST use the LENGTH field value to advance past the structure 255 during parsing, rather than use knowledge about the internal 256 format of the structure. 258 2. Packet Format 260 In this section, we introduce the format of RTP MIDI packets. The 261 description includes some background information on RTP, for the benefit 262 of MIDI implementors new to IETF tools. Implementors should consult 263 [RFC3550] for an authoritative description of RTP. 265 This memo assumes the reader is familiar with MIDI syntax and semantics. 266 Appendix E provides a MIDI overview, at a level of detail sufficient to 267 understand most of this memo. Implementors should consult [MIDI] for an 268 authoritative description of MIDI. 270 The MIDI payload format maps a MIDI command stream (16 voice channels + 271 systems) onto an RTP stream. An RTP media stream is a sequence of 272 logical packets that share a common format. Each packet consists of two 273 parts: the RTP header and the MIDI payload. Figure 1 shows this format 274 (vertical space delineates the header and payload). 276 We describe RTP packets as "logical" packets to highlight the fact that 277 RTP itself is not a network-layer protocol. Instead, RTP packets are 278 mapped onto network protocols (such as unicast UDP, multicast UDP, or 279 TCP) by an application [ALF]. The interleaved mode of the Real Time 280 Streaming Protocol (RTSP, [RFC2326]) is an example of an RTP mapping to 281 TCP transport, as is [CONTRANS]. 283 2.1 RTP Header 285 [RFC3550] provides a complete description of the RTP header fields. In 286 this section, we clarify the role of a few RTP header fields for MIDI 287 applications. All fields are coded in network byte order (big-endian). 289 0 1 2 3 290 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 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 | V |P|X| CC |M| PT | Sequence number | 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 | Timestamp | 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 | SSRC | 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | MIDI command section ... | 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 | Journal section ... | 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 Figure 1 -- Packet format 307 The behavior of the 1-bit M field depends on the media type of the 308 stream. For native streams, the M bit MUST be set to 1 if the MIDI 309 command section has a non-zero LEN field, and MUST be set to 0 310 otherwise. For mpeg4-generic streams, the M bit MUST be set to 1 for 311 all packets (to conform to [RFC3640]). 313 In an RTP MIDI stream, the 16-bit sequence number field is initialized 314 to a randomly chosen value, and is incremented by one (modulo 2^16) for 315 each packet sent in the stream. A related quantity, the 32-bit extended 316 packet sequence number, may be computed by tracking rollovers of the 317 16-bit sequence number. Note that different receivers of the same 318 stream may compute different extended packet sequence numbers, depending 319 on when the receiver joined the session. 321 The 32-bit timestamp field sets the base timestamp value for the packet. 322 The payload codes MIDI command timing relative to this value. The 323 timestamp units are set by the clock rate parameter. For example, if 324 the clock rate has a value of 44100 Hz, two packets whose base timestamp 325 values differ by 2 seconds have RTP timestamp fields that differ by 326 88200. 328 Note that the clock rate parameter is not encoded within each RTP MIDI 329 packet. A receiver of an RTP MIDI stream becomes aware of the clock 330 rate as part of the session setup process. For example, if a session 331 management tool uses the Session Description Protocol (SDP, [SDP]) to 332 describe a media session, the clock rate parameter is set using the 333 rtpmap attribute. We show examples of session setup in Section 6. 335 For RTP MIDI stream destined to be rendered into audio, the clock rate 336 SHOULD be an audio sample rate of 32 KHz or higher. This recommendation 337 is due to the sensitivity of human musical perception to small timing 338 errors in musical note sequences, and due to the timbral changes that 339 occur when two near-simultaneous MIDI NoteOns are rendered with a 340 different timing than desired by the content author due to clock rate 341 quantization. RTP MIDI streams that are not destined for audio 342 rendering (such as MIDI streams that control stage lighting) MAY use a 343 lower clock rate, but SHOULD use a clock rate high enough to avoid 344 timing artifacts in the application. 346 For RTP MIDI streams destined to be rendered into audio, the clock rate 347 SHOULD be chosen from rates in common use in professional audio 348 applications or in consumer audio distribution. At the time of this 349 writing, these rates include 32 KHz, 44.1 KHz, 48 KHz, 64 KHz, 88.2 KHz, 350 96 KHz, 176.4 KHz, and 192 KHz. If the RTP MIDI session is a part of a 351 synchronized media session that includes another (non-MIDI) RTP audio 352 stream with a clock rates of 32 KHz or higher, the RTP MIDI stream 353 SHOULD use a clock rate that matches the clock rate of the other audio 354 stream. However, if the RTP MIDI stream is destined to be rendered into 355 audio, the RTP MIDI stream SHOULD NOT use a clock rate lower than 32 356 KHz, even if this second stream has a clock rate less than 32 KHz. 358 Timestamps of consecutive packets do not necessarily increment at a 359 fixed rate, because RTP MIDI packets are not necessarily sent at a fixed 360 rate. The degree of packet transmission regularity reflects the 361 underlying application dynamics. Interactive applications may vary the 362 packet sending rate to track the gestural rate of a human performer, 363 whereas content-streaming applications may send packets at a fixed rate. 365 Therefore, the timestamps for two sequential RTP packets may be 366 identical, or the second packet may have a timestamp arbitrarily larger 367 than the first packet (modulo 2^32). Section 3 places additional 368 restrictions on the RTP timestamps for two sequential RTP packets, as 369 does the guardtime parameter (Appendix C.4.2). 371 We use the term "media time" to denote the temporal duration of the 372 media coded by an RTP packet. The media time coded by a packet is 373 computed by subtracting the last command timestamp in the MIDI command 374 section from the RTP timestamp (modulo 2^32). If the MIDI list of the 375 MIDI command section of a packet is empty, the media time coded by the 376 packet is 0 ms. Appendix C.4.1 discusses media time issues in detail. 378 We now define RTP session semantics, in the context of sessions 379 specified using the session description protocol [SDP]. A session 380 description media line ("m=") specifies an RTP session. An RTP session 381 has an independent space of 2^32 synchronization sources. 382 Synchronization source identifiers are coded in the SSRC header field of 383 RTP session packets. The payload types that may appear in the PT header 384 field of RTP session packets are listed at the end of the media line. 386 Several RTP MIDI streams may appear in an RTP session. Each stream is 387 distinguished by a unique SSRC value, and has a unique sequence number 388 and RTP timestamp space. Multiple streams in the RTP session may be 389 sent by a single party. Multiple parties may send streams in the RTP 390 session. An RTP MIDI stream encodes data for a single MIDI command name 391 space (16 voice channels + Systems). 393 Streams in an RTP session may use different payload types, or may use 394 the same payload type. However, each party may send, at most, one RTP 395 MIDI stream for each payload type mapped to an RTP MIDI payload format 396 in an RTP session. Recall that dynamic binding of payload type numbers 397 in [SDP] lets a party map many payload type numbers to the RTP MIDI 398 payload format, and thus a party may send many RTP MIDI streams in a 399 single RTP session. Pairs of streams (unicast or multicast) that 400 communicate between two parties in an RTP session and that share a 401 payload type have the same association as a MIDI cable pair that cross- 402 connects two devices in a MIDI 1.0 DIN network. 404 The RTP session architecture described above is efficient in its use of 405 network ports, as one RTP session (using a port pair per party) supports 406 the transport of many MIDI name spaces (16 MIDI channels + systems). We 407 define tools for grouping and labelling MIDI name spaces across streams 408 and sessions in Appendix C.5 of this memo. 410 The RTP header timestamps for each stream in an RTP session have 411 separately and randomly chosen initialization values. Receivers use the 412 timing fields encoded in the RTP control protocol (RTCP, [RFC3550]) 413 sender reports to synchronize the streams sent by a party. The SSRC 414 values for each stream in an RTP session are also separately and 415 randomly chosen, as described in [RFC3550]. Receivers use the CNAME 416 field encoded in RTCP sender reports to verify that streams were sent by 417 the same party, and to detect SSRC collisions, as described in 418 [RFC3550]. 420 In some applications, a receiver renders MIDI commands into audio (or 421 into control actions, such as the rewind of a tape deck or the dimming 422 of stage lights). In other applications, a receiver presents a MIDI 423 stream to software programs via an Application Programmer Interface 424 (API). Appendix C.6 defines session configuration tools to specify what 425 receivers should do with a MIDI command stream. 427 If a multimedia session uses different RTP MIDI streams to send 428 different classes of media, the streams MUST be sent over different RTP 429 sessions. For example, if a multimedia session uses one MIDI stream for 430 audio and a second MIDI stream to control a lighting system, the audio 431 and lighting streams MUST be sent over different RTP sessions, each with 432 its own media line. 434 Session description tools defined in Appendix C.5 let a sending party 435 split a single MIDI name space (16 voice channels + systems) over 436 several RTP MIDI streams. Split transport of a MIDI command stream is a 437 delicate task, because correct command stream reconstruction by a 438 receiver depends on exact timing synchronization across the streams. 440 To support split name spaces, we define the following requirements: 442 o A party MUST NOT send several RTP MIDI streams that share a MIDI 443 name space in the same RTP session. Instead, each stream MUST 444 be sent from a different RTP session. 446 o If several RTP MIDI streams sent by a party share a MIDI name 447 space, all streams MUST use the same SSRC value, and MUST use 448 the same randomly chosen RTP timestamp initialization value. 450 These rules let a receiver identify streams that share a MIDI name space 451 (by matching SSRC values), and also lets a receiver accurately 452 reconstruct the source MIDI command stream (by using RTP timestamps to 453 interleave commands from the two streams). Care MUST be taken by 454 senders to ensure that SSRC changes due to collisions are reflected in 455 both streams. Receivers MUST regularly examine the RTCP CNAME fields 456 associated with the linked streams, to ensure that the assumed link is 457 legitimate, and not the result of a SSRC collision by another sender. 459 Except for the special cases described above, a party may send many RTP 460 MIDI streams in the same session. However, it is sometimes advantageous 461 for two RTP MIDI streams to be sent over different RTP sessions. For 462 example, two streams may need different values for RTP session-level 463 attributes (such as the sendonly and recvonly attributes). As a second 464 example, two RTP sessions may be needed to send two unicast streams in a 465 multimedia session that originate on different computers (with different 466 IP numbers). Two RTP sessions are needed in this case because transport 467 addresses are specified on the RTP-session or multimedia-session level, 468 not on a payload type level. 470 On a final note, in some uses of MIDI, parties send bidirectional 471 traffic to conduct transactions (such as file exchange). These commands 472 were designed to work over MIDI 1.0 DIN cable networks may be configured 473 in a multicast topology, which use pure pure "party-line" signalling. 474 Thus, if a multimedia session ensures a multicast connection between all 475 parties, bidirectional MIDI commands will work without additional 476 support from the RTP MIDI payload format. 478 2.2 MIDI Payload 480 The payload (Figure 1) MUST begin with the MIDI command section. The 481 MIDI command section codes a (possibly empty) list of timestamped MIDI 482 commands, and provides the essential service of the payload format. 484 The payload MAY also contain a journal section. The journal section 485 provides resiliency by coding the recent history of the stream. A flag 486 in the MIDI command section codes the presence of a journal section in 487 the payload. 489 Section 3 defines the MIDI command section. Sections 4-5 and Appendices 490 A-B define the recovery journal, the default format for the journal 491 section. Here, we describe how these payload sections operate in a 492 stream in an RTP session. 494 The journalling method for a stream is set at the start of a session and 495 MUST NOT be changed thereafter. A stream may be set to use the recovery 496 journal, to use an alternative journal format (none are defined in this 497 memo), or to not use a journal. 499 The default journalling method of a stream is inferred from its 500 transport type. Streams that use unreliable transport (such as UDP) 501 default to using the recovery journal. Streams that use reliable 502 transport (such as TCP) default to not using a journal. Appendix C.2.1 503 defines session configuration tools for overriding these defaults. For 504 all types of transport, a sender MUST transmit an RTP packet stream with 505 consecutive sequence numbers (modulo 2^16). 507 If a stream uses the recovery journal, every payload in the stream MUST 508 include a journal section. If a stream does not use journalling, a 509 journal section MUST NOT appear in a stream payload. If a stream uses 510 an alternative journal format, the specification for the journal format 511 defines an inclusion policy. 513 If a stream is sent over UDP transport, the Maximum Transmission Unit 514 (MTU) of the underlying network limits the practical size of the payload 515 section (for example, an Ethernet MTU is 1500 octets), for applications 516 where predictable and minimal packet transmission latency is critical. 517 A sender SHOULD NOT create RTP MIDI UDP packets whose size exceeds the 518 MTU of the underlying network. Instead, the sender SHOULD take steps to 519 keep the maximum packet size under the MTU limit. 521 These steps may take many forms. The default closed-loop recovery 522 journal sending policy (defined in Appendix C.2.2.2) uses RTP control 523 protocol (RTCP, [RFC3550]) feedback to manage the RTP MIDI packet size. 524 In addition, Section 3.2 and Appendix B.5.2 provide specific tools for 525 managing the size of packets that code MIDI System Exclusive (0xF0) 526 commands. Appendix C.5 defines session configuration tools that may be 527 used to split a dense MIDI name space into several UDP streams (each 528 sent in a different RTP session, per Section 2.1) so that the payload 529 fits comfortably into an MTU. Another option is to use TCP. Section 530 4.3 of [GUIDE] provides non-normative advice for packet size management. 532 3. MIDI Command Section 534 Figure 2 shows the format of the MIDI command section. 536 0 1 2 3 537 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 538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 539 |B|J|Z|P|LEN... | MIDI list ... | 540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 542 Figure 2 -- MIDI command section 544 The MIDI command section begins with a variable-length header. 546 The header field LEN codes the number of octets in the MIDI list that 547 follows the header. If the header flag B is 0, the header is one octet 548 long, and LEN is a 4-bit field, supporting a maximum MIDI list length of 549 15 octets. 551 If B is 1, the header is two octets long, and LEN is a 12-bit field, 552 supporting a maximum MIDI list length of 4095 octets. LEN is coded in 553 network byte order (big-endian): the 4 bits of LEN that appear in the 554 first header octet code the most significant 4 bits of the 12-bit LEN 555 value. 557 A LEN value of 0 is legal, and codes an empty MIDI list 559 If the J header bit is set to 1, a journal section MUST appear after 560 MIDI command section in the payload. If the J header bit is set to 0, 561 the payload MUST NOT contain a journal section. 563 We define the semantics of the P header bit in Section 3.2. 565 If the LEN header field is nonzero, the MIDI list has the structure 566 shown in Figure 3. 568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 569 | Delta Time 0 (1-4 octets long, or 0 octets if Z = 1) | 570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 | MIDI Command 0 (1 or more octets long) | 572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 573 | Delta Time 1 (1-4 octets long) | 574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 575 | MIDI Command 1 (1 or more octets long) | 576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 577 | ... | 578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 579 | Delta Time N (1-4 octets long) | 580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 581 | MIDI Command N (0 or more octets long) | 582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 584 Figure 3 -- MIDI list structure. 586 If the header flag Z is 1, the MIDI list begins with a complete MIDI 587 command (coded in the MIDI Command 0 field in Figure 3) preceded by a 588 delta time (coded in the Delta Time 0 field). If Z is 0, the Delta Time 589 0 field is not present in the MIDI list, and the command coded in the 590 MIDI Command 0 field has an implicit delta time of 0. 592 The MIDI list structure may also optionally encode a list of N 593 additional complete MIDI commands, each coded in a MIDI Command K field. 594 Each additional command MUST be preceded by a Delta Time K field, which 595 codes the command's delta time. We discuss exceptions to the "command 596 fields code complete MIDI commands" rule in Section 3.2. 598 The final MIDI command field (i.e. the MIDI Command N field shown in 599 Figure 3) in the MIDI list MAY be empty. Moreover, a MIDI list MAY 600 consist a single delta time (encoded in the Delta Time 0 field) without 601 an associated command (which would have been encoded in the MIDI Command 602 0 field). These rules enable MIDI coding features that are explained in 603 Section 3.1. We delay the explanations because an understanding of RTP 604 MIDI timestamps is necessary to describe the features. 606 3.1 Timestamps 608 In this section, we describe how RTP MIDI encodes a timestamp for each 609 MIDI list command. Command timestamps have the same units as RTP packet 610 header timestamps (described in Section 2.1 and [RFC3550]). Recall that 611 RTP timestamps have units of seconds, whose scaling is set during 612 session configuration (see Section 6.1 and [SDP]). 614 As shown in Figure 3, the MIDI list encodes time using a compact delta- 615 time format. The RTP MIDI delta time syntax is a modified form of the 616 MIDI File delta time syntax [MIDI]. RTP MIDI delta times use 1-4 octet 617 fields to encode 32-bit unsigned integers. Figure 4 shows the encoded 618 and decoded forms of delta times. Note that delta time values may be 619 legally encoded in multiple formats; for example, there are four legal 620 ways to encode the zero delta time (0x00, 0x8000, 0x808000, 0x80808000). 622 RTP MIDI uses delta times to encode a timestamp for each MIDI command. 623 The timestamp for MIDI Command K is the summation (modulo 2^32) of the 624 RTP timestamp and decoded delta times 0 through K. This cumulative 625 coding technique, borrowed from MIDI File delta time coding, is 626 efficient because it reduces the number of multi-octet delta times. 628 All command timestamps in a packet MUST be less than or equal to the RTP 629 timestamp of the next packet in the stream (modulo 2^32). 631 This restriction ensures that a particular RTP MIDI packet in a stream 632 is uniquely responsible for encoding time starting at the moment after 633 the RTP timestamp encoded in the RTP packet header, and ending at the 634 moment before the final command timestamp encoded in the MIDI list. The 635 "moment before" and "moment after" qualifiers acknowledge the "less than 636 or equal" semantics (as opposed to "strictly less than") in the sentence 637 above this paragraph. 639 Note that it is possible to "pad" the end of an RTP MIDI packet with 640 time that is guaranteed to be void of MIDI commands, by setting the 641 "Delta Time N" field of the MIDI list to the end of the void time, and 642 by omitting its corresponding "MIDI Command N" field (a syntactic 643 construction the preamble of Section 3 expressly made legal). 645 In addition, it is possible to code an RTP MIDI packet to express that a 646 period of time in the stream is void of MIDI commands. The RTP 647 timestamp in the header would code the start of the void time. The MIDI 648 list of this packet would consist of a "Delta Time 0" field that coded 649 the end of the void time. No other fields would be present in the MIDI 650 list (a syntactic construction the preamble of Section 3 also expressly 651 made legal). 653 By default, a command timestamp indicates the execution time for the 654 command. The difference between two timestamps indicates the time delay 655 between the execution of the commands. This difference may be zero, 656 coding simultaneous execution. In this memo, we refer to this 657 interpretation of timestamps as "comex" (COMmand EXecution) semantics. 658 We formally define comex semantics in Appendix C.3. 660 The comex interpretation of timestamps works well for transcoding a 661 Standard MIDI File (SMF) into an RTP MIDI stream, as SMFs code a 662 timestamp for each MIDI command stored in the file. To transcode an SMF 663 that uses metric time markers, use the SMF tempo map (encoded in the SMF 664 as meta-events) to convert metric SMF timestamp units into seconds-based 665 RTP timestamp units. 667 The comex interpretation also works well for MIDI hardware controllers 668 that are coding raw sensor data directly onto an RTP MIDI stream. Note 669 that this controller design that is preferable to a design that converts 670 raw sensor data into a MIDI 1.0 cable command stream and then transcodes 671 the stream onto an RTP MIDI stream. 673 The comex interpretation of timestamps is usually not the best timestamp 674 interpretation for transcoding a MIDI source that uses implicit command 675 timing (such as MIDI 1.0 DIN cables) into an RTP MIDI stream. Appendix 676 C.3 defines alternatives to comex semantics, and describes session 677 configuration tools for selecting the timestamp interpretation semantics 678 for a stream. 680 One-Octet Delta Time: 682 Encoded form: 0ddddddd 683 Decoded form: 00000000 00000000 00000000 0ddddddd 685 Two-Octet Delta Time: 687 Encoded form: 1ccccccc 0ddddddd 688 Decoded form: 00000000 00000000 00cccccc cddddddd 690 Three-Octet Delta Time: 692 Encoded form: 1bbbbbbb 1ccccccc 0ddddddd 693 Decoded form: 00000000 000bbbbb bbcccccc cddddddd 695 Four-Octet Delta Time: 697 Encoded form: 1aaaaaaa 1bbbbbbb 1ccccccc 0ddddddd 698 Decoded form: 0000aaaa aaabbbbb bbcccccc cddddddd 700 Figure 4 -- Decoding delta time formats 702 3.2 Command Coding 704 Each non-empty MIDI Command field in the MIDI list codes one of the MIDI 705 command types that may legally appear on a MIDI 1.0 DIN cable. Standard 706 MIDI File meta-events do not fit this definition and MUST NOT appear in 707 the MIDI list. As a rule, each MIDI Command field codes a complete 708 command, in the binary command format defined in [MIDI]. In the 709 remainder of this section, we describe exceptions to this rule. 711 The first MIDI channel command in the MIDI list MUST include a status 712 octet. Running status coding, as defined in [MIDI], MAY be used for all 713 subsequent MIDI channel commands in the list. As in [MIDI], System 714 Common and System Exclusive messages (0xF0 ... 0xF7) cancel the running 715 status state, but System Real-time messages (0xF8 ... 0xFF) do not 716 affect the running status state. All System commands in the MIDI list 717 MUST include a status octet. 719 As we note above, the first channel command in the MIDI list MUST 720 include a status octet. However, the corresponding command in the 721 original MIDI source data stream might not have a status octet (in this 722 case, the source would be coding the command using running status). If 723 the status octet of the first channel command in the MIDI list does not 724 appear in the source data stream, the P (phantom) header bit MUST be set 725 to 1. In all other cases, the P bit MUST be set to 0. 727 Note that the P bit describes the MIDI source data stream, not the MIDI 728 list encoding; regardless of the state of the P bit, the MIDI list MUST 729 include the status octet. 731 As receivers MUST be able to decode running status, sender implementors 732 should feel free to use running status to improve bandwidth efficiency. 733 However, senders SHOULD NOT introduce timing jitter into an existing 734 MIDI command stream through an inappropriate use or removal of running 735 status coding. This warning primarily applies to senders whose RTP MIDI 736 streams may be transcoded onto a MIDI 1.0 DIN cable [MIDI] by the 737 receiver: both the timestamps and the command coding (running status or 738 not) must comply with the physical restrictions of implicit time coding 739 over a slow serial line. 741 On a MIDI 1.0 DIN cable [MIDI], a System Real-time command may be 742 embedded inside of another "host" MIDI command. This syntactic 743 construction is not supported in the payload format: a MIDI Command 744 field in the MIDI list codes exactly one MIDI command (partially or 745 completely). 747 To encode an embedded System Real-time command, senders MUST extract the 748 command from its host, and code it in the MIDI list as a separate 749 command. The host command and System Real-time command SHOULD appear in 750 the same MIDI list. The delta time of the System Real-time command 751 SHOULD result in a command timestamp that encodes the System Real-time 752 command placement in its original embedded position. 754 Two methods are provided for encoding MIDI System Exclusive (SysEx) 755 commands in the MIDI list. A SysEx command may be encoded in a MIDI 756 Command field verbatim: a 0xF0 octet, followed by an arbitrary number of 757 data octets, followed by a 0xF7 octet. 759 Alternatively, a SysEx command may be encoded as multiple segments. The 760 command is divided into two or more SysEx command segments; each segment 761 is encoded in its own MIDI Command field in the MIDI list. 763 The payload format supports segmentation in order to encode SysEx 764 commands that encode information in the temporal pattern of data octets. 765 By encoding these commands as a series of segments, each data octet may 766 be associated with a distinct delta time. Segmentation also supports 767 the coding of large SysEx commands across several packets. 769 To segment a SysEx command, first partition its data octet list into two 770 or more sublists. The last sublist MAY be empty (i.e. contain no 771 octets); all other sublists MUST contain at least one data octet. To 772 complete the segmentation, add the status octets defined in Figure 5 to 773 the head and tail of the first, last, and any "middle" sublists. Figure 774 6 shows example segmentations of a SysEx command. 776 A sender MAY cancel a segmented SysEx command transmission that is in 777 progress, by sending the "cancel" sublist shown in Figure 5. A "cancel" 778 sublist MAY follow a "first" or "middle" sublist in the transmission, 779 but MUST NOT follow a "last" sublist. The cancel MUST be empty (thus, 780 0xF7 0xF4 is the only legal cancel sublist). 782 The cancellation feature is needed because Appendix C.1 defines 783 configuration tools that let session parties exclude certain SysEx 784 commands in the stream. Senders that transcode a MIDI source onto an 785 RTP MIDI stream under these constraints have the responsibility of 786 excluding undesired commands from the RTP MIDI stream. 788 The cancellation feature lets a sender start the transmission of a 789 command before the MIDI source has sent the entire command. If a sender 790 determines that the command whose transmission is in progress should not 791 appear on the RTP stream, it cancels the command. Without a method for 792 cancelling a SysEx command transmission, senders would be forced to use 793 a high-latency store-and-forward approach to transcoding SysEx commands 794 onto RTP MIDI packets, in order to validate each SysEx command before 795 transmission. 797 The recommended receiver reaction to a cancellation depends on the 798 capabilities of the receiver. For example, a sound synthesizer that is 799 directly parsing RTP MIDI packets and rendering them to audio will be 800 aware of the fact that SysEx commands may be cancelled in RTP MIDI. 801 These receivers SHOULD detect a SysEx cancellation in the MIDI list, and 802 act as if it had never received the SysEx command. 804 As a second example, a synthesizer may be receiving MIDI data from an 805 RTP MIDI stream via a MIDI DIN cable (or a software API emulation of a 806 MIDI DIN cable). In this case, an RTP-MIDI aware system receives the 807 RTP MIDI stream, and transcodes it onto the MIDI DIN cable (or its 808 emulation). Upon the receipt of the cancel sublist, the RTP-MIDI aware 809 transcoder might have already sent the first part of the SysEx command 810 on the MIDI DIN cable to the receiver. 812 Unfortunately, the MIDI DIN cable protocol cannot directly code "cancel 813 SysEx in progress" semantics. However, MIDI DIN cable receivers begin 814 SysEx processing after the complete command arrives. The receiver 815 checks to see if it recognizes the command (coded in the first few 816 octets) and then checks to see if the command is the correct length. 817 Thus, in practice, a transcoder can cancel a SysEx command by sending an 818 0xF7 to (prematurely) end the SysEx command -- the receiver will detect 819 the incorrect command length, and discard the command. 821 Appendix C.1 defines configuration tools that may be used to prohibit 822 SysEx command cancellation. 824 The relative ordering of SysEx command segments in a MIDI list must 825 match the relative ordering of the sublists in the original SysEx 826 command. By default, commands other than System Real-time MIDI commands 827 MUST NOT appear between SysEx command segments (Appendix C.1 defines 828 configuration tools to change this default, to let other commands types 829 appear between segments). If the command segments of a SysEx command 830 are placed in the MIDI lists of two or more RTP packets, the segment 831 ordering rules apply to the concatenation of all affected MIDI lists. 833 ----------------------------------------------------------- 834 | Sublist Position | Head Status Octet | Tail Status Octet | 835 |-----------------------------------------------------------| 836 | first | 0xF0 | 0xF0 | 837 |-----------------------------------------------------------| 838 | middle | 0xF7 | 0xF0 | 839 |-----------------------------------------------------------| 840 | last | 0xF7 | 0xF7 | 841 |-----------------------------------------------------------| 842 | cancel | 0xF7 | 0xF4 | 843 ----------------------------------------------------------- 845 Figure 5 -- Command segmentation status octets 847 [MIDI] permits 0xF7 octets that are not part of a (0xF0, 0xF7) pair to 848 appear on a MIDI 1.0 DIN cable. Unpaired 0xF7 octets have no semantic 849 meaning in MIDI, apart from cancelling running status. 851 Unpaired 0xF7 octets MUST NOT appear in the MIDI list of the MIDI 852 Command section. We impose this restriction to avoid interference with 853 the command segmentation coding defined in Figure 5. 855 SysEx commands carried on a MIDI 1.0 DIN cable may use the "dropped 856 0xF7" construction [MIDI]. In this coding method, the 0xF7 octet is 857 dropped from the end of the SysEx command, and the status octet of the 858 next MIDI command acts both to terminate the SysEx command and start the 859 next command. To encode this construction in the payload format, follow 860 these steps: 862 o Determine the appropriate delta times for the SysEx command and 863 the command that follows the SysEx command. 865 o Insert the "dropped" 0xF7 octet at the end of the SysEx command, 866 to form the standard SysEx syntax. 868 o Code both commands into the MIDI list using the rules above. 870 o Replace the 0xF7 octet that terminates the verbatim SysEx 871 encoding or the last segment of the segmented SysEx encoding 872 with a 0xF5 octet. This substitution informs the receiver 873 of the original dropped 0xF7 coding. 875 [MIDI] reserves the undefined System Common commands 0xF4 and 0xF5 and 876 the undefined System Real-time commands 0xF9 and 0xFD for future use. 877 By default, undefined commands MUST NOT appear in a MIDI Command field 878 in the MIDI list, with the exception of the 0xF5 octets used to code the 879 "dropped 0xF7" construction and the 0xF4 octets used by SysEx "cancel" 880 sublists. 882 During session configuration, a stream may be customized to transport 883 undefined commands (Appendix C.1). For this case, we now define how 884 senders encode undefined commands in the MIDI list. 886 An undefined System Real-time command MUST be coded using the System 887 Real-time rules. 889 If the undefined System Common commands are put to use in a future 890 version of [MIDI], the command will begin with an 0xF4 or 0xF5 status 891 octet, followed by an arbitrary number of data octets (i.e. zero or more 892 data bytes). To encode these commands, senders MUST terminate the 893 command with an 0xF7 octet, and place the modified command into the MIDI 894 Command field. 896 Unfortunately, non-compliant uses of the undefined System Common 897 commands may appear in MIDI implementations. To model these commands, 898 we assume the command begins with an 0xF4 or 0xF5 status octet, followed 899 by zero or more data octets, followed by zero or more trailing 0xF7 900 status octet(s). To encode the command, senders MUST first remove all 901 trailing 0xF7 status octets from the command. Then, senders MUST 902 terminate the command with an 0xF7 octet, and place the modified command 903 into the MIDI Command field. 905 Note that we include the trailing octets in our model as a cautionary 906 measure: if such commands appeared in a non-compliant use of an 907 undefined System Common command, an RTP MIDI encoding of the command 908 that did not remove trailing octets could be mistaken for an encoding of 909 "middle" or "last" sublist of a segmented SysEx commands (Figure 5) 910 under certain packet loss conditions. 912 Original SysEx command: 914 0xF0 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0xF7 916 A two-segment segmentation: 918 0xF0 0x01 0x02 0x03 0x04 0xF0 920 0xF7 0x05 0x06 0x07 0x08 0xF7 922 A different two-segment segmentation: 924 0xF0 0x01 0xF0 926 0xF7 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0xF7 928 A three-segment segmentation: 930 0xF0 0x01 0x02 0xF0 932 0xF7 0x03 0x04 0xF0 934 0xF7 0x05 0x06 0x07 0x08 0xF7 936 The segmentation with the largest number of segments: 938 0xF0 0x01 0xF0 940 0xF7 0x02 0xF0 942 0xF7 0x03 0xF0 944 0xF7 0x04 0xF0 946 0xF7 0x05 0xF0 948 0xF7 0x06 0xF0 950 0xF7 0x07 0xF0 952 0xF7 0x08 0xF0 954 0xF7 0xF7 956 Figure 6 -- Example segmentations 958 4. The Recovery Journal System 960 The recovery journal is the default resiliency tool for unreliable 961 transport. In this section, we normatively define the roles that 962 senders and receivers play in the recovery journal system. 964 MIDI is a fragile code. A single lost command in a MIDI command stream 965 may produce an artifact in the rendered performance. We normatively 966 classify rendering artifacts into two categories: 968 o Transient artifacts. Transient artifacts produce immediate 969 but short-term glitches in the performance. For example, a lost 970 NoteOn (0x9) command produces a transient artifact: one note 971 fails to play, but the artifact does not extend beyond the end 972 of that note. 974 o Indefinite artifacts. Indefinite artifacts produce long-lasting 975 errors in the rendered performance. For example, a lost NoteOff 976 (0x8) command may produce an indefinite artifact: the note that 977 should have been ended by the lost NoteOff command may sustain 978 indefinitely. As a second example, the loss of a Control Change 979 (0xB) command for controller number 7 (Channel Volume) may 980 produce an indefinite artifact: after the loss, all notes on 981 the channel may play too softly or too loudly. 983 The purpose of the recovery journal system is to satisfy the recovery 984 journal mandate: the MIDI performance rendered from an RTP MIDI stream 985 sent over unreliable transport MUST NOT contain indefinite artifacts. 987 The recovery journal system does not use packet retransmission to 988 satisfy this mandate. Instead, each packet includes a special section, 989 called the recovery journal. 991 The recovery journal codes the history of the stream, back to an earlier 992 packet called the checkpoint packet. The range of coverage for the 993 journal is called the checkpoint history. The recovery journal codes 994 the information necessary to recover from the loss of an arbitrary 995 number of packets in the checkpoint history. Appendix A.1 normatively 996 defines the checkpoint packet and the checkpoint history. 998 When a receiver detects a packet loss, it compares its own knowledge 999 about the history of the stream with the history information coded in 1000 the recovery journal of the packet that ends the loss event. By noting 1001 the differences in these two versions of the past, a receiver is able to 1002 transform all indefinite artifacts in the rendered performance into 1003 transient artifacts, by executing MIDI commands to repair the stream. 1005 We now state the normative role for senders in the recovery journal 1006 system. 1008 Senders prepare a recovery journal for every packet in the stream. In 1009 doing so, senders choose the checkpoint packet identity for the journal. 1010 Senders make this choice by applying a sending policy. Appendix C.2.2 1011 normatively defines three sending policies: "closed-loop", "open-loop", 1012 and "anchor". 1014 By default, senders MUST use the closed-loop sending policy. If the 1015 session description overrides this default policy, by using the 1016 parameter j_update defined in Appendix C.2.2, senders MUST use the 1017 specified policy. 1019 After choosing the checkpoint packet identity for a packet, the sender 1020 creates the recovery journal. By default, this journal MUST conform to 1021 the normative semantics in Section 5 and Appendices A-B in this memo. 1022 In Appendix C.2.3, we define parameters that modify the normative 1023 semantics for recovery journals. If the session description uses these 1024 parameters, the journal created by the sender MUST conform to the 1025 modified semantics. 1027 Next, we state the normative role for receivers in the recovery journal 1028 system. 1030 A receiver MUST detect each RTP sequence number break in a stream. If 1031 the sequence number break is due to a packet loss event (as defined in 1032 [RFC3550]) the receiver MUST repair all indefinite artifacts in the 1033 rendered MIDI performance caused by the loss. If the sequence number 1034 break is due to an out-of-order packet (as defined in [RFC3550]) the 1035 receiver MUST NOT take actions that introduce indefinite artifacts 1036 (ignoring the out-of-order packet is a safe option). 1038 Receivers take special precautions when entering or exiting a session. 1039 A receiver MUST process the first received packet in a stream as if it 1040 were a packet that ends a loss event. Upon exiting a session, a 1041 receiver MUST ensure that the rendered MIDI performance does not end 1042 with indefinite artifacts. 1044 Receivers are under no obligation to perform indefinite artifact repairs 1045 at the moment a packet arrives. A receiver that uses a playout buffer 1046 may choose to wait until the moment of rendering before processing the 1047 recovery journal, as the "lost" packet may be a late packet that arrives 1048 in time to use. 1050 Next, we state the normative role for the creator of the session 1051 description in the recovery journal system. Depending on the 1052 application, the sender, the receivers, and other parties may take part 1053 in creating or approving the session description. 1055 A session description that specifies the default closed-loop sending 1056 policy and the default recovery journal semantics satisfies the recovery 1057 journal mandate. However, these default behaviors may not be 1058 appropriate for all sessions. If the creators of a session description 1059 use the parameters defined in Appendix C.2 to override these defaults, 1060 the creators MUST ensure that the parameters define a system that 1061 satisfy the recovery journal mandate. 1063 Finally, we note that this memo does not specify sender or receiver 1064 recovery journal algorithms. Implementations are free to use any 1065 algorithm that conforms to the requirements in this section. The non- 1066 normative [GUIDE] discusses sender and receiver algorithm design. 1068 5. Recovery Journal Format 1070 This section introduces the structure of the recovery journal, and 1071 defines the bitfields of recovery journal headers. Appendices A-B 1072 complete the bitfield definition of the recovery journal. 1074 The recovery journal has a three-level structure: 1076 o Top-level header. 1078 o Channel and system journal headers. Encodes recovery 1079 information for a single voice channel (channel journal) or 1080 for all systems commands (system journal). 1082 o Chapters. Describes recovery information for a single MIDI 1083 command type. 1085 Figure 7 shows the top-level structure of the recovery journal. The 1086 recovery journals consists of a 3-octet header, followed by an optional 1087 system journal (labeled S-journal in Figure 7) and an optional list of 1088 channel journals. Figure 8 shows the recovery journal header format. 1090 0 1 2 3 1091 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 1092 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1093 | Recovery journal header | S-journal ... | 1094 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1095 | Channel journals ... | 1096 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1098 Figure 7 -- Top-level recovery journal format 1100 0 1 2 1101 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 1102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1103 |S|Y|A|H|TOTCHAN| Checkpoint Packet Seqnum | 1104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1106 Figure 8 -- Recovery journal header 1108 If the Y header bit is set to 1, the system journal appears in recovery 1109 journal, directly following the recovery journal header. 1111 If the A header bit is set to 1, the recovery journal ends with a list 1112 of (TOTCHAN + 1) channel journals (the 4-bit TOTCHAN header field is 1113 interpreted as an unsigned integer). 1115 A MIDI channel MAY be represented by (at most) one channel journal in a 1116 recovery journal. Channel journals MUST appear in the recovery journal 1117 in ascending channel-number order. 1119 If A and Y are both zero, the recovery journal only contains its 3-octet 1120 header, and is considered to be an "empty" journal. 1122 The S (single-packet loss) bit appears in most recovery journal 1123 structures, including the recovery journal header. The S bit helps 1124 receivers efficiently parse the recovery journal in the common case of 1125 the loss of a single packet. Appendix A.1 defines S bit semantics. 1127 The H bit indicates if MIDI channels in the stream have been configured 1128 to use the enhanced Chapter C encoding (Appendix A.3.3). 1130 By default, the payload format does not use enhanced Chapter C encoding. 1131 In this default case, the H bit MUST be set to 0 for all packets in the 1132 stream. 1134 If the stream has been configured so that controller numbers for one or 1135 more MIDI channels use enhanced Chapter C encoding, the H bit MUST be 1136 set to 1 in all packets in the stream. In Appendix C.2.3, we show how 1137 to configure a stream to use enhanced Chapter C encoding. 1139 The 16-bit Checkpoint Packet Seqnum header field codes the sequence 1140 number of the checkpoint packet for this journal, in network byte order 1141 (big-endian). The choice of the checkpoint packet sets the depth of the 1142 checkpoint history for the journal (defined in Appendix A.1). 1144 Receivers may use the Checkpoint Packet Seqnum field of the packet that 1145 ends a loss event to verify that the journal checkpoint history covers 1146 the entire loss event. The checkpoint history covers the loss event if 1147 the Checkpoint Packet Seqnum field is less than or equal to one plus the 1148 highest RTP sequence number previously received on the stream (modulo 1149 2^16). 1151 0 1 2 3 1152 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 1153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1154 |S| CHAN |H| LENGTH |P|C|M|W|N|E|T|A| Chapters ... | 1155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1157 Figure 9 -- Channel journal format 1159 Figure 9 shows the structure of a channel journal: a 3-octet header, 1160 followed by a list of leaf elements called channel chapters. A channel 1161 journal encodes information about MIDI commands on the MIDI channel 1162 coded by the 4-bit CHAN header field. Note that CHAN uses the same bit 1163 encoding as the channel nibble in MIDI Channel Messages (the cccc field 1164 in Figure E.1 of Appendix E). 1166 The 10-bit LENGTH field codes the length of the channel journal. The 1167 semantics for LENGTH fields are uniform throughout the recovery journal, 1168 and are defined in Appendix A.1. 1170 The third octet of the channel journal header is the Table of Contents 1171 (TOC) of the channel journal. The TOC is a set of bits that encode the 1172 presence of a chapter in the journal. Each chapter contains information 1173 about a certain class of MIDI channel command: 1175 o Chapter P: MIDI Program Change (0xC) 1176 o Chapter C: MIDI Control Change (0xB) 1177 o Chapter M: MIDI Parameter System (part of 0xB) 1178 o Chapter W: MIDI Pitch Wheel (0xE) 1179 o Chapter N: MIDI NoteOff (0x8), NoteOn (0x9) 1180 o Chapter E: MIDI Note Command Extras (0x8, 0x9) 1181 o Chapter T: MIDI Channel Aftertouch (0xD) 1182 o Chapter A: MIDI Poly Aftertouch (0xA) 1184 Chapters appear in a list following the header, in order of their 1185 appearance in the TOC. Appendices A.2-9 describe the bitfield format 1186 for each chapter, and define the conditions under which a chapter type 1187 MUST appear in the recovery journal. If any chapter types are required 1188 for a channel, an associated channel journal MUST appear in the recovery 1189 journal. 1191 The H bit indicates if controller numbers on a MIDI channel have been 1192 configured to use the enhanced Chapter C encoding (Appendix A.3.3). 1194 By default, controller numbers on a MIDI channel do not use enhanced 1195 Chapter C encoding. In this default case, the H bit MUST be set to 0 1196 for all channel journal headers for the channel in the recovery journal, 1197 for all packets in the stream. 1199 However, if at least one controller number for a MIDI channel has been 1200 configured to use the enhanced Chapter C encoding, the H bit for its 1201 channel journal MUST be set to 1, for all packets in the stream. 1203 In Appendix C.2.3, we show how to configure a controller number to use 1204 enhanced Chapter C encoding. 1206 0 1 2 3 1207 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 1208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1209 |S|D|V|Q|F|X| LENGTH | System chapters ... | 1210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1212 Figure 10 -- System journal format 1214 Figure 10 shows the structure of the system journal: a 2-octet header, 1215 followed by a list of system chapters. Each chapter codes information 1216 about a specific class of MIDI Systems command: 1218 o Chapter D: Song Select (0xF3), Tune Request (0xF6), Reset (0xFF), 1219 undefined System commands (0xF4, 0xF5, 0xF9, 0xFD) 1220 o Chapter V: Active Sense (0xFE) 1221 o Chapter Q: Sequencer State (0xF2, 0xF8, 0xF9, 0xFA, 0xFB, 0xFC) 1222 o Chapter F: MTC Tape Position (0xF1, 0xF0 0x7F 0xcc 0x01 0x01) 1223 o Chapter X: System Exclusive (all other 0xF0) 1225 The 10-bit LENGTH field codes the size of the system journal, and 1226 conforms to semantics described in Appendix A.1. 1228 The D, V, Q, F, and X header bits form a Table of Contents (TOC) for the 1229 system journal. A TOC bit that is set to 1 codes the presence of a 1230 chapter in the journal. Chapters appear in a list following the header, 1231 in the order of their appearance in the TOC. 1233 Appendix B describes the bitfield format for the system chapters, and 1234 define the conditions under which a chapter type MUST appear in the 1235 recovery journal. If any system chapter type is required to appear in 1236 the recovery journal, the system journal MUST appear in the recovery 1237 journal. 1239 6. Session Description Protocol 1241 RTP does not perform session management. Instead, RTP works together 1242 with session management tools, such as the Session Initiation Protocol 1243 (SIP, [RFC3261]) and the Real Time Streaming Protocol (RTSP, [RFC2326]). 1245 RTP payload formats define media type parameters for use in session 1246 management (for example, this memo defines "rtp-midi" as the media type 1247 for native RTP MIDI streams). 1249 In most cases, session management tools use the media type parameters 1250 via another standard, the Session Description Protocol (SDP, [SDP]). 1252 SDP is a textual format for specifying session descriptions. Session 1253 descriptions specify the network transport and media encoding for RTP 1254 sessions. Session management tools coordinate the exchange of session 1255 descriptions between participants ("parties"). 1257 Some session management tools use SDP to negotiate details of media 1258 transport (network addresses, ports, etc). We refer to this use of SDP 1259 as "negotiated usage". One example of negotiated usage is the 1260 Offer/Answer protocol ([RFC3264] and Appendix C.7.2 in this memo) as 1261 used by SIP. 1263 Other session management tools use SDP to declare the media encoding for 1264 the session, but use other techniques to negotiate network transport. 1265 We refer to this use of SDP as "declarative usage". One example of 1266 declarative usage is RTSP ([RFC2326] and Appendix C.7.1 in this memo). 1268 Below, we show session description examples for native (Section 6.1) and 1269 mpeg4-generic (Section 6.2) streams. In Section 6.3, we introduce 1270 session configuration tools that may be used to customize streams. 1272 6.1 Session Descriptions for Native Streams 1274 The session description below defines a unicast UDP RTP session (via a 1275 media ("m=") line) whose sole payload type (96) is mapped to a minimal 1276 native RTP MIDI stream. 1278 v=0 1279 o=lazzaro 2520644554 2838152170 IN IP4 first.example.net 1280 s=Example 1281 t=0 0 1282 m=audio 5004 RTP/AVP 96 1283 c=IN IP4 192.0.2.94 1284 a=rtpmap:96 rtp-midi/44100 1286 The rtpmap attribute line uses the "rtp-midi" media type to specify an 1287 RTP MIDI native stream. The clock rate specified on the rtpmap line (in 1288 the example above, 44100 Hz) sets the scaling for the RTP timestamp 1289 header field (see Section 2.1, and also [RFC3550]). 1291 Note that this document does not specify a default clock rate value for 1292 RTP MIDI. When RTP MIDI is used with SDP, parties MUST use the rtpmap 1293 line to communicate the clock rate. Guidance for selecting the RTP MIDI 1294 clock rate value appears in Section 2.1. 1296 We consider the RTP MIDI stream shown above to be "minimal" because the 1297 session description does not customize the stream with parameters. 1298 Without such customization, a native RTP MIDI stream has these 1299 characteristics: 1301 1. If the stream uses unreliable transport (unicast UDP, multicast 1302 UDP, ...), the recovery journal system is in use, and the RTP 1303 payload contains both the MIDI command section and the journal 1304 section. If the stream uses reliable transport (such as TCP), 1305 the stream does not use journalling, and the payload contains 1306 only the MIDI command section (Section 2.2). 1308 2. If the stream uses the recovery journal system, the recovery 1309 journal system uses the default sending policy and the default 1310 journal semantics (Section 4). 1312 3. In the MIDI command section of the payload, command timestamps 1313 use the default "comex" semantics (Section 3). 1315 4. The recommended temporal duration ("media time") an RTP packet 1316 ranges from 0 to 200 ms, and the RTP timestamp difference between 1317 sequential packets in the stream may be arbitrarily large 1318 (Section 2.1). 1320 5. If more than one minimal rtp-midi stream appears in a session, 1321 the MIDI name spaces for these streams are independent: channel 1322 1 in the first stream does not reference the same MIDI channel 1323 as channel 1 in the second stream (see Appendix C.5 for a 1324 discussion of the independence of minimal rtp-midi streams). 1326 6. The rendering method for the stream is not specified. What a 1327 what the receiver "does" with a minimal native MIDI stream is 1328 "out of scope" of this memo. For example, in content creation 1329 environments, a user may manually configure client software to 1330 render the stream with a specific software package. 1332 As in standard in RTP, RTP sessions managed by SIP are sendrecv by 1333 default (parties send and receive MIDI), and RTP sessions managed by 1334 RTSP are recvonly by default (server sends and client receives). 1336 In sendrecv RTP MIDI sessions for the session description shown above, 1337 the 16 voice channel + systems MIDI name space is unique for each 1338 sender. Thus, in a two party session, the voice channel 0 sent by one 1339 party is distinct from the voice channel 0 sent by the other party. 1341 This behavior corresponds to what occurs when two MIDI 1.0 DIN devices 1342 are cross-connected with two MIDI cables (one cable routing MIDI Out 1343 from the first device into MIDI In of the second device, a second cable 1344 routing MIDI In from the first device into MIDI Out of the second 1345 device). We define this "association" formally in Section 2.1. 1347 MIDI 1.0 DIN networks may be configured in a "party-line" multicast 1348 topology. For these networks, the MIDI protocol itself provides tools 1349 for addressing specific devices in transactions on a multicast network, 1350 and for device discovery. Thus, apart from providing a 1-to-many 1351 forward path and a many-to-1 reverse path, IETF protocols do not need to 1352 provide any special support for MIDI multicast networking. 1354 6.2 Session Descriptions for mpeg4-generic Streams 1356 An mpeg4-generic [RFC3640] RTP MIDI stream uses an MPEG 4 Audio Object 1357 Type to render MIDI into audio. Three Audio Object Types accept MIDI 1358 input: 1360 o General MIDI (Audio Object Type ID 15), based on the General 1361 MIDI rendering standard [MIDI]. 1363 o Wavetable Synthesis (Audio Object Type ID 14), based on the 1364 Downloadable Sounds Level 2 (DLS 2) rendering standard [DLS2]. 1366 o Main Synthetic (Audio Object Type ID 13), based on Structured 1367 Audio and the programming language SAOL [MPEGSA]. 1369 The primary service of an mpeg4-generic stream is to code Access Units 1370 (AUs). We define the mpeg4-generic RTP MIDI AU as the MIDI payload 1371 shown in Figure 1 of Section 2.1 of this memo: a MIDI command section 1372 optionally followed by a journal section. 1374 Exactly one RTP MIDI AU MUST be mapped to one mpeg4-generic RTP MIDI 1375 packet. The mpeg4-generic options for placing several AUs in an RTP 1376 packet MUST NOT be used with RTP MIDI. The mpeg4-generic options for 1377 fragmenting and interleaving AUs MUST NOT be used with RTP MIDI. The 1378 mpeg4-generic RTP packet payload (Figure 1 in [RFC3640]) MUST contain 1379 empty AU Header and Auxiliary sections. These rules yield mpeg4-generic 1380 packets that are structurally identical to native RTP MIDI packets, an 1381 essential property for the correct operation of the payload format. 1383 The session description below defines a unicast UDP RTP session (via a 1384 media ("m=") line) whose sole payload type (96) is mapped to a minimal 1385 mpeg4-generic RTP MIDI stream. This example uses the General MIDI Audio 1386 Object Type under Synthesis Profile @ Level 2. 1388 v=0 1389 o=lazzaro 2520644554 2838152170 IN IP6 first.example.net 1390 s=Example 1391 t=0 0 1392 m=audio 5004 RTP/AVP 96 1393 c=IN IP6 2001:DB80::7F2E:172A:1E24 1394 a=rtpmap:96 mpeg4-generic/44100 1395 a=fmtp:96 streamtype=5; mode=rtp-midi; profile-level-id=12; 1396 config=7A0A0000001A4D546864000000060000000100604D54726B0000 1397 000600FF2F000 1399 (The a=fmtp line has been wrapped to fit the page to accommodate 1400 memo formatting restrictions; it comprises a single line in SDP) 1402 The fmtp attribute line codes the four parameters (streamtype, mode, 1403 profile-level-id, and config) that are required in all mpeg4-generic 1404 session descriptions [RFC3640]. For RTP MIDI streams, the streamtype 1405 parameter MUST be set to 5, the "mode" parameter MUST be set to "rtp- 1406 midi", and the "profile-level-id" parameter MUST be set to the MPEG-4 1407 Profile Level for the stream. For the Synthesis Profile, legal profile- 1408 level-id values are 11, 12, and 13, coding low (11), medium (12), or 1409 high (13) decoder computational complexity, as defined by MPEG 1410 conformance tests. 1412 In a minimal RTP MIDI session description, the config value MUST be a 1413 hexadecimal encoding [RFC3640] of the AudioSpecificConfig data block 1414 [MPEGAUDIO] for the stream. AudioSpecificConfig encodes the Audio 1415 Object Type for the stream, and also encodes initialization data (SAOL 1416 programs, DLS 2 wave tables, etc). Standard MIDI Files encoded in 1417 AudioSpecificConfig in a minimal session description MUST be ignored by 1418 the receiver. 1420 Receivers determine the rendering algorithm for the session by 1421 interpreting the first 5 bits of AudioSpecificConfig as an unsigned 1422 integer that codes the Audio Object Type. In our example above, the 1423 leading config string nibbles "7A" yield the Audio Object Type 15 1424 (General MIDI). In Appendix E.4, we derive the config string value in 1425 the session description shown above; the starting point of the 1426 derivation is the MPEG bitstreams defined in [MPEGSA] and [MPEGAUDIO]. 1428 We consider the stream to be "minimal" because the session description 1429 does not customize the stream through the use of parameters, other than 1430 the 4 required mpeg4-generic parameters described above. In Section 1431 6.1, we describe the behavior of a minimal native stream, as a numbered 1432 list of characteristics. Items 1-4 on that list also describe the 1433 minimal mpeg4-generic stream, but items 5 and 6 require restatements, as 1434 listed below: 1436 5. If more than one minimal mpeg4-generic stream appears in 1437 a session, each stream uses an independent instance of the 1438 Audio Object Type coded in the config parameter value. 1440 6. A minimal mpeg4-generic stream encodes the AudioSpecificConfig 1441 as an inline hexadecimal constant. If session description 1442 is sent over UDP, it may be impossible to transport large 1443 AudioSpecificConfig blocks within the Maximum Transmission Size 1444 (MTU) of the underlying network (for Ethernet, the MTU is 1500 1445 octets). In some cases, the AudioSpecificConfig block may 1446 exceed the maximum size of the UDP packet itself. 1448 The comments in Section 6.1 on SIP and RTSP stream directional defaults, 1449 sendrecv MIDI channel usage and MIDI 1.0 DIN multicast networks also 1450 apply to mpeg4-generic RTP MIDI sessions. 1452 In sendrecv sessions, each party's session description MUST use 1453 identical values for the mpeg4-generic parameters (including the 1454 required streamtype, mode, profile-level-id, and config parameters). As 1455 a consequence, each party uses an identically-configured MPEG 4 Audio 1456 Object Type to render MIDI commands into audio. The preamble to 1457 Appendix C discusses a way to create "virtual sendrecv" sessions that do 1458 not have this restriction. 1460 6.3 Parameters 1462 This section introduces parameters for session configuration for RTP 1463 MIDI streams. In session descriptions, parameters modify the semantics 1464 of a payload type. Parameters are specified on a fmtp attribute line. 1465 See the session description example in Section 6.2 for an example of a 1466 fmtp attribute line. 1468 The parameters add features to the minimal streams described in Sections 1469 6.1-2, and support several types of services: 1471 o Stream subsetting. By default, all MIDI commands that 1472 are legal to appear on a MIDI 1.0 DIN cable may appear 1473 in an RTP MIDI stream. The cm_unused parameter overrides 1474 this default by prohibiting certain commands from appearing 1475 in the stream. The cm_used parameter is used in conjunction 1476 with cm_unused, to simplify the specification of complex 1477 exclusion rules. We describe cm_unused and cm_used in 1478 Appendix C.1. 1480 o Journal customization. The j_sec and j_update parameters 1481 configure the use of the journal section. The ch_default, 1482 ch_never, and ch_anchor parameters configure the semantics 1483 of the recovery journal chapters. These parameters are 1484 described in Appendix C.2, and override the default stream 1485 behaviors 1 and 2 listed in Section 6.1 and referenced in 1486 Section 6.2. 1488 o MIDI command timestamp semantics. The tsmode, octpos, 1489 mperiod, and linerate parameters customize the semantics 1490 of timestamps in the MIDI command section. These parameters 1491 let RTP MIDI accurately encode the implicit time coding of 1492 MIDI 1.0 DIN cables. These parameters are described in 1493 Appendix C.3, and override default stream behavior 3 listed in 1494 Section 6.1 and referenced in Section 6.2 1496 o Media time. The rtp_ptime and rtp_maxptime parameters define 1497 the temporal duration ("media time") of an RTP MIDI packet. 1498 The guardtime parameter sets the minimum sending rate of stream 1499 packets. These parameters are described in Appendix C.4, 1500 and override default stream behavior 4 listed in Section 6.1 1501 and referenced in Section 6.2. 1503 o Stream description. The musicport parameter labels the 1504 MIDI name space of RTP streams in a multimedia session. 1505 Musicport is described in Appendix C.5. The musicport 1506 parameter overrides default stream behavior 5 in Sections 1507 6.1 and 6.2. 1509 o MIDI rendering. Several parameters specify the MIDI 1510 rendering method of a stream. These parameters are described 1511 in Appendix C.6, and override default stream behavior 6 in 1512 Sections 6.1 and 6.2. 1514 In Appendix C.7, we specify interoperability guidelines for two RTP MIDI 1515 application areas: content-streaming using RTSP (Appendix C.7.1) and 1516 network musical performance using SIP (Appendix C.7.2). 1518 7. Extensibility 1520 The payload format defined in this memo exclusively encodes all commands 1521 that may legally appear on a MIDI 1.0 DIN cable. 1523 Many worthy uses of MIDI over RTP do not fall within the narrow scope of 1524 the payload format. For example, the payload format does not support 1525 the direct transport of Standard MIDI File (SMF) meta-event and metric 1526 timing data. As a second example, the payload format does not define 1527 transport tools for user-defined commands (apart from tools to support 1528 System Exclusive commands [MIDI]). 1530 The payload format does not provide an extension mechanism to support 1531 new features of this nature, by design. Instead, we encourage the 1532 development of new payload formats for specialized musical applications. 1533 The IETF session management tools [RFC3264] [RFC2326] support codec 1534 negotiation, to facilitate the use of new payload formats in a backward- 1535 compatible way. 1537 However, the payload format does provide several extensibility tools, 1538 which we list below: 1540 o Journalling. As described in Appendix C.2, new token 1541 values for the j_sec and j_update parameters may 1542 be defined in IETF standards-track documents. This 1543 mechanism supports the design of new journal formats 1544 and the definition of new journal sending policies. 1546 o Rendering. The payload format may be extended to support 1547 new MIDI renderers (Appendix C.6.2). Certain general aspects 1548 of the RTP MIDI rendering process may also be extended, via 1549 the definition of new token values for the render (Appendix C.6) 1550 and smf_info (Appendix C.6.4.1) parameters. 1552 o Undefined commands. [MIDI] reserves 4 MIDI System commands 1553 for future use (0xF4, 0xF5, 0xF9, 0xFD). If updates 1554 to [MIDI] define the reserved commands, IETF standards-track 1555 documents may be defined to provide resiliency support for 1556 the commands. Opaque LEGAL fields appear in System Chapter 1557 D for this purpose (Appendix B.1.1). 1559 A final form of extensibility involves the inclusion of the payload 1560 format in framework documents. Framework documents describe how to 1561 combine protocols to form a platform for interoperable applications. 1562 For example, a stage and studio framework might define how to use SIP 1563 [RFC3261], RTSP [RFC2326], SDP [SDP] and RTP [RFC3550] to support media 1564 networking for professional audio equipment and electronic musical 1565 instruments. 1567 8. Congestion Control 1569 The RTP congestion control requirements defined in [RFC3550] apply to 1570 RTP MIDI sessions, and implementors should carefully read the congestion 1571 control section in [RFC3550]. As noted in [RFC3550], all transport 1572 protocols used on the Internet need to address congestion control in 1573 some way, and RTP is not an exception. 1575 In addition, the congestion control requirements defined in [RFC3551] 1576 applies to RTP MIDI sessions run under applicable profiles. The basic 1577 congestion control requirement defined in [RFC3551] is that RTP sessions 1578 that use UDP transport should monitor packet loss (via RTCP, or via 1579 other means) to ensure that the RTP stream competes fairly with TCP 1580 flows that share the network. 1582 Finally, RTP MIDI has congestion control issues that are unique for an 1583 audio RTP payload format. In applications such as network musical 1584 performance [NMP], the packet rate is linked to the gestural rate of a 1585 human performer. Senders MUST monitor the MIDI command source for 1586 patterns that result in excessive packet rates, and take actions during 1587 RTP transcoding to reduce the RTP packet rate. [GUIDE] offers 1588 implementation guidance on this issue. 1590 A. The Recovery Journal Channel Chapters 1592 A.1 Recovery Journal Definitions 1594 This Appendix defines the terminology and the coding idioms that are 1595 used in the recovery journal bitfield descriptions in Section 5 (journal 1596 header structure), Appendices A.2-9 (channel journal chapters) and 1597 Appendices B.1-5 (system journal chapters). 1599 We assume that the recovery journal resides in the journal section of an 1600 RTP packet with sequence number I ("packet I") and that the Checkpoint 1601 Packet Seqnum field in the top-level recovery journal header refers to a 1602 previous packet with sequence number C (an exception is the self- 1603 referential C = I case). Unless stated otherwise, algorithms are 1604 assumed to use modulo 2^16 arithmetic for calculations on 16-bit 1605 sequence numbers and modulo 2^32 arithmetic for calculations on 32-bit 1606 extended sequence numbers. 1608 Several bitfield coding idioms appear throughout the recovery journal 1609 system, with consistent semantics. Most recovery journal elements begin 1610 with an "S" (Single-packet loss) bit. S bits are designed to help 1611 receivers efficiently parse through the recovery journal hierarchy in 1612 the common case of the loss of a single packet. 1614 As a rule, S bits MUST be set to 1. However, an exception applies if a 1615 recovery journal element in packet I encodes data about a command stored 1616 in the MIDI command section of packet I - 1. In this case, the S bit of 1617 the recovery journal element MUST be set to 0. If a recovery journal 1618 element has its S bit set to 0, all higher-level recovery journal 1619 elements that contain it MUST also have S bits that are set to 0, 1620 including the top-level recovery journal header. 1622 Other consistent bitfield coding idioms are described below: 1624 o R flag bit. R flag bits are reserved for future use. Senders 1625 MUST set R bits to 0. Receivers MUST ignore R bit values. 1627 o LENGTH field. All fields named LENGTH (as distinct from LEN) 1628 code the number of octets in the structure that contains it, 1629 including the header it resides in and all hierarchical levels 1630 below it. If a structure contains a LENGTH field, a receiver 1631 MUST use the LENGTH field value to advance past the structure 1632 during parsing, rather than use knowledge about the internal 1633 format of the structure. 1635 We now define normative terms used to describe recovery journal 1636 semantics. 1638 o Checkpoint history. The checkpoint history of a recovery journal 1639 is the concatenation of the MIDI command sections of packets C 1640 through I - 1. The final command in the MIDI command section for 1641 packet I - 1 is considered the most recent command; the first 1642 command in the MIDI command section for packet C is the oldest 1643 command. If command X is less recent than command Y, X is 1644 considered to be "before Y". A checkpoint history with no 1645 commands is considered to be empty. The checkpoint history 1646 never contains the MIDI command section of the packet I (the 1647 packet containing the recovery journal), so if C == I, the 1648 checkpoint history is empty by definition. 1650 o Session history. The session history of a recovery journal is 1651 the concatenation of MIDI command sections from the first 1652 packet of the session up to packet I - 1. The definitions of 1653 command recency and history emptiness follow those in the 1654 checkpoint history. The session history never contains the 1655 MIDI command section of packet I, and so the session history of 1656 the first packet in the session is empty by definition. 1658 o Finished/unfinished commands. If all octets of a MIDI command 1659 appear in the session history, the command is defined to be 1660 finished. If some but not all octets of a command appear 1661 in the session history, the command is defined to be unfinished. 1662 Unfinished commands occur if segments of a SysEx command appear 1663 in several RTP packets. For example, if a SysEx command is coded 1664 as 3 segments, with segment 1 in packet K, segment 2 in packet 1665 K + 1, and segment 3 in packet K + 2, the session histories for 1666 packets K + 1 and K + 2 contain unfinished versions of the command. 1667 A session history contains a finished version of a cancelled SysEx 1668 command if the history contains the cancel sublist for the command. 1670 o Reset State commands. Reset State (RS) commands reset 1671 renderers to an initialized "powerup" condition. The 1672 RS commands are: System Reset (0xFF), General MIDI System Enable 1673 (0xF0 0x7E 0xcc 0x09 0x01 0xF7), General MIDI 2 System Enable 1674 (0xF0 0x7E 0xcc 0x09 0x03 0xF7), General MIDI System Disable 1675 (0xF0 0x7E 0xcc 0x09 0x00 0xF7), Turn DLS On (0xF0 0x7E 0xcc 0x0A 1676 0x01 0xF7) and Turn DLS Off (0xF0 0x7E 0xcc 0x0A 0x02 0xF7). 1677 Registrations of subrender parameter token values (Appendix C.6.2) 1678 and IETF standards-track documents MAY specify additional 1679 RS commands. 1681 o Active commands. Active command are MIDI commands that do not 1682 appear before a Reset State command in the session history. 1684 o N-active commands. N-active commands are MIDI commands that do 1685 not appear before one of the following commands in the session 1686 history: MIDI Control Change numbers 123-127 (numbers with All 1687 Notes Off semantics) or 120 (All Sound Off), and any Reset 1688 State command. 1690 o C-active commands. C-active commands are MIDI commands that do 1691 not appear before one of the following commands in the session 1692 history: MIDI Control Change number 121 (Reset All Controllers) 1693 and any Reset State command. 1695 o Oldest-first ordering rule. Several recovery journal chapters 1696 contain a list of elements, where each element is associated 1697 with a MIDI command that appears in the session history. In 1698 most cases, the chapter definition requires that list elements 1699 be ordered in accordance with the "oldest-first ordering rule". 1700 Below, we normatively define this rule: 1702 Elements associated with the most recent command in the session 1703 history coded in the list MUST appear at the end of the list. 1705 Elements associated with the oldest command in the session 1706 history coded in the list MUST appear at the start of the list. 1708 All other list elements MUST be arranged with respect to these 1709 boundary elements, to produce a list ordering that strictly 1710 reflects the relative session history recency of the commands 1711 coded by the elements in the list. 1713 o Parameter system. A MIDI feature that provides two sets of 1714 16,384 parameters to expand the 0-127 controller number space. 1715 The Registered Parameter Names (RPN) system and the Non-Registered 1716 Parameter Names (NRPN) system each provides 16,384 parameters. 1718 o Parameter system transaction. The value of RPNs and NRPNs are 1719 changed by a series of Control Change commands that form a 1720 parameter system transaction. A canonical transaction begins 1721 with two Control Change commands to set the parameter number 1722 (controller numbers 99 and 98 for NRPNs, controller numbers 101 1723 and 100 for RPNs). The transaction continues with an arbitrary 1724 number of Data Entry (controller numbers 6 and 38), Data Increment 1725 (controller number 96), and Data Decrement (controller number 1726 97) Control Change commands to set the parameter value. The 1727 transaction ends with a second pair of (99, 98) or (101, 100) 1728 Control Change commands that specify the null parameter (MSB 1729 value 0x7F, LSB value 0x7F). 1731 Several variants of the canonical transaction sequence are 1732 possible. Most commonly, the terminal pair of (99, 98) or 1733 (101, 100) Control Change commands may specify a parameter 1734 other than the null parameter. In this case, the command 1735 pair terminates the first transaction and starts a second 1736 transaction. The command pair is considered to be a part 1737 both transactions. This variant is legal and recommended 1738 in [MIDI]. We refer to this variant as a "type 1 variant". 1740 Less commonly, the MSB (99 or 101) or LSB (98 or 100) command 1741 of a (99, 98) or (101, 100) Control Change pair may be omitted. 1743 If the MSB command is omitted, the transaction uses the MSB value 1744 of the most recent C-active Control Change command for controller 1745 number 99 or 101 that appears in the session history. We refer to 1746 this variant as a "type 2 variant". 1748 If the LSB command is omitted, the LSB value 0x00 is assumed. We 1749 refer to this variant as a "type 3 variant". The type 2 and type 3 1750 variants are defined as legal, but are not recommended, in [MIDI]. 1752 System real-time commands may appear at any point during 1753 a transaction (even between octets of individual commands 1754 in the transaction). More generally, [MIDI] does not forbid 1755 the appearance of unrelated MIDI commands during an open 1756 transaction. As a rule, these commands are considered to 1757 be "outside" the transaction, and do not effect the status 1758 of the transaction in any way. Exceptions to this rule are 1759 commands whose semantics act to terminate transactions: 1760 Reset State commands, and Control Change (0xB) for controller 1761 number 121 (Reset All Controllers) [RP015]. 1763 o Initiated parameter system transaction. A canonical parameter 1764 system transaction whose (99, 98) or (101, 100) initial Control 1765 Change command pair appears in the session history is considered 1766 to be an initiated parameter system transaction. This definition 1767 also holds for type 1 variants. For type 2 variants (dropped MSB), 1768 a transaction whose initial LSB Control Change command appears in 1769 the session history is an initiated transaction. For type 3 1770 variants (dropped LSB), a transaction is considered to be 1771 initiated if at least one transaction command follows the initial 1772 MSB (99 or 101) Control Change command in the session history. 1773 The completion of a transaction does not nullify its "initiated" 1774 status. 1776 o Session history reference counts. Several recovery journal 1777 chapters include a reference count field, which codes the 1778 total number of commands of a type that appear in the session 1779 history. Examples include the Reset and Tune Request command 1780 logs (Chapter D, Appendix B.1) and the Active Sense command 1781 (Chapter V, Appendix B.2). Upon the detection of a loss event, 1782 reference count fields let a receiver deduce if any instances of 1783 the command have been lost, by comparing the journal reference 1784 count with its own reference count. Thus, a reference count 1785 field makes sense, even for command types in which knowing the 1786 NUMBER of lost commands is irrelevant (as is true with all of 1787 the example commands mentioned above). 1789 The chapter definitions in Appendices A.2-9 and B.1-5 reflect the 1790 default recovery journal behavior. The ch_default, ch_never, and 1791 ch_anchor parameters modify these definitions, as described in Appendix 1792 C.2.3. 1794 The chapter definitions specify if data MUST be present in the journal. 1795 Senders MAY also include non-required data in the journal. This 1796 optional data MUST comply with the normative chapter definition. For 1797 example, if a chapter definition states that a field codes data from the 1798 most recent active command in the session history, the sender MUST NOT 1799 code inactive commands or older commands in the field. 1801 Finally, we note that a channel journal only encodes information about 1802 MIDI commands appearing on the MIDI channel the journal protects. All 1803 references to MIDI commands in Appendices A.2-9 should be read as "MIDI 1804 commands appearing on this channel." 1805 A.2 Chapter P: MIDI Program Change 1807 A channel journal MUST contain Chapter P if an active Program Change 1808 (0xC) command appears in the checkpoint history. Figure A.2.1 shows the 1809 format for Chapter P. 1811 0 1 2 1812 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 1813 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1814 |S| PROGRAM |B| BANK-MSB |X| BANK-LSB | 1815 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1817 Figure A.2.1 -- Chapter P format 1819 The chapter has a fixed size of 24 bits. The PROGRAM field indicates 1820 the data value of the most recent active Program Change command in the 1821 session history. By default, the B, BANK-MSB, X, and BANK-LSB fields 1822 MUST be set to 0. Below, we define exceptions to this default 1823 condition. 1825 If an active Control Change (0xB) command for controller number 0 (Bank 1826 Select MSB) appears before the Program Change command in the session 1827 history, the B bit MUST be set to 1, and the BANK-MSB field MUST code 1828 the data value of the Control Change command. 1830 If B is set to 1, the BANK-LSB field MUST code the data value of the 1831 most recent Control Change command for controller number 32 (Bank Select 1832 LSB) that preceded the Program Change command coded in the PROGRAM field 1833 and followed the Control Change command coded in the BANK-MSB field. If 1834 no such Control Change command exists, the BANK-LSB field MUST be set to 1835 0. 1837 If B is set to 1, and if a Control Change command for controller number 1838 121 (Reset All Controllers) appears in the MIDI stream between the 1839 Control Change command coded by the BANK-MSB field and the Program 1840 Change command coded by the PROGRAM field, the X bit MUST be set to 1. 1842 Note that [RP015] specifies that Reset All Controllers does not reset 1843 the values of of controller numbers 0 (Bank Select MSB) and 32 (Bank 1844 Select LSB). Thus, the X bit does not effect how receivers will use the 1845 BANK-LSB and BANK-MSB values when recovering from a lost Program Change 1846 command. The X bit serves to aid recovery in MIDI applications where 1847 controller numbers 0 and 32 are used in a non-standard way. 1849 A.3 Chapter C: MIDI Control Change 1851 Figure A.3.1 shows the format for Chapter C. 1853 0 1 2 3 1854 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 1855 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1856 |S| LEN |S| NUMBER |A| VALUE/ALT |S| NUMBER | 1857 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1858 |A| VALUE/ALT | .... | 1859 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1861 Figure A.3.1 -- Chapter C format 1863 The chapter consists of a 1-octet header, followed by a variable length 1864 list of 2-octet controller logs. The list MUST contain at least one 1865 controller log. The 7-bit LEN field codes the number of controller logs 1866 in the list, minus one. We define the semantics of the controller log 1867 fields in Appendix A.3.2. 1869 A channel journal MUST contain Chapter C if the rules defined in this 1870 Appendix require that one or more controller logs appear in the list. 1872 A.3.1 Log Inclusion Rules 1874 A controller log encodes information about a particular Control Change 1875 command in the session history. 1877 In the default use of the payload format, list logs MUST encode 1878 information about the most recent active command in the session history 1879 for a controller number. Logs encoding earlier commands MUST NOT appear 1880 in the list. 1882 Also, as a rule, the list MUST contain a log for the most recent active 1883 command for a controller number that appears in the checkpoint history. 1884 Below, we define exceptions to this rule: 1886 o MIDI streams may transmit 14-bit controller values using paired 1887 Most Significant Byte (MSB, controller numbers 0-31, 99, 101) and 1888 Least Significant Byte (LSB, controller numbers 32-63, 98, 100) 1889 Control Change commands [MIDI]. 1891 If the most recent active Control Change command in the session 1892 history for a 14-bit controller pair uses the MSB number, Chapter 1893 C MAY omit the controller log for most recent active Control Change 1894 command for the associated LSB number, as the command ordering 1895 makes this LSB value irrelevant. However, this exception MUST NOT 1896 be applied if the sender is not certain that the MIDI source uses 1897 14-bit semantics for the controller number pair. Note that some 1898 MIDI sources ignore 14-bit controller semantics, and use the LSB 1899 controller numbers as independent 7-bit controllers. 1901 o If active Control Change commands for controller numbers 0 (Bank 1902 Select MSB) or 32 (Bank Select LSB) appear in the checkpoint 1903 history, and if the command instances are also coded in the 1904 BANK-MSB and BANK-LSB fields of the Chapter P (Appendix A.2), 1905 Chapter C MAY omit the controller logs for the commands. 1907 o Several controller numbers pairs are defined to be mutually 1908 exclusive. Controller numbers 124 (Omni Off) and 125 (Omni On) 1909 form a mutually exclusive pair, as do controller numbers 126 1910 (Mono) and 127 (Poly). 1912 If active Control Change commands for one or both members of 1913 a mutually exclusive pair appear in the checkpoint history, a 1914 log for the controller number of the most recent command for the 1915 pair in the checkpoint history MUST appear in the controller list. 1916 However, the list MAY omit the controller log for the most recent 1917 active command for the other number in the pair. 1919 If active Control Change commands for one or both members of a 1920 mutually exclusive pair appear in the session history, and a log 1921 for the controller number of the most recent command for the pair 1922 does not appear in the controller list, a log for the most recent 1923 command for the other number of the pair MUST NOT appear in the 1924 controller list. 1926 o If an active Control Change command for controller number 121 1927 (Reset All Controllers) appears in the session history, the 1928 controller list MAY omit logs for Control Change commands that 1929 precede the Reset All Controllers command in the session history, 1930 under certain conditions. 1932 Namely, a log MAY be omitted if the sender is certain that 1933 command stream follows the Reset All Controllers semantics 1934 defined in [RP015], and if the log codes a controller number 1935 for which [RP015] specifies a reset value. 1937 For example, [RP015] specifies that controller number 1 1938 (Modulation Wheel) is reset to the value 0, and thus 1939 a controller log for Modulation Wheel MAY be omitted 1940 from the controller log list. In contrast, [RP015] specifies 1941 that controller number 7 (Channel Volume) is not reset, 1942 and thus a controller log for Channel Volume MUST NOT 1943 be omitted from the controller log list. 1945 o Appendix A.3.4 defines exception rules for the MIDI Parameter 1946 System controller numbers 6, 38, and 96-101. 1948 A.3.2 Controller Log Format 1950 Figure A.3.2 shows the controller log structure of Chapter C. 1952 0 1 1953 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1954 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1955 |S| NUMBER |A| VALUE/ALT | 1956 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1958 Figure A.3.2 -- Chapter C controller log 1960 The 7-bit NUMBER field identifies the controller number of the coded 1961 command. The 7-bit VALUE/ALT field codes recovery information for the 1962 command. The A bit sets the format of the VALUE/ALT field. 1964 A log encodes recovery information using one of the following tools: the 1965 value tool, the toggle tool, or the count tool. 1967 A log uses the value tool if the A bit is set to 0. The value tool 1968 codes the 7-bit data value of a command in the VALUE/ALT field. The 1969 value tool works best for controllers that code a continuous quantity, 1970 such as number 1 (Modulation Wheel). 1972 The A bit is set to 1 to code the toggle or count tool. These tools 1973 work best for controllers that code discrete actions. Figure A.3.3 1974 shows the controller log for these tools. 1976 0 1 1977 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1978 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1979 |S| NUMBER |1|T| ALT | 1980 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1982 Figure A.3.3 -- Controller log for ALT tools 1984 A log uses the toggle tool if the T bit is set to 0. A log uses the 1985 count tool if the T bit is set to 1. Both methods use the 6-bit ALT 1986 field as an unsigned integer. 1988 The toggle tool works best for controllers that act as on/off switches, 1989 such as 64 (Damper Pedal (Sustain)). These controllers code the "off" 1990 state with control values 0-63 and the "on" state with 64-127. 1992 For the toggle tool, the ALT field codes the total number of toggles 1993 (off->on and on->off) due to Control Change commands in the session 1994 history, up to and including a toggle caused by the command coded by the 1995 log. The toggle count includes toggles caused by Control Change 1996 commands for controller number 121 (Reset All Controllers). 1998 Toggle counting is performed modulo 64. The toggle count is reset at 1999 the start of a session, and whenever a Reset State command (Appendix 2000 A.1) appears in the session history. When these reset events occur, the 2001 toggle count for a controller is set to 0 (for controllers whose default 2002 value is 0-63) or 1 (for controllers whose default value is 64-127). 2004 The Damper Pedal (Sustain) controller illustrates the benefits of the 2005 toggle tool over the value tool for switch controllers. As often used 2006 in piano applications, the "on" state of the controller lets notes 2007 resonate, while the "off" state immediately damps notes to silence. The 2008 loss of the "off" command in an "on->off->on" sequence results in 2009 ringing notes that should have been damped silent. The toggle tool lets 2010 receivers detect this lost "off" command but the value tool does not. 2012 The count tool conceptually similar to the toggle tool. For the count 2013 tool, the ALT field codes the total number of Control Change commands in 2014 the session history, up to and including the command coded by the log. 2015 Command counting is performed modulo 64. The command count is set to 0 2016 at the start of the session, and is reset to 0 whenever a Reset State 2017 command (Appendix A.1) appears in the session history. 2019 Because the count tool ignores the data value, it is a good match for 2020 controllers whose controller value is ignored, such as number 123 (All 2021 Notes Off). More generally, the count tool may be used to code a 2022 (modulo 64) identification number for a command. 2024 A.3.3 Log List Coding Rules 2026 In this section, we describe the organization of controller logs in the 2027 Chapter C log list. 2029 A log encodes information about a particular Control Change command in 2030 the session history. In most cases, a command SHOULD be coded by a 2031 single tool (and thus, a single log). If a number is coded with a 2032 single tool, and this tool is the count tool, recovery Control Change 2033 commands generated by a receiver SHOULD use the default control value 2034 for the controller. 2036 However, a command MAY be coded by several tool types (and thus, several 2037 logs, each using a different tool). This technique may improve recovery 2038 performance for controllers with complex semantics, such as controller 2039 number 84 (Portamento Control), or controller number 121 (Reset All 2040 Controllers) when used with a non-zero data octet (with the semantics 2041 described in [DLS2]). 2043 If a command is encoded by multiple tools, the logs MUST be placed in 2044 the list in the following order: count tool log (if any), followed by 2045 value tool log (if any), followed by toggle tool log (if any). 2047 The Chapter C log list MUST obey the oldest-first ordering rule (defined 2048 in Appendix A.1). Note that this ordering preserves the information 2049 necessary for the recovery of 14-bit controller values, without 2050 precluding the use of MSB and LSB controller pairs as independent 7-bit 2051 controllers. 2053 In the default use of the payload format, all logs that appear in the 2054 list for a controller number encode information about one Control Change 2055 command -- namely, the most recent active Control Change command in the 2056 session history for the number. 2058 This coding scheme provides good recovery performance for the standard 2059 uses of Control Change commands defined in [MIDI]. However, not all 2060 MIDI applications restrict the use of Control Change commands to those 2061 defined in [MIDI]. 2063 For example, consider the common MIDI encoding of rotary encoders 2064 ("infinite" rotation knobs). The mixing console MIDI convention defined 2065 in [LCP] codes the position of rotary encoders as a series of Control 2066 Change commands. Each command encodes a relative change of knob 2067 position from the last update (expressed as a clockwise or counter- 2068 clockwise knob turning angle). 2070 As the knob position is encoded incrementally over a series of Control 2071 Change commands, the best recovery performance is obtained if the log 2072 list encodes all Control Change commands for encoder controller numbers 2073 that appear in the checkpoint history, not only the most recent command. 2075 To support application areas that use Control Change commands in this 2076 way, Chapter C may be configured to encode information about several 2077 Control Change commands for a controller number. We use the term 2078 "enhanced" to describe this encoding method, which we describe below. 2080 In Appendix C.2.3, we show how to configure a stream to use enhanced 2081 Chapter C encoding for specific controller numbers. In Section 5 in the 2082 main text, we show how the H bits in the recovery journal header (Figure 2083 8) and in the channel journal header (Figure 9) indicate the use of 2084 enhanced Chapter C encoding. 2086 Here, we define how to encode a Chapter C log list that uses the 2087 enhanced encoding method. 2089 Senders that use the enhanced encoding method for a controller number 2090 MUST obey the rules below. These rules let a receiver determine which 2091 logs in the list correspond to lost commands. Note that these rules 2092 override the exceptions listed in Appendix A.3.1. 2094 o If N commands for a controller number are encoded in the list, 2095 the commands MUST be the N most recent commands for the controller 2096 number in the session history. For example, for N = 2, the sender 2097 MUST encode the most recent command and the second most recent 2098 command, not the most recent command and the third most recent 2099 command. 2101 o If a controller number uses enhanced encoding, the encoding 2102 of the least-recent command for the controller number in the 2103 log list MUST include a count tool log. In addition, if 2104 commands are encoded for the controller number whose logs 2105 have S bits set to 0, the encoding of the least-recent 2106 command with S = 0 logs MUST include a count tool log. 2108 The count tool is OPTIONAL for the other commands for the 2109 controller number encoded in the list, as a receiver is 2110 able to efficiently deduce the count tool value for these 2111 commands, for both single-packet and multi-packet loss events. 2113 o The use of the value and toggle tools MUST be identical for all 2114 commands for a controller number encoded in the list. For 2115 example, a value tool log either MUST appear for all commands 2116 for the controller number coded in the list, or alternatively, 2117 value tool logs for the controller number MUST NOT appear in 2118 the list. Likewise, a toggle tool log either MUST appear for 2119 all commands for the controller number coded in the list, or 2120 alternatively, toggle tool logs for the controller number MUST 2121 NOT appear in the list. 2123 o If a command is encoded by multiple tools, the logs MUST be 2124 placed in the list in the following order: count tool log 2125 (if any), followed by value tool log (if any), followed by 2126 toggle tool log (if any). 2128 These rules permit a receiver recovering from a packet loss to use the 2129 count tool log to match the commands encoded in the list with its own 2130 history of the stream, as we describe below. Note that the text below 2131 describes a non-normative algorithm; receivers are free to use any 2132 algorithm to match its history with the log list. 2134 In a typical implementation of the enhanced encoding method, a receiver 2135 computes and stores count, value, and toggle tool data field values for 2136 the most recent Control Change command it has received for a controller 2137 number. 2139 After a loss event, a receiver parses the Chapter C list, and processes 2140 list logs for a controller number that uses enhanced encoding as 2141 follows. 2143 The receiver compares the count tool ALT field for the least-recent 2144 command for the controller number in the list against its stored count 2145 data for the controller number, to determine if recovery is necessary 2146 for the command coded in the list. The value and toggle tool logs (if 2147 any) that directly follow the count tool log are associated with this 2148 least-recent command. 2150 To check more-recent commands for the controller, the receiver detects 2151 additional value and/or toggle tool logs for the controller number in 2152 the list, and infers count tool data for the command coded by these 2153 log(s). This inferred data is used to determine if recovery is 2154 necessary for the command coded by the value and/or toggle tool logs. 2156 In this way, a receiver is able to execute only lost commands, without 2157 executing a command twice. While recovering from a single packet loss, 2158 a receiver may skip through S = 1 logs in the list, as the first S = 0 2159 log for an enhanced controller number is always a count tool log. 2161 Note that the requirements in Appendix C.2.2.2 for protective sender and 2162 receiver actions during session startup for multicast operation are of 2163 particular importance for enhanced encoding, as receivers need to 2164 initialize its count tool data structures with recovery journal data in 2165 order to match commands correctly after a loss event. 2167 Finally, we note in passing that in some applications of rotary 2168 encoders, a good user experience may be possible without the use of 2169 enhanced encoding. These applications are distinguished by visual 2170 feedback of encoding position that is driven by the post-recovery rotary 2171 encoding stream, and relatively low packet loss. In these domains, 2172 recovery performance may be acceptable for rotary encoders if the log 2173 list encodes only the most recent command, if both count and value logs 2174 appear for the command. 2176 A.3.4 The Parameter System 2178 Readers may wish to review the Appendix A.1 definitions of "parameter 2179 system", "parameter system transaction", and "initiated parameter system 2180 transaction" before reading this section. 2182 Parameter system transactions update a MIDI Registered Parameter Number 2183 (RPN) or Non-Registered Parameter Number (NRPN) value. A parameter 2184 system transaction is a sequence of Control Change commands that may use 2185 the following controllers numbers: 2187 o Data Entry MSB (6) 2188 o Data Entry LSB (38) 2189 o Data Increment (96) 2190 o Data Decrement (97) 2191 o Non-Registered Parameter Number (NRPN) LSB (98) 2192 o Non-Registered Parameter Number (NRPN) MSB (99) 2193 o Registered Parameter Number (RPN) LSB (100) 2194 o Registered Parameter Number (RPN) MSB (101) 2196 Control Change commands that are a part of a parameter system 2197 transaction MUST NOT be coded in Chapter C controller logs. Instead, 2198 these commands are coded in Chapter M, the MIDI Parameter chapter 2199 defined in Appendix A.4. 2201 However, Control Change commands that use the listed controllers as 2202 general-purpose controllers (i.e. outside of a parameter system 2203 transaction) MUST NOT be coded in Chapter M. 2205 Instead, the controllers are coded in Chapter C controller logs. The 2206 controller logs follow the coding rules stated in Appendix A.3.2 and 2207 A.3.3. The rules for coding paired LSB and MSB controllers, as defined 2208 in Appendix A.3.1, apply to the pairs (6, 38), (99, 98), and (101, 100) 2209 when coded in Chapter C. 2211 If active Control Change commands for controller numbers 6, 38, or 2212 96-101 appear in the checkpoint history, and these commands are used as 2213 general-purpose controllers, the most recent general-purpose command 2214 instance for these controller numbers MUST appear as entries in the 2215 Chapter C controller list. 2217 MIDI syntax permits a source to use controllers 6, 38, 96, and 97 as 2218 parameter-system controllers and general-purpose controllers in the same 2219 stream. An RTP MIDI sender MUST deduce the role of each Control Change 2220 command for these controller numbers by noting the placement of the 2221 command in the stream, and MUST use this information to code the command 2222 in Chapter C or Chapter M as appropriate. 2224 Specifically, active Control Change commands for controllers 6, 38, 96, 2225 and 97 act in a general-purpose way when 2227 o No active Control Change commands that set an RPN or 2228 NRPN parameter number appear in the session history, or 2230 o The most recent active Control Change commands in the session 2231 history that set an RPN or NRPN parameter number code the null 2232 parameter (MSB value 0x7F, LSB value 0x7F), or 2234 o A Control Change command for controller number 121 (Reset 2235 All Controllers) appears more recently in the session history 2236 than all active Control Change commands that set an RPN or 2237 NRPN parameter number (see [RP015] for details). 2239 Finally, we note that a MIDI source that follows the recommendations of 2240 [MIDI] exclusively uses numbers 98-101 as parameter system controllers. 2241 Alternatively, a MIDI source may exclusively use 98-101 as general- 2242 purpose controllers, and lose the ability perform parameter system 2243 transactions in a stream. 2245 In the language of [MIDI], the general-purpose use of controllers 98-101 2246 constitutes a non-standard controller assignment. As most real-world 2247 MIDI sources use the standard controller assignment for controller 2248 numbers 98-101, an RTP MIDI sender SHOULD assume these controllers act 2249 as parameter system controllers unless it knows that a MIDI source uses 2250 controller numbers 98-101 in a general-purpose way. 2252 A.4 Chapter M: MIDI Parameter System 2254 Readers may wish to review the Appendix A.1 definitions for "C-active", 2255 "parameter system", "parameter system transaction", and "initiated 2256 parameter system transaction" before reading this Appendix. 2258 Chapter M protects parameter system transactions for Registered 2259 Parameter Number (RPN) and Non-Registered Parameter Number (NRPN) 2260 values. Figure A.4.1 shows the format for Chapter M. 2262 0 1 2 3 2263 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 2264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2265 |S|P|E|U|W|Z| LENGTH |Q| PENDING | Log list ... | 2266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2268 Figure A.4.1 -- Top-level Chapter M format 2270 Chapter M begins with a 2-octet header. If the P header bit is set to 2271 1, a 1-octet field follows the header, coding the 7-bit PENDING value 2272 and its associated Q bit. 2274 The 10-bit LENGTH field codes the size of Chapter M, and conforms to 2275 semantics described in Appendix A.1. 2277 Chapter M ends with a list of zero or more variable-length parameter 2278 logs. Appendix A.4.2 defines the bitfield format of a parameter log. 2279 Appendix A.4.1 defines the inclusion semantics of the log list. 2281 A channel journal MUST contain Chapter M if the rules defined in 2282 Appendix A.4.1 require that one or more parameter logs appear in the 2283 list. 2285 A channel journal also MUST contain Chapter M if the most recent C- 2286 active Control Change command involved in a parameter system transaction 2287 in the checkpoint history is: 2289 o an RPN MSB (101) or NRPN MSB (99) controller, or 2291 o an RPN LSB (100) or NRPN LSB (98) controller that completes the 2292 coding of the null parameter (MSB value 0x7F, LSB value 0x7F). 2294 This rule provides loss protection for partially-transmitted parameter 2295 numbers and for the null parameter numbers. 2297 If the most recent C-active Control Change command involved in a 2298 parameter system transaction in the session history is for the RPN MSB 2299 or NRPN MSB controller, the P header bit MUST be set to 1, and the 2300 PENDING field (and its associated Q bit) MUST follow the Chapter M 2301 header. Otherwise, the P header bit MUST be set to 0, and the PENDING 2302 field and Q bit MUST NOT appear in Chapter M. 2304 If PENDING codes an NRPN MSB, the Q bit MUST be set to 1. If PENDING 2305 codes an RPN MSB, the Q bit MUST be set to 0. 2307 The E header bit codes the current transaction state of the MIDI stream. 2308 If E = 1, an initiated transaction is in progress. Below, we define the 2309 rules for setting the E header bit: 2311 o If no C-active parameter system transaction Control Change 2312 commands appear in the session history, the E bit MUST be 2313 set to 0. 2315 o If the P header bit is set to 1, the E bit MUST be set to 0. 2317 o If the most recent C-active parameter system transaction 2318 Control Change command in the session history is for the 2319 NRPN LSB or RPN LSB controller number, and this command 2320 acts to complete the coding of the null parameter (MSB 2321 value 0x7F, LSB value 0x7F), the E bit MUST be set to 0. 2323 o Otherwise, an initiated transaction is in progress, and the 2324 E bit MUST be set to 1. 2326 The U, W, and Z header bits code properties that are shared by all 2327 parameter logs in the list. If these properties are set, parameter logs 2328 may be coded with improved efficiency (we explain how in A.4.1). 2330 By default, the U, W, and Z bits MUST be set to 0. If all parameter 2331 logs in the list code RPN parameters, the U bit MAY be set to 1. If all 2332 parameter logs in the list code NRPN parameters, the W bit MAY be set to 2333 1. If the parameter numbers of all RPN and NRPN logs in the list lie in 2334 the range 0-127 (and thus have an MSB value of 0), the Z bit MAY be set 2335 to 1. 2337 Note that C-active semantics appear in the preceding paragraphs because 2338 [RP015] specifies that pending Parameter System transactions are closed 2339 by a Control Change command for controller number 121 (Reset All 2340 Controllers). 2342 A.4.1 Log Inclusion Rules 2344 Parameter logs code recovery information for a specific RPN or NRPN 2345 parameter. 2347 A parameter log MUST appear in the list if an active Control Change 2348 command that forms a part of an initiated transaction for the parameter 2349 appears in the checkpoint history. 2351 An exception to this rule applies if the checkpoint history only 2352 contains transaction Control Change commands for controller numbers 2353 98-101 that act to terminate the transaction. In this case, a log for 2354 the parameter MAY be omitted from the list. 2356 A log MAY appear in the list if an active Control Change command that 2357 forms a part of an initiated transaction for the parameter appears in 2358 the session history. Otherwise, a log for the parameter MUST NOT appear 2359 in the list. 2361 Multiple logs for the same RPN or NRPN parameter MUST NOT appear in the 2362 log list. 2364 The parameter log list MUST obey the oldest-first ordering rule (defined 2365 in Appendix A.1), with the phrase "parameter transaction" replacing the 2366 word "command" in the rule definition. 2368 Parameter logs associated with the RPN or NRPN null parameter (LSB = 2369 0x7F, MSB = 0x7F) MUST NOT appear in the log list. Chapter M uses the E 2370 header bit (Figure A.4.1) and the log list ordering rules to code null 2371 parameter semantics. 2373 Note that "active" semantics (rather than "C-active" semantics) appear 2374 in the preceding paragraphs because [RP015] specifies that pending 2375 Parameter System transactions are not reset by a Control Change command 2376 for controller number 121 (Reset All Controllers). However, the rule 2377 that follows uses C-active semantics, because it concerns the protection 2378 of the transaction system itself, and [RP015] specifies that Reset All 2379 Controllers acts to close a transaction in progress. 2381 In most cases, parameter logs for RPN and NRPN parameters that are 2382 assigned to the ch_never parameter (Appendix C.2.3) MAY be omitted from 2383 the list. An exception applies if: 2385 o The log codes the most recent initiated transaction 2386 in the session history, and 2388 o A C-active command that forms a part of the transaction 2389 appears in the checkpoint history, and 2391 o The E header bit for the top-level Chapter M header (Figure 2392 A.4.1) is set to 1. 2394 In this case, a log for the parameter MUST appear in the list. This log 2395 informs receivers recovering from a loss that a transaction is in 2396 progress, so that the receiver is able to correctly interpret RPN or 2397 NRPN Control Change commands that follow the loss event. 2399 A.4.2 Log Coding Rules 2401 Figure A.4.2 shows the parameter log structure of Chapter M. 2403 0 1 2 3 2404 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 2405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2406 |S| PNUM-LSB |Q| PNUM-MSB |J|K|L|M|N|T|V|R| Fields ... | 2407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2409 Figure A.4.2 -- Parameter log format 2411 The log begins with a header, whose default size (as shown in Figure 2412 A.4.2) is 3 octets. If the Q header bit is set to 0, the log encodes an 2413 RPN parameter. If Q = 1, the log encodes an NRPN parameter. The 7-bit 2414 PNUM-MSB and PNUM-LSB fields code the parameter number, and reflect the 2415 Control Change command data values for controllers 99 and 98 (for NRPNs) 2416 or 101 and 100 (for RPNs). 2418 The J, K, L, M, and N header bits form a Table of Contents (TOC) for the 2419 log, and signal the presence of fixed-sized fields that follow the 2420 header. A header bit that is set to 1 codes the presence of a field in 2421 the log. The ordering of fields in the log follows the ordering of the 2422 header bits in the TOC. Appendices A.4.2.1-2 define the fields 2423 associated with each TOC header bit. 2425 The T and V header bits code information about the parameter log, but 2426 are not part of the TOC. A set T or V bit does not signal the presence 2427 of any parameter log field. 2429 If the rules in Appendix A.4.1 state that a log for a given parameter 2430 MUST appear in Chapter M, the log MUST code sufficient information to 2431 protect the parameter from the loss of active parameter transaction 2432 Control Change commands in the checkpoint history. 2434 This rule does not apply if the parameter coded by the log is assigned 2435 to the ch_never parameter (Appendix C.2.3). In this case, senders MAY 2436 choose to set the J, K, L, M, and N TOC bits to 0, coding a parameter 2437 log with no fields. 2439 Note that logs to protect parameters that are assigned to ch_never are 2440 REQUIRED under certain conditions (see Appendix A.4.1). The purpose of 2441 the log is to inform receivers recovering from a loss that a transaction 2442 is in progress, so that the receiver is able to correctly interpret RPN 2443 or NRPN Control Change commands that follow the loss event. 2445 Parameter logs provide two tools for parameter protection: the value 2446 tool and the count tool. Depending on the semantics of the parameter, 2447 senders may use either tool, both tools, or neither tool to protect a 2448 given parameter. 2450 The value tool codes information a receiver may use to determine the 2451 current value of an RPN or NRPN parameter. If a parameter log uses the 2452 value tool, the V header bit MUST be set to 1, and the semantics defined 2453 in Appendices A.4.2.1 for setting the J, K, L, and M TOC bits MUST be 2454 followed. If a parameter log does not use the value tool, the V bit 2455 MUST be set to 0, and the J, K, L, and M TOC bits MUST also be set to 0. 2457 The count tool codes the number of transactions for an RPN or NRPN 2458 parameter. If a parameter log uses the count tool, the T header bit 2459 MUST be set to 1, and the semantics defined in Appendices A.4.2.2 for 2460 setting the N TOC bit MUST be followed. If a parameter log does not use 2461 the count tool, the T bit and the N TOC bit MUST be set to 0. 2463 Note that V and T are set if the sender uses value (V) or count (T) tool 2464 for the log on an ongoing basis. Thus, V may be set even if J = K = L = 2465 M = 0, and T may be set even if N = 0. 2467 In many cases, all parameters coded in the log list are of one type (RPN 2468 and NRPN), and all parameter numbers lie in the range 0-127. As 2469 described in Appendix A.4.1, senders MAY signal this condition by 2470 setting the top-level Chapter M header bit Z to 1 (to code the 2471 restricted range) and by setting the U or W bit to 1 (to code the 2472 parameter type). 2474 If the top-level Chapter M header codes Z = 1 and either U = 1 or W = 1, 2475 all logs in the parameter log list MUST use a modified header format. 2476 This modification deletes bits 8-15 of the bitfield shown in Figure 2477 A.4.2, to yield a 2-octet header. The values of the deleted PNUM-MSB 2478 and Q fields may be inferred from the U, W, and Z bit values. 2480 A.4.2.1 The Value Tool 2482 The value tool uses several fields to track the value of an RPN or NRPN 2483 parameter. 2485 The J TOC bit codes the presence of the octet shown in Figure A.4.3 in 2486 the field list. 2488 0 2489 0 1 2 3 4 5 6 7 2490 +-+-+-+-+-+-+-+-+ 2491 |X| ENTRY-MSB | 2492 +-+-+-+-+-+-+-+-+ 2494 Figure A.4.3 -- ENTRY-MSB field 2496 The 7-bit ENTRY-MSB field codes the data value of the most recent active 2497 Control Change command for controller number 6 (Data Entry MSB) in the 2498 session history that appears in a transaction for the log parameter. 2500 The X bit MUST be set to 1 if the command coded by ENTRY-MSB precedes 2501 the most recent Control Change command for controller 121 (Reset All 2502 Controllers) in the session history. Otherwise, the X bit MUST be set 2503 to 0. 2505 A parameter log that uses the value tool MUST include the ENTRY-MSB 2506 field if an active Control Change command for controller number 6 2507 appears in the checkpoint history. 2509 Note that [RP015] specifies that Control Change commands for controller 2510 121 (Reset All Controllers) do not reset RPN and NRPN values, and thus 2511 the X bit would not play a recovery role for MIDI systems that comply 2512 with [RP015]. 2514 However, certain renderers (such as DLS 2 [DLS2]) specify that certain 2515 RPN values are reset for some uses of Reset All Controllers. The X bit 2516 (and other bitfield features of this nature in this Appendix) plays a 2517 role in recovery for renderers of this type. 2519 The K TOC bit codes the presence of the octet shown in Figure A.4.4 in 2520 the field list. 2522 0 2523 0 1 2 3 4 5 6 7 2524 +-+-+-+-+-+-+-+-+ 2525 |X| ENTRY-LSB | 2526 +-+-+-+-+-+-+-+-+ 2528 Figure A.4.4 -- ENTRY-LSB field 2530 The 7-bit ENTRY-LSB field codes the data value of the most recent active 2531 Control Change command for controller number 38 (Data Entry LSB) in the 2532 session history that appears in a transaction for the log parameter. 2534 The X bit MUST be set to 1 if the command coded by ENTRY-LSB precedes 2535 the most recent Control Change command for controller 121 (Reset All 2536 Controllers) in the session history. Otherwise, the X bit MUST be set 2537 to 0. 2539 As a rule, a parameter log that uses the value tool MUST include the 2540 ENTRY-LSB field if an active Control Change command for controller 2541 number 38 appears in the checkpoint history. However, the ENTRY-LSB 2542 field MUST NOT appear in a parameter log if the Control Change command 2543 associated with the ENTRY-LSB precedes a Control Change command for 2544 controller number 6 (Data Entry MSB) that appears in a transaction for 2545 the log parameter in the session history. 2547 The L TOC bit codes the presence of the octets shown in Figure A.4.5 in 2548 the field list. 2550 0 1 2551 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2553 |G|X| A-BUTTON | 2554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2556 Figure A.4.5 -- A-BUTTON field 2558 The 14-bit A-BUTTON field codes a count of the number of active Control 2559 Change commands for controller numbers 96 and 97 (Data Increment and 2560 Data Decrement) in the session history that appear in a transaction for 2561 the log parameter. 2563 The M TOC bit codes the presence of the octets shown in Figure A.4.6 in 2564 the field list. 2566 0 1 2567 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2569 |G|R| C-BUTTON | 2570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2572 Figure A.4.6 -- C-BUTTON field 2574 The 14-bit C-BUTTON field has semantics identical to A-BUTTON, except 2575 that Data Increment and Data Decrement Control Change commands that 2576 precede the most recent Control Change command for controller 121 (Reset 2577 All Controllers) in the session history are not counted. 2579 For both A-BUTTON and C-BUTTON, Data Increment and Data Decrement 2580 Control Change commands are not counted if they precede Control Changes 2581 commands for controller numbers 6 (Data Entry MSB) or 38 (Data Entry 2582 LSB) that appear in a transaction for the log parameter in the session 2583 history. 2585 The A-BUTTON and C-BUTTON fields are interpreted as unsigned integers, 2586 and the G bit associated the field codes the sign of the integer (G = 0 2587 for positive or zero, G = 1 for negative). 2589 To compute and code the count value, initialize the count value to 0, 2590 add 1 for each qualifying Data Increment command, and subtract 1 for 2591 each qualifying Data Decrement command. After each add or subtract, 2592 limit the count magnitude to 16383. The G bit codes the sign of the 2593 count, and the A-BUTTON or C-BUTTON field codes the count magnitude. 2595 For the A-BUTTON field, if the most recent qualified Data Increment or 2596 Data Decrement command precedes the most recent Control Change command 2597 for controller 121 (Reset All Controllers) in the session history, the X 2598 bit associated with A-BUTTON field MUST be set to 1. Otherwise, the X 2599 bit MUST be set to 0. 2601 A parameter log that uses the value tool MUST include the A-BUTTON and 2602 C-BUTTON fields if an active Control Change command for controller 2603 numbers 96 or 97 appears in the checkpoint history. However, to improve 2604 coding efficiency, this rule has several exceptions: 2606 o If the log includes the A-BUTTON field, and if the X bit of 2607 the A-BUTTON field is set to 1, the C-BUTTON field (and its 2608 associated R and G bits) MAY be omitted from the log. 2610 o If the log includes the A-BUTTON field, and if the A-BUTTON 2611 and C-BUTTON fields (and their associated G bits) code identical 2612 values, the C-BUTTON field (and its associated R and G bits) 2613 MAY be omitted from the log. 2615 A.4.2.2 The Count Tool 2617 The count tool tracks the number of transactions for an RPN or NRPN 2618 parameter. The N TOC bit codes the presence of the octet shown in 2619 Figure A.4.7 in the field list. 2621 0 2622 0 1 2 3 4 5 6 7 2623 +-+-+-+-+-+-+-+-+ 2624 |X| COUNT | 2625 +-+-+-+-+-+-+-+-+ 2627 Figure A.4.7 -- COUNT field 2629 The 7-bit COUNT codes the number of initiated transactions for the log 2630 parameter that appear in the session history. Initiated transactions 2631 are counted if they contain one or more active Control Change commands, 2632 including commands for controllers 98-101 that initiate the parameter 2633 transaction. 2635 If the most recent counted transaction precedes the most recent Control 2636 Change command for controller 121 (Reset All Controllers) in the session 2637 history, the X bit associated with the COUNT field MUST be set to 1. 2638 Otherwise, the X bit MUST be set to 0. 2640 Transaction counting is performed modulo 128. The transaction count is 2641 set to 0 at the start of a session, and is reset to 0 whenever a Reset 2642 State command (Appendix A.1) appears in the session history. 2644 A parameter log that uses the count tool MUST include the COUNT field if 2645 an active command that increments the transaction count (modulo 128) 2646 appears in the checkpoint history. 2648 A.5 Chapter W: MIDI Pitch Wheel 2650 A channel journal MUST contain Chapter W if a C-active MIDI Pitch Wheel 2651 (0xE) command appears in the checkpoint history. Figure A.5.1 shows the 2652 format for Chapter W. 2654 0 1 2655 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2657 |S| FIRST |R| SECOND | 2658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2660 Figure A.5.1 -- Chapter W format 2662 The chapter has a fixed size of 16 bits. The FIRST and SECOND fields 2663 are the 7-bit values of the first and second data octets of the most 2664 recent active Pitch Wheel command in the session history. 2666 Note that Chapter W encodes C-active commands, and thus does not encode 2667 active commands that are not C-active (see the second-to-last paragraph 2668 of Appendix A.1 for an explanation of chapter inclusion text in this 2669 regard). 2671 Chapter W does not encode "active but not C-active" commands because 2672 [RP015] declares that Control Change commands for controller number 121 2673 (Reset All Controllers) acts to reset the Pitch Wheel value to 0. If 2674 Chapter W encoded "active but not C-active" commands, a repair operation 2675 following a Reset All Controllers command could incorrectly repair the 2676 stream with a stale Pitch Wheel value. 2678 A.6 Chapter N: MIDI NoteOff and NoteOn 2680 In this Appendix, we consider NoteOn commands with zero velocity to be 2681 NoteOff commands. Readers may wish to review the Appendix A.1 2682 definition of "N-active commands" before reading this Appendix. 2684 Chapter N completely protects note commands in streams that alternate 2685 between NoteOn and NoteOff commands for a particular note number. 2686 However, in rare applications, multiple overlapping NoteOn commands may 2687 appear for a note number. Chapter E, described in Appendix A.7, 2688 augments Chapter N to completely protect these streams. 2690 A channel journal MUST contain Chapter N if an N-active MIDI NoteOn 2691 (0x9) or NoteOff (0x8) command appears in the checkpoint history. 2692 Figure A.6.1 shows the format for Chapter N. 2694 0 1 2 3 2695 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 2696 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2697 |B| LEN | LOW | HIGH |S| NOTENUM |Y| VELOCITY | 2698 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2699 |S| NOTENUM |Y| VELOCITY | .... | 2700 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2701 | OFFBITS | OFFBITS | .... | OFFBITS | 2702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2704 Figure A.6.1 -- Chapter N format 2706 Chapter N consists of a 2-octet header, followed by at least one of the 2707 following data structures: 2709 o A list of note logs to code NoteOn commands. 2710 o A NoteOff bitfield structure to code NoteOff commands. 2712 We define the header bitfield semantics in Appendix A.6.1. We define 2713 the note log semantics and the NoteOff bitfield semantics in Appendix 2714 A.6.2. 2716 If one or more N-active NoteOn or NoteOff commands in the checkpoint 2717 history reference a note number, the note number MUST be coded in either 2718 the note log list or the NoteOff bitfield structure. 2720 The note log list MUST contain an entry for all note numbers whose most 2721 recent checkpoint history appearance is in an N-active NoteOn command. 2722 The NoteOff bitfield structure MUST contain a set bit for all note 2723 numbers whose most recent checkpoint history appearance is in an N- 2724 active NoteOff command. 2726 A note number MUST NOT be coded in both structures. 2728 All note logs and NoteOff bitfield set bits MUST code the most recent N- 2729 active NoteOn or NoteOff reference to a note number in the session 2730 history. 2732 The note log list MUST obey the oldest-first ordering rule (defined in 2733 Appendix A.1). 2735 A.6.1 Header Structure 2737 The header for Chapter N, shown in Figure A.6.2, codes the size of the 2738 note list and bitfield structures. 2740 0 1 2741 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2742 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2743 |B| LEN | LOW | HIGH | 2744 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2746 Figure A.6.2 -- Chapter N header 2748 The LEN field, a 7-bit integer value, codes the number of 2-octet note 2749 logs in the note list. Zero is a valid value for LEN, and codes an 2750 empty note list. 2752 The 4-bit LOW and HIGH fields code the number of OFFBITS octets that 2753 follow the note log list. LOW and HIGH are unsigned integer values. If 2754 LOW <= HIGH, there are (HIGH - LOW + 1) OFFBITS octets in the chapter. 2755 The value pairs (LOW = 15, HIGH = 0) and (LOW = 15, HIGH = 1) code an 2756 empty NoteOff bitfield structure (i.e. no OFFBITS octets). Other (LOW > 2757 HIGH) value pairs MUST NOT appear in the header. 2759 The B bit provides S-bit functionality (Appendix A.1) for the NoteOff 2760 bitfield structure. By default, the B bit MUST be set to 1. However, 2761 if the MIDI command section of the previous packet (packet I - 1, with I 2762 as defined in Appendix A.1) includes a NoteOff command for the channel, 2763 the B bit MUST be set to 0. If the B bit is set to 0, the higher-level 2764 recovery journal elements that contain Chapter N MUST have S bits that 2765 are set to 0, including the top-level journal header. 2767 The LEN value of 127 codes a note list length of 127 or 128 note logs, 2768 depending on the values of LOW and HIGH. If LEN = 127, LOW = 15, and 2769 HIGH = 0, the note list holds 128 note logs, and the NoteOff bitfield 2770 structure is empty. For other values of LOW and HIGH, LEN = 127 codes 2771 that the note list contains 127 note logs. In this case, the chapter 2772 has (HIGH - LOW + 1) NoteOff OFFBITS octets if LOW <= HIGH, and has no 2773 OFFBITS octets if LOW = 15 and HIGH = 1. 2775 A.6.2 Note Structures 2777 Figure A.6.3 shows the 2-octet note log structure. 2779 0 1 2780 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2781 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2782 |S| NOTENUM |Y| VELOCITY | 2783 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2785 Figure A.6.3 -- Chapter N note log 2787 The 7-bit NOTENUM field codes the note number for the log. A note 2788 number MUST NOT be represented by multiple note logs in the note list. 2790 The 7-bit VELOCITY field codes the velocity value for the most recent N- 2791 active NoteOn command for the note number in the session history. 2792 Multiple overlapping NoteOns for a given note number may be coded using 2793 Chapter E, as discussed in Appendix A.7. 2795 VELOCITY is never zero; NoteOn commands with zero velocity are coded as 2796 NoteOff commands in the NoteOff bitfield structure. 2798 The note log does not code the execution time of the NoteOn command. 2799 However, the Y bit codes a hint from the sender about the NoteOn 2800 execution time. The Y bit codes a recommendation to play (Y = 1) or 2801 skip (Y = 0) the NoteOn command recovered from the note log. See 2802 Section 4.2 of [GUIDE] for non-normative guidance on the use of the Y 2803 bit. 2805 Figure A.6.1 shows the NoteOff bitfield structure, as the list of 2806 OFFBITS octets at the end of the chapter. A NoteOff OFFBITS octet codes 2807 NoteOff information for eight consecutive MIDI note numbers, with the 2808 most-significant bit representing the lowest note number. The most- 2809 significant bit of the first OFFBITS octet codes the note number 8*LOW; 2810 the most-significant bit of the last OFFBITS octet codes the note number 2811 8*HIGH. 2813 A set bit codes a NoteOff command for the note number. In the most 2814 efficient coding for the NoteOff bitfield structure, the first and last 2815 octets of the structure contain at least one set bit. Note that Chapter 2816 N does not code NoteOff velocity data. 2818 Note that in the general case, the recovery journal does not code the 2819 relative placement of a NoteOff command and a Change Control command for 2820 controller 64 (Damper Pedal (Sustain)). In many cases, a receiver 2821 processing a loss event may deduce this relative placement from the 2822 history of the stream, and thus determine if a NoteOff note is sustained 2823 by the pedal. If such a determination is not possible, receivers SHOULD 2824 err on the side of silencing pedal sustains, as erroneously sustained 2825 notes may produce unpleasant (albeit transient) artifacts. 2827 A.7 Chapter E: MIDI Note Command Extras 2829 Readers may wish to review the Appendix A.1 definition of "N-active 2830 commands" before reading this Appendix. In this Appendix, a NoteOn 2831 command with a velocity of 0 is considered to be a NoteOff command with 2832 a release velocity value of 64. 2834 Chapter E encodes recovery information about MIDI NoteOn (0x9) and 2835 NoteOff (0x8) command features that rarely appear in MIDI streams. 2836 Receivers use Chapter E to reduce transient artifacts for streams where 2837 several NoteOn commands appear for a note number without an intervening 2838 NoteOff. Receivers also use Chapter E to reduce transient artifacts for 2839 streams that use NoteOff release velocity. Chapter E supplements the 2840 note information coded in Chapter N (Appendix A.6). 2842 Figure A.7.1 shows the format for Chapter E. 2844 0 1 2 3 2845 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 2846 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2847 |S| LEN |S| NOTENUM |V| COUNT/VEL |S| NOTENUM | 2848 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2849 |V| COUNT/VEL | .... | 2850 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2852 Figure A.7.1 -- Chapter E format 2854 The chapter consists of a 1-octet header, followed by a variable length 2855 list of 2-octet note logs. Appendix A.7.1 defines the bitfield format 2856 for a note log. 2858 The log list MUST contain at least one note log. The 7-bit LEN header 2859 field codes the number of note logs in the list, minus one. A channel 2860 journal MUST contain Chapter E if the rules defined in this Appendix 2861 require that one or more note logs appear in the list. The note log 2862 list MUST obey the oldest-first ordering rule (defined in Appendix A.1). 2864 A.7.1 Note Log Format 2866 Figure A.7.2 reproduces the note log structure of Chapter E. 2868 0 1 2869 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2870 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2871 |S| NOTENUM |V| COUNT/VEL | 2872 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2874 Figure A.7.2 -- Chapter E note log 2876 A note log codes information about the MIDI note number coded by the 2877 7-bit NOTENUM field. The nature of the information depends on the value 2878 of the V flag bit. 2880 If the V bit is set to 1, the COUNT/VEL field codes the release velocity 2881 value for the most recent N-active NoteOff command for the note number 2882 that appears in the session history. 2884 If the V bit is set to 0, the COUNT/VEL field codes a reference count of 2885 the number of NoteOn and NoteOff commands for the note number that 2886 appear in the session history. 2888 The reference count is set to 0 at the start of the session. NoteOn 2889 commands increment the count by 1. NoteOff commands decrement the count 2890 by 1. However, a decrement that generates a negative count value is not 2891 performed. 2893 If the reference count is in the range 0-126, the 7-bit COUNT/VEL field 2894 codes an unsigned integer representation of the count. If the count is 2895 greater or equal to 127, COUNT/VEL is set to 127. 2897 By default, the count is reset to 0 whenever a Reset State command 2898 (Appendix A.1) appears in the session history, and whenever MIDI Control 2899 Change commands for controller numbers 123-127 (numbers with All Notes 2900 Off semantics) or 120 (All Sound Off) appear in the session history. 2902 A.7.2 Log Inclusion Rules 2904 If the most recent N-active NoteOn or NoteOff command for a note number 2905 in the checkpoint history is a NoteOff command with a release velocity 2906 value other than 64, a note log whose V bit is set to 1 MUST appear in 2907 Chapter E for the note number. 2909 If the most recent N-active NoteOn or NoteOff command for a note number 2910 in the checkpoint history is a NoteOff command, and if the reference 2911 count for the note number is greater than 0, a note log whose V bit is 2912 set to 0 MUST appear in Chapter E for the note number. 2914 If the most recent N-active NoteOn or NoteOff command for a note number 2915 in the checkpoint history is a NoteOn command, and if the reference 2916 count for the note number is greater than 1, a note log whose V bit is 2917 set to 0 MUST appear in Chapter E for the note number. 2919 At most two note logs MAY appear in Chapter E for a note number: one log 2920 whose V bit is set to 0, and one log whose V bit is set to 1. 2922 Chapter E codes a maximum of 128 note logs. If the log inclusion rules 2923 yield more than 128 REQUIRED logs, note logs whose V bit is set to 1 2924 MUST be dropped from Chapter E in order to reach the 128-log limit. 2925 Note logs whose V bit is set to 0 MUST NOT be dropped. 2927 Most MIDI streams do not use NoteOn and NoteOff commands in ways that 2928 would trigger the log inclusion rules. For these streams, Chapter E 2929 would never be REQUIRED to appear in a channel journal. 2931 The ch_never parameter (Appendix C.2.3) may be used to configure the log 2932 inclusion rules for Chapter E. 2934 A.8 Chapter T: MIDI Channel Aftertouch 2936 A channel journal MUST contain Chapter T if an N-active and C-active 2937 MIDI Channel Aftertouch (0xD) command appears in the checkpoint history. 2938 Figure A.8.1 shows the format for Chapter T. 2940 0 2941 0 1 2 3 4 5 6 7 2942 +-+-+-+-+-+-+-+-+ 2943 |S| PRESSURE | 2944 +-+-+-+-+-+-+-+-+ 2946 Figure A.8.1 -- Chapter T format 2948 The chapter has a fixed size of 8 bits. The 7-bit PRESSURE field holds 2949 the pressure value of the most recent N-active and C-active Channel 2950 Aftertouch command in the session history. 2952 Chapter T only encodes commands that are C-active and N-active. We 2953 define a C-active restriction because [RP015] declares that a Control 2954 Change command for controller 121 (Reset All Controllers) acts to reset 2955 the channel pressure to 0 (see the discussion at the end of Appendix A.5 2956 for a more complete rationale). 2958 We define an N-active restriction on the assumption that aftertouch 2959 commands are linked to note activity, and thus Channel Aftertouch 2960 commands that are not N-active are stale and should not be used to 2961 repair a stream. 2963 A.9 Chapter A: MIDI Poly Aftertouch 2965 A channel journal MUST contain Chapter A if a C-active Poly Aftertouch 2966 (0xA) command appears in the checkpoint history. Figure A.9.1 shows the 2967 format for Chapter A. 2969 0 1 2 3 2970 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 2971 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2972 |S| LEN |S| NOTENUM |X| PRESSURE |S| NOTENUM | 2973 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2974 |X| PRESSURE | .... | 2975 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2977 Figure A.9.1 -- Chapter A format 2979 The chapter consists of a 1-octet header, followed by a variable length 2980 list of 2-octet note logs. A note log MUST appear for a note number if 2981 a C-active Poly Aftertouch command for the note number appears in the 2982 checkpoint history. A note number MUST NOT be represented by multiple 2983 note logs in the note list. The note log list MUST obey the oldest- 2984 first ordering rule (defined in Appendix A.1). 2986 The 7-bit LEN field codes the number of note logs in the list, minus 2987 one. Figure A.9.2 reproduces the note log structure of Chapter A. 2989 0 1 2990 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2991 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2992 |S| NOTENUM |X| PRESSURE | 2993 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2995 Figure A.9.2 -- Chapter A note log 2997 The 7-bit PRESSURE field codes the pressure value of the most recent C- 2998 active Poly Aftertouch command in the session history for the MIDI note 2999 number coded in the 7-bit NOTENUM field. 3001 As a rule, the X bit MUST be set to 0. However, the X bit MUST be set 3002 to 1 if the command coded by the log appears before one of the following 3003 commands in the session history: MIDI Control Change numbers 123-127 3004 (numbers with All Notes Off semantics) or 120 (All Sound Off). 3006 We define C-active restrictions for Chapter A because [RP015] declares 3007 that a Control Change command for controller 121 (Reset All Controllers) 3008 acts to reset the polyphonic pressure to 0 (see the discussion at the 3009 end of Appendix A.5 for a more complete rationale). 3011 B. The Recovery Journal System Chapters 3013 B.1 System Chapter D: Simple System Commands 3015 The system journal MUST contain Chapter D if an active MIDI Reset 3016 (0xFF), MIDI Tune Request (0xF6), MIDI Song Select (0xF3), undefined 3017 MIDI System Common (0xF4 and 0xF5), or undefined MIDI System Real-time 3018 (0xF9 and 0xFD) command appears in the checkpoint history. 3020 Figure B.1.1 shows the variable-length format for Chapter D. 3022 0 1 2 3 3023 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 3024 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3025 |S|B|G|H|J|K|Y|Z| Command logs ... | 3026 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3028 Figure B.1.1 -- System Chapter D format 3030 The chapter consists of a 1-octet header, followed by one or more 3031 command logs. Header flag bits indicate the presence of command logs 3032 for the Reset (B = 1), Tune Request (G = 1), Song Select (H = 1), 3033 undefined System Common 0xF4 (J = 1), undefined System Common 0xF5 (K = 3034 1), undefined System Real-time 0xF9 (Y = 1), or undefined System Real- 3035 time 0xFD (Z = 1) commands. 3037 Command logs appear in a list following the header, in the order that 3038 the flag bits appear in the header. 3040 Figure B.1.2 shows the 1-octet command log format for the Reset and Tune 3041 Request commands. 3043 0 3044 0 1 2 3 4 5 6 7 3045 +-+-+-+-+-+-+-+-+ 3046 |S| COUNT | 3047 +-+-+-+-+-+-+-+-+ 3049 Figure B.1.2 -- Command log for Reset and Tune Request 3051 Chapter D MUST contain the Reset command log if an active Reset command 3052 appears in the checkpoint history. The 7-bit COUNT field codes the 3053 total number of Reset commands (modulo 128) present in the session 3054 history. 3056 Chapter D MUST contain the Tune Request command log if an active Tune 3057 Request command appears in the checkpoint history. The 7-bit COUNT 3058 field codes the total number of Tune Request commands (modulo 128) 3059 present in the session history. 3061 For these commands, the COUNT field acts as a reference count. See the 3062 definition of "session history reference counts" in Appendix A.1 for 3063 more information. 3065 Figure B.1.3 shows the 1-octet command log format for the Song Select 3066 command. 3068 0 3069 0 1 2 3 4 5 6 7 3070 +-+-+-+-+-+-+-+-+ 3071 |S| VALUE | 3072 +-+-+-+-+-+-+-+-+ 3074 Figure B.1.3 -- Song Select command log format 3076 Chapter D MUST contain the Song Select command log if an active Song 3077 Select command appears in the checkpoint history. The 7-bit VALUE field 3078 codes the song number of the most recent active Song Select command in 3079 the session history. 3081 B.1.1 Undefined System Commands 3083 In this section, we define the Chapter D command logs for the undefined 3084 System commands. [MIDI] reserves the undefined System commands 0xF4, 3085 0xF5, 0xF9, and 0xFD for future use. At the time of this writing, any 3086 MIDI command stream that uses these commands is non-compliant with 3087 [MIDI]. However, future versions of [MIDI] may define these commands, 3088 and a few products do use these commands in a non-compliant manner. 3090 Figure B.1.4 shows the variable length command log format for the 3091 undefined System Common commands (0xF4 and 0xF5). 3093 0 1 2 3 3094 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 3095 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3096 |S|C|V|L|DSZ| LENGTH | COUNT | VALUE ... | 3097 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3098 | LEGAL ... | 3099 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3101 Figure B.1.4 -- Undefined System Common command log format 3103 The command log codes a single command type (0xF4 or 0xF5, not both). 3104 Chapter D MUST contain a command log if an active 0xF4 command appears 3105 in the checkpoint history, and MUST contain an independent command log 3106 if an active 0xF5 command appears in the checkpoint history. 3108 Chapter D consists of a two-octet header followed by a variable number 3109 of data fields. Header flag bits indicate the presence of the COUNT 3110 field (C = 1), the VALUE field (V = 1), and the LEGAL field (L = 1). 3111 The 10-bit LENGTH field codes the size of the command log, and conforms 3112 to semantics described in Appendix A.1. 3114 The 2-bit DSZ field codes the number of data octets in the command 3115 instance that appears most recently in the session history. If DSZ = 3116 0-2, the command has 0-2 data octets. If DSZ = 3, the command has 3 or 3117 more command data octets. 3119 We now define the default rules for the use of the COUNT, VALUE, and 3120 LEGAL fields. The session configuration tools defined in Appendix C.2.3 3121 may be used to override this behavior. 3123 By default, if the DSZ field is set to 0, the command log MUST include 3124 the COUNT field. The 8-bit COUNT field codes the total number of 3125 commands of the type coded by the log (0xF4 or 0xF5) present in the 3126 session history, modulo 256. 3128 By default, if the DSZ field is set to 1-3, the command log MUST include 3129 the VALUE field. The variable-length VALUE field codes a verbatim copy 3130 the data octets for the most recent use of the command type coded by the 3131 log (0xF4 or 0xF5) in the session history. The most-significant bit of 3132 the final data octet MUST be set to 1, and the most-significant bit of 3133 all other data octets MUST be set to 0. 3135 The LEGAL field is reserved for future use. If an update to [MIDI] 3136 defines the 0xF4 or 0xF5 command, an IETF standards-track document may 3137 define the LEGAL field. Until such a document appears, senders MUST NOT 3138 use the LEGAL field, and receivers MUST use the LENGTH field to skip 3139 over the LEGAL field. The LEGAL field would be defined by the IETF if 3140 the semantics of the new 0xF4 or 0xF5 command could not be protected 3141 from packet loss via the use of the COUNT and VALUE fields. 3143 Figure B.1.5 shows the variable length command log format for the 3144 undefined System Real-time commands (0xF9 and 0xFD). 3146 0 1 2 3 3147 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 3148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3149 |S|C|L| LENGTH | COUNT | LEGAL ... | 3150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3152 Figure B.1.5 -- Undefined System Real-time command log format 3154 The command log codes a single command type (0xF9 or 0xFD, not both). 3155 Chapter D MUST contain a command log if an active 0xF9 command appears 3156 in the checkpoint history, and MUST contain an independent command log 3157 if an active 0xFD command appears in the checkpoint history. 3159 Chapter D consists of a one-octet header followed by a variable number 3160 of data fields. Header flag bits indicate the presence of the COUNT 3161 field (C = 1) and the LEGAL field (L = 1). The 5-bit LENGTH field codes 3162 the size of the command log, and conforms to semantics described in 3163 Appendix A.1. 3165 We now define the default rules for the use of the COUNT and LEGAL 3166 fields. The session configuration tools defined in Appendix C.2.3 may 3167 be used to override this behavior. 3169 The 8-bit COUNT field codes the total number of commands of the type 3170 coded by the log present in the session history, modulo 256. By 3171 default, the COUNT field MUST be present in the command log. 3173 The LEGAL field is reserved for future use. If an update to [MIDI] 3174 defines the 0xF9 or 0xFD command, an IETF standards-track document may 3175 define the LEGAL field to protect the command. Until such a document 3176 appears, senders MUST NOT use the LEGAL field, and receivers MUST use 3177 the LENGTH field to skip over the LEGAL field. The LEGAL field would be 3178 defined by the IETF if the semantics of the new 0xF9 or 0xFD command 3179 could not be protected from packet loss via the use of the COUNT field. 3181 Finally, we note that some non-standard uses of the undefined System 3182 Real-time commands act to implement non-compliant variants of the MIDI 3183 sequencer system. In Appendix B.3.1, we describe resiliency tools for 3184 the MIDI sequencer system that provide some protection in this case. 3186 B.2 System Chapter V: Active Sense Command 3188 The system journal MUST contain Chapter V if an active MIDI Active Sense 3189 (0xFE) command appears in the checkpoint history. Figure B.2.1 shows 3190 the format for Chapter V. 3192 0 3193 0 1 2 3 4 5 6 7 3194 +-+-+-+-+-+-+-+-+ 3195 |S| COUNT | 3196 +-+-+-+-+-+-+-+-+ 3198 Figure B.2.1 -- System Chapter V format 3200 The 7-bit COUNT field codes the total number of Active Sense commands 3201 (modulo 128) present in the session history. The COUNT field acts as a 3202 reference count. See the definition of "session history reference 3203 counts" in Appendix A.1 for more information. 3205 B.3 System Chapter Q: Sequencer State Commands 3207 This Appendix describes Chapter Q, the system chapter for the MIDI 3208 sequencer commands. 3210 The system journal MUST contain Chapter Q if an active MIDI Song 3211 Position Pointer (0xF2), MIDI Clock (0xF8), MIDI Start (0xFA), MIDI 3212 Continue (0xFB) or MIDI Stop (0xFC) command appears in the checkpoint 3213 history, and if the rules defined in this Appendix require a change in 3214 the Chapter Q bitfield contents because of the command appearance. 3216 Figure B.3.1 shows the variable-length format for Chapter Q. 3218 0 1 2 3 3219 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 3220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3221 |S|N|D|C|T| TOP | CLOCK | TIMETOOLS ... | 3222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3223 | ... | 3224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3226 Figure B.3.1 -- System Chapter Q format 3228 Chapter Q consists of a 1-octet header followed by several optional 3229 fields, in the order shown in Figure B.3.1. 3231 Header flag bits signal the presence of the 16-bit CLOCK field (C = 1) 3232 and the 24-bit TIMETOOLS field (T = 1). The 3-bit TOP header field is 3233 interpreted as an unsigned integer, as are CLOCK and TIMETOOLS. We 3234 describe the TIMETOOLS field in Appendix B.3.1. 3236 Chapter Q encodes the most recent state of the sequencer system. 3237 Receivers use the chapter to re-synchronize the sequencer after a packet 3238 loss episode. Chapter fields encode the on/off state of the sequencer, 3239 the current position in the song, and the downbeat. 3241 The N header bit encodes the relative occurrence of the Start, Stop, and 3242 Continue commands in the session history. If an active Start or 3243 Continue command appears most recently, the N bit MUST be set to 1. If 3244 an active Stop appears most recently, or if no active Start, Stop, or 3245 Continue commands appear in the session history, the N bit MUST be set 3246 to 0. 3248 The C header flag, the TOP header field, and the CLOCK field act to code 3249 the current position in the sequence: 3251 o If C = 1, the 3-bit TOP header field and the 16-bit 3252 CLOCK field are combined to form the 19-bit unsigned quantity 3253 65536*TOP + CLOCK. This value encodes the song position 3254 in units of MIDI Clocks (24 clocks per quarter note), 3255 modulo 524288. Note that the maximum song position value 3256 that may be coded by the Song Position Pointer command is 3257 98303 clocks (which may be coded with 17 bits), and MIDI-coded 3258 songs are generally constructed to avoid durations longer than 3259 this value. However, the 19-bit size may be useful for 3260 real-time applications, such as a drum machine MIDI output 3261 that is sending clock commands for long periods of time. 3263 o If C = 0, the song position is the start of the song. 3264 The C = 0 position is identical to the position coded 3265 by C = 1, TOP = 0, and CLOCK = 0, for the case where 3266 the song position is less than 524288 MIDI clocks. 3267 In certain situations (defined later in this section), 3268 normative text may require the C = 0 or the C = 1, 3269 TOP = 0, CLOCK = 0 encoding of the start of the song. 3271 The C, TOP, and CLOCK fields MUST be set to code the current song 3272 position, for both N = 0 and N = 1 conditions. If C = 0, the TOP field 3273 MUST be set to 0. See [MIDI] for a precise definition of a song 3274 position. 3276 The D header bit encodes information about the downbeat, and acts to 3277 qualify the song position coded by the C, TOP, and CLOCK fields. 3279 If the D bit is set to 1, the song position represents the most recent 3280 position in the sequence that has played. If D = 1, the next Clock 3281 command (if N = 1) or the next (Continue, Clock) pair (if N = 0) acts to 3282 increment the song position by one clock, and to play the updated 3283 position. 3285 If the D bit is set to 0, the song position represents a position in the 3286 sequence that has not yet been played. If D = 0, the next Clock command 3287 (if N = 1) or the next (Continue, Clock) pair (if N = 0) acts to play 3288 the point in the song coded by the song position. The song position is 3289 not incremented. 3291 An example stream that uses D = 0 coding is one whose most recent 3292 sequence command is a Start or Song Position Pointer command (both N = 1 3293 conditions). However, it is also possible to construct examples where D 3294 = 0 and N = 0. A Start command immediately followed by a Stop command 3295 is coded in Chapter Q by setting C = 0, D = 0, N = 0, TOP = 0. 3297 If N = 1 (coding Start or Continue), D = 0 (coding that the downbeat has 3298 yet to be played), and the song position is at the start of the song, 3299 the C = 0 song position encoding MUST be used if a Start command occurs 3300 more recently than a Continue command in the session history, and the C 3301 = 1, TOP = 0, CLOCK = 0 song position encoding MUST be used if a 3302 Continue command occurs more recently than a Start command in the 3303 session history. 3305 B.3.1 Non-compliant Sequencers 3307 The Chapter Q description in this Appendix assumes that the sequencer 3308 system counts off time with Clock commands, as mandated in [MIDI]. 3309 However, a few non-compliant products do not use Clock commands to count 3310 off time, but instead use non-standard methods. 3312 Chapter Q uses the TIMETOOLS field to provide resiliency support for 3313 these non-standard products. By default, the TIMETOOLS field MUST NOT 3314 appear in Chapter Q, and the T header bit MUST be set to 0. The session 3315 configuration tools described in Appendix C.2.3 may be used to select 3316 TIMETOOLS coding. 3318 Figure B.3.2 shows the format of the 24-bit TIMETOOLS field. 3320 0 1 2 3321 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 3322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3323 | TIME | 3324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3326 Figure B.3.2 -- TIMETOOLS format 3328 The TIME field is a 24-bit unsigned integer quantity, with units of 3329 milliseconds. TIME codes an additive correction term for the song 3330 position coded by the TOP, CLOCK, C fields. TIME is coded in network 3331 byte order (big-endian). 3333 A receiver computes the correct song position by converting TIME into 3334 units of MIDI clocks and adding it to 65536*TOP + CLOCK (assuming C = 3335 1). Alternatively, a receiver may convert 65536*TOP + CLOCK into 3336 milliseconds (assuming C = 1) and add it to TIME. The downbeat (D 3337 header bit) semantics defined in Appendix B.3 apply to the corrected 3338 song position. 3340 B.4 System Chapter F: MIDI Time Code Tape Position 3342 This Appendix describes Chapter F, the system chapter for the MIDI Time 3343 Code (MTC) commands. Readers may wish to review the Appendix A.1 3344 definition of "finished/unfinished commands" before reading this 3345 Appendix. 3347 The system journal MUST contain Chapter F if an active System Common 3348 Quarter Frame command (0xF1) or an active finished System Exclusive 3349 (Universal Real Time) MTC Full Frame command (F0 7F cc 01 01 hr mn sc fr 3350 F7) appears in the checkpoint history. Otherwise, the system journal 3351 MUST NOT contain Chapter F. 3353 Figure B.4.1 shows the variable-length format for Chapter F. 3355 0 1 2 3 3356 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 3357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3358 |S|C|P|Q|D|POINT| COMPLETE ... | 3359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3360 | ... | PARTIAL ... | 3361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3362 | ... | 3363 +-+-+-+-+-+-+-+-+ 3365 Figure B.4.1 -- System Chapter F format 3367 Chapter F holds information about recent MTC tape positions coded in the 3368 session history. Receivers use Chapter F to re-synchronize the MTC 3369 system after a packet loss episode. 3371 Chapter F consists of a 1-octet header followed by several optional 3372 fields, in the order shown in Figure B.4.1. The C and P header bits 3373 form a Table of Contents (TOC), and signal the presence of the 32-bit 3374 COMPLETE field (C = 1) and the 32-bit PARTIAL field (P = 1). 3376 The Q header bit codes information about the COMPLETE field format. If 3377 Chapter F does not contain a COMPLETE field, Q MUST be set to 0. 3379 The D header bit codes the tape movement direction. If the tape is 3380 moving forward, or if the tape direction is indeterminate, the D bit 3381 MUST be set to 0. If the tape is moving in the reverse direction, the D 3382 bit MUST be set to 1. In most cases, the ordering of commands in the 3383 session history clearly defines the tape direction. However, a few 3384 command sequences have an indeterminate direction (such as a session 3385 history consisting of one Full Frame command). 3387 The 3-bit POINT header field is interpreted as an unsigned integer. 3388 Appendix B.4.1 defines how the POINT field codes information about the 3389 contents of the PARTIAL field. If Chapter F does not contain a PARTIAL 3390 field, POINT MUST be set to 7 (if D = 0) or 0 (if D = 1). 3392 Chapter F MUST include the COMPLETE field if an active finished Full 3393 Frame command appears in the checkpoint history, or if an active Quarter 3394 Frame command that completes the encoding of a frame value appears in 3395 the checkpoint history. 3397 The COMPLETE field encodes the most recent active complete MTC frame 3398 value that appears in the session history. This frame value may take 3399 the form of a series of 8 active Quarter Frame commands (0xF1 0x0n 3400 through 0xF1 0x7n for forward tape movement, 0xF1 0x7n through 0xF1 0x0n 3401 for reverse tape movement), or may take the form of an active finished 3402 Full Frame command. 3404 If the COMPLETE field encodes a Quarter Frame command series, the Q 3405 header bit MUST be set to 1, and the COMPLETE field MUST have the format 3406 shown in Figure B.4.2. The 4-bit fields MT0 through MT7 code the data 3407 (lower) nibble for the Quarter Frame commands for Message Type 0 through 3408 Message Type 7 [MIDI]. These nibbles encode a complete frame value, in 3409 addition to fields reserved for future use by [MIDI]. 3411 0 1 2 3 3412 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 3413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3414 | MT0 | MT1 | MT2 | MT3 | MT4 | MT5 | MT6 | MT7 | 3415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3417 Figure B.4.2 -- COMPLETE field format, Q = 1 3419 In this usage, the frame value encoded in the COMPLETE field MUST be 3420 offset by 2 frames (relative to the frame value encoded in the Quarter 3421 Frame commands) if the frame value codes a 0xF1 0x0n through 0xF1 0x7n 3422 command sequence. This offset compensates for the two-frame latency of 3423 the Quarter Frame encoding for forward tape movement. No offset is 3424 applied if the frame value codes a 0xF1 0x7n through 0xF1 0x0n Quarter 3425 Frame command sequence. 3427 The most recent active complete MTC frame value may alternatively be 3428 encoded by an active finished Full Frame command. In this case, the Q 3429 header bit MUST be set to 0, and the COMPLETE field MUST have format 3430 shown in Figure B.4.3. The HR, MN, SC, and FR fields correspond to the 3431 hr, mn, sc, and fr data octets of the Full Frame command. 3433 0 1 2 3 3434 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3436 | HR | MN | SC | FR | 3437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3439 Figure B.4.3 -- COMPLETE field format, Q = 0 3441 B.4.1 Partial Frames 3443 The most recent active session history command that encodes MTC frame 3444 value data may be a Quarter Frame command other than a forward-moving 3445 0xF1 0x7n command (which completes a frame value for forward tape 3446 movement) or a reverse-moving 0xF1 0x1n command (which completes a frame 3447 value for reverse tape movement). 3449 We consider this type of Quarter Frame command to be associated with a 3450 partial frame value. The Quarter Frame sequence that defines a partial 3451 frame value MUST either start at Message Type 0 and increment 3452 contiguously to an intermediate Message Type less than 7, or start at 3453 Message Type 7 and decrement contiguously to an intermediate Message 3454 type greater than 0. A Quarter Frame command sequence that does not 3455 follow this pattern is not associated with a partial frame value. 3457 Chapter F MUST include a PARTIAL field if the most recent active command 3458 in the checkpoint history that encodes MTC frame value data is a Quarter 3459 Frame command that is associated with a partial frame value. Otherwise, 3460 Chapter F MUST NOT include a PARTIAL field. 3462 The partial frame value consists of the data (lower) nibbles of the 3463 Quarter Frame command sequence. The PARTIAL field codes the partial 3464 frame value, using the format shown in Figure B.4.2. Message Type 3465 fields that are not associated with a Quarter Frame command MUST be set 3466 to 0. 3468 The POINT header field indicates the Message Type fields in the PARTIAL 3469 field code valid data. If P = 1, the POINT field MUST encode the 3470 unsigned integer value formed by the lower 3 bits of the upper nibble of 3471 the data value of the most recent active Quarter Frame command in the 3472 session history. If D = 0 and P = 1, POINT MUST take on a value in the 3473 range 0-6. If D = 1 and P = 1, POINT MUST take on a value in the range 3474 1-7. 3476 If D = 0, MT fields (Figure B.4.2) in the inclusive range 0 up to and 3477 including the POINT value encode the partial frame value. If D = 1, MT 3478 fields in the inclusive range 7 down to and including the POINT value 3479 encode the partial frame value. Note that unlike the COMPLETE field 3480 encoding, senders MUST NOT add a 2-frame offset to the partial frame 3481 value encoded in PARTIAL. 3483 For the default semantics, if a recovery journal contains Chapter F, and 3484 if the session history codes a legal [MIDI] series of Quarter Frame and 3485 Full Frame commands, the chapter always contains a COMPLETE or a PARTIAL 3486 field (and may contain both fields). Thus, a one-octet Chapter F (C = P 3487 = 0) always codes the presence of an illegal command sequence in the 3488 session history (under some conditions, the C = 1, P = 0 condition may 3489 also code the presence of an illegal command sequence). The illegal 3490 command sequence conditions are transient in nature, and usually 3491 indicate that a Quarter Frame command sequence began with an 3492 intermediate Message Type. 3494 B.5 System Chapter X: System Exclusive 3496 This Appendix describes Chapter X, the system chapter for MIDI System 3497 Exclusive (SysEx) commands (0xF0). Readers may wish to review the 3498 Appendix A.1 definition of "finished/unfinished commands" before reading 3499 this Appendix. 3501 Chapter X consists of a list of one or more command logs. Each log in 3502 the list codes information about a specific finished or unfinished SysEx 3503 command that appears in the session history. The system journal MUST 3504 contain Chapter X if the rules defined in Appendix B.5.2 require that 3505 one or more logs appear in the list. 3507 The log list is not preceded by a header. Instead, each log implicitly 3508 encodes its own length. Given the length of the N'th list log, the 3509 presence of the (N+1)'th list log may be inferred from the LENGTH field 3510 of the system journal header (Figure 10 in Section 5 of the main text). 3511 The log list MUST obey the oldest-first ordering rule (defined in 3512 Appendix A.1). 3514 B.5.1 Chapter Format 3516 Figure B.5.1 shows the bitfield format for the Chapter X command log. 3518 0 1 2 3 3519 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 3520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3521 |S|T|C|F|D|L|STA| TCOUNT | COUNT | FIRST ... | 3522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3523 | DATA ... | 3524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3526 Figure B.5.1 -- Chapter X command log format 3528 A Chapter X command log consists of a 1-octet header, followed by the 3529 optional TCOUNT, COUNT, FIRST, and DATA fields. 3531 The T, C, F, and D header bits act as a Table of Contents (TOC) for the 3532 log. If T is set to 1, the 1-octet TCOUNT field appears in the log. If 3533 C is set to 1, the 1-octet COUNT field appears in the log. If F is set 3534 to 1, the variable-length FIRST field appears in the log. If D is set 3535 to 1, the variable-length DATA field appears in the log. 3537 The L header bit sets the coding tool for the log. We define the log 3538 coding tools in Appendix B.5.2. 3540 The STA field codes the status of the command coded by the log. The 3541 2-bit STA value is interpreted as an unsigned integer. If STA is 0, the 3542 log codes an unfinished command. Non-zero STA values code different 3543 classes of finished commands. An STA value of 1 codes a cancelled 3544 command, an STA value of 2 codes a command that uses the "dropped F7" 3545 construction, and an STA value of 3 codes all other finished commands. 3546 Section 3.2 in the main text describes cancelled and "dropped F7" 3547 commands. 3549 The S bit (Appendix A.1) of the first log in the list acts as the S bit 3550 for Chapter X. For the other logs in the list, the S bit refers to the 3551 log itself. The value of the "phantom" S bit associated with the first 3552 log is defined by the following rules: 3554 o If the list codes one log, the phantom S-bit value is 3555 the same as the Chapter X S-bit value. 3557 o If the list codes multiple logs, the phantom S-bit value is 3558 the logical OR of the S-bit value of the first and second 3559 command logs in the list. 3561 In all other respects, the S bit follows the semantics defined in 3562 Appendix A.1. 3564 The FIRST field (present if F = 1) encodes a variable-length unsigned 3565 integer value that sets the coverage of the DATA field. 3567 The FIRST field (present if F = 1) encodes a variable-length unsigned 3568 integer value that specifies which SysEx data bytes are encoded in the 3569 DATA field of the log. The FIRST field consists of an octet whose most- 3570 significant bit is set to 0, optionally preceded by one or more octets 3571 whose most-significant bit is set to 1. The algorithm shown in Figure 3572 B.5.2 decodes this format into an unsigned integer, to yield the value 3573 dec(FIRST). FIRST uses a variable-length encoding because dec(FIRST) 3574 references a data octet in a SysEx command, and a SysEx command may 3575 contain an arbitrary number of data octets. 3577 One-Octet FIRST value: 3579 Encoded form: 0ddddddd 3580 Decoded form: 00000000 00000000 00000000 0ddddddd 3582 Two-Octet FIRST value: 3584 Encoded form: 1ccccccc 0ddddddd 3585 Decoded form: 00000000 00000000 00cccccc cddddddd 3587 Three-Octet FIRST value: 3589 Encoded form: 1bbbbbbb 1ccccccc 0ddddddd 3590 Decoded form: 00000000 000bbbbb bbcccccc cddddddd 3592 Four-Octet FIRST value: 3594 Encoded form: 1aaaaaaa 1bbbbbbb 1ccccccc 0ddddddd 3595 Decoded form: 0000aaaa aaabbbbb bbcccccc cddddddd 3597 Figure B.5.2 -- Decoding FIRST field formats 3599 The DATA field (present if D = 1) encodes a modified version of the data 3600 octets of the SysEx command coded by the log. Status octets MUST NOT be 3601 coded in the DATA field. 3603 If F = 0, the DATA field begins with the first data octet of the SysEx 3604 command, and includes all subsequent data octets for the command that 3605 appear in the session history. If F = 1, the DATA field begins with the 3606 (dec(FIRST) + 1)'th data octet of the SysEx command, and includes all 3607 subsequent data octets for the command that appear in the session 3608 history. Note that the word "command" in the descriptions above refers 3609 to the original SysEx command as it appears in the source MIDI data 3610 stream, not to a particular MIDI list SysEx command segment. 3612 The length of the DATA field is coded implicitly, using the most- 3613 significant bit of each octet. The most-significant bit of the final 3614 octet of the DATA field MUST be set to 1. The most significant bit of 3615 all other DATA octets MUST be set to 0. This coding method relies on 3616 the fact that the most-significant bit of a MIDI data octet is 0 by 3617 definition. Apart from this length-coding modification, the DATA field 3618 encodes a verbatim copy of all data octets it encodes. 3620 B.5.2 Log Inclusion Semantics 3622 Chapter X offers two tools to protect SysEx commands: the "recency" tool 3623 and the "list" tool. The tool definitions use the concept of the "SysEx 3624 type" of a command, which we now define. 3626 Each SysEx command instance in a session, excepting MTC Full Frame 3627 commands, is said to have a "SysEx type". Types are used in equality 3628 comparisons: two SysEx commands in a session are said to have "the same 3629 SysEx type" or "different SysEx types". 3631 If efficiency is not a concern, a sender may follow a simple typing 3632 rule: every SysEx command in the session history has a different SysEx 3633 type, and thus, no two commands in the session have the same type. 3635 To improve efficiency, senders MAY implement exceptions to this rule. 3636 These exceptions declare certain sets of SysEx command instances to have 3637 the same SysEx type. Any command not covered by an exception follows 3638 the simple rule. We list exceptions below: 3640 o All commands with identical data octet fields (same number of 3641 data octets, same value for each data octet) have the same type. 3642 This rule MUST be applied to all SysEx commands in the session, 3643 or not at all. Note that the implementation of this exception 3644 requires no sender knowledge of the format and semantics of 3645 the SysEx commands in the stream, merely the ability to count 3646 and compare octets. 3648 o Two instances of the same command whose semantics set or report 3649 the value of the same "parameter" have the same type. The 3650 implementation of this exception requires specific knowledge of 3651 the format and semantics of SysEx commands. In practice, a 3652 sender implementation chooses to support this exception for 3653 certain classes of commands (such as the Universal System 3654 Exclusive commands defined in [MIDI]). If a sender supports 3655 this exception for a particular command in a class (for 3656 example, the Universal Real Time System Exclusive message 3657 for Master Volume, F0 F7 cc 04 01 vv vv F7, defined in [MIDI]), 3658 it MUST support the exception to all instances of this 3659 particular command in the session. 3661 We now use this definition of "SysEx type" to define the "recency" tool 3662 and the "list" tool for Chapter X. 3664 By default, the Chapter X log list MUST code sufficient information to 3665 protect the rendered MIDI performance from indefinite artifacts caused 3666 by the loss of all finished or unfinished active SysEx commands that 3667 appear in the checkpoint history (excluding finished MTC Full Frame 3668 commands, which are coded in Chapter F (Appendix B.4)). 3670 To protect a command of a specific SysEx type with the recency tool, 3671 senders MUST code a log in the log list for the most recent finished 3672 active instance of the SysEx type that appears in the checkpoint 3673 history. Additionally, if an unfinished active instance of the SysEx 3674 type appears in the checkpoint history, senders MUST code a log in the 3675 log list for the unfinished command instance. The L header bit of both 3676 command logs MUST be set to 0. 3678 To protect a command of a specific SysEx type with the list tool, 3679 senders MUST code a log in the Chapter X log list for each finished or 3680 unfinished active instance of the SysEx type that appears in the 3681 checkpoint history. The L header bit of list tool command logs MUST be 3682 set to 1. 3684 As a rule, a log REQUIRED by the list or recency tool MUST include a 3685 DATA field that codes all data octets that appear in the checkpoint 3686 history for the SysEx command instance associated with the log. The 3687 FIRST field MAY be used to configure a DATA field that minimally meets 3688 this requirement. 3690 An exception to this rule applies to cancelled commands (defined in 3691 Section 3.2). REQUIRED command logs associated with cancelled commands 3692 MAY be coded with no DATA field. However, if DATA appears in the log, 3693 DATA MUST code all data octets that appear in the checkpoint history for 3694 the command associated with the log. 3696 As defined by the preceding text in this section, by default all 3697 finished or unfinished active SysEx commands that appear in the 3698 checkpoint history (excluding finished MTC Full Frame commands) MUST be 3699 protected by the list tool or the recency tool. 3701 For some MIDI source streams, this default yields a Chapter X whose size 3702 is too large. For example, imagine that a sender begins to transcode a 3703 SysEx command with 10,000 data octets onto a UDP RTP stream "on the 3704 fly", by sending SysEx command segments as soon as data octets are 3705 delivered by the MIDI source. After 1000 octets have been sent, the 3706 expansion of Chapter X yields an RTP packet that is too large to fit in 3707 the Maximum Transmission Unit (MTU) for the stream. 3709 In this situation, if a sender uses the closed-loop sending policy for 3710 SysEx commands, the RTP packet size may always be capped by stalling the 3711 stream. In a stream stall, once the packet reaches a maximum size, the 3712 sender refrains from sending new packets with non-empty MIDI Command 3713 Sections until receiver feedback permits the trimming of Chapter X. If 3714 the stream permits arbitrary commands to appear between SysEx segments 3715 (selectable during configuration using the tools defined in Appendix 3716 C.1), the sender may stall the SysEx segment stream but continue to code 3717 other commands in the MIDI list. 3719 Stalls are a workable but sub-optimal solution to Chapter X size issues. 3720 As an alternative to stalls, senders SHOULD take preemptive action 3721 during session configuration to reduce the anticipated size of Chapter 3722 X, using the methods described below: 3724 o Partitioned transport. Appendix C.5 provides tools 3725 for sending a MIDI name space over several RTP streams. 3726 Senders may use these tools to map a MIDI source 3727 into a low-latency UDP RTP stream (for channel commands 3728 and short SysEx commands) and a reliable [CONTRANS] TCP stream 3729 (for bulk-data SysEx commands). The cm_unused and 3730 cm_used parameters (Appendix C.1) may be used to 3731 communicate the nature of the SysEx command partition. 3732 As TCP is reliable, the RTP MIDI TCP stream would not 3733 use the recovery journal. To minimize transmission 3734 latency for short SysEx commands, senders may begin 3735 segmental transmission for all SysEx commands over the 3736 UDP stream, and then cancel the UDP transmission of long 3737 commands (using tools described in Section 3.2) and 3738 resend the commands over the TCP stream. 3740 o Selective protection. Journal protection may not be 3741 necessary for all SysEx commands in a stream. The 3742 ch_never parameter (Appendix C.2) may be used to 3743 communicate which SysEx commands are excluded from 3744 Chapter X. 3746 B.5.3 TCOUNT and COUNT fields 3748 If the T header bit is set to 1, the 8-bit TCOUNT field appears in the 3749 command log. If the C header bit is set to 1, the 8-bit COUNT field 3750 appears in the command log. TCOUNT and COUNT are interpreted as 3751 unsigned integers. 3753 The TCOUNT field codes the total number of SysEx commands of the SysEx 3754 type coded by the log that appear in the session history, at the moment 3755 after the (finished or unfinished) command coded by the log enters the 3756 session history. 3758 The COUNT field codes the total number of SysEx commands that appear in 3759 the session history, excluding commands that are excluded from Chapter X 3760 via the ch_never parameter (Appendix C.2), at the moment after the 3761 (finished or unfinished) command coded by the log enters the session 3762 history. 3764 Command counting for TCOUNT and COUNT uses modulo-256 arithmetic. MTC 3765 Full Frame command instances (Appendix B.4) are included in command 3766 counting if the TCOUNT and COUNT definitions warrant their inclusion, as 3767 are cancelled commands (Section 3.2). 3769 Senders use the TCOUNT and COUNT fields to track the identity and (for 3770 TCOUNT) the sequence position of a command instance. Senders MUST use 3771 the TCOUNT or COUNT fields if identity or sequence information is 3772 necessary to protect the command type coded by the log. 3774 If a sender uses the COUNT field in a session, the final command log in 3775 every Chapter X in the stream MUST code the COUNT field. This rule lets 3776 receivers resynchronize the COUNT value after a packet loss. 3778 C. Session Configuration Tools 3780 In Sections 6.1-2 of the main text, we show session descriptions for 3781 minimal native and mpeg4-generic RTP MIDI streams. Minimal streams lack 3782 the flexibility to support some applications. In this Appendix, we 3783 describe how to customize stream behavior through the use of the payload 3784 format parameters. 3786 The Appendix begins with 6 sections, each devoted to parameters that 3787 affect a particular aspect of stream behavior: 3789 o Appendix C.1 describes the stream subsetting system 3790 (cm_unused and cm_used). 3792 o Appendix C.2 describes the journalling system (ch_anchor, 3793 ch_default, ch_never, j_sec, j_update). 3795 o Appendix C.3 describes MIDI command timestamp semantics 3796 (linerate, mperiod, octpos, tsmode). 3798 o Appendix C.4 describes the temporal duration ("media time") 3799 of an RTP MIDI packet (guardtime, rtp_maxptime, rtp_ptime). 3801 o Appendix C.5 concerns stream description (musicport). 3803 o Appendix C.6 describes MIDI rendering (chanmask, cid, 3804 inline, multimode, render, rinit, subrender, smf_cid, 3805 smf_info, smf_inline, smf_url, url). 3807 The parameters listed above may optionally appear in session 3808 descriptions of RTP MIDI streams. If these parameters are used in an 3809 SDP session description, the parameters appear on an fmtp attribute 3810 line. This attribute line applies to the payload type associated with 3811 the fmtp line. 3813 The parameters listed above add extra functionality ("features") to 3814 minimal RTP MIDI streams. In Appendix C.7, we show how to use these 3815 features to support two classes of applications: content-streaming using 3816 RTSP (Appendix C.7.1) and network musical performance using SIP 3817 (Appendix C.7.2). 3819 The participants in a multimedia session MUST share a common view of all 3820 of the RTP MIDI streams that appear in an RTP session, as defined by a 3821 single media (m=) line. In some RTP MIDI applications, the "common 3822 view" restriction makes it difficult to use sendrecv streams (all 3823 parties send and receive), as each party has its own requirements. For 3824 example, a two-party network musical performance application may wish to 3825 customize the renderer on each host to match the CPU performance of the 3826 host [NMP]. 3828 We solve this problem by using two RTP MIDI streams -- one sendonly, one 3829 recvonly -- in lieu of one sendrecv stream. The data flows in the two 3830 streams travel in opposite directions, to control receivers configured 3831 to use different renderers. In the third example in Appendix C.5, we 3832 show how the musicport parameter may be used to define virtual sendrecv 3833 streams. 3835 As a general rule, the RTP MIDI protocol does not handle parameter 3836 changes during a session well, because the parameters describe 3837 heavyweight or stateful configuration that are not easily changed once a 3838 session has begun. Thus, parties SHOULD NOT expect that parameter 3839 change requests during a session will be accepted by other parties. 3840 However, implementors SHOULD support in-session parameter changes that 3841 are easy to handle (example: the guardtime parameter defined in Appendix 3842 C.4), and SHOULD be capable of accepting requests for changes of those 3843 parameters, as received by its session management protocol (for example, 3844 re-offers in SIP [RFC3264]). 3846 Appendix D defines the Augmented Backus-Naur Form (ABNF, [RFC2234]) 3847 syntax for the payload parameters. Appendix H provides information to 3848 the Internet Assigned Numbers Authority (IANA) on the media types and 3849 parameters defined in this document. 3851 Appendix C.6.5 defines the media type "audio/asc", a stored object for 3852 initializing mpeg4-generic renderers. As described in Appendix C.6, the 3853 audio/asc media type is assigned to the "rinit" parameter to specify an 3854 initialization data object for the default mpeg4-generic renderer. Note 3855 that RTP stream semantics are not defined for "audio/asc". Therefore, 3856 the "asc" subtype MUST NOT appear on the rtpmap line of a session 3857 description. 3859 C.1 Configuration Tools: Stream Subsetting 3861 As defined in Section 3.2 in the main text, the MIDI list of an RTP MIDI 3862 packet may encode any MIDI command that may legally appear on a MIDI 1.0 3863 DIN cable. 3865 In this Appendix we define two parameters (cm_unused and cm_used) that 3866 modify this default condition, by excluding certain types of MIDI 3867 commands from the MIDI list of all packets in a stream. For example, if 3868 a multimedia session partitions a MIDI name space into two RTP MIDI 3869 streams, the parameters may be used to define which commands appear in 3870 each stream. 3872 In this Appendix, we define a simple language for specifying MIDI 3873 command types. If a command type is assigned to cm_unused, the commands 3874 coded by the string MUST NOT appear in the MIDI list. If a command type 3875 is assigned to cm_used, the commands coded by the string MAY appear in 3876 the MIDI list. 3878 The parameter list may code multiple assignments to cm_used and 3879 cm_unused. Assignments have a cumulative effect, and are applied in the 3880 order of appearance in the parameter list. A later assignment of a 3881 command type to the same parameter expands the scope of the earlier 3882 assignment. A later assignment of a command type to the opposite 3883 parameter cancels (partially or completely) the effect of an earlier 3884 assignment. 3886 To initialize the stream subsetting system, "implicit" assignments to 3887 cm_unused and cm_used are processed before processing the actual 3888 assignments that appear in the parameter list. The System Common 3889 undefined commands (0xF4, 0xF5) and the System Real-Time Undefined 3890 commands (0xF9, 0xFD) are implicitly assigned to cm_unused. All other 3891 command types are implicitly assigned to cm_used. 3893 Note that the implicit assignments code the default behavior of an RTP 3894 MIDI stream as defined in Section 3.2 in the main text (namely, that all 3895 commands that may legally appear on a MIDI 1.0 DIN cable may appear in 3896 the stream). Also note that assignments of the System Common undefined 3897 commands (0xF4, 0xF5) apply to the use of these commands in the MIDI 3898 source command stream, not the special use of 0xF4 and 0xF5 in SysEx 3899 segment encoding defined in Section 3.2 in the main text. 3901 As a rule, parameter assignments obey the following syntax (see Appendix 3902 D for ABNF): 3904 = [channel list][field list] 3906 The command-type list is mandatory; the channel and field lists are 3907 optional. 3909 The command-type list specifies the MIDI command types for which the 3910 parameter applies. The command-type list is a concatenated sequence of 3911 one or more of the letters (ABCFGHJKMNPQTVWXYZ). The letters code the 3912 following command types: 3914 o A: Poly Aftertouch (0xA) 3915 o B: System Reset (0xFF) 3916 o C: Control Change (0xB) 3917 o F: System Time Code (0xF1) 3918 o G: System Tune Request (0xF6) 3919 o H: System Song Select (0xF3) 3920 o J: System Common Undefined (0xF4) 3921 o K: System Common Undefined (0xF5) 3922 o N: NoteOff (0x8), NoteOn (0x9) 3923 o P: Program Change (0xC) 3924 o Q: System Sequencer (0xF2, 0xF8, 0xF9, 0xFA, 0xFB, 0xFC) 3925 o T: Channel Aftertouch (0xD) 3926 o V: System Active Sense (0xFE) 3927 o W: Pitch Wheel (0xE) 3928 o X: SysEx (0xF0) 3929 o Y: System Real-Time Undefined (0xF9) 3930 o Z: System Real-Time Undefined (0xFD) 3932 In addition to the letters above, the letter M may also appear in the 3933 command-type list. The letter M refers to the MIDI parameter system 3934 (see definition in Appendix A.1 and in [MIDI]). An assignment of M to 3935 cm_unused codes that no RPN or NRPN transactions may appear in the MIDI 3936 list. 3938 Note that if cm_unused is assigned the letter M, Control Change (0xB) 3939 commands for the controller numbers in the standard controller 3940 assignment might still appear in the MIDI list. For an explanation, see 3941 Appendix A.3.4 for a discussion of the "general-purpose" use of 3942 parameter system controller numbers. 3944 In the text below, rules that apply to "MIDI voice channel commands" 3945 also apply to letter M. 3947 The letters in the command-type list MUST be upper case, and MUST appear 3948 in alphabetical order. Letters other than (ABCFGHJKMNPQTVWXYZ) that 3949 appear in the list MUST be ignored. 3951 For MIDI voice channel commands, the channel list specifies the MIDI 3952 channels for which the parameter applies. If no channel list is 3953 provided, the parameter applies to all MIDI channels (0-15). The 3954 channel list takes the form of a list of channel numbers (0 through 15) 3955 and dash-separated channel number ranges (i.e. 0-5, 8-12, etc). Dots 3956 (i.e. "." characters) separate elements in the channel list. 3958 Recall that System commands do not have a MIDI channel associated with 3959 them. Thus, for most command-type letters that code System commands (B, 3960 F, G, H, J, K, Q, V, Y and Z), the channel list is ignored. 3962 For the command-type letter X, the appearance of certain numbers in the 3963 channel list codes special semantics. 3965 o The digit 0 codes that SysEx "cancel" sublists (Section 3966 3.2 in the main text) MUST NOT appear in the MIDI list. 3968 o The digit 1 codes that cancel sublists MAY appear in the 3969 MIDI list (the default condition). 3971 o The digit 2 codes that commands other than System 3972 Real-time MIDI commands MUST NOT appear between SysEx 3973 command segments in the MIDI list (the default condition). 3975 o The digit 3 codes that any MIDI command type may 3976 appear between SysEx command segments in the MIDI list, 3977 with the exception of the segmented encoding of a second 3978 SysEx command (verbatim SysEx commands are OK). 3980 For command-type X, the channel list MUST NOT contain both digits 0 and 3981 1, and MUST NOT contain both digits 2 and 3. For command-type X, 3982 channel list numbers other than the numbers defined above are ignored. 3983 If X does not have a channel list, the semantics marked "the default 3984 condition" in the list above apply. 3986 The syntax for field lists in a parameter assignment follows the syntax 3987 for channel lists. If no field list is provided, the parameter applies 3988 to all controller or note numbers. 3990 For command-type C (Control Change), the field list codes the controller 3991 numbers (0-255) for which the parameter applies. 3993 For command-type M (Parameter System), the field list codes the 3994 Registered Parameter Numbers (RPNs) and Non-Registered Parameter Numbers 3995 (NRPNs) for which the parameter applies. The number range 0-16383 3996 specifies RPNs, the number range 16384-32767 specifies NRPNs (16384 3997 corresponds to NRPN 0, 32767 corresponds to NRPN 16383). 3999 For command-types N (NoteOn and NoteOff) and A (Poly Aftertouch), the 4000 field list codes the note numbers for which the parameter applies. 4002 For command-types J and K (System Common Undefined), the field list 4003 consists of a single digit, which specifies the number of data octets 4004 that follow the command octet. 4006 For command-type X (SysEx), the field list codes the number of data 4007 octets that may appear in a SysEx command. Thus, the field list 0-255 4008 specifies SysEx commands with 255 or fewer data octets, the field list 4009 256-429496729 specifies SysEx commands with more than 255 data octets 4010 but excludes commands with 255 or fewer data octets, and the field list 4011 0 excludes all commands. 4013 A secondary parameter assignment syntax customizes command-type X (see 4014 Appendix D for complete ABNF): 4016 = "__" ["_" ] "__" 4018 The assignment defines the class of SysEx commands that obeys the 4019 semantics of the assigned parameter. The command class is specified by 4020 listing the permitted values of the first N data octets that follow the 4021 SysEx 0xF0 command octet. Any SysEx command whose first N data octets 4022 match the list is a member of the class. 4024 Each defines a data octet of the command, as a dot-separated 4025 (".") list of one or more hexadecimal constants (such as "7F") or dash- 4026 separated hexadecimal ranges (such as "01-1F"). Underscores ("_") 4027 separate each . Double-underscores ("__") delineate the data 4028 octet list. 4030 Using this syntax, each assignment specifies a single SysEx command 4031 class. Session descriptions may use several assignments to cm_used and 4032 cm_unused to specify complex behaviors. 4034 The example session description below illustrates the use of the stream 4035 subsetting parameters: 4037 v=0 4038 o=lazzaro 2520644554 2838152170 IN IP6 first.example.net 4039 s=Example 4040 t=0 0 4041 m=audio 5004 RTP/AVP 96 4042 c=IN IP6 2001:DB80::7F2E:172A:1E24 4043 a=rtpmap:96 rtp-midi/44100 4044 a=fmtp:96 cm_unused=ACGHJKNMPTVWXYZ; cm_used=__7F_00-7F_01_01__ 4046 The session description configures the stream for use in clock 4047 applications. All voice channels are unused, as are all System Commands 4048 except those used for MIDI Time Code (command-type F, and the Full Frame 4049 SysEx command that is matched by the string assigned to cm_used), the 4050 System Sequencer commands (command-type Q), and System Reset (command- 4051 type B). 4053 C.2 Configuration Tools: The Journalling System 4055 In this Appendix, we define the payload format parameters that configure 4056 stream journalling and the recovery journal system. 4058 The j_sec parameter (Appendix C.2.1) sets the journalling method for the 4059 stream. The j_update parameter (Appendix C.2.2) sets the recovery 4060 journal sending policy for the stream. Appendix C.2.2 also defines the 4061 sending policies of the recovery journal system. 4063 Appendix C.2.3 defines several parameters that modify the recovery 4064 journal semantics. These parameters change the default recovery journal 4065 semantics as defined in Section 5 and Appendices A-B. 4067 The journalling method for a stream is set at the start of a session and 4068 MUST NOT be changed thereafter. This requirement forbids changes to the 4069 j_sec parameter once a session has begun. 4071 A related requirement, defined in the Appendix sections below, forbids 4072 the acceptance of parameter values that would violate the recovery 4073 journal mandate. In many cases, a change in one of the parameters 4074 defined in this Appendix during an on-going session would result in a 4075 violation of the recovery journal mandate for an implementation; in this 4076 case, the parameter change MUST NOT be accepted. 4078 C.2.1 The j_sec Parameter 4080 Section 2.2 defines the default journalling method for a stream. 4081 Streams that use unreliable transport (such as UDP) default to using the 4082 recovery journal. Streams that use reliable transport (such as TCP) 4083 default to not using a journal. 4085 The parameter j_sec may be used to override this default. This memo 4086 defines two symbolic values for j_sec: "none", to indicate that all 4087 stream payloads MUST NOT contain a journal section, and "recj", to 4088 indicate that all stream payloads MUST contain a journal section that 4089 uses the recovery journal format. 4091 For example, the j_sec parameter might be set to "none" for a UDP stream 4092 that travels between two hosts on a local network that is known to 4093 provide reliable datagram delivery. 4095 The session description below configures a UDP stream that does not use 4096 the recovery journal: 4098 v=0 4099 o=lazzaro 2520644554 2838152170 IN IP4 first.example.net 4100 s=Example 4101 t=0 0 4102 m=audio 5004 RTP/AVP 96 4103 c=IN IP4 192.0.2.94 4104 a=rtpmap:96 rtp-midi/44100 4105 a=fmtp:96 j_sec=none 4107 Other IETF standards-track documents may define alternative journal 4108 formats. These documents MUST define new symbolic values for the j_sec 4109 parameter to signal the use of the format. 4111 Parties MUST NOT accept a j_sec value that violates the recovery journal 4112 mandate (see Section 4 for details). If a session description uses a 4113 j_sec value unknown to the recipient, the recipient MUST NOT accept the 4114 description. 4116 Special j_sec issues arise when sessions are managed by session 4117 management tools (like RTSP, [RFC2326]) that use SDP for "declarative 4118 usage" purposes (see the preamble of Section 6 for details). For these 4119 session management tools, SDP does not code transport details (such as 4120 UDP or TCP) for the session. Instead, server and client negotiate 4121 transport details via other means (for RTSP, the SETUP method). 4123 In this scenario, the use of the j_sec parameter may be ill-advised, as 4124 the creator of the session description may not yet know the transport 4125 type for the session. In this case, the session description SHOULD 4126 configure the journalling system using the parameters defined in the 4127 remainder of Appendix C.2, but SHOULD NOT use j_sec to set the 4128 journalling status. Recall that if j_sec does not appear in the session 4129 description, the default method for choosing the journalling method is 4130 in effect (no journal for reliable transport, recovery journal for 4131 unreliable transport). 4133 However, in declarative usage situations where the creator of the 4134 session description knows journalling is always required or never 4135 required, the session description SHOULD use the j_sec parameter. 4137 C.2.2 The j_update Parameter 4139 In Section 4, we use the term "sending policy" to describe the method a 4140 sender uses to choose the checkpoint packet identity for each recovery 4141 journal in a stream. In the sub-sections that follow, we normatively 4142 define three sending policies: anchor, closed-loop, and open-loop. 4144 As stated in Section 4, the default sending policy for a stream is the 4145 closed-loop policy. The j_update parameter may be used to override this 4146 default. 4148 We define three symbolic values for j_update: "anchor", to indicate that 4149 the stream uses the anchor sending policy, "open-loop", to indicate that 4150 the stream uses the open-loop sending policy, and "closed-loop", to 4151 indicate that the stream uses the closed-loop sending policy. See 4152 Appendix C.2.3 for examples session descriptions that use the j_update 4153 parameter. 4155 Parties MUST NOT accept a j_update value that violates the recovery 4156 journal mandate (Section 4). 4158 Other IETF standards-track documents may define additional sending 4159 policies for the recovery journal system. These documents MUST define 4160 new symbolic values for the j_update parameter to signal the use of the 4161 new policy. If a session description uses a j_update value unknown to 4162 the recipient, the recipient MUST NOT accept the description. 4164 C.2.2.1 The anchor Sending Policy 4166 In the anchor policy, the sender uses the first packet in the stream as 4167 the checkpoint packet for all packets in the stream. The anchor policy 4168 satisfies the recovery journal mandate (Section 4), as the checkpoint 4169 history always covers the entire stream. 4171 The anchor policy does not require the use of the RTP control protocol 4172 (RTCP, [RFC3550]) or other feedback from receiver to sender. Senders do 4173 not need to take special actions to ensure that received streams start 4174 up free of artifacts, as the recovery journal always covers the entire 4175 history of the stream. Receivers are relieved of the responsibility of 4176 tracking the changing identity of the checkpoint packet, because the 4177 checkpoint packet never changes. 4179 The main drawback of the anchor policy is bandwidth efficiency. Because 4180 the checkpoint history covers the entire stream, the size of the 4181 recovery journals produced by this policy usually exceeds the journal 4182 size of alternative policies. For single-channel MIDI data streams, the 4183 bandwidth overhead of the anchor policy is often acceptable (see 4184 Appendix A.4 of [NMP]). For dense streams, the closed-loop or open-loop 4185 policies may be more appropriate. 4187 C.2.2.2 The closed-loop Sending Policy 4189 The closed-loop policy is the default policy of the recovery journal 4190 system. For each packet in the stream, the policy lets senders choose 4191 the smallest possible checkpoint history that satisfies the recovery 4192 journal mandate. As smaller checkpoint histories generally yield 4193 smaller recovery journals, the closed-loop policy reduces the bandwidth 4194 of a stream, relative to the anchor policy. 4196 The closed-loop policy relies on feedback from receiver to sender. The 4197 policy assumes that a receiver periodically informs the sender of the 4198 highest sequence number it has seen so far in the stream, coded in the 4199 32-bit extension format defined in [RFC3550]. For RTCP, receivers 4200 transmit this information in the Extended Highest Sequence Number 4201 Received (EHSNR) field of Receiver Reports. RTCP Sender or Receiver 4202 Reports MUST be sent by any participant in a session with closed loop 4203 sending policy, unless another feedback mechanism has been agreed upon. 4205 The sender may safely use receiver sequence number feedback to guide 4206 checkpoint history management, because Section 4 requires receivers to 4207 repair indefinite artifacts whenever a packet loss event occur. 4209 We now normatively define the closed-loop policy. At the moment a 4210 sender prepares an RTP packet for transmission, the sender is aware of R 4211 >= 0 receivers for the stream. Senders may become aware of a receiver 4212 via RTCP traffic from the receiver, via RTP packets from a paired stream 4213 sent by the receiver to the sender, via messages from a session 4214 management tool, or by other means. As receivers join and leave a 4215 session, the value of R changes. 4217 Each known receiver k (1 <= k <= R) is associated with a 32-bit extended 4218 packet sequence number M(k), where the extension reflects the sequence 4219 number rollover count of the sender. 4221 If the sender has received at least one feedback report from receiver k, 4222 M(k) is the most recent report of the highest RTP packet sequence number 4223 seen by the receiver, normalized to reflect the rollover count of the 4224 sender. 4226 If the sender has not received a feedback report from the receiver, M(k) 4227 is the extended sequence number of the last packet the sender 4228 transmitted before it became aware of the receiver. If the sender 4229 became aware of this receiver before it sent the first packet in the 4230 stream, M(k) is the extended sequence number of the first packet in the 4231 stream. 4233 Given this definition of M(), we now state the closed-loop policy. When 4234 preparing a new packet for transmission, a sender MUST choose a 4235 checkpoint packet with extended sequence number N, such that M(k) >= (N 4236 - 1) for all k, 1 <= k <= R, where R >= 1. The policy does not restrict 4237 sender behavior in the R == 0 (no known receivers) case. 4239 Under the closed-loop policy as defined above, a sender may transmit 4240 packets whose checkpoint history is shorter than the session history (as 4241 defined in Appendix A.1). In this event, a new receiver that joins the 4242 stream may experience indefinite artifacts. 4244 For example, if a Control Change (0xB) command for Channel Volume 4245 (controller number 7) was sent early in a stream, and later a new 4246 receiver joins the session, the closed-loop policy may permit all 4247 packets sent to the new receiver to use a checkpoint history that does 4248 not include the Channel Volume Control Change command. As a result, the 4249 new receiver experiences an indefinite artifact, and play all notes on a 4250 channel too loudly or too softly. 4252 To address this issue, the closed-loop policy states that whenever a 4253 sender becomes aware of a new receiver, the sender MUST determine if the 4254 receiver would be subject to indefinite artifacts under the closed-loop 4255 policy. If so, the sender MUST ensure that the receiver starts the 4256 session free of indefinite artifacts. For example, to solve the Channel 4257 Volume issue described above, the sender may code the current state of 4258 the Channel Volume controller numbers in the recovery journal Chapter C, 4259 until it receives the first RTCP RR report that signals that a packet 4260 containing this Chapter C has been received. 4262 In satisfying this requirement, senders MAY infer the initial MIDI state 4263 of the receiver from the session description. For example, the stream 4264 example in Section 6.2 has the initial state defined in [MIDI] for 4265 General MIDI. 4267 In a unicast RTP session, a receiver may safely assume that the sender 4268 is aware of its presence of a receiver from the first packet sent in the 4269 RTP stream. However, in other types of RTP sessions (multicast, 4270 conference focus, RTP translator/mixer), a receiver is often not able to 4271 determine if the sender is initially aware of its presence as a 4272 receiver. 4274 To address this issue, the closed-loop policy states that if a receiver 4275 participates in a session where it may have access to a stream whose 4276 sender is not aware of the receiver, the receiver MUST take actions to 4277 ensure that its rendered MIDI performance does not contain indefinite 4278 artifacts. These protections will be necessarily incomplete. For 4279 example, a receiver may monitor the Checkpoint Packet Seqnum for 4280 uncovered loss events, and "err on the side of caution" with respect to 4281 handling stuck notes due to lost MIDI NoteOff commands, but the receiver 4282 is not able to compensate for the lack of Channel Volume initialization 4283 data in the recovery journal. 4285 The receiver MUST NOT discontinue these protective actions until it is 4286 certain that the sender is aware of its presence. If a receiver is not 4287 able to ascertain sender awareness, the receiver MUST continue these 4288 protective actions for the duration of the session. 4290 Note that in a multicast session where all parties are expected to send 4291 and receive, the reception of RTCP receiver reports from the sender 4292 about the RTP stream a receiver is multicasting is evidence of sender 4293 awareness that the RTP stream multicast by the sender is being monitored 4294 by the receiver. Receivers may also obtain sender awareness evidence 4295 from session management tools, or by other means. In practice, ongoing 4296 observation of the Checkpoint Packet Seqnum to determine if the sender 4297 is taking actions to prevent loss events for a receiver is a good 4298 indication of sender awareness, as is the sudden appearance of recovery 4299 journal chapters with numerous Control Change controller data that was 4300 not foreshadowed by recent commands coded in the MIDI list shortly after 4301 sending an RTCP RR. 4303 The final set of normative closed-loop policy requirements concern how 4304 senders and receivers handle unplanned disruptions of RTCP feedback from 4305 a receiver to a sender. By "unplanned", we refer to disruptions that 4306 are not due to the signalled termination of an RTP stream, via an RTCP 4307 BYE or via session management tools. 4309 As defined earlier in this section, the closed-loop policy states that a 4310 sender MUST choose a checkpoint packet with extended sequence number N, 4311 such that M(k) >= (N - 1) for all k, 1 <= k <= R, where R >= 1. If the 4312 sender has received at least one feedback report from receiver k, M(k) 4313 is the most recent report of the highest RTP packet sequence number seen 4314 by the receiver, normalized to reflect the rollover count of the sender. 4316 If this receiver k stops sending feedback to the sender, the M(k) value 4317 used by the sender reflects the last feedback report from the receiver. 4318 As time progresses without feedback from receiver k, this fixed M(k) 4319 value forces the sender to increase the size of the checkpoint history, 4320 and thus increases the bandwidth of the stream. 4322 At some point, the sender may need to take action in order to limit the 4323 bandwidth of the stream. In most envisioned uses of RTP MIDI, long 4324 before this point is reached, the SSRC time-out mechanism defined in 4325 [RFC3550] will remove the uncooperative receiver from the session (note 4326 that the closed-loop policy does not suggest or require any special 4327 sender behavior upon an SSRC time-out, other than the sender actions 4328 related to changing R described earlier in this section). 4330 However, in rare situations, the bandwidth of the stream (due to a lack 4331 of feedback reports from the sender) may become too large to continue 4332 sending the stream to the receiver before the SSRC time-out occurs for 4333 the receiver. In this case, the closed-loop policy states that the 4334 sender should invoke the SSRC time-out for the receiver early. 4336 We now discuss receiver responsibilities in the case of unplanned 4337 disruptions of RTCP feedback from receiver to sender. 4339 In the unicast case, if a sender invokes the SSRC time-out mechanism for 4340 a receiver, the receiver stops receiving packets from the sender. The 4341 sender behavior imposed by the guardtime parameter (Appendix C.4.2) lets 4342 the receiver conclude a SSRC time-out has occurred in a reasonable time 4343 period. 4345 In this case of a time-out, a receiver MUST keep sending RTCP feedback, 4346 in order to re-establish the RTP flow from the sender. Unless the 4347 receiver expects a prompt recovery of the RTP flow, the receiver MUST 4348 take actions to ensure that the rendered MIDI performance does not 4349 exhibit "very long transient artifacts" (for example, by silencing 4350 NoteOns to prevent stuck notes) while awaiting reconnection of the flow. 4352 In the multicast case, if a sender invokes the SSRC time-out mechanism 4353 for a receiver, the receiver may continue to receive packets, but the 4354 sender will no longer being using the M(k) feedback from the receiver to 4355 choose each checkpoint packet. If the receiver does not have additional 4356 information that precludes an SSRC time-out (such as RTCP Receiver 4357 Reports from the sender about an RTP stream the receiver is multicasting 4358 back to the sender), the receiver MUST monitor the Checkpoint Packet 4359 Seqnum to detect an SSRC time-out. If an SSRC time-out is detected, the 4360 receiver MUST follow the instructions for SSRC time-outs described for 4361 the unicast case above. 4363 Finally, we note that the closed-loop policy is suitable for use in 4364 RTP/RTCP sessions that use multicast transport. However, aspects of the 4365 closed-loop policy do not scale well to sessions with large numbers of 4366 participants. The sender state scales linearly with the number of 4367 receivers, as the sender needs to track the identity and M(k) value for 4368 each receiver k. The average recovery journal size is not independent 4369 of the number of receivers, as the RTCP reporting interval backoff slows 4370 down the rate of a full update of M(k) values. The backoff algorithm 4371 may also increase the amount of ancillary state used by implementations 4372 of the normative sender and receiver behaviors defined in Section 4. 4374 C.2.2.3 The open-loop Sending Policy 4376 The open-loop policy is suitable for sessions that are not able to 4377 implement the receiver-to-sender feedback required by the closed-loop 4378 policy, and are also not able to use the anchor policy because of 4379 bandwidth constraints. 4381 The open-loop policy does not place constraints on how a sender chooses 4382 the checkpoint packet for each packet in the stream. In the absence of 4383 such constraints, a receiver may find that the recovery journal in the 4384 packet that ends a loss event has a checkpoint history that does not 4385 cover the entire loss event. We refer to loss events of this type as 4386 uncovered loss events. 4388 To ensure that uncovered loss events do not compromise the recovery 4389 journal mandate, the open-loop policy assigns specific recovery tasks to 4390 senders, receivers, and the creators of session descriptions. The 4391 underlying premise of the open-loop policy is that the indefinite 4392 artifacts produces during uncovered loss events fall into two classes. 4394 One class of artifacts are recoverable indefinite artifacts. Receivers 4395 are able to repair recoverable artifacts that occur during an uncovered 4396 loss event without intervention from the sender, at the potential cost 4397 of unpleasant transient artifacts. 4399 For example, after an uncovered loss event, receivers are able to repair 4400 indefinite artifacts due to NoteOff (0x8) commands that may have 4401 occurred during the loss event, by executing NoteOff commands for all 4402 active NoteOns commands. This action causes a transient artifacts (a 4403 sudden silent period in the performance), but ensures that no stuck 4404 notes sound indefinitely. We refer to MIDI commands that are amenable 4405 to repair in this fashion as recoverable MIDI commands. 4407 A second class of artifacts are unrecoverable indefinite artifacts. If 4408 this class of artifact occurs during an uncovered loss event, the 4409 receiver is not able to repair the stream. 4411 For example, after an uncovered loss event, receivers are not able to 4412 repair indefinite artifacts due to Control Change (0xB) Channel Volume 4413 (controller number 7) commands that have occurred during the loss event. 4414 A repair is impossible because the receiver has no way of determining 4415 the data value of a lost Channel Volume command. We refer to MIDI 4416 commands that are fragile in this way as unrecoverable MIDI commands. 4418 The open-loop policy does not specify how to partition the MIDI command 4419 set into recoverable and unrecoverable commands. Instead, it assumes 4420 that the creators of the session descriptions are able to come to 4421 agreement on a suitable recoverable/unrecoverable MIDI command partition 4422 for an application. 4424 Given these definitions, we now state the normative requirements for the 4425 open-loop policy. 4427 In the open-loop policy, the creators of the session description MUST 4428 use the ch_anchor parameter (defined in Appendix C.2.3) to protect all 4429 unrecoverable MIDI command types from indefinite artifacts, or 4430 alternatively MUST use the cm_unused parameter (defined in Appendix C.1) 4431 to exclude the command types from the stream. These options act to 4432 shield command types from artifacts during an uncovered loss event. 4434 In the open-loop policy, receivers MUST examine the Checkpoint Packet 4435 Seqnum field of the recovery journal header after every loss event, to 4436 check if the loss event is an uncovered loss event. Section 5 shows how 4437 to perform this check. If an uncovered loss event has occurred, a 4438 receiver MUST perform indefinite artifact recovery for all MIDI command 4439 types that are not shielded by ch_anchor and cm_unused parameter 4440 assignments in the session description. 4442 The open-loop policy does not place specific constraints on the sender. 4443 However, the open-loop policy works best if the sender manages the size 4444 of the checkpoint history to ensure that uncovered losses occur 4445 infrequently, by taking into account the delay and loss characteristics 4446 of the network. Also, as each checkpoint packet change incurs the risk 4447 of an uncovered loss, senders should only move the checkpoint if it 4448 reduces the size of the journal. 4450 C.2.3 Recovery Journal Chapter Inclusion Parameters 4452 The recovery journal chapter definitions (Appendices A-B) specify under 4453 what conditions a chapter MUST appear in the recovery journal. In most 4454 cases, the definition states that if a certain command appears in the 4455 checkpoint history, a certain chapter type MUST appear in the recovery 4456 journal to protect the command. 4458 In this section, we describe the chapter inclusion parameters. These 4459 parameters modify the conditions under which a chapter appears the 4460 journal. These parameters are essential to the use of the open-loop 4461 policy (Appendix C.2.2.3), and may also be used to simplify 4462 implementations of the closed-loop (Appendix C.2.2.2) and anchor 4463 (Appendix C.2.2.1) policies. 4465 Each parameter represents a type of chapter inclusion semantics. An 4466 assignment to a parameter declares which chapters (or chapter subsets) 4467 obey the inclusion semantics. We describe the assignment syntax for 4468 these parameters later in this section. 4470 A party MUST NOT accept chapter inclusion parameter values that violate 4471 the recovery journal mandate (Section 4). All assignments of the 4472 subsetting parameters (cm_used and cm_unused) MUST precede the first 4473 assignment of a chapter inclusion parameter in the parameter list. 4475 Below, we normatively define the semantics of the chapter inclusion 4476 parameters. For clarity, we define the action of parameters on complete 4477 chapters. If a parameter is assigned a subset of a chapter, the 4478 definition applies only to the chapter subset. 4480 o ch_never. A chapter assigned to the ch_never parameter MUST 4481 NOT appear in the recovery journal (Appendix A.4.1-2 defines 4482 exceptions to this rule for Chapter M). To signal the exclusion 4483 of a chapter from the journal, an assignment to ch_never MUST 4484 be made, even if the commands coded by the chapter are assigned 4485 to cm_unused. This rule simplifies the handling of commands 4486 types that may be coded in several chapters. 4488 o ch_default. A chapter assigned to the ch_default parameter 4489 MUST follow the default semantics for the chapter, as defined 4490 in Appendices A-B. 4492 o ch_anchor. A chapter assigned to the ch_anchor MUST obey a 4493 modified version of the default chapter semantics. In the 4494 modified semantics, all references to the checkpoint history 4495 are replaced with references to the session history, and all 4496 references to the checkpoint packet are replaced with 4497 references to the first packet sent in the stream. 4499 Parameter assignments obey the following syntax (see Appendix D for 4500 ABNF): 4502 = [channel list][field list] 4504 The chapter list is mandatory; the channel and field lists are optional. 4505 Multiple assignments to parameters have a cumulative effect, and are 4506 applied in the order of parameter appearance in a media description. 4508 To determine the semantics of a list of chapter inclusion parameter 4509 assignments, we begin by assuming an implicit assignment of all channel 4510 and system chapters to the ch_default parameter, with the default values 4511 for the channel list and field list for each chapter that are defined 4512 below. 4514 We then interpret the semantics of the actual parameter assignments, 4515 using the rules below. 4517 A later assignment of a chapter to the same parameter expands the scope 4518 of the earlier assignment. In most cases, a later assignment of a 4519 chapter to a different parameter cancels (partially or completely) the 4520 effect of an earlier assignment. 4522 The chapter list specifies the channel or system chapters for which the 4523 parameter applies. The chapter list is a concatenated sequence of one 4524 or more of the letters corresponding to the chapter types 4525 (ACDEFMNPQTVWX). In addition, the list may contain one or more of the 4526 letters for the sub-chapter types (BGHJKYZ) of System Chapter D. 4528 The letters in a chapter list MUST be upper case, and MUST appear in 4529 alphabetical order. Letters other than (ABCDEFGHJKMNPQTVWXYZ) that 4530 appear in the chapter list MUST be ignored. 4532 The channel list specifies the channel journals for which this parameter 4533 applies; if no channel list is provided, the parameter applies to all 4534 channel journals. The channel list takes the form of a list of channel 4535 numbers (0 through 15) and dash-separated channel number ranges (i.e. 4536 0-5, 8-12, etc). Dots (i.e. "." characters) separate elements in the 4537 channel list. 4539 Several of the systems chapters may be configured to have special 4540 semantics. Configuration occurs by specifying a channel list for the 4541 systems channel, using the coding described below (note that MIDI 4542 Systems commands do not have a "channel", and thus the original purpose 4543 of the channel list does not apply to systems chapters). The expression 4544 "the digit N" in the text below refers to the inclusion of N as a 4545 "channel" in the channel list for a systems chapter. 4547 For the J and K Chapter D sub-chapters (undefined System Common), the 4548 digit 0 codes that the parameter applies to the LEGAL field of the 4549 associated command log (Figure B.1.4 of Appendix B.1), the digit 1 codes 4550 that the parameter applies to the VALUE field of the command log, and 4551 the digit 2 codes that the parameter applies to the COUNT field of the 4552 command log. 4554 For the Y and Z Chapter D sub-chapters (undefined System Real-time), the 4555 digit 0 codes that the parameter applies to the LEGAL field of the 4556 associated command log (Figure B.1.5 of Appendix B.1) and the digit 1 4557 codes that the parameter applies to the COUNT field of the command log. 4559 For Chapter Q (Sequencer State Commands), the digit 0 codes that the 4560 parameter applies to the default Chapter Q definition, which forbids the 4561 TIME field. The digit 1 codes that the parameter applies to the 4562 optional Chapter Q definition, which supports the TIME field. 4564 The syntax for field lists follows the syntax for channel lists. If no 4565 field list is provided, the parameter applies to all controller or note 4566 numbers. For Chapter C, if no field list is provided, the controller 4567 numbers do not use enhanced Chapter C encoding (Appendix A.3.3). 4569 For Chapter C, the field list may take on values in the range 0 to 255. 4570 A field value X in the range 0-127 refers to a controller number X, and 4571 indicates that the controller number does not use enhanced Chapter C 4572 encoding. A field value X in the range 128-255 refers to a controller 4573 number "X minus 128", and indicates the controller number does use the 4574 enhanced Chapter C encoding. 4576 Assignments made to configure the Chapter C encoding method for a 4577 controller number MUST be made to the ch_default or ch_anchor 4578 parameters, as assignments to ch_never act to exclude the number from 4579 the recovery journal (and thus, the indicated encoding method is 4580 irrelevant). 4582 A Chapter C field list MUST NOT encode conflicting information about the 4583 enhanced encoding status of a particular controller number. For 4584 example, values 0 and 128 MUST NOT both be coded by a field list. 4586 For Chapter M, the field list codes the Registered Parameter Numbers 4587 (RPNs) and Non-Registered Parameter Numbers (NRPNs) for which the 4588 parameter applies. The number range 0-16383 specifies RPNs, the number 4589 range 16384-32767 specifies NRPNs (16384 corresponds to NRPN 0, 32767 4590 corresponds to NRPN 16383). 4592 For Chapters N and A, the field list codes the note numbers for which 4593 the parameter applies. The note number range specified for Chapter N 4594 also applies to Chapter E. 4596 For Chapter E, the digit 0 codes that the parameter applies to Chapter E 4597 note logs whose V bit is set to 0, the digit 1 codes that the parameter 4598 applies to note logs whose V bit is set to 1. 4600 For Chapter X, the field list codes the number of data octets that may 4601 appear in a SysEx command that is coded in the chapter. Thus, the field 4602 list 0-255 specifies SysEx commands with 255 or fewer data octets, the 4603 field list 256-429496729 specifies SysEx commands with more than 255 4604 data octets but excludes commands with 255 or fewer data octets, and the 4605 field list 0 excludes all commands. 4607 A secondary parameter assignment syntax customizes Chapter X (see 4608 Appendix D for complete ABNF): 4610 = "__" ["_" ] "__" 4612 The assignment defines a class of SysEx commands whose Chapter X coding 4613 obeys the semantics of the assigned parameter. The command class is 4614 specified by listing the permitted values of the first N data octets 4615 that follow the SysEx 0xF0 command octet. Any SysEx command whose first 4616 N data octets match the list is a member of the class. 4618 Each defines a data octet of the command, as a dot-separated 4619 (".") list of one or more hexadecimal constants (such as "7F") or dash- 4620 separated hexadecimal ranges (such as "01-1F"). Underscores ("_") 4621 separate each . Double-underscores ("__") delineate the data 4622 octet list. 4624 Using this syntax, each assignment specifies a single SysEx command 4625 class. Session descriptions may use several assignments to the same (or 4626 different) parameters to specify complex Chapter X behaviors. The 4627 ordering behavior of multiple assignments follows the guidelines for 4628 chapter parameter assignments described earlier in this section. 4630 The example session description below illustrates the use of the chapter 4631 inclusion parameters: 4633 v=0 4634 o=lazzaro 2520644554 2838152170 IN IP6 first.example.net 4635 s=Example 4636 t=0 0 4637 m=audio 5004 RTP/AVP 96 4638 c=IN IP6 2001:DB80::7F2E:172A:1E24 4639 a=rtpmap:96 rtp-midi/44100 4640 a=fmtp:96 j_update=open-loop; cm_unused=ABCFGHJKMQTVWXYZ; 4641 cm_used=__7E_00-7F_09_01.02.03__; 4642 cm_used=__7F_00-7F_04_01.02__; cm_used=C7.64; 4643 ch_never=ABCDEFGHJKMQTVWXYZ; ch_never=4.11-13N; 4644 ch_anchor=P; ch_anchor=C7.64; 4645 ch_anchor=__7E_00-7F_09_01.02.03__; 4646 ch_anchor=__7F_00-7F_04_01.02__ 4648 (The a=fmtp line has been wrapped to fit the page to accommodate 4649 memo formatting restrictions; it comprises a single line in SDP) 4651 The j_update parameter codes that the stream uses the open-loop policy. 4652 Most MIDI command-types are assigned to cm_unused and thus do not appear 4653 in the stream. As a consequence, the assignments to the first ch_never 4654 parameter reflect that most chapters are not in use. 4656 Chapter N for several MIDI channels is assigned to ch_never. Chapter N 4657 for MIDI channels other than 4, 11, 12, and 13 may appear in the 4658 recovery journal, using the (default) ch_default semantics. In 4659 practice, this assignment pattern would reflect knowledge about a 4660 resilient rendering method in use for the excluded channels. 4662 The MIDI Program Change command and several MIDI Control Change 4663 controller numbers are assigned to ch_anchor. Note that the ordering of 4664 the ch_anchor chapter C assignment after the ch_never command acts to 4665 override the ch_never assignment for the listed controller numbers (7 4666 and 64). 4668 The assignment of command-type X to cm_unused excludes most SysEx 4669 commands from the stream. Exceptions are made for General MIDI System 4670 On/Off commands and for the Master Volume and Balance commands, via the 4671 use of the secondary assignment syntax. The cm_used assignment codes 4672 the exception, and the ch_anchor assignment codes how these commands are 4673 protected in Chapter X. 4675 C.3 Configuration Tools: Timestamp Semantics 4677 The MIDI command section of the payload format consists of a list of 4678 commands, each with an associated timestamp. The semantics of command 4679 timestamps may be set during session configuration, using the parameters 4680 we describe in this section 4682 The parameter "tsmode" specifies the timestamp semantics for a stream. 4683 The parameter takes on one of three token values: "comex", "async", or 4684 "buffer". 4686 The default "comex" value specifies that timestamps code the execution 4687 time for a command (Appendix C.3.1), and supports the accurate 4688 transcoding Standard MIDI Files (SMFs, [MIDI]). The "comex" value is 4689 also RECOMMENDED for new MIDI user-interface controller designs. The 4690 "async" value specifies an asynchronous timestamp sampling algorithm for 4691 time-of-arrival sources (Appendix C.3.2). The "buffer" value specifies 4692 a synchronous timestamp sampling algorithm (Appendix C.3.3) for time-of- 4693 arrival sources. 4695 Ancillary parameters MAY follow tsmode in a media description. We 4696 define these parameters in Appendices C.3.2-3 below. 4698 C.3.1 The comex Algorithm 4700 The default "comex" (COMmand EXecution) tsmode value specifies the 4701 execution time for the command. With comex, the difference between two 4702 timestamps indicates the time delay between the execution of the 4703 commands. This difference may be zero, coding simultaneous execution. 4705 The comex interpretation of timestamps works well for transcoding a 4706 Standard MIDI File (SMF, [MIDI]) into an RTP MIDI stream, as SMFs code a 4707 timestamp for each MIDI command stored in the file. To transcode an SMF 4708 that uses metric time markers, use the SMF tempo map (encoded in the SMF 4709 as meta-events) to convert metric SMF timestamp units into seconds-based 4710 RTP timestamp units. 4712 New MIDI controller designs (piano keyboard, drum pads, etc) that 4713 support RTP MIDI and that have direct access to sensor data SHOULD use 4714 comex interpretation for timestamps, so that simultaneous gestural 4715 events may be accurately coded by RTP MIDI. 4717 Comex is a poor choice for transcoding MIDI 1.0 DIN cables [MIDI], for a 4718 reason that we now explain. A MIDI DIN cable is an asynchronous serial 4719 protocol (320 microseconds per MIDI byte). MIDI commands on a DIN cable 4720 are not tagged with timestamps. Instead, MIDI DIN receivers infer 4721 command timing from the time of arrival of the bytes. Thus, two two- 4722 byte MIDI commands that occur at a source simultaneously are encoded on 4723 a MIDI 1.0 DIN cable with a 640 microsecond time offset. A MIDI DIN 4724 receiver is unable to tell if this time offset existed in the source 4725 performance, or is an artifact of the serial speed of the cable. 4726 However, the RTP MIDI comex interpretation of timestamps declares that a 4727 timestamp offset between two commands reflects the timing of the source 4728 performance. 4730 This semantic mismatch is the reason that comex is a poor choice for 4731 transcoding MIDI DIN cables. Note that the choice of the RTP timestamp 4732 rate (Section 6.1-2 in the main text) cannot fix this inaccuracy issue. 4733 In the sections that follow, we describe two alternative timestamp 4734 interpretations ("async" and "buffer") that are a better match to MIDI 4735 1.0 DIN cable timing, and to other MIDI time-of-arrival sources. 4737 The "octpos", "linerate", and "mperiod" ancillary parameters (defined 4738 below) SHOULD NOT be used with comex. 4740 C.3.2 The async Algorithm 4742 The "async" tsmode value specifies the asynchronous sampling of a MIDI 4743 time-of-arrival source. In asynchronous sampling, the moment an octet 4744 is received from a source it is labelled with a wall-clock time value. 4745 The time value has RTP timestamp units. 4747 The "octpos" ancillary parameter defines how RTP command timestamps are 4748 derived from octet time values. If octpos has the token value "first", 4749 a timestamp codes the time value of the first octet of the command. If 4750 octpos has the token value "last", a timestamp codes the time value of 4751 the last octet of the command. If the octpos parameter does not appear 4752 in the media description, the sender does not know the which octet of 4753 the command the timestamp references (for example, the sender may be 4754 relying on an operating system service that does not specify this 4755 information). 4757 The octpos semantics refer to the first or last octet of a command as it 4758 appears on a time-of-arrival MIDI source, not as it appears in an RTP 4759 MIDI packet. This distinction is significant because the RTP coding may 4760 contain octets that are not present in the source. For example, the 4761 status octet of the first MIDI command in a packet may have been added 4762 to the MIDI stream during transcoding, to comply with the RTP MIDI 4763 running status requirements (Section 3.2). 4765 The "linerate" ancillary parameter defines the timespan of one MIDI 4766 octet on the transmission medium of the MIDI source to be sampled (such 4767 as a MIDI 1.0 DIN cable). The parameter has units of nanoseconds, and 4768 takes on integral values. For MIDI 1.0 DIN cables, the correct linerate 4769 value is 320000 (this value is also the default value for the 4770 parameter). 4772 We now show a session description example for the async algorithm. 4773 Consider a sender that is transcoding a MIDI 1.0 DIN cable source into 4774 RTP. The sender runs on a computing platform that assigns time values 4775 to every incoming octet of the source, and the sender uses the time 4776 values to label the first octet of each command in the RTP packet. This 4777 session description describes the transcoding: 4779 v=0 4780 o=lazzaro 2520644554 2838152170 IN IP4 first.example.net 4781 s=Example 4782 t=0 0 4783 m=audio 5004 RTP/AVP 96 4784 c=IN IP4 192.0.2.94 4785 a=rtpmap:96 rtp-midi/44100 4786 a=sendonly 4787 a=fmtp:96 tsmode=async; linerate=320000; octpos=first 4789 C.3.3 The buffer Algorithm 4791 The "buffer" tsmode value specifies the synchronous sampling of a MIDI 4792 time-of-arrival source. 4794 In synchronous sampling, octets received from a source are placed in a 4795 holding buffer upon arrival. At periodic intervals, the RTP sender 4796 examines the buffer. The sender removes complete commands from the 4797 buffer, and codes those commands in an RTP packet. The command 4798 timestamp codes the moment of buffer examination, expressed in RTP 4799 timestamp units. Note that several commands may have the same timestamp 4800 value. 4802 The "mperiod" ancillary parameter defines the nominal periodic sampling 4803 interval. The parameter takes on positive integral values, and has RTP 4804 timestamp units. 4806 The "octpos" ancillary parameter, defined in Appendix C.3.1 for 4807 asynchronous sampling, plays a different role in synchronous sampling. 4808 In synchronous sampling, the parameter specifies the timestamp semantics 4809 of a command whose octets span several sampling periods. 4811 If octpos has the token value "first", the timestamp reflects the 4812 arrival period of the first octet of the command. If octpos has the 4813 token value "last", the timestamp reflects the arrival period of the 4814 last octet of the command. The octpos semantics refer to the first or 4815 last octet of the command as it appears on a time-of-arrival source, not 4816 as it appears in the RTP packet. 4818 If the octpos parameter does not appear in the media description, the 4819 timestamp MAY reflect the arrival period of any octet of the command -- 4820 senders use this option to signal a lack of knowledge about the timing 4821 details of the buffering process at sub-command granularity. 4823 We now show a session description example for the buffer algorithm. 4824 Consider a sender that is transcoding a MIDI 1.0 DIN cable source into 4825 RTP. The sender runs on a computing platform that places source data 4826 into a buffer upon receipt. The sender polls the buffer 1000 times a 4827 second, extracts all complete commands from the buffer, and places the 4828 commands in an RTP packet. This session description describes the 4829 transcoding: 4831 v=0 4832 o=lazzaro 2520644554 2838152170 IN IP6 first.example.net 4833 s=Example 4834 t=0 0 4835 m=audio 5004 RTP/AVP 96 4836 c=IN IP6 2001:DB80::7F2E:172A:1E24 4837 a=rtpmap:96 rtp-midi/44100 4838 a=sendonly 4839 a=fmtp:96 tsmode=buffer; linerate=320000; octpos=last; mperiod=44 4841 The mperiod value of 44 is derived by dividing the clock rate specified 4842 by the rtpmap attribute (44100 Hz) by the 1000 Hz buffer sampling rate, 4843 and rounding to the nearest integer. Command timestamps might not 4844 increment by exact multiples of 44, as the actual sampling period might 4845 not precisely match the nominal mperiod value. 4847 C.4 Configuration Tools: Packet Timing Tools 4849 In this Appendix, we describe session configuration tools for 4850 customizing the temporal behavior of MIDI stream packets. 4852 C.4.1 Packet Duration Tools 4854 Senders control the granularity of a stream by setting the temporal 4855 duration ("media time") of the packets in the stream. Short media times 4856 (20 ms or less) often imply an interactive session. Longer media times 4857 (100 ms or more) usually indicate a content streaming session. The RTP 4858 AVP profile [RFC3551] recommends audio packet media times in a range 4859 from 0 to 200 ms. 4861 By default, an RTP receiver dynamically senses the media time of packets 4862 in a stream, and chooses the length of its playout buffer to match the 4863 stream. A receiver typically sizes its playout buffer to fit several 4864 audio packets, and adjusts the buffer length to reflect the network 4865 jitter and the sender timing fidelity. 4867 Alternatively, the packet media time may be statically set during 4868 session configuration. Session descriptions MAY use the RTP MIDI 4869 parameter "rtp_ptime" to set the recommended media time for a packet. 4870 Session descriptions MAY also use the RTP MIDI parameter "rtp_maxptime" 4871 to set the maximum media time for a packet permitted in a stream. Both 4872 parameters MAY be used together to configure a stream. 4874 The values assigned to the rtp_ptime and rtp_maxptime parameters have 4875 the units of the RTP timestamp for the stream, as set by the rtpmap 4876 attribute (see Section 6.1). Thus, if rtpmap sets the clock rate of a 4877 stream to 44100 Hz, a maximum packet media time of 10 ms is coded by 4878 setting rtp_maxptime=441. As stated in the Appendix C preamble, the 4879 senders and receivers of a stream MUST agree on common values for 4880 rtp_ptime and rtp_maxptime if the parameters appear in the media 4881 description for the stream. 4883 0 ms is a reasonable media time value for MIDI packets, and is often 4884 used in low-latency interactive applications. In a packet with a 0 ms 4885 media time, all commands execute at the instant coded by the packet 4886 timestamp. The session description below configures all packets in the 4887 stream to have 0 ms media time: 4889 v=0 4890 o=lazzaro 2520644554 2838152170 IN IP4 first.example.net 4891 s=Example 4892 t=0 0 4893 m=audio 5004 RTP/AVP 96 4894 c=IN IP4 192.0.2.94 4895 a=rtpmap:96 rtp-midi/44100 4896 a=fmtp:96 rtp_ptime=0; rtp_maxptime=0 4898 The session attributes ptime and maxptime [SDP] MUST NOT be used to 4899 configure an RTP MIDI stream. Sessions MUST use rtp_ptime in lieu of 4900 ptime, and MUST use rtp_maxptime in lieu of maxptime. RTP MIDI defines 4901 its own parameters for media time configuration because 0 ms values for 4902 ptime and maxptime are forbidden by [RFC3264], but are essential for 4903 certain applications of RTP MIDI. 4905 See the Appendix C.7 examples for additional discussion about using 4906 rtp_ptime and rtp_maxptime for session configuration. 4908 C.4.2 The guardtime Parameter 4910 RTP permits a sender to stop sending audio packets for an arbitrary 4911 period of time during a session. When sending resumes, the RTP sequence 4912 number series continues unbroken, and the RTP timestamp value reflects 4913 the media time silence gap. 4915 This RTP feature has its roots in telephony, but is also well matched to 4916 interactive MIDI sessions, as players may fall silent for several 4917 seconds during (or between) songs. 4919 Certain MIDI applications benefit from a slight enhancement to this RTP 4920 feature. In interactive applications, receivers may use on-line network 4921 models to guide heuristics for handling lost and late RTP packets. 4922 These models may work poorly if a sender ceases packet transmission for 4923 long periods of time. 4925 Session descriptions may use the parameter "guardtime" to set a minimum 4926 sending rate for a media session. The value assigned to guardtime codes 4927 the maximum separation time between two sequential packets, as expressed 4928 in RTP timestamp units. 4930 Typical guardtime values are 500-2000 ms. This value range is not a 4931 normative bound, and parties SHOULD be prepared to process values 4932 outside of this range. 4934 The congestion control requirements for sender implementations 4935 (described in Section 8 and [RFC3550]) take precedence over the 4936 guardtime parameter. Thus, if the guardtime parameter requests a 4937 minimum sending rate, but sending at this rate would violate the 4938 congestion control requirements, senders MUST ignore the guardtime 4939 parameter value. In this case, senders SHOULD use the lowest minimum 4940 sending rate that satisfies the congestion control requirements. 4942 Below, we show a session description that uses the guardtime parameter. 4944 v=0 4945 o=lazzaro 2520644554 2838152170 IN IP6 first.example.net 4946 s=Example 4947 t=0 0 4948 m=audio 5004 RTP/AVP 96 4949 c=IN IP6 2001:DB80::7F2E:172A:1E24 4950 a=rtpmap:96 rtp-midi/44100 4951 a=fmtp:96 guardtime=44100; rtp_ptime=0; rtp_maxptime=0 4952 C.5 Configuration Tools: Stream Description 4954 As we discussed in Section 2.1 in the main text, a party may send 4955 several RTP MIDI streams in the same RTP session, and several RTP 4956 sessions that carry MIDI may appear in a multimedia session. 4958 By default, the MIDI name space (16 channels + systems) of each RTP 4959 stream sent by a party in a multimedia session is independent. By 4960 independent, we mean three distinct things: 4962 o By independent, we mean that if a party sends two RTP MIDI 4963 streams (A and B), MIDI voice channel 0 in stream A is a 4964 different "channel 0" than MIDI voice channel 0 in stream B. 4966 o By independent, we mean that MIDI voice channel 0 in stream B 4967 is not considered to be "channel 16" of a 32-channel MIDI voice 4968 channel space whose "channel 0" is channel 0 of stream A. 4970 o By independent, we mean that streams sent by different parties 4971 over different RTP sessions, or that streams sent by different 4972 parties send over the same RTP session but with different 4973 payload type numbers, do not share the association that is 4974 shared by a MIDI cable pair that cross-connects two devices 4975 in a MIDI 1.0 DIN network. By default, this association is 4976 only held by streams sent by different parties in the same 4977 RTP session that use the same payload type number. 4979 In this Appendix, we show how to express that specific RTP MIDI streams 4980 in a multimedia session are not independent, but instead are related in 4981 one of the three ways defined above. We use two tools to express these 4982 relations: 4984 o The musicport parameter. This parameter is assigned a 4985 non-negative integer value between 0 and 429496729. It 4986 appears in the fmtp lines of payload types. 4988 o The FID grouping attribute [RFC3388] signals that several RTP 4989 sessions in a multimedia session are using the musicport 4990 parameter to express an inter-session relationship. 4992 If a multimedia session has several payload types whose musicport 4993 parameters are assigned the same integer value, streams using these 4994 payload types share an "identity relationship" (including streams that 4995 use the same payload type). Streams in an identity relationship share 4996 two properties: 4998 o Identity relationship streams sent by the same party 4999 target the same MIDI name space. Thus, if streams A 5000 and B share an identity relationship, voice channel 0 5001 in stream A is the same "channel 0" as voice channel 5002 0 in stream B. 5004 o Pairs of identity relationship streams that are sent by 5005 different parties share the association that is shared 5006 by a MIDI cable pair that cross-connects two devices in 5007 a MIDI 1.0 DIN network. 5009 A party MUST NOT send two RTP MIDI streams that share an identity 5010 relationship in the same RTP session. Instead, each stream MUST be in a 5011 separate RTP session. As explained in Section 2.1 in the main text, 5012 this restriction is necessary to support the RTP MIDI method for the 5013 synchronization of streams that share a MIDI name space. 5015 If a multimedia session has several payload types whose musicport 5016 parameters are assigned sequential values (i.e. i, i+1, ... i+k), the 5017 streams using the payload types share an "ordered relationship". For 5018 example, if payload type A assigns 2 to musicport and payload type B 5019 assigns 3 to musicport, A and B are in an ordered relationship. 5021 Streams in an ordered relationship that are sent by the same party are 5022 considered by renderers to form a single larger MIDI space. For 5023 example, if stream A has a musicport value of 2 and stream B has a 5024 musicport value of 3, MIDI voice channel 0 in stream B is considered to 5025 be voice channel 16 in the larger MIDI space formed by the relationship. 5026 Note that it is possible for streams to participate in both an identity 5027 relationship and an ordered relationship. 5029 We now state several rules for using musicport: 5031 o If streams from several RTP sessions in a multimedia 5032 session use the musicport parameter, the RTP sessions 5033 MUST be grouped using the FID grouping attribute 5034 defined in [RFC3388]. 5036 o An ordered or identity relationship MUST NOT 5037 contain both native RTP MIDI streams and 5038 mpeg4-generic RTP MIDI streams. An exception applies 5039 if a relationship consists of sendonly and recvonly 5040 (but not sendrecv) streams. In this case, the sendonly 5041 streams MUST NOT contain both types of streams, and the 5042 recvonly streams MUST NOT contain both types of streams. 5044 o It is possible to construct identity relationships 5045 that violate the recovery journal mandate (example: 5046 sending NoteOns for a voice channel on stream A and 5047 NoteOffs for the same voice channel on stream B). 5049 Parties MUST NOT generate (or accept) session 5050 descriptions that exhibit this flaw. 5052 o Other payload formats MAY define musicport media type 5053 parameters. Formats would define these parameters so that 5054 their sessions could be bundled into RTP MIDI name spaces. 5055 The parameter definitions MUST be compatible with the 5056 musicport semantics defined in this Appendix. 5058 As a rule, at most one payload type in a relationship may specify a MIDI 5059 renderer. An exception to the rule applies to relationships that 5060 contain sendonly and recvonly streams but no sendrecv streams. In this 5061 case, one sendonly session and one recvonly session may each define a 5062 renderer. 5064 Renderer specification in a relationship may be done using the tools 5065 described in Appendix C.6. These tools work for both native streams and 5066 mpeg4-generic streams. An mpeg4-generic stream that uses the Appendix 5067 C.6 tools MUST set all "config" parameters to the empty string (""). 5069 Alternatively, for mpeg4-generic streams, renderer specification may be 5070 done by setting one "config" parameter in the relationship to the 5071 renderer configuration string, and all other config parameters to the 5072 empty string (""). 5074 We now define sender and receiver rules that apply when a party sends 5075 several streams that target the same MIDI name space. 5077 Senders MAY use the subsetting parameters (Appendix C.1) to predefine 5078 the partitioning of commands between streams, or MAY use a dynamic 5079 partitioning strategy. 5081 Receivers that merge identity relationship streams into a single MIDI 5082 command stream MUST maintain the structural integrity of the MIDI 5083 commands coded in each stream during the merging process, in the same 5084 way that software that merges traditional MIDI 1.0 DIN cable flows is 5085 responsible for creating a merged command flow compatible with [MIDI]. 5087 Senders MUST partition the name space so that the rendered MIDI 5088 performance does not contain indefinite artifacts (as defined in Section 5089 4). This responsibility holds even if all streams are sent over 5090 reliable transport, as different stream latencies may yield indefinite 5091 artifacts. For example, stuck notes may occur in a performance split 5092 over two TCP streams, if NoteOn commands are sent on one stream and 5093 NoteOff commands are sent on the other. 5095 Senders MUST NOT split a Registered Parameter Name (RPN) or Non- 5096 Registered Parameter Name (NRPN) transaction appearing on a MIDI channel 5097 across multiple identity relationship sessions. Receivers MUST assume 5098 that the RPN/NRPN transactions that appear on different identity 5099 relationship sessions are independent, and MUST preserve transactional 5100 integrity during the MIDI merge. 5102 A simple way to safely partition voice channel commands is to place all 5103 MIDI commands for a particular voice channel into the same session. 5104 Safe partitioning of MIDI Systems commands may be more complicated for 5105 sessions that extensively use System Exclusive. 5107 We now show several session description examples that use the musicport 5108 parameter. 5110 Our first session description example shows two RTP MIDI streams that 5111 drive the same General MIDI decoder. The sender partitions MIDI 5112 commands between the streams dynamically. The musicport values indicate 5113 the streams share an identity relationship. 5115 v=0 5116 o=lazzaro 2520644554 2838152170 IN IP4 first.example.net 5117 s=Example 5118 t=0 0 5119 a=group:FID 1 2 5120 c=IN IP4 192.0.2.94 5121 m=audio 5004 RTP/AVP 96 5122 a=rtpmap:96 mpeg4-generic/44100 5123 a=mid:1 5124 a=fmtp:96 streamtype=5; mode=rtp-midi; profile-level-id=12; 5125 config=7A0A0000001A4D546864000000060000000100604D54726B0 5126 000000600FF2F000; musicport=12 5127 m=audio 5006 RTP/AVP 96 5128 a=rtpmap:96 mpeg4-generic/44100 5129 a=mid:2 5130 a=fmtp:96 streamtype=5; mode=rtp-midi; config=""; profile-level-id=12; 5131 musicport=12 5133 (The a=fmtp lines have been wrapped to fit the page to accommodate 5134 memo formatting restrictions; they comprise single lines in SDP) 5136 Recall that Section 2.1 in the main text defines rules for streams that 5137 target the same MIDI name space. Those rules, implemented in the 5138 example above, require that each stream resides in a separate RTP 5139 session, and that the grouping mechanisms defined in [RFC3388] signal an 5140 inter-session relationship. The "group" and "mid" attribute lines 5141 implement this grouping mechanism. 5143 A variant on this example, whose session description is not shown, would 5144 use two streams in an identity relationship driving the same MIDI 5145 renderer, each with a different transport type. One stream would use 5146 UDP, and would be dedicated to real-time messages. A second stream 5147 would use TCP [CONTRANS] and would be used for SysEx bulk data messages. 5149 In the next example, two mpeg4-generic streams form an ordered 5150 relationship to drive a Structured Audio decoder with 32 MIDI voice 5151 channels. Both streams reside in the same RTP session. 5153 v=0 5154 o=lazzaro 2520644554 2838152170 IN IP6 first.example.net 5155 s=Example 5156 t=0 0 5157 m=audio 5006 RTP/AVP 96 97 5158 c=IN IP6 2001:DB80::7F2E:172A:1E24 5159 a=rtpmap:96 mpeg4-generic/44100 5160 a=fmtp:96 streamtype=5; mode=rtp-midi; config=""; profile-level-id=13; 5161 musicport=5 5162 a=rtpmap:97 mpeg4-generic/44100 5163 a=fmtp:97 streamtype=5; mode=rtp-midi; config=""; profile-level-id=13; 5164 musicport=6; render=synthetic; rinit="audio/asc"; 5165 url="http://example.com/cardinal.asc"; 5166 cid="azsldkaslkdjqpwojdkmsldkfpe" 5168 (The a=fmtp lines have been wrapped to fit the page to accommodate 5169 memo formatting restrictions; they comprise single lines in SDP) 5171 The sequential musicport values for the two sessions establishes the 5172 ordered relationship. The musicport=5 session maps to Structured Audio 5173 extended channels range 0-15, the musicport=6 session maps to Structured 5174 Audio extended channels range 16-31. 5176 Both config strings are empty. The configuration data is specified by 5177 parameters that appear in the fmtp line of the second media description. 5178 We define this configuration method in Appendix C.6. 5180 The next example shows two RTP MIDI streams (one recvonly, one sendonly) 5181 that form a "virtual sendrecv" session. Each stream resides in a 5182 different RTP session (a requirement because sendonly and recvonly are 5183 RTP session attributes). 5185 v=0 5186 o=lazzaro 2520644554 2838152170 IN IP4 first.example.net 5187 s=Example 5188 t=0 0 5189 a=group:FID 1 2 5190 c=IN IP4 192.0.2.94 5191 m=audio 5004 RTP/AVP 96 5192 a=sendonly 5193 a=rtpmap:96 mpeg4-generic/44100 5194 a=mid:1 5195 a=fmtp:96 streamtype=5; mode=rtp-midi; profile-level-id=12; 5196 config=7A0A0000001A4D546864000000060000000100604D54726B0 5197 000000600FF2F000; musicport=12 5198 m=audio 5006 RTP/AVP 96 5199 a=recvonly 5200 a=rtpmap:96 mpeg4-generic/44100 5201 a=mid:2 5202 a=fmtp:96 streamtype=5; mode=rtp-midi; profile-level-id=12; 5203 config=7A0A0000001A4D546864000000060000000100604D54726B0 5204 000000600FF2F000; musicport=12 5206 (The a=fmtp lines have been wrapped to fit the page to accommodate 5207 memo formatting restrictions; they comprise single lines in SDP) 5209 To signal the "virtual sendrecv" semantics, the two streams assign 5210 musicport to the same value (12). As defined earlier in this section, 5211 pairs of identity relationship streams that are sent by different 5212 parties share the association that is shared by a MIDI cable pair that 5213 cross-connects two devices in a MIDI 1.0 network. We use the term 5214 "virtual sendrecv" because streams sent by different parties in a true 5215 sendrecv session also have this property. 5217 As discussed in the preamble to Appendix C, the primary advantage of the 5218 virtual sendrecv configuration is that each party can customize the 5219 property of the stream it receives. In the example above, each stream 5220 defines its own "config" string that could customize the rendering 5221 algorithm for each party (in fact, the particular strings shown in this 5222 example are identical, because General MIDI is not a configurable MPEG 4 5223 renderer). 5225 C.6 Configuration Tools: MIDI Rendering 5227 This Appendix defines the session configuration tools for rendering. 5229 The "render" parameter specifies a rendering method for a stream. The 5230 parameter is assigned a token value that signals the top-level rendering 5231 class. This memo defines four token values for render: "unknown", 5232 "synthetic", "api", and "null": 5234 o An "unknown" renderer is a renderer whose nature is unspecified. 5235 It is the default renderer for native RTP MIDI streams. 5237 o A "synthetic" renderer transforms the MIDI stream into audio 5238 output (or sometimes, into stage lighting changes or other 5239 actions). It is the default renderer for mpeg4-generic 5240 RTP MIDI streams. 5242 o An "api" renderer presents the command stream to applications 5243 via an Application Programmer Interface (API). 5245 o The "null" renderer discards the MIDI stream. 5247 The "null" render value plays special roles during Offer/Answer 5248 negotiations [RFC3264]. A party uses the "null" value in an answer to 5249 reject an offered renderer. Note that rejecting a renderer is 5250 independent from rejecting a payload type (coded by by removing the 5251 payload type from a media line) and rejecting a media stream (coded by 5252 zeroing the port of a media line that uses the renderer). 5254 Other render token values MAY be registered with IANA. The token value 5255 MUST adhere to the ABNF for render tokens defined in Appendix D. 5256 Registrations MUST include a complete specification of parameter value 5257 usage, similar in depth to the specifications that appear throughout 5258 Appendix C.6 for "synthetic" and "api" render values. If a party is 5259 offered a session description that uses a render token value that is not 5260 known to the party, the party MUST NOT accept the renderer. Options 5261 include rejecting the renderer (using the "null" value), the payload 5262 type, the media stream, or the session description. 5264 Other parameters MAY follow a render parameter in a parameter list. The 5265 additional parameters act to define the exact nature of the renderer. 5266 For example, the "subrender" parameter (defined in Appendix C.6.2) 5267 specifies the exact nature of the renderer. 5269 Special rules apply to using the render parameter in an mpeg4-generic 5270 stream. We define these rules in Appendix C.6.5. 5272 C.6.1 The multimode Parameter 5274 A media description MAY contain several render parameters. By default, 5275 if a parameter lists includes several render parameters, a receiver MUST 5276 choose exactly one renderer from the list to render the stream. The 5277 "multimode" parameter may be used to override this default. We define 5278 two token values for multimode: "one" and "all": 5280 o The default "one" value requests rendering by exactly one of 5281 the listed renderers. 5283 o The "all" value requests the synchronized rendering of the RTP 5284 MIDI stream by all listed renderers, if possible. 5286 If the multimode parameter appears in a parameter list, it MUST appear 5287 before the first render parameter assignment. 5289 Render parameters appear in the parameter list in order of decreasing 5290 priority. A receiver MAY use the priority ordering to decide which 5291 renderer(s) to retain in a session. 5293 If the "offer" in an Offer/Answer-style negotiation [RFC3264] contains a 5294 parameter list with one or more render parameters, the "answer" MUST set 5295 the render parameters of all unchosen renderers to "null". 5297 C.6.2 Renderer Specification 5299 The render parameter (Appendix C.6 preamble) specifies, in a broad 5300 sense, what a renderer does with a MIDI stream. In this Appendix, we 5301 describe the "subrender" parameter. The token value assigned to 5302 subrender defines the exact nature of the renderer. Thus, "render" and 5303 "subrender" combine to define a renderer, in the same way as MIME types 5304 and MIME subtypes combine to define a type of media [RFC2045]. 5306 If the subrender parameter is used for a renderer definition, it MUST 5307 appear immediately after the render parameter in the parameter list. At 5308 most one subrender parameter may appear in a renderer definition. 5310 This document defines one value for subrender: the value "default". The 5311 "default" token specifies the use of the the default renderer for the 5312 stream type (native or mpeg4-generic). The default renderer for native 5313 RTP MIDI streams is a renderer whose nature is unspecified (see point 6 5314 in Section 6.1 in the main text for details). The default renderer for 5315 mpeg4-generic RTP MIDI streams is an MPEG 4 Audio Object Type whose ID 5316 number is 13, 14, or 15 (see Section 6.2 in the main text for details). 5318 If a renderer definition does not use the subrender parameter, the value 5319 "default" is assumed for subrender. 5321 Other subrender token values may be registered with IANA. We now 5322 discuss guidelines for registering subrender values. 5324 A subrender value is registered for a specific stream type (native or 5325 mpeg4-generic) and a specific render value (excluding "null" and 5326 "unknown"). Registrations for mpeg4-generic subrender values are 5327 restricted to new MPEG 4 Audio Object Types that accept MIDI input. The 5328 syntax of the token MUST adhere to the token definition in Appendix D. 5330 For "render=synthetic" renderers, a subrender value registration 5331 specifies an exact method for transforming the MIDI stream into audio 5332 (or sometimes, into video or control actions, such as stage lighting). 5333 For standardized renderers, this specification is usually a pointer to a 5334 standards document, perhaps supplemented by RTP-MIDI specific 5335 information. For commercial products and open-source projects, this 5336 specification usually takes the form of instructions for interfacing the 5337 RTP MIDI stream with the product or project software. A 5338 "render=synthetic" registration MAY specify additional Reset State 5339 commands for the renderer (Appendix A.1). 5341 A "render=api" subrender value registration specifies how an RTP MIDI 5342 stream interfaces with an API (Application Programmers Interface). This 5343 specification is usually a pointer to programmer's documentation for the 5344 API, perhaps supplemented by RTP-MIDI specific information. 5346 A subrender registration MAY specify an initialization file (referred to 5347 in this document as an initialization data object) for the stream. The 5348 initialization data object MAY be encoded in the parameter list 5349 (verbatim or by reference) using the coding tools defined in Appendix 5350 C.6.3. An initialization data object MUST have a registered [MTYPE] 5351 media type and subtype [RFC2045]. 5353 For "render=synthetic" renderers, the data object usually encodes 5354 initialization data for the renderer (sample files, synthesis patch 5355 parameters, reverberation room impulse responses, etc). 5357 For "render=api" renderers, the data object usually encodes data about 5358 the stream used by the API (for example, for an RTP MIDI stream 5359 generated by a piano keyboard controller, the manufacturer and model 5360 number of the keyboard, for use in GUI presentation). 5362 Usually, only one initialization object is encoded for a renderer. If a 5363 renderer uses multiple data objects, the correct receiver interpretation 5364 of multiple data objects MUST be defined in the subrender registration. 5366 A subrender value registration may also specify additional parameters, 5367 to appear in the parameter list immediately after subrender. These 5368 parameter names MUST begin with the subrender value followed by an 5369 underscore ("_"), to avoid name space collisions with future RTP MIDI 5370 parameter names (example: a parameter "foo_bar" defined for subrender 5371 value "foo"). 5373 We now specify guidelines for interpreting the subrender parameter 5374 during session configuration. 5376 If a party is offered a session description that uses a renderer whose 5377 subrender value is not known to the party, the party MUST NOT accept the 5378 renderer. Options include rejecting the renderer (using the "null" 5379 value), the payload type, the media stream, or the session description. 5381 Receivers MUST be aware of the Reset State commands (Appendix A.1) for 5382 the renderer specified by the subrender parameter, and MUST insure that 5383 the renderer does not experience indefinite artifacts due to the 5384 presence (or the loss) of a Reset State command. 5386 C.6.3 Renderer Initialization 5388 If the renderer for a stream uses an initialization data object, an 5389 "rinit" parameter MUST appear in the parameter list immediately after 5390 the "subrender" parameter. If the renderer parameter list does not 5391 include a subrender parameter (recall the semantics for "default" in 5392 Appendix C.6.2), the "rinit" parameter MUST appear immediately after the 5393 "render" parameter. 5395 The value assigned to the rinit parameter MUST be the media type/subtype 5396 [RFC2045] for the initialization data object. If an initialization 5397 object type is registered with several media types, including audio, the 5398 assignment to rinit MUST use the audio media type. 5400 RTP MIDI supports several parameters for encoding initialization data 5401 objects for renderers in the parameter list: "inline", "url", and "cid". 5403 If the "inline", "url", and/or "cid" parameters are used by a renderer, 5404 these parameters MUST immediately follow the "rinit" parameter. 5406 If a "url" parameter appears for a renderer, an "inline" parameter MUST 5407 NOT appear. If an "inline" parameter appears for a renderer, a "url" 5408 parameter MUST NOT appear. However, neither "url" or "inline" are 5409 required to appear. If neither "url" or "inline" parameters follow 5410 "rinit", the "cid" parameter MUST follow "rinit". 5412 The "inline" parameter supports the inline encoding of the data object. 5413 The parameter is assigned a double-quoted Base64 [RFC2045] encoding of 5414 the binary data object, with no line breaks. Appendix E.4 shows an 5415 example that constructs an inline parameter value. 5417 The "url" parameter is assigned a double-quoted string representation of 5418 a Uniform Resource Locator (URL) for the data object. The string MUST 5419 specify a HyperText Transport Protocol URL (HTTP, [RFC2616]). HTTP MAY 5420 be used over TCP, or MAY be used over a secure network transport, such 5421 as the method described in [RFC2818]. The media type/subtype for the 5422 data object SHOULD be specified in the appropriate HTTP transport 5423 header. 5425 The "cid" parameter supports data object caching. The parameter is 5426 assigned a double-quoted string value that encodes a globally unique 5427 identifier for the data object. 5429 A cid parameter MAY immediately follow an inline parameter, in which 5430 case the cid identifier value MUST be associated with the inline data 5431 object. 5433 If a url parameter is present, and if the data object for the URL is 5434 expected to be unchanged for the life of the URL, a cid parameter MAY 5435 immediately follow the url parameter. The cid identifier value MUST be 5436 associated with the data object for the URL. A cid parameter assigned 5437 to the same identifier value SHOULD be specified following the data 5438 object type/subtype in the appropriate HTTP transport header. 5440 If a url parameter is present, and if the data object for the URL is 5441 expected to change during the life of the URL, a cid parameter MUST NOT 5442 follow the url parameter. A receiver interprets the presence of a cid 5443 parameter as an indication that it is safe use a cached copy of the url 5444 data object; the absence of a cid parameter is an indication that it is 5445 not safe to use a cached copy, as it may change. 5447 Finally, the cid parameter MAY be used without the inline and url 5448 parameters. In this case, the identifier references a local or 5449 distributed catalog of data objects. 5451 In most cases, only one data object is coded in the parameter list for 5452 each renderer. For example, the default renderer for mpeg4-generic 5453 streams uses a single data object (see Appendix C.6.5 for example 5454 usage). 5456 However, a subrender registration MAY permit the use of multiple data 5457 objects for a renderer. If multiple data objects are encoded for a 5458 renderer, each object encoding begins with an "rinit" parameter, 5459 followed by "inline", "url", and/or "cid" parameters. 5461 Initialization data object MAY encapsulate a Standard MIDI File (SMF). 5462 By default, the SMFs that are encapsulated in a data object MUST be 5463 ignored by an RTP MIDI receiver. We define parameters to override this 5464 default in Appendix C.6.4. 5466 To end this section, we offer guidelines for registering media types for 5467 initialization data objects. These guidelines are in addition to the 5468 information in [RFC2048]. 5470 Some initialization data objects are also capable of encoding MIDI note 5471 information, and thus complete audio performances. These objects SHOULD 5472 be registered using the "audio" media type, so that the objects may also 5473 be used for store-and-forward rendering, and "application" media type, 5474 to support editing tools. Initialization objects without note storage, 5475 or initialization objects for non-audio renderers, SHOULD be registered 5476 only for an "application" media type. 5478 C.6.4 MIDI Channel Mapping 5480 In this Appendix, we specify how to map MIDI name spaces (16 voice 5481 channels + systems) onto a renderer. 5483 In the general case: 5485 o A session may define an ordered relationship (Appendix C.5) 5486 that presents more than one MIDI name space to a renderer. 5488 o A renderer may accept an arbitrary number of MIDI name spaces, 5489 or may expect a specific number of MIDI name spaces. 5491 A session description SHOULD provide a compatible MIDI name space to 5492 each renderer in the session. If a receiver detects that a session 5493 description has too many or too few MIDI name spaces for a renderer, 5494 MIDI data from extra stream name spaces MUST be discarded, and extra 5495 renderer name spaces MUST NOT be driven with MIDI data (except as 5496 described in Appendix C.6.4.1 below). 5498 If a parameter list defines several renderers and assigns the "all" 5499 token value to the multimode parameter, the same name space is presented 5500 to each renderer. However, the "chanmask" parameter may be used to mask 5501 out selected voice channels to each renderer. We define "chanmask" and 5502 other MIDI management parameters in the sub-sections below. 5504 C.6.4.1 The smf_info Parameter 5506 The smf_info parameter defines the use of the SMFs encapsulated in 5507 renderer data objects (if any). The smf_info parameter also defines the 5508 use of SMFs coded in the smf_inline, smf_url, and smf_cid parameters 5509 (defined in Appendix C.6.4.2). 5511 The smf_info parameter describes the "render" parameter that most 5512 recently precedes it in the parameter list. The smf_info parameter MUST 5513 NOT appear in parameter lists that do not use the "render" parameter, 5514 and MUST NOT appear before the first use of "render" in the parameter 5515 list. 5517 We define three token values for smf_info: "ignore", "sdp_start", and 5518 "identity": 5520 o The "ignore" value indicates that the SMFs MUST be discarded. 5521 This behavior is the default SMF rendering behavior. 5523 o The "sdp_start" value codes that SMFs MUST be rendered, 5524 and that the rendering MUST begin upon the acceptance of 5525 the session description. If a receiver is offered a session 5526 description with a renderer that uses an smf_info parameter 5527 set to sdp_start, and if the receiver does not support 5528 rendering SMFs, the receiver MUST NOT accept the renderer 5529 associated with the smf_info parameter. Options include 5530 rejecting the renderer (by setting the "render" parameter 5531 to "null"), the payload type, the media stream, or the 5532 entire session description. 5534 o The "identity" value indicates the SMFs code the identity 5535 of the renderer. The value is meant for use with the 5536 "unknown" renderer (see Appendix C.6 preamble). The MIDI commands 5537 coded in the SMF are informational in nature, and MUST NOT be 5538 presented to a renderer for audio presentation. In 5539 typical use, the SMF would use SysEx Identity Reply 5540 commands (F0 7E nn 06 02, as defined in [MIDI]) to identify 5541 devices, and use device-specific SysEx commands to describe 5542 current state of the devices (patch memory contents, etc). 5544 Other smf_info token values MAY be registered with IANA. The token 5545 value MUST adhere to the ABNF for render tokens defined in Appendix D. 5546 Registrations MUST include a complete specification of parameter usage, 5547 similar in depth to the specifications that appear in this Appendix for 5548 "sdp_start" and "identity". 5550 If a party is offered a session description that uses an smf_info 5551 parameter value that is not known to the party, the party MUST NOT 5552 accept the renderer associated with the smf_info parameter. Options 5553 include rejecting the renderer, the payload type, the media stream, or 5554 the entire session description. 5556 We now define the rendering semantics for the "sdp_start" token value in 5557 detail. 5559 The SMFs and RTP MIDI streams in a session description share the same 5560 MIDI name space(s). In the simple case of a single RTP MIDI stream and 5561 a single SMF, the SMF MIDI commands and RTP MIDI commands are merged 5562 into a single name space and presented to the renderer. The indefinite 5563 artifact responsibilities for merged MIDI streams defined in Appendix 5564 C.5 also apply to merging RTP and SMF MIDI data. 5566 If a payload type codes multiple SMFs, the SMF name spaces are presented 5567 as an ordered entity to the renderer. To determine the ordering of SMFs 5568 for a renderer (which SMF is "first", which is "second", etc), use the 5569 following rules: 5571 o If the renderer uses a single data object, the order of 5572 appearance of the SMFs in the object's internal structure 5573 defines the order of the SMFs (the earliest SMF in the object 5574 is "first", the next SMF in the object is "second", etc). 5576 o If multiple data objects are encoded for a renderer, the 5577 appearance of each data object in the parameter list 5578 sets the relative order of the SMFs encoded in each 5579 data object (SMFs encoded in parameters that appear 5580 earlier in the list are ordered before SMFs encoded 5581 in parameters that appear later in the list). 5583 o If SMFs are encoded in data objects parameters and in 5584 the parameters defined in C.6.4.2, the relative order 5585 of the data object parameters and C.6.4.2 parameters 5586 in the parameter list sets the relative order of SMFs 5587 (SMFs encoded in parameters that appear earlier in the 5588 list are ordered before SMFs in parameters that appear 5589 later in the list). 5591 Given this ordering of SMFs, we now define the mapping of SMFs to 5592 renderer name spaces. The SMF that appears first for a renderer maps to 5593 the first renderer name space. The SMF that appears second for a 5594 renderer maps to the second renderer name space, etc. If the associated 5595 RTP MIDI streams also form an ordered relationship, the first SMF is 5596 merged with the first name space of the relationship, the second SMF is 5597 merged to the second name space of the relationship, etc. 5599 Unless the streams and the SMFs both use MIDI Time Code, the time offset 5600 between SMF and stream data is unspecified. This restriction limits the 5601 use of SMFs to applications where synchronization is not critical, such 5602 as the transport of System Exclusive commands for renderer 5603 initialization, or human-SMF interactivity. 5605 Finally, we note that each SMF in the sdp_start discussion above encodes 5606 exactly one MIDI name space (16 voice channels + systems). Thus, the 5607 use of the Device Name SMF meta event to specify several MIDI name 5608 spaces in an SMF is not supported for sdp_start. 5610 C.6.4.2 The smf_inline, smf_url, and smf_cid Parameters 5612 In some applications, the renderer data object may not encapsulate SMFs, 5613 but an application may wish to use SMFs in the manner defined in 5614 Appendix C.6.4.1. 5616 The "smf_inline", "smf_url", and "smf_cid" parameters address this 5617 situation. These parameters use the syntax and semantics of the inline, 5618 url, and cid parameters defined in Appendix C.6.3, except that the 5619 encoded data object is an SMF. 5621 The "smf_inline", "smf_url", and "smf_cid" parameters belong to the 5622 "render" parameter that most recently precedes it in the session 5623 description. The "smf_inline", "smf_url", and "smf_cid" parameters MUST 5624 NOT appear in parameter lists that do not use the "render" parameter, 5625 and MUST NOT appear before the first use of "render" in the parameter 5626 list. If several "smf_inline", "smf_url", or "smf_cid" parameters 5627 appear for a renderer, the order of the parameters defines the SMF name 5628 space ordering. 5630 C.6.4.3 The chanmask Parameter 5632 The chanmask parameter instructs the renderer to ignore all MIDI voice 5633 commands for certain channel numbers. The parameter value is a 5634 concatenated string of "1" and "0" digits. Each string position maps to 5635 a MIDI voice channel number (system channels may not be masked). A "1" 5636 instructs the renderer to process the voice channel; a "0" instructs the 5637 renderer to ignore the voice channel. 5639 The string length of the chanmask parameter value MUST be 16 (for a 5640 single stream or an identity relationship) or a multiple of 16 (for an 5641 ordered relationship). 5643 The chanmask parameter describes the "render" parameter that most 5644 recently precedes it in the session description; chanmask MUST NOT 5645 appear in parameter lists that do not use the "render" parameter, and 5646 MUST NOT appear before the first use of "render" in the parameter list. 5648 The chanmask parameter describes the final MIDI name spaces presented to 5649 the renderer. The SMF and stream components of the MIDI name spaces may 5650 not be independently masked. 5652 If a receiver is offered a session description with a renderer that uses 5653 the chanmask parameter, and if the receiver does not implement the 5654 semantics of the chanmask parameter, the receiver MUST NOT accept the 5655 renderer unless the chanmask parameter value contains only "1"'s. 5657 C.6.5 The audio/asc Media Type 5659 In Appendix H.3, we register the audio/asc media type. The data object 5660 for audio/asc is a binary encoding of the AudioSpecificConfig data block 5661 used to initialize mpeg4-generic streams (Section 6.2 and [MPEGAUDIO]). 5663 An mpeg4-generic parameter list MAY use the render, subrender, and rinit 5664 parameters with the audio/asc media type for renderer configuration. 5665 Several restrictions apply to the use of these parameters in 5666 mpeg4-generic parameter lists: 5668 o An mpeg4-generic media description that uses the render parameter 5669 MUST assign the empty string ("") to the mpeg4-generic "config" 5670 parameter. The use of the streamtype, mode, and profile-level-id 5671 parameters MUST follow the normative text in Section 6.2. 5673 o Sessions that use identity or ordered relationships MUST follow 5674 the mpeg4-generic configuration restrictions in Appendix C.5. 5676 o The render parameter MUST be assigned the value "synthetic", 5677 "unknown", "null", or a render value that has been added to 5678 the IANA repository for use with mpeg4-generic RTP MIDI 5679 streams. The "api" token value for render MUST NOT be used. 5681 o If a subrender parameter is present, it MUST immediately follow 5682 the render parameter, and it MUST be assigned the token value 5683 "default", or assigned a subrender value added to the IANA 5684 repository for use with mpeg4-generic RTP MIDI streams. A 5685 subrender parameter assignment may be left out of the renderer 5686 configuration, in which case the implied value of subrender 5687 is the default value of "default". 5689 o If the render parameter is assigned the value "synthetic", 5690 and the subrender parameter has the value "default" (assigned 5691 or implied), the rinit parameter MUST be assigned the value 5692 "audio/asc", and an AudioSpecificConfig data object MUST be encoded 5693 using the mechanisms defined in C.6.2-3. The AudioSpecificConfig 5694 data MUST encode one of the MPEG 4 Audio Object Types defined for 5695 use with mpeg4-generic in Section 6.2. If the subrender value is 5696 other than "default", refer to the subrender registration 5697 for information on the use of "audio/asc" with the renderer. 5699 o If the render parameter is assigned the value "null" or 5700 "unknown", the data object MAY be omitted. 5702 Several general restrictions apply to the use of the audio/asc media 5703 type in RTP MIDI: 5705 o A native stream MUST NOT assign "audio/asc" to rinit. The 5706 audio/asc media type is not intended to be a general-purpose 5707 container for rendering systems outside of MPEG usage. 5709 o The audio/asc media type defines a stored object type; it does 5710 not define semantics for RTP streams. Thus, audio/asc MUST NOT 5711 appear on an rtpmap line of a session description. 5713 Below, we show session description examples for audio/asc. The session 5714 description below uses the inline parameter to code the 5715 AudioSpecificConfig block for a mpeg4-generic General MIDI stream. We 5716 derive the value assigned to the inline parameter in Appendix E.4. The 5717 subrender token value of "default" is implied by the absence of the 5718 subrender parameter in the parameter list. 5720 v=0 5721 o=lazzaro 2520644554 2838152170 IN IP4 first.example.net 5722 s=Example 5723 t=0 0 5724 m=audio 5004 RTP/AVP 96 5725 c=IN IP4 192.0.2.94 5726 a=rtpmap:96 mpeg4-generic/44100 5727 a=fmtp:96 streamtype=5; mode=rtp-midi; config=""; profile-level-id=12; 5728 render=synthetic; rinit="audio/asc"; 5729 inline="egoAAAAaTVRoZAAAAAYAAAABAGBNVHJrAAAABgD/LwAA" 5731 (The a=fmtp line has been wrapped to fit the page to accommodate 5732 memo formatting restrictions; it comprises a single line in SDP) 5734 The session description below uses the url parameter to code the 5735 AudioSpecificConfig block for the same General MIDI stream: 5737 v=0 5738 o=lazzaro 2520644554 2838152170 IN IP4 first.example.net 5739 s=Example 5740 t=0 0 5741 m=audio 5004 RTP/AVP 96 5742 c=IN IP4 192.0.2.94 5743 a=rtpmap:96 mpeg4-generic/44100 5744 a=fmtp:96 streamtype=5; mode=rtp-midi; config=""; profile-level-id=12; 5745 render=synthetic; rinit="audio/asc"; url="http://example.net/oski.asc"; 5746 cid="xjflsoeiurvpa09itnvlduihgnvet98pa3w9utnuighbuk" 5748 (The a=fmtp line has been wrapped to fit the page to accommodate 5749 memo formatting restrictions; it comprises a single line in SDP) 5751 C.7 Interoperability 5753 In this Appendix, we define interoperability guidelines for two 5754 application areas: 5756 o MIDI content-streaming applications. Adding RTP MIDI to 5757 RTSP-based content-streaming servers, so that viewers may 5758 experience MIDI performances (produced by a specified client-side 5759 renderer) in synchronization with other streams (video, audio). 5761 o Long-distance network musical performance applications. Adding 5762 RTP MIDI to SIP-based voice chat or videoconferencing programs, 5763 as an alternative, or as an addition, to audio and/or video RTP 5764 streams. 5766 For each application we define a core set of functionality that all 5767 implementations MUST implement. 5769 The applications we address in this section are not an exhaustive list 5770 of potential RTP MIDI uses. We expect framework documents for other 5771 applications to be developed, within the IETF or within other 5772 organizations. We discuss other potential application areas for RTP 5773 MIDI in Section 1 of the main text of this memo. 5775 C.7.1 MIDI content streaming applications 5777 In content-streaming applications, a user invokes an RTSP client to 5778 initiate a request to an RTSP server to view a multimedia session. For 5779 example, clicking on a web page link for an Internet Radio channel 5780 launches an RTSP client that uses the link's RTSP URL to contact the 5781 RTSP server hosting the radio channel. 5783 The content may be pre-recorded (example: on-demand replay of 5784 yesterday's football game) or "live" (example: football game coverage as 5785 it occurs) but in either case the user is usually an "audience member" 5786 as opposed to a "participant" (as the user would be in telephony). 5788 Note that these examples describe the distribution of audio content to 5789 an audience member. The interoperability guidelines in this Appendix 5790 address RTP MIDI applications of this nature, not applications such as 5791 the transmission of raw MIDI command streams for use in a professional 5792 environment (recording studio, performance stage, etc). 5794 In an RTSP session, a client accesses a session description that is 5795 "declared" by the server, either via the RTSP DESCRIBE method, or via 5796 other means, such as HTTP or email. The session description defines the 5797 session from the perspective of the client. For example, if a media 5798 line in the session description contains a non-zero port number, it 5799 encodes the server's preference for the client's port numbers for RTP 5800 and RTCP reception. Once media flow begins, the server sends an RTP 5801 MIDI stream to the client, which renders it for presentation, perhaps in 5802 synchrony with video or other audio streams. 5804 We now define the interoperability text for content-streaming RTSP 5805 applications. 5807 In most cases, server interoperability responsibilities are described in 5808 terms of limits on the "reference" session description a server provides 5809 for a performance if it has no information about the capabilities of the 5810 client. The reference session is a "lowest common denominator" session 5811 that maximizes the odds that a client will be able to view the session. 5812 If a server is aware of the capabilities of the client, the server is 5813 free to provide a session description customized for the client in the 5814 DESCRIBE reply. 5816 Clients MUST support unicast UDP RTP MIDI streams that use the recovery 5817 journal with the closed-loop or the anchor sending policies. Clients 5818 MUST be able to interpret stream subsetting and chapter inclusion 5819 parameters in the session description that qualify the sending policies. 5820 Client support of enhanced Chapter C encoding is OPTIONAL. 5822 The reference session description offered by a server MUST send all RTP 5823 MIDI UDP streams as unicast streams that use the recovery journal and 5824 the closed-loop or anchor sending policies. Servers SHOULD use the 5825 stream subsetting and chapter inclusion parameters in the reference 5826 session description, to simplify the rendering task of the client. 5827 Server support of enhanced Chapter C encoding is OPTIONAL. 5829 Clients and servers MUST support the use of RTSP interleaved mode (a 5830 method for interleaving RTP onto the RTSP TCP transport). 5832 Clients MUST be able to interpret the timestamp semantics signalled by 5833 the "comex" value of the tsmode parameter (i.e. the timestamp semantics 5834 of Standard MIDI Files [MIDI]). Servers MUST use the "comex" value for 5835 the "tsmode" parameter in the reference session description. 5837 Clients MUST be able to process an RTP MIDI stream whose packets encode 5838 an arbitrary temporal duration ("media time"). Thus, in practice, 5839 clients MUST implement a MIDI playout buffer. Clients MUST NOT depend 5840 on the presence of rtp_ptime, rtp_maxtime, and guardtime parameters in 5841 the session description in order to process packets, but SHOULD be able 5842 to use these parameters to improve packet processing. 5844 Servers SHOULD strive to send RTP MIDI streams in the same way media 5845 servers send conventional audio streams: a sequence of packets that 5846 either all code the same temporal duration (non-normative example: 50 ms 5847 packets) or that code one of an integral number of temporal durations 5848 (non-normative example: 50 ms, 100 ms, 250 ms, or 500 ms packets). 5849 Servers SHOULD encode information about the packetization method in the 5850 rtp_ptime and rtp_maxtime parameters in the session description. 5852 Clients MUST be able to examine the render and subrender parameter, to 5853 determine if a multimedia session uses a renderer it supports. Clients 5854 MUST be able to interpret the default "one" value of the "multimode" 5855 parameter, to identify supported renderer(s) from a list of renderer 5856 descriptions. Clients MUST be able to interpret the musicport 5857 parameter, to the degree it is relevant to the renderers it supports. 5858 Clients MUST be able to interpret the chanmask parameter. 5860 Clients supporting renderers whose data object (as encoded by a 5861 parameter value for "inline"), could exceed 300 octets in size MUST 5862 support the url and cid parameters, and thus, must implement the HTTP 5863 protocol in addition to RTSP. 5865 Servers MUST specify complete rendering systems for RTP MIDI streams. 5866 Note that a minimal RTP MIDI native stream does not meet this 5867 requirement (Section 6.1), as the rendering method for such streams is 5868 "not specified". 5870 At the time this memo was written, the only way for servers to specify a 5871 complete rendering system is to specify an mpeg4-generic RTP MIDI stream 5872 in mode rtp-midi (Section 6.2 and C.6.5). As a consequence, the only 5873 rendering systems that may be presently used are General MIDI [MIDI], 5874 DLS 2 [DLS2], or Structured Audio [MPEGSA]. Note that the maximum 5875 inline value for General MIDI is well under 300 octets (and thus clients 5876 need not support the "url" parameter), but the maximum inline values for 5877 DLS 2 and Structured Audio may be quite larger than 300 octets (and thus 5878 clients MUST support the url parameter). 5880 We anticipate that the owners of rendering systems (both standardized 5881 and proprietary) will register subrender parameters for their renderers. 5882 Once registration occurs, native RTP MIDI sessions may use render and 5883 subrender (Appendix C.6.2) to specify complete rendering systems for 5884 RTSP content-streaming multimedia sessions. 5886 Servers MUST NOT use the sdp_start value for the smf_info parameter in 5887 the reference session description, as this use would require clients to 5888 be able to parse and render Standard MIDI Files. 5890 Clients MUST support mpeg4-generic mode rtp-midi General MIDI (GM) 5891 sessions, at a polyphony limited by the hardware capabilities of the 5892 client. This requirement provides a "lowest common denominator" 5893 rendering system for content providers to target. Note that this 5894 requirement does not force implementors of a non-GM renderer (such as 5895 DLS 2 or Structured Audio) to add a second rendering engine. Instead, a 5896 client may satisfy the requirement by including a set of voice patches 5897 that implement the GM instrument set, and using this emulation for 5898 mpeg4-generic GM sessions. 5900 It is RECOMMENDED that servers use General MIDI as the renderer for the 5901 reference session description, because clients are REQUIRED to support 5902 it. We do not require General MIDI as the reference renderer, because 5903 for normative applications it is an inappropriate choice. Servers using 5904 General MIDI as a "lowest common denominator" renderer SHOULD use 5905 Universal Real-Time SysEx MIP message [SPMIDI] to communicate the 5906 priority of voices to polyphony-limited clients. 5908 C.7.2 MIDI network musical performance applications 5910 In Internet telephony and videoconferencing applications, parties 5911 interact over an IP network as they would face-to-face. Good user 5912 experiences require low end-to-end audio latency and tight audiovisual 5913 synchronization (for "lip-sync"). The Session Initiation Protocol (SIP, 5914 [RFC3261]) is used for session management. 5916 In this Appendix section, we define interoperability guidelines for 5917 using RTP MIDI streams in interactive SIP applications. Our primary 5918 interest is supporting Network Musical Performances (NMP), where 5919 musicians in different locations interact over the network as if they 5920 were in the same room. See [NMP] for background information on NMP, and 5921 see [GUIDE] for a discussion of low-latency RTP MIDI implementation 5922 techniques for NMP. 5924 Note that the goal of NMP applications is telepresence: the parties 5925 should hear audio that is close to what they would hear if they were in 5926 the same room. The interoperability guidelines in this Appendix address 5927 RTP MIDI applications of this nature, not applications such as the 5928 transmission of raw MIDI command streams for use in a professional 5929 environment (recording studio, performance stage, etc). 5931 We focus on session management for two-party unicast sessions that 5932 specify a renderer for RTP MIDI streams. Within this limited scope, the 5933 guidelines defined here are sufficient to let applications interoperate. 5934 We define the REQUIRED capabilities of RTP MIDI senders and receivers in 5935 NMP sessions, and define how session descriptions exchanged are used to 5936 set up network musical performance sessions. 5938 SIP lets parties negotiate details of the session, using the 5939 Offer/Answer protocol [RFC3264]. However, RTP MIDI has so many 5940 parameters that "blind" negotiations between two parties using different 5941 applications might not yield a common session configuration. 5943 Thus, we now define a set of capabilities that NMP parties MUST support. 5944 Session description offers whose options lie outside the envelope of 5945 REQUIRED party behavior risk negotiation failure. We also define 5946 session description idioms that the RTP MIDI part of an offer MUST 5947 follow, in order to structure the offer for simpler analysis. 5949 We use the term "offerer" for the party making a SIP offer, and 5950 "answerer" for the party answering the offer. Finally, we note that 5951 unless qualified by the adjective "sender" or "receiver", a statement 5952 that a party MUST support X implies that it MUST support X for both 5953 sending and receiving. 5955 If an offerer wishes to define a "sendrecv" RTP MIDI stream, it may use 5956 a true sendrecv session or the "virtual sendrecv" construction described 5957 in the preamble to Appendix C and in Appendix C.5. A true sendrecv 5958 session indicates that the offerer wishes to participate in a session 5959 where both parties use identically-configured renderers. A virtual 5960 sendrecv session indicates that the offerer is willing to participate in 5961 a session where the two parties may be using different renderer 5962 configurations. Thus, parties MUST be prepared to see both real and 5963 virtual sendrecv sessions in an offer. 5965 Parties MUST support unicast UDP transport of RTP MIDI streams. These 5966 streams MUST use the recovery journal with the closed-loop or anchor 5967 sending policies. These streams MUST use the stream subsetting and 5968 chapter inclusion parameters to declare the types of MIDI commands that 5969 will be sent on the stream (for sendonly streams) or will be processed 5970 (for recvonly streams), including the size limits on System Exclusive 5971 commands. Support of enhanced Chapter C encoding is OPTIONAL. 5973 Note that both TCP and multicast UDP support are OPTIONAL. We make TCP 5974 OPTIONAL because we expect NMP renderers to rely on data objects 5975 (signalled by "rinit" and associated parameters) for initialization at 5976 the start of the session, and to only use System Exclusive commands for 5977 interactive control during the session. These interactive commands are 5978 small enough to be protected via the recovery journal mechanism of RTP 5979 MIDI UDP streams. 5981 We now discuss timestamps, packet timing, and packet sending algorithms. 5983 Recall that the tsmode parameter controls the semantics of command 5984 timestamps in the MIDI list of RTP packets. 5986 Parties MUST support clock rates of 44.1 kHz, 48 kHz, 88.2 kHz, and 96 5987 kHz. Parties MUST support streams using the "comex", "async", and 5988 "buffer" tsmode values. Recvonly offers MUST offer the default "comex". 5990 Parties MUST support a wide range of packet temporal durations: from 5991 rtp_ptime and rtp_maxptime values of 0, to rtp_ptime and rtp_maxptime 5992 values that code 100 ms. Thus, receivers MUST be able to implement a 5993 playout buffer. 5995 Offers and answers MUST present rtp_ptime, rtp_maxptime, and guardtime 5996 values that support the latency that users would expect in the 5997 application, subject to bandwidth constraints. As senders MUST abide by 5998 values set for these parameters in a session description, a receiver 5999 SHOULD use these values to size its playout buffer to produce the lowest 6000 reliable latency for a session. Implementers should refer to [GUIDE] 6001 for information on packet sending algorithms for latency-sensitive 6002 applications. Parties MUST be able to implement the semantics of the 6003 guardtime parameter, for times from 5 ms to 5000 ms. 6005 We now discuss the use of the render parameter. 6007 Sessions MUST specify complete rendering systems for all RTP MIDI 6008 streams. Note that a minimal RTP MIDI native stream does not meet this 6009 requirement (Section 6.1), as the rendering method for such streams is 6010 "not specified". 6012 At the time this writing, the only way for parties to specify a complete 6013 rendering system is to specify an mpeg4-generic RTP MIDI stream in mode 6014 rtp-midi (Section 6.2 and C.6.5). We anticipate that the owners of 6015 rendering systems (both standardized and proprietary) will register 6016 subrender values for their renderers. Once IANA registration occurs, 6017 native RTP MIDI sessions may use render and subrender (Appendix C.6.2) 6018 to specify complete rendering systems for SIP network musical 6019 performance multimedia sessions. 6021 All parties MUST support General MIDI (GM) sessions, at a polyphony 6022 limited by the hardware capabilities of the party. This requirement 6023 provides a "lowest common denominator" rendering system, without which 6024 practical interoperability will be quite difficult. When using GM, 6025 parties SHOULD use Universal Real-Time SysEx MIP message [SPMIDI] to 6026 communicate the priority of voices to polyphony-limited clients. 6028 Note that this requirement does not force implementors of a non-GM 6029 renderer (for mpeg4-generic sessions, DLS 2 or Structured Audio) to add 6030 a second rendering engine. Instead, a client may satisfy the 6031 requirement by including a set of voice patches that implement the GM 6032 instrument set, and using this emulation for mpeg4-generic GM sessions. 6033 We require GM support, so that an offerer that wishes to maximize 6034 interoperability may do so by offering GM if its preferred renderer is 6035 not accepted by the answerer. 6037 Offerers MUST NOT present several renderers as options in a session 6038 description by listing several payload types on a media line, as Section 6039 2.1 uses this construct to let a party send several RTP MIDI streams in 6040 the same RTP session. 6042 Instead, an offerer wishing to present rendering options SHOULD offer a 6043 single payload type that offers several renderers. In this construct, 6044 the parameter list codes a list of render parameters (each followed by 6045 its support parameters). As discussed in Appendix C.6.1, the order of 6046 renderers in the list declares the offerer's preference. The "unknown" 6047 and "null" values MUST NOT appear in the offer. The answer MUST set all 6048 render values except the desired renderer to "null". Thus, "unknown" 6049 MUST NOT appear in the answer. 6051 We use SHOULD instead of MUST in the first sentence in the paragraph 6052 above, because this technique does not work in all situations (example: 6053 an offerer wishes to offer both mpeg4-generic renderers and native RTP 6054 MIDI renderers as options). In this case, the offerer MUST present a 6055 series of session descriptions, each offering a single renderer, until 6056 the answerer accepts a session description. 6058 Parties MUST support the musicport, chanmask, subrender, rinit, and 6059 inline parameters. Parties supporting renderers whose data object (as 6060 encoded by a parameter value for "inline"), could exceed 300 octets in 6061 size MUST support the url and cid parameters, and thus, must implement 6062 HTTP protocol. Note that in mpeg4-generic, General MIDI data objects 6063 can not exceed 300 octets, but DLS 2 and Structured Audio data objects 6064 may. Support for the other rendering parameters (smf_cif, smf_info, 6065 smf_inline, smf_url) is OPTIONAL. 6067 Our discussion of rendering so far in this document assumes that the 6068 only MIDI flow that drives a renderer is the network flows described in 6069 the session description. In NMP applications, this assumption would 6070 require two rendering engines: one for local use by a party, a second 6071 for the remote party. 6073 In practice, applications may wish to have both parties share a single 6074 rendering engine. In this case, the session description MUST use a 6075 virtual sendrecv session, and MUST use the stream subsetting and chapter 6076 inclusion parameters to allocate which MIDI channels are intended for 6077 use by a party. If two parties are sharing a MIDI channels, the 6078 application MUST ensure appropriate MIDI merging occurs at the input to 6079 the renderer. 6081 We now discuss the use of (non-MIDI) audio streams in the session. 6083 Audio streams may be used for two purposes: as a "talkback" channel for 6084 parties to converse, or as a way to conduct a performance that includes 6085 MIDI and audio channels. In the latter case, offers MUST use sample 6086 rates and the packet temporal durations for the audio and MIDI streams 6087 that support low-latency synchronized rendering. 6089 We now show an example of an offer/answer exchange in a network musical 6090 performance application (next page). 6092 Below, we show an offer that complies with the interoperability text in 6093 this Appendix section. 6095 v=0 6096 o=first 2520644554 2838152170 IN IP4 first.example.net 6097 s=Example 6098 t=0 0 6099 a=group:FID 1 2 6100 c=IN IP4 192.0.2.94 6101 m=audio 16112 RTP/AVP 96 6102 a=recvonly 6103 a=mid:1 6104 a=rtpmap:96 mpeg4-generic/44100 6105 a=fmtp:96 streamtype=5; mode=rtp-midi; config=""; profile-level-id=12; 6106 cm_unused=ABCFGHJKMNPQTVWXYZ; cm_used=2NPTW; 6107 cm_used=2C0.1.7.10.11.64.121.123; cm_used=2M0.1.2 6108 cm_used=X0-16; ch_never=ABCDEFGHJKMNPQTVWXYZ; 6109 ch_default=2NPTW; ch_default=2C0.1.7.10.11.64.121.123; 6110 ch_default=2M0.1.2; cm_default=X0-16; 6111 rtp_ptime=0; rtp_maxptime=0; guardtime=44100; 6112 musicport=1; render=synthetic; rinit="audio/asc"; 6113 inline="egoAAAAaTVRoZAAAAAYAAAABAGBNVHJrAAAABgD/LwAA" 6114 m=audio 16114 RTP/AVP 96 6115 a=sendonly 6116 a=mid:2 6117 a=rtpmap:96 mpeg4-generic/44100 6118 a=fmtp:96 streamtype=5; mode=rtp-midi; config=""; profile-level-id=12; 6119 cm_unused=ABCFGHJKMNPQTVWXYZ; cm_used=1NPTW; 6120 cm_used=1C0.1.7.10.11.64.121.123; cm_used=1M0.1.2 6121 cm_used=X0-16; ch_never=ABCDEFGHJKMNPQTVWXYZ; 6122 ch_default=1NPTW; ch_default=1C0.1.7.10.11.64.121.123; 6123 ch_default=1M0.1.2; cm_default=X0-16; 6124 rtp_ptime=0; rtp_maxptime=0; guardtime=44100; 6125 musicport=1; render=synthetic; rinit="audio/asc"; 6126 inline="egoAAAAaTVRoZAAAAAYAAAABAGBNVHJrAAAABgD/LwAA" 6128 (The a=fmtp lines have been wrapped to fit the page to accommodate 6129 memo formatting restrictions; it comprises a single line in SDP) 6131 The owner line (o=) identifies the session owner as "first". 6133 The session description defines two MIDI streams: a recvonly stream on 6134 which "first" receives a performance, and a sendonly stream that "first" 6135 uses to send a performance. The recvonly port number encodes the ports 6136 on which "first" wishes to receive RTP (16112) and RTCP (16113) media at 6137 IP4 address 192.0.2.94. The sendonly port number encodes the port on 6138 which "first" wishes to receive RTCP for the stream (16115). 6140 The musicport parameters code that the two streams share and identity 6141 relationship, and thus form a virtual sendrecv stream. 6143 Both streams are mpeg4-generic RTP MIDI streams that specify a General 6144 MIDI renderer. The stream subsetting parameters code that the recvonly 6145 stream uses MIDI channel 1 exclusively for voice commands, and that the 6146 sendonly stream uses MIDI channel 2 exclusively for voice commands. 6147 This mapping permits the application software to share a single renderer 6148 for local and remote performers. 6150 We now show the answer to the offer. 6152 v=0 6153 o=second 2520644554 2838152170 IN IP4 second.example.net 6154 s=Example 6155 t=0 0 6156 a=group:FID 1 2 6157 c=IN IP4 192.0.2.105 6158 m=audio 5004 RTP/AVP 96 6159 a=sendonly 6160 a=mid:1 6161 a=rtpmap:96 mpeg4-generic/44100 6162 a=fmtp:96 streamtype=5; mode=rtp-midi; config=""; profile-level-id=12; 6163 cm_unused=ABCFGHJKMNPQTVWXYZ; cm_used=2NPTW; 6164 cm_used=2C0.1.7.10.11.64.121.123; cm_used=2M0.1.2 6165 cm_used=X0-16; ch_never=ABCDEFGHJKMNPQTVWXYZ; 6166 ch_default=2NPTW; ch_default=2C0.1.7.10.11.64.121.123; 6167 ch_default=2M0.1.2; cm_default=X0-16; 6168 rtp_ptime=0; rtp_maxptime=882; guardtime=44100; 6169 musicport=1; render=synthetic; rinit="audio/asc"; 6170 inline="egoAAAAaTVRoZAAAAAYAAAABAGBNVHJrAAAABgD/LwAA" 6171 m=audio 5006 RTP/AVP 96 6172 a=recvonly 6173 a=mid:2 6174 a=rtpmap:96 mpeg4-generic/44100 6175 a=fmtp:96 streamtype=5; mode=rtp-midi; config=""; profile-level-id=12; 6176 cm_unused=ABCFGHJKMNPQTVWXYZ; cm_used=1NPTW; 6177 cm_used=1C0.1.7.10.11.64.121.123; cm_used=1M0.1.2 6178 cm_used=X0-16; ch_never=ABCDEFGHJKMNPQTVWXYZ; 6179 ch_default=1NPTW; ch_default=1C0.1.7.10.11.64.121.123; 6180 ch_default=1M0.1.2; cm_default=X0-16; 6181 rtp_ptime=0; rtp_maxptime=0; guardtime=88200; 6182 musicport=1; render=synthetic; rinit="audio/asc"; 6183 inline="egoAAAAaTVRoZAAAAAYAAAABAGBNVHJrAAAABgD/LwAA" 6185 (The a=fmtp lines have been wrapped to fit the page to accommodate 6186 memo formatting restrictions; they comprise single lines in SDP) 6188 The owner line (o=) identifies the session owner as "second". 6190 The port numbers for both media streams are non-zero; thus, "second" has 6191 accepted the session description. The stream marked "sendonly" in the 6192 offer is marked "recvonly" in the answer, and vice versa, coding the 6193 different view of the session held by "session". The IP4 number 6194 (192.0.2.105) and the RTP (5004 and 5006) and RTCP (5005 and 5007) have 6195 been changed by "second" to match its transport wishes. 6197 In addition, "second" has made several parameter changes: rtp_maxptime 6198 for the sendonly stream has been changed to code 2 ms (441 in clock 6199 units), and the guardtime for the recvonly stream has been doubled. As 6200 these parameter modifications request capabilities that are REQUIRED to 6201 be implemented by interoperable parties, "second" can make these changes 6202 with confidence that "first" can abide by them. 6204 D. Parameter Syntax Definitions 6206 In this Appendix, we define the syntax for the RTP MIDI media type 6207 parameters in Augmented Backus-Naur Form (ABNF, [RFC2234]). When using 6208 these parameters with SDP, all parameters MUST appear on a single fmtp 6209 attribute line of an RTP MIDI media description. For mpeg4-generic RTP 6210 MIDI streams, this line MUST also include any mpeg4-generic parameters 6211 (usage described in Section 6.2). An fmtp attribute line may be defined 6212 (after [RFC3640]) as: 6214 ; 6215 ; SDP fmtp line definition 6216 ; 6218 fmtp = "a=fmtp:" token SP param-assign 0*(";" SP param-assign) CRLF 6220 where codes the RTP payload type. Note that white space MUST 6221 NOT appear between the "a=fmtp:" and the RTP payload type. 6223 We now define the syntax of the parameters defined in Appendix C. The 6224 definition takes the form of the incremental assembly of the token. See [RFC3640] for the syntax of the mpeg4-generic 6226 parameters discussed in Section 6.2. 6227 ; 6228 ; 6229 ; top-level definition for all parameters 6230 ; 6231 ; 6233 ; 6234 ; Parameters defined in Appendix C.1 6236 param-assign /= "cm_unused" "=" ([channel-list] command-type [f-list]) 6237 / sysex-data 6239 param-assign /= "cm_used" "=" ([channel-list] command-type [f-list]) 6240 / sysex-data 6242 ; 6243 ; Parameters defined in Appendix C.2 6245 param-assign = "j_sec" "=" ("none" / "recj" / *ietf-extension) 6247 param-assign /= "j_update" "=" ("anchor" / "closed-loop" / "open-loop" 6248 / *ietf-extension) 6250 param-assign /= "ch_default" "=" ([channel-list] chapter-list [f-list]) 6251 / sysex-data 6253 param-assign /= "ch_never" "=" ([channel-list] chapter-list [f-list]) 6254 / sysex-data 6256 param-assign /= "ch_anchor" "=" ([channel-list] chapter-list [f-list]) 6257 / sysex-data 6259 ; 6260 ; Parameters defined in Appendix C.3 6262 param-assign /= "tsmode" "=" ("comex" / "async" / "buffer") 6264 param-assign /= "linerate" "=" nonzero-four-octet 6266 param-assign /= "octpos" "=" ("first" / "last") 6268 param-assign /= "mperiod" "=" nonzero-four-octet 6270 ; 6271 ; Parameter defined in Appendix C.4 6273 param-assign /= "guardtime" "=" nonzero-four-octet 6275 param-assign /= "rtp_ptime" "=" four-octet 6277 param-assign /= "rtp_maxptime" "=" four-octet 6279 ; 6280 ; Parameters defined in Appendix C.5 6282 param-assign /= "musicport" "=" four-octet 6284 ; 6285 ; Parameters defined in Appendix C.6 6287 param-assign /= "chanmask" "=" 1*( 16( "0" / "1" ) ) 6289 param-assign /= "cid" "=" double-quote cid-block double-quote 6291 param-assign /= "inline" "=" double-quote base-64-block double-quote 6293 param-assign /= "multimode" "=" ("all" / "one") 6295 param-assign /= "render" "=" ("synthetic" / "api" / "null" / 6296 "unknown" / *extension) 6298 param-assign /= "rinit" "=" mime-type "/" mime-subtype 6300 param-assign /= "smf_cid" "=" double-quote cid-block double-quote 6301 param-assign /= "smf_info" "=" ("ignore" / "identity" / "sdp_start" 6302 / *extension) 6304 param-assign /= "smf_inline" "=" double-quote base-64-block double-quote 6306 param-assign /= "smf_url" "=" double-quote uri-element double-quote 6308 param-assign /= "subrender" "=" ("default" / *extension) 6310 param-assign /= "url" "=" double-quote uri-element double-quote 6312 ; 6313 ; list definitions for the cm_ command-type 6314 ; 6316 command-type = command-part1 command-part2 command-part3 6318 command-part1 = 0*1"A" 0*1"B" 0*1"C" 0*1"F" 0*1"G" 6320 command-part2 = 0*1"H" 0*1"J" 0*1"K" 0*1"M" 0*1"N" 0*1"P" 0*1"Q" 6322 command-part3 = 0*1"T" 0*1"V" 0*1"W" 0*1"X" 0*1"Y" 0*1"Z" 6324 ; 6325 ; list definitions for the ch_ chapter-list 6326 ; 6328 chapter-list = chapter-part1 chapter-part2 chapter-part3 6330 chapter-part1 = 0*1"A" 0*1"B" 0*1"C" 0*1"D" 0*1"E" 0*1"F" 0*1"G" 6332 chapter-part2 = 0*1"H" 0*1"J" 0*1"K" 0*1"M" 0*1"N" 0*1"P" 0*1"Q" 6334 chapter-part3 = 0*1"T" 0*1"V" 0*1"W" 0*1"X" 0*1"Y" 0*1"Z" 6336 ; 6337 ; list definitions for the ch_ channel-list 6338 ; 6340 channel-list = midi-chan-element *("." midi-chan-element) 6342 midi-chan-element = midi-chan / midi-chan-range 6344 midi-chan-range = midi-chan "-" midi-chan 6346 ; decimal value of left midi-chan 6347 ; MUST be strictly less than decimal 6348 ; value of right midi-chan 6350 midi-chan = %d0-15 6352 ; 6353 ; list definitions for the ch_ field list (f-list) 6354 ; 6356 f-list = midi-field-element *("." midi-field-element) 6358 midi-field-element = midi-field / midi-field-range 6360 midi-field-range = midi-field "-" midi-field 6361 ; 6362 ; decimal value of left midi-field 6363 ; MUST be strictly less than decimal 6364 ; value of right midi-field 6366 midi-field = four-octet 6367 ; 6368 ; large range accommodates Chapter M 6369 ; RPN (0-16383) and NRPN (16384-32767) 6370 ; parameters, and Chapter X octet sizes. 6372 ; 6373 ; definitions for ch_ sysex-data 6374 ; 6376 sysex-data = "__" h-list *("_" h-list) "__" 6378 h-list = hex-field-element *("." hex-field-element) 6380 hex-field-element = hex-octet / hex-field-range 6382 hex-field-range = hex-octet "-" hex-octet 6383 ; 6384 ; hexadecimal value of left hex-octet 6385 ; MUST be strictly less than hexadecimal 6386 ; value of right hex-octet 6388 hex-octet = 2("0" / "1" / "2"/ "3" / "4" / 6389 "5" / "6" / "7" / "8" / "9" / 6390 "A" / "B" / "C" / "D" / "E" / "F") 6391 ; 6392 ; rewritten version of hex-octet in [RFC2045] 6393 ; (page 23). 6394 ; note that a-f are not permitted, only A-F. 6395 ; hex-octet values MUST NOT exceed 7F. 6397 ; 6398 ; definitions for rinit parameter 6399 ; 6401 mime-type = "audio" / "application" 6403 mime-subtype = token 6404 ; 6405 ; See Appendix C.6.2 for registration 6406 ; requirements for rinit type/subtypes. 6408 ; 6409 ; definitions for base64 encoding 6410 ; copied from [SDP] 6412 base-64-block = *base64-unit [base64-pad] 6414 base64-unit = 4base64-char 6416 base64-pad = 2base64-char "==" / 3base64-char "=" 6418 base64-char = %x41-5A / %x61-7A / %x30-39 / "+" / "/" 6419 ; A-Z, a-z, 0-9, "+" and "/" 6421 ; 6422 ; generic rules 6423 ; 6425 ietf-extension = token 6426 ; 6427 ; ietf-extension may only be defined in 6428 ; standards-track RFCs. 6430 extension = token 6431 ; 6432 ; extension may be defined by filing 6433 ; a registration with IANA. 6435 four-octet = %d0-429496729 6436 ; unsigned encoding of 32-bits 6438 nonzero-four-octet = %d1-429496729 6439 ; unsigned encoding of 32-bits, ex-zero 6441 uri-element = URI-reference 6442 ; as defined in [RFC2396] and [RFC2732] 6444 double-quote = %x22 6445 ; the double-quote (") character 6447 token = 1*(token-char) 6448 ; copied from [SDP] 6450 token-char = %x21 / %x23-27 / %x2A-2B / %x2D-2E / 6451 %x30-39 / %x41-5A / %x5E-7E 6452 ; copied from [SDP] 6454 cid-block = 1*(cid-char) 6456 cid-char = token-char 6457 cid-char /= "@" 6458 cid-char /= "," 6459 cid-char /= ";" 6460 cid-char /= ":" 6461 cid-char /= "\" 6462 cid-char /= "/" 6463 cid-char /= "[" 6464 cid-char /= "]" 6465 cid-char /= "?" 6466 cid-char /= "=" 6467 ; 6468 ; add back in the tspecials [RFC2045], except for 6469 ; double-quote and the non-email safe () <> 6470 ; note that "cid" defined above ensures that 6471 ; cid-block is enclosed with double-quotes 6473 ; external references 6474 ; URI-reference: from [RFC2396] and [RFC2732] 6476 ; 6477 ; End of ABNF 6479 The mpeg4-generic RTP payload [RFC3640] defines a "mode" parameter that 6480 signals the type of MPEG stream in use. We add a new mode value, "rtp- 6481 midi", using the ABNF rule below: 6483 ; 6484 ; mpeg4-generic mode parameter extension 6485 ; 6487 mode /= "rtp-midi" 6488 ; as described in Section 6.2 of this memo 6490 E. A MIDI Overview for Networking Specialists 6492 This Appendix presents an overview of the MIDI standard, for the benefit 6493 of networking specialists new to musical applications. Implementors 6494 should consult [MIDI] for a normative description of MIDI. 6496 Musicians make music by performing a controlled sequence of physical 6497 movements. For example, a pianist plays by coordinating a series of key 6498 presses, key releases, and pedal actions. MIDI represents a musical 6499 performance by encoding these physical gestures as a sequence of MIDI 6500 commands. This high-level musical representation is compact but 6501 fragile: one lost command may be catastrophic to the performance. 6503 MIDI commands have much in common with the machine instructions of a 6504 microprocessor. MIDI commands are defined as binary elements. 6505 Bitfields within a MIDI command have a regular structure and a 6506 specialized purpose. For example, the upper nibble of the first command 6507 octet (the opcode field) codes the command type. MIDI commands may 6508 consist of an arbitrary number of complete octets, but most MIDI 6509 commands are 1, 2, or 3 octets in length. 6511 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 6512 | Channel Voice Messages | Bitfield Pattern | 6513 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 6514 | NoteOff (end a note) | 1000cccc 0nnnnnnn 0vvvvvvv | 6515 |-------------------------------------------------------------| 6516 | NoteOn (start a note) | 1001cccc 0nnnnnnn 0vvvvvvv | 6517 |-------------------------------------------------------------| 6518 | PTouch (Polyphonic Aftertouch) | 1010cccc 0nnnnnnn 0aaaaaaa | 6519 |-------------------------------------------------------------| 6520 | CControl (Controller Change) | 1011cccc 0xxxxxxx 0yyyyyyy | 6521 |-------------------------------------------------------------| 6522 | PChange (Program Change) | 1100cccc 0ppppppp | 6523 |-------------------------------------------------------------| 6524 | CTouch (Channel Aftertouch) | 1101cccc 0aaaaaaa | 6525 |-------------------------------------------------------------| 6526 | PWheel (Pitch Wheel) | 1110cccc 0xxxxxxx 0yyyyyyy | 6527 ------------------------------------------------------------- 6529 Figure E.1 -- MIDI Channel Messages 6531 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 6532 | System Common Messages | Bitfield Pattern | 6533 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 6534 | System Exclusive | 11110000, followed by a | 6535 | | list of 0xxxxxx octets, | 6536 | | followed by 11110111 | 6537 |-------------------------------------------------------------| 6538 | MIDI Time Code Quarter Frame | 11110001 0xxxxxxx | 6539 |-------------------------------------------------------------| 6540 | Song Position Pointer | 11110010 0xxxxxxx 0yyyyyyy | 6541 |-------------------------------------------------------------| 6542 | Song Select | 11110011 0xxxxxxx | 6543 |-------------------------------------------------------------| 6544 | Undefined | 11110100 | 6545 |-------------------------------------------------------------| 6546 | Undefined | 11110101 | 6547 |-------------------------------------------------------------| 6548 | Tune Request | 11110110 | 6549 |-------------------------------------------------------------| 6550 | System Exclusive End Marker | 11110111 | 6551 ------------------------------------------------------------- 6553 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 6554 | System Realtime Messages | Bitfield Pattern | 6555 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 6556 | Clock | 11111000 | 6557 |-------------------------------------------------------------| 6558 | Undefined | 11111001 | 6559 |-------------------------------------------------------------| 6560 | Start | 11111010 | 6561 |-------------------------------------------------------------| 6562 | Continue | 11111011 | 6563 |-------------------------------------------------------------| 6564 | Stop | 11111100 | 6565 |-------------------------------------------------------------| 6566 | Undefined | 11111101 | 6567 |-------------------------------------------------------------| 6568 | Active Sense | 11111110 | 6569 |-------------------------------------------------------------| 6570 | System Reset | 11111111 | 6571 ------------------------------------------------------------- 6573 Figure E.2 -- MIDI System Messages 6575 Figure E.1 and E.2 show the MIDI command family. There are three major 6576 classes of commands: voice commands (opcode field values in the range 6577 0x8 through 0xE), system common commands (opcode field 0xF, commands 6578 0xF0 through 0xF7), and system real-time commands (opcode field 0xF, 6579 commands 0xF8 through 0xFF). Voice commands code the musical gestures 6580 for each timbre in a composition. Systems commands perform functions 6581 that usually affect all voice channels, such as System Reset (0xFF). 6583 E.1 Commands Types 6585 Voice commands execute on one of 16 MIDI channels, as coded by its 4-bit 6586 channel field (field cccc in Figure E.1). In most applications, notes 6587 for different timbres are assigned to different channels. To support 6588 applications that require more than 16 channels, MIDI systems use 6589 several MIDI command streams in parallel, to yield 32, 48, or 64 MIDI 6590 channels. 6592 As an example of a voice command, consider a NoteOn command (opcode 6593 0x9), with binary encoding 1001cccc 0nnnnnnn 0aaaaaaa. This command 6594 signals the start of a musical note on MIDI channel cccc. The note has 6595 a pitch coded by the note number nnnnnnn, and an onset amplitude coded 6596 by note velocity aaaaaaa. 6598 Other voice commands signal the end of notes (NoteOff, opcode 0x8), map 6599 a specific timbre to a MIDI channel (PChange, opcode 0xC), or set the 6600 value of parameters that modulate the timbral quality (all other voice 6601 commands). The exact meaning of most voice channel commands depends on 6602 the rendering algorithms the MIDI receiver uses to generate sound. In 6603 most applications, a MIDI sender has a model (in some sense) of the 6604 rendering method used by the receiver. 6606 System commands perform a variety of global tasks in the stream, 6607 including "sequencer" playback control of pre-recorded MIDI commands 6608 (the Song Position Pointer, Song Select, Clock, Start, Continue, and 6609 Stop messages), SMPTE time code (the MIDI Time Code Quarter Frame 6610 command), and the communication of device-specific data (the System 6611 Exclusive messages). 6613 E.2 Running Status 6615 All MIDI command bitfields share a special structure: the leading bit of 6616 the first octet is set to 1, and the leading bit of all subsequent 6617 octets is set to 0. This structure supports a data compression system, 6618 called running status [MIDI], that improves the coding efficiency of 6619 MIDI. 6621 In running status coding, the first octet of a MIDI voice command may be 6622 dropped if it is identical to the first octet of the previous MIDI voice 6623 command. This rule, in combination with a convention to consider NoteOn 6624 commands with a null third octet as NoteOff commands, supports the 6625 coding of note sequences using two octets per command. 6627 Running status coding is only used for voice commands. The presence of 6628 a system common message in the stream cancels running status mode for 6629 the next voice command. However, system real-time messages do not 6630 cancel running status mode. 6632 E.3 Command Timing 6634 The bitfield formats in Figures E.1 and E.2 do not encode the execution 6635 time for a command. Timing information is not a part of the MIDI 6636 command syntax itself; different applications of the MIDI command 6637 language use different methods to encode timing. 6639 For example, the MIDI command set acts as the transport layer for MIDI 6640 1.0 DIN cables [MIDI]. MIDI cables are short asynchronous serial lines 6641 that facilitate the remote operation of musical instruments and audio 6642 equipment. Timestamps are not sent over a MIDI 1.0 DIN cable. Instead, 6643 the standard uses an implicit "time of arrival" code. Receivers execute 6644 MIDI commands at the moment of arrival. 6646 In contrast, Standard MIDI Files (SMFs, [MIDI]), a file format for 6647 representing complete musical performances, add a explicit timestamp to 6648 each MIDI command, using a delta encoding scheme that is optimized for 6649 statistics of musical performance. SMF timestamps usually code timing 6650 using the metric notation of a musical score. SMF meta-events are used 6651 to add a tempo map to the file, so that score beats may be accurately 6652 converted into units of seconds during rendering. 6654 E.4 AudioSpecificConfig templates for MMA renderers 6656 In Section 6.2 and Appendix C.6.5 in this memo, we describe how session 6657 descriptions include an AudioSpecificConfig data block to specify a MIDI 6658 rendering algorithm for mpeg4-generic RTP MIDI streams. 6660 The bitfield format of AudioSpecificConfig is defined in [MPEGAUDIO]. 6661 StructuredAudioSpecificConfig, a key data structure coded in 6662 AudioSpecificConfig, is defined in [MPEGSA]. 6664 For implementors wishing to specify Structured Audio renderers, a full 6665 understanding of [MPEGSA] and [MPEGAUDIO] are essential. However, many 6666 implementors will limit their rendering options to the two MIDI 6667 Manufacturers Association renderers that may be specified in 6668 AudioSpecificConfig: General MIDI (GM, [MIDI]) and Downloadable Sounds 2 6669 (DLS 2, [DLS2]). 6671 To aid these implementors, we reproduce the AudioSpecificConfig bitfield 6672 formats for a GM renderer and a DLS 2 renderer below. We have checked 6673 these bitfields carefully and believe they are correct. However, we 6674 stress that the material below is informative, and [MPEGAUDIO] and 6675 [MPEGSA] are the normative definitions for AudioSpecificConfig. 6677 As described in Section 6.2, a minimal mpeg4-generic session description 6678 encodes the AudioSpecificConfig binary bitfield as a hexadecimal string 6679 (whose format is defined in [RFC3640]) that is assigned to the "config" 6680 parameter. As described in Appendix C.6.3, a session description that 6681 uses the render parameter encodes the AudioSpecificConfig binary 6682 bitfield as a Base64-encoded string assigned to the "inline" parameter, 6683 or in the body of an HTTP URL assigned to the "url" parameter. 6685 Below, we show a simplified binary AudioSpecificConfig bitfield format, 6686 suitable for sending and receiving GM and DLS 2 data: 6688 0 1 2 3 6689 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 6690 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6691 | AOTYPE |FREQIDX|CHANNEL|SACNK| FILE_BLK 1 (required) ... | 6692 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6693 |1|SACNK| FILE_BLK 2 (optional) ... | 6694 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6695 | ... |1|SACNK| FILE_BLK N (optional) ... | 6696 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6697 |0|0| (first "0" bit terminates FILE_BLK list) 6698 +-+-+ 6700 Figure E.3 -- Simplified AudioSpecificConfig 6702 The 5-bit AOTYPE field specifies the Audio Object Type as an unsigned 6703 integer. The legal values for use with mpeg4-generic RTP MIDI streams 6704 are "15" (General MIDI), "14" (DLS 2), and "13" (Structured Audio). 6705 Thus, receivers that do not support all three mpeg4-generic renderers 6706 may parse the first 5 bits of an AudioSpecificConfig coded in a session 6707 description, and reject sessions that specify unsupported renderers. 6709 The 4-bit FREQIDX field specifies the sampling rate of the renderer. We 6710 show the mapping of FREQIDX values to sampling rates in Figure E.4. 6711 Senders MUST specify a sampling frequency that matches the RTP clock 6712 rate, if possible; if not, senders MUST specify the escape value. 6713 Receivers MUST consult the RTP clock parameter for the true sampling 6714 rate if the escape value is specified. 6716 FREQIDX Sampling Frequency 6718 0x0 96000 6719 0x1 88200 6720 0x2 64000 6721 0x3 48000 6722 0x4 44100 6723 0x5 32000 6724 0x6 24000 6725 0x7 22050 6726 0x8 16000 6727 0x9 12000 6728 0xa 11025 6729 0xb 8000 6730 0xc reserved 6731 0xd reserved 6732 0xe reserved 6733 0xf escape value 6735 Figure E.4 -- FreqIdx encoding 6737 The 4-bit CHANNEL field specifies the number of audio channels for the 6738 renderer. The values 0x1-0x5 specify 1 to 5 audio channels; the value 6739 0x6 specified 5+1 surround sound, and the value 0x7 specifies 7+1 6740 surround sound. If the rtpmap line in the session description specifies 6741 one of these formats, CHANNEL MUST be set to the corresponding value. 6742 Otherwise, CHANNEL MUST be set to 0x0. 6744 The CHANNEL field is followed by a list of one or more binary file data 6745 blocks. The 3-bit SACNK field (the chunk_type field in class 6746 StructuredAudioSpecificConfig defined in [MPEGSA]) specifies the type of 6747 each data block. 6749 For General MIDI, only Standard MIDI Files may appear in the list (SACNK 6750 field value 2). For DLS 2, only Standard MIDI Files and DLS 2 RIFF 6751 files (SACNK field value 4) may appear. For both of these file types, 6752 the FILE_BLK field has the format shown in Figure E.5: a 32-bit unsigned 6753 integer value (FILE_LEN) coding the number of bytes in the SMF or RIFF 6754 file, followed by FILE_LEN bytes coding the file data. 6756 0 1 2 3 6757 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 6758 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6759 | FILE_LEN (32-bit, a byte count SMF file or RIFF file) | 6760 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6761 | FILE_DATA (file contents, a list of FILE_LEN bytes) ... | 6762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6764 Figure E.5 -- The FILE_BLK field format 6766 Note that several files may follow CHANNEL field. The "1" constant 6767 fields in Figure E.3 code the presence of another file; the "0" constant 6768 field codes the end of the list. The final "0" bit in Figure E.3 codes 6769 the absence of special coding tools (see [MPEGAUDIO] for details). 6770 Senders not using these tools MUST append this "0" bit; receivers that 6771 do not understand these coding tools MUST ignore all data following a 6772 "1" in this position. 6774 The StructuredAudioSpecificConfig bitfield structure requires the 6775 presence of one FILE_BLK. For mpeg4-generic RTP MIDI use of DLS 2, 6776 FILE_BLKs MUST code RIFF files or SMF files. For mpeg4-generic RTP MIDI 6777 use of General MIDI, FILE_BLKs MUST code SMF files. By default, this 6778 SMF will be ignored (Appendix C.6.4.1). In this default case, a GM 6779 StructuredAudioSpecificConfig bitfield SHOULD code a FILE_BLK whose 6780 FILE_LEN is 0, and whose FILE_DATA is empty. 6782 To complete this Appendix, we derive the StructuredAudioSpecificConfig 6783 that we use in the General MIDI session examples in this memo. 6784 Referring to Figure E.3, we note that for GM, AOTYPE = 15. Our examples 6785 use a 44,100 Hz sample rate (FREQIDX = 4) and are in mono (CHANNEL = 1). 6786 For GM, a single SMF is encoded (SACNK = 2), using the SMF shown in 6787 Figure E.6 (a 26 byte file). 6789 -------------------------------------------- 6790 | MIDI File =
| 6791 -------------------------------------------- 6793 Where: 6795
= 6796 4D 54 68 64 00 00 00 06 00 00 00 01 00 60 6798 = 6799 4D 54 72 6B 00 00 00 04 00 FF 2F 00 6801 Figure E.6 -- SMF file encoded in the example 6803 Placing these constants in binary format into the data structure shown 6804 in Figure E.3 yields the constant shown in Figure E.7. 6806 0 1 2 3 6807 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 6808 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6809 |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| 6810 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6811 |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| 6812 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6813 |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| 6814 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6815 |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| 6816 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6817 |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| 6818 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6819 |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| 6820 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6821 |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| 6822 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6823 |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| 6824 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6825 |0|0| 6826 +-+-+ 6828 Figure E.7 -- AudioSpecificConfig used in GM examples 6830 Expressing this bitfield as an ASCII hexadecimal string yields: 6832 7A0A0000001A4D546864000000060000000100604D54726B0000000600FF2F000 6834 This string is assigned to the "config" parameter in the minimal 6835 mpeg4-generic General MIDI examples in this memo (such as the example in 6836 Section 6.2). Expressing this string in Base64 [RFC2045] yields: 6838 egoAAAAaTVRoZAAAAAYAAAABAGBNVHJrAAAABgD/LwAA 6840 This string is assigned to the "inline" parameter in the General MIDI 6841 example shown in Appendix C.6.5. 6843 F. Acknowledgements 6845 We thank the networking, media compression, and computer music community 6846 members who have commented or contributed to the effort, including Kurt 6847 B, Cynthia Bruyns, Steve Casner, Paul Davis, Robin Davies, Joanne Dow, 6848 Tobias Erichsen, Nicolas Falquet, Dominique Fober, Philippe Gentric, 6849 Michael Godfrey, Chris Grigg, Todd Hager, Michel Jullian, Phil Kerr, 6850 Young-Kwon Lim, Jessica Little, Jan van der Meer, Colin Perkins, Charlie 6851 Richmond, Herbie Robinson, Larry Rowe, Eric Scheirer, Dave Singer, 6852 Martijn Sipkema, William Stewart, Kent Terry, Magnus Westerlund, Tom 6853 White, Jim Wright, Doug Wyatt, and Giorgio Zoia. We also thank the 6854 members of the San Francisco Bay Area music and audio community for 6855 creating the context for the work, including Don Buchla, Chris Chafe, 6856 Richard Duda, Dan Ellis, Adrian Freed, Ben Gold, Jaron Lanier, Roger 6857 Linn, Richard Lyon, Dana Massie, Max Mathews, Keith McMillen, Carver 6858 Mead, Nelson Morgan, Tom Oberheim, Malcolm Slaney, Dave Smith, Julius 6859 Smith, David Wessel, and Matt Wright. 6861 G. Security Considerations 6863 Implementors should carefully read the Security Considerations sections 6864 of the RTP [RFC3550], AVP [RFC3551], and other RTP profile documents, as 6865 the issues discussed in these sections directly apply to RTP MIDI 6866 streams. Implementors should also review the Secure Real-time Transport 6867 Protocol (SRTP, [RFC3711]), an RTP profile that addresses the security 6868 issues discussed in [RFC3550] [RFC3551]. 6870 In this Appendix, we discuss security issues that are unique to the RTP 6871 MIDI payload format. 6873 When using RTP MIDI, authentication of incoming RTP and RTCP packets is 6874 RECOMMENDED. Per-packet authentication may be provided by SRTP or by 6875 other means. Without the use of authentication, attackers could forge 6876 MIDI commands into an ongoing stream, damaging speakers and eardrums. 6877 An attacker could also craft RTP and RTCP packets to exploit known bugs 6878 in the client, and take effective control of a client machine. 6880 Session management tools (such as SIP [RFC3261]) SHOULD use 6881 authentication during the transport of all session descriptions 6882 containing RTP MIDI media streams. For SIP, the Security Considerations 6883 section in [RFC3261] provides an overview of possible authentication 6884 mechanisms. RTP MIDI session descriptions should use authentication 6885 because the session descriptions may code initialization data using the 6886 parameters described in Appendix C. If an attacker inserts bogus 6887 initialization data into a session description, he can corrupt the 6888 session or forge an client attack. 6890 Session descriptions may also code renderer initialization data by 6891 reference, via the url (Appendix C.6.3) and smf_url (Appendix C.6.4.2) 6892 parameters. If the coded URL is spoofed, both session and client are 6893 open to attack, even if the session description itself is authenticated. 6894 Therefore, URLs specified in url and smf_url parameters SHOULD use 6895 [RFC2818]. 6897 Section 2.1 allows streams sent by a party in two RTP sessions to have 6898 the same SSRC value and the same RTP timestamp initialization value, 6899 under certain circumstances. Normally, these values are randomly chosen 6900 for each stream in a session, to make plaintext guessing harder to do if 6901 the payloads are encrypted. Thus, Section 2.1 weakens this aspect of 6902 RTP security. 6904 H. IANA Considerations 6906 This Appendix makes a series of requests to IANA. Thus, we begin with 6907 an outline of our requests. The sub-appendices that follow hold the 6908 actual, detailed requests. All registrations in this Appendix are in 6909 the IETF tree, and follow the rules of [MTYPE] and [RFC3555] as 6910 appropriate. 6912 In Appendix H.1, we request the registration of a new media type: 6913 "audio/rtp-midi". Paired with this request is a request for a 6914 repository for new values for several parameters associated with 6915 "audio/rtp-midi". We request this repository in Appendix H.1.1. 6917 In Appendix H.2, we request the registration of a new value ("rtp-midi") 6918 for the "mode" parameter of the "mpeg4-generic" media type, in Appendix 6919 H.2. The "mpeg4-generic" media type is defined in [RFC3640], and 6920 [RFC3640] defines a repository for the "mode" parameter. However, we 6921 believe we are the first to request the registration of a "mode" value, 6922 and so we believe the registry for "mode" has not yet been created by 6923 IANA. 6925 Paired with our "mode" parameter value request for "mpeg4-generic" is a 6926 request for a repository for new values for several parameters we have 6927 defined for use with the "rtp-midi" mode value. We request this 6928 repository in Appendix H.2.1. 6930 In Appendix H.3, we request the registration of a new media type: 6931 "audio/asc". No repository request is associated with this request. 6933 H.1 rtp-midi Media Type Registration 6935 This Appendix requests the registration of the "rtp-midi" subtype for 6936 the "audio" media type. We request the registration of the parameters 6937 listed in the "optional parameters" section below (both the "non- 6938 extensible parameters" and the "extensible parameters" lists). We also 6939 request the creation of repositories for the "extensible parameters"; 6940 the details of this request appear in Appendix H.1.1 below. 6942 Media type name: 6944 audio 6946 Subtype name: 6948 rtp-midi 6950 Required parameters: 6952 rate: The RTP timestamp clock rate. See Sections 2.1 and 6.1 6953 for usage details. 6955 Optional parameters: 6957 Non-extensible parameters: 6959 ch_anchor: See Appendix C.2.3 for usage details. 6960 ch_default: See Appendix C.2.3 for usage details. 6961 ch_never: See Appendix C.2.3 for usage details. 6962 cm_unused: See Appendix C.1 for usage details. 6963 cm_used: See Appendix C.1 for usage details. 6964 chanmask: See Appendix C.6.4.3 for usage details. 6965 cid: See Appendix C.6.3 for usage details. 6966 guardtime: See Appendix C.4.2 for usage details. 6967 inline: See Appendix C.6.3 for usage details. 6968 linerate: See Appendix C.3 for usage details. 6969 mperiod: See Appendix C.3 for usage details. 6970 multimode: See Appendix C.6.1 for usage details. 6971 musicport: See Appendix C.5 for usage details. 6972 octpos: See Appendix C.3 for usage details. 6973 rinit: See Appendix C.6.3 for usage details. 6974 rtp_maxptime: See Appendix C.4.1 for usage details. 6975 rtp_ptime: See Appendix C.4.1 for usage details. 6976 smf_cid: See Appendix C.6.4.2 for usage details. 6977 smf_inline: See Appendix C.6.4.2 for usage details. 6978 smf_url: See Appendix C.6.4.2 for usage details. 6979 tsmode: See Appendix C.3 for usage details. 6980 url: See Appendix C.6.3 for usage details. 6982 Extensible parameters: 6984 j_sec: See Appendix C.2.1 for usage details. See 6985 Appendix H.1.1 for repository details. 6986 j_update: See Appendix C.2.2 for usage details. See 6987 Appendix H.1.1 for repository details. 6988 render: See Appendix C.6 for usage details. See 6989 Appendix H.1.1 for repository details. 6990 subrender: See Appendix C.6.2 for usage details. See 6991 Appendix H.1.1 for repository details. 6992 smf_info: See Appendix C.6.4.1 for usage details. See 6993 Appendix H.1.1 for repository details. 6995 Encoding considerations: 6997 The format for this type is framed and binary. 6999 Restrictions on usage: 7001 This type is only defined for real-time transfers of MIDI 7002 streams via RTP. Stored-file semantics for rtp-midi may 7003 be defined in the future. 7005 Security considerations: 7007 See Appendix G of this memo. 7009 Interoperability considerations: 7011 None. 7013 Published specification: 7015 This memo and [MIDI] serve as the normative specification. In 7016 addition, references [NMP], [GRAME], and [GUIDE] provide 7017 non-normative implementation guidance. 7019 Applications which use this media type: 7021 Audio content-creation hardware, such as MIDI controller piano 7022 keyboards and MIDI audio synthesizers. Audio content-creation 7023 software, such as music sequencers, digital audio workstations, 7024 and soft synthesizers. Computer operating systems, for network 7025 support of MIDI Application Programmer Interfaces. Content 7026 distribution servers and terminals may use this media type for 7027 low bit-rate music coding. 7029 Additional information: 7031 None. 7033 Person & email address to contact for further information: 7035 John Lazzaro 7037 Intended usage: 7039 COMMON. 7041 Author: 7043 John Lazzaro 7045 Change Controller: 7047 IETF Audio/Video Transport Working Group delegated 7048 from the IESG. 7050 H.1.1 Repository request for "audio/rtp-midi" 7052 For the "rtp-midi" subtype, we request the creation of repositories for 7053 extensions to the following parameters (which are those listed as 7054 "extensible parameters" in Appendix H.1). 7056 j_sec: 7058 Registrations for this repository may only occur 7059 via an IETF standards-track document. Appendix C.2.1 7060 of this memo describes appropriate registrations for this 7061 repository. 7063 Initial values for this repository appear below: 7065 "none": Defined in Appendix C.2.1 of this memo. 7066 "recj": Defined in Appendix C.2.1 of this memo. 7068 j_update: 7070 Registrations for this repository may only occur 7071 via an IETF standards-track document. Appendix C.2.2 7072 of this memo describes appropriate registrations for this 7073 repository. 7075 Initial values for this repository appear below: 7077 "anchor": Defined in Appendix C.2.2 of this memo. 7078 "open-loop": Defined in Appendix C.2.2 of this memo. 7079 "closed-loop": Defined in Appendix C.2.2 of this memo. 7081 render: 7083 Registrations for this repository MUST include a 7084 specification of the usage of the proposed value. 7085 See text in the preamble of Appendix C.6 for details 7086 (the paragraph that begins "Other render token ..."). 7088 Initial values for this repository appear below: 7090 "unknown": Defined in Appendix C.6 of this memo. 7091 "synthetic": Defined in Appendix C.6 of this memo. 7092 "api": Defined in Appendix C.6 of this memo. 7093 "null": Defined in Appendix C.6 of this memo. 7095 subrender: 7097 Registrations for this repository MUST include a 7098 specification of the usage of the proposed value. 7099 See text Appendix C.6.2 for details (the paragraph 7100 that begins "Other subrender token ..."). 7102 Initial values for this repository appear below: 7104 "default": Defined in Appendix C.6.2 of this memo. 7106 smf_info: 7108 Registrations for this repository MUST include a 7109 specification of the usage of the proposed value. 7110 See text in Appendix C.6.4.1 for details (the 7111 paragraph that begins "Other smf_info token ..."). 7113 Initial values for this repository appear below: 7115 "ignore": Defined in Appendix C.6.4.1 of this memo. 7116 "sdp_start": Defined in Appendix C.6.4.1 of this memo. 7117 "identity": Defined in Appendix C.6.4.1 of this memo. 7119 H.2 mpeg4-generic Media Type Registration 7121 This Appendix requests the registration of the "rtp-midi" value for the 7122 "mode" parameter of the "mpeg4-generic" media type. The "mpeg4-generic" 7123 media type is defined in [RFC3640], and [RFC3640] defines a repository 7124 for the "mode" parameter. We are registering mode rtp-midi to support 7125 the MPEG Audio codecs [MPEGSA] that use MIDI. 7127 In conjunction with this registration request, we request the 7128 registration of the parameters listed in the "optional parameters" 7129 section below (both the "non-extensible parameters" and the "extensible 7130 parameters" lists). We also request the creation of repositories for 7131 the "extensible parameters"; the details of this request appear in 7132 Appendix H.2.1 below. 7134 Media type name: 7136 audio 7138 Subtype name: 7140 mpeg4-generic 7142 Required parameters: 7144 The "mode" parameter is required by [RFC3640]. [RFC3640] requests 7145 a repository for "mode", so that new values for mode 7146 may be added. We request that the value "rtp-midi" be 7147 added to the "mode" repository. 7149 In mode rtp-midi, the mpeg4-generic parameter rate is 7150 a required parameter. Rate specifies the RTP timestamp 7151 clock rate. See Sections 2.1 and 6.2 for usage details 7152 of rate in mode rtp-midi. 7154 Optional parameters: 7156 We request registration of the following parameters 7157 for use in mode rtp-midi for mpeg4-generic. 7159 Non-extensible parameters: 7161 ch_anchor: See Appendix C.2.3 for usage details. 7162 ch_default: See Appendix C.2.3 for usage details. 7163 ch_never: See Appendix C.2.3 for usage details. 7164 cm_unused: See Appendix C.1 for usage details. 7165 cm_used: See Appendix C.1 for usage details. 7166 chanmask: See Appendix C.6.4.3 for usage details. 7167 cid: See Appendix C.6.3 for usage details. 7168 guardtime: See Appendix C.4.2 for usage details. 7169 inline: See Appendix C.6.3 for usage details. 7170 linerate: See Appendix C.3 for usage details. 7171 mperiod: See Appendix C.3 for usage details. 7173 multimode: See Appendix C.6.1 for usage details. 7174 musicport: See Appendix C.5 for usage details. 7175 octpos: See Appendix C.3 for usage details. 7176 rinit: See Appendix C.6.3 for usage details. 7177 rtp_maxptime: See Appendix C.4.1 for usage details. 7178 rtp_ptime: See Appendix C.4.1 for usage details. 7179 smf_cid: See Appendix C.6.4.2 for usage details. 7180 smf_inline: See Appendix C.6.4.2 for usage details. 7181 smf_url: See Appendix C.6.4.2 for usage details. 7182 tsmode: See Appendix C.3 for usage details. 7183 url: See Appendix C.6.3 for usage details. 7185 Extensible parameters: 7187 j_sec: See Appendix C.2.1 for usage details. See 7188 Appendix H.2.1 for repository details. 7189 j_update: See Appendix C.2.2 for usage details. See 7190 Appendix H.2.1 for repository details. 7191 render: See Appendix C.6 for usage details. See 7192 Appendix H.2.1 for repository details. 7193 subrender: See Appendix C.6.2 for usage details. See 7194 Appendix H.2.1 for repository details. 7195 smf_info: See Appendix C.6.4.1 for usage details. See 7196 Appendix H.2.1 for repository details. 7198 Encoding considerations: 7200 The format for this type is framed and binary. 7202 Restrictions on usage: 7204 Only defined for real-time transfers of audio/mpeg4-generic 7205 RTP streams with mode=rtp-midi. 7207 Security considerations: 7209 See Appendix G of this memo. 7211 Interoperability considerations: 7213 Except for the marker bit (Section 2.1), the packet formats 7214 for audio/rtp-midi and audio/mpeg4-generic (mode rtp-midi) 7215 are identical. The formats differ in use: audio/mpeg4-generic 7216 is for MPEG work, audio/rtp-midi is for all other work. 7218 Published specification: 7220 This memo, [MIDI], and [MPEGSA] are the normative references. 7221 In addition, references [NMP], [GRAME], and [GUIDE] provide 7222 non-normative implementation guidance. 7224 Applications which use this media type: 7226 MPEG 4 servers and terminals that support [MPEGSA]. 7228 Additional information: 7230 None. 7232 Person & email address to contact for further information: 7234 John Lazzaro 7236 Intended usage: 7238 COMMON. 7240 Author: 7242 John Lazzaro 7244 Change Controller: 7246 IETF Audio/Video Transport Working Group delegated 7247 from the IESG. 7249 H.2.1 Repository request for mode rtp-midi for mpeg4-generic 7251 For mode rtp-midi of the mpeg4-generic subtype, we request the creation 7252 of repositories for extensions to the following parameters (which are 7253 those listed as "extensible parameters" in Appendix H.2). 7255 j_sec: 7257 Registrations for this repository may only occur 7258 via an IETF standards-track document. Appendix C.2.1 7259 of this memo describes appropriate registrations for this 7260 repository. 7262 Initial values for this repository appear below: 7264 "none": Defined in Appendix C.2.1 of this memo. 7265 "recj": Defined in Appendix C.2.1 of this memo. 7267 j_update: 7269 Registrations for this repository may only occur 7270 via an IETF standards-track document. Appendix C.2.2 7271 of this memo describes appropriate registrations for this 7272 repository. 7274 Initial values for this repository appear below: 7276 "anchor": Defined in Appendix C.2.2 of this memo. 7277 "open-loop": Defined in Appendix C.2.2 of this memo. 7278 "closed-loop": Defined in Appendix C.2.2 of this memo. 7280 render: 7282 Registrations for this repository MUST include a 7283 specification of the usage of the proposed value. 7284 See text in the preamble of Appendix C.6 for details 7285 (the paragraph that begins "Other render token ..."). 7287 Initial values for this repository appear below: 7289 "unknown": Defined in Appendix C.6 of this memo. 7290 "synthetic": Defined in Appendix C.6 of this memo. 7291 "null": Defined in Appendix C.6 of this memo. 7293 subrender: 7295 Registrations for this repository MUST include a 7296 specification of the usage of the proposed value. 7297 See text Appendix C.6.2 for details (the paragraph 7298 that begins "Other subrender token ..." and 7299 subsequent paragraphs). Note that the text in 7300 Appendix C.6.2 contains restrictions on subrender 7301 registrations for mpeg4-generic ("Registrations 7302 for mpeg4-generic subrender values ..."). 7304 Initial values for this repository appear below: 7306 "default": Defined in Appendix C.6.2 of this memo. 7308 smf_info: 7310 Registrations for this repository MUST include a 7311 specification of the usage of the proposed value. 7312 See text in Appendix C.6.4.1 for details (the 7313 paragraph that begins "Other smf_info token ..."). 7315 Initial values for this repository appear below: 7317 "ignore": Defined in Appendix C.6.4.1 of this memo. 7318 "sdp_start": Defined in Appendix C.6.4.1 of this memo. 7319 "identity": Defined in Appendix C.6.4.1 of this memo. 7321 H.3 asc Media Type Registration 7323 This section registers "asc" as a subtype for the "audio" media type. 7324 We register this subtype to support the remote transfer of the "config" 7325 parameter of the mpeg4-generic media type [RFC3640] when used with 7326 mpeg4-generic mode rtp-midi (registered in Appendix H.2 above). We 7327 explain the mechanics of using "audio/asc" to set the config parameter 7328 in Section 6.2 and Appendix C.6.5 of this document. 7330 Note that this registration is a new subtype registration, and is not an 7331 addition to a repository defined by MPEG-related memos (such as 7332 [RFC3640]). Also note that this request for "audio/asc" does not 7333 register parameters, and does not request the creation of a repository. 7335 Media type name: 7337 audio 7339 Subtype name: 7341 asc 7343 Required parameters: 7345 none 7347 Optional parameters: 7349 none 7351 Encoding considerations: 7353 The native form of the data object is binary data, 7354 zero-padded to an octet boundary. 7356 Restrictions on usage: 7358 This type is only defined for data object (stored file) 7359 transfer. The most common transports for the type are 7360 HTTP and SMTP. 7362 Security considerations: 7364 See Appendix G of this memo. 7366 Interoperability considerations: 7368 None. 7370 Published specification: 7372 The audio/asc data object is the AudioSpecificConfig 7373 binary data structure, which is normatively defined in [MPEGAUDIO]. 7375 Applications which use this media type: 7377 MPEG 4 Audio servers and terminals which support 7378 audio/mpeg4-generic RTP streams for mode rtp-midi. 7380 Additional information: 7382 None. 7384 Person & email address to contact for further information: 7386 John Lazzaro 7388 Intended usage: 7390 COMMON. 7392 Author: 7394 John Lazzaro 7396 Change Controller: 7398 IETF Audio/Video Transport Working Group delegated 7399 from the IESG. 7401 I. References 7403 I.1 Normative References 7405 [MIDI] MIDI Manufacturers Association. "The Complete MIDI 1.0 7406 Detailed Specification", 1996. 7408 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson. 7409 "RTP: A transport protocol for real-time applications", RFC 3550, July 7410 2003. 7412 [RFC3551] Schulzrinne, H., and S. Casner. "RTP Profile for Audio and 7413 Video Conferences with Minimal Control", RFC 3551, July 2003. 7415 [RFC3640] van der Meer, J., Mackie, D., Swaminathan, V., Singer, D., 7416 and P. Gentric. "RTP Payload Format for Transport of MPEG-4 7417 Elementary Streams", RFC 3640, November 2003. 7419 [MPEGSA] International Standards Organization. "ISO/IEC 14496 MPEG-4", 7420 Part 3 (Audio), Subpart 5 (Structured Audio), 2001. 7422 [SDP] Handley, M., Jacobson, V., and C. Perkins. "SDP: Session 7423 Description Protocol", draft-ietf-mmusic-sdp-new-25.txt. 7425 [MPEGAUDIO] International Standards Organization. "ISO 14496 MPEG-4", 7426 Part 3 (Audio), 2001. 7428 [RFC2045] Freed, N. and N. Borenstein. "MIME Part One: Format of 7429 Internet Message Bodies", RFC 2045, November 1996. 7431 [DLS2] MIDI Manufacturers Association. "The MIDI Downloadable Sounds 7432 Specification", v98.2, 1998. 7434 [RFC2234] Crocker, D. and P. Overell. "Augmented BNF for Syntax 7435 Specifications: ABNF.", RFC 2234, November 1997. 7437 [RFC2119] Bradner, S. "Key words for use in RFCs to Indicate 7438 Requirement Levels", BCP 14, RFC 2119, March 1997. 7440 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and 7441 K. Norrman. "The Secure Real-time Transport Protocol (SRTP)", RFC 7442 3711, March 2004. 7444 [RFC3264] Rosenberg, J. and H. Schulzrinne. "An Offer/Answer Model 7445 with SDP", RFC 3264, June 2002. 7447 [RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform 7448 Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998. 7450 [RFC2732] Hinden, R., Carpenter, B. and L. Masinter, "Format for 7451 Literal IPv6 Addresses in URL's", RFC 2732, December 1999. 7453 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, 7454 L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol, 7455 HTTP/1.1", RFC 2616, June 1999. 7457 [RFC3388] Camarillo, G., Eriksson, G., Holler, J., and H. Schulzrinne. 7458 "Grouping of Media Lines in the Session Description Protocol (SDP)", 7459 RFC 3388, December 2002. 7461 [RP015] MIDI Manufacturers Association. "Recommended Practice 015 7462 (RP-015): Response to Reset All Controllers", 11/98. 7464 [MTYPE] Freed, N. and J. Klensin. "Media Type Specifications and 7465 Registration Procedures", draft-freed-media-type-reg-05. 7467 [RFC3555] Casner, S. and P Hoschka. "MIME Type Registration of RTP 7468 Payload Formats", RFC 3555, July 2003. 7470 I.2 Informative References 7472 [NMP] Lazzaro, J. and J. Wawrzynek. "A Case for Network Musical 7473 Performance", 11th International Workshop on Network and Operating 7474 Systems Support for Digital Audio and Video (NOSSDAV 2001) June 25-26, 7475 2001, Port Jefferson, New York. 7477 [GRAME] Fober, D., Orlarey, Y. and S. Letz. "Real Time Musical Events 7478 Streaming over Internet", Proceedings of the International Conference 7479 on WEB Delivering of Music 2001, pages 147-154. 7481 [RFC3261] Rosenberg, J, Schulzrinne, H., Camarillo, G., Johnston, A., 7482 Peterson, J., Sparks, R., Handley, M., and E. Schooler. "SIP: Session 7483 Initiation Protocol", RFC 3261, June 2002. 7485 [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier. "Real Time 7486 Streaming Protocol (RTSP)", RFC 2326, April 1998. 7488 [ALF] Clark, D. D. and D. L. Tennenhouse. "Architectural 7489 considerations for a new generation of protocols", SIGCOMM Symposium 7490 on Communications Architectures and Protocols , (Philadelphia, 7491 Pennsylvania), pp. 200--208, IEEE, Sept. 1990. 7493 [GUIDE] Lazzaro, J., and J. Wawrzynek. "An Implementation Guide for 7494 RTP MIDI", draft-ietf-avt-rtp-midi-guidelines-15.txt. 7496 [RFC2205] Braden, R. et al. "Resource ReSerVation Protocol (RSVP) -- 7497 Version 1 Functional Specification", RFC 2205, September 1997. 7499 [RFC2048] Freed, N., Klensin, J., and J. Postel. "MIME Part Four: 7500 Registration Procedures", RFC 2048, November 1996. 7502 [CONTRANS] Lazzaro, J. "Framing RTP and RTCP Packets over 7503 Connection-Oriented Transport", 7504 draft-ietf-avt-rtp-framing-contrans-05.txt. 7506 [RFC2818] E. Rescorla. "HTTP over TLS", RFC 2818, May 2000. 7508 [SPMIDI] MIDI Manufacturers Association. "Scalable Polyphony MIDI, 7509 Specification and Device Profiles", Document Version 1.0a, 2002. 7511 [LCP] Apple Computer. "Logic 7 Dedicated Control Surface Support", 7512 Appendix B. Product manual available from www.apple.com. 7514 J. Authors' Addresses 7516 John Lazzaro (corresponding author) 7517 UC Berkeley 7518 CS Division 7519 315 Soda Hall 7520 Berkeley CA 94720-1776 7521 Email: lazzaro@cs.berkeley.edu 7523 John Wawrzynek 7524 UC Berkeley 7525 CS Division 7526 631 Soda Hall 7527 Berkeley CA 94720-1776 7528 Email: johnw@cs.berkeley.edu 7530 K. Intellectual Property Rights Statement 7532 The IETF takes no position regarding the validity or scope of any 7533 Intellectual Property Rights or other rights that might be claimed to 7534 pertain to the implementation or use of the technology described in this 7535 document or the extent to which any license under such rights might or 7536 might not be available; nor does it represent that it has made any 7537 independent effort to identify any such rights. Information on the 7538 procedures with respect to rights in RFC documents can be found in BCP 7539 78 and BCP 79. 7541 Copies of IPR disclosures made to the IETF Secretariat and any 7542 assurances of licenses to be made available, or the result of an attempt 7543 made to obtain a general license or permission for the use of such 7544 proprietary rights by implementers or users of this specification can be 7545 obtained from the IETF on-line IPR repository at 7546 http://www.ietf.org/ipr. 7548 The IETF invites any interested party to bring to its attention any 7549 copyrights, patents or patent applications, or other proprietary rights 7550 that may cover technology that may be required to implement this 7551 standard. Please address the information to the IETF at ietf- 7552 ipr@ietf.org. 7554 L. Full Copyright Statement 7556 Copyright (C) The Internet Society (2006). This document is subject to 7557 the rights, licenses and restrictions contained in BCP 78, and except as 7558 set forth therein, the authors retain all their rights. 7560 This document and the information contained herein are provided 7561 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 7562 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 7563 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 7564 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 7565 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 7566 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 7567 PARTICULAR PURPOSE. 7569 Acknowledgement 7571 Funding for the RFC Editor function is currently provided by the 7572 Internet Society. 7574 N. Change Log for 7576 [Note to RFC Editors: this Appendix, and its Table of Contents listing, 7577 should be removed from the final version of the memo] 7579 The following changes were made to the document: 7581 -- 7583 [1] The IP6 "c=" lines in all session description 7584 examples were changed to be: 7586 c=IN IP6 2001:DB80::7F2E:172A:1E24 7588 [2] In Appendix C.6.3, the final paragraph, the 7589 phrase "audio complete performances" was changed 7590 to be the grammatically correct "complete audio 7591 performances". 7593 [3] Updated GUIDE reference to version -15.txt. 7594 Also, RTCP is now defined as "RTP control protocol", 7595 not "Real Time Control Protocol, in its first 7596 appearance in the text, and in several other 7597 places in the text. 7599 --- 7601 The wording changes below are in response to 7602 a late-arriving review by Jim Wright, who has 7603 been reviewing RTP MIDI for the MMA. These 7604 changes reflect confusions he had understanding 7605 RTP session and stream definitions that were 7606 added to the I-Ds shortly before Last Call. 7607 He basically got in the mode of rereading 7608 Section 2.1 over and over, trying to figure 7609 out how it all fit together. He felt these 7610 four clarifications would have helped him 7611 figure out the mechanism easier, and so I 7612 added these into the I-D. 7614 [4] In Section 2.1, the paragraph that began 7615 "A session description [SDP] media line ("m=") 7616 is now preceded by the introductory line: 7618 "We now define RTP session semantics, in the 7619 context of sessions specified using the session 7620 description protocol [SDP]." 7621 [5] In the aforementioned paragraph, the sentence 7622 beginning with "Source" now begins with 7623 "Synchronization source". 7625 [6] Later in Section 2.1, the paragraph that 7626 begins "Streams in an RTP session may use" 7627 has the added sentence: 7629 Recall that dynamic binding of payload type 7630 numbers in [SDP] lets a party map many payload 7631 type numbers to the RTP MIDI payload format, 7632 and thus a party may send many RTP MIDI streams 7633 in a single RTP session. 7635 [7] Later in Section 2.1, the paragraph that 7636 begins "The RTP header timestamps for each stream" 7637 ends with a few sentences that have been modified 7638 to include specific references to [RFC3550]. Here 7639 are the modified sentences: 7641 The SSRC values for each stream in an RTP session 7642 are also separately and randomly chosen, as described 7643 in [RFC3550]. Receivers use the CNAME field encoded 7644 in RTCP sender reports to verify that streams were 7645 sent by the same party, and to detect SSRC collisions, 7646 as described in [RFC3550].