Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 6295

RTP Payload Format for MIDI

Pages: 171
Proposed Standard
Errata
Obsoletes:  4695
Part 7 of 7 – Pages 153 to 171
First   Prev   None

Top   ToC   RFC6295 - Page 153   prevText

Appendix D. Parameter Syntax Definitions

In this appendix, we define the syntax for the RTP MIDI media type parameters in Augmented Backus-Naur Form (ABNF, [RFC5234]). When using these parameters with SDP, all parameters MUST appear on a single fmtp attribute line of an RTP MIDI media description. For mpeg4-generic RTP MIDI streams, this line MUST also include any mpeg4-generic parameters (usage described in Section 6.2). An fmtp attribute line may be defined (after [RFC3640]) as: ; ; SDP fmtp line definition ; fmtp = "a=fmtp:" token SP param-assign 0*(";" SP param-assign) CRLF where <token> codes the 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 parameters defined in Appendix C. The definition takes the form of the incremental assembly of the <param-assign> token. See [RFC3640] for the syntax of the mpeg4-generic parameters discussed in Section 6.2. ; ; ; top-level definition for all parameters ;
Top   ToC   RFC6295 - Page 154
    ;

    ;
    ; Parameters defined in Appendix C.1

    param-assign =   ("cm_unused="   (([channel-list] command-type
                                       [f-list]) / sysex-data))

    param-assign =/  ("cm_used="     (([channel-list] command-type
                                       [f-list]) / sysex-data))

    ;
    ; Parameters defined in Appendix C.2

    param-assign =/  ("j_sec="       ("none" / "recj" / ietf-extension))

    param-assign =/  ("j_update="    ("anchor" / "closed-loop" /
                                      "open-loop" / ietf-extension))

    param-assign =/  ("ch_default="  (([channel-list] chapter-list
                                       [f-list]) / sysex-data))

    param-assign =/  ("ch_never="    (([channel-list] chapter-list
                                       [f-list]) / sysex-data))

    param-assign =/  ("ch_anchor="   (([channel-list] chapter-list
                                       [f-list]) / sysex-data))

    ;
    ; Parameters defined in Appendix C.3

    param-assign =/  ("tsmode="      ("comex" / "async" / "buffer"))

    param-assign =/  ("linerate="     nonzero-four-octet)

    param-assign =/  ("octpos="       ("first" / "last"))

    param-assign =/  ("mperiod="      nonzero-four-octet)

    ;
    ; Parameter defined in Appendix C.4

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

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

    param-assign =/  ("rtp_maxptime=" four-octet)
Top   ToC   RFC6295 - Page 155
    ;
    ; Parameters defined in Appendix C.5

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

    ;
    ; Parameters defined in Appendix C.6

    param-assign =/  ("chanmask="     1*( 16(BIT) ))

    param-assign =/  ("cid="          DQUOTE cid-block DQUOTE)

    param-assign =/  ("inline="       DQUOTE base-64-block DQUOTE)

    param-assign =/  ("multimode="    ("all" / "one"))

    param-assign =/  ("render="       ("synthetic" / "api" / "null" /
                                       "unknown" / extension))

    param-assign =/  ("rinit="        mime-type "/" mime-subtype)

    param-assign =/  ("smf_cid="      DQUOTE cid-block DQUOTE)

    param-assign =/  ("smf_info="     ("ignore" / "identity" /
                                      "sdp_start" / extension))

    param-assign =/  ("smf_inline="   DQUOTE base-64-block DQUOTE)

    param-assign =/  ("smf_url="      DQUOTE uri-element DQUOTE)

    param-assign =/  ("subrender="    ("default" / extension))

    param-assign =/  ("url="          DQUOTE uri-element DQUOTE)

    ;
    ; list definitions for the cm_ command-type
    ;

    command-type =   [A] [B] [C] [F] [G] [H] [J] [K] [M]
                     [N] [P] [Q] [T] [V] [W] [X] [Y] [Z]

    ;
    ; list definitions for the ch_ chapter-list
    ;

    chapter-list =   [A] [B] [C] [D] [E] [F] [G] [H] [J] [K]
                     [M] [N] [P] [Q] [T] [V] [W] [X] [Y] [Z]
