Re: [rtcweb] Plan A, respun

["Roni Even" <[e-mail]>]

Hi Paul,
The problem in the CLUE case in the example you gave is that the receiver
will get an RTP stream with a new SSRC not in the SDP  to the same port and
will need to know how to map it to one of the media capture replacing the
previous one.
I think that this mode can work in plan B as an additional case, multiple
RTP streams in an m-line but the SSRC or mapping to media capture is done
via RTP header extension. For plan A it works only if it will allow multiple
RTP streams based on the same m-line.  The assumption in both cases is that
both sides identify that they understand this specific usage, for example,
by support of the specific header extension

Roni 

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of
Paul Kyzivat
Sent: 08 May, 2013 12:10 AM
To: Adam Roach
Cc: [e-mail]
Subject: Re: [rtcweb] Plan A, respun

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

_______________________________________________
rtcweb mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/rtcweb