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

Hello Jonathan,
Do you mean to add MID SDES Item [1] using SDES header extensions [2] and
also extends that to provide the "version"?
If we use this approach, RTP MID Header Extension [3] would be useless,
wouldn't it?

Anyway, could you expand your idea to show how would you solve the race
condition problem?

Best!!

Refs
[1]
https://tools.ietf.org/html/draft-ietf-mmusic-sdp-bundle-negotiation-31#section-14.2
[2] https://tools.ietf.org/html/draft-ietf-avtext-sdes-hdr-ext-07
[3]
https://tools.ietf.org/html/draft-ietf-mmusic-sdp-bundle-negotiation-31#section-14.3

2016-07-20 17:46 GMT+02:00 Jonathan Lennox <jonathan@vidyo.com>:

> 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>
> 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>:
>
>> 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
> ------------------------------------------------------------------------
>
>
>

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