Top   ToC   RFC6295 - Page 156
    ;
    ; list definitions for the channel-list (used in ch_* / cm_* params)
    ;

    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          = DIGIT / ("1" %x30-35)   ; "0" .. "15"

    ;
    ; list definitions for the ch_ field list (f-list)
    ;

    f-list             = midi-field-element *("." midi-field-element)

    midi-field-element = midi-field / midi-field-range

    midi-field-range   = midi-field "-" midi-field
                       ;
                       ; Decimal value of left midi-field
                       ; MUST be strictly less than
                       ; decimal value of right midi-field.

    midi-field         = four-octet
                       ;
                       ; Large range accommodates Chapter M
                       ; RPN (0-16383), 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
Top   ToC   RFC6295 - Page 157
    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          = %x30-37 U-HEXDIG
                       ;
                       ; Rewritten special case of hex-octet in
                       ; [RFC2045] (page 23).
                       ; Note that a-f are not permitted, only A-F.
                       ; hex-octet values MUST NOT exceed 0x7F.

    ;
    ; definitions for rinit parameter
    ;

    mime-type          = "audio" / "application"

    mime-subtype       = subtype-name
                       ;
                       ; See Appendix C.6.2 for registration
                       ; requirements for rinit type/subtypes.
                       ;
                       ; subtype-name is defined in [RFC4288],
                       ; Section 4.2.

    ;
    ; Definitions for base64 encoding
    ; copied from [RFC4566]
    ; changes from [RFC4566] to improve automatic syntax checking.
    ;

    base-64-block      = *base64-unit [base64-pad]

    base64-unit        = 4(base64-char)

    base64-pad         = (2(base64-char) "==") / (3(base64-char) "=")

    base64-char        = %x41-5A / %x61-7A / %x30-39 / "+" / "/"
                       ; A-Z, a-z, 0-9, "+" and "/"

    ;
    ; generic rules
    ;
Top   ToC   RFC6295 - Page 158
    ietf-extension     = token
                       ;
                       ; may only be defined in Standards-Track RFCs

    extension          = token
                       ;
                       ; may be defined
                       ; by filing a registration with IANA

    nonzero-four-octet =  (NZ-DIGIT 0*8(DIGIT))
                        / (%x31-33 9(DIGIT))
                        / ("4" %x30-31 8(DIGIT))
                        / ("42" %x30-38 7(DIGIT))
                        / ("429" %x30-33 6(DIGIT))
                        / ("4294" %x30-38 5(DIGIT))
                        / ("42949" %x30-35 4(DIGIT))
                        / ("429496" %x30-36 3(DIGIT))
                        / ("4294967" %x30-31 2(DIGIT))
                        / ("42949672" %x30-38 (DIGIT))
                        / ("429496729" %x30-34)
                       ;
                       ; unsigned encoding of non-zero 32-bit value:
                       ;  1 .. 4294967295

    four-octet         = "0" / nonzero-four-octet
                       ;
                       ; unsigned encoding of 32-bit value:
                       ;  0 .. 4294967295

    uri-element        = URI-reference
                       ; as defined in [RFC3986]

    token              = 1*token-char
                       ; copied from [RFC4566]

    token-char         = %x21 / %x23-27 / %x2A-2B / %x2D-2E /
                         %x30-39 / %x41-5A / %x5E-7E
                       ; copied from [RFC4566]

    cid-block          = 1*cid-char

    cid-char           =  token-char
    cid-char           =/ "@"
    cid-char           =/ ","
    cid-char           =/ ";"
    cid-char           =/ ":"
    cid-char           =/ "\"
    cid-char           =/ "/"
Top   ToC   RFC6295 - Page 159
    cid-char           =/ "["
    cid-char           =/ "]"
    cid-char           =/ "?"
    cid-char           =/ "="
                       ;
                       ; - Add back in the tspecials [RFC2045], except
                       ;   for DQUOTE and the non-email safe ( ) < >.
                       ; - Note that the definitions above ensure that
                       ;   cid-block is always enclosed with DQUOTEs.

    A        = %x41    ; Uppercase-only letters used above.
    B        = %x42
    C        = %x43
    D        = %x44
    E        = %x45
    F        = %x46
    G        = %x47
    H        = %x48
    J        = %x4A
    K        = %x4B
    M        = %x4D
    N        = %x4E
    P        = %x50
    Q        = %x51
    T        = %x54
    V        = %x56
    W        = %x57
    X        = %x58
    Y        = %x59
    Z        = %x5A

    NZ-DIGIT = %x31-39 ; non-zero decimal digit

    U-HEXDIG = DIGIT / A / B / C / D / E / F
                       ; variant of HEXDIG [RFC5234] :
                       ; hexadecimal digit using uppercase A-F only

    ; The rules below are from the Core Rules from [RFC5234].

    BIT     =  "0" / "1"

    DQUOTE  =  %x22           ; "  (Double Quote)

    DIGIT   =  %x30-39        ; 0-9


    ; external references
    ; URI-reference: from [RFC3986]
Top   ToC   RFC6295 - Page 160
    ; subtype-name: from [RFC4288]

    ;
    ; End of ABNF

   The mpeg4-generic RTP payload [RFC3640] defines a mode parameter that
   signals the type of MPEG stream in use.  We add a new mode value,
   rtp-midi, using the ABNF rule below:

      ;
      ; mpeg4-generic mode parameter extension
      ;

      mode               =/ "rtp-midi"
                         ; as described in Section 6.2 of this memo

Appendix 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 [MIDI] 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.
Top   ToC   RFC6295 - Page 161
     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     |     Channel Voice Messages     |      Bitfield Pattern      |
     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     | NoteOff (end a note)           | 1000cccc 0nnnnnnn 0vvvvvvv |
     |-------------------------------------------------------------|
     | NoteOn (start a note)          | 1001cccc 0nnnnnnn 0vvvvvvv |
     |-------------------------------------------------------------|
     | PTouch (Polyphonic Aftertouch) | 1010cccc 0nnnnnnn 0aaaaaaa |
     |-------------------------------------------------------------|
     | CControl (Controller Change)   | 1011cccc 0xxxxxxx 0yyyyyyy |
     |-------------------------------------------------------------|
     | PChange (Program Change)       | 1100cccc 0ppppppp          |
     |-------------------------------------------------------------|
     | CTouch (Channel Aftertouch)    | 1101cccc 0aaaaaaa          |
     |-------------------------------------------------------------|
     | PWheel (Pitch Wheel)           | 1110cccc 0xxxxxxx 0yyyyyyy |
      -------------------------------------------------------------

                    Figure E.1 -- MIDI Channel Messages


     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     |      System Common Messages    |     Bitfield Pattern       |
     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     | System Exclusive               | 11110000, followed by 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                   |
      -------------------------------------------------------------
Top   ToC   RFC6295 - Page 162
     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     |    System Real-Time 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

   Figures 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.  System commands
   perform functions that usually affect all voice channels, such as
   System Reset (0xFF).

E.1. Commands Types

A voice command executes 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.
Top   ToC   RFC6295 - Page 163
   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 [MIDI], 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 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 [MIDI]. 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.
Top   ToC   RFC6295 - Page 164
   In contrast, Standard MIDI Files (SMFs, [MIDI]), a file format for
   representing complete musical performances, add an 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.6.5, 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 [MPEGAUDIO]. StructuredAudioSpecificConfig, a key data structure coded in AudioSpecificConfig, is defined in [MPEGSA]. For implementors wishing to specify Structured Audio renderers, a full understanding of [MPEGSA] and [MPEGAUDIO] is essential. However, many implementors will limit their rendering options to the two MIDI Manufacturers Association (MMA) renderers that may be specified in AudioSpecificConfig: General MIDI (GM, [MIDI]) and Downloadable Sounds 2 (DLS 2, [DLS2]). To aid these implementors, we reproduce the AudioSpecificConfig bitfield formats for a GM renderer and a DLS 2 renderer below. We have checked these bitfields carefully and believe they are correct. However, we stress that the material below is informative and that [MPEGAUDIO] and [MPEGSA] are the normative definitions for AudioSpecificConfig. As described in Section 6.2, a minimal mpeg4-generic session description encodes the AudioSpecificConfig binary bitfield as a hexadecimal string (whose format is defined in [RFC3640]) that is assigned to the "config" parameter. As described in Appendix C.6.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:
Top   ToC   RFC6295 - Page 165
       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.
Top   ToC   RFC6295 - Page 166
                       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 to 0x5 specify 1 to 5 audio channels;
   the value 0x6 specifies 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 [MPEGSA]) 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.
Top   ToC   RFC6295 - Page 167
       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 the 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 [MPEGAUDIO]
   for details).  Senders not using these tools MUST append this "0"
   bit; receivers that do not understand these coding tools MUST ignore
   all data following a "1" 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 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.6.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).

         --------------------------------------------
        |  MIDI File = <Header Chunk> <Track Chunk>  |
         --------------------------------------------

   <Header Chunk> = <chunk type> <length>     <format> <ntrks> <divsn>
                    4D 54 68 64  00 00 00 06  00 00    00 01   00 60

   <Track Chunk> = <chunk type>  <length>     <delta-time> <end-event>
                   4D 54 72 6B   00 00 00 04  00           FF 2F 00

            Figure E.6 -- SMF File Encoded in the Example
Top   ToC   RFC6295 - Page 168
   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 hexadecimal string yields:

      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 [RFC2045] yields:

      egoAAAAaTVRoZAAAAAYAAAABAGBNVHJrAAAABgD/LwAA

   This string is assigned to the inline parameter in the General MIDI
   example shown in Appendix C.6.5.
Top   ToC   RFC6295 - Page 169

References

Normative References

[MIDI] MIDI Manufacturers Association. "The Complete MIDI 1.0 Detailed Specification", 1996. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, July 2003. [RFC3640] van der Meer, J., Mackie, D., Swaminathan, V., Singer, D., and P. Gentric, "RTP Payload Format for Transport of MPEG-4 Elementary Streams", RFC 3640, November 2003. [MPEGSA] International Standards Organization. "ISO/IEC 14496 MPEG-4", Part 3 (Audio), Subpart 5 (Structured Audio), 2001. [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006. [MPEGAUDIO] International Standards Organization. "ISO 14496 MPEG- 4", Part 3 (Audio), 2001. [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996. [DLS2] MIDI Manufacturers Association. "The MIDI Downloadable Sounds Specification", v98.2, 1998. [RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
Top   ToC   RFC6295 - Page 170
   [RFC3264]   Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
               with Session Description Protocol (SDP)", RFC 3264, June
               2002.

   [RFC3986]   Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
               Resource Identifier (URI): Generic Syntax", STD 66, RFC
               3986, January 2005.

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

   [RFC5888]   Camarillo, G. and H. Schulzrinne, "The Session
               Description Protocol (SDP) Grouping Framework", RFC 5888,
               June 2010.

   [RFC2818]   Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.

   [RP015]     MIDI Manufacturers Association.  "Recommended Practice
               015 (RP-015): Response to Reset All Controllers", 11/98.

   [RFC4288]   Freed, N. and J. Klensin, "Media Type Specifications and
               Registration Procedures", BCP 13, RFC 4288, December
               2005.

   [RFC4855]   Casner, S., "Media Type Registration of RTP Payload
               Formats", RFC 4855, February 2007.

Informative References

[NMP] Lazzaro, J. and J. Wawrzynek. "A Case for Network Musical Performance", 11th International Workshop on Network and Operating Systems Support for Digital Audio and Video (NOSSDAV 2001) June 25-26, 2001, Port Jefferson, New York. [GRAME] Fober, D., Orlarey, Y., and S. Letz. "Real Time Musical Events Streaming over Internet", Proceedings of the International Conference on WEB Delivering of Music 2001, pages 147-154. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998.
Top   ToC   RFC6295 - Page 171
   [ALF]       Clark, D.D. and D.L. Tennenhouse. "Architectural
               Considerations for a New Generation of Protocols",
               SIGCOMM Symposium on Communications Architectures and
               Protocols, (Philadelphia, Pennsylvania), pp. 200-208,
               ACM, Sept. 1990.

   [RFC4695]   Lazzaro, J. and J. Wawrzynek, "RTP Payload Format for
               MIDI", RFC 4695, November 2006.

   [RFC4696]   Lazzaro, J. and J. Wawrzynek, "An Implementation Guide
               for RTP MIDI", RFC 4696, November 2006.

   [RFC2205]   Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and
               S. Jamin, "Resource ReSerVation Protocol (RSVP) --
               Version 1 Functional Specification", RFC 2205, September
               1997.

   [RFC4571]   Lazzaro, J., "Framing Real-time Transport Protocol (RTP)
               and RTP Control Protocol (RTCP) Packets over Connection-
               Oriented Transport", RFC 4571, July 2006.

   [SPMIDI]    MIDI Manufacturers Association.  "Scalable Polyphony
               MIDI, Specification and Device Profiles", Document
               Version 1.0a, 2002.

   [LCP]       Apple Computer. "Logic 7 Dedicated Control Surface
               Support", Appendix B.  Product manual available from
               www.apple.com.

Authors' Addresses

John Lazzaro (corresponding author) UC Berkeley CS Division 315 Soda Hall Berkeley, CA 94720-1776 EMail: lazzaro@cs.berkeley.edu John Wawrzynek UC Berkeley CS Division 631 Soda Hall Berkeley, CA 94720-1776 EMail: johnw@cs.berkeley.edu