Re: [AVTCORE] Moving draft-ietf-avtcore-multiplex-guidelines along
Colin Perkins <csp@csperkins.org> Mon, 17 February 2020 22:40 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 EAF9C120048; Mon, 17 Feb 2020 14:40:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.8
X-Spam-Level:
X-Spam-Status: No, score=-1.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 6tfb_viM6pEp; Mon, 17 Feb 2020 14:40:52 -0800 (PST)
Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82: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 88DFA120041; Mon, 17 Feb 2020 14:40:51 -0800 (PST)
Received: from [81.187.2.149] (port=38672 helo=[192.168.0.66]) by balrog.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92.3) (envelope-from <csp@csperkins.org>) id 1j3p4F-0003fb-Lr; Mon, 17 Feb 2020 22:40:48 +0000
From: Colin Perkins <csp@csperkins.org>
Message-Id: <269C9774-62FD-44BC-A04C-73C810FB9EBA@csperkins.org>
Content-Type: multipart/alternative; boundary="Apple-Mail=_4D884549-83E6-4993-AF73-60B465C0951A"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Mon, 17 Feb 2020 22:40:33 +0000
In-Reply-To: <9c7f68d8ae395f0a4d93d7c775cd796013564ee4.camel@ericsson.com>
Cc: Roni Even <roni.even@huawei.com>, "barryleiba@computer.org" <barryleiba@computer.org>, "bernard.aboba@gmail.com" <bernard.aboba@gmail.com>, "draft-ietf-avtcore-multiplex-guidelines.all@ietf.org" <draft-ietf-avtcore-multiplex-guidelines.all@ietf.org>, "avt@ietf.org" <avt@ietf.org>
To: Magnus Westerlund <magnus.westerlund@ericsson.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> <6E58094ECC8D8344914996DAD28F1CCD27D914E8@dggemm526-mbx.china.huawei.com> <9c7f68d8ae395f0a4d93d7c775cd796013564ee4.camel@ericsson.com>
X-Mailer: Apple Mail (2.3445.104.11)
X-BlackCat-Spam-Score: 4
Archived-At: <https://mailarchive.ietf.org/arch/msg/avt/v9dl5xmjSmVEJRFZI_wgEelVBvU>
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: Mon, 17 Feb 2020 22:40:54 -0000
Thanks, Magnus – those changes look good to me. Colin > On 17 Feb 2020, at 11:04, Magnus Westerlund <magnus.westerlund@ericsson.com> wrote: > > 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: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://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 <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 +46 10 7148287 > Torshamnsgatan 23 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com <mailto:magnus.westerlund@ericsson.com> > ---------------------------------------------------------------------- -- 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