INTERNET-DRAFT                                                J. Lazzaro
April 25, 2005                                              J. Wawrzynek
Expires: October 25, 2005                                    UC Berkeley


                      RTP Payload Format for MIDI

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


Status of 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 the Internet Engineering
Task Force (IETF), its areas, and its working groups.  Note that other
groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
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 of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.txt.

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

This Internet-Draft will expire on October 25, 2005.

Copyright Notice

Copyright (C) The Internet Society (2005).  All Rights Reserved.














Lazzaro/Wawrzynek                                               [Page 1]


INTERNET-DRAFT                                             25 April 2005


                                Abstract

     This memo describes an RTP payload format for the MIDI 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 the remote operation of musical instruments)
     and content-delivery applications (such as file streaming).  The
     format may be used over unicast and multicast UDP as well as TCP,
     and 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 Terminology . . . . . . . . . . . . . . . . . . . . . . . .   6
     1.2 Bitfield Conventions  . . . . . . . . . . . . . . . . . . .   6
2. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . . .   7
     2.1 RTP Header  . . . . . . . . . . . . . . . . . . . . . . . .   7
     2.2 MIDI Payload  . . . . . . . . . . . . . . . . . . . . . . .  12
3. MIDI Command Section  . . . . . . . . . . . . . . . . . . . . . .  14
     3.1 Timestamps  . . . . . . . . . . . . . . . . . . . . . . . .  15
     3.2 Command Coding  . . . . . . . . . . . . . . . . . . . . . .  17
4. The Recovery Journal System . . . . . . . . . . . . . . . . . . .  24
5. Recovery Journal Format . . . . . . . . . . . . . . . . . . . . .  26
6. Session Description Protocol  . . . . . . . . . . . . . . . . . .  29
     6.1 Session Descriptions for Native Streams . . . . . . . . . .  30
     6.2 Session Descriptions for mpeg4-generic Streams  . . . . . .  32
     6.3 Parameters  . . . . . . . . . . . . . . . . . . . . . . . .  35
7. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . . .  36
8. Congestion Control  . . . . . . . . . . . . . . . . . . . . . . .  37
A. The Recovery Journal Channel Chapters . . . . . . . . . . . . . .  38
     A.1 Recovery Journal Definitions  . . . . . . . . . . . . . . .  38
     A.2 Chapter P: MIDI Program Change  . . . . . . . . . . . . . .  43
     A.3 Chapter C: MIDI Control Change  . . . . . . . . . . . . . .  44
          A.3.1 Log Inclusion Rules  . . . . . . . . . . . . . . . .  44
          A.3.2 Controller Log Format  . . . . . . . . . . . . . . .  46
          A.3.3 Log List Coding Rules  . . . . . . . . . . . . . . .  47
          A.3.4 The Parameter System . . . . . . . . . . . . . . . .  48
     A.4 Chapter M: MIDI Parameter System  . . . . . . . . . . . . .  50
          A.4.1 Log Inclusion Rules  . . . . . . . . . . . . . . . .  51
          A.4.2 Log Coding Rules . . . . . . . . . . . . . . . . . .  53
               A.4.2.1 The Value Tool  . . . . . . . . . . . . . . .  54
               A.4.2.2 The Count Tool  . . . . . . . . . . . . . . .  57
     A.5 Chapter W: MIDI Pitch Wheel . . . . . . . . . . . . . . . .  59



Lazzaro/Wawrzynek                                               [Page 2]


INTERNET-DRAFT                                             25 April 2005


     A.6 Chapter N: MIDI NoteOff and NoteOn  . . . . . . . . . . . .  60
          A.6.1 Header Structure . . . . . . . . . . . . . . . . . .  61
          A.6.2 Note Structures  . . . . . . . . . . . . . . . . . .  62
     A.7 Chapter E: MIDI Note Command Extras . . . . . . . . . . . .  63
          A.7.1 Note Log Format  . . . . . . . . . . . . . . . . . .  64
          A.7.2 Log Inclusion Rules  . . . . . . . . . . . . . . . .  64
     A.8 Chapter T: MIDI Channel Aftertouch  . . . . . . . . . . . .  65
     A.9 Chapter A: MIDI Poly Aftertouch . . . . . . . . . . . . . .  66
B. The Recovery Journal System Chapters  . . . . . . . . . . . . . .  67
     B.1 System Chapter D: Simple System Commands  . . . . . . . . .  67
               B.1.1 Undefined System Commands . . . . . . . . . . .  68
     B.2 System Chapter V: Active Sense Command  . . . . . . . . . .  71
     B.3 System Chapter Q: Sequencer State Commands  . . . . . . . .  72
               B.3.1 Non-compliant Sequencers  . . . . . . . . . . .  74
     B.4 System Chapter F: MIDI Time Code  . . . . . . . . . . . . .  75
          B.4.1  Partial Frames  . . . . . . . . . . . . . . . . . .  77
     B.5 System Chapter X: System Exclusive  . . . . . . . . . . . .  79
               B.5.1 Chapter Format  . . . . . . . . . . . . . . . .  79
               B.5.2 Log Inclusion Semantics . . . . . . . . . . . .  82
               B.5.3 TCOUNT and COUNT fields . . . . . . . . . . . .  84
C. Session Configuration Tools . . . . . . . . . . . . . . . . . . .  86
     C.1 The Journalling System  . . . . . . . . . . . . . . . . . .  87
          C.1.1 The j_sec Parameter  . . . . . . . . . . . . . . . .  88
          C.1.2 The j_update Parameter . . . . . . . . . . . . . . .  89
               C.1.2.1 The anchor Sending Policy . . . . . . . . . .  89
               C.1.2.2 The closed-loop Sending Policy  . . . . . . .  90
               C.1.2.3 The open-loop Sending Policy  . . . . . . . .  94
          C.1.3 Chapter Inclusion Parameters . . . . . . . . . . . .  95
     C.2 Timestamp Semantics . . . . . . . . . . . . . . . . . . . . 102
          C.2.1 The comex Algorithm  . . . . . . . . . . . . . . . . 102
          C.2.2 The async Algorithm  . . . . . . . . . . . . . . . . 103
          C.2.3 The buffer Algorithm . . . . . . . . . . . . . . . . 104
     C.3 Packet Timing Tools . . . . . . . . . . . . . . . . . . . . 106
          C.3.1 Packet Duration Tools  . . . . . . . . . . . . . . . 106
          C.3.2 The guardtime Parameter  . . . . . . . . . . . . . . 107
          C.3.3 MIDI Time Code Issues  . . . . . . . . . . . . . . . 108
     C.4 Stream Description  . . . . . . . . . . . . . . . . . . . . 109
          C.4.1 The musicport Parameter  . . . . . . . . . . . . . . 109
          C.4.2 Multi-stream examples using musicport  . . . . . . . 112
     C.5 MIDI Rendering  . . . . . . . . . . . . . . . . . . . . . . 114
          C.5.1 The multimode Parameter  . . . . . . . . . . . . . . 115
          C.5.2 The rinit Parameter  . . . . . . . . . . . . . . . . 115
          C.5.3 Encoding rinit Data Objects  . . . . . . . . . . . . 117
          C.5.4 MIDI Channel Mapping . . . . . . . . . . . . . . . . 118
               C.5.4.1 smf_info  . . . . . . . . . . . . . . . . . . 118
               C.5.4.2 smf_inline, smf_url, smf_cid  . . . . . . . . 120
               C.5.4.3 chanmask  . . . . . . . . . . . . . . . . . . 121
          C.5.5 The audio/asc MIME Type  . . . . . . . . . . . . . . 122



Lazzaro/Wawrzynek                                               [Page 3]


INTERNET-DRAFT                                             25 April 2005


     C.6 Interoperability  . . . . . . . . . . . . . . . . . . . . . 124
          C.6.1 Content streaming  . . . . . . . . . . . . . . . . . 124
          C.6.2 Stage and studio . . . . . . . . . . . . . . . . . . 127
               C.6.2.1 Capabilities  . . . . . . . . . . . . . . . . 130
                    C.6.2.1.1 MIDI media lines . . . . . . . . . . . 132
                    C.6.2.1.2 MIDI rendering . . . . . . . . . . . . 134
                    C.6.2.1.3 Audio media lines  . . . . . . . . . . 137
               C.6.2.2 Baseline session  . . . . . . . . . . . . . . 137
               C.6.2.3 Examples  . . . . . . . . . . . . . . . . . . 139
          C.6.3 Network musical performance  . . . . . . . . . . . . 146
D. Parameter Syntax Definitions  . . . . . . . . . . . . . . . . . . 152
E. A MIDI Overview for Networking Specialists  . . . . . . . . . . . 158
     E.1 Commands Types  . . . . . . . . . . . . . . . . . . . . . . 160
     E.2 Running Status  . . . . . . . . . . . . . . . . . . . . . . 160
     E.3 Command Timing  . . . . . . . . . . . . . . . . . . . . . . 161
     E.4 AudioSpecificConfig templates for MMA renderers . . . . . . 161
F. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . . 166
G. Security Considerations . . . . . . . . . . . . . . . . . . . . . 167
H. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . . 168
     H.1 rtp-midi MIME Registration  . . . . . . . . . . . . . . . . 168
          H.1.1 Repository request . . . . . . . . . . . . . . . . . 171
     H.2 mpeg4-generic MIME Registration . . . . . . . . . . . . . . 172
          H.2.1 Repository request . . . . . . . . . . . . . . . . . 175
     H.3 asc MIME Registration . . . . . . . . . . . . . . . . . . . 176
I. References  . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
     I.1 Normative References  . . . . . . . . . . . . . . . . . . . 178
     I.2 Informative References  . . . . . . . . . . . . . . . . . . 179
J. Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . 181
K. Intellectual Property Rights Statement  . . . . . . . . . . . . . 181
L. Full Copyright Statement  . . . . . . . . . . . . . . . . . . . . 181
M. Change Log for <draft-ietf-avt-rtp-midi-format-08.txt>  . . . . . 183




















Lazzaro/Wawrzynek                                               [Page 4]


INTERNET-DRAFT                                             25 April 2005


1.  Introduction

The Internet Engineering Task Force (IETF) has developed a set of
focused tools for multimedia networking ([2] [6] [19] [20]).  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, [19]) to set up a phone call.  Call setup would include
negotiations to agree on a common audio codec [13].  Negotiations would
use the Session Description Protocol (SDP, [6]) to describe candidate
codecs.

After a call is set up, audio data would flow between the parties using
the Real Time Protocol (RTP, [2]) under any applicable profile (for
example, the Audio/Visual Profile (AVP, [3])).  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 as the Real Time Streaming Protocol (RTSP, [20])).

The MIDI command language [1] 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, [1]) rendered using the General
MIDI standard [1] 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 located in the same room [17].  As another example, the
streaming community may begin to use MIDI for low-bitrate audio coding,
perhaps in conjunction with normative sound synthesis methods [5].  As
another example, manufacturers of professional audio equipment and
electronic musical instruments may consider adopting the IETF multimedia
stack (IP, RTP, RTSP) as the networking layer for a MIDI control plane.

To enable MIDI applications using 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.




Lazzaro/Wawrzynek                                               [Page 5]


INTERNET-DRAFT                                             25 April 2005


Appendix C also includes interoperability guidelines for the three
example applications described above: network musical performance using
SIP (Appendix C.6.3), content-streaming using RTSP (Appendix C.6.1) and
RTSP-based stage and studio devices (Appendix C.6.2).

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 [23], 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 [22] provides
informative guidance on algorithms.  Supplemental information may be
found in related conference publications [17] [18].

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

1.1 Terminology

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 [11].

1.2 Bitfield Conventions

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



Lazzaro/Wawrzynek                                               [Page 6]


INTERNET-DRAFT                                             25 April 2005


    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 [2]
for an authoritative description of RTP.

This memo assumes 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 [1] 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 [21].  The interleaved mode of the Real Time
Streaming Protocol (RTSP, [20]) is an example of an RTP mapping to TCP
transport, as is [25].

2.1 RTP Header

[2] 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).















Lazzaro/Wawrzynek                                               [Page 7]


INTERNET-DRAFT                                             25 April 2005


    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 MIME 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 [4]).

In an RTP MIDI stream, the 16-bit sequence number field is initialized
to a randomly chosen 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, [6]) to
describe a media session, the clock rate parameter is set using the
rtpmap attribute.  We show examples of session setup in Section 6.



Lazzaro/Wawrzynek                                               [Page 8]


INTERNET-DRAFT                                             25 April 2005


We now address the subject of the resolution of the clock rate.  For RTP
MIDI stream 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 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, 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-RTP MIDI) RTP
audio stream with a clock rates 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 MIME parameter (Appendix C.3.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.3.1 discusses media time issues in detail.

All RTP streams from all parties in a multimedia session whose payload
types (coded by the PT header field) are mapped to the rtp-midi media
type share a single RTP session, and thus a common SSRC payload field
space (as defined in [2]).  Likewise, all RTP streams from all parties



Lazzaro/Wawrzynek                                               [Page 9]


INTERNET-DRAFT                                             25 April 2005


in a multimedia session whose payload types are mapped to the
mpeg4-generic media type in mode rtp-midi share an (independent) single
RTP session.

If a media line contains an RTP MIDI payload type, the media line
payload type list MUST consist entirely of payload types mapped to the
rtp-midi media type, or entirely of payload types mapped to the
mpeg4-generic media type in mode rtp-midi.

All RTP MIDI streams generated by a party using a single timing
synchronization source share a distinct SSRC header field value.  The
SSRC value is chosen and updated using the methods described in [2].
For example, in the common case of a party sending one 16 voice channel
+ systems MIDI name space on a single RTP MIDI stream sent over a single
network transport, the packets that make up the RTP MIDI stream are
identifiable by a unique SSRC value.

More complex uses of RTP MIDI may involve a single party sending several
RTP MIDI streams.  In many of these uses, the party uses a single timing
synchronization clock, and thus all packets sent by the party share the
same SSRC header field value.  In these uses, a different payload type
is assigned to each RTP MIDI stream.  A receiver uses the PT field to
identify which packets from an SSRC belong to each of the RTP MIDI
streams it sends.

For example, a hardware "breakout box" that transcodes the data on its
MIDI 1.0 DIN input jack onto an RTP MIDI stream would use the same SSRC
header value for all packets it sent in a multimedia session.  If the
breakout box had two MIDI 1.0 DIN input jacks, and used a common clock
to timestamp incoming data on both jacks, the box would send two RTP
MIDI streams, with each stream using the same SSRC field value with a
different PT field value.

In other cases, a party does not use the same timing synchronization
clock for all of the RTP MIDI streams it sends.  This architecture
usually reflects the underlying hardware of the party, such as two MIDI
piano keyboards, each generating an RTP MIDI stream from a distinct
Internet address.  Each piano would have its own clock.

In this case, each RTP MIDI stream MUST use a distinct SSRC header field
value.  Although these streams MAY use the same payload type field,
doing so would make it impossible, in the general case, for a session
description to assign different properties for each stream (such as how
the receiver should render the stream into audio, or how the receiver
should present the stream to software applications via an operating
system API).  Thus, in practice, each of these streams usually has a
distinct PT field value as well.




Lazzaro/Wawrzynek                                              [Page 10]


INTERNET-DRAFT                                             25 April 2005


In general, the network transport choices for the RTP MIDI streams by a
party are independent of the uses of the SSRC and PT values as described
above -- indeed, the packet identification field permits this freedom of
transport assignment.

So, for example, a party may split a single 16-channel + Systems MIDI
name space into two RTP MIDI streams, each containing a subset of MIDI
commands.  One stream may be sent over UDP transport (perhaps this
stream contains real-time Note commands), the other stream may over TCP
(perhaps this stream contains only bulk-data System Exclusive commands,
unsuitable for UDP).  Each stream uses the same SSRC.  The session
description maps a different payload type onto each stream, and via this
payload type describes the nature of the MIDI command split, and perhaps
the rendering method for the stream.

As a second example, a party may generate 2 RTP MIDI streams, each
coding a different 16-channel + Systems MIDI name space whose timestamps
are derived from different synchronization timing sources, and send the
streams to the same unicast network address and port pair (RTP port +
RTCP port).  In this case, two RTP MIDI streams are sent over a single
logical transport (the receiver unicast address/port pair), and a
receiver uses the different SSRC values (and probably, different PT
values) to demultiplex the two streams of packets arriving at the same
port.

In an RTP MIDI session, each synchronization source (identified by its
SSRC field value) MUST randomly choose a value to initialize its 32-bit
timestamp clock, and MUST use readings from this clock to generate the
timestamp field of all packets it creates for the RTP MIDI session.

Note that in the case multiple RTP MIDI streams sent by a single SSRC,
initializing each RTP MIDI stream with a unique random initialization
value would not work, because the RTCP synchronization mechanism [2]
maps the timebase of each SSRC (NOT each RTP MIDI stream) to a wall
clock time.  Instead, receivers of multiple RTP MIDI streams from a
single SSRC merge-sort the streams using the RTP timestamp field, which
is based on a common clock and a common random initialization value.

In contrast, receivers DO use the wall clock time coded by RTCP to
synchronize two RTP MIDI streams sent by the same party using different
clock synchronization sources, and thus, different SSRC values.

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



Lazzaro/Wawrzynek                                              [Page 11]


INTERNET-DRAFT                                             25 April 2005


support from the RTP MIDI payload format.

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.

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 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.1.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.

The payload of a stream encodes data for a single MIDI command name
space (16 voice channels + Systems).  Applications may use several
streams in a session.  Session configuration tools for multi-stream
sessions are defined in Appendix C.4.

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.5 defines session configuration tools to specify what
receivers should do with a MIDI command stream.



Lazzaro/Wawrzynek                                              [Page 12]


INTERNET-DRAFT                                             25 April 2005


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.1.2.2) uses Real Time
Control Protocol (RTCP, [2]) 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.4 defines session configuration tools that
may be used to split a dense MIDI name space into several UDP streams,
so that the payload fits comfortably into an MTU.  Another option is to
use TCP.  Section 4.3 of [22] provides non-normative advice for packet
size management.

































Lazzaro/Wawrzynek                                              [Page 13]


INTERNET-DRAFT                                             25 April 2005


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 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 codes an empty MIDI list

If the J header bit is set to 1, a journal section MUST appear after
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.














Lazzaro/Wawrzynek                                              [Page 14]


INTERNET-DRAFT                                             25 April 2005


   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  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.


If the header flag Z is 1, the MIDI list begins with a complete MIDI
command (coded in the MIDI Command 0 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. the MIDI Command N 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 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 [2]).  Recall that RTP
timestamps have units of seconds, whose scaling is set during session
configuration (see Section 6.1 and [6]).

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



Lazzaro/Wawrzynek                                              [Page 15]


INTERNET-DRAFT                                             25 April 2005


time format.  The RTP MIDI delta time syntax is a modified form of the
MIDI File delta time syntax [1].  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" text acknowledges the "less than or
equal" semantics (as opposed to "strictly less than") in the sentence
above this paragraph.

Thus, 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 in void of MIDI commands, without sending
any other information in the packet's MIDI list.  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.2.

The comex interpretation of timestamps works well for transcoding a
Standard MIDI File (SMF) into an RTP MIDI stream, as SMFs code a



Lazzaro/Wawrzynek                                              [Page 16]


INTERNET-DRAFT                                             25 April 2005


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
controllers that are implementing RTP MIDI natively (i.e. NOT by
transcoding a MIDI 1.0 DIN serial cable).

Other interpretations of timestamps may work better for transcoding a
MIDI source that uses implicit command timing (such as MIDI 1.0 DIN
cables) into an RTP MIDI stream.  Appendix C.2 defines alternatives to
comex 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 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 [1].  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



Lazzaro/Wawrzynek                                              [Page 17]


INTERNET-DRAFT                                             25 April 2005


octet.  Running status coding, as defined in [1], MAY be used for all
subsequent MIDI channel commands in the list.  As in [1], 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 [1] 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 [1], 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, 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



Lazzaro/Wawrzynek                                              [Page 18]


INTERNET-DRAFT                                             25 April 2005


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. 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.3 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, and
act as if it 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 system receives the
RTP MIDI stream, and transcodes it onto the MIDI DIN cable (or its
emulation).  Upon the receipt of the cancel sublist, the RTP-MIDI aware



Lazzaro/Wawrzynek                                              [Page 19]


INTERNET-DRAFT                                             25 April 2005


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, and discard the command.

Appendix C.1.3 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.3 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


[1] 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.




Lazzaro/Wawrzynek                                              [Page 20]


INTERNET-DRAFT                                             25 April 2005


SysEx commands carried on a MIDI 1.0 DIN cable may use the "dropped
0xF7" construction [1].  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.

[1] 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.3).  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 [1], the command will begin with an 0xF4 or 0xF5 status
octet, followed by zero, one, or two data octets.  To encode these
commands, senders MUST terminate the command with an 0xF7 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 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).  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, and place the modified command
into the MIDI Command field.



Lazzaro/Wawrzynek                                              [Page 21]


INTERNET-DRAFT                                             25 April 2005


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.













































Lazzaro/Wawrzynek                                              [Page 22]


INTERNET-DRAFT                                             25 April 2005


       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





Lazzaro/Wawrzynek                                              [Page 23]


INTERNET-DRAFT                                             25 April 2005


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.





Lazzaro/Wawrzynek                                              [Page 24]


INTERNET-DRAFT                                             25 April 2005


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.1.2
normatively defines three sending policies: "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 MIME
parameter j_update defined in Appendix C.1.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.1.3, we define MIME 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
[2]) 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 [2]) 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.







Lazzaro/Wawrzynek                                              [Page 25]


INTERNET-DRAFT                                             25 April 2005


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.1 to override these defaults,
the creators MUST ensure that the parameters define a system that
satisfy 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 [22] discusses sender and receiver algorithm design.


5.  Recovery Journal Format

This section introduces the structure of the recovery 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 recovery
    information for a single voice channel (channel journal) or
    for all systems commands (system journal).

  o Chapters.  Describes 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.











Lazzaro/Wawrzynek                                              [Page 26]


INTERNET-DRAFT                                             25 April 2005


    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|R|TOTCHAN|   Checkpoint Packet Seqnum    |
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                 Figure 8 -- Recovery journal header


If the Y header bit is set to 1, the system journal appears in 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, 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 R header bit is reserved.  The semantics for R bits are uniform
throughout the recovery journal, and are defined in Appendix A.1.

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).



Lazzaro/Wawrzynek                                              [Page 27]


INTERNET-DRAFT                                             25 April 2005


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  |R|      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.



Lazzaro/Wawrzynek                                              [Page 28]


INTERNET-DRAFT                                             25 April 2005


    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, 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, and
define 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, [19]) and the Real Time Streaming Protocol (RTSP, [20]).

RTP interacts with session management tools by defining media type
parameters.  In many cases, session management tools use the media type
parameters via another standard, the Session Description Protocol (SDP,
[6]).  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



Lazzaro/Wawrzynek                                              [Page 29]


INTERNET-DRAFT                                             25 April 2005


session descriptions between participants.

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

Other session management tools use SDP to declare the media encoding for
the 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 ([20], and Appendices C.6.1-2 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 Session Descriptions for Native Streams

The session description below shows a minimal native RTP MIDI stream
sent over unicast UDP transport.

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 MIME type to specify a
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 [2]).  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.

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, ...), 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



Lazzaro/Wawrzynek                                              [Page 30]


INTERNET-DRAFT                                             25 April 2005


     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 semantics (Section 3).

  4. The recommended temporal duration ("media time") 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. For each party, only one media description ("m=") that
     contains a payload type which is mapped to the rtp-midi
     media type may appear in the rtp-midi RTP session for
     the multimedia session.  As described in Section 2.1, only
     one such RTP session may appear in the multimedia session.
     In this media description, only only payload type may appear
     which is mapped to the rtp-midi media type.

  6. The rendering method for the stream is not specified.

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, the 16 voice channel + systems MIDI name
space is unique for each sender.  Thus, in a 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).

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
forward path and a many-to-1 reverse path, IETF protocols do not need to
provide any special support for MIDI multicast networking.








Lazzaro/Wawrzynek                                              [Page 31]


INTERNET-DRAFT                                             25 April 2005


6.2 Session Descriptions for mpeg4-generic Streams

An mpeg4-generic [4] 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 [1].

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

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

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 [4]) MUST contain empty AU
Header and Auxiliary sections.  These rules yield 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 shows a minimal mpeg4-generic RTP MIDI stream
sent over unicast UDP transport.  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 FF1E:03AD::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)

The fmtp attribute line codes the four parameters (streamtype, mode,
profile-level-id, and config) that are required in all mpeg4-generic



Lazzaro/Wawrzynek                                              [Page 32]


INTERNET-DRAFT                                             25 April 2005


session descriptions [4].  For RTP MIDI streams, the streamtype
parameter MUST be set to 5, the "mode" parameter MUST be set to "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 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 [4] of the AudioSpecificConfig data block [7] for
the stream.  AudioSpecificConfig encodes the Audio Object Type for the
stream, and also encodes initialization data (SAOL programs, DLS 2 wave
tables, 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 [5] and [7].

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. For each party, only one media description ("m=") that
     contains a payload type which is mapped to the mpeg4-generic
     media type under mode rtp-midi may appear in the RTP session
     for mpeg4-generic mode rtp-midi in the multimedia session.
     As described in Section 2.1, only one such RTP session may appear
     in the multimedia session.  In this media description, only only
     payload type may appear which is mapped to the mpeg4-generic
     mode rtp-midi media type.

  6. A minimal mpeg4-generic stream encodes the AudioSpecificConfig
     as an inline hexadecimal constant.  If 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.




Lazzaro/Wawrzynek                                              [Page 33]


INTERNET-DRAFT                                             25 April 2005


The Section 6.1 comments on SIP and RTSP stream directional defaults,
sendrecv MIDI channel 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 MIME parameters (including the
required streamtype, mode, profile-level-id, and config parameters).  As
a consequence, each party uses an 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.








































Lazzaro/Wawrzynek                                              [Page 34]


INTERNET-DRAFT                                             25 April 2005


6.3 Parameters

This section introduces parameters for session configuration for RTP
MIDI streams.  Parameters are applied on a per-payload-type basis
(signalled by the PT field in RTP headers, and by the payload type
number in media lines in session descriptions).  The parameters add
features to the minimal streams described in Sections 6.1-2, and support
several types of services:

  o  Journal customization.  The j_sec and j_update parameters
     configure the use of the journal section.  The ch_default,
     ch_unused, ch_never, ch_anchor, and ch_active parameters
     configure the semantics of the recovery journal chapters,
     and also define the capabilities of the stream, by
     declaring the subset of MIDI commands that may appear in
     the stream.  These MIME parameters are described in Appendix
     C.1, and override the default stream behaviors 1 and 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 MIME parameters are described in
     Appendix C.2, and override default stream behavior 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 MIME parameters are described in Appendix C.3,
     and override default stream behavior 4 listed in Section 6.1
     and referenced in Section 6.2.

  o  Stream description.  The musicport parameter labels the
     MIDI name space of multi-stream RTP sessions.  Musicport
     is described in Appendix C.4.  The musicport parameter overrides
     default stream behavior 5 in Sections 6.1 and 6.2.

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

In Appendix C.6, we specify interoperability guidelines for three RTP
MIDI application areas: content-streaming using RTSP (Appendix C.6.1),
RTSP-based stage and studio devices (Appendix C.6.2), and network
musical performance using SIP (Appendix C.6.3),



Lazzaro/Wawrzynek                                              [Page 35]


INTERNET-DRAFT                                             25 April 2005


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 [1]).

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 [13] [20] support codec negotiation,
to facilitate the use of new payload formats in a backward-compatible
way.

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

  o  Journalling.  As described in Appendix C.1, new token
     values for the j_sec and j_update MIME 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.5.2).  The extension
     mechanism uses the standard MIME registration process [24].
     Certain general aspects of the RTP MIDI rendering process may
     also be extended, via IETF standards-track documents that
     define new token values for the render (Appendix C.5) and
     smf_info (Appendix C.5.4.1) MIME parameters.

  o  Undefined commands.  [1] reserves 4 MIDI System commands
     for future use (0xF4, 0xF5, 0xF9, 0xFD).  If updates
     to [1] 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).









Lazzaro/Wawrzynek                                              [Page 36]


INTERNET-DRAFT                                             25 April 2005


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 network musical performance [17] framework might define
how to use SIP [19], SDP [6] and RTP [2] to support real-time
performances between geographically-distributed players.  We discuss
frameworks from an interoperability perspective in Appendix C.6.


8.  Congestion Control

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

In addition, as RTP MIDI runs under the Audio/Video Profile [3], the
congestion control requirements defined in [3] apply to RTP MIDI
sessions.  The basic congestion control requirement defined in [3] is
that RTP sessions that use UDP transport should monitor packet loss (via
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 [17], 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, and take actions during
RTP transcoding to reduce the RTP packet rate.  [22] offers
implementation guidance on this issue.




















Lazzaro/Wawrzynek                                              [Page 37]


INTERNET-DRAFT                                             25 April 2005


A.  The Recovery Journal Channel Chapters

A.1 Recovery Journal Definitions

This Appendix defines the terminology and the coding idioms that are
used in the recovery journal bitfield descriptions in Section 5 (journal
header structure), Appendices A.2-9 (channel journal chapters) and
Appendices B.1-5 (system journal chapters).

We assume that the recovery journal resides in the journal section of an
RTP packet with sequence number I ("packet I") and that the Checkpoint
Packet Seqnum field 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 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 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 data about a command stored
in the MIDI command section of packet I - 1.  In this case, the S bit of
the recovery journal element MUST be set to 0.  If a recovery journal
element has its S bit set 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 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.







Lazzaro/Wawrzynek                                              [Page 38]


INTERNET-DRAFT                                             25 April 2005


We now define normative terms used to describe recovery journal
semantics.

  o Checkpoint history.  The checkpoint history of a recovery journal
    is the concatenation of the MIDI 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 command; the first
    command in the MIDI command section 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 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 a recovery journal is
    the concatenation of MIDI 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
    MIDI command section of packet I, and so the session history of
    the first packet in the session is empty by definition.

  o Finished/unfinished commands.  If all octets of a MIDI command
    appear in the session history, the command 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 a SysEx command appear
    in several RTP packets.  For example, if a 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 session histories for
    packets K + 1 and K + 2 contain unfinished versions of the command.
    A session history contains a finished version of a cancelled SysEx
    command if the history contains the cancel sublist 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).
    MIME registrations for renderers (Appendix C.5.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.




Lazzaro/Wawrzynek                                              [Page 39]


INTERNET-DRAFT                                             25 April 2005


  o N-active commands.  N-active commands are MIDI commands that do
    not appear before one of the following commands in the 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 are MIDI commands that do
    not appear before one of the following commands in 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 of elements, where each element is associated
    with a MIDI command that appears in the session history.  In
    most cases, the chapter definition requires that list elements
    be ordered in accordance with the "oldest-first ordering rule".
    Below, we normatively define this rule:

    Elements associated with the most recent command in the session
    history coded in the list MUST appear at the end of the list.

    Elements associated with the oldest command in the session
    history coded in the list MUST appear at the start of the list.

    All other list elements MUST be arranged with respect to these
    boundary elements, to produce a list ordering that strictly
    reflects the relative session history recency of the commands
    coded by the elements 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.
    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 of RPNs and NRPNs are
    changed by a series of Control Change commands that form a
    parameter system transaction.  A canonical transaction begins
    with two Control Change commands to set the parameter number
    (controller numbers 99 and 98 for NRPNs, controller numbers 101
    and 100 for RPNs).  The 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 parameter value.  The
    transaction ends with a second pair of (99, 98) or (101, 100)
    Control Change commands that specify the null parameter (MSB
    value 0x7F, LSB value 0x7F).





Lazzaro/Wawrzynek                                              [Page 40]


INTERNET-DRAFT                                             25 April 2005


    Several variants of the canonical transaction sequence are
    possible.  Most commonly, the terminal pair of (99, 98) or
    (101, 100) Control Change commands may specify a parameter
    other than the null parameter.  In 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
    in [1].  We refer to this variant as a "type 1 variant".

    Less commonly, the 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 is omitted, the transaction uses the MSB value
    of the most recent C-active Control Change command for controller
    number 99 or 101 that appears in the session history.  We refer to
    this variant as a "type 2 variant".

    If the LSB command is omitted, the LSB value 0x00 is assumed.  We
    refer to this variant as a "type 3 variant".  The type 2 and type 3
    variants are defined as legal, but are not recommended, in [1].

    System real-time commands may appear at any point during
    a transaction (even between octets of individual commands
    in the transaction).  More generally, [1] does not forbid
    the appearance of unrelated MIDI commands during an open
    transaction.  These commands are considered to be "outside"
    the transaction, and do not effect the status of the transaction
    in any way.  In particular, these "outside" commands do not
    terminate the transaction (excepting a Reset State command whose
    semantics act to reset the transaction system).

  o Initiated parameter system transaction.  A canonical parameter
    system transaction whose (99, 98) or (101, 100) initial Control
    Change command pair appears in the session history is considered
    to be an initiated parameter system transaction.  This definition
    also holds 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 type 3
    variants (dropped LSB),  a transaction is considered to be
    initiated if at least one transaction command follows the initial
    MSB (99 or 101) Control Change command in the 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 field, which codes the
    total number of commands of a type that appear in the session
    history.  Examples include the Reset and Tune Request command



Lazzaro/Wawrzynek                                              [Page 41]


INTERNET-DRAFT                                             25 April 2005


    logs (Chapter D, Appendix B.1) and the Active Sense command
    (Chapter V, Appendix B.2).  Upon the detection of a loss event,
    reference count fields let a receiver deduce if ANY instances 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 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 the
default recovery journal behavior.  The ch_default, ch_unused, ch_never,
ch_anchor, and ch_active parameters modify these definitions, as
described in Appendix C.1.3.

The chapter definitions specify if data MUST be present in the journal.
Senders MAY also include non-required data in the journal.  This
optional data MUST comply with the normative chapter definition.  For
example, if a chapter definition states that a field codes data from the
most recent active command in the session history, the sender MUST NOT
code inactive commands or older commands 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."


























Lazzaro/Wawrzynek                                              [Page 42]


INTERNET-DRAFT                                             25 April 2005


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
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 active Program Change command in the
session history.  By default, the B, BANK-MSB, X, and BANK-LSB fields
MUST be set to 0.  Below, we define exceptions to this default
condition.

If an active Control Change (0xB) command for controller number 0 (Bank
Select MSB) appears before the Program Change command in the session
history, the B bit MUST be set to 1, and the BANK-MSB field MUST code
the data value of the Control Change command.

If B is set to 1, the BANK-LSB field MUST code the data value of the
most recent Control Change command for controller number 32 (Bank Select
LSB) that preceded the Program Change command coded in the PROGRAM field
and followed the Control Change command coded in the BANK-MSB field.  If
no such Control Change command exists, the BANK-LSB field MUST be set to
0.

If B is set to 1, and if a Control Change command for controller number
121 (Reset All Controllers) appears in the MIDI stream between the
Control Change command coded by the BANK-MSB field and the Program
Change command coded by the PROGRAM field, the X bit MUST be set to 1.













Lazzaro/Wawrzynek                                              [Page 43]


INTERNET-DRAFT                                             25 April 2005


A.3 Chapter C: MIDI Control Change

Readers may wish to review the Appendix A.1 definition of "C-active
commands" before reading this Appendix.

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 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 the number of controller logs
in the list, minus one.  We define the semantics of the controller log
fields in Appendix A.3.2.

A channel journal MUST contain Chapter C if the rules defined in this
Appendix require that one or more controller logs appear in the list.

A.3.1 Log Inclusion Rules

If a C-active Control Change command for a controller number in the
range 0-119 appears in the checkpoint history, the list MUST contain a
controller log for the number, with possible exceptions for numbers 0,
6, 32-63 and 96-101.

If an active Control Change command for a controller number in the range
120-127 appears in the checkpoint history, the list MUST contain a
controller log for the number, with possible exceptions for numbers
124-127.

We now define the rules for the exceptions.

  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 [1].

     If the most recent C-active Control Change command in the session



Lazzaro/Wawrzynek                                              [Page 44]


INTERNET-DRAFT                                             25 April 2005


     history for a 14-bit controller pair uses the MSB number, Chapter
     C MAY omit the controller log for the associated LSB number, as
     the command ordering makes this LSB value irrelevant.  However,
     this exception MUST NOT be applied if the sender is 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 C-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
     BANK-MSB and BANK-LSB fields of the Chapter P (Appendix A.2),
     Chapter C MAY omit the controller logs for the commands.

  o  Several controller numbers pairs are 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 checkpoint history, a
     log for the controller number of the most recent command for the
     pair in the checkpoint history MUST appear in the controller list.
     However, the list MAY omit the controller log for the other number
     in the pair.

     If active Control Change commands for one or both members of a
     mutually exclusive pair appear in the session history, and a log
     for the controller number of the most recent command for the pair
     does not appear in the controller list, a log for the other number
     of the pair MUST NOT appear in the controller list.

  o  Appendix A.3.4 defines exception rules for the MIDI Parameter
     System controller numbers 6, 38, and 96-101.

The ch_active MIME parameter (Appendix C.1.3) may be used to change
Chapter C semantics to support MIDI renderers (such as [9] in certain
configurations) that exclude particular controller numbers from the
semantics of Control Change commands for controller 121 (Reset All
Controllers).  Appendix C.1.3 defines how ch_active modifies Chapter C
semantics.









Lazzaro/Wawrzynek                                              [Page 45]


INTERNET-DRAFT                                             25 April 2005


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


The 7-bit NUMBER field identifies the controller number.  The 7-bit
VALUE/ALT field codes recovery information for the controller number.
The A bit defines the coding format of the VALUE/ALT field.

Chapter C provides three tools for coding recovery information in the
VALUE/ALT field: the value tool, the toggle tool, and the count tool.
Implementations may choose among the tools to best code recovery
information for a particular controller number.

In the value tool, the 7-bit VALUE/ALT field codes the control value of
the most recent C-active (controller numbers 0-119) or active
(controller numbers 120-127) Control Change command in the session
history.  This tool works best for controllers that code a continuous
quantity, such as number 1 (Modulation Wheel).  If the value tool is
chosen, the A bit is set to 0.

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


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

              Figure A.3.3 -- Controller log for ALT tools


The T flag is set to 1 to code the toggle tool; T is set to 0 to code
the count tool.  Both methods use the 6-bit ALT field as an unsigned
integer.




Lazzaro/Wawrzynek                                              [Page 46]


INTERNET-DRAFT                                             25 April 2005


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 and the "on" state with 64-127.  The ALT
field codes the total number of toggles (off->on and on->off) due to
Control Change commands in the session history, including toggle events
caused by Control Change commands 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 command (Appendix
A.1) appears in the session history.  When these reset events occur, the
toggle count for a controller is set to 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 benefits of the
toggle tool over the value tool for switch controllers.  As often used
in piano applications, the "on" state of the controller lets notes
resonate, while the "off" state immediately damps notes to silence.  The
loss of the "off" 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.

The count tool is similar to the toggle tool, but is optimized for
controllers whose controller value is ignored, such as number 123 (All
Notes Off).  For the count tool, the ALT field codes the total number of
Control Change commands in the session history.  Command counting is
performed modulo 64.

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

A.3.3 Log List Coding Rules

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

In most situations, a controller number SHOULD be coded by a single tool
(and thus, a single controller log).  If a number is coded with a single
tool, and this tool is the count tool, recovery Control Change commands
generated by a receiver SHOULD use the default control value for the
controller.

A controller number MAY be coded by several tool types (and thus,
several controller logs, each using a 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) when used with a non-zero data octet (with



Lazzaro/Wawrzynek                                              [Page 47]


INTERNET-DRAFT                                             25 April 2005


the semantics described in [9]).

However, multiple logs for the same controller number that use the SAME
tool type MUST NOT appear in the controller list.

The Chapter C log list MUST obey the oldest-first ordering rule (defined
in Appendix A.1).  Note that this ordering codes 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.


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 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 (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 a parameter system
transaction MUST NOT be coded in Chapter C controller logs.  Instead,
these commands are coded in Chapter M, the MIDI Parameter chapter
defined in Appendix A.4.

However, Control Change 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 controllers are coded in Chapter C controller logs.  The
controller logs follow the coding rules stated in Appendix A.3.2 and
A.3.3.  The 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.





Lazzaro/Wawrzynek                                              [Page 48]


INTERNET-DRAFT                                             25 April 2005


If C-active Control Change commands for controller numbers 6, 38, or
96-101 appear in the 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
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 the role of each Control Change
command for these controller numbers by noting the placement of the
command in the stream, and MUST use this information to code 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 the most recent active Control
Change commands in the session history that set an RPN or NRPN parameter
number code the null parameter (MSB value 0x7F, LSB value 0x7F), or when
no active Control Change commands that set an RPN or NRPN parameter
number appear in the session history.

A MIDI source that follows the recommendations of [1] exclusively 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 the language of [1], the general-purpose use of controllers 98-101
constitutes a non-standard controller assignment.  As most real-world
MIDI sources use the 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.




















Lazzaro/Wawrzynek                                              [Page 49]


INTERNET-DRAFT                                             25 April 2005


A.4 Chapter M: MIDI Parameter System

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

Chapter M protects parameter system transactions for Registered
Parameter Number (RPN) and Non-Registered Parameter Number (NRPN)
values.  Figure A.4.1 shows the format for 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 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |S|P|E|U|W|Z|      LENGTH       |Q|  PENDING    |  Log list ... |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

               Figure A.4.1 -- 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 follows the header, coding the 7-bit PENDING value
and its associated Q bit.

The 10-bit LENGTH field codes the size of 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 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 the
list.

A channel journal also MUST contain Chapter M if the most recent C-
active 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) controller that completes the
     coding of the null parameter (MSB value 0x7F, LSB value 0x7F).

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

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



Lazzaro/Wawrzynek                                              [Page 50]


INTERNET-DRAFT                                             25 April 2005


parameter system transaction in the session history is for the RPN MSB
or NRPN MSB controller, the P header bit MUST be set to 1, and the
PENDING field (and its associated Q bit) MUST follow the 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.  If PENDING
codes an RPN MSB, the Q bit MUST be set to 0.

The E header bit codes the current transaction state of the MIDI stream.
If E = 1, an initiated transaction is in progress.  Below, we define the
rules for setting the E header bit:

  o  If no C-active parameter system transaction Control Change
     commands appear in the session history, the E bit MUST be
     set to 0.

  o  If the P header bit is set to 1, the E bit MUST be set to 0.

  o  If the most recent C-active parameter system transaction
     Control Change command in the session history is for the
     NRPN LSB or RPN LSB controller number, and this command
     acts to complete the coding of the null parameter (MSB
     value 0x7F, LSB value 0x7F), the E bit MUST be set to 0.

  o  Otherwise, an initiated transaction is in progress, and the
     E bit MUST be set 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.

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 set to 1.  If all
parameter logs in the list code NRPN parameters, the W bit MAY be set to
1.  If the parameter numbers of all RPN and NRPN logs in the list lie in
the range 0-127 (and thus have an MSB value of 0), the Z bit MAY be set
to 1.

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 a C-active command that forms
a part of an initiated transaction for the parameter appears in the
checkpoint history.




Lazzaro/Wawrzynek                                              [Page 51]


INTERNET-DRAFT                                             25 April 2005


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, a log for
the parameter MAY be omitted from the list.

A log MAY appear in the list if a C-active Control Change command that
forms a part of an initiated transaction for the parameter appears in
the session history.  Otherwise, a log for the parameter MUST NOT appear
in the list.

Multiple logs for the same RPN or NRPN parameter MUST NOT appear in the
log list.

The parameter log list MUST obey the oldest-first ordering rule (defined
in Appendix A.1), with the phrase "parameter transaction" replacing the
word "command" in the rule definition.

Parameter logs associated with the RPN or NRPN null parameter (LSB =
0x7F, MSB = 0x7F) MUST NOT appear in 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.

The ch_active MIME parameter (Appendix C.1.3) may be used to change
parameter log inclusion semantics, to support renderers (such as [9])
that exclude certain RPN parameters from the semantics of Control Change
commands for controller 121 (Reset All Controllers).  This support is
necessary because an active (but no longer C-active) Control Change
command for an RPN or NRPN parameter in the checkpoint history requires
loss protection if the renderer ignores Reset All Controllers commands
for the parameter.  Appendix C.1.3 defines how the ch_active parameter
modifies Chapter M semantics.

In most cases, parameter logs for RPN and NRPN parameters that are
assigned to the ch_never MIME parameter (Appendix C.1.3) MAY be omitted
from the list.  An exception applies if:

  o  The log codes the most recent initiated transaction
     in the session history, and

  o  A C-active command that forms a part of the transaction
     appears in the checkpoint history, and

  o  The E header bit for the top-level Chapter 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



Lazzaro/Wawrzynek                                              [Page 52]


INTERNET-DRAFT                                             25 April 2005


NRPN Control Change commands that follow the loss event.

A.4.2 Log Coding Rules

Figure A.4.2 shows the parameter log structure of 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 5 6 7 8 8 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |S|  PNUM-LSB   |Q|  PNUM-MSB   |J|K|L|M|N|T|V|A|   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 header bit is set to 0, the log encodes an
RPN parameter.  If Q = 1, the log encodes an NRPN parameter.  The 7-bit
PNUM-MSB and 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 Contents (TOC) for the
log, and 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 log.  The ordering of fields in the 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 T, V, and A header bits code information about the parameter log,
but are NOT part of the TOC.  A set T, V, or A bit does NOT signal the
presence of any parameter log field.

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 the loss of C-active parameter transaction
Control Change commands in the checkpoint history.

This rule does not apply if the parameter coded by the log is assigned
to the ch_never MIME parameter (Appendix C.1.3).  In this case, senders
MAY choose to set the J, K, L, M, and N TOC bits 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 of
the log is to inform receivers recovering from a loss that a transaction
is in progress, so that the receiver is able to correctly interpret RPN



Lazzaro/Wawrzynek                                              [Page 53]


INTERNET-DRAFT                                             25 April 2005


or NRPN Control Change commands that follow the loss event.

Parameter logs provide two tools for parameter protection: the value
tool and the count tool.  Depending on the semantics of the parameter,
senders may use either tool, both tools, or neither tool to protect a
given parameter.

The value tool codes information a receiver may use to determine the
current value of an RPN or NRPN parameter.  If a parameter log uses the
value tool, the V header bit MUST be set to 1, and the 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 count tool codes the number of transactions for an RPN or NRPN
parameter.  If a parameter log uses the count tool, the T header bit
MUST be set to 1, and the semantics defined in Appendices A.4.2.2 for
setting the N TOC bit MUST be followed.  If a parameter log does not use
the count tool, the T bit and the N TOC bit MUST be set to 0.

Note that V and T are set if 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.

The A header bit codes the level of protection provided by the value and
count tools.  If the log parameter is assigned to the ch_active MIME
parameter (Appendix C.1.3), the A header bit MUST be set to 1, coding
the elevated protection level of the parameter.  Otherwise, the A header
bit MUST be set to 0, coding the standard protection level.

In many cases, all parameters coded in the log list are 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 the top-level Chapter M header bit Z to 1 (to code the
restricted range) AND by setting the U or W bit 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 the parameter log list MUST use a modified header format.
This modification deletes bits 8-15 of the bitfield shown in Figure
A.4.2, to yield a 2-octet header.  The values of the deleted PNUM-MSB
and Q fields may be inferred from the U, W, and Z bit values.

A.4.2.1 The Value Tool

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




Lazzaro/Wawrzynek                                              [Page 54]


INTERNET-DRAFT                                             25 April 2005


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 the most recent C-
active Control Change command for controller number 6 (Data Entry MSB)
in the 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 recent Control Change command for controller 121 (Reset All
Controllers) in the session history.  Otherwise, the X bit MUST be set
to 0.

Note that in the default case, the ENTRY-MSB field may only code C-
active commands, and so X MUST be set to 0.  The X bit plays a useful
encoding role if an assignment to the ch_active MIME parameter (Appendix
C.1.3) permits the ENTRY-MSB field to code commands that are active but
not C-active.

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 the data value of the most recent C-
active Control Change command for controller number 38 (Data Entry LSB)
in the 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-LSB precedes



Lazzaro/Wawrzynek                                              [Page 55]


INTERNET-DRAFT                                             25 April 2005


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 the value tool MUST include the ENTRY-MSB
field if a C-active Control Change command for controller number 6
appears in the checkpoint history.

As a rule, a parameter log that uses the value tool MUST include the
ENTRY-LSB field if a C-active Control Change command for controller
number 38 appears in the checkpoint history.  However, the ENTRY-LSB
field MUST NOT appear in a parameter log if the Control Change command
associated with the ENTRY-LSB precedes a Control Change command for
controller number 6 (Data Entry MSB) in the session history that appears
in a transaction for the log parameter.

The L TOC bit codes the presence 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 count of the number of active Control
Change commands for controller numbers 96 and 97 (Data Increment and
Data Decrement) in the session history that appear in a transaction for
the log parameter.

The M TOC bit codes the presence of the octets shown in Figure A.4.6 in
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


The 14-bit C-BUTTON field has semantics identical to A-BUTTON, except



Lazzaro/Wawrzynek                                              [Page 56]


INTERNET-DRAFT                                             25 April 2005


that Data Increment and Data Decrement Control Change commands that
precede the most recent Control Change command for controller 121 (Reset
All Controllers) in the session history are not counted.

For both A-BUTTON and C-BUTTON, Data Increment and Data Decrement
Control Change commands are not counted if they precede Control Changes
commands for controller numbers 6 (Data Entry MSB) or 38 (Data Entry
LSB) that appear in a transaction for the log parameter in the session
history.

The A-BUTTON and C-BUTTON fields are interpreted as unsigned integers,
and the G bit associated the field codes the sign of the integer (G = 0
for positive or zero, G = 1 for negative).

To compute and code the count value, initialize the count value to 0,
add 1 for each qualifying Data Increment command, and subtract 1 for
each qualifying Data Decrement command.  After each add or subtract,
limit the count magnitude to 16383.  The G bit codes the sign of the
count, and the A-BUTTON or C-BUTTON field codes the count magnitude.

For the A-BUTTON field, if the most recent qualified Data Increment or
Data Decrement command precedes the most recent Control Change command
for controller 121 (Reset All Controllers) 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 C-BUTTON
fields if a C-active Control Change command for controller numbers 96 or
97 appears in the checkpoint history.

If a parameter is assigned to the ch_active MIME parameter (Appendix
C.1.3), a log for this parameter that uses the value tool MUST include
the A-BUTTON and C-BUTTON fields if an active Control Change command for
controller numbers 96 or 97 appears in the checkpoint history.  However,
to improve coding efficiency, this this rule has several exceptions:

  o  If the log includes the A-BUTTON field, and if the X bit of
     the A-BUTTON field is set to 1, the C-BUTTON field (and its
     associated R and 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



Lazzaro/Wawrzynek                                              [Page 57]


INTERNET-DRAFT                                             25 April 2005


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 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) in the session
history, the X bit associated with the COUNT field MUST be set to 1.
Otherwise, the X bit MUST be set to 0.

Transaction counting is performed modulo 128.  The transaction count is
set to 0 at the start 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
a C-active command that increments the transaction count (modulo 128)
appears in the checkpoint history.  Note that an assignment to the
ch_active MIME parameter (Appendix C.1.3) may change these inclusion
semantics.


















Lazzaro/Wawrzynek                                              [Page 58]


INTERNET-DRAFT                                             25 April 2005


A.5 Chapter W: MIDI Pitch Wheel

A channel journal MUST contain Chapter W if an active MIDI Pitch Wheel
(0xE) command appears in the checkpoint history.  Figure A.5.1 shows 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 the 7-bit values of the first and second data octets of the most
recent active Pitch Wheel command in the session history.
































Lazzaro/Wawrzynek                                              [Page 59]


INTERNET-DRAFT                                             25 April 2005


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 Appendix 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 particular note number.
However, in rare applications, multiple overlapping NoteOn commands may
appear for a note number.  Chapter E, described in Appendix A.7,
augments Chapter N to completely protect these streams.

A channel journal MUST contain Chapter N if an N-active MIDI NoteOn
(0x9) or NoteOff (0x8) command appears in the checkpoint history.
Figure A.6.1 shows the format 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 a 2-octet header, followed by at least one of the
following data structures:

   o A list of note logs to code NoteOn commands.
   o A NoteOff bitfield structure to code NoteOff commands.

We define the header bitfield semantics in Appendix A.6.1.  We define
the note log semantics and the NoteOff bitfield semantics in Appendix
A.6.2.

If one or more N-active NoteOn or NoteOff commands in the checkpoint
history reference a note number, the note number MUST be coded in either
the note log list or the NoteOff bitfield structure.

The note log list MUST contain an entry for all note numbers whose most
recent checkpoint history appearance is 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 in an N-



Lazzaro/Wawrzynek                                              [Page 60]


INTERNET-DRAFT                                             25 April 2005


active NoteOff command.

A note number MUST NOT be coded in both structures.

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

The note log list MUST obey the oldest-first ordering rule (defined in
Appendix A.1).

A.6.1 Header Structure

The header for Chapter N, shown in Figure A.6.2, codes the size of the
note list and bitfield structures.


                    0                   1
                    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                   |B|     LEN     |  LOW  | HIGH  |
                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure A.6.2 -- Chapter N header


The LEN field, a 7-bit integer value, codes the number of 2-octet note
logs in the note list.  Zero is a valid value for LEN, and codes an
empty note list.

The 4-bit LOW and HIGH fields code the number of OFFBITS octets that
follow the note log list.  LOW and HIGH are unsigned integer values.  If
LOW <= HIGH, there are (HIGH - LOW + 1) OFFBITS octets in the chapter.
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 in the header.

The B bit provides S-bit functionality (Appendix A.1) for the NoteOff
bitfield structure.  By default, the B bit MUST be set to 1.  However,
if the MIDI command section of the previous packet (packet I - 1, with I
as defined in Appendix A.1) includes a NoteOff command for the channel,
the B bit MUST be set to 0.  If the B bit is set to 0, the higher-level
recovery journal elements that contain Chapter N MUST have S bits that
are set to 0, including the top-level journal header.

The LEN value of 127 codes a note list length of 127 or 128 note logs,
depending on the values of LOW and HIGH.  If LEN = 127, LOW = 15, and
HIGH = 0, the note list holds 128 note logs, and the NoteOff bitfield



Lazzaro/Wawrzynek                                              [Page 61]


INTERNET-DRAFT                                             25 April 2005


structure is empty.  For other values of LOW and HIGH, LEN = 127 codes
that the note list contains 127 note logs.  In this case, the chapter
has (HIGH - LOW + 1) NoteOff OFFBITS octets if LOW <= HIGH, 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 log


The 7-bit NOTENUM field codes the note number for the log.  A note
number MUST NOT be represented by multiple note logs in the note list.

The 7-bit VELOCITY field codes the velocity value for the most recent N-
active NoteOn command for the note number in the session history.
Multiple overlapping NoteOns for a given note number may be 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 of the NoteOn command.
However, the Y bit codes a hint from the sender about the NoteOn
execution time.  The Y bit codes a recommendation to play (Y = 1) or
skip (Y = 0) the NoteOn command recovered from the note log.  See
Section 4.2 of [22] for non-normative guidance on the use of the Y bit.

Figure A.6.1 shows the NoteOff bitfield structure, as the list of
OFFBITS octets at the end of the chapter.  A NoteOff OFFBITS octet codes
NoteOff information for eight consecutive MIDI note numbers, with the
most-significant bit representing the lowest note number.  The most-
significant bit of the first OFFBITS octet codes the note number 8*LOW;
the most-significant bit of the last OFFBITS octet codes the note number
8*HIGH.

A set bit codes a NoteOff command for the note number.  In the most
efficient coding for the NoteOff bitfield structure, the first and last
octets of the structure contain at least one set bit.  Note that Chapter
N does not code NoteOff velocity data.



Lazzaro/Wawrzynek                                              [Page 62]


INTERNET-DRAFT                                             25 April 2005


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
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 A.7.1 shows the format for Chapter 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 8 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |S|     LEN     |S|   NOTENUM   |V|  COUNT/VEL  |S|  NOTENUM    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |V|  COUNT/VEL  |  ....                                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure A.7.1 -- 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.  The 7-bit LEN header
field codes the number of note logs in the list, minus one.  A channel
journal MUST contain Chapter E if the rules defined in this Appendix
require that one or more note logs appear in the list.  The note log
list MUST obey the oldest-first ordering rule (defined in Appendix A.1).













Lazzaro/Wawrzynek                                              [Page 63]


INTERNET-DRAFT                                             25 April 2005


A.7.1 Note Log Format

Figure A.7.2 reproduces the note log structure of 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 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 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 field codes a reference count of
the number of NoteOn and NoteOff commands for the note number that
appear in the session history.

The reference count is set to 0 at the start 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 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 to 127.

By default, the count is reset to 0 whenever a Reset State command
(Appendix A.1) appears in the 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 session history.
The ch_active MIME parameter may be used to change count reset behavior,
as described in Appendix C.1.3.

A.7.2 Log Inclusion Rules

If the most recent N-active NoteOn or NoteOff command for a note number
in the checkpoint history is a NoteOff command with a release velocity
value other than 64, a note log whose V bit is set to 1 MUST appear in
Chapter E for the note number.



Lazzaro/Wawrzynek                                              [Page 64]


INTERNET-DRAFT                                             25 April 2005


If the most recent N-active NoteOn or NoteOff command for a note number
in the checkpoint history is a NoteOff command, and if the reference
count for the note number is greater than 0, a note log whose V bit is
set to 0 MUST appear in Chapter E for the note number.

If the most recent N-active NoteOn or NoteOff command for a note number
in the checkpoint history is a NoteOn command, and if the reference
count for the note number is greater than 1, a note log whose V bit is
set to 0 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 set to 1.

Chapter E codes a maximum of 128 note logs.  If the log inclusion rules
yield more than 128 REQUIRED logs, note logs whose V 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 MIME parameter (Appendix C.1.3) may be used to configure
the log inclusion rules for Chapter E.


A.8 Chapter T: MIDI Channel Aftertouch

A channel journal MUST contain Chapter T if an N-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
                           +-+-+-+-+-+-+-+-+
                           |S|   PRESSURE  |
                           +-+-+-+-+-+-+-+-+

                   Figure A.8.1 -- Chapter T format


The chapter has a fixed size of 8 bits.  The 7-bit PRESSURE field holds
the pressure value of the most recent N-active Channel Aftertouch
command in the session history.






Lazzaro/Wawrzynek                                              [Page 65]


INTERNET-DRAFT                                             25 April 2005


A.9 Chapter A: MIDI Poly Aftertouch

A channel journal MUST contain Chapter A if an N-active Poly Aftertouch
(0xA) command appears in the checkpoint history.  Figure A.9.1 shows the
format for Chapter 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 8 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |S|    LEN      |S|   NOTENUM   |X|  PRESSURE   |S|   NOTENUM   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |X|  PRESSURE   |  ....                                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure A.9.1 -- Chapter A format


The chapter consists of a 1-octet header, followed by a variable length
list of 2-octet note logs.  A note log MUST appear for a note number if
an N-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.  The note log list MUST obey 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 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 of the most recent N-
active Poly Aftertouch 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
commands in the session history: MIDI Control Change numbers 123-127
(numbers with All Notes Off semantics) or 120 (All Sound Off).  This
condition occurs only if the session description uses the ch_active MIME
parameter (Appendix C.1.3) to alter the semantics of Chapter A.



Lazzaro/Wawrzynek                                              [Page 66]


INTERNET-DRAFT                                             25 April 2005


B.  The Recovery Journal System Chapters

B.1 System Chapter D: Simple System Commands

The system journal MUST contain Chapter D if an active MIDI Reset
(0xFF), MIDI Tune Request (0xF6), MIDI Song Select (0xF3), undefined
MIDI System Common (0xF4 and 0xF5), or undefined MIDI System Real-time
(0xF9 and 0xFD) command appears in the checkpoint history.

Figure B.1.1 shows the variable-length format for 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |S|B|G|H|J|K|Y|Z|  Command logs ...                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

               Figure B.1.1 -- 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 header, in the order that
the flag bits appear in 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 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 session
history.



Lazzaro/Wawrzynek                                              [Page 67]


INTERNET-DRAFT                                             25 April 2005


Chapter D MUST contain the Tune Request command log if an active Tune
Request command appears in the 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" in Appendix A.1 for
more information.

Figure B.1.3 shows the 1-octet command 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 Song Select command 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.  [1] reserves the undefined System commands 0xF4, 0xF5,
0xF9, and 0xFD for future use.  At the time of this writing, any MIDI
command stream that uses these commands is non-compliant with [1].
However, future versions of [1] may define these commands, and a few
products do use these commands in a non-compliant manner.

Figure B.1.4 shows the variable length command log format for the
undefined System Common commands (0xF4 and 0xF5).













Lazzaro/Wawrzynek                                              [Page 68]


INTERNET-DRAFT                                             25 April 2005


    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|R|R|DSZ|    LENGTH     |    COUNT      |  VALUE ...    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  LEGAL ...                                                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Figure B.1.4 -- 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 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 8-bit LENGTH field codes the size of the command log, and conforms
to semantics described in Appendix A.1.

The 2-bit DSZ field codes the number of data octets in the command
instance that appears most recently in the session history.  If DSZ =
0-2, the command has 0-2 data octets.  If DSZ = 3, the command has 3 or
more command data octets.

As noted in Section 3.2 in the main text, if the undefined System Common
commands are put to use in a future version of [1], the command will
begin with an 0xF4 or 0xF5 status octet, followed by zero, one, or two
data octets.  Thus, compliant uses of of undefined System Common
commands will never set DSZ = 3.  If DSZ = 3, the log codes a non-
compliant use of undefined System Common commands.

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

If the DSZ field is set to 0, the command log MUST include the COUNT
field.  The 8-bit COUNT field codes the total number of commands of the
type coded by the log present in the session history, modulo 256.

If the DSZ field is set to 1-3, the command log MUST include the VALUE
field.  The variable-length VALUE field codes a verbatim copy the data
octets for the most recent use of the command in the session history.
The most-significant bit of the final data octet MUST be set to 1, and
the most-significant bit of all other data octets MUST be set to 0.




Lazzaro/Wawrzynek                                              [Page 69]


INTERNET-DRAFT                                             25 April 2005


The LEGAL field is reserved for future use.  If an update to [1] 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
the LEGAL field, and receivers MUST use the LENGTH field to skip over
the LEGAL field.  The LEGAL field would be defined by the IETF if the
semantics of the new 0xF4 or 0xF5 command could not be protected from
packet loss via the use of the COUNT and VALUE fields.

Figure B.1.5 shows the variable length command log format for the
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|C|L| LENGTH  |     COUNT     |  LEGAL ...                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Figure B.1.5 -- Undefined System Real-time command log format


The command log codes a single command type (0xF9 or 0xFD, not both).
Chapter 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 one-octet header followed by a variable number
of data fields.  Header flag bits indicate the presence of the COUNT
field (C = 1) and the LEGAL field (L = 1).  The 5-bit LENGTH field codes
the size of the command log, and conforms to semantics described in
Appendix A.1.

We now define the default rules for the use of the COUNT and LEGAL
fields.  The session configuration tools defined in Appendix C.1.3 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 in the session history, modulo 256.  By
default, the COUNT field MUST be present in the command log.

The LEGAL field is reserved for future use.  If an update to [1] defines
the 0xF9 or 0xFD command, an IETF standards-track document MAY define
the LEGAL field to protect the command.  Until such a document appears,
senders MUST NOT use the LEGAL field, and receivers MUST use the LENGTH
field to skip over the LEGAL field.  The LEGAL field would be defined by
the IETF if the semantics of the new 0xF9 or 0xFD command could not be
protected from packet loss via the use of the COUNT field.




Lazzaro/Wawrzynek                                              [Page 70]


INTERNET-DRAFT                                             25 April 2005


Finally, we note that some non-standard uses of the undefined System
Real-time commands act to implement non-compliant variants of the 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 appears in the checkpoint history.  Figure B.2.1 shows
the format for Chapter V.


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

                  Figure B.2.1 -- System Chapter V format


The 7-bit COUNT field codes the total number of Active Sense commands
(modulo 128) present in the session history.  The COUNT field acts as a
reference count.  See the definition of "session history reference
counts" in Appendix A.1 for more information.

























Lazzaro/Wawrzynek                                              [Page 71]


INTERNET-DRAFT                                             25 April 2005


B.3 System Chapter Q: Sequencer State Commands

This Appendix describes Chapter Q, the system chapter for the MIDI
sequencer commands.

The system journal MUST contain 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 in the checkpoint
history, and if the rules defined in this Appendix require a change in
the Chapter Q bitfield contents because of the command appearance.

Figure B.3.1 shows the 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 order shown in Figure B.3.1.

Header flag bits signal the presence 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 Appendix B.3.1.

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

The N header bit encodes the relative occurrence of the 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.  If
an active Stop appears most recently, or if no active Start, Stop, or
Continue commands appear in the session history, the N bit MUST be set
to 0.

The C header flag, the TOP header field, and the CLOCK field act to code
the current position in the sequence:




Lazzaro/Wawrzynek                                              [Page 72]


INTERNET-DRAFT                                             25 April 2005


   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 of 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 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 of time.

  o  If C = 0, the song position is the start of the song.
     The C = 0 position is identical to the position coded
     by C = 1, TOP = 0, and CLOCK = 0, for the case where
     the song position is less than 524288 MIDI clocks.
     In certain situations (defined later in this section),
     normative text may require the C = 0 or the C = 1,
     TOP = 0, CLOCK = 0 encoding of the start of the song.

The C, TOP, and CLOCK fields MUST be set to code the current song
position, for both N = 0 and N = 1 conditions.  If C = 0, the TOP field
MUST be set to 0.  See [1] for a precise definition of a song position.

The D header bit encodes information about the downbeat, and acts to
qualify the song position coded by the C, TOP, and CLOCK fields.

If the D bit is set to 1, the song position represents the most recent
position in the 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
increment the song position by one clock, and to play the updated
position.

If the D bit is set to 0, the song position represents a position in the
sequence that 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 song coded by 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 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 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 downbeat has
yet to be played), and the song position is at the start of the song,
the C = 0 song position encoding MUST be used if a Start command occurs



