Re: [MMUSIC] Some more APPID questions

AppIDs need to be unique with an RTP session in order to work for the use cases we've identified so far.

There may be use cases that would like to define them to be unique more broadly -- presumably within a multimedia session, across several RTP sessions -- and enforcing that wouldn't break anything about the mechanism, I think, if it turns out to be useful.

It's the responsibility of the signaling mechanism that negotiates the AppID values to ensure uniqueness.  The current draft is a little vague on how you do this in SDP, because we haven't quite figured out how much AppID values should be receiver-selected vs. sender-selected.  (Sender-selected makes more sense conceptually, but doesn't solve the Bundle early-media race condition with an offered recvonly stream.)

On Nov 4, 2013, at 3:54 AM, Harald Alvestrand <harald@alvestrand.no>
 wrote:

> On 11/04/2013 09:02 AM, Roni Even wrote:
>> Harald,
>> 
>> If you map appID:45 to SSRC B also in RTP header and afterwards have
>> appID:45 map to SSRC A it means that you replaced SSRC B with SSRC A for
>> appId 45. The example is if appId 45 is the active speaker and it starts
>> from left camera with SSRC B and changes to right camera with SSRC A.
>> 
>> What is allowed is to have appID 45 and appID 27 both map to SSRC A. example
>> is appID 45 is active speaker and appID 27 is left camera and left camera is
>> the current active speaker.
> 
> Roni,
> 
> we are not communicating; I may not have expressed myself clearly.
> 
> my question was "what's the scope of uniqueness for appIDs?"
> 
> That is - within what context can I assume that two appIDs are different
> if they serve different purposes or identify different things - and what
> control point inside that context guarantees the uniqueness?
> 
> I can imagine much confusion resulting from collision of appIDs, and
> want to know how I can be sure it won't happen.
> 
> 
>> 
>> Roni
>> 
>>> -----Original Message-----
>>> From: Harald Alvestrand [mailto:harald@alvestrand.no]
>>> Sent: 04 November, 2013 2:25 AM
>>> To: Roni Even; 'mmusic'
>>> Subject: Re: [MMUSIC] Some more APPID questions
>>> 
>>> On 11/03/2013 11:35 PM, Roni Even wrote:
>>>>> -----Original Message-----
>>>>> From: Harald Alvestrand [mailto:harald@alvestrand.no]
>>>>> Sent: 04 November, 2013 12:31 AM
>>>>> To: Roni Even; 'mmusic'
>>>>> Subject: Re: [MMUSIC] Some more APPID questions
>>>>> 
>>>>> On 11/03/2013 10:49 PM, Roni Even wrote:
>>>>>> Hi Harald,
>>>>>> The current draft is still not mature enough and the presentation
>>>>>> will have some information which is not there and some of the text
>>>>>> in the
>>>>>> 00 version that is not in the 01 version may come back.
>>>>>> 
>>>>>> An SSRC can have multiple appIds example is in a three camera system
>>>>>> one appID for active speaker which is now the left camera having a
>>>>>> different appID
>>>>>> 
>>>>>> The uniqueness of appID should be per media packet stream.
>>>>>> 
>>>>> so if you have
>>>>> 
>>>>> ssrc A: appid 45
>>>>> ssrc B: appid 27
>>>>> 
>>>>> this means exactly the same thing as
>>>>> 
>>>>> ssrc A: appid 45
>>>>> ssrc B: appid 45
>>>>> 
>>>>> ?
>>>>> 
>>>>> This seems to create issues when you have a single appid that is
>>>>> moving
>>>> around
>>>>> between SSRCs.
>>>> [Roni Even] The mapping from AppID to SSRC should be in SDES or RTP
>>>> header extension, example is appID 45 that can be first SSRC A and
>>>> then SSRC B if appId represent the active speaker.
>>>> 
>>> But if uniqueness of appids is per SSRC, then SSRC B might already be
>> using
>>> appid 45 for something else.
>>> 
>>> If we're using an appid for some property that can jump around between
>>> SSRCs, the uniqueness of that appid must be guaranteed over the whole
>> context
>>> it's jumping around inside, I think. I'm worried if I can't figure out
>> what that
>>> context is.
>>> 
>>> --
>>> Surveillance is pervasive. Go Dark.
> 
> 
> -- 
> Surveillance is pervasive. Go Dark.
> 
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
> 
> 