Subject: Re: [avtext] WGLC: draft-ietf-avtext-rid-01.txt

From: Adam Roach <[email-masked]>
Date: Sun, 3 Apr 2016 11:59:17 -0300

On 3/31/16 11:30, Magnus Westerlund wrote:
> Hi,
>
> Here are my comments on the draft-ietf-avtext-rid-01. I think it is 
> very good that we have an upcoming meeting where we can discuss the 
> below issues.
>
> 1. Abstract:
>
>    This document defines and registers an RTCP SDES item, RID, for
>    identification of RTP streams associated with Encoded Streams and
>    Dependent Streams.
>
> Should this really use plural of RTP streams as well as Encoded 
> Streams. A particular RID value is the identifier for one Encoded or 
> Dependent Stream in its RTP packetized form plus. Thus I think this 
> abstract could be clearer.  However, I think it may need to addressed 
> anyway based on comment 3 and 4.

No; grammatically, what's in there makes sense. It might not be as 
obvious because we're talking about abstract concepts rather than 
concrete nouns, but this sentence is grammatically parallel to "This 
document defines and registers a metal label, called a "license plate", 
for identification of cars associated with drivers and passengers." 
(Yes, this isn't what license plates do, but I'm clarifying the 
grammatical structure, not the meaning).

>
> 2. Section 1:
>
> RTP sessions frequently consist of multiple streams, each of which is
>    identified at any given time by its SSRC; however, the SSRC
>    associated with a stream is not guaranteed to be stable over its
>    lifetime.  Within a session, these streams can be tagged with a
>    number of identifiers, including CNAMEs and MSIDs
>    [I-D.ietf-mmusic-msid].  Unfortunately, none of these have the proper
>    ordinality to refer to an individual stream; all such identifiers can
>    appear in more than one stream at a time.  While approaches that use
>    unique Payload Types (PTs) per stream have been used in some
>    applications,
>
> I think the usage of Stream should at least on the first usage say 
> "RTP Stream" and with a reference to RFC7656 to make it clear what 
> entity you are discussing in this paragraph.

How about "RTP sessions frequently consist of mutiple RTP streams (see 
section 3), each of which..."?

> 3. Section 3:
>
>    For Encoded Streams, the RID refers to the "Source RTP Stream" as
>    defined by [RFC7656] Section 2.1.10.  For Dependent Streams, it
>    refers to the RTP Stream that, like the Source RTP Stream of an
>    Encoded Stream, is the RTP Stream that is not a Redundancy RTP
>    Stream.  For conciseness, we define the term "RID RTP Stream" to
>    refer to this construct.
>
> I think this definition is not correct. From my perspective it might 
> be better to talk about the RTP stream produced by the media 
> packetizer from a encoded or set of dependent streams. I write a set 
> of dependent stream as on RTP stream can be produced by packetizing 
> multiple dependent streams in the same. This would occur if one is not 
> producing different RTP streams for all produced scalability layers.
>
> However, the main issue is that the definition does not correctly 
> identifies what the RID refers to. To my understanding the RID refers 
> to one RTP stream [A] packetized from either one encoded stream and 
> zero or more dependent streams, or one or more dependent streams and 
> the one or more redundancy streams protecting the RTP stream [A].

For WebRTC simulcast, at least, this isn't what we need. If we have one 
encoded stream and two dependent streams, this needs to result in three 
RIDs (regardless of the presence or number of redundancy streams).

> This also has the consequence that RID RTP Stream is not a suitable 
> term as the RID identifies an possible aggregate of RTP streams, one 
> source and zero or more redundancy RTP streams.

We need some concise term here, and I don't care what it is. I would 
personally be happy happy to change the term to "Spicy Mango Surprise" 
if it got us to finished. I just want a well-defined term that means 
exactly this construct.

> 4. Section 3:
>
>    For clarity, when RID is used, Redundancy RTP Streams that can be
>    used to repair Received RTP Streams will use the same RID value as
>    the Received RTP Stream they are intended to be combined with. If
>    applications want to identify individual redundancy streams, they can
>    add an RRID to them instead of or in addition to the RID.
>
> So the intention with RRID, is to identify Redundancy RTP streams. 
> Considering that RID doesn't actually only represent the source RTP 
> stream for the media, there is a mismatch.

I'm confused. If I read the text you quoted above, it's pretty clear: 
"For Encoded Streams, the RID refers to the 'Source RTP Stream'". It 
then builds a parallel construct for dependent streams, but these are 
always going to have a different RID than their corresponding encoded 
streams.

> Also, the needs for RRID is also not clear, however, the basics of 
> identifying the RTP stream only has the advantage of high likelihood 
> of re-use in other mechanisms.

This came out of discussions with Colin, which I interpreted as a 
request to add a means to uniquely identify redundancy streams. The 
*current* discussion seems to be leaning toward removing RRID, although 
I'm waiting to hear from others on the topic still.

> Some may protest, hey but we are loosing the coupling method between 
> the source RTP stream and the Redundancy stream. Yes, I have a 
> proposal below for how to resolve that, but at the same time, it is 
> this coupling that creates the complicated definition of the RID SDES 
> item. And this is actually quite a separate problem. One which has 
> existed for some time, and may actually benefit from being taken on a 
> separate work item. Especially as we may want to retrofit the outcome 
> onto some existing mechanisms such as RTP Retransmission and Generic 
> XOR FEC to enable single RTP session usage efficiently for both.
>
> So below is a possible solution if one desire to have a way of 
> coupling the redundancy stream to the source RTP stream already in 
> signalling and identifying it with the same properties as we get with 
> RID for the Source RTP streams.
>
> The solution is simple, we simply have a=RID lines also for the 
> Redundancy RTP streams. Then we define a new constraint which I will 
> call "protect" which is a list of SIDs that points at one or more RTP 
> streams for which this Redundancy RTP Stream is constrained to protect 
> and provide redundancy for.

We already had several rounds of discussion on this topic, and I made a 
proposal that is functionally equivalent to what you're proposing.

The problem that was raised is that making this change forces the WebRTC 
API to expose multiple identifiers associated with a single WebRTC 
construct. Basically, you can make the protocol slightly more 
complicated and the API slightly simpler, or you can make the protocol 
slightly simpler and the API slightly more complicated. There are a 
couple of tie breakers here, both pointing to the API being simpler: (1) 
the API is already defined and effectively frozen (WebRTC is trying to 
get the document to stop changing so it can be published); and (2) the 
priority of constituencies 
(https://www.w3.org/TR/html-design-principles/#priority-of-constituencies) 
prioritizes authors over implementors in protocol trade-offs, and this 
calls for simplifying the API rather than the wire protocol. I recognize 
that this is a W3C principle rather than an IETF principle, but it 
remains sound advice in general.

> 5. Section 4 and 6.
>
> What I am missing in this is a discussion of privacy and the potential 
> for tracking the streams across an RTP system. This is usually fine, 
> but may reveal things to a third party, thus their value should be 
> protected towards third parties.

If you can point me to similar language in another document for SSRC, 
I'd be happy to copy it directly into this document.

> The next part of this issue is the generation of these values should 
> avoid leaking any information about the user and implementation. This 
> leads to the question if the values should be using random values, 
> with tag lengths as needed by the application.

In practice, since these are scoped to the sending endpoint, I would 
expect most implementations to use a very simple scheme, like a 
single-character representation that starts with "0", works through "9", 
and then steps up to "a" through "z", moving on to two-character 
identifiers if they use more than 36 streams.

/a

---

From: Colin Perkins <[email-masked]>
Date: Mon, 4 Apr 2016 11:28:01 +0100

> On 3 Apr 2016, at 15:59, Adam Roach <[email-masked]> wrote:
> 
>> Here are my comments on the draft-ietf-avtext-rid-01. I think it is very good that we have an upcoming meeting where we can discuss the below issues.
>> 
>> 1. Abstract:
>> 
>> Should this really use plural of RTP streams as well as Encoded Streams. A particular RID value is the identifier for one Encoded or Dependent Stream in its RTP packetized form plus. Thus I think this abstract could be clearer.  However, I think it may need to addressed anyway based on comment 3 and 4.
> 
> No; grammatically, what's in there makes sense. It might not be as obvious because we're talking about abstract concepts rather than concrete nouns, but this sentence is grammatically parallel to "This document defines and registers a metal label, called a "license plate", for identification of cars associated with drivers and passengers." (Yes, this isn't what license plates do, but I'm clarifying the grammatical structure, not the meaning).
> 
> 
>> 
>> 2. Section 1:
>> 
>> I think the usage of Stream should at least on the first usage say "RTP Stream" and with a reference to RFC7656 to make it clear what entity you are discussing in this paragraph.
> 
> How about "RTP sessions frequently consist of mutiple RTP streams (see section 3), each of which..."?
> 
> 
>> 3. Section 3:
>> 
>> I think this definition is not correct. From my perspective it might be better to talk about the RTP stream produced by the media packetizer from a encoded or set of dependent streams. I write a set of dependent stream as on RTP stream can be produced by packetizing multiple dependent streams in the same. This would occur if one is not producing different RTP streams for all produced scalability layers.
>> 
>> However, the main issue is that the definition does not correctly identifies what the RID refers to. To my understanding the RID refers to one RTP stream [A] packetized from either one encoded stream and zero or more dependent streams, or one or more dependent streams and the one or more redundancy streams protecting the RTP stream [A].
> 
> For WebRTC simulcast, at least, this isn't what we need. If we have one encoded stream and two dependent streams, this needs to result in three RIDs (regardless of the presence or number of redundancy streams).
> 
>> This also has the consequence that RID RTP Stream is not a suitable term as the RID identifies an possible aggregate of RTP streams, one source and zero or more redundancy RTP streams.
> 
> We need some concise term here, and I don't care what it is. I would personally be happy happy to change the term to "Spicy Mango Surprise" if it got us to finished. I just want a well-defined term that means exactly this construct.
> 
>> 4. Section 3:
>> 
>> So the intention with RRID, is to identify Redundancy RTP streams. Considering that RID doesn't actually only represent the source RTP stream for the media, there is a mismatch.
> 
> I'm confused. If I read the text you quoted above, it's pretty clear: "For Encoded Streams, the RID refers to the 'Source RTP Stream'". It then builds a parallel construct for dependent streams, but these are always going to have a different RID than their corresponding encoded streams.
> 
> 
>> Also, the needs for RRID is also not clear, however, the basics of identifying the RTP stream only has the advantage of high likelihood of re-use in other mechanisms.
> 
> This came out of discussions with Colin, which I interpreted as a request to add a means to uniquely identify redundancy streams.

I suggested that, if RID is being used, every RTP stream in an RTP session needs to have a unique RID. 

A consequence of that would be that a redundant RTP stream would have a different RID to the original RTP stream. However, that would be true of any two RTP streams.

> The *current* discussion seems to be leaning toward removing RRID, although I’m waiting to hear from others on the topic still.

I don’t see value in the RRID as specified. 

I do see value in defining an “associated RID” header extension. That would be a field that indicates a stream associated with the current stream. For example, if the main RTP stream had RID=XXX and the redundant RTP stream had RID=YYY, then the redundant RTP stream could also contain an “associated RID”=XXX header, to indicate which stream it is providing redundancy for. This is similar to Magnus’ current proposal (and the arguments for-and-against it were similar).

Colin

>> Some may protest, hey but we are loosing the coupling method between the source RTP stream and the Redundancy stream. Yes, I have a proposal below for how to resolve that, but at the same time, it is this coupling that creates the complicated definition of the RID SDES item. And this is actually quite a separate problem. One which has existed for some time, and may actually benefit from being taken on a separate work item. Especially as we may want to retrofit the outcome onto some existing mechanisms such as RTP Retransmission and Generic XOR FEC to enable single RTP session usage efficiently for both.
>> 
>> So below is a possible solution if one desire to have a way of coupling the redundancy stream to the source RTP stream already in signalling and identifying it with the same properties as we get with RID for the Source RTP streams.
>> 
>> The solution is simple, we simply have a=RID lines also for the Redundancy RTP streams. Then we define a new constraint which I will call "protect" which is a list of SIDs that points at one or more RTP streams for which this Redundancy RTP Stream is constrained to protect and provide redundancy for.
> 
> We already had several rounds of discussion on this topic, and I made a proposal that is functionally equivalent to what you're proposing.
> 
> The problem that was raised is that making this change forces the WebRTC API to expose multiple identifiers associated with a single WebRTC construct. Basically, you can make the protocol slightly more complicated and the API slightly simpler, or you can make the protocol slightly simpler and the API slightly more complicated. There are a couple of tie breakers here, both pointing to the API being simpler: (1) the API is already defined and effectively frozen (WebRTC is trying to get the document to stop changing so it can be published); and (2) the priority of constituencies (https://www.w3.org/TR/html-design-principles/#priority-of-constituencies) prioritizes authors over implementors in protocol trade-offs, and this calls for simplifying the API rather than the wire protocol. I recognize that this is a W3C principle rather than an IETF principle, but it remains sound advice in general.
> 
> 
>> 5. Section 4 and 6.
>> 
>> What I am missing in this is a discussion of privacy and the potential for tracking the streams across an RTP system. This is usually fine, but may reveal things to a third party, thus their value should be protected towards third parties.
> 
> If you can point me to similar language in another document for SSRC, I'd be happy to copy it directly into this document.
> 
>> The next part of this issue is the generation of these values should avoid leaking any information about the user and implementation. This leads to the question if the values should be using random values, with tag lengths as needed by the application.
> 
> In practice, since these are scoped to the sending endpoint, I would expect most implementations to use a very simple scheme, like a single-character representation that starts with "0", works through "9", and then steps up to "a" through "z", moving on to two-character identifiers if they use more than 36 streams.
> 
> /a
> 
> _______________________________________________
> avtext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avtext

-- 
Colin Perkins
https://csperkins.org/

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 4 Apr 2016 11:26:05 -0300

Hi,

Please see inline. I think there are some clarifications needed here.

> grammatical structure, not the meaning).

Ok

> section 3), each of which..."?

