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

From: Harald Alvestrand <[email-masked]>
Date: Wed, 14 Oct 2015 09:10:43 +0200

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?

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.

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

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 14 Oct 2015 13:00:23 -0400

>    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.

> 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

> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 14 Oct 2015 22:28:05 +0200

> 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.

-- 
Surveillance is pervasive. Go Dark.

---

From: Adam Roach <[email-masked]>
Date: Thu, 15 Oct 2015 15:46:55 -0500

> We are worrying about the same set of issues.

This is actually the exact problem that RID seeks to solve: by defining 
a new construct rather than trying to leverage existing ones (which, as 
you observe, end up being ill-fitting in many cases), we are able to 
point quite precisely at the *thing* of interest, instead of obliquely 
waving at some badly-matched proxy for that thing.

/a

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 15 Oct 2015 23:00:53 +0200

On 10/15/2015 10:46 PM, Adam Roach wrote:
> This is actually the exact problem that RID seeks to solve: by
> defining a new construct rather than trying to leverage existing ones
> (which, as you observe, end up being ill-fitting in many cases), we
> are able to point quite precisely at the *thing* of interest, instead
> of obliquely waving at some badly-matched proxy for that thing.

That is the good thing about RID: That it is able to point precisely at
one specific media stream.
[distraction: can two media streams have the same RID but different
SSRCs? What does that mean if it's legal? Where do we enforce the
restriction if it's illegal?]

That was also the good thing about a=SSRC (modulo the collision problem).

Now we "only" have to define:

- What exactly we can state about the thing we're pointing at
- What language(s) we use to make those statements
- How those statements are resolved against all the *other* tools inside
SDP that can be used to make statements about things that might also
happen to refer to the thing we're pointing at.

It's possible that we can define RID in such a way that the answers are
simple enough that they can be written down and agreed upon quickly.

But I can't see us succeeding without at least considering the issues.

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 15 Oct 2015 17:43:23 -0400

> one specific media stream.

I think we should carefully identify what we are talking about within 
the terminology of the taxonomy document.

> restriction if it's illegal?]

That is an important thing to resolve.

> happen to refer to the thing we're pointing at.

This last point is important. (And hard.)

> But I can't see us succeeding without at least considering the issues.

Yup.

	Thanks,
	Paul

---

From: Jonathan Lennox <[email-masked]>
Date: Thu, 15 Oct 2015 22:02:20 +0000

> On Oct 15, 2015, at 5:00 PM, Harald Alvestrand <[email-masked]> wrote:
> 

I think only one encoded (or dependent) stream at a time can have a given RID value, but the mapping between RID and stream will change over time. (For the Selective Forwarding Unit RTP topology, it may change quickly, as in at speaker-switch speeds.)

However, a redundancy stream (FEC or RTX) will share the same RID value as the stream it’s protecting.

---

From: Bo Burman <[email-masked]>
Date: Sat, 17 Oct 2015 17:35:40 +0000

> However, a redundancy stream (FEC or RTX) will share the same RID value as the stream it’s protecting.
For RTX, that seems reasonable, since RTX is just a time-shifted repetition of something already having a RID.

If it is reasonable for FEC depends on what "entity" we decide a RID to describe.

Specifically, what about a FEC stream that protects multiple RTP streams; should it then be marked with multiple RIDs? That would mean that not only can different RTP streams share the same RID (although maybe not at once, but only time-multiplexed, if going with Jonathan's proposal), but a single (FEC) RTP stream would then also have multiple RIDs at once.

> -----Original Message-----
> From: mmusic [mailto:[email-masked]] On Behalf Of Jonathan Lennox
> Sent: den 16 oktober 2015 00:02
> To: Harald Alvestrand
> Cc: mmusic
> Subject: Re: [MMUSIC] Some more thoughts on the simulcast discussion
> 
> 
> I think only one encoded (or dependent) stream at a time can have a given RID value, but the mapping between RID and
> stream will change over time. (For the Selective Forwarding Unit RTP topology, it may change quickly, as in at speaker-
> switch speeds.)
>