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

[Henning Schulzrinne <hgs@cs.columbia.edu>]

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

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

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

> 
> Brian
> 


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