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

> On Jul 13, 2016, at 3:24 AM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:
> 
> Hi,
> 
> I assume this would only work for bundled m- lines, right?
> 
> If the łboss˛ and łloudest speaker˛ m- lines are non-bundled, both RTP
> streams would be sent even if they are identical, or?

Yes, that’s right, you’d have no choice but to duplicate the packets in that case. (But if you’re in a non-SSRC-changing topology, you can re-use the same SSRC for the two non-bundled sources.)
> 
> Regards,
> 
> Christer
> 
> 
> On 08/07/16 01:36, "mmusic on behalf of Jonathan Lennox"
> <mmusic-bounces@ietf.org on behalf of 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
>