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

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

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