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

From: Joerg Ott <[email-masked]>
Date: Tue, 02 Jul 2002 16:15:21 +0200

> 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

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Joerg Ott <[email-masked]>
Date: Tue, 02 Jul 2002 17:12:27 +0200

> There have been hints of this nature; see RFC 2032 for H.261.

See also draft-ietf-avt-rtcp-feedback-03.txt, which doesn't
make it reliable but still conveys similar information to the
sender.

> There's always RTSP that probably fits a bit better and avoids the proxy
> issues. (I'm not suggesting that this is the ideal solution, but it's
> another point in the design space.) It specifically has SET_PARAMETER
> for such purposes.

Right.  It would also be cleaner from the semantics perspective.
I am not sure what kind other "remote control" protocols will be
showing up in the near future (there have been some discussion of
desired functionality which is not yet covered over the past months)
but RTSP has been suggested for at least two of them as being a
reasonable candidate.  But as stated in an earlier mail, there
is probably still a long way to go.

There are other issues: e.g. with broadcast-style scenarios in which
you do not have individual control connections to each those.  But
you still may want to be able to communicate "freeze" events as
Roni pointed out.  In many-to-many scenarios, we may or may not want
to have (yet) full mesh or n:m signaling relationships (besides SIP)
set-up just to send such commands and indications.

> It would be tricky to do this right in the presence of RTP mixers and
> translators, to name just one set of problems.

What is actually the default behavior of a mixer/translator if it
receives an RTCP compound packet in which individual RTCP packets
are not understood?  The spec seems to be rather silent about this.

Joerg