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

Hi, Paul --

On Oct 29, 2013, at 11:36 AM, Paul Kyzivat <pkyzivat@alum.mit.edu>
 wrote:

> Roni,
> 
> I'm still not sure I understand. I'm going to repeat my characterization about what I understand one more time:
> 
> - an RTP session MAY have one or more aphid tokens

Yes.

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

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

However, it's not as simple as saying that the same appid applies to all the streams of the source.

The important cases where a single source's streams will be split across multiple appid values are simulcast and MST layered codecs.  An important use case of appid is to disambiguate the various simulcast streams and layers; however, in the taxonomy draft's terminology these are a single source, and Unified puts them into a single m-line.  It's not clear to me yet how Unified is planning to signal these cases (I know Magnus has a proposal, but I haven't read it in detail yet), but appid will need to be able to handle it.

> - *new* appid:ssrc mappings MAY be initialized via SDP

Yes.

> - new appid:ssrc mappings MAY be initialized via receipt
>  of the new RTPC SDES message or header extension

Yes.  Only for appid values whose semantics are already specified (without an SSRC mapping) in SDP or elsewhere, however; otherwise there's no semantics to attach them to.  (Early media cases may need more thought here.)

> - existing appid:ssrc mappings MAY be updated via
>  receipt of the new RTCP SDES message or header extension.

Yes.

> 
> Can you either confirm the above is correct, or else update it so it is correct?
> 
> 	Thanks,
> 	Paul
> 
> 
> On 10/29/13 1:06 AM, Roni Even wrote:
>> Martin,
>> 1. My understanding that unified is only applicable to RTCweb but not a general MMUSIC solution. A singe media stream per m-line that may be grouped  is also a case for MMUSIC.
>> 2. The motivation for appID is also having multiple media streams (each with a different SSRC) in a single m-line representing a media source. (unified).
>> 3. The FEC example is more a corner case and a question I had about msid and unified but not the motivation for appID
>> Roni
>> 
>>> -----Original Message-----
>>> From: Martin Thomson [mailto:martin.thomson@gmail.com]
>>> Sent: 28 October, 2013 7:17 PM
>>> To: Roni Even
>>> Cc: Paul Kyzivat; mmusic@ietf.org
>>> Subject: Re: [MMUSIC] comments on draft-even-mmusic-application-token-01
>>> 
>>> On 28 October 2013 07:57, Roni Even <ron.even.tlv@gmail.com> wrote:
>>>> there can be an m-line for RTP stream
>>> 
>>> I have http://tools.ietf.org/html/draft-roach-mmusic-unified-plan-00#section-
>>> 3.3
>>> bookmarked, strangely enough, and the third paragraph is fairly clear about
>>> the desired configuration, which is that multiple SSRCs are grouped into the
>>> same m-line.
>>> 
>>> The issues regarding the use of a single FEC repair stream for multiple sources
>>> is where the "can" part comes in, but I wouldn't have used that as the starting
>>> position for this appid work.
>> 
>> 
> 
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
> 