Re: [MMUSIC] FWD: I-D ACTION:draft-even-mmusic-video-media-control-00.txt

[Joerg Ott <jo@tzi.uni-bremen.de>]

> We need to think carefully about this.
> If you accept that we need a reasonably reliable communication
> mechanism to accomplish tasks like video refresh, then we have,
> it seems to me, three choices:
> 
> 1. Use the signalling channel to do this.  Roni proposed
> a solution.

There is a sub-choice to be made here: The representation used to
convey the information.

The signaling channel may be adequate in some scenarios but SDP may not.

Also, as Henning pointed out, some signaling protocols -- such as RTSP --
may already provide reasonable hooks to achieve what Roni wants.  Others,
such as SIP, may have to rely on the message content to convey the
intended meaning.

We probably do not want to require all entities to speak both RTSP and
SIP.

> 2. Create an entirely new protocol to do this.
> You proposed to do this.

I'd consider this to be more on the worst case side of choices.

> 3. Make RTCP reliable and use it.

I don't think we need to make RTCP reliable, nor should we aim
for such a thing.

> 
> I'm not thrilled about using the signalling channel,
> but it has the very large advantage that it's, by far,
> the simplest way to solve the problem.  What Roni proposes may
> be ugly to you, but it will work. Sure, there may be latency
> issues, but I suspect that it won't be a big deal.

I think it is a rather ugly solution -- except for Jonathan's comment
pointing out that picture freeze is to some degree comparable to putting
a call on hold.  But again: which signaling protocol would you use
and how do you convey the information.

Also, I don't think reliability is key in all cases.  Taken to the
extreme, whether a command does not get through for a while
(because of re-transmissions), takes a while because some FEC scheme
is used, or is substituted by a later command after some (short) period
of time should not make too much a difference for many scenarios.
In either case, you will get rubbish (or nothing) on your screen
for a while; this can only be dealt with by the receiver.

> Designing an entirely new media level protocol for
> command/response of course keeps us protocol designers with vast
> new opportunities to enjoy 'many fine lunches', and a purpose
> built protocol MAY be the most appropriate thing to do, but,
> realistically, how long would you estimate it could be done,
> and what do we do in the mean time?

Right.  This is not an approach feasible for the short term.

> Enhancing RTCP might be between these two approaches,
> but seems to warp the original purpose a fair amount.
> I'm not real sure it still isn't the wisest approach.
> Besides, it might make the acronym more appropriate :)

We have been doing some work on RTCP feedback for receivers,
and we have discussed Roni's ideas in this context.  While "feedback"
is of course misleading for some of the cases, the mechanisms
described there could be applicable in such a different context,
too.  But I was reluctant to include the fairly different semantics
in the same document.  But one can probably build on top of it.

Joerg

_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic