From nobody Tue Jan 5 11:56:11 2016 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 A64ED1B2D5F for ; Tue, 5 Jan 2016 11:56:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3] autolearn=no 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 COHGDUpmdLBG for ; Tue, 5 Jan 2016 11:56:09 -0800 (PST) Received: from mail-yk0-x234.google.com (mail-yk0-x234.google.com [IPv6:2607:f8b0:4002:c07::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25DAB1B2D5E for ; Tue, 5 Jan 2016 11:56:09 -0800 (PST) Received: by mail-yk0-x234.google.com with SMTP id x67so293088020ykd.2 for ; Tue, 05 Jan 2016 11:56:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to:content-type :content-transfer-encoding; bh=gHv9q+ZivHiF+vQ8JBySDl6jJk1KIcJfXR+zyV9TYew=; b=WFRkzMeKCATacFgzpFIxTV6BdBw7oeYdlNcTivyb/KrJbj8nORb8tjE/AKXjdx0/+x vgblzqlly7YfVLFtcXTlLENeFSO0mRnJFOq18bjxGizJ+WgzrNTGzqN+QOKbH3ZnlPvv 6dVoBzV5XZHG/wVRekAX8Ii28MFzo5ichOeUuqcOH0/SV4gugJHtL/W9cX3N0S4L1RGB AmyecKalYpBrYwhpmBZJu+L4vIs0OyWfKnrWkABeCYgq2hco/OMju5I/HQUd3xcMDMEg 9o2XuIkWeZ1N1UHYtkcN6npvUtC+FRCQ1R3NyN8EsLf2HK1b68HjVpY6mMv7Ldg1M7OB nSVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type:content-transfer-encoding; bh=gHv9q+ZivHiF+vQ8JBySDl6jJk1KIcJfXR+zyV9TYew=; b=Dw84g4oyUv3duLSrnW8R57vho+SAELPxgZudvrEuWqe8Zs1XfDJfCq+jEVG9piz/t5 4FHOg7pgbj32yxYrsrLmJi6KY8lRqOr59n+4snWFKPuvrc6E0mnUHohuVFftUtLTHUN4 1rmhY1ahGQQNESYXQW2Vr69BhetnugTM3L9lX5q1U+3m1DrXYVjpeQgI0a7U1W6Ijzvz 9sLh5XMtgHlus5cqsME6VRfS0Qo8uzeTFEN4NDOS2GYdVf9RFC3tfRTldvfU3auvXLYA 6VTMfgltaLGnwAmnLEGwbXzdUSSH11CR6HSxInpiXcCice9051AUf/ZHKBYXXC6T2fU4 PIrA== X-Gm-Message-State: ALoCoQnesKutKOqqggD/pJxrmaM3fBI/u2+Efs/iUWJ6GeQ5bZn/i5xVwqbxsulx6fEBGiMXqRSKYIqwjullD/xzy569wenb8g== X-Received: by 10.13.196.197 with SMTP id g188mr70686985ywd.209.1452023768399; Tue, 05 Jan 2016 11:56:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.193.194 with HTTP; Tue, 5 Jan 2016 11:55:49 -0800 (PST) From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Tue, 5 Jan 2016 20:55:49 +0100 Message-ID: To: "rtcweb@ietf.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [rtcweb] Is "use_srtp" DTLS extension required if just DataChannel is requested? 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: Tue, 05 Jan 2016 19:56:10 -0000 If a WebRTC endpoint acting as DTLS client just wants to offer a DataChannel (and not audio or video) should it also include the "use_srtp" DTLS extension? Should a WebRTC endpoint acting as DTLS server reject the DTLS handshake if the DTLS client did not include the "use_srtp" DTLS extension? Thanks. --=20 I=C3=B1aki Baz Castillo From nobody Tue Jan 5 13:36:30 2016 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 2F8601A92ED for ; Tue, 5 Jan 2016 13:36:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no 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 ymJWi6AVoH0Q for ; Tue, 5 Jan 2016 13:36:27 -0800 (PST) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFDDB1A92E7 for ; Tue, 5 Jan 2016 13:36:27 -0800 (PST) Received: by mail-ig0-x230.google.com with SMTP id ik10so20344782igb.1 for ; Tue, 05 Jan 2016 13:36:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=W/W4SEsvRMC5a7mwRqn7Fx6JGR8KpyEBv/S6DEC47uI=; b=bR5XD1gzZM5mLgliu7fQLC31hJRrRvriHXsm4IJP+aoAAZSxQBUvI5QRlamnRHxUXR rya39cVVEx9vyBXrGhca+lYCIk9GZJXwhIXEWb6LyIF1cqZ7geRMwvOrUzw1SgShIU94 wwTYOgWMGVCtov4VTwtPUm+xiQSJ/54IZ7hXR+Gbf/abYaKGh8CfXvW2IAyDRisiIZco oiQ8QmIEY/yNhu1sfWQZCoW8eES5P0tLK0Kph1heorgMJjSmddOxICtDLVYqnXqvqPZh Y7oVvy7eIaJ8lUNTF0BzPcN4ZfrXouozBjfg95GlWNwxdbYjyo8bpw7mDySnTJ6r2Wjp ietQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=W/W4SEsvRMC5a7mwRqn7Fx6JGR8KpyEBv/S6DEC47uI=; b=kTuTwFyUk1RKK/YtcLuiOU/HsawMrBO94sonMebEjVzWWKsMJ59XD+teyT87iIlK4A yH2hV1D+kTiXQbDBRAoaLBruFqegHHvk0tr6g4ywKhlFmY3EtuWqn4pTaPnjR4AYdSiT jdTsWCPyMYWQY9wno/TS768N0AnYnabSByAuhN8iQiMf6KqiLK3FKm5EWsOL+YGxN6Uk /8fSPXPzpWOiiq24tgUE0itdCrG8m3QMRY6cRkGzxg4J2jVU+UV8zgshD16/MT6/P9sI 1XlGSJwfJmkVv8qb8CSSA5G9jbI6AGlyRaJxiCzdXmh+knWudf0/n5yAIllFsR3l8tah wn2g== X-Gm-Message-State: ALoCoQlgp2PibuGNNHLuqGANWWTwj7KgBB9m1Pf5B6mPO2twMSjO2M+OY/bT6kUxSKD3iu8ccA63T0Jing69f+tTfuksARwzWQ== X-Received: by 10.50.137.98 with SMTP id qh2mr5176412igb.75.1452029787172; Tue, 05 Jan 2016 13:36:27 -0800 (PST) Received: from mail-ig0-f180.google.com (mail-ig0-f180.google.com. [209.85.213.180]) by smtp.gmail.com with ESMTPSA id d132sm20208272ioe.12.2016.01.05.13.36.25 for (version=TLSv1/SSLv3 cipher=OTHER); Tue, 05 Jan 2016 13:36:26 -0800 (PST) Received: by mail-ig0-f180.google.com with SMTP id ik10so20344361igb.1 for ; Tue, 05 Jan 2016 13:36:25 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.50.88.7 with SMTP id bc7mr5868990igb.24.1452029785560; Tue, 05 Jan 2016 13:36:25 -0800 (PST) Received: by 10.36.105.15 with HTTP; Tue, 5 Jan 2016 13:36:25 -0800 (PST) In-Reply-To: References: Date: Tue, 5 Jan 2016 16:36:25 -0500 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=089e01184168928ab405289d0758 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Is "use_srtp" DTLS extension required if just DataChannel is requested? 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: Tue, 05 Jan 2016 21:36:29 -0000 --089e01184168928ab405289d0758 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I think the decision was that "use_srtp" DTLS extension is required and DTLS server should reject the handshake if this extension is not offered. This was decided since it is difficult to predict if RTP would be added in the bundle over the same transport in some point in the future. Without "use_srtp" DTLS extension being present from the start adding RTP would require negotiating a whole new transport including ICE setup since "use_srtp" extension cannot be added to an existing DTLS association. _____________ Roman Shpount On Tue, Jan 5, 2016 at 2:55 PM, I=C3=B1aki Baz Castillo wro= te: > If a WebRTC endpoint acting as DTLS client just wants to offer a > DataChannel (and not audio or video) should it also include the > "use_srtp" DTLS extension? > > Should a WebRTC endpoint acting as DTLS server reject the DTLS > handshake if the DTLS client did not include the "use_srtp" DTLS > extension? > > Thanks. > > -- > I=C3=B1aki Baz Castillo > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --089e01184168928ab405289d0758 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I think the decision was that=C2=A0"use_srtp" DTLS extension is required = and DTLS server should reject the handshake if this extension is not offere= d. This was decided since it is difficult to predict if RTP would be added = in the bundle over the same transport in some point in the future. Without= =C2=A0"use_sr= tp" DTLS extension being present from the start adding RTP would requi= re negotiating a whole new transport including ICE setup since "use_sr= tp" extension cannot be added to an existing DTLS association.<= /div>

_____________
Roman Shpount

On Tue, Jan 5, 2016 at 2:55 PM, I=C3=B1aki B= az Castillo <ibc@aliax.net> wrote:
If a WebRTC endpoint acting as DTLS client just wants to offer a
DataChannel (and not audio or video) should it also include the
"use_srtp" DTLS extension?

Should a WebRTC endpoint acting as DTLS server reject the DTLS
handshake if the DTLS client did not include the "use_srtp" DTLS<= br> extension?

Thanks.

--
I=C3=B1aki Baz Castillo
<ibc@aliax.net>

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

--089e01184168928ab405289d0758-- From nobody Tue Jan 5 13:37:38 2016 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 B422E1A92EE for ; Tue, 5 Jan 2016 13:37:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3] autolearn=no 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 mkZ_fkWpnqel for ; Tue, 5 Jan 2016 13:37:37 -0800 (PST) Received: from mail-yk0-x229.google.com (mail-yk0-x229.google.com [IPv6:2607:f8b0:4002:c07::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBFD31A92ED for ; Tue, 5 Jan 2016 13:37:36 -0800 (PST) Received: by mail-yk0-x229.google.com with SMTP id a85so218760350ykb.1 for ; Tue, 05 Jan 2016 13:37:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=/uvc2IwfAh65IwsWdHLHmrnaxvzghgS+vfylProDyio=; b=DB3V21GCj/mWEQCZ+xDnBK0KcutP9G6Wi5krpDBLdTwxp/oEHw7Fydn9/33gMdy7Iq AbGbmzmWzvUBIxThw4/k7DN5H8q69KW3TtYRgfOdPCbMp/10EhZyiTvezoMTkZZ5lHPN UoRoyagO2fUNMNacPlH1mQJYAFZcqlmB5gcHADlDUGTuZgQAo5ObimokRXuPKQEkA/Nm G9mQl5a4fHNRk5/PT/qfuFR9JPfW14IhPg+edEiJ9tPek8CGzD2/LoVas+4KqCjcP5a/ LZaSTMqmCZjQP8JckFJQX2MUkV9zwqWqukgqnKVjZRJDd/LHhyNiFr+hmOKJrH466Q1E gciA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=/uvc2IwfAh65IwsWdHLHmrnaxvzghgS+vfylProDyio=; b=lU7c+cTsVmyZulFG0JY947WnGONHUzhFBWAZvsynI+iL4lHGyNd8YSaiApOryih+nb 4AmAy5qL7X9JOHTTfa8x+y+XnF58E4O77ipsm0UGVYhY9yZ6nxGz0jT9tZ1Oa9vd9C/O brasJjpkMT787PQu6+h22SsZF3AMdaRCKSsv4YsNciBKbIzSDmRLueTMvEvKKhnrxW+R NgC+wSr7Z8VGQlH9gRhSfaQ8np73kjXyAfHC5Owlp94/XnMU8mq8lCotol+i0/AmZ+OI /2RiP+j3yF6H14tRw3qe8vaNTVPxbiDK63mWC5J2JORPHhBaXjdBjAjChM9FADKmYyZF NB6Q== X-Gm-Message-State: ALoCoQmbqMBKp3yThwP5IrUmojdw3w94C0mQwMDB2660/JmC2wMCWW1igDEPTmaezszGKSSj7xc1FV3j7GUb5Trp0SJ5huDkEw== X-Received: by 10.129.9.212 with SMTP id 203mr49245340ywj.30.1452029856098; Tue, 05 Jan 2016 13:37:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.193.194 with HTTP; Tue, 5 Jan 2016 13:37:16 -0800 (PST) In-Reply-To: References: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Tue, 5 Jan 2016 22:37:16 +0100 Message-ID: To: Roman Shpount Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Is "use_srtp" DTLS extension required if just DataChannel is requested? 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: Tue, 05 Jan 2016 21:37:37 -0000 2016-01-05 22:36 GMT+01:00 Roman Shpount : > I think the decision was that "use_srtp" DTLS extension is required and D= TLS > server should reject the handshake if this extension is not offered. This > was decided since it is difficult to predict if RTP would be added in the > bundle over the same transport in some point in the future. Without > "use_srtp" DTLS extension being present from the start adding RTP would > require negotiating a whole new transport including ICE setup since > "use_srtp" extension cannot be added to an existing DTLS association. Clear. Thanks. --=20 I=C3=B1aki Baz Castillo From nobody Thu Jan 7 07:37:49 2016 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 C4C601A8F49 for ; Thu, 7 Jan 2016 07:37:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.799 X-Spam-Level: X-Spam-Status: No, score=-0.799 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_16=0.6, J_CHICKENPOX_32=0.6, SPF_PASS=-0.001] autolearn=no 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 ROjKehIe1CeU for ; Thu, 7 Jan 2016 07:37:47 -0800 (PST) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B12861A8F48 for ; Thu, 7 Jan 2016 07:37:46 -0800 (PST) Received: by mail-wm0-x234.google.com with SMTP id f206so129493434wmf.0 for ; Thu, 07 Jan 2016 07:37:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=DRHqt+mhG4sli2Xn6EQs4TsvsD0dfs21d+4tuQs+ztw=; b=ZMWULAp6uPYb7gQtwcV3gHOLnRUrin1NFSNw7Y990cmkCwiesdpTodklj5b4fzvLAC v151wRlTizKmuy3Zq4UXcbheZYsmLvHMoMTsmZqn2IninMbCjjEIj/JMVEcXr1LBjJby pGcYwGDMIMEQjnKM1S9bQ0nRAnOv1gArBYQZFlCsJ6FuedROjWH3pRai9z51UaLXrFF+ 8yAW0s1K1INUFo85bTckwqzshstwcYeNhyaNzn+PTaHyRCa/69D8tJ6lxBv3DagYvOp5 DEz3ziGz2eb44B4yI9yEwRGgzemFOdAALne9c/BL+RH1qn/8HlBJ8E0U/0w8b0mCpFPe bFLw== X-Received: by 10.28.216.211 with SMTP id p202mr18064557wmg.84.1452181065308; Thu, 07 Jan 2016 07:37:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.27.104.215 with HTTP; Thu, 7 Jan 2016 07:37:25 -0800 (PST) From: Bernard Aboba Date: Thu, 7 Jan 2016 07:37:25 -0800 Message-ID: To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=001a1147127c8c1f720528c04079 Archived-At: Subject: [rtcweb] JSEP: "VoiceActivityDetection" option and cient-mixer "vad" extension 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: Thu, 07 Jan 2016 15:37:47 -0000 --001a1147127c8c1f720528c04079 Content-Type: text/plain; charset=UTF-8 JSEP Section 5.2.3.4 discusses the implications of the "VoiceActivityDetection" option for the offer. One thing that is not covered is whether the "VoiceActivityDetection" option determines whether the client-mixer "vad" extension is set to "on" or "off". For example, I believe that the W3C WEBRTC WG determined that the client-mixer extension (support for which is required in RTP-Usage) should always be advertised in the offer. RFC 6464 Section 4 gives an example of the a=extmap line: a=extmap:6 urn:ietf:params:rtp-hdrext:ssrc-audio-level vad=on So, my question is whether "vad=on" or "vad=off" is determined by the "VoiceActivityDetection" option, or if not, whether there is a setting (e.g. "vad=on") that is always present in the offer. --001a1147127c8c1f720528c04079 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
JSEP Section 5.2.3.4 discusses the implications of the &qu= ot;VoiceActivityDetection" option for the offer.=C2=A0

<= div>One thing that is not covered is whether the "VoiceActivityDetecti= on" option determines whether the client-mixer "vad" extensi= on is set to "on" or "off". =C2=A0

=
For example, I believe that the W3C WEBRTC WG determined that the clie= nt-mixer extension (support for which is required in RTP-Usage) should alwa= ys be advertised in the offer.=C2=A0 RFC 6464 Section 4 gives an example of= the a=3Dextmap line:=C2=A0

=
a=3Dextmap:6 urn:ietf:params:rtp-hdrext:ssrc-audio-level vad=3Don

So, my question is whether "vad=3Don" or "vad=3Doff"=
; is determined by the "VoiceActivityDetection" option, or if not=
, whether there is a setting (e.g. "vad=3Don") that is always pre=
sent in the offer.=C2=A0
--001a1147127c8c1f720528c04079-- From nobody Fri Jan 8 16:20:20 2016 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 CEB641B2CCA; Fri, 8 Jan 2016 16:20:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 MFmjcsNClOnc; Fri, 8 Jan 2016 16:20:13 -0800 (PST) Received: from mail-io0-f169.google.com (mail-io0-f169.google.com [209.85.223.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA3051B2CC9; Fri, 8 Jan 2016 16:20:09 -0800 (PST) Received: by mail-io0-f169.google.com with SMTP id 77so271285312ioc.2; Fri, 08 Jan 2016 16:20:09 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-type; bh=IoSNs7urxYGgKNgbZjMZ0aqlsZMBf8fnI6PksDggqio=; b=g/vyAynqRm+4boMocbGjnk89EWF7P8jvfUqUXNJkg0eFRctWa/b23UEcdVHULjT9P9 VCsvhFjJIwyZuCwPukzQRPSoNCIoxEMbgJg18l0KZTjmstrhtQ6ILIi7qhMC66RLOjpn VnyEyQjvDH0vIinnv3d2osoBVReVtQ0rDTEKs4964q9AdvFluC5X8Wax8KjSltm8dDBC YFXLC1QSyNXYR3MATf2zvsKjFm+vqCHkd86SqBAgt4B4qa27blvp5pFJgQpbfK++dZ8a YUIBrsKlMlqTOari4fdywCJHpICm5QpGN1om9yczX/9wzFT5LMqwArLxVAlCVHL/gRst jwaw== X-Received: by 10.107.170.212 with SMTP id g81mr89168011ioj.44.1452298809085; Fri, 08 Jan 2016 16:20:09 -0800 (PST) MIME-Version: 1.0 References: <563B01C9.6060801@ericsson.com> In-Reply-To: <563B01C9.6060801@ericsson.com> From: Justin Uberti Date: Sat, 09 Jan 2016 00:19:59 +0000 Message-ID: To: Magnus Westerlund , "rtcweb@ietf.org" , draft-ietf-rtcweb-fec@ietf.org, "juberti/m@aol.com" Content-Type: multipart/mixed; boundary=001a11425b709fbb5c0528dbaaca Archived-At: Subject: Re: [rtcweb] Comments on draft-ietf-rtcweb-fec-02 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: Sat, 09 Jan 2016 00:20:20 -0000 --001a11425b709fbb5c0528dbaaca Content-Type: multipart/alternative; boundary=001a11425b709fbb560528dbaac8 --001a11425b709fbb560528dbaac8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Finally got around to updating the document. Comments inline; new version of the doc attached. On Wed, Nov 4, 2015 at 11:15 PM Magnus Westerlund < magnus.westerlund@ericsson.com> wrote: > Hi, > > A. Section 3.2: > > I think the draft should note that some RTP Payload format, including > several of the one recommended in > draft-ietf-rtcweb-audio-codecs-for-interop-02, do support internal > redundancy. The codecs that I know for a fact can do this within the > payload format are: AMR and AMR-WB. > > I would suggest adding some sentence on that time delayed redundancy may > be supported by codecs, and give AMR and AMR-WB as examples. > I added a section on AMR/AMR-WB that parallels the Opus section. > > B. Section 4. > > I think this draft should consider the recommended drafts in > draft-ietf-rtcweb-audio-codecs-for-interop-02. Here we clearly can > consider internal redundancy for AMR and AMR-WB. > Done. > > C. Section 4.2 > > There are a parameter in AMR and AMR-WB that can negotiate how much > redundancy one may include: max-red > I mentioned this parameter in the doc. Do you want to recommend a default value? > > D. Section 5.1: > > The receiver can demultiplex the incoming FEC stream by > SSRC and correlate it with the primary stream via the ssrc-group > mechanism. > > Given that FlexFEC has built in indication of which SSRC that are > included in protection, why include it in SDP? For the purpose to > indicate selectively which streams that should have FEC protection? > > You also need a reference for "ssrc-group" if intended to be supported > going forward? > Agree. Left as a TODO for now until I can sort out the details. > > E. Section 5.2, first paragraph: > > This section needs clearer references to SDP. > Not sure exactly what you had in mind here. > > F. Section 6. > > WebRTC also supports the ability to send generic application data, > and provides transport-level retransmission mechanisms that the > application can use to ensure that its data is delivered reliably. > > > This should informationally reference data channel. > Done. > > G. Section 6. > > I think this section should say even less. Just note that SCTP has > reliable and semi-reliable modes and the application can control it. > Nothing more. > I don't see a problem with mentioning the app can do its own FEC if it wants. I did adjust the first para to mention the reliability modes more explicitly. > > H. Section 7. > > To support the functionality recommended above, implementations MUST > support the redundant encoding mechanism described in [RFC2198] > > For which Codecs does on need to support this? > Added detail on this. > > I. Section 7. > > the FEC mechanism described in [RFC5956] and > [I-D.ietf-payload-flexible-fec-scheme] > > As RFC5956 is not a FEC mechanism, only a grouping mechanism I think > this need to be reformulated. > Removed that part. > > J. Section 9. > > This section needs to be clearer that an implementation is expected to > adapt the amount of FEC to the seen packet loss rate to ensure > sufficient protection. And that adaptation must take into account the > available network resources (Bandwidth) to trade-off media quality and > what streams can be sent with use of FEC. > That's what this paragraph says, I think, but I rewrote it a bit to try to make this more clear. > > Cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=C3=A4r=C3=B6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > --001a11425b709fbb560528dbaac8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Finally got around to updating the document. Comments inli= ne; new version of the doc attached.

On Wed, Nov 4, 2015 at 11:15 PM Magnus Westerlund <magnus.westerlund@ericsson.com> wrote:
Hi,

A. Section 3.2:

I think the draft should note that some RTP Payload format, including
several of the one recommended in
draft-ietf-rtcweb-audio-codecs-for-interop-02, do support internal
redundancy. The codecs that I know for a fact can do this within the
payload format are: AMR and AMR-WB.

I would suggest adding some sentence on that time delayed redundancy may be supported by codecs, and give AMR and AMR-WB as examples.

I added a section on AMR/AMR-WB that parallels the Op= us section.=C2=A0

B. Section 4.

I think this draft should consider the recommended drafts in
draft-ietf-rtcweb-audio-codecs-for-interop-02. Here we clearly can
consider internal redundancy for AMR and AMR-WB.

<= /div>
Done.=C2=A0

C. Section 4.2

There are a parameter in AMR and AMR-WB that can negotiate how much
redundancy one may include: max-red

I m= entioned this parameter in the doc. Do you want to recommend a default valu= e?=C2=A0

D. Section 5.1:

=C2=A0 =C2=A0 The receiver can demultiplex the incoming FEC stream by
=C2=A0 =C2=A0 SSRC and correlate it with the primary stream via the ssrc-gr= oup
=C2=A0 =C2=A0 mechanism.

Given that FlexFEC has built in indication of which SSRC that are
included in protection, why include it in SDP? For the purpose to
indicate selectively which streams that should have FEC protection?

You also need a reference for "ssrc-group" if intended to be supp= orted
going forward?

Agree. Left as a TODO fo= r now until I can sort out the details.=C2=A0

E. Section 5.2, first paragraph:

This section needs clearer references to SDP.

Not sure exactly what you had in mind here.=C2=A0

F. Section 6.

=C2=A0 =C2=A0 WebRTC also supports the ability to send generic application = data,
=C2=A0 =C2=A0 and provides transport-level retransmission mechanisms that t= he
=C2=A0 =C2=A0 application can use to ensure that its data is delivered reli= ably.


This should informationally reference data channel.
Done.=C2=A0

G. Section 6.

I think this section should say even less. Just note that SCTP has
reliable and semi-reliable modes and the application can control it.
Nothing more.

I don't see a problem= with mentioning the app can do its own FEC if it wants. I did adjust the f= irst para to mention the reliability modes more explicitly.=C2=A0

H. Section 7.

=C2=A0 =C2=A0 To support the functionality recommended above, implementatio= ns MUST
=C2=A0 =C2=A0 support the redundant encoding mechanism described in [RFC219= 8]

For which Codecs does on need to support this?

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| = Phone=C2=A0 +46 10 7148287
F=C3=A4r=C3=B6gatan 6=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0| Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------

--001a11425b709fbb560528dbaac8-- --001a11425b709fbb5c0528dbaaca Content-Type: text/plain; charset=US-ASCII; name="draft-ietf-rtcweb-fec (3).txt" Content-Disposition: attachment; filename="draft-ietf-rtcweb-fec (3).txt" Content-Transfer-Encoding: base64 Content-ID: <15223c09ea62de22a5d1> X-Attachment-Id: 15223c09ea62de22a5d1 CgoKCk5ldHdvcmsgV29ya2luZyBHcm91cCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIEouIFViZXJ0aQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBHb29nbGUKSW50ZW5kZWQgc3RhdHVzOiBTdGFu ZGFyZHMgVHJhY2sgICAgICAgICAgICAgICAgICAgICAgICAgSmFudWFyeSA4LCAyMDE2CkV4cGly ZXM6IEp1bHkgMTEsIDIwMTYKCgogICAgICAgICAgICAgIFdlYlJUQyBGb3J3YXJkIEVycm9yIENv cnJlY3Rpb24gUmVxdWlyZW1lbnRzCiAgICAgICAgICAgICAgICAgICAgICAgIGRyYWZ0LWlldGYt cnRjd2ViLWZlYy0wMwoKQWJzdHJhY3QKCiAgIFRoaXMgZG9jdW1lbnQgcHJvdmlkZXMgaW5mb3Jt YXRpb24gYW5kIHJlcXVpcmVtZW50cyBmb3IgaG93IEZvcndhcmQKICAgRXJyb3IgQ29ycmVjdGlv biAoRkVDKSBzaG91bGQgYmUgdXNlZCBieSBXZWJSVEMgYXBwbGljYXRpb25zLgoKU3RhdHVzIG9m IFRoaXMgTWVtbwoKICAgVGhpcyBJbnRlcm5ldC1EcmFmdCBpcyBzdWJtaXR0ZWQgaW4gZnVsbCBj b25mb3JtYW5jZSB3aXRoIHRoZQogICBwcm92aXNpb25zIG9mIEJDUCA3OCBhbmQgQkNQIDc5LgoK ICAgSW50ZXJuZXQtRHJhZnRzIGFyZSB3b3JraW5nIGRvY3VtZW50cyBvZiB0aGUgSW50ZXJuZXQg RW5naW5lZXJpbmcKICAgVGFzayBGb3JjZSAoSUVURikuICBOb3RlIHRoYXQgb3RoZXIgZ3JvdXBz IG1heSBhbHNvIGRpc3RyaWJ1dGUKICAgd29ya2luZyBkb2N1bWVudHMgYXMgSW50ZXJuZXQtRHJh ZnRzLiAgVGhlIGxpc3Qgb2YgY3VycmVudCBJbnRlcm5ldC0KICAgRHJhZnRzIGlzIGF0IGh0dHA6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kcmFmdHMvY3VycmVudC8uCgogICBJbnRlcm5ldC1EcmFm dHMgYXJlIGRyYWZ0IGRvY3VtZW50cyB2YWxpZCBmb3IgYSBtYXhpbXVtIG9mIHNpeCBtb250aHMK ICAgYW5kIG1heSBiZSB1cGRhdGVkLCByZXBsYWNlZCwgb3Igb2Jzb2xldGVkIGJ5IG90aGVyIGRv Y3VtZW50cyBhdCBhbnkKICAgdGltZS4gIEl0IGlzIGluYXBwcm9wcmlhdGUgdG8gdXNlIEludGVy bmV0LURyYWZ0cyBhcyByZWZlcmVuY2UKICAgbWF0ZXJpYWwgb3IgdG8gY2l0ZSB0aGVtIG90aGVy IHRoYW4gYXMgIndvcmsgaW4gcHJvZ3Jlc3MuIgoKICAgVGhpcyBJbnRlcm5ldC1EcmFmdCB3aWxs IGV4cGlyZSBvbiBKdWx5IDExLCAyMDE2LgoKQ29weXJpZ2h0IE5vdGljZQoKICAgQ29weXJpZ2h0 IChjKSAyMDE2IElFVEYgVHJ1c3QgYW5kIHRoZSBwZXJzb25zIGlkZW50aWZpZWQgYXMgdGhlCiAg IGRvY3VtZW50IGF1dGhvcnMuICBBbGwgcmlnaHRzIHJlc2VydmVkLgoKICAgVGhpcyBkb2N1bWVu dCBpcyBzdWJqZWN0IHRvIEJDUCA3OCBhbmQgdGhlIElFVEYgVHJ1c3QncyBMZWdhbAogICBQcm92 aXNpb25zIFJlbGF0aW5nIHRvIElFVEYgRG9jdW1lbnRzCiAgIChodHRwOi8vdHJ1c3RlZS5pZXRm Lm9yZy9saWNlbnNlLWluZm8pIGluIGVmZmVjdCBvbiB0aGUgZGF0ZSBvZgogICBwdWJsaWNhdGlv biBvZiB0aGlzIGRvY3VtZW50LiAgUGxlYXNlIHJldmlldyB0aGVzZSBkb2N1bWVudHMKICAgY2Fy ZWZ1bGx5LCBhcyB0aGV5IGRlc2NyaWJlIHlvdXIgcmlnaHRzIGFuZCByZXN0cmljdGlvbnMgd2l0 aCByZXNwZWN0CiAgIHRvIHRoaXMgZG9jdW1lbnQuICBDb2RlIENvbXBvbmVudHMgZXh0cmFjdGVk IGZyb20gdGhpcyBkb2N1bWVudCBtdXN0CiAgIGluY2x1ZGUgU2ltcGxpZmllZCBCU0QgTGljZW5z ZSB0ZXh0IGFzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDQuZSBvZgogICB0aGUgVHJ1c3QgTGVnYWwg UHJvdmlzaW9ucyBhbmQgYXJlIHByb3ZpZGVkIHdpdGhvdXQgd2FycmFudHkgYXMKICAgZGVzY3Jp YmVkIGluIHRoZSBTaW1wbGlmaWVkIEJTRCBMaWNlbnNlLgoKCgoKCgpVYmVydGkgICAgICAgICAg ICAgICAgICAgIEV4cGlyZXMgSnVseSAxMSwgMjAxNiAgICAgICAgICAgICAgICAgW1BhZ2UgMV0K DApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgV2ViUlRDIEZFQyAgICAgICAgICAgICAg ICAgICBKYW51YXJ5IDIwMTYKCgpUYWJsZSBvZiBDb250ZW50cwoKICAgMS4gIEludHJvZHVjdGlv biAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICAyCiAg IDIuICBUZXJtaW5vbG9neSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuICAgMgogICAzLiAgVHlwZXMgb2YgRkVDICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDIKICAgICAzLjEuICBTZXBhcmF0ZSBGRUMgU3Ry ZWFtIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICAzCiAgICAgMy4yLiAg UmVkdW5kYW50IEVuY29kaW5nICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu ICAgMwogICAgIDMuMy4gIENvZGVjLVNwZWNpZmljIEluLWJhbmQgRkVDICAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAgIDMKICAgNC4gIEZFQyBmb3IgQXVkaW8gQ29udGVudCAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA0CiAgICAgNC4xLiAgUmVjb21tZW5k ZWQgTWVjaGFuaXNtIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNAogICAg IDQuMi4gIE5lZ290aWF0aW5nIFN1cHBvcnQgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAgIDQKICAgNS4gIEZFQyBmb3IgVmlkZW8gQ29udGVudCAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA1CiAgICAgNS4xLiAgUmVjb21tZW5kZWQgTWVjaGFu aXNtIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNQogICAgIDUuMi4gIE5l Z290aWF0aW5nIFN1cHBvcnQgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAg IDUKICAgNi4gIEZFQyBmb3IgQXBwbGljYXRpb24gQ29udGVudCAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gICA2CiAgIDcuICBJbXBsZW1lbnRhdGlvbiBSZXF1aXJlbWVudHMgLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNgogICA4LiAgQWRhcHRpdmUgVXNlIG9m IEZFQyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDYKICAgOS4g IFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gICA2CiAgIDEwLiBJQU5BIENvbnNpZGVyYXRpb25zIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNwogICAxMS4gQWNrbm93bGVkZ2VtZW50cyAgLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDcKICAgMTIuIFJlZmVyZW5j ZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA3 CiAgICAgMTIuMS4gIE5vcm1hdGl2ZSBSZWZlcmVuY2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuICAgNwogICAgIDEyLjIuICBJbmZvcm1hdGl2ZSBSZWZlcmVuY2VzIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDcKICAgQXBwZW5kaXggQS4gIENoYW5nZSBs b2cgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA4CiAgIEF1dGhv cidzIEFkZHJlc3MgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuICAgOQoKMS4gIEludHJvZHVjdGlvbgoKICAgSW4gc2l0dWF0aW9ucyB3aGVyZSBwYWNrZXQg bG9zcyBpcyBoaWdoLCBvciBwZXJmZWN0IG1lZGlhIHF1YWxpdHkgaXMKICAgZXNzZW50aWFsLCBG b3J3YXJkIEVycm9yIENvcnJlY3Rpb24gKEZFQykgY2FuIGJlIHVzZWQgdG8gcHJvYWN0aXZlbHkK ICAgcmVjb3ZlciBmcm9tIHBhY2tldCBsb3NzZXMuICBUaGlzIHNwZWNpZmljYXRpb24gcHJvdmlk ZXMgZ3VpZGFuY2Ugb24KICAgd2hpY2ggRkVDIG1lY2hhbmlzbXMgdG8gdXNlLCBhbmQgaG93IHRv IHVzZSB0aGVtLCBmb3IgV2ViUlRDIGNsaWVudAogICBpbXBsZW1lbnRhdGlvbnMuCgoyLiAgVGVy bWlub2xvZ3kKCiAgIFRoZSBrZXkgd29yZHMgIk1VU1QiLCAiTVVTVCBOT1QiLCAiUkVRVUlSRUQi LCAiU0hBTEwiLCAiU0hBTEwgTk9UIiwKICAgIlNIT1VMRCIsICJTSE9VTEQgTk9UIiwgIlJFQ09N TUVOREVEIiwgIk1BWSIsIGFuZCAiT1BUSU9OQUwiIGluIHRoaXMKICAgZG9jdW1lbnQgYXJlIHRv IGJlIGludGVycHJldGVkIGFzIGRlc2NyaWJlZCBpbiBbUkZDMjExOV0uCgozLiAgVHlwZXMgb2Yg RkVDCgogICBCeSBpdHMgbmFtZSwgRkVDIGRlc2NyaWJlcyB0aGUgc2VuZGluZyBvZiByZWR1bmRh bnQgaW5mb3JtYXRpb24gaW4gYW4KICAgb3V0Z29pbmcgcGFja2V0IHN0cmVhbSBzbyB0aGF0IGlu Zm9ybWF0aW9uIGNhbiBzdGlsbCBiZSByZWNvdmVyZWQKICAgZXZlbiBpbiB0aGUgZmFjZSBvZiBw YWNrZXQgbG9zcy4gIFRoZXJlIGFyZSBtdWx0aXBsZSB3YXlzIGluIHdoaWNoCiAgIHRoaXMgY2Fu IGJlIGFjY29tcGxpc2hlZDsgdGhpcyBzZWN0aW9uIGVudW1lcmF0ZXMgdGhlIHZhcmlvdXMKICAg bWVjaGFuaXNtcyBhbmQgZGVzY3JpYmVzIHRoZWlyIHRyYWRlb2Zmcy4KCgoKClViZXJ0aSAgICAg ICAgICAgICAgICAgICAgRXhwaXJlcyBKdWx5IDExLCAyMDE2ICAgICAgICAgICAgICAgICBbUGFn ZSAyXQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICBXZWJSVEMgRkVDICAgICAgICAg ICAgICAgICAgIEphbnVhcnkgMjAxNgoKCjMuMS4gIFNlcGFyYXRlIEZFQyBTdHJlYW0KCiAgIFRo aXMgYXBwcm9hY2gsIGFzIGRlc2NyaWJlZCBpbiBbUkZDNTk1Nl0sIFNlY3Rpb24gNC4zLCBzZW5k cyBGRUMKICAgcGFja2V0cyBhcyBhbiBpbmRlcGVuZGVudCBTU1JDLW11bHRpcGxleGVkIHN0cmVh bSwgd2l0aCBpdHMgb3duIFNTUkMKICAgYW5kIHBheWxvYWQgdHlwZS4gIFdoaWxlIGJ5IGZhciB0 aGUgbW9zdCBmbGV4aWJsZSwgZWFjaCBGRUMgcGFja2V0CiAgIHdpbGwgaGF2ZSBpdHMgb3duIElQ K1VEUCtSVFArRkVDIGhlYWRlciwgbGVhZGluZyB0byBhZGRpdGlvbmFsCiAgIG92ZXJoZWFkIG9m IHRoZSBGRUMgc3RyZWFtLgoKMy4yLiAgUmVkdW5kYW50IEVuY29kaW5nCgogICBUaGlzIGFwcHJv YWNoLCBhcyBkZXNjaWJlZCBpbiBbUkZDMjE5OF0sIGFsbG93cyBmb3IgcmVkdW5kYW50IGRhdGEg dG8KICAgYmUgcGlnZ3liYWNrZWQgb24gYW4gZXhpc3RpbmcgcHJpbWFyeSBlbmNvZGluZywgYWxs IGluIGEgc2luZ2xlCiAgIHBhY2tldC4gIFRoaXMgcmVkdW5kYW50IGRhdGEgbWF5IGJlIGFuIGV4 YWN0IGNvcHkgb2YgYSBwcmV2aW91cwogICBwYWNrZXQsIG9yIGZvciBjb2RlY3MgdGhhdCBzdXBw b3J0IHZhcmlhYmxlLWJpdHJhdGUgZW5jb2RpbmdzLAogICBwb3NzaWJseSBhIHNtYWxsZXIsIGxv d2VyLXF1YWxpdHkgcmVwcmVzZW50YXRpb24uICBJbiBjZXJ0YWluIGNhc2VzLAogICB0aGUgcmVk dW5kYW50IGRhdGEgY291bGQgaW5jbHVkZSBtdWx0aXBsZSBwcmlvciBwYWNrZXRzLgoKICAgU2lu Y2UgdGhlcmUgaXMgb25seSBhIHNpbmdsZSBzZXQgb2YgcGFja2V0IGhlYWRlcnMsIHRoaXMgYXBw cm9hY2gKICAgYWxsb3dzIGZvciBhIHZlcnkgZWZmaWNpZW50IHJlcHJlc2VudGF0aW9uIG9mIHBy aW1hcnkgKyByZWR1bmRhbnQKICAgZGF0YS4gIEhvd2V2ZXIsIHRoaXMgc2F2aW5ncyBpcyBvbmx5 IHJlYWxpemVkIHdoZW4gdGhlIGRhdGEgYWxsIGZpdHMKICAgaW50byBhIHNpbmdsZSBwYWNrZXQg KGkuZS4gdGhlIHNpemUgaXMgbGVzcyB0aGFuIGEgTVRVKS4gIEFzIGEKICAgcmVzdWx0LCB0aGlz IGFwcHJvYWNoIGlzIGdlbmVyYWxseSBub3QgdXNlZnVsIGZvciB2aWRlbyBjb250ZW50LgoKMy4z LiAgQ29kZWMtU3BlY2lmaWMgSW4tYmFuZCBGRUMKCiAgIFNvbWUgYXVkaW8gY29kZWNzLCBub3Rh Ymx5IE9wdXMgW1JGQzY3MTZdIGFuZCBBTVIgW1JGQzQ4NjddIHN1cHBvcnQKICAgdGhlaXIgb3du IGluLWJhbmQgRkVDIG1lY2hhbmlzbSwgd2hlcmUgcmVkdW5kYW50IGRhdGEgaXMgaW5jbHVkZWQg aW4KICAgdGhlIGNvZGVjIHBheWxvYWQuCgogICBGb3IgT3B1cywgcGFja2V0cyBkZWVtZWQgYXMg aW1wb3J0YW50IGFyZSByZS1lbmNvZGVkIGF0IGEgbG93ZXIKICAgYml0cmF0ZSBhbmQgYWRkZWQg dG8gdGhlIHN1YnNlcXVlbnQgcGFja2V0LCBhbGxvd2luZyBwYXJ0aWFsIHJlY292ZXJ5CiAgIG9m IGEgbG9zdCBwYWNrZXQuICBUaGlzIHNjaGVtZSBpcyBmYWlybHkgZWZmaWNpZW50OyBleHBlcmlt ZW50cwogICBwZXJmb3JtZWQgaW5kaWNhdGUgdGhhdCB3aGVuIE9wdXMgRkVDIGlzIHVzZWQsIHRo ZSBvdmVyaGVhZCBpbXBvc2VkCiAgIGlzIGFib3V0IDIwLTMwJSwgZGVwZW5kaW5nIG9uIHRoZSBh bW91bnQgb2YgcHJvdGVjdGlvbiBuZWVkZWQuICBOb3RlCiAgIHRoYXQgdGhpcyBtZWNoYW5pc20g Y2FuIG9ubHkgY2FycnkgcmVkdW5kYW5jeSBpbmZvcm1hdGlvbiBmb3IgdGhlCiAgIGltbWVkaWF0 ZWx5IHByZWNlZGluZyBwYWNrZXQ7IGFzIHN1Y2ggdGhlIGRlY29kZXIgY2Fubm90IGZ1bGx5CiAg IHJlY292ZXIgbXVsdGlwbGUgY29uc2VjdXRpdmUgbG9zdCBwYWNrZXRzLiAgU2VlIFtSRkM2NzE2 XSwKICAgU2VjdGlvbiAyLjEuNyBmb3IgY29tcGxldGUgZGV0YWlscy4KCiAgIEZvciBBTVIvQU1S LVdCLCBwYWNrZXRzIGNhbiBjb250YWluIGNvcGllcyBvciBsb3dlci1xdWFsaXR5IGVuY29kaW5n cwogICBvZiBtdWx0aXBsZSBwcmlvciBhdWRpbyBmcmFtZXMuICBUaGlzIG1lY2hhbmlzbSBpcyBz aW1pbGFyIHRvIHRoZQogICBbUkZDMjE5OF0gbWVjaGFuaXNtIGRlc2NyaWJlZCBhYm92ZSwgYnV0 IGFzIGl0IGFkZHMgbm8gYWRkaXRpb25hbAogICBmcmFtaW5nLCBpdCBjYW4gYmUgc2xpZ2h0bHkg bW9yZSBlZmZpY2llbnQuICBTZWUgW1JGQzQ4NjddLAogICBTZWN0aW9uIDMuNy4xIGZvciBkZXRh aWxzIG9uIHRoaXMgbWVjaGFuaXNtLgoKCgoKCgoKVWJlcnRpICAgICAgICAgICAgICAgICAgICBF eHBpcmVzIEp1bHkgMTEsIDIwMTYgICAgICAgICAgICAgICAgIFtQYWdlIDNdCgwKSW50ZXJuZXQt RHJhZnQgICAgICAgICAgICAgICAgIFdlYlJUQyBGRUMgICAgICAgICAgICAgICAgICAgSmFudWFy eSAyMDE2CgoKNC4gIEZFQyBmb3IgQXVkaW8gQ29udGVudAoKICAgVGhlIGZvbGxvd2luZyBzZWN0 aW9uIHByb3ZpZGVzIGd1aWRhbmNlIG9uIGhvdyB0byBiZXN0IHVzZSBGRUMgZm9yCiAgIHRyYW5z bWl0dGluZyBhdWRpbyBkYXRhLiAgQXMgaW5kaWNhdGVkIGluIFNlY3Rpb24gOCBiZWxvdywgRkVD IHNob3VsZAogICBvbmx5IGJlIGFjdGl2YXRlZCBpZiBuZXR3b3JrIGNvbmRpdGlvbnMgd2FycmFu dCBpdCwgb3IgdXBvbiBleHBsaWNpdAogICBhcHBsaWNhdGlvbiByZXF1ZXN0LgoKNC4xLiAgUmVj b21tZW5kZWQgTWVjaGFuaXNtCgogICBXaGVuIHVzaW5nIHRoZSBPcHVzIGNvZGVjLCB1c2Ugb2Yg dGhlIGJ1aWx0LWluIE9wdXMgRkVDIG1lY2hhbmlzbSBpcwogICBSRUNPTU1FTkRFRC4gIFRoaXMg cHJvdmlkZXMgcmVhc29uYWJsZSBwcm90ZWN0aW9uIG9mIHRoZSBhdWRpbyBzdHJlYW0KICAgYWdh aW5zdCB0eXBpY2FsIGxvc3Nlcywgd2l0aCBtb2Rlc3Qgb3ZlcmhlYWQuICBOb3RlIHRoYXQgYXMg aW5kaWNhdGVkCiAgIGFib3ZlIHRoZSBidWlsdC1pbiBPcHVzIEZFQyBvbmx5IHByb3ZpZGVzIHNp bmdsZS1mcmFtZSByZWR1bmRhbmN5OyBpZgogICBtdWx0aS1wYWNrZXQgcHJvdGVjdGlvbiBpcyBu ZWVkZWQsIHRoZSBidWlsdC1pbiBGRUMgc2hvdWxkIGJlCiAgIGNvbWJpbmVkIHdpdGggW1JGQzIx OThdIHJlZHVuZGFuY3kgdG8gcHJvdGVjdCB0aGUgTi0ydGgsIE4tM3JkLCBldGMuCiAgIHBhY2tl dHMuCgogICBXaGVuIHVzaW5nIHRoZSBBTVIvQU1SLVdCIGNvZGVjcywgdXNlIG9mIHRoZWlyIGJ1 aWx0LWluIEZFQyBtZWNoYW5pc20KICAgaXMgUkVDT01NRU5ERUQuICBUaGlzIHByb3ZpZGVzIHNs aWdodGx5IG1vcmUgZWZmaWNpZW50IHByb3RlY3Rpb24gb2YKICAgdGhlIGF1ZGlvIHN0cmVhbSB0 aGFuIFtSRkMyMTk4XS4KCiAgIFdoZW4gdXNpbmcgdmFyaWFibGUtYml0cmF0ZSBjb2RlY3Mgd2l0 aG91dCBhbiBpbnRlcm5hbCBGRUMsIFtSRkMyMTk4XQogICByZWR1bmRhbnQgZW5jb2Rpbmcgd2l0 aCBsb3dlci1maWRlbGl0eSB2ZXJzaW9uKHMpIG9mIHByZXZpb3VzCiAgIHBhY2tldChzKSBpcyBS RUNPTU1FTkRFRC4gIFRoaXMgcHJvdmlkZXMgcmVhc29uYWJsZSBwcm90ZWN0aW9uIG9mIHRoZQog ICBwYXlsb2FkIHdpdGggbW9kZXJhdGUgb3ZlcmhlYWQuCgogICBXaGVuIHVzaW5nIGNvbnN0YW50 LWJpdHJhdGUgY29kZWNzLCBlLmcuICBQQ01VLCB1c2Ugb2YgW1JGQzIxOThdCiAgIHJlZHVuZGFu dCBlbmNvZGluZyBNQVkgYmUgdXNlZCwgYnV0IG5vdGUgdGhhdCB0aGlzIHdpbGwgcmVzdWx0IGlu IGEKICAgcG90ZW50aWFsbHkgc2lnbmlmaWNhbnQgYml0cmF0ZSBpbmNyZWFzZSwgYW5kIHRoYXQg c3VkZGVubHkKICAgaW5jcmVhc2luZyBiaXRyYXRlIHRvIGRlYWwgd2l0aCBsb3NzZXMgZnJvbSBj b25nZXN0aW9uIG1heSBhY3R1YWxseQogICBtYWtlIHRoaW5ncyB3b3JzZS4KCiAgIEJlY2F1c2Ug b2YgdGhlIGxvd2VyIHBhY2tldCByYXRlIG9mIGF1ZGlvIGVuY29kaW5ncywgdXN1YWxseSBhIHNp bmdsZQogICBwYWNrZXQgcGVyIGZyYW1lLCB1c2Ugb2YgYSBzZXBhcmF0ZSBGRUMgc3RyZWFtIGNv bWVzIHdpdGggYSBoaWdoZXIKICAgb3ZlcmhlYWQgdGhhbiBvdGhlciBtZWNoYW5pc21zLCBhbmQg dGhlcmVmb3JlIGlzIE5PVCBSRUNPTU1FTkRFRC4KCjQuMi4gIE5lZ290aWF0aW5nIFN1cHBvcnQK CiAgIFN1cHBvcnQgZm9yIHJlZHVuZGFudCBlbmNvZGluZyBjYW4gYmUgaW5kaWNhdGVkIGJ5IG9m ZmVyaW5nICJyZWQiIGFzCiAgIGEgc3VwcG9ydGVkIHBheWxvYWQgdHlwZSBpbiB0aGUgb2ZmZXIu ICBBbnN3ZXJlcnMgY2FuIHJlamVjdCB0aGUgdXNlCiAgIG9mIHJlZHVuZGFudCBlbmNvZGluZyBi eSBub3QgaW5jbHVkaW5nICJyZWQiIGFzIGEgc3VwcG9ydGVkIHBheWxvYWQKICAgdHlwZSBpbiB0 aGUgYW5zd2VyLgoKICAgU3VwcG9ydCBmb3IgY29kZWMtc3BlY2lmaWMgRkVDIG1lY2hhbmlzbXMg YXJlIHR5cGljYWxseSBpbmRpY2F0ZWQgdmlhCiAgICJhPWZtdHAiIHBhcmFtZXRlcnMuCgogICBG b3IgT3B1cywgc3VwcG9ydCBmb3IgRkVDIGF0IHRoZSByZWNlaXZlZCBzaWRlIGlzIGNvbnRyb2xs ZWQgYnkgdGhlCiAgICJ1c2VpbmJhbmRmZWM9MSIgcGFyYW1ldGVyLCBhcyBzcGVjaWZpZWQgaW4K CgoKVWJlcnRpICAgICAgICAgICAgICAgICAgICBFeHBpcmVzIEp1bHkgMTEsIDIwMTYgICAgICAg ICAgICAgICAgIFtQYWdlIDRdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgIFdlYlJU QyBGRUMgICAgICAgICAgICAgICAgICAgSmFudWFyeSAyMDE2CgoKICAgW0ktRC5pZXRmLXBheWxv YWQtcnRwLW9wdXNdLiAgVGhpcyBwYXJhbWV0ZXIgaXMgZGVjbGFyYXRpdmUgYW5kIGNhbgogICBi ZSBuZWdvdGlhdGVkIHNlcGFyYXRlbHkgZm9yIGVpdGhlciBtZWRpYSBkaXJlY3Rpb24uCgogICBG b3IgQU1SL0FNUi1XQiwgc3VwcG9ydCBmb3IgcmVkdW5kYW50IGVuY29kaW5nLCBhbmQgdGhlIG1h eGltdW0KICAgc3VwcG9ydGVkIGRlcHRoLCBhcmUgY29udHJvbGxlZCBieSB0aGUgJ21heC1yZWQn IHBhcmFtZXRlciwgYXMKICAgc3BlY2lmaWVkIGluIFtSRkM0ODY3XSwgU2VjdGlvbiA4LjEuICBb VE9ETzogZmlndXJlIG91dCBhbnkKICAgYWRkaXRpb25hbCByZWNvbW1lbmRhdGlvbnMgYXJlIG5l ZWRlZC5dCgo1LiAgRkVDIGZvciBWaWRlbyBDb250ZW50CgogICBUaGUgZm9sbG93aW5nIHNlY3Rp b24gcHJvdmlkZXMgZ3VpZGFuY2Ugb24gaG93IHRvIGJlc3QgdXNlIEZFQyBmb3IKICAgdHJhbnNt aXR0aW5nIHZpZGVvIGRhdGEuICBBcyBpbmRpY2F0ZWQgaW4gU2VjdGlvbiA4IGJlbG93LCBGRUMg c2hvdWxkCiAgIG9ubHkgYmUgYWN0aXZhdGVkIGlmIG5ldHdvcmsgY29uZGl0aW9ucyB3YXJyYW50 IGl0LCBvciB1cG9uIGV4cGxpY2l0CiAgIGFwcGxpY2F0aW9uIHJlcXVlc3QuCgo1LjEuICBSZWNv bW1lbmRlZCBNZWNoYW5pc20KCiAgIEZvciB2aWRlbyBjb250ZW50LCB1c2Ugb2YgYSBzZXBhcmF0 ZSBGRUMgc3RyZWFtIHdpdGggdGhlIFJUUCBwYXlsb2FkCiAgIGZvcm1hdCBkZXNjcmliZWQgaW4g W0ktRC5pZXRmLXBheWxvYWQtZmxleGlibGUtZmVjLXNjaGVtZV0gaXMKICAgUkVDT01NRU5ERUQu ICBUaGUgcmVjZWl2ZXIgY2FuIGRlbXVsdGlwbGV4IHRoZSBpbmNvbWluZyBGRUMgc3RyZWFtIGJ5 CiAgIFNTUkMgYW5kIGNvcnJlbGF0ZSBpdCB3aXRoIHRoZSBwcmltYXJ5IHN0cmVhbSB2aWEgdGhl IHNzcmMtZ3JvdXAKICAgbWVjaGFuaXNtLiAgW1RPRE86IHJlcGxhY2Ugd2l0aCBSSURdCgogICBT dXBwb3J0IGZvciBwcm90ZWN0aW5nIG11bHRpcGxlIHByaW1hcnkgc3RyZWFtcyB3aXRoIGEgc2lu Z2xlIEZFQwogICBzdHJlYW0gaXMgY29tcGxpY2F0ZWQgYnkgV2ViUlRDJ3MgMS1tLWxpbmUtcGVy LXN0cmVhbSBwb2xpY3ksIHdoaWNoCiAgIGRvZXMgbm90IGFsbG93IGZvciBhIG0tbGluZSBkZWRp Y2F0ZWQgc3BlY2lmaWNhbGx5IHRvIEZFQy4KCjUuMi4gIE5lZ290aWF0aW5nIFN1cHBvcnQKCiAg IFRvIG9mZmVyIHN1cHBvcnQgZm9yIGEgc2VwYXJhdGUgU1NSQy1tdWx0aXBsZXhlZCBGRUMgc3Ry ZWFtLCB0aGUKICAgb2ZmZXJlciBNVVNUIG9mZmVyIG9uZSBvZiB0aGUgZm9ybWF0cyBkZXNjcmli ZWQgaW4KICAgW0ktRC5pZXRmLXBheWxvYWQtZmxleGlibGUtZmVjLXNjaGVtZV0sIFNlY3Rpb24g NS4xLCBhcyB3ZWxsIGFzIGEKICAgc3NyYy1ncm91cCB3aXRoICJGRUMtRlIiIHNlbWFudGljcyBh cyBkZXNjcmliZWQgaW4gW1JGQzU5NTZdLAogICBTZWN0aW9uIDQuMy4gIFtUT0RPOiByZXBsYWNl IHdpdGggUklEXQoKICAgVXNlIG9mIEZFQy1vbmx5IG0tbGluZXMsIGFuZCBncm91cGluZyB1c2lu ZyB0aGUgU0RQIGdyb3VwIG1lY2hhbmlzbSwKICAgaXMgbm90IGN1cnJlbnRseSBkZWZpbmVkIGZv ciBXZWJSVEMsIGFuZCBTSE9VTEQgTk9UIGJlIG9mZmVyZWQuCgogICBBbnN3ZXJlcnMgY2FuIHJl amVjdCB0aGUgdXNlIG9mIFNTUkMtbXVsdGlwbGV4ZWQgRkVDLCBieSBub3QKICAgaW5jbHVkaW5n IEZFQyBwYXlsb2FkIHR5cGVzIGluIHRoZSBhbnN3ZXIuCgogICBBbnN3ZXJlcnMgU0hPVUxEIHJl amVjdCBhbnkgRkVDLW9ubHkgbS1saW5lcywgdW5sZXNzIHRoZXkKICAgc3BlY2lmaWNhbGx5IGtu b3cgaG93IHRvIGhhbmRsZSBzdWNoIGEgdGhpbmcgaW4gYSBXZWJSVEMgY29udGV4dAogICAocGVy aGFwcyBkZWZpbmVkIGJ5IGEgZnV0dXJlIHZlcnNpb24gb2YgdGhlIFdlYlJUQyBzcGVjaWZpY2F0 aW9ucykuCiAgIFRoaXMgZW5zdXJlcyB0aGF0IGltcGxlbWVudGF0aW9ucyB3aWxsIG5vdCBtYWxm dW5jdGlvbiB3aGVuIHNhaWQKICAgZnV0dXJlIHZlcnNpb24gb2YgV2ViUlRDIGVuYWJsZXMgb2Zm ZXJzIG9mIEZFQy1vbmx5IG0tbGluZXMuCgoKCgoKVWJlcnRpICAgICAgICAgICAgICAgICAgICBF eHBpcmVzIEp1bHkgMTEsIDIwMTYgICAgICAgICAgICAgICAgIFtQYWdlIDVdCgwKSW50ZXJuZXQt RHJhZnQgICAgICAgICAgICAgICAgIFdlYlJUQyBGRUMgICAgICAgICAgICAgICAgICAgSmFudWFy eSAyMDE2CgoKNi4gIEZFQyBmb3IgQXBwbGljYXRpb24gQ29udGVudAoKICAgV2ViUlRDIGFsc28g c3VwcG9ydHMgdGhlIGFiaWxpdHkgdG8gc2VuZCBnZW5lcmljIGFwcGxpY2F0aW9uIGRhdGEsCiAg IGFuZCBwcm92aWRlcyB0cmFuc3BvcnQtbGV2ZWwgcmV0cmFuc21pc3Npb24gbWVjaGFuaXNtcyB0 byBzdXBwb3J0CiAgIGZ1bGwgYW5kIHBhcnRpYWwgKGUuZy4gdGltZWQpIHJlbGlhYmlsaXR5LiAg U2VlCiAgIFtJLUQuaWV0Zi1ydGN3ZWItZGF0YS1jaGFubmVsXSBmb3IgZGV0YWlscy4KCiAgIEJl Y2F1c2UgdGhlIGFwcGxpY2F0aW9uIGNhbiBjb250cm9sIGV4YWN0bHkgd2hhdCBkYXRhIHRvIHNl bmQsIGl0IGhhcwogICB0aGUgYWJpbGl0eSB0byBtb25pdG9yIHBhY2tldCBzdGF0aXN0aWNzIGFu ZCBwZXJmb3JtIGl0cyBvd24KICAgYXBwbGljYXRpb24tbGV2ZWwgRkVDLCBpZiBuZWNlc3Nhcnku CgogICBBcyBhIHJlc3VsdCwgdGhpcyBkb2N1bWVudCBtYWtlcyBubyByZWNvbW1lbmRhdGlvbnMg cmVnYXJkaW5nIEZFQyBmb3IKICAgdGhlIHVuZGVybHlpbmcgZGF0YSB0cmFuc3BvcnQuCgo3LiAg SW1wbGVtZW50YXRpb24gUmVxdWlyZW1lbnRzCgogICBUbyBzdXBwb3J0IHRoZSBmdW5jdGlvbmFs aXR5IHJlY29tbWVuZGVkIGFib3ZlLCBpbXBsZW1lbnRhdGlvbnMgTVVTVAogICBzdXBwb3J0IHRo ZSByZWxldmFudCBtZWNoYW5pc21zIGZvciB0aGVpciBzdXBwb3J0ZWQgYXVkaW8gY29kZWNzLCBh cwogICBkZXNjcmliZWQgaW4gU2VjdGlvbiA0LCBhbmQgdGhlIGdlbmVyYWwgRkVDIG1lY2hhbmlz bSBkZXNjcmliZWQgaW4KICAgW0ktRC5pZXRmLXBheWxvYWQtZmxleGlibGUtZmVjLXNjaGVtZV0u CgogICBJbXBsZW1lbnRhdGlvbnMgTUFZIHN1cHBvcnQgYWRkaXRpb25hbCBGRUMgbWVjaGFuaXNt cyBpZiBkZXNpcmVkLAogICBlLmcuICBbUkZDNTEwOV0uCgo4LiAgQWRhcHRpdmUgVXNlIG9mIEZF QwoKICAgU2luY2UgdXNlIG9mIEZFQyBjYXVzZXMgcmVkdW5kYW50IGRhdGEgdG8gYmUgdHJhbnNt aXR0ZWQsIHRoaXMgd2lsbAogICBsZWFkIHRvIGxlc3MgYmFuZHdpZHRoIGF2YWlsYWJsZSBmb3Ig dGhlIHByaW1hcnkgZW5jb2RpbmcsIHdoZW4gaW4gYQogICBiYW5kd2lkdGgtY29uc3RyYWluZWQg ZW52aXJvbm1lbnQuICBHaXZlbiB0aGlzLCBXZWJSVEMKICAgaW1wbGVtZW50YXRpb25zIFNIT1VM RCBvbmx5IHRyYW5zbWl0IHRoZSBhbW91bnQgb2YgRkVDIG5lZWRlZCB0bwogICBwcm90ZWN0IGFn YWluc3QgdGhlIG9ic2VydmVkIHBhY2tldCBsb3NzICh3aGljaCBjYW4gYmUgZGV0ZXJtaW5lZCwK ICAgZS5nLiwgYnkgbW9uaXRvcmluZyB0cmFuc21pdCBwYWNrZXQgbG9zcyBkYXRhIGZyb20gUlRD UCBSZWNlaXZlcgogICBSZXBvcnRzKSwgb3IgdGhlIGFwcGxpY2F0aW9uIGluZGljYXRlcyBpdCBp cyB3aWxsaW5nIHRvIHBheSBhIHF1YWxpdHkKICAgcGVuYWx0eSB0byBwcm9hY3RpdmVseSBhdm9p ZCBsb3NzZXMuCgo5LiAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMKCiAgIFRoaXMgZG9jdW1lbnQg bWFrZXMgcmVjb21tZW5kYXRpb25zIHJlZ2FyZGluZyB0aGUgdXNlIG9mIEZFQy4KICAgR2VuZXJh bGx5LCBpdCBzaG91bGQgYmUgbm90ZWQgdGhhdCBhbHRob3VnaCBhcHBseWluZyByZWR1bmRhbmN5 IGlzCiAgIG9mdGVuIHVzZWZ1bCBpbiBwcm90ZWN0aW5nIGEgc3RyZWFtIGFnYWluc3QgcGFja2V0 IGxvc3MsIGlmIHRoZSBsb3NzCiAgIGlzIGNhdXNlZCBieSBuZXR3b3JrIGNvbmdlc3Rpb24sIHRo ZSBhZGRpdGlvbmFsIGJhbmR3aWR0aCB1c2VkIGJ5IHRoZQogICByZWR1bmRhbnQgZGF0YSBtYXkg YWN0dWFsbHkgbWFrZSB0aGUgc2l0dWF0aW9uIHdvcnNlLCBhbmQgY2FuIGxlYWQgdG8KICAgc2ln bmlmaWNhbnQgZGVncmFkYXRpb24gb2YgdGhlIG5ldHdvcmsuCgogICBBZGRpdGlvbmFsIHNlY3Vy aXR5IGNvbnNpZGVyYXRpb25zIGZvciBlYWNoIGluZGl2aWR1YWwgRkVDIG1lY2hhbmlzbQogICBh cmUgZW51bWVyYXRlZCBpbiB0aGVpciByZXNwZWN0aXZlIGRvY3VtZW50cy4KCgoKCgpVYmVydGkg ICAgICAgICAgICAgICAgICAgIEV4cGlyZXMgSnVseSAxMSwgMjAxNiAgICAgICAgICAgICAgICAg W1BhZ2UgNl0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgV2ViUlRDIEZFQyAgICAg ICAgICAgICAgICAgICBKYW51YXJ5IDIwMTYKCgoxMC4gIElBTkEgQ29uc2lkZXJhdGlvbnMKCiAg IFRoaXMgZG9jdW1lbnQgcmVxdWlyZXMgbm8gYWN0aW9ucyBmcm9tIElBTkEuCgoxMS4gIEFja25v d2xlZGdlbWVudHMKCiAgIFNldmVyYWwgcGVvcGxlIHByb3ZpZGVkIHNpZ25pZmljYW50IGlucHV0 IGludG8gdGhpcyBkb2N1bWVudCwKICAgaW5jbHVkaW5nIEpvbmF0aGFuIExlbm5veCwgR2lyaSBN YW5keWFtLCBWYXJ1biBTaW5naCwgVGltIFRlcnJpYmVycnksCiAgIGFuZCBNbyBaYW5hdHkuCgox Mi4gIFJlZmVyZW5jZXMKCjEyLjEuICBOb3JtYXRpdmUgUmVmZXJlbmNlcwoKICAgW0ktRC5pZXRm LXBheWxvYWQtZmxleGlibGUtZmVjLXNjaGVtZV0KICAgICAgICAgICAgICBTaW5naCwgVi4sIEJl Z2VuLCBBLiwgWmFuYXR5LCBNLiwgYW5kIEcuIE1hbmR5YW0sICJSVFAKICAgICAgICAgICAgICBQ YXlsb2FkIEZvcm1hdCBmb3IgRmxleGlibGUgRm9yd2FyZCBFcnJvciBDb3JyZWN0aW9uCiAgICAg ICAgICAgICAgKEZFQykiLCBkcmFmdC1pZXRmLXBheWxvYWQtZmxleGlibGUtZmVjLXNjaGVtZS0w MSAod29yayBpbgogICAgICAgICAgICAgIHByb2dyZXNzKSwgT2N0b2JlciAyMDE1LgoKICAgW1JG QzIxMTldICBCcmFkbmVyLCBTLiwgIktleSB3b3JkcyBmb3IgdXNlIGluIFJGQ3MgdG8gSW5kaWNh dGUKICAgICAgICAgICAgICBSZXF1aXJlbWVudCBMZXZlbHMiLCBCQ1AgMTQsIFJGQyAyMTE5LAog ICAgICAgICAgICAgIERPSSAxMC4xNzQ4Ny9SRkMyMTE5LCBNYXJjaCAxOTk3LAogICAgICAgICAg ICAgIDxodHRwOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2luZm8vcmZjMjExOT4uCgogICBbUkZDMjE5 OF0gIFBlcmtpbnMsIEMuLCBLb3V2ZWxhcywgSS4sIEhvZHNvbiwgTy4sIEhhcmRtYW4sIFYuLAog ICAgICAgICAgICAgIEhhbmRsZXksIE0uLCBCb2xvdCwgSi4sIFZlZ2EtR2FyY2lhLCBBLiwgYW5k IFMuIEZvc3NlLQogICAgICAgICAgICAgIFBhcmlzaXMsICJSVFAgUGF5bG9hZCBmb3IgUmVkdW5k YW50IEF1ZGlvIERhdGEiLCBSRkMgMjE5OCwKICAgICAgICAgICAgICBET0kgMTAuMTc0ODcvUkZD MjE5OCwgU2VwdGVtYmVyIDE5OTcsCiAgICAgICAgICAgICAgPGh0dHA6Ly93d3cucmZjLWVkaXRv ci5vcmcvaW5mby9yZmMyMTk4Pi4KCiAgIFtSRkM1OTU2XSAgQmVnZW4sIEEuLCAiRm9yd2FyZCBF cnJvciBDb3JyZWN0aW9uIEdyb3VwaW5nIFNlbWFudGljcyBpbgogICAgICAgICAgICAgIHRoZSBT ZXNzaW9uIERlc2NyaXB0aW9uIFByb3RvY29sIiwgUkZDIDU5NTYsCiAgICAgICAgICAgICAgRE9J IDEwLjE3NDg3L1JGQzU5NTYsIFNlcHRlbWJlciAyMDEwLAogICAgICAgICAgICAgIDxodHRwOi8v d3d3LnJmYy1lZGl0b3Iub3JnL2luZm8vcmZjNTk1Nj4uCgoxMi4yLiAgSW5mb3JtYXRpdmUgUmVm ZXJlbmNlcwoKICAgW0ktRC5pZXRmLXBheWxvYWQtcnRwLW9wdXNdCiAgICAgICAgICAgICAgU3Bp dHRrYSwgSi4sIFZvcywgSy4sIGFuZCBKLiBWYWxpbiwgIlJUUCBQYXlsb2FkIEZvcm1hdAogICAg ICAgICAgICAgIGZvciB0aGUgT3B1cyBTcGVlY2ggYW5kIEF1ZGlvIENvZGVjIiwgZHJhZnQtaWV0 Zi1wYXlsb2FkLQogICAgICAgICAgICAgIHJ0cC1vcHVzLTExICh3b3JrIGluIHByb2dyZXNzKSwg QXByaWwgMjAxNS4KCiAgIFtJLUQuaWV0Zi1ydGN3ZWItZGF0YS1jaGFubmVsXQogICAgICAgICAg ICAgIEplc3VwLCBSLiwgTG9yZXRvLCBTLiwgYW5kIE0uIFR1ZXhlbiwgIldlYlJUQyBEYXRhCiAg ICAgICAgICAgICAgQ2hhbm5lbHMiLCBkcmFmdC1pZXRmLXJ0Y3dlYi1kYXRhLWNoYW5uZWwtMTMg KHdvcmsgaW4KICAgICAgICAgICAgICBwcm9ncmVzcyksIEphbnVhcnkgMjAxNS4KCgoKClViZXJ0 aSAgICAgICAgICAgICAgICAgICAgRXhwaXJlcyBKdWx5IDExLCAyMDE2ICAgICAgICAgICAgICAg ICBbUGFnZSA3XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICBXZWJSVEMgRkVDICAg ICAgICAgICAgICAgICAgIEphbnVhcnkgMjAxNgoKCiAgIFtSRkM0ODY3XSAgU2pvYmVyZywgSi4s IFdlc3Rlcmx1bmQsIE0uLCBMYWthbmllbWksIEEuLCBhbmQgUS4gWGllLAogICAgICAgICAgICAg ICJSVFAgUGF5bG9hZCBGb3JtYXQgYW5kIEZpbGUgU3RvcmFnZSBGb3JtYXQgZm9yIHRoZQogICAg ICAgICAgICAgIEFkYXB0aXZlIE11bHRpLVJhdGUgKEFNUikgYW5kIEFkYXB0aXZlIE11bHRpLVJh dGUgV2lkZWJhbmQKICAgICAgICAgICAgICAoQU1SLVdCKSBBdWRpbyBDb2RlY3MiLCBSRkMgNDg2 NywgRE9JIDEwLjE3NDg3L1JGQzQ4NjcsCiAgICAgICAgICAgICAgQXByaWwgMjAwNywgPGh0dHA6 Ly93d3cucmZjLWVkaXRvci5vcmcvaW5mby9yZmM0ODY3Pi4KCiAgIFtSRkM1MTA5XSAgTGksIEEu LCBFZC4sICJSVFAgUGF5bG9hZCBGb3JtYXQgZm9yIEdlbmVyaWMgRm9yd2FyZCBFcnJvcgogICAg ICAgICAgICAgIENvcnJlY3Rpb24iLCBSRkMgNTEwOSwgRE9JIDEwLjE3NDg3L1JGQzUxMDksIERl Y2VtYmVyCiAgICAgICAgICAgICAgMjAwNywgPGh0dHA6Ly93d3cucmZjLWVkaXRvci5vcmcvaW5m by9yZmM1MTA5Pi4KCiAgIFtSRkM2NzE2XSAgVmFsaW4sIEpNLiwgVm9zLCBLLiwgYW5kIFQuIFRl cnJpYmVycnksICJEZWZpbml0aW9uIG9mIHRoZQogICAgICAgICAgICAgIE9wdXMgQXVkaW8gQ29k ZWMiLCBSRkMgNjcxNiwgRE9JIDEwLjE3NDg3L1JGQzY3MTYsCiAgICAgICAgICAgICAgU2VwdGVt YmVyIDIwMTIsIDxodHRwOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2luZm8vcmZjNjcxNj4uCgpBcHBl bmRpeCBBLiAgQ2hhbmdlIGxvZwoKICAgQ2hhbmdlcyBpbiBkcmFmdCAtMDM6CgogICBvICBBZGRl ZCBvdmVyaGVhZCBzdGF0cyBmb3IgT3B1cy4KCiAgIG8gIEV4cGFuZGVkIGRpc2N1c3Npb24gb2Yg bXVsdGktcGFja2V0IEZFQyBmb3IgT3B1cy4KCiAgIG8gIEFkZGVkIGRpc2N1c3Npb24gb2YgQU1S L0FNUi1XQi4KCiAgIG8gIFJlZmVyZW5jZWQgdGhlIGRhdGEgY2hhbm5lbCBkb2MuCgogICBvICBT ZXZlcmFsIHNtYWxsIGVkaXRzIGJhc2VkIG9uIGZlZWRiYWNrIGZyb20gTWFnbnVzLgoKICAgQ2hh bmdlcyBpbiBkcmFmdCAtMDI6CgogICBvICBFeHBhbmRlZCBkaXNjdXNzaW9uIG9mIEZFQy1vbmx5 IG0tbGluZXMsIGFuZCBob3cgdGhleSBzaG91bGQgYmUKICAgICAgaGFuZGxlZCBpbiBvZmZlcnMg YW5kIGFuc3dlcnMuCgogICBDaGFuZ2VzIGluIGRyYWZ0IC0wMToKCiAgIG8gIFR3ZWFrZWQgYWJz dHJhY3QvaW50cm8gdGV4dCB0aGF0IHdhcyBhbWJpZ3VvdXNseSBub3JtYXRpdmUuCgogICBvICBS ZW1vdmVkIHRleHQgb24gRkVDIGZvciBPcHVzIGluIENFTFQgbW9kZS4KCiAgIG8gIENoYW5nZWQg UkZDIDIxOTggcmVjb21tZW5kYXRpb24gZm9yIFBDTVUgdG8gYmUgTUFZIGluc3RlYWQgb2YgTk9U CiAgICAgIFJFQ09NTUVOREVELCBiYXNlZCBvbiBsaXN0IGZlZWRiYWNrLgoKICAgbyAgRXhwbGlj aXRseSBjYWxsZWQgb3V0IGFwcGxpY2F0aW9uIGRhdGEgYXMgc29tZXRoaW5nIG5vdCBhZGRyZXNz ZWQKICAgICAgaW4gdGhpcyBkb2N1bWVudC4KCiAgIG8gIFVwZGF0ZWQgZmxleGlibGUtZmVjIHJl ZmVyZW5jZS4KCiAgIENoYW5nZXMgaW4gZHJhZnQgLTAwOgoKCgpVYmVydGkgICAgICAgICAgICAg ICAgICAgIEV4cGlyZXMgSnVseSAxMSwgMjAxNiAgICAgICAgICAgICAgICAgW1BhZ2UgOF0KDApJ bnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgV2ViUlRDIEZFQyAgICAgICAgICAgICAgICAg ICBKYW51YXJ5IDIwMTYKCgogICBvICBJbml0aWFsIHZlcnNpb24sIGZyb20gc2lkZWJhciBjb252 ZXJzYXRpb24gYXQgSUVURiA5MC4KCkF1dGhvcidzIEFkZHJlc3MKCiAgIEp1c3RpbiBVYmVydGkK ICAgR29vZ2xlCiAgIDc0NyA2dGggQXZlIFMKICAgS2lya2xhbmQsIFdBICA5ODAzMwogICBVU0EK CiAgIEVtYWlsOiBqdXN0aW5AdWJlcnRpLm5hbWUKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoK CgoKCgoKCgoKCgoKClViZXJ0aSAgICAgICAgICAgICAgICAgICAgRXhwaXJlcyBKdWx5IDExLCAy MDE2ICAgICAgICAgICAgICAgICBbUGFnZSA5XQo= --001a11425b709fbb5c0528dbaaca-- From nobody Fri Jan 8 16:21:24 2016 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 E49CA1B2CCD; Fri, 8 Jan 2016 16:21:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 PAGIMjMd5upQ; Fri, 8 Jan 2016 16:21:20 -0800 (PST) Received: from mail-ig0-f176.google.com (mail-ig0-f176.google.com [209.85.213.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE49C1B2CCB; Fri, 8 Jan 2016 16:21:20 -0800 (PST) Received: by mail-ig0-f176.google.com with SMTP id t15so62923685igr.0; Fri, 08 Jan 2016 16:21:20 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-type; bh=4kMvo4s7LrLZY/JegX30mXM8TOGmlNIn9yzeS6Vi0zY=; b=HMABPM7KIX9wEotjERGQJH+XhyOH/bxfWtcNzCoTVnaJmniyzrxFpLye4aDU4mhS72 pj+uS91hPLK1ztKklz9yI7el1HJCuX3mYAu5oV1UgSt20iuLW5lEL1jmwb+QvzWDnqme vpullcwFFuGx9bcyuNI6p+K9icjFQTiXOCMKXQUVFJ++zDG6GGFXIWYSMieTWiCeZnEW rerNbEX6+PyreMje8wBgldazciRlb2GhOPVI4dq6Tu64DZ9NMy4S+EURMLskIfWJx2Qg Mriwob21PDR/w6bdIXwYK2jILa+Qht/mVB9LHj7dy37I0/btgevqrvXCdDtGR4SVISmI 2NMg== X-Received: by 10.50.134.227 with SMTP id pn3mr1642775igb.13.1452298879939; Fri, 08 Jan 2016 16:21:19 -0800 (PST) MIME-Version: 1.0 References: <563B01C9.6060801@ericsson.com> In-Reply-To: From: Justin Uberti Date: Sat, 09 Jan 2016 00:21:10 +0000 Message-ID: To: Magnus Westerlund , "rtcweb@ietf.org" , draft-ietf-rtcweb-fec@ietf.org, Justin Uberti Content-Type: multipart/alternative; boundary=047d7b2e12d9d8bc210528dbae50 Archived-At: Subject: Re: [rtcweb] Comments on draft-ietf-rtcweb-fec-02 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: Sat, 09 Jan 2016 00:21:23 -0000 --047d7b2e12d9d8bc210528dbae50 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable [fixing wrong email address] On Fri, Jan 8, 2016 at 4:19 PM Justin Uberti wrote: > Finally got around to updating the document. Comments inline; new version > of the doc attached. > > On Wed, Nov 4, 2015 at 11:15 PM Magnus Westerlund < > magnus.westerlund@ericsson.com> wrote: > >> Hi, >> >> A. Section 3.2: >> >> I think the draft should note that some RTP Payload format, including >> several of the one recommended in >> draft-ietf-rtcweb-audio-codecs-for-interop-02, do support internal >> redundancy. The codecs that I know for a fact can do this within the >> payload format are: AMR and AMR-WB. >> >> I would suggest adding some sentence on that time delayed redundancy may >> be supported by codecs, and give AMR and AMR-WB as examples. >> > > I added a section on AMR/AMR-WB that parallels the Opus section. > >> >> B. Section 4. >> >> I think this draft should consider the recommended drafts in >> draft-ietf-rtcweb-audio-codecs-for-interop-02. Here we clearly can >> consider internal redundancy for AMR and AMR-WB. >> > > Done. > >> >> C. Section 4.2 >> >> There are a parameter in AMR and AMR-WB that can negotiate how much >> redundancy one may include: max-red >> > > I mentioned this parameter in the doc. Do you want to recommend a default > value? > >> >> D. Section 5.1: >> >> The receiver can demultiplex the incoming FEC stream by >> SSRC and correlate it with the primary stream via the ssrc-group >> mechanism. >> >> Given that FlexFEC has built in indication of which SSRC that are >> included in protection, why include it in SDP? For the purpose to >> indicate selectively which streams that should have FEC protection? >> >> You also need a reference for "ssrc-group" if intended to be supported >> going forward? >> > > Agree. Left as a TODO for now until I can sort out the details. > >> >> E. Section 5.2, first paragraph: >> >> This section needs clearer references to SDP. >> > > Not sure exactly what you had in mind here. > >> >> F. Section 6. >> >> WebRTC also supports the ability to send generic application data, >> and provides transport-level retransmission mechanisms that the >> application can use to ensure that its data is delivered reliably. >> >> >> This should informationally reference data channel. >> > > Done. > >> >> G. Section 6. >> >> I think this section should say even less. Just note that SCTP has >> reliable and semi-reliable modes and the application can control it. >> Nothing more. >> > > I don't see a problem with mentioning the app can do its own FEC if it > wants. I did adjust the first para to mention the reliability modes more > explicitly. > >> >> H. Section 7. >> >> To support the functionality recommended above, implementations MUST >> support the redundant encoding mechanism described in [RFC2198] >> >> For which Codecs does on need to support this? >> > > Added detail on this. > >> >> I. Section 7. >> >> the FEC mechanism described in [RFC5956] and >> [I-D.ietf-payload-flexible-fec-scheme] >> >> As RFC5956 is not a FEC mechanism, only a grouping mechanism I think >> this need to be reformulated. >> > > Removed that part. > >> >> J. Section 9. >> >> This section needs to be clearer that an implementation is expected to >> adapt the amount of FEC to the seen packet loss rate to ensure >> sufficient protection. And that adaptation must take into account the >> available network resources (Bandwidth) to trade-off media quality and >> what streams can be sent with use of FEC. >> > > That's what this paragraph says, I think, but I rewrote it a bit to try t= o > make this more clear. > >> >> Cheers >> >> Magnus Westerlund >> >> ---------------------------------------------------------------------- >> Services, Media and Network features, Ericsson Research EAB/TXM >> ---------------------------------------------------------------------- >> Ericsson AB | Phone +46 10 7148287 >> F=C3=A4r=C3=B6gatan 6 | Mobile +46 73 0949079 >> SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >> ---------------------------------------------------------------------- >> >> --047d7b2e12d9d8bc210528dbae50 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
[fixing wrong email address]

On Fri, Jan 8, 2016 at 4:19 PM Justin Uberti <justin@uberti.name> wrote:
Finally got around to upd= ating the document. Comments inline; new version of the doc attached.
On Wed, Nov 4, 2015 at 11:15 PM Magnus Westerlun= d <m= agnus.westerlund@ericsson.com> wrote:
Hi,

A. Section 3.2:

I think the draft should note that some RTP Payload format, including
several of the one recommended in
draft-ietf-rtcweb-audio-codecs-for-interop-02, do support internal
redundancy. The codecs that I know for a fact can do this within the
payload format are: AMR and AMR-WB.

I would suggest adding some sentence on that time delayed redundancy may be supported by codecs, and give AMR and AMR-WB as examples.

I added a section on AMR/AMR-WB that parallels the Opus section.=C2=A0

B. Section 4.

I think this draft should consider the recommended drafts in
draft-ietf-rtcweb-audio-codecs-for-interop-02. Here we clearly can
consider internal redundancy for AMR and AMR-WB.

<= /div>
Done.=C2= =A0

C. Section 4.2

There are a parameter in AMR and AMR-WB that can negotiate how much
redundancy one may include: max-red

I mentioned this param= eter in the doc. Do you want to recommend a default value?=C2=A0

D. Section 5.1:

=C2=A0 =C2=A0 The receiver can demultiplex the incoming FEC stream by
=C2=A0 =C2=A0 SSRC and correlate it with the primary stream via the ssrc-gr= oup
=C2=A0 =C2=A0 mechanism.

Given that FlexFEC has built in indication of which SSRC that are
included in protection, why include it in SDP? For the purpose to
indicate selectively which streams that should have FEC protection?

You also need a reference for "ssrc-group" if intended to be supp= orted
going forward?

=
Agree. Left as a TODO for now until I can s= ort out the details.=C2=A0

E. Section 5.2, first paragraph:

This section needs clearer references to SDP.

Not sure exa= ctly what you had in mind here.=C2=A0

F. Section 6.

=C2=A0 =C2=A0 WebRTC also supports the ability to send generic application = data,
=C2=A0 =C2=A0 and provides transport-level retransmission mechanisms that t= he
=C2=A0 =C2=A0 application can use to ensure that its data is delivered reli= ably.


This should informationally reference data channel.
Done.= =C2=A0

G. Section 6.

I think this section should say even less. Just note that SCTP has
reliable and semi-reliable modes and the application can control it.
Nothing more.

<= div class=3D"gmail_quote">
I don't see a problem with mentioning th= e app can do its own FEC if it wants. I did adjust the first para to mentio= n the reliability modes more explicitly.=C2=A0

H. Section 7.

=C2=A0 =C2=A0 To support the functionality recommended above, implementatio= ns MUST
=C2=A0 =C2=A0 support the redundant encoding mechanism described in [RFC219= 8]

For which Codecs does on need to support this?

Added detai= l on this.=C2=A0

I. Section 7.

the FEC mechanism described in [RFC5956] and
=C2=A0 =C2=A0 [I-D.ietf-payload-flexible-fec-scheme]

As RFC5956 is not a FEC mechanism, only a grouping mechanism I think
this need to be reformulated.

Removed that part.=C2=A0

J. Section 9.

This section needs to be clearer that an implementation is expected to
adapt the amount of FEC to the seen packet loss rate to ensure
sufficient protection. And that adaptation must take into account the
available network resources (Bandwidth) to trade-off media quality and
what streams can be sent with use of FEC.

That's what = this paragraph says, I think, but I rewrote it a bit to try to make this mo= re clear.=C2=A0

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| = Phone=C2=A0 +46 10 7148287
F=C3=A4r=C3=B6gatan 6=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0| Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------

--047d7b2e12d9d8bc210528dbae50-- From nobody Fri Jan 8 17:19:44 2016 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 875031B2D1C for ; Fri, 8 Jan 2016 17:19:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.188 X-Spam-Level: X-Spam-Status: No, score=-0.188 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_16=0.6, J_CHICKENPOX_32=0.6, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 7zHuwoQzsFSu for ; Fri, 8 Jan 2016 17:19:41 -0800 (PST) Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DA9C1B2D1B for ; Fri, 8 Jan 2016 17:19:41 -0800 (PST) Received: by mail-vk0-x234.google.com with SMTP id i129so62683298vkb.0 for ; Fri, 08 Jan 2016 17:19:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=SxlqcMo7aEKEtCyfV7OOtJ8LXz1r5+FydK1eb1TKEfE=; b=fNgEzG2No14amd8uT2rJQKDHVTULl3007ks6dPRqAAOu2vwgjsEQsWTjimSgX7MCab 6NcJvSwzvF4T/GyYIycza1hxUqpLsTjshGCDpRqLqz+yldFjlKEqBpHWDSaD/yQ2Z4kS 9bMrn35CBbXaJyLvqRAB0B4witwBnM8OkCdiEzgcrwibI6U/aI1k7QZsHWsyfs9nLuhj 5t/74epMrdpDbqqdy2TN+SlctBhSyUUYg+ZMbmjAl42UL4qvmdIrg3uuYk8PiG9KF76x OSD3LAZ2vOuIW5nYUJlZEyU/Hkel1qiphupAkbzaLbNpo+Zm7cFkleYYETFnLjn9xSWL gLsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=SxlqcMo7aEKEtCyfV7OOtJ8LXz1r5+FydK1eb1TKEfE=; b=fUgeJUah2zFgYlKrqqwlLbcy5GBWhA/HtmH93ZHDrwzPmpzSenmx/xj2AJPEmrVeFB +bHLUj51wBxMj8kvUlkNIPqdrRS4wiSqHe5MS+Gh8sVm9DRomR5CgXBJeoaM8nNsJlZS NzvkGZcvXiyY19Pobv1Z1SsH7tKJ4CnUfZgETF16DlGvf1iM+URoDrPdmh4QXyemWZgY nYTblhZiAeHF3i63RP/DBKtDIKfFyhVjdCVZVBZTQWtl89ZJmq7EvRYXCtS64qwC7mq0 x/fwTH5R1OcHMEwsJ8+xUBmQGx/zyGJFP6X7CSQUVXzpV7Mk5ZstBSCBBTY1XvSMiJvr JyBQ== X-Gm-Message-State: ALoCoQlcC96qapSSvSMr4YMIv0Rg2EhQKL717pxi9HpRAJyarzoKbVwkXj89AyWTdL47keIq7z3fHDwglaLMda7qziL39/h4BqipvRV9xyYZCu1eu6tMXWw= X-Received: by 10.31.149.78 with SMTP id x75mr65306759vkd.103.1452302380153; Fri, 08 Jan 2016 17:19:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.198.132 with HTTP; Fri, 8 Jan 2016 17:19:20 -0800 (PST) In-Reply-To: References: From: Justin Uberti Date: Fri, 8 Jan 2016 17:19:20 -0800 Message-ID: To: Bernard Aboba Content-Type: multipart/alternative; boundary=001a114267487a19e00528dc7f73 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP: "VoiceActivityDetection" option and cient-mixer "vad" extension 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: Sat, 09 Jan 2016 01:19:42 -0000 --001a114267487a19e00528dc7f73 Content-Type: text/plain; charset=UTF-8 I don't think the VoiceActivityDetection setting would have any bearing on the "vad" param. You could certainly imagine wanting to set the VAD bit in client-mixer even when not using DTX. IOW, I think that we should always send VAD in client-mixer. There's no size penalty, and it's useful information for mixers. On Thu, Jan 7, 2016 at 7:37 AM, Bernard Aboba wrote: > JSEP Section 5.2.3.4 discusses the implications of the > "VoiceActivityDetection" option for the offer. > > One thing that is not covered is whether the "VoiceActivityDetection" > option determines whether the client-mixer "vad" extension is set to "on" > or "off". > > For example, I believe that the W3C WEBRTC WG determined that the > client-mixer extension (support for which is required in RTP-Usage) should > always be advertised in the offer. RFC 6464 Section 4 gives an example of > the a=extmap line: > > a=extmap:6 urn:ietf:params:rtp-hdrext:ssrc-audio-level vad=on > > > So, my question is whether "vad=on" or "vad=off" is determined by the "VoiceActivityDetection" option, or if not, whether there is a setting (e.g. "vad=on") that is always present in the offer. > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --001a114267487a19e00528dc7f73 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I don't think the VoiceActivityDetection setting would= have any bearing on the "vad" param. You could certainly imagine= wanting to set the VAD bit in client-mixer even when not using DTX.
IOW, I think that we should always send VAD in client-mixer. T= here's no size penalty, and it's useful information for mixers.

On Thu, J= an 7, 2016 at 7:37 AM, Bernard Aboba <bernard.aboba@gmail.com>= ; wrote:
JSEP Sec= tion 5.2.3.4 discusses the implications of the "VoiceActivityDetection= " option for the offer.=C2=A0

One thing that is not= covered is whether the "VoiceActivityDetection" option determine= s whether the client-mixer "vad" extension is set to "on&quo= t; or "off". =C2=A0

For example, I belie= ve that the W3C WEBRTC WG determined that the client-mixer extension (suppo= rt for which is required in RTP-Usage) should always be advertised in the o= ffer.=C2=A0 RFC 6464 Section 4 gives an example of the a=3Dextmap line:=C2= =A0

a=3Dextmap:6 urn:ietf:params:rtp-hdr=
ext:ssrc-audio-level vad=3Don

So, my question is whether "vad=3Don" or &qu=
ot;vad=3Doff" is determined by the "VoiceActivityDetection" =
option, or if not, whether there is a setting (e.g. "vad=3Don") t=
hat is always present in the offer.=C2=A0

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


--001a114267487a19e00528dc7f73-- From nobody Fri Jan 8 17:23:13 2016 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 BB5421B2D20 for ; Fri, 8 Jan 2016 17:23:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 FgnIIFVHOv_H for ; Fri, 8 Jan 2016 17:23:10 -0800 (PST) Received: from mail-vk0-x230.google.com (mail-vk0-x230.google.com [IPv6:2607:f8b0:400c:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 459391B2D1B for ; Fri, 8 Jan 2016 17:23:10 -0800 (PST) Received: by mail-vk0-x230.google.com with SMTP id i129so62706619vkb.0 for ; Fri, 08 Jan 2016 17:23:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=ikXiBmZtfZTqxv5PrGHfcSylfQerYN+1d+LlgGYf0iQ=; b=MbkTCOo5kXF1g7FVgna8ZjSBL11gsaCbDHGgDAT24kIQlvEYsbnBHnLEn2iniZYN8v PGYsRgLHO9ENkH3malYz97IjbeBVb+B3zFtUXhcoP99YpyWtl5/Nsk6YmYvzM6voxiH/ YiKlkJKUGqH8Gvii27v4zCeYUyNNZRvxnZNpdN5BWA7b2CD94BUQxYEj9e95ept0LLl9 JQ42jS56PLGJWlCIPDh140h9TQ2I5mlSxV+9agBxcmIObUWfIR8re8LoQv4D0Rl6MqhC DIslU/J2QSB/Cc9I8R0OSOnTFr4uA+fW2+nEMLbSIW1ld8hbxCmAo51o6BCUVeq3LKaV kolw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=ikXiBmZtfZTqxv5PrGHfcSylfQerYN+1d+LlgGYf0iQ=; b=JcL+QUKxYD1S82ShlytxAxLHoclFlacRj4QJNcTQK44puGFVEy5mIi2eNSyUFvtreW rZfvdPscAEWaeYridlGkar+LtMu8CS7hgnKLW7t9jyclsAZthWOkuxdJVBqPVu+lbz89 ghoE25nLmhbuDjN5S+PcVf7mHaT4rARbwvLytoeJJyc6t38g03HkK0M4Jj9NHZwM5A6O 3clRv1j4VFB1V/sNhtMzsdnmcUGZrQogkshdf7nPMKuWUGtriuow6PKkwrbivQG4Apsp 1BidRRl4WE1YdF/zBZNAzOuBAU9bLunqYc3D6v3lsBlPNFcSFe7P2eg61sQcANHaaJqH 6gUg== X-Gm-Message-State: ALoCoQno2XSDkH0zgabHd+XXPVHMNpK1+AFMrJ2VxBjGQMQ6b1vJ4lB3NVlhw+fJ2SrMyocBaAyEIq/zQ2VATY0M17V3mQBk2KyGRanTAnTBSleDyBXHT4c= X-Received: by 10.31.137.11 with SMTP id l11mr39058190vkd.98.1452302589367; Fri, 08 Jan 2016 17:23:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.198.132 with HTTP; Fri, 8 Jan 2016 17:22:49 -0800 (PST) In-Reply-To: References: <5660B824.7010807@goodadvice.pages.de> <5661CD94.2070209@goodadvice.pages.de> From: Justin Uberti Date: Fri, 8 Jan 2016 17:22:49 -0800 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=001a11441386f256e90528dc8b26 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP: why is iceCandidatePoolSize an integer? 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: Sat, 09 Jan 2016 01:23:11 -0000 --001a11441386f256e90528dc8b26 Content-Type: text/plain; charset=UTF-8 [late to the party] I'd be reluctant to add any more complexity to the operation of the candidate pool - as Martin points out, it is already quite complex. If you don't want to pregather all types of candidates, just don't use it. On Sat, Dec 5, 2015 at 1:40 AM, Martin Thomson wrote: > On 5 December 2015 at 04:29, Philipp Hancke > wrote: > > But if this is about components, how can the application make a decision > > whether to pre-gather and hold on to stun or relay candidates (which > > consumes resources)? > > The application might be able to defer the gathering of candidates via > relays (I don't think that STUN is a real resource concern) by only > providing the relays as stun URIs, or not providing them at all, then > updating the iceServers with setConfiguration. > > I don't know if this is something that would work, we'd have to spec that. > > I'm actually beginning to question the utility of the pre-warming > thing. Maybe it's a performance gain, but it's certainly quite > complex. > > >> No, this counts components. > > > > > > Calling it iceCandidatePoolSize in the w3c spec seems odd to me then ;-) > > Yeah, I'm sure that - given it's current level of interoperability > (i.e., zero) - the working group might be receptive to suggestions of > a more accurate name. > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --001a11441386f256e90528dc8b26 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
[late to the party]

I'd be reluctan= t to add any more complexity to the operation of the candidate pool - as Ma= rtin points out, it is already quite complex.

If y= ou don't want to pregather all types of candidates, just don't use = it.


On Sat, Dec 5, 2015 at 1:40 AM, Martin Thomson = <martin.thomson@gmail.com> wrote:
On 5 December 2015 at 04:29, Philipp Hancke= <fippo@goodadvice.pages.de= > wrote:
> But if this is about components, how can the application make a decisi= on
> whether to pre-gather and hold on to stun or relay candidates (which > consumes resources)?

The application might be able to defer the gathering of candidates v= ia
relays (I don't think that STUN is a real resource concern) by only
providing the relays as stun URIs, or not providing them at all, then
updating the iceServers with setConfiguration.

I don't know if this is something that would work, we'd have to spe= c that.

I'm actually beginning to question the utility of the pre-warming
thing.=C2=A0 Maybe it's a performance gain, but it's certainly quit= e
complex.

>> No, this counts components.
>
>
> Calling it iceCandidatePoolSize in the w3c spec seems odd to me then ;= -)

Yeah, I'm sure that - given it's current level of interopera= bility
(i.e., zero) - the working group might be receptive to suggestions of
a more accurate name.

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

--001a11441386f256e90528dc8b26-- From nobody Fri Jan 8 17:30:00 2016 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 88D781B2D30 for ; Fri, 8 Jan 2016 17:29:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 kBrObl6YjvoK for ; Fri, 8 Jan 2016 17:29:58 -0800 (PST) Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E75FC1B2D2D for ; Fri, 8 Jan 2016 17:29:57 -0800 (PST) Received: by mail-vk0-x232.google.com with SMTP id k1so200819678vkb.2 for ; Fri, 08 Jan 2016 17:29:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=8c2+HbIaLXCCzSbiZGrycMcDsiBsEnBVRVOZoMS2Hbs=; b=VAntDxG+AkJCtMF+iW/7LAcQEa4r69oVmSRZ0nLGUCm4QEqsDzpfYZkcJOwv5zNzm5 J85pTWniLezkm+RG5K0wU8cQQ2xZXvi2vkH1W5XjMjEKlkDbsDXtZSwuOGLQcfckTQ2l zbiy/FUjpZFfbXAdeE2fAWB3pFCiGirm65JMJKBBl8cTboNs/G4iCsSSm8+yABQOrvtt YUFoNnkTpEAL3oKC25hs/EQOLAjl8uNINjeutd7kPlV9JZo9hg5xZNuIFkPo2/iP5lNK aq+j+2/A6j27XMLInPcuodSoFHqTITJL/JXp2iH4YIBtWJZFUhNE9mrDUZ6Xo+qjir9o 3/LQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=8c2+HbIaLXCCzSbiZGrycMcDsiBsEnBVRVOZoMS2Hbs=; b=jPSDD12sNM/0Wsv48d1TFoo1dMU5R19hWVLBrPQ4INdl6AEeAtLpG4Ke/sA9a8TVCc yX9MWmQHQohJL3N5eN1W0MsuXhHIZs2i2jw3qgAyJAmrTtMykh3XUmG/P65PrrqJcuw/ XDa9OghrWnia3JkVr25dj706CEEFKc9HOL4T7RiYeNBshDobk4OdCcGwMB9Q2kyTXAkZ rb8WLx1LIQgPJBRueDlXFxMlmJlWB7PXplD88gwzYWSNBuPRIe7lxd/SAfFa7Ft0cnN8 F2bmKZlUZiWJMZovCmNfYYPS5UeL1G95H5A1tFqcxgia8E9FUE3Vsg1gJP0hpduLFHJJ TXgg== X-Gm-Message-State: ALoCoQl4U0McDELl1L3jGGlT9CcYFhdY3nkgX11GU934DT/V8+nxAadSQ+TRjJrwwWqLk+b5GRV+2qcRM+wOVR86mF1dMDkVyKqHMXNP1hPUttKnI3iLdCw= X-Received: by 10.31.149.78 with SMTP id x75mr65325835vkd.103.1452302997015; Fri, 08 Jan 2016 17:29:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.198.132 with HTTP; Fri, 8 Jan 2016 17:29:37 -0800 (PST) In-Reply-To: <566EB695.4080607@alvestrand.no> References: <566EB695.4080607@alvestrand.no> From: Justin Uberti Date: Fri, 8 Jan 2016 17:29:37 -0800 Message-ID: To: Harald Alvestrand Content-Type: multipart/alternative; boundary=001a114267483e9b7e0528dca45a Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Proposed resolution on comfort noise 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: Sat, 09 Jan 2016 01:29:59 -0000 --001a114267483e9b7e0528dca45a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I support this resolution. To Felix's point, this text just says that WebRTC endpoints MUST support CN, not MUST use it. Applications are free to not offer it (via the VoiceActivityDetection parameter). On Mon, Dec 14, 2015 at 4:31 AM, Harald Alvestrand wrote: > I support this resolution. > > I note that there's material in this discussion for an extensive treatise > on the pros and cons of offering CN at gateways. If someone wishes to > extract this as a PR against the -gateways draft, the draft is at > https://github.com/rtcweb-wg/gateways. > > > > On 12/10/2015 11:14 PM, Ted Hardie wrote: > > After reading the discussion on the comfort noise issue, it appears that > one way forward might be to adjust this language: > > "comfort noise (CN). Receivers MUST support RFC3389 CN for streams > encoded with G.711 or any other supported codec that does not provide it= s > own CN.=E2=80=9D > > to say instead > > "comfort noise (CN). WebRTC endpoints MUST support RFC3389 CN for stream= s > encoded with G.711 or any other supported codec that does not provide it= s > own CN.=E2=80=9D > > This would still allow non-WebRTC endpoints to omit CN support, while > retaining the mandate for WebRTC endpoints. > > Does this resolve the issue? > > regards, > > Ted > > > _______________________________________________ > rtcweb mailing listrtcweb@ietf.orghttps://www.ietf.org/mailman/listinfo/r= tcweb > > > > -- > Surveillance is pervasive. Go Dark. > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --001a114267483e9b7e0528dca45a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I support this resolution.

To Felix'= ;s point, this text just says that WebRTC endpoints MUST support CN, not MU= ST use it. Applications are free to not offer it (via the VoiceActivityDete= ction parameter).

On Mon, Dec 14, 2015 at 4:31 AM, Harald Alvestrand <harald@= alvestrand.no> wrote:
=20 =20 =20
I support this resolution.

I note that there's material in this discussion for an extensive treatise on the pros and cons of offering CN at gateways. If someone wishes to extract this as a PR against the -gateways draft, the draft is at https://github.com/rtcweb-wg/gateways.



On 12/10/2015 11:14 PM, Ted Hardie wrote:
After reading the discussion on the comfort noise issue, it appears that one way forward might be to adjust this language:

"comfort noise (CN).=C2=A0 Receivers MUST support RFC3389 CN= for streams encoded with G.711 or any other supported codec that =C2=A0does not provide its own CN.=E2=80=9D

to say instead

"comfort noise (CN).=C2=A0 WebRTC endpoints MUST support RFC3389 CN for streams encoded with G.711 or any other supported codec that =C2=A0does not provide its own CN.=E2=80=9D

This would still allow non-WebRTC endpoints to omit CN support, while retaining the mandate for WebRTC endpoints.

Does this resolve the issue?

regards,

Ted


___________________________________=
____________
rtcweb mailing list
rtcweb@ietf.org
=
https://www.ietf.org/mailman/listinfo/rtcweb



--=20
Surveillance is pervasive. Go Dark.

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


--001a114267483e9b7e0528dca45a-- From nobody Fri Jan 8 17:41:51 2016 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 D86FD1A0021 for ; Fri, 8 Jan 2016 17:41:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.012 X-Spam-Level: * X-Spam-Status: No, score=1.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_47=0.6, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 Rw9ObNE7Aw9x for ; Fri, 8 Jan 2016 17:41:48 -0800 (PST) Received: from mail-vk0-x22a.google.com (mail-vk0-x22a.google.com [IPv6:2607:f8b0:400c:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38DDC1A001C for ; Fri, 8 Jan 2016 17:41:48 -0800 (PST) Received: by mail-vk0-x22a.google.com with SMTP id n1so46575233vkb.3 for ; Fri, 08 Jan 2016 17:41:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=FYFEMK9WaCb7mJCccsgfVNAlc+aAYEEEuyyQVs0jWw0=; b=ZXGm5Ov5MKnryB5TQ7G9v5WSU6wVZH33pJyiC4pd9QYwAGF1+XUuKz4FhBZ6WzUi4i Zk7cVGsE9CgsFIjOo+z8kYQy91bkQU0de7qXW2WDnWBHARGpt+ZTTVb/XEFwcFz/+A90 TBL6hOuj5rE7yyuDFq5HT+pBbvQYNjROKYIHLs51B63/6z1vZiu9PW2mimEybTlAy0yd CqZfEctkE427lFZSPwilk+mdL8UqzZgUXjutQ3teIoLt9ZkulZyefJo8r7SSRTXFQpsJ +uFwiXA2m/+5Gq0wySglquwGNr9hrhsT+e428i0kS+cm+IWdGNfHbHG9wh4hzB/eeuTZ FwXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=FYFEMK9WaCb7mJCccsgfVNAlc+aAYEEEuyyQVs0jWw0=; b=Il60T7W03Oszk/xk82QqMieyv1ukvoRoSsIQ0QVh7lmcK6ZWdD1Mn+g9n1JnTbcqY+ 1O1nP6uEbzen1aEUevFl48dves+d65JX6bT/YZJais4Xew2Aew5A0umLgda3a0OS2d68 vcOk8UPS84LHOQMs9Phpuy1FttBoQWTsJx9YuC9m1dnn0rbXck4qapSVRgsS3O3Lr8sD NLIsxzmM15H7YYyetCPTWoCaGhN/WaJiRjttmTSE4V6Yvsu3HNqK7twc9xUXO91FU0jK JLsyeycOjQZBNLm3axT4OjOhMJxE+uMV+QfVxwmeuTPNHle4kYRIuST8MQcYA7v0WYx3 sK5g== X-Gm-Message-State: ALoCoQns6avAj7BTV1npd3r6z7lPPr5L4LBw/c3PRNL1c3I/xeiIpO9ThISpOct9E1/+Or5KPEtsS9vs5f71jbA0aX3W3D0pBefzMHE85jHdALO2NtlFujs= X-Received: by 10.31.54.5 with SMTP id d5mr79265421vka.158.1452303707226; Fri, 08 Jan 2016 17:41:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.198.132 with HTTP; Fri, 8 Jan 2016 17:41:27 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37CC9AF8@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37CC9AF8@ESESSMB209.ericsson.se> From: Justin Uberti Date: Fri, 8 Jan 2016 17:41:27 -0800 Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=001a1143ff3c93a12a0528dcce40 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP: Usage of a=rtcp attribute 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: Sat, 09 Jan 2016 01:41:50 -0000 --001a1143ff3c93a12a0528dcce40 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Unfortunately, that would contradict 5245. See https://tools.ietf.org/html/rfc5245#section-4.3, 6th para. Perhaps we could say that trickle with non-mux-exclusive should use a=3Drtcp:10 or some such... On Sun, Dec 13, 2015 at 7:02 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > > > Section 5.2.1 of draft-jsep contains the following statement: > > > > =E2=80=9Co An "a=3Drtcp" line, as specified in [RFC3605], Section 2.1= , > > containing the dummy value "9 IN IP4 0.0.0.0", because no > > candidates have yet been gathered.=E2=80=9D > > > > =E2=80=A6i.e. the same port:address as in the associated c/m-line. > > > > The problem is that the currently suggested mechanism to indicate > exclusive support of RTP/RTCP-mux also says that the a=3Drtcp line shall = be > identical to the c/m-line. > > > > My question is: is there really a need to always include the rtcp > attribute in trickle offers? Isn=E2=80=99t it enough to indicate port 9 i= n the m- > line, and address 0.0.0.0 in the c-line? In my opinion that would also > apply to RTCP. > > > > Example: > > > > JSEP trickle offer **without** mux-exclusive indication: > > > > c=3DIN IP4 0.0.0.0 > > m=3Daudio 9=E2=80=A6 > > a=3Drtcp-mux > > > > JSEP trickle offer **with** mux-exclusive indication: > > > > c=3DIN IP4 0.0.0.0 > > m=3Daudio 9=E2=80=A6 > > *a=3Drtcp: 9 IN IP4 0.0.0.0* > > a=3Drtcp-mux > > > > Regards, > > > > Christer > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --001a1143ff3c93a12a0528dcce40 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Unfortunately, that would contradict 5245. See=C2=A0https://tools.ietf.or= g/html/rfc5245#section-4.3, 6th para.

Perhaps we cou= ld say that trickle with non-mux-exclusive should use a=3Drtcp:10 or some s= uch...

On Sun, Dec 13, 2015 at 7:02 AM, Christer Holmberg <<= a href=3D"mailto:christer.holmberg@ericsson.com" target=3D"_blank">christer= .holmberg@ericsson.com> wrote:

Hi,

=C2=A0

Section 5.2.1 of draft-jsep contains the following s= tatement:

=C2=A0

=C2=A0=C2=A0 =E2=80=9Co =C2=A0An "a=3Drtcp"= ; line, as specified in [RFC3605], Section 2.1,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 containing the dummy = value "9 IN IP4 0.0.0.0", because no

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 candidates have yet b= een gathered.=E2=80=9D

=C2=A0

=E2=80=A6i.e. the same port:address as in the associ= ated c/m-line.

=C2=A0

The problem is that the currently suggested mechanis= m to indicate exclusive support of RTP/RTCP-mux also says that the a=3Drtcp= line shall be identical to the c/m-line.

=C2=A0

My question is: is there really a need to always inc= lude the rtcp attribute in trickle offers? Isn=E2=80=99t it enough to indic= ate port 9 in the m- line, and address 0.0.0.0 in the c-line? In my opinion= that would also apply to RTCP.

=C2=A0

Example:

=C2=A0

JSEP trickle offer *without* mux-exclusive in= dication:

=C2=A0

c=3DIN IP4 0.0.0.0 <= /u>

m=3Daudio 9=E2=80=A6=

a=3Drtcp-mux<= /u>

=C2=A0

JSEP trickle offer *with* mux-exclusive indic= ation:

=C2=A0

c=3DIN IP4 0.0.0.0 <= /u>

m=3Daudio 9=E2=80=A6=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 a=3Drtcp: 9 IN IP4 0.0.0.0=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 a=3Drtcp-mux

=C2=A0

Regards,

=C2=A0

Christer


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


--001a1143ff3c93a12a0528dcce40-- From nobody Fri Jan 8 21:32:33 2016 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 700461A19E4 for ; Fri, 8 Jan 2016 21:32:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_47=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 L7B_ckooYJt3 for ; Fri, 8 Jan 2016 21:32:27 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3A241A044F for ; Fri, 8 Jan 2016 21:32:26 -0800 (PST) X-AuditID: c1b4fb3a-f79df6d0000013b1-aa-56909b683a0d Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.183.90]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id CF.F9.05041.86B90965; Sat, 9 Jan 2016 06:32:24 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.76]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.03.0248.002; Sat, 9 Jan 2016 06:32:24 +0100 From: Christer Holmberg To: Justin Uberti Thread-Topic: [rtcweb] JSEP: Usage of a=rtcp attribute Thread-Index: AdE1tk5+GgxwzrGpR6mZvYz9J4lNJQUwCquAAAopOu8= Date: Sat, 9 Jan 2016 05:32:23 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37D1020D@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37CC9AF8@ESESSMB209.ericsson.se>, In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B37D1020DESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprMIsWRmVeSWpSXmKPExsUyM2J7lG7G7AlhBkcaJSy2ThWyWPuvnd2B yWPBplKPJUt+MgUwRXHZpKTmZJalFunbJXBlPFsyi6ngmUPFiXWHmBoY/1t0MXJySAiYSHw+ vIkRwhaTuHBvPVsXIxeHkMBhRokr6+4xQjiLGCVWH1zA3sXIwcEmYCHR/U8bpEFEQE3i4axd rCA2s4C6xJ3F59hBbGEBU4ljfyexQdSYSdx7fIEJwraSWPpiD1gNi4CKxP5LH1lAbF4BX4nn T5+xQOyaxCgx69kdsKGcAoESvx6eBrMZga77fmoNE8QycYmmLytZIa4WkFiy5zwzhC0q8fLx P6iD8iUaFvyAWiAocXLmE5YJjCKzkLTPQlI2C0kZRNxA4sv721C2tsSyha+ZIWx9ie73p5mQ xRcwsq9iFC1OLS7OTTcy0kstykwuLs7P08tLLdnECIyqg1t+W+1gPPjc8RCjAAejEg9vgf2E MCHWxLLiytxDjBIczEoivOuTgUK8KYmVValF+fFFpTmpxYcYpTlYlMR5k2Qaw4QE0hNLUrNT UwtSi2CyTBycUg2MKnvSlxsuubHU8uqWhou3/rClhjC3MjK9t2868qJ+qdrBXxPz3xzrvTb7 75d9UTdEfv712+e6ReHVipbbBjKSXDlCpwQ9nj5lFVN7LyKZbjsl+a5bjdnv7cLmjF//3Lxk sDq0W9Z0yr23Nf1Tvk1cviBeI+7QqvOa/h2F2ivP8686832Rsc89HiWW4oxEQy3mouJEAH3q nRqmAgAA Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP: Usage of a=rtcp attribute 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: Sat, 09 Jan 2016 05:32:29 -0000 --_000_7594FB04B1934943A5C02806D1A2204B37D1020DESESSMB209erics_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable Hi, Eventhough the text in 5245 is a little unclear (should probably be fixed i= n 5245bis) I don't think it says that you must include the rtcp attribute -= it describes how to encode the rtcp candidate. Regards, Christer Sent from my Windows Phone ________________________________ From: Justin Uberti Sent: =FD09/=FD01/=FD2016 03:41 To: Christer Holmberg Cc: rtcweb@ietf.org Subject: Re: [rtcweb] JSEP: Usage of a=3Drtcp attribute Unfortunately, that would contradict 5245. See https://tools.ietf.org/html/= rfc5245#section-4.3, 6th para. Perhaps we could say that trickle with non-mux-exclusive should use a=3Drtc= p:10 or some such... On Sun, Dec 13, 2015 at 7:02 AM, Christer Holmberg > wrote: Hi, Section 5.2.1 of draft-jsep contains the following statement: =93o An "a=3Drtcp" line, as specified in [RFC3605], Section 2.1, containing the dummy value "9 IN IP4 0.0.0.0", because no candidates have yet been gathered.=94 =85i.e. the same port:address as in the associated c/m-line. The problem is that the currently suggested mechanism to indicate exclusive= support of RTP/RTCP-mux also says that the a=3Drtcp line shall be identica= l to the c/m-line. My question is: is there really a need to always include the rtcp attribute= in trickle offers? Isn=92t it enough to indicate port 9 in the m- line, an= d address 0.0.0.0 in the c-line? In my opinion that would also apply to RTC= P. Example: JSEP trickle offer *without* mux-exclusive indication: c=3DIN IP4 0.0.0.0 m=3Daudio 9=85 a=3Drtcp-mux JSEP trickle offer *with* mux-exclusive indication: c=3DIN IP4 0.0.0.0 m=3Daudio 9=85 a=3Drtcp: 9 IN IP4 0.0.0.0 a=3Drtcp-mux Regards, Christer _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --_000_7594FB04B1934943A5C02806D1A2204B37D1020DESESSMB209erics_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
Hi,

Eventhough the text in 5245 is a little unclear (should probably be fixed i= n 5245bis) I don't think it says that you must include the rtcp attribute -= it describes how to encode the rtcp candidate.

Regards,

Christer


Sent from my Windows Phone
From: Justin Uberti
Sent: =FD09= /=FD01/=FD2016 03:41
To: Christer Holmberg Cc: rtcweb@ietf.org
Subject: Re: [= rtcweb] JSEP: Usage of a=3Drtcp attribute

Unfortunately, that would contradict 5245. See https://tools.ietf.or= g/html/rfc5245#section-4.3, 6th para.

Perhaps we could say that trickle with non-mux-exclusive should use a= =3Drtcp:10 or some such...

On Sun, Dec 13, 2015 at 7:02 AM, Christer Holmbe= rg <chr= ister.holmberg@ericsson.com> wrote:

Hi,

 

Section 5.2.1 of draft-jsep contains the following s= tatement:

 

   =93o  An "a=3Drtcp" line= , as specified in [RFC3605], Section 2.1,

      containing the dummy = value "9 IN IP4 0.0.0.0", because no

      candidates have yet b= een gathered.=94

 

=85i.e. the same port:address as in the associated c= /m-line.

 

The problem is that the currently suggested mechanis= m to indicate exclusive support of RTP/RTCP-mux also says that the a=3Drtcp= line shall be identical to the c/m-line.

 

My question is: is there really a need to always inc= lude the rtcp attribute in trickle offers? Isn=92t it enough to indicate po= rt 9 in the m- line, and address 0.0.0.0 in the c-line? In my opinion that = would also apply to RTCP.

 

Example:

 

JSEP trickle offer *without* mux-exclusive in= dication:

 

c=3DIN IP4 0.0.0.0 <= /u>

m=3Daudio 9=85

a=3Drtcp-mux<= /u>

 

JSEP trickle offer *with* mux-exclusive indic= ation:

 

c=3DIN IP4 0.0.0.0 <= /u>

m=3Daudio 9=85

        &nbs= p;     a=3Drtcp: 9 IN IP4 0.0.0.0<= /p>

        &nbs= p;     a=3Drtcp-mux

 

Regards,

 

Christer


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


--_000_7594FB04B1934943A5C02806D1A2204B37D1020DESESSMB209erics_-- From nobody Sat Jan 9 20:32:04 2016 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 737351A0031 for ; Sat, 9 Jan 2016 20:32:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.122 X-Spam-Level: * X-Spam-Status: No, score=1.122 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_47=0.6, SPF_PASS=-0.001] autolearn=no 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 m0cqG4-8AgRQ for ; Sat, 9 Jan 2016 20:32:00 -0800 (PST) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77EC51A0032 for ; Sat, 9 Jan 2016 20:32:00 -0800 (PST) Received: by mail-io0-x22e.google.com with SMTP id q21so321313558iod.0 for ; Sat, 09 Jan 2016 20:32:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Ysx7uUs/TTHRlJ0efpLgsTUBkAv0L+SJUu1tIcPFvAU=; b=ne4s4G7Mw8MJmcWLP5bjay0IyqbNYA4EdziVdS6VKZWgC3jIaDnWGp5Uulrubzz90W a9HR7Jfs27uRcC48hRar011jLvaw545LvglxMML3mC2pcMRLtzb68xTN9DGeciZvmF8X AN5fdaXr6NrTY6nv6dROeCHemJuPmyXNYoatsg9yzlY5wnKNtTiefmnV7Eaq2G8pfe68 fycgOU+g2DhcAxLsMKWOJxrMTPeZHC00amYhrIKUZV+jNenlZQi1fXdwUf5RxAX5vDk7 r+SM/2XOXFok4qy46g3RoOp10r6Kk/akMCX0IL0t+gfR6w7klAwzyvQNo9q4+mJ4wOSd 79fw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Ysx7uUs/TTHRlJ0efpLgsTUBkAv0L+SJUu1tIcPFvAU=; b=iMOaQlpCQskkiTIubmsk6zITbk9aCLyAbFw/mQE6srG8h4u/mtjGD5tGtxXXUJhxy0 DgWjc3StKVexVxPAG5zGacm+/3dAxwzZ+klXkQ76pHnf5+WHWVh07pwaRblFnVbOqNIE j/H4dNwEPyPdLCJpchZJY1xYBPsoP9m5gH9I93sJGm97D6Ww7NFwDc3M3r6X7yOFZ158 w9pOBrKy7lfV/xh7LQ5lvILfxmjoFDQ9qr72z5Qokq3QE6MWG7kU/MGhgRjCULxfYHbO D8JbU5QVAklyDDo0rsaWpsdO8kWMWKlnTgmD5SXCFUSS7aGrsjLoaDhsjS8QwQs7/d2W U0Sg== X-Gm-Message-State: ALoCoQmYxzyCtfU/L/8WTG1xfGaCx+EmyUQWKHwnGIaXfvvA7Fz9AMsII2dRArT+TwDN26vdLs8UpJPQRosEeDXVfU2NkM+R7Q== X-Received: by 10.107.2.150 with SMTP id 144mr61458643ioc.55.1452400319649; Sat, 09 Jan 2016 20:31:59 -0800 (PST) Received: from mail-ig0-f175.google.com (mail-ig0-f175.google.com. [209.85.213.175]) by smtp.gmail.com with ESMTPSA id w191sm27310018iod.30.2016.01.09.20.31.57 for (version=TLSv1/SSLv3 cipher=OTHER); Sat, 09 Jan 2016 20:31:58 -0800 (PST) Received: by mail-ig0-f175.google.com with SMTP id z14so81675646igp.1 for ; Sat, 09 Jan 2016 20:31:57 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.50.102.69 with SMTP id fm5mr6275874igb.24.1452400317538; Sat, 09 Jan 2016 20:31:57 -0800 (PST) Received: by 10.36.105.15 with HTTP; Sat, 9 Jan 2016 20:31:57 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37D1020D@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37CC9AF8@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37D1020D@ESESSMB209.ericsson.se> Date: Sat, 9 Jan 2016 23:31:57 -0500 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: Christer Holmberg Content-Type: multipart/alternative; boundary=047d7b10ca09ffaa460528f34cc6 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP: Usage of a=rtcp attribute 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: Sun, 10 Jan 2016 04:32:02 -0000 --047d7b10ca09ffaa460528f34cc6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, To add to above, if default RTCP candidate is on the same address as RTP and is using RTP port+1, why is SDP rtcp attribute is still required? It is totally redundant. Does anybody know the reason why rtcp SDP attribute was made a requirement in RFC 5245? Regards, _____________ Roman Shpount On Sat, Jan 9, 2016 at 12:32 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > Eventhough the text in 5245 is a little unclear (should probably be fixed > in 5245bis) I don't think it says that you must include the rtcp attribut= e > - it describes how to encode the rtcp candidate. > > Regards, > > Christer > > > Sent from my Windows Phone > ------------------------------ > From: Justin Uberti > Sent: =E2=80=8E09/=E2=80=8E01/=E2=80=8E2016 03:41 > To: Christer Holmberg > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] JSEP: Usage of a=3Drtcp attribute > > Unfortunately, that would contradict 5245. See > https://tools.ietf.org/html/rfc5245#section-4.3, 6th para. > > Perhaps we could say that trickle with non-mux-exclusive should use > a=3Drtcp:10 or some such... > > On Sun, Dec 13, 2015 at 7:02 AM, Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > >> Hi, >> >> >> >> Section 5.2.1 of draft-jsep contains the following statement: >> >> >> >> =E2=80=9Co An "a=3Drtcp" line, as specified in [RFC3605], Section 2.= 1, >> >> containing the dummy value "9 IN IP4 0.0.0.0", because no >> >> candidates have yet been gathered.=E2=80=9D >> >> >> >> =E2=80=A6i.e. the same port:address as in the associated c/m-line. >> >> >> >> The problem is that the currently suggested mechanism to indicate >> exclusive support of RTP/RTCP-mux also says that the a=3Drtcp line shall= be >> identical to the c/m-line. >> >> >> >> My question is: is there really a need to always include the rtcp >> attribute in trickle offers? Isn=E2=80=99t it enough to indicate port 9 = in the m- >> line, and address 0.0.0.0 in the c-line? In my opinion that would also >> apply to RTCP. >> >> >> >> Example: >> >> >> >> JSEP trickle offer **without** mux-exclusive indication: >> >> >> >> c=3DIN IP4 0.0.0.0 >> >> m=3Daudio 9=E2=80=A6 >> >> a=3Drtcp-mux >> >> >> >> JSEP trickle offer **with** mux-exclusive indication: >> >> >> >> c=3DIN IP4 0.0.0.0 >> >> m=3Daudio 9=E2=80=A6 >> >> *a=3Drtcp: 9 IN IP4 0.0.0.0* >> >> a=3Drtcp-mux >> >> >> >> Regards, >> >> >> >> Christer >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> >> > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --047d7b10ca09ffaa460528f34cc6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

To add to above, if default RTCP ca= ndidate is on the same address as RTP and is using RTP port+1, why is SDP r= tcp attribute is still required? It is totally redundant. Does anybody know= the reason why rtcp SDP attribute was made a requirement in RFC=C2=A05245?

Regards,

_____________
Roman Shpount

On Sat, Jan 9, 2016 at 12:32 AM, Christer Ho= lmberg <christer.holmberg@ericsson.com> wrote:<= br>
Hi,

Eventhough the text in 5245 is a little unclear (should probably be fixed i= n 5245bis) I don't think it says that you must include the rtcp attribu= te - it describes how to encode the rtcp candidate.

Regards,

Christer


Sent from my Windows Phone
From: Justin Uberti<= br> Sent: =E2=80= =8E09/=E2=80=8E01/=E2=80=8E2016 03:41
To: Christer Holm= berg
Cc: rtcweb@ietf.org Subject: Re: [r= tcweb] JSEP: Usage of a=3Drtcp attribute

Unfortunately, that would contradict 5245. See=C2=A0htt= ps://tools.ietf.org/html/rfc5245#section-4.3, 6th para.

Perhaps we could say that trickle with non-mux-exclusive should use a= =3Drtcp:10 or some such...

On Sun, Dec 13, 2015 at 7:02 AM, Christer Holmbe= rg <chr= ister.holmberg@ericsson.com> wrote:

Hi,

=C2=A0

Section 5.2.1 of draft-jsep contains the following s= tatement:

=C2=A0

=C2=A0=C2=A0 =E2=80=9Co =C2=A0An "a=3Drtcp"= ; line, as specified in [RFC3605], Section 2.1,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 containing the dummy = value "9 IN IP4 0.0.0.0", because no

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 candidates have yet b= een gathered.=E2=80=9D

=C2=A0

=E2=80=A6i.e. the same port:address as in the associ= ated c/m-line.

=C2=A0

The problem is that the currently suggested mechanis= m to indicate exclusive support of RTP/RTCP-mux also says that the a=3Drtcp= line shall be identical to the c/m-line.

=C2=A0

My question is: is there really a need to always inc= lude the rtcp attribute in trickle offers? Isn=E2=80=99t it enough to indic= ate port 9 in the m- line, and address 0.0.0.0 in the c-line? In my opinion= that would also apply to RTCP.

=C2=A0

Example:

=C2=A0

JSEP trickle offer *without* mux-exclusive in= dication:

=C2=A0

c=3DIN IP4 0.0.0.0 <= /u>

m=3Daudio 9=E2=80=A6=

a=3Drtcp-mux<= /u>

=C2=A0

JSEP trickle offer *with* mux-exclusive indic= ation:

=C2=A0

c=3DIN IP4 0.0.0.0 <= /u>

m=3Daudio 9=E2=80=A6=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 a=3Drtcp: 9 IN IP4 0.0.0.0=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 a=3Drtcp-mux

=C2=A0

Regards,=

=C2=A0

Christer


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



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


--047d7b10ca09ffaa460528f34cc6-- From nobody Sun Jan 10 09:24:08 2016 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 C9EA51ACE3B for ; Sun, 10 Jan 2016 09:24:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.423 X-Spam-Level: * X-Spam-Status: No, score=1.423 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=no 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 qM2IvE8pzuMW for ; Sun, 10 Jan 2016 09:24:06 -0800 (PST) Received: from mail-yk0-x231.google.com (mail-yk0-x231.google.com [IPv6:2607:f8b0:4002:c07::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 321921ACE3D for ; Sun, 10 Jan 2016 09:24:05 -0800 (PST) Received: by mail-yk0-x231.google.com with SMTP id v14so316685104ykd.3 for ; Sun, 10 Jan 2016 09:24:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=9GAgt6F/+6L41XewkZ0s9RxdOW7J/x7MBfpH99EPVvk=; b=FXxnPUxg1iV5y61p9Nzl9eunnKPPYwzoJLPlVQfaYS5cNv+CSIvLnzKOsp4aAE51Ni EjmX1UumcyHNmNbhDnZUWkuOjy8RMfDgYL7IsWRlUEpqGYcW90RudDUP8tc4PW6uoz81 c3yWseC8gG7YHdXO9RZtgFpMnqRbb8ZEXIV1AwENHbmwwLD8OeCxL94RdGP1t+Z94xz1 KhTQqlfD92sWhtd3zo7anqL4VIJW0dYCqLSEBjFEoAZN9nb/U3qiD1RY14XAH1bEZkPy QCBguhnlpu8xUFnSwuHJsumdfmxmj+9fdfZXhCENZTtlpcWH2WJseWUE1na/iDNpXI0O 8S6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=9GAgt6F/+6L41XewkZ0s9RxdOW7J/x7MBfpH99EPVvk=; b=YVHhdE7TM5x5CgBW1Iu+BmM7UGnEBNw3BThfmO2bhKddGzEnTZqS/aPPpwGlQHZHO1 BTSyp2bcld2wAZgHUAsSMqvR77QrMwmmjQs8/wY1WXIWxemvdo88AUd7LqxySStSwx3F ofUq6rj20zssOMbBewgBjOyMh9D6bhzchltGZHKN8581P0jY9uzryI6F5OHu7MiFv8YX C80DQQmPY8t4i6cbBJHmxonQaKUHvLwcKPuPMdlR9voxbGVeeVTMnBIvS7/9vW7iXb9r 5ckTMKBuMydp8M7LcsIkiBQm/yrS0dmjIf1gxhQjNN4yMtzz848C1WfkUH06a22Eni4G /gAw== X-Gm-Message-State: ALoCoQl5d8gtWa1V9jPY/RYq3mYDknm74TUH9D7JfaY5hANGtJ0kVrbsuOc5dr8WY9JovGv7d+QoQ4cUPeY7jUlOLblTERlZnw== X-Received: by 10.13.218.198 with SMTP id c189mr98211377ywe.165.1452446644499; Sun, 10 Jan 2016 09:24:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.249.197 with HTTP; Sun, 10 Jan 2016 09:23:25 -0800 (PST) In-Reply-To: References: <5660B824.7010807@goodadvice.pages.de> <5661CD94.2070209@goodadvice.pages.de> From: Eric Rescorla Date: Sun, 10 Jan 2016 09:23:25 -0800 Message-ID: To: Justin Uberti Content-Type: multipart/alternative; boundary=94eb2c08192a4d2b760528fe16e0 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP: why is iceCandidatePoolSize an integer? 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: Sun, 10 Jan 2016 17:24:07 -0000 --94eb2c08192a4d2b760528fe16e0 Content-Type: text/plain; charset=UTF-8 I agree with Justin. Remember that this is an optimization and it only impacts the *timing* of the delivery of the candidates. If we get to the point where w find that this wasn't enough control, we should be able deal with that later i a backward compatible way. -Ekr On Fri, Jan 8, 2016 at 5:22 PM, Justin Uberti wrote: > [late to the party] > > I'd be reluctant to add any more complexity to the operation of the > candidate pool - as Martin points out, it is already quite complex. > > If you don't want to pregather all types of candidates, just don't use it. > > > > On Sat, Dec 5, 2015 at 1:40 AM, Martin Thomson > wrote: > >> On 5 December 2015 at 04:29, Philipp Hancke >> wrote: >> > But if this is about components, how can the application make a decision >> > whether to pre-gather and hold on to stun or relay candidates (which >> > consumes resources)? >> >> The application might be able to defer the gathering of candidates via >> relays (I don't think that STUN is a real resource concern) by only >> providing the relays as stun URIs, or not providing them at all, then >> updating the iceServers with setConfiguration. >> >> I don't know if this is something that would work, we'd have to spec that. >> >> I'm actually beginning to question the utility of the pre-warming >> thing. Maybe it's a performance gain, but it's certainly quite >> complex. >> >> >> No, this counts components. >> > >> > >> > Calling it iceCandidatePoolSize in the w3c spec seems odd to me then ;-) >> >> Yeah, I'm sure that - given it's current level of interoperability >> (i.e., zero) - the working group might be receptive to suggestions of >> a more accurate name. >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --94eb2c08192a4d2b760528fe16e0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I agree with Justin. Remember that this is an optimization= and it only impacts
the *timing* of the delivery of the candidates. If= we get to the point where w
find that this wasn't enough con= trol, we should be able deal with that later i
a backward compati= ble way.

-Ekr

<= div class=3D"gmail_extra">
On Fri, Jan 8, 201= 6 at 5:22 PM, Justin Uberti <juberti@google.com> wrote:
=
[late to the party]
I'd be reluctant to add any more complexity to the operatio= n of the candidate pool - as Martin points out, it is already quite complex= .

If you don't want to pregather all types of = candidates, just don't use it.



On Sat, Dec 5, 2015 at 1:40 AM, Martin Thomson <martin.thomson@gmail.com> wrote:
On 5 December 2015 at 04:29, Philipp Hancke <fippo@goodadvice.pages= .de> wrote:
> But if this is about components, how can the application make a decisi= on
> whether to pre-gather and hold on to stun or relay candidates (which > consumes resources)?

The application might be able to defer the gathering of candidates v= ia
relays (I don't think that STUN is a real resource concern) by only
providing the relays as stun URIs, or not providing them at all, then
updating the iceServers with setConfiguration.

I don't know if this is something that would work, we'd have to spe= c that.

I'm actually beginning to question the utility of the pre-warming
thing.=C2=A0 Maybe it's a performance gain, but it's certainly quit= e
complex.

>> No, this counts components.
>
>
> Calling it iceCandidatePoolSize in the w3c spec seems odd to me then ;= -)

Yeah, I'm sure that - given it's current level of interopera= bility
(i.e., zero) - the working group might be receptive to suggestions of
a more accurate name.

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


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


--94eb2c08192a4d2b760528fe16e0-- From nobody Sun Jan 10 14:25:19 2016 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 A2C7D1A0AFE for ; Sun, 10 Jan 2016 14:25:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.021 X-Spam-Level: * X-Spam-Status: No, score=1.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_47=0.6, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no 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 484JRfMsiH41 for ; Sun, 10 Jan 2016 14:24:58 -0800 (PST) Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FEAA1A0AC8 for ; Sun, 10 Jan 2016 14:24:58 -0800 (PST) Received: by mail-vk0-x232.google.com with SMTP id i129so77782322vkb.0 for ; Sun, 10 Jan 2016 14:24:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=2L/0sdEfqmYBdaUWh333UHblGd07dv6IudXTlzJ/Sd8=; b=CcJfSFyztCxp81urFsYKYMiCgYknl4rgFtPfIsMoCY1QyblqsoP5a7PtQoDYHPN8o1 m72AlqQHK9L0/PTHReBd+/ZbEA5U4R7cJVop0H904tyczm3WKeIRgNr4NPZ66F4eJ1n7 /als1WBiKm92zM/8v3hInPd6uLdCarhZoEb21W6Neh2fxJo8HV9IFBYL02Rl4/d1+whS 2PeWcpuBLPED7VyLCSgeUHpjLp5Lnfp0xwRP9wbYCMpbCQfJbzMCyOgA6agEKEFtmxYZ X361M8TUAJ2DaR3M5KJtJxggbE42j+1OYjspuTXxWbEM4IsxvX1iqLOncGDVL7EUqrWZ YLEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=2L/0sdEfqmYBdaUWh333UHblGd07dv6IudXTlzJ/Sd8=; b=HpxwCCS4+eThoeChBbIHUKh4P7vxvfNya5fuEXBCFuf8biQ04otTjTzPWNSqtIBSa/ V2hTqrwkZPrwLC4PcHOdj0QldUAmZlDtIkpg4HkM2CtxNA/oUkjPnSqjDInhvwVHFmrr gxPqPQylTi/3bJTFQ+3xE+HtmEvkAMx3wshSWbnaT0hpyDfG6/GC80tkBPI6J761GLHz 5zt2ZPGtjv0bnMGW/qqqSy+THNNYufb24eCwegc22+O/DxGSSdDEKVoW491lZIjEoVbq KNg1FIGDbKN+vCvZoO7X5S4U14uKDCCp23ScI7OKVUJhpblCYJ1oCK9/Es9lWpnWG7mY jk1w== X-Gm-Message-State: ALoCoQn74q5ztMZHVRPqR7ZQ6KtPrqhwPBhwadBxRUQRnDfXxeV1yhGePlvtapgTFP1a9uhwOFuEfAssArQcLb7ycK11Hr1rR+feSkj7ANU/NWlD3hDLp40= X-Received: by 10.31.149.78 with SMTP id x75mr71499671vkd.103.1452464697465; Sun, 10 Jan 2016 14:24:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.198.132 with HTTP; Sun, 10 Jan 2016 14:24:37 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37D1020D@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37CC9AF8@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37D1020D@ESESSMB209.ericsson.se> From: Justin Uberti Date: Sun, 10 Jan 2016 14:24:37 -0800 Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=001a1142674857b73b0529024a20 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP: Usage of a=rtcp attribute 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: Sun, 10 Jan 2016 22:25:00 -0000 --001a1142674857b73b0529024a20 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I think the text is pretty clear that you need to add an a=3Drtcp attribute= : The default candidates are added to the SDP as the default destination for media. For streams based on RTP, this is done by placing the IP address and port of the RTP candidate into the c and m lines, respectively. *If the agent is utilizing RTCP, it MUST encode the RTCP candidate using the a=3Drtcp attribute as defined in RFC 3605 [RFC3605 ].* If RTCP is not in use, the agent MUST signal that using b=3DRS:0 and b=3DRR:0 as defined in RFC 3556 [RFC3556 ]. On Fri, Jan 8, 2016 at 9:32 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > Eventhough the text in 5245 is a little unclear (should probably be fixed > in 5245bis) I don't think it says that you must include the rtcp attribut= e > - it describes how to encode the rtcp candidate. > > Regards, > > Christer > > > Sent from my Windows Phone > ------------------------------ > From: Justin Uberti > Sent: =E2=80=8E09/=E2=80=8E01/=E2=80=8E2016 03:41 > To: Christer Holmberg > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] JSEP: Usage of a=3Drtcp attribute > > Unfortunately, that would contradict 5245. See > https://tools.ietf.org/html/rfc5245#section-4.3, 6th para. > > Perhaps we could say that trickle with non-mux-exclusive should use > a=3Drtcp:10 or some such... > > On Sun, Dec 13, 2015 at 7:02 AM, Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > >> Hi, >> >> >> >> Section 5.2.1 of draft-jsep contains the following statement: >> >> >> >> =E2=80=9Co An "a=3Drtcp" line, as specified in [RFC3605], Section 2.= 1, >> >> containing the dummy value "9 IN IP4 0.0.0.0", because no >> >> candidates have yet been gathered.=E2=80=9D >> >> >> >> =E2=80=A6i.e. the same port:address as in the associated c/m-line. >> >> >> >> The problem is that the currently suggested mechanism to indicate >> exclusive support of RTP/RTCP-mux also says that the a=3Drtcp line shall= be >> identical to the c/m-line. >> >> >> >> My question is: is there really a need to always include the rtcp >> attribute in trickle offers? Isn=E2=80=99t it enough to indicate port 9 = in the m- >> line, and address 0.0.0.0 in the c-line? In my opinion that would also >> apply to RTCP. >> >> >> >> Example: >> >> >> >> JSEP trickle offer **without** mux-exclusive indication: >> >> >> >> c=3DIN IP4 0.0.0.0 >> >> m=3Daudio 9=E2=80=A6 >> >> a=3Drtcp-mux >> >> >> >> JSEP trickle offer **with** mux-exclusive indication: >> >> >> >> c=3DIN IP4 0.0.0.0 >> >> m=3Daudio 9=E2=80=A6 >> >> *a=3Drtcp: 9 IN IP4 0.0.0.0* >> >> a=3Drtcp-mux >> >> >> >> Regards, >> >> >> >> Christer >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> >> > --001a1142674857b73b0529024a20 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I think the text is pretty clear that you need to add an a= =3Drtcp attribute:

   The default c=
andidates are added to the SDP as the default
   destination for media.  For streams based on RTP, this is done by
   placing the IP address and port of the RTP candidate into the c and m
   lines, respectively.  If the agent is utilizing RTCP, it MUST encode
   the RTCP candidate using the a=3Drtcp attribute as defined in RFC 3605
   [RFC3605].  If RTCP is not in use, the agent MUST signal that =
using
   b=3DRS:0 and b=3DRR:0 as defined in RFC 3556 [RFC3556].
<= div class=3D"gmail_extra">
On Fri, Jan 8, 201= 6 at 9:32 PM, Christer Holmberg <christer.holmberg@ericsson.c= om> wrote:
Hi,

Eventhough the text in 5245 is a little unclear (should probably be fixed i= n 5245bis) I don't think it says that you must include the rtcp attribu= te - it describes how to encode the rtcp candidate.

Regards,

Christer


Sent from my Windows Phone
From: Justin Uberti<= br> Sent: =E2=80= =8E09/=E2=80=8E01/=E2=80=8E2016 03:41
To: Christer Holm= berg
Cc: rtcweb@ietf.org Subject: Re: [r= tcweb] JSEP: Usage of a=3Drtcp attribute

Unfortunately, that would contradict 5245. See=C2=A0htt= ps://tools.ietf.org/html/rfc5245#section-4.3, 6th para.

Perhaps we could say that trickle with non-mux-exclusive should use a= =3Drtcp:10 or some such...

On Sun, Dec 13, 2015 at 7:02 AM, Christer Holmbe= rg <chr= ister.holmberg@ericsson.com> wrote:

Hi,

=C2=A0

Section 5.2.1 of draft-jsep contains the following s= tatement:

=C2=A0

=C2=A0=C2=A0 =E2=80=9Co =C2=A0An "a=3Drtcp"= ; line, as specified in [RFC3605], Section 2.1,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 containing the dummy = value "9 IN IP4 0.0.0.0", because no

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 candidates have yet b= een gathered.=E2=80=9D

=C2=A0

=E2=80=A6i.e. the same port:address as in the associ= ated c/m-line.

=C2=A0

The problem is that the currently suggested mechanis= m to indicate exclusive support of RTP/RTCP-mux also says that the a=3Drtcp= line shall be identical to the c/m-line.

=C2=A0

My question is: is there really a need to always inc= lude the rtcp attribute in trickle offers? Isn=E2=80=99t it enough to indic= ate port 9 in the m- line, and address 0.0.0.0 in the c-line? In my opinion= that would also apply to RTCP.

=C2=A0

Example:

=C2=A0

JSEP trickle offer *without* mux-exclusive in= dication:

=C2=A0

c=3DIN IP4 0.0.0.0 <= /u>

m=3Daudio 9=E2=80=A6=

a=3Drtcp-mux<= /u>

=C2=A0

JSEP trickle offer *with* mux-exclusive indic= ation:

=C2=A0

c=3DIN IP4 0.0.0.0 <= /u>

m=3Daudio 9=E2=80=A6=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 a=3Drtcp: 9 IN IP4 0.0.0.0=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 a=3Drtcp-mux

=C2=A0

Regards,=

=C2=A0

Christer


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



--001a1142674857b73b0529024a20-- From nobody Mon Jan 11 04:35:13 2016 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 BC1081A89B4 for ; Mon, 11 Jan 2016 04:35:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_47=0.6, RCVD_IN_DNSWL_MED=-2.3] 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 fW9FZvb_4F1S for ; Mon, 11 Jan 2016 04:35:08 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5B181A89B0 for ; Mon, 11 Jan 2016 04:35:07 -0800 (PST) X-AuditID: c1b4fb25-f797e6d000007600-b7-5693a179d7c3 Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id F0.C8.30208.971A3965; Mon, 11 Jan 2016 13:35:05 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.76]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0248.002; Mon, 11 Jan 2016 13:35:05 +0100 From: Christer Holmberg To: Justin Uberti Thread-Topic: [rtcweb] JSEP: Usage of a=rtcp attribute Thread-Index: AdE1tk5+GgxwzrGpR6mZvYz9J4lNJQUwCquAAAopOu8AU4wngAAfsOHA Date: Mon, 11 Jan 2016 12:35:04 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37D11DAE@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37CC9AF8@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37D1020D@ESESSMB209.ericsson.se> In-Reply-To: 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_7594FB04B1934943A5C02806D1A2204B37D11DAEESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprLIsWRmVeSWpSXmKPExsUyM2K7qG7lwslhBvc3GVlsnSpksfZfO7sD k8eCTaUeS5b8ZApgiuKySUnNySxLLdK3S+DKeLzkMlvBvGOMFTs7mpgbGBsOMnYxcnJICJhI nF7XwQZhi0lcuLcezBYSOMwo8etpDIS9mFHizXr+LkYODjYBC4nuf9ogYREBNYmHs3axgtjM AuoSdxafYwexhQVMJY79ncQGUWMmce/xBSYI201i/oH77CBjWARUJTav0gAJ8wr4Sqx5vQMo zAW0aT6TRMfdq2D1nAKBEh8O/AKbwwh02vdTa5ggdolL3HoynwniZAGJJXvOM0PYohIvH/9j hbCVJH5suMQCUZ8v0f/mEzPEMkGJkzOfsExgFJ2FZNQsJGWzkJTNAjqVWUBTYv0ufYgSRYkp 3Q/ZIWwNidY5c9mRxRcwsq9iFC1OLU7KTTcy1kstykwuLs7P08tLLdnECIy0g1t+q+5gvPzG 8RCjAAejEg9vwaNJYUKsiWXFlbmHGCU4mJVEeHdnTw4T4k1JrKxKLcqPLyrNSS0+xCjNwaIk zpsk0xgmJJCeWJKanZpakFoEk2Xi4JRqYKx04WJZOFflerGK9tfYrMKvM39sXvt7XaZIpnKq 6wzNYueV/T1eCYvb5y336blv+L6oYvFtQYXDbjdvbNaOVFCyjmG3+uv+5Erog02cssfeOmrY nv5ryrbR1Ufxrd/CBwnME9YtWfGJK/Dw89R5piGJl7I+nuz3f9XCpON7uPHk18BIdpH6HiWW 4oxEQy3mouJEAHF1rbewAgAA Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP: Usage of a=rtcp attribute 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: Mon, 11 Jan 2016 12:35:10 -0000 --_000_7594FB04B1934943A5C02806D1A2204B37D11DAEESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkkgdGhpbmsgd2UgY291bGQgY2xhcmlmeSB0aGF0IHRoZSBhdHRyaWJ1dGUgaXMgdXNl ZCBvbmx5IGlmIHRoZXJlIGlzIGEgcmVhbCBwb3J0LCBhbmQgaWYgc29tZXRoaW5nIGlzIHRvIGJl IHNlbnQuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCkZyb206IEp1c3RpbiBVYmVydGkgW21h aWx0bzpqdWJlcnRpQGdvb2dsZS5jb21dDQpTZW50OiAxMS4gdGFtbWlrdXV0YSAyMDE2IDA6MjUN ClRvOiBDaHJpc3RlciBIb2xtYmVyZw0KQ2M6IHJ0Y3dlYkBpZXRmLm9yZw0KU3ViamVjdDogUmU6 IFtydGN3ZWJdIEpTRVA6IFVzYWdlIG9mIGE9cnRjcCBhdHRyaWJ1dGUNCg0KSSB0aGluayB0aGUg dGV4dCBpcyBwcmV0dHkgY2xlYXIgdGhhdCB5b3UgbmVlZCB0byBhZGQgYW4gYT1ydGNwIGF0dHJp YnV0ZToNCg0KDQogICBUaGUgZGVmYXVsdCBjYW5kaWRhdGVzIGFyZSBhZGRlZCB0byB0aGUgU0RQ IGFzIHRoZSBkZWZhdWx0DQoNCiAgIGRlc3RpbmF0aW9uIGZvciBtZWRpYS4gIEZvciBzdHJlYW1z IGJhc2VkIG9uIFJUUCwgdGhpcyBpcyBkb25lIGJ5DQoNCiAgIHBsYWNpbmcgdGhlIElQIGFkZHJl c3MgYW5kIHBvcnQgb2YgdGhlIFJUUCBjYW5kaWRhdGUgaW50byB0aGUgYyBhbmQgbQ0KDQogICBs aW5lcywgcmVzcGVjdGl2ZWx5LiAgSWYgdGhlIGFnZW50IGlzIHV0aWxpemluZyBSVENQLCBpdCBN VVNUIGVuY29kZQ0KDQogICB0aGUgUlRDUCBjYW5kaWRhdGUgdXNpbmcgdGhlIGE9cnRjcCBhdHRy aWJ1dGUgYXMgZGVmaW5lZCBpbiBSRkMgMzYwNTxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv cmZjMzYwNT4NCg0KICAgW1JGQzM2MDU8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzM2 MDU+XS4gIElmIFJUQ1AgaXMgbm90IGluIHVzZSwgdGhlIGFnZW50IE1VU1Qgc2lnbmFsIHRoYXQg dXNpbmcNCg0KICAgYj1SUzowIGFuZCBiPVJSOjAgYXMgZGVmaW5lZCBpbiBSRkMgMzU1NjxodHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjMzU1Nj4gW1JGQzM1NTY8aHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL3JmYzM1NTY+XS4NCg0KT24gRnJpLCBKYW4gOCwgMjAxNiBhdCA5OjMyIFBN LCBDaHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPG1haWx0 bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+PiB3cm90ZToNCkhpLA0KDQpFdmVudGhv dWdoIHRoZSB0ZXh0IGluIDUyNDUgaXMgYSBsaXR0bGUgdW5jbGVhciAoc2hvdWxkIHByb2JhYmx5 IGJlIGZpeGVkIGluIDUyNDViaXMpIEkgZG9uJ3QgdGhpbmsgaXQgc2F5cyB0aGF0IHlvdSBtdXN0 IGluY2x1ZGUgdGhlIHJ0Y3AgYXR0cmlidXRlIC0gaXQgZGVzY3JpYmVzIGhvdyB0byBlbmNvZGUg dGhlIHJ0Y3AgY2FuZGlkYXRlLg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoNClNlbnQgZnJv bSBteSBXaW5kb3dzIFBob25lDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRnJv bTogSnVzdGluIFViZXJ0aTxtYWlsdG86anViZXJ0aUBnb29nbGUuY29tPg0KU2VudDog4oCOMDkv 4oCOMDEv4oCOMjAxNiAwMzo0MQ0KVG86IENocmlzdGVyIEhvbG1iZXJnPG1haWx0bzpjaHJpc3Rl ci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+DQpDYzogcnRjd2ViQGlldGYub3JnPG1haWx0bzpydGN3 ZWJAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW3J0Y3dlYl0gSlNFUDogVXNhZ2Ugb2YgYT1ydGNw IGF0dHJpYnV0ZQ0KVW5mb3J0dW5hdGVseSwgdGhhdCB3b3VsZCBjb250cmFkaWN0IDUyNDUuIFNl ZSBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNTI0NSNzZWN0aW9uLTQuMywgNnRoIHBh cmEuDQoNClBlcmhhcHMgd2UgY291bGQgc2F5IHRoYXQgdHJpY2tsZSB3aXRoIG5vbi1tdXgtZXhj bHVzaXZlIHNob3VsZCB1c2UgYT1ydGNwOjEwIG9yIHNvbWUgc3VjaC4uLg0KDQpPbiBTdW4sIERl YyAxMywgMjAxNSBhdCA3OjAyIEFNLCBDaHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJl cmdAZXJpY3Nzb24uY29tPG1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+PiB3 cm90ZToNCkhpLA0KDQpTZWN0aW9uIDUuMi4xIG9mIGRyYWZ0LWpzZXAgY29udGFpbnMgdGhlIGZv bGxvd2luZyBzdGF0ZW1lbnQ6DQoNCiAgIOKAnG8gIEFuICJhPXJ0Y3AiIGxpbmUsIGFzIHNwZWNp ZmllZCBpbiBbUkZDMzYwNV0sIFNlY3Rpb24gMi4xLA0KICAgICAgY29udGFpbmluZyB0aGUgZHVt bXkgdmFsdWUgIjkgSU4gSVA0IDAuMC4wLjAiLCBiZWNhdXNlIG5vDQogICAgICBjYW5kaWRhdGVz IGhhdmUgeWV0IGJlZW4gZ2F0aGVyZWQu4oCdDQoNCuKApmkuZS4gdGhlIHNhbWUgcG9ydDphZGRy ZXNzIGFzIGluIHRoZSBhc3NvY2lhdGVkIGMvbS1saW5lLg0KDQpUaGUgcHJvYmxlbSBpcyB0aGF0 IHRoZSBjdXJyZW50bHkgc3VnZ2VzdGVkIG1lY2hhbmlzbSB0byBpbmRpY2F0ZSBleGNsdXNpdmUg c3VwcG9ydCBvZiBSVFAvUlRDUC1tdXggYWxzbyBzYXlzIHRoYXQgdGhlIGE9cnRjcCBsaW5lIHNo YWxsIGJlIGlkZW50aWNhbCB0byB0aGUgYy9tLWxpbmUuDQoNCk15IHF1ZXN0aW9uIGlzOiBpcyB0 aGVyZSByZWFsbHkgYSBuZWVkIHRvIGFsd2F5cyBpbmNsdWRlIHRoZSBydGNwIGF0dHJpYnV0ZSBp biB0cmlja2xlIG9mZmVycz8gSXNu4oCZdCBpdCBlbm91Z2ggdG8gaW5kaWNhdGUgcG9ydCA5IGlu IHRoZSBtLSBsaW5lLCBhbmQgYWRkcmVzcyAwLjAuMC4wIGluIHRoZSBjLWxpbmU/IEluIG15IG9w aW5pb24gdGhhdCB3b3VsZCBhbHNvIGFwcGx5IHRvIFJUQ1AuDQoNCkV4YW1wbGU6DQoNCkpTRVAg dHJpY2tsZSBvZmZlciAqd2l0aG91dCogbXV4LWV4Y2x1c2l2ZSBpbmRpY2F0aW9uOg0KDQpjPUlO IElQNCAwLjAuMC4wDQptPWF1ZGlvIDnigKYNCmE9cnRjcC1tdXgNCg0KSlNFUCB0cmlja2xlIG9m ZmVyICp3aXRoKiBtdXgtZXhjbHVzaXZlIGluZGljYXRpb246DQoNCmM9SU4gSVA0IDAuMC4wLjAN Cm09YXVkaW8gOeKApg0KICAgICAgICAgICAgICBhPXJ0Y3A6IDkgSU4gSVA0IDAuMC4wLjANCiAg ICAgICAgICAgICAgYT1ydGNwLW11eA0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KcnRjd2ViIG1haWxpbmcg bGlzdA0KcnRjd2ViQGlldGYub3JnPG1haWx0bzpydGN3ZWJAaWV0Zi5vcmc+DQpodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYg0KDQoNCg== --_000_7594FB04B1934943A5C02806D1A2204B37D11DAEESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQg MyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5v c2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5N c29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1h cmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJU aW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRN TCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAx cHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnAu TXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2lu OjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQt ZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFy DQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250 LWZhbWlseToiQ29uc29sYXMiLCJzZXJpZiI7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6Rkk7fQ0K c3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4u QmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJ bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0K CWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjsNCgltc28tZmFyZWFzdC1sYW5ndWFn ZTpGSTt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdl OkVOLVVTO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCglt YXJnaW46NzAuODVwdCAyLjBjbSA3MC44NXB0IDIuMGNtO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7 cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48 IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0 PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5 b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRkkiIGxpbms9ImJs dWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+SGksPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgdGhp bmsgd2UgY291bGQgY2xhcmlmeSB0aGF0IHRoZSBhdHRyaWJ1dGUgaXMgdXNlZCBvbmx5IGlmIHRo ZXJlIGlzIGEgcmVhbCBwb3J0LCBhbmQgaWYgc29tZXRoaW5nIGlzIHRvIGJlIHNlbnQuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPkNocmlzdGVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206 PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBKdXN0 aW4gVWJlcnRpIFttYWlsdG86anViZXJ0aUBnb29nbGUuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+ IDExLiB0YW1taWt1dXRhIDIwMTYgMDoyNTxicj4NCjxiPlRvOjwvYj4gQ2hyaXN0ZXIgSG9sbWJl cmc8YnI+DQo8Yj5DYzo8L2I+IHJ0Y3dlYkBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBS ZTogW3J0Y3dlYl0gSlNFUDogVXNhZ2Ugb2YgYT1ydGNwIGF0dHJpYnV0ZTxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgdGhpbmsgdGhlIHRleHQgaXMgcHJldHR5IGNsZWFy IHRoYXQgeW91IG5lZWQgdG8gYWRkIGFuIGE9cnRjcCBhdHRyaWJ1dGU6PG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IFRo ZSBkZWZhdWx0IGNhbmRpZGF0ZXMgYXJlIGFkZGVkIHRvIHRoZSBTRFAgYXMgdGhlIGRlZmF1bHQ8 bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4m bmJzcDsmbmJzcDsgZGVzdGluYXRpb24gZm9yIG1lZGlhLiZuYnNwOyBGb3Igc3RyZWFtcyBiYXNl ZCBvbiBSVFAsIHRoaXMgaXMgZG9uZSBieTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBwbGFjaW5nIHRoZSBJUCBhZGRy ZXNzIGFuZCBwb3J0IG9mIHRoZSBSVFAgY2FuZGlkYXRlIGludG8gdGhlIGMgYW5kIG08bzpwPjwv bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsm bmJzcDsgbGluZXMsIHJlc3BlY3RpdmVseS4mbmJzcDsgPGI+SWYgdGhlIGFnZW50IGlzIHV0aWxp emluZyBSVENQLCBpdCBNVVNUIGVuY29kZTxvOnA+PC9vOnA+PC9iPjwvc3Bhbj48L3ByZT4NCjxw cmU+PGI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgdGhlIFJUQ1AgY2Fu ZGlkYXRlIHVzaW5nIHRoZSBhPXJ0Y3AgYXR0cmlidXRlIGFzIGRlZmluZWQgaW4gPGEgaHJlZj0i aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzM2MDUiPlJGQyAzNjA1PC9hPjxvOnA+PC9v OnA+PC9zcGFuPjwvYj48L3ByZT4NCjxwcmU+PGI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4m bmJzcDsmbmJzcDsgWzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmMzNjA1 IiB0aXRsZT0iJnF1b3Q7UmVhbCBUaW1lIENvbnRyb2wgUHJvdG9jb2wgKFJUQ1ApIGF0dHJpYnV0 ZSBpbiBTZXNzaW9uIERlc2NyaXB0aW9uIFByb3RvY29sIChTRFApJnF1b3Q7Ij5SRkMzNjA1PC9h Pl0uPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyBJZiBSVENQIGlz IG5vdCBpbiB1c2UsIHRoZSBhZ2VudCBNVVNUIHNpZ25hbCB0aGF0IHVzaW5nPG86cD48L286cD48 L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7 IGI9UlM6MCBhbmQgYj1SUjowIGFzIGRlZmluZWQgaW4gPGEgaHJlZj0iaHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL3JmYzM1NTYiPlJGQyAzNTU2PC9hPiBbPGEgaHJlZj0iaHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL3JmYzM1NTYiIHRpdGxlPSImcXVvdDtTZXNzaW9uIERlc2NyaXB0aW9u IFByb3RvY29sIChTRFApIEJhbmR3aWR0aCBNb2RpZmllcnMgZm9yIFJUUCBDb250cm9sIFByb3Rv Y29sIChSVENQKSBCYW5kd2lkdGgmcXVvdDsiPlJGQzM1NTY8L2E+XS48bzpwPjwvbzpwPjwvc3Bh bj48L3ByZT4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gRnJpLCBK YW4gOCwgMjAxNiBhdCA5OjMyIFBNLCBDaHJpc3RlciBIb2xtYmVyZyAmbHQ7PGEgaHJlZj0ibWFp bHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmNocmlz dGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij5IaSw8YnI+DQo8YnI+DQpFdmVudGhvdWdoIHRoZSB0ZXh0IGluIDUyNDUg aXMgYSBsaXR0bGUgdW5jbGVhciAoc2hvdWxkIHByb2JhYmx5IGJlIGZpeGVkIGluIDUyNDViaXMp IEkgZG9uJ3QgdGhpbmsgaXQgc2F5cyB0aGF0IHlvdSBtdXN0IGluY2x1ZGUgdGhlIHJ0Y3AgYXR0 cmlidXRlIC0gaXQgZGVzY3JpYmVzIGhvdyB0byBlbmNvZGUgdGhlIHJ0Y3AgY2FuZGlkYXRlLjxi cj4NCjxicj4NClJlZ2FyZHMsPGJyPg0KPGJyPg0KQ2hyaXN0ZXI8YnI+DQo8YnI+DQo8YnI+DQpT ZW50IGZyb20gbXkgV2luZG93cyBQaG9uZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdiBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHls ZT0idGV4dC1hbGlnbjpjZW50ZXIiPg0KPGhyIHNpemU9IjIiIHdpZHRoPSIxMDAlIiBhbGlnbj0i Y2VudGVyIj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0 b206MTIuMHB0Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206DQo8L3NwYW4+ PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGEgaHJlZj0ibWFpbHRvOmp1YmVydGlA Z29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPkp1c3RpbiBVYmVydGk8L2E+PC9zcGFuPjxicj4N CjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+U2VudDogPC9zcGFuPg0KPC9iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+4oCOMDkv4oCOMDEv4oCOMjAxNiAwMzo0MTwvc3Bhbj48 YnI+DQo8Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlRvOiA8L3NwYW4+PC9iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGEgaHJlZj0ibWFpbHRvOmNocmlzdGVyLmhvbG1iZXJn QGVyaWNzc29uLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPkNocmlzdGVyIEhvbG1iZXJnPC9hPjwvc3Bh bj48YnI+DQo8Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkNjOiA8L3NwYW4+PC9iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGEgaHJlZj0ibWFpbHRvOnJ0Y3dlYkBpZXRmLm9y ZyIgdGFyZ2V0PSJfYmxhbmsiPnJ0Y3dlYkBpZXRmLm9yZzwvYT48L3NwYW4+PGJyPg0KPGI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5TdWJqZWN0OiA8L3NwYW4+DQo8L2I+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij5SZTogW3J0Y3dlYl0gSlNFUDogVXNhZ2Ugb2YgYT1ydGNwIGF0 dHJpYnV0ZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlVuZm9ydHVuYXRlbHksIHRoYXQgd291bGQg Y29udHJhZGljdCA1MjQ1LiBTZWUmbmJzcDs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvcmZjNTI0NSNzZWN0aW9uLTQuMyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9yZmM1MjQ1I3NlY3Rpb24tNC4zPC9hPiwgNnRoIHBhcmEuDQo8bzpwPjwv bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlBlcmhhcHMgd2UgY291bGQg c2F5IHRoYXQgdHJpY2tsZSB3aXRoIG5vbi1tdXgtZXhjbHVzaXZlIHNob3VsZCB1c2UgYT1ydGNw OjEwIG9yIHNvbWUgc3VjaC4uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5PbiBTdW4sIERlYyAxMywgMjAxNSBhdCA3OjAyIEFNLCBDaHJpc3Rl ciBIb2xtYmVyZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29u LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTwvYT4m Z3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj5IaSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj4mbmJzcDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj5TZWN0 aW9uIDUuMi4xIG9mIGRyYWZ0LWpzZXAgY29udGFpbnMgdGhlIGZvbGxvd2luZyBzdGF0ZW1lbnQ6 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5n PSJFTi1HQiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+Jm5ic3A7Jm5ic3A7IOKAnG8gJm5ic3A7QW4gJnF1b3Q7 YT1ydGNwJnF1b3Q7IGxpbmUsIGFzIHNwZWNpZmllZCBpbiBbUkZDMzYwNV0sIFNlY3Rpb24gMi4x LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFu Zz0iRU4tR0IiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBjb250YWluaW5nIHRoZSBk dW1teSB2YWx1ZSAmcXVvdDs5IElOIElQNCAwLjAuMC4wJnF1b3Q7LCBiZWNhdXNlIG5vPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1H QiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGNhbmRpZGF0ZXMgaGF2ZSB5ZXQgYmVl biBnYXRoZXJlZC7igJ08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj7igKZpLmUuIHRoZSBzYW1lIHBv cnQ6YWRkcmVzcyBhcyBpbiB0aGUgYXNzb2NpYXRlZCBjL20tbGluZS48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj4mbmJzcDs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9 IkVOLUdCIj5UaGUgcHJvYmxlbSBpcyB0aGF0IHRoZSBjdXJyZW50bHkgc3VnZ2VzdGVkIG1lY2hh bmlzbSB0byBpbmRpY2F0ZSBleGNsdXNpdmUgc3VwcG9ydCBvZiBSVFAvUlRDUC1tdXggYWxzbyBz YXlzIHRoYXQgdGhlIGE9cnRjcCBsaW5lIHNoYWxsIGJlIGlkZW50aWNhbCB0byB0aGUgYy9tLWxp bmUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBs YW5nPSJFTi1HQiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+TXkgcXVlc3Rpb24gaXM6IGlzIHRoZXJlIHJlYWxs eSBhIG5lZWQgdG8gYWx3YXlzIGluY2x1ZGUgdGhlIHJ0Y3AgYXR0cmlidXRlIGluIHRyaWNrbGUg b2ZmZXJzPyBJc27igJl0IGl0IGVub3VnaCB0byBpbmRpY2F0ZSBwb3J0IDkgaW4gdGhlIG0tIGxp bmUsIGFuZCBhZGRyZXNzDQogMC4wLjAuMCBpbiB0aGUgYy1saW5lPyBJbiBteSBvcGluaW9uIHRo YXQgd291bGQgYWxzbyBhcHBseSB0byBSVENQLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPiZuYnNwOzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPkV4YW1w bGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBs YW5nPSJFTi1HQiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+SlNFUCB0cmlja2xlIG9mZmVyICo8Yj53aXRob3V0 PC9iPiogbXV4LWV4Y2x1c2l2ZSBpbmRpY2F0aW9uOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPiZuYnNwOzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWluZGVudDozNi4wcHQiPg0K PHNwYW4gbGFuZz0iRU4tR0IiPmM9SU4gSVA0IDAuMC4wLjAgPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvO3RleHQtaW5kZW50OjM2LjBwdCI+DQo8c3BhbiBsYW5n PSJFTi1HQiI+bT1hdWRpbyA54oCmPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvO3RleHQtaW5kZW50OjM2LjBwdCI+DQo8c3BhbiBsYW5nPSJFTi1HQiI+YT1ydGNw LW11eDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g bGFuZz0iRU4tR0IiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPkpTRVAgdHJpY2tsZSBvZmZlciAqPGI+d2l0aDwv Yj4qIG11eC1leGNsdXNpdmUgaW5kaWNhdGlvbjo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj4mbmJzcDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87dGV4dC1pbmRlbnQ6MzYuMHB0Ij4NCjxz cGFuIGxhbmc9IkVOLUdCIj5jPUlOIElQNCAwLjAuMC4wIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWluZGVudDozNi4wcHQiPg0KPHNwYW4gbGFuZz0i RU4tR0IiPm09YXVkaW8gOeKApjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPGI+YT1y dGNwOiA5IElOIElQNCAwLjAuMC4wPC9iPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBh PXJ0Y3AtbXV4PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBsYW5nPSJFTi1HQiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0i Y29sb3I6Izg4ODg4OCI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImNvbG9yOiM4ODg4ODgiPkNocmlz dGVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpydGN3ZWIgbWFpbGluZyBsaXN0 PGJyPg0KPGEgaHJlZj0ibWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnJ0 Y3dlYkBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3J0Y3dlYiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vcnRjd2ViPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_7594FB04B1934943A5C02806D1A2204B37D11DAEESESSMB209erics_-- From nobody Mon Jan 11 07:42:51 2016 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 CAF7E1A1AB6 for ; Mon, 11 Jan 2016 07:42:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.678 X-Spam-Level: X-Spam-Status: No, score=-0.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, SPF_PASS=-0.001] autolearn=no 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 mffmfSEPq99U for ; Mon, 11 Jan 2016 07:42:48 -0800 (PST) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF5A51A1B1D for ; Mon, 11 Jan 2016 07:42:48 -0800 (PST) Received: by mail-io0-x236.google.com with SMTP id g73so156097174ioe.3 for ; Mon, 11 Jan 2016 07:42:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vOmtsrRm864N+PRqGxUoEmlN04knVslipEYMm4yA+AY=; b=gZmFGE43185hLw6q6UxRlrhZ3gqXqFJH4GgnDsUDaEBb71Nbmp7oKfv1HRtLxP7z4n AdwOtoX9iynjh6yDTFJadlG3OTY6t9H+Z2pSur+P6sIQnlKiDIKbx7zBYGuqTwI5yQN4 9snT0D1wSOfXnE5FKq6G/+uQDBbMd8Rdhj0bwgyw653qKK6lCgfaA9XK6Utdqxpbip+j lOA08GLKULiEfuhn58FzXKRZjxcfLFXqMOT13rWxf4m1PuufeBi2eeQ/AiWI7d7oi6S1 y9dLNlLDyVGR6csFoTiS0IUD0tELljKWN3jCRgGcjWRNKBTnu8Z8QvM5iRrWL3JZiHp/ e6EA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=vOmtsrRm864N+PRqGxUoEmlN04knVslipEYMm4yA+AY=; b=FireCUBUIm3+egq9Nl74eqwJo8L2eicLB/+VBdmWa6Yw4AXum57f6B7j/teZddAbUq 6ZWo7YByBzHbPzU36B1SGzx0VQZTLWogGkECLG0LqELG69RXw64UVUJAaZRH/B3g6gfO aJMT1nN3J5TkB4wbEfX7cdo9E3F8E40UOgk99z0MtQg6uzB+qasWPavywphGlnmdHFtR 0T/F6+5OqRMfR7UR9By0A8ao+2mb/4lON0rkHc/TURmP1MwDrUbQOkY3UMBu1kK+Uz8i k5JXxeCyuZnZBBUd4+FkHIw5iBz5p04y6+TDh0UKCK5dEUhpmjCkCi7thhZxazRJYaH7 5RSQ== X-Gm-Message-State: ALoCoQmWhnOAOwN5n2Rzeqql0Z8MdM/jW1PDJe/XB8QsqKWmnYQiz1br40pfrp+s9OOgkrQ/BVoqlm8CY3k5dJhQBSw9KnPnEA== X-Received: by 10.107.44.199 with SMTP id s190mr104879851ios.24.1452526968187; Mon, 11 Jan 2016 07:42:48 -0800 (PST) Received: from mail-ig0-f175.google.com (mail-ig0-f175.google.com. [209.85.213.175]) by smtp.gmail.com with ESMTPSA id n8sm4781209igv.1.2016.01.11.07.42.43 for (version=TLSv1/SSLv3 cipher=OTHER); Mon, 11 Jan 2016 07:42:44 -0800 (PST) Received: by mail-ig0-f175.google.com with SMTP id mw1so113050524igb.1 for ; Mon, 11 Jan 2016 07:42:43 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.50.114.3 with SMTP id jc3mr12789023igb.2.1452526963475; Mon, 11 Jan 2016 07:42:43 -0800 (PST) Received: by 10.36.105.15 with HTTP; Mon, 11 Jan 2016 07:42:43 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37D11DAE@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37CC9AF8@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37D1020D@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37D11DAE@ESESSMB209.ericsson.se> Date: Mon, 11 Jan 2016 10:42:43 -0500 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: Christer Holmberg Content-Type: multipart/alternative; boundary=089e01538448af4bab052910c929 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP: Usage of a=rtcp attribute 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: Mon, 11 Jan 2016 15:42:49 -0000 --089e01538448af4bab052910c929 Content-Type: text/plain; charset=UTF-8 On Mon, Jan 11, 2016 at 7:35 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > I think we could clarify that the attribute is used only if there is a > real port, and if something is to be sent. > > > This most likely be a change to RFC 5245 not a clarification. It can definitely be proposed for RFC 5245 bis to ice working group. _____________ Roman Shpount --089e01538448af4bab052910c929 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Jan 11, 2016 at 7:35 AM, Christer Holmberg &= lt;chri= ster.holmberg@ericsson.com> wrote:

I think we could clarify that the attribute = is used only if there is a real port, and if something is to be sent.



This most likely be a change to RFC 5245 not a clarification. It can defin= itely be proposed for RFC 5245 bis to ice working group.
_____________
Roman Shpount
=C2= =A0
--089e01538448af4bab052910c929-- From nobody Mon Jan 11 08:12:21 2016 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 B7F1A1A6F42 for ; Mon, 11 Jan 2016 08:12:20 -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_14=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 uFmRo5ZMA0P4 for ; Mon, 11 Jan 2016 08:12:19 -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 AC8801A6F32 for ; Mon, 11 Jan 2016 08:12:18 -0800 (PST) X-AuditID: c1b4fb30-f79a76d000000a93-1f-5693d45f4db7 Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.183.66]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 5D.D0.02707.F54D3965; Mon, 11 Jan 2016 17:12:15 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.76]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.03.0248.002; Mon, 11 Jan 2016 17:12:15 +0100 From: Christer Holmberg To: Roman Shpount Thread-Topic: [rtcweb] JSEP: Usage of a=rtcp attribute Thread-Index: AdE1tk5+GgxwzrGpR6mZvYz9J4lNJQUwCquAAAopOu8AU4wngAAfsOHAAASQdoAAAyCBGg== Date: Mon, 11 Jan 2016 16:12:14 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37D1240D@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37CC9AF8@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37D1020D@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37D11DAE@ESESSMB209.ericsson.se>, In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B37D1240DESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprFIsWRmVeSWpSXmKPExsUyM2K7k278lclhBlO7TS22ThWymHFhKrPF 2n/t7A7MHgs2lXosWfKTyePWlIIA5igum5TUnMyy1CJ9uwSujDN3Z7EWnFKpeLRpO0sD4yP5 LkYODgkBE4knf+26GDmBTDGJC/fWs3UxcnEICRxmlOhf/pkVwlnMKNF7eRULSAObgIVE9z9t kAYRAVWJv98nM4HYzALeEp8WPWAHsYUFTCWO/Z3EBlFjJnHv8QUmCDtM4srRbWBxFqDemwfP gI3kFfCVaDvsBbFqBbPEwvX/GUFqOAUCJV5u7AerZwQ67vupNVC7xCWavqxkhThaQGLJnvPM ELaoxMvH/1ghavIlTn3aCjaHV0BQ4uTMJywTGEVmIWmfhaRsFpIyiLiBxJf3t6FsbYllC18z Q9j6Et3vTzMhiy9gZF/FKFqcWpyUm25kpJdalJlcXJyfp5eXWrKJERhjB7f8NtjB+PK54yFG AQ5GJR7egkeTwoRYE8uKK3MPMUpwMCuJ8KptnxwmxJuSWFmVWpQfX1Sak1p8iFGag0VJnDdJ pjFMSCA9sSQ1OzW1ILUIJsvEwSnVwLjkxYc3Pr9rIj/n3z7IUrn1vO6BN3+qfu4KPWUiu2P7 2sU1wQmN1cs2ykifiXRUEN+RKDObMXvV3+e5v3fofalkm+XH3uxrE7B7qw23+/nnM4zEn07Q 62ooXjf1t8VOo+spvb9Us4/PWa/+5OShzihrdwa5y1fvPpns8GaP6rJ0dZ0e7WSP0iolluKM REMt5qLiRABhGy+2rQIAAA== Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP: Usage of a=rtcp attribute 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: Mon, 11 Jan 2016 16:12:20 -0000 --_000_7594FB04B1934943A5C02806D1A2204B37D1240DESESSMB209erics_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable Hi, If we put it in 5245bis I assume JSEP (and trickle ICE) would have to refer= ence 5245bis. Currently I think both of those specs reference 5245, but I m= ay be wrong. It can be discussed whether it's a change or clarification. 5245 says that = the RTCP candidate shall be encoded using the rtcp attribute - but if you a= re doing trickle there is no candidate to encode. Regards, Christer Sent from my Windows Phone ________________________________ From: Roman Shpount Sent: =FD11/=FD01/=FD2016 17:42 To: Christer Holmberg Cc: Justin Uberti; rtcweb@ietf.org Subject: Re: [rtcweb] JSEP: Usage of a=3Drtcp attribute On Mon, Jan 11, 2016 at 7:35 AM, Christer Holmberg > wrote: I think we could clarify that the attribute is used only if there is a real= port, and if something is to be sent. This most likely be a change to RFC 5245 not a clarification. It can defini= tely be proposed for RFC 5245 bis to ice working group. _____________ Roman Shpount --_000_7594FB04B1934943A5C02806D1A2204B37D1240DESESSMB209erics_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
Hi,

If we put it in 5245bis I assume JSEP (and trickle ICE) would have to refer= ence 5245bis. Currently I think both of those specs reference 5245, but I m= ay be wrong.

It can be discussed whether it's a change or clarification. 5245 says that = the RTCP candidate shall be encoded using the rtcp attribute - but if you a= re doing trickle there is no candidate to encode.

Regards,

Christer

Sent from my Windows Phone
From: Roman Shpount
Sent: =FD11= /=FD01/=FD2016 17:42
To: Christer Holmberg Cc: Justin Uberti; rtcweb@ietf.org
Subject: Re: [= rtcweb] JSEP: Usage of a=3Drtcp attribute

On Mon, Jan 11, 2016 at 7:35 AM, Christer Ho= lmberg <chr= ister.holmberg@ericsson.com> wrote:

I think we could clarify that the attribut= e is used only if there is a real port, and if something is to be sent.



This most likely be a change to RFC 5245 not a clarification. It can d= efinitely be proposed for RFC 5245 bis to ice working group.
_____________
Roman Shpount
 
--_000_7594FB04B1934943A5C02806D1A2204B37D1240DESESSMB209erics_-- From nobody Tue Jan 12 11:34:18 2016 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 3BF331A8769 for ; Tue, 12 Jan 2016 11:34:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 ZyvxxjTgst-m for ; Tue, 12 Jan 2016 11:34:16 -0800 (PST) Received: from smtp81.iad3a.emailsrvr.com (smtp81.iad3a.emailsrvr.com [173.203.187.81]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDAD91A8759 for ; Tue, 12 Jan 2016 11:34:15 -0800 (PST) Received: from smtp11.relay.iad3a.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp11.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 1C274100498; Tue, 12 Jan 2016 14:34:15 -0500 (EST) X-Auth-ID: fluffy@iii.ca Received: by smtp11.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 5D29C100397; Tue, 12 Jan 2016 14:34:14 -0500 (EST) X-Sender-Id: fluffy@iii.ca Received: from [192.168.4.100] ([UNAVAILABLE]. [128.107.241.166]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:465 (trex/5.5.4); Tue, 12 Jan 2016 14:34:15 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Cullen Jennings In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37D1240D@ESESSMB209.ericsson.se> Date: Tue, 12 Jan 2016 12:34:12 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5D256406-8FD4-451A-A614-E62599FD0838@iii.ca> References: <7594FB04B1934943A5C02806D1A2204B37CC9AF8@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37D1020D@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37D11DAE@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37D1240D@ESESSMB209.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP: Usage of a=rtcp attribute 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: Tue, 12 Jan 2016 19:34:17 -0000 Having the attribute indicates that the device is capable of rtcp on a = port other than the rtp+1 port=20 > On Jan 11, 2016, at 9:12 AM, Christer Holmberg = wrote: >=20 > Hi, >=20 > If we put it in 5245bis I assume JSEP (and trickle ICE) would have to = reference 5245bis. Currently I think both of those specs reference 5245, = but I may be wrong. >=20 > It can be discussed whether it's a change or clarification. 5245 says = that the RTCP candidate shall be encoded using the rtcp attribute - but = if you are doing trickle there is no candidate to encode. >=20 > Regards, >=20 > Christer >=20 > Sent from my Windows Phone > From: Roman Shpount > Sent: =E2=80=8E11/=E2=80=8E01/=E2=80=8E2016 17:42 > To: Christer Holmberg > Cc: Justin Uberti; rtcweb@ietf.org > Subject: Re: [rtcweb] JSEP: Usage of a=3Drtcp attribute >=20 > On Mon, Jan 11, 2016 at 7:35 AM, Christer Holmberg = wrote: > I think we could clarify that the attribute is used only if there is a = real port, and if something is to be sent. >=20 >=20 > This most likely be a change to RFC 5245 not a clarification. It can = definitely be proposed for RFC 5245 bis to ice working group. > _____________ > Roman Shpount > =20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Tue Jan 12 11:37:47 2016 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 565291A86FE for ; Tue, 12 Jan 2016 11:37:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 mpNpVfvszg_Y for ; Tue, 12 Jan 2016 11:37:44 -0800 (PST) Received: from smtp89.iad3a.emailsrvr.com (smtp89.iad3a.emailsrvr.com [173.203.187.89]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A08B1A020A for ; Tue, 12 Jan 2016 11:37:44 -0800 (PST) Received: from smtp28.relay.iad3a.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp28.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 97BCE380372; Tue, 12 Jan 2016 14:37:43 -0500 (EST) X-Auth-ID: fluffy@iii.ca Received: by smtp28.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id DEACB3802C5; Tue, 12 Jan 2016 14:37:42 -0500 (EST) X-Sender-Id: fluffy@iii.ca Received: from [192.168.4.100] ([UNAVAILABLE]. [128.107.241.166]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:465 (trex/5.5.4); Tue, 12 Jan 2016 14:37:43 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Cullen Jennings In-Reply-To: Date: Tue, 12 Jan 2016 12:37:41 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <20F7D3C2-C721-4C86-9004-929E01F4362A@iii.ca> References: <5660B824.7010807@goodadvice.pages.de> <5661CD94.2070209@goodadvice.pages.de> To: "rtcweb@ietf.org" X-Mailer: Apple Mail (2.3112) Archived-At: Subject: Re: [rtcweb] JSEP: why is iceCandidatePoolSize an integer? 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: Tue, 12 Jan 2016 19:37:46 -0000 +1 I think that most people that want to use the pre-gather can make a = reasonable guess of how many candidates they need to get "quickly" (to = get the main call up). If it takes a bit longer for all the variable = things such as thumb nails, that does not impact the UX in the same way. > On Jan 10, 2016, at 10:23 AM, Eric Rescorla wrote: >=20 > I agree with Justin. Remember that this is an optimization and it only = impacts > the *timing* of the delivery of the candidates. If we get to the point = where w > find that this wasn't enough control, we should be able deal with that = later i > a backward compatible way. >=20 > -Ekr >=20 >=20 > On Fri, Jan 8, 2016 at 5:22 PM, Justin Uberti = wrote: > [late to the party] >=20 > I'd be reluctant to add any more complexity to the operation of the = candidate pool - as Martin points out, it is already quite complex. >=20 > If you don't want to pregather all types of candidates, just don't use = it. >=20 >=20 >=20 > On Sat, Dec 5, 2015 at 1:40 AM, Martin Thomson = wrote: > On 5 December 2015 at 04:29, Philipp Hancke = wrote: > > But if this is about components, how can the application make a = decision > > whether to pre-gather and hold on to stun or relay candidates (which > > consumes resources)? >=20 > The application might be able to defer the gathering of candidates via > relays (I don't think that STUN is a real resource concern) by only > providing the relays as stun URIs, or not providing them at all, then > updating the iceServers with setConfiguration. >=20 > I don't know if this is something that would work, we'd have to spec = that. >=20 > I'm actually beginning to question the utility of the pre-warming > thing. Maybe it's a performance gain, but it's certainly quite > complex. >=20 > >> No, this counts components. > > > > > > Calling it iceCandidatePoolSize in the w3c spec seems odd to me then = ;-) >=20 > Yeah, I'm sure that - given it's current level of interoperability > (i.e., zero) - the working group might be receptive to suggestions of > a more accurate name. >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Tue Jan 12 11:56:03 2016 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 711681A87DF for ; Tue, 12 Jan 2016 11:56:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.701 X-Spam-Level: X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_16=0.6, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 f5wEMMoajZzm for ; Tue, 12 Jan 2016 11:56:00 -0800 (PST) Received: from smtp81.iad3a.emailsrvr.com (smtp81.iad3a.emailsrvr.com [173.203.187.81]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BDF81A87A2 for ; Tue, 12 Jan 2016 11:56:00 -0800 (PST) Received: from smtp3.relay.iad3a.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp3.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 892BC30063E; Tue, 12 Jan 2016 14:55:59 -0500 (EST) X-Auth-ID: fluffy@iii.ca Received: by smtp3.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 04E863005E7; Tue, 12 Jan 2016 14:55:58 -0500 (EST) X-Sender-Id: fluffy@iii.ca Received: from [192.168.4.100] ([UNAVAILABLE]. [128.107.241.166]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:465 (trex/5.5.4); Tue, 12 Jan 2016 14:55:59 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Cullen Jennings In-Reply-To: Date: Tue, 12 Jan 2016 12:55:57 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <721B3FCB-31A2-447C-94B7-06466DE5AB39@iii.ca> References: To: Bernard Aboba X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP: "VoiceActivityDetection" option and cient-mixer "vad" extension 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: Tue, 12 Jan 2016 19:56:02 -0000 Bernard,=20 Two things.... To answer your questions ... I think the controll of the V bit in = rfc6464 is totally indepneded of this VoiceActivityDetection option in = JS.=20 We probably need a PR for jsep to clarify this. The key thing to me is = that if the VoiceActivityDetection is set to false by the JS, the = browser MUST NOT do silence suppressions but must send all the audio for = all packets like we would need for cases such as an E911 call or = detecting modem, fax, other tones etc. I think = file:///Volumes/Main2/fluffy/src/drafts/jsep/draft-ietf-rtcweb-jsep.html#r= fc.section.5.2.3.4 could be clearer about that. That has nothing to do = with the=20 On the setting of the rfc6464 signaling for v bit, It seems to me the = browser should always offer that and honor whatever is negotiated. I = don't think the VoiceActivityDetection should effect this and the JS can = munch the SDP to controls what happens if it wants.=20 > On Jan 7, 2016, at 8:37 AM, Bernard Aboba = wrote: >=20 > JSEP Section 5.2.3.4 discusses the implications of the = "VoiceActivityDetection" option for the offer.=20 >=20 > One thing that is not covered is whether the "VoiceActivityDetection" = option determines whether the client-mixer "vad" extension is set to = "on" or "off". =20 >=20 > For example, I believe that the W3C WEBRTC WG determined that the = client-mixer extension (support for which is required in RTP-Usage) = should always be advertised in the offer. RFC 6464 Section 4 gives an = example of the a=3Dextmap line:=20 >=20 > a=3Dextmap:6 urn:ietf:params:rtp-hdrext:ssrc-audio-level vad=3Don >=20 > So, my question is whether "vad=3Don" or "vad=3Doff" is determined by = the "VoiceActivityDetection" option, or if not, whether there is a = setting (e.g. "vad=3Don") that is always present in the offer.=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Tue Jan 12 12:25:12 2016 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 AAA0F1A8886 for ; Tue, 12 Jan 2016 12:25:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.678 X-Spam-Level: X-Spam-Status: No, score=-0.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, SPF_PASS=-0.001] autolearn=no 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 JG7iU1z3XI5V for ; Tue, 12 Jan 2016 12:25:08 -0800 (PST) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38DC71A8885 for ; Tue, 12 Jan 2016 12:25:08 -0800 (PST) Received: by mail-ig0-x229.google.com with SMTP id z14so152587038igp.0 for ; Tue, 12 Jan 2016 12:25:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ZKb7magnYQqbB8A1YEBQEkCf4dmSWNTdEnhLhsFSdBU=; b=Ow+ls496l8SYorx3bn02uYncdceD1XwFtHXLV1spyjV/+hfi86smyPg99mtWEwjkD/ /TrTTGgxnEgcZjNTvAGFRHeBeT5ee7duNVVXU6Lico8fjHREoyCz/9O+6Q3GqDp7rkt6 P4xR0XETMZZ9bLOft13toBlFiyhz3FOoNmmsqGbc9o2ZGYOd6WMfjNCTSVGACJnNYC0z XRpaljgdXbxYjatXC/YWSD6YobPfGHiBDjHSfiEhgo+ySHyNzHTvkoVQ+GT2VNK4LXZG nXQtOVJn7F4rnCEMVzfJYCuQ+Ecl2pX/VRDFFRjQflOJ9fbBj9Q5FP4gj2hIEQD/xsg7 IzpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ZKb7magnYQqbB8A1YEBQEkCf4dmSWNTdEnhLhsFSdBU=; b=CW0/Bp1jL5oDAPcM/0NN09wWXi+fERySBFeT9fnvXADicjTDEOpm+VQG4AhVI2b1hY greHUJ22DVEDzd/ri4jlvmYMm94HaHD3HZAd/BqFaoOEuIB5kWPmhKPgh0uARpgwK36V KgwHhaDYM9qloiZOfQOgHUvzVPnTK3E/LHG7s3xnlYeHY3OfIZrUwrB/QMQ0nV7uGk8T 3UivEfIrJ5Yt+z4gXVMFQyQQHlzqM9wxU46NrbpTzCsOwrluRy1Xm291W5Xqpy7S4RbF j1YwUFQjV45d/LacfNJRCNLRuGtsT8RE2p+Lhh6e5/40QG3RfQKr0USuAzRzhGxvljsW Uc3A== X-Gm-Message-State: ALoCoQnjVTMuC5N6wK4jbzeo1kP20OY8NAi3HbxU3cu+UP4efQSmmj40TP+gBiHZ7LZ0hdfiFiRlIZYyIBCrNHPU2vv/Z2wxdQ== X-Received: by 10.50.129.97 with SMTP id nv1mr21158739igb.0.1452630307541; Tue, 12 Jan 2016 12:25:07 -0800 (PST) Received: from mail-io0-f174.google.com (mail-io0-f174.google.com. [209.85.223.174]) by smtp.gmail.com with ESMTPSA id rq3sm36445igb.15.2016.01.12.12.25.05 for (version=TLSv1/SSLv3 cipher=OTHER); Tue, 12 Jan 2016 12:25:05 -0800 (PST) Received: by mail-io0-f174.google.com with SMTP id 77so365074641ioc.2 for ; Tue, 12 Jan 2016 12:25:05 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.107.14.72 with SMTP id 69mr89426031ioo.145.1452630305353; Tue, 12 Jan 2016 12:25:05 -0800 (PST) Received: by 10.36.105.15 with HTTP; Tue, 12 Jan 2016 12:25:05 -0800 (PST) In-Reply-To: <5D256406-8FD4-451A-A614-E62599FD0838@iii.ca> References: <7594FB04B1934943A5C02806D1A2204B37CC9AF8@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37D1020D@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37D11DAE@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37D1240D@ESESSMB209.ericsson.se> <5D256406-8FD4-451A-A614-E62599FD0838@iii.ca> Date: Tue, 12 Jan 2016 15:25:05 -0500 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: Cullen Jennings Content-Type: multipart/alternative; boundary=001a113fcf0e573825052928d934 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP: Usage of a=rtcp attribute 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: Tue, 12 Jan 2016 20:25:09 -0000 --001a113fcf0e573825052928d934 Content-Type: text/plain; charset=UTF-8 On Tue, Jan 12, 2016 at 2:34 PM, Cullen Jennings wrote: > > Having the attribute indicates that the device is capable of rtcp on a > port other than the rtp+1 port > First of all, according to RFC 5245 rtcp SDP attribute must be present even if RTCP is being received on rtp+1 port. Furthermore, RFC 5245 also specifies that if RTCP is not being used, b=RS:0 and b=RR:0 must be present. If most of the cases (especially if TURN candidates are default, which is the recommended behavior), default ICE candidate for RTCP is rtp+1 port, which makes it SDP rtcp attribute totally redundant. More importantly, as far as initial offer for trickle ICE is concerned, I do no think there are any use cases which would be negatively affected by SDP rtcp attribute not being present in the initial offer with no candidates. We can argue regarding RFC 5245 usage of rtcp attribute, or we can get trickle ICE to update RFC 5245 (which it does anyway) and specify that initial offer with no candidates MUST NOT include SDP rtcp attribute unless rtcp-mux is required. _____________ Roman Shpount --001a113fcf0e573825052928d934 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Jan 12, 2016 at 2:34 PM, Cullen Jennings <= ;fluffy@iii.ca> wrote:
Having the attribute indicates that the device is capable of rtcp on a port= other than the rtp+1 port

First of all, acc= ording to =C2=A0RFC 5245 rtcp SDP attribute must be present even if RTCP is= being received on=C2=A0=C2=A0rtp+1 port.=C2=A0Furthermore, RFC 5245 also=C2=A0specifies=C2= =A0that if RTCP is not being used,=C2=A0b=3DRS:0 and b=3DRR:0 must be present. If most= of the cases (especially if TURN candidates are default, which is the reco= mmended behavior), default ICE candidate for RTCP is rtp+1 port, which make= s it SDP rtcp attribute totally redundant.

More importantly, as far as initial offer for trickle ICE is concerned, I= do no think there are any use cases which would be negatively affected by = SDP rtcp attribute not being present in the initial offer with no candidate= s. We can argue regarding RFC 5245 usage of rtcp attribute, or we can get t= rickle ICE to update RFC 5245 (which it does anyway) and specify that initi= al offer with no candidates MUST NOT include SDP rtcp attribute unless rtcp= -mux is required.
____= _________
Roman Shpount
=C2=A0
--001a113fcf0e573825052928d934-- From nobody Tue Jan 12 12:40:39 2016 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 457871A88A7 for ; Tue, 12 Jan 2016 12:40:37 -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, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-2.3] 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 GJq30aadCJj9 for ; Tue, 12 Jan 2016 12:40:35 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CB851A88A4 for ; Tue, 12 Jan 2016 12:40:34 -0800 (PST) X-AuditID: c1b4fb3a-f79df6d0000013b1-7e-569564c0fc71 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.183.48]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 6E.0F.05041.0C465965; Tue, 12 Jan 2016 21:40:32 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.76]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0248.002; Tue, 12 Jan 2016 21:40:32 +0100 From: Christer Holmberg To: Cullen Jennings Thread-Topic: [rtcweb] JSEP: Usage of a=rtcp attribute Thread-Index: AdE1tk5+GgxwzrGpR6mZvYz9J4lNJQUwCquAAAopOu8AU4wngAAfsOHAAASQdoAAAyCBGgA3P7gAAARZBnA= Date: Tue, 12 Jan 2016 20:40:31 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37D15222@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37CC9AF8@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37D1020D@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37D11DAE@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37D1240D@ESESSMB209.ericsson.se> <5D256406-8FD4-451A-A614-E62599FD0838@iii.ca> In-Reply-To: <5D256406-8FD4-451A-A614-E62599FD0838@iii.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupjkeLIzCtJLcpLzFFi42KZGbHdQPdAytQwg1eT1Cw+rP/BaDHjwlRm i7X/2tkdmD2WLPnJ5HH5/EdGj1tTCgKYo7hsUlJzMstSi/TtErgyln0/xFTwRLBizf2NTA2M KwS7GDk5JARMJOb1bmGFsMUkLtxbz9bFyMUhJHCYUWL5hWUsEM5iRon/a44CZTg42AQsJLr/ aYM0iAgoS5zbcZcZxGYW8JK4caGXDcQWFjCVOPZ3EhtEjZnEvccXmCDsJInT7RdZQMawCKhK 3N4sChLmFfCV+D/5MSvEqnksEucbW5hAajgFrCRenZQEqWEEuu37qTVMEKvEJW49mc8EcbOA xJI955khbFGJl4//Qf2iJLFi+yVGkDHMApoS63fpQ7QqSkzpfsgOsVZQ4uTMJywTGMVmIZk6 C6FjFpKOWUg6FjCyrGIULU4tLs5NNzLSSy3KTC4uzs/Ty0st2cQIjKWDW35b7WA8+NzxEKMA B6MSD+8H4ylhQqyJZcWVuYcYJTiYlUR4uUOnhgnxpiRWVqUW5ccXleakFh9ilOZgURLnTZJp DBMSSE8sSc1OTS1ILYLJMnFwSjUwykz+w/2Y+3vMf82X4Xl9Pw4IL5nztCXk0a5djR7ruCZP nF17UuuC/4letZb9t55WNHd+5vi/M00toGndJs1NK7fyNPzbzNNSUaZvYnD03cfpmp9er2Vo qzviPvvSLNHvuscXTKifV3WCfYXG4vnLFlxwMFzSFVdkr/Tks3KUosvH2n1RrL+EVyqxFGck GmoxFxUnAgAUiFyCoQIAAA== Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP: Usage of a=rtcp attribute 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: Tue, 12 Jan 2016 20:40:37 -0000 SGksDQoNCj5IYXZpbmcgdGhlIGF0dHJpYnV0ZSBpbmRpY2F0ZXMgdGhhdCB0aGUgZGV2aWNlIGlz IGNhcGFibGUgb2YgcnRjcCBvbiBhIHBvcnQgb3RoZXIgdGhhbiB0aGUgcnRwKzEgcG9ydCANCg0K QW55IHdoeSBpcyB0aGF0IHVzZWZ1bCBpbmZvcm1hdGlvbj8gSXQgZG9lc24ndCBzYXkgYW55dGhp bmcgYWJvdXQgV0hJQ0ggb3RoZXIgcG9ydChzKS4NCg0KQW5kLCBvbmNlIHRoZSBkZXZpY2Ugc3Rh cnRzIHByb3ZpZGluZyB0aGUgY2FuZGlkYXRlcywgdGhlIHJlbW90ZSBlbmRwb2ludCB3aWxsIGZp Z3VyZSBvdXQgKGZyb20gdGhlIGhvc3QgY2FuZGlkYXRlKSBvbiB3aGljaCBsb2NhbCBwb3J0cyB0 aGUgZGV2aWNlIGNhbiByZWNlaXZlIFJUQ1AuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg0K PiBPbiBKYW4gMTEsIDIwMTYsIGF0IDk6MTIgQU0sIENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rl ci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+IHdyb3RlOg0KPiANCj4gSGksDQo+IA0KPiBJZiB3ZSBw dXQgaXQgaW4gNTI0NWJpcyBJIGFzc3VtZSBKU0VQIChhbmQgdHJpY2tsZSBJQ0UpIHdvdWxkIGhh dmUgdG8gcmVmZXJlbmNlIDUyNDViaXMuIEN1cnJlbnRseSBJIHRoaW5rIGJvdGggb2YgdGhvc2Ug c3BlY3MgcmVmZXJlbmNlIDUyNDUsIGJ1dCBJIG1heSBiZSB3cm9uZy4NCj4gDQo+IEl0IGNhbiBi ZSBkaXNjdXNzZWQgd2hldGhlciBpdCdzIGEgY2hhbmdlIG9yIGNsYXJpZmljYXRpb24uIDUyNDUg c2F5cyB0aGF0IHRoZSBSVENQIGNhbmRpZGF0ZSBzaGFsbCBiZSBlbmNvZGVkIHVzaW5nIHRoZSBy dGNwIGF0dHJpYnV0ZSAtIGJ1dCBpZiB5b3UgYXJlIGRvaW5nIHRyaWNrbGUgdGhlcmUgaXMgbm8g Y2FuZGlkYXRlIHRvIGVuY29kZS4NCj4gDQo+IFJlZ2FyZHMsDQo+IA0KPiBDaHJpc3Rlcg0KPiAN Cj4gU2VudCBmcm9tIG15IFdpbmRvd3MgUGhvbmUNCj4gRnJvbTogUm9tYW4gU2hwb3VudA0KPiBT ZW50OiDigI4xMS/igI4wMS/igI4yMDE2IDE3OjQyDQo+IFRvOiBDaHJpc3RlciBIb2xtYmVyZw0K PiBDYzogSnVzdGluIFViZXJ0aTsgcnRjd2ViQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbcnRj d2ViXSBKU0VQOiBVc2FnZSBvZiBhPXJ0Y3AgYXR0cmlidXRlDQo+IA0KPiBPbiBNb24sIEphbiAx MSwgMjAxNiBhdCA3OjM1IEFNLCBDaHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJlcmdA ZXJpY3Nzb24uY29tPiB3cm90ZToNCj4gSSB0aGluayB3ZSBjb3VsZCBjbGFyaWZ5IHRoYXQgdGhl IGF0dHJpYnV0ZSBpcyB1c2VkIG9ubHkgaWYgdGhlcmUgaXMgYSByZWFsIHBvcnQsIGFuZCBpZiBz b21ldGhpbmcgaXMgdG8gYmUgc2VudC4NCj4gDQo+IA0KPiBUaGlzIG1vc3QgbGlrZWx5IGJlIGEg Y2hhbmdlIHRvIFJGQyA1MjQ1IG5vdCBhIGNsYXJpZmljYXRpb24uIEl0IGNhbiBkZWZpbml0ZWx5 IGJlIHByb3Bvc2VkIGZvciBSRkMgNTI0NSBiaXMgdG8gaWNlIHdvcmtpbmcgZ3JvdXAuDQo+IF9f X19fX19fX19fX18NCj4gUm9tYW4gU2hwb3VudA0KPiAgDQo+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IHJ0Y3dlYiBtYWlsaW5nIGxpc3QNCj4gcnRj d2ViQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRj d2ViDQoNCg== From nobody Wed Jan 20 14:41:36 2016 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 64E5D1B29EF for ; Wed, 20 Jan 2016 14:41:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 Br_3964ImM_C for ; Wed, 20 Jan 2016 14:41:32 -0800 (PST) Received: from mail-qg0-x22c.google.com (mail-qg0-x22c.google.com [IPv6:2607:f8b0:400d:c04::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C00171B29EC for ; Wed, 20 Jan 2016 14:41:32 -0800 (PST) Received: by mail-qg0-x22c.google.com with SMTP id o11so18556868qge.2 for ; Wed, 20 Jan 2016 14:41:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-type:content-transfer-encoding:date:subject:to :message-id:mime-version; bh=8UMNOy2LTwcA+lE1sy9JIyA2JNPN+vPcwP81IJ5nRi0=; b=CcoqDiq2DTfzXFJTvGwhsG2hgFnd4zwHYKjQKJO/8ym+fFrTFrWPsVjvHNzLw2v3U3 h/6GNuB+SlesKXYV7RiDumNSUO+aXQIToxvgIL57Jv2LW8YSQC3ythE6D9BI1XQ7N4ss EvsvPy4VHF73yx1tBKstlJ19XlK5FZMtb7Jdk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-type:content-transfer-encoding:date :subject:to:message-id:mime-version; bh=8UMNOy2LTwcA+lE1sy9JIyA2JNPN+vPcwP81IJ5nRi0=; b=NVdmxdIgCW5xp0W851S6srcS3obZTQOke+CG+Sg4q2e5MrBAwYLtiPo7QOiO+1Vns2 M0wr66+D99soPzpypXO4w98pKl2wEPfqeQqihfpL90emHKqhqNTovHn4mubuwZUZ19ym QaYY1t9Skb4G7nnMcVTfTUTOQZt8i4N1zzy+6pO2UQ8vDW2zFIxPlDNCYwOC5isSG3zW QjNot0clR1UqVlm+kwVw02XQRpK4J/ZaEmr7rthbcyRSSOUx9OCg2WsqHDQ3vrdvGto0 hlrGjeV82krdO/1i3xyAtNH9mf8JFKX2iN6yYihhqbWAE/yPB/3xI5tMqrml469VqOXx 2a3Q== X-Gm-Message-State: ALoCoQlZ3kxMJb+I1/3/cN4Gw5jQXkBxYRGgObnvOmqsbbjln8qWoFmo53tsLbBj5BaZBGTN94LciI+wKgaRc2bBCeHNxN/iLw== X-Received: by 10.140.91.66 with SMTP id y60mr47998751qgd.20.1453329691910; Wed, 20 Jan 2016 14:41:31 -0800 (PST) Received: from [172.16.0.112] ([96.231.217.211]) by smtp.gmail.com with ESMTPSA id b6sm15300585qkh.12.2016.01.20.14.41.31 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 20 Jan 2016 14:41:31 -0800 (PST) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Wed, 20 Jan 2016 17:41:30 -0500 To: rtcweb@ietf.org Message-Id: Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) X-Mailer: Apple Mail (2.3112) Archived-At: Subject: [rtcweb] Call for WG adoption: draft-shieh-rtcweb-ip-handling 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: Wed, 20 Jan 2016 22:41:34 -0000 All, In Yokohama, we reviewed the "IP address leakage=E2=80=9D issues and the = sense of the room was that we should document this in its own document. = So to get that done =E2=80=A6 please respond to indicate whether you = support adoption of = https://datatracker.ietf.org/doc/draft-shieh-rtcweb-ip-handling/ as a = working group work item and whether you will participate in the = discussion. If you are opposed to this draft becoming a WG document, = please say so (and say why). Please have your response in by February = 4th. Thanks in advance! T/C/S= From nobody Wed Jan 20 14:41:44 2016 Return-Path: X-Original-To: rtcweb@ietf.org Delivered-To: rtcweb@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 53A301B29EA; Wed, 20 Jan 2016 14:41:42 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , X-Test-IDTracker: no X-IETF-IDTracker: 6.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160120224142.8171.91614.idtracker@ietfa.amsl.com> Date: Wed, 20 Jan 2016 14:41:42 -0800 Archived-At: Subject: [rtcweb] The RTCWEB WG has placed draft-shieh-rtcweb-ip-handling in state "Call For Adoption By WG Issued" X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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: Wed, 20 Jan 2016 22:41:42 -0000 The RTCWEB WG has placed draft-shieh-rtcweb-ip-handling in state Call For Adoption By WG Issued (entered by spt) The document is available at https://datatracker.ietf.org/doc/draft-shieh-rtcweb-ip-handling/ From nobody Wed Jan 20 14:52:15 2016 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 17FBD1B2A4A for ; Wed, 20 Jan 2016 14:52:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 UjFktbZ1yXYX for ; Wed, 20 Jan 2016 14:52:12 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BA621B2A45 for ; Wed, 20 Jan 2016 14:52:12 -0800 (PST) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u0KMqAiq016849 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 20 Jan 2016 16:52:11 -0600 (CST) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local To: Sean Turner , rtcweb@ietf.org References: From: Adam Roach Message-ID: <56A00F99.5060402@nostrum.com> Date: Wed, 20 Jan 2016 16:52:09 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [rtcweb] Call for WG adoption: draft-shieh-rtcweb-ip-handling 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: Wed, 20 Jan 2016 22:52:14 -0000 I support adoption of this document as part of the "Send Security Solution (draft-ietf-rtcweb-security-arch) to IESG for publication as Proposed Standard" milestone, although would suggest revising the milestone name. I plan to participate in the discussion, and hope to have feedback on the current version to the mailing list by the end of next week. /a On 1/20/16 16:41, Sean Turner wrote: > All, > > In Yokohama, we reviewed the "IP address leakage” issues and the sense of the room was that we should document this in its own document. So to get that done … please respond to indicate whether you support adoption of https://datatracker.ietf.org/doc/draft-shieh-rtcweb-ip-handling/ as a working group work item and whether you will participate in the discussion. If you are opposed to this draft becoming a WG document, please say so (and say why). Please have your response in by February 4th. > > Thanks in advance! > T/C/S > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Thu Jan 21 08:39:43 2016 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 05BCB1A9056 for ; Thu, 21 Jan 2016 08:39:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 ZOhc3mDSLFiG for ; Thu, 21 Jan 2016 08:39:39 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E7451A9026 for ; Thu, 21 Jan 2016 08:39:37 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2BCCQA+CaFW/yYyC4coNhkBAQEBDwEBAQGCPiErUm0GhTSDHbALghMBDYFZCRgBCIVuAoE9OBQBAQEBAQEBfwsJBQEBgg6CFgEBAQEDEgsQXgEVBAQBAQsdORQJCQEEEwgah3kBDZ41hRKaDAEBAQEGAQEBAQEBARmGOok/LQmCE0sYgQ8FlnUBhUWJb0qDeoMbDIUwjjweAQFCgU2CGWoBAQGGJAF7AQEB X-IPAS-Result: A2BCCQA+CaFW/yYyC4coNhkBAQEBDwEBAQGCPiErUm0GhTSDHbALghMBDYFZCRgBCIVuAoE9OBQBAQEBAQEBfwsJBQEBgg6CFgEBAQEDEgsQXgEVBAQBAQsdORQJCQEEEwgah3kBDZ41hRKaDAEBAQEGAQEBAQEBARmGOok/LQmCE0sYgQ8FlnUBhUWJb0qDeoMbDIUwjjweAQFCgU2CGWoBAQGGJAF7AQEB X-IronPort-AV: E=Sophos;i="5.22,326,1449550800"; d="scan'208,217";a="139504335" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by de307622-de-outbound.net.avaya.com with ESMTP; 21 Jan 2016 11:39:35 -0500 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC04.global.avaya.com) ([135.64.58.14]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/AES256-SHA; 21 Jan 2016 11:39:34 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC04.global.avaya.com ([135.64.58.14]) with mapi id 14.03.0174.001; Thu, 21 Jan 2016 17:39:32 +0100 From: "Romascanu, Dan (Dan)" To: "rtcweb@ietf.org" Thread-Topic: (xrblock) WGLC for draft-ietf-xrblock-rtcweb-rtcp-xr-metrics-02.txt Thread-Index: AdFUakvbEXMM5zb/SGi9n4vJWqqbVQ== Date: Thu, 21 Jan 2016 16:39:32 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA6BEF3155@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.47] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA6BEF3155AZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: Subject: [rtcweb] (xrblock) WGLC for draft-ietf-xrblock-rtcweb-rtcp-xr-metrics-02.txt 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: Thu, 21 Jan 2016 16:39:42 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA6BEF3155AZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The xrblock WG sent to LC the Internet-Draft 'Considerations for Selecting = RTCP Extended Report (XR) Metrics for the WebRTC Statistics API'. Comments or questions are welcome - best on xrblock@ietf.org. Thanks and Regards, Dan From: xrblock [mailto:xrblock-bounces@ietf.org] On Behalf Of Shida Schubert Sent: Wednesday, January 20, 2016 6:32 AM To: xrblock Subject: [xrblock] WGLC for draft-ietf-xrblock-rtcweb-rtcp-xr-metrics All; This message starts a Working Group Last Call for the draft-ietf-xrblock-rt= cweb-rtcp-xr-metrics-02.txt. http://tools.ietf.org/id/draft-ietf-xrblock-rtcweb-rtcp-xr-metrics-02.txt Even if you have no questions, comments or concern, if you have read the dr= aft and agree that it's ready for submission to IESG as a Standard Track, p= lease send a message to the list indicating this. Obviously if you have any issues or questions please submit it to the list,= if you are highlighting issues suggestions to fix the issues is always hel= pful. The Working Group Last Call will end on February 4th. Shida As co-chair --_000_9904FB1B0159DA42B0B887B7FA8119CA6BEF3155AZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 
The xrblock WG sent to LC the Internet-Draft ‘Co=
nsiderations for Selecting RTCP Extended Report (XR) Metrics for the WebRTC=
 Statistics API’. 
 
Comments or questions are welcome – best on xrblock@ietf.org. 

 


Thanks and Regards,


 


Dan


 


 


 


From: xrblock =
[mailto:xrblock-bounces@ietf.or=
g]
On Behalf Of Shida Schubert

Sent: Wednesday, January 20, 2016 6:32 AM

To: xrblock

Subject: [xrblock] WGLC for draft-ietf-xrblock-rtcweb-rtcp-xr-metric=
s


 


All;


 


This message starts a Working Group Last Call for th=
e draft-ietf-xrblock-rtcweb-rtcp-xr-metrics-02.txt. 

 


http://tools.ietf.org/id/draft-ietf-xrblock-rtcweb-rtcp-xr-metrics-02=
.txt


 


Even if you have no questions, comments or concern, =
if you have read the draft and agree that it’s ready for submission t=
o IESG as a Standard Track, please send a message to the list indicating th=
is. 


 


Obviously if you have any issues or questions please=
 submit it to the list, if you are highlighting issues suggestions to fix t=
he issues is always helpful.


 


The Working Group Last Call will end on February 4th=
. 


 


Shida


As co-chair


 
--_000_9904FB1B0159DA42B0B887B7FA8119CA6BEF3155AZFFEXMB04globa_-- From nobody Thu Jan 21 12:07:57 2016 Return-Path: X-Original-To: rtcweb@ietf.org Delivered-To: rtcweb@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DB661A90A0; Thu, 21 Jan 2016 12:07:56 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160121200756.26839.58819.idtracker@ietfa.amsl.com> Date: Thu, 21 Jan 2016 12:07:56 -0800 Archived-At: Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-overview-15.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 21 Jan 2016 20:07:56 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Real-Time Communication in WEB-browsers Working Group of the IETF. Title : Overview: Real Time Protocols for Browser-based Applications Author : Harald T. Alvestrand Filename : draft-ietf-rtcweb-overview-15.txt Pages : 22 Date : 2016-01-21 Abstract: This document gives an overview and context of a protocol suite intended for use with real-time applications that can be deployed in browsers - "real time communication on the Web". It intends to serve as a starting and coordination point to make sure all the parts that are needed to achieve this goal are findable, and that the parts that belong in the Internet protocol suite are fully specified and on the right publication track. This document is an Applicability Statement - it does not itself specify any protocol, but specifies which other specifications WebRTC compliant implementations are supposed to follow. This document is a work item of the RTCWEB working group. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-overview/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-rtcweb-overview-15 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-overview-15 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jan 21 12:24:36 2016 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 E80731A90DB for ; Thu, 21 Jan 2016 12:24:35 -0800 (PST) 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, RP_MATCHES_RCVD=-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 BMcfZEKnqk4v for ; Thu, 21 Jan 2016 12:24:33 -0800 (PST) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id AE5BD1A90DD for ; Thu, 21 Jan 2016 12:24:33 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id F34997C6788 for ; Thu, 21 Jan 2016 21:24:32 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qLPu--_3Lp22 for ; Thu, 21 Jan 2016 21:24:32 +0100 (CET) Received: from [IPv6:2001:470:de0a:1:ad9f:e18a:60c4:3865] (unknown [IPv6:2001:470:de0a:1:ad9f:e18a:60c4:3865]) by mork.alvestrand.no (Postfix) with ESMTPSA id 3F4DF7C6786 for ; Thu, 21 Jan 2016 21:24:32 +0100 (CET) To: rtcweb@ietf.org References: From: Harald Alvestrand Message-ID: <56A13E7F.2020808@alvestrand.no> Date: Thu, 21 Jan 2016 21:24:31 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [rtcweb] Call for WG adoption: draft-shieh-rtcweb-ip-handling 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: Thu, 21 Jan 2016 20:24:36 -0000 I support adoption of this draft as the a working group item. Den 20. jan. 2016 23:41, skrev Sean Turner: > All, > > In Yokohama, we reviewed the "IP address leakage” issues and the sense of the room was that we should document this in its own document. So to get that done … please respond to indicate whether you support adoption of https://datatracker.ietf.org/doc/draft-shieh-rtcweb-ip-handling/ as a working group work item and whether you will participate in the discussion. If you are opposed to this draft becoming a WG document, please say so (and say why). Please have your response in by February 4th. > > Thanks in advance! > T/C/S > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From nobody Thu Jan 21 12:25:55 2016 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 4B4FD1A90DE for ; Thu, 21 Jan 2016 12:25:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 CLLy8aes8o7L for ; Thu, 21 Jan 2016 12:25:52 -0800 (PST) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id C248F1A90DD for ; Thu, 21 Jan 2016 12:25:51 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 0C4BD7C6788 for ; Thu, 21 Jan 2016 21:25:49 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1g79n5I7p0Pv for ; Thu, 21 Jan 2016 21:25:48 +0100 (CET) Received: from [IPv6:2001:470:de0a:1:ad9f:e18a:60c4:3865] (unknown [IPv6:2001:470:de0a:1:ad9f:e18a:60c4:3865]) by mork.alvestrand.no (Postfix) with ESMTPSA id DAC207C6786 for ; Thu, 21 Jan 2016 21:25:47 +0100 (CET) To: rtcweb@ietf.org References: <20160121200756.26839.58819.idtracker@ietfa.amsl.com> From: Harald Alvestrand Message-ID: <56A13ECB.8030209@alvestrand.no> Date: Thu, 21 Jan 2016 21:25:47 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <20160121200756.26839.58819.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-overview-15.txt 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: Thu, 21 Jan 2016 20:25:54 -0000 This is a keepalive update only. No issues have been filed on github or mentioned where they stuck in my memory, so I have merely changed the dates (and one reference). Harald Den 21. jan. 2016 21:07, skrev internet-drafts@ietf.org: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Real-Time Communication in WEB-browsers Working Group of the IETF. > > Title : Overview: Real Time Protocols for Browser-based Applications > Author : Harald T. Alvestrand > Filename : draft-ietf-rtcweb-overview-15.txt > Pages : 22 > Date : 2016-01-21 > > Abstract: > This document gives an overview and context of a protocol suite > intended for use with real-time applications that can be deployed in > browsers - "real time communication on the Web". > > It intends to serve as a starting and coordination point to make sure > all the parts that are needed to achieve this goal are findable, and > that the parts that belong in the Internet protocol suite are fully > specified and on the right publication track. > > This document is an Applicability Statement - it does not itself > specify any protocol, but specifies which other specifications WebRTC > compliant implementations are supposed to follow. > > This document is a work item of the RTCWEB working group. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-overview/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-rtcweb-overview-15 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-overview-15 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From nobody Thu Jan 21 12:45:32 2016 Return-Path: X-Original-To: rtcweb@ietf.org Delivered-To: rtcweb@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B71C1A9130; Thu, 21 Jan 2016 12:45:32 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160121204532.22206.28732.idtracker@ietfa.amsl.com> Date: Thu, 21 Jan 2016 12:45:32 -0800 Archived-At: Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-gateways-02.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 21 Jan 2016 20:45:32 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Real-Time Communication in WEB-browsers Working Group of the IETF. Title : WebRTC Gateways Authors : Harald Alvestrand Uwe Rauschenbach Filename : draft-ietf-rtcweb-gateways-02.txt Pages : 7 Date : 2016-01-21 Abstract: This document describes interoperability considerations for a class of WebRTC-compatible endpoints called "WebRTC gateways", which interconnect between WebRTC endpoints and devices that are not WebRTC endpoints. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-gateways/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-rtcweb-gateways-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-gateways-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jan 21 12:47:31 2016 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 253591A9131 for ; Thu, 21 Jan 2016 12:47:29 -0800 (PST) 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, RP_MATCHES_RCVD=-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 8xbg2g8qElW0 for ; Thu, 21 Jan 2016 12:47:27 -0800 (PST) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id A97381A912A for ; Thu, 21 Jan 2016 12:47:27 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id EFC3F7C6788 for ; Thu, 21 Jan 2016 21:47:26 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YWbwrG8f12fP for ; Thu, 21 Jan 2016 21:47:26 +0100 (CET) Received: from [IPv6:2001:470:de0a:1:ad9f:e18a:60c4:3865] (unknown [IPv6:2001:470:de0a:1:ad9f:e18a:60c4:3865]) by mork.alvestrand.no (Postfix) with ESMTPSA id 07AC57C6786 for ; Thu, 21 Jan 2016 21:47:25 +0100 (CET) To: rtcweb@ietf.org References: <20160121204532.22206.28732.idtracker@ietfa.amsl.com> From: Harald Alvestrand Message-ID: <56A143DD.2020906@alvestrand.no> Date: Thu, 21 Jan 2016 21:47:25 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <20160121204532.22206.28732.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-gateways-02.txt 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: Thu, 21 Jan 2016 20:47:29 -0000 This, too, is a keepalive. Please file issues in github for desired changes. Den 21. jan. 2016 21:45, skrev internet-drafts@ietf.org: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Real-Time Communication in WEB-browsers Working Group of the IETF. > > Title : WebRTC Gateways > Authors : Harald Alvestrand > Uwe Rauschenbach > Filename : draft-ietf-rtcweb-gateways-02.txt > Pages : 7 > Date : 2016-01-21 > > Abstract: > This document describes interoperability considerations for a class > of WebRTC-compatible endpoints called "WebRTC gateways", which > interconnect between WebRTC endpoints and devices that are not WebRTC > endpoints. > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-gateways/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-rtcweb-gateways-02 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-gateways-02 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From nobody Thu Jan 21 18:49:06 2016 Return-Path: X-Original-To: rtcweb@ietf.org Delivered-To: rtcweb@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E53D1B36AE; Thu, 21 Jan 2016 18:49:03 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160122024903.361.27299.idtracker@ietfa.amsl.com> Date: Thu, 21 Jan 2016 18:49:03 -0800 Archived-At: Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-alpn-02.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 22 Jan 2016 02:49:03 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Real-Time Communication in WEB-browsers Working Group of the IETF. Title : Application Layer Protocol Negotiation for Web Real-Time Communications (WebRTC) Author : Martin Thomson Filename : draft-ietf-rtcweb-alpn-02.txt Pages : 7 Date : 2016-01-21 Abstract: Application Layer Protocol Negotiation (ALPN) labels are defined for use in identifying Web Real-Time Communications (WebRTC) usages of Datagram Transport Layer Security (DTLS). Labels are provided for identifying a session that uses a combination of WebRTC compatible media and data, and for identifying a session requiring confidentiality protection. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-alpn/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-rtcweb-alpn-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-alpn-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jan 25 07:56:35 2016 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 85CCC1B2C8A for ; Mon, 25 Jan 2016 07:56:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 Vysa0kwUPwz0 for ; Mon, 25 Jan 2016 07:56:33 -0800 (PST) Received: from mail-yk0-x229.google.com (mail-yk0-x229.google.com [IPv6:2607:f8b0:4002:c07::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3BE71B2C89 for ; Mon, 25 Jan 2016 07:56:32 -0800 (PST) Received: by mail-yk0-x229.google.com with SMTP id a85so165426661ykb.1 for ; Mon, 25 Jan 2016 07:56:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=mJVh+mAUj7jZCw7NbxDTAONiCc3tBXrvY54kEgFvmy4=; b=aUpaOTwGNX0qfiDm0Wh9vv8OuL39M0u4gbTjqlmic70r7UDmC24+KaKWpsLiWyMwqx L9rm8omXjzQXSs9CwAdvHgneM6t4nOxyZKliP8l9fT1Kmh4C8j5RB0nZ87AJInRRkquU xsOq7hiHPPdAOpn3fjbV+/yzjlLzlHnELQ58Y= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:content-transfer-encoding:message-id:references:to; bh=mJVh+mAUj7jZCw7NbxDTAONiCc3tBXrvY54kEgFvmy4=; b=V6+LQbdu+JsjmXe18x8J3c1ZdldkSdyGRUoX6BbSZn32mrGiXlqK4wVjqIXvkL7S9l lS8VGzoGA8ztJuR21WZ17zbEn2jMyFEXVi+aTE98jSQukdUv/3767j918ChW7+MOWf28 +48K0BFCUEGxYdWMxHJxM1tUQ37v8uT/l9yiCZSuzAzk7MBbbA7oii+KAJB46qjGrzvL 5S5j/KdnqOtFL00JGd88TzcpgZbIMz5Xcyl8wlDOEHqbFLJ9rQboX5/DntRD7kcxKWZ2 x4numHZVOWnC2iznGiE7oy3JmZ8GUquCQhnpTHGXvHbjXt0J2GT4Y212sBUUICQxfmxp 28xg== X-Gm-Message-State: AG10YOSVQpVTZ6WmQlh56X0y71pZ8xlrURPeHLMMJ4cL7v8RNvCT9gfBaD2zVCON+PjYGw== X-Received: by 10.37.97.5 with SMTP id v5mr9497389ybb.83.1453737392093; Mon, 25 Jan 2016 07:56:32 -0800 (PST) Received: from [172.16.0.112] ([96.231.217.211]) by smtp.gmail.com with ESMTPSA id a5sm4073785ywg.21.2016.01.25.07.56.31 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 25 Jan 2016 07:56:31 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Sean Turner In-Reply-To: <20160122024903.361.27299.idtracker@ietfa.amsl.com> Date: Mon, 25 Jan 2016 10:56:29 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <7DD53C1F-7490-45A8-B593-056A6EFC5D77@sn3rd.com> References: <20160122024903.361.27299.idtracker@ietfa.amsl.com> To: rtcweb@ietf.org X-Mailer: Apple Mail (2.3112) Archived-At: Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-alpn-02.txt 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: Mon, 25 Jan 2016 15:56:34 -0000 Just so that nobody is caught off-guard: The chairs asked Martin to = submit this version so we could get a WGLC going on it. Expect that = call to come out shortly in a separate message. spt > On Jan 21, 2016, at 21:49, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Real-Time Communication in = WEB-browsers Working Group of the IETF. >=20 > Title : Application Layer Protocol Negotiation for = Web Real-Time Communications (WebRTC)=20 > Author : Martin Thomson > Filename : draft-ietf-rtcweb-alpn-02.txt > Pages : 7 > Date : 2016-01-21 >=20 > Abstract: > Application Layer Protocol Negotiation (ALPN) labels are defined for > use in identifying Web Real-Time Communications (WebRTC) usages of > Datagram Transport Layer Security (DTLS). Labels are provided for > identifying a session that uses a combination of WebRTC compatible > media and data, and for identifying a session requiring > confidentiality protection. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-alpn/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-rtcweb-alpn-02 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcweb-alpn-02 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Mon Jan 25 08:19:00 2016 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 AA8511B2CDB for ; Mon, 25 Jan 2016 08:18:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 J_kacg6ROdGA for ; Mon, 25 Jan 2016 08:18:57 -0800 (PST) Received: from mail-yk0-x235.google.com (mail-yk0-x235.google.com [IPv6:2607:f8b0:4002:c07::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2271C1B2CDA for ; Mon, 25 Jan 2016 08:18:57 -0800 (PST) Received: by mail-yk0-x235.google.com with SMTP id v14so166341463ykd.3 for ; Mon, 25 Jan 2016 08:18:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-type:content-transfer-encoding:subject:message-id:date :to:mime-version; bh=4VXzWHWZ0cjw6cJuIUhg69dMiuczfmen6jf6E5H8VgA=; b=MA2V5yVM9K7vl/XwUF5zzy47zm4vDqLr2ZhU4HCuKox19VAJ06I+TzfTS7a+tqiHBk x/ARUe4tmK+Ucwi0uzzO+NcZrUukLw34RF4vrRrXXVlU9pKTZm792FW8vgX17xBNEmQK 5a+CTOOdvS+ZwbGNItciZ8bb6cElSysIO9FL4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-type:content-transfer-encoding :subject:message-id:date:to:mime-version; bh=4VXzWHWZ0cjw6cJuIUhg69dMiuczfmen6jf6E5H8VgA=; b=iGYaNRzcGg8hazcjZ7R1p/twFwTmXY6Yxqd3DwlvgqYFG95KyZYcC90C7bOeHElGNQ hAX3T0Pqo3IhcsUS8yfM49a4Z9eOsgR5JmfgMhzBATq99DVHb9+Fek0MYNKbU+9PW0dF pp3dRMgYKz8kQNWwX2M9xjNyNeNIJ15DOf2B+jBEjgT8g1iQDH35whvK4+2V3BdTBGnA 0iTl9ZpPBtyxl8ZNsgahzaXosi3Kb1mGzWqMK1b+s2zo/AkE32UBr7Vri0ex6eQOhJzL 9lGRXbw6mcRjuulcNsN+1yiaCgzfZnYuj0tMUp3+hDq78ktWRMhuMuPp9aOqs8Zcvwta JQKg== X-Gm-Message-State: AG10YORXMfDQDR8PyL80FyfOtAjPRe8uf1+l6P4cpjhx9ZJNsqTXHBtfKbtVCA11Q9HIiQ== X-Received: by 10.37.56.211 with SMTP id f202mr9699956yba.1.1453738736451; Mon, 25 Jan 2016 08:18:56 -0800 (PST) Received: from [172.16.0.112] ([96.231.217.211]) by smtp.gmail.com with ESMTPSA id f186sm14618226ywa.6.2016.01.25.08.18.55 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 25 Jan 2016 08:18:56 -0800 (PST) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <2073ABB8-AEC7-4475-8159-AA7FE426C5B6@sn3rd.com> Date: Mon, 25 Jan 2016 11:18:54 -0500 To: rtcweb@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) X-Mailer: Apple Mail (2.3112) Archived-At: Subject: [rtcweb] WGLC for draft-ietf-rtcweb-alpn 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: Mon, 25 Jan 2016 16:18:58 -0000 All, This is the working group last call for the =E2=80=9CALPN" draft = available at https://datatracker.ietf.org/doc/draft-ietf-rtcweb-alpn/. = Please review the draft and send your comments to this list by Tuesday, = February 9th, 2016. =20 Thanks, C/T/S= From nobody Tue Jan 26 04:15:16 2016 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 5F03C1B2CD1 for ; Tue, 26 Jan 2016 04:15:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.499 X-Spam-Level: X-Spam-Status: No, score=-0.499 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 hJOTGnK2Iqan for ; Tue, 26 Jan 2016 04:15:13 -0800 (PST) Received: from smtp002.apm-internet.net (smtp002.apm-internet.net [85.119.248.221]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25D571B2CA5 for ; Tue, 26 Jan 2016 04:15:12 -0800 (PST) Received: (qmail 49947 invoked from network); 26 Jan 2016 12:15:10 -0000 X-AV-Scan: clean X-APM-Authkey: 83769/0 6420 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp002.apm-internet.net with SMTP; 26 Jan 2016 12:15:10 -0000 Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTPS id AC11718A0643; Tue, 26 Jan 2016 12:15:07 +0000 (GMT) Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTPS id 9981418A0CDB; Tue, 26 Jan 2016 12:15:07 +0000 (GMT) Received: from limit.westhawk.co.uk (unknown [192.67.4.33]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id 7B52618A0643; Tue, 26 Jan 2016 12:15:07 +0000 (GMT) Content-Type: multipart/alternative; boundary="Apple-Mail=_F879A6FF-BD73-4469-9B56-2AC573FA1EA9" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Tim Panton In-Reply-To: Date: Tue, 26 Jan 2016 12:15:06 +0000 Message-Id: <78C957DC-4659-49A9-B4B9-EFAD5641574F@phonefromhere.com> References: To: "Cullen Jennings (fluffy)" X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Working group last call for draft-ietf-rtcweb-audio 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: Tue, 26 Jan 2016 12:15:15 -0000 --Apple-Mail=_F879A6FF-BD73-4469-9B56-2AC573FA1EA9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 19 Dec 2015, at 00:10, Cullen Jennings (fluffy) > wrote: >=20 >=20 >> On Dec 18, 2015, at 3:24 PM, Roman Shpount > wrote: >>=20 >> This applies to all DTMF tones, not A-D specifically. What I am = saying is that WebRTC endpoints must be able to generate all DTMF tones = including A-D and send them to legacy PSTN (gateway). >=20 > The thing people keep asking is why? what is the use case ? >=20 > I don=E2=80=99t feel like I have seen an answer to this.=20 More specifically - Under what circumstances will we need them where=20 the same result couldn=E2=80=99t be achieved by injecting the correct = notes into the stream using webAudio? It has been suggested that webaudio tone generation might not work with = certain sets of codecs. But surely the (few) legacy systems (coal mines for example) that use = A-D will be using G711 for which tone generation should work well. (I might add that tone _detection_ can also be done in webaudio so = developers have a symmetrical solution). Tim. >=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb Tim Panton - Web/VoIP consultant and implementor www.westhawk.co.uk --Apple-Mail=_F879A6FF-BD73-4469-9B56-2AC573FA1EA9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 19 Dec 2015, at 00:10, Cullen Jennings = (fluffy) <fluffy@cisco.com> wrote:


On Dec 18, 2015, at 3:24 PM, Roman Shpount <roman@telurix.com> = wrote:

This applies to all DTMF tones, not A-D specifically. What I am saying is = that WebRTC endpoints must be able to generate all DTMF tones including = A-D and send them to legacy PSTN (gateway).

The thing people keep asking is why? what is the use = case ?

I don=E2=80=99t feel like I have seen an answer to = this. 

More specifically - Under what = circumstances will we need them where 
the = same result couldn=E2=80=99t be achieved by injecting the correct notes = into the stream using webAudio?
It has been = suggested that webaudio tone generation might not work with certain sets = of codecs.
But surely the (few) legacy systems = (coal mines for example) that use A-D will be using G711
for which tone generation should work well.

(I might add that tone = _detection_ can also be done in webaudio so developers have a = symmetrical solution).

Tim.



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

Tim Panton - = Web/VoIP consultant and implementor
www.westhawk.co.uk



= --Apple-Mail=_F879A6FF-BD73-4469-9B56-2AC573FA1EA9-- From nobody Tue Jan 26 06:26:33 2016 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 12AE51B2A1F for ; Tue, 26 Jan 2016 06:26:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 pI4JZK-Q7DvI for ; Tue, 26 Jan 2016 06:26:30 -0800 (PST) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77F761B2A1E for ; Tue, 26 Jan 2016 06:26:30 -0800 (PST) Received: by mail-wm0-x22f.google.com with SMTP id r129so106440241wmr.0 for ; Tue, 26 Jan 2016 06:26:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=4SWELUYt9Dr9P+XW0Z+/CzhX5iXofHpMlLYVBpqfJQs=; b=n4WYdKXFX67edKcrmrtU2j1O52drawxMDb/GcSlYkVOnA6XSPtRRaXA37aoj7CU7bE 5Vb4LZoL6KDGzO2c5xf1KMh0eZiJr8f6unL689yqCymj+fr8S4mpMR9jeHudPaSr94Lg CvVczoC3lnFvO7vVMXsHczT7Nm5hqWsWT02Dk/X030T6nPytISYjpydzJ9r/LQTF/AU7 a8se2CGkoueOqmxjzdzaxiCJpXhzh9zSr8uXgDffdD7HwABpp4c3nuAh4qSBpKNtmYc3 s5DGUIYh8Eg3CWyggvZNnik1D5zR5+Q3tRi7wxPHWGw/XIuTBhFOW3w9IGuSFYFUwFTb h7tQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type:content-transfer-encoding; bh=4SWELUYt9Dr9P+XW0Z+/CzhX5iXofHpMlLYVBpqfJQs=; b=BKsftAnoOCAwSqaBSjGovqQ/+ae7S2cM5pkXKBU4f22H3V7BGWN7Lhux910hgelyHg YCGTQJKdp4y+LHtqhe4x/BJV6FADGPkUWo4WAzp0fxU2+ZKulr1E5lJTsL9J88c3169o YXYSbCbETi8K+7XkWB0E+poJn3yZa6cSM5xmRhNoqvsY43FsSVX7zTnn9K9FbBJ7LSnn WAAtnMWC5TJJqnu4So7Lh0zoOizv4uAEq1MuDOpEcUnjxdZ+f71BAAe5JIvCiOC0Nx1L ERQXYscPvs6zdkhy4Vw+XHgrEZna+UsEUw29zDVs+z8T/2EiXUYdtbu0IYiQdd5Frq2P y8+g== X-Gm-Message-State: AG10YOT7AD2NO5kXJHF38HmU/7x4J8PFAhHSjYUxz6Om5gOYAMUvgErumtoWsX9lUWDmuUYRaYhTFSJe1noFaw== MIME-Version: 1.0 X-Received: by 10.28.99.69 with SMTP id x66mr25250610wmb.10.1453818388903; Tue, 26 Jan 2016 06:26:28 -0800 (PST) Received: by 10.28.94.18 with HTTP; Tue, 26 Jan 2016 06:26:28 -0800 (PST) In-Reply-To: References: Date: Tue, 26 Jan 2016 15:26:28 +0100 Message-ID: From: Victor Pascual Avila To: "rtcweb@ietf.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [rtcweb] Call for WG adoption: draft-shieh-rtcweb-ip-handling 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: Tue, 26 Jan 2016 14:26:32 -0000 I support the adoption of this draft as WG item On Wed, Jan 20, 2016 at 11:41 PM, Sean Turner wrote: > All, > > In Yokohama, we reviewed the "IP address leakage=E2=80=9D issues and the = sense of the room was that we should document this in its own document. So= to get that done =E2=80=A6 please respond to indicate whether you support = adoption of https://datatracker.ietf.org/doc/draft-shieh-rtcweb-ip-handling= / as a working group work item and whether you will participate in the disc= ussion. If you are opposed to this draft becoming a WG document, please s= ay so (and say why). Please have your response in by February 4th. > > Thanks in advance! > T/C/S > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --=20 Victor Pascual =C3=81vila From nobody Tue Jan 26 11:51:32 2016 Return-Path: X-Original-To: rtcweb@ietf.org Delivered-To: rtcweb@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 168CB1B2C47; Tue, 26 Jan 2016 11:51:30 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160126195130.9900.25846.idtracker@ietfa.amsl.com> Date: Tue, 26 Jan 2016 11:51:30 -0800 Archived-At: Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-return-01.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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: Tue, 26 Jan 2016 19:51:30 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Real-Time Communication in WEB-browsers Working Group of the IETF. Title : Recursively Encapsulated TURN (RETURN) for Connectivity and Privacy in WebRTC Authors : Benjamin M. Schwartz Justin Uberti Filename : draft-ietf-rtcweb-return-01.txt Pages : 18 Date : 2016-01-26 Abstract: In the context of WebRTC, the concept of a local TURN proxy has been suggested, but not reviewed in detail. WebRTC applications are already using TURN to enhance connectivity and privacy. This document explains how local TURN proxies and WebRTC applications can work together. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-return/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-rtcweb-return-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-return-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jan 26 12:00:08 2016 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 A44441B2CB2 for ; Tue, 26 Jan 2016 12:00:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no 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 iY2ooOy9Ac-q for ; Tue, 26 Jan 2016 12:00:00 -0800 (PST) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49E131B2C46 for ; Tue, 26 Jan 2016 12:00:00 -0800 (PST) Received: by mail-io0-x22d.google.com with SMTP id g73so202228377ioe.3 for ; Tue, 26 Jan 2016 12:00:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=VId9ylHlNRhlodVLdr7zgN940QzoC2MgkBfRSoLoEdk=; b=vjD928Rm119guEAC5kcmldNVcgvi8cyQUHbmIGP+iLVriqoLSsQXowXxiyIbA0I3Rc nCgON9BCge7wEIROi23ooh+B4OkL6gqEN54ecmuWWyjEpjPV6Kkr7eYpoqsdwk1YJNx6 UoT84PMlQGA5FnmaXT7TYItYJpQM1kmZp8iO1jfK1qHAPSStM/xZxA+DHlMH+A6+dARC YpRba98NPzDkNqqfMJdi5GQoGLgo4cJI2l0IlbzO5gMNshlnuAFJOyE7L7Cl54nO+1lj tVIejDCDk5kcG4ZYURlDTs5IoztLNuyNT3IMjyqbMLV/JO/hBZONHGB0S4gIUQVpmn+O ++tA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=VId9ylHlNRhlodVLdr7zgN940QzoC2MgkBfRSoLoEdk=; b=fnxfslCeqzJuVHyDPtEcxMhGpop0c6i0Ofqi8Vl+dsukJRkKhEEjFUd8XiANEzAjUr ofKdB6KSlXzMz3M3qAEdu65kep7vvXRs0MjI32eGM1i3hUzFxZH5pcIYFfB1mTEabTcS sFnhqsVzmttYYySYMZF9nK0PVsxweZJcunUJYCGhovAPzAo5MW2a09pPs7yMo0V+E6Zg WmSYIZi3S8yaprQQuTPxx1qkHoN+iIXNjASykrBc3BphaFUNs7mBfi8rMS2PD6vsyG+k omDVYsQqv3ztplBTI/49J56Djas8Kua4crGOADdN63Pplrt5OFlwhVBM2qb8PRsYb03P pf2g== X-Gm-Message-State: AG10YOSwlyzZoXX1r5cIJD0HALyNKFABiLmuuxbAcpL1pYxguGWSZoFVW9LJL+43LHmqHQ== X-Received: by 10.107.129.16 with SMTP id c16mr24071159iod.181.1453838399596; Tue, 26 Jan 2016 11:59:59 -0800 (PST) Received: from mail-ig0-f171.google.com (mail-ig0-f171.google.com. [209.85.213.171]) by smtp.gmail.com with ESMTPSA id kl9sm1911804igb.22.2016.01.26.11.59.58 for (version=TLSv1/SSLv3 cipher=OTHER); Tue, 26 Jan 2016 11:59:58 -0800 (PST) Received: by mail-ig0-f171.google.com with SMTP id mw1so59871442igb.1 for ; Tue, 26 Jan 2016 11:59:58 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.50.43.136 with SMTP id w8mr25288295igl.96.1453838398025; Tue, 26 Jan 2016 11:59:58 -0800 (PST) Received: by 10.36.105.77 with HTTP; Tue, 26 Jan 2016 11:59:57 -0800 (PST) In-Reply-To: <78C957DC-4659-49A9-B4B9-EFAD5641574F@phonefromhere.com> References: <78C957DC-4659-49A9-B4B9-EFAD5641574F@phonefromhere.com> Date: Tue, 26 Jan 2016 14:59:57 -0500 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: Tim Panton Content-Type: multipart/alternative; boundary=089e011602a8467b10052a42218e Archived-At: Cc: "Cullen Jennings \(fluffy\)" , "rtcweb@ietf.org" Subject: Re: [rtcweb] Working group last call for draft-ietf-rtcweb-audio 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: Tue, 26 Jan 2016 20:00:06 -0000 --089e011602a8467b10052a42218e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Jan 26, 2016 at 7:15 AM, Tim Panton wrote: > > More specifically - Under what circumstances will we need them where > the same result couldn=E2=80=99t be achieved by injecting the correct not= es into > the stream using webAudio? > It has been suggested that webaudio tone generation might not work with > certain sets of codecs. > But surely the (few) legacy systems (coal mines for example) that use A-D > will be using G711 > for which tone generation should work well. > > (I might add that tone _detection_ can also be done in webaudio so > developers have a symmetrical solution). > Any tone generated using inband audio will be less reliable then telephone-events tone. For telephone-events 3 or more packets in a row need to be lost for the tone to be lost or interrupted. For inband loosing a single packet can break tone in two distinct tones. I am not even talking about all the extra work and interop required to properly implement tone generation. To generate all DTMF tone telephone-events you need no extra code in the browser you need no additional code. Finally, if you want WebRTC to be backwards compatible with RFC 2833 (which is the most common implementation of telephone-events in PSTN universe), then you will need to deal with this https://tools.ietf.org/html/rfc2833#section-3.3: A compliant implementation MUST support the events listed in Table 1 with the exception of "flash". If it uses some other, out-of-band mechanism for signaling line conditions, it does not have to implement the other events. Here is table 1 (https://tools.ietf.org/html/rfc2833#section-3.10): Table 1 summarizes the DTMF-related named events within the telephone-event payload format. Event encoding (decimal) _________________________ 0--9 0--9 * 10 # 11 A--D 12--15 Flash 16 Table 1: DTMF named events So, all DTMF digits 0-9, *, #, A-D are required by RFC 2833. So, if you want to break backwards compatibility please explain your motivation. These tones (as well as all the other telephone-events) are only needed for backwards compatibility. Implemented all or some of them requires the same amount of effort. Not implementing all of them will make life harder for the few people who use them. Finally, I have wrote several other things regarding DTMF tone generation which are considerably more important. Does everyone agree with the following or no one cares: Generated events MUST have duration of no more than 6000 ms and no less than 40 ms with the recommended default duration of 100 ms for each tone. The gap between events MUST be no less then 30 ms with the recommended default duration of 70 ms. Event SHOULD start on a regular audio packet border and event and gap duration SHOULD be rounded up to the next regular audio packet border. During the time events are generated no audio SHOULD be sent for the same audio stream. When gaps between events are generated, silence and not the background audio SHOULD be sent using regular audio encoding. If multiple audio sampling rates are supported, audio/telephone-event payload SHOULD be present for each supported sampling rate. Endpoints SHOULD use audio/telephone-event format parameters during the offer/answer to indicate which events are supported. Receivers MUST be able to consume any audio/telephone-event events in such a way that it will not generate audio artifacts, jitter buffer adjustments, payload mismatches, or invalid RTCP statistics calculation. Receivers MAY generate audio corresponding to the received events but are also allowed to discard them in a manner that does not affect regular audio processing. Regards, _____________ Roman Shpount --089e011602a8467b10052a42218e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Jan 26, 2016 at 7:15 AM, Tim Panton <tim@phonefromhere.co= m> wrote:

More specifically - Under what circumstances w= ill we need them where=C2=A0
the same result couldn=E2=80=99t be = achieved by injecting the correct notes into the stream using webAudio?
It has been suggested that webaudio tone generation might not work w= ith certain sets of codecs.
But surely the (few) legacy systems (= coal mines for example) that use A-D will be using G711
for which= tone generation should work well.

(I might add th= at tone _detection_ can also be done in webaudio so developers have a symme= trical solution).

Any ton= e generated using inband audio will be less reliable then telephone-events = tone. For telephone-events 3 or more packets in a row need to be lost for t= he tone to be lost or interrupted. For inband loosing a single packet can b= reak tone in two distinct tones. I am not even talking about all the extra = work and interop required to properly implement tone generation. To generat= e all DTMF tone telephone-events you need no extra code in the browser you = need no additional code.

Finally, if you want WebR= TC to be backwards compatible with RFC 2833 (which is the most common imple= mentation of telephone-events in PSTN universe), then you will need to deal= with this=C2=A0https://tools.ietf.org/html/rfc2833#section-3.3:

<= div>
   A compliant implementation MUST support the eve=
nts listed in Table 1
   with the exception of "flash". If it uses some other, out-of-b=
and
   mechanism for signaling line conditions, it does not have to
   implement the other events.

Here is = table 1 (https= ://tools.ietf.org/html/rfc2833#section-3.10):

= 
   Table 1 summarizes the DTMF-related named events wi=
thin the
   telephone-event payload format.

                     Event  encoding (decimal)
                     _________________________
                     0--9                0--9
                     *                     10
                     #                     11
                     A--D              12--15
                     Flash                 16

                     Table 1: DTMF named events
=
So, all DTMF digits 0-9, *, #, A-D are required by RFC 2833.

So, if you want to break backwards compatibility pleas= e explain your motivation. These tones (as well as all the other telephone-= events) are only needed for backwards compatibility. Implemented all or som= e of them requires the same amount of effort. Not implementing all of them = will make life harder for the few people who use them.

=
Finally, I have wrote several other things regarding DTMF tone generat= ion which are considerably more important. Does everyone agree with the fol= lowing or no one cares:

Generated events= MUST have duration of no more than 6000 ms and no less
than 40 ms with the recommended default duration of 100 ms for each tone= .=C2=A0
The gap between events MUST be no less then 3= 0 ms with the recommended
default duration of 70 ms. = Event SHOULD start on a regular audio packet
border a= nd event and gap duration SHOULD be rounded up to the next regular
audio=C2=A0packet border.

During= the time events are generated no audio SHOULD be sent for the same<= /div>
audio stream. When gaps between events are generated, silenc= e
and not the background audio SHOULD be= sent using regular audio encoding.

If multiple audio sampling rates are supported, audio/telepho= ne-event payload
SHOULD be present for each supported= sampling rate. Endpoints SHOULD use
audio/telephone-= event format parameters during the offer/answer to=C2=A0
indicate which events are supported.

<= /div>
Receivers MUST be able to consume any audio/telephone-event = events
in such a way that it will not generate audio = artifacts, jitter buffer
adjustments, payload mismatc= hes, or invalid RTCP statistics calculation.
Receiver= s MAY generate audio=C2=A0corresponding to the received events=C2=A0
but are also allowed to discard them=C2=A0in a manner that does not affect=C2=A0=
regular audio processing.

Regards,
_____________
Roman Shpount
=C2=A0
--089e011602a8467b10052a42218e-- From nobody Tue Jan 26 12:26:58 2016 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 C9D351B2CFC for ; Tue, 26 Jan 2016 12:26:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 sgOJaaqsuj1H for ; Tue, 26 Jan 2016 12:26:46 -0800 (PST) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 730811B2CF9 for ; Tue, 26 Jan 2016 12:26:46 -0800 (PST) Received: by mail-qk0-x232.google.com with SMTP id o6so68089546qkc.2 for ; Tue, 26 Jan 2016 12:26:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=Nde1B8+mG18F9wd2+vv54VZzTn8magzrOJ/2N77FjY4=; b=C0QWHSzK73tNo6PwBb2Xa3+VePfLLTIZYVpROSzIeiXYN8ri2GapxdNjZGTqdm0qKu 727rUMXFteLVEZFiGPI6e1w4USvExivfbrVAkseVVYrVq6iUayg6l+G1EKl3XegO0M/q 2ps66aZdJVdRul7N5DUf1sQ1+dX+gHPx+pj5d3X1u8R0hclN5/O+6arEqWw2qVAS73It FwrKDW2fZH0xbzZhT1QRtAqHCXUJxXwbYRkpi8K9mQ+eg8i9U4RkJ1CYcDkG5vnEyevK NDQl29J/HgeQvWIVUJ0FJhFShsckNj1rY+mGkp0OAqoal8LMrDrpiA0tINq9CfJdhSpl QllQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=Nde1B8+mG18F9wd2+vv54VZzTn8magzrOJ/2N77FjY4=; b=JfX2o4rHQbJhHvYdSXF1txDFLOBF5VekUX8iFNXft+AS1znXhRqIlvnmDZZ8fi0TT1 jTbR/6i5msszGbxug1ZvnCN0eyDKlHZanprAYqhy4YW/ORKaQ71gC//T1xASLoOJja3L R5mIOKkfTTIptjxMNkbyJK2KAoLLGbdtLXuBKIPWiM9ypge0mVV3z3egmvikfg3VFrMe eOts88EB44jV7+sQvySG3QO9sqJ+WyHXevn+MWTPMBWuNm3ppaObQtYo2k/fapeGx96I BbSbasNZji68Zjg2RwDCb3Cnl/DJv1K1CMNhMP+2LB4KFuBMJXqRob4uSE9bUwwqmoDr SIzA== X-Gm-Message-State: AG10YOQ4QERXkWEqnO/YkoQsyNWHdvCEAH94XStdzh9FTq8RzWPz8nPBg5siLe+RKaISLqea X-Received: by 10.55.79.86 with SMTP id d83mr31326868qkb.22.1453840005391; Tue, 26 Jan 2016 12:26:45 -0800 (PST) Received: from panoramix.jmvalin.ca (modemcable121.240-21-96.mc.videotron.ca. [96.21.240.121]) by smtp.gmail.com with ESMTPSA id v137sm203920qka.43.2016.01.26.12.26.43 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 26 Jan 2016 12:26:44 -0800 (PST) To: Roman Shpount , Tim Panton References: <78C957DC-4659-49A9-B4B9-EFAD5641574F@phonefromhere.com> From: Jean-Marc Valin X-Enigmail-Draft-Status: N1110 Message-ID: <56A7D683.2010807@mozilla.com> Date: Tue, 26 Jan 2016 15:26:43 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Cc: "Cullen Jennings \(fluffy\)" , "rtcweb@ietf.org" Subject: Re: [rtcweb] Working group last call for draft-ietf-rtcweb-audio 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: Tue, 26 Jan 2016 20:26:54 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi Roman, On 01/26/2016 02:59 PM, Roman Shpount wrote: > Finally, I have wrote several other things regarding DTMF tone > generation which are considerably more important. Does everyone > agree with the following or no one cares: The text below is what you propose for the rtcweb-audio draft? I personally have no opinion on these events (see comment inline for clarification though) so I'm happy to include that text if everyone else is OK with it. > Generated events MUST have duration of no more than 6000 ms and no > less than 40 ms with the recommended default duration of 100 ms for > each tone. The gap between events MUST be no less then 30 ms with > the recommended default duration of 70 ms. Event SHOULD start on a > regular audio packet border and event and gap duration SHOULD be > rounded up to the next regular audio packet border. > > During the time events are generated no audio SHOULD be sent for > the same audio stream. When gaps between events are generated, > silence and not the background audio SHOULD be sent using regular > audio encoding. I think this would require a bit of clarification. What does "no audio" mean here? Silence or no codec packets at all (in that case what about PLC)? Also, keep in mind that any silence may not be perfectly aligned with theoretical frame boundaries, due to look-ahead. > If multiple audio sampling rates are supported, > audio/telephone-event payload SHOULD be present for each supported > sampling rate. Endpoints SHOULD use audio/telephone-event format > parameters during the offer/answer to indicate which events are > supported. > > Receivers MUST be able to consume any audio/telephone-event events > in such a way that it will not generate audio artifacts, jitter > buffer adjustments, payload mismatches, or invalid RTCP statistics > calculation. Receivers MAY generate audio corresponding to the > received events but are also allowed to discard them in a manner > that does not affect regular audio processing. Cheers, Jean-Marc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJWp9aBAAoJEJ6/8sItn9q9rMkH/1a1vSiUD48mxA2MN7WeHYV9 qGZl1Or69xJnOaG/67oyiwMg6E46BaxFi55Wqd5RAIqC9uNkKosk5HgbPbc+NM2Y xaJxfDPXKnCPNiS7HxtUOTzGMysXOpOEkDKAF2EYCMyh6fQKhKJQxaRWFGgmctgj 0lOZnyk1NbQBhq8pWW3dFO0BiRCph/JLi3CH3HYA1YjMCi2n0JH6kmVSV57j1qQc eTFdkuJIMF05f0I9224sAMYBhCMvw/r5tKM34b2SPwFMDZRixVsMfZT6oJfHorhg jz8MIUcaiTezdGfUJ8OEFCRD3Qn3SrkWy1NEC+qUDpVwNZiUwE8uNRBu+PqSISw= =1UJ7 -----END PGP SIGNATURE----- From nobody Tue Jan 26 13:21:48 2016 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 9C7A71B3180 for ; Tue, 26 Jan 2016 13:21:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no 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 F4o7mia41Pom for ; Tue, 26 Jan 2016 13:21:44 -0800 (PST) Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F2271B2C67 for ; Tue, 26 Jan 2016 13:21:44 -0800 (PST) Received: by mail-ig0-x22b.google.com with SMTP id t15so69254317igr.0 for ; Tue, 26 Jan 2016 13:21:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/7tL7VC52mlPN+pO80lyp8Wzf15edPLelJv6sFa5b04=; b=OvDULqlizu5ReCCrqxCz/xBv1irWCsa60zhtw3LIgFEE18JCGiSauH1wCgNAV/jtk9 dzwitOinbz2mkVA/YwamsUAVwgxLB/kfTPYrDdLSLs4948/iXoMVPun+2t9isDwwqJ6s F5Bf8VVVME+kQent3JYTmzHIFrCNtEe1SQfs7twnJ7Q2AjcrLWupJAml2qL/B1YYubjA Oc+HxEQha76ZKw31vg/trP91qKYKK4rMyl4arnKYHKe/yAYeC6UEbOlqFeh95dkelaNS dKYVb8vmINcHGTh4edQOs/1n0Hg0Zy2GMmMKHcvnl5lGRYiBI9aqBtoqM5Q2OtrJgBVd uF8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=/7tL7VC52mlPN+pO80lyp8Wzf15edPLelJv6sFa5b04=; b=cV/EZAPtUmISms1fGgyINyKHPzm15OzTdsJcSe5WCC1Vkn8pbFQeUZp8xjRlWyk78a 1mwgbJY5blXNIGHh1877u7FUtQunC+dMt9MTuQloocUzb0r04qWPOhcOBYKeJdFCz2yb bFAYupw+9poLBLrHbbSo3nNNKtpUhstpK6nO1H5PRnKERUh8m4OMSWdk5qrxNXzb7Fpr xlLVRUVTYmXqURf/FodQHXBGTc6NZQ4CHQBg2rvBC2nkQYq3SAsv3x2s+UFUmd8us9SI Ol+a3We9cbQYMQr0cOpb2hj7tpixw+K2gD98f5pQ34g/NrUjryI4Q3E+TB62zXbXKO3z Oi6Q== X-Gm-Message-State: AG10YOTFESamTwIkeKocTSy+lBstv5h86Z+723k7TbyuqxzkxSARyC2fRS3ghYJRJuXmBg== X-Received: by 10.50.155.43 with SMTP id vt11mr25725303igb.6.1453843303636; Tue, 26 Jan 2016 13:21:43 -0800 (PST) Received: from mail-ig0-f170.google.com (mail-ig0-f170.google.com. [209.85.213.170]) by smtp.gmail.com with ESMTPSA id qd10sm2051061igc.1.2016.01.26.13.21.41 for (version=TLSv1/SSLv3 cipher=OTHER); Tue, 26 Jan 2016 13:21:42 -0800 (PST) Received: by mail-ig0-f170.google.com with SMTP id z14so66937251igp.0 for ; Tue, 26 Jan 2016 13:21:41 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.50.102.69 with SMTP id fm5mr25784652igb.24.1453843301499; Tue, 26 Jan 2016 13:21:41 -0800 (PST) Received: by 10.36.105.77 with HTTP; Tue, 26 Jan 2016 13:21:41 -0800 (PST) In-Reply-To: <56A7D683.2010807@mozilla.com> References: <78C957DC-4659-49A9-B4B9-EFAD5641574F@phonefromhere.com> <56A7D683.2010807@mozilla.com> Date: Tue, 26 Jan 2016 16:21:41 -0500 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: Jean-Marc Valin Content-Type: multipart/alternative; boundary=047d7b10ca098b963b052a434572 Archived-At: Cc: "Cullen Jennings \(fluffy\)" , "rtcweb@ietf.org" Subject: Re: [rtcweb] Working group last call for draft-ietf-rtcweb-audio 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: Tue, 26 Jan 2016 21:21:46 -0000 --047d7b10ca098b963b052a434572 Content-Type: text/plain; charset=UTF-8 On Tue, Jan 26, 2016 at 3:26 PM, Jean-Marc Valin wrote: > The text below is what you propose for the rtcweb-audio draft? I > personally have no opinion on these events (see comment inline for > clarification though) so I'm happy to include that text if everyone > else is OK with it. > Yes, this is the text I am proposing for rtcweb-audio draft. > Generated events MUST have duration of no more than 6000 ms and no > > less than 40 ms with the recommended default duration of 100 ms for > > each tone. The gap between events MUST be no less then 30 ms with > > the recommended default duration of 70 ms. Event SHOULD start on a > > regular audio packet border and event and gap duration SHOULD be > > rounded up to the next regular audio packet border. > > > > During the time events are generated no audio SHOULD be sent for > > the same audio stream. When gaps between events are generated, > > silence and not the background audio SHOULD be sent using regular > > audio encoding. > > I think this would require a bit of clarification. What does "no > audio" mean here? Silence or no codec packets at all (in that case > what about PLC)? Also, keep in mind that any silence may not be > perfectly aligned with theoretical frame boundaries, due to look-ahead. > > First of all I was trying to copy all the normative tone duration information from W3C document to rtcweb-audio draft. Second, as far as "no audio" is concerned, what I mean here is that RFC4733 telephone-events are alternative audio encoding similar to CN (see https://tools.ietf.org/html/rfc4733#section-2.5.2.2). For RTP timestamp interval covered by telephone-event no non-event audio packets, such as Opus or G.711, should be present since they are redundant and cause interop problems. PLC does not apply here since remote gateways is supposed to generate audio based on the information in telephone-events packets. This is essentially the same requirement that end point should not send packets with two different audio encodings (i.e. send Opus and G.711 RTP packets) at the same time. This can work but can also cause interop problems. Packet boundaries of audio encoded using codecs such as G.711 or Opus should create a continuous stream as far as RTP timestamps are concerned with RFC 4733 telephone event packets unless discontinuous RTP is used. It should be possible to align decoded audio and telephone-events based on RTP timestamps. I also wanted to provide clarification for https://tools.ietf.org/html/rfc4733#section-2.5.1.2. This section says: A source has wide latitude as to how often it sends event updates. A natural interval is the spacing between non-event audio packets. (Recall that a single RTP packet can contain multiple audio frames for frame-based codecs and that the packet interval can vary during a session.) Alternatively, a source MAY decide to use a different spacing for event updates, with a value of 50 ms RECOMMENDED. I am proposing that WebRTC should recommend that sending telephone-event packet at natural interval between non-event audio packets is strongly preferred. Also, blocking input audio for a short period of time after telephone-events are transmitted prevents a duplicate DTMF digit audio from being present in the encoded audio stream which some times happen due to microphone picking up audio feedback tones played by some DTMF keypad implementations. This also improves DTMF tone recognition by a receiving IVR system after audio stream passes through PSTN gateway since having background audio as a separator between DTMF digits can negatively affect some tone detection algorithms. Please let me know if you need more information. Regards, _____________ Roman Shpount --047d7b10ca098b963b052a434572 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Jan 26, 2016 at 3:26 PM, Jean-Marc Valin <= ;jmvalin@mozilla.c= om> wrote:
The text below is what you propose for the rtcweb-audio draft? I personally have no opinion on these events (see comment inline for
clarification though) so I'm happy to include that text if everyone
else is OK with it.

Yes, this is the te= xt I am proposing for rtcweb-audio draft.=C2=A0

> Generated events MUST have duration of no m= ore than 6000 ms and no
> less than 40 ms with the recommended default duration of 100 ms for > each tone. The gap between events MUST be no less then 30 ms with
> the recommended default duration of 70 ms. Event SHOULD start on a
> regular audio packet border and event and gap duration SHOULD be
> rounded up to the next regular audio packet border.
>
> During the time events are generated no audio SHOULD be sent for
> the same audio stream. When gaps between events are generated,
> silence and not the background audio SHOULD be sent using regular
> audio encoding.

I think this would require a bit of clarification. What does "n= o
audio" mean here? Silence or no codec packets at all (in that case
what about PLC)? Also, keep in mind that any silence may not be
perfectly aligned with theoretical frame boundaries, due to look-ahead.


First of all I= was trying to copy all the normative tone duration information from W3C do= cument to rtcweb-audio draft.

Second, as far as &q= uot;no audio" is concerned, what I mean here is that RFC4733 telephone= -events are alternative audio encoding similar to CN (see =C2=A0https://tools.ietf.org= /html/rfc4733#section-2.5.2.2). For RTP timestamp interval covered by t= elephone-event no non-event audio packets, such as Opus or G.711, should be= present since they are redundant and cause interop problems. PLC does not = apply here since remote gateways is supposed to generate audio based on the= information in telephone-events packets. This is essentially the same requ= irement that end point should not send packets with two different audio enc= odings (i.e. send Opus and G.711 RTP packets) at the same time. This can wo= rk but can also cause interop problems.=C2=A0

Pack= et boundaries of audio encoded using codecs such as G.711 or Opus should cr= eate a continuous stream as far as RTP timestamps are concerned with RFC 47= 33 telephone event packets unless discontinuous RTP is used. It should be p= ossible to align decoded audio and telephone-events based on RTP timestamps= .

I also wanted to provide clarification for https://tools.ie= tf.org/html/rfc4733#section-2.5.1.2. This section says:

<= /div>
   A source has wide latitude as to how ofte=
n it sends event updates.  A
   natural interval is the spacing between non-event audio packets.
   (Recall that a single RTP packet can contain multiple audio frames
   for frame-based codecs and that the packet interval can vary during a
   session.)  Alternatively, a source MAY decide to use a different
   spacing for event updates, with a value of 50 ms RECOMMENDED.

I am proposing that WebRTC should recommend= that sending telephone-event packet at natural interval between non-event audio packets i= s strongly=C2=A0preferred.

Also, blocking input audio for a short period = of time after telephone-events are transmitted prevents a duplicate DTMF di= git audio from being present in the encoded audio stream which some times h= appen due to microphone picking up audio feedback tones played by some DTMF= keypad implementations. This also improves DTMF tone recognition by a rece= iving IVR system after audio stream passes through PSTN gateway since havin= g background audio as a separator between DTMF digits can negatively affect= some tone detection algorithms.

Please let me know if you need more information= .
Reg= ards,
_____________
Roma= n Shpount
=C2=A0
--047d7b10ca098b963b052a434572-- From nobody Wed Jan 27 09:18:13 2016 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 45AFB1ACE81 for ; Wed, 27 Jan 2016 09:18:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 7pryiAKrsuFd for ; Wed, 27 Jan 2016 09:18:01 -0800 (PST) Received: from mail-qg0-x233.google.com (mail-qg0-x233.google.com [IPv6:2607:f8b0:400d:c04::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE6C21ACE7F for ; Wed, 27 Jan 2016 09:18:01 -0800 (PST) Received: by mail-qg0-x233.google.com with SMTP id 6so12209640qgy.1 for ; Wed, 27 Jan 2016 09:18:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=VdA1w6D9fAdVKJw6JHj7YVXP6mq2+rqZGpCdoqskzCA=; b=Oc6yrPjFQ+n00gY9QNj6rNxCZ3qPiF2JggzRig4BHOKvXX69I3E+eLj8h5iMXtpnat UHOVnft43H2WW/3qjVkzIRqUEC1G6Fq+Om+EYmwof+dqD16yfPjwjva/JKSn56HUSQMy 30AF+ATRf4kJpysN5GqaJd8gCQjaHHhvOru/7q4ci5SzXz0cWJeN4yh8YCYQQAdTczXb XKGjoJ0vZ/OIg4K58+Qxn1U0mtkP3kH/+9PmINJIdCXfQp2J/iCu9Fh1SohnbT8XvmEM bI/mdqv3EClZXwbSRFR1ANyqAPFadym2LRkey3g6rYjqn/SuJSUmVxPW9bOjIQ6MLucR j9uA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=VdA1w6D9fAdVKJw6JHj7YVXP6mq2+rqZGpCdoqskzCA=; b=V8LOddovJjC+rOs+N4VxNhes9iKkESC2pzlpPRIePvvBN1Ba19oBUCdRN5ApdA6+YR 4jG3mXnfp/DmJnAAgTsu30Auf8E/bGybcuaOvsRttVdBYRNdCT+Soc8EP6ZvLz2yinpM iQfOiyKwzsBzA5J0T4cw4L0lrE8jb3koAAouirp4dVZ5Xv5Kc5yuRnSWDXrYxzdxQ9Lw ntawDNk1eQPz/8nIT7L1Lx0XL8qTxbE2+4m5JWg4n9rfUtBLbUbWWPkM/PqdmY+aHNhV zP7VFPt0t4sRhreVYESp+KkuBVq6AVPrEm4bCnfYkclm2tYvJ3/6yoJSbZiG/F7WCEe5 SYkw== X-Gm-Message-State: AG10YORpo3LskQDws8FfJv0AsPsPTa0B60AVLJWy6Ec5O44Ht8fOyiMW3vDf9u6qF9QdqRRF X-Received: by 10.140.20.145 with SMTP id 17mr37326248qgj.45.1453915080715; Wed, 27 Jan 2016 09:18:00 -0800 (PST) Received: from panoramix.jmvalin.ca (modemcable121.240-21-96.mc.videotron.ca. [96.21.240.121]) by smtp.gmail.com with ESMTPSA id z106sm2995719qge.18.2016.01.27.09.17.59 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 27 Jan 2016 09:17:59 -0800 (PST) To: Roman Shpount References: <78C957DC-4659-49A9-B4B9-EFAD5641574F@phonefromhere.com> <56A7D683.2010807@mozilla.com> From: Jean-Marc Valin X-Enigmail-Draft-Status: N1110 Message-ID: <56A8FBC6.5090304@mozilla.com> Date: Wed, 27 Jan 2016 12:17:58 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "Cullen Jennings \(fluffy\)" , "rtcweb@ietf.org" Subject: Re: [rtcweb] Working group last call for draft-ietf-rtcweb-audio 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: Wed, 27 Jan 2016 17:18:08 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 01/26/2016 04:21 PM, Roman Shpount wrote: > Second, as far as "no audio" is concerned, what I mean here is > that RFC4733 telephone-events are alternative audio encoding > similar to CN (see > https://tools.ietf.org/html/rfc4733#section-2.5.2.2). For RTP > timestamp interval covered by telephone-event no non-event audio > packets, such as Opus or G.711, should be present since they are > redundant and cause interop problems. PLC does not apply here > since remote gateways is supposed to generate audio based on the > information in telephone-events packets. This is essentially the > same requirement that end point should not send packets with two > different audio encodings (i.e. send Opus and G.711 RTP packets) at > the same time. This can work but can also cause interop problems. The problem I see is that unlike G.711, modern codecs (not just Opus) aren't stateless. It's not a simple thing to just stop and restart transmission during telephony events -- especially if you want to avoid glitches and want all implementations to behave the same. You need to consider look-ahead (6 ms for Opus, with 5-10 ms being typical), but also the "memory" from the previous frame. > Packet boundaries of audio encoded using codecs such as G.711 or > Opus should create a continuous stream as far as RTP timestamps are > concerned with RFC 4733 telephone event packets unless > discontinuous RTP is used. It should be possible to align decoded > audio and telephone-events based on RTP timestamps. What do you mean "create a continuous stream"? I thought you wanted the codec to stop transmitting. Jean-Marc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJWqPvDAAoJEJ6/8sItn9q9d9oH/iG/atFW3iubaitrGjd6tQvH czVTYEfIoJAFG6zoZaRDbsqyudhtpCPv3Yp2uMFeGNHUs9W70WyTZAaNLDaI9LXQ QvsfdVhiLx/36bgUP3Z4fJDoDBCOKCnKupnmG+GMYEbD22s7CHA+/N9sEthDMic7 bahQXSbCgu574Gv90uw//qY7pyhD96zG7PjTEO7fCWeIvdDXkXeH5cK3pb/4+49a rTI1D3MHvTwxIh9P9nf3squ4NYX+QWY4v6UAICQ+GcCVS0wmv7BKpFAccQERGJs/ CXHfo9sLavFSVKYND8//StqiVrtJrrLG/WUltvtpkqiiqTKObp22a15nrvQ9SCg= =oIW6 -----END PGP SIGNATURE----- From nobody Wed Jan 27 09:43:31 2016 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 20E761AD063 for ; Wed, 27 Jan 2016 09:43:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no 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 J_IPi0i7UuTO for ; Wed, 27 Jan 2016 09:43:28 -0800 (PST) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DAA41AD05F for ; Wed, 27 Jan 2016 09:43:28 -0800 (PST) Received: by mail-io0-x229.google.com with SMTP id g73so27426107ioe.3 for ; Wed, 27 Jan 2016 09:43:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7wWd4c/sztPkWAi08EuGxsbwXMP5Os4mOQL3vkAi8X0=; b=r3ZSXKxb/nW4+GnFBN8hTsktoADMLX5AaQB7n5dydRJ7f3omNmQ2qFrzcGnwCP+8IH F7RwW839RW3bjM6LU41s6cFkBQQkEVNQroDrcXSBX/ZMSxvhTd7i+8XY68jHs2hXtRSw K7ok3zcOpHsHG/5DT6OplPe+ee1MkyboOfIotzCHTbDdgTLR3M2MLXoKCG1RC5+7Tsfr TQVe1qR6NXJcyE0aSgwc8SESfwOXa+ol6cUHDCpj0ii2neXLyVOAZlXMVHyYBxJQTGb1 dyAZSl+H2GlUQbf6hpGD7u/U4Jx3hSTk8lkE7Rrwk/GlNwwBpAO6rvO7Os7VO6OeZQRx bJOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=7wWd4c/sztPkWAi08EuGxsbwXMP5Os4mOQL3vkAi8X0=; b=LmNiLq5z/JhqyVEn/MV6zyKAIZCf5mdEemx3bocH/i2/oSLp0Fd5R2TYsnhzS24EjR u7A7K+iqmwYz8bBKrpAGsmUS1/UBqVAYVP0iq8Lg/kD2sdNsH8qs3W4T2WiwdbVFUzuZ HnHv6tLTw7XchXiwQGw6CHcR0hQEmX/oDQXe3yCmlPVYkYqRlxcPnAgEVHf98u45pMlL JayCTtqhA5mfv+LDnRVX96aljROOji/4FuJYlzKCbFJVWmkS926V73C4LWpyRoCawwg2 EwT/KSN47Nsf1Ik7nmsBqiqrQlTvZbd/41OwUuZ6f2AyVHdjO4hDJLVqZmj9gTNEd2Cs Oq6g== X-Gm-Message-State: AG10YOQ9XyDdY/j1aue3SreFcGyv3ao0+pdT9f1sChHQTRMePMm23C+ojYZYG7uMdLLwEQ== X-Received: by 10.107.1.5 with SMTP id 5mr27570487iob.85.1453916607695; Wed, 27 Jan 2016 09:43:27 -0800 (PST) Received: from mail-ig0-f174.google.com (mail-ig0-f174.google.com. [209.85.213.174]) by smtp.gmail.com with ESMTPSA id vf11sm3480704igb.20.2016.01.27.09.43.26 for (version=TLSv1/SSLv3 cipher=OTHER); Wed, 27 Jan 2016 09:43:26 -0800 (PST) Received: by mail-ig0-f174.google.com with SMTP id h5so16785023igh.0 for ; Wed, 27 Jan 2016 09:43:26 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.50.155.65 with SMTP id vu1mr30934638igb.2.1453916605647; Wed, 27 Jan 2016 09:43:25 -0800 (PST) Received: by 10.36.105.77 with HTTP; Wed, 27 Jan 2016 09:43:25 -0800 (PST) In-Reply-To: <56A8FBC6.5090304@mozilla.com> References: <78C957DC-4659-49A9-B4B9-EFAD5641574F@phonefromhere.com> <56A7D683.2010807@mozilla.com> <56A8FBC6.5090304@mozilla.com> Date: Wed, 27 Jan 2016 12:43:25 -0500 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: Jean-Marc Valin Content-Type: multipart/alternative; boundary=001a11346410d01769052a54565e Archived-At: Cc: "Cullen Jennings \(fluffy\)" , "rtcweb@ietf.org" Subject: Re: [rtcweb] Working group last call for draft-ietf-rtcweb-audio 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: Wed, 27 Jan 2016 17:43:30 -0000 --001a11346410d01769052a54565e Content-Type: text/plain; charset=UTF-8 On Wed, Jan 27, 2016 at 12:17 PM, Jean-Marc Valin wrote: > The problem I see is that unlike G.711, modern codecs (not just Opus) > aren't stateless. It's not a simple thing to just stop and restart > transmission during telephony events -- especially if you want to > avoid glitches and want all implementations to behave the same. You > need to consider look-ahead (6 ms for Opus, with 5-10 ms being > typical), but also the "memory" from the previous frame. > In this regard Opus is no different then G.729 which was used with telephone-events for ages. Sending a telephone-event packet is an audio codec switch. Its behavior should be no different then switch from Opus to PCMU or from Opus to CN and back. I assume statefull codec such as Opus should reset its state before starting to send audio after such switch occurs. Is this correct? From what I know this was never defined anywhere and it might be a good idea from the codec designers to specify what is the best behavior for codec switches from telephone-event or CN. Since most of codecs converge very quickly I see this implemented equally often with or without codec state reset. Also, since telephone-events are normally followed by a period of silence (intertone gap), codec state plays much smaller role in practice. > Packet boundaries of audio encoded using codecs such as G.711 or > > Opus should create a continuous stream as far as RTP timestamps are > > concerned with RFC 4733 telephone event packets unless > > discontinuous RTP is used. It should be possible to align decoded > > audio and telephone-events based on RTP timestamps. > > What do you mean "create a continuous stream"? I thought you wanted > the codec to stop transmitting. > Yes, I do want the code to stop transmitting. I want the clean codec switch from non-event audio codec to telephone-event and back. What I mean here is if you have PCMU packet with timestamp 1000 and duration 160 the following telephone-event start timestamp should be 1160. The transition in other direction should also happen without the timestamp gap so that if telephone-event start timestamp is 1160 and the total tone duration is 800 then next non event audio packet should start with timestamp 1960. Furthermore, I like to recommend to switch from non-event to telephone-event and back on the regular packet boundary. This means no partial audio packets (17 ms audio packet before telephone event) and no gaps or overlaps after telephone-event (no telephone events with duration 117 ms which causes subsequent audio packet either start before the end of the telephone-event or with a 3 ms gap after the event or exactly after the telephone event but with 3 ms offset in comparison with audio packets before telephone events). Sorry for spending so much time on telephone-event generation but equipment generating broken telephone-event streams and then causing havoc in the phone network is something that is something that wasted couple of weeks of my time this month alone. I simply want to provide the list of recommendations for rtcweb which will cause the least amount of interop trouble in the future. Regards, _____________ Roman Shpount --001a11346410d01769052a54565e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Jan 27, 2016 at 12:17 PM, Jean-Marc Valin &l= t;jmvalin@mozilla.= com> wrote:
The problem I see is that unlike G.711, modern codecs (not just O= pus)
aren't stateless. It's not a simple thing to just stop and restart<= br> transmission during telephony events -- especially if you want to
avoid glitches and want all implementations to behave the same. You
need to consider look-ahead (6 ms for Opus, with 5-10 ms being
typical), but also the "memory" from the previous frame.

In this regard Opus is no different then G.729 = which was used with telephone-events for ages. Sending a telephone-event pa= cket is an audio codec switch. Its behavior should be no different then swi= tch from Opus to PCMU or from Opus to CN and back. I assume statefull codec= such as Opus should reset its state before starting to send audio after su= ch switch occurs. Is this correct? From what I know this was never defined = anywhere and it might be a good idea from the codec designers to specify wh= at is the best behavior for codec switches from telephone-event or CN. Sinc= e most of codecs converge very quickly I see this implemented equally often= with or without codec state reset. Also, since telephone-events are normal= ly followed by a period of silence (intertone gap), codec state plays much = smaller role in practice.

> Packet boundaries of audio encoded using codecs such as G.711 or=
> Opus should create a continuous stream as far as RTP timestamps are > concerned with RFC 4733 telephone event packets unless
> discontinuous RTP is used. It should be possible to align decoded
> audio and telephone-events based on RTP timestamps.

What do you mean "create a continuous stream"? I thought y= ou wanted
the codec to stop transmitting.

Yes, I = do want the code to stop transmitting. I want the clean codec switch from n= on-event audio codec to telephone-event and back. What I mean here is if yo= u have PCMU packet with timestamp 1000 and duration 160 the following telep= hone-event start timestamp should be 1160. The transition in other directio= n should also happen without the timestamp gap so that if telephone-event s= tart timestamp is 1160 and the total tone duration is 800 then next non eve= nt audio packet should start with timestamp 1960. Furthermore, I like to re= commend to switch from non-event to telephone-event and back on the regular= packet boundary. This means no partial audio packets (17 ms audio packet b= efore telephone event) and no gaps or overlaps after telephone-event (no te= lephone events with duration 117 ms which causes subsequent audio packet ei= ther start before the end of the telephone-event or with a 3 ms gap after t= he event or exactly after the telephone event but with 3 ms offset in compa= rison with audio packets before telephone events).

Sorry for spending so much time on telephone-event generation but equipmen= t generating broken telephone-event streams and then causing havoc in the p= hone network is something that is something that wasted couple of weeks of = my time this month alone. I simply want to provide the list of recommendati= ons for rtcweb which will cause the least amount of interop trouble in the = future.

Regards,
_____________
Roman Shpount
=C2=A0
--001a11346410d01769052a54565e-- From nobody Wed Jan 27 15:54:57 2016 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 1D1981B3934 for ; Wed, 27 Jan 2016 15:54:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 BHQUCNpnUPRm for ; Wed, 27 Jan 2016 15:54:55 -0800 (PST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6E0C1A92AF for ; Wed, 27 Jan 2016 15:54:54 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 30C5B218CB for ; Wed, 27 Jan 2016 18:54:54 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute3.internal (MEProxy); Wed, 27 Jan 2016 18:54:54 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h= content-type:date:from:message-id:mime-version:subject:to :x-sasl-enc:x-sasl-enc; s=mesmtp; bh=msnSNvbWBbKRE4SobQiVCZeM3NY =; b=v7XRMo20W3kcUWMvmZ+vB8HBMHoAv+x096CVamTZ18zK3FLyemS2/k3RFTi E16S9hrSI93UDb49jgAo05AZPBg9IerT+odckX8+D00xLTQGzBx9v3v9tis7ys9L AGku9bpcW/L6hBVSfRyv3Mpwy6PdglHv/wQvNaI0j+faV1lc= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=ms nSNvbWBbKRE4SobQiVCZeM3NY=; b=XY99FDrFwxmNC+N6VUIetBkCsgWjL1KM9c KJsQ7HGue0kWPnmXMqmzB55EtNINaBYEKn7BhAeH/3GguIzUWVawC0Sy/dfd95yY A5Lk07pcczUB8FoqgNUVbOd41lKhQDX0cnZUNg52WWq/GJ5FScIwOPFWpQqOQhUF i7Yl71tu0= X-Sasl-enc: /QIbnR/I54Ee/4lfI6UU2t48PgrX92eI4EKxXUwQxXLr 1453938893 Received: from dhcp-171-68-20-84.cisco.com (dhcp-171-68-20-84.cisco.com [171.68.20.84]) by mail.messagingengine.com (Postfix) with ESMTPA id C02BE6800F3 for ; Wed, 27 Jan 2016 18:54:53 -0500 (EST) From: Alissa Cooper Content-Type: multipart/alternative; boundary="Apple-Mail=_822DFCE6-D04E-4CE8-92B3-217FECEBCA79" Message-Id: <0699FDB2-DD89-4DAB-8DA9-B0512F364571@cooperw.in> Date: Wed, 27 Jan 2016 15:54:52 -0800 To: rtcweb@ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) Archived-At: Subject: [rtcweb] AD evaluation: draft-ietf-rtcweb-audio-09 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: Wed, 27 Jan 2016 23:54:56 -0000 --Apple-Mail=_822DFCE6-D04E-4CE8-92B3-217FECEBCA79 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I have reviewed this document in preparation for IETF LC. The document = is loose with terminology =E2=80=94 =E2=80=9CWebRTC endpoint = implementations,=E2=80=9D =E2=80=9CWebRTC endpoints,=E2=80=9D =E2=80=9Cthe= browser,=E2=80=9D "WebRTC compatible endpoints,=E2=80=9D etc. I think = this document needs to reference draft-ietf-rtcweb-overview and = consistently use the terminology defined there (or, if not, explain why = not). Once those changes are made, I believe this document will be ready = for last call. Alissa= --Apple-Mail=_822DFCE6-D04E-4CE8-92B3-217FECEBCA79 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I have reviewed this document in preparation for IETF LC. = The document is loose with = terminology =E2=80=94 =E2=80=9CWebRTC endpoint implementations,=E2=80=9D = =E2=80=9CWebRTC endpoints,=E2=80=9D =E2=80=9Cthe browser,=E2=80=9D = "WebRTC compatible endpoints,=E2=80=9D etc. I think this document needs to = reference draft-ietf-rtcweb-overview and consistently use the = terminology defined there (or, if not, explain why not). Once those = changes are made, I believe this document will be ready for last = call.

Alissa
= --Apple-Mail=_822DFCE6-D04E-4CE8-92B3-217FECEBCA79-- From nobody Wed Jan 27 15:55:03 2016 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 C0EE61B393F for ; Wed, 27 Jan 2016 15:55:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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 oJ_tmWbfOWr5 for ; Wed, 27 Jan 2016 15:55:01 -0800 (PST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F04E1B393E for ; Wed, 27 Jan 2016 15:55:01 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 5090A218E5 for ; Wed, 27 Jan 2016 18:55:00 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute3.internal (MEProxy); Wed, 27 Jan 2016 18:55:00 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h= content-transfer-encoding:content-type:date:from:message-id :mime-version:subject:to:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=IlN U/FIRTbxrdbtvK48SMMlDSvQ=; b=acrX2xIc0+4DF6BNSSo2BfGUJCFhIk0KrdK cJFU+1KBGjRVVD1uPeO8UySJ5X/U72IyDS6aj/YXfJGgAHxwaMrtv2402EOlNCJq BmooJq/bDRQkWvDzBFSjuiag6isuNfhMCe/8KVBeYXuUeayZXEl6quCkpo8ryre2 O8R7fgHY= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=IlNU/FIRTbxrdbtvK48SMMlDSvQ=; b=Ksz99 At2pdWa6p+N4ClFClNzw03ZxFSNppzYsYUIJ+D9kvAOAbxLJwlsr+io0Rrc76g97 mmogo9xYBz9dHkMj7PcW1b2M3ZdKGanO2MU+bpsTflFntuhsCyVwc9BN+0/OKNr+ r0CMu/6vXVlnz3FZvmzGHP13xowjhpCVn3AnqQ= X-Sasl-enc: EXkl8lO4TDfq21Y64I2q1gg3b3YP25JlQuB0uQ10WCEE 1453938899 Received: from dhcp-171-68-20-84.cisco.com (dhcp-171-68-20-84.cisco.com [171.68.20.84]) by mail.messagingengine.com (Postfix) with ESMTPA id C489668014A for ; Wed, 27 Jan 2016 18:54:59 -0500 (EST) From: Alissa Cooper Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <36299A4C-DEF7-4A4A-9CC2-0D9AC1BFCE47@cooperw.in> Date: Wed, 27 Jan 2016 15:54:59 -0800 To: rtcweb@ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) Archived-At: Subject: [rtcweb] AD evaluation: draft-ietf-rtcweb-audio-codecs-for-interop-04 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: Wed, 27 Jan 2016 23:55:02 -0000 I have reviewed this document in preparation for IETF LC. I have a few = substantive comments that need to be resolved for IETF LC. I=E2=80=99ve = also included some nits below that should be resolved together with LC = comments. Substantive comments: (1) Typically when a long author list gets shifted to the = Acknowledgments section the remaining name at the top get marked as an = editor. That seems appropriate in this case. (2) The document uses the term =E2=80=9CWebRTC client=E2=80=9D in a few = places. I would suggest referencing the terminology defined in = draft-ietf-rtcweb-overview regarding endpoints/devices/browsers and = consistently using the terminology defined there (or, if not, explain = why not). (3) The claims throughout Section 4 about the number of terminals = affected sound like marketing. Wanted to check if the WG is confident = that these claims need to be in the document. (4) Section 4.4 seems superfluous and should be deleted. Nits: =3D Section 1 =3D s/to include in the offer other suitable audio codecs/to include in the = offer other suitable audio codecs beyond those that are mandatory to = implement/ =3D Section 5 =3D s/to also report more specifically/to also refer more specifically/ From nobody Thu Jan 28 03:08:41 2016 Return-Path: X-Original-To: rtcweb@ietf.org Delivered-To: rtcweb@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C63B1B3B8A; Thu, 28 Jan 2016 03:08:39 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160128110839.8817.92489.idtracker@ietfa.amsl.com> Date: Thu, 28 Jan 2016 03:08:39 -0800 Archived-At: Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-transports-11.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 28 Jan 2016 11:08:39 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Real-Time Communication in WEB-browsers Working Group of the IETF. Title : Transports for WebRTC Author : Harald Alvestrand Filename : draft-ietf-rtcweb-transports-11.txt Pages : 16 Date : 2016-01-28 Abstract: This document describes the data transport protocols used by WebRTC, including the protocols used for interaction with intermediate boxes such as firewalls, relays and NAT boxes. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-transports/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-rtcweb-transports-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-transports-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jan 28 03:16:52 2016 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 D537B1B3BAC for ; Thu, 28 Jan 2016 03:16:50 -0800 (PST) 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, RP_MATCHES_RCVD=-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 IPSdGxeFIdev for ; Thu, 28 Jan 2016 03:16:48 -0800 (PST) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id 8A5BB1B3BA8 for ; Thu, 28 Jan 2016 03:16:48 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 764817C6943 for ; Thu, 28 Jan 2016 12:16:47 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O-2k7N2OJrI2 for ; Thu, 28 Jan 2016 12:16:46 +0100 (CET) Received: from [IPv6:2001:470:de0a:1:51ca:7a92:c762:e9f3] (unknown [IPv6:2001:470:de0a:1:51ca:7a92:c762:e9f3]) by mork.alvestrand.no (Postfix) with ESMTPSA id 809FD7C679B for ; Thu, 28 Jan 2016 12:16:46 +0100 (CET) To: "rtcweb@ietf.org" References: <20160128110839.8817.92489.idtracker@ietfa.amsl.com> From: Harald Alvestrand Message-ID: <56A9F89D.8010506@alvestrand.no> Date: Thu, 28 Jan 2016 12:16:45 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <20160128110839.8817.92489.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-transports-11.txt 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: Thu, 28 Jan 2016 11:16:51 -0000 The main change in this version is to define the terms "data flow" and "media flow", which are referenced by the -qos draft that is about to be submitted for publication. This version closes both open issues I had in github (https://github.com/rtcweb-wg/rtcweb-transport/issues). Harald Den 28. jan. 2016 12:08, skrev internet-drafts@ietf.org: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Real-Time Communication in WEB-browsers Working Group of the IETF. > > Title : Transports for WebRTC > Author : Harald Alvestrand > Filename : draft-ietf-rtcweb-transports-11.txt > Pages : 16 > Date : 2016-01-28 > > Abstract: > This document describes the data transport protocols used by WebRTC, > including the protocols used for interaction with intermediate boxes > such as firewalls, relays and NAT boxes. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-transports/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-rtcweb-transports-11 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-transports-11 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > From nobody Thu Jan 28 12:05:54 2016 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 40BC61ACDE1 for ; Thu, 28 Jan 2016 12:05:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.378 X-Spam-Level: X-Spam-Status: No, score=-0.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_15=0.6, MIME_8BIT_HEADER=0.3] autolearn=no 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 P2pLOnDv27KD for ; Thu, 28 Jan 2016 12:05:51 -0800 (PST) Received: from mail-yk0-x230.google.com (mail-yk0-x230.google.com [IPv6:2607:f8b0:4002:c07::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF9D21ACDB2 for ; Thu, 28 Jan 2016 12:05:51 -0800 (PST) Received: by mail-yk0-x230.google.com with SMTP id a85so44392059ykb.1 for ; Thu, 28 Jan 2016 12:05:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to:content-type :content-transfer-encoding; bh=G2aFtvEo/kWspA8LX/l8Yqp13EvBjoo9+QsJjF9cVF4=; b=Cxj07cBKOVa4+N9ILl/DWFC8ulkF0Uu2dr4cJQw6frgGebspDi09yYt4popFj89KET 0lotmqZ+9sBf8J5tB4NUWdLV0K3Qr0uEyjD2tw4QJnTV2VPsFRMhrEDtCpBB5cd5cizj MuCXz+2RloI5sQ7YaT4RckE5otGyEVr/fKHWwlQQkE7ciGDHvzXEPRhN3Q4HwRhipQTF n2cuNlCPl2hg62bgrWmfrBejPJoseDhWpFB53lrJE0QbZ+eOuOG1oi3l35fNNPf5oB4Z WekqK+r/yVLhuow6KwTJSa1gwdLoCLQ7tkFDpTh53GM2Exkzjk+/EQiXKUTleE3moh77 YbGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type:content-transfer-encoding; bh=G2aFtvEo/kWspA8LX/l8Yqp13EvBjoo9+QsJjF9cVF4=; b=Ur+apSz9lfSToN56nMsVtyH/gDs1ENhzJ5BPd65FRF6+3NvJ8uTeuWa0p80tu2yAZn 5xRRw9QdCgoc64NTv7wyflsRknGKgHHvFGAHW0W27hXzdjPnQBdxMTpCpcjDFWJA8zlK miqKzSM1zkqd7CdN3D7/1Z536kVmzT62OBEbSaDDezfMVhmRpophWTbeCwkzK2fjVlmN 9horZRM/J67c4bv4E1/+d3C6bj6CzMn9ZaD33uTYHeN66td1cdVGbDhSqTDLvMx8De63 fcXxMKtY+h92RKR/0u6+06BzONqLN6HC39kRDvTWyBu9wbhJ86B9MoWf+ZINNG3Ve7KW JzUQ== X-Gm-Message-State: AG10YOSgapGf0Vs3uB3dfEkEz/y+ucZ3y5Rar22DUYpfzFx3otZ3eFTw5iwcCXd2CwzBSOD4m4FeF78+QveOjg== X-Received: by 10.37.41.139 with SMTP id p133mr2687752ybp.178.1454011551028; Thu, 28 Jan 2016 12:05:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.88.136 with HTTP; Thu, 28 Jan 2016 12:05:31 -0800 (PST) From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Thu, 28 Jan 2016 21:05:31 +0100 Message-ID: To: "rtcweb@ietf.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [rtcweb] Plan B and SDP with different payload numbers pointing to the same codec 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: Thu, 28 Jan 2016 20:05:53 -0000 Hi, In Plan B [*] if a SFU receives VP8 tracks from 3 peers, using each peer a different SSRC and payload type/number: Can the SFU generate a SDP containing a single m=3Dvideo line with 3 different payload numbers pointing to the same VP8 codec? The draft seems to assume that the SFU/server will translate/override the payloadType of the incoming sources and make them the same. Thanks a lot. [*] https://tools.ietf.org/html/draft-uberti-rtcweb-plan-00 --=20 I=C3=B1aki Baz Castillo From nobody Thu Jan 28 13:28:07 2016 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 509031A9081 for ; Thu, 28 Jan 2016 13:28:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.001 X-Spam-Level: X-Spam-Status: No, score=-1.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.001] autolearn=no 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 5-Qz-1G1CHR4 for ; Thu, 28 Jan 2016 13:28:05 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 700491A907F for ; Thu, 28 Jan 2016 13:28:05 -0800 (PST) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u0SLS3tk057075 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 28 Jan 2016 15:28:04 -0600 (CST) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local To: =?UTF-8?Q?I=c3=b1aki_Baz_Castillo?= , "rtcweb@ietf.org" References: From: Adam Roach Message-ID: <56AA87E3.50303@nostrum.com> Date: Thu, 28 Jan 2016 15:28:03 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [rtcweb] Plan B and SDP with different payload numbers pointing to the same codec 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: Thu, 28 Jan 2016 21:28:06 -0000 Um... the working group decided not to move forward with this mechanism. I'm not sure it was ever fully formed enough to be able answer your question. Put another way: you're implementing a non-standard solution. Interoperability is a matter of between you and other people wanting to implement your proprietary approach. /a On 1/28/16 14:05, Iñaki Baz Castillo wrote: > Hi, > > In Plan B [*] if a SFU receives VP8 tracks from 3 peers, using each > peer a different > SSRC and payload type/number: Can the SFU generate a SDP containing a > single m=video line with 3 different payload numbers pointing to the > same VP8 codec? > > The draft seems to assume that the SFU/server will translate/override > the payloadType of the incoming sources and make them the same. > > Thanks a lot. > > > [*] https://tools.ietf.org/html/draft-uberti-rtcweb-plan-00 > From nobody Thu Jan 28 13:34:51 2016 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 9AE231A90A6 for ; Thu, 28 Jan 2016 13:34:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3] autolearn=no 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 1DNwhSkD3-8O for ; Thu, 28 Jan 2016 13:34:47 -0800 (PST) Received: from mail-yk0-x230.google.com (mail-yk0-x230.google.com [IPv6:2607:f8b0:4002:c07::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB8F01A90A3 for ; Thu, 28 Jan 2016 13:34:47 -0800 (PST) Received: by mail-yk0-x230.google.com with SMTP id v14so47078722ykd.3 for ; Thu, 28 Jan 2016 13:34:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=Tf2KHHkGQvtRYJso1kgnxFkjPRCdQua5c82FMl/5cQI=; b=eia2q8p/rUSqPQxq5pC+8sSr5y33lZnC+upkiOCEJkoA3DdAoF25NpQYie4gzLbq8E c5SdmCGfX/un+VNu6CZJPRXS/WpM785S4lJ8uqjUQKn2kA8A8w2tGZMJSoxK2vVOyNE2 Z9Yfey6Mgk5vFOoK4+CJrmixRWxGbkQwpL6Rbl/s20jwIZsSi6dP0GaIGOJXi8/Ta3hV VJYZn5umNqXDf4wCfhANgIFe/WunyeB6P5TGOTe+QpfaJGrEAqNCSJC1QUO8WaVswg3F 9nwJYmISXrUZBNMIpuGCQ0dCKxMUPg4BfQ2bcMB3MqjqeEp2ID+4YNLsn4cwK2DJ6nf4 zDeg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=Tf2KHHkGQvtRYJso1kgnxFkjPRCdQua5c82FMl/5cQI=; b=DjDZCqs0RAwQYrWucvkmY8tSCBll6OxqoxbK+yln2c5uDivVFtiwGM1rJ91EHSLgw1 uNyxQVUvn0iQAXUoku3ShetWuqPcxCPTzzFI2PT0sXG5BSjirWx47jad03yt8JEIQsdb Rn4UAUYIoaJccNGAGVEL/NBEt2ENy9enF4aCn/SpousAJLkD+OMO/TH7q3ltsrCvp+Q4 sxMzznZx9IcpDdhTewaWVf685Qg498JAt7eMZUpW2YuuGarHIa2rG4/79kwjDwgFBfnJ cvLfNYUWIU33FrPBzgwGwZvFOgDQEmJ2hDuC/CZ6PBvgNlZfctEuL/l7qGnADEJs3iaD gT9Q== X-Gm-Message-State: AG10YOTGkrcich023fYLIDDw8evwMyfpydjH6fHdgV0Lw8LA/Avb63ZZ3ZflL+tD05BItoFLstAztZmZzj55fQ== X-Received: by 10.37.34.10 with SMTP id i10mr2905003ybi.101.1454016887033; Thu, 28 Jan 2016 13:34:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.88.136 with HTTP; Thu, 28 Jan 2016 13:34:27 -0800 (PST) In-Reply-To: <56AA87E3.50303@nostrum.com> References: <56AA87E3.50303@nostrum.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Thu, 28 Jan 2016 22:34:27 +0100 Message-ID: To: Adam Roach Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Plan B and SDP with different payload numbers pointing to the same codec 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: Thu, 28 Jan 2016 21:34:48 -0000 2016-01-28 22:28 GMT+01:00 Adam Roach : > Um... the working group decided not to move forward with this mechanism. = I'm > not sure it was ever fully formed enough to be able answer your question. > > Put another way: you're implementing a non-standard solution. > Interoperability is a matter of between you and other people wanting to > implement your proprietary approach. Hi Adam, I don't want Plan A, Plan B or Unified-Plan. But... SDP + Plan B is what current Google's libwebrtc implements so I need to interop with it. Said that, I agree that Plan B is an abandoned draft so I shouldn't expect a specific response to my question. Thanks a lot. --=20 I=C3=B1aki Baz Castillo From nobody Thu Jan 28 13:41:42 2016 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 9053B1A90B0 for ; Thu, 28 Jan 2016 13:41:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.079 X-Spam-Level: X-Spam-Status: No, score=-1.079 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no 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 9WYhvqaFmpQf for ; Thu, 28 Jan 2016 13:41:40 -0800 (PST) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 508731A908D for ; Thu, 28 Jan 2016 13:41:40 -0800 (PST) Received: by mail-oi0-x22b.google.com with SMTP id o124so35443637oia.3 for ; Thu, 28 Jan 2016 13:41:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Y4Dcl54b7DwNyngfhmEBxmYOtZuZPxnBbV3mjH5ShJs=; b=e3PNfi3NGEEczyl1LuL6GqJECdnshrOv3H3cJKqGg/QhiDZICYYB4zfCYHwf41PXo0 nEFS5LS2dOE4YoTzeb7s/Zp2erd3fTK1U/NQqp7fABVKgX0SBmBGZPOdjUhwydQV/dhM k+sADutR9dNgJC7Rt3nwX7lCejyvzjCuw6QBxszAKYddx9GLzFRt9Co2zOxpI4fWyll1 6Fh/qhPKVqEtlR0L2g8JUitvgExbvV22OjRWRDd1e8c9RUQhMG5p8RPOuiJdDjwqCla/ TE7CB+GmElRKBxRudrW8eQARS/8L0ic6LPQPSMphy7hHlXhn8k4snQ9mg6xVGNXGfcr9 PvaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=Y4Dcl54b7DwNyngfhmEBxmYOtZuZPxnBbV3mjH5ShJs=; b=QqI6fCTq1bO2D6Brsa6//955iHUkRGKxBkFa5f0dd8Oou3p1wDsovv6l0EXGoq+XBb O+bedKpU6QaHVuyPHHOP+bOSBB4uzFFA++t/LKQMQEYSXTrymGTOgybVwBFP1wwYUI// zP/8eH/AplwwAOOpb2psT1HpI3s3McvGwbQXikhOBEFJrh/3S+KY6oge2m2CHeXnZVIW oLXfZGpjnHcHEJRqJvhRXBPBalv9qur16ckE43Mi1p4qaGRSd6KwGPg4Ud0W7xRnhTyi PiEMPAZyxL5zAlNz9CHW6yW42NguxU2PfUubbVk9HcFwJGOFwF3tWJp3vnsFENY2vsj2 l5qg== X-Gm-Message-State: AG10YOQQtOqtXfpvg7nSgUMbI9qVz/rngysQrqsVT4mjJlBhlpv7AGe45UXPfRNnk29/iijTdz1xVSfRKOxgHFqh X-Received: by 10.202.216.133 with SMTP id p127mr3594207oig.136.1454017299670; Thu, 28 Jan 2016 13:41:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.202.226.205 with HTTP; Thu, 28 Jan 2016 13:41:00 -0800 (PST) In-Reply-To: References: <56AA87E3.50303@nostrum.com> From: Peter Thatcher Date: Thu, 28 Jan 2016 13:41:00 -0800 Message-ID: To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=001a113d616aa52bf1052a6bc861 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Plan B and SDP with different payload numbers pointing to the same codec 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: Thu, 28 Jan 2016 21:41:41 -0000 --001a113d616aa52bf1052a6bc861 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable This isn't the right form to talk about Plan B. Perhaps discuss-webrtc@googlegroups.com would be. On Thu, Jan 28, 2016 at 1:34 PM, I=C3=B1aki Baz Castillo wr= ote: > 2016-01-28 22:28 GMT+01:00 Adam Roach : > > Um... the working group decided not to move forward with this mechanism= . > I'm > > not sure it was ever fully formed enough to be able answer your questio= n. > > > > Put another way: you're implementing a non-standard solution. > > Interoperability is a matter of between you and other people wanting to > > implement your proprietary approach. > > Hi Adam, > > I don't want Plan A, Plan B or Unified-Plan. But... SDP + Plan B is > what current Google's libwebrtc implements so I need to interop with > it. > > Said that, I agree that Plan B is an abandoned draft so I shouldn't > expect a specific response to my question. > > Thanks a lot. > > -- > I=C3=B1aki Baz Castillo > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --001a113d616aa52bf1052a6bc861 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This isn't the right form to talk about Plan B.=C2= =A0 Perhaps discuss-webrtc@googlegroups.com=C2=A0would be.

On Thu, Jan 28, 2016 at 1:34 P= M, I=C3=B1aki Baz Castillo <ibc@aliax.net> wrote:
2016-01-28 22:28 GMT+01:00 Adam Roach <adam@nostrum.com>: > Um... the working group decided not to move forward with this mechanis= m. I'm
> not sure it was ever fully formed enough to be able answer your questi= on.
>
> Put another way: you're implementing a non-standard solution.
> Interoperability is a matter of between you and other people wanting t= o
> implement your proprietary approach.

Hi Adam,

I don't want Plan A, Plan B or Unified-Plan. But... SDP + Plan B is
what current Google's libwebrtc implements so I need to interop with it.

Said that, I agree that Plan B is an abandoned draft so I shouldn't
expect a specific response to my question.

Thanks a lot.

--
I=C3=B1aki Baz Castillo
<ibc@aliax.net>= ;

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

--001a113d616aa52bf1052a6bc861-- From nobody Fri Jan 29 11:11:03 2016 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 B23DC1B31E2 for ; Fri, 29 Jan 2016 11:11:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 P0_R6ruhRDWV for ; Fri, 29 Jan 2016 11:11:01 -0800 (PST) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3E141B31E1 for ; Fri, 29 Jan 2016 11:11:00 -0800 (PST) Received: by mail-qk0-x232.google.com with SMTP id o6so28236383qkc.2 for ; Fri, 29 Jan 2016 11:11:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=TsRy7ScdjXOZj3wXYxkWC/E9yJgvLk2CMVTJkPuy5/U=; b=Czi5H9Ut1kktKGNGOzWFo20cYEZuO4eDoW5JkGbF2yRUz6fEF3iHRsf6huAPRB1ymO lmHN9uBql8mENJ7lRThCBoYNzi8Y2NkxERVWBAX8j6m9Yj9eK2r0QNQPHLEglKopGVkN LjtZh02JXtY4yLhLBj3s4n9A+Tmgfif4Fwf0FF22QNlJZ8yFIqj7kpmEiepu+JXrzZs0 56eyIrHMMC2kKdLYsLv5LwQ6gm0JZ4Y/P2UJMGsFAJ7qMMpsRB5Wyi+QjH33x5VcTF4f obJ3tsYSCTpt4qMU9lIJABgI9RYC+xR1W+jPQzpFu+iIVWA0Dlx6lQCe/hPQR51Xh2VX MfXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=TsRy7ScdjXOZj3wXYxkWC/E9yJgvLk2CMVTJkPuy5/U=; b=DMPSgtz8nhevE1W5xon+e9q20nPcCgkodduxNwsh/CxgZjGhYdJnM/P5CZ6oEENeBn eOXOOIGquQgV3cwDpsFBVqqWd6DQyZkQIDzFQxEchjhzh3DLnBaAnrjrtqblmVl9X1yE 5m6gZD8PCgSTwxF2lhFxpLB6/5KZ14gwWqcUnitz8ZY/8Jpom6FwDrKcIlELVkCTPgVk MBgaP90/69zpLPvS2paPC/10+IARBveunw7K/UnBroVBoPsy9saxl3uids1Gkb3HMIqt w6/q+Qb8JY6kt9BQy6SzAQ6L7/VR3e5Js1NfRlgonc0eVUAyKYtiPfjgRsG18s99Vp24 TpHA== X-Gm-Message-State: AG10YOS7RtSAeRX0fZjoIUNc7ajwoDlwqsOO5ff0nl5vxjRI55WkHoEsfaLsr1xYEY0Cdb1oUgnnsyNh7a7A2w== X-Received: by 10.55.74.141 with SMTP id x135mr12689441qka.20.1454094660198; Fri, 29 Jan 2016 11:11:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.55.14.211 with HTTP; Fri, 29 Jan 2016 11:10:40 -0800 (PST) From: Ted Hardie Date: Fri, 29 Jan 2016 11:10:40 -0800 Message-ID: To: "rtcweb@ietf.org" , Sean Turner , Cullen Jennings Content-Type: multipart/alternative; boundary=001a114a7c6eb0e861052a7dcb04 Archived-At: Subject: [rtcweb] Doodle for Virtual Interim timing 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, 29 Jan 2016 19:11:02 -0000 --001a114a7c6eb0e861052a7dcb04 Content-Type: text/plain; charset=UTF-8 Howdy, The chairs have heard from the JSEP editor team that there is likely be to a new version of JSEP in early march. In order to make as much as progress as possible, we'd like to consider a two-hour virtual interim just after that to discuss the changes and look any further issues that need discussion at IETF 95. Below is a doodle poll for approximate timing: http://doodle.com/poll/tn2uavay8bhq4iwe Please fill it out if you would consider attending, and let the chairs know if there are concerns, thanks, Sean, Cullen, Ted --001a114a7c6eb0e861052a7dcb04 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Howdy,

The chairs have heard fr= om the JSEP editor team that there is likely be to a new version of JSEP in= early march.=C2=A0 In order to make as much as progress as possible, we= 9;d like to consider a two-hour virtual interim just after that to discuss = the changes and look any further issues that need discussion at IETF 95.=C2= =A0 Below is a doodle poll for approximate timing:

htt= p://doodle.com/poll/tn2uavay8bhq4iwe


Please fill it out if you would consider attending, an= d let the chairs know if there are concerns,

thanks,
Sean, Cullen, Ted
--001a114a7c6eb0e861052a7dcb04-- From nobody Sun Jan 31 15:50:04 2016 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 E44DB1A1F1D for ; Sun, 31 Jan 2016 15:50:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.6 X-Spam-Level: X-Spam-Status: No, score=-0.6 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 7L7t1700jNDd for ; Sun, 31 Jan 2016 15:50:01 -0800 (PST) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6985A1A1F02 for ; Sun, 31 Jan 2016 15:50:01 -0800 (PST) Received: by mail-io0-x231.google.com with SMTP id g73so140961232ioe.3 for ; Sun, 31 Jan 2016 15:50:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=NBXsBqq6eHI3hrv+EF/I1Mv/xjw3AeBlKwVX4/bAtdY=; b=fnO2bATaTFTV5ip2s6xz6QYXdC6Ssj2EBqXQokAq6Y604SDXoR6XrELeLdgrPfUEvY n7rcR8Uf9w8MfclWHMh+GpPQIzFSuDb4L/VrC6UJYwJXn8ZDRI5JYMIz0xA7odVMuJqW 7/V66lugkxhfnvWALslMmOvFhGfaeeYF7kJkf41gsWqlGEsH5LyhyK1DxE2fF0XKhc7G MNpHpkgbulANy90iLJbaxJVHUVShRLPkrR92fEwJ7zkwCKHpFANlyA3HYqzT8NLxZupo vXlDksNoi+ZcEzbiHY7JDw7gO4BKadujFZqc5fMykobZK7VTixMpt2Cv7bhMimedMsX4 wLgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=NBXsBqq6eHI3hrv+EF/I1Mv/xjw3AeBlKwVX4/bAtdY=; b=b12DytysFyXD12Wqi8Y5AKb5yF9tq+GPymugPi5gbARn2SRp2JgaUXoJjGxVAYVIWm C7FWyq2gVIsCYepLnlkJQBr5blSqZ4Ty2sPqKqxaXRbrgMz55PlHeh7hWbH7RUoG4vDs 48PALBK0fQJXn4IXc/plTaAIjnS1TvrZVTZa/24ts4K/p/Kcw/tJlER91yBPTocjYImU pvp90oQiUOv+9yaT/bCPIux69m0JH9q+fknldyJq1JlWEmU8JUfdFP57/k4NKfrID6q5 SuMyggIxPH5ta25ROKjRnk0EJNrcB5SkRRu8nrKdsJpofFzc9eaAHwAq1x2Xx4QTJGme 5+zQ== X-Gm-Message-State: AG10YOTNc/TOA4qpCI+bzR+dwcQ9IkqDZU7ltKLFSr2egOxzMflpBQ9fcKCwZUIBU7Yu/w6IHhzyWhfoMuAX5g== MIME-Version: 1.0 X-Received: by 10.107.16.153 with SMTP id 25mr3013354ioq.100.1454284200881; Sun, 31 Jan 2016 15:50:00 -0800 (PST) Received: by 10.36.149.130 with HTTP; Sun, 31 Jan 2016 15:50:00 -0800 (PST) In-Reply-To: References: Date: Mon, 1 Feb 2016 10:50:00 +1100 Message-ID: From: Martin Thomson To: Ted Hardie Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Cullen Jennings , "rtcweb@ietf.org" Subject: Re: [rtcweb] Doodle for Virtual Interim timing 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: Sun, 31 Jan 2016 23:50:03 -0000 On 30 January 2016 at 06:10, Ted Hardie wrote: > http://doodle.com/poll/tn2uavay8bhq4iwe I assume that in the absence of time zone information, this is Pacific Time. No? From nobody Sun Jan 31 17:02:14 2016 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 92D711A872B for ; Sun, 31 Jan 2016 17:02:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no 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 mQvEifkmKcLH for ; Sun, 31 Jan 2016 17:02:12 -0800 (PST) Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 548A21A872A for ; Sun, 31 Jan 2016 17:02:12 -0800 (PST) Received: by mail-vk0-x234.google.com with SMTP id e6so68398351vkh.2 for ; Sun, 31 Jan 2016 17:02:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5FXk0tk85O03dk3VQETsG5HsigNX0m0fQEuoE0EMlfA=; b=dlT0pM/6Wq2CKl+6dbOUWb0A2vsj41PSp0ntGjsivCvRAOFRTVP3PZJk+4Grg6oZ50 DBIDL7FZ80Di4iEW334Mz/pZgMvpQlQEs/Br7BDMCcS2e0rJMJm23+2pkH+NaA55m6FL GE1uGLLQG2D/s2zYEbBUsFOwiFVmufjQJ3mGnmCrbk6c69QccZ1jyvNq64Y2LYUl1k7E IJOme/b/KBVHjmwCtWUG9KtsQJzqSsd6EL2G3GKgk2huL1MDsJxYCVrOMCiy/taqMkPL NC5l62VtQ7FItNq07XZME9JuGM04nCHFrfbcMyLroG+NX2HFdQ3Xl7NMCZH6i58bq1JD UmFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=5FXk0tk85O03dk3VQETsG5HsigNX0m0fQEuoE0EMlfA=; b=K8nAKWHFbwRwgVGLDL26PhTInAetj6paYIAnzzjv9LEqkdQLiUi10j5GTcXGVs0tEj YzLQ86/6LkeAgBCPNoK6CHF349XlMbfV/cIPw1ELzO55DMLYnB82XmljFAWtiHE/nm+G WoSKbd8PhKm6YCtOathPbv7JgKoEPvhFm2qV9E9hbgCBBcg2a1vRwP5CH+C+IyZD4JWR 1A8zWYYK0AfZW4KMO+sKFWcD1/2dWhutG48e0AV854jUe6BRwxUnlrIjLc7CzeLZmzbX gAaBQPFgVwldDWFgNlkckYvLHYdgoLhieuI+CZ7o51XN+Uy0HySH+wlsSL/iuezO7x08 wvLQ== X-Gm-Message-State: AG10YOS0KDkbvLDicnxsoS67eEpgsG0F1NZHXB4CE1Gn7LgSIEzbFHO5pgtqZd28V/Mr7dZGvsbXwFRofYDQPg== MIME-Version: 1.0 X-Received: by 10.31.166.208 with SMTP id p199mr14301931vke.122.1454288531432; Sun, 31 Jan 2016 17:02:11 -0800 (PST) Received: by 10.31.94.209 with HTTP; Sun, 31 Jan 2016 17:02:11 -0800 (PST) In-Reply-To: References: Date: Sun, 31 Jan 2016 17:02:11 -0800 Message-ID: From: Suhas Nandakumar To: Martin Thomson Content-Type: multipart/alternative; boundary=001a11416fbc512957052aaaef92 Archived-At: Cc: Cullen Jennings , "rtcweb@ietf.org" Subject: Re: [rtcweb] Doodle for Virtual Interim timing 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: Mon, 01 Feb 2016 01:02:13 -0000 --001a11416fbc512957052aaaef92 Content-Type: text/plain; charset=UTF-8 That was my assumption looking at the offered slots :) On Sunday, January 31, 2016, Martin Thomson wrote: > On 30 January 2016 at 06:10, Ted Hardie > > wrote: > > http://doodle.com/poll/tn2uavay8bhq4iwe > > > I assume that in the absence of time zone information, this is Pacific > Time. No? > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --001a11416fbc512957052aaaef92 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable That was my assumption looking at the offered slots :)

On Sunday, Ja= nuary 31, 2016, Martin Thomson <martin.thomson@gmail.com> wrote:
On 30 January 2016 at 06:10, Ted Hardie <ted.ietf@g= mail.com> wrote:
> = http://doodle.com/poll/tn2uavay8bhq4iwe


I assume that in the absence of time zone information, this is Pacific Time= . No?

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb
--001a11416fbc512957052aaaef92--