[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
Hi John,
See comments inline:
lazzaro wrote:
On May 20, 2005, at 5:04 AM, Magnus Westerlund wrote:
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.
I reread section C.4. I don't find the section particular clear.
Especially I reacted to this first normative statement:
"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 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.
So as long as the music port is linked to the PT you are using the PT
for this type of multiplexing.
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.
Okay, this mechanism I have missed. To my understanding what you tried
to accomplish what that two different transport destination would form
part of the same RTP session. Thus the same SSRC on both transports
would be the same part so that the following RTP sequence could be sent:
TCP 1 4 5
UDP 2 3 6 7
However the above can't be used, because the packet loss detection
doesn't work. It is impossible to determine what the loss rate actually
is over a specific transport link.
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.
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.
Good.
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.
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.
Cheers
Magnus Westerlund
Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB | Phone +46 8 4048287
Torshamsgatan 23 | Fax +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: magnus.westerlund at ericsson.com
_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www1.ietf.org/mailman/listinfo/avt