Lazzaro/Wawrzynek                                              [Page 73]


INTERNET-DRAFT                                             25 April 2005


more recently than a Continue command in the session history, and the C
= 1, TOP = 0, CLOCK = 0 song position encoding MUST be used if a
Continue command occurs more recently than a Start command in the
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 [1].
However, a few non-compliant products do not use Clock commands to count
off time, but instead use non-standard methods.

Chapter Q uses the TIMETOOLS field to provide resiliency support for
these non-standard products.  By default, the TIMETOOLS field MUST NOT
appear in Chapter Q, and the T header bit MUST be set to 0.  The session
configuration tools described in Appendix C.1.3 may be used to select
TIMETOOLS coding.

Figure B.3.2 shows the format of the 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 TIME field is a 24-bit unsigned integer quantity, with units of
milliseconds.  TIME codes an additive correction term for the song
position coded by the TOP, CLOCK, C fields.  TIME is coded in network
byte order (big-endian).

A receiver computes the 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 corrected
song position.










Lazzaro/Wawrzynek                                              [Page 74]


INTERNET-DRAFT                                             25 April 2005


B.4 System Chapter F: MIDI Time Code Tape Position

This Appendix describes Chapter F, the system chapter for the MIDI Time
Code (MTC) commands.  Readers may wish to review the Appendix A.1
definition of "finished/unfinished commands" before reading this
Appendix.

The system journal MUST contain Chapter F if an active System Common
Quarter Frame command (0xF1) or an active finished System Exclusive
(Universal Real Time) MTC Full Frame 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 shows the 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
session history.  Receivers use Chapter F to re-synchronize the MTC
system after a packet loss episode.

Chapter F consists of a 1-octet header followed by several optional
fields, in the order shown in Figure B.4.1.  The C and P header bits
form a Table of Contents (TOC), and signal the presence of the 32-bit
COMPLETE field (C = 1) and the 32-bit PARTIAL field (P = 1).

The Q header bit codes information about the COMPLETE field format.  If
Chapter F does not contain a COMPLETE field, Q MUST be set to 0.

The D header bit codes the tape movement direction.  If the tape is
moving forward, or if the tape direction is indeterminate, the D bit
MUST be set to 0.  If the tape is moving in the reverse direction, the D
bit MUST be set to 1.  In most cases, the ordering of commands in the
session history clearly defines the tape direction.  However, a few
command sequences have an indeterminate direction (such as a session
history consisting of one Full Frame command).



Lazzaro/Wawrzynek                                              [Page 75]


INTERNET-DRAFT                                             25 April 2005


The 3-bit POINT header field is interpreted as an unsigned integer.
Appendix B.4.1 defines how the POINT field codes information about the
contents of the PARTIAL field.  If Chapter F does not contain a PARTIAL
field, POINT MUST be set to 7 (if D = 0) or 0 (if D = 1).

Chapter F MUST include the COMPLETE field if an active finished Full
Frame command appears in the checkpoint history, or if an active Quarter
Frame 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 the Quarter Frame commands for Message Type 0 through
Message Type 7 [1].  These nibbles encode a complete frame value, in
addition to fields reserved for future use by [1].


    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 frame value encoded in the COMPLETE field MUST be
offset by 2 frames (relative to the frame value encoded in the Quarter
Frame commands) if the frame value codes a 0xF1 0x0n through 0xF1 0x7n
command sequence.  This offset compensates for the two-frame latency of
the Quarter Frame encoding for forward tape movement.  No offset is
applied if the 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 case, the Q
header bit MUST be set to 0, and the COMPLETE field MUST have format
shown in Figure B.4.3.  The HR, MN, SC, and FR fields correspond to the
hr, mn, sc, and fr data octets of the Full Frame command.




Lazzaro/Wawrzynek                                              [Page 76]


INTERNET-DRAFT                                             25 April 2005


    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 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 a reverse-moving 0xF1 0x1n 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, 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 not associated with a partial frame value.

Chapter F MUST include a PARTIAL field if the most recent active command
in the checkpoint history that encodes MTC frame value data is a 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 data (lower) nibbles of the
Quarter Frame command sequence.  The PARTIAL field codes the partial
frame value, using 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 field indicates the Message Type fields in the PARTIAL
field code valid data.  If P = 1, the POINT field MUST encode the
unsigned integer value formed by the lower 3 bits of the upper nibble of
the data value of the most recent active Quarter Frame command in the
session history.  If D = 0 and P = 1, POINT MUST take on a value in the
range 0-6.  If D = 1 and P = 1, POINT MUST take on a value in the range
1-7.

If D = 0, MT fields (Figure B.4.2) in the inclusive range 0 up to and
including the POINT value encode the partial frame value.  If D = 1, MT
fields in the inclusive range 7 down to and including the POINT value
encode the partial frame value.  Note that unlike the COMPLETE field



Lazzaro/Wawrzynek                                              [Page 77]


INTERNET-DRAFT                                             25 April 2005


encoding, senders MUST NOT add a 2-frame offset to the partial frame
value encoded in PARTIAL.

For the default semantics, if a recovery journal contains Chapter F, and
if the session history codes a legal [1] series of Quarter Frame and
Full Frame commands, 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 the presence of an illegal command sequence in the
session history (under some conditions, the C = 1, P = 0 condition may
also code the presence of an illegal command sequence).  The illegal
command sequence conditions are transient in nature, and usually
indicate that a Quarter Frame command sequence began with an
intermediate Message Type.






































Lazzaro/Wawrzynek                                              [Page 78]


INTERNET-DRAFT                                             25 April 2005


B.5 System Chapter X: System Exclusive

This Appendix describes Chapter X, the system chapter for MIDI System
Exclusive (SysEx) commands (0xF0).  Readers may wish to 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 that appears in the session history.  The system journal MUST
contain Chapter X if the rules defined in Appendix B.5.2 require that
one or more logs appear in the list.

The log list is NOT preceded by a header.  Instead, each log implicitly
encodes its own length.  Given the length of the N'th list log, the
presence of the (N+1)'th list log may be inferred from the LENGTH field
of the system journal header (Figure 10 in Section 5 of the main text).
The log list MUST obey the oldest-first ordering rule (defined in
Appendix A.1).

B.5.1 Chapter Format

Figure B.5.1 shows the bitfield format for the Chapter X command 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
optional TCOUNT, COUNT, FIRST, and DATA fields.

The T, C, F, and D header bits act as a Table of Contents (TOC) for the
log.  If T is set to 1, the 1-octet TCOUNT field appears in the log.  If
C is set to 1, the 1-octet COUNT field appears in the log.  If F is set
to 1, the variable-length FIRST field appears in the log.  If D is set
to 1, the variable-length DATA field appears in the log.

The L header bit sets the coding tool for the log.  We define the log
coding tools in Appendix B.5.2.



Lazzaro/Wawrzynek                                              [Page 79]


INTERNET-DRAFT                                             25 April 2005


The STA field codes the status of the command coded by the log.  The
2-bit STA value is interpreted as an 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 cancelled
command, an STA value of 2 codes a command that uses the "dropped F7"
construction, and 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 the S bit
for Chapter X.  For the other logs in the list, the S bit refers to the
log itself.  The value of the "phantom" S bit associated with the first
log is defined by the following rules:

  o  If the list codes one log, the phantom S-bit value is
     the same as the Chapter X S-bit value.

  o  If the list codes multiple logs, the phantom S-bit value is
     the logical OR of the S-bit value of the first and second
     command logs in the list.

In all other respects, the S bit follows the semantics defined in
Appendix A.1.

The FIRST field (present if F = 1) encodes a variable-length unsigned
integer value that sets the coverage of the DATA field.  The FIRST field
consists of an octet whose most-significant bit is set to 0, optionally
preceded by one or more octets whose most-significant bit is set to 1.
The algorithm shown 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,
and a SysEx command may contain an arbitrary number of data octets.



















Lazzaro/Wawrzynek                                              [Page 80]


INTERNET-DRAFT                                             25 April 2005


     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 of the SysEx command coded by the log.  Status octets MUST NOT be
coded in the DATA field.

If F = 0, the DATA field begins with the first data octet of the SysEx
command, and includes all subsequent data octets for the command that
appear in the session history.  If F = 1, the DATA field begins with the
(dec(FIRST) + 1)'th data octet of the SysEx command, and includes all
subsequent data octets for the command that appear in the session
history.  Note that the word "command" in the descriptions above refers
to the original SysEx command as it appears in the source MIDI data
stream, not to a particular MIDI list SysEx command segment.

The length of the DATA field is coded implicitly, using the most-
significant bit of each octet.  The most-significant bit of the final
octet of the DATA field MUST be set to 1.  The most significant bit of
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 is 0 by
definition.  Apart from this length-coding modification, the DATA field
encodes a verbatim copy of all data octets it encodes.







Lazzaro/Wawrzynek                                              [Page 81]


INTERNET-DRAFT                                             25 April 2005


B.5.2 Log Inclusion Semantics

Chapter X offers two tools to protect SysEx commands: the "recency" tool
and the "list" tool.  The tool definitions use the concept of the "SysEx
type" of a command, which we now define.

Each SysEx 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 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 session history has a different SysEx
type, and thus, no two commands in the session have the same type.

To improve efficiency, senders MAY implement exceptions to this rule.
These exceptions declare certain sets of SysEx command instances to have
the same SysEx type.  Any command not covered 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 for each data octet) have the same type.
       This rule MUST be applied to all SysEx commands in the session,
       or not at all.  Note that the implementation of this exception
       requires no sender knowledge of the format and semantics of
       the SysEx commands in the stream, merely the ability to count
       and compare octets.

    o  Two instances of the same command whose semantics set or report
       the value of the same "parameter" have the same type.  The
       implementation of this exception requires specific knowledge of
       the format and semantics of SysEx commands.  In practice, a
       sender implementation chooses to support this exception for
       certain classes of commands (such as the Universal System
       Exclusive commands defined in [1]).  If a sender supports
       this exception for a particular command in a class (for
       example, the Universal Real Time System Exclusive message
       for Master Volume, F0 F7 cc 04 01 vv vv F7, defined in [1]),
       it MUST support the exception to all instances of this
       particular command in the session.


We now use this definition of "SysEx type" to define the "recency" tool
and the "list" tool for Chapter X.

By default, the Chapter X log list MUST code sufficient information to
protect the rendered MIDI performance from indefinite artifacts caused



Lazzaro/Wawrzynek                                              [Page 82]


INTERNET-DRAFT                                             25 April 2005


by the loss of all 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 code a log in the log list for the most recent finished
active instance of the SysEx type that appears in the checkpoint
history.  Additionally, if an unfinished active instance of the SysEx
type appears in the checkpoint history, senders MUST code a log in the
log list for the unfinished command instance.  The L header bit of both
command logs MUST be set to 0.

To protect a command of a specific SysEx type with the list tool,
senders MUST code a log in the Chapter X log list for each finished or
unfinished active instance of the SysEx type that appears in the
checkpoint history.  The L 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 in the checkpoint
history for the SysEx command instance associated with the log.  The
FIRST field MAY be used to configure 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 with cancelled commands
MAY be coded with no DATA field.  However, if DATA appears in the log,
DATA MUST code all data octets that appear in the checkpoint history for
the command associated with the log.

As defined by the preceding text in this section, by default all
finished or unfinished active SysEx commands that appear in the
checkpoint history (excluding finished MTC Full Frame commands) MUST be
protected by the list tool or the recency tool.

For 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 RTP stream "on the
fly", by sending SysEx command segments as soon as data octets are
delivered by the 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 situation, if a sender uses the closed-loop sending policy for
SysEx commands, the RTP packet size may always be capped by stalling the
stream.  In a stream stall, once the packet reaches a maximum size, the
sender refrains from sending new packets with non-empty MIDI Command
Sections until receiver feedback permits the trimming of Chapter X.  If



Lazzaro/Wawrzynek                                              [Page 83]


INTERNET-DRAFT                                             25 April 2005


the stream permits arbitrary commands to appear between SysEx segments
(selectable during configuration using the tools defined in Appendix
C.1.3), the sender may stall the SysEx segment stream but continue to
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 configuration to reduce the anticipated size of Chapter
X, using the methods described below:

  o  Partitioned transport.  Appendix C.4 provides tools
     for partitioning a MIDI source into several 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 [25] TCP stream
     (for bulk-data SysEx commands).  The ch_unused and
     ch_active parameters (Appendix C.1) may be used to
     communicate the nature of the SysEx command partition.
     As TCP 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 the
     UDP stream, and then cancel the UDP transmission of long
     commands (using tools described in Section 3.2) and
     resend the commands over the TCP stream.

  o  Selective protection.  Journal protection may not be
     necessary for all SysEx commands in a stream.  The
     ch_never parameter (Appendix C.1) may be used to
     communicate which SysEx commands are excluded from
     Chapter X.  Alternatively, senders may communicate
     the deletion of certain SysEx commands from the
     stream (and thus Chapter X), via the ch_unused parameter.

B.5.3 TCOUNT and COUNT fields

If the T header bit is set to 1, the 8-bit TCOUNT field appears in the
command log.  If the C header bit is set to 1, the 8-bit COUNT field
appears in the command log.  TCOUNT and COUNT are interpreted as
unsigned integers.

The TCOUNT field codes the total number of SysEx commands of the SysEx
type coded by the log that appear 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 the total number of SysEx commands that appear in
the session history, excluding commands that are excluded from Chapter X



Lazzaro/Wawrzynek                                              [Page 84]


INTERNET-DRAFT                                             25 April 2005


via the ch_never parameter (Appendix C.1), at the moment after the
(finished or unfinished) command coded by the log enters the session
history.

Command counting for TCOUNT and COUNT uses modulo-256 arithmetic.  MTC
Full Frame command instances (Appendix B.4) are included in command
counting if the TCOUNT and COUNT definitions warrant their inclusion, as
are cancelled commands (Section 3.2).

Senders use the TCOUNT and COUNT fields to track the identity and (for
TCOUNT) the sequence position of a command instance.  Senders MUST use
the TCOUNT or COUNT fields if identity or sequence information is
necessary to protect the command type coded by the log.

If a sender uses the COUNT field in a session, the final command log in
every Chapter X in the stream MUST code the COUNT field.  This rule lets
receivers resynchronize the COUNT value after a packet loss.


































Lazzaro/Wawrzynek                                              [Page 85]


INTERNET-DRAFT                                             25 April 2005


C.  Session Configuration Tools

In the main text, we show session descriptions that set up minimal
native (Section 6.1) and mpeg4-generic (Section 6.2) RTP MIDI streams.
In practice, minimal streams lack the flexibility to support most MIDI
applications.  In this Appendix, we describe how to customize stream
behavior through the use of the payload format MIME parameters.

The Appendix begins with 5 sections, each devoted to parameters that
affect a particular aspect of stream behavior:

  o  Appendix C.1 describes the journalling system (ch_active,
     ch_anchor, ch_default, ch_never, ch_unused, j_sec, j_update).

  o  Appendix C.2 describes MIDI command timestamp semantics
     (linerate, mperiod, octpos, tsmode).

  o  Appendix C.3 describes the temporal duration ("media time")
     of an RTP MIDI packet (guardtime, rtp_maxptime, rtp_ptime).

  o  Appendix C.4 concerns stream description (musicport).

  o  Appendix C.5 describes MIDI rendering (chanmask, cid,
     inline, multimode, render, rinit, smf_cid, smf_info,
     smf_inline, smf_url, url).

The parameters listed above may optionally appear in session
descriptions of RTP MIDI streams; none are REQUIRED to appear.  If these
parameters are used in an SDP session description, the parameters appear
on an fmtp attribute line.  This attribute line specifies a payload
type.  The parameters in the attribute line apply to RTP MIDI streams
that use this payload type.

The parameters listed above add extra functionality ("features") to
minimal RTP MIDI streams.  In Appendix C.6, we define REQUIRED RTP MIDI
features for three classes of applications: content-streaming using RTSP
(Appendix C.6.1), RTSP-based devices for stage and studio applications
(Appendix C.6.2) and network musical performance (Appendix C.6.3).

The participants in a multimedia session MUST share a common view of all
of the RTP MIDI streams that appear in an RTP MIDI session.  In many RTP
MIDI applications, this restriction makes it difficult to use sendrecv
streams (all parties send and receive), as each party has its own
requirements.  For example, a two-party network musical performance
application may wish to customize the renderer on each host to match the
CPU performance of the host [17].

We solve this problem by using two RTP MIDI streams -- one sendonly, one



Lazzaro/Wawrzynek                                              [Page 86]


INTERNET-DRAFT                                             25 April 2005


recvonly -- in lieu of one sendrecv stream.  The data flows in the two
streams travel in opposite directions, to control receivers configured
to use different renderers.  In Appendix C.4, we describe how the
musicport parameter is used to define these "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 that are not easily changed once a
session has begun.  Thus, parties SHOULD NOT expect that parameter
change requests during a session will be accepted by other parties.
However, implementors SHOULD support in-session parameter changes that
are easy to handle (example: the guardtime parameter defined in Appendix
C.3), and SHOULD be capable of accepting requests for changes of those
parameters, as received by its session management protocol (for example,
re-offers in SIP [13]).

Appendix D defines the Augmented Backus-Naur Form (ABNF, [10]) syntax
for the payload MIME parameters.  Appendix H provides information to the
Internet Assigned Numbers Authority (IANA) on the MIME types and
parameters defined in this document.

Appendix C.5.5 defines the MIME type "audio/asc", a stored object for
initializing mpeg4-generic renderers.  As described in Appendix C.5, the
audio/asc MIME type is assigned to the "render" parameter to signal how
to initialize the renderer.  Note that RTP stream semantics are NOT
defined for "audio/asc".  Therefore, the "asc" MIME subtype MUST NOT
appear on the rtpmap line of a session description.


C.1 Configuration Tools: The Journalling System

In this Appendix, we define the payload format MIME parameters that
configure stream journalling and the recovery journal system.

The j_sec parameter (Appendix C.1.1) sets the journalling method for the
stream.  The j_update parameter (Appendix C.1.2) sets the recovery
journal sending policy for the stream.  Appendix C.1.2 also defines the
sending policies of the recovery journal system.

Appendix C.1.3 defines several parameters that modify the recovery
journal semantics.  These parameters change the default recovery journal
semantics as defined in Section 5 and Appendices A-B.

The journalling method for a stream is set at the start 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



Lazzaro/Wawrzynek                                              [Page 87]


INTERNET-DRAFT                                             25 April 2005


the acceptance of parameter values that would violate the recovery
journal mandate.  In many cases, a change in one of the parameters
defined in this Appendix during an on-going session would result in a
violation of the recovery journal mandate for an implementation; in this
case, the parameter change MUST NOT be accepted.

C.1.1 The j_sec Parameter

Section 2.2 defines the default journalling method for a stream.
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.

The MIME parameter j_sec may be used to 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 "recj", to
indicate that all stream payloads MUST contain a journal section that
uses the recovery journal format.

For example, the j_sec parameter might be set to "none" for 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 a UDP stream that does not use
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 MUST define new symbolic values for the j_sec
parameter to signal the use of the format.

Parties MUST NOT accept a j_sec value that violates the recovery journal
mandate (see Section 4 for details).  If a session description uses a
j_sec value unknown to the recipient, the recipient MUST NOT accept the
description.

Special j_sec issues arise when sessions are managed by session
management tools (like RTSP, [20]) that use SDP for "declarative usage"
purposes (see the preamble of Section 6 for details).  For these session
management tools, SDP does not code transport details (such as UDP or



Lazzaro/Wawrzynek                                              [Page 88]


INTERNET-DRAFT                                             25 April 2005


TCP) for the session.  Instead, server and client negotiate transport
details via other means (for RTSP, the SETUP method).

In this scenario, the use of the j_sec parameter may be ill-advised, as
the creator of the session description may not yet know the transport
type for the session.  In this case, the session description SHOULD
configure the journalling system using the parameters defined in the
remainder of Appendix C.1, but SHOULD NOT use j_sec to set the
journalling status.  Recall that if 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 for
unreliable transport).

However, in declarative usage situations where the creator of the
session description knows journalling is always required or never
required, the session description SHOULD use the j_sec parameter.

C.1.2 The j_update Parameter

In Section 4, we 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 the 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 MIME parameter may be used to override
this default.

We define three symbolic values for j_update: "anchor", to indicate that
the stream uses the anchor sending policy, "open-loop", to indicate that
the stream uses the open-loop sending policy, and "closed-loop", to
indicate that the stream uses the closed-loop sending policy.  See
Appendix C.1.3 for examples session descriptions that use the j_update
parameter.

Parties MUST NOT accept a j_update value that violates the recovery
journal mandate (Section 4).

Other IETF standards-track documents may define additional sending
policies for the recovery journal system.  These documents MUST define
new symbolic values for the j_update parameter to signal the use of the
new policy.  If a session description uses a j_update value unknown to
the recipient, the recipient MUST NOT accept the description.

C.1.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



Lazzaro/Wawrzynek                                              [Page 89]


INTERNET-DRAFT                                             25 April 2005


satisfies the recovery journal mandate (Section 4), as the checkpoint
history always covers the entire stream.

The anchor policy does not require the use of the Real Time Control
Protocol (RTCP, [2]) or other feedback from receiver to sender.  Senders
do not need to take special actions to ensure that received streams
start up free of artifacts, as the recovery journal always covers the
entire history of the stream.  Receivers are relieved of the
responsibility of tracking the changing identity of the checkpoint
packet, because the checkpoint packet never changes.

The main drawback of the anchor policy is bandwidth efficiency.  Because
the checkpoint history covers the entire stream, the size of the
recovery journals produced by this policy usually exceeds the journal
size of alternative policies.  For single-channel MIDI data streams, the
bandwidth overhead of the anchor policy is often acceptable (see
Appendix A.4 of [17]).  For dense streams, the closed-loop or open-loop
policies may be more appropriate.

C.1.2.2 The closed-loop Sending Policy

The closed-loop policy is the default policy of the recovery journal
system.  For each packet 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
of a stream, relative to the anchor policy.

The closed-loop policy relies on feedback from receiver 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 the
32-bit extension format defined in [2].  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 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 receivers to
repair indefinite artifacts whenever a packet loss event occur.

We now normatively define the closed-loop policy.  At the moment a
sender prepares an RTP packet for transmission, the sender is aware of R
>= 0 receivers for the stream.  Senders may become aware of a receiver
via RTCP traffic from the receiver, via RTP packets from a paired stream
sent by the receiver to the sender, via messages from a session
management tool, or by other means.  As receivers join and leave a
session, the value of R changes.



Lazzaro/Wawrzynek                                              [Page 90]


INTERNET-DRAFT                                             25 April 2005


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 of the sender.

If the sender has 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 the receiver, normalized to reflect the rollover count of the
sender.

If the sender has not received a feedback report from the receiver, M(k)
is the extended sequence number of the last packet the sender
transmitted before it became aware of the receiver.  If the sender
became aware of this receiver before it sent the first packet in the
stream, M(k) is the extended sequence number of the first packet in the
stream.

Given this definition of M(), 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 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 the closed-loop policy as defined above, a sender may transmit
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.

For example, if a Control Change (0xB) command for Channel Volume
(controller number 7) was sent early in a stream, and later a new
receiver joins the session, the closed-loop policy may permit all
packets sent to the new receiver 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 this issue, the closed-loop policy states that whenever a
sender becomes aware of a new receiver, the sender MUST determine if the
receiver would be subject to indefinite artifacts under the closed-loop
policy.  If so, the sender MUST ensure that the receiver starts the
session free of indefinite artifacts.  For example, to solve the Channel
Volume issue described above, the sender may code the current state of
the Channel Volume controller numbers in the recovery journal Chapter C,
until it receives the first RTCP RR report that signals that a packet
containing this Chapter C has been received.

In satisfying this requirement, senders MAY infer the initial MIDI state
of the receiver from the session description.  For example, the stream
example in Section 6.2 has the initial state defined in [1] for General



Lazzaro/Wawrzynek                                              [Page 91]


INTERNET-DRAFT                                             25 April 2005


MIDI.

In a unicast RTP session, a receiver may safely assume that the sender
is aware of its presence of a receiver from the first packet sent in the
RTP stream.  However, in other types of RTP sessions (multicast,
conference focus, RTP translator/mixer), a receiver is often not able to
determine if the sender is initially aware of its presence as a
receiver.

To address this issue, the closed-loop policy states that if a receiver
participates in a session where it may have access to 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 may monitor the Checkpoint Packet Seqnum for
uncovered loss events, and "err on the side of caution" with respect to
handling stuck notes due to lost MIDI NoteOff commands, but the receiver
is not able to compensate for the lack of Channel Volume initialization
data in the recovery journal.

The receiver MUST NOT discontinue these protective actions until it is
certain that the sender is aware of its presence.  If a receiver is not
able to ascertain sender awareness, the receiver MUST continue these
protective actions for the duration of the session.

Note that in a multicast session where all parties are expected to send
and receive, the reception of RTCP receiver reports from the sender
about the RTP stream a receiver is multicasting is evidence of sender
awareness that the RTP stream multicast by the sender 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 the Checkpoint Packet Seqnum to determine if the sender
is taking actions to prevent loss events for a receiver is a good
indication of sender awareness, as is the sudden appearance 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.

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 to the signalled termination of an RTP stream, via an RTCP
BYE or via session management tools.

As defined earlier in this section, the closed-loop policy states that 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
sender has received at least one feedback report from receiver k, M(k)



Lazzaro/Wawrzynek                                              [Page 92]


INTERNET-DRAFT                                             25 April 2005


is the most recent report of the highest RTP packet sequence number seen
by the receiver, normalized to reflect the rollover count of the sender.

If this receiver k stops sending feedback to the sender, the M(k) value
used by the sender reflects the last feedback report from the receiver.
As time progresses without feedback from receiver k, this fixed M(k)
value forces the sender to increase the size of the checkpoint history,
and thus increases the bandwidth of the stream.

At some point, the sender may need to take action in order to limit the
bandwidth of the stream.  In most envisioned uses of RTP MIDI, long
before this point is reached, the SSRC time-out mechanism defined in [2]
will remove the uncooperative receiver from the session (note that the
closed-loop policy does not suggest or require any special sender
behavior upon an SSRC time-out, other than the sender actions related to
changing R described earlier in this section).

However, in rare situations, the bandwidth of the stream (due to a lack
of feedback reports from the sender) may become too large to continue
sending the stream to the receiver before the SSRC time-out occurs for
the receiver.  In this case, the closed-loop policy states that the
sender should invoke the SSRC time-out for the receiver early.

We now discuss receiver responsibilities in the case of unplanned
disruptions of RTCP feedback from receiver to sender.

In the unicast case, if a sender invokes the SSRC time-out mechanism for
a receiver, the receiver stops receiving packets from the sender.  The
sender behavior imposed by the guardtime parameter (Appendix C.3.2) lets
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 to re-establish the RTP flow from the sender.  Unless the
receiver expects a prompt recovery of the RTP flow, the receiver MUST
take actions to ensure that the rendered MIDI performance does not
exhibit "very long transient artifacts" (for example, by silencing
NoteOns to prevent stuck notes) while awaiting reconnection of the flow.

In the multicast case, if a sender invokes the SSRC time-out mechanism
for a receiver, the receiver may continue to receive packets, but the
sender will no longer being 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 stream the receiver is 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 SSRC time-outs described for



Lazzaro/Wawrzynek                                              [Page 93]


INTERNET-DRAFT                                             25 April 2005


the unicast case above.

Finally, we note that the closed-loop policy is suitable for use in
RTP/RTCP sessions that use multicast transport.  However, aspects of the
closed-loop policy do not scale well to sessions with large numbers of
participants.  The sender state scales linearly with the number of
receivers, as the sender needs to track the identity and M(k) value for
each receiver k.  The average recovery journal size is not independent
of the number of receivers, as the RTCP reporting interval backoff slows
down the rate of a full update of M(k) values.  The backoff algorithm
may also increase the amount of ancillary state used by implementations
of the normative sender and receiver behaviors defined in Section 4.

C.1.2.3 The open-loop Sending Policy

The open-loop policy is suitable for sessions that are not able to
implement the receiver-to-sender feedback required by the closed-loop
policy, and 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 checkpoint packet for each packet in the stream.  In the absence of
such constraints, a receiver may find that the recovery journal in the
packet that ends a loss event has a checkpoint history 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 the recovery
journal mandate, the open-loop policy assigns specific recovery tasks to
senders, receivers, and the creators of session descriptions.  The
underlying premise of the open-loop policy is that the indefinite
artifacts produces during uncovered loss events fall into two classes.

One class of artifacts are recoverable indefinite artifacts.  Receivers
are able to repair recoverable artifacts that occur during an uncovered
loss event without intervention from the sender, at the 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 loss event, by executing NoteOff commands for all
active NoteOns commands.  This action causes a transient artifacts (a
sudden silent period in the 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 artifacts are unrecoverable indefinite artifacts.  If
this class of artifact occurs during an uncovered loss event, the



Lazzaro/Wawrzynek                                              [Page 94]


INTERNET-DRAFT                                             25 April 2005


receiver is not able to repair the stream.

For example, after 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 the receiver has no way of determining
the 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 how to partition the MIDI command
set into recoverable and unrecoverable commands.  Instead, it assumes
that the creators of the session descriptions are able to come to
agreement 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 session description MUST
use the ch_unused or ch_anchor MIME parameters (defined in Appendix
C.1.3) to protect all unrecoverable MIDI command types from indefinite
artifacts.

In a general sense, the ch_anchor parameter changes the recovery journal
semantics to use the anchor checkpoint policy (Appendix C.1.2.1) for a
command, and the ch_unused parameter acts to exclude a command type from
the stream.  These options act to shield command types from artifacts
during an uncovered loss event.

In the open-loop policy, receivers MUST examine the Checkpoint Packet
Seqnum field of the recovery journal header after every loss event, to
check if the loss event is an uncovered loss event.  Section 5 shows how
to perform this check.  If an uncovered loss event has occurred, a
receiver MUST perform indefinite artifact recovery for all MIDI command
types that are not shielded by ch_anchor and ch_unused parameter
assignments in the session description.

The open-loop policy does not place specific constraints on the sender.
However, the open-loop policy works best if the sender manages the size
of the checkpoint history to ensure that uncovered losses occur
infrequently, by taking into account the delay and loss characteristics
of the network.  Also, as each checkpoint packet change incurs the risk
of an uncovered loss, senders should only move the checkpoint if it
reduces the size of the journal.

C.1.3 Recovery Journal Chapter Inclusion Parameters

The recovery journal chapter definitions (Appendices A-B) specify under



Lazzaro/Wawrzynek                                              [Page 95]


INTERNET-DRAFT                                             25 April 2005


what conditions a chapter MUST appear in the recovery journal.  In most
cases, the definition states that if a certain command appears in the
checkpoint history, a certain chapter type MUST appear in the recovery
journal to protect the command.

In this section, we describe the chapter inclusion MIME parameters.
These parameters modify the conditions under which a chapter appears the
journal.  These parameters are essential to the use of the open-loop
policy (Appendix C.1.2.3), and may also be used to simplify
implementations of the closed-loop (Appendix C.1.2.2) and anchor
(Appendix C.1.2.1) policies.

The parameters may also be used to indicate the MIDI command types that
do not appear in a session.  In this role, the parameters may be used
with streams that do not use journalling.  For example, if a session
partitions a MIDI source into two RTP streams (Appendix C.4), the
parameters may be used to define which commands appear in each stream.

A party MUST NOT accept chapter inclusion parameter values that violate
the recovery journal mandate (Section 4).  In addition, a party MUST NOT
accept chapter inclusion parameter values that yield a MIDI command
stream incompatible with its renderer (Appendix C.5).

Each parameter represents a type of chapter inclusion semantics.  An
assignment to a parameter declares which chapters (or chapter subsets)
obey the inclusion semantics.  We describe the assignment syntax for
these parameters later in this section.

Below, we normatively define the semantics of the chapter inclusion
parameters.  For clarity, we define the action of parameters on complete
chapters.  If a parameter is assigned a subset of a chapter, the
definition applies only to the chapter subset.

  o  ch_unused.  If a chapter is assigned to the ch_unused parameter,
     the command types encoded by the chapter MUST NOT appear in the
     MIDI command sections of stream packets.  As a consequence,
     the chapter MUST NOT appear in the recovery journal.

In contrast with ch_unused, if a chapter is assigned to the parameters
we define below, the command types encoded by the chapter MAY appear in
the MIDI command section of stream packets.

  o  ch_never.  A chapter assigned to the ch_never parameter MUST
     NOT appear in the recovery journal (Appendix A.4.1-2 defines
     exceptions to this rule for Chapter M).

  o  ch_default.  A chapter assigned to the ch_default parameter
     MUST follow the default semantics for the chapter, as defined



Lazzaro/Wawrzynek                                              [Page 96]


INTERNET-DRAFT                                             25 April 2005


     in Appendices A-B.

  o  ch_anchor.  A chapter assigned to the 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 are replaced with
     references to the first packet sent in the stream.

  o  ch_active.  A chapter assigned to the ch_anchor MUST obey a
     modified version of the default chapter semantics.  In the
     modified semantics, certain uses of the terms "C-active"
     and "N-active" in the chapter definitions are replaced by
     the term "active" (quoted terms are defined in Appendix A.1).
     The exact semantics for ch_active appear later in this section.

Parameter assignments obey the following syntax (see Appendix D for
ABNF):

  <parameter> = [channel list]<chapter list>[field list]

The chapter list is mandatory; the channel and field lists are optional.
Multiple assignments to parameters have a cumulative effect, and are
applied in the order of parameter appearance 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 the default values
for the channel list and field list for each chapter that are defined
below.

We then interpret the semantics of the actual parameter assignments,
using the rules below.

A later assignment of a chapter to the same parameter expands the scope
of the earlier assignment.  In most cases, a later assignment of a
chapter to a different parameter cancels (partially or completely) the
effect of an earlier assignment.  An exception is the parameter pair
ch_active and ch_anchor: if a chapter is applied to both parameters, the
semantic modifications of both parameters apply to the chapter.

The chapter list specifies the channel or system chapters for which the
parameter applies.  The chapter list is a concatenated sequence of one
or more of the letters corresponding to the 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 chapter list MUST be upper case, and MUST appear in



Lazzaro/Wawrzynek                                              [Page 97]


INTERNET-DRAFT                                             25 April 2005


alphabetical order.  Letters other than (ABCDEFGHJKMNPQTVWXYZ) that
appear in the chapter list MUST be ignored.

The channel list specifies the 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 list 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.

Several of the systems chapters may be configured to have special
semantics.  Configuration occurs by specifying a channel list for the
systems channel, using the coding described below (note that MIDI
Systems commands do not have a "channel", and thus the original purpose
of the channel list does not apply to systems chapters).  The expression
"the digit N" in the text below refers to the inclusion of N as a
"channel" in the channel list for a systems chapter.

For the J and K Chapter D sub-chapters (undefined System Common), the
digit 0 codes that the parameter applies to the LEGAL field of the
associated command log (Figure B.1.4 of Appendix B.1), the digit 1 codes
that the parameter applies to the VALUE field of the command log, and
the digit 2 codes that the parameter applies 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 to the LEGAL field of the
associated command log (Figure B.1.5 of Appendix B.1) and the digit 1
codes that the parameter applies to the COUNT field of the command log.

For Chapter Q (Sequencer State Commands), the digit 0 codes that the
parameter applies to the default Chapter Q definition, which forbids the
TIME field.  The digit 1 codes that the parameter applies to the
optional Chapter Q definition, which supports the TIME field.

For Chapter X, the digit 0 codes that SysEx "cancel" sublists (Section
3.2 in the main text) MUST NOT appear in the MIDI list.  The digit 1
codes that cancel sublists MAY appear in the MIDI list (the default
condition).  The channel list MUST NOT contain both digits 0 and 1.

Also for Chapter X, 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, as defined in Section 3.2 in
the main text).  The digit 3 codes that any MIDI command type may appear
between SysEx command segments in the MIDI list, with the exception of
the segmented encoding of a second SysEx command (verbatim SysEx
commands are OK).  The channel list MUST NOT contain both digits 2 and
3.



Lazzaro/Wawrzynek                                              [Page 98]


INTERNET-DRAFT                                             25 April 2005


The syntax for field lists follows the syntax for channel lists.  If no
field list is provided, the parameter applies to all controller or note
numbers.

For Chapter C, the field list codes the controller numbers for which the
parameter applies.

For Chapter M, the field list codes the Registered Parameter Numbers
(RPNs) and Non-Registered Parameter Numbers (NRPNs) for which the
parameter applies.  The number range 0-16383 specifies RPNs, the number
range 16384-32767 specifies NRPNs (16384 corresponds to NRPN 0, 32767
corresponds to NRPN 16383).

For Chapters N and A, the field list codes the note numbers for which
the parameter applies.  The note number range specified for Chapter N
also applies to Chapter E.

For Chapter E, the digit 0 codes that the parameter applies to Chapter E
note logs whose V bit is set to 0, the digit 1 codes that the parameter
applies to note logs whose V bit is set to 1.

For sub-chapters J and K of Chapter D, the field list consists of a
single digit, which specifies the number of data octets that follow the
command octet.

For Chapter X, the field list codes the number of data octets that may
appear in a SysEx command.  Thus, the field list 0-255 specifies SysEx
commands with 255 or fewer data octets, the field list 256-429496729
specifies SysEx commands with more than 255 data octets but excludes
commands with 255 or fewer data octets, and the field list 0 excludes
all commands.

The chapter list assigned to the ch_active parameter MUST NOT code
chapters other than Chapters C, E, M, N, T, and A.  The semantics of
ch_active assignment for these chapters are defined below:

  o  Chapter C.  Logs for controllers assigned to ch_active obey
     the semantics defined in Appendices A.3.1-4, except that all
     uses of the term "C-active" are replaced with the term "active".

  o  Chapter E.  If any note number is assigned to ch_active,
     all uses of the term N-active in Appendix A.7 are replaced
     with the term "active.  In addition, MIDI Control Change
     commands no longer act to reset note reference counts.

  o  Chapter M.  Logs for RPN and NRPN parameters assigned to
     ch_active obey the semantics defined in Appendices A.4.1-2,
     except that all uses of the term "C-active" in these



Lazzaro/Wawrzynek                                              [Page 99]


INTERNET-DRAFT                                             25 April 2005


     Appendices are replaced with the term "active".  The ch_active
     parameter does not affect uses of the term "C-active" in the
     Appendix A.4 text that precedes Appendix A.4.1.

  o  Chapter N.  If any note number is assigned to ch_active,
     all uses of the term N-active in Appendix A.6 are replaced
     with the term "active.

  o  Chapter T.  If Chapter T is assigned to ch_active, all uses
     of the term N-active in Appendix A.8 are replaced with the
     term "active.

  o  Chapter A.  If any note number is assigned to ch_active,
     all uses of the term "N-active" in Appendix A.9 are replaced
     with the term "active".

Chapter E parameter assignments to ch_unused indicate that NoteOff and
NoteOn commands do not use the semantics protected by Chapter E.  In
contrast, Chapter N ch_unused assignments refer to all NoteOff and
NoteOn commands.

A secondary parameter assignment syntax customizes Chapter X (see
Appendix D for complete ABNF):

  <parameter> = "__" <h-list> ["_" <h-list>] "__"

The assignment defines a class of SysEx commands whose Chapter X coding
obeys the semantics of the assigned parameter.  The command class is
specified by listing the permitted values of the first N data octets
that follow the SysEx 0xF0 command octet.  Any SysEx command whose first
N data octets match the list is a member of the class.

Each <h-list> defines a data octet 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 the data
octet list.

Using this syntax, each assignment specifies a single SysEx command
class.  Session descriptions may use several assignments to the same (or
different) parameters to specify complex Chapter X behaviors.  The
ordering behavior of multiple assignments follows the guidelines for
chapter parameter assignments described earlier in this section.

The example session description below illustrates the use of the chapter
inclusion parameters:





Lazzaro/Wawrzynek                                             [Page 100]


INTERNET-DRAFT                                             25 April 2005


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 FF1E:03AD::7F2E:172A:1E24
a=rtpmap:96 rtp-midi/44100
a=fmtp:96 j_update=open-loop; ch_unused=ABCDEFGHJKMQTVWXYZ; ch_anchor=P;
ch_anchor=C7.64; ch_never=4.11-13N; 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 the page to accommodate
 memo formatting restrictions; it comprises a single line in SDP)

The j_update parameter codes that the stream uses the open-loop policy.
Most chapters are assigned to ch_unused, a typical MIDI usage pattern of
a low-bandwidth stream.

To guard against indefinite artifacts, the MIDI Program Change command
and several MIDI Control Change controller numbers are assigned to
ch_anchor.  Note that the ordering of the ch_anchor chapter C assignment
after the ch_unused command acts to override the ch_unused assignment
for the listed controller numbers (7 and 64).

Chapter N for several MIDI channels is assigned to ch_never; in
practice, this assignment pattern would reflect knowledge about a
resilient rendering method in use for certain channels.  In this
example, Chapter N for MIDI channels other than 4, 11, 12, and 13 may
appear in the recovery journal, per the default behavior.

The assignment of Chapter X to ch_unused excludes most System Exclusive
commands from the stream.  Exceptions are made for General MIDI System
On/Off commands and for the Master Volume and Balance commands, via the
use of the secondary assignment syntax.

















Lazzaro/Wawrzynek                                             [Page 101]


INTERNET-DRAFT                                             25 April 2005


C.2 Configuration Tools: Timestamp Semantics

The MIDI command section of the payload format consists of a 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 MIME parameter "tsmode" specifies the timestamp semantics for a
stream.  The parameter takes on one of three token values: "comex",
"async", or "buffer".

The default "comex" value specifies that timestamps code the execution
time for a command (Appendix C.2.1), and supports the accurate
transcoding Standard MIDI Files (SMFs, [1]).  The "async" value
specifies an asynchronous timestamp sampling algorithm for time-of-
arrival sources (Appendix C.2.2).  The "buffer" value specifies a
synchronous timestamp sampling algorithm (Appendix C.2.3).

Ancillary MIME parameters MAY follow tsmode in a media description.  We
define these parameters in Appendices C.2.2-3 below.

C.2.1 The comex Algorithm

The default "comex" (COMmand EXecution) tsmode value specifies the
execution time for the command.  With comex, the difference between two
timestamps indicates the time delay between the execution 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, [1]) 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.

Comex is a poor choice for transcoding MIDI 1.0 DIN cables [1], for a
reason that we now explain.  A MIDI DIN cable is an asynchronous serial
protocol (320 microseconds per MIDI byte).  MIDI commands on a DIN cable
are not tagged with timestamps.  Instead, MIDI DIN receivers infer
command timing from the time of arrival of 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 to tell if this time offset existed in the source
performance, or is an artifact of the serial speed of the cable.
However, the RTP MIDI comex interpretation of timestamps declares that a
timestamp offset between two commands reflects the timing of the source
performance.




Lazzaro/Wawrzynek                                             [Page 102]


INTERNET-DRAFT                                             25 April 2005


This semantic mismatch is the reason that comex is a poor choice for
transcoding MIDI DIN cables.  Note that the choice of the RTP timestamp
rate (Section 6.1-2 in the main text) cannot fix this inaccuracy issue.
In the sections that follow, we describe two alternative timestamp
interpretations ("async" and "buffer") that are a better match to MIDI
1.0 DIN cable timing, and to other MIDI time-of-arrival sources.

The "octpos", "linerate", and "mperiod" ancillary MIME parameters
(defined below) SHOULD NOT be used with comex.

C.2.2 The async Algorithm

The "async" tsmode value specifies the asynchronous sampling of a MIDI
time-of-arrival source.  In asynchronous sampling, the moment an octet
is received from a source it is labelled with a wall-clock time value.
The time value has RTP timestamp units.

The "octpos" ancillary MIME parameter defines how RTP command timestamps
are derived from octet time values.  If octpos has the token value
"first", a timestamp codes the time value of the first octet of the
command.  If octpos has the token value "last", a timestamp codes the
time value of the last octet of the command.  If the octpos parameter
does not appear in the media description, the sender does not know the
which octet of the command the timestamp references (for example, the
sender may be relying on an operating system service that does not
specify this information).

The octpos semantics refer to the first or last octet of a command as it
appears on a time-of-arrival MIDI source, not as it appears in an RTP
MIDI packet.  This distinction is significant because the RTP coding may
contain octets that are not present in the source.  For example, the
status octet of the first MIDI command in a packet may have been added
to the MIDI stream during transcoding, to comply with the RTP MIDI
running status requirements (Section 3.2).

The "linerate" ancillary MIME parameter defines the timespan of one MIDI
octet on the transmission medium of the MIDI source 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, the correct linerate
value is 320000 (this value is also the default value for the
parameter).

We now show a session description example for the async algorithm.
Consider a sender that is transcoding a MIDI 1.0 DIN cable source into
RTP.  The sender runs on a computing platform that assigns time values
to every incoming octet of the source, and the sender uses the time
values to label the first octet of each command in the RTP packet.  This
session description describes the transcoding:



Lazzaro/Wawrzynek                                             [Page 103]


INTERNET-DRAFT                                             25 April 2005


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 tsmode=async; linerate=320000; octpos=first
a=sendonly

C.2.3 The buffer Algorithm

The "buffer" tsmode value specifies 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, the RTP sender
examines the buffer.  The sender removes complete commands from the
buffer, and codes those commands in an RTP packet.  The command
timestamp codes the moment of buffer examination, expressed in RTP
timestamp units.  Note that several commands may have the same timestamp
value.

The "mperiod" ancillary MIME parameter defines the nominal periodic
sampling interval.  The parameter takes on positive integral values, and
has RTP timestamp units.

The "octpos" ancillary MIME parameter, defined in Appendix C.2.1 for
asynchronous sampling, plays a different role in synchronous sampling.
In synchronous sampling, the parameter specifies the timestamp semantics
of a command whose octets span several sampling periods.

If octpos has the token value "first", the timestamp reflects the
arrival period of the first octet of the command.  If octpos has the
token value "last", the timestamp reflects the arrival period of the
last octet of the command.  The octpos semantics refer to the first or
last octet of the command as it appears on a time-of-arrival source, not
as it appears in the RTP packet.

If the octpos parameter does not appear in the media description, the
timestamp MAY reflect the arrival period of any octet of the command --
senders use this option to signal a lack of knowledge about the timing
details of the buffering process at sub-command granularity.

We now show a session description example for 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 a buffer upon receipt.  The sender polls the buffer 1000 times a



Lazzaro/Wawrzynek                                             [Page 104]


INTERNET-DRAFT                                             25 April 2005


second, extracts all complete commands from the buffer, and places the
commands in an RTP packet.  This session description describes 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 FF1E:03AD::7F2E:172A:1E24
a=rtpmap:96 rtp-midi/44100
a=fmtp:96 tsmode=buffer; linerate=320000; octpos=last; mperiod=44
a=sendonly

The mperiod value of 44 is derived by dividing the clock rate specified
by the 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 actual sampling period might
not precisely match the nominal mperiod value.
































Lazzaro/Wawrzynek                                             [Page 105]


INTERNET-DRAFT                                             25 April 2005


C.3 Configuration Tools: Packet Timing Tools

In this Appendix, we describe session configuration tools for
customizing the temporal behavior of MIDI stream packets.

C.3.1 Packet Duration Tools

Senders control the granularity of a stream by setting the temporal
duration ("media time") 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 a content streaming session.  The RTP
AVP profile [3] recommends audio packet media times in a range from 0 to
200 ms.

By default, an RTP receiver dynamically senses the media time of packets
in a stream, and chooses the length of 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 RTP MIDI MIME
parameter "rtp_ptime" to set the recommended media time for a packet.
Session descriptions MAY also use the RTP MIDI MIME parameter
"rtp_maxptime" to set the maximum media time for a packet permitted in a
stream.  Both parameters MAY be used together to configure a stream.

The values assigned to the rtp_ptime and rtp_maxptime parameters have
the units of the RTP timestamp for the stream, as set by the rtpmap
attribute (see Section 6.1).  Thus, if rtpmap sets the clock rate of a
stream to 44100 Hz, a maximum packet media time of 10 ms is coded by
setting rtp_maxptime=441.  As stated in the Appendix C preamble, the
senders and receivers of a stream MUST agree on common values for
rtp_ptime and rtp_maxptime if the parameters appear in the media
description for the stream.

0 ms is a reasonable media time value for MIDI packets, and is often
used in low-latency interactive applications.  In a packet with a 0 ms
media time, all commands execute at the instant coded by the packet
timestamp.  The session description below configures all packets in the
stream to have 0 ms media time:










Lazzaro/Wawrzynek                                             [Page 106]


INTERNET-DRAFT                                             25 April 2005


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 [6] MUST NOT be used to
configure an RTP MIDI stream.  Sessions MUST use rtp_ptime in lieu of
ptime, and MUST use rtp_maxptime 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 [13], but are essential for certain
applications of RTP MIDI.

See the Appendix C.6 examples for additional discussion about using
rtp_ptime and rtp_maxptime for session configuration.

C.3.2 The guardtime Parameter

RTP permits a sender to stop sending audio packets for an arbitrary
period of time during a session.  When sending resumes, the RTP sequence
number series continues unbroken, and the RTP timestamp value reflects
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 to guide heuristics for handling lost and late RTP packets.
These models may work poorly if a sender ceases packet transmission for
long periods of time.

Session descriptions may use the MIME parameter "guardtime" to set a
minimum sending rate for a media session.  The value assigned 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, and parties SHOULD be prepared to process values
outside of this range.

The congestion control requirements for sender implementations
(described in Section 8 and [2]) take precedence over the guardtime
parameter.  Thus, if the guardtime parameter requests a minimum sending



Lazzaro/Wawrzynek                                             [Page 107]


INTERNET-DRAFT                                             25 April 2005


rate, but sending at this rate would violate the congestion control
requirements, senders MUST ignore the guardtime parameter value.  In
this case, senders SHOULD use the lowest minimum sending rate that
satisfies the congestion control requirements.

Below, we show a session description that uses the guardtime parameter.

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 FF1E:03AD::7F2E:172A:1E24
a=rtpmap:96 rtp-midi/44100
a=fmtp:96 guardtime=44100; rtp_ptime=0; rtp_maxptime=0

C.3.3 MIDI Time Code Issues

RTP defines tools to synchronize the playout of multiple RTP media
streams.  We discuss stream synchronization issues in the context of the
SSRC field in Section 2.1 of the main text.

In content-creation applications, it may be necessary to synchronize
stream playout with media that are not sent over RTP.  For example,
analog video may be marked with SMPTE 12M timecode, and an application
may need to synchronize MIDI playout the video using timecode.

The MIDI standard includes the MIDI Time Code (MTC) commands for SMPTE
12M timecode [1].  An application MAY use MTC to send timecode data
(including offsets and user data) in the MIDI command stream for
heterogeneous synchronization purposes.




















Lazzaro/Wawrzynek                                             [Page 108]


INTERNET-DRAFT                                             25 April 2005


C.4 Configuration Tools: Stream Description

In an RTP MIDI session, a party may send several RTP MIDI streams.  In
Section 2.1 of the main text, we discuss RTP-oriented issues (SSRC,
payload type, and synchronization issues) for multiple streams.

In this Appendix, we discuss MIDI-oriented issues for multiple streams.
In specific, we show how to label which MIDI name space is associated
with an RTP MIDI stream.  A particular MIDI name space is defined as a
particular set of 16 voice channel commands + Systems commands that
would appear on a MIDI 1.0 DIN cable, as defined by [1].

We define the "musicport" parameter to set the label of RTP MIDI
streams.  The musicport parameter adds these features to RTP MIDI:

  1. A sendonly RTP stream and a recvonly RTP stream may
     be associated to form a "virtual" bidirectional RTP session.

  2. Several streams may target the same MIDI name space.

  3. Several streams may be bundled to form a larger MIDI
     name space, that a single rendering system may treat as
     an ordered entity.

In Appendices C.4.1, we define the musicport parameter.  In Appendix
C.4.2, we show session description examples.

Parties MUST NOT accept multi-stream session descriptions that violate
the recovery journal mandate (defined in Section 4 of the main text).

Other payload formats MAY define musicport MIME parameters.  Formats
would define these parameters so that their streams could be bundled
into RTP MIDI name spaces.  The parameter definitions MUST be compatible
with the musicport semantics defined in this Appendix.

C.4.1 The musicport Parameter

The musicport parameter codes an arbitrary identification number for the
MIDI name space (16 voice channels + systems) of an RTP MIDI payload
type.  The musicport parameter may take on integer values between 0 and
429496729.

If any payload types on an RTP MIDI media line define a musicport
parameter, all payload types on the media line MUST define a musicport
parameter that is assigned the same value.  This restriction implies
that the musicport parameter value of a media stream is independent of
the payload type in use.  Thus, in the text below, we refer to the
musicport parameter of a stream (media line), as shorthand for "the



Lazzaro/Wawrzynek                                             [Page 109]


INTERNET-DRAFT                                             25 April 2005


musicport parameter of the payload type in use by the stream."

To define the musicport parameter, we must first define the concept of a
stream's direction.  For a unicast stream, the term direction implies
"sending from party A to party B travels in one direction, sending from
party B to party A travels in the opposite direction".  For an N-party
multicast stream there are N directions: each path from a party K into
the multicast transport is a unique direction.

If several MIDI streams in an RTP session share the same musicport
value, the streams form an identity relationship.

In an identity relationship, streams that travel in same direction
target the same MIDI name space.  Streams that do not travel in the same
direction have the same MIDI name space characteristics as sendrecv
streams in an RTP MIDI session (as described in Section 6.1 of the main
text).  We refer to such sessions as "virtual" sendrecv sessions.

If several MIDI streams in an RTP session have contiguous musicport
values (i.e. i, i+1, ... i+k), the MIDI name spaces of the streams form
an ordered entity.  In this case, the streams in the entity are said to
share an ordered relationship.

Note that a stream may participate in both an identity and an ordered
relationship.  For example, a stream in an identity relationship may
have a musicport value that forms part of an ordered relationship.  If
the musicport values of two streams are not part of an ordered or
identity relationship, the MIDI name spaces of the two streams are
distinct entities, and there is no relative ordering of the voice
channel numbers in one stream relative to the voice channel numbers in
the other stream.

RTP MIDI streams in an ordered or identity relationship MUST be members
of the same RTP session.  Thus, the RTP MIDI streams MUST be all native
streams or all mpeg4-generic streams.  Thus, we refer to relationships
as being native relationships or mpeg4-generic relationships.

An exception to this "all relationship streams share the same type" rule
applies to relationships that exclusively contain sendonly and recvonly
streams.  In this case, the sendonly streams MUST be all native streams
or all mpeg4-generic streams, and the recvonly streams MUST be all
native streams or all mpeg4-generic streams, but the sendonly and
recvonly streams may be of differing types.

For native relationships, at most one stream may specify MIDI renderers
(using the tools described in Appendix C.5).  Each MIDI rendering type
may define its own semantics with regard to identity and ordered
relationships.



Lazzaro/Wawrzynek                                             [Page 110]


INTERNET-DRAFT                                             25 April 2005


For mpeg4-generic relationships, at most one stream in an identity or
ordered relationship may have a config parameter value other than the
empty string.  In this case, the config value configures the stream.
Alternatively, all config parameters may be set to the empty string.  In
this case, exactly one stream in the relationship MUST define the
configuration using the tools described in Appendix C.5.

For both native and mpeg4-generic relationships, an exception to the
"one stream defines the rendering" rule applies to relationships that
exclusively contain sendonly and recvonly streams.  In this case, a
stream in each direction may define a renderer.

In an identity relationship, a sender MAY partition the MIDI name space
(16 voice channels + systems) into several RTP streams.  We discuss the
SSRC, PT, and synchronization issues of this configuration in Section
2.1 of the main text.  Senders MAY use the chapter inclusion parameters
(Appendix C.1.3) to predefine a partition, or MAY use a dynamic
partitioning strategy.  We now specify receiver and sender
responsibilities to ensure the robust transmission of identity
relationships.

Receivers that merge identity relationship streams into a single MIDI
command stream MUST maintain the structural integrity of the MIDI
commands coded in each stream during the merging process, in the same
way that software that merges traditional MIDI 1.0 DIN cable flows is
responsible for creating a merged command flow compatible with [1].

Senders MUST partition the name space so 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 commands are sent on one stream and
NoteOff commands are sent on the 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 streams.  Receivers MUST assume
that the RPN/NRPN transactions that appear on different identity
relationship streams are independent, and MUST preserve transactional
integrity during the MIDI merge.

A simple way to safely partition voice channel commands is to place all
MIDI commands for a particular voice channel into the same stream.  Safe
partitioning of MIDI Systems commands may be more complicated for
streams that extensively use System Exclusive commands.





Lazzaro/Wawrzynek                                             [Page 111]


INTERNET-DRAFT                                             25 April 2005


C.4.2  Multi-stream examples using musicport

This section shows several session description examples that use the
musicport parameter.

Our first session description example shows two mpeg4-generic streams
that drive the same General MIDI decoder.

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; profile-level-id=12;
config=7A0A0000001A4D546864000000060000000100604D54726B0
000000600FF2F000; musicport=12
m=audio 5006 RTP/AVP 97
c=IN IP4 192.0.2.94
a=rtpmap:97 mpeg4-generic/44100
a=fmtp:97 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)

The musicport values indicate the streams share an identity
relationship.

A variant on this example, whose session description is not shown, would
use two streams in an identity relationship driving the same MIDI
renderer, each with a different transport type.  One stream would use
UDP, and would be dedicated to real-time messages.  A second stream
would use TCP [25] and would be used for SysEx bulk data messages.
















Lazzaro/Wawrzynek                                             [Page 112]


INTERNET-DRAFT                                             25 April 2005


In the next example, two mpeg4-generic streams form an ordered
relationship to drive a Structured Audio decoder with 32 MIDI voice
channels.

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 FF1E:03AD::7F2E:172A:1E24
a=rtpmap:96 mpeg4-generic/44100
a=fmtp:96 streamtype=5; mode=rtp-midi; config=""; profile-level-id=13;
musicport=5
m=audio 5006 RTP/AVP 97
c=IN IP6 FF1E:03AD::7F2E:172A:1E24
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 the page to accommodate
 memo formatting restrictions; they comprise single lines in SDP)

The sequential musicport values for the two streams establishes the
ordered relationship.  The musicport=5 stream maps to Structured Audio
extended channels range 0-15, the musicport=6 stream maps to Structured
Audio extended channels range 16-31.

Both config strings are empty.  The configuration data is specified by
MIME parameters that appear in the fmtp line of the second media
description.  We define this configuration method in Appendix C.5.



















Lazzaro/Wawrzynek                                             [Page 113]


INTERNET-DRAFT                                             25 April 2005


C.5 Configuration Tools: MIDI Rendering

This Appendix defines the session configuration tools for rendering.

The "render" MIME parameter specifies a rendering method for a stream.
The parameter is assigned a token value that 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 whose nature is unspecified.
     It is the default renderer for native RTP MIDI streams.

  o  A "synthetic" renderer transforms the MIDI stream into audio
     output (or sometimes, into stage lighting changes or other
     actions).  It is 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  The "null" renderer discards the MIDI stream.

The "null" render value plays special roles during Offer/Answer
negotiations [13].  A party uses the "null" value in an answer to reject
an offered renderer.  Note that rejecting a renderer is independent from
rejecting a payload type (coded by by removing the payload type from a
media line) and rejecting a media stream (coded by zeroing the port of a
media line that uses the renderer).

Other IETF standards-track documents MAY define additional token values
for the render parameter.  If a party is offered a session description
that uses a token value that is not known to the party, and if the party
needs to know about the renderer for correct operation, 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.

Other MIME parameters MAY follow a render parameter in the media
description, and define the exact nature of a renderer.  The "rinit"
MIME parameter (defined in Appendix C.5.2) specifies the MIME type and
subtype for the renderer, and the "inline", "url", and "cid" MIME
parameters (defined in Appendix C.5.3) specify renderer initialization
data.  We describe these parameters (and related renderer MIME
parameters) in the sections below.

Special rules apply to using the render parameter in an mpeg4-generic
stream.  We define these rules in Appendix C.5.5.




Lazzaro/Wawrzynek                                             [Page 114]


INTERNET-DRAFT                                             25 April 2005


C.5.1 The multimode Parameter

A media description MAY contain several render parameters.  By default,
if a media description lists several render parameters, a receiver MUST
choose exactly one renderer from the list to render the stream.  The
MIME parameter "multimode" may be used to override this default.  We
define two token values for multimode: "one" and "all":

  o  The default "one" value requests rendering by exactly one of
     the listed renderers.

  o  The "all" value requests the synchronized rendering of the RTP
     MIDI stream by all listed renderers, if possible.

If the multimode parameter appears in a media description, it MUST
appear before the first render parameter assignment.

If the multimode parameter is assigned the "all" value, receivers MUST
be aware of the Reset State commands (Appendix C.1) for all stream
renderers, and MUST insure that no renderer experiences indefinite
artifacts due to the presence (or the loss) of a Reset State command.

Render parameters appear in the media description in order of decreasing
priority.  A receiver MAY use the priority ordering to decide which
renderer(s) to retain in a session.

If the "offer" in an Offer/Answer-style negotiation [13] contains a
media description with one or more render parameters, the "answer" MUST
set the render parameters of all unchosen renderers to "null".

C.5.2 The rinit Parameter

The "rinit" MIME parameter defines the exact nature of the renderer.  At
most one rinit parameter MAY follow a render parameter in a media
description.  The value assigned to the rinit parameter MUST be the MIME
type/subtype [8] for the renderer.

Authors of rendering systems and MIDI APIs MUST register [24] a MIME
subtype for use with RTP MIDI.  Authors of rendering systems MUST NOT
use "audio/octet-stream" or "application/octet-stream" type/subtypes as
an rinit MIME type/subtype, as this practice limits interoperability.