Yes, that is fine.

> RIDs (regardless of the presence or number of redundancy streams).

So there are some corner cases here, which is part of the issue. I agree 
that the most common case would be that a media encoder that produces 
one encoded stream and two dependent stream would in most cases be 
packetized as three different RTP streams. However, it is possible for 
some codecs to produce only one or two RTP streams from the above set of 
encoded and dependent streams. The following possibilities do exists:

1 RTP stream: Encoded stream + two dependent
2 RTP stream (alt A):
     First RTP stream = Encoded stream + dependent stream
     Second RTP stream = dependent stream
2 RTP stream (alt B):
    First RTP stream = Encoded stream
    Second RTP stream = both dependent stream

These possibilities in the RTP packetization is one thing that 
complicates the definition of the RID aggregate definition.

> if it got us to finished. I just want a well-defined term that means

Yes, lets first talk about what RID actually should be, the aggregate of 
the source RTP stream and the redundnacy stream or for an individual RTP 
stream, then we can go back to what we call this.

> always going to have a different RID than their corresponding encoded

So my understanding is that the RID actually represent the aggregate of 
the RTP source stream and the redundancy, from that perspective, term 
RTP stream Identifier is the wrong term.

> I'm waiting to hear from others on the topic still.

Yes, so I agree with leaning to removing the RRID concept, because I 
think there is not a clear need at this point. At the same time I think 
RID as an aggregate is a bad construct, and would rather have RID to 
only name one particular RTP Stream, not an aggregate.

