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

Paul Kyzivat <pkyzivat@alum.mit.edu> Wed, 28 August 2019 14:15 UTC

Return-Path: <pkyzivat@alum.mit.edu>
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 D0DDB120043 for <rum@ietfa.amsl.com>; Wed, 28 Aug 2019 07:15:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wc7hPEl_26XQ for <rum@ietfa.amsl.com>; Wed, 28 Aug 2019 07:15:50 -0700 (PDT)
Received: from outgoing-alum.mit.edu (outgoing-alum.mit.edu [18.7.68.33]) (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 BA03A12001E for <rum@ietf.org>; Wed, 28 Aug 2019 07:15:49 -0700 (PDT)
Received: from Kokiri.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (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 <adam@nostrum.com>, Brian Rosen <br@brianrosen.net>
Cc: rum@ietf.org
References: <8FB5F5A0-E3FE-40F8-A6D0-35D9002C6770@brianrosen.net> <85828597-D024-4E7E-8876-F1C4753E6B7D@edvina.net> <64B406DC-4171-41EB-9171-A2AF7B78B409@brianrosen.net> <a3d82911-8d07-16a3-780b-0592e48e37bd@alum.mit.edu> <69F15B2A-0158-4D23-B090-642497E3BDC7@brianrosen.net> <fa8e7a65-d818-58eb-a432-f8a57ed6af95@nostrum.com>
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
Message-ID: <3fdefa0c-3a64-3445-8ceb-d293fe4b4831@alum.mit.edu>
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: <fa8e7a65-d818-58eb-a432-f8a57ed6af95@nostrum.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/rum/Ja89QupNyqYxdsWwnMBGvcSyalw>
Subject: Re: [Rum] Codec requirements in draft-rosen-rue-01
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: Wed, 28 Aug 2019 14:15:52 -0000

Inline...

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.

	Thanks,
	Paul

> /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 <pkyzivat@alum.mit.edu> 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
>>>
>>>
> 
>