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

[Suhas Nandakumar <[e-mail]>]

On Wed, Jul 13, 2016 at 8:28 PM, Jonathan Lennox <[e-mail]> wrote:

>
> On Jul 13, 2016, at 10:50 AM, Suhas Nandakumar <[e-mail]>
> wrote:
>
>
>
> On Fri, Jul 8, 2016 at 4:06 AM, Jonathan Lennox <[e-mail]>
> 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.)
>>
>>
> Thinking a bit more on this .. it seems like a nice way forward . I agree
> with Magnus that it needs a way for the recipient to understand
> addition/removal of an item from the set ..
>
>
> My thinking was that you always send the complete set, if you send any MID
> at all. Thus, when you go from 2 MIDs to 1 MID, you send 1 MID, and the
> receiver knows that the other MID no longer applies.  (This rule applies
> both for header extensions and SDES items.)
>

Agreed..  That's the point i was probably trying to make in my example
earlier. There might be few explanations needed on handling as you implied.


> If the set represent duplicates , then when the boss is the loud speaker,
> the set will contain 2 mids .. when the loudest speaker is not the boss,
> the set will have just one item in this example and the receiver will do
> the normal processing of the loudest speaker .. From the mux point of view
> these MIDs must be IDENTICAL-PER-PT
>
>
> Right.
>
>
>
>
>> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mmusic
>>
>
>
>