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

[Martin Thomson <[e-mail]>]

On 29 October 2013 14:34, Jonathan Lennox <[e-mail]> wrote:
>> - at any point in time each appid token maps to at most
>>  one stream (SSRC) within the session.
>
> This one isn't right.  An appid maps to at most one *source* -- but in situations where multiple streams (SSRCs) make up one source, in some cases we'll want them to be associated by having them have the same appid.

Thanks Jonathan, I had hoped that this was the intended answer.  It's
the only one that makes any sense.

> 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.