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

["Even, Roni" <roni.even@polycom.co.il>]

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

Thanks
Roni Even

> -----Original Message-----
> From: Joerg Ott [mailto:jo@tzi.uni-bremen.de]
> Sent: Wednesday, June 19, 2002 4:30 PM
> To: Even, Roni
> Cc: 'mmusic@ietf.org'; 'avt@ietf.org'
> Subject: Re: [MMUSIC] FWD: I-D 
> ACTION:draft-even-mmusic-video-media-control-00.txt
> 
> 
> Roni,
> 
> a couple of quick comments on the draft:
> 
> Section 3 looks ok to me.  I like the idea of minimizing the number
> of parameters one has to deal with.  The BNF needs some fixing to
> allow for fractional value but that's straightforward.
> 
> In addition, you need to specify the handling of this attribute
> for the offer/answer and for the session annoucement case.
> E.g. for offer/answer multiple video-resolution attributes may
> be included since the two parties intend to negotiate a proper
> mode of operation.  For SAP announcements, however, the semantics
> are different.
> 
> I have concerns regarding section four though.  You are describing
> two different aspects there:
> 
> 1. notifying the receiver(s) about an upcoming change in the media
>    stream ("freeze picture")
> 
> 2. allowing the receiver(s) to instruct the sender to use a certain
>    repair mechanism.
> 
> You propose both to be implemented by means of SDP in the signaling
> path.  While I consent that the information carried are valuable
> and possibly required in certain scenarios, I am not sure that
> SDP carried in the signaling path is the right answer to your
> needs.
> 
> Item 1) could be looked at in two different ways: a picture freeze
> can be thought of something of longer duration which happens rather
> infrequently such as a mute operation (using a=inactive carried via
> SIP) for hold/unhold operations but I do not think that the area of
> application is really comparable.  In my opinion, what you want to
> do, is provide some kind of marker (possibly included in the media
> stream) that indicates that decoding shall stop until a certain
> condition (e.g. the intra frame from another source) is received.
> This seems highly video-specific and better be reasonably synchronized
> with the media stream.  SDP is definitely not an ideal option (what
> would you do if you not have a separate signaling path as in
> broadcasting applications).  RTCP is better but the information may
> not reach the receivers in a timely fashion; information contained
> within the media stream itself (or the RTP headers) migth be a
> better alternative (but I suspect that some religion may be
> involved here).
> 
> Item 2) is clearly related to the feedback work we have been doing.
> The primary issue seems to be that we prefer to provide "hints"
> to the other side while you prefer to call those hints "commands"
> and require the other side to act accordingly.  Again, I do not
> see SDP being a suitable candidate to carry this information;
> any such feedback via SDP is likely to take longer to reach the
> sender compared to using RTCP -- and if you have multiple commands
> to send, you are bound to one command per SIP transaction.
> 
> For item 2), I'd like to point out that SDP is also the wrong
> place from a semantics perspective.  Indicating a certain temporary
> receiver condition is fundamentally different from indicating a
> (change in a) media stream property; those two aspects should not
> be confused and hence different mechanisms should be applied here.
> 
> I'll be happy to try and find an RTP/RTCP-based solution but
> SDP is a bad idea for this.
> 
> Joerg
> 

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