Subject: [avtext] Call for adoption of RID draft

From: Jonathan Lennox <[email-masked]>
Date: Mon, 1 Feb 2016 18:43:47 +0000

Hello, AVTEXT —

As discussed in Yokohama, Adam Roach et al have submitted a draft on a “RID” SDES item and header extension for identifying encoded and dependent streams.

This is a call to see whether the AVTEXT working group wants to take on this work as a work item (both adding a milestone for the work and adopting the existing draft as the starting point for a working group document).

Please comment on the AVTEXT mailing list in the next two weeks (by February 15, 2016).

Thank you!

Jonathan

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 1 Feb 2016 14:56:25 -0700

Yes, I strongly support adopting this draft and adding the WG milestone. It is need to break a lot of log jams, has been extensively discussed in various incarnations.

Cullen

> On Feb 1, 2016, at 11:43 AM, Jonathan Lennox <[email-masked]> wrote:
> 
> Hello, AVTEXT —
> 
> _______________________________________________
> avtext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avtext

---

From: Bo Burman <[email-masked]>
Date: Tue, 2 Feb 2016 08:59:34 +0000

+1
/Bo B

> -----Original Message-----
> From: avtext [mailto:[email-masked]] On Behalf Of Cullen Jennings
> Sent: den 1 februari 2016 22:56
> To: Jonathan Lennox
> Cc: [email-masked]
> Subject: Re: [avtext] Call for adoption of RID draft
> 
> 
> Yes, I strongly support adopting this draft and adding the WG milestone. It is need to break a lot of log jams, has been
> extensively discussed in various incarnations.
> 
> Cullen
> 
> 
> > As discussed in Yokohama, Adam Roach et al have submitted a draft on a “RID” SDES item and header extension for
> identifying encoded and dependent streams.
> >
> > This is a call to see whether the AVTEXT working group wants to take on this work as a work item (both adding a
> milestone for the work and adopting the existing draft as the starting point for a working group document).
> >

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 2 Feb 2016 10:00:56 +0100

Hi,

Yes, I support adopting this.

Magnus Westerlund

-- 

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: Colin Perkins <[email-masked]>
Date: Tue, 2 Feb 2016 17:49:12 +0000

> On 1 Feb 2016, at 18:43, Jonathan Lennox <[email-masked]> wrote:
> 
> Hello, AVTEXT —
> 

I don’t object to adopting this draft as a working group item.

However, I do think the working group should carefully review the semantics of the RID before this is published as an RFC. The complaint in the Introduction that none of the previous attempts to address this problem “have the proper ordinality to refer to an individual stream; all such identifiers can appear in more than one stream at a time” doesn’t align with the later requirements that main and redundancy RTP streams have the same RID. 

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

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 2 Feb 2016 10:32:11 -0800

> >Please comment on the AVTEXT mailing list in the next two weeks (by February 15, 2016).
[BA] I am in favor of adopting this draft as a working group item. 
Colin said: 
> 
> I do think the working group should carefully review the semantics of the RID before this is published as an RFC. 
[BA] It is generally considered good practice for Working Groups to carefully review documents before they publish them.  I would expect no less from this highly esteemed group :)
>The complaint in the Introduction that none of the previous attempts to address this problem “have the proper ordinality to refer to an individual stream; all such identifiers can appear in more than one stream at a time” doesn’t align with the later requirements that main and redundancy RTP streams have the same RID. 

[BA] Yes, I noticed that as well. This statement isn't correct, because SSRC multiplexing is widely implemented and interoperates at the RTP level (there are SDP issues, but that's for the MMUSIC draft).  Of course there are benefits for the use of RIDs beyond what is provided by SSRC multiplexing (e.g. an ability to decode incoming RTP packets prior to arrival of the Answer).

---

From: Peter Thatcher <[email-masked]>
Date: Tue, 2 Feb 2016 10:35:59 -0800

I support adopting the draft.

On Mon, Feb 1, 2016 at 10:43 AM, Jonathan Lennox <[email-masked]> wrote:

> Hello, AVTEXT —
>
> As discussed in Yokohama, Adam Roach et al have submitted a draft on a
> “RID” SDES item and header extension for identifying encoded and dependent
> streams.
>
> This is a call to see whether the AVTEXT working group wants to take on
> this work as a work item (both adding a milestone for the work and adopting
> the existing draft as the starting point for a working group document).
>

---

From: Peter Thatcher <[email-masked]>
Date: Tue, 2 Feb 2016 10:45:27 -0800

On Tue, Feb 2, 2016 at 9:49 AM, Colin Perkins <[email-masked]> wrote:

> However, I do think the working group should carefully review the
> semantics of the RID before this is published as an RFC. The complaint in
> the Introduction that none of the previous attempts to address this problem
> “have the proper ordinality to refer to an individual stream; all such
> identifiers can appear in more than one stream at a time” doesn’t align
> with the later requirements that main and redundancy RTP streams have the
> same RID.
>
>
​Perhaps the introduction could be more precise by saying "have the proper
ordinality to refer to an individual source RTP stream; all such
identifiers can appear in more than one source RTP stream"​

​There is one RID per source RTP stream. ​
​  ​The redundancy RTP streams have the same RID as the source RTP stream
to indicate which source RTP stream they are redundant with (or repair, or
refer to, or whatever you want to call it).   It doesn't matter how many
redundancy RTP streams there are per RID, as long as there is only one
source RTP stream.

---

From: Colin Perkins <[email-masked]>
Date: Tue, 2 Feb 2016 18:51:29 +0000

> On 2 Feb 2016, at 18:45, Peter Thatcher <[email-masked]> wrote:
> 
> 
> 
> ​Perhaps the introduction could be more precise by saying "have the proper ordinality to refer to an individual source RTP stream; all such identifiers can appear in more than one source RTP stream"​
> 
> ​There is one RID per source RTP stream. The redundancy RTP streams have the same RID as the source RTP stream to indicate which source RTP stream they are redundant with (or repair, or refer to, or whatever you want to call it).   It doesn’t matter how many redundancy RTP streams there are per RID, as long as there is only one source RTP stream.  

Perhaps, but on the principle that explicit is better than implicit, another design might be for each stream, source or redundancy, to have a unique RID, and for redundancy streams to include a list of RID values that they provide redundancy for. That way, there is no scope for confusion between source and redundancy streams. 

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

---

From: Peter Thatcher <[email-masked]>
Date: Tue, 2 Feb 2016 11:41:03 -0800

On Tue, Feb 2, 2016 at 10:51 AM, Colin Perkins <[email-masked]> wrote:

> > > This is a call to see whether the AVTEXT working group wants to take
> on this work as a work item (both adding a milestone for the work and
> adopting the existing draft as the starting point for a working group
> document).
> > >
> > ​Perhaps the introduction could be more precise by saying "have the
> proper ordinality to refer to an individual source RTP stream; all such
> > ​There is one RID per source RTP stream. The redundancy RTP streams
> have the same RID as the source RTP stream to indicate which source RTP
> stream they are redundant with (or repair, or refer to, or whatever you
> want to call it).   It doesn’t matter how many redundancy RTP streams there
> are per RID, as long as there is only one source RTP stream.
>
> Perhaps, but on the principle that explicit is better than implicit,
> another design might be for each stream, source or redundancy, to have a
> unique RID, and for redundancy streams to include a list of RID values that
> they provide redundancy for. That way, there is no scope for confusion
> between source and redundancy streams.
>

​When does a redundancy stream apply to more than one source RTP stream?
Flexfec is the only case I can think of, and that already provides all of
the necessary info in the payload, so there's no need for a header
extension.

​And what value would an ID of a redundancy RTP stream provide?  Would
anything ever refer to it?  If not, let's just not include it (it just
wastes bytes).

So let's start with your idea, remove the IDs of the redundancy RTP streams
(since no one refers to them, they have no value, and just waste bytes).
We'll also reduce the list to a single value (since only flexfec would have
a list, and flexfec doesn't need the header extension).  What are we left
with?  An ID in the source RTP stream, and a reference to that ID in the
redundancy RTP streams.  That sounds good to me, but we've just gone and
re-invented RID.

So it sounds like what you're really asking for is multiple RIDs in the
redundancy RTP streams. But I don't really see a use case for that, and on
the principle of simple is better than complex, I'd prefer a single value
in the redundancy RTP streams.

--

---

From: Adam Roach <[email-masked]>
Date: Thu, 4 Feb 2016 16:57:51 -0600

I don't have a strong opinion one way or another here. At this point, I 
hear one voice for keeping as-is, and another for giving redundancy 
streams their own RID (or RIDs? I don't understand the suggestion that 
we use a list of RIDs).

Does anyone else want to weigh in?

/a

On 2/2/16 13:41, Peter Thatcher wrote:
>
>
> On Tue, Feb 2, 2016 at 10:51 AM, Colin Perkins <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>
>     > On 2 Feb 2016, at 18:45, Peter Thatcher <[email-masked]
>     <mailto:[email-masked]>> wrote:
>     >
>     >
>     >
>     > On Tue, Feb 2, 2016 at 9:49 AM, Colin Perkins <[email-masked]
>     <mailto:[email-masked]>> wrote:
>     > > On 1 Feb 2016, at 18:43, Jonathan Lennox <[email-masked]
>     <mailto:[email-masked]>> wrote:
>     > >
>     > > Hello, AVTEXT —
>     > >
>     > > As discussed in Yokohama, Adam Roach et al have submitted a
>     draft on a “RID” SDES item and header extension for identifying
>     encoded and dependent streams.
>     > >
>     > > This is a call to see whether the AVTEXT working group wants
>     to take on this work as a work item (both adding a milestone for
>     the work and adopting the existing draft as the starting point for
>     a working group document).
>     > >
>     > However, I do think the working group should carefully review
>     the semantics of the RID before this is published as an RFC. The
>     complaint in the Introduction that none of the previous attempts
>     to address this problem “have the proper ordinality to refer to an
>     individual stream; all such identifiers can appear in more than
>     one stream at a time” doesn’t align with the later requirements
>     that main and redundancy RTP streams have the same RID.
>     >
>     >
>     > ​Perhaps the introduction could be more precise by saying "have
>     the proper ordinality to refer to an individual source RTP stream;
>     all such identifiers can appear in more than one source RTP stream"​
>     >
>     > ​There is one RID per source RTP stream. The redundancy RTP
>     streams have the same RID as the source RTP stream to indicate
>     which source RTP stream they are redundant with (or repair, or
>     refer to, or whatever you want to call it).   It doesn’t matter
>     how many redundancy RTP streams there are per RID, as long as
>     there is only one source RTP stream.
>
>     Perhaps, but on the principle that explicit is better than
>     implicit, another design might be for each stream, source or
>     redundancy, to have a unique RID, and for redundancy streams to
>     include a list of RID values that they provide redundancy for.
>     That way, there is no scope for confusion between source and
>     redundancy streams.
>
>
> ​When does a redundancy stream apply to more than one source RTP 
> stream?  Flexfec is the only case I can think of, and that already 
> provides all of the necessary info in the payload, so there's no need 
> for a header extension.
>
> So let's start with your idea, remove the IDs of the redundancy RTP 
> streams (since no one refers to them, they have no value, and just 
> waste bytes).  We'll also reduce the list to a single value (since 
> only flexfec would have a list, and flexfec doesn't need the header 
> extension). What are we left with?  An ID in the source RTP stream, 
> and a reference to that ID in the redundancy RTP streams.  That sounds 
> good to me, but we've just gone and re-invented RID.
>
> So it sounds like what you're really asking for is multiple RIDs in 
> the redundancy RTP streams. But I don't really see a use case for 
> that, and on the principle of simple is better than complex, I'd 
> prefer a single value in the redundancy RTP streams.
>
>     --
>     Colin Perkins
>     https://csperkins.org/
>
>
>
>
>
>
>

---

From: Peter Thatcher <[email-masked]>
Date: Thu, 4 Feb 2016 15:20:20 -0800

You already know which I prefer, but if we were to choose to put a ID on
the redundancy stream, we'd need to have two IDs in the header extensions,
or two header extensions: one for the redundancy stream to refer to itself
and one for the redundancy stream to refer to the source stream.  And if we
did so, I'd prefer to make the redundancy stream's ID/heeader-extension
referring to itself to be optional.

On Thu, Feb 4, 2016 at 2:57 PM, Adam Roach <[email-masked]> wrote:

> hear one voice for keeping as-is, and another for giving redundancy streams
> their own RID (or RIDs? I don't understand the suggestion that we use a
> list of RIDs).
>
>> > On 2 Feb 2016, at 18:45, Peter Thatcher < <[email-masked]>
>> [email-masked]> wrote:
>> >
>> >
>> >
>> > On Tue, Feb 2, 2016 at 9:49 AM, Colin Perkins < <[email-masked]>
>> [email-masked]> wrote:
>> > > On 1 Feb 2016, at 18:43, Jonathan Lennox < <[email-masked]>
>> [email-masked]> wrote:
>> > >
>> > > Hello, AVTEXT —
>> > >
>> > > As discussed in Yokohama, Adam Roach et al have submitted a draft on
>> a “RID” SDES item and header extension for identifying encoded and
>> dependent streams.
>> > >
>> streams have the same RID as the source RTP stream to indicate which source
>> RTP stream they are redundant with (or repair, or refer to, or whatever you
> streams (since no one refers to them, they have no value, and just waste
> bytes).  We'll also reduce the list to a single value (since only flexfec
> would have a list, and flexfec doesn't need the header extension).  What
> are we left with?  An ID in the source RTP stream, and a reference to that
> ID in the redundancy RTP streams.  That sounds good to me, but we've just
> gone and re-invented RID.
>
> avtext mailing [email-masked]://www.ietf.org/mailman/listinfo/avtext
>
>
>

---

From: Adam Roach <[email-masked]>
Date: Thu, 4 Feb 2016 17:54:19 -0600

On 2/4/16 17:20, Peter Thatcher wrote:
> You already know which I prefer, but if we were to choose to put a ID 
> on the redundancy stream, we'd need to have two IDs in the header 
> extensions, or two header extensions: one for the redundancy stream to 
> refer to itself and one for the redundancy stream to refer to the 
> source stream.  And if we did so, I'd prefer to make the redundancy 
> stream's ID/heeader-extension referring to itself to be optional.

So, there's a third option here in which the redundancy stream gets its 
own RID, and we bind those RIDs together in the SDP. Minimally, if we 
had a source RTP stream with a RID of 0, and assigned its redundancy 
stream a RID of 1, you could make the application aware of their 
association like this:

   a=rid:0 send
   a=rid:1 send depend=0

In fact, as I'm rummaging around in my memory, I think this use case is 
why we added "depend" to the mmusic document in the first place. This 
seems effective and clean. Am I overlooking something?

/a

---

From: Colin Perkins <[email-masked]>
Date: Thu, 4 Feb 2016 23:54:57 +0000

> On 4 Feb 2016, at 22:57, Adam Roach <[email-masked]> wrote:
> 
> I don't have a strong opinion one way or another here. At this point, I hear one voice for keeping as-is, and another for giving redundancy streams their own RID (or RIDs? I don't understand the suggestion that we use a list of RIDs).

Perhaps I didn’t explain myself well. The RID draft is trying to do two things: provide a unique identifier for an RTP stream, and provide an identifier which can connect a redundancy RTP stream and the RTP stream it is protecting. I was suggesting that these functions should be kept separate. Each stream, whether original or redundancy, could optionally have a RID assigned to it. The original and redundant streams would have different RIDs. Each stream that has a RID assigned to it could also (optionally) include a list of other RID values that it’s associated with. If it’s a FEC stream, these other RID values could be the stream(s) that it’s protecting; if it’s a simulcast stream, they could be the other versions; if it’s a layered stream, they could be the other layers, etc. Each stream therefore has a unique identifier, and relationships between them are explicit rather than implicit. 

