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

Bernard Aboba <bernard.aboba@gmail.com> Thu, 05 December 2019 20:20 UTC

Return-Path: <bernard.aboba@gmail.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 D52FF120090; Thu, 5 Dec 2019 12:20:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 xlb2uioxE6Qu; Thu, 5 Dec 2019 12:20:39 -0800 (PST)
Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48A9112002F; Thu, 5 Dec 2019 12:20:39 -0800 (PST)
Received: by mail-lf1-x133.google.com with SMTP id m30so3468207lfp.8; Thu, 05 Dec 2019 12:20:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=DJg0s2J5AbWpUhmEEPC1Dgwbt4BQo4/7zfRq8HODNNE=; b=Z1BKke3ISiAXSAKI/5ZrIbPn4UYKHsKTZdK8Iz43n/5nB1A583fzfZkVMSnIfbr4vA hOSxhXg9yiCmFZJyMhnpoWXrMELuqZ11roYvrLHOODFidm3vOfrAI6CertZ89NsurPD8 f70AuYhGu2f9YGN0QyUXOof4aCDDTH4fJVFHy2TLV4hlCZD1AKMw57JbYVE0BhNMVxxF myqIRCFbQc1KMwJNXXdJaPzGjaGwHOqNTRAYy/SHDPm2idFNYUclGWV+3FVjhMNM0kh0 IRQbI0l/sFFdYQ/akYeT/4hl6aOrOwMHxEpJ0c5CdJZe+iIayoAwlUYjZGxPlxdeYnSL MTUA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=DJg0s2J5AbWpUhmEEPC1Dgwbt4BQo4/7zfRq8HODNNE=; b=BH+IJpMX83gnzPFGFeU2BGezD8R6DjAZh13te8Y2FILW4RtVhaJd7sUSjyCke3SyHy JNI0Tb7VXb2BI85GloBuW2uE+9zVvSBgYmNVknJoEZkYfU4destwQVNuUoplAKg/qgno 2yM5RoLUzgu4whmObxyzG2Vl6x8TDjoSDiNKvoOqG2Hu6i8/ix76vB8vZWEn2KAhlxQe 84g+t5E+EQVnDSMSInDTx5yFQ6pqUmY+TDA21ju/wnPLBmtQWXX1iBzvofWr27ZMGsJL GTqPo6ijKDZitnfgbnytZJCC9he1pJe9dJZbkaydD79DNvHjsNLureSMlYHzIcfkqF3e RfTg==
X-Gm-Message-State: APjAAAWLd5/iNGDqqku7K4Hpa79K97mFeebdD35P0npQr5JZjI8KH7Pe VWrlfaqmN4crlcxOuPfnNJO4Lysy7wd+ClijhvA=
X-Google-Smtp-Source: APXvYqw67QNhi+p19h8re+4P1Pyjz3aj/KsVlTzA9v9z1T/QTjsM7o9fiXZmKZaneF8YS2nqBC3KGLaAAIaCiqHGdLI=
X-Received: by 2002:a19:dc14:: with SMTP id t20mr6217889lfg.47.1575577237121; Thu, 05 Dec 2019 12:20:37 -0800 (PST)
MIME-Version: 1.0
References: <CALaySJ+FVGYTStOVYjarR_UtPG5Ksm8hKDD2DdXQLYgQO3zRrg@mail.gmail.com> <DB7PR07MB5736513571AA3CFD7E16574795B00@DB7PR07MB5736.eurprd07.prod.outlook.com> <CALaySJ+xsk-CVmvbwcNP31J8kLsQd4hLfQh1OT-gDBhzsqCaAA@mail.gmail.com> <HE1PR0701MB2697A398E78C5C636B42C49B954F0@HE1PR0701MB2697.eurprd07.prod.outlook.com> <CALaySJKMzcsAU4d6sr5Fdk-Z_OSK=MyHd9no13bnawKzfZKC6Q@mail.gmail.com> <HE1PR07MB32596CC0FC216BA57A273DB98D420@HE1PR07MB3259.eurprd07.prod.outlook.com>
In-Reply-To: <HE1PR07MB32596CC0FC216BA57A273DB98D420@HE1PR07MB3259.eurprd07.prod.outlook.com>
From: Bernard Aboba <bernard.aboba@gmail.com>
Date: Thu, 05 Dec 2019 12:20:25 -0800
Message-ID: <CAOW+2dvpLOVTrZBq6+u9NH6t1rAxYZiQxof=MRimPWVqxkOgWg@mail.gmail.com>
To: Bo Burman <bo.burman@ericsson.com>
Cc: Magnus Westerlund <magnus.westerlund@ericsson.com>, "Barry Leiba (barryleiba@computer.org)" <barryleiba@computer.org>, "draft-ietf-avtcore-multiplex-guidelines.all@ietf.org" <draft-ietf-avtcore-multiplex-guidelines.all@ietf.org>, "avt@ietf.org" <avt@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000088f2700598faa9dc"
Archived-At: <https://mailarchive.ietf.org/arch/msg/avt/2jaI681QQjOC1z6EsWtjhoRubeE>
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: Thu, 05 Dec 2019 20:20:42 -0000

