Re: [Rum] Codec requirements in draft-rosen-rue-01

Paul Kyzivat <> Wed, 28 August 2019 14:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D0DDB120043 for <>; Wed, 28 Aug 2019 07:15:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wc7hPEl_26XQ for <>; Wed, 28 Aug 2019 07:15:50 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BA03A12001E for <>; Wed, 28 Aug 2019 07:15:49 -0700 (PDT)
Received: from Kokiri.localdomain ( []) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by (8.14.7/8.12.4) with ESMTP id x7SEFinJ004315 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 28 Aug 2019 10:15:45 -0400
To: Adam Roach <>, Brian Rosen <>
References: <> <> <> <> <> <>
From: Paul Kyzivat <>
Message-ID: <>
Date: Wed, 28 Aug 2019 10:15:44 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [Rum] Codec requirements in draft-rosen-rue-01
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: Wed, 28 Aug 2019 14:15:52 -0000


On 8/27/19 5:57 PM, Adam Roach wrote:
> I certainly have thoughts. The executive summary is that I personally 
> believe RUM should specify Opus as the one audio codec MTI, and match 
> RFC 7742's "Non-Browser" requirements for the video codec MTI. Rationale 
> below.
>  From an interop perspective, the important thing is that any given 
> profile has (at least) one MTI video codec and (at least) one MTI audio 
> codec. I know there is a strong desire -- one that I share -- that these 
> endpoints can talk to/be implemented in web browsers without the need 
> for media transcoding.
> For audio: WebRTC selected G.711 and Opus as both MTI; the former 
> because it works without transcoding to landline PSTN destinations, and 
> the latter because it sounds much, much better. RUM could make the same 
> decision; or it could decide to move away from a codec that is as old as 
> I am and opt to designate Opus as the only MTI. Given that RUM 
> inherently needs to deploy into audio/video environments, backwards 
> compatibility with the PSTN seems to be unnecessary baggage.

Please keep in mind where we are coming from. The RUM will be a new 
interface to the *existing* VRS infrastructure. That infrastructure 
currently has proprietary devices that serve the RUE function, deployed 
to VRS users and to Communications Assistants (CAs, Interpreters). These 
have G.711 MTI, and also *recommend* G.722.2.

Making OPUS the only MTI audio codec would be problematic.

> For video: While specifying either VP8 or H.264 would be sufficient for 
> system interop, and for interop with compliant WebRTC endpoints, I'd 
> really prefer not to re-live the WebRTC video codec wars. Concretely, 
> what I would propose is that RUM indicate that the video codec 
> requirements are defined to be identical to those defined for "WebRTC 
> Non-Browsers" in Section 5 of RFC 7742. It should be made clear that RUM 
> endpoints *are* *not* WebRTC Non-Browsers per se; merely that they 
> comply with the same video codec requirements as WebRTC Non-Browsers.

Continuing my comment above, existing devices have H.264 Constrained 
Baseline Profile, Level 1.3, packetization mode 1 as the MTI codec. Odds 
are many of these devices aren't capable of VP8.

We can't realistically require a wholesale swap out of existing devices 
before the RUE defined by RUM can work. We can *discuss* whether forcing 
the providers to transcode is a practical way forward. I'm dubious.


> /a
> On 8/27/19 2:34 PM, Brian Rosen wrote:
>> Well, we certainly want interoperability, and I think we can only get 
>> that with MTI codecs.
>> I think we really are talking about a WebRTC-compatible endpoint, but 
>> we want interoperability with a WebRTC browser endpoint.
>> Not sure how to say this.  Maybe Adam can help.
>> Brian
>>> On Aug 12, 2019, at 4:20 PM, Paul Kyzivat <> wrote:
>>> 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