> remains sound advice in general.

So I took a look at the W3C API where RID is mentioned and found the 
following definition in the current working draft:

rid of type DOMString

     If set, this RTP encoding will be sent with the RID header
     extension as defined by [JSEP].

So, to my understanding the RID in the API only points to the source RTP 
stream.

Thus I don't see a big issue with using a definition for RID is the ID 
for a single RTP stream. Then solving the redundancy stream binding 
using either of these two proposals:

1. Using a new RTP header extension that points on the source for the 
redundancy stream

2. Creating a new SDP RID constraint that allows a identified Redundancy 
stream to be bound in SDP to its source.

I am currently thinking either of these proposals do work.

> I'd be happy to copy it directly into this document.

So there are some language in RFC 7022 on the CNAME. I note that CNAMES 
usually have more persistence across middlebox than RID has, as that is 
likely negotiated on per leg level.

> identifiers if they use more than 36 streams.

Yes, I fully agree. But there should be some warning or consideration 
that the assignment can actually reveal some information of which 
implementation is setting it. And in worst case if based on user details 
be a privacy issue.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Peter Thatcher <[email-masked]>
Date: Mon, 4 Apr 2016 07:27:25 -0700

On Mon, Apr 4, 2016 at 3:28 AM, Colin Perkins <[email-masked]> wrote:

> very good that we have an upcoming meeting where we can discuss the below
> issues.
> >>
> >> 1. Abstract:
> >>
> obvious because we're talking about abstract concepts rather than concrete
> nouns, but this sentence is grammatically parallel to "This document
> defines and registers a metal label, called a "license plate", for
> identification of cars associated with drivers and passengers." (Yes, this
> isn't what license plates do, but I'm clarifying the grammatical structure,
> not the meaning).
> >
> >
> >>
> >> 2. Section 1:
> >>
> >> I think the usage of Stream should at least on the first usage say "RTP
> Stream" and with a reference to RFC7656 to make it clear what entity you
> are discussing in this paragraph.
> >
> >> I think this definition is not correct. From my perspective it might be
> better to talk about the RTP stream produced by the media packetizer from a
> encoded or set of dependent streams. I write a set of dependent stream as
> on RTP stream can be produced by packetizing multiple dependent streams in
> the same. This would occur if one is not producing different RTP streams
> for all produced scalability layers.
> >>
> identifies what the RID refers to. To my understanding the RID refers to
> one RTP stream [A] packetized from either one encoded stream and zero or
> more dependent streams, or one or more dependent streams and the one or
> more redundancy streams protecting the RTP stream [A].
> >
> term as the RID identifies an possible aggregate of RTP streams, one source
> and zero or more redundancy RTP streams.
> >
> personally be happy happy to change the term to "Spicy Mango Surprise" if
> it got us to finished. I just want a well-defined term that means exactly
> this construct.
> >
> >> 4. Section 3:
> >>
> Considering that RID doesn't actually only represent the source RTP stream
> for the media, there is a mismatch.
> >
> "For Encoded Streams, the RID refers to the 'Source RTP Stream'". It then
> builds a parallel construct for dependent streams, but these are always
> going to have a different RID than their corresponding encoded streams.
> >
> >
> identifying the RTP stream only has the advantage of high likelihood of
> re-use in other mechanisms.
> >
> request to add a means to uniquely identify redundancy streams.
>
​That's what Magnus is calling "SID", so let's stick with that name to
avoid confusion.​
​

