wdiff rfc4695.original rfc4695.txt

INTERNET-DRAFT
Network Working Group J. Lazzaro
January 23, 2006
Request for Comments: 4695 J. Wawrzynek
Expires: July 23, 2006
Category: Standards Track UC Berkeley
November 2006

RTP Payload Format for MIDI

<draft-ietf-avt-rtp-midi-format-15.txt>

Status of this This Memo

By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware have
been or will be disclosed, and any of which he or she becomes aware
will be disclosed, in accordance with Section 6 of BCP 79.

Internet-Drafts are working documents of

This document specifies an Internet standards track protocol for the
Internet Engineering
Task Force (IETF), its areas, community, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid requests discussion and suggestions for a maximum
improvements. Please refer to the current edition of six months the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

The list status of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.txt.

The list this protocol. Distribution of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

This Internet-Draft will expire on July 23, 2006. this memo is unlimited.

Abstract

This memo describes an RTP a Real-time Transport Protocol (RTP) payload
format for the MIDI (Musical Instrument Digital Interface) command
language. The format encodes all commands that may legally appear on
a MIDI 1.0 DIN cable. The format is suitable for interactive
applications (such as network musical performance) and
content-delivery content-
delivery applications (such as file streaming). The format may be
used over unicast and multicast UDP as well as and TCP, and it defines tools for
graceful recovery from packet loss. Stream behavior, including the
MIDI rendering method, may be customized during session setup. The
format also serves as a mode for the mpeg4-generic format, to support
the MPEG 4 Audio Object Types for General MIDI, Downloadable Sounds
Level 2, and Structured Audio.

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1 ....................................................4
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2 ................................................5
1.2. Bitfield Conventions . . . . . . . . . . . . . . . . . . . 6 .......................................6
2. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1 ...................................................6
2.1. RTP Header . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2 .................................................7
2.2. MIDI Payload . . . . . . . . . . . . . . . . . . . . . . . 12 ..............................................11
3. MIDI Command Section . . . . . . . . . . . . . . . . . . . . . . 14
3.1 ...........................................12
3.1. Timestamps . . . . . . . . . . . . . . . . . . . . . . . . 15
3.2 ...............................................14
3.2. Command Coding . . . . . . . . . . . . . . . . . . . . . . 17 ...........................................16
4. The Recovery Journal System . . . . . . . . . . . . . . . . . . . 24 ....................................22
5. Recovery Journal Format . . . . . . . . . . . . . . . . . . . . . 26 ........................................24
6. Session Description Protocol . . . . . . . . . . . . . . . . . . 30
6.1 ...................................28
6.1. Session Descriptions for Native Streams . . . . . . . . . . 31
6.2 ...................29
6.2. Session Descriptions for mpeg4-generic Streams . . . . . . 33
6.3 ............30
6.3. Parameters . . . . . . . . . . . . . . . . . . . . . . . . 35 ................................................33
7. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . . . 37 ..................................................34
8. Congestion Control . . . . . . . . . . . . . . . . . . . . . . . 38 .............................................35
9. Security Considerations ........................................35
10. Acknowledgements ..............................................36
11. IANA Considerations ...........................................37
11.1. rtp-midi Media Type Registration .........................37
11.1.1. Repository Request for "audio/rtp-midi" ...........40
11.2. mpeg4-generic Media Type Registration ....................41
11.2.1. Repository Request for Mode rtp-midi for
mpeg4-generic .....................................44
11.3. asc Media Type Registration ..............................46
A. The Recovery Journal Channel Chapters . . . . . . . . . . . . . . 39
A.1 ..........................48
A.1. Recovery Journal Definitions . . . . . . . . . . . . . . . 39
A.2 ..............................48
A.2. Chapter P: MIDI Program Change . . . . . . . . . . . . . . 44
A.3 ............................52
A.3. Chapter C: MIDI Control Change . . . . . . . . . . . . . . 45
A.3.1 ............................53
A.3.1. Log Inclusion Rules . . . . . . . . . . . . . . . . 45
A.3.2 ................................54
A.3.2. Controller Log Format . . . . . . . . . . . . . . . 47
A.3.3 ..............................55
A.3.3. Log List Coding Rules . . . . . . . . . . . . . . . 49
A.3.4 ..............................57
A.3.4. The Parameter System . . . . . . . . . . . . . . . . 52
A.4 ...............................60
A.4. Chapter M: MIDI Parameter System . . . . . . . . . . . . . 54
A.4.1 ..........................62
A.4.1. Log Inclusion Rules . . . . . . . . . . . . . . . . 55
A.4.2 ................................64
A.4.2. Log Coding Rules . . . . . . . . . . . . . . . . . . 57
A.4.2.1 ...................................65
A.4.2.1. The Value Tool . . . . . . . . . . . . . . . 58
A.4.2.2 .............................67
A.4.2.2. The Count Tool . . . . . . . . . . . . . . . 62
A.5 .............................70
A.5. Chapter W: MIDI Pitch Wheel . . . . . . . . . . . . . . . . 63
A.6 ...............................71
A.6. Chapter N: MIDI NoteOff and NoteOn . . . . . . . . . . . . 64
A.6.1 ........................71
A.6.1. Header Structure . . . . . . . . . . . . . . . . . . 65
A.6.2 ...................................73
A.6.2. Note Structures . . . . . . . . . . . . . . . . . . 66
A.7 ....................................74
A.7. Chapter E: MIDI Note Command Extras . . . . . . . . . . . . 68
A.7.1 .......................75
A.7.1. Note Log Format . . . . . . . . . . . . . . . . . . 69
A.7.2 ....................................76
A.7.2. Log Inclusion Rules . . . . . . . . . . . . . . . . 69
A.8 ................................76
A.8. Chapter T: MIDI Channel Aftertouch . . . . . . . . . . . . 70
A.9 ........................77
A.9. Chapter A: MIDI Poly Aftertouch . . . . . . . . . . . . . . 71 ...........................78
B. The Recovery Journal System Chapters . . . . . . . . . . . . . . 73
B.1 ...........................79
B.1. System Chapter D: Simple System Commands . . . . . . . . . 73
B.1.1 ..................79
B.1.1. Undefined System Commands . . . . . . . . . . . 74
B.2 ..........................80
B.2. System Chapter V: Active Sense Command . . . . . . . . . . 77
B.3 ....................83
B.3. System Chapter Q: Sequencer State Commands . . . . . . . . 78
B.3.1 ................83
B.3.1. Non-compliant Sequencers . . . . . . . . . . . 80
B.4 ...........................85
B.4. System Chapter F: MIDI Time Code . . . . . . . . . . . . . 81
B.4.1 Tape Position ............86
B.4.1. Partial Frames . . . . . . . . . . . . . . . . . . 83
B.5 .....................................88
B.5. System Chapter X: System Exclusive . . . . . . . . . . . . 85
B.5.1 ........................89
B.5.1. Chapter Format . . . . . . . . . . . . . . . . 85
B.5.2 .....................................90
B.5.2. Log Inclusion Semantics . . . . . . . . . . . . 88
B.5.3 ............................92
B.5.3. TCOUNT and COUNT fields . . . . . . . . . . . . 90 Fields ............................95
C. Session Configuration Tools . . . . . . . . . . . . . . . . . . . 92
C.1 ....................................95
C.1. Configuration Tools: Stream Subsetting . . . . . . . . . . . . . . . . . . . . . 93
C.2 ....................97
C.2. Configuration Tools: The Journalling System . . . . . . . . . . . . . . . . . . 97
C.2.1 ..............101
C.2.1. The j_sec Parameter . . . . . . . . . . . . . . . . 98
C.2.2 ...............................102
C.2.2. The j_update Parameter . . . . . . . . . . . . . . . 99
C.2.2.1 ............................103
C.2.2.1. The anchor Sending Policy . . . . . . . . . . 100
C.2.2.2 .................104
C.2.2.2. The closed-loop Sending Policy . . . . . . . 100
C.2.2.3 ............104
C.2.2.3. The open-loop Sending Policy . . . . . . . . 104
C.2.3 ..............108
C.2.3. Recovery Journal Chapter Inclusion Parameters . . . . . . . . . . . . 106
C.3 .....110
C.3. Configuration Tools: Timestamp Semantics . . . . . . . . . . . . . . . . . . . . 111
C.3.1 .................115
C.3.1. The comex Algorithm . . . . . . . . . . . . . . . . 111
C.3.2 ...............................115
C.3.2. The async Algorithm . . . . . . . . . . . . . . . . 112
C.3.3 ...............................116
C.3.3. The buffer Algorithm . . . . . . . . . . . . . . . . 113
C.4 ..............................117
C.4. Configuration Tools: Packet Timing Tools . . . . . . . . . . . . . . . . . . . . 115
C.4.1 .................118
C.4.1. Packet Duration Tools . . . . . . . . . . . . . . . 115
C.4.2 .............................119
C.4.2. The guardtime Parameter . . . . . . . . . . . . . . 116
C.5 ...........................120
C.5. Configuration Tools: Stream Description . . . . . . . . . . . . . . . . . . . . 118
C.6 ..................121
C.6. Configuration Tools: MIDI Rendering . . . . . . . . . . . . . . . . . . . . . . 124
C.6.1 ......................128
C.6.1. The multimode Parameter . . . . . . . . . . . . . . 125
C.6.2 ...........................129
C.6.2. Renderer Specification . . . . . . . . . . . . . . . 125
C.6.3 ............................129
C.6.3. Renderer Initialization . . . . . . . . . . . . . . 128
C.6.4 ...........................131
C.6.4. MIDI Channel Mapping . . . . . . . . . . . . . . . . 129
C.6.4.1 ..............................133
C.6.4.1. The smf_info . . . . . . . . . . . . . . . . . . 130
C.6.4.2 Parameter ....................134
C.6.4.2. The smf_inline, smf_url, and smf_cid . . . . . . . . 132
C.6.4.3
Parameters ................................136
C.6.4.3. The chanmask . . . . . . . . . . . . . . . . . . 133
C.6.5 Parameter ....................136
C.6.5. The audio/asc Media Type . . . . . . . . . . . . . . 134
C.7 ..........................137
C.7. Interoperability . . . . . . . . . . . . . . . . . . . . . 136
C.7.1 .........................................139
C.7.1. MIDI Content streaming . . . . . . . . . . . . . . . . . 136
C.7.2 Streaming Applications ...............139
C.7.2. MIDI Network musical performance . . . . . . . . . . . . 139 Musical Performance Applications .....142
D. Parameter Syntax Definitions . . . . . . . . . . . . . . . . . . 148 ..................................150
E. A MIDI Overview for Networking Specialists . . . . . . . . . . . 154
E.1 ....................156
E.1. Commands Types . . . . . . . . . . . . . . . . . . . . . . 156
E.2 ...........................................159
E.2. Running Status . . . . . . . . . . . . . . . . . . . . . . 156
E.3 ...........................................159
E.3. Command Timing . . . . . . . . . . . . . . . . . . . . . . 157
E.4 ...........................................160
E.4. AudioSpecificConfig templates Templates for MMA renderers . . . . . . 157
F. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 162
G. Security Considerations . . . . . . . . . . . . . . . . . . . . . 163
H. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . . 164
H.1 rtp-midi Media Type Registration . . . . . . . . . . . . . 164
H.1.1 Repository request . . . . . . . . . . . . . . . . . 167
H.2 mpeg4-generic Media Type Registration . . . . . . . . . . . 168
H.2.1 Repository request . . . . . . . . . . . . . . . . . 171
H.3 asc Media Type Registration . . . . . . . . . . . . . . . . 173
I. Renderers ..........160
References . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
I.1 .......................................................165
Normative References . . . . . . . . . . . . . . . . . . . 175
I.2 .............................................165
Informative References . . . . . . . . . . . . . . . . . . 176
J. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 178
K. Intellectual Property Rights Statement . . . . . . . . . . . . . 178
L. Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 178
N. Change Log for <draft-ietf-avt-rtp-midi-format-15.txt> . . . . . 180 ...........................................166

1. Introduction

The Internet Engineering Task Force (IETF) has developed a set of
focused tools for multimedia networking ([RFC3550] [SDP] [RFC4566]
[RFC3261] [RFC2326]). These tools can be combined in different ways
to support a variety of real-time applications over Internet Protocol
(IP) networks.

For example, a telephony application might use the Session Initiation
Protocol (SIP, [RFC3261]) to set up a phone call. Call setup would
include negotiations to agree on a common audio codec [RFC3264].
Negotiations would use the Session Description Protocol (SDP, [SDP])
[RFC4566]) to describe candidate codecs.

After a call is set up, audio data would flow between the parties
using the Real Time Protocol (RTP, [RFC3550]) under any applicable
profile (for example, the Audio/Visual Profile (AVP, [RFC3551])).
The tools used in this telephony example (SIP, SDP, RTP) might be
combined in a different way to support a content streaming
application, perhaps in conjunction with other tools (such tools, such as the
Real Time Streaming Protocol (RTSP, [RFC2326])). [RFC2326]).

The MIDI (Musical Instrument Digital Interface) command language
[MIDI] is widely used in musical applications that are analogous to
the examples described above. On stage and in the recording studio,
MIDI is used for the interactive remote control of musical
instruments, an application similar in spirit to telephony. On web
pages, Standard MIDI Files (SMFs, [MIDI]) rendered using the General
MIDI standard [MIDI] provide a low-bandwidth substitute for audio
streaming.

This memo is motivated by a simple premise: if MIDI performances
could be sent as RTP streams that are managed by IETF session tools,
a hybridization of the MIDI and IETF application domains may occur.

For example, interoperable MIDI networking may foster network music
performance applications, in which a group of musicians, located at
different physical locations, interact over a network to perform as
they would if they were located in the same room [NMP]. As a second
example, the streaming community may begin to use MIDI for low-bitrate low-
bitrate audio coding, perhaps in conjunction with normative sound
synthesis methods [MPEGSA].

To enable MIDI applications using to use RTP, this memo defines an RTP
payload format and its media type. Sections 2-5 and Appendices A-B
define the RTP payload format. Section 6 and Appendices C-D define
the media types identifying the payload format, the parameters needed
for configuration, and how the parameters are utilized in SDP.

Appendix C also includes interoperability guidelines for the example
applications described above: network musical performance using SIP
(Appendix C.7.2) and content-streaming using RTSP (Appendix C.7.1).

Another potential application area for RTP MIDI is MIDI networking
for professional audio equipment and electronic musical instruments.
We do not offer interoperability guidelines for this application in
this memo. However, RTP MIDI has been designed with stage and studio
applications in mind, and we expect that efforts to define a stage
and studio framework will rely on RTP MIDI for MIDI transport
services.

Some applications may require MIDI media delivery at a certain
service quality level (latency, jitter, packet loss, etc). RTP
itself does not provide service guarantees. However, applications
may use lower-layer network protocols to configure the quality of the
transport services that RTP uses. These protocols may act to reserve
network resources for RTP flows [RFC2205], [RFC2205] or may simply direct RTP
traffic onto a dedicated "media network" in a local installation.
Note that RTP and the MIDI payload format do provide tools that
applications may use to achieve the best possible real-time
performance at a given service level.

This memo normatively defines the syntax and semantics of the MIDI
payload format. However, this memo does not define algorithms for
sending and receiving packets. An ancillary document [GUIDE] [RFC4696]
provides informative guidance on algorithms. Supplemental
information may be found in related conference publications [NMP]
[GRAME].

Throughout this memo, the phrase "native stream" refers to a stream
that uses the rtp-midi media type. The phrase "mpeg4-generic stream"
refers to a stream that uses the mpeg4-generic media type (in mode
rtp-midi) to operate in an MPEG 4 environment [RFC3640]. Section 6
describes this distinction in detail.

1.1

1.1. Terminology

The

In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, RFC 2119
[RFC2119].

1.2

1.2. Bitfield Conventions

The

In this document, the packet bitfields in this document that share a common name often
have identical semantics. As most of these bitfields appear in
Appendices A-B, we define the common bitfield names in Appendix A.1.

However, a few of these common names also appear in the main text of
this document. For convenience, we list these definitions below:

o R flag bit. R flag bits are reserved for future use. Senders
MUST set R bits to 0. Receivers MUST ignore R bit values.

o LENGTH field. All fields named LENGTH (as distinct from LEN)
code the number of octets in the structure that contains it,
including the header it resides in and all hierarchical levels
below it. If a structure contains a LENGTH field, a receiver
MUST use the LENGTH field value to advance past the structure
during parsing, rather than use knowledge about the internal
format of the structure.

2. Packet Format

In this section, we introduce the format of RTP MIDI packets. The
description includes some background information on RTP, for the
benefit of MIDI implementors new to IETF tools. Implementors should
consult [RFC3550] for an authoritative description of RTP.

This memo assumes that the reader is familiar with MIDI syntax and
semantics. Appendix E provides a MIDI overview, at a level of detail
sufficient to understand most of this memo. Implementors should
consult [MIDI] for an authoritative description of MIDI.

The MIDI payload format maps a MIDI command stream (16 voice channels
+ systems) onto an RTP stream. An RTP media stream is a sequence of
logical packets that share a common format. Each packet consists of
two parts: the RTP header and the MIDI payload. Figure 1 shows this
format (vertical space delineates the header and payload).

We describe RTP packets as "logical" packets to highlight the fact
that RTP itself is not a network-layer protocol. Instead, RTP
packets are mapped onto network protocols (such as unicast UDP,
multicast UDP, or TCP) by an application [ALF]. The interleaved mode
of the Real Time Streaming Protocol (RTSP, [RFC2326]) is an example
of an RTP mapping to TCP transport, as is [CONTRANS].

2.1 [RFC4571].

2.1. RTP Header

[RFC3550] provides a complete description of the RTP header fields.
In this section, we clarify the role of a few RTP header fields for
MIDI applications. All fields are coded in network byte order (big-endian). (big-
endian).

0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V |P|X| CC |M| PT | Sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MIDI command section ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Journal section ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 1 -- Packet format

The behavior of the 1-bit M field depends on the media type of the
stream. For native streams, the M bit MUST be set to 1 if the MIDI
command section has a non-zero LEN field, and MUST be set to 0
otherwise. For mpeg4-generic streams, the M bit MUST be set to 1 for
all packets (to conform to [RFC3640]).

In an RTP MIDI stream, the 16-bit sequence number field is
initialized to a randomly chosen value, value and is incremented by one
(modulo 2^16) for each packet sent in the stream. A related
quantity, the 32-bit extended packet sequence number, may be computed
by tracking rollovers of the 16-bit sequence number. Note that
different receivers of the same stream may compute different extended
packet sequence numbers, depending on when the receiver joined the
session.

The 32-bit timestamp field sets the base timestamp value for the
packet. The payload codes MIDI command timing relative to this
value. The timestamp units are set by the clock rate parameter. For
example, if the clock rate has a value of 44100 Hz, two packets whose
base timestamp values differ by 2 seconds have RTP timestamp fields
that differ by 88200.

Note that the clock rate parameter is not encoded within each RTP
MIDI packet. A receiver of an RTP MIDI stream becomes aware of the
clock rate as part of the session setup process. For example, if a
session management tool uses the Session Description Protocol (SDP, [SDP])
[RFC4566]) to describe a media session, the clock rate parameter is
set using the rtpmap attribute. We show examples of session setup in
Section 6.

For RTP MIDI stream streams destined to be rendered into audio, the clock
rate SHOULD be an audio sample rate of 32 KHz or higher. This
recommendation is due to the sensitivity of human musical perception
to small timing errors in musical note sequences, and due to the
timbral changes that occur when two near-simultaneous MIDI NoteOns
are rendered with a different timing than that desired by the content
author due to clock rate quantization. RTP MIDI streams that are not
destined for audio rendering (such as MIDI streams that control stage
lighting) MAY use a lower clock rate, rate but SHOULD use a clock rate high
enough to avoid timing artifacts in the application.

For RTP MIDI streams destined to be rendered into audio, the clock
rate SHOULD be chosen from rates in common use in professional audio
applications or in consumer audio distribution. At the time of this
writing, these rates include 32 KHz, 44.1 KHz, 48 KHz, 64 KHz, 88.2
KHz, 96 KHz, 176.4 KHz, and 192 KHz. If the RTP MIDI session is a
part of a synchronized media session that includes another (non-MIDI)
RTP audio stream with a clock rates rate of 32 KHz or higher, the RTP MIDI
stream SHOULD use a clock rate that matches the clock rate of the
other audio stream. However, if the RTP MIDI stream is destined to
be rendered into audio, the RTP MIDI stream SHOULD NOT use a clock
rate lower than 32 KHz, even if this second stream has a clock rate
less than 32 KHz.

Timestamps of consecutive packets do not necessarily increment at a
fixed rate, because RTP MIDI packets are not necessarily sent at a
fixed rate. The degree of packet transmission regularity reflects
the underlying application dynamics. Interactive applications may
vary the packet sending rate to track the gestural rate of a human
performer, whereas content-streaming applications may send packets at
a fixed rate.

Therefore, the timestamps for two sequential RTP packets may be
identical, or the second packet may have a timestamp arbitrarily
larger than the first packet (modulo 2^32). Section 3 places
additional restrictions on the RTP timestamps for two sequential RTP
packets, as does the guardtime parameter (Appendix C.4.2).

We use the term "media time" to denote the temporal duration of the
media coded by an RTP packet. The media time coded by a packet is
computed by subtracting the last command timestamp in the MIDI
command section from the RTP timestamp (modulo 2^32). If the MIDI
list of the MIDI command section of a packet is empty, the media time
coded by the packet is 0 ms. Appendix C.4.1 discusses media time
issues in detail.

We now define RTP session semantics, in the context of sessions
specified using the session description protocol [SDP]. [RFC4566]. A
session description media line ("m=") specifies an RTP session. An
RTP session has an independent space of 2^32 synchronization sources.
Synchronization source identifiers are coded in the SSRC header field
of RTP session packets. The payload types that may appear in the PT
header field of RTP session packets are listed at the end of the
media line.

Several RTP MIDI streams may appear in an RTP session. Each stream
is distinguished by a unique SSRC value, value and has a unique sequence
number and RTP timestamp space. Multiple streams in the RTP session
may be sent by a single party. Multiple parties may send streams in
the RTP session. An RTP MIDI stream encodes data for a single MIDI
command name space (16 voice channels + Systems).

Streams in an RTP session may use different payload types, or they
may use the same payload type. However, each party may send, at
most, one RTP MIDI stream for each payload type mapped to an RTP MIDI
payload format in an RTP session. Recall that dynamic binding of
payload type numbers in [SDP] [RFC4566] lets a party map many payload type
numbers to the RTP MIDI payload format, and format; thus a party may send many
RTP MIDI streams in a single RTP session. Pairs of streams (unicast
or multicast) that communicate between two parties in an RTP session
and that share a payload type have the same association as a MIDI
cable pair that cross-
connects cross-connects two devices in a MIDI 1.0 DIN network.

The RTP session architecture described above is efficient in its use
of network ports, as one RTP session (using a port pair per party)
supports the transport of many MIDI name spaces (16 MIDI channels +
systems). We define tools for grouping and labelling MIDI name
spaces across streams and sessions in Appendix C.5 of this memo.

The RTP header timestamps for each stream in an RTP session have
separately and randomly chosen initialization values. Receivers use
the timing fields encoded in the RTP control protocol (RTCP,
[RFC3550]) sender reports to synchronize the streams sent by a party.
The SSRC values for each stream in an RTP session are also separately
and randomly chosen, as described in [RFC3550]. Receivers use the
CNAME field encoded in RTCP sender reports to verify that streams
were sent by the same party, and to detect SSRC collisions, as
described in [RFC3550].

In some applications, a receiver renders MIDI commands into audio (or
into control actions, such as the rewind of a tape deck or the
dimming of stage lights). In other applications, a receiver presents
a MIDI stream to software programs via an Application Programmer
Interface (API). Appendix C.6 defines session configuration tools to
specify what receivers should do with a MIDI command stream.

If a multimedia session uses different RTP MIDI streams to send
different classes of media, the streams MUST be sent over different
RTP sessions. For example, if a multimedia session uses one MIDI
stream for audio and a second MIDI stream to control a lighting
system, the audio and lighting streams MUST be sent over different
RTP sessions, each with its own media line.

Session description tools defined in Appendix C.5 let a sending party
split a single MIDI name space (16 voice channels + systems) over
several RTP MIDI streams. Split transport of a MIDI command stream
is a delicate task, because correct command stream reconstruction by
a receiver depends on exact timing synchronization across the
streams.

To support split name spaces, we define the following requirements:

o A party MUST NOT send several RTP MIDI streams that share a MIDI
name space in the same RTP session. Instead, each stream MUST
be sent from a different RTP session.

o If several RTP MIDI streams sent by a party share a MIDI name
space, all streams MUST use the same SSRC value, value and MUST use the
same randomly chosen RTP timestamp initialization value.

These rules let a receiver identify streams that share a MIDI name
space (by matching SSRC values), values) and also lets let a receiver accurately
reconstruct the source MIDI command stream (by using RTP timestamps
to interleave commands from the two streams). Care MUST be taken by
senders to ensure that SSRC changes due to collisions are reflected
in both streams. Receivers MUST regularly examine the RTCP CNAME
fields associated with the linked streams, to ensure that the assumed
link is
legitimate, legitimate and not the result of a an SSRC collision by another
sender.

Except for the special cases described above, a party may send many
RTP MIDI streams in the same session. However, it is sometimes
advantageous for two RTP MIDI streams to be sent over different RTP
sessions. For example, two streams may need different values for RTP
session-level attributes (such as the sendonly and recvonly
attributes). As a second example, two RTP sessions may be needed to
send two unicast streams in a multimedia session that originate on
different computers (with different IP numbers). Two RTP sessions
are needed in this case because transport addresses are specified on
the RTP-session or multimedia-session level, not on a payload type
level.

On a final note, in some uses of MIDI, parties send bidirectional
traffic to conduct transactions (such as file exchange). These
commands were designed to work over MIDI 1.0 DIN cable networks may
be configured in a multicast topology, which use pure pure "party-line"
signalling. Thus, if a multimedia session ensures a multicast
connection between all parties, bidirectional MIDI commands will work
without additional support from the RTP MIDI payload format.

2.2

2.2. MIDI Payload

The payload (Figure 1) MUST begin with the MIDI command section. The
MIDI command section codes a (possibly empty) list of timestamped
MIDI commands, and provides the essential service of the payload
format.

The payload MAY also contain a journal section. The journal section
provides resiliency by coding the recent history of the stream. A
flag in the MIDI command section codes the presence of a journal
section in the payload.

Section 3 defines the MIDI command section. Sections 4-5 and
Appendices A-B define the recovery journal, the default format for
the journal section. Here, we describe how these payload sections
operate in a stream in an RTP session.

The journalling method for a stream is set at the start of a session
and MUST NOT be changed thereafter. A stream may be set to use the
recovery journal, to use an alternative journal format (none are
defined in this memo), or to not to use a journal.

The default journalling method of a stream is inferred from its
transport type. Streams that use unreliable transport (such as UDP)
default to using the recovery journal. Streams that use reliable
transport (such as TCP) default to not using a journal. Appendix
C.2.1 defines session configuration tools for overriding these
defaults. For all types of transport, a sender MUST transmit an RTP
packet stream with consecutive sequence numbers (modulo 2^16).

If a stream uses the recovery journal, every payload in the stream
MUST include a journal section. If a stream does not use
journalling, a journal section MUST NOT appear in a stream payload.
If a stream uses an alternative journal format, the specification for
the journal format defines an inclusion policy.

If a stream is sent over UDP transport, the Maximum Transmission Unit
(MTU) of the underlying network limits the practical size of the
payload section (for example, an Ethernet MTU is 1500 octets), for
applications where predictable and minimal packet transmission
latency is critical. A sender SHOULD NOT create RTP MIDI UDP packets
whose size exceeds the MTU of the underlying network. Instead, the
sender SHOULD take steps to keep the maximum packet size under the
MTU limit.

These steps may take many forms. The default closed-loop recovery
journal sending policy (defined in Appendix C.2.2.2) uses RTP control
protocol (RTCP, [RFC3550]) feedback to manage the RTP MIDI packet
size. In addition, Section 3.2 and Appendix B.5.2 provide specific
tools for managing the size of packets that code MIDI System
Exclusive (0xF0) commands. Appendix C.5 defines session
configuration tools that may be used to split a dense MIDI name space
into several UDP streams (each sent in a different RTP session, per
Section 2.1) so that the payload fits comfortably into an MTU.
Another option is to use TCP. Section 4.3 of [GUIDE] [RFC4696] provides
non-normative advice for packet size management.

3. MIDI Command Section

Figure 2 shows the format of the MIDI command section.

0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|B|J|Z|P|LEN... | MIDI list ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 2 -- MIDI command section

The MIDI command section begins with a variable-length header.

The header field LEN codes the number of octets in the MIDI list that
follows
follow the header. If the header flag B is 0, the header is one
octet long, and LEN is a 4-bit field, supporting a maximum MIDI list
length of 15 octets.

If B is 1, the header is two octets long, and LEN is a 12-bit field,
supporting a maximum MIDI list length of 4095 octets. LEN is coded
in network byte order (big-endian): the 4 bits of LEN that appear in
the first header octet code the most significant 4 bits of the 12-bit
LEN value.

A LEN value of 0 is legal, and it codes an empty MIDI list list.

If the J header bit is set to 1, a journal section MUST appear after
the MIDI command section in the payload. If the J header bit is set
to 0, the payload MUST NOT contain a journal section.

We define the semantics of the P header bit in Section 3.2.

If the LEN header field is nonzero, the MIDI list has the structure
shown in Figure 3.

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Delta Time 0 (1-4 octets long, or 0 octets if Z = 1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MIDI Command 0 (1 or more octets long) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Delta Time 1 (1-4 octets long) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MIDI Command 1 (1 or more octets long) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Delta Time N (1-4 octets long) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MIDI Command N (0 or more octets long) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 3 -- MIDI list structure. structure

If the header flag Z is 1, the MIDI list begins with a complete MIDI
command (coded in the MIDI Command 0 field field, in Figure 3) preceded by
a delta time (coded in the Delta Time 0 field). If Z is 0, the Delta
Time 0 field is not present in the MIDI list, and the command coded
in the MIDI Command 0 field has an implicit delta time of 0.

The MIDI list structure may also optionally encode a list of N
additional complete MIDI commands, each coded in a MIDI Command K
field. Each additional command MUST be preceded by a Delta Time K
field, which codes the command's delta time. We discuss exceptions
to the "command fields code complete MIDI commands" rule in Section
3.2.

The final MIDI command field (i.e. (i.e., the MIDI Command N field field, shown
in Figure 3) in the MIDI list MAY be empty. Moreover, a MIDI list
MAY consist a single delta time (encoded in the Delta Time 0 field)
without an associated command (which would have been encoded in the
MIDI Command 0 field). These rules enable MIDI coding features that
are explained in Section 3.1. We delay the explanations because an
understanding of RTP MIDI timestamps is necessary to describe the
features.

3.1

3.1. Timestamps

In this section, we describe how RTP MIDI encodes a timestamp for
each MIDI list command. Command timestamps have the same units as
RTP packet header timestamps (described in Section 2.1 and
[RFC3550]). Recall that RTP timestamps have units of seconds, whose
scaling is set during session configuration (see Section 6.1 and [SDP]).
[RFC4566]).

As shown in Figure 3, the MIDI list encodes time using a compact delta-

time
delta-time format. The RTP MIDI delta time syntax is a modified form
of the MIDI File delta time syntax [MIDI]. RTP MIDI delta times use
1-4 octet fields to encode 32-bit unsigned integers. Figure 4 shows
the encoded and decoded forms of delta times. Note that delta time
values may be legally encoded in multiple formats; for example, there
are four legal ways to encode the zero delta time (0x00, 0x8000,
0x808000, 0x80808000).

RTP MIDI uses delta times to encode a timestamp for each MIDI
command. The timestamp for MIDI Command K is the summation (modulo
2^32) of the RTP timestamp and decoded delta times 0 through K. This
cumulative coding technique, borrowed from MIDI File delta time
coding, is efficient because it reduces the number of multi-octet
delta times.

All command timestamps in a packet MUST be less than or equal to the
RTP timestamp of the next packet in the stream (modulo 2^32).

This restriction ensures that a particular RTP MIDI packet in a
stream is uniquely responsible for encoding time starting at the
moment after the RTP timestamp encoded in the RTP packet header, and
ending at the moment before the final command timestamp encoded in
the MIDI list. The "moment before" and "moment after" qualifiers
acknowledge the "less than or equal" semantics (as opposed to
"strictly less than") in the sentence above this paragraph.

Note that it is possible to "pad" the end of an RTP MIDI packet with
time that is guaranteed to be void of MIDI commands, by setting the
"Delta Time N" field of the MIDI list to the end of the void time,
and by omitting its corresponding "MIDI Command N" field (a syntactic
construction the preamble of Section 3 expressly made legal).

In addition, it is possible to code an RTP MIDI packet to express
that a period of time in the stream is void of MIDI commands. The
RTP timestamp in the header would code the start of the void time.
The MIDI list of this packet would consist of a "Delta Time 0" field
that coded the end of the void time. No other fields would be
present in the MIDI list (a syntactic construction the preamble of
Section 3 also expressly made legal).

By default, a command timestamp indicates the execution time for the
command. The difference between two timestamps indicates the time
delay between the execution of the commands. This difference may be
zero, coding simultaneous execution. In this memo, we refer to this
interpretation of timestamps as "comex" (COMmand EXecution)
semantics. We formally define comex semantics in Appendix C.3.

The comex interpretation of timestamps works well for transcoding a
Standard MIDI File (SMF) into an RTP MIDI stream, as SMFs code a
timestamp for each MIDI command stored in the file. To transcode an
SMF that uses metric time markers, use the SMF tempo map (encoded in
the SMF as meta-events) to convert metric SMF timestamp units into
seconds-based RTP timestamp units.

The comex interpretation also works well for MIDI hardware
controllers that are coding raw sensor data directly onto an RTP MIDI
stream. Note that this controller design that is preferable to a design
that converts raw sensor data into a MIDI 1.0 cable command stream
and then transcodes the stream onto an RTP MIDI stream.

The comex interpretation of timestamps is usually not the best
timestamp interpretation for transcoding a MIDI source that uses
implicit command timing (such as MIDI 1.0 DIN cables) into an RTP
MIDI stream. Appendix C.3 defines alternatives to comex semantics, semantics
and describes session configuration tools for selecting the timestamp
interpretation semantics for a stream.

One-Octet Delta Time:

Encoded form: 0ddddddd
Decoded form: 00000000 00000000 00000000 0ddddddd

Two-Octet Delta Time:

Encoded form: 1ccccccc 0ddddddd
Decoded form: 00000000 00000000 00cccccc cddddddd

Three-Octet Delta Time:

Encoded form: 1bbbbbbb 1ccccccc 0ddddddd
Decoded form: 00000000 000bbbbb bbcccccc cddddddd

Four-Octet Delta Time:

Encoded form: 1aaaaaaa 1bbbbbbb 1ccccccc 0ddddddd
Decoded form: 0000aaaa aaabbbbb bbcccccc cddddddd

Figure 4 -- Decoding delta time formats

3.2

3.2. Command Coding

Each non-empty MIDI Command field in the MIDI list codes one of the
MIDI command types that may legally appear on a MIDI 1.0 DIN cable.
Standard MIDI File meta-events do not fit this definition and MUST
NOT appear in the MIDI list. As a rule, each MIDI Command field
codes a complete command, in the binary command format defined in
[MIDI]. In the remainder of this section, we describe exceptions to
this rule.

The first MIDI channel command in the MIDI list MUST include a status
octet. Running status coding, as defined in [MIDI], MAY be used for
all subsequent MIDI channel commands in the list. As in [MIDI],
System Common and System Exclusive messages (0xF0 ... 0xF7) cancel
the running status state, but System Real-time messages (0xF8 ...
0xFF) do not affect the running status state. All System commands in
the MIDI list MUST include a status octet.

As we note above, the first channel command in the MIDI list MUST
include a status octet. However, the corresponding command in the
original MIDI source data stream might not have a status octet (in
this case, the source would be coding the command using running
status). If the status octet of the first channel command in the
MIDI list does not appear in the source data stream, the P (phantom)
header bit MUST be set to 1. In all other cases, the P bit MUST be
set to 0.

Note that the P bit describes the MIDI source data stream, not the
MIDI list encoding; regardless of the state of the P bit, the MIDI
list MUST include the status octet.

As receivers MUST be able to decode running status, sender
implementors should feel free to use running status to improve
bandwidth efficiency. However, senders SHOULD NOT introduce timing
jitter into an existing MIDI command stream through an inappropriate
use or removal of running status coding. This warning primarily
applies to senders whose RTP MIDI streams may be transcoded onto a
MIDI 1.0 DIN cable [MIDI] by the receiver: both the timestamps and
the command coding (running status or not) must comply with the
physical restrictions of implicit time coding over a slow serial
line.

On a MIDI 1.0 DIN cable [MIDI], a System Real-time command may be
embedded inside of another "host" MIDI command. This syntactic
construction is not supported in the payload format: a MIDI Command
field in the MIDI list codes exactly one MIDI command (partially or
completely).

To encode an embedded System Real-time command, senders MUST extract
the command from its host, host and code it in the MIDI list as a separate
command. The host command and System Real-time command SHOULD appear
in the same MIDI list. The delta time of the System Real-time
command SHOULD result in a command timestamp that encodes the System
Real-time command placement in its original embedded position.

Two methods are provided for encoding MIDI System Exclusive (SysEx)
commands in the MIDI list. A SysEx command may be encoded in a MIDI
Command field verbatim: a 0xF0 octet, followed by an arbitrary number
of data octets, followed by a 0xF7 octet.

Alternatively, a SysEx command may be encoded as multiple segments.
The command is divided into two or more SysEx command segments; each
segment is encoded in its own MIDI Command field in the MIDI list.

The payload format supports segmentation in order to encode SysEx
commands that encode information in the temporal pattern of data
octets. By encoding these commands as a series of segments, each
data octet may be associated with a distinct delta time.
Segmentation also supports the coding of large SysEx commands across
several packets.

To segment a SysEx command, first partition its data octet list into
two or more sublists. The last sublist MAY be empty (i.e. (i.e., contain
no octets); all other sublists MUST contain at least one data octet.
To complete the segmentation, add the status octets defined in Figure
5 to the head and tail of the first, last, and any "middle" sublists.
Figure 6 shows example segmentations of a SysEx command.

A sender MAY cancel a segmented SysEx command transmission that is in
progress, by sending the "cancel" sublist shown in Figure 5. A
"cancel" sublist MAY follow a "first" or "middle" sublist in the
transmission, but MUST NOT follow a "last" sublist. The cancel MUST
be empty (thus, 0xF7 0xF4 is the only legal cancel sublist).

The cancellation feature is needed because Appendix C.1 defines
configuration tools that let session parties exclude certain SysEx
commands in the stream. Senders that transcode a MIDI source onto an
RTP MIDI stream under these constraints have the responsibility of
excluding undesired commands from the RTP MIDI stream.

The cancellation feature lets a sender start the transmission of a
command before the MIDI source has sent the entire command. If a
sender determines that the command whose transmission is in progress
should not appear on the RTP stream, it cancels the command. Without
a method for cancelling a SysEx command transmission, senders would
be forced to use a high-latency store-and-forward approach to
transcoding SysEx commands onto RTP MIDI packets, in order to
validate each SysEx command before transmission.

The recommended receiver reaction to a cancellation depends on the
capabilities of the receiver. For example, a sound synthesizer that
is directly parsing RTP MIDI packets and rendering them to audio will
be aware of the fact that SysEx commands may be cancelled in RTP
MIDI. These receivers SHOULD detect a SysEx cancellation in the MIDI list,
list and act as if it they had never received the SysEx command.

As a second example, a synthesizer may be receiving MIDI data from an
RTP MIDI stream via a MIDI DIN cable (or a software API emulation of
a MIDI DIN cable). In this case, an RTP-MIDI aware RTP-MIDI-aware system receives
the RTP MIDI stream, stream and transcodes it onto the MIDI DIN cable (or its
emulation). Upon the receipt of the cancel sublist, the RTP-MIDI RTP-MIDI-
aware transcoder might have already sent the first part of the SysEx
command on the MIDI DIN cable to the receiver.

Unfortunately, the MIDI DIN cable protocol cannot directly code
"cancel SysEx in progress" semantics. However, MIDI DIN cable
receivers begin SysEx processing after the complete command arrives.
The receiver checks to see if it recognizes the command (coded in the
first few octets) and then checks to see if the command is the
correct length. Thus, in practice, a transcoder can cancel a SysEx
command by sending an 0xF7 to (prematurely) end the SysEx command --
the receiver will detect the incorrect command length, length and discard the
command.

Appendix C.1 defines configuration tools that may be used to prohibit
SysEx command cancellation.

The relative ordering of SysEx command segments in a MIDI list must
match the relative ordering of the sublists in the original SysEx
command. By default, commands other than System Real-time MIDI
commands MUST NOT appear between SysEx command segments (Appendix C.1
defines configuration tools to change this default, to let other
commands types appear between segments). If the command segments of
a SysEx command are placed in the MIDI lists of two or more RTP
packets, the segment ordering rules apply to the concatenation of all
affected MIDI lists.

-----------------------------------------------------------
| Sublist Position | Head Status Octet | Tail Status Octet |
|-----------------------------------------------------------|
| first | 0xF0 | 0xF0 |
|-----------------------------------------------------------|
| middle | 0xF7 | 0xF0 |
|-----------------------------------------------------------|
| last | 0xF7 | 0xF7 |
|-----------------------------------------------------------|
| cancel | 0xF7 | 0xF4 |
-----------------------------------------------------------

Figure 5 -- Command segmentation status octets

[MIDI] permits 0xF7 octets that are not part of a (0xF0, 0xF7) pair
to appear on a MIDI 1.0 DIN cable. Unpaired 0xF7 octets have no
semantic meaning in MIDI, apart from cancelling running status.

Unpaired 0xF7 octets MUST NOT appear in the MIDI list of the MIDI
Command section. We impose this restriction to avoid interference
with the command segmentation coding defined in Figure 5.

SysEx commands carried on a MIDI 1.0 DIN cable may use the "dropped
0xF7" construction [MIDI]. In this coding method, the 0xF7 octet is
dropped from the end of the SysEx command, and the status octet of
the next MIDI command acts both to terminate the SysEx command and
start the next command. To encode this construction in the payload
format, follow these steps:

o Determine the appropriate delta times for the SysEx command and
the command that follows the SysEx command.

o Insert the "dropped" 0xF7 octet at the end of the SysEx command,
to form the standard SysEx syntax.

o Code both commands into the MIDI list using the rules above.

o Replace the 0xF7 octet that terminates the verbatim SysEx
encoding or the last segment of the segmented SysEx encoding
with a 0xF5 octet. This substitution informs the receiver of
the original dropped 0xF7 coding.

[MIDI] reserves the undefined System Common commands 0xF4 and 0xF5
and the undefined System Real-time commands 0xF9 and 0xFD for future
use. By default, undefined commands MUST NOT appear in a MIDI
Command field in the MIDI list, with the exception of the 0xF5 octets
used to code the "dropped 0xF7" construction and the 0xF4 octets used
by SysEx "cancel" sublists.

During session configuration, a stream may be customized to transport
undefined commands (Appendix C.1). For this case, we now define how
senders encode undefined commands in the MIDI list.

An undefined System Real-time command MUST be coded using the System
Real-time rules.

If the undefined System Common commands are put to use in a future
version of [MIDI], the command will begin with an 0xF4 or 0xF5 status
octet, followed by an arbitrary number of data octets (i.e. (i.e., zero or
more data bytes). To encode these commands, senders MUST terminate
the command with an 0xF7 octet, octet and place the modified command into
the MIDI Command field.

Unfortunately, non-compliant uses of the undefined System Common
commands may appear in MIDI implementations. To model these
commands, we assume that the command begins with an 0xF4 or 0xF5
status octet, followed by zero or more data octets, followed by zero
or more trailing 0xF7 status octet(s). octets. To encode the command, senders
MUST first remove all trailing 0xF7 status octets from the command.
Then, senders MUST terminate the command with an 0xF7 octet, octet and place
the modified command into the MIDI Command field.

Note that we include the trailing octets in our model as a cautionary
measure: if such commands appeared in a non-compliant use of an
undefined System Common command, an RTP MIDI encoding of the command
that did not remove trailing octets could be mistaken for an encoding
of "middle" or "last" sublist of a segmented SysEx commands (Figure
5) under certain packet loss conditions.

Original SysEx command:

0xF0 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0xF7

A two-segment segmentation:

0xF0 0x01 0x02 0x03 0x04 0xF0

0xF7 0x05 0x06 0x07 0x08 0xF7

A different two-segment segmentation:

0xF0 0x01 0xF0

0xF7 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0xF7

A three-segment segmentation:

0xF0 0x01 0x02 0xF0

0xF7 0x03 0x04 0xF0

0xF7 0x05 0x06 0x07 0x08 0xF7

The segmentation with the largest number of segments:

0xF0 0x01 0xF0

0xF7 0x02 0xF0

0xF7 0x03 0xF0

0xF7 0x04 0xF0

0xF7 0x05 0xF0

0xF7 0x06 0xF0

0xF7 0x07 0xF0

0xF7 0x08 0xF0

0xF7 0xF7

Figure 6 -- Example segmentations

4. The Recovery Journal System

The recovery journal is the default resiliency tool for unreliable
transport. In this section, we normatively define the roles that
senders and receivers play in the recovery journal system.

MIDI is a fragile code. A single lost command in a MIDI command
stream may produce an artifact in the rendered performance. We
normatively classify rendering artifacts into two categories:

o Transient artifacts. Transient artifacts produce immediate but
short-term glitches in the performance. For example, a lost
NoteOn (0x9) command produces a transient artifact: one note
fails to play, but the artifact does not extend beyond the end of
that note.

o Indefinite artifacts. Indefinite artifacts produce long-lasting
errors in the rendered performance. For example, a lost NoteOff
(0x8) command may produce an indefinite artifact: the note that
should have been ended by the lost NoteOff command may sustain
indefinitely. As a second example, the loss of a Control Change
(0xB) command for controller number 7 (Channel Volume) may
produce an indefinite artifact: after the loss, all notes on the
channel may play too softly or too loudly.

The purpose of the recovery journal system is to satisfy the recovery
journal mandate: the MIDI performance rendered from an RTP MIDI
stream sent over unreliable transport MUST NOT contain indefinite
artifacts.

The recovery journal system does not use packet retransmission to
satisfy this mandate. Instead, each packet includes a special
section, called the recovery journal.

The recovery journal codes the history of the stream, back to an
earlier packet called the checkpoint packet. The range of coverage
for the journal is called the checkpoint history. The recovery
journal codes the information necessary to recover from the loss of
an arbitrary number of packets in the checkpoint history. Appendix
A.1 normatively defines the checkpoint packet and the checkpoint
history.

When a receiver detects a packet loss, it compares its own knowledge
about the history of the stream with the history information coded in
the recovery journal of the packet that ends the loss event. By
noting the differences in these two versions of the past, a receiver
is able to transform all indefinite artifacts in the rendered
performance into transient artifacts, by executing MIDI commands to
repair the stream.

We now state the normative role for senders in the recovery journal
system.

Senders prepare a recovery journal for every packet in the stream.
In doing so, senders choose the checkpoint packet identity for the
journal. Senders make this choice by applying a sending policy.
Appendix C.2.2 normatively defines three sending policies: "closed-loop", "closed-
loop", "open-loop", and "anchor".

By default, senders MUST use the closed-loop sending policy. If the
session description overrides this default policy, by using the
parameter j_update defined in Appendix C.2.2, senders MUST use the
specified policy.

After choosing the checkpoint packet identity for a packet, the
sender creates the recovery journal. By default, this journal MUST
conform to the normative semantics in Section 5 and Appendices A-B in
this memo. In Appendix C.2.3, we define parameters that modify the
normative semantics for recovery journals. If the session
description uses these parameters, the journal created by the sender
MUST conform to the modified semantics.

Next, we state the normative role for receivers in the recovery
journal system.

A receiver MUST detect each RTP sequence number break in a stream.
If the sequence number break is due to a packet loss event (as
defined in
[RFC3550]) [RFC3550]), the receiver MUST repair all indefinite
artifacts in the rendered MIDI performance caused by the loss. If
the sequence number break is due to an out-of-order packet (as
defined in [RFC3550]) [RFC3550]), the receiver MUST NOT take actions that
introduce indefinite artifacts (ignoring the out-of-order packet is a
safe option).

Receivers take special precautions when entering or exiting a
session. A receiver MUST process the first received packet in a
stream as if it were a packet that ends a loss event. Upon exiting a
session, a receiver MUST ensure that the rendered MIDI performance
does not end with indefinite artifacts.

Receivers are under no obligation to perform indefinite artifact
repairs at the moment a packet arrives. A receiver that uses a
playout buffer may choose to wait until the moment of rendering
before processing the recovery journal, as the "lost" packet may be a
late packet that arrives in time to use.

Next, we state the normative role for the creator of the session
description in the recovery journal system. Depending on the
application, the sender, the receivers, and other parties may take
part in creating or approving the session description.

A session description that specifies the default closed-loop sending
policy and the default recovery journal semantics satisfies the
recovery journal mandate. However, these default behaviors may not
be appropriate for all sessions. If the creators of a session
description use the parameters defined in Appendix C.2 to override
these defaults, the creators MUST ensure that the parameters define a
system that
satisfy satisfies the recovery journal mandate.

Finally, we note that this memo does not specify sender or receiver
recovery journal algorithms. Implementations are free to use any
algorithm that conforms to the requirements in this section. The non-
normative [GUIDE]
non-normative [RFC4696] discusses sender and receiver algorithm
design.

5. Recovery Journal Format

This section introduces the structure of the recovery journal, journal and
defines the bitfields of recovery journal headers. Appendices A-B
complete the bitfield definition of the recovery journal.

The recovery journal has a three-level structure:

o Top-level header.

o Channel and system journal headers. Encodes These headers encode
recovery information for a single voice channel (channel journal)
or for all systems commands (system journal).

o Chapters. Describes Chapters describe recovery information for a single
MIDI command type.

Figure 7 shows the top-level structure of the recovery journal. The
recovery journals consists of a 3-octet header, followed by an
optional system journal (labeled S-journal in Figure 7) and an
optional list of channel journals. Figure 8 shows the recovery
journal header format.

0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Recovery journal header | S-journal ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Channel journals ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 7 -- Top-level recovery journal format

0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S|Y|A|H|TOTCHAN| Checkpoint Packet Seqnum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 8 -- Recovery journal header

If the Y header bit is set to 1, the system journal appears in the
recovery journal, directly following the recovery journal header.

If the A header bit is set to 1, the recovery journal ends with a
list of (TOTCHAN + 1) channel journals (the 4-bit TOTCHAN header
field is interpreted as an unsigned integer).

A MIDI channel MAY be represented by (at most) one channel journal in
a recovery journal. Channel journals MUST appear in the recovery
journal in ascending channel-number order.

If A and Y are both zero, the recovery journal only contains its 3-octet
header, 3-
octet header and is considered to be an "empty" journal.

The S (single-packet loss) bit appears in most recovery journal
structures, including the recovery journal header. The S bit helps
receivers efficiently parse the recovery journal in the common case
of the loss of a single packet. Appendix A.1 defines S bit
semantics.

The H bit indicates if MIDI channels in the stream have been
configured to use the enhanced Chapter C encoding (Appendix A.3.3).

By default, the payload format does not use enhanced Chapter C
encoding. In this default case, the H bit MUST be set to 0 for all
packets in the stream.

If the stream has been configured so that controller numbers for one
or more MIDI channels use enhanced Chapter C encoding, the H bit MUST
be set to 1 in all packets in the stream. In Appendix C.2.3, we show
how to configure a stream to use enhanced Chapter C encoding.

The 16-bit Checkpoint Packet Seqnum header field codes the sequence
number of the checkpoint packet for this journal, in network byte
order (big-endian). The choice of the checkpoint packet sets the
depth of the checkpoint history for the journal (defined in Appendix
A.1).

Receivers may use the Checkpoint Packet Seqnum field of the packet
that ends a loss event to verify that the journal checkpoint history
covers the entire loss event. The checkpoint history covers the loss
event if the Checkpoint Packet Seqnum field is less than or equal to
one plus the highest RTP sequence number previously received on the
stream (modulo 2^16).

0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| CHAN |H| LENGTH |P|C|M|W|N|E|T|A| Chapters ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 9 -- Channel journal format

Figure 9 shows the structure of a channel journal: a 3-octet header,
followed by a list of leaf elements called channel chapters. A
channel journal encodes information about MIDI commands on the MIDI
channel coded by the 4-bit CHAN header field. Note that CHAN uses
the same bit encoding as the channel nibble in MIDI Channel Messages
(the cccc field in Figure E.1 of Appendix E).

The 10-bit LENGTH field codes the length of the channel journal. The
semantics for LENGTH fields are uniform throughout the recovery
journal, and are defined in Appendix A.1.

The third octet of the channel journal header is the Table of
Contents (TOC) of the channel journal. The TOC is a set of bits that
encode the presence of a chapter in the journal. Each chapter
contains information about a certain class of MIDI channel command:

o Chapter P: MIDI Program Change (0xC)
o Chapter C: MIDI Control Change (0xB)
o Chapter M: MIDI Parameter System (part of 0xB)
o Chapter W: MIDI Pitch Wheel (0xE)
o Chapter N: MIDI NoteOff (0x8), NoteOn (0x9)
o Chapter E: MIDI Note Command Extras (0x8, 0x9)
o Chapter T: MIDI Channel Aftertouch (0xD)
o Chapter A: MIDI Poly Aftertouch (0xA)

Chapters appear in a list following the header, in order of their
appearance in the TOC. Appendices A.2-9 describe the bitfield format
for each chapter, and define the conditions under which a chapter
type MUST appear in the recovery journal. If any chapter types are
required for a channel, an associated channel journal MUST appear in
the recovery journal.

The H bit indicates if controller numbers on a MIDI channel have been
configured to use the enhanced Chapter C encoding (Appendix A.3.3).

By default, controller numbers on a MIDI channel do not use enhanced
Chapter C encoding. In this default case, the H bit MUST be set to 0
for all channel journal headers for the channel in the recovery
journal, for all packets in the stream.

However, if at least one controller number for a MIDI channel has
been configured to use the enhanced Chapter C encoding, the H bit for
its channel journal MUST be set to 1, for all packets in the stream.

In Appendix C.2.3, we show how to configure a controller number to
use enhanced Chapter C encoding.

0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S|D|V|Q|F|X| LENGTH | System chapters ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 10 -- System journal format

Figure 10 shows the structure of the system journal: a 2-octet
header, followed by a list of system chapters. Each chapter codes
information about a specific class of MIDI Systems command:

o Chapter D: Song Select (0xF3), Tune Request (0xF6), Reset
(0xFF), undefined System commands (0xF4, 0xF5, 0xF9,
0xFD)
o Chapter V: Active Sense (0xFE)
o Chapter Q: Sequencer State (0xF2, 0xF8, 0xF9, 0xFA, 0xFB, 0xFC)
o Chapter F: MTC Tape Position (0xF1, 0xF0 0x7F 0xcc 0x01 0x01)
o Chapter X: System Exclusive (all other 0xF0)

The 10-bit LENGTH field codes the size of the system journal, journal and
conforms to semantics described in Appendix A.1.

The D, V, Q, F, and X header bits form a Table of Contents (TOC) for
the system journal. A TOC bit that is set to 1 codes the presence of
a chapter in the journal. Chapters appear in a list following the
header, in the order of their appearance in the TOC.

Appendix B describes the bitfield format for the system chapters, chapters and
define
defines the conditions under which a chapter type MUST appear in the
recovery journal. If any system chapter type is required to appear
in the recovery journal, the system journal MUST appear in the
recovery journal.

6. Session Description Protocol

RTP does not perform session management. Instead, RTP works together
with session management tools, such as the Session Initiation
Protocol (SIP, [RFC3261]) and the Real Time Streaming Protocol (RTSP,
[RFC2326]).

RTP payload formats define media type parameters for use in session
management (for example, this memo defines "rtp-midi" as the media
type for native RTP MIDI streams).

In most cases, session management tools use the media type parameters
via another standard, the Session Description Protocol (SDP, [SDP]).
[RFC4566]).

SDP is a textual format for specifying session descriptions. Session
descriptions specify the network transport and media encoding for RTP
sessions. Session management tools coordinate the exchange of
session descriptions between participants ("parties").

Some session management tools use SDP to negotiate details of media
transport (network addresses, ports, etc). etc.). We refer to this use of
SDP as "negotiated usage". One example of negotiated usage is the
Offer/Answer protocol ([RFC3264] and Appendix C.7.2 in this memo) as
used by SIP.

Other session management tools use SDP to declare the media encoding
for the session, session but use other techniques to negotiate network
transport. We refer to this use of SDP as "declarative usage". One
example of declarative usage is RTSP ([RFC2326] and Appendix C.7.1 in
this memo).

Below, we show session description examples for native (Section 6.1)
and mpeg4-generic (Section 6.2) streams. In Section 6.3, we
introduce session configuration tools that may be used to customize
streams.

6.1

6.1. Session Descriptions for Native Streams

The session description below defines a unicast UDP RTP session (via
a media ("m=") line) whose sole payload type (96) is mapped to a
minimal native RTP MIDI stream.

v=0
o=lazzaro 2520644554 2838152170 IN IP4 first.example.net
s=Example
t=0 0
m=audio 5004 RTP/AVP 96
c=IN IP4 192.0.2.94
a=rtpmap:96 rtp-midi/44100

The rtpmap attribute line uses the "rtp-midi" media type to specify
an RTP MIDI native stream. The clock rate specified on the rtpmap
line (in the example above, 44100 Hz) sets the scaling for the RTP
timestamp header field (see Section 2.1, and also [RFC3550]).

Note that this document does not specify a default clock rate value
for RTP MIDI. When RTP MIDI is used with SDP, parties MUST use the
rtpmap line to communicate the clock rate. Guidance for selecting
the RTP MIDI clock rate value appears in Section 2.1.

We consider the RTP MIDI stream shown above to be "minimal" because
the session description does not customize the stream with
parameters. Without such customization, a native RTP MIDI stream has
these characteristics:

1. If the stream uses unreliable transport (unicast UDP, multicast
UDP, ...), etc.), the recovery journal system is in use, and the RTP
payload contains both the MIDI command section and the journal
section. If the stream uses reliable transport (such as TCP),
the stream does not use journalling, and the payload contains
only the MIDI command section (Section 2.2).

2. If the stream uses the recovery journal system, the recovery
journal system uses the default sending policy and the default
journal semantics (Section 4).

3. In the MIDI command section of the payload, command timestamps
use the default "comex" semantics (Section 3).

4. The recommended temporal duration ("media time") of an RTP
packet ranges from 0 to 200 ms, and the RTP timestamp difference
between sequential packets in the stream may be arbitrarily
large (Section 2.1).

5. If more than one minimal rtp-midi stream appears in a session,
the MIDI name spaces for these streams are independent: channel
1 in the first stream does not reference the same MIDI channel
as channel 1 in the second stream (see Appendix C.5 for a
discussion of the independence of minimal rtp-midi streams).

6. The rendering method for the stream is not specified. What a
what the
receiver "does" with a minimal native MIDI stream is "out of
scope" of this memo. For example, in content creation
environments, a user may manually configure client software to
render the stream with a specific software package.

As in standard in RTP, RTP sessions managed by SIP are sendrecv by
default (parties send and receive MIDI), and RTP sessions managed by
RTSP are recvonly by default (server sends and client receives).

In sendrecv RTP MIDI sessions for the session description shown
above, the 16 voice channel + systems MIDI name space is unique for
each sender. Thus, in a two party two-party session, the voice channel 0 sent
by one party is distinct from the voice channel 0 sent by the other
party.

This behavior corresponds to what occurs when two MIDI 1.0 DIN
devices are cross-connected with two MIDI cables (one cable routing
MIDI Out from the first device into MIDI In of the second device, a
second cable routing MIDI In from the first device into MIDI Out of
the second device). We define this "association" formally in Section
2.1.

MIDI 1.0 DIN networks may be configured in a "party-line" multicast
topology. For these networks, the MIDI protocol itself provides
tools for addressing specific devices in transactions on a multicast
network, and for device discovery. Thus, apart from providing a 1-to-many 1-
to-many forward path and a many-to-1 reverse path, IETF protocols do
not need to provide any special support for MIDI multicast
networking.

6.2

6.2. Session Descriptions for mpeg4-generic Streams

An mpeg4-generic [RFC3640] RTP MIDI stream uses an MPEG 4 Audio
Object Type to render MIDI into audio. Three Audio Object Types
accept MIDI input:

o General MIDI (Audio Object Type ID 15), based on the General MIDI
rendering standard [MIDI].

o Wavetable Synthesis (Audio Object Type ID 14), based on the
Downloadable Sounds Level 2 (DLS 2) rendering standard [DLS2].

o Main Synthetic (Audio Object Type ID 13), based on Structured
Audio and the programming language SAOL [MPEGSA].

The primary service of an mpeg4-generic stream is to code Access
Units (AUs). We define the mpeg4-generic RTP MIDI AU as the MIDI
payload shown in Figure 1 of Section 2.1 of this memo: a MIDI command
section optionally followed by a journal section.

Exactly one RTP MIDI AU MUST be mapped to one mpeg4-generic RTP MIDI
packet. The mpeg4-generic options for placing several AUs in an RTP
packet MUST NOT be used with RTP MIDI. The mpeg4-generic options for
fragmenting and interleaving AUs MUST NOT be used with RTP MIDI. The
mpeg4-generic RTP packet payload (Figure 1 in [RFC3640]) MUST contain
empty AU Header and Auxiliary sections. These rules yield mpeg4-generic mpeg4-
generic packets that are structurally identical to native RTP MIDI
packets, an essential property for the correct operation of the
payload format.

The session description below that follows defines a unicast UDP RTP
session (via a media ("m=") line) whose sole payload type (96) is
mapped to a minimal mpeg4-generic RTP MIDI stream. This example uses
the General MIDI Audio Object Type under Synthesis Profile @ Level 2.

v=0
o=lazzaro 2520644554 2838152170 IN IP6 first.example.net
s=Example
t=0 0
m=audio 5004 RTP/AVP 96
c=IN IP6 2001:DB80::7F2E:172A:1E24
a=rtpmap:96 mpeg4-generic/44100
a=fmtp:96 streamtype=5; mode=rtp-midi; profile-level-id=12;
config=7A0A0000001A4D546864000000060000000100604D54726B0000
000600FF2F000

(The a=fmtp line has been wrapped to fit the page to accommodate memo
formatting restrictions; it comprises a single line in SDP) SDP.)

The fmtp attribute line codes the four parameters (streamtype, mode,
profile-level-id, and config) that are required in all mpeg4-generic
session descriptions [RFC3640]. For RTP MIDI streams, the streamtype
parameter MUST be set to 5, the "mode" parameter MUST be set to "rtp-
midi",
"rtp-midi", and the "profile-level-id" parameter MUST be set to the
MPEG-4 Profile Level for the stream. For the Synthesis Profile,
legal profile-
level-id profile-level-id values are 11, 12, and 13, coding low (11),
medium (12), or high (13) decoder computational complexity, as
defined by MPEG conformance tests.

In a minimal RTP MIDI session description, the config value MUST be a
hexadecimal encoding [RFC3640] of the AudioSpecificConfig data block
[MPEGAUDIO] for the stream. AudioSpecificConfig encodes the Audio
Object Type for the stream, stream and also encodes initialization data (SAOL
programs, DLS 2 wave tables, etc). etc.). Standard MIDI Files encoded in
AudioSpecificConfig in a minimal session description MUST be ignored
by the receiver.

Receivers determine the rendering algorithm for the session by
interpreting the first 5 bits of AudioSpecificConfig as an unsigned
integer that codes the Audio Object Type. In our example above, the
leading config string nibbles "7A" yield the Audio Object Type 15
(General MIDI). In Appendix E.4, we derive the config string value
in the session description shown above; the starting point of the
derivation is the MPEG bitstreams defined in [MPEGSA] and
[MPEGAUDIO].

We consider the stream to be "minimal" because the session
description does not customize the stream through the use of
parameters, other than the 4 required mpeg4-generic parameters
described above. In Section 6.1, we describe the behavior of a
minimal native stream, as a numbered list of characteristics. Items
1-4 on that list also describe the minimal mpeg4-generic stream, but
items 5 and 6 require restatements, as listed below:

5. If more than one minimal mpeg4-generic stream appears in a
session, each stream uses an independent instance of the Audio
Object Type coded in the config parameter value.

6. A minimal mpeg4-generic stream encodes the AudioSpecificConfig
as an inline hexadecimal constant. If a session description is
sent over UDP, it may be impossible to transport large
AudioSpecificConfig blocks within the Maximum Transmission Size
(MTU) of the underlying network (for Ethernet, the MTU is 1500
octets). In some cases, the AudioSpecificConfig block may
exceed the maximum size of the UDP packet itself.

The comments in Section 6.1 on SIP and RTSP stream directional
defaults, sendrecv MIDI channel usage usage, and MIDI 1.0 DIN multicast
networks also apply to mpeg4-generic RTP MIDI sessions.

In sendrecv sessions, each party's session description MUST use
identical values for the mpeg4-generic parameters (including the
required streamtype, mode, profile-level-id, and config parameters).
As a consequence, each party uses an identically-configured identically configured MPEG 4
Audio Object Type to render MIDI commands into audio. The preamble
to Appendix C discusses a way to create "virtual sendrecv" sessions
that do not have this restriction.

6.3

6.3. Parameters

This section introduces parameters for session configuration for RTP
MIDI streams. In session descriptions, parameters modify the
semantics of a payload type. Parameters are specified on a an fmtp
attribute line. See the session description example in Section 6.2
for an example of a fmtp attribute line.

The parameters add features to the minimal streams described in
Sections 6.1-2, and support several types of services:

o Stream subsetting. By default, all MIDI commands that are legal
to appear on a MIDI 1.0 DIN cable may appear in an RTP MIDI
stream. The cm_unused parameter overrides this default by
prohibiting certain commands from appearing in the stream. The
cm_used parameter is used in conjunction with cm_unused, to
simplify the specification of complex exclusion rules. We
describe cm_unused and cm_used in Appendix C.1.

o Journal customization. The j_sec and j_update parameters
configure the use of the journal section. The ch_default,
ch_never, and ch_anchor parameters configure the semantics of
the recovery journal chapters. These parameters are described
in Appendix C.2, C.2 and override the default stream behaviors 1 and 2
2, listed in Section 6.1 and referenced in Section 6.2.

o MIDI command timestamp semantics. The tsmode, octpos, mperiod,
and linerate parameters customize the semantics of timestamps in
the MIDI command section. These parameters let RTP MIDI
accurately encode the implicit time coding of MIDI 1.0 DIN
cables. These parameters are described in Appendix C.3, C.3 and
override default stream behavior 3 3, listed in Section 6.1 and
referenced in Section 6.2

o Media time. The rtp_ptime and rtp_maxptime parameters define
the temporal duration ("media time") of an RTP MIDI packet. The
guardtime parameter sets the minimum sending rate of stream
packets. These parameters are described in Appendix C.4, C.4 and
override default stream behavior 4 4, listed in Section 6.1 and
referenced in Section 6.2.

o Stream description. The musicport parameter labels the MIDI
name space of RTP streams in a multimedia session. Musicport is
described in Appendix C.5. The musicport parameter overrides
default stream behavior 5 5, in Sections 6.1 and 6.2.

o MIDI rendering. Several parameters specify the MIDI rendering
method of a stream. These parameters are described in Appendix C.6,
C.6 and override default stream behavior 6 6, in Sections 6.1 and
6.2.

In Appendix C.7, we specify interoperability guidelines for two RTP
MIDI application areas: content-streaming using RTSP (Appendix C.7.1)
and network musical performance using SIP (Appendix C.7.2).

7. Extensibility

The payload format defined in this memo exclusively encodes all
commands that may legally appear on a MIDI 1.0 DIN cable.

Many worthy uses of MIDI over RTP do not fall within the narrow scope
of the payload format. For example, the payload format does not
support the direct transport of Standard MIDI File (SMF) meta-event
and metric timing data. As a second example, the payload format does
not define transport tools for user-defined commands (apart from
tools to support System Exclusive commands [MIDI]).

The payload format does not provide an extension mechanism to support
new features of this nature, by design. Instead, we encourage the
development of new payload formats for specialized musical
applications. The IETF session management tools [RFC3264] [RFC2326]
support codec negotiation, to facilitate the use of new payload
formats in a backward-
compatible backward-compatible way.

However, the payload format does provide several extensibility tools,
which we list below:

o Journalling. As described in Appendix C.2, new token values for
the j_sec and j_update parameters may be defined in IETF
standards-track documents. This mechanism supports the design
of new journal formats and the definition of new journal sending
policies.

o Rendering. The payload format may be extended to support new
MIDI renderers (Appendix C.6.2). Certain general aspects of the
RTP MIDI rendering process may also be extended, via the
definition of new token values for the render (Appendix C.6) and
smf_info (Appendix C.6.4.1) parameters.

o Undefined commands. [MIDI] reserves 4 MIDI System commands for
future use (0xF4, 0xF5, 0xF9, 0xFD). If updates to [MIDI]
define the reserved commands, IETF standards-track documents may
be defined to provide resiliency support for the commands.

Opaque LEGAL fields appear in System Chapter D for this purpose
(Appendix B.1.1).

A final form of extensibility involves the inclusion of the payload
format in framework documents. Framework documents describe how to
combine protocols to form a platform for interoperable applications.
For example, a stage and studio framework might define how to use SIP
[RFC3261], RTSP [RFC2326], SDP [SDP] [RFC4566], and RTP [RFC3550] to
support media networking for professional audio equipment and
electronic musical instruments.

8. Congestion Control

The RTP congestion control requirements defined in [RFC3550] apply to
RTP MIDI sessions, and implementors should carefully read the
congestion control section in [RFC3550]. As noted in [RFC3550], all
transport protocols used on the Internet need to address congestion
control in some way, and RTP is not an exception.

In addition, the congestion control requirements defined in [RFC3551]
applies to RTP MIDI sessions run under applicable profiles. The
basic congestion control requirement defined in [RFC3551] is that RTP
sessions that use UDP transport should monitor packet loss (via RTCP, RTCP
or via other means) to ensure that the RTP stream competes fairly with
TCP flows that share the network.

Finally, RTP MIDI has congestion control issues that are unique for
an audio RTP payload format. In applications such as network musical
performance [NMP], the packet rate is linked to the gestural rate of
a human performer. Senders MUST monitor the MIDI command source for
patterns that result in excessive packet rates, rates and take actions
during RTP transcoding to reduce the RTP packet rate. [GUIDE] [RFC4696]
offers implementation guidance on this issue.

A. The Recovery Journal Channel Chapters

A.1 Recovery Journal Definitions

This Appendix defines the terminology and

9. Security Considerations

Implementors should carefully read the coding idioms that are
used in Security Considerations
sections of the recovery journal bitfield descriptions in Section 5 (journal
header structure), Appendices A.2-9 (channel journal chapters) RTP [RFC3550], AVP [RFC3551], and
Appendices B.1-5 (system journal chapters).

We assume that other RTP profile
documents, as the recovery journal resides issues discussed in these sections directly apply
to RTP MIDI streams. Implementors should also review the journal section of Secure
Real-time Transport Protocol (SRTP, [RFC3711]), an RTP packet with sequence number I ("packet I") and profile that
addresses the Checkpoint
Packet Seqnum field security issues discussed in the top-level recovery journal header refers to a
previous packet with sequence number C (an exception is the self-
referential C = I case). Unless stated otherwise, algorithms [RFC3550] and [RFC3551].

Here, we discuss security issues that are
assumed unique to use modulo 2^16 arithmetic for calculations on 16-bit
sequence numbers the RTP MIDI
payload format.

When using RTP MIDI, authentication of incoming RTP and modulo 2^32 arithmetic for calculations on 32-bit
extended sequence numbers.

Several bitfield coding idioms appear throughout RTCP packets
is RECOMMENDED. Per-packet authentication may be provided by SRTP or
by other means. Without the recovery journal
system, with consistent semantics. Most recovery journal elements begin
with use of authentication, attackers could
forge MIDI commands into an "S" (Single-packet loss) bit. S bits are designed ongoing stream, damaging speakers and
eardrums. An attacker could also craft RTP and RTCP packets to help
receivers efficiently parse through the recovery journal hierarchy
exploit known bugs in the common case client and take effective control of a
client machine.

Session management tools (such as SIP [RFC3261]) SHOULD use
authentication during the loss transport of a single packet.

As a rule, S bits MUST be set to 1. However, all session descriptions
containing RTP MIDI media streams. For SIP, the Security
Considerations section in [RFC3261] provides an exception applies if a
recovery journal element overview of possible
authentication mechanisms. RTP MIDI session descriptions should use
authentication because the session descriptions may code
initialization data using the parameters described in packet I encodes Appendix C. If
an attacker inserts bogus initialization data about into a command stored
in session
description, he can corrupt the MIDI command section of packet I - 1. In this case, session or forge an client attack.

Session descriptions may also code renderer initialization data by
reference, via the S bit of url (Appendix C.6.3) and smf_url (Appendix
C.6.4.2) parameters. If the recovery journal element MUST be set coded URL is spoofed, both session and
client are open to 0. If attack, even if the session description itself is
authenticated. Therefore, URLs specified in url and smf_url
parameters SHOULD use [RFC2818].

Section 2.1 allows streams sent by a recovery journal
element has its S bit set party in two RTP sessions to 0, all higher-level recovery journal
elements that contain it MUST also
have S bits that are set to 0,
including the top-level recovery journal header.

Other consistent bitfield coding idioms are described below:

o R flag bit. R flag bits same SSRC value and the same RTP timestamp initialization
value, under certain circumstances. Normally, these values are reserved
randomly chosen for future use. Senders
MUST set R bits to 0. Receivers MUST ignore R bit values.

o LENGTH field. All fields named LENGTH (as distinct from LEN)
code the number of octets in the structure that contains it,
including the header it resides each stream in and all hierarchical levels
below it. If a structure contains a LENGTH field, a receiver
MUST use the LENGTH field value session, to advance past the structure
during parsing, rather than use knowledge about make plaintext
guessing harder to do if the internal
format payloads are encrypted. Thus, Section
2.1 weakens this aspect of the structure. RTP security.

10. Acknowledgements

We now define normative terms used thank the networking, media compression, and computer music
community members who have commented or contributed to describe recovery journal
semantics.

o Checkpoint history. The checkpoint history of a recovery journal
is the concatenation of effort,
including Kurt B, Cynthia Bruyns, Steve Casner, Paul Davis, Robin
Davies, Joanne Dow, Tobias Erichsen, Nicolas Falquet, Dominique
Fober, Philippe Gentric, Michael Godfrey, Chris Grigg, Todd Hager,
Michel Jullian, Phil Kerr, Young-Kwon Lim, Jessica Little, Jan van
der Meer, Colin Perkins, Charlie Richmond, Herbie Robinson, Larry
Rowe, Eric Scheirer, Dave Singer, Martijn Sipkema, William Stewart,
Kent Terry, Magnus Westerlund, Tom White, Jim Wright, Doug Wyatt, and
Giorgio Zoia. We also thank the MIDI command sections members of packets C
through I - 1. The final command in the MIDI command section San Francisco Bay
Area music and audio community for
packet I - 1 is considered the most recent command; the first
command in creating the MIDI command section context for packet C is the oldest
command. If command X is less recent than command Y, X is
considered to be "before Y". A checkpoint history with no
commands is considered to be empty. The checkpoint history
never contains the MIDI command work,
including Don Buchla, Chris Chafe, Richard Duda, Dan Ellis, Adrian
Freed, Ben Gold, Jaron Lanier, Roger Linn, Richard Lyon, Dana Massie,
Max Mathews, Keith McMillen, Carver Mead, Nelson Morgan, Tom
Oberheim, Malcolm Slaney, Dave Smith, Julius Smith, David Wessel, and
Matt Wright.

11. IANA Considerations

This section of the packet I (the
packet containing the recovery journal), so if C == I, the
checkpoint history is empty by definition.

o Session history. The session history of makes a recovery journal is
the concatenation of MIDI command sections from the first
packet series of the session up requests to packet I - 1. IANA. The definitions IANA has
completed registration/assignments of
command recency and history emptiness follow those in the
checkpoint history. below requests.

The session history never contains sub-sections that follow hold the
MIDI command actual, detailed requests. All
registrations in this section of packet I, are in the IETF tree and so follow the session history
rules of [RFC4288] and [RFC3555], as appropriate.

In Section 11.1, we request the first packet in the session is empty by definition.

o Finished/unfinished commands. If all octets registration of a MIDI command
appear in the session history, the command new media type:
"audio/rtp-midi". Paired with this request is defined to be
finished. If some but not all octets of a command appear
in the session history, the command is defined to be unfinished.
Unfinished commands occur if segments of request for a SysEx command appear
in
repository for new values for several RTP packets. For example, if a SysEx command is coded
as 3 segments, parameters associated with segment 1 in packet K, segment 2 in packet
K + 1, and segment 3
"audio/rtp-midi". We request this repository in packet K + 2, the session histories for
packets K + 1 and K + 2 contain unfinished versions of Section 11.1.1.

In Section 11.2, we request the command.
A session history contains a finished version registration of a cancelled SysEx
command if the history contains the cancel sublist new value ("rtp-
midi") for the command.

o Reset State commands. Reset State (RS) commands reset
renderers to an initialized "powerup" condition. The
RS commands are: System Reset (0xFF), General MIDI System Enable
(0xF0 0x7E 0xcc 0x09 0x01 0xF7), General MIDI 2 System Enable
(0xF0 0x7E 0xcc 0x09 0x03 0xF7), General MIDI System Disable
(0xF0 0x7E 0xcc 0x09 0x00 0xF7), Turn DLS On (0xF0 0x7E 0xcc 0x0A
0x01 0xF7) and Turn DLS Off (0xF0 0x7E 0xcc 0x0A 0x02 0xF7).
Registrations of subrender "mode" parameter token values (Appendix C.6.2)
and IETF standards-track documents MAY specify additional
RS commands.

o Active commands. Active command are MIDI commands that do not
appear before a Reset State command in the session history.

o N-active commands. N-active commands are MIDI commands that do
not appear before one of the following commands "mpeg4-generic" media type.
The "mpeg4-generic" media type is defined in the session
history: MIDI Control Change numbers 123-127 (numbers with All
Notes Off semantics) or 120 (All Sound Off), [RFC3640], and any Reset
State command.

o C-active commands. C-active commands [RFC3640]
defines a repository for the "mode" parameter. However, we believe
we are MIDI commands that do
not appear before one of the following commands in first to request the session
history: MIDI Control Change number 121 (Reset All Controllers)
and any Reset State command.

o Oldest-first ordering rule. Several recovery journal chapters
contain a list registration of elements, where each element is associated
with a MIDI command that appears in the session history. In
most cases, "mode" value, so we
believe the chapter definition requires that list elements
be ordered in accordance registry for "mode" has not yet been created by IANA.

Paired with the "oldest-first ordering rule".
Below, our "mode" parameter value request for "mpeg4-generic" is
a request for a repository for new values for several parameters we normatively define
have defined for use with the "rtp-midi" mode value. We request this rule:

Elements
repository in Section 11.2.1.

In Section 11.3, we request the registration of a new media type:
"audio/asc". No repository request is associated with this request.

11.1. rtp-midi Media Type Registration

This section requests the most recent command in registration of the session
history coded in "rtp-midi" subtype for
the list MUST appear at "audio" media type. We request the end registration of the list.

Elements associated with the oldest command
parameters listed in the session
history coded in "optional parameters" section below (both
the list MUST appear at "non-extensible parameters" and the start "extensible parameters"
lists). We also request the creation of repositories for the list.

All other list elements MUST be arranged with respect to these
boundary elements, to produce a list ordering that strictly
reflects
"extensible parameters"; the relative session history recency details of the commands
coded by the elements this request appear in the list.

o Parameter system. A MIDI feature that provides two sets of
16,384 parameters to expand the 0-127 controller number space.
Section 11.1.1, below.

Media type name:

audio

Subtype name:

rtp-midi
Required parameters:

rate: The Registered Parameter Names (RPN) system RTP timestamp clock rate. See Sections 2.1 and the Non-Registered
Parameter Names (NRPN) system each provides 16,384 parameters.

o Parameter system transaction. 6.1
for usage details.

Optional parameters:

Non-extensible parameters:

ch_anchor: See Appendix C.2.3 for usage details.
ch_default: See Appendix C.2.3 for usage details.
ch_never: See Appendix C.2.3 for usage details.
cm_unused: See Appendix C.1 for usage details.
cm_used: See Appendix C.1 for usage details.
chanmask: See Appendix C.6.4.3 for usage details.
cid: See Appendix C.6.3 for usage details.
guardtime: See Appendix C.4.2 for usage details.
inline: See Appendix C.6.3 for usage details.
linerate: See Appendix C.3 for usage details.
mperiod: See Appendix C.3 for usage details.
multimode: See Appendix C.6.1 for usage details.
musicport: See Appendix C.5 for usage details.
octpos: See Appendix C.3 for usage details.
rinit: See Appendix C.6.3 for usage details.
rtp_maxptime: See Appendix C.4.1 for usage details.
rtp_ptime: See Appendix C.4.1 for usage details.
smf_cid: See Appendix C.6.4.2 for usage details.
smf_inline: See Appendix C.6.4.2 for usage details.
smf_url: See Appendix C.6.4.2 for usage details.
tsmode: See Appendix C.3 for usage details.
url: See Appendix C.6.3 for usage details.

Extensible parameters:

j_sec: See Appendix C.2.1 for usage details. See
Section 11.1.1 for repository details.
j_update: See Appendix C.2.2 for usage details. See
Section 11.1.1 for repository details.
render: See Appendix C.6 for usage details. See
Section 11.1.1 for repository details.
subrender: See Appendix C.6.2 for usage details. See
Section 11.1.1 for repository details.
smf_info: See Appendix C.6.4.1 for usage details. See
Section 11.1.1 for repository details.

Encoding considerations:

The value of RPNs format for this type is framed and NRPNs are
changed by a series binary.

Restrictions on usage:

This type is only defined for real-time transfers of Control Change commands that form a
parameter system transaction. A canonical transaction begins
with two Control Change commands to set MIDI
streams via RTP. Stored-file semantics for rtp-midi may
be defined in the parameter number
(controller numbers 99 future.

Security considerations:

See Section 9 of this memo.

Interoperability considerations:

None.

Published specification:

This memo and 98 for NRPNs, [MIDI] serve as the normative specification. In
addition, references [NMP], [GRAME], and [RFC4696] provide
non-normative implementation guidance.

Applications that use this media type:

Audio content-creation hardware, such as MIDI controller numbers 101 piano
keyboards and 100 MIDI audio synthesizers. Audio content-creation
software, such as music sequencers, digital audio workstations,
and soft synthesizers. Computer operating systems, for RPNs). The transaction continues with an arbitrary
number network
support of Data Entry (controller numbers 6 and 38), Data Increment
(controller number 96), MIDI Application Programmer Interfaces. Content
distribution servers and Data Decrement (controller number
97) Control Change commands terminals may use this media type for
low bit-rate music coding.

Additional information:

None.

Person & email address to set the parameter value. The
transaction ends with a second pair of (99, 98) or (101, 100)
Control contact for further information:

John Lazzaro <lazzaro@cs.berkeley.edu>

Intended usage:

COMMON.

Author:

John Lazzaro <lazzaro@cs.berkeley.edu>
Change commands that specify controller:

IETF Audio/Video Transport Working Group delegated
from the null parameter (MSB
value 0x7F, LSB value 0x7F).

Several variants IESG.

11.1.1. Repository Request for "audio/rtp-midi"

For the "rtp-midi" subtype, we request the creation of repositories
for extensions to the canonical transaction sequence following parameters (which are
possible. Most commonly, the terminal pair those listed as
"extensible parameters" in Section 11.1).

j_sec:

Registrations for this repository may only occur
via an IETF standards-track document. Appendix C.2.1
of (99, 98) or
(101, 100) Control Change commands this memo describes appropriate registrations for this
repository.

Initial values for this repository appear below:

"none": Defined in Appendix C.2.1 of this memo.
"recj": Defined in Appendix C.2.1 of this memo.

j_update:

Registrations for this repository may specify a parameter
other than the null parameter. In only occur
via an IETF standards-track document. Appendix C.2.2
of this case, the command
pair terminates the first transaction and starts a second
transaction. The command pair is considered to be a part
both transactions. This variant is legal and recommended memo describes appropriate registrations for this
repository.

Initial values for this repository appear below:

"anchor": Defined in [MIDI]. We refer to Appendix C.2.2 of this variant as a "type 1 variant".

Less commonly, the MSB (99 or 101) or LSB (98 or 100) command memo.
"open-loop": Defined in Appendix C.2.2 of this memo.
"closed-loop": Defined in Appendix C.2.2 of this memo.

render:

Registrations for this repository MUST include a (99, 98) or (101, 100) Control Change pair may be omitted.

If
specification of the MSB command is omitted, usage of the transaction uses proposed value.
See text in the MSB value preamble of the most recent C-active Control Change command Appendix C.6 for controller
number 99 or 101 details
(the paragraph that appears begins "Other render token ...").

Initial values for this repository appear below:

"unknown": Defined in the session history. We refer to Appendix C.6 of this variant as a "type 2 variant".

If the LSB command is omitted, the LSB value 0x00 is assumed. We
refer to memo.
"synthetic": Defined in Appendix C.6 of this variant as a "type 3 variant". The type 2 and type 3
variants are defined as legal, but are not recommended, memo.
"api": Defined in [MIDI].

System real-time commands may appear at any point during
a transaction (even between octets Appendix C.6 of individual commands this memo.
"null": Defined in Appendix C.6 of this memo.

subrender:

Registrations for this repository MUST include a
specification of the transaction). More generally, [MIDI] does not forbid usage of the appearance proposed value.
See text Appendix C.6.2 for details (the paragraph
that begins "Other subrender token ...").

Initial values for this repository appear below:

"default": Defined in Appendix C.6.2 of unrelated MIDI commands during an open
transaction. As this memo.

smf_info:

Registrations for this repository MUST include a rule, these commands are considered to
be "outside" the transaction, and do not effect
specification of the status usage of the transaction proposed value.
See text in any way. Exceptions to Appendix C.6.4.1 for details (the
paragraph that begins "Other smf_info token ...").

Initial values for this rule are
commands whose semantics act to terminate transactions:
Reset State commands, and Control Change (0xB) for controller
number 121 (Reset All Controllers) [RP015].

o Initiated parameter system transaction. A canonical parameter
system transaction whose (99, 98) or (101, 100) initial Control
Change command pair appears repository appear below:

"ignore": Defined in the session history is considered
to be an initiated parameter system transaction. Appendix C.6.4.1 of this memo.
"sdp_start": Defined in Appendix C.6.4.1 of this memo.
"identity": Defined in Appendix C.6.4.1 of this memo.

11.2. mpeg4-generic Media Type Registration

This definition
also holds section requests the registration of the "rtp-midi" value for type 1 variants. For type 2 variants (dropped MSB),
a transaction whose initial LSB Control Change command appears in
the session history is an initiated transaction. For "mode" parameter of the "mpeg4-generic" media type. The "mpeg4-
generic" media type 3
variants (dropped LSB), a transaction is considered defined in [RFC3640], and [RFC3640] defines a
repository for the "mode" parameter. We are registering mode rtp-
midi to be
initiated if at least one transaction command follows support the initial
MSB (99 or 101) Control Change command in MPEG Audio codecs [MPEGSA] that use MIDI.

In conjunction with this registration request, we request the session history.
The completion
registration of a transaction does not nullify its "initiated"
status.

o Session history reference counts. Several recovery journal
chapters include a reference count field, which codes the
total number of commands of a type that appear parameters listed in the session
history. Examples include "optional parameters"
section below (both the Reset and Tune Request command
logs (Chapter D, Appendix B.1) "non-extensible parameters" and the Active Sense command
(Chapter V, Appendix B.2). Upon
"extensible parameters" lists). We also request the detection of a loss event,
reference count fields let a receiver deduce if any instances creation of
the command have been lost, by comparing the journal reference
count with its own reference count. Thus, a reference count
field makes sense, even
repositories for command types in which knowing the
NUMBER of lost commands is irrelevant (as is true with all of the example commands mentioned above).

The chapter definitions in Appendices A.2-9 and B.1-5 reflect "extensible parameters"; the
default recovery journal behavior. The ch_default, ch_never, and
ch_anchor parameters modify these definitions, as described details of this
request appear in Appendix
C.2.3. 11.2.1, below.

Media type name:

audio

Subtype name:

mpeg4-generic

Required parameters:

The chapter definitions specify if data MUST "mode" parameter is required by [RFC3640]. [RFC3640]
requests a repository for "mode", so that new values for mode
may be present in added. We request that the journal.
Senders MAY also include non-required data in value "rtp-midi" be
added to the journal. This
optional data MUST comply with "mode" repository.

In mode rtp-midi, the normative chapter definition. For
example, if a chapter definition states that mpeg4-generic parameter rate is
a field codes data from required parameter. Rate specifies the
most recent active command RTP timestamp
clock rate. See Sections 2.1 and 6.2 for usage details
of rate in mode rtp-midi.

Optional parameters:

We request registration of the session history, the sender MUST NOT
code inactive commands or older commands following parameters
for use in the field.

Finally, we note that a channel journal only encodes information about
MIDI commands appearing on the MIDI channel the journal protects. All
references to MIDI commands in Appendices A.2-9 should be read as "MIDI
commands appearing on this channel."

A.2 Chapter P: MIDI Program Change

A channel journal MUST contain Chapter P if an active Program Change
(0xC) command appears in the checkpoint history. Figure A.2.1 shows the mode rtp-midi for mpeg4-generic.

Non-extensible parameters:

smf_url: See Appendix C.6.4.2 for usage details.
tsmode: See Appendix C.3 for usage details.
url: See Appendix C.6.3 for usage details.

Extensible parameters:

j_sec: See Appendix C.2.1 for usage details. See
Section 11.2.1 for repository details.
j_update: See Appendix C.2.2 for usage details. See
Section 11.2.1 for repository details.
render: See Appendix C.6 for usage details. See
Section 11.2.1 for repository details.
subrender: See Appendix C.6.2 for usage details. See
Section 11.2.1 for repository details.
smf_info: See Appendix C.6.4.1 for usage details. See
Section 11.2.1 for repository details.

Encoding considerations:

The format for Chapter P.

0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 this type is framed and binary.

Restrictions on usage:

Only defined for real-time transfers of audio/mpeg4-generic
RTP streams with mode=rtp-midi.

Security considerations:

See Section 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| PROGRAM |B| BANK-MSB |X| BANK-LSB |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure A.2.1 -- Chapter P format

The chapter has a fixed size of 24 bits. The PROGRAM field indicates this memo.

Interoperability considerations:

Except for the data value of marker bit (Section 2.1), the most recent active Program Change command packet formats
for audio/rtp-midi and audio/mpeg4-generic (mode rtp-midi)
are identical. The formats differ in use: audio/mpeg4-generic
is for MPEG work, and audio/rtp-midi is for all other work.

Published specification:

This memo, [MIDI], and [MPEGSA] are the
session history. By default, the B, BANK-MSB, X, normative references.
In addition, references [NMP], [GRAME], and BANK-LSB fields
MUST be set to 0. Below, we define exceptions to [RFC4696] provide
non-normative implementation guidance.

Applications that use this default
condition.

If an active Control Change (0xB) command media type:

MPEG 4 servers and terminals that support [MPEGSA].

Additional information:

None.

Person & email address to contact for controller number 0 (Bank
Select MSB) appears before the Program further information:

John Lazzaro <lazzaro@cs.berkeley.edu>

Intended usage:

COMMON.

Author:

John Lazzaro <lazzaro@cs.berkeley.edu>

Change command in controller:

IETF Audio/Video Transport Working Group delegated
from the session
history, IESG.

11.2.1. Repository Request for Mode rtp-midi for mpeg4-generic

For mode rtp-midi of the B bit MUST be set mpeg4-generic subtype, we request the
creation of repositories for extensions to 1, and the BANK-MSB field following parameters
(which are those listed as "extensible parameters" in Section 11.2).

j_sec:

Registrations for this repository may only occur
via an IETF standards-track document. Appendix C.2.1
of this memo describes appropriate registrations for this
repository.

Initial values for this repository appear below:

"none": Defined in Appendix C.2.1 of this memo.
"recj": Defined in Appendix C.2.1 of this memo.

j_update:

Registrations for this repository may only occur
via an IETF standards-track document. Appendix C.2.2
of this memo describes appropriate registrations for this
repository.

Initial values for this repository appear below:

"anchor": Defined in Appendix C.2.2 of this memo.
"open-loop": Defined in Appendix C.2.2 of this memo.
"closed-loop": Defined in Appendix C.2.2 of this memo.

render:

Registrations for this repository MUST code include a
specification of the data value usage of the Control Change command.

If B is set to 1, proposed value.
See text in the BANK-LSB field preamble of Appendix C.6 for details
(the paragraph that begins "Other render token ...").

Initial values for this repository appear below:

"unknown": Defined in Appendix C.6 of this memo.
"synthetic": Defined in Appendix C.6 of this memo.
"null": Defined in Appendix C.6 of this memo.

subrender:

Registrations for this repository MUST code include a
specification of the data value usage of the
most recent Control Change command proposed value.
See text Appendix C.6.2 for controller number 32 (Bank Select
LSB) details (the paragraph
that preceded the Program Change command coded in the PROGRAM field begins "Other subrender token ..." and followed
subsequent paragraphs). Note that the Control Change command coded text in the BANK-MSB field. If
no such Control Change command exists, the BANK-LSB field
Appendix C.6.2 contains restrictions on subrender
registrations for mpeg4-generic ("Registrations
for mpeg4-generic subrender values ...").

Initial values for this repository appear below:

"default": Defined in Appendix C.6.2 of this memo.

smf_info:

Registrations for this repository MUST be set to
0.

If B is set to 1, and if include a Control Change command
specification of the usage of the proposed value.
See text in Appendix C.6.4.1 for controller number
121 (Reset All Controllers) appears details (the
paragraph that begins "Other smf_info token ...").

Initial values for this repository appear below:

"ignore": Defined in Appendix C.6.4.1 of this memo.
"sdp_start": Defined in Appendix C.6.4.1 of this memo.
"identity": Defined in Appendix C.6.4.1 of this memo.

11.3. asc Media Type Registration

This section registers "asc" as a subtype for the MIDI stream between the
Control Change command coded by "audio" media type.
We register this subtype to support the BANK-MSB field and remote transfer of the Program
Change command coded by
"config" parameter of the PROGRAM field, mpeg4-generic media type [RFC3640] when it
is used with mpeg4-generic mode rtp-midi (registered in Appendix 11.2
above). We explain the X bit MUST be set mechanics of using "audio/asc" to 1. set the
config parameter in Section 6.2 and Appendix C.6.5 of this document.

Note that [RP015] specifies this registration is a new subtype registration and is not
an addition to a repository defined by MPEG-related memos (such as
[RFC3640]). Also note that Reset All Controllers this request for "audio/asc" does not reset
register parameters, and does not request the values creation of a
repository.

Media type name:

audio

Subtype name:

asc

Required parameters:

None.

Optional parameters:

None.

Encoding considerations:

The native form of controller numbers 0 (Bank Select MSB) the data object is binary data,
zero-padded to an octet boundary.

Restrictions on usage:

This type is only defined for data object (stored file)
transfer. The most common transports for the type are
HTTP and 32 (Bank
Select LSB). Thus, SMTP.

Security considerations:

See Section 9 of this memo.

Interoperability considerations:

None.

Published specification:

The audio/asc data object is the X bit does not effect how receivers will AudioSpecificConfig
binary data structure, which is normatively defined in
[MPEGAUDIO].

Applications that use the
BANK-LSB this media type:

MPEG 4 Audio servers and BANK-MSB values when recovering from a lost Program terminals that support
audio/mpeg4-generic RTP streams for mode rtp-midi.

Additional information:

None.

Person & email address to contact for further information:

John Lazzaro <lazzaro@cs.berkeley.edu>

Intended usage:

COMMON.

Author:

John Lazzaro <lazzaro@cs.berkeley.edu>

Change
command. controller:

IETF Audio/Video Transport Working Group delegated
from the IESG.

A. The X bit serves to aid recovery in MIDI applications where
controller numbers 0 Recovery Journal Channel Chapters

A.1. Recovery Journal Definitions

This appendix defines the terminology and 32 the coding idioms that are
used in a non-standard way.

A.3 Chapter C: MIDI Control Change

Figure A.3.1 shows the format for Chapter C.

0 1 2 3
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 recovery journal bitfield descriptions in Section 5 6 7 8 8 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| LEN |S| NUMBER |A| VALUE/ALT |S| NUMBER |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A| VALUE/ALT | .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure A.3.1 -- Chapter C format

The chapter consists of a 1-octet header, followed by a variable length
list of 2-octet controller logs. The list MUST contain at least one
controller log. The 7-bit LEN field codes
(journal header structure), Appendices A.2 to A.9 (channel journal
chapters) and Appendices B.1 to B.5 (system journal chapters).

We assume that the number of controller logs recovery journal resides in the list, minus one. We define the semantics journal section of
an RTP packet with sequence number I ("packet I") and that the controller log
fields
Checkpoint Packet Seqnum field in Appendix A.3.2.

A channel the top-level recovery journal MUST contain Chapter
header refers to a previous packet with sequence number C if (an
exception is the rules defined in this
Appendix require that one or more controller logs self- referential C = I case). Unless stated
otherwise, algorithms are assumed to use modulo 2^16 arithmetic for
calculations on 16-bit sequence numbers and modulo 2^32 arithmetic
for calculations on 32-bit extended sequence numbers.

Several bitfield coding idioms appear throughout the recovery journal
system, with consistent semantics. Most recovery journal elements
begin with an "S" (Single-packet loss) bit. S bits are designed to
help receivers efficiently parse through the recovery journal
hierarchy in the list.

A.3.1 Log Inclusion Rules

A controller log common case of the loss of a single packet.

As a rule, S bits MUST be set to 1. However, an exception applies if
a recovery journal element in packet I encodes information data about a particular Control Change command
stored in the session history. MIDI command section of packet I - 1. In this case,
the default use S bit of the payload format, list logs recovery journal element MUST encode
information about the most recent active command in the session history
for be set to 0. If a controller number. Logs encoding earlier commands
recovery journal element has its S bit set to 0, all higher-level
recovery journal elements that contain it MUST NOT appear
in the list.

Also, as a rule, also have S bits that
are set to 0, including the list MUST contain a log top-level recovery journal header.

Other consistent bitfield coding idioms are described below:

o R flag bit. R flag bits are reserved for future use. Senders
MUST set R bits to 0. Receivers MUST ignore R bit values.

o LENGTH field. All fields named LENGTH (as distinct from LEN)
code the most recent active
command for a controller number of octets in the structure that appears contains it,
including the header it resides in and all hierarchical levels
below it. If a structure contains a LENGTH field, a receiver
MUST use the checkpoint history.
Below, we LENGTH field value to advance past the structure
during parsing, rather than use knowledge about the internal
format of the structure.

We now define exceptions normative terms used to this rule: describe recovery journal
semantics.

o Checkpoint history. The checkpoint history of a recovery journal
is the concatenation of the MIDI streams may transmit 14-bit controller values using paired
Most Significant Byte (MSB, controller numbers 0-31, 99, 101) and
Least Significant Byte (LSB, controller numbers 32-63, 98, 100)
Control Change commands [MIDI].

If command sections of packets C
through I - 1. The final command in the MIDI command section for
packet I - 1 is considered the most recent active Control Change command; the first
command in the session
history MIDI command section for a 14-bit controller pair uses the MSB number, Chapter packet C MAY omit is the controller log for most oldest
command. If command X is less recent active Control Change than command for the associated LSB number, as Y, X is
considered to be "before Y". A checkpoint history with no
commands is considered to be empty. The checkpoint history never
contains the MIDI command ordering
makes this LSB value irrelevant. However, this exception MUST NOT
be applied section of packet I (the packet
containing the recovery journal), so if C == I, the sender checkpoint
history is empty by definition.

o Session history. The session history of a recovery journal is not certain that
the concatenation of MIDI source uses
14-bit semantics for command sections from the first packet
of the session up to packet I - 1. The definitions of command
recency and history emptiness follow those in the checkpoint
history. The session history never contains the controller number pair. Note that some MIDI sources ignore 14-bit controller semantics, command
section of packet I, and use so the LSB
controller numbers as independent 7-bit controllers. session history of the first
packet in the session is empty by definition.

o Finished/unfinished commands. If active Control Change commands for controller numbers 0 (Bank
Select MSB) or 32 (Bank Select LSB) all octets of a MIDI command
appear in the checkpoint session history, and if the command instances are also coded in the
BANK-MSB and BANK-LSB fields is defined as being
finished. If some but not all octets of a command appear in the Chapter P (Appendix A.2),
Chapter C MAY omit the controller logs for
session history, the commands.

o Several controller numbers pairs are command is defined to be mutually
exclusive. Controller numbers 124 (Omni Off) and 125 (Omni On)
form a mutually exclusive pair, as do controller numbers 126
(Mono) and 127 (Poly).

If active Control Change being unfinished.
Unfinished commands for one or both members occur if segments of a mutually exclusive pair SysEx command appear
in the checkpoint history, several RTP packets. For example, if a
log for SysEx command is coded
as 3 segments, with segment 1 in packet K, segment 2 in packet K
+ 1, and segment 3 in packet K + 2, the controller number session histories for
packets K + 1 and K + 2 contain unfinished versions of the most recent
command. A session history contains a finished version of a
cancelled SysEx command for the
pair in if the checkpoint history MUST appear in the controller list.
However, the list MAY omit contains the controller log cancel
sublist for the most recent
active command.

o Reset State commands. Reset State (RS) commands reset renderers
to an initialized "powerup" condition. The RS commands are:
System Reset (0xFF), General MIDI System Enable (0xF0 0x7E 0xcc
0x09 0x01 0xF7), General MIDI 2 System Enable (0xF0 0x7E 0xcc
0x09 0x03 0xF7), General MIDI System Disable (0xF0 0x7E 0xcc 0x09
0x00 0xF7), Turn DLS On (0xF0 0x7E 0xcc 0x0A 0x01 0xF7), and Turn
DLS Off (0xF0 0x7E 0xcc 0x0A 0x02 0xF7). Registrations of
subrender parameter token values (Appendix C.6.2) and IETF
standards-track documents MAY specify additional RS commands.

o Active commands. Active command for are MIDI commands that do not
appear before a Reset State command in the other number session history.

o N-active commands. N-active commands are MIDI commands that do
not appear before one of the following commands in the pair.

If active session
history: MIDI Control Change numbers 123-127 (numbers with All
Notes Off semantics) or 120 (All Sound Off), and any Reset State
command.

o C-active commands. C-active commands for are MIDI commands that do
not appear before one or both members of a
mutually exclusive pair appear the following commands in the session history,
history: MIDI Control Change number 121 (Reset All Controllers)
and any Reset State command.

o Oldest-first ordering rule. Several recovery journal chapters
contain a log
for the controller number list of elements, where each element is associated with
a MIDI command that appears in the session history. In most recent command for
cases, the pair
does not appear chapter definition requires that list elements be
ordered in accordance with the controller list, a log for "oldest-first ordering rule".
Below, we normatively define this rule:

Elements associated with the most recent command for in the other number of session
history coded in the pair list MUST NOT appear in at the end of the
controller list.

o If an active Control Change

Elements associated with the oldest command for controller number 121
(Reset All Controllers) appears in the session history,
history coded in the
controller list MAY omit logs for Control Change commands that
precede the Reset All Controllers command in MUST appear at the session history,
under certain conditions.

Namely, a log MAY be omitted if start of the sender is certain list.

All other list elements MUST be arranged with respect to these
boundary elements, to produce a list ordering that
command stream follows strictly
reflects the Reset All Controllers semantics
defined relative session history recency of the commands
coded by the elements in [RP015], and if the log codes a controller number
for which [RP015] specifies a reset value.

For example, [RP015] specifies list.

o Parameter system. A MIDI feature that provides two sets of
16,384 parameters to expand the 0-127 controller number 1
(Modulation Wheel) is reset to space.
The Registered Parameter Names (RPN) system and the Non-
Registered Parameter Names (NRPN) system each provides 16,384
parameters.

o Parameter system transaction. The value 0, of RPNs and thus NRPNs are
changed by a controller log for Modulation Wheel MAY be omitted
from the controller log list. In contrast, [RP015] specifies series of Control Change commands that controller number 7 (Channel Volume) is not reset,
and thus form a controller log for Channel Volume MUST NOT
be omitted from
parameter system transaction. A canonical transaction begins
with two Control Change commands to set the controller log list.

o Appendix A.3.4 defines exception rules parameter number
(controller numbers 99 and 98 for the MIDI Parameter
System NRPNs, controller numbers 6, 38, 101
and 96-101.

A.3.2 Controller Log Format

Figure A.3.2 shows the controller log structure of Chapter C.

0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| NUMBER |A| VALUE/ALT |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure A.3.2 -- Chapter C controller log 100 for RPNs). The 7-bit NUMBER field identifies the controller transaction continues with an arbitrary
number of Data Entry (controller numbers 6 and 38), Data
Increment (controller number 96), and Data Decrement (controller
number 97) Control Change commands to set the coded
command. The 7-bit VALUE/ALT field codes recovery information for the
command. parameter value.
The A bit sets the format transaction ends with a second pair of (99, 98) or (101, 100)
Control Change commands that specify the VALUE/ALT field.

A log encodes recovery information using one null parameter (MSB
value 0x7F, LSB value 0x7F).

Several variants of the following tools: the
value tool, canonical transaction sequence are
possible. Most commonly, the toggle tool, terminal pair of (99, 98) or (101,
100) Control Change commands may specify a parameter other than
the count tool.

A log uses null parameter. In this case, the value tool if command pair terminates
the A bit first transaction and starts a second transaction. The
command pair is set considered to 0. The value tool
codes be a part of both transactions.
This variant is legal and recommended in [MIDI]. We refer to
this variant as a "type 1 variant".

Less commonly, the 7-bit data value MSB (99 or 101) or LSB (98 or 100) command of
a (99, 98) or (101, 100) Control Change pair may be omitted.

If the MSB command in is omitted, the VALUE/ALT field. The transaction uses the MSB value tool works best
of the most recent C-active Control Change command for controllers that code a continuous quantity,
such as controller
number 1 (Modulation Wheel).

The A bit is set to 1 to code the toggle 99 or count tool. These tools
work best for controllers 101 that code discrete actions. Figure A.3.3
shows appears in the controller log for these tools.

0 1
0 1 2 3 4 5 6 7 8 9 0 1 session history. We refer
to this variant as a "type 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| NUMBER |1|T| ALT |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure A.3.3 -- Controller log for ALT tools

A log uses the toggle tool if variant".

If the T bit LSB command is set to 0. A log uses the
count tool if omitted, the T bit LSB value 0x00 is set assumed. We
refer to 1. Both methods use the 6-bit ALT
field this variant as an unsigned integer. a "type 3 variant". The toggle tool works best for controllers that act as on/off switches,
such as 64 (Damper Pedal (Sustain)). These controllers code the "off"
state with control values 0-63 type 2 and type
3 variants are defined as legal, but are not recommended, in
[MIDI].

System real-time commands may appear at any point during a
transaction (even between octets of individual commands in the "on" state with 64-127.

For
transaction). More generally, [MIDI] does not forbid the toggle tool,
appearance of unrelated MIDI commands during an open transaction.
As a rule, these commands are considered to be "outside" the ALT field codes
transaction and do not affect the total number status of toggles
(off->on and on->off) due the transaction in
any way. Exceptions to Control Change this rule are commands in the session
history, up whose semantics
act to terminate transactions: Reset State commands, and including a toggle caused by the command coded by the
log. The toggle count includes toggles caused by Control
Change
commands (0xB) for controller number 121 (Reset All Controllers).

Toggle counting is performed modulo 64. The toggle count is reset at
the start of a session, and whenever a Reset State Controllers)
[RP015].

o Initiated parameter system transaction. A canonical parameter
system transaction whose (99, 98) or (101, 100) initial Control
Change command (Appendix
A.1) pair appears in the session history. When these reset events occur, the
toggle count for a controller history is set considered
to 0 (for controllers whose default
value is 0-63) or be an initiated parameter system transaction. This definition
also holds for type 1 (for controllers variants. For type 2 variants (dropped
MSB), a transaction whose default value is 64-127).

The Damper Pedal (Sustain) controller illustrates the benefits of the
toggle tool over the value tool for switch controllers. As often used initial LSB Control Change command
appears in piano applications, the "on" state of the controller lets notes
resonate, while the "off" state immediately damps notes session history is an initiated transaction. For
type 3 variants (dropped LSB), a transaction is considered to silence. The
loss of be
initiated if at least one transaction command follows the "off" initial
MSB (99 or 101) Control Change command in an "on->off->on" sequence results in
ringing notes that should have been damped silent. The toggle tool lets
receivers detect this lost "off" command but the value tool does not. session history.
The completion of a transaction does not nullify its "initiated"
status.

o Session history reference counts. Several recovery journal
chapters include a reference count tool conceptually similar to the toggle tool. For the count
tool, the ALT field field, which codes the total
number of Control Change commands of a type that appear in the session history, up to and including history.
Examples include the Reset and Tune Request command coded by logs (Chapter
D, Appendix B.1) and the log.
Command counting is performed modulo 64. The Active Sense command count is set to 0
at (Chapter V,
Appendix B.2). Upon the start detection of the session, and is reset to 0 whenever a Reset State
command (Appendix A.1) appears in the session history.

Because the loss event, reference
count tool ignores the data value, it is fields let a good match for
controllers whose controller value is ignored, such as number 123 (All
Notes Off). More generally, receiver deduce if any instances of the
command have been lost, by comparing the journal reference count tool may be used to code
with its own reference count. Thus, a
(modulo 64) identification number reference count field
makes sense, even for a command.

A.3.3 Log List Coding Rules

In this section, we describe the organization of controller logs in the
Chapter C log list.

A log encodes information about a particular Control Change command types in which knowing the session history. In most cases, a command SHOULD be coded by a
single tool (and thus, a single log). If a number NUMBER
of lost commands is coded with a
single tool, and this tool irrelevant (as is true with all of the count tool, recovery Control Change
example commands generated by a receiver SHOULD use mentioned above).

The chapter definitions in Appendices A.2 to A.9 and B.1 to B.5
reflect the default control value
for the controller.

However, a command MAY be coded by several tool types (and thus, several
logs, each using a different tool). This technique may improve recovery
performance for controllers with complex semantics, such journal behavior. The ch_default,
ch_never, and ch_anchor parameters modify these definitions, as controller
number 84 (Portamento Control), or controller number 121 (Reset All
Controllers) when used with a non-zero data octet (with the semantics
described in [DLS2]).

If a command is encoded by multiple tools, the logs Appendix C.2.3.

The chapter definitions specify if data MUST be placed present in the list
journal. Senders MAY also include non-required data in the following order: count tool log (if any), followed by
value tool log (if any), followed by toggle tool log (if any).

The Chapter C log list journal.
This optional data MUST obey the oldest-first ordering rule (defined
in Appendix A.1). Note that this ordering preserves the information
necessary for the recovery of 14-bit controller values, without
precluding the use of MSB and LSB controller pairs as independent 7-bit
controllers.

In the default use of comply with the payload format, all logs normative chapter definition.
For example, if a chapter definition states that appear in the
list for a controller number encode information about one Control Change
command -- namely, field codes data
from the most recent active Control Change command in the session history for the number.

This coding scheme provides good recovery performance for history, the standard
uses of Control Change
sender MUST NOT code inactive commands defined in [MIDI]. However, not all
MIDI applications restrict the use of Control Change or older commands to those
defined in [MIDI].

For example, consider the common MIDI encoding of rotary encoders
("infinite" rotation knobs). The mixing console
field.

Finally, we note that a channel journal only encodes information
about MIDI convention defined
in [LCP] codes commands appearing on the position of rotary encoders as a series of Control
Change commands. Each command encodes a relative change of knob
position from MIDI channel the last update (expressed journal
protects. All references to MIDI commands in Appendices A.2 to A.9
should be read as a clockwise or counter-
clockwise knob turning angle).

As the knob position is encoded incrementally over a series of Control "MIDI commands appearing on this channel."

A.2. Chapter P: MIDI Program Change commands, the best recovery performance is obtained

A channel journal MUST contain Chapter P if the log

list encodes all Control an active Program Change commands for encoder controller numbers
that appear
(0xC) command appears in the checkpoint history, not only history. Figure A.2.1 shows
the format for Chapter P.

0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| PROGRAM |B| BANK-MSB |X| BANK-LSB |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure A.2.1 -- Chapter P format

The chapter has a fixed size of 24 bits. The PROGRAM field indicates
the data value of the most recent command.

To support application areas that use Control active Program Change commands command in this
way, Chapter C may
the session history. By default, the B, BANK-MSB, X, and BANK-LSB
fields MUST be configured set to encode information about several 0. Below, we define exceptions to this default
condition.

If an active Control Change commands (0xB) command for a controller number. We use number 0
(Bank Select MSB) appears before the term
"enhanced" to describe this encoding method, which we describe below.

In Appendix C.2.3, we show how to configure a stream to use enhanced
Chapter C encoding for specific controller numbers. In Section 5 Program Change command in the
main text, we show how the H bits in
session history, the recovery journal header (Figure
8) B bit MUST be set to 1, and in the channel journal header (Figure 9) indicate BANK-MSB field
MUST code the use data value of
enhanced Chapter C encoding.

Here, we define how the Control Change command.

If B is set to encode a Chapter C log list that uses 1, the
enhanced encoding method.

Senders that use BANK-LSB field MUST code the enhanced encoding method data value of the
most recent Control Change command for a controller number
MUST obey 32 (Bank
Select LSB) that preceded the rules below. These rules let a receiver determine which
logs Program Change command coded in the list correspond to lost commands. Note that these rules
override
PROGRAM field and followed the exceptions listed in Appendix A.3.1.

o If N commands for a controller number are encoded Control Change command coded in the list,
BANK-MSB field. If no such Control Change command exists, the commands BANK-
LSB field MUST be the N most recent commands set to 0.

If B is set to 1, and if a Control Change command for the controller
number 121 (Reset All Controllers) appears in the session history. For example, for N = 2, the sender
MUST encode MIDI stream between
the most recent Control Change command and the second most recent
command, not coded by the most recent command BANK-MSB field and the third most recent
command.

o If a controller number uses enhanced encoding, the encoding
of the least-recent
Program Change command for coded by the controller number in PROGRAM field, the
log list X bit MUST include a count tool log. In addition, if
commands are encoded for the controller number whose logs
have S bits be
set to 0, 1.

Note that [RP015] specifies that Reset All Controllers does not reset
the encoding values of the least-recent
command with S = controller numbers 0 logs MUST include a count tool log.

The count tool is OPTIONAL for (Bank Select MSB) and 32 (Bank
Select LSB). Thus, the other commands for X bit does not effect how receivers will use
the BANK-LSB and BANK-MSB values when recovering from a lost Program
Change command. The X bit serves to aid recovery in MIDI
applications where controller number encoded numbers 0 and 32 are used in the list, as a receiver is
able to efficiently deduce non-
standard way.

A.3. Chapter C: MIDI Control Change

Figure A.3.1 shows the count tool value for these
commands, format for both single-packet and multi-packet loss events.

o Chapter C.

0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| LEN |S| NUMBER |A| VALUE/ALT |S| NUMBER |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A| VALUE/ALT | .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure A.3.1 -- Chapter C format

The use chapter consists of the value and toggle tools MUST be identical for all
commands for a controller number encoded in the list. For
example, 1-octet header, followed by a value tool log either variable
length list of 2-octet controller logs. The list MUST appear for all commands
for the contain at
least one controller log. The 7-bit LEN field codes the number coded of
controller logs in the list, or alternatively,
value tool logs for minus one. We define the controller number MUST NOT appear in semantics of
the list. Likewise, a toggle tool controller log either fields in Appendix A.3.2.

A channel journal MUST appear for
all commands for contain Chapter C if the controller number coded rules defined in the list, this
appendix require that one or
alternatively, toggle tool logs for the more controller number MUST
NOT logs appear in the list.

o If

A.3.1. Log Inclusion Rules

A controller log encodes information about a particular Control
Change command is encoded by multiple tools, the logs MUST be
placed in the list in session history.

In the following order: count tool log
(if any), followed by value tool log (if any), followed by
toggle tool log (if any).

These rules permit a receiver recovering from a packet loss to default use of the
count tool log to match payload format, list logs MUST encode
information about the commands encoded most recent active command in the list with its own session
history of the stream, as we describe below. Note that the text below
describes for a non-normative algorithm; receivers are free to use any
algorithm to match its history with controller number. Logs encoding earlier commands MUST
NOT appear in the log list.

Also, as a typical implementation of rule, the enhanced encoding method, list MUST contain a receiver
computes and stores count, value, and toggle tool data field values log for the most recent Control Change
active command it has received for a controller
number.

After a loss event, a receiver parses the Chapter C list, and processes
list logs for a controller number that uses enhanced encoding as
follows.

The receiver compares appears in the count tool ALT field for checkpoint
history. Below, we define exceptions to this rule:

o MIDI streams may transmit 14-bit controller values using paired
Most Significant Byte (MSB, controller numbers 0-31, 99, 101)
and Least Significant Byte (LSB, controller numbers 32-63, 98,
100) Control Change commands [MIDI].

If the least-recent most recent active Control Change command in the session
history for a 14-bit controller pair uses the MSB number,
Chapter C MAY omit the controller number in log for the list against its stored count
data most recent active
Control Change command for the controller associated LSB number, to determine as the
command ordering makes this LSB value irrelevant. However, this
exception MUST NOT be applied if recovery the sender is necessary not certain that
the MIDI source uses 14-bit semantics for the controller number
pair. Note that some MIDI sources ignore 14-bit controller
semantics and use the LSB controller numbers as independent 7-
bit controllers.

o If active Control Change commands for controller numbers 0 (Bank
Select MSB) or 32 (Bank Select LSB) appear in the checkpoint
history, and if the command instances are also coded in the list. The value
BANK-MSB and toggle tool BANK-LSB fields of the Chapter P (Appendix A.2),
Chapter C MAY omit the controller logs (if
any) that directly follow for the count tool log commands.

o Several controller number pairs are associated with this
least-recent command.

To check more-recent defined to be mutually
exclusive. Controller numbers 124 (Omni Off) and 125 (Omni On)
form a mutually exclusive pair, as do controller numbers 126
(Mono) and 127 (Poly).

If active Control Change commands for one or both members of a
mutually exclusive pair appear in the controller, the receiver detects
additional value and/or toggle tool logs checkpoint history, a log
for the controller number of the most recent command for the
pair in the list, and infers count tool data checkpoint history MUST appear in the controller
list. However, the list MAY omit the controller log for the
most recent active command coded by these
log(s). This inferred data is used to determine if recovery is
necessary for the command coded by other number in the value and/or toggle tool logs.

In this way, a receiver is able to execute only lost commands, without
executing a command twice. While recovering from a single packet loss, pair.

If active Control Change commands for one or both members of a receiver may skip through S = 1 logs
mutually exclusive pair appear in the list, as the first S = 0 session history, and if a
log for an enhanced the controller number is always a count tool log.

Note that of the requirements most recent command for the
pair does not appear in Appendix C.2.2.2 the controller list, a log for protective sender and
receiver actions during session startup the most
recent command for multicast operation are the other number of
particular importance the pair MUST NOT appear
in the controller list.

o If an active Control Change command for enhanced encoding, as receivers need to
initialize its count tool data structures with recovery journal data controller number 121
(Reset All Controllers) appears in
order to match the session history, the
controller list MAY omit logs for Control Change commands correctly after a loss event.

Finally, we note in passing that in some applications of rotary
encoders,
precede the Reset All Controllers command in the session
history, under certain conditions.

Namely, a good user experience may log MAY be possible without omitted if the use of
enhanced encoding. These applications are distinguished by visual
feedback of encoding position that sender is driven by certain that a
command stream follows the post-recovery rotary
encoding stream, Reset All Controllers semantics
defined in [RP015], and relatively low packet loss. In these domains,
recovery performance may be acceptable for rotary encoders if the log
list encodes only the most recent command, if both count and value logs
appear codes a controller number for the command.

A.3.4 The Parameter System

Readers may wish to review the Appendix A.1 definitions of "parameter
system", "parameter system transaction", and "initiated parameter system
transaction" before reading this section.

Parameter system transactions update
which [RP015] specifies a MIDI Registered Parameter Number
(RPN) or Non-Registered Parameter Number (NRPN) reset value. A parameter
system transaction is a sequence of Control Change commands

For example, [RP015] specifies that may use controller number 1
(Modulation Wheel) is reset to the following controllers numbers:

o Data Entry MSB (6)
o Data Entry LSB (38)
o Data Increment (96)
o Data Decrement (97)
o Non-Registered Parameter Number (NRPN) LSB (98)
o Non-Registered Parameter Number (NRPN) MSB (99)
o Registered Parameter Number (RPN) LSB (100)
o Registered Parameter Number (RPN) MSB (101)

Control Change commands that are a part of value 0, and thus a parameter system
transaction MUST NOT be coded in Chapter C
controller logs. Instead,
these commands are coded in Chapter M, log for Modulation Wheel MAY be omitted from the MIDI Parameter chapter
defined in Appendix A.4.

However, Control Change commands
controller log list. In contrast, [RP015] specifies that use the listed controllers as
general-purpose controllers (i.e. outside of
controller number 7 (Channel Volume) is not reset, and thus a parameter system
transaction)
controller log for Channel Volume MUST NOT be coded in Chapter M.

Instead, omitted from the controllers are coded in Chapter C controller logs. The
controller logs follow the coding rules stated in log list.

o Appendix A.3.2 and
A.3.3. The A.3.4 defines exception rules for coding paired LSB and MSB controllers, as defined
in Appendix A.3.1, apply to the pairs (6, 38), (99, 98), and (101, 100)
when coded in Chapter C.

If active Control Change commands for MIDI Parameter
System controller numbers 6, 38, or
96-101 appear in the checkpoint history, and these commands are used as
general-purpose controllers, 96-101.

A.3.2. Controller Log Format

Figure A.3.2 shows the most recent general-purpose command
instance for these controller numbers MUST appear as entries in the log structure of Chapter C.

0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| NUMBER |A| VALUE/ALT |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure A.3.2 -- Chapter C controller list.

MIDI syntax permits a source to use controllers 6, 38, 96, and 97 as
parameter-system controllers and general-purpose controllers in the same
stream. An RTP MIDI sender MUST deduce log

The 7-bit NUMBER field identifies the role of each Control Change
command for these controller numbers by noting the placement number of the
command in the stream, and MUST use this coded
command. The 7-bit VALUE/ALT field codes recovery information to code for
the command
in Chapter C or Chapter M as appropriate.

Specifically, active Control Change commands for controllers 6, 38, 96,
and 97 act in a general-purpose way when

o No active Control Change commands that set an RPN or
NRPN parameter number appear in the session history, or

o command. The most recent active Control Change commands in A bit sets the session
history that set an RPN or NRPN parameter number code format of the null
parameter (MSB value 0x7F, LSB value 0x7F), or

o VALUE/ALT field.

A Control Change command for controller number 121 (Reset
All Controllers) appears more recently in log encodes recovery information using one of the session history
than all active Control Change commands that set an RPN following tools:
the value tool, the toggle tool, or
NRPN parameter number (see [RP015] for details).

Finally, we note that a MIDI source that follows the recommendations of
[MIDI] exclusively count tool.

A log uses numbers 98-101 as parameter system controllers.
Alternatively, a MIDI source may exclusively use 98-101 as general-
purpose controllers, and lose the ability perform parameter system
transactions in a stream.

In value tool if the language of [MIDI], A bit is set to 0. The value tool
codes the general-purpose use 7-bit data value of controllers 98-101
constitutes a non-standard controller assignment. As most real-world
MIDI sources use command in the standard controller assignment VALUE/ALT field. The
value tool works best for controller
numbers 98-101, an RTP MIDI sender SHOULD assume these controllers act
as parameter system controllers unless it knows that code a MIDI source uses
controller numbers 98-101 in a general-purpose way.

A.4 Chapter M: MIDI Parameter System

Readers may wish continuous
quantity, such as number 1 (Modulation Wheel).

The A bit is set to review 1 to code the Appendix A.1 definitions for "C-active",
"parameter system", "parameter system transaction", and "initiated
parameter system transaction" before reading this Appendix.

Chapter M protects parameter system transactions toggle or count tool. These tools
work best for Registered
Parameter Number (RPN) and Non-Registered Parameter Number (NRPN)
values. controllers that code discrete actions. Figure A.4.1 A.3.3
shows the format controller log for Chapter M.

0 1 2 3 these tools.

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S|P|E|U|W|Z| LENGTH |Q| PENDING | Log list ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| NUMBER |1|T| ALT |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure A.4.1 A.3.3 -- Top-level Chapter M format

Chapter M begins with a 2-octet header. If Controller log for ALT tools

A log uses the P header toggle tool if the T bit is set to
1, a 1-octet field follows 0. A log uses the header, coding
count tool if the 7-bit PENDING value
and its associated Q bit. T bit is set to 1. Both methods use the 6-bit ALT
field as an unsigned integer.

The 10-bit LENGTH toggle tool works best for controllers that act as on/off
switches, such as 64 (Damper Pedal (Sustain)). These controllers
code the "off" state with control values 0-63 and the "on" state with
64-127.

For the toggle tool, the ALT field codes the size total number of Chapter M, toggles
(off->on and conforms on->off) due to
semantics described Control Change commands in Appendix A.1.

Chapter M ends with a list of zero or more variable-length parameter
logs. Appendix A.4.2 defines the bitfield format of a parameter log.
Appendix A.4.1 defines the inclusion semantics of the log list.

A channel journal MUST contain Chapter M if the rules defined in
Appendix A.4.1 require that one or more parameter logs appear in session
history, up to and including a toggle caused by the
list.

A channel journal also MUST contain Chapter M if command coded by
the most recent C-
active log. The toggle count includes toggles caused by Control Change command involved in a parameter system transaction
in the checkpoint history is:

o an RPN MSB (101) or NRPN MSB (99) controller, or

o an RPN LSB (100) or NRPN LSB (98)
commands for controller that completes number 121 (Reset All Controllers).

Toggle counting is performed modulo 64. The toggle count is reset at
the
coding start of the null parameter (MSB value 0x7F, LSB value 0x7F).

This rule provides loss protection for partially-transmitted parameter
numbers a session, and for the null parameter numbers.

If the most recent C-active Control Change command involved in whenever a

parameter system transaction Reset State command (Appendix
A.1) appears in the session history is for the RPN MSB
or NRPN MSB controller, history. When these reset events occur,
the P header bit MUST be toggle count for a controller is set to 1, and the
PENDING field (and its associated Q bit) MUST follow 0 (for controllers whose
default value is 0-63) or 1 (for controllers whose default value is
64-127).

The Damper Pedal (Sustain) controller illustrates the Chapter M
header. Otherwise, benefits of the P header bit MUST be set to 0, and
toggle tool over the PENDING
field and Q bit MUST NOT appear value tool for switch controllers. As often
used in Chapter M.

If PENDING codes an NRPN MSB, piano applications, the Q bit MUST be set to 1. If PENDING
codes an RPN MSB, "on" state of the Q bit MUST be set to 0.

The E header bit codes controller lets
notes resonate, while the current transaction "off" state immediately damps notes to
silence. The loss of the MIDI stream.
If E = 1, "off" command in an initiated transaction is "on->off->on" sequence
results in progress. Below, we define ringing notes that should have been damped silent. The
toggle tool lets receivers detect this lost "off" command, but the
rules for setting
value tool does not.

The count tool is conceptually similar to the E header bit:

o If no C-active parameter system transaction toggle tool. For the
count tool, the ALT field codes the total number of Control Change
commands appear in the session history, the E bit MUST be
set up to 0.

o If and including the P header bit command
coded by the log. Command counting is performed modulo 64. The
command count is set to 1, 0 at the E bit MUST be set to 0.

o If start of the most recent C-active parameter system transaction
Control Change session and is reset to
0 whenever a Reset State command (Appendix A.1) appears in the
session history history.

Because the count tool ignores the data value, it is a good match for the
NRPN LSB or RPN LSB
controllers whose controller number, and this command
acts to complete the coding of the null parameter (MSB
value 0x7F, LSB value 0x7F), is ignored, such as number 123
(All Notes Off). More generally, the E bit MUST count tool may be set to 0.

o Otherwise, an initiated transaction is in progress, and the
E bit MUST be set used to 1.

The U, W, and Z header bits code properties that are shared by all
parameter logs in the list. If these properties are set, parameter logs
may be coded with improved efficiency (we explain how in A.4.1).

By default,
a (modulo 64) identification number for a command.

A.3.3. Log List Coding Rules

In this section, we describe the U, W, and Z bits MUST be set to 0. If all parameter organization of controller logs in
the list code RPN parameters, the U bit MAY be set to 1. If all
parameter logs Chapter C log list.

A log encodes information about a particular Control Change command
in the list code NRPN parameters, the W bit MAY session history. In most cases, a command SHOULD be set to
1. coded by
a single tool (and, thus, a single log). If the parameter numbers of all RPN a number is coded with a
single tool and NRPN logs in this tool is the list lie in count tool, recovery Control Change
commands generated by a receiver SHOULD use the range 0-127 (and thus have an MSB default control value of 0),
for the Z bit controller.

However, a command MAY be set
to 1.

Note that C-active semantics appear in the preceding paragraphs because
[RP015] specifies that pending Parameter System transactions are closed coded by several tool types (and, thus,
several logs, each using a Control Change command different tool). This technique may
improve recovery performance for controllers with complex semantics,
such as controller number 84 (Portamento Control) or controller
number 121 (Reset All
Controllers).

A.4.1 Log Inclusion Rules

Parameter logs code recovery information for a specific RPN or NRPN
parameter.

A parameter log MUST appear in the list if an active Control Change
command that forms Controllers) when used with a part of an initiated transaction for non-zero data
octet (with the parameter
appears semantics described in the checkpoint history.

An exception to this rule applies if the checkpoint history only
contains transaction Control Change commands for controller numbers
98-101 that act to terminate the transaction. In this case, [DLS2]).

If a log for command is encoded by multiple tools, the parameter MAY logs MUST be omitted from the list.

A log MAY appear placed in
the list if an active Control Change command that
forms a part of an initiated transaction for the parameter appears in the session history. Otherwise, a following order: count tool log for the parameter MUST NOT appear
in the list.

Multiple logs for the same RPN or NRPN parameter MUST NOT appear in the (if any), followed by
value tool log list. (if any), followed by toggle tool log (if any).

The parameter Chapter C log list MUST obey the oldest-first ordering rule
(defined in Appendix A.1), with the phrase "parameter transaction" replacing A.1). Note that this ordering preserves the
word "command" in
information necessary for the rule definition.

Parameter logs associated with recovery of 14-bit controller values,
without precluding the RPN or NRPN null parameter (LSB =
0x7F, use of MSB = 0x7F) MUST NOT appear in and LSB controller pairs as
independent 7-bit controllers.

In the log list. Chapter M uses default use of the E
header bit (Figure A.4.1) and payload format, all logs that appear in the log
list ordering rules to code null
parameter semantics.

Note that "active" semantics (rather than "C-active" semantics) appear
in the preceding paragraphs because [RP015] specifies that pending
Parameter System transactions are not reset by for a controller number encode information about one Control
Change command -- namely, the most recent active Control Change
command in the session history for controller number 121 (Reset All Controllers). However, the rule
that follows uses C-active semantics, because it concerns number.

This coding scheme provides good recovery performance for the protection
standard uses of Control Change commands defined in [MIDI]. However,
not all MIDI applications restrict the transaction system itself, and [RP015] specifies that Reset All
Controllers acts use of Control Change commands
to close a transaction those defined in progress.

In most cases, parameter logs for RPN and NRPN parameters that are
assigned to the ch_never parameter (Appendix C.2.3) MAY be omitted from [MIDI].

For example, consider the list. An exception applies if:

o common MIDI encoding of rotary encoders
("infinite" rotation knobs). The log codes the most recent initiated transaction mixing console MIDI convention
defined in [LCP] codes the session history, and

o A C-active position of rotary encoders as a series of
Control Change commands. Each command that forms encodes a part relative change of
knob position from the transaction
appears in the checkpoint history, and

o The E header bit for last update (expressed as a clockwise or
counter-clockwise knob turning angle).

As the top-level Chapter M header (Figure
A.4.1) knob position is set to 1.

In this case, encoded incrementally over a series of
Control Change commands, the best recovery performance is obtained if
the log list encodes all Control Change commands for the parameter MUST encoder
controller numbers that appear in the list. This log

informs receivers recovering from a loss checkpoint history, not only
the most recent command.

To support application areas that a transaction is use Control Change commands in
progress, so that the receiver is able this
way, Chapter C may be configured to correctly interpret RPN or
NRPN encode information about several
Control Change commands that follow the loss event.

A.4.2 Log Coding Rules

Figure A.4.2 shows for a controller number. We use the parameter log structure of term
"enhanced" to describe this encoding method, which we describe below.

In Appendix C.2.3, we show how to configure a stream to use enhanced
Chapter M.

0 1 2 3
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 C encoding for specific controller numbers. In Section 5 6 7 8 8 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| PNUM-LSB |Q| PNUM-MSB |J|K|L|M|N|T|V|R| Fields ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure A.4.2 -- Parameter log format

The log begins with a header, whose default size (as shown in Figure
A.4.2) is 3 octets. If
the Q main text, we show how the H bits in the recovery journal header bit is set to 0,
(Figure 8) and in the log encodes an
RPN parameter. If Q = 1, channel journal header (Figure 9) indicate the
use of enhanced Chapter C encoding.

Here, we define how to encode a Chapter C log encodes an NRPN parameter. The 7-bit
PNUM-MSB and PNUM-LSB fields code list that uses the parameter number, and reflect
enhanced encoding method.

Senders that use the
Control Change command data values enhanced encoding method for controllers 99 and 98 (for NRPNs)
or 101 and 100 (for RPNs).

The J, K, L, M, and N header bits form a Table of Contents (TOC) for the
log, and signal controller number
MUST obey the presence of fixed-sized fields that follow rules below. These rules let a receiver determine
which logs in the
header. A header bit that is set list correspond to 1 codes lost commands. Note that these
rules override the presence of exceptions listed in Appendix A.3.1.

o If N commands for a field controller number are encoded in the log. The ordering of fields in list,
the log follows commands MUST be the ordering of N most recent commands for the
header bits
controller number in the TOC. Appendices A.4.2.1-2 define session history. For example, for N =
2, the fields
associated with each TOC header bit.

The T sender MUST encode the most recent command and V header bits code information about the parameter log, but
are second
most recent command, not part of the TOC. A set T or V bit does not signal most recent command and the presence
of any parameter log field. third
most recent command.

o If the rules in Appendix A.4.1 state that a log for a given parameter
MUST appear in Chapter M, the log MUST code sufficient information to
protect the parameter from controller number uses enhanced encoding, the loss encoding of active parameter transaction
Control Change commands in
the checkpoint history.

This rule does not apply if least-recent command for the parameter coded by controller number in the log is assigned
to the ch_never parameter (Appendix C.2.3).
list MUST include a count tool log. In this case, senders MAY
choose to set addition, if commands
are encoded for the J, K, L, M, and N TOC controller number whose logs have S bits set
to 0, coding a parameter
log with no fields.

Note that logs to protect parameters that are assigned to ch_never are
REQUIRED under certain conditions (see Appendix A.4.1). The purpose the encoding of the log is to inform receivers recovering from a loss that least-recent command with S = 0 logs
MUST include a transaction count tool log.

The count tool is OPTIONAL for the other commands for the
controller number encoded in progress, so that the list, as a receiver is able to correctly interpret RPN
or NRPN Control Change commands that follow
efficiently deduce the count tool value for these commands, for
both single-packet and multi-packet loss event.

Parameter logs provide two events.

o The use of the value and toggle tools MUST be identical for parameter protection: all
commands for a controller number encoded in the list. For
example, a value tool and the count tool. Depending on log either MUST appear for all commands
for the semantics of controller number coded in the parameter,
senders may use either tool, both tools, list, or neither tool to protect a
given parameter.

The alternatively,
value tool codes information a receiver may use to determine logs for the
current value of an RPN or NRPN parameter. If controller number MUST NOT appear in the
list. Likewise, a parameter toggle tool log uses the
value tool, the V header bit either MUST be set to 1, and appear for all
commands for the semantics defined controller number coded in Appendices A.4.2.1 for setting the J, K, L, and M TOC bits MUST be
followed. If a parameter log does not use the value tool, the V bit
MUST be set to 0, and the J, K, L, and M TOC bits MUST also be set to 0.

The count list, or
alternatively, toggle tool codes logs for the controller number of transactions for an RPN or NRPN
parameter. MUST
NOT appear in the list.

o If a parameter log uses the count tool, command is encoded by multiple tools, the T header bit logs MUST be set to 1, and the semantics defined
placed in Appendices A.4.2.2 for
setting the N TOC bit MUST be followed. If a parameter log does not use list in the following order: count tool, the T bit and the N TOC bit MUST be set tool log (if
any), followed by value tool log (if any), followed by toggle
tool log (if any).

These rules permit a receiver recovering from a packet loss to 0.

Note that V and T are set if use
the sender uses value (V) or count (T) tool
for the log on an ongoing basis. Thus, V may be set even if J = K = L =
M = 0, and T may be set even if N = 0.

In many cases, all parameters coded to match the commands encoded in the log list are with its
own history of one type (RPN
and NRPN), and all parameter numbers lie in the range 0-127. As
described in Appendix A.4.1, senders MAY signal this condition by
setting stream, as we describe below. Note that the top-level Chapter M header bit Z text
below describes a non-normative algorithm; receivers are free to 1 (to code the
restricted range) and by setting the U or W bit use
any algorithm to 1 (to code the
parameter type).

If the top-level Chapter M header codes Z = 1 and either U = 1 or W = 1,
all logs in match its history with the parameter log list MUST use list.

In a modified header format.
This modification deletes bits 8-15 typical implementation of the bitfield shown in Figure
A.4.2, to yield enhanced encoding method, a 2-octet header. The values of the deleted PNUM-MSB
receiver computes and Q fields may be inferred from the U, W, stores count, value, and Z bit values.

A.4.2.1 The Value Tool

The value toggle tool uses several fields to track the value of an RPN or NRPN
parameter.

The J TOC bit codes the presence of the octet shown in Figure A.4.3 in
the field list.

0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|X| ENTRY-MSB |
+-+-+-+-+-+-+-+-+

Figure A.4.3 -- ENTRY-MSB field

The 7-bit ENTRY-MSB field codes the data value of field
values for the most recent active Control Change command it has received for
a controller number 6 (Data Entry MSB) in number.

After a loss event, a receiver parses the
session history Chapter C list and
processes list logs for a controller number that appears uses enhanced
encoding as follows.

The receiver compares the count tool ALT field for the least-recent
command for the controller number in a transaction the list against its stored
count data for the log parameter.

The X bit MUST be set controller number, to 1 determine if recovery is
necessary for the command coded by ENTRY-MSB precedes
the most recent Control Change command for controller 121 (Reset All
Controllers) in the session history. Otherwise, the X bit MUST be set
to 0.

A parameter log that uses in the list. The value and toggle
tool MUST include the ENTRY-MSB
field if an active Control Change command for controller number 6
appears in the checkpoint history.

Note that [RP015] specifies logs (if any) that Control Change commands for controller
121 (Reset All Controllers) do not reset RPN and NRPN values, and thus directly follow the X bit would not play a recovery role for MIDI systems that comply
with [RP015].

However, certain renderers (such as DLS 2 [DLS2]) specify that certain
RPN values count tool log are reset for some uses of Reset All Controllers. The X bit
(and other bitfield features of this nature in
associated with this Appendix) plays a
role in recovery least-recent command.

To check more-recent commands for renderers of this type.

The K TOC bit codes the presence of the octet shown in Figure A.4.4 in the field list.

0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|X| ENTRY-LSB |
+-+-+-+-+-+-+-+-+

Figure A.4.4 -- ENTRY-LSB field

The 7-bit ENTRY-LSB field codes controller, the data receiver
detects additional value of the most recent active
Control Change command and/or toggle tool logs for the controller
number 38 (Data Entry LSB) in the
session history that appears in a transaction list and infers count tool data for the log parameter.

The X bit MUST be set command coded
by these logs. This inferred data is used to 1 determine if recovery
is necessary for the command coded by ENTRY-LSB precedes
the most recent Control Change command for controller 121 (Reset All
Controllers) in the session history. Otherwise, the X bit MUST be set
to 0.

As a rule, a parameter log that uses the value and/or toggle tool MUST include the
ENTRY-LSB field if an active Control Change
logs.

In this way, a receiver is able to execute only lost commands,
without executing a command for controller
number 38 appears twice. While recovering from a single
packet loss, a receiver may skip through S = 1 logs in the checkpoint history. However, list, as
the ENTRY-LSB
field MUST NOT appear in a parameter first S = 0 log if the Control Change command
associated with the ENTRY-LSB precedes a Control Change command for an enhanced controller number 6 (Data Entry MSB) that appears in is always a transaction for
count tool log.

Note that the log parameter requirements in the Appendix C.2.2.2 for protective sender
and receiver actions during session history.

The L TOC bit codes the presence startup for multicast operation
are of the octets shown in Figure A.4.5 in
the field list.

0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|G|X| A-BUTTON |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure A.4.5 -- A-BUTTON field

The 14-bit A-BUTTON field codes a particular importance for enhanced encoding, as receivers need
to initialize its count of the number of active Control
Change tool data structures with recovery journal
data in order to match commands for controller numbers 96 and 97 (Data Increment and
Data Decrement) correctly after a loss event.

Finally, we note in the session history passing that appear in some applications of rotary
encoders, a transaction for
the log parameter.

The M TOC bit codes good user experience may be possible without the presence use of
enhanced encoding. These applications are distinguished by visual
feedback of encoding position that is driven by the octets shown in Figure A.4.6 in post-recovery
rotary encoding stream, and relatively low packet loss. In these
domains, recovery performance may be acceptable for rotary encoders
if the field list.

0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|G|R| C-BUTTON |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure A.4.6 -- C-BUTTON field log list encodes only the most recent command, if both count
and value logs appear for the command.

A.3.4. The 14-bit C-BUTTON field has semantics identical Parameter System

Readers may wish to A-BUTTON, except review the Appendix A.1 definitions of "parameter
system", "parameter system transaction", and "initiated parameter
system transaction" before reading this section.

Parameter system transactions update a MIDI Registered Parameter
Number (RPN) or Non-Registered Parameter Number (NRPN) value. A
parameter system transaction is a sequence of Control Change commands
that may use the following controllers numbers:

o Data Entry MSB (6)
o Data Entry LSB (38)
o Data Increment and (96)
o Data Decrement (97)
o Non-Registered Parameter Number (NRPN) LSB (98)
o Non-Registered Parameter Number (NRPN) MSB (99)
o Registered Parameter Number (RPN) LSB (100)
o Registered Parameter Number (RPN) MSB (101)
Control Change commands that
precede are a part of a parameter system
transaction MUST NOT be coded in Chapter C controller logs. Instead,
these commands are coded in Chapter M, the most recent MIDI Parameter chapter
defined in Appendix A.4.

However, Control Change command for controller 121 (Reset
All Controllers) commands that use the listed controllers as
general-purpose controllers (i.e., outside of a parameter system
transaction) MUST NOT be coded in Chapter M.

Instead, the session history controllers are not counted.

For both A-BUTTON coded in Chapter C controller logs. The
controller logs follow the coding rules stated in Appendix A.3.2 and C-BUTTON, Data Increment
A.3.3. The rules for coding paired LSB and Data Decrement MSB controllers, as
defined in Appendix A.3.1, apply to the pairs (6, 38), (99, 98), and
(101, 100) when coded in Chapter C.

If active Control Change commands are not counted if they precede Control Changes
commands for controller numbers 6 (Data Entry MSB) 6, 38, or 38 (Data Entry
LSB) that
96-101 appear in a transaction for the log parameter checkpoint history, and these commands are used
as general-purpose controllers, the most recent general-purpose
command instance for these controller numbers MUST appear as entries
in the session
history.

The A-BUTTON Chapter C controller list.

MIDI syntax permits a source to use controllers 6, 38, 96, and C-BUTTON fields are interpreted 97 as unsigned integers,
parameter-system controllers and general-purpose controllers in the G bit associated
same stream. An RTP MIDI sender MUST deduce the field codes role of each Control
Change command for these controller numbers by noting the sign placement
of the integer (G = 0
for positive or zero, G = 1 for negative).

To compute command in the stream and MUST use this information to code
the count value, initialize the count value to 0,
add 1 command in Chapter C or Chapter M, as appropriate.

Specifically, active Control Change commands for each qualifying Data Increment command, controllers 6, 38,
96, and subtract 1 for
each qualifying Data Decrement command. After each add 97 act in a general-purpose way when

o no active Control Change commands that set an RPN or subtract,
limit the count magnitude to 16383. The G bit codes the sign of the
count, and NRPN
parameter number appear in the A-BUTTON session history, or C-BUTTON field codes the count magnitude.

For the A-BUTTON field, if

o the most recent qualified Data Increment active Control Change commands in the session
history that set an RPN or
Data Decrement command precedes NRPN parameter number code the most recent null
parameter (MSB value 0x7F, LSB value 0x7F), or

o a Control Change command for controller number 121 (Reset All
Controllers) appears more recently in the session history, the X
bit associated with A-BUTTON field MUST be set to 1. Otherwise, the X
bit MUST be set to 0.

A parameter log that uses the value tool MUST include the A-BUTTON and
C-BUTTON fields if an history than
all active Control Change command for controller
numbers 96 commands that set an RPN or 97 appears in the checkpoint history. However, to improve
coding efficiency, this rule has several exceptions:

o If the log includes the A-BUTTON field, and if NRPN
parameter number (see [RP015] for details).

Finally, we note that a MIDI source that follows the X bit recommendations
of
the A-BUTTON field is set to 1, the C-BUTTON field (and its
associated R [MIDI] exclusively uses numbers 98-101 as parameter system
controllers. Alternatively, a MIDI source may exclusively use 98-101
as general-purpose controllers and G bits) MAY be omitted from lose the log.

o If ability perform parameter
system transactions in a stream.

In the log includes language of [MIDI], the A-BUTTON field, and if general-purpose use of controllers
98-101 constitutes a non-standard controller assignment. As most
real-world MIDI sources use the A-BUTTON
and C-BUTTON fields (and their associated G bits) code identical
values, standard controller assignment for
controller numbers 98-101, an RTP MIDI sender SHOULD assume these
controllers act as parameter system controllers, unless it knows that
a MIDI source uses controller numbers 98-101 in a general-purpose
way.

A.4. Chapter M: MIDI Parameter System

Readers may wish to review the C-BUTTON field (and its associated R Appendix A.1 definitions for
"C-active", "parameter system", "parameter system transaction", and G bits)
MAY be omitted from the log.

A.4.2.2 The Count Tool

The count tool tracks the number of
"initiated parameter system transaction" before reading this
appendix.

Chapter M protects parameter system transactions for an RPN or NRPN
parameter. The N TOC bit codes the presence of the octet shown in Registered
Parameter Number (RPN) and Non-Registered Parameter Number (NRPN)
values. Figure A.4.7 in A.4.1 shows the field list. format for Chapter M.

0 1 2 3
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|X| COUNT 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S|P|E|U|W|Z| LENGTH |Q| PENDING |
+-+-+-+-+-+-+-+-+ Log list ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure A.4.7 A.4.1 -- COUNT Top-level Chapter M format

Chapter M begins with a 2-octet header. If the P header bit is set
to 1, a 1-octet field

The follows the header, coding the 7-bit COUNT PENDING
value and its associated Q bit.

The 10-bit LENGTH field codes the number size of initiated transactions for the log
parameter that appear Chapter M and conforms to
semantics described in Appendix A.1.

Chapter M ends with a list of zero or more variable-length parameter
logs. Appendix A.4.2 defines the session history. Initiated transactions
are counted if they bitfield format of a parameter log.
Appendix A.4.1 defines the inclusion semantics of the log list.

A channel journal MUST contain Chapter M if the rules defined in
Appendix A.4.1 require that one or more active parameter logs appear in the
list.

A channel journal also MUST contain Chapter M if the most recent
C-active Control Change commands,
including commands for controllers 98-101 command involved in a parameter system
transaction in the checkpoint history is

o an RPN MSB (101) or NRPN MSB (99) controller, or
o an RPN LSB (100) or NRPN LSB (98) controller that initiate completes the
coding of the null parameter
transaction.

If (MSB value 0x7F, LSB value 0x7F).

This rule provides loss protection for partially transmitted
parameter numbers and for the most recent counted transaction precedes null parameter numbers.

If the most recent C-active Control Change command for controller 121 (Reset All Controllers) involved in a
parameter system transaction in the session
history, history is for the X RPN
MSB or NRPN MSB controller, the P header bit MUST be set to 1, and
the PENDING field (and its associated with Q bit) MUST follow the COUNT Chapter
M header. Otherwise, the P header bit MUST be set to 0, and the
PENDING field and Q bit MUST NOT appear in Chapter M.

If PENDING codes an NRPN MSB, the Q bit MUST be set to 1.
Otherwise, If PENDING
codes an RPN MSB, the X Q bit MUST be set to 0.

Transaction counting is performed modulo 128.

The transaction count is
set to 0 at E header bit codes the start current transaction state of a session, and is reset to 0 whenever a Reset
State command (Appendix A.1) appears in the session history.

A parameter log that uses the count tool MUST include the COUNT field if MIDI
stream. If E = 1, an active command that increments the initiated transaction count (modulo 128)
appears is in progress. Below,
we define the checkpoint history.

A.5 Chapter W: MIDI Pitch Wheel

A channel journal MUST contain Chapter W if a rules for setting the E header bit:

o If no C-active MIDI Pitch Wheel
(0xE) command appears parameter system transaction Control Change
commands appear in the checkpoint history. Figure A.5.1 shows session history, the
format for Chapter W.

0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| FIRST |R| SECOND |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure A.5.1 -- Chapter W format

The chapter has a fixed size of 16 bits. The FIRST and SECOND fields
are E bit MUST be set to
0.

o If the 7-bit values of P header bit is set to 1, the first and second data octets of E bit MUST be set to 0.

o If the most recent active Pitch Wheel C-active parameter system transaction Control
Change command in the session history.

Note that Chapter W encodes C-active commands, history is for the NRPN LSB or RPN
LSB controller number, and thus does not encode
active commands that are not C-active (see if this command acts to complete the second-to-last paragraph
of Appendix A.1 for an explanation
coding of chapter inclusion text in this
regard).

Chapter W does not encode "active but not C-active" commands because
[RP015] declares that Control Change commands for controller number 121
(Reset All Controllers) acts to reset the Pitch Wheel null parameter (MSB value 0x7F, LSB value 0x7F),
the E bit MUST be set to 0. If
Chapter W encoded "active but not C-active" commands, a repair operation
following a Reset All Controllers command could incorrectly repair

o Otherwise, an initiated transaction is in progress, and the
stream with a stale Pitch Wheel value.

A.6 Chapter N: MIDI NoteOff E
bit MUST be set to 1.

The U, W, and NoteOn

In this Appendix, we consider NoteOn commands Z header bits code properties that are shared by all
parameter logs in the list. If these properties are set, parameter
logs may be coded with zero velocity improved efficiency (we explain how in A.4.1).

By default, the U, W, and Z bits MUST be set to 0. If all parameter
logs in the list code RPN parameters, the U bit MAY be
NoteOff commands. Readers may wish set to review 1. If
all parameter logs in the Appendix A.1
definition list code NRPN parameters, the W bit MAY be
set to 1. If the parameter numbers of "N-active commands" before reading this Appendix.

Chapter N completely protects note commands in streams that alternate
between NoteOn all RPN and NoteOff commands for a particular note number.
However, NRPN logs in rare applications, multiple overlapping NoteOn commands may the
list lie in the range 0-127 (and thus have an MSB value of 0), the Z
bit MAY be set to 1.

Note that C-active semantics appear in the preceding paragraphs
because [RP015] specifies that pending Parameter System transactions
are closed by a Control Change command for controller number 121
(Reset All Controllers).

A.4.1. Log Inclusion Rules

Parameter logs code recovery information for a note number. Chapter E, described in Appendix A.7,
augments Chapter N to completely protect these streams. specific RPN or NRPN
parameter.

A channel journal parameter log MUST contain Chapter N appear in the list if an N-active MIDI NoteOn
(0x9) or NoteOff (0x8) active Control Change
command that forms a part of an initiated transaction for the
parameter appears in the checkpoint history.
Figure A.6.1 shows

An exception to this rule applies if the format checkpoint history only
contains transaction Control Change commands for Chapter N.

0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|B| LEN | LOW | HIGH |S| NOTENUM |Y| VELOCITY |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| NOTENUM |Y| VELOCITY | .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OFFBITS | OFFBITS | .... | OFFBITS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure A.6.1 -- Chapter N format

Chapter N consists of controller numbers
98-101 that act to terminate the transaction. In this case, a 2-octet header, followed by at least one of log
for the
following data structures:

o parameter MAY be omitted from the list.

A log MAY appear in the list if an active Control Change command that
forms a part of note logs to code NoteOn commands.
o A NoteOff bitfield structure to code NoteOff commands.

We define an initiated transaction for the header bitfield semantics parameter appears in Appendix A.6.1. We define
the note session history. Otherwise, a log semantics and for the NoteOff bitfield semantics in Appendix
A.6.2.

If one or more N-active NoteOn or NoteOff commands parameter MUST NOT
appear in the checkpoint
history reference a note number, list.

Multiple logs for the note number same RPN or NRPN parameter MUST be coded NOT appear in either
the note log list or the NoteOff bitfield structure. list.

The note parameter log list MUST contain an entry for all note numbers whose most
recent checkpoint history appearance is obey the oldest-first ordering rule
(defined in an N-active NoteOn command.
The NoteOff bitfield structure MUST contain a set bit for all note
numbers whose most recent checkpoint history appearance is Appendix A.1), with the phrase "parameter transaction"
replacing the word "command" in an N-

active NoteOff command.

A note number the rule definition.

Parameter logs associated with the RPN or NRPN null parameter (LSB =
0x7F, MSB = 0x7F) MUST NOT be coded appear in both structures. the log list. Chapter M uses
the E header bit (Figure A.4.1) and the log list ordering rules to
code null parameter semantics.

Note that "active" semantics (rather than "C-active" semantics)
appear in the preceding paragraphs because [RP015] specifies that
pending Parameter System transactions are not reset by a Control
Change command for controller number 121 (Reset All note Controllers).
However, the rule that follows uses C-active semantics, because it
concerns the protection of the transaction system itself, and [RP015]
specifies that Reset All Controllers acts to close a transaction in
progress.

In most cases, parameter logs for RPN and NoteOff bitfield set bits MUST code NRPN parameters that are
assigned to the ch_never parameter (Appendix C.2.3) MAY be omitted
from the list. An exception applies if

o the log codes the most recent N-
active NoteOn or NoteOff reference to a note number initiated transaction in the
session
history.

The note log list MUST obey history, and

o a C-active command that forms a part of the oldest-first ordering rule (defined transaction appears
in
Appendix A.1).

A.6.1 Header Structure

The the checkpoint history, and

o the E header bit for the top-level Chapter N, shown M header (Figure
A.4.1) is set to 1.

In this case, a log for the parameter MUST appear in the list. This
log informs receivers recovering from a loss that a transaction is in
progress, so that the receiver is able to correctly interpret RPN or
NRPN Control Change commands that follow the loss event.

A.4.2. Log Coding Rules

Figure A.6.2, codes A.4.2 shows the size parameter log structure of the
note list and bitfield structures. Chapter M.

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|B| LEN | LOW | HIGH 6 7 8 9 0 1 2 3 4 5 6 7 8 8 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| PNUM-LSB |Q| PNUM-MSB |J|K|L|M|N|T|V|R| Fields ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure A.6.2 A.4.2 -- Chapter N header Parameter log format

The LEN field, log begins with a 7-bit integer value, codes the number of 2-octet note
logs header, whose default size (as shown in Figure
A.4.2) is 3 octets. If the note list. Zero Q header bit is a valid value for LEN, and codes set to 0, the log encodes
an
empty note list. RPN parameter. If Q = 1, the log encodes an NRPN parameter. The 4-bit LOW
7-bit PNUM-MSB and HIGH PNUM-LSB fields code the parameter number and
reflect the Control Change command data values for controllers 99 and
98 (for NRPNs) or 101 and 100 (for RPNs).

The J, K, L, M, and N header bits form a Table of OFFBITS octets that
follow Contents (TOC) for
the note log list. LOW and HIGH are unsigned integer values. If
LOW <= HIGH, there are (HIGH - LOW + 1) OFFBITS octets signal the presence of fixed-sized fields that follow the
header. A header bit that is set to 1 codes the presence of a field
in the chapter. log. The value pairs (LOW = 15, HIGH = 0) and (LOW = 15, HIGH = 1) code an
empty NoteOff bitfield structure (i.e. no OFFBITS octets). Other (LOW >
HIGH) value pairs MUST NOT appear ordering of fields in the header. log follows the ordering
of the header bits in the TOC. Appendices A.4.2.1-2 define the
fields associated with each TOC header bit.

The B bit provides S-bit functionality (Appendix A.1) for T and V header bits code information about the NoteOff
bitfield structure. By default, parameter log but
are not part of the B bit MUST be TOC. A set to 1. However,
if T or V bit does not signal the MIDI command section
presence of any parameter log field.

If the previous packet (packet I - 1, with I
as defined rules in Appendix A.1) includes A.4.1 state that a NoteOff command log for a given parameter
MUST appear in Chapter M, the channel,
the B bit log MUST be set code sufficient information to 0. If
protect the B bit parameter from the loss of active parameter transaction
Control Change commands in the checkpoint history.

This rule does not apply if the parameter coded by the log is set
assigned to 0, the higher-level
recovery journal elements that contain Chapter ch_never parameter (Appendix C.2.3). In this case,
senders MAY choose to set the J, K, L, M, and N MUST have S TOC bits to 0, coding
a parameter log with no fields.

Note that logs to protect parameters that are set assigned to 0, including the top-level journal header. ch_never
are REQUIRED under certain conditions (see Appendix A.4.1). The LEN value
purpose of 127 codes the log is to inform receivers recovering from a note list length of 127 loss that
a transaction is in progress, so that the receiver is able to
correctly interpret RPN or 128 note logs,
depending on NRPN Control Change commands that follow
the values of LOW and HIGH. If LEN = 127, LOW = 15, and
HIGH = 0, loss event.

Parameter logs provide two tools for parameter protection: the note list holds 128 note logs, value
tool and the NoteOff bitfield

structure is empty. For other values count tool. Depending on the semantics of LOW and HIGH, LEN = 127 the
parameter, senders may use either tool, both tools, or neither tool
to protect a given parameter.

The value tool codes
that information a receiver may use to determine the note list contains 127 note logs. In this case,
current value of an RPN or NRPN parameter. If a parameter log uses
the chapter
has (HIGH - LOW + 1) NoteOff OFFBITS octets if LOW <= HIGH, value tool, the V header bit MUST be set to 1, and has no
OFFBITS octets if LOW = 15 and HIGH = 1.

A.6.2 Note Structures

Figure A.6.3 shows the 2-octet note log structure.

0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| NOTENUM |Y| VELOCITY |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure A.6.3 -- Chapter N note semantics
defined in Appendices A.4.2.1 for setting the J, K, L, and M TOC bits
MUST be followed. If a parameter log does not use the value tool,
the V bit MUST be set to 0, and the J, K, L, and M TOC bits MUST also
be set to 0.

The 7-bit NOTENUM field count tool codes the note number of transactions for an RPN or NRPN
parameter. If a parameter log uses the log. A note
number count tool, the T header bit
MUST NOT be represented by multiple note logs set to 1, and the semantics defined in Appendices A.4.2.2 for
setting the note list.

The 7-bit VELOCITY field codes N TOC bit MUST be followed. If a parameter log does not
use the velocity value for count tool, the most recent N-
active NoteOn command for T bit and the note number in N TOC bit MUST be set to 0.

Note that V and T are set if the session history.
Multiple overlapping NoteOns sender uses value (V) or count (T)
tool for a given note number the log on an ongoing basis. Thus, V may be set even if J =
K = L = M = 0, and T may be set even if N = 0.

In many cases, all parameters coded using
Chapter E, as discussed in Appendix A.7.

VELOCITY is never zero; NoteOn commands with zero velocity are coded as
NoteOff commands in the NoteOff bitfield structure.

The note log does not code the execution time list are of one type
(RPN and NRPN), and all parameter numbers lie in the NoteOn command.
However, range 0-127. As
described in Appendix A.4.1, senders MAY signal this condition by
setting the Y top-level Chapter M header bit codes a hint from Z to 1 (to code the sender about
restricted range) and by setting the NoteOn
execution time. The Y U or W bit codes a recommendation to play (Y 1 (to code the
parameter type).

If the top-level Chapter M header codes Z = 1) 1 and either U = 1 or
skip (Y
W = 0) the NoteOn command recovered from the note log. See
Section 4.2 of [GUIDE] for non-normative guidance on 1, all logs in the parameter log list MUST use a modified header
format. This modification deletes bits 8-15 of the Y
bit.

Figure A.6.1 shows the NoteOff bitfield structure, as the list of
OFFBITS octets at the end shown in
Figure A.4.2, to yield a 2-octet header. The values of the chapter. A NoteOff OFFBITS octet codes
NoteOff information for eight consecutive MIDI note numbers, with deleted
PNUM-MSB and Q fields may be inferred from the
most-significant U, W, and Z bit representing
values.

A.4.2.1. The Value Tool

The value tool uses several fields to track the lowest note number. value of an RPN or
NRPN parameter.

The most-
significant J TOC bit of the first OFFBITS octet codes the note number 8*LOW;
the most-significant bit presence of the last OFFBITS octet codes shown in Figure A.4.3
in the note number
8*HIGH.

A set bit field list.

0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|X| ENTRY-MSB |
+-+-+-+-+-+-+-+-+

Figure A.4.3 -- ENTRY-MSB field

The 7-bit ENTRY-MSB field codes a NoteOff the data value of the most recent
active Control Change command for controller number 6 (Data Entry
MSB) in the note number. In session history that appears in a transaction for the log
parameter.

The X bit MUST be set to 1 if the command coded by ENTRY-MSB precedes
the most
efficient coding recent Control Change command for controller 121 (Reset All
Controllers) in the NoteOff bitfield structure, the first and last
octets of session history. Otherwise, the structure contain at least one X bit MUST be
set bit. Note that Chapter

N does not code NoteOff velocity data.

Note to 0.

A parameter log that in the general case, uses the recovery journal does not code value tool MUST include the
relative placement of a NoteOff command and a Change ENTRY-MSB
field if an active Control Change command for controller 64 (Damper Pedal (Sustain)). In many cases, a receiver
processing a loss event may deduce this relative placement from the
history of number 6
appears in the stream, checkpoint history.

Note that [RP015] specifies that Control Change commands for
controller 121 (Reset All Controllers) do not reset RPN and NRPN
values, and thus determine if a NoteOff note is sustained
by the pedal. If such a determination is X bit would not possible, receivers SHOULD
err on the side of silencing pedal sustains, as erroneously sustained
notes may produce unpleasant (albeit transient) artifacts.

A.7 Chapter E: MIDI Note Command Extras

Readers may wish to review the Appendix A.1 definition of "N-active
commands" before reading this Appendix. In this Appendix, a NoteOn
command with a velocity of 0 is considered to be a NoteOff command with play a release velocity value of 64.

Chapter E encodes recovery information about role for MIDI NoteOn (0x9) and
NoteOff (0x8) command features
systems that rarely appear in MIDI streams.
Receivers use Chapter E to reduce transient artifacts for streams where
several NoteOn commands appear comply with [RP015].

However, certain renderers (such as DLS 2 [DLS2]) specify that
certain RPN values are reset for some uses of Reset All Controllers.
The X bit (and other bitfield features of this nature in this
appendix) plays a note number without an intervening
NoteOff. Receivers also use Chapter E to reduce transient artifacts role in recovery for
streams that use NoteOff release velocity. Chapter E supplements renderers of this type.

The K TOC bit codes the
note information coded presence of the octet shown in Chapter N (Appendix A.6). Figure A.7.1 shows A.4.4
in the format for Chapter E.

0 1 2 3
0 1 2 3 4 5 6 7 8 9 field list.

0 1 2 3 4 5 6 7 8 9
0 1 2 3 4 5 6 7 8 8 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| LEN |S| NOTENUM |V| COUNT/VEL |S| NOTENUM |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V| COUNT/VEL | ....
+-+-+-+-+-+-+-+-+
|X| ENTRY-LSB |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+

Figure A.7.1 A.4.4 -- Chapter E format

The chapter consists of a 1-octet header, followed by a variable length
list of 2-octet note logs. Appendix A.7.1 defines the bitfield format
for a note log.

The log list MUST contain at least one note log. ENTRY-LSB field

The 7-bit LEN header ENTRY-LSB field codes the number data value of note logs the most recent
active Control Change command for controller number 38 (Data Entry
LSB) in the list, minus one. A channel
journal session history that appears in a transaction for the log
parameter.

The X bit MUST contain Chapter E be set to 1 if the rules defined command coded by ENTRY-LSB precedes
the most recent Control Change command for controller 121 (Reset All
Controllers) in this Appendix
require the session history. Otherwise, the X bit MUST be
set to 0.

As a rule, a parameter log that one or more note logs appear uses the value tool MUST include the
ENTRY-LSB field if an active Control Change command for controller
number 38 appears in the list. The note log
list checkpoint history. However, the ENTRY-LSB
field MUST obey NOT appear in a parameter log if the oldest-first ordering rule (defined Control Change
command associated with the ENTRY-LSB precedes a Control Change
command for controller number 6 (Data Entry MSB) that appears in Appendix A.1).

A.7.1 Note Log Format

Figure A.7.2 reproduces a
transaction for the note log structure parameter in the session history.

The L TOC bit codes the presence of Chapter E. the octets shown in Figure A.4.5
in the field list.

0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| NOTENUM |V| COUNT/VEL
|G|X| A-BUTTON |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure A.7.2 A.4.5 -- Chapter E note log

A note log codes information about the MIDI note number coded by the
7-bit NOTENUM field. The nature of the information depends on the value
of the V flag bit.

If the V bit is set to 1, the COUNT/VEL A-BUTTON field codes the release velocity
value for the most recent N-active NoteOff command for the note number
that appears in the session history.

If the V bit is set to 0, the COUNT/VEL

The 14-bit A-BUTTON field codes a reference count of the number of NoteOn and NoteOff active
Control Change commands for controller numbers 96 and 97 (Data
Increment and Data Decrement) in the note number session history that appear in a
transaction for the session history. log parameter.

The reference count is set to 0 at M TOC bit codes the start presence of the session. NoteOn
commands increment the count by 1. NoteOff commands decrement the count
by 1. However, a decrement that generates a negative count value is not
performed.

If the reference count is octets shown in Figure A.4.6
in the range 0-126, the 7-bit COUNT/VEL field
codes an unsigned integer representation of the count. If the count is
greater or equal to 127, COUNT/VEL is set list.

0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|G|R| C-BUTTON |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure A.4.6 -- C-BUTTON field

The 14-bit C-BUTTON field has semantics identical to 127.

By default, A-BUTTON, except
that Data Increment and Data Decrement Control Change commands that
precede the count is reset to 0 whenever a Reset State most recent Control Change command
(Appendix A.1) appears for controller 121
(Reset All Controllers) in the session history, history are not counted.

For both A-BUTTON and whenever MIDI C-BUTTON, Data Increment and Data Decrement
Control Change commands are not counted if they precede Control
Changes commands for controller numbers 123-127 (numbers with All Notes
Off semantics) 6 (Data Entry MSB) or 120 (All Sound Off) 38
(Data Entry LSB) that appear in a transaction for the log parameter
in the session history.

A.7.2 Log Inclusion Rules

The A-BUTTON and C-BUTTON fields are interpreted as unsigned
integers, and the most recent N-active NoteOn G bit associated the field codes the sign of the
integer (G = 0 for positive or NoteOff command zero, G = 1 for a note number
in negative).

To compute and code the checkpoint history is a NoteOff command with a release velocity count value, initialize the count value other than 64, a note log whose V bit is set to 0,
add 1 for each qualifying Data Increment command, and subtract 1 MUST appear in
Chapter E for
each qualifying Data Decrement command. After each add or subtract,
limit the note number.

If count magnitude to 16383. The G bit codes the most recent N-active NoteOn or NoteOff command for a note number

in sign of the checkpoint history is a NoteOff command,
count, and if the reference
count for A-BUTTON or C-BUTTON field codes the note number is greater than 0, a note log whose V bit is
set to 0 MUST appear in Chapter E for count magnitude.

For the note number.

If A-BUTTON field, if the most recent N-active NoteOn qualified Data Increment
or NoteOff Data Decrement command precedes the most recent Control Change
command for a note number controller 121 (Reset All Controllers) in the checkpoint history is a NoteOn command, and if the reference
count for session
history, the note number is greater than 1, a note log whose V X bit is
set to 0 associated with A-BUTTON field MUST appear in Chapter E for the note number.

At most two note logs MAY appear in Chapter E for a note number: one log
whose V bit is set to 0, and one log whose V bit is be set to 1.

Chapter E codes a maximum of 128 note logs. If
Otherwise, the log inclusion rules
yield more than 128 REQUIRED logs, note logs whose V X bit is set to 1 MUST be dropped from Chapter E in order to reach the 128-log limit.
Note logs whose V bit is set to 0 MUST NOT be dropped.

Most MIDI streams do not use NoteOn and NoteOff commands in ways that
would trigger the log inclusion rules. For these streams, Chapter E
would never be REQUIRED to appear in a channel journal.

The ch_never 0.

A parameter (Appendix C.2.3) may be used to configure the log
inclusion rules for Chapter E.

A.8 Chapter T: MIDI Channel Aftertouch

A channel journal that uses the value tool MUST contain Chapter T include the A-BUTTON
and C-BUTTON fields if an N-active and C-active
MIDI Channel Aftertouch (0xD) active Control Change command for
controller numbers 96 or 97 appears in the checkpoint history.
Figure A.8.1 shows the format for Chapter T.

0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|S| PRESSURE |
+-+-+-+-+-+-+-+-+

Figure A.8.1 -- Chapter T format

The chapter
However, to improve coding efficiency, this rule has a fixed size of 8 bits. The 7-bit PRESSURE field holds several
exceptions:

o If the pressure value of log includes the most recent N-active A-BUTTON field, and C-active Channel
Aftertouch command in if the session history.

Chapter T only encodes commands that are C-active X bit of the
A-BUTTON field is set to 1, the C-BUTTON field (and its
associated R and N-active. We
define a C-active restriction because [RP015] declares G bits) MAY be omitted from the log.

o If the log includes the A-BUTTON field, and if the A-BUTTON and
C-BUTTON fields (and their associated G bits) code identical
values, the C-BUTTON field (and its associated R and G bits) MAY
be omitted from the log.

A.4.2.2. The Count Tool

The count tool tracks the number of transactions for an RPN or NRPN
parameter. The N TOC bit codes the presence of the octet shown in
Figure A.4.7 in the field list.

0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|X| COUNT |
+-+-+-+-+-+-+-+-+

Figure A.4.7 -- COUNT field

The 7-bit COUNT codes the number of initiated transactions for the
log parameter that a appear in the session history. Initiated
transactions are counted if they contain one or more active Control
Change commands, including commands for controllers 98-101 that
initiate the parameter transaction.

If the most recent counted transaction precedes the most recent
Control Change command for controller 121 (Reset All Controllers) acts in
the session history, the X bit associated with the COUNT field MUST
be set to reset 1. Otherwise, the channel pressure X bit MUST be set to 0.

Transaction counting is performed modulo 128. The transaction count
is set to 0 (see the discussion at the end start of Appendix A.5
for a more complete rationale).

We define an N-active restriction on the assumption that aftertouch
commands are linked to note activity, and thus Channel Aftertouch
commands that are not N-active are stale session and should not be used is reset to
repair 0 whenever a stream.

A.9
Reset State command (Appendix A.1) appears in the session history.

A parameter log that uses the count tool MUST include the COUNT field
if an active command that increments the transaction count (modulo
128) appears in the checkpoint history.

A.5. Chapter A: W: MIDI Poly Aftertouch Pitch Wheel

A channel journal MUST contain Chapter A W if a C-active Poly Aftertouch
(0xA) MIDI Pitch
Wheel (0xE) command appears in the checkpoint history. Figure A.9.1 A.5.1
shows the format for Chapter A.

0 1 2 3 W.

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| LEN |S| NOTENUM |X| PRESSURE
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| NOTENUM |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|X| PRESSURE | .... FIRST |R| SECOND |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure A.9.1 A.5.1 -- Chapter A W format

The chapter consists of a 1-octet header, followed by has a variable length
list fixed size of 2-octet note logs. A note log MUST appear for a note number if
a C-active Poly Aftertouch command for the note number appears in the
checkpoint history. A note number MUST NOT be represented by multiple
note logs in the note list. 16 bits. The note log list MUST obey FIRST and SECOND fields
are the oldest-
first ordering rule (defined in Appendix A.1).

The 7-bit LEN field codes the number of note logs in the list, minus
one. Figure A.9.2 reproduces the note log structure values of Chapter A.

0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| NOTENUM |X| PRESSURE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure A.9.2 -- Chapter A note log

The 7-bit PRESSURE field codes the pressure value first and second data octets of the most
recent C- active Poly Aftertouch Pitch Wheel command in the session history for the MIDI note
number coded in the 7-bit NOTENUM field.

As a rule, the X bit MUST be set to 0. However, the X bit MUST be set
to 1 if the command coded by the log appears before one of the following history.

Note that Chapter W encodes C-active commands in the session history: MIDI Control Change numbers 123-127
(numbers with All Notes Off semantics) or 120 (All Sound Off).

We define and thus does not
encode active commands that are not C-active restrictions (see the second-to-last
paragraph of Appendix A.1 for an explanation of chapter inclusion
text in this regard).

Chapter A W does not encode "active but not C-active" commands because
[RP015] declares that a Control Change command commands for controller number
121 (Reset All Controllers)
acts act to reset the polyphonic pressure Pitch Wheel value to 0 (see 0.
If Chapter W encoded "active but not C-active" commands, a repair
operation following a Reset All Controllers command could incorrectly
repair the discussion at stream with a stale Pitch Wheel value.

A.6. Chapter N: MIDI NoteOff and NoteOn

In this appendix, we consider NoteOn commands with zero velocity to
be NoteOff commands. Readers may wish to review the
end of Appendix A.5 A.1
definition of "N-active commands" before reading this appendix.

Chapter N completely protects note commands in streams that alternate
between NoteOn and NoteOff commands for a more complete rationale).

B. The Recovery Journal System Chapters

B.1 System particular note number.
However, in rare applications, multiple overlapping NoteOn commands
may appear for a note number. Chapter D: Simple System Commands

The system E, described in Appendix A.7,
augments Chapter N to completely protect these streams.

A channel journal MUST contain Chapter D N if an active MIDI Reset
(0xFF), MIDI Tune Request (0xF6), MIDI Song Select (0xF3), undefined N-active MIDI System Common (0xF4 and 0xF5), NoteOn
(0x9) or undefined MIDI System Real-time
(0xF9 and 0xFD) NoteOff (0x8) command appears in the checkpoint history.
Figure B.1.1 A.6.1 shows the variable-length format for Chapter D. N.

0 1 2 3
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 8 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S|B|G|H|J|K|Y|Z| Command logs ...
|B| LEN | LOW | HIGH |S| NOTENUM |Y| VELOCITY |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| NOTENUM |Y| VELOCITY | .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OFFBITS | OFFBITS | .... | OFFBITS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure B.1.1 A.6.1 -- System Chapter D N format

The chapter

Chapter N consists of a 1-octet 2-octet header, followed by at least one or more
command logs. Header flag bits indicate of
the presence following data structures:

o A list of command note logs
for the Reset (B = 1), Tune Request (G = 1), Song Select (H = 1),
undefined System Common 0xF4 (J = 1), undefined System Common 0xF5 (K =
1), undefined System Real-time 0xF9 (Y = 1), or undefined System Real-
time 0xFD (Z = 1) to code NoteOn commands.

Command logs appear in a list following the header, in the order that
o A NoteOff bitfield structure to code NoteOff commands.

We define the flag bits appear header bitfield semantics in Appendix A.6.1. We define
the header.

Figure B.1.2 shows the 1-octet command log format for the Reset and Tune
Request commands.

0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|S| COUNT |
+-+-+-+-+-+-+-+-+

Figure B.1.2 -- Command note log for Reset semantics and Tune Request

Chapter D MUST contain the Reset command log if an active Reset command
appears NoteOff bitfield semantics in Appendix
A.6.2.

If one or more N-active NoteOn or NoteOff commands in the checkpoint history. The 7-bit COUNT field codes
history reference a note number, the
total note number of Reset commands (modulo 128) present MUST be coded in
either the session
history.

Chapter D MUST contain note log list or the Tune Request command NoteOff bitfield structure.

The note log if list MUST contain an active Tune
Request command appears in the entry for all note numbers whose
most recent checkpoint history. The 7-bit COUNT
field codes the total number of Tune Request commands (modulo 128)
present in the session history.

For these commands, the COUNT field acts as a reference count. See the
definition of "session history reference counts" appearance is in Appendix A.1 for
more information.

Figure B.1.3 shows the 1-octet command log format for the Song Select an N-active NoteOn
command.

0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|S| VALUE |
+-+-+-+-+-+-+-+-+

Figure B.1.3 -- Song Select command log format

Chapter D The NoteOff bitfield structure MUST contain the Song Select command log if an active Song
Select command appears in the a set bit for
all note numbers whose most recent checkpoint history. The 7-bit VALUE field
codes the song history appearance is
in an N-active NoteOff command.

A note number of MUST NOT be coded in both structures.

All note logs and NoteOff bitfield set bits MUST code the most recent active Song Select command
N-active NoteOn or NoteOff reference to a note number in the session
history.

B.1.1 Undefined System Commands

In this section, we define the Chapter D command logs for the undefined
System commands. [MIDI] reserves

The note log list MUST obey the undefined System commands 0xF4,
0xF5, 0xF9, and 0xFD oldest-first ordering rule (defined
in Appendix A.1).

A.6.1. Header Structure

The header for future use. At the time of this writing, any
MIDI command stream that uses these commands is non-compliant with
[MIDI]. However, future versions of [MIDI] may define these commands,
and a few products do use these commands Chapter N, shown in a non-compliant manner. Figure B.1.4 shows A.6.2, codes the variable length command log format for size of
the
undefined System Common commands (0xF4 note list and 0xF5).

0 1 2 3 bitfield structures.

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S|C|V|L|DSZ| LENGTH | COUNT | VALUE ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|B| LEN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ LOW | LEGAL ... HIGH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure B.1.4 A.6.2 -- Undefined System Common command log format

The command log codes a single command type (0xF4 or 0xF5, not both).
Chapter D MUST contain a command log if an active 0xF4 command appears
in the checkpoint history, and MUST contain an independent command log
if an active 0xF5 command appears in the checkpoint history. Chapter D consists of a two-octet N header followed by a variable number
of data fields. Header flag bits indicate the presence of the COUNT
field (C = 1), the VALUE field (V = 1), and the LEGAL field (L = 1).

The 10-bit LENGTH field LEN field, a 7-bit integer value, codes the size number of 2-octet
note logs in the command log, note list. Zero is a valid value for LEN and conforms
to semantics described in Appendix A.1.

The 2-bit DSZ field codes
an empty note list.

The 4-bit LOW and HIGH fields code the number of data OFFBITS octets in the command
instance that appears most recently in
follow the session history. note log list. LOW and HIGH are unsigned integer values.
If DSZ =
0-2, LOW <= HIGH, there are (HIGH - LOW + 1) OFFBITS octets in the command has 0-2 data octets. If DSZ
chapter. The value pairs (LOW = 3, the command has 3 or
more command data octets.

We now define the default rules for the use of the COUNT, VALUE, 15, HIGH = 0) and
LEGAL fields. The session configuration tools defined in Appendix C.2.3
may be used to override this behavior.

By default, if the DSZ field is set to 0, the command log (LOW = 15, HIGH =
1) code an empty NoteOff bitfield structure (i.e., no OFFBITS
octets). Other (LOW > HIGH) value pairs MUST include NOT appear in the COUNT field.
header.

The 8-bit COUNT field codes the total number of
commands of the type coded by the log (0xF4 or 0xF5) present in B bit provides S-bit functionality (Appendix A.1) for the
session history, modulo 256. NoteOff
bitfield structure. By default, if the DSZ field is B bit MUST be set to 1-3, 1.
However, if the MIDI command log MUST include
the VALUE field. The variable-length VALUE field codes a verbatim copy
the data octets for the most recent use section of the previous packet (packet I
- 1, with I as defined in Appendix A.1) includes a NoteOff command type coded by
for the
log (0xF4 or 0xF5) in channel, the session history. The most-significant B bit of
the final data octet MUST be set to 1, and 0. If the most-significant B bit of
all other data octets MUST be set to 0.

The LEGAL field is reserved for future use. If an update set to [MIDI]
defines the 0xF4 or 0xF5 command, an IETF standards-track document may
define the LEGAL field. Until such a document appears, senders MUST NOT
use
0, the LEGAL field, and receivers higher-level recovery journal elements that contain Chapter N
MUST use the LENGTH field have S bits that are set to skip
over 0, including the LEGAL field. top-level journal
header.

The LEGAL field would be defined by the IETF if LEN value of 127 codes a note list length of 127 or 128 note
logs, depending on the semantics values of LOW and HIGH. If LEN = 127, LOW =
15, and HIGH = 0, the new 0xF4 or 0xF5 command could not be protected
from packet loss via note list holds 128 note logs, and the use NoteOff
bitfield structure is empty. For other values of LOW and HIGH, LEN =
127 codes that the COUNT note list contains 127 note logs. In this case,
the chapter has (HIGH - LOW + 1) NoteOff OFFBITS octets if LOW <=
HIGH and VALUE fields. has no OFFBITS octets if LOW = 15 and HIGH = 1.

A.6.2. Note Structures

Figure B.1.5 A.6.3 shows the variable length command 2-octet note log format for the
undefined System Real-time commands (0xF9 and 0xFD).

0 1 2 3 structure.

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S|C|L| LENGTH | COUNT | LEGAL ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| NOTENUM |Y| VELOCITY |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure B.1.5 A.6.3 -- Undefined System Real-time command Chapter N note log format

The command log 7-bit NOTENUM field codes a single command type (0xF9 or 0xFD, not both).
Chapter D the note number for the log. A note
number MUST contain a command log if an active 0xF9 command appears
in the checkpoint history, and MUST contain an independent command log
if an active 0xFD command appears in the checkpoint history.

Chapter D consists of a one-octet header followed NOT be represented by a variable number
of data fields. Header flag bits indicate the presence of the COUNT
field (C = 1) and multiple note logs in the LEGAL field (L = 1). note
list.

The 5-bit LENGTH 7-bit VELOCITY field codes the size of velocity value for the most recent
N-active NoteOn command log, and conforms to semantics described in
Appendix A.1.

We now define the default rules for the use of note number in the COUNT and LEGAL
fields. The session configuration tools defined in Appendix C.2.3 history.
Multiple overlapping NoteOns for a given note number may be used to override this behavior.

The 8-bit COUNT field codes the total number of commands of the type coded by the log present
using Chapter E, as discussed in the session history, modulo 256. By
default, the COUNT field MUST be present Appendix A.7.

VELOCITY is never zero; NoteOn commands with zero velocity are coded
as NoteOff commands in the command log. NoteOff bitfield structure.

The LEGAL field is reserved for future use. If an update to [MIDI]
defines the 0xF9 or 0xFD command, an IETF standards-track document may
define note log does not code the LEGAL field to protect execution time of the NoteOn command. Until such
However, the Y bit codes a document
appears, senders MUST NOT use hint from the LEGAL field, and receivers MUST use sender about the LENGTH field NoteOn
execution time. The Y bit codes a recommendation to play (Y = 1) or
skip over the LEGAL field. The LEGAL field would be
defined by the IETF if the semantics of (Y = 0) the new 0xF9 or 0xFD NoteOn command
could not be protected recovered from packet loss via the note log. See
Section 4.2 of [RFC4696] for non-normative guidance on the use of the COUNT field.

Finally, we note that some non-standard uses
Y bit.

Figure A.6.1 shows the NoteOff bitfield structure, as the list of
OFFBITS octets at the undefined System
Real-time commands act to implement non-compliant variants end of the MIDI
sequencer system. In Appendix B.3.1, we describe resiliency tools chapter. A NoteOff OFFBITS octet
codes NoteOff information for
the MIDI sequencer system that provide some protection in this case.

B.2 System Chapter V: Active Sense Command

The system journal MUST contain Chapter V if an active eight consecutive MIDI Active Sense
(0xFE) command appears in note numbers,
with the checkpoint history. Figure B.2.1 shows most-significant bit representing the format for Chapter V.

0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|S| COUNT |
+-+-+-+-+-+-+-+-+

Figure B.2.1 -- System Chapter V format lowest note number.
The 7-bit COUNT field most-significant bit of the first OFFBITS octet codes the total note
number 8*LOW; the most-significant bit of Active Sense commands
(modulo 128) present in the session history. The COUNT field acts as a
reference count. See last OFFBITS octet
codes the definition of "session history reference
counts" in Appendix A.1 note number 8*HIGH.

A set bit codes a NoteOff command for more information.

B.3 System Chapter Q: Sequencer State Commands

This Appendix describes Chapter Q, the system chapter note number. In the most
efficient coding for the MIDI
sequencer commands.

The system journal MUST NoteOff bitfield structure, the first and
last octets of the structure contain at least one set bit. Note that
Chapter Q if an active MIDI Song
Position Pointer (0xF2), MIDI Clock (0xF8), MIDI Start (0xFA), MIDI
Continue (0xFB) or MIDI Stop (0xFC) command appears N does not code NoteOff velocity data.

Note that in the checkpoint
history, general case, the recovery journal does not code the
relative placement of a NoteOff command and a Change Control command
for controller 64 (Damper Pedal (Sustain)). In many cases, a
receiver processing a loss event may deduce this relative placement
from the history of the stream and thus determine if a NoteOff note
is sustained by the rules defined in this Appendix require pedal. If such a change in determination is not possible,
receivers SHOULD err on the Chapter Q bitfield contents because side of silencing pedal sustains, as
erroneously sustained notes may produce unpleasant (albeit transient)
artifacts.

A.7. Chapter E: MIDI Note Command Extras

Readers may wish to review the Appendix A.1 definition of "N-active
commands" before reading this appendix. In this appendix, a NoteOn
command appearance. with a velocity of 0 is considered to be a NoteOff command
with a release velocity value of 64.

Chapter E encodes recovery information about MIDI NoteOn (0x9) and
NoteOff (0x8) command features that rarely appear in MIDI streams.
Receivers use Chapter E to reduce transient artifacts for streams
where several NoteOn commands appear for a note number without an
intervening NoteOff. Receivers also use Chapter E to reduce
transient artifacts for streams that use NoteOff release velocity.
Chapter E supplements the note information coded in Chapter N
(Appendix A.6).

Figure B.3.1 A.7.1 shows the variable-length format for Chapter Q. E.

0 1 2 3
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 8 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S|N|D|C|T| TOP | CLOCK | TIMETOOLS ...
|S| LEN |S| NOTENUM |V| COUNT/VEL |S| NOTENUM |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V| COUNT/VEL | ... .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure B.3.1 A.7.1 -- System Chapter Q E format

Chapter Q

The chapter consists of a 1-octet header header, followed by several optional
fields, in the order shown in Figure B.3.1.

Header flag bits signal the presence a variable-
length list of the 16-bit CLOCK field (C = 1)
and the 24-bit TIMETOOLS field (T = 1). The 3-bit TOP header field is
interpreted as an unsigned integer, as are CLOCK and TIMETOOLS. We
describe the TIMETOOLS field in 2-octet note logs. Appendix B.3.1.

Chapter Q encodes the most recent state of the sequencer system.
Receivers use the chapter to re-synchronize A.7.1 defines the sequencer after
bitfield format for a packet
loss episode. Chapter fields encode the on/off state of the sequencer,
the current position in the song, and the downbeat. note log.

The N log list MUST contain at least one note log. The 7-bit LEN
header bit encodes field codes the relative occurrence number of the Start, Stop, and
Continue commands note logs in the session history. If an active Start or
Continue command appears most recently, the N bit list, minus one. A
channel journal MUST be set to 1. If
an active Stop appears most recently, or contain Chapter E if no active Start, Stop, the rules defined in this
appendix require that one or
Continue commands more note logs appear in the session history, the N bit MUST be set
to 0. list. The C header flag, the TOP header field, and the CLOCK field act to code
note log list MUST obey the current position oldest-first ordering rule (defined in
Appendix A.1).

A.7.1. Note Log Format

Figure A.7.2 reproduces the sequence:

o If C = 1, the 3-bit TOP header field and the 16-bit
CLOCK field are combined to form the 19-bit unsigned quantity
65536*TOP + CLOCK. This value encodes the song position
in units note log structure of MIDI Clocks (24 clocks per quarter note),
modulo 524288. Note that Chapter E.

0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| NOTENUM |V| COUNT/VEL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure A.7.2 -- Chapter E note log

A note log codes information about the maximum song position value
that may be MIDI note number coded by the Song Position Pointer command is
98303 clocks (which may be coded with 17 bits), and MIDI-coded
songs are generally constructed to avoid durations longer than
this value. However, the 19-bit size may be useful for
real-time applications, such as a drum machine MIDI output
that is sending clock commands for long periods
7-bit NOTENUM field. The nature of time.

o If C = 0, the song position is information depends on the start
value of the song.
The C = 0 position V flag bit.

If the V bit is identical set to the position coded
by C = 1, TOP = 0, and CLOCK = 0, for the case where COUNT/VEL field codes the song position is less than 524288 MIDI clocks.
In certain situations (defined later in this section),
normative text may require release
velocity value for the C = 0 or most recent N-active NoteOff command for the C = 1,
TOP = 0, CLOCK = 0 encoding of
note number that appears in the start of session history.

If the song.

The C, TOP, and CLOCK fields MUST be V bit is set to code the current song
position, for both N = 0 and N = 1 conditions. If C = 0, the TOP COUNT/VEL field
MUST be set to 0. See [MIDI] for codes a precise definition reference count
of a song
position.

The D header bit encodes information about the downbeat, number of NoteOn and acts to
qualify the song position coded by NoteOff commands for the C, TOP, and CLOCK fields.

If note number that
appear in the D bit session history.

The reference count is set to 1, 0 at the song position represents start of the most recent
position in session. NoteOn
commands increment the sequence count by 1. NoteOff commands decrement the
count by 1. However, a decrement that has played. generates a negative count
value is not performed.

If D = 1, the next Clock
command (if N = 1) or reference count is in the next (Continue, Clock) pair (if N = 0) acts to
increment range 0-126, the song position by one clock, and to play 7-bit COUNT/VEL
field codes an unsigned integer representation of the updated
position. count. If the D bit
count is greater than or equal to 127, COUNT/VEL is set to 0, 127.

By default, the song position represents count is reset to 0 whenever a position in the
sequence that has not yet been played. If D = 0, the next Clock Reset State command
(if N = 1) or
(Appendix A.1) appears in the next (Continue, Clock) pair (if N = 0) acts to play
the point session history, and whenever MIDI
Control Change commands for controller numbers 123-127 (numbers with
All Notes Off semantics) or 120 (All Sound Off) appear in the song coded by session
history.

A.7.2. Log Inclusion Rules

If the song position. The song position is
not incremented.

An example stream that uses D = 0 coding is one whose most recent
sequence command is a Start N-active NoteOn or Song Position Pointer NoteOff command (both N = 1
conditions). However, it for a note
number in the checkpoint history is also possible to construct examples where D
= 0 and N = 0. A Start command immediately followed by a Stop NoteOff command with a release
velocity value other than 64, a note log whose V bit is coded set to 1 MUST
appear in Chapter Q by setting C = 0, D = 0, N = 0, TOP = 0. E for the note number.

If N = 1 (coding Start or Continue), D = 0 (coding that the downbeat has
yet to be played), and most recent N-active NoteOn or NoteOff command for a note
number in the song position checkpoint history is at the start of a NoteOff command, and if the song,
reference count for the C = note number is greater than 0, a note log
whose V bit is set to 0 song position encoding MUST be used if a Start appear in Chapter E for the note number.

If the most recent N-active NoteOn or NoteOff command occurs
more recently than for a Continue command note
number in the session history, checkpoint history is a NoteOn command, and if the C
=
reference count for the note number is greater than 1, TOP = 0, CLOCK = a note log
whose V bit is set to 0 song position encoding MUST be used if a
Continue command occurs more recently than a Start command appear in the
session history.

B.3.1 Non-compliant Sequencers

The Chapter Q description in this Appendix assumes that E for the sequencer
system counts off time with Clock commands, as mandated note number.

At most, two note logs MAY appear in [MIDI].
However, Chapter E for a few non-compliant products do not use Clock commands note number: one
log whose V bit is set to count
off time, but instead use non-standard methods. 0, and one log whose V bit is set to 1.

Chapter Q uses E codes a maximum of 128 note logs. If the TIMETOOLS field log inclusion
rules yield more than 128 REQUIRED logs, note logs whose V bit is set
to provide resiliency support for
these non-standard products. By default, the TIMETOOLS field 1 MUST NOT
appear in be dropped from Chapter Q, and E in order to reach the T header 128-log
limit. Note logs whose V bit is set to 0 MUST NOT be set dropped.

Most MIDI streams do not use NoteOn and NoteOff commands in ways that
would trigger the log inclusion rules. For these streams, Chapter E
would never be REQUIRED to 0. The session
configuration tools described appear in Appendix C.2.3 a channel journal.

The ch_never parameter (Appendix C.2.3) may be used to select
TIMETOOLS coding.

Figure B.3.2 shows the format of configure the 24-bit TIMETOOLS field.

0 1 2
0 1 2 3 4 5 6 7 8 9
log inclusion rules for Chapter E.

A.8. Chapter T: MIDI Channel Aftertouch

A channel journal MUST contain Chapter T if an N-active and C-active
MIDI Channel Aftertouch (0xD) command appears in the checkpoint
history. Figure A.8.1 shows the format for Chapter T.

0
0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TIME
+-+-+-+-+-+-+-+-+
|S| PRESSURE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+

Figure B.3.2 A.8.1 -- TIMETOOLS Chapter T format

The TIME field is chapter has a 24-bit unsigned integer quantity, with units fixed size of
milliseconds. TIME codes an additive correction term for 8 bits. The 7-bit PRESSURE field
holds the song
position coded by pressure value of the TOP, CLOCK, C fields. TIME is coded most recent N-active and C-active
Channel Aftertouch command in network
byte order (big-endian).

A receiver computes the correct song position by converting TIME into
units of MIDI clocks session history.

Chapter T only encodes commands that are C-active and adding it to 65536*TOP + CLOCK (assuming C =
1). Alternatively, N-active. We
define a receiver may convert 65536*TOP + CLOCK into
milliseconds (assuming C = 1) and add it C-active restriction because [RP015] declares that a Control
Change command for controller 121 (Reset All Controllers) acts to TIME. The downbeat (D
header bit) semantics defined in Appendix B.3 apply
reset the channel pressure to 0 (see the corrected
song position.

B.4 System Chapter F: MIDI Time Code Tape Position

This Appendix describes Chapter F, discussion at the system chapter end of
Appendix A.5 for a more complete rationale).

We define an N-active restriction on the MIDI Time
Code (MTC) commands. Readers may wish assumption that aftertouch
commands are linked to review the Appendix A.1
definition of "finished/unfinished commands" before reading this
Appendix.

The system note activity, and thus Channel Aftertouch
commands that are not N-active are stale and should not be used to
repair a stream.

A.9. Chapter A: MIDI Poly Aftertouch

A channel journal MUST contain Chapter F A if an active System Common
Quarter Frame command (0xF1) or an active finished System Exclusive
(Universal Real Time) MTC Full Frame a C-active Poly
Aftertouch (0xA) command (F0 7F cc 01 01 hr mn sc fr
F7) appears in the checkpoint history. Otherwise, the system journal
MUST NOT contain Chapter F. Figure B.4.1
A.9.1 shows the variable-length format for Chapter F. A.

0 1 2 3
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 8 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S|C|P|Q|D|POINT| COMPLETE ...
|S| LEN |S| NOTENUM |X| PRESSURE |S| NOTENUM |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|X| PRESSURE | ... | PARTIAL ... .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+

Figure B.4.1 A.9.1 -- System Chapter F A format

Chapter F holds information about recent MTC tape positions coded in the
session history. Receivers use Chapter F to re-synchronize the MTC
system after a packet loss episode.

Chapter F

The chapter consists of a 1-octet header header, followed by several optional
fields, a variable-
length list of 2-octet note logs. A note log MUST appear for a note
number if a C-active Poly Aftertouch command for the note number
appears in the order shown checkpoint history. A note number MUST NOT be
represented by multiple note logs in Figure B.4.1. the note list. The C and P header bits
form a Table of Contents (TOC), and signal note log
list MUST obey the presence oldest-first ordering rule (defined in Appendix
A.1).

The 7-bit LEN field codes the number of note logs in the 32-bit
COMPLETE field (C = 1) and list, minus
one. Figure A.9.2 reproduces the 32-bit PARTIAL field (P = 1).

The Q header bit codes information about the COMPLETE field format. If note log structure of Chapter F does not contain a COMPLETE field, Q MUST be set to 0. A.

0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| NOTENUM |X| PRESSURE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure A.9.2 -- Chapter A note log

The D header bit 7-bit PRESSURE field codes the tape movement direction. If pressure value of the tape is
moving forward, or if most recent
C-active Poly Aftertouch command in the tape direction is indeterminate, session history for the D MIDI
note number coded in the 7-bit NOTENUM field.

As a rule, the X bit MUST be set to 0. If the tape is moving in the reverse direction, However, the D X bit MUST be
set to 1. In most cases, 1 if the ordering command coded by the log appears before one of the
following commands in the session history clearly defines the tape direction. However, history: MIDI Control Change
numbers 123-127 (numbers with All Notes Off semantics) or 120 (All
Sound Off).

We define C-active restrictions for Chapter A because [RP015]
declares that a few Control Change command sequences have an indeterminate direction (such as a session
history consisting of one Full Frame command).

The 3-bit POINT header field is interpreted as an unsigned integer.
Appendix B.4.1 defines how for controller 121 (Reset All
Controllers) acts to reset the POINT field codes information about polyphonic pressure to 0 (see the
contents of
discussion at the PARTIAL field. If Chapter F does not contain end of Appendix A.5 for a PARTIAL
field, POINT MUST be set to 7 (if D = 0) or 0 (if D = 1). more complete rationale).

B. The Recovery Journal System Chapters

B.1. System Chapter F D: Simple System Commands

The system journal MUST include the COMPLETE field contain Chapter D if an active finished Full
Frame command appears in the checkpoint history, MIDI Reset
(0xFF), MIDI Tune Request (0xF6), MIDI Song Select (0xF3), undefined
MIDI System Common (0xF4 and 0xF5), or if an active Quarter
Frame undefined MIDI System Real-
time (0xF9 and 0xFD) command that completes the encoding of a frame value appears in the checkpoint history.

The COMPLETE field encodes the most recent active complete MTC frame
value that appears in the session history. This frame value may take
the form of a series of 8 active Quarter Frame commands (0xF1 0x0n
through 0xF1 0x7n for forward tape movement, 0xF1 0x7n through 0xF1 0x0n
for reverse tape movement), or may take the form of an active finished
Full Frame command.

If the COMPLETE field encodes a Quarter Frame command series, the Q
header bit MUST be set to 1, and the COMPLETE field MUST have the format
shown in

Figure B.4.2. The 4-bit fields MT0 through MT7 code the data
(lower) nibble for B.1.1 shows the Quarter Frame commands for Message Type 0 through
Message Type 7 [MIDI]. These nibbles encode a complete frame value, in
addition to fields reserved variable-length format for future use by [MIDI]. Chapter D.

0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MT0 | MT1 | MT2 | MT3 | MT4 | MT5 | MT6 | MT7
|S|B|G|H|J|K|Y|Z| Command logs ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure B.4.2 B.1.1 -- COMPLETE field format, Q = 1

In this usage, the frame value encoded System Chapter D format

The chapter consists of a 1-octet header, followed by one or more
command logs. Header flag bits indicate the presence of command logs
for the Reset (B = 1), Tune Request (G = 1), Song Select (H = 1),
undefined System Common 0xF4 (J = 1), undefined System Common 0xF5 (K
= 1), undefined System Real-time 0xF9 (Y = 1), or undefined System
Real-time 0xFD (Z = 1) commands.

Command logs appear in a list following the COMPLETE field MUST be
offset by 2 frames (relative to header, in the frame value encoded order that
the flag bits appear in the Quarter
Frame commands) if header.

Figure B.1.2 shows the frame value codes a 0xF1 0x0n through 0xF1 0x7n 1-octet command sequence. This offset compensates log format for the two-frame latency Reset and
Tune Request commands.

0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|S| COUNT |
+-+-+-+-+-+-+-+-+

Figure B.1.2 -- Command log for Reset and Tune Request
Chapter D MUST contain the Reset command log if an active Reset
command appears in the checkpoint history. The 7-bit COUNT field
codes the total number of Reset commands (modulo 128) present in the Quarter Frame encoding for forward tape movement. No offset is
applied
session history.

Chapter D MUST contain the Tune Request command log if an active Tune
Request command appears in the frame value checkpoint history. The 7-bit COUNT
field codes the total number of Tune Request commands (modulo 128)
present in the session history.

For these commands, the COUNT field acts as a 0xF1 0x7n through 0xF1 0x0n Quarter
Frame reference count. See
the definition of "session history reference counts" in Appendix A.1
for more information.

Figure B.1.3 shows the 1-octet command sequence. log format for the Song Select
command.

0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|S| VALUE |
+-+-+-+-+-+-+-+-+

Figure B.1.3 -- Song Select command log format

Chapter D MUST contain the Song Select command log if an active Song
Select command appears in the checkpoint history. The 7-bit VALUE
field codes the song number of the most recent active complete MTC frame value may alternatively be
encoded by an active finished Full Frame command. Song Select
command in the session history.

B.1.1. Undefined System Commands

In this case, section, we define the Q
header bit MUST be set to 0, Chapter D command logs for the
undefined System commands. [MIDI] reserves the undefined System
commands 0xF4, 0xF5, 0xF9, and 0xFD for future use. At the COMPLETE field MUST have format
shown time of
this writing, any MIDI command stream that uses these commands is
non-compliant with [MIDI]. However, future versions of [MIDI] may
define these commands, and a few products do use these commands in a
non-compliant manner.

Figure B.4.3. The HR, MN, SC, and FR fields correspond to B.1.4 shows the
hr, mn, sc, and fr data octets of variable-length command log format for the Full Frame command.
undefined System Common commands (0xF4 and 0xF5).

0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S|C|V|L|DSZ| LENGTH | HR COUNT | MN VALUE ... | SC
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FR LEGAL ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure B.4.3 B.1.4 -- COMPLETE field format, Q = 0

B.4.1 Partial Frames Undefined System Common command log format

The most recent active session history command that encodes MTC frame
value data may be a Quarter Frame command other than a forward-moving
0xF1 0x7n command (which completes a frame value for forward tape
movement) or log codes a reverse-moving 0xF1 0x1n single command (which completes a frame
value for reverse tape movement).

We consider this type of Quarter Frame command to be associated with a
partial frame value. The Quarter Frame sequence that defines a partial
frame value MUST either start at Message Type 0 and increment
contiguously to an intermediate Message Type less than 7, (0xF4 or start at
Message Type 7 and decrement contiguously to an intermediate Message
type greater than 0. A Quarter Frame command sequence that does not
follow this pattern is 0xF5, not associated with a partial frame value. both).
Chapter F D MUST include contain a PARTIAL field command log if the most recent an active 0xF4 command
appears in the checkpoint history that encodes MTC frame value data is a Quarter
Frame and MUST contain an independent
command that is associated with a partial frame value. Otherwise, log if an active 0xF5 command appears in the checkpoint
history.

Chapter F MUST NOT include a PARTIAL field.

The partial frame value D consists of the a two-octet header followed by a variable
number of data (lower) nibbles fields. Header flag bits indicate the presence of the
Quarter Frame command sequence. The PARTIAL
COUNT field codes the partial
frame value, using (C = 1), the format shown in Figure B.4.2. Message Type
fields that are not associated with a Quarter Frame command MUST be set
to 0.

The POINT header VALUE field indicates the Message Type fields in (V = 1), and the PARTIAL LEGAL field code valid data. If P (L
= 1, the POINT 1). The 10-bit LENGTH field MUST encode the
unsigned integer value formed by codes the lower 3 bits size of the upper nibble of command log and
conforms to semantics described in Appendix A.1.

The 2-bit DSZ field codes the data value number of data octets in the most recent active Quarter Frame command
instance that appears most recently in the session history. If D = 0 and P DSZ = 1, POINT MUST take on a value in
0-2, the
range 0-6. command has 0-2 data octets. If D DSZ = 1 3, the command has 3
or more command data octets.

We now define the default rules for the use of the COUNT, VALUE, and P = 1, POINT MUST take on a value
LEGAL fields. The session configuration tools defined in Appendix
C.2.3 may be used to override this behavior.

By default, if the range
1-7.

If D = DSZ field is set to 0, MT fields (Figure B.4.2) in the inclusive range 0 up to and
including command log MUST
include the POINT value encode COUNT field. The 8-bit COUNT field codes the partial frame value. If D = 1, MT
fields in total
number of commands of the inclusive range 7 down to and including type coded by the POINT value
encode log (0xF4 or 0xF5)
present in the partial frame value. Note that unlike session history, modulo 256.

By default, if the COMPLETE DSZ field

encoding, senders MUST NOT add a 2-frame offset is set to 1-3, the partial frame
value encoded in PARTIAL.

For command log MUST
include the default semantics, if VALUE field. The variable-length VALUE field codes a recovery journal contains Chapter F, and
if the session history codes a legal [MIDI] series of Quarter Frame and
Full Frame commands,
verbatim copy the chapter always contains a COMPLETE or a PARTIAL
field (and may contain both fields). Thus, a one-octet Chapter F (C = P
= 0) always codes data octets for the presence most recent use of an illegal the command sequence
type coded by the log (0xF4 or 0xF5) in the session history (under some conditions, history. The
most-significant bit of the C = final data octet MUST be set to 1, P = 0 condition may
also code and
the presence most-significant bit of an illegal command sequence). all other data octets MUST be set to 0.

The illegal
command sequence conditions are transient in nature, and usually
indicate that a Quarter Frame command sequence began with an
intermediate Message Type.

B.5 System Chapter X: System Exclusive

This Appendix describes Chapter X, the system chapter LEGAL field is reserved for MIDI System
Exclusive (SysEx) commands (0xF0). Readers may wish future use. If an update to review [MIDI]
defines the
Appendix A.1 definition of "finished/unfinished commands" before reading
this Appendix.

Chapter X consists of a list of one 0xF4 or more command logs. Each log in 0xF5 command, an IETF standards-track document
may define the list codes information about LEGAL field. Until such a specific finished or unfinished SysEx
command that appears in document appears, senders
MUST NOT use the session history. The system journal LEGAL field, and receivers MUST
contain Chapter X if use the rules defined in Appendix B.5.2 require that
one or more logs appear in LENGTH field
to skip over the list. LEGAL field. The log list is not preceded LEGAL field would be defined by a header. Instead, each log implicitly
encodes its own length. Given the length of
the N'th list log, IETF if the
presence semantics of the (N+1)'th list log may new 0xF4 or 0xF5 command could not
be inferred protected from packet loss via the LENGTH field
of the system journal header (Figure 10 in Section 5 use of the main text).
The log list MUST obey the oldest-first ordering rule (defined in
Appendix A.1).

B.5.1 Chapter Format COUNT and VALUE
fields.

Figure B.5.1 B.1.5 shows the bitfield variable-length command log format for the Chapter X command log.
undefined System Real-time commands (0xF9 and 0xFD).

0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S|T|C|F|D|L|STA| TCOUNT
|S|C|L| LENGTH | COUNT | FIRST ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DATA LEGAL ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure B.5.1 B.1.5 -- Chapter X Undefined System Real-time command log format

The command log codes a single command type (0xF9 or 0xFD, not both).
Chapter X D MUST contain a command log if an active 0xF9 command
appears in the checkpoint history and MUST contain an independent
command log if an active 0xFD command appears in the checkpoint
history.

Chapter D consists of a 1-octet header, one-octet header followed by the
optional TCOUNT, COUNT, FIRST, and DATA fields.

The T, C, F, and D header bits act as a Table variable
number of Contents (TOC) for the
log. If T is set to 1, the 1-octet TCOUNT field appears in data fields. Header flag bits indicate the log. If
C is set to 1, presence of the 1-octet
COUNT field appears in the log. If F is set
to 1, (C = 1) and the variable-length FIRST LEGAL field appears in (L = 1). The 5-bit LENGTH
field codes the log. If D is set
to 1, size of the variable-length DATA field appears command log and conforms to semantics
described in Appendix A.1.

We now define the log.

The L header bit sets the coding tool default rules for the log. We define use of the log
coding COUNT and LEGAL
fields. The session configuration tools defined in Appendix B.5.2. C.2.3
may be used to override this behavior.

The STA 8-bit COUNT field codes the status total number of commands of the command type
coded by the log present in the session history, modulo 256. By
default, the COUNT field MUST be present in the command log.

The
2-bit STA value LEGAL field is interpreted as an unsigned integer. reserved for future use. If STA is 0, the
log codes an unfinished command. Non-zero STA values code different
classes of finished commands. An STA value of 1 codes a cancelled
command, an STA value of 2 codes a command that uses update to [MIDI]
defines the "dropped F7"
construction, and 0xF9 or 0xFD command, an STA value of 3 codes all other finished commands.
Section 3.2 in the main text describes cancelled and "dropped F7"
commands.

The S bit (Appendix A.1) of the first log in the list acts as IETF standards-track document
may define the S bit
for Chapter X. For LEGAL field to protect the other logs in command. Until such a
document appears, senders MUST NOT use the list, LEGAL field, and receivers
MUST use the S bit refers LENGTH field to skip over the
log itself. LEGAL field. The value of the "phantom" S bit associated with the first
log is LEGAL
field would be defined by the following rules:

o If the list codes one log, the phantom S-bit value is
the same as IETF if the Chapter X S-bit value.

o If semantics of the list codes multiple logs, new 0xF9
or 0xFD command could not be protected from packet loss via the phantom S-bit value is use
of the logical OR COUNT field.

Finally, we note that some non-standard uses of the S-bit value undefined System
Real-time commands act to implement non-compliant variants of the first and second
MIDI sequencer system. In Appendix B.3.1, we describe resiliency
tools for the MIDI sequencer system that provide some protection in
this case.

B.2. System Chapter V: Active Sense Command

The system journal MUST contain Chapter V if an active MIDI Active
Sense (0xFE) command logs appears in the list.

In all other respects, the S bit follows checkpoint history. Figure B.2.1
shows the semantics defined in
Appendix A.1. format for Chapter V.

0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|S| COUNT |
+-+-+-+-+-+-+-+-+

Figure B.2.1 -- System Chapter V format

The FIRST 7-bit COUNT field (present if F = 1) encodes a variable-length unsigned
integer value that sets codes the coverage total number of Active Sense commands
(modulo 128) present in the DATA field. session history. The FIRST COUNT field (present if F = 1) encodes acts as
a variable-length unsigned
integer value that specifies which SysEx data bytes are encoded in reference count. See the
DATA field definition of "session history reference
counts" in Appendix A.1 for more information.

B.3. System Chapter Q: Sequencer State Commands

This appendix describes Chapter Q, the log. system chapter for the MIDI
sequencer commands.

The FIRST field consists of system journal MUST contain Chapter Q if an octet whose most-
significant bit is set to 0, optionally preceded by one active MIDI Song
Position Pointer (0xF2), MIDI Clock (0xF8), MIDI Start (0xFA), MIDI
Continue (0xFB), or more octets
whose most-significant bit is set to 1. The algorithm shown MIDI Stop (0xFC) command appears in Figure
B.5.2 decodes this format into an unsigned integer, to yield the value
dec(FIRST). FIRST uses a variable-length encoding because dec(FIRST)
references a data octet in a SysEx command,
checkpoint history, and a SysEx command may
contain an arbitrary number of data octets.

One-Octet FIRST value:

Encoded form: 0ddddddd
Decoded form: 00000000 00000000 00000000 0ddddddd

Two-Octet FIRST value:

Encoded form: 1ccccccc 0ddddddd
Decoded form: 00000000 00000000 00cccccc cddddddd

Three-Octet FIRST value:

Encoded form: 1bbbbbbb 1ccccccc 0ddddddd
Decoded form: 00000000 000bbbbb bbcccccc cddddddd

Four-Octet FIRST value:

Encoded form: 1aaaaaaa 1bbbbbbb 1ccccccc 0ddddddd
Decoded form: 0000aaaa aaabbbbb bbcccccc cddddddd

Figure B.5.2 -- Decoding FIRST field formats

The DATA field (present if D = 1) encodes the rules defined in this appendix require
a modified version of change in the data
octets Chapter Q bitfield contents because of the SysEx command coded by
appearance.

Figure B.3.1 shows the log. Status octets MUST NOT be
coded variable-length format for Chapter Q.

0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S|N|D|C|T| TOP | CLOCK | TIMETOOLS ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure B.3.1 -- System Chapter Q format
Chapter Q consists of a 1-octet header followed by several optional
fields, in the DATA field.

If F = 0, the DATA field begins with order shown in Figure B.3.1.

Header flag bits signal the first data octet presence of the SysEx
command, 16-bit CLOCK field (C =
1) and includes all subsequent data octets for the command that
appear in the session history. If F 24-bit TIMETOOLS field (T = 1, the DATA 1). The 3-bit TOP header
field begins with the
(dec(FIRST) + 1)'th data octet of the SysEx command, is interpreted as an unsigned integer, as are CLOCK and includes all
subsequent data octets for
TIMETOOLS. We describe the command that appear TIMETOOLS field in Appendix B.3.1.

Chapter Q encodes the session
history. Note that most recent state of the word "command" in sequencer system.
Receivers use the descriptions above refers chapter to re-synchronize the original SysEx command as it appears in the source MIDI data
stream, not to sequencer after a particular MIDI list SysEx command segment.

The length
packet loss episode. Chapter fields encode the on/off state of the DATA field is coded implicitly, using
sequencer, the most-
significant bit of each octet. current position in the song, and the downbeat.

The most-significant N header bit of encodes the final
octet relative occurrence of the DATA field Start, Stop,
and Continue commands in the session history. If an active Start or
Continue command appears most recently, the N bit MUST be set to 1. The
If an active Stop appears most significant recently, or if no active Start, Stop,
or Continue commands appear in the session history, the N bit of
all other DATA octets MUST be
set to 0. This coding method relies on

The C header flag, the fact that TOP header field, and the most-significant bit of a MIDI data octet is 0 by
definition. Apart from this length-coding modification, the DATA CLOCK field
encodes a verbatim copy of all data octets it encodes.

B.5.2 Log Inclusion Semantics

Chapter X offers two tools act to protect SysEx commands:
code the "recency" tool current position in the sequence:

o If C = 1, the 3-bit TOP header field and the "list" tool. The tool definitions use 16-bit CLOCK field
are combined to form the concept of 19-bit unsigned quantity 65536*TOP +
CLOCK. This value encodes the "SysEx
type" song position in units of a command, which we now define.

Each SysEx MIDI
Clocks (24 clocks per quarter note), modulo 524288. Note that
the maximum song position value that may be coded by the Song
Position Pointer command instance in a session, excepting MTC Full Frame
commands, is said to have a "SysEx type". Types are used in equality
comparisons: two SysEx commands in a session 98303 clocks (which may be coded
with 17 bits), and that MIDI-coded songs are said generally
constructed to have "the same
SysEx type" or "different SysEx types".

If efficiency is not a concern, a sender may follow a simple typing
rule: every SysEx command in avoid durations longer than this value. However,
the session history has 19-bit size may be useful for real-time applications, such
as a different SysEx
type, and thus, no two drum machine MIDI output that is sending clock commands in for
long periods of time.

o If C = 0, the session have song position is the same type.

To improve efficiency, senders MAY implement exceptions to this rule.
These exceptions declare certain sets start of SysEx command instances the song. The C = 0
position is identical to have the same SysEx type. Any command not covered position coded by an exception follows
the simple rule. We list exceptions below:

o All commands with identical data octet fields (same number of
data octets, same value C = 1, TOP = 0,
and CLOCK = 0, for each data octet) have the same type.
This rule MUST be applied to all SysEx commands case where the song position is less than
524288 MIDI clocks. In certain situations (defined later in
this section), normative text may require the session, C = 0 or not at all. Note that the implementation of this exception
requires no sender knowledge C =
1, TOP = 0, CLOCK = 0 encoding of the format and semantics start of the SysEx commands in the stream, merely the ability song.

The C, TOP, and CLOCK fields MUST be set to count code the current song
position, for both N = 0 and compare octets.

o Two instances of N = 1 conditions. If C = 0, the same command whose semantics TOP
field MUST be set or report
the value to 0. See [MIDI] for a precise definition of the same "parameter" have the same type. a
song position.

The
implementation of this exception requires specific knowledge of D header bit encodes information about the format downbeat and semantics of SysEx commands. In practice, a
sender implementation chooses acts to support this exception for
certain classes of commands (such as
qualify the Universal System
Exclusive commands defined in [MIDI]). If a sender supports
this exception for a particular command in a class (for
example, song position coded by the Universal Real Time System Exclusive message
for Master Volume, F0 F7 cc 04 01 vv vv F7, defined in [MIDI]),
it MUST support C, TOP, and CLOCK fields.

If the exception D bit is set to all instances of this
particular command 1, the song position represents the most
recent position in the session.

We now use this definition of "SysEx type" sequence that has played. If D = 1, the next
Clock command (if N = 1) or the next (Continue, Clock) pair (if
N = 0) acts to define increment the "recency" tool song position by one clock, and to play
the "list" tool for Chapter X.

By default, updated position.

If the Chapter X log list MUST code sufficient information D bit is set to
protect 0, the rendered MIDI performance from indefinite artifacts caused

by song position represents a position in
the loss of all finished or unfinished active SysEx commands sequence that
appear has not yet been played. If D = 0, the next Clock
command (if N = 1) or the next (Continue, Clock) pair (if N = 0) acts
to play the point in the checkpoint history (excluding finished MTC Full Frame
commands, which are song coded in Chapter F (Appendix B.4)).

To protect by the song position. The song
position is not incremented.

An example of a stream that uses D = 0 coding is one whose most
recent sequence command of is a specific SysEx type with the recency tool,
senders MUST code Start or Song Position Pointer command
(both N = 1 conditions). However, it is also possible to construct
examples where D = 0 and N = 0. A Start command immediately followed
by a log Stop command is coded in Chapter Q by setting C = 0, D = 0,
N = 0, TOP = 0.

If N = 1 (coding Start or Continue), D = 0 (coding that the log list for the most recent finished
active instance of downbeat
has yet to be played), and the SysEx type that appears in song position is at the checkpoint
history. Additionally, if an unfinished active instance start of the SysEx
type appears in
song, the checkpoint history, senders C = 0 song position encoding MUST code be used if a log Start
command occurs more recently than a Continue command in the
log list for session
history, and the unfinished command instance. The L header bit of both
command logs C = 1, TOP = 0, CLOCK = 0 song position encoding
MUST be set to 0.

To protect used if a Continue command of occurs more recently than a specific SysEx type with Start
command in the list tool,
senders MUST code a log session history.

B.3.1. Non-compliant Sequencers

The Chapter Q description in this appendix assumes that the sequencer
system counts off time with Clock commands, as mandated in [MIDI].
However, a few non-compliant products do not use Clock commands to
count off time, but instead use non-standard methods.

Chapter X log list Q uses the TIMETOOLS field to provide resiliency support for each finished or
unfinished active instance of
these non-standard products. By default, the SysEx type that appears TIMETOOLS field MUST
NOT appear in Chapter Q, and the
checkpoint history. The L T header bit of list tool command logs MUST be set to 1.

As a rule, a log REQUIRED by the list or recency tool MUST include a
DATA field that codes all data octets that appear 0. The
session configuration tools described in Appendix C.2.3 may be used
to select TIMETOOLS coding.

Figure B.3.2 shows the checkpoint
history for the SysEx command instance associated with format of the log. 24-bit TIMETOOLS field.

0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TIME |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure B.3.2 -- TIMETOOLS format

The
FIRST TIME field MAY be used to configure is a DATA field that minimally meets
this requirement.

An exception to this rule applies to cancelled commands (defined in
Section 3.2). REQUIRED command logs associated 24-bit unsigned integer quantity, with cancelled commands
MAY be units of
milliseconds. TIME codes an additive correction term for the song
position coded by the TOP, CLOCK, and C fields. TIME is coded with no DATA field. However, if DATA appears in
network byte order (big-endian).

A receiver computes the log,
DATA MUST code all data octets that appear correct song position by converting TIME into
units of MIDI clocks and adding it to 65536*TOP + CLOCK (assuming
C = 1). Alternatively, a receiver may convert 65536*TOP + CLOCK into
milliseconds (assuming C = 1) and add it to TIME. The downbeat (D
header bit) semantics defined in Appendix B.3 apply to the checkpoint history for corrected
song position.

B.4. System Chapter F: MIDI Time Code Tape Position

This appendix describes Chapter F, the command associated with system chapter for the log.

As defined by MIDI
Time Code (MTC) commands. Readers may wish to review the preceding text in Appendix
A.1 definition of "finished/unfinished commands" before reading this section, by default all
finished
appendix.

The system journal MUST contain Chapter F if an active System Common
Quarter Frame command (0xF1) or unfinished an active SysEx commands that appear in the
checkpoint history (excluding finished System Exclusive
(Universal Real Time) MTC Full Frame commands) command (F0 7F cc 01 01 hr mn sc
fr F7) appears in the checkpoint history. Otherwise, the system
journal MUST be
protected by NOT contain Chapter F.

Figure B.4.1 shows the list tool or variable-length format for Chapter F.

0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S|C|P|Q|D|POINT| COMPLETE ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | PARTIAL ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+

Figure B.4.1 -- System Chapter F format
Chapter F holds information about recent MTC tape positions coded in
the recency tool.

For some MIDI source streams, this default yields a session history. Receivers use Chapter X whose size
is too large. For example, imagine that a sender begins F to transcode re-synchronize the
MTC system after a
SysEx command with 10,000 data octets onto packet loss episode.

Chapter F consists of a UDP RTP stream "on the
fly", by sending SysEx command segments as soon as data octets are
delivered 1-octet header followed by several optional
fields, in the MIDI source. After 1000 octets have been sent, the
expansion of Chapter X yields an RTP packet that is too large to fit order shown in
the Maximum Transmission Unit (MTU) for the stream.

In this situation, if Figure B.4.1. The C and P header bits
form a sender uses Table of Contents (TOC) and signal the closed-loop sending policy for
SysEx commands, presence of the RTP packet size may always be capped by stalling 32-bit
COMPLETE field (C = 1) and the
stream. In a stream stall, once 32-bit PARTIAL field (P = 1).

The Q header bit codes information about the packet reaches COMPLETE field format.
If Chapter F does not contain a maximum size, the
sender refrains from sending new packets with non-empty MIDI Command
Sections until receiver feedback permits COMPLETE field, Q MUST be set to 0.

The D header bit codes the trimming of Chapter X. tape movement direction. If the stream permits arbitrary commands tape is
moving forward, or if the tape direction is indeterminate, the D bit
MUST be set to appear between SysEx segments
(selectable during configuration using 0. If the tools defined tape is moving in Appendix
C.1), the sender may stall reverse direction,
the SysEx segment stream but continue D bit MUST be set to code
other 1. In most cases, the ordering of commands
in the MIDI list.

Stalls are a workable but sub-optimal solution to Chapter X size issues.
As an alternative to stalls, senders SHOULD take preemptive action
during session configuration to reduce the anticipated size of Chapter
X, using history clearly defines the methods described below:

o Partitioned transport. Appendix C.5 provides tools
for sending a MIDI name space over several RTP streams.
Senders may use these tools to map a MIDI source
into tape direction. However,
a low-latency UDP RTP stream (for channel commands
and short SysEx commands) and few command sequences have an indeterminate direction (such as a reliable [CONTRANS] TCP stream
(for bulk-data SysEx commands). The cm_unused and
cm_used parameters (Appendix C.1) may be used to
communicate the nature
session history consisting of the SysEx command partition.
As TCP one Full Frame command).

The 3-bit POINT header field is reliable, the RTP MIDI TCP stream would not
use the recovery journal. To minimize transmission
latency for short SysEx commands, senders may begin
segmental transmission for all SysEx commands over interpreted as an unsigned integer.
Appendix B.4.1 defines how the
UDP stream, and then cancel POINT field codes information about
the UDP transmission contents of long
commands (using tools described in Section 3.2) and
resend the commands over the TCP stream.

o Selective protection. Journal protection may PARTIAL field. If Chapter F does not be
necessary for all SysEx commands in contain a stream. The
ch_never parameter (Appendix C.2) may
PARTIAL field, POINT MUST be used to
communicate which SysEx commands are excluded from
Chapter X.

B.5.3 TCOUNT and COUNT fields

If the T header bit is set to 1, 7 (if D = 0) or 0 (if D = 1).

Chapter F MUST include the 8-bit TCOUNT COMPLETE field if an active finished Full
Frame command appears in the checkpoint history, or if an active
Quarter Frame command log. If the C header bit is set to 1, that completes the 8-bit COUNT field encoding of a frame value
appears in the command log. TCOUNT and COUNT are interpreted as
unsigned integers. checkpoint history.

The TCOUNT COMPLETE field codes the total number of SysEx commands of the SysEx
type coded by encodes the log most recent active complete MTC frame
value that appear appears in the session history, at the moment
after the (finished or unfinished) command coded by the log enters the
session history.

The COUNT field codes This frame value may take
the total number form of SysEx commands that appear in
the session history, excluding a series of 8 active Quarter Frame commands that are excluded from Chapter X
via the ch_never parameter (Appendix C.2), at the moment after the
(finished (0xF1 0x0n
through 0xF1 0x7n for forward tape movement, 0xF1 0x7n through 0xF1
0x0n for reverse tape movement) or unfinished) command coded by the log enters may take the session

history.

Command counting for TCOUNT and COUNT uses modulo-256 arithmetic. MTC form of an active
finished Full Frame command instances (Appendix B.4) are included in command
counting if command.

If the TCOUNT and COUNT definitions warrant their inclusion, as
are cancelled commands (Section 3.2).

Senders use COMPLETE field encodes a Quarter Frame command series, the TCOUNT and COUNT fields Q
header bit MUST be set to track the identity 1, and (for
TCOUNT) the sequence position of a command instance. Senders COMPLETE field MUST use have the TCOUNT or COUNT
format shown in Figure B.4.2. The 4-bit fields if identity or sequence information is
necessary to protect MT0 through MT7 code
the command type coded by data (lower) nibble for the log.

If Quarter Frame commands for Message
Type 0 through Message Type 7 [MIDI]. These nibbles encode a sender uses the COUNT field
complete frame value, in a session, addition to fields reserved for future use
by [MIDI].

0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MT0 | MT1 | MT2 | MT3 | MT4 | MT5 | MT6 | MT7 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure B.4.2 -- COMPLETE field format, Q = 1

In this usage, the final command log in
every Chapter X frame value encoded in the stream COMPLETE field MUST code be
offset by 2 frames (relative to the COUNT field. This rule lets
receivers resynchronize frame value encoded in the COUNT
Quarter Frame commands) if the frame value after codes a packet loss.

C. Session Configuration Tools

In Sections 6.1-2 0xF1 0x0n through
0xF1 0x7n command sequence. This offset compensates for the two-
frame latency of the main text, we show session descriptions Quarter Frame encoding for
minimal native and mpeg4-generic RTP MIDI streams. Minimal streams lack forward tape
movement. No offset is applied if the flexibility to support some applications. frame value codes a 0xF1 0x7n
through 0xF1 0x0n Quarter Frame command sequence.

The most recent active complete MTC frame value may alternatively be
encoded by an active finished Full Frame command. In this Appendix, we
describe how to customize stream behavior through case, the use of
Q header bit MUST be set to 0, and the payload COMPLETE field MUST have
format parameters. shown in Figure B.4.3. The Appendix begins with 6 sections, each devoted HR, MN, SC, and FR fields
correspond to parameters that
affect a particular aspect of stream behavior:

o Appendix C.1 describes the stream subsetting system
(cm_unused hr, mn, sc, and cm_used).

o Appendix C.2 describes the journalling system (ch_anchor,
ch_default, ch_never, j_sec, j_update).

o Appendix C.3 describes MIDI command timestamp semantics
(linerate, mperiod, octpos, tsmode).

o Appendix C.4 describes the temporal duration ("media time") fr data octets of an RTP MIDI packet (guardtime, rtp_maxptime, rtp_ptime).

o Appendix C.5 concerns stream description (musicport).

o Appendix C.6 describes MIDI rendering (chanmask, cid,
inline, multimode, render, rinit, subrender, smf_cid,
smf_info, smf_inline, smf_url, url). the Full Frame
command.

0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HR | MN | SC | FR |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure B.4.3 -- COMPLETE field format, Q = 0

B.4.1. Partial Frames

The parameters listed above may optionally appear in most recent active session
descriptions history command that encodes MTC frame
value data may be a Quarter Frame command other than a forward-moving
0xF1 0x7n command (which completes a frame value for forward tape
movement) or a reverse-moving 0xF1 0x1n command (which completes a
frame value for reverse tape movement).

We consider this type of RTP MIDI streams. If these parameters are used in an
SDP session description, the parameters appear on an fmtp attribute
line. This attribute line applies Quarter Frame command to the payload type be associated with
the fmtp line.
a partial frame value. The parameters listed above add extra functionality ("features") to
minimal RTP MIDI streams. In Appendix C.7, we show how to use these
features Quarter Frame sequence that defines a
partial frame value MUST either start at Message Type 0 and increment
contiguously to support two classes of applications: content-streaming using
RTSP (Appendix C.7.1) an intermediate Message Type less than 7, or start at
Message Type 7 and network musical performance using SIP
(Appendix C.7.2).

The participants in decrement contiguously to an intermediate Message
type greater than 0. A Quarter Frame command sequence that does not
follow this pattern is not associated with a multimedia session partial frame value.

Chapter F MUST share include a common view of all
of PARTIAL field if the RTP MIDI streams that appear most recent active
command in an RTP session, as defined by a
single media (m=) line. In some RTP MIDI applications, the "common
view" restriction makes it difficult to use sendrecv streams (all
parties send and receive), as each party has its own requirements. For
example, checkpoint history that encodes MTC frame value data
is a two-party network musical performance application may wish to
customize the renderer on each host to match the CPU performance Quarter Frame command that is associated with a partial frame
value. Otherwise, Chapter F MUST NOT include a PARTIAL field.

The partial frame value consists of the

host [NMP].

We solve this problem by using two RTP MIDI streams -- one sendonly, one
recvonly -- in lieu data (lower) nibbles of one sendrecv stream. the
Quarter Frame command sequence. The data flows in PARTIAL field codes the two
streams travel partial
frame value, using the format shown in opposite directions, to control receivers configured
to use different renderers. In the third example in Appendix C.5, we
show how the musicport parameter may be used to define virtual sendrecv
streams.

As a general rule, the RTP MIDI protocol does not handle parameter
changes during a session well, because the parameters describe
heavyweight or stateful configuration Figure B.4.2. Message Type
fields that are not easily changed once a
session has begun. Thus, parties SHOULD NOT expect that parameter
change requests during associated with a session will Quarter Frame command MUST be accepted by other parties.
However, implementors SHOULD support in-session parameter changes that
are easy
set to handle (example: 0.

The POINT header field indicates the guardtime parameter defined in Appendix
C.4), and SHOULD be capable of accepting requests for changes of those
parameters, as received by its session management protocol (for example,
re-offers Message Type fields in SIP [RFC3264]).

Appendix D defines the Augmented Backus-Naur Form (ABNF, [RFC2234])
syntax for the payload parameters. Appendix H provides information to
PARTIAL field code valid data. If P = 1, the Internet Assigned Numbers Authority (IANA) on POINT field MUST encode
the media types and
parameters defined in this document.

Appendix C.6.5 defines unsigned integer value formed by the media type "audio/asc", a stored object for
initializing mpeg4-generic renderers. As described in Appendix C.6, lower 3 bits of the
audio/asc media type is assigned to upper
nibble of the "rinit" parameter to specify an
initialization data object for value of the default mpeg4-generic renderer. Note
that RTP stream semantics are not defined for "audio/asc". Therefore, most recent active Quarter Frame
command in the "asc" subtype session history. If D = 0 and P = 1, POINT MUST NOT appear take
on the rtpmap line of a session
description.

C.1 Configuration Tools: Stream Subsetting

As defined in Section 3.2 value in the main text, the MIDI list of an RTP MIDI
packet may encode any MIDI command that may legally appear range 0-6. If D = 1 and P = 1, POINT MUST take on
a MIDI 1.0
DIN cable.

In this Appendix we define two parameters (cm_unused and cm_used) that
modify this default condition, by excluding certain types of MIDI
commands from value in the MIDI list of all packets range 1-7.

If D = 0, MT fields (Figure B.4.2) in a stream. For example, if
a multimedia session partitions a MIDI name space into two RTP MIDI
streams, the parameters may be used inclusive range from 0 up
to define which commands appear in
each stream.

In this Appendix, we define a simple language for specifying MIDI

command types. and including the POINT value encode the partial frame value. If a command type is assigned
D = 1, MT fields in the inclusive range from 7 down to cm_unused, and including
the commands
coded by POINT value encode the string partial frame value. Note that, unlike
the COMPLETE field encoding, senders MUST NOT appear in the MIDI list. If add a command type
is assigned 2-frame offset to cm_used, the commands coded by
the string MAY appear partial frame value encoded in PARTIAL.

For the MIDI list.

The parameter list may code multiple assignments to cm_used and
cm_unused. Assignments have default semantics, if a cumulative effect, recovery journal contains Chapter F,
and are applied in if the
order session history codes a legal [MIDI] series of appearance in Quarter
Frame and Full Frame commands, the parameter list. A later assignment of chapter always contains a
command type to the same parameter expands the scope of COMPLETE
or a PARTIAL field (and may contain both fields). Thus, a one-octet
Chapter F (C = P = 0) always codes the earlier
assignment. A later assignment presence of a an illegal command type to
sequence in the opposite
parameter cancels (partially or completely) session history (under some conditions, the effect C = 1,
P = 0 condition may also code the presence of an earlier
assignment.

To initialize the stream subsetting system, "implicit" assignments to
cm_unused and cm_used illegal command
sequence). The illegal command sequence conditions are processed before processing the actual
assignments that appear transient in the parameter list. The System Common
undefined commands (0xF4, 0xF5)
nature and usually indicate that a Quarter Frame command sequence
began with an intermediate Message Type.

B.5. System Chapter X: System Exclusive

This appendix describes Chapter X, the system chapter for MIDI System Real-Time Undefined
Exclusive (SysEx) commands (0xF9, 0xFD) are implicitly assigned (0xF0). Readers may wish to cm_unused. All other review the
Appendix A.1 definition of "finished/unfinished commands" before
reading this appendix.

Chapter X consists of a list of one or more command logs. Each log
in the list codes information about a specific finished or unfinished
SysEx command types are implicitly assigned to cm_used.

Note that appears in the implicit assignments code session history. The system
journal MUST contain Chapter X if the default behavior of an RTP
MIDI stream as rules defined in Section 3.2 in the main text (namely, that all
commands Appendix B.5.2
require that may legally appear on a MIDI 1.0 DIN cable may one or more logs appear in the stream). Also note that assignments list.

The log list is not preceded by a header. Instead, each log
implicitly encodes its own length. Given the length of the System Common undefined
commands (0xF4, 0xF5) apply to N'th list
log, the use presence of these commands in the MIDI
source command stream, not (N+1)'th list log may be inferred from the special use
LENGTH field of 0xF4 and 0xF5 in SysEx
segment encoding defined the system journal header (Figure 10 in Section 3.2 in 5 of
the main text.

As a rule, parameter assignments text). The log list MUST obey the following syntax (see oldest-first ordering
rule (defined in Appendix
D for ABNF):

<parameter> = [channel list]<command-type list>[field list]

The command-type list is mandatory; A.1).

B.5.1. Chapter Format

Figure B.5.1 shows the channel and field lists are
optional.

The command-type list specifies bitfield format for the MIDI Chapter X command types for which log.

0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S|T|C|F|D|L|STA| TCOUNT | COUNT | FIRST ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DATA ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure B.5.1 -- Chapter X command log format

A Chapter X command log consists of a 1-octet header, followed by the
parameter applies.
optional TCOUNT, COUNT, FIRST, and DATA fields.

The command-type list is T, C, F, and D header bits act as a concatenated sequence of
one or more Table of Contents (TOC) for
the letters (ABCFGHJKMNPQTVWXYZ). The letters code the
following command types:

o A: Poly Aftertouch (0xA)
o B: System Reset (0xFF)
o C: Control Change (0xB)
o F: System Time Code (0xF1)
o G: System Tune Request (0xF6)
o H: System Song Select (0xF3)
o J: System Common Undefined (0xF4)
o K: System Common Undefined (0xF5)
o N: NoteOff (0x8), NoteOn (0x9)
o P: Program Change (0xC)
o Q: System Sequencer (0xF2, 0xF8, 0xF9, 0xFA, 0xFB, 0xFC)
o T: Channel Aftertouch (0xD)
o V: System Active Sense (0xFE)
o W: Pitch Wheel (0xE)
o X: SysEx (0xF0)
o Y: System Real-Time Undefined (0xF9)
o Z: System Real-Time Undefined (0xFD)

In addition log. If T is set to 1, the letters above, the letter M may also appear 1-octet TCOUNT field appears in the
command-type list. The letter M refers
log. If C is set to 1, the MIDI parameter system
(see definition in Appendix A.1 and 1-octet COUNT field appears in [MIDI]). An assignment of M the log.
If F is set to
cm_unused codes that no RPN or NRPN transactions may appear 1, the variable-length FIRST field appears in the MIDI
list.

Note that if cm_unused log.
If D is assigned set to 1, the letter M, Control Change (0xB)
commands variable-length DATA field appears in the log.

The L header bit sets the coding tool for the controller numbers in log. We define the standard controller
assignment might still appear log
coding tools in Appendix B.5.2.

The STA field codes the MIDI list. For status of the command coded by the log. The
2-bit STA value is interpreted as an explanation, see
Appendix A.3.4 for unsigned integer. If STA is 0,
the log codes an unfinished command. Non-zero STA values code
different classes of finished commands. An STA value of 1 codes a discussion
cancelled command, an STA value of 2 codes a command that uses the "general-purpose" use
"dropped F7" construction, and an STA value of
parameter system controller numbers.

In 3 codes all other
finished commands. Section 3.2 in the main text below, rules that apply to "MIDI voice channel commands"
also apply to letter M. describes cancelled
and "dropped F7" commands.

The letters in S bit (Appendix A.1) of the command-type list MUST be upper case, and MUST appear
in alphabetical order. Letters other than (ABCFGHJKMNPQTVWXYZ) that
appear first log in the list MUST be ignored.

For MIDI voice channel commands, the channel list specifies acts as the MIDI
channels S
bit for which Chapter X. For the parameter applies. If no channel list is
provided, other logs in the parameter applies list, the S bit refers
to all MIDI channels (0-15). The
channel list takes the form of a list log itself. The value of channel numbers (0 through 15)
and dash-separated channel number ranges (i.e. 0-5, 8-12, etc). Dots
(i.e. "." characters) separate elements in the channel list.

Recall that System commands do not have a MIDI channel "phantom" S bit associated with
them. Thus, for most command-type letters that code System commands (B,
F, G, H, J, K, Q, V, Y and Z),
the channel list first log is ignored.

For the command-type letter X, defined by the appearance of certain numbers in following rules:

o If the
channel list codes special semantics. one log, the phantom S-bit value is the same
as the Chapter X S-bit value.

o The digit 0 If the list codes that SysEx "cancel" sublists (Section
3.2 in the main text) MUST NOT appear in the MIDI list.

o The digit 1 codes that cancel sublists MAY appear in the
MIDI list (the default condition).

o The digit 2 codes that commands other than System
Real-time MIDI commands MUST NOT appear between SysEx
command segments in the MIDI list (the default condition).

o The digit 3 codes that any MIDI command type may
appear between SysEx command segments in multiple logs, the MIDI list,
with phantom S-bit value is the exception
logical OR of the segmented encoding S-bit value of a the first and second
SysEx command (verbatim SysEx commands are OK).

For command-type X,
logs in the channel list MUST NOT contain both digits 0 and
1, and MUST NOT contain both digits 2 and 3. For command-type X,
channel list numbers list.

In all other than respects, the numbers defined above are ignored.
If X does not have a channel list, S bit follows the semantics marked "the default
condition" defined in the list above apply.
Appendix A.1.

The syntax for FIRST field lists in (present if F = 1) encodes a parameter assignment follows the syntax
for channel lists. If no field list is provided, variable-length unsigned
integer value that sets the parameter applies
to all controller or note numbers.

For command-type C (Control Change), coverage of the DATA field.

The FIRST field list codes the controller
numbers (0-255) for (present if F = 1) encodes a variable-length unsigned
integer value that specifies which SysEx data bytes are encoded in
the parameter applies.

For command-type M (Parameter System), the DATA field list codes the
Registered Parameter Numbers (RPNs) and Non-Registered Parameter Numbers
(NRPNs) for which of the parameter applies. log. The number range 0-16383
specifies RPNs, the number range 16384-32767 specifies NRPNs (16384
corresponds FIRST field consists of an octet
whose most-significant bit is set to NRPN 0, 32767 corresponds optionally preceded by one or
more octets whose most-significant bit is set to NRPN 16383).

For command-types N (NoteOn and NoteOff) and A (Poly Aftertouch), the
field list codes the note numbers for which 1. The algorithm
shown in Figure B.5.2 decodes this format into an unsigned integer,
to yield the parameter applies.

For command-types J value dec(FIRST). FIRST uses a variable-length encoding
because dec(FIRST) references a data octet in a SysEx command, and K (System Common Undefined), the field list
consists of a single digit, which specifies the
SysEx command may contain an arbitrary number of data octets.

One-Octet FIRST value:

Encoded form: 0ddddddd
Decoded form: 00000000 00000000 00000000 0ddddddd

Two-Octet FIRST value:

Encoded form: 1ccccccc 0ddddddd
Decoded form: 00000000 00000000 00cccccc cddddddd

Three-Octet FIRST value:

Encoded form: 1bbbbbbb 1ccccccc 0ddddddd
Decoded form: 00000000 000bbbbb bbcccccc cddddddd

Four-Octet FIRST value:

Encoded form: 1aaaaaaa 1bbbbbbb 1ccccccc 0ddddddd
Decoded form: 0000aaaa aaabbbbb bbcccccc cddddddd

Figure B.5.2 -- Decoding FIRST field formats
The DATA field (present if D = 1) encodes a modified version of the
data octets
that follow of the SysEx command octet.

For command-type X (SysEx), coded by the log. Status octets
MUST NOT be coded in the DATA field.

If F = 0, the DATA field list codes begins with the number first data octet of the
SysEx command and includes all subsequent data octets for the command
that may appear in a SysEx command. Thus, the session history. If F = 1, the DATA field list 0-255
specifies SysEx commands begins
with 255 or fewer the (dec(FIRST) + 1)'th data octets, octet of the field list
256-429496729 specifies SysEx commands with more than 255 data octets
but excludes commands with 255 or fewer data octets, command and the field list
0 excludes
includes all commands.

A secondary parameter assignment syntax customizes command-type X (see
Appendix D subsequent data octets for complete ABNF):

<parameter> = "__" <h-list> ["_" <h-list>] "__"

The assignment defines the class of SysEx commands command that obeys the
semantics of appear in
the assigned parameter. The command class is specified by
listing session history. Note that the permitted values of word "command" in the first N data octets that follow
descriptions above refers to the original SysEx 0xF0 command octet. Any as it appears
in the source MIDI data stream, not to a particular MIDI list SysEx
command whose first N data octets
match segment.

The length of the list DATA field is a member coded implicitly, using the most-
significant bit of each octet. The most-significant bit of the class.

Each <h-list> defines a data final
octet of the command, as a dot-separated
(".") list DATA field MUST be set to 1. The most-significant bit
of one or more hexadecimal constants (such as "7F") or dash-
separated hexadecimal ranges (such as "01-1F"). Underscores ("_")
separate each <h-list>. Double-underscores ("__") delineate all other DATA octets MUST be set to 0. This coding method relies
on the fact that the most-significant bit of a MIDI data octet list.

Using is 0
by definition. Apart from this syntax, each assignment specifies length-coding modification, the DATA
field encodes a single SysEx command
class. Session descriptions may use several assignments verbatim copy of all data octets it encodes.

B.5.2. Log Inclusion Semantics

Chapter X offers two tools to cm_used protect SysEx commands: the "recency"
tool and
cm_unused to specify complex behaviors.

The example session description below illustrates the "list" tool. The tool definitions use of the stream
subsetting parameters:

The session description configures concept of
the stream for use "SysEx type" of a command, which we now define.

Each SysEx command instance in clock
applications. All voice channels are unused, as are all System Commands
except those used for MIDI Time Code (command-type F, and the a session, excepting MTC Full Frame
SysEx command that
commands, is matched by the string assigned said to cm_used), the
System Sequencer have a "SysEx type". Types are used in equality
comparisons: two SysEx commands (command-type Q), and System Reset (command-
type B).

C.2 Configuration Tools: The Journalling System

In this Appendix, we define in a session are said to have "the
same SysEx type" or "different SysEx types".

If efficiency is not a concern, a sender may follow a simple typing
rule: every SysEx command in the payload format parameters that configure
stream journalling session history has a different
SysEx type, and thus no two commands in the recovery journal system.

The j_sec parameter (Appendix C.2.1) sets the journalling method for session have the
stream. The j_update parameter (Appendix C.2.2) same
type.

To improve efficiency, senders MAY implement exceptions to this rule.
These exceptions declare that certain sets of SysEx command instances
have the recovery
journal sending policy for the stream. Appendix C.2.2 also defines same SysEx type. Any command not covered by an exception
follows the
sending policies simple rule. We list exceptions below:

o All commands with identical data octet fields (same number of
data octets, same value for each data octet) have the recovery journal system.

Appendix C.2.3 defines several parameters same type.
This rule MUST be applied to all SysEx commands in the session,
or not at all. Note that modify the recovery
journal semantics. These parameters change implementation of this exception
requires no sender knowledge of the default recovery journal format and semantics as defined of the
SysEx commands in Section 5 the stream, merely the ability to count and Appendices A-B.

The journalling method for a stream is
compare octets.

o Two instances of the same command whose semantics set at or report
the start value of a session and
MUST NOT be changed thereafter. This requirement forbids changes to the
j_sec parameter once a session has begun.

A related requirement, defined in the Appendix sections below, forbids same "parameter" have the acceptance same type. The
implementation of this exception requires specific knowledge of parameter values that would violate
the recovery
journal mandate. format and semantics of SysEx commands. In many cases, practice, a change in one
sender implementation chooses to support this exception for
certain classes of commands (such as the parameters Universal System
Exclusive commands defined in [MIDI]). If a sender supports
this Appendix during an on-going session would result exception for a particular command in a
violation of class (for example,
the recovery journal mandate Universal Real Time System Exclusive message for an implementation; Master
Volume, F0 F7 cc 04 01 vv vv F7, defined in this
case, the parameter change [MIDI]), it MUST NOT be accepted.

C.2.1 The j_sec Parameter

Section 2.2 defines
support the default journalling method for a stream.
Streams that use unreliable transport (such as UDP) default exception to using all instances of this particular
command in the
recovery journal. Streams that session.

We now use reliable transport (such as TCP)
default to not using a journal.

The parameter j_sec may be used to override this default. This memo
defines two symbolic values definition of "SysEx type" to define the "recency"
tool and the "list" tool for j_sec: "none", Chapter X.

By default, the Chapter X log list MUST code sufficient information
to indicate that protect the rendered MIDI performance from indefinite artifacts
caused by the loss of all
stream payloads finished or unfinished active SysEx
commands that appear in the checkpoint history (excluding finished
MTC Full Frame commands, which are coded in Chapter F (Appendix
B.4)).

To protect a command of a specific SysEx type with the recency tool,
senders MUST NOT contain code a journal section, and "recj", to
indicate log in the log list for the most recent finished
active instance of the SysEx type that all stream payloads appears in the checkpoint
history. Additionally, if an unfinished active instance of the SysEx
type appears in the checkpoint history, senders MUST contain code a journal section that
uses log in
the recovery journal format.

For example, log list for the j_sec parameter might unfinished command instance. The L header bit
of both command logs MUST be set to "none" for 0.

To protect a UDP stream
that travels between two hosts on a local network that is known to
provide reliable datagram delivery.

The session description below configures command of a UDP stream that does not use specific SysEx type with the recovery journal:

v=0
o=lazzaro 2520644554 2838152170 IN IP4 first.example.net
s=Example
t=0 0
m=audio 5004 RTP/AVP 96
c=IN IP4 192.0.2.94
a=rtpmap:96 rtp-midi/44100
a=fmtp:96 j_sec=none

Other IETF standards-track documents may define alternative journal
formats. These documents list tool,
senders MUST define new symbolic values code a log in the Chapter X log list for each finished
or unfinished active instance of the j_sec
parameter to signal SysEx type that appears in the use
checkpoint history. The L header bit of list tool command logs MUST
be set to 1.

As a rule, a log REQUIRED by the format.

Parties list or recency tool MUST NOT accept include a j_sec value
DATA field that violates codes all data octets that appear in the recovery journal
mandate (see Section 4 checkpoint
history for details). If a session description uses the SysEx command instance associated with the log. The
FIRST field MAY be used to configure a

j_sec value unknown DATA field that minimally
meets this requirement.

An exception to this rule applies to cancelled commands (defined in
Section 3.2). REQUIRED command logs associated with cancelled
commands MAY be coded with no DATA field. However, if DATA appears
in the recipient, the recipient log, DATA MUST NOT accept code all data octets that appear in the
description.

Special j_sec issues arise when sessions are managed
checkpoint history for the command associated with the log.

As defined by session
management tools (like RTSP, [RFC2326]) the preceding text in this section, by default all
finished or unfinished active SysEx commands that use SDP for "declarative
usage" purposes (see appear in the preamble of Section 6 for details).
checkpoint history (excluding finished MTC Full Frame commands) MUST
be protected by the list tool or the recency tool.

For these
session management tools, SDP does not code transport details (such as some MIDI source streams, this default yields a Chapter X whose
size is too large. For example, imagine that a sender begins to
transcode a SysEx command with 10,000 data octets onto a UDP or TCP) for RTP
stream "on the session. Instead, server and client negotiate
transport details via other means (for RTSP, fly", by sending SysEx command segments as soon as
data octets are delivered by the SETUP method). MIDI source. After 1000 octets have
been sent, the expansion of Chapter X yields an RTP packet that is
too large to fit in the Maximum Transmission Unit (MTU) for the
stream.

In this scenario, situation, if a sender uses the use of closed-loop sending policy
for SysEx commands, the j_sec parameter RTP packet size may always be ill-advised, as
the creator of capped by
stalling the session description may not yet know stream. In a stream stall, once the transport
type for packet reaches a
maximum size, the session. In this case, sender refrains from sending new packets with non-
empty MIDI Command Sections until receiver feedback permits the session description SHOULD
configure
trimming of Chapter X. If the journalling system stream permits arbitrary commands to
appear between SysEx segments (selectable during configuration using
the parameters tools defined in the
remainder of Appendix C.2, C.1), the sender may stall the SysEx
segment stream but SHOULD NOT use j_sec continue to set the
journalling status. Recall that if j_sec does not appear code other commands in the MIDI list.

Stalls are a workable but sub-optimal solution to Chapter X size
issues. As an alternative to stalls, senders SHOULD take preemptive
action during session
description, configuration to reduce the default method for choosing anticipated size of
Chapter X, using the journalling method is
in effect (no journal methods described below:

o Partitioned transport. Appendix C.5 provides tools for sending
a MIDI name space over several RTP streams. Senders may use
these tools to map a MIDI source into a low-latency UDP RTP
stream (for channel commands and short SysEx commands) and a
reliable transport, recovery journal for
unreliable transport).

However, in declarative usage situations where [RFC4571] TCP stream (for bulk-data SysEx commands).
The cm_unused and cm_used parameters (Appendix C.1) may be used
to communicate the creator nature of the
session description knows journalling SysEx command partition. As
TCP is always required or never
required, the session description SHOULD use reliable, the j_sec parameter.

C.2.2 The j_update Parameter

In Section 4, we RTP MIDI TCP stream would not use the term "sending policy" to describe the method a
sender uses to choose the checkpoint packet identity for each
recovery
journal in a stream. In journal. To minimize transmission latency for short
SysEx commands, senders may begin segmental transmission for all
SysEx commands over the sub-sections that follow, we normatively
define three sending policies: anchor, closed-loop, UDP stream and open-loop.

As stated then cancel the UDP
transmission of long commands (using tools described in Section 4,
3.2) and resend the default sending policy commands over the TCP stream.

o Selective protection. Journal protection may not be necessary
for all SysEx commands in a stream is the
closed-loop policy. stream. The j_update ch_never parameter
(Appendix C.2) may be used to override this
default.

We define three symbolic values for j_update: "anchor", communicate which SysEx commands
are excluded from Chapter X.

B.5.3. TCOUNT and COUNT Fields

If the T header bit is set to indicate that 1, the stream uses 8-bit TCOUNT field appears in
the anchor sending policy, "open-loop", command log. If the C header bit is set to indicate that 1, the stream uses 8-bit COUNT
field appears in the open-loop sending policy, command log. TCOUNT and "closed-loop", to
indicate that COUNT are interpreted
as unsigned integers.

The TCOUNT field codes the stream uses total number of SysEx commands of the closed-loop sending policy. See
Appendix C.2.3 for examples session descriptions that use
SysEx type coded by the j_update
parameter.

Parties MUST NOT accept a j_update value log that violates appear in the recovery
journal mandate (Section 4).

Other IETF standards-track documents may define additional sending
policies for session history, at
the recovery journal system. These documents MUST define
new symbolic values for moment after the j_update parameter to signal (finished or unfinished) command coded by the use of
log enters the

new policy. If a session description uses a j_update value unknown to history.

The COUNT field codes the recipient, total number of SysEx commands that appear
in the recipient MUST NOT accept session history, excluding commands that are excluded from
Chapter X via the description.

C.2.2.1 The anchor Sending Policy

In ch_never parameter (Appendix C.2), at the anchor policy, moment
after the sender uses the first packet in (finished or unfinished) command coded by the stream as log enters
the checkpoint packet session history.

Command counting for all packets TCOUNT and COUNT uses modulo-256 arithmetic.
MTC Full Frame command instances (Appendix B.4) are included in
command counting if the stream. The anchor policy
satisfies the recovery journal mandate (Section 4), TCOUNT and COUNT definitions warrant their
inclusion, as are cancelled commands (Section 3.2).

Senders use the checkpoint
history always covers TCOUNT and COUNT fields to track the entire stream.

The anchor policy does not require identity and
(for TCOUNT) the use sequence position of a command instance. Senders
MUST use the RTP control protocol
(RTCP, [RFC3550]) TCOUNT or other feedback from receiver to sender. Senders do
not need to take special actions COUNT fields if identity or sequence
information is necessary to ensure that received streams start
up free of artifacts, as protect the recovery journal always covers command type coded by the entire
history of
log.

If a sender uses the stream. Receivers are relieved of COUNT field in a session, the responsibility of
tracking final command log
in every Chapter X in the changing identity of stream MUST code the checkpoint packet, because COUNT field. This
rule lets receivers resynchronize the
checkpoint COUNT value after a packet never changes.

The main drawback
loss.

C. Session Configuration Tools

In Sections 6.1-2 of the anchor policy is bandwidth efficiency. Because
the checkpoint history covers the entire stream, the size of main text, we show session descriptions for
minimal native and mpeg4-generic RTP MIDI streams. Minimal streams
lack the
recovery journals produced by flexibility to support some applications. In this policy usually exceeds appendix,
we describe how to customize stream behavior through the journal
size use of alternative policies. For single-channel MIDI data streams, the
bandwidth overhead
payload format parameters.

The appendix begins with 6 sections, each devoted to parameters that
affect a particular aspect of stream behavior:

o Appendix C.1 describes the anchor policy is often acceptable (see stream subsetting system (cm_unused
and cm_used).

o Appendix A.4 of [NMP]). For dense streams, C.2 describes the closed-loop or open-loop
policies may be more appropriate.

C.2.2.2 The closed-loop Sending Policy

The closed-loop policy is journalling system (ch_anchor,
ch_default, ch_never, j_sec, j_update).

o Appendix C.3 describes MIDI command timestamp semantics
(linerate, mperiod, octpos, tsmode).

o Appendix C.4 describes the default policy temporal duration ("media time") of the recovery journal
system. For each
an RTP MIDI packet (guardtime, rtp_maxptime, rtp_ptime).

o Appendix C.5 concerns stream description (musicport).

o Appendix C.6 describes MIDI rendering (chanmask, cid, inline,
multimode, render, rinit, subrender, smf_cid, smf_info,
smf_inline, smf_url, url).

The parameters listed above may optionally appear in the stream, the policy lets senders choose
the smallest possible checkpoint history that satisfies the recovery
journal mandate. As smaller checkpoint histories generally yield
smaller recovery journals, the closed-loop policy reduces the bandwidth session
descriptions of a stream, relative to RTP MIDI streams. If these parameters are used in an
SDP session description, the anchor policy.

The closed-loop policy relies parameters appear on feedback from receiver an fmtp attribute
line. This attribute line applies to sender. The
policy assumes that a receiver periodically informs the sender of the
highest sequence number it has seen so far in the stream, coded in payload type associated
with the
32-bit extension format defined in [RFC3550]. For RTCP, receivers
transmit this information in the Extended Highest Sequence Number
Received (EHSNR) field fmtp line.

The parameters listed above add extra functionality ("features") to
minimal RTP MIDI streams. In Appendix C.7, we show how to use these
features to support two classes of Receiver Reports. RTCP Sender or Receiver
Reports MUST be sent by any participant applications: content-streaming
using RTSP (Appendix C.7.1) and network musical performance using SIP
(Appendix C.7.2).

The participants in a multimedia session with closed loop
sending policy, unless another feedback mechanism MUST share a common view of
all of the RTP MIDI streams that appear in an RTP session, as defined
by a single media (m=) line. In some RTP MIDI applications, the
"common view" restriction makes it difficult to use sendrecv streams
(all parties send and receive), as each party has been agreed upon.

The sender its own
requirements. For example, a two-party network musical performance
application may safely use receiver sequence number feedback wish to guide
checkpoint history management, because Section 4 requires receivers customize the renderer on each host to
repair indefinite artifacts whenever a packet loss event occur.

We now normatively define match
the closed-loop policy. At CPU performance of the moment a
sender prepares an host [NMP].

We solve this problem by using two RTP packet for transmission, the sender is aware MIDI streams -- one sendonly,
one recvonly -- in lieu of R
>= 0 one sendrecv stream. The data flows in
the two streams travel in opposite directions, to control receivers for
configured to use different renderers. In the stream. Senders third example in
Appendix C.5, we show how the musicport parameter may become aware of be used to
define virtual sendrecv streams.

As a receiver
via RTCP traffic from general rule, the receiver, via RTP packets from MIDI protocol does not handle parameter
changes during a paired stream
sent by the receiver to session well, because the sender, via messages from parameters describe
heavyweight or stateful configuration that is not easily changed once
a session
management tool, or has begun. Thus, parties SHOULD NOT expect that parameter
change requests during a session will be accepted by other means. As receivers join and leave a
session, parties.
However, implementors SHOULD support in-session parameter changes
that are easy to handle (for example, the value guardtime parameter defined
in Appendix C.4) and SHOULD be capable of R changes.

Each known receiver k (1 <= k <= R) is associated with a 32-bit extended
packet sequence number M(k), where the extension reflects the sequence
number rollover count accepting requests for
changes of the sender.

If the sender has those parameters, as received at least one feedback report from receiver k,
M(k) is the most recent report of the highest RTP packet sequence number
seen by its session management
protocol (for example, re-offers in SIP [RFC3264]).

Appendix D defines the receiver, normalized Augmented Backus-Naur Form (ABNF, [RFC4234])
syntax for the payload parameters. Section 11 provides information
to reflect the rollover count of Internet Assigned Numbers Authority (IANA) on the
sender.

If media types
and parameters defined in this document.

Appendix C.6.5 defines the sender has not received media type "audio/asc", a feedback report from stored object
for initializing mpeg4-generic renderers. As described in Appendix
C.6, the receiver, M(k)
is the extended sequence number of audio/asc media type is assigned to the last packet "rinit" parameter to
specify an initialization data object for the sender
transmitted before it became aware of default mpeg4-generic
renderer. Note that RTP stream semantics are not defined for
"audio/asc". Therefore, the receiver. If "asc" subtype MUST NOT appear on the sender
became aware
rtpmap line of this receiver before it sent the first packet a session description.

C.1. Configuration Tools: Stream Subsetting

As defined in Section 3.2 in the
stream, M(k) is main text, the extended sequence number MIDI list of the first an RTP
MIDI packet in the
stream.

Given may encode any MIDI command that may legally appear on a
MIDI 1.0 DIN cable.

In this definition of M(), appendix, we now state the closed-loop policy. When
preparing a new packet for transmission, a sender MUST choose a
checkpoint packet with extended sequence number N, such define two parameters (cm_unused and cm_used)
that M(k) >= (N
- 1) for all k, 1 <= k <= R, where R >= 1. The policy does not restrict
sender behavior in the R == 0 (no known receivers) case.

Under modify this default condition, by excluding certain types of
MIDI commands from the closed-loop policy as defined above, a sender may transmit MIDI list of all packets whose checkpoint history is shorter than the session history (as
defined in Appendix A.1). In this event, a new receiver that joins the
stream may experience indefinite artifacts. stream. For
example, if a Control Change (0xB) command for Channel Volume
(controller number 7) was sent early in a stream, and later multimedia session partitions a new
receiver joins the session, MIDI name space into
two RTP MIDI streams, the closed-loop policy parameters may permit all
packets sent to the new receiver be used to use a checkpoint history that does
not include the Channel Volume Control Change command. As a result, the
new receiver experiences an indefinite artifact, and play all notes on a
channel too loudly or too softly.

To address define which
commands appear in each stream.

In this issue, the closed-loop policy states that whenever appendix, we define a
sender becomes aware of simple language for specifying MIDI
command types. If a new receiver, the sender MUST determine if the
receiver would be subject command type is assigned to indefinite artifacts under cm_unused, the closed-loop
policy. If so,
commands coded by the sender string MUST ensure that the receiver starts NOT appear in the
session free of indefinite artifacts. For example, MIDI list. If a
command type is assigned to solve cm_used, the Channel

Volume issue described above, commands coded by the sender string
MAY appear in the MIDI list.

The parameter list may code multiple assignments to cm_used and
cm_unused. Assignments have a cumulative effect and are applied in
the current state order of
the Channel Volume controller numbers appearance in the recovery journal Chapter C,
until it receives the first RTCP RR report that signals that parameter list. A later assignment of
a packet
containing this Chapter C has been received.

In satisfying this requirement, senders MAY infer command type to the initial MIDI state same parameter expands the scope of the receiver from earlier
assignment. A later assignment of a command type to the session description. For example, opposite
parameter cancels (partially or completely) the effect of an earlier
assignment.

To initialize the stream
example in Section 6.2 has subsetting system, "implicit" assignments to
cm_unused and cm_used are processed before processing the initial state defined in [MIDI] for
General MIDI.

In a unicast RTP session, a receiver may safely assume actual
assignments that the sender
is aware of its presence of a receiver from the first packet sent appear in the
RTP stream. However, in parameter list. The System Common
undefined commands (0xF4, 0xF5) and the System Real-Time Undefined
commands (0xF9, 0xFD) are implicitly assigned to cm_unused. All
other command types of RTP sessions (multicast,
conference focus, RTP translator/mixer), a receiver is often not able are implicitly assigned to
determine if cm_used.

Note that the sender is initially aware implicit assignments code the default behavior of its presence an
RTP MIDI stream as a
receiver.

To address this issue, defined in Section 3.2 in the closed-loop policy states main text (namely,
that all commands that if a receiver
participates in a session where it may have access to legally appear on a stream whose
sender is not aware of the receiver, the receiver MUST take actions to
ensure that its rendered MIDI performance does not contain indefinite
artifacts. These protections will be necessarily incomplete. For
example, a receiver 1.0 DIN cable may monitor the Checkpoint Packet Seqnum for
uncovered loss events, and "err on
appear in the side stream). Also note that assignments of caution" with respect to
handling stuck notes due to lost MIDI NoteOff commands, but the receiver
is not able System
Common undefined commands (0xF4, 0xF5) apply to compensate for the lack use of Channel Volume initialization
data in the recovery journal.

The receiver MUST NOT discontinue these protective actions until it is
certain that
commands in the sender is aware of its presence. If a receiver is MIDI source command stream, not
able to ascertain sender awareness, the receiver MUST continue these
protective actions for the duration special use of the session.

Note that in a multicast session where all parties are expected to send
0xF4 and receive, the reception of RTCP receiver reports from the sender
about 0xF5 in SysEx segment encoding defined in Section 3.2 in the RTP stream
main text.

As a receiver is multicasting is evidence of sender
awareness that the RTP stream multicast by rule, parameter assignments obey the sender following syntax (see
Appendix D for ABNF):

<parameter> = [channel list]<command-type list>[field list]

The command-type list is being monitored
by the receiver. Receivers may also obtain sender awareness evidence
from session management tools, or by other means. In practice, ongoing
observation of mandatory; the Checkpoint Packet Seqnum to determine if channel and field lists are
optional.

The command-type list specifies the sender
is taking actions to prevent loss events MIDI command types for a receiver which the
parameter applies. The command-type list is a good
indication concatenated sequence
of sender awareness, as is the sudden appearance one or more of recovery
journal chapters with numerous Control Change controller data that was
not foreshadowed by recent commands coded in the MIDI list shortly after
sending an RTCP RR. letters (ABCFGHJKMNPQTVWXYZ). The final set of normative closed-loop policy requirements concern how
senders and receivers handle unplanned disruptions of RTCP feedback from

a receiver to a sender. By "unplanned", we refer to disruptions that
are not due letters code
the following command types:

In addition to the signalled termination letters above, the letter M may also appear in the
command-type list. The letter M refers to the MIDI parameter system
(see definition in Appendix A.1 and in [MIDI]). An assignment of an RTP stream, via an RTCP
BYE M
to cm_unused codes that no RPN or via session management tools.

As defined earlier NRPN transactions may appear in this section, the closed-loop policy states that a
sender MUST choose a checkpoint packet with extended sequence number N,
such
MIDI list.

Note that M(k) >= (N - 1) for all k, 1 <= k <= R, where R >= 1. If the
sender has received at least one feedback report from receiver k, M(k) if cm_unused is assigned the most recent report of letter M, Control Change (0xB)
commands for the highest RTP packet sequence number seen
by controller numbers in the receiver, normalized to reflect standard controller
assignment might still appear in the rollover count MIDI list. For an explanation,
see Appendix A.3.4 for a discussion of the sender.

If this receiver k stops sending feedback "general-purpose" use of
parameter system controller numbers.

In the text below, rules that apply to "MIDI voice channel commands"
also apply to the sender, letter M.

The letters in the M(k) value
used by command-type list MUST be uppercase and MUST
appear in alphabetical order. Letters other than
(ABCFGHJKMNPQTVWXYZ) that appear in the sender reflects list MUST be ignored.

For MIDI voice channel commands, the last feedback report from channel list specifies the receiver.
As time progresses without feedback from receiver k, this fixed M(k)
value forces MIDI
channels for which the sender parameter applies. If no channel list is
provided, the parameter applies to increase all MIDI channels (0-15). The
channel list takes the size form of the checkpoint history,
and thus increases the bandwidth a list of the stream.

At some point, the sender may need to take action channel numbers (0 through
15) and dash-separated channel number ranges (i.e., 0-5, 8-12, etc).
Dots (i.e., "." characters) separate elements in order to limit the
bandwidth of the stream. In channel list.

Recall that System commands do not have a MIDI channel associated
with them. Thus, for most envisioned uses of RTP MIDI, long
before this point command-type letters that code System
commands (B, F, G, H, J, K, Q, V, Y, and Z), the channel list is reached,
ignored.

For the SSRC time-out mechanism defined in
[RFC3550] will remove command-type letter X, the uncooperative receiver from appearance of certain numbers in
the session (note channel list codes special semantics.

o The digit 0 codes that SysEx "cancel" sublists (Section 3.2 in
the closed-loop policy does not suggest or require any special
sender behavior upon an SSRC time-out, main text) MUST NOT appear in the MIDI list.

o The digit 1 codes that cancel sublists MAY appear in the MIDI
list (the default condition).

o The digit 2 codes that commands other than the sender actions
related to changing R described earlier System Real-time MIDI
commands MUST NOT appear between SysEx command segments in this section).

However, the
MIDI list (the default condition).

o The digit 3 codes that any MIDI command type may appear between
SysEx command segments in rare situations, the bandwidth MIDI list, with the exception of
the stream (due to a lack segmented encoding of feedback reports from a second SysEx command (verbatim SysEx
commands are OK).

For command-type X, the sender) may become too large to continue
sending channel list MUST NOT contain both digits 0
and 1, and it MUST NOT contain both digits 2 and 3. For command-type
X, channel list numbers other than the stream to numbers defined above are
ignored. If X does not have a channel list, the receiver before semantics marked
"the default condition" in the SSRC time-out occurs list above apply.

The syntax for field lists in a parameter assignment follows the receiver. In this case, the closed-loop policy states that the
sender should invoke the SSRC time-out
syntax for channel lists. If no field list is provided, the receiver early.

We now discuss receiver responsibilities in the case of unplanned
disruptions of RTCP feedback from receiver
parameter applies to sender.

In all controller or note numbers.

For command-type C (Control Change), the unicast case, if a sender invokes field list codes the SSRC time-out mechanism
controller numbers (0-255) for
a receiver, which the receiver stops receiving packets from parameter applies.

For command-type M (Parameter System), the sender. The
sender behavior imposed by field list codes the
Registered Parameter Numbers (RPNs) and Non-Registered Parameter
Numbers (NRPNs) for which the guardtime parameter (Appendix C.4.2) lets applies. The number range
0-16383 specifies RPNs, the receiver conclude a SSRC time-out has occurred in a reasonable time
period.

In this case of a time-out, a receiver MUST keep sending RTCP feedback,
in order number range 16384-32767 specifies NRPNs
(16384 corresponds to re-establish NRPN 0, 32767 corresponds to NRPN 16383).

For command-types N (NoteOn and NoteOff) and A (Poly Aftertouch), the RTP flow from
field list codes the sender. Unless note numbers for which the
receiver expects a prompt recovery of parameter applies.

For command-types J and K (System Common Undefined), the RTP flow, field list
consists of a single digit, which specifies the receiver MUST
take actions to ensure number of data octets
that follow the rendered MIDI performance does not
exhibit "very long transient artifacts" (for example, by silencing
NoteOns to prevent stuck notes) while awaiting reconnection of command octet.

For command-type X (SysEx), the flow.

In field list codes the multicast case, if number of data
octets that may appear in a sender invokes SysEx command. Thus, the SSRC time-out mechanism

for a receiver, field list
0-255 specifies SysEx commands with 255 or fewer data octets, the receiver may continue to receive packets,
field list 256-4294967295 specifies SysEx commands with more than 255
data octets but excludes commands with 255 or fewer data octets, and
the
sender will no longer being using the M(k) feedback from the receiver to
choose each checkpoint packet. If field list 0 excludes all commands.

A secondary parameter assignment syntax customizes command-type X
(see Appendix D for complete ABNF):

<parameter> = "__" <h-list> ["_" <h-list>] "__"

The assignment defines the receiver does not have additional
information class of SysEx commands that precludes an SSRC time-out (such as RTCP Receiver
Reports from obeys the sender about an RTP stream
semantics of the receiver assigned parameter. The command class is multicasting
back to the sender), the receiver MUST monitor specified
by listing the Checkpoint Packet
Seqnum to detect an SSRC time-out. If an SSRC time-out is detected, permitted values of the
receiver MUST first N data octets that
follow the instructions for SSRC time-outs described for
the unicast case above.

Finally, we note that SysEx 0xF0 command octet. Any SysEx command whose first N
data octets match the closed-loop policy list is suitable for use in
RTP/RTCP sessions that use multicast transport. However, aspects a member of the
closed-loop policy do not scale well to sessions with large numbers class.

Each <h-list> defines a data octet of
participants. The sender state scales linearly with the number command, as a dot-separated
(".") list of
receivers, one or more hexadecimal constants (such as "7F") or
dash-separated hexadecimal ranges (such as "01-1F"). Underscores
("_") separate each <h-list>. Double-underscores ("__") delineate
the sender needs data octet list.

Using this syntax, each assignment specifies a single SysEx command
class. Session descriptions may use several assignments to track the identity cm_used
and M(k) value for
each receiver k. cm_unused to specify complex behaviors.

The average recovery journal size is not independent
of example session description below illustrates the number use of receivers, as the RTCP reporting interval backoff slows
down the rate of a full update of M(k) values.
stream subsetting parameters:

The backoff algorithm
may also increase session description configures the amount of ancillary state stream for use in clock
applications. All voice channels are unused, as are all System
Commands except those used for MIDI Time Code (command-type F, and
the Full Frame SysEx command that is matched by implementations
of the normative sender string assigned
to cm_used), the System Sequencer commands (command-type Q), and receiver behaviors defined in Section 4.

C.2.2.3 The open-loop Sending Policy
System Reset (command-type B).

C.2. Configuration Tools: The open-loop policy is suitable for sessions Journalling System

In this appendix, we define the payload format parameters that are not able to
implement
configure stream journalling and the receiver-to-sender feedback required by recovery journal system.

The j_sec parameter (Appendix C.2.1) sets the closed-loop
policy, and are also not able to use journalling method for
the anchor policy because of
bandwidth constraints. stream. The open-loop policy does not place constraints on how a sender chooses j_update parameter (Appendix C.2.2) sets the checkpoint packet
recovery journal sending policy for each packet in the stream. In Appendix C.2.2 also
defines the absence sending policies of
such constraints, a receiver may find that the recovery journal in the
packet that ends a loss event has a checkpoint history system.

Appendix C.2.3 defines several parameters that does not
cover the entire loss event. We refer to loss events of this type as
uncovered loss events.

To ensure that uncovered loss events do not compromise modify the recovery
journal mandate, semantics. These parameters change the open-loop policy assigns specific default recovery tasks to
senders, receivers,
journal semantics as defined in Section 5 and the creators of session descriptions. Appendices A-B.

The
underlying premise of the open-loop policy journalling method for a stream is that set at the indefinite
artifacts produces during uncovered loss events fall into two classes.

One class start of artifacts are recoverable indefinite artifacts. Receivers
are able a session
and MUST NOT be changed thereafter. This requirement forbids changes
to repair recoverable artifacts that occur during an uncovered
loss event without intervention from the sender, at j_sec parameter once a session has begun.

A related requirement, defined in the potential cost appendix sections below,
forbids the acceptance of unpleasant transient artifacts.

For example, after an uncovered loss event, receivers are able to repair
indefinite artifacts due to NoteOff (0x8) commands parameter values that may have

occurred during would violate the loss event, by executing NoteOff commands for all
active NoteOns commands. This action causes
recovery journal mandate. In many cases, a transient artifacts (a
sudden silent period change in one of the performance), but ensures that no stuck
notes sound indefinitely. We refer to MIDI commands that are amenable
to repair
parameters defined in this fashion as recoverable MIDI commands.

A second class of artifacts are unrecoverable indefinite artifacts. If
this class of artifact occurs appendix during an uncovered loss event, the
receiver is not able to repair ongoing session would
result in a violation of the stream.

For example, after recovery journal mandate for an uncovered loss event, receivers are not able to
repair indefinite artifacts due to Control Change (0xB) Channel Volume
(controller number 7) commands that have occurred during the loss event.
A repair is impossible because
implementation; in this case, the receiver has no way of determining parameter change MUST NOT be
accepted.

C.2.1. The j_sec Parameter

Section 2.2 defines the data value of default journalling method for a lost Channel Volume command. We refer stream.
Streams that use unreliable transport (such as UDP) default to MIDI
commands using
the recovery journal. Streams that are fragile in this way use reliable transport (such as unrecoverable MIDI commands.

The open-loop policy does
TCP) default to not specify how using a journal.

The parameter j_sec may be used to partition the MIDI command
set into recoverable override this default. This memo
defines two symbolic values for j_sec: "none", to indicate that all
stream payloads MUST NOT contain a journal section, and unrecoverable commands. Instead, it assumes "recj", to
indicate that all stream payloads MUST contain a journal section that
uses the creators of recovery journal format.

For example, the session descriptions are able to come j_sec parameter might be set to
agreement "none" for a UDP
stream that travels between two hosts on a suitable recoverable/unrecoverable MIDI command partition
for an application.

Given these definitions, we now state the normative requirements for the
open-loop policy.

In the open-loop policy, the creators of the local network that is
known to provide reliable datagram delivery.

The session description MUST below configures a UDP stream that does not
use the ch_anchor parameter (defined in Appendix C.2.3) to protect all
unrecoverable MIDI command types from indefinite artifacts, or
alternatively recovery journal:

v=0
o=lazzaro 2520644554 2838152170 IN IP4 first.example.net
s=Example
t=0 0
m=audio 5004 RTP/AVP 96
c=IN IP4 192.0.2.94
a=rtpmap:96 rtp-midi/44100
a=fmtp:96 j_sec=none

Other IETF standards-track documents may define alternative journal
formats. These documents MUST use define new symbolic values for the cm_unused
j_sec parameter (defined in Appendix C.1) to exclude the command types from signal the stream. These options act to
shield command types from artifacts during an uncovered loss event.

In use of the open-loop policy, receivers format.

Parties MUST examine the Checkpoint Packet
Seqnum field of NOT accept a j_sec value that violates the recovery
journal header after every loss event, to
check if the loss event is an uncovered loss event. mandate (see Section 5 shows how
to perform this check. 4 for details). If an uncovered loss event has occurred, a
receiver session
description uses a j_sec value unknown to the recipient, the
recipient MUST perform indefinite artifact recovery for all MIDI command
types that NOT accept the description.

Special j_sec issues arise when sessions are not shielded managed by ch_anchor and cm_unused parameter
assignments in session
management tools (like RTSP, [RFC2326]) that use SDP for "declarative
usage" purposes (see the preamble of Section 6 for details). For
these session description.

The open-loop policy management tools, SDP does not place specific constraints on the sender.
However, code transport details
(such as UDP or TCP) for the open-loop policy works best if session. Instead, server and client
negotiate transport details via other means (for RTSP, the sender manages SETUP
method).

In this scenario, the size use of the checkpoint history to ensure that uncovered losses occur
infrequently, by taking into account j_sec parameter may be ill-advised,
as the delay and loss characteristics creator of the network. Also, as each checkpoint packet change incurs session description may not yet know the risk
of an uncovered loss, senders should only move
transport type for the checkpoint if it
reduces session. In this case, the size of session
description SHOULD configure the journal.

C.2.3 Recovery Journal Chapter Inclusion Parameters

The recovery journal chapter definitions (Appendices A-B) specify under
what conditions a chapter MUST appear journalling system using the
parameters defined in the recovery journal. In most
cases, remainder of Appendix C.2, but it SHOULD
NOT use j_sec to set the definition states journalling status. Recall that if a certain command appears in the
checkpoint history, a certain chapter type MUST j_sec
does not appear in the session description, the default method for
choosing the journalling method is in effect (no journal for reliable
transport, recovery journal to protect for unreliable transport).

However, in declarative usage situations where the command. creator of the
session description knows that journalling is always required or
never required, the session description SHOULD use the j_sec
parameter.

C.2.2. The j_update Parameter

In this section, Section 4, we describe use the chapter inclusion parameters. These
parameters modify term "sending policy" to describe the conditions under which method
a chapter appears the
journal. These parameters are essential sender uses to choose the use of checkpoint packet identity for each
recovery journal in a stream. In the open-loop
policy (Appendix C.2.2.3), sub-sections that follow, we
normatively define three sending policies: anchor, closed-loop, and
open-loop.

As stated in Section 4, the default sending policy for a stream is
the closed-loop policy. The j_update parameter may also be used to simplify
implementations of
override this default.

We define three symbolic values for j_update: "anchor", to indicate
that the stream uses the closed-loop (Appendix C.2.2.2) and anchor
(Appendix C.2.2.1) policies.

Each parameter represents a type of chapter inclusion semantics. An
assignment sending policy, "open-loop", to a parameter declares which chapters (or chapter subsets)
obey
indicate that the inclusion semantics. We describe stream uses the assignment syntax open-loop sending policy, and
"closed-loop", to indicate that the stream uses the closed-loop
sending policy. See Appendix C.2.3 for
these parameters later in this section.

A party examples session descriptions
that use the j_update parameter.

Parties MUST NOT accept chapter inclusion parameter values a j_update value that violate violates the recovery
journal mandate (Section 4). All assignments of

Other IETF standards-track documents may define additional sending
policies for the
subsetting parameters (cm_used and cm_unused) recovery journal system. These documents MUST precede the first
assignment of a chapter inclusion parameter in
define new symbolic values for the j_update parameter list.

Below, we normatively define to signal the semantics
use of the chapter inclusion
parameters. For clarity, we define the action of parameters on complete
chapters. new policy. If a parameter is assigned a subset of session description uses a chapter, the
definition applies only j_update
value unknown to the chapter subset.

o ch_never. A chapter assigned to recipient, the ch_never parameter recipient MUST NOT appear accept the
description.

C.2.2.1. The anchor Sending Policy

In the anchor policy, the sender uses the first packet in the stream
as the checkpoint packet for all packets in the stream. The anchor
policy satisfies the recovery journal (Appendix A.4.1-2 defines
exceptions to this rule for Chapter M). To signal mandate (Section 4), as the exclusion
checkpoint history always covers the entire stream.

The anchor policy does not require the use of a chapter from the journal, an assignment RTP control
protocol (RTCP, [RFC3550]) or other feedback from receiver to ch_never MUST
be made, even if sender.
Senders do not need to take special actions to ensure that received
streams start up free of artifacts, as the commands coded by recovery journal always
covers the chapter are assigned
to cm_unused. This rule simplifies entire history of the handling stream. Receivers are relieved of commands
types that may be coded in several chapters.

o ch_default. A chapter assigned to
the ch_default parameter
MUST follow responsibility of tracking the default semantics for changing identity of the chapter, as defined
in Appendices A-B.

o ch_anchor. A chapter assigned to
checkpoint packet, because the ch_anchor MUST obey a
modified version checkpoint packet never changes.

The main drawback of the default chapter semantics. In the
modified semantics, all references to anchor policy is bandwidth efficiency.
Because the checkpoint history
are replaced with references to covers the session history, and all
references to entire stream, the checkpoint packet are replaced with
references to size of
the first packet sent in recovery journals produced by this policy usually exceeds the stream.

Parameter assignments obey
journal size of alternative policies. For single-channel MIDI data
streams, the following syntax bandwidth overhead of the anchor policy is often
acceptable (see Appendix D for
ABNF):

<parameter> = [channel list]<chapter list>[field list] A.4 of [NMP]). For dense streams, the
closed-loop or open-loop policies may be more appropriate.

C.2.2.2. The chapter list closed-loop Sending Policy

The closed-loop policy is mandatory; the channel and field lists are optional.
Multiple assignments to parameters have a cumulative effect, and are
applied in default policy of the order of parameter appearance recovery journal
system. For each packet in a media description.

To determine the semantics of a list of chapter inclusion parameter
assignments, we begin by assuming an implicit assignment of all channel
and system chapters to the ch_default parameter, with stream, the default values
for policy lets senders
choose the channel list and field list for each chapter smallest possible checkpoint history that are defined
below.

We then interpret satisfies the semantics of
recovery journal mandate. As smaller checkpoint histories generally
yield smaller recovery journals, the actual parameter assignments,
using closed-loop policy reduces the rules below.

A later assignment
bandwidth of a chapter stream, relative to the same parameter expands anchor policy.

The closed-loop policy relies on feedback from receiver to sender.
The policy assumes that a receiver periodically informs the scope sender of
the earlier assignment. In most cases, a later assignment highest sequence number it has seen so far in the stream, coded
in the 32-bit extension format defined in [RFC3550]. For RTCP,
receivers transmit this information in the Extended Highest Sequence
Number Received (EHSNR) field of Receiver Reports. RTCP Sender or
Receiver Reports MUST be sent by any participant in a
chapter session with
closed loop sending policy, unless another feedback mechanism has
been agreed upon.

The sender may safely use receiver sequence number feedback to guide
checkpoint history management, because Section 4 requires that
receivers repair indefinite artifacts whenever a different parameter cancels (partially or completely) packet loss event
occur.

We now normatively define the
effect of an earlier assignment.

The chapter list specifies closed-loop policy. At the channel or system chapters moment a
sender prepares an RTP packet for which transmission, the
parameter applies. The chapter list sender is a concatenated sequence aware
of one
or more R >= 0 receivers for the stream. Senders may become aware of a
receiver via RTCP traffic from the letters corresponding to receiver, via RTP packets from a
paired stream sent by the chapter types
(ACDEFMNPQTVWX). In addition, receiver to the list may contain one sender, via messages from a
session management tool, or more by other means. As receivers join and
leave a session, the value of R changes.

Each known receiver k (1 <= k <= R) is associated with a 32-bit
extended packet sequence number M(k), where the
letters for extension reflects
the sub-chapter types (BGHJKYZ) sequence number rollover count of System Chapter D.

The letters in a chapter list MUST be upper case, and MUST appear in
alphabetical order. Letters other than (ABCDEFGHJKMNPQTVWXYZ) that
appear in the chapter list MUST be ignored.

The channel list specifies sender.

If the channel journals for which this parameter
applies; if no channel list sender has received at least one feedback report from receiver
k, M(k) is provided, the parameter applies to all
channel journals. The channel list takes the form of a list most recent report of channel
numbers (0 through 15) and dash-separated channel the highest RTP packet sequence
number ranges (i.e.
0-5, 8-12, etc). Dots (i.e. "." characters) separate elements in seen by the
channel list.

Several receiver, normalized to reflect the rollover count
of the systems chapters may be configured to have special
semantics. Configuration occurs by specifying sender.

If the sender has not received a channel list for feedback report from the
systems channel, using receiver,
M(k) is the coding described below (note that MIDI
Systems commands do not have a "channel", and thus extended sequence number of the original purpose last packet the sender
transmitted before it became aware of the channel list does not apply to systems chapters). The expression
"the digit N" receiver. If the sender
became aware of this receiver before it sent the first packet in the text below refers to
stream, M(k) is the inclusion extended sequence number of N as a
"channel" the first packet in
the channel list stream.

Given this definition of M(), we now state the closed-loop policy.
When preparing a new packet for transmission, a systems chapter.

For the J and K Chapter D sub-chapters (undefined System Common), the
digit 0 codes sender MUST choose a
checkpoint packet with extended sequence number N, such that M(k) >=
(N - 1) for all k, 1 <= k <= R, where R >= 1. The policy does not
restrict sender behavior in the parameter applies to R == 0 (no known receivers) case.

Under the LEGAL field of closed-loop policy as defined above, a sender may transmit
packets whose checkpoint history is shorter than the
associated command log (Figure B.1.4 of session history
(as defined in Appendix B.1), the digit 1 codes A.1). In this event, a new receiver that
joins the parameter applies to the VALUE field of the stream may experience indefinite artifacts.

For example, if a Control Change (0xB) command log, for Channel Volume
(controller number 7) was sent early in a stream, and later a new
receiver joins the digit 2 codes that session, the parameter applies closed-loop policy may permit all
packets sent to the COUNT field of the
command log.

For the Y and Z Chapter D sub-chapters (undefined System Real-time), the
digit 0 codes that the parameter applies new receiver to use a checkpoint history that
does not include the LEGAL field of Channel Volume Control Change command. As a
result, the
associated command log (Figure B.1.5 of Appendix B.1) new receiver experiences an indefinite artifact, and
plays all notes on a channel too loudly or too softly.

To address this issue, the digit 1
codes closed-loop policy states that the parameter applies to the COUNT field whenever a
sender becomes aware of a new receiver, the command log.

For Chapter Q (Sequencer State Commands), the digit 0 codes that sender MUST determine if
the
parameter applies receiver would be subject to indefinite artifacts under the default Chapter Q definition, which forbids
closed-loop policy. If so, the
TIME field. The digit 1 codes sender MUST ensure that the parameter applies receiver
starts the session free of indefinite artifacts.

For example, to solve the
optional Chapter Q definition, which supports Channel Volume issue described above, the TIME field.

The syntax for field lists follows
sender may code the syntax for channel lists. If no
field list is provided, current state of the parameter applies to all Channel Volume controller or note
numbers. For
numbers in the recovery journal Chapter C, if no field list is provided, until it receives the controller
numbers do not use enhanced
first RTCP RR report that signals that a packet containing this
Chapter C encoding (Appendix A.3.3).

For Chapter C, the field list may take on values in has been received.

In satisfying this requirement, senders MAY infer the range 0 to 255.
A field value X initial MIDI
state of the receiver from the session description. For example, the
stream example in Section 6.2 has the range 0-127 refers to initial state defined in [MIDI]
for General MIDI.

In a controller number X, and
indicates unicast RTP session, a receiver may safely assume that the controller number does not use enhanced Chapter C
encoding. A field value X
sender is aware of its presence of a receiver from the first packet
sent in the range 128-255 refers to RTP stream. However, in other types of RTP sessions
(multicast, conference focus, RTP translator/mixer), a controller
number "X minus 128", and indicates receiver is
often not able to determine if the controller number does use sender is initially aware of its
presence as a receiver.

To address this issue, the
enhanced Chapter C encoding.

Assignments made closed-loop policy states that if a
receiver participates in a session where it may have access to configure the Chapter C encoding method for a
controller number
stream whose sender is not aware of the receiver, the receiver MUST be made
take actions to ensure that its rendered MIDI performance does not
contain indefinite artifacts. These protections will be necessarily
incomplete. For example, a receiver may monitor the ch_default or ch_anchor
parameters, as assignments Checkpoint
Packet Seqnum for uncovered loss events, and "err on the side of
caution" with respect to ch_never act handling stuck notes due to exclude lost MIDI
NoteOff commands, but the number from receiver is not able to compensate for the recovery journal (and thus,
lack of Channel Volume initialization data in the indicated encoding method is
irrelevant).

A Chapter C field list recovery journal.

The receiver MUST NOT encode conflicting information about discontinue these protective actions until it
is certain that the
enhanced encoding status sender is aware of its presence. If a particular controller number. For
example, values 0 and 128 MUST NOT both be coded by a field list.

For Chapter M, the field list codes receiver
is not able to ascertain sender awareness, the Registered Parameter Numbers
(RPNs) and Non-Registered Parameter Numbers (NRPNs) receiver MUST continue
these protective actions for which the
parameter applies. The number range 0-16383 specifies RPNs, duration of the number
range 16384-32767 specifies NRPNs (16384 corresponds to NRPN 0, 32767
corresponds session.

Note that in a multicast session where all parties are expected to NRPN 16383).

For Chapters N
send and A, receive, the field list codes reception of RTCP receiver reports from the note numbers for which
sender about the parameter applies. The note number range specified for Chapter N
also applies to Chapter E.

For Chapter E, RTP stream a receiver is multicasting is evidence of
the digit 0 codes sender's awareness that the parameter applies to Chapter E
note logs whose V bit RTP stream multicast by the sender is set to 0,
being monitored by the digit 1 codes that receiver. Receivers may also obtain sender
awareness evidence from session management tools, or by other means.
In practice, ongoing observation of the parameter
applies Checkpoint Packet Seqnum to note logs whose V bit
determine if the sender is set taking actions to 1.

For Chapter X, the field list codes the number of data octets that may
appear in prevent loss events for
a SysEx command that receiver is a good indication of sender awareness, as is coded in the chapter. Thus, the field
list 0-255 specifies SysEx commands with 255 or fewer data octets, the
field list 256-429496729 specifies SysEx commands sudden
appearance of recovery journal chapters with more than 255 numerous Control Change
controller data octets but excludes that was not foreshadowed by recent commands with 255 or fewer data octets, and coded in
the
field MIDI list 0 excludes all commands.

A secondary parameter assignment syntax customizes Chapter X (see
Appendix D for complete ABNF):

<parameter> = "__" <h-list> ["_" <h-list>] "__" shortly after sending an RTCP RR.

The assignment defines a class final set of SysEx commands whose Chapter X coding
obeys the semantics normative closed-loop policy requirements concern
how senders and receivers handle unplanned disruptions of RTCP
feedback from a receiver to a sender. By "unplanned", we refer to
disruptions that are not due to the assigned parameter. The command class is
specified by listing the permitted values signalled termination of an RTP
stream, via an RTCP BYE or via session management tools.

As defined earlier in this section, the first N data octets closed-loop policy states
that follow the SysEx 0xF0 command octet. Any SysEx command whose first
N data octets match a sender MUST choose a checkpoint packet with extended sequence
number N, such that M(k) >= (N - 1) for all k, 1 <= k <= R, where R
>= 1. If the list sender has received at least one feedback report from
receiver k, M(k) is a member of the class.

Each <h-list> defines a data octet most recent report of the command, as a dot-separated
(".") list of one or more hexadecimal constants (such as "7F") or dash-
separated hexadecimal ranges (such as "01-1F"). Underscores ("_")
separate each <h-list>. Double-underscores ("__") delineate highest RTP packet
sequence number seen by the data
octet list.

Using this syntax, each assignment specifies a single SysEx command
class. Session descriptions may use several assignments receiver, normalized to reflect the same (or
different) parameters to specify complex Chapter X behaviors. The
ordering behavior
rollover count of multiple assignments follows the guidelines for
chapter parameter assignments described earlier in sender.

If this section.

The example session description below illustrates receiver k stops sending feedback to the use of sender, the chapter
inclusion parameters:

v=0
o=lazzaro 2520644554 2838152170 IN IP6 first.example.net
s=Example
t=0 0
m=audio 5004 RTP/AVP 96
c=IN IP6 2001:DB80::7F2E:172A:1E24
a=rtpmap:96 rtp-midi/44100
a=fmtp:96 j_update=open-loop; cm_unused=ABCFGHJKMQTVWXYZ;
cm_used=__7E_00-7F_09_01.02.03__;
cm_used=__7F_00-7F_04_01.02__; cm_used=C7.64;
ch_never=ABCDEFGHJKMQTVWXYZ; ch_never=4.11-13N;
ch_anchor=P; ch_anchor=C7.64;
ch_anchor=__7E_00-7F_09_01.02.03__;
ch_anchor=__7F_00-7F_04_01.02__

(The a=fmtp line has been wrapped to fit M(k)
value used by the page to accommodate
memo formatting restrictions; it comprises a single line in SDP)

The j_update parameter codes that sender reflects the stream uses last feedback report from the open-loop policy.
Most MIDI command-types are assigned
receiver. As time progresses without feedback from receiver k, this
fixed M(k) value forces the sender to cm_unused increase the size of the
checkpoint history, and thus do not appear
in increases the bandwidth of the stream. As a consequence,

At some point, the assignments sender may need to take action in order to limit
the first ch_never
parameter reflect that bandwidth of the stream. In most chapters are not in use.

Chapter N for several MIDI channels envisioned uses of RTP MIDI,
long before this point is assigned to ch_never. Chapter N
for MIDI channels other than 4, 11, 12, and 13 may appear reached, the SSRC time-out mechanism
defined in [RFC3550] will remove the
recovery journal, using uncooperative receiver from the (default) ch_default semantics. In
practice, this assignment pattern would reflect knowledge about a
resilient rendering method in use for
session (note that the excluded channels.

The MIDI Program Change command and several MIDI Control Change
controller numbers are assigned closed-loop policy does not suggest or require
any special sender behavior upon an SSRC time-out, other than the
sender actions related to ch_anchor. Note that changing R, described earlier in this
section).

However, in rare situations, the ordering bandwidth of the ch_anchor chapter C assignment after the ch_never command acts stream (due to
override a
lack of feedback reports from the ch_never assignment for sender) may become too large to
continue sending the listed controller numbers (7
and 64).

The assignment of command-type X stream to cm_unused excludes most SysEx
commands from the stream. Exceptions are made for General MIDI System
On/Off commands and receiver before the SSRC time-out
occurs for the Master Volume and Balance commands, via receiver. In this case, the
use of closed-loop policy states
that the secondary assignment syntax. The cm_used assignment codes sender should invoke the exception, and SSRC time-out for the ch_anchor assignment codes how these commands are
protected receiver
early.

We now discuss receiver responsibilities in Chapter X.

C.3 Configuration Tools: Timestamp Semantics

The MIDI command section of the payload format consists of a list case of
commands, each with an associated timestamp. The semantics unplanned
disruptions of command
timestamps may be set during session configuration, using RTCP feedback from receiver to sender.

In the parameters
we describe in this section

The parameter "tsmode" specifies unicast case, if a sender invokes the timestamp semantics SSRC time-out mechanism
for a stream.
The parameter takes on one of three token values: "comex", "async", or
"buffer". receiver, the receiver stops receiving packets from the sender.
The default "comex" value specifies that timestamps code sender behavior imposed by the execution
time for a command guardtime parameter (Appendix C.3.1), and supports
C.4.2) lets the accurate
transcoding Standard MIDI Files (SMFs, [MIDI]). The "comex" value is
also RECOMMENDED for new MIDI user-interface controller designs. The
"async" value specifies receiver conclude that an asynchronous timestamp sampling algorithm for
time-of-arrival sources (Appendix C.3.2). The "buffer" value specifies
a synchronous timestamp sampling algorithm (Appendix C.3.3) for time-of-
arrival sources.

Ancillary parameters MAY follow tsmode SSRC time-out has occurred
in a media description. We
define these parameters in Appendices C.3.2-3 below.

C.3.1 The comex Algorithm

The default "comex" (COMmand EXecution) tsmode value specifies the
execution reasonable time for the command. With comex, period.

In this case of a time-out, a receiver MUST keep sending RTCP
feedback, in order to re-establish the difference between two
timestamps indicates RTP flow from the time delay between sender.
Unless the execution receiver expects a prompt recovery of the
commands. This difference may be zero, coding simultaneous execution.

The comex interpretation of timestamps works well for transcoding a
Standard MIDI File (SMF, [MIDI]) into an RTP MIDI stream, as SMFs code a
timestamp for each MIDI command stored in flow, the file. To transcode an SMF
receiver MUST take actions to ensure that uses metric time markers, use the SMF tempo map (encoded in the SMF
as meta-events) to convert metric SMF timestamp units into seconds-based
RTP timestamp units.

New MIDI controller designs (piano keyboard, drum pads, etc) that
support RTP rendered MIDI and that have direct access
performance does not exhibit "very long transient artifacts" (for
example, by silencing NoteOns to sensor data SHOULD use
comex interpretation prevent stuck notes) while awaiting
reconnection of the flow.

In the multicast case, if a sender invokes the SSRC time-out
mechanism for timestamps, so that simultaneous gestural
events a receiver, the receiver may continue to receive
packets, but the sender will no longer be accurately coded by using the M(k) feedback
from the receiver to choose each checkpoint packet. If the receiver
does not have additional information that precludes an SSRC time-out
(such as RTCP Receiver Reports from the sender about an RTP MIDI.

Comex stream
the receiver is a poor choice multicasting back to the sender), the receiver MUST
monitor the Checkpoint Packet Seqnum to detect an SSRC time-out. If
an SSRC time-out is detected, the receiver MUST follow the
instructions for transcoding MIDI 1.0 DIN cables [MIDI], SSRC time-outs described for a
reason that the unicast case above.

Finally, we now explain. A MIDI DIN cable note that the closed-loop policy is an asynchronous serial
protocol (320 microseconds per MIDI byte). MIDI commands on a DIN cable
are suitable for use in
RTP/RTCP sessions that use multicast transport. However, aspects of
the closed-loop policy do not tagged scale well to sessions with timestamps. Instead, MIDI DIN receivers infer
command timing from the time large
numbers of arrival participants. The sender state scales linearly with the
number of receivers, as the bytes. Thus, two two-
byte MIDI commands that occur at a source simultaneously are encoded on

a MIDI 1.0 DIN cable with a 640 microsecond time offset. A MIDI DIN
receiver is unable sender needs to tell if this time offset existed in track the source
performance, or identity and
M(k) value for each receiver k. The average recovery journal size is an artifact
not independent of the serial speed number of receivers, as the cable.
However, RTCP reporting
interval backoff slows down the RTP MIDI comex interpretation rate of timestamps declares that a
timestamp offset between two commands reflects the timing full update of M(k) values.
The backoff algorithm may also increase the source
performance.

This semantic mismatch is amount of ancillary state
used by implementations of the reason that comex normative sender and receiver
behaviors defined in Section 4.

C.2.2.3. The open-loop Sending Policy

The open-loop policy is a poor choice suitable for
transcoding MIDI DIN cables. Note sessions that are not able to
implement the choice receiver-to-sender feedback required by the closed-loop
policy, and that are also not able to use the anchor policy because
of bandwidth constraints.

The open-loop policy does not place constraints on how a sender
chooses the RTP timestamp
rate (Section 6.1-2 checkpoint packet for each packet in the main text) cannot fix this inaccuracy issue. stream. In the sections
absence of such constraints, a receiver may find that follow, we describe two alternative timestamp
interpretations ("async" and "buffer") the recovery
journal in the packet that are ends a better match loss event has a checkpoint history
that does not cover the entire loss event. We refer to MIDI
1.0 DIN cable timing, and loss events
of this type as uncovered loss events.

To ensure that uncovered loss events do not compromise the recovery
journal mandate, the open-loop policy assigns specific recovery tasks
to other MIDI time-of-arrival sources.

The "octpos", "linerate", senders, receivers, and "mperiod" ancillary parameters (defined
below) SHOULD NOT be used with comex.

C.3.2 The async Algorithm

The "async" tsmode value specifies the asynchronous sampling creators of session descriptions. The
underlying premise of a MIDI
time-of-arrival source. In asynchronous sampling, the moment an octet open-loop policy is received from a source it that the indefinite
artifacts produced during uncovered loss events fall into two
classes.

One class of artifacts is labelled with a wall-clock time value.
The time value has RTP timestamp units.

The "octpos" ancillary parameter defines how RTP command timestamps recoverable indefinite artifacts.
Receivers are
derived able to repair recoverable artifacts that occur during
an uncovered loss event without intervention from octet time values. If octpos has the token value "first",
a timestamp codes the time value of sender, at the first octet
potential cost of unpleasant transient artifacts.

For example, after an uncovered loss event, receivers are able to
repair indefinite artifacts due to NoteOff (0x8) commands that may
have occurred during the command. If
octpos has the token value "last", loss event, by executing NoteOff commands
for all active NoteOns commands. This action causes a timestamp codes the time value of transient
artifact (a sudden silent period in the last octet performance), but ensures
that no stuck notes sound indefinitely. We refer to MIDI commands
that are amenable to repair in this fashion as recoverable MIDI
commands.

A second class of the command. artifacts is unrecoverable indefinite artifacts.
If this class of artifact occurs during an uncovered loss event, the octpos parameter does
receiver is not appear
in the media description, able to repair the sender does stream.

For example, after an uncovered loss event, receivers are not know the which octet of able to
repair indefinite artifacts due to Control Change (0xB) Channel
Volume (controller number 7) commands that have occurred during the command
loss event. A repair is impossible because the timestamp references (for example, receiver has no way
of determining the sender may be
relying on an operating system service data value of a lost Channel Volume command. We
refer to MIDI commands that are fragile in this way as unrecoverable
MIDI commands.

The open-loop policy does not specify this
information).

The octpos semantics refer how to partition the first or last octet of a MIDI
command as set into recoverable and unrecoverable commands. Instead, it
appears
assumes that the creators of the session descriptions are able to
come to agreement on a time-of-arrival suitable recoverable/unrecoverable MIDI source, not as it appears in
command partition for an RTP
MIDI packet. This distinction is significant because application.

Given these definitions, we now state the RTP coding may
contain octets that are not present in normative requirements for
the source. For example, open-loop policy.

In the
status octet open-loop policy, the creators of the first MIDI command session description MUST
use the ch_anchor parameter (defined in a packet may have been added Appendix C.2.3) to the protect
all unrecoverable MIDI stream during transcoding, command types from indefinite artifacts, or
alternatively MUST use the cm_unused parameter (defined in Appendix
C.1) to comply with exclude the RTP MIDI
running status requirements (Section 3.2).

The "linerate" ancillary parameter defines command types from the timespan of one MIDI
octet on stream. These options act
to shield command types from artifacts during an uncovered loss
event.

In the transmission medium open-loop policy, receivers MUST examine the Checkpoint Packet
Seqnum field of the MIDI source recovery journal header after every loss event,
to be sampled (such
as a MIDI 1.0 DIN cable). The parameter has units of nanoseconds, and
takes on integral values. For MIDI 1.0 DIN cables, check if the correct linerate
value is 320000 (this value loss event is also the default value for the
parameter).

We now show an uncovered loss event. Section 5
shows how to perform this check. If an uncovered loss event has
occurred, a session description example receiver MUST perform indefinite artifact recovery for the async algorithm.
Consider a sender that is transcoding a
all MIDI 1.0 DIN cable source into
RTP. The sender runs on a computing platform command types that assigns time values
to every incoming octet of the source, are not shielded by ch_anchor and the sender uses the time
values to label the first octet of each command
cm_unused parameter assignments in the RTP packet. This session description describes the transcoding:

v=0
o=lazzaro 2520644554 2838152170 IN IP4 first.example.net
s=Example
t=0 0
m=audio 5004 RTP/AVP 96
c=IN IP4 192.0.2.94
a=rtpmap:96 rtp-midi/44100
a=sendonly
a=fmtp:96 tsmode=async; linerate=320000; octpos=first

C.3.3 The buffer Algorithm description.

The "buffer" tsmode value specifies open-loop policy does not place specific constraints on the synchronous sampling of a MIDI
time-of-arrival source.

In synchronous sampling, octets received from a source are placed in a
holding buffer upon arrival. At periodic intervals,
sender. However, the RTP sender
examines open-loop policy works best if the buffer. The sender removes complete commands from the
buffer, and codes those commands in an RTP packet. The command
timestamp codes
manages the moment size of buffer examination, expressed in RTP
timestamp units. Note that several commands may have the same timestamp
value.

The "mperiod" ancillary parameter defines checkpoint history to ensure that uncovered
losses occur infrequently, by taking into account the nominal periodic sampling
interval. The parameter takes on positive integral values, delay and has RTP
timestamp units.

The "octpos" ancillary parameter, defined in Appendix C.3.1 for
asynchronous sampling, plays a different role in synchronous sampling.
In synchronous sampling, the parameter specifies the timestamp semantics loss
characteristics of a command whose octets span several sampling periods.

If octpos has the token value "first", the timestamp reflects the
arrival period of network. Also, as each checkpoint packet
change incurs the first octet risk of an uncovered loss, senders should only move
the command. If octpos has the
token value "last", the timestamp reflects the arrival period of checkpoint if it reduces the
last octet size of the command. journal.

C.2.3. Recovery Journal Chapter Inclusion Parameters

The octpos semantics refer to recovery journal chapter definitions (Appendices A-B) specify
under what conditions a chapter MUST appear in the first or
last octet of recovery journal.
In most cases, the command as it appears on definition states that if a time-of-arrival source, not
as it certain command
appears in the RTP packet.

If the octpos parameter does not checkpoint history, a certain chapter type MUST appear
in the media description, recovery journal to protect the
timestamp MAY reflect command.

In this section, we describe the arrival period of any octet of chapter inclusion parameters. These
parameters modify the command --

senders use this option to signal conditions under which a lack of knowledge about chapter appears the timing
details
journal. These parameters are essential to the use of the buffering process at sub-command granularity.

We now show a session description example for open-loop
policy (Appendix C.2.2.3) and may also be used to simplify
implementations of the buffer algorithm.
Consider a sender that is transcoding a MIDI 1.0 DIN cable source into
RTP. The sender runs on a computing platform that places source data
into closed-loop (Appendix C.2.2.2) and anchor
(Appendix C.2.2.1) policies.

Each parameter represents a buffer upon receipt. The sender polls the buffer 1000 times type of chapter inclusion semantics. An
assignment to a
second, extracts all complete commands from parameter declares which chapters (or chapter
subsets) obey the buffer, and places inclusion semantics. We describe the
commands assignment
syntax for these parameters later in an RTP packet. This session description describes this section.

A party MUST NOT accept chapter inclusion parameter values that
violate the
transcoding:

v=0
o=lazzaro 2520644554 2838152170 IN IP6 first.example.net
s=Example
t=0 0
m=audio 5004 RTP/AVP 96
c=IN IP6 2001:DB80::7F2E:172A:1E24
a=rtpmap:96 rtp-midi/44100
a=sendonly
a=fmtp:96 tsmode=buffer; linerate=320000; octpos=last; mperiod=44

The mperiod value recovery journal mandate (Section 4). All assignments of 44 is derived by dividing the clock rate specified
by the rtpmap attribute (44100 Hz) by
the 1000 Hz buffer sampling rate, subsetting parameters (cm_used and rounding to cm_unused) MUST precede the nearest integer. Command timestamps might not
increment by exact multiples
first assignment of 44, as the actual sampling period might
not precisely match a chapter inclusion parameter in the nominal mperiod value.

C.4 Configuration Tools: Packet Timing Tools

In this Appendix, parameter
list.

Below, we describe session configuration tools for
customizing normatively define the temporal behavior semantics of MIDI stream packets.

C.4.1 Packet Duration Tools

Senders control the granularity of a stream by setting chapter inclusion
parameters. For clarity, we define the temporal
duration ("media time") action of the packets in the stream. Short media times
(20 ms or less) often imply an interactive session. Longer media times
(100 ms or more) usually indicate parameters on
complete chapters. If a content streaming session. The RTP
AVP profile [RFC3551] recommends audio packet media times in parameter is assigned a range
from 0 to 200 ms.

By default, an RTP receiver dynamically senses the media time subset of packets
in a stream, and chooses chapter,
the length of its playout buffer definition applies only to match the
stream. chapter subset.

o ch_never. A receiver typically sizes its playout buffer chapter assigned to fit several
audio packets, and adjusts the buffer length ch_never parameter MUST NOT
appear in the recovery journal (Appendix A.4.1-2 defines
exceptions to reflect this rule for Chapter M). To signal the network
jitter and exclusion
of a chapter from the sender timing fidelity.

Alternatively, journal, an assignment to ch_never MUST be
made, even if the packet media time commands coded by the chapter are assigned to
cm_unused. This rule simplifies the handling of commands types
that may be statically set during
session configuration. Session descriptions MAY use coded in several chapters.

o ch_default. A chapter assigned to the RTP MIDI ch_default parameter "rtp_ptime" to set MUST
follow the recommended media time default semantics for a packet.
Session descriptions MAY also use the RTP MIDI parameter "rtp_maxptime" chapter, as defined in
Appendices A-B.

o ch_anchor. A chapter assigned to set the maximum media time for ch_anchor MUST obey a
modified version of the default chapter semantics. In the
modified semantics, all references to the checkpoint history are
replaced with references to the session history, and all
references to the checkpoint packet permitted in a stream. Both
parameters MAY be used together are replaced with references
to configure a the first packet sent in the stream.

Parameter assignments obey the following syntax (see Appendix D for
ABNF):

<parameter> = [channel list]<chapter list>[field list]

The values assigned to chapter list is mandatory; the rtp_ptime channel and rtp_maxptime field lists are
optional. Multiple assignments to parameters have a cumulative
effect and are applied in the units order of parameter appearance in a
media description.

To determine the RTP timestamp semantics of a list of chapter inclusion parameter
assignments, we begin by assuming an implicit assignment of all
channel and system chapters to the ch_default parameter, with the
default values for the stream, as set by channel list and field list for each chapter
that are defined below.

We then interpret the rtpmap
attribute (see Section 6.1). Thus, if rtpmap sets semantics of the clock rate actual parameter assignments,
using the rules below.

A later assignment of a
stream chapter to 44100 Hz, the same parameter expands the
scope of the earlier assignment. In most cases, a maximum packet media time later assignment
of 10 ms a chapter to a different parameter cancels (partially or
completely) the effect of an earlier assignment.

The chapter list specifies the channel or system chapters for which
the parameter applies. The chapter list is coded by
setting rtp_maxptime=441. As stated in a concatenated sequence
of one or more of the Appendix C preamble, letters corresponding to the
senders and receivers chapter types
(ACDEFMNPQTVWX). In addition, the list may contain one or more of
the letters for the sub-chapter types (BGHJKYZ) of System Chapter D.

The letters in a stream chapter list MUST agree on common values for
rtp_ptime be uppercase and rtp_maxptime if the parameters MUST appear in
alphabetical order. Letters other than (ABCDEFGHJKMNPQTVWXYZ) that
appear in the media
description for chapter list MUST be ignored.

The channel list specifies the stream.

0 ms channel journals for which this
parameter applies; if no channel list is provided, the parameter
applies to all channel journals. The channel list takes the form of
a reasonable media time value for MIDI packets, list of channel numbers (0 through 15) and is often
used dash-separated channel
number ranges (i.e., 0-5, 8-12, etc.). Dots (i.e., "." characters)
separate elements in low-latency interactive applications. In a packet with the channel list.

Several of the systems chapters may be configured to have special
semantics. Configuration occurs by specifying a 0 ms
media time, all channel list for the
systems channel, using the coding described below (note that MIDI
Systems commands execute at do not have a "channel", and thus the instant coded by original
purpose of the packet
timestamp. channel list does not apply to systems chapters). The session description below configures all packets
expression "the digit N" in the
stream text below refers to have 0 ms media time:

v=0
o=lazzaro 2520644554 2838152170 IN IP4 first.example.net
s=Example
t=0 0
m=audio 5004 RTP/AVP 96
c=IN IP4 192.0.2.94
a=rtpmap:96 rtp-midi/44100
a=fmtp:96 rtp_ptime=0; rtp_maxptime=0

The session attributes ptime and maxptime [SDP] MUST NOT be used to
configure an RTP MIDI stream. Sessions MUST use rtp_ptime in lieu the inclusion of
ptime, and MUST use rtp_maxptime
N as a "channel" in lieu of maxptime. RTP MIDI defines
its own parameters for media time configuration because 0 ms values for
ptime and maxptime are forbidden by [RFC3264], but are essential for
certain applications of RTP MIDI.

See the Appendix C.7 examples for additional discussion about using
rtp_ptime and rtp_maxptime for session configuration.

C.4.2 The guardtime Parameter

RTP permits a sender to stop sending audio packets channel list for an arbitrary
period of time during a session. When sending resumes, systems chapter.

For the RTP sequence
number series continues unbroken, J and K Chapter D sub-chapters (undefined System Common), the RTP timestamp value reflects
digit 0 codes that the media time silence gap.

This RTP feature has its roots in telephony, but is also well matched to
interactive MIDI sessions, as players may fall silent for several
seconds during (or between) songs.

Certain MIDI applications benefit from a slight enhancement to this RTP
feature. In interactive applications, receivers may use on-line network
models parameter applies to guide heuristics for handling lost and late RTP packets.
These models may work poorly if a sender ceases packet transmission for
long periods the LEGAL field of time.

Session descriptions may use the
associated command log (Figure B.1.4 of Appendix B.1), the digit 1
codes that the parameter "guardtime" to set a minimum
sending rate for a media session. The value assigned applies to guardtime codes the maximum separation time between two sequential packets, as expressed
in RTP timestamp units.

Typical guardtime values are 500-2000 ms. This value range is not a
normative bound, VALUE field of the command
log, and parties SHOULD be prepared the digit 2 codes that the parameter applies to process values
outside the COUNT
field of this range.

The congestion control requirements for sender implementations
(described in Section 8 the command log.

For the Y and [RFC3550]) take precedence over Z Chapter D sub-chapters (undefined System Real-time),
the
guardtime parameter. Thus, if digit 0 codes that the guardtime parameter requests a

minimum sending rate, but sending at this rate would violate applies to the
congestion control requirements, senders MUST ignore LEGAL field of
the guardtime
parameter value. In this case, senders SHOULD use associated command log (Figure B.1.5 of Appendix B.1) and the lowest minimum
sending rate
digit 1 codes that satisfies the congestion control requirements.

Below, we show a session description that uses parameter applies to the guardtime parameter.

v=0
o=lazzaro 2520644554 2838152170 IN IP6 first.example.net
s=Example
t=0 COUNT field of the
command log.

For Chapter Q (Sequencer State Commands), the digit 0
m=audio 5004 RTP/AVP 96
c=IN IP6 2001:DB80::7F2E:172A:1E24
a=rtpmap:96 rtp-midi/44100
a=fmtp:96 guardtime=44100; rtp_ptime=0; rtp_maxptime=0

C.5 Configuration Tools: Stream Description

As we discussed in Section 2.1 in codes that the main text, a party may send
several RTP MIDI streams in
parameter applies to the same RTP session, and several RTP
sessions default Chapter Q definition, which forbids
the TIME field. The digit 1 codes that carry MIDI may appear in a multimedia session.

By default, the MIDI name space (16 channels + systems) of each RTP
stream sent by a party in a multimedia session is independent. By
independent, we mean three distinct things:

o By independent, we mean that if a party sends two RTP MIDI
streams (A and B), MIDI voice channel 0 in stream A is a
different "channel 0" than MIDI voice channel 0 in stream B.

o By independent, we mean that MIDI voice channel 0 in stream B
is not considered parameter applies to be "channel 16" of a 32-channel MIDI voice the
optional Chapter Q definition, which supports the TIME field.

The syntax for field lists follows the syntax for channel space whose "channel 0" lists. If
no field list is channel 0 of stream A.

o By independent, we mean that streams sent by different parties
over different RTP sessions, provided, the parameter applies to all controller or that streams sent by different
parties send over
note numbers. For Chapter C, if no field list is provided, the same RTP session but with different
payload type numbers,
controller numbers do not share use enhanced Chapter C encoding (Appendix
A.3.3).

For Chapter C, the association that is
shared by a MIDI cable pair that cross-connects two devices
in a MIDI 1.0 DIN network. By default, this association is
only held by streams sent by different parties field list may take on values in the same
RTP session that use the same payload type number.

In this Appendix, we show how range 0 to express that specific RTP MIDI streams
in a multimedia session are not independent, but instead are related
255. A field value X in
one of the three ways defined above. We use two tools range 0-127 refers to express these
relations:

o The musicport parameter. This parameter is assigned a
non-negative integer value between 0 controller
number X, and 429496729. It
appears in the fmtp lines of payload types.

o The FID grouping attribute [RFC3388] signals indicates that several RTP
sessions the controller number does not use
enhanced Chapter C encoding. A field value X in a multimedia session are using the musicport
parameter range 128-255
refers to express an inter-session relationship.

If a multimedia session has several payload types whose musicport
parameters are assigned controller number "X minus 128" and indicates the same integer value, streams using these
payload types share an "identity relationship" (including streams that
controller number does use the same payload type). Streams in an identity relationship share
two properties:

o Identity relationship streams sent by the same party
target enhanced Chapter C encoding.

Assignments made to configure the same MIDI name space. Thus, if streams A
and B share an identity relationship, voice channel 0
in stream A is Chapter C encoding method for a
controller number MUST be made to the same "channel 0" ch_default or ch_anchor
parameters, as voice channel
0 in stream B.

o Pairs of identity relationship streams that are sent by
different parties share assignments to ch_never act to exclude the association that number from
the recovery journal (and thus the indicated encoding method is shared
by a MIDI cable pair that cross-connects two devices in
a MIDI 1.0 DIN network.
irrelevant).

A party Chapter C field list MUST NOT send two RTP MIDI streams that share an identity
relationship in encode conflicting information about
the same RTP session. Instead, each stream enhanced encoding status of a particular controller number. For
example, values 0 and 128 MUST NOT both be in coded by a
separate RTP session. As explained in Section 2.1 in field list.

For Chapter M, the main text,
this restriction is necessary to support field list codes the RTP MIDI method Registered Parameter Numbers
(RPNs) and Non-Registered Parameter Numbers (NRPNs) for which the
synchronization of streams that share a MIDI name space.

If a multimedia session has several payload types whose musicport
parameters are assigned sequential values (i.e. i, i+1, ... i+k), the
streams using
parameter applies. The number range 0-16383 specifies RPNs, the payload types share an "ordered relationship". For
example, if payload type A assigns 2
number range 16384-32767 specifies NRPNs (16384 corresponds to musicport and payload type B
assigns 3 NRPN
0, 32767 corresponds to musicport, A NRPN 16383).

For Chapters N and B are in an ordered relationship.

Streams in an ordered relationship that are sent by A, the same party are
considered by renderers field list codes the note numbers for which
the parameter applies. The note number range specified for Chapter N
also applies to form a single larger MIDI space. Chapter E.

For
example, if stream A has a musicport value of 2 and stream B has a
musicport value of 3, MIDI voice channel Chapter E, the digit 0 in stream B codes that the parameter applies to
Chapter E note logs whose V bit is considered set to
be voice channel 16 in the larger MIDI space formed by 0, and the relationship.
Note digit 1 codes
that it the parameter applies to note logs whose V bit is possible for streams set to participate in both an identity
relationship and an ordered relationship.

We now state several rules for using musicport:

o If streams from several RTP sessions 1.

For Chapter X, the field list codes the number of data octets that
may appear in a multimedia
session use SysEx command that is coded in the musicport parameter, chapter. Thus,
the RTP sessions
MUST be grouped using field list 0-255 specifies SysEx commands with 255 or fewer data
octets, the FID grouping attribute
defined in [RFC3388].

o An ordered field list 256-4294967295 specifies SysEx commands with
more than 255 data octets but excludes commands with 255 or identity relationship MUST NOT
contain both native RTP MIDI streams fewer
data octets, and
mpeg4-generic RTP MIDI streams. An exception applies
if the field list 0 excludes all commands.

A secondary parameter assignment syntax customizes Chapter X (see
Appendix D for complete ABNF):

<parameter> = "__" <h-list> ["_" <h-list>] "__"

The assignment defines a relationship consists class of sendonly and recvonly
(but not sendrecv) streams. In this case, SysEx commands whose Chapter X
coding obeys the sendonly
streams MUST NOT contain both types semantics of streams, and the
recvonly streams MUST NOT contain both types of streams.

o It assigned parameter. The command
class is possible to construct identity relationships
that violate specified by listing the recovery journal mandate (example:
sending NoteOns for a voice channel on stream A and
NoteOffs for permitted values of the same voice channel on stream B).

Parties MUST NOT generate (or accept) session
descriptions that exhibit this flaw.

o Other payload formats MAY define musicport media type
parameters. Formats would define these parameters so first N
data octets that
their sessions could be bundled into RTP MIDI name spaces.
The parameter definitions MUST be compatible with follow the
musicport semantics defined in this Appendix.

As SysEx 0xF0 command octet. Any SysEx
command whose first N data octets match the list is a rule, at most one payload type in member of the
class.

Each <h-list> defines a relationship may specify data octet of the command, as a MIDI
renderer. An exception to dot-separated
(".") list of one or more hexadecimal constants (such as "7F") or
dash-separated hexadecimal ranges (such as "01-1F"). Underscores
("_") separate each <h-list>. Double-underscores ("__") delineate
the rule applies to relationships that
contain sendonly and recvonly streams but no sendrecv streams. In data octet list.

Using this
case, one sendonly session and one recvonly session may syntax, each define a
renderer.

Renderer specification in assignment specifies a relationship single SysEx command
class. Session descriptions may be done using the tools
described in Appendix C.6. These tools work for both native streams and
mpeg4-generic streams. An mpeg4-generic stream that uses use several assignments to the Appendix
C.6 tools MUST set all "config" same
(or different) parameters to specify complex Chapter X behaviors.
The ordering behavior of multiple assignments follows the empty string ("").

Alternatively, guidelines
for mpeg4-generic streams, renderer specification may be
done by setting one "config" chapter parameter assignments described earlier in this section.

The example session description below illustrates the relationship to use of the
renderer configuration string, and all other config parameters
chapter inclusion parameters:

(The a=fmtp line has been wrapped to fit the
empty string ("").

We now define sender and receiver rules that apply when page to accommodate
memo formatting restrictions; it comprises a party sends
several streams single line in SDP.)

The j_update parameter codes that target the same MIDI name space.

Senders MAY use stream uses the subsetting parameters (Appendix C.1) open-loop
policy. Most MIDI command-types are assigned to predefine cm_unused and thus
do not appear in the partitioning of commands between streams, or MAY use a dynamic
partitioning strategy.

Receivers that merge identity relationship streams into stream. As a single MIDI
command stream MUST maintain consequence, the structural integrity of assignments to
the first ch_never parameter reflect that most chapters are not in
use.

Chapter N for several MIDI
commands coded channels is assigned to ch_never. Chapter
N for MIDI channels other than 4, 11, 12, and 13 may appear in each stream during the merging process,
recovery journal, using the (default) ch_default semantics. In
practice, this assignment pattern would reflect knowledge about a
resilient rendering method in use for the same
way that software that merges traditional excluded channels.

The MIDI 1.0 DIN cable flows is
responsible for creating a merged Program Change command flow compatible with [MIDI].

Senders MUST partition the name space so and several MIDI Control Change
controller numbers are assigned to ch_anchor. Note that the rendered MIDI
performance does not contain indefinite artifacts (as defined in Section
4). This responsibility holds even if all streams are sent over
reliable transport, as different stream latencies may yield indefinite
artifacts. For example, stuck notes may occur in a performance split
over two TCP streams, if NoteOn ordering
of the ch_anchor chapter C assignment after the ch_never command acts
to override the ch_never assignment for the listed controller numbers
(7 and 64).

The assignment of command-type X to cm_unused excludes most SysEx
commands from the stream. Exceptions are sent on one stream made for General MIDI
System On/Off commands and
NoteOff for the Master Volume and Balance
commands, via the use of the secondary assignment syntax. The
cm_used assignment codes the exception, and the ch_anchor assignment
codes how these commands are sent on protected in Chapter X.

C.3. Configuration Tools: Timestamp Semantics

The MIDI command section of the other.

Senders MUST NOT split payload format consists of a Registered Parameter Name (RPN) or Non-
Registered Parameter Name (NRPN) transaction appearing on list of
commands, each with an associated timestamp. The semantics of
command timestamps may be set during session configuration, using the
parameters we describe in this section

The parameter "tsmode" specifies the timestamp semantics for a MIDI channel

across multiple identity relationship sessions. Receivers MUST assume
stream. The parameter takes on one of three token values: "comex",
"async", or "buffer".

The default "comex" value specifies that timestamps code the RPN/NRPN transactions that appear on different identity
relationship sessions are independent,
execution time for a command (Appendix C.3.1) and MUST preserve transactional
integrity during supports the
accurate transcoding Standard MIDI merge.

A simple way to safely partition voice channel commands Files (SMFs, [MIDI]). The "comex"
value is to place all also RECOMMENDED for new MIDI commands user-interface controller
designs. The "async" value specifies an asynchronous timestamp
sampling algorithm for time-of-arrival sources (Appendix C.3.2). The
"buffer" value specifies a synchronous timestamp sampling algorithm
(Appendix C.3.3) for time-of-arrival sources.

Ancillary parameters MAY follow tsmode in a particular voice channel into media description. We
define these parameters in Appendices C.3.2-3 below.

C.3.1. The comex Algorithm

The default "comex" (COMmand EXecution) tsmode value specifies the same session.
Safe partitioning
execution time for the command. With comex, the difference between
two timestamps indicates the time delay between the execution of MIDI Systems commands the
commands. This difference may be more complicated zero, coding simultaneous
execution.

The comex interpretation of timestamps works well for
sessions that extensively use System Exclusive.

We now show several session description examples transcoding a
Standard MIDI File (SMF, [MIDI]) into an RTP MIDI stream, as SMFs
code a timestamp for each MIDI command stored in the file. To
transcode an SMF that uses metric time markers, use the musicport
parameter.

Our first session description example shows two SMF tempo map
(encoded in the SMF as meta-events) to convert metric SMF timestamp
units into seconds-based RTP timestamp units.

New MIDI streams controller designs (piano keyboard, drum pads, etc.) that
drive the same General
support RTP MIDI decoder. The sender partitions and that have direct access to sensor data SHOULD
use comex interpretation for timestamps, so that simultaneous
gestural events may be accurately coded by RTP MIDI.

Comex is a poor choice for transcoding MIDI
commands between the streams dynamically. The musicport values indicate
the streams share an identity relationship.

v=0
o=lazzaro 2520644554 2838152170 IN IP4 first.example.net
s=Example
t=0 0
a=group:FID 1 2
c=IN IP4 192.0.2.94
m=audio 5004 RTP/AVP 96
a=rtpmap:96 mpeg4-generic/44100
a=mid:1
a=fmtp:96 streamtype=5; mode=rtp-midi; profile-level-id=12;
config=7A0A0000001A4D546864000000060000000100604D54726B0
000000600FF2F000; musicport=12
m=audio 5006 RTP/AVP 96
a=rtpmap:96 mpeg4-generic/44100
a=mid:2
a=fmtp:96 streamtype=5; mode=rtp-midi; config=""; profile-level-id=12;
musicport=12

(The a=fmtp lines have been wrapped to fit the page to accommodate
memo formatting restrictions; they comprise single lines in SDP)

Recall that Section 2.1 in the main text defines rules 1.0 DIN cables [MIDI],
for streams that
target the same MIDI name space. Those rules, implemented in the
example above, require that each stream resides in a separate RTP
session, and reason that the grouping mechanisms defined in [RFC3388] signal an
inter-session relationship. The "group" and "mid" attribute lines
implement this grouping mechanism. we will now explain. A variant on this example, whose session description MIDI DIN cable is not shown, would
use two streams in an identity relationship driving the same
asynchronous serial protocol (320 microseconds per MIDI

renderer, each with byte). MIDI
commands on a different transport type. One stream would use
UDP, and would be dedicated to real-time messages. A second stream
would use TCP [CONTRANS] and would be used for SysEx bulk data messages.

In DIN cable are not tagged with timestamps. Instead,
MIDI DIN receivers infer command timing from the next example, time of arrival of
the bytes. Thus, two mpeg4-generic streams form an ordered
relationship to drive two-byte MIDI commands that occur at a Structured Audio decoder source
simultaneously are encoded on a MIDI 1.0 DIN cable with 32 a 640
microsecond time offset. A MIDI voice
channels. Both streams reside DIN receiver is unable to tell if
this time offset existed in the same RTP session.

v=0
o=lazzaro 2520644554 2838152170 IN IP6 first.example.net
s=Example
t=0 0
m=audio 5006 RTP/AVP 96 97
c=IN IP6 2001:DB80::7F2E:172A:1E24
a=rtpmap:96 mpeg4-generic/44100
a=fmtp:96 streamtype=5; mode=rtp-midi; config=""; profile-level-id=13;
musicport=5
a=rtpmap:97 mpeg4-generic/44100
a=fmtp:97 streamtype=5; mode=rtp-midi; config=""; profile-level-id=13;
musicport=6; render=synthetic; rinit="audio/asc";
url="http://example.com/cardinal.asc";
cid="azsldkaslkdjqpwojdkmsldkfpe"

(The a=fmtp lines have been wrapped to fit source performance or is an artifact
of the page to accommodate
memo formatting restrictions; they comprise single lines in SDP)

The sequential musicport values for serial speed of the cable. However, the RTP MIDI comex
interpretation of timestamps declares that a timestamp offset between
two sessions establishes commands reflects the
ordered relationship. The musicport=5 session maps to Structured Audio
extended channels range 0-15, timing of the musicport=6 session maps to Structured
Audio extended channels range 16-31.

Both config strings are empty. The configuration data source performance.

This semantic mismatch is specified by
parameters the reason that comex is a poor choice for
transcoding MIDI DIN cables. Note that appear in the fmtp line choice of the second media description.
We define this configuration method RTP
timestamp rate (Section 6.1-2 in Appendix C.6.

The next example shows the main text) cannot fix this
inaccuracy issue. In the sections that follow, we describe two RTP MIDI streams (one recvonly, one sendonly)
alternative timestamp interpretations ("async" and "buffer") that form a "virtual sendrecv" session. Each stream resides in are
a
different RTP session (a requirement because sendonly better match to MIDI 1.0 DIN cable timing, and recvonly are
RTP session attributes).

v=0
o=lazzaro 2520644554 2838152170 IN IP4 first.example.net
s=Example
t=0 0
a=group:FID 1 2
c=IN IP4 192.0.2.94
m=audio 5004 RTP/AVP 96
a=sendonly
a=rtpmap:96 mpeg4-generic/44100
a=mid:1
a=fmtp:96 streamtype=5; mode=rtp-midi; profile-level-id=12;
config=7A0A0000001A4D546864000000060000000100604D54726B0
000000600FF2F000; musicport=12
m=audio 5006 RTP/AVP 96
a=recvonly
a=rtpmap:96 mpeg4-generic/44100
a=mid:2
a=fmtp:96 streamtype=5; mode=rtp-midi; profile-level-id=12;
config=7A0A0000001A4D546864000000060000000100604D54726B0
000000600FF2F000; musicport=12

(The a=fmtp lines have been wrapped to fit the page to accommodate
memo formatting restrictions; they comprise single lines in SDP)

To signal the "virtual sendrecv" semantics, the two streams assign
musicport to the same other MIDI time-
of-arrival sources.

The "octpos", "linerate", and "mperiod" ancillary parameters (defined
below) SHOULD NOT be used with comex.

C.3.2. The async Algorithm

The "async" tsmode value (12). As defined earlier in this section,
pairs specifies the asynchronous sampling of identity relationship streams that are sent by different
parties share a
MIDI time-of-arrival source. In asynchronous sampling, the association that moment an
octet is shared by received from a MIDI cable pair that
cross-connects two devices in source, it is labelled with a MIDI 1.0 network. We use wall-clock
time value. The time value has RTP timestamp units.

The "octpos" ancillary parameter defines how RTP command timestamps
are derived from octet time values. If octpos has the term
"virtual sendrecv" because streams sent by different parties in token value
"first", a true
sendrecv session also have this property.

As discussed in timestamp codes the preamble to Appendix C, time value of the primary advantage first octet of the
virtual sendrecv configuration is that each party can customize
command. If octpos has the
property of token value "last", a timestamp codes the stream it receives. In
time value of the example above, each stream
defines its own "config" string that could customize last octet of the rendering
algorithm for each party (in fact, command. If the particular strings shown octpos parameter
does not appear in this
example are identical, because General MIDI is the media description, the sender does not a configurable MPEG 4
renderer).

C.6 Configuration Tools: MIDI Rendering

This Appendix defines know
which octet of the session configuration tools for rendering. command the timestamp references (for example, the
sender may be relying on an operating system service that does not
specify this information).

The "render" parameter specifies a rendering method for octpos semantics refer to the first or last octet of a stream. The
parameter is assigned command as
it appears on a token value that signals the top-level rendering
class. time-of-arrival MIDI source, not as it appears in an
RTP MIDI packet. This memo defines four token values for render: "unknown",
"synthetic", "api", and "null":

o An "unknown" renderer is a renderer whose nature is unspecified.
It distinction is significant because the default renderer for native RTP
coding may contain octets that are not present in the source. For
example, the status octet of the first MIDI streams.

o A "synthetic" renderer transforms command in a packet may
have been added to the MIDI stream into audio
output (or sometimes, into stage lighting changes or other
actions). It is during transcoding, to comply with
the default renderer for mpeg4-generic RTP MIDI streams.

o An "api" renderer presents the command stream to applications
via an Application Programmer Interface (API).

o running status requirements (Section 3.2).

The "null" renderer discards "linerate" ancillary parameter defines the timespan of one MIDI stream.

The "null" render value plays special roles during Offer/Answer
negotiations [RFC3264]. A party uses
octet on the "null" value in an answer transmission medium of the MIDI source to
reject an offered renderer. Note that rejecting be sampled
(such as a renderer MIDI 1.0 DIN cable). The parameter has units of
nanoseconds, and takes on integral values. For MIDI 1.0 DIN cables,
the correct linerate value is
independent from rejecting 320000 (this value is also the default
value for the parameter).

We now show a payload type (coded by by removing session description example for the
payload type from async algorithm.
Consider a media line) and rejecting sender that is transcoding a media stream (coded by
zeroing the port of MIDI 1.0 DIN cable source
into RTP. The sender runs on a media line computing platform that assigns time
values to every incoming octet of the source, and the sender uses the renderer).

Other render token
time values MAY be registered with IANA. to label the first octet of each command in the RTP
packet. This session description describes the transcoding:

C.3.3. The token buffer Algorithm

The "buffer" tsmode value
MUST adhere to specifies the ABNF for render tokens defined synchronous sampling of a
MIDI time-of-arrival source.

In synchronous sampling, octets received from a source are placed in Appendix D.
Registrations MUST include
a holding buffer upon arrival. At periodic intervals, the RTP sender
examines the buffer. The sender removes complete specification of parameter value
usage, similar commands from the
buffer and codes those commands in depth to an RTP packet. The command
timestamp codes the specifications moment of buffer examination, expressed in RTP
timestamp units. Note that appear throughout several commands may have the same
timestamp value.

The "mperiod" ancillary parameter defines the nominal periodic
sampling interval. The parameter takes on positive integral values
and has RTP timestamp units.

The "octpos" ancillary parameter, defined in Appendix C.6 C.3.1 for "synthetic" and "api" render values. If a party is
offered
asynchronous sampling, plays a session description that uses different role in synchronous
sampling. In synchronous sampling, the parameter specifies the
timestamp semantics of a render command whose octets span several sampling
periods.

If octpos has the token value that is not
known to "first", the party, timestamp reflects the party MUST NOT accept
arrival period of the renderer. Options
include rejecting first octet of the renderer (using command. If octpos has the "null" value),
token value "last", the payload
type, timestamp reflects the media stream, or arrival period of the session description.

Other parameters MAY follow a render parameter in a parameter list.
last octet of the command. The
additional parameters act octpos semantics refer to define the exact nature first
or last octet of the renderer.
For example, command as it appears on a time-of-arrival
source, not as it appears in the "subrender" RTP packet.

If the octpos parameter (defined does not appear in Appendix C.6.2)
specifies the exact nature media description, the
timestamp MAY reflect the arrival period of any octet of the renderer.

Special rules apply command;
senders use this option to using signal a lack of knowledge about the render parameter in an mpeg4-generic
stream.
timing details of the buffering process at sub-command granularity.

We define these rules in Appendix C.6.5.

C.6.1 The multimode Parameter

A media now show a session description MAY contain several render parameters. By default,
if example for the buffer algorithm.
Consider a parameter lists includes several render parameters, sender that is transcoding a receiver MUST
choose exactly one renderer from MIDI 1.0 DIN cable source
into RTP. The sender runs on a computing platform that places source
data into a buffer upon receipt. The sender polls the list to render buffer 1000
times a second, extracts all complete commands from the stream. The
"multimode" parameter may be used to override this default. We define
two token values for multimode: "one" buffer, and "all":

o
places the commands in an RTP packet. This session description
describes the transcoding:

The default "one" mperiod value requests rendering by exactly one of 44 is derived by dividing the listed renderers.

o The "all" value requests clock rate
specified by the synchronized rendering rtpmap attribute (44100 Hz) by the 1000 Hz buffer
sampling rate and rounding to the nearest integer. Command
timestamps might not increment by exact multiples of 44, as the RTP
actual sampling period might not precisely match the nominal mperiod
value.

C.4. Configuration Tools: Packet Timing Tools

In this appendix, we describe session configuration tools for
customizing the temporal behavior of MIDI stream packets.

C.4.1. Packet Duration Tools

Senders control the granularity of a stream by all listed renderers, if possible.

If setting the multimode parameter appears temporal
duration ("media time") of the packets in a parameter list, it MUST appear
before the first render parameter assignment.

Render parameters appear stream. Short media
times (20 ms or less) often imply an interactive session. Longer
media times (100 ms or more) usually indicate a content streaming
session. The RTP AVP profile [RFC3551] recommends audio packet media
times in a range from 0 to 200 ms.

By default, an RTP receiver dynamically senses the parameter list media time of
packets in order a stream and chooses the length of decreasing
priority. its playout buffer to
match the stream. A receiver typically sizes its playout buffer to
fit several audio packets and adjusts the buffer length to reflect
the network jitter and the sender timing fidelity.

Alternatively, the packet media time may be statically set during
session configuration. Session descriptions MAY use the priority ordering to decide which
renderer(s) RTP MIDI
parameter "rtp_ptime" to retain in a session.

If set the "offer" in an Offer/Answer-style negotiation [RFC3264] contains recommended media time for a
parameter list with one or more render parameters, packet.
Session descriptions MAY also use the "answer" MUST RTP MIDI parameter
"rtp_maxptime" to set the render parameters of all unchosen renderers to "null".

C.6.2 Renderer Specification

The render parameter (Appendix C.6 preamble) specifies, in maximum media time for a broad
sense, what packet permitted
in a renderer does with stream. Both parameters MAY be used together to configure a MIDI
stream. In this Appendix, we
describe the "subrender" parameter.

The token value values assigned to
subrender defines the exact nature of the renderer. Thus, "render" rtp_ptime and
"subrender" combine to define a renderer, in rtp_maxptime parameters have
the same way as MIME types
and MIME subtypes combine to define a type units of media [RFC2045].

If the subrender parameter is used RTP timestamp for a renderer definition, it MUST
appear immediately after the render parameter in stream, as set by the parameter list. At
most one subrender parameter may appear in rtpmap
attribute (see Section 6.1). Thus, if rtpmap sets the clock rate of
a renderer definition.

This document defines one value for subrender: stream to 44100 Hz, a maximum packet media time of 10 ms is coded
by setting rtp_maxptime=441. As stated in the value "default". The
"default" token specifies Appendix C preamble,
the use senders and receivers of a stream MUST agree on common values for
rtp_ptime and rtp_maxptime if the parameters appear in the default renderer media
description for the
stream type (native or mpeg4-generic). The default renderer for native
RTP MIDI streams stream.

0 ms is a renderer whose nature reasonable media time value for MIDI packets and is unspecified (see point 6 often
used in Section 6.1 low-latency interactive applications. In a packet with a 0
ms media time, all commands execute at the instant they are coded by
the packet timestamp. The session description below configures all
packets in the main text for details). stream to have 0 ms media time:

v=0
o=lazzaro 2520644554 2838152170 IN IP4 first.example.net
s=Example
t=0 0
m=audio 5004 RTP/AVP 96
c=IN IP4 192.0.2.94
a=rtpmap:96 rtp-midi/44100
a=fmtp:96 rtp_ptime=0; rtp_maxptime=0
The default renderer for
mpeg4-generic session attributes ptime and maxptime [RFC4566] MUST NOT be used
to configure an RTP MIDI streams is an MPEG 4 Audio Object Type whose ID
number is 13, 14, or 15 (see Section 6.2 stream. Sessions MUST use rtp_ptime in the main text for details).

If a renderer definition does not lieu
of ptime and MUST use the subrender parameter, the value
"default" is assumed rtp_maxptime in lieu of maxptime. RTP MIDI
defines its own parameters for subrender.

Other subrender token media time configuration because 0 ms
values may be registered with IANA. We now
discuss guidelines for registering subrender values.

A subrender value is registered for a specific stream type (native or
mpeg4-generic) ptime and a specific render value (excluding "null" maxptime are forbidden by [RFC3264] but are
essential for certain applications of RTP MIDI.

See the Appendix C.7 examples for additional discussion about using
rtp_ptime and
"unknown"). Registrations rtp_maxptime for mpeg4-generic subrender values are
restricted to new MPEG 4 Audio Object Types that accept MIDI input. session configuration.

C.4.2. The
syntax guardtime Parameter

RTP permits a sender to stop sending audio packets for an arbitrary
period of time during a session. When sending resumes, the token MUST adhere to RTP
sequence number series continues unbroken, and the token definition in Appendix D.

For "render=synthetic" renderers, a subrender RTP timestamp
value registration
specifies an exact method for transforming reflects the media time silence gap.

This RTP feature has its roots in telephony, but it is also well
matched to interactive MIDI stream into audio
(or sometimes, into video or control actions, such sessions, as stage lighting).
For standardized renderers, this specification is usually players may fall silent for
several seconds during (or between) songs.

Certain MIDI applications benefit from a pointer slight enhancement to a
standards document, perhaps supplemented by RTP-MIDI specific
information. For commercial products and open-source projects, this
specification usually takes the form of instructions
RTP feature. In interactive applications, receivers may use on-line
network models to guide heuristics for interfacing the handling lost and late RTP MIDI stream with the product or project software. A
"render=synthetic" registration MAY specify additional Reset State
commands
packets. These models may work poorly if a sender ceases packet
transmission for long periods of time.

Session descriptions may use the renderer (Appendix A.1).

A "render=api" subrender parameter "guardtime" to set a
minimum sending rate for a media session. The value registration specifies how an assigned to
guardtime codes the maximum separation time between two sequential
packets, as expressed in RTP MIDI
stream interfaces with an API (Application Programmers Interface). timestamp units.

Typical guardtime values are 500-2000 ms. This
specification value range is usually not a pointer to programmer's documentation for the
API, perhaps supplemented by RTP-MIDI specific information.

A subrender registration MAY specify an initialization file (referred
normative bound, and parties SHOULD be prepared to
in process values
outside this document as an initialization data object) for the stream. range.

The
initialization data object MAY be encoded congestion control requirements for sender implementations
(described in Section 8 and [RFC3550]) take precedence over the parameter list
(verbatim or by reference) using
guardtime parameter. Thus, if the coding tools defined in Appendix
C.6.3. An initialization data object MUST have guardtime parameter requests a registered [MTYPE]
media type and subtype [RFC2045].

For "render=synthetic" renderers, the data object usually encodes
initialization data for
minimum sending rate, but sending at this rate would violate the renderer (sample files, synthesis patch
parameters, reverberation room impulse responses, etc).

For "render=api" renderers,
congestion control requirements, senders MUST ignore the data object usually encodes data about guardtime
parameter value. In this case, senders SHOULD use the stream used by lowest minimum
sending rate that satisfies the API (for example, for an RTP MIDI stream
generated by congestion control requirements.

Below, we show a piano keyboard controller, the manufacturer and model
number of session description that uses the keyboard, for use guardtime
parameter.

C.5. Configuration Tools: Stream Description

As we discussed in GUI presentation).

Usually, only one initialization object is encoded for a renderer. If Section 2.1, a
renderer uses multiple data objects, the correct receiver interpretation
of multiple data objects MUST be defined party may send several RTP MIDI
streams in the subrender registration.

A subrender value registration same RTP session, and several RTP sessions that carry
MIDI may also specify additional parameters,
to appear in a multimedia session.

By default, the parameter list immediately after subrender. These
parameter names MUST begin with the subrender value followed by an

underscore ("_"), to avoid MIDI name space collisions with future (16 channels + systems) of each RTP MIDI
parameter names (example:
stream sent by a parameter "foo_bar" defined for subrender
value "foo").

We now specify guidelines for interpreting the subrender parameter
during party in a multimedia session configuration. is independent. By
independent, we mean three distinct things:

o If a party sends two RTP MIDI streams (A and B), MIDI voice
channel 0 in stream A is offered a session description that uses a renderer whose
subrender value different "channel 0" than MIDI voice
channel 0 in stream B.

o MIDI voice channel 0 in stream B is not known considered to the party, the party MUST NOT accept the
renderer. Options include rejecting the renderer (using the "null"
value), the payload type, the media stream, or the session description.

Receivers MUST be aware
"channel 16" of a 32-channel MIDI voice channel space whose
"channel 0" is channel 0 of stream A.

o Streams sent by different parties over different RTP sessions,
or over the Reset State commands (Appendix A.1) for same RTP session but with different payload type
numbers, do not share the renderer specified association that is shared by a MIDI
cable pair that cross-connects two devices in a MIDI 1.0 DIN
network. By default, this association is only held by streams
sent by different parties in the subrender parameter, and MUST insure same RTP session that use the renderer does not experience indefinite artifacts due
same payload type number.

In this appendix, we show how to the
presence (or the loss) of a Reset State command.

C.6.3 Renderer Initialization

If the renderer for express that specific RTP MIDI
streams in a stream uses an initialization data object, an
"rinit" parameter MUST appear multimedia session are not independent but instead are
related in one of the parameter list immediately after
the "subrender" three ways defined above. We use two tools to
express these relations:

o The musicport parameter. If the renderer This parameter list does not
include is assigned a subrender parameter (recall the semantics for "default" non-
negative integer value between 0 and 4294967295. It appears in
Appendix C.6.2), the "rinit" parameter MUST appear immediately after
the
"render" parameter. fmtp lines of payload types.

o The value assigned to FID grouping attribute [RFC3388] signals that several RTP
sessions in a multimedia session are using the rinit musicport
parameter MUST be the media type/subtype
[RFC2045] for the initialization data object. If to express an initialization
object type is registered with inter-session relationship.

If a multimedia session has several media types, including audio, payload types whose musicport
parameters are assigned the
assignment to rinit MUST same integer value, streams using these
payload types share an "identity relationship" (including streams
that use the audio media type.

RTP MIDI supports several parameters for encoding initialization data
objects for renderers same payload type). Streams in an identity relationship
share two properties:

o Identity relationship streams sent by the parameter list: "inline", "url", same party target the
same MIDI name space. Thus, if streams A and "cid".

If B share an
identity relationship, voice channel 0 in stream A is the "inline", "url", and/or "cid" parameters same
"channel 0" as voice channel 0 in stream B.

o Pairs of identity relationship streams that are used sent by a renderer,
these parameters MUST immediately follow
different parties share the "rinit" parameter.

If association that is shared by a "url" parameter appears for MIDI
cable pair that cross-connects two devices in a renderer, an "inline" parameter MIDI 1.0 DIN
network.

A party MUST NOT appear. If send two RTP MIDI streams that share an "inline" parameter appears identity
relationship in the same RTP session. Instead, each stream MUST be
in a separate RTP session. As explained in Section 2.1, this
restriction is necessary to support the RTP MIDI method for the
synchronization of streams that share a renderer, MIDI name space.

If a "url"
parameter MUST NOT appear. However, neither "url" or "inline" multimedia session has several payload types whose musicport
parameters are
required to appear. If neither "url" or "inline" parameters follow
"rinit", the "cid" parameter MUST follow "rinit".

The "inline" parameter supports the inline encoding of the data object.
The parameter is assigned a double-quoted Base64 [RFC2045] encoding of sequential values (i.e., i, i+1, ... i+k),
the binary data object, with no line breaks. Appendix E.4 shows streams using the payload types share an
example that constructs "ordered relationship".
For example, if payload type A assigns 2 to musicport and payload
type B assigns 3 to musicport, A and B are in an inline parameter value.

The "url" parameter is assigned a double-quoted string representation of
a Uniform Resource Locator (URL) for ordered
relationship.

Streams in an ordered relationship that are sent by the data object. The string MUST
specify same party
are considered by renderers to form a HyperText Transport Protocol URL (HTTP, [RFC2616]). HTTP MAY
be used over TCP, or MAY be used over single larger MIDI space. For
example, if stream A has a secure network transport, such
as the method described musicport value of 2 and stream B has a
musicport value of 3, MIDI voice channel 0 in [RFC2818]. The media type/subtype for the
data object SHOULD stream B is considered
to be specified voice channel 16 in the appropriate HTTP transport
header.

The "cid" parameter supports data object caching. The parameter is
assigned a double-quoted string value larger MIDI space formed by the
relationship. Note that encodes a globally unique
identifier it is possible for the data object.

A cid parameter MAY immediately follow streams to participate in
both an inline parameter, identity relationship and an ordered relationship.

We now state several rules for using musicport:

o If streams from several RTP sessions in which
case a multimedia session use
the cid identifier value musicport parameter, the RTP sessions MUST be associated with grouped using
the inline data
object.

If a url parameter is present, FID grouping attribute defined in [RFC3388].

o An ordered or identity relationship MUST NOT contain both native
RTP MIDI streams and mpeg4-generic RTP MIDI streams. An
exception applies if a relationship consists of sendonly and
recvonly (but not sendrecv) streams. In this case, the data object for sendonly
streams MUST NOT contain both types of streams, and the URL recvonly
streams MUST NOT contain both types of streams.

o It is

expected possible to be unchanged for the life of construct identity relationships that violate
the URL, recovery journal mandate (for example, sending NoteOns for a cid parameter MAY
immediately follow
voice channel on stream A and NoteOffs for the url parameter. The cid identifier value same voice
channel on stream B). Parties MUST NOT generate (or accept)
session descriptions that exhibit this flaw.

o Other payload formats MAY define musicport media type
parameters. Formats would define these parameters so that their
sessions could be
associated with the data object for the URL. A cid bundled into RTP MIDI name spaces. The
parameter assigned
to the same identifier value SHOULD definitions MUST be specified following compatible with the data
object type/subtype musicport
semantics defined in the appropriate HTTP transport header.

If this appendix.

As a url parameter is present, and if rule, at most one payload type in a relationship may specify a
MIDI renderer. An exception to the data object for the URL is
expected rule applies to change during the life of the URL, a cid parameter MUST NOT
follow the url parameter. A receiver interprets the presence of a cid
parameter as an indication that it is safe use a cached copy of the url
data object; the absence of a cid parameter is an indication relationships
that it is
not safe to use a cached copy, as it may change.

Finally, the cid parameter MAY be used without the inline contain sendonly and url
parameters. recvonly streams but no sendrecv streams.
In this case, the identifier references a local or
distributed catalog of data objects.

In most cases, only one data object is coded in the parameter list for sendonly session and one recvonly session may each
define a renderer. For example,

Renderer specification in a relationship may be done using the default renderer tools
described in Appendix C.6. These tools work for mpeg4-generic both native streams
and mpeg4-generic streams. An mpeg4-generic stream that uses a single data object (see Appendix C.6.5 for example
usage).

However, a subrender registration MAY permit the use of multiple data
objects for a renderer. If multiple data objects are encoded for a
renderer, each object encoding begins with an "rinit" parameter,
followed by "inline", "url", and/or "cid" parameters.

Initialization data object MAY encapsulate a Standard MIDI File (SMF).
By default, the SMFs that are encapsulated in a data object
Appendix C.6 tools MUST be
ignored by an RTP MIDI receiver. We define set all "config" parameters to override this
default in Appendix C.6.4.

To end this section, we offer guidelines for registering media types the empty
string ("").

Alternatively, for
initialization data objects. These guidelines are mpeg4-generic streams, renderer specification may
be done by setting one "config" parameter in addition the relationship to the
information in [RFC2048].

Some initialization data objects are also capable of encoding MIDI note
information,
renderer configuration string, and thus complete audio performances. These objects SHOULD
be registered using all other config parameters to the "audio" media type, so
empty string ("").

We now define sender and receiver rules that apply when a party sends
several streams that target the objects may also
be used for store-and-forward rendering, and "application" media type,
to support editing tools. Initialization objects without note storage,
or initialization objects for non-audio renderers, SHOULD be registered
only for an "application" media type.

C.6.4 MIDI Channel Mapping

In this Appendix, we specify how to map same MIDI name spaces (16 voice
channels + systems) onto a renderer.

In space.

Senders MAY use the general case:

o A session may define an ordered relationship subsetting parameters (Appendix C.5)
that presents more than one MIDI name space C.1) to a renderer.

o A renderer may accept an arbitrary number predefine
the partitioning of MIDI name spaces, commands between streams, or may expect they MAY use a specific number of MIDI name spaces.

A session description SHOULD provide
dynamic partitioning strategy.

Receivers that merge identity relationship streams into a compatible single MIDI name space to
command stream MUST maintain the structural integrity of the MIDI
commands coded in each renderer stream during the merging process, in the session. If a receiver detects same
way that a session
description has too many or too few software that merges traditional MIDI name spaces for 1.0 DIN cable flows is
responsible for creating a renderer,
MIDI data from extra stream name spaces merged command flow compatible with
[MIDI].

Senders MUST be discarded, and extra
renderer partition the name spaces MUST NOT be driven with space so that the rendered MIDI data (except
performance does not contain indefinite artifacts (as defined in
Section 4). This responsibility holds even if all streams are sent
over reliable transport, as
described different stream latencies may yield
indefinite artifacts. For example, stuck notes may occur in Appendix C.6.4.1 below).

If a parameter list defines several renderers
performance split over two TCP streams, if NoteOn commands are sent
on one stream and assigns NoteOff commands are sent on the "all"
token value to other.

Senders MUST NOT split a Registered Parameter Name (RPN) or Non-
Registered Parameter Name (NRPN) transaction appearing on a MIDI
channel across multiple identity relationship sessions. Receivers
MUST assume that the multimode parameter, RPN/NRPN transactions that appear on different
identity relationship sessions are independent and MUST preserve
transactional integrity during the same name space MIDI merge.

A simple way to safely partition voice channel commands is presented to each renderer. However, place
all MIDI commands for a particular voice channel into the "chanmask" parameter same
session. Safe partitioning of MIDI Systems commands may be used to mask
out selected voice channels to each renderer. more
complicated for sessions that extensively use System Exclusive.

We define "chanmask" and
other now show several session description examples that use the
musicport parameter.

Our first session description example shows two RTP MIDI management parameters in streams that
drive the sub-sections below.

C.6.4.1 same General MIDI decoder. The smf_info Parameter sender partitions MIDI
commands between the streams dynamically. The smf_info parameter defines musicport values
indicate that the use of streams share an identity relationship.

(The a=fmtp lines have been wrapped to fit the SMFs encapsulated page to accommodate
memo formatting restrictions; they comprise single lines in
renderer data objects (if any). The smf_info parameter also SDP.)

Recall that Section 2.1 defines rules for streams that target the
use of SMFs coded in the smf_inline, smf_url, and smf_cid parameters
(defined
same MIDI name space. Those rules, implemented in Appendix C.6.4.2).

The smf_info parameter describes the "render" parameter example above,
require that most
recently precedes it each stream resides in a separate RTP session, and that
the parameter list. The smf_info parameter MUST
NOT appear grouping mechanisms defined in parameter lists that do [RFC3388] signal an inter-session
relationship. The "group" and "mid" attribute lines implement this
grouping mechanism.

A variant on this example, whose session description is not shown,
would use two streams in an identity relationship driving the "render" parameter, same
MIDI renderer, each with a different transport type. One stream
would use UDP and MUST NOT appear before the first would be dedicated to real-time messages. A second
stream would use of "render" in the parameter
list.

We define three token values for smf_info: "ignore", "sdp_start", TCP [RFC4571] and
"identity":

o The "ignore" value indicates that the SMFs MUST would be discarded.
This behavior is the default SMF rendering behavior.

o The "sdp_start" value codes that SMFs MUST be rendered,
and that the rendering MUST begin upon the acceptance of used for SysEx bulk data
messages.

In the session description. If a receiver is offered a session
description with a renderer that uses next example, two mpeg4-generic streams form an smf_info parameter
set to sdp_start, and if the receiver does not support
rendering SMFs, the receiver MUST NOT accept the renderer
associated with the smf_info parameter. Options include
rejecting the renderer (by setting the "render" parameter ordered
relationship to "null"), the payload type, the media stream, or the
entire session description.

o The "identity" value indicates the SMFs code the identity
of the renderer. The value is meant for use drive a Structured Audio decoder with the
"unknown" renderer (see Appendix C.6 preamble). The 32 MIDI commands
coded voice
channels. Both streams reside in the SMF are informational in nature, and MUST NOT be
presented same RTP session.

v=0
o=lazzaro 2520644554 2838152170 IN IP6 first.example.net
s=Example
t=0 0
m=audio 5006 RTP/AVP 96 97
c=IN IP6 2001:DB80::7F2E:172A:1E24
a=rtpmap:96 mpeg4-generic/44100
a=fmtp:96 streamtype=5; mode=rtp-midi; config="";
profile-level-id=13; musicport=5
a=rtpmap:97 mpeg4-generic/44100
a=fmtp:97 streamtype=5; mode=rtp-midi; config="";
profile-level-id=13; musicport=6; render=synthetic;
rinit="audio/asc";
url="http://example.com/cardinal.asc";
cid="azsldkaslkdjqpwojdkmsldkfpe"

(The a=fmtp lines have been wrapped to a renderer for audio presentation. In
typical use, fit the SMF would use SysEx Identity Reply
commands (F0 7E nn 06 02, as defined in [MIDI]) to identify
devices, and use device-specific SysEx commands page to describe
current state of the devices (patch memory contents, etc).

Other smf_info token accommodate
memo formatting restrictions; they comprise single lines in SDP.)

The sequential musicport values MAY be registered with IANA. for the two sessions establish the
ordered relationship. The token
value MUST adhere musicport=5 session maps to Structured
Audio extended channels range 0-15, the ABNF for render tokens defined in Appendix D.
Registrations MUST include a complete specification of parameter usage,
similar in depth musicport=6 session maps to the specifications
Structured Audio extended channels range 16-31.

Both config strings are empty. The configuration data is specified
by parameters that appear in this Appendix for
"sdp_start" and "identity".

If a party is offered a session description that uses an smf_info
parameter value that is not known to the party, the party MUST NOT
accept the renderer associated with the smf_info parameter. Options
include rejecting the renderer, the payload type, fmtp line of the second media stream, or
the entire session
description. We now define the rendering semantics for the "sdp_start" token value this configuration method in
detail. Appendix C.6.

The SMFs and next example shows two RTP MIDI streams in a session description share the same
MIDI name space(s). In the simple case of (one recvonly, one
sendonly) that form a single RTP MIDI "virtual sendrecv" session. Each stream and
a single SMF, the SMF MIDI commands and RTP MIDI commands are merged
into a single name space and presented to the renderer. The indefinite
artifact responsibilities for merged MIDI streams defined
resides in Appendix
C.5 also apply to merging a different RTP session (a requirement because sendonly
and SMF MIDI data.

If a payload type codes multiple SMFs, the SMF name spaces recvonly are presented
as an ordered entity to the renderer. To determine the ordering of SMFs
for a renderer (which SMF is "first", which is "second", etc), use the
following rules:

o If RTP session attributes).

(The a=fmtp lines have been wrapped to fit the renderer uses a page to accommodate
memo formatting restrictions; they comprise single data object, the order of
appearance of the SMFs lines in SDP.)

To signal the object's internal structure
defines "virtual sendrecv" semantics, the order of two streams assign
musicport to the SMFs (the earliest SMF same value (12). As defined earlier in this
section, pairs of identity relationship streams that are sent by
different parties share the object association that is "first", the next SMF shared by a MIDI
cable pair that cross-connects two devices in the object is "second", etc).

o If multiple data objects are encoded for a renderer, MIDI 1.0 network. We
use the
appearance of each data object term "virtual sendrecv" because streams sent by different
parties in a true sendrecv session also have this property.

As discussed in the parameter list
sets preamble to Appendix C, the relative order primary advantage of
the SMFs encoded in each
data object (SMFs encoded in parameters that appear
earlier in the list are ordered before SMFs encoded
in parameters virtual sendrecv configuration is that appear later in the list).

o If SMFs are encoded in data objects parameters and in
the parameters defined in C.6.4.2, each party can customize
the relative order property of the data object parameters and C.6.4.2 parameters
in the parameter list sets stream it receives. In the relative order of SMFs
(SMFs encoded in parameters example above, each
stream defines its own "config" string that appear earlier in could customize the
list are ordered before SMFs in parameters that appear
later in
rendering algorithm for each party (in fact, the list).

Given particular strings
shown in this ordering of SMFs, we now define example are identical, because General MIDI is not a
configurable MPEG 4 renderer).

C.6. Configuration Tools: MIDI Rendering

This appendix defines the mapping of SMFs to
renderer name spaces. session configuration tools for rendering.

The SMF that appears first "render" parameter specifies a rendering method for a renderer maps to
the first renderer name space. stream.
The SMF parameter is assigned a token value that appears second signals the top-level
rendering class. This memo defines four token values for render:
"unknown", "synthetic", "api", and "null":

o An "unknown" renderer is a renderer maps to whose nature is unspecified.
It is the second default renderer name space, etc. If the associated for native RTP MIDI streams also form an ordered relationship, streams.

o A "synthetic" renderer transforms the first SMF MIDI stream into audio
output (or sometimes into stage lighting changes or other
actions). It is
merged with the first name space of the relationship, default renderer for mpeg4-generic RTP MIDI
streams.

o An "api" renderer presents the second SMF is
merged command stream to applications
via an Application Programmer Interface (API).

o The "null" renderer discards the second name space of the relationship, etc.

Unless the streams and the SMFs both use MIDI Time Code, the time offset
between SMF and stream data is unspecified. This restriction limits stream.

The "null" render value plays special roles during Offer/Answer
negotiations [RFC3264]. A party uses the
use of SMFs "null" value in an answer
to applications where synchronization is not critical, such
as the transport of System Exclusive commands for renderer
initialization, or human-SMF interactivity.

Finally, we note reject an offered renderer. Note that each SMF in rejecting a renderer is
independent from rejecting a payload type (coded by removing the sdp_start discussion above encodes
exactly one MIDI name space (16 voice channels + systems). Thus,
payload type from a media line) and rejecting a media stream (coded
by zeroing the
use port of a media line that uses the Device Name SMF meta event to specify several MIDI name
spaces in an SMF is not supported for sdp_start.

C.6.4.2 renderer).

Other render token values MAY be registered with IANA. The smf_inline, smf_url, and smf_cid Parameters

In some applications, the renderer data object may not encapsulate SMFs,
but an application may wish token
value MUST adhere to use SMFs in the manner ABNF for render tokens defined in Appendix C.6.4.1.

The "smf_inline", "smf_url", and "smf_cid" parameters address this
situation. These parameters use the syntax and semantics
D. Registrations MUST include a complete specification of the inline,
url, and cid parameters defined parameter
value usage, similar in depth to the specifications that appear
throughout Appendix C.6.3, except C.6 for "synthetic" and "api" render values. If
a party is offered a session description that uses a render token
value that the
encoded data object is an SMF.

The "smf_inline", "smf_url", and "smf_cid" parameters belong not known to the
"render" parameter that most recently precedes it in party, the party MUST NOT accept the
renderer. Options include rejecting the renderer (using the "null"
value), the payload type, the media stream, or the session
description. The "smf_inline", "smf_url", and "smf_cid"

Other parameters MUST
NOT appear MAY follow a render parameter in a parameter lists that do not use the "render" parameter,
and MUST NOT appear before list.
The additional parameters act to define the first use exact nature of "render" in the
renderer. For example, the "subrender" parameter
list. If several "smf_inline", "smf_url", or "smf_cid" parameters

appear for a renderer, (defined in
Appendix C.6.2) specifies the order exact nature of the parameters defines renderer.

Special rules apply to using the SMF name
space ordering.

C.6.4.3 render parameter in an mpeg4-generic
stream. We define these rules in Appendix C.6.5.

C.6.1. The chanmask multimode Parameter

The chanmask

A media description MAY contain several render parameters. By
default, if a parameter instructs the list includes several render parameters, a
receiver MUST choose exactly one renderer from the list to ignore all MIDI voice
commands for certain channel numbers. render the
stream. The "multimode" parameter value is a
concatenated string of "1" and "0" digits. Each string position maps to
a MIDI voice channel number (system channels may not be masked). A "1"
instructs the renderer to process the voice channel; a "0" instructs the
renderer used to ignore the voice channel. override this
default. We define two token values for multimode: "one" and "all":

o The string length default "one" value requests rendering by exactly one of the chanmask parameter
listed renderers.

o The "all" value MUST be 16 (for a
single stream or an identity relationship) or a multiple requests the synchronized rendering of 16 (for an
ordered relationship).

The chanmask parameter describes the "render" parameter that most
recently precedes it in RTP
MIDI stream by all listed renderers, if possible.

If the session description; chanmask MUST NOT
appear multimode parameter appears in a parameter lists that do not use the "render" parameter, and list, it MUST NOT
appear before the first use of "render" render parameter assignment.

Render parameters appear in the parameter list.

The chanmask parameter describes the final MIDI name spaces presented to
the renderer. The SMF and stream components list in order of decreasing
priority. A receiver MAY use the MIDI name spaces may
not be independently masked.

If priority ordering to decide which
renderer(s) to retain in a receiver is offered session.

If the "offer" in an Offer/Answer-style negotiation [RFC3264]
contains a session description parameter list with a renderer that uses
the chanmask parameter, and if the receiver does not implement the
semantics of the chanmask parameter, one or more render parameters, the receiver
"answer" MUST NOT accept the
renderer unless set the chanmask parameter value contains only "1"'s.

C.6.5 render parameters of all unchosen renderers to
"null".

C.6.2. Renderer Specification

The audio/asc Media Type render parameter (Appendix C.6 preamble) specifies, in a broad
sense, what a renderer does with a MIDI stream. In Appendix H.3, this appendix, we register
describe the audio/asc media type. "subrender" parameter. The data object
for audio/asc is a binary encoding token value assigned to
subrender defines the exact nature of the AudioSpecificConfig data block
used to initialize mpeg4-generic streams (Section 6.2 renderer. Thus, "render"
and [MPEGAUDIO]).

An mpeg4-generic parameter list MAY use "subrender" combine to define a renderer, in the render, subrender, same way as MIME
types and rinit
parameters with the audio/asc media type for renderer configuration.
Several restrictions apply MIME subtypes combine to the use define a type of these parameters in
mpeg4-generic parameter lists:

o An mpeg4-generic media description that uses [RFC2045].

If the render subrender parameter is used for a renderer definition, it MUST assign
appear immediately after the empty string ("") to render parameter in the mpeg4-generic "config"
parameter. parameter list.
At most one subrender parameter may appear in a renderer definition.

This document defines one value for subrender: the value "default".
The "default" token specifies the use of the streamtype, mode, and profile-level-id
parameters MUST follow default renderer for the normative text in Section 6.2.

o Sessions that use identity
stream type (native or ordered relationships MUST follow
the mpeg4-generic configuration restrictions in Appendix C.5.

o mpeg4-generic). The render parameter MUST be assigned the value "synthetic",
"unknown", "null", or default renderer for
native RTP MIDI streams is a render value that has been added to
the IANA repository renderer whose nature is unspecified
(see point 6 in Section 6.1 for details). The default renderer for use with
mpeg4-generic RTP MIDI
streams. The "api" token value streams is an MPEG 4 Audio Object Type whose
ID number is 13, 14, or 15 (see Section 6.2 for render MUST NOT be used.

o details).

If a subrender parameter is present, it MUST immediately follow renderer definition does not use the render subrender parameter, and it MUST be assigned the token value
"default", or assigned a subrender
value added to the IANA
repository "default" is assumed for use with mpeg4-generic RTP MIDI streams. A subrender.

Other subrender parameter assignment token values may be left out of the renderer
configuration, in which case the implied value of registered with IANA. We now
discuss guidelines for registering subrender
is the default value of "default".

o If the render parameter is assigned the value "synthetic",
and the values.

A subrender parameter has the value "default" (assigned is registered for a specific stream type (native or implied), the rinit parameter MUST be assigned the
mpeg4-generic) and a specific render value
"audio/asc", (excluding "null" and an AudioSpecificConfig data object MUST be encoded
using the mechanisms defined in C.6.2-3. The AudioSpecificConfig
data MUST encode one of the
"unknown"). Registrations for mpeg4-generic subrender values are
restricted to new MPEG 4 Audio Object Types defined for
use with mpeg4-generic in Section 6.2. If that accept MIDI input.
The syntax of the subrender value is
other than "default", refer token MUST adhere to the token definition in
Appendix D.

For "render=synthetic" renderers, a subrender value registration
specifies an exact method for information on transforming the use MIDI stream into audio
(or sometimes into video or control actions, such as stage lighting).
For standardized renderers, this specification is usually a pointer
to a standards document, perhaps supplemented by RTP-MIDI-specific
information. For commercial products and open-source projects, this
specification usually takes the form of "audio/asc" instructions for interfacing
the RTP MIDI stream with the renderer.

o If product or project software. A
"render=synthetic" registration MAY specify additional Reset State
commands for the render parameter renderer (Appendix A.1).

A "render=api" subrender value registration specifies how an RTP MIDI
stream interfaces with an API (Application Programmers Interface).
This specification is assigned usually a pointer to programmer's documentation
for the value "null" or
"unknown", API, perhaps supplemented by RTP-MIDI-specific information.

A subrender registration MAY specify an initialization file (referred
to in this document as an initialization data object) for the stream.
The initialization data object MAY be omitted.

Several general restrictions apply to encoded in the use of parameter list
(verbatim or by reference) using the audio/asc media
type coding tools defined in RTP MIDI:

o A native stream Appendix
C.6.3. An initialization data object MUST NOT assign "audio/asc" to rinit. The
audio/asc media type is not intended to be have a general-purpose
container for rendering systems outside of MPEG usage.

o The audio/asc registered
[RFC4288] media type defines a stored and subtype [RFC2045].

For "render=synthetic" renderers, the data object type; it does
not define semantics for RTP streams. Thus, audio/asc MUST NOT
appear on an rtpmap line of a session description.

Below, we show session description examples usually encodes
initialization data for audio/asc. The session
description below uses the inline parameter to code renderer (sample files, synthesis patch
parameters, reverberation room impulse responses, etc.).

For "render=api" renderers, the
AudioSpecificConfig block data object usually encodes data
about the stream used by the API (for example, for a mpeg4-generic General an RTP MIDI stream. We
derive stream
generated by a piano keyboard controller, the value assigned to manufacturer and model
number of the inline parameter keyboard, for use in Appendix E.4. The
subrender token value of "default" GUI presentation).

Usually, only one initialization object is implied by encoded for a renderer.
If a renderer uses multiple data objects, the absence correct receiver
interpretation of multiple data objects MUST be defined in the
subrender parameter registration.

A subrender value registration may also specify additional
parameters, to appear in the parameter list.

v=0
o=lazzaro 2520644554 2838152170 IN IP4 first.example.net
s=Example
t=0 0
m=audio 5004 RTP/AVP 96
c=IN IP4 192.0.2.94
a=rtpmap:96 mpeg4-generic/44100
a=fmtp:96 streamtype=5; mode=rtp-midi; config=""; profile-level-id=12;
render=synthetic; rinit="audio/asc";
inline="egoAAAAaTVRoZAAAAAYAAAABAGBNVHJrAAAABgD/LwAA"

(The a=fmtp line has been wrapped to fit list immediately after
subrender. These parameter names MUST begin with the page subrender
value, followed by an underscore ("_"), to accommodate
memo formatting restrictions; it comprises avoid name space
collisions with future RTP MIDI parameter names (for example, a
parameter "foo_bar" defined for subrender value "foo").

We now specify guidelines for interpreting the subrender parameter
during session configuration.

If a party is offered a single line in SDP)

The session description below that uses the url parameter a renderer
whose subrender value is not known to code the
AudioSpecificConfig block party, the party MUST NOT
accept the renderer. Options include rejecting the renderer (using
the "null" value), the payload type, the media stream, or the session
description.

Receivers MUST be aware of the Reset State commands (Appendix A.1)
for the same General MIDI stream:

v=0
o=lazzaro 2520644554 2838152170 IN IP4 first.example.net
s=Example
t=0 0
m=audio 5004 RTP/AVP 96
c=IN IP4 192.0.2.94
a=rtpmap:96 mpeg4-generic/44100
a=fmtp:96 streamtype=5; mode=rtp-midi; config=""; profile-level-id=12;
render=synthetic; rinit="audio/asc"; url="http://example.net/oski.asc";
cid="xjflsoeiurvpa09itnvlduihgnvet98pa3w9utnuighbuk"

(The a=fmtp line has been wrapped to fit renderer specified by the page subrender parameter and MUST insure
that the renderer does not experience indefinite artifacts due to accommodate
memo formatting restrictions; it comprises the
presence (or the loss) of a single line in SDP)

C.7 Interoperability

In this Appendix, we define interoperability guidelines Reset State command.

C.6.3. Renderer Initialization

If the renderer for two
application areas:

o MIDI content-streaming applications. Adding RTP MIDI to
RTSP-based content-streaming servers, so that viewers may
experience MIDI performances (produced by a specified client-side
renderer) in synchronization with other streams (video, audio).

o Long-distance network musical performance applications. Adding
RTP MIDI to SIP-based voice chat or videoconferencing programs,
as stream uses an alternative, or as initialization data object, an addition, to audio and/or video RTP
streams.

For each application we define a core set of functionality that all
implementations
"rinit" parameter MUST implement.

The applications we address appear in this section are not an exhaustive the parameter list
of potential RTP MIDI uses. We expect framework documents immediately after
the "subrender" parameter. If the renderer parameter list does not
include a subrender parameter (recall the semantics for other
applications "default" in
Appendix C.6.2), the "rinit" parameter MUST appear immediately after
the "render" parameter.

The value assigned to the rinit parameter MUST be developed, within the IETF or within other
organizations. We discuss other potential application areas media
type/subtype [RFC2045] for the initialization data object. If an
initialization object type is registered with several media types,
including audio, the assignment to rinit MUST use the audio media
type.

RTP MIDI supports several parameters for encoding initialization data
objects for renderers in Section 1 of the main text of this memo.

C.7.1 MIDI content streaming applications

In content-streaming applications, a user invokes an RTSP client to
initiate a request to an RTSP server to view parameter list: "inline", "url", and
"cid".

If the "inline", "url", and/or "cid" parameters are used by a multimedia session. For
example, clicking on
renderer, these parameters MUST immediately follow the "rinit"
parameter.

If a web page link "url" parameter appears for a renderer, an Internet Radio channel
launches "inline" parameter
MUST NOT appear. If an RTSP client that uses the link's RTSP URL "inline" parameter appears for a renderer, a
"url" parameter MUST NOT appear. However, neither "url" or "inline"
is required to contact the
RTSP server hosting appear. If neither "url" or "inline" parameters
follow "rinit", the radio channel. "cid" parameter MUST follow "rinit".

The content may be pre-recorded (example: on-demand replay "inline" parameter supports the inline encoding of
yesterday's football game) or "live" (example: football game coverage as
it occurs) but in either case the user data
object. The parameter is usually an "audience member"
as opposed to assigned a "participant" (as double-quoted Base64 [RFC2045]
encoding of the user would be in telephony).

Note binary data object, with no line breaks. Appendix
E.4 shows an example that these examples describe the distribution of audio content to constructs an audience member. inline parameter value.

The interoperability guidelines in this Appendix
address RTP MIDI applications of this nature, not applications such as
the transmission of raw MIDI command streams for use in a professional
environment (recording studio, performance stage, etc).

In an RTSP session, "url" parameter is assigned a client accesses double-quoted string representation
of a session description that is
"declared" by the server, either via Uniform Resource Locator (URL) for the RTSP DESCRIBE method, data object. The string
MUST specify a HyperText Transport Protocol URL (HTTP, [RFC2616]).
HTTP MAY be used over TCP or via
other means, MAY be used over a secure network
transport, such as HTTP or email. The session description defines the
session from the perspective of the client. For example, if a method described in [RFC2818]. The media

line
type/subtype for the data object SHOULD be specified in the session description contains
appropriate HTTP transport header.

The "cid" parameter supports data object caching. The parameter is
assigned a non-zero port number, it double-quoted string value that encodes the server's preference for the client's port numbers a globally unique
identifier for RTP
and RTCP reception. Once media flow begins, the server sends data object.

A cid parameter MAY immediately follow an RTP
MIDI stream to the client, which renders it for presentation, perhaps inline parameter, in
synchrony which
case the cid identifier value MUST be associated with video or other audio streams.

We now define the interoperability text inline data
object.

If a url parameter is present, and if the data object for content-streaming RTSP
applications.

In most cases, server interoperability responsibilities are described in
terms of limits on the "reference" session description a server provides URL is
expected to be unchanged for a performance if it has no information about the capabilities life of the
client. The reference session is URL, a "lowest common denominator" session
that maximizes cid parameter MAY
immediately follow the odds that a client will url parameter. The cid identifier value MUST
be able associated with the data object for the URL. A cid parameter
assigned to view the session. same identifier value SHOULD be specified following
the data object type/subtype in the appropriate HTTP transport
header.

If a server url parameter is aware of the capabilities of present, and if the client, data object for the server URL is
free
expected to provide a session description customized for change during the client in life of the
DESCRIBE reply.

Clients URL, a cid parameter MUST support unicast UDP RTP MIDI streams that use
NOT follow the recovery
journal with url parameter. A receiver interprets the closed-loop or the anchor sending policies. Clients
MUST be able to interpret stream subsetting and chapter inclusion
parameters in the session description that qualify the sending policies.
Client support presence of enhanced Chapter C encoding is OPTIONAL.

The reference session description offered by
a server MUST send all RTP
MIDI UDP streams cid parameter as unicast streams an indication that use the recovery journal and
the closed-loop or anchor sending policies. Servers SHOULD use the
stream subsetting and chapter inclusion parameters in the reference
session description, it is safe to simplify the rendering task use a cached copy
of the client.
Server support url data object; the absence of enhanced Chapter C encoding a cid parameter is OPTIONAL.

Clients and servers MUST support the an
indication that it is not safe to use of RTSP interleaved mode (a
method for interleaving RTP onto a cached copy, as it may
change.

Finally, the RTSP TCP transport).

Clients MUST cid parameter MAY be able to interpret used without the timestamp semantics signalled by inline and url
parameters. In this case, the "comex" value identifier references a local or
distributed catalog of data objects.

In most cases, only one data object is coded in the tsmode parameter (i.e. list
for each renderer. For example, the timestamp semantics default renderer for mpeg4-
generic streams uses a single data object (see Appendix C.6.5 for
example usage).

Initialization data objects MAY encapsulate a Standard MIDI Files [MIDI]). Servers MUST use the "comex" value for File
(SMF). By default, the "tsmode" parameter SMFs that are encapsulated in the reference session description.

Clients a data object
MUST be able to process ignored by an RTP MIDI stream whose packets encode
an arbitrary temporal duration ("media time"). Thus, in practice,
clients MUST implement a MIDI playout buffer. Clients MUST NOT depend
on the presence of rtp_ptime, rtp_maxtime, and guardtime receiver. We define parameters to
override this default in
the session description Appendix C.6.4.

To end this section, we offer guidelines for registering media types
for initialization data objects. These guidelines are in order addition to process packets, but
the information in [RFC4288] [RFC4289].

Some initialization data objects are also capable of encoding MIDI
note information and thus complete audio performances. These objects
SHOULD be able
to use these parameters registered using the "audio" media type, so that the
objects may also be used for store-and-forward rendering, and
"application" media type, to improve packet processing.

Servers support editing tools. Initialization
objects without note storage, or initialization objects for non-audio
renderers, SHOULD strive be registered only for an "application" media type.

C.6.4. MIDI Channel Mapping

In this appendix, we specify how to send RTP map MIDI streams in the same way media
servers send conventional audio streams: name spaces (16 voice
channels + systems) onto a sequence of packets that

either all code renderer.

In the same temporal duration (non-normative example: 50 ms
packets) or general case:

o A session may define an ordered relationship (Appendix C.5) that code
presents more than one of MIDI name space to a renderer.

o A renderer may accept an integral arbitrary number of temporal durations
(non-normative example: 50 ms, 100 ms, 250 ms, MIDI name spaces,
or 500 ms packets).
Servers it may expect a specific number of MIDI name spaces.

A session description SHOULD encode information about the packetization method in the
rtp_ptime and rtp_maxtime parameters provide a compatible MIDI name space to
each renderer in the session. If a receiver detects that a session description.

Clients
description has too many or too few MIDI name spaces for a renderer,
MIDI data from extra stream name spaces MUST be able to examine the render discarded, and subrender parameter, to
determine if a multimedia session uses a extra
renderer it supports. Clients name spaces MUST NOT be able to interpret the default "one" value of the "multimode"
parameter, to identify supported renderer(s) from driven with MIDI data (except as
described in Appendix C.6.4.1, below).

If a parameter list of renderer
descriptions. Clients MUST be able defines several renderers and assigns the "all"
token value to interpret the musicport multimode parameter, to the degree it same name space is relevant
presented to each renderer. However, the renderers it supports.
Clients MUST "chanmask" parameter may be able
used to interpret mask out selected voice channels to each renderer. We define
"chanmask" and other MIDI management parameters in the chanmask parameter.

Clients supporting renderers whose sub-sections
below.

C.6.4.1. The smf_info Parameter

The smf_info parameter defines the use of the SMFs encapsulated in
renderer data object (as encoded by a objects (if any). The smf_info parameter value for "inline"), could exceed 300 octets also defines
the use of SMFs coded in size MUST
support the url and cid parameters, smf_inline, smf_url, and thus, must implement smf_cid
parameters (defined in Appendix C.6.4.2).

The smf_info parameter describes the HTTP
protocol "render" parameter that most
recently precedes it in addition to RTSP.

Servers the parameter list. The smf_info parameter
MUST specify complete rendering systems for RTP MIDI streams.
Note NOT appear in parameter lists that a minimal RTP MIDI native stream does do not meet this
requirement (Section 6.1), as use the rendering method for such streams is
"not specified".

At "render"
parameter, and MUST NOT appear before the time this memo was written, first use of "render" in
the only way parameter list.

We define three token values for servers to specify a
complete rendering system is to specify an mpeg4-generic RTP MIDI stream
in mode rtp-midi (Section 6.2 smf_info: "ignore", "sdp_start", and C.6.5). As a consequence,
"identity":

o The "ignore" value indicates that the only SMFs MUST be discarded.
This behavior is the default SMF rendering systems behavior.

o The "sdp_start" value codes that may SMFs MUST be presently used are General MIDI [MIDI],
DLS 2 [DLS2], or Structured Audio [MPEGSA]. Note rendered, and that
the maximum
inline value for General MIDI rendering MUST begin upon the acceptance of the session
description. If a receiver is well under 300 octets (and thus clients
need offered a session description
with a renderer that uses an smf_info parameter set to
sdp_start, and if the receiver does not support rendering SMFs,
the "url" parameter), but the maximum inline values for
DLS 2 and Structured Audio may be quite larger than 300 octets (and thus
clients receiver MUST support NOT accept the url parameter).

We anticipate that renderer associated with the owners of rendering systems (both standardized
and proprietary) will register subrender parameters for their renderers.
Once registration occurs, native RTP MIDI sessions may use render and
subrender (Appendix C.6.2)
smf_info parameter. Options include rejecting the renderer (by
setting the "render" parameter to specify complete rendering systems for
RTSP content-streaming multimedia sessions.

Servers MUST NOT use "null"), the sdp_start payload type, the
media stream, or the entire session description.

o The "identity" value indicates that the SMFs code the identity
of the renderer. The value is meant for use with the smf_info parameter "unknown"
renderer (see Appendix C.6 preamble). The MIDI commands coded
in the reference session description, SMF are informational in nature and MUST NOT be presented
to a renderer for audio presentation. In typical use, the SMF
would use SysEx Identity Reply commands (F0 7E nn 06 02, as this
defined in [MIDI]) to identify devices, and use would require clients device-specific
SysEx commands to describe current state of the devices (patch
memory contents, etc.).

Other smf_info token values MAY be able registered with IANA. The token
value MUST adhere to parse and the ABNF for render Standard MIDI Files.

Clients tokens defined in Appendix
D. Registrations MUST support mpeg4-generic mode rtp-midi General MIDI (GM)
sessions, at a polyphony limited by the hardware capabilities of the
client. This requirement provides include a "lowest common denominator"
rendering system for content providers to target. Note that this

requirement does not force implementors complete specification of a non-GM renderer (such as
DLS 2 or Structured Audio) parameter
usage, similar in depth to add a second rendering engine. Instead, a
client may satisfy the requirement by including a set of voice patches specifications that implement the GM instrument set, and using appear in this emulation
appendix for
mpeg4-generic GM sessions.

It "sdp_start" and "identity".

If a party is RECOMMENDED offered a session description that servers use General MIDI as uses an smf_info
parameter value that is not known to the party, the party MUST NOT
accept the renderer for associated with the
reference smf_info parameter. Options
include rejecting the renderer, the payload type, the media stream,
or the entire session description, because clients are REQUIRED to support
it. description.

We do not require General MIDI as now define the reference renderer, because rendering semantics for normative applications it is an inappropriate choice. Servers using
General the "sdp_start" token value
in detail.

The SMFs and RTP MIDI as streams in a "lowest common denominator" renderer SHOULD use
Universal Real-Time SysEx MIP message [SPMIDI] to communicate session description share the
priority of voices to polyphony-limited clients.

C.7.2 same
MIDI network musical performance applications name space(s). In Internet telephony the simple case of a single RTP MIDI stream
and videoconferencing applications, parties
interact over an IP network as they would face-to-face. Good user
experiences require low end-to-end audio latency a single SMF, the SMF MIDI commands and tight audiovisual
synchronization (for "lip-sync"). RTP MIDI commands are
merged into a single name space and presented to the renderer. The Session Initiation Protocol (SIP,
[RFC3261]) is used for session management.

In this Appendix section, we define interoperability guidelines
indefinite artifact responsibilities for
using RTP merged MIDI streams defined
in interactive SIP applications. Our primary
interest is supporting Network Musical Performances (NMP), where
musicians in different locations interact over Appendix C.5 also apply to merging RTP and SMF MIDI data.

If a payload type codes multiple SMFs, the network SMF name spaces are
presented as if they
were in an ordered entity to the same room. See [NMP] for background information on NMP, and
see [GUIDE] renderer. To determine the
ordering of SMFs for a discussion renderer (which SMF is "first", which is
"second", etc.), use the following rules:

o If the renderer uses a single data object, the order of
appearance of low-latency RTP MIDI implementation
techniques for NMP.

Note that the goal SMFs in the object's internal structure
defines the order of NMP applications is telepresence: the parties
should hear audio that is close to what they would hear if they were SMFs (the earliest SMF in the same room. The interoperability guidelines object is
"first", the next SMF in this Appendix address
RTP MIDI applications the object is "second", etc.).

o If multiple data objects are encoded for a renderer, the
appearance of this nature, not applications such as each data object in the
transmission parameter list sets the
relative order of raw MIDI command streams for use the SMFs encoded in a professional
environment (recording studio, performance stage, etc).

We focus on session management for two-party unicast sessions each data object (SMFs
encoded in parameters that
specify a renderer for RTP MIDI streams. Within this limited scope, appear earlier in the
guidelines defined here list are sufficient to let applications interoperate.
We define
ordered before SMFs encoded in parameters that appear later in
the REQUIRED capabilities of RTP MIDI senders and receivers list).

o If SMFs are encoded in
NMP sessions, data objects parameters and define how session descriptions exchanged are used to
set up network musical performance sessions.

SIP lets parties negotiate details in the
parameters defined in C.6.4.2, the relative order of the session, using data
object parameters and C.6.4.2 parameters in the
Offer/Answer protocol [RFC3264]. However, RTP MIDI has so many parameter list
sets the relative order of SMFs (SMFs encoded in parameters that "blind" negotiations between two parties using different

applications might not yield a common session configuration.

Thus,
appear earlier in the list are ordered before SMFs in parameters
that appear later in the list).

Given this ordering of SMFs, we now define a set the mapping of capabilities SMFs to
renderer name spaces. The SMF that NMP parties MUST support.
Session description offers whose options lie outside appears first for a renderer maps
to the envelope of
REQUIRED party behavior risk negotiation failure. We also define
session description idioms first renderer name space. The SMF that appears second for a
renderer maps to the second renderer name space, etc. If the
associated RTP MIDI part of streams also form an offer MUST
follow, in order ordered relationship, the
first SMF is merged with the first name space of the relationship,
the second SMF is merged to structure the offer for simpler analysis.

We use second name space of the term "offerer" for
relationship, etc.

Unless the party making a SIP offer, streams and
"answerer" for the party answering SMFs both use MIDI Time Code, the offer. time
offset between SMF and stream data is unspecified. This restriction
limits the use of SMFs to applications where synchronization is not
critical, such as the transport of System Exclusive commands for
renderer initialization, or human-SMF interactivity.

Finally, we note that
unless qualified by each SMF in the adjective "sender" or "receiver", a statement
that a party MUST support X implies that it MUST support X sdp_start discussion above
encodes exactly one MIDI name space (16 voice channels + systems).
Thus, the use of the Device Name SMF meta event to specify several
MIDI name spaces in an SMF is not supported for both
sending sdp_start.

C.6.4.2. The smf_inline, smf_url, and receiving.

If smf_cid Parameters

In some applications, the renderer data object may not encapsulate
SMFs, but an offerer wishes to define a "sendrecv" RTP MIDI stream, it application may wish to use
a true sendrecv session or the "virtual sendrecv" construction described SMFs in the preamble to Appendix C and manner defined
in Appendix C.5. A true sendrecv
session indicates that C.6.4.1.

The "smf_inline", "smf_url", and "smf_cid" parameters address this
situation. These parameters use the offerer wishes to participate syntax and semantics of the
inline, url, and cid parameters defined in a session
where both parties use identically-configured renderers. A virtual
sendrecv session indicates Appendix C.6.3, except
that the offerer encoded data object is willing an SMF.

The "smf_inline", "smf_url", and "smf_cid" parameters belong to participate the
"render" parameter that most recently precedes it in
a session where the two parties may be using different renderer
configurations. Thus, parties MUST be prepared to see both real session
description. The "smf_inline", "smf_url", and
virtual sendrecv sessions in an offer.

Parties MUST support unicast UDP transport of RTP MIDI streams. These
streams "smf_cid" parameters
MUST NOT appear in parameter lists that do not use the recovery journal with the closed-loop or anchor
sending policies. These streams "render"
parameter and MUST NOT appear before the first use of "render" in the stream subsetting and
chapter inclusion
parameter list. If several "smf_inline", "smf_url", or "smf_cid"
parameters to declare appear for a renderer, the types order of MIDI commands that
will be sent on the stream (for sendonly streams) or will be processed
(for recvonly streams), including parameters defines
the size limits on System Exclusive
commands. Support of enhanced Chapter C encoding is OPTIONAL.

Note that both TCP and multicast UDP support are OPTIONAL. We make TCP
OPTIONAL because we expect NMP renderers SMF name space ordering.

C.6.4.3. The chanmask Parameter

The chanmask parameter instructs the renderer to rely on data objects
(signalled by "rinit" and associated parameters) ignore all MIDI
voice commands for initialization at
the start certain channel numbers. The parameter value is a
concatenated string of the session, "1" and "0" digits. Each string position maps
to only use System Exclusive commands for
interactive control during a MIDI voice channel number (system channels may not be masked).
A "1" instructs the session. These interactive commands are
small enough renderer to be protected via process the recovery journal mechanism voice channel; a "0"
instructs the renderer to ignore the voice channel.

The string length of RTP
MIDI UDP streams.

We now discuss timestamps, packet timing, and packet sending algorithms.

Recall that the tsmode chanmask parameter controls the semantics value MUST be 16 (for a
single stream or an identity relationship) or a multiple of command
timestamps 16 (for
an ordered relationship).

The chanmask parameter describes the "render" parameter that most
recently precedes it in the MIDI list of RTP packets.

Parties session description; chanmask MUST support clock rates of 44.1 kHz, 48 kHz, 88.2 kHz, NOT
appear in parameter lists that do not use the "render" parameter and 96
kHz. Parties
MUST support streams using NOT appear before the "comex", "async", and
"buffer" tsmode values. Recvonly offers MUST offer the default "comex".

Parties MUST support a wide range of packet temporal durations: from
rtp_ptime and rtp_maxptime values first use of 0, "render" in the parameter
list.

The chanmask parameter describes the final MIDI name spaces presented
to rtp_ptime the renderer. The SMF and rtp_maxptime
values that code 100 ms. Thus, receivers MUST stream components of the MIDI name
spaces may not be able to implement independently masked.

If a
playout buffer.

Offers and answers MUST present rtp_ptime, rtp_maxptime, and guardtime
values that support the latency that users would expect in the
application, subject to bandwidth constraints. As senders MUST abide by
values set for these parameters in receiver is offered a session description, description with a receiver
SHOULD use these values to size its playout buffer to produce renderer that
uses the lowest
reliable latency for a session. Implementers should refer to [GUIDE]
for information on packet sending algorithms for latency-sensitive
applications. Parties MUST be able to chanmask parameter, and if the receiver does not implement
the semantics of the
guardtime chanmask parameter, the receiver MUST NOT accept
the renderer unless the chanmask parameter value contains only "1"s.

C.6.5. The audio/asc Media Type

In Appendix 11.3, we register the audio/asc media type. The data
object for times from 5 ms audio/asc is a binary encoding of the AudioSpecificConfig
data block used to initialize mpeg4-generic streams (Section 6.2 and
[MPEGAUDIO]).

An mpeg4-generic parameter list MAY use the render, subrender, and
rinit parameters with the audio/asc media type for renderer
configuration. Several restrictions apply to 5000 ms.

We now discuss the use of these
parameters in mpeg4-generic parameter lists:

o An mpeg4-generic media description that uses the render
parameter MUST assign the empty string ("") to the mpeg4-generic
"config" parameter. The use of the streamtype, mode, and
profile-level-id parameters MUST follow the normative text in
Section 6.2.

o Sessions that use identity or ordered relationships MUST specify complete rendering systems follow
the mpeg4-generic configuration restrictions in Appendix C.5.

o The render parameter MUST be assigned the value "synthetic",
"unknown", "null", or a render value that has been added to the
IANA repository for all use with mpeg4-generic RTP MIDI streams. Note that a minimal RTP MIDI native stream does not meet this
requirement (Section 6.1), as the rendering method
The "api" token value for such streams render MUST NOT be used.

o If a subrender parameter is
"not specified".

At present, it MUST immediately follow
the time this writing, render parameter, and it MUST be assigned the only way for parties to specify token value
"default" or assigned a complete
rendering system is subrender value added to specify an the IANA
repository for use with mpeg4-generic RTP MIDI stream streams. A
subrender parameter assignment may be left out of the renderer
configuration, in mode
rtp-midi (Section 6.2 and C.6.5). We anticipate that which case the owners implied value of
rendering systems (both standardized and proprietary) will register subrender values for their renderers. Once IANA registration occurs,
native RTP MIDI sessions may use is
the default value of "default".

o If the render parameter is assigned the value "synthetic" and
the subrender (Appendix C.6.2)
to specify complete rendering systems for SIP network musical
performance multimedia sessions.

All parties MUST support General MIDI (GM) sessions, at a polyphony
limited by parameter has the hardware capabilities of value "default" (assigned or
implied), the party. This requirement
provides a "lowest common denominator" rendering system, without which
practical interoperability will rinit parameter MUST be quite difficult. When assigned the value
"audio/asc", and an AudioSpecificConfig data object MUST be
encoded using GM,
parties SHOULD use Universal Real-Time SysEx MIP message [SPMIDI] to
communicate the priority mechanisms defined in C.6.2-3. The
AudioSpecificConfig data MUST encode one of voices the MPEG 4 Audio
Object Types defined for use with mpeg4-generic in Section 6.2.
If the subrender value is other than "default", refer to polyphony-limited clients.

Note that this requirement does not force implementors the
subrender registration for information on the use of a non-GM
renderer (for mpeg4-generic sessions, DLS 2 "audio/asc"
with the renderer.

o If the render parameter is assigned the value "null" or Structured Audio)
"unknown", the data object MAY be omitted.

Several general restrictions apply to add
a second rendering engine. Instead, a client may satisfy the
requirement by including a set use of voice patches that implement the GM
instrument set, and using this emulation for mpeg4-generic GM sessions.
We require GM support, so that an offerer that wishes audio/asc media
type in RTP MIDI:

o A native stream MUST NOT assign "audio/asc" to maximize
interoperability may do so by offering GM if its preferred renderer rinit. The
audio/asc media type is not accepted by the answerer.

Offerers intended to be a general-purpose
container for rendering systems outside of MPEG usage.

o The audio/asc media type defines a stored object type; it does
not define semantics for RTP streams. Thus, audio/asc MUST NOT present several renderers as options in
appear on an rtpmap line of a session description.

Below, we show session description by listing several payload types on a media line, as Section
2.1 examples for audio/asc. The
session description below uses this construct the inline parameter to let code the
AudioSpecificConfig block for a party send several RTP mpeg4-generic General MIDI streams in stream.
We derive the same RTP session.

Instead, an offerer wishing value assigned to present rendering options SHOULD offer a
single payload type that offers several renderers. In this construct, the inline parameter list codes a list of render parameters (each followed by
its support parameters). As discussed in Appendix C.6.1, the order of
renderers in the list declares the offerer's preference. The "unknown"
and "null" values MUST NOT appear in the offer. E.4.
The answer MUST set all
render values except the desired renderer to "null". Thus, "unknown"
MUST NOT appear in subrender token value of "default" is implied by the answer.

We use SHOULD instead absence of MUST in
the first sentence subrender parameter in the paragraph
above, because this technique does not work in all situations (example:
an offerer wishes parameter list.

v=0
o=lazzaro 2520644554 2838152170 IN IP4 first.example.net
s=Example
t=0 0
m=audio 5004 RTP/AVP 96
c=IN IP4 192.0.2.94
a=rtpmap:96 mpeg4-generic/44100
a=fmtp:96 streamtype=5; mode=rtp-midi; config="";
profile-level-id=12; render=synthetic; rinit="audio/asc";
inline="egoAAAAaTVRoZAAAAAYAAAABAGBNVHJrAAAABgD/LwAA"

(The a=fmtp line has been wrapped to offer both mpeg4-generic renderers and native RTP
MIDI renderers as options). In this case, fit the offerer MUST present a
series of session descriptions, each offering page to accommodate
memo formatting restrictions; it comprises a single renderer, until
the answerer accepts a line in SDP.)
The session description.

Parties MUST support the musicport, chanmask, subrender, rinit, and
inline parameters. Parties supporting renderers whose data object (as
encoded by a parameter value for "inline"), could exceed 300 octets in
size MUST support description below uses the url and cid parameters, and thus, must implement
HTTP protocol. Note that in mpeg4-generic, General MIDI data objects
can not exceed 300 octets, but DLS 2 and Structured Audio data objects
may. Support for the other rendering parameters (smf_cif, smf_info,
smf_inline, smf_url) is OPTIONAL.

Our discussion of rendering so far in this document assumes that the
only MIDI flow that drives a renderer is the network flows described in
the session description. In NMP applications, this assumption would
require two rendering engines: one for local use by a party, a second
for the remote party.

In practice, applications may wish to have both parties share a single
rendering engine. In this case, the session description MUST use a
virtual sendrecv session, and MUST use the stream subsetting and chapter
inclusion parameters to allocate which MIDI channels are intended for
use by a party. If two parties are sharing a MIDI channels, the
application MUST ensure appropriate MIDI merging occurs at the input to
the renderer.

We now discuss the use of (non-MIDI) audio streams in the session.

Audio streams may be used for two purposes: as a "talkback" channel for
parties to converse, or as a way parameter to conduct a performance that includes
MIDI and audio channels. In the latter case, offers MUST use sample

rates and code the packet temporal durations
AudioSpecificConfig block for the audio and same General MIDI streams
that support low-latency synchronized rendering.

We now show an example of an offer/answer exchange in a network musical
performance application (next page).

Below, we show an offer that complies with the interoperability text in
this Appendix section. stream:

v=0
o=first
o=lazzaro 2520644554 2838152170 IN IP4 first.example.net
s=Example
t=0 0
a=group:FID 1 2
c=IN IP4 192.0.2.94
m=audio 16112 RTP/AVP 96
a=recvonly
a=mid:1
a=rtpmap:96 mpeg4-generic/44100
a=fmtp:96 streamtype=5; mode=rtp-midi; config=""; profile-level-id=12;
cm_unused=ABCFGHJKMNPQTVWXYZ; cm_used=2NPTW;
cm_used=2C0.1.7.10.11.64.121.123; cm_used=2M0.1.2
cm_used=X0-16; ch_never=ABCDEFGHJKMNPQTVWXYZ;
ch_default=2NPTW; ch_default=2C0.1.7.10.11.64.121.123;
ch_default=2M0.1.2; cm_default=X0-16;
rtp_ptime=0; rtp_maxptime=0; guardtime=44100;
musicport=1; render=synthetic; rinit="audio/asc";
inline="egoAAAAaTVRoZAAAAAYAAAABAGBNVHJrAAAABgD/LwAA"
m=audio 16114 5004 RTP/AVP 96
a=sendonly
a=mid:2
c=IN IP4 192.0.2.94
a=rtpmap:96 mpeg4-generic/44100
a=fmtp:96 streamtype=5; mode=rtp-midi; config="";
profile-level-id=12;
cm_unused=ABCFGHJKMNPQTVWXYZ; cm_used=1NPTW;
cm_used=1C0.1.7.10.11.64.121.123; cm_used=1M0.1.2
cm_used=X0-16; ch_never=ABCDEFGHJKMNPQTVWXYZ;
ch_default=1NPTW; ch_default=1C0.1.7.10.11.64.121.123;
ch_default=1M0.1.2; cm_default=X0-16;
rtp_ptime=0; rtp_maxptime=0; guardtime=44100;
musicport=1; render=synthetic; rinit="audio/asc";
inline="egoAAAAaTVRoZAAAAAYAAAABAGBNVHJrAAAABgD/LwAA"
url="http://example.net/oski.asc";
cid="xjflsoeiurvpa09itnvlduihgnvet98pa3w9utnuighbuk"

(The a=fmtp lines have line has been wrapped to fit the page to accommodate
memo formatting restrictions; it comprises a single line in SDP)

The owner line (o=) identifies the session owner as "first".

The session description defines SDP.)

C.7. Interoperability

In this appendix, we define interoperability guidelines for two
application areas:

o MIDI streams: a recvonly stream on
which "first" receives a performance, and a sendonly stream that "first"
uses to send a performance. The recvonly port number encodes the ports
on which "first" wishes to receive content-streaming applications. RTP (16112) and RTCP (16113) media at
IP4 address 192.0.2.94. The sendonly port number encodes the port on

which "first" wishes MIDI is added to receive RTCP for the stream (16115).

The musicport parameters code
RTSP-based content-streaming servers, so that the two streams share and identity
relationship, and thus form viewers may
experience MIDI performances (produced by a virtual sendrecv stream.

Both specified client-
side renderer) in synchronization with other streams are mpeg4-generic (video,
audio).

o Long-distance network musical performance applications. RTP
MIDI streams that specify a General
MIDI renderer. The stream subsetting parameters code that the recvonly
stream uses MIDI channel 1 exclusively for is added to SIP-based voice commands, and chat or videoconferencing
programs, as an alternative, or as an addition, to audio and/or
video RTP streams.

For each application, we define a core set of functionality that the
sendonly stream uses all
implementations MUST implement.

The applications we address in this section are not an exhaustive
list of potential RTP MIDI channel 2 exclusively uses. We expect framework documents for voice commands.
This mapping permits
other applications to be developed, within the IETF or within other
organizations. We discuss other potential application software areas for RTP
MIDI in Section 1 of the main text of this memo.

C.7.1. MIDI Content Streaming Applications

In content-streaming applications, a user invokes an RTSP client to share
initiate a single renderer request to an RTSP server to view a multimedia session.
For example, clicking on a web page link for local and remote performers.

We now show an Internet Radio
channel launches an RTSP client that uses the answer link's RTSP URL to
contact the offer.

v=0
o=second 2520644554 2838152170 IN IP4 second.example.net
s=Example
t=0 0
a=group:FID 1 2
c=IN IP4 192.0.2.105
m=audio 5004 RTP/AVP 96
a=sendonly
a=mid:1
a=rtpmap:96 mpeg4-generic/44100
a=fmtp:96 streamtype=5; mode=rtp-midi; config=""; profile-level-id=12;
cm_unused=ABCFGHJKMNPQTVWXYZ; cm_used=2NPTW;
cm_used=2C0.1.7.10.11.64.121.123; cm_used=2M0.1.2
cm_used=X0-16; ch_never=ABCDEFGHJKMNPQTVWXYZ;
ch_default=2NPTW; ch_default=2C0.1.7.10.11.64.121.123;
ch_default=2M0.1.2; cm_default=X0-16;
rtp_ptime=0; rtp_maxptime=882; guardtime=44100;
musicport=1; render=synthetic; rinit="audio/asc";
inline="egoAAAAaTVRoZAAAAAYAAAABAGBNVHJrAAAABgD/LwAA"
m=audio 5006 RTP/AVP 96
a=recvonly
a=mid:2
a=rtpmap:96 mpeg4-generic/44100
a=fmtp:96 streamtype=5; mode=rtp-midi; config=""; profile-level-id=12;
cm_unused=ABCFGHJKMNPQTVWXYZ; cm_used=1NPTW;
cm_used=1C0.1.7.10.11.64.121.123; cm_used=1M0.1.2
cm_used=X0-16; ch_never=ABCDEFGHJKMNPQTVWXYZ;
ch_default=1NPTW; ch_default=1C0.1.7.10.11.64.121.123;
ch_default=1M0.1.2; cm_default=X0-16;
rtp_ptime=0; rtp_maxptime=0; guardtime=88200;
musicport=1; render=synthetic; rinit="audio/asc";
inline="egoAAAAaTVRoZAAAAAYAAAABAGBNVHJrAAAABgD/LwAA"

(The a=fmtp lines have been wrapped to fit RTSP server hosting the page to accommodate
memo formatting restrictions; they comprise single lines in SDP) radio channel.

The owner line (o=) identifies content may be pre-recorded (for example, on-demand replay of
yesterday's football game) or "live" (for example, football game
coverage as it occurs), but in either case the session owner user is usually an
"audience member" as "second".

The port numbers for both media streams are non-zero; thus, "second" has
accepted opposed to a "participant" (as the session description. user would be
in telephony).

Note that these examples describe the distribution of audio content
to an audience member. The stream marked "sendonly" interoperability guidelines in this
appendix address RTP MIDI applications of this nature, not
applications such as the
offer is marked "recvonly" transmission of raw MIDI command streams for
use in a professional environment (recording studio, performance
stage, etc.).

In an RTSP session, a client accesses a session description that is
"declared" by the answer, and vice versa, coding server, either via the
different view RTSP DESCRIBE method, or via
other means, such as HTTP or email. The session description defines
the session from the perspective of the client. For example, if a
media line in the session held by "session". The IP4 number
(192.0.2.105) and description contains a non-zero port
number, it encodes the server's preference for the client's port
numbers for RTP (5004 and 5006) and RTCP (5005 and 5007) have
been changed by "second" to match its transport wishes.

In addition, "second" has made several parameter changes: rtp_maxptime
for reception. Once media flow begins, the sendonly
server sends an RTP MIDI stream has been changed to code 2 ms (441 in clock
units), and the guardtime client, which renders it for the recvonly stream has been doubled. As
these parameter modifications request capabilities that are REQUIRED to
be implemented by interoperable parties, "second" can make these changes
presentation, perhaps in synchrony with confidence that "first" can abide by them.

D. Parameter Syntax Definitions

In this Appendix, we video or other audio streams.

We now define the syntax interoperability text for the RTP MIDI media type
parameters content-streaming RTSP
applications.

In most cases, server interoperability responsibilities are described
in Augmented Backus-Naur Form (ABNF, [RFC2234]). When using
these parameters with SDP, all parameters MUST appear terms of limits on the "reference" session description a single fmtp
attribute line server
provides for a performance if it has no information about the
capabilities of an RTP MIDI media description. For mpeg4-generic the client. The reference session is a "lowest
common denominator" session that maximizes the odds that a client
will be able to view the session. If a server is aware of the
capabilities of the client, the server is free to provide a session
description customized for the client in the DESCRIBE reply.

Clients MUST support unicast UDP RTP MIDI streams, this line streams that use the
recovery journal with the closed-loop or the anchor sending policies.
Clients MUST also include any mpeg4-generic be able to interpret stream subsetting and chapter
inclusion parameters
(usage described in Section 6.2). An fmtp attribute line may be defined
(after [RFC3640]) as:

;
; SDP fmtp line definition
;

fmtp = "a=fmtp:" token SP param-assign 0*(";" SP param-assign) CRLF

where <token> codes the RTP payload type. Note session description that white space qualify the
sending policies. Client support of enhanced Chapter C encoding is
OPTIONAL.

The reference session description offered by a server MUST
NOT appear between send all
RTP MIDI UDP streams as unicast streams that use the "a=fmtp:" recovery journal
and the RTP payload type.

We now define the syntax of closed-loop or anchor sending policies. Servers SHOULD use
the stream subsetting and chapter inclusion parameters defined in Appendix C. The
definition takes the form
reference session description, to simplify the rendering task of the incremental assembly
client. Server support of enhanced Chapter C encoding is OPTIONAL.

Clients and servers MUST support the <param-
assign> token. See [RFC3640] use of RTSP interleaved mode (a
method for interleaving RTP onto the syntax RTSP TCP transport).

Clients MUST be able to interpret the timestamp semantics signalled
by the "comex" value of the mpeg4-generic
parameters discussed in Section 6.2.
;
;
; top-level definition tsmode parameter (i.e., the timestamp
semantics of Standard MIDI Files [MIDI]). Servers MUST use the
"comex" value for all parameters
;
;

;
; Parameters defined the "tsmode" parameter in Appendix C.1

param-assign /= "cm_unused" "=" ([channel-list] command-type [f-list])
/ sysex-data

param-assign /= "cm_used" "=" ([channel-list] command-type [f-list])
/ sysex-data

;
; Parameters defined the reference session
description.

Clients MUST be able to process an RTP MIDI stream whose packets
encode an arbitrary temporal duration ("media time"). Thus, in Appendix C.2

param-assign = "j_sec" "=" ("none" / "recj" / *ietf-extension)

param-assign /= "j_update" "=" ("anchor" / "closed-loop" / "open-loop"
/ *ietf-extension)

param-assign /= "ch_default" "=" ([channel-list] chapter-list [f-list])
/ sysex-data

param-assign /= "ch_never" "=" ([channel-list] chapter-list [f-list])
/ sysex-data

param-assign /= "ch_anchor" "=" ([channel-list] chapter-list [f-list])
/ sysex-data

;
; Parameters defined
practice, clients MUST implement a MIDI playout buffer. Clients MUST
NOT depend on the presence of rtp_ptime, rtp_maxtime, and guardtime
parameters in Appendix C.3

param-assign /= "tsmode" "=" ("comex" / "async" / "buffer")

param-assign /= "linerate" "=" nonzero-four-octet

param-assign /= "octpos" "=" ("first" / "last")

param-assign /= "mperiod" "=" nonzero-four-octet

;
; Parameter defined the session description in Appendix C.4

param-assign /= "guardtime" "=" nonzero-four-octet

param-assign /= "rtp_ptime" "=" four-octet

param-assign /= "rtp_maxptime" "=" four-octet

;
; Parameters defined order to process packets,
but they SHOULD be able to use these parameters to improve packet
processing.

Servers SHOULD strive to send RTP MIDI streams in Appendix C.5

param-assign /= "musicport" "=" four-octet

;
; Parameters defined the same way media
servers send conventional audio streams: a sequence of packets that
either all code the same temporal duration (non-normative example: 50
ms packets) or that code one of an integral number of temporal
durations (non-normative example: 50 ms, 100 ms, 250 ms, or 500 ms
packets). Servers SHOULD encode information about the packetization
method in Appendix C.6

param-assign /= "chanmask" "=" 1*( 16( "0" / "1" ) )

param-assign /= "cid" "=" double-quote cid-block double-quote

param-assign /= "inline" "=" double-quote base-64-block double-quote

param-assign /= "multimode" "=" ("all" / "one")

param-assign /= "render" "=" ("synthetic" / "api" / "null" /
"unknown" / *extension)

param-assign /= "rinit" "=" mime-type "/" mime-subtype

param-assign /= "smf_cid" "=" double-quote cid-block double-quote

param-assign /= "smf_info" "=" ("ignore" / "identity" / "sdp_start"
/ *extension)

param-assign /= "smf_inline" "=" double-quote base-64-block double-quote

param-assign /= "smf_url" "=" double-quote uri-element double-quote

param-assign /= "subrender" "=" ("default" / *extension)

param-assign /= "url" "=" double-quote uri-element double-quote

;
; list definitions for the cm_ command-type
;

command-type = command-part1 command-part2 command-part3

command-part1 = 0*1"A" 0*1"B" 0*1"C" 0*1"F" 0*1"G"

command-part2 = 0*1"H" 0*1"J" 0*1"K" 0*1"M" 0*1"N" 0*1"P" 0*1"Q"

command-part3 = 0*1"T" 0*1"V" 0*1"W" 0*1"X" 0*1"Y" 0*1"Z"

;
; list definitions for rtp_ptime and rtp_maxtime parameters in the ch_ chapter-list
;

chapter-list = chapter-part1 chapter-part2 chapter-part3

chapter-part1 = 0*1"A" 0*1"B" 0*1"C" 0*1"D" 0*1"E" 0*1"F" 0*1"G"

chapter-part2 = 0*1"H" 0*1"J" 0*1"K" 0*1"M" 0*1"N" 0*1"P" 0*1"Q"

chapter-part3 = 0*1"T" 0*1"V" 0*1"W" 0*1"X" 0*1"Y" 0*1"Z"

;
; list definitions for session
description.

Clients MUST be able to examine the ch_ channel-list
;

channel-list = midi-chan-element *("." midi-chan-element)

midi-chan-element = midi-chan / midi-chan-range

midi-chan-range = midi-chan "-" midi-chan

; decimal value of left midi-chan
; render and subrender parameter,
to determine if a multimedia session uses a renderer it supports.
Clients MUST be strictly less than decimal
; able to interpret the default "one" value of right midi-chan

midi-chan = %d0-15

;
; list definitions for the ch_ field
"multimode" parameter, to identify supported renderers from a list (f-list)
;

f-list = midi-field-element *("." midi-field-element)

midi-field-element = midi-field / midi-field-range

midi-field-range = midi-field "-" midi-field
;
; decimal value of left midi-field
;
renderer descriptions. Clients MUST be strictly less than decimal
; able to interpret the
musicport parameter, to the degree that it is relevant to the
renderers it supports. Clients MUST be able to interpret the
chanmask parameter.

Clients supporting renderers whose data object (as encoded by a
parameter value of right midi-field

midi-field = four-octet
;
; large range accommodates Chapter M
; RPN (0-16383) for "inline") could exceed 300 octets in size MUST
support the url and NRPN (16384-32767)
; parameters, cid parameters and Chapter X octet sizes.

;
; definitions thus must implement the HTTP
protocol in addition to RTSP.

Servers MUST specify complete rendering systems for ch_ sysex-data
;

sysex-data = "__" h-list *("_" h-list) "__"

h-list = hex-field-element *("." hex-field-element)

hex-field-element = hex-octet / hex-field-range

hex-field-range = hex-octet "-" hex-octet
;
; hexadecimal value RTP MIDI streams.
Note that a minimal RTP MIDI native stream does not meet this
requirement (Section 6.1), as the rendering method for such streams
is "not specified".

At the time of left hex-octet
; MUST be strictly less than hexadecimal
; value of right hex-octet

hex-octet = 2("0" / "1" / "2"/ "3" / "4" /
"5" / "6" / "7" / "8" / "9" /
"A" / "B" / "C" / "D" / "E" / "F")
;
; rewritten version of hex-octet in [RFC2045]
; (page 23).
; note that a-f are not permitted, this memo, the only A-F.
; hex-octet values MUST NOT exceed 7F.

;
; definitions for rinit parameter
;

mime-type = "audio" / "application"

mime-subtype = token
;
; See Appendix C.6.2 for registration
; requirements for rinit type/subtypes.

;
; definitions way for base64 encoding
; copied from [SDP]

base-64-block = *base64-unit [base64-pad]

base64-unit = 4base64-char

base64-pad = 2base64-char "==" / 3base64-char "="

base64-char = %x41-5A / %x61-7A / %x30-39 / "+" / "/"
; A-Z, a-z, 0-9, "+" servers to specify a
complete rendering system is to specify an mpeg4-generic RTP MIDI
stream in mode rtp-midi (Section 6.2 and "/"

;
; generic rules
;

ietf-extension = token
;
; ietf-extension may C.6.5). As a consequence,
the only be defined in
; standards-track RFCs.

extension = token
;
; extension rendering systems that may be defined by filing
; a registration with IANA.

four-octet = %d0-429496729
; unsigned encoding of 32-bits

nonzero-four-octet = %d1-429496729
; unsigned encoding of 32-bits, ex-zero

uri-element = URI-reference
; as defined in [RFC2396] and [RFC2732]

double-quote = %x22
; presently used are General
MIDI [MIDI], DLS 2 [DLS2], or Structured Audio [MPEGSA]. Note that
the double-quote (") character

token = 1*(token-char)
; copied from [SDP]

token-char = %x21 / %x23-27 / %x2A-2B / %x2D-2E /
%x30-39 / %x41-5A / %x5E-7E
; copied from [SDP]

cid-block = 1*(cid-char)

cid-char = token-char
cid-char /= "@"
cid-char /= ","
cid-char /= ";"
cid-char /= ":"
cid-char /= "\"
cid-char /= "/"
cid-char /= "["
cid-char /= "]"
cid-char /= "?"
cid-char /= "="
;
; add back in maximum inline value for General MIDI is well under 300 octets
(and thus clients need not support the tspecials [RFC2045], except "url" parameter), and that the
maximum inline values for
; double-quote DLS 2 and Structured Audio may be much
larger than 300 octets (and thus clients MUST support the non-email safe () <>
; note that "cid" defined above ensures url
parameter).

We anticipate that
; cid-block is enclosed with double-quotes

; external references
; URI-reference: from [RFC2396] and [RFC2732]

;
; End the owners of ABNF

The mpeg4-generic rendering systems (both standardized
and proprietary) will register subrender parameters for their
renderers. Once registration occurs, native RTP payload [RFC3640] defines a "mode" parameter that
signals MIDI sessions may
use render and subrender (Appendix C.6.2) to specify complete
rendering systems for RTSP content-streaming multimedia sessions.

Servers MUST NOT use the type of MPEG stream in use. We add a new mode value, "rtp-
midi", using sdp_start value for the ABNF rule below:

;
; mpeg4-generic mode smf_info parameter extension
;

mode /= "rtp-midi"
; as described
in Section 6.2 of the reference session description, as this memo

E. A use would require that
clients be able to parse and render Standard MIDI Overview for Networking Specialists

This Appendix presents an overview of the Files.

Clients MUST support mpeg4-generic mode rtp-midi General MIDI standard, for (GM)
sessions, at a polyphony limited by the benefit hardware capabilities of networking specialists new to musical applications. Implementors
should consult [MIDI] for the
client. This requirement provides a normative description "lowest common denominator"
rendering system for content providers to target. Note that this
requirement does not force implementors of MIDI.

Musicians make music by performing a controlled sequence of physical
movements. For example, non-GM renderer (such as
DLS 2 or Structured Audio) to add a pianist plays second rendering engine.
Instead, a client may satisfy the requirement by coordinating including a series set of key
presses, key releases,
voice patches that implement the GM instrument set, and pedal actions. using this
emulation for mpeg4-generic GM sessions.

It is RECOMMENDED that servers use General MIDI represents a musical
performance by encoding these physical gestures as a sequence of MIDI
commands. This high-level musical representation is compact but
fragile: one lost command may be catastrophic the renderer for
the reference session description, because clients are REQUIRED to
support it. We do not require General MIDI as the performance. reference
renderer, because for normative applications it is an inappropriate
choice. Servers using General MIDI commands have much in as a "lowest common with denominator"
renderer SHOULD use Universal Real-Time SysEx MIP message [SPMIDI] to
communicate the machine instructions priority of a
microprocessor. voices to polyphony-limited clients.

C.7.2. MIDI commands are defined Network Musical Performance Applications

In Internet telephony and videoconferencing applications, parties
interact over an IP network as binary elements.
Bitfields within a they would face-to-face. Good user
experiences require low end-to-end audio latency and tight
audiovisual synchronization (for "lip-sync"). The Session Initiation
Protocol (SIP, [RFC3261]) is used for session management.

In this appendix section, we define interoperability guidelines for
using RTP MIDI command have a regular structure streams in interactive SIP applications. Our primary
interest is supporting Network Musical Performances (NMP), where
musicians in different locations interact over the network as if they
were in the same room. See [NMP] for background information on NMP,
and see [RFC4696] for a
specialized purpose. For example, discussion of low-latency RTP MIDI
implementation techniques for NMP.

Note that the upper nibble goal of NMP applications is telepresence: the first command
octet (the opcode field) codes parties
should hear audio that is close to what they would hear if they were
in the command type. same room. The interoperability guidelines in this appendix
address RTP MIDI commands may
consist applications of an arbitrary number this nature, not applications such
as the transmission of complete octets, but most raw MIDI
commands are 1, 2, or 3 octets command streams for use in length.

We focus on session management for two-party unicast sessions that
specify a note) | 1001cccc 0nnnnnnn 0vvvvvvv |
|-------------------------------------------------------------|
| PTouch (Polyphonic Aftertouch) | 1010cccc 0nnnnnnn 0aaaaaaa |
|-------------------------------------------------------------|
| CControl (Controller Change) | 1011cccc 0xxxxxxx 0yyyyyyy |
|-------------------------------------------------------------|
| PChange (Program Change) | 1100cccc 0ppppppp |
|-------------------------------------------------------------|
| CTouch (Channel Aftertouch) | 1101cccc 0aaaaaaa |
|-------------------------------------------------------------|
| PWheel (Pitch Wheel) | 1110cccc 0xxxxxxx 0yyyyyyy |
-------------------------------------------------------------

Figure E.1 -- renderer for RTP MIDI Channel Messages
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| System Common Messages | Bitfield Pattern |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| System Exclusive | 11110000, followed by a |
| | list of 0xxxxxx octets, |
| | followed by 11110111 |
|-------------------------------------------------------------|
| MIDI Time Code Quarter Frame | 11110001 0xxxxxxx |
|-------------------------------------------------------------|
| Song Position Pointer | 11110010 0xxxxxxx 0yyyyyyy |
|-------------------------------------------------------------|
| Song Select | 11110011 0xxxxxxx |
|-------------------------------------------------------------|
| Undefined | 11110100 |
|-------------------------------------------------------------|
| Undefined | 11110101 |
|-------------------------------------------------------------|
| Tune Request | 11110110 |
|-------------------------------------------------------------|
| System Exclusive End Marker | 11110111 |
-------------------------------------------------------------

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| System Realtime Messages | Bitfield Pattern |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| Clock | 11111000 |
|-------------------------------------------------------------|
| Undefined | 11111001 |
|-------------------------------------------------------------|
| Start | 11111010 |
|-------------------------------------------------------------|
| Continue | 11111011 |
|-------------------------------------------------------------|
| Stop | 11111100 |
|-------------------------------------------------------------|
| Undefined | 11111101 |
|-------------------------------------------------------------|
| Active Sense | 11111110 |
|-------------------------------------------------------------|
| System Reset | 11111111 |
-------------------------------------------------------------

Figure E.2 -- MIDI System Messages

Figure E.1 and E.2 show streams. Within this limited scope,
the MIDI command family. There guidelines defined here are three major
classes of commands: voice commands (opcode field values in the range
0x8 through 0xE), system common commands (opcode field 0xF, commands
0xF0 through 0xF7), and system real-time commands (opcode field 0xF,
commands 0xF8 through 0xFF). Voice commands code sufficient to let applications
interoperate. We define the musical gestures
for each timbre in a composition. Systems commands perform functions
that usually affect all voice channels, such as System Reset (0xFF).

E.1 Commands Types

Voice commands execute on one REQUIRED capabilities of 16 RTP MIDI channels, as coded by its 4-bit
channel field (field cccc
senders and receivers in Figure E.1). In most applications, notes
for different timbres NMP sessions and define how session
descriptions exchanged are assigned used to set up network musical performance
sessions.

SIP lets parties negotiate details of the session, using the
Offer/Answer protocol [RFC3264]. However, RTP MIDI has so many
parameters that "blind" negotiations between two parties using
different channels. To support applications that require more than 16 channels, MIDI systems use
several MIDI command streams in parallel, to might not yield 32, 48, or 64 MIDI
channels.

As an example of a voice command, consider common session
configuration.

Thus, we now define a NoteOn command (opcode
0x9), with binary encoding 1001cccc 0nnnnnnn 0aaaaaaa. This command
signals set of capabilities that NMP parties MUST
support. Session description offers whose options lie outside the start
envelope of a musical note on REQUIRED party behavior risk negotiation failure. We
also define session description idioms that the RTP MIDI channel cccc. The note has part of an
offer MUST follow, in order to structure the offer for simpler
analysis.

We use the term "offerer" for the party making a pitch coded by SIP offer, and
"answerer" for the party answering the offer. Finally, we note number nnnnnnn, and an onset amplitude coded that
unless it is qualified by note velocity aaaaaaa.

Other voice commands signal the end of notes (NoteOff, opcode 0x8), map adjective "sender" or "receiver", a specific timbre
statement that a party MUST support X implies that it MUST support X
for both sending and receiving.

If an offerer wishes to define a "sendrecv" RTP MIDI channel (PChange, opcode 0xC), stream, it may
use a true sendrecv session or set the
value of parameters that modulate the timbral quality (all other voice
commands). The exact meaning of most voice channel commands depends on "virtual sendrecv" construction
described in the rendering algorithms preamble to Appendix C and in Appendix C.5. A true
sendrecv session indicates that the MIDI receiver uses offerer wishes to generate sound. In
most applications, participate in
a MIDI sender has session where both parties use identically configured renderers. A
virtual sendrecv session indicates that the offerer is willing to
participate in a model (in some sense) session where the two parties may be using different
renderer configurations. Thus, parties MUST be prepared to see both
real and virtual sendrecv sessions in an offer.

Parties MUST support unicast UDP transport of RTP MIDI streams.
These streams MUST use the
rendering method used by recovery journal with the receiver.

System commands perform a variety of global tasks in closed-loop or
anchor sending policies. These streams MUST use the stream,
including "sequencer" playback control stream
subsetting and chapter inclusion parameters to declare the types of pre-recorded
MIDI commands
(the Song Position Pointer, Song Select, Clock, Start, Continue, and
Stop messages), SMPTE time code (the MIDI Time Code Quarter Frame
command), and that will be sent on the communication of device-specific data (the stream (for sendonly streams)
or will be processed (for recvonly streams), including the size
limits on System Exclusive messages).

E.2 Running Status

All MIDI command bitfields share a special structure: the leading bit commands. Support of
the first octet enhanced Chapter C
encoding is set OPTIONAL.

Note that both TCP and multicast UDP support are OPTIONAL. We make
TCP OPTIONAL because we expect NMP renderers to 1, rely on data objects
(signalled by "rinit" and associated parameters) for initialization
at the leading bit start of all subsequent
octets is set the session, and only to 0. This structure supports a data compression system,
called running status [MIDI], that improves use System Exclusive
commands for interactive control during the coding efficiency of
MIDI.

In running status coding, session. These
interactive commands are small enough to be protected via the first octet
recovery journal mechanism of a RTP MIDI voice command may be
dropped if it is identical to UDP streams.

We now discuss timestamps, packet timing, and packet sending
algorithms.

Recall that the first octet of tsmode parameter controls the previous MIDI voice

command. This rule, semantics of command
timestamps in combination with a convention to consider NoteOn
commands with a null third octet as NoteOff commands, supports the
coding MIDI list of note sequences using two octets per command.

Running status coding is only used for voice commands. The presence RTP packets.

Parties MUST support clock rates of
a system common message in the stream cancels running status mode for 44.1 kHz, 48 kHz, 88.2 kHz, and
96 kHz. Parties MUST support streams using the next voice command. However, system real-time messages do not
cancel running status mode.

E.3 Command Timing

The bitfield formats in Figures E.1 "comex", "async", and E.2 do not encode
"buffer" tsmode values. Recvonly offers MUST offer the execution
time for a command. Timing information is not default
"comex".

Parties MUST support a part wide range of the MIDI
command syntax itself; different applications packet temporal durations: from
rtp_ptime and rtp_maxptime values of the MIDI command
language use different methods 0, to encode timing.

For example, the MIDI command set acts as the transport layer for MIDI
1.0 DIN cables [MIDI]. MIDI cables are short asynchronous serial lines
that facilitate the remote operation of musical instruments rtp_ptime and audio
equipment. Timestamps are not sent over rtp_maxptime
values that code 100 ms. Thus, receivers MUST be able to implement a MIDI 1.0 DIN cable. Instead,
playout buffer.

Offers and answers MUST present rtp_ptime, rtp_maxptime, and
guardtime values that support the standard uses an implicit "time of arrival" code. Receivers execute
MIDI commands at latency that users would expect in
the moment of arrival.

In contrast, Standard MIDI Files (SMFs, [MIDI]), a file format application, subject to bandwidth constraints. As senders MUST
abide by values set for
representing complete musical performances, add these parameters in a explicit timestamp to
each MIDI command, using session description, a delta encoding scheme that is optimized for
statistics of musical performance. SMF timestamps usually code timing
using
receiver SHOULD use these values to size its playout buffer to
produce the metric notation of lowest reliable latency for a musical score. SMF meta-events are used session. Implementers
should refer to add a tempo map [RFC4696] for information on packet sending
algorithms for latency-sensitive applications. Parties MUST be able
to implement the file, so that score beats may be accurately
converted into units semantics of seconds during rendering.

E.4 AudioSpecificConfig templates the guardtime parameter, for MMA renderers

In Section 6.2 and Appendix C.6.5 in this memo, we describe how session
descriptions include an AudioSpecificConfig data block times from
5 ms to 5000 ms.

We now discuss the use of the render parameter.

Sessions MUST specify a MIDI complete rendering algorithm systems for mpeg4-generic all RTP MIDI
streams.

The bitfield format of AudioSpecificConfig is defined in [MPEGAUDIO].
StructuredAudioSpecificConfig, Note that a key data structure coded in
AudioSpecificConfig, minimal RTP MIDI native stream does not meet
this requirement (Section 6.1), as the rendering method for such
streams is defined in [MPEGSA].

For implementors wishing "not specified".

At the time this writing, the only way for parties to specify Structured Audio renderers, a full
understanding of [MPEGSA] and [MPEGAUDIO] are essential. However, many
implementors will limit their
complete rendering options system is to the two specify an mpeg4-generic RTP MIDI
Manufacturers Association renderers that may be specified
stream in
AudioSpecificConfig: General MIDI (GM, [MIDI]) and Downloadable Sounds 2
(DLS 2, [DLS2]).

To aid these implementors, we reproduce the AudioSpecificConfig bitfield
formats for a GM renderer mode rtp-midi (Section 6.2 and a DLS 2 renderer below. C.6.5). We have checked
these bitfields carefully and believe they are correct. However, we
stress anticipate that
the material below is informative, owners of rendering systems (both standardized and [MPEGAUDIO] proprietary)
will register subrender values for their renderers. Once IANA
registration occurs, native RTP MIDI sessions may use render and
[MPEGSA] are the normative definitions
subrender (Appendix C.6.2) to specify complete rendering systems for AudioSpecificConfig.

As described in Section 6.2,
SIP network musical performance multimedia sessions.

All parties MUST support General MIDI (GM) sessions, at a minimal mpeg4-generic session description
encodes polyphony
limited by the AudioSpecificConfig binary bitfield as a hexadecimal string
(whose format is defined in [RFC3640]) that is assigned to hardware capabilities of the "config"
parameter. As described in Appendix C.6.3, party. This requirement
provides a session description that
uses the render parameter encodes the AudioSpecificConfig binary
bitfield as a Base64-encoded string assigned "lowest common denominator" rendering system, without
which practical interoperability will be quite difficult. When using
GM, parties SHOULD use Universal Real-Time SysEx MIP message [SPMIDI]
to communicate the "inline" parameter,
or in the body priority of an HTTP URL assigned voices to polyphony-limited clients.

Note that this requirement does not force implementors of a non-GM
renderer (for mpeg4-generic sessions, DLS 2, or Structured Audio) to
add a second rendering engine. Instead, a client may satisfy the "url" parameter.

Below, we show
requirement by including a simplified binary AudioSpecificConfig bitfield format,
suitable for sending and receiving set of voice patches that implement the GM
instrument set, and DLS 2 data:

0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AOTYPE |FREQIDX|CHANNEL|SACNK| FILE_BLK 1 (required) ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|SACNK| FILE_BLK 2 (optional) ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |1|SACNK| FILE_BLK N (optional) ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| (first "0" bit terminates FILE_BLK list)
+-+-+

Figure E.3 -- Simplified AudioSpecificConfig

The 5-bit AOTYPE field specifies the Audio Object Type as an unsigned
integer. The legal values using this emulation for use with mpeg4-generic RTP MIDI streams
are "15" (General MIDI), "14" (DLS 2), and "13" (Structured Audio).
Thus, receivers GM
sessions. We require GM support so that an offerer that wishes to
maximize interoperability may do so by offering GM if its preferred
renderer is not support all three mpeg4-generic renderers
may parse accepted by the first 5 bits of an AudioSpecificConfig coded answerer.

Offerers MUST NOT present several renderers as options in a session
description, and reject sessions
description by listing several payload types on a media line, as
Section 2.1 uses this construct to let a party send several RTP MIDI
streams in the same RTP session.

Instead, an offerer wishing to present rendering options SHOULD offer
a single payload type that specify unsupported offers several renderers.

The 4-bit FREQIDX field specifies In this
construct, the sampling rate parameter list codes a list of render parameters (each
followed by its support parameters). As discussed in Appendix C.6.1,
the renderer. We
show the mapping order of FREQIDX renderers in the list declares the offerer's preference.
The "unknown" and "null" values MUST NOT appear in the offer. The
answer MUST set all render values except the desired renderer to sampling rates
"null". Thus, "unknown" MUST NOT appear in Figure E.4.
Senders the answer.

We use SHOULD instead of MUST specify a sampling frequency that matches in the first sentence in the paragraph
above, because this technique does not work in all situations
(example: an offerer wishes to offer both mpeg4-generic renderers
and native RTP clock
rate, if possible; if not, senders MIDI renderers as options). In this case, the offerer
MUST specify present a series of session descriptions, each offering a single
renderer, until the escape value.
Receivers answerer accepts a session description.

Parties MUST consult support the RTP clock musicport, chanmask, subrender, rinit, and
inline parameters. Parties supporting renderers whose data object
(as encoded by a parameter value for "inline") could exceed 300
octets in size MUST support the true sampling
rate if the escape value is specified.

FREQIDX Sampling Frequency

0x0 96000
0x1 88200
0x2 64000
0x3 48000
0x4 44100
0x5 32000
0x6 24000
0x7 22050
0x8 16000
0x9 12000
0xa 11025
0xb 8000
0xc reserved
0xd reserved
0xe reserved
0xf escape value

Figure E.4 -- FreqIdx encoding

The 4-bit CHANNEL field specifies the number of audio channels url and cid parameters and thus must
implement HTTP protocol. Note that in mpeg4-generic, General MIDI
data objects cannot exceed 300 octets, but DLS 2 and Structured Audio
data objects may. Support for the
renderer. The values 0x1-0x5 specify 1 to 5 audio channels; the value
0x6 specified 5+1 surround sound, and other rendering parameters
(smf_cif, smf_info, smf_inline, smf_url) is OPTIONAL.

Thus far in this document, our discussion has assumed that the value 0x7 specifies 7+1
surround sound. If only
MIDI flows that drive a renderer are the rtpmap line network flows described in
the session description specifies description. In NMP applications, this assumption would
require two rendering engines: one of these formats, CHANNEL MUST be set for local use by a party, a second
for the remote party.

In practice, applications may wish to have both parties share a
single rendering engine. In this case, the corresponding value.
Otherwise, CHANNEL session description MUST be set
use a virtual sendrecv session and MUST use the stream subsetting and
chapter inclusion parameters to 0x0.

The CHANNEL field is followed allocate which MIDI channels are
intended for use by a list of one or more binary file data
blocks. The 3-bit SACNK field (the chunk_type field in class
StructuredAudioSpecificConfig defined in [MPEGSA]) specifies the type of
each data block.

For General MIDI, only Standard party. If two parties are sharing a MIDI Files may appear in
channels, the list (SACNK
field value 2). For DLS 2, only Standard application MUST ensure that appropriate MIDI Files and DLS 2 RIFF
files (SACNK field value 4) may appear. For both of these file types, merging
occurs at the FILE_BLK field has input to the format shown in Figure E.5: a 32-bit unsigned
integer value (FILE_LEN) coding renderer.

We now discuss the number use of bytes (non-MIDI) audio streams in the SMF or RIFF
file, followed by FILE_LEN bytes coding the file data.

0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FILE_LEN (32-bit, session.

Audio streams may be used for two purposes: as a byte count SMF file "talkback" channel
for parties to converse, or RIFF file) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FILE_DATA (file contents, as a list of FILE_LEN bytes) ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure E.5 -- The FILE_BLK field format

Note way to conduct a performance that several files may follow CHANNEL field. The "1" constant
fields in Figure E.3 code
includes MIDI and audio channels. In the presence of another file; latter case, offers MUST
use sample rates and the "0" constant
field codes packet temporal durations for the end audio and
MIDI streams that support low-latency synchronized rendering.

We now show an example of the list. The final "0" bit an offer/answer exchange in Figure E.3 codes
the absence of special coding tools (see [MPEGAUDIO] for details).
Senders not using these tools MUST append this "0" bit; receivers that
do not understand these coding tools MUST ignore all data following a
"1" network
musical performance application (next page). Below, we show an offer
that complies with the interoperability text in this position. appendix
section.

v=0
o=first 2520644554 2838152170 IN IP4 first.example.net
s=Example
t=0 0
a=group:FID 1 2
c=IN IP4 192.0.2.94
m=audio 16112 RTP/AVP 96
a=recvonly
a=mid:1
a=rtpmap:96 mpeg4-generic/44100
a=fmtp:96 streamtype=5; mode=rtp-midi; config="";
profile-level-id=12; cm_unused=ABCFGHJKMNPQTVWXYZ; cm_used=2NPTW;
cm_used=2C0.1.7.10.11.64.121.123; cm_used=2M0.1.2
cm_used=X0-16; ch_never=ABCDEFGHJKMNPQTVWXYZ;
ch_default=2NPTW; ch_default=2C0.1.7.10.11.64.121.123;
ch_default=2M0.1.2; cm_default=X0-16;
rtp_ptime=0; rtp_maxptime=0; guardtime=44100;
musicport=1; render=synthetic; rinit="audio/asc";
inline="egoAAAAaTVRoZAAAAAYAAAABAGBNVHJrAAAABgD/LwAA"
m=audio 16114 RTP/AVP 96
a=sendonly
a=mid:2
a=rtpmap:96 mpeg4-generic/44100
a=fmtp:96 streamtype=5; mode=rtp-midi; config="";
profile-level-id=12; cm_unused=ABCFGHJKMNPQTVWXYZ; cm_used=1NPTW;
cm_used=1C0.1.7.10.11.64.121.123; cm_used=1M0.1.2
cm_used=X0-16; ch_never=ABCDEFGHJKMNPQTVWXYZ;
ch_default=1NPTW; ch_default=1C0.1.7.10.11.64.121.123;
ch_default=1M0.1.2; cm_default=X0-16;
rtp_ptime=0; rtp_maxptime=0; guardtime=44100;
musicport=1; render=synthetic; rinit="audio/asc";
inline="egoAAAAaTVRoZAAAAAYAAAABAGBNVHJrAAAABgD/LwAA"

(The a=fmtp lines have been wrapped to fit the page to accommodate
memo formatting restrictions; it comprises a single line in SDP.)

The StructuredAudioSpecificConfig bitfield structure requires owner line (o=) identifies the
presence of one FILE_BLK. For mpeg4-generic RTP MIDI use of DLS 2,
FILE_BLKs MUST code RIFF files or SMF files. For mpeg4-generic RTP session owner as "first".

The session description defines two MIDI
use of General MIDI, FILE_BLKs MUST code SMF files. By default, this
SMF will be ignored (Appendix C.6.4.1). In this default case, streams: a GM
StructuredAudioSpecificConfig bitfield SHOULD code recvonly stream
on which "first" receives a FILE_BLK whose
FILE_LEN is 0, performance, and whose FILE_DATA is empty.

To complete this Appendix, we derive a sendonly stream that
"first" uses to send a performance. The recvonly port number encodes
the StructuredAudioSpecificConfig ports on which "first" wishes to receive RTP (16112) and RTCP
(16113) media at IP4 address 192.0.2.94. The sendonly port number
encodes the port on which "first" wishes to receive RTCP for the
stream (16115).

The musicport parameters code that we use in the two streams share and identity
relationship and thus form a virtual sendrecv stream.

Both streams are mpeg4-generic RTP MIDI streams that specify a
General MIDI session examples in this memo.
Referring to Figure E.3, we note renderer. The stream subsetting parameters code that
the recvonly stream uses MIDI channel 1 exclusively for GM, AOTYPE = 15. Our examples
use a 44,100 Hz sample rate (FREQIDX = 4) voice
commands, and are in mono (CHANNEL = 1).
For GM, a single SMF is encoded (SACNK = 2), using that the SMF shown in
Figure E.6 (a 26 byte file).

--------------------------------------------
| sendonly stream uses MIDI File = <Header Chunk> <Track Chunk> |
--------------------------------------------

Where:

<Header Chunk> = <chunk type> <length> <format> <ntrks> <divsn>
4D 54 68 64 00 00 00 06 00 00 00 01 00 60

<Track Chunk> = <chunk type> <length> <delta-time> <end-event>
4D 54 72 6B 00 00 00 04 00 FF 2F 00

Figure E.6 -- SMF file encoded in channel 2
exclusively for voice commands. This mapping permits the example

Placing these constants in binary format into application
software to share a single renderer for local and remote performers.

We now show the data structure shown
in Figure E.3 yields answer to the constant shown in Figure E.7.

0 1 2 3 offer.

v=0
o=second 2520644554 2838152170 IN IP4 second.example.net
s=Example
t=0 0
a=group:FID 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0|
+-+-+

Figure E.7 -- AudioSpecificConfig used in GM examples

Expressing this bitfield as an ASCII hexadecimal string yields:

7A0A0000001A4D546864000000060000000100604D54726B0000000600FF2F000

This string is assigned
c=IN IP4 192.0.2.105
m=audio 5004 RTP/AVP 96
a=sendonly
a=mid:1
a=rtpmap:96 mpeg4-generic/44100
a=fmtp:96 streamtype=5; mode=rtp-midi; config="";
profile-level-id=12; cm_unused=ABCFGHJKMNPQTVWXYZ; cm_used=2NPTW;
cm_used=2C0.1.7.10.11.64.121.123; cm_used=2M0.1.2
cm_used=X0-16; ch_never=ABCDEFGHJKMNPQTVWXYZ;
ch_default=2NPTW; ch_default=2C0.1.7.10.11.64.121.123;
ch_default=2M0.1.2; cm_default=X0-16;
rtp_ptime=0; rtp_maxptime=882; guardtime=44100;
musicport=1; render=synthetic; rinit="audio/asc";
inline="egoAAAAaTVRoZAAAAAYAAAABAGBNVHJrAAAABgD/LwAA"
m=audio 5006 RTP/AVP 96
a=recvonly
a=mid:2
a=rtpmap:96 mpeg4-generic/44100
a=fmtp:96 streamtype=5; mode=rtp-midi; config="";
profile-level-id=12; cm_unused=ABCFGHJKMNPQTVWXYZ; cm_used=1NPTW;
cm_used=1C0.1.7.10.11.64.121.123; cm_used=1M0.1.2
cm_used=X0-16; ch_never=ABCDEFGHJKMNPQTVWXYZ;
ch_default=1NPTW; ch_default=1C0.1.7.10.11.64.121.123;
ch_default=1M0.1.2; cm_default=X0-16;
rtp_ptime=0; rtp_maxptime=0; guardtime=88200;
musicport=1; render=synthetic; rinit="audio/asc";
inline="egoAAAAaTVRoZAAAAAYAAAABAGBNVHJrAAAABgD/LwAA"

(The a=fmtp lines have been wrapped to fit the "config" parameter page to accommodate
memo formatting restrictions; they comprise single lines in SDP.)

The owner line (o=) identifies the minimal
mpeg4-generic General MIDI examples in this memo (such session owner as "second".

The port numbers for both media streams are non-zero; thus, "second"
has accepted the example in
Section 6.2). Expressing this string session description. The stream marked "sendonly"
in Base64 [RFC2045] yields:

egoAAAAaTVRoZAAAAAYAAAABAGBNVHJrAAAABgD/LwAA

This string is assigned to the "inline" parameter offer is marked "recvonly" in the General MIDI
example shown in Appendix C.6.5.

F. Acknowledgements

We thank answer, and vice versa,
coding the networking, media compression, different view of the session held by "session". The IP4
number (192.0.2.105) and computer music community
members who the RTP (5004 and 5006) and RTCP (5005 and
5007) have commented or contributed been changed by "second" to match its transport wishes.

In addition, "second" has made several parameter changes:
rtp_maxptime for the effort, including Kurt
B, Cynthia Bruyns, Steve Casner, Paul Davis, Robin Davies, Joanne Dow,
Tobias Erichsen, Nicolas Falquet, Dominique Fober, Philippe Gentric,
Michael Godfrey, Chris Grigg, Todd Hager, Michel Jullian, Phil Kerr,
Young-Kwon Lim, Jessica Little, Jan van der Meer, Colin Perkins, Charlie
Richmond, Herbie Robinson, Larry Rowe, Eric Scheirer, Dave Singer,
Martijn Sipkema, William Stewart, Kent Terry, Magnus Westerlund, Tom
White, Jim Wright, Doug Wyatt, sendonly stream has been changed to code 2 ms
(441 in clock units), and Giorgio Zoia. We the guardtime for the recvonly stream has
been doubled. As these parameter modifications request capabilities
that are REQUIRED to be implemented by interoperable parties,
"second" can make these changes with confidence that "first" can
abide by them.

D. Parameter Syntax Definitions

In this appendix, we define the syntax for the RTP MIDI media type
parameters in Augmented Backus-Naur Form (ABNF, [RFC4234]). When
using these parameters with SDP, all parameters MUST appear on a
single fmtp attribute line of an RTP MIDI media description. For
mpeg4-generic RTP MIDI streams, this line MUST also thank include any
mpeg4-generic parameters (usage described in Section 6.2). An fmtp
attribute line may be defined (after [RFC3640]) as:

;
; SDP fmtp line definition
;

fmtp = "a=fmtp:" token SP param-assign 0*(";" SP param-assign) CRLF

where <token> codes the
members RTP payload type. Note that white space MUST
NOT appear between the "a=fmtp:" and the RTP payload type.

We now define the syntax of the San Francisco Bay Area music parameters defined in Appendix C.
The definition takes the form of the incremental assembly of the
<param-assign> token. See [RFC3640] for the syntax of the
mpeg4-generic parameters discussed in Section 6.2.

;
;
; top-level definition for all parameters
;
;

;
; Parameters defined in Appendix C.1

param-assign = ("cm_unused=" (([channel-list] command-type
[f-list]) / sysex-data))

param-assign =/ ("cm_used=" (([channel-list] command-type
[f-list]) / sysex-data))
;
; Parameters defined in Appendix C.2

param-assign =/ ("j_sec=" ("none" / "recj" / *ietf-extension))

param-assign =/ ("j_update=" ("anchor" / "closed-loop" /
"open-loop" / *ietf-extension))

param-assign =/ ("ch_default=" (([channel-list] chapter-list
[f-list]) / sysex-data))

param-assign =/ ("ch_never=" (([channel-list] chapter-list
[f-list]) / sysex-data))

param-assign =/ ("ch_anchor=" (([channel-list] chapter-list
[f-list]) / sysex-data))

;
; Parameters defined in Appendix C.3

param-assign =/ ("tsmode=" ("comex" / "async" / "buffer"))

param-assign =/ ("linerate=" nonzero-four-octet)

param-assign =/ ("octpos=" ("first" / "last"))

param-assign =/ ("mperiod=" nonzero-four-octet)

;
; Parameter defined in Appendix C.4

param-assign =/ ("guardtime=" nonzero-four-octet)

param-assign =/ ("rtp_ptime=" four-octet)

param-assign =/ ("rtp_maxptime=" four-octet)

;
; Parameters defined in Appendix C.5

param-assign =/ ("musicport=" four-octet)
;
; Parameters defined in Appendix C.6

param-assign =/ ("chanmask=" ( 1*( 16( "0" / "1" ) )))

param-assign =/ ("cid=" double-quote cid-block
double-quote)

param-assign =/ ("inline=" double-quote base-64-block
double-quote)

param-assign =/ ("multimode=" ("all" / "one"))

param-assign =/ ("render=" ("synthetic" / "api" / "null" /
"unknown" / *extension))

param-assign =/ ("rinit=" mime-type "/" mime-subtype)

param-assign =/ ("smf_cid=" double-quote cid-block
double-quote)

param-assign =/ ("smf_info=" ("ignore" / "identity" /
"sdp_start" / *extension))

param-assign =/ ("smf_inline=" double-quote base-64-block
double-quote)

param-assign =/ ("smf_url=" double-quote uri-element
double-quote)

param-assign =/ ("subrender=" ("default" / *extension))

param-assign =/ ("url=" double-quote uri-element
double-quote)

;
; list definitions for the cm_ command-type
;

command-type = command-part1 command-part2 command-part3

command-part1 = (*1"A") (*1"B") (*1"C") (*1"F") (*1"G") (*1"H")

command-part2 = (*1"J") (*1"K") (*1"M") (*1"N") (*1"P") (*1"Q")

command-part3 = (*1"T") (*1"V") (*1"W") (*1"X") (*1"Y") (*1"Z")
;
; list definitions for the ch_ chapter-list
;

chapter-list = ch-part1 ch-part2 ch-part3

ch-part1 = (*1"A") (*1"B") (*1"C") (*1"D") (*1"E") (*1"F") (*1"G")

ch-part2 = (*1"H") (*1"J") (*1"K") (*1"M") (*1"N") (*1"P") (*1"Q")

ch-part3 = (*1"T") (*1"V") (*1"W") (*1"X") (*1"Y") (*1"Z")

;
; list definitions for the ch_ channel-list
;

channel-list = midi-chan-element *("." midi-chan-element)

midi-chan-element = midi-chan / midi-chan-range

midi-chan-range = midi-chan "-" midi-chan

; decimal value of left midi-chan
; MUST be strictly less than decimal
; value of right midi-chan

midi-chan = %d0-15

;
; list definitions for the ch_ field list (f-list)
;

f-list = midi-field-element *("." midi-field-element)

midi-field-element = midi-field / midi-field-range

midi-field-range = midi-field "-" midi-field
;
; decimal value of left midi-field
; MUST be strictly less than decimal
; value of right midi-field

midi-field = four-octet
;
; large range accommodates Chapter M
; RPN (0-16383) and audio community NRPN (16384-32767)
; parameters, and Chapter X octet sizes.

;
; definitions for ch_ sysex-data
;

sysex-data = "__" h-list *("_" h-list) "__"

h-list = hex-field-element *("." hex-field-element)

hex-field-element = hex-octet / hex-field-range

hex-field-range = hex-octet "-" hex-octet
;
; hexadecimal value of left hex-octet
; MUST be strictly less than hexadecimal
; value of right hex-octet

;
; definitions for rinit parameter
;

mime-type = "audio" / "application"

mime-subtype = token
;
; See Appendix C.6.2 for registration
; requirements for rinit type/subtypes.

;
; definitions for base64 encoding
; copied from [RFC4566]

base-64-block = *base64-unit [base64-pad]

base64-unit = 4base64-char

base64-pad = 2base64-char "==" / 3base64-char "="

base64-char = %x41-5A / %x61-7A / %x30-39 / "+" / "/"
; A-Z, a-z, 0-9, "+" and "/"
;
; generic rules
;

ietf-extension = token
;
; ietf-extension may only be defined in
; standards-track RFCs.

extension = token
;
; extension may be defined by filing
; a registration with IANA.

four-octet = %d0-4294967295
; unsigned encoding of 32-bits

nonzero-four-octet = %d1-4294967295
; unsigned encoding of 32-bits, ex-zero

uri-element = URI-reference
; as defined in [RFC3986]

double-quote = %x22

; the double-quote (") character

token = 1*token-char
; copied from [RFC4566]

token-char = %x21 / %x23-27 / %x2A-2B / %x2D-2E /
%x30-39 / %x41-5A / %x5E-7E
; copied from [RFC4566]

cid-block = 1*cid-char

cid-char = token-char
cid-char =/ "@"
cid-char =/ ","
cid-char =/ ";"
cid-char =/ ":"
cid-char =/ "
cid-char =/ "/"
cid-char =/ "["
cid-char =/ "]"
cid-char =/ "?"
cid-char =/ "="
;
; add back in the tspecials [RFC2045], except for
; double-quote and the non-email safe () <>
; note that "cid" defined above ensures that
; cid-block is enclosed with double-quotes

; external references
; URI-reference: from [RFC3986]

;
; End of ABNF

The mpeg4-generic RTP payload [RFC3640] defines a "mode" parameter
that signals the type of MPEG stream in use. We add a new mode
value, "rtp-midi", using the ABNF rule below:

;
; mpeg4-generic mode parameter extension
;

mode =/ "rtp-midi"
; as described in Section 6.2 of this memo

E. A MIDI Overview for
creating Networking Specialists

This appendix presents an overview of the context MIDI standard, for the work, including Don Buchla, Chris Chafe,
Richard Duda, Dan Ellis, Adrian Freed, Ben Gold, Jaron Lanier, Roger
Linn, Richard Lyon, Dana Massie, Max Mathews, Keith McMillen, Carver
Mead, Nelson Morgan, Tom Oberheim, Malcolm Slaney, Dave Smith, Julius
Smith, David Wessel, and Matt Wright.

G. Security Considerations
benefit of networking specialists new to musical applications.
Implementors should carefully read the Security Considerations sections consult [MIDI] for a normative description of the RTP [RFC3550], AVP [RFC3551],
MIDI.

Musicians make music by performing a controlled sequence of physical
movements. For example, a pianist plays by coordinating a series of
key presses, key releases, and other RTP profile documents, pedal actions. MIDI represents a
musical performance by encoding these physical gestures as a sequence
of MIDI commands. This high-level musical representation is compact
but fragile: one lost command may be catastrophic to the issues discussed performance.

MIDI commands have much in these sections directly apply to RTP common with the machine instructions of a
microprocessor. MIDI
streams. Implementors should also review commands are defined as binary elements.
Bitfields within a MIDI command have a regular structure and a
specialized purpose. For example, the Secure Real-time Transport
Protocol (SRTP, [RFC3711]), an RTP profile that addresses upper nibble of the security
issues discussed in [RFC3550] [RFC3551].

In this Appendix, we discuss security issues that are unique to first
command octet (the opcode field) codes the RTP command type. MIDI payload format.

When using RTP MIDI, authentication of incoming RTP and RTCP packets is
RECOMMENDED. Per-packet authentication
commands may be provided by SRTP consist of an arbitrary number of complete octets, but
most MIDI commands are 1, 2, or 3 octets in length.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| Channel Voice Messages | Bitfield Pattern |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| NoteOff (end a note) | 1000cccc 0nnnnnnn 0vvvvvvv |
|-------------------------------------------------------------|
| NoteOn (start a note) | 1001cccc 0nnnnnnn 0vvvvvvv |
|-------------------------------------------------------------|
| PTouch (Polyphonic Aftertouch) | 1010cccc 0nnnnnnn 0aaaaaaa |
|-------------------------------------------------------------|
| CControl (Controller Change) | 1011cccc 0xxxxxxx 0yyyyyyy |
|-------------------------------------------------------------|
| PChange (Program Change) | 1100cccc 0ppppppp |
|-------------------------------------------------------------|
| CTouch (Channel Aftertouch) | 1101cccc 0aaaaaaa |
|-------------------------------------------------------------|
| PWheel (Pitch Wheel) | 1110cccc 0xxxxxxx 0yyyyyyy |
-------------------------------------------------------------

Figure E.1 -- MIDI Channel Messages
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| System Common Messages | Bitfield Pattern |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| System Exclusive | 11110000, followed by
other means. Without the use a |
| | list of authentication, attackers could forge 0xxxxxx octets, |
| | followed by 11110111 |
|-------------------------------------------------------------|
| MIDI Time Code Quarter Frame | 11110001 0xxxxxxx |
|-------------------------------------------------------------|
| Song Position Pointer | 11110010 0xxxxxxx 0yyyyyyy |
|-------------------------------------------------------------|
| Song Select | 11110011 0xxxxxxx |
|-------------------------------------------------------------|
| Undefined | 11110100 |
|-------------------------------------------------------------|
| Undefined | 11110101 |
|-------------------------------------------------------------|
| Tune Request | 11110110 |
|-------------------------------------------------------------|
| System Exclusive End Marker | 11110111 |
-------------------------------------------------------------

Figure E.2 -- MIDI commands into an ongoing stream, damaging speakers and eardrums.
An attacker could also craft RTP and RTCP packets to exploit known bugs
in the client, System Messages
Figure E.1 and take effective control of a client machine.

Session management tools (such as SIP [RFC3261]) SHOULD use
authentication during the transport of all session descriptions
containing RTP MIDI media streams. For SIP, E.2 show the Security Considerations
section in [RFC3261] provides an overview of possible authentication
mechanisms. RTP MIDI session descriptions should use authentication
because the session descriptions may code initialization data using the
parameters described in Appendix C. If an attacker inserts bogus
initialization data into a session description, he can corrupt the
session or forge an client attack.

Session descriptions may also code renderer initialization data by
reference, via the url (Appendix C.6.3) and smf_url (Appendix C.6.4.2)
parameters. If the coded URL is spoofed, both session and client command family. There are
open to attack, even if the session description itself is authenticated.
Therefore, URLs specified in url and smf_url parameters SHOULD use
[RFC2818].

Section 2.1 allows streams sent by a party three
major classes of commands: voice commands (opcode field values in two RTP sessions to have the same SSRC value
range 0x8 through 0xE), system common commands (opcode field 0xF,
commands 0xF0 through 0xF7), and system real-time commands (opcode
field 0xF, commands 0xF8 through 0xFF). Voice commands code the same RTP timestamp initialization value,
under certain circumstances. Normally, these values are randomly chosen
musical gestures for each stream timbre in a session, to make plaintext guessing harder to do if
the payloads are encrypted. Thus, Section 2.1 weakens this aspect of
RTP security.

H. IANA Considerations

This Appendix makes a series of requests to IANA. Thus, we begin with
an outline of our requests. The sub-appendices composition. Systems commands
perform functions that follow hold the
actual, detailed requests. All registrations in this Appendix are in
the IETF tree, and follow the rules of [MTYPE] and [RFC3555] usually affect all voice channels, such as
appropriate.

In Appendix H.1, we request the registration
System Reset (0xFF).

E.1. Commands Types

Voice commands execute on one of a new media type:
"audio/rtp-midi". Paired with this request is a request for a
repository for new values for several parameters associated with
"audio/rtp-midi". We request this repository 16 MIDI channels, as coded by its
4-bit channel field (field cccc in Appendix H.1.1. Figure E.1). In Appendix H.2, we request the registration of a new value ("rtp-midi")
for the "mode" parameter of the "mpeg4-generic" media type, in Appendix
H.2. The "mpeg4-generic" media type is defined in [RFC3640], and
[RFC3640] defines a repository most
applications, notes for the "mode" parameter. However, we
believe we different timbres are the first assigned to request the registration of a "mode" value,
and so we believe the registry for "mode" has not yet been created by
IANA.

Paired with our "mode" parameter value request for "mpeg4-generic" is a
request for a repository for new values for several parameters we have
defined for different
channels. To support applications that require more than 16
channels, MIDI systems use with the "rtp-midi" mode value. We request this
repository several MIDI command streams in Appendix H.2.1.

In Appendix H.3, we request the registration parallel,
to yield 32, 48, or 64 MIDI channels.

As an example of a new media type:
"audio/asc". No repository request is associated voice command, consider a NoteOn command (opcode
0x9), with this request.

H.1 rtp-midi Media Type Registration binary encoding 1001cccc 0nnnnnnn 0aaaaaaa. This Appendix requests command
signals the registration start of a musical note on MIDI channel cccc. The note
has a pitch coded by the "rtp-midi" subtype for
the "audio" media type. We request note number nnnnnnn, and an onset amplitude
coded by note velocity aaaaaaa.

Other voice commands signal the registration end of notes (NoteOff, opcode 0x8),
map a specific timbre to a MIDI channel (PChange, opcode 0xC), or set
the value of parameters
listed in the "optional parameters" section below (both the "non-
extensible parameters" and the "extensible parameters" lists). We also
request that modulate the creation timbral quality (all other
voice commands). The exact meaning of repositories for most voice channel commands
depends on the "extensible parameters"; rendering algorithms the details of this request appear in Appendix H.1.1 below.

Media type name:

audio

Subtype name:

rtp-midi

Required parameters:

rate: The RTP timestamp clock rate. See Sections 2.1 and 6.1
for usage details.

Optional parameters:

Non-extensible parameters:

Extensible parameters:

j_sec: See Appendix C.2.1 for usage details. See
Appendix H.1.1 for repository details.
j_update: See Appendix C.2.2 for usage details. See
Appendix H.1.1 for repository details.
render: See Appendix C.6 for usage details. See
Appendix H.1.1 for repository details.
subrender: See Appendix C.6.2 for usage details. See
Appendix H.1.1 for repository details.
smf_info: See Appendix C.6.4.1 for usage details. See
Appendix H.1.1 for repository details.

Encoding considerations:

The format for this type is framed and binary.

Restrictions on usage:

This type is only defined for real-time transfers of MIDI
streams via RTP. Stored-file semantics for rtp-midi may
be defined in the future.

Security considerations:

See Appendix G receiver uses to
generate sound. In most applications, a MIDI sender has a model (in
some sense) of this memo.

Interoperability considerations:

None.

Published specification:

This memo and [MIDI] serve as the normative specification. In
addition, references [NMP], [GRAME], and [GUIDE] provide
non-normative implementation guidance.

Applications which use this media type:

Audio content-creation hardware, such as rendering method used by the receiver.

System commands perform a variety of global tasks in the stream,
including "sequencer" playback control of pre-recorded MIDI controller piano
keyboards commands
(the Song Position Pointer, Song Select, Clock, Start, Continue, and
Stop messages), SMPTE time code (the MIDI audio synthesizers. Audio content-creation
software, such as music sequencers, digital audio workstations, Time Code Quarter Frame
command), and soft synthesizers. Computer operating systems, for network
support the communication of device-specific data (the System
Exclusive messages).

E.2. Running Status

All MIDI Application Programmer Interfaces. Content
distribution servers and terminals may use this media type for
low bit-rate music coding.

Additional information:

None.

Person & email address to contact for further information:

John Lazzaro <lazzaro@cs.berkeley.edu>

Intended usage:

COMMON.

Author:

John Lazzaro <lazzaro@cs.berkeley.edu>

Change Controller:

IETF Audio/Video Transport Working Group delegated
from command bitfields share a special structure: the IESG.

H.1.1 Repository request for "audio/rtp-midi"

For leading bit
of the "rtp-midi" subtype, we request first octet is set to 1, and the creation leading bit of repositories for
extensions all subsequent
octets is set to 0. This structure supports a data compression
system, called running status [MIDI], that improves the following parameters (which are those listed as
"extensible parameters" in Appendix H.1).

j_sec:

Registrations for this repository may only occur
via an IETF standards-track document. Appendix C.2.1 coding
efficiency of this memo describes appropriate registrations for this
repository.

Initial values for this repository appear below:

"none": Defined in Appendix C.2.1 MIDI.

In running status coding, the first octet of this memo.
"recj": Defined a MIDI voice command may
be dropped if it is identical to the first octet of the previous MIDI
voice command. This rule, in Appendix C.2.1 combination with a convention to
consider NoteOn commands with a null third octet as NoteOff commands,
supports the coding of this memo.

j_update:

Registrations for this repository may note sequences using two octets per command.

Running status coding is only occur
via an IETF standards-track document. Appendix C.2.2
of this memo describes appropriate registrations for this
repository.

Initial values used for this repository appear below:

"anchor": Defined in Appendix C.2.2 voice commands. The presence
of this memo.
"open-loop": Defined a system common message in Appendix C.2.2 of this memo.
"closed-loop": Defined the stream cancels running status mode
for the next voice command. However, system real-time messages do
not cancel running status mode.

E.3. Command Timing

The bitfield formats in Appendix C.2.2 of this memo.

render:

Registrations Figures E.1 and E.2 do not encode the
execution time for this repository MUST include a
specification command. Timing information is not a part of
the usage MIDI command syntax itself; different applications of the proposed value.
See text in MIDI
command language use different methods to encode timing.

For example, the preamble of Appendix C.6 MIDI command set acts as the transport layer for details
(the paragraph
MIDI 1.0 DIN cables [MIDI]. MIDI cables are short asynchronous
serial lines that begins "Other render token ...").

Initial values for this repository appear below:

"unknown": Defined in Appendix C.6 of this memo.
"synthetic": Defined in Appendix C.6 facilitate the remote operation of this memo.
"api": Defined in Appendix C.6 musical
instruments and audio equipment. Timestamps are not sent over a MIDI
1.0 DIN cable. Instead, the standard uses an implicit "time of this memo.
"null": Defined in Appendix C.6
arrival" code. Receivers execute MIDI commands at the moment of this memo.

subrender:

Registrations
arrival.

In contrast, Standard MIDI Files (SMFs, [MIDI]), a file format for this repository MUST include
representing complete musical performances, add an explicit timestamp
to each MIDI command, using a
specification delta encoding scheme that is optimized
for statistics of musical performance. SMF timestamps usually code
timing using the usage metric notation of a musical score. SMF meta-events
are used to add a tempo map to the proposed value.
See text Appendix C.6.2 for details (the paragraph file, so that begins "Other subrender token ...").

Initial values for this repository appear below:

"default": Defined in Appendix C.6.2 score beats may be
accurately converted into units of this memo.

smf_info:

Registrations seconds during rendering.

E.4. AudioSpecificConfig Templates for this repository MUST MMA Renderers

In Section 6.2 and Appendix C.6.5, we describe how session
descriptions include an AudioSpecificConfig data block to specify a
specification
MIDI rendering algorithm for mpeg4-generic RTP MIDI streams.

The bitfield format of the usage AudioSpecificConfig is defined in [MPEGAUDIO].
StructuredAudioSpecificConfig, a key data structure coded in
AudioSpecificConfig, is defined in [MPEGSA].

For implementors wishing to specify Structured Audio renderers, a
full understanding of [MPEGSA] and [MPEGAUDIO] is essential.
However, many implementors will limit their rendering options to the proposed value.
See text
two MIDI Manufacturers Association renderers that may be specified in Appendix C.6.4.1
AudioSpecificConfig: General MIDI (GM, [MIDI]) and Downloadable
Sounds 2 (DLS 2, [DLS2]).

To aid these implementors, we reproduce the AudioSpecificConfig
bitfield formats for details (the
paragraph a GM renderer and a DLS 2 renderer below. We
have checked these bitfields carefully and believe they are correct.
However, we stress that begins "Other smf_info token ...").

Initial values the material below is informative, and that
[MPEGAUDIO] and [MPEGSA] are the normative definitions for this repository appear below:

"ignore": Defined
AudioSpecificConfig.

As described in Appendix C.6.4.1 of this memo.
"sdp_start": Defined Section 6.2, a minimal mpeg4-generic session
description encodes the AudioSpecificConfig binary bitfield as a
hexadecimal string (whose format is defined in Appendix C.6.4.1 of this memo.
"identity": Defined [RFC3640]) that is
assigned to the "config" parameter. As described in Appendix C.6.4.1 of this memo.

H.2 mpeg4-generic Media Type Registration

This Appendix requests C.6.3,
a session description that uses the registration of render parameter encodes the "rtp-midi" value for
AudioSpecificConfig binary bitfield as a Base64-encoded string
assigned to the
"mode" parameter "inline" parameter, or in the body of an HTTP URL
assigned to the "mpeg4-generic" media type. The "mpeg4-generic"
media type is defined in [RFC3640], and [RFC3640] defines "url" parameter.

Below, we show a repository simplified binary AudioSpecificConfig bitfield
format, suitable for sending and receiving GM and DLS 2 data:

Figure E.3 -- Simplified AudioSpecificConfig

The 5-bit AOTYPE field specifies the "mode" parameter. We are registering mode rtp-midi to support
the MPEG Audio codecs [MPEGSA] that Object Type as an unsigned
integer. The legal values for use MIDI.

In conjunction with this registration request, we request mpeg4-generic RTP MIDI
streams are "15" (General MIDI), "14" (DLS 2), and "13" (Structured
Audio). Thus, receivers that do not support all three mpeg4-generic
renderers may parse the

registration first 5 bits of the parameters listed an AudioSpecificConfig coded
in the "optional parameters"
section below (both the "non-extensible parameters" a session description and reject sessions that specify unsupported
renderers.

The 4-bit FREQIDX field specifies the "extensible
parameters" lists). We also request the creation sampling rate of repositories for the "extensible parameters"; renderer.
We show the details mapping of this request appear FREQIDX values to sampling rates in
Appendix H.2.1 below.

Media type name:

audio

Subtype name:

mpeg4-generic

Required parameters:

The "mode" parameter is required by [RFC3640]. [RFC3640] requests Figure
E.4. Senders MUST specify a repository for "mode", so that new values for mode
may be added. We request sampling frequency that matches the value "rtp-midi" be
added to the "mode" repository.

In mode rtp-midi, RTP
clock rate, if possible; if not, senders MUST specify the mpeg4-generic parameter rate is
a required parameter. Rate specifies escape
value. Receivers MUST consult the RTP timestamp clock rate. See Sections 2.1 and 6.2 parameter for usage details
of the true
sampling rate in mode rtp-midi.

Optional parameters:

We request registration of if the following parameters
for use in mode rtp-midi for mpeg4-generic.

Non-extensible parameters:

multimode: See Appendix C.6.1 for usage details.
musicport: See Appendix C.5 for usage details.
octpos: See Appendix C.3 for usage details.
rinit: See Appendix C.6.3 for usage details.
rtp_maxptime: See Appendix C.4.1 for usage details.
rtp_ptime: See Appendix C.4.1 for usage details.
smf_cid: See Appendix C.6.4.2 for usage details.
smf_inline: See Appendix C.6.4.2 for usage details.
smf_url: See Appendix C.6.4.2 for usage details.
tsmode: See Appendix C.3 for usage details.
url: See Appendix C.6.3 for usage details.

Extensible parameters:

j_sec: See Appendix C.2.1 for usage details. See
Appendix H.2.1 for repository details.
j_update: See Appendix C.2.2 for usage details. See
Appendix H.2.1 for repository details.
render: See Appendix C.6 for usage details. See
Appendix H.2.1 for repository details.
subrender: See Appendix C.6.2 for usage details. See
Appendix H.2.1 for repository details.
smf_info: See Appendix C.6.4.1 for usage details. See
Appendix H.2.1 for repository details.

Encoding considerations:

The format for this type escape value is framed and binary.

Restrictions on usage:

Only defined for real-time transfers of audio/mpeg4-generic
RTP streams with mode=rtp-midi.

Security considerations:

See Appendix G of this memo.

Interoperability considerations:

Except for the marker bit (Section 2.1), specified.

FREQIDX Sampling Frequency

0x0 96000
0x1 88200
0x2 64000
0x3 48000
0x4 44100
0x5 32000
0x6 24000
0x7 22050
0x8 16000
0x9 12000
0xa 11025
0xb 8000
0xc reserved
0xd reserved
0xe reserved
0xf escape value

Figure E.4 -- FreqIdx encoding

The 4-bit CHANNEL field specifies the packet formats number of audio channels for audio/rtp-midi and audio/mpeg4-generic (mode rtp-midi)
are identical.
the renderer. The formats differ in use: audio/mpeg4-generic
is for MPEG work, audio/rtp-midi is for all other work.

Published specification:

This memo, [MIDI], and [MPEGSA] are values 0x1 to 0x5 specify 1 to 5 audio channels;
the normative references.
In addition, references [NMP], [GRAME], and [GUIDE] provide
non-normative implementation guidance.

Applications which use this media type:

MPEG 4 servers value 0x6 specifies 5+1 surround sound, and terminals that support [MPEGSA].

Additional information:

None.

Person & email address to contact for further information:

John Lazzaro <lazzaro@cs.berkeley.edu>

Intended usage:

COMMON.

Author:

John Lazzaro <lazzaro@cs.berkeley.edu>

Change Controller:

IETF Audio/Video Transport Working Group delegated
from the IESG.

H.2.1 Repository request for mode rtp-midi for mpeg4-generic

For mode rtp-midi of value 0x7
specifies 7+1 surround sound. If the mpeg4-generic subtype, we request rtpmap line in the creation session
description specifies one of repositories for extensions these formats, CHANNEL MUST be set to
the following parameters (which are
those listed as "extensible parameters" in Appendix H.2).

j_sec:

Registrations for this repository may only occur
via an IETF standards-track document. Appendix C.2.1 corresponding value. Otherwise, CHANNEL MUST be set to 0x0.

The CHANNEL field is followed by a list of this memo describes appropriate registrations for this
repository.

Initial values for this repository appear below:

"none": Defined one or more binary file
data blocks. The 3-bit SACNK field (the chunk_type field in Appendix C.2.1 of this memo.
"recj": Defined class
StructuredAudioSpecificConfig, defined in Appendix C.2.1 [MPEGSA]) specifies the
type of this memo.

j_update:

Registrations for this repository may each data block.

For General MIDI, only occur
via an IETF standards-track document. Appendix C.2.2
of this memo describes appropriate registrations for this
repository.

Initial values for this repository Standard MIDI Files may appear below:

"anchor": Defined in Appendix C.2.2 of this memo.
"open-loop": Defined in Appendix C.2.2 the list
(SACNK field value 2). For DLS 2, only Standard MIDI Files and DLS 2
RIFF files (SACNK field value 4) may appear. For both of this memo.
"closed-loop": Defined these file
types, the FILE_BLK field has the format shown in Appendix C.2.2 of this memo.

render:

Registrations for this repository MUST include Figure E.5: a
specification of 32-
bit unsigned integer value (FILE_LEN) coding the usage number of the proposed value.
See text bytes in
the preamble SMF or RIFF file, followed by FILE_LEN bytes coding the file
data.

0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FILE_LEN (32-bit, a byte count SMF file or RIFF file) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FILE_DATA (file contents, a list of Appendix C.6 for details
(the paragraph FILE_LEN bytes) ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure E.5 -- The FILE_BLK field format

Note that begins "Other render token ...").

Initial values for this repository appear below:

"unknown": Defined several files may follow CHANNEL field. The "1" constant
fields in Appendix C.6 Figure E.3 code the presence of this memo.
"synthetic": Defined in Appendix C.6 another file; the "0"
constant field codes the end of this memo.
"null": Defined the list. The final "0" bit in Appendix C.6
Figure E.3 codes the absence of this memo.

subrender:

Registrations special coding tools (see [MPEGAUDIO]
for details). Senders not using these tools MUST append this repository "0"
bit; receivers that do not understand these coding tools MUST include ignore
all data following a
specification of "1" in this position.

The StructuredAudioSpecificConfig bitfield structure requires the usage
presence of the proposed value.
See text Appendix C.6.2 for details (the paragraph
that begins "Other subrender token ..." and
subsequent paragraphs). Note that the text in
Appendix C.6.2 contains restrictions on subrender
registrations for one FILE_BLK. For mpeg4-generic ("Registrations
for RTP MIDI use of DLS 2,
FILE_BLKs MUST code RIFF files or SMF files. For mpeg4-generic subrender values ...").

Initial values for this repository appear below:

"default": Defined in Appendix C.6.2 RTP
MIDI use of General MIDI, FILE_BLKs MUST code SMF files. By default,
this memo.

smf_info:

Registrations for SMF will be ignored (Appendix C.6.4.1). In this repository MUST include default case, a
specification of
GM StructuredAudioSpecificConfig bitfield SHOULD code a FILE_BLK
whose FILE_LEN is 0, and whose FILE_DATA is empty.

To complete this appendix, we derive the usage of
StructuredAudioSpecificConfig that we use in the proposed value.
See text General MIDI session
examples in Appendix C.6.4.1 for details (the
paragraph this memo. Referring to Figure E.3, we note that begins "Other smf_info token ...").

Initial values for this repository appear below:

"ignore": Defined GM,
AOTYPE = 15. Our examples use a 44,100 Hz sample rate (FREQIDX = 4)
and are in Appendix C.6.4.1 of this memo.
"sdp_start": Defined mono (CHANNEL = 1). For GM, a single SMF is encoded
(SACNK = 2), using the SMF shown in Appendix C.6.4.1 of this memo.
"identity": Defined Figure E.6 (a 26 byte file).

--------------------------------------------
| MIDI File = <Header Chunk> <Track Chunk> |
--------------------------------------------

<Header Chunk> = <chunk type> <length> <format> <ntrks> <divsn>
4D 54 68 64 00 00 00 06 00 00 00 01 00 60

<Track Chunk> = <chunk type> <length> <delta-time> <end-event>
4D 54 72 6B 00 00 00 04 00 FF 2F 00

Figure E.6 -- SMF file encoded in the example
Placing these constants in binary format into the data structure
shown in Figure E.3 yields the constant shown in Figure E.7.

0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0|
+-+-+

Figure E.7 -- AudioSpecificConfig used in Appendix C.6.4.1 of GM examples

Expressing this memo.

H.3 asc Media Type Registration

This section registers "asc" bitfield as a subtype for the "audio" media type.
We register this subtype an ASCII hexadecimal string yields:

7A0A0000001A4D546864000000060000000100604D54726B0000000600FF2F000

This string is assigned to support the remote transfer of the "config" parameter of the mpeg4-generic media type [RFC3640] when used with
mpeg4-generic mode rtp-midi (registered in Appendix H.2 above). We
explain the mechanics of using "audio/asc" to set the config parameter minimal
mpeg4-generic General MIDI examples in Section 6.2 and Appendix C.6.5 of this document.

Note that this registration is a new subtype registration, and is not an
addition to a repository defined by MPEG-related memos memo (such as
[RFC3640]). Also note that this request for "audio/asc" does not
register parameters, and does not request the creation of a repository.

Media type name:

audio

Subtype name:

asc

Required parameters:

none

Optional parameters:

none

Encoding considerations:

The native form of the data object is binary data,
zero-padded to an octet boundary.

Restrictions on usage:

This type is only defined for data object (stored file)
transfer. The most common transports for the type are
HTTP and SMTP.

Security considerations:

See Appendix G of example
in Section 6.2). Expressing this memo.

Interoperability considerations:

None.

Published specification:

The audio/asc data object string in Base64 [RFC2045] yields:

egoAAAAaTVRoZAAAAAYAAAABAGBNVHJrAAAABgD/LwAA

This string is assigned to the AudioSpecificConfig
binary data structure, which is normatively defined "inline" parameter in [MPEGAUDIO].

Applications which use this media type:

MPEG 4 Audio servers and terminals which support
audio/mpeg4-generic RTP streams for mode rtp-midi.

Additional information:

None.

Person & email address to contact for further information:

John Lazzaro <lazzaro@cs.berkeley.edu>

Intended usage:

COMMON.

Author:

John Lazzaro <lazzaro@cs.berkeley.edu>

Change Controller:

IETF Audio/Video Transport Working Group delegated
from the IESG.

I. General MIDI
example shown in Appendix C.6.5.

References

I.1

Normative References

[MIDI] MIDI Manufacturers Association. "The Complete MIDI 1.0
Detailed Specification", 1996.

[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson.
Jacobson, "RTP: A transport protocol Transport Protocol for real-time applications", Real-Time
Applications", STD 64, RFC 3550, July 2003.

[RFC3551] Schulzrinne, H., H. and S. Casner. Casner, "RTP Profile for Audio and
Video Conferences with Minimal Control", STD 65, RFC
3551, July 2003.

[RFC3640] van der Meer, J., Mackie, D., Swaminathan, V., Singer,
D., and P. Gentric. Gentric, "RTP Payload Format for Transport of
MPEG-4 Elementary Streams", RFC 3640, November 2003.

[MPEGSA] International Standards Organization. "ISO/IEC 14496
MPEG-4", Part 3 (Audio), Subpart 5 (Structured Audio),
2001.

[SDP]

[RFC4566] Handley, M., Jacobson, V., and C. Perkins. Perkins, "SDP: Session
Description Protocol", draft-ietf-mmusic-sdp-new-25.txt. RFC 4566, July 2006.

[MPEGAUDIO] International Standards Organization. "ISO 14496 MPEG-4", MPEG-
4", Part 3 (Audio), 2001.

[RFC2045] Freed, N. and N. Borenstein. "MIME Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, November 1996.

[DLS2] MIDI Manufacturers Association. "The MIDI Downloadable
Sounds Specification", v98.2, 1998.

[RFC2234]

[RFC4234] Crocker, D. and P. Overell. Overell, "Augmented BNF for Syntax
Specifications: ABNF.", ABNF", RFC 2234, November 1997. 4234, October 2005.

[RFC2119] Bradner, S. S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman.
Norrman, "The Secure Real-time Transport Protocol
(SRTP)", RFC 3711, March 2004.

[RFC3264] Rosenberg, J. and H. Schulzrinne. Schulzrinne, "An Offer/Answer Model
with SDP", Session Description Protocol (SDP)", RFC 3264, June
2002.

[RFC2396]

[RFC3986] Berners-Lee, T., Fielding, R. R., and L. Masinter, "Uniform
Resource Identifiers Identifier (URI): Generic Syntax", STD 66, RFC 2396, August 1998.

[RFC2732] Hinden, R., Carpenter, B. and L. Masinter, "Format for
Literal IPv6 Addresses in URL's", RFC 2732, December 1999.
3986, January 2005.

[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P. P., and T. Berners-Lee, "Hypertext
Transfer Protocol, Protocol -- HTTP/1.1", RFC 2616, June 1999.

[RFC3388] Camarillo, G., Eriksson, G., Holler, J., and H. Schulzrinne.
Schulzrinne, "Grouping of Media Lines in the Session
Description Protocol (SDP)", RFC 3388, December 2002.

[RP015] MIDI Manufacturers Association. "Recommended Practice
015 (RP-015): Response to Reset All Controllers", 11/98.

[MTYPE]

[RFC4288] Freed, N. and J. Klensin. Klensin, "Media Type Specifications and
Registration Procedures", draft-freed-media-type-reg-05. BCP 13, RFC 4288, December
2005.

[RFC3555] Casner, S. and P Hoschka. P. Hoschka, "MIME Type Registration of RTP
Payload Formats", RFC 3555, July 2003.

I.2

Informative References

[NMP] Lazzaro, J. and J. Wawrzynek. "A Case for Network
Musical Performance", 11th International Workshop on
Network and Operating Systems Support for Digital Audio
and Video (NOSSDAV 2001) June 25-26, 2001, Port
Jefferson, New York.

[GRAME] Fober, D., Orlarey, Y. and S. Letz. "Real Time Musical
Events Streaming over Internet", Proceedings of the
International Conference on WEB Delivering of Music 2001,
pages 147-154.

[RFC3261] Rosenberg, J, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. Schooler.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.

[RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier. Lanphier, "Real Time
Streaming Protocol (RTSP)", RFC 2326, April 1998.

[ALF] Clark, D. D. and D. L. Tennenhouse. "Architectural
considerations for a new generation of protocols",
SIGCOMM Symposium on Communications Architectures and
Protocols , (Philadelphia, Pennsylvania), pp. 200--208,
IEEE, Sept. 1990.

[GUIDE]

[RFC4696] Lazzaro, J., J. and J. Wawrzynek. Wawrzynek, "An Implementation Guide
for RTP MIDI", draft-ietf-avt-rtp-midi-guidelines-15.txt. RFC 4696, November 2006.

[RFC2205] Braden, R. et al. R., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, September 1997.

[RFC2048]

[RFC4288] Freed, N., N. and J. Klensin, J., "Media Type Specifications and
Registration Procedures", BCP 13, RFC 4288, December
2005.

[RFC4289] Freed, N. and J. Postel. "MIME Klensin, "Multipurpose Internet Mail
Extensions (MIME) Part Four: Registration Procedures",
BCP 13, RFC 2048, November 1996.

[CONTRANS] 4289, December 2005.

[RFC4571] Lazzaro, J. "Framing RTP Real-time Transport Protocol (RTP)
and RTCP RTP Control Protocol (RTCP) Packets over
Connection-Oriented Connection-
Oriented Transport",
draft-ietf-avt-rtp-framing-contrans-05.txt. RFC 4571, July 2006.

[RFC2818] E. Rescorla. Rescorla, E., "HTTP over Over TLS", RFC 2818, May 2000.

[SPMIDI] MIDI Manufacturers Association. "Scalable Polyphony
MIDI, Specification and Device Profiles", Document
Version 1.0a, 2002.

[LCP] Apple Computer. "Logic 7 Dedicated Control Surface
Support", Appendix B. Product manual available from
www.apple.com.

Authors' Addresses

John Lazzaro (corresponding author)
UC Berkeley
CS Division
315 Soda Hall
Berkeley CA 94720-1776
Email:

EMail: lazzaro@cs.berkeley.edu

John Wawrzynek
UC Berkeley
CS Division
631 Soda Hall
Berkeley CA 94720-1776
Email:

EMail: johnw@cs.berkeley.edu

Full Copyright Statement

This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.

This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST,
AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY
IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR
PURPOSE.

Intellectual Property Rights Statement

The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.

L. Full Copyright Statement

Copyright (C) The Internet Society (2006). This document is subject to
the rights, licenses and restrictions contained in BCP 78, and except as
set forth therein, the authors retain all their rights.

This document and the information contained herein are provided
on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE.
ietf-ipr@ietf.org.

Acknowledgement

Funding for the RFC Editor function is currently provided by the
Internet Society.

N. Change Log for <draft-ietf-avt-rtp-midi-format-15.txt>

[Note to RFC Editors: this Appendix, and its Table of Contents listing,
should be removed from the final version of the memo]

The following changes were made to the document:

[1] The IP6 "c=" lines in all session description
examples were changed to be:

c=IN IP6 2001:DB80::7F2E:172A:1E24

[2] In Appendix C.6.3, the final paragraph, the
phrase "audio complete performances" was changed
to be the grammatically correct "complete audio
performances".

[3] Updated GUIDE reference to version -15.txt.
Also, RTCP is now defined as "RTP control protocol",
not "Real Time Control Protocol, in its first
appearance in the text, and in several other
places in the text.

---

The wording changes below are in response to
a late-arriving review by Jim Wright, who has
been reviewing RTP MIDI for the MMA. These
changes reflect confusions he had understanding
RTP session and stream definitions that were
added to the I-Ds shortly before Last Call.
He basically got in the mode of rereading
Section 2.1 over and over, trying to figure
out how it all fit together. He felt these
four clarifications would have helped him
figure out the mechanism easier, and so I
added these into the I-D.

[4] In Section 2.1, the paragraph that began
"A session description [SDP] media line ("m=")
is now preceded by the introductory line:

"We now define RTP session semantics, in the
context of sessions specified using the session
description protocol [SDP]."

[5] In the aforementioned paragraph, the sentence
beginning with "Source" now begins with
"Synchronization source".

[6] Later in Section 2.1, the paragraph that
begins "Streams in an RTP session may use"
has the added sentence:

Recall that dynamic binding of payload type
numbers in [SDP] lets a party map many payload
type numbers to the RTP MIDI payload format,
and thus a party may send many RTP MIDI streams
in a single RTP session.

[7] Later in Section 2.1, the paragraph that
begins "The RTP header timestamps for each stream"
ends with a few sentences that have been modified
to include specific references to [RFC3550]. Here
are the modified sentences:

The SSRC values for each stream in an RTP session
are also separately and randomly chosen, as described
in [RFC3550]. Receivers use the CNAME field encoded
in RTCP sender reports to verify that streams were
sent by the same party, and to detect SSRC collisions,
as described in [RFC3550]. IETF
Administrative Support Activity (IASA).