Subject: [MMUSIC] draft-roach-mmusic-unified-plan-00

From: Paul Kyzivat <[email-masked]>
Date: Wed, 24 Jul 2013 11:55:12 -0400

Some comments after carefully rereading this draft:

Section 3.2.1 says:

    A different problem can arise when interoperating with legacy
    equipment.  A number of circumstances can lead to the inability of a
    legacy endpoint to include SSRC information in its SDP.  For example,
    in a system that decomposes signaling and media into different
    network devices, the protocol used to communicate between the boxes
    frequently will not include SSRC information, making it impossible to
    include in the SDP.  If these devices choose to implement bundling,
    correlation of media streams to m-lines requires an alternate
    correlator.

    These cases (and possibly other similar situations) can be
    ameliorated by using information in the media stream itself as a
    correlator to the SDP offer.  If a packet arrives with an SSRC that
    is not yet associated with an m-line, we would ideally have some
    means of correlating it prior to the arrival of the answer.

    The authors reiterate and emphasize that this technique is used
    solely for the purposes of correlation of an RTP stream to an SDP
    m-line after that stream has already been demultiplexed.
    Demultiplexing of multiple streams on a single transport address
    continues to be based on SSRC values.

This suggests that it is only a problem with legacy devices, but I think 
that is not so. E.g., media can outrun the answer in all cases.

It also seems to exclude the possibility that in some cases we might 
*want* a particular SSRC to be associated with different m-lines over 
time. This is a case that actually comes up in CLUE:

We have an MCU that is providing multiple capture-encodings to a 
consumer for rendering. I think that with the unified plan CLUE would 
map a capture-encoding (conceptually similar to a media stream track) to 
an m-line, and that this would then be rendered to a particular device 
or window.

But the captures being delivered by the MCU may be "switched". For 
instance, one capture-encoding might represent the image of the loudest 
speaker, and another an image of the 2nd loudest speaker. When a 
particular speaker moves from being loudest speaker to 2nd loudest, the 
MCU will want to move the SSRC for the image of that speaker from one 
capture-encoding to another - and hence from one m-line to another.

This seems to be excluded, except by sending a new O/A every time the 
speaker switches, which isn't feasible. If this means that CLUE can't 
represent capture-encodings as m-lines, then there is no benefit to CLUE 
for the unified plan over No Plan (Emil's multiple-sources draft).

Section 3.2.2/3.2.3:

IMO the primary justification for the various multiple-m-line approaches 
is that then one can presume to first associate a packet to an m-line, 
and then transitively associate all the attributes of that m-line with 
that packet. What you describe here is a special case of that.

The unified plan has a spin on this. You preferentially use the SSRC to 
associate a packet to an m-line, and only use other properties of a 
packet if the SSRC-m-line association isn't yet known. But as mentioned 
above, that is a limitation.

Section 3.3:

This falls back to dependency on signaling specific SSRCs. I don't see 
how the other correlation mechanisms mentioned earlier can be employed 
with these features. That can mean confusion for media received before 
the answer.

	Thanks,
	Paul

---

From: Adam Roach <[email-masked]>
Date: Wed, 24 Jul 2013 11:03:25 -0500

On 7/24/13 10:55, Paul Kyzivat wrote:
> represent capture-encodings as m-lines, then there is no benefit to 
> CLUE for the unified plan over No Plan (Emil's multiple-sources draft). 

That's interesting. I wonder whether we should simply move to the RTP 
header extension described in section 3.2.1.1 as the primary means of 
correlation. It would seem to address the case you describe.

/a

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Thu, 25 Jul 2013 23:41:31 +0000

On Jul 24, 2013, at 10:03 AM, Adam Roach <[email-masked]> wrote:

>> This seems to be excluded, except by sending a new O/A every time the speaker switches, which isn't feasible. If this means that CLUE can't represent capture-encodings as m-lines, then there is no benefit to CLUE for the unified plan over No Plan (Emil's multiple-sources draft). 
> 
> That's interesting. I wonder whether we should simply move to the RTP header extension described in section 3.2.1.1 as the primary means of correlation. It would seem to address the case you describe.
> 
> /a

SSRC can collide too so they might be wrong but the  header extension does not have that problem. It seems to me the algorithm is roughly

if you have  header extension, use that, if not then if you know the SSRC use that, if not then if you have unique PTs, use that. Perhaps there are other things to use too but roughly those get used in that order.

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 25 Jul 2013 20:19:39 -0400

> if you have  header extension, use that, if not then if you know the SSRC use that, if not then if you have unique PTs, use that. Perhaps there are other things to use too but roughly those get use…

I commented on this before. You don't need to have an ordering.

If the combination of things you have is unique, use that. If not, then 
you have a problem.

	Thanks,
	Paul

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Fri, 26 Jul 2013 12:04:50 +0000

On Jul 25, 2013, at 6:19 PM, Paul Kyzivat <[email-masked]> wrote:

> If the combination of things you have is unique, use that. If not, then you have a problem.
> 

That would be fine with me too.