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

James Hamlin <> Thu, 07 November 2019 17:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9CE9D1208A4 for <>; Thu, 7 Nov 2019 09:40:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hFntSFhXZT7q for <>; Thu, 7 Nov 2019 09:40:07 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 20C3C120089 for <>; Thu, 7 Nov 2019 09:40:06 -0800 (PST)
Received: from (unknown []) by (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO); Thu, 07 Nov 2019 17:40:02 +0000
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 7 Nov 2019 09:39:58 -0800
Received: from ([fe80::b41b:40df:b152:6817]) by ([fe80::b41b:40df:b152:6817%27]) with mapi id 15.00.1263.000; Thu, 7 Nov 2019 09:39:58 -0800
From: James Hamlin <>
To: Paul Kyzivat <>, "" <>
Thread-Topic: [Rum] I-D Action: draft-ietf-rum-rue-01.txt
Thread-Index: AQHVk1XNq3ZXe2FDzkOPjnZjRliuSKd9cZIAgAKKNh0=
Date: Thu, 7 Nov 2019 17:39:58 +0000
Message-ID: <>
References: <>, <>
In-Reply-To: <>
Accept-Language: en-GB, en-US
Content-Language: en-GB
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-BESS-ID: 1573148398-893023-24127-27889-1
X-BESS-VER: 2019.1_20191106.2224
X-BESS-Outbound-Spam-Score: 0.00
X-BESS-Outbound-Spam-Report: Code version 3.2, rules version [from] 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: <>
Subject: Re: [Rum] I-D Action: draft-ietf-rum-rue-01.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Relay User Machine <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 07 Nov 2019 17:40:11 -0000


We've discussed rtcweb-overview provides for a "WebRTC-compatible Endpoint"; the intent is to support legacy systems such as the PSTN and older VRS endpoints.

This text would clarify things:-

At the start of section 6:-

On the Relay Service Provider side of the RUM interface, there are connections to the PSTN and legacy endpoints which cannot be upgraded soon. The Relay Service Provider is regarded here as a WebRTC-compatible Endpoint as described in draft-ietf-rtcweb-overview. Relay Service Providers therefore do not have to offer, or be willing to accept all the WEBRTC codecs but will always have at least one codec in common with any RUE that is compliant with this profile.

In section 6.3 Video:-

The RUE and Relay Service Provider MUST conform to [RFC7742] with the exception that, since backwards compatibility is desirable and older devices do not support VP8, that only H.264, as specified in [RFC7742] is Mandatory to Implement by Relay Service Providers.

In section 6.4.  Audio:-

The RUE and Relay Service Provider MUST conform to [RFC7874] with the exception that, since backwards compatibility is desirable and older devices only G.711 is mandatory to implement by Relay Service Provider.

Best regards


From: Rum <> on behalf of Paul Kyzivat <>
Sent: 05 November 2019 18:44
Subject: Re: [Rum] I-D Action: draft-ietf-rum-rue-01.txt

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.


On 11/4/19 4:20 PM, 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:
> There are also htmlized versions available at:
> A diff from the previous version is available at:
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at
> Internet-Drafts are also available by anonymous FTP at:

Rum mailing list,1,ANxha7oZqejOC1IAQ9J9lBR5rVW3cOiTi5v5Y3XBZwV-QxAHx3Z0BNmJco8zmLV5hWyxbIu5F4ptM7kQ3E8cqrl5o7sLgrOfmJCv9Dd_&typo=0