Re: [rtcweb] Plan A, respun

[Paul Kyzivat <[e-mail]>]

On 5/7/13 4:00 PM, Adam Roach wrote:
> On 5/7/13 14:29, Paul Kyzivat wrote:
>> If I bundle an m-line without a=ssrc, and with unique PTs, do you
>> consider it ok if there are multiple "anonymous" flows each complying
>> to the attributes of the m-line?
>
> I presume, by "multiple anonymous flows," you mean multiple series of
> packets with the same PT, but with different SSRC values.
>
>> Or do you assume that all packets with that PT are treated as one
>> flow, switching from one SSRC to another as they are received?
>
> In the example you gave, all of those packets are defined to be
> associated with the same media line. Looking at basic principles, the
> intention here is that the semantics would be identical to non-webrtc,
> non-bundle clients receiving multiple SSRCs on the same port.
> Admittedly, those semantics have never been crystal clear, but my
> experience is that most systems would use this approach to send multiple
> streams that are semantically the same "thing" and should be rendered as
> one "thing" (e.g., window, speaker, etc).
>
> Specifically, we are *not* trying to allow the situation in which (1)
> the SDP has no SSRC for the m-lines in a bundle group; (2) the party who
> generated the SDP receives multiple streams (distinguished, presumably,
> by SSRC) with the same PT, and (3) the recipient then deduces that there
> should be two different rendering outputs (e.g., windows) as a result.
> That is specifically and intentionally one of the behaviors we removed
> from the Orlando proposal, since it severely dilutes the value of
> preserving existing SDP semantics.
>
> Does that answer the question you're answering?

Yes, that exactly answers the question I was asking.

It fits a clue case, of a "dynamic switched capture", where a single 
logical flow (capture) may be conveyed via unknown SSRCs.

But it doesn't cope well with a case where there a several of those, 
because each will require distinct PTs, and that may not work.

To adequately cover that, I think we need the potential to signal a 
*different* demux algorithm, instead of PT or SSRC. (We are assuming a 
new RTP header extension).

Bottom line, instead of saying the demux is by ssrc if present, and 
otherwise by PT, I suggest that we explicitly signal the demux 
mechanism, with options being at least those, plus another one once we 
get it defined.

Otherwise I think what you are proposing can work for CLUE.

	Thanks,
	Paul