Re: [MMUSIC] Some more APPID questions

[Harald Alvestrand <[e-mail]>]

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:[e-mail]]
>> 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:[e-mail]]
>>>> 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.