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

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

> -----Original Message-----
> From: Colin Perkins [mailto:csp@csperkins.org]
> Sent: Sunday, February 16, 2020 3:46 PM
> To: Barry Leiba
> Cc: Bernard Aboba; Magnus Westerlund; avt@ietf.org; draft-ietf-avtcore-
> multiplex-guidelines.all@ietf.org
> 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
>            |        +------------+
>            |        |   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 <barryleiba@computer.org> wrote:
> >
> > Thanks, Bernard.
> >
> > b
> >
> > On Fri, Feb 14, 2020 at 9:13 AM Bernard Aboba
> <bernard.aboba@gmail.com> wrote:
> > The comments have been addressed. Thanks!
> >
> > On Tue, Nov 19, 2019 at 9:01 PM Barry Leiba <barryleiba@computer.org>
> wrote:
> > Hey, all.  Where are we on this?
> >
> > Barry
> >
> > On Thu, Sep 12, 2019 at 7:30 PM Magnus Westerlund
> > <magnus.westerlund@ericsson.com> wrote:
> > >
> > > Hi Barry,
> > >
> > >
> > >
> > > 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
> > >
> > >
> > >
> > > From: Barry Leiba <barryleiba@computer.org>
> > > Sent: den 12 september 2019 06:35
> > > To: draft-ietf-avtcore-multiplex-guidelines.all@ietf.org
> > > Cc: avt@ietf.org
> > > 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/80u2zgVtdCBDvoRhPmSXRAjufT
> > > A
> > >
> > >
> > >
> > > ...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 avt@ietf.org
> > https://www.ietf.org/mailman/listinfo/avt
> 
> 
> 
> --
> Colin Perkins
> https://csperkins.org/
> 
> 
> 