(We can argue later about whether this is one SDES item with two parts to it, or two SDES items; the syntax isn’t the important part) 

Yes, this has slightly higher overhead (although if you care about overhead that much, you probably want to rethink sending a redundant video stream…). Yes, it’s perhaps slightly more complex in some ways; but it’s simpler in that each stream has a unique identifier that can unambiguously refer to it, whether from another RTP stream or from the signalling channel, so we won’t have to define yet another identifier if we later find a requirement to refer to original and redundant streams independently. 

Colin

>> On Tue, Feb 2, 2016 at 10:51 AM, Colin Perkins <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> > On 2 Feb 2016, at 18:45, Peter Thatcher < <mailto:[email-masked]>[email-masked] <mailto:[email-masked]>> wrote:
>> >
>> >
>> >
>> > On Tue, Feb 2, 2016 at 9:49 AM, Colin Perkins < <mailto:[email-masked]>[email-masked] <mailto:[email-masked]>> wrote:
>> > > On 1 Feb 2016, at 18:43, Jonathan Lennox < <mailto:[email-masked]>[email-masked] <mailto:[email-masked]>> wrote:
>> > >
>> > > Hello, AVTEXT —
>> > >
>> ​When does a redundancy stream apply to more than one source RTP stream?  Flexfec is the only case I can think of, and that already provides all of the necessary info in the payload, so there's no need for a header extension.  
>> 
>> ​And what value would an ID of a redundancy RTP stream provide?  Would anything ever refer to it?  If not, let's just not include it (it just wastes bytes).
>> 
>> So let's start with your idea, remove the IDs of the redundancy RTP streams (since no one refers to them, they have no value, and just waste bytes).  We'll also reduce the list to a single value (since only flexfec would have a list, and flexfec doesn't need the header extension).  What are we left with?  An ID in the source RTP stream, and a reference to that ID in the redundancy RTP streams.  That sounds good to me, but we've just gone and re-invented RID.
>> 
>> So it sounds like what you're really asking for is multiple RIDs in the redundancy RTP streams. But I don't really see a use case for that, and on the principle of simple is better than complex, I'd prefer a single value in the redundancy RTP streams.
>> 
>> --
>> Colin Perkins
>> https://csperkins.org/ <https://csperkins.org/>
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/avtext <https://www.ietf.org/mailman/listinfo/avtext>
> 

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

---

From: Colin Perkins <[email-masked]>
Date: Thu, 4 Feb 2016 23:56:05 +0000

> On 4 Feb 2016, at 23:54, Adam Roach <[email-masked]> wrote:
> 
>> You already know which I prefer, but if we were to choose to put a ID on the redundancy stream, we'd need to have two IDs in the header extensions, or two header extensions: one for the redundancy stream to refer to itself and one for the redundancy stream to refer to the source stream.  And if we did so, I'd prefer to make the redundancy stream's ID/heeader-extension referring to itself to be optional.
> 
> So, there's a third option here in which the redundancy stream gets its own RID, and we bind those RIDs together in the SDP. Minimally, if we had a source RTP stream with a RID of 0, and assigned its redundancy stream a RID of 1, you could make the application aware of their association like this:
> 
>   a=rid:0 send
>   a=rid:1 send depend=0
> 
> In fact, as I'm rummaging around in my memory, I think this use case is why we added "depend" to the mmusic document in the first place. This seems effective and clean. Am I overlooking something?

That’s essentially what I’m proposing, except that I was also giving the option of making the dependency explicit in the RTP packets. 

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

---

From: Peter Thatcher <[email-masked]>
Date: Thu, 4 Feb 2016 16:08:06 -0800

That seems like needless complexity to me.  Do we really need to make this
more complex?

On Thu, Feb 4, 2016 at 3:54 PM, Adam Roach <[email-masked]> wrote:

> own RID, and we bind those RIDs together in the SDP. Minimally, if we had a
> source RTP stream with a RID of 0, and assigned its redundancy stream a RID
> of 1, you could make the application aware of their association like this:
>
>   a=rid:0 send
>   a=rid:1 send depend=0
>
> why we added "depend" to the mmusic document in the first place. This seems
> effective and clean. Am I overlooking something?
>
> /a
>

---

From: Peter Thatcher <[email-masked]>
Date: Thu, 4 Feb 2016 16:14:01 -0800

I want to be able to pick one ID and put that one ID in the RTP packets and
the SDP and be done.  If we define optional additional IDs and flexibility
on top of that, I'm not opposed to that, but I want the common use case to
be simple: pick one ID, send one ID, and leave the other things optional
(or non-existent).  It's not worth complicating the main use case for
other, theoretical uses.

On Thu, Feb 4, 2016 at 3:54 PM, Colin Perkins <[email-masked]> wrote:

> Perhaps I didn’t explain myself well. The RID draft is trying to do two
> things: provide a unique identifier for an RTP stream, and provide an
> identifier which can connect a redundancy RTP stream and the RTP stream it
> is protecting. I was suggesting that these functions should be kept
> separate. Each stream, whether original or redundancy, could optionally
> have a RID assigned to it. The original and redundant streams would have
> different RIDs. Each stream that has a RID assigned to it could also
> (optionally) include a list of other RID values that it’s associated with.
> If it’s a FEC stream, these other RID values could be the stream(s) that
> it’s protecting; if it’s a simulcast stream, they could be the other
> versions; if it’s a layered stream, they could be the other layers, etc.
> Each stream therefore has a unique identifier, and relationships between
> them are explicit rather than implicit.
>
> (We can argue later about whether this is one SDES item with two parts to
> it, or two SDES items; the syntax isn’t the important part)
>
> Yes, this has slightly higher overhead (although if you care about
> overhead that much, you probably want to rethink sending a redundant video
> stream…). Yes, it’s perhaps slightly more complex in some ways; but it’s
> simpler in that each stream has a unique identifier that can unambiguously
> refer to it, whether from another RTP stream or from the signalling
> channel, so we won’t have to define yet another identifier if we later find
> a requirement to refer to original and redundant streams independently.
>
> Colin
>
>
>

---

From: Colin Perkins <[email-masked]>
Date: Fri, 5 Feb 2016 00:26:05 +0000

Pick your complexity: multiple simple identifiers, one for each need, where the complexity comes from knowing which to implement for which applications, or one (slightly) more complex identifier that can address multiple needs. 

Colin

> On 5 Feb 2016, at 00:14, Peter Thatcher <[email-masked]> wrote:
> 
> I want to be able to pick one ID and put that one ID in the RTP packets and the SDP and be done.  If we define optional additional IDs and flexibility on top of that, I'm not opposed to that, but I want the common use case to be simple: pick one ID, send one ID, and leave the other things optional (or non-existent).  It's not worth complicating the main use case for other, theoretical uses.
> 
> On Thu, Feb 4, 2016 at 3:54 PM, Colin Perkins <[email-masked] <mailto:[email-masked]>> wrote:
> 
>> On 4 Feb 2016, at 22:57, Adam Roach <[email-masked] <mailto:[email-masked]>> wrote:
>> 

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

---

From: Peter Thatcher <[email-masked]>
Date: Thu, 4 Feb 2016 16:33:02 -0800

That sounds to me like "solve the problem we know in a simple way" or
"solve the problem we know and maybe other problems we can't think of yet
with a more complex way".

I'll go with the simple solution to the known problem.

The implications of multiple IDs don't just affect the complexity of the
header extension or the SDP.  They also affect how the WebRTC API that will
ultimately use these.  And so changes to this here and now will ripple
there way through more discussions and designs and edge cases to figure out
in other groups.  So the "slightly" on the more complex part can grow
pretty quickly.

On Thu, Feb 4, 2016 at 4:26 PM, Colin Perkins <[email-masked]> wrote:

> Pick your complexity: multiple simple identifiers, one for each need,
> where the complexity comes from knowing which to implement for which
> applications, or one (slightly) more complex identifier that can address
> multiple needs.
>
> Colin
>
>
>
>
>
> I want to be able to pick one ID and put that one ID in the RTP packets
> and the SDP and be done.  If we define optional additional IDs and
> flexibility on top of that, I'm not opposed to that, but I want the common
> use case to be simple: pick one ID, send one ID, and leave the other things
> optional (or non-existent).  It's not worth complicating the main use case
> for other, theoretical uses.
>

---

From: Colin Perkins <[email-masked]>
Date: Fri, 5 Feb 2016 01:35:27 +0000

I agree, of course: if we give each stream a unique RID, and explicitly link them, that introduces some complexity in SDP and the WebRTC API that we'd need to resolve. 

But, so does the proposal to define RID exactly as you need it today, without thought for extension. Any change in requirements, perhaps to distinguish original and redundant streams, to label streams for a different reason, or to associate streams in a different way, then requires another identifier to be introduced. And that new identifier then has to be added to SDP, exposed via the WebRTC API, have its edge cases and interactions with other mechanisms defined, and so on. There's complexity here too, and I'd argue worse complexity, since – unless we really think WebRTC will never need any future extensions in this area – we'd end up with an ad-hoc and non-orthogonal set of features to combine. 

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

> On 5 Feb 2016, at 00:33, Peter Thatcher <[email-masked]> wrote:
> 
> That sounds to me like "solve the problem we know in a simple way" or "solve the problem we know and maybe other problems we can't think of yet with a more complex way".
> 
> The implications of multiple IDs don't just affect the complexity of the header extension or the SDP.  They also affect how the WebRTC API that will ultimately use these.  And so changes to this here and now will ripple there way through more discussions and designs and edge cases to figure out in other groups.  So the "slightly" on the more complex part can grow pretty quickly.
> 
> 
>

---

From: Peter Thatcher <[email-masked]>
Date: Thu, 4 Feb 2016 17:48:03 -0800

Again, you're arguing to make a simple solution for a known problem into a
complex solution for a theoretical problem.   Let's not over-engineer this.

On Thu, Feb 4, 2016 at 5:35 PM, Colin Perkins <[email-masked]> wrote:

> I agree, of course: if we give each stream a unique RID, and explicitly
> link them, that introduces some complexity in SDP and the WebRTC API that
> we'd need to resolve.
>
> But, so does the proposal to define RID exactly as you need it today,
> without thought for extension. Any change in requirements, perhaps to
> distinguish original and redundant streams, to label streams for a
> different reason, or to associate streams in a different way, then requires
> another identifier to be introduced. And that new identifier then has to be
> added to SDP, exposed via the WebRTC API, have its edge cases and
> interactions with other mechanisms defined, and so on. There's complexity
> here too, and I'd argue worse complexity, since – unless we really think
> WebRTC will never need any future extensions in this area – we'd end up
> with an ad-hoc and non-orthogonal set of features to combine.
>
> --
> Colin Perkins
> http://csperkins.org/
>
>>> (We can argue later about whether this is one SDES item with two parts
>>> to it, or two SDES items; the syntax isn’t the important part)
>>>
>>>> > > As discussed in Yokohama, Adam Roach et al have submitted a draft
>>>> on a “RID” SDES item and header extension for identifying encoded and
>>>> dependent streams.
>>>> > >
>>>> > > This is a call to see whether the AVTEXT working group wants to
>>>> take on this work as a work item (both adding a milestone for the work and
>>> stream?  Flexfec is the only case I can think of, and that already provides
>>> all of the necessary info in the payload, so there's no need for a header
>>> extension.
>>>

---

From: Peter Thatcher <[email-masked]>
Date: Thu, 4 Feb 2016 18:38:12 -0800

OK, I'll try a little more detailed thought/design experiment.

First, we're really talking about two different IDs, so let's give them
different names for a moment to avoid confusion:

SRID: source RTP stream ID: can only refer to a source RTP stream ID
ARID: any RTP stream ID: can refer to any RTP stream ID

Now let's compare how we could use them, with two options:

Option A (current RID draft):

The source RTP stream's packets contain an SRID, which identifies itself.
The redundancy RTP stream's packets contain an SRID, which is the SRID of
the source RTP stream that it protects.

Option B (your idea as I understand it):

The source RTP stream's packets contain an ARID, which identifies itself.
The redundancy RTP stream's packets contain an ARID which identifies
itself, *and* an SRID, which is the ARID of the source RTP stream that it
protects.

Option C (another possibility mentioned in the thread, I think):

The source RTP stream's packets contain an ARID, which identifies itself.
The redundancy RTP stream's packets contain an ARID which identifies itself
The ARID of the source and redundancy streams are tied together by
signaling.

I don't like Option C at all.  It requires too much signaling and API
complexity.

However, let's go back to Option B.   If make the ARID on the redundancy
RTP stream referring to itself optional (since it's not used most of the
time, why include it?), then we end up with how I would use it:

Option B2 (your idea, with the ARID optional on the redundancy stream):

The source RTP stream's packets contain an ARID, which identifies itself.
The redundancy RTP stream's packets contain an SRID, which is the ARID of
the source RTP stream that it protects (and optionally an ARID which
identifies itself)

Now another question: what if you get an SRID in a source RTP stream?  What
does that mean?  Well, it could only mean one thing:  the ID refers to the
source stream itself, which means it's functionally equivalent to an ARID
on a source RTP stream.  If this were allowed, we would end up with this
option:

Option B3 (your idea, with the ARID optional on the source and redundancy
streams):

The source RTP stream's packets contain an SRID (or, optionally, an ARID),
which identifies itself.
The redundancy RTP stream's packets contain an SRID, which is the ARID of
the source RTP stream that it protects (and optionally an ARID which
identifies itself)

Now, that looks like a system that would allow me to do what I want (put
one SRID on both) and let you do what you want (put an ARID on everything).

The SDP/API implications for this would be to basically rename every
instance of "rid" in the MMUSIC RID drafts, JSEP, and the WebRTC API with
"srid", and then given a name to ARID (probably just "rid").   Either that
or leave "rid" to mean SRID and think of a new name for ARID.  That would
be a lot less work, but I can't think of a good name for the ARID.

I don't think Option B3 is worth the additional complexity, since I don't
think the ARID is worth having, but if the WG wants to have it, then I'm
not strongly opposed, as long as ARIDs are optional and I can choose not to
use them.

And Option C is right out.

I hope that helps explain my thinking.

---

From: Peter Thatcher <[email-masked]>
Date: Thu, 4 Feb 2016 18:39:49 -0800

Sorry, one minor correction to that, the Option B3 should read:

The source RTP stream's packets contain an SRID (or, optionally, an ARID),
which identifies itself.
The redundancy RTP stream's packets contain an SRID, which is the SRID/ARID
(either way) of the source RTP stream that it protects (and optionally an
ARID which identifies itself)

On Thu, Feb 4, 2016 at 6:38 PM, Peter Thatcher <[email-masked]> wrote:

> Now another question: what if you get an SRID in a source RTP stream?
> What does that mean?  Well, it could only mean one thing:  the ID refers to
> the source stream itself, which means it's functionally equivalent to an
> ARID on a source RTP stream.  If this were allowed, we would end up with
> this option:
>

---

From: Colin Perkins <[email-masked]>
Date: Fri, 5 Feb 2016 08:24:10 +0000

My proposal is actually much simpler: every stream can have a RID; streams that have a RID can also express an association with another RID; both are optional. 

Colin

> On 5 Feb 2016, at 02:38, Peter Thatcher <[email-masked]> wrote:
> 
> First, we're really talking about two different IDs, so let's give them different names for a moment to avoid confusion:
> 
> The redundancy RTP stream's packets contain an SRID, which is the SRID of the source RTP stream that it protects.
> 
> The redundancy RTP stream's packets contain an ARID which identifies itself, *and* an SRID, which is the ARID of the source RTP stream that it protects.
> 
> The ARID of the source and redundancy streams are tied together by signaling.
> 
> 
> I don't like Option C at all.  It requires too much signaling and API complexity.
> 
> However, let's go back to Option B.   If make the ARID on the redundancy RTP stream referring to itself optional (since it's not used most of the time, why include it?), then we end up with how I would use it:
> 
> The redundancy RTP stream's packets contain an SRID, which is the ARID of the source RTP stream that it protects (and optionally an ARID which identifies itself)
> 
> 
> Now another question: what if you get an SRID in a source RTP stream?  What does that mean?  Well, it could only mean one thing:  the ID refers to the source stream itself, which means it's functionally equivalent to an ARID on a source RTP stream.  If this were allowed, we would end up with this option:
> 
> Option B3 (your idea, with the ARID optional on the source and redundancy streams):
> 
> The source RTP stream's packets contain an SRID (or, optionally, an ARID), which identifies itself.
> The redundancy RTP stream's packets contain an SRID, which is the ARID of the source RTP stream that it protects (and optionally an ARID which identifies itself)
> 
> Now, that looks like a system that would allow me to do what I want (put one SRID on both) and let you do what you want (put an ARID on everything). 
> 
> 
> The SDP/API implications for this would be to basically rename every instance of "rid" in the MMUSIC RID drafts, JSEP, and the WebRTC API with "srid", and then given a name to ARID (probably just "rid").   Either that or leave "rid" to mean SRID and think of a new name for ARID.  That would be a lot less work, but I can't think of a good name for the ARID.
> 
> 
> I don't think Option B3 is worth the additional complexity, since I don't think the ARID is worth having, but if the WG wants to have it, then I'm not strongly opposed, as long as ARIDs are optional and I can choose not to use them.  
> 

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

---

From: Adam Roach <[email-masked]>
Date: Fri, 5 Feb 2016 08:49:35 -0600

In the spirit of finding a compromise, I want to back up a bit and see 
if we can't thread this needle a little differently.

I'm sympathetic to Peter's concern that solutions that require multiple 
identifiers in a packet or signaling-level correlation of identifiers 
introduce API complexities at the top of the RTP stack, and that these 
complexities bubble all the way up to the WebRTC API in a very ugly way.

At the same time, I share Colin's concerns that designing a solution 
without consideration for future applications is needlessly 
short-sighted, and may well lead us back to trying to define a new 
identifier with even finer granularity in the foreseeable future.

I propose that we retain the meaning of RID that is currently in the 
document, which should satisfy Peter's concern. I want to address 
Colin's concern by proposing that we add text to the document indicating 
that any future applications of RID that need to identify a Repair RTP 
Stream independently of its Source RTP Stream do so with a RID plus a 
sub-identifier. This sub-identifier will be scoped to (and unique 
within) a RID.

And this sub-identifier will be PT.

Yes, the purpose of defining RID is to get away from using PTs to 
identify anything other than the configuration of payload types. But the 
reason that such a split is necessary is that using naked PTs for 
identification leads to creation of multiple PTs that represent the same 
configuration, solely for the purpose of minting unique identifiers. 
Since redundancy streams will already have a unique PT within the scope 
of any given Source RTP Stream, this proposal does not result in such a 
situation.

In Colin's terms: Every stream can have [an identifier] (RID+PT in this 
proposal); streams that have [an identifier] can also express an 
association with another [identifier] (by sharing a common RID); both 
are optional (implementations that don't care about having a unique name 
for redundancy streams don't need to talk about them).

In Peter's terms: SRID = RID, and ARID = RID+PT

Sound reasonable?

/a

On 2/5/16 02:24, Colin Perkins wrote:
> My proposal is actually much simpler: every stream can have a RID; 
> streams that have a RID can also express an association with another 
> RID; both are optional.
>
> Colin
>
>
>
>> On 5 Feb 2016, at 02:38, Peter Thatcher <[email-masked] 
>> First, we're really talking about two different IDs, so let's give 
>> them different names for a moment to avoid confusion:
>>
>> The redundancy RTP stream's packets contain an SRID, which is the 
>> SRID of the source RTP stream that it protects.
>>
>> itself, *and* an SRID, which is the ARID of the source RTP stream 
>> that it protects.
>>
>> itself
>> However, let's go back to Option B.   If make the ARID on the 
>> redundancy RTP stream referring to itself optional (since it's not 
>> used most of the time, why include it?), then we end up with how I 
>> would use it:
>>
>> The redundancy RTP stream's packets contain an SRID, which is the 
>> ARID of the source RTP stream that it protects (and optionally an 
>> What does that mean?  Well, it could only mean one thing:  the ID 
>> refers to the source stream itself, which means it's functionally 
>> equivalent to an ARID on a source RTP stream.  If this were allowed, 
>> we would end up with this option:
>>
>> The redundancy RTP stream's packets contain an SRID, which is the 
>> ARID of the source RTP stream that it protects (and optionally an 
>> Now, that looks like a system that would allow me to do what I want 
>> (put one SRID on both) and let you do what you want (put an ARID on 
>> everything).
>>
>>
>> instance of "rid" in the MMUSIC RID drafts, JSEP, and the WebRTC API 
>> with "srid", and then given a name to ARID (probably just "rid").   
>> Either that or leave "rid" to mean SRID and think of a new name for 
>> ARID.  That would be a lot less work, but I can't think of a good 
>> name for the ARID.
>>
>>
>> I don't think Option B3 is worth the additional complexity, since I 
>> don't think the ARID is worth having, but if the WG wants to have it, 
>> then I'm not strongly opposed, as long as ARIDs are optional and I 
>> can choose not to use them.
>>
>>>     I don't have a strong opinion one way or another here. At this
>>>     point, I hear one voice for keeping as-is, and another for
>>>     giving redundancy streams their own RID (or RIDs? I don't
>>>     understand the suggestion that we use a list of RIDs).
>>
>>     Perhaps I didn’t explain myself well. The RID draft is trying to
>>     do two things: provide a unique identifier for an RTP stream, and
>>     provide an identifier which can connect a redundancy RTP stream
>>     and the RTP stream it is protecting. I was suggesting that these
>>     functions should be kept separate. Each stream, whether original
>>     or redundancy, could optionally have a RID assigned to it. The
>>     original and redundant streams would have different RIDs. Each
>>     stream that has a RID assigned to it could also (optionally)
>>     include a list of other RID values that it’s associated with. If
>>     it’s a FEC stream, these other RID values could be the stream(s)
>>     that it’s protecting; if it’s a simulcast stream, they could be
>>     the other versions; if it’s a layered stream, they could be the
>>     other layers, etc. Each stream therefore has a unique identifier,
>>     and relationships between them are explicit rather than implicit.
>>
>>     (We can argue later about whether this is one SDES item with two
>>     parts to it, or two SDES items; the syntax isn’t the important part)
>>
>>     Yes, this has slightly higher overhead (although if you care
>>     about overhead that much, you probably want to rethink sending a
>>     redundant video stream…). Yes, it’s perhaps slightly more complex
>>     in some ways; but it’s simpler in that each stream has a unique
>>     identifier that can unambiguously refer to it, whether from
>>     another RTP stream or from the signalling channel, so we won’t
>>     have to define yet another identifier if we later find a
>>     requirement to refer to original and redundant streams
>>     independently.
>>
>>     Colin
>>
>>
>>
>>>>     On Tue, Feb 2, 2016 at 10:51 AM, Colin Perkins
>>>>     <[email-masked] <mailto:[email-masked]>> wrote:
>>>>
>>>>
>>>>         > On 2 Feb 2016, at 18:45, Peter Thatcher
>>>>         <[email-masked] <mailto:[email-masked]>> wrote:
>>>>         >
>>>>         >
>>>>         >
>>>>         > On Tue, Feb 2, 2016 at 9:49 AM, Colin Perkins
>>>>         <[email-masked] <mailto:[email-masked]>> wrote:
>>>>         > > On 1 Feb 2016, at 18:43, Jonathan Lennox
>>>>         <[email-masked] <mailto:[email-masked]>> wrote:
>>>>         > >
>>>>         > > Hello, AVTEXT —
>>>>         > >
>>>>         > > As discussed in Yokohama, Adam Roach et al have
>>>>         submitted a draft on a “RID” SDES item and header extension
>>>>         for identifying encoded and dependent streams.
>>>>         > >
>>>>         > > This is a call to see whether the AVTEXT working group
>>>>         wants to take on this work as a work item (both adding a
>>>>         milestone for the work and adopting the existing draft as
>>>>         the starting point for a working group document).
>>>>         > >
>>>>         > However, I do think the working group should carefully
>>>>         review the semantics of the RID before this is published as
>>>>         an RFC. The complaint in the Introduction that none of the
>>>>         previous attempts to address this problem “have the proper
>>>>         ordinality to refer to an individual stream; all such
>>>>         identifiers can appear in more than one stream at a time”
>>>>         doesn’t align with the later requirements that main and
>>>>         redundancy RTP streams have the same RID.
>>>>         >
>>>>         >
>>>>         > ​Perhaps the introduction could be more precise by saying
>>>>         "have the proper ordinality to refer to an individual
>>>>         source RTP stream; all such identifiers can appear in more
>>>>         than one source RTP stream"​
>>>>         >
>>>>         > ​There is one RID per source RTP stream. The
>>>>         redundancy RTP streams have the same RID as the source RTP
>>>>         stream to indicate which source RTP stream they are
>>>>         redundant with (or repair, or refer to, or whatever you
>>>>         want to call it).   It doesn’t matter how many redundancy
>>>>         RTP streams there are per RID, as long as there is only one
>>>>         source RTP stream.
>>>>
>>>>         implicit, another design might be for each stream, source
>>>>         or redundancy, to have a unique RID, and for redundancy
>>>>         streams to include a list of RID values that they provide
>>>>         redundancy for. That way, there is no scope for confusion
>>>>     ​ When does a redundancy stream apply to more than one source
>>>>     RTP stream? Flexfec is the only case I can think of, and that
>>>>     already provides all of the necessary info in the payload, so
>>>>     there's no need for a header extension.
>>>>
>>>>     ​ And what value would an ID of a redundancy RTP stream
>>>>     provide?  Would anything ever refer to it?  If not, let's just
>>>>     not include it (it just wastes bytes).
>>>>
>>>>     So let's start with your idea, remove the IDs of the redundancy
>>>>     RTP streams (since no one refers to them, they have no value,
>>>>     and just waste bytes). We'll also reduce the list to a single
>>>>     value (since only flexfec would have a list, and flexfec
>>>>     doesn't need the header extension).  What are we left with?  An
>>>>     ID in the source RTP stream, and a reference to that ID in the
>>>>     redundancy RTP streams.  That sounds good to me, but we've just
>>>>     So it sounds like what you're really asking for is multiple
>>>>     RIDs in the redundancy RTP streams. But I don't really see a
>>>>     use case for that, and on the principle of simple is better
>>>>     than complex, I'd prefer a single value in the redundancy RTP
>>>>     streams.
>>>>
>>>>         --
>>>>         Colin Perkins
>>>>         https://csperkins.org/
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>

---

From: Peter Thatcher <[email-masked]>
Date: Fri, 5 Feb 2016 08:29:21 -0800

Sounds like a good compromise to me.

On Fri, Feb 5, 2016 at 6:49 AM, Adam Roach <[email-masked]> wrote:

> In the spirit of finding a compromise, I want to back up a bit and see if
> we can't thread this needle a little differently.
>
> without consideration for future applications is needlessly short-sighted,
> and may well lead us back to trying to define a new identifier with even
> finer granularity in the foreseeable future.
>
> document, which should satisfy Peter's concern. I want to address Colin's
> concern by proposing that we add text to the document indicating that any
> future applications of RID that need to identify a Repair RTP Stream
> independently of its Source RTP Stream do so with a RID plus a
> sub-identifier. This sub-identifier will be scoped to (and unique within) a
> RID.
>
> Yes, the purpose of defining RID is to get away from using PTs to identify
> anything other than the configuration of payload types. But the reason that
> such a split is necessary is that using naked PTs for identification leads
> to creation of multiple PTs that represent the same configuration, solely
> for the purpose of minting unique identifiers. Since redundancy streams
> will already have a unique PT within the scope of any given Source RTP
> Stream, this proposal does not result in such a situation.
>
>
> association with another [identifier] (by sharing a common RID); both are
> optional (implementations that don't care about having a unique name for
> redundancy streams don't need to talk about them).
>
> My proposal is actually much simpler: every stream can have a RID; streams
> that have a RID can also express an association with another RID; both are
> optional.
>
> Colin
>
>
>
> On 5 Feb 2016, at 02:38, Peter Thatcher < <[email-masked]>
> On Thu, Feb 4, 2016 at 3:54 PM, Colin Perkins < <[email-masked]>
>> On Tue, Feb 2, 2016 at 10:51 AM, Colin Perkins < <[email-masked]>
>> ​ When does a redundancy stream apply to more than one source RTP
>> ​ And what value would an ID of a redundancy RTP stream provide?  Would
>>> <https://csperkins.org/>https://csperkins.org/
>>>
>>>
>>>
>>>
>>>
>>
>>

---

From: Adam Roach <[email-masked]>
Date: Mon, 8 Feb 2016 08:22:13 -0600

Colin -- any comment?

/a

On 2/5/16 08:49, Adam Roach wrote:
> I'm sympathetic to Peter's concern that solutions that require 
> multiple identifiers in a packet or signaling-level correlation of 
> identifiers introduce API complexities at the top of the RTP stack, 
> and that these complexities bubble all the way up to the WebRTC API in 
> a very ugly way.
>
> Colin's concern by proposing that we add text to the document 
> indicating that any future applications of RID that need to identify a 
> Repair RTP Stream independently of its Source RTP Stream do so with a 
> RID plus a sub-identifier. This sub-identifier will be scoped to (and 
> unique within) a RID.
>
> identify anything other than the configuration of payload types. But 
> the reason that such a split is necessary is that using naked PTs for 
> identification leads to creation of multiple PTs that represent the 
> same configuration, solely for the purpose of minting unique 
> identifiers. Since redundancy streams will already have a unique PT 
> within the scope of any given Source RTP Stream, this proposal does 
> not result in such a situation.
>
>
> In Colin's terms: Every stream can have [an identifier] (RID+PT in 
> this proposal); streams that have [an identifier] can also express an 
> are optional (implementations that don't care about having a unique 
> name for redundancy streams don't need to talk about them).
>
>>> Now another question: what if you get an SRID in a source RTP 
>>> stream? What does that mean?  Well, it could only mean one thing: 
>>>  the ID refers to the source stream itself, which means it's 
>>> functionally equivalent to an ARID on a source RTP stream.  If this 
>>> were allowed, we would end up with this option:
>>>
>>> don't think the ARID is worth having, but if the WG wants to have 
>>> it, then I'm not strongly opposed, as long as ARIDs are optional and 
>>> I can choose not to use them.
>>>
>>>     do two things: provide a unique identifier for an RTP stream,
>>>     and provide an identifier which can connect a redundancy RTP
>>>     stream and the RTP stream it is protecting. I was suggesting
>>>     that these functions should be kept separate. Each stream,
>>>     whether original or redundancy, could optionally have a RID
>>>     assigned to it. The original and redundant streams would have
>>>     different RIDs. Each stream that has a RID assigned to it could
>>>     also (optionally) include a list of other RID values that it’s
>>>     associated with. If it’s a FEC stream, these other RID values
>>>     could be the stream(s) that it’s protecting; if it’s a simulcast
>>>     stream, they could be the other versions; if it’s a layered
>>>     stream, they could be the other layers, etc. Each stream
>>>     therefore has a unique identifier, and relationships between
>>>     redundant video stream…). Yes, it’s perhaps slightly more
>>>     complex in some ways; but it’s simpler in that each stream has a
>>>     unique identifier that can unambiguously refer to it, whether
>>>     from another RTP stream or from the signalling channel, so we
>>>     won’t have to define yet another identifier if we later find a
>>>>>     <[email-masked]> wrote:
>>>>>
>>>>>
>>>>>         <[email-masked]> wrote:
>>>>>         >
>>>>>         >
>>>>>         >
>>>>>         <[email-masked]> wrote:
>>>>>         <[email-masked]> wrote:
>>>>>         > >
>>>>>         > > Hello, AVTEXT —
>>>>>         > >
>>>>>         submitted a draft on a “RID” SDES item and header
>>>>>         extension for identifying encoded and dependent streams.
>>>>>         > >
>>>>>         review the semantics of the RID before this is published
>>>>>         as an RFC. The complaint in the Introduction that none of
>>>>>         the previous attempts to address this problem “have the
>>>>>         proper ordinality to refer to an individual stream; all
>>>>>         such identifiers can appear in more than one stream at a
>>>>>         time” doesn’t align with the later requirements that main
>>>>>         and redundancy RTP streams have the same RID.
>>>>>         >
>>>>>         >
>>>>>         > ​Perhaps the introduction could be more precise by
>>>>>         saying "have the proper ordinality to refer to an
>>>>>         individual source RTP stream; all such identifiers can
>>>>>         appear in more than one source RTP stream"​
>>>>>         >
>>>>>         RTP streams there are per RID, as long as there is only
>>>>>         one source RTP stream.
>>>>>
>>>>>     So let's start with your idea, remove the IDs of the
>>>>>     redundancy RTP streams (since no one refers to them, they have
>>>>>     no value, and just waste bytes).  We'll also reduce the list
>>>>>     to a single value (since only flexfec would have a list, and
>>>>>     flexfec doesn't need the header extension).  What are we left
>>>>>     with?  An ID in the source RTP stream, and a reference to that
>>>>>     ID in the redundancy RTP streams.  That sounds good to me, but
>>>>>     we've just gone and re-invented RID.
>>>>>

---

From: Jonathan Lennox <[email-masked]>
Date: Mon, 15 Feb 2016 16:32:08 +0000

> On Feb 1, 2016, at 1:43 PM, Jonathan Lennox <[email-masked]> wrote:
> 
> Hello, AVTEXT —
> 

There is uncontested consensus to do the work and adopt this draft.  I’ll work with the AD and the authors to set a milestone.

Authors, once the milestone is approved, please submit your individual submission unchanged as a working group -00 draft, and then continue discussion and work on an updated version reflecting the discussion on the mailing list.

Thank you all!

Jonathan Lennox
AVTEXT co-chair

---

From: Colin Perkins <[email-masked]>
Date: Mon, 15 Feb 2016 20:41:13 +0000

Hi,

Apologies for the slow reply...

Having read this a few times, I'm not sure I object, but I'm also not sure I see much benefit over the original proposal. Further perpetuating the link to payload type numbers seems architecturally problematic. And, while I'm sympathetic to WebRTC API issues, using the PT and RID combination to link streams seems more likely to expose non-orthogonal and hard to work with information in the API, than exposing an additional identifier. 

So, if I haven't convinced with my arguments, I tend to favour the original proposal (what's in the draft now) to the compromise below, since it leaves a cleaner path to defining the more general identifier later, without having to deal with a legacy PT-linked identifier. 

Colin

> On 5 Feb 2016, at 14:49, Adam Roach <[email-masked]> wrote:
> 
> In the spirit of finding a compromise, I want to back up a bit and see if we can't thread this needle a little differently.
> 
> I'm sympathetic to Peter's concern that solutions that require multiple identifiers in a packet or signaling-level correlation of identifiers introduce API complexities at the top of the RTP stack, and that these complexities bubble all the way up to the WebRTC API in a very ugly way.
> 
> At the same time, I share Colin's concerns that designing a solution without consideration for future applications is needlessly short-sighted, and may well lead us back to trying to define a new identifier with even finer granularity in the foreseeable future.
> 
> I propose that we retain the meaning of RID that is currently in the document, which should satisfy Peter's concern. I want to address Colin's concern by proposing that we add text to the document indicating that any future applications of RID that need to identify a Repair RTP Stream independently of its Source RTP Stream do so with a RID plus a sub-identifier. This sub-identifier will be scoped to (and unique within) a RID.
> 
> Yes, the purpose of defining RID is to get away from using PTs to identify anything other than the configuration of payload types. But the reason that such a split is necessary is that using naked PTs for identification leads to creation of multiple PTs that represent the same configuration, solely for the purpose of minting unique identifiers. Since redundancy streams will already have a unique PT within the scope of any given Source RTP Stream, this proposal does not result in such a situation.
> 
> 
> In Colin's terms: Every stream can have [an identifier] (RID+PT in this proposal); streams that have [an identifier] can also express an association with another [identifier] (by sharing a common RID); both are optional (implementations that don't care about having a unique name for redundancy streams don't need to talk about them).
> 
>>>>>> ​ When does a redundancy stream apply to more than one source RTP stream?  Flexfec is the only case I can think of, and that already provides all of the necessary info in the payload, so there's no need for a header extension.  
>>>>>> 
>>>>>> ​ And what value would an ID of a redundancy RTP stream provide?  Would anything ever refer to it?  If not, let's just not include it (it just wastes bytes).
>>>>>>

---

From: Adam Roach <[email-masked]>
Date: Tue, 16 Feb 2016 15:05:02 -0600

On 2/15/16 14:41, Colin Perkins wrote:
> Having read this a few times, I'm not sure I object, but I'm also not 
> sure I see much benefit over the original proposal. Further 
> perpetuating the link to payload type numbers seems architecturally 
> problematic. And, while I'm sympathetic to WebRTC API issues, using 
> the PT and RID combination to link streams seems more likely to expose 
> non-orthogonal and hard to work with information in the API, than 
> exposing an additional identifier.

Okay, let me take another stab at this, then.

Currently, RIDs are UTF8 identifiers, with a format like:

         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |      RID=TBD  |     length    | rid                         ...
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

What we're looking for is an optional way to identify individual 
redundant streams associated with a source stream, while also having a 
single identifier that includes source streams and all of their 
redundant streams.

What if we had two variants of the RID format. If the field starts with 
the bits "10", then the next six bits encode the identity of the 
redundancy stream (scoped to the RID):

         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |      RID=TBD  |     length    |1|0|  sub-rid  | rid         ...
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

[Aside: the choice of  "10" as the distinguishing bit pattern is based 
on the fact that RID is a UTF8 encoded field, and no valid UTF8 string 
can start with that pattern]

But for all other bit patterns, the entire field is the RID value 
(matching the current diagram in the document). This allows unique 
identification of individual streams for applications that require it, 
while imposing virtually nothing on those implementations that don't 
wish to perform such identification -- and it gets us away from the 
admittedly architecturally inelegant solution of using PT.

The use of an escape bit sequence rather than a fixed field is 
intentional; it prevents imposing a one-byte-per-RID overhead on 
implementations that don't need to uniquely identify redundancy streams.

Sound good?

/a

---

From: Peter Thatcher <[email-masked]>
Date: Tue, 16 Feb 2016 21:56:23 -0800

This looks like a good compromise solution to me.

I like how it allows the extra ID (Redundancy RID?  RRID?) to be optional
without wasting space.  And I think it's improvement over using PTs.

On Tue, Feb 16, 2016 at 1:05 PM, Adam Roach <[email-masked]> wrote:

> Having read this a few times, I'm not sure I object, but I'm also not sure
> I see much benefit over the original proposal. Further perpetuating the
> link to payload type numbers seems architecturally problematic. And, while
> I'm sympathetic to WebRTC API issues, using the PT and RID combination to
> link streams seems more likely to expose non-orthogonal and hard to work
> with information in the API, than exposing an additional identifier.
>
>
> What we're looking for is an optional way to identify individual redundant
> streams associated with a source stream, while also having a single
> identifier that includes source streams and all of their redundant streams.
>
> the bits "10", then the next six bits encode the identity of the redundancy
> stream (scoped to the RID):
>
> [Aside: the choice of  "10" as the distinguishing bit pattern is based on
> the fact that RID is a UTF8 encoded field, and no valid UTF8 string can
> start with that pattern]
>
> while imposing virtually nothing on those implementations that don't wish
> to perform such identification -- and it gets us away from the admittedly
> architecturally inelegant solution of using PT.
>

---

From: Jonathan Lennox <[email-masked]>
Date: Wed, 17 Feb 2016 15:26:42 +0000

(Speaking as an individual.)

While the syntax of header extensions is pretty freeform, this is also meant to be an SDES item, and there’s been a reasonably strong assumption that SDES item contents are valid UTF-8.

Another possibility might be to define two SDES item types (and thus header extensions): one for “this is the identity of the stream I am”, and another for “this is the identity of the stream for which I am a redundant stream.” For our current use cases, any given stream would only ever need to send one or the other, but we'd have the flexibility in the future to generalize that.

(This is roughly Peter’s ARID/SRID proposal, I think?)

Compared to the current proposal, this would use up an additional SDES item type ID (not a big deal) and also require sessions to allocate an additional header extension ID (potentially more problematic if you’re using the 4+4 short-form header extension syntax?), but doesn’t result in any more bits on the wire.

This also has the advantage that we’re not forcing the assumption that payload types always distinguish encoded streams from redundant streams.  (I could imagine payload formats where this wasn’t true, say if you had some sort of codec-specific redundancy information which could be sent with the same payload type as the primary stream.)

On Feb 17, 2016, at 12:56 AM, Peter Thatcher <[email-masked]<mailto:[email-masked]>> wrote:

I like how it allows the extra ID (Redundancy RID?  RRID?) to be optional without wasting space.  And I think it's improvement over using PTs.

On Tue, Feb 16, 2016 at 1:05 PM, Adam Roach <[email-masked]<mailto:[email-masked]>> wrote:
On 2/15/16 14:41, Colin Perkins wrote:
Having read this a few times, I'm not sure I object, but I'm also not sure I see much benefit over the original proposal. Further perpetuating the link to payload type numbers seems architecturally problematic. And, while I'm sympathetic to WebRTC API issues, using the PT and RID combination to link streams seems more likely to expose non-orthogonal and hard to work with information in the API, than exposing an additional identifier.

What we're looking for is an optional way to identify individual redundant streams associated with a source stream, while also having a single identifier that includes source streams and all of their redundant streams.

What if we had two variants of the RID format. If the field starts with the bits "10", then the next six bits encode the identity of the redundancy stream (scoped to the RID):

[Aside: the choice of  "10" as the distinguishing bit pattern is based on the fact that RID is a UTF8 encoded field, and no valid UTF8 string can start with that pattern]

But for all other bit patterns, the entire field is the RID value (matching the current diagram in the document). This allows unique identification of individual streams for applications that require it, while imposing virtually nothing on those implementations that don't wish to perform such identification -- and it gets us away from the admittedly architecturally inelegant solution of using PT.

The use of an escape bit sequence rather than a fixed field is intentional; it prevents imposing a one-byte-per-RID overhead on implementations that don't need to uniquely identify redundancy streams.

Sound good?

/a

---

From: Peter Thatcher <[email-masked]>
Date: Wed, 17 Feb 2016 07:36:15 -0800

I'd also be happy with this design as a compromise solution.

It's just a question of whether we want to signal the support of two header
extensions or want to do a remember to check two bits when we implement the
reading of one.  I'm fine either way.

On Wed, Feb 17, 2016 at 7:26 AM, Jonathan Lennox <[email-masked]> wrote:

> While the syntax of header extensions is pretty freeform, this is also
> meant to be an SDES item, and there’s been a reasonably strong assumption
> that SDES item contents are valid UTF-8.
>
> Another possibility might be to define two SDES item types (and thus
> header extensions): one for “this is the identity of the stream I am”, and
> another for “this is the identity of the stream for which I am a redundant
> stream.” For our current use cases, any given stream would only ever need
> to send one or the other, but we'd have the flexibility in the future to
> generalize that.
>
> Compared to the current proposal, this would use up an additional SDES
> item type ID (not a big deal) and also require sessions to allocate an
> additional header extension ID (potentially more problematic if you’re
> using the 4+4 short-form header extension syntax?), but doesn’t result in
> any more bits on the wire.
>
> This also has the advantage that we’re not forcing the assumption that
> payload types always distinguish encoded streams from redundant streams.
> (I could imagine payload formats where this wasn’t true, say if you had
> some sort of codec-specific redundancy information which could be sent with
> the same payload type as the primary stream.)
>

---

From: Adam Roach <[email-masked]>
Date: Wed, 17 Feb 2016 11:55:29 -0600

On 2/17/16 09:26, Jonathan Lennox wrote:
> meant to be an SDES item, and there’s been a reasonably strong 
> assumption that SDES item contents are valid UTF-8.

Okay, that's reasonably compelling.

> header extensions): one for “this is the identity of the stream I am”, 
> and another for “this is the identity of the stream for which I am a 
> redundant stream.” For our current use cases, any given stream would 
> only ever need to send one or the other, but we'd have the flexibility 
> in the future to generalize that.
>

Well, sort of. You're slicing things a little differently. In Peter's 
description of things, for the normal case (i.e., don't need to 
distinguish repair streams from their source streams), you would only 
need to negotiate a single extension (what he calls SRID). The only time 
you'd need to negotiate for the additional identifier type (what he 
calls ARID) would be when you *do* need to make that distinction. And 
there's a reasonable argument to be made that the need to make such a 
distinction will be quite rare.

> item type ID (not a big deal)

Agreed.

> and also require sessions to allocate an additional header extension 
> ID (potentially more problematic if you’re using the 4+4 short-form 
> header extension syntax?), but doesn’t result in any more bits on the 
> wire.

Well, if we divide things up more along the lines of how Peter proposes, 
then we only need to allocate a single ID in most cases.

I'll put together some language and add it to the document after the 
milestone is added to the charter.

/a

---

From: Colin Perkins <[email-masked]>
Date: Wed, 17 Feb 2016 23:55:42 +0000

> On 17 Feb 2016, at 15:26, Jonathan Lennox <[email-masked]> wrote:
> 

Right. RFC 3550, section 6.5, says the text in SDES items “is encoded according to the UTF-8 encoding”.

> (This is roughly Peter’s ARID/SRID proposal, I think?)

That seems reasonable, yes, provided there would be the option for the redundant stream to include both SDES items, if there’s a need to explicitly identify the redundant stream, as well as the original stream for which it’s providing redundancy.

Colin

>> On Feb 17, 2016, at 12:56 AM, Peter Thatcher <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> On Tue, Feb 16, 2016 at 1:05 PM, Adam Roach <[email-masked] <mailto:[email-masked]>> wrote:

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