Bo said:

"Bernard, you indicate "a OR b" above; should they be seen as mutually
exclusive or could they both apply in the way I indicate? Would adding a
clarification along the lines above address your concern?"

[BA] A given application will typically use either a) or b), but for an
implementation as a whole, both could be implemented.  Note that the WebRTC
1.0 API only supports b) but not a), though other APIs (e.g. ORTC) support
both. Adding a clarification would address the concern.



On Tue, Dec 3, 2019 at 4:03 AM Bo Burman <bo.burman@ericsson.com> wrote:

> Hi,
>
> I've started a (so far author-internal) draft -10 that tries to address
> most
> of Bernard's comments; in progress.
>
> I however didn't yet do a total re-haul to consider if use of MID/RID/RRID
> is
> sufficiently covered and described throughout the document. Help on
> identifying potentially impacted text would be greatly appreciated, from
> my
> co-authors as well as from the list.
>
> Regarding Bernard's comment to section 5.2:
>
> >  3.  For applications with dynamic usage of RTP streams, i.e.
> >       frequently added and removed, having much of the state associated
> >       with the RTP session rather than per individual SSRC can avoid
> >       the need for in-session signalling of meta-information about each
>  >      SSRC.
> >
> > [BA] Not sure I grasp your point here.  If there are multiple SSRCs in
> the
> > same RTP session, avoiding the need for in-session signaling typically
> > requires:
> >
> > a. A mechanism for handling "unsignaled streams" (e.g. an Unhandled RTP
> > event as in ORTC), OR
> >
> > b. Support for MID to allow routing to the correct RTP receiver without
> > in-session signaling of the SSRC.
>
> Firstly, I think the original text in bullet 3 doesn't consider use of
> bundle
> or MID but rather assumes the pre-bundle type of RTP session. Adding use
> of
> MID would be part of an RTP session state (e.g. mapping SSRC to an media
> source, which would also map to an m= line if SDP is used) that doesn't
> require in-session signaling. That would correspond to your alternative b.
>
> Secondly, there could still be "unsignaled streams" handling, either
> within
> (using same) MID or when not using MID in the RTP session, where other RTP
> session information can be used to allow proper handling of dynamically
> occuring RTP streams, such as e.g. RTCP SDES CNAME to identify RTP streams
> sent from the same endpoint (but not necessarily the same media source).
> What
> type of RTP session information that is needed for proper RTP stream
> handling
> depends on, I must assume, application-dependent requirements. That would
> correspond to your alternative a.
>
> Bernard, you indicate "a OR b" above; should they be seen as mutually
> exclusive or could they both apply in the way I indicate? Would adding a
> clarification along the lines above address your concern?
>
> Cheers,
> /Bo
>
> > -----Original Message-----
> > From: Barry Leiba <barryleiba@computer.org>
> > Sent: den 20 november 2019 07:22
> > To: Magnus Westerlund <magnus.westerlund@ericsson.com>
> > Cc: draft-ietf-avtcore-multiplex-guidelines.all@ietf.org; avt@ietf.org
> > Subject: Re: Moving draft-ietf-avtcore-multiplex-guidelines along
> >
> > Thanks; I'd love to move it forward.
> >
> > b
> >
> > On Wed, Nov 20, 2019 at 2:20 PM Magnus Westerlund
> > <magnus.westerlund@ericsson.com> wrote:
> > >
> > > Hi Barry,
> > >
> > > Sorry, this has failed to get the necessary author time to take care
> > > of the comments. Will try to get it done soonish.
> > >
> > > Cheers
> > >
> > > Magnus Westerlund
> > >
> > >
>