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

[Paul Kyzivat <[e-mail]>]

Jonathan,

Thanks for the clarifications. I have more questions.

On 10/29/13 5:34 PM, Jonathan Lennox wrote:
> Hi, Paul --
>
> On Oct 29, 2013, at 11:36 AM, Paul Kyzivat <[e-mail]>
>   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.

I thought that in RPT terms a source is equivalent to an SSRC.
Are you talking about a "Media Source" according to the taxonomy?

If an appid could only map to *one* ssrc, then changes are easy - when 
you get a new mapping then the old one goes away.

But if an appid can map to multiple SSRCs, then that complicates 
changing the mapping. Getting a mapping of the same appid to a new ssrc 
doesn't necessarily invalidate any old mappings. It might be necessary 
to explicitly unmap it. I don't see how you would do that.

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

I presume it doesn't make sense to give two arbitrary SSRCs the same 
appid. Is there a way to revise/replace this statement with one that is 
correct and says something useful?

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

ISTM that it is important to distinguish valid mappings from invalid ones.

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

I'm not sure I follow this.

Suppose there was nothing in SDP. But a new appid shows up in RTCP SDES. 
It could (via a common value) tie together a raw stream with an RTX or 
FEC stream. It just doesn't say what it is used for. But putting it in 
SDP doesn't say what it is used for either.

In CLUE, the semantics could be in an Advertisement. (But, if we use an 
SDP label to reference an encoding, then I guess we would need the appid 
in the SDP too in order to tie those together.)

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

I'm still concerned about appid:ssrc mappings in subsequent 
offers/answers. If the first O/A defined one mapping, and a subsequent 
O/A revised that (different ssrc for the same appid) would that mapping 
change take effect?

Would the answer change depending on whether any media has been 
send/received with that ssrc?

Would the answer change depending on whether the mapping has been 
updated via RTCP SDES message or header extension?

	Thanks,
	Paul