Re: [MMUSIC] [AVTCORE] BUNDLE: a single stream with multiple MIDs?

Hello,
thinking a bit about that idea, if we support that different RTP streams
have the same MID, we should provide a kind of version to deal with race
conditions.

Taking the example of “the current loudest speaker” (LS) , if the middle
box switches many times Alice <-> Bob streams the endpoint receiving the
RTP streams may show the incorrect loudest-speaker due to processing an RTP
stream before the other one (network, race condition into the endpoint,
etc.)

Imagine that case:
MidleBox side: Alice LS -> Bob LS -> Alice LS
Endpoint side: Process Alice as LS -> Process Alice LS -> Process Bob LS

At the end the endpoint would render Bob as LS, but it is wrong.

To fix this race condition problem I propose adding a version:
MidleBox side: Alice LS-0 -> Bob LS-1 -> Alice LS-2
Endpoint side: Process Alice as LS-0 -> Process Alice LS-2 -> Process Bob
LS-1 (discarded because 1<2)

What do you think about that?

Best regards!!

2016-07-14 17:49 GMT+02:00 Christer Holmberg <christer.holmberg@ericsson.com
>:

> Hi,
>
> You don't need a common logic. You can define an application layer
> protocol (e.g. CLUE) to define/configure/negotiate these kind of things.
>
> Regards,
>
> Christer
>
> Sent from my Windows Phone
> ------------------------------
> From: Suhas Nandakumar <suhasietf@gmail.com>
> Sent: ‎14/‎07/‎2016 18:43
> To: Christer Holmberg <christer.holmberg@ericsson.com>
> Cc: Iñaki Baz Castillo <ibc@aliax.net>; Jonathan Lennox
> <jonathan@vidyo.com>; mmusic <mmusic@ietf.org>; IETF AVTCore WG
> <avt@ietf.org>
> Subject: Re: [MMUSIC] [AVTCORE] BUNDLE: a single stream with multiple
> MIDs?
>
>
>
> On Thu, Jul 14, 2016 at 3:27 PM, Christer Holmberg <
> christer.holmberg@ericsson.com> wrote:
>
>>
>> >...
>> >
>> >The current proposal breaks that. Please let's MID to be a single,
>> >unique and mandatory attribute per m-line.
>>
>>
>> Šand let each RTP packet be associated with one, and only one, of those
>> MIDs/m-lines.
>>
>>
>> You can then have application logic saying e.g. ³If no Œloudest-speaker¹
>> media is received, then duplicate the Œboss¹ media on the screen
>> associated with the loudest speaker². It¹s much more flexible, and without
>> any of the constraints mentioned earlier.
>>
>>
> I agree it brings in flexibility and it scares me a bit as well .. Each
> application needs to define their own logic or need a common logic across
> all applications ..
>
>
>
>>
>> Regards,
>>
>> Christer
>>
>> _______________________________________________
>> mmusic mailing list
>> mmusic@ietf.org
>> https://www.ietf.org/mailman/listinfo/mmusic
>>
>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>
>

-- 
Miguel París Díaz
------------------------------------------------------------------------
Computer/Software engineer.
Researcher and architect in http://www.kurento.org
http://twitter.com/mparisdiaz
------------------------------------------------------------------------