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

[Jonathan Lennox <[e-mail]>]

On Oct 29, 2013, at 6:04 PM, Paul Kyzivat <[e-mail]>
 wrote:

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

Right, yes; I'm trying to follow the taxonomy's terminology distinction.

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

Hm, that's a good point.

I think the right formulation is that, in the terminology of the latest taxonomy draft, an appid (at any given time) encompasses a single Source Packet Stream and its associated Redundancy Packet Streams.

In all cases I know about, it's possible to differentiate Source Packet Streams from Redundancy Packet Streams by payload type.

There is still an issue of getting the grouping of these streams correct when an appid changes sources, though; this will need a little bit of thought.

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

Right, I agree.

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

My point is that if you receive an appid in RTP that you've never heard of in signaling (whichever signaling you're using), you don't know what it means and can't do anything useful with it.  Thus my early-media analogy -- possibly you can assume that signaling describing the appid is forthcoming.

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

My inclination would be to say that if you've ever sent a mapping for an appid in RTP/RTCP, don't put an appid:ssrc mapping into subsequent offer/answer messages.  From a receiver point of view, this is equivalent to saying that appid:ssrc mappings in SDP are ignored if you've received mappings in RTP/RTCP.

I don't think RTP and RTCP should be distinguished in this respect.