RE: [MMUSIC] FWD: I-D ACTION:draft-even-mmusic-video-media-contr ol-00.txt

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

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.
2. Create an entirely new protocol to do this.  
You proposed to do this.
3. Make RTCP reliable and use it.

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?

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

Brian

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
> Sent: Wednesday, June 26, 2002 5:48 PM
> To: Even, Roni
> Cc: 'Joerg Ott'; 'mmusic@ietf.org'; 'avt@ietf.org'
> Subject: Re: [MMUSIC] FWD: I-D
> ACTION:draft-even-mmusic-video-media-contr ol-00.txt
> 
> 
> inline.
> 
> Even, Roni wrote:
> > Hi Joerg,
> > Thanks for your comments.
> > 
> > 1. About the BNF I will fix it.
> > 
> > 2. I thought of having a section describing the usage in 
> SIP and SAP but
> > noticed that other drafts like offer/answer and simple 
> capabilities do
> > not
> > have section about SIP usage. If you meant that you want to 
> explain how
> > the
> > encoder uses this attribute to select the mode of operation 
> I can add
> > this
> > 
> > 3. About fast update and freeze. 
> > 	3.1 Using RTCP feedback for update was discussed in the last
> > meeting
> > and I agreed with the AVT guys that this should not be there
> > 	3.2 I would like to look at the new picture and freeze picture
> > in
> > the same context as a new codec request. This means that we use
> > signalling
> > to ask for a new codec and I see this feature as the same since I am
> > asking
> > for the same codec but with a new picture. If you want to look at it
> > from
> > the decoder wants a new codec or a new picture. Since 
> changing a codec
> > during a session is working in SAP and in SIP I do not see 
> the problem
> 
> THe problem is that the new picture request, in particular, is not a 
> change in STATE of the session, its a command to send a new 
> picture. The 
> SDP and offer/answer stuff is appropriate where there is a change in 
> state of the session parameters. That is not the case here. I also 
> suspect latency is an issue, since the video is distorted 
> until you get 
> the new intra picture. So it would seem to argue for a media 
> path thing. 
> Latency is generally not an issue for things like codec 
> change and hold.
> 
> The new picture request is a lot like things such as camera controls, 
> which are real-time media stream control activities. I am inclined to 
> argue that the appropriate solution is an e2e control protocol that, 
> like a media stream, is signaled in the SDP. We've argued 
> that the same 
> is true for thigns like floor control.
> 
> Freeze picture request does seem like its a lot like hold. Its a 
> persistent state of the session, and it must be explicitly changed to 
> get off of "freeze". Thus, I think an SDP approach here is fine.
> 
> -Jonathan R.
> 
> 
> 
> -- 
> Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
> Chief Scientist                         First Floor
> dynamicsoft                             East Hanover, NJ 07936
> jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
> http://www.jdrosen.net                  PH:  (973) 952-5000
> http://www.dynamicsoft.com
> 
> 
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www1.ietf.org/mailman/listinfo/mmusic
> 

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