Re: [Rum] I-D Action: draft-ietf-rum-rue-01.txt

Eric Burger <eburger@standardstrack.com> Tue, 05 November 2019 23:53 UTC

Return-Path: <eburger@standardstrack.com>
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 F23C9120121 for <rum@ietfa.amsl.com>; Tue, 5 Nov 2019 15:53:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.687
X-Spam-Level:
X-Spam-Status: No, score=-1.687 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=standardstrack.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 TRW6ooSVQN-p for <rum@ietfa.amsl.com>; Tue, 5 Nov 2019 15:53:49 -0800 (PST)
Received: from se4e-iad1.servconfig.com (se4e-iad1.servconfig.com [173.231.241.35]) (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 27F921200C3 for <rum@ietf.org>; Tue, 5 Nov 2019 15:53:43 -0800 (PST)
Received: from biz221.inmotionhosting.com ([192.145.239.201]) by se4-iad1.servconfig.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from <eburger@standardstrack.com>) id 1iS8dc-000jwG-LN for rum@ietf.org; Tue, 05 Nov 2019 18:53:42 -0500
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=standardstrack.com; s=default; h=Message-Id:In-Reply-To:To:References:Date: Subject:Mime-Version:Content-Type:From:Sender:Reply-To:Cc: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=P1BAKwxmWf6XET4ktzR6x6fIYLZY8Siu5ToUNbAp2As=; b=YJHbrkMGCRmTLVE4zlh+JJkPf 2Xlsbr2kUy2ZX8DF/XtK4E0yk2Z9NJEcSED6eFmNwjGw0ybLaLh5wfn4aW3tB7B496Ysw9EWmmGWj D8AKebu2NVbvb+S9YY54rPNYzAaay6rNzlOgzZNndHpr3upbEr7ZuGiCFHE4n84kEobIc=;
Received: from [68.100.101.142] (port=49846 helo=[192.168.10.23]) by biz221.inmotionhosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from <eburger@standardstrack.com>) id 1iS8dQ-00DfEm-FD for rum@ietf.org; Tue, 05 Nov 2019 15:53:27 -0800
From: Eric Burger <eburger@standardstrack.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_16F596DF-2B33-4692-B78D-B0C1B930408A"; protocol="application/pgp-signature"; micalg=pgp-sha256
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Tue, 5 Nov 2019 18:53:14 -0500
References: <157290244575.13960.5728950433793071735@ietfa.amsl.com> <57728288-27e6-4598-09a4-3bcc9b0bff04@alum.mit.edu> <A9BF6EBB-317D-4AA0-B205-6455760F9746@standardstrack.com> <49DAABAB-09DC-40CF-81EE-61D08DA3E9CF@sorenson.com> <22E29C3D-1989-4BA8-A8AC-27F1C54AB6DC@brianrosen.net> <MWHPR04MB099129CACB1985CF28608203C57E0@MWHPR04MB0991.namprd04.prod.outlook.com>
To: "rum@ietf.org" <rum@ietf.org>
In-Reply-To: <MWHPR04MB099129CACB1985CF28608203C57E0@MWHPR04MB0991.namprd04.prod.outlook.com>
Message-Id: <9B3FF0F1-D9C3-4465-AC81-084820A0BE9A@standardstrack.com>
X-Mailer: Apple Mail (2.3445.104.11)
X-OutGoing-Spam-Status: No, score=-1.0
X-Get-Message-Sender-Via: biz221.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed
X-Authenticated-Sender: biz221.inmotionhosting.com: eburger@standardstrack.com
X-Originating-IP: 192.145.239.201
X-SpamExperts-Domain: biz221.inmotionhosting.com
X-SpamExperts-Username: 192.145.239.201
Authentication-Results: servconfig.com; auth=pass smtp.auth=192.145.239.201@biz221.inmotionhosting.com
X-SpamExperts-Outgoing-Class: ham
X-SpamExperts-Outgoing-Evidence: Combined (0.05)
X-Recommended-Action: accept
X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0T9zDZOvA8ND4p2eQxdfzLSpSDasLI4SayDByyq9LIhVnOwkWtdVO6z9 9zpZG0kY10TNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDwzmmD1lPZONmDbVrCI7lkOfH zJ6mVE7ewsipSVIfs4ZcUE9vvbJOBXSR9+tmcomZ2rBNMmEsKEibQwSU1xBeOMmSzsp3pt/8SYf6 yfMWHYJZgZXCO92Mo5TSCnevpCrdvIoGvvglhsuQYdkCCibJcQgQXA5XXIlZpQBsIdXf6rw5Fu/n q1mfdqvGyP7QRMmubEYBdMHLz8fdZytxBPvQ/tfm/6ZhrBvMHqGRRS2yqrTz7IssKbNSm6Aylrz7 vRRedYGRJ5j/qgI5gfjNk3Q1FcO1wjmeb9RCa+YI49T4kOuhAPmLnhEQ2H55IKD7afzmVf1qzaRU c3P3olRHLamMQyb0mbZGjIHswS91OoTWbV3vACnlJN4y6bSeAbUjBgwJUB0x5xwn0JVoh8+nMohe tJ8ZQzrOqjAERHu4pt/Ia6wELzcGxDgkPe7eR6qspNNQGjLhGMBSrFdf8dBbPvtqJwEiRQv+PVjj wa+Z5RFCOMTINdrO3sPm3EohYThvRn1pCN1VcB+A/1UHSRZq8MjLdTY/SAdw/QEv3otIlOZYYpcF VVikJYXKyGo2lFnLPaHwOuqJPPu/Mw4caI9hNjB7gP3QzxUBjDlIxq/CY6GWA8+LBDMrD7q/cJog wbqzsuoksATD6B4YJw/xkJTvi2DZT2gxaUBTIJceeww0VXdyJ0n96g9+SXYiBT9oXj3MvV3t9G2M BD02jS67r6+BrUuu/zwJWw42swm4bO6gacpMpzJJAaQB6RGfbERqROM6OR63chyvPJpL6DooRBPw XkYc1RNWLRL0zEKCV1rC6yEoKMXwY8LwTJ3glwd29LcBySVMm98OiyQ6+7o3FFiI0zRNn0gvzxVp TGvrZrKdIxaZrH3oREI39Ng7w+jWwVgutjGnuuve+J5DMBKo4X0ih5QNkGE9sb8xJz7YLbS4YH6b pqcEiBscwRdrth+1+oWTDTjsecoU4vapvCGSUh6RXSeW2w==
X-Report-Abuse-To: spam@se1-lax1.servconfig.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/rum/iaVV0JQ6WkN9CGFgGdQiIvwticI>
Subject: Re: [Rum] I-D Action: draft-ietf-rum-rue-01.txt
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: Tue, 05 Nov 2019 23:53:53 -0000

I don’t think we are required to be backwards compatible with everything. No one expects this to work with RUM:


Image CC 2.0 Methodshop.com <http://methodshop.com/> (https://www.flickr.com/photos/methodshop/21638277765/in/photostream/ <https://www.flickr.com/photos/methodshop/21638277765/in/photostream/>)

> On Nov 5, 2019, at 5:54 PM, Richard Shields <richard@sorenson.com>; wrote:
> 
> OPUS looks like an interesting audio codec. Considering that we support older devices, where video is already pushing the limits of CPU and memory usage, making OPUS MTI raises concerns about how well it would perform on older hardware.
> 
> Richard
> 
> From: Rum <rum-bounces@ietf.org <mailto:rum-bounces@ietf.org>> On Behalf Of Brian Rosen
> Sent: Tuesday, November 5, 2019 2:51 PM
> To: Isaac Roach <IRoach@sorenson.com <mailto:IRoach@sorenson.com>>
> Cc: rum@ietf.org <mailto:rum@ietf.org>
> Subject: Re: [Rum] I-D Action: draft-ietf-rum-rue-01.txt
> 
> [EXTERNAL] In this case I think the IETF considers OPUS to be the best practice audio codec, its free, small, and efficient.  There is only one Wideband codec that is MTI in the WebRTC specs.  I think it would be very hard to get this profile through the IETF without it.
> 
> This effort, while some of the motivation is from the US FCC, is broader scope, and thus not limited to FCC interoperability requirements.  One of the things that happens when you take work to the IETF consensus process is that it’s hard to limit to some external organizations requirements.
> 
> Brian
> 
> 
> On Nov 5, 2019, at 2:22 PM, Isaac Roach <IRoach@sorenson.com <mailto:IRoach@sorenson.com>> wrote:
> 
> Sorenson has a concern about making OPUS mandatory to implement as part of the RUM.  We don’t necessarily object to improvements that might have benefits for users in the long-run, but making OPUS mandatory specifically at this time in the RUM seems to be beyond what is necessary to implement the FCC’s interoperability requirements.  There’s nothing inherent in establishing a standard interface between devices and providers that requires implementation of OPUS.  This would instead appear to create a new minimum standard for VRS that goes beyond the FCC’s requirements.  In addition, Sorenson is concerned that mandatory implementation of OPUS would be expensive as it would require implementation of the CODEC on endpoints and backend systems when it would likely not be used in the near future for Relay PSTN G.711 calls. It would more likely be used for P2P calls but that is out of scope per the RUM charter.
> 
> We’re happy to discuss the merits of these and other long-term goals and improvements for VRS, but this is not the right place to create new minimum requirements that are not necessary for interoperability.
> 
> Thanks,
> 
> Isaac
> 
> 
> From: Rum <rum-bounces@ietf.org <mailto:rum-bounces@ietf.org>> on behalf of Eric Burger <eburger@standardstrack.com <mailto:eburger@standardstrack.com>>
> Date: Tuesday, November 5, 2019 at 12:09 PM
> To: "rum@ietf.org <mailto:rum@ietf.org>" <rum@ietf.org <mailto:rum@ietf.org>>
> Subject: Re: [Rum] I-D Action: draft-ietf-rum-rue-01.txt
> 
> The Pulakka paper I referenced for Keith might be why one would transcode from G.711 to Opus. However, I would not mandate it.
> https://www.isca-speech.org/archive/archive_papers/interspeech_2006/i06_1245.pdf <https://www.isca-speech.org/archive/archive_papers/interspeech_2006/i06_1245.pdf>
> 
> 
> 
> 
> On Nov 5, 2019, at 1:44 PM, Paul Kyzivat <pkyzivat@alum.mit.edu <mailto:pkyzivat@alum.mit.edu>> wrote:
> 
> The new text in section 6 on Mandatory to Implement is confusing. A G.711 call originating in the PSTN is never going to be *originated* by a RUE.
> 
> Calls *originated* by a RUE should *offer* all MTI codecs including OPUS. If the call terminates in the PSTN then OPUS won't be selected in the answer.
> 
> OTOH, a VRS provider when relaying a call to a RUE that originated in the PSTN may offer G.711 and not OPUS. In normal use cases such a call will be a VRS call with an interpreter. I *think* in that case audio gets relayed to the RUE, in which case continuing G.711 makes sense. But does audio from interpreter also go to the RUE? If so, transcoding up to OPUS and then mixing in the interpreter might make sense.
> 
> So this is heavily entangled in the need for different requirements for the RUE and the VRS Provider.
> 
> Thanks,
> Paul
> 
> On 11/4/19 4:20 PM, internet-drafts@ietf.org <mailto:internet-drafts@ietf.org> wrote:
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Relay User Machine WG of the IETF.
>         Title           : Interoperability Profile for Relay User Equipment
>         Author          : Brian Rosen
> Filename        : draft-ietf-rum-rue-01.txt
> Pages           : 28
> Date            : 2019-11-04
> Abstract:
>    Video Relay Service (VRS) is a term used to describe a method by
>    which a hearing persons can communicate with deaf/Hard of Hearing
>    user using an interpreter ("Communications Assistant") connected via
>    a videophone to the deaf/HoH user and an audio telephone call to the
>    hearing user.  The CA interprets using sign language on the
>    videophone link and voice on the telephone link.  Often the
>    interpreters may be supplied by a company or agency termed a
>    "provider" in this document.  The provider also provides a video
>    service that allows users to connect video devices to their service,
>    and subsequently to CAs and other dead/HoH users.  It is desirable
>    that the videophones used by the deaf/HoH/H-I user conform to a
>    standard so that any device may be used with any provider and that
>    video calls direct between deaf/HoH users work.  This document
>    describes the interface between a videophone and a provider.
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-rum-rue/ <https://datatracker.ietf.org/doc/draft-ietf-rum-rue/>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-rum-rue-01 <https://tools.ietf.org/html/draft-ietf-rum-rue-01>
> https://datatracker.ietf.org/doc/html/draft-ietf-rum-rue-01 <https://datatracker.ietf.org/doc/html/draft-ietf-rum-rue-01>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-rum-rue-01 <https://www.ietf.org/rfcdiff?url2=draft-ietf-rum-rue-01>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org <http://tools.ietf.org/>;.
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/ <ftp://ftp.ietf.org/internet-drafts/>
> 
> --
> Rum mailing list
> Rum@ietf.org <mailto:Rum@ietf.org>
> https://www.ietf.org/mailman/listinfo/rum <https://www.ietf.org/mailman/listinfo/rum>
> 
> --
> Rum mailing list
> Rum@ietf.org <mailto:Rum@ietf.org>
> https://www.ietf.org/mailman/listinfo/rum <https://www.ietf.org/mailman/listinfo/rum>
> 
> --
> Rum mailing list
> Rum@ietf.org <mailto:Rum@ietf.org>
> https://www.ietf.org/mailman/listinfo/rum <https://www.ietf.org/mailman/listinfo/rum>