Re: [Rum] Distinguishing RUE and Provider requirements

James Hamlin <james.hamlin@purple.us> Mon, 04 November 2019 12:58 UTC

Return-Path: <james.hamlin@purple.us>
X-Original-To: rum@ietfa.amsl.com
Delivered-To: rum@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 410E71200E6 for <rum@ietfa.amsl.com>; Mon, 4 Nov 2019 04:58:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 TNMs1m2jlghO for <rum@ietfa.amsl.com>; Mon, 4 Nov 2019 04:58:01 -0800 (PST)
Received: from 1pmail.ess.barracuda.com (1pmail.ess.barracuda.com [209.222.82.12]) (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 22D401200B7 for <rum@ietf.org>; Mon, 4 Nov 2019 04:57:59 -0800 (PST)
Received: from smtp.purple.us (unknown [208.17.91.144]) by mx15.us-east-2a.ess.aws.cudaops.com (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO); Mon, 04 Nov 2019 12:57:56 +0000
Received: from 1-WP-402-EXCH.purplenetwork.net (10.0.10.144) by 1-wp-402-exch.purplenetwork.net (10.0.10.144) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 4 Nov 2019 04:56:22 -0800
Received: from 1-WP-402-EXCH.purplenetwork.net ([fe80::b41b:40df:b152:6817]) by 1-wp-402-exch.purplenetwork.net ([fe80::b41b:40df:b152:6817%27]) with mapi id 15.00.1263.000; Mon, 4 Nov 2019 04:56:22 -0800
From: James Hamlin <james.hamlin@purple.us>
To: "rum@ietf.org" <rum@ietf.org>, Paul Kyzivat <pkyzivat@alum.mit.edu>
Thread-Topic: [Rum] Distinguishing RUE and Provider requirements
Thread-Index: AQHVeIyT+OS9Xi64G0KyEjlMjNcpzad7IbOa
Date: Mon, 4 Nov 2019 12:56:21 +0000
Message-ID: <1572872182151.78082@purple.us>
References: <a3d82911-8d07-16a3-780b-0592e48e37bd@alum.mit.edu>, <ab68a7fb-7196-4374-7cd4-baf9a03cf6ff@alum.mit.edu>
In-Reply-To: <ab68a7fb-7196-4374-7cd4-baf9a03cf6ff@alum.mit.edu>
Accept-Language: en-GB, en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.0.10.15]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-BESS-ID: 1572872262-893028-16428-33978-1
X-BESS-VER: 2019.1_20191102.1628
X-BESS-Apparent-Source-IP: 208.17.91.144
X-BESS-Outbound-Spam-Score: 0.00
X-BESS-Outbound-Spam-Report: Code version 3.2, rules version 3.2.2.220148 [from cloudscan17-181.us-east-2b.ess.aws.cudaops.com] Rule breakdown below pts rule name description ---- ---------------------- -------------------------------- 0.00 BSF_BESS_OUTBOUND META: BESS Outbound
X-BESS-Outbound-Spam-Status: SCORE=0.00 using global scores of KILL_LEVEL=7.0 tests=BSF_BESS_OUTBOUND
X-BESS-BRTS-Status: 1
Archived-At: <https://mailarchive.ietf.org/arch/msg/rum/2yWE9IpC09SXOksvksyVzk2oP_8>
Subject: Re: [Rum] Distinguishing RUE and Provider requirements
X-BeenThere: rum@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Relay User Machine <rum.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rum>, <mailto:rum-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rum/>
List-Post: <mailto:rum@ietf.org>
List-Help: <mailto:rum-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rum>, <mailto:rum-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 04 Nov 2019 12:58:03 -0000

Paul

In the draft-ietf-rum-rue-00, there's an exemption from VP8 support for providers but no exemption from Opus support. The implication is that, in a call from the PSTN using Voice Carry Over, the provider must offer OPUS even though the audio content is constrained to 8bit*8kHz PCM over the PSTN. I don't recall seeing any argument for requiring transcoding in this case; there would be no benefit in audio quality.

Best regards

James

________________________________________
From: Rum <rum-bounces@ietf.org>; on behalf of Paul Kyzivat <pkyzivat@alum.mit.edu>;
Sent: 01 October 2019 20:15
To: rum@ietf.org
Subject: [Rum] Distinguishing RUE and Provider requirements

In the discussion thread that followed the attached message it started
to become apparent that there is a need to distinguish the requirements,
and/or requirement strength, that apply to the RUE itself from those
that apply when a RUE connects to a VRS Provider.

Now that we have a wg draft to work from, I would like to see people
step forward and make proposal(s) for what those differences should be.

While the prior discussion focused on codecs, please also consider what
else might need to differ.

        Thanks,
        Paul

-------- Forwarded Message --------
Subject: [Rum] Codec requirements in draft-rosen-rue-01
Resent-From: pkyzivat@alum.mit.edu
Date: Mon, 12 Aug 2019 16:20:51 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>;
To: rum@ietf.org

draft-rosen-rue-01 changes the video codec requirements. It now simply
references webrtc RFC7742.

RFC7742 distinguishes three types of endpoints: "WebRTC browser",
"WebRTC non-browser", and "WebRTC-compatible endpoint". AFAIK it assumes
that each end is one of these.

Is the expectation here that both the RUE and the provider comply with
one of these? In particular, that the provider may simply be a
"WebRTC-compatible endpoint? Notably:

    "WebRTC-compatible endpoints" are free to implement any video codecs
    they see fit.  This follows logically from the definition of "WebRTC-
    compatible endpoint".  It is, of course, advisable to implement at
    least one of the video codecs that is mandated for WebRTC browsers,
    and implementors are encouraged to do so.

Similarly, the audio requirements have been changed to reference webrtc
RFC7874. That one doesn't have the distinction between "WebRTC browser",
"WebRTC non-browser", and "WebRTC-compatible endpoint". It applies the
same requirements to all. In particular, it requires OPUS support. I
don't know why it doesn't make the same endpoint distinctions as for video.

I think simply referencing these documents isn't sufficient. Seems like
we need a more nuanced specification of what is required, though we may
still reference these docs with qualifications.

        Thanks,
        Paul

--
Rum mailing list
Rum@ietf.org
https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2frum&c=E,1,Fpj3uNl4KHZVkbPWDbLGqfVwMGBdbeBLTsOB6QL2I3YozMnj25zcbabu7vIDBK1XllKKO2g7RstAehUCAqLal9VAcn2JjWNhbLeuauSs&typo=0

--
Rum mailing list
Rum@ietf.org
https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2frum&c=E,1,G7A8JW3tfx9hiDhscPDTeHCoLWUSZAbId59jwHnCzDyqC39OUhM8kWYkfV9kiAEQFFRR9WYYMFy1o70xg8b-0emBXUamnQT4emSupy2-U8Yb5E-WvU4iSpdSVqQ,&typo=0