A renderer that directly produces audio output SHOULD use the "audio"
MIME type.  API presentation renderers, and renderers that control
primarily non-audio devices, SHOULD use the "application" MIME type.
MIME types other than "audio" and "application" MUST NOT be used.

The MIME subtype registration for a renderer MAY define a data object.



Lazzaro/Wawrzynek                                             [Page 115]


INTERNET-DRAFT                                             25 April 2005


Additional MIME parameters (defined in Appendix C.5.3) MAY follow the
rinit parameter to encode an instance of the object.  Alternatively, an
instance of the object MAY be made available through other means.

Renderers that directly produce audio or control output usually define a
data object that codes initialization data for the rendering algorithm.
The data object MAY also encapsulate a Standard MIDI File (SMF), so that
the data object may be used as a format for stored performances.  By
default, the SMFs that are encapsulated in a data object MUST be ignored
by an RTP MIDI receiver.  We define MIME parameters to override this
default in Appendix C.5.4.

Renderers that present a MIDI stream to an API usually define a data
object that is compatible with the API.  The data object may describe
the hardware device that generates the stream (manufacturer, model,
etc), information about MIDI command semantics, and audio rendering
algorithm preferences and initialization data.

MIME registrations for renderers MAY define parameters for use with the
renderer.  When used to describe a renderer, these parameters MUST
appear after the "rinit" parameter and before any data object parameters
(defined in C.5.3) for the renderer.  MIME registrations for renderers
MAY specify additional Reset State commands (Appendix A.1).

If a party is offered a session description that uses a renderer whose
rinit MIME subtype value is not known to the party, and if the party
needs to know about the subtype for correct operation, 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.

Special rules apply to using the rinit parameter in an mpeg4-generic
stream.  We define these rules in Appendix C.5.5.


















Lazzaro/Wawrzynek                                             [Page 116]


INTERNET-DRAFT                                             25 April 2005


C.5.3 Encoding rinit Data Objects

The "inline", "url", and "cid" MIME parameters MAY follow the rinit
parameter in a media description.  These parameters encode the
initialization data object for the renderer.

The "inline" parameter supports the inline encoding of the data object.
The parameter is assigned a double-quoted Base64 [8] encoding of the
binary data object, with no line breaks.  Appendix E.4 shows an example
that constructs an inline parameter value.

The "url" parameter is assigned a double-quoted string representation of
a Uniform Resource Locator (URL) for the data object.  The string MUST
specify a HyperText Transport Protocol URL (HTTP, [16]).  HTTP MAY be
used over TCP, or MAY be used over a secure network transport, such as
the method described in [26].  The MIME type/subtype for the data object
SHOULD be specified in the appropriate HTTP transport header.

Two url parameters that appear in sequence, the first assigned to a TCP
HTTP URL and second assigned to a secure HTTP URL, MUST point to the
same data object.  A receiver MUST first access the secure HTTP URL to
fetch the data object if it is able to do so, and only use the TCP URL
if the secure HTTP URL does not work.  The appearance of a TCP and
secure HTTP URL pair indicates the acceptability of using the TCP URL.
If secure access to a URL is REQUIRED for an application, a url
parameter with a TCP HTTP URL value MUST NOT be present.

The "cid" parameter supports data object caching.  The parameter is
assigned a double-quoted string value that encodes a globally unique
identifier for the data object.

A cid parameter MAY immediately follow an inline parameter, in which
case the cid identifier value MUST be associated with the inline data
object.

If a url parameter is present, and if the data object for the URL is
expected to be unchanged for the life of the URL, a cid parameter MAY
immediately follow the url parameter.  The cid identifier value MUST be
associated with the data object for the URL.  A cid parameter assigned
to the same identifier value SHOULD be specified following the data
object type/subtype in the appropriate HTTP transport header.

In the case (described above) of two url parameters offering the same
data object over TCP and secure transport, a cid parameter for this data
object MAY follow the url pair.

If a url parameter is present, and if the data object for the URL IS
expected to change during the life of the URL, a cid parameter MUST NOT



Lazzaro/Wawrzynek                                             [Page 117]


INTERNET-DRAFT                                             25 April 2005


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 that it is
not safe to use a cached copy, as it may change.

Finally, the cid parameter MAY be used without the inline and url
parameters.  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
each renderer.  The correct receiver interpretation of multiple data
objects SHOULD be defined in the renderer MIME registration.

C.5.4 MIDI Channel Mapping

In this Appendix, we specify how to map MIDI name spaces (16 voice
channels + systems) onto a renderer.

In the general case:

  o  A session may define an ordered relationship (Appendix C.4)
     that presents more than one MIDI name space to a renderer.

  o  A renderer may accept an arbitrary number of MIDI name spaces,
     or may expect a specific number of MIDI name spaces.

A session description SHOULD provide a compatible MIDI name space to
each renderer in the session.  If a receiver detects that a session
description has too many or too few MIDI name spaces for a renderer,
MIDI data from extra stream name spaces MUST be discarded, and extra
renderer name spaces MUST NOT be driven with MIDI data (except as
described in Appendix C.5.4.1 below).

If a media description defines several renderers and assigns the "all"
token value to the multimode parameter, the same name space is presented
to each renderer.  However, the "chanmask" MIME parameter may be used to
mask out selected voice channels to each renderer.  We define "chanmask"
and other MIDI management MIME parameters in the sub-sections below.

C.5.4.1 The smf_info MIME Parameter

The smf_info parameter defines the use of all SMFs encapsulated in
renderer data objects (if any).  The smf_info parameter also defines the
use of SMFs coded in the smf_inline, smf_url, and smf_cid MIME
parameters (defined in Appendix C.5.4.2).

The smf_info parameter describes the "render" parameter that most
recently precedes it in the session description.  The smf_info parameter



Lazzaro/Wawrzynek                                             [Page 118]


INTERNET-DRAFT                                             25 April 2005


MUST NOT appear in sessions descriptions that do not use the "render"
parameter, and MUST NOT appear before the first use of "render" in the
session description.

We define three token values for smf_info: "ignore", "sdp_start", and
"identity":

  o  The "ignore" value indicates that the SMFs MUST 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
     the session description.  If a receiver is 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 receiver MUST NOT accept the renderer
     associated with the smf_info parameter.  Options include
     rejecting the renderer (by setting the "render" parameter
     to "null") or rejecting the entire session description.

  o  The "identity" value indicates the SMFs code the identity
     of the renderer.  The value is meant for use in session
     management negotiations [13].  The MIDI commands coded in
     the SMF are informational in nature, and MUST NOT be

  o  The "sdp_start" value codes that SMFs MUST be rendered,
     and that the rendering MUST begin upon the acceptance of
     the session description.  If a receiver is offered a session
     description with a payload type that uses an smf_info parameter
     set to sdp_start, and if the receiver does not support
     rendering SMFs, the receiver MUST NOT accept the payload type.
     Options include rejecting 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 with the
     "unknown" renderer (see Appendix C.6.2.1).  The MIDI commands
     coded in the 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 defined in [1]) to identify
     devices, and use device-specific SysEx commands to describe
     current state of the devices (patch memory contents, etc).

Other IETF standards-track documents MAY define additional token values
for smf_info.

If a party is offered a session description that uses an smf_info



Lazzaro/Wawrzynek                                             [Page 119]


INTERNET-DRAFT                                             25 April 2005


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, the media stream, or
the entire session description.

We now define the rendering semantics for the "sdp_start" token value in
detail.

The SMFs and RTP MIDI streams in a session description share the same
MIDI name space(s).  In the simple case of a single RTP MIDI 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 in Appendix
C.4.1 also apply to merging RTP and SMF MIDI data.

If a payload type codes multiple SMFs, the SMF name spaces are presented
as an ordered entity to the renderer.  The first SMF maps to the first
renderer name space, the second SMF maps to the second renderer name
space, etc.  If the associated RTP MIDI streams also form an ordered
relationship, the first SMF is merged with the first name space of the
relationship, the second SMF is merged to 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 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.

C.5.4.2 The smf_inline, smf_url, and smf_cid MIME Parameters

In some applications, the renderer data object may not encapsulate SMFs,
but an application may wish to use SMFs in the manner defined in
Appendix C.5.4.1.

The "smf_inline", "smf_url", and "smf_cid" MIME parameters address this
situation.  These parameters use the syntax and semantics of the inline,
url, and cid parameters defined in Appendix C.5.3, except that the
encoded data object is an SMF.

The "smf_inline", "smf_url", and "smf_cid" parameters belong to the
"render" parameter that most recently precedes it in the session
description.  The "smf_inline", "smf_url", and "smf_cid" parameters MUST
NOT appear in sessions descriptions that do not use the "render"
parameter, and MUST NOT appear before the first use of "render" in the
session description.  If several "smf_inline", "smf_url", or "smf_cid"
parameters appear for a renderer, the order of the parameters defines
the SMF name space ordering.



Lazzaro/Wawrzynek                                             [Page 120]


INTERNET-DRAFT                                             25 April 2005


If smf_url points to a MIME object, the "application/octet-stream"
type/subtype SHOULD be used for the object.

C.5.4.3 The chanmask MIME Parameter

The chanmask MIME parameter instructs the renderer to ignore all MIDI
voice commands for certain channel numbers.  The 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 to ignore the voice channel.

The string length of the chanmask parameter value MUST be 16 (for a
single stream or an identity relationship) or a multiple of 16 (for an
ordered relationship).

The chanmask parameter describes the "render" parameter that most
recently precedes it in the session description; chanmask MUST NOT
appear in sessions descriptions that do not use the "render" parameter,
and MUST NOT appear before the first use of "render" in the session
description.

The chanmask parameter describes the final MIDI name spaces presented to
the renderer.  The SMF and stream components of the MIDI name spaces may
not be independently masked.

If a receiver is offered a session description with a renderer that uses
the chanmask parameter, and if the receiver does not implement the
semantics of the chanmask parameter, the receiver MUST NOT accept the
renderer unless the chanmask parameter value contains only "1"'s.





















Lazzaro/Wawrzynek                                             [Page 121]


INTERNET-DRAFT                                             25 April 2005


C.5.5 The audio/asc MIME Type

In Appendix H.3, we register the audio/asc MIME type.  The data object
for audio/asc is a binary encoding of the AudioSpecificConfig data block
used to configure mpeg4-generic streams (Section 6.2 and [7]).

An mpeg4-generic media description MAY use the render and rinit
parameters with the audio/asc MIME type for renderer configuration.
Several restrictions apply to the use of these parameters in
mpeg4-generic media descriptions:

  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
     MIME parameters MUST follow the normative text in Section 6.2.

  o  Sessions that use identity or ordered relationships MUST follow
     the mpeg4-generic configuration restrictions in Appendix C.4.1.

  o  The render parameter MUST be assigned the value "synthetic",
     "unknown", "null", or a value that has been added to the IANA
     repository for the mode rtp-midi mpeg4-generic parameter "render".
     The "api" token value MUST NOT be used.

  o  The rinit parameter MUST be assigned the value "audio/asc".
     Other rinit token values MUST NOT be used.

  o  If the render parameter is assigned the value "synthetic",
     the AudioSpecificConfig data object MUST be encoded using the
     mechanisms defined in C.5.2-3 (including the mechanism in
     C.5.2 for coding the data object by other means).  The
     AudioSpecificConfig data MUST encode one of the MPEG 4 Audio
     Object Types defined for use with mpeg4-generic in Section 6.2.

  o  If the render parameter is assigned the value "null" or
     "unknown", the data object MAY be omitted.

Several general restrictions apply to the use of the audio/asc MIME type
in RTP MIDI:

  o  A native stream MUST NOT assign "audio/asc" to rinit.

  o  The audio/asc MIME type defines a stored 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 for audio/asc.  The session
description below uses the inline parameter to code the



Lazzaro/Wawrzynek                                             [Page 122]


INTERNET-DRAFT                                             25 April 2005


AudioSpecificConfig block for a mpeg4-generic General MIDI stream.  We
derive the value assigned to the inline parameter in Appendix E.4.

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 the page to accommodate
 memo formatting restrictions; it comprises a single line in SDP)

The session description below uses the url MIME parameter to code the
AudioSpecificConfig block 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 the page to accommodate
 memo formatting restrictions; it comprises a single line in SDP)


















Lazzaro/Wawrzynek                                             [Page 123]


INTERNET-DRAFT                                             25 April 2005


C.6  Interoperability

In a broad sense, we expect RTP MIDI to be used in two different ways:

  o  Existing Internet applications that use RTSP or SIP
     to manage multimedia sessions will add RTP MIDI support.

  o  Products that use MIDI 1.0 DIN networks, USB MIDI networks,
     and Firewire MIDI networks will add support for Internet
     networking, using RTP MIDI for MIDI transport, and using
     existing RTP payload formats for audio and video.

In this Appendix, we define interoperability guidelines for three
potential application areas for RTP MIDI:

  o  MIDI content-streaming applications.  RTP MIDI support is added
     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  RTP MIDI RTSP servers on performance stages and in the studio.
     Real-time devices (examples: MIDI piano controllers, rack-mount
     MIDI-controlled synthesizers and signal processors, MIDI Show
     Control devices) act as RTSP servers on a local area network.

  o  Long-distance network musical performance applications.  RTP MIDI
     is added to SIP-based voice 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 all
implementations MUST implement.

We believe that interoperability specifications only make sense within
an RTP MIDI application class, not between classes.  However, devices
MAY support several application areas.

The applications we address in this section are not an exhaustive list
of potential RTP MIDI uses.  We expect framework documents for other
applications to be developed, within the IETF or within other
organizations.


C.6.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 a multimedia session.  For
example, clicking on a web page link for an Internet Radio channel



Lazzaro/Wawrzynek                                             [Page 124]


INTERNET-DRAFT                                             25 April 2005


launches an RTSP client that uses the link's RTSP URL to contact the
RTSP server hosting the radio channel.

The content may be pre-recorded (example: on-demand replay of
yesterday's football game) or "live" (example: football game coverage as
it occurs) but in either case the user is usually an "audience member"
as opposed to a "participant" (as the user would be in telephony).

In an RTSP session, a client accesses a session description that is
"declared" by the server, either via the 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 description contains a non-zero port number, it
encodes the server's preference for the client's port numbers for RTP
and RTCP reception.  Once media flow begins, the server sends an RTP
MIDI stream to the client, which renders it for presentation, perhaps in
synchrony with video or other audio streams.

We now define the interoperability text for content-streaming RTSP
applications.

In most cases, server interoperability responsibilities are described in
terms of limits on the "reference" session description it MUST provide
for a performance.  The reference session a "lowest common denominator"
session that maximizes the odds that a client will be able to view the
session.  Other session descriptions for a performance SHOULD also be
provided, to offer enhanced support for full-featured clients (just as
Internet Radio services may offer the same content using several audio
codecs at several bandwidths).

Clients MUST support unicast UDP RTP MIDI streams that use the recovery
journal with the closed-loop or the anchor sending policies, and MUST be
able to interpret chapter inclusion parameters in the session
description that qualify the sending policies.

Servers MUST offer a reference session description that sends all RTP
MIDI streams as unicast UDP using the recovery journal and the closed-
loop or anchor sending policies.  Servers SHOULD use the chapter
inclusion parameters in the reference session description, to simplify
the rendering task of the client.

Clients and servers MUST support the use of RTSP interleaved mode (a
method for interleaving RTP onto the RTSP TCP transport).

Clients MUST be able to interpret the timestamp semantics signalled by
the "comex" value of the tsmode parameter (i.e. the timestamp semantics
of Standard MIDI Files [1]).  Servers MUST use the "comex" value for the
"tsmode" parameter in the reference session description.



Lazzaro/Wawrzynek                                             [Page 125]


INTERNET-DRAFT                                             25 April 2005


Clients MUST be able to process 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 parameters in
the session description in order to process packets, but SHOULD be able
to use these parameters to improve packet processing.

Servers SHOULD strive to send RTP MIDI streams in 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 the
rtp_ptime and rtp_maxtime parameters in the session description.

Clients MUST be able to examine the rinit parameter, to determine if a
multimedia session uses a renderer it supports.  Clients MUST be able to
interpret the default "one" value of the "multimode" parameter, to
identify supported renderer(s) from a list of renderer descriptions.
Clients MUST be able to interpret the musicport parameter, to the degree
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 for "inline"), could exceed 300 octets in size MUST
support the url and cid parameters, and thus, must implement the HTTP
protocol in addition to RTSP.

Servers MUST specify complete rendering systems for 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 this writing, the only way for servers to specify a complete
rendering system is to specify an mpeg4-generic RTP MIDI stream in mode
rtp-midi (Section 6.2 and C.5.5).  As a consequence, the only rendering
systems that may be presently used are General MIDI [1], DLS 2 [9], or
Structured Audio [5].  Note that the maximum inline value for General
MIDI is well under 300 octets (and thus clients need not support the
"url" parameter), but the maximum inline values for DLS 2 and Structured
Audio may be quite larger than 300 octets (and thus clients MUST support
the url parameter).

We anticipate that the owners of rendering systems (both standardized
and proprietary) will register MIME subtypes for their renderers.  Once
IANA registration occurs, native RTP MIDI sessions may use rinit and
associated parameters (Appendix C.5.2) to specify complete rendering
systems for RTSP content-streaming multimedia sessions.



Lazzaro/Wawrzynek                                             [Page 126]


INTERNET-DRAFT                                             25 April 2005


Servers MUST NOT use the sdp_start value for the smf_info parameter in
the reference session description, as this use would require clients to
be able to parse and render Standard MIDI Files.

Clients 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 a "lowest common denominator"
rendering system for content providers to target.  Note that this
requirement does not force implementors of a non-GM renderer (such as
DLS 2 or Structured Audio) to add a second rendering engine.  Instead, a
client may satisfy the requirement by including a set of voice patches
that implement the GM instrument set, and using this emulation for
mpeg4-generic GM sessions.

It is RECOMMENDED that servers use General MIDI as the renderer for the
reference session description, because clients are REQUIRED to support
it.  We do not require General MIDI as the reference renderer, because
for normative applications it is an inappropriate choice.  Servers using
General MIDI as a "lowest common denominator" renderer SHOULD use
Universal Real-Time SysEx MIP message [27] to communicate the priority
of voices to polyphony-limited clients.


C.6.2  RTP MIDI RTSP servers on stage and in the studio

In this Appendix, we consider digital devices on a performance stage or
in a recording studio that are connected to a wired or wireless Local
Area Network (LAN).  Media flows travel between the devices using RTP
over IP on the LAN, managed by the RTSP protocol.

To introduce the topic of using RTSP in this domain, we begin with an
example that closely matches the traditional use of RTSP for content
streaming.

Consider a simple MIDI piano controller keyboard.  The keyboard does not
include a synthesis engine, and thus does not produce audio output.  The
keyboard is not configurable via System Exclusive commands, and
therefore does not accept MIDI input.

As a simple media source, the keyboard is a good fit for RTSP.  On the
LAN, the keyboard presents itself as an RTSP server, and delivers RTP
MIDI streams to RTSP clients.  A client accesses the keyboard by
connecting to the server and sending RTSP DESCRIBE, SETUP, PLAY, and
TEARDOWN methods.  The session description returned by the server
includes a recvonly RTP MIDI media line.

Some popular features of real-world piano controllers are easy to add to
the session description.  For example, the keyboard may include audio



Lazzaro/Wawrzynek                                             [Page 127]


INTERNET-DRAFT                                             25 April 2005


input jacks, so that players can plug in microphones.  To send the
microphone signals to the RTSP client, a recvonly media line for an
uncompressed audio payload format is added to the session description.

However, other popular features of keyboard controllers diverge from
RTSP content-streaming conventions.  Keyboards often include audio
outputs, so that external digital sources may be routed to local
speakers and headphones.  Keyboards may also route a MIDI input to its
own internal circuits, so that an external device may configure the
behavior of the keyboard via System Exclusive commands.  Finally,
keyboards may include MIDI 1.0 DIN input and output jacks, so that
musicians may hook up secondary controllers.

A natural way to support these features in RTSP is to allow recvonly AND
sendonly audio and MIDI streams to appear in session descriptions.  A
sendonly stream flows from client back to server.  The standard SETUP
method may be used to define RTP and RTCP ports for media to flow in
both directions.

So far, we have been discussing keyboard controllers, an example a
"user-interface" stage and studio device.  "Signal processors" are a
different type of stage and studio device.  Signal processors accept
audio and/or MIDI input and generate audio and/or MIDI outputs in
response to the inputs.

Like user-interface device session descriptions, session descriptions
for signal processors consist of a set of sendonly and recvonly audio
and MIDI streams.  Session descriptions use structural conventions and
special media parameters to differentiate between user-interface streams
and signal-processor streams.

In this Appendix, we define interoperability guidelines for RTSP servers
and clients in stage and studio applications.  We begin with a
discussion of the scope of this Appendix.  For RTSP devices to
interoperate, three aspects of operation must be defined:

  1.  Upon connecting a device to the LAN, how do other
      nodes on the network know that a new device offering RTSP
      RTP MIDI services has arrived?

  2.  How does a client discover the RTSP URLs for a device,
      so that it can initiate a session with the properties
      it desires?

  3.  What features of RTP MIDI media sessions are mandatory
      for clients and servers to support?  More generally,
      what types of session descriptions, and which RTSP
      methods, are mandatory for clients and servers to support?



Lazzaro/Wawrzynek                                             [Page 128]


INTERNET-DRAFT                                             25 April 2005


We consider issue #1 and significant parts of issue #2 and #3 to be
outside the scope of this Appendix.  We expect a framework document for
stage and studio, developed within the IETF or within another
organization, to fully define an interoperable stage and studio RTSP
stack.

More specifically, with regard to issue #1, this Appendix assumes that
clients discovery of servers has occurred, and that the client knows the
correct network address and ports to initiate contact with the RTSP
server.  We expect a framework document to specify a LAN discovery tool
(such as link-local multicast DNS) for use with stage and studio
devices, and to specify well-defined ports for stage and studio RTSP.

With regard to issue #2, we anticipate three ways for clients to obtain
a session description for the device.  The foolproof way is to send a
DESCRIBE method to the server for the "*" Request-URI token.  In
response, a stage and studio server MUST return the "baseline" session
description for the device.  The purpose of the baseline session
description is to ensure a fundamental level of "out of the box"
interoperability for all stage and studio clients and servers.  We
define the properties of the baseline session description in Appendix
C.6.2.2.

Issue #3 concerns the set of capabilities that all clients and servers
MUST implement.  We define these capabilities in Appendix C.6.2.1.  The
selection of the Appendix C.6.2.1 capabilities was driven by the
requirements of the baseline session description.  Thus, we expect a
framework document to define "profiles" that expand the required
capabilities for different classes of devices.

By its nature, the baseline session description offers a "lowest common
denominator" of service, that may not fully exploit the capabilities of
a device.  We expect the framework document to specify two additional
services for session descriptions to reach beyond "lowest common
denominator" service:

  o  A hierarchy of RTSP URLs for session descriptions with
     certain properties, that all devices MUST implement.
     The framework document may also specify human-friendly
     (HTML) and machine-friendly (XML) HTTP URL
     hierarchies to support discovery of the RTSP URLs.

  o  A policy for the use of the RTSP ANNOUNCE method, so that
     clients may upload a session description with specific
     properties to a server.

All framework documents MUST reserve all URLs beginning with /device/
for the exclusive use of the device.  Stage and studio devices MUST



Lazzaro/Wawrzynek                                             [Page 129]


INTERNET-DRAFT                                             25 April 2005


restrict its URLs to the /device/ tree, to avoid collisions with future
frameworks.  Devices manufacturers SHOULD inform customers of its
/device/ URL tree in documentation, in the same way MIDI implementation
charts are included in user documentation.

The remainder of this Appendix is organized as follows.  As mentioned
above, Appendix C.6.2.1 defines the REQUIRED capabilities of RTSP
clients and servers for stage and studio, and Appendix C.6.2.2 defines
the baseline session description that MUST be offered by servers.  In
Appendix C.6.2.3, we show example session descriptions for several
common types of stage and studio devices.

Finally, we note that RTSP servers and clients are logical, not
physical, devices.  It may make sense for certain products to implement
both server and client functionality.  For example, a piano keyboard
controller may choose to implement an RTSP server (so that applications
running on a general-purpose computer may access it by acting as an RTSP
client) and an RTSP client (so that users can choose to play rack-mount
music synthesizers that appear as servers in the keyboard's LCD user-
interface display).

C.6.2.1  Capabilities of servers and clients

In this Appendix section, we define the the order of appearance of media
lines in the session description, and the attributes (including the fmtp
attribute lines that define parameter values) that belong to each media
line.  Stage and studio RTSP clients and servers MUST be able to
interpret the structure we define below.

A schematic of the session description structure appears below:

    ["auxiliary" audio and video media lines]

    ["intrinsic" MIDI media lines]

    ["auxiliary" MIDI media lines]

    ["signal processor" audio and video media lines]

The schematic introduces the media session taxonomy:

   "Auxiliary" media lines code audio, video, and MIDI streams that
   service (logical) input and output connectors on the server
   device.  Examples of auxiliary services include audio line-level
   and microphone inputs, audio headphone, speaker, and line-level
   outputs, and MIDI 1.0 DIN input and output jacks.

   "Intrinsic" MIDI media lines are involved with the core



Lazzaro/Wawrzynek                                             [Page 130]


INTERNET-DRAFT                                             25 April 2005


   operation of the device (in contrast to auxiliary MIDI media
   lines).  Examples: recvonly MIDI streams that carry live
   controller data from user-interface devices, sendonly MIDI
   streams that drive the rendering engine of signal processor
   devices, sendonly and recvonly MIDI streams that carry System
   commands that configure or synchronize servers and clients.

   "Signal processor" media lines code audio and video media
   streams that function as the inputs and outputs of a signal
   processing server.

If a session description DOES NOT contain MIDI media lines, the audio
and video media lines in the session are all auxiliary media lines.

If MIDI media lines DO exist in the session description, the first set
of MIDI media lines that appear in the session description MUST be the
intrinsic MIDI streams for the device.  The intrinsic streams MUST form
an ordered and/or identity relationship, through the use of the
musicport parameter.  Thus, clients and servers MUST be able to
interpret the musicport parameter.

In the special case of a single intrinsic MIDI media line, the line MUST
be labelled with a musicport parameter whose value separates it from all
other relationships in the session.

If the device has auxiliary MIDI connectors, the auxiliary MIDI media
lines for these connectors MUST directly follow the intrinsic MIDI media
lines.  Auxiliary MIDI media lines MUST form ordered and/or identity
relationships distinct from the intrinsic relationships.

Audio and video media lines for signal processing streams MUST appear
after all MIDI media lines in the session description.

In the special case of a signal processing device that does not support
MIDI input or output, a single intrinsic MIDI media line MUST still
appear in the session.  This media line MUST be marked by the "inactive"
attribute, MUST specify 0 as its port, and MUST NOT be associated with
an RTSP control URL.

Session descriptions MUST define a one-to-one match between media lines
and device functions.  For example, if the auxiliary audio inputs for a
device consist of one monophonic microphone input, the session
description MUST list a single one-channel recvonly media line for the
microphone, not several.

In the subsections below, we discuss capability requirements of the
media lines that appear in RTSP stage and studio session descriptions.




Lazzaro/Wawrzynek                                             [Page 131]


INTERNET-DRAFT                                             25 April 2005


C.6.2.1.1  MIDI media lines

In RTSP stage and studio session descriptions, both clients and servers
may function as both senders and receivers of MIDI streams.  Unless
otherwise noted, the rules below for "RTP MIDI senders" or "RTP MIDI
receivers" apply to both server and clients, and rules for "RTSP
servers" or "RTSP clients" apply to both senders and receivers.

Likewise, in the absence of "intrinsic" or "auxiliary" qualifiers, the
rules below apply to all MIDI streams in the session description.

In addition, we use the term "interactive MIDI commands" to refer to all
MIDI channel commands and all Systems commands, excepting System
commands that transfer bulk data or that are related the transfer of
bulk data.  We define "bulk data" commands as System commands that code
more than 12 data octets; commands with more than 12 data octets are a
poor match for the recovery journal mechanism.

All MIDI media lines in the session description MUST be marked as
recvonly (flow from server to client), or as sendonly (flow from client
to server), or as inactive.

The only role for the inactive attribute is to signal that a MIDI media
line is a separator in signal processing device that does not use MIDI,
as described earlier in this Appendix.  Otherwise the inactive
attribution MUST NOT appear in a session description.

Note that the sendrecv attribute MUST NOT be used.  In lieu of sendrecv,
the musicport parameter is used create virtual sendrecv streams, by
forming identity relationships between sendonly and recvonly streams.
We forbid sendrecv streams to ensure unambiguous semantics for RTSP
control URLs, as we discuss later in this Appendix.

We now discuss transport issues for MIDI streams.

Senders MUST send all interactive MIDI commands over UDP transport.
These streams MUST use the recovery journal with the closed-loop or the
anchor sending policies.  Receivers MUST be prepared to accept unicast
UDP RTP MIDI streams that use the recovery journal with the closed-loop
or the anchor sending policies.  Sender and receiver support of
multicast UDP is OPTIONAL.

For intrinsic MIDI streams, the chapter inclusion parameters MUST be
used indicate the types of MIDI commands that a server does not intend
to process (for sendonly streams) or does not intend to send (for
recvonly streams).  Clients use these parameters to infer the purpose of
streams.  For example, if the intrinsic recvonly stream indicates that
all voice channel commands will not be sent, a client may infer that the



Lazzaro/Wawrzynek                                             [Page 132]


INTERNET-DRAFT                                             25 April 2005


server does not intend to act as a user-interface device, and that the
stream is provided for Systems command transport.

Senders MUST send bulk-data commands over TCP transport using [25], and
receivers MUST support TCP transport using [25].  TCP traffic MUST
exclusively be bulk-data commands, and commands that are related to the
transport of bulk-data (such as hand-shaking commands).  As noted in the
previous paragraph, all other (interactive) traffic MUST flow over UDP
RTP MIDI streams.

Session descriptions MUST be constructed with this constraint in mind.
Thus, if a server is supporting the receipt of bulk-data commands on a
sendonly stream, or if the server is support the transmission of bulk-
data commands on a recvonly stream, a TCP media line MUST be provided
for the stream.

Session descriptions MUST place UDP and TCP RTP MIDI streams that form
part of the same MIDI name space in an identity relationship.  This rule
is particularly important for auxiliary MIDI streams, which may
terminate on a MIDI 1.0 DIN cable.

For intrinsic MIDI streams, it is usually more convenient to allocate a
dedicated MIDI name space for bulk-data System commands.  In this case,
rather than sharing an identity relationship, the TCP stream and UDP
stream would share an ordered relationship.

If an identity relationship binds a TCP sendonly stream to a TCP
recvonly stream, recvonly and sendonly RTP packets flow bidirectionally
on a single TCP flow, and RTCP packets flow bidirectionally on a
companion TCP flow.

Except for inactive MIDI streams, each MIDI media stream MUST include
exactly one RTSP control URL.  Clients are under no responsibility to
access all RTSP control URLs, and servers MUST be implemented to cope
with clients that access some URLs but not others.  For example, a
client that does not use an auxiliary stream is under no responsibility
to open its URL.

To facilitate this client control in the case of TCP streams, session
descriptions MUST set the connection attribute (as referenced in [25])
for TCP streams so that responsibility for opening a socket lies with
the client, not the server.  For TCP streams, the client_port and
sender_port values returned by the RTSP SETUP method replace the media
line ports in the TCP connection algorithms referenced in [25].

Firewalls will generally not be an issue within the LAN environment of
stage and studio.  Therefore, support of RTSP interleaved mode is
OPTIONAL for both server and client.



Lazzaro/Wawrzynek                                             [Page 133]


INTERNET-DRAFT                                             25 April 2005


We now discuss timestamps, packet timing, and packet sending algorithms
for RTP MIDI streams.

Recall that the tsmode parameter controls the semantics of command
timestamps in the MIDI list of RTP packets.

Senders and receivers MUST support clock rates of 44.1 kHz, 48 kHz, 88.2
kHz, and 96 kHz.  Senders MUST be able to send streams using the
"comex", "async", and "buffer" tsmode values.  Receivers MUST be able to
interpret the "comex", "async", or "buffer" values for the tsmode
parameter.

