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

[Christer Holmberg <[e-mail]>]

Hi,

First, would this really be worth the effort?

It’s true that sending two identical streams (in Jonathan’s case where “boss” and “loudest speaker” are the same persons) is a resource waste. But, the needed resources must be available anyway, as the “loudest speaker” can change at any time.

Also, there seems to be so many constraints (the codecs, payload types etc must overlap), so the question is whether it would be usable to begin with.


Second, IF we want to do something like this, should it instead be done on a higher application/CLUE layer?  Why start mixing up the lower-layer MID semantics etc?

Regards,

Christer

From: avt <[e-mail]<mailto:[e-mail]>> on behalf of "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Date: Wednesday 13 July 2016 at 21:14
To: Jonathan Lennox <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: [AVTCORE] [MMUSIC] BUNDLE: a single stream with multiple MIDs?



On Tue, Jul 12, 2016 at 9:42 AM, Jonathan Lennox <[e-mail]<mailto:[e-mail]>> wrote:

On Jul 11, 2016, at 1:42 PM, Peter Thatcher <[e-mail]<mailto:[e-mail]><mailto:[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?

​That doesn't match my mental model of MIDs.   I've always thought of an RTP stream as being bound to a particular MID, not able to change between various MIDs.  I might be wrong, but it seems like there are weird edge cases with switching MIDs, such as how RIDs play into it (since they are scoped to MIDs).  Another is the demux algorithm in WebRTC/ORTC which "locks on" to SSRCs and only looks at MIDs if the SSRCs are unknown (the demux algorithm certainly does not take into account demuxing a packet into multiple RtpReceivers).

So it sounds like you are asking for two things:
1.  Be able to switch MIDs
2.  Be able to have > 1 MIDs.

And both of those blow up my mental model of MIDs and could cause problems with other things.


I think it would be less risky to define a separate header extension for "multiplicity of changable MIDs" rather than re-using the existing header extension, when the semantics seems so much different (than my mental model, at least).



On Fri, Jul 8, 2016 at 8:51 AM, Jonathan Lennox <[e-mail]<mailto:[e-mail]><mailto:[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]><mailto:[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]><mailto:[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]><mailto:[e-mail]<mailto:[e-mail]>>
https://www.ietf.org/mailman/listinfo/mmusic



_______________________________________________
mmusic mailing list
[e-mail]<mailto:[e-mail]><mailto:[e-mail]<mailto:[e-mail]>>
https://www.ietf.org/mailman/listinfo/mmusic