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

Basically what your're asking for is header extension that says "Not only
am I MID X, but I'm also, temporarily, MID Y"?   Why not just have a
second, separate, header extension for "I'm also temporarily MID Y"?   Then
the existing semantics of BUNDLE and MID (and RIDs, which are scoped to
MIDs) need not change, but you get the information you need (I think).

On Fri, Jul 8, 2016 at 8:51 AM, Jonathan Lennox <jonathan@vidyo.com> wrote:

> The intention of my proposal is that these could indeed be (temporarily)
> the same RTP media source, even though they’re two separate m-lines.
>
> On Jul 7, 2016, at 8:52 PM, Suhas Nandakumar <suhasietf@gmail.com> wrote:
>
> Hi Jonathan
>
>   Clarification question :
>
>    if we have 2 m=lines
>
> m = ...
> a=mid1
> <manager>
>
> m=...
> a=mid2
> <loudest speaker>
>
> does these 2 correspond to same media source ? It felt so from the
> duplicate design you mentioned but wanted to confirm
>
> Thanks
> Suhas
>
>
>
> On Fri, Jul 8, 2016 at 4:06 AM, Jonathan Lennox <jonathan@vidyo.com>
> wrote:
>
>> Hi, all —
>>
>> (This was an issue I raised in AVTCORE in Buenos Aires — I promised to
>> send e-mail to the list but hadn’t remembered to get around to it until
>> now.)
>>
>> When finishing up the CLUE RTP mapping draft, I realized that one of
>> CLUE’s RTP requirements didn’t actually end up getting satisfied by BUNDLE
>> (which is the solution CLUE converged on).  This isn’t a CLUE-specific
>> issue, so I’m raising it here.
>>
>> The issue is whether we want to support a use case, in BUNDLE, where a
>> single RTP stream corresponds to more than media description (and thus has
>> more than one MID value)?
>>
>> The use case is where one m-line has a semantic of “always view this
>> person” (my boss, say, or my customer); and another m-line has a semantic
>> of “the current loudest speaker”. (In CLUE, these would be a single content
>> capture in the former case, and a switched capture for the latter.)
>> Whenever the boss *is* the current loudest speaker, the same content would
>> be sent for both m-lines.
>>
>> A naive implementation would simply duplicate all the packets for the two
>> m-lines, with different MID values, but this has two problems.  First off
>> all, it obviously wastes bandwidth.  Potentially more seriously, it
>> precludes any RTP middlebox topology which doesn’t rewrite SSRC values,
>> since the same content (arriving with a single SSRC value at the middlebox)
>> would need to be sent with two different SSRC values down from the
>> middlebox.  If PERC goes with its current consensus of no SSRC rewriting,
>> this will particularly be a problem for PERC.
>>
>> I certainly don’t think this is something that should block BUNDLE’s
>> completion, but I think it could be a pretty easy extension.
>>
>> (My initial design proposal was to allow multiple SDES values of the same
>> type, and multiple SDES header extensions items of the same type, to be
>> sent simultaneously in RTP — protocol-syntactically this is trivial, you’d
>> just need to negotiate that you support it.  But I’m not wedded to this
>> solution.)
>>
>> What do people think — is this worth working on?  Is there interest in
>> discussing it in Berlin, and if so, in what venue?
>> _______________________________________________
>> 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
>
>