Subject: Re: [AVT] new MWPP I-D ...

From: John Lazzaro <[email-masked]>
Date: Mon, 23 Sep 2002 15:21:38 -0700

> "Martijn Sipkema" <[email-masked]> writes:
>
> This approach is not unacceptable, but I really hope a better way of
> handling (N)RPNs (and possibly other non-atomic messages) is be
> possible. I'm not sure how they are best handled.  If only for
> (N)RPNs, the receiver could be mandated to keep state (current
> parameter) for a 'midiport' and handle (N)RPNs that way I suppose...

OK, I'l take a second look at this as part of the writing process for
the BCP, where the detailed merging guidance will reside -- it may be
that rebalancing the sender and receiver responsibilities in the
normative document is possible, to give the sender more freedom and
the receivers more responsibility.

But it is a delicate balance ... for "rarely used features", it makes
sense to put as much of the responsibility onto senders that use the
feature as possible, so that receivers don't have to implement logic
that may never be used over the lifetime of the product.

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

---

From: John Lazzaro <[email-masked]>
Date: Mon, 30 Sep 2002 18:11:51 -0700

[bundled replies to Colin Perkins and David Oran ...]

> Colin Perkins <[email-masked]> writes:
>
>
> How much of the playout model do you want to specify? The usual RTP semantic 
> is that buffering is a local issue for the receiver, with the RTP timestamp
> representing the timeline at the sender. You could make the sender aware of
> the buffering at all receivers, but that would add significant complexity,
> which may not be worthwhile.

Yes, I agree -- I'm skeptical that the complexity of this approach is
worth the gain, especially given MWPP-specific issues (see my reply to
David below). The sort of interactive MIDI applications that would use
this feature would be better off trimming receiver buffers to the
30-80ms range, rather than depend on API enhancements to improve the
perceived latency of 500ms receiver buffers ...

> "David R. Oran" <[email-masked]> writes:
>
>It would seem that the "panic" function would be better handled by an 
>out-of-band signal and then resychronization of the RTP media.
>
> [...]
>
>My personal perferred machinery would be via RTCP by defining something 
>like a new RTCP packet which asks the receiver to "dump your jitter buffer 
>and ignore all data (e.g. in-flight packets) until timestamp T".

Unfortunately, this wouldn't work for MWPP -- the "dump your jitter
buffer" command needs to be accompanied by MIDI commands to direct
post-dump stream cleanup. But, these MIDI commands would need to be
coded in the forward RTP stream, in order to be protected by the
recovery journal mechanism that rides in the forward stream. So, if
MWPP ends up with the sort of functionality (which is unlikely), it
will need to be integrated into the MWPP packetization itself, in the
forward RTP path.

Of course, MWPP is exceptional in this way -- for most codecs, a
general-purpose approach would have clear advantages ...