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

[Harald Alvestrand <[e-mail]>]

On 10/14/2015 07:00 PM, Paul Kyzivat wrote:
> 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.
Yes.
I was using the term "media stream" without checking grouping-taxonomy
first; I intended it to mean "the lowest unit of stream-like thing", and
was using the plural deliberately; both media sections and payload types
can describe multiples of these 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.

We are worrying about the same set of issues.

>
>     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
>>
>
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic


-- 
Surveillance is pervasive. Go Dark.