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

Colin Perkins <csp@csperkins.org> Sun, 16 February 2020 13:46 UTC

Return-Path: <csp@csperkins.org>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD5EE12002E; Sun, 16 Feb 2020 05:46:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oyrnmU_SufOs; Sun, 16 Feb 2020 05:46:21 -0800 (PST)
Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81B78120020; Sun, 16 Feb 2020 05:46:21 -0800 (PST)
Received: from [81.187.2.149] (port=43820 helo=[192.168.0.66]) by haggis.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92.3) (envelope-from <csp@csperkins.org>) id 1j3KFX-0003aU-8n; Sun, 16 Feb 2020 13:46:19 +0000
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Colin Perkins <csp@csperkins.org>
In-Reply-To: <CALaySJLziO42tM1gtcdLnfA88JExci9nujUDh2sgbv9fJqY8Tg@mail.gmail.com>
Date: Sun, 16 Feb 2020 13:46:15 +0000
Cc: Bernard Aboba <bernard.aboba@gmail.com>, Magnus Westerlund <magnus.westerlund@ericsson.com>, "avt@ietf.org" <avt@ietf.org>, "draft-ietf-avtcore-multiplex-guidelines.all@ietf.org" <draft-ietf-avtcore-multiplex-guidelines.all@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <14719C1F-0ED6-4FFA-9B09-9632F43B9F71@csperkins.org>
References: <CALaySJ+FVGYTStOVYjarR_UtPG5Ksm8hKDD2DdXQLYgQO3zRrg@mail.gmail.com> <DB7PR07MB5736513571AA3CFD7E16574795B00@DB7PR07MB5736.eurprd07.prod.outlook.com> <CALaySJ+xsk-CVmvbwcNP31J8kLsQd4hLfQh1OT-gDBhzsqCaAA@mail.gmail.com> <CAOW+2dvNesLiS8Se64x-ynu5BB626bJNTVrJCasSQ5RGhAx11A@mail.gmail.com> <CALaySJLziO42tM1gtcdLnfA88JExci9nujUDh2sgbv9fJqY8Tg@mail.gmail.com>
To: Barry Leiba <barryleiba@computer.org>
X-Mailer: Apple Mail (2.3445.104.11)
X-BlackCat-Spam-Score: 4
Archived-At: <https://mailarchive.ietf.org/arch/msg/avt/0QkXnvPzIi7K63ovA4UkLXaySGM>
Subject: Re: [AVTCORE] Moving draft-ietf-avtcore-multiplex-guidelines along
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/avt/>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 16 Feb 2020 13:46:24 -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 <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/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
> avt@ietf.org
> https://www.ietf.org/mailman/listinfo/avt



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