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

Paul Kyzivat <pkyzivat@alum.mit.edu> Mon, 12 August 2019 22:38 UTC

Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: rum@ietfa.amsl.com
Delivered-To: rum@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id D1AFD121471 for <rum@ietfa.amsl.com>; Mon, 12 Aug 2019 15:38:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
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 mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id jx0Qw3SFz-Bq for <rum@ietfa.amsl.com>; Mon, 12 Aug 2019 15:38:32 -0700 (PDT)
Received: from outgoing-alum.mit.edu (outgoing-alum.mit.edu []) (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 CA24A120C84 for <rum@ietf.org>; Mon, 12 Aug 2019 13:20:54 -0700 (PDT)
Received: from Kokiri.localdomain (c-24-62-227-142.hsd1.ma.comcast.net []) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id x7CKKqkE019956 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for <rum@ietf.org>; Mon, 12 Aug 2019 16:20:52 -0400
To: 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>
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
Message-ID: <a3d82911-8d07-16a3-780b-0592e48e37bd@alum.mit.edu>
Date: Mon, 12 Aug 2019 16:20:51 -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: <64B406DC-4171-41EB-9171-A2AF7B78B409@brianrosen.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/rum/ynjBHyaDaCSkTM7Yb5wcWLwF5K8>
Subject: [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: Mon, 12 Aug 2019 22:38:34 -0000

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.