Re: [rtcweb] [MMUSIC] Extremely drafty minutes

[Ted Hardie <[e-mail]>]

On Tue, Mar 5, 2013 at 9:06 AM, Charles Eckel (eckelcu)
<[e-mail]> wrote:

> One question I have is in regard to the following point from the Feb 5 summary.
>
> " All SSRCs related to a single peer connection (which could encompasses more than one MediaStreams having more than one track) would come from a single SSRC space. "
>
> Is this a restatement of an opinion expressed at the mic, or does it carry some weight as a working group consensus? I recall discussion in this area, but I did not think consensus was reached that this is the way to go. If that is the case, I think the notes should mention that more discussion is needed.
>

My understanding of this is that it was expressed as a requirement by
WebRTC on the work of RTCWEB, needed as part
of the mechanics of how to plumb connections via the API.  The base
requirement is "a consistent identifer space for all the
media that will be plumbed"; the SSRCs are the identifiers available.
I may be mis-stating this, though, so it might be helpful
if Stefan or Harald commented, as I think it was one of them that
actually expressed it.

As context for those who might be able to add their own understanding
here, this is the relevant part of the draft
minutes:

For signaling, among the points raised:  CLUE and RTCWEB likely have
two different usage patterns.
For CLUE, multiple media sources will be common, multiple encodings
per media source will be the norm,
multiple endpoints may be visible even in unicast transport, and there
may be one or more RTP session.
For RTCWEB, the current theory is that there is a single RTP session
per media type,
if not a single RTP session full stop.  All SSRCs related to a single
peer connection (which could
encompasses more than one MediaStreams having more than one track)
would come from a single
SSRC space.

regards,

Ted