Re: [rtcweb] Definitions of WebRTC entities

Christer Holmberg <christer.holmberg@ericsson.com> Fri, 03 October 2014 12:01 UTC

Return-Path: <christer.holmberg@ericsson.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 5107C1A0300 for <rtcweb@ietfa.amsl.com>; Fri, 3 Oct 2014 05:01:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] 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 HjXyPbsK720A for <rtcweb@ietfa.amsl.com>; Fri, 3 Oct 2014 05:01:24 -0700 (PDT)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6A061A0307 for <rtcweb@ietf.org>; Fri, 3 Oct 2014 05:01:23 -0700 (PDT)
X-AuditID: c1b4fb2d-f793d6d000005356-41-542e90116606
Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id B4.96.21334.1109E245; Fri, 3 Oct 2014 14:01:21 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.136]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.03.0174.001; Fri, 3 Oct 2014 14:01:21 +0200
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Harald Alvestrand <harald@alvestrand.no>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Thread-Topic: [rtcweb] Definitions of WebRTC entities
Thread-Index: AQHP3t3ehH0V0UJNhEaGpnZRIRprGZweQ+vQ
Date: Fri, 03 Oct 2014 12:01:20 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1D465376@ESESSMB209.ericsson.se>
References: <542E53D2.5040500@alvestrand.no>
In-Reply-To: <542E53D2.5040500@alvestrand.no>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.146]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrALMWRmVeSWpSXmKPExsUyM+Jvja7gBL0Qg/nbzS2O9XWxWaz9187u wORxZcIVVo8lS34yBTBFcdmkpOZklqUW6dslcGXca+AseCJVcejmfuYGxnmiXYycHBICJhL7 j81gg7DFJC7cWw9kc3EICRxllNg7ZQYjhLOYUaJvxVWmLkYODjYBC4nuf9ogDSICwRK9z98z gtjCQIN2ztvECBE3leiadR/KNpI4f2MbC4jNIqAiMW/ZNVYQm1fAV2LL33YmEFtIQEdi98SL YHFOAV2JlcchDmIEOuj7qTVgNcwC4hK3nsxngjhUQGLJnvPMELaoxMvH/1ghbCWJHxsusUDU 60gs2P2JDcLWlli28DUzxF5BiZMzn7BMYBSdhWTsLCQts5C0zELSsoCRZRWjaHFqcXFuupGx XmpRZnJxcX6eXl5qySZGYJQc3PJbdwfj6teOhxgFOBiVeHgVmPVChFgTy4orcw8xSnOwKInz Ljo3L1hIID2xJDU7NbUgtSi+qDQntfgQIxMHp1QDY2duuo/L06LtzetNmc5NyFKUCX7ydxEf b6B13oZkC52snIOXZONe8n/Yqvl8ZVRCyj+Gy50HWGYaHsyxSqjX/C2SpPefz2hbC8s9R92v nXmFyUcmr4hj/6L1mlfgr1KNi+X+BI98nqIrWjWhlSvurjZNXskZ+PNTQcLpc/kGmR6hC195 GucosRRnJBpqMRcVJwIAEcbXwXMCAAA=
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/AgRSOkmlrt2ruYnhakEAXcpYoHg
Subject: Re: [rtcweb] Definitions of WebRTC entities
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: Fri, 03 Oct 2014 12:01:27 -0000

Hi,

First, I personally see no need for all these definitions.

I think it would be enough to have:

- WebRTC endpoint (e.g. a browser)
- WebRTC-compatible endpoint (e.g. a gateway)

If people really think we need more, I won't argue against. I just think it becomes very messy, and people WILL end up using the wrong terminology :)


Second, you say:

	"Note that support for DTLS, ICE and TURN ARE required for a WebRTC-compatible endpoint, and if RTP is used at all, DTLS-SRTP MUST be used."

You already in the bullet list said support of ICE lite, so the text is conflicting. 

I am not sure what you mean by "support for TURN". An ICE lite endpoint will not create TURN candidates etc. Of course, it may receive media via a TURN server.

What do you mean by "support for DTLS"? I think you need to be a little more specific (later you do mention DTLS-SRTP in case of RTP).

Regards,

Christer




-----Original Message-----
From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Harald Alvestrand
Sent: 3. lokakuuta 2014 10:44
To: rtcweb@ietf.org
Subject: [rtcweb] Definitions of WebRTC entities

After all the feedback, I've taken another whack at this.

It seems that the term "WebRTC endpoint" is already used widely enough that it's worth continuing to use it. So I ended up with the following suggested text for -overview's definitions.

Comments?
If this seems OK, I'll emit another -overview next week with these definitions.

--------------------------

    o  A WebRTC User Agent (also called an UA or browser) is something that conforms to both the protocol specification and the Javascript API defined above.

    o  A WebRTC device is something that conforms to the protocol
       specification, but does not claim to implement the Javascript API.

    o  A WebRTC endpoint is either a WebRTC UA or a WebRTC device.

    o  A WebRTC-compatible endpoint is an endpoint that is capable of successfully communicating with a WebRTC endpoint, but may fail to meet some requirement of the WebRTC endpoint. This may limit where in the network such an endpoint can be attached, or may limit the security guarantees that it offers to others.

    o  A WebRTC gateway is a WebRTC-compatible endpoint that mediates media traffic to non-WebRTC entities.

-----------------------------

FOR TRANSPORT:

A WebRTC-compatible endpoint is capable of inititating or accepting a session with a WebRTC endpoint. The following requirements on a WebRTC endpoint are not required for such success:

- Support for full ICE. If the endpoint is only ever going to be attached to the public Internet, it does not need to be able to fix its own external address; ICE-Lite is enough.
- Support for the full suite of MTI codecs for a WebRTC endpoint. In particular, audio gateways that connect to native G.711 networks may choose to implement G.711 and not implement Opus.
- Offering BUNDLE or RTCP-MUX
- Using MSID in its offers or answers
<should congestion cutoff requirement be in or out?> <there will be more>

Note that support for DTLS, ICE and TURN ARE required for a WebRTC-compatible endpoint, and if RTP is used at all, DTLS-SRTP MUST be used.


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