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

"Roni Even (A)" <roni.even@huawei.com> Sun, 16 February 2020 14:27 UTC

Return-Path: <roni.even@huawei.com>
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 B205D12001E; Sun, 16 Feb 2020 06:27:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 ifx2ZGrrInVJ; Sun, 16 Feb 2020 06:27:38 -0800 (PST)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 56647120018; Sun, 16 Feb 2020 06:27:38 -0800 (PST)
Received: from LHREML710-CAH.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id BBB9C5501F8655EF22EB; Sun, 16 Feb 2020 14:27:32 +0000 (GMT)
Received: from DGGEMM403-HUB.china.huawei.com (10.3.20.211) by LHREML710-CAH.china.huawei.com (10.201.108.33) with Microsoft SMTP Server (TLS) id 14.3.408.0; Sun, 16 Feb 2020 14:27:32 +0000
Received: from DGGEMM526-MBX.china.huawei.com ([169.254.8.96]) by DGGEMM403-HUB.china.huawei.com ([10.3.20.211]) with mapi id 14.03.0439.000; Sun, 16 Feb 2020 22:27:29 +0800
From: "Roni Even (A)" <roni.even@huawei.com>
To: Colin Perkins <csp@csperkins.org>, Barry Leiba <barryleiba@computer.org>
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>
Thread-Topic: [AVTCORE] Moving draft-ietf-avtcore-multiplex-guidelines along
Thread-Index: AQHV5M+Fs12pz6+2b0afmESgPn04EKgd3sVA
Date: Sun, 16 Feb 2020 14:27:29 +0000
Message-ID: <6E58094ECC8D8344914996DAD28F1CCD27D914E8@dggemm526-mbx.china.huawei.com>
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> <14719C1F-0ED6-4FFA-9B09-9632F43B9F71@csperkins.org>
In-Reply-To: <14719C1F-0ED6-4FFA-9B09-9632F43B9F71@csperkins.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.200.202.72]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/avt/hEm8AsTdCC6-HWvlJn8LshWnDtU>
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 14:27:42 -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


> -----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/
> 
> 
>