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

[Magnus Westerlund <[e-mail]>]

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
           |        +------------+
           |        |   Socket   |   Transport Protocol Demultiplexing
           |        +------------+
           |            ||  ||
      RTP  |       RTP/ ||  |+-----> DTLS (SRTP Keying, SCTP, etc)
   Session |       RTCP ||  +------> STUN (multiplexed using same port)
           +--          ||
           +--          ||
           |        (split by SSRC)  +---> Identify SSRC collision
           |      ||    ||    ||    ||
           |(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
           |     +---+ +---+ +---+
           +--


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
> 
> 
> > -----Original Message-----
> > From: Colin Perkins [mailto:[e-mail]]
> > Sent: Sunday, February 16, 2020 3:46 PM
> > To: Barry Leiba
> > Cc: Bernard Aboba; Magnus Westerlund; [e-mail]; draft-ietf-avtcore-
> > [e-mail]
> > 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 <[e-mail]> wrote:
> > > 
> > > Thanks, Bernard.
> > > 
> > > b
> > > 
> > > On Fri, Feb 14, 2020 at 9:13 AM Bernard Aboba
> > 
> > <[e-mail]> wrote:
> > > The comments have been addressed. Thanks!
> > > 
> > > On Tue, Nov 19, 2019 at 9:01 PM Barry Leiba <[e-mail]>
> > 
> > wrote:
> > > Hey, all.  Where are we on this?
> > > 
> > > Barry
> > > 
> > > On Thu, Sep 12, 2019 at 7:30 PM Magnus Westerlund
> > > <[e-mail]> 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 <[e-mail]>
> > > > Sent: den 12 september 2019 06:35
> > > > To: [e-mail]
> > > > Cc: [e-mail]
> > > > 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 [e-mail]
> > > 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
> > 
> > 
> > 
> 
> 
-- 
Cheers

Magnus Westerlund 


----------------------------------------------------------------------
Networks, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  [phone]
Torshamnsgatan 23           | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------