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

[Paul Kyzivat <[e-mail]>]

On 10/29/13 3:23 PM, Roni Even wrote:
> Paul,
> Inline
> Roni
>
>> -----Original Message-----
>> From: Paul Kyzivat [mailto:[e-mail]]
>> Sent: 29 October, 2013 5:36 PM
>> To: Roni Even; 'Martin Thomson'
>> Cc: [e-mail]
>> Subject: Re: [MMUSIC] comments on draft-even-mmusic-application-token-01
>>
>> 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 appid tokens
> [Roni Even] This is correct but not important, an m-line can have one or more appIds toke

Historically there was a 1:1 relationship between m-lines and RTP 
sessions. But now we have Bundle, which is changing that relationship. 
And I think AppId can be involved in understanding the relationship.

An RTP implementation will be looking at what arrives in RTP packets, 
and trying to do the correlation with information from SDP. I am trying 
to clarify the relationships.

So this statement, on its own may be somewhat simplistic, is a 
foundation for the following points. I think the "namespace" for AppIds 
must be an RTP session.

>> - at any point in time each appid token maps to at most
>>     one stream (SSRC) within the session.
> [Roni Even] To one media stream - see the taxonomy draft

OK, good. Everybody seems to be agreeing on this. I suggest being very 
explict, so no future reader is confused.

>> - *new* appid:ssrc mappings MAY be initialized via SDP
> [Roni Even] Yes
>> - new appid:ssrc mappings MAY be initialized via receipt
>>     of the new RTPC SDES message or header extension
> [Roni Even] This is not a may but that is the MUST and we need both SDES and RTP header but the RTP header should have precedence in case of race condition. This is to allow the binding between a media stream in SDP to an SSRC to happen in the RTP when it is used.

My point with the MAY was that the sender might not use this mechanism.
There are two mechanisms:
- SDP a=appid
- RTCP SDES & RTP header (IIUC these are two parts of one mechanism)

They are both optional to use.

At least that is what I understand.

>> - existing appid:ssrc mappings MAY be updated via
>>     receipt of the new RTCP SDES message or header extension.
> [Roni Even] Yes, RTP header has precedence over SDES in case of race condition.

I'm not sure what "precedence" means here. Doesn't each update the state 
when it is received?

	Thanks,
	Paul

>> 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:[e-mail]]
>>>> Sent: 28 October, 2013 7:17 PM
>>>> To: Roni Even
>>>> Cc: Paul Kyzivat; [e-mail]
>>>> Subject: Re: [MMUSIC] comments on
>>>> draft-even-mmusic-application-token-01
>>>>
>>>> On 28 October 2013 07:57, Roni Even <[e-mail]> 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.
>>>
>>>
>
>