Return-Path: 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 CB3F81A1AD3 for ; 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-Level: 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yKDFiqgj6zHk for ; Fri, 28 Nov 2014 05:03:38 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 ; Fri, 28 Nov 2014 05:03:37 -0800 (PST) X-AuditID: c1b4fb30-f79d66d00000744c-e7-547872a6da25 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.124]) 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 ([169.254.9.126]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0195.001; Fri, 28 Nov 2014 14:03:34 +0100 From: Christer Holmberg To: "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-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] 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" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Nov 2014 13:03:43 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D53EF61ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Below are my notes from the 1st RTCWEB session. Regards, Christer ---------------- Topic:JSEP 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 th= e SCTP-SDP draft. Indicated that it sounds like an error in the SCTP-SDP dr= aft. 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 dis= abled 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? Ind= icated that it has previously been stated that one may want to do max BUNDL= E, but not use rtcp-mux. OUTCOME: ??? 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=3Dssrc for a=3Drecvonly m=3D 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 t= o 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 bri= ng it. Signaling synchronization (#31): OUTCOME: If LS is not indicated, streams are synchronized if they share the= same CNAME value. Changing b=3D (#9): It was indicated that Magnus was supposed to produce text, and that a new v= olunteer is needed. However, it was unclear what the issue is. OUTCOME: Agreed to wait until Magnus comes back, as the issue will most lik= ely 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, bu= t 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. OUTCOME: - 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 d= evice. 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 fun= ctionality 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 J= avaScript API, providing similar functionality, the WebRTC API to a non-Web= RTC 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 a= dopt 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 t= hey are never the less important in order to be able to achieve interoperab= ility between WebRTC devices and legacy devices and systems. Described how gateway are different from WebRTC browsers, related to securi= ty considerations, support of features (e.g. ICE), specific codecs etc. Indicated that it was previously agreed to add a section about gateway to t= he common overview document, rather than having a separate document. Indica= ted the minutes from the previous meeting indicate that having a separate d= ocument for gateway was the preferred way forward. OUTCOME: Further discussions on the list are needed, before a decision to a= dopt the draft can be made. --_000_7594FB04B1934943A5C02806D1A2204B1D53EF61ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Below are my notes from the 1st RTCWEB session.=

 

Regards,

 

Christer

 

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

 

 

Topic:JSEP

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 th= at 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 supp= ort 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.

 

OUTCOME: ???

 

 

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=3Dssrc for a=3Drecvonly m=3D lines (#79):

 

OUTCOME: The suggested proposal was not accepted. Some more thinking about this i= s 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 MMUSI= C, but that has not yet happened. A volunteer is needed.<= /p>

 

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=3D (#9):

 <= /u>

It was indicated that Magnus was supposed to produce text, and that a ne= w 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 de= lay 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.

 

OUTCOME:

 

- 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 WebRT= C device. It was indicated that “device” terminology is confusi= ng.

 

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 WebRT= C 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-browse= rs”, and the next version of the draft will incorporate that terminol= ogy.

 

 

 

Topic: Recursively Encapsulated TURN (RETURN) for Co= nnectivity 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 dra= ft.

 

OUTCOME: Further discussions on the list are needed, before a decision to adopt t= he 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, bu= t they are never the less important in order to be able to achieve interope= rability between WebRTC devices and legacy devices and systems.

 

Described how gateway are different from WebRTC browsers, related to sec= urity considerations, support of features (e.g. ICE), specific codecs etc.<= o:p>

 

Indicated that it was previously agreed to add a section about gateway t= o the common overview document, rather than having a separate document. Ind= icated 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 t= he draft can be made.

 

 

--_000_7594FB04B1934943A5C02806D1A2204B1D53EF61ESESSMB209erics_--