[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[AVT] draft-ietf-avt-rtp-midi-08.txt: Issues with multiplexing different MIDI spaces
Hi,
Some comments on the updated draft (08) regarding the MIDI command
spaces and how they are multiplexed.
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.
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.
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.
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:
Different MIDI spaces are identified by use of payload types as each
MIDI space needs its configuration data. An SSRC SHALL only be sending
for a single MIDI space. Any number of receivers MAY be used. One or
more senders with unique SSRCs MAY exist within a MIDI space, depending
on the MIDI space usage. Several MIDI spaces may share a single RTP
session.
If one desires to share MIDI space between more than one transport
option. Several m= lines are declared. These are grouped together using
Grouping of media lines.
Comments, opinions?
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