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

draft-ietf-avtext-sdes-hdr-ext discusses ways to notice reordering of packets carrying SDES header extensions (of which MID is an instance).  Is that text sufficient?

On Jul 20, 2016, at 1:36 PM, Miguel París Díaz <mparisdiaz@gmail.com<mailto:mparisdiaz@gmail.com>> wrote:

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<mailto: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<mailto:suhasietf@gmail.com>
Sent: ‎14/‎07/‎2016 18:43
To: Christer Holmberg<mailto:christer.holmberg@ericsson.com>
Cc: Iñaki Baz Castillo<mailto:ibc@aliax.net>; Jonathan Lennox<mailto:jonathan@vidyo.com>; mmusic<mailto:mmusic@ietf.org>; IETF AVTCore WG<mailto: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<mailto: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<mailto:mmusic@ietf.org>
https://www.ietf.org/mailman/listinfo/mmusic

_______________________________________________
mmusic mailing list
mmusic@ietf.org<mailto: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://www.kurento.org/>
http://twitter.com/mparisdiaz
------------------------------------------------------------------------