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

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

> > 1. Use the signalling channel to do this.  Roni proposed
> > a solution.
> > 2. Create an entirely new protocol to do this.
> > You proposed to do this.
> > 3. Make RTCP reliable and use it.
> 
> 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.

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

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

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