Subject: Re: [AVTCORE] Moving draft-ietf-avtcore-multiplex-guidelines along

From: Barry Leiba <[email-masked]>
Date: Fri, 14 Feb 2020 04:41:30 +0000

Hi... any progress on this?

Barry

On Tue, Dec 3, 2019 at 7:03 AM Bo Burman <[email-masked]> wrote:

> Hi,
>
> I've started a (so far author-internal) draft -10 that tries to address
> most
> of Bernard's comments; in progress.
>
> I however didn't yet do a total re-haul to consider if use of MID/RID/RRID
> is
> sufficiently covered and described throughout the document. Help on
> identifying potentially impacted text would be greatly appreciated, from
> my
> co-authors as well as from the list.
>
> Regarding Bernard's comment to section 5.2:
>
> >  3.  For applications with dynamic usage of RTP streams, i.e.
> >       frequently added and removed, having much of the state associated
> >       with the RTP session rather than per individual SSRC can avoid
> >       the need for in-session signalling of meta-information about each
>  >      SSRC.
> >
> > [BA] Not sure I grasp your point here.  If there are multiple SSRCs in
> the
> > same RTP session, avoiding the need for in-session signaling typically
> > requires:
> >
> > a. A mechanism for handling "unsignaled streams" (e.g. an Unhandled RTP
> > event as in ORTC), OR
> >
> > b. Support for MID to allow routing to the correct RTP receiver without
> > in-session signaling of the SSRC.
>
> Firstly, I think the original text in bullet 3 doesn't consider use of
> bundle
> or MID but rather assumes the pre-bundle type of RTP session. Adding use
> of
> MID would be part of an RTP session state (e.g. mapping SSRC to an media
> source, which would also map to an m= line if SDP is used) that doesn't
> require in-session signaling. That would correspond to your alternative b.
>
> Secondly, there could still be "unsignaled streams" handling, either
> within
> (using same) MID or when not using MID in the RTP session, where other RTP
> session information can be used to allow proper handling of dynamically
> occuring RTP streams, such as e.g. RTCP SDES CNAME to identify RTP streams
> sent from the same endpoint (but not necessarily the same media source).
> What
> type of RTP session information that is needed for proper RTP stream
> handling
> depends on, I must assume, application-dependent requirements. That would
> correspond to your alternative a.
>
> Bernard, you indicate "a OR b" above; should they be seen as mutually
> exclusive or could they both apply in the way I indicate? Would adding a
> clarification along the lines above address your concern?
>
> Cheers,
> /Bo
>
> > -----Original Message-----
> > From: Barry Leiba <[email-masked]>
> > Sent: den 20 november 2019 07:22
> > To: Magnus Westerlund <[email-masked]>
> > Cc: [email-masked]; [email-masked]
> > Subject: Re: Moving draft-ietf-avtcore-multiplex-guidelines along
> >
> > Thanks; I'd love to move it forward.
> >
> > b
> >
> > On Wed, Nov 20, 2019 at 2:20 PM Magnus Westerlund
> > <[email-masked]> wrote:
> > >
> > > Hi Barry,
> > >
> > > Sorry, this has failed to get the necessary author time to take care
> > > of the comments. Will try to get it done soonish.
> > >
> > > Cheers
> > >
> > > Magnus Westerlund
> > >
> > >
>

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 14 Feb 2020 14:57:24 +0000

Hi,

Sorry, this has been down prioritized again by me. Will do my best to get it
moving.

Cheers

Magnus

On Fri, 2020-02-14 at 04:41 +0000, Barry Leiba wrote:
> > identifying potentially impacted text would be greatly appreciated, from my 
> > or MID but rather assumes the pre-bundle type of RTP session. Adding use of 
> > Secondly, there could still be "unsignaled streams" handling, either within 
-- 
Cheers

Magnus Westerlund 

----------------------------------------------------------------------
Networks, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 14 Feb 2020 16:26:30 +0000

Hi,

So an update is now submitted. It should address Bernards comments. Please
review it. Sorry for the delay in getting this finished up. 

Cheers

Magnus Westerlund

On Fri, 2020-02-14 at 14:57 +0000, Magnus Westerlund wrote:
> 	Error verifying signature: parse error
> Hi,
> 
> > > sent from the same endpoint (but not necessarily the same media source)
> 
> --=-W6zG64IaZZKwKI/Kf88C--
-- 
Cheers

Magnus Westerlund

---

From: Barry Leiba <[email-masked]>
Date: Fri, 14 Feb 2020 11:27:25 -0500

Bernard, I will wait for your response before proceeding.

Thanks, all,
Barry

On Fri, Feb 14, 2020 at 8:26 AM Magnus Westerlund <
[email-masked]> wrote:

> > > > (using same) MID or when not using MID in the RTP session, where
> other
> > > > RTP

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 14 Feb 2020 12:13:08 -0500

The comments have been addressed. Thanks!

On Tue, Nov 19, 2019 at 9:01 PM Barry Leiba <[email-masked]> wrote:

> Hey, all.  Where are we on this?
>
> Barry
>
> On Thu, Sep 12, 2019 at 7:30 PM Magnus Westerlund
> > Yes, we have apparently missed Bernard’s review. We will go through it
> and respond to it so that we can progress.
> >
> >
> >
> > Cheers
> >
> >
> >
> > Magnus Westerlund
> >
> >
> >
> > Sent: den 12 september 2019 06:35
> > To: [email-masked]
> > Cc: [email-masked]
> > Subject: Moving draft-ietf-avtcore-multiplex-guidelines along
> >
> >
> >
> > I’m so sorry to have let this document get lost, but I am on it now and
> will move it along without further undue delay.
> >
> >
> >
> > I’ve had a look at version -09 and like the changes there.  I think they
> address most of the comments from Ben and during last call.  But...
> >
> >
> >
> > I have not seen any response to Bernard’s TSVART review:
> >
> > https://mailarchive.ietf.org/arch/msg/avt/80u2zgVtdCBDvoRhPmSXRAjufTA
> >
> >
> >
> > ...and version -09 does not appear to address it.  Did it slip by?  Can
> the editors reply to that review now?
> >
> >
> >
> > Barry
> >
> >
>
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt
>

---

From: Barry Leiba <[email-masked]>
Date: Fri, 14 Feb 2020 18:11:14 -0500

Thanks, Bernard.

b

On Fri, Feb 14, 2020 at 9:13 AM Bernard Aboba <[email-masked]>
wrote:

>> > I’ve had a look at version -09 and like the changes there.  I think
>> they address most of the comments from Ben and during last call.  But...
>> >
>> >
>> >

---

From: Colin Perkins <[email-masked]>
Date: Sun, 16 Feb 2020 13:46:15 +0000

Hi,

I’m not sure I agree with this change. The -10 version of the draft changes Figure 1 to be:

                           |
                           | packets
           +--             v
           |        +------------+
           |        |   Socket   |   Transport Protocol Demultiplexing
           |        +------------+
           |            ||  ||
      RTP  |       RTP/ ||  |+-----> DTLS (SRTP Keying, SCTP, etc)
   Session |       RTCP ||  +------> STUN (multiplexed using same port)
           +--          ||
           +--          ||
           | (split by MID/RID and/or SSRC)
           |      ||    ||    ||    ||
           |      ||    ||    ||    ||
     RTP   |     +--+  +--+  +--+  +--+ Jitter buffer,
   Streams |     |PB|  |PB|  |PB|  |PB| process RTCP, etc.
           |     +--+  +--+  +--+  +--+
           +--      |   |      |    |
             (select decoder based on PT)
           +--      |  /       |  /
           |        +----+     | /
           |         /   |     |
   Payload |     +---+ +---+ +---+
   Formats |     |Dec| |Dec| |Dec| Decoders
           |     +---+ +---+ +---+
           +--

Changing “split by SSRC” to "split by MID/RID and/or SSRC”. This is not correct, and conflicts with Section 9.2 of BUNDLE. What should happen is that incoming RTP packets are first split into RTP streams identified by SSRC. The MID and/or RID, if present, is then used to associate each RTP stream with an SDP m= line. More like:

                           |
                           | packets
           +--             v
           |        +------------+
           |        |   Socket   |   Transport Protocol Demultiplexing
           |        +------------+
           |            ||  ||
      RTP  |       RTP/ ||  |+-----> DTLS (SRTP Keying, SCTP, etc)
   Session |       RTCP ||  +------> STUN (multiplexed using same port)
           +--          ||
           +--          ||
           |        (split by SSRC)
           |      ||    ||    ||    ||
           |(associate with signalling by MID/RID)
           |      ||    ||    ||    ||
     RTP   |     +--+  +--+  +--+  +--+ Jitter buffer,
   Streams |     |PB|  |PB|  |PB|  |PB| process RTCP, etc.
           |     +--+  +--+  +--+  +--+
           +--      |   |      |    |
             (select decoder based on PT)
           +--      |  /       |  /
           |        +----+     | /
           |         /   |     |
   Payload |     +---+ +---+ +---+
   Formats |     |Dec| |Dec| |Dec| Decoders
           |     +---+ +---+ +---+
           +--

That is, the SSRC remains the RTP stream identifier, and the MID is used to associate RTP streams with the signalling. The MID doesn’t replace the SSRC as the stream identifier.

Similarly, in Section 3.2.2:

>    Use of the MID extension
>    [I-D.ietf-mmusic-sdp-bundle-negotiation] helps to identify which
>    media source the apparently new source belongs to and use of the RID
>    extension [I-D.ietf-mmusic-rid] helps to identify what encoding or
>    redundancy stream it represents, even though the SSRC changed.

should say “Use of the MID extension […] helps to identify which media source the new SSRC represents”.

Colin

> On 14 Feb 2020, at 23:11, Barry Leiba <[email-masked]> wrote:
> 
> Thanks, Bernard.
> 
> b
> 
> On Fri, Feb 14, 2020 at 9:13 AM Bernard Aboba <[email-masked]> wrote:
> > Yes, we have apparently missed Bernard’s review. We will go through it and respond to it so that we can progress.
> >
> >
> >
> > Cheers
> >
> >
> >
> > Magnus Westerlund
> >
> >
> >
> > I’m so sorry to have let this document get lost, but I am on it now and will move it along without further undue delay.
> >
> >
> >
> > I’ve had a look at version -09 and like the changes there.  I think they address most of the comments from Ben and during last call.  But...
> >
> >
> >
> > ...and version -09 does not appear to address it.  Did it slip by?  Can the editors reply to that review now?
> >
> >
> >
> > Barry
> >
> >
> 

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

---

From: "Roni Even (A)" <[email-masked]>
Date: Sun, 16 Feb 2020 14:27:29 +0000

Hi,
I agree with Colin. I also think that split SSRC is when the demultiplexing should identify SSRC collision , one of the motivation for the rid in SDP instead of using of a=ssrc attribute

|        (split by SSRC)  +------> Identify SSRC collision

Roni

> From: Colin Perkins [mailto:[email-masked]]
> Sent: Sunday, February 16, 2020 3:46 PM
> To: Barry Leiba
> Cc: Bernard Aboba; Magnus Westerlund; [email-masked]; draft-ietf-avtcore-
> [email-masked]
> Subject: Re: [AVTCORE] Moving draft-ietf-avtcore-multiplex-guidelines along
> 
> Hi,
> 
> Changing “split by SSRC” to "split by MID/RID and/or SSRC”. This is not
> correct, and conflicts with Section 9.2 of BUNDLE. What should happen is
> that incoming RTP packets are first split into RTP streams identified by SSRC.
> The MID and/or RID, if present, is then used to associate each RTP stream
> with an SDP m= line. More like:
> 
>                            |
>                            | packets
>            +--             v
>            |        +------------+
> That is, the SSRC remains the RTP stream identifier, and the MID is used to
> associate RTP streams with the signalling. The MID doesn’t replace the SSRC
> as the stream identifier.
> 
> 
> > > I’m so sorry to have let this document get lost, but I am on it now and will
> move it along without further undue delay.
> > >
> > >
> > >
> > Audio/Video Transport Core Maintenance [email-masked]

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 17 Feb 2020 11:04:19 +0000

Hi,

Colin, I do see your point. This slipped past me. I have added to repository the
changes to address your points. 

Roni, I think we could add this about SSRC collision, I don't know how relevant
this is in this particular context. However, I have included this also in the
source in the repo based on that section 3.2 do discuss SSRC collision.  

If we would add both of your changes to the figure it results in this: 

                           |
                           | packets
           +--             v
           |        +------------+
           |        (split by SSRC)  +---> Identify SSRC collision

Regarding 3.2.2. change. I was a bit uncertain on the extent of the change and
the rest of the sentence. The changes I have made to our source would result in
this paragraph. Is this what you had in mind Colin?

   An RTP receiver receiving a previously unseen SSRC value will
   interpret it
as a new source.  It might in fact be a previously
   existing source that had to
change SSRC number due to an SSRC
   conflict.  Use of the MID extension
   [I-
D.ietf-mmusic-sdp-bundle-negotiation] helps to identify which
   media source the
new SSRC represents and use of the RID extension
   [I-D.ietf-mmusic-rid] helps
to identify what encoding or redundancy
   stream it represents, even though the
SSRC changed.  However, the
   originator of the previous SSRC ought to have
ended the conflicting
   source by sending an RTCP BYE for it prior to starting
to send with
   the new SSRC, making the new SSRC a new source.

Cheers

Magnus

On Sun, 2020-02-16 at 14:27 +0000, Roni Even (A) wrote:
> Hi,
> I agree with Colin. I also think that split SSRC is when the demultiplexing
> should identify SSRC collision , one of the motivation for the rid in SDP
> instead of using of a=ssrc attribute
> 
> >        (split by SSRC)  +------> Identify SSRC collision
> 
> 
> Roni
> 
> 
> > > On Fri, Feb 14, 2020 at 9:13 AM Bernard Aboba
> > 
> > <[email-masked]> wrote:
> > > On Tue, Nov 19, 2019 at 9:01 PM Barry Leiba <[email-masked]>
> > 
> > wrote:
> > > > will
> > editors reply to that review now?
> > > > 
> > > > 
> > > > 
> > > > Barry
> > > > 
> > > > 
> > > 
https://protect2.fireeye.com/v1/url?k=dfc6b111-8312bc63-dfc6f18a-86859b2931b3-0cb2385e2a77d464&q=1&e=5f902834-666c-4eca-ac04-c86569fe4505&u=https%3A%2F%2Fcsperkins.org%2F
-- 
Cheers

Magnus Westerlund

---

From: Colin Perkins <[email-masked]>
Date: Mon, 17 Feb 2020 22:40:33 +0000

Thanks, Magnus – those changes look good to me.
Colin

> On 17 Feb 2020, at 11:04, Magnus Westerlund <[email-masked]> wrote:
> 
> Hi,
> 
> https://protect2.fireeye.com/v1/url?k=dfc6b111-8312bc63-dfc6f18a-86859b2931b3-0cb2385e2a77d464&q=1&e=5f902834-666c-4eca-ac04-c86569fe4505&u=https%3A%2F%2Fcsperkins.org%2F <https://protect2.fireeye.com/v1/url?k=dfc6b111-8312bc63-dfc6f18a-86859b2931b3-0cb2385e2a77d464&q=1&e=5f902834-666c-4eca-ac04-c86569fe4505&u=https%3A%2F%2Fcsperkins.org%2F>
>>> 
>>> 
>>> 
>> 
>> 
> -- 
> Cheers
> 
> Magnus Westerlund 
> 
> 
> SE-164 80 Stockholm, Sweden | mailto: [email-masked] <mailto:[email-masked]>

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

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 18 Feb 2020 09:32:36 +0000

