[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 23, 2005, at 7:53 AM, Magnus Westerlund wrote:
I reread section C.4. I don't find the section particular clear. 

I'll rewrite it to make it clearer ...

[points below are reordered to help the narrative flow ...]

My concern is that you do a grouping of the media lines from payload type level, without anything at the top level like RFC 3388 to indicate that this is happening. Grouping of media lines are intended for exactly the purpose of identifying that two media lines has a relation that goes beyond the normal we are streams in a synchronized multi-media session.

Thus I don't see a problem with musicport to provide the ordered relation. However I think that this special relation should be indicated on a higher level than payload types, using RFC 3388.

OK, that's fine -- I'll add extra RFC 3388 stuff to signal the multiplexing
is happening, and musicport will stay to signal the MIDI semantics of
the multiplexing.


"If any payload types on an RTP MIDI media line define a musicport
parameter, all payload types on the media line MUST define a musicport
parameter that is assigned the same value."

This requires that different midi spaces use separate RTP session. Was that really intended?

My answer is forward-looking to -09.txt, where RFC 3388 will signal multiplexing, not PTs.

In -09.txt, the answer to your question will be "yes". Each RTP session
is dedicated to a single MIDI name space. If a particular party wishes to send
data on two name spaces, it needs two RTP sessions.

To do anything else is to use the PT for MIDI multiplexing. If PT1
for an RTP session handles MIDI channels 0-15, and PT2 for the
same RTP session handles MIDI channels 16-31, and if a sending party
takes turns switching between PT1 and PT2 on the same RTP session, well,
this seems like the very definition of using the PT for multiplexing to me.

Also, recall that two parties sending MIDI streams in the same
RTP session are NOT sending to the same namespace -- these name
spaces have an association of some sort (for example, handshaking
commands in MIDI consider the two cables as a paired entity), but
that is different from "sharing the same name space". For the
association to make sense, all parties need to choose a PT whose
MIDI name space matches the PT chosen by all other parties.
The only way to effectively do this is to have one name space for all PTs.


So what can work is to say that in the case of split transport. For a split stream the same SSRC should be used in both sessions. This requirement has some implication on collision detection and resolution. RTCP Cname would need to be used to confirm that two different sources really is the same.

Then in addition to simplify things the same RTP TS offset can be recommended to be used. However the synch information in RTCP must confirm this view that they are running the same time frame.


My preference now is to use the traditional RTP tools: split transport is done
with 2 RTP sessions, the grouping is signalled by RFC 3388 signalling,
the MIDI semantics of the grouping is signalled by musicport, the two
streams are independent synchronization sources with independent RTP
timestamp offsets, and synchronization is done via RTCP NTP/RTP
timestamp pairs.

The responsibility lies with the creator of the session descriptions to
split streams in a way where the temporal rearrangement of
commands on the two streams does not change MIDI semantics.

Note that packet loss is not an issue here -- the UDP session has
a recovery journal to handle loss, the TCP session has no loss.
The issue is that, due to lost or late packets, commands can be
executed out of order from the standpoint of the original unsplit
MIDI stream.

However ...

Consider that the only MIDI commands that are truly "too big"
for UDP are commands like "transfer this large block of data".
These are all System Exclusive commands.  I believe that
it is acceptable to segregate these commands to a TCP
stream, and the relative timing between the large SysEx
commands and real-time commands will be fine with the
temporal sync that RTCP NTP/RTP TS pairs provides.

Smaller real-time oriented SysEx commands belong on
the UDP RTP session, because real-time response is important.
I believe the journalling tools are sufficient for protecting
these sorts of commands, and if not, the answer lies in
designing better journalling systems, this is why there is
a parameter for signalling the journal system presently in use.

If one is making a new product from scratch using RTP MIDI
(as opposed to transcoding a MIDI 1.0 cable from an existing
product), one simply uses two MIDI streams, each with an
independent name space, one to do file transfer and one to do
real-time.  Or alternatively, one adds a web server into their
product to transfer files, and uses MIDI only for real-time work.


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.


I am not fully agreeing that what I as suggesting is not needed. I think there are still concerns on how the multiplexing is done an signaled in these more advanced case. 

Hopefully the adoption of RFC 3388 described above handles
these concerns.  Please let me know, I'm writing up -09.txt
as we speak ... ideally, we can get your input in time so that
the -09.txt can handle all of your remaining concerns.


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