< draft-ietf-avt-rtp-midi-format-14.txt   draft-ietf-avt-rtp-midi-format-15.txt >
INTERNET-DRAFT J. Lazzaro INTERNET-DRAFT J. Lazzaro
December 5, 2005 J. Wawrzynek January 23, 2006 J. Wawrzynek
Expires: June 5, 2006 UC Berkeley Expires: July 23, 2006 UC Berkeley
RTP Payload Format for MIDI RTP Payload Format for MIDI
<draft-ietf-avt-rtp-midi-format-14.txt> <draft-ietf-avt-rtp-midi-format-15.txt>
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware have 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 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. will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that other
skipping to change at page 1, line 33 skipping to change at page 1, line 33
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.txt. http://www.ietf.org/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on June 5, 2006. This Internet-Draft will expire on July 23, 2006.
Abstract Abstract
This memo describes an RTP payload format for the MIDI command This memo describes an RTP payload format for the MIDI command
language. The format encodes all commands that may legally appear language. The format encodes all commands that may legally appear
on a MIDI 1.0 DIN cable. The format is suitable for interactive on a MIDI 1.0 DIN cable. The format is suitable for interactive
applications (such as network musical performance) and applications (such as network musical performance) and
content-delivery applications (such as file streaming). The format content-delivery applications (such as file streaming). The format
may be used over unicast and multicast UDP as well as TCP, and may be used over unicast and multicast UDP as well as TCP, and
defines tools for graceful recovery from packet loss. Stream defines tools for graceful recovery from packet loss. Stream
skipping to change at page 2, line 26 skipping to change at page 2, line 26
mpeg4-generic format, to support the MPEG 4 Audio Object Types for mpeg4-generic format, to support the MPEG 4 Audio Object Types for
General MIDI, Downloadable Sounds Level 2, and Structured Audio. General MIDI, Downloadable Sounds Level 2, and Structured Audio.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 6 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2 Bitfield Conventions . . . . . . . . . . . . . . . . . . . 6 1.2 Bitfield Conventions . . . . . . . . . . . . . . . . . . . 6
2. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1 RTP Header . . . . . . . . . . . . . . . . . . . . . . . . 7 2.1 RTP Header . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2 MIDI Payload . . . . . . . . . . . . . . . . . . . . . . . 11 2.2 MIDI Payload . . . . . . . . . . . . . . . . . . . . . . . 12
3. MIDI Command Section . . . . . . . . . . . . . . . . . . . . . . 13 3. MIDI Command Section . . . . . . . . . . . . . . . . . . . . . . 14
3.1 Timestamps . . . . . . . . . . . . . . . . . . . . . . . . 14 3.1 Timestamps . . . . . . . . . . . . . . . . . . . . . . . . 15
3.2 Command Coding . . . . . . . . . . . . . . . . . . . . . . 16 3.2 Command Coding . . . . . . . . . . . . . . . . . . . . . . 17
4. The Recovery Journal System . . . . . . . . . . . . . . . . . . . 23 4. The Recovery Journal System . . . . . . . . . . . . . . . . . . . 24
5. Recovery Journal Format . . . . . . . . . . . . . . . . . . . . . 25 5. Recovery Journal Format . . . . . . . . . . . . . . . . . . . . . 26
6. Session Description Protocol . . . . . . . . . . . . . . . . . . 29 6. Session Description Protocol . . . . . . . . . . . . . . . . . . 30
6.1 Session Descriptions for Native Streams . . . . . . . . . . 30 6.1 Session Descriptions for Native Streams . . . . . . . . . . 31
6.2 Session Descriptions for mpeg4-generic Streams . . . . . . 32 6.2 Session Descriptions for mpeg4-generic Streams . . . . . . 33
6.3 Parameters . . . . . . . . . . . . . . . . . . . . . . . . 34 6.3 Parameters . . . . . . . . . . . . . . . . . . . . . . . . 35
7. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . . . 36 7. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . . . 37
8. Congestion Control . . . . . . . . . . . . . . . . . . . . . . . 37 8. Congestion Control . . . . . . . . . . . . . . . . . . . . . . . 38
A. The Recovery Journal Channel Chapters . . . . . . . . . . . . . . 38 A. The Recovery Journal Channel Chapters . . . . . . . . . . . . . . 39
A.1 Recovery Journal Definitions . . . . . . . . . . . . . . . 38 A.1 Recovery Journal Definitions . . . . . . . . . . . . . . . 39
A.2 Chapter P: MIDI Program Change . . . . . . . . . . . . . . 43 A.2 Chapter P: MIDI Program Change . . . . . . . . . . . . . . 44
A.3 Chapter C: MIDI Control Change . . . . . . . . . . . . . . 44 A.3 Chapter C: MIDI Control Change . . . . . . . . . . . . . . 45
A.3.1 Log Inclusion Rules . . . . . . . . . . . . . . . . 44 A.3.1 Log Inclusion Rules . . . . . . . . . . . . . . . . 45
A.3.2 Controller Log Format . . . . . . . . . . . . . . . 46 A.3.2 Controller Log Format . . . . . . . . . . . . . . . 47
A.3.3 Log List Coding Rules . . . . . . . . . . . . . . . 48 A.3.3 Log List Coding Rules . . . . . . . . . . . . . . . 49
A.3.4 The Parameter System . . . . . . . . . . . . . . . . 51 A.3.4 The Parameter System . . . . . . . . . . . . . . . . 52
A.4 Chapter M: MIDI Parameter System . . . . . . . . . . . . . 53 A.4 Chapter M: MIDI Parameter System . . . . . . . . . . . . . 54
A.4.1 Log Inclusion Rules . . . . . . . . . . . . . . . . 54 A.4.1 Log Inclusion Rules . . . . . . . . . . . . . . . . 55
A.4.2 Log Coding Rules . . . . . . . . . . . . . . . . . . 56 A.4.2 Log Coding Rules . . . . . . . . . . . . . . . . . . 57
A.4.2.1 The Value Tool . . . . . . . . . . . . . . . 57 A.4.2.1 The Value Tool . . . . . . . . . . . . . . . 58
A.4.2.2 The Count Tool . . . . . . . . . . . . . . . 61 A.4.2.2 The Count Tool . . . . . . . . . . . . . . . 62
A.5 Chapter W: MIDI Pitch Wheel . . . . . . . . . . . . . . . . 62 A.5 Chapter W: MIDI Pitch Wheel . . . . . . . . . . . . . . . . 63
A.6 Chapter N: MIDI NoteOff and NoteOn . . . . . . . . . . . . 63 A.6 Chapter N: MIDI NoteOff and NoteOn . . . . . . . . . . . . 64
A.6.1 Header Structure . . . . . . . . . . . . . . . . . . 64 A.6.1 Header Structure . . . . . . . . . . . . . . . . . . 65
A.6.2 Note Structures . . . . . . . . . . . . . . . . . . 65 A.6.2 Note Structures . . . . . . . . . . . . . . . . . . 66
A.7 Chapter E: MIDI Note Command Extras . . . . . . . . . . . . 67 A.7 Chapter E: MIDI Note Command Extras . . . . . . . . . . . . 68
A.7.1 Note Log Format . . . . . . . . . . . . . . . . . . 68 A.7.1 Note Log Format . . . . . . . . . . . . . . . . . . 69
A.7.2 Log Inclusion Rules . . . . . . . . . . . . . . . . 68 A.7.2 Log Inclusion Rules . . . . . . . . . . . . . . . . 69
A.8 Chapter T: MIDI Channel Aftertouch . . . . . . . . . . . . 69 A.8 Chapter T: MIDI Channel Aftertouch . . . . . . . . . . . . 70
A.9 Chapter A: MIDI Poly Aftertouch . . . . . . . . . . . . . . 70 A.9 Chapter A: MIDI Poly Aftertouch . . . . . . . . . . . . . . 71
B. The Recovery Journal System Chapters . . . . . . . . . . . . . . 72 B. The Recovery Journal System Chapters . . . . . . . . . . . . . . 73
B.1 System Chapter D: Simple System Commands . . . . . . . . . 72 B.1 System Chapter D: Simple System Commands . . . . . . . . . 73
B.1.1 Undefined System Commands . . . . . . . . . . . 73 B.1.1 Undefined System Commands . . . . . . . . . . . 74
B.2 System Chapter V: Active Sense Command . . . . . . . . . . 76 B.2 System Chapter V: Active Sense Command . . . . . . . . . . 77
B.3 System Chapter Q: Sequencer State Commands . . . . . . . . 77 B.3 System Chapter Q: Sequencer State Commands . . . . . . . . 78
B.3.1 Non-compliant Sequencers . . . . . . . . . . . 79 B.3.1 Non-compliant Sequencers . . . . . . . . . . . 80
B.4 System Chapter F: MIDI Time Code . . . . . . . . . . . . . 80 B.4 System Chapter F: MIDI Time Code . . . . . . . . . . . . . 81
B.4.1 Partial Frames . . . . . . . . . . . . . . . . . . 82 B.4.1 Partial Frames . . . . . . . . . . . . . . . . . . 83
B.5 System Chapter X: System Exclusive . . . . . . . . . . . . 84 B.5 System Chapter X: System Exclusive . . . . . . . . . . . . 85
B.5.1 Chapter Format . . . . . . . . . . . . . . . . 84 B.5.1 Chapter Format . . . . . . . . . . . . . . . . 85
B.5.2 Log Inclusion Semantics . . . . . . . . . . . . 87 B.5.2 Log Inclusion Semantics . . . . . . . . . . . . 88
B.5.3 TCOUNT and COUNT fields . . . . . . . . . . . . 89 B.5.3 TCOUNT and COUNT fields . . . . . . . . . . . . 90
C. Session Configuration Tools . . . . . . . . . . . . . . . . . . . 91 C. Session Configuration Tools . . . . . . . . . . . . . . . . . . . 92
C.1 Stream Subsetting . . . . . . . . . . . . . . . . . . . . . 92 C.1 Stream Subsetting . . . . . . . . . . . . . . . . . . . . . 93
C.2 The Journalling System . . . . . . . . . . . . . . . . . . 96 C.2 The Journalling System . . . . . . . . . . . . . . . . . . 97
C.2.1 The j_sec Parameter . . . . . . . . . . . . . . . . 97 C.2.1 The j_sec Parameter . . . . . . . . . . . . . . . . 98
C.2.2 The j_update Parameter . . . . . . . . . . . . . . . 98 C.2.2 The j_update Parameter . . . . . . . . . . . . . . . 99
C.2.2.1 The anchor Sending Policy . . . . . . . . . . 99 C.2.2.1 The anchor Sending Policy . . . . . . . . . . 100
C.2.2.2 The closed-loop Sending Policy . . . . . . . 99 C.2.2.2 The closed-loop Sending Policy . . . . . . . 100
C.2.2.3 The open-loop Sending Policy . . . . . . . . 103 C.2.2.3 The open-loop Sending Policy . . . . . . . . 104
C.2.3 Chapter Inclusion Parameters . . . . . . . . . . . . 105 C.2.3 Chapter Inclusion Parameters . . . . . . . . . . . . 106
C.3 Timestamp Semantics . . . . . . . . . . . . . . . . . . . . 110 C.3 Timestamp Semantics . . . . . . . . . . . . . . . . . . . . 111
C.3.1 The comex Algorithm . . . . . . . . . . . . . . . . 110 C.3.1 The comex Algorithm . . . . . . . . . . . . . . . . 111
C.3.2 The async Algorithm . . . . . . . . . . . . . . . . 111 C.3.2 The async Algorithm . . . . . . . . . . . . . . . . 112
C.3.3 The buffer Algorithm . . . . . . . . . . . . . . . . 112 C.3.3 The buffer Algorithm . . . . . . . . . . . . . . . . 113
C.4 Packet Timing Tools . . . . . . . . . . . . . . . . . . . . 114 C.4 Packet Timing Tools . . . . . . . . . . . . . . . . . . . . 115
C.4.1 Packet Duration Tools . . . . . . . . . . . . . . . 114 C.4.1 Packet Duration Tools . . . . . . . . . . . . . . . 115
C.4.2 The guardtime Parameter . . . . . . . . . . . . . . 115 C.4.2 The guardtime Parameter . . . . . . . . . . . . . . 116
C.5 Stream Description . . . . . . . . . . . . . . . . . . . . 117 C.5 Stream Description . . . . . . . . . . . . . . . . . . . . 118
C.6 MIDI Rendering . . . . . . . . . . . . . . . . . . . . . . 123 C.6 MIDI Rendering . . . . . . . . . . . . . . . . . . . . . . 124
C.6.1 The multimode Parameter . . . . . . . . . . . . . . 124 C.6.1 The multimode Parameter . . . . . . . . . . . . . . 125
C.6.2 Renderer Specification . . . . . . . . . . . . . . . 124 C.6.2 Renderer Specification . . . . . . . . . . . . . . . 125
C.6.3 Renderer Initialization . . . . . . . . . . . . . . 127 C.6.3 Renderer Initialization . . . . . . . . . . . . . . 128
C.6.4 MIDI Channel Mapping . . . . . . . . . . . . . . . . 128 C.6.4 MIDI Channel Mapping . . . . . . . . . . . . . . . . 129
C.6.4.1 smf_info . . . . . . . . . . . . . . . . . . 129 C.6.4.1 smf_info . . . . . . . . . . . . . . . . . . 130
C.6.4.2 smf_inline, smf_url, smf_cid . . . . . . . . 131 C.6.4.2 smf_inline, smf_url, smf_cid . . . . . . . . 132
C.6.4.3 chanmask . . . . . . . . . . . . . . . . . . 132 C.6.4.3 chanmask . . . . . . . . . . . . . . . . . . 133
C.6.5 The audio/asc Media Type . . . . . . . . . . . . . . 133 C.6.5 The audio/asc Media Type . . . . . . . . . . . . . . 134
C.7 Interoperability . . . . . . . . . . . . . . . . . . . . . 135 C.7 Interoperability . . . . . . . . . . . . . . . . . . . . . 136
C.7.1 Content streaming . . . . . . . . . . . . . . . . . 135 C.7.1 Content streaming . . . . . . . . . . . . . . . . . 136
C.7.2 Network musical performance . . . . . . . . . . . . 138 C.7.2 Network musical performance . . . . . . . . . . . . 139
D. Parameter Syntax Definitions . . . . . . . . . . . . . . . . . . 147 D. Parameter Syntax Definitions . . . . . . . . . . . . . . . . . . 148
E. A MIDI Overview for Networking Specialists . . . . . . . . . . . 153 E. A MIDI Overview for Networking Specialists . . . . . . . . . . . 154
E.1 Commands Types . . . . . . . . . . . . . . . . . . . . . . 155 E.1 Commands Types . . . . . . . . . . . . . . . . . . . . . . 156
E.2 Running Status . . . . . . . . . . . . . . . . . . . . . . 155 E.2 Running Status . . . . . . . . . . . . . . . . . . . . . . 156
E.3 Command Timing . . . . . . . . . . . . . . . . . . . . . . 156 E.3 Command Timing . . . . . . . . . . . . . . . . . . . . . . 157
E.4 AudioSpecificConfig templates for MMA renderers . . . . . . 156 E.4 AudioSpecificConfig templates for MMA renderers . . . . . . 157
F. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 161 F. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 162
G. Security Considerations . . . . . . . . . . . . . . . . . . . . . 162 G. Security Considerations . . . . . . . . . . . . . . . . . . . . . 163
H. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . . 163 H. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . . 164
H.1 rtp-midi Media Type Registration . . . . . . . . . . . . . 163 H.1 rtp-midi Media Type Registration . . . . . . . . . . . . . 164
H.1.1 Repository request . . . . . . . . . . . . . . . . . 166 H.1.1 Repository request . . . . . . . . . . . . . . . . . 167
H.2 mpeg4-generic Media Type Registration . . . . . . . . . . . 167 H.2 mpeg4-generic Media Type Registration . . . . . . . . . . . 168
H.2.1 Repository request . . . . . . . . . . . . . . . . . 170 H.2.1 Repository request . . . . . . . . . . . . . . . . . 171
H.3 asc Media Type Registration . . . . . . . . . . . . . . . . 172 H.3 asc Media Type Registration . . . . . . . . . . . . . . . . 173
I. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 174 I. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
I.1 Normative References . . . . . . . . . . . . . . . . . . . 174 I.1 Normative References . . . . . . . . . . . . . . . . . . . 175
I.2 Informative References . . . . . . . . . . . . . . . . . . 175 I.2 Informative References . . . . . . . . . . . . . . . . . . 176
J. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 177 J. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 178
K. Intellectual Property Rights Statement . . . . . . . . . . . . . 177 K. Intellectual Property Rights Statement . . . . . . . . . . . . . 178
L. Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 177 L. Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 178
N. Change Log for <draft-ietf-avt-rtp-midi-format-14.txt> . . . . . 179 N. Change Log for <draft-ietf-avt-rtp-midi-format-15.txt> . . . . . 180
1. Introduction 1. Introduction
The Internet Engineering Task Force (IETF) has developed a set of The Internet Engineering Task Force (IETF) has developed a set of
focused tools for multimedia networking ([RFC3550] [SDP] [RFC3261] focused tools for multimedia networking ([RFC3550] [SDP] [RFC3261]
[RFC2326]). These tools can be combined in different ways to support a [RFC2326]). These tools can be combined in different ways to support a
variety of real-time applications over Internet Protocol (IP) networks. variety of real-time applications over Internet Protocol (IP) networks.
For example, a telephony application might use the Session Initiation For example, a telephony application might use the Session Initiation
Protocol (SIP, [RFC3261]) to set up a phone call. Call setup would Protocol (SIP, [RFC3261]) to set up a phone call. Call setup would
include negotiations to agree on a common audio codec [RFC3264]. include negotiations to agree on a common audio codec [RFC3264].
skipping to change at page 9, line 48 skipping to change at page 9, line 48
restrictions on the RTP timestamps for two sequential RTP packets, as restrictions on the RTP timestamps for two sequential RTP packets, as
does the guardtime parameter (Appendix C.4.2). does the guardtime parameter (Appendix C.4.2).
We use the term "media time" to denote the temporal duration of the 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 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 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 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 MIDI command section of a packet is empty, the media time coded by the
packet is 0 ms. Appendix C.4.1 discusses media time issues in detail. packet is 0 ms. Appendix C.4.1 discusses media time issues in detail.
A session description [SDP] media line ("m=") specifies an RTP session. We now define RTP session semantics, in the context of sessions
An RTP session has an independent space of 2^32 synchronization sources. specified using the session description protocol [SDP]. A session
Source identifiers are coded in the SSRC header field of RTP session description media line ("m=") specifies an RTP session. An RTP session
packets. The payload types that may appear in the PT header field of has an independent space of 2^32 synchronization sources.
RTP session packets are listed at the end of the media line. Synchronization source identifiers are coded in the SSRC header field of
RTP session packets. The payload types that may appear in the PT header
field of RTP session packets are listed at the end of the media line.
Several RTP MIDI streams may appear in an RTP session. Each stream is Several RTP MIDI streams may appear in an RTP session. Each stream is
distinguished by a unique SSRC value, and has a unique sequence number distinguished by a unique SSRC value, and has a unique sequence number
and RTP timestamp space. Multiple streams in the RTP session may be and RTP timestamp space. Multiple streams in the RTP session may be
sent by a single party. Multiple parties may send streams in the RTP sent by a single party. Multiple parties may send streams in the RTP
session. An RTP MIDI stream encodes data for a single MIDI command name session. An RTP MIDI stream encodes data for a single MIDI command name
space (16 voice channels + Systems). space (16 voice channels + Systems).
Streams in an RTP session may use different payload types, or may use Streams in an RTP session may use different payload types, or may use
the same payload type. However, each party may send, at most, one RTP the same payload type. However, each party may send, at most, one RTP
MIDI stream for each payload type mapped to an RTP MIDI payload format MIDI stream for each payload type mapped to an RTP MIDI payload format
in an RTP session. Pairs of streams (unicast or multicast) that in an RTP session. Recall that dynamic binding of payload type numbers
in [SDP] lets a party map many payload type numbers to the RTP MIDI
payload format, and thus a party may send many RTP MIDI streams in a
single RTP session. Pairs of streams (unicast or multicast) that
communicate between two parties in an RTP session and that share a communicate between two parties in an RTP session and that share a
payload type have the same association as a MIDI cable pair that cross- payload type have the same association as a MIDI cable pair that cross-
connects two devices in a MIDI 1.0 DIN network. connects two devices in a MIDI 1.0 DIN network.
The RTP session architecture described above is efficient in its use of The RTP session architecture described above is efficient in its use of
network ports, as one RTP session (using a port pair per party) supports network ports, as one RTP session (using a port pair per party) supports
the transport of many MIDI name spaces (16 MIDI channels + systems). We the transport of many MIDI name spaces (16 MIDI channels + systems). We
define tools for grouping and labelling MIDI name spaces across streams define tools for grouping and labelling MIDI name spaces across streams
and sessions in Appendix C.5 of this memo. and sessions in Appendix C.5 of this memo.
The RTP header timestamps for each stream in an RTP session have The RTP header timestamps for each stream in an RTP session have
separately and randomly chosen initialization values. Receivers use the separately and randomly chosen initialization values. Receivers use the
timing fields encoded in RTCP sender reports to synchronize the streams timing fields encoded in the RTP control protocol (RTCP, [RFC3550])
sent by a party. The SSRC values for each stream in an RTP session are sender reports to synchronize the streams sent by a party. The SSRC
also separately and randomly chosen. Receivers use the CNAME field values for each stream in an RTP session are also separately and
encoded in RTCP sender reports to verify that streams were sent by the randomly chosen, as described in [RFC3550]. Receivers use the CNAME
same party. field encoded in RTCP sender reports to verify that streams were sent by
the same party, and to detect SSRC collisions, as described in
[RFC3550].
In some applications, a receiver renders MIDI commands into audio (or 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 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 of stage lights). In other applications, a receiver presents a MIDI
stream to software programs via an Application Programmer Interface stream to software programs via an Application Programmer Interface
(API). Appendix C.6 defines session configuration tools to specify what (API). Appendix C.6 defines session configuration tools to specify what
receivers should do with a MIDI command stream. receivers should do with a MIDI command stream.
If a multimedia session uses different RTP MIDI streams to send If a multimedia session uses different RTP MIDI streams to send
different classes of media, the streams MUST be sent over different RTP different classes of media, the streams MUST be sent over different RTP
skipping to change at page 12, line 38 skipping to change at page 12, line 49
If a stream is sent over UDP transport, the Maximum Transmission Unit If a stream is sent over UDP transport, the Maximum Transmission Unit
(MTU) of the underlying network limits the practical size of the payload (MTU) of the underlying network limits the practical size of the payload
section (for example, an Ethernet MTU is 1500 octets), for applications section (for example, an Ethernet MTU is 1500 octets), for applications
where predictable and minimal packet transmission latency is critical. where predictable and minimal packet transmission latency is critical.
A sender SHOULD NOT create RTP MIDI UDP packets whose size exceeds the 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 MTU of the underlying network. Instead, the sender SHOULD take steps to
keep the maximum packet size under the MTU limit. keep the maximum packet size under the MTU limit.
These steps may take many forms. The default closed-loop recovery These steps may take many forms. The default closed-loop recovery
journal sending policy (defined in Appendix C.2.2.2) uses Real Time journal sending policy (defined in Appendix C.2.2.2) uses RTP control
Control Protocol (RTCP, [RFC3550]) feedback to manage the RTP MIDI protocol (RTCP, [RFC3550]) feedback to manage the RTP MIDI packet size.
packet size. In addition, Section 3.2 and Appendix B.5.2 provide In addition, Section 3.2 and Appendix B.5.2 provide specific tools for
specific tools for managing the size of packets that code MIDI System managing the size of packets that code MIDI System Exclusive (0xF0)
Exclusive (0xF0) commands. Appendix C.5 defines session configuration commands. Appendix C.5 defines session configuration tools that may be
tools that may be used to split a dense MIDI name space into several UDP used to split a dense MIDI name space into several UDP streams (each
streams (each sent in a different RTP session, per Section 2.1) so that sent in a different RTP session, per Section 2.1) so that the payload
the payload fits comfortably into an MTU. Another option is to use TCP. fits comfortably into an MTU. Another option is to use TCP. Section
Section 4.3 of [GUIDE] provides non-normative advice for packet size 4.3 of [GUIDE] provides non-normative advice for packet size management.
management.
3. MIDI Command Section 3. MIDI Command Section
Figure 2 shows the format of the MIDI command section. Figure 2 shows the format of the MIDI command section.
0 1 2 3 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 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 ... | |B|J|Z|P|LEN... | MIDI list ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 33, line 15 skipping to change at page 34, line 15
The session description below defines a unicast UDP RTP session (via a The session description below defines a unicast UDP RTP session (via a
media ("m=") line) whose sole payload type (96) is mapped to a minimal media ("m=") line) whose sole payload type (96) is mapped to a minimal
mpeg4-generic RTP MIDI stream. This example uses the General MIDI Audio mpeg4-generic RTP MIDI stream. This example uses the General MIDI Audio
Object Type under Synthesis Profile @ Level 2. Object Type under Synthesis Profile @ Level 2.
v=0 v=0
o=lazzaro 2520644554 2838152170 IN IP6 first.example.net o=lazzaro 2520644554 2838152170 IN IP6 first.example.net
s=Example s=Example
t=0 0 t=0 0
m=audio 5004 RTP/AVP 96 m=audio 5004 RTP/AVP 96
c=IN IP6 FF1E:03AD::7F2E:172A:1E24 c=IN IP6 2001:DB80::7F2E:172A:1E24
a=rtpmap:96 mpeg4-generic/44100 a=rtpmap:96 mpeg4-generic/44100
a=fmtp:96 streamtype=5; mode=rtp-midi; profile-level-id=12; a=fmtp:96 streamtype=5; mode=rtp-midi; profile-level-id=12;
config=7A0A0000001A4D546864000000060000000100604D54726B0000 config=7A0A0000001A4D546864000000060000000100604D54726B0000
000600FF2F000 000600FF2F000
(The a=fmtp line has been wrapped to fit the page to accommodate (The a=fmtp line has been wrapped to fit the page to accommodate
memo formatting restrictions; it comprises a single line in SDP) memo formatting restrictions; it comprises a single line in SDP)
The fmtp attribute line codes the four parameters (streamtype, mode, The fmtp attribute line codes the four parameters (streamtype, mode,
profile-level-id, and config) that are required in all mpeg4-generic profile-level-id, and config) that are required in all mpeg4-generic
skipping to change at page 96, line 29 skipping to change at page 97, line 29
cm_unused to specify complex behaviors. cm_unused to specify complex behaviors.
The example session description below illustrates the use of the stream The example session description below illustrates the use of the stream
subsetting parameters: subsetting parameters:
v=0 v=0
o=lazzaro 2520644554 2838152170 IN IP6 first.example.net o=lazzaro 2520644554 2838152170 IN IP6 first.example.net
s=Example s=Example
t=0 0 t=0 0
m=audio 5004 RTP/AVP 96 m=audio 5004 RTP/AVP 96
c=IN IP6 FF1E:03AD::7F2E:172A:1E24 c=IN IP6 2001:DB80::7F2E:172A:1E24
a=rtpmap:96 rtp-midi/44100 a=rtpmap:96 rtp-midi/44100
a=fmtp:96 cm_unused=ACGHJKNMPTVWXYZ; cm_used=__7F_00-7F_01_01__ a=fmtp:96 cm_unused=ACGHJKNMPTVWXYZ; cm_used=__7F_00-7F_01_01__
The session description configures the stream for use in clock The session description configures the stream for use in clock
applications. All voice channels are unused, as are all System Commands applications. All voice channels are unused, as are all System Commands
except those used for MIDI Time Code (command-type F, and the Full Frame except those used for MIDI Time Code (command-type F, and the Full Frame
SysEx command that is matched by the string assigned to cm_used), the SysEx command that is matched by the string assigned to cm_used), the
System Sequencer commands (command-type Q), and System Reset (command- System Sequencer commands (command-type Q), and System Reset (command-
type B). type B).
skipping to change at page 99, line 14 skipping to change at page 100, line 14
new policy. If a session description uses a j_update value unknown to new policy. If a session description uses a j_update value unknown to
the recipient, the recipient MUST NOT accept the description. the recipient, the recipient MUST NOT accept the description.
C.2.2.1 The anchor Sending Policy C.2.2.1 The anchor Sending Policy
In the anchor policy, the sender uses the first packet in the stream as 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 the checkpoint packet for all packets in the stream. The anchor policy
satisfies the recovery journal mandate (Section 4), as the checkpoint satisfies the recovery journal mandate (Section 4), as the checkpoint
history always covers the entire stream. history always covers the entire stream.
The anchor policy does not require the use of the Real Time Control The anchor policy does not require the use of the RTP control protocol
Protocol (RTCP, [RFC3550]) or other feedback from receiver to sender. (RTCP, [RFC3550]) or other feedback from receiver to sender. Senders do
Senders do not need to take special actions to ensure that received not need to take special actions to ensure that received streams start
streams start up free of artifacts, as the recovery journal always up free of artifacts, as the recovery journal always covers the entire
covers the entire history of the stream. Receivers are relieved of the history of the stream. Receivers are relieved of the responsibility of
responsibility of tracking the changing identity of the checkpoint tracking the changing identity of the checkpoint packet, because the
packet, because the checkpoint packet never changes. checkpoint packet never changes.
The main drawback of the anchor policy is bandwidth efficiency. Because The main drawback of the anchor policy is bandwidth efficiency. Because
the checkpoint history covers the entire stream, the size of the the checkpoint history covers the entire stream, the size of the
recovery journals produced by this policy usually exceeds the journal recovery journals produced by this policy usually exceeds the journal
size of alternative policies. For single-channel MIDI data streams, the size of alternative policies. For single-channel MIDI data streams, the
bandwidth overhead of the anchor policy is often acceptable (see bandwidth overhead of the anchor policy is often acceptable (see
Appendix A.4 of [NMP]). For dense streams, the closed-loop or open-loop Appendix A.4 of [NMP]). For dense streams, the closed-loop or open-loop
policies may be more appropriate. policies may be more appropriate.
C.2.2.2 The closed-loop Sending Policy C.2.2.2 The closed-loop Sending Policy
skipping to change at page 109, line 10 skipping to change at page 110, line 10
chapter parameter assignments described earlier in this section. chapter parameter assignments described earlier in this section.
The example session description below illustrates the use of the chapter The example session description below illustrates the use of the chapter
inclusion parameters: inclusion parameters:
v=0 v=0
o=lazzaro 2520644554 2838152170 IN IP6 first.example.net o=lazzaro 2520644554 2838152170 IN IP6 first.example.net
s=Example s=Example
t=0 0 t=0 0
m=audio 5004 RTP/AVP 96 m=audio 5004 RTP/AVP 96
c=IN IP6 FF1E:03AD::7F2E:172A:1E24 c=IN IP6 2001:DB80::7F2E:172A:1E24
a=rtpmap:96 rtp-midi/44100 a=rtpmap:96 rtp-midi/44100
a=fmtp:96 j_update=open-loop; cm_unused=ABCFGHJKMQTVWXYZ; a=fmtp:96 j_update=open-loop; cm_unused=ABCFGHJKMQTVWXYZ;
cm_used=__7E_00-7F_09_01.02.03__; cm_used=__7E_00-7F_09_01.02.03__;
cm_used=__7F_00-7F_04_01.02__; cm_used=C7.64; cm_used=__7F_00-7F_04_01.02__; cm_used=C7.64;
ch_never=ABCDEFGHJKMQTVWXYZ; ch_never=4.11-13N; ch_never=ABCDEFGHJKMQTVWXYZ; ch_never=4.11-13N;
ch_anchor=P; ch_anchor=C7.64; ch_anchor=P; ch_anchor=C7.64;
ch_anchor=__7E_00-7F_09_01.02.03__; ch_anchor=__7E_00-7F_09_01.02.03__;
ch_anchor=__7F_00-7F_04_01.02__ ch_anchor=__7F_00-7F_04_01.02__
(The a=fmtp line has been wrapped to fit the page to accommodate (The a=fmtp line has been wrapped to fit the page to accommodate
skipping to change at page 113, line 20 skipping to change at page 114, line 20
into a buffer upon receipt. The sender polls the buffer 1000 times a into a buffer upon receipt. The sender polls the buffer 1000 times a
second, extracts all complete commands from the buffer, and places the second, extracts all complete commands from the buffer, and places the
commands in an RTP packet. This session description describes the commands in an RTP packet. This session description describes the
transcoding: transcoding:
v=0 v=0
o=lazzaro 2520644554 2838152170 IN IP6 first.example.net o=lazzaro 2520644554 2838152170 IN IP6 first.example.net
s=Example s=Example
t=0 0 t=0 0
m=audio 5004 RTP/AVP 96 m=audio 5004 RTP/AVP 96
c=IN IP6 FF1E:03AD::7F2E:172A:1E24 c=IN IP6 2001:DB80::7F2E:172A:1E24
a=rtpmap:96 rtp-midi/44100 a=rtpmap:96 rtp-midi/44100
a=sendonly a=sendonly
a=fmtp:96 tsmode=buffer; linerate=320000; octpos=last; mperiod=44 a=fmtp:96 tsmode=buffer; linerate=320000; octpos=last; mperiod=44
The mperiod value of 44 is derived by dividing the clock rate specified 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, by the rtpmap attribute (44100 Hz) by the 1000 Hz buffer sampling rate,
and rounding to the nearest integer. Command timestamps might not and rounding to the nearest integer. Command timestamps might not
increment by exact multiples of 44, as the actual sampling period might increment by exact multiples of 44, as the actual sampling period might
not precisely match the nominal mperiod value. not precisely match the nominal mperiod value.
skipping to change at page 116, line 16 skipping to change at page 117, line 16
parameter value. In this case, senders SHOULD use the lowest minimum parameter value. In this case, senders SHOULD use the lowest minimum
sending rate that satisfies the congestion control requirements. sending rate that satisfies the congestion control requirements.
Below, we show a session description that uses the guardtime parameter. Below, we show a session description that uses the guardtime parameter.
v=0 v=0
o=lazzaro 2520644554 2838152170 IN IP6 first.example.net o=lazzaro 2520644554 2838152170 IN IP6 first.example.net
s=Example s=Example
t=0 0 t=0 0
m=audio 5004 RTP/AVP 96 m=audio 5004 RTP/AVP 96
c=IN IP6 FF1E:03AD::7F2E:172A:1E24 c=IN IP6 2001:DB80::7F2E:172A:1E24
a=rtpmap:96 rtp-midi/44100 a=rtpmap:96 rtp-midi/44100
a=fmtp:96 guardtime=44100; rtp_ptime=0; rtp_maxptime=0 a=fmtp:96 guardtime=44100; rtp_ptime=0; rtp_maxptime=0
C.5 Configuration Tools: Stream Description C.5 Configuration Tools: Stream Description
As we discussed in Section 2.1 in the main text, a party may send As we discussed in Section 2.1 in the main text, a party may send
several RTP MIDI streams in the same RTP session, and several RTP several RTP MIDI streams in the same RTP session, and several RTP
sessions that carry MIDI may appear in a multimedia session. sessions that carry MIDI may appear in a multimedia session.
By default, the MIDI name space (16 channels + systems) of each RTP By default, the MIDI name space (16 channels + systems) of each RTP
stream sent by a party in a multimedia session is independent. By stream sent by a party in a multimedia session is independent. By
skipping to change at page 121, line 17 skipping to change at page 122, line 17
In the next example, two mpeg4-generic streams form an ordered In the next example, two mpeg4-generic streams form an ordered
relationship to drive a Structured Audio decoder with 32 MIDI voice relationship to drive a Structured Audio decoder with 32 MIDI voice
channels. Both streams reside in the same RTP session. channels. Both streams reside in the same RTP session.
v=0 v=0
o=lazzaro 2520644554 2838152170 IN IP6 first.example.net o=lazzaro 2520644554 2838152170 IN IP6 first.example.net
s=Example s=Example
t=0 0 t=0 0
m=audio 5006 RTP/AVP 96 97 m=audio 5006 RTP/AVP 96 97
c=IN IP6 FF1E:03AD::7F2E:172A:1E24 c=IN IP6 2001:DB80::7F2E:172A:1E24
a=rtpmap:96 mpeg4-generic/44100 a=rtpmap:96 mpeg4-generic/44100
a=fmtp:96 streamtype=5; mode=rtp-midi; config=""; profile-level-id=13; a=fmtp:96 streamtype=5; mode=rtp-midi; config=""; profile-level-id=13;
musicport=5 musicport=5
a=rtpmap:97 mpeg4-generic/44100 a=rtpmap:97 mpeg4-generic/44100
a=fmtp:97 streamtype=5; mode=rtp-midi; config=""; profile-level-id=13; a=fmtp:97 streamtype=5; mode=rtp-midi; config=""; profile-level-id=13;
musicport=6; render=synthetic; rinit="audio/asc"; musicport=6; render=synthetic; rinit="audio/asc";
url="http://example.com/cardinal.asc"; url="http://example.com/cardinal.asc";
cid="azsldkaslkdjqpwojdkmsldkfpe" cid="azsldkaslkdjqpwojdkmsldkfpe"
(The a=fmtp lines have been wrapped to fit the page to accommodate (The a=fmtp lines have been wrapped to fit the page to accommodate
skipping to change at page 128, line 41 skipping to change at page 129, line 41
Initialization data object MAY encapsulate a Standard MIDI File (SMF). Initialization data object MAY encapsulate a Standard MIDI File (SMF).
By default, the SMFs that are encapsulated in a data object MUST be By default, the SMFs that are encapsulated in a data object MUST be
ignored by an RTP MIDI receiver. We define parameters to override this ignored by an RTP MIDI receiver. We define parameters to override this
default in Appendix C.6.4. default in Appendix C.6.4.
To end this section, we offer guidelines for registering media types for To end this section, we offer guidelines for registering media types for
initialization data objects. These guidelines are in addition to the initialization data objects. These guidelines are in addition to the
information in [RFC2048]. information in [RFC2048].
Some initialization data objects are also capable of encoding MIDI note Some initialization data objects are also capable of encoding MIDI note
information, and thus audio complete performances. These objects SHOULD information, and thus complete audio performances. These objects SHOULD
be registered using the "audio" media type, so that the objects may also be registered using the "audio" media type, so that the objects may also
be used for store-and-forward rendering, and "application" media type, be used for store-and-forward rendering, and "application" media type,
to support editing tools. Initialization objects without note storage, to support editing tools. Initialization objects without note storage,
or initialization objects for non-audio renderers, SHOULD be registered or initialization objects for non-audio renderers, SHOULD be registered
only for an "application" media type. only for an "application" media type.
C.6.4 MIDI Channel Mapping C.6.4 MIDI Channel Mapping
In this Appendix, we specify how to map MIDI name spaces (16 voice In this Appendix, we specify how to map MIDI name spaces (16 voice
channels + systems) onto a renderer. channels + systems) onto a renderer.
skipping to change at page 176, line 18 skipping to change at page 177, line 18
[RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier. "Real Time [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier. "Real Time
Streaming Protocol (RTSP)", RFC 2326, April 1998. Streaming Protocol (RTSP)", RFC 2326, April 1998.
[ALF] Clark, D. D. and D. L. Tennenhouse. "Architectural [ALF] Clark, D. D. and D. L. Tennenhouse. "Architectural
considerations for a new generation of protocols", SIGCOMM Symposium considerations for a new generation of protocols", SIGCOMM Symposium
on Communications Architectures and Protocols , (Philadelphia, on Communications Architectures and Protocols , (Philadelphia,
Pennsylvania), pp. 200--208, IEEE, Sept. 1990. Pennsylvania), pp. 200--208, IEEE, Sept. 1990.
[GUIDE] Lazzaro, J., and J. Wawrzynek. "An Implementation Guide for [GUIDE] Lazzaro, J., and J. Wawrzynek. "An Implementation Guide for
RTP MIDI", draft-ietf-avt-rtp-midi-guidelines-14.txt. RTP MIDI", draft-ietf-avt-rtp-midi-guidelines-15.txt.
[RFC2205] Braden, R. et al. "Resource ReSerVation Protocol (RSVP) -- [RFC2205] Braden, R. et al. "Resource ReSerVation Protocol (RSVP) --
Version 1 Functional Specification", RFC 2205, September 1997. Version 1 Functional Specification", RFC 2205, September 1997.
[RFC2048] Freed, N., Klensin, J., and J. Postel. "MIME Part Four: [RFC2048] Freed, N., Klensin, J., and J. Postel. "MIME Part Four:
Registration Procedures", RFC 2048, November 1996. Registration Procedures", RFC 2048, November 1996.
[CONTRANS] Lazzaro, J. "Framing RTP and RTCP Packets over [CONTRANS] Lazzaro, J. "Framing RTP and RTCP Packets over
Connection-Oriented Transport", Connection-Oriented Transport",
draft-ietf-avt-rtp-framing-contrans-05.txt. draft-ietf-avt-rtp-framing-contrans-05.txt.
skipping to change at page 177, line 47 skipping to change at page 178, line 47
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary rights copyrights, patents or patent applications, or other proprietary rights
that may cover technology that may be required to implement this that may cover technology that may be required to implement this
standard. Please address the information to the IETF at ietf- standard. Please address the information to the IETF at ietf-
ipr@ietf.org. ipr@ietf.org.
L. Full Copyright Statement L. Full Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject to Copyright (C) The Internet Society (2006). This document is subject to
the rights, licenses and restrictions contained in BCP 78, and except as the rights, licenses and restrictions contained in BCP 78, and except as
set forth therein, the authors retain all their rights. set forth therein, the authors retain all their rights.
This document and the information contained herein are provided This document and the information contained herein are provided
on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE. PARTICULAR PURPOSE.
Acknowledgement Acknowledgement
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
N. Change Log for <draft-ietf-avt-rtp-midi-format-14.txt> N. Change Log for <draft-ietf-avt-rtp-midi-format-15.txt>
[Note to RFC Editors: this Appendix, and its Table of Contents listing, [Note to RFC Editors: this Appendix, and its Table of Contents listing,
should be removed from the final version of the memo] should be removed from the final version of the memo]
Fixed typo in Appendix C.2.3 -- the section quoted below had assumed The following changes were made to the document:
MIDI had 255 controllers instead of 127 (!) in earlier -13.txt:
[begin quote] --
For Chapter C, the field list may take on values in the range 0 to [1] The IP6 "c=" lines in all session description
255. A field value X in the range 0-127 refers to a controller number examples were changed to be:
X, and indicates that the controller number does not use enhanced
Chapter C encoding. A field value X in the range 128-255 refers to a
controller number "X minus 128", and indicates the controller number
does use the enhanced Chapter C encoding.
Assignments made to configure the Chapter C encoding method for a c=IN IP6 2001:DB80::7F2E:172A:1E24
controller number MUST be made to the ch_default or ch_anchor
parameters, as assignments to ch_never act to exclude the number from
the recovery journal (and thus, the indicated encoding method is
irrelevant).
A Chapter C field list MUST NOT encode conflicting information about [2] In Appendix C.6.3, the final paragraph, the
the enhanced encoding status of a particular controller number. For phrase "audio complete performances" was changed
example, values 0 and 128 MUST NOT both be coded by a field list. to be the grammatically correct "complete audio
performances".
[endquote] [3] Updated GUIDE reference to version -15.txt.
Also, RTCP is now defined as "RTP control protocol",
not "Real Time Control Protocol, in its first
appearance in the text, and in several other
places in the text.
Also, updated GUIDE reference to version -14.txt. ---
The wording changes below are in response to
a late-arriving review by Jim Wright, who has
been reviewing RTP MIDI for the MMA. These
changes reflect confusions he had understanding
RTP session and stream definitions that were
added to the I-Ds shortly before Last Call.
He basically got in the mode of rereading
Section 2.1 over and over, trying to figure
out how it all fit together. He felt these
four clarifications would have helped him
figure out the mechanism easier, and so I
added these into the I-D.
[4] In Section 2.1, the paragraph that began
"A session description [SDP] media line ("m=")
is now preceded by the introductory line:
"We now define RTP session semantics, in the
context of sessions specified using the session
description protocol [SDP]."
[5] In the aforementioned paragraph, the sentence
beginning with "Source" now begins with
"Synchronization source".
[6] Later in Section 2.1, the paragraph that
begins "Streams in an RTP session may use"
has the added sentence:
Recall that dynamic binding of payload type
numbers in [SDP] lets a party map many payload
type numbers to the RTP MIDI payload format,
and thus a party may send many RTP MIDI streams
in a single RTP session.
[7] Later in Section 2.1, the paragraph that
begins "The RTP header timestamps for each stream"
ends with a few sentences that have been modified
to include specific references to [RFC3550]. Here
are the modified sentences:
The SSRC values for each stream in an RTP session
are also separately and randomly chosen, as described
in [RFC3550]. Receivers use the CNAME field encoded
in RTCP sender reports to verify that streams were
sent by the same party, and to detect SSRC collisions,
as described in [RFC3550].
 End of changes. 27 change blocks. 
156 lines changed or deleted 158 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/