Hi,

I have just submitted a new version with these changes.

/Magnus

From: Colin Perkins <[email-masked]> 
Sent: den 17 februari 2020 23:41
To: Magnus Westerlund <[email-masked]>
Cc: Roni Even <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [AVTCORE] Moving draft-ietf-avtcore-multiplex-guidelines along

Colin

On 17 Feb 2020, at 11:04, Magnus Westerlund <[email-masked] <mailto:[email-masked]> > wrote:

Hi,

                          |
                          | packets
          +--             v
          |        +------------+

Cheers

Magnus

Hi,

Roni

-----Original Message-----
From: Colin Perkins [mailto:[email-masked]]
Sent: Sunday, February 16, 2020 3:46 PM
To: Barry Leiba
Cc: Bernard Aboba; Magnus Westerlund; [email-masked] <mailto:[email-masked]> ; draft-ietf-avtcore-
[email-masked] <mailto:[email-masked]> 
Subject: Re: [AVTCORE] Moving draft-ietf-avtcore-multiplex-guidelines along

Hi,

I’m not sure I agree with this change. The -10 version of the draft changes
Figure 1 to be:

                          |
                          | packets
          +--             v
          |        +------------+

that incoming RTP packets are first split into RTP streams identified by

                          |
                          | packets
          +--             v
          |        +------------+

  Use of the MID extension

should say “Use of the MID extension […] helps to identify which media
source the new SSRC represents”.

Colin

On 14 Feb 2020, at 23:11, Barry Leiba <[email-masked] <mailto:[email-masked]> > wrote:

Thanks, Bernard.

b

<[email-masked] <mailto:[email-masked]> > wrote:

On Tue, Nov 19, 2019 at 9:01 PM Barry Leiba <[email-masked] <mailto:[email-masked]> >

wrote:

Barry

On Thu, Sep 12, 2019 at 7:30 PM Magnus Westerlund
<[email-masked] <mailto:[email-masked]> > wrote:

Hi Barry,

Cheers

Magnus Westerlund

From: Barry Leiba <[email-masked] <mailto:[email-masked]> >
Sent: den 12 september 2019 06:35
To: [email-masked] <mailto:[email-masked]> 
Cc: [email-masked] <mailto:[email-masked]> 
Subject: Moving draft-ietf-avtcore-multiplex-guidelines along

https://mailarchive.ietf.org/arch/msg/avt/80u2zgVtdCBDvoRhPmSXRAjufT

A

Barry

_______________________________________________
Audio/Video Transport Core Maintenance [email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/avt

--
Colin Perkins

 <https://protect2.fireeye.com/v1/url?k=dfc6b111-8312bc63-dfc6f18a-86859b2931b3-0cb2385e2a77d464&q=1&e=5f902834-666c-4eca-ac04-c86569fe4505&u=https%3A%2F%2Fcsperkins.org%2F> https://protect2.fireeye.com/v1/url?k=dfc6b111-8312bc63-dfc6f18a-86859b2931b3-0cb2385e2a77d464&q=1&e=5f902834-666c-4eca-ac04-c86569fe4505&u=https%3A%2F%2Fcsperkins.org%2F

-- 
Cheers

Magnus Westerlund 

SE-164 80 Stockholm, Sweden | mailto:  <mailto:[email-masked]> [email-masked]

-- 
Colin Perkins
https://csperkins.org/ <https://protect2.fireeye.com/v1/url?k=9e569236-c2df3d5d-9e56d2ad-0cc47ad93ea2-01f39bb5f5ebb0bb&q=1&e=0478ad65-1d88-46e8-a223-66eda54de36f&u=https%3A%2F%2Fcsperkins.org%2F>