[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