> A consequence of that would be that a redundant RTP stream would have a
> different RID to the original RTP stream. However, that would be true of
> any two RTP streams.
>
> > The *current* discussion seems to be leaning toward removing RRID,
> although I’m waiting to hear from others on the topic still.
>
> I do see value in defining an “associated RID” header extension. That
> would be a field that indicates a stream associated with the current
> stream. For example, if the main RTP stream had RID=XXX and the redundant
> RTP stream had RID=YYY, then the redundant RTP stream could also contain an
> “associated RID”=XXX header, to indicate which stream it is providing
> redundancy for. This is similar to Magnus’ current proposal (and the
> arguments for-and-against it were similar).
>

​That's what RID is, basically.  It's the way for the Redundancy RTP Stream
to refer to the non-Redundancy RTP Stream.
​

> the source RTP stream and the Redundancy stream. Yes, I have a proposal
> below for how to resolve that, but at the same time, it is this coupling
> that creates the complicated definition of the RID SDES item. And this is
> actually quite a separate problem. One which has existed for some time, and
> may actually benefit from being taken on a separate work item. Especially
> as we may want to retrofit the outcome onto some existing mechanisms such
> as RTP Retransmission and Generic XOR FEC to enable single RTP session
> usage efficiently for both.
> >>
> >> So below is a possible solution if one desire to have a way of coupling
> the redundancy stream to the source RTP stream already in signalling and
> identifying it with the same properties as we get with RID for the Source
> RTP streams.
> >>
> Redundancy RTP streams. Then we define a new constraint which I will call
> "protect" which is a list of SIDs that points at one or more RTP streams
> for which this Redundancy RTP Stream is constrained to protect and provide
> redundancy for.
> >
> construct. Basically, you can make the protocol slightly more complicated
> and the API slightly simpler, or you can make the protocol slightly simpler
> and the API slightly more complicated. There are a couple of tie breakers
> here, both pointing to the API being simpler: (1) the API is already
> defined and effectively frozen (WebRTC is trying to get the document to
> stop changing so it can be published); and (2) the priority of
> constituencies (
> https://www.w3.org/TR/html-design-principles/#priority-of-constituencies)
> that this is a W3C principle rather than an IETF principle, but it remains
> sound advice in general.
> >
> >
> >> 5. Section 4 and 6.
> >>
> for tracking the streams across an RTP system. This is usually fine, but
> may reveal things to a third party, thus their value should be protected
> towards third parties.
> >
> avoid leaking any information about the user and implementation. This leads
> to the question if the values should be using random values, with tag
> lengths as needed by the application.
> >

---

From: Peter Thatcher <[email-masked]>
Date: Mon, 4 Apr 2016 07:29:48 -0700

On Mon, Apr 4, 2016 at 7:26 AM, Magnus Westerlund <
[email-masked]> wrote:

> that the most common case would be that a media encoder that produces one
> encoded stream and two dependent stream would in most cases be packetized
> as three different RTP streams. However, it is possible for some codecs to
> produce only one or two RTP streams from the above set of encoded and
> dependent streams. The following possibilities do exists:
>
> These possibilities in the RTP packetization is one thing that complicates
> the definition of the RID aggregate definition.
>
> the RTP source stream and the redundancy, from that perspective, term RTP
> stream Identifier is the wrong term.

​No, it does not represent the aggregate.  It represents one RTP Stream.  ​

> Yes, so I agree with leaning to removing the RRID concept, because I think
> there is not a clear need at this point. At the same time I think RID as an
> aggregate is a bad construct, and would rather have RID to only name one
> particular RTP Stream, not an aggregate.

​It's not an aggregate.
​

> Thus I don't see a big issue with using a definition for RID is the ID for
> a single RTP stream. Then solving the redundancy stream binding using
> either of these two proposals:
>

​That's what it is: one RTP Stream.​

> Yes, I fully agree. But there should be some warning or consideration that
> the assignment can actually reveal some information of which implementation
> is setting it. And in worst case if based on user details be a privacy
> issue.
>
>
> Cheers
>
> Magnus Westerlund
>

---

From: Peter Thatcher <[email-masked]>
Date: Mon, 4 Apr 2016 07:25:48 -0700

I think you can get what you want by simply renaming RRID to SID and having
the following definitions:

SID == "RTP Stream ID"
RID == "non-Redundancy RTP Stream ID"

For a non-Redundancy RTP Stream, SID == RID.

On Thu, Mar 31, 2016 at 7:30 AM, Magnus Westerlund <
[email-masked]> wrote:

> Hi,
>
> Here are my comments on the draft-ietf-avtext-rid-01. I think it is very
> good that we have an upcoming meeting where we can discuss the below issues.
>
> 1. Abstract:
>
> Should this really use plural of RTP streams as well as Encoded Streams. A
> particular RID value is the identifier for one Encoded or Dependent Stream
> in its RTP packetized form plus. Thus I think this abstract could be
> clearer.  However, I think it may need to addressed anyway based on comment
> 3 and 4.
>

​The RID, as written, does not identify an Encoded Stream or Dependent
Stream.  It identifies a non-Redundancy RTP stream.

> more redundancy streams protecting the RTP stream [A].

The RID identifies an RTP stream that is not a Redundancy RTP Stream.
​T
hat's all there is to it.

​An Encoded Stream has one non-Redundancy RTP Stream called the Source RTP
Stream.  A RID refers to that RTP Stream.

A Dependent Stream ​
​
​has one non-Redundancy RTP Stream which, exactly like the Encoded Stream,
but which doesn't have a name in the taxono​my draft.  Call it the
"Dependent Source RTP Stream" if you like.    A RID refers to that RTP
Stream.

> This also has the consequence that RID RTP Stream is not a suitable term
> as the RID identifies an possible aggregate of RTP streams, one source and
> zero or more redundancy RTP streams.
>

Since the RID only identifies one RTP Stream, it cannot be an aggregate
stream, since a
 Source RTP Stream cannot be an aggregate of RTP streams.  ​

>
> The above changed definition could be used, however I am not certain that
> it is what we really like to use here. For that purpose see next comment.
>
> 4. Section 3:
>

The RID *does* identify the Source RTP Stream (or the unnamed equivalent of
​a Dependent Stream).

The RID identifies a non-Redudancy RTP Stream.
The RRID identifies a Redundancy RTP Stream.

> re-use in other mechanisms.

​I don't see the need either, but Colin asked for it.
​

>
> However, I would like to take a collected consideration of the RID and
> RRID definitions and actually propose that we change the RID definition. To
> be clear on that this is another definition this new identifier I will
> refer to as RTP Stream IDentifier (SID).
>
> The definition of SID would be: "An identifier for a single RTP stream."
>

​That's basically what RRID is.  We even considered calling it SID, I
believe.  For a non-Redundancy RTP Stream, an RRID == RID, so it would just
use RID and not RRID.

>
> This of course have implication on the RID mechanism expressing the
> payload format constraints. However, I think it fulfil the basic needs very
> nicely. The a=rid lines points at a SID for which is the RTP stream for
> which the set of constraints apply.
>

​If an "a=rid' line points to a SID and not a RID, I think we've be just
confusing ourselves way more than we need to.  But since RID==SID for a
non-Redundancy RTP Stream, it doesn't matter.

> This is the basic part of the RID proposal. And this removes the need for
> RRID, as also Redundancy RTP streams can have a SID, if needed by the
> application. We get a generic basic identification that is likely to be
> re-usable while solving the current needs.
>

​At that point, you've basically just renamed RRID to SID.  ​  The real
question, though, is what goes in the header extension of the Redundancy
RTP Stream.  The whole point of RIDs in the first place is to allow the
Redundancy RTP Stream to refer to the non-Redundancy RTP Stream.  Referring
to itself is useless.  So we still need a header extension that means "The
ID of the non-Redundancy RTP Stream".

We have a few options for doing so:

Option A (current draft):

non-Redundancy referring to self: RID
Redundancy Refererring to self: RRID
Redundancy Referring to non-Redundancy: RID

Option B (your proposal):

non-Redundancy referring to self: SID
Redundancy Refererring to self: SID
Redundancy Referring to non-Redundancy: ???

Option C​

non-Redundancy referring to self: SID or RID (either way!)
Redundancy Refererring to self: SID
Redundancy Referring to non-Redundancy: RID

I'd be happy with Option C, as long as the header extension allows the
Redundancy RTP Stream to include the RID and not the SID of itself.

​ ​

>
> Some may protest, hey but we are loosing the coupling method between the
> source RTP stream and the Redundancy stream. Yes, I have a proposal below
> for how to resolve that, but at the same time, it is this coupling that
> creates the complicated definition of the RID SDES item. And this is
> The solution is simple, we simply have a=RID lines also for the Redundancy
> RTP streams. Then we define a new constraint which I will call "protect"
> which is a list of SIDs that points at one or more RTP streams for which
> this Redundancy RTP Stream is constrained to protect and provide redundancy
> for.
>
​
No, no, no.  There is no need for requiring this to be signalled, or for
this to be in SDP.  That's just useless complexity.

I'm fine with renaming RRID to SID and tweaking the definition, but I'm not
OK with adding a bunch of SDP complexity where we don't need it.

>
> An basic SDP example for this would be the following:
>
>    m=video 10000 RTP/SAVPF 100 101 108 109
>    a=rtpmap:100 H264/90000
>    a=fmtp:100 profile-level-id=42401f; packetization-mode=0
>    a=rtpmap:101 H264/90000
>    a=fmtp:101 profile-level-id=42401f; packetization-mode=1
>    a=rtpmap:108 rtx/90000
>    a=fmtp:108 apt=100
>    a=rtpmap:109 rtx/90000
>    a=fmtp:109 apt=101
>    a=sendrecv
>    a=mid:v1 (max resolution)
>    a=rid:1 send max-width=1280;max-height=720;max-fps=30
>    a=rid:2 recv max-width=1280;max-height=720;max-fps=30
>    a=rid:A send pt=108,109;protect=1
>    a=rid:B recv pt=108,109;protect=2
>
> So at RTP session startup when the offerer of the above starts sending it
> will send two RTP streams from the above block. One for the video using
> SID=1 and another for the RTX packets using SID=A.
>
>
> 5. Section 4 and 6.
>
> What I am missing in this is a discussion of privacy and the potential for
> tracking the streams across an RTP system. This is usually fine, but may
> reveal things to a third party, thus their value should be protected
> towards third parties.
>
> The next part of this issue is the generation of these values should avoid
> leaking any information about the user and implementation. This leads to
> the question if the values should be using random values, with tag lengths
> as needed by the application.
>
>
> Cheers
>
> Magnus Westerlund
>

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 4 Apr 2016 19:10:32 -0300

Den 2016-04-04 kl. 11:29, skrev Peter Thatcher:
>
> On Mon, Apr 4, 2016 at 7:26 AM, Magnus Westerlund
> <[email-masked] <mailto:[email-masked]>>
> wrote:
>
>     Hi,
>
>             4. Section 3:
>
>     So my understanding is that the RID actually represent the aggregate
>     of the RTP source stream and the redundancy, from that perspective,
>     term RTP stream Identifier is the wrong term.
>
>

Okay, then it is wrong to put the SID on the RTP Redundancy stream using 
the RTP header extension for RID. Then that should have another header 
extension or rely on the signalling layer to create the relation and 
explicitly Identify the redundancy stream also using the SID.

Cheers

Magnus Westerlund