[rtcweb] IETF#91: Notes from 1st RTCWEB session

Christer Holmberg <christer.holmberg@ericsson.com> Fri, 28 November 2014 13:03 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 []) by ietfa.amsl.com (Postfix) with ESMTP id CB3F81A1AD3 for <rtcweb@ietfa.amsl.com>; Fri, 28 Nov 2014 05:03:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.6
X-Spam-Status: No, score=-3.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id yKDFiqgj6zHk for <rtcweb@ietfa.amsl.com>; Fri, 28 Nov 2014 05:03:38 -0800 (PST)
Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EF8F1A1AFB for <rtcweb@ietf.org>; Fri, 28 Nov 2014 05:03:37 -0800 (PST)
X-AuditID: c1b4fb30-f79d66d00000744c-e7-547872a6da25
Received: from ESESSHC007.ericsson.se (Unknown_Domain []) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 61.44.29772.6A278745; Fri, 28 Nov 2014 14:03:35 +0100 (CET)
Received: from ESESSMB209.ericsson.se ([]) by ESESSHC007.ericsson.se ([]) with mapi id 14.03.0195.001; Fri, 28 Nov 2014 14:03:34 +0100
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: "rtcweb@ietf.org" <rtcweb@ietf.org>
Thread-Topic: IETF#91: Notes from 1st RTCWEB session
Thread-Index: AdALC6+4hyPFqCLJRbuI4SCmIfNy1A==
Date: Fri, 28 Nov 2014 13:03:33 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1D53EF61@ESESSMB209.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D53EF61ESESSMB209erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNLMWRmVeSWpSXmKPExsUyM+Jvje7yoooQg877PBZzdj1gslj7r53d gcljyZKfTB5fLn9mC2CK4rJJSc3JLEst0rdL4MqYs7eBseDGbcaKS5c3sjcw/j3I2MXIySEh YCJx9Mk3NghbTOLCvfVgtpDAEUaJi4dTuxi5gOwljBL3O9cBJTg42AQsJLr/aYPUiAioS1x+ eIEdxGYWcJTY3beDCcQWFtCX2LpvIyNIuQjQ/O45PhDlehLfDzSBlbAIqEpc/LkI7AReAV+J y+tesoLYjEAnfD+1hglipLjErSfzmSBOE5BYsuc8M4QtKvHy8T9WCFtJ4seGSywgq5gF8iXu LE2HGCkocXLmE5YJjMKzkEyahVA1C0kVRImOxILdn9ggbG2JZQtfM8PYZw48ZkIWX8DIvopR tDi1OCk33chIL7UoM7m4OD9PLy+1ZBMjMHYObvltsIPx5XPHQ4wCHIxKPLwFshUhQqyJZcWV uYcYpTlYlMR5F56bFywkkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qBcbum6Hzf1NK9Mkvu3pSX iklwVmTztv2x6VBMg/CD8+UdCiYf38+8elnEa0sOX3j5Qqt5iq8dC468256S9Gz+p67Uk7vy jqxPM99Y/vXGzpRXHVY1n576Xz3wV91122KxCZXWogGLa2ak//+iddvS1u9O5Mmvc7er5i09 ZRo4/Su74S8rNuM5/5RYijMSDbWYi4oTAej2LDl+AgAA
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/RUoK1s8Rg2vEFcabE9MZqja4XQ0
Cc: "rtcweb-chairs@tools.ietf.org" <rtcweb-chairs@tools.ietf.org>
Subject: [rtcweb] IETF#91: Notes from 1st RTCWEB session
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, 28 Nov 2014 13:03:43 -0000


Below are my notes from the 1st RTCWEB session.





Draft: draft-ietf-rtcweb-jsep-08

Presenter: Eric Rescola

Presentation of the updates in the latest version of the draft.

m- line considerations:

Indicated that the SDP fingerprint attribute will be used to indicate that DTLS-SRTP is used.

It was commented that the fingerprint attribute is currently optional in the SCTP-SDP draft. Indicated that it sounds like an error in the SCTP-SDP draft.

BUNDLE clarification:

It was commented that a JavaScript application cannot request a browser to not offer BUNDLE, in case it is known that the remote peer does not support BUNDLE. Indicated that BUNDLE works with such peers, as BUNDLE will be disabled if not supported by the peer.

BUNDLE/MUX policy (#91):

Question whether we need to be able to explicitly specify usage of rtcp-mux. Why can't the max-bundle option implicitly include usage of rtcp-mux? Indicated that it has previously been stated that one may want to do max BUNDLE, but not use rtcp-mux.


Value of {local/remote} description when closed (#88).

OUTCOME: This belongs to the W3C spec. No need to say anything in the JSEP draft.

a=ssrc for a=recvonly m= lines (#79):

OUTCOME: The suggested proposal was not accepted. Some more thinking about this is needed.

Death of a one-way stream (#76)

Indicated that we need a way to indicate, for a given m- line, "I am never going to send media associated with this m- line again" and "I never want to receive media associated with this m- line again".

Indicated that it has previously been agreed to bring the issue to MMUSIC, but that has not yet happened. A volunteer is needed.

OUTCOME: This issue needs to be brought to MMUSIC, but unclear who will bring it.

Signaling synchronization (#31):

OUTCOME: If LS is not indicated, streams are synchronized if they share the same CNAME value.

Changing b= (#9):

It was indicated that Magnus was supposed to produce text, and that a new volunteer is needed. However, it was unclear what the issue is.

OUTCOME: Agreed to wait until Magnus comes back, as the issue will most likely delay the JSEP draft.

Topic:WebRTC Data Channels

Draft: draft-ietf-rtcweb-data-channel

Presenter: Salvatore Loreto

Provided status update based on the IESG review. There are no DISCUSSes, but some COMMENTs.

Indicated that we need to decide whether to use DTLS 1.0 or DTLS 1.2.

Indicated that DTLS 1.2 is not widely available at this stage.


- MUST support 1.0, SHOULD support latest version.

- No objection to having a reference to RFC 6347.

- We need to adjust the crypto suites (Cullen)

Topic: WebRTC Terminology

Draft: draft-ietf-rtcweb-overview

Presenter: Harald Alvestrand

The discussion focused on the split between a WebRTC browser and a WebRTC device. It was indicated that "device" terminology is confusing.

It was suggested to talk about "native applications" instead of "devices".

It was suggested to simply talk about "non-browsers" instead of "devices".

It was asked whether a browser plug-in, providing WebRTC JavaScript API functionality to a non-WebRTC browser, is considered a "browser" or a "device". The combination of the browser and the plug-in is considered a "browser".

It was asked whether a non-JavaScript library, very similar to the WebRTC JavaScript API, providing similar functionality, the WebRTC API to a non-WebRTC browser, is considered a "browser" or a "device".

OUTCOME: It was agreed to talk about "browsers" and "non-browsers", and the next version of the draft will incorporate that terminology.

Topic: Recursively Encapsulated TURN (RETURN) for Connectivity and Privacy in WebRTC

Draft: draft-schwartz-rtcweb-return

Presenter: Justin Uberti

It was realized that very few people had read the draft.

Half of the participants thought the draft should be adopted as a WG draft.

OUTCOME: Further discussions on the list are needed, before a decision to adopt the draft can be made.

Topic: WebRTC Gateways

Draft: draft-alvestrand-rtcweb-gateways

Presenter: Harald Alvestrand

Indicated that gateways are not part of the core WebRTC architecture, but they are never the less important in order to be able to achieve interoperability between WebRTC devices and legacy devices and systems.

Described how gateway are different from WebRTC browsers, related to security considerations, support of features (e.g. ICE), specific codecs etc.

Indicated that it was previously agreed to add a section about gateway to the common overview document, rather than having a separate document. Indicated the minutes from the previous meeting indicate that having a separate document for gateway was the preferred way forward.

OUTCOME: Further discussions on the list are needed, before a decision to adopt the draft can be made.