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

Hi Paul,
One thing I am trying to look at is that we can use the appID to create the
binding to SSRC in the RTP header and RTCP SDES and have the binding to SSRC
in SDP as optional.
This will take way the need to do binding like a=ssrc:xxxx cname:yyyy
srcname:zzz which should be done in the RTCP SDES.
Roni

> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]
> Sent: 28 October, 2013 7:33 PM
> To: Roni Even; 'Martin Thomson'
> Cc: mmusic@ietf.org
> Subject: Re: [MMUSIC] comments on draft-even-mmusic-application-token-01
> 
> Roni,
> 
> On 10/28/13 10:57 AM, Roni Even wrote:
> > 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?)
> 
> I *think* you are confirming what I wrote in my original comment:
> 
> > - an RTP session MAY have one or more appid tokens
> > - at any point in time each appid token maps to at most
> >   one stream (SSRC) within the session.
> > - *new* appid:ssrc mappings MAY be initialized via SDP
> > - new appid:ssrc mappings MAY be initialized via receipt
> >   of the new RTPC SDES message or header extension
> > - existing appid:ssrc mappings MAY be updated via
> >   receipt of the new RTCP SDES message or header extension.
> 
> including the 2nd point above. Is that true?
> 
> 	Thanks,
> 	Paul
> 
> > 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
> >
> >