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

Richard Shockey <richard@shockey.us> Tue, 05 November 2019 21:38 UTC

Return-Path: <richard@shockey.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 EE7DB120BD2 for <rum@ietfa.amsl.com>; Tue, 5 Nov 2019 13:38:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.118
X-Spam-Level:
X-Spam-Status: No, score=-1.118 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=shockey.us
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 7_rN9xjVIe-N for <rum@ietfa.amsl.com>; Tue, 5 Nov 2019 13:38:42 -0800 (PST)
Received: from gateway34.websitewelcome.com (gateway34.websitewelcome.com [192.185.149.72]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B29112095B for <rum@ietf.org>; Tue, 5 Nov 2019 13:38:42 -0800 (PST)
Received: from cm12.websitewelcome.com (cm12.websitewelcome.com [100.42.49.8]) by gateway34.websitewelcome.com (Postfix) with ESMTP id 6B67A127D4BA for <rum@ietf.org>; Tue, 5 Nov 2019 15:38:41 -0600 (CST)
Received: from box5527.bluehost.com ([162.241.218.19]) by cmsmtp with SMTP id S6XAi9GhnW4frS6XAicbks; Tue, 05 Nov 2019 15:38:41 -0600
X-Authority-Reason: nr=8
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-type:Mime-version:In-Reply-To:References:Message-ID:To: From:Subject:Date: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=EvuDqNrjNTvRcC4TF/3NumEZb/Y/IcruOUU0X6S8CeU=; b=QR068HQlKpRI7QVlK/2+StyzjD Nyrtd25GJBg9mlFetLEGPPsZk9vNe07lBEsbf2XS0jVI30UxiUAEm+BuJBCPc7y1Yvb/dV4Dckkkt dXcbPvUllRCVu7Zn1yOyFHcvz;
Received: from pool-100-36-47-17.washdc.fios.verizon.net ([100.36.47.17]:52087 helo=[192.168.1.156]) by box5527.bluehost.com with esmtpa (Exim 4.92) (envelope-from <richard@shockey.us>) id 1iS6XA-001Xqp-MR; Tue, 05 Nov 2019 14:38:40 -0700
User-Agent: Microsoft-MacOutlook/10.1e.0.191013
Date: Tue, 05 Nov 2019 16:38:39 -0500
From: Richard Shockey <richard@shockey.us>
To: Isaac Roach <IRoach@sorenson.com>, "rum@ietf.org" <rum@ietf.org>
Message-ID: <CC6D2F3B-8F61-4773-8469-21CEFD1A4E7B@shockey.us>
Thread-Topic: [Rum] I-D Action: draft-ietf-rum-rue-01.txt
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>
In-Reply-To: <49DAABAB-09DC-40CF-81EE-61D08DA3E9CF@sorenson.com>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3655816720_1699377769"
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box5527.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - shockey.us
X-BWhitelist: no
X-Source-IP: 100.36.47.17
X-Source-L: No
X-Exim-ID: 1iS6XA-001Xqp-MR
X-Source:
X-Source-Args:
X-Source-Dir:
X-Source-Sender: pool-100-36-47-17.washdc.fios.verizon.net ([192.168.1.156]) [100.36.47.17]:52087
X-Source-Auth: richard+shockey.us
X-Email-Count: 1
X-Source-Cap: c2hvY2tleXU7c2hvY2tleXU7Ym94NTUyNy5ibHVlaG9zdC5jb20=
X-Local-Domain: yes
Archived-At: <https://mailarchive.ietf.org/arch/msg/rum/3xKiVUmqy1zm22nVmCvcMi3BIM0>
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 21:38:46 -0000

 
This is certainly the place to discuss minimum requirements, interoperability  and conformance with generally accepted Internet standards (read OPUS)
IMHO your argument is <fill in the blank> 
 

— 

Richard Shockey

Shockey Consulting LLC

Chairman of the Board SIP Forum

www.shockey.us

www.sipforum.org

richard<at>shockey.us

Skype-Linkedin-Facebook –Twitter  rshockey101

PSTN +1 703-593-2683

 

 

From: Rum <rum-bounces@ietf.org>; on behalf of Isaac Roach <IRoach@sorenson.com>;
Date: Tuesday, November 5, 2019 at 2:22 PM
To: "rum@ietf.org"; <rum@ietf.org>;
Subject: Re: [Rum] I-D Action: draft-ietf-rum-rue-01.txt

 

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>; on behalf of Eric Burger <eburger@standardstrack.com>;
Date: Tuesday, November 5, 2019 at 12:09 PM
To: "rum@ietf.org"; <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

 




On Nov 5, 2019, at 1:44 PM, Paul Kyzivat <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 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/
There are also htmlized versions available at:
https://tools.ietf.org/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
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.
Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


-- 
Rum mailing list
Rum@ietf.org
https://www.ietf.org/mailman/listinfo/rum

 

-- Rum mailing list Rum@ietf.org https://www.ietf.org/mailman/listinfo/rum