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

[Christian Groves <[e-mail]>]

I agree for CLUE the RTP sender doesn't really know how long it will be 
sending the two MIDs for. Its the peer endpoint that initiates a CLUE 
configure that results in a particular RTP stream/s being sent.

You could have a situations where more than two RTP streams could be 
sent. E.g. Capture 1: See Boss, Capture 2: See active speaker, Capture 
3: 2nd previous speaker Capture 4: 3rd previous speaker. Where the boss 
is the active and 3rd previous speaker. So I don't think you can limit 
the use to two MIDs.

It seems like allowing multiple MIDs is a reasonable solution.

Christian


On 13/07/2016 2:42 AM, Jonathan Lennox wrote:
>
>> On Jul 11, 2016, at 1:42 PM, Peter Thatcher <[e-mail] 
>> <mailto:[e-mail]>> wrote:
>>
>> 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).
>
> The thing is, all MID values are, conceptually, temporary — they can 
> change at any time.  So is it really meaningful to distinguish 
> short-term temporary from long-term temporary?  Where do you draw the 
> line?
>
>> On Fri, Jul 8, 2016 at 8:51 AM, Jonathan Lennox <[e-mail] 
>> <mailto:[e-mail]>> 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
>>>     <[e-mail] <mailto:[e-mail]>> 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
>>>     <[e-mail] <mailto:[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] <mailto:[e-mail]>
>>>         https://www.ietf.org/mailman/listinfo/mmusic
>>>
>>>
>>
>>
>>     _______________________________________________
>>     mmusic mailing list
>>     [e-mail] <mailto:[e-mail]>
>>     https://www.ietf.org/mailman/listinfo/mmusic
>>
>>
>
>
>
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic