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

From: Christer Holmberg <[email-masked]>
Date: Wed, 13 Jul 2016 07:24:03 +0000

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?

Regards,

Christer

On 08/07/16 01:36, "mmusic on behalf of Jonathan Lennox"
<[email-masked] on behalf of [email-masked]> 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
>[email-masked]
>https://www.ietf.org/mailman/listinfo/mmusic

---

From: Jonathan Lennox <[email-masked]>
Date: Wed, 13 Jul 2016 14:16:04 +0000

> On Jul 13, 2016, at 3:24 AM, Christer Holmberg <[email-masked]> wrote:
> 
> Hi,
> 
> If the łboss˛ and łloudest speaker˛ m- lines are non-bundled, both RTP

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.)
>> send e-mail to the list but hadnąt remembered to get around to it until
>> now.)
>> 
>> 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 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
>> precludes any RTP middlebox topology which doesnąt rewrite SSRC values,
>> I certainly donąt think this is something that should block BUNDLEąs
>> youąd just need to negotiate that you support it.  But Iąm not wedded to
>> this solution.)
>>