Re: [MMUSIC] Some more thoughts on the simulcast discussion

[Paul Kyzivat <[e-mail]>]

On 10/14/15 3:10 AM, Harald Alvestrand wrote:
> This note is in response to yesterday's simulcast discussion. It's not
> directly related to the current proposals, and doesn't criticize or
> suggest changes to them in detail; it's more of a "step back".
>
> It seems to me that simulcast is just the latest iteration of a
> recurring problem, which can be roughly described as
>
>    HOW DO WE SPECIFY CONSTRAINTS ON A MEDIA STREAM?

+1

IIUC this is a result of lack of precision in SDP regarding what it is 
describing.

> It seems to me also that we've consistently failed to come up with
> viable, reusable, architecturally clean solutions to this problem. So
> perhaps it's time to step back.
>
> The problem can be broken into three logical parts:
>
> - WHICH media stream(s) are we talking about?
> - WHAT constraints do we want to describe for it?
> - WHEN do we want these constraints to apply?
>
> The first question (WHICH) has often been answered with "media section",
> "ssrc", "payload type" or "payload type inside a media section"; the
> current debate suggests adding "rid" to the mix. SSRC is said to be
> unsuitable because the rules say that other session participants can
> force you to change your SSRC by colliding with it.

Not necessarily which streams - rather *what things*.

The identifiers you list don't all identify the same sort of things.

I think it is necessary to go to draft-ietf-avtext-rtp-grouping-taxonomy 
and sort out which things in SDP identify which things there.

What seems clear is that SDP doesn't get the granularity right about the 
stuff it can reference. So people end up using things that aren't quite 
right, and adjusting their usage to align with what it is possible to 
describe.

	Thanks,
	Paul

> The second question has had numerous answers, all with slightly
> different syntax and semantics:
>
> - fmtp parameters (which don't have agreed-upon cross-codec syntax)
> - a=imageattr parameters
> - b=, a=ptime, lots of ad hoc parameters
> - the COP proposal
> - the current rid proposal
>
> The third question includes answers of "after (re)negotiation", "at
> random times signalled in RTP" (the COP proposal), "whenever a stream is
> active (it can be paused)" and so on. It also includes the question of
> "who decides" - at the moment, proposals seem to be of the form
> "proposer sets the limits, responder can accept these limits or propose
> tighter ones; responder's limits are always accepted", but that's not
> the only way this can be imagined - even within the confines of SDP usage.
>
> Lapsing into similes: It seems to me that we would be better off if we
> could avoid inventing more incompatible drive trains and making sure we
> have a reusable wheel and a reusable gearbox.
>
>       Harald
>
>
>
>
>
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
>