Subject: [AVT] Summary of issues for Yokohama: draft-ietf-avt-mwpp-midi-rtp-04.txt

From: John Lazzaro <[email-masked]>
Date: Tue, 9 Jul 2002 19:14:36 -0700

Hi everyone,

	Below is the "summary of issues" document for IETF 54 for:

http://www.ietf.org/internet-drafts/draft-ietf-avt-mwpp-midi-rtp-04.txt

	The meeting slides will focus on a few of the issues listed
below, guided by pre-meeting email and AVT-list comments received ...

							--john lazzaro

---------

	Since IETF 53, we have released two revisions for the MWPP
I-D. A short summary of the document status:

  o  The recovery journal chapter definitions are complete (Appendices
     A.1-8 and B.1-5, pp 30-55 of -04.txt). In other words, all MIDI
     Voice Channel and System command types are supported in the MWPP
     scheme for resiliency. As the MIDI Command Section also supports
     all MIDI command types, the MWPP payload is substantially complete.
     Bugfixes and potential minor enhancements are the open RTP issues.

  o  The SDP story is improving. All SDP definitions have been moved
     out of the payload text of the I-D, and placed in separate part
     of the text (Section 6, pp. 21-27, and Appendices C.1-5, pp 56-65).

     Section 6 describes the "minimal MWPP streams" for the two MWPP
     MIME types (mpeg4-generic and mwpp). Appendices C.1-5 define five
     classes of SDP parameters that "customize" the minimal MWPP stream;
     most parameters work for both mpeg4-generic and mwpp MIME types.
     These SDP parameters represent our initial estimation of the SDP
     support needed for the three target applications for MWPP:

       -- MIDI file streaming, into both MPEG 4 and other receivers.

       -- Replacing MIDI cable trees with a zeroconf/SIP/RTP LAN stack, 
          in studios and on stages.

       -- WAN network musical performance.

The I-D progress since IETF 53 was largely driven by the technical and
editorial suggestions from the growing group of "MIDI experts" that
read through every revision of the draft -- thanks for the
contributions!

We see the MWPP path leading up to IETF 55 in this way:

  o  In the foreground, finding bugs in the RTP payload, via:

        -- Review and comment from MIDI experts.

        -- Rewriting the sfront networking code, to reflect the
           -04.txt document, and extending this codebase to test
           both "MIDI cable" and "MIDI file streaming" uses of MWPP
           (sfront currently uses the pre-MWPP RTP packetization of
            August 2001).

        -- Begin to write the MWPP "Informative" I-D(s).
           The document(s) will describe algorithms for sending 
           and receiving recovery journals, timestamping MIDI input,
           and the rendering of MWPP MIDI command sections.

  o  In the background, several issues:

        -- Structured Audio access units are capable of
           carrying more than just MIDI -- SA defines its
           own modern score language, SASL. As SASL and
           MIDI are often used together in SA, one could
           imagine down the road:

             o  a SASL RTP packetization effort begins, and ...

             o  ... a design requirement is that SASL 
                and MWPP RTP streams must be able to target
                the same SA decoder instance in a session.

           It probably is a good idea to sketch out what a
           SASL RTP packetization might look like, with the
           goal of finding SASL-MWPP interoperability issues
           and fixing them in MWPP now (before its too late).

        -- As stated in the introduction to -04.txt:

               The scope of this memo is also limited
               in that it defines MIDI extensions for
               RTP and SDP, but it does not define 
               profiles for using RTP, SDP and other
               IETF tools in any specific MIDI application
               domain. We expect other documents, from the
               IETF or from other organizations, to define
               profiles that are based on MWPP, but this
               memo does not.

            Developing "strawman" frameworks documents for
            using MWPP in the target application domains 
            (file streaming, LANs to replace MIDI cable trees,
             and Network Musical Performance) would be a 
            good exercise to check the completeness of the
            current SDP parameter set in Appendix C.1-5. 
            Sample titles:

             "SIP sessions for MIDI on Stage and in the Studio"
             "RTSP File Streaming Guidelines for MIDI Files"

Finally, we list a few specific issues -04.txt that center on non-MIDI
issues in MWPP, that we would appreciate input from the AVT WG
audience:

  o  In Section 6.2, we show in detail how to set up an mpeg4-generic
     stream for mode mwpp. If one of the MPEG folks would double check
     the details we would appreciate it, as a few of our MPEG documents
     are FCD-vintage, and we may be using the wrong magic numbers. 
     In specific, we make these associations:

     MPEG Audio Object Profile ID 12 maps to SDP profile-level-id 74
     and codes Main Synthetic.

     MPEG Audio Object Profile ID 13 maps to SDP profile-level-id 75
     and codes Wavetable Synthesis.

     MPEG Audio Object Profile ID 14 maps to SDP profile-level-id 76
     and codes General MIDI.

     Are these all correct? 

     In addition, for the stream examples in Section 6.2, we looked at
     14496-3 part 1, along with the mpeg4-generic document, and deduced
     that for General MIDI at 44100 Hz, the proper AudioSpecificConfig 
     string was "E4" -- the "E" is the 14 value of the Object Profile ID
     for General MIDI, the 4 codes 44100Hz, and lack of any further 
     characters indicates that for an Object Profile ID 14 with no MIDI
     File, the StructuredAudioSpecificConfig has no chunks and therefore
     does not exist. 

     Is this correct? Given the many GM streaming implementors will 
     just blindly copy this "E4" string from the MWPP document, it 
     will become the de-facto GM config string, and so checking it
     for accuracy would be good ...

  o  In Appendix C.4, we define an SDP parameter (zerosync) to provide
     an alternative method to sync up several MWPP streams in the same
     session. The MPEG I-D series hints that the MPEG folks are thinking
     about this issue in a general MPEG context; it would be good to 
     get feedback on the Appendix C.4 approach ...

  o  In Appendix C.5, we define an extensible parameter, render, to
     code the MIDI rendering method used by the receiver. A few 
     potential issues here:

      -- An extensible parameter implies a policy on how to extend
         it. The -04.txt implies that "only standards-track IETF documents
         may extend render". Alternatives options to consider:

           -- "documents from the IETF and other organizations may
               extend render".

           -- "only standards-track IETF documents may extend render,
               with the exception of the x- namespace, which follows
               the MIME rules for x- MIME types".

          Comments?

      -- We define no general-purpose supplemental parameters for 
         use with render. Instead, we define one full-featured render
         method (sasc), to show a set of techniques for authors of
         render extensions to use or disregard as they see fit. 
          
         The other option would be to define a set of general-purpose
         supplemental parameters, and use sasc as the example of how
         to apply these supplemental parameters to a specific render
         type. 

         Comments?

  o  In Appendix C.5.1 (page 66), we propose the MIME type audio/sasc,
     which we use for transport of the AudioSpecificConfig() when config="".
     It would be good for both MIME and MPEG experts to look this section
     over with a critical eye ...

-------------------------------------------------------------------------
John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley
lazzaro [at] cs [dot] berkeley [dot] edu     www.cs.berkeley.edu/~lazzaro
-------------------------------------------------------------------------

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt