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

["Rosen, Brian" <Brian.Rosen@marconi.com>]

I agree that the signalling channel might be appropriate
I agree that SDP may not be the best way to do it in the signalling 
	channel, but I think it could work
I agree that requiring RTSP to get a picture refresh in a SIP based
	terminal is not a good idea
I agree that designing a new protocol for this purpose is not 
	feasible

I think we need to decide whether RTCP or SIP signalling is the 
best way to solve the problem.  

I'll agree that there are many grades of reliability, and picture 
refresh doesn't need a lot of reliability, but wouldn't you say 
that you tend to need picture refresh when RTCP is pretty unlikely 
to get through?  It seems to me that you need something better than 
what RTCP currently does.  I'm neutral on whether it's easier to put 
it in the signalling channel, or enhance RTCP.  I just want to decide 
how best to do it, and go do it.

I observe that what you need is a lightweight mechanism that is
reasonably "robust" in the face of congestion.  Robust means that
refresh requests get through reasonably reliably without contributing
substantially to the congestion problem.  I observe that the more
reliable the mechanism is, the better the sender behaves with respect
to congestion -- if the receiver blocks waiting for the refresh,
and the sender doesn't get the request, it sends updates that are 
discarded at the receiver, until the refresh comes.  Then it sends
the refreshed image.  If the refresh came in a timely and somewhat
reliable (in the face of congestion) manner, then the sender would
be more likely to send only useful data.

Brian


> -----Original Message-----
> From: Joerg Ott [mailto:jo@tzi.uni-bremen.de]
> Sent: Tuesday, July 02, 2002 10:15 AM
> To: Rosen, Brian
> Cc: 'Jonathan Rosenberg'; Even, Roni; 'mmusic@ietf.org'; 
> 'avt@ietf.org'
> Subject: [AVT] Re: [MMUSIC] FWD: I-D
> ACTION:draft-even-mmusic-video-media-control-00.txt
> 
> 
> > 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
> avt@ietf.org
> https://www1.ietf.org/mailman/listinfo/avt
> 

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