[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



> 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.
> 
Seems like the problem here is reliability.  You need this "command"
to be reliable.  I'm not sure it has to be -very- reliable, but it
has to be more reliable than RTCP.  I think that is why sending it
in signalling was suggested.  Other suggestions for something more
reliable than RTCP are welcome, at least by me.

Brian

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