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

[Christer Holmberg <[e-mail]>]

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"
<[e-mail] on behalf of [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.)
>
>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