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/ > > >
- [AVTCORE] Moving draft-ietf-avtcore-multiplex-gui… Barry Leiba
- Re: [AVTCORE] Moving draft-ietf-avtcore-multiplex… Magnus Westerlund
- Re: [AVTCORE] Moving draft-ietf-avtcore-multiplex… Barry Leiba
- Re: [AVTCORE] Moving draft-ietf-avtcore-multiplex… Magnus Westerlund
- Re: [AVTCORE] Moving draft-ietf-avtcore-multiplex… Barry Leiba
- Re: [AVTCORE] Moving draft-ietf-avtcore-multiplex… Bo Burman
- Re: [AVTCORE] Moving draft-ietf-avtcore-multiplex… Bernard Aboba
- Re: [AVTCORE] Moving draft-ietf-avtcore-multiplex… Barry Leiba
- Re: [AVTCORE] Moving draft-ietf-avtcore-multiplex… Magnus Westerlund
- Re: [AVTCORE] Moving draft-ietf-avtcore-multiplex… Magnus Westerlund
- Re: [AVTCORE] Moving draft-ietf-avtcore-multiplex… Barry Leiba
- Re: [AVTCORE] Moving draft-ietf-avtcore-multiplex… Bernard Aboba
- Re: [AVTCORE] Moving draft-ietf-avtcore-multiplex… Barry Leiba
- Re: [AVTCORE] Moving draft-ietf-avtcore-multiplex… Colin Perkins
- Re: [AVTCORE] Moving draft-ietf-avtcore-multiplex… Roni Even (A)
- Re: [AVTCORE] Moving draft-ietf-avtcore-multiplex… Magnus Westerlund
- Re: [AVTCORE] Moving draft-ietf-avtcore-multiplex… Colin Perkins
- Re: [AVTCORE] Moving draft-ietf-avtcore-multiplex… Magnus Westerlund