Re: [MMUSIC] comments on draft-even-mmusic-application-token-01

[Jonathan Lennox <[e-mail]>]

On Oct 29, 2013, at 6:00 PM, Martin Thomson <[e-mail]>
 wrote:

> On 29 October 2013 14:34, Jonathan Lennox <[e-mail]> wrote:
> 
>> In particular, I think, RTX and single-stream-repair FEC streams should probably be associated to their primary stream using appid.  (Multi-stream-repair FEC is more complicated, as the draft discusses.  Yes, we probably shouldn't have jumped to the more complicated case so quickly in the examples.)
> 
> The SDES extension or RTP extension could identify an SSRC as
> contributing to multiple sources in those complicated scenarios.  The
> simple case is where each SSRC contributes to just a single source.
> Maybe that's too much information for an RTP extension, in which case
> you could send the appid indications for each source a) when the
> contribution commences - i.e., at the start of transmission; and b)
> interleaved when there is more than one appid.  That assumes that the
> SSRC can't ever stop contributing to a given source, which I think is
> a safe assumption.

Hi, Martin -- there are several separate issues here, which it's good to keep separate.

One is that a set of streams can make up a single source, associated with a single appid, as in RTX and FEC.  Each stream is associated to a single source in this sense, except in multi-stream-repair FEC cases.

However, which source corresponds to an appid can change dynamically.  The primary use case I personally see for this is loudest-speaker switching, where the appid corresponds to a requested loudest speaker.

More controversially, I've also proposed that a single source can satisfy more than one appid at a time -- as in the case when you've requested both my video, and the current loudest speaker video, and right now I'm the current loudest speaker.