Recall that rtp_ptime and rtp_maxptime parameters encode the nominal and
maximum temporal duration of packets in an RTP MIDI stream, and that the
guardtime parameter sets the minimum rate of RTP packet transmission.

Session descriptions MUST present rtp_ptime, rtp_maxptime, and guardtime
values that support the latency that users would expect from the device,
subject to bandwidth constraints.  Implementers should refer to [22] for
information on packet sending algorithms for latency-sensitive
applications.

Senders MUST be able to create packet streams over a wide range of
temporal durations: from rtp_ptime and rtp_maxptime values of 0, to
rtp_ptime and rtp_maxptime values that code 100 ms.  Senders MUST be
able to implement the semantics of the guardtime parameter, for times
from 0 ms to 5000 ms.

Receivers MUST be able to process an RTP MIDI stream whose packets
encode an arbitrary temporal duration.  Thus, receivers MUST have the
ability to use a playout buffer.

Receivers MUST be able to interpret the rtp_ptime, rtp_maxptime, and
guardtime parameters.  Receivers MUST be able to handle rtp_ptime and
rtp_maxptime values that range from 0 to values that code 100 ms.  As
senders MUST abide by values set for these parameters in a session
description, a receiver SHOULD use these values to size its playout
buffer to produce the lowest reliable latency for a session.  Receivers
MUST be able to implement the semantics of the guardtime parameter, for
times from 0 ms to 5000 ms.

C.6.2.1.2  MIDI rendering

The specification of a renderer is OPTIONAL for MIDI media lines in
stage and studio session descriptions.  Clients and servers MUST be able
to interpret session descriptions whose MIDI media lines do not specify
a renderer.




Lazzaro/Wawrzynek                                             [Page 134]


INTERNET-DRAFT                                             25 April 2005


Although the specification of a renderer is OPTIONAL, it is also quite
valuable, and has the potential for reducing the amount of manual
initialization that is necessary in stage and studio environments.
Thus, we encourage developers to register media types, as we discuss in
Appendix C.5.

If a render parameter is not specified for a stream, a client or server
MUST send or receiver the stream as it would send or receive on a MIDI
1.0 DIN cable transport (this requirement does not pertain to timestamp
issues: senders MAY use comex, async, or buffer values for the tsmode
parameter).  The normative text in this Appendix (Appendix C.6.2), such
as text defining the session description structure and the use of
attributes and parameters, ensures that clients and servers have
sufficient information to perform correctly with an unspecified
renderer.

MIDI media streams code that a renderer is "unspecified" in two
different ways.  As described in Section 6.1 in the main text, a native
RTP MIDI stream that does not use the render parameter has an
unspecified renderer.  As described in Appendix C.5, a render parameter
assigned the "unknown" value also codes that the renderer is
unspecified.  Clients and servers MUST be able to interpret both session
description encodings of an unspecified renderer for a stream.

If a device is a product from a manufacturer with a MIDI Manufacturer's
ID number, using "unknown" to code an unspecified renderer is
RECOMMENDED for one MIDI media line in the session.  For this line, the
render parameter SHOULD be followed by an "smf_info" parameter set to
the "identity" token, which should in turn be followed by an
"smf_inline" parameter whose value identifies the manufacturer and the
device.  To reduce session description size, this construction SHOULD
appear only once in the session description, ideally for a sendonly
intrinsic MIDI media line.

We now discuss how devices may specify renderers in stage and studio
session.  The rules below work for both native RTP MIDI sessions and
mpeg4-generic RTP MIDI sessions.  We begin with several definitions.

In some contexts, using a renderer provides an enhanced experience, but
the renderer is not an essential part of the session description.  We
refer to these renderers as "enhanced experience" renderers.

For example, the session description for a piano keyboard controller may
define a recvonly native MIDI stream to transport the performance data
of the pianist.  Several payload types may be used to define API
renderers for common operating system MIDI APIs, so that device
information in an OS-specific format is available to the client.




Lazzaro/Wawrzynek                                             [Page 135]


INTERNET-DRAFT                                             25 April 2005


Alternatively, a session description may use a renderer to inform a
client of essential information.  For example, a signal processor device
may require initialization by the client via System Exclusive commands.
The sendonly stream in its session description may define a renderer,
whose data object describes how to perform initialization.  If a client
is not aware of the renderer, it will not be able to perform the
initialization, and the device will not work.  We refer to these
renderers as "essential experience" renderers.

We now specify rules for renderer use on RTP MIDI media lines.

As a rule, stage and studio MIDI media lines MUST be sendonly or
recvonly (inactive streams are the sole exception to the rule).  In
relationships that consist of sendonly and recvonly streams, at most two
renderers may be specified for a relationship: one renderer for all
sendonly streams, and one renderer for all recvonly streams.

All renderers for the sendonly streams in the relationship MUST be
defined in the first sendonly media line in the relationship that
appears in the session description.  Renderers are defined by the
appearance of one or more payload types on the media line, each of which
defines a renderer in its parameter list.  Renderers appear in order of
decreasing server preference.

For "enhanced experience" renderers (but NOT for "essential experience"
renderers) one payload type in the list MUST define the "unspecified"
renderer, by using a render parameter set to "unknown" (this works for
both native and mpeg4-generic streams).  This requirement lets clients
unaware of any listed renderer use a device with MIDI 1.0 DIN semantics.

All other sendonly streams in the relationship MUST specify a single
payload type that sets its render parameter to unknown.  The type of
this stream (native or mpeg4-generic) MUST match the other sendonly
streams in the relationship.  This payload type acts to defer the
rendering specification to the primary sendonly media line.

To code that the renderer for sendonly streams also applies to recvonly
streams, all recvonly streams MUST specify a single payload type that
sets its render parameter to unknown.

The rules in the previous three paragraphs also apply if all uses of
"sendonly" are switched to "recvonly", and vice versa.

Clients and servers supporting renderers whose data object (as encoded
by a parameter value for "inline"), could exceed 300 octets in size MUST
support the url and cid parameters that support remote transport of
renderer data objects, and thus, must implement the HTTP protocol in
addition to RTSP.  Note that for mpeg4-generic RTP MIDI streams, the



Lazzaro/Wawrzynek                                             [Page 136]


INTERNET-DRAFT                                             25 April 2005


data objects for DLS 2 and Structured Audio require url and cid
parameter support, but the data object for General MIDI does not.

Servers and clients MUST support the chanmask parameter.  Note that this
parameter may appear for the "unknown" render value, and so this
REQUIRED behavior applies to servers and clients that do not support
renderers.

C.6.2.1.3  Audio media lines

We now define interoperability guidelines that apply to audio streams
that appear in the session description.

For auxiliary and signal processing audio stream groups, the ordering of
media lines and the relative order of audio channels within each audio
stream MUST reflect the numbering convention used by the device.

Senders and receivers that support audio streams MUST support the L16
(16-bit linear, no pre-emphasis) and L24 (24-bit linear, no pre-
emphasis) RTP payload formats for uncompressed audio, at sample rates of
44.1 kHz, 48 kHz, 88.2 kHz, 96 kHz.

Note that this requirement concerns transport, not signal processing:
devices are not constrained to operate internally at all of these sample
rates and resolutions, but MUST be able to convert to these sample rates
and resolutions for transport over RTP.

Servers and clients that support sending or receiving audio streams MUST
support sending or receiving 1-channel and 2-channel streams.

Senders and receivers that support audio stream MUST support UDP
transport.  Session descriptions MUST specify ptime and maxptime values
that support the latency that users would expect from the device,
subject to bandwidth constraints.  Senders and receivers MUST be able to
interpret ptime and maxptime for audio streams, for values between 2 ms
and 100 ms inclusive.

Special considerations apply for the synchronized startup of signal
processing audio and MIDI streams.  We discuss this topic in the
examples shown in Appendix C.6.2.3.

C.6.2.2  The baseline session description

A server MUST return the "baseline" session description in response to
an RTSP DESCRIBE method for the "*" Request-URI.  In this Appendix
section, we define interoperability guidelines for the baseline session
description.




Lazzaro/Wawrzynek                                             [Page 137]


INTERNET-DRAFT                                             25 April 2005


The role of the baseline session description is to ensure a common level
on interoperability between all RTSP stage and studio clients and
servers.  The "*" token is the only Request-URI that servers are
REQUIRED to support, and thus, the only Request-URI that clients can
rely on a priori to exist.

Note that "/" (the root of the absolute Request-URI name space) is not
synonymous with "*".  We expect the framework document to define a
special use for "/" that will be different than the "*" use we define in
this document.  Thus, servers MUST NOT return the baseline session
description for "/", and clients MUST NOT expect servers to do so.

The baseline session description has two goals: to offer an accurate
portrayal of the capability of the device, and to provide as much
network access to device functionality as possible.  If it is not
possible to provide full device access within the constraints of a
single session description, the offered capabilities SHOULD be weighted
to fall within the REQUIRED client capabilities defined in Appendix
C.6.2.1.  Below we list the most important interoperability issues of
this nature:

  o  Multicast UDP is OPTIONAL for clients.  For audio, TCP
     is OPTIONAL for clients.

  o  Clients MUST support send and receive clock rates of
     44.1 kHz, 48 kHz, 88.2 kHz, and 96 kHz in audio and MIDI
     streams.

  o  For audio streams, clients MUST support L16 and L24
     uncompressed audio, and MUST support 1-channel and
     2-channel streams.

  o  Client senders and receivers of MIDI streams MUST
     support rtp_ptime and rtp_maxptime values that code from
     0 ms to 100 ms.  Client senders and receivers of audio
     streams MUST support ptime and maxptime values from
     2 ms to 100 ms.

  o  Renderer support is OPTIONAL for clients.  Client support
     of the url parameter is OPTIONAL for clients that only
     support renderers whose data object cannot be larger than
     300 bytes.

To accurately portray the capabilities of a device, there MUST be a one-
to-one match between media lines and device function.  For example, if
the auxiliary audio inputs for a device consist of one monophonic
microphone input, the session description MUST list a single one-channel
recvonly media line for the microphone, not several.



Lazzaro/Wawrzynek                                             [Page 138]


INTERNET-DRAFT                                             25 April 2005


Session descriptions are able to let clients choose a configuration for
a sendonly stream by defining several payload types for the stream.
Clients inform senders of their choice via the payload type field in the
RTP header in each packet sent.

However, the 7-bit range of payload formats, and the desire for
reasonably short session descriptions, limit the use of this mechanism
to the most important functional variations for a device.  Moreover,
this mechanism does not work for recvonly streams.  While one could
imagine pairing each payload type with its own control URL, so that
clients could communicate recvonly payload type choice via its URL
choice, unfortunately this construction is not permitted by RTSP.  Note
that the primary mechanism for choice in RTSP is to choose a different
session description, as we discussed in Appendix C.6.2.

Given this limit, we offer recommendations for default values for common
functionality.

Audio streams offering limited options SHOULD choose the highest
performance option that clients MUST support.  For example, a 96 kHz L24
stream as a sole option is preferable to a 44.1 kHz L16 stream.

To maximize the potential temporal fidelity of sendonly MIDI media
lines, the "comex" tsmode value is RECOMMENDED for all streams that do
not terminate in a MIDI 1.0 DIN cable.  For streams that DO terminate in
a MIDI 1.0 DIN cable, the RECOMMENDED tsmode value is "async".

The ptime, maxptime, rtp_ptime, and rtp_maxptime SHOULD be set to limit
payload temporal duration to the range needed to support application
latency, but SHOULD NOT be overly restrictive.  Suggested values for
audio streams are a ptime value of 2 ms and a maxptime value of 10 ms.
Suggested value for MIDI streams are a rtp_ptime value of 0 and an
rtp_maxptime value that codes 2 ms.

C.6.2.3  Examples

In this Appendix section, we show baseline session description examples
for several types of RTSP stage and studio devices, and show how clients
invoke RTSP methods to use these devices.












Lazzaro/Wawrzynek                                             [Page 139]


INTERNET-DRAFT                                             25 April 2005


Below, we show the baseline session description for a simple piano
keyboard controller.

v=0
o=lazzaro 2520644554 2838152170 IN IP4 first.example.net
s=Example
t=0 0
c=IN IP4 192.0.2.94
m=audio 0 RTP/AVP 96
a=control:rtsp://device/mic1
a=recvonly
a=ptime:2
a=maxptime:2
a=rtpmap:96 L24/96000/1
m=audio 0 RTP/AVP 97
a=control:rtsp://device/mic2
a=recvonly
a=ptime:2
a=maxptime:2
a=rtpmap:97 L24/96000/1
m=audio 0 RTP/AVP 98 99
a=control:rtsp://device/lineout
a=ptime:2
a=maxptime:10
a=sendonly
a=rtpmap:98 L16/44100/2
a=rtpmap:99 L24/96000/2
m=audio 0 RTP/AVP 100
a=control:rtsp://device/kbd_midi_out
a=recvonly
a=rtpmap:100 rtp-midi/96000
a=fmtp:100 ch_unused=ABCDEFGHJKMQTVXYZ; ch_default=C0.7.64;
tsmode=comex; rtp_ptime=0; rtp_maxptime=0;
guardtime=9600; musicport=1;
m=audio 0 RTP/AVP 101
a=control:rtsp://device/kbd_midi_in
a=sendonly
a=rtpmap:101 rtp-midi/96000
a=fmtp:101 ch_unused=ABCDEFGHJKMNPQTVWXYZ; ch_default=0X0-15;
tsmode=comex; rtp_ptime=0; rtp_maxptime=0; guardtime=9600;
musicport=1

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







Lazzaro/Wawrzynek                                             [Page 140]


INTERNET-DRAFT                                             25 April 2005


The first media lines declare the auxiliary audio features of the
device, which we now describe.

The device has two microphone inputs that are declared as monophonic
recvonly streams (payload types 96 and 97).  As client choice is not
possible with recvonly streams, the server uses the highest quality
encoding for the signals that all clients are REQUIRED to support
(24-bit linear, 96 kHz).

The device also has a line-level stereo output, with a low-quality
(payload type 100) and a high-quality (payload type 101) variant.  In
this case, the client may choose the desired encoding, and code the
choice in the payload type field of the RTP packets it sends.

Following the auxiliary audio streams are the intrinsic MIDI media lines
for the device: a recvonly stream (payload type 102) to send the
player's performance to the client, and a sendonly stream (payload type
103) to let the client configure the device via System Exclusive
commands.  The client identifies both streams as intrinsic by noting the
identity relationship coded by the musicport commands.  The ch_unused
and ch_default parameters signal the device's intentions for the stream
to the client.

To receive the MIDI keyboard stream, a client sends the SETUP method to
the server:

C->S SETUP rtsp://one.example.com/device/kbd_midi_out RTSP/1.0
     CSeq: 1
     Transport: RTP/AVP/UDP;unicast;client_port=5004-5005

S->  RTSP/1.0 200 OK
     CSeq: 1
     Session: 12345678
     Transport: RTP/AVP/UDP;unicast;client_port=5004-5005
     server_port=20000-20001; ssrc=1827364
















Lazzaro/Wawrzynek                                             [Page 141]


INTERNET-DRAFT                                             25 April 2005


Then, to start stream delivery from ssrc 1827364 at UDP port 5004 (RTP)
and 5005 (RTCP), a client sends the PLAY method to the server:

C->S PLAY rtsp://one.example.com/device/kbd_midi_out RTSP/1.0
     CSeq: 2
     Session: 12345678
     Range: smpte=0:10:00-

S->  RTSP/1.0 200 OK
     CSeq: 2
     Session: 12345678
     Range: smpte=0:10:00-
     RTP-Info: url=rtsp://one.example.com/device/kbd_midi_out RTSP/1.0;
     seq=182873; rtptime=739874

The Range field specifies the start time of the stream in SMPTE
timecode.  If the client was also requesting playback of the two
microphone streams (via separate PLAY methods), the common Range
timecode in each request would facilitate the delivery of synchronized
streams by the server.

After the OK, the server begins sending RTP packets to port 5004 of the
server, and the server and clients begin to exchange RTCP packets that
arrive at 5005 (client) and 2001 (server).

To setup to the auxiliary line outputs of the device, the client sends:

C->S SETUP rtsp://one.example.com/device/lineout RTSP/1.0
     CSeq: 1
     Transport: RTP/AVP/UDP;unicast;client_port=5006-5007

S->  RTSP/1.0 200 OK
     CSeq: 1
     Session: 252604
     Transport: RTP/AVP/UDP;unicast;client_port=5006-5007
     server_port=20002-20003; ssrc=1928374

The server replies with the ports it expects to receive the sendonly
stream (20002 for RTP, 20003 for RTCP), and the ssrc it expects the
stream to be (1928374).  To begin sending the stream, the client uses
the PLAY method:










Lazzaro/Wawrzynek                                             [Page 142]


INTERNET-DRAFT                                             25 April 2005


C->S PLAY rtsp://one.example.com/device/lineout RTSP/1.0
     CSeq: 2
     Session: 252604
     Range: ntp=0-

S->  RTSP/1.0 200 OK
     CSeq: 2
     Session: 252604
     Range: ntp=0-
     RTP-Info: url=rtsp://one.example.com/device/lineout RTSP/1.0;
     seq=39485; rtptime=98374

The server responds with the RTP sequence number and RTP timestamp
values it expects the first RTP packet arriving at 20002 to have.

With the exception of "signal processing" audio streams and the
intrinsic MIDI streams that drive them (discussed in the next example),
the stream timing coded in the Range field for sendonly streams and
recvonly streams are independent.

Next, we show the baseline session description for a simple signal
processing device:

v=0
o=lazzaro 2520644554 2838152170 IN IP4 first.example.net
s=Example
t=0 0
c=IN IP4 192.0.2.94
m=audio 0 RTP/AVP 96
a=control:rtsp://device/synth_midi
a=rtpmap:96 rtp-midi/96000
a=sendonly
a=fmtp:96 ch_unused=ABCDEFGHJKMQTVXYZ; ch_default=0NPW;
ch_default=0C0.7.64;
tsmode=comex; rtp_ptime=0; rtp_maxptime=0;
guardtime=9600; musicport=1
m=audio 0 RTP/AVP 97
a=control:rtsp://device/synth_audio
a=recvonly
a=rtpmap:97 L24/96000/1
a=fmtp:97 ptime=2; maxptime=6

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

This device is a rack-mount music synthesizer.  The only input to the
synth is an intrinsic sendonly MIDI stream (payload type 96).  The synth
output is a recvonly signal processor audio stream (24-bit linear, 96



Lazzaro/Wawrzynek                                             [Page 143]


INTERNET-DRAFT                                             25 April 2005


kHz, mono).  The placement of the audio stream codes its role as a
signal processor stream.

The chapter exclusion parameters for the MIDI stream indicate that the
synth only responds on MIDI voice channel 0, and only responds to basic
voice channel commands (NoteOn/NoteOff, Program Change, Pitch Wheel, Mod
Wheel, Channel Volume, and Sustain Pedal).  Other parameters specify the
type of timestamps (comex) and the media time range (0 ms per packet
only) that the synth expects.

The SETUP methods for the two streams are below, and are similar to the
SETUP exchanges for the keyboard controller.

C->S SETUP rtsp://two.example.com/device/synth_midi RTSP/1.0
     CSeq: 1
     Transport: RTP/AVP/UDP;unicast;client_port=5004-5005

S->  RTSP/1.0 200 OK
     CSeq: 1
     Session: 90125
     Transport: RTP/AVP/UDP;unicast;client_port=5004-5005
     server_port=20000-20001; ssrc=121212



C->S SETUP rtsp://two.example.com/device/synth_audio RTSP/1.0
     CSeq: 1
     Transport: RTP/AVP/UDP;unicast;client_port=5006-5007

S->  RTSP/1.0 200 OK
     CSeq: 1
     Session: 19145
     Transport: RTP/AVP/UDP;unicast;client_port=5006-5007
     server_port=20002-20003; ssrc=1928374

The PLAY methods, however, are different, because the time coded by the
Range fields are shared for signal processor audio streams and intrinsic
MIDI streams.

This shared time enables a client to use RTSP servers as offload clients
in situations where "sample-accurate" audio is essential.  In this
example, the term "sample-accurate" implies that it is possible for the
client to know which audio sample from the recvonly stream correlates
with a particular MIDI command sent on the sendonly stream.







Lazzaro/Wawrzynek                                             [Page 144]


INTERNET-DRAFT                                             25 April 2005


Below, we show how the PLAY methods support sample-accurate timing:

C->S PLAY rtsp://two.example.com/device/synth_midi RTSP/1.0
     CSeq: 2
     Session: 90125
     Range: smpte=0:10:00-

S->  RTSP/1.0 200 OK
     CSeq: 2
     Session: 90125
     Range: smpte=0:10:00-
     RTP-Info: url=rtsp://two.example.com/device/synth_midi RTSP/1.0;
     seq=182873; rtptime=739874



C->S PLAY rtsp://two.example.com/device/synth_audio RTSP/1.0
     CSeq: 2
     Session: 19145
     Range: ntp=0-

S->  RTSP/1.0 200 OK
     CSeq: 2
     Session: 19145
     Range: smpte=0:10:00-
     RTP-Info: url=rtsp://one.example.com/device/synth_audio RTSP/1.0;
     seq=39485; rtptime=98374

The PLAY requests and responses code the following timing semantics:
When interpreting the RTP MIDI stream arriving on its port 20000, the
server equates SMPTE time 0:10:00 with the RTP packet timestamp 739874.
Likewise, when the server begins sending its RTP audio stream to port
5006 on the client, the packet timestamp 98374 will reflect the audio
produced at the same time 0:10:00.

These temporal correlations let the client use the server for sample-
accurate application.














Lazzaro/Wawrzynek                                             [Page 145]


INTERNET-DRAFT                                             25 April 2005


C.6.3  MIDI network musical performance applications

In Internet telephony 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 and tight audiovisual
synchronization (for "lip-sync").  The Session Initiation Protocol (SIP,
[19]) is used for session management.

In this Appendix section, we define interoperability guidelines for
using RTP MIDI 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.

In this Appendix section, we define the REQUIRED capabilities of RTP
MIDI senders and receivers in NMP sessions, and define how session
descriptions exchanged are used to set up network musical performance
sessions.  Elsewhere, we discuss NMP as an application [17] and also
discuss RTP MIDI NMP low-latency implementation techniques [22].

The common usage scenarios for NMP have the following properties:

  o  The application goal is telepresence.  The audio heard by
     sender in response to his MIDI controller should be identical
     to the audio heard by the receiver.  The application goal is
     NOT the remote control of an arbitrary MIDI device.

  o  Network transport is unicast.  Session descriptions define
     performances between two players.  Applications compose
     two-player sessions to implement performances with many
     players.


Thus, we limit our focus here to session setup for two-party unicast
sessions, whose RTP MIDI streams specify a renderer.  Within this
limited scope, the guidelines defined here are sufficient to let
applications interoperate.  We expect framework documents to be
developed to the address broader NMP applications excluded from our
narrow scope in this Appendix section.

SIP lets parties negotiate details of the session, using the
Offer/Answer protocol [13].  However, RTP MIDI has so many parameters
that "blind" negotiations between two parties using different
applications might not yield a common session configuration.

Thus, we now define a set of capabilities that NMP parties MUST support.
Session description offers whose options lie outside the envelope of
REQUIRED party behavior risk negotiation failure.  We also define



Lazzaro/Wawrzynek                                             [Page 146]


INTERNET-DRAFT                                             25 April 2005


session description idioms that the RTP MIDI 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 SIP offer, and
"answerer" for the party answering the offer.  Finally, we note that
unless qualified by the adjective "sender" or "receiver", a 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 stream, it may use
a true sendrecv session or the "virtual sendrecv" construction described
in the preamble to Appendix C and in Appendix C.4.  A true sendrecv
session indicates that the offerer wishes to participate in a session
where both parties use identically-configured renderers.  A virtual
sendrecv session indicates that the offerer is willing to participate in
a 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 recovery journal with the closed-loop or anchor
sending policies.  These streams MUST use the chapter inclusion
parameters to declare the types of MIDI commands that will be sent on
the stream (for sendonly streams) or will be processed (for recvonly
streams), including the size limits on System Exclusive commands.

Note that both TCP and multicast UDP are OPTIONAL.  We make TCP OPTIONAL
because the renderers we expect to find use in NMP rely on the data
object functionality of the "rinit" parameter to initialize the renderer
at the start of the session, and only use System Exclusive commands
during the session for interactive control.  These interactive commands
are small enough to be protected via the recovery journal mechanism of
RTP MIDI UDP streams.

We now discuss timestamps, packet timing, and packet sending algorithms.

Recall that the tsmode parameter controls the semantics of command
timestamps in the MIDI list of RTP packets.

Parties MUST support clock rates of 44.1 kHz, 48 kHz, 88.2 kHz, and 96
kHz.  Parties MUST support streams using 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 of 0, to rtp_ptime and rtp_maxptime
values that code 100 ms.  Thus, receivers MUST be able to implement a
playout buffer.




Lazzaro/Wawrzynek                                             [Page 147]


INTERNET-DRAFT                                             25 April 2005


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 a session description, a receiver
SHOULD use these values to size its playout buffer to produce the lowest
reliable latency for a session.  Implementers should refer to [22] for
information on packet sending algorithms for latency-sensitive
applications.  Parties MUST be able to implement the semantics of the
guardtime parameter, for times from 0 ms to 5000 ms.

We now discuss the use of the render parameter.

Sessions MUST specify complete rendering systems for all 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 this writing, the only way for parties to specify a complete
rendering system is to specify an mpeg4-generic RTP MIDI stream in mode
rtp-midi (Section 6.2 and C.5.5).  We anticipate that the owners of
rendering systems (both standardized and proprietary) will register MIME
subtypes for their renderers.  Once IANA registration occurs, native RTP
MIDI sessions may use rinit and associated parameters (Appendix C.5.2)
to specify complete rendering systems for RTSP content-streaming
multimedia sessions.

All parties MUST support General MIDI (GM) sessions, at a polyphony
limited by the hardware capabilities of the party.  This requirement
provides a "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 [27] to
communicate the priority of voices to polyphony-limited clients.

Note that this requirement does not force implementors of a non-GM
renderer (DLS 2 or Structured Audio) to add a second rendering engine.
Instead, a client may satisfy the requirement by including a set of
voice patches that implement the GM instrument set, and using this
emulation for mpeg4-generic GM sessions.

We require GM support, so that offerers that wish to maximize
interoperability may do so by offering GM as an option.  In the common
case of a mpeg4-generic session with a single sendonly and a single
recvonly RTP MIDI stream in an identity relationship, the offer would
list several payload types on each media line.  One of which would be
mapped to General MIDI.  The answer would indicate the preferred
payload, using the methods we discuss in the preamble to Appendix C.5.

Alternatively, parties may offer a single payload format that offers



Lazzaro/Wawrzynek                                             [Page 148]


INTERNET-DRAFT                                             25 April 2005


several renderers.  In this case, the fmtp string presents a list of
render parameters (each followed by its support parameters), following
the default "one" value semantics of the "multimode" parameter (Appendix
C.5.1).  As discussed in Appendix C.5.1, the order of 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 "null".  Thus, "unknown" MUST NOT appear
in the answer.

Parties MUST support the musicport, chanmask, 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 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 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 to conduct a performance that includes
MIDI and audio channels.  In the latter case, offers MUST coordinate the
sample rates and the packet temporal duration of the audio and MIDI
streams.  In most cases, this "coordination" will imply identical sample
rates and packet temporal durations.

We now show an example of an offer/answer exchange in a network musical
performance application.

Below, we show an offer that complies with the interoperability text in
this Appendix section.






Lazzaro/Wawrzynek                                             [Page 149]


INTERNET-DRAFT                                             25 April 2005


v=0
o=first 2520644554 2838152170 IN IP4 first.example.net
s=Example
t=0 0
c=IN IP4 192.0.2.94
m=audio 16112 RTP/AVP 96
a=recvonly
a=rtpmap:96 mpeg4-generic/44100
a=fmtp:96 streamtype=5; mode=rtp-midi; config=""; profile-level-id=12;
ch_unused=ABCDEFGHJKMNPQTVWXYZ; ch_default=2NPTW;
ch_default=2C0.1.7.10.11.64.121.123; ch_default=2M0.1.2
ch_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 97
a=sendonly
a=rtpmap:97 mpeg4-generic/44100
a=fmtp:97 streamtype=5; mode=rtp-midi; config=""; profile-level-id=12;
ch_unused=ABCDEFGHJKMNPQTVWXYZ; ch_default=1NPTW;
ch_default=1C0.1.7.10.11.64.121.123; ch_default=1M0.1.2
ch_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 owner line (o=) identifies the session owner as "first".

The session description defines two 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 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 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 renderer.  The chapter inclusion parameters code that the recvonly
stream uses MIDI channel 1 exclusively for voice commands, and that the
sendonly stream uses MIDI channel 2 exclusively for voice commands.
This mapping permits the application software to share a single renderer
for local and remote performers.





Lazzaro/Wawrzynek                                             [Page 150]


INTERNET-DRAFT                                             25 April 2005


We now show the answer to the offer.
v=0
o=second 2520644554 2838152170 IN IP4 second.example.net
s=Example
t=0 0
c=IN IP4 192.0.2.105
m=audio 5004 RTP/AVP 96
a=sendonly
a=rtpmap:96 mpeg4-generic/44100
a=fmtp:96 streamtype=5; mode=rtp-midi; config=""; profile-level-id=12;
ch_unused=ABCDEFGHJKMNPQTVWXYZ; ch_default=2NPTW;
ch_default=2C0.1.7.10.11.64.121.123; ch_default=2M0.1.2
ch_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 97
a=recvonly
a=rtpmap:97 mpeg4-generic/44100
a=fmtp:97 streamtype=5; mode=rtp-midi; config=""; profile-level-id=12;
ch_unused=ABCDEFGHJKMNPQTVWXYZ; ch_default=1NPTW;
ch_default=1C0.1.7.10.11.64.121.123; ch_default=1M0.1.2
ch_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 page to accommodate
 memo formatting restrictions; they comprise single lines in SDP)


The owner line (o=) identifies the session owner as "second".

The port numbers for both media streams are non-zero; thus, "second" has
accepted the session description.  The stream marked "sendonly" in the
offer is marked "recvonly" in the answer, and vice versa, coding the
different view of the session held by "session".  The IP4 number
(192.0.2.105) and the 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 the sendonly stream has been changed to code 2 ms (441 in clock
units), and 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.







Lazzaro/Wawrzynek                                             [Page 151]


INTERNET-DRAFT                                             25 April 2005


D.  Parameter Syntax Definitions

In this Appendix, we define the syntax for the RTP MIDI MIME parameters
in Augmented Backus-Naur Form (ABNF, [10]).  When using these MIME
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 include any mpeg4-generic MIME
parameters (usage described in Section 6.2).  An fmtp attribute line may
be defined (after [4]) 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 that white space MUST
NOT appear between the "a=fmtp:" and the RTP payload type.

We now define the syntax of the MIME parameters defined in Appendix C.
The definition takes the form of the incremental assembly of the <param-
assign> token.  See [4] for the syntax of the mpeg4-generic MIME
parameters discussed in Section 6.2.
;
;
; top-level definition for all parameters
;
;

;
; Parameters defined in Appendix C.1

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_unused"  "=" ([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



Lazzaro/Wawrzynek                                             [Page 152]


INTERNET-DRAFT                                             25 April 2005


param-assign /= "ch_active"  "=" ([channel-list] chapter-list [f-list])
                              ;
                              ;  sysex-data NOT an option for ch_active

;
; Parameters defined in Appendix C.2

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.3

param-assign /= "guardtime"    "="  nonzero-four-octet

param-assign /= "rtp_ptime"    "="  four-octet

param-assign /= "rtp_maxptime" "="  four-octet

;
; Parameters defined in Appendix C.4

param-assign /= "musicport"  "=" four-octet

;
; Parameters defined in Appendix C.5

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" / *ietf-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"



Lazzaro/Wawrzynek                                             [Page 153]


INTERNET-DRAFT                                             25 April 2005


                                  / *ietf-extension)

param-assign /= "smf_inline" "=" double-quote base-64-block double-quote

param-assign /= "smf_url"    "=" double-quote uri-element double-quote

param-assign /= "url"        "=" double-quote uri-element double-quote

;
; list definitions for 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 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



Lazzaro/Wawrzynek                                             [Page 154]


INTERNET-DRAFT                                             25 April 2005


                   ; value of right midi-field

midi-field         = four-octet
                   ;
                   ; large range accommodates Chapter M
                   ; RPN (0-16383) and 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

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 [8], page 23.
                   ; note that a-f are not permitted, only A-F.
                   ; hex-octet values MUST NOT exceed 7F.


;
; definitions for rinit MIME parameter
;

mime-type          = "audio" / "application"

mime-subtype       = token
                   ;
                   ; See Appendix C.5.2 for registration
                   ; requirements for rinit MIME subtypes.

;
; definitions for base64 encoding
; copied from [6]




Lazzaro/Wawrzynek                                             [Page 155]


INTERNET-DRAFT                                             25 April 2005


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 (Section 7).

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 [14] and [15]

double-quote       = %x22
                   ; the double-quote (") character

token              =  1*(token-char)
                   ; copied from [6]

token-char         =  %x21 / %x23-27 / %x2A-2B / %x2D-2E /
                      %x30-39 / %x41-5A / %x5E-7E
                   ; copied from [6]

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           /=  "]"



Lazzaro/Wawrzynek                                             [Page 156]


INTERNET-DRAFT                                             25 April 2005


cid-char           /=  "?"
cid-char           /=  "="
                   ;
                   ; add back in the tspecials [8], 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 [14] and [15]

;
; End of ABNF


The mpeg4-generic RTP payload [4] 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


























Lazzaro/Wawrzynek                                             [Page 157]


INTERNET-DRAFT                                             25 April 2005


E.  A MIDI Overview for Networking Specialists

This Appendix presents an overview of the MIDI standard, for the benefit
of networking specialists new to musical applications.  Implementors
should consult [1] for a normative description of 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 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 performance.

MIDI commands have much in common with the machine instructions of a
microprocessor.  MIDI commands are defined as binary elements.
Bitfields within a MIDI command have a regular structure and a
specialized purpose.  For example, the upper nibble of the first command
octet (the opcode field) codes the command type.  MIDI commands may
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







Lazzaro/Wawrzynek                                             [Page 158]


INTERNET-DRAFT                                             25 April 2005


  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  |      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







Lazzaro/Wawrzynek                                             [Page 159]


INTERNET-DRAFT                                             25 April 2005


Figure E.1 and E.2 show the MIDI command family.  There 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 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 of 16 MIDI channels, as coded by its 4-bit
channel field (field cccc in Figure E.1).  In most applications, notes
for different timbres are assigned to different channels.  To support
applications that require more than 16 channels, MIDI systems use
several MIDI command streams in parallel, to yield 32, 48, or 64 MIDI
channels.

As an example of a voice command, consider a NoteOn command (opcode
0x9), with binary encoding 1001cccc 0nnnnnnn 0aaaaaaa.  This command
signals the start of a musical note on MIDI channel cccc.  The note has
a pitch coded by the note number nnnnnnn, and an onset amplitude coded
by note velocity aaaaaaa.

Other voice commands signal the end of notes (NoteOff, opcode 0x8), map
a specific timbre to a MIDI channel (PChange, opcode 0xC), 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
the rendering algorithms the MIDI receiver uses to generate sound.  In
most applications, a MIDI sender has a model (in some sense) of the
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 commands
(the Song Position Pointer, Song Select, Clock, Start, Continue, and
Stop messages), SMPTE time code (the MIDI Time Code Quarter Frame
command), and the communication of device-specific data (the System
Exclusive messages).

E.2 Running Status

All MIDI command bitfields share a special structure: the leading bit of
the first octet is set to 1, and the leading bit of all subsequent
octets is set to 0.  This structure supports a data compression system,
called running status [1], that improves the coding efficiency of MIDI.

In running status coding, the first octet of a MIDI voice command may be
dropped if it is identical to the first octet of the previous MIDI voice
command.  This rule, in combination with a convention to consider NoteOn



Lazzaro/Wawrzynek                                             [Page 160]


INTERNET-DRAFT                                             25 April 2005


commands with a null third octet as NoteOff commands, supports the
coding of note sequences using two octets per command.

Running status coding is only used for voice commands.  The presence of
a system common message in 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 Figures E.1 and E.2 do not encode the execution
time for a command.  Timing information is not a part of the MIDI
command syntax itself; different applications of the MIDI command
language use different methods to encode timing.

For example, the MIDI command set acts as the transport layer for MIDI
1.0 DIN cables [1].  MIDI cables are short asynchronous serial lines
that facilitate the remote operation of musical instruments and audio
equipment.  Timestamps are not sent over a MIDI 1.0 DIN cable.  Instead,
the standard uses an implicit "time of arrival" code.  Receivers execute
MIDI commands at the moment of arrival.

In contrast, Standard MIDI Files (SMFs, [1]), a file format for
representing complete musical performances, add a explicit timestamp to
each MIDI command, using a delta encoding scheme that is optimized for
statistics of musical performance.  SMF timestamps usually code timing
using the metric notation of a musical score.  SMF meta-events are used
to add a tempo map to the file, so that score beats may be accurately
converted into units of seconds during rendering.

E.4 AudioSpecificConfig templates for MMA renderers

In Section 6.2 and Appendix C.5.5 in this memo, we describe how session
descriptions include an AudioSpecificConfig data block to specify a MIDI
rendering algorithm for mpeg4-generic RTP MIDI streams.

The bitfield format of AudioSpecificConfig is defined in [7].
StructuredAudioSpecificConfig, a key data structure coded in
AudioSpecificConfig, is defined in [5].

For implementors wishing to specify Structured Audio renderers, a full
understanding of [5] and [7] are essential.  However, many implementors
will limit their rendering options to the two MIDI Manufacturers
Association renderers that may be specified in AudioSpecificConfig:
General MIDI (GM, [1]) and Downloadable Sounds 2 (DLS 2, [9]).

To aid these implementors, we reproduce the AudioSpecificConfig bitfield
formats for a GM renderer and a DLS 2 renderer below.  As described in



Lazzaro/Wawrzynek                                             [Page 161]


INTERNET-DRAFT                                             25 April 2005


Section 6.2, a minimal mpeg4-generic session description encodes the
AudioSpecificConfig binary bitfield as a hexidecimal string (whose
format is defined in [4]) that is assigned to the "config" parameter.
As described in Appendix C.5.3, a session description that uses the
render parameter encodes the AudiospecificConfig binary bitfield as a
Base64-encoded string assigned to the "inline" parameter, or in the body
of an HTTP URL assigned to the "url" parameter.

Below, we show a simplified binary AudioSpecificConfig bitfield format,
suitable for sending and receiving GM 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 for use with 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 first 5 bits of an AudioSpecificConfig coded in a session
description, and reject sessions that specify unsupported renderers.

The 4-bit FREQIDX field specifies the sampling rate of the renderer.  We
show the mapping of FREQIDX values to sampling rates in Figure E.4.
Senders MUST specify a sampling frequency that matches the RTP clock
rate, if possible; if not, senders MUST specify the escape value.
Receivers MUST consult the RTP clock parameter for the true sampling
rate if the escape value is specified.











Lazzaro/Wawrzynek                                             [Page 162]


INTERNET-DRAFT                                             25 April 2005


                    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 for the
renderer.  The values 0x1-0x5 specify 1 to 5 audio channels; the value
0x6 specified 5+1 surround sound, and the value 0x7 specifies 7+1
surround sound.  If the rtpmap line in the session description specifies
one of these formats, CHANNEL MUST be set to the corresponding value.
Otherwise, CHANNEL MUST be set to 0x0.

The CHANNEL field is followed 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 [5]) specifies the type of each
data block.

For General MIDI, only Standard MIDI Files may appear in 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 these file types,
the FILE_BLK field has the format shown in Figure E.5: a 32-bit unsigned
integer value (FILE_LEN) coding the number of bytes in the SMF or RIFF
file, followed by FILE_LEN bytes coding the file data.











Lazzaro/Wawrzynek                                             [Page 163]


INTERNET-DRAFT                                             25 April 2005


    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 FILE_LEN bytes) ...      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

               Figure E.5 -- The FILE_BLK field format


Note that several files may follow CHANNEL field.  The "1" constant
fields in Figure E.3 code the presence of another file; the "0" constant
field codes the end of the list.  The final "0" bit in Figure E.3 codes
the absence of special coding tools (see [7] 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" in
this position.

The StructuredAudioSpecificConfig bitfield structure requires the
presence of one FILE_BLK.  For mpeg4-generic RTP MIDI use of DLS 2,
FILE_BLKs may MUST code RIFF files or SMF files.  For mpeg4-generic RTP
MIDI use of General MIDI, FILE_BLKs MUST code SMF files.  By default,
this SMF will be ignored (Appendix C.5.4.1).  In this default case, a 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 StructuredAudioSpecificConfig
that we use in the General MIDI session examples in this memo.
Referring to Figure E.3, we note that for GM, AOTYPE = 15.  Our examples
use a 44,100 Hz sample rate (FREQIDX = 4) and are in mono (CHANNEL = 1).
For GM, a single SMF is encoded (SACNK = 2), using the SMF shown in
Figure E.6 (a 26 byte file).


















Lazzaro/Wawrzynek                                             [Page 164]


INTERNET-DRAFT                                             25 April 2005


      --------------------------------------------
     |  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 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 GM examples


Expressing this bitfield as an ASCII hexidecimal string yields:




Lazzaro/Wawrzynek                                             [Page 165]


INTERNET-DRAFT                                             25 April 2005


   7A0A0000001A4D546864000000060000000100604D54726B0000000600FF2F000


This string is assigned to the "config" parameter in the minimal
mpeg4-generic General MIDI examples in this memo (such as the example in
Section 6.2).  Expressing this string in Base64 [8] yields:


   egoAAAAaTVRoZAAAAAYAAAABAGBNVHJrAAAABgD/LwAA


This string is assigned to the "inline" parameter in the General MIDI
example shown in Appendix C.5.5.


F.  Acknowledgements

We thank the networking, media compression, and computer music community
members who have commented or contributed to 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, and Giorgio Zoia.  We also thank the
members of the San Francisco Bay Area music and audio community for
creating the context 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.



















Lazzaro/Wawrzynek                                             [Page 166]


INTERNET-DRAFT                                             25 April 2005


G.  Security Considerations

Implementors should carefully read the Security Considerations sections
of the RTP [2], AVP [3], and other RTP profile documents, as the issues
discussed in these sections directly apply to RTP MIDI streams.
Implementors should also review the Secure Real-time Transport Protocol
(SRTP, [12]), an RTP profile that addresses the security issues
discussed in [2] [3].

In this Appendix, we discuss security issues that are unique to the RTP
MIDI payload format.

When using RTP MIDI, authentication of incoming RTP and RTCP packets is
RECOMMENDED.  Per-packet authentication may be provided by SRTP or by
other means.  Without the use of authentication, attackers could forge
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, and take effective control of a client machine.

Session management tools (such as SIP [19]) SHOULD use authentication
during the transport of all session descriptions containing RTP MIDI
media streams.  For SIP, the Security Considerations section in [19]
provides an overview of possible authentication mechanisms.  RTP MIDI
session descriptions should use authentication because the session
descriptions may code initialization data using the MIME 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.5.3) and smf_url (Appendix C.5.4.2)
parameters.  If the coded URL is spoofed, both session and client are
open to attack, even if the session description itself is authenticated.


















Lazzaro/Wawrzynek                                             [Page 167]


INTERNET-DRAFT                                             25 April 2005


H.  IANA Considerations

This Appendix makes a series of requests to IANA.  Thus, we begin with
an outline of our requests.  The sub-appendices that follow hold the
actual, detailed requests.  All registrations in this Appendix are in
the IETF tree.

In Appendix H.1, we request the registration of a new MIME 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 in Appendix H.1.1.

In Appendix H.2, we request the registration of a new value ("rtp-midi")
for the "mode" parameter of the "mpeg4-generic" MIME type, in Appendix
H.2.  The "mpeg4-generic" MIME type is defined in [4], and [4] defines a
repository for the "mode" parameter.  However, we believe we are the
first 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 use with the "rtp-midi" mode value.  We request this
repository in Appendix H.2.1.

In Appendix H.3, we request the registration of a new MIME type:
"audio/asc".  No repository request is associated with this request.


H.1 rtp-midi MIME Registration

This Appendix requests the registration of the "rtp-midi" MIME subtype
for the "audio" MIMI type.  We request the registration of the
parameters listed in the "optional parameters" section below (both the
"non-extensible parameters" and the "extensible parameters" lists).  We
also request the creation of repositories for the "extensible
parameters"; the details of this request appear in Appendix H.1.1 below.



MIME media type name:

    audio


MIME subtype name:

    rtp-midi




Lazzaro/Wawrzynek                                             [Page 168]


INTERNET-DRAFT                                             25 April 2005


Required parameters:

    rate: The RTP timestamp clock rate.  See Sections 2.1 and 6.1
    for usage details.


Optional parameters:

    Non-extensible parameters:

       ch_active:    See Appendix C.1.3 for usage details.
       ch_anchor:    See Appendix C.1.3 for usage details.
       ch_default:   See Appendix C.1.3 for usage details.
       ch_never:     See Appendix C.1.3 for usage details.
       ch_unused:    See Appendix C.1.3 for usage details.
       chanmask:     See Appendix C.5.4.3 for usage details.
       cid:          See Appendix C.5.3 for usage details.
       guardtime:    See Appendix C.3.2 for usage details.
       inline:       See Appendix C.5.3 for usage details.
       linerate:     See Appendix C.2 for usage details.
       mperiod:      See Appendix C.2 for usage details.
       multimode:    See Appendix C.5.1 for usage details.
       musicport:    See Appendix C.4.1 for usage details.
       octpos:       See Appendix C.2 for usage details.
       rtp_maxptime: See Appendix C.3.1 for usage details.
       rtp_ptime:    See Appendix C.3.1 for usage details.
       smf_cid:      See Appendix C.5.4.2 for usage details.
       smf_inline:   See Appendix C.5.4.2 for usage details.
       smf_url:      See Appendix C.5.4.2 for usage details.
       tsmode:       See Appendix C.2 for usage details.
       url:          See Appendix C.5.3 for usage details.

    Extensible parameters:

       j_sec:        See Appendix C.1.1 for usage details.  See
               Appendix H.1.1 for repository details.
       j_update:     See Appendix C.1.2 for usage details.  See
               Appendix H.1.1 for repository details.
       render:       See Appendix C.5 for usage details.  See
               Appendix H.1.1 for repository details.
       rinit:        See Appendix C.5.2 for usage details.  See
               Appendix H.1.1 for repository details.
       smf_info:     See Appendix C.5.4.1 for usage details.  See
               Appendix H.1.1 for repository details.


Encoding considerations:




Lazzaro/Wawrzynek                                             [Page 169]


INTERNET-DRAFT                                             25 April 2005


    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 of this memo.


Interoperability considerations:

    None.


Published specification:

    This memo and [1] serve as the normative specification.  In
    addition, references [17], [18], and [22] provide non-normative
    implementation guidance.


Applications which use this media type:

    Audio content-creation hardware, such as MIDI controller piano
    keyboards and MIDI audio synthesizers.  Audio content-creation
    software, such as music sequencers, digital audio workstations,
    and soft synthesizers.  Computer operating systems, for network
    support of 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.





Lazzaro/Wawrzynek                                             [Page 170]


INTERNET-DRAFT                                             25 April 2005


Author:

    John Lazzaro <lazzaro@cs.berkeley.edu>


Change Controller:

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

H.1.1 Repository request for "audio/rtp-midi"


For the "rtp-midi" subtype, we request the creation of repositories for
extensions to 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.1.1
      of this memo describes appropriate registrations for this
      repository.

      Initial values for this repository appear below:

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

   j_update:

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

      Initial values for this repository appear below:

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

   render:

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




Lazzaro/Wawrzynek                                             [Page 171]


INTERNET-DRAFT                                             25 April 2005


      Initial values for this repository appear below:

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

   rinit:

      This parameter MUST be assigned to a MIME type/subtype [8].
      Thus, only registered MIME subtypes are permitted to
      appear in this repository.  Appendix C.5.2 offers guidance
      to authors of MIME subtype registrations that are to be
      included in this repository.

      There are no initial values for this repository defined
      in this memo.

   smf_info:

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

      Initial values for this repository appear below:

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


H.2 mpeg4-generic MIME Registration

This Appendix requests the registration of the "rtp-midi" value for the
"mode" parameter of the "mpeg4-generic" MIME type.  The "mpeg4-generic"
MIME type is defined in [4], and [4] defines a repository for the "mode"
parameter.  We are registering mode rtp-midi to support the MPEG Audio
codecs [5] that use MIDI.

In conjunction with this registration request, we request the
registration of the parameters listed in the "optional parameters"
section below (both the "non-extensible parameters" and the "extensible
parameters" lists).  We also request the creation of repositories for
the "extensible parameters"; the details of this request appear in
Appendix H.2.1 below.





Lazzaro/Wawrzynek                                             [Page 172]


INTERNET-DRAFT                                             25 April 2005


MIME media type name:

    audio


MIME subtype name:

    mpeg4-generic


Required parameters:

    The "mode" parameter is required by [4].  [4] requests
    a repository for "mode", so that new values for mode
    may be added.  We request that the value "rtp-midi" be
    added to the "mode" repository.

    In mode rtp-midi, the mpeg4-generic parameter rate is
    a required parameter.  Rate specifies the 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 following parameters
    for use in mode rtp-midi for mpeg4-generic.

    Non-extensible parameters:

       ch_active:    See Appendix C.1.3 for usage details.
       ch_anchor:    See Appendix C.1.3 for usage details.
       ch_default:   See Appendix C.1.3 for usage details.
       ch_never:     See Appendix C.1.3 for usage details.
       ch_unused:    See Appendix C.1.3 for usage details.
       chanmask:     See Appendix C.5.4.3 for usage details.
       cid:          See Appendix C.5.3 for usage details.
       guardtime:    See Appendix C.3.2 for usage details.
       inline:       See Appendix C.5.3 for usage details.
       linerate:     See Appendix C.2 for usage details.
       mperiod:      See Appendix C.2 for usage details.
       multimode:    See Appendix C.5.1 for usage details.
       musicport:    See Appendix C.4.1 for usage details.
       octpos:       See Appendix C.2 for usage details.
       rinit:        See Appendix C.5.2 and C.5.5 for usage
                     details.  Note that we list "rinit" as
                     a non-extensible parameter, and we
                     DO NOT request a repository for rinit
                     in Appendix H.2.1.  In this way, rinit



Lazzaro/Wawrzynek                                             [Page 173]


INTERNET-DRAFT                                             25 April 2005


                     for mode rtp-midi in mpeg4-generic differs
                     from the rinit parameter defined for the
                     MIME type "audio/rtp-midi".  This difference
                     is intentional, as explained in Appendix C.5.5.
       rtp_maxptime: See Appendix C.3.1 for usage details.
       rtp_ptime:    See Appendix C.3.1 for usage details.
       smf_cid:      See Appendix C.5.4.2 for usage details.
       smf_inline:   See Appendix C.5.4.2 for usage details.
       smf_url:      See Appendix C.5.4.2 for usage details.
       tsmode:       See Appendix C.2 for usage details.
       url:          See Appendix C.5.3 for usage details.

    Extensible parameters:

       j_sec:        See Appendix C.1.1 for usage details.  See
               Appendix H.1.1 for repository details.
       j_update:     See Appendix C.1.2 for usage details.  See
               Appendix H.1.1 for repository details.
       render:       See Appendix C.5 for usage details.  See
               Appendix H.1.1 for repository details.
       smf_info:     See Appendix C.5.4.1 for usage details.  See
               Appendix H.1.1 for repository details.


Encoding considerations:

    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), the 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, audio/rtp-midi is for all other work.


Published specification:

    This memo, [1], and [5] are the normative references.  In
    addition, references [17], [18], and [22] provide non-normative
    implementation guidance.



Lazzaro/Wawrzynek                                             [Page 174]


INTERNET-DRAFT                                             25 April 2005


Applications which use this media type:

    MPEG 4 servers and terminals that support [5].


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 the mpeg4-generic subtype, we request the creation
of repositories for extensions 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.1.1
      of this memo describes appropriate registrations for this
      repository.

      Initial values for this repository appear below:

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



Lazzaro/Wawrzynek                                             [Page 175]


INTERNET-DRAFT                                             25 April 2005


   j_update:

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

      Initial values for this repository appear below:

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

   render:

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

      Initial values for this repository appear below:

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

   smf_info:

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

      Initial values for this repository appear below:

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


H.3 asc MIME Registration

This section registers "asc" as a MIME subtype for the "audio" type.  We
register this MIME subtype to support the remote transfer of the
"config" parameter of the mpeg4-generic MIME type [4] 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
in Section 6.2 of this document.



Lazzaro/Wawrzynek                                             [Page 176]


INTERNET-DRAFT                                             25 April 2005


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



MIME media type name:

    audio


MIME subtype name:

    asc


Required parameters:

    none


Optional parameters:

    none


Encoding considerations:

    This type is only defined for data object (stored file)
    transfer.  The native form of the data object is binary
    data, zero-padded to an octet boundary.  The most common
    transports for the type are HTTP and SMTP.


Security considerations:

    See Appendix G of this memo.


Interoperability considerations:

    None.


Published specification:

    The audio/asc data object is the AudioSpecificConfig



Lazzaro/Wawrzynek                                             [Page 177]


INTERNET-DRAFT                                             25 April 2005


    binary data structure, which is normatively defined in [7].


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.  References

I.1 Normative References

[1] MIDI Manufacturers Association.  "The Complete MIDI 1.0 Detailed
Specification", 1996.

[2] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson.
"RTP: A transport protocol for real-time applications", RFC 3550, July
2003.

[3] Schulzrinne, H., and S. Casner.  "RTP Profile for Audio and Video
Conferences with Minimal Control", RFC 3551, July 2003.



Lazzaro/Wawrzynek                                             [Page 178]


INTERNET-DRAFT                                             25 April 2005


[4] van der Meer, J., Mackie, D., Swaminathan, V., Singer, D., and
P. Gentric.  "RTP Payload Format for Transport of MPEG-4 Elementary
Streams", RFC 3640, November 2003.

[5] International Standards Organization.  "ISO/IEC 14496 MPEG-4",
Part 3 (Audio), Subpart 5 (Structured Audio), 2001.

[6] Handley, M., Jacobson, V., and C. Perkins.  "SDP: Session
Description Protocol", draft-ietf-mmusic-sdp-new-22.txt.

[7] International Standards Organization.  "ISO 14496 MPEG-4", Part 3
(Audio), 2001.

[8] Freed, N. and N. Borenstein.  "MIME Part One: Format of Internet
Message Bodies", RFC 2045, November 1996.

[9] MIDI Manufacturers Association.  "The MIDI Downloadable Sounds
Specification", v98.2, 1998.

[10] Crocker, D. and P. Overell.  "Augmented BNF for Syntax
Specifications: ABNF.", RFC 2234, November 1997.

[11] Bradner, S.  "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.

[12] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman.
"The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.

[13] Rosenberg, J. and H. Schulzrinne.  "An Offer/Answer Model with
SDP", RFC 3264, June 2002.

[14] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource
Identifiers (URI): Generic Syntax", RFC 2396, August 1998.

[15] Hinden, R., Carpenter, B. and L. Masinter, "Format for Literal
IPv6 Addresses in URL's", RFC 2732, December 1999.

[16] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol, HTTP/1.1",
RFC 2616, June 1999.


I.2 Informative References

[17] 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.



Lazzaro/Wawrzynek                                             [Page 179]


INTERNET-DRAFT                                             25 April 2005


[18] 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.

[19] Rosenberg, J, Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler.  "SIP: Session
Initiation Protocol", RFC 3261, June 2002.

[20] Schulzrinne, H., Rao, A., and R. Lanphier. "Real Time Streaming
Protocol (RTSP)", RFC 2326, April 1998.

[21] 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.

[22] Lazzaro, J., and J. Wawrzynek.  "An Implementation Guide for RTP
MIDI", draft-ietf-avt-rtp-midi-guidelines-08.txt.

[23] Braden, R. et al. "Resource ReSerVation Protocol (RSVP) --
Version 1 Functional Specification", RFC 2205, September 1997.

[24] Freed, N., Klensin, J., and J. Postel.  "MIME Part Four:
Registration Procedures", RFC 2048, November 1996.

[25] Lazzaro, J. "Framing RTP and RTCP Packets over
Connection-Oriented Transport",
draft-ietf-avt-rtp-framing-contrans-05.txt.

[26] E. Rescorla. "HTTP over TLS", RFC 2818, May 2000.

[27] MIDI Manufacturers Association.  "Scalable Polyphony MIDI,
Specification and Device Profiles", Document Version 1.0a, 2002.


















Lazzaro/Wawrzynek                                             [Page 180]


INTERNET-DRAFT                                             25 April 2005


J.  Authors' Addresses

John Lazzaro (corresponding author)
UC Berkeley
CS Division
315 Soda Hall
Berkeley CA 94720-1776
Email: lazzaro@cs.berkeley.edu

John Wawrzynek
UC Berkeley
CS Division
631 Soda Hall
Berkeley CA 94720-1776
Email: johnw@cs.berkeley.edu


K.  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 (2004).  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.




Lazzaro/Wawrzynek                                             [Page 181]


INTERNET-DRAFT                                             25 April 2005


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.

Acknowledgement

Funding for the RFC Editor function is currently provided by the
Internet Society.






































Lazzaro/Wawrzynek                                             [Page 182]


INTERNET-DRAFT                                             25 April 2005


M.  Change Log for <draft-ietf-avt-rtp-midi-format-08.txt>

[Note to RFC Editors: this Appendix, and its Table of Contents listing,
should be removed from the final version of the memo]

Document changes reflect WG last call responses, as well as issues that
arose during implementation efforts, and MIDI compatibility issues that
arose after a new review "recommended-practice" documents from the MMA.

We begin with the 42 issues that Magnus raised during WG Last Call.  But
first, a note about the "RTP MIDI Issue: #3 and #36" AVT postings.

This thread raised a set of basic issues about SSRC, PT, and MIDI name
space, and discussed a set of alternatives.  Below is the set of
solutions this I-D implements:

-A- All RTP streams from all parties in a multimedia session that use a
payload type mapped to the audio/rtp-midi media type are in one RTP
session, and thus share the same SSRC space.  Likewise, all RTP streams
from all parties in a session that use a payload type mapped to
audio/mpeg4-generic mode rtp-midi are in one (independent, i.e.
different from the audio/rtp-midi) RTP session, and thus share the same
SSRC space (Issue 3).

-B- A unique SSRC is used for all of the RTP streams that are based on a
common synchronization clock and that are sent by one party.  Both "one
party, one sync source (and thus one SSRC)" and "one party, several sync
sources (and thus, several SSRCs)" may be expected in real-world MIDI
use. (Issue 3).

-C- As distinct sets of parameters and values will generally be used to
characterize the role each RTP MIDI stream plays in a session, in
practice the payload type (PT) becomes the multiplexing point -- it is
needed as the label for the fmtp string that defines each stream's
properties.  A 7-bit PT space will not limit MIDI applications. (Issue
3).

-D- Transport and SSRC are independent.  One requirement for RTP MIDI is
to split a single MIDI name space over two transports (because MIDI can
carry bulk data that would not work over UDP, but the same MIDI source
can also send interactive data that works poorly over TCP).  When
splitting one MIDI name space over two transports, we have: one MIDI
namespace, two streams, one SSRC, two PTs, each stream sent on a
separate transport.  As a second example, consider two MIDI In jacks of
MIDI sent by a party, who samples the jacks with a common
synchronization clock.  In this case, we have: two MIDI name spaces, one
SSRC, two PTs, both potentially sent to a shared transport address/port
pair.  (Issue 3).



Lazzaro/Wawrzynek                                             [Page 183]


INTERNET-DRAFT                                             25 April 2005


-E- MIDI name space labels are independent of: SSRC, PT, transport.  The
musicport parameter lets two streams be labelled as sharing a single
MIDI namespace ("identity relationships"), as sharing consecutively
numbered MIDI namespaces ("ordered relationships"), or as independent
from any relationship.  In addition, the MIDI semantics of the data
flowing in different directions on a particular stream are also defined
(directionality is defined in a way suitable for both unicast and
multicast Internet transport).  (Issue 36).

-F- Rendering and relationships are linked.  Streams in a relationship
share one render parameter, and thus one renderer (or set of renderers).
A stream independent from a relationship defines its own render
parameter. (Issue 36).

-G- "MIDI multicast" not an IETF concern.  MIDI defines System Exclusive
commands for transactions to work in a multicast environment (in MIDI
1.0 DIN, this is done by daisy-chaining through MIDI Thru's, or by using
a hub of some sort).  As MIDI DIN networks are true "party lines", MIDI
expects no help from the transport in identifying hosts on the network
-- the SysEx commands have DeviceIDs, and one command supports
discovery.  Apart from establishing all-to-all connectivity with
appropriate musicport parameters, nothing else needs to be done by RTP
MIDI.

-H- Many renderers for one namespace possible.  A set of parameters in
Appendix C.5 supports defining many renderers for a single MIDI name
space. Many render parameters may be defined for a stream, each may use
the "chanmask" parameter to mask out all but a subset of MIDI channels,
a "multimode" parameter defines whether a single receiver should be
attempting to "find itself" in the render list, or whether it should be
attempting to do all renders itself, etc.

---

The next 42 issues correspond to the issues Magnus raised during WG Last
Call (actually 43, as Mangus reused 17 twice -- so, there are Issues 17
and 17a below).


[Issue 1]

Section 1, third paragraph. I haven't seen anything in this payload
format that makes it RTP profile specific. Therefore I would like to
have removed or changed all occurances where it specifies that it is to
be used under AVP. If you like to maintain the profile reference then
make it as an example. I would suggest the following change in this
sentence:




Lazzaro/Wawrzynek                                             [Page 184]


INTERNET-DRAFT                                             25 April 2005


Was: After a call is set up, audio data would flow between the parties
using the Real Time Protocol (RTP, [2]) under the Audio/Visual Profile
(AVP, [3]).

Change to: After a call is set up, audio data would flow between the
parties using the Real Time Protocol (RTP, [2]) under any applicable
profile, e.g. the Audio/Visual Profile (AVP, [3]).

In addition I think one can change basically all references to "RTP/AVP"
to "RTP".


[Response 1]

Done.

---

[Issue 2]

Section 1, last paragraph page 5: "To provide a foundation for RTP MIDI
applications, this memo extends two of the IETF tools (RTP and SDP) to
support MIDI. Sections 2-5 and Appendices A-B extend RTP/AVP by adding a
MIDI payload format. Section 6 and Appendices C-D extend SDP by adding
session configuration tools to customize the stream behavior (including
the MIDI rendering method) during session setup."

As an RTP payload format extends neither the basic RTP functionality or
SDP, I am against using the word "extends" in this context. I would
instead propose that you change this paragraph to:

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


[Response 2]

Done (I made small wording changes to your suggested text).

---

[Issue 3]

Section 2.1: I am missing a explanation how to consider the SSRC in this
payload format. If I understand correctly, the intention is to utilize



Lazzaro/Wawrzynek                                             [Page 185]


INTERNET-DRAFT                                             25 April 2005


multiple SSRCs for each block of 16 midi channels to transmit. I think
it is important to discuss this here.


[Response 3]

In Section 2.1, we handle the header-oriented part of the open issues
around this topic -- defining the RTP session, defining the role of SSRC
and PT for RTP sessions that have a party sending more than one RTP
stream, and clarifying the relation between MIDI bidirectionality and
the identification of parties via network, transport, and RTP header
info.

Search for the paragraph in Section 2.1 that begins with "All RTP
streams from all parties" to see the details -- read through the
paragraph that starts with "On a final note".  Also see Issue 37, and
the separate discussion above the issue list about your AVT emails, to
see the rest of the picture on this topic.

---

[Issue 4]

Section 2.1: Timestamp resolution. There is no discussion on the
timestamp resolution issues that exist. Especially when it comes to high
performance application.


[Response 4]

Fixed in Section 2.1.  Start with paragraph that begins with "The 32-bit
timestamp field sets", and read until the end of the paragraph that
begins with "For RTP MIDI streams destined".

---

[Issue 5]

Section 2.2, 5th paragraph on page 9:

"A sender MUST NOT knowingly create RTP MIDI UDP packets whose size
exceeds the MTU of the underlying network."

I think the MUST should be changed to SHOULD, due to the problems of
ensuring that it is actually followed. Also at least in IPv4 avoiding
fragmentation is mostly an performance issues, rather than something
breaks.




Lazzaro/Wawrzynek                                             [Page 186]


INTERNET-DRAFT                                             25 April 2005


[Response 5]

Done.

---

[Issue 6]

Same paragraph as 5:

"If these steps are not successful at limiting packet size to fit within
an MTU, the session MUST be terminated."

I am not comfortable requiring that the session is terminated. What is
the motivation behind this drastic measure? Also what are the thresholds
for considering one unsuccessful?

[Response 6]

I removed the quoted sentence.

---

[Issue 7]

Section 3: third paragraph on page 11: "A MIDI list MAY consist a single
delta time (Delta Time 0) without an associated command (MIDI Command
0).  In this case, the MIDI list codes the interval of time over which
no commands appear in the stream."

I am not certain I understand this paragraph. So is the interval of time
in which no commands are present: From TS to TS+Delta_Time_0? I think
you need to explain this better. Also the "(Delta Time 0)" is a bit
confusing. I misunderstood this at first to refer to a delta time value
of 0 rather than the first value present in the list. Also some
explanation what the benefit would be good.


[Response 7]

I changed the end of the Section 3 preamble to read:

  The final MIDI command field (i.e. the MIDI Command N 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.2.  We delay the explanations because an



Lazzaro/Wawrzynek                                             [Page 187]


INTERNET-DRAFT                                             25 April 2005


  understanding of RTP MIDI timestamps is necessary to describe the
  features.

And moved the explanation to Section 3.1.  Start reading at the line
"All command timestamps in a packet MUST be" and continue reading
through the paragraph that begins "In addition, it is ".

---

[Issue 8]

Section 3.1: First paragraph on page 12:

"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, 0x800000, 0x80000000)."

I think this example is in error, shouldn't they be 0x808000 and
0x80808000?


[Response 8]

Error is now fixed.

---

[Issue 9]

Section 3.2: "Although the first channel command in the MIDI list MUST
include a status octet, 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."

Must the packetization generate the status octet or is it allowed to
excluded it if you have the P bit set to 1?

[Response 9]

I rewrote the quoted paragraph to clarify this issue -- in Section 3.2,
read the paragraph that begins "As we note above", and the paragraph
that follows it.

---




Lazzaro/Wawrzynek                                             [Page 188]


INTERNET-DRAFT                                             25 April 2005


[Issue 10]

Section 3.2, page 15, the cancellation mechanism. I think there are a
problem here.

"If a sender determines that the command whose transmission is in
progress should not appear on the RTP stream, it cancels the command."
Which I interprets as you don't need to transmit more than up to the
cancellation of the SYSEX.

Then you have the following text: "A cancelled transmission SHOULD be
ignored by the receiver, if possible. However, if a receiver has
forwarded earlier command segments to a MIDI destination that is not
able to ignore commands, the receiver SHOULD forward the data octets
coded in the "cancel" sublist, and end the forwarded SysEx command with
an 0xF7."

If you can ignore the cancel message, does not the complete message need
to be transmitted then? Or is this something I am missing in the MIDI
part here?

[Response 10]

Yes, there's no rational reason to send any data octets in the cancel
command. I changed the cancel list definition -- in Section 3.2, read
the paragraph that begins "A sender MAY cancel", up until the end of the
paragraph that begins "Unfortunately, the MIDI DIN cable".


---

[Issue 11]

Section 5, page 22: The ordering of the bit list. Shouldn't the
definition of the bits be equal to the order they appear in the packet?
That would be easier to read.

[Response 11]

I believe this issue is in error -- the ordering of the definitions in
the memo appear to match the ordering in the bit list.


---

[Issue 12]

Section 5, the definition of R and LENGTH. I think that these as they



Lazzaro/Wawrzynek                                             [Page 189]


INTERNET-DRAFT                                             25 April 2005


are commonly used should be defined in the 1.1 Terminology section.

[Response 12]

Added a new 1.2 Bitfield Conventions section.

---

[Issue 13]

Section 5, is the CHAN field also in MIDI encoded as channel 0 to 15 so
that they are directly mapped?

[Response 13]

Yes.  See new paragraph that begins "Figure 9 shows the structure" for
clarifying text.

---

[Issue 14]

Section 6.1, bullet 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."


What is the definition of "stream" in this sentence?


[Response 14]

The redefinition of SSRC and PT in Section 2.2 has caused the definition
of a minimal stream to change in this respect, for both Sections 6.1 and
6.2.  See new point 5 for Section 6.1.

---

[Issue 15]

Section 6.1: "By default, an RTP session, and thus a minimal RTP MIDI
session, is bidirectional ("sendrecv", as defined in [6]).  Each
participant acts as sender and receiver, as in traditional telephony."

The above sentence is only true in the SIP context. Other application
context may not necessarily share this default value.



Lazzaro/Wawrzynek                                             [Page 190]


INTERNET-DRAFT                                             25 April 2005


[Response 15]

In Section 6.1, see new paragraph that begins "As in standard RTP".  In
Section 6.2, see new paragraph that begins with "The Section 6.1
comments".


---

[Issue 16]

IANA section: I think it can be made more clear that this draft is
registering a new mode for mpeg-generic. This repository is defined but
not created by IANA, which will need to happen now.


[Response 16]

Rewrote the preamble to Appendix H, to make what we are requesting very
clear (I hope).


---

[Issue 17]

IANA Consideration. I think it would be much better if the rules for
registering values to the the extensible parameters are put into a
subsection of the IANA consideration section. Also the initial statement
on the action for IANA must be made clearer. It should list all the
repositories that shall be created, and their initial values.

I would like to see something like:

IANA is kindly request to perform the following actions:

Register one MIME type "audio/rtp-midi" which defines 5 repositories for
extensions:
    j_sec: Registrations in this repository is done according to section
           18.1.1.
           Initial values in the repository are:
           xyz : RFC XXXX, section x.y.z


    j_update:  ....


--- End of example ---- That way the actions to actually create the



Lazzaro/Wawrzynek                                             [Page 191]


INTERNET-DRAFT                                             25 April 2005


repositories will not be missed by IANA. Also any one registering things
in the future can't miss the rules and how to do it.


[Response 17]

Two new subsections, H.1.1 and H.2.1, are the formal repository requests
for "audio/rtp-midi" and for mode rtp-midi of mpeg4-generic.

---

[Issue 17a]

Section 6.2, the AudioSpecifiConfig, how big can this become part
become?

[Response 17a]

DLS or Structured Audio AudioSpecificConfigs can be quite large -- many
MB.  This was the motivation behind asking for config="" semantics in
the mpeg4-generic RFC, and is why the "url" parameter exists (C.5.3).
GM are trivial in size.

---

[Issue 18]

Section 6.2, "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."

I don't understand this sentence. What is here meant with "stream" and
how is the mapping between the different instances accomplished?

[Response 18]

The redefinition of SSRC and PT in Section 2.2 has caused the definition
of a minimal stream to change in this respect, for both Sections 6.1 and
6.2.  See new point 5 for Section 6.1-2.

---

[Issue 19]

Section A.1, definition of N-active and C-active. Isn't there a way to
define these command in a inclusive way, instead of exclusive way. I am
especially concerned with future extensions and if they automatically
should be included or excluded in these sets. However I don't at all



Lazzaro/Wawrzynek                                             [Page 192]


INTERNET-DRAFT                                             25 April 2005


understand what the intention with these definitions are, and what is
the main properties of these. But that may be my lack of knowledge about
MIDI.

[Response 19]

The MIDI stream can code commands that "reset" some parts of the dynamic
state associated with a MIDI renderer.

A few commands of this type are a standard part of all MIDI uses.  Reset
All Controllers (MIDI Control Change number 121) resets all MIDI
controllers (set by MIDI Control commands number 0-119).  MIDI Control
Change commands with All Notes Off semantics (123-127) or All Sound Off
semantics (120) releases all active notes (All Notes Off and All Sound
Off specify different semantics for how the release occurs).

The recovery journal semantics need to specify special treatment for
reset controllers and released notes, to ensure that the recovery
journal is not encoding "stale" information about recovery.  The most
compact way to specify this special treatment is to define two terms
that denote that a controller is reset ("C-active") or that a note has
been release ("N-active") by one of these special commands.

Historically, each MMA-created rendering specification has defined other
commands that also reset state in some way.  See the "Reset State"
bullet for a list of these commands.  If the recovery journal didn't
acknowledge the semantics of these commands as it does the Reset All
Controllers, All Notes Off, and All Sound Off commands, the journal
would be at risk of coding "stale" recovery information.

If we wish for it to be possible for RTP MIDI to support new renderers
in the future, we need the ability to add in new Reset State commands
for these renderers as they are created by the MMA and other standards
bodies.  Thus, the "MIME registrations for renderers and IETF standards-
track documents MAY specify additional RS commands" caveat in the Reset
State command bullet in Appendix A.1.

As far as inclusive vs exclusive goes, being "active" is indeed an
exclusive thing -- commands that have not been reset are active.  I
experimented with different wordings, and the result was a longer
definition that harder to comprehend.  Once one changes "before" to
"after" in the definitions:

  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 in the session



Lazzaro/Wawrzynek                                             [Page 193]


INTERNET-DRAFT                                             25 April 2005


    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 are MIDI commands that do
    not appear before one of the following commands in the session
    history:  MIDI Control Change number 121 (Reset All Controllers)
    and any Reset State command.

a few sentences of legalistic text are needed to cover all of the
special cases (what if there are no reset commands to appear after?
what if there are multiple reset commands?).  That's the only real way
to write it inclusively, and it seemed to be bad to go that direction.

---

[Issue 20]

Appendix C: Section title, I would like to remove "SDP" from it. The
basic configuration is expressed as a series of parameter and values.
These can for example be mapped to SDP, however in general we like to
separate the basic requirement for configuration and therefore express
it as Media Types parameters, and then map these to SDP. That way the
work will be simpler when one take the step to another format for
configuration.

[Response 20]

All uses of "SDP" in section titles, and as an adjective for parameters,
have been removed from the document.

---

[Issue 21]

Section C.1.1: 5th paragraph page 82: "Special j_sec issues arise when
sessions are managed by the Real Time Streaming Protocol (RTSP, [20]).
In many streaming applications, the session description in the response
to the DESCRIBE method does not code the transport details (such as UDP
or TCP) for the session.  Instead, server and client negotiate transport
details using the SETUP method."

Similar behavior exist in other applications using declarative media
configuration. This include MBONE application using SAP or pre-
distributed SDP files. So I would recommend that you refer to the two
cases as "Declarative usage" and "Negotiated usage". Where declarative
usage can be exemplified with RTSP and SAP, while "Negotiated usage" is
exemplified with Offer/Answer in SIP.



Lazzaro/Wawrzynek                                             [Page 194]


INTERNET-DRAFT                                             25 April 2005


[Response 21]

Done.  See preamble of Section 6 ("Some session managers ...")  and
Section C.1.1 for a rewrite of the "Special j_sec issues" paragraphs
quoted above.


---

[Issue 22]

Section C.1.2.2, page 85: "To address this issue, the closed-loop policy
states that if a receiver participates in a session where it may have
access to a stream before the sender is aware of the receiver, the
receiver MUST take actions to ensure that its rendered MIDI performance
does not contain indefinite artifacts.  The receiver MUST NOT
discontinue these protective actions until it is certain that the sender
is aware of its presence."

How will a receiver be able to determine that the sender is aware of its
presence? In any case where some other entity (multicast, conference
focus, RTP translator/mixer) then the sender is distributing the traffic
to multiple receivers, the receiver can't really determine if the sender
has received its feedback.

[Response 22]

Fixed.  In Appendix C.1.2.2, see the paragraph that begins "To address
this issue, the closed-loop policy states" for preparation, and then
read the paragraphs that begin "In a unicast RTP session, a receiver
may" to see the change.


---

[Issue 23]

Section C.1.2.2, page 85-86: "At some point, the sender may need to take
action in order to limit the bandwidth of the stream.  The closed-loop
policy states that if this situation occurs, and if the nature of the
session permits a sender to stop transmitting packets to the offending
receiver, the sender MUST stop transmitting packets to this receiver.
In other words, it is not permissible for a sender to no longer use M(k)
in computing the checkpoint packet identity but still send the stream to
receiver k, if it is possible for the sender to actively cut off
receiver k from the stream."

As the default method for feedback is RTCP, I think one should discuss



Lazzaro/Wawrzynek                                             [Page 195]


INTERNET-DRAFT                                             25 April 2005


the action when one times out an SSRC. To my understanding a timed out
SSRC, does not need to be provided tailored recovery journals for.

[Response 23]

Fixed.  For preparation, in Section C.1.2.2, read the paragraph that
begins "The final set of normative closed-loop policy", and then read
the 2 paragraphs that begin "At some point, the sender may need".


---

[Issue 24]

Section C.1.2.2, page 83: "The closed-loop policy relies on feedback
from receiver 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 the 32-bit extension format defined
in [2].  In sessions that use RTCP, receivers transmit this information
in the Extended Highest Sequence Number Received (EHSNR) field of
Receiver Report (RR) packets.  However, applications MAY use any method
of feedback to implement the closed-loop policy."

I think there is a need for a more strict requirement on RTCP in this
case. Although transport events may result in the loss of RTCP feedback
from a specific receiver, the receiver should really send feedback. Thus
I think that the following formulation should be added.  "RTCP Sender or
Receiver Reports SHALL be sent by any participant in a session with
closed loop sending policy, unless other feedback mechanism has been
agreed upon."


[Response 24]

Fixed.  See the rewritten paragraph the begins "The closed-loop policy
relies on feedback from receiver to sender".

---

[Issue 25]

Section C.1.2.2, page 86: "If the receiver detects this condition, it
MUST leave the session, and close down the rendered MIDI performance in
a manner that is free of indefinite artifacts."

I do understand the need to stop the rendered MIDI performance, however
I don't see why he must leave the session. The only way of getting back
is hanging in there and try get his feedback through. Thus enabling him



Lazzaro/Wawrzynek                                             [Page 196]


INTERNET-DRAFT                                             25 April 2005


to get the necessary recovery information.

[Response 25]

Fixed.  See the 4 rewritten paragraphs that begin with "We now discuss
receiver responsibilities in the case of unplanned disruptions".


---

[Issue 26]

Section C.1.3, page 90: It is not explained how the special semantics is
inserted into the channel list. Is there any restrictions on combination
of special channel lists and the chapters?

[Response 26]

See new paragraph that begins with "Several of the systems chapters may
be configured to have special".


---

[Issue 27]

Section C.1.3, page 93: "To guard against indefinite artifacts, the MIDI
Program Change command and several MIDI Control Change controller
numbers are assigned to ch_anchor.  Note that the ordering of the
ch_anchor chapter C assignment after the ch_unused command acts to
override the ch_unused assignment for the listed controller numbers (7
and 64)."

I don't quite understand how "ch_anchor=C7.64;" can override something
that is not included in the "ch_unused" list?


[Response 27]

Fixed the typo in the fmtp list that led to problem, see text.  Also,
see the new paragraph that begins with "To determine the semantics of a
list of chapter inclusion parameter". near the top of C.1.3.

---

[Issue 28]

Section C.2.1: "If comex is used to transcode MIDI time-of-arrival



Lazzaro/Wawrzynek                                             [Page 197]


INTERNET-DRAFT                                             25 April 2005


sources (such as MIDI 1.0 DIN cables [1]), the performance rendered from
the MIDI stream may exhibit temporal jitter relative to the original
source, as comex semantics differ from MIDI time-of-arrival source
semantics."

Is this temporal jitter a result of the imprecision of the RTP timestamp
to correctly encode the execution time, or is it depending on something
else? If it is depending on the conversion of the time scale, I think a
note that the size of the jitter is dependent on the RTP timestamp rate
should be added.


[Response 28]

Fixed.  See paragraphs that begin with "Comex is a poor choice for
transcoding" in C.2.1.


---

[Issue 29]

Section C.2.2: "If the octpos parameter does not appear in the media
description, a timestamp MAY reflect the time value of any octet of the
command."

Is this no definition resulting in uncertainty a good thing. Why not
default it to either value? Same applies to octpos in section C.2.3.

[Response 29]

Fixed.  See paragraph that begins with "The "octpos" ancillary MIME
parameter" and the two paragraphs that begin with "If octpos has the
token value".

---

[Issue 30]

Section C.3.1: "The RTP/AVP profile [3] permits audio packet media times
to range from 0 to 200 ms."

The implications of the usage of "permits" is a bit to strong. RFC 3551
says in section 4.2 (Operating Recommendations): A receiver SHOULD
accept packets representing between 0 and 200 ms of audio data.

This a recommendation not a fixed rule, and for formats for which it
makes sense, even more media time may be used. So I would change this



Lazzaro/Wawrzynek                                             [Page 198]


INTERNET-DRAFT                                             25 April 2005


sentence from "permits" to "recommend".

[Response 30]

Fixed (permits -> recommend), in C.3.1 and in Section 6.1.

---

[Issue 31]

Section C.4.2: The zerosync non-zero behavior does not work. For it to
be useful it will need to encode all SSRCs TS offset compared to the
reference SSRC.

[Response 31]

I've deleted the zerosync parameter from RTP MIDI, part of the
reorganization described in Issue 3.

---

[Issue 32]

Section C.4.2: the zero-behavior. I do not like it, as it further the
view that this behavior as completely acceptable. I am not certain that
it is sufficiently studied the effects of this usage. I do not have time
to think of what potential issues this usage may produce beyond
weakening security.

[Response 32]

See Response for 31.

---

[Issue 33]

Section 5.2: The "fasym" and "rasym" values indicate that the stream
uses the client- server semantics of MIDI 1.0 DIN network cable pairs.
The "fasym" value indicates the forward flow from server to client; the
"rasym value codes the reverse flow from client to server.  In a session
that uses client- server semantics, the host that receives the "fasym"
flow runs an instance of the renderer, but the host that receives the
"rasym" flow does not.

I think the second sentence is a bit unclear, as the parameter is
defined for the stream one receives if I interpret the first paragraph
on the page. Also the parameters relation to the SDP directional



Lazzaro/Wawrzynek                                             [Page 199]


INTERNET-DRAFT                                             25 April 2005


attribute is unclear.

Also I am concerned with the definition implying that they also has
capability declaring effects. What I have learned is that it is unwise
to connect stream properties with capabilities. It is better to separate
them so that one actually can express both at the same time and with
different values. There are clearly benefits to being able to express
that I will receive the rasym, but is also capable of symmetric and the
reverse.


[Response 33]

Dirsense has been removed from the protocol.  It became apparent during
the rewrite of the interoperability section that the chapter inclusion
parameters are a sufficient mechanism for an RTP MIDI stream to describe
its capabilities -- a MIDI stream's capabilities are the subset of
commands it is prepared to send or receive, no more and no less.

---

[Issue 34]

Section 5.3: Why is opaque render types allowed at all? Isn't it simpler
to require the usage of a MIME type?


[Response 34]

It is no longer allowed (see "Authors of rendering systems" paragraph in
Appendix C.5.2).

---

[Issue 35]

Section 5.4: For the "url" type, is any specific download protocols
required to be implemented? If not interoperability seems to be at stake
in many case, preventing usage of this method.

[Response 35]

The url parameter now requires HTTP.  See paragraphs that begin with
"The "url" parameter is assigned a double-quoted string representation",
and paragraphs that begin with "The "cid" parameter supports data".

---




Lazzaro/Wawrzynek                                             [Page 200]


INTERNET-DRAFT                                             25 April 2005


[Issue 36]

Section C.5: If I understand the implications of these parameters is
that for a specific source to be able to use more than 16 channels with
different renders, it must assign one payload type for each block of 16
channels. Is this acceptable? I am considering the SDP size, and also
complexity of configuring the MIDI renderers for each PT.

[Response 36]

See Issue 3's response for background, as well as the discussion of the
AVT thread that precede the issue list.  The payload type is indeed the
mechanism used to link the rendering-related parameters to an RTP MIDI
stream.

In the general case, one can indeed define a single renderer for each PT
-- simply use the musicport parameter to isolate each PT from being in a
relationship.

However, note that for streams whose musicport parameter (Appendix
C.4.1) indicates an ordered relationship (one stream is channels 0-15, a
second stream is channels 16-31) or a same-direction identity
relationship (several streams all share the same channels 0-15, all
sending in the same "direction", a word defined to make sense for both
unicast and multicast), one rendering system is defined for the
relationship, which will encompass several PTs.  This is one purpose of
relationships -- to bind several streams to a single renderer.

Also note that if one wishes to specify 16 renderers, one for each MIDI
channel of a single MIDI name space, one does not need to use 16 payload
type numbers - C.5.1 specifically permits the definition of several
renderers for one payload type, the "multimode" parameter described how
receivers should interpret multiple renderers, and the "chanmask"
parameter lets each renderer mask out all channels except the ones that
are of interest.

With regards to SDP size, the purpose of the url and smf_url parameters
is to let large files be sent via HTTP reference.  So, the largest
single parameter values (by far) have been designed with SDP size in
mind.

---

[Issue 37]

Section C.6: In general I think their should be more MUSTs in this
section. All the tools necessary to get decent performance in a number
of situations should be made mandatory to support. The problem with



Lazzaro/Wawrzynek                                             [Page 201]


INTERNET-DRAFT                                             25 April 2005


SHOULD in a interoperability specification is that it prevents the
clients from being sure that the parameter will be understood. Thus even
more code will go to handle these cases and work arounds.

[Response 37]

Section C.6 has been rewritten from scratch, to focus on exactly how the
tools work for three popular "situations": WAN content-streaming using
RTSP, stage and studio LAN applicances using RTSP, and WAN network
musical performance using SIP.  This level of specificity was necessary
to make MUSTs with confidence.

Basically, RTP MIDI is best viewed as a foundation payload, that really
needs a framework document in order to be used at all -- MIDI is an
extremely general protocol, and is used in many unusual ways in the real
world.  The three "situations" described in C.6 act as self-contained
framework documents for simple use scenareos.

---

[Issue 38]

Comment around guard time. If one uses RTCP, a receiver will continue to
get RTCP reports from the SSRC that prior sent packets. Thus as long as
this happens it is possible to determine that this sender is still
present, but not actively sending for the moment.


[Response 38]

There are several reasons why guardtime functionality is needed, and
that RTCP feedback is not enough.  These are described in Section 4.2 in
the guidelines document, whose introduction is quoted below:

   During a session, musicians might refrain from generating MIDI data
   for extended periods of time (seconds or even minutes).  If an RTP
   stream followed the dynamics of a silent MIDI source, and stopped
   sending RTP packets, system behavior might be degraded in the
   following ways:

    o  The receiver's model of network performance may fall out
       of date.

    o  Network middleboxes (such as Network Address Translators)
       may "time-out" the silent stream and drop the port and IP
       association state.

    o  If the session does not use RTCP, receivers may misinterpret



Lazzaro/Wawrzynek                                             [Page 202]


INTERNET-DRAFT                                             25 April 2005


       the silent stream as a dropped network connection.

  Senders avoid these problems by sending "keep-alive" RTP packets
  during periods of network inactivity.  Keep-alive packets have empty
  MIDI lists.

  [...]

  Senders may also send empty packets to improve the performance of the
  recovery journal system.  As we describe in Section 6, the recovery
  process begins when a receiver detects a break in the RTP sequence
  number pattern of the stream.  The receiver uses the recovery journal
  of the break packet to guide corrective rendering actions, such as
  ending stuck notes and updating out-of-date controller values.

  Consider the situation where the local player produces a MIDI NoteOff
  command (which the sender promptly transmits in a packet), but then 5
  seconds pass before the player produces another MIDI command (which
  the sender transmits in a second packet).  If the packet coding the
  NoteOff is lost, the receiver is not be aware of the packet loss
  incident for 5 seconds, and the rendered MIDI performance contains a
  note that sounds for 5 seconds too long.

This part of the guidelines document then proceeds to give guidelines
for algorithms concerning the sending of empty RTP packets for these
purposes.

Note that in the format document, one of the reasons cited in the
guidelines document quoted above is mentioned in the definition text of
guardtime (C.3.2):

  Certain MIDI applications benefit from a slight enhancement to this
  RTP feature.  In interactive applications, receivers may use on-line
  network models to guide heuristics for handling lost and late RTP
  packets.  These models may work poorly if a sender ceases packet
  transmission for long periods of time.

Incidently, sfront works this way. See Appendix B of reference [17] for
sfront's algorithm, which would suffer if many seconds routinely went by
without new RTP packets.

---

[Issue 39]

ABNF check of syntax in section D: I used
http://www.apps.ietf.org/abnf.html to produce this results.




Lazzaro/Wawrzynek                                             [Page 203]


INTERNET-DRAFT                                             25 April 2005


undefined rule: hex-octet undefined rule: type undefined rule: uri
undefined rule: msg-id undefined rule: subtype undefined rule: token
undefined rule: base64 ABNF validation (version 1.0) completed

Of these, at least "msg-id" is lacking a complete ABNF definition that
is easily implementable. Can't you define this in a more explicit way?
Especially considering that you define +1 operations on it.

[Response 39]

In the revised ABNF, hex-octet, type, subtype, token, and base64 rules
have a complete ABNF definition.  msg-id is replaced with cid-char,
which is a compplete ABNF definition.  The uri definition now references
the ABNF of the primary RFCs, bypassing the SDP I-D indirect references.
The ABNF validation passes correctly, and shows uri as the only
undefined rule.

---

[Issue 40]

Section D. Comment on "rinit" def.  I think the rinit MIME type needs to
have room for parameters that a MIME type may have.

[Response 40]

Added to Appendix C.5.2, see paragraph that begins with "MIME
registrations for renderers MAY define parameters".


---

[Issue 41]

Section H. "rate" parameter for audio/rtp-midi Please change the
definition from being dependent on the rtpmap line.


[Response 41]

Done, see H.1-2.

---

[Issue 42]

Section H. The Author / Change Controller: This section should be split
into two headings. Put yourself under "Author" and Change Controller



Lazzaro/Wawrzynek                                             [Page 204]


INTERNET-DRAFT                                             25 April 2005


should be written as follows: "IETF Audio/Video Transport Working Group
delegated from the IESG"


[Response 42]

Done, see H.1-3.

---

[Issue 43]

The audio/asc type, that is nothing that MPEG has defined is it?  This
format, both its definition and name is done in this draft?

[Response 43]

Added to Appendix H.3 is a brief explanation of this issue:

  This section registers "asc" as a MIME subtype for the "audio" type.
  We register this MIME subtype to support the remote transfer of the
  "config" parameter of the mpeg4-generic MIME type [4] 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
  in Section 6.2 of this document.

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

Below is the complete story.

If you look at the SDP examples in the mpeg4-generic RFC (RFC 3640), the
inline config parameter for audio modes is set to the
AudioSpecificConfig defined in ISO 14496 MPEG-4, Part 3.  For example,
see the CELP-vbr example on page 24.

RFC 3640 did not need to define a MIME types for these configs, because
each mode definition in 3640 defines what MPEG structure is encoded in
the config parameter, and this config is only assigned inline, because
it is so short.  However, for Structured Audio, the config may literally
be MBs (DLS wavetables, for example).

So, at my request, the config string may be passed by other means for
Structured Audio, as described in Page 29 of RFC 3640:

   For MPEG-4 Audio streams, config is the audio object type specific



Lazzaro/Wawrzynek                                             [Page 205]


INTERNET-DRAFT                                             25 April 2005


   decoder configuration data AudioSpecificConfig(), as defined in
   ISO/IEC 14496-3.  For Structured Audio, the
   AudioSpecificConfig() may be conveyed by other means, not
   defined by this specification.  If the AudioSpecificConfig() is
   conveyed by other means for Structured Audio, then the config
   MUST be a quoted empty hexadecimal octet string, as follows:
   config="".

   Note that a future mode of using this RTP payload format for
   Structured Audio may define such other means.

In the format document, I am defining this "other means".  As this other
means includes the "url" means, which may specify (for example) an HTTP
URL which would want to have a MIME type in its header describing the
format of the payload, I needed to define a MIME type for
AudioSpecificConfig data for MPEG audio.  I also needed it because I
chose to use the MIME type registry as my registry for "rinit".

To my knowledge, a MIME type for AudioSpecificConfig has not been
defined previously as part of the MPEG MIME TYPEs, and thus the MIME
type, "it is nothing that MPEG has defined", to use your wording.
However, the bitfield encoded by the MIME type has indeed been defined
by MPEG in ISO/IEC 14496, as described above.

(end of Magnus opus)

---

The next set of issues arose from implementation experience.  These are
labeled with letters.

[A] The normative text for computing the A-BUTTON and C-BUTTON fields
(Appendix A.4.2.1) has been slightly changed.  The -07.txt read:

   To compute and code the count value, initialize the count value to
   0, add 1 for each qualifying Data Increment command, subtract 1 for
   each qualifying Data Decrement command, and limit the magnitude
   of the final count to 16383.

The revised text in -08.txt:

  To compute and code the count value, initialize the count value to 0,
  add 1 for each qualifying Data Increment command, and subtract 1 for
  each qualifying Data Decrement command.  After each add or subtract,
  limit the count magnitude to 16383.

[B] In Section 3, the big-endian coding of the 12-bit LEN field is
clarified, using this revised text:



Lazzaro/Wawrzynek                                             [Page 206]


INTERNET-DRAFT                                             25 April 2005


   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.

Thanks to Tobias Erichsen for this change.

[C] In Section 6.1, we emphasize that the RTP timestamp field cannot be
interpreted correctly without knowledge of the clock rate set in the
rtpmap line of the session description:

   The rtpmap attribute line uses the rtp-midi MIME type to specify a
   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 [2]).  Note that this
document
   does not specify a default clock rate value for RTP MIDI.  Parties
   MUST use the rtpmap line of session descriptions to communicate the
   clock rate.

Thanks to Tobias Erichsen for this change.

[D] A new Appendix E.4 that derives the "config" and "inline" strings
used in the session description examples for General MIDI in the memo.
I wrote this after finding bugs in the existing strings, strings that I
had spent many hours researching to get (supposedly) "right" earlier.
If I couldn't navigate MPEG documents accurately enough to do these
simple examples on the first try, the average reader wouldn't get it
right -- thus, I added this Appendix to document the popular uses of
mpeg4-generic RTP MIDI (GM and DLS 2).

[E] Updates to the "Parameter System Transaction" definition in Appendix
A.1, and to Appendix A.3.4, to clarify how to determine when MIDI
Control Change parameters 6, 38, 96, and 97 are being used in a
"general-purpose" way.  Thanks to Nicolas Falquet (GRAME).

[F] In the preamble to Appendix C, clarification of how implementations
should handle requests for parameter changes to an ongoing session:

  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 that are not easily changed
  once a session has begun.  Thus, parties SHOULD NOT expect that
  parameter change requests during a session will be accepted by other
  parties.  However, implementors SHOULD support in-session parameter
  changes that are easy to handle (example: the guardtime parameter
  defined in Appendix C.3), and SHOULD be capable of accepting



Lazzaro/Wawrzynek                                             [Page 207]


INTERNET-DRAFT                                             25 April 2005


  requests for changes of those parameters, as received by its
  session management protocol (for example, re-offers in SIP [13]).

And also, in the preamble to Appendix C.1:

  The journalling method for a stream is set at the start 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 the acceptance of parameter values that would violate the
  recovery journal mandate.  In many cases, a change in one of the
  parameters defined in this Appendix during an on-going session would
  result in a violation of the recovery journal mandate for an
  implementation; in this case, the parameter change MUST NOT be
  accepted.

Thanks to Nicolas Falquet (GRAME).

































Lazzaro/Wawrzynek                                             [Page 208]