IETF Logo Mail Archive

Re: [rtcweb] WebRTC endpoint categories

Gaelle Martin-Cocher <gmartincocher@blackberry.com> Thu, 11 December 2014 22:41 UTC

Return-Path: <gmartincocher@blackberry.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3F791A89AF for <rtcweb@ietfa.amsl.com>; Thu, 11 Dec 2014 14:41:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 p7Dbt8YBDxV6 for <rtcweb@ietfa.amsl.com>; Thu, 11 Dec 2014 14:41:09 -0800 (PST)
Received: from smtp-p02.blackberry.com (smtp-p02.blackberry.com [208.65.78.89]) by ietfa.amsl.com (Postfix) with ESMTP id D45F41A1BE7 for <rtcweb@ietf.org>; Thu, 11 Dec 2014 14:41:08 -0800 (PST)
Received: from xct108cnc.rim.net ([10.65.161.208]) by mhs215cnc.rim.net with ESMTP/TLS/AES128-SHA; 11 Dec 2014 17:41:03 -0500
Received: from XCT116CNC.rim.net (10.65.161.216) by XCT108CNC.rim.net (10.65.161.208) with Microsoft SMTP Server (TLS) id 14.3.210.2; Thu, 11 Dec 2014 17:41:02 -0500
Received: from XMB111CNC.rim.net ([fe80::fcd6:cc6c:9e0b:25bc]) by XCT116CNC.rim.net ([::1]) with mapi id 14.03.0210.002; Thu, 11 Dec 2014 17:41:02 -0500
From: Gaelle Martin-Cocher <gmartincocher@blackberry.com>
To: Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Thread-Topic: [rtcweb] WebRTC endpoint categories
Thread-Index: AQHQFM0kak8mo4J6FkamLzsTItyLlZyJylqAgAEt3QA=
Date: Thu, 11 Dec 2014 22:41:02 +0000
Message-ID: <92D0D52F3A63344CA478CF12DB0648AADF35FA2D@XMB111CNC.rim.net>
References: <E3FA0C72-48C5-465E-AE15-EB19D8D563A7@ieca.com> <CAPF_GTaJwaS9+9uSSGTC1+RqKb=uF8UQxsP4u5jPJiRi=88-Nw@mail.gmail.com> <CAOW+2dvGH6jEp072GxfQwZ=O_QaxZpTrq3bgd2A-gOMj2PL9ZQ@mail.gmail.com> <CABcZeBPw+JoXmHM_nH=ZF6zWfMpw_V1MLZU=hD6kac8qv_Z5eQ@mail.gmail.com> <CAOW+2dsv9W9_x+RroLdsAKyhNAFGGdCTm9P3BMf1_L0XzB8UBQ@mail.gmail.com> <20141210012208.GK19538@hex.shelbyville.oz> <E425BA63-1BF0-4E51-AC4E-453A9E04C60F@apple.com> <20141210200027.GM19538@hex.shelbyville.oz> <F233B756-AF95-4DE0-B974-67AE552534E1@apple.com> <20141210230012.GN19538@hex.shelbyville.oz> <5488D58B.6040606@gmail.com>
In-Reply-To: <5488D58B.6040606@gmail.com>
Accept-Language: fr-FR, en-CA, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.65.160.250]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/H0RO0-Pwg_jmHELpGxdbMajovIk
Subject: Re: [rtcweb] WebRTC endpoint categories
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Dec 2014 22:41:11 -0000

Answering your questions below with [gmc] and repeating myself, sorry.

-----Original Message-----
From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Sergio Garcia Murillo
Sent: Wednesday, December 10, 2014 6:22 PM
To: rtcweb@ietf.org
Subject: Re: [rtcweb] WebRTC endpoint categories


Also, I hear some people complaining about the definition of a WebRTC compatible endpoint, but it would be good if those people expose what are the changes that they want to introduce:
  -Remove webrtc compatible endpoints mentions from spec 
[gmc] for me, that is an option if 'WebRTC-compatible endpoint' is not better defined.
Currently that unclear category correspond to both ‘meaningful’ entities (gateway, current WebRTC librairies, or Ron’s coffee maker) and possibly some sub-standard implementation.

  -Change definition of a webrtc compatible endpoint 
[gmc] yes, or actually clearly set out the requirements that apply to them. As said before: The WebRTC gateway in https://tools.ietf.org/id/draft-alvestrand-rtcweb-gateways-01.txt is defined as a WebRTC-compatible endpoint with some requirements being applied to it.
I am not sure how the last sentence in the WebRTC-compatible endpoint definition  “It is not constrained by this specification…”  applies to the gateway.
Proposal A: define in a draft the minimal requirements that apply to a WebRTC-compatible endpoint to “successfully communicate with a WebRTC endpoint”.    This draft can be an extension of the gateway draft.
Proposal B:  the WebRTC gateway could be removed from the WebRTC-compatible endpoint category and called a webRTC gateway with its own draft. As, there might be enough differences to  justify two entities, there would be the gateway draft and a draft for WebRTC-compatible endpoint as in proposal A.
Changing the naming of “WebRTC-compatible” to a less confusing term is a cosmetic change (but might be a good thing).

  -Mandate webrtc compatible enpoints to implement both MTI video codecs
[gmc] No. 

Proposal C: allow an endpoint that do not required some functions (by function it means that function in its entirety) to be called a WebRTC endpoint.
Example: an endpoint that does not need to do audio at all is a webRTC endpoint. An endpoint that chose to implement a single audio codec out of the two MTI audio codec is not a WebRTC endpoint.

Gaëlle




Best regards
Sergio

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

v2.27.6 | Report a Bug | By Email | System Status