[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[AVT] Re: draft-ietf-avt-rtp-midi-08.txt: Issues with multiplexing different MIDI spaces


On May 20, 2005, at 5:04 AM, Magnus Westerlund wrote: 
Some comments on the updated draft (08) regarding the MIDI
command spaces and how they are multiplexed.


OK, these fit in to where -09.txt is going ... namely, to only
cover in the I-D session management issues for the application
domains where mature IETF session management protocols exist
for the domains (RTSP content streaming, and network musical
performance using SIP sessions) and to remove SDP-related
tools that are specific to stage and studio.  The issues you address
below have their roots in stage and studio applications.


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

I don't like this definition at all. RTP has a session context and that context should be indicated by the signalling, rather than being overridden by the RTP payload format. This limits the possibilities for usage. The signalling should tell the participant in a session if there is a single session or multiple sessions. So please don't change the RTP session usage. I would also like to point out that RTP payload types only have RTP session scope. They are not carried over to other sessions. Each RTP session can have its own PT=96 with what ever configuration. 

OK, this will go back to the normal way.


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

This combination of different media lines in SDP should be done explicitly
using a grouping of media lines RFC 3366.

We weren't using PTs for grouping here -- RTP MIDI uses the musicport parameter
for MIDI-savvy grouping. Musicport, defined in Appendix C.4, is a better tool
for RTP MIDI grouping than RFC 3388, because musicport encodes several
types of information about a set of MIDI namespaces -- identity and orderedness,
as defined in Appendix C.4 -- into a single integer value.

What we were using PTs for is to get two streams whose timestamp
field can be used for interleaving in a feed-forward way -- two streams
whose timestamp fields have the same random offset. This property
greatly simplifies the task of reliably splitting up a MIDI source and putting
it back together.

But, this example becomes much less interesting now that -09.txt will
remove stage and studio applications from the I-D -- so, I'll just remove
examples of this sort, and accept that this problem is hard presently.


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

This restriction is also not good. It prevents usage of any of the standardized RTP robustness mechanism that operates on RTP paylaods. See RFC 2198, RFC 2733 and the onging work on RTP retransmission. I don't understand the reasoning behind this. Are there any motives for this. 

The restriction was written overly broad -- it only was intended to
prohibit mpeg4-generic RTP MIDI and native RTP MIDI appearing
on the same line.  So I'll rewrite it to remove your concerns.

Also, I'll take a second look to see if even this narrow native/mpeg4- generic
restriction is really needed. The underlying reasons were complex, and may
have changed now that stage and studio is slated for removal.


My understanding what you tried to accomplish was that you may have several MIDI command spaces, each identified by the RTP PT. Each midi command space may have multiple entities sending (kind of shared cable or multiplexor box), and any number of entities receiving it. In addition you like to have the capability to split certain commands or data over different transports for reliabilty reasons.

To allow this I would propose to modify your proposal to the following: 

As I described above, musicport handles grouping, not PT,
and its very finely tuned to handle what RTP MIDI needs.  So,
when we remove the PT functionality from -09.txt, we will still
have all the expressive power we need, and the changes you
propose are not needed.


---
John Lazzaro
http://www.cs.berkeley.edu/~lazzaro
lazzaro [at] cs [dot] berkeley [dot] edu
---



_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www1.ietf.org/mailman/listinfo/avt