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

Hi,
The appId is used to map to an SSRC so in the unified plan there can be more
than one RTP stream from a source like simulcast (see the new avtcore
simulcast-03 draft) but there can be an m-line for RTP stream like the CLUE
signaling examples. 
So there should be a different appIDd to the source and repair streams and
the association  is done using SDP group (RFC5956), note that the
association is very flexibly and the example we give is the case when one
repair stream is repairing three source streams from different cameras which
are different sources. This is feasible for a TP system. 
Having this FEC repair stream raises
 The question what is the msid of the repair stream and my thought was that
there is none (or all three?)

Roni

> -----Original Message-----
> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf
> Of Martin Thomson
> Sent: 28 October, 2013 4:46 AM
> To: Paul Kyzivat
> Cc: mmusic@ietf.org
> Subject: Re: [MMUSIC] comments on draft-even-mmusic-application-token-01
> 
> On 27 October 2013 15:11, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
> > I *thought* that for instance in case of FEC, the original stream and
the
> repair stream would have the same appid. But the example showed otherwise.
> 
> That's odd.  I'd have thought that too.
> 
> > I'd like the model to be spelled out. Then we wouldn't be wondering.
> 
> Yep.  Much better.  All it takes is something like 1 appid = 1 media
source.
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic