From tim@phonefromhere.com Wed Aug 1 04:26:11 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8653021F863F for ; Wed, 1 Aug 2012 04:26:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bkmELIDibxeO for ; Wed, 1 Aug 2012 04:26:10 -0700 (PDT) Received: from zimbra.westhawk.co.uk (zimbra.westhawk.co.uk [192.67.4.167]) by ietfa.amsl.com (Postfix) with ESMTP id 5843521F8608 for ; Wed, 1 Aug 2012 04:26:10 -0700 (PDT) Received: from [192.168.0.34] (bau56-1-78-229-103-109.fbx.proxad.net [78.229.103.109]) by zimbra.westhawk.co.uk (Postfix) with ESMTP id 1027C37A905; Wed, 1 Aug 2012 12:35:08 +0100 (BST) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable References: <5016D714.4030908@digium.com> From: Tim Panton Mime-Version: 1.0 (1.0) In-Reply-To: <5016D714.4030908@digium.com> Message-Id: <31030B23-2924-402E-AD6A-2E0467C22882@phonefromhere.com> Date: Wed, 1 Aug 2012 12:33:21 +0200 To: "Kevin P. Fleming" X-Mailer: iPhone Mail (10A5355d) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Should we also make G.722 a mandatory to implement codec? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 01 Aug 2012 11:26:11 -0000 I (personally) am against making g711 or g722 MTI audio codecs. There are ne= twork environments where they will behave significantly worse than opus (in s= ilk mode). Neither codec will adapt to variable available bandwidth or cope w= ell with packet loss -as seen on the edge of wifi networks and on 3G network= s .=20 We should not be encouraging the use of legacy codecs by making them MTI.=20= When I mentioned H261 as a compromise MTI video codec, I was told that bette= r codecs existed and that we should adopt them. Same goes for audio.=20 Tim. =20 Sent from my iPhone On 30 Jul 2012, at 20:48, "Kevin P. Fleming" wrote: > On 07/30/2012 12:21 PM, Roman Shpount wrote: >> Should we consider adding G.722 as a mandatory to implement audio codec? >> It is low complexity and carries no royalty or license restrictions, it >> is very good quality for voice audio communications at the >> same bandwidths as G.711, and it is very widely implemented by the >> desktop IP phones. >=20 > I would certainly support making G.722 mandatory to implement. >=20 > --=20 > Kevin P. Fleming > Digium, Inc. | Director of Software Technologies > Jabber: kfleming@digium.com | SIP: kpfleming@digium.com | Skype: kpfleming= > 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA > Check us out at www.digium.com & www.asterisk.org > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From roman@telurix.com Wed Aug 1 08:24:18 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A17FF21F8905 for ; Wed, 1 Aug 2012 08:24:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.85 X-Spam-Level: X-Spam-Status: No, score=-2.85 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4BZyyWpEB3ZB for ; Wed, 1 Aug 2012 08:24:17 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 931A321F8904 for ; Wed, 1 Aug 2012 08:24:17 -0700 (PDT) Received: by pbbjt11 with SMTP id jt11so1286490pbb.31 for ; Wed, 01 Aug 2012 08:24:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=0swnYvJuT0tI+rBl1gR1BD2nY7I7JkwRQAUgLBMtJlM=; b=n8lbs74w8qAxULm+BQmcoIPwcP4lB7LeGbEyTPakBPNnBFzJvsaYlXVG4Vcp09vpKK hYTth+PVKVTRD+RDkfE80xnGddF45jlxBMbpIqTNKTdraGJ8jUZWWobksg7ni4b62eJa OhRGX999xVZEIBe7m5oA9hZ960buYL3HNdO850mAB29ZggkkP9Mn3YnHLpceUMrDGv9A gco4waD7LShswVju/gD7MrGSHQ7Mhm51rupsg7/SpABY850eQGoc93RyqKuonBSd7wHN s7xc4giYhN5ibxjiMGM6f4ua56JWAMNSlcCrwOTbvvwUkxTUwVGzAmF4wHkre8pNwY1V fFtQ== Received: by 10.68.235.236 with SMTP id up12mr52709036pbc.79.1343834657202; Wed, 01 Aug 2012 08:24:17 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by mx.google.com with ESMTPS id rz10sm2782715pbc.32.2012.08.01.08.24.16 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 01 Aug 2012 08:24:16 -0700 (PDT) Received: by pbbjt11 with SMTP id jt11so1286460pbb.31 for ; Wed, 01 Aug 2012 08:24:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.217.100 with SMTP id ox4mr52573893pbc.87.1343834655510; Wed, 01 Aug 2012 08:24:15 -0700 (PDT) Received: by 10.68.28.72 with HTTP; Wed, 1 Aug 2012 08:24:15 -0700 (PDT) In-Reply-To: <31030B23-2924-402E-AD6A-2E0467C22882@phonefromhere.com> References: <5016D714.4030908@digium.com> <31030B23-2924-402E-AD6A-2E0467C22882@phonefromhere.com> Date: Wed, 1 Aug 2012 11:24:15 -0400 Message-ID: From: Roman Shpount To: Tim Panton Content-Type: multipart/alternative; boundary=e89a8ff245df474fdf04c635e3c8 X-Gm-Message-State: ALoCoQnRX3WdFDAB8fcY7KQS9LJ4PQd+gA7bvdOjDFl833e+PlXlV03FXV0HGudcbuZoMmetCg8d Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Should we also make G.722 a mandatory to implement codec? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 01 Aug 2012 15:24:18 -0000 --e89a8ff245df474fdf04c635e3c8 Content-Type: text/plain; charset=ISO-8859-1 I personally think it would be a mistake not to require G.711 and G.722. Even though OPUS can be better under some circumstances, it is much more expensive to encode, has no deployed base, and might proof to be patent encumbered. The CPU resources to encode or transcode to OPUS are several orders of magnitude more then for G.711 and G.722. If we need to communicate with legacy equipment, the cost to transcode from OPUS to G.711 or G.722 might be prohibitive. Also, if we need to transcode to other low bitrate codecs, such as AMR, it would require half the resources to transcode between G.722 and AMR vs OPUS and AMR. Even though OPUS is supposed to be an unencumbered codec, it is not unfeasible for some party to step forward and claim intellectual property rigts that OPUS is using. In this case we might have no recourse but to pay royalties. G.711 and G.722 are guaranteed not to be encumbered in any way since they been in use long enough for any IP claims to expire. Finally, OPUS is still in a draft phase, so there is no or little deployment experience with it. We might still discover things that will negatively affect it in some way. G.711 and G.722 are very widely deployed and all the issues related to it are well known. In a lot of cases they are simply good enough. P.S. This is in no way an argument against OPUS. I think we should make it mandatory and hope for the best, but I think we should also have easy to implement, widely deployed, unencumbered codecs supported as well. _____________ Roman Shpount On Wed, Aug 1, 2012 at 6:33 AM, Tim Panton wrote: > I (personally) am against making g711 or g722 MTI audio codecs. There are > network environments where they will behave significantly worse than opus > (in silk mode). Neither codec will adapt to variable available bandwidth or > cope well with packet loss -as seen on the edge of wifi networks and on 3G > networks . > > We should not be encouraging the use of legacy codecs by making them MTI. > > When I mentioned H261 as a compromise MTI video codec, I was told that > better codecs existed and that we should adopt them. Same goes for audio. > > Tim. > > Sent from my iPhone > > On 30 Jul 2012, at 20:48, "Kevin P. Fleming" wrote: > > > On 07/30/2012 12:21 PM, Roman Shpount wrote: > >> Should we consider adding G.722 as a mandatory to implement audio codec? > >> It is low complexity and carries no royalty or license restrictions, it > >> is very good quality for voice audio communications at the > >> same bandwidths as G.711, and it is very widely implemented by the > >> desktop IP phones. > > > > I would certainly support making G.722 mandatory to implement. > > > > -- > > Kevin P. Fleming > > Digium, Inc. | Director of Software Technologies > > Jabber: kfleming@digium.com | SIP: kpfleming@digium.com | Skype: > kpfleming > > 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA > > Check us out at www.digium.com & www.asterisk.org > > _______________________________________________ > > 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 > --e89a8ff245df474fdf04c635e3c8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I personally think it would be a mistake not to require G.711 and G.722. Ev= en though OPUS can be better under some circumstances, it is much more expe= nsive to encode, has no deployed base, and might proof to be patent encumbe= red.

The CPU resources to encode or transcode to OPUS are several orders of = magnitude more then for G.711 and G.722. If we need to communicate with leg= acy equipment, the cost to transcode from OPUS to G.711 or G.722 might be p= rohibitive. Also, if we need to transcode to other low bitrate codecs, such= as AMR, it would require half the resources to transcode between G.722 and= AMR vs OPUS and AMR.

Even though OPUS is supposed to be an unencumbered codec, it is not unf= easible for some party to step forward and claim intellectual property rigt= s that OPUS is using. In this case we might have no recourse but to pay roy= alties. G.711 and G.722 are guaranteed not to be encumbered in any way sinc= e they been in use long enough for any IP claims to expire.

Finally, OPUS is still in a draft phase, so there is no or little deplo= yment experience with it. We might still discover things that will negative= ly affect it in some way. G.711 and G.722 are very widely deployed and all = the issues related to it are well known. In a lot of cases they are simply = good enough.

P.S. This is in no way an argument against OPUS. I think we should make= it mandatory and hope for the best, but I think we should also have easy t= o implement, widely deployed, unencumbered codecs supported as well.
_____________
Roman Shpount


On Wed, Aug 1, 2012 at 6:33 AM, Tim Pant= on <tim@phonefromhere.com> wrote:
I (personally) am against making g711 or g722 MTI audio codecs. There are n= etwork environments where they will behave significantly worse than opus (i= n silk mode). Neither codec will adapt to variable available bandwidth or c= ope well with packet loss -as seen on the edge of wifi networks and on 3G n= etworks .

We should not be encouraging the use of legacy codecs by making them MTI.
When I mentioned H261 as a compromise MTI video codec, I was told that bett= er codecs existed and that we should adopt them. Same goes for audio.

Tim.

Sent from my iPhone

On 30 Jul 2012, at 20:48, "Kevin P. Fleming" <kpfleming@digium.com> wrote:

> On 07/30/2012 12:21 PM, Roman Shpount wrote:
>> Should we consider adding G.722 as a mandatory to implement audio = codec?
>> It is low complexity and carries no royalty or license restriction= s, it
>> is very good quality for voice audio communications at the
>> same bandwidths as G.711, and it is very widely implemented by the=
>> desktop IP phones.
>
> I would certainly support making G.722 mandatory to implement.
>
> --
> Kevin P. Fleming
> Digium, Inc. | Director of Software Technologies
> Jabber: kfleming@digium.com= | SIP: kpfleming@digium.com | = Skype: kpfleming
> 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
> Check us out at ww= w.digium.com & www.asterisk.org
> _______________________________________________
> 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

--e89a8ff245df474fdf04c635e3c8-- From mandyam@quicinc.com Tue Jul 31 11:05:11 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8046D21F873B for ; Tue, 31 Jul 2012 11:05:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.489 X-Spam-Level: X-Spam-Status: No, score=-5.489 tagged_above=-999 required=5 tests=[AWL=1.109, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lPtV2Ha-+Ib5 for ; Tue, 31 Jul 2012 11:05:09 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by ietfa.amsl.com (Postfix) with ESMTP id E5E3921F873A for ; Tue, 31 Jul 2012 11:05:08 -0700 (PDT) X-IronPort-AV: E=McAfee;i="5400,1158,6789"; a="216415396" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by wolverine01.qualcomm.com with ESMTP; 31 Jul 2012 11:05:09 -0700 X-IronPort-AV: E=Sophos;i="4.77,688,1336374000"; d="scan'208,217";a="356805720" Received: from nasanexhc11.na.qualcomm.com ([172.30.39.6]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 31 Jul 2012 11:05:09 -0700 Received: from NASANEXD01H.na.qualcomm.com ([169.254.8.4]) by nasanexhc11.na.qualcomm.com ([172.30.39.6]) with mapi id 14.02.0309.002; Tue, 31 Jul 2012 11:05:08 -0700 From: "Mandyam, Giridhar" To: Harald Alvestrand , "rtcweb@ietf.org" Thread-Topic: [rtcweb] RTCWeb Data Stream and RTP Synchronization - new I.-D. Thread-Index: Ac1uhw6a/JJcvNvQQAOvCTbyQufuQQA6aoiAAAuaWsA= Date: Tue, 31 Jul 2012 18:05:07 +0000 Message-ID: References: <501801DB.3030600@alvestrand.no> In-Reply-To: <501801DB.3030600@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [199.106.115.219] Content-Type: multipart/alternative; boundary="_000_CAC8DBE4E9704C41BCB290C2F3CC921A1627D557nasanexd01hnaqu_" MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 01 Aug 2012 10:12:34 -0700 Subject: Re: [rtcweb] RTCWeb Data Stream and RTP Synchronization - new I.-D. X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 31 Jul 2012 18:05:11 -0000 --_000_CAC8DBE4E9704C41BCB290C2F3CC921A1627D557nasanexd01hnaqu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Harald, Thanks for your feedback. Our intention was to leverage the latest Editor'= s Draft of the WebRTC API as is. This should have been stated more clearly= in the I.-D. - I apologize. Therefore JS does not have access to timestamp data in RTP (AFAICT) with th= e current PeerConnection API. Ergo for application-generated data, a JS me= chanism such as Date().getTime() could be used to embed timestamp data with= in the application data sent over SCTP. This is far from perfect and does = not provide perfect synchronization to an accompanying RTP stream. We were not intending to extend the data channel mechanism as defined by I-= D.-jesup-rtcweb-data-protocol to include timestamp data, if that is what yo= u were referring to. I'm not sure that solves the problem either, because = there are no guarantees that such a mechanism would leverage the same times= tamp generation as the RTP stream would. We feel that the best way to assure tight synchronization between the RTP s= tream and any opaque data is through the RTP extension header. -Giri From: rtcweb-bounces@ietf.org [mailto:rtcwe= b-bounces@ietf.org] On Behalf Of H= arald Alvestrand Sent: Tuesday, July 31, 2012 9:04 AM To: rtcweb@ietf.org Subject: Re: [rtcweb] RTCWeb Data Stream and RTP Synchronization - new I.-D= . On 07/30/2012 12:11 PM, Mandyam, Giridhar wrote: Hello, Please note the internet draft recently uploaded: http://tools.ietf.org/ht= ml/draft-mandyam-rtcweb-data-synch-00 entitled "RTCWeb Data Stream and RTP = Synchronization." All comments, suggestions, requests for clarification, = corrections are welcome. Hello - I scanned your draft quickly, and I see a lot of talk about signali= ng that synchronization between data tracks and RTP tracks is requested, bu= t nothing about how you intended to represent timestamps in SCTP. Could you clarify what timestamps you intended to synchronize? Harald Thanks, -Giri Mandyam, Qualcomm Innovation Center _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --_000_CAC8DBE4E9704C41BCB290C2F3CC921A1627D557nasanexd01hnaqu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Harald,

Thanks for your feedback.=   Our intention was to leverage the latest Editor’s Draft of the= WebRTC API as is.  This should have been stated more clearly in the I.-D. – I apologize.

 <= /p>

Therefore JS does not hav= e access to timestamp data in RTP (AFAICT) with the current PeerConnection = API.  Ergo for application-generated data, a JS mechanism such as Date().getTime() could be used to embed timestamp data within the = application data sent over SCTP.  This is far from perfect and does no= t provide perfect synchronization to an accompanying RTP stream.=

 <= /p>

We were not intending to = extend the data channel mechanism as defined by I-D.-jesup-rtcweb-data-prot= ocol to include timestamp data, if that is what you were referring to.  I’m not sure that solves the problem either, bec= ause there are no guarantees that such a mechanism would leverage the same = timestamp generation as the RTP stream would.

 <= /p>

We feel that the best way= to assure tight synchronization between the RTP stream and any opaque data= is through the RTP extension header.

 <= /p>

-Giri

 <= /p>

From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Harald Alvestrand<= br> Sent: Tuesday, July 31, 2012 9:04 AM
To: rtcweb@ietf.org
Subject: Re: [rtcweb] RTCWeb Data Stream and RTP Synchronization - n= ew I.-D.

 

On 07/30/2012 12:11 PM, Mandyam, Giridhar wrote:

Hello,<= /p> 

Please note the internet draft recently upl=
oaded:  http://tools.ietf.org/html/draft-mandyam-rt=
cweb-data-synch-00 entitled “RT=
CWeb Data Stream and RTP Synchronization.“   All comments, =
suggestions, requests for clarification, corrections are welcome.
 

Hello - I scanned your draft quickly, and I see a lo= t of talk about signaling that synchronization between data tracks and RTP = tracks is requested, but nothing about how you intended to represent timest= amps in SCTP.

Could you clarify what timestamps you intended to synchronize?

            &nb= sp;    Harald


Thanks,
-Giri Mandyam, Qualcomm Innovation Center




_______________________________________________
rtcweb mailing list
rtcweb@ietf.org

https://www.i=
etf.org/mailman/listinfo/rtcweb


 
--_000_CAC8DBE4E9704C41BCB290C2F3CC921A1627D557nasanexd01hnaqu_-- From miguelecasassanchez@gmail.com Thu Aug 2 06:01:13 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E89B21F84EB for ; Thu, 2 Aug 2012 06:01:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id agtBf6Vskgwa for ; Thu, 2 Aug 2012 06:01:12 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 45E4521F84E4 for ; Thu, 2 Aug 2012 06:01:10 -0700 (PDT) Received: by weyu54 with SMTP id u54so6588393wey.31 for ; Thu, 02 Aug 2012 06:01:09 -0700 (PDT) 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=s7mIbpeWn8F0xbF0nBZwc1LgYu+7PSRufVv0d91Qb5A=; b=SccnZv/tnFWrNAEh0yxDJamJum6tC6mDftZm8o3CsxVacCwORbbeUuLe2Bc+FpQ6Cq ft8wLw21w16obMGhCrKyyaYOcW0xktrVdPv0iaVzgl17xoQuMtwzqkxUAxk8p95InDzX h/UHKqinXdG9rer0uIdivunsBQ+R77b+n5s5q8hH/ra3SG/MJ5Vvoi5AEjPs2ShmTyG/ Hme/e8Un3Gf/qjZ304izer2bm884oyKyudjm4swYNwwURcvNLJiXgB2W5B/ZDdFDnGcD 0uRG7gDW61vt9eYR4u7I2z6VH+qGTiSoKHEYSrMb1E/b5Wsvkf/AoQIRSreHK5dgDkPi 7Pqw== MIME-Version: 1.0 Received: by 10.180.83.106 with SMTP id p10mr4532151wiy.21.1343912463612; Thu, 02 Aug 2012 06:01:03 -0700 (PDT) Received: by 10.216.141.150 with HTTP; Thu, 2 Aug 2012 06:01:03 -0700 (PDT) In-Reply-To: <3425F545-99A6-4CAD-8ECD-E888275A27DD@apple.com> References: <5015D506.5010201@mozilla.com> <5015E6FF.2000804@reavy.org> <5015FBE7.9060809@thaumas.net> <501640E3.1000009@jesup.org> <3425F545-99A6-4CAD-8ECD-E888275A27DD@apple.com> Date: Thu, 2 Aug 2012 15:01:03 +0200 Message-ID: From: Miguel Casas-Sanchez To: David Singer Content-Type: text/plain; charset=ISO-8859-1 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Google statement on codecs X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 02 Aug 2012 13:01:13 -0000 You can count on a +1 from me, for what matters. I agree on the base statement, but what's more important, I've seen what happens if you follow down the licesing/royalty way of ITU and the likes, or, like some of us call here, the lawyer's way... I bet we all know a bit what's this about. M On 1 August 2012 00:12, David Singer wrote: > > On Jul 30, 2012, at 1:08 , Randell Jesup wrote: > >> On 7/29/2012 8:13 PM, Ralph Giles wrote: >>> On 12-07-29 6:44 PM, Maire Reavy wrote: >>> >>>> Mandating encumbered codecswould force open-source projects to violate >>>> the spec (by not implementing a mandatory codec). For this reason and >>>> the reasons Justin cites, we believe Opus, G.711 and VP8 are the best >>>> mandatory-to-implement choices for the spec. >>> +1 >> > > There are open-source implementations of encumbered codecs (e.g. x264); and I expect that there are proprietary codecs that are believed to be unencumbered :-). Let's not confuse the two classes. > > David Singer > Multimedia and Software Standards, Apple Inc. > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From dwing@cisco.com Thu Aug 2 10:47:06 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F12921E811B for ; Thu, 2 Aug 2012 10:47:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.487 X-Spam-Level: X-Spam-Status: No, score=-110.487 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S0ZOv994eGss for ; Thu, 2 Aug 2012 10:47:05 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 4FF4311E81B1 for ; Thu, 2 Aug 2012 10:47:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=798; q=dns/txt; s=iport; t=1343929625; x=1345139225; h=from:to:subject:date:message-id:mime-version: content-transfer-encoding; bh=0r6mI9D6KTFWhOT1XsJCfchm1xXo+GaVGhgpiYGt1Wk=; b=MIYJTEEEJKxFVokEYtNMFqXbNDOKIF53WLHB2dGGAsp2VysOGXighyAs kmLUAgmkpuDKp4luQ8yMpiq+fm9ztpEwYTR1TDLlDqV7lQsYsnwincuTh mIIW1cu9nbUgIxj/WxZWspGW5dSFL5ZJkmfh/OYWh4hvFV7EVXiWPZa7i 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjMFAPy7GlCrRDoH/2dsb2JhbABFhTSkKI89gQeCJwgKARcQTAUYUCMcAQQeF4dqDJs6gSigVI8ygxwDiE2FDIkCjROBZoJ/ X-IronPort-AV: E=Sophos;i="4.77,702,1336348800"; d="scan'208";a="53891508" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 02 Aug 2012 17:45:04 +0000 Received: from dwingWS (sjc-vpn5-1740.cisco.com [10.21.94.204]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q72Hj4HO011618 for ; Thu, 2 Aug 2012 17:45:04 GMT From: "Dan Wing" To: Date: Thu, 2 Aug 2012 10:45:03 -0700 Message-ID: <038b01cd70d6$8c5bc870$a5135950$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac1w1ovfvzUgFxvbR0qnhkeGI2kOuA== Content-Language: en-us Subject: [rtcweb] NAT behavior heuristics X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 02 Aug 2012 17:47:06 -0000 In today's RTCWEB meeting I said that NAT heuristics do not work reliably, especially if a NAT is busy (high CPU or lots of ports consumed), but there are other situations with a NAT that cause heuristics to be inaccurate. The IETF document regarding this is http://tools.ietf.org/html/rfc5780, and be sure to read its Applicability Statement in Section 1, http://tools.ietf.org/html/rfc5780#section-1. An explicit protocol, such Port Control Protocol (PCP, draft-ietf-pcp-base) is the only reliable way to communicate with a NAT and reduce application keepalive traffic. Several of us have noticed the need to document exactly how PCP can be reliably used to reduce UDP keepalive traffic. We will write down those details before the next IETF, probably in an Internet Draft. -d From ietf@meetecho.com Thu Aug 2 11:01:23 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 493A811E80E6 for ; Thu, 2 Aug 2012 11:01:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.529 X-Spam-Level: X-Spam-Status: No, score=-0.529 tagged_above=-999 required=5 tests=[AWL=0.190, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tWoHfnPEsvR0 for ; Thu, 2 Aug 2012 11:01:22 -0700 (PDT) Received: from smtplq03.aruba.it (smtplq-out5.aruba.it [62.149.158.25]) by ietfa.amsl.com (Postfix) with SMTP id 497CF11E80DF for ; Thu, 2 Aug 2012 11:01:22 -0700 (PDT) Received: (qmail 9606 invoked by uid 89); 2 Aug 2012 18:01:20 -0000 Received: from unknown (HELO smtp2.aruba.it) (62.149.158.222) by smtplq03.aruba.it with SMTP; 2 Aug 2012 18:01:20 -0000 Received: (qmail 22559 invoked by uid 89); 2 Aug 2012 18:01:20 -0000 Received: from unknown (HELO ?130.129.21.177?) (alex@meetecho.com@130.129.21.177) by smtp2.ad.aruba.it with ESMTPA; 2 Aug 2012 18:01:20 -0000 Message-ID: <501AC066.8020504@meetecho.com> Date: Thu, 02 Aug 2012 20:01:10 +0200 From: Meetecho IETF support User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: rtcweb@ietf.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: smtplq03.aruba.it 1.6.2 0/1000/N Subject: [rtcweb] Meetecho session recording available X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 02 Aug 2012 18:01:23 -0000 Dear all, the full recording (synchronized video, audio, slides and jabber room) of the first RTCWEB session at IETF-84 is available. You can watch it by accessing the following URL: http://ietf84.conf.meetecho.com/index.php/Recorded_Sessions#IETF84_RTCWEB_I For the chair(s): please feel free to put the link to the recording in the minutes, if you think this might be useful. In case of problems with the playout, just drop an e-mail to team@meetecho.com. Cheers, the Meetecho team -- Meetecho s.r.l. Web Conferencing and Collaboration Tools www.meetecho.com From martin.thomson@gmail.com Thu Aug 2 16:02:29 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD0FF11E814E for ; Thu, 2 Aug 2012 16:02:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.015 X-Spam-Level: X-Spam-Status: No, score=-4.015 tagged_above=-999 required=5 tests=[AWL=-0.416, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yl9ULEE6n2XH for ; Thu, 2 Aug 2012 16:02:29 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 98F8611E8120 for ; Thu, 2 Aug 2012 16:02:28 -0700 (PDT) Received: by lahm15 with SMTP id m15so36335lah.31 for ; Thu, 02 Aug 2012 16:02:27 -0700 (PDT) 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=bjpknQBSeZeuU6ds9Ho2BHt/qAdByd33c4d4NpanbY0=; b=y6dc7EQlunxFOEGC/UrVNdchfr3p6ahsJRvcnxGIRBMp3IXgE6MuUeSPSIKkuzuW+4 WNtoq1JYJL8XAuBqKUl/vaFrtAlf6ShWNEl/OAsESZEWW8HFkXt/9NGfqaGPb/1N1Z7s Rq+8I9scjgFhumB2t/87/CboZTaZ0TLDKfgincN4JiH4rdJluEq2doCUqcS/ulfHUmCQ 7t0VTrkfjgJQC00VXorP+uGNT0MOo8MhvOIweLMWUpIZP49voUQH9yUlS/fuR8KIYgvW uiI6OtJUtGEnnIEV/5l1+7/xN72GVqk15krvM7ErSi0/ESikSIa16pO6lJ75PTHMv7jZ KTMw== MIME-Version: 1.0 Received: by 10.152.109.198 with SMTP id hu6mr22923697lab.21.1343948547496; Thu, 02 Aug 2012 16:02:27 -0700 (PDT) Received: by 10.112.82.1 with HTTP; Thu, 2 Aug 2012 16:02:27 -0700 (PDT) In-Reply-To: <038b01cd70d6$8c5bc870$a5135950$@com> References: <038b01cd70d6$8c5bc870$a5135950$@com> Date: Thu, 2 Aug 2012 16:02:27 -0700 Message-ID: From: Martin Thomson To: Dan Wing Content-Type: text/plain; charset=UTF-8 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] NAT behavior heuristics X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 02 Aug 2012 23:02:29 -0000 I assume that this applies only to the NAT that doesn't exist yet and that we will have to live with status quo (and the current keep-alive recommendations) until PCP becomes bountiful. We might want to consider other options for things like power saving in addition to this. One option that springs to mind is the ability to explicitly shut down streams that aren't in use and pay the price for warm-up. Optimizations to candidate pair select at warm-up might be handy in this case. On 2 August 2012 10:45, Dan Wing wrote: > In today's RTCWEB meeting I said that NAT heuristics do not work reliably, > especially if a NAT is busy (high CPU or lots of ports consumed), but there > are other situations with a NAT that cause heuristics to be inaccurate. The > IETF document regarding this is http://tools.ietf.org/html/rfc5780, and be > sure to read its Applicability Statement in Section 1, > http://tools.ietf.org/html/rfc5780#section-1. > > An explicit protocol, such Port Control Protocol (PCP, draft-ietf-pcp-base) > is the only reliable way to communicate with a NAT and reduce application > keepalive traffic. Several of us have noticed the need to document exactly > how PCP can be reliably used to reduce UDP keepalive traffic. We will write > down those details before the next IETF, probably in an Internet Draft. > > -d > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From dwing@cisco.com Thu Aug 2 16:15:47 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E64E521E804A for ; Thu, 2 Aug 2012 16:15:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gJd6UK+23O0q for ; Thu, 2 Aug 2012 16:15:47 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id D107D21E8039 for ; Thu, 2 Aug 2012 16:15:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=2351; q=dns/txt; s=iport; t=1343949346; x=1345158946; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=7PqDarZ/4ALZgjlXKsEHXsa2K1M4qK5oFc5B/4qSDjI=; b=dvhay72V0WZTYFAFwWV/fmTaGmlJT0F8533WxpwvlKx1sJwvwqvfxdPT xvVNDBFAAbQW7VmfV8NFJGIA//ch0jOL39Pfgr3GkF104N7KmwJS0oWsm x1npIRNkGWFnjoiFFlBUUqSm/Nxb3YD/VW8p9qHUCBiqEBfnz8IG0+8AX I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFADMIG1CQ/khM/2dsb2JhbABFhXujY489gQeCIAEBAQMBAQEBBQoBEAc9BwsFBwEDAgkPAgQBAQECAiMDAgIZCAYVCgkIAQEEEwsXh1wDBgYLnHqNGYlSDYlOgSGJQmcFFoVXgRIDiE2FDIYbgmeJdoMdgWaCfw X-IronPort-AV: E=Sophos;i="4.77,703,1336348800"; d="scan'208";a="75752180" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 02 Aug 2012 23:15:44 +0000 Received: from dwingWS (sjc-vpn6-1214.cisco.com [10.21.124.190]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q72NFhQ0002326; Thu, 2 Aug 2012 23:15:44 GMT From: "Dan Wing" To: "'Martin Thomson'" References: <038b01cd70d6$8c5bc870$a5135950$@com> In-Reply-To: Date: Thu, 2 Aug 2012 16:15:43 -0700 Message-ID: <04ff01cd7104$be09bed0$3a1d3c70$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac1xAunMGd6HFGy9RJmomYLEhqfaSQAAA9tA Content-Language: en-us Cc: rtcweb@ietf.org Subject: Re: [rtcweb] NAT behavior heuristics X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 02 Aug 2012 23:15:48 -0000 > -----Original Message----- > From: Martin Thomson [mailto:martin.thomson@gmail.com] > Sent: Thursday, August 02, 2012 4:02 PM > To: Dan Wing > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] NAT behavior heuristics > > I assume that this applies only to the NAT that doesn't exist yet and > that we will have to live with status quo (and the current keep-alive > recommendations) until PCP becomes bountiful. Yes. PCP is new, somewhat like RTCWEB. There is an incentive for the existing CGNs, deployed by almost all 3G/LTE carriers around the world, to have their vendors add PCP support to those NATs, as it saves battery lifetime for their subscribers and reduces chatter on their network. Incentives are well aligned for that to happen. I agree that home NATs, enterprise NATs, and enterprise firewalls do not have those same incentives. > We might want to consider other options for things like power saving > in addition to this. One option that springs to mind is the ability > to explicitly shut down streams that aren't in use and pay the price > for warm-up. Optimizations to candidate pair select at warm-up might > be handy in this case. Such as draft-westerlund-avtext-rtp-stream-pause? -d > On 2 August 2012 10:45, Dan Wing wrote: > > In today's RTCWEB meeting I said that NAT heuristics do not work > reliably, > > especially if a NAT is busy (high CPU or lots of ports consumed), but > there > > are other situations with a NAT that cause heuristics to be > inaccurate. The > > IETF document regarding this is http://tools.ietf.org/html/rfc5780, > and be > > sure to read its Applicability Statement in Section 1, > > http://tools.ietf.org/html/rfc5780#section-1. > > > > An explicit protocol, such Port Control Protocol (PCP, draft-ietf- > pcp-base) > > is the only reliable way to communicate with a NAT and reduce > application > > keepalive traffic. Several of us have noticed the need to document > exactly > > how PCP can be reliably used to reduce UDP keepalive traffic. We > will write > > down those details before the next IETF, probably in an Internet > Draft. > > > > -d > > > > > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb From martin.thomson@gmail.com Thu Aug 2 16:20:55 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E294E21E80B2 for ; Thu, 2 Aug 2012 16:20:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.008 X-Spam-Level: X-Spam-Status: No, score=-4.008 tagged_above=-999 required=5 tests=[AWL=-0.409, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jx083NAE8fmY for ; Thu, 2 Aug 2012 16:20:54 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 00A3721E80AE for ; Thu, 2 Aug 2012 16:20:53 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so1364373lbb.31 for ; Thu, 02 Aug 2012 16:20:53 -0700 (PDT) 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=Bq6BmL94K5I7SXWiXss+BRMT3pbK/tZnvSqpIaEUN0M=; b=A22mDsV9KSOxIcL5Pj9qngNkFrwp8S+fv5UKco2u+WLcngYxw7g1E8gPHsTHbZUn/P mRwa1M3V3GwX1DtVxArGMFaUsS+8GrX8wojbD+gLrhoFctFfIV/49UCt0FBsZCVZS+ZI nsyzJur1AFMKVVzedsGbbeFSbKEEZk1qa9m94Bme9cVKHNUi2VrEgTuVII0aEEhjiEKf Nt75/AWbZlm6xHr6NsRLdFr4UY1vDl7RHdzbL+tdu74s+NN93eLbGe4T9HhlwFAoo07d NpKtocup7s7nvYMiWqongWz4vb4GZzhfBIEV6BKKskR7Y6ANwoqzoh/MmmNotmIusKT0 +9Tg== MIME-Version: 1.0 Received: by 10.112.46.166 with SMTP id w6mr10201266lbm.100.1343949652919; Thu, 02 Aug 2012 16:20:52 -0700 (PDT) Received: by 10.112.82.1 with HTTP; Thu, 2 Aug 2012 16:20:52 -0700 (PDT) In-Reply-To: <04ff01cd7104$be09bed0$3a1d3c70$@com> References: <038b01cd70d6$8c5bc870$a5135950$@com> <04ff01cd7104$be09bed0$3a1d3c70$@com> Date: Thu, 2 Aug 2012 16:20:52 -0700 Message-ID: From: Martin Thomson To: Dan Wing Content-Type: text/plain; charset=UTF-8 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] NAT behavior heuristics X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 02 Aug 2012 23:20:55 -0000 On 2 August 2012 16:15, Dan Wing wrote: >> We might want to consider other options for things like power saving >> in addition to this. One option that springs to mind is the ability >> to explicitly shut down streams that aren't in use and pay the price >> for warm-up. Optimizations to candidate pair select at warm-up might >> be handy in this case. > > Such as draft-westerlund-avtext-rtp-stream-pause? That would work at the RTP layer. That could flow down to the UDP flow, but resumption is non-trivial. If you lose the NAT bindings as a result, you would have to be prepared to restart the flow. The (previously) active flow might simply have to represent the highest priority candidate pair in an ICE reboot. From dwing@cisco.com Thu Aug 2 16:46:06 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EF9011E8118 for ; Thu, 2 Aug 2012 16:46:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ySWpHQazp58B for ; Thu, 2 Aug 2012 16:46:06 -0700 (PDT) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id B356C11E8072 for ; Thu, 2 Aug 2012 16:46:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=1207; q=dns/txt; s=iport; t=1343951165; x=1345160765; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=zvI1KUbwxcqZDB+hzkhGP3Pc05CI6fAJpLkIzhHmL8k=; b=hJ7bgDM5Ex+/LCrTCb9VXUrBGwtptnTsWUCNQ+kwCdfk4V99bEskZ1yG kd9kpbu56zqRk0Nk0P8cNaAcs4hfJXwixtsed6qsGOvPTZzqzeONmVFB0 D2NWa/KB8Fzc50FFuumwDG6EhHApSSHVp/HUsFnMDckUvZCxTPWopuxV2 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhEFAFoQG1CQ/khN/2dsb2JhbABFhXujY489gQeCIAEBAQQICgEQB08MAQMCCQ8CBAEBAQICIwMCAhkIGwoJCAEBBBMLF4dcAwycfI0ZiVcNiU6BIYlCZxuFV4ESA4hNhQyGG4xdgx2BZoJ/ X-IronPort-AV: E=Sophos;i="4.77,704,1336348800"; d="scan'208";a="7089968" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-3.cisco.com with ESMTP; 02 Aug 2012 23:46:04 +0000 Received: from dwingWS (sjc-vpn6-1214.cisco.com [10.21.124.190]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q72Nk3WT031703; Thu, 2 Aug 2012 23:46:03 GMT From: "Dan Wing" To: "'Martin Thomson'" References: <038b01cd70d6$8c5bc870$a5135950$@com> <04ff01cd7104$be09bed0$3a1d3c70$@com> In-Reply-To: Date: Thu, 2 Aug 2012 16:46:02 -0700 Message-ID: <051e01cd7108$fab81ee0$f0285ca0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac1xBX2fJAeN8Y1OQra/U7QeEjttPgAA0yvQ Content-Language: en-us Cc: rtcweb@ietf.org Subject: Re: [rtcweb] NAT behavior heuristics X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 02 Aug 2012 23:46:06 -0000 > -----Original Message----- > From: Martin Thomson [mailto:martin.thomson@gmail.com] > Sent: Thursday, August 02, 2012 4:21 PM > To: Dan Wing > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] NAT behavior heuristics > > On 2 August 2012 16:15, Dan Wing wrote: > >> We might want to consider other options for things like power saving > >> in addition to this. One option that springs to mind is the ability > >> to explicitly shut down streams that aren't in use and pay the price > >> for warm-up. Optimizations to candidate pair select at warm-up > might > >> be handy in this case. > > > > Such as draft-westerlund-avtext-rtp-stream-pause? > > That would work at the RTP layer. That could flow down to the UDP > flow, but resumption is non-trivial. If you lose the NAT bindings as > a result, you would have to be prepared to restart the flow. The > (previously) active flow might simply have to represent the highest > priority candidate pair in an ICE reboot. Thanks. Perhaps modeling the long-duration stopped flow as a long-duration mobility event (draft-wing-mmusic-ice-mobility) might be worthwhile; they feel the same to me at the moment. -d From mperumal@cisco.com Fri Aug 3 00:58:58 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 191A721F8D1B for ; Fri, 3 Aug 2012 00:58:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uau6d9Cy4+nP for ; Fri, 3 Aug 2012 00:58:57 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id DCD5A21F8D3C for ; Fri, 3 Aug 2012 00:58:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mperumal@cisco.com; l=3995; q=dns/txt; s=iport; t=1343980737; x=1345190337; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=PMZ6CPcAD9XuZKYhay0R80T12gMzQ2I+DOFCjD5Vygg=; b=WzwHyrgpBKS2NPKB6J8DrGu/0tlNzQqYr0ZQyrvjRew1AZW+dmKIbqdM 603VyMm4kacDE7Gp0g+f/+vm5h/t4ajyAo9L+/4sATfQO/+VXKLsIWwTY JkE6wszkzIdxKOa9WAvnBa+Chwc1MbP7LfLgn7cZkb2AlQnNxl/aw3+6e 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAMiDG1CtJV2Z/2dsb2JhbABFuSWBB4IgAQEBBAEBAQ8BJzQLDAQCAQgRBAEBCxQJBycLFAkIAgQBDQUIGodrC5x5oDWLRwUWhglgA5ZcjROBZoJfgVYH X-IronPort-AV: E=Sophos;i="4.77,705,1336348800"; d="scan'208";a="108125911" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-8.cisco.com with ESMTP; 03 Aug 2012 07:58:56 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q737wull007394 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 3 Aug 2012 07:58:56 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.113]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0298.004; Fri, 3 Aug 2012 02:58:56 -0500 From: "Muthu Arul Mozhi Perumal (mperumal)" To: Martin Thomson , "Dan Wing (dwing)" Thread-Topic: [rtcweb] NAT behavior heuristics Thread-Index: AQHNcQLmZq9mQPoftU6IiiFi63YLnpdHtxfQ Date: Fri, 3 Aug 2012 07:58:55 +0000 Message-ID: References: <038b01cd70d6$8c5bc870$a5135950$@com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.76.102] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19082.002 x-tm-as-result: No--40.231500-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] NAT behavior heuristics X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 03 Aug 2012 07:58:58 -0000 |We might want to consider other options for things like power saving |in addition to this. One option that springs to mind is the ability |to explicitly shut down streams that aren't in use and pay the price |for warm-up. =20 I think that can be done by slightly tweaking the consent freshness test in= draft-muthu-behave-consent-freshness-01. We can also combine it with the s= ession liveness test and optimize everything. Here is the algorithm I have = in mind: The browser starts two timers after ICE concludes: - A consent timer t1 for 15 sec (configurable in the browser) - A liveness timer t2 for 5 sec (configurable by the JS) When t1 expires: If nothing except consent freshness request(s) was sent in the last x sec t= hen=20 goto power_saving_mode. Else // We has been sending media on the candidate pair. If a STUN transaction isn't already active then=20 Send a consent freshness request. If the transaction fails then=20 goto power_saving_mode. Else // The transaction succeeds Reset t1. =20 When t2 expires: If nothing was received since the last liveness test then=20 If a STUN transaction isn't already active then Send a liveness request.=20 If the transaction fails then Notify the JS. Else // The transaction succeeds Reset t2. =20 power_saving_mode: Stop sending everything on that candidate pair.=20 Stop both timers. Notify the JS.=20 Notes: The JS is responsible for restarting ICE in the power_saving_mode. Consent freshness and liveness requests are STUN binding requests. The default value for t1 is the same as the default for ICE keepalives (sec= tion 10 of RFC5245). The default value for x is 60 sec (configurable by the JS). By carefully choose t1, t2 and x we can: 1. Make it work for existing NATs. 2. Interoperate with existing ICE/ICE-lite implementations. 3. Save battery. 4. Achieve good user experience. Comments welcome. Muthu |-----Original Message----- |From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf O= f Martin Thomson |Sent: Friday, August 03, 2012 4:32 AM |To: Dan Wing (dwing) |Cc: rtcweb@ietf.org |Subject: Re: [rtcweb] NAT behavior heuristics | |I assume that this applies only to the NAT that doesn't exist yet and |that we will have to live with status quo (and the current keep-alive |recommendations) until PCP becomes bountiful. | |We might want to consider other options for things like power saving |in addition to this. One option that springs to mind is the ability |to explicitly shut down streams that aren't in use and pay the price |for warm-up. Optimizations to candidate pair select at warm-up might |be handy in this case. | |On 2 August 2012 10:45, Dan Wing wrote: |> In today's RTCWEB meeting I said that NAT heuristics do not work reliabl= y, |> especially if a NAT is busy (high CPU or lots of ports consumed), but th= ere |> are other situations with a NAT that cause heuristics to be inaccurate. = The |> IETF document regarding this is http://tools.ietf.org/html/rfc5780, and = be |> sure to read its Applicability Statement in Section 1, |> http://tools.ietf.org/html/rfc5780#section-1. |> |> An explicit protocol, such Port Control Protocol (PCP, draft-ietf-pcp-ba= se) |> is the only reliable way to communicate with a NAT and reduce applicatio= n |> keepalive traffic. Several of us have noticed the need to document exac= tly |> how PCP can be reliably used to reduce UDP keepalive traffic. We will w= rite |> down those details before the next IETF, probably in an Internet Draft. |> |> -d |> |> |> _______________________________________________ |> 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 From likepeng@huawei.com Fri Aug 3 01:44:08 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C756321F8D77 for ; Fri, 3 Aug 2012 01:44:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lhURcL6zsUbO for ; Fri, 3 Aug 2012 01:44:08 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id B5D1821F8D7E for ; Fri, 3 Aug 2012 01:44:07 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AIM18679; Fri, 03 Aug 2012 00:44:07 -0800 (PST) Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 3 Aug 2012 01:41:06 -0700 Received: from SZXEML422-HUB.china.huawei.com (10.82.67.161) by dfweml407-hub.china.huawei.com (10.193.5.132) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 3 Aug 2012 01:41:12 -0700 Received: from SZXEML525-MBX.china.huawei.com ([169.254.1.5]) by szxeml422-hub.china.huawei.com ([10.82.67.161]) with mapi id 14.01.0323.003; Fri, 3 Aug 2012 16:41:05 +0800 From: Likepeng To: Justin Uberti Thread-Topic: [rtcweb] Fw: New Version Notification for draft-li-rtcweb-jsep-xmpp-mapping-00.txt Thread-Index: AQHNbiTIl1A6XHCWTUGcMhcvyZeTZ5dBi+BwgAABaICABjysIA== Date: Fri, 3 Aug 2012 08:41:05 +0000 Message-ID: <34966E97BE8AD64EAE9D3D6E4DEE36F207BD5E41@szxeml525-mbx.china.huawei.com> References: <34966E97BE8AD64EAE9D3D6E4DEE36F207BD4A03@szxeml525-mbx.china.huawei.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.110.124] Content-Type: multipart/alternative; boundary="_000_34966E97BE8AD64EAE9D3D6E4DEE36F207BD5E41szxeml525mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Fw: New Version Notification for draft-li-rtcweb-jsep-xmpp-mapping-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 03 Aug 2012 08:44:08 -0000 --_000_34966E97BE8AD64EAE9D3D6E4DEE36F207BD5E41szxeml525mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PkkgZGlkbid0IHNlZSBhIHNlY3Rpb24gd2hlcmUgaXQgZXhwbGFpbnMgaG93IHRvIG1hcCB0aGUg SmluZ2xlIG1lc3NhZ2VzIHRvIHRoZSBKU0VQIEFQSSwgb3IgdGhlIHBheWxvYWRzIG9mIHRoZXNl IG1lc3NhZ2VzIHRvIFNEUCAoYXMgcmVxdWlyZWQgYnkgdGhlIEFQSSkuDQoNCkkgcmV2aXNlIHRo ZSBkcmFmdCBhY2NvcmRpbmcgdG8gdGhlIHN1Z2dlc3Rpb246DQpodHRwOi8vd3d3LmlldGYub3Jn L2ludGVybmV0LWRyYWZ0cy9kcmFmdC1saS1ydGN3ZWItanNlcC14bXBwLW1hcHBpbmctMDEudHh0 DQoNCkkgd291bGQgYXBwcmVjaWF0ZSB5b3VyIGZ1cnRoZXIgY29tbWVudHMgYW5kIGZlZWRiYWNr cy4NCg0KVGhhbmtzLA0KDQpLaW5kIFJlZ2FyZHMNCktlcGVuZw0KDQrlj5Hku7bkuro6IEp1c3Rp biBVYmVydGkgW21haWx0bzpqdWJlcnRpQGdvb2dsZS5jb21dDQrlj5HpgIHml7bpl7Q6IDIwMTLl ubQ35pyIMzHml6UgMToyMg0K5pS25Lu25Lq6OiBMaWtlcGVuZw0K5oqE6YCBOiBydGN3ZWJAaWV0 Zi5vcmcNCuS4u+mimDogUmU6IFtydGN3ZWJdIEZ3OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24g Zm9yIGRyYWZ0LWxpLXJ0Y3dlYi1qc2VwLXhtcHAtbWFwcGluZy0wMC50eHQNCg0KTGlrZXBlbmcs DQoNClRoaXMgZHJhZnQgc2hvd3MgaG93IEpTIGNsaWVudHMgY291bGQgdXNlIHRoZSBKaW5nbGUg cHJvdG9jb2wgdG8gZXN0YWJsaXNoIGEgc2Vzc2lvbiwgYnV0IEkgZGlkbid0IHNlZSBhIHNlY3Rp b24gd2hlcmUgaXQgZXhwbGFpbnMgaG93IHRvIG1hcCB0aGUgSmluZ2xlIG1lc3NhZ2VzIHRvIHRo ZSBKU0VQIEFQSSwgb3IgdGhlIHBheWxvYWRzIG9mIHRoZXNlIG1lc3NhZ2VzIHRvIFNEUCAoYXMg cmVxdWlyZWQgYnkgdGhlIEFQSSkuDQoNCkkgdGhpbmsgdGhpcyBjb3VsZCBiZSBlYXNpbHkgYWRk ZWQgLSBmb3IgZXhhbXBsZSwgYSByZWNlaXZlZCBzZXNzaW9uLWluaXRpYXRlIHdpbGwgbWFwIHRv IGEgc2V0UmVtb3RlRGVzY3JpcHRpb24gLSBidXQgaW4gb3JkZXIgZm9yIGEgZGV2ZWxvcGVyIHRv IGltcGxlbWVudCBhbiBKaW5nbGUgY2xpZW50IGluIEpTLCB0aGVzZSBtYXBwaW5ncyBuZWVkIHRv IGJlIGNsZWFybHkgZGVmaW5lZC4NCg0KT24gTW9uLCBKdWwgMzAsIDIwMTIgYXQgMjoyMCBBTSwg TGlrZXBlbmcgPGxpa2VwZW5nQGh1YXdlaS5jb208bWFpbHRvOmxpa2VwZW5nQGh1YXdlaS5jb20+ PiB3cm90ZToNCldlbGNvbWUgeW91ciBjb21tZW50cyB0byB0aGlzIGRyYWZ0Lg0KDQpIYXZlIGEg bmljZSBtZWV0aW5nIGluIFZhbmNvdXZlciENCg0KS2luZCBSZWdhcmRzDQpLZXBlbmcNCi0tLS0t 6YKu5Lu25Y6f5Lu2LS0tLS0NCuWPkeS7tuS6ujogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPG1h aWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+IFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGll dGYub3JnPG1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+XQ0K5Y+R6YCB5pe26Ze0OiAy MDEy5bm0N+aciDMw5pelIDE1OjI3DQrmlLbku7bkuro6IExpa2VwZW5nDQrmioTpgIE6IExpa2Vw ZW5nDQrkuLvpopg6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtbGktcnRjd2Vi LWpzZXAteG1wcC1tYXBwaW5nLTAwLnR4dA0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQt bGktcnRjd2ViLWpzZXAteG1wcC1tYXBwaW5nLTAwLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5 IHN1Ym1pdHRlZCBieSBLZXBlbmcgYW5kIHBvc3RlZCB0byB0aGUNCklFVEYgcmVwb3NpdG9yeS4N Cg0KRmlsZW5hbWU6ICAgICAgICBkcmFmdC1saS1ydGN3ZWItanNlcC14bXBwLW1hcHBpbmcNClJl dmlzaW9uOiAgICAgICAgMDANClRpdGxlOiAgICAgICAgICAgUlRDV2ViIEpTRVAgWE1QUC9KaW5n bGUgTWFwcGluZw0KQ3JlYXRpb24gZGF0ZTogICAyMDEyLTA3LTMwDQpXRyBJRDogICAgICAgICAg IEluZGl2aWR1YWwgU3VibWlzc2lvbg0KTnVtYmVyIG9mIHBhZ2VzOiAxMA0KVVJMOiAgICAgICAg ICAgICBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1saS1ydGN3ZWIt anNlcC14bXBwLW1hcHBpbmctMDAudHh0DQpTdGF0dXM6ICAgICAgICAgIGh0dHA6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtbGktcnRjd2ViLWpzZXAteG1wcC1tYXBwaW5nDQpIdG1s aXplZDogICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWxpLXJ0Y3dlYi1q c2VwLXhtcHAtbWFwcGluZy0wMA0KDQpBYnN0cmFjdDoNCiAgIFRoaXMgZG9jdW1lbnQgcHJvcG9z ZXMgbWFwcGluZyBtZXNzYWdlIHJlcHJlc2VudGF0aW9ucyBiZXR3ZWVuIFJUQ1dlYg0KICAgSmF2 YXNjcmlwdCBTZXNzaW9uIEVzdGFibGlzaG1lbnQgUHJvdG9jb2woSlNFUCkgc2NoZW1lIGFuZCBY TVBQLw0KICAgSmluZ2xlIFtYRVAtMDE2Nl0gbWVzc2FnaW5nIHNjaGVtZS4gIFN1Y2ggYSBzaWdu YWxpbmcgbWFwcGluZyBpcw0KICAgaW50ZW5kZWQgdG8gZW5hYmxlIEphdmFzY3JpcHQgdG8gdXNl IFhNUFAvSmluZ2xlIHRvIGVzdGFibGlzaCBhDQogICBzZXNzaW9uIGJldHdlZW4gdHdvIFJUQ1dl YiBlbmFibGVkIGJyb3dzZXJzLg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnJ0Y3dlYiBtYWlsaW5nIGxpc3QN CnJ0Y3dlYkBpZXRmLm9yZzxtYWlsdG86cnRjd2ViQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWINCg0K --_000_34966E97BE8AD64EAE9D3D6E4DEE36F207BD5E41szxeml525mbxchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OuWui+S9kzt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWls U3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQN Cgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3Np emU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4wcHQ7 fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3Bp ZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRh dGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8 Ym9keSBsYW5nPSJaSC1DTiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNz PSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi PiZndDtJIGRpZG4ndCBzZWUgYSBzZWN0aW9uIHdoZXJlIGl0IGV4cGxhaW5zIGhvdyB0byBtYXAg dGhlIEppbmdsZSBtZXNzYWdlcyB0byB0aGUgSlNFUCBBUEksIG9yIHRoZSBwYXlsb2FkcyBvZiB0 aGVzZSBtZXNzYWdlcyB0byBTRFAgKGFzIHJlcXVpcmVkIGJ5IHRoZSBBUEkpLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+SSByZXZpc2UgdGhlIGRyYWZ0IGFjY29yZGluZyB0byB0aGUgc3VnZ2VzdGlvbjo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+PGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQt bGktcnRjd2ViLWpzZXAteG1wcC1tYXBwaW5nLTAxLnR4dCI+aHR0cDovL3d3dy5pZXRmLm9yZy9p bnRlcm5ldC1kcmFmdHMvZHJhZnQtbGktcnRjd2ViLWpzZXAteG1wcC1tYXBwaW5nLTAxLnR4dDwv YT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5JIHdvdWxkIGFw cHJlY2lhdGUgeW91ciBmdXJ0aGVyIGNvbW1lbnRzIGFuZCBmZWVkYmFja3MuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIj5UaGFua3MsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5LaW5kIFJlZ2FyZHM8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+S2Vw ZW5nPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNC NUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+5Y+R5Lu25Lq6PHNwYW4gbGFu Zz0iRU4tVVMiPjo8L3NwYW4+PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQiPiBKdXN0aW4gVWJlcnRpIFttYWlsdG86anViZXJ0aUBnb29nbGUuY29t XQ0KPGJyPg0KPC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij7lj5HpgIHm l7bpl7Q8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+IDIwMTI8L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQiPuW5tDxzcGFuIGxhbmc9IkVOLVVTIj43PC9zcGFuPuaciDxzcGFuIGxh bmc9IkVOLVVTIj4zMTwvc3Bhbj7ml6U8c3BhbiBsYW5nPSJFTi1VUyI+IDE6MjI8YnI+DQo8L3Nw YW4+PGI+5pS25Lu25Lq6PHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9 IkVOLVVTIj4gTGlrZXBlbmc8YnI+DQo8L3NwYW4+PGI+5oqE6YCBPHNwYW4gbGFuZz0iRU4tVVMi Pjo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4gcnRjd2ViQGlldGYub3JnPGJyPg0KPC9z cGFuPjxiPuS4u+mimDxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJF Ti1VUyI+IFJlOiBbcnRjd2ViXSBGdzogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFm dC1saS1ydGN3ZWItanNlcC14bXBwLW1hcHBpbmctMDAudHh0PG86cD48L286cD48L3NwYW4+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj5MaWtlcGVuZyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIj5UaGlzIGRyYWZ0IHNob3dzIGhvdyBKUyBjbGllbnRzIGNvdWxkIHVzZSB0aGUgSmlu Z2xlIHByb3RvY29sIHRvIGVzdGFibGlzaCBhIHNlc3Npb24sIGJ1dCBJIGRpZG4ndCBzZWUgYSBz ZWN0aW9uIHdoZXJlIGl0IGV4cGxhaW5zIGhvdyB0byBtYXAgdGhlIEppbmdsZSBtZXNzYWdlcyB0 byB0aGUgSlNFUCBBUEksIG9yIHRoZSBwYXlsb2FkcyBvZiB0aGVzZSBtZXNzYWdlcyB0byBTRFAN CiAoYXMgcmVxdWlyZWQgYnkgdGhlIEFQSSkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj5JIHRoaW5rIHRoaXMgY291bGQgYmUgZWFzaWx5IGFkZGVkIC0g Zm9yIGV4YW1wbGUsIGEgcmVjZWl2ZWQgc2Vzc2lvbi1pbml0aWF0ZSB3aWxsIG1hcCB0byBhIHNl dFJlbW90ZURlc2NyaXB0aW9uIC0gYnV0IGluIG9yZGVyIGZvciBhIGRldmVsb3BlciB0byBpbXBs ZW1lbnQgYW4gSmluZ2xlIGNsaWVudCBpbiBKUywgdGhlc2UgbWFwcGluZ3MgbmVlZCB0byBiZSBj bGVhcmx5IGRlZmluZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5n PSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5PbiBNb24sIEp1bCAzMCwgMjAxMiBhdCAyOjIw IEFNLCBMaWtlcGVuZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmxpa2VwZW5nQGh1YXdlaS5jb20iIHRh cmdldD0iX2JsYW5rIj5saWtlcGVuZ0BodWF3ZWkuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPldl bGNvbWUgeW91ciBjb21tZW50cyB0byB0aGlzIGRyYWZ0Ljxicj4NCjxicj4NCkhhdmUgYSBuaWNl IG1lZXRpbmcgaW4gVmFuY291dmVyITxicj4NCjxicj4NCktpbmQgUmVnYXJkczxicj4NCktlcGVu Zzxicj4NCi0tLS0tPC9zcGFuPumCruS7tuWOn+S7tjxzcGFuIGxhbmc9IkVOLVVTIj4tLS0tLTxi cj4NCjwvc3Bhbj7lj5Hku7bkuro8c3BhbiBsYW5nPSJFTi1VUyI+OiA8YSBocmVmPSJtYWlsdG86 aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIj5pbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8L2E+IFtt YWlsdG86PGEgaHJlZj0ibWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyI+aW50ZXJuZXQt ZHJhZnRzQGlldGYub3JnPC9hPl08YnI+DQo8L3NwYW4+5Y+R6YCB5pe26Ze0PHNwYW4gbGFuZz0i RU4tVVMiPjogMjAxMjwvc3Bhbj7lubQ8c3BhbiBsYW5nPSJFTi1VUyI+Nzwvc3Bhbj7mnIg8c3Bh biBsYW5nPSJFTi1VUyI+MzA8L3NwYW4+5pelPHNwYW4gbGFuZz0iRU4tVVMiPiAxNToyNzxicj4N Cjwvc3Bhbj7mlLbku7bkuro8c3BhbiBsYW5nPSJFTi1VUyI+OiBMaWtlcGVuZzxicj4NCjwvc3Bh bj7mioTpgIE8c3BhbiBsYW5nPSJFTi1VUyI+OiBMaWtlcGVuZzxicj4NCjwvc3Bhbj7kuLvpopg8 c3BhbiBsYW5nPSJFTi1VUyI+OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWxp LXJ0Y3dlYi1qc2VwLXhtcHAtbWFwcGluZy0wMC50eHQ8YnI+DQo8YnI+DQpBIG5ldyB2ZXJzaW9u IG9mIEktRCwgZHJhZnQtbGktcnRjd2ViLWpzZXAteG1wcC1tYXBwaW5nLTAwLnR4dDxicj4NCmhh cyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgS2VwZW5nIGFuZCBwb3N0ZWQgdG8gdGhl PGJyPg0KSUVURiByZXBvc2l0b3J5Ljxicj4NCjxicj4NCkZpbGVuYW1lOiAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDtkcmFmdC1saS1ydGN3ZWItanNlcC14bXBwLW1hcHBpbmc8YnI+DQpSZXZp c2lvbjogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7MDA8YnI+DQpUaXRsZTogJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBSVENXZWIgSlNFUCBYTVBQL0ppbmdsZSBNYXBwaW5n PGJyPg0KQ3JlYXRpb24gZGF0ZTogJm5ic3A7IDIwMTItMDctMzA8YnI+DQpXRyBJRDogJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBJbmRpdmlkdWFsIFN1Ym1pc3Npb248YnI+DQpO dW1iZXIgb2YgcGFnZXM6IDEwPGJyPg0KVVJMOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyA8YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1saS1ydGN3ZWItanNlcC14bXBwLW1hcHBpbmctMDAudHh0IiB0YXJnZXQ9Il9ibGFu ayI+DQpodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1saS1ydGN3ZWIt anNlcC14bXBwLW1hcHBpbmctMDAudHh0PC9hPjxicj4NClN0YXR1czogJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOzxhIGhyZWY9Imh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvZHJhZnQtbGktcnRjd2ViLWpzZXAteG1wcC1tYXBwaW5nIiB0YXJnZXQ9Il9ibGFuayI+aHR0 cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1saS1ydGN3ZWItanNlcC14bXBwLW1h cHBpbmc8L2E+PGJyPg0KSHRtbGl6ZWQ6ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzxhIGhy ZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWxpLXJ0Y3dlYi1qc2VwLXhtcHAt bWFwcGluZy0wMCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWxpLXJ0Y3dlYi1qc2VwLXhtcHAtbWFwcGluZy0wMDwvYT48YnI+DQo8YnI+DQpBYnN0cmFj dDo8YnI+DQombmJzcDsgJm5ic3A7VGhpcyBkb2N1bWVudCBwcm9wb3NlcyBtYXBwaW5nIG1lc3Nh Z2UgcmVwcmVzZW50YXRpb25zIGJldHdlZW4gUlRDV2ViPGJyPg0KJm5ic3A7ICZuYnNwO0phdmFz Y3JpcHQgU2Vzc2lvbiBFc3RhYmxpc2htZW50IFByb3RvY29sKEpTRVApIHNjaGVtZSBhbmQgWE1Q UC88YnI+DQombmJzcDsgJm5ic3A7SmluZ2xlIFtYRVAtMDE2Nl0gbWVzc2FnaW5nIHNjaGVtZS4g Jm5ic3A7U3VjaCBhIHNpZ25hbGluZyBtYXBwaW5nIGlzPGJyPg0KJm5ic3A7ICZuYnNwO2ludGVu ZGVkIHRvIGVuYWJsZSBKYXZhc2NyaXB0IHRvIHVzZSBYTVBQL0ppbmdsZSB0byBlc3RhYmxpc2gg YTxicj4NCiZuYnNwOyAmbmJzcDtzZXNzaW9uIGJldHdlZW4gdHdvIFJUQ1dlYiBlbmFibGVkIGJy b3dzZXJzLjxicj4NCjxicj4NClRoZSBJRVRGIFNlY3JldGFyaWF0PGJyPg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpydGN3ZWIgbWFpbGluZyBs aXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZyI+cnRjd2ViQGlldGYub3Jn PC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v cnRjd2ViIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9ydGN3ZWI8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_34966E97BE8AD64EAE9D3D6E4DEE36F207BD5E41szxeml525mbxchi_-- From harald@alvestrand.no Fri Aug 3 08:26:43 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B18F21F8D33 for ; Fri, 3 Aug 2012 08:26:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lu7l51-Vckja for ; Fri, 3 Aug 2012 08:26:42 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id AD10421F8CAD for ; Fri, 3 Aug 2012 08:26:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 33ABD39E179 for ; Fri, 3 Aug 2012 17:26:39 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6QqNGEOJDMli for ; Fri, 3 Aug 2012 17:26:36 +0200 (CEST) Received: from [192.168.16.101] (dhcp-442d.meeting.ietf.org [130.129.68.45]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id D39D439E056 for ; Fri, 3 Aug 2012 17:26:35 +0200 (CEST) Message-ID: <501BEDAE.8090005@alvestrand.no> Date: Fri, 03 Aug 2012 08:26:38 -0700 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <038b01cd70d6$8c5bc870$a5135950$@com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] NAT behavior heuristics X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 03 Aug 2012 15:26:43 -0000 Don't forget that if you want to shut down a flow according to RTP rules, you have to stop sending RTCP on it, which, again according to RTP rules, will declare the flow ended after a timeout. If you want to have the flow "active but not sending", you have to go on sending RTCP SR's, reporting that "I still have this flow, but I deliberately did not send any packets on it" - which of course will keep the radio awake. If the flow is regarded as ended at all layers, resumption becomes a non-issue; you just add a new flow when the time comes. On 08/03/2012 12:58 AM, Muthu Arul Mozhi Perumal (mperumal) wrote: > |We might want to consider other options for things like power saving > |in addition to this. One option that springs to mind is the ability > |to explicitly shut down streams that aren't in use and pay the price > |for warm-up. > > I think that can be done by slightly tweaking the consent freshness test in draft-muthu-behave-consent-freshness-01. We can also combine it with the session liveness test and optimize everything. Here is the algorithm I have in mind: > > The browser starts two timers after ICE concludes: > - A consent timer t1 for 15 sec (configurable in the browser) > - A liveness timer t2 for 5 sec (configurable by the JS) > > When t1 expires: > If nothing except consent freshness request(s) was sent in the last x sec then > goto power_saving_mode. > Else // We has been sending media on the candidate pair. > If a STUN transaction isn't already active then > Send a consent freshness request. > If the transaction fails then > goto power_saving_mode. > Else // The transaction succeeds > Reset t1. > > When t2 expires: > If nothing was received since the last liveness test then > If a STUN transaction isn't already active then > Send a liveness request. > If the transaction fails then > Notify the JS. > Else // The transaction succeeds > Reset t2. > > power_saving_mode: > Stop sending everything on that candidate pair. > Stop both timers. > Notify the JS. > > Notes: > The JS is responsible for restarting ICE in the power_saving_mode. > Consent freshness and liveness requests are STUN binding requests. > The default value for t1 is the same as the default for ICE keepalives (section 10 of RFC5245). > The default value for x is 60 sec (configurable by the JS). > > By carefully choose t1, t2 and x we can: > 1. Make it work for existing NATs. > 2. Interoperate with existing ICE/ICE-lite implementations. > 3. Save battery. > 4. Achieve good user experience. > > Comments welcome. > > Muthu > > |-----Original Message----- > |From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Martin Thomson > |Sent: Friday, August 03, 2012 4:32 AM > |To: Dan Wing (dwing) > |Cc: rtcweb@ietf.org > |Subject: Re: [rtcweb] NAT behavior heuristics > | > |I assume that this applies only to the NAT that doesn't exist yet and > |that we will have to live with status quo (and the current keep-alive > |recommendations) until PCP becomes bountiful. > | > |We might want to consider other options for things like power saving > |in addition to this. One option that springs to mind is the ability > |to explicitly shut down streams that aren't in use and pay the price > |for warm-up. Optimizations to candidate pair select at warm-up might > |be handy in this case. > | > |On 2 August 2012 10:45, Dan Wing wrote: > |> In today's RTCWEB meeting I said that NAT heuristics do not work reliably, > |> especially if a NAT is busy (high CPU or lots of ports consumed), but there > |> are other situations with a NAT that cause heuristics to be inaccurate. The > |> IETF document regarding this is http://tools.ietf.org/html/rfc5780, and be > |> sure to read its Applicability Statement in Section 1, > |> http://tools.ietf.org/html/rfc5780#section-1. > |> > |> An explicit protocol, such Port Control Protocol (PCP, draft-ietf-pcp-base) > |> is the only reliable way to communicate with a NAT and reduce application > |> keepalive traffic. Several of us have noticed the need to document exactly > |> how PCP can be reliably used to reduce UDP keepalive traffic. We will write > |> down those details before the next IETF, probably in an Internet Draft. > |> > |> -d > |> > |> > |> _______________________________________________ > |> 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 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From mperumal@cisco.com Fri Aug 3 17:04:56 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86A5A21E8055 for ; Fri, 3 Aug 2012 17:04:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.556 X-Spam-Level: X-Spam-Status: No, score=-10.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nRY-InOZivJi for ; Fri, 3 Aug 2012 17:04:55 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id F081521E803D for ; Fri, 3 Aug 2012 17:04:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5769; q=dns/txt; s=iport; t=1344038695; x=1345248295; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=m4+nc+8goYxvNRU9Qe2s9GWwtAqzRNU+n9ujiUiXA1w=; b=fvovjYvWgFVPDh6lAiWPtIUsLPm28N4nDTS74V981lQDYHnq6/Yv+zZ1 ltGJ1HpE4/4KPOJ1gdElks6TRYHgPyoCqjXT9XzEcrKE+WwnWQXo0eBNU HnaYusR9DFsOymlPjjulGy59Pw3KuG53TteylhjzN48DMnBYoUkrlUQSr U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAOplHFCtJV2Z/2dsb2JhbABFuTuBB4IgAQEBBAEBAQ8BJzQXBAIBCBEEAQELFAkHJwsUCQgCBAESCBqHawucVqASi0gFFoYJYAOWXo0TgWaCX4FWBw X-IronPort-AV: E=Sophos;i="4.77,709,1336348800"; d="scan'208";a="105376545" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-9.cisco.com with ESMTP; 04 Aug 2012 00:04:54 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q7404seX018923 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 4 Aug 2012 00:04:54 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.113]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0283.003; Fri, 3 Aug 2012 19:04:54 -0500 From: "Muthu Arul Mozhi Perumal (mperumal)" To: Harald Alvestrand , "rtcweb@ietf.org" Thread-Topic: [rtcweb] NAT behavior heuristics Thread-Index: AQHNcQLmZq9mQPoftU6IiiFi63YLnpdHtxfQgADTdACAADrF8A== Date: Sat, 4 Aug 2012 00:04:53 +0000 Message-ID: References: <038b01cd70d6$8c5bc870$a5135950$@com> <501BEDAE.8090005@alvestrand.no> In-Reply-To: <501BEDAE.8090005@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.72.165] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19084.001 x-tm-as-result: No--43.626600-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [rtcweb] NAT behavior heuristics X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 04 Aug 2012 00:04:56 -0000 |Don't forget that if you want to shut down a flow according to=20 |RTP rules, you have to stop sending RTCP on it, which, again=20 |according to RTP rules, will declare the flow ended after a=20 |timeout. The idea is to completely shut down the flow. The RTP rules will ensure tha= t the peer times out and releases its resources. Muthu=20 |-----Original Message----- |From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf O= f Harald Alvestrand |Sent: Friday, August 03, 2012 8:57 PM |To: rtcweb@ietf.org |Subject: Re: [rtcweb] NAT behavior heuristics | |Don't forget that if you want to shut down a flow according to RTP |rules, you have to stop sending RTCP on it, which, again according to |RTP rules, will declare the flow ended after a timeout. | |If you want to have the flow "active but not sending", you have to go on |sending RTCP SR's, reporting that "I still have this flow, but I |deliberately did not send any packets on it" - which of course will keep |the radio awake. | |If the flow is regarded as ended at all layers, resumption becomes a |non-issue; you just add a new flow when the time comes. | |On 08/03/2012 12:58 AM, Muthu Arul Mozhi Perumal (mperumal) wrote: |> |We might want to consider other options for things like power saving |> |in addition to this. One option that springs to mind is the ability |> |to explicitly shut down streams that aren't in use and pay the price |> |for warm-up. |> |> I think that can be done by slightly tweaking the consent freshness test= in draft-muthu-behave- |consent-freshness-01. We can also combine it with the session liveness tes= t and optimize everything. |Here is the algorithm I have in mind: |> |> The browser starts two timers after ICE concludes: |> - A consent timer t1 for 15 sec (configurable in the browser) |> - A liveness timer t2 for 5 sec (configurable by the JS) |> |> When t1 expires: |> If nothing except consent freshness request(s) was sent in the last x se= c then |> goto power_saving_mode. |> Else // We has been sending media on the candidate pair. |> If a STUN transaction isn't already active then |> Send a consent freshness request. |> If the transaction fails then |> goto power_saving_mode. |> Else // The transaction succeeds |> Reset t1. |> |> When t2 expires: |> If nothing was received since the last liveness test then |> If a STUN transaction isn't already active then |> Send a liveness request. |> If the transaction fails then |> Notify the JS. |> Else // The transaction succeeds |> Reset t2. |> |> power_saving_mode: |> Stop sending everything on that candidate pair. |> Stop both timers. |> Notify the JS. |> |> Notes: |> The JS is responsible for restarting ICE in the power_saving_mode. |> Consent freshness and liveness requests are STUN binding requests. |> The default value for t1 is the same as the default for ICE keepalives (= section 10 of RFC5245). |> The default value for x is 60 sec (configurable by the JS). |> |> By carefully choose t1, t2 and x we can: |> 1. Make it work for existing NATs. |> 2. Interoperate with existing ICE/ICE-lite implementations. |> 3. Save battery. |> 4. Achieve good user experience. |> |> Comments welcome. |> |> Muthu |> |> |-----Original Message----- |> |From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behal= f Of Martin Thomson |> |Sent: Friday, August 03, 2012 4:32 AM |> |To: Dan Wing (dwing) |> |Cc: rtcweb@ietf.org |> |Subject: Re: [rtcweb] NAT behavior heuristics |> | |> |I assume that this applies only to the NAT that doesn't exist yet and |> |that we will have to live with status quo (and the current keep-alive |> |recommendations) until PCP becomes bountiful. |> | |> |We might want to consider other options for things like power saving |> |in addition to this. One option that springs to mind is the ability |> |to explicitly shut down streams that aren't in use and pay the price |> |for warm-up. Optimizations to candidate pair select at warm-up might |> |be handy in this case. |> | |> |On 2 August 2012 10:45, Dan Wing wrote: |> |> In today's RTCWEB meeting I said that NAT heuristics do not work reli= ably, |> |> especially if a NAT is busy (high CPU or lots of ports consumed), but= there |> |> are other situations with a NAT that cause heuristics to be inaccurat= e. The |> |> IETF document regarding this is http://tools.ietf.org/html/rfc5780, a= nd be |> |> sure to read its Applicability Statement in Section 1, |> |> http://tools.ietf.org/html/rfc5780#section-1. |> |> |> |> An explicit protocol, such Port Control Protocol (PCP, draft-ietf-pcp= -base) |> |> is the only reliable way to communicate with a NAT and reduce applica= tion |> |> keepalive traffic. Several of us have noticed the need to document e= xactly |> |> how PCP can be reliably used to reduce UDP keepalive traffic. We wil= l write |> |> down those details before the next IETF, probably in an Internet Draf= t. |> |> |> |> -d |> |> |> |> |> |> _______________________________________________ |> |> 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 |> _______________________________________________ |> 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 From randell-ietf@jesup.org Sun Aug 5 00:20:12 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A013621F8659 for ; Sun, 5 Aug 2012 00:20:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.855 X-Spam-Level: X-Spam-Status: No, score=-1.855 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_05=-1.11] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zfgt5eDVUpdJ for ; Sun, 5 Aug 2012 00:20:12 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 0A95A21F8624 for ; Sun, 5 Aug 2012 00:20:11 -0700 (PDT) Received: from pool-173-49-141-60.phlapa.fios.verizon.net ([173.49.141.60] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1Sxv8E-0007Wc-LJ for rtcweb@ietf.org; Sun, 05 Aug 2012 02:20:10 -0500 Message-ID: <501E1E40.8070203@jesup.org> Date: Sun, 05 Aug 2012 03:18:24 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <038b01cd70d6$8c5bc870$a5135950$@com> <04ff01cd7104$be09bed0$3a1d3c70$@com> In-Reply-To: <04ff01cd7104$be09bed0$3a1d3c70$@com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [rtcweb] NAT behavior heuristics X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 05 Aug 2012 07:20:12 -0000 On 8/2/2012 7:15 PM, Dan Wing wrote: >> -----Original Message----- >> From: Martin Thomson [mailto:martin.thomson@gmail.com] >> Sent: Thursday, August 02, 2012 4:02 PM >> To: Dan Wing >> Cc: rtcweb@ietf.org >> Subject: Re: [rtcweb] NAT behavior heuristics >> >> I assume that this applies only to the NAT that doesn't exist yet and >> that we will have to live with status quo (and the current keep-alive >> recommendations) until PCP becomes bountiful. > > Yes. PCP is new, somewhat like RTCWEB. > > There is an incentive for the existing CGNs, deployed by almost all > 3G/LTE carriers around the world, to have their vendors add PCP > support to those NATs, as it saves battery lifetime for their > subscribers and reduces chatter on their network. Incentives are > well aligned for that to happen. > > I agree that home NATs, enterprise NATs, and enterprise firewalls > do not have those same incentives. And that's a rub, since in many/most cases, the 3G/LTE people will likely be talking to non-3G/LTE people, and if either side needs keepalives, then radio will be kept active. Note we're talking long-term inactive media flows and an inactive (or rarely active) datachannel, such as a client using PeerConnection and DataChannels to keep a registration or empty conference alive, or various non-phone-like applications. An alternative mechanism for keepalives might help - you can use short-TTL packets to prop the local router without letting the packet go all the way to the other end. If the fixed-station PC uses this TTL trick, and the mobile unit uses PCP, the mobile unit can keep its radio off. Short-TTL can be handy for reducing loads on servers, especially where the port needs to stay open with no real traffic for long periods (think SIP). The local router is rarely more than 5-7 hops from a device, though there are pathological cases; this could be configured (and disableable). There are also ways to do discovery on the local router; these might work better than discovery of UDP port binding time, which is known to not work. -- Randell Jesup randell-ietf@jesup.org From cb.list6@gmail.com Sun Aug 5 05:32:29 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4817421F84C9 for ; Sun, 5 Aug 2012 05:32:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.46 X-Spam-Level: X-Spam-Status: No, score=-3.46 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NP5QM5qrwGS8 for ; Sun, 5 Aug 2012 05:32:28 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id BDED621F8466 for ; Sun, 5 Aug 2012 05:32:27 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so2475869lbb.31 for ; Sun, 05 Aug 2012 05:32:26 -0700 (PDT) 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=EaApJPBHd8Yywjr+nVQH31raec9pYyQaC9tp6MQ4hus=; b=tRXGRZVUujzGGw5pIR3oFMwSYdXz/Y2mmqEPElmpQy0OfIQGk4PAP8yjO1L3ufzy80 VJkSuX9QIe/cgtjYIIkMczCV4Ytq53dqVp/NgwZvrquvF7Oja1OKOboCFYGYamjX/0mW TUopJmcZ5c5XTDCOiwqxwX3toQoD9AzueagEyebT1yGr7S2pTvKJy23ZRfzmy05OEV7w o+zKhjMhTX6Ezn8o9I//VPlbI5n0UbsJFmrWn7qkXf1sMwwM6kFWH5uZ1scFm4z2hlu4 uISRys4kbTTkCLXh7bKvFR9CeLhY2/Mq+h//CKZXc/zObK7JXKDvoRO24EqYho4zPe4f ty1w== MIME-Version: 1.0 Received: by 10.152.146.101 with SMTP id tb5mr7535145lab.0.1344169946756; Sun, 05 Aug 2012 05:32:26 -0700 (PDT) Received: by 10.112.3.196 with HTTP; Sun, 5 Aug 2012 05:32:26 -0700 (PDT) Received: by 10.112.3.196 with HTTP; Sun, 5 Aug 2012 05:32:26 -0700 (PDT) In-Reply-To: <501E1E40.8070203@jesup.org> References: <038b01cd70d6$8c5bc870$a5135950$@com> <04ff01cd7104$be09bed0$3a1d3c70$@com> <501E1E40.8070203@jesup.org> Date: Sun, 5 Aug 2012 05:32:26 -0700 Message-ID: From: Cameron Byrne To: Randell Jesup Content-Type: multipart/alternative; boundary=e89a8f2348b331b69a04c683f46c Cc: rtcweb@ietf.org Subject: Re: [rtcweb] NAT behavior heuristics X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 05 Aug 2012 12:32:29 -0000 --e89a8f2348b331b69a04c683f46c Content-Type: text/plain; charset=ISO-8859-1 On Aug 5, 2012 12:20 AM, "Randell Jesup" wrote: > > On 8/2/2012 7:15 PM, Dan Wing wrote: >>> >>> -----Original Message----- >>> From: Martin Thomson [mailto:martin.thomson@gmail.com] >>> Sent: Thursday, August 02, 2012 4:02 PM >>> To: Dan Wing >>> Cc: rtcweb@ietf.org >>> Subject: Re: [rtcweb] NAT behavior heuristics >>> >>> I assume that this applies only to the NAT that doesn't exist yet and >>> that we will have to live with status quo (and the current keep-alive >>> recommendations) until PCP becomes bountiful. >> >> >> Yes. PCP is new, somewhat like RTCWEB. >> >> There is an incentive for the existing CGNs, deployed by almost all >> 3G/LTE carriers around the world, to have their vendors add PCP >> support to those NATs, as it saves battery lifetime for their >> subscribers and reduces chatter on their network. Incentives are >> well aligned for that to happen. >> >> I agree that home NATs, enterprise NATs, and enterprise firewalls >> do not have those same incentives. > > > And that's a rub, since in many/most cases, the 3G/LTE people will likely be talking to non-3G/LTE people, and if either side needs keepalives, then radio will be kept active. Note we're talking long-term inactive media flows and an inactive (or rarely active) datachannel, such as a client using PeerConnection and DataChannels to keep a registration or empty conference alive, or various non-phone-like applications. > > An alternative mechanism for keepalives might help - you can use short-TTL packets to prop the local router without letting the packet go all the way to the other end. If the fixed-station PC uses this TTL trick, and the mobile unit uses PCP, the mobile unit can keep its radio off. > Fyi. I have not seen any traction for pcp anywhere in the mobile space. Not on host and not on the CGN. I would not assume it will catch on. As a mobile operator i have zero plans for ever supporting it. I have operated CGN in mobile for years, most mobile operators have, and we don't see inbound connections to mobiles via the cgn as a requirement (nat44 works today, and applying polish to crap is not productive) I would avoid the rtcweb layer going into too much effort to optimize batteries of devices. The intention is good, but at some point it becomes a layer violation and suboptimization. Ipv6 is the solution to these issue. CB > Short-TTL can be handy for reducing loads on servers, especially where the port needs to stay open with no real traffic for long periods (think SIP). > > The local router is rarely more than 5-7 hops from a device, though there are pathological cases; this could be configured (and disableable). There are also ways to do discovery on the local router; these might work better than discovery of UDP port binding time, which is known to not work. > > > -- > Randell Jesup > randell-ietf@jesup.org > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --e89a8f2348b331b69a04c683f46c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Aug 5, 2012 12:20 AM, "Randell Jesup" <randell-ietf@jesup.org> wrote:
>
> On 8/2/2012 7:15 PM, Dan Wing wrote:
>>>
>>> -----Original Message-----
>>> From: Martin Thomson [mailto:martin.thomson@gmail.com]
>>> Sent: Thursday, August 02, 2012 4:02 PM
>>> To: Dan Wing
>>> Cc: rtcweb@ietf.org
>>> Subject: Re: [rtcweb] NAT behavior heuristics
>>>
>>> I assume that this applies only to the NAT that doesn't ex= ist yet and
>>> that we will have to live with status quo (and the current kee= p-alive
>>> recommendations) until PCP becomes bountiful.
>>
>>
>> Yes. =A0PCP is new, somewhat like RTCWEB.
>>
>> There is an incentive for the existing CGNs, deployed by almost al= l
>> 3G/LTE carriers around the world, to have their vendors add PCP >> support to those NATs, as it saves battery lifetime for their
>> subscribers and reduces chatter on their network. =A0Incentives ar= e
>> well aligned for that to happen.
>>
>> I agree that home NATs, enterprise NATs, and enterprise firewalls<= br> >> do not have those same incentives.
>
>
> And that's a rub, since in many/most cases, the 3G/LTE people will= likely be talking to non-3G/LTE people, and if either side needs keepalive= s, then radio will be kept active. =A0Note we're talking long-term inac= tive media flows and an inactive (or rarely active) datachannel, such as a = client using PeerConnection and DataChannels to keep a registration or empt= y conference alive, or various non-phone-like applications.
>
> An alternative mechanism for keepalives might help - you can use short= -TTL packets to prop the local router without letting the packet go all the= way to the other end. =A0If the fixed-station PC uses this TTL trick, and = the mobile unit uses PCP, the mobile unit can keep its radio off.
>

Fyi. I have not seen any traction for pcp anywhere in the mobile space.= =A0 Not on host and not on the CGN. I would not assume it will catch on. As= a mobile operator i have zero plans for ever supporting it. I have operate= d CGN in mobile for years, most mobile operators have, and we don't see= inbound connections to mobiles via the cgn as a requirement (nat44 works t= oday, and applying polish to crap is not productive)

I would avoid the rtcweb layer going into too much effort to optimize ba= tteries of devices. The intention is good, but at some point it becomes a l= ayer violation and suboptimization.

Ipv6 is the solution to these issue.

CB

> Short-TTL can be handy for reducing loads on servers, especially wh= ere the port needs to stay open with no real traffic for long periods (thin= k SIP).
>
> The local router is rarely more than 5-7 hops from a device, though th= ere are pathological cases; this could be configured (and disableable). =A0= There are also ways to do discovery on the local router; these might work b= etter than discovery of UDP port binding time, which is known to not work.<= br> >
>
> --
> Randell Jesup
> randell-ietf@jesup.org >
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.i= etf.org/mailman/listinfo/rtcweb

--e89a8f2348b331b69a04c683f46c-- From tireddy@cisco.com Sun Aug 5 14:49:51 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B300E21F8564 for ; Sun, 5 Aug 2012 14:49:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.449 X-Spam-Level: X-Spam-Status: No, score=-10.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z6hXSlCJyX0U for ; Sun, 5 Aug 2012 14:49:50 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id BC6C221F8562 for ; Sun, 5 Aug 2012 14:49:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=tireddy@cisco.com; l=3378; q=dns/txt; s=iport; t=1344203390; x=1345412990; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=k9KaDc7RbbBQXpr2kv7V7NYNnywexBNSA+Egp4/SwO0=; b=C+svUq3nF+fA9e6LlfgF6nXcqzo173uf5Z77O0rTffC/zd5W+qvrCgzq 5iw4zvtSQZmB8TvloZbnxJAsVvcXV5xq5EkPqk4rtpX5a4+QCIurBBfEK 9qrkfHy4A7NtUiR2hZhY1DvTkxLhdzhKiR2wbFsZ6W3nUHZvg9EYHy9Rh U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAD/pHlCtJV2a/2dsb2JhbABFuT2BB4IgAQEBAwEBAQEPARQTLQEGEAcEAgEIEQQBAQEKFAkHIQYLFAkIAQEEARIIGodcAwYGC5szlRoNiUoEimNnBYYfYAOTdoxcgx2BZoJf X-IronPort-AV: E=Sophos;i="4.77,715,1336348800"; d="scan'208";a="108417106" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-1.cisco.com with ESMTP; 05 Aug 2012 21:49:50 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q75Lnoph023162 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 5 Aug 2012 21:49:50 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.216]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0298.004; Sun, 5 Aug 2012 16:49:49 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Randell Jesup , "rtcweb@ietf.org" Thread-Topic: [rtcweb] NAT behavior heuristics Thread-Index: Ac1w1ovfvzUgFxvbR0qnhkeGI2kOuAAVj+eAAAB2nYAAdXC7AAAQkmkg Date: Sun, 5 Aug 2012 21:49:49 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A1477C16C@xmb-rcd-x10.cisco.com> References: <038b01cd70d6$8c5bc870$a5135950$@com> <04ff01cd7104$be09bed0$3a1d3c70$@com> <501E1E40.8070203@jesup.org> In-Reply-To: <501E1E40.8070203@jesup.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.83.244] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19088.001 x-tm-as-result: No--48.144400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [rtcweb] NAT behavior heuristics X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 05 Aug 2012 21:49:51 -0000 > And that's a rub, since in many/most cases, the 3G/LTE people will > likely be talking to non-3G/LTE people, and if either side needs > keepalives, then radio will be kept active. Note we're talking > long-term inactive media flows and an inactive (or rarely active) > datachannel, such as a client using PeerConnection and DataChannels to > keep a registration or empty conference alive, or various non-phone- > like applications. If just 3G/LTE supports PCP and non-3G/LTE does not support PCP -> Any STUN= indications coming from the non-3G can be dropped by the Mobile Network it= self to avoid reaching the Mobile Node, since it knows NAT binding is alive= using PCP.=20 --Tiru. > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > Behalf Of Randell Jesup > Sent: Sunday, August 05, 2012 1:18 AM > To: rtcweb@ietf.org > Subject: Re: [rtcweb] NAT behavior heuristics >=20 > On 8/2/2012 7:15 PM, Dan Wing wrote: > >> -----Original Message----- > >> From: Martin Thomson [mailto:martin.thomson@gmail.com] > >> Sent: Thursday, August 02, 2012 4:02 PM > >> To: Dan Wing > >> Cc: rtcweb@ietf.org > >> Subject: Re: [rtcweb] NAT behavior heuristics > >> > >> I assume that this applies only to the NAT that doesn't exist yet > and > >> that we will have to live with status quo (and the current keep- > alive > >> recommendations) until PCP becomes bountiful. > > > > Yes. PCP is new, somewhat like RTCWEB. > > > > There is an incentive for the existing CGNs, deployed by almost all > > 3G/LTE carriers around the world, to have their vendors add PCP > > support to those NATs, as it saves battery lifetime for their > > subscribers and reduces chatter on their network. Incentives are > > well aligned for that to happen. > > > > I agree that home NATs, enterprise NATs, and enterprise firewalls > > do not have those same incentives. >=20 > And that's a rub, since in many/most cases, the 3G/LTE people will > likely be talking to non-3G/LTE people, and if either side needs > keepalives, then radio will be kept active. Note we're talking > long-term inactive media flows and an inactive (or rarely active) > datachannel, such as a client using PeerConnection and DataChannels to > keep a registration or empty conference alive, or various non-phone- > like > applications. >=20 > An alternative mechanism for keepalives might help - you can use > short-TTL packets to prop the local router without letting the packet > go > all the way to the other end. If the fixed-station PC uses this TTL > trick, and the mobile unit uses PCP, the mobile unit can keep its radio > off. >=20 > Short-TTL can be handy for reducing loads on servers, especially where > the port needs to stay open with no real traffic for long periods > (think > SIP). >=20 > The local router is rarely more than 5-7 hops from a device, though > there are pathological cases; this could be configured (and > disableable). There are also ways to do discovery on the local router; > these might work better than discovery of UDP port binding time, which > is known to not work. >=20 >=20 > -- > Randell Jesup > randell-ietf@jesup.org > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From tireddy@cisco.com Sun Aug 5 15:05:53 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC2BA21F851B for ; Sun, 5 Aug 2012 15:05:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RMxdleg7afhY for ; Sun, 5 Aug 2012 15:05:53 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id EB7EF21F8575 for ; Sun, 5 Aug 2012 15:05:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=tireddy@cisco.com; l=3337; q=dns/txt; s=iport; t=1344204353; x=1345413953; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Dz+rq5TTBCya5v0Uj4u/zoqQYngD01wLHGCOApvepA8=; b=ThFBaZnGZWhvrAr6uPJEvCRKcwyF81laYc5mO0ptCstZGrh/JjcF7+J2 8fG8awU4DP54aqD5dF/6fu+VHagTWxeTnc0jlBBGbu7fsNtOQq5oHqmIl yv07z61LEETnkFOGj906YR9l+xGhacqXSD+UHU8voslVx6sK3ACUHDEWX g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAGntHlCtJV2a/2dsb2JhbABFuT2BB4IgAQEBAwEBAQEPAVQBBgsFBwQCAQgOAwQBAQEKHQchBgsUCQgBAQQBDQUIEweHXAMGBgubMpUaDYlOimNnBYYfYAOIGItegmeJdYMdgWaCXw X-IronPort-AV: E=Sophos;i="4.77,715,1336348800"; d="scan'208";a="108638982" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-8.cisco.com with ESMTP; 05 Aug 2012 22:05:52 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q75M5q8C001670 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 5 Aug 2012 22:05:52 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.216]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0298.004; Sun, 5 Aug 2012 17:05:52 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Cameron Byrne , Randell Jesup Thread-Topic: [rtcweb] NAT behavior heuristics Thread-Index: Ac1w1ovfvzUgFxvbR0qnhkeGI2kOuAAVj+eAAAB2nYAAdXC7AAAK960AAAlqvrA= Date: Sun, 5 Aug 2012 22:05:51 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A1477C17F@xmb-rcd-x10.cisco.com> References: <038b01cd70d6$8c5bc870$a5135950$@com> <04ff01cd7104$be09bed0$3a1d3c70$@com> <501E1E40.8070203@jesup.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.84.88] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19088.001 x-tm-as-result: No--40.769300-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" , "phdgang@gmail.com" Subject: Re: [rtcweb] NAT behavior heuristics X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 05 Aug 2012 22:05:54 -0000 > Fyi. I have not seen any traction for pcp anywhere in the mobile space. http://tools.ietf.org/html/draft-chen-pcp-mobile-deployment-01 describes us= age of PCP in Mobile Deployments. --Tiru. On Aug 5, 2012 12:20 AM, "Randell Jesup" wrote: > > On 8/2/2012 7:15 PM, Dan Wing wrote: >>> >>> -----Original Message----- >>> From: Martin Thomson [mailto:martin.thomson@gmail.com] >>> Sent: Thursday, August 02, 2012 4:02 PM >>> To: Dan Wing >>> Cc: rtcweb@ietf.org >>> Subject: Re: [rtcweb] NAT behavior heuristics >>> >>> I assume that this applies only to the NAT that doesn't exist yet and >>> that we will have to live with status quo (and the current keep-alive >>> recommendations) until PCP becomes bountiful. >> >> >> Yes. =A0PCP is new, somewhat like RTCWEB. >> >> There is an incentive for the existing CGNs, deployed by almost all >> 3G/LTE carriers around the world, to have their vendors add PCP >> support to those NATs, as it saves battery lifetime for their >> subscribers and reduces chatter on their network. =A0Incentives are >> well aligned for that to happen. >> >> I agree that home NATs, enterprise NATs, and enterprise firewalls >> do not have those same incentives. > > > And that's a rub, since in many/most cases, the 3G/LTE people will likely= be talking to non-3G/LTE people, and if either side needs keepalives, then= radio will be kept active. =A0Note we're talking long-term inactive media = flows and an inactive (or rarely active) datachannel, such as a client usin= g PeerConnection and DataChannels to keep a registration or empty conferenc= e alive, or various non-phone-like applications. > > An alternative mechanism for keepalives might help - you can use short-TT= L packets to prop the local router without letting the packet go all the wa= y to the other end. =A0If the fixed-station PC uses this TTL trick, and the= mobile unit uses PCP, the mobile unit can keep its radio off. > Fyi. I have not seen any traction for pcp anywhere in the mobile space.=A0 = Not on host and not on the CGN. I would not assume it will catch on. As a m= obile operator i have zero plans for ever supporting it. I have operated CG= N in mobile for years, most mobile operators have, and we don't see inbound= connections to mobiles via the cgn as a requirement (nat44 works today, an= d applying polish to crap is not productive) I would avoid the rtcweb layer going into too much effort to optimize batte= ries of devices. The intention is good, but at some point it becomes a laye= r violation and suboptimization. Ipv6 is the solution to these issue. CB > Short-TTL can be handy for reducing loads on servers, especially where th= e port needs to stay open with no real traffic for long periods (think SIP)= . > > The local router is rarely more than 5-7 hops from a device, though there= are pathological cases; this could be configured (and disableable). =A0The= re are also ways to do discovery on the local router; these might work bett= er than discovery of UDP port binding time, which is known to not work. > > > --=20 > Randell Jesup > randell-ietf@jesup.org > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From cb.list6@gmail.com Sun Aug 5 15:22:08 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB6B221F851B for ; Sun, 5 Aug 2012 15:22:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.468 X-Spam-Level: X-Spam-Status: No, score=-3.468 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Si7cb-pCtfjD for ; Sun, 5 Aug 2012 15:22:07 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 987B621F8578 for ; Sun, 5 Aug 2012 15:22:03 -0700 (PDT) Received: by lahm15 with SMTP id m15so1287172lah.31 for ; Sun, 05 Aug 2012 15:22:02 -0700 (PDT) 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=8hvSEPkgYuGfokL3bmn4vrYit8ZeNRIyRdR2hIfYvbc=; b=LatE2oiDdahD6Sw2lYH5MHAFKu9nSQfAbZIsPoH/AoMIWiunhtcIR3pLmTfEh9DSIp L/Z6et6fP/Ce/OMzqo+MtnRRQEockmCFJGZ28FPdfQVElGBNECmBoZd1KyOS7okFjHST nejK2b89WTX0OfAJperkz1nA348YHVB2kkHXHfsqVoFny+DKNZHSz21CxXvkJAZC/EAP Hmv3+sM91Zuot1iYd9vfwuq+5debp7pa3890zru/uXqdLbonBISmNtK3oXuB0Cwnbfa5 lZJUczJXKtk/JldRZzaZPhBMZMDJgH7NIY8yQ9jGS7r8BNwGYxDOctBsOfRPQjWIIdaO t9Bg== MIME-Version: 1.0 Received: by 10.152.146.101 with SMTP id tb5mr8711930lab.0.1344205322592; Sun, 05 Aug 2012 15:22:02 -0700 (PDT) Received: by 10.112.3.196 with HTTP; Sun, 5 Aug 2012 15:22:02 -0700 (PDT) In-Reply-To: <913383AAA69FF945B8F946018B75898A1477C17F@xmb-rcd-x10.cisco.com> References: <038b01cd70d6$8c5bc870$a5135950$@com> <04ff01cd7104$be09bed0$3a1d3c70$@com> <501E1E40.8070203@jesup.org> <913383AAA69FF945B8F946018B75898A1477C17F@xmb-rcd-x10.cisco.com> Date: Sun, 5 Aug 2012 15:22:02 -0700 Message-ID: From: Cameron Byrne To: "Tirumaleswar Reddy (tireddy)" Content-Type: text/plain; charset=ISO-8859-1 Cc: Randell Jesup , "rtcweb@ietf.org" , "phdgang@gmail.com" Subject: Re: [rtcweb] NAT behavior heuristics X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 05 Aug 2012 22:22:08 -0000 On Sun, Aug 5, 2012 at 3:05 PM, Tirumaleswar Reddy (tireddy) wrote: >> Fyi. I have not seen any traction for pcp anywhere in the mobile space. > > http://tools.ietf.org/html/draft-chen-pcp-mobile-deployment-01 describes usage of PCP in Mobile Deployments. > > --Tiru. > Yep, that's an I-D. And, it says things like "Without the particular considerations , PCP may not provide desirable outcomes. Some default behaviours may even cause negative impacts or system failures in a mobile environment. " Got an operators with a timeline on supporting it? How about a mobile OS that plans to support PCP, because you will need both. And, that would be interesting information. I asked around in Vancouver about PCP, and all the operators i spoke to said no-plans, no motivation. But, that was a small sample. In any event, my only point is that RTCWEB should NOT be counting on PCP. If PCP is a tool you have, use it. My point: it is not a tool you have. CB From tireddy@cisco.com Sun Aug 5 15:42:19 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B55521F8578 for ; Sun, 5 Aug 2012 15:42:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3NceABvaGFMX for ; Sun, 5 Aug 2012 15:42:18 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 53B9621F8577 for ; Sun, 5 Aug 2012 15:42:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=tireddy@cisco.com; l=1781; q=dns/txt; s=iport; t=1344206538; x=1345416138; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=WFdSx7eV/WwF0UsoV/m82ivVHTubEG2K9Cmw7iREqh4=; b=VpGqRhqJYDjm2zn/b/Lco+2dz00MV9v+SydYu4Uq1rI7ltBrr6Mw4Sd/ D5sT3iX8gZtAMGfUbwAI+e76XhBgyDw4HV/B5OEbH3YVwxk90+y0dLJFE 4czkaSx7LK+kIUkUPcdvelVFw75GdwRhcWj40MGHH6oYfIgTlPLMWXJi4 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAGj2HlCtJV2d/2dsb2JhbABFuTyBB4IgAQEBAwESASc/DAQCAQgOAwQBAQEKFAkHIREUCQgCBA4FCBqHXAMGBgubL5UeDYlOimNnhiRgA5N2gmeJdYMdgWaCXw X-IronPort-AV: E=Sophos;i="4.77,715,1336348800"; d="scan'208";a="108661679" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-3.cisco.com with ESMTP; 05 Aug 2012 22:42:18 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id q75MgHtC020215 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 5 Aug 2012 22:42:17 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.216]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0298.004; Sun, 5 Aug 2012 17:42:17 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Cameron Byrne Thread-Topic: [rtcweb] NAT behavior heuristics Thread-Index: Ac1w1ovfvzUgFxvbR0qnhkeGI2kOuAAVj+eAAAB2nYAAdXC7AAAK960AAAlqvrAACyyyAAAKKo2w Date: Sun, 5 Aug 2012 22:42:17 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A1477C1BA@xmb-rcd-x10.cisco.com> References: <038b01cd70d6$8c5bc870$a5135950$@com> <04ff01cd7104$be09bed0$3a1d3c70$@com> <501E1E40.8070203@jesup.org> <913383AAA69FF945B8F946018B75898A1477C17F@xmb-rcd-x10.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.78.115] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19088.001 x-tm-as-result: No--48.235100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Randell Jesup , "rtcweb@ietf.org" , "phdgang@gmail.com" Subject: Re: [rtcweb] NAT behavior heuristics X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 05 Aug 2012 22:42:19 -0000 > -----Original Message----- > From: Cameron Byrne [mailto:cb.list6@gmail.com] > Sent: Sunday, August 05, 2012 4:22 PM > To: Tirumaleswar Reddy (tireddy) > Cc: Randell Jesup; rtcweb@ietf.org; phdgang@gmail.com > Subject: Re: [rtcweb] NAT behavior heuristics >=20 > On Sun, Aug 5, 2012 at 3:05 PM, Tirumaleswar Reddy (tireddy) > wrote: > >> Fyi. I have not seen any traction for pcp anywhere in the mobile > space. > > > > http://tools.ietf.org/html/draft-chen-pcp-mobile-deployment-01 > describes usage of PCP in Mobile Deployments. > > > > --Tiru. > > >=20 > Yep, that's an I-D. >=20 > And, it says things like "Without > the particular considerations , PCP may not provide desirable > outcomes. Some default behaviours may even cause negative impacts > or > system failures in a mobile environment. " >=20 > Got an operators with a timeline on supporting it? How about a mobile > OS that plans to support PCP, because you will need both. And, that > would be interesting information. In my conversation Nokia supports PCP and my understanding is it can be imp= lemented as library in user space without any support from kernel. >=20 > I asked around in Vancouver about PCP, and all the operators i spoke > to said no-plans, no motivation. But, that was a small sample. >=20 > In any event, my only point is that RTCWEB should NOT be counting on > PCP. If PCP is a tool you have, use it. My point: it is not a tool > you have. Yes, If the tool is gets deployed in future it will not just help RTCWEB an= d various other applications. Even with IPv6 this draft refers to Firewalls= deployed by Mobile Networks and Firewalls usually timeout UDP sessions in = 30 seconds. --Tiru. >=20 > CB From harald@alvestrand.no Mon Aug 6 03:31:50 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE43621F863B for ; Mon, 6 Aug 2012 03:31:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PxuztBuChfbs for ; Mon, 6 Aug 2012 03:31:49 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 02D5021F85E6 for ; Mon, 6 Aug 2012 03:31:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 64A8039E0FA for ; Mon, 6 Aug 2012 12:31:46 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PzuNfuuHXx3O for ; Mon, 6 Aug 2012 12:31:45 +0200 (CEST) Received: from [192.168.1.107] (unknown [188.113.88.47]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id B79B539E062 for ; Mon, 6 Aug 2012 12:31:45 +0200 (CEST) Message-ID: <501F9D18.4080909@alvestrand.no> Date: Mon, 06 Aug 2012 12:31:52 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <038b01cd70d6$8c5bc870$a5135950$@com> <04ff01cd7104$be09bed0$3a1d3c70$@com> <501E1E40.8070203@jesup.org> <913383AAA69FF945B8F946018B75898A1477C16C@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A1477C16C@xmb-rcd-x10.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] NAT behavior heuristics X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 06 Aug 2012 10:31:50 -0000 On 08/05/2012 11:49 PM, Tirumaleswar Reddy (tireddy) wrote: >> And that's a rub, since in many/most cases, the 3G/LTE people will >> likely be talking to non-3G/LTE people, and if either side needs >> keepalives, then radio will be kept active. Note we're talking >> long-term inactive media flows and an inactive (or rarely active) >> datachannel, such as a client using PeerConnection and DataChannels to >> keep a registration or empty conference alive, or various non-phone- >> like applications. > If just 3G/LTE supports PCP and non-3G/LTE does not support PCP -> Any STUN indications coming from the non-3G can be dropped by the Mobile Network itself to avoid reaching the Mobile Node, since it knows NAT binding is alive using PCP. > 1) the at-the-moment theory is that consent verification will use ICE Bind requests, not indications 2) if the mobile network drops these, the end node will assume that consent is withdrawn, and stop. Agreed with those who argue that we shouldn't spend too much energy on optimizing for a moving target. From harald@alvestrand.no Mon Aug 6 06:58:58 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D549B21F8617 for ; Mon, 6 Aug 2012 06:58:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r4itb81CkVXi for ; Mon, 6 Aug 2012 06:58:57 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 9CD9321F8623 for ; Mon, 6 Aug 2012 06:58:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2935339E0FA for ; Mon, 6 Aug 2012 15:58:54 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ERK1fMp2Yeld for ; Mon, 6 Aug 2012 15:58:53 +0200 (CEST) Received: from [192.168.1.107] (unknown [188.113.88.47]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 27F4139E062 for ; Mon, 6 Aug 2012 15:58:53 +0200 (CEST) Message-ID: <501FCDA3.7050900@alvestrand.no> Date: Mon, 06 Aug 2012 15:58:59 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: "rtcweb@ietf.org" Content-Type: multipart/mixed; boundary="------------080305030808040409060505" Subject: [rtcweb] Comparision between H.264 Baseline and VP8 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 06 Aug 2012 13:58:59 -0000 This is a multi-part message in MIME format. --------------080305030808040409060505 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Executing on an action item: I enclose a presentation that was shown by Mohamad Raad at the recent ISO MPEG meeting in Stockholm, comparing VP8 with the "anchors" for the IVC project (H.264 Baseline, approximately). The comparisions to "RFM 1.1" refer to the so-called "Chinese proposal" for a royalty-free codec. Stefan Wenger was there; I'm sure he can give more details on the comments that were made, in particular why the "Class D" results were seen as suspicious. Harald --------------080305030808040409060505 Content-Type: application/vnd.openxmlformats-officedocument.presentationml.presentation; name="Report on the comparison of the VP8 video - edited (2).pptx" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename*0="Report on the comparison of the VP8 video - edited (2).pptx" UEsDBBQABgAIAAAAIQA4Ozh/WAIAAJ8YAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIo oAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADEmV1v2yAUhu8n7T9Y3E4xSbe13ZSkF/u4 2keldj+A2icJmw0ISNb8+2Hnw67l1U0OiJsoBDjnASTel5PpzWNZJBvQhksxI5N0TBIQmcy5 WM7Ir/uvo2uSGMtEzgopYEa2YMjN/PWr6f1WgUncbGFmZGWt+kipyVZQMpNKBcL1LKQumXVN vaSKZX/YEujFeHxJMyksCDuyVQwyn36GBVsXNvny6H7ekfxWsCTJp93AKteM8LIKUHfQ3jka CtOZw5QqeMasWx3diLxDNtpTpW5mPcasuDJvHDrpz1D1PIVqJ9jP++m2U/Mcklum7Q9WOnSq lKVKg3GrrhOlz0fqQZWLBc8gl9m6dEHSdrCyeNJMS8bFYRH/gzGFI/zOjHVHT1uNiW+yVuwX Me1pwnCcQnARZCdOIXgbneBddIL30QkuoxNcRSe4jk7wITrBZBwfIc6tKKQFc9CKVsM7TSv2 0D1Z6d+tlsr4PpRj4CGCDYe/QQiOgYcIrHNbQOtP/FHUYQYzsocC7uy2AO/7bpvQQxS1pfjG tnJt925h18BvQsdVtRKdyxTGRezWey5TGF+BYwrjNHBMYbwHjimMG8ExhfEnOKYwjgXHFMbD 4JgCuRokVMybvKWq+Mv7Rapa25676kFuaPPd+x40oYeEoxnZBsLvRkdemzTnAXnXMSyQdxHD AnlXMCyQd/nCAnnXLiyQd+HCAnlXLSyQf8lCE0W6q101uH6BuoK6htMfwofqdzV7pNxjGrTl cKx/95WOjxld3fv0hJ0aNlTl/hzynty0/nth/g8AAP//AwBQSwMEFAAGAAgAAAAhAGj4dKEF AQAA4gIAAAsACAJfcmVscy8ucmVscyCiBAIooAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AACskttKAzEQhu8F3yHMfTfbKiLSbG9E6J3I+gBjMrsb3RxIptK+vaHgYWEtgr2c0z9f8s96 s3ejeKeUbfAKllUNgrwOxvpewXP7sLgFkRm9wTF4UnCgDJvm8mL9RCNyGcqDjVkUFZ8VDMzx TsqsB3KYqxDJl0oXkkMuYeplRP2GPclVXd/I9FMDmomm2BoFaWuuQLSHWDb/R1s6YjTIKHVI tIipkCW25S2ixdQTKzBBP5Z0PnZUhRrkPNDqvEA87NyLRzvOoHzVqtdI/W9Ay78Dha6zmu6D 3jnyPGOCnHZ8M8XIMibKZexo+6kfuj4nEO2ZvCFz2jSM8ZNITi6z+QAAAP//AwBQSwMEFAAG AAgAAAAhAMRG2VDZAAAAzgEAACAAAABwcHQvc2xpZGVzL19yZWxzL3NsaWRlNC54bWwucmVs c6yRwWrDMAyG74O9g9G9dhrKGKNOL6VQ2GnrHsDYSmKaWMZyx/L28w4DBwq77KZfQp8+0P7w NU/iExN7Chq2sgGBwZLzYdDwcTltnkFwNsGZiQJqWJDh0D0+7N9wMrks8egji0IJrGHMOb4o xXbE2bCkiKFMekqzySWmQUVjr2ZA1TbNk0o1A7oVU5ydhnR2LYjLEsvlv9nU997ikextxpDv nFCBMvL75B0WqkkDZg1SVm2u6p0s7qDua23/U4t/jF7NQre88qr6rKrQ/pqp1Re6bwAAAP// AwBQSwMEFAAGAAgAAAAhAK05BGDZAAAAzgEAACAAAABwcHQvc2xpZGVzL19yZWxzL3NsaWRl My54bWwucmVsc6yRwWrDMAyG74O9g9G9dprCGKNOL6VQ2GnrHsDYSmKaWMZyx/L28w4DBwq7 7KZfQp8+0P7wNU/iExN7Chq2sgGBwZLzYdDwcTltnkFwNsGZiQJqWJDh0D0+7N9wMrks8egj i0IJrGHMOb4oxXbE2bCkiKFMekqzySWmQUVjr2ZA1TbNk0o1A7oVU5ydhnR2LYjLEsvlv9nU 997ikextxpDvnFCBMvL75B0WqkkDZg1SVm2u6p0s7qDua23/U4t/jF7NQre88qr6rKrQ/pqp 1Re6bwAAAP//AwBQSwMEFAAGAAgAAAAhACPzcKTXAAAAzgEAACAAAABwcHQvc2xpZGVzL19y ZWxzL3NsaWRlMi54bWwucmVsc6yRwWrDMAyG74O9g9F9VppDGaNOL2NQ2GntHsDYSmKW2MZy S/P2cy/FgcIuu+mX0KcPtNtf50lcKLELXsFGNiDIm2CdHxR8nz5eXkFw1t7qKXhSsBDDvnt+ 2n3RpHNZ4tFFFoXiWcGYc3xDZDPSrFmGSL5M+pBmnUtMA0ZtfvRA2DbNFlPNgG7FFAerIB1s C+K0xHL5b3boe2foPZjzTD4/OIE+ZOLj5CwVqk4DZQVSVm2u6lYWd8DHWpv/1OKb0adewjmv vKo+YxXuZrj6QvcLAAD//wMAUEsDBBQABgAIAAAAIQDYA4Jr1wAAAM4BAAAgAAAAcHB0L3Ns aWRlcy9fcmVscy9zbGlkZTEueG1sLnJlbHOskcFqwzAMhu+DvYPRfVbSQxmjTi+jUOhp7R7A 2EpiltjGcsfy9nMvxYHCLrvpl9CnD7Tb/8yT+KbELngFrWxAkDfBOj8o+LwcXl5BcNbe6il4 UrAQw757ftp90KRzWeLRRRaF4lnBmHN8Q2Qz0qxZhki+TPqQZp1LTANGbb70QLhpmi2mmgHd iimOVkE62g2IyxLL5b/Zoe+dofdgrjP5/OAE+pCJz5OzVKg6DZQVSFm1uapbWdwBH2u1/6nF N6OTXsI1r7yqPmMV7ma4+kL3CwAA//8DAFBLAwQUAAYACAAAACEASoytlNkAAADOAQAAIAAA AHBwdC9zbGlkZXMvX3JlbHMvc2xpZGU1LnhtbC5yZWxzrJHBasMwDIbvg72D0b12GugYo04v pVDYaesewNhKYppYxnLH8vbzDgMHCrvspl9Cnz7Q/vA1T+ITE3sKGrayAYHBkvNh0PBxOW2e QXA2wZmJAmpYkOHQPT7s33AyuSzx6COLQgmsYcw5vijFdsTZsKSIoUx6SrPJJaZBRWOvZkDV Ns2TSjUDuhVTnJ2GdHYtiMsSy+W/2dT33uKR7G3GkO+cUIEy8vvkHRaqSQNmDVJWba7qnSzu oO5rbf9Ti3+MXs1Ct7zyqvqsqtD+mqnVF7pvAAAA//8DAFBLAwQUAAYACAAAACEAFx81x9kA AADOAQAAIAAAAHBwdC9zbGlkZXMvX3JlbHMvc2xpZGU3LnhtbC5yZWxzrJHBasMwDIbvg72D 0b12mkM3Rp1eSqGw09Y9gLGVxDSxjOWO5e3nHQYOFHbZTb+EPn2g/eFrnsQnJvYUNGxlAwKD JefDoOHjcto8g+BsgjMTBdSwIMOhe3zYv+Fkclni0UcWhRJYw5hzfFGK7YizYUkRQ5n0lGaT S0yDisZezYCqbZqdSjUDuhVTnJ2GdHYtiMsSy+W/2dT33uKR7G3GkO+cUIEy8vvkHRaqSQNm DVJWba7qJ1ncQd3X2v6nFv8YvZqFbnnlVfVZVaH9NVOrL3TfAAAA//8DAFBLAwQUAAYACAAA ACEA+eURnnQBAACjCQAAHwAIAXBwdC9fcmVscy9wcmVzZW50YXRpb24ueG1sLnJlbHMgogQB KKAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC8ls9OwzAMxu9I vEOVO0uzf2xo3S4IaQckBOMBQut1FW0SxWGwtyfqxpZNk7lEvVTy19b56bOdZLb4aepkCxYr rTImeilLQOW6qFSZsffV092EJeikKmStFWRsB8gW89ub2SvU0vmfcFMZTHwWhRnbOGceOMd8 A43Enjag/Ju1to10PrQlNzL/lCXwfpqOuQ1zsPlZzmRZZMwuC7/+amf8yv/n1ut1lcOjzr8a UO7KEhzrqgCfUNoSXMbaEPfqfc+TMn4dQgxiUijtAJ8lOrAnlkBEHgSC4oqKRZjTpyDuY3pD QIwpCNHviEKQBRFRzXDyo4Y3t6v90B2bNhApQzrzg4IQ45hVcX5XCaa3DXn7pGsSk6Htz8vZ DcTDbrL/gsSKag0xNiOyQCK6OadObaEOhoiUwhh1RDGkIERUim0F3y9Wm2ByjxJJ4U/gTg68 KUUx7AhiQEFMO4KYUBAiqhXGAl50xVH6o+BnV6v5LwAAAP//AwBQSwMEFAAGAAgAAAAhAHwN Gd/ZAAAAzwEAACEAAABwcHQvc2xpZGVzL19yZWxzL3NsaWRlMTEueG1sLnJlbHOskcFqwzAM hu+DvYPRfXaSQxmjTi9jUNip7R7A2EpilsjGcsfy9vUOAwcKu+ymX0KfPtD+8L3M4gsT+0Aa WtmAQLLBeRo1fFzenp5BcDbkzBwINazIcOgfH/YnnE0uSzz5yKJQiDVMOccXpdhOuBiWISKV yRDSYnKJaVTR2E8zouqaZqdSzYB+wxRHpyEdXQfissZy+W92GAZv8TXY64KU75xQFDLyefYO C9WkEbMGKas2V3XbyiIP6r5X+59e/KP0btZwzRuxqs+qCt2vmdq8ob8BAAD//wMAUEsDBBQA BgAIAAAAIQDyx20b2QAAAM8BAAAhAAAAcHB0L3NsaWRlcy9fcmVscy9zbGlkZTEwLnhtbC5y ZWxzrJHBasMwDIbvg72D0X1WkkMZo04vY1DYqe0ewNhKYpbYxnLH8vb1DgMHCrvspl9Cnz7Q /vC9zOKLErvgFbSyAUHeBOv8qODj8vb0DIKz9lbPwZOClRgO/ePD/kSzzmWJJxdZFIpnBVPO 8QWRzUSLZhki+TIZQlp0LjGNGLX51CNh1zQ7TDUD+g1THK2CdLQdiMsay+W/2WEYnKHXYK4L +XznBPqQic+zs1SoOo2UFUhZtbmq20YWecD7Xu1/evGP0rtewzVvxKo+YxW6XzPcvKG/AQAA //8DAFBLAwQUAAYACAAAACEAxeGPptkAAADOAQAAIAAAAHBwdC9zbGlkZXMvX3JlbHMvc2xp ZGU5LnhtbC5yZWxzrJHBasMwDIbvg72D0b12mkPZRp1eSqGw09Y9gLGVxDSxjOWO5e3nHQYO FHbZTb+EPn2g/eFrnsQnJvYUNGxlAwKDJefDoOHjcto8geBsgjMTBdSwIMOhe3zYv+Fkclni 0UcWhRJYw5hzfFGK7YizYUkRQ5n0lGaTS0yDisZezYCqbZqdSjUDuhVTnJ2GdHYtiMsSy+W/ 2dT33uKR7G3GkO+cUIEy8vvkHRaqSQNmDVJWba7qZ1ncQd3X2v6nFv8YvZqFbnnlVfVZVaH9 NVOrL3TfAAAA//8DAFBLAwQUAAYACAAAACEASyv7YtgAAADOAQAAIAAAAHBwdC9zbGlkZXMv X3JlbHMvc2xpZGU4LnhtbC5yZWxzrJHBasMwDIbvhb2D0X12msMopU4vpVDYaesewNhKYppY xnLH8vbzDgMHCrvspl9Cnz7Q4fg1T+ITE3sKGrayAYHBkvNh0PBxPT/vQHA2wZmJAmpYkOHY PW0ObziZXJZ49JFFoQTWMOYc90qxHXE2LCliKJOe0mxyiWlQ0dibGVC1TfOiUs2AbsUUF6ch XVwL4rrEcvlvNvW9t3gie58x5AcnVKCM/D55h4Vq0oBZg5RVm6t6J4s7qMda2//U4h+jV7PQ Pa+8qj6rKrS/Zmr1he4bAAD//wMAUEsDBBQABgAIAAAAIQCZ1UED2AAAAM4BAAAgAAAAcHB0 L3NsaWRlcy9fcmVscy9zbGlkZTYueG1sLnJlbHOskcFqwzAMhu+DvoPRvXaaQxmjTi+lUNhp 6x7A2EpimsjGcsfy9vMOAwcKu+ymX0KfPtDh+DVP4hMT+0AadrIBgWSD8zRo+Liet88gOBty ZgqEGhZkOHabp8MbTiaXJR59ZFEoxBrGnOOLUmxHnA3LEJHKpA9pNrnENKho7M0MqNqm2atU M6BbMcXFaUgX14K4LrFc/psd+t5bPAV7n5HygxOKQkZ+n7zDQjVpwKxByqrNVb2XxR3UY63d f2rxj9GrWcI9r7yqPqsqtL9mavWF7hsAAP//AwBQSwMEFAAGAAgAAAAhAP+8w5SbAgAAHQ4A ABQAAABwcHQvcHJlc2VudGF0aW9uLnhtbOyXzW6jMBDH7yvtOyBfVy2B8BUUUml3ValSV4qa 9gFcmDSoxiDbySZ9+h0bpzhhD30Abth/z3jmZ88Ay7tjw7wDCFm3vCDB7Yx4wMu2qvlbQV6e 728y4klFeUVZy6EgJ5DkbvX927LLOwESuKIKTT10w2VOC7JTqst9X5Y7aKi8bTvgqG1b0VCF Q/HmV4L+RfcN88PZLPEbWnNi7cVX7Nvtti7hd1vuG9y+dyKAmTjkru7k2Vv3FW9uFpchSXqA zf5VgrpvuZJIh6wwbcmqP1QqEA/Vo1RXM15dFSQMojTK5kmE7ESuZ3BtQPzV0v+fOW8VyCuX F3OOk7n1cqEPYbghPVR9MHHiRBFqexPEp5w6snF/Kbs5RGPrhWMdj+QEr9MngWQsB46cjuXQ kbOxPHfkxVh28w5mYz1yzANzPBeZJ7GrG3D98bmQNx9eeSzIIoii2QyTLU8FSbI4MwN16rBi ZCkAeHS0bM3JWbPPldrs7MMcUAVbumfqGY5qo04MVkua49x6LezT01p4jOoiBX7zstHZ+e4S dmBBh2saKh4LgpFR9oYFzoiHbp7p6+bjvCNmqZhZAvSR/xTv+qKjb1VzO0TrHW6FNbve81L1 hWA201FI9BRgwsR7B6F7CFY1FgrNZcvq6r5mzAx0P4BfTHgHirupY18PV6vMrp7mtqUlsvvR 8BumdHI0B3olAO2FUl4JpRxwYISGjOWhHeFjOKCJ4lQHPPExUCyf+cCnv5YTnwPTUCyfaOAT zNMgmS6QripNxQKKHUBZmJn2MHUgTcUCSgZAYZjhBZpaEN4gTcUCSh1AaTSferR5cWkqFlA2 ANJ08PtjatIHpqlYQAsHUBKnU5M2N0hTMT8i409M/Lx1/4ZW/wAAAP//AwBQSwMEFAAGAAgA AAAhAGYB6AJoAwAA9AgAABUAAABwcHQvc2xpZGVzL3NsaWRlMS54bWykVm1v0zAQ/o7Ef7D8 CSTa9G2ji9aiNlCExKDqC989x1ksHNuyr6UV4r9zceJtjCFG6YfWse+e3HN+7q6Xbw6VInvh vDR6QvvdHiVCc5NLfTOh282iM6bEA9M5U0aLCT0KT99Mnz+7tKlXOUFv7VM2oSWATZPE81JU zHeNFRrPCuMqBvjobpLcsW+IWqlk0OudJxWTmrb+7in+pigkF28N31VCQwPihGKAkftSWh/R 7FPQrBMeYYL3LyFNkRlfq7z+9XbjhKhXev/e2bVdunD8ab90ROaYL0o0qzAtNGkPWrPwqNEM F8kD95uIxNJD4arpJUuRGzlMKCb/WH+jE0vFAQhvNvndLi8/P2LLy3ePWCfxBRjB7UtrVg2j 3+kMIp2NBCVI/5ZVY8rQ9aPhXz3RBnnW9Bt6/NM+gtWca3hbEjhazAwHF9Ba0+Y8pCS6eExr yBcc5iY/1tyv8bfGYalGBc12YAoJpDAa1pwpRL3o4SdA3jdWHtZwVCLkD1myNGA4vC3FakEL 3dmuKbkON5dLB3eJhelKWOOAGE2gFISbyjInPT6aIux8WY7JXubC4FkuOAETtj98ychqcUX6 3T7BOrndu8T0A95+DCKE85dIiHBYCyGttXNWLE9BCfRhSmaal8b57gMMofMlc2x1P5bZlpL7 +cCoMX94TfFOcNno5s/qGUb1rHfXEAQ0qG8IyynK4yQB+d11IyCsOCyHqLl/EVJIyP+JIytR CyCZJguhlHDkQVKfJDTiK8iUYNhp2yKH6YutlqH/wrEW2lZVr8h7gW1TH18GPZ30ol91dGVK VrH8FKSopVN8H6O7YiwnL05Cazn9CXUjeHkS7iOXQjKcKTsFOK9ekdnOg2NKspcP4P+nkEI9 xemCrf6jx15hQ9PfOTmh3+fzi/NBNp535v3RojN6e/G6M1ucn3UWZ8PRKJuPZ9nw3Q+KPv1R yp0Ig+xDHMi4+dsQrCR3xpsCutjakmaaJtZ8E84aGQZqv9dO5T1TEzo+Ox8Mh+PesO3cGGTo CDFYZBDnJFfuitnP+1AEOP5BuCxsWUwgKqg2vTPBpiIrPKj5gm6JY68NrWKj42DNd9gKpc5F IbUEQQlObGAOJlQLLBhsNtiFN2HGQLUyBto4AxK+sYWuV+3rcIn/WaY/AQAA//8DAFBLAwQU AAYACAAAACEA9ptZSIkDAAAACQAAFQAAAHBwdC9zbGlkZXMvc2xpZGUyLnhtbLRWTW/bOBC9 F9j/MNBp92DLctxsIsQuYrduA/TDSJzeaXIcEUuRLEk7Nor97zukpBROXKRBsReJImce5z0O Z3TxZlcr2KLz0uhxVvQHGaDmRkh9N85ul/PeWQY+MC2YMhrH2R599mbyx6sLW3olgLy1L9k4 q0KwZZ57XmHNfN9Y1LS2Nq5mgT7dXS4cuyfUWuXDweA0r5nUWevvfsXfrNeS41vDNzXq0IA4 VCxQ5L6S1ndo9lfQrENPMMn7IKQJMeM3SsS3t0uHGEd6+97ZG7twafnzduFACtIrA81qkiXL 24XWLH1qMqNB/sj9rkNi5W7t6skFK4kb7MYZib+PT3JiJe4C8GaS/5jl1Zcjtrx6d8Q67zag CB42jawaRk/pDDs6SxkUQvHAqjFl5PrR8H88aEM8I/2GHv+87cAi5whvKwh7S8qECNXaNYtJ j87ek6ZJrLCbGrGPxFf0TpOsVD7chL3CJAiFzUoCpwfJr1jMUNS9y9sMhHQhaQS+DjOFjHK5 lTFMrnRwRmx4TJQL0iTQkbRAqMWCOXb9U7zIj5W0MwXdRUjDRsKfC3nSCTkzOlCawUIxjpVR Ah0Mf09WKSgpOuX/F0Vvb55R9BqtccHDIzWfns0BUjrEMDEaQoXATW2Zk54+OXNOogCzCSA2 jopEslDMB7j88B4sOmkErDDcIzbedrNSkqs9sC2Tiq0oW78uzmArBRqCFsiBalaCufo6g+v5 Jyj6BfzJPNyjUkDvGERcexkJQEfVKskfM2m2XrzMvxWBouOVceDx24bqLfqXoRxL87/6BxhN 2qbcPXZrjp3MspIepLZ0DJzy1snVJt4ZYEJQtfTooY6NINDgYKtn8Y+E21yslDGrZ/LmsTcx a12e1IIDVo/94nmNeqcvjL09MOpkDxlDOXmoNRXr3ygkqZ50jYaq/kdPFcqm+k+XYZx9n07P T4ezs2lvWozmvdHb8797l/PT173565PRaDY9u5ydvPs3I59iVHKHqadddb2ZJp/0w1pyZ7xZ hz7dwrxprLk19+iskam3FoO2QW+ZGmfD4nw0GI6KYtQWcooylcQuWqLQ9Uyu3Cdmv2zTodKv QEA3S1OW7nU8dTL9YUJVVda0EAkH3TKnuhC/+VJ3TZaqwjiTWuBaahkwA8rHwFwYZxrp54Wq LV35ZdNv6mtjQhtnQqIdW+g4arejIf2/TP4DAAD//wMAUEsDBBQABgAIAAAAIQBP17tZdAQA AEsLAAAWAAAAcHB0L3NsaWRlcy9zbGlkZTExLnhtbNRWTW8bNxC9F+h/IPbUopYlWZLrCJYD S46CAI4j2E7uFHdWy5ZLsiRXtlr0v/eRu+vEX3XSXtrLfpAzw5k3bzhz/Pq2UmxLzkujZ9lw f5Ax0sLkUm9m2cfrZe8oYz5wnXNlNM2yHfns9cn33x3bqVc5g7b2Uz7LyhDstN/3oqSK+31j SWOvMK7iAb9u088dv4HVSvUPBoPDfsWlzlp99zX6piikoDMj6op0aIw4UjzAc19K6ztr9mus WUceZpL2PZdOEJm4Unl8e3vtiOKX3r519squXNq+2K4ckznwypjmFWDJ+u1GK5Z+NcTw0X+g vuks8elt4aqTYz5FbOx2lgH8XXxCiU/pNjDRLIrPq6L88ISsKN88Id3vDoAHd4fGqJqIHodz 0IVzLYMiNryLqhHlUD034lfPtEGcMfwmPHGx7YzFmKN5W7Kws0AmRFOtXLOZ8OjkPTBNYIXb ucl3MfA13mmRT5UPV2GnKAECt/kUxvEA/IpHhpLunX7MWC5dSBgxX4WFIg4utzCGk0sSpgJn 8oYqx4AlICutLayvuOOXz5qMIfIpDoffnZP4bFB8HstRh+XC6ACmsZXigkqjcnLs4N8hK3Pw ogP/W0CN4GnU5GkdTCEDK+DbleAKeTqaDAbgn9JXVlxSXotYV7MMtYrlBoMmMdHG47wgjazi 7nyWTYbj0QSWpM4R9izrtQtRb10vcWJiRgE0ZtlP1S89FaL9uBnduqirljnIylqKFTlp8taD VID/iARv5ZY0CyUP7NPqiHmiyrNgWEUEf0pijn6rpaN4t3jg4tLimntSUhOzDnihJLwlIQtJ OcJLEu8+LdgDRr1EUXK473BzPEHVRbH6RmNPGNljuK6Tc8A4BoeYkWtfr+NFHiRXasdMHSy5 eD8DBoQvauciSy+X76GPu37DbmRAEWPvSzOeycqqBFMqJyaBFi5JmORbLhVfA6V4/o3M42Lt Kd+Lx0POdYUI+O4ysYZ4bmzAGm9c0XTDIqxwhf0QHwf7gx/3H+CyfgnlB8CghBuVF+v9YV6a 4k83AB7/E5oTM2tPbgtUXVfMkbKR+23euRaAvoG8cOhizMvfCULCEWjvn82aRUGiPAzytoUR 9HRkE+kNJEptlNns4mYkzuIszg4b2kt/X+z70tSYHpD7CqNGqieodEczgY4uPW5NsYtO33NY OOMbp6FYUCIt5NMVKxT38Bz6mGgQ+hqewI3/YI3ep/M9ir1I0L9pSKkvdTMLBohzj05n0yhR OznL/pjPXx0eLI7mvflwvOyNz1793DtdHk56y8loPF7Mj04Xozd/ZtAZjqeRB7EJvOvGPCw+ Gq0qGRNiirCPJttvZrS+NTfkrJFpTBsO2llvy9UsG41HgzE6wqRrX/AytdbOW4TQjV9Cuffc ftimUsdUGcgt0pIF5yIKEP0sgu4sK2zEgINuI7ccyhC71t28lte4fWNvKqSWgTLUBzjq0Kg0 gTXo2ian62Z0qS6NSc0JJyVLeLem41d7HD4xCp/8BQAA//8DAFBLAwQUAAYACAAAACEAVxem 6DwDAACjCAAAFQAAAHBwdC9zbGlkZXMvc2xpZGU0LnhtbMRWXW/TMBR9R+I/WHnaHtq0Xem6 qN20dgxNGlCxbu+ufbtYOLax3bQV4r9z7SSgjQ5WJsRLPmzf43uOb+7J6GxTSFKCdUKrcdJt dxICimku1P04uZ1ftoYJcZ4qTqVWME624JKz09evRiZzkhOMVi6j4yT33mRp6lgOBXVtbUDh 3FLbgnp8tfcpt3SNqIVMe53OIC2oUEkdb58Tr5dLweBCs1UBylcgFiT1mLnLhXENmnkOmrHg ECZGP0jpFJmxG8nD3Zm5BQhPqnxnzY2Z2Tj9oZxZIjjqlRBFC5QlSeuJell8VbgMH9JH4fcN Es02S1ucjmiG3MhmnKD423DFIJrBxhNWDbKfoyz/uGMty9/uWJ02G2AGPzYNrCpGv9LpNXTm wksg3R+sqqUUQ681++yI0sgz0K/osQ9lAxY4B3iTE781qIwPUPW6ajLq0ax3qGkUy28mmm8D 8QXe4yDNpPM3fishCoJp0wzB8YLySxoqFFTr/DYhXFgfNSKu8FMJFGu5ltGfzsF54sCvzAgV 8XggNQwoPqOWfnoSLbCjGe6LKTf54WMl4NMyHjUyTrXyWGRkJimDXEsOlvReJqrgWBKN7v9J z7VuOoYjeknuZsOqZyC7lQP+SOXFnkeGitch+x/1wUL7nJjVQgomt4SWVEi6kHCYPUiqOtR4 sngJx1/KWtW/qjBSdton7QE5wAbH9dod/uPdum1s1OTgWqjV5jd77Sl8+Dau7qbkQfJ/1gMs tm9shDu+vOlytifYDhCCDgJWUEnW1MUCI2uBp+xzIBa+rIQFThh6gLdoKd4RaowUwNuPtn7J 1x4/+sYLsDFfO2wjJrbolRXj5OtkcjLoTYeT1qTbv2z1L06OW+eXgzetyzdH/f50MjyfHr39 lmBMt58xC9F2rhr7xMFfLKsQzGqnl77NdJFW3pcavQZrNLJE++t2ag8tKRZv77h3PBwMhoOm N2CWsW812SKFxtaYtO+p+VjG+kC3RnmnccigP9cd/ecSbH2iwIlA2KuauaEYjIhz1fggX2EZ YPnDUijhIcGzwf8G68eJAvy/wJaoOcwrSyg+ae1rT4hIob9W0OGp3i6Ijj78HQAA//8DAFBL AwQUAAYACAAAACEAzT2BBj0GAAC2MAAAFQAAAHBwdC9zbGlkZXMvc2xpZGU1LnhtbOxb627b NhT+P2DvQAgY0GGQrJvlC+IUthwXBZo2cJwC+0lTdKxNEgWScZIVfZc9y55sh5Tk2K6d2G22 OInzwxZvh+f6HYo+OXp7kyZoRrmIWdYxHMs2EM0Ii+LssmNcjAZm00BC4izCCctox7ilwnh7 /PNPR3lbJBGC1Zlo444xlTJv12qCTGmKhcVymsHYhPEUS2jyy1rE8TVQTZOaa9tBLcVxZpTr +Tbr2WQSE9pn5CqlmSyIcJpgCZyLaZyLilq+DbWcUwFk9Oollo5BMnKeROpb5CNOqXrKZu94 fp6fcT38cXbGURyBvgyU4RTUYtTKgXKabmYwDR5qK8svK0q4fTPh6fERboNs6KZjgPJv1Scs wm16IxEpOsldL5l+WjOXTE/WzK5VGwAH802VVIVE34rjVuKMYplQ5MylKqZiWPqBkT8FyhjI qcQvxCMfZxUxJbMin0+RvM1BM1KRKucVg1of1XwBOtXKkjc9Ft0qwcfwrTtxOxHyXN4mVCsE 2MZtIA4foP4EKw+lmdm9MFAUc6l1hEQqw4Ri8OVSjfJ4SMVVIsURqEOCNUoaNIvOMMfDjaSU aLgNmwK/FXPwWGhvsw69SochyyR4GDpLMKFTlkSUI/fHNBpH4A+V0p9GmZ+RbbWsAEmGVhT6 kGUohzCHgFljoXBytiOxNUQQzsiUcbHK1/ghxlZogdHLJbu72puCB9RBBEBJcsA4GqHu5xCN saAJtH5dErRwMO1lEPA/5JGXHOfTmAw44FER3+8WelaBy6+8dITHEOne3C9XF2FAjjvCm6J/ dZVCvGJLQLEPAsIu13h2xeOO8aXvu1230e+Zvb7nmH6vGZpNr+uYg+DkJBy4vu+5zlcD1jh+ O2XR+yrNQPsbaE9jwplgE2kRltaKHFHL2TXlOYt1mnDsMtfMcAIO6Nbrthc03KDEJGBQh3jF qEYnxbt++FawFchuNZzALnDbbbWCVl2H+B16B37Thj8DKQz3bNdXjQI1K0qlgpW3lY99LDHS uto5rUplT9AdYN04Kb8A4iYxF3LIrnUE6kbIlDYMcMwsKgf0dLVeY+776PhLPXTduu93zcbJ SWD6nu+aPdtvms16rx+2Bn0n9LpftUcvLtMd40QpUbPxjseQTpV0cQTbIsVFAIeAQhOP1Q+x BCJXe0mOph2jbmt9az4I4uz6PFepwS0UtF3GgQSFcHIJy/64ElKvFDnpTsBtVEIkZ1Ig7VqF XXWfHlXBXehAK2IpaV2cAxD+BR4BalhIX4oknUwoUUFTJCBYptk//ufvJejYjBdb0IXMCief TKfoCaSnjjGKUyrQR3qNhizFmXJR2AEvzDg9R6exgljtvovbzxMlWGCuU0lAbynmHzpG0Kw3 QUpoDBcbI33ggd5emayVBYkWliDlK4WxvO8zFn86S/X65hBLit7kMSUUXceCInI1jsky+C+q cPk48yIsOD2l/BI8y9nFfhty4N1ZbNXFipG52/zfmyqXLeJzDd7MnkADOnzmQXjvUfoO2J4w Vn5/RaD23GxzcbDNulfQvYibz6/ENvcB7HfF09Me4sIEC4G6r8R48/PcM0pIZtOyf3nR9ikv SjrGuDzJV6en74qn//jssHRdpBjc9Hr0m+Na9RW76ZPZj753HZwBtL4fB8kdnMGzvIMz7PoO vhYZXmQG7q04x4b3zm3uaPb+LmUfYf0+JDedpuUcUHdvUPdeW7mB1TjY6pnYyrfcV2irZ5PA 7gu04sUx3DVtrZI8JCvwhsf8VcZsHF4XH67a2IsrM9NzLO8V4t+zvIXx7FcZVy8oV/UPuUr/ iK7L1vYDAO3DWX2PctX2t1mea7VWoulwtflgRcna26x9TYbbO4PjWP7BGR7zalMlXVUsB98L BXiLbV0NWI6VFZa6FLgqD6+KBxerHHu9VuCGTahydPyB6fdbDbM7COrmoO75fthrdkPvpKpy JJzqSvRHLXX0Wi3PaXiBp0sSgd81pY5VpTtJ+CnOP800rEABv6Q81F05lOyrGhsoir+bAgXR cQoDqqxTZmV9Z45hMUwbZVVpfHQFFb9xFtFJnMWSGghq7iXmsmNkFP7lAEpQWURHRZV4OmRM loWRmhLsWJJWT+V28Aj/dXD8LwAAAP//AwBQSwMEFAAGAAgAAAAhAK/cewe3BAAAsgwAABUA AABwcHQvc2xpZGVzL3NsaWRlMy54bWysV9tuGzcQfS/Qfxjskw1YlnWxJAuWA0uOUqOJY1hK +1hQu1wtUS7JkpRstSiQD2l/Ll/SQ642qR0bjWu9SLwOZ86cuezpq7tS0ppbJ7QaJa3Do4S4 SnUm1HKUfJhPG4OEnGcqY1IrPko23CWvzr7/7tQMncwIt5UbslFSeG+GzaZLC14yd6gNV9jL tS2Zx9Qum5llt5Baymb76KjXLJlQyfa+/Zb7Os9Fyi90uiq58pUQyyXz0NwVwrhamvkWacZy BzHx9j2VzmBZOpNZ+HdmbjkPI7V+Y83MXNu4fbW+tiQy4JWQYiVgSZrbje2xOFU4hkHzwfVl LYkN73Jbnp2yIWyju1EC8DfhF5fYkN95SqvF9MtqWrx/5GxavH7kdLN+ABp8fjRYVVn0tTnt 2py58JJT67NV1VGGq291+qsjpWFnML8yL71a18KCzUG8KchvDJDxQdT2XLUZ8ajPO2AawfJ3 Y51tguEL/MdFNpTOz/xG8ggI1GZDCMcP4JcsMJSrxvmHhDJhfcSIXOknkjNweQujP/vpenAK KDw8sb3PVXbNLLt5Ukwwiw3xIHStFcOwQu5p/Do1fhOtPNhF15KlvNAy45baL0NTZOBCDfgT QAZsHlCqe9xHuEVetXpHR2EcwazZNWiftNq9bkKBY93+oNVq96O3aknR7MqnNRK1i8JzChF+ vvI6F55yWD1LmYTX+/3j8KpUM5Pe8GyVhigdJXi+UgDoVm4OMnbi5WlMNcQcZdylVix4RkLR 5ev5lG6mE+p1Bj3aM6uFFKncEFszIdlC8v3De+So3B59/7/INrXIB5H6bkg/8g3lcWHvshEH +wd0CWrYakZ719X+Pt1TAuA8k+cBz+rK8+Nj70rTuNLjgBYrZB2maMHJiXKF9MqzHUP0wXFH F5M5+GLpfEKp5iG1CwSMO6Sff6g2Lu5v0F6qy4VQ0ateky+4sKRvoalEStqxiudS0gKMdt5y VqIieqvNBppmeH/lUMaIWeGLknuRhmWs7JZHs+3Lkodq52Av83AKivCSYD48xKQp2IJ7aMIx cfqeeg/49F904hY1GNXskfRZrPK8ZOqZAh8RtMUJQWgFPF85kZgxiMhYh0nnX8O6Y8/OC1R0 sjznFn0OJ1GyJehotHMC2SAox9dCr9wBLUPeVgcPQ/MFUDLpf8HTL4dyx6CMQwg5ugWjkTIZ Ob4MrKO9d2MwLUOttUtu96lga+S2AqkhJLnfVkx58XvlunhMa0O5kMhvEOE9gsLtNio+ffzr KuR5+enj3weE2UyURnLMCIxSmuS/VCjZJqSxSDCe3VcE7dULeoBYE+vWEJX0rUNzYWLHtrJi lPwxHp/02pPBuDFudaeN7sVJv3E+7R03psedbncyHpxPOq//THCn1R2mSDGhOl7W3TQWv+pg S5Fa7XTuD5EGm1Ur3DT6llujReyGW0fblnrN5CjpHHdarX6n1zmJxTzqdha6mVpbDOsuN5X2 HTPv15HYaN7hvklcMnBg6IRw9MsRNESixEYw2Kut5YbhMo7NVd0WZyskFKEyngslPE8QcviM sH6UKI7PDTRKyKXzqkMsb7T2Wz2jJLy4FR1G2+cwxBfH2T8AAAD//wMAUEsDBBQABgAIAAAA IQB9W7XUCAYAABctAAAVAAAAcHB0L3NsaWRlcy9zbGlkZTcueG1s7FrbbuM2EH0v0H8gBBRo HyRbF8uyEWdhy3GwwCYbOE6APtIUHauVRIFknGQX+y/9ln5Zh5TkW+Igzu7WuTgPsURyhuSZ mTOUNAcfbtMEzSgXMcs6hm3VDUQzwqI4u+oYF6OBGRhISJxFOGEZ7Rh3VBgfDn/95SBviyRC IJ2JNu4YUynzdq0myJSmWFgspxn0TRhPsYRbflWLOL4BrWlSc+p1v5biODNKef4UeTaZxIT2 GblOaSYLJZwmWMLKxTTORaUtf4q2nFMBarT0ypIOYWfkPInUr8hHnFJ1lc2OeX6en3HdfTo7 4yiOAC8DZTgFWIxa2VEO07cZDIOL2pr4VaUJt28nPD08wG3YG7rtGAD+nfoPQrhNbyUiRSNZ tJLp5wfGkunRA6Nr1QSwgvmkalfFju5vx6m2M4plQpE931UxFIPoJ0b+FihjsE+1/WJ75HRW KVN7VurzKZJ3OSAjlapyXNGp8ajGC8BUgyVveyy6Uxsfw69uxO1EyHN5l1ANCCwbt0E5/AP4 E6w8lGZm98JAUcylxgiJVIYJxeDLJYzycEjFdSLFAcAhwRqlDppFZ5jj4UZVamu4DZPCeqvF wWWB3mYM3QrDkGUSPAydJZjQKUsiypHzfYjGEfhDBfpuwLysWy3LR5Khj5chGg5OkG3ZK9AW oGnkwIm/C+UrjvNpTAYcYqzw2eOllvVg9CrkR3gM3uvOsV4XwhANC8WbPHpdSkVxMSVE5icB rpTrGL3mccf42vecrtPs98xe37VNrxeEZuB2bXPgHx2FA8fzXMf+ZoCM7bVTFn2sqBPu79FV GhPOBJtIi7C0VvBeLWc3lOcs1tRn10v+nOGkYzhOs9l0Wq1Auzz4KCxQu221UB1xau364v7G 1mio1bT9esFFoNVvNbTbLhjJ94I6/BlI8ZJbdzx1UzBBpakEWAVrednHEiON1dapQip7AnYQ v+Ok/IGwncRcyCG70TSsb0IGaAAnjyFflR16uJLXPPIxOvzaCB2n4Xlds3l05Jue6zlmr+4F ZtDo9cPWoG+Hbveb9uhlMd0wThSIehnHPIYUoXYXRzAtUqvwIbEVSPyodkVZ46SaS3I07RiN usZbr4Mgzm7Oc0V3TgHQ01gUSBfh5ArE/roWUkuKnHQn4DaK5MmZFEi7VmFX3aZ7VXAXGGgg Voj44hyOCl/AIwCGJUpWKulkQokKmoJUQUwv//Dff1aoYzNfPEEvZAvI5plOOxOg3I4xilMq 0Cm9QUOW4ky5KMyAl0acnKOTOCNTpt13efo5+YMF5phKArilmH/qGH7QgHBTN8Plm5FO4tDa KxOQsiDRmyVI+UphLPd5xuK7s1Svbw6xpOj3PKaEoptYUESuxzH54z1ZcHpC+RV4lr2N/Tbk wMX5Yt3Fip652/zfkyqXLeLzAb6Z7QABHT7zIHz0eLggth3Gyp/vKCRejm00uW/IMxfbWmRd 2YtPLq/DDpdv2g6PEeez7POzDmfr3g0Lnx/JwgQLgbpv2lDzM9krSipmywp+29Yqixcj6yZ/ gYSGsDqJw7vAcXkar05Az4qdHeZ/025azb2t4GFrl2e1dY9fJjnTDixvawuta3wtMfSG8lJv WwZ8BTZbfdx7OWS3Dt1KAHmO5bybAHpZ54VH7eI0LXtvFwXR/W9HP/nlwON28d+RXd5Qwgn3 CUe/NtcfX3cZQG7rHZ3YXlHCcZtWY59wdpJwNj/drxzVXP8ZkbNZ9/6p5wd/Kn3s3FC8jevv k9ALSUKO5e7Jbidk91iUmI5n+Xu77MQumxPFShKC59L61hbarPuVJSH1QKRKl+B3qRxq+V7X ZpV9Zb2bLjasClCrUq7lmrNer+U7YQA1Z7Y3ML1+q2l2B37DHDRczwt7QTd0j6qaM8KprnX9 oYVnXuC5gdsImmX11wN1Z1UpLUn4Cc4/z3RhAVQIS8pD3ZRDTbB6AwZVt4shUHEZp9Chauxk Vhbb5RiEYdgoq2pvo2v4WhBnEZ3EWSypgaCoV2IuO0ZGoaYZ6gFZREdFGWo6ZEyW69SaYMZS tboqp1OYQ+3vfwAAAP//AwBQSwMEFAAGAAgAAAAhAOBUP/+BAwAABggAABYAAABwcHQvc2xp ZGVzL3NsaWRlMTAueG1srFXbbhs3EH0v0H8Y7Lu0kizb8sJyICmW4cJxBFvpO02OtES4JEFy dUFRoL/R3+uXdMjddeI4AdImeljtkjOHc85wZi7fHCoFO3ReGj3Nhv1BBqi5EVJvp9mH9bI3 ycAHpgVTRuM0O6LP3lz9+sulLbwSQN7aF2yalSHYIs89L7Fivm8satrbGFexQJ9umwvH9oRa qXw0GJzlFZM6a/3d9/ibzUZyfGt4XaEODYhDxQJF7ktpfYdmvwfNOvQEk7xfhHRFzPijEvHf 27VDjG96d+Pso125tH2/WzmQgvTKQLOKZMnydqM1S5+azOgl/8J92yGx4rBx1dUlK4gbHKYZ iX+MT3JiBR4C8GaRf1rl5fuv2PLy+ivWeXcARfB8aGTVMHpNZ9TRWcugEIbPrBpTRq53hn/0 oA3xjPQbevx+14FFzhHelhCOlpQJEaq1azaTHp29J02TWOEwN+IYiT/Rf1pkhfLhMRwVJkEo bFYQOD1IfsXiDUXdm33IQEgXkkbgq7BQyOgutzKGq9vVwyVJESgTrT9qsWKOPXwTJtJiBR1I sXaB0Wuj3Lf1O+n0Wxgd6HbBSjGOpVECHYx+TE0p6C50gv8XIaNgmupwVgezkQGUfrT8AUXN Y+UQ5oB+KUGd9NHjpyh/Y8yW7lHJPGwdI0kEbKigoPYIZgO3K6B4zF57SIVM28HA76sJGA0M 9sYpsZcC4Yl56fsvktikJ+Xof12Kd6vrm97dDJjWptacjpYalvjkauaOMBoMhxBKhKaBkU4x XpZisyyl1hqj+nCr4bdaJYcRdJg+SKWAm5oapDYBAtLnvkT9GtLXvCTczzCJdvR7QgKorEIS 7ecyvzfwUZPowEumFOot+ih7k6t//vrbA1dMVhQrC8/5IcuYLkoT7iiRbZ5eBkYt6wfqKpVX 126p9915KlibumDt5DT7Yz6/OBstJvPefDhe9sZvL857s+XZaW95ejIeL+aT2eLk+s+MfIbj gjtMnf22m1C0+GoqVJI7480m9EnpvBkvuTV7dNbINGGGg3ZM7ZiiQhldnJ9Ozsfjs7adUZSp Q3TREoVucnDl3jH7fpfaFQ3EgG6RliyNwLZpfjKhJiMr2oiEg26ZW5YaKV/rbtSImgal1AI3 UsuAGaWDRrML00wjjXBqPkbguum61YMxoY0zIcVO1kDHt/a4KDqNun8BAAD//wMAUEsDBBQA BgAIAAAAIQCsNRuURAYAABExAAAVAAAAcHB0L3NsaWRlcy9zbGlkZTYueG1s7FvdbuI4FL5f ad/BirTSrlYJ5A8CKh1BKNVI05mK0pH20jimZDeJI8el7Y7mXfZZ9sn22EmAZoBCp93SKXPR JP45tr9zzndsz+Ho3W0coRnlWciSjmYadQ3RhLAgTK462uVooHsaygROAhyxhHa0O5pp745/ /ukobWdRgKB3krVxR5sKkbZrtYxMaYwzg6U0gboJ4zEW8MmvagHHNyA1jmpWvd6oxThMtKI/ 36Y/m0xCQvuMXMc0EbkQTiMsYObZNEyzUlq6jbSU0wzEqN73pnQMKyMXUSCfWTrilMq3ZHbK 04v0nKvqj7NzjsIA8NJQgmOARasVFUUz9ZlAM3ipVbpflZJw+3bC4+Mj3Ia1oduOBuDfyb/Q CbfprUAkLySLUjL9tKItmZ6saF0rB4AZzAeVq8pX9O1yrHI5o1BEFJnzVeVNMXT9wMhfGUoY rFMuP18e+Tgrhck1S/HpFIm7FJARUlTRLq9UeJTtM8BUgSVueyy4kwsfw1MV4naUiQtxF1EF CEwbt0E4/AH4IywtlCZ691JDQciFwghlsfAjisGWCxjF8ZBm15HIjgAOAdooZNAkOMccD9eK kkvDbRgU5ltODl5z9NZjaJcY+iwRYGHoPMKETlkUUI6s70M0DMAeStBfBszPyDSAJZBgqALo Q5qhHNwcHGaFhvzJ+Y7CVghBOCFTxu/rOdegUiN41Hep/IrjdBqSAQeHzx3odKmkygxOaQYj PAZXsueKr3bC4JoLwevcq9pLUko+JNDEhwzsOlWEcc3Djval71hdq9nv6b2+bepOz/N1z+6a +qBxcuIPLMexLfOrBn1Mpx2z4H3J4/D9DXfGIeEsYxNhEBbXchKupeyG8pSFiofNekHmMxx1 NMttuk7LdQqXh+kpDyqnqZxfzly9fLusCiO2mmajntOi1Wo1Wq7yoAU5NhyvDv80JCnSrluO /MhJqZRUwCt5o3jtY4GRQmrnqCWkNgE5oJJxVDyAQSYhz8SQ3SgDVx8+AyzA2scQOosK1Vz2 V5T2Pjj+4vqW5TpOV2+enDR0x3YsvVd3PN1ze32/Neibvt39qjxjuZsqGEcSRDWNUx5CtJKr CwMYFslZNCDG5kg8Vblkz3FUjiU4mnY0t67wVvMgiLObi1Qyr5UDtB2hA/8jHF1Btz+vM6F6 ZinpTsBsZLwh5yJDyrByvaoyVStdO8dAAXEvJlxeAM/8DRYBMCxFBymSTiaUSJfJ+R26qekf //tPhYLWscUWciFwwcYiURFwAuzf0UZhTDP0kd6gIYtxIk0UpoKXWpxdoLNQMpgy32Wymsch 0MAcU0EAtxjzDx2t4bkerBI+hssfI7WfgNJeEQulBolaLEHSVnJl2Y9TFn9eTd2LEpvU1uvr Qyzow8HoESbxaxpSQtFNmFFErsch+e0tmcj0jPIrMF1zFwNZ4zSLvVTVhvOauV3+34NKn8gJ YAWhzV4AAeWfcy/fuBVeMOczO+Mm//vjDbnEa9PN5UE3q46Qz+w3m7zl864aqQrb653FJjJ9 lO+87I7Qj3CWoe6uKltcRrwq5c03h3sWfLbeCf7uGvWKrlRk/96DwS8VoWu2ONucN/bQe4tb k442Ls4d5VbsUQ77zBuR7W3BbBqNit4OxvDgIfFHNQbbsA/GsOuNwUpjeDUhvhp7YeLzq548 sPcqJvEgr1dF7iGb3z9N7yOFV0Fc1otutozmIdzCzeD+n/t1yzYaB129El1Zhv0GdfVqgtX6 I+MyPeZhy981bK0XfghgAO9T/h+S3jDcN+hn+3p1sHGvYXmGedDVC8evzRpyHxG1qhL3kON+ 9INVf9cI9Qp0tv8Hq+3vxuyW0aqo6HA39lbvxlzbcA7G8CR3Y/u6DdqBGWzDOxjDkxhDcfaU D5koCM+l5MPlb5UJWdQVuaUqy7jMPC8TJ5fzO3u9VsPyPcjvNJ2B7vRbTb07aLj6wLUdx+95 Xd8+KfM7Cacqyf1JkzxN23Jc03RaXpFsuSLNs0yiJxE/w+mnmYox8NsAQbmvilL4NYCMq5Bv v2gCudZhDBUyoVUkRWZriqEzNBslZdZ9cA3JxGES0EmYhIJqCNL5BeaioyUUfs0AybcsoKM8 AT0eMiaKeSpJMGIhWr4Vw0nQIev/PwAAAP//AwBQSwMEFAAGAAgAAAAhAFOXBLotBgAAnC0A ABUAAABwcHQvc2xpZGVzL3NsaWRlOC54bWzsWttu4zYQfS/QfyAEFGhRSLYuVmwjzsKW42CB zW7gOAv0kaboWK0kCiTjJF3sv/Rb+mUdUpIvSryNk806TpyHWKTIIefMzBlKmsN3N0mMZpSL iKUdw7bqBqIpYWGUXnaMi9HAbBpISJyGOGYp7Ri3VBjvjn7+6TBrizhEMDsVbdwxplJm7VpN kClNsLBYRlO4N2E8wRKa/LIWcnwNUpO45tTrfi3BUWoU8/lD5rPJJCK0z8hVQlOZC+E0xhJ2 LqZRJkpp2UOkZZwKEKNnr2zpCDQj53GofkU24pSqq3R2wrPz7Izr2x9nZxxFIeBloBQnAItR K24Uw3QzhWFwUatMvywl4fbNhCdHh7gNuqGbjgHg36r/MAm36Y1EJO8ki14y/XTPWDI9vmd0 rVwAdjBfVGmVa3RXHadUZxTJmCJ7rlU+FMPUD4z8JVDKQE+lfq4e+TgrhSmdlfhsiuRtBshI JaoYl9/UeJTjBWCqwZI3PRbeKsXH8Ks7cTsW8lzexlQDAtvGbRAO/wD+GCsPpanZvTBQGHGp MUIikUFMMfhyAaM8GlJxFUtxCHBIsEYhg6bhGeZ4uFaUUg23YVHYb7k5uMzRW4+hW2IYsFSC h6GzGBM6ZXFIOXKehmgUgj+UoG8HzM+2BSSBJEPDwSmCxgqsOWAaNXDgJyF8yXE2jciAQ3zl /nqy1FMNRK9EfYTH4LnuHOfqJAyRsBC8zpurs1QE50tCVH4Q4EaZjs8rHnWML33P6ToH/Z7Z 67u26fWagdl0u7Y58I+Pg4Hjea5jfzVgju21Exa+L2kT2neoKokIZ4JNpEVYUss5r5axa8oz Fmnas+sFd85w3DFcv95ym27LK90CNqhdttyojja1d31xV7EKBbUObL+e85DTavmthnbZBRv5 XrMOfwZSnOTWHU81chYoJRUAq0AtLvtYYqSx2jhNSGVPwA5idxwXPxCyk4gLOWTXmoJ1I2CA BvDxGHJVcUMPV/M1h7wPj740AsdpeF7XPDg+9k3P9RyzV/eaZrPR6wetQd8O3O5X7dHL03TH OFYg6m2c8AjSg9IuCmFZpHbhQ1LLkfhe/YquxnG5luRo2jEadY233gdBnF2fZ4rqnByghzEo EC7C8SVM+/NKSD1TZKQ7AbdRBE/OpEDatXK76j59VwV3joEGYoWEL87hmPA3eATAsETHSiSd TChRQZMTKkzT2z/6958V6ljPFw+QC5kCMnmqU84E6LZjjKKECvSRXqMhS3CqXBRWwEsjTs/R aZSSKdPuu7z8nPjBAnNMJQHcEsw/dAy/2WiCltAYLjdGOoFDb69IPsqCRCtLkPKV3Fju44zF t2epXt8cYknRr1lECUXXkaCIXI0j8ttbsuD0lPJL8Cx7E/utyYGLs0XVxfI7c7f50Ysql83j 8x6+mW0BAR0+8yD85tFwQWxbjJU/3lBIvBzbaHJfk2cuNrVIVdiLTy67YYfPr9oO3yLOR9nn uQ5nVe+Gjc+PZEGMhUDdV22o+Zlsh5KK6VjOL5taZfFSpGryF0hoCKuTOLwHHBen8fIE9KjY eZb8X0VxOXBM27XqG1uoKnFvF8C0fBaFy4c9bVZRXLVLw/LejF1A87WH90fF0fZyUG9Ttqt6 wQuMpdVHu0cZ5FmIbX2iWAklr275G4fSetkv0EC7noTAQvskpF/03f1u9MwvB6r0sxI5btNq bRw5VYm7Ei+vKAkF+ySko0l/eN1qAPlvKIB28gHVdfeHg/8vXthqDDmWu09C5Qe5TV/+bO9J qL9PQj8sCS2eVlbqiKpHseXD3e+21ahYSH8/e+rX8Y1DdbH36nZ35eS4k4nP9qzG3lZQW/Hy P82atm8dvEFbFU9k6keVUMHvUlnWclvXiBX3iro7XfBYFsGWJWXLtW+9Xst3gibUvtnewPT6 rQOzO/Ab5qDhel7Qa3YD97isfSOc6nrb71oAB1VqbqPl2PMytHsK4Mp6XhLzU5x9mmmGhjJl SXmguzIoTFav56D0dzEEyj6jBG6oYj+ZFlV/GYbJMGyUlgXA4RV8tojSkE6iNJLUQFBZLDGX HSOlUFgNhYkspKO8FjYZMiaLcjktCVYsRKurYjkFOhQg/wcAAP//AwBQSwMEFAAGAAgAAAAh AFqhnqM/BgAAki4AABUAAABwcHQvc2xpZGVzL3NsaWRlOS54bWzsWttu2zgQfV9g/4EQsECL hWTdLF8Qp7DkuCjQtIbjFNhHmqJj7UqiQDFO0qL/st+yX7ZDSvJFjYs4TTeO13mIxduQPDNz hqLm5M1tEqMF5XnE0p5mGaaGaEpYGKVXPe1yMtTbGsoFTkMcs5T2tDuaa29Of/3lJOvmcYhg dJp3cU+bC5F1G42czGmCc4NlNIW2GeMJFlDkV42Q4xuQmsQN2zS9RoKjVCvH84eMZ7NZROiA keuEpqIQwmmMBaw8n0dZXknLHiIt4zQHMWr0xpJOYWfkIg7lb55NOKXyKV285dlFNuKq+cNi xFEUAl4aSnECsGiNsqHspoopdIOHRm34VSUJd29nPDk9wV3YG7rtaQD+nfwPg3CX3gpEikqy qiXzj/f0JfOze3o3qglgBctJ5a6KHX27HbvaziQSMUXWcldFVwxD3zPyV45SBvuU2y+2Rz4s KmFyz1J8NkfiLgNkhBRV9isaFR5V/xwwVWCJW5+Fd3LjU/hVlbgb5+JC3MVUAQLLxl0QDv8A /hhLC6Wp3r/UUBhxoTBCeSKCmGKw5RJGcTqm+XUs8hOAQ4A2Shk0DUeY4/FWUXJruAuTwnqr xcFjgd52DJ0Kw4ClAiwMjWJM6JzFIeXI/jFEoxDsoQL9ecD8ZBodw0Ov3o1Go9dIMDQeniPL sKDG90evN0Au4FMYgjn/EN5XHGfziAw5eFthvW/Xaupu6VY6mOAp2LGzRL0+CINfrARvs+36 KOnPxZTgo+9zMKpMees1j3ral4Fr9+3WwNf9gWPprt8O9LbTt/Shd3YWDG3XdWzrqwZjLLeb sPBdRaJQ/oa4kohwlrOZMAhLGgUDNjJ2Q3nGIkWCllky6QLHPc2xWqbdaTW9VulxsEBlwNVC le/JtauHbzdWI6ROy/LMgpXsTsfrNJUBr7jJc9sm/GlIMpRj2q4sFJxQSSoBlm5bPg6wwEhh tXPQEFKfgB148jQuf8CBZxHPxZjdKEJWhYABGsDOU4hcZYPqLscrRnkXnn5pBrbddN2+3jo7 83TXcW3dN9223m76g6AzHFiB0/+qLHp9mKqYxhJEtYy3PIJgIXcXhTAtkqvwIMQVSDxVvSSv aVzNJTia97SmqfBW6yCIs5uLTBKfXQD0MD4F+kU4voJhf17nQo3MM9KfgdlIuicjkSNlWoVe VZ1qlc5dYKCA2KDkyws4NHwGiwAY1shZiqSzGSXSaQp6hWFq+af//L1BHdv54gFyIW5AXE9V AJoB+fa0SZTQHH2gN2jMEpxKE4UZ8FqP8wt0HqVkzpT5rk+/DAOggSWmggBuCebve5rXbrZh l1AYrxcmKpxDrV+GIqlBojZLkLSVQlnO45TFn09T/kAfY0HRqyyihKKbKKeIXE8jskn+6xBu BuuD0OD8nPIrsCxrF/1tiYGrk0bdxIqWpdn815NKky388x6+WTwDAsp9lk743YPiitie0Vf+ +B+R2v7oRpH7ljhzuatG6sL2Pri8DD18Omg9fI84H6Wfn3U4q1s3LHx5JAtinOeof9CKWp7J XlBQ0VuG99uuWlldkdRVvoeEhrA8icOt4LQ8jVcnoEf5zk+O/xtXTnVw1/3p947RqqlNHa5+ 9NXpaAvwMrcfZ8GH24LlGd7RGHZ9jb6XGA4o2Po1k9jywri6XKnzzR6S+eY77P4weB26darW HdNo78yrdYl7qIx7HehFHoKcjtHcWUPHU9DT3u3WLX7Th1pGa2cN1SW+FB86oCAUHIOQ+j6g vjf/5GvEurlvOJDtPoLi6hJfigO9zCDkPeKYcAxCTxuEtuO54U1O27B2DkfbZb8UvzqgwDQ4 Bqb9CExW2+js7ErHwPS02RQPv2tyjldN8nSxW8bG4bwpm484RR5M3JPhT6aKwe9a+tl6WeXC lW1lfqFK86xSf6vUufUcP9/veHbQhhw/yx3q7qDT0vtDr6kPm47rBn67HzhnVY4f4VRlGT9p op/dapmWY3rNTplud0+iX5XFTGJ+jrOPC/WxAZKzBeWBqsogHVvezkHC86oLJLtGCTTIpEaR ltmNGYbB0G2SVmnP4TV8nonSkM6iNBJUQ5BPLTAXPS2lkE4OCZgspJMiAzgZMybKdSpJMGMp Wj6V00nQIe36XwAAAP//AwBQSwMEFAAGAAgAAAAhANXRkvG+AAAANwEAACwAAABwcHQvc2xp ZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0MS54bWwucmVsc4SPwQrCMBBE74L/EPZu0noQ kaZeRPDgRfQDlmTbBtskZKPo35tjBcHj7DBvdpr9axrFkxK74DXUsgJB3gTrfK/hdj2utiA4 o7c4Bk8a3sSwb5eL5kIj5hLiwUUWheJZw5Bz3CnFZqAJWYZIvjhdSBPmIlOvIpo79qTWVbVR ac6A9ospTlZDOtkaxPUdS/N/dug6Z+gQzGMin39UKB6dpTNyplSwmHrKGqSc33kualneB9U2 6mtu+wEAAP//AwBQSwMEFAAGAAgAAAAhANXRkvG+AAAANwEAACwAAABwcHQvc2xpZGVMYXlv dXRzL19yZWxzL3NsaWRlTGF5b3V0NS54bWwucmVsc4SPwQrCMBBE74L/EPZu0noQkaZeRPDg RfQDlmTbBtskZKPo35tjBcHj7DBvdpr9axrFkxK74DXUsgJB3gTrfK/hdj2utiA4o7c4Bk8a 3sSwb5eL5kIj5hLiwUUWheJZw5Bz3CnFZqAJWYZIvjhdSBPmIlOvIpo79qTWVbVRac6A9osp TlZDOtkaxPUdS/N/dug6Z+gQzGMin39UKB6dpTNyplSwmHrKGqSc33kualneB9U26mtu+wEA AP//AwBQSwMEFAAGAAgAAAAhANXRkvG+AAAANwEAACwAAABwcHQvc2xpZGVMYXlvdXRzL19y ZWxzL3NsaWRlTGF5b3V0NC54bWwucmVsc4SPwQrCMBBE74L/EPZu0noQkaZeRPDgRfQDlmTb BtskZKPo35tjBcHj7DBvdpr9axrFkxK74DXUsgJB3gTrfK/hdj2utiA4o7c4Bk8a3sSwb5eL 5kIj5hLiwUUWheJZw5Bz3CnFZqAJWYZIvjhdSBPmIlOvIpo79qTWVbVRac6A9ospTlZDOtka xPUdS/N/dug6Z+gQzGMin39UKB6dpTNyplSwmHrKGqSc33kualneB9U26mtu+wEAAP//AwBQ SwMEFAAGAAgAAAAhANXRkvG+AAAANwEAACwAAABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3Ns aWRlTGF5b3V0My54bWwucmVsc4SPwQrCMBBE74L/EPZu0noQkaZeRPDgRfQDlmTbBtskZKPo 35tjBcHj7DBvdpr9axrFkxK74DXUsgJB3gTrfK/hdj2utiA4o7c4Bk8a3sSwb5eL5kIj5hLi wUUWheJZw5Bz3CnFZqAJWYZIvjhdSBPmIlOvIpo79qTWVbVRac6A9ospTlZDOtkaxPUdS/N/ dug6Z+gQzGMin39UKB6dpTNyplSwmHrKGqSc33kualneB9U26mtu+wEAAP//AwBQSwMEFAAG AAgAAAAhANXRkvG+AAAANwEAACwAAABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5 b3V0Mi54bWwucmVsc4SPwQrCMBBE74L/EPZu0noQkaZeRPDgRfQDlmTbBtskZKPo35tjBcHj 7DBvdpr9axrFkxK74DXUsgJB3gTrfK/hdj2utiA4o7c4Bk8a3sSwb5eL5kIj5hLiwUUWheJZ w5Bz3CnFZqAJWYZIvjhdSBPmIlOvIpo79qTWVbVRac6A9ospTlZDOtkaxPUdS/N/dug6Z+gQ zGMin39UKB6dpTNyplSwmHrKGqSc33kualneB9U26mtu+wEAAP//AwBQSwMEFAAGAAgAAAAh ANZx+pzVAAAAwAEAACsAAABwcHQvbm90ZXNTbGlkZXMvX3JlbHMvbm90ZXNTbGlkZTExLnht bC5yZWxzrJDBasMwDIbvg72D0X1W0sMYo04vY9BDL6V7AGEriWliG8sb7dvXUBgJFHbZSfwS +vSh7e4yT+qHs/gYDLS6AcXBRufDYODr9PnyBkoKBUdTDGzgygK77vlpe+SJSl2S0SdRlRLE wFhKekcUO/JMomPiUCd9zDOVGvOAieyZBsZN07xiXjKgWzHV3hnIe7cBdbqmevlvdux7b/kj 2u+ZQ3lwAmXyjiuQ8sDFgNb3jtxL2+pqC/hYpP1PkRALy4GkcF7pLPqCi/Brhqu/dzcAAAD/ /wMAUEsDBBQABgAIAAAAIQDV0ZLxvgAAADcBAAAsAAAAcHB0L3NsaWRlTGF5b3V0cy9fcmVs cy9zbGlkZUxheW91dDYueG1sLnJlbHOEj8EKwjAQRO+C/xD2btJ6EJGmXkTw4EX0A5Zk2wbb JGSj6N+bYwXB4+wwb3aa/WsaxZMSu+A11LICQd4E63yv4XY9rrYgOKO3OAZPGt7EsG+Xi+ZC I+YS4sFFFoXiWcOQc9wpxWagCVmGSL44XUgT5iJTryKaO/ak1lW1UWnOgPaLKU5WQzrZGsT1 HUvzf3boOmfoEMxjIp9/VCgenaUzcqZUsJh6yhqknN95LmpZ3gfVNuprbvsBAAD//wMAUEsD BBQABgAIAAAAIQDV0ZLxvgAAADcBAAAsAAAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlk ZUxheW91dDgueG1sLnJlbHOEj8EKwjAQRO+C/xD2btJ6EJGmXkTw4EX0A5Zk2wbbJGSj6N+b YwXB4+wwb3aa/WsaxZMSu+A11LICQd4E63yv4XY9rrYgOKO3OAZPGt7EsG+Xi+ZCI+YS4sFF FoXiWcOQc9wpxWagCVmGSL44XUgT5iJTryKaO/ak1lW1UWnOgPaLKU5WQzrZGsT1HUvzf3bo OmfoEMxjIp9/VCgenaUzcqZUsJh6yhqknN95LmpZ3gfVNuprbvsBAAD//wMAUEsDBBQABgAI AAAAIQAj0KgJ1QAAAL8BAAAqAAAAcHB0L25vdGVzU2xpZGVzL19yZWxzL25vdGVzU2xpZGU2 LnhtbC5yZWxzrJDBasMwDIbvhb6D0X120kMZpU4vY9DDLqN7AGEriVliG0sb69vPUAoJFHbZ SfwS+vSh4+lnntQ3FQ4pWmh1A4qiSz7EwcLH5fXpGRQLRo9TimThSgynbrs5vtOEUpd4DJlV pUS2MIrkgzHsRpqRdcoU66RPZUapsQwmo/vEgcyuafamLBnQrZjq7C2Us9+Bulxzvfw3O/V9 cPSS3NdMUR6cMDwFTxWIZSCxoPWtw7ey11UWzGOP9j89YhLiN2ShsrJZ9NksQns3M6u3d78A AAD//wMAUEsDBBQABgAIAAAAIQCtGtzN1QAAAL8BAAAqAAAAcHB0L25vdGVzU2xpZGVzL19y ZWxzL25vdGVzU2xpZGU3LnhtbC5yZWxzrJDBasMwDIbvg72D0X120kM3Rp1exqCHXUr7AMZW ErNENpY21refoRQSKOyyk/gl9OlDu/3PPKlvLBwTWWh1AwrJpxBpsHA+vT+9gGJxFNyUCC1c kGHfPT7sjjg5qUs8xsyqUogtjCL51Rj2I86OdcpIddKnMjupsQwmO//pBjSbptmasmRAt2Kq Q7BQDmED6nTJ9fLf7NT30eNb8l8zktw5YXiKASvQlQHFgtbXDl/Ls66yYO57tP/pQUmQPxwL lpXNos9mEdqbmVm9vfsFAAD//wMAUEsDBBQABgAIAAAAIQDxLhJo1QAAAL8BAAAqAAAAcHB0 L25vdGVzU2xpZGVzL19yZWxzL25vdGVzU2xpZGU4LnhtbC5yZWxzrJDBasMwDIbvhb6D0b12 0sMopU4vY9DDLqN7AGEriVliG0sb69vPUAYJFHbZSfwS+vSh0/l7ntQXFQ4pWmh1A4qiSz7E wcL79WV3AMWC0eOUIlm4EcO5225ObzSh1CUeQ2ZVKZEtjCL5aAy7kWZknTLFOulTmVFqLIPJ 6D5wILNvmidTlgzoVkx18RbKxe9BXW+5Xv6bnfo+OHpO7nOmKA9OGJ6CpwrEMpBY0Pre4Xs5 6CoL5rFH+58eMQnxK7JQWdks+mwWof01M6u3dz8AAAD//wMAUEsDBBQABgAIAAAAIQB/5Gas 1QAAAL8BAAAqAAAAcHB0L25vdGVzU2xpZGVzL19yZWxzL25vdGVzU2xpZGU5LnhtbC5yZWxz rJDBasMwDIbvg72D0X120kPZRp1exqCHXUr7AMZWErNENpY21refoRQSKOyyk/gl9OlDu/3P PKlvLBwTWWh1AwrJpxBpsHA+vT89g2JxFNyUCC1ckGHfPT7sjjg5qUs8xsyqUogtjCL51Rj2 I86OdcpIddKnMjupsQwmO//pBjSbptmasmRAt2KqQ7BQDmED6nTJ9fLf7NT30eNb8l8zktw5 YXiKASvQlQHFgtbXDl/Li66yYO57tP/pQUmQPxwLlpXNos9mEdqbmVm9vfsFAAD//wMAUEsD BBQABgAIAAAAIQBYu45Y1QAAAMABAAArAAAAcHB0L25vdGVzU2xpZGVzL19yZWxzL25vdGVz U2xpZGUxMC54bWwucmVsc6yQwWrDMAyG74O9g9F9dtLDGKNOL2PQQy+lewBhK4lpYhtLG+3b 11AGCRR22Un8Evr0oe3uMk/qhwqHFC20ugFF0SUf4mDh6/T58gaKBaPHKUWycCWGXff8tD3S hFKXeAyZVaVEtjCK5Hdj2I00I+uUKdZJn8qMUmMZTEZ3xoHMpmleTVkyoFsx1d5bKHu/AXW6 5nr5b3bq++DoI7nvmaI8OGF4Cp4qEMtAYkHre4fvpW10tQXzWKT9T5GYhPiALFRWOos+m0Vo f83M6u/dDQAA//8DAFBLAwQUAAYACAAAACEA8IlEntUAAAC/AQAAKgAAAHBwdC9ub3Rlc1Ns aWRlcy9fcmVscy9ub3Rlc1NsaWRlNS54bWwucmVsc6yQwWrDMAyG74O9g9F9dlLoGKNOL2PQ wy6lfQBjK4lZIhtLG+vbz1AKCRR22Un8Evr0od3+Z57UNxaOiSy0ugGF5FOINFg4n96fXkCx OApuSoQWLsiw7x4fdkecnNQlHmNmVSnEFkaR/GoM+xFnxzplpDrpU5md1FgGk53/dAOaTdM8 m7JkQLdiqkOwUA5hA+p0yfXy3+zU99HjW/JfM5LcOWF4igEr0JUBxYLW1w5fy1ZXWTD3Pdr/ 9KAkyB+OBcvKZtFnswjtzcys3t79AgAA//8DAFBLAwQUAAYACAAAACEAfkMwWtUAAAC/AQAA KgAAAHBwdC9ub3Rlc1NsaWRlcy9fcmVscy9ub3Rlc1NsaWRlNC54bWwucmVsc6yQwWrDMAyG 74O9g9F9dlLKGKNOL2PQwy6lfQBjK4lZIhtLG+vbz1AKCRR22Un8Evr0od3+Z57UNxaOiSy0 ugGF5FOINFg4n96fXkCxOApuSoQWLsiw7x4fdkecnNQlHmNmVSnEFkaR/GoM+xFnxzplpDrp U5md1FgGk53/dAOaTdM8m7JkQLdiqkOwUA5hA+p0yfXy3+zU99HjW/JfM5LcOWF4igEr0JUB xYLW1w5fy1ZXWTD3Pdr/9KAkyB+OBcvKZtFnswjtzcys3t79AgAA//8DAFBLAwQUAAYACAAA ACEAFzztatUAAAC/AQAAKgAAAHBwdC9ub3Rlc1NsaWRlcy9fcmVscy9ub3Rlc1NsaWRlMy54 bWwucmVsc6yQwWrDMAyG74O9g9F9dtLCGKNOL2PQwy6lfQBjK4lZIhtLG+vbz1AKCRR22Un8 Evr0od3+Z57UNxaOiSy0ugGF5FOINFg4n96fXkCxOApuSoQWLsiw7x4fdkecnNQlHmNmVSnE FkaR/GoM+xFnxzplpDrpU5md1FgGk53/dAOaTdM8m7JkQLdiqkOwUA5hA+p0yfXy3+zU99Hj W/JfM5LcOWF4igEr0JUBxYLW1w5fy1ZXWTD3Pdr/9KAkyB+OBcvKZtFnswjtzcys3t79AgAA //8DAFBLAwQUAAYACAAAACEA1dGS8b4AAAA3AQAALAAAAHBwdC9zbGlkZUxheW91dHMvX3Jl bHMvc2xpZGVMYXlvdXQ5LnhtbC5yZWxzhI/BCsIwEETvgv8Q9m7SehCRpl5E8OBF9AOWZNsG 2yRko+jfm2MFwePsMG92mv1rGsWTErvgNdSyAkHeBOt8r+F2Pa62IDijtzgGTxrexLBvl4vm QiPmEuLBRRaF4lnDkHPcKcVmoAlZhki+OF1IE+YiU68imjv2pNZVtVFpzoD2iylOVkM62RrE 9R1L83926Dpn6BDMYyKff1QoHp2lM3KmVLCYesoapJzfeS5qWd4H1Tbqa277AQAA//8DAFBL AwQUAAYACAAAACEA1dGS8b4AAAA3AQAALQAAAHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xp ZGVMYXlvdXQxMC54bWwucmVsc4SPwQrCMBBE74L/EPZu0noQkaZeRPDgRfQDlmTbBtskZKPo 35tjBcHj7DBvdpr9axrFkxK74DXUsgJB3gTrfK/hdj2utiA4o7c4Bk8a3sSwb5eL5kIj5hLi wUUWheJZw5Bz3CnFZqAJWYZIvjhdSBPmIlOvIpo79qTWVbVRac6A9ospTlZDOtkaxPUdS/N/ dug6Z+gQzGMin39UKB6dpTNyplSwmHrKGqSc33kualneB9U26mtu+wEAAP//AwBQSwMEFAAG AAgAAAAhANXRkvG+AAAANwEAAC0AAABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5 b3V0MTEueG1sLnJlbHOEj8EKwjAQRO+C/xD2btJ6EJGmXkTw4EX0A5Zk2wbbJGSj6N+bYwXB 4+wwb3aa/WsaxZMSu+A11LICQd4E63yv4XY9rrYgOKO3OAZPGt7EsG+Xi+ZCI+YS4sFFFoXi WcOQc9wpxWagCVmGSL44XUgT5iJTryKaO/ak1lW1UWnOgPaLKU5WQzrZGsT1HUvzf3boOmfo EMxjIp9/VCgenaUzcqZUsJh6yhqknN95LmpZ3gfVNuprbvsBAAD//wMAUEsDBBQABgAIAAAA IQBKr3U51AAAAL8BAAAqAAAAcHB0L25vdGVzU2xpZGVzL19yZWxzL25vdGVzU2xpZGUxLnht bC5yZWxzrJDBasMwDIbvg72D0X1W0sMYo04vY9BDL6V7AGEriWliG8sb7dvXUBgJFHbZSfwS +vSh7e4yT+qHs/gYDLS6AcXBRufDYODr9PnyBkoKBUdTDGzgygK77vlpe+SJSl2S0SdRlRLE wFhKekcUO/JMomPiUCd9zDOVGvOAieyZBsZN07xiXjKgWzHV3hnIe7cBdbqmevlvdux7b/kj 2u+ZQ3lwAmXyjiuQ8sDFgNb3jtxLq6ss4GOP9j89QiwsB5LCeWWz6Asuwq8Zrt7e3QAAAP// AwBQSwMEFAAGAAgAAAAhAJn2ma7VAAAAvwEAACoAAABwcHQvbm90ZXNTbGlkZXMvX3JlbHMv bm90ZXNTbGlkZTIueG1sLnJlbHOskMFqwzAMhu+DvYPRfVaSwxijTi9j0MMuo3sAYyuJaWIb Sy3r289QBgkUdtlJ/BL69KHd/nuZ1YUKhxQNtLoBRdElH+Jo4Ov4/vQCisVGb+cUycCVGPb9 48Puk2YrdYmnkFlVSmQDk0h+RWQ30WJZp0yxToZUFis1lhGzdSc7EnZN84xlzYB+w1QHb6Ac fAfqeM318t/sNAzB0Vty54Wi3DmBPAdPFWjLSGJA61uHb6XTVRbwvkf7nx4xCfGHZaGysVn1 GVeh/TXDzdv7HwAAAP//AwBQSwMEFAAGAAgAAAAhANXRkvG+AAAANwEAACwAAABwcHQvc2xp ZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0Ny54bWwucmVsc4SPwQrCMBBE74L/EPZu0noQ kaZeRPDgRfQDlmTbBtskZKPo35tjBcHj7DBvdpr9axrFkxK74DXUsgJB3gTrfK/hdj2utiA4 o7c4Bk8a3sSwb5eL5kIj5hLiwUUWheJZw5Bz3CnFZqAJWYZIvjhdSBPmIlOvIpo79qTWVbVR ac6A9ospTlZDOtkaxPUdS/N/dug6Z+gQzGMin39UKB6dpTNyplSwmHrKGqSc33kualneB9U2 6mtu+wEAAP//AwBQSwMEFAAGAAgAAAAhANUglVkOCAAA2i8AACEAAABwcHQvc2xpZGVNYXN0 ZXJzL3NsaWRlTWFzdGVyMS54bWzsWl1u40YSfl9g70Awj4FG4j8ljBxYspUM4EyM2HOAFtmy GFMkt9ny2AkWmDvsDXKL7L7lKHOSVFV3U5QtOfJaBmzDgCGT3c1id31f/Urvv7te5NYVF3VW FkPbedezLV4kZZoVF0P70/mkE9tWLVmRsrws+NC+4bX93cE///G+GtR5+iOrJRcWyCjqARva cymrQbdbJ3O+YPW7suIFzM1KsWASbsVFNxXsM8he5F231wu7C5YVtn5e7PJ8OZtlCT8qk+WC F1IJETxnEvZfz7OqNtKqXaRVgtcghp5e29IBnC85y1P8P71Qnz/zmZWl16ClXs+xD96zAZ2T j3NhXbF8aE8vHLt78L6Lj8BifYUP19W54ByviqvvRXVWnQq8ST5enQqQCSJtq2AL0C8KoAm9 jG4LWKYErz1+YSSxwfVMLHBHoB4Ldggo3uAnPMQG/FpaiRpMVqPJ/KcNa5P58YbVXfMCOFrz UjyVOtHd47jmOOeZzLl1mrOEz8s8Ba6QiuiE6jHQYnVSJpe1VZRwZlSFOiooxwjG8+Orqrkl byrQkkSxep2ahJ0Vzfqa9Gs23WjFDyIgHanGjfzQi9f1E7tuP8R51JLj+F4PbnAvK0GVqOX3 vFxYeDG0BU8kEYFdndRSLTVLCH21kWogr0dleoNgTOE/YA4WB8/PS/GrbeUfinpo9x3fh3dL uqGd2pZoz0zXZmQ+LoFy8AQrEpAztBMpaC8FWNvhUpazTO9IvRJfntfyTN7knGgB4LEBqBU+ YEM5Q4PnRefTGRj8Qo5zzsAhaArJg3GeJZeWLC2eZtLSdk8wgHsAkaglSboikbxIT5lgP7cl H37S2oQ3A1xGJ3CpiLSdTl5DJ+Rym00uinwsm1BBtjZt2iJyCRn3QFI5wB4kGKnXWN0aq/zA Dfqhp/VgjNZQ5hmxCmnxICKBxVn5FTGSjv9IYqH2iFf1GrGAZERb9WFeSR7jAVw+40lZpFbO r3i+g3ji2APEn88zsbt0IsMDpE/KpZDznTfvKzbuDMckm22UDmFkrybtG5M+YnI9QJBCHmvS qQQv9it4WJbPtGkTjGTR/4dph14Af7dM23U8rwkYXhg4bvD8LXstXpCpmqhAEeIqd9CUWX4B 3j+3cSzlM/TjqE4H3RuO1WWepZMsz+kG071VGiSvVXYks0KqxCgKVqG0yZkoWLTkgG2rN9EE +BLciLrWYQvfRZY/y1PKmn5zA+do4rpup+8Fk47fc8NOHPb7nXg07kejcQRB9fjfEFQpaUiB aTJb8El2sRT8p6UK3WvBD0LUpuDnOd1eBLmm467cBewB97NfqwiMVUzKEhPrdqgjS36sXcwg SSAk/7VkAt6gbUNFpIeEPc9xfZNMbTaOuB+8auMw+dbzM4/9cjI0nDwDk+fWx+VieouZ5PUe y0yoJkH0JnIS8R/kuMMg8O4n52v33KoUeH7UbDz38fjIOQ6CuDOZHPc6/tg96oycY3DkvhMG x70wDPtR47lrZF4B7ECPu4vD/vrlj2++fvnvHrw1VSemeIesFOo8LDgwP12KbGj/Nhr1Q3cc j2D7PoSgo37UOZyEQWcSeL4/HsWHYw9CEDzj+INEcGo1fEh1ywMG77QpFlkiyrqcyXdJueiq fke3Kj9zUZUQUTEM9XTfhLoO8JowcMHZUu5BW6PKxWwWTmA6GUkufmSVBX0KiO0Seg4Qqod2 eglX0wsXx6Bwl9dwlV7CFUsSaI7ACn1hRmBejTRrPDMClZqagnPpCzMSmBEIcmoqNCPgYuZ5 VlyCLvCfbc3K/Ac1YK7wcNRyOmE35VJ+SDUQ4DbMCKUEruNHfuyFfh/K5wG2VsSHVPcctq2F vG61VleUW9eCrhq5OlXduhb006zV4XvrWtBcs1Y71K1rIXlu1hLsa5pZ00MA2m7WRne0uL4W cGjWUnPkHrlRa23/b+RCD7GR61ASfY/gNeBMM6ilCg28vKZWRo20oD4E3aKD0KmjzmExTFvg CM/Z9AwyWGqzIN5SdU84OylGApgHuGIXsdC3sGQOLRFoVZ4uiwR6NbrjVyUj7Oxh1yo5TXR+ S0eC/BXG9Ox0+RHapZRet5wwdHhA7iUX2GrdNZUGISi6nXDTRimrnUFjbWh/u/ilk0sEARJS dmuCMzWR1LcmkhontqXd61qFliY0Se6oeMHEydD2fLePB8sK8NKgqo4ZMFXEU+sfVKnaLrcw mJRQgWDyr9R0KDKW21aVyWQ+YYsshz6fB7aUzJmoOWxc13fT5RhGaHhof/3yu9JfC0eVXDwF jsU2HIvOFhyLzr04kjm4WNIprCLACv1dg5UbB1CegUvWFd/Lxuo/d7By46eyuT1ihQBp1+Wt sDI96BZYbkw11esA665huU/mIPcIFiKkwfJbYOnm72sFa4NlodN9kmi2R7AQIQ1WsALL7QUR UW3lBl+RZf35v7te8CVghQBprMIWVoHjk9N7lVhtSi8wnXn2hoUIabCiFlj9yKGA+wbWfe3x nXL6PXpBREiDFa/AUmn6WjL4irzgi7UsREiD1W+BFcch9TTfLOs5WRYiRO22Vn1cDUo556Kp lqFyPFWQ6hqy/WOLpgTXS0z3QpVrT1KYtSpZ5axfZCVrfs2z/1ropelnc/VoOl1v+tlSsHkR /mDnKTofL41Am4skJ3ZjyuXeGLSlMqFs6Y1BELK2VAORr1qlbwzakoFDRkd9iDcFbcl6wyB6 c9LUxG8yzXZyCV/urr4Iw++qzW/yD/4CAAD//wMAUEsDBBQABgAIAAAAIQAyfZp9qAQAAAkR AAAhAAAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDEueG1szFjbbuNGDH0v0H8Q1GdF 94uFJIv4VhTIJkGdfMBEGsfCji4djb32FgX2t9rP2S8pSWksZ9dtg9Yo/JLIEoc65CFnDnX5 blsKY8NlW9TVleleOKbBq6zOi+rlynx6nFuJabSKVTkTdcWvzB1vzXfX33932aStyG/Zrl4r A3xUbcquzJVSTWrbbbbiJWsv6oZX8GxZy5Ip+Clf7Fyyj+C7FLbnOJFdsqIy+/XyLevr5bLI +LTO1iWvVOdEcsEU4G9XRdNqb81bvDWSt+CGVr+GpHYNRKsKJbhpkJncwA3XvIbIs4XIjYqV cOMRLYyFKHJOj9rmUXKORtXmR9ksmgdJK+42D9IocvTQrzTt/kFvRj8rMIML+6vlL9oTS7dL WV5fshQSYWyvTOBrh39hEUv5VhlZdzMb7mar+yO22Wp2xNrWLwAE+5cC1U0X0bfheDqcLhHu PqrOlMHS2zr70BpVDXFi+F142d1GO8OY0X2zMrqsZ0qSt960e04p0UtaSqvGuk9GlISJ02XE c30n8MLXeYnj2AvQALPjBrHjdBaHUXeum1Rtx3W+w6w+w39ihaWiVQu1E5yyDTlhKSCHP8Ct YNgxvLKeFtAxpZoIzqCjembU9UQU2QdD1QbPC2W8Z63i0lBUPS26vAQQCpjvXfIqf2CS/Xzo +eaJMsJSeDOkQyOEy46fv2bJ1ywt1s/dOz10BZWsafhXRLXr544oqGwoO83t2wlz/diNesb8 JIlgT3jNWAR0EaXEWBx6aI0VpLmn4Lv60fk4yhjSJDbChcIxSiZvqXOKKofup0smXoAtqDzo YnCwvoPdjljO+RJIwJttDV0+L4SgH7jF8YmQxoYJ2Ci2uDMAg0Wlujtx6Oyh0n6IxgT8wA+E of3DZY8P/cClN0ANwhgzY5wfXgTZ4/UHvCM3oDY7P7wIsscbDHj3ZXh+gBFlDzg8AJx4CbXF +QFGlD3gaADseQl07lmWMKLsAccHgOPAP9OeQ5Q94GQAjGjPtOkQZQ94dAA4CmPa+8+vhhEl bdX6vEf0Jzju4bz8v078QJ/4U6a48SBYxle1yEFz+Kc4+XMFIucTSGwmlnAu0enfHcyoXCl7 eLGgRKI+IQE1aJajZ/Sgqpagr1Es/+qF7nTueZ418sO5FTheZCXRaGQl48koHk9iOGlmv5m9 bswhVFWUfF68rCW/XysTeXslzkBCHRNnvms7MQwTrjfIMMCAy08rxEJNy7yuUQAeEhOcgpgl KBhi5pc1k/AGTc4/aDMSg38roAZyTpuRSGeEZijjbl0+f5UXEvH/WaqKHFwfTQ1JYRovTle3 s8nUnYVhYs3nM8cKJt7UGrszKOPAjcKZE0XRKN7XbYvTYwXo3lquXz7//sOXz3+coFZJPuuJ FcbH2xZmkIYGybUsoAHH41HkTZIxwA+gAaej2LqZR6E1D/0gmIyTm4kPDQhr3CDNJKdJ+qe8 n+jh5jdTeFlksm7rpbrI6tLuxnm7qT9y2dQgnrEJnf6zAClrLwpBTIZJFJHuJ2w0/mi0EALO 4zTNCPmeNfcb2LxZCh8goP5BdMOtBj45QAGj6WCCsetPGNd/AgAA//8DAFBLAwQUAAYACAAA ACEArijjTxAFAAA1EgAAIQAAAHBwdC9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQ5LnhtbKxY W27jNhT9L9A9COq3Y+stG3EG8asokEmCJlkAI9GxMHqVop24RYHZVrucWUnPpUTbSpyO4/FP YtOXh/d57iXPP71kqbHiokqKfGhaZz3T4HlUxEn+NDQf7med0DQqyfKYpUXOh+aaV+ani59/ Oi8HVRpfsXWxlAYw8mrAhuZCynLQ7VbRgmesOitKnuO3eSEyJvFVPHVjwZ6BnaVdu9fzuxlL crPZLw7ZX8znScQnRbTMeC5rEMFTJqF/tUjKSqOVh6CVgleAUbvbKsl1CWvLJLp/MQ0lJlZY sMwLWB7dpbGRswwLt0kkl4Ibz4lcGGNWkh5KpirvBeckna9+FeVdeSvU1uvVrTCSmKAaCLPb /NCIqa85xPCh+2r7k0Zig5e5yC7O2QAeMV6GJgK3pr/YxAb8RRpRvRhtV6PFzR7ZaDHdI93V B0CDzaGIeVlb9NYcW5tzn8iUG9bGqlqUYetVEX2pjLyAnWR+bV50vdJgZDPBlwujdr8kqEau /lH5Q8tXyqda0Y0nrKBv2yHyFpa7IbKs98ornhv6LhYN8o3n+4ETqkM0Eg6pocuBfBkV8Zpc +oj/iBzLo0WBTH2kHWyQVvJOrlPEGZ9XqQWNDJY+oZRSZAEbxHz+O5aqP4cm8h1HPmrLN/II chsHLmYDOAJ/sDVlVIk87zzcoRIzOU45A3xjkrwYp0n0xZCFweNEGp9ZJbkwlONQt9CM0KU6 Q0HyPL5lgpFSG+TLh8Z8nAzbtc3KDRSP94Pu6KDrMrhNWcQXRRpDCZtQUSw6wEelACrQRLkg l3XCHJcIvmUHgVcHTVdHKw9cy6JkaTxRF9f/JMK70c+YuFLVmOQxqIU+Uigfl9fgT7VrJycc JEVzYpM9JIuPNiVSDeV6AUkZh+DZWwsakAbP2eL1LVcl/0F4JAmlKUNXKYE0eO4Wz3ICi0rs MAWpCDaAhNIAejuAIar3OEBCaQD9LSDYAAoepSGhNIDBDmDgqsgdYTKhNIDhFpDQDg9Ky4eE 0gD2dwB9LzgyKISyn5NOyx2u5o57qsdd4nAoQ36UOIivQZgg3gVL5w2HKEpCVR/HIZ6DVlH3 im2LbZFI2ENrqQ85oJkoNtjXQT7EIVarRqkDNelwJIdYLU4ikAbvSA6xWul6Ag7pn5hCWngn YJAW3gkIpIV3Av5o4Z2APlp477MHkROayGZ0UWl1/IRDpKEGnKo14aBTfXiK8TQTTZjkLSZy T8FEsXzDQ1bdBN8lIsV/eg7Ts2eLLtQXNSnOcReh+8RftmdNZrZtd/qON+u4PdvvhH6/3wlH 434wGgdo/NO/zWa0jmGqTDI+S55wfblZSpOqvBUOjIX7Bk7H6vYCXLwse+t46EDbT9sgfB2W WVHQULvbItQk96MtYi5FHZk/lkzgBD1ofmfS/EhwTuuRQHvkLk1iblwvs8dXfvFPkbC42AN6 r2u+00A/4ppN3k7HE2vqeWFnNpv2Ou7YnnRG1hRp7Fq+N+35vt8PNnlbkeU5tDs0Xb99/eeX b1//PUGuqtuAvtSDfq4q3KtKdddeigQFOBr1fXscjqC+iwKc9IPO5cz3OjPPcd3xKLwcOyhA 7LHcQSS4enX4LW5eP7D45sUiSyJRVMVcnkVF1q2fPrpl8cxFWSTq9cPqNU8oKwZmtYMwdHC1 dXWYoKW60mltYQK9XajpKhWfWXmzUjSMxxrk/1gtlXieQRxJdCtCtuvnnov/AAAA//8DAFBL AwQUAAYACAAAACEAxQWWo9YDAADRCwAAIgAAAHBwdC9zbGlkZUxheW91dHMvc2xpZGVMYXlv dXQxMC54bWysVsFu4zYQvRfoPxDqWZElS7ItxF7Esl0UyCZB7fTOlehYWEpUKdprtyiwv9V+ zn5JHykx2WS9gLPxRbao4ePMm5nHuXy3LznZMdkUoho7/kXPIazKRF5UD2PnfrVwhw5pFK1y ykXFxs6BNc67yc8/XdZJw/NrehBbRYBRNQkdOxul6sTzmmzDStpciJpV+LYWsqQKr/LByyX9 BOySe0GvF3slLSqn2y9P2S/W6yJjM5FtS1apFkQyThX8bzZF3Vi0+hS0WrIGMGb3c5fUoUa0 IEat9g4xdnKHFd+ZIPRsyXNS0RILq0JxRkAQ+QPGRUY5WbG9MmZNvZKM6Q3V7ldZL+s7aXbf 7O4kKXKN1qE4XvehMzOvFczwx3ux/cEi0WS/luXkkiZghezHDpJ30E9sogmcIFm7mD2tZpvb I7bZZn7E2rMHwIPHQ5H3uo3o23ACG05Liv8YVWtKsfVaZB8bUgnEqcNvw8tudhZMx6zh6w1p U6A0v51d+9HwYe0bcGrIUvupyA868A/4NYs04Y1aqgNnhhC4TROA4wH6OdUVzir3fokKL1XK GUUHdOSpScqL7CNRgrC8UOQ9bRSTxDiDfgDkJdhRSE4Hyar8jkr6+9fIV/fGb5rgZDhtPcTf lsLvE9m3RD6rKXLHacY2gudwJdDYqERL3Q+Rq6lyiJAFmqCtdgd1iaKxmXkN41pGgMKodlp7 d4x/pIvwHX8k+o350EVu0tE8yweyYrLdPuyRJqhXlMCSZQJ9zdmO8RPgTUZeAb/aFPJ09H7L 6Ml8LcRWqs3JzoevhS/WR9GhO2fthNB2wowq9qwBDCFvbYBcofn/wlVB+dqWvpEAIzJait6k NmtcE1rn/w4if7YIgsAd9aOFG/aC2B3Go5E7nKajwTQdjPxw/o/TSV6OUFVRskXxsJXsdqsv kxeiBWk5Jlp93+sNcCn6wVO9wge9/bxpiWxaFkJoYfxamUwpvTUxayXbzPy5pRIn2OT8iDB9 R4rOy0hsGVnyImfkZlt+eMFLdA7FxtAF6KPUGP05c93O05k/j6Khu1jMe26YBjN36s9RxqEf R/NeHMejwWPdNjryCt6dWq5fPv/7y5fP/52hVs2daoctXArXDe7m2sxAW1mgAafTURykwync D9GAs9HAvVrEkbuI+mGYTodXaR8NiD1+mGSSmYnwt7ybTLH4zTRZFpkUjViri0yUXjuWerX4 xGQtCjOZ+r1uvN1R3HdBLx4M+/0wsvICL426WG8Rgh4rzaXO5Xta3+4gPzTBII36T81SjdEZ 1axNn0x07HYUn/wPAAD//wMAUEsDBBQABgAIAAAAIQBWAddoIQQAALAMAAAiAAAAcHB0L3Ns aWRlTGF5b3V0cy9zbGlkZUxheW91dDExLnhtbLRX227jNhB9L9B/INRnRRdLsiTEXsSytSiQ TYLa6TtXomNiKVFL0V67RYH9rfZz9ks6pEQncVzU2XhfnFiaOZw5Z2Y4vny3rRjaENFSXo8s 78K1EKkLXtL6YWTdL3I7tlArcV1ixmsysnaktd6Nf/7psklbVl7jHV9LBBh1m+KRtZKySR2n LVakwu0Fb0gN75ZcVFjCV/HglAJ/AeyKOb7rRk6FaW31/uIUf75c0oJMebGuSC07EEEYlhB/ u6JNa9CaU9AaQVqA0d7PQ5K7BrIFYuSCSkau6nKxtZC2Fxt441ljoKCYsxLVuIIHv4MpLTBD 2h4BY2hBtlKbtc1CEKIc6s170cybO6G9bzZ3AtFSofUoltO/6M301xrM4B/nwP3BIOF0uxTV +BKnwA7ajiwQcac+wQmnEAQquofF49NidXvEtljNjlg75gCIYH8o6N90Gb1MxzfpHJDi7dPr fDBgXPPiU4tqDgkrHro8i5uNQVXJq3OaFeo0kUoPC3FBQblOot6rM9U0Ge9WU23i3xMURX4S uB1N/jCIBvFzrnw3HOr3irEwDr3QD/UhBgkO6aCbVG4nvNwppj/CXxBUFc3IIlgl38GyVs7l jhGtB7CGU0gJPsCYYdVopLbv59BolcwYwdCIvXZynDFafEKSI1JSiT7gVhKBNAXQlgB5CeJI qI0ektTlHRb4t6fIV/d96HAyxG3i1SkoZv9bx8FLHVU13TFckBVnJYTiK2xoBCPYd0mqiDtQ FNoCatbUw+nKBuEQBouu/2PCRq6XxOr9jxIW6g2xDdsr+EahFd1a5/aZ0CC3LqPuwxyp2XpF bc1JwWFMMbIh7AR4LfUr4BcrKk5HH3StcjJfOV8LuTo5+OC18HR5FB3m6VlbLDAtNsWSPOss TchbO6uUMFX+gKsQs6XV95SeLXpKqsmq/3k6LnU/myFhhpqeXC/H2BKuP3V//emH3jT3fd9O BmFuB64f2XGUJHY8yZLhJBsmXjD7y+oneAmpSlqRnD6sBbldq0vyYBrCzDo2DQee4w7h0vf8 x3qFGJT7eWUJjSw552riPh15upTeKsxSik6Zz2ss4AQjzv9MvNeIc15GIsPInNGSoJt19fGA F31DvpUXWCoB+ig1ev6cuW5n2dSbhWFs5/nMtYPMn9oTbwZlHHhROHOjKEqG+7ptVeY1RHdq uX77+vcv377+c4Za1Ze1WSLhUrhu4dJv9G63FhQacDJJIj+LJxB+AA04TYb2VR6Fdh4OgiCb xFfZABoQfLwgLQTRG++vZb95w8MX23JFC8FbvpQXBa+cbu12Gv6FiIZTvXl7br++bzDcd0Hs RkM/8CO9bOjQ9HAxwUIGalvWywITH3Bzu4Hpg1P4nQDln+lHDfwygApXpo8mKnXzS2P8LwAA AP//AwBQSwMEFAAGAAgAAAAhAGmiXyEeAQAAxwcAACwAAABwcHQvc2xpZGVNYXN0ZXJzL19y ZWxzL3NsaWRlTWFzdGVyMS54bWwucmVsc8TV3WrDIBQH8PvB3kHO/WKStukHNb0Zg8KuRvcA Ek8+WKKidixvPykMEiiOQsCbgIrn/Pgr5nj6GXryjcZ2SjLIkhQIykqJTjYMPi9vLzsg1nEp eK8kMhjRwql8fjp+YM+d32TbTlviq0jLoHVOHyi1VYsDt4nSKP1KrczAnR+ahmpeffEGaZ6m BTXTGlDOapKzYGDOwve/jNp3/r+2quuuwldVXQeU7k4LavtO4Dsf1dX5stw06BgkyXTeTge7 xPOB3petYspWIdk2pmwbkmX5kjTnrxnODvI2Q2/fLORYlPHorcpDsmzJgB6VBTMrYsqKYGZx QwumtomZ2iaYmn/r4z2tWRqyrWPS1iHZPqZs/yejs99v+QsAAP//AwBQSwMEFAAGAAgAAAAh AL2sJG++AgAAXgYAAB8AAABwcHQvbm90ZXNTbGlkZXMvbm90ZXNTbGlkZTIueG1srFRdT9sw FH2ftP8Q+T2kSdOsiZqiph8TEisVhR9gHLeJ5tie7ZYWxH/fjZMAAzbQRB9a175f55x77+j0 UDFnT5UuBU+Rf9JDDuVE5CXfpuj6auEOkaMN5jlmgtMUHalGp+OvX0Yy4cJQ7YA/1wlOUWGM TDxPk4JWWJ8ISTm8bYSqsIG/auvlCt9C3Ip5Qa8XeRUuOWr91Uf8xWZTEjoTZFdRbpogijJs oHZdlFJ30eRHoklFNYSx3n+UNAZsZM3y+lfLK0VpfeL770qu5UrZ5+V+pZwyB8aQw3EFxCCv fWjN7F8OZnDwXrhvu0g4OWxUNR7hBLA5hxQB/cf6G5xwQg/GIc0lebolxcUbtqSYv2HtdQmg gsekNaoG0Ws4QQdnzcqcOmcV3lJnxTChhWA5VY7/iLNxxhDsXJCf2uECkDeEiEth2tO0wHxL J1pSYq8aNshy3+WuKaqrkYVjjhKI1Cw/q7Z1Gktb/WoPnYMGDZrHBsbfwfQ7MEvbqc9hBO/D eL/SG5EfEXQBSGRp+We9MjGHDBxqYWtHCwInTJu1OTIK2XACsoDqPF9hhS+hwRhwlyLK3cm1 5cNaQJYuEhzf4yDsOGgEXe6qG1DxORX9z6ACRIPQsCruUvRrh5WhqmPGNvPnULNhuR26+6AX D+dzf+D2fd93wyiK3Swaxu4sGITzaBYH2Xz2gB4bClqZQ3U1u+oFrY6uzJRRDMuvnTozDkYw NwbaDieQ8f80sdJ0uwMG+VxDQGlHeqfKFN1nWRwF02HmZn64cMNZ/M2dLKKBuxj0w3CaDSfT /vwBSpZ+mBBF7Zo6y9t1CZevVlxVEiW02JgTIiqv2ZWeFLdUSVHaden32p27xwxaNgzj+jOM bG/Z2uyoddUChG4NEqZ+YHmxh1nECWx3kHdqryTs83ZQnkxqseuJG/8GAAD//wMAUEsDBBQA BgAIAAAAIQCKIBmYYQUAAMUSAAAhAAAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDgu eG1szFjdcuI2GL3vTN9B416zIP+b2WRnIdDpTDbJlOQBFFsEd23LlQWbtNOZfa32cfZJeiRb BFi2wCYXvQEjjo6+/++z3r57LAuy4rLJRXXm0DcDh/AqFVlePZw5d7fTXuyQRrEqY4Wo+Jnz xBvn3fmPP7yth02RXbInsVQEHFUzZGfOQql62O836YKXrHkjal7hv7mQJVP4KR/6mWSfwF0W fXcwCPslyyun2y+P2S/m8zzlFyJdlrxSLYnkBVOQv1nkdWPZ6mPYaskb0Jjd2yKppxraivvf bh8dYmByhQXqnEPzdFZkpGIlFsaiUmAgn3K1IGNWazkMpqlvJecaXa1+lvWsvpFm69XqRpI8 01QdhdPv/uhg5mcFGB76O9sfLBMbPs5lef6WDWER8njmwHFP+hOb2JA/KpK2i+nzarq43oNN F5M96L49ABKsD4XP61ajr9VxrTq3uSo4oWutWijD1kuRfmxIJaCnVr9VL71aWTKts6avF6Q1 v9JUHa7909jD4htjUyvo2hJ+ECG2jDncyBsEOzbxBoPYo55DtGUoDd0Osalxy1wP1eNIZE/a ovf4huNYlS4EAvW+tXPRqJl6KuBmNixWBYVAhBUPyKQCQcCGGZ//iqXmjzMHIkGme6v4Gg8f 43mDBxZmQ9gBH9haMJ2IvOrdzZCIpRoXnIG+00mdj4s8/UiUIDzLFfnAGsUlMXZD2kIyza7M GYaSV9kNk0wLtWZ+f2dMzIY4Gfa1OuOx9fa3fQ4jbmfBTcFSvhBFBiFczYpcsf49MQLyDPFr g+R453tBFGiH6mTY5/2AUgpE6/0gDjyKUNCRaMPIqN3GobWE9b5JrU1XdS7f8bSno6+l3ADg 0e3idTMq4k2sBQDr7cH6m1gLANbfg9XRtpbBAoANDmEtANjwENYCgI0OYS0A2PgQ1gKATQ5h W8C+HMJOAoZ1srwwp3RNNSnVbOUUTjYZ237YI03gnpDGM56KKiMFX/HiCHqTWyfQ3y5yeTy7 SYgT2KdiKdH9jhXe14F5Cn0+38uONveq1cy31exWu3qzlBmDfH8pa5uZ7iAo4WgFC1bMHcwA KHDGkaap6ZJjHmYm4nXx1Uu2LO3rbtT3Atrm+XPL32pvfpjQQfjiAkdKJi/NiJFXGaYd/ahF u19eYSg03tyoaXSrTumeqLHIRF3eOirbo4/i26qnOzWy40uor08lR/Ft1cadOtrxUS+i4bGE yX/UWssXu7Eu9UcJuMW3U487PteNId738O3UbMsX+aZtnS7fTl3v+DTZ0Q7Z0nen9lu+MIi+ zx//j/6AzLbThBkw9GT07bkqsJXogim+VYlM7XxpJcrUV3WIttOCftvYW4iQ488a7J2HTBUw TXCOlyP9gvOnG9CLqeu6vcQLpj1/4Ia9OEySXjwaJ9FoHCFpJ3853ayfQVWVl3yaPywlv14q U2G2RmAMqvtGYI/2BxHeBKn73Dkhgy46r9sgQuuWqRB6zN5sEYFuai91zFzJ1jO/L5nECV2T oAfG4FOc87oWiaxFZkWecXK1LO937BK+hl1w0wDqvaY50EBPMc06bifjCzoJgrg3nU4GPX/s XvRGdIIw9mkYTAZhGCbROm4brXkF6XS8HROuXz7//dOXz/+8QqyaSmJvGTCzXDZ406vNy/9S 5kjA0SgJ3XE8gvg+EvAiiXrvp2HQmwae749H8fuxhwTEHuoPU8nNNcgvWXcdg8WvrlDKPJWi EXP1JhVlv72L6dfiE5e1yM11DB10dzorhsk7CRIviT3PVhcIaaYcKyw00HcpJnMK+YHV1ysz LODyCOE/Nks1rovgRg19hmjV7fXT+b8AAAD//wMAUEsDBBQABgAIAAAAIQD6liEyEAMAAGsH AAAhAAAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDcueG1srFX/bpswEP5/0t4Bsb8p P0JIQEmqQsI0qWujpX0A15gEFWzPdtJk06S+1vY4fZKdDbRb20mVln8SOO7O933f+W5yum9q a0eErBid2v6JZ1uEYlZUdD21r69yZ2xbUiFaoJpRMrUPRNqns/fvJjyRdXGODmyrLMhBZYKm 9kYpnriuxBvSIHnCOKHwrWSiQQpexdotBLqD3E3tBp4XuQ2qqN3Fi7fEs7KsMJkzvG0IVW0S QWqkoH65qbjss/G3ZOOCSEhjov8uSR04oL2pEb21LeMmdmDw7Rkgx6u6sChqwJAaD22U/EoQ op/o7qPgK74UxvditxRWVejYLsZ2uw+dm3ml4AYP7rPwdZ8JJftSNLMJSoACaz+1QamD/oUg lJC9snBrxE9WvLl8xRdvFq94u/0BUMHjoRpVi+glnKCHM0eKWMsaYbJhdUGE5T8CbKMQZDln +FZalAFkzUSLFF/s+rwavj6Jb6yW+kJB430DEVFd2sAfgPMNWMOQdjYPfbwEug2Pap+y4qA5 uYF/Y0RJLdVKHWpiuAJEKClBQS3K92Doz/MgCJx4MMyd0AsiZxzFsTNOs3iUZqPYDxc/7L4o gKqqhuTVeivI5VZBO6BEgMDQBnBhCHXOrqHuRmU1QXChOnnUbOC73gja1Q8mwLSC6k0NRjta LJFAX55l0RShBIoFnD0oeGwF+bcsg16WnDEFYvwpTHAMYUolWmW+bpGAE3pxelFbJf9LHHJU RsKekVVdFcS62DY3z3gZHIMXGIeQ+lVqDO+GkeP17SKb+4vhcOzk+cJzwiyYO6m/gDYO/Wi4 8KIoikePfSs1cgrVvbVdH+5/fni4/3WEXjUt209GGFPnEpqfm4G1FRVcwDSNoyAbp1B+CBdw Ho+cszwaOvlwEIZZOj7LBnABIcYPEyyImdWfim5ngPHFnG8qLJhkpTrBrHHbheFydkcEZ5XZ Gb7XLZ4dqmGsxNFg4I+90agbS1CluXV9tQBBT3xdNq7FZ8QvdzB+UAIrDvo/MyYOS60bak8u Gnu/JGe/AQAA//8DAFBLAwQUAAYACAAAACEAZrBoO0wDAAC8CAAAIQAAAHBwdC9zbGlkZUxh eW91dHMvc2xpZGVMYXlvdXQ2LnhtbKxW7W6bMBT9P2nvYLHflI8ACShJ1ZAwTWqbaGkfwAWn QTU2s50s2TSpr7U9Tp9k1wbars2kasufBMy9h3vO/WJ4uqso2hIhS85GlnfiWoiwnBclux1Z 11eZPbCQVJgVmHJGRtaeSOt0/P7dsE4kLc7xnm8UAgwmEzyy1krViePIfE0qLE94TRg8W3FR YQW34tYpBP4K2BV1fNeNnAqXzGr9xVv8+WpV5mTK801FmGpABKFYQfxyXdayQ6vfglYLIgHG eP8ZktrXwFaVipI5o3sLGVOxhUPPGgP7fEkLxHAFB1faChkz/UTWV4IQfcW2H0W9rBfCOFxu FwKVhQZoHS2nfdCamVsGZnDhvHC/7ZBwsluJajzECWiBdiMLUrbXv+CEE7JTKG8O86fTfD0/ YJuvZwesne4FEMHjSzWrhtFrOn5Hp9HBe2TVmGJwPef5nUSMA09Nv6GXX247MM1Zw9dr9Ez4 1q55aPTo7CVoasRSuwkv9pr4DfybQ5xQqZZqT4kRBMLGCYDDD8hPsa5rwuzrJdR1pVJKMNR9 K54ap7TM75DiiBSlQhdYKiKQqQLoAoAcgjoKktNCElYssMCfnyOfXZu4cQJvhqC7COGykfDv QvY6IadYEbSgOCdrTguIwNeQUHOdYv+kaaGA8jdoC0xXFhQiVIlniBtpdQL+S+MV9IOu7u9+ 6E0z3/ftuBdmduD6kT2I4tgeTNK4P0n7sRfMflhtogugqsqKZOXtRpD5RlmvUgWCHkpVz3Pc PgwAz39KCsSg3Y+blqBLS8a5LofniekdIzErJZrMfNlgAW/oktM1yhEa4LiKhJ0iS1oWBF1u qpsXugTH0AUWDEAflMY0xJHrdpZOvVkYDuwsm7l2kPpTe+LNoIwDLwpnbhRFcf+xbqVmziC6 t5brw/3PDw/3v45Qq2aSdCsG5v25hIlUm8m/ESU04GQSR346mED4ATTgNO7bZ1kU2lnYC4J0 MjhLe9CA4OMFSS6I2X6finYLw+GrzVmVueCSr9RJziunWcFOzb8SUfPSbGHPbVf5FtORFfih 2+vFYWgmoQnNDJcuWGCg16cZaVRc4Hq+hemDE/hmgPJPzVENXwntnngy0dS7r47xbwAAAP// AwBQSwMEFAAGAAgAAAAhAET9rvi8AwAAmgsAACEAAABwcHQvc2xpZGVMYXlvdXRzL3NsaWRl TGF5b3V0Mi54bWysVl1u4zYQfi/QOxDqs6IfS7ItxF7EslUUyCZBnRyAkaiIXUpUSdprtyiw 12qPsyfpkBKTTdYF7MYvskXNfJz55uNwLj/sGoa2REjK25kTXPgOIm3BS9o+zZyH+9ydOEgq 3JaY8ZbMnD2Rzof5jz9cdqlk5TXe841CgNHKFM+cWqku9TxZ1KTB8oJ3pIVvFRcNVvAqnrxS 4M+A3TAv9P3EazBtncFfHOPPq4oWZMmLTUNa1YMIwrCC+GVNO2nRumPQOkEkwBjv1yGpfQfZ 8sffHGSMxBZeA2cOeRdrVqIWN7BwTxUjCNhBGW8VIBkD2d0LQrRpu/1ZdOvuThi/m+2dQLTU OIO/4w0fBjPz2oIZ/PHeuD9ZJJzuKtHML3EKZKDdzIGa7fUTnHBKdgoV/WLxslrUtwdsi3p1 wNqzG0AEz5tCubs+o+/TCW06PR3Bc1a9KQbXa158kqjlkKdOv0+vuNlaMJ2zhu9q1DOvNLOD Xf/R8GHtJXBqyFK7BS/3OvFH+DWLOGVSrdWeEUMIhI1TAIcH0M+wFjZp3Yc1CLtRGSMYhD+Q p+YZo8UnpDgiJVXoI5aKCGSCgWMAkJfAjoLiDJCkLe+wwL9+i3z1YOLGKewMQdsI4W9P4X8T ObJEDmpCdwwXpOashCBCjQrqs6SdSCstQRSW+TMwCgVAbMueqXsnw1q2hmD5imHg2dSvf9gt TRonFHVNCg5nlJEtYUfAG6ZPgL+vqTgefaTreAJ6zjdC1UcHH50KT6uD6NBJzqrtyGp7iRV5 JWxDyP8Xdt8vSgXH+Q/o+ZhVDjRZLXZzqE3b0M3lXf2jgpavO/efYRws8zAM3ekozt3IDxN3 kkyn7mSRTceLbDwNotVfztDESkhV0Ybk9GkjyO1GXw9Q+TfN4lAbGgWeP4bbLQhf9AoxaPfz liW2Zck5163u245jpPTewlRK9JX5fYMF7GCLc8ZWdF5GEsvImtGSoJtN8/iGl/h9nbgXLExP AH2QGtN/zqzbVbYMVnE8cfN85btRFi7dRbACGUdBEq/8JEmm42fdSp15C9EdK9evX/7+6euX f86gVXNL2vEJLoVrCbdtZ6aajaBwABeLaRJmkwWEH8EBXE7H7lWexG4ej6IoW0yushEcQPAJ orQQxIx2v5TDiAmL342FDS0El7xSFwVvvH6+9Dr+mYiOUzNiBv4wp24x3Hcjf5wkQRiObXuB KE13sdFCCnpENJc1Ex9xd7uF9oNTmIhB/5lZ6mAGhmtAm76Y6NztTD3/FwAA//8DAFBLAwQU AAYACAAAACEAIAC5dvQEAABdEQAAIQAAAHBwdC9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQz LnhtbMxY227jNhB9L9B/ENRnx5KsqxFnEd/aAtkkWCcfwEh0LCx1KUV77RYF9rfaz9kv2TOU 5Es2Rb1ZI8hLIlPk8MzMGc6hzt+tM2GsuKzSIh+Y9pllGjyPiyTNHwfm/d20E5pGpVieMFHk fGBueGW+u/j5p/OyX4nkim2KpTJgI6/6bGAulCr73W4VL3jGqrOi5DnezQuZMYWf8rGbSPYJ tjPRdSzL72Yszc1mvTxmfTGfpzEfF/Ey47mqjUgumAL+apGWVWutPMZaKXkFM3r1ISS1KeFt xePfOEtMQ0+UKwzZ5gV8j2ciMXKWYWDGY9rcoIlc6rdVeSc5p3n56ldZzspbqRddr26lkSZk pFlsdpsXzTT9M8c0PHSfLH9sLbH+ei6zi3PWRzSM9cBE0jb0F4tYn6+VEdeD8W40Xtw8Mzde TJ6Z3W03AILtpsh3WXv0rTtO685dqgQ37K1X9VSGpVdF/LEy8gJ+kvu1e/H1qjVGPpP5cmHU oVdkqplXv9TxaOdXOqYt0G0kAsfp2T0dDte1/Mh6EpQgCBwXgwaFxu75jhV4epPWEjapTZd9 tR4WyYZC+oD/yBzL40UBlipawfqiUjO1EcgznlfCBiKDiUeUkQALWD/h8w8Yqv4cmNgSez7o xMcMEWBCNNs2K5HuQ4sINusjJPgDI4JRPfK8cz9DPWZqJDjDRo136mIk0vijoQqDJ6ky3rNK cWnoEKJ6gZGsK72HNsnz5JZJRvC2li/vG0TYGVFovdcBocz8d/oR77oU7oh7t4LFfFEIFIPh kElUS5vnFzGBom+ibMDpljgvIoQTWX4AchxUySEhPMuyw6CJQ11kxxDiobb5HCEyJq90gaZ5 gpOGHimnD8trHKcayR5NcCTWr6tCpMk0FYLm6tOUj4Q0VkyAfWs6gpDONFf1SADYmglI8nay TvaeHbyrd6qZVvOV7ICADlG3Rup6AVAg3EfAtcNXhEsYG7i9HdzIRpkfC9d/RbiEsYHr7uDa vcAmFMeFlzwjG3tZ3EvwadlAIBu83h7e0AkpyW8PL4Fs8Po7vI4TIrxvES+BbPAGe3gDt3d8 ub0mHwhkgzfc4SWwx9fba+IlkA3eaA+v7wVvs94IZH0S76kI3fMJPc7kbXPXbr1cA1BL1hKg OtAAaAff3efdts+PmeIHfV431R/t84mCtIFYWjAxb/t93dZICOtw0cNMR66WaVpdtEql1Wm6 q7a9WP/QcZ1DsZP2/svx7PHUcZxO1POmHddy/E7oR1EnHI6iYDgK0FMmf5uNDE3gqkozPk0f l5LfLJVJLDtIB4TTc5KsZ3etABcU29kFHhho+Wnll9emZVoUJPv2BZh7CgE2V7LOzB9LJrFD m5z/UWPfk5zTRsRvIzKDjOLG9TJ7eBIXLfp/lLC4AMP0s6HRwhfS8ZS8nYzG9sTzws50OrE6 7sgZd4b2BDR2bd+bWL7vR8GWtxV5ngPdsXT98vmfX758/vcEXNWKub0A4/i5qnDzKPW9dClT FOBwGPnOKBwCvosCHEdB53Lqe52p13Pd0TC8HPVQgFhju/1Ycn07/z1pvhJg8JubfZbGsqiK uTqLi6xbfyLolsUnLssCKpmK0Go+NWgJbdtO1Iss16+lvsamLz0tWrhAN3x9dxHyPStvVvoY xkcN8B9SHEMlPmOA4jR1N4V8bz+LXHwFAAD//wMAUEsDBBQABgAIAAAAIQAxZ2mbfwQAAGwS AAAhAAAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDQueG1s7FhdbuM2EH4v0DsQ6rOi f9kSkixi2SoKZJOgTg7ASHSsLiWqJO3ELQrstdrj7Ek6pETHSZza7voxL7ZEfRzOfPPDIU8/ PdUULQkXFWvOLO/EtRBpClZWzcOZdXeb20MLCYmbElPWkDNrRYT16fzHH07bVNDyEq/YQiKQ 0YgUn1lzKdvUcUQxJzUWJ6wlDXybMV5jCa/8wSk5fgTZNXV8142dGleN1c/n+8xns1lVkDEr FjVpZCeEE4ol6C/mVSuMtHYfaS0nAsTo2S9VkqsWrJWP7Pr+NwtpHF/CiGedg+nFlJaowTUM 3D4ylLFGghj9SbS3nBAFapY/83ba3nA942p5w1FVKgn9TMvpP/Qw/doADB6cV9MfjCScPs14 fX6KU2ACPZ1Z4LCV+oVJOCVPEhXdYPE8Wsyvt2CL+WQL2jELgAbrRcHXbWfRW3N8Y85tJSlB 3tqqDoph6iUrvgjUMLBTmd+ZV1wtjTBlsxLfzlFPuxLV47qPmg+DF8CpJks+jVi5Uobfw78e xCkVcipXlGhCQG2cgnD4AfopVlFNGvtuClFdy4wSDFHfkyfPM1oVX5BkiJSVRJ+xkIQjqe0S SuQpsCPBOb1I0pQ3mONfNyVf3Gm9cQorg9JGQ3jsKHyfyMAQ2UcTuqG4IHNGS1DCV1Ih7gxp B9Iq/oBswHRmQQRCeBgfvMOtoutVlIXRAPJVh5oXu6561vyagAvdYAjjFlJhF0Z+lMRBT0Qn SRPQudlwstVram26pJ5OG5yWZKboVfr7w25RYH8DAI/+Fmy4iTUAwAZbsO4m1gAAG77Fei90 MADARruwBgDYeBfWAAA72IU1AMAOd2ENALDJLmwHUFz36aQco7MJZiKQsE6b78wuFUE6ucSL 7IKVu9X0umZJHbgHJPSUFKwpESVLQvcQr7PsAPG384rvL10nxAHSc7bgcr638mGXkXu7I69m W6XDLnLUuhb+V13TnBytrmn/6a1CVRr9sLlnbKtrcTj8KGywI3wUtvSjsK0boY/CtkfDFpnC NsaSvOjWdCn+/1Wta4JLCT3qq75NO+j9AndIUzyDE4w6jvzpR944933fToIot0PXj+1hnCT2 cJQlg1E2SLxw8pfVd+YlmCqrmuTVw4KT64U688CW9qoD3tZbB57jDuC85vnPGzHooKYfd7+J jVtyxlT/vtlGR9/XRneOmUneeeb3Beawgmmqd3TVhzjnuIwMDCNTWpUEXS3q+1e8xMfgBe4D QPRWanZszIdQs47bSTb2JlE0tPN84tph5o/tkTeBMA69OJq4cRwng3XcCmV5A9rtG67fvv79 07ev/xwhVnUlMXcC0O1eCjhCtvqovuAVJOBolMR+NhyB+iEk4DgZ2Bd5HNl5FIRhNhpeZAEk IMzxwrTgRF9W/FL2lyYw+Oaio64KzgSbyZOC1U53Y+K07JHwllX60sRz+5uXJYZGPvCTIBkE UTDQRzatm26fjLZggrrx0CdQyj/j9noJ/RVO4Y4H4j/TQy3c6oAfFfQZomw3t0Tn/wIAAP// AwBQSwMEFAAGAAgAAAAhAOM89NLjBQAAOxwAACEAAABwcHQvc2xpZGVMYXlvdXRzL3NsaWRl TGF5b3V0NS54bWzsWetu4kYU/l+p72C5vwm+X1DIKhCoKmWTqJAHmNhDcNf2uOOBkK0q7Wu1 j7NP0nPGHjC3XYfkx0rNHzDm8+dzmfP5+Mz5h1WWakvKy4Tlfd08M3SN5hGLk/yxr99Px51A 10pB8pikLKd9/ZmW+oeLn386L3plGl+TZ7YQGnDkZY/09bkQRa/bLaM5zUh5xgqaw38zxjMi 4Cd/7MacPAF3lnYtw/C6GUlyvb6et7mezWZJRK9YtMhoLioSTlMiwP5ynhSlYivasBWclkAj r942STwX4K14YtPV9IndPvyhaxLMl3Da1C/A/2iSxlpOMjgxZFlBeFKyXP5TFlNOKWLy5a+8 mBR3XF5ws7zjWhIjQX2h3q3/qGHyZw4wOOjuXP6omEhvNePZxTnpQTS0VV+HpD3jJ1xEenQl tKg6GW3ORvPbA9hoPjqA7qobgAXrm0K+i8qjfXcs5c40ESnVzLVXFZTApdcs+lRqOQM/0f3K vehmqcjQZ6Qv5lodeqSqcdWfMh4KX0JMZbDEasDiZ3T8Ab7lSdJLSzERzymkAI6XqSkTQHox nf1ehbZxGrxtwsFJ0gNT4AOSlRKsA5p37idQB5kYppRAndShFhfDNIk+aYJpNE6E9pGUgnJN yCiUaMA5sAtIZU1J8/iOcAJGbJgv76WXpAd3BheVP3BYBfx42O112DHndymJ6JylMVhgISWs UBXfkzKA8dRhucJaUgk7kgiM1s6SdFwfClyuS9O1XdO00aTN6nQMxzADEBdco54d+p60ubn0 MMXohYqIyrBG8mjOQC0eKspm9upkaxnh17IukjyGAsdDvPvD4gZUTBpSrQWt/NzXLQctfVBu NtaGPLTAjppQedWK1dhnRSq0A8y0N6yh6UgL2rCawT4rUtWszobVtH3TQ3ArWoncDgFy1bRu gzawAmnDqbTIVdN6G1rLCsCEV1iLXDWt36D1HVuuw1OtRa6aNtjQImf7lB2ILXLVtGGD1nP9 V6UMuaTaNGtCKhreBFbdWrrk3U9XOBQcKXDllsJB+b5YxRylYkOWC6jVLSGTqnG6kGF1z0k6 q2Wskhh8rMow4cFERgy1tkrIcRmzTN8JfPcbMmaHrgnFgYg2OiZlqJmovSfVRp0qygYADpWY NJUMS2iNVQDAKoloYKWSrLEKAFhV900srso1VgEAq4r5KFYBAKsq9ChWAQCryu4oVgEAq2rp KFYBAFsViOoEZHylSK59+zEqSJYRfKiilc/fF7QlExqxPNZSuqTpgQLdpZd18QL66Tzh7dnr J39rxRmzBRfz1sY7VUW2p09mB9mhN3nT7sxVujbd7c6kxaeLWtUfV90ZCtyfC8Kh7aw1TkZb tsqtNc5zXMMCc6ETO9armT4o33uv1tffezXol997tb5u/x97NU9p2qFeTbZGp8vavpRJnTxZ yo71axspe+/XMObb/c97v3ZkpvPNN57dhuq9X8MRWvU2uBubH7Vf85W2XRFBt15CPewwTxe2 ql+LBQwQt19Hzeqd6uj7qLzr7vQLTm4GlvKHfL+fwSwaJ8t/Wa55NbYsqxPa7rjjGJbXCbww 7ASDYegPhj40MKO/9XrIGoOrIsnoOHlccHq7EDqyb40FYDx5aPBpm13Dh/G7aW3eL8AGvPxt 22gYEVYz9jFjOFxtjjn9t0jMTEDrvP/wMb8z83xJct42IqGKyCRNYqrdLLKHnbjIEcRrFyxs 7wD1wdB8Z47yktCs1+1oeGWOXDfojMcjo+MMravOwBzBMnZMzx0ZnueF/nrdluh5Dta1Xa5f v/zzy9cv/77BWpVzebW9Aw+F6xLm+4XcdVnwBApwMAg9axgMwHwHCvAq9DuXY8/tjF3bcYaD 4HJoQwHCNabTiziVe0+/xfUeGJzc27fKkoizks3EWcSybrUB1i3YE+UFS+QemGnUG2lLAhM+ y3Yd2w8NT70KgpVya0FZCy7g3pXUtJR/JMXtEtSa9GDLDipsKE8VsEkHeUToBoK+q02/i/8A AAD//wMAUEsDBBQABgAIAAAAIQCx6jYLvwIAAF0GAAAfAAAAcHB0L25vdGVzU2xpZGVzL25v dGVzU2xpZGUzLnhtbKxUXU/bMBR9n7T/EPk9pEnTrImaoqYfExIrFYUfYBy3iebYnu2WFsR/ 342TAAM20MRL69j365xz7x2dHirm7KnSpeAp8k96yKGciLzk2xRdXy3cIXK0wTzHTHCaoiPV 6HT89ctIJlwYqh3w5zrBKSqMkYnnaVLQCusTISmHt41QFTbwqbZervAtxK2YF/R6kVfhkqPW X33EX2w2JaEzQXYV5aYJoijDBmrXRSl1F01+JJpUVEMY6/1HSWPARtYsr/+1vFKU1ie+/67k Wq6UfV7uV8opc2AMORxXQAzy2ofWzH5yMIOD98J920XCyWGjqvEIJ4DNOaQI6D/Wv+CEE3ow DmkuydMtKS7esCXF/A1rr0sAFTwmrVE1iF7DCTo4a1bm1Dmr8JY6K4YJLQTLqXL8R5yNM4Zg 54L81A4XgLwhRFwK056mBeZbOtGSEnvVsEGW+y53TVFdjSwcc5RApGb5WbWt01ja6ld76Bw0 aNA8NjD+DqbfgVnaTn0OI3gfxvuV3oj8iKALQCJLyz/rlYk5ZOBQC1s7WhA4YdqszZFRyIYT kAVU5/kKK3wJDcaAuxRR7k6uLR/WArJ0keD4Hgdhx0Ej6HJX3YCKz6nofwYVIBqEhlVxl6Jf O6wMVR0ztpk/h5oNy+3Q3Qe9eDif+wO37/u+G0ZR7GbRMHZnwSCcR7M4yOazB/TYUNDKHKqr 2VUvaHV0ZaaMYlh+7dSZcX8Ec2Og7XACGf9PEytNtztgkM81BJR2pHeqTNF9lsVRMB1mbuaH Czecxd/cySIauItBPwyn2XAy7c8foGTphwlR1K6ps7xdl3D5asVVJVFCi405IaLyml3pSXFL lRSlXZd+r925e8xSFAXhsBf3w8i2li3NTlpXLCDotiBh6geWF3sYRZzAcgd1p/ZKwjpv5+TJ pNa6HrjxbwAAAP//AwBQSwMEFAAGAAgAAAAhAHJAWyW/AgAAXgYAAB8AAABwcHQvbm90ZXNT bGlkZXMvbm90ZXNTbGlkZTEueG1srFTtTtswFP0/ae8Q+X/IR9PQRk1R048JiZWKwgMYx22i ObZnu6Ud4t134yTAgA008ad17Pt1zrn3js4OFXP2VOlS8BQFJz5yKCciL/k2RTfXC3eAHG0w zzETnKboSDU6G3/9MpIJF4ZqB/y5TnCKCmNk4nmaFLTC+kRIyuFtI1SFDXyqrZcrfAdxK+aF vh97FS45av3VR/zFZlMSOhNkV1FumiCKMmygdl2UUnfR5EeiSUU1hLHef5Q0BmxkzfL6X8tr RWl94vtvSq7lStnn5X6lnDIHxpDDcQXEIK99aM3sJwczOHgv3LddJJwcNqoaj3AC2JxDioD+ Y/0LTjihB+OQ5pI83ZLi8g1bUszfsPa6BFDBY9IaVYPoNZywg7NmZU6d8wpvqbNimNBCsJwq J3jE2ThjCHYhyA/tcAHIG0LElTDtaVpgvqUTLSmxVw0bZLnvctcU1dXIwjFHCURqlp9X2zqN pa1+tYfOQYMGzWMD4+9geh2Ype3U5zDC92G8X+mtyI8IugAksrT8s16ZmEMGDrWwtaMFgROm zdocGYVsOAFZQHWer7DCV9BgDLhLEeXu5MbyYS0gSxcJju9xEHUcNIIud9UtqPicit5nUAGi QWhYFb9S9HOHlaGqY8Y28+dQs2G5Hbr70B8O5vOg7/aCIHCjOB66WTwYurOwH83j2TDM5rMH 9NhQ0MocqqvZVS9odXRlpoxiWH7t1JlxMIK5MdB2OIGM/6eJlabbHTDIFxoCSjvSO1Wm6D7L hnE4HWRuFkQLN5oNT93JIu67i34viqbZYDLtzR+gZBlECVHUrqnzvF2XcPlqxVUlUUKLjTkh ovKaXelJcUeVFKVdl4Hf7tw9ZikCDk/9eOCHA9tbtjY7al21AKFbg4Sp71he7mEWcQLbHeSd 2isJ+7wdlCeTWux64sa/AQAA//8DAFBLAwQUAAYACAAAACEAcfDyucACAABeBgAAHwAAAHBw dC9ub3Rlc1NsaWRlcy9ub3Rlc1NsaWRlNS54bWysVO1O2zAU/T9p7xD5f0jz0dJETVHTjwmJ lYrCAxjHbaI5tme7pR3i3XfjJMCADTTxp3Xs+3XOufeOzg4Vc/ZU6VLwFPknPeRQTkRe8m2K bq4X7hA52mCeYyY4TdGRanQ2/vplJBMuDNUO+HOd4BQVxsjE8zQpaIX1iZCUw9tGqAob+FRb L1f4DuJWzAt6vYFX4ZKj1l99xF9sNiWhM0F2FeWmCaIowwZq10UpdRdNfiSaVFRDGOv9R0lj wEbWLK//tbxWlNYnvv+m5FqulH1e7lfKKXNgDDkcV0AM8tqH1sx+cjCDg/fCfdtFwslho6rx CCeAzTmkCOg/1r/ghBN6MA5pLsnTLSku37AlxfwNa69LABU8Jq1RNYhewwk6OGtW5tQ5r/CW OiuGCS0Ey6ly/EecjTOGYBeC/NAOF4C8IURcCdOepgXmWzrRkhJ71bBBlvsud01RXY0sHHOU QKRm+Xm1rdNY2upXe+gcNGjQPDYw/g4m7MAsbac+hxG8D+P9Sm9FfkTQBSCRpeWf9crEHDJw qIWtHS0InDBt1ubIKGTDCcgCqvN8hRW+ggZjwF2KKHcnN5YPawFZukhwfI+DqOOgEXS5q25B xedUhJ9BBYgGoWFV/ErRzx1WhqqOGdvMn0PNhuV26O6DXjycz/2+G/q+70aDQexmg2HszoJ+ NB/M4iCbzx7QY0NBK3OormZXvaDV0ZWZMoph+bVTZ8b9EcyNgbbDCWT8P02sNN3ugEG+0BBQ 2pHeqTJF91kWD4LpMHMzP1q40Sw+dSeLQd9d9MMommbDyTScP0DJ0o8SoqhdU+d5uy7h8tWK q0qihBYbc0JE5TW70pPijiopSrsu/V67c/eYpSjyT3th5Mfh0PaWrc2OWlctQOjWIGHqO5aX e5hFnMB2B3mn9krCPm8H5cmkFrueuPFvAAAA//8DAFBLAwQUAAYACAAAACEAhQMfrr4CAABe BgAAHwAAAHBwdC9ub3Rlc1NsaWRlcy9ub3Rlc1NsaWRlNC54bWysVO1O2zAU/T9p7xD5f0jz 0dBGTVHTjwmJlYrCAxjHbaI5tme7pR3i3XfjJMCADTTxp3Xs+3XOufeOzg4Vc/ZU6VLwFPkn PeRQTkRe8m2Kbq4X7gA52mCeYyY4TdGRanQ2/vplJBMuDNUO+HOd4BQVxsjE8zQpaIX1iZCU w9tGqAob+FRbL1f4DuJWzAt6vdircMlR668+4i82m5LQmSC7inLTBFGUYQO166KUuosmPxJN KqohjPX+o6QxYCNrltf/Wl4rSusT339Tci1Xyj4v9yvllDkwhhyOKyAGee1Da2Y/OZjBwXvh vu0i4eSwUdV4hBPA5hxSBPQf619wwgk9GIc0l+TplhSXb9iSYv6GtdclgAoek9aoGkSv4QQd nDUrc+qcV3hLnRXDhBaC5VQ5/iPOxhlDsAtBfmiHC0DeECKuhGlP0wLzLZ1oSYm9atggy32X u6aorkYWjjlKIFKz/Lza1mksbfWrPXQOGjRoHhsYfwcTdmCWtlOfwwjeh/F+pbciPyLoApDI 0vLPemViDhk41MLWjhYETpg2a3NkFLLhBGQB1Xm+wgpfQYMx4C5FlLuTG8uHtYAsXSQ4vsdB 1HHQCLrcVbeg4nMqws+gAkSD0LAqfqXo5w4rQ1XHjG3mz6Fmw3I7dPdBbziYz/2+G/q+70Zx PHSzeDB0Z0E/msezYZDNZw/osaGglTlUV7OrXtDq6MpMGcWw/NqpM+NoBHNjoO1wAhn/TxMr Tbc7YJAvNASUdqR3qkzRfZYN42A6yNzMjxZuNBueupNF3HcX/TCKptlgMg3nD1Cy9KOEKGrX 1Hnerku4fLXiqpIoocXGnBBRec2u9KS4o0qK0q5Lv9fu3D1m0LK9MAyi037cCQRV2lHrqgUI 3RokTH3H8nIPs4gT2O4g79ReSdjn7aA8mdRi1xM3/g0AAP//AwBQSwMEFAAGAAgAAAAhAKq2 H3zBAgAAXwYAACAAAABwcHQvbm90ZXNTbGlkZXMvbm90ZXNTbGlkZTEwLnhtbKxU607bMBT+ P2nvEPl/yKVpaaKmqOllQmKlovAAxnGbaI7t2W5ph3j3nTgJMGADTahS69rn9n3fOWd0dqiY s6dKl4KnKDjxkUM5EXnJtym6uV64Q+Rog3mOmeA0RUeq0dn465eRTLgwVDvgz3WCU1QYIxPP 06SgFdYnQlIObxuhKmzgr9p6ucJ3ELdiXuj7A6/CJUetv/qIv9hsSkJnguwqyk0TRFGGDdSu i1LqLpr8SDSpqIYw1vuPksaAjaxZXv9qea0orU98/03JtVwp+7zcr5RT5sAYcjiugBjktQ+t mf3LwQwO3gv3bRcJJ4eNqsYjnAA255AioP9Yf4MTTujBOKS5JE+3pLh8w5YU8zesvS4BVPCY tEbVIHoNJ+zgrFmZU+e8wlvqrBgmtBAsp8oJHnE2zhiCXQjyQztcAPKGEHElTHuaFphv6URL SuxVwwZZ7rvcNUV1NbJwzFECkZrl59W2TmNpq1/toXPQoEHz2MD4O5heB2ZpO/U5jPB9GO9X eivyI4IuAIksLf+sVybmkIFDLWztaEHghGmzNkdGIRtOQBZQnecrrPAVNBgD7lJEuTu5sXxY C8jSRYLjexxEHQeNoMtddQsqPqei9xlUgGgQGlbFrxT93GFlqOqYsc38OdRsWG6H7j704+F8 HvTdXhAEbjQYxG42GMbuLOxH88EsDrP57AE9NhS0MofqanbVC1odXZkpoxiWXzt1Zhz4Ixgc A32HE0j5f6JYbbrlAZN8oSGgtDO9U2WK7rMsHoTTYeZmQbRwo1l86k4Wg7676PeiaJoNJ9Pe /AFqlkGUEEXtnjrP230Jl692XFUSJbTYmBMiKq9Zlp4Ud1RJUdp9Gfjt0t1jBj0b94an8PFt B0C9UKWdta5auOr2IGHqO5aXexhGnMB6B32n9krCQm8n5cmkVrseufFvAAAA//8DAFBLAwQU AAYACAAAACEA+QrvyL8CAABeBgAAHwAAAHBwdC9ub3Rlc1NsaWRlcy9ub3Rlc1NsaWRlOS54 bWysVF1P2zAUfZ+0/xD5PaRJ06yJmqKmHxMSKxWFH2Act4nm2J7tlhbEf9+NkwADNtDES+vY 9+ucc+8dnR4q5uyp0qXgKfJPesihnIi85NsUXV8t3CFytME8x0xwmqIj1eh0/PXLSCZcGKod 8Oc6wSkqjJGJ52lS0ArrEyEph7eNUBU28Km2Xq7wLcStmBf0epFX4ZKj1l99xF9sNiWhM0F2 FeWmCaIowwZq10UpdRdNfiSaVFRDGOv9R0ljwEbWLK//tbxSlNYnvv+u5FqulH1e7lfKKXNg DDkcV0AM8tqH1sx+cjCDg/fCfdtFwslho6rxCCeAzTmkCOg/1r/ghBN6MA5pLsnTLSku3rAl xfwNa69LABU8Jq1RNYhewwk6OGtW5tQ5q/CWOiuGCS0Ey6ly/EecjTOGYOeC/NQOF4C8IURc CtOepgXmWzrRkhJ71bBBlvsud01RXY0sHHOUQKRm+Vm1rdNY2upXe+gcNGjQPDYw/g6m34FZ 2k59DiN4H8b7ld6I/IigC0AiS8s/65WJOWTgUAtbO1oQOGHarM2RUciGE5AFVOf5Cit8CQ3G gLsUUe5Ori0f1gKydJHg+B4HYcdBI+hyV92Ais+p6H8GFSAahIZVcZeiXzusDFUdM7aZP4ea Dcvt0N0HvXg4n/sDt+/7vhtGUexm0TB2Z8EgnEezOMjmswf02FDQyhyqq9lVL2h1dGWmjGJY fu3UmXE8grkx0HY4gYz/p4mVptsdMMjnGgJKO9I7VaboPsviKJgOMzfzw4UbzuJv7mQRDdzF oB+G02w4mfbnD1Cy9MOEKGrX1Fnerku4fLXiqpIoocXGnBBRec2u9KS4pUqK0q5Lv9fu3D1m KepHQGIc9MLY9patzY5aVy1A6NYgYeoHlhd7mEWcwHYHeaf2SsI+bwflyaQWu5648W8AAAD/ /wMAUEsDBBQABgAIAAAAIQB2vjvFwAIAAF4GAAAfAAAAcHB0L25vdGVzU2xpZGVzL25vdGVz U2xpZGU4LnhtbKxUXU/bMBR9n7T/EPk9pEnTkEZNUdOPCYmVisIPMI7bRHNsz3ZLO8R/342T AAM20MRL69j365xz7x2dHSrm7KnSpeAp8k96yKGciLzk2xTdXC/cGDnaYJ5jJjhN0ZFqdDb+ +mUkEy4M1Q74c53gFBXGyMTzNClohfWJkJTD20aoChv4VFsvV/gO4lbMC3q9yKtwyVHrrz7i LzabktCZILuKctMEUZRhA7XropS6iyY/Ek0qqiGM9f6jpDFgI2uW1/9aXitK6xPff1NyLVfK Pi/3K+WUOTCGHI4rIAZ57UNrZj85mMHBe+G+7SLh5LBR1XiEE8DmHFIE9B/rX3DCCT0YhzSX 5OmWFJdv2JJi/oa11yWACh6T1qgaRK/hBB2cNStz6pxXeEudFcOEFoLlVDn+I87GGUOwC0F+ aIcLQN4QIq6EaU/TAvMtnWhJib1q2CDLfZe7pqiuRhaOOUogUrP8vNrWaSxt9as9dA4aNGge Gxh/B9PvwCxtpz6HEbwP4/1Kb0V+RNAFIJGl5Z/1ysQcMnCoha0dLQicMG3W5sgoZMMJyAKq 83yFFb6CBmPAXYoodyc3lg9rAVm6SHB8j4Ow46ARdLmrbkHF51T0P4MKEA1Cw6r4laKfO6wM VR0ztpk/h5oNy+3Q3Qe9YTyf+wO37/u+G0bR0M2ieOjOgkE4j2bDIJvPHtBjQ0Erc6iuZle9 oNXRlZkyimH5tVNnxvEI5sZA2+EEMv6fJlaabnfAIF9oCCjtSO9UmaL7LBtGwTTO3MwPF244 G566k0U0cBeDfhhOs3gy7c8foGTphwlR1K6p87xdl3D5asVVJVFCi405IaLyml3pSXFHlRSl XZd+r925e8ygZfunUW8QxdGp7S1bmx21rlqA0K1BwtR3LC/3MIs4ge0O8k7tlYR93g7Kk0kt dj1x498AAAD//wMAUEsDBBQABgAIAAAAIQAGQrgNwQIAAF4GAAAgAAAAcHB0L25vdGVzU2xp ZGVzL25vdGVzU2xpZGUxMS54bWysVF1P2zAUfZ+0/xD5PaRJ09BETVHTjwmJlYrCDzCO20Rz bM92SzvEf9+NkwADNtDES+tc+36cc+89o7NDxZw9VboUPEX+SQ85lBORl3ybopvrhTtEjjaY 55gJTlN0pBqdjb9+GcmEC0O1A/5cJzhFhTEy8TxNClphfSIk5XC3EarCBj7V1ssVvoO4FfOC Xi/yKlxy1Pqrj/iLzaYkdCbIrqLcNEEUZdhA7boope6iyY9Ek4pqCGO9/yhpDNjImuX1v5bX itL6xPfflFzLlbLXy/1KOWUOjCGH4wqIQV570T6znxyewcF74b7tIuHksFHVeIQTwOYcUgT0 H+tfcMIJPRiHNEbyZCXF5RtvSTF/47XXJYAKHpPWqBpEr+EEHZw1K3PqnFd4S50Vw4QWguVU Of4jzsYZQ7ALQX5ohwtA3hAiroRpT9MC8y2daEmJNTVskOW+y11TVFcjC8ccJRCpWX5ebes0 lrb61h46Bw09aC4bGH8H0+/ALO2kPocRvA/j/UpvRX5EMAXQIkvLP+uViTlk4FA3tna0IHDC tFmbI6OQDSfQFug6z1dY4SsYMAbcpYhyd3Jj+bAvIEsXCY7vcRB2HDQNXe6qW+jicyr6n0EF NA1Cg1T8StHPHVaGqo4ZO8yfQ82G5Xbp7oNePJzP/YHb933fDaModrNoGLuzYBDOo1kcZPPZ A3ocKBhlDtXV7KoXtDq6MlNGMYhfu3Vm7PsjWBwDc4cTSPl/TbG96cQDNvlCQ0Bpd3qnyhTd Z1kcBdNh5mZ+uHDDWXzqThbRwF0M+mE4zYaTaX/+ADVLP0yIolanzvNWL8H4SuOqkiihxcac EFF5jVh6UtxRJUVp9dLvtaK7xyxFwTCKTuPo1A4AlAtF2lXrigVTJ4OEqe9YXu5hF3EC6g7t nVqTBD1vF+XpSd3seuPGvwEAAP//AwBQSwMEFAAGAAgAAAAhAMkTYse+AgAAXAYAAB8AAABw cHQvbm90ZXNTbGlkZXMvbm90ZXNTbGlkZTcueG1srFRdT9swFH2ftP8Q+T2kSdPQRE1R048J iZWKwg8wjttEc2zPdks7xH/fjZMAAzbQxEvr2PfrnHPvHZ0dKubsqdKl4CnyT3rIoZyIvOTb FN1cL9whcrTBPMdMcJqiI9XobPz1y0gmXBiqHfDnOsEpKoyRiedpUtAK6xMhKYe3jVAVNvCp tl6u8B3ErZgX9HqRV+GSo9ZffcRfbDYloTNBdhXlpgmiKMMGatdFKXUXTX4kmlRUQxjr/UdJ Y8BG1iyv/7W8VpTWJ77/puRarpR9Xu5XyilzYAw5HFdADPLah9bMfnIwg4P3wn3bRcLJYaOq 8QgngM05pAjoP9a/4IQTejAOaS7J0y0pLt+wJcX8DWuvSwAVPCatUTWIXsMJOjhrVubUOa/w ljorhgktBMupcvxHnI0zhmAXgvzQDheAvCFEXAnTnqYF5ls60ZISe9WwQZb7LndNUV2NLBxz lECkZvl5ta3TWNrqV3voHDRo0Dw2MP4Opt+BWdpOfQ4jeB/G+5XeivyIoAtAIkvLP+uViTlk 4FALWztaEDhh2qzNkVHIhhOQBVTn+QorfAUNxoC7FFHuTm4sH9YCsnSR4PgeB2HHQSPoclfd gorPqeh/BhUgGoSGVfErRT93WBmqOmZsM38ONRuW26G7D3rxcD73B27f9303jKLYzaJh7M6C QTiPZnGQzWcP6LGhoJU5VFezq17Q6ujKTBnFsPzaqTPj0xHMjYG2wwlk/D9NrDTd7oBBvtAQ UNqR3qkyRfdZFkfBdJi5mR8u3HAWn7qTRTRwF4N+GE6z4WTanz9AydIPE6KoXVPnebsu4fLV iqtKooQWG3NCROU1u9KT4o4qKUq7Lv1eu3P3mEHL+vFpHA2GtrNsZXbQuloBQLcECVPfsbzc wyTiBHY7iDu1VxK2eTsmTya11PW8jX8DAAD//wMAUEsDBBQABgAIAAAAIQCwfGERwAIAAF4G AAAfAAAAcHB0L25vdGVzU2xpZGVzL25vdGVzU2xpZGU2LnhtbKxUXU/bMBR9n7T/EPk9pEnT 0ERNUdOPCYmVisIPMI7bRHNsz3ZLO8R/342TAAM20MRL69j365xz7x2dHSrm7KnSpeAp8k96 yKGciLzk2xTdXC/cIXK0wTzHTHCaoiPV6Gz89ctIJlwYqh3w5zrBKSqMkYnnaVLQCusTISmH t41QFTbwqbZervAdxK2YF/R6kVfhkqPWX33EX2w2JaEzQXYV5aYJoijDBmrXRSl1F01+JJpU VEMY6/1HSWPARtYsr/+1vFaU1ie+/6bkWq6UfV7uV8opc2AMORxXQAzy2ofWzH5yMIOD98J9 20XCyWGjqvEIJ4DNOaQI6D/Wv+CEE3owDmkuydMtKS7fsCXF/A1rr0sAFTwmrVE1iF7DCTo4 a1bm1Dmv8JY6K4YJLQTLqXL8R5yNM4ZgF4L80A4XgLwhRFwJ056mBeZbOtGSEnvVsEGW+y53 TVFdjSwcc5RApGb5ebWt01ja6ld76Bw0aNA8NjD+DqbfgVnaTn0OI3gfxvuV3or8iKALQCJL yz/rlYk5ZOBQC1s7WhA4YdqszZFRyIYTkAVU5/kKK3wFDcaAuxRR7k5uLB/WArJ0keD4Hgdh x0Ej6HJX3YKKz6nofwYVIBqEhlXxK0U/d1gZqjpmbDN/DjUbltuhuw968XA+9wdu3/d9N4yi 2M2iYezOgkE4j2ZxkM1nD+ixoaCVOVRXs6te0OroykwZxbD82qkz42gEc2Og7XACGf9PEytN tztgkC80BJR2pHeqTNF9lsVRMB1mbuaHCzecxafuZBEN3MWgH4bTbDiZ9ucPULL0w4QoatfU ed6uS7h8teKqkiihxcacEFF5za70pLijSorSrku/1+7cPWbQssPTOB6GQXxqe8vWZketqxYg dGuQMPUdy8s9zCJOYLuDvFN7JWGft4PyZFKLXU/c+DcAAAD//wMAUEsDBBQABgAIAAAAIQC5 f+5zlgYAALAbAAAUAAAAcHB0L3RoZW1lL3RoZW1lMS54bWzsWU9v2zYUvw/YdyB0b2MndhoH dYrYsZutTRvEboceaYmWWFOiQNJJfRva44ABw7phlwG77TBsK9ACu3SfJluHrQP6FfZISrIY y0jSBtuwxYdEIn98/9/jI3X9xqOYoUMiJOVJ26tfrXmIJD4PaBK2vXvD/pUND0mFkwAznpC2 NyPSu7H1/nvX8aaKSEwQrE/kJm57kVLp5sqK9GEYy6s8JQnMjbmIsYJXEa4EAh8B3ZitrNZq 6ysxpomHEhwD2bvjMfUJGmqS3lZOvMfgNVFSD/hMDDRp4qww2GBS1wg5k10m0CFmbQ/4BPxo SB4pDzEsFUy0vZr5eStb11fwZraIqSVrS+v65petyxYEk1XDU4Sjgmm932hd2ynoGwBTi7he r9ft1Qt6BoB9HzS1spRpNvob9U5OswSyj4u0u7VmreHiS/TXFmRudTqdZiuTxRI1IPvYWMBv 1NYb26sO3oAsvrmAb3S2u911B29AFr++gO9fa603XLwBRYwmkwW0dmi/n1EvIGPOdivhGwDf qGXwOQqioYguzWLME7Us1mL8kIs+ADSQYUUTpGYpGWMforiLGR0JqhngTYJLM3bIlwtDmheS vqCpansfphgyYk7vzcvv37x8jt68fHb8+MXx45+Onzw5fvyjpeUs3MVJWF74+tvP/vz6Y/TH 829eP/2iGi/L+F9/+OSXnz+vBkIGzSV69eWz3148e/XVp79/97QCvi3wqAwf0phIdIccoQMe g27GMK7kZCTOt2IYYVpesZ2EEidYc6mg31ORg74zwwxX4DrEteB9ARWkCnhz+tAReBCJqcpc 7mh2K4od4B7nrMNFpRVuaV4lMw+nSVjNXEzLuAOMD6t4d3Hi+Lc3TaF00iqS3Yg4Yu4znCgc koQopOf4hJAKez2g1LHrHvUFl3ys0AOKOphWmmRIR040zRft0hj8MqsSEPzt2GbvPupwVqX1 Djl0kZAVmFUIPyTMMeNNPFU4riI5xDErG/w2VlGVkIOZ8Mu4nlTg6ZAwjnoBkbJqzV0B+pac fguqR7Xb99gsdpFC0UkVzduY8zJyh0+6EY7TKuyAJlEZ+4GcQIhitM9VFXyPuxmi38EPOFnq 7vuUOO4+vRrco6Ej0jxA9MxUVPjyJuFO/A5mbIyJKTVQ151yHdPksnafuXZvC1qZPLsnKvYy 3Mk63eUioP/+Mr2Dp8k+gcxY3Ksuq/Rllfb+81V6WT5ffG2el2Oo1Lp3sk23acHjpR34mDI2 UDNGbkvThEvYhII+DOp15vRJihNZGsGjzmRg4OBCgc0aJLj6iKpoEOEUGvi6p4mEMiMdSpRy CQdHM1xJW+PhEKDssbOpDyS2ckis9nhgh9f0cH7uKMgYqUJzuM0ZrWkCZ2W2di0jCrq9DbO6 FurM3OpGNFMUHW6FytrE5oAOJi9Ug8HCmtDdIOiJwMrrcP7XrOHggxkJtN2tj3K3GC9cpItk hAOS+UjrveijunFSHisLimg9bDDoQ+QpVitxa2my78DtLE4qs2ssYZd77128lEfw3EtA7WQ6 sqScnCxBR22v1VxtesjHadsbw5kZHuMUvC51Q4lZCBdPvhI27E9NZpPlc2+2csXcJKjDNYi1 +4LCTh1IhVQ7WEY2NMxUFgIs0Zys/KtNMOtFKVBRjc4mxdoGBMM/JgXY0XUtGY+Jr8rOLo1o 29nXrJTyqSJiEAVHaMSm4gCD+3Wogj4BlXD1YSqCfoF7Om1tM+UW5yzpyrdjBmfHMUsjnJVb naJ5Jlu4KUiFDOatJB7oVim7Ue78qpiUvyBVymH8P1NF7ydwDbEWaA/4cE0sMNKZ0va4UBGH KpRG1O8LaBxM7YBogbtemIaggstq81+QQ/3f5pylYdIaTpPqgIZIUNiPVCQI2YeyZKLvFGL1 bO+yJFlGyERUSVyZWrFH5JCwoa6B63pv91AEoW6qSVYGDO5k/LnvWQaNQt3klPPNqWTF3mtz 4O/ufGwyg1JuHTYNTW7/QsSiPZjvqna9WZ7vvWVF9MS8zWrkWQHMSltBK0v7txThnFutrVgL Gq82c+HAi4saw2DREKVwmYT0H9j/qPCZ/fKhN9QhP4DaiuBDhiYGYQNRfcU2HkgXSDs4gsbJ Dtpg0qSsabPWSVst36wvuNMt+J4wtpbsLP4+p7GL5sxl5+TiRRo7s7Bjazu21NTg2ZMpCkPj /CBjHGM+mZW/avHRQ3D0Dnw/mDIlTTDBNyuBoYcemDyA5LcczdKtvwAAAP//AwBQSwMEFAAG AAgAAAAhAGkJ4g1kBgAAzh0AACEAAABwcHQvbm90ZXNNYXN0ZXJzL25vdGVzTWFzdGVyMS54 bWzsWeluGzcQ/l+g77DY/iw20h5arQTLgc7EgJMYsfMA1C4lLcQ9SlKOnCBAXit9nDxJZ3jo sJ1GTtygbYQAMpfHkPPxm4OTk6frgjnXlIu8Knuu/6TpOrRMqywv5z33zdXES1xHSFJmhFUl 7bk3VLhPT3/95aTulpWk4gURknIHpJSiS3ruQsq622iIdEELIp5UNS1hbFbxgkj45PNGxslb kF6wRtBsxo2C5KVr1vND1lezWZ7SUZWuClpKLYRTRiRoIBZ5Lay0+hBpNacCxKjVe0c6BQ3T S5bh3+lc/76mMyfP1oBTs+m7pyekq/SkQ8ada8J67nTuu43TkwYugcmmhYtFfcUpxVZ5/YzX l/UFx4/05fUFB5kg0nVKUgDCKEANmGnqs4RpWvDe8rmVRLrrGS/wRACPAyeEe7zBX1hEunQt nVR3ptvedPHqnrnpYnzP7IbdAFTbbIpaaY3uqhNYdZ5TkgFBLhhJ6aJi2FYYKRX1OoCxPq/S pXDKCpRGLLSugI6VjADgXvXCkTc1wLTIODDzXc/9Y0U4UNAs0fPglOVmqVBYWwX+HqGg0/aT JoCHOEWtNlBUCd6urrmQz2hVONjouZymUjGBXJ8LiccmXTtFXb/eve7K9aDKbvA2pvAXLh2M DtYvKv7OddhZKXpux48i2FqqD7W56/DdkeneiGTDCjhn7pgJeSlvGFCMdNk180Fph7A5GDVT 58vo7DV0IWL+ViszUx17VwLcK9CmzC4IJ7iMEfQHtPT6bwweMANQtlpBU3Phy4wILSNGRNI9 PgQo8nv5kEnX2OaDmRAmSRT7cL6tbViL+T/ygX8rH2YsU67qfb81bE7GSeQNx8OBF/mjxOv7 g5EXxH408fuDZr/T+gBEVoaawXXLvKCTfL7i9NVKmwu/RSpHFHLIKAG+GkLL09BvNNvg4P0A rUoqksIZHp+akaXmJcsz6pwVZL7P0PDrDAXf9boCg0Y/Xg0XYC+0L2rwDoe5M8Gys2JuKKwM QvkwdHqqYf3gF5yZ70dhE/0WUDhOWujC9jy/dmXGr4VR0MHJ2lvZwGG91kGOjUD0n+SMqU1Y 6bxFr9IGmXg5ogIYcRQ/UOw2PkIUWJp9d2bB7bJSKfoDvKVDyhS8bs9NpQoasLdxnUqZf8Dz tSy9XmLGtOf6oq8TC29pxzliZLsVCjGg7MdC7QkVax9EI0MdZFEUwr/bNGpFSYydOjwC6QzR NunBNvgdRCM43A+4cU3SO5eMERLi38bhgKmR7p5fenMJsN71S0OWp0tHVg7NcumYDFhiyBAY gcXWW6H1AiTKDtSP3VJlOLDboVte0rQqM4fRa8oOEK8cyAPEXy1yfrh0xasHSJ9UKy4XBx9e 2cRDxOeze6U/dgITWzOeVGDH+ylt6zHseAYOaS+l1Was8HiQGes4kIA1B5DWKPr/pxOajcue amWsw0br+Vfmum1LFZ1QvFwV01uEiR+DMJA0gOj7OKP4+CDO7CbBPyNzvj8rDpqdZDz2W17o +74XxXHHG8RJxxsFrWgcjzrBYDzaZMUCM80SLu9OBIAX1n1B5/PHT799/vjn1vl/cyasgq6t RoBfOBeQWteqSLDiec99Pxh04mCYDLwBpPNeNOq0vf4kbnmTVhhFw0HSH4bjD3Dw2o+6Kaeq dnKWmRoOdN6puxR5yitRzeSTtCoauoDTqKu3lNdVrmo4ftMUglQZxYf9w04n9K3rg1OqLMie FlSwtZmU8RekdqDyAi9dCdm3XEMrW0JrOg+wD0oRcg2tbAktkqZQ7oEZpmF7YFz3bOaEtgce hnoIFDMN29OyPZDi6aHY9kC0WLC8XAIY+Md1ZhV7rjtsS7sAVUa783QvCD/HzGTzhnfgAX9F ppfwfld1AhjiUiUvDiXn5YDDTqAz1sFK8wlT8B0CxbaLVakfIsi225UAZ0k51v6wKoDjO4n5 nQIXgIunhqRmb5baVb33ZlDm6bm/F6XHpHbWlNwaoEQPpOLWQCqMbH1Ctc2mQKE8fYA5m4bG FGeO+DAExUTCcIuPJYmtAf28/EFQDD7RFh8/bPsxPmWOACEqBqDWDkBJkKhS6BEgRMUAFG8B CoIECHRkELhoRMUA1N4BqB2FGFSOJsYQFQNQsgUI0VHllKOJISoGoM4OQHGrfXTSKvVBVFQO vJsv4gtv+7+wp38BAAD//wMAUEsDBBQABgAIAAAAIQC0z1gZuwAAACQBAAAsAAAAcHB0L25v dGVzTWFzdGVycy9fcmVscy9ub3Rlc01hc3RlcjEueG1sLnJlbHOEj8EKwjAQRO+C/xD2btL2 ICJNehGhV6kfENJtGmyTkESxf2+gFwuCl4WZZd/M1s17nsgLQzTOcihpAQStcr2xmsO9ux5O QGKStpeTs8hhwQiN2O/qG04y5aM4Gh9JptjIYUzJnxmLasRZRuo82rwZXJhlyjJo5qV6SI2s KoojC98MEBsmaXsOoe1LIN3ic/J/thsGo/Di1HNGm35EsJR7YQbKoDFxoHR11lnR3BWYqNnm N/EBAAD//wMAUEsDBBQABgAIAAAAIQC5f+5zlgYAALAbAAAUAAAAcHB0L3RoZW1lL3RoZW1l Mi54bWzsWU9v2zYUvw/YdyB0b2MndhoHdYrYsZutTRvEboceaYmWWFOiQNJJfRva44ABw7ph lwG77TBsK9ACu3SfJluHrQP6FfZISrIYy0jSBtuwxYdEIn98/9/jI3X9xqOYoUMiJOVJ26tf rXmIJD4PaBK2vXvD/pUND0mFkwAznpC2NyPSu7H1/nvX8aaKSEwQrE/kJm57kVLp5sqK9GEY y6s8JQnMjbmIsYJXEa4EAh8B3ZitrNZq6ysxpomHEhwD2bvjMfUJGmqS3lZOvMfgNVFSD/hM DDRp4qww2GBS1wg5k10m0CFmbQ/4BPxoSB4pDzEsFUy0vZr5eStb11fwZraIqSVrS+v65pet yxYEk1XDU4Sjgmm932hd2ynoGwBTi7her9ft1Qt6BoB9HzS1spRpNvob9U5OswSyj4u0u7Vm reHiS/TXFmRudTqdZiuTxRI1IPvYWMBv1NYb26sO3oAsvrmAb3S2u911B29AFr++gO9fa603 XLwBRYwmkwW0dmi/n1EvIGPOdivhGwDfqGXwOQqioYguzWLME7Us1mL8kIs+ADSQYUUTpGYp GWMforiLGR0JqhngTYJLM3bIlwtDmheSvqCpansfphgyYk7vzcvv37x8jt68fHb8+MXx45+O nzw5fvyjpeUs3MVJWF74+tvP/vz6Y/TH829eP/2iGi/L+F9/+OSXnz+vBkIGzSV69eWz3148 e/XVp79/97QCvi3wqAwf0phIdIccoQMeg27GMK7kZCTOt2IYYVpesZ2EEidYc6mg31ORg74z wwxX4DrEteB9ARWkCnhz+tAReBCJqcpc7mh2K4od4B7nrMNFpRVuaV4lMw+nSVjNXEzLuAOM D6t4d3Hi+Lc3TaF00iqS3Yg4Yu4znCgckoQopOf4hJAKez2g1LHrHvUFl3ys0AOKOphWmmRI R040zRft0hj8MqsSEPzt2GbvPupwVqX1Djl0kZAVmFUIPyTMMeNNPFU4riI5xDErG/w2VlGV kIOZ8Mu4nlTg6ZAwjnoBkbJqzV0B+pacfguqR7Xb99gsdpFC0UkVzduY8zJyh0+6EY7TKuyA JlEZ+4GcQIhitM9VFXyPuxmi38EPOFnq7vuUOO4+vRrco6Ej0jxA9MxUVPjyJuFO/A5mbIyJ KTVQ151yHdPksnafuXZvC1qZPLsnKvYy3Mk63eUioP/+Mr2Dp8k+gcxY3Ksuq/Rllfb+81V6 WT5ffG2el2Oo1Lp3sk23acHjpR34mDI2UDNGbkvThEvYhII+DOp15vRJihNZGsGjzmRg4OBC gc0aJLj6iKpoEOEUGvi6p4mEMiMdSpRyCQdHM1xJW+PhEKDssbOpDyS2ckis9nhgh9f0cH7u KMgYqUJzuM0ZrWkCZ2W2di0jCrq9DbO6FurM3OpGNFMUHW6FytrE5oAOJi9Ug8HCmtDdIOiJ wMrrcP7XrOHggxkJtN2tj3K3GC9cpItkhAOS+UjrveijunFSHisLimg9bDDoQ+QpVitxa2my 78DtLE4qs2ssYZd77128lEfw3EtA7WQ6sqScnCxBR22v1VxtesjHadsbw5kZHuMUvC51Q4lZ CBdPvhI27E9NZpPlc2+2csXcJKjDNYi1+4LCTh1IhVQ7WEY2NMxUFgIs0Zys/KtNMOtFKVBR jc4mxdoGBMM/JgXY0XUtGY+Jr8rOLo1o29nXrJTyqSJiEAVHaMSm4gCD+3Wogj4BlXD1YSqC foF7Om1tM+UW5yzpyrdjBmfHMUsjnJVbnaJ5Jlu4KUiFDOatJB7oVim7Ue78qpiUvyBVymH8 P1NF7ydwDbEWaA/4cE0sMNKZ0va4UBGHKpRG1O8LaBxM7YBogbtemIaggstq81+QQ/3f5pyl YdIaTpPqgIZIUNiPVCQI2YeyZKLvFGL1bO+yJFlGyERUSVyZWrFH5JCwoa6B63pv91AEoW6q SVYGDO5k/LnvWQaNQt3klPPNqWTF3mtz4O/ufGwyg1JuHTYNTW7/QsSiPZjvqna9WZ7vvWVF 9MS8zWrkWQHMSltBK0v7txThnFutrVgLGq82c+HAi4saw2DREKVwmYT0H9j/qPCZ/fKhN9Qh P4DaiuBDhiYGYQNRfcU2HkgXSDs4gsbJDtpg0qSsabPWSVst36wvuNMt+J4wtpbsLP4+p7GL 5sxl5+TiRRo7s7Bjazu21NTg2ZMpCkPj/CBjHGM+mZW/avHRQ3D0Dnw/mDIlTTDBNyuBoYce mDyA5LcczdKtvwAAAP//AwBQSwMECgAAAAAAAAAhABqRE9AAgAAAAIAAABcAAABkb2NQcm9w cy90aHVtYm5haWwuanBlZ//Y/+AAEEpGSUYAAQEBAGAAYAAA/9sAQwABAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB/9sA QwEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEB/8AAEQgAwAEAAwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAAAAAB AgMEBQYHCAkKC//EALUQAAIBAwMCBAMFBQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGh CCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkqNDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVm Z2hpanN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfI ycrS09TV1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5+v/EAB8BAAMBAQEBAQEBAQEAAAAAAAAB AgMEBQYHCAkKC//EALURAAIBAgQEAwQHBQQEAAECdwABAgMRBAUhMQYSQVEHYXETIjKBCBRC kaGxwQkjM1LwFWJy0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2Rl ZmdoaWpzdHV2d3h5eoKDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXG x8jJytLT1NXW19jZ2uLj5OXm5+jp6vLz9PX29/j5+v/aAAwDAQACEQMRAD8A/v4ooooAKKKK ACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAo oooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK ACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAo oooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACivwBt/+C13xBtPiFrc3ib9kzwBpX7P Gjf8FUr7/glIPiBpX7U+ta18dNT+Kr+Jn8MeH/iPpH7Pt5+zHoHhTVfBt9PNp2pa5omm/tBX ni/QtI/ty+sdK8RR6IP7Q/Srw9/wUP8A2PvFXx9vP2Z9C+LVxefFW18beMPhhCZPhv8AFmx+ GGt/FX4e+H7fxT4++EfhL496h4FtfgN40+LvgnQJ5NR8W/Crwj8Stb+IPhyPTddi1fw3Z3Ph 3XodOmlKNbC0cbTlF4evRWIpyk1Cf1d5VkeduvOhNxr0qEcr4lyHFzq1acKcIZnhoTlGq5U4 1iIywtfE4eunTqYOpVo4hv3qNOrRzHOMpq0/rMebDznDMeH85wzjTqybll+Imk6SjUl9qUV+ ePwJ/wCCrH7Bf7SvjP4XeBPgx8b77xTrHxt03xhqHwf1XUPg/wDHTwV4D+Jlz8PLD+1fiB4X 8EfFHx58M/DHw08R/ELwJpqzX3jT4ZaX4tuPiJ4VtbTUJte8L6emnX5t9T4X/wDBT/8AYf8A jJ8RvD/wv+Hnxi1TV9e8bSfFCL4Y+I9R+D3xy8KfCP41TfBe4uoPifD8Afjz4v8AhroPwP8A 2gJvCKWGo6hew/Bf4h+O5brRNL1XxBpiX2h6Xf6hbuTUE5TailQrYpuT5UsNh1VeIxDbslQo KhXdar/DpKjVc5RVOfK5U5xlUjKE4ypVIUasZRalTq1FVdOlUTV4VKioV3CErSkqNXlT9nO3 31RX4b/HD/gvV+yd4L+Fv7P3xj+AHhr4w/tQ/Dv46/tNfBb9n6Pxp4O/Z/8A2s9A8F6dpvxU 1O5sNd8T+DfF4/Zo8TaH8W/HngJrWbT7j4D+CrmX4ka54yttR+HccGleNdK1DRrf9PfjN+1f 8Cf2e/hX4U+Mfxh8V634M8JePNb8D+FPAujz/Dj4nax8VvG3jb4kPCng34eeD/gT4e8G6v8A G/xP8TNWEs00vw10P4eX/jzSLXTNevNa8Pada+HNem02uWXsqlZpwp0syp5RUdROnKOY1sJl uNw+F5KnLOUsVhs3y+WEnGLpYupWlQw06uIw+JpUZaarU8Pa9erhKuOhSj783haGKxuCxFVq PNyvDYnL8XTxNOVquGVONSvCnSrUJ1fouivz7f8A4KmfsKW/wx0P4uX/AMar/SPCev8A7QF1 +ynb6Zr3wh+OPh/4l6T+0lbaVretr8EPF/wX1v4a2Hxj8B/ErUdN0C7n0Hwt428CeH9T8RyX /hm10CHUrvxj4Sg1v2/4L/tc/An9oX4XeOfi98Idf8X+KPC/w08ReOPBvj7RLz4QfGTwj8Vf CPjf4cwrceLvAuvfAzxp4A8PfGzTvHGnwyWslp4Nn+Hy+JtcS/0ttA0rVBqunfaonONOnias 3ang8P8AW8VOzaw+F9jgMT9YrWTdOi8PmmWV41JJRlSzLAVItxxmGdQcZKdCDTU8TWlh8NFq 0sRiI1sdh5UKKdnVqxr5ZmVGVOHNONXL8dTaU8JiFT+laK/m+0T/AIL2/wDCy/2Wv2MP2ofC nwb1L4SaP8b/APgoZ4W/ZL+NXhr4o/DT9oLxTaaL8NtV1n4/aNNrvwO8aH4d/B6z+LvxK1cf CHRZodF+Hmg/EyTwV4p8QXPwp8S+FNQ8fJaWbfqhB/wUx/Yvufg1P8dY/ih4oTwdB8bG/ZsP hi5+Bf7QVp8dJ/2g1vksT8E7H9mO7+FkP7SWo/FLDHVR4HsPhRc+Ij4ZhuvFo08+F7O61iHR RbVdu0ZYfGxwNWk5R9rGrUw/D+IoVPZpuX1fFPifJcNhazShiMbjKeEpc1aUITVReyrRoS1l OliKsZw9+jJ4TH8Q5di6MK0b0qtbC1uFs6rV4UpTUMFhHjeZ4Z+0X3jRXgPw5/al/Z++K3wH n/ab8F/FDw/cfAvT9E8XeIPEHj/xCmp+BrLwZp/w+m1W1+IMXxC0nxzYeHPEXw61fwBeaFrd h478PeOtH8PeIPBuoaRqen+JdM0y9sbmCL58tP8AgqJ+xNdfCAfHCX4meNtI8FXnjD4d+AvD Wk+J/wBnf9pXwj8WviL4q+Ltpb6h8KtO+EPwB8U/CHR/jv8AGaH4labLd6r4E1X4UfDfxlo/ izSdB8X6roV/faf4K8XXOiJpqdWm01Oi8Gq0GrTpPMK7wuAVWL1pvHYlPD4PmS+s106NHnqL lCKc1TlFc0a0sTClKOqqzwdP22MhTaupywtH97iYxu6FP36qjHU/QGivzvu/+CrX7B1h8OPD 3xSv/jRrVh4f8T/HjV/2XdN8PX/wR/aAsvizbftH6LouseIJ/gX4i+BFz8LIvjd4Q+KupaXo k8nhjwN4s+Hui+IfGV1qfhbTPCVhrep+NPB9nrj/AINf8FWP2DPj941+G/w9+FvxvvtZ8VfF rUPH/h/wJaa58H/jp4C03U/HPwr/ALVk+I3wo1PxJ8QPhn4X8NeFfjd4NsNGvNe174GeLdX0 P4wWPhaXSvFsngj/AIRnXdE1bUE/djOb0hSUZVJPSNOM8JhsfFzk9IKWBxuDxsXJpSwmLw2I V6NelOam1TSlUapxftbOb5U/Y4jE4StZysn7LFYPGYarb+HiMJiaMrVKFWMP0Nor87vgd/wV d/YH/aP8X/DLwV8Hvjnd+JNT+NGleMtU+Emtar8Ifjl4G+H3xIl+HOnHV/iH4b8GfFTx/wDD Twv8MfEHj/wDpaT6h43+Gmm+Lp/iF4StLLUZ9f8ADGnx6bftbWtP/wCCpv7DOoP8XI5Pi94i 0P8A4Up8EvEX7Svi+Txj8C/2hPAsGu/s9eFby6sdb+N/weufGfwq0G3/AGhfhVBcWqi08d/A KX4l+G9Xh1DQ7rR9Rv7XxFoM2pTOUaacqkowisPiMU3NqKWFwlHFYjF4luVksPhqGCxlbEVv 4dGjhMVUqSjChVlDX2VV1HRVKo6yr0MM6XJL2ixOKxFPCYbDuFuZV8Ri6tLC0KVvaVsRVp0a cZVJxi/0Hor8ibr/AIKr/BbVPjP8Kdb8N/Gz4ReH/wBj7X/2bf2m/jr4w8X/ABU+E37Vnw/+ Jfi7R/gO/wALtRPxV+B/iXxV8LfDfwa8Ufs+aR4c8cy3er+ODrmsn4k3ur6AnwaufEkGi+KG i+iX/wCClX7HNt8HP+F6ap8QvHHh3wZN8RfCHwj0jw74t/Z7/aO8H/GzxX8TPiFY6Rq3gHwT 4D/Zs8UfCXSP2iviDr/jfQtbsfEvhGy8EfC3xA3iTwrHqnirRje+HdC1vU9OtxkknOMqc7xU 6VSLhWpOrm+OyLC+1ptXh9dzPLsVhcFf/ea1OVCnfEQqUYYxlGVR04NVHzOEJQalCtKGWYLN 68aLV/aPC4DH4aviklehTqKrNKjKnVn920V+fb/8FTP2FLf4Y6H8XL/41X+keE9f/aAuv2U7 fTNe+EPxx8P/ABL0n9pK20rW9bX4IeL/AIL638NbD4x+A/iVqOm6Bdz6D4W8beBPD+p+I5L/ AMM2ugQ6ld+MfCUGt/Q/7Ov7TvwV/as8G6746+CHibWdf0bwp458TfDLxhpviv4ffEf4T+OP BXxC8HTW8PiXwZ43+Gfxd8JeBfiP4L8R6V9rsp5tK8UeFdJupbG+sdRto57C9tbmZxjKbqqE ZTdGnCtWUU5OlRqU8vrQq1Uk3Tpzo5tldWFSVoyp5ll803HGYZ1HNqn7L2jVP21SdKjzvk9r Vp1cdRqUqXNb2lSnWyvM6U4RvKNXLsdTklPCYhU/faK+C73/AIKbfsS2Hxmb4E3Pxf1T/hMY /jPa/s4z+KLf4QfG+9+BNt+0Le6XFqtv8Cbv9p+z+G1x+zXZ/GNxPDo7/DO6+LMXjSHxdKng ebRY/GTDQa+b/wDgnt/wUa8aftl+LP29fGXiDQ9U8M/BT9mf45/EL4SfDXwJa/seftYeE/iz daB8Ko1tdb8VeKPHvjUSaJ8SviF4r1Oy1l1/Zx+G3wd0D4xfCqBfD2k+O9K1DXfFGj2tzlTq QqRqVYyX1ajlOLzqpjPiwscvwcsrjUqqtHmVSU1nWW1KUKSnKWGxH1x8uEp1a8NK1OpQUfaQ mqs8xwOVxw/K1iPreYwzWeGjKk0nThNZJmcFUqckZYjCywlL2mLnToT/AGEor+b7RP8Agvb/ AMLL/Za/Yw/ah8KfBvUvhJo/xv8A+Chnhb9kv41eGvij8NP2gvFNpovw21XWfj9o02u/A7xo fh38HrP4u/ErVx8IdFmh0X4eaD8TJPBXinxBc/CnxL4U1Dx8lpZt+qEH/BTH9i+5+DU/x1j+ KHihPB0Hxsb9mw+GLn4F/tBWnx0n/aDW+SxPwTsf2Y7v4WQ/tJaj8UsMdVHgew+FFz4iPhmG 68WjTz4Xs7rWIdVFtV27Rlh8bHA1aTlH2satTD8P4ihU9mm5fV8U+J8lw2FrNKGIxuMp4Slz VpQhOKi9lWjQlrKdLEVYzh79GTwmP4hy7F0YVo3pVa2FrcLZ1WrwpSmoYLCPG8zwz9ovvGiv IvgX8ePhN+0r8MtA+MPwT8XweNfh/wCJJdWtLHVV0vXfD2p2OreH9WvfD/iTw34m8KeK9L0L xf4M8XeF9f03UdB8U+DvF+haH4p8M65YXuj69pGn6jaz20frtEoyhJxnGUJK14yTjJXSaumk 1dNNd001oyYyjNXjKMleSvFpq8ZOMldXV4yTjJbqSaeqYUUUVJQUUUUAFFB4BOCcDoMZPsMk DJ9yB6kV+X0X/BWX9neb9kjxL+1zF4G+Nz6V4S/aTn/ZG1n4IDw98P1+PsX7QEPx40/9n6P4 fQ+GX+Ji+CJtVu/E2rab4qs1HxEHneAb2DW9q6gW0VSH7ytDDU/fxFV0FTox1qT+s4/BZXQc YfE4zzHMsvwPOlyxxWOwdGbjPE0VNyXJT9tO0aXtXR9pJqMFUWDxuYSjKUmlFQwOW4/FzlJq EMPhK9Wcowpya/N/Sv8Agij8bPhx46+JH7VfwfuP2XfDn7ccf/BW74n/ALa3wt+Lk8vivTJf Fv7IPxe1T+xfHf7Mnxn8f6X8KLnxsI9d+H/iDxjcJ4T0/SvGPhDQfG39k3uieIoBf6rq8Pe/ svf8Eg/G3wB/aCu9Y+JfgbwT8fvhV4V/bE+Nv7W3wb+Mutf8FCv24fCXiv4Z6x8VLrxX4t0y 8P8AwT7tPAGufsfa58R/C2veNfFHgy/8d2nxI8Ov4x8LanL4t1bTbbxDPqGgX31F4F/4LTfs 5eLvirF8Ptf+D37Snwu8E6j+1d8Wv2I/Dn7Qvj/w98G5/gt4l/aY+D0WqXOu/DqzT4ffG/x7 8X9D/t+x0e/vfB/ibxp8JPC3hLWY4GtZtcsNTDWC9z+yp/wVo+Av7Wvxa+G3wq8H/C/49+A4 fjx8IviF8ef2bviR8SdG+FEfgD9oP4SfDPxppXgnxF4w8ERfD74wfEL4g+DopLvWtM1fTNE+ OXgH4R+JrzRbne+i2+qxT6THzUcOq+CwmGwE1y/2HHAZdWS9o8NhJcNcM5hgpQmpU6mExjyb grKeKcFSpVsHjcVSjmWdYdTw2Y4utNZhUVStms8c+WriMyr1cxh8Lni62fcUZbinUo2lDF4W Gc8X5vw9inXp4rA4evHBZPieSvl1ClT/ABN/4JO/sV/tFfte/sbf8EivEnxH1X4MeD/2Wv2U 7v8AaT+LXhvxH4F8WfEGb9oL4j6/4/Pxk+EmheA9Y8B6n4Ft/Anw90rwnJ408Va9qnxK0f4t +M9U8Wrpnh6w034deBZrvUNRsvs39n7/AIJW/tg+G/Cv/BOv9nP4y+Iv2a9P+AH/AATI8W/E nxv8Ovin8K/HPxQ1X4w/tHasngv4i/C34K6f43+FGsfB/wAC+CvgNp1t4R+JmpeJPizcaN8X fj/c+JPEeh22gaRDbaZr+p69Z/vrL8T/AIa2/wARbf4Pz/EPwND8Wrzwbd/Ea0+F0vi3QI/i LdfD2w1i38PX3ju38EvqC+Jp/Btlr95aaHd+KItMbRLbWLq30ya+S9nigb5D8Aft9/Cj4g/F z4waRpHjD9ni8/Zm+Ff7P/g348RftV+H/wBrj4D+LvD2sabrHij4jeG/G7698P8Aw94ivPEP w6+Hnw/k+Ht6svxj8Y6lZ+CPEmtQ+KfD2lyRXvgjW5T1YuVDF1cc1D2eHznHV82xClUvCrj8 ooZtiMFmeJxzjThHG5Lhstx1DC4iU8PRxmKy2FHGUMfmUYQnpP2kmq04KVXC4WOUQ5KbdSlg c/r06OJy3D4aPM3RzjEZvGvVhTpVK+GoV6dfBVcDl+CoSwv5paV/wSa/aZ8Mf8EpP+Cf/wCy Ro/iz4Fav+0t+wv+0x8Df2lrdNS8X+P9H+BnxG1L4Q/HjxR8SLrwZN8QbX4U6z4+8N2Wt+FP FE1tb+IU+EWsT2fiGzitZNDn02Z9ST7s/bw/ZO+On7SumfsVfF/4Wt8JtI/aJ/Y6/aP8CftI Wnwx+IPjfxhD8EfHsx8FeJfAHxM+G118UdE+F2v+K9BMOjeNdWv/AIffFQfA/WdRt9V0Owa9 +H+kxeIL19Fh/Z7/AOCpnwF/aG+Pn7bHw88M+JvhE3wC/Y4+G/wD+KE/7W+hfHnwb4t+D/j3 wv8AGPwz8QfEPiTVptd0+wtPBfg7QfhdL8PdT03XPEL/ABC8S6fdyC/mvz4cbSbi2l+tLP8A a9/ZN1H4JX/7TGn/ALUH7O9/+zhpVw1nqn7QFn8a/hrdfBLTbtNctvDD2t/8VoPEz+BLO4Tx Le2fh5oLjXo5V1y7ttJKi/nit31r1606tfFVJeyrVeIsHxy5OMYywmburk1KhjPZVFJUqGIr 8PZPSeFxdOdKVXBqnCEJYjFRr4wpQ/c4JQ9rGOSy4U9inKccZlmZZfXzGGCjVpSUqtf+z+Jc VXhVwVWGKpRzKSqzVbC4ZYT8c4f+CVH7Tniz4geG/wBobx/4s+BehfGLxx/wV3+CH/BQr4zf Dvwh4z+JHiL4YfD74P8AwL+C+u/Arw38Nfhf441z4Z+Hdf8Aih8TNQ8OReHvE2v+JvEnw3+D Xh/VtZ1TVdFhs9K03wvo9/r36K/sPfsp/EL9mnxn+3x4h8eaz4N1aw/an/bh+IP7S3w/i8I6 jrd/d6P4D8WfDL4S+C9P0nxims+HdBh0/wAXQ6n4D1i4vLDRZ/EOjR2FzpssGvXNxNdWtn9c /Cn4w/CT47+CNL+JnwP+KXw5+Mvw31ubULfRfiB8KfG/hn4ieCNXuNJv7jS9Vg0vxX4Q1PWN Bv5tM1O0utO1CK0v5Xsr+2uLS5WK4hkjXhfD37WX7LHi5vjMvhP9pf8AZ/8AE7fs5JqMn7Qq +HvjL8Otab4Dx6ONebV3+Mw03xHcn4XppY8K+JzqLeNxoa2I8Oa8bkxDR9Q+z5QUcFTxGGjT jQoLKa+BqYepzuOGyf6rwJgJRbrylWVHD4XgPhWh9axFSpV92tPEV6tbHzqSqcZYyccRJyrV Hj6VT2tNRtUzCeZcZY+ELUoqn7atj+NuIuWhTjHmc6FGnTSwkYn4mfBb/glJ+1r8O/gP+xd+ zXrmtfs6TeD/ANiT/gqbH+2J4Y+IWlfEn4l33iX4pfATUPH37R/jvU9O17wLefAvSdL8B/F7 S5PjD4c0ux8M6f458beDNbSz1u9uPHugNZWNprGB8Z/+CNP7RXjjXvid8SdA8efD678WJ/wV v8Wf8FA/hr4B0z9oH9or9nSw8bfCXxz8A/BnwJ13wH4u/aE+BPg2L4x/Af4q6fZaf4m17QPF Pww0b4h6XCFtNA1Ka/0rxTrY0f8AcvwD+15+yd8Vvhp41+M/wu/af/Z3+JPwe+Go1RviN8WP APxr+G3jH4aeAF0PSIfEGtN418d+HvEuo+F/Co0fQbi31vVDruq2A0/SJ4dSu/JspUmb5K/Z 7/4KmfAX9ob4+ftsfDzwz4m+ETfAL9jj4b/AP4oT/tb6F8efBvi34P8Aj3wv8Y/DPxB8Q+JN Wm13T7C08F+DtB+F0vw91PTdc8Qv8QvEun3cgv5r8+HG0m4tpZhGWHqT1ca1CnRzOvUrxhLl jTxHAeYwxuJVeDoOOJr+HPDmJaqw9jiY0sxVOlKjia0aelecsX9axVT95HEyxGGqulKcXOWa ZlxXgKtDD+wlGu6scd4oZvhl9Wbr4V4vA1JyprBqqcfZ/wDBN7TvEP8AwTK/aT/YctfBvhr9 l/xD+074Z+PsPi1/CH7Rvx6/bP0vS/iL8aH1RtQ+JWq/Gn9oTw78MPi98SNS8RahNY+JPGWn 6/o2jJLe3Gq6RDeanbyyarf+QfFD9jP9vz42fC/9iPxh4u0v9j7wj+0d+wB8f/g/8VPhx8Nv D3xj+NHiz4G/GrQPCXws1v4VfE6Pxv8AFrWv2d/D3i34V694t03xhqesfDy30X4A/FVvhpqH hayivvFPjdfG15c+Cf0+t/2w/wBke7+Cd1+0ta/tTfs5XP7ONjenTb34/wBv8b/hnN8E7PUV 1qHw2dPuvirH4nbwJb3o8RXNvoBtZteSca1cQ6WY/t0scDeVftf/APBQ79mP9i39kHVP23vi P40svGfwNi0rwjq/g7UfhZ4j+H3iLUPi5b+O57E+FIfhBea7428K+EPH1zrekXsnijTI9L8W BNS8Labqmt6bLeW1m2+pTdCrUxV/YOOL4McJS5pU8HjeGsXUxvCSpe3dRQ5HjKlPDYOs6mEx ODrQprDSp0cPKjFOh9bVHCxprEe3hxVQ5FaDxlDiajQwnEtKrKi6XN7VYejKvi4ShjMLiIyr vFU61avOr+aWhf8ABKv9pvXPjT4L/ai+Iviv4F6J8V/Fv/BVLwb+3j8avhv4L8ZfEjxJ8OfA Hwp+Gn7N/ib9m/wX8OfhZ411/wCGfhrWvij8RbrR28N+KvFfinxN8PPgxoepajqer6RZadZW PhbRrrxBX+B3/BJ79or4WeK/2Z/EniDxn8Fryx+Cf/BUH9vT9t3xVFo3iLxzcXeofCn9p/wj 8XtD8A+H/D8d78OdOhu/iFpF3490eTxhpWpT6T4b0+3ttSfRfFniCWG1hvP1g8Sft+fsL+Cv AHwz+Kvjn9sz9lPwN8NvjPZ6tffCTx54z/aI+D/hnwd8TLbw/Pa2niJ/AHijV/GVroPjMeHb 29tLHXm8M6jqkekXtzBa3zwzTRK+f+3H+3V8Bf8Agn3+zD4v/ax+O2q3tx8N/Cv9gQ2OleEL 7wZN4w8eap4m1C1s9I0H4d2PjHxf4L0HxRr11aT3Wux6XD4jt7ibw/pGsapai4jsJEPPiKCo YTE4Wny4Kko08kpcynUp4KrTp8FZbg8E3WqOpUq4b/UPhnDqGIrzxVaVDE/WK1StjKtUUY/2 s6Mo3xTzWhjMVSlDlpvGUMzlxnVxeKpcsYU1SnLj3iGbq04Ro0fa4ZJQjhIxf85//BJn9j39 q39qT9jv/gkN481fxT8DPhl8Bv2Pr/8AaQ+Nnwz8feFdT8a+Kfjn4v8AiF4xf4x/C3wP4X8T fCLxJ4HtPhr4a8PeA9X8X+IfFWu+MbX4u+Mbj4g2+jaDoVt8O/AY1LU9Ssum0b/giZ/wUK8V 3XxN8U/G34x/Cnxl8T/G/wDwTI/as/Yh1v4heM/2xP2v/wBoW6+Jfxh+NepeGtW8MfGh/D/x h+Etv4d/Zw8AapPa6vB4p+C/wT0+/wDC3gUWGmXnhmPxo2szWfhr9dLz/gsB+yRo/wC05YfC LxP8YP2ePCf7Puv/ALIPhT9qfwl+2H4l/aW+GejfCPxXf+KvjX4v+Ddt8L9D1LUHtvBOpajF c+DdX1ZNe0z4mX811dWep6FH4aSTSrnUT9y/Eb9qf9mL4PX/AMNtK+Lf7RvwH+FuqfGW4itf hBpvxG+L3w+8EX/xWuribSLaC2+G1n4m8Q6ZceObia48QaDbxQ+F49Ukkm1vSIkVn1KzWbpx lGnjquMxKozjDOMTxNgpU3Uc8RLG5phs84JzanN8sK8MxeX0MZlVSHs6CzOOUZZmuKwuOxGX 5bmFPSljnDEUa0J0/bYGjkGZUpRio0I4HDV8r47yurGKf1etgvrOYYTNI1v3ssthmWNynDV8 vwlfG5afk38Uf+CYXxs8aXn7Hd0YP2aPiFo37PX/AAS8+O37E/xJ+HXxb1L4kXHgT4n/ABA+ J/g74B+H7HTXXw14RttZX4T61/wqzxPpfiDxit3pHjbwra6zoniLRPAnia/tbnRI/AvCn/BJ n9uLwx4T+FXiyy+J3wwn8Ufssft4+AP2nv2R/wBkb4lftO/tGftD/A/4X/A/w/8ABU/BDxh+ z+37X3xb+Dt18dYIdX0/WNc8afDrUZ/gL4n0X4QanpmneGtA0PU7HxHrOu6d+2P7Vn7Xnw2/ Y/0j4Jaz8StD8ca7bfHr9pT4OfsteD4vAum6BqVxp3xB+N+uT6B4T1fxIviDxN4Yis/B2n3t u8niHUNMm1jWrS2KPpvh/VpS0K/M0X/BWX9neb9kjxL+1zF4G+Nz6V4S/aTn/ZG1n4IDw98P 1+PsX7QEPx40/wDZ+j+H0Phl/iYvgibVbvxNq2m+KrNR8RB53gG9g1vauoFtFXWniK2Lx1XG 0J82MqZvTp/uYx0zePHGVccUP3Di6eIq4fifi7JoYeWJp4ilg6HENHLaLoxzjFQxfH9SoYXB YXB1aaWEWCjQgq9Rr2mXVuDcx4NnSlX5ozw+HxHDvC2aSxdTD1MLOrXyaWY4iq55bgZ4b4sh /wCCVH7Tniz4geG/2hvH/iz4F6F8YvHH/BXf4If8FCvjN8O/CHjP4keIvhh8Pvg/8C/gvrvw K8N/DX4X+ONc+Gfh3X/ih8TNQ8OReHvE2v8AibxJ8N/g14f1bWdU1XRYbPStN8L6Pf69+i37 Dn7KvxC/Zn8a/t7eI/Hes+DNWsf2pf24viB+0x8P4vCWo65f3ej+BPFfwz+EvgzTtJ8YprPh 3QYdP8Ww6p4C1ie9sNEn8Q6NHYXOmywa9c3E11a2dLwn/wAFF/A3xL+L3jb4c/B74AftOfGb 4f8Aws+Mtp+z38Wf2l/hv4O+HWqfA34dfGVtS07RNe8F3tlqnxV0X47eN4fAOta1omnfEvxr 8I/gj8Rfhz8PV1C61fxb4w0rw94Y8aax4a3v2rf28/DX7LPxi/Zo/Z/g+Anx9/aE+MH7V6/G CT4U+DPgZ/woiykMPwP8O+HvFXjmbxJr/wAfvjt8CPCmjqmheI4LzSUi16/m1FrDULURQ3Ys IL/HCVI4ehQlg4cuFx2Bq5ZgacI1asZZa8n4Fr01hnN1MRVwsci4B4XxmFzCtOtHFZfTr5h9 bxMMdUxMuitCWKr1nWfNXw2IrYzFTk4UVTxeEzHjbMMZCu0qdGlicNmHGXEsMbgkqdbC1nQw dWhRqYWFJ/lv/wAOnP2sP+EN8YfsYjxN+z2n7GfjD/gpQ37eFz8eR4/+KA/als/BLfGvSP2n X+CqfBaD4RW3gK98ZSfFXRofAifHC+/aUm+zfD24PikfDG48Q2dp4YX9Nf8Agn/+yn8Qv2Vd F/a6034iaz4N1mX4+/t5/tRftReEH8F6jreox6b8Pvjb4m03WfCuj+JG1zw74daz8Y6faWcs fiDT9Lj1nRLS4aNNO8QatGWlX500H/gtL8D/AIh2X7IkHwR/Z0/at+Onjn9szT/2hbn4e/C3 wTpn7OXhPxr4L1b9lnWbfw/8bvC3xRvvjb+0l8Jfh/ofiDwnrD3tlAvhvxz4v0fX/wCyru60 DWNSsbnR7rVPSPhz/wAFYvgN48/b31n/AIJyax8Mfj18Lf2g9D8EaN4oub34h6H8L5PhrdeJ tU+FPgn40Xvwj03xl8Pvi14+bUPid4d8BeM5NT1e1t9Jfwbdf8Ih4wfw3408QWdlpN5rTwVL 2dClgcNGE6c8lxmWwjKUZfXcsy+lwvluKxNKcpKGIp4bDeH/AA/lrxeE/wBlnPAyv7XMcyxF fFLFtYivXrV04VaOZQzXE04xlCeEzFYrieVSniaTTqYWvLG8fZ7ia+AxChWw/wBai40cPgcu hTw/wf8ABb/glJ+1r8O/gP8AsXfs165rX7Ok3g/9iT/gqbH+2J4Y+IWlfEn4l33iX4pfATUP H37R/jvU9O17wLefAvSdL8B/F7S5PjD4c0ux8M6f458beDNbSz1u9uPHugNZWNprGB8Z/wDg jT+0V44174nfEnQPHnw+u/Fif8Fb/Fn/AAUD+GvgHTP2gf2iv2dLDxt8JfHPwD8GfAnXfAfi 79oT4E+DYvjH8B/irp9lp/ibXtA8U/DDRviHpcIW00DUpr/SvFOtjR/03/Y9/wCCnvwB/bc+ P37Un7PXwh8KfF7TPEH7KOr2Ol+LPGfjjw74R0n4e/EO2v8Axr8Q/h/D4g+E+qaJ478SeINf 8O/8JN8MPFdquo+JPDHhFrq3gtLywt7uC53x6/7TH/BSv9nT9lj9pP8AZk/ZP8c2XxO8T/GL 9qXx54K8DeE9P+H3gka14a8BL8RNQ8V6R4K8VfFjxhq+reHvDvhTQPE2r+BfGWn6Dp2n3+v+ ONcbwt4jvtG8HahpOgazqFjGGT9plnsG6mIzfFYF5dzRhVrY/H1cfwLXo2oVYSVTEVsf4a8P 1MVh6tFQg8PmkcRRpUa2IjS0xtRynntbGe6suo5nLO5qU6UMBh60eMsVjJVa1GUXQhGHiRnn sK1Oqp3xWWxoVJV6NDn739hX9m/Tf2XvgSPANt8I/C/wX1vxD4/+IHxL8b+EvCX7TPxz/a+0 3UPG/jvxFc6tr/jG8+Pn7Rvg/wAB/Fjxpr/jCTyNd8RyeIfC9gtlrd3fWtrPqkaHVr77Hrxr 9oL49/Df9mL4P+M/jj8WdQ1aw8DeB7bTHv08O+Hdb8YeJ9Y1XxBrmmeFvCnhbwp4T8NWOpa9 4m8WeL/Fmt6J4W8MaDpNjcXmq67rGn2caoJmlThf2Mf2sfh5+3N+zF8I/wBq/wCFGheOPDXw 9+M2h6jr/hnQviTpmh6N440200vxHrXhi5g8RaX4b8R+LtEs7w6hoV5JHFp/iPVI/sr27yTR ztLbw6ubxHtpQV4YCGXYWrGMpyhhIVcPXpZbhk6k5uEHhssrxw9FScaNDDKEY06SpReKjGi6 alpLG1cxxFOTjFOvVp18PXzCo3CMYyqRrZphp1qk/wB5VniVUqSq1ZVZn0/RRRWZYUUUUAFf zT67/wAE1v2q3/4K+nU9H8IaUn/BMTxf+018Pf8Agpx4w8TxeLfCFrqOmftk/Dj4IeMPhEvw 7tfBH/CQp45u7Lxl44b4ffGfXdcj8LSeF3n8OCxn1l9RlktI/wCliiij+4xuGx8NK+FtyN7S 9ni8FmeF5mrVF9SzrKsnzrD+znTvmGUYJYj2+CeKweJKv77BYvAT/gY2nKlVt8UYVqGIwOLV Ju8YSxmVY7M8nr1OV1I5dmuPhh50MTUpYmj/ADn/ALFP/BJr4n6R4i+P3xZ/aV1bx/Z+JvCH /BSH9s79rn9jr9n3xL4p+C2qfs56d4v+I93e2fwY/aZ8Qj4X+DtT+L+q+Jn0jWNTS38H+Pvi 3qWieFYZZdS/4VJpHimOzvx4P/wSR/4JrftS/ss/tc/CH40ar+z14g/Z3WT9mL4m/Df9vPWf HfiX9k3X/hd8bfi9rfxJufiJ4J1L9hn4ffs5+IvE2o/s/wDw1j8Z674m1zxP4Qbwh+zh4F1D wlY+C1v/AIU658Tx4k8VT/1UUUsCv7PqYKeH0+o5Nhclpxkk/a0MLw1V4UeJr1IqNeeLxWWS wzxrhVp4bFVsqyONXCvCZHlOFwixa+uxx8azf/CjnFfOq7iklHEVeIpcT08PShJSpQwmEzGt jVgoypzr4enmucVIYj67m2YYzEfgX/wWz/ZV/bm+I+q/s4ftJf8ABNrwHoPjb9p34f6F+0X+ zd4pt9V8b+F/h62l/A/9qb4Taj4X1Px++teLvFfhTSdWb4P+P9C8HeOdE8Nxzavqt1rxtbzT tHu4rTUBXwr+0r/wRl/aD0TTfjz8Lf2YfhPpPif4P+DP2GP+CX/wt+Eeh61478GeHtM/aJ8V fsY/tS+MfjR8Xfg7rEeqeLLTUPD+p/EPw21pdf8ACR+PrLRvAGreKfFNvBeeJLW3i1jUtE/r eopYSP1KthsRhpOFbCZvSznDzfLJU8RhcHneHwVCNKUXRWDweM4k4gzmFFU08Vm2cYyrmNTG 4R0cHRrEtYuDpVoJ055fLLq0IOdJ16NXM8mzDE1qlWnONf63iKPD+TZS8VTq06uFyvL8NSy6 WDxdNYw/kU/aO/4Jx/t5/tNeIv8AgrL8X/Bv7Neofs5/8NXat/wTE+KHwv8AhbrHxL/Zhvfi V8WP+GO/F/iXV/i18PPFk3h/xL8V/gZ4Y+KWuRaD4b1TwrN8QNU8e/BrW31HwPYeL/Fd5Yf8 J3ovg/1rxB/wTw/aDS6+GH7VXgj4PftvfFH4leDf+Cm/wh/bL/aD/Z2/bE+IH/BNfQfiJ8cr Lwb8ENS+B/8AwsT4J2n7IfjXwh+ydovjDwRY6z4c8T6fpnxL8afDnUfFmreB9YvtT1JdTPh2 bXv6ka+V/jH+138Nvgh+0N+yX+zT4r0TxxqHjr9snX/i34c+GOreHtN0G78JaFffBr4cXXxQ 8Ty+PL/UvEuk6xpdrf6BaSWegv4e0HxRNdawyW+oQaXZFtQXTDyeHqYaOFXsp08blOKwcYyn UdKvk2J4azChSoutKrKNCvLg3JPreG5vYVIYNOnClVjSq05rReJ+v1sRerCrlePpY/RUoSy+ PDmZ5PiqlWOHVHmnhsqx+ZVliZc2J9rWqynVqU7UT45/YD/Zq+PHg+X/AIKNfF34jeDtQ/Zo vf24v2k/E/xd+F/wNuPE3w/8S+Lvg1psPwj8G/COPxz461T4Tax40+F1p8Ufihr/AIMn+J3i HTvA3jX4h6Xp9pe+HRqnivVPFT+IbSy/L/8A4YA/bH8af8Ef/CP7B15+xvp/gz46/smeHfgr YN4p8VfE79n658B/tq2fwZ/aZ8M/F7xZ8N/hd4j8F+NPE3jPRvAnx30nwAfGWt3X7Q+lfASa 3+I+u+B7DxLoep2reM/F3g/+ju8/aT+C1h+0TYfsn3PjIp+0DqnwZ1f9oLT/AIfjw74qc3Pw i0Lxfp/gPVPFg8VLoZ8ERG28Warp+kjQbjxLD4lmNx9ug0aXTIp72LnP2Pf2p/h9+2x+zb8L v2ovhXo/jLw/4A+LemaxqvhzR/iDp+iaV4xsrfRPFGueE7tNb0/w54h8V6LbTSajoF5NbrYe INSjeyltpJJIp3ltoVhrQWGxWEioUcBQ4SoYSdJynRoPgx5xk/D1ajVqOo6lTCYjAZ3gcZB1 KmHxdfB43A5lQrRozw0aqa1MVSrpyqYjF51jMXTm5U6klxVXwWdZlQqRpypzp0cXRqYGvgay 5MbgcNXoY3KcXhcTVhjX/Pf+13+wD+2p+2bqP/BQn9o3wx+zTqXwKl+Lfg3/AIJ+eGPA37IX xY+JXwG/4Tj9qG+/Yy+Of/C8vHmpfEzW/gr8UPiR8E/Clv408Maofgr8LG8UfGHVru9/sG5m 8fQ/D/ws/h+8h86/aO/4Jx/t5/tNeIv+Csvxf8G/s16h+zn/AMNXat/wTE+KHwv+FusfEv8A ZhvfiV8WP+GO/F/iXV/i18PPFk3h/wAS/Ff4GeGPilrkWg+G9U8KzfEDVPHvwa1t9R8D2Hi/ xXeWH/Cd6L4P/rrr4g+In/BR79jH4T/E7xx8HfiD8ZD4c+IPw08ffs5fDLx7pMvw7+K1/pvh Txn+1rcapafs+6frHivSvA1/4RttP8f3ej39ofEn9ut4Y8J3S2tt431jw1NqOnJdFBqj9Uwm FTpTWY0cVl9OlUqvELNcXmuR4jnw8nUliMRUx+b5ZlChgqkq+EjXdHB5fhMPSqUsOlWTq0My rV/eo1MvwdHNK84QVGGV5VDC0cMqy5VhcHTw9OjGjPMKVPD4yUMROFbGy5cL7D8V7/8AYD/a I0jXfhR+1h4H+DH7dPxT+IPhT/gpZ8Of2vv2i/2f/wBrT4if8EydB+KPxltfDn7PGv8AwCtf iV8EtM/ZT8Z+D/2SNM8SeCrfxD4b8RjTviL47+GniLxJf+CdY1Jr8a63hq+1T9Ff+Cj/AOzL 8Xv2xP8Agkb+0b+z78I/gro/wn+M/wAW/hi+t+EvgPd+Ivh/ZHS/FkXxA0v4nnwNrfifw1qS /Cyw8deJZdOuLXxHqel+KdW8AWfj/WdReP4heI/DsZ8b6j9lfEr9tr9lj4N/EL4g/C/4q/GL QPAHiz4UfAi1/aY+JL+KdO8SaT4S8E/BS/8AFmoeBtN8YeIviJdaKnw80641bxXpWoaPo/hK bxSPGurzWzT6b4curN4rh9T9nr9rf4H/ALUKa+vwm1P4gx6j4Z0zwvr2reG/iv8AAv46/s8+ NF8L+N01c+DfGmneBv2g/hv8L/GOueA/Fcvh7xHZeHfHmh6HqPg7WdU8N+I9J07W7jU9A1e0 spj+/wAFXwmGtGiq+GzKlUwqjJ5asJl+A4Rw8sLC1TDU8JTqcF08LCGIoV6EMyyrH4Smo0qG IwVPWlVqYDNMFmk7/W8FGnQUcVzcuJn/AGpiOK6f1nmcK0q06nFlOv8AuqtF1cDmeX1pRnPE UMTV/HH4l/CH9r2y/az+I/7Y9v8AsAfFD49+Hf2mv+CZVj+yUfgNqHxT/Y3074j/ALO/xI8H +PPG+raj4H+JU/jX9oqx+EGqfBf402XjGw13VfEvwm8c/GPXLS50Ke38Q+BoybHTbjsPjj/w Tg/aOv8A/g3um/4Jt6HrWg/FH9pnwp+yN8NfhpYyQ6/Fp/hrxZ45+Gl/4T8SHwb4b8UeLY/D dtbaNKvhp/BPgrXPFcfhyzFpFot74iOhWxvXs/0f1L/goZ+yNpvxo1j4CH4l65q3jvwx418L fDPxtrHhb4Q/Grxl8Hvhx8TfG91Z6f4R+GfxT/aJ8J/DrWv2ffhZ8R/EWqapomjaT4C+InxO 8M+LrvXPEnhbRI9HOreKfDtnqfyv4P8A+C2/7GPiDwp4A8beJtG/aP8Ah/4c+Nmo/GyT9nSY /s9ePvjfrX7QvgD9nzU20r4pfGTwB4O/ZLtP2ifGvhn4YaDMjXv9ofGjw78KfE8uipJr7eFI tEilv0n21KWAxUKFSFDDYuvLFQxlOopQoTw2acTcU0KOFrYiVbC1Hga/F+cY+jQrRxOIqZdB V8T9ZwmCxNUWBp1MBjspr0ac6uKyR4WhSoVIznKrVp5Zw1k1OpjaNPkqqVXC8F5Vh5zo/VaC xPtqcI062KoU4+B+NP2VP2ifjx+178Y/2mtd/Zc1rwDovxF/4Im+K/2S/DOifEvxb+z7rXjb w5+0Drfxd+JeqXvwrvJPAXxV+IOiWqa94Y1LQNWl8V6T4iu/h/eaVqVjY6v4ltNatNT0TTPz ivv+CV/7aaWnwi0v4x+Bf2v/ABr8Kvif/wAEdP2Xf2Evjn4E/Y18df8ABNG9+KHw/wDGXwms rkfFL4YfEDVf277658NT+CPFeo+KLrxF4f8AiH+zR8Qk8QJ4v8M3MurzS29r4K1xP61PhV8V fhx8cvhx4L+L3wh8aeH/AIifDL4ieH7DxT4K8a+Fr+LU9C8RaFqcQltL6xu4j/vwXVrOkN5Y XkNxYX9vbXttcW8XiHgH9uP9lX4oftTfGX9inwH8XtK8Q/tPfs/eG9B8W/Fz4WQaD4wtLzwn 4f8AEtn4fv8ASr9PEupeHrPwV4hYW3irw9/all4W8Sa3f6BPq1paa9a6bdu0C7ewdPGTwLwz WIU8xr1MrnGs6n1ehV8SMTmlCrhpS+syweGp+KHENLHRquTp4XC5VHFVL0MdPMOWhOEcFRxN HEOWGpYfJaFDMIVIckHQoeHeX5TXpYmCVGGIxNTw74dnhqlOyq47GY+eEjCVfAQwPxj/AMFG P2TPjF8Yfgv/AME7/h98DvC3iD4gT/s8ft9/sKfFvx7N4s8YeCLDxVpPwf8Agd4gaXxz428T avrWuaFpPifxBpGlxw32s2HhSTUtZ1/UZblvDmjaiXWIfEmu/wDBNb9qt/8Agr6dT0fwhpSf 8ExPF/7TXw9/4KceMPE8Xi3wha6jpn7ZPw4+CHjD4RL8O7XwR/wkKeObuy8ZeOG+H3xn13XI /C0nhd5/DgsZ9ZfUZZLSP+livmb9sD9qr4efsU/s/eMf2kPipo3jPX/A/gjVvh9o2raV8P8A TtD1XxXcXXxJ+I/hL4YaHJp9j4j8ReFNIlgtNf8AGWl3mrNc67aSQaPBf3FnFfXsVvp91dKt UhjY4mLU8XjOJK+bxlLWdbNs3XCOFwuHjJOMlSw+c8H8LZ1gIRlGr/bOApvFV8Tl1Srl83Ol CWAWX25cLDIsPkKjFJcmX4atns60oqzjDEYzLuJM9yTFVoQjbKMxr08LHC4txxi/OD9gH4Vf tZ/sFap8Zv2Urr9k3Xfir8LfG37ZXxg+Nnwt/as8HfFn4F6L8L7T4RfH74hS/EXW0+NvhzxT 490P4/ad8Vvhvb6nr2gQaT8OvgP8QvCnjO/svCWmQ+LfDmiXWs+LND1P+CjH7CfxJ/a//bq/ 4Jm+NNOsPifpfwL+CWk/ttWnxt+Kfwc+Pmv/ALP/AMRPhle/Fb4TeCNB+Ft74e8TfDz4i+AP i1eS6z4p0O6tri08FjXdHktrWWy8e6fJ4X1K4tb79pKK41h6X1bLsLVj7enleBjluHdRuE5Y Glw/LhrC0KkqDo2lg8uk54fE0VSxf1tRxFbEVnGMV0qrOGIx+JpP2U8xrZlia8YLmpxxGb4n F4vH1acantGvb18bWl7GbqYaEOWlCjGkpQl/Jn+zh/wS0/aw1fxn/wAElfAX7Q3wD1z4Q/DT 9hXw9/wUI+DXxX+I/wCzX+0Tp37N1/4u0fxT/wAItB8AvjhpOqfsofGn4e/F3T9S/aGTT5/E PxI0zR7qHxBe+MX8Wan8W9I0+LxHi/X9tr/gmh+37L8Tf2/P2j/2Mvh88/x78J/tC/8ABP34 u/sFeI/F/wAVvCOr678TNI+Ff7Ktz+zH8fNO1jxb8QPifB4gsrq18OeM/EbeINS+M2v6TrPj 650E39pfeIdS1C01Ob+suitMQpYulTp4mpUqycP9srRl7CpmWKnxTg+L8Rj8csMqNF4rFZrh OSqsLSw2Fp4DE4nB4XC4em6LorDTWFxNfExpwqe3jjKMaFdOrRw+Cx2AnltbL6DlL28cL9Ul y3qV6mKqVYrE4jE1sS5VZfg5/wAEuP8Agnb8V/2Gf2sPjy+q+FkT4Hv+xH/wT4+BHw++Jaa9 4RuT8RfiJ8CPBvj/AEz4yajN4a0vWZvFej3U3ifX49bvNR8ReHtIs9autcmn0q81No72SLsP +Cs3w/8A2nvip8V/+CeMnwE/ZB+Mvx88Pfsx/to/CT9rT4l+L/A3j39lDwjoh8IeC9E+Jfhn WvAXh2x+OP7Sfwj8V6r8St+u6Pq9pby+GrHwFPpN+gPj+PV7e90m1/bOiunEYmticbhMfOaj iMHnq4hpunCEac8fDiKvxRTVSnyuP1enmtbmjSp+zbw9KlQnOS9rKrzUqEKeGx+FfPWhmOSL IcROtOcqv1P/AFZwnCdSpGonFvFV8qwq9rWqKpH61Xr16dOn+5hR+KNU+N37TV5D+01a6p+w t8Tn8KeCNA+GkPwGfwl8av2a9c+JP7R1z8QvCsEvxIsrfwd4o+KXgHwF8Jbr4J+I7+XQ9abx 38YzY+OLHS9R1zwLfaqW0vS9U+Zf+CIXwq/aA/Z2/wCCdvwK/Zm/aU/Z98efAX4m/AjR9a8M avH4s8YfAnxpoPjVtd8a+LfGEeteBtW+CXxh+K27R7C012z02/XxpbeC9Z/tVLhbDR7/AE1I 9Sl/XGisqclS+u8sI/7fTymFZNzfLPJ4Y+OHr0/eXLVrPNMfPEqXPRlLEWo0aEKVGFPScef6 teT5sLLFyhJct5xxtPAwrUqityuCngKNeDhGFSNWVROpKjKNGBRRRUlBRRRQAUUUUAFFFFAB X8ePw88EftR+Lf8Agrl+zD8dE/Yz1n9n3VNB/a//AG2fAn7Q/iDwT+xp+03p3jbWfgjr/wAO viNp/wAJ/Ff7RX/BRTxv4x8QfCz9rn4afEe88LeGtX+HHhrwb4c0/wAE/AWe28B+A9Mu/D8N p8P9Euv7DqK5qmGVTEKtKclD6hjcDKnGyusbWwM51OZ3TUqGErYGtRqQqUq2Dx+KjanWVCvR qrL2mBxWCty/WZN+13cL5fmeBTjHRqpRnmMcbQq0506lPFYLDqUqmHniKFb+O79gb9iL4u/B Pw3/AMEJ/iT4R/Zm+Ivwp/aFuIP26vAn7W/xN1r4SeMtH+IWgeCtV+FPxjl+Dfhb9pHxNrnh 2fxH4f8AhxYeMtJ+HA+F3hf4gyW/hbR7u28P6d4F0m3W5tbK486/YJ/ZX8Y+Hv2l/wDgiX4p uf2J/wBpfwB+0h8EPG/7bdp/wU1/aB8dfAD4o+F9O8W/Gjxz8HvjBY6L8QfiV8cPEPh/SvDf 7REXj3xWmvXvgL416Bq/xI8K6No3ijw/4K/4WDo2oeL9A8Na3/atRXpLEuOZYvMYwUXia7r0 qEZOMMHG2ZxeEwko2lRwNd5zja+Nw1PkWNxlHLa9WXs8JXw+NnF3xdCpRm7OvleMy3EzfvrF VMdDHU6mZ4unJ8mKzShSxNGhgcZiFVqYLD0q9Og4yxbqUf5/fj7+zB4K0v8A4L1/s6ftS+Of 2UZPH3gLxv8AsU+LvhxoXxq8N/sya38ZLDwX+1p4X+Nvw/1H4d+K/iN4y8GfD7xcfg/4k0r4 YNe6P4J+M/xBv/C2l6NoVpqmgWPjHTrGzvLaP83f2EP2HfjJ8BfA/wDwQ4+JHw0/Za8c/Cf9 pOex/b88H/tUfEPXPhB4w0DxvpGga98KvjXqPwb8MftNeJdX8P8A/CRaB8OB8RNP+HU3w78O fEG4s/DemX66La+CdOtnvILa5/skorzo4eMcoqZRGdWlGbxUI4vDTWHxVKhjM34nzbERpTUZ claq+KsXgKlaNoTy7BZbh50JOhVnX2lXlPG4vGThSq/XMFhMNPD4iHtqEa2AyTD5HgsQoSaU o4WnhKGPoUpJyo5jUxuIp1oRxMKdD+Tf/gh7+yn8W/hx8Yfg58Q/i/q3jr4N/tEeFPgf8aPB P7XXwzk/4Jk/tc/BC8/aP+Iuu/ES01PUPiJ+0h/wUF+IXxJ8b/s2ftffEPwx43h1Hxb8K/iJ 4CittW8R+E/G3iEeF4rLwtNqOl6X6/8AHX9g74lftVftL/8ABwX8PtV+H3jnw3oH7Q/7NH7B 9v8As5/FLVvCviDRvCHiP4zfB34b/FHxL4a1D4f+M7qxttH8Qan8PPihYeCz4j/4RvUru88P XFza22o/Y5ruFJP6aaK3x3PjaHsoTeAlHL8zweGlgL0I5bWzLMK+afWsrTlOvhZYLH4ieKwK q4nFV8PXUZxxNoUo05wc/qc8TNp4yWKxOT4ivUx0nXrYv+xsbkmLpxx8/cp4qWKp5HQwmLlC lh6dWhUn+5U7yn/F9B+zP+3j+3X+wX+2X+2t8Yf2X/iv4S/an+MPxz/YL1v/AIZC8daBqHw6 +JPjn4C/8E+m+F+qfEDwVpGkeO18M31gvxi+Is3x1+IHhDQdUh+x+IGXwwdI0651PWbN5P6s /wBnz9pnwx+0laa1qfg/4Y/tHeBNH0Gy8PNeX/7Qf7Ovxe/Zsu7nXtbi1C5v/Cui+Ffjp4U8 A+OfEN74VtrWwl8Q+JtC8Laj8N5Zdc0/TvDfjjxDq9j4k0/Qfo6iumVdS+sQjRpUsPWqYbF0 8PQj7OFHMYZTleT4/FRs2nTzKjk+DxdbDqMPZ5gq2JhWccRXo1OKnho0o0eWpVnVpUp4P29a XtasstpY7E43LcJKVo81TLYYuvl9LFVPaVKuXShh6kFPDYOthv57P+CfFhf/ALLnhz9q/wDY J/ad/ZZ/aI8eeLvjB+2x+0z4ts/E1t+zb8Q/jB+zr+0r8Fv2ofHN14gsfiJ4w+OEHh3X/wBn Xwpo+m/D7WLnQ/il8PfjT8S/Dvi9LLwpc6BZeGfFHiPxBoPhjVvyc/Yv/wCCfn7U3gC0/wCC HFr8CPgbb/sifE6x+CH/AAUvH7SHxW+I37FnjjxToPgDxl8QU0nwx4U1P4+eEfD/AIv/AGfN Qh+JHjDwVo+l6H8M9U+JXxBsbi8tNH0SK30jxXoWlRaHJ/btRXDQw9Knh6OHrRdeNLKcsyGT U6lD6xlOT8LZ1wpgcNiHSmpzlPCZy8Zj2qkcPi8bhoOnhcLhprDU+ydSbrYutTah9azXGZ3G M4QrrDZlmWeU8+x1WhGrGVONOWJp/V8LzU5YqhhnH2uLxVeCrv47/Zn/AGfPAv8AwTu/Yp8B /AT4bxeP/iJ4O/Zr+FOsx6ag06XxN8SfH93pUes+L9dksdB8NaaZdT8T+L/EN5qk2k+G/Duk v/pmpWmiaPYyKltC380XwN+D/wDwUi+CPjH/AIJ6f8FAvGv7FNhZ+Kvi7+1P8bNc/a3h+Gvj z4z/ABT/AGnrX4Rf8FItci1vVbP41/s1H9ljwKnwz8O/suHwt8HLfUHt/jF8QbzwJb+ALfT9 V8P2sF/rM3h3+yGirxSqY3HYzMcTU9pi8Zy0qs1CFJPCYvF1MRxBg5PDqhUeH4hpLCYTGUo1 IUadDC8kKMoYitB4+ypxyyGVUoypYenTr+yl7SpVnTxUMuq5flGNj7aVSLxGS/WcZicNUqKp UniK8KsqkauHpVF/HN+wj+xJ8Zfgj4Q/4IY/EvwN+zL8RPhV+0hNYft4eBf2rfiZrnwf8Y6d 8QNB8Jap8JfjLN8FfCv7SfiDXtHt/EOi/Dex8baT8Nl+F/hL4h6jpfhXSrq28P6X4Hs9PS6t oJeOuv2XbnXv+CKXxY+Dvh39iL9qXQ/+CiOo6D+zjov7b3in/hnL46+D/HHx6+Lmkftx+APE /jnxde/E4aJpkP7YHiZzZ/EL4l+H/jh8LNX+MNr8Pfhxc6neP8QPAOkeKdO0bW/7SqK63WTz KvmDpRca2ZZfmMMLtSwyy7MMVj45fhna9DLsbUx+LlmeGpqP16tDAVKk1Tw2Iw+N0xEp13Qm qk6dWlQhTqzjJuONxEcesfHMsdDR4rMsM6WGoZdi6s3PL6dOrKlzVKtOVD+RX9rX9jD48/Dn VP8Agsp8K/2Nf2c/iL4C/Zz8b6P/AMEyPHzfC34CeANa8AaB8fPBWmeJPFkf7dnhb4JyeHLD R9G8c/FHx18IdDstD+LWieEp9Y8XfEO1ni8Ia7Ya54g8Z2Vjqvhf7Wv7Kvjnxt8Mf+ClVx/w T9/Y/wDj98Fv2M/iH/w7T034f/Avwh+y18bf2YNc8aftMfDn9pDw54j+N/xl+C37Mmp+DPh3 8VvA2neFvg/L4B0rx/8AFnRfhb4K0vxbrfhRtX07Xdfuvh3rOv2f9r1Fc+FUcPWw1WpFYmOG zTDZoqVb3oYpYf8As2lDK8epKccXkuHw2WUJZdl0oQp5fmcpZpSnOpChRpPEylWjilSlPCPE 4WhhovDzlTWDnQhg5SzDL4wcFhc1xuLwjqZpj1zVcwwlaWCrJeyo4in/ACx/trfsm6f8Av27 v2dvHH7I37IF58UZvAuh/sufCj4efszXf7EHxH1P9nr4e+DZ/wBpHWfG/jn46/spftvfBrV9 A+Gn7CPxk8Grf+JNa+M8Xxak0uP4qacNMu9a0Xxbp2tWD339E/wL+OifHOD4p3Efwg+OvwiT 4XfGXx38HFT46fDqb4cz/EceBZ7OD/havwst7jUtQn8V/Brxj9s87wJ43kj0tvEEFpeyf2VZ iAB/daKqhOVLCvC1ZSxEfrmd4+nOpJ89PEZ3j8DmFaXO+atWUMRSzStL6xVrSqYjOcRKE6OF wmAweHyq04TxUsVSjGjKeGyjC1IxScalLKcHjcHFcqUKVN1aVbLqcfYUqUaVHKaKmq+KxePx mIKKKKksKKKKACiiigAooooAKKKKACsrXtRm0jQ9Z1a3s5NRuNL0rUdRg0+JnWW/msrOa5is 42jindZLp4lgRkgmcM4KxSHCHVorOrGc6VSFOo6U505xhVSUnTnKLUaii2lJwbUkm0na10XT lGNSEpwVSEZxlOm5OKqRUk5Qco+9FSSceZaq91qfmwvxc+Mth8CPhX8XLD4wWHjTxp8Yda+D eqx/Di50f4e6HpOk2/jP4oeEdK1zwp4Q1LT9Au9d07wzp2n+J38A+J9Y8Vp498RWepHS9Zsd X8P6pFc6Zqnqvhn9qbxT4v8AFPhvwDafDHTNL8TajJ8Z7bxhcP8AEaSTS/Co+C3jXTfBniK6 8N3zfDq4m8XS3/8AasGp6BHqmh+F4ppkNjqiWUBa9H0dp/wg+E2kXGrXelfC/wCHemXWv63p niXXbnT/AAT4asrjWvEeianLrWjeINWmttMik1LW9I1mebVtM1W8aa/sNTmlv7WeK6keU7Nn 4D8DadqX9taf4M8KWOsZ8QN/a1n4d0e11Ld4svodT8Ut9ugs0us+JdStrfUPEB83Os31vDd6 j9puIo5Fud5KtGKVOFSeY1adNScnQliMHhaWAoRrtKvUoYPEU69WrKclUrOUalNUHUq0nmrr klzc1SEcBTnUcYxjWVHE4ipja0sOr0KdXE0alGlTjCLp0/ZtVPapQcfhKX9sDx3pvww0rVrD wRZSapqX7N8vxc8MeKvih4j1uCHxn4j03wtrPibWtAspfAfwc0jwFr+q+HtL0d9V1zSoNf8A htq+pJMo0fwzpujNNrtj1eoftNeMPCd/qD+J9E0Y+I5fht8FdetfB8PivxLqng258QfEvxJ4 30iDTfCH/CEfs9eLfi3qXiC+t9Btbma0m0fxFYOStlZ2GjQ6XqPiLW/qex+D3wk0y/Gq6b8L fhzp+qDw7/wiA1Kx8EeGbS/HhL7Ktj/wi4vINMjuB4d+woln/Ynmf2Z9lRbf7N5KhBXf4J/B mTRZPDcnwj+GMnh2aw03SptAfwF4VbRZdL0fU73WtI02TSm0k2L2GlazqWo6tptm0Bt7HU7+ 9v7WOK6up5ZKqvnqVpU/3camIhOEbKXssOqubKdOCa5OaVDFZdytppVcE3LmTUpEVanCDbco UJQ527uVZ/2TKNSWqk4RnhMwTi5c0qeNaU435afyXov7ceo+IdM0PxLpPwiil8KN4Y+B/iXx nqFz8QGtNX8Pf8Lp8dan8PYNO0HQ5PBDL4ouPD2u6VdTTS3+p+FIdR0xPPBsLox2MnpX7U/j j4i+FNQ+BWh/DzVPGthP4++J194b161+Hdl8Krrxnq2kWvgLxb4gSy0Of4y2lz4FsJ01DSLO 7uLnUprNmsre5gt52nlihl99tfhb8MbKyl02y+HPgS006e30O0nsLXwh4ft7Ka18L6rca74a tpbWLT0gkt/Dut3d1rGhwvGY9J1W5uNQsFt7uaSZul1HQdC1e70e/wBW0XSdUvvDt9Jqnh+9 1HTrO9u9D1OWzudOl1HR7m5hlm0y+k0+8vLCS7snguHs7u5tWkME8qO6nJN2ipQisxeITUnz rAqvhqtPBt/DLkhTr0nNxvUhVSqyqWbCLklVb5W5YJ0YJq8Y4mWBlRliHopXeMnKvFRcVCnG mqcYTjKUvkHS/wBqHxFcfEq9+Fdj8K/H+sad4Y1i08BeJviHcaX4jv8AVtH8Tf8ACvrHxZLr 3iiLwp8MJPgzYaPHe6hp2k6rPafFOxv0vr5dV0vwU3heWxvJvFfBv7XPxA8OeF9K8U+MzefE GbUvgR+zLq9hoFnpEenfb/iP8XvG3jHwrqWr3UvgnwZr/iKGzu/sWlPPp3h/wv4hmX7Elp4a 8LXWqagttdfeF94J+DV78R7PXtS8I/DG7+Lo0ibUtP1q+0DwrP8AEcaDZKmh3F/Z6jcWj+Jx pFouox6PNdQTfY4Fv0095EF0sL6T/Cz4YSaXd6HJ8OPAcmi3+gaZ4TvtHfwh4ebS73wtok9x daN4au9PbTjaXGgaRc3d1caZo00L6dYT3NxNa20Uk0jNEXPlVSXK6k50ZScVajUjQpZlh8RC lFqUaCr169OXuwqvCzw8FJ4meFpSk3GN6lNOapqnGNPmd61KUsRgcTCdSScZVXDD0ZU3eVP6 zTrz0oU8RUS+e/Bf7TPjLxj4v+Gvgc/Be/8AC+u+NLH4g6xry+NNZ8W+EI9D0H4eeJ/D+hXm s+HtO8T/AAt0fxV4mtPEOneIrLWfDS654Z8CzXLB9O1WPR3jnuoPLbP4t+P7b43GNfFOrWfh 3xN+2Rqvwe1HRdUNvd6Tb+EvDH7P66ppOj6RDqkd1DoTa74xiOvtdaF/Zeo6zdXMMFxPdRs0 Un234c+Gfw48HnST4S+H/gjwsdBs9V0/Qz4c8KaDoh0Ww128g1DW7HSTplha/wBnWes39ra3 2q21n5MOo3ltBc3aTTQxuvNj4IfDq5uviUdf0Gx8Y6L8VfEmjeLvE/hDxlpeheJPCQ8QaJoW i+H4dQsNG1LSZVWW5tfD2j3Vz9vm1AJqNlHd2P2Is6NcXGFSlPl51ChKNVSbSrVf7ay3GRSi uaEIrLMLicHzcspOdefOqlOrJRmSlKFeHMoOpOSpSirujTllONwjd/dlOoswxFDGxXNGMVQp 8koVKcXL410f9rz4k6DoviqWfwbYfFGbTLv9qXx9HrF94rsfAVnafC74G/EWLw7Bp+kDR/Au vQeIL46bqEFnpVy6wfb7yxkTVtWVnuNQh6jxF+2XZ/Di+8b674l0PW7/AMA2XjeTw8Nb1fxF 4ctF8N3t18BNE+LPhPQ9O0vSvBOnTfZvFuoS3nhmMa74m8R6laeJLqCaDV7vT9RstE0r7Ij+ Gvw5h0+10mHwB4Ji0ux8Mal4KsdNj8K6Emn2fg3WjbHWPCVrZrYC2t/DGrGyszqWgwxppV+b S2N1aS+RFsjv/hh8NdVsNQ0rVPh54G1LS9W1HS9Y1TTb/wAJaBeWGpatodpZWGi6pqFncafJ b3mo6RY6dp9lpd9cRyXOn2lhZW1pLDDawJHnCLjShSnUlKUMHhsJ9YUYqrKVPGw9vjHCXPS+ szyyjShTc41P9uniKuIliKdWSlpJp1p1VBKnLEYvE/VueXJFVcMvq+GVRJVPY0cbUxEpcqhG WG+rxpUqLpRhH5a0X9rvxNqvj658HN8DPFP2LQ9QsvDnjLWtJHj7XIfCfiif4c2Pjq8/tDVL T4Tx/DuPwnp19qdj4Zm1nUPiPpfimSS6g15fAY0SeC4lk8P/ALVfizW9E+CviDW/hfpvg7wx 8b9KbU9L8Ut438T6zp+gDUrfRx4X0G51HT/g1feH7bx74huNRvTpWh+KtQ8N+G7tNOt4dP8A FWsavezaDZfT198LPhhqfiyPx7qXw48B6j46hg+zQ+NL7wh4eu/FkVt9jl077PH4juNOk1iO D+z557HylvBH9jmlttvkSOhjHwm+Fa3nhfUV+Gnw/XUPA+nrpHgq+Hg3w4LzwhpSxyRLpnhe 6Gm+f4f09YppY1stJe0thHLIgi2uwJJSnFrSEpzpKXI5ckKSp4qOIdK7VRVKk54WpQ56kvq7 pSjOeJXM60K8WrS5uSlVtKUY3nXcsO6DqRanT9lTUa6rKMb11UXLGhp7P4p8JftWfF6bTU1e D4daJ408JaP+zB4H+PF8b7xybb4p6musXfiGDXN/9h/DPRPA2qalFF4evjBo2l6H4UtZ2tIr 21vVk1pPD2hfXnwa+LGnfGjw1qvjTw/aWy+Ef+Es8Q6D4R1u11T+04PF2i+HrpdLm8TRKLCz XT4LrWrfV7G2s1l1FXt9Piv0v3S9WGDYn+FPw6ZNOksPBfhPRNU0DwzqHhDwnr2keFPDEGte DfD+o2c9jPpnhS6uNHuotH09YbiXGlQ27aRLkxXen3Nu8sMlr4a/D3w38KPAXhP4ceEYJbfw 54O0Wz0TTBcfZzdzxWqfvr6/e0trO2m1LUrlp9Q1K4gtLaO4v7m4nWCISbF25oSliG4WX7xY eK0u8RmWPxLnNrXmweBWX4GlDSnJVMTNqbhQdGXFpUVB688HWk7ybhRy3BYZU0paL6xjljMb OonKa5adN2VSbl8IfFL9tDx9D8NfF3iDwN8P9G0RNd8GfHjUfhf4tvvGp1HXLC5+CmtQ+HfE WseMPA1x4Bl0zRbhTNc6r4a02LxB4ts9Q1G103RPE50JNUmmtPbfip47+JHw5/Z9+G/iabxN 9n8ZT+MPgZpPjLxDOPDmsxTad4s8eeF9I8XfaLseC/CehC2u9M1O8tDqln4O8NNaxyrc2dtp 10kcq+6D4PfCRb7xVqa/C34crqXju0vLDxvqA8EeGRfeMrHUZluNQs/FV2NM+0eIbS+uESe8 t9XkvIbqZFlnR3UMOw1TQNC1zRbzw3rWi6TrHh3UbGTS9Q0DVNOs9Q0W+0yWLyJdOvNLu4Zr G6sZIf3MlpPA9u8X7toynFZUrwhRcrVasK2W16vM7RrPBYvEYivh20uWNHG0alHDV5RopTjB yqUZxjCmaVLTnUUW6dOUc2pQcVeVOGPpYang6iTalKrl3s606XPWlLnkpwq05VJtfB+q/Hj4 maf8afEOhw+IPtfgzSv2k7HwBb6dHpXh8W83hu1/Zl1b4h6z4ZXWF0eW9FynjK2tdQu7w3Uu sWDslgbiPTnNg7dJ/bX8bXllpOtaj8D9EsdAvvDXwH8d3l1a/F2fUNSs/BXx58V/8Idodzb6 ZJ8MNPgvfEmi6mHuNR0GTU7HTZtPUSweJRct9kH2dpXwu+Geg6VpGhaH8OvAujaJoGo3mr6D o2leEfD+naVomraha3tjf6ppGnWenw2mm6jfWOo6hZ3l7Zww3Nza397bzSvDdTo8i/DT4cJa pYp8P/BK2Uel+G9Ejs18KaEtrHovg2+OqeENIS3FgIl0vwrqZOo+G9PVBaaHfE3emQ2twfMq qNqfsY1G60KcsrU7rklUp4XA0sPmF5JuaqY7EUYV1J1Jez56801XrSqua3NUu6aVGTp4iGj5 kpVMyliKE0nHk5qGBq1cPf2a5qscPzRlQoxproNH17Q/EMFzdaBrWk65a2Wpaho95c6PqNnq cFpq+kXUljqulXM1lNPHBqWmXsUtnqFjKyXVldRSW9zFFKjINaub8J+EPDngfR10HwvpqaXp gv8AVdUki+0Xl7cXWp65qV1rGsalfahqNxd6hqGoalqd7dXt5e311cXM80zM8pAUDpKXSPfk hz9nU5I+0ceqg58zgneShyqTbTbfWXbnny9+Tnfs+bpz8nLz20578ulgooooAKKKKACiiigA ooooAKKKKACvyy+J3h7xppvxa8ca9rHwlb4j/EW/+NPw5m+G3iPXfgz8R/iNp1h8FpLjwnY2 Nv8ADr4o+CdW0zRvgPrHw/1U+N/Evif+17yyutdv3TVruzu7TVLe7P6J/EX4g6N8M/DkfiTW 7bU7+C58QeFfC9hp2iw2lxqmo634y8SaX4W0SztIr69060Jk1PVrZp3nvYEhtUnm3O0axvyH gv8AaE+EvxB8WXHgnwr4j1K78RQP4qjig1HwZ448O6bqsngbWYfD3i+Lw74g8SeG9J8PeJ5f DusXENlqsfh3VdUe1aQTOv2cNMCjpiqNaH7ydJzi6S1co4atl+Y4jlteUKkKVLDwr1Um6eBx teLUfrEKsCo/3FSnJ8kanKlN+6r16eLwtGM729pTqTlWnSpc0efF4SlUjJyw0ov4huviX+2l HcfHGZbbXbfU9D8MfGibwt4TT4ceK9ahi1PSNbZPhVefDm+t/wBnTSvBuuT3OkQwG+0vU/jj 8Vb3xPDqpvrPRfD99p97otj3fjW6/ar03W7+y8N+PvihdafoGnfs7PbXa/Cz4e6inii9+Inx C1/Sfiybya3+GaRbfAvhb+zb42+hnTn8NWltY6j4llvEuLye/wD0Mrzfx18WfBHw5vtI0vxR d67/AGrr2na5q2j6R4b8FeNvHGr6hp3hubRYNdurfSvBHh3xFqDR6Y/iHSXuQ1sri2uJbtVa 1sr6a2mDjSjhVUkpeweEcnOVvrH1OeLxFdVG25SjiqVWSxKcpNUsPTd+SjBU3OMqssQqacXi J4qUIwjzOisVPByhCkktFh1h6tOgoqPJHF1WkpqMn+ffiz4n/tfeGP8AhGNI0zTfjH4p1TSP ib420y618/DzRE0Xxv4G8O/GfT9H0lfEukeG/wBn3xAiahrHw4nvdRtPEGmeLvgn4dutGtv7 X0O88S66o02462PW/wBsSeO7vLPxT4thvvEek/tMz6dpniD4W+FbPw74M1D4Y/ECwX4NwNep 4Q0/UY4viN4ZhvNPe78Satfxa3ol8+teHIIL+yj1Q/b3w2+KHg/4t+HIfFvgafXr3w7dGI2G p634L8a+DItVt57aG7gv9Gi8a+HvD1zrOlTwTxtBq+lQ3mlzP5kMd400M0aaXjfxN4Q8MaLE /jie2i0LxFrOh+CBBeaZdavaanqfjbVbXwxpGjXVla2d8JLbWNR1O306d7uAabFFcNJqM0Fm s0qEoV6dKjQTtjI06+HhVqw96visdh6WEw0p0JRdNzhXVKthqUab/f1JKnG9aSm4TpSrTrtX wv1mni6lKErwp4bCSxNbEUFUupRoOM+au3OKVPDRhOXsU4x+CfhP8QPGfxa+Kn7MPxU1mK80 7/hYOmftM+ItI8O6pY6fZ6l4Z+EBTwFpvhbTpW0u3hF6l/q+naD4jS91Oa+u5Trjx295LZww Kno/7VHxC+PHg7xh8ObT4O6D8R9UtbiTTNR10+HfDtr4i8HapaweN/DdnrPh/W4LX4LfEDWb XUp/C11rN6l5P8SPhFp9rp9vNdaXqPiLXLePR3+vtP8ACXhXSbjS7vSvDPh/TLvQ9BXwtot1 p+jabZ3Gj+GFe0lXw5pc1tbRyafoKyWFjIukWjQ6eHsrRxb7reEpxl38afhtZ+PpPhlLr11J 4utpNFt9Sgs/DfinUNC0G+8SxTTeG9K8T+MrDRbnwZ4W1rxEkI/sDRPEev6Xq+tPdabFptld S6rpiXezlT9vgVSi1Tw1epKnhG3JYilHEYmVCjVu3UrOUK1CpjJycp4nGKrUqOftpc2MYzVD FKpO86tJznidvq85OlUrVIXSjTpU5Rq4fDxbSpYR04qUZRXL8UXnjP8AbI0nS9a17Tn8b+KN S1/w5+1IumeE9Q+GHh2zsfBmoeAfHFppnwc1DSZbTwvo+qX+q+IvC8l7qek2HijWNUsfHEEF u2j6bNIXuLj2D9lPT/E6+Kf2hvEPiCX4karZeKPHXg298PeK/ij4Af4b+JfFOm6d8NPDGi3F 5L4cHhTwRbwpp+o2F1pCyQeFtFaaOyinuLLzpjcXH2VRWdL91G3xyWCeC55aylB46ONdScne Uqv7ujQU3LmlSppVXVapex0qe/JSXuf7XicTaOi5a8I06eHsrL2OHjH93GzXO5VOVVJTlP8A HjR/hJ8XNN1fx14D0vwT4xt/Av7VPxP+LC/FHVX0nVLRPB+l+Cfiv4t1efWGe4sTHZ2Xxk+F t9a+DtHvJQseqNBp17pFw77fO6nwFrf7TfgzwX8JvBOjaZ8TPCc+gfDP9nWy8CeErH4SHWfC Pi3UtR13+z/i7p3xj8U6n4J1a6+Hr+FtDgAhtJfF/wAMrq0tCuoQS65dzx2sX6b+LfGXhvwL pMWueKtS/svS59Z0Dw/FdfY7++3av4o1uw8O6FaeRp1reXC/btZ1Oxs/tDQi1tfP+0Xk1vax zTxtj8a+Grmayh03UX137b4h1Twqbnw1Yal4n0/S/EGiJenWNN8R6n4es9T07wrJps2n3Vhe y+JbrSba31ZYtGkmXVbq1s5jDfuoUacf3saNbAKcpe9OosspSpU8JU0cHRVPMcNBYedOcKUK 1K0HLEwmFf8AeTxNV/u3iFiqkUtKdGeKxUcZVrU1pKEqkcDOnWnTnTdaFOvNyjJVWfmv4Wk/ aP8AhL4a1OTQ7P4uazoPiCT9rjxAfAujeAvDtpqPhDWdN+Mf9p/D/UfDWtaj8M/FeqjUPGmn 63rus2cXijSvHdnr+ju0vhLwjfz2lrHPWsfiB+2rr/gjUZUuvij4d1rw34E/aG8RaZfx/CXS L3U/G2u+EfFXhOX4QaPqdt4n+CnhGSWTxH4d1nVrK3sdL+H3w/8AEHiW10qe9i0LR9Wtb6O1 /VqiohFwVNOUpKlg6uFgpO/vzeK9liajd3VrYdV6caftHJSWHpKpz2jyXKSk6kuVJ1cxlj6j WjlGdeNaeFi1Zwo1EpwqONpSc5VdKkpyn+XPxP8AH37Xng/QvHuj+HpPjN4r1q18XWw8CeL9 K+HXhdFFnqfwY0jxUdI1bTdD/Z4+I0XiLQLT4hy3/hnSprLQ/Cf2fUPN0jxr8VdEFut4t251 X46/EH4z/CWbxpo3xSsLTw58c/CfiODwbB8LWj+Geg+BZPgdcq/jO4+I0fhNb3/hIj448Q65 omp6FqPje5fSxL9kvfCekvYRajN99XvxR8B6d8RtH+E174gig+IOv6DceJdJ8PGx1R2utGtn vkkuTqcdi+jW8z/2Xqkltp91qMGo3tvpmpXNnaT29hdyw9/WtKSjWpYnlU4wrZfWoxfwRlld bD80oPVOrWxWBlHE1Jc/LKeJSjHFWrwxlBug8M5yU44XF4avPapVeY4drnrK+kVQxCrUKUeR JSo8svqjlh6vxF+2b8NfFPxPn+Ami+GPCvh7xU1p8TdevtRi8beB77x98P8AT4V+FvjqGwuf G2j2d7pqQaRcavLYWFrqV1qNrFYaxd6ddRpfXEUOn3Xzr4L8d/tGeCpf2ffBXg7wN+0Jb+Dd F8C+C9E8ZaH4n8LWF5G6Hwl4v0vW0stQufgI66NqXhbxRpmhR2Wo+JfjLpcNxBJobW3w31Lw lfXmsRfqomt6NJrM/hxNX0x/ENtpttrVzoSX9o2s2+j3t1dWVnq0+liU30Wm3d7Y3tpbX8kC 2s91Z3VvFK8tvKiX5po7eGWeVtkUMbzSvhm2xxqXdtqhmbaqk4UFjjABOBWFlSpV2qrp06+L o46tNtKLWCw9fCcnM/dVL3pus5c1pUkl7OUZSNm/aVad4KU6WCqYGnBJ8y+s11iva6e+qvLO Co8jg0pKd5qSR+VPg34t/tZaxooj8X2fx08LeGJ/iNpwvPGNl8IIPF3xN0jwpqPwk1LUofD0 Xh2f9nL4fwa1YxfFGyttH13xFZ/Bjy9JW6ksY/E8miz6Z4vn+1P2TdD13w1+zd8GtB8TaTqW heINK8D6XZ6vpGsWM2manp99F5ont72wuAJrWdGOWhfO0EbWdSrH07wV8RvCfxDsdP1Xwjda tqekav4c0XxXpWszeFvFWk6LqWieIBctpktjrGtaLp2m3V8yWskl9osF0+taRFJaS6vp9jHf WTXDbD4g6Nf/ABF8SfDAW2p2viLw34X8NeMZZrqG1XTNU0LxRf6/pdrcaTcQ3s9zLJY6j4cv 7TU4r2zsTDJJaNbG7imaSPpfuzr01S9nPESw0fZtPmj/AGZhcRSnFKV6jm/9qr4pt254zm4Q nGtUqYJXjTqOo5RoUpRnO6UZ/XMVCpRq1OW0eZ+3w+Hou2sJU4wfJKEI91RRRWZoFFFFABRR RQAUUUUAFFFFABRRRQB85/tNaBrOs+DvA+paJpmsa1P4M+Nvwb8aX+k6FZ3eo6jeaJo3jzSI 9bkj0+xhubu9j0vTL251uaGCCRxHphlwqxs6/K8P7GXxT0ODxRfaBrXw31fWvF9h+0Lp1/p3 xAudZ8beENEHxJ+IK+NPBepeEvDfizwj4m8O6HfXVhEmh/ESyg8NnQL+X7Fq93pHjO50rydS /TSiojBRjUSunUlj5Of2orMcDgcuxMY3TjaWHwFLl5k3GcpzWvJyVKTk6blqqTwcox2TeBxG NxWHcmrS0rY+s5cso8yjTjtGXP8Akif2Hvj0mgeA9EtNZ+DVong3x1r/AIy0e5jh8OrrXg37 d8TvD/xC0uw8OeJbT9nWyvoNOghs9b0+fRPh1afBDR01O+i1FoL/AEKSTwlB7h8Mv2WPHPg/ 4w2nj/VrX4XbLCH48war420XUNff4gfEyT4seK4fEPhvUPGen3PhSzsLG48I2EK6DHB/wk/i ho7QgabfW1jHDpUX39RTlFSpRotWhCjjaKab5+XH4aGDxEpTd5zlLDU40o87lGOk+V1IU5wi 3vzndtzxGGxUl9n22FqVqtOSj8MU6lec5qKXNLVWvLm/Ly2/Yk+JkOrfBm81HxFoOqweAPh/ 8HvC1zNpXizSvDmreCdb+G+t3uq6tq3w/wBZ8R/s9/E7xDJZ6+9xaTXUHh7xB8IL7Wls5tH8 S32paXd2h0fu7n9krxPrHhzxR4U1/wAO/By8fXfjT4b8da78QnudYuvHfxU8G2Xxsk+Il9o/ xBmbwVaTWVzo3hBl8LaJoi6/4u0i/n8tItS8KaVax20v6EUVq5t1YVWoucMbXx6ulyvEYjF4 fGVOaKspU3Uw1OPs5Xi6ek+aUaUqalFShUhqo1aGHw8rN3VPDYKtl9JxevLP6tXnFz3U7VI8 srt+J/Ab4YXvwh8Ia74Pm/saDST8R/iP4h8I6T4fe5GkeHvBnijxdqmu+G/D9paT2VhFpY0r T75LebStOgbS7GfzYrCe4g2zP5/pnwq+LvhPxn8Y7XwfqfgiDwL8aPFsnji68Y32q+I4PiF4 C1bUPCGleGNasdF8J2Ghf2F4jDt4d0278Pa7c+OPDMuhT391cX2i+IhpcFpqn1ZRWUoKaSk5 P/YY5dN80lKrhYxwqcak01KU51MFha1SqnGpUq0nzydOrWp1NIycXJxUYt4ueOhaMWqWJnLE v2lODTglCOLxFOnTnGdOMKluRyhTlH8wdB/Yk8bHRLXSNZ034SeHLUWf7PuheLtI8I654lvd K+LH/CsPiKPFnjz4j+OWm8DeG5W8c+L9Da50m1tLu38S3Vy99fQa145ktJ1ki6ez/ZC8caT4 k8CyaLF8NbDw94M+IHxe1HR3urxNcsPCfw2+IvjS78QWHhnwj8PdZ+FN5HoniHTdLFhb2Ov+ DfiR8PpPD91Jd2bHxTokSWV3+i9FOSUviScfaYirKK92M54r6r7e6hytQksKoQpwcadGhXxG Eowp4Or9XirtXabUuShCM370oRw0cTChy8/MnKEcS26k1OpVq0qGJrSqYqn7d/mnoH7JvxsO k6BpviW/+Flo3hLwH+zR8ONJbRPEXi3Ul1TS/gR8VofHGp69qLX/AII0o6ff+INHM8Nho1tH qFvZ6lHDa3GsSWsz6hB1Gg/skeIvDmprFoWh/Cbw7pVj+0J4/wDitBq+gzX2n6zr3hLxd4S+ J+i6HoGr6TZ+BbK2sL7wXc+NtN0zSrRNf1vTDosepXFnc6VJHBpN5+glFFRe1hVhU95VpYyd aWilUqY/HYLMsVN8qSTni8DRqRjBRhTjKrCnCMJ2Sp2pSUqaUeVUIwjrJQhhcuxOVUIR5m5O NPBYqrTvKUpykoVJylNNy/ID4gfsoeK/hR8MtEstG8L6Rr2n6t4J/Zz8GfEnRvAeieIfFT6/ 49+H/ijxDrfi34geIdAj+FvxIHiHRrmC60uyj1rWfhP8Tr6eBFsNU8A22nxQarpf2L+yTY+N dE8D6F4al+FSfCX4X6F4M0mHw3omutG3jrVPGN5r/ie68W63qMdrZ+F0stF1W3bR9atbLV/h v8PNfh1TWdTgn8MaVaWtvYW/11RWqqz5a6k1L22Nr43ayjLEU5wnSa2lThKfPh46Kgo04RTj Sp8mcqcW6PLeKpYahh97uX1fkUKib+GpOnBQryScqvNUlzR9tWVT4T8W/sx/FHxH8Rdb+Mlv 8RYLPxtY/GfwL4x8EeEftmnnwC/w+8EWcfhmHSfEGqyfDu58e6brupeFPEPxHe403Qtdm8KL rXiSOSe1vGa41JOIvf2UPi5f/bNA1M/DnU/Bml6f+03pmhNYeOvE/hzxL4ktv2hPHFp4sibW Zbj4W+K9H8Jv4etoZbC5gjsfiBYaq2Bd2c9hcXFif0jorBQUacaSb5Y0q9NNvmm3icBhstrV pykm6laWFwsFzVOZKpUq1FHmlFw2lLmqKpJJyVehXj0Ufq1XGVaNKEYtKNGDx+IhyRs5U5Rh KTUUfmFf/sV+PrnRteEeh/AJfFvir9m7UPhDP4l0vT4vBsvhDxcmoeMJNL1rQbfwn8KrKw1C 01Lw9ruh+FfEmsaTp3w/ma10WS7sfCn2GW08PWfWa/8Asi+N0+NXww8Z+BLb4P8AhHwP8Pk8 MGOLRNF0Hw34rMUWheLtI8daXcXum/CW88U69b+JLnxMNRt5J/inomgDF+up+Cb7WLqHxDbf ojRVTiqijGS92NV1lFXUXJ4rMcXyvq6arZpi/cbacHCEuaMWpQlZSV379GVBvZ8k8Jl+Ck0l aKl9Xy3Dxi1G0G6rgoupp+Zs37HnxYh8DWHh22vPhHq95B8IfgB8OdRsvEVtY67pV9c/DDxJ 4y1Txc9gfHXwj+Ivh7Szf6f4jtE8M+INS+H3ia6guorxZtA02Q22ox+hfs1fCHx98OPiNoWl eMDc3y/DL9mLwR8LrjxLZw6n/wAIp4g1i48feLNbhs9A1DUtJ0caofDHhzTtEtrk21qq6b/a sdnNFCWj837worSNSUatSqrc9TFYrGTur3q4vC5hhKiXWNOMMzxc6cE0o1J8zvqmpwjOLi7p PD4PDaO37vBYjL8RRbWqc75dQpzm/elTck3dQcCiiioKCiiigAooooAKKKKACiiigAooooAK KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK KKKACiiigD//2QIAQM5HBJC0CmUAAAAAAAAAAAAAAAA8AwAAAAECAADPRwSQtAplAAAAAAAA AAAAAAAAPQMAAAABAgAAIEgEkLQKZQAAAAAAAAAAAAAAAD4DAAAAAQIAwCBIBJC0CmUAAAAA AAAAAAAAAAA/AwAAAAECAIAhSASQtAplAAAAAAAAAAAAAAAAQAMAAAABAgBAIkgEkLQKZQAA AAAAAAAAAAAAAEEDAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAUEsDBBQABgAIAAAAIQA/hbhxQwIAACgLAAATAAAAcHB0L3RhYmxlU3R5bGVzLnht bORWUW/aMBB+n7T/YPk9DQmhZYhQAS3apG0PHeu7Eztg1bFR4hWqaf99l0tIUtRWZSNapT3h iPN93919d+fx5S5V5F5kuTQ6pN5ZjxKhY8OlXoX0+3LhDCnJLdOcKaNFSB9ETi8n79+N2chG 6pt9UOJzbgl40fmIhXRt7Wbkunm8FinLz8xGaPgvMVnKLHxmK5dnbAveU+X6vd65mzKpKeEi CenPwdz3B0EwdS6ur8+doB/4zqwXDJ3hYHY1/7C48ub96S86aWEDN2Dwib/6cnnhK0shli+C yx8pwSCITxwyjWOhLfEQYrs2SiwjhXDxcodmxUditL0RCZF8F9JUapOh/SbL7Vxl5J6pkEaK xXfUnYzd2r64imkRtRW/8yob2wawcY1l4xnPiptKJBZ/NdlCnfyLHlQqTjcQea5XSCA3SvKF VMj4AEnZPVLLCrgpjRT33jO5WncIU7u3ZtNdMJXzyFhr0u5gGv9S55KLj91BtQDK423XWAAA 6qjVl+xV9YLEGDZP2TtWQhthI0CPg1LLRqg1ic4fC7FEQMxK/HBut2AEM8jDHB+2BziHJvtj hsHfMGxYFSf/OX4HcTW2eB+r+eaiQlbI9Dl+T0WFtorBKDSPJyeJQmo0DqrTDdBmrL04QI9W SKXXRu0Q6pMKbUWayGIB/BdRt0MtMnBjtkUP1jX4l7VGIu310h96J92VuF5Q+tVqPmb0HCWs Kq2Y7beW4mb7KXyRnDrLe/+dJ7rJbgFVPWnL7de8bye/AQAA//8DAFBLAwQUAAYACAAAACEA wNHLSIABAAAtAwAAEQAAAHBwdC92aWV3UHJvcHMueG1sjJJNb8IwDIbvk/YfotyhH9o6VlG4 TDtxmATbPUrcEqlNoiRA4dfPbejajR24JbH9+H0dL9dtU5MjWCe1KmgyjykBxbWQqiro5+59 tqDEeaYEq7WCgp7B0fXq8WFp8qOE04clCFAuZwXde2/yKHJ8Dw1zc21AYazUtmEer7aKhGUn BDd1lMZxFjVMKnqtt/fU67KUHN40PzSgfIBYqJlH8W4vjRto5h6aseAQ01f/krRCc6qTXX/1 Frs75nptQWyg9MRdcFTPWRrTaBrbadOHXp+yrA9FtxxXSwEjlm9rMbmNR8dZDasly11L8GMW KSUCm8Y9F1/Pt6/Y7Vplcm1lJRVpCzpL4jSj5FzQNMk6vZjGxz7VAfVsnO989GeCpTgVHKC2 F0qMdn3l1WpICY+LxWByhHTwiaVO0m/DSntwO2j9KGGi5o/rJJjuVA+WJ08dPExp6hcXGL0O yn7YmPxP68pKsTWM41ISjsN6wb3EhedICMcwr2NYg28AAAD//wMAUEsDBBQABgAIAAAAIQDc MS/x8gEAAF4EAAARAAAAcHB0L3ByZXNQcm9wcy54bWysk82OmzAQgO+V+g7IdwcbCBAUsrLB kSq1qz20D+CCk1gyGNnOZquq717zk1WivewhXBiwZ+abz7B9eutU8CqMlbovAV4hEIi+0a3s jyX49XMPcxBYx/uWK92LEvwRFjztvn7ZDsVghBW9486nvpjAF+ptwUtwcm4owtA2J9Fxu9KD 6P3aQZuOO/9ojmFr+MU36FQYIZSGHZc9WPLNZ/L14SAbUevm3HmAuYgRaiKxJznYa7XhM9Vu 57hD2vkh7Ulf/HDj7ZkbM7XwnsC4tiSG0z7VEqWm0M9bKbPbcr/BOh8Gr1yVwIgW+PXQ5y0b hkK8ue/Wjfk+Cs5GluAvq3Ca0bqGOc4jmBCaQcKqCjKaoJjFhNI4+zf2x0mhuBVm7DDL968+ DNzJxmirD27V6C6czYWDvggzaDnJw2g+gZHYmuPvd+L9Hvlrhr5pNs3gee+xo31NoxRlEGd5 AhPGKKTZJocZo+s8Thmrc3LFHm3+EK3klTPKPgR+dowXwxOdN33168P5IBfmj9KztGKbhMAU xRVMcBJBuvEjpDWOM4QwItG79Fbahpv2W8ePgrXS1dzxB86wCB/Z7w3XMSYojQj0WglM4mgD yfidUErydZpGaI3R1XArDvys3MRYD/KBeFF0B3gv+fZXejG7/wAAAP//AwBQSwMEFAAGAAgA AAAhAM5tfidsAgAA1wUAABAACAFkb2NQcm9wcy9hcHAueG1sIKIEASigAAEAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAvFRLb9swDL4P2H8QfNoOjeMuLYpAUVGk KFpgWYzEzc6qRMfCHNGQlLTdrx9tx3ms6YDtMJ/IjzQfHyny65dVyTbgvEE7ipJeP2JgFWpj l6PoMbs7u4qYD9JqWaKFUfQKProWHz/w1GEFLhjwjEJYP4qKEKphHHtVwEr6HpktWXJ0KxlI dcsY89wouEW1XoEN8Xm/fxnDSwCrQZ9Vu4BRG3G4Cf8aVKOq6/OL7LWiggXPMMgyMysQfR7v Ff4dnfbiYnDJ41bkN1VVGiUD8SEmRjn0mAc2bSpnKT6DS9HYwONDR2IDPLXU/HbXdCym9swr B2DZvMBn9mkw/PKZxycceSqdXDpZFV4kF+fks9f5vDQaCE94vBX5NwxbpJX4vdEa7NZM/R3p fDIZl6bydeOdyOdKljAmhkQuSw8Uewfwe5D19FNpnBd8E4YbUAEd8+YnzX8QsSfpoeZ1FG2k M9IG4rd2a5VGLisfnMhoESg22Vq9EQ/dDmUzENQj+ZLwR8c2VtMty0wowf9Nindy1InbPin5 MQNtjmlOUwknCEnODxlpimv5aOvcLs4bKnakzKBCFxhaFgpgClcV8ehJxbxBFukV29AOINk0 KBawgR8WYza7m7CklzB6nTtsnKfsxqoCne8d8rLL92CDQ71W9YKfdKCEJ/EMfGAewro6aZ6B X5fhaBa7nP/b9pDO3qmR+KXTo5t3elTr0QL8NvJxPRT7KjL0hXmSPO4A/tXYH/6xyvBWBuje 0jHI54V0oOnodfY9wO/pGbmyDjIupF2C7nzeGurDtGjvtEgGvT59zQ3qsPq0dBdZ/AIAAP// AwBQSwMEFAAGAAgAAAAhAGbk19xrAQAAqgIAABEACAFkb2NQcm9wcy9jb3JlLnhtbCCiBAEo oAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIySXU/DIBiF7038 Dw33Lf1wOknbJWp25ZImzmi8I/BuIxZoANft30vbrXbRCy/hHB7OeyBfHGQd7MFYoVWBkihG ASimuVDbAr2ul+EcBdZRxWmtFRToCBYtyuurnDWEaQOV0Q0YJ8AGnqQsYU2Bds41BGPLdiCp jbxDeXGjjaTOL80WN5R90i3gNI5vsQRHOXUUd8CwGYnohORsRDZfpu4BnGGoQYJyFidRgn+8 Doy0fx7olYlTCnds/EynuFM2Z4M4ug9WjMa2baM262P4/Al+Xz2/9KOGQnVdMUBlzhlxwtVQ VroFU2mhXFAZsD4xdb7sHI+OzssMUKdNudI7KiXwXj5vdmXX1LqVf5eNAP5wnPh+a53dwF50 b1omWY6na39Z38NwI/DAT0aGHs7KW/b4tF6iMo2TNIzvwiRbx3OS3pDs9qPLdXG+m3TYkKd0 /yBmyTqekdk9mcUT4hlQ9okvf1f5DQAA//8DAFBLAQItABQABgAIAAAAIQA4Ozh/WAIAAJ8Y AAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAh AGj4dKEFAQAA4gIAAAsAAAAAAAAAAAAAAAAAkQQAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgA AAAhAMRG2VDZAAAAzgEAACAAAAAAAAAAAAAAAAAAxwcAAHBwdC9zbGlkZXMvX3JlbHMvc2xp ZGU0LnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhAK05BGDZAAAAzgEAACAAAAAAAAAAAAAAAAAA 3ggAAHBwdC9zbGlkZXMvX3JlbHMvc2xpZGUzLnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhACPz cKTXAAAAzgEAACAAAAAAAAAAAAAAAAAA9QkAAHBwdC9zbGlkZXMvX3JlbHMvc2xpZGUyLnht bC5yZWxzUEsBAi0AFAAGAAgAAAAhANgDgmvXAAAAzgEAACAAAAAAAAAAAAAAAAAACgsAAHBw dC9zbGlkZXMvX3JlbHMvc2xpZGUxLnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhAEqMrZTZAAAA zgEAACAAAAAAAAAAAAAAAAAAHwwAAHBwdC9zbGlkZXMvX3JlbHMvc2xpZGU1LnhtbC5yZWxz UEsBAi0AFAAGAAgAAAAhABcfNcfZAAAAzgEAACAAAAAAAAAAAAAAAAAANg0AAHBwdC9zbGlk ZXMvX3JlbHMvc2xpZGU3LnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhAPnlEZ50AQAAowkAAB8A AAAAAAAAAAAAAAAATQ4AAHBwdC9fcmVscy9wcmVzZW50YXRpb24ueG1sLnJlbHNQSwECLQAU AAYACAAAACEAfA0Z39kAAADPAQAAIQAAAAAAAAAAAAAAAAAGEQAAcHB0L3NsaWRlcy9fcmVs cy9zbGlkZTExLnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhAPLHbRvZAAAAzwEAACEAAAAAAAAA AAAAAAAAHhIAAHBwdC9zbGlkZXMvX3JlbHMvc2xpZGUxMC54bWwucmVsc1BLAQItABQABgAI AAAAIQDF4Y+m2QAAAM4BAAAgAAAAAAAAAAAAAAAAADYTAABwcHQvc2xpZGVzL19yZWxzL3Ns aWRlOS54bWwucmVsc1BLAQItABQABgAIAAAAIQBLK/ti2AAAAM4BAAAgAAAAAAAAAAAAAAAA AE0UAABwcHQvc2xpZGVzL19yZWxzL3NsaWRlOC54bWwucmVsc1BLAQItABQABgAIAAAAIQCZ 1UED2AAAAM4BAAAgAAAAAAAAAAAAAAAAAGMVAABwcHQvc2xpZGVzL19yZWxzL3NsaWRlNi54 bWwucmVsc1BLAQItABQABgAIAAAAIQD/vMOUmwIAAB0OAAAUAAAAAAAAAAAAAAAAAHkWAABw cHQvcHJlc2VudGF0aW9uLnhtbFBLAQItABQABgAIAAAAIQBmAegCaAMAAPQIAAAVAAAAAAAA AAAAAAAAAEYZAABwcHQvc2xpZGVzL3NsaWRlMS54bWxQSwECLQAUAAYACAAAACEA9ptZSIkD AAAACQAAFQAAAAAAAAAAAAAAAADhHAAAcHB0L3NsaWRlcy9zbGlkZTIueG1sUEsBAi0AFAAG AAgAAAAhAE/Xu1l0BAAASwsAABYAAAAAAAAAAAAAAAAAnSAAAHBwdC9zbGlkZXMvc2xpZGUx MS54bWxQSwECLQAUAAYACAAAACEAVxem6DwDAACjCAAAFQAAAAAAAAAAAAAAAABFJQAAcHB0 L3NsaWRlcy9zbGlkZTQueG1sUEsBAi0AFAAGAAgAAAAhAM09gQY9BgAAtjAAABUAAAAAAAAA AAAAAAAAtCgAAHBwdC9zbGlkZXMvc2xpZGU1LnhtbFBLAQItABQABgAIAAAAIQCv3HsHtwQA ALIMAAAVAAAAAAAAAAAAAAAAACQvAABwcHQvc2xpZGVzL3NsaWRlMy54bWxQSwECLQAUAAYA CAAAACEAfVu11AgGAAAXLQAAFQAAAAAAAAAAAAAAAAAONAAAcHB0L3NsaWRlcy9zbGlkZTcu eG1sUEsBAi0AFAAGAAgAAAAhAOBUP/+BAwAABggAABYAAAAAAAAAAAAAAAAASToAAHBwdC9z bGlkZXMvc2xpZGUxMC54bWxQSwECLQAUAAYACAAAACEArDUblEQGAAARMQAAFQAAAAAAAAAA AAAAAAD+PQAAcHB0L3NsaWRlcy9zbGlkZTYueG1sUEsBAi0AFAAGAAgAAAAhAFOXBLotBgAA nC0AABUAAAAAAAAAAAAAAAAAdUQAAHBwdC9zbGlkZXMvc2xpZGU4LnhtbFBLAQItABQABgAI AAAAIQBaoZ6jPwYAAJIuAAAVAAAAAAAAAAAAAAAAANVKAABwcHQvc2xpZGVzL3NsaWRlOS54 bWxQSwECLQAUAAYACAAAACEA1dGS8b4AAAA3AQAALAAAAAAAAAAAAAAAAABHUQAAcHB0L3Ns aWRlTGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDEueG1sLnJlbHNQSwECLQAUAAYACAAAACEA 1dGS8b4AAAA3AQAALAAAAAAAAAAAAAAAAABPUgAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9z bGlkZUxheW91dDUueG1sLnJlbHNQSwECLQAUAAYACAAAACEA1dGS8b4AAAA3AQAALAAAAAAA AAAAAAAAAABXUwAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDQueG1sLnJl bHNQSwECLQAUAAYACAAAACEA1dGS8b4AAAA3AQAALAAAAAAAAAAAAAAAAABfVAAAcHB0L3Ns aWRlTGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDMueG1sLnJlbHNQSwECLQAUAAYACAAAACEA 1dGS8b4AAAA3AQAALAAAAAAAAAAAAAAAAABnVQAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9z bGlkZUxheW91dDIueG1sLnJlbHNQSwECLQAUAAYACAAAACEA1nH6nNUAAADAAQAAKwAAAAAA AAAAAAAAAABvVgAAcHB0L25vdGVzU2xpZGVzL19yZWxzL25vdGVzU2xpZGUxMS54bWwucmVs c1BLAQItABQABgAIAAAAIQDV0ZLxvgAAADcBAAAsAAAAAAAAAAAAAAAAAI1XAABwcHQvc2xp ZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0Ni54bWwucmVsc1BLAQItABQABgAIAAAAIQDV 0ZLxvgAAADcBAAAsAAAAAAAAAAAAAAAAAJVYAABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3Ns aWRlTGF5b3V0OC54bWwucmVsc1BLAQItABQABgAIAAAAIQAj0KgJ1QAAAL8BAAAqAAAAAAAA AAAAAAAAAJ1ZAABwcHQvbm90ZXNTbGlkZXMvX3JlbHMvbm90ZXNTbGlkZTYueG1sLnJlbHNQ SwECLQAUAAYACAAAACEArRrczdUAAAC/AQAAKgAAAAAAAAAAAAAAAAC6WgAAcHB0L25vdGVz U2xpZGVzL19yZWxzL25vdGVzU2xpZGU3LnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhAPEuEmjV AAAAvwEAACoAAAAAAAAAAAAAAAAA11sAAHBwdC9ub3Rlc1NsaWRlcy9fcmVscy9ub3Rlc1Ns aWRlOC54bWwucmVsc1BLAQItABQABgAIAAAAIQB/5Gas1QAAAL8BAAAqAAAAAAAAAAAAAAAA APRcAABwcHQvbm90ZXNTbGlkZXMvX3JlbHMvbm90ZXNTbGlkZTkueG1sLnJlbHNQSwECLQAU AAYACAAAACEAWLuOWNUAAADAAQAAKwAAAAAAAAAAAAAAAAARXgAAcHB0L25vdGVzU2xpZGVz L19yZWxzL25vdGVzU2xpZGUxMC54bWwucmVsc1BLAQItABQABgAIAAAAIQDwiUSe1QAAAL8B AAAqAAAAAAAAAAAAAAAAAC9fAABwcHQvbm90ZXNTbGlkZXMvX3JlbHMvbm90ZXNTbGlkZTUu eG1sLnJlbHNQSwECLQAUAAYACAAAACEAfkMwWtUAAAC/AQAAKgAAAAAAAAAAAAAAAABMYAAA cHB0L25vdGVzU2xpZGVzL19yZWxzL25vdGVzU2xpZGU0LnhtbC5yZWxzUEsBAi0AFAAGAAgA AAAhABc87WrVAAAAvwEAACoAAAAAAAAAAAAAAAAAaWEAAHBwdC9ub3Rlc1NsaWRlcy9fcmVs cy9ub3Rlc1NsaWRlMy54bWwucmVsc1BLAQItABQABgAIAAAAIQDV0ZLxvgAAADcBAAAsAAAA AAAAAAAAAAAAAIZiAABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0OS54bWwu cmVsc1BLAQItABQABgAIAAAAIQDV0ZLxvgAAADcBAAAtAAAAAAAAAAAAAAAAAI5jAABwcHQv c2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0MTAueG1sLnJlbHNQSwECLQAUAAYACAAA ACEA1dGS8b4AAAA3AQAALQAAAAAAAAAAAAAAAACXZAAAcHB0L3NsaWRlTGF5b3V0cy9fcmVs cy9zbGlkZUxheW91dDExLnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhAEqvdTnUAAAAvwEAACoA AAAAAAAAAAAAAAAAoGUAAHBwdC9ub3Rlc1NsaWRlcy9fcmVscy9ub3Rlc1NsaWRlMS54bWwu cmVsc1BLAQItABQABgAIAAAAIQCZ9pmu1QAAAL8BAAAqAAAAAAAAAAAAAAAAALxmAABwcHQv bm90ZXNTbGlkZXMvX3JlbHMvbm90ZXNTbGlkZTIueG1sLnJlbHNQSwECLQAUAAYACAAAACEA 1dGS8b4AAAA3AQAALAAAAAAAAAAAAAAAAADZZwAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9z bGlkZUxheW91dDcueG1sLnJlbHNQSwECLQAUAAYACAAAACEA1SCVWQ4IAADaLwAAIQAAAAAA AAAAAAAAAADhaAAAcHB0L3NsaWRlTWFzdGVycy9zbGlkZU1hc3RlcjEueG1sUEsBAi0AFAAG AAgAAAAhADJ9mn2oBAAACREAACEAAAAAAAAAAAAAAAAALnEAAHBwdC9zbGlkZUxheW91dHMv c2xpZGVMYXlvdXQxLnhtbFBLAQItABQABgAIAAAAIQCuKONPEAUAADUSAAAhAAAAAAAAAAAA AAAAABV2AABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0OS54bWxQSwECLQAUAAYACAAA ACEAxQWWo9YDAADRCwAAIgAAAAAAAAAAAAAAAABkewAAcHB0L3NsaWRlTGF5b3V0cy9zbGlk ZUxheW91dDEwLnhtbFBLAQItABQABgAIAAAAIQBWAddoIQQAALAMAAAiAAAAAAAAAAAAAAAA AHp/AABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0MTEueG1sUEsBAi0AFAAGAAgAAAAh AGmiXyEeAQAAxwcAACwAAAAAAAAAAAAAAAAA24MAAHBwdC9zbGlkZU1hc3RlcnMvX3JlbHMv c2xpZGVNYXN0ZXIxLnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhAL2sJG++AgAAXgYAAB8AAAAA AAAAAAAAAAAAQ4UAAHBwdC9ub3Rlc1NsaWRlcy9ub3Rlc1NsaWRlMi54bWxQSwECLQAUAAYA CAAAACEAiiAZmGEFAADFEgAAIQAAAAAAAAAAAAAAAAA+iAAAcHB0L3NsaWRlTGF5b3V0cy9z bGlkZUxheW91dDgueG1sUEsBAi0AFAAGAAgAAAAhAPqWITIQAwAAawcAACEAAAAAAAAAAAAA AAAA3o0AAHBwdC9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQ3LnhtbFBLAQItABQABgAIAAAA IQBmsGg7TAMAALwIAAAhAAAAAAAAAAAAAAAAAC2RAABwcHQvc2xpZGVMYXlvdXRzL3NsaWRl TGF5b3V0Ni54bWxQSwECLQAUAAYACAAAACEARP2u+LwDAACaCwAAIQAAAAAAAAAAAAAAAAC4 lAAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDIueG1sUEsBAi0AFAAGAAgAAAAhACAA uXb0BAAAXREAACEAAAAAAAAAAAAAAAAAs5gAAHBwdC9zbGlkZUxheW91dHMvc2xpZGVMYXlv dXQzLnhtbFBLAQItABQABgAIAAAAIQAxZ2mbfwQAAGwSAAAhAAAAAAAAAAAAAAAAAOadAABw cHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0NC54bWxQSwECLQAUAAYACAAAACEA4zz00uMF AAA7HAAAIQAAAAAAAAAAAAAAAACkogAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDUu eG1sUEsBAi0AFAAGAAgAAAAhALHqNgu/AgAAXQYAAB8AAAAAAAAAAAAAAAAAxqgAAHBwdC9u b3Rlc1NsaWRlcy9ub3Rlc1NsaWRlMy54bWxQSwECLQAUAAYACAAAACEAckBbJb8CAABeBgAA HwAAAAAAAAAAAAAAAADCqwAAcHB0L25vdGVzU2xpZGVzL25vdGVzU2xpZGUxLnhtbFBLAQIt ABQABgAIAAAAIQBx8PK5wAIAAF4GAAAfAAAAAAAAAAAAAAAAAL6uAABwcHQvbm90ZXNTbGlk ZXMvbm90ZXNTbGlkZTUueG1sUEsBAi0AFAAGAAgAAAAhAIUDH66+AgAAXgYAAB8AAAAAAAAA AAAAAAAAu7EAAHBwdC9ub3Rlc1NsaWRlcy9ub3Rlc1NsaWRlNC54bWxQSwECLQAUAAYACAAA ACEAqrYffMECAABfBgAAIAAAAAAAAAAAAAAAAAC2tAAAcHB0L25vdGVzU2xpZGVzL25vdGVz U2xpZGUxMC54bWxQSwECLQAUAAYACAAAACEA+QrvyL8CAABeBgAAHwAAAAAAAAAAAAAAAAC1 twAAcHB0L25vdGVzU2xpZGVzL25vdGVzU2xpZGU5LnhtbFBLAQItABQABgAIAAAAIQB2vjvF wAIAAF4GAAAfAAAAAAAAAAAAAAAAALG6AABwcHQvbm90ZXNTbGlkZXMvbm90ZXNTbGlkZTgu eG1sUEsBAi0AFAAGAAgAAAAhAAZCuA3BAgAAXgYAACAAAAAAAAAAAAAAAAAArr0AAHBwdC9u b3Rlc1NsaWRlcy9ub3Rlc1NsaWRlMTEueG1sUEsBAi0AFAAGAAgAAAAhAMkTYse+AgAAXAYA AB8AAAAAAAAAAAAAAAAArcAAAHBwdC9ub3Rlc1NsaWRlcy9ub3Rlc1NsaWRlNy54bWxQSwEC LQAUAAYACAAAACEAsHxhEcACAABeBgAAHwAAAAAAAAAAAAAAAACowwAAcHB0L25vdGVzU2xp ZGVzL25vdGVzU2xpZGU2LnhtbFBLAQItABQABgAIAAAAIQC5f+5zlgYAALAbAAAUAAAAAAAA AAAAAAAAAKXGAABwcHQvdGhlbWUvdGhlbWUxLnhtbFBLAQItABQABgAIAAAAIQBpCeINZAYA AM4dAAAhAAAAAAAAAAAAAAAAAG3NAABwcHQvbm90ZXNNYXN0ZXJzL25vdGVzTWFzdGVyMS54 bWxQSwECLQAUAAYACAAAACEAtM9YGbsAAAAkAQAALAAAAAAAAAAAAAAAAAAQ1AAAcHB0L25v dGVzTWFzdGVycy9fcmVscy9ub3Rlc01hc3RlcjEueG1sLnJlbHNQSwECLQAUAAYACAAAACEA uX/uc5YGAACwGwAAFAAAAAAAAAAAAAAAAAAV1QAAcHB0L3RoZW1lL3RoZW1lMi54bWxQSwEC LQAKAAAAAAAAACEAGpET0ACAAAAAgAAAFwAAAAAAAAAAAAAAAADd2wAAZG9jUHJvcHMvdGh1 bWJuYWlsLmpwZWdQSwECLQAUAAYACAAAACEAP4W4cUMCAAAoCwAAEwAAAAAAAAAAAAAAAAAS XAEAcHB0L3RhYmxlU3R5bGVzLnhtbFBLAQItABQABgAIAAAAIQDA0ctIgAEAAC0DAAARAAAA AAAAAAAAAAAAAIZeAQBwcHQvdmlld1Byb3BzLnhtbFBLAQItABQABgAIAAAAIQDcMS/x8gEA AF4EAAARAAAAAAAAAAAAAAAAADVgAQBwcHQvcHJlc1Byb3BzLnhtbFBLAQItABQABgAIAAAA IQDObX4nbAIAANcFAAAQAAAAAAAAAAAAAAAAAFZiAQBkb2NQcm9wcy9hcHAueG1sUEsBAi0A FAAGAAgAAAAhAGbk19xrAQAAqgIAABEAAAAAAAAAAAAAAAAA+GUBAGRvY1Byb3BzL2NvcmUu eG1sUEsFBgAAAABSAFIAARkAAJpoAQAAAA== --------------080305030808040409060505-- From fluffy@cisco.com Mon Aug 6 09:43:04 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89A6721E805E for ; Mon, 6 Aug 2012 09:43:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.406 X-Spam-Level: X-Spam-Status: No, score=-110.406 tagged_above=-999 required=5 tests=[AWL=0.193, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wg8cKmltwJfx for ; Mon, 6 Aug 2012 09:43:03 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id E70FF21E8044 for ; Mon, 6 Aug 2012 09:43:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=294; q=dns/txt; s=iport; t=1344271383; x=1345480983; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=2B3WUTLy+S36GdmnMHJHtibB3fDzqaAhjLquryugqKk=; b=bjUDSNZZspI3K6tDBD+mCiRoueAmt8XZQA35n41nkpYQOAYg5SLu5DET kyQJggxBwMcA0KVZrTznYuaD5Xxwro203jrz3m9+zTaFLmjv0hjMG1wg9 mGcFjtvFVoGSLBEyh4d9uzy0rX9SUAHLNaaPy0rStJ0O3oElC7op4Ts6W c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAGAETzH1CtJXG+/2dsb2JhbAAkIYU0tBKBB4InEgEnUQE+QicEATSHawubK6AOkW5gA5VJgRSNEoFmgl8 X-IronPort-AV: E=Sophos;i="4.77,720,1336348800"; d="scan'208";a="108646770" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-1.cisco.com with ESMTP; 06 Aug 2012 16:43:02 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id q76Gh23U000728 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 6 Aug 2012 16:43:02 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.72]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0298.004; Mon, 6 Aug 2012 11:43:02 -0500 From: "Cullen Jennings (fluffy)" To: "public-webrtc@w3.org" , "rtcweb@ietf.org" Thread-Topic: Microsoft tells W3C and IETF what we are doing no signs of offering real world interoperability Thread-Index: AQHNc/KKtNgifpdI6EiCHb2fk+96dQ== Date: Mon, 6 Aug 2012 16:43:01 +0000 Message-ID: <53223349-A31F-4381-899F-82E29B0A0B6C@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.167] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19088.004 x-tm-as-result: No--20.316000-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <253C7FF8E6DD9A4793E8E186DE81F982@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [rtcweb] Microsoft tells W3C and IETF what we are doing no signs of offering real world interoperability X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 06 Aug 2012 16:43:04 -0000 I see that Microsoft decided to wait until the W3C and IETF were close to d= one before putting together a proposal that, if accepted, would explode mos= t the current works and create maximal delay on this work.=20 http://blogs.skype.com/en/2012/08/customizable_ubiquitous_real_t.html From ldecicco@gmail.com Mon Aug 6 10:16:50 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAF3F21E8044 for ; Mon, 6 Aug 2012 10:16:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iv6RV0VeP5sD for ; Mon, 6 Aug 2012 10:16:50 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id E731111E8098 for ; Mon, 6 Aug 2012 10:16:49 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so4117289pbb.31 for ; Mon, 06 Aug 2012 10:16:49 -0700 (PDT) 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=9VuwQh7SC6sceckBbGgykfFc9IMruOjtx3ynzZm6NOs=; b=lstfW2iDL+VOz3SBsGpq1gGR/QD/BH+mIM26YqHwPNcnEu9JcTr4DncOjFEIocGEoC vf/54yXhhu3IxPNu5rU1Vcjm+f2UeqGru+Fi8j+kI81RDRuSd2HD4lWYhhwvJhxyuODY RbgkeM3605QgX/7ZhPOi+6UDkSvfHU6EI1tMZK6sSTd8aQrngO+wqCWeOG5vAj9S04/k Y8TXzgfG1oJOUy1qHgrQC1I+Tw+qOOStEJQRnICbC8XBc1KRYrvJZ6ePkK10CG1gnnj9 XWjtf/seKMEWNeHExZlM94BaZRuvUoY67kZMS9/83Kil/Dm9M6bMjZSsefLlU4m0kHcX Q90w== MIME-Version: 1.0 Received: by 10.68.234.70 with SMTP id uc6mr20440726pbc.44.1344273409455; Mon, 06 Aug 2012 10:16:49 -0700 (PDT) Received: by 10.68.197.193 with HTTP; Mon, 6 Aug 2012 10:16:49 -0700 (PDT) In-Reply-To: <53223349-A31F-4381-899F-82E29B0A0B6C@cisco.com> References: <53223349-A31F-4381-899F-82E29B0A0B6C@cisco.com> Date: Mon, 6 Aug 2012 19:16:49 +0200 Message-ID: From: Luca De Cicco To: "Cullen Jennings (fluffy)" Content-Type: multipart/alternative; boundary=047d7b33d6da0d35a604c69c0bda Cc: "rtcweb@ietf.org" , "public-webrtc@w3.org" Subject: Re: [rtcweb] Microsoft tells W3C and IETF what we are doing no signs of offering real world interoperability X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 06 Aug 2012 17:16:51 -0000 --047d7b33d6da0d35a604c69c0bda Content-Type: text/plain; charset=ISO-8859-1 I think that the proposed "customizable response to changing network quality" is a good idea. Wiring the adaptation logic into webrtc would make it less flexible to different needs in particular applications. Of course a default adaptation logic should be implemented in the browser. Cheers, -- Luca De Cicco, PhD Politecnico di Bari Dipartimento di Elettrotecnica ed Elettronica Via Re David, 200 - Bari - ITALY Office: +39 080 596 3851 On Mon, Aug 6, 2012 at 6:43 PM, Cullen Jennings (fluffy) wrote: > > I see that Microsoft decided to wait until the W3C and IETF were close to > done before putting together a proposal that, if accepted, would explode > most the current works and create maximal delay on this work. > > http://blogs.skype.com/en/2012/08/customizable_ubiquitous_real_t.html > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --047d7b33d6da0d35a604c69c0bda Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I think that the pr= oposed "customizable response to changing network quality" is a g= ood idea.=A0
Wiring the adaptati= on logic into webrtc would make it less flexible to different needs in part= icular
applications. Of co= urse a default adaptation=A0logic should be implemented in the browser.

<= /div>
Cheers,=
--
Luca De Cicco, PhD
Politecnico di Bari
Dipartimento di Elet= trotecnica ed Elettronica
Via Re David, 200 - Bari - ITALY
Office: +39 080 596 3851


On Mon, Aug 6, 2012 at 6:43 PM, Cullen J= ennings (fluffy) <fluffy@cisco.com> wrote:

I see that Microsoft decided to wait until the W3C and IETF were close to d= one before putting together a proposal that, if accepted, would explode mos= t the current works and create maximal delay on this work.

http://blogs.skype.com/en/2012/08/customizable_ubi= quitous_real_t.html



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

--047d7b33d6da0d35a604c69c0bda-- From rohit.puri@tenhands.net Mon Aug 6 12:27:33 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C18BF21E8088 for ; Mon, 6 Aug 2012 12:27:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eN-umUmT3xM2 for ; Mon, 6 Aug 2012 12:27:32 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id A225721E808A for ; Mon, 6 Aug 2012 12:27:32 -0700 (PDT) Received: by yenm5 with SMTP id m5so1053640yen.31 for ; Mon, 06 Aug 2012 12:27:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=02Q1umjCvxSs7XahA8D70zHbcffoo0rldHuWzmOCPas=; b=KtJmAwxTKmnPUuZCpg5T4zJ1yS6t0Vdo0b1W4xPMZfGAG9LwTZ4SOWRfOUNlOuS5k+ fZU3IYVJBQBVeuESO4brBvRICVy2STSweeFWkns9jf6A6Gq7JJRj5nXpvZdvPqHt6Afo ZRhY+jbqkTTEeG7/z3ARgIaBXljWCUDNTIRm15wOOsoS2NiwxZlRPm2zqD0sZzbjOAYa 1Oq9LUAqFWI6O9QtLJNWRLhZslZA6WIZ7OCAJdT8AnDoPSZot3XkKWeVmRMgMbrhK5B+ x2xCc4q6uUqLG4hdQBmfaULWRdJWJqFZlpkpnPRwyAi2fjzoMKE+l4gH1L3ds6x5fYZJ iNLw== MIME-Version: 1.0 Received: by 10.60.3.42 with SMTP id 10mr20768947oez.5.1344281252070; Mon, 06 Aug 2012 12:27:32 -0700 (PDT) Received: by 10.76.143.38 with HTTP; Mon, 6 Aug 2012 12:27:32 -0700 (PDT) In-Reply-To: References: <53223349-A31F-4381-899F-82E29B0A0B6C@cisco.com> Date: Mon, 6 Aug 2012 12:27:32 -0700 Message-ID: From: Rohit Puri To: Luca De Cicco Content-Type: multipart/alternative; boundary=e89a8fb1ff1482043704c69ddef6 X-Gm-Message-State: ALoCoQmqLR/gOOSfieITs5s3opFNW0MaqNcgZVHr4b0QIr/6WVBK7wNeoJ7TFHjjNmN/cXJ00TEL Cc: "Cullen Jennings \(fluffy\)" , "rtcweb@ietf.org" , "public-webrtc@w3.org" Subject: Re: [rtcweb] Microsoft tells W3C and IETF what we are doing no signs of offering real world interoperability X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 06 Aug 2012 19:27:34 -0000 --e89a8fb1ff1482043704c69ddef6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Based on our experiences at TenHands Inc. where we are trying to build a RT video-centric collaboration service, the goal cited in MSFT proposal ( http://html5labs.com/cu-rtc-web/cu-rtc-web.htm), namely: "*Flexibility in its support of popular media formats and codecs as well as openness to future innovation*=97A successful standard cannot be tied to individual codecs, data formats or scenarios. They may soon be supplanted by newer versions, which would make such a tightly coupled standard obsolete just as quickly. The right approach is instead to to support multiple media formats and to bring the bulk of the logic to the application layer, enabling developers to innovate. " sounds like a great idea. I have not gone through the MSFT proposal yet and do not consider myself to be a browser expert, but if it were possible to have flexibility in the webRTC framework to the extent that a client developer could use their own "algorithms" in the media pipeline, that would be awesome. Concretely, some algorithms that come to mind include (a) pre-processing of captured media (b) any choice of codecs (b) bandwidth adaptation (c) post-processing of decoded media (d) CPU adaptation. There is probably many more. On Mon, Aug 6, 2012 at 10:16 AM, Luca De Cicco wrote: > I think that the proposed "customizable response to changing network > quality" is a good idea. > Wiring the adaptation logic into webrtc would make it less flexible to > different needs in particular > applications. Of course a default adaptation logic should be implemented > in the browser. > > Cheers, > -- > Luca De Cicco, PhD > Politecnico di Bari > Dipartimento di Elettrotecnica ed Elettronica > Via Re David, 200 - Bari - ITALY > Office: +39 080 596 3851 > > > > On Mon, Aug 6, 2012 at 6:43 PM, Cullen Jennings (fluffy) > wrote: > >> >> I see that Microsoft decided to wait until the W3C and IETF were close t= o >> done before putting together a proposal that, if accepted, would explode >> most the current works and create maximal delay on this work. >> >> http://blogs.skype.com/en/2012/08/customizable_ubiquitous_real_t.html >> >> >> >> _______________________________________________ >> 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 > > --=20 Thanks and best regards, Rohit Puri (rohit.puri@tenhands.net) Software Development, TenHands Inc. (www.tenhands.net) My TenHands URL: http://tenhands.net/rohit.puri@tenhands.net --e89a8fb1ff1482043704c69ddef6 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Based on our experiences at TenHands Inc. where we are trying to build a RT= video-centric collaboration service, the goal cited in MSFT proposal (http://html5labs.com= /cu-rtc-web/cu-rtc-web.htm), namely:

"Flexibility in its support of popular media formats and codecs= as=20 well as openness to future innovation=97A successful standard cannot = be=20 tied to individual codecs, data formats or scenarios. They may soon be=20 supplanted by newer versions, which would make such a tightly coupled sta= ndard=20 obsolete just as quickly. The right approach is instead to to support mul= tiple=20 media formats and to bring the bulk of the logic to the application layer= ,=20 enabling developers to innovate. "

sounds like a great idea. =

I have not gone through the MSFT proposal yet and do not consider m= yself to be a browser expert, but if it were possible to have flexibility i= n the webRTC framework to the extent that a client developer could use thei= r own "algorithms" in the media pipeline, that would be awesome. = Concretely, some algorithms that come to mind include (a) pre-processing of= captured media (b) any choice of codecs (b) bandwidth adaptation (c) post-= processing of decoded media (d) CPU adaptation.=A0 There is probably many m= ore.



On Mon, Aug 6, 2012 at 10:16 AM, Luc= a De Cicco <ldecicco@gmail.com> wrote:
I think that the pr= oposed "customizable response to changing network quality" is a g= ood idea.=A0
Wiring the adaptati= on logic into webrtc would make it less flexible to different needs in part= icular
applications. Of co= urse a default adaptation=A0logic should be implemented in the browser.

<= /div>
Cheers,=
--
Luca De Cicco, PhD
Politecnico di Bari
Dipartimento di Elet= trotecnica ed Elettronica
Via Re David, 200 - Bari - ITALY
Office: +39 080 596 3851



On Mon, Aug 6, 2012 at 6:43 PM, Cullen J= ennings (fluffy) <fluffy@cisco.com> wrote:

I see that Microsoft decided to wait until the W3C and IETF were close to d= one before putting together a proposal that, if accepted, would explode mos= t the current works and create maximal delay on this work.

http://blogs.skype.com/en/2012/08/customizable_ubi= quitous_real_t.html



_______________________________________________
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




--
Thanks and bes= t regards,

Rohit Puri=A0(rohit.puri@tenhands.net)
Software De= velopment, TenHands Inc. (www.tenhands.net)
My TenHands URL:=A0http://tenhands.net/rohit.puri@tenhands.net
--e89a8fb1ff1482043704c69ddef6-- From harald@alvestrand.no Mon Aug 6 12:43:52 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B6A421F8470 for ; Mon, 6 Aug 2012 12:43:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vqUYhJWnV0DW for ; Mon, 6 Aug 2012 12:43:50 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 7F4C021F846F for ; Mon, 6 Aug 2012 12:43:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1C8E639E0FA for ; Mon, 6 Aug 2012 21:43:48 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iukSn-qotTBa for ; Mon, 6 Aug 2012 21:43:45 +0200 (CEST) Received: from [192.168.1.107] (unknown [188.113.88.47]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id C99D739E062 for ; Mon, 6 Aug 2012 21:43:45 +0200 (CEST) Message-ID: <50201E78.3060602@alvestrand.no> Date: Mon, 06 Aug 2012 21:43:52 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <53223349-A31F-4381-899F-82E29B0A0B6C@cisco.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------070203080905090407040901" Subject: Re: [rtcweb] Microsoft tells W3C and IETF what we are doing no signs of offering real world interoperability X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 06 Aug 2012 19:43:52 -0000 This is a multi-part message in MIME format. --------------070203080905090407040901 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 08/06/2012 09:27 PM, Rohit Puri wrote: > Based on our experiences at TenHands Inc. where we are trying to build > a RT video-centric collaboration service, the goal cited in MSFT > proposal (http://html5labs.com/cu-rtc-web/cu-rtc-web.htm), namely: > > "*Flexibility in its support of popular media formats and codecs as > well as openness to future innovation*---A successful standard cannot > be tied to individual codecs, data formats or scenarios. They may soon > be supplanted by newer versions, which would make such a tightly > coupled standard obsolete just as quickly. The right approach is > instead to to support multiple media formats and to bring the bulk of > the logic to the application layer, enabling developers to innovate. " > > sounds like a great idea. The WG agrees with you that multiple codecs should be supported, but the WG long ago came to consensus that there needs to be a mandatory-to-implement codec to prevent interoperability failure. That consensus has been rough at times, but I believe it is still the consensus. See section 2.3 of draft-ietf-rtcweb-overview. --------------070203080905090407040901 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 08/06/2012 09:27 PM, Rohit Puri wrote:
Based on our experiences at TenHands Inc. where we are trying to build a RT video-centric collaboration service, the goal cited in MSFT proposal (http://html5labs.com/cu-rtc-web/cu-rtc-web.htm), namely:

"Flexibility in its support of popular media formats and codecs as well as openness to future innovation—A successful standard cannot be tied to individual codecs, data formats or scenarios. They may soon be supplanted by newer versions, which would make such a tightly coupled standard obsolete just as quickly. The right approach is instead to to support multiple media formats and to bring the bulk of the logic to the application layer, enabling developers to innovate. "

sounds like a great idea.
The WG agrees with you that multiple codecs should be supported, but the WG long ago came to consensus that there needs to be a mandatory-to-implement codec to prevent interoperability failure.
That consensus has been rough at times, but I believe it is still the consensus.

See section 2.3 of draft-ietf-rtcweb-overview.


--------------070203080905090407040901-- From fluffy@cisco.com Mon Aug 6 13:00:42 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F298E21F84D3 for ; Mon, 6 Aug 2012 13:00:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.467 X-Spam-Level: X-Spam-Status: No, score=-110.467 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VGpBHfsxaPqx for ; Mon, 6 Aug 2012 13:00:40 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 482EA21F8493 for ; Mon, 6 Aug 2012 13:00:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=1063; q=dns/txt; s=iport; t=1344283239; x=1345492839; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=SJLA4AyPmRXafBHjC1POho2ST6O2vLNHFMebO9ondDg=; b=S3pEdBdUwHCR1NsoirBw4GwpYMzKCiHxqDqixGS2b5dBjAz5yBO1xflD TTzi0QDON/65lcdMOT9WwudeVRdbJh9uxVxybyxhsxue9haq7uL9WDr8X Qtk2gMI4iQNQC5VAojOrNsvYJ2bJlasvRHoBSZb/+b3UZlFFEll+On8kc A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj4FAOshIFCtJXG8/2dsb2JhbABFtW6DWoEHgiABAQEDARIBZgULAgEIOwsyJQIEDieHZQYLmnegH4tKhiRgA5VJgRSNEoFmgl8 X-IronPort-AV: E=Sophos;i="4.77,720,1336348800"; d="scan'208";a="108708839" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-1.cisco.com with ESMTP; 06 Aug 2012 20:00:38 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id q76K0ccn025004 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 6 Aug 2012 20:00:38 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.72]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0298.004; Mon, 6 Aug 2012 15:00:38 -0500 From: "Cullen Jennings (fluffy)" To: Rohit Puri Thread-Topic: [rtcweb] Microsoft tells W3C and IETF what we are doing no signs of offering real world interoperability Thread-Index: AQHNdAmGDrNTZRUPr0+8joeDXihPyJdNiAmA Date: Mon, 6 Aug 2012 20:00:37 +0000 Message-ID: References: <53223349-A31F-4381-899F-82E29B0A0B6C@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.167] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19088.004 x-tm-as-result: No--18.677400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="Windows-1252" Content-ID: <828A1E58E8DCCD48AFC98E35C6153032@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" , "public-webrtc@w3.org" Subject: Re: [rtcweb] Microsoft tells W3C and IETF what we are doing no signs of offering real world interoperability X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 06 Aug 2012 20:00:42 -0000 On Aug 6, 2012, at 1:27 PM, Rohit Puri wrote: > Based on our experiences at TenHands Inc. where we are trying to build a = RT video-centric collaboration service, the goal cited in MSFT proposal (ht= tp://html5labs.com/cu-rtc-web/cu-rtc-web.htm), namely: >=20 > "Flexibility in its support of popular media formats and codecs as well a= s openness to future innovation=97A successful standard cannot be tied to i= ndividual codecs, data formats or scenarios. They may soon be supplanted by= newer versions, which would make such a tightly coupled standard obsolete = just as quickly. The right approach is instead to to support multiple media= formats and to bring the bulk of the logic to the application layer, enabl= ing developers to innovate. " >=20 > sounds like a great idea.=20 and every proposal from any company or individual that I can recall being s= ent to theses WGs has had exactly that property. So it is sort of disappoin= ting to see Microsoft present it as if their proposal was somehow different= in this regards. = From juberti@google.com Mon Aug 6 13:20:06 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2698A11E80A6 for ; Mon, 6 Aug 2012 13:20:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.719 X-Spam-Level: X-Spam-Status: No, score=-102.719 tagged_above=-999 required=5 tests=[AWL=0.257, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uffN2i+S1BCr for ; Mon, 6 Aug 2012 13:20:05 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id C61A511E80A5 for ; Mon, 6 Aug 2012 13:20:04 -0700 (PDT) Received: by qcac10 with SMTP id c10so2321476qca.31 for ; Mon, 06 Aug 2012 13:20:04 -0700 (PDT) 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:x-system-of-record; bh=6IKShilgXVHsg85VVpt/k/4z0kqhCDiGFqljo5/jzhw=; b=eK2a5CfGyhZIQ8OYKNcGqQufdH7rH9A20to+fLZH99V0TqR5M19F9U2y9dxEs5+b/t yMrr1qtusymwwk7HnYlpiVcZ1pj5b0oj0K5h4wlrrgg0c4+dRvs5VwoN2XCKMeDrjNWU vfP7qvDPPxzQ4JhsAkQ5jPmQ4k9IMs5Au+pvAov4lPP9lqMwon4f7w0kzieshy0O8HU+ Fc7yfWZX1+HISFRXGsZ0Xsf3+ofjoLedMsXre0cSX5dCtPuLEHbIjmHRRvhF3VPDA8Pb aX9e6rAM0wjLH0oJIxqltN6YPowESuA33uJ2SB+BhhldFZy9uz9dx4JZyM2gXuWaPcHf u97g== X-Google-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:x-system-of-record:x-gm-message-state; bh=6IKShilgXVHsg85VVpt/k/4z0kqhCDiGFqljo5/jzhw=; b=nZCbMhRQG+SkXBA656h/JzV6+KJpCJfYmV75hdNVKOZEVtfkK16WSuDrHi1gDBeM0u Cc1p5Y66iZDMhcUN+mIjeM7v3kqOAllNLYzHrL+s30Z8sROik92nCYeLV/ZOFW0153Ph y5xTwXnuxf4TRvCL7M2HVa4xRuQ2buKakQZOSYSRBMQVzjiEHWCsGy+9X28h9EKHBGDC OO/I5raPCfIdyVsSNIBk/zoSfbmDs2C/TmTinakHmaUdSG9MWYfEcD4q1lz5sO2trzbp qPclpqAmQsiP/xAvYS+GjYrBgk3EAzFN91+eF/xHVDDRt44HYH2lkwmtIFP6fazeWvHi SD5Q== Received: by 10.224.180.146 with SMTP id bu18mr20066044qab.10.1344284404230; Mon, 06 Aug 2012 13:20:04 -0700 (PDT) Received: by 10.224.180.146 with SMTP id bu18mr20066031qab.10.1344284404113; Mon, 06 Aug 2012 13:20:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.218.80 with HTTP; Mon, 6 Aug 2012 13:19:43 -0700 (PDT) In-Reply-To: References: <53223349-A31F-4381-899F-82E29B0A0B6C@cisco.com> From: Justin Uberti Date: Mon, 6 Aug 2012 22:19:43 +0200 Message-ID: To: "Cullen Jennings (fluffy)" Content-Type: multipart/alternative; boundary=485b397dcfcd6260fc04c69e9aed X-System-Of-Record: true X-Gm-Message-State: ALoCoQn5b3E8W0hgpmYSk0CYFQkeYteV8vUoFgKzCzTGrYPKZsUGxI6RxNAMDs0Ydxaqltu9/dHHAtRRJ4zr3XeVIMRS+Khz6DXl5isGQaHDUlu6BE14dhXpSu1dJJeqJsEqw+nYDOHB9J9h91OGt/j4wl7pnjUrzUCqR7e/BtJrMTM6SqrKr/fExX4Nsdgkc8SaKBBMW+8z Cc: "rtcweb@ietf.org" , "public-webrtc@w3.org" Subject: Re: [rtcweb] Microsoft tells W3C and IETF what we are doing no signs of offering real world interoperability X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 06 Aug 2012 20:20:06 -0000 --485b397dcfcd6260fc04c69e9aed Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Note also that pre- and post-processing of media are not covered by this proposal, those concepts are in the domain of MediaStream (and post-processing is possible today through various methods). In fact, I think the primary novel features of this proposal are: - SessionDescriptions are true objects, instead of wrappers around SDP - Additional control over the ICE Agent However, no use cases have yet been outlined that require this functionality. On Mon, Aug 6, 2012 at 10:00 PM, Cullen Jennings (fluffy) wrote: > > On Aug 6, 2012, at 1:27 PM, Rohit Puri wrote: > > > Based on our experiences at TenHands Inc. where we are trying to build = a > RT video-centric collaboration service, the goal cited in MSFT proposal ( > http://html5labs.com/cu-rtc-web/cu-rtc-web.htm), namely: > > > > "Flexibility in its support of popular media formats and codecs as well > as openness to future innovation=E2=80=94A successful standard cannot be = tied to > individual codecs, data formats or scenarios. They may soon be supplanted > by newer versions, which would make such a tightly coupled standard > obsolete just as quickly. The right approach is instead to to support > multiple media formats and to bring the bulk of the logic to the > application layer, enabling developers to innovate. " > > > > sounds like a great idea. > > and every proposal from any company or individual that I can recall being > sent to theses WGs has had exactly that property. So it is sort of > disappointing to see Microsoft present it as if their proposal was someho= w > different in this regards. > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --485b397dcfcd6260fc04c69e9aed Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Note also that pre- and post-processing of media are not covered by this pr= oposal, those concepts are in the domain of MediaStream (and post-processin= g is possible today through various methods).

In fact, I= think the primary novel features of this proposal are:
- SessionDescriptions are true objects, instead of wrappers around SDP=
- Additional control over the ICE Agent

However, no use cases have yet been outlined that require this functionali= ty.


On Mon, Aug 6= , 2012 at 10:00 PM, Cullen Jennings (fluffy) <fluffy@cisco.com> wrote:

On Aug 6, 2012, at 1:27 PM, Rohit Puri wrote:

> Based on our experiences at TenHands Inc. where we are trying to build= a RT video-centric collaboration service, the goal cited in MSFT proposal = (http://html5labs.com/cu-rtc-web/cu-rtc-web.htm), namely:
>
> "Flexibility in its support of popular media formats and codecs a= s well as openness to future innovation=E2=80=94A successful standard canno= t be tied to individual codecs, data formats or scenarios. They may soon be= supplanted by newer versions, which would make such a tightly coupled stan= dard obsolete just as quickly. The right approach is instead to to support = multiple media formats and to bring the bulk of the logic to the applicatio= n layer, enabling developers to innovate. "
>
> sounds like a great idea.

and every proposal from any company or individual that I can recall b= eing sent to theses WGs has had exactly that property. So it is sort of dis= appointing to see Microsoft present it as if their proposal was somehow dif= ferent in this regards.
___________________________________= ____________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb

--485b397dcfcd6260fc04c69e9aed-- From rohit.puri@tenhands.net Mon Aug 6 13:49:36 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC8C121E80AC for ; Mon, 6 Aug 2012 13:49:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nhdyytSlAa-f for ; Mon, 6 Aug 2012 13:49:35 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6D54021E80AB for ; Mon, 6 Aug 2012 13:49:35 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so7256036obb.31 for ; Mon, 06 Aug 2012 13:49:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=ehWjtnMttlJhR7tbJegyXvXql5wInrL3xaXQToiZJ3M=; b=Ff4JzaM7imRy0ofLOH4A100n9qn93raqJXVuDub6xP8R8VogbpmdhV2rtLkcZ22u6p g4hO9X9r+9fKsUBBrXq1MDgls2RENqRpv2JKe92V8GGe5EDmUNsx7FTZAG7eJiWRU+V7 IFKjkR0/K5LfNh9jsauZaUS4EiOr7lEM+Wj6PLwEh09VlOAhYHF5K5s5FbL4/R212R1v XzAXN8rUN55t1S1DLY2Qr17Y6ihQqVm0nY5qtrKKghAFhUBdAe2d91A9kr714HPR9wWx I5/R2OrGQrqvz0bPEt3D5Q69XtqHLbO7FWQf+Lhms/n46Z9Gs7kOXdATww5/HXEHCFsP UyLA== MIME-Version: 1.0 Received: by 10.182.177.7 with SMTP id cm7mr132914obc.17.1344286174489; Mon, 06 Aug 2012 13:49:34 -0700 (PDT) Received: by 10.76.143.38 with HTTP; Mon, 6 Aug 2012 13:49:34 -0700 (PDT) In-Reply-To: References: <53223349-A31F-4381-899F-82E29B0A0B6C@cisco.com> Date: Mon, 6 Aug 2012 13:49:34 -0700 Message-ID: From: Rohit Puri To: Justin Uberti , "Cullen Jennings (fluffy)" Content-Type: multipart/alternative; boundary=e89a8f8396e3e82bb604c69f034e X-Gm-Message-State: ALoCoQl67PNB1SxreiHet2tiVnDuoCA0DRabtWy/wg7IsJfi4oP3kDn7wF43Xm8gRWKV9Msguo7C Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Microsoft tells W3C and IETF what we are doing no signs of offering real world interoperability X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 06 Aug 2012 20:49:36 -0000 --e89a8f8396e3e82bb604c69f034e Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Having not been actively involved in the effort and realizing that i might be late to the party, i do not mean to cause distraction. Regardless, I want to voice out the following high-level opinion based on what we have been learning at TenHands Inc. (this is one of the reasons for us to continue with a plugin implementation for our service). If from the media pipeline perspective, it were possible to have an architecture like for example, gstreamer, wherein there is a concept of a processing chain for media and it is possible for the client developer to provide proprietary processing blocks that suit the use case for their application better than the default implementation, that would be great. Perhaps, the MSFT proposal does not talk about this, but two of the tenets they lay out upfront, namely (a) *Customizable response to changing network quality and (b) **Flexibility in its support of popular media formats and codecs as well as openness to future innovation* certainly sound appealing. On Mon, Aug 6, 2012 at 1:19 PM, Justin Uberti wrote: > Note also that pre- and post-processing of media are not covered by this > proposal, those concepts are in the domain of MediaStream (and > post-processing is possible today through various methods). > > In fact, I think the primary novel features of this proposal are: > - SessionDescriptions are true objects, instead of wrappers around SDP > - Additional control over the ICE Agent > > However, no use cases have yet been outlined that require this > functionality. > > > On Mon, Aug 6, 2012 at 10:00 PM, Cullen Jennings (fluffy) < > fluffy@cisco.com> wrote: > >> >> On Aug 6, 2012, at 1:27 PM, Rohit Puri wrote: >> >> > Based on our experiences at TenHands Inc. where we are trying to build >> a RT video-centric collaboration service, the goal cited in MSFT proposa= l ( >> http://html5labs.com/cu-rtc-web/cu-rtc-web.htm), namely: >> > >> > "Flexibility in its support of popular media formats and codecs as wel= l >> as openness to future innovation=97A successful standard cannot be tied = to >> individual codecs, data formats or scenarios. They may soon be supplante= d >> by newer versions, which would make such a tightly coupled standard >> obsolete just as quickly. The right approach is instead to to support >> multiple media formats and to bring the bulk of the logic to the >> application layer, enabling developers to innovate. " >> > >> > sounds like a great idea. >> >> and every proposal from any company or individual that I can recall bein= g >> sent to theses WGs has had exactly that property. So it is sort of >> disappointing to see Microsoft present it as if their proposal was someh= ow >> different in this regards. >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> > > --=20 Thanks and best regards, Rohit Puri (rohit.puri@tenhands.net) Software Development, TenHands Inc. (www.tenhands.net) My TenHands URL: http://tenhands.net/rohit.puri@tenhands.net --e89a8f8396e3e82bb604c69f034e Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Having not been actively involved in the effort and realizing that i might = be late to the party, i do not mean to cause distraction. Regardless, I wan= t to voice out the following high-level opinion based on what we have been = learning at TenHands Inc. (this is one of the reasons for us to continue wi= th a plugin implementation for our service).

If from the media pipeline perspective, it were possible to have an arc= hitecture like for example, gstreamer, wherein there is a concept of a proc= essing chain for media and it is possible for the client developer to provi= de proprietary processing blocks that suit the use case for their applicati= on better than the default implementation, that would be great.

Perhaps, the MSFT proposal does not talk about this, but two of the ten= ets they lay out upfront, namely (a) Customizable response to chang= ing network quality and (b) Flexibility in its support of = popular media formats and codecs as=20 well as openness to future innovation certainly sound appealing.=



On Mon, Aug 6, 2012 at 1:19 PM,= Justin Uberti <juberti@google.com> wrote:
Note also that pre- and post-processing of m= edia are not covered by this proposal, those concepts are in the domain of = MediaStream (and post-processing is possible today through various methods)= .

In fact, I think the primary novel features of this proposal= are:
- SessionDescriptions are true objects, instead of wrappers around SDP=
- Additional control over the ICE Agent

However, no use cases have yet been outlined that require this functionali= ty.


On Mon, Aug 6, 2012 at 10:00 PM, Cullen Jennings (fluffy) <fluffy= @cisco.com> wrote:

On Aug 6, 2012, at 1:27 PM, Rohit Puri wrote:

> Based on our experiences at TenHands Inc. where we are trying to build= a RT video-centric collaboration service, the goal cited in MSFT proposal = (http://html5labs.com/cu-rtc-web/cu-rtc-web.htm), namely:
>
> "Flexibility in its support of popular media formats and codecs a= s well as openness to future innovation=97A successful standard cannot be t= ied to individual codecs, data formats or scenarios. They may soon be suppl= anted by newer versions, which would make such a tightly coupled standard o= bsolete just as quickly. The right approach is instead to to support multip= le media formats and to bring the bulk of the logic to the application laye= r, enabling developers to innovate. "
>
> sounds like a great idea.

and every proposal from any company or individual that I can recall b= eing sent to theses WGs has had exactly that property. So it is sort of dis= appointing to see Microsoft present it as if their proposal was somehow dif= ferent in this regards.
___________________________________= ____________
rtcweb mailing list
rtcweb@ietf.org = https://www.ietf.org/mailman/listinfo/rtcweb




--
Thanks and best re= gards,

Rohit Puri=A0(rohit.puri@tenhands.net)
Software Develo= pment, TenHands Inc. (www.tenhands.net)
My TenHands URL:=A0http://tenhands.net/rohit.puri@tenhands.net
--e89a8f8396e3e82bb604c69f034e-- From kpfleming@digium.com Mon Aug 6 14:07:22 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12F0C21F8494 for ; Mon, 6 Aug 2012 14:07:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.599 X-Spam-Level: X-Spam-Status: No, score=-109.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3xWnYYPYfQuT for ; Mon, 6 Aug 2012 14:07:21 -0700 (PDT) Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by ietfa.amsl.com (Postfix) with ESMTP id EA18621F8493 for ; Mon, 6 Aug 2012 14:07:20 -0700 (PDT) Received: from [10.24.55.203] (helo=zimbra.hsv.digium.com) by mail.digium.com with esmtp (Exim 4.69) (envelope-from ) id 1SyUWF-0001op-RZ for rtcweb@ietf.org; Mon, 06 Aug 2012 16:07:19 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.hsv.digium.com (Postfix) with ESMTP id CCAEDD887A for ; Mon, 6 Aug 2012 16:07:19 -0500 (CDT) Received: from zimbra.hsv.digium.com ([127.0.0.1]) by localhost (zimbra.hsv.digium.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w76gYZYzmZEZ for ; Mon, 6 Aug 2012 16:07:19 -0500 (CDT) Received: from [10.24.19.142] (sligo.digium.internal [10.24.19.142]) by zimbra.hsv.digium.com (Postfix) with ESMTPSA id 59712D8002 for ; Mon, 6 Aug 2012 16:07:19 -0500 (CDT) Message-ID: <502031F8.8020104@digium.com> Date: Mon, 06 Aug 2012 16:07:04 -0500 From: "Kevin P. Fleming" Organization: Digium, Inc. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <53223349-A31F-4381-899F-82E29B0A0B6C@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Microsoft tells W3C and IETF what we are doing no signs of offering real world interoperability X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 06 Aug 2012 21:07:22 -0000 On 08/06/2012 03:19 PM, Justin Uberti wrote: > Note also that pre- and post-processing of media are not covered by this > proposal, those concepts are in the domain of MediaStream (and > post-processing is possible today through various methods). > > In fact, I think the primary novel features of this proposal are: > - SessionDescriptions are true objects, instead of wrappers around SDP > - Additional control over the ICE Agent > > However, no use cases have yet been outlined that require this > functionality. I doubt you'll ever see a use case that *requires* SessionDescription objects, since the identical behavior can be achieved (in most cases) by handling SDP directly. As has been previously discussed, though, using objects would make life easier for JS developers, and might lead to more natural solutions to problems that have been recently posted on this list (like inspection of offers to determine which parts should be accepted and which should not). -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies Jabber: kfleming@digium.com | SIP: kpfleming@digium.com | Skype: kpfleming 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at www.digium.com & www.asterisk.org From Jim.Barnett@genesyslab.com Mon Aug 6 14:12:20 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58AAE11E80F9 for ; Mon, 6 Aug 2012 14:12:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mwva2iMFPZj6 for ; Mon, 6 Aug 2012 14:12:19 -0700 (PDT) Received: from relay-out2.dc.genesyslab.com (relay-out2.dc.genesyslab.com [198.49.180.221]) by ietfa.amsl.com (Postfix) with ESMTP id 7C15811E80DE for ; Mon, 6 Aug 2012 14:12:19 -0700 (PDT) Received: from g2.genesyslab.com (g2.genesyslab.com [192.168.20.138]) by relay-out2.dc.genesyslab.com (8.13.8+Sun/8.13.8) with ESMTP id q76LCEi1021057; Mon, 6 Aug 2012 14:12:14 -0700 (PDT) Received: from NAHALD.us.int.genesyslab.com ([192.168.20.93]) by g2.genesyslab.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 6 Aug 2012 14:12:14 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 6 Aug 2012 14:11:42 -0700 Message-ID: In-Reply-To: <502031F8.8020104@digium.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] Microsoft tells W3C and IETF what we are doing no signs of offering real world interoperability Thread-Index: Ac10F3osEMHXjZFjRMKKxmN75hDYsQAAGJWQ References: <53223349-A31F-4381-899F-82E29B0A0B6C@cisco.com> <502031F8.8020104@digium.com> From: "Jim Barnett" To: "Kevin P. Fleming" , X-OriginalArrivalTime: 06 Aug 2012 21:12:14.0734 (UTC) FILETIME=[27150AE0:01CD7418] Subject: Re: [rtcweb] Microsoft tells W3C and IETF what we are doing no signs of offering real world interoperability X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 06 Aug 2012 21:12:20 -0000 As I recall, we recently discussed the idea of an API abstraction on top of the SDP and rejected it. I think that the reasoning was that it was an unnecessary complication. - Jim -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Kevin P. Fleming Sent: Monday, August 06, 2012 5:07 PM To: rtcweb@ietf.org Subject: Re: [rtcweb] Microsoft tells W3C and IETF what we are doing no signs of offering real world interoperability On 08/06/2012 03:19 PM, Justin Uberti wrote: > Note also that pre- and post-processing of media are not covered by=20 > this proposal, those concepts are in the domain of MediaStream (and=20 > post-processing is possible today through various methods). > > In fact, I think the primary novel features of this proposal are: > - SessionDescriptions are true objects, instead of wrappers around SDP > - Additional control over the ICE Agent > > However, no use cases have yet been outlined that require this=20 > functionality. I doubt you'll ever see a use case that *requires* SessionDescription objects, since the identical behavior can be achieved (in most cases) by handling SDP directly. As has been previously discussed, though, using objects would make life easier for JS developers, and might lead to more natural solutions to problems that have been recently posted on this list (like inspection of offers to determine which parts should be accepted and which should not). -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies Jabber: kfleming@digium.com | SIP: kpfleming@digium.com | Skype: kpfleming 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at www.digium.com & www.asterisk.org _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From kpfleming@digium.com Mon Aug 6 14:14:41 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A2FA11E80FA for ; Mon, 6 Aug 2012 14:14:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.799 X-Spam-Level: X-Spam-Status: No, score=-109.799 tagged_above=-999 required=5 tests=[AWL=0.800, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0mSOYDxq7ljX for ; Mon, 6 Aug 2012 14:14:41 -0700 (PDT) Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by ietfa.amsl.com (Postfix) with ESMTP id E89BD11E80DE for ; Mon, 6 Aug 2012 14:14:40 -0700 (PDT) Received: from [10.24.55.203] (helo=zimbra.hsv.digium.com) by mail.digium.com with esmtp (Exim 4.69) (envelope-from ) id 1SyUdM-0001ts-30; Mon, 06 Aug 2012 16:14:40 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.hsv.digium.com (Postfix) with ESMTP id 1366DD887A; Mon, 6 Aug 2012 16:14:40 -0500 (CDT) Received: from zimbra.hsv.digium.com ([127.0.0.1]) by localhost (zimbra.hsv.digium.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hvsBmpjQTfYk; Mon, 6 Aug 2012 16:14:39 -0500 (CDT) Received: from [10.24.19.142] (sligo.digium.internal [10.24.19.142]) by zimbra.hsv.digium.com (Postfix) with ESMTPSA id B969AD8002; Mon, 6 Aug 2012 16:14:39 -0500 (CDT) Message-ID: <502033B0.2020608@digium.com> Date: Mon, 06 Aug 2012 16:14:24 -0500 From: "Kevin P. Fleming" Organization: Digium, Inc. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: Jim Barnett References: <53223349-A31F-4381-899F-82E29B0A0B6C@cisco.com> <502031F8.8020104@digium.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Microsoft tells W3C and IETF what we are doing no signs of offering real world interoperability X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 06 Aug 2012 21:14:41 -0000 On 08/06/2012 04:11 PM, Jim Barnett wrote: > As I recall, we recently discussed the idea of an API abstraction on top > of the SDP and rejected it. I think that the reasoning was that it was > an unnecessary complication. Indeed... and yet if it turns out that the abstraction is useful somebody will produce one and publish it as a JS library :-) -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies Jabber: kfleming@digium.com | SIP: kpfleming@digium.com | Skype: kpfleming 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at www.digium.com & www.asterisk.org From randell-ietf@jesup.org Mon Aug 6 14:18:37 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED9DB21E8051 for ; Mon, 6 Aug 2012 14:18:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.351 X-Spam-Level: X-Spam-Status: No, score=-2.351 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E6lMZFbfuDOa for ; Mon, 6 Aug 2012 14:18:37 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 174C121E804D for ; Mon, 6 Aug 2012 14:18:37 -0700 (PDT) Received: from pool-173-49-141-60.phlapa.fios.verizon.net ([173.49.141.60] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1SyUh9-0008NH-V0 for rtcweb@ietf.org; Mon, 06 Aug 2012 16:18:36 -0500 Message-ID: <5020343F.7070204@jesup.org> Date: Mon, 06 Aug 2012 17:16:47 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <53223349-A31F-4381-899F-82E29B0A0B6C@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [rtcweb] Microsoft tells W3C and IETF what we are doing no signs of offering real world interoperability X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 06 Aug 2012 21:18:38 -0000 On 8/6/2012 1:16 PM, Luca De Cicco wrote: > I think that the proposed "customizable response to changing network > quality" is a good idea. > Wiring the adaptation logic into webrtc would make it less flexible to > different needs in particular > applications. Of course a default adaptation logic should be implemented > in the browser. Already proposed by me (and we've said here that we will have a way to do this from the application). Here's my proposed API, which I think covers exactly this and what you want: https://www.w3.org/Bugs/Public/show_bug.cgi?id=15861 -- Randell Jesup randell-ietf@jesup.org From randell-ietf@jesup.org Mon Aug 6 14:23:28 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C215421F855F for ; Mon, 6 Aug 2012 14:23:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fyyIgVJhO4Oc for ; Mon, 6 Aug 2012 14:23:28 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 1393721F855D for ; Mon, 6 Aug 2012 14:23:27 -0700 (PDT) Received: from pool-173-49-141-60.phlapa.fios.verizon.net ([173.49.141.60] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1SyUlr-0009ZM-IV for rtcweb@ietf.org; Mon, 06 Aug 2012 16:23:27 -0500 Message-ID: <50203564.8070509@jesup.org> Date: Mon, 06 Aug 2012 17:21:40 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <53223349-A31F-4381-899F-82E29B0A0B6C@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [rtcweb] Microsoft tells W3C and IETF what we are doing no signs of offering real world interoperability X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 06 Aug 2012 21:23:29 -0000 On 8/6/2012 4:49 PM, Rohit Puri wrote: > If from the media pipeline perspective, it were possible to have an > architecture like for example, gstreamer, wherein there is a concept of > a processing chain for media and it is possible for the client developer > to provide proprietary processing blocks that suit the use case for > their application better than the default implementation, that would be > great. See the MediaStream Processing API proposal: https://dvcs.w3.org/hg/audio/raw-file/tip/streams/StreamProcessing.html Note that this was partly an alternative to the Web Audio API, which has been adopted, and they plan to integrate some aspects of MediaStream Processing into Web Audio, but MediaStream Processing is still relevant, especially for video (and will be more so once JS workers can access WebGL). -- Randell Jesup randell-ietf@jesup.org From matthew.kaufman@skype.net Mon Aug 6 14:52:02 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5145321E808E for ; Mon, 6 Aug 2012 14:52:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j+5AFUOrhXXj for ; Mon, 6 Aug 2012 14:52:01 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe004.messaging.microsoft.com [216.32.180.187]) by ietfa.amsl.com (Postfix) with ESMTP id 9274821E808D for ; Mon, 6 Aug 2012 14:52:01 -0700 (PDT) Received: from mail144-co1-R.bigfish.com (10.243.78.230) by CO1EHSOBE015.bigfish.com (10.243.66.78) with Microsoft SMTP Server id 14.1.225.23; Mon, 6 Aug 2012 21:52:00 +0000 Received: from mail144-co1 (localhost [127.0.0.1]) by mail144-co1-R.bigfish.com (Postfix) with ESMTP id 9DB0D5000BA; Mon, 6 Aug 2012 21:52:00 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC107.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -21 X-BigFish: VS-21(zz1432Izz1202hzz1033IL8275dhz2fh2a8h668h839h944hd25hf0ah107ah) Received-SPF: pass (mail144-co1: domain of skype.net designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=matthew.kaufman@skype.net; helo=TK5EX14HUBC107.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail144-co1 (localhost.localdomain [127.0.0.1]) by mail144-co1 (MessageSwitch) id 1344289917826177_1023; Mon, 6 Aug 2012 21:51:57 +0000 (UTC) Received: from CO1EHSMHS001.bigfish.com (unknown [10.243.78.244]) by mail144-co1.bigfish.com (Postfix) with ESMTP id C4B20BC0044; Mon, 6 Aug 2012 21:51:57 +0000 (UTC) Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (131.107.125.8) by CO1EHSMHS001.bigfish.com (10.243.66.11) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 6 Aug 2012 21:51:56 +0000 Received: from TK5EX14MBXC273.redmond.corp.microsoft.com ([169.254.1.216]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.02.0309.003; Mon, 6 Aug 2012 21:51:56 +0000 From: Matthew Kaufman To: Justin Uberti , "Cullen Jennings (fluffy)" Thread-Topic: [rtcweb] Microsoft tells W3C and IETF what we are doing no signs of offering real world interoperability Thread-Index: AQHNc/KKtNgifpdI6EiCHb2fk+96dZdNBqGAgAAkhgCAAAk+gIAABVaAgAAS5nI= Date: Mon, 6 Aug 2012 21:51:55 +0000 Message-ID: References: <53223349-A31F-4381-899F-82E29B0A0B6C@cisco.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.36] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: skype.net Cc: "rtcweb@ietf.org" , "public-webrtc@w3.org" Subject: Re: [rtcweb] Microsoft tells W3C and IETF what we are doing no signs of offering real world interoperability X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 06 Aug 2012 21:52:02 -0000 =0A= From: rtcweb-bounces@ietf.org [rtcweb-bounces@ietf.org] on behalf of Justin= Uberti [juberti@google.com]:=0A= =0A= > In fact, I think the primary novel features of this proposal are:=0A= >=0A= > - SessionDescriptions are true objects, instead of wrappers around SDP=0A= =0A= More important, there is no SDP Offer/Answer state machine within the brows= er. A developer who desires SDP Offer/Answer semantics may implement that i= n Javascript or server-side. This is as opposed to JSEP, which includes a p= articular SDP O/A state machine within the browser, thus requiring it to be= interoperable with other SDP O/A state machines both within other vendor b= rowsers as well as existing SIP+SDP equipment and software.=0A= =0A= > - Additional control over the ICE Agent=0A= >=0A= > However, no use cases have yet been outlined that require this functional= ity.=0A= =0A= I believe that there are several use cases, including interoperability use = cases, where our proposed solution is more likely to be able to meet all ed= ge cases.=0A= =0A= An example would be recovery from call setup in the face of a browser page = reload... a case where the state of the browser must be reinitialized, lead= ing to edge cases where it becomes impossible with JSEP for a developer to = write Javascript that behaves properly in all cases (because without an off= er one cannot generate an answer, and once an offer has been generated one = must not generate another offer until the first offer has been answered, bu= t in either case there is no longer sufficient information as to how to pro= ceed). While SDP O/A is a useful abstraction for trunk interconnection of p= eer endpoints, we do not believe it is a good choice for the Javascript API= surface.=0A= =0A= Likewise, baking in one ICE implementation is likely to lead to interoperab= ility failures when it is found that it has subtle incompatibilities with o= ther deployed applications, whereas our proposal would allow the developer = of the web site or supporting Javascript library to code around these issue= s once RTC-capable browsers are already fielded.=0A= =0A= In addition to these differences that fall out of not baking in the full IC= E and SDP O/A state machines, our proposal provides several other capabilit= ies, including hooks that allow a developer to customize their application'= s response to changing network conditions... an area which is currently com= pletely unaddressed in the current WebRTC draft.=0A= =0A= I wouldn't be surprised if the existing use-case document(s) is (are) inade= quate to describe situations where, for instance, a developer might wish to= prioritize video quality over frame rate, or drop video in order to contin= ue audio, but that just means that we all need to provide more input on tho= se documents as well.=0A= =0A= =0A= Matthew Kaufman= From juberti@google.com Mon Aug 6 17:11:49 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B38BB11E80A5 for ; Mon, 6 Aug 2012 17:11:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.443 X-Spam-Level: X-Spam-Status: No, score=-102.443 tagged_above=-999 required=5 tests=[AWL=-0.067, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mwAt35fGMdF9 for ; Mon, 6 Aug 2012 17:11:48 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7450011E8087 for ; Mon, 6 Aug 2012 17:11:48 -0700 (PDT) Received: by qcac10 with SMTP id c10so2428417qca.31 for ; Mon, 06 Aug 2012 17:11:47 -0700 (PDT) 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:x-system-of-record; bh=7w0jJQTUbBFje0Usq91tT2UylFYFVZyG0fGJBzgntQU=; b=pDFaig+MvDEs7xY4eCloSp0tJwJMGjrdZK+m8KXcz5wEWiyjOiwLlR4j7j0iI8UCHm GI/zPo5Xce8rVHtx6MdXml3UVX74Jy/druKvpvC2JTSYUHI9NSmAORv1aeInawldZ2Sp PvSArjM8ArBcjUf388y2l1UTcH1eQ+PkTBhtAb98CXzaCFaUzmQ9NlJkIDAGNYJIJu3o 8qgIiQLDDnJGZESI1Vw2azsHj+GvjDgItwNprUVhK0aYXtCIsALP6IjSxq9wmBifVn7p jJRHTRIKZP5iSYdYV6cekLl4XrfHy7ZAAb+BQHIu9zIHKkK1X/cl9BEZoagPBm2Y/8mf sjbw== X-Google-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:x-system-of-record:x-gm-message-state; bh=7w0jJQTUbBFje0Usq91tT2UylFYFVZyG0fGJBzgntQU=; b=Pf9aF747fSVes+t/S08TGmmKKUN5KBrgXOr1DPf23eEC800F9AMtuGxJdK0DyUwQw0 VuYTzUmB2HCOF/MThPhFb8T+lIs8KbFbrnucY7vqHfW0/zqR6QDf/cx/QirbHzp6OfCK BQkfm8pnHjrEmzirj+RWjfY1J1Bn+KkV0Zt4N3dbUApiTpbO1Yw47JuKw2cSKXygl+lJ b3w2pHYcLZCtse/XlI5k52uwHegzq7QKOdI+0R+ZMcot92yZCj34fPIlLeR0cZgMs3HG WFikIAC+2jfXu9lKY8Y7iL1Quh4gdhssEdVXo1vrU8wiqAkF5epVPh85Txca86cN5qlT XcQQ== Received: by 10.224.188.12 with SMTP id cy12mr20743915qab.68.1344298307632; Mon, 06 Aug 2012 17:11:47 -0700 (PDT) Received: by 10.224.188.12 with SMTP id cy12mr20743899qab.68.1344298307526; Mon, 06 Aug 2012 17:11:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.218.80 with HTTP; Mon, 6 Aug 2012 17:11:27 -0700 (PDT) In-Reply-To: References: <53223349-A31F-4381-899F-82E29B0A0B6C@cisco.com> From: Justin Uberti Date: Tue, 7 Aug 2012 02:11:27 +0200 Message-ID: To: Matthew Kaufman Content-Type: multipart/alternative; boundary=20cf30363ebb17a1fd04c6a1d781 X-System-Of-Record: true X-Gm-Message-State: ALoCoQkKJ8+Zrsxi2y6ov9i+mBuCybdBq7rBdNs5y1jGLvgbdpoBq+ETaXt1X8wdl5WRFdsJv/Bpd8kNiHJc0GGbydWUbQ33ucuiqdBjqIO5zZIYHl60og/xXu5OH/gxkDYuwhdod23oHxXU16Vy1vfF2BZIp+wfXsiAPjQN7qqx9LemYPpjWfpp2FT8UtV6NBgfHvE7Jxlf Cc: "Cullen Jennings \(fluffy\)" , "rtcweb@ietf.org" , "public-webrtc@w3.org" Subject: Re: [rtcweb] Microsoft tells W3C and IETF what we are doing no signs of offering real world interoperability X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 07 Aug 2012 00:11:50 -0000 --20cf30363ebb17a1fd04c6a1d781 Content-Type: text/plain; charset=UTF-8 On Mon, Aug 6, 2012 at 11:51 PM, Matthew Kaufman wrote: > > From: rtcweb-bounces@ietf.org [rtcweb-bounces@ietf.org] on behalf of > Justin Uberti [juberti@google.com]: > > > In fact, I think the primary novel features of this proposal are: > > > > - SessionDescriptions are true objects, instead of wrappers around SDP > > More important, there is no SDP Offer/Answer state machine within the > browser. A developer who desires SDP Offer/Answer semantics may implement > that in Javascript or server-side. This is as opposed to JSEP, which > includes a particular SDP O/A state machine within the browser, thus > requiring it to be interoperable with other SDP O/A state machines both > within other vendor browsers as well as existing SIP+SDP equipment and > software. > While there is a simple state machine, with JSEP you can drive the state machine to any state you want, easily. To say that it bakes in SDP offer/answer is inaccurate; if you don't want to use offer/answer you can just set the local or remote description at any time (followed by reapplying the existing remote/local description to complete the sequence). This could of course be streamlined, but this could be done as an evolution of the existing API. > > - Additional control over the ICE Agent > > > > However, no use cases have yet been outlined that require this > functionality. > > I believe that there are several use cases, including interoperability use > cases, where our proposed solution is more likely to be able to meet all > edge cases. > > An example would be recovery from call setup in the face of a browser page > reload... a case where the state of the browser must be reinitialized, > leading to edge cases where it becomes impossible with JSEP for a developer > to write Javascript that behaves properly in all cases (because without an > offer one cannot generate an answer, and once an offer has been generated > one must not generate another offer until the first offer has been > answered, but in either case there is no longer sufficient information as > to how to proceed). While SDP O/A is a useful abstraction for trunk > interconnection of peer endpoints, we do not believe it is a good choice > for the Javascript API surface. > > Likewise, baking in one ICE implementation is likely to lead to > interoperability failures when it is found that it has subtle > incompatibilities with other deployed applications, whereas our proposal > would allow the developer of the web site or supporting Javascript library > to code around these issues once RTC-capable browsers are already fielded. > In addition to these differences that fall out of not baking in the full > ICE and SDP O/A state machines, our proposal provides several other > capabilities, including hooks that allow a developer to customize their > application's response to changing network conditions... an area which is > currently completely unaddressed in the current WebRTC draft. > As others have pointed out, these kinds of hooks have been discussed but haven't yet made it into the current API draft. > > I wouldn't be surprised if the existing use-case document(s) is (are) > inadequate to describe situations where, for instance, a developer might > wish to prioritize video quality over frame rate, or drop video in order to > continue audio, but that just means that we all need to provide more input > on those documents as well. > > > Matthew Kaufman > --20cf30363ebb17a1fd04c6a1d781 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, A= ug 6, 2012 at 11:51 PM, Matthew Kaufman <matthew.kaufman@skype.net= > wrote:

From: rtcweb-bounces@ietf.org [rtcweb-bounces@ietf.org] = on behalf of Justin Uberti [juberti@g= oogle.com]:

> In fact, I think the primary novel features of this proposal are:
>
> - SessionDescriptions are true objects, instead of wrappers around SDP=

More important, there is no SDP Offer/Answer state machine within the= browser. A developer who desires SDP Offer/Answer semantics may implement = that in Javascript or server-side. This is as opposed to JSEP, which includ= es a particular SDP O/A state machine within the browser, thus requiring it= to be interoperable with other SDP O/A state machines both within other ve= ndor browsers as well as existing SIP+SDP equipment and software.

While there is a simple state machine, wit= h JSEP you can drive the state machine to any state you want, easily. To sa= y that it bakes in SDP offer/answer is inaccurate; if you don't want to= use offer/answer you can just set the local or remote description at any t= ime (followed by reapplying the existing remote/local description to comple= te the sequence).=C2=A0

This could of course be streamlined, but this could be = done as an evolution of the existing API.


> - Additional control over the ICE Agent
>
> However, no use cases have yet been outlined that require this functio= nality.

I believe that there are several use cases, including interoperabilit= y use cases, where our proposed solution is more likely to be able to meet = all edge cases.

An example would be recovery from call setup in the face of a browser page = reload... a case where the state of the browser must be reinitialized, lead= ing to edge cases where it becomes impossible with JSEP for a developer to = write Javascript that behaves properly in all cases (because without an off= er one cannot generate an answer, and once an offer has been generated one = must not generate another offer until the first offer has been answered, bu= t in either case there is no longer sufficient information as to how to pro= ceed). While SDP O/A is a useful abstraction for trunk interconnection of p= eer endpoints, we do not believe it is a good choice for the Javascript API= surface.

Likewise, baking in one ICE implementation is likely to lead to interoperab= ility failures when it is found that it has subtle incompatibilities with o= ther deployed applications, whereas our proposal would allow the developer = of the web site or supporting Javascript library to code around these issue= s once RTC-capable browsers are already fielded.

In addition to these differences that fall out of not baking in the full IC= E and SDP O/A state machines, our proposal provides several other capabilit= ies, including hooks that allow a developer to customize their application&= #39;s response to changing network conditions... an area which is currently= completely unaddressed in the current WebRTC draft.

As others have pointed out, these kinds of= hooks have been discussed but haven't yet made it into the current API= draft.

I wouldn't be surprised if the existing use-case document(s) is (are) i= nadequate to describe situations where, for instance, a developer might wis= h to prioritize video quality over frame rate, or drop video in order to co= ntinue audio, but that just means that we all need to provide more input on= those documents as well.


Matthew Kaufman

--20cf30363ebb17a1fd04c6a1d781-- From duerst@it.aoyama.ac.jp Mon Aug 6 18:27:44 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11B3C11E808A for ; Mon, 6 Aug 2012 18:27:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.917 X-Spam-Level: X-Spam-Status: No, score=-102.917 tagged_above=-999 required=5 tests=[AWL=0.873, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VQ6VgPUELFx7 for ; Mon, 6 Aug 2012 18:27:43 -0700 (PDT) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id 3C58C11E8087 for ; Mon, 6 Aug 2012 18:27:42 -0700 (PDT) Received: from scmse01.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id q771RWo2017756 for ; Tue, 7 Aug 2012 10:27:33 +0900 Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 01a7_5660_0f4777b2_e02f_11e1_9d8d_001d096c566a; Tue, 07 Aug 2012 10:27:31 +0900 Received: from [IPv6:::1] ([133.2.210.1]:49134) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Tue, 7 Aug 2012 10:27:35 +0900 Message-ID: <50206F01.8060407@it.aoyama.ac.jp> Date: Tue, 07 Aug 2012 10:27:29 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Rohit Puri References: <53223349-A31F-4381-899F-82E29B0A0B6C@cisco.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "Cullen Jennings \(fluffy\)" , "rtcweb@ietf.org" , "public-webrtc@w3.org" Subject: Re: [rtcweb] Microsoft tells W3C and IETF what we are doing no signs of offering real world interoperability X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 07 Aug 2012 01:27:44 -0000 On 2012/08/07 4:27, Rohit Puri wrote: > Based on our experiences at TenHands Inc. where we are trying to build a RT > video-centric collaboration service, the goal cited in MSFT proposal ( > http://html5labs.com/cu-rtc-web/cu-rtc-web.htm), namely: I'm surprised to see this called a W3C Submission when it is not (yet?) listed at http://www.w3.org/Submission/ (and it's not yet the 7th in the areas of the world where most of the involved people are :-). Regards, Martin. From randell-ietf@jesup.org Mon Aug 6 18:48:06 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B47E711E80E9 for ; Mon, 6 Aug 2012 18:48:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FtnK92QLmdo5 for ; Mon, 6 Aug 2012 18:48:06 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 176E911E809C for ; Mon, 6 Aug 2012 18:48:05 -0700 (PDT) Received: from pool-173-49-141-60.phlapa.fios.verizon.net ([173.49.141.60] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1SyYtx-0007fN-B3 for rtcweb@ietf.org; Mon, 06 Aug 2012 20:48:05 -0500 Message-ID: <50207367.9030605@jesup.org> Date: Mon, 06 Aug 2012 21:46:15 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: "rtcweb@ietf.org" References: <53223349-A31F-4381-899F-82E29B0A0B6C@cisco.com> , In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [rtcweb] Microsoft tells W3C and IETF what we are doing no signs of offering real world interoperability X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 07 Aug 2012 01:48:06 -0000 On 8/6/2012 5:51 PM, Matthew Kaufman wrote: > In addition to these differences that fall out of not baking in the > full ICE and SDP O/A state machines, our proposal provides several > other capabilities, including hooks that allow a developer to > customize their application's response to changing network > conditions... an area which is currently completely unaddressed in the > current WebRTC draft. We've said repeatedly that we need such capability, and I have a proposed JS API for just that: https://www.w3.org/Bugs/Public/show_bug.cgi?id=15861 The other side of this is in the hands of the Media Capture Task Force, where we've been discussing the best way to modify a MediaStream/Track after they're created. There are two rough proposals, one to re-use the constraints API for getUserMedia(), and the other I've proposed (verbally only so far, no draft API) uses events and lets them "bubble up" the chain of MediaStreams/Tracks from a consumer to a source (which could be a remote source, and the application could signal that request (such as a resolution or frame-rate change) across to the remote source of the stream. This is relevant even without a remote connection. > I wouldn't be surprised if the existing use-case document(s) is (are) > inadequate to describe situations where, for instance, a developer > might wish to prioritize video quality over frame rate, or drop video > in order to continue audio, but that just means that we all need to > provide more input on those documents as well. Matthew Kaufman I think most of those concerns are covered in what I describe above. (For example, the application could override the automatic allocation of bits and close a video stream, change the resolution, etc.) I'd love to your input on these proposals, API suggestions, alternatives, etc! I'm glad you're willing to help flesh out them out and bring them to completion, and get them into the spec drafts ASAP. -- Randell Jesup randell-ietf@jesup.org From alexey@zingaya.com Mon Aug 6 10:13:04 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 291E021F85B8 for ; Mon, 6 Aug 2012 10:13:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.185 X-Spam-Level: X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v1cRRI7jeHeG for ; Mon, 6 Aug 2012 10:13:03 -0700 (PDT) Received: from o1.email.zingaya.com (o1.email.zingaya.com [50.31.39.33]) by ietfa.amsl.com (Postfix) with SMTP id 4934D21F85A8 for ; Mon, 6 Aug 2012 10:13:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=zingaya.com; h=date :subject:message-id:from:to:cc:mime-version:content-type :content-transfer-encoding; s=smtpapi; bh=j0TNKhl3v914buS2SfGHZT jF5Uw=; b=ex0UZtAat/QvbW99reINXtgxxmOHWnkDDH07gPwjzcq7My8SyJjNdT RNSsJqqRiJLXylZiCqDeFyF35As6R6ocGdVdyfYnKQ7MHY8dBX7D90Cj1HKe72Qm 4c1f7VGJ/nCGFy5cmX6qoIN7CQebvi/weE7tF3J3u0eYymAdySypc= Received: by 10.16.69.112 with SMTP id mf23.17018.501FFB1E3 Mon, 06 Aug 2012 12:13:02 -0500 (CDT) Received: from mail.zingaya.com (unknown [10.9.180.5]) by mi2 (SG) with ESMTP id 501ffb1e.4517.f7eafe Mon, 06 Aug 2012 12:13:02 -0500 (CST) Received: by mail.zingaya.com (Postfix, from userid 1000) id 547CF103A004; Mon, 6 Aug 2012 19:12:59 +0200 (CEST) Received: from [172.20.148.46] (mail.zingaya.com [188.138.50.58]) by mail.zingaya.com (Postfix) with ESMTPA id A4701103A003; Mon, 6 Aug 2012 19:12:57 +0200 (CEST) Date: Mon, 06 Aug 2012 21:11:19 +0400 Message-ID: From: Alexey Aylarov To: "Cullen Jennings (fluffy)" MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 X-Sendgrid-EID: 1ZgjKEJRFrScP9jRqx/qmkgw2v3eAagChXzRcreaJSsG3lbHoVkH2/9vIsMLt812Nl4sGNoJElE0AxM8v3E/xhy42UDcP02wkZDIKsPFTx3I77H5h538+IoXT//0ZADmnMV42h3WrMjwfs2Ht2/8SA== X-Mailman-Approved-At: Tue, 07 Aug 2012 00:27:50 -0700 Cc: "rtcweb@ietf.org " , public-webrtc@w3.org Subject: Re: [rtcweb] Microsoft tells W3C and IETF what we are doing no signs of offering real world interoperability X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 06 Aug 2012 17:14:57 -0000 SXQgd2FzIGVhc3kgdG8gZXhwZWN0IGZyb20gY29tcGFueSB3aGljaCB0cmll cyB0byBidWlsZCBpdHMgb3duIHN0YW5kYXJkcyBhbGwgdGhlIHRpbWUgaW5z dGVhZCBvZiB0ZWFtIHdvcmsgb24gb3BlbiB0ZWNobm9sb2dpZXMuIElmIHRo ZXkgd2FudCB0byBsaXZlIGluIHRoZWlyIG93biB1bml2ZXJzZSAtIGl0J3Mg dGhlaXIgY2hvaWNlLiBXZSBuZWVkIHRvIGNvbnRpbnVlIHRlYW0gd29yayBv biB0aGUgZnV0dXJlIG9mIG9wZW4gd2ViIGNvbW11bmljYXRpb25zLgoKIkN1 bGxlbiBKZW5uaW5ncyAoZmx1ZmZ5KSIgPGZsdWZmeUBjaXNjby5jb20+IHdy b3RlOgoKPgo+SSBzZWUgdGhhdCBNaWNyb3NvZnQgZGVjaWRlZCB0byB3YWl0 IHVudGlsIHRoZSBXM0MgYW5kIElFVEYgd2VyZSBjbG9zZSB0byBkb25lIGJl Zm9yZSBwdXR0aW5nIHRvZ2V0aGVyIGEgcHJvcG9zYWwgdGhhdCwgaWYgYWNj ZXB0ZWQsIHdvdWxkIGV4cGxvZGUgbW9zdCB0aGUgY3VycmVudCB3b3JrcyBh bmQgY3JlYXRlIG1heGltYWwgZGVsYXkgb24gdGhpcyB3b3JrLiAKPgo+aHR0 cDovL2Jsb2dzLnNreXBlLmNvbS9lbi8yMDEyLzA4L2N1c3RvbWl6YWJsZV91 YmlxdWl0b3VzX3JlYWxfdC5odG1sCj4KPgo+Cj4K From tim@phonefromhere.com Tue Aug 7 05:11:43 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 748B921F86D7 for ; Tue, 7 Aug 2012 05:11:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mtvT1JFVjGYk for ; Tue, 7 Aug 2012 05:11:41 -0700 (PDT) Received: from zimbra.westhawk.co.uk (zimbra.westhawk.co.uk [192.67.4.167]) by ietfa.amsl.com (Postfix) with ESMTP id 6DA7D21F866E for ; Tue, 7 Aug 2012 05:11:41 -0700 (PDT) Received: from [192.168.43.136] (unknown [82.132.219.98]) by zimbra.westhawk.co.uk (Postfix) with ESMTP id 4412537A905; Tue, 7 Aug 2012 13:20:38 +0100 (BST) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable References: From: Tim Panton Mime-Version: 1.0 (1.0) In-Reply-To: Message-Id: <81579634-CC55-46FF-8C3B-94EB5019786A@phonefromhere.com> Date: Tue, 7 Aug 2012 11:57:39 +0200 To: Alexey Aylarov X-Mailer: iPhone Mail (10A5355d) Cc: "Cullen Jennings \(fluffy\)" , "rtcweb@ietf.org" , "public-webrtc@w3.org" Subject: Re: [rtcweb] Microsoft tells W3C and IETF what we are doing no signs of offering real world interoperability X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 07 Aug 2012 12:11:44 -0000 Ok, the timing is unfortunate, but can you honestly say that we didn't know t= hat this was skype/microsofts opinion? We just chose to ignore it because it= was inconvenient.=20 Now that it is out there, are we seriously going to ignore a document with _= those_ authors from a major browser maker and a team with extensive experien= ce in the field jus because it is late!?!?=20 Tim, speaking for himself.=20 Sent from my iPhone On 6 Aug 2012, at 19:11, Alexey Aylarov wrote: > It was easy to expect from company which tries to build its own standards a= ll the time instead of team work on open technologies. If they want to live i= n their own universe - it's their choice. We need to continue team work on t= he future of open web communications. >=20 > "Cullen Jennings (fluffy)" wrote: >=20 >>=20 >> I see that Microsoft decided to wait until the W3C and IETF were close to= done before putting together a proposal that, if accepted, would explode mo= st the current works and create maximal delay on this work.=20 >>=20 >> http://blogs.skype.com/en/2012/08/customizable_ubiquitous_real_t.html > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From lorenzo@meetecho.com Tue Aug 7 05:28:08 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63B6921F8620 for ; Tue, 7 Aug 2012 05:28:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dr5-IZy3QreX for ; Tue, 7 Aug 2012 05:28:07 -0700 (PDT) Received: from smtplq01.aruba.it (smtplq-out5.aruba.it [62.149.158.25]) by ietfa.amsl.com (Postfix) with SMTP id DE03721F8600 for ; Tue, 7 Aug 2012 05:28:06 -0700 (PDT) Received: (qmail 21043 invoked by uid 89); 7 Aug 2012 12:28:04 -0000 Received: from unknown (HELO smtp5.aruba.it) (62.149.158.225) by smtplq01.aruba.it with SMTP; 7 Aug 2012 12:28:04 -0000 Received: (qmail 15587 invoked by uid 89); 7 Aug 2012 12:28:04 -0000 Received: from unknown (HELO rainpc) (lorenzo@meetecho.com@80.181.173.222) by smtp5.ad.aruba.it with SMTP; 7 Aug 2012 12:28:04 -0000 Date: Tue, 7 Aug 2012 14:21:58 +0200 From: Lorenzo Miniero To: Tim Panton Message-ID: <20120807142158.2bb62d9e@rainpc> In-Reply-To: <81579634-CC55-46FF-8C3B-94EB5019786A@phonefromhere.com> References: <81579634-CC55-46FF-8C3B-94EB5019786A@phonefromhere.com> Organization: Meetecho X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.8; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Rating: smtp5.ad.aruba.it 1.6.2 0/1000/N X-Spam-Rating: smtplq01.aruba.it 1.6.2 0/1000/N Cc: Alexey Aylarov , "Cullen Jennings \(fluffy\)" , "rtcweb@ietf.org" , "public-webrtc@w3.org" Subject: Re: [rtcweb] Microsoft tells W3C and IETF what we are doing no signs of offering real world interoperability X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 07 Aug 2012 12:28:08 -0000 On Tue, 7 Aug 2012 11:57:39 +0200 Tim Panton wrote: > Ok, the timing is unfortunate, but can you honestly say that we didn't know that this was skype/microsofts opinion? We just chose to ignore it because it was inconvenient. > > Now that it is out there, are we seriously going to ignore a document with _those_ authors from a major browser maker and a team with extensive experience in the field jus because it is late!?!? > An "unfortunately major" browser maker, I'd say, especially considering its well known history of poor adherence to standards (go tell the poor web developers out there), and this latest untimely post of theirs doesn't seem to change that. RTCWEB wasn't born yesterday, they've had more than a year to contribute, and claiming that a team at Microsoft can do better than 100s people contributing here and in the W3C seems a bit pretentious. I agree that the post probably contains some useful feedback, and ignoring it is unwise, but not it if that means changing too much on what we already have. L. > Tim, speaking for himself. > > Sent from my iPhone > > On 6 Aug 2012, at 19:11, Alexey Aylarov wrote: > > > It was easy to expect from company which tries to build its own standards all the time instead of team work on open technologies. If they want to live in their own universe - it's their choice. We need to continue team work on the future of open web communications. > > > > "Cullen Jennings (fluffy)" wrote: > > > >> > >> I see that Microsoft decided to wait until the W3C and IETF were close to done before putting together a proposal that, if accepted, would explode most the current works and create maximal delay on this work. > >> > >> http://blogs.skype.com/en/2012/08/customizable_ubiquitous_real_t.html > > _______________________________________________ > > 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 -- Lorenzo Miniero, COB Meetecho s.r.l. Web Conferencing and Collaboration Tools http://www.meetecho.com From Jim.Barnett@genesyslab.com Tue Aug 7 05:59:58 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DE8021F8678 for ; Tue, 7 Aug 2012 05:59:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qgG5Rq51rh9K for ; Tue, 7 Aug 2012 05:59:57 -0700 (PDT) Received: from relay-out2.dc.genesyslab.com (relay-out2.dc.genesyslab.com [198.49.180.221]) by ietfa.amsl.com (Postfix) with ESMTP id DCC0A21F8652 for ; Tue, 7 Aug 2012 05:59:57 -0700 (PDT) Received: from g2.genesyslab.com (g2.genesyslab.com [192.168.20.138]) by relay-out2.dc.genesyslab.com (8.13.8+Sun/8.13.8) with ESMTP id q77CxsW7009257; Tue, 7 Aug 2012 05:59:55 -0700 (PDT) Received: from NAHALD.us.int.genesyslab.com ([192.168.20.93]) by g2.genesyslab.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 7 Aug 2012 05:59:55 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 7 Aug 2012 05:59:20 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] Microsoft tells W3C and IETF what we are doing no signs of offering real world interoperability Thread-Index: Ac10bi8MrjY6CIctQbCrFa0VuQiHdAALEEGw References: From: "Jim Barnett" To: "Alexey Aylarov" , "Cullen Jennings (fluffy)" X-OriginalArrivalTime: 07 Aug 2012 12:59:55.0389 (UTC) FILETIME=[8AAC72D0:01CD749C] Cc: rtcweb@ietf.org, public-webrtc@w3.org Subject: Re: [rtcweb] Microsoft tells W3C and IETF what we are doing no signs of offering real world interoperability X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 07 Aug 2012 12:59:58 -0000 It seems to me that this proposal is a continuation of a discussion that the group has been having for a while over how much to bake into the browser. JSEP leaves more to the application than ROAP did, and now this proposal suggests moving even more into the application. It seems to me that the trade-off is clear, and doesn't involve "openness": the less we bake into the browser, the more flexibility the app developer has, and the more work he has to do. (To link this back to another discussion we've been having, it has been suggested that thoughtless developers might miss-use constraints. It seems to me that a developer who can't use constraints correctly is unlikely to code the ICE state machine correctly. So, are we worried about that kind of developer or not?) =20 Justin suggests that JSEP can provide the same flexibility that this proposal does, at least to a sophisticated developer who understands how to tweak it. Let's find out. I agree with Stefan that we should draw up a detailed list of differences and analyze them. At first glance, it seems to me that many of the differences are independent of each other, so that it is not a question of simply accepting or rejecting the entire Microsoft proposal. - Jim =20 -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Alexey Aylarov Sent: Monday, August 06, 2012 1:11 PM To: Cullen Jennings (fluffy) Cc: rtcweb@ietf.org ; public-webrtc@w3.org Subject: Re: [rtcweb] Microsoft tells W3C and IETF what we are doing no signs of offering real world interoperability It was easy to expect from company which tries to build its own standards all the time instead of team work on open technologies. If they want to live in their own universe - it's their choice. We need to continue team work on the future of open web communications. "Cullen Jennings (fluffy)" wrote: > >I see that Microsoft decided to wait until the W3C and IETF were close to done before putting together a proposal that, if accepted, would explode most the current works and create maximal delay on this work.=20 > >http://blogs.skype.com/en/2012/08/customizable_ubiquitous_real_t.html > > > > _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From Markus.Isomaki@nokia.com Tue Aug 7 07:13:28 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8339021F86DF for ; Tue, 7 Aug 2012 07:13:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PQI0K6Fqdzk6 for ; Tue, 7 Aug 2012 07:13:27 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 7DD6421F86CB for ; Tue, 7 Aug 2012 07:13:27 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-da01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q77EDKvQ011121; Tue, 7 Aug 2012 17:13:22 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.59]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 7 Aug 2012 17:14:14 +0300 Received: from 008-AM1MPN1-042.mgdnok.nokia.com ([169.254.2.220]) by 008-AM1MMR1-004.mgdnok.nokia.com ([65.54.30.59]) with mapi id 14.02.0283.004; Tue, 7 Aug 2012 16:13:19 +0200 From: To: , Thread-Topic: [rtcweb] NAT behavior heuristics Thread-Index: AQHNctqAZq9mQPoftU6IiiFi63YLnpdLBYEAgACgNoCAAASFAIACtXmA Date: Tue, 7 Aug 2012 14:13:18 +0000 Message-ID: References: <038b01cd70d6$8c5bc870$a5135950$@com> <04ff01cd7104$be09bed0$3a1d3c70$@com> <501E1E40.8070203@jesup.org> <913383AAA69FF945B8F946018B75898A1477C17F@xmb-rcd-x10.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.22.0.90] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 07 Aug 2012 14:14:14.0787 (UTC) FILETIME=[ECAE9530:01CD74A6] X-Nokia-AV: Clean Cc: randell-ietf@jesup.org, rtcweb@ietf.org, phdgang@gmail.com Subject: Re: [rtcweb] NAT behavior heuristics X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 07 Aug 2012 14:13:28 -0000 Hi Cameron, Cameron Byrne wrote: > >I asked around in Vancouver about PCP, and all the operators i spoke to sa= id >no-plans, no motivation. But, that was a small sample. This is probably a fair assessment about the concrete plans. Most mobile op= erators don't even follow IETF much, so I doubt that they have even heard a= bout PCP so far. There are however a few operators, where at least the rese= arch and standardization people have been interested in PCP (as witnessed b= y http://datatracker.ietf.org/doc/draft-chen-pcp-mobile-deployment/). I thi= nk some operators are also proposing PCP to be included in the 3GPP specs (= release 12). It is hard to say how much that means in the real world, but a= t least I'd expect we could find a few operators willing to do real-network= trials withing the next 12 months.=20 Personally I see PCP as a very useful tool in the cellular access environme= nt, for probing the NAT/FW timers and in the best case even setting them. I= t will be a major chicken-and-egg situation between apps, mobile OS's and t= he networks, to get anything into use. I think we should still do our best = to overcome it. I agree that RTCWeb or anyone else should not rely on PCP (= or any similar mechanim), but have the ability to make use of it if it happ= ens to be available.=20 I'm unconvinced IPv6 will help at all in this case. How do you know how lon= g the FW on the path will keep its state up without keepalives? It will pro= bably be the same as for NATs: In some networks timeout is 2 minutes, while= in others 60 minutes. Having something like PCP to check out that it indee= d is 60 min. would be extremely helpful. While most app developers might no= t be willing/able to optimize for battery/mobile, there are already some th= at are doing a good job. So there is hope that the new mechanisms would get= some traction. Markus >-----Original Message----- >From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf >Of ext Cameron Byrne >Sent: 06 August, 2012 01:22 >To: Tirumaleswar Reddy (tireddy) >Cc: Randell Jesup; rtcweb@ietf.org; phdgang@gmail.com >Subject: Re: [rtcweb] NAT behavior heuristics > >On Sun, Aug 5, 2012 at 3:05 PM, Tirumaleswar Reddy (tireddy) > wrote: >>> Fyi. I have not seen any traction for pcp anywhere in the mobile space. >> >> http://tools.ietf.org/html/draft-chen-pcp-mobile-deployment-01 describes >usage of PCP in Mobile Deployments. >> >> --Tiru. >> > >Yep, that's an I-D. > >And, it says things like "Without > the particular considerations , PCP may not provide desirable > outcomes. Some default behaviours may even cause negative impacts or > system failures in a mobile environment. " > >Got an operators with a timeline on supporting it? How about a mobile OS >that plans to support PCP, because you will need both. And, that would be >interesting information. > >I asked around in Vancouver about PCP, and all the operators i spoke to sa= id >no-plans, no motivation. But, that was a small sample. > >In any event, my only point is that RTCWEB should NOT be counting on PCP. = If >PCP is a tool you have, use it. My point: it is not a tool you have. > >CB >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb From cb.list6@gmail.com Tue Aug 7 08:11:05 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C29C221F86DE for ; Tue, 7 Aug 2012 08:11:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.464 X-Spam-Level: X-Spam-Status: No, score=-3.464 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oawKcLhqJMs5 for ; Tue, 7 Aug 2012 08:11:04 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8CFFA21F8665 for ; Tue, 7 Aug 2012 08:11:03 -0700 (PDT) Received: by lahm15 with SMTP id m15so2357480lah.31 for ; Tue, 07 Aug 2012 08:11:02 -0700 (PDT) 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=by2A7zQ1tRzhdLxi7iiV+z1dCvhNHiUNPOaMb00jp5U=; b=mx870O04PVeK51L0djPN3rh7tNCf0JAe6FTpH/Qei0FcFik6ixZpMYj78JgNzDeQNT fFjUCs3z5V/EJ+ScEjhZoZSZMZv0N+WQzG7/VfYTjGY8+2ce6Klf6tswvDIIKTK71Mus qIs+9s3sjdnIX0hjzgdBQtuhOy+P76/SbMVg8k4H64WuY+LPM4e6u30GG6fw5uCmAYYN jrgiOfam6pWU9tlZSzkvjj4EKiCP9SB4KLpUfiLdetMeNbdInwYemYZ96xYopAzFVS4y tfhzZJzrAtpySNoo4HwmE47IYZjuGIDOslhO2ku7gqY/trvym1bXYPaZps1YhPVioAkU R5qw== MIME-Version: 1.0 Received: by 10.112.44.163 with SMTP id f3mr6387716lbm.59.1344352262404; Tue, 07 Aug 2012 08:11:02 -0700 (PDT) Received: by 10.112.3.196 with HTTP; Tue, 7 Aug 2012 08:11:02 -0700 (PDT) Received: by 10.112.3.196 with HTTP; Tue, 7 Aug 2012 08:11:02 -0700 (PDT) In-Reply-To: References: <038b01cd70d6$8c5bc870$a5135950$@com> <04ff01cd7104$be09bed0$3a1d3c70$@com> <501E1E40.8070203@jesup.org> <913383AAA69FF945B8F946018B75898A1477C17F@xmb-rcd-x10.cisco.com> Date: Tue, 7 Aug 2012 08:11:02 -0700 Message-ID: From: Cameron Byrne To: Markus.Isomaki@nokia.com Content-Type: multipart/alternative; boundary=bcaec554d23e0dbcc604c6ae6751 Cc: randell-ietf@jesup.org, rtcweb@ietf.org, phdgang@gmail.com Subject: Re: [rtcweb] NAT behavior heuristics X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 07 Aug 2012 15:11:06 -0000 --bcaec554d23e0dbcc604c6ae6751 Content-Type: text/plain; charset=ISO-8859-1 On Aug 7, 2012 7:13 AM, wrote: > > Hi Cameron, > > Cameron Byrne wrote: > > > >I asked around in Vancouver about PCP, and all the operators i spoke to said > >no-plans, no motivation. But, that was a small sample. > > This is probably a fair assessment about the concrete plans. Most mobile operators don't even follow IETF much, so I doubt that they have even heard about PCP so far. There are however a few operators, where at least the research and standardization people have been interested in PCP (as witnessed by http://datatracker.ietf.org/doc/draft-chen-pcp-mobile-deployment/). I think some operators are also proposing PCP to be included in the 3GPP specs (release 12). It is hard to say how much that means in the real world, but at least I'd expect we could find a few operators willing to do real-network trials withing the next 12 months. > > Personally I see PCP as a very useful tool in the cellular access environment, for probing the NAT/FW timers and in the best case even setting them. It will be a major chicken-and-egg situation between apps, mobile OS's and the networks, to get anything into use. I think we should still do our best to overcome it. I agree that RTCWeb or anyone else should not rely on PCP (or any similar mechanim), but have the ability to make use of it if it happens to be available. > > I'm unconvinced IPv6 will help at all in this case. How do you know how long the FW on the path will keep its state up without keepalives? It will probably be the same as for NATs: In some networks timeout is 2 minutes, while in others 60 minutes. Having something like PCP to check out that it indeed is 60 min. would be extremely helpful. While most app developers might not be willing/able to optimize for battery/mobile, there are already some that are doing a good job. So there is hope that the new mechanisms would get some traction. > I know of one large USA mobile operator that is not SPI firewalling or tracking state for ipv6 mobiels, so this is not a problem for them. If operators choose to statefully inspect user traffic, those cost and limitations are assumed as part of the cost and service definition from the mobile operator. IMHO, SPI FW in ipv6 is not prudent or cost justified in mobile networks. CB > Markus > > > >-----Original Message----- > >From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf > >Of ext Cameron Byrne > >Sent: 06 August, 2012 01:22 > >To: Tirumaleswar Reddy (tireddy) > >Cc: Randell Jesup; rtcweb@ietf.org; phdgang@gmail.com > >Subject: Re: [rtcweb] NAT behavior heuristics > > > >On Sun, Aug 5, 2012 at 3:05 PM, Tirumaleswar Reddy (tireddy) > > wrote: > >>> Fyi. I have not seen any traction for pcp anywhere in the mobile space. > >> > >> http://tools.ietf.org/html/draft-chen-pcp-mobile-deployment-01describes > >usage of PCP in Mobile Deployments. > >> > >> --Tiru. > >> > > > >Yep, that's an I-D. > > > >And, it says things like "Without > > the particular considerations , PCP may not provide desirable > > outcomes. Some default behaviours may even cause negative impacts or > > system failures in a mobile environment. " > > > >Got an operators with a timeline on supporting it? How about a mobile OS > >that plans to support PCP, because you will need both. And, that would be > >interesting information. > > > >I asked around in Vancouver about PCP, and all the operators i spoke to said > >no-plans, no motivation. But, that was a small sample. > > > >In any event, my only point is that RTCWEB should NOT be counting on PCP. If > >PCP is a tool you have, use it. My point: it is not a tool you have. > > > >CB > >_______________________________________________ > >rtcweb mailing list > >rtcweb@ietf.org > >https://www.ietf.org/mailman/listinfo/rtcweb --bcaec554d23e0dbcc604c6ae6751 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Aug 7, 2012 7:13 AM, <Mar= kus.Isomaki@nokia.com> wrote:
>
> Hi Cameron,
>
> Cameron Byrne wrote:
> >
> >I asked around in Vancouver about PCP, and all the operators i spo= ke to said
> >no-plans, no motivation. =A0But, that was a small sample.
>
> This is probably a fair assessment about the concrete plans. Most mobi= le operators don't even follow IETF much, so I doubt that they have eve= n heard about PCP so far. There are however a few operators, where at least= the research and standardization people have been interested in PCP (as wi= tnessed by http://datatracker.ietf.org/doc/draft-chen-pcp-mobile-deploym= ent/). I think some operators are also proposing PCP to be included in = the 3GPP specs (release 12). It is hard to say how much that means in the r= eal world, but at least I'd expect we could find a few operators willin= g to do real-network trials withing the next 12 months.
>
> Personally I see PCP as a very useful tool in the cellular access envi= ronment, for probing the NAT/FW timers and in the best case even setting th= em. It will be a major chicken-and-egg situation between apps, mobile OS= 9;s and the networks, to get anything into use. I think we should still do = our best to overcome it. I agree that RTCWeb or anyone else should not rely= on PCP (or any similar mechanim), but have the ability to make use of it i= f it happens to be available.
>
> I'm unconvinced IPv6 will help at all in this case. How do you kno= w how long the FW on the path will keep its state up without keepalives? It= will probably be the same as for NATs: In some networks timeout is 2 minut= es, while in others 60 minutes. Having something like PCP to check out that= it indeed is 60 min. would be extremely helpful. While most app developers= might not be willing/able to optimize for battery/mobile, there are alread= y some that are doing a good job. So there is hope that the new mechanisms = would get some traction.
>

I know of one large USA mobile operator that is not SPI firewalling or t= racking state for ipv6 mobiels, so this is not a problem for them.

If operators choose to statefully inspect user traffic, those cost and l= imitations are assumed as part of the cost and service definition from the = mobile operator.

IMHO, SPI FW in ipv6 is not prudent or cost justified in mobile networks= .

CB

> Markus
>
>
> >-----Original Message-----
> >From: rtcweb-bounces@ie= tf.org [mailto:rtcweb-bounce= s@ietf.org] On Behalf
> >Of ext Cameron Byrne
> >Sent: 06 August, 2012 01:22
> >To: Tirumaleswar Reddy (tireddy)
> >Cc: Randell Jesup; rtcweb@ietf.= org; phdgang@gmail.com
> >Subject: Re: [rtcweb] NAT behavior heuristics
> >
> >On Sun, Aug 5, 2012 at 3:05 PM, Tirumaleswar Reddy (tireddy)
> ><tireddy@cisco.com>= wrote:
> >>> Fyi. I have not seen any traction for pcp anywhere in the= mobile space.
> >>
> >> http://tools.ietf.org/html/draft-chen-pcp-mobile-deployment-0= 1 describes
> >usage of PCP in Mobile Deployments.
> >>
> >> --Tiru.
> >>
> >
> >Yep, that's =A0an I-D.
> >
> >And, it says things like "Without
> > =A0 the particular considerations , PCP may not provide desirable=
> > =A0 outcomes. =A0Some default behaviours may even cause negative = impacts or
> > =A0 system failures in a mobile environment. =A0"
> >
> >Got an operators with a timeline on supporting it? =A0How about a = mobile OS
> >that plans to support PCP, because you will need both. =A0And, tha= t would be
> >interesting information.
> >
> >I asked around in Vancouver about PCP, and all the operators i spo= ke to said
> >no-plans, no motivation. =A0But, that was a small sample.
> >
> >In any event, my only point is that RTCWEB should NOT be counting = on PCP. =A0If
> >PCP is a tool you have, use it. =A0My point: it is not a tool you = have.
> >
> >CB
> >_______________________________________________
> >rtcweb mailing list
> >rtcweb@ietf.org
> >https://w= ww.ietf.org/mailman/listinfo/rtcweb

--bcaec554d23e0dbcc604c6ae6751-- From tireddy@cisco.com Tue Aug 7 08:37:34 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0086721F8718 for ; Tue, 7 Aug 2012 08:37:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.479 X-Spam-Level: X-Spam-Status: No, score=-10.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AkkX0JNJ2dfg for ; Tue, 7 Aug 2012 08:37:32 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 9C68721F8646 for ; Tue, 7 Aug 2012 08:37:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=tireddy@cisco.com; l=5083; q=dns/txt; s=iport; t=1344353852; x=1345563452; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Ywz6Xab3ofdm/UfH06yxZlYpUWkza0ME+4fN2+LaqhI=; b=ld3mRLsgPdWHzxJYapbTW8rmOruiyJ1eedw1euHQt3oQ2n+4U8HQpqCS SAQ9i1f5A7nY+6H+JzbJj09Q3sDfWI3TBNoKCDgGwsaphON7tJ4uP+DiD v8bIPuCQ3aSWoxIVngeVQKA8+7VlQYvUMqRX2B8sA1fwegIVcr/YsI4+8 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAB41IVCtJV2d/2dsb2JhbABFuUaBB4IgAQEBAgEBAQEBDwFbCwUHBAIBCA4DBAEBAQodByEGCxQJCAIEAQ0FCBqHXAMGBgubVJZ/DYlOiitkBYYIYAOIGItdgmeJdYMdgWaCXw X-IronPort-AV: E=Sophos;i="4.77,727,1336348800"; d="scan'208";a="109215442" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-8.cisco.com with ESMTP; 07 Aug 2012 15:37:30 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id q77FbUmW009782 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 7 Aug 2012 15:37:30 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.216]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0298.004; Tue, 7 Aug 2012 10:37:29 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Cameron Byrne , "Markus.Isomaki@nokia.com" Thread-Topic: [rtcweb] NAT behavior heuristics Thread-Index: Ac1w1ovfvzUgFxvbR0qnhkeGI2kOuAAVj+eAAAB2nYAAdXC7AAAK960AAAlqvrAACyyyAABTg5cAAAIELQAACfK/kA== Date: Tue, 7 Aug 2012 15:37:27 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A1477E4F7@xmb-rcd-x10.cisco.com> References: <038b01cd70d6$8c5bc870$a5135950$@com> <04ff01cd7104$be09bed0$3a1d3c70$@com> <501E1E40.8070203@jesup.org> <913383AAA69FF945B8F946018B75898A1477C17F@xmb-rcd-x10.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.85.252] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19090.005 x-tm-as-result: No--60.448700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "randell-ietf@jesup.org" , "rtcweb@ietf.org" , "phdgang@gmail.com" Subject: Re: [rtcweb] NAT behavior heuristics X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 07 Aug 2012 15:37:34 -0000 > I know of one large USA mobile operator that is not SPI firewalling or tr= acking state for ipv6 mobiels, so this is not a problem for them. > If operators choose to statefully inspect user traffic, those cost and li= mitations are assumed as part of the cost and service definition from the m= obile=20 > operator. > IMHO, SPI FW in ipv6 is not prudent or cost justified in mobile networks. http://www.bluecoat.com/sites/default/files/documents/files/Content_Filteri= ng_for_Mobile_Operators.pdf offers URL filtering based on user profile, claims to block Skype if sent o= ver port 80/443 (http://www.bluecoat.com/sites/default/files/documents/fil= es/How_Mobile_Operators_Can_Control_Skype.1.pdf), block viruses/worm. This = product is targeted for Mobile Operators.=20 --Tiru. From: Cameron Byrne [mailto:cb.list6@gmail.com]=20 Sent: Tuesday, August 07, 2012 8:41 PM To: Markus.Isomaki@nokia.com Cc: rtcweb@ietf.org; Tirumaleswar Reddy (tireddy); phdgang@gmail.com; rande= ll-ietf@jesup.org Subject: RE: [rtcweb] NAT behavior heuristics On Aug 7, 2012 7:13 AM, wrote: > > Hi Cameron, > > Cameron Byrne wrote: > > > >I asked around in Vancouver about PCP, and all the operators i spoke to = said > >no-plans, no motivation. =A0But, that was a small sample. > > This is probably a fair assessment about the concrete plans. Most mobile = operators don't even follow IETF much, so I doubt that they have even heard= about PCP so far. There are however a few operators, where at least the re= search and standardization people have been interested in PCP (as witnessed= by http://datatracker.ietf.org/doc/draft-chen-pcp-mobile-deployment/). I t= hink some operators are also proposing PCP to be included in the 3GPP specs= (release 12). It is hard to say how much that means in the real world, but= at least I'd expect we could find a few operators willing to do real-netwo= rk trials withing the next 12 months. > > Personally I see PCP as a very useful tool in the cellular access environ= ment, for probing the NAT/FW timers and in the best case even setting them.= It will be a major chicken-and-egg situation between apps, mobile OS's and= the networks, to get anything into use. I think we should still do our bes= t to overcome it. I agree that RTCWeb or anyone else should not rely on PCP= (or any similar mechanim), but have the ability to make use of it if it ha= ppens to be available. > > I'm unconvinced IPv6 will help at all in this case. How do you know how l= ong the FW on the path will keep its state up without keepalives? It will p= robably be the same as for NATs: In some networks timeout is 2 minutes, whi= le in others 60 minutes. Having something like PCP to check out that it ind= eed is 60 min. would be extremely helpful. While most app developers might = not be willing/able to optimize for battery/mobile, there are already some = that are doing a good job. So there is hope that the new mechanisms would g= et some traction. > I know of one large USA mobile operator that is not SPI firewalling or trac= king state for ipv6 mobiels, so this is not a problem for them. If operators choose to statefully inspect user traffic, those cost and limi= tations are assumed as part of the cost and service definition from the mob= ile operator. IMHO, SPI FW in ipv6 is not prudent or cost justified in mobile networks.=20 CB > Markus > > > >-----Original Message----- > >From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf > >Of ext Cameron Byrne > >Sent: 06 August, 2012 01:22 > >To: Tirumaleswar Reddy (tireddy) > >Cc: Randell Jesup; rtcweb@ietf.org; phdgang@gmail.com > >Subject: Re: [rtcweb] NAT behavior heuristics > > > >On Sun, Aug 5, 2012 at 3:05 PM, Tirumaleswar Reddy (tireddy) > > wrote: > >>> Fyi. I have not seen any traction for pcp anywhere in the mobile spac= e. > >> > >> http://tools.ietf.org/html/draft-chen-pcp-mobile-deployment-01 describ= es > >usage of PCP in Mobile Deployments. > >> > >> --Tiru. > >> > > > >Yep, that's =A0an I-D. > > > >And, it says things like "Without > > =A0 the particular considerations , PCP may not provide desirable > > =A0 outcomes. =A0Some default behaviours may even cause negative impact= s or > > =A0 system failures in a mobile environment. =A0" > > > >Got an operators with a timeline on supporting it? =A0How about a mobile= OS > >that plans to support PCP, because you will need both. =A0And, that woul= d be > >interesting information. > > > >I asked around in Vancouver about PCP, and all the operators i spoke to = said > >no-plans, no motivation. =A0But, that was a small sample. > > > >In any event, my only point is that RTCWEB should NOT be counting on PCP= . =A0If > >PCP is a tool you have, use it. =A0My point: it is not a tool you have. > > > >CB > >_______________________________________________ > >rtcweb mailing list > >rtcweb@ietf.org > >https://www.ietf.org/mailman/listinfo/rtcweb From lorenzo@meetecho.com Tue Aug 7 09:08:06 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0E5E21F8652 for ; Tue, 7 Aug 2012 09:08:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5kHpR1vo+giC for ; Tue, 7 Aug 2012 09:08:05 -0700 (PDT) Received: from smtplq04.aruba.it (smtplq-out6.aruba.it [62.149.158.26]) by ietfa.amsl.com (Postfix) with SMTP id 5E51921F8674 for ; Tue, 7 Aug 2012 09:08:05 -0700 (PDT) Received: (qmail 1661 invoked by uid 89); 7 Aug 2012 16:08:03 -0000 Received: from unknown (HELO smtp5.aruba.it) (62.149.158.225) by smtplq04.aruba.it with SMTP; 7 Aug 2012 16:08:03 -0000 Received: (qmail 7522 invoked by uid 89); 7 Aug 2012 16:08:03 -0000 Received: from unknown (HELO rainpc) (lorenzo@meetecho.com@80.181.173.222) by smtp5.ad.aruba.it with SMTP; 7 Aug 2012 16:08:03 -0000 Date: Tue, 7 Aug 2012 18:01:56 +0200 From: Lorenzo Miniero To: rtcweb@ietf.org Message-ID: <20120807180156.286e74d2@rainpc> Organization: Meetecho X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.8; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Rating: smtp5.ad.aruba.it 1.6.2 0/1000/N X-Spam-Rating: smtplq04.aruba.it 1.6.2 0/1000/N Subject: [rtcweb] HTTP Fallback draft X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 07 Aug 2012 16:08:07 -0000 Dear all, during the meeting in Vancouver, there was some discussion about the need we have for UDP-blocking firewall traversal in RTCWEB. HTTP fallback was mentioned, and I remember it being a matter of discussion at the latest interim meeting as well (at least looking at the minutes), even though it hasn't apparently been addressed on the ML since. Something in line with this was also discussed in Prague at the BOF, when it was clearly quite too early to address. Someone suggested that, rather than trying to address the issue right away, it could be better to first try and summarize as a BCP draft what people already do in that respect: it's quite obvious, in fact, that this is already being done by many companies in their deployments, even though probably in a non-standard way. Since the subject interests me (during the abovementioned IETF in Prague we brought a simple demo, which we used to informally showcase to a few interested folks the basic prototype refrlecting our research in that field) I chose to write a simple individual draft, instead, that rather than doing the summary, basically documents the first steps we did with our prototype. You can read the draft here: http://www.ietf.org/id/draft-miniero-rtcweb-http-fallback-00.txt Please beware that it is not at all meant to be a ready-to-be-used solution to the problem, quite the opposite. I wrote the draft in a few hours and it simply addresses what we started to do to try and address the problem, and, as it will be obvious when reading the draft, it is all but complete with respect to what such a solution is supposed to make available: nevertheless, it tries to explain the basics of what may be needed, even if much more is still missing. Its purpose is rather trying to "throw a stone in the lake", as we like to say in Italy, in order to draw attention on the problem and gather potential interest by other people to work on it, whether or not such work would be based on this draft. I placed a few Editors Notes across the text on some of the most controversial issues, like how this should mix with ICE and negotiation, how easy it should be to detect it and so on. Other even more controversial ones, like how to address the impact of congestion control on real-time streams, is not in the document as of yet, but it's clear this will have to be taken care of eventually. Feedback and suggestions are more than welcome! That said, I guess there's a different question I should be asking to the chairs: since there seems to be no related item in the milestones, is such a work actually in line with what is the expected outcome of the WG? Considering the draft basically addresses a new transport for RTP and something that probably needs to be negotiated as well, I guess this could be seen as belonging elsewhere (AVTCORE and/or MMUSIC?). Nevertheless, my feeling is it belongs more here than somewhere else, especially considering we're specifying a solution that will be deployed in browsers and, as such, people will expect it to work wherever other web applications do. Thanks, Lorenzo -- Lorenzo Miniero, COB Meetecho s.r.l. Web Conferencing and Collaboration Tools http://www.meetecho.com From cb.list6@gmail.com Tue Aug 7 09:08:42 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7C0521F8652 for ; Tue, 7 Aug 2012 09:08:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.47 X-Spam-Level: X-Spam-Status: No, score=-3.47 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dq+UWJuSNQBV for ; Tue, 7 Aug 2012 09:08:41 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 04F3D21F8716 for ; Tue, 7 Aug 2012 09:08:40 -0700 (PDT) Received: by lbbgg6 with SMTP id gg6so1204961lbb.31 for ; Tue, 07 Aug 2012 09:08:39 -0700 (PDT) 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:content-transfer-encoding; bh=Tt7wqVPl3jQsHxbCkrxVfdn5KPX+EEeTzhAhHsvw2Vs=; b=TBcEY7ZEuHqyZikHADcYbkoljKmNuLD6XC9x85kaQNjaybTqdYcNDbSsFISYJxQRZ7 OWN/+bRQHOcWsaMfTU2w3/4KrIInQ3+3wdtHhZOxLyN7HpHeY89pYRcA+E4OxNC6fsKp VV03v45Rd5oC0EXBQacVmExdgxyACBraBnD0HAebU7GiDvPVhw8BidnouUBN68LpWEoo b7aRAV/VGFG0YOs4o1LAhsII7KsJduGgwNHLcVSx3iXWykGFZQ2bUxtBRTd3d9aZWyqt hziK5fTC/Aj2pNMfH/AdVlzSpstpxqik8U+LaSCsW84GD6pZnSLEVRUxAEY1uo3ONgtr sbxg== MIME-Version: 1.0 Received: by 10.112.84.39 with SMTP id v7mr6610057lby.15.1344355719565; Tue, 07 Aug 2012 09:08:39 -0700 (PDT) Received: by 10.112.3.196 with HTTP; Tue, 7 Aug 2012 09:08:39 -0700 (PDT) In-Reply-To: <913383AAA69FF945B8F946018B75898A1477E4F7@xmb-rcd-x10.cisco.com> References: <038b01cd70d6$8c5bc870$a5135950$@com> <04ff01cd7104$be09bed0$3a1d3c70$@com> <501E1E40.8070203@jesup.org> <913383AAA69FF945B8F946018B75898A1477C17F@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A1477E4F7@xmb-rcd-x10.cisco.com> Date: Tue, 7 Aug 2012 09:08:39 -0700 Message-ID: From: Cameron Byrne To: "Tirumaleswar Reddy (tireddy)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "randell-ietf@jesup.org" , "phdgang@gmail.com" , "rtcweb@ietf.org" Subject: Re: [rtcweb] NAT behavior heuristics X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 07 Aug 2012 16:08:43 -0000 On Tue, Aug 7, 2012 at 8:37 AM, Tirumaleswar Reddy (tireddy) wrote: >> I know of one large USA mobile operator that is not SPI firewalling or t= racking state for ipv6 mobiels, so this is not a problem for them. >> If operators choose to statefully inspect user traffic, those cost and l= imitations are assumed as part of the cost and service definition from the = mobile >> operator. >> IMHO, SPI FW in ipv6 is not prudent or cost justified in mobile networks= . > > http://www.bluecoat.com/sites/default/files/documents/files/Content_Filte= ring_for_Mobile_Operators.pdf > offers URL filtering based on user profile, claims to block Skype if sent= over port 80/443 (http://www.bluecoat.com/sites/default/files/documents/f= iles/How_Mobile_Operators_Can_Control_Skype.1.pdf), block viruses/worm. Thi= s product is targeted for Mobile Operators. > Since you just sent URLs without an explanation, i am not sure the intent of your email. If you are suggesting that mobile operators should buy this product to block Skype, you are probably on the wrong mailing list. If you are suggesting mobile operators should buy this product to block Skype and then use PCP to allow Skype, .... Not sure that will get much traction either. CB > --Tiru. > > > From: Cameron Byrne [mailto:cb.list6@gmail.com] > Sent: Tuesday, August 07, 2012 8:41 PM > To: Markus.Isomaki@nokia.com > Cc: rtcweb@ietf.org; Tirumaleswar Reddy (tireddy); phdgang@gmail.com; ran= dell-ietf@jesup.org > Subject: RE: [rtcweb] NAT behavior heuristics > > > On Aug 7, 2012 7:13 AM, wrote: >> >> Hi Cameron, >> >> Cameron Byrne wrote: >> > >> >I asked around in Vancouver about PCP, and all the operators i spoke to= said >> >no-plans, no motivation. But, that was a small sample. >> >> This is probably a fair assessment about the concrete plans. Most mobile= operators don't even follow IETF much, so I doubt that they have even hear= d about PCP so far. There are however a few operators, where at least the r= esearch and standardization people have been interested in PCP (as witnesse= d by http://datatracker.ietf.org/doc/draft-chen-pcp-mobile-deployment/). I = think some operators are also proposing PCP to be included in the 3GPP spec= s (release 12). It is hard to say how much that means in the real world, bu= t at least I'd expect we could find a few operators willing to do real-netw= ork trials withing the next 12 months. >> >> Personally I see PCP as a very useful tool in the cellular access enviro= nment, for probing the NAT/FW timers and in the best case even setting them= . It will be a major chicken-and-egg situation between apps, mobile OS's an= d the networks, to get anything into use. I think we should still do our be= st to overcome it. I agree that RTCWeb or anyone else should not rely on PC= P (or any similar mechanim), but have the ability to make use of it if it h= appens to be available. >> >> I'm unconvinced IPv6 will help at all in this case. How do you know how = long the FW on the path will keep its state up without keepalives? It will = probably be the same as for NATs: In some networks timeout is 2 minutes, wh= ile in others 60 minutes. Having something like PCP to check out that it in= deed is 60 min. would be extremely helpful. While most app developers might= not be willing/able to optimize for battery/mobile, there are already some= that are doing a good job. So there is hope that the new mechanisms would = get some traction. >> > I know of one large USA mobile operator that is not SPI firewalling or tr= acking state for ipv6 mobiels, so this is not a problem for them. > If operators choose to statefully inspect user traffic, those cost and li= mitations are assumed as part of the cost and service definition from the m= obile operator. > IMHO, SPI FW in ipv6 is not prudent or cost justified in mobile networks. > CB >> Markus >> >> >> >-----Original Message----- >> >From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behal= f >> >Of ext Cameron Byrne >> >Sent: 06 August, 2012 01:22 >> >To: Tirumaleswar Reddy (tireddy) >> >Cc: Randell Jesup; rtcweb@ietf.org; phdgang@gmail.com >> >Subject: Re: [rtcweb] NAT behavior heuristics >> > >> >On Sun, Aug 5, 2012 at 3:05 PM, Tirumaleswar Reddy (tireddy) >> > wrote: >> >>> Fyi. I have not seen any traction for pcp anywhere in the mobile spa= ce. >> >> >> >> http://tools.ietf.org/html/draft-chen-pcp-mobile-deployment-01 descri= bes >> >usage of PCP in Mobile Deployments. >> >> >> >> --Tiru. >> >> >> > >> >Yep, that's an I-D. >> > >> >And, it says things like "Without >> > the particular considerations , PCP may not provide desirable >> > outcomes. Some default behaviours may even cause negative impacts o= r >> > system failures in a mobile environment. " >> > >> >Got an operators with a timeline on supporting it? How about a mobile = OS >> >that plans to support PCP, because you will need both. And, that would= be >> >interesting information. >> > >> >I asked around in Vancouver about PCP, and all the operators i spoke to= said >> >no-plans, no motivation. But, that was a small sample. >> > >> >In any event, my only point is that RTCWEB should NOT be counting on PC= P. If >> >PCP is a tool you have, use it. My point: it is not a tool you have. >> > >> >CB >> >_______________________________________________ >> >rtcweb mailing list >> >rtcweb@ietf.org >> >https://www.ietf.org/mailman/listinfo/rtcweb From tireddy@cisco.com Tue Aug 7 09:20:09 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B4F921F8767 for ; Tue, 7 Aug 2012 09:20:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.499 X-Spam-Level: X-Spam-Status: No, score=-10.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Bg6KQdk9h+A for ; Tue, 7 Aug 2012 09:20:06 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 6D21921F8799 for ; Tue, 7 Aug 2012 09:20:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=tireddy@cisco.com; l=6994; q=dns/txt; s=iport; t=1344356406; x=1345566006; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Np581ndab8H/XIFDmhObw8uOf0VCTBDVj0d+wP81Y4c=; b=jCn95njulqha0bLzsMofQ3AZ1XHe+T4EusXmuPPbyODKIojdFZjtat3O jyns7dAHs7bL/ZYl0BvvUxLpYT6BLWfMlhHGxT+FuVi/+XDY60c4gB7J8 9yQWohBbsyt+J04jtlEa87nVVQD/Uinyb9QOH+C8ktpPnUejbHErGOCVV 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAMs/IVCtJV2Y/2dsb2JhbABFuWWBB4IgAQEBAwEBAQEPASc0CwUHBAIBCA4DBAEBAQoUCQchBgsUCQgCBA4FCBqHXAMGBgubVZZ+DYlOiitkBYV7YAOTdYJniXWDHYFmgl+BXw X-IronPort-AV: E=Sophos;i="4.77,728,1336348800"; d="scan'208";a="109219514" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-6.cisco.com with ESMTP; 07 Aug 2012 16:20:03 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q77GK36k004979 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 7 Aug 2012 16:20:03 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.216]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0298.004; Tue, 7 Aug 2012 11:20:02 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Cameron Byrne Thread-Topic: [rtcweb] NAT behavior heuristics Thread-Index: Ac1w1ovfvzUgFxvbR0qnhkeGI2kOuAAVj+eAAAB2nYAAdXC7AAAK960AAAlqvrAACyyyAABTg5cAAAIELQAACfK/kP//wIOAgABTl8A= Date: Tue, 7 Aug 2012 16:20:02 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A1477E5A0@xmb-rcd-x10.cisco.com> References: <038b01cd70d6$8c5bc870$a5135950$@com> <04ff01cd7104$be09bed0$3a1d3c70$@com> <501E1E40.8070203@jesup.org> <913383AAA69FF945B8F946018B75898A1477C17F@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A1477E4F7@xmb-rcd-x10.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.85.252] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19090.005 x-tm-as-result: No--68.006000-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "randell-ietf@jesup.org" , "phdgang@gmail.com" , "rtcweb@ietf.org" Subject: Re: [rtcweb] NAT behavior heuristics X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 07 Aug 2012 16:20:09 -0000 > If you are suggesting that mobile operators should buy this product to > block Skype, you are probably on the wrong mailing list. I am not selling this product. I am just saying that these products are off= ered to Mobile Operators to detect Port Misuse/for other security purposes = like detecting viruses and hence the Mobile Network will have a firewall/IP= S that will do DPI. My argument is IPv6 Firewall/IPS in various modes like = content filtering, Application Visibility and Control when deployed in Mobi= le Network will have sessions just like NAT but a different purpose and wil= l have timeout mechanism. PCP can also be used to avoid keep-alive for Fire= wall sessions. It's up to the Mobile Operator policy to permit the flow or = not, honor the PCP request or not to permit certain flow. --Tiru. > -----Original Message----- > From: Cameron Byrne [mailto:cb.list6@gmail.com] > Sent: Tuesday, August 07, 2012 9:39 PM > To: Tirumaleswar Reddy (tireddy) > Cc: Markus.Isomaki@nokia.com; rtcweb@ietf.org; phdgang@gmail.com; > randell-ietf@jesup.org > Subject: Re: [rtcweb] NAT behavior heuristics >=20 > On Tue, Aug 7, 2012 at 8:37 AM, Tirumaleswar Reddy (tireddy) > wrote: > >> I know of one large USA mobile operator that is not SPI firewalling > or tracking state for ipv6 mobiels, so this is not a problem for them. > >> If operators choose to statefully inspect user traffic, those cost > and limitations are assumed as part of the cost and service definition > from the mobile > >> operator. > >> IMHO, SPI FW in ipv6 is not prudent or cost justified in mobile > networks. > > > > > http://www.bluecoat.com/sites/default/files/documents/files/Content_Fil > tering_for_Mobile_Operators.pdf > > offers URL filtering based on user profile, claims to block Skype if > sent over port 80/443 > (http://www.bluecoat.com/sites/default/files/documents/files/How_Mobile > _Operators_Can_Control_Skype.1.pdf), block viruses/worm. This product > is targeted for Mobile Operators. > > >=20 > Since you just sent URLs without an explanation, i am not sure the > intent of your email. >=20 > If you are suggesting that mobile operators should buy this product to > block Skype, you are probably on the wrong mailing list. >=20 > If you are suggesting mobile operators should buy this product to > block Skype and then use PCP to allow Skype, .... Not sure that will > get much traction either. >=20 > CB >=20 > > --Tiru. > > > > > > From: Cameron Byrne [mailto:cb.list6@gmail.com] > > Sent: Tuesday, August 07, 2012 8:41 PM > > To: Markus.Isomaki@nokia.com > > Cc: rtcweb@ietf.org; Tirumaleswar Reddy (tireddy); phdgang@gmail.com; > randell-ietf@jesup.org > > Subject: RE: [rtcweb] NAT behavior heuristics > > > > > > On Aug 7, 2012 7:13 AM, wrote: > >> > >> Hi Cameron, > >> > >> Cameron Byrne wrote: > >> > > >> >I asked around in Vancouver about PCP, and all the operators i > spoke to said > >> >no-plans, no motivation. But, that was a small sample. > >> > >> This is probably a fair assessment about the concrete plans. Most > mobile operators don't even follow IETF much, so I doubt that they have > even heard about PCP so far. There are however a few operators, where > at least the research and standardization people have been interested > in PCP (as witnessed by http://datatracker.ietf.org/doc/draft-chen-pcp- > mobile-deployment/). I think some operators are also proposing PCP to > be included in the 3GPP specs (release 12). It is hard to say how much > that means in the real world, but at least I'd expect we could find a > few operators willing to do real-network trials withing the next 12 > months. > >> > >> Personally I see PCP as a very useful tool in the cellular access > environment, for probing the NAT/FW timers and in the best case even > setting them. It will be a major chicken-and-egg situation between > apps, mobile OS's and the networks, to get anything into use. I think > we should still do our best to overcome it. I agree that RTCWeb or > anyone else should not rely on PCP (or any similar mechanim), but have > the ability to make use of it if it happens to be available. > >> > >> I'm unconvinced IPv6 will help at all in this case. How do you know > how long the FW on the path will keep its state up without keepalives? > It will probably be the same as for NATs: In some networks timeout is 2 > minutes, while in others 60 minutes. Having something like PCP to check > out that it indeed is 60 min. would be extremely helpful. While most > app developers might not be willing/able to optimize for > battery/mobile, there are already some that are doing a good job. So > there is hope that the new mechanisms would get some traction. > >> > > I know of one large USA mobile operator that is not SPI firewalling > or tracking state for ipv6 mobiels, so this is not a problem for them. > > If operators choose to statefully inspect user traffic, those cost > and limitations are assumed as part of the cost and service definition > from the mobile operator. > > IMHO, SPI FW in ipv6 is not prudent or cost justified in mobile > networks. > > CB > >> Markus > >> > >> > >> >-----Original Message----- > >> >From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > Behalf > >> >Of ext Cameron Byrne > >> >Sent: 06 August, 2012 01:22 > >> >To: Tirumaleswar Reddy (tireddy) > >> >Cc: Randell Jesup; rtcweb@ietf.org; phdgang@gmail.com > >> >Subject: Re: [rtcweb] NAT behavior heuristics > >> > > >> >On Sun, Aug 5, 2012 at 3:05 PM, Tirumaleswar Reddy (tireddy) > >> > wrote: > >> >>> Fyi. I have not seen any traction for pcp anywhere in the mobile > space. > >> >> > >> >> http://tools.ietf.org/html/draft-chen-pcp-mobile-deployment-01 > describes > >> >usage of PCP in Mobile Deployments. > >> >> > >> >> --Tiru. > >> >> > >> > > >> >Yep, that's an I-D. > >> > > >> >And, it says things like "Without > >> > the particular considerations , PCP may not provide desirable > >> > outcomes. Some default behaviours may even cause negative > impacts or > >> > system failures in a mobile environment. " > >> > > >> >Got an operators with a timeline on supporting it? How about a > mobile OS > >> >that plans to support PCP, because you will need both. And, that > would be > >> >interesting information. > >> > > >> >I asked around in Vancouver about PCP, and all the operators i > spoke to said > >> >no-plans, no motivation. But, that was a small sample. > >> > > >> >In any event, my only point is that RTCWEB should NOT be counting > on PCP. If > >> >PCP is a tool you have, use it. My point: it is not a tool you > have. > >> > > >> >CB > >> >_______________________________________________ > >> >rtcweb mailing list > >> >rtcweb@ietf.org > >> >https://www.ietf.org/mailman/listinfo/rtcweb From hannes.tschofenig@gmx.net Tue Aug 7 09:38:57 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FF3621F8683 for ; Tue, 7 Aug 2012 09:38:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.615 X-Spam-Level: X-Spam-Status: No, score=-102.615 tagged_above=-999 required=5 tests=[AWL=-0.016, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 80UhAPWFvNLd for ; Tue, 7 Aug 2012 09:38:56 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id E145C21F84F2 for ; Tue, 7 Aug 2012 09:38:55 -0700 (PDT) Received: (qmail invoked by alias); 07 Aug 2012 16:38:54 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.105]) [88.115.216.191] by mail.gmx.net (mp041) with SMTP; 07 Aug 2012 18:38:54 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18TEmMUlbMTPg0gL8H/REJTLGh14HDAW4+NeL7g+d acDZG2Lb7j4Dzq Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <20120807180156.286e74d2@rainpc> Date: Tue, 7 Aug 2012 19:38:52 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120807180156.286e74d2@rainpc> To: Lorenzo Miniero X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] HTTP Fallback draft X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 07 Aug 2012 16:38:57 -0000 Hi Lorenzo,=20 working on http://tools.ietf.org/html/draft-tschofenig-hourglass-00 (and = Marc on draft-blanchet-iab-internetoverport443) I am wondering about the = following aspect:=20 1) Do you have experience with network elements filtering RTP traffic? = If so, in what networks did that happen? 2) In case you answered question #1 with 'yes' I would also like to = understand why you believe that HTTP traffic will be allowed to = traverse? Wouldn't you have to switch to HTTPS instead?=20 Just to be clear, I don't have objections regarding your draft. I just = would like to understand what motives people to run everything over HTTP = (besides using HTTP features, which you don't really do).=20 Ciao Hannes On Aug 7, 2012, at 7:01 PM, Lorenzo Miniero wrote: > Dear all, >=20 > during the meeting in Vancouver, there was some discussion about the > need we have for UDP-blocking firewall traversal in RTCWEB. HTTP > fallback was mentioned, and I remember it being a matter of discussion > at the latest interim meeting as well (at least looking at the = minutes), > even though it hasn't apparently been addressed on the ML since. > Something in line with this was also discussed in Prague at the BOF, > when it was clearly quite too early to address. >=20 > Someone suggested that, rather than trying to address the issue right > away, it could be better to first try and summarize as a BCP draft = what > people already do in that respect: it's quite obvious, in fact, that > this is already being done by many companies in their deployments, = even > though probably in a non-standard way. >=20 > Since the subject interests me (during the abovementioned IETF in = Prague > we brought a simple demo, which we used to informally showcase to a = few > interested folks the basic prototype refrlecting our research in that > field) I chose to write a simple individual draft, instead, that = rather > than doing the summary, basically documents the first steps we did = with > our prototype. You can read the draft here: >=20 > http://www.ietf.org/id/draft-miniero-rtcweb-http-fallback-00.txt >=20 > Please beware that it is not at all meant to be a ready-to-be-used > solution to the problem, quite the opposite. I wrote the draft in a = few > hours and it simply addresses what we started to do to try and address > the problem, and, as it will be obvious when reading the draft, it is > all but complete with respect to what such a solution is supposed to > make available: nevertheless, it tries to explain the basics of what = may > be needed, even if much more is still missing. Its purpose is rather > trying to "throw a stone in the lake", as we like to say in Italy, in > order to draw attention on the problem and gather potential interest = by > other people to work on it, whether or not such work would be based on > this draft. I placed a few Editors Notes across the text on some of = the > most controversial issues, like how this should mix with ICE and > negotiation, how easy it should be to detect it and so on. Other even > more controversial ones, like how to address the impact of congestion > control on real-time streams, is not in the document as of yet, but = it's > clear this will have to be taken care of eventually. Feedback and > suggestions are more than welcome! >=20 > That said, I guess there's a different question I should be asking to > the chairs: since there seems to be no related item in the milestones, > is such a work actually in line with what is the expected outcome of = the > WG? Considering the draft basically addresses a new transport for RTP > and something that probably needs to be negotiated as well, I guess = this > could be seen as belonging elsewhere (AVTCORE and/or MMUSIC?). > Nevertheless, my feeling is it belongs more here than somewhere else, > especially considering we're specifying a solution that will be = deployed > in browsers and, as such, people will expect it to work wherever other > web applications do. >=20 > Thanks, > Lorenzo >=20 > --=20 > Lorenzo Miniero, COB >=20 > Meetecho s.r.l. > Web Conferencing and Collaboration Tools > http://www.meetecho.com > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From ekr@rtfm.com Tue Aug 7 10:15:14 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EB2821F85D0 for ; Tue, 7 Aug 2012 10:15:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id acQs5g5N9aNO for ; Tue, 7 Aug 2012 10:15:13 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 017EE21F859A for ; Tue, 7 Aug 2012 10:15:12 -0700 (PDT) Received: by eekb45 with SMTP id b45so1209322eek.31 for ; Tue, 07 Aug 2012 10:15:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:from:date:message-id:subject:to :content-type:x-gm-message-state; bh=3FDotlogrZAlUjvXogMwulOSo7LKjQ3PNI5I6+7M4d8=; b=JokYZJfqQbUXR7zQagwtgVnzkubJh3q7FnSps/SvPhUHDPqhHVkwU3KyeBzfahFxji LyjvvP70H2BKBKXC6iolu7Sh4XtxOrBhKq0pSgp0+oAKD7FAVTL9GUtyhnJdY1neQR7C 2SaZyJ4GEzgxU8VrhajJS199uF0uI47+cP7Thp8af/mJ7YgwbMxCcX3e+s7bkD8Psaok f96CPpyH765q+lA+W/HpBSNvWd8eu+l/JhDFK15ftsuCA2B+4a4iHcZKLtoYSoXQTKio O0kKc5z1TZJ7MeJdhRVbRsFbpTx2/Cp8XiJtdFtAfGnGbhf1MW+1stgdUKvxU2LVm3ha S3Kg== Received: by 10.14.216.198 with SMTP id g46mr18769008eep.32.1344359712135; Tue, 07 Aug 2012 10:15:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.14.224.199 with HTTP; Tue, 7 Aug 2012 10:14:31 -0700 (PDT) X-Originating-IP: [63.245.220.224] From: Eric Rescorla Date: Tue, 7 Aug 2012 10:14:31 -0700 Message-ID: To: public-webrtc@w3.org, rtcweb@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQm1Rr1y9nsm11BkySA7tMIr9LUwEzCgjOlMR9u5m7IA6DMbX0p3vSVzuYN3pJRQJWW0TzxK Subject: [rtcweb] Initial notes on MS proposal X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 07 Aug 2012 17:15:14 -0000 I've gone over MS's proposal and written up some initial notes: http://www.educatedguesswork.org/2012/08/initial_notes_on_microsofts_cu.html -Ekr From ekr@rtfm.com Tue Aug 7 10:18:36 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A99A221F859A for ; Tue, 7 Aug 2012 10:18:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5rXA46lKQnaR for ; Tue, 7 Aug 2012 10:18:36 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id C7F5121F8599 for ; Tue, 7 Aug 2012 10:18:35 -0700 (PDT) Received: by eekb45 with SMTP id b45so1210136eek.31 for ; Tue, 07 Aug 2012 10:18:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:content-type:x-gm-message-state; bh=xtTRoujh++rwIsooSqMBXNvOzw1jmjeecrpS+dgFomY=; b=Qc/LGlLT5wTcXy3ftE2QgcGaily+/0ulqFgOSohEL2JdvgvFbZfVs+YAzfzL0/UTmt n2XZE1xcNLqy+084RwTfq0vf8JGC8jjgSw8pyPUZ9tY4qxKDkTDFD1Nm664gAKeIuvdl MqkavNUVTaYPf8T5tK6hslBBa8rW7e7wsGMdUOsPGj96ZQjc7ZW27X/IQ9nGVG/ADZwL LqXLNxY8NEmPkwPsCY1lAlOFLPiBUar2GSgoI53xFI+0ieP48t9c1FtSjMFSBmKYHtvy UQJ+JtW9aBAD7/dC/4vP9VeaEsdZRIDFnGsC3C7Nb4YyQSN/p/KJAxMPg7g8vUPdjzCw 9aww== Received: by 10.14.223.9 with SMTP id u9mr18625635eep.10.1344359914855; Tue, 07 Aug 2012 10:18:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.14.224.199 with HTTP; Tue, 7 Aug 2012 10:17:54 -0700 (PDT) X-Originating-IP: [63.245.220.224] In-Reply-To: References: From: Eric Rescorla Date: Tue, 7 Aug 2012 10:17:54 -0700 Message-ID: To: public-webrtc@w3.org, rtcweb@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQns6KdvN26PqOFwxrZ4a8pG+5GhXMA1tEbs93lMoDnL3EZ75ujxJMOwjH0lV1MK8SeFCBVx Subject: Re: [rtcweb] Initial notes on MS proposal X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 07 Aug 2012 17:18:37 -0000 FWIW, I'm finding that CU-RTC-Web is a bit of a mouthful. I hereby propose the pronunciation "Curtsy-Web" -Ekr On Tue, Aug 7, 2012 at 10:14 AM, Eric Rescorla wrote: > I've gone over MS's proposal and written up some initial notes: > > http://www.educatedguesswork.org/2012/08/initial_notes_on_microsofts_cu.html > > -Ekr From lorenzo@meetecho.com Tue Aug 7 10:18:37 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6B7E21F8599 for ; Tue, 7 Aug 2012 10:18:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E-Xpmrn-fsH7 for ; Tue, 7 Aug 2012 10:18:36 -0700 (PDT) Received: from smtplq03.aruba.it (smtplq-out5.aruba.it [62.149.158.25]) by ietfa.amsl.com (Postfix) with SMTP id AE20021F8592 for ; Tue, 7 Aug 2012 10:18:35 -0700 (PDT) Received: (qmail 24552 invoked by uid 89); 7 Aug 2012 17:18:34 -0000 Received: from unknown (HELO smtp7.aruba.it) (62.149.158.227) by smtplq03.aruba.it with SMTP; 7 Aug 2012 17:18:34 -0000 Received: (qmail 21143 invoked by uid 89); 7 Aug 2012 17:18:34 -0000 Received: from unknown (HELO rainpc) (lorenzo@meetecho.com@80.181.173.222) by smtp7.ad.aruba.it with SMTP; 7 Aug 2012 17:18:33 -0000 Date: Tue, 7 Aug 2012 19:12:26 +0200 From: Lorenzo Miniero To: Hannes Tschofenig Message-ID: <20120807191226.5b8e7f32@rainpc> In-Reply-To: References: <20120807180156.286e74d2@rainpc> Organization: Meetecho X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.8; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Rating: smtp7.ad.aruba.it 1.6.2 0/1000/N X-Spam-Rating: smtplq03.aruba.it 1.6.2 0/1000/N Cc: rtcweb@ietf.org Subject: Re: [rtcweb] HTTP Fallback draft X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 07 Aug 2012 17:18:37 -0000 Hi Hannes, answering inline, On Tue, 7 Aug 2012 19:38:52 +0300 Hannes Tschofenig wrote: > Hi Lorenzo, > > working on http://tools.ietf.org/html/draft-tschofenig-hourglass-00 (and Marc on draft-blanchet-iab-internetoverport443) I am wondering about the following aspect: > > 1) Do you have experience with network elements filtering RTP traffic? If so, in what networks did that happen? > We indeed met such network elements in our experience, even though most of the times it was just blind UDP filtering rather than RTP filtering per se. It sometimes was just blind port filtering but the effect was the same. This mostly happened within enterprises networks where we tried, no matter how small or large. > 2) In case you answered question #1 with 'yes' I would also like to understand why you believe that HTTP traffic will be allowed to traverse? Wouldn't you have to switch to HTTPS instead? > You're right. A couple of years ago we wrote a paper addressing the potential approaches for tunneling attempts (if you're interested, I can send you the link offline). In this paper we basically described, as a diagram, which incremental steps could be carried out in order to attempt a successful tunneling: 1) the first attempt is to just try port 443, without encapulating anything (e.g., ssh using 443 instead of 22); 2) in case that doesn't work, the second attempt is to use HTTP CONNECT and then fall back to 1. for the connection that is established; 3) the third attempt (e.g., 443 is not available or the proxy acts as a MITM) is to actually encapsulate in HTTP messages, whether you do HTTP or HTTPS. In every case, the peer (either endpoint or server) must be configured accordingly of course. What I describe in the draft is step 3, even though I guess some words to suggest steps 1 and 2 (where you'd still need to encapsulate RTP packets on top of a TCP-based protocol anyway) could be considered. As long as it looks like valid HTTP and it behaves accordingly, I think there's no reason why traversing should be impeded: there are cases where of course we might WANT the traversal to be controlled (as I said in the draft, it doesn't have to be sneaky, and could be made so that network administrators can control it) but that's a different issue. Probably far from being the optimal solution, but for extreme scenarios it may get things working whereas everything else might fail. > Just to be clear, I don't have objections regarding your draft. I just would like to understand what motives people to run everything over HTTP (besides using HTTP features, which you don't really do). > I agree with you and I'm not really dying to do RTP over HTTP either, but if some scenarios make it impossible for use cases to work (and some firewall/NAT deployers are to blame here, probably) then a fallback mechanism is something that can be nice to have, especially if we're interested in something that "just works". Thanks, Lorenzo > Ciao > Hannes > > On Aug 7, 2012, at 7:01 PM, Lorenzo Miniero wrote: > > > Dear all, > > > > during the meeting in Vancouver, there was some discussion about the > > need we have for UDP-blocking firewall traversal in RTCWEB. HTTP > > fallback was mentioned, and I remember it being a matter of discussion > > at the latest interim meeting as well (at least looking at the minutes), > > even though it hasn't apparently been addressed on the ML since. > > Something in line with this was also discussed in Prague at the BOF, > > when it was clearly quite too early to address. > > > > Someone suggested that, rather than trying to address the issue right > > away, it could be better to first try and summarize as a BCP draft what > > people already do in that respect: it's quite obvious, in fact, that > > this is already being done by many companies in their deployments, even > > though probably in a non-standard way. > > > > Since the subject interests me (during the abovementioned IETF in Prague > > we brought a simple demo, which we used to informally showcase to a few > > interested folks the basic prototype refrlecting our research in that > > field) I chose to write a simple individual draft, instead, that rather > > than doing the summary, basically documents the first steps we did with > > our prototype. You can read the draft here: > > > > http://www.ietf.org/id/draft-miniero-rtcweb-http-fallback-00.txt > > > > Please beware that it is not at all meant to be a ready-to-be-used > > solution to the problem, quite the opposite. I wrote the draft in a few > > hours and it simply addresses what we started to do to try and address > > the problem, and, as it will be obvious when reading the draft, it is > > all but complete with respect to what such a solution is supposed to > > make available: nevertheless, it tries to explain the basics of what may > > be needed, even if much more is still missing. Its purpose is rather > > trying to "throw a stone in the lake", as we like to say in Italy, in > > order to draw attention on the problem and gather potential interest by > > other people to work on it, whether or not such work would be based on > > this draft. I placed a few Editors Notes across the text on some of the > > most controversial issues, like how this should mix with ICE and > > negotiation, how easy it should be to detect it and so on. Other even > > more controversial ones, like how to address the impact of congestion > > control on real-time streams, is not in the document as of yet, but it's > > clear this will have to be taken care of eventually. Feedback and > > suggestions are more than welcome! > > > > That said, I guess there's a different question I should be asking to > > the chairs: since there seems to be no related item in the milestones, > > is such a work actually in line with what is the expected outcome of the > > WG? Considering the draft basically addresses a new transport for RTP > > and something that probably needs to be negotiated as well, I guess this > > could be seen as belonging elsewhere (AVTCORE and/or MMUSIC?). > > Nevertheless, my feeling is it belongs more here than somewhere else, > > especially considering we're specifying a solution that will be deployed > > in browsers and, as such, people will expect it to work wherever other > > web applications do. > > > > Thanks, > > Lorenzo > > > > -- > > Lorenzo Miniero, COB > > > > Meetecho s.r.l. > > Web Conferencing and Collaboration Tools > > http://www.meetecho.com > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb > -- Lorenzo Miniero, COB Meetecho s.r.l. Web Conferencing and Collaboration Tools http://www.meetecho.com From ted.ietf@gmail.com Tue Aug 7 10:50:09 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4B3A21F867D for ; Tue, 7 Aug 2012 10:50:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.091 X-Spam-Level: X-Spam-Status: No, score=-4.091 tagged_above=-999 required=5 tests=[AWL=-0.492, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EQ1e5o1RU+CX for ; Tue, 7 Aug 2012 10:50:09 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id C802021F8611 for ; Tue, 7 Aug 2012 10:50:08 -0700 (PDT) Received: by wibhr14 with SMTP id hr14so2401241wib.13 for ; Tue, 07 Aug 2012 10:50:07 -0700 (PDT) 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=lH1+QqJV80PTBFxE3BBBYaq2LJBg+dryGqhdeKitUX4=; b=CiQz7SgYJe7d8aT5/J+5QNXV4FfceScU9Socytgas3FSTizB8ZSrNrKM24TWA4lilQ 4xXCyJjHmJEJEOS+IK8/0nQtV8/J3dd6IJeKqXAchgUWrWK/395BuPdFrNMQrglNoIYD pS8oOdzlns+RjFIM08BnC31qeprxglGsnVPGKiy7a0n1B0xVnZY9gZ+RE3ytq6SvHADg 54knl0VEF9bSkerSErgtiEQayplKpkyC2m5utM22zjF3aP90QR9EX7yL9SGWo3AiD9zS IVBFMRULzk+BhXhxHyDFAGEKptf7GzgHI2PmDhUtqr5R2Je9hxseAN9ajGbR1NVdhOn9 bq2Q== MIME-Version: 1.0 Received: by 10.180.106.137 with SMTP id gu9mr29315942wib.20.1344361807927; Tue, 07 Aug 2012 10:50:07 -0700 (PDT) Received: by 10.216.90.134 with HTTP; Tue, 7 Aug 2012 10:50:07 -0700 (PDT) In-Reply-To: <20120807180156.286e74d2@rainpc> References: <20120807180156.286e74d2@rainpc> Date: Tue, 7 Aug 2012 10:50:07 -0700 Message-ID: From: Ted Hardie To: Lorenzo Miniero Content-Type: text/plain; charset=ISO-8859-1 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] HTTP Fallback draft X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 07 Aug 2012 17:50:10 -0000 On Tue, Aug 7, 2012 at 9:01 AM, Lorenzo Miniero wrote: > That said, I guess there's a different question I should be asking to > the chairs: since there seems to be no related item in the milestones, > is such a work actually in line with what is the expected outcome of the > WG? Considering the draft basically addresses a new transport for RTP > and something that probably needs to be negotiated as well, I guess this > could be seen as belonging elsewhere (AVTCORE and/or MMUSIC?). > Nevertheless, my feeling is it belongs more here than somewhere else, > especially considering we're specifying a solution that will be deployed > in browsers and, as such, people will expect it to work wherever other > web applications do. My take on this is that the actual work on developing the alternate transport for RTP would have to occur elsewhere and, frankly, I think it is a large enough task that it would likely require its own working group (much as the RTP congestion control topic ended up as a BoF and hopefully will become its own working group). That doesn't mean that the work couldn't be informed by the RTCWEB use cases, but I think it would have to be done elsewhere. I'd personally suggest starting with a discussion with the ADs on whether a BoF on this topic would be something they might consider. (Note, however, that I have not talked to Cullen about this and Magnus is on vacation, so this is not a "Chairs' response"; just my own thoughts). regards, Ted Hardie From ibc@aliax.net Tue Aug 7 11:04:22 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F9E011E809A for ; Tue, 7 Aug 2012 11:04:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.656 X-Spam-Level: X-Spam-Status: No, score=-2.656 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jWyFXtDTpCQz for ; Tue, 7 Aug 2012 11:04:21 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5F16B11E8099 for ; Tue, 7 Aug 2012 11:04:21 -0700 (PDT) Received: by lbbgg6 with SMTP id gg6so11041lbb.31 for ; Tue, 07 Aug 2012 11:04:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type :content-transfer-encoding:x-gm-message-state; bh=8a1sFeq/ZkkWrJKBXwycU/cE6EiAlZ1uWVSgKUrNkmA=; b=PfQeDWTmcmo5mttxzsQZOLYE6YQaCfIG+QVEM9iHHrbnAWzyuJGkrBDBx19nDJkSVC DJw2HmleUvKsA7ydU1MJXcI1/nE+8O/sfY9UAS0/q2htHkEhDCLuI8ZspOVgpIIsFSGh kiasFvmNxiopDWtiel4rCSwa/pSr4DAyIT5+bVhDZ2pvLXd1oBYRq+Ymd3kww5Cp46FS g9aIyaHYk7Vl3uE3FK3IwzXdtlVx6FqVYK/iRNStMX5t5AWoehLBc3bSuCaLA1vinsOY 7L16FDM7n7/JJDnPiAu6tpg+WqxkwNrDIOp+q5fTdfh1/raejIQN4MFatJ8pQBeAKOCt /G5Q== Received: by 10.112.23.200 with SMTP id o8mr6857578lbf.9.1344362660305; Tue, 07 Aug 2012 11:04:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.23.2 with HTTP; Tue, 7 Aug 2012 11:04:00 -0700 (PDT) From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Tue, 7 Aug 2012 20:04:00 +0200 Message-ID: To: rtcweb@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmV4ulSoioSFwtEad6ZYv6lSCgr26MLrxQPWceHi6O9M4UTOALAwQUqXt+9DKMBoXFxNU1/ Subject: [rtcweb] Why http://www.ietf.org/id/draft-miniero-rtcweb-http-fallback-00.txt ? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 07 Aug 2012 18:04:22 -0000 Hi, I'm reading http://www.ietf.org/id/draft-miniero-rtcweb-http-fallback-00.txt: This draft describes a way to implement an HTTP Fallback for RTP media streams, that is, a way to effectively encapsulate RTP packets in HTTP messages in order to traverse proxies and firewalls. Well, why does WebRTC need it at all? don't we have TURN over TCP/TLS? --=20 I=C3=B1aki Baz Castillo From petithug@acm.org Tue Aug 7 11:12:44 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78EEC21F86EB for ; Tue, 7 Aug 2012 11:12:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.411 X-Spam-Level: X-Spam-Status: No, score=-102.411 tagged_above=-999 required=5 tests=[AWL=-0.111, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id plrLcVKyBEGK for ; Tue, 7 Aug 2012 11:12:43 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id D334321F86E5 for ; Tue, 7 Aug 2012 11:12:43 -0700 (PDT) Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] (shalmaneser.org [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 478DD20491; Tue, 7 Aug 2012 18:12:41 +0000 (UTC) Message-ID: <50215A96.20604@acm.org> Date: Tue, 07 Aug 2012 11:12:38 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.6esrpre) Gecko/20120805 Icedove/10.0.6 MIME-Version: 1.0 To: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= References: In-Reply-To: X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Why http://www.ietf.org/id/draft-miniero-rtcweb-http-fallback-00.txt ? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 07 Aug 2012 18:12:44 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 08/07/2012 11:04 AM, Iñaki Baz Castillo wrote: > Hi, I'm reading > http://www.ietf.org/id/draft-miniero-rtcweb-http-fallback-00.txt: > > This draft describes a way to implement an HTTP Fallback for RTP media > streams, that is, a way to effectively encapsulate RTP packets in HTTP > messages in order to traverse proxies and firewalls. > > Well, why does WebRTC need it at all? don't we have TURN over TCP/TLS? > Or TURN over Websocket. - -- Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJQIVqJAAoJECnERZXWan7EXkQP/3+6ZhsmUNRy2GCwOHlCutdF cVTPhFMuNTi4ZTO4EIYQ7rxTiWyGJFCdPI6j24wl1+JmflxmSPQXTJOph8c0rmDr tPF3WJ2ayn29rpOvUYp+Yp190EUaDt+awgWLo8RTEL9QNNR2hO1G0Jff2ux6AfC+ mbrIS/FJQtuiDlllLH2Xgxq5vUf4oP/sZowoB7bLhp+4MZWD0p/JscYr3+lNbRme DrbFODfzYYLuPvW0T4OYMzN7hkVKL0M0Hwx7NYN+RBSR184wUrhmFdgmAL61oAzP SkMNjNs585C/6wUK1un1o2QxppPOUlf/vMCs+XYS45rovOprAmsf6UrrayzMg8Y3 SDfKCtIaCWg5F+LVq+p90KVgP39nQwjY/v6IEQf9egOFFh8pf2KaP8UR1Z7mP8ss zpLkzJSg7+YNSF7dM+k8PTq1GqdZoWr0YRxAN5xh0zWUdyoOfycYLGWNaD3edjwa 2cTQ9AkAZFfjvVpjAVBdo20c0Gm7mqgngEzrccZyMoVIKoEUC6cPPSfW+etiUYbs KDWad4n4TbWUDmROohiB7fVlWJdHWxW8oB6rCGkf0ta8RrVFmUDZqoCA8E4AAcjj E8h0gWnurn2uX9jj6dQB/Q+YApzL+Z11wKvzOzeMnSovCaOg9H0uSs2ezmVuAUA6 uQDV5qElSRqcBvktCWoJ =hBDl -----END PGP SIGNATURE----- From ibc@aliax.net Tue Aug 7 11:19:20 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D1C221F8717 for ; Tue, 7 Aug 2012 11:19:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.657 X-Spam-Level: X-Spam-Status: No, score=-2.657 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u12UxgoVs7SJ for ; Tue, 7 Aug 2012 11:19:20 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 97DD321F8715 for ; Tue, 7 Aug 2012 11:19:19 -0700 (PDT) Received: by lbbgg6 with SMTP id gg6so18701lbb.31 for ; Tue, 07 Aug 2012 11:19:18 -0700 (PDT) X-Google-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:content-transfer-encoding:x-gm-message-state; bh=VRmg1t9jgIq+b3rzyegJBhWQsRMLdhoyoK7sc0MbNVA=; b=nej4Tv0TLPwYplATfNpYNZ2GgvBkrMCTBFDSWKDKY3seP4NeNgnZBvFPfBr4JuLA0O /qEmyHOyIOQSiN6qXPA8tUR7gTC0aAqmcZyUeegjVFwYvhoqXpVrq5oEXi/tr3mXW2Hy qjIWHBgbNh+gwgWEkus6BMW21fNeqTdzNeb6je4kHz8/xHWUoP5jBUIPmJo1v2+ZbM/6 Bschm86+68PvvWAJHHsDIyt4djqbAzhvMF3B0jgbh1bInR5X9BJKMzKdRtiWyzXqIoLs ZJxhodVOD58/smR41bxdg59EkQ89JYZZRwOTnFwpA48oFCD/U+0nYS01LPhxLJPZU68h osrA== Received: by 10.112.27.226 with SMTP id w2mr6737941lbg.57.1344363558507; Tue, 07 Aug 2012 11:19:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.23.2 with HTTP; Tue, 7 Aug 2012 11:18:58 -0700 (PDT) In-Reply-To: <50215A96.20604@acm.org> References: <50215A96.20604@acm.org> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Tue, 7 Aug 2012 20:18:58 +0200 Message-ID: To: Marc Petit-Huguenin Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnhud5925qrB3iqOHP4ixBkbpIVDTCc9QZ+rF+BVAYEZIUu4i4ZorUItbgskZdA1N00+hG1 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Why http://www.ietf.org/id/draft-miniero-rtcweb-http-fallback-00.txt ? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 07 Aug 2012 18:19:20 -0000 2012/8/7 Marc Petit-Huguenin : > Or TURN over Websocket. Why do we need that? By using TURN over TLS we have all we need to avoid stupid hotel's firewalls (that provide "Internet free access" but just for HTTP port 80 and HTTPS port 443). It just about setting a TURN server listening TLS on port 443, am I right? --=20 I=C3=B1aki Baz Castillo From roman@telurix.com Tue Aug 7 11:30:06 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 566FC21F8592 for ; Tue, 7 Aug 2012 11:30:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.712 X-Spam-Level: X-Spam-Status: No, score=-2.712 tagged_above=-999 required=5 tests=[AWL=-0.035, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wMv2AycqfsxZ for ; Tue, 7 Aug 2012 11:30:05 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8131221F858F for ; Tue, 7 Aug 2012 11:30:05 -0700 (PDT) Received: by ghbg16 with SMTP id g16so2001628ghb.31 for ; Tue, 07 Aug 2012 11:30:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=DkMHu6PSvLof6P7b9yb0uWEz8D2F1w/6DJMdckVmkgQ=; b=Eu8WdxIYhAm5WLRJHgd+aLhyDXmJhjgdqAnT0IGbTErMDbf5PDpRCnyUcIu5u0jL7z 4LROtPTNzcVRazHTk/X9ExF8OV+Xog4Ut8GSVU7IQTFLFCdLhWfPUeJJS02r+fg0iprF w86aA0a89NHE7QUXAY8HSvEBK3F8bzySJTLDluW04cLf5m5hAFwivk0kMoQaGe8g3cdF sSOR14hTascZtCb0lhcQCs3KjE2kLOgWtnLO1YX6a9Xenu0W3ptf7+YHy3ArwhcfqM7f et3O92TJlEDa3KTPaMeS+oLvkB99GAbLhmLVhCqvE9+i+MwFaikeKzAQyErNdfNkflYb WTJg== Received: by 10.236.156.229 with SMTP id m65mr10515256yhk.105.1344364204993; Tue, 07 Aug 2012 11:30:04 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by mx.google.com with ESMTPS id t57sm38169890yhg.0.2012.08.07.11.30.04 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 07 Aug 2012 11:30:04 -0700 (PDT) Received: by yhq56 with SMTP id 56so4397361yhq.31 for ; Tue, 07 Aug 2012 11:30:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.72.169 with SMTP id e9mr27934526pav.44.1344364203423; Tue, 07 Aug 2012 11:30:03 -0700 (PDT) Received: by 10.68.28.72 with HTTP; Tue, 7 Aug 2012 11:30:03 -0700 (PDT) In-Reply-To: References: <50215A96.20604@acm.org> Date: Tue, 7 Aug 2012 14:30:03 -0400 Message-ID: From: Roman Shpount To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=f46d042dfdcdcb385804c6b12e67 X-Gm-Message-State: ALoCoQn84cno1DSwaayZsTSxB2zCdvK68zbKTPCBuH06HWwSw2gSeXdxNUSG1sggyD6TBTz83v0H Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Why http://www.ietf.org/id/draft-miniero-rtcweb-http-fallback-00.txt ? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 07 Aug 2012 18:30:06 -0000 --f46d042dfdcdcb385804c6b12e67 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Aug 7, 2012 at 2:18 PM, I=F1aki Baz Castillo wrote: > 2012/8/7 Marc Petit-Huguenin : > > Or TURN over Websocket. > > Why do we need that? By using TURN over TLS we have all we need to > avoid stupid hotel's firewalls (that provide "Internet free access" > but just for HTTP port 80 and HTTPS port 443). It just about setting a > TURN server listening TLS on port 443, am I right? > > You still got the locations where the only way to connect to anything is via the man-in-the-middle accept HTTP request and resend it proxies. Such proxies will install their own certificate in the client certificate chain and will decode every request. TURN over websocket will work over such connection, but regular TURN will not. I am not sure how much effort we want to spend supporting this, since we are talking about prisons, military, and other similar nice places which will generally would try to avoid supporting WebRTC due to its own security. _____________ Roman Shpount --f46d042dfdcdcb385804c6b12e67 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Aug 7, 2012 at 2:18 PM, I=F1aki Baz Cast= illo <ibc@aliax.net> wrote:
2012/8/7 Marc Petit-Huguenin <petith= ug@acm.org>:
> Or TURN over Websocket.

Why do we need that? By using TURN over TLS we have all we need to
avoid stupid hotel's firewalls (that provide "Internet free access= "
but just for HTTP port 80 and HTTPS port 443). It just about setting a
TURN server listening TLS on port 443, am I right?


You still got the locations = where the only way to connect to anything is via the man-in-the-middle acce= pt HTTP request and resend it proxies. Such proxies will install their own = certificate in the client certificate chain and will decode every request. = TURN over websocket will work over such connection, but regular TURN will n= ot. I am not sure how much effort we want to spend supporting this, since w= e are talking about prisons, military, and other similar nice places which = will generally would try to avoid supporting WebRTC due to its own security= .
_____________
Roman Shpount
=A0
--f46d042dfdcdcb385804c6b12e67-- From lorenzo@meetecho.com Tue Aug 7 12:01:10 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA46D21F86DE for ; Tue, 7 Aug 2012 12:01:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kx85iM+KwKig for ; Tue, 7 Aug 2012 12:01:09 -0700 (PDT) Received: from smtplq02.aruba.it (smtplq-out6.aruba.it [62.149.158.26]) by ietfa.amsl.com (Postfix) with SMTP id E438A21F873C for ; Tue, 7 Aug 2012 12:00:57 -0700 (PDT) Received: (qmail 2989 invoked by uid 89); 7 Aug 2012 19:00:53 -0000 Received: from unknown (HELO smtp3.aruba.it) (62.149.158.223) by smtplq02.aruba.it with SMTP; 7 Aug 2012 19:00:53 -0000 Received: (qmail 26579 invoked by uid 89); 7 Aug 2012 19:00:53 -0000 Received: from unknown (HELO rainpc) (lorenzo@meetecho.com@80.181.173.222) by smtp3.ad.aruba.it with SMTP; 7 Aug 2012 19:00:53 -0000 Date: Tue, 7 Aug 2012 20:54:47 +0200 From: Lorenzo Miniero To: Ted Hardie Message-ID: <20120807205447.2212f617@rainpc> In-Reply-To: References: <20120807180156.286e74d2@rainpc> Organization: Meetecho X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.8; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Rating: smtp3.ad.aruba.it 1.6.2 0/1000/N X-Spam-Rating: smtplq02.aruba.it 1.6.2 0/1000/N Cc: rtcweb@ietf.org Subject: Re: [rtcweb] HTTP Fallback draft X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 07 Aug 2012 19:01:11 -0000 Hello Ted, On Tue, 7 Aug 2012 10:50:07 -0700 Ted Hardie wrote: > On Tue, Aug 7, 2012 at 9:01 AM, Lorenzo Miniero wrote: > > That said, I guess there's a different question I should be asking to > > the chairs: since there seems to be no related item in the milestones, > > is such a work actually in line with what is the expected outcome of the > > WG? Considering the draft basically addresses a new transport for RTP > > and something that probably needs to be negotiated as well, I guess this > > could be seen as belonging elsewhere (AVTCORE and/or MMUSIC?). > > Nevertheless, my feeling is it belongs more here than somewhere else, > > especially considering we're specifying a solution that will be deployed > > in browsers and, as such, people will expect it to work wherever other > > web applications do. > > My take on this is that the actual work on developing the alternate > transport for RTP would have to occur elsewhere and, frankly, I think > it is a large enough task that it would likely require its own working > group (much as the RTP congestion control topic ended up as a BoF and > hopefully will become its own working group). That doesn't mean that > the work couldn't be informed by the RTCWEB use cases, but I think it > would have to be done elsewhere. > > I'd personally suggest starting with a discussion with the ADs on > whether a BoF on this topic would be something they might consider. > (Note, however, that I have not talked to Cullen about this and Magnus > is on vacation, so this is not a "Chairs' response"; just my own > thoughts). > This makes sense. I'm a bit concerned about the additional time that may be needed by going through the process of forming a new WG (compared to just adding a milestone to an existing WG, that is), as the final result may end up being available much after the original WG completed its works, but I see your point. I'll wait for more feedback about this and, if enough people seem interested about doing something like this, contacting the ADs and consider the next steps may be a good idea. Lorenzo > regards, > > Ted Hardie -- Lorenzo Miniero, COB Meetecho s.r.l. Web Conferencing and Collaboration Tools http://www.meetecho.com From lorenzo@meetecho.com Tue Aug 7 12:06:51 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8481521F87C7 for ; Tue, 7 Aug 2012 12:06:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.569 X-Spam-Level: X-Spam-Status: No, score=-0.569 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aGrZqy7NsiUn for ; Tue, 7 Aug 2012 12:06:50 -0700 (PDT) Received: from smtplq04.aruba.it (smtplq-out6.aruba.it [62.149.158.26]) by ietfa.amsl.com (Postfix) with SMTP id 1DC6621F8604 for ; Tue, 7 Aug 2012 12:06:49 -0700 (PDT) Received: (qmail 27446 invoked by uid 89); 7 Aug 2012 19:06:48 -0000 Received: from unknown (HELO smtp5.aruba.it) (62.149.158.225) by smtplq04.aruba.it with SMTP; 7 Aug 2012 19:06:48 -0000 Received: (qmail 31326 invoked by uid 89); 7 Aug 2012 19:06:48 -0000 Received: from unknown (HELO rainpc) (lorenzo@meetecho.com@80.181.173.222) by smtp5.ad.aruba.it with SMTP; 7 Aug 2012 19:06:47 -0000 Date: Tue, 7 Aug 2012 21:00:42 +0200 From: Lorenzo Miniero To: =?UTF-8?B?ScOxYWtp?= Baz Castillo Message-ID: <20120807210042.7e1fb9fa@rainpc> In-Reply-To: References: <50215A96.20604@acm.org> Organization: Meetecho X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.8; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Rating: smtp5.ad.aruba.it 1.6.2 0/1000/N X-Spam-Rating: smtplq04.aruba.it 1.6.2 0/1000/N Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Why http://www.ietf.org/id/draft-miniero-rtcweb-http-fallback-00.txt ? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 07 Aug 2012 19:06:51 -0000 I=C3=B1aki, discussions would be much easier to follow if you just answered to the orig= inal thread, rather than opening a new one... about your question, please s= ee inline. On Tue, 7 Aug 2012 20:18:58 +0200 I=C3=B1aki Baz Castillo wrote: > 2012/8/7 Marc Petit-Huguenin : > > Or TURN over Websocket. >=20 > Why do we need that? By using TURN over TLS we have all we need to > avoid stupid hotel's firewalls (that provide "Internet free access" > but just for HTTP port 80 and HTTPS port 443). It just about setting a > TURN server listening TLS on port 443, am I right? >=20 "Do we need that" is exactly what I wanted to ask by publishing the draft. = There was already some discussions in the past, someone even suggested just= deploying TURN over HTTP (a bit like Marc's point on WebSockets), and TURN= over TLS (or just anything on 443, for what matters) is another viable sol= ution. The problem IMHO is that, just as Roman pointed out in his reply, that's no= t always a way out. In my experience such a scenario is not only limited to= those ultra-closed environments he mentioned, but that's probably debatabl= e (who closes his network that way, probably doesn't want anything else to = go through anyway). About the "just pipe everything on 443", please refer to my reply to Hannes= in the original thread, as I've answered more extensively there. Lorenzo > --=20 > I=C3=B1aki Baz Castillo > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --=20 Lorenzo Miniero, COB Meetecho s.r.l. Web Conferencing and Collaboration Tools http://www.meetecho.com From ibc@aliax.net Tue Aug 7 12:34:31 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F5E021F8744 for ; Tue, 7 Aug 2012 12:34:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.658 X-Spam-Level: X-Spam-Status: No, score=-2.658 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xast29YyIgzm for ; Tue, 7 Aug 2012 12:34:30 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 63C8B21F8733 for ; Tue, 7 Aug 2012 12:34:30 -0700 (PDT) Received: by lbbgg6 with SMTP id gg6so56995lbb.31 for ; Tue, 07 Aug 2012 12:34:29 -0700 (PDT) X-Google-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:content-transfer-encoding:x-gm-message-state; bh=bF4NYAs0JnMujMxl6+cq+VG4Ob3SxQ3YOhq0+ix1d1I=; b=TPS/YeaB7fubHfiwIFnigfqWJ446GsPiqQ0ZTjB1JYVi+SLPEU6xYtua66fSjsb1ry TQmj43jzOdcK0Iqckoav7OO2sCGe5HXMqvgkMNjheq2pEWEcQVfC0iR2tk0JzBzLr7oV mG4xnHIU6UsxsxRNd151aJFGKYJDRfYIk7lZ/7+Sv91pVTD1X7cCSba54vRQmVb4vTTf muZ3m+H8SCovUQSWsryZAidGyAajoe8cLzkophQnj+SjtNreRHpOAkxIen8Y74iQ5ytd SxeZ4WIE2RTofAZjH/fkmN/hYL7oYWaNmHKrP5PgAeACvC1KJJ+PVq/GRwAKcK8lci1w 83rg== Received: by 10.152.112.136 with SMTP id iq8mr11864228lab.18.1344368069326; Tue, 07 Aug 2012 12:34:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.23.2 with HTTP; Tue, 7 Aug 2012 12:34:09 -0700 (PDT) In-Reply-To: <20120807191226.5b8e7f32@rainpc> References: <20120807180156.286e74d2@rainpc> <20120807191226.5b8e7f32@rainpc> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Tue, 7 Aug 2012 21:34:09 +0200 Message-ID: To: Lorenzo Miniero Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmSh47oNaYomLJFcGsUeHOXnX770E8kXYotEyVkDciRh5AeI9BUlfPxywduNpW4jCzFXEMB Cc: rtcweb@ietf.org Subject: Re: [rtcweb] HTTP Fallback draft X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 07 Aug 2012 19:34:31 -0000 Hi Lorenzo, sorry for opening another thread about this (I didn't check my unread emails before reading the draft). Please see comments inline: > Hannes Tschofenig wrote: >> Just to be clear, I don't have objections regarding your draft. I just w= ould like to understand what motives people to run everything over HTTP (be= sides using HTTP features, which you don't really do). Honestly I don't like the "all-over-http" vision. Admins filtering traffic other than HTTP or HTTPS will also do their best efforts for filtering specific traffic over HTTP, and IMHO making specifications to run protocolos over HTTP legitimizes those hateful filtering techniques. 2012/8/7 Lorenzo Miniero : > I agree with you and I'm not really dying to do RTP over HTTP either, but= if some scenarios make it impossible for use cases to work (and some firew= all/NAT deployers are to blame here, probably) then a fallback mechanism is= something that can be nice to have, especially if we're interested in some= thing that "just works". That's the problem (IMHO): if we make all to work over HTTP then some day telcos providers will just offer HTTP (as "Internet") and we'll need to study a new OSI model in which the lowest layer is called "HTTP". BTW: I sitll don't understand which is the advantage of using RTP over HTTPS in comparison to TURN over TLS:443. Does is exist? Regards. --=20 I=C3=B1aki Baz Castillo From lorenzo@meetecho.com Tue Aug 7 13:00:24 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E877021F85FF for ; Tue, 7 Aug 2012 13:00:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.539 X-Spam-Level: X-Spam-Status: No, score=-0.539 tagged_above=-999 required=5 tests=[AWL=-0.120, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mG-NoxwQT3JH for ; Tue, 7 Aug 2012 13:00:24 -0700 (PDT) Received: from smtplq02.aruba.it (smtplqs-out17.aruba.it [62.149.158.57]) by ietfa.amsl.com (Postfix) with SMTP id 808C921F853B for ; Tue, 7 Aug 2012 13:00:23 -0700 (PDT) Received: (qmail 6632 invoked by uid 89); 7 Aug 2012 20:00:21 -0000 Received: from unknown (HELO smtp7.aruba.it) (62.149.158.227) by smtplq02.aruba.it with SMTP; 7 Aug 2012 20:00:21 -0000 Received: (qmail 2091 invoked by uid 89); 7 Aug 2012 20:00:21 -0000 Received: from unknown (HELO rainpc) (lorenzo@meetecho.com@80.181.173.222) by smtp7.ad.aruba.it with SMTP; 7 Aug 2012 20:00:21 -0000 Date: Tue, 7 Aug 2012 21:54:15 +0200 From: Lorenzo Miniero To: =?UTF-8?B?ScOxYWtp?= Baz Castillo Message-ID: <20120807215415.00bebaa7@rainpc> In-Reply-To: References: <20120807180156.286e74d2@rainpc> <20120807191226.5b8e7f32@rainpc> Organization: Meetecho X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.8; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Rating: smtp7.ad.aruba.it 1.6.2 0/1000/N X-Spam-Rating: smtplq02.aruba.it 1.6.2 0/1000/N Cc: rtcweb@ietf.org Subject: Re: [rtcweb] HTTP Fallback draft X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 07 Aug 2012 20:00:25 -0000 Hi I=C3=B1aki, On Tue, 7 Aug 2012 21:34:09 +0200 I=C3=B1aki Baz Castillo wrote: > Hi Lorenzo, sorry for opening another thread about this (I didn't > check my unread emails before reading the draft). Please see comments > inline: >=20 No harm done, don't worry! >=20 > > Hannes Tschofenig wrote: >=20 > >> Just to be clear, I don't have objections regarding your draft. I just= would like to understand what motives people to run everything over HTTP (= besides using HTTP features, which you don't really do). >=20 > Honestly I don't like the "all-over-http" vision. Admins filtering > traffic other than HTTP or HTTPS will also do their best efforts for > filtering specific traffic over HTTP, and IMHO making specifications > to run protocolos over HTTP legitimizes those hateful filtering > techniques. >=20 I'm not a fan either, believe me :) That said, as I said in another post I still think that, if RTCWEB/WebRTC i= s going to be deployed in browsers, they'll expect it to work in all the pl= aces where all other web applications do. Many proprietary protocols that d= o real-time communication implement tunneling somehow, or pretend to do so,= which means something in line with that is needed for RTCWEB as well. >=20 >=20 >=20 >=20 > 2012/8/7 Lorenzo Miniero : >=20 > > I agree with you and I'm not really dying to do RTP over HTTP either, b= ut if some scenarios make it impossible for use cases to work (and some fir= ewall/NAT deployers are to blame here, probably) then a fallback mechanism = is something that can be nice to have, especially if we're interested in so= mething that "just works". >=20 > That's the problem (IMHO): if we make all to work over HTTP then some > day telcos providers will just offer HTTP (as "Internet") and we'll > need to study a new OSI model in which the lowest layer is called > "HTTP". >=20 Which is close enough to the hourglass draft Hannes mentioned in his post, = I'm afraid. I can't but agree with you, but, again, if we have use cases an= d we want to have them working in as many topologies as possible, something= must be done. > BTW: I sitll don't understand which is the advantage of using RTP over > HTTPS in comparison to TURN over TLS:443. Does is exist? >=20 If we talk about a simple comparison, I'm sure TURN:TLS:443 performs much b= etter than RTP over HTTPS, or at least, over the simple approach I document= ed in the draft at least (even though I tried to keep the overhead as littl= e as possible). Comparing them is probably not fair, though, as they addres= s two different scenarios: that's why HTTP would be just a fallback, and no= t something you'd use when you have alternatives. Referring to the steps I described in my previous answer to Hannes, TURN:TL= S:443 is probably the most useful option for scenarios 1 and 2, that is, wh= ere you can just pipe what you want on port 443 and be sure it will be igno= red by the proxy. If the proxy checks what's going on, though, that may not= be as easy. The proxy may be acting as a MITM for HTTPS, as Roman describe= d, or just doing some traffic monitoring with anomaly detection or somethin= g like that: faking to be HTTPS is not going to work in that case, since th= e proxy may just see it's not HTTP at all, or may just understand it's not = what it claims to be because it doesn't behave as it should; HTTP connectio= ns have a usually quite simple pattern (e.g., much more traffic going in on= e direction than the other and never at the same time), something that woul= d be very different in a TURN connection instead. Lorenzo >=20 > Regards. >=20 >=20 > --=20 > I=C3=B1aki Baz Castillo > --=20 Lorenzo Miniero, COB Meetecho s.r.l. Web Conferencing and Collaboration Tools http://www.meetecho.com From tireddy@cisco.com Tue Aug 7 14:23:56 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC86E11E80DC for ; Tue, 7 Aug 2012 14:23:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.149 X-Spam-Level: X-Spam-Status: No, score=-10.149 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U3hauduEuUZ5 for ; Tue, 7 Aug 2012 14:23:55 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 319A011E809B for ; Tue, 7 Aug 2012 14:23:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6540; q=dns/txt; s=iport; t=1344374632; x=1345584232; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=LIqzsjxfOMyMmNuDMm+u2l2nwUPZgWiD0A06UrLqwDU=; b=ctDWebRJv4qAoRlOP3LrKM8Gtg8hnt0CtbfgEOrBVJmg6Yk6IWkuXm8X f1bZh8vopErMnaPwq3GeVCewJNr39DHJ48nReISgHf4+6dT5XusF3WWdc 6ExKMSRxrpiIM8GwtszI8wBdjNl1fKF2EgJn6ActHvDhkJg/qxTyEulVE E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAGGGIVCtJV2d/2dsb2JhbABFhXyyeHKBB4IgAQEBAwEBAQEPARARIRkLDAQCAQgRBAEBAQICBh0DAgICJQsUAQgIAgQBDQUIGodcAwYGC5sVjRmTSIEhiQpkhU4yYAOjboFmgl8 X-IronPort-AV: E=Sophos;i="4.77,728,1336348800"; d="scan'208";a="106341897" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-9.cisco.com with ESMTP; 07 Aug 2012 21:23:51 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id q77LNpQf017989 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 7 Aug 2012 21:23:51 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.216]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0298.004; Tue, 7 Aug 2012 16:23:51 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Lorenzo Miniero , =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= Thread-Topic: [rtcweb] HTTP Fallback draft Thread-Index: AQHNdLbePFtYWCPhFk+Ws7zgJPkdgJdO4KUAgAAJYQCAACeYgIAABZ6A//++iUA= Date: Tue, 7 Aug 2012 21:23:50 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A1477E8D5@xmb-rcd-x10.cisco.com> References: <20120807180156.286e74d2@rainpc> <20120807191226.5b8e7f32@rainpc> <20120807215415.00bebaa7@rainpc> In-Reply-To: <20120807215415.00bebaa7@rainpc> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.69.132] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19090.004 x-tm-as-result: No--57.104600-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] HTTP Fallback draft X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 07 Aug 2012 21:23:56 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBydGN3ZWItYm91bmNlc0BpZXRm Lm9yZyBbbWFpbHRvOnJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnXSBPbg0KPiBCZWhhbGYgT2YgTG9y ZW56byBNaW5pZXJvDQo+IFNlbnQ6IFdlZG5lc2RheSwgQXVndXN0IDA4LCAyMDEyIDE6MjQgQU0N Cj4gVG86IEnDsWFraSBCYXogQ2FzdGlsbG8NCj4gQ2M6IHJ0Y3dlYkBpZXRmLm9yZw0KPiBTdWJq ZWN0OiBSZTogW3J0Y3dlYl0gSFRUUCBGYWxsYmFjayBkcmFmdA0KPiANCj4gSGkgScOxYWtpLA0K PiANCj4gDQo+IE9uIFR1ZSwgNyBBdWcgMjAxMiAyMTozNDowOSArMDIwMA0KPiBJw7Fha2kgQmF6 IENhc3RpbGxvIDxpYmNAYWxpYXgubmV0PiB3cm90ZToNCj4gDQo+ID4gSGkgTG9yZW56bywgc29y cnkgZm9yIG9wZW5pbmcgYW5vdGhlciB0aHJlYWQgYWJvdXQgdGhpcyAoSSBkaWRuJ3QNCj4gPiBj aGVjayBteSB1bnJlYWQgZW1haWxzIGJlZm9yZSByZWFkaW5nIHRoZSBkcmFmdCkuIFBsZWFzZSBz ZWUgY29tbWVudHMNCj4gPiBpbmxpbmU6DQo+ID4NCj4gDQo+IA0KPiBObyBoYXJtIGRvbmUsIGRv bid0IHdvcnJ5IQ0KPiANCj4gDQo+ID4NCj4gPiA+IEhhbm5lcyBUc2Nob2ZlbmlnIDxoYW5uZXMu dHNjaG9mZW5pZ0BnbXgubmV0PiB3cm90ZToNCj4gPg0KPiA+ID4+IEp1c3QgdG8gYmUgY2xlYXIs IEkgZG9uJ3QgaGF2ZSBvYmplY3Rpb25zIHJlZ2FyZGluZyB5b3VyIGRyYWZ0LiBJDQo+IGp1c3Qg d291bGQgbGlrZSB0byB1bmRlcnN0YW5kIHdoYXQgbW90aXZlcyBwZW9wbGUgdG8gcnVuIGV2ZXJ5 dGhpbmcNCj4gb3ZlciBIVFRQIChiZXNpZGVzIHVzaW5nIEhUVFAgZmVhdHVyZXMsIHdoaWNoIHlv dSBkb24ndCByZWFsbHkgZG8pLg0KPiA+DQo+ID4gSG9uZXN0bHkgSSBkb24ndCBsaWtlIHRoZSAi YWxsLW92ZXItaHR0cCIgdmlzaW9uLiBBZG1pbnMgZmlsdGVyaW5nDQo+ID4gdHJhZmZpYyBvdGhl ciB0aGFuIEhUVFAgb3IgSFRUUFMgd2lsbCBhbHNvIGRvIHRoZWlyIGJlc3QgZWZmb3J0cyBmb3IN Cj4gPiBmaWx0ZXJpbmcgc3BlY2lmaWMgdHJhZmZpYyBvdmVyIEhUVFAsIGFuZCBJTUhPIG1ha2lu ZyBzcGVjaWZpY2F0aW9ucw0KPiA+IHRvIHJ1biBwcm90b2NvbG9zIG92ZXIgSFRUUCBsZWdpdGlt aXplcyB0aG9zZSBoYXRlZnVsIGZpbHRlcmluZw0KPiA+IHRlY2huaXF1ZXMuDQo+ID4NCj4gDQo+ IA0KPiBJJ20gbm90IGEgZmFuIGVpdGhlciwgYmVsaWV2ZSBtZSA6KQ0KPiANCj4gVGhhdCBzYWlk LCBhcyBJIHNhaWQgaW4gYW5vdGhlciBwb3N0IEkgc3RpbGwgdGhpbmsgdGhhdCwgaWYNCj4gUlRD V0VCL1dlYlJUQyBpcyBnb2luZyB0byBiZSBkZXBsb3llZCBpbiBicm93c2VycywgdGhleSdsbCBl eHBlY3QgaXQgdG8NCj4gd29yayBpbiBhbGwgdGhlIHBsYWNlcyB3aGVyZSBhbGwgb3RoZXIgd2Vi IGFwcGxpY2F0aW9ucyBkby4gTWFueQ0KPiBwcm9wcmlldGFyeSBwcm90b2NvbHMgdGhhdCBkbyBy ZWFsLXRpbWUgY29tbXVuaWNhdGlvbiBpbXBsZW1lbnQNCj4gdHVubmVsaW5nIHNvbWVob3csIG9y IHByZXRlbmQgdG8gZG8gc28sIHdoaWNoIG1lYW5zIHNvbWV0aGluZyBpbiBsaW5lDQo+IHdpdGgg dGhhdCBpcyBuZWVkZWQgZm9yIFJUQ1dFQiBhcyB3ZWxsLg0KPiANCj4gDQo+ID4NCj4gPg0KPiA+ DQo+ID4NCj4gPiAyMDEyLzgvNyBMb3JlbnpvIE1pbmllcm8gPGxvcmVuem9AbWVldGVjaG8uY29t PjoNCj4gPg0KPiA+ID4gSSBhZ3JlZSB3aXRoIHlvdSBhbmQgSSdtIG5vdCByZWFsbHkgZHlpbmcg dG8gZG8gUlRQIG92ZXIgSFRUUA0KPiBlaXRoZXIsIGJ1dCBpZiBzb21lIHNjZW5hcmlvcyBtYWtl IGl0IGltcG9zc2libGUgZm9yIHVzZSBjYXNlcyB0byB3b3JrDQo+IChhbmQgc29tZSBmaXJld2Fs bC9OQVQgZGVwbG95ZXJzIGFyZSB0byBibGFtZSBoZXJlLCBwcm9iYWJseSkgdGhlbiBhDQo+IGZh bGxiYWNrIG1lY2hhbmlzbSBpcyBzb21ldGhpbmcgdGhhdCBjYW4gYmUgbmljZSB0byBoYXZlLCBl c3BlY2lhbGx5IGlmDQo+IHdlJ3JlIGludGVyZXN0ZWQgaW4gc29tZXRoaW5nIHRoYXQgImp1c3Qg d29ya3MiLg0KPiA+DQo+ID4gVGhhdCdzIHRoZSBwcm9ibGVtIChJTUhPKTogaWYgd2UgbWFrZSBh bGwgdG8gd29yayBvdmVyIEhUVFAgdGhlbiBzb21lDQo+ID4gZGF5IHRlbGNvcyBwcm92aWRlcnMg d2lsbCBqdXN0IG9mZmVyIEhUVFAgKGFzICJJbnRlcm5ldCIpIGFuZCB3ZSdsbA0KPiA+IG5lZWQg dG8gc3R1ZHkgYSBuZXcgT1NJIG1vZGVsIGluIHdoaWNoIHRoZSBsb3dlc3QgbGF5ZXIgaXMgY2Fs bGVkDQo+ID4gIkhUVFAiLg0KPiA+DQo+IA0KPiANCj4gV2hpY2ggaXMgY2xvc2UgZW5vdWdoIHRv IHRoZSBob3VyZ2xhc3MgZHJhZnQgSGFubmVzIG1lbnRpb25lZCBpbiBoaXMNCj4gcG9zdCwgSSdt IGFmcmFpZC4gSSBjYW4ndCBidXQgYWdyZWUgd2l0aCB5b3UsIGJ1dCwgYWdhaW4sIGlmIHdlIGhh dmUNCj4gdXNlIGNhc2VzIGFuZCB3ZSB3YW50IHRvIGhhdmUgdGhlbSB3b3JraW5nIGluIGFzIG1h bnkgdG9wb2xvZ2llcyBhcw0KPiBwb3NzaWJsZSwgc29tZXRoaW5nIG11c3QgYmUgZG9uZS4NCj4g DQo+IA0KPiA+IEJUVzogSSBzaXRsbCBkb24ndCB1bmRlcnN0YW5kIHdoaWNoIGlzIHRoZSBhZHZh bnRhZ2Ugb2YgdXNpbmcgUlRQDQo+IG92ZXINCj4gPiBIVFRQUyBpbiBjb21wYXJpc29uIHRvIFRV Uk4gb3ZlciBUTFM6NDQzLiBEb2VzIGlzIGV4aXN0Pw0KPiA+DQo+IA0KPiANCj4gSWYgd2UgdGFs ayBhYm91dCBhIHNpbXBsZSBjb21wYXJpc29uLCBJJ20gc3VyZSBUVVJOOlRMUzo0NDMgcGVyZm9y bXMNCj4gbXVjaCBiZXR0ZXIgdGhhbiBSVFAgb3ZlciBIVFRQUywgb3IgYXQgbGVhc3QsIG92ZXIg dGhlIHNpbXBsZSBhcHByb2FjaA0KPiBJIGRvY3VtZW50ZWQgaW4gdGhlIGRyYWZ0IGF0IGxlYXN0 IChldmVuIHRob3VnaCBJIHRyaWVkIHRvIGtlZXAgdGhlDQo+IG92ZXJoZWFkIGFzIGxpdHRsZSBh cyBwb3NzaWJsZSkuIENvbXBhcmluZyB0aGVtIGlzIHByb2JhYmx5IG5vdCBmYWlyLA0KPiB0aG91 Z2gsIGFzIHRoZXkgYWRkcmVzcyB0d28gZGlmZmVyZW50IHNjZW5hcmlvczogdGhhdCdzIHdoeSBI VFRQIHdvdWxkDQo+IGJlIGp1c3QgYSBmYWxsYmFjaywgYW5kIG5vdCBzb21ldGhpbmcgeW91J2Qg dXNlIHdoZW4geW91IGhhdmUNCj4gYWx0ZXJuYXRpdmVzLg0KPiANCj4gUmVmZXJyaW5nIHRvIHRo ZSBzdGVwcyBJIGRlc2NyaWJlZCBpbiBteSBwcmV2aW91cyBhbnN3ZXIgdG8gSGFubmVzLA0KPiBU VVJOOlRMUzo0NDMgaXMgcHJvYmFibHkgdGhlIG1vc3QgdXNlZnVsIG9wdGlvbiBmb3Igc2NlbmFy aW9zIDEgYW5kIDIsDQo+IHRoYXQgaXMsIHdoZXJlIHlvdSBjYW4ganVzdCBwaXBlIHdoYXQgeW91 IHdhbnQgb24gcG9ydCA0NDMgYW5kIGJlIHN1cmUNCj4gaXQgd2lsbCBiZSBpZ25vcmVkIGJ5IHRo ZSBwcm94eS4gSWYgdGhlIHByb3h5IGNoZWNrcyB3aGF0J3MgZ29pbmcgb24sDQo+IHRob3VnaCwg dGhhdCBtYXkgbm90IGJlIGFzIGVhc3kuIFRoZSBwcm94eSBtYXkgYmUgYWN0aW5nIGFzIGEgTUlU TSBmb3INCj4gSFRUUFMsIGFzIFJvbWFuIGRlc2NyaWJlZCwgb3IganVzdCBkb2luZyBzb21lIHRy YWZmaWMgbW9uaXRvcmluZyB3aXRoDQo+IGFub21hbHkgZGV0ZWN0aW9uIG9yIHNvbWV0aGluZyBs aWtlIHRoYXQ6IGZha2luZyB0byBiZSBIVFRQUyBpcyBub3QNCj4gZ29pbmcgdG8gd29yayBpbiB0 aGF0IGNhc2UsIHNpbmNlIHRoZSBwcm94eSBtYXkganVzdCBzZWUgaXQncyBub3QgSFRUUA0KPiBh dCBhbGwsIG9yIG1heSBqdXN0IHVuZGVyc3RhbmQgaXQncyBub3Qgd2hhdCBpdCBjbGFpbXMgdG8g YmUgYmVjYXVzZSBpdA0KPiBkb2Vzbid0IGJlaGF2ZSBhcyBpdCBzaG91bGQ7IEhUVFAgY29ubmVj dGlvbnMgaGF2ZSBhIHVzdWFsbHkgcXVpdGUNCj4gc2ltcGxlIHBhdHRlcm4gKGUuZy4sIG11Y2gg bW9yZSB0cmFmZmljIGdvaW5nIGluIG9uZSBkaXJlY3Rpb24gdGhhbiB0aGUNCj4gb3RoZXIgYW5k IG5ldmVyIGF0IHRoZSBzYW1lIHRpbWUpLCBzb21ldGhpbmcgdGhhdCB3b3VsZCBiZSB2ZXJ5DQo+ IGRpZmZlcmVudCBpbiBhIFRVUk4gY29ubmVjdGlvbiBpbnN0ZWFkLg0KDQpIaSBMb3JlbnpvIC0N Cg0KRW50ZXJwcmlzZSBGaXJld2FsbHMgZG8gaGF2ZSBUTFMgUHJveHkgdGhhdCBpbnNwZWN0IFRM UyB0cmFmZmljLiBUaGlzIGlzIHVzdWFsbHkgZG9uZSB0byBkZXRlY3QgbWFsd2FyZSwgY29udGVu dCBmaWx0ZXJpbmcsIERhdGEgbGVha2FnZSBQcmV2ZW50aW9uLCBwb3J0IG1pc3VzZSwgQXBwbGlj YXRpb24gdmlzaWJpbGl0eSBldGMuIFNvIHNlbmRpbmcgUlRQIHRyYWZmaWMgb3ZlciBIVFRQUy9I VFRQIGNhbiBiZSBkZXRlY3RlZCBhbmQgYmxvY2tlZCBpZiBwb2xpY3kgbWFuZGF0ZXMgaXQuIA0K DQotLVRpcnUuDQoNCj4gDQo+IExvcmVuem8NCj4gDQo+ID4NCj4gPiBSZWdhcmRzLg0KPiA+DQo+ ID4NCj4gPiAtLQ0KPiA+IEnDsWFraSBCYXogQ2FzdGlsbG8NCj4gPiA8aWJjQGFsaWF4Lm5ldD4N Cj4gDQo+IA0KPiAtLQ0KPiBMb3JlbnpvIE1pbmllcm8sIENPQg0KPiANCj4gTWVldGVjaG8gcy5y LmwuDQo+IFdlYiBDb25mZXJlbmNpbmcgYW5kIENvbGxhYm9yYXRpb24gVG9vbHMNCj4gaHR0cDov L3d3dy5tZWV0ZWNoby5jb20NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4gcnRjd2ViIG1haWxpbmcgbGlzdA0KPiBydGN3ZWJAaWV0Zi5vcmcNCj4g aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWINCg== From petithug@acm.org Tue Aug 7 14:36:39 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C528421F8668 for ; Tue, 7 Aug 2012 14:36:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.557 X-Spam-Level: X-Spam-Status: No, score=-102.557 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zy46bflaQpag for ; Tue, 7 Aug 2012 14:36:38 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id B51AC21F8667 for ; Tue, 7 Aug 2012 14:36:38 -0700 (PDT) Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] (shalmaneser.org [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 4928820491; Tue, 7 Aug 2012 21:36:37 +0000 (UTC) Message-ID: <50218A62.6010708@acm.org> Date: Tue, 07 Aug 2012 14:36:34 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.6esrpre) Gecko/20120805 Icedove/10.0.6 MIME-Version: 1.0 To: Lorenzo Miniero References: <20120807180156.286e74d2@rainpc> <20120807191226.5b8e7f32@rainpc> <20120807215415.00bebaa7@rainpc> In-Reply-To: <20120807215415.00bebaa7@rainpc> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: rtcweb@ietf.org Subject: Re: [rtcweb] HTTP Fallback draft X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 07 Aug 2012 21:36:39 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 08/07/2012 12:54 PM, Lorenzo Miniero wrote: > Hi Iñaki, > > > On Tue, 7 Aug 2012 21:34:09 +0200 Iñaki Baz Castillo > wrote: > >> Hi Lorenzo, sorry for opening another thread about this (I didn't check >> my unread emails before reading the draft). Please see comments inline: >> > > > No harm done, don't worry! > > >> >>> Hannes Tschofenig wrote: >> >>>> Just to be clear, I don't have objections regarding your draft. I >>>> just would like to understand what motives people to run everything >>>> over HTTP (besides using HTTP features, which you don't really do). >> >> Honestly I don't like the "all-over-http" vision. Admins filtering >> traffic other than HTTP or HTTPS will also do their best efforts for >> filtering specific traffic over HTTP, and IMHO making specifications to >> run protocolos over HTTP legitimizes those hateful filtering techniques. >> > > > I'm not a fan either, believe me :) > > That said, as I said in another post I still think that, if RTCWEB/WebRTC > is going to be deployed in browsers, they'll expect it to work in all the > places where all other web applications do. Many proprietary protocols that > do real-time communication implement tunneling somehow, or pretend to do > so, which means something in line with that is needed for RTCWEB as well. > > >> >> >> >> >> 2012/8/7 Lorenzo Miniero : >> >>> I agree with you and I'm not really dying to do RTP over HTTP either, >>> but if some scenarios make it impossible for use cases to work (and >>> some firewall/NAT deployers are to blame here, probably) then a >>> fallback mechanism is something that can be nice to have, especially if >>> we're interested in something that "just works". >> >> That's the problem (IMHO): if we make all to work over HTTP then some day >> telcos providers will just offer HTTP (as "Internet") and we'll need to >> study a new OSI model in which the lowest layer is called "HTTP". >> > > > Which is close enough to the hourglass draft Hannes mentioned in his post, > I'm afraid. I can't but agree with you, but, again, if we have use cases > and we want to have them working in as many topologies as possible, > something must be done. > > >> BTW: I sitll don't understand which is the advantage of using RTP over >> HTTPS in comparison to TURN over TLS:443. Does is exist? >> > > > If we talk about a simple comparison, I'm sure TURN:TLS:443 performs much > better than RTP over HTTPS, or at least, over the simple approach I > documented in the draft at least (even though I tried to keep the overhead > as little as possible). Comparing them is probably not fair, though, as > they address two different scenarios: that's why HTTP would be just a > fallback, and not something you'd use when you have alternatives. > > Referring to the steps I described in my previous answer to Hannes, > TURN:TLS:443 is probably the most useful option for scenarios 1 and 2, that > is, where you can just pipe what you want on port 443 and be sure it will > be ignored by the proxy. If the proxy checks what's going on, though, that > may not be as easy. The proxy may be acting as a MITM for HTTPS, as Roman > described, or just doing some traffic monitoring with anomaly detection or > something like that: faking to be HTTPS is not going to work in that case, > since the proxy may just see it's not HTTP at all, or may just understand > it's not what it claims to be because it doesn't behave as it should; HTTP > connections have a usually quite simple pattern (e.g., much more traffic > going in one direction than the other and never at the same time), > something that would be very different in a TURN connection instead. > I think that this problem should be looked from another point of view. One of the basic assumption of ICE is that a TURN address is always added with the lowest priority to the gathered candidate addresses, because it guarantees that ICE will always works. Now we all now that this assumption is not true in 100% of the cases, and this is the reason why years ago I added a TURN over HTTP(S) transport in the product I was developing at the time and worked on an I-D (never published). So instead of seeing TURN over Websocket as a way to work in difficult environments, we can just see it as a way to fulfill the promise of ICE, which is to find a path in 100% of the cases, by adding TURN over UDP then TURN over TCP/TLS, then TURN over Websockets as the lowest priority in the gathered candidate addresses (that will probably require a modification in RFC 5245, as it already recommends a priority of 0 for TURN over UDP). After Taipei I restarted working on this idea, but using Websocket this time. I gave up when I discovered that there was no Websocket dissector in Wireshark, but now that this issue seems to be fixed, perhaps it is a good idea to finish this work. - -- Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJQIYpfAAoJECnERZXWan7EWv0QAK3VY6SzGdzyNCj1PeyMTVb7 UtAbaLWowhpnTYcMsX21qfU5wpH5r9hukJF9hLAxHEe3pYfo6LQaX3Hy18G/kjVo xt7yLmmCvfzV3opbXIoMRiOjLEVLdtLAQLnAEBHwWlP7S32FNCGo45MXu7pg752T 6mWxqyujQJPHSsHZh6b3ayLnjaH2yP6d+hhiuIynta1XuWdsvzi5CBVFB5iLTeKA bAgknMU5O6+j4aJHagNeyybUA/BGmcbday7UomSyJsvEvkcZ1OnFRA6IFU/s+pCp y6f4NrVcJfkL0DC2P1Tu24hd1HcajBFrnn7CPe6x5qZinw0GH0m537QQJG4iqKcr NVdwYvDTl3kJISS/L15jGIat9QLelNqq2ZWmoXIZ/D6NXN4SzlGp91tLCSdiJPtH ODgt8UOdPXuYEDso7uN/LatCRrdc0cSEDFcx+6ipptgaL3nFlrbArXsAnlVdCDo0 a17XiFvpj3NQXXfmYWcJeFvlyh0M8O00+rnjxl1srze+2GR/zZpF9chVxjq8AfVC y3e7n4AyZhtu1B3byYte92abOHgsTW4VQtJrREeTHi3cW5yAGusjfk3XTpQ31YhU FP7t8XARaKI2GOyiUOESbmK1JkCYs8VpdvrM81yVbrRB0DuvUa84caFohAm/VhRm 2pgS8vEHgeO4wXmhGGbq =Ckmc -----END PGP SIGNATURE----- From anant@mozilla.com Tue Aug 7 17:43:01 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7899211E80FA for ; Tue, 7 Aug 2012 17:43:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l7rhpscKsYzd for ; Tue, 7 Aug 2012 17:43:01 -0700 (PDT) Received: from smtp.mozilla.org (mx2.corp.phx1.mozilla.com [63.245.216.70]) by ietfa.amsl.com (Postfix) with ESMTP id CEB5A11E80F2 for ; Tue, 7 Aug 2012 17:43:00 -0700 (PDT) Received: from host-7-176.mv.mozilla.com (corp-240.mv.mozilla.com [63.245.220.240]) (Authenticated sender: anarayanan@mozilla.com) by mx2.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 2DF69F21F6; Tue, 7 Aug 2012 17:43:00 -0700 (PDT) Message-ID: <5021B616.3020302@mozilla.com> Date: Tue, 07 Aug 2012 17:43:02 -0700 From: Anant Narayanan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: "rtcweb@ietf.org" References: <81579634-CC55-46FF-8C3B-94EB5019786A@phonefromhere.com> In-Reply-To: <81579634-CC55-46FF-8C3B-94EB5019786A@phonefromhere.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "public-webrtc@w3.org" Subject: Re: [rtcweb] Microsoft tells W3C and IETF what we are doing no signs of offering real world interoperability X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 08 Aug 2012 00:43:01 -0000 On 8/7/12 2:57 AM, Tim Panton wrote: > Ok, the timing is unfortunate, but can you honestly say that we didn't know that this was skype/microsofts opinion? We just chose to ignore it because it was inconvenient. > > Now that it is out there, are we seriously going to ignore a document with _those_ authors from a major browser maker and a team with extensive experience in the field jus because it is late!?!? I absolutely don't want to discount the extensive collective experience and knowledge of how RTC works that went behind the document - but I have a hard time treating this proposal as coming from a major browser vendor. A proposal from the team behind Skype or Lync is different from a proposal that comes from the IE team. In particular, I strongly disagree with the statement that the existing proposal does not honor "key web tenets". As ekr wrote in his analysis, the web has moved away from a completely stateless model for a while now. In fact, PeerConnection is already more low-level than I would have preferred, especially when compared to the original proposal from Ian Hickson. I don't fully grasp how the significantly more complex Javascript API proposed in the document is actually beneficial to the modern web as a whole. -Anant From bernard_aboba@hotmail.com Tue Aug 7 18:46:41 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D6C811E80F1 for ; Tue, 7 Aug 2012 18:46:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.762 X-Spam-Level: X-Spam-Status: No, score=-101.762 tagged_above=-999 required=5 tests=[AWL=-0.559, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IvTk7QkRHW3k for ; Tue, 7 Aug 2012 18:46:41 -0700 (PDT) Received: from blu0-omc3-s14.blu0.hotmail.com (blu0-omc3-s14.blu0.hotmail.com [65.55.116.89]) by ietfa.amsl.com (Postfix) with ESMTP id 01FD611E80D2 for ; Tue, 7 Aug 2012 18:46:40 -0700 (PDT) Received: from BLU401-EAS256 ([65.55.116.73]) by blu0-omc3-s14.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 7 Aug 2012 18:46:40 -0700 X-Originating-IP: [24.16.96.166] X-EIP: [6DhMyuoPyslJKRCESBx7sDlC9cgNLyhT] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: References: <20120807180156.286e74d2@rainpc> <20120807191226.5b8e7f32@rainpc> Content-Transfer-Encoding: quoted-printable From: Bernard Aboba Content-Type: text/plain; charset="us-ascii" In-Reply-To: <20120807191226.5b8e7f32@rainpc> Date: Tue, 7 Aug 2012 18:51:39 -0700 To: Lorenzo Miniero MIME-Version: 1.0 (1.0) X-OriginalArrivalTime: 08 Aug 2012 01:46:40.0402 (UTC) FILETIME=[A7CC5720:01CD7507] Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] HTTP Fallback draft X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 08 Aug 2012 01:46:41 -0000 > We indeed met such network elements in our experience, even though most of= the times it was just blind UDP filtering rather than RTP filtering per se.= It sometimes was just blind port filtering but the effect was the same. Thi= s mostly happened within enterprises networks where we tried, no matter how s= mall or large. [BA] this fits with my experience as well. > You're right. A couple of years ago we wrote a paper addressing the potent= ial approaches for tunneling attempts (if you're interested, I can send you t= he link offline). In this paper we basically described, as a diagram, which i= ncremental steps could be carried out in order to attempt a successful tunne= ling: 1) the first attempt is to just try port 443, without encapulating any= thing (e.g., ssh using 443 instead of 22); [BA] There are DPI boxes that will compare traffic against TLS and catch thi= s. So if it doesn't work you can't assume that 443 is blocked by the firewal= l. Same with non-HTTP on port 80. > 2) in case that doesn't work, the second attempt is to use HTTP CONNECT an= d then fall back to 1. for the connection that is established; [BA] Trying HTTP on port 443 isn't likely to work if the original non-TLS te= st on 443 failed.=20 > 3) the third attempt (e.g., 443 is not available or the proxy acts as a MI= TM) is to actually encapsulate in HTTP messages, whether you do HTTP or HTTP= S. In every case, the peer (either endpoint or server) must be configured ac= cordingly of course. [BA] If HTTP failed earlier, HTTP encapsulation also will probably fail. It m= akes more sense to me to try TLS on 443. > What I describe in the draft is step 3, even though I guess some words to s= uggest steps 1 and 2 (where you'd still need to encapsulate RTP packets on t= op of a TCP-based protocol anyway) could be considered. As long as it looks l= ike valid HTTP and it behaves accordingly, I think there's no reason why tra= versing should be impeded: [BA] DPI boxes aren't always up to date. For example don't expect them to un= derstand websockets. > I agree with you and I'm not really dying to do RTP over HTTP either, but i= f some scenarios make it impossible for use cases to work (and some firewall= /NAT deployers are to blame here, probably) then a fallback mechanism is som= ething that can be nice to have, especially if we're interested in something= that "just works". [BA] If all the other avenues are tried first, then this would really be a l= ast resort. Any idea how frequently it should be expected to be used?=20= From juberti@google.com Tue Aug 7 20:23:37 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2F2611E80EA for ; Tue, 7 Aug 2012 20:23:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.737 X-Spam-Level: X-Spam-Status: No, score=-102.737 tagged_above=-999 required=5 tests=[AWL=0.239, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5FApmmPCLHSz for ; Tue, 7 Aug 2012 20:23:36 -0700 (PDT) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 61A4511E8087 for ; Tue, 7 Aug 2012 20:23:36 -0700 (PDT) Received: by qadz3 with SMTP id z3so2153286qad.10 for ; Tue, 07 Aug 2012 20:23:35 -0700 (PDT) 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:x-system-of-record; bh=g3F19/v7uGw2pIEhHQf9FzNYyI1FL3cAPv+5EOVVH8Q=; b=T+V/MW7aw1hcjavXaF19BfeL6Y2poqMnrWMde3IAgTWheUQZDlfp3iAnRmskJLU7+u TILX1QPn82jbV70jcZapVVNlfKghjXIC2wBCXAp1m9nS3PKB01+HOwm9HjEf/25vpE+a 3p/QFaU/F653EYuKjDy6ZXA1iLU15tcPEeUnBMM/b5/qSjn9yvBl0clnv5M87uigWanl t/smRlZVujgtLDvquBCnhr/gAQd8gdihJfrAPIXNfpNl+ZhGIrvX0fEcUQUeNuE8uZGP kPF0cfzKNHnswNgd062c+S2gvTWmxPvDA0b3muL+KaESnI0MdJROdWps0ggq6YOC+039 0mTg== X-Google-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:x-system-of-record:x-gm-message-state; bh=g3F19/v7uGw2pIEhHQf9FzNYyI1FL3cAPv+5EOVVH8Q=; b=FESWWYDJt+3C8m1yrAHtsCJPdSDoOKZMvD/ujmtBTnOcfs1iuE6uFVgIgUubHFCQSr EVmTqTTrj3ppe1QbnA4MrLkCeWhEO2aIWS0GPhOEMJ7vMMht7OaT3nAtVyWbVX6PlQsz lT7rlwwpRfjink5JEyi7+DMcPQ0RRfE/IE0Udf0f0v1PDhCBOPlU2pFOj92Nr8FsGXN+ a3NSPeIhX4/L/bWE/Un3F6r+rtQG9cPo+akslvQ4TFHpZ9f06g1iD3Rp+U10EPMPJhdO 6VCkRluFJ7LFZy0erltvf6TTc1k1QxerUIVmFmiTjLWYI5MyyoOIkhnRzH9o5+rFjp6J BbgQ== Received: by 10.224.188.12 with SMTP id cy12mr27631345qab.68.1344396215916; Tue, 07 Aug 2012 20:23:35 -0700 (PDT) Received: by 10.224.188.12 with SMTP id cy12mr27631337qab.68.1344396215812; Tue, 07 Aug 2012 20:23:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.218.80 with HTTP; Tue, 7 Aug 2012 20:23:15 -0700 (PDT) In-Reply-To: <20120807205447.2212f617@rainpc> References: <20120807180156.286e74d2@rainpc> <20120807205447.2212f617@rainpc> From: Justin Uberti Date: Tue, 7 Aug 2012 20:23:15 -0700 Message-ID: To: Lorenzo Miniero Content-Type: multipart/alternative; boundary=20cf30363ebbe181b104c6b8a2b4 X-System-Of-Record: true X-Gm-Message-State: ALoCoQkZQ2tMS/wfj0EhgRDXATSGNcTC8b0X0+ik9zfv7gQpTzo4Vd/DG44aOF2SwIBSzqwq/49lZJ6pKJAaWgbnSXnP+g98i8sPhpZlkr8xXOuKZQESN2/IhOsY7xlfdDcbNI6Z26x2TM+M76DgHj3s1sQmr7gWLOCf/nJKadxNac8CXlURoMo4JjS5Y/bakSvoBC4BnWW2 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] HTTP Fallback draft X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 08 Aug 2012 03:23:38 -0000 --20cf30363ebbe181b104c6b8a2b4 Content-Type: text/plain; charset=UTF-8 My perspective is that we can make a huge impact simply by codifying the rules for doing basic things like TURN over 443 (with or without TLS), HTTP CONNECT, etc. Running RTP over HTTP could help us get closer to 100% coverage, but I think we start to enter the area of diminishing returns. As such, I'd like to see us work towards a best practices document for establishing sessions in these restricted environments; I think such a document would be in scope for RTCWEB. On Tue, Aug 7, 2012 at 11:54 AM, Lorenzo Miniero wrote: > Hello Ted, > > > On Tue, 7 Aug 2012 10:50:07 -0700 > Ted Hardie wrote: > > > On Tue, Aug 7, 2012 at 9:01 AM, Lorenzo Miniero > wrote: > > > That said, I guess there's a different question I should be asking to > > > the chairs: since there seems to be no related item in the milestones, > > > is such a work actually in line with what is the expected outcome of > the > > > WG? Considering the draft basically addresses a new transport for RTP > > > and something that probably needs to be negotiated as well, I guess > this > > > could be seen as belonging elsewhere (AVTCORE and/or MMUSIC?). > > > Nevertheless, my feeling is it belongs more here than somewhere else, > > > especially considering we're specifying a solution that will be > deployed > > > in browsers and, as such, people will expect it to work wherever other > > > web applications do. > > > > My take on this is that the actual work on developing the alternate > > transport for RTP would have to occur elsewhere and, frankly, I think > > it is a large enough task that it would likely require its own working > > group (much as the RTP congestion control topic ended up as a BoF and > > hopefully will become its own working group). That doesn't mean that > > the work couldn't be informed by the RTCWEB use cases, but I think it > > would have to be done elsewhere. > > > > I'd personally suggest starting with a discussion with the ADs on > > whether a BoF on this topic would be something they might consider. > > (Note, however, that I have not talked to Cullen about this and Magnus > > is on vacation, so this is not a "Chairs' response"; just my own > > thoughts). > > > > > This makes sense. I'm a bit concerned about the additional time that may > be needed by going through the process of forming a new WG (compared to > just adding a milestone to an existing WG, that is), as the final result > may end up being available much after the original WG completed its works, > but I see your point. > > I'll wait for more feedback about this and, if enough people seem > interested about doing something like this, contacting the ADs and consider > the next steps may be a good idea. > > Lorenzo > > > > regards, > > > > Ted Hardie > > > -- > Lorenzo Miniero, COB > > Meetecho s.r.l. > Web Conferencing and Collaboration Tools > http://www.meetecho.com > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --20cf30363ebbe181b104c6b8a2b4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable My perspective is that we can make a huge impact simply by codifying the ru= les for doing basic things like TURN over 443 (with or without TLS), HTTP C= ONNECT, etc. Running RTP over HTTP could help us get closer to 100% coverag= e, but I think we start to enter the area of diminishing returns.

As such, I'd like to see us work towards a best practice= s document for establishing sessions in these restricted environments; I th= ink such a document would be in scope for RTCWEB.


On Tue, Aug 7, 2012 at 11:54 AM, Lorenzo= Miniero <lorenzo@meetecho.com> wrote:
Hello Ted,


On Tue, 7 Aug 2012 10:50:07 -0700
Ted Hardie <ted.ietf@gmail.com= > wrote:

> On Tue, Aug 7, 2012 at 9:01 AM, Lorenzo Miniero <lorenzo@meetecho.com> wrote:
> > That said, I guess there's a different question I should be a= sking to
> > the chairs: since there seems to be no related item in the milest= ones,
> > is such a work actually in line with what is the expected outcome= of the
> > WG? Considering the draft basically addresses a new transport for= RTP
> > and something that probably needs to be negotiated as well, I gue= ss this
> > could be seen as belonging elsewhere (AVTCORE and/or MMUSIC?). > > Nevertheless, my feeling is it belongs more here than somewhere e= lse,
> > especially considering we're specifying a solution that will = be deployed
> > in browsers and, as such, people will expect it to work wherever = other
> > web applications do.
>
> My take on this is that the actual work on developing the alternate > transport for RTP would have to occur elsewhere and, frankly, I think<= br> > it is a large enough task that it would likely require its own working=
> group (much as the RTP congestion control topic ended up as a BoF and<= br> > hopefully will become its own working group). =C2=A0That doesn't m= ean that
> the work couldn't be informed by the RTCWEB use cases, but I think= it
> would have to be done elsewhere.
>
> I'd personally suggest starting with a discussion with the ADs on<= br> > whether a BoF on this topic would be something they might consider. > (Note, however, that I have not talked to Cullen about this and Magnus=
> is on vacation, so this is not a "Chairs' response"; jus= t my own
> thoughts).
>


This makes sense. I'm a bit concerned about the additional = time that may be needed by going through the process of forming a new WG (c= ompared to just adding a milestone to an existing WG, that is), as the fina= l result may end up being available much after the original WG completed it= s works, but I see your point.

I'll wait for more feedback about this and, if enough people seem inter= ested about doing something like this, contacting the ADs and consider the = next steps may be a good idea.

Lorenzo


> regards,
>
> Ted Hardie


--
Lorenzo Miniero, COB

Meetecho s.r.l.
Web Conferencing and Collaboration Tools
http://www.meetecho.c= om
_____________________________= __________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb

--20cf30363ebbe181b104c6b8a2b4-- From tireddy@cisco.com Tue Aug 7 23:18:29 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48BC611E8132 for ; Tue, 7 Aug 2012 23:18:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.174 X-Spam-Level: X-Spam-Status: No, score=-10.174 tagged_above=-999 required=5 tests=[AWL=0.425, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KkEcYYrPOCEt for ; Tue, 7 Aug 2012 23:18:28 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 7D01011E80AD for ; Tue, 7 Aug 2012 23:18:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=tireddy@cisco.com; l=3309; q=dns/txt; s=iport; t=1344406708; x=1345616308; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=e+bi1nbENmre5ci3j8JOAdDCM6omXroKKnvLBhJN1ts=; b=fZvhvoUm+07hK36DT39dKIjJ+jL5Eh6p50sCOP9ZeQeXmg9hVMFzH12c M5u8VED3aw78QCAmtcNxXuFP7JUsieja6TZ1qhwcnUQ4L2HXnukgfdNDq /c3+fNqnz9yuB/16vOMzk9TV1enI7bk/4FuozstqkWAXBV14j/7DHeo8s I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAOcDIlCtJV2d/2dsb2JhbABFuWyBB4IgAQEBAwEBAQEPASctBwsMBAIBCBEEAQELFAkHJwsUCQgCBAENBQgah2UGC5pYoEOLD4YAYAOWXI0SgWaCXw X-IronPort-AV: E=Sophos;i="4.77,730,1336348800"; d="scan'208";a="109459656" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-6.cisco.com with ESMTP; 08 Aug 2012 06:18:28 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id q786IQQR031869 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 8 Aug 2012 06:18:27 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.216]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0298.004; Wed, 8 Aug 2012 01:18:27 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Bernard Aboba , Lorenzo Miniero Thread-Topic: [rtcweb] HTTP Fallback draft Thread-Index: AQHNdLbePFtYWCPhFk+Ws7zgJPkdgJdO4KUAgAAJYQCAAJERgP//9WQg Date: Wed, 8 Aug 2012 06:18:27 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A1477EDB9@xmb-rcd-x10.cisco.com> References: <20120807180156.286e74d2@rainpc> <20120807191226.5b8e7f32@rainpc> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.85.136] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19092.004 x-tm-as-result: No--55.020500-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] HTTP Fallback draft X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 08 Aug 2012 06:18:29 -0000 > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > Behalf Of Bernard Aboba > Sent: Wednesday, August 08, 2012 7:22 AM > To: Lorenzo Miniero > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] HTTP Fallback draft >=20 > > We indeed met such network elements in our experience, even though > most of the times it was just blind UDP filtering rather than RTP > filtering per se. It sometimes was just blind port filtering but the > effect was the same. This mostly happened within enterprises networks > where we tried, no matter how small or large. >=20 >=20 > [BA] this fits with my experience as well. >=20 > > You're right. A couple of years ago we wrote a paper addressing the > potential approaches for tunneling attempts (if you're interested, I > can send you the link offline). In this paper we basically described, > as a diagram, which incremental steps could be carried out in order to > attempt a successful tunneling: 1) the first attempt is to just try > port 443, without encapulating anything (e.g., ssh using 443 instead of > 22); >=20 > [BA] There are DPI boxes that will compare traffic against TLS and > catch this. So if it doesn't work you can't assume that 443 is blocked > by the firewall. Same with non-HTTP on port 80. >=20 > > 2) in case that doesn't work, the second attempt is to use HTTP > CONNECT and then fall back to 1. for the connection that is > established; >=20 > [BA] Trying HTTP on port 443 isn't likely to work if the original non- > TLS test on 443 failed. >=20 > > 3) the third attempt (e.g., 443 is not available or the proxy acts as > a MITM) is to actually encapsulate in HTTP messages, whether you do > HTTP or HTTPS. In every case, the peer (either endpoint or server) must > be configured accordingly of course. >=20 > [BA] If HTTP failed earlier, HTTP encapsulation also will probably > fail. It makes more sense to me to try TLS on 443. [Tiru] Firewalls with TLS Proxy capability can detect such misuse and block= . we have an alternate proposal to permit UDP flows across firewall http://tools.ietf.org/html/draft-reddy-rtcweb-stun-auth-fw-traversal-00=20 >=20 > > What I describe in the draft is step 3, even though I guess some > words to suggest steps 1 and 2 (where you'd still need to encapsulate > RTP packets on top of a TCP-based protocol anyway) could be considered. > As long as it looks like valid HTTP and it behaves accordingly, I think > there's no reason why traversing should be impeded: >=20 > [BA] DPI boxes aren't always up to date. For example don't expect them > to understand websockets. >=20 > > I agree with you and I'm not really dying to do RTP over HTTP either, > but if some scenarios make it impossible for use cases to work (and > some firewall/NAT deployers are to blame here, probably) then a > fallback mechanism is something that can be nice to have, especially if > we're interested in something that "just works". >=20 > [BA] If all the other avenues are tried first, then this would really > be a last resort. Any idea how frequently it should be expected to be > used? > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From lorenzo@meetecho.com Wed Aug 8 03:09:31 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64F1C21F86B0 for ; Wed, 8 Aug 2012 03:09:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.669 X-Spam-Level: X-Spam-Status: No, score=-0.669 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QvCSecwhmRAA for ; Wed, 8 Aug 2012 03:09:30 -0700 (PDT) Received: from smtplq01.aruba.it (smtplq-out5.aruba.it [62.149.158.25]) by ietfa.amsl.com (Postfix) with SMTP id EA48221F86AF for ; Wed, 8 Aug 2012 03:09:29 -0700 (PDT) Received: (qmail 3054 invoked by uid 89); 8 Aug 2012 10:09:27 -0000 Received: from unknown (HELO smtp4.aruba.it) (62.149.158.224) by smtplq01.aruba.it with SMTP; 8 Aug 2012 10:09:27 -0000 Received: (qmail 14981 invoked by uid 89); 8 Aug 2012 10:09:27 -0000 Received: from unknown (HELO rainpc) (lorenzo@meetecho.com@80.181.173.222) by smtp4.ad.aruba.it with SMTP; 8 Aug 2012 10:09:26 -0000 Date: Wed, 8 Aug 2012 12:03:18 +0200 From: Lorenzo Miniero To: Bernard Aboba Message-ID: <20120808120318.374ac70b@rainpc> In-Reply-To: References: <20120807180156.286e74d2@rainpc> <20120807191226.5b8e7f32@rainpc> Organization: Meetecho X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.8; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Rating: smtp4.ad.aruba.it 1.6.2 0/1000/N X-Spam-Rating: smtplq01.aruba.it 1.6.2 0/1000/N Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] HTTP Fallback draft X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 08 Aug 2012 10:09:31 -0000 Hi Bernard, answering inline, On Tue, 7 Aug 2012 18:51:39 -0700 Bernard Aboba wrote: > > We indeed met such network elements in our experience, even though most of the times it was just blind UDP filtering rather than RTP filtering per se. It sometimes was just blind port filtering but the effect was the same. This mostly happened within enterprises networks where we tried, no matter how small or large. > > > [BA] this fits with my experience as well. > > > You're right. A couple of years ago we wrote a paper addressing the potential approaches for tunneling attempts (if you're interested, I can send you the link offline). In this paper we basically described, as a diagram, which incremental steps could be carried out in order to attempt a successful tunneling: 1) the first attempt is to just try port 443, without encapulating anything (e.g., ssh using 443 instead of 22); > > [BA] There are DPI boxes that will compare traffic against TLS and catch this. So if it doesn't work you can't assume that 443 is blocked by the firewall. Same with non-HTTP on port 80. > You're right, actually I didn't fully describe the approach we presented in that paper. In that approach, infact, we did made use of TLS to encapsulate the traffic to tunnel (in the paper we tunneled everything we needed, not just RTP) on 443, with or without the CONNECT. So it was not a blind piping stuff on 443 or 80 (which may still work in a few cases, though), which means that other approaches like the TURN/TLS:443 could work fine there. > > 2) in case that doesn't work, the second attempt is to use HTTP CONNECT and then fall back to 1. for the connection that is established; > > [BA] Trying HTTP on port 443 isn't likely to work if the original non-TLS test on 443 failed. > The CONNECT approach as we conceived it in the paper at the time actually sends an HTTP CONNECT on port 80 to request an encrypted connection towards a 443 destination. If the request is successfull, we have the same TLS stuff as in the direct approach. Or are you talking about something different? > > 3) the third attempt (e.g., 443 is not available or the proxy acts as a MITM) is to actually encapsulate in HTTP messages, whether you do HTTP or HTTPS. In every case, the peer (either endpoint or server) must be configured accordingly of course. > > [BA] If HTTP failed earlier, HTTP encapsulation also will probably fail. It makes more sense to me to try TLS on 443. > > > What I describe in the draft is step 3, even though I guess some words to suggest steps 1 and 2 (where you'd still need to encapsulate RTP packets on top of a TCP-based protocol anyway) could be considered. As long as it looks like valid HTTP and it behaves accordingly, I think there's no reason why traversing should be impeded: > > [BA] DPI boxes aren't always up to date. For example don't expect them to understand websockets. > That's true, and that's why in the draft I proposed a more "basic" approach: that is, relying on a simpler behaviour for HTTP, chunked or not GET and POST messages, in order to look as much as possible as normal HTTP. Probably not very efficient, but more likely to be accepted by intermediaries. > > I agree with you and I'm not really dying to do RTP over HTTP either, but if some scenarios make it impossible for use cases to work (and some firewall/NAT deployers are to blame here, probably) then a fallback mechanism is something that can be nice to have, especially if we're interested in something that "just works". > > [BA] If all the other avenues are tried first, then this would really be a last resort. Any idea how frequently it should be expected to be used? The ideal scenario would be "never" :) Unfortunately, there are still cases where such an approach may be needed. I'm not sure how often this could happen, though, as it probably depends on how many deployments that enforce such limitations are out there: I'm not sure it's just prisons or military as Roman said, as you just need to properly set up a proxy like Squid to do something like that cheaply, so there could be more. Thanks, Lorenzo -- Lorenzo Miniero, COB Meetecho s.r.l. Web Conferencing and Collaboration Tools http://www.meetecho.com From lorenzo@meetecho.com Wed Aug 8 03:14:55 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA21221F86B1 for ; Wed, 8 Aug 2012 03:14:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.676 X-Spam-Level: X-Spam-Status: No, score=-0.676 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b-BX27tKb+Rh for ; Wed, 8 Aug 2012 03:14:55 -0700 (PDT) Received: from smtplq04.aruba.it (smtplq-out6.aruba.it [62.149.158.26]) by ietfa.amsl.com (Postfix) with SMTP id 633F021F8516 for ; Wed, 8 Aug 2012 03:14:54 -0700 (PDT) Received: (qmail 1924 invoked by uid 89); 8 Aug 2012 10:14:51 -0000 Received: from unknown (HELO smtp5.aruba.it) (62.149.158.225) by smtplq04.aruba.it with SMTP; 8 Aug 2012 10:14:51 -0000 Received: (qmail 2381 invoked by uid 89); 8 Aug 2012 10:14:51 -0000 Received: from unknown (HELO rainpc) (lorenzo@meetecho.com@80.181.173.222) by smtp5.ad.aruba.it with SMTP; 8 Aug 2012 10:14:50 -0000 Date: Wed, 8 Aug 2012 12:08:42 +0200 From: Lorenzo Miniero To: Justin Uberti Message-ID: <20120808120842.1ad1e709@rainpc> In-Reply-To: References: <20120807180156.286e74d2@rainpc> <20120807205447.2212f617@rainpc> Organization: Meetecho X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.8; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Rating: smtp5.ad.aruba.it 1.6.2 0/1000/N X-Spam-Rating: smtplq04.aruba.it 1.6.2 0/1000/N Cc: rtcweb@ietf.org Subject: Re: [rtcweb] HTTP Fallback draft X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 08 Aug 2012 10:14:56 -0000 Hi Justin, On Tue, 7 Aug 2012 20:23:15 -0700 Justin Uberti wrote: > My perspective is that we can make a huge impact simply by codifying the > rules for doing basic things like TURN over 443 (with or without TLS), HTTP > CONNECT, etc. Running RTP over HTTP could help us get closer to 100% > coverage, but I think we start to enter the area of diminishing returns. > > As such, I'd like to see us work towards a best practices document for > establishing sessions in these restricted environments; I think such a > document would be in scope for RTCWEB. > You're right, according to the feedback gathered on the draft so far this looks like a reasonable way to move on. I'm not sure a pure BCP would be enough, though, considering that too many documented different approaches, no matter how effective each, could eventually lead to a few interoperability issues (some browsers/relays may end up implementing some and not others). Maybe something in line with a BCP that at least mandates a certain sequence of or logic in attempts? Lorenzo > > On Tue, Aug 7, 2012 at 11:54 AM, Lorenzo Miniero wrote: > > > Hello Ted, > > > > > > On Tue, 7 Aug 2012 10:50:07 -0700 > > Ted Hardie wrote: > > > > > On Tue, Aug 7, 2012 at 9:01 AM, Lorenzo Miniero > > wrote: > > > > That said, I guess there's a different question I should be asking to > > > > the chairs: since there seems to be no related item in the milestones, > > > > is such a work actually in line with what is the expected outcome of > > the > > > > WG? Considering the draft basically addresses a new transport for RTP > > > > and something that probably needs to be negotiated as well, I guess > > this > > > > could be seen as belonging elsewhere (AVTCORE and/or MMUSIC?). > > > > Nevertheless, my feeling is it belongs more here than somewhere else, > > > > especially considering we're specifying a solution that will be > > deployed > > > > in browsers and, as such, people will expect it to work wherever other > > > > web applications do. > > > > > > My take on this is that the actual work on developing the alternate > > > transport for RTP would have to occur elsewhere and, frankly, I think > > > it is a large enough task that it would likely require its own working > > > group (much as the RTP congestion control topic ended up as a BoF and > > > hopefully will become its own working group). That doesn't mean that > > > the work couldn't be informed by the RTCWEB use cases, but I think it > > > would have to be done elsewhere. > > > > > > I'd personally suggest starting with a discussion with the ADs on > > > whether a BoF on this topic would be something they might consider. > > > (Note, however, that I have not talked to Cullen about this and Magnus > > > is on vacation, so this is not a "Chairs' response"; just my own > > > thoughts). > > > > > > > > > This makes sense. I'm a bit concerned about the additional time that may > > be needed by going through the process of forming a new WG (compared to > > just adding a milestone to an existing WG, that is), as the final result > > may end up being available much after the original WG completed its works, > > but I see your point. > > > > I'll wait for more feedback about this and, if enough people seem > > interested about doing something like this, contacting the ADs and consider > > the next steps may be a good idea. > > > > Lorenzo > > > > > > > regards, > > > > > > Ted Hardie > > > > > > -- > > Lorenzo Miniero, COB > > > > Meetecho s.r.l. > > Web Conferencing and Collaboration Tools > > http://www.meetecho.com > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb > > -- Lorenzo Miniero, COB Meetecho s.r.l. Web Conferencing and Collaboration Tools http://www.meetecho.com From cb.list6@gmail.com Wed Aug 8 08:05:32 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AF9A21F84F5 for ; Wed, 8 Aug 2012 08:05:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.468 X-Spam-Level: X-Spam-Status: No, score=-3.468 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2hgxQG3B5x4H for ; Wed, 8 Aug 2012 08:05:31 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7AB4921F8319 for ; Wed, 8 Aug 2012 08:05:30 -0700 (PDT) Received: by lahm15 with SMTP id m15so503468lah.31 for ; Wed, 08 Aug 2012 08:05:29 -0700 (PDT) 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=cloWDLE54Ky+01MXkQAgcrdwl5MjkDnkEDNoZIOuiS4=; b=ivrAFDAVPqm319hIu7tCG5JKWO1R2GXIHWvavf0DvMPo3xdj9XovXriMSqHTJBpQfm gH4Ec34jQ4CK3SmLaaf9Qe55KJR0Gz7roKfdHbf00D0VW5zZ5PlJ44CkJ3kxBGG/Wq3V 4EqVxN2OnF0Z2rzxNEr+YoHMpXwhTgK69JZu5Z7BYkdOsHjiyVNDTG9UKnkWsm3OjvKt AUjN1N+NAYF8d1JMSeEj3MqU9w/sgchjOFzIeYmK/tgRLJ3POjyPwhLJfdhB2yA6qn8y M28RLnlNrbqAbOuJpOMEZr8nxMug2kZp/srqTzXtw2zzCvxDzXF/YHzT0Y9Lt/q0oGkm 71Ig== MIME-Version: 1.0 Received: by 10.112.101.194 with SMTP id fi2mr2669729lbb.104.1344438329213; Wed, 08 Aug 2012 08:05:29 -0700 (PDT) Received: by 10.112.3.196 with HTTP; Wed, 8 Aug 2012 08:05:28 -0700 (PDT) Received: by 10.112.3.196 with HTTP; Wed, 8 Aug 2012 08:05:28 -0700 (PDT) In-Reply-To: <913383AAA69FF945B8F946018B75898A1477EDB9@xmb-rcd-x10.cisco.com> References: <20120807180156.286e74d2@rainpc> <20120807191226.5b8e7f32@rainpc> <913383AAA69FF945B8F946018B75898A1477EDB9@xmb-rcd-x10.cisco.com> Date: Wed, 8 Aug 2012 08:05:28 -0700 Message-ID: From: Cameron Byrne To: "Tirumaleswar Reddy (tireddy)" Content-Type: multipart/alternative; boundary=f46d040169b50904a804c6c2712b Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] HTTP Fallback draft X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 08 Aug 2012 15:05:32 -0000 --f46d040169b50904a804c6c2712b Content-Type: text/plain; charset=ISO-8859-1 On Aug 7, 2012 11:18 PM, "Tirumaleswar Reddy (tireddy)" wrote: > > > -----Original Message----- > > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > > Behalf Of Bernard Aboba > > Sent: Wednesday, August 08, 2012 7:22 AM > > To: Lorenzo Miniero > > Cc: rtcweb@ietf.org > > Subject: Re: [rtcweb] HTTP Fallback draft > > > > > We indeed met such network elements in our experience, even though > > most of the times it was just blind UDP filtering rather than RTP > > filtering per se. It sometimes was just blind port filtering but the > > effect was the same. This mostly happened within enterprises networks > > where we tried, no matter how small or large. > > > > > > [BA] this fits with my experience as well. > > > > > You're right. A couple of years ago we wrote a paper addressing the > > potential approaches for tunneling attempts (if you're interested, I > > can send you the link offline). In this paper we basically described, > > as a diagram, which incremental steps could be carried out in order to > > attempt a successful tunneling: 1) the first attempt is to just try > > port 443, without encapulating anything (e.g., ssh using 443 instead of > > 22); > > > > [BA] There are DPI boxes that will compare traffic against TLS and > > catch this. So if it doesn't work you can't assume that 443 is blocked > > by the firewall. Same with non-HTTP on port 80. > > > > > 2) in case that doesn't work, the second attempt is to use HTTP > > CONNECT and then fall back to 1. for the connection that is > > established; > > > > [BA] Trying HTTP on port 443 isn't likely to work if the original non- > > TLS test on 443 failed. > > > > > 3) the third attempt (e.g., 443 is not available or the proxy acts as > > a MITM) is to actually encapsulate in HTTP messages, whether you do > > HTTP or HTTPS. In every case, the peer (either endpoint or server) must > > be configured accordingly of course. > > > > [BA] If HTTP failed earlier, HTTP encapsulation also will probably > > fail. It makes more sense to me to try TLS on 443. > > [Tiru] Firewalls with TLS Proxy capability can detect such misuse and block. we have an alternate proposal to permit UDP flows across firewall > http://tools.ietf.org/html/draft-reddy-rtcweb-stun-auth-fw-traversal-00 > Is this thread really about the ietf engineering a way to by-pass network policy set by network operators? I do not believe that is acceptable. CB > > > > > What I describe in the draft is step 3, even though I guess some > > words to suggest steps 1 and 2 (where you'd still need to encapsulate > > RTP packets on top of a TCP-based protocol anyway) could be considered. > > As long as it looks like valid HTTP and it behaves accordingly, I think > > there's no reason why traversing should be impeded: > > > > [BA] DPI boxes aren't always up to date. For example don't expect them > > to understand websockets. > > > > > I agree with you and I'm not really dying to do RTP over HTTP either, > > but if some scenarios make it impossible for use cases to work (and > > some firewall/NAT deployers are to blame here, probably) then a > > fallback mechanism is something that can be nice to have, especially if > > we're interested in something that "just works". > > > > [BA] If all the other avenues are tried first, then this would really > > be a last resort. Any idea how frequently it should be expected to be > > used? > > _______________________________________________ > > 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 --f46d040169b50904a804c6c2712b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Aug 7, 2012 11:18 PM, "Tirumaleswar Reddy (tireddy)" <tireddy@cisco.com> wrote:
>
> > -----Original Message-----
> > From: rtcweb-bounces@i= etf.org [mailto:rtcweb-bounc= es@ietf.org] On
> > Behalf Of Bernard Aboba
> > Sent: Wednesday, August 08, 2012 7:22 AM
> > To: Lorenzo Miniero
> > Cc: rtcweb@ietf.org
> > Subject: Re: [rtcweb] HTTP Fallback draft
> >
> > > We indeed met such network elements in our experience, even = though
> > most of the times it was just blind UDP filtering rather than RTP=
> > filtering per se. It sometimes was just blind port filtering but = the
> > effect was the same. This mostly happened within enterprises netw= orks
> > where we tried, no matter how small or large.
> >
> >
> > [BA] this fits with my experience as well.
> >
> > > You're right. A couple of years ago we wrote a paper add= ressing the
> > potential approaches for tunneling attempts (if you're intere= sted, I
> > can send you the link offline). In this paper we basically descri= bed,
> > as a diagram, which incremental steps could be carried out in ord= er to
> > attempt a successful tunneling: 1) the first attempt is to just t= ry
> > port 443, without encapulating anything (e.g., ssh using 443 inst= ead of
> > 22);
> >
> > [BA] There are DPI boxes that will compare traffic against TLS an= d
> > catch this. So if it doesn't work you can't assume that 4= 43 is blocked
> > by the firewall. Same with non-HTTP on port 80.
> >
> > > 2) in case that doesn't work, the second attempt is to u= se HTTP
> > CONNECT and then fall back to 1. for the connection that is
> > established;
> >
> > [BA] Trying HTTP on port 443 isn't likely to work if the orig= inal non-
> > TLS test on 443 failed.
> >
> > > 3) the third attempt (e.g., 443 is not available or the prox= y acts as
> > a MITM) is to actually encapsulate in HTTP messages, whether you = do
> > HTTP or HTTPS. In every case, the peer (either endpoint or server= ) must
> > be configured accordingly of course.
> >
> > [BA] If HTTP failed earlier, HTTP encapsulation also will probabl= y
> > fail. It makes more sense to me to try TLS on 443.
>
> [Tiru] Firewalls with TLS Proxy capability can detect such misuse and = block. we have an alternate proposal to permit UDP flows across firewall > http://tools.ietf.org/html/draft-reddy-rtcweb-stun-auth-fw-tr= aversal-00
>

Is this thread=A0 really about the ietf engineering a way to by-pass net= work policy set by network operators?

I do not believe that is acceptable.

CB

> >
> > > What I describe in the draft is step 3, even though I guess = some
> > words to suggest steps 1 and 2 (where you'd still need to enc= apsulate
> > RTP packets on top of a TCP-based protocol anyway) could be consi= dered.
> > As long as it looks like valid HTTP and it behaves accordingly, I= think
> > there's no reason why traversing should be impeded:
> >
> > [BA] DPI boxes aren't always up to date. For example don'= t expect them
> > to understand websockets.
> >
> > > I agree with you and I'm not really dying to do RTP over= HTTP either,
> > but if some scenarios make it impossible for use cases to work (a= nd
> > some firewall/NAT deployers are to blame here, probably) then a > > fallback mechanism is something that can be nice to have, especia= lly if
> > we're interested in something that "just works". > >
> > [BA] If all the other avenues are tried first, then this would re= ally
> > be a last resort. Any idea how frequently it should be expected t= o be
> > used?
> > _______________________________________________
> > rtcweb mailing list
> > rtcweb@ietf.org
> > https://= www.ietf.org/mailman/listinfo/rtcweb
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.i= etf.org/mailman/listinfo/rtcweb

--f46d040169b50904a804c6c2712b-- From ibc@aliax.net Wed Aug 8 08:10:46 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B15DD21F853B for ; Wed, 8 Aug 2012 08:10:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.659 X-Spam-Level: X-Spam-Status: No, score=-2.659 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zbd7cSuXp+Aa for ; Wed, 8 Aug 2012 08:10:38 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id E859421F84F5 for ; Wed, 8 Aug 2012 08:10:37 -0700 (PDT) Received: by lahm15 with SMTP id m15so506739lah.31 for ; Wed, 08 Aug 2012 08:10:36 -0700 (PDT) X-Google-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:content-transfer-encoding:x-gm-message-state; bh=y2NUrnEc4MIesgHlt5QXatEoUrGMl4yIcDyDYtAT7zU=; b=Ch8i6GZOftBvMOWqFsTMzX7ExXpqeOTq3f16ePapst/Po4uwzVhTcniFiNpYOw3C6g 8GgDO4ckcyE7D4PpGaqDRqjAbwOM7rpHnrUxQ8zJrwdDri43Fkx+wlEcUZEq/sjeOOjF 40wuvejCPU1oDbBrMSL/nlteVvgWB+4BgjUHMITz+dREsTMb6u2oEgzZK+RgSIfApACc G8nIj8mM66i8VstOou3YHQ2K3S9JHHtfPR0ELTJ/n9qx0OeV7XxjgKvGP0CkQ4RsD/GA 5ted2aHEn02u60T6x8U4w9xMJkog8xZyX9ho2al050rwLAon8jBMpkWRydFkDThr/MUt Lsyg== Received: by 10.152.112.233 with SMTP id it9mr18340208lab.40.1344438636733; Wed, 08 Aug 2012 08:10:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.23.2 with HTTP; Wed, 8 Aug 2012 08:10:16 -0700 (PDT) In-Reply-To: References: <20120807180156.286e74d2@rainpc> <20120807191226.5b8e7f32@rainpc> <913383AAA69FF945B8F946018B75898A1477EDB9@xmb-rcd-x10.cisco.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Wed, 8 Aug 2012 17:10:16 +0200 Message-ID: To: Cameron Byrne Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQk1BchdLfvBZYrZJtrGAPJKAqO1mRMGUB9O0KCAG1Yr2PS9KOYt+x8lwIZ1JgA6KQ8Zdn0Z Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] HTTP Fallback draft X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 08 Aug 2012 15:10:46 -0000 2012/8/8 Cameron Byrne : > Is this thread really about the ietf engineering a way to by-pass networ= k > policy set by network operators? > > I do not believe that is acceptable. Not exactly. Imagine the classic example of hotels providing free WiFi (but just for HTTP and HTTPS). They do allow their clients to visit web pages and, therefore, I could expect that they would also allow any kind of communication that takes place within the web page. WebRTC introduces UDP, RTP, ICE and more stuf into the WWW world. These protocols could be blocked in some scenarios (hotel WiFi) but that does not necessarily mean that the network admins want to block WebRTC (since it occurs "within" the WWW they already allow). --=20 I=C3=B1aki Baz Castillo From tireddy@cisco.com Wed Aug 8 08:21:13 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F80121F859A for ; Wed, 8 Aug 2012 08:21:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.234 X-Spam-Level: X-Spam-Status: No, score=-10.234 tagged_above=-999 required=5 tests=[AWL=0.364, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eXuyxPxoe1AI for ; Wed, 8 Aug 2012 08:21:11 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id F1E3421F85A5 for ; Wed, 8 Aug 2012 08:21:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=tireddy@cisco.com; l=14846; q=dns/txt; s=iport; t=1344439271; x=1345648871; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=5S1OLQaN6D4pbby+NClvJkrvUk1f52bSj9DbHWlbDwk=; b=e2KJQBsVFM5g62WhHW1X4zEqtmmy+WBirCwALC/HVqDkiGkhkxli33YF h0rrzbIj5bVFgg32LjPTHUmPha/3xICLakYBWnRUrxSZC55atgpMrXPs4 nlAaKmi4epaT2BG+vKYIvwTlsUvuOLqxVg1QYGuCAbs418wLY3uIK21Qt 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFAKmCIlCtJV2c/2dsb2JhbABFgkquRwGISYEHgiABAQEEAQEBDwEaOgcLDAQCAQgOAwQBAQEKHQchBgsUCQgCBA4FCBqHXAMMC5pmlmYNiU6KLWWGAGADk3aCZ4l2gx+BZoJf X-IronPort-AV: E=Sophos;i="4.77,733,1336348800"; d="scan'208,217";a="109616146" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-8.cisco.com with ESMTP; 08 Aug 2012 15:21:10 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id q78FL9gk024431 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 8 Aug 2012 15:21:10 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.216]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0298.004; Wed, 8 Aug 2012 10:21:09 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Cameron Byrne Thread-Topic: [rtcweb] HTTP Fallback draft Thread-Index: AQHNdLbePFtYWCPhFk+Ws7zgJPkdgJdO4KUAgAAJYQCAAJERgP//9WQggADoZgD//63vwA== Date: Wed, 8 Aug 2012 15:21:09 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A1477F233@xmb-rcd-x10.cisco.com> References: <20120807180156.286e74d2@rainpc> <20120807191226.5b8e7f32@rainpc> <913383AAA69FF945B8F946018B75898A1477EDB9@xmb-rcd-x10.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.87.8] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19094.000 x-tm-as-result: No--57.431700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A1477F233xmbrcdx10ciscoc_" MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] HTTP Fallback draft X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 08 Aug 2012 15:21:13 -0000 --_000_913383AAA69FF945B8F946018B75898A1477F233xmbrcdx10ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > [Tiru] Firewalls with TLS Proxy capability can detect such misuse and blo= ck. we have an alternate proposal to permit UDP flows across firewall > http://tools.ietf.org/html/draft-reddy-rtcweb-stun-auth-fw-traversal-00 > Is this thread really about the ietf engineering a way to by-pass network = policy set by network operators? I do not believe that is acceptable. CB [Tiru] The above technique is not to by bass Enterprise Firewall policy, bu= t have Firewall policy to permit nominated UDP flows only. For example Ente= rprise can permit calls to selected WebRTC servers that it trusts (let's sa= y Dr.Good) and block others (like Dr. Evil). This draft is solving the pro= blem that in such cases permit call to be successful with WebRTC server Dr.= Good and permit UDP flows for those calls without the need to have a ALG on= Firewall. From: Cameron Byrne [mailto:cb.list6@gmail.com] Sent: Wednesday, August 08, 2012 8:35 PM To: Tirumaleswar Reddy (tireddy) Cc: rtcweb@ietf.org; Lorenzo Miniero; Bernard Aboba Subject: Re: [rtcweb] HTTP Fallback draft On Aug 7, 2012 11:18 PM, "Tirumaleswar Reddy (tireddy)" > wrote: > > > -----Original Message----- > > From: rtcweb-bounces@ietf.org [mailto:r= tcweb-bounces@ietf.org] On > > Behalf Of Bernard Aboba > > Sent: Wednesday, August 08, 2012 7:22 AM > > To: Lorenzo Miniero > > Cc: rtcweb@ietf.org > > Subject: Re: [rtcweb] HTTP Fallback draft > > > > > We indeed met such network elements in our experience, even though > > most of the times it was just blind UDP filtering rather than RTP > > filtering per se. It sometimes was just blind port filtering but the > > effect was the same. This mostly happened within enterprises networks > > where we tried, no matter how small or large. > > > > > > [BA] this fits with my experience as well. > > > > > You're right. A couple of years ago we wrote a paper addressing the > > potential approaches for tunneling attempts (if you're interested, I > > can send you the link offline). In this paper we basically described, > > as a diagram, which incremental steps could be carried out in order to > > attempt a successful tunneling: 1) the first attempt is to just try > > port 443, without encapulating anything (e.g., ssh using 443 instead of > > 22); > > > > [BA] There are DPI boxes that will compare traffic against TLS and > > catch this. So if it doesn't work you can't assume that 443 is blocked > > by the firewall. Same with non-HTTP on port 80. > > > > > 2) in case that doesn't work, the second attempt is to use HTTP > > CONNECT and then fall back to 1. for the connection that is > > established; > > > > [BA] Trying HTTP on port 443 isn't likely to work if the original non- > > TLS test on 443 failed. > > > > > 3) the third attempt (e.g., 443 is not available or the proxy acts as > > a MITM) is to actually encapsulate in HTTP messages, whether you do > > HTTP or HTTPS. In every case, the peer (either endpoint or server) must > > be configured accordingly of course. > > > > [BA] If HTTP failed earlier, HTTP encapsulation also will probably > > fail. It makes more sense to me to try TLS on 443. > > [Tiru] Firewalls with TLS Proxy capability can detect such misuse and blo= ck. we have an alternate proposal to permit UDP flows across firewall > http://tools.ietf.org/html/draft-reddy-rtcweb-stun-auth-fw-traversal-00 > Is this thread really about the ietf engineering a way to by-pass network = policy set by network operators? I do not believe that is acceptable. CB > > > > > What I describe in the draft is step 3, even though I guess some > > words to suggest steps 1 and 2 (where you'd still need to encapsulate > > RTP packets on top of a TCP-based protocol anyway) could be considered. > > As long as it looks like valid HTTP and it behaves accordingly, I think > > there's no reason why traversing should be impeded: > > > > [BA] DPI boxes aren't always up to date. For example don't expect them > > to understand websockets. > > > > > I agree with you and I'm not really dying to do RTP over HTTP either, > > but if some scenarios make it impossible for use cases to work (and > > some firewall/NAT deployers are to blame here, probably) then a > > fallback mechanism is something that can be nice to have, especially if > > we're interested in something that "just works". > > > > [BA] If all the other avenues are tried first, then this would really > > be a last resort. Any idea how frequently it should be expected to be > > used? > > _______________________________________________ > > 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 --_000_913383AAA69FF945B8F946018B75898A1477F233xmbrcdx10ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

> [Tiru] Firewalls with TLS Proxy capability can detect such misuse a= nd block. we have an alternate proposal to permit UDP flows across firewall=
> http://tools.ietf.org/html/draft-reddy-rtcweb-stun-auth-fw-traversal-00=
>

Is this thread  really about the ietf engineering a way to by-pass = network policy set by network operators?

I do not believe that is acceptable.

CB

[Tiru] The above technique is not to by bass Enterprise Fire= wall policy, but have Firewall policy to permit nominated UDP flows only. F= or example Enterprise can permit calls to selected WebRTC servers that it trusts (let’s sa= y Dr.Good) and block others (like Dr. Evil). This draft is  solving th= e problem that in such cases permit call to be successful with WebRTC serve= r Dr.Good and permit UDP flows for those calls without the need to have a ALG on Firewall.

 

 

From: Cameron = Byrne [mailto:cb.list6@gmail.com]
Sent: Wednesday, August 08, 2012 8:35 PM
To: Tirumaleswar Reddy (tireddy)
Cc: rtcweb@ietf.org; Lorenzo Miniero; Bernard Aboba
Subject: Re: [rtcweb] HTTP Fallback draft

 


On Aug 7, 2012 11:18 PM, "Tirumaleswar Reddy (tireddy)" <tireddy@cisco.com> wrote:
>
> > -----Original Message-----
> > From: rtcweb-bounces@i= etf.org [mailto:rtcweb-bounc= es@ietf.org] On
> > Behalf Of Bernard Aboba
> > Sent: Wednesday, August 08, 2012 7:22 AM
> > To: Lorenzo Miniero
> > Cc: rtcweb@ietf.org
> > Subject: Re: [rtcweb] HTTP Fallback draft
> >
> > > We indeed met such network elements in our experience, even = though
> > most of the times it was just blind UDP filtering rather than RTP=
> > filtering per se. It sometimes was just blind port filtering but = the
> > effect was the same. This mostly happened within enterprises netw= orks
> > where we tried, no matter how small or large.
> >
> >
> > [BA] this fits with my experience as well.
> >
> > > You're right. A couple of years ago we wrote a paper address= ing the
> > potential approaches for tunneling attempts (if you're interested= , I
> > can send you the link offline). In this paper we basically descri= bed,
> > as a diagram, which incremental steps could be carried out in ord= er to
> > attempt a successful tunneling: 1) the first attempt is to just t= ry
> > port 443, without encapulating anything (e.g., ssh using 443 inst= ead of
> > 22);
> >
> > [BA] There are DPI boxes that will compare traffic against TLS an= d
> > catch this. So if it doesn't work you can't assume that 443 is bl= ocked
> > by the firewall. Same with non-HTTP on port 80.
> >
> > > 2) in case that doesn't work, the second attempt is to use H= TTP
> > CONNECT and then fall back to 1. for the connection that is
> > established;
> >
> > [BA] Trying HTTP on port 443 isn't likely to work if the original= non-
> > TLS test on 443 failed.
> >
> > > 3) the third attempt (e.g., 443 is not available or the prox= y acts as
> > a MITM) is to actually encapsulate in HTTP messages, whether you = do
> > HTTP or HTTPS. In every case, the peer (either endpoint or server= ) must
> > be configured accordingly of course.
> >
> > [BA] If HTTP failed earlier, HTTP encapsulation also will probabl= y
> > fail. It makes more sense to me to try TLS on 443.
>
> [Tiru] Firewalls with TLS Proxy capability can detect such misuse and = block. we have an alternate proposal to permit UDP flows across firewall > http://tools.ietf.org/html/draft-reddy-rtcweb-stun-auth-fw-traversal-00=
>

Is this thread  really about the ietf engineering a way to by-pass = network policy set by network operators?

I do not believe that is acceptable.

CB

> >
> > > What I describe in the draft is step 3, even though I guess = some
> > words to suggest steps 1 and 2 (where you'd still need to encapsu= late
> > RTP packets on top of a TCP-based protocol anyway) could be consi= dered.
> > As long as it looks like valid HTTP and it behaves accordingly, I= think
> > there's no reason why traversing should be impeded:
> >
> > [BA] DPI boxes aren't always up to date. For example don't expect= them
> > to understand websockets.
> >
> > > I agree with you and I'm not really dying to do RTP over HTT= P either,
> > but if some scenarios make it impossible for use cases to work (a= nd
> > some firewall/NAT deployers are to blame here, probably) then a > > fallback mechanism is something that can be nice to have, especia= lly if
> > we're interested in something that "just works".
> >
> > [BA] If all the other avenues are tried first, then this would re= ally
> > be a last resort. Any idea how frequently it should be expected t= o be
> > used?
> > _______________________________________________
> > rtcweb mailing list
> > rtcweb@ietf.org
> > https://= www.ietf.org/mailman/listinfo/rtcweb
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.i= etf.org/mailman/listinfo/rtcweb

--_000_913383AAA69FF945B8F946018B75898A1477F233xmbrcdx10ciscoc_-- From harald@alvestrand.no Wed Aug 8 08:28:56 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CED3821F86BB for ; Wed, 8 Aug 2012 08:28:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.333 X-Spam-Level: X-Spam-Status: No, score=-110.333 tagged_above=-999 required=5 tests=[AWL=0.266, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DBvSEz77obC6 for ; Wed, 8 Aug 2012 08:28:54 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id D426F21F86B9 for ; Wed, 8 Aug 2012 08:28:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A750039E106 for ; Wed, 8 Aug 2012 17:28:51 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cf9q6QM1DCY6 for ; Wed, 8 Aug 2012 17:28:50 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:be30:5bff:fede:bcdc]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id C665F39E058 for ; Wed, 8 Aug 2012 17:28:50 +0200 (CEST) Message-ID: <502285B2.8080007@alvestrand.no> Date: Wed, 08 Aug 2012 17:28:50 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <20120807180156.286e74d2@rainpc> <20120807191226.5b8e7f32@rainpc> <913383AAA69FF945B8F946018B75898A1477EDB9@xmb-rcd-x10.cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [rtcweb] Appropriateness of bypass mechanisms (Re: HTTP Fallback draft) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 08 Aug 2012 15:28:56 -0000 Forking thread.... On 08/08/2012 05:05 PM, Cameron Byrne wrote: > > > Is this thread really about the ietf engineering a way to by-pass > network policy set by network operators? > It's about getting stuff done in the presence of rules that hinder the "simple way". Those rules may be set that way deliberately, by ignorance, because of implementation limitations, or in error; there's no way to know. > I do not believe that is acceptable. > We've already done TURN, including TURN over TLS. Old quote: "This is not about starting down the slippery slope; this is about how far we slide into the muck at the bottom". From harald@alvestrand.no Wed Aug 8 08:57:23 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08FE811E80FB for ; Wed, 8 Aug 2012 08:57:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.346 X-Spam-Level: X-Spam-Status: No, score=-110.346 tagged_above=-999 required=5 tests=[AWL=0.253, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xBpDwaQAr+jM for ; Wed, 8 Aug 2012 08:57:22 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 5DAB111E80BA for ; Wed, 8 Aug 2012 08:57:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id DC9E439E149; Wed, 8 Aug 2012 17:57:20 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5D-ASrlixJrx; Wed, 8 Aug 2012 17:57:20 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:be30:5bff:fede:bcdc]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id C94B639E106; Wed, 8 Aug 2012 17:57:19 +0200 (CEST) Message-ID: <50228C5F.8010403@alvestrand.no> Date: Wed, 08 Aug 2012 17:57:19 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Tim Panton References: <81579634-CC55-46FF-8C3B-94EB5019786A@phonefromhere.com> In-Reply-To: <81579634-CC55-46FF-8C3B-94EB5019786A@phonefromhere.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Alexey Aylarov , "Cullen Jennings \(fluffy\)" , "rtcweb@ietf.org" , "public-webrtc@w3.org" Subject: Re: [rtcweb] Microsoft tells W3C and IETF what we are doing no signs of offering real world interoperability X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 08 Aug 2012 15:57:23 -0000 On 08/07/2012 11:57 AM, Tim Panton wrote: > Ok, the timing is unfortunate, but can you honestly say that we didn't know that this was skype/microsofts opinion? We just chose to ignore it because it was inconvenient. > > Now that it is out there, are we seriously going to ignore a document with _those_ authors from a major browser maker and a team with extensive experience in the field jus because it is late!?!? Speaking with WG chair hat on: At the time of previous "what is the appropriate level" discussion, the WG chairs concluded that there was a rough WG consensus to stay with a higher-level API rather than trying to move the level of the API downwards towards a "low level API". Since that time and until this week, there has been no specific proposal to be evaluated, and the main proponents of such an API have been silent. Normal behaviour is to assume that a previous consensus declaration stands until there is new technical evidence to be evaluated, and proceed with further work on that basis. So I can't agree that "because it was inconvenient" is an appropriate characterization. Harald From juberti@google.com Wed Aug 8 12:02:38 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C597721F854F for ; Wed, 8 Aug 2012 12:02:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.756 X-Spam-Level: X-Spam-Status: No, score=-102.756 tagged_above=-999 required=5 tests=[AWL=0.220, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mAdknJZwh-2m for ; Wed, 8 Aug 2012 12:02:37 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 5796321F8484 for ; Wed, 8 Aug 2012 12:02:37 -0700 (PDT) Received: by qaea16 with SMTP id a16so810127qae.10 for ; Wed, 08 Aug 2012 12:02:36 -0700 (PDT) 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:x-system-of-record; bh=aWeMPm8z70nk9THBkW/CojrZwEQHsLsE2T7soaLLvlc=; b=mCpFtkpU2okWVIvzrD/6x14bTWg0zvbwuEMmhVof4azczg1f3oaqVKQZuk7VWYvyCJ sfIAEGAptWQPKWRwx4reB3SuSda5L4EU5sgaMdiW5J3VWyN1f6uxMUOUrWkaoyiyC93u LQTm4zI6JImAyGAc53lRlI+OnSGAYVzAPRCkheplnTz/P2+2IqBQLnr1ON5hSEJ53wC2 9FPTok0XyNjeS83eR4EVSYtggdIwDJnVqIizEjLKpoI6z3ui/DlW0t+iA86hImdxQ15V hm6e7RZ9OH9cWHf7U1qFWOJvqB16zxIeGKS/AmYzU4frJ/j2j5dVdMRTOcrU9rFsMRIz +Duw== X-Google-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:x-system-of-record:x-gm-message-state; bh=aWeMPm8z70nk9THBkW/CojrZwEQHsLsE2T7soaLLvlc=; b=p0slPPjIxHqeAtwEnlFN6RqOcl0EXiCEsUq26x6/kVMqyyIofvj266jhG0J1/VaK8C gXbxYo1mOgpESrUJSeNF0RaYZu9A/EwZYtSGzAcPRk7/SAQwuxL78ibFeRMYZAdzdiGl vjNx+Jjwf5h4sE3QyU3rAvFa7aGx1Uoe+zd6qb86PmDtipp3GlknxBijqH8AsAW9umm7 AMbifjUaJT/6xqIOfeuqf/T9Y8tbGxIetGKoxBrHS9FqxEg6Ma/2UGCDoh6p5WAszsbL Z1IfWm+9PwZZ+dG/uuFsCjo8XScQ5Krses+RWhoV70uUpPuZkznqte85sbi5df/ULN2x GMCA== Received: by 10.224.106.138 with SMTP id x10mr32174554qao.1.1344452556534; Wed, 08 Aug 2012 12:02:36 -0700 (PDT) Received: by 10.224.106.138 with SMTP id x10mr32174520qao.1.1344452556264; Wed, 08 Aug 2012 12:02:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.218.80 with HTTP; Wed, 8 Aug 2012 12:02:15 -0700 (PDT) In-Reply-To: <20120808120842.1ad1e709@rainpc> References: <20120807180156.286e74d2@rainpc> <20120807205447.2212f617@rainpc> <20120808120842.1ad1e709@rainpc> From: Justin Uberti Date: Wed, 8 Aug 2012 12:02:15 -0700 Message-ID: To: Lorenzo Miniero Content-Type: multipart/alternative; boundary=20cf3074b2d20894ee04c6c5c1da X-System-Of-Record: true X-Gm-Message-State: ALoCoQmVnl4QFjJ/UNQcqcXTISb9FsHvq75aLsQ+d92mOWqCTeESG3VE34DmmnVWxH3j4h7ZEIr66fSFf+LI5zpO3C5O+7jyysfmaESdPQbq/wNGKeGmm1knLvCCZWSxuqAQVyCh3dy68ZfkEeZBCNdN1PocL4cc8nHte2/r8hftG2YMEa/OO9QfPn9E7NjG5VQa4QBDbeLY Cc: rtcweb@ietf.org Subject: Re: [rtcweb] HTTP Fallback draft X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 08 Aug 2012 19:02:38 -0000 --20cf3074b2d20894ee04c6c5c1da Content-Type: text/plain; charset=UTF-8 That makes sense to me. The overall point I was driving at was that we wouldn't have to invent new protocols, we could just propose the sequence/logic that you describe, perhaps accompanied by real-world data that explains the approach. On Wed, Aug 8, 2012 at 3:08 AM, Lorenzo Miniero wrote: > Hi Justin, > > > On Tue, 7 Aug 2012 20:23:15 -0700 > Justin Uberti wrote: > > > My perspective is that we can make a huge impact simply by codifying the > > rules for doing basic things like TURN over 443 (with or without TLS), > HTTP > > CONNECT, etc. Running RTP over HTTP could help us get closer to 100% > > coverage, but I think we start to enter the area of diminishing returns. > > > > As such, I'd like to see us work towards a best practices document for > > establishing sessions in these restricted environments; I think such a > > document would be in scope for RTCWEB. > > > > > You're right, according to the feedback gathered on the draft so far this > looks like a reasonable way to move on. I'm not sure a pure BCP would be > enough, though, considering that too many documented different approaches, > no matter how effective each, could eventually lead to a few > interoperability issues (some browsers/relays may end up implementing some > and not others). Maybe something in line with a BCP that at least mandates > a certain sequence of or logic in attempts? > > Lorenzo > > > > > > On Tue, Aug 7, 2012 at 11:54 AM, Lorenzo Miniero >wrote: > > > > > Hello Ted, > > > > > > > > > On Tue, 7 Aug 2012 10:50:07 -0700 > > > Ted Hardie wrote: > > > > > > > On Tue, Aug 7, 2012 at 9:01 AM, Lorenzo Miniero < > lorenzo@meetecho.com> > > > wrote: > > > > > That said, I guess there's a different question I should be asking > to > > > > > the chairs: since there seems to be no related item in the > milestones, > > > > > is such a work actually in line with what is the expected outcome > of > > > the > > > > > WG? Considering the draft basically addresses a new transport for > RTP > > > > > and something that probably needs to be negotiated as well, I guess > > > this > > > > > could be seen as belonging elsewhere (AVTCORE and/or MMUSIC?). > > > > > Nevertheless, my feeling is it belongs more here than somewhere > else, > > > > > especially considering we're specifying a solution that will be > > > deployed > > > > > in browsers and, as such, people will expect it to work wherever > other > > > > > web applications do. > > > > > > > > My take on this is that the actual work on developing the alternate > > > > transport for RTP would have to occur elsewhere and, frankly, I think > > > > it is a large enough task that it would likely require its own > working > > > > group (much as the RTP congestion control topic ended up as a BoF and > > > > hopefully will become its own working group). That doesn't mean that > > > > the work couldn't be informed by the RTCWEB use cases, but I think it > > > > would have to be done elsewhere. > > > > > > > > I'd personally suggest starting with a discussion with the ADs on > > > > whether a BoF on this topic would be something they might consider. > > > > (Note, however, that I have not talked to Cullen about this and > Magnus > > > > is on vacation, so this is not a "Chairs' response"; just my own > > > > thoughts). > > > > > > > > > > > > > This makes sense. I'm a bit concerned about the additional time that > may > > > be needed by going through the process of forming a new WG (compared to > > > just adding a milestone to an existing WG, that is), as the final > result > > > may end up being available much after the original WG completed its > works, > > > but I see your point. > > > > > > I'll wait for more feedback about this and, if enough people seem > > > interested about doing something like this, contacting the ADs and > consider > > > the next steps may be a good idea. > > > > > > Lorenzo > > > > > > > > > > regards, > > > > > > > > Ted Hardie > > > > > > > > > -- > > > Lorenzo Miniero, COB > > > > > > Meetecho s.r.l. > > > Web Conferencing and Collaboration Tools > > > http://www.meetecho.com > > > _______________________________________________ > > > rtcweb mailing list > > > rtcweb@ietf.org > > > https://www.ietf.org/mailman/listinfo/rtcweb > > > > > > -- > Lorenzo Miniero, COB > > Meetecho s.r.l. > Web Conferencing and Collaboration Tools > http://www.meetecho.com > --20cf3074b2d20894ee04c6c5c1da Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable That makes sense to me. The overall point I was driving at was that we woul= dn't have to invent new protocols, we could just propose the sequence/l= ogic that you describe, perhaps accompanied by real-world data that explain= s the approach.


On Wed, Aug 8, 2012 at 3:08 AM, Lorenzo = Miniero <lorenzo@meetecho.com> wrote:
Hi Justin,


On Tue, 7 Aug 2012 20:23:15 -0700
Justin Uberti <juberti@google.com<= /a>> wrote:

> My perspective is that we can make a huge impact simply by codifying t= he
> rules for doing basic things like TURN over 443 (with or without TLS),= HTTP
> CONNECT, etc. Running RTP over HTTP could help us get closer to 100% > coverage, but I think we start to enter the area of diminishing return= s.
>
> As such, I'd like to see us work towards a best practices document= for
> establishing sessions in these restricted environments; I think such a=
> document would be in scope for RTCWEB.
>


You're right, according to the feedback gathered on the draft so = far this looks like a reasonable way to move on. I'm not sure a pure BC= P would be enough, though, considering that too many documented different a= pproaches, no matter how effective each, could eventually lead to a few int= eroperability issues (some browsers/relays may end up implementing some and= not others). Maybe something in line with a BCP that at least mandates a c= ertain sequence of or logic in attempts?

Lorenzo


>
> On Tue, Aug 7, 2012 at 11:54 AM, Lorenzo Miniero <lorenzo@meetecho.com>wrote:
>
> > Hello Ted,
> >
> >
> > On Tue, 7 Aug 2012 10:50:07 -0700
> > Ted Hardie <ted.ietf@gma= il.com> wrote:
> >
> > > On Tue, Aug 7, 2012 at 9:01 AM, Lorenzo Miniero <lorenzo@meetecho.com>
> > wrote:
> > > > That said, I guess there's a different question I s= hould be asking to
> > > > the chairs: since there seems to be no related item in = the milestones,
> > > > is such a work actually in line with what is the expect= ed outcome of
> > the
> > > > WG? Considering the draft basically addresses a new tra= nsport for RTP
> > > > and something that probably needs to be negotiated as w= ell, I guess
> > this
> > > > could be seen as belonging elsewhere (AVTCORE and/or MM= USIC?).
> > > > Nevertheless, my feeling is it belongs more here than s= omewhere else,
> > > > especially considering we're specifying a solution = that will be
> > deployed
> > > > in browsers and, as such, people will expect it to work= wherever other
> > > > web applications do.
> > >
> > > My take on this is that the actual work on developing the al= ternate
> > > transport for RTP would have to occur elsewhere and, frankly= , I think
> > > it is a large enough task that it would likely require its o= wn working
> > > group (much as the RTP congestion control topic ended up as = a BoF and
> > > hopefully will become its own working group). =C2=A0That doe= sn't mean that
> > > the work couldn't be informed by the RTCWEB use cases, b= ut I think it
> > > would have to be done elsewhere.
> > >
> > > I'd personally suggest starting with a discussion with t= he ADs on
> > > whether a BoF on this topic would be something they might co= nsider.
> > > (Note, however, that I have not talked to Cullen about this = and Magnus
> > > is on vacation, so this is not a "Chairs' response&= quot;; just my own
> > > thoughts).
> > >
> >
> >
> > This makes sense. I'm a bit concerned about the additional ti= me that may
> > be needed by going through the process of forming a new WG (compa= red to
> > just adding a milestone to an existing WG, that is), as the final= result
> > may end up being available much after the original WG completed i= ts works,
> > but I see your point.
> >
> > I'll wait for more feedback about this and, if enough people = seem
> > interested about doing something like this, contacting the ADs an= d consider
> > the next steps may be a good idea.
> >
> > Lorenzo
> >
> >
> > > regards,
> > >
> > > Ted Hardie
> >
> >
> > --
> > Lorenzo Miniero, COB
> >
> > Meetecho s.r.l.
> > Web Conferencing and Collaboration Tools
> > http://www.= meetecho.com
> > _______________________________________________
> > rtcweb mailing list
> > rtcweb@ietf.org
> > https://www.ietf.org/mailman/listinfo/rtcweb
> >


--
Lorenzo Miniero, COB

Meetecho s.r.l.
Web Conferencing and Collaboration Tools
http://www.meetecho.c= om

--20cf3074b2d20894ee04c6c5c1da-- From ted.ietf@gmail.com Thu Aug 9 09:24:29 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52CE521F8707 for ; Thu, 9 Aug 2012 09:24:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.056 X-Spam-Level: X-Spam-Status: No, score=-4.056 tagged_above=-999 required=5 tests=[AWL=-0.457, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8fSe6-vpB6XF for ; Thu, 9 Aug 2012 09:24:28 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7CB2D21F86BA for ; Thu, 9 Aug 2012 09:24:28 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so590596vbb.31 for ; Thu, 09 Aug 2012 09:24:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=mt18OnJvZyTwWbXa/3OAwEjBCiqe6vBqO5i8demRrbQ=; b=FMr/sw7egBhjA+L5tuBCH/7CFTLYKrs4nsr22uLUAsHISVMCo3UE6td17Wu6bhAx63 0DDUxCHzqnox+MgrikQESd3DgxLxW1b2bXLkFOmiyEGRxXBI6T0WO3jUyfmlXA/ncrwX BLjCRJaPvwoGru4E4NxN2szTM/JKLI9NxegKHzblGjJHiScYOAlZAzzG+k163MUVnUMl u3gk++Y9Y8keKM6RkgeQwQ7PzaE00hIJpD+4y8ypUbJ78wGCJV3+D9SmzuDjl3Ivfcly XcdyOKDAC6f3zkPBEczmwQuvkwVDML6jlUgfxpyN1kqHvVpMjwoc5bLsenCNjgY8YQ/m o73w== MIME-Version: 1.0 Received: by 10.52.96.135 with SMTP id ds7mr15172094vdb.50.1344529467909; Thu, 09 Aug 2012 09:24:27 -0700 (PDT) Received: by 10.58.55.233 with HTTP; Thu, 9 Aug 2012 09:24:27 -0700 (PDT) Date: Thu, 9 Aug 2012 09:24:27 -0700 Message-ID: From: Ted Hardie To: rtcweb@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [rtcweb] Notes from the sessions requested X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 09 Aug 2012 16:24:29 -0000 Howdy, We'd like to thank Christer and Brian for taking notes for the session. If there are folks who have additional notes from the two sessions which they can share with the chairs or the group, we'd appreciate it; that would help a lot in making more complete minutes. thanks, Ted From albrecht.schwarz@alcatel-lucent.com Mon Aug 13 07:35:26 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 755BB21F8752 for ; Mon, 13 Aug 2012 07:35:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.362 X-Spam-Level: X-Spam-Status: No, score=-7.362 tagged_above=-999 required=5 tests=[AWL=-1.114, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qzf6qlweYWi2 for ; Mon, 13 Aug 2012 07:35:23 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [62.23.212.57]) by ietfa.amsl.com (Postfix) with ESMTP id 464AC21F8766 for ; Mon, 13 Aug 2012 07:35:23 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q7DEMfAD013456 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 13 Aug 2012 16:34:52 +0200 Received: from FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com ([135.120.45.50]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Mon, 13 Aug 2012 16:33:13 +0200 From: "Schwarz, Albrecht (Albrecht)" To: "csp@csperkins.org" , Magnus Westerlund Date: Mon, 13 Aug 2012 16:33:04 +0200 Thread-Topic: editorial nits: draft-ietf-rtcweb-rtp-usage-04 Thread-Index: Ac15YIzDpGcRzNpCR2SBlY2H/Hly3A== Message-ID: <5F7BCCF5541B7444830A2288ABBEBC96218B57F57E@FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-puzzleid: {EB319EBA-A696-4F9D-8612-8917D1F2CB94} x-cr-hashedpuzzle: Bvf5 LAkk L7gp MJfT NeA0 ODIc Swd1 TKmI UZge YboI Ynqg ZogW aqm3 bmV+ cyxB iEou; 3; YwBzAHAAQABjAHMAcABlAHIAawBpAG4AcwAuAG8AcgBnADsAbQBhAGcAbgB1AHMALgB3AGUAcwB0AGUAcgBsAHUAbgBkAEAAZQByAGkAYwBzAHMAbwBuAC4AYwBvAG0AOwByAHQAYwB3AGUAYgBAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {EB319EBA-A696-4F9D-8612-8917D1F2CB94}; YQBsAGIAcgBlAGMAaAB0AC4AcwBjAGgAdwBhAHIAegBAAGEAbABjAGEAdABlAGwALQBsAHUAYwBlAG4AdAAuAGMAbwBtAA==; Mon, 13 Aug 2012 14:33:04 GMT; ZQBkAGkAdABvAHIAaQBhAGwAIABuAGkAdABzADoAIABkAHIAYQBmAHQALQBpAGUAdABmAC0AcgB0AGMAdwBlAGIALQByAHQAcAAtAHUAcwBhAGcAZQAtADAANAA= acceptlanguage: de-DE, en-US Content-Type: multipart/alternative; boundary="_000_5F7BCCF5541B7444830A2288ABBEBC96218B57F57EFRMRSSXCHMBSD_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 Cc: "rtcweb@ietf.org" Subject: [rtcweb] editorial nits: draft-ietf-rtcweb-rtp-usage-04 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 13 Aug 2012 14:35:26 -0000 --_000_5F7BCCF5541B7444830A2288ABBEBC96218B57F57EFRMRSSXCHMBSD_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Colin, Magnus, fyi, some editorial nits, regards, Albrecht Line numbers according http://tools.ietf.org/idnits?url=3Dhttp://tools.ietf.org/id/draft-ietf-rtcw= eb-rtp-usage-04.txt Editorial change proposals: 232 RTP Media Stream: A sequence of RTP packets, and associated RTC= P 233 packets, using a single synchronisation source (SSRC) that =3D> synchronization (according RFC 3550) =3D> ... multiple times in doc 295 participants in the session; support for randomised RTCP =3D> randomized 407 session also effects the possibility for differentiated treatmen= t of =3D> affects 528 implemented using a centralised server, multi-unicast, or using = IP =3D> centralized ... multiple times 588 Request above as there there may be multiple methods to fulfill = the =3D> delete 'there' 694 optimisations of non critical functions, and is hence OPTIONAL t= o =3D> optimizations 715 will support negative acknowlegdements (NACKs) for RTP data pack= ets =3D> acknowledgements 1247 own traffic. While is is clearly considered a bug, it is import= ant =3D> is is 1248 that the end-point is able to recognise and handle the case when= it =3D> recognize 1670 This in an attempt to highlight the differencies and the in many= case =3D> differences 1718 An RTP session have good support for simultanously transport mul= tiple =3D> simultaneously 1723 video cameras can potentially transmitt video from both to its =3D> transmit 1730 Thus we can introduce a couple of different notiations in the be= low =3D> notations 1731 two alternate figures of a single peer connection in a a point t= o =3D> a a 1838 different media bit-rates to the differnt peers, thus not forcin= g B =3D> different 1839 to endure the same quality reductions if there are limiations in= the =3D> limitations 1874 encoder instances each beeing associated with two different =3D> being 1883 resource costrained will use a different implementation strategy =3D> constrained 1918 limited to congestion control, also prefered resolution to recei= ve =3D> preferred 1919 based on dispaly area available is another aspect requiring =3D> display 1920 consideration. The need for this type of descion logic does ari= se in =3D> decision 1949 its operation and form new RTP packets, encrypts and integegrity =3D> integrity 1970 in a media domain mix of the incomming RTP media streams. Then =3D> incoming 1980 produce a Mix of all N streams for the group that are curently n= ot =3D> currently 2046 particpants. As each peer receives a different version produced= by =3D> participants 2070 There exist an possible implementation choice to have the RTP =3D> "a possible" ? 2074 about the contributing sources. This removes both the functiona= lity =3D> functionality 2078 they can be avoide to be resolved and instead remapped between t= he =3D> avoided 2080 requiresthat SSRC/CSRC are never exposed to the WebRTC javascrip= t =3D> space 2185 arguments and conisderations as discussed in Appendix A.3.1.1 ap= plies =3D> considerations 2194 mixer in another RTP session recieves media from that end-point. =3D> receives 2257 sequence number will need to be consequitvely incremented based = on =3D> consequ... ? 2263 handled indepdentently also thus working around any SSRC collisi= ons =3D> independently 2265 related WebRTC MediaStream signalling must be correspondlingly =3D> correspondingly 2272 requests comming from an end-point and decide if it can act on i= t =3D> coming 2327 end-point. For example receving a 2.5 mbps video stream and the= n =3D> receiving 2328 send out a 250 kbps video stream after transcoding is a vaste of =3D> waste 2332 increasing media bit-rate futher than what is needed to represen= t the =3D> further 2368 in the two different PeerConnections that are represtented by ha= ving =3D> represented 2372 likely needed to be soruced by the translator in response to act= ions =3D> sourced 2397 keymanagement. On RTP level the main functions that may be miss= ing =3D> key management 2398 in a legacy implementation that otherswise support RTP are RTCP = in =3D> otherwise 2433 need to change is higly dependent on what functions it need to p= roxy =3D> highly 2451 packet content or media. In fact one of the more likley scenari= o is =3D> likely 2455 encryption and integirty protection operation to resolve missmat= ch in =3D> integrity =3D> mismatch 2464 and the second one which is to to provide a group communication =3D> to to 2480 forwards all the RTP/RTCP traffic and keymanagment to the end-po= int =3D> key management 2551 the client A must be capable of handlilng that when determining =3D> handling 2560 reporting in that case becomes incosistent and without explicit =3D> inconsistent 2634 A relay approache will result in that the WebRTC end-points will= have =3D> approach 2671 to be most easily accomplished by establishing mutliple =3D> multiple --_000_5F7BCCF5541B7444830A2288ABBEBC96218B57F57EFRMRSSXCHMBSD_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Colin, Magnus,
fyi, some editorial nits,
regards,
Albrecht
 
Line numbers according
 
Editorial change proposals:
 
232        RTP Media Stream:  = A sequence of RTP packets, and associated RTCP
  1.       packets, using a single synchronisation = source (SSRC) that
 
  • synchronization (according RFC 3550)
  • … multiple times in = doc
 
295           partic= ipants in the session; support for randomised RTCP
=3D> randomized
 
407        session also effects the= possibility for differentiated treatment of
=3D> affects
 
528        implemented using a cent= ralised server, multi-unicast, or using IP
=3D> centralized
… multiple times
 
588        Request above as there t= here may be multiple methods to fulfill the
=3D> delete ‘there’
 
694        optimisations of non cri= tical functions, and is hence OPTIONAL to
=3D> optimizations
 
715        will support negative ac= knowlegdements (NACKs) for RTP data packets
=3D> acknowledgements
 
1247       own traffic.  While is i= s clearly considered a bug, it is important
=3D> is is
1248       that the end-point is able to= recognise and handle the case when it
=3D> recognize
 
 
1670       This in an attempt to highlig= ht the differencies and the in many case
=3D> differences
 
1718       An RTP session have good supp= ort for simultanously transport multiple
=3D> simultaneously
 
1723       video cameras can potentially= transmitt video from both to its
=3D> transmit
 
1730       Thus we can introduce a coupl= e of different notiations in the below
=3D> notations
 
1731       two alternate figures of a si= ngle peer connection in a a point to
=3D> a a
 
1838       different media bit-rates to = the differnt peers, thus not forcing B
=3D> different
 
1839       to endure the same quality re= ductions if there are limiations in the
=3D> limitations
1874       encoder instances each beeing= associated with two different
=3D> being
 
1883       resource costrained will use = a different implementation strategy
=3D> constrained
 
1918       limited to congestion control= , also prefered resolution to receive
=3D> preferred
 
1919       based on dispaly area availab= le is another aspect requiring
=3D> display
 
1920       consideration.  The need= for this type of descion logic does arise in
=3D> decision
 
1949       its operation and form new RT= P packets, encrypts and integegrity
=3D> integrity
 
1970       in a media domain mix of the = incomming RTP media streams.  Then
=3D> incoming
 
1980       produce a Mix of all N stream= s for the group that are curently not
=3D> currently
 
2046       particpants.  As each pe= er receives a different version produced by
=3D> participants
 
2070       There exist an possible imple= mentation choice to have the RTP
=3D> “a possible” ?
 
2074       about the contributing source= s.  This removes both the functionality
=3D> functionality
 
2078       they can be avoide to be reso= lved and instead remapped between the
=3D> avoided
 
2080       requiresthat SSRC/CSRC are ne= ver exposed to the WebRTC javascript
=3D> space
 
2185       arguments and conisderations = as discussed in Appendix A.3.1.1 applies
=3D> considerations
 
2194       mixer in another RTP session = recieves media from that end-point.
=3D> receives
 
2257       sequence number will need to = be consequitvely incremented based on
=3D> consequ… ?
 
2263       handled indepdentently also t= hus working around any SSRC collisions
=3D> independently
 
2265       related WebRTC MediaStream si= gnalling must be correspondlingly
=3D> correspondingly
 
2272       requests comming from an end-= point and decide if it can act on it
=3D> coming
 
2327       end-point.  For example = receving a 2.5 mbps video stream and then
=3D> receiving
 
2328       send out a 250 kbps video str= eam after transcoding is a vaste of
=3D> waste
 
2332       increasing media bit-rate fut= her than what is needed to represent the
=3D> further
 
2368       in the two different PeerConn= ections that are represtented by having
=3D> represented
 
2372       likely needed to be soruced b= y the translator in response to actions
=3D> sourced
 
2397       keymanagement.  On RTP l= evel the main functions that may be missing
=3D> key management
 
2398       in a legacy implementation th= at otherswise support RTP are RTCP in
=3D> otherwise
 
2433       need to change is higly depen= dent on what functions it need to proxy
=3D> highly
2451       packet content or media. = ; In fact one of the more likley scenario is
=3D> likely
 
2455       encryption and integirty prot= ection operation to resolve missmatch in
=3D> integrity
=3D> mismatch
 
2464       and the second one which is t= o to provide a group communication
=3D> to to
2480       forwards all the RTP/RTCP tra= ffic and keymanagment to the end-point
=3D> key management
 
2551       the client A must be capable = of handlilng that when determining
=3D> handling
 
2560       reporting in that case become= s incosistent and without explicit
=3D> inconsistent
 
2634       A relay approache will result= in that the WebRTC end-points will have
=3D> approach
 
 
2671       to be most easily accomplishe= d by establishing mutliple
=3D> multiple
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 --_000_5F7BCCF5541B7444830A2288ABBEBC96218B57F57EFRMRSSXCHMBSD_-- From mandyam@quicinc.com Wed Aug 15 06:48:27 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 835BB21F88E3 for ; Wed, 15 Aug 2012 06:48:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.612 X-Spam-Level: X-Spam-Status: No, score=-5.612 tagged_above=-999 required=5 tests=[AWL=0.986, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FDnfQNogX9E5 for ; Wed, 15 Aug 2012 06:48:26 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id 4419C21F88E6 for ; Wed, 15 Aug 2012 06:48:18 -0700 (PDT) X-IronPort-AV: E=McAfee;i="5400,1158,6803"; a="223220611" Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by wolverine02.qualcomm.com with ESMTP; 15 Aug 2012 06:48:19 -0700 X-IronPort-AV: E=Sophos;i="4.77,773,1336374000"; d="scan'208,217";a="282511466" Received: from nasanexhc11.na.qualcomm.com ([172.30.39.6]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 15 Aug 2012 06:48:19 -0700 Received: from NASANEXD01H.na.qualcomm.com ([169.254.8.4]) by nasanexhc11.na.qualcomm.com ([172.30.39.6]) with mapi id 14.02.0309.002; Wed, 15 Aug 2012 06:48:18 -0700 From: "Mandyam, Giridhar" To: "rtcweb@ietf.org" Thread-Topic: Qualcomm's Position on Mandatory-to-Implement Audio Codecs for RTCWeb Thread-Index: Ac1wxkUEr1d+Ke5WQFCmnJL9YXz1tQ== Date: Wed, 15 Aug 2012 13:48:17 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.45.230.6] Content-Type: multipart/alternative; boundary="_000_CAC8DBE4E9704C41BCB290C2F3CC921A162A76ABnasanexd01hnaqu_" MIME-Version: 1.0 Subject: [rtcweb] Qualcomm's Position on Mandatory-to-Implement Audio Codecs for RTCWeb X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 15 Aug 2012 13:48:27 -0000 --_000_CAC8DBE4E9704C41BCB290C2F3CC921A162A76ABnasanexd01hnaqu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello All, Qualcomm is in favor of G.711 being the only mandatory-to-implement codec f= or RTCWeb. We do not support having both Opus and G.711 as mandatory-to-im= plement codecs. We state the following reasons: a) There is no technical need to have an audio codec besides G.711 be = designated as mandatory to implement. Because RTCWeb uses SDP to negotiate= the codecs, the only reason to have anything as mandatory is to make sure = there is always at least one codec that both sides can use, a lowest common= denominator. This allows the market to decide which codecs to support, ra= ther than edict from a standards body. Implementations can base their choi= ce of which codec to support based on what they are trying to optimize. Fo= r example, better performance for the environment at the time of the sessio= n, such as cell phone or desktop. b) G.711 is universal, unencumbered, and widely implemented. In add= ition, note that codec implementation and testing is quite costly for chip = and device manufacturers, and that cost is ultimately reflected in the cost= of the end-user device. The computational simplicity of G.711 and its lon= g-time availability on a broad range of platforms means that the implementa= tion is available on low/entry-tier devices and testing costs have already = been amortized over many years, thereby enabling its use in low cost end-us= er devices. If we want to see widespread use of RTCWeb for voice, than we = will reach a much broader population if the minimum requirements do not pro= hibit low-cost devices. c) A mandate for Opus will limit initial RTCWeb clients to use softwa= re-based codecs (on general purpose processors) where Opus can be implemen= ted and tested easily until it is available on a variety of DSPs. Even the= n, it will likely start on high-cost platforms. This may in turn mean that= RTCWeb clients could consume significantly more battery power than DSP-bas= ed codecs used in many traditional (circuit-switched) voice services, furth= er inhibiting the end-user from choosing RTCWeb over those services. d) We do not believe Opus is more versatile than other standardized co= decs, because any measure of versatility should take into account quality a= t a given bitrate. If Opus is not able to deliver superior quality at all = supported bitrates when compared to other codecs, then it cannot be deemed = as being more versatile simply because it supports more bitrates when compa= red to other standardized codecs. In conclusion - the IETF has a strong tradition of starting work with the l= east amount of complexity and specification possible, gaining operational e= xperience, and then refining things with revisions or extensions. So, the = least amount of complexity would be G.711 as the sole audio codec. --_000_CAC8DBE4E9704C41BCB290C2F3CC921A162A76ABnasanexd01hnaqu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello All,

Qualcomm is in favor of G.711 being the only mandato= ry-to-implement codec for RTCWeb.  We do not support having both Opus = and G.711 as mandatory-to-implement codecs.  We state the following re= asons:

 

a)      There is no technical need to have an audio codec b= esides G.711 be designated as mandatory to implement.  Because RTCWeb = uses SDP to negotiate the codecs, the only reason to have anything as manda= tory is to make sure there is always at least one codec that both sides can use, a lowest common denominator.&n= bsp; This allows the market to decide which codecs to support, rather than = edict from a standards body.  Implementations can base their choice of= which codec to support based on what they are trying to optimize.  For example, better performance for the envi= ronment at the time of the session, such as cell phone or desktop.

b)      G.711 is universal, unencumbered, and widely implem= ented.    In addition, note that codec implementation and te= sting is quite costly for chip and device manufacturers, and that cost is u= ltimately reflected in the cost of the end-user device.  The computational simplicity of G.711 and its long-time avai= lability on a broad range of platforms means that the implementation is ava= ilable on low/entry-tier devices and testing costs have already been amorti= zed over many years, thereby enabling its use in low cost end-user devices.  If we want to see widespread u= se of RTCWeb for voice, than we will reach a much broader population if the= minimum requirements do not prohibit low-cost devices. 

c)     &= nbsp; A mandate for Opus will limit initial RTCWeb client= s to use software-based  codecs (on general purpose processors) where = Opus can be implemented and tested easily until it is available on a variet= y of DSPs.  Even then, it will likely start on high-cost platforms.  This may in turn mean that RTCWeb clie= nts could consume significantly more battery power than DSP-based codecs us= ed in many traditional (circuit-switched) voice services, further inhibitin= g the end-user from choosing RTCWeb over those services.

d)      We do not believe Opus is more versatile than other= standardized codecs, because any measure of versatility should take into a= ccount quality at a given bitrate.  If Opus is not able to deliver sup= erior quality at all supported bitrates when compared to other codecs, then it cannot be deemed as being more vers= atile simply because it supports more bitrates when compared to other stand= ardized codecs.

 

In conclusion - the IETF has a strong tradition o= f starting work with the least amount of complexity and specification possi= ble, gaining operational experience, and then refining things with revision= s or extensions.  So, the least amount of complexity would be G.711 as the sole audio codec.

--_000_CAC8DBE4E9704C41BCB290C2F3CC921A162A76ABnasanexd01hnaqu_-- From tim@phonefromhere.com Thu Aug 16 02:41:13 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 118D421F861F for ; Thu, 16 Aug 2012 02:41:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3r3dY36JnA7e for ; Thu, 16 Aug 2012 02:41:12 -0700 (PDT) Received: from zimbra.westhawk.co.uk (zimbra.westhawk.co.uk [192.67.4.167]) by ietfa.amsl.com (Postfix) with ESMTP id 47A1321F84FD for ; Thu, 16 Aug 2012 02:41:08 -0700 (PDT) Received: from [192.67.4.12] (unknown [192.67.4.12]) by zimbra.westhawk.co.uk (Postfix) with ESMTP id BEE2237A905; Thu, 16 Aug 2012 10:49:53 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_D7AAB7AC-70E0-41A8-B4C2-3781AA1F0459" From: Tim Panton In-Reply-To: Date: Thu, 16 Aug 2012 10:40:53 +0100 Message-Id: <00DC1626-33DA-469F-9F06-4D59F2141260@phonefromhere.com> References: To: "Mandyam, Giridhar" X-Mailer: Apple Mail (2.1278) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Qualcomm's Position on Mandatory-to-Implement Audio Codecs for RTCWeb X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 16 Aug 2012 09:41:13 -0000 --Apple-Mail=_D7AAB7AC-70E0-41A8-B4C2-3781AA1F0459 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 15 Aug 2012, at 14:48, Mandyam, Giridhar wrote: > Hello All, > Qualcomm is in favor of G.711 being the only mandatory-to-implement = codec for RTCWeb. We do not support having both Opus and G.711 as = mandatory-to-implement codecs. We state the following reasons: > =20 > a) There is no technical need to have an audio codec besides = G.711 be designated as mandatory to implement. Because RTCWeb uses SDP = to negotiate the codecs, the only reason to have anything as mandatory = is to make sure there is always at least one codec that both sides can = use, a lowest common denominator. This allows the market to decide = which codecs to support, rather than edict from a standards body. = Implementations can base their choice of which codec to support based on = what they are trying to optimize. For example, better performance for = the environment at the time of the session, such as cell phone or = desktop. I made exactly the same argument about H261 and was told (correctly) = that it was unacceptable to mandate a codec that would give users a poorer than necessary experience. I think what applies for video applies = for audio. Specifically g711 is a poor codec choice in a wide variety of network = situations - e.g. 3g and edge of wifi. In my experience a lower = bandwidth codec which supports wideband, dynamically variable bitrates and error = correction / packet loss concealment is required to give these users = audio that is acceptable to use in the coffee-shop / airport scenario.=20 > b) G.711 is universal, unencumbered, and widely implemented. = In addition, note that codec implementation and testing is quite costly = for chip and device manufacturers, and that cost is ultimately reflected = in the cost of the end-user device. The computational simplicity of = G.711 and its long-time availability on a broad range of platforms means = that the implementation is available on low/entry-tier devices and = testing costs have already been amortized over many years, thereby = enabling its use in low cost end-user devices. If we want to see = widespread use of RTCWeb for voice, than we will reach a much broader = population if the minimum requirements do not prohibit low-cost devices.=20= There are many codecs which that can be said for. We happily run speex = on low end smartphones. - Heck we even use the java implementation in applets and get acceptable performance. g722 has recently dropped out of = patent, uses the same bandwidth as 711 and gives significantly better = audio. Any device capable of running SRTP is capable of running either 722 or = speex in my experience.=20 > c) A mandate for Opus will limit initial RTCWeb clients to use = software-based codecs (on general purpose processors) where Opus can be = implemented and tested easily until it is available on a variety of = DSPs. Even then, it will likely start on high-cost platforms. This may = in turn mean that RTCWeb clients could consume significantly more = battery power than DSP-based codecs used in many traditional = (circuit-switched) voice services, further inhibiting the end-user from = choosing RTCWeb over those services. You are confusing mandatory-to-implement and mandatory-to-use. Just = because Opus must be available , you don't have to use it. The devices = you=20 mention almost all have AMR in DSP - but unfortunately that is = encumbered so isn't ideal as a mandatory-to-implememnt codec but may = well be=20 used when it is available.=20 > d) We do not believe Opus is more versatile than other = standardized codecs, because any measure of versatility should take into = account quality at a given bitrate. If Opus is not able to deliver = superior quality at all supported bitrates when compared to other = codecs, then it cannot be deemed as being more versatile simply because = it supports more bitrates when compared to other standardized codecs. Again - making Opus mandatory to implement does not preclude supporting = or using any other codecs.=20 By the way point d) applies to any codec you choose to name - so you are = probably arguing for no mandatory-to-implement codec - which would be a mistake I think. It certainly applies to g711 - in spades! > =20 > In conclusion - the IETF has a strong tradition of starting work with = the least amount of complexity and specification possible, gaining = operational experience, and then refining things with revisions or = extensions. So, the least amount of complexity would be G.711 as the = sole audio codec. RTCweb is never going to be a _least_possible_complexity_ project. The = requirements mean we need SRTP (DTLS?), a video modern codec, Echo = cancellation, AGC, etc. Adding a good audio codec will not significantly = extend the complexity. > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --Apple-Mail=_D7AAB7AC-70E0-41A8-B4C2-3781AA1F0459 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On 15 Aug 2012, at 14:48, Mandyam, = Giridhar wrote:

Hello = All,
Qualcomm is in favor of G.711 being the only = mandatory-to-implement codec for RTCWeb.  We do not support having = both Opus and G.711 as mandatory-to-implement codecs.  We state the = following reasons:
 
a) There is no = technical need to have an audio codec besides G.711 be designated as = mandatory to implement.  Because RTCWeb uses SDP to negotiate the = codecs, the only reason to have anything as mandatory is to make sure = there is always at least one codec that both sides can use, a lowest = common denominator.  This allows the market to decide which codecs = to support, rather than edict from a standards body.  = Implementations can base their choice of which codec to support based on = what they are trying to optimize.  For example, better performance = for the environment at the time of the session, such as cell phone or = desktop.

I made = exactly the same argument about H261 and was told (correctly) that it = was unacceptable to mandate a codec that would give users = a
poorer than necessary experience. I think what applies for = video applies for audio.

Specifically g711 is a = poor codec choice in a wide variety of network situations - e.g. 3g and = edge of wifi. In my experience a lower bandwidth
codec which = supports wideband, dynamically variable bitrates and error = correction / packet loss concealment is required to give these users = audio
that is acceptable to use in the  coffee-shop / = airport scenario. 

b) G.711 is = universal, unencumbered, and widely implemented.    In = addition, note that codec implementation and testing is quite costly for = chip and device manufacturers, and that cost is ultimately reflected in = the cost of the end-user device.  The computational simplicity of = G.711 and its long-time availability on a broad range of platforms means = that the implementation is available on low/entry-tier devices and = testing costs have already been amortized over many years, thereby = enabling its use in low cost end-user devices.  If we want to see = widespread use of RTCWeb for voice, than we will reach a much broader = population if the minimum requirements do not prohibit low-cost = devices. 

Th= ere are many codecs which that can be said for. We happily run speex on = low end smartphones. - Heck we even use the java implementation = in
applets and get acceptable performance. g722 has recently = dropped out of patent, uses the same bandwidth as 711 and gives = significantly better audio.
Any device capable of running SRTP = is capable of running either 722 or speex in my = experience. 


c) A mandate for = Opus will limit initial RTCWeb clients to use software-based  = codecs (on general purpose processors) where Opus can be implemented and = tested easily until it is available on a variety of DSPs.  Even = then, it will likely start on high-cost platforms.  This may in = turn mean that RTCWeb clients could consume significantly more battery = power than DSP-based codecs used in many traditional (circuit-switched) = voice services, further inhibiting the end-user from choosing RTCWeb = over those = services.

You = are confusing mandatory-to-implement and mandatory-to-use. Just because = Opus must be available , you don't have to use it. The devices = you 
mention almost all have AMR in DSP - but = unfortunately that is encumbered so isn't ideal as a = mandatory-to-implememnt codec but may well be 
used when = it is available. 

d) We do not = believe Opus is more versatile than other standardized codecs, because = any measure of versatility should take into account quality at a given = bitrate.  If Opus is not able to deliver superior quality at all = supported bitrates when compared to other codecs, then it cannot be = deemed as being more versatile simply because it supports more bitrates = when compared to other standardized = codecs.


Again - making Opus mandatory to implement does not preclude = supporting or using any other codecs. 

By = the way point d) applies to any codec you choose to name - so you are = probably arguing for no mandatory-to-implement codec - which would = be
a mistake I think. It certainly applies to g711 - in = spades!

 
In conclusion - the = IETF has a strong tradition of starting work with the least amount of = complexity and specification possible, gaining operational experience, = and then refining things with revisions or extensions.  So, the = least amount of complexity would be G.711 as the sole audio = codec.

RTCweb = is never going to be a _least_possible_complexity_ project. The = requirements mean we need  SRTP (DTLS?), a video modern codec, Echo = cancellation, AGC, etc. Adding a good audio codec will not significantly = extend the = complexity.



; Thu, 16 Aug 2012 17:15:44 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.72]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0298.004; Thu, 16 Aug 2012 12:15:43 -0500 From: "Cullen Jennings (fluffy)" To: "rtcweb@ietf.org" Thread-Topic: Confirmation of consensus on audio codecs Thread-Index: AQHNe9LENUMF/Hj3nEmo2lnRJlNz2w== Date: Thu, 16 Aug 2012 17:15:42 +0000 Message-ID: <9E2843EA-EBB9-40B3-898C-6B5216FAE7A5@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.167] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19116.000 x-tm-as-result: No--28.648300-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [rtcweb] Confirmation of consensus on audio codecs X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 16 Aug 2012 17:15:49 -0000 At the last meeting we took a hum on selecting Opus and G.711 as the mediat= ory to implement audio codecs. If there is any new opinions please send the= m to the list by August 30th, after which the chairs will make a determinat= ion of consensus. Thanks, Cullen Please note that the following IPR disclosure have been made on these codec= s. They can be found at=20 http://datatracker.ietf.org/ipr/ 2010-11-07=09 =95 ID # 1445 "Broadcom Corporation's Statement about IPR related to draft-ietf-codec-opu= s-00 and draft-ietf-codec-description-00 (1)" 2010-11-07=09 =95 ID # 1446 "Xiph.Org Foundation's Statement about IPR related to draft-ietf-codec-opus= -00" 2010-11-12=09 =95 ID # 1447 "Broadcom Corporation's Statement about IPR related to draft-ietf-codec-opu= s-00 and draft-ietf-codec-description-00 (2)" 2011-03-23=09 =95 ID # 1520 "Qualcomm Incorporated's Statement about IPR related to draft-ietf-codec-op= us-05" 2011-03-27=09 =95 ID # 1524 "Xiph.Org Foundation's Statement about IPR related to draft-ietf-codec-opus= -05" 2011-03-29=09 =95 ID # 1526 "Broadcom Corporation's Statement about IPR related to draft-ietf-codec-opu= s-05" 2011-03-29=09 =95 ID # 1525 "Skype Limited's Statement about IPR related to draft-ietf-codec-opus-05" 2011-07-23=09 =95 ID # 1602 "Skype Limited's Statement about IPR related to draft-ietf-codec-opus-07" 2012-01-25=09 =95 ID # 1670 "Microsoft Corporation's Statement about IPR related to draft-ietf-codec-op= us-10" 2012-03-12=09 =95 ID # 1712 "Huawei Technologies Co.,Ltd's Statement about IPR related to draft-ietf-co= dec-opus-11 (1)" 2012-04-02=09 =95 ID # 1741 "Huawei Technologies Co.,Ltd's Statement about IPR related to draft-ietf-co= dec-opus-11 (2)" From roman@telurix.com Thu Aug 16 10:35:14 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBCB721F845F for ; Thu, 16 Aug 2012 10:35:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.868 X-Spam-Level: X-Spam-Status: No, score=-2.868 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WXzMgGcWt-6j for ; Thu, 16 Aug 2012 10:35:11 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 763C321F845D for ; Thu, 16 Aug 2012 10:35:10 -0700 (PDT) Received: by qcac10 with SMTP id c10so2616692qca.31 for ; Thu, 16 Aug 2012 10:35:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=zwDTyFA5mDlZkLhpiFl2T6wQg2eIPI/vFq8uSSHQH+o=; b=K3Vkd5WpDlMUKoKapFskP+BV2CFfYYu7+SS7QqVOT7qjC37aOHo63MSl/W2AcvCdbv WKJcYcQ3+GafT6LiRfirpTEuqMQlZZarpnztVd1CYYq5VSXrG6VIsqf5DQHfZVpfBQkm 6X8g3hOIqeQDv1A3eTWU6Kh1vcueksp7CBk9/DGK0N3du23qSjM89JfRg79InYYCr+nP 7XFHEt/5mtg/XqbUwg1yCEIT/5o7vQKAVW2YGubr47JechKgzTl993yMYT1ZDCil2ydc MqeXtCXuns1e5RDgIRqfBBSC+VX5cHiOfCJupjfonizDsgXPmVH3bN2WjdCm2iYBkNIB AWdw== Received: by 10.229.106.130 with SMTP id x2mr1246402qco.121.1345138502934; Thu, 16 Aug 2012 10:35:02 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by mx.google.com with ESMTPS id gp4sm7388280qab.3.2012.08.16.10.35.02 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 16 Aug 2012 10:35:02 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so3030375vbb.31 for ; Thu, 16 Aug 2012 10:35:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.59.0.41 with SMTP id av9mr972328ved.32.1345138501819; Thu, 16 Aug 2012 10:35:01 -0700 (PDT) Received: by 10.58.255.66 with HTTP; Thu, 16 Aug 2012 10:35:01 -0700 (PDT) In-Reply-To: <9E2843EA-EBB9-40B3-898C-6B5216FAE7A5@cisco.com> References: <9E2843EA-EBB9-40B3-898C-6B5216FAE7A5@cisco.com> Date: Thu, 16 Aug 2012 13:35:01 -0400 Message-ID: From: Roman Shpount To: "Cullen Jennings (fluffy)" Content-Type: multipart/alternative; boundary=047d7bdc992c931c6e04c76576cf X-Gm-Message-State: ALoCoQmtqjo0J1swBQTA2mBYqh8DGeTYftT70i3do1Ks97T+lRVgeHDfvNzbHeY5k6DYAB9s0zmi Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Confirmation of consensus on audio codecs X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 16 Aug 2012 17:35:15 -0000 --047d7bdc992c931c6e04c76576cf Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable As I have mentioned before I would like to see G.722 as a mandatory to implement codec in addition to G.711 and OPUS. G.722 is license free and is widely supported. It operates at the same bandwidths as G.711 with virtually the same CPU requirements, but offers HD audio quality superior to G.711. One question I wanted to ask about G.711, do we require any of the appendixes to be implemented, ie would PLC and DTX be required? I think that PLC should be at least recommended, since it will significantly improve resulting communication experience in most of the real deployment scenarios. _____________ Roman Shpount On Thu, Aug 16, 2012 at 1:15 PM, Cullen Jennings (fluffy) wrote: > > At the last meeting we took a hum on selecting Opus and G.711 as the > mediatory to implement audio codecs. If there is any new opinions please > send them to the list by August 30th, after which the chairs will make a > determination of consensus. > > Thanks, > Cullen > > Please note that the following IPR disclosure have been made on these > codecs. They can be found at > > http://datatracker.ietf.org/ipr/ > > > 2010-11-07 > =95 ID # 1445 > "Broadcom Corporation's Statement about IPR related to > draft-ietf-codec-opus-00 and draft-ietf-codec-description-00 (1)" > 2010-11-07 > =95 ID # 1446 > "Xiph.Org Foundation's Statement about IPR related to > draft-ietf-codec-opus-00" > 2010-11-12 > =95 ID # 1447 > "Broadcom Corporation's Statement about IPR related to > draft-ietf-codec-opus-00 and draft-ietf-codec-description-00 (2)" > 2011-03-23 > =95 ID # 1520 > "Qualcomm Incorporated's Statement about IPR related to > draft-ietf-codec-opus-05" > 2011-03-27 > =95 ID # 1524 > "Xiph.Org Foundation's Statement about IPR related to > draft-ietf-codec-opus-05" > 2011-03-29 > =95 ID # 1526 > "Broadcom Corporation's Statement about IPR related to > draft-ietf-codec-opus-05" > 2011-03-29 > =95 ID # 1525 > "Skype Limited's Statement about IPR related to draft-ietf-codec-opus-05" > 2011-07-23 > =95 ID # 1602 > "Skype Limited's Statement about IPR related to draft-ietf-codec-opus-07" > 2012-01-25 > =95 ID # 1670 > "Microsoft Corporation's Statement about IPR related to > draft-ietf-codec-opus-10" > 2012-03-12 > =95 ID # 1712 > "Huawei Technologies Co.,Ltd's Statement about IPR related to > draft-ietf-codec-opus-11 (1)" > 2012-04-02 > =95 ID # 1741 > "Huawei Technologies Co.,Ltd's Statement about IPR related to > draft-ietf-codec-opus-11 (2)" > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --047d7bdc992c931c6e04c76576cf Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable As I have mentioned before I would like to see G.722 as a mandatory to impl= ement codec in addition to G.711 and OPUS. G.722 is license free=A0and is w= idely supported. It operates at the same bandwidths as G.711 with virtually= the same CPU requirements, but offers HD audio quality=A0superior=A0to G.7= 11.

One question I wanted to ask about G.711, do we require any = of the appendixes to be implemented, ie would PLC and DTX be required? I th= ink that PLC should be at least recommended, since it will=A0significantly = improve resulting communication experience in most of the real deployment s= cenarios.=A0
_____________
Roman Shpount


On Thu, Aug 16, 2012 at 1:15 PM, Cullen = Jennings (fluffy) <fluffy@cisco.com> wrote:

At the last meeting we took a hum on selecting Opus and G.711 as the mediat= ory to implement audio codecs. If there is any new opinions please send the= m to the list by August 30th, after which the chairs will make a determinat= ion of consensus.

Thanks,
Cullen

Please note that the following IPR disclosure have been made on these codec= s. They can be found at

http://datat= racker.ietf.org/ipr/


2010-11-07
=95 ID # 1445
"Broadcom Corporation's Statement about IPR related to draft-ietf-= codec-opus-00 and draft-ietf-codec-description-00 (1)"
2010-11-07
=95 ID # 1446
"Xiph.Org Foundation's Statement about IPR related to draft-ietf-c= odec-opus-00"
2010-11-12
=95 ID # 1447
"Broadcom Corporation's Statement about IPR related to draft-ietf-= codec-opus-00 and draft-ietf-codec-description-00 (2)"
2011-03-23
=95 ID # 1520
"Qualcomm Incorporated's Statement about IPR related to draft-ietf= -codec-opus-05"
2011-03-27
=95 ID # 1524
"Xiph.Org Foundation's Statement about IPR related to draft-ietf-c= odec-opus-05"
2011-03-29
=95 ID # 1526
"Broadcom Corporation's Statement about IPR related to draft-ietf-= codec-opus-05"
2011-03-29
=95 ID # 1525
"Skype Limited's Statement about IPR related to draft-ietf-codec-o= pus-05"
2011-07-23
=95 ID # 1602
"Skype Limited's Statement about IPR related to draft-ietf-codec-o= pus-07"
2012-01-25
=95 ID # 1670
"Microsoft Corporation's Statement about IPR related to draft-ietf= -codec-opus-10"
2012-03-12
=95 ID # 1712
"Huawei Technologies Co.,Ltd's Statement about IPR related to draf= t-ietf-codec-opus-11 (1)"
2012-04-02
=95 ID # 1741
"Huawei Technologies Co.,Ltd's Statement about IPR related to draf= t-ietf-codec-opus-11 (2)"



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

--047d7bdc992c931c6e04c76576cf-- From richard@shockey.us Thu Aug 16 16:24:13 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 758FA11E808A for ; Thu, 16 Aug 2012 16:24:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.236 X-Spam-Level: X-Spam-Status: No, score=-101.236 tagged_above=-999 required=5 tests=[AWL=1.029, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9CeJs9LdzPE8 for ; Thu, 16 Aug 2012 16:24:09 -0700 (PDT) Received: from oproxy5-pub.bluehost.com (oproxy5-pub.bluehost.com [67.222.38.55]) by ietfa.amsl.com (Postfix) with SMTP id C2B1621F8484 for ; Thu, 16 Aug 2012 16:24:09 -0700 (PDT) Received: (qmail 31214 invoked by uid 0); 16 Aug 2012 23:23:46 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by cpoproxy2.bluehost.com with SMTP; 16 Aug 2012 23:23:46 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:To:From; bh=NjM6ua1O8Kr3rFIILq/HuGkQMit9LzObTeMBKP+5f9E=; b=Ei9t9BNnIU7L2ghsrCSz+iX/D94RhP9+yBQtwmKJCT5uaLvOupPoLpjts8gu0eGF3+AK/A1nYEBSS9OBDj9uKwgT9i9HD6IbKuP9odSpy45F5ZosMLjtDpRokRIFyY9h; Received: from [71.191.243.130] (port=52869 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1T29Pm-00028q-1B; Thu, 16 Aug 2012 17:23:46 -0600 From: "Richard Shockey" To: "'Cullen Jennings \(fluffy\)'" , References: <9E2843EA-EBB9-40B3-898C-6B5216FAE7A5@cisco.com> In-Reply-To: <9E2843EA-EBB9-40B3-898C-6B5216FAE7A5@cisco.com> Date: Thu, 16 Aug 2012 19:23:43 -0400 Message-ID: <000801cd7c06$2de34710$89a9d530$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHNe9LENUMF/Hj3nEmo2lnRJlNz25ddEQPw Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 71.191.243.130 authed with richard@shockey.us} Subject: Re: [rtcweb] Confirmation of consensus on audio codecs X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 16 Aug 2012 23:24:13 -0000 Reading this list is occasionally an act of torture banned by several conventions ..but since you ask. I completely support the selection of Opus and G.711 as mandatory to implement audio codec's ..however I'm very very open minded about supporting G.722. It has it merits. It should be totally obvious to most that if you even think about interconnecting to public E.164 networks the default option for VoLTE and Enterprise Voice networks is going to be G.722. If it is your goal to create globally useful stove pipes fine, but interconnection with existing carrier real time networks is IMHO a rational goal. As for Video .. for goodness sakes just get over it people. H.264 is totally implemented everywhere on the planet Earth. So what about the intellectual property problems. It's not like VP8 doesn't have problems either. I'll save my comments about the SDP offer/answer issue for another day. -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Cullen Jennings (fluffy) Sent: Thursday, August 16, 2012 1:16 PM To: rtcweb@ietf.org Subject: [rtcweb] Confirmation of consensus on audio codecs At the last meeting we took a hum on selecting Opus and G.711 as the mediatory to implement audio codecs. If there is any new opinions please send them to the list by August 30th, after which the chairs will make a determination of consensus. Thanks, Cullen Please note that the following IPR disclosure have been made on these codecs. They can be found at http://datatracker.ietf.org/ipr/ 2010-11-07 . ID # 1445 "Broadcom Corporation's Statement about IPR related to draft-ietf-codec-opus-00 and draft-ietf-codec-description-00 (1)" 2010-11-07 . ID # 1446 "Xiph.Org Foundation's Statement about IPR related to draft-ietf-codec-opus-00" 2010-11-12 . ID # 1447 "Broadcom Corporation's Statement about IPR related to draft-ietf-codec-opus-00 and draft-ietf-codec-description-00 (2)" 2011-03-23 . ID # 1520 "Qualcomm Incorporated's Statement about IPR related to draft-ietf-codec-opus-05" 2011-03-27 . ID # 1524 "Xiph.Org Foundation's Statement about IPR related to draft-ietf-codec-opus-05" 2011-03-29 . ID # 1526 "Broadcom Corporation's Statement about IPR related to draft-ietf-codec-opus-05" 2011-03-29 . ID # 1525 "Skype Limited's Statement about IPR related to draft-ietf-codec-opus-05" 2011-07-23 . ID # 1602 "Skype Limited's Statement about IPR related to draft-ietf-codec-opus-07" 2012-01-25 . ID # 1670 "Microsoft Corporation's Statement about IPR related to draft-ietf-codec-opus-10" 2012-03-12 . ID # 1712 "Huawei Technologies Co.,Ltd's Statement about IPR related to draft-ietf-codec-opus-11 (1)" 2012-04-02 . ID # 1741 "Huawei Technologies Co.,Ltd's Statement about IPR related to draft-ietf-codec-opus-11 (2)" _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From xiphmont@gmail.com Thu Aug 16 17:11:09 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BD7721F847F for ; Thu, 16 Aug 2012 17:11:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2wmnJOFdCKcG for ; Thu, 16 Aug 2012 17:11:05 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id D3C7421F84D1 for ; Thu, 16 Aug 2012 17:11:04 -0700 (PDT) Received: by eekb45 with SMTP id b45so954525eek.31 for ; Thu, 16 Aug 2012 17:11:04 -0700 (PDT) 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=f/CCLo0yLHO8LLxli1/V/T/dogKQXrlAnn50qCfJiFQ=; b=Ir1wX/W9JA1ZDLMIXaUuAi1zrLhlTGghUosWWQpm7OeeTHGfkcM1unVIYfNw87VseP HpW6aodFHz/44DM5Rm35p6WSvg0fDBUThb/BqYaYZKzYphSxrGs2IIx7Xp8d5xklGdch Q87XCBAKIU9JBcIzIA9q8nLDS5ioK6K2zCfvUe+y+U9MAh1U1Qx9Bco6LdnJTrYITkV2 GXNAozD3aZpEhY+GHFRV4EheEutLr6nK+1U1ezX+g/dzgxcKU/PfxIicnoBvDjPP2Ptd OkyWs8izRE6v8wWGaeiebrb1KH/x1v/eiNYUAitCDaZMvghN6SBTlrvR/Y+n4mlfF0Lu qX/g== MIME-Version: 1.0 Received: by 10.14.202.66 with SMTP id c42mr4042857eeo.35.1345162264085; Thu, 16 Aug 2012 17:11:04 -0700 (PDT) Received: by 10.14.183.136 with HTTP; Thu, 16 Aug 2012 17:11:04 -0700 (PDT) In-Reply-To: <000801cd7c06$2de34710$89a9d530$@us> References: <9E2843EA-EBB9-40B3-898C-6B5216FAE7A5@cisco.com> <000801cd7c06$2de34710$89a9d530$@us> Date: Thu, 16 Aug 2012 20:11:04 -0400 Message-ID: From: Monty Montgomery To: Richard Shockey Content-Type: text/plain; charset=ISO-8859-1 Cc: "Cullen Jennings \(fluffy\)" , rtcweb@ietf.org Subject: Re: [rtcweb] Confirmation of consensus on audio codecs X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 17 Aug 2012 00:11:09 -0000 > It's not like VP8 doesn't have problems either. Actually, no, it doesn't have problems. Monty Xiph.Org From bernard_aboba@hotmail.com Thu Aug 16 17:41:58 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3682121F84F3 for ; Thu, 16 Aug 2012 17:41:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.203 X-Spam-Level: X-Spam-Status: No, score=-101.203 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D3y73hCrAIwd for ; Thu, 16 Aug 2012 17:41:54 -0700 (PDT) Received: from blu0-omc4-s29.blu0.hotmail.com (blu0-omc4-s29.blu0.hotmail.com [65.55.111.168]) by ietfa.amsl.com (Postfix) with ESMTP id 9C7A621F84F2 for ; Thu, 16 Aug 2012 17:41:52 -0700 (PDT) Received: from BLU401-EAS85 ([65.55.111.137]) by blu0-omc4-s29.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 16 Aug 2012 17:41:51 -0700 X-Originating-IP: [166.147.94.9] X-EIP: [3uE+xBWFhcvMf1j20n6iJ0kFfHwGFjq5] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: References: <9E2843EA-EBB9-40B3-898C-6B5216FAE7A5@cisco.com> <000801cd7c06$2de34710$89a9d530$@us> Content-Transfer-Encoding: quoted-printable From: Bernard Aboba Content-Type: text/plain; charset="us-ascii" In-Reply-To: <000801cd7c06$2de34710$89a9d530$@us> Date: Thu, 16 Aug 2012 17:41:50 -0700 To: "rtcweb@ietf.org" MIME-Version: 1.0 (1.0) X-OriginalArrivalTime: 17 Aug 2012 00:41:51.0555 (UTC) FILETIME=[17952130:01CD7C11] Cc: "Cullen Jennings \(fluffy\)" , "rtcweb@ietf.org" Subject: Re: [rtcweb] Confirmation of consensus on audio codecs X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 17 Aug 2012 00:41:58 -0000 I also support the selection of OPUS and G.711 as MTI. G.722 can be a SHOULD= ; it is widely supported. On Aug 16, 2012, at 4:24 PM, "Richard Shockey" wrote: > Reading this list is occasionally an act of torture banned by several > conventions ..but since you ask. >=20 > I completely support the selection of Opus and G.711 as mandatory to > implement audio codec's ..however I'm very very open minded about supporti= ng > G.722. It has it merits. It should be totally obvious to most that if you= > even think about interconnecting to public E.164 networks the default opti= on > for VoLTE and Enterprise Voice networks is going to be G.722.=20 >=20 > If it is your goal to create globally useful stove pipes fine, but > interconnection with existing carrier real time networks is IMHO a rationa= l > goal.=20 >=20 > As for Video .. for goodness sakes just get over it people. H.264 is total= ly > implemented everywhere on the planet Earth. So what about the intellectual= > property problems. It's not like VP8 doesn't have problems either.=20 >=20 > I'll save my comments about the SDP offer/answer issue for another day.=20= >=20 > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf O= f > Cullen Jennings (fluffy) > Sent: Thursday, August 16, 2012 1:16 PM > To: rtcweb@ietf.org > Subject: [rtcweb] Confirmation of consensus on audio codecs >=20 >=20 > At the last meeting we took a hum on selecting Opus and G.711 as the > mediatory to implement audio codecs. If there is any new opinions please > send them to the list by August 30th, after which the chairs will make a > determination of consensus. >=20 > Thanks, > Cullen >=20 > Please note that the following IPR disclosure have been made on these > codecs. They can be found at=20 >=20 > http://datatracker.ietf.org/ipr/ >=20 >=20 > 2010-11-07 =20 > . ID # 1445 > "Broadcom Corporation's Statement about IPR related to > draft-ietf-codec-opus-00 and draft-ietf-codec-description-00 (1)" > 2010-11-07 =20 > . ID # 1446 > "Xiph.Org Foundation's Statement about IPR related to > draft-ietf-codec-opus-00" > 2010-11-12 =20 > . ID # 1447 > "Broadcom Corporation's Statement about IPR related to > draft-ietf-codec-opus-00 and draft-ietf-codec-description-00 (2)" > 2011-03-23 =20 > . ID # 1520 > "Qualcomm Incorporated's Statement about IPR related to > draft-ietf-codec-opus-05" > 2011-03-27 =20 > . ID # 1524 > "Xiph.Org Foundation's Statement about IPR related to > draft-ietf-codec-opus-05" > 2011-03-29 =20 > . ID # 1526 > "Broadcom Corporation's Statement about IPR related to > draft-ietf-codec-opus-05" > 2011-03-29 =20 > . ID # 1525 > "Skype Limited's Statement about IPR related to draft-ietf-codec-opus-05" > 2011-07-23 =20 > . ID # 1602 > "Skype Limited's Statement about IPR related to draft-ietf-codec-opus-07" > 2012-01-25 =20 > . ID # 1670 > "Microsoft Corporation's Statement about IPR related to > draft-ietf-codec-opus-10" > 2012-03-12 =20 > . ID # 1712 > "Huawei Technologies Co.,Ltd's Statement about IPR related to > draft-ietf-codec-opus-11 (1)" > 2012-04-02 =20 > . ID # 1741 > "Huawei Technologies Co.,Ltd's Statement about IPR related to > draft-ietf-codec-opus-11 (2)" >=20 >=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From richard@shockey.us Thu Aug 16 18:39:06 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5EA011E809C for ; Thu, 16 Aug 2012 18:39:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.476 X-Spam-Level: X-Spam-Status: No, score=-101.476 tagged_above=-999 required=5 tests=[AWL=1.123, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SLrjyF2pduKg for ; Thu, 16 Aug 2012 18:39:03 -0700 (PDT) Received: from oproxy12-pub.bluehost.com (oproxy12-pub.bluehost.com [50.87.16.10]) by ietfa.amsl.com (Postfix) with SMTP id 8EBE211E8091 for ; Thu, 16 Aug 2012 18:38:57 -0700 (PDT) Received: (qmail 17936 invoked by uid 0); 17 Aug 2012 01:38:36 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy12.bluehost.com with SMTP; 17 Aug 2012 01:38:36 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:To:From; bh=Ayqpia9OcQYcXK921JDcj2/U8XrRjhuoZy4DS56N+5Q=; b=fcnesQp346lVe6yFSHkET8opa+t7TXWDK8pLtBQb9jeyhu5KoJ9A/hPUtQ2lUAjA0VjOG9bs0RI2bUGG/jOAYdFK3js0VmGWc1LV54Y/i4NBtOK0mIwRKMbTSjK/g3PR; Received: from [71.191.243.130] (port=56884 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1T2BWF-0003Bc-Iq; Thu, 16 Aug 2012 19:38:35 -0600 From: "Richard Shockey" To: "'Monty Montgomery'" , References: <9E2843EA-EBB9-40B3-898C-6B5216FAE7A5@cisco.com> <000801cd7c06$2de34710$89a9d530$@us> In-Reply-To: Date: Thu, 16 Aug 2012 21:38:32 -0400 Message-ID: <001901cd7c19$03abf4c0$0b03de40$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac18DMuLQ6xnrfSGQva7QmcN187kYQADAq4g Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 71.191.243.130 authed with richard@shockey.us} Subject: Re: [rtcweb] Confirmation of consensus on audio codecs X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 17 Aug 2012 01:39:06 -0000 SOOO WRONG .. just do a simple search. It just hasn't been fully litigated ...yet. -----Original Message----- From: Monty Montgomery [mailto:xiphmont@gmail.com] Sent: Thursday, August 16, 2012 8:11 PM To: Richard Shockey Cc: Cullen Jennings (fluffy); rtcweb@ietf.org Subject: Re: [rtcweb] Confirmation of consensus on audio codecs > It's not like VP8 doesn't have problems either. Actually, no, it doesn't have problems. Monty Xiph.Org From richard@shockey.us Thu Aug 16 18:40:59 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9621A11E80BA for ; Thu, 16 Aug 2012 18:40:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.384 X-Spam-Level: X-Spam-Status: No, score=-101.384 tagged_above=-999 required=5 tests=[AWL=0.881, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cIoX6HDUgVka for ; Thu, 16 Aug 2012 18:40:59 -0700 (PDT) Received: from oproxy8-pub.bluehost.com (oproxy8-pub.bluehost.com [69.89.22.20]) by ietfa.amsl.com (Postfix) with SMTP id 2522911E80D1 for ; Thu, 16 Aug 2012 18:40:59 -0700 (PDT) Received: (qmail 18361 invoked by uid 0); 17 Aug 2012 01:40:37 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy8.bluehost.com with SMTP; 17 Aug 2012 01:40:37 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From; bh=NBCAVpboQqmR3P6YmoWa32CHXn4ywQ32LwUgOh800Ro=; b=fBJiu0fGUIr6ZJN/XiiyL9ySIPcQj91jNTn3y4oq+NtD6g28BLiYe/JsAjqXYoFeH99KGqZ+nlDE3EdIhnlbREkPPVLN0wQfh2Ocw/aEmcP/Fa0Zl5rFHtMmf4U306AM; Received: from [71.191.243.130] (port=56945 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1T2BYD-0004E8-2a; Thu, 16 Aug 2012 19:40:37 -0600 From: "Richard Shockey" To: "'Bernard Aboba'" , References: <9E2843EA-EBB9-40B3-898C-6B5216FAE7A5@cisco.com> <000801cd7c06$2de34710$89a9d530$@us> In-Reply-To: Date: Thu, 16 Aug 2012 21:40:34 -0400 Message-ID: <001a01cd7c19$4c0d9e80$e428db80$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac18ERyduxwsxnBpR/a9QkRlaXolkgACB/sA Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 71.191.243.130 authed with richard@shockey.us} Cc: "'Cullen Jennings \(fluffy\)'" , rtcweb@ietf.org Subject: Re: [rtcweb] Confirmation of consensus on audio codecs X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 17 Aug 2012 01:40:59 -0000 -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Bernard Aboba Sent: Thursday, August 16, 2012 8:42 PM To: rtcweb@ietf.org Cc: Cullen Jennings (fluffy); rtcweb@ietf.org Subject: Re: [rtcweb] Confirmation of consensus on audio codecs I also support the selection of OPUS and G.711 as MTI. G.722 can be a SHOULD; it is widely supported. [RS> ] +1 From xiphmont@gmail.com Thu Aug 16 19:38:59 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC8EB21F84D4 for ; Thu, 16 Aug 2012 19:38:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ELa72tnJ6int for ; Thu, 16 Aug 2012 19:38:55 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2287C21F84B6 for ; Thu, 16 Aug 2012 19:38:54 -0700 (PDT) Received: by eekb45 with SMTP id b45so968902eek.31 for ; Thu, 16 Aug 2012 19:38:53 -0700 (PDT) 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=OdoO74i/mkC8Tb24A6HYx50X2F2TfImpE/D3PpJEh/c=; b=ACVk9pLpr+GxtswhBF9ZYmosRFVdnfU97xxTj3vJbPAZSC5gm5y3HGuaISW+kIz3yW 6PHm53CP0up2FVI0ezuZi+RcXgGHU8eSBhllCPtfQJTNj3EVL6htvj4+N5Z96tbCCc7A WHGJI79izN2c/ky43nvNo5f/CuC2Ab6DMSB0puInu0Ak+vWvq2kL3rYkT5Kv0QAK7GUR XVW9J93Nlj41mqkGpDdOZHYjwLoci3GCjXOAYgJ+riqtsVkxdGYhQySMWjs8MIEL3ptM i4+dug1fFKclhiqLh34sBZmQX2Koo4J1EqBDhg4evfbPBjbq5h55L3eOTR7GAxpwoUqo HfUA== MIME-Version: 1.0 Received: by 10.14.204.72 with SMTP id g48mr4392385eeo.45.1345171133815; Thu, 16 Aug 2012 19:38:53 -0700 (PDT) Received: by 10.14.183.136 with HTTP; Thu, 16 Aug 2012 19:38:53 -0700 (PDT) In-Reply-To: <001901cd7c19$03abf4c0$0b03de40$@us> References: <9E2843EA-EBB9-40B3-898C-6B5216FAE7A5@cisco.com> <000801cd7c06$2de34710$89a9d530$@us> <001901cd7c19$03abf4c0$0b03de40$@us> Date: Thu, 16 Aug 2012 22:38:53 -0400 Message-ID: From: Monty Montgomery To: Richard Shockey Content-Type: text/plain; charset=ISO-8859-1 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Confirmation of consensus on audio codecs X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 17 Aug 2012 02:38:59 -0000 On Thu, Aug 16, 2012 at 9:38 PM, Richard Shockey wrote: > SOOO WRONG .. just do a simple search. It just hasn't been fully litigated > ...yet. It hasn't been litigated at all. Or even credibly threatened beyond the same substanceless mouthing off in to press we saw with Vorbis, Theora, etc... Monty Xiph.Org From lorenzo@meetecho.com Fri Aug 17 00:52:54 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA15721F8569 for ; Fri, 17 Aug 2012 00:52:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.675 X-Spam-Level: X-Spam-Status: No, score=-0.675 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id itfFyADWG-dy for ; Fri, 17 Aug 2012 00:52:50 -0700 (PDT) Received: from smtplq02.aruba.it (smtplq-out6.aruba.it [62.149.158.26]) by ietfa.amsl.com (Postfix) with SMTP id 65D6221F8564 for ; Fri, 17 Aug 2012 00:52:50 -0700 (PDT) Received: (qmail 24044 invoked by uid 89); 17 Aug 2012 07:52:47 -0000 Received: from unknown (HELO smtp4.aruba.it) (62.149.158.224) by smtplq02.aruba.it with SMTP; 17 Aug 2012 07:52:47 -0000 Received: (qmail 32466 invoked by uid 89); 17 Aug 2012 07:52:47 -0000 Received: from unknown (HELO localhost) (lorenzo@meetecho.com@80.187.201.11) by smtp4.ad.aruba.it with SMTP; 17 Aug 2012 07:52:47 -0000 Date: Fri, 17 Aug 2012 07:12:50 +0300 Message-ID: <2ipmq6k3bq9kogc9deirbhf8.1345176770806@email.android.com> From: Lorenzo Miniero To: Bernard Aboba , "rtcweb@ietf.org" MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 X-Spam-Rating: smtp4.ad.aruba.it 1.6.2 0/1000/N X-Spam-Rating: smtplq02.aruba.it 1.6.2 0/1000/N Cc: "Cullen Jennings \(fluffy\)" Subject: Re: [rtcweb] Confirmation of consensus on audio codecs X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 17 Aug 2012 07:52:55 -0000 KzEgb24gdGhpcy4KCkxvcmVuem8KCkJlcm5hcmQgQWJvYmEgPGJlcm5hcmRfYWJvYmFAaG90bWFp bC5jb20+IGhhIHNjcml0dG86Cgo+SSBhbHNvIHN1cHBvcnQgdGhlIHNlbGVjdGlvbiBvZiBPUFVT IGFuZCBHLjcxMSBhcyBNVEkuIEcuNzIyIGNhbiBiZSBhIFNIT1VMRDsgaXQgaXMgd2lkZWx5IHN1 cHBvcnRlZC4KPgo+Cj4KPk9uIEF1ZyAxNiwgMjAxMiwgYXQgNDoyNCBQTSwgIlJpY2hhcmQgU2hv Y2tleSIgPHJpY2hhcmRAc2hvY2tleS51cz4gd3JvdGU6Cj4KPj4gUmVhZGluZyB0aGlzIGxpc3Qg aXMgb2NjYXNpb25hbGx5IGFuIGFjdCBvZiB0b3J0dXJlIGJhbm5lZCBieSBzZXZlcmFsCj4+IGNv bnZlbnRpb25zIC4uYnV0IHNpbmNlIHlvdSBhc2suCj4+IAo+PiBJIGNvbXBsZXRlbHkgc3VwcG9y dCB0aGUgc2VsZWN0aW9uIG9mIE9wdXMgYW5kIEcuNzExIGFzIG1hbmRhdG9yeSB0bwo+PiBpbXBs ZW1lbnQgYXVkaW8gY29kZWMncyAuLmhvd2V2ZXIgSSdtIHZlcnkgdmVyeSBvcGVuIG1pbmRlZCBh Ym91dCBzdXBwb3J0aW5nCj4+IEcuNzIyLiBJdCBoYXMgaXQgbWVyaXRzLiAgSXQgc2hvdWxkIGJl IHRvdGFsbHkgb2J2aW91cyB0byBtb3N0IHRoYXQgaWYgeW91Cj4+IGV2ZW4gdGhpbmsgYWJvdXQg aW50ZXJjb25uZWN0aW5nIHRvIHB1YmxpYyBFLjE2NCBuZXR3b3JrcyB0aGUgZGVmYXVsdCBvcHRp b24KPj4gZm9yIFZvTFRFIGFuZCBFbnRlcnByaXNlIFZvaWNlIG5ldHdvcmtzIGlzIGdvaW5nIHRv IGJlIEcuNzIyLiAKPj4gCj4+IElmIGl0IGlzIHlvdXIgZ29hbCB0byBjcmVhdGUgZ2xvYmFsbHkg dXNlZnVsIHN0b3ZlIHBpcGVzIGZpbmUsICBidXQKPj4gaW50ZXJjb25uZWN0aW9uIHdpdGggZXhp c3RpbmcgY2FycmllciByZWFsIHRpbWUgbmV0d29ya3MgaXMgSU1ITyBhIHJhdGlvbmFsCj4+IGdv YWwuIAo+PiAKPj4gQXMgZm9yIFZpZGVvIC4uIGZvciBnb29kbmVzcyBzYWtlcyBqdXN0IGdldCBv dmVyIGl0IHBlb3BsZS4gSC4yNjQgaXMgdG90YWxseQo+PiBpbXBsZW1lbnRlZCBldmVyeXdoZXJl IG9uIHRoZSBwbGFuZXQgRWFydGguIFNvIHdoYXQgYWJvdXQgdGhlIGludGVsbGVjdHVhbAo+PiBw cm9wZXJ0eSBwcm9ibGVtcy4gSXQncyBub3QgbGlrZSBWUDggZG9lc24ndCBoYXZlIHByb2JsZW1z IGVpdGhlci4gCj4+IAo+PiBJJ2xsIHNhdmUgbXkgY29tbWVudHMgYWJvdXQgdGhlIFNEUCBvZmZl ci9hbnN3ZXIgaXNzdWUgZm9yIGFub3RoZXIgZGF5LiAKPj4gCj4+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tCj4+IEZyb206IHJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86cnRjd2Vi LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZgo+PiBDdWxsZW4gSmVubmluZ3MgKGZsdWZm eSkKPj4gU2VudDogVGh1cnNkYXksIEF1Z3VzdCAxNiwgMjAxMiAxOjE2IFBNCj4+IFRvOiBydGN3 ZWJAaWV0Zi5vcmcKPj4gU3ViamVjdDogW3J0Y3dlYl0gQ29uZmlybWF0aW9uIG9mIGNvbnNlbnN1 cyBvbiBhdWRpbyBjb2RlY3MKPj4gCj4+IAo+PiBBdCB0aGUgbGFzdCBtZWV0aW5nIHdlIHRvb2sg YSBodW0gb24gc2VsZWN0aW5nIE9wdXMgYW5kIEcuNzExIGFzIHRoZQo+PiBtZWRpYXRvcnkgdG8g aW1wbGVtZW50IGF1ZGlvIGNvZGVjcy4gSWYgdGhlcmUgaXMgYW55IG5ldyBvcGluaW9ucyBwbGVh c2UKPj4gc2VuZCB0aGVtIHRvIHRoZSBsaXN0IGJ5IEF1Z3VzdCAzMHRoLCBhZnRlciB3aGljaCB0 aGUgY2hhaXJzIHdpbGwgbWFrZSBhCj4+IGRldGVybWluYXRpb24gb2YgY29uc2Vuc3VzLgo+PiAK Pj4gVGhhbmtzLAo+PiBDdWxsZW4KPj4gCj4+IFBsZWFzZSBub3RlIHRoYXQgdGhlIGZvbGxvd2lu ZyBJUFIgZGlzY2xvc3VyZSBoYXZlIGJlZW4gbWFkZSBvbiB0aGVzZQo+PiBjb2RlY3MuIFRoZXkg Y2FuIGJlIGZvdW5kIGF0IAo+PiAKPj4gaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2lwci8K Pj4gCj4+IAo+PiAyMDEwLTExLTA3ICAgIAo+PiAuIElEICMgMTQ0NQo+PiAiQnJvYWRjb20gQ29y cG9yYXRpb24ncyBTdGF0ZW1lbnQgYWJvdXQgSVBSIHJlbGF0ZWQgdG8KPj4gZHJhZnQtaWV0Zi1j b2RlYy1vcHVzLTAwIGFuZCBkcmFmdC1pZXRmLWNvZGVjLWRlc2NyaXB0aW9uLTAwICgxKSIKPj4g MjAxMC0xMS0wNyAgICAKPj4gLiBJRCAjIDE0NDYKPj4gIlhpcGguT3JnIEZvdW5kYXRpb24ncyBT dGF0ZW1lbnQgYWJvdXQgSVBSIHJlbGF0ZWQgdG8KPj4gZHJhZnQtaWV0Zi1jb2RlYy1vcHVzLTAw Igo+PiAyMDEwLTExLTEyICAgIAo+PiAuIElEICMgMTQ0Nwo+PiAiQnJvYWRjb20gQ29ycG9yYXRp b24ncyBTdGF0ZW1lbnQgYWJvdXQgSVBSIHJlbGF0ZWQgdG8KPj4gZHJhZnQtaWV0Zi1jb2RlYy1v cHVzLTAwIGFuZCBkcmFmdC1pZXRmLWNvZGVjLWRlc2NyaXB0aW9uLTAwICgyKSIKPj4gMjAxMS0w My0yMyAgICAKPj4gLiBJRCAjIDE1MjAKPj4gIlF1YWxjb21tIEluY29ycG9yYXRlZCdzIFN0YXRl bWVudCBhYm91dCBJUFIgcmVsYXRlZCB0bwo+PiBkcmFmdC1pZXRmLWNvZGVjLW9wdXMtMDUiCj4+ IDIwMTEtMDMtMjcgICAgCj4+IC4gSUQgIyAxNTI0Cj4+ICJYaXBoLk9yZyBGb3VuZGF0aW9uJ3Mg U3RhdGVtZW50IGFib3V0IElQUiByZWxhdGVkIHRvCj4+IGRyYWZ0LWlldGYtY29kZWMtb3B1cy0w NSIKPj4gMjAxMS0wMy0yOSAgICAKPj4gLiBJRCAjIDE1MjYKPj4gIkJyb2FkY29tIENvcnBvcmF0 aW9uJ3MgU3RhdGVtZW50IGFib3V0IElQUiByZWxhdGVkIHRvCj4+IGRyYWZ0LWlldGYtY29kZWMt b3B1cy0wNSIKPj4gMjAxMS0wMy0yOSAgICAKPj4gLiBJRCAjIDE1MjUKPj4gIlNreXBlIExpbWl0 ZWQncyBTdGF0ZW1lbnQgYWJvdXQgSVBSIHJlbGF0ZWQgdG8gZHJhZnQtaWV0Zi1jb2RlYy1vcHVz LTA1Igo+PiAyMDExLTA3LTIzICAgIAo+PiAuIElEICMgMTYwMgo+PiAiU2t5cGUgTGltaXRlZCdz IFN0YXRlbWVudCBhYm91dCBJUFIgcmVsYXRlZCB0byBkcmFmdC1pZXRmLWNvZGVjLW9wdXMtMDci Cj4+IDIwMTItMDEtMjUgICAgCj4+IC4gSUQgIyAxNjcwCj4+ICJNaWNyb3NvZnQgQ29ycG9yYXRp b24ncyBTdGF0ZW1lbnQgYWJvdXQgSVBSIHJlbGF0ZWQgdG8KPj4gZHJhZnQtaWV0Zi1jb2RlYy1v cHVzLTEwIgo+PiAyMDEyLTAzLTEyICAgIAo+PiAuIElEICMgMTcxMgo+PiAiSHVhd2VpIFRlY2hu b2xvZ2llcyBDby4sTHRkJ3MgU3RhdGVtZW50IGFib3V0IElQUiByZWxhdGVkIHRvCj4+IGRyYWZ0 LWlldGYtY29kZWMtb3B1cy0xMSAoMSkiCj4+IDIwMTItMDQtMDIgICAgCj4+IC4gSUQgIyAxNzQx Cj4+ICJIdWF3ZWkgVGVjaG5vbG9naWVzIENvLixMdGQncyBTdGF0ZW1lbnQgYWJvdXQgSVBSIHJl bGF0ZWQgdG8KPj4gZHJhZnQtaWV0Zi1jb2RlYy1vcHVzLTExICgyKSIKPj4gCj4+IAo+PiAKPj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPj4gcnRjd2Vi IG1haWxpbmcgbGlzdAo+PiBydGN3ZWJAaWV0Zi5vcmcKPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9ydGN3ZWIKPj4gCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fCj4+IHJ0Y3dlYiBtYWlsaW5nIGxpc3QKPj4gcnRjd2ViQGll dGYub3JnCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViCj5f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+cnRjd2ViIG1h aWxpbmcgbGlzdAo+cnRjd2ViQGlldGYub3JnCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3J0Y3dlYgo= From matthew.kaufman@skype.net Fri Aug 17 09:30:52 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD17D11E80A5 for ; Fri, 17 Aug 2012 09:30:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.949 X-Spam-Level: X-Spam-Status: No, score=-4.949 tagged_above=-999 required=5 tests=[AWL=1.650, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N88RDzf5ypGn for ; Fri, 17 Aug 2012 09:30:52 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe002.messaging.microsoft.com [65.55.88.12]) by ietfa.amsl.com (Postfix) with ESMTP id 24C5321F845A for ; Fri, 17 Aug 2012 09:30:51 -0700 (PDT) Received: from mail125-tx2-R.bigfish.com (10.9.14.249) by TX2EHSOBE008.bigfish.com (10.9.40.28) with Microsoft SMTP Server id 14.1.225.23; Fri, 17 Aug 2012 16:30:51 +0000 Received: from mail125-tx2 (localhost [127.0.0.1]) by mail125-tx2-R.bigfish.com (Postfix) with ESMTP id 75F144200B9; Fri, 17 Aug 2012 16:30:51 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC107.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -26 X-BigFish: VS-26(zz9371I542Mzz1202hzz1033IL8275dhz2fh2a8h668h839h944hd25hf0ah107ah) Received-SPF: pass (mail125-tx2: domain of skype.net designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=matthew.kaufman@skype.net; helo=TK5EX14HUBC107.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail125-tx2 (localhost.localdomain [127.0.0.1]) by mail125-tx2 (MessageSwitch) id 1345221048834487_7929; Fri, 17 Aug 2012 16:30:48 +0000 (UTC) Received: from TX2EHSMHS011.bigfish.com (unknown [10.9.14.252]) by mail125-tx2.bigfish.com (Postfix) with ESMTP id C9078460103; Fri, 17 Aug 2012 16:30:48 +0000 (UTC) Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (131.107.125.8) by TX2EHSMHS011.bigfish.com (10.9.99.111) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 17 Aug 2012 16:30:48 +0000 Received: from TK5EX14MBXC272.redmond.corp.microsoft.com ([169.254.2.89]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.02.0309.003; Fri, 17 Aug 2012 16:30:46 +0000 From: Matthew Kaufman To: Bernard Aboba , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Confirmation of consensus on audio codecs Thread-Index: AQHNe9LENUMF/Hj3nEmo2lnRJlNz25ddEQPwgAAZhACAAQfEoA== Date: Fri, 17 Aug 2012 16:30:46 +0000 Message-ID: References: <9E2843EA-EBB9-40B3-898C-6B5216FAE7A5@cisco.com> <000801cd7c06$2de34710$89a9d530$@us> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.33] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: skype.net Cc: "Cullen Jennings \(fluffy\)" , "rtcweb@ietf.org" Subject: Re: [rtcweb] Confirmation of consensus on audio codecs X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 17 Aug 2012 16:30:52 -0000 I agree. OPUS because it will be the IETF standard for wideband audio on th= e Internet, G.711 for maximum interoperability. G.722 is a reasonable thing= to put on the "SHOULD" list... there's some other good choices for the SHO= ULD list, but they unfortunately come with additional IPR issues. Matthew Kaufman -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= Bernard Aboba Sent: Thursday, August 16, 2012 5:42 PM To: rtcweb@ietf.org Cc: Cullen Jennings (fluffy); rtcweb@ietf.org Subject: Re: [rtcweb] Confirmation of consensus on audio codecs I also support the selection of OPUS and G.711 as MTI. G.722 can be a SHOUL= D; it is widely supported. From jdrosen@jdrosen.net Fri Aug 17 10:02:26 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3C8321F8496 for ; Fri, 17 Aug 2012 10:02:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.643 X-Spam-Level: X-Spam-Status: No, score=-101.643 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5JorEZ1kqIeM for ; Fri, 17 Aug 2012 10:02:26 -0700 (PDT) Received: from ecbiz71.inmotionhosting.com (ecbiz71.inmotionhosting.com [69.174.114.155]) by ietfa.amsl.com (Postfix) with ESMTP id 0EE0921F8450 for ; Fri, 17 Aug 2012 10:02:26 -0700 (PDT) Received: from mail-we0-f172.google.com ([74.125.82.172]:49072) by ecbiz71.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.77) (envelope-from ) id 1T2PwH-0000tk-5G for rtcweb@ietf.org; Fri, 17 Aug 2012 13:02:25 -0400 Received: by weyu54 with SMTP id u54so2981366wey.31 for ; Fri, 17 Aug 2012 10:02:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.181.67 with SMTP id k45mr2666351wem.17.1345222944527; Fri, 17 Aug 2012 10:02:24 -0700 (PDT) Received: by 10.227.2.77 with HTTP; Fri, 17 Aug 2012 10:02:24 -0700 (PDT) In-Reply-To: References: <9E2843EA-EBB9-40B3-898C-6B5216FAE7A5@cisco.com> <000801cd7c06$2de34710$89a9d530$@us> Date: Fri, 17 Aug 2012 13:02:24 -0400 Message-ID: From: Jonathan Rosenberg To: Matthew Kaufman Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ecbiz71.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jdrosen.net X-Source: X-Source-Args: X-Source-Dir: Cc: "Cullen Jennings \(fluffy\)" , "rtcweb@ietf.org" Subject: Re: [rtcweb] Confirmation of consensus on audio codecs X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 17 Aug 2012 17:02:26 -0000 I'll chime in here too - it'll surprise no one that I agree Opus should be MTI. I agree on G.711 as well, as this has realistically been the lingua franca for voip since the very beginning. Its easy to put in, no IPR and will help with the many interop scenarios which the market will eventually want. Even if intermediaries are needed on the media path for other things - like ICE interop - at least we won't need transcode. -Jonathan R. On Fri, Aug 17, 2012 at 12:30 PM, Matthew Kaufman wrote: > I agree. OPUS because it will be the IETF standard for wideband audio on = the Internet, G.711 for maximum interoperability. G.722 is a reasonable thi= ng to put on the "SHOULD" list... there's some other good choices for the S= HOULD list, but they unfortunately come with additional IPR issues. > > Matthew Kaufman > > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf = Of Bernard Aboba > Sent: Thursday, August 16, 2012 5:42 PM > To: rtcweb@ietf.org > Cc: Cullen Jennings (fluffy); rtcweb@ietf.org > Subject: Re: [rtcweb] Confirmation of consensus on audio codecs > > I also support the selection of OPUS and G.711 as MTI. G.722 can be a SHO= ULD; it is widely supported. > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --=20 Jonathan Rosenberg, Ph.D. GM Product Strategy and Research, Microsoft/Skype jdrosen@{skype.net,jdrosen.net,microsoft.com} http://www.jdrosen.net From ietf@kenfischer.net Fri Aug 17 10:47:00 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ED6011E809B for ; Fri, 17 Aug 2012 10:47:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ApBWdqG3-gFn for ; Fri, 17 Aug 2012 10:46:59 -0700 (PDT) Received: from homiemail-a33.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by ietfa.amsl.com (Postfix) with ESMTP id B849311E80D1 for ; Fri, 17 Aug 2012 10:46:59 -0700 (PDT) Received: from homiemail-a33.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTP id 5D83F594069; Fri, 17 Aug 2012 10:46:59 -0700 (PDT) Received: from [192.168.123.108] (c-67-172-143-206.hsd1.co.comcast.net [67.172.143.206]) (Authenticated sender: ietf@kenfischer.net) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTPA id BA85759405E; Fri, 17 Aug 2012 10:46:58 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.10.0.110310 Date: Fri, 17 Aug 2012 11:46:56 -0600 From: Ken Fischer Sender: Ken Fischer To: Matthew Kaufman , "rtcweb@ietf.org" Message-ID: Thread-Topic: [rtcweb] Confirmation of consensus on audio codecs In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [rtcweb] Confirmation of consensus on audio codecs X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 17 Aug 2012 17:47:00 -0000 +1 on Matthew's recommendation. I agree that .722 should be on the SHOULD list, but honestly I think most people who implement beyond the MUST will add what ever they like, and what ever they have access to, and so the ultimate impact of the SHOULDs has always been questionable to me. Ken On 8/17/12 10:30 AM, "Matthew Kaufman" wrote: >I agree. OPUS because it will be the IETF standard for wideband audio on >the Internet, G.711 for maximum interoperability. G.722 is a reasonable >thing to put on the "SHOULD" list... there's some other good choices for >the SHOULD list, but they unfortunately come with additional IPR issues. > >Matthew Kaufman > >-----Original Message----- >From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf >Of Bernard Aboba >Sent: Thursday, August 16, 2012 5:42 PM >To: rtcweb@ietf.org >Cc: Cullen Jennings (fluffy); rtcweb@ietf.org >Subject: Re: [rtcweb] Confirmation of consensus on audio codecs > >I also support the selection of OPUS and G.711 as MTI. G.722 can be a >SHOULD; it is widely supported. > > > >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb From tim@phonefromhere.com Fri Aug 17 12:34:50 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56A2721F845B for ; Fri, 17 Aug 2012 12:34:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tloUxTMn+B2f for ; Fri, 17 Aug 2012 12:34:49 -0700 (PDT) Received: from zimbra.westhawk.co.uk (zimbra.westhawk.co.uk [192.67.4.167]) by ietfa.amsl.com (Postfix) with ESMTP id 925D621F8452 for ; Fri, 17 Aug 2012 12:34:49 -0700 (PDT) Received: from [10.47.160.214] (unknown [212.183.132.59]) by zimbra.westhawk.co.uk (Postfix) with ESMTP id D632637A905; Fri, 17 Aug 2012 20:43:41 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Tim Panton In-Reply-To: <50228C5F.8010403@alvestrand.no> Date: Fri, 17 Aug 2012 20:22:42 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <5561F28B-9BE5-424B-8898-1144BACF51F8@phonefromhere.com> References: <81579634-CC55-46FF-8C3B-94EB5019786A@phonefromhere.com> <50228C5F.8010403@alvestrand.no> To: Harald Alvestrand X-Mailer: Apple Mail (2.1278) Cc: Alexey Aylarov , "Cullen Jennings \(fluffy\)" , "rtcweb@ietf.org" , "public-webrtc@w3.org" Subject: Re: [rtcweb] Microsoft tells W3C and IETF what we are doing no signs of offering real world interoperability X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 17 Aug 2012 19:34:50 -0000 Harald, I see from reviewing the archives that my reply to this didn't = go in for some reason, so I just want to put on the record that you are (of course) right. = There was no specific proposal to action, so there was nothing for the chairs to ignore. The point I failed to make politely was that many of us knew informally = that Skype/MS were not=20 happy with the situation, so a document like this should not have been = unexpected. My apologies for my rudeness. Tim. On 8 Aug 2012, at 16:57, Harald Alvestrand wrote: > On 08/07/2012 11:57 AM, Tim Panton wrote: >> Ok, the timing is unfortunate, but can you honestly say that we = didn't know that this was skype/microsofts opinion? We just chose to = ignore it because it was inconvenient. >>=20 >> Now that it is out there, are we seriously going to ignore a document = with _those_ authors from a major browser maker and a team with = extensive experience in the field jus because it is late!?!? > Speaking with WG chair hat on: >=20 > At the time of previous "what is the appropriate level" discussion, = the WG chairs concluded that there was a rough WG consensus to stay with = a higher-level API rather than trying to move the level of the API = downwards towards a "low level API". >=20 > Since that time and until this week, there has been no specific = proposal to be evaluated, and the main proponents of such an API have = been silent. Normal behaviour is to assume that a previous consensus = declaration stands until there is new technical evidence to be = evaluated, and proceed with further work on that basis. >=20 > So I can't agree that "because it was inconvenient" is an appropriate = characterization. >=20 > Harald >=20 >=20 From tim@phonefromhere.com Fri Aug 17 12:34:56 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E93A511E80E2 for ; Fri, 17 Aug 2012 12:34:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tDN-sTvbAlZ4 for ; Fri, 17 Aug 2012 12:34:56 -0700 (PDT) Received: from zimbra.westhawk.co.uk (zimbra.westhawk.co.uk [192.67.4.167]) by ietfa.amsl.com (Postfix) with ESMTP id 41C1C11E80E0 for ; Fri, 17 Aug 2012 12:34:56 -0700 (PDT) Received: from [10.47.160.214] (unknown [212.183.132.59]) by zimbra.westhawk.co.uk (Postfix) with ESMTP id 29D8937A91B; Fri, 17 Aug 2012 20:43:53 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Tim Panton In-Reply-To: <50228C5F.8010403@alvestrand.no> Date: Fri, 17 Aug 2012 20:34:43 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <81579634-CC55-46FF-8C3B-94EB5019786A@phonefromhere.com> <50228C5F.8010403@alvestrand.no> To: Harald Alvestrand X-Mailer: Apple Mail (2.1278) Cc: Alexey Aylarov , "Cullen Jennings \(fluffy\)" , "rtcweb@ietf.org" , "public-webrtc@w3.org" Subject: Re: [rtcweb] Microsoft tells W3C and IETF what we are doing no signs of offering real world interoperability X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 17 Aug 2012 19:34:57 -0000 Harald, I see from reviewing the archives that my reply to this didn't = go in for some reason, so I just want to put on the record that you are (of course) right. = There was no specific proposal to action, so there was nothing for the chairs to ignore. The point I failed to make politely was that many of us knew informally = that Skype/MS were not=20 happy with the situation, so a document like this should not have been = unexpected. My apologies for my rudeness. Tim. On 8 Aug 2012, at 16:57, Harald Alvestrand wrote: > On 08/07/2012 11:57 AM, Tim Panton wrote: >> Ok, the timing is unfortunate, but can you honestly say that we = didn't know that this was skype/microsofts opinion? We just chose to = ignore it because it was inconvenient. >>=20 >> Now that it is out there, are we seriously going to ignore a document = with _those_ authors from a major browser maker and a team with = extensive experience in the field jus because it is late!?!? > Speaking with WG chair hat on: >=20 > At the time of previous "what is the appropriate level" discussion, = the WG chairs concluded that there was a rough WG consensus to stay with = a higher-level API rather than trying to move the level of the API = downwards towards a "low level API". >=20 > Since that time and until this week, there has been no specific = proposal to be evaluated, and the main proponents of such an API have = been silent. Normal behaviour is to assume that a previous consensus = declaration stands until there is new technical evidence to be = evaluated, and proceed with further work on that basis. >=20 > So I can't agree that "because it was inconvenient" is an appropriate = characterization. >=20 > Harald >=20 >=20 From basilgohar@librevideo.org Fri Aug 17 13:05:17 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93AA521E8048 for ; Fri, 17 Aug 2012 13:05:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fetIAga5rSSo for ; Fri, 17 Aug 2012 13:05:17 -0700 (PDT) Received: from mail.zaytoon.hidayahonline.net (zaytoon.hidayahonline.net [173.193.202.83]) by ietfa.amsl.com (Postfix) with ESMTP id 1E4FB21E8044 for ; Fri, 17 Aug 2012 13:05:17 -0700 (PDT) Received: from [10.10.40.98] (rrcs-98-103-138-67.central.biz.rr.com [98.103.138.67]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: basilgohar@librevideo.org) by mail.zaytoon.hidayahonline.net (Postfix) with ESMTPSA id 5140065666F for ; Fri, 17 Aug 2012 16:05:16 -0400 (EDT) Message-ID: <502EA3F9.7080400@librevideo.org> Date: Fri, 17 Aug 2012 16:05:13 -0400 From: Basil Mohamed Gohar User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120717 Thunderbird/14.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <9E2843EA-EBB9-40B3-898C-6B5216FAE7A5@cisco.com> In-Reply-To: <9E2843EA-EBB9-40B3-898C-6B5216FAE7A5@cisco.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Confirmation of consensus on audio codecs X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 17 Aug 2012 20:05:17 -0000 +1 to Opus and G.711 being mandatory for audio. From basilgohar@librevideo.org Fri Aug 17 13:08:43 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3C8611E80F1 for ; Fri, 17 Aug 2012 13:08:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xjh49540iJOc for ; Fri, 17 Aug 2012 13:08:43 -0700 (PDT) Received: from mail.zaytoon.hidayahonline.net (zaytoon.hidayahonline.net [173.193.202.83]) by ietfa.amsl.com (Postfix) with ESMTP id 43C5C11E80EF for ; Fri, 17 Aug 2012 13:08:43 -0700 (PDT) Received: from [10.10.40.98] (rrcs-98-103-138-67.central.biz.rr.com [98.103.138.67]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: basilgohar@librevideo.org) by mail.zaytoon.hidayahonline.net (Postfix) with ESMTPSA id 6D63D656FFA for ; Fri, 17 Aug 2012 16:08:42 -0400 (EDT) Message-ID: <502EA4C7.5050407@librevideo.org> Date: Fri, 17 Aug 2012 16:08:39 -0400 From: Basil Mohamed Gohar User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120717 Thunderbird/14.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <9E2843EA-EBB9-40B3-898C-6B5216FAE7A5@cisco.com> <000801cd7c06$2de34710$89a9d530$@us> <001901cd7c19$03abf4c0$0b03de40$@us> In-Reply-To: <001901cd7c19$03abf4c0$0b03de40$@us> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Confirmation of consensus on audio codecs X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 17 Aug 2012 20:08:43 -0000 On 08/16/2012 09:38 PM, Richard Shockey wrote: > SOOO WRONG .. just do a simple search. It just hasn't been fully litigated > ...yet. It's impossible for something to be fully litigated. Even someone licensing H.264 through MPEG-LA is liable to be sued, as Motorola has taught us, and the promises from the cartel hold no guarantees for their future. The condition you are placing on VP8 is impossible to meet and falsely assumed to apply to H.264. What is real is that H.264 has a licensing situation that excludes implementation in a free software context in most places of the world that will use it, and VP8 does not. Now, this is a discussion about the audio codecs, but FUD is FUD and needs to be nipped in the bud. From juberti@google.com Fri Aug 17 16:23:18 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 611E511E80D7 for ; Fri, 17 Aug 2012 16:23:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.771 X-Spam-Level: X-Spam-Status: No, score=-102.771 tagged_above=-999 required=5 tests=[AWL=0.205, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Fa00bq0LXrE for ; Fri, 17 Aug 2012 16:23:14 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0933211E80A4 for ; Fri, 17 Aug 2012 16:23:13 -0700 (PDT) Received: by qcac10 with SMTP id c10so3880329qca.31 for ; Fri, 17 Aug 2012 16:23:13 -0700 (PDT) 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:x-system-of-record; bh=rUJLuFoJFByuFE9Wu3T+5tKa1r+xF95h924ivbo5O/c=; b=oPjABi1110AQdE8nK0W37TwVbS3lT6lhKKBXBmiPh5bGCHscLogc0ptxU9M3qd0sFO RCGnfi+8RICWyyUdJg4LvPCRq2EOAzoPJ5ZhuMLGISWDzgT1VTMEZA00zjZ8StvPbXG9 rpvV+V2vvjujynsYhanBRLcuhqXbn1slS6oj6rwTB+AHQ0dqX4VjqZFqC3eDdQyeAAxn X3Uep5IZjHLXSN10EFhGdbCFXyFEoySiWAoB+CRb/PjHPhJ9VPe05mkMHjyjXBnsPrW8 n9GEFCulJT4J018TBApoqV9cCXFY79NvJUoH+8G7NnzajBQwma9r5MLuJgjmucgksHwv EwfQ== X-Google-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:x-system-of-record:x-gm-message-state; bh=rUJLuFoJFByuFE9Wu3T+5tKa1r+xF95h924ivbo5O/c=; b=KOdiHT74Yn6Jr6F47NhIqnb69i3AiQXkXSlltF4LNGvrM9DYYjqGWVrFFZHiL22bcd Hu/ZTzn8lCK4NOUlpiNOFQy2L/Kksr4dz4eiQooK9SQ4iQXZ+Z0QtYcybG0M/PCaoQ+0 s5S/1RtkIvc3RbX0u/jWXdxy6JFd5RMfZYVLDA+krWgFtPJxwn2wIRPP4Zjl5KOsDmwD UQHWn4hUfge/VO/a8JeXO01q3EYxanPslZt3O/prd2k87h7mHiypS+DnTjK2eLTmDYaH JYLFwHXWasiUczflWqpNXl5c5jyw3QNNSssKdNR4oV9Bj5jOeVCwVobo/RZbQy3a7UNr FutQ== Received: by 10.229.114.220 with SMTP id f28mr771510qcq.107.1345245793120; Fri, 17 Aug 2012 16:23:13 -0700 (PDT) Received: by 10.229.114.220 with SMTP id f28mr771497qcq.107.1345245792874; Fri, 17 Aug 2012 16:23:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.218.80 with HTTP; Fri, 17 Aug 2012 16:22:52 -0700 (PDT) In-Reply-To: References: <9E2843EA-EBB9-40B3-898C-6B5216FAE7A5@cisco.com> <000801cd7c06$2de34710$89a9d530$@us> From: Justin Uberti Date: Fri, 17 Aug 2012 16:22:52 -0700 Message-ID: To: Bernard Aboba Content-Type: multipart/alternative; boundary=0023544702ec9eafa304c77e7117 X-System-Of-Record: true X-Gm-Message-State: ALoCoQlPaF+EJrHRQCed0K9ALmYZJ46oNRflE3lN0qHpKHsu7eNC52Yt4SqPZW7FeOOyXNNynRXqJ0NPk+hXwdLAGjv/gDj/BnTJZa0TVXtUcY1IAdAxghms15ZS7me4vnYBZCMhnpawjQLtxrkTL+EgV7KDWzTIo2CIBUqmPQoGoZrlqGcq5kY/htORwq2eOYBE6W3D544a Cc: "Cullen Jennings \(fluffy\)" , "rtcweb@ietf.org" Subject: Re: [rtcweb] Confirmation of consensus on audio codecs X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 17 Aug 2012 23:23:18 -0000 --0023544702ec9eafa304c77e7117 Content-Type: text/plain; charset=UTF-8 I agree that Opus and G.711 should be the MTI audio codecs for WebRTC. On Thu, Aug 16, 2012 at 5:41 PM, Bernard Aboba wrote: > I also support the selection of OPUS and G.711 as MTI. G.722 can be a > SHOULD; it is widely supported. > > > > On Aug 16, 2012, at 4:24 PM, "Richard Shockey" wrote: > > > Reading this list is occasionally an act of torture banned by several > > conventions ..but since you ask. > > > > I completely support the selection of Opus and G.711 as mandatory to > > implement audio codec's ..however I'm very very open minded about > supporting > > G.722. It has it merits. It should be totally obvious to most that if > you > > even think about interconnecting to public E.164 networks the default > option > > for VoLTE and Enterprise Voice networks is going to be G.722. > > > > If it is your goal to create globally useful stove pipes fine, but > > interconnection with existing carrier real time networks is IMHO a > rational > > goal. > > > > As for Video .. for goodness sakes just get over it people. H.264 is > totally > > implemented everywhere on the planet Earth. So what about the > intellectual > > property problems. It's not like VP8 doesn't have problems either. > > > > I'll save my comments about the SDP offer/answer issue for another day. > > > > -----Original Message----- > > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > Behalf Of > > Cullen Jennings (fluffy) > > Sent: Thursday, August 16, 2012 1:16 PM > > To: rtcweb@ietf.org > > Subject: [rtcweb] Confirmation of consensus on audio codecs > > > > > > At the last meeting we took a hum on selecting Opus and G.711 as the > > mediatory to implement audio codecs. If there is any new opinions please > > send them to the list by August 30th, after which the chairs will make a > > determination of consensus. > > > > Thanks, > > Cullen > > > > Please note that the following IPR disclosure have been made on these > > codecs. They can be found at > > > > http://datatracker.ietf.org/ipr/ > > > > > > 2010-11-07 > > . ID # 1445 > > "Broadcom Corporation's Statement about IPR related to > > draft-ietf-codec-opus-00 and draft-ietf-codec-description-00 (1)" > > 2010-11-07 > > . ID # 1446 > > "Xiph.Org Foundation's Statement about IPR related to > > draft-ietf-codec-opus-00" > > 2010-11-12 > > . ID # 1447 > > "Broadcom Corporation's Statement about IPR related to > > draft-ietf-codec-opus-00 and draft-ietf-codec-description-00 (2)" > > 2011-03-23 > > . ID # 1520 > > "Qualcomm Incorporated's Statement about IPR related to > > draft-ietf-codec-opus-05" > > 2011-03-27 > > . ID # 1524 > > "Xiph.Org Foundation's Statement about IPR related to > > draft-ietf-codec-opus-05" > > 2011-03-29 > > . ID # 1526 > > "Broadcom Corporation's Statement about IPR related to > > draft-ietf-codec-opus-05" > > 2011-03-29 > > . ID # 1525 > > "Skype Limited's Statement about IPR related to draft-ietf-codec-opus-05" > > 2011-07-23 > > . ID # 1602 > > "Skype Limited's Statement about IPR related to draft-ietf-codec-opus-07" > > 2012-01-25 > > . ID # 1670 > > "Microsoft Corporation's Statement about IPR related to > > draft-ietf-codec-opus-10" > > 2012-03-12 > > . ID # 1712 > > "Huawei Technologies Co.,Ltd's Statement about IPR related to > > draft-ietf-codec-opus-11 (1)" > > 2012-04-02 > > . ID # 1741 > > "Huawei Technologies Co.,Ltd's Statement about IPR related to > > draft-ietf-codec-opus-11 (2)" > > > > > > > > _______________________________________________ > > 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 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --0023544702ec9eafa304c77e7117 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I agree that Opus and G.711 should be the MTI audio codecs for WebRTC.


On Thu, Aug 16, 20= 12 at 5:41 PM, Bernard Aboba <bernard_aboba@hotmail.com> wrote:
I also support the selection of OPUS and G.7= 11 as MTI. G.722 can be a SHOULD; it is widely supported.



On Aug 16, 2012, at 4:24 PM, "Richard Shockey" <richard@shockey.us> wrote:

> Reading this list is occasionally an act of torture banned by several<= br> > conventions ..but since you ask.
>
> I completely support the selection of Opus and G.711 as mandatory to > implement audio codec's ..however I'm very very open minded ab= out supporting
> G.722. It has it merits. =C2=A0It should be totally obvious to most th= at if you
> even think about interconnecting to public E.164 networks the default = option
> for VoLTE and Enterprise Voice networks is going to be G.722.
>
> If it is your goal to create globally useful stove pipes fine, =C2=A0b= ut
> interconnection with existing carrier real time networks is IMHO a rat= ional
> goal.
>
> As for Video .. for goodness sakes just get over it people. H.264 is t= otally
> implemented everywhere on the planet Earth. So what about the intellec= tual
> property problems. It's not like VP8 doesn't have problems eit= her.
>
> I'll save my comments about the SDP offer/answer issue for another= day.
>
> -----Original Message-----
> From: rtcweb-bounces@ietf.o= rg [mailto:rtcweb-bounces@ie= tf.org] On Behalf Of
> Cullen Jennings (fluffy)
> Sent: Thursday, August 16, 2012 1:16 PM
> To: rtcweb@ietf.org
> Subject: [rtcweb] Confirmation of consensus on audio codecs
>
>
> At the last meeting we took a hum on selecting Opus and G.711 as the > mediatory to implement audio codecs. If there is any new opinions plea= se
> send them to the list by August 30th, after which the chairs will make= a
> determination of consensus.
>
> Thanks,
> Cullen
>
> Please note that the following IPR disclosure have been made on these<= br> > codecs. They can be found at
>
> http://= datatracker.ietf.org/ipr/
>
>
> 2010-11-07
> . ID # 1445
> "Broadcom Corporation's Statement about IPR related to
> draft-ietf-codec-opus-00 and draft-ietf-codec-description-00 (1)"=
> 2010-11-07
> . ID # 1446
> "Xiph.Org Foundation's Statement about IPR related to
> draft-ietf-codec-opus-00"
> 2010-11-12
> . ID # 1447
> "Broadcom Corporation's Statement about IPR related to
> draft-ietf-codec-opus-00 and draft-ietf-codec-description-00 (2)"=
> 2011-03-23
> . ID # 1520
> "Qualcomm Incorporated's Statement about IPR related to
> draft-ietf-codec-opus-05"
> 2011-03-27
> . ID # 1524
> "Xiph.Org Foundation's Statement about IPR related to
> draft-ietf-codec-opus-05"
> 2011-03-29
> . ID # 1526
> "Broadcom Corporation's Statement about IPR related to
> draft-ietf-codec-opus-05"
> 2011-03-29
> . ID # 1525
> "Skype Limited's Statement about IPR related to draft-ietf-co= dec-opus-05"
> 2011-07-23
> . ID # 1602
> "Skype Limited's Statement about IPR related to draft-ietf-co= dec-opus-07"
> 2012-01-25
> . ID # 1670
> "Microsoft Corporation's Statement about IPR related to
> draft-ietf-codec-opus-10"
> 2012-03-12
> . ID # 1712
> "Huawei Technologies Co.,Ltd's Statement about IPR related to=
> draft-ietf-codec-opus-11 (1)"
> 2012-04-02
> . ID # 1741
> "Huawei Technologies Co.,Ltd's Statement about IPR related to=
> draft-ietf-codec-opus-11 (2)"
>
>
>
> _______________________________________________
> 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
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb

--0023544702ec9eafa304c77e7117-- From stpeter@stpeter.im Fri Aug 17 16:44:04 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E362E21F848A for ; Fri, 17 Aug 2012 16:44:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.764 X-Spam-Level: X-Spam-Status: No, score=-102.764 tagged_above=-999 required=5 tests=[AWL=-0.165, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NObxwYGW1Kyz for ; Fri, 17 Aug 2012 16:44:00 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 1412021F847A for ; Fri, 17 Aug 2012 16:44:00 -0700 (PDT) Received: from [192.168.0.4] (unknown [67.177.192.224]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 89ECB404EA; Fri, 17 Aug 2012 17:44:32 -0600 (MDT) Message-ID: <502ED73C.6030902@stpeter.im> Date: Fri, 17 Aug 2012 17:43:56 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Justin Uberti References: <9E2843EA-EBB9-40B3-898C-6B5216FAE7A5@cisco.com> <000801cd7c06$2de34710$89a9d530$@us> In-Reply-To: X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "Cullen Jennings \(fluffy\)" , "rtcweb@ietf.org" Subject: Re: [rtcweb] Confirmation of consensus on audio codecs X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 17 Aug 2012 23:44:04 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Agreed (as long as by G.711 we mean both PCMA and PCMU). On 8/17/12 5:22 PM, Justin Uberti wrote: > I agree that Opus and G.711 should be the MTI audio codecs for > WebRTC. > > > On Thu, Aug 16, 2012 at 5:41 PM, Bernard Aboba > > > wrote: > > I also support the selection of OPUS and G.711 as MTI. G.722 can > be a SHOULD; it is widely supported. > > > > On Aug 16, 2012, at 4:24 PM, "Richard Shockey" > wrote: > >> Reading this list is occasionally an act of torture banned by >> several conventions ..but since you ask. >> >> I completely support the selection of Opus and G.711 as mandatory >> to implement audio codec's ..however I'm very very open minded >> about > supporting >> G.722. It has it merits. It should be totally obvious to most > that if you >> even think about interconnecting to public E.164 networks the > default option >> for VoLTE and Enterprise Voice networks is going to be G.722. >> >> If it is your goal to create globally useful stove pipes fine, >> but interconnection with existing carrier real time networks is >> IMHO a > rational >> goal. >> >> As for Video .. for goodness sakes just get over it people. >> H.264 > is totally >> implemented everywhere on the planet Earth. So what about the > intellectual >> property problems. It's not like VP8 doesn't have problems >> either. >> >> I'll save my comments about the SDP offer/answer issue for >> another > day. >> >> -----Original Message----- From: rtcweb-bounces@ietf.org >> > [mailto:rtcweb-bounces@ietf.org ] > On Behalf Of >> Cullen Jennings (fluffy) Sent: Thursday, August 16, 2012 1:16 PM >> To: rtcweb@ietf.org Subject: [rtcweb] >> Confirmation of consensus on audio codecs >> >> >> At the last meeting we took a hum on selecting Opus and G.711 as >> the mediatory to implement audio codecs. If there is any new >> opinions > please >> send them to the list by August 30th, after which the chairs >> will > make a >> determination of consensus. >> >> Thanks, Cullen >> >> Please note that the following IPR disclosure have been made on >> these codecs. They can be found at >> >> http://datatracker.ietf.org/ipr/ >> >> >> 2010-11-07 . ID # 1445 "Broadcom Corporation's Statement about >> IPR related to draft-ietf-codec-opus-00 and >> draft-ietf-codec-description-00 (1)" 2010-11-07 . ID # 1446 >> "Xiph.Org Foundation's Statement about IPR related to >> draft-ietf-codec-opus-00" 2010-11-12 . ID # 1447 "Broadcom >> Corporation's Statement about IPR related to >> draft-ietf-codec-opus-00 and draft-ietf-codec-description-00 >> (2)" 2011-03-23 . ID # 1520 "Qualcomm Incorporated's Statement >> about IPR related to draft-ietf-codec-opus-05" 2011-03-27 . ID # >> 1524 "Xiph.Org Foundation's Statement about IPR related to >> draft-ietf-codec-opus-05" 2011-03-29 . ID # 1526 "Broadcom >> Corporation's Statement about IPR related to >> draft-ietf-codec-opus-05" 2011-03-29 . ID # 1525 "Skype Limited's >> Statement about IPR related to > draft-ietf-codec-opus-05" >> 2011-07-23 . ID # 1602 "Skype Limited's Statement about IPR >> related to > draft-ietf-codec-opus-07" >> 2012-01-25 . ID # 1670 "Microsoft Corporation's Statement about >> IPR related to draft-ietf-codec-opus-10" 2012-03-12 . ID # 1712 >> "Huawei Technologies Co.,Ltd's Statement about IPR related to >> draft-ietf-codec-opus-11 (1)" 2012-04-02 . ID # 1741 "Huawei >> Technologies Co.,Ltd's Statement about IPR related to >> draft-ietf-codec-opus-11 (2)" >> -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlAu1zwACgkQNL8k5A2w/vxYzgCg5KnKpp5fIgoA54YB7XLev2Rk xO0An0+JXgD7RgnRTQVvyg+Z3WqC6MMQ =DFvE -----END PGP SIGNATURE----- From richard@shockey.us Sat Aug 18 11:05:05 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5109121F8487 for ; Sat, 18 Aug 2012 11:05:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.47 X-Spam-Level: X-Spam-Status: No, score=-101.47 tagged_above=-999 required=5 tests=[AWL=0.795, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 73m3qp2O9UV2 for ; Sat, 18 Aug 2012 11:05:04 -0700 (PDT) Received: from oproxy5-pub.bluehost.com (oproxy5-pub.bluehost.com [67.222.38.55]) by ietfa.amsl.com (Postfix) with SMTP id 987BD21F846F for ; Sat, 18 Aug 2012 11:04:52 -0700 (PDT) Received: (qmail 1587 invoked by uid 0); 18 Aug 2012 18:04:30 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by cpoproxy2.bluehost.com with SMTP; 18 Aug 2012 18:04:30 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From; bh=XcBo3mUSLKyCzYozUeKSz7okTFLxrNis+/bKpDSJXY0=; b=Zuq42dmBki2zxLER+z4bvBvGQ+hu7lycd+jHCSKYmV1I6u+6/p7ppD0ZmFfFFH/CRBIOagSclQ42eY8JvxaBwNqPgu7Mlt/+u+cnIE62IoqhR5XijveekL84PM/Az9HN; Received: from [71.191.243.130] (port=55063 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1T2nNu-0007Pb-4h; Sat, 18 Aug 2012 12:04:30 -0600 From: "Richard Shockey" To: "'Jonathan Rosenberg'" , "'Matthew Kaufman'" References: <9E2843EA-EBB9-40B3-898C-6B5216FAE7A5@cisco.com> <000801cd7c06$2de34710$89a9d530$@us> In-Reply-To: Date: Sat, 18 Aug 2012 14:04:26 -0400 Message-ID: <001d01cd7d6b$e8d75050$ba85f0f0$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac18mhYH7FeVglmQSZGsfoxxO/aUzQA0SfFw Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 71.191.243.130 authed with richard@shockey.us} Cc: "'Cullen Jennings \(fluffy\)'" , rtcweb@ietf.org Subject: Re: [rtcweb] Confirmation of consensus on audio codecs X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 18 Aug 2012 18:05:06 -0000 Even though 711 quality actually sucks. I only mention 722 ..AMR WB btw since it's obvious that if you may want to interoperate with the several billion mobile endpoints that may be deploying VoLTE over the next few years. It might prove useful, unless this entire exercise is about creating N squared silos. You are still going to have to define a MUST support video codec eventually so just get on with it ..saying VP8 only is just unrealistic. -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Jonathan Rosenberg Sent: Friday, August 17, 2012 1:02 PM To: Matthew Kaufman Cc: Cullen Jennings (fluffy); rtcweb@ietf.org Subject: Re: [rtcweb] Confirmation of consensus on audio codecs I'll chime in here too - it'll surprise no one that I agree Opus should be MTI. I agree on G.711 as well, as this has realistically been the lingua franca for voip since the very beginning. Its easy to put in, no IPR and will help with the many interop scenarios which the market will eventually want. Even if intermediaries are needed on the media path for other things - like ICE interop - at least we won't need transcode. -Jonathan R. On Fri, Aug 17, 2012 at 12:30 PM, Matthew Kaufman wrote: > I agree. OPUS because it will be the IETF standard for wideband audio on the Internet, G.711 for maximum interoperability. G.722 is a reasonable thing to put on the "SHOULD" list... there's some other good choices for the SHOULD list, but they unfortunately come with additional IPR issues. > > Matthew Kaufman > > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > Behalf Of Bernard Aboba > Sent: Thursday, August 16, 2012 5:42 PM > To: rtcweb@ietf.org > Cc: Cullen Jennings (fluffy); rtcweb@ietf.org > Subject: Re: [rtcweb] Confirmation of consensus on audio codecs > > I also support the selection of OPUS and G.711 as MTI. G.722 can be a SHOULD; it is widely supported. > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb -- Jonathan Rosenberg, Ph.D. GM Product Strategy and Research, Microsoft/Skype jdrosen@{skype.net,jdrosen.net,microsoft.com} http://www.jdrosen.net _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From richard@shockey.us Sat Aug 18 11:12:32 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C3C321F8495 for ; Sat, 18 Aug 2012 11:12:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.585 X-Spam-Level: X-Spam-Status: No, score=-100.585 tagged_above=-999 required=5 tests=[AWL=-0.179, BAYES_20=-0.74, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LAxzqSZ8RLjS for ; Sat, 18 Aug 2012 11:12:31 -0700 (PDT) Received: from oproxy9.bluehost.com (oproxy9.bluehost.com [69.89.24.6]) by ietfa.amsl.com (Postfix) with SMTP id 88A3221F848F for ; Sat, 18 Aug 2012 11:12:31 -0700 (PDT) Received: (qmail 3042 invoked by uid 0); 18 Aug 2012 18:12:04 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy9.bluehost.com with SMTP; 18 Aug 2012 18:12:04 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:To:From; bh=nD8OADEDxtANKBlh0IhNWWjefE2/noYmnWfhrl1qhcc=; b=SSIXXrGc7/gs1LCPgGjZt/70eWBqvIX8gWlfv50yCarbXBRmUbT+haB/VcFsL/IMgqRd/mLAArHh/d8fpeEaxjnrqpQgF+57fZ/Vnj1cCbHQBe+QkS5jQ2zleKJuEnc0; Received: from [71.191.243.130] (port=55304 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1T2nVE-0003IK-DX; Sat, 18 Aug 2012 12:12:04 -0600 From: "Richard Shockey" To: "'Basil Mohamed Gohar'" , References: <9E2843EA-EBB9-40B3-898C-6B5216FAE7A5@cisco.com> <000801cd7c06$2de34710$89a9d530$@us> <001901cd7c19$03abf4c0$0b03de40$@us> <502EA4C7.5050407@librevideo.org> In-Reply-To: <502EA4C7.5050407@librevideo.org> Date: Sat, 18 Aug 2012 14:12:01 -0400 Message-ID: <001e01cd7d6c$f79bdf60$e6d39e20$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac18tBwKHGFN+4YpT9WMTChQewz5/QAuKcyw Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 71.191.243.130 authed with richard@shockey.us} Subject: Re: [rtcweb] Confirmation of consensus on audio codecs X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 18 Aug 2012 18:12:32 -0000 Well nip on this for a while .. a simple search against "VP8 intellectual property issues" brings up some interesting points. It only takes one suit. -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Basil Mohamed Gohar Sent: Friday, August 17, 2012 4:09 PM To: rtcweb@ietf.org Subject: Re: [rtcweb] Confirmation of consensus on audio codecs On 08/16/2012 09:38 PM, Richard Shockey wrote: > SOOO WRONG .. just do a simple search. It just hasn't been fully > litigated ...yet. It's impossible for something to be fully litigated. Even someone licensing H.264 through MPEG-LA is liable to be sued, as Motorola has taught us, and the promises from the cartel hold no guarantees for their future. The condition you are placing on VP8 is impossible to meet and falsely assumed to apply to H.264. What is real is that H.264 has a licensing situation that excludes implementation in a free software context in most places of the world that will use it, and VP8 does not. Now, this is a discussion about the audio codecs, but FUD is FUD and needs to be nipped in the bud. _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From richard@shockey.us Sat Aug 18 11:36:42 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 376B821F849C for ; Sat, 18 Aug 2012 11:36:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.742 X-Spam-Level: X-Spam-Status: No, score=-100.742 tagged_above=-999 required=5 tests=[AWL=-0.002, BAYES_20=-0.74, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XOEwobr6Csel for ; Sat, 18 Aug 2012 11:36:41 -0700 (PDT) Received: from oproxy12-pub.bluehost.com (oproxy12-pub.bluehost.com [50.87.16.10]) by ietfa.amsl.com (Postfix) with SMTP id 32E6121F848F for ; Sat, 18 Aug 2012 11:36:34 -0700 (PDT) Received: (qmail 9311 invoked by uid 0); 18 Aug 2012 18:36:12 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy12.bluehost.com with SMTP; 18 Aug 2012 18:36:12 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:To:From; bh=tTgGn+YDmF2N4Rnvxo1eDKcJMJblFNjrJMIxyL7t5ys=; b=XPi9ooUDFfi3bcQGUHr1V3DKQPOHjRZjRe8/VmDamXG8kctkSFghG6nwniWeBLBm2QrFa0hD1Y1/i28qsAYq7uHL6btHf2AVSrXT/lPvElFuDVJJ+XVl3EBsqcpMm9wN; Received: from [71.191.243.130] (port=56050 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1T2nsa-0006UX-6Z; Sat, 18 Aug 2012 12:36:12 -0600 From: "Richard Shockey" To: "'Ted Hardie'" , References: In-Reply-To: Date: Sat, 18 Aug 2012 14:36:09 -0400 Message-ID: <002801cd7d70$568c3210$03a49630$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac170pzwuKrD/MqqQ+WsyqEqwqZFwwBnHaww Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 71.191.243.130 authed with richard@shockey.us} Subject: Re: [rtcweb] Video codec proposals due October 15th, 2012 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 18 Aug 2012 18:36:42 -0000 To make my position clear. The WG should support both H 264 and VP8. VP8 for obvious reasons. H 264 since it is nearly universally deployed. I would like to remind the WG of the importance of this decision in another context. Our obligation to support persons of with hearing impairments. http://en.wikipedia.org/wiki/Video_relay_service http://hraunfoss.fcc.gov/edocs_public/attachmatch/FCC-11-184A1.pdf Appendix B is instructive. There is a marvelous opportunity here to really do "the right thing" tm. -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Ted Hardie Sent: Thursday, August 16, 2012 1:14 PM To: rtcweb@ietf.org Subject: [rtcweb] Video codec proposals due October 15th, 2012 As agreed at the recent meeting, the chairs solicit internet-drafts naming proposed mandatory-to-implement video codecs or codec sets by October 15th, 2012. Please include any technical data you believe supports the choice you are proposing. A non-exhaustive list of data you may wish to include is found in slides 3-6 of http://www.ietf.org/proceedings/84/slides/slides-84-rtcweb-4.pptx . Discussion based on these will commence immediately upon receipt, rather than waiting until the October 15th deadline, so early submission is encouraged. regards, Ted Hardie _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From xiphmont@gmail.com Sat Aug 18 14:28:51 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5A5421F84CD for ; Sat, 18 Aug 2012 14:28:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eqdgm7m8LcWp for ; Sat, 18 Aug 2012 14:28:46 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 669BD21F847D for ; Sat, 18 Aug 2012 14:28:46 -0700 (PDT) Received: by eekb45 with SMTP id b45so1284017eek.31 for ; Sat, 18 Aug 2012 14:28:45 -0700 (PDT) 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=zXDHNmIZ53b6LdPdZGXNsfSBAvA5HF7Xx2h8aoukUlE=; b=EZSV8qVQRSy7KI0SQmB8LlN8rjPdJtLiy3Hzm6DNV/0ejFRDKhmFf7G7rvQEWTvXd8 O3cK515vyReEXjYpLu2G9DPj7MEgBILOfw7KaNlMcBOuWvyEcJu6QhsdsNVZjvNSr5/3 uwuhnTCxN8CfHXmvi/LT39GKgRz1RjMEnZdnHMyzqQvoNYUtkJ/QdiLA2tA4WSSvrYFP IRzP7GSvhNXxeo3Kh0/UVbnC46NipvoTjkcND1sNSePfblGB//5rHecGcsyCkdBbLMYR eCwGksqYRsg82GobZLtfjgqcpM3AfJnY6QrvVCWEaSoua1GZb9ZaPSlWNboA6Hd9f2gr MiQA== MIME-Version: 1.0 Received: by 10.14.4.201 with SMTP id 49mr2591201eej.0.1345325325397; Sat, 18 Aug 2012 14:28:45 -0700 (PDT) Received: by 10.14.183.136 with HTTP; Sat, 18 Aug 2012 14:28:45 -0700 (PDT) In-Reply-To: <002801cd7d70$568c3210$03a49630$@us> References: <002801cd7d70$568c3210$03a49630$@us> Date: Sat, 18 Aug 2012 17:28:45 -0400 Message-ID: From: Monty Montgomery To: Richard Shockey Content-Type: text/plain; charset=ISO-8859-1 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Video codec proposals due October 15th, 2012 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 18 Aug 2012 21:28:51 -0000 On Sat, Aug 18, 2012 at 2:36 PM, Richard Shockey wrote: > To make my position clear. The WG should support both H 264 and VP8. This misses the primary point of VP8: the fact that many stakeholders here CANNOT implement h.264. Every stakeholder can implement VP8. Some refuse to do so as they have a sunk investment in h.264, but this is not the same as 'cannot'. > H 264 since it is nearly universally deployed. You've lost me here. I can't use it. Oh sure, I have the code-- I'm just not allowed to do anything with it, and MPEG-LA won't sell me a license because I don't track downstream. Monty Xiph.Org From xiphmont@gmail.com Sat Aug 18 14:30:42 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0E2221F84CF for ; Sat, 18 Aug 2012 14:30:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xrlsalQKrn0v for ; Sat, 18 Aug 2012 14:30:37 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 39A1C21F847D for ; Sat, 18 Aug 2012 14:30:37 -0700 (PDT) Received: by eekb45 with SMTP id b45so1284178eek.31 for ; Sat, 18 Aug 2012 14:30:36 -0700 (PDT) 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=CMImYYYjhgT5c502aVbIz4lV1dRG6P3CkNknWtLvYJg=; b=AgAGvEMNiANU9T+TK2hMMVei6gJjV7Z4cICcGznIu6IcOWUrfMlue3SODmblF3KlYd GGBC0Z9CQeHlBStjbdIKg6MV83TI12eRwDotsq8LMNABq2MHJJiY7X37FBPyuHyfUrcA 4XudOwy83HLBU4KnNAn2KYp0ixkSuwjMKK1mjv9ZGbD8csR8n9DOWpj19e98ymuSEXNy H/RCuncSF9hHhBejH7V9u86T8OCzDBSF1q9aQJMfExrSqQKtGBL26OZCHOllHRjneRwN A8xzRg+nyW8yQplJg4v/yy8nCGrFVPbIcy12rTRZMAZIdFRsv6SOS1pAsZvtaVQLjy6K BqEg== MIME-Version: 1.0 Received: by 10.14.224.4 with SMTP id w4mr2595761eep.21.1345325436273; Sat, 18 Aug 2012 14:30:36 -0700 (PDT) Received: by 10.14.183.136 with HTTP; Sat, 18 Aug 2012 14:30:36 -0700 (PDT) In-Reply-To: References: <002801cd7d70$568c3210$03a49630$@us> Date: Sat, 18 Aug 2012 17:30:36 -0400 Message-ID: From: Monty Montgomery To: Richard Shockey Content-Type: text/plain; charset=ISO-8859-1 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Video codec proposals due October 15th, 2012 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 18 Aug 2012 21:30:42 -0000 On Sat, Aug 18, 2012 at 5:28 PM, Monty Montgomery wrote: > On Sat, Aug 18, 2012 at 2:36 PM, Richard Shockey wrote: >> To make my position clear. The WG should support both H 264 and VP8. Actually, I realize I may have misread what you wrote; you said 'support' which I took to mean 'mandate'. I assumed that's what you meant, but it is not what you wrote. Monty Xiph.Org From stewe@stewe.org Sat Aug 18 16:58:12 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 962C321F84DD for ; Sat, 18 Aug 2012 16:58:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.132 X-Spam-Level: X-Spam-Status: No, score=-5.132 tagged_above=-999 required=5 tests=[AWL=1.467, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BwizaCTMZKmT for ; Sat, 18 Aug 2012 16:58:08 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe006.messaging.microsoft.com [216.32.180.16]) by ietfa.amsl.com (Postfix) with ESMTP id 8CBF921F84B2 for ; Sat, 18 Aug 2012 16:58:08 -0700 (PDT) Received: from mail7-va3-R.bigfish.com (10.7.14.236) by VA3EHSOBE013.bigfish.com (10.7.40.63) with Microsoft SMTP Server id 14.1.225.23; Sat, 18 Aug 2012 23:58:07 +0000 Received: from mail7-va3 (localhost [127.0.0.1]) by mail7-va3-R.bigfish.com (Postfix) with ESMTP id C6FCE160159; Sat, 18 Aug 2012 23:58:07 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.133; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0710HT002.namprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -20 X-BigFish: PS-20(zz98dI9371I1432Izz1202h1082kzz1033IL8275bh8275dhz2fh2a8h668h839h944he5bhf0ah107ah) Received-SPF: pass (mail7-va3: domain of stewe.org designates 157.56.240.133 as permitted sender) client-ip=157.56.240.133; envelope-from=stewe@stewe.org; helo=BL2PRD0710HT002.namprd07.prod.outlook.com ; .outlook.com ; Received: from mail7-va3 (localhost.localdomain [127.0.0.1]) by mail7-va3 (MessageSwitch) id 1345334284703522_11405; Sat, 18 Aug 2012 23:58:04 +0000 (UTC) Received: from VA3EHSMHS002.bigfish.com (unknown [10.7.14.248]) by mail7-va3.bigfish.com (Postfix) with ESMTP id A8CC94A0333; Sat, 18 Aug 2012 23:58:04 +0000 (UTC) Received: from BL2PRD0710HT002.namprd07.prod.outlook.com (157.56.240.133) by VA3EHSMHS002.bigfish.com (10.7.99.12) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sat, 18 Aug 2012 23:58:04 +0000 Received: from BL2PRD0710MB349.namprd07.prod.outlook.com ([169.254.1.75]) by BL2PRD0710HT002.namprd07.prod.outlook.com ([10.255.102.37]) with mapi id 14.16.0190.008; Sat, 18 Aug 2012 23:58:04 +0000 From: Stephan Wenger To: Monty Montgomery Thread-Topic: [rtcweb] Video codec proposals due October 15th, 2012 Thread-Index: AQHNe9KcnBvEU9mQJkq36trv7RuVjpdf6QaAgAAwOYD//7RmAA== Date: Sat, 18 Aug 2012 23:58:01 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.102.4] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: stewe.org Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Video codec proposals due October 15th, 2012 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 18 Aug 2012 23:58:12 -0000 On 8.18.2012 14:28 , "Monty Montgomery" wrote: >On Sat, Aug 18, 2012 at 2:36 PM, Richard Shockey >wrote: >> To make my position clear. The WG should support both H 264 and VP8. > >This misses the primary point of VP8: the fact that many stakeholders >here CANNOT implement h.264. Every stakeholder can implement VP8. >Some refuse to do so as they have a sunk investment in h.264, but this >is not the same as 'cannot'. Monty, I refuse to accept this 'CANNOT" argument. It has been made before, in many variants. It's bogus, or at least unproductive. "CANNOT" necessarily is different from the viewpoint of various entities. However, in our case, I believe it boils down to what the entity calls an acceptable risk, and not so much into "investments sunk". The definition of an acceptable risk is up to the stakeholder that makes the determination, not you or me. If one stakeholder entity believes that violating, however openly, an open source license of their choice means they CANNOT implement a certain technology, so be it. (We all know that with respect to H.264 implementations, some folks beliefs are very differently from what people argue in rtcweb; x264 is published under the GPLv2, right?). I mean, I can accept that the stakeholder has good and valid reasons to make the argument. If one entity believes that they would need to pay MPEG-LA, and that paying $6.5M per year for getting a license under most H.264 patents put them out of business, it's again a useful argument, but not, in isolation, a decisive one. Those entities obviously have the right to make their point, as you do, and as the Mozilla guys do. (Not listing Google here; their motivations may well be a bit less straightforward, but that's for them to comment on and not for me. Just a small stab: if "investments sunk" would really play a big role, then let's look who has sunk one of the biggest investments into a codec technology over the past few years :-) However, if another stakeholder entity decides, for reasons of their own, that an implementation of VP8 may expose them to risks to the point that legal or business says cannot, then they CANNOT. These two CANNOTs must have the same strength when determining rough consensus. We have heard both voices. The two camps are approximately of the same strength. Even when looking at browser market share, neither camp is an overwhelming "winner". Which is why I suggested in Vancouver that it may be time to follow the WhatWG and W3C's lead and leave the mandatory video codec selection to the browser vendors, not to a standards community that, as this discussion shows again and again, is ill-prepared to deal with commercial realities. Leaving it to the browser vendors knowing that, at least initially, we may have interop problems. I said in Vancouver that it is unacceptable to allow the commercial considerations of an industry operating under one business model (for example open source), to block standards development going in a certain direction, if there are others operating under another business model (close source and $$$ for licensing) and they want a different direction. I will continue to say so. And will object quite noisily if such an argument would be decisive in the IETF's decision making process, one way or another. > >> H 264 since it is nearly universally deployed. > >You've lost me here. I can't use it. Oh sure, I have the code-- I'm >just not allowed to do anything with it, and MPEG-LA won't sell me a >license because I don't track downstream. So start tracking downstream. Your business model does not allow for it? Change it! =20 > >Monty >Xiph.Org >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb > From xiphmont@gmail.com Sat Aug 18 18:22:42 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76CC521F8484 for ; Sat, 18 Aug 2012 18:22:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lfvMlTi2Uipq for ; Sat, 18 Aug 2012 18:22:38 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id E631921F8455 for ; Sat, 18 Aug 2012 18:22:37 -0700 (PDT) Received: by eekb45 with SMTP id b45so1302531eek.31 for ; Sat, 18 Aug 2012 18:22:37 -0700 (PDT) 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=8UvezTVAntaO1tRhhQ9Pttmaf8du2NLPXR1I8/D9dDQ=; b=w/14ppBbsWNNyQkbfeRSt9y//yj3XAmYZYdUBQ35BHp+8N37q+K3Y7yyIUOAcaFYjw mIvXSDnw4UXvF7pNta1Qzu3gO0Q2lVSItv+uxG2bqjpKtNPn8NQeoWGeVwOXuI6jSD97 6+6o6eqOOF1WV2lAmqFP/rZZnR7qkg3T5JmDfxYv+mPYEiO9LsT113E9UllwLGblfOgW WKGMfYBFYrJzDXIgZ442F1vGAruChlCqlqvTUBwszQYLswjCW4XSmyHO+Etw+ZM4R1Ds B/Q/qexz4vHSX1WAGifNOBSJIzLTfNoFQI1LGj27bwtqLuqgYjoYX2bGr56aGBTIJkFi tV2A== MIME-Version: 1.0 Received: by 10.14.181.132 with SMTP id l4mr3109654eem.17.1345339356873; Sat, 18 Aug 2012 18:22:36 -0700 (PDT) Received: by 10.14.183.136 with HTTP; Sat, 18 Aug 2012 18:22:36 -0700 (PDT) In-Reply-To: References: Date: Sat, 18 Aug 2012 21:22:36 -0400 Message-ID: From: Monty Montgomery To: Stephan Wenger Content-Type: text/plain; charset=ISO-8859-1 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Video codec proposals due October 15th, 2012 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 19 Aug 2012 01:22:42 -0000 > Your business model does not allow for it? > Change it! You're entitled to your model, but I'm not entitled to mine? Well, of course, neither of us is entitled to anything. But to the point: No, I will not. I will continue to push for and accept only RF-or-nothing, as will many [most?] of the individuals actually contributing the work. This is non-negotiable with respect to many of our participation. That's not an ultimatum, it's a statement of fact (and part of Xiph's corporate charter; we must pull out if we ourselves cannot deploy it.) Others are welcome to bring the proceedings to a crashing halt if they so desire, and set up a nice, tightly controlled little proprietary sandbox where no one 'unapproved' is able to contribute, and we'll see how far that goes. Pity, there was already so much completed work. The Web was invented many times. No one cared until one came along that was Free. Lather, rinse, repeat. Monty Xiph.Org "All progress relies on the unreasonable man." From silviapfeiffer1@gmail.com Sat Aug 18 19:21:14 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ADF321F84CE for ; Sat, 18 Aug 2012 19:21:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LK0NRoGlJcap for ; Sat, 18 Aug 2012 19:21:14 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id DA14F21F8484 for ; Sat, 18 Aug 2012 19:21:13 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so5113690vbb.31 for ; Sat, 18 Aug 2012 19:21:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=1O4BkPYKx1t2/Nv9jqJS20KzRrQYcpHQGC8ZLL9kmf4=; b=0ISdJK5oLP0t+NBScNjrXBdRDRKBZ0s2VUrpqUDJuFT/lwjgBcKq9LJy9Bf9x3+Brb 8DVSKgwPRtPDtZ04DnsvGcQDfaX8k1zAOcfrdfE0BXm85xjuqxmQixwirNWPsPdbr7CF H3v4JTbW4LwUPsUL436BvOTX0UaPcpJ5MXBkeugB8IK9oaGmD6Qk9EOtR8O/Jo55ulWA wHSN/apiwKHToG/K6yBzzuT6vRnMdd6GBpehucWxlulmhy2HNSQH0r0D3ytlZ+lxUb9n AljUegHXt00E2xDsfWCAJN09UTVHtEn7DbRB+vow02D1RSN2bdKOQp0mxfmTxhplhFeU NGKA== Received: by 10.52.100.165 with SMTP id ez5mr5499284vdb.108.1345342873293; Sat, 18 Aug 2012 19:21:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.119.206 with HTTP; Sat, 18 Aug 2012 19:20:52 -0700 (PDT) In-Reply-To: <001e01cd7d6c$f79bdf60$e6d39e20$@us> References: <9E2843EA-EBB9-40B3-898C-6B5216FAE7A5@cisco.com> <000801cd7c06$2de34710$89a9d530$@us> <001901cd7c19$03abf4c0$0b03de40$@us> <502EA4C7.5050407@librevideo.org> <001e01cd7d6c$f79bdf60$e6d39e20$@us> From: Silvia Pfeiffer Date: Sun, 19 Aug 2012 12:20:52 +1000 Message-ID: To: Richard Shockey Content-Type: text/plain; charset=ISO-8859-1 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Confirmation of consensus on audio codecs X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 19 Aug 2012 02:21:14 -0000 On that search: did you also notice that it got amazingly quiet since July 2011? S. On Sun, Aug 19, 2012 at 4:12 AM, Richard Shockey wrote: > Well nip on this for a while .. a simple search against "VP8 intellectual > property issues" brings up some interesting points. It only takes one suit. > > > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of > Basil Mohamed Gohar > Sent: Friday, August 17, 2012 4:09 PM > To: rtcweb@ietf.org > Subject: Re: [rtcweb] Confirmation of consensus on audio codecs > > On 08/16/2012 09:38 PM, Richard Shockey wrote: >> SOOO WRONG .. just do a simple search. It just hasn't been fully >> litigated ...yet. > It's impossible for something to be fully litigated. Even someone licensing > H.264 through MPEG-LA is liable to be sued, as Motorola has taught us, and > the promises from the cartel hold no guarantees for their future. > > The condition you are placing on VP8 is impossible to meet and falsely > assumed to apply to H.264. What is real is that H.264 has a licensing > situation that excludes implementation in a free software context in most > places of the world that will use it, and VP8 does not. > > Now, this is a discussion about the audio codecs, but FUD is FUD and needs > to be nipped in the bud. > _______________________________________________ > 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 From tharper@logitech.com Sat Aug 18 19:29:32 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B259F21F84C9 for ; Sat, 18 Aug 2012 19:29:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kk9XAgANKv-1 for ; Sat, 18 Aug 2012 19:29:32 -0700 (PDT) Received: from na3sys009aog117.obsmtp.com (na3sys009aog117.obsmtp.com [74.125.149.242]) by ietfa.amsl.com (Postfix) with ESMTP id CDD9C21F8498 for ; Sat, 18 Aug 2012 19:29:31 -0700 (PDT) Received: from mail-pb0-f49.google.com ([209.85.160.49]) (using TLSv1) by na3sys009aob117.postini.com ([74.125.148.12]) with SMTP ID DSNKUDBPiwxIvgw02uv0QhPyWEh7ZWakTzar@postini.com; Sat, 18 Aug 2012 19:29:31 PDT Received: by pbbrq8 with SMTP id rq8so5564130pbb.8 for ; Sat, 18 Aug 2012 19:29:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:reply-to:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=DIOLHaI+gfwpxoj1u/9xDl5E3twGaiDQXedF0VbK0vc=; b=VRF5m5bjYi03LeSxZt0p2jKShZEcvvhyo38j0jnBjiuZmr5Q0d36+UUi23b4EkGLVa +m+BNnYYadn1weuVZ8cCrH73KfR6oje1NQnefZAgqB6h6Fa/SXErgEhPyIkzM4Bavj/y 9foFH/OwESU6VUHb++DdVT9o/HAVwfJCw5XSfEqCCnDqMnrgcl+Z38wrVENka8oiBCKp tzeXjKjE7ips1TLIlqp4T1zivXs3JGlAW9+796XPHomUxzvrr0OPKSIOoq1IZeaCT5h4 QbxnBvhpwZAvbNKorQvjJ68f7lmkVSxoDIeKwhRiaP/vN3U6bU2HDBfwG/BTQYAZC8Mm Eg3g== Received: by 10.68.231.168 with SMTP id th8mr24011122pbc.14.1345343370817; Sat, 18 Aug 2012 19:29:30 -0700 (PDT) Received: from [172.19.173.133] (c-76-126-8-251.hsd1.ca.comcast.net. [76.126.8.251]) by mx.google.com with ESMTPS id to6sm8108628pbc.12.2012.08.18.19.29.29 (version=SSLv3 cipher=OTHER); Sat, 18 Aug 2012 19:29:30 -0700 (PDT) Message-ID: <50304F80.3090107@logitech.com> Date: Sat, 18 Aug 2012 19:29:20 -0700 From: tom harper User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Richard Shockey References: <9E2843EA-EBB9-40B3-898C-6B5216FAE7A5@cisco.com> <000801cd7c06$2de34710$89a9d530$@us> <001d01cd7d6b$e8d75050$ba85f0f0$@us> In-Reply-To: <001d01cd7d6b$e8d75050$ba85f0f0$@us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQmkvDecY/Gw9SdisHRlhGVppqiw8wd5OJWC7oZkZb0ygVDQfBr2/Hk5Q2NFPJ1LVFtmqk4o Cc: "'Cullen Jennings \(fluffy\)'" , rtcweb@ietf.org Subject: Re: [rtcweb] Confirmation of consensus on audio codecs X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: tharper@logitech.com 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, 19 Aug 2012 02:29:32 -0000 I strongly support having 722 as mandatory - interop in the enterprise will greatly benefit. Opus and g.711 are +1 Tom On 8/18/2012 11:04 AM, Richard Shockey wrote: > Even though 711 quality actually sucks. I only mention 722 ..AMR WB btw > since it's obvious that if you may want to interoperate with the several > billion mobile endpoints that may be deploying VoLTE over the next few > years. It might prove useful, unless this entire exercise is about creating > N squared silos. > > You are still going to have to define a MUST support video codec eventually > so just get on with it ..saying VP8 only is just unrealistic. > > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of > Jonathan Rosenberg > Sent: Friday, August 17, 2012 1:02 PM > To: Matthew Kaufman > Cc: Cullen Jennings (fluffy); rtcweb@ietf.org > Subject: Re: [rtcweb] Confirmation of consensus on audio codecs > > I'll chime in here too - it'll surprise no one that I agree Opus should be > MTI. I agree on G.711 as well, as this has realistically been the lingua > franca for voip since the very beginning. Its easy to put in, no IPR and > will help with the many interop scenarios which the market will eventually > want. Even if intermediaries are needed on the media path for other things - > like ICE interop - at least we won't need transcode. > > -Jonathan R. > > On Fri, Aug 17, 2012 at 12:30 PM, Matthew Kaufman > wrote: >> I agree. OPUS because it will be the IETF standard for wideband audio on > the Internet, G.711 for maximum interoperability. G.722 is a reasonable > thing to put on the "SHOULD" list... there's some other good choices for the > SHOULD list, but they unfortunately come with additional IPR issues. >> Matthew Kaufman >> >> -----Original Message----- >> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On >> Behalf Of Bernard Aboba >> Sent: Thursday, August 16, 2012 5:42 PM >> To: rtcweb@ietf.org >> Cc: Cullen Jennings (fluffy); rtcweb@ietf.org >> Subject: Re: [rtcweb] Confirmation of consensus on audio codecs >> >> I also support the selection of OPUS and G.711 as MTI. G.722 can be a > SHOULD; it is widely supported. >> >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb > > > -- > Jonathan Rosenberg, Ph.D. > GM Product Strategy and Research, Microsoft/Skype > jdrosen@{skype.net,jdrosen.net,microsoft.com} > http://www.jdrosen.net > _______________________________________________ > 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 > > From richard@shockey.us Sun Aug 19 11:49:34 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CD2821F8595 for ; Sun, 19 Aug 2012 11:49:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.505 X-Spam-Level: X-Spam-Status: No, score=-101.505 tagged_above=-999 required=5 tests=[AWL=0.760, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EUUBlkWw22DO for ; Sun, 19 Aug 2012 11:49:30 -0700 (PDT) Received: from oproxy6-pub.bluehost.com (oproxy6-pub.bluehost.com [67.222.54.6]) by ietfa.amsl.com (Postfix) with SMTP id 69C8F21F8458 for ; Sun, 19 Aug 2012 11:49:30 -0700 (PDT) Received: (qmail 12573 invoked by uid 0); 19 Aug 2012 18:49:08 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by cpoproxy3.bluehost.com with SMTP; 19 Aug 2012 18:49:08 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From; bh=3zAihM9hFDLIkrDK6bY6w2v3Rhg55f+ovxWKB70ZKlA=; b=CidY6piku1xuJ7VNTLF6w/Um6vZ4XAlygHa7iHxtjHl5reluBDFrszLIOZddyf/atdVA2b9Kd8WrEzR12G6hy8Efi5OT1Y2VZEzCEeM0eJzG+fEEZplfSafpkfVga7Yc; Received: from [71.191.243.130] (port=53054 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1T3AYe-00041E-Bn; Sun, 19 Aug 2012 12:49:08 -0600 From: "Richard Shockey" To: "'Stephan Wenger'" , "'Monty Montgomery'" References: In-Reply-To: Date: Sun, 19 Aug 2012 14:49:05 -0400 Message-ID: <001501cd7e3b$4fca7150$ef5f53f0$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHNe9KcnBvEU9mQJkq36trv7RuVjpdf6QaAgAAwOYD//7RmAIABsEjg Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 71.191.243.130 authed with richard@shockey.us} Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Video codec proposals due October 15th, 2012 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 19 Aug 2012 18:49:34 -0000 We have heard both voices. The two camps are approximately of the same strength. Even when looking at browser market share, neither camp is an overwhelming "winner". Which is why I suggested in Vancouver that it may be time to follow the WhatWG and W3C's lead and leave the mandatory video codec selection to the browser vendors, not to a standards community that, as this discussion shows again and again, is ill-prepared to deal with commercial realities. Leaving it to the browser vendors knowing that, at least initially, we may have interop problems. [RS> ] I suggest that this is not a can you can kick down the road indefinitely. At some point we will have to make a decision since the ultimate goal is a globally interoperable service. I said in Vancouver that it is unacceptable to allow the commercial considerations of an industry operating under one business model (for example open source), to block standards development going in a certain direction, if there are others operating under another business model (close source and $$$ for licensing) and they want a different direction. I will continue to say so. And will object quite noisily if such an argument would be decisive in the IETF's decision making process, one way or another. > >> H 264 since it is nearly universally deployed. > >You've lost me here. I can't use it. Oh sure, I have the code-- I'm >just not allowed to do anything with it, and MPEG-LA won't sell me a >license because I don't track downstream. So start tracking downstream. Your business model does not allow for it? Change it! > >Monty >Xiph.Org >_______________________________________________ >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 From xiphmont@gmail.com Sun Aug 19 14:21:56 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BD2E21F85F4 for ; Sun, 19 Aug 2012 14:21:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vpJyIJFNhMyW for ; Sun, 19 Aug 2012 14:21:55 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 638BB21F85BB for ; Sun, 19 Aug 2012 14:21:55 -0700 (PDT) Received: by eekb45 with SMTP id b45so1423311eek.31 for ; Sun, 19 Aug 2012 14:21:54 -0700 (PDT) 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=wORa61HNm1OZQexYCrbQNkcUFtBvYMJu2crxPm0RKLQ=; b=hBvybPSimz9lB/ydfCkFCv7WvZTJ25EVIRBCZm6nEsMVB89hbugTq8jItuMppb930b jzTx9UvTA9XjJGesXr+11mahoP75SXCqauWTQ9/25nxiyXp3Y7cXhr4hw8eiK0jEuhD5 2ziRNIrVzAqIwbzIZoa1jF2ELbqgwrBU0UsZOVtm9yIAskU81lKAqbeHz+Wsfs4z8XqU HOh2CqBKlxhohKJYtKXmwDZR6at3HZ0mzjRL7tL+oyj/6GjwYFhbD+yqs/2PNGuQlgh2 UNzRPudKEaQimQyH0feQZ/FkgwMtZ2fsFxtAhdiPvvFa51H0rxcEHAAA0ypNU2bXXMgA DeUQ== MIME-Version: 1.0 Received: by 10.14.211.3 with SMTP id v3mr5894202eeo.43.1345411314609; Sun, 19 Aug 2012 14:21:54 -0700 (PDT) Received: by 10.14.183.136 with HTTP; Sun, 19 Aug 2012 14:21:54 -0700 (PDT) In-Reply-To: <001501cd7e3b$4fca7150$ef5f53f0$@us> References: <001501cd7e3b$4fca7150$ef5f53f0$@us> Date: Sun, 19 Aug 2012 17:21:54 -0400 Message-ID: From: Monty Montgomery To: Richard Shockey Content-Type: text/plain; charset=ISO-8859-1 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Video codec proposals due October 15th, 2012 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 19 Aug 2012 21:21:56 -0000 > not to a standards community that, as this > discussion shows again and again, is ill-prepared to deal with commercial > realities. Commercial realities? I thought we were the Lorax: we spoke for the Net, not for any one group's commercial realities. There's a world outside of MPEG. The net is a public resource, a public utility. Everyone is allowed to use the pipes. The water in the pipes is not free, but it is provided nearly at cost and ~ universally. The public has a right to the pipes and the water. Companies do not own the pipes. They do not own the water. But companies reap the benefits of clean, potable water (and a sewer system, though it's not as much fun to talk about) like everybody else. When the water in the pipes must be licensed, tracked, and restricted, by a single for-profit consortium with complete authority in the matter, it is no longer a public resource. It becomes a bad musical. I will not be able to buy the water in these pipes. Not because I can't afford it; those who control it will not sell me a license because I'm not willing to become an extension of their water enforcement agency. It is not about money, it is about control. So I am actually slightly offended at the suggestion I do not understand the commercial reality. I am knowingly standing against where it wants to take us. If WebRTC becomes encumbered, it very simply becomes yet another for-profit play, and that's... just not very interesting. We already have several of those in the same space. Monty From lorenzo@meetecho.com Sun Aug 19 14:32:56 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17FC721F84D1 for ; Sun, 19 Aug 2012 14:32:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WogEggyvZPlE for ; Sun, 19 Aug 2012 14:32:55 -0700 (PDT) Received: from smtplq01.aruba.it (smtplqs-out18.aruba.it [62.149.158.58]) by ietfa.amsl.com (Postfix) with SMTP id B276B21F84A7 for ; Sun, 19 Aug 2012 14:32:54 -0700 (PDT) Received: (qmail 3630 invoked by uid 89); 19 Aug 2012 21:32:52 -0000 Received: from unknown (HELO smtp8.aruba.it) (62.149.158.228) by smtplq01.aruba.it with SMTP; 19 Aug 2012 21:32:52 -0000 Received: (qmail 8563 invoked by uid 89); 19 Aug 2012 21:32:52 -0000 Received: from unknown (HELO rainpc) (lorenzo@meetecho.com@188.11.106.30) by smtp8.ad.aruba.it with SMTP; 19 Aug 2012 21:32:52 -0000 Date: Sun, 19 Aug 2012 23:26:08 +0200 From: Lorenzo Miniero To: Monty Montgomery Message-ID: <20120819232608.5aea9229@rainpc> In-Reply-To: References: <001501cd7e3b$4fca7150$ef5f53f0$@us> Organization: Meetecho X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.8; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Rating: smtp8.ad.aruba.it 1.6.2 0/1000/N X-Spam-Rating: smtplq01.aruba.it 1.6.2 0/1000/N Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Video codec proposals due October 15th, 2012 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 19 Aug 2012 21:32:56 -0000 On Sun, 19 Aug 2012 17:21:54 -0400 Monty Montgomery wrote: > > not to a standards community that, as this > > discussion shows again and again, is ill-prepared to deal with commercial > > realities. > > Commercial realities? I thought we were the Lorax: we spoke for the > Net, not for any one group's commercial realities. There's a world > outside of MPEG. > > The net is a public resource, a public utility. Everyone is allowed > to use the pipes. The water in the pipes is not free, but it is > provided nearly at cost and ~ universally. The public has a right to > the pipes and the water. Companies do not own the pipes. They do not > own the water. But companies reap the benefits of clean, potable > water (and a sewer system, though it's not as much fun to talk about) > like everybody else. > > When the water in the pipes must be licensed, tracked, and restricted, > by a single for-profit consortium with complete authority in the > matter, it is no longer a public resource. It becomes a bad musical. > > I will not be able to buy the water in these pipes. Not because I > can't afford it; those who control it will not sell me a license > because I'm not willing to become an extension of their water > enforcement agency. It is not about money, it is about control. > > So I am actually slightly offended at the suggestion I do not > understand the commercial reality. I am knowingly standing against > where it wants to take us. > > If WebRTC becomes encumbered, it very simply becomes yet another > for-profit play, and that's... just not very interesting. We already > have several of those in the same space. > I agree. Besides, it's not like just the browsers need to agree on the codec. Endpoints may not be browsers, but something someone else builds to make new and exciting applications out of the bricks WebRTC provides us with. As I already said some time ago, an encumbered codec would cut out most of the people who could fuel WebRTC with new ideas, use cases and so on. Go tell a student/geek that if he wants to implement a WebRTC endpoint that takes video from a peer, manipulates it somehow for fun and then gives it back or sends it to another peer that he needs a license for that. That of course also applies to small/tiny companies or startups: how many of them would embark the WebRTC road to try and make some business, knowing they should buy god-knows-how-many licences that could sink their business before it can even start? If they're even given the choice to buy some, of course, according to what Monty said. Just my two ents, Lorenzo > Monty > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb -- Lorenzo Miniero, COB Meetecho s.r.l. Web Conferencing and Collaboration Tools http://www.meetecho.com From mandyam@quicinc.com Sun Aug 19 20:26:11 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86D4321F8643 for ; Sun, 19 Aug 2012 20:26:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.711 X-Spam-Level: X-Spam-Status: No, score=-5.711 tagged_above=-999 required=5 tests=[AWL=0.887, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GYPTfdiehw9T for ; Sun, 19 Aug 2012 20:26:06 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id D4C2321F863C for ; Sun, 19 Aug 2012 20:26:05 -0700 (PDT) X-IronPort-AV: E=McAfee;i="5400,1158,6809"; a="224753134" Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by wolverine02.qualcomm.com with ESMTP; 19 Aug 2012 20:26:04 -0700 X-IronPort-AV: E=Sophos;i="4.77,795,1336374000"; d="scan'208,217";a="310216541" Received: from nasanexhc07.na.qualcomm.com ([172.30.39.190]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 19 Aug 2012 20:26:04 -0700 Received: from NASANEXD01H.na.qualcomm.com ([169.254.8.250]) by nasanexhc07.na.qualcomm.com ([172.30.39.190]) with mapi id 14.02.0318.001; Sun, 19 Aug 2012 20:26:03 -0700 From: "Mandyam, Giridhar" To: Tim Panton Thread-Topic: [rtcweb] Qualcomm's Position on Mandatory-to-Implement Audio Codecs for RTCWeb Thread-Index: Ac1wxkUEr1d+Ke5WQFCmnJL9YXz1tQLB6GGAACvIfBA= Date: Mon, 20 Aug 2012 03:26:02 +0000 Message-ID: References: <00DC1626-33DA-469F-9F06-4D59F2141260@phonefromhere.com> In-Reply-To: <00DC1626-33DA-469F-9F06-4D59F2141260@phonefromhere.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.30.39.5] Content-Type: multipart/alternative; boundary="_000_CAC8DBE4E9704C41BCB290C2F3CC921A162BAAFEnasanexd01hnaqu_" MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Qualcomm's Position on Mandatory-to-Implement Audio Codecs for RTCWeb X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 20 Aug 2012 03:26:11 -0000 --_000_CAC8DBE4E9704C41BCB290C2F3CC921A162BAAFEnasanexd01hnaqu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Tim, Thank you for your well-thought out reply. Please note that I was using th= e options presented in the straw poll conducted on mandatory-to-implement (= MTI) audio codecs at the RTCWeb meeting in Vancouver IETF 84 as the basis f= or this position statement. Since I have not seen official RTCWeb minutes = from that meeting yet, I will have to reproduce from memory the voting opti= ons presented to the attendees: (1) G.711 only for MTI, (2) G.711 and Opus= only for MTI, and (3) Opus only for MTI. Based on Cullen's email from las= t week, I assume that the call for consensus is still around these three op= tions alone. I made exactly the same argument about H261 and was told (correctly) that i= t was unacceptable to mandate a codec that would give users a poorer than necessary experience. I think what applies for video applies fo= r audio. Specifically g711 is a poor codec choice in a wide variety of network situa= tions - e.g. 3g and edge of wifi. In my experience a lower bandwidth codec which supports wideband, dynamically variable bitrates and error corr= ection / packet loss concealment is required to give these users audio that is acceptable to use in the coffee-shop / airport scenario. Can you clarify what you would suggest as an alternative? If one is willin= g to concede that Opus is not the best audio codec for many lower bandwidth= situations (which is depicted in http://www.opus-codec.org/comparison/), t= hen "poorer than necessary" would seem to point to mandating the codec that= provides best-in-class performance at a given operating condition. This w= ould provide optimal user experience but would also lead to many codecs bei= ng designated as MTI. There are many codecs which that can be said for. We happily run speex on l= ow end smartphones. - Heck we even use the java implementation in applets and get acceptable performance. g722 has recently dropped out of pa= tent, uses the same bandwidth as 711 and gives significantly better audio. Any device capable of running SRTP is capable of running either 722 or spee= x in my experience. Sorry to request clarification again, but do you believe G.722 should be re= -examined as an MTI option? Based on my understanding, .722 is not conside= red in the current call-for-consensus (although other participants have sug= gested it as well). If we are to open up such a debate, it would be helpfu= l if you could provide quantitative data backing your position. You are confusing mandatory-to-implement and mandatory-to-use. Just because= Opus must be available , you don't have to use it. The devices you mention almost all have AMR in DSP - but unfortunately that is encumbered s= o isn't ideal as a mandatory-to-implememnt codec but may well be used when it is available. That was not my intention - maybe my original wording was unclear. It is a= burden on app developers to have to provide SW-based Opus libraries if Opu= s is not available natively on the HW platforms they are targeting. They w= ill have to do this if Opus is MTI. They will also have to optimize their = SW-based implementation for each target HW platform, which also is costly. Again - making Opus mandatory to implement does not preclude supporting or = using any other codecs. By the way point d) applies to any codec you choose to name - so you are pr= obably arguing for no mandatory-to-implement codec - which would be a mistake I think. It certainly applies to g711 - in spades! And not having Opus as MTI does not preclude its use either. If we assume = the "poorer than necessary" criterion over a wide range of operating condit= ions as a prerequisite for MTI, then neither Opus nor G.711 are adequate. = With G.711 as the sole MTI audio codec, implementations are free to negotia= te the best possible user experience given the environment at the moment an= d what each side supports. From: Tim Panton [mailto:tim@phonefromhere.com] Sent: Thursday, August 16, 2012 2:41 AM To: Mandyam, Giridhar Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Qualcomm's Position on Mandatory-to-Implement Audio C= odecs for RTCWeb On 15 Aug 2012, at 14:48, Mandyam, Giridhar wrote: Hello All, Qualcomm is in favor of G.711 being the only mandatory-to-implement codec f= or RTCWeb. We do not support having both Opus and G.711 as mandatory-to-im= plement codecs. We state the following reasons: a) There is no technical need to have an audio codec besides G.711 be = designated as mandatory to implement. Because RTCWeb uses SDP to negotiate= the codecs, the only reason to have anything as mandatory is to make sure = there is always at least one codec that both sides can use, a lowest common= denominator. This allows the market to decide which codecs to support, ra= ther than edict from a standards body. Implementations can base their choi= ce of which codec to support based on what they are trying to optimize. Fo= r example, better performance for the environment at the time of the sessio= n, such as cell phone or desktop. I made exactly the same argument about H261 and was told (correctly) that i= t was unacceptable to mandate a codec that would give users a poorer than necessary experience. I think what applies for video applies fo= r audio. Specifically g711 is a poor codec choice in a wide variety of network situa= tions - e.g. 3g and edge of wifi. In my experience a lower bandwidth codec which supports wideband, dynamically variable bitrates and error corr= ection / packet loss concealment is required to give these users audio that is acceptable to use in the coffee-shop / airport scenario. b) G.711 is universal, unencumbered, and widely implemented. In add= ition, note that codec implementation and testing is quite costly for chip = and device manufacturers, and that cost is ultimately reflected in the cost= of the end-user device. The computational simplicity of G.711 and its lon= g-time availability on a broad range of platforms means that the implementa= tion is available on low/entry-tier devices and testing costs have already = been amortized over many years, thereby enabling its use in low cost end-us= er devices. If we want to see widespread use of RTCWeb for voice, than we = will reach a much broader population if the minimum requirements do not pro= hibit low-cost devices. There are many codecs which that can be said for. We happily run speex on l= ow end smartphones. - Heck we even use the java implementation in applets and get acceptable performance. g722 has recently dropped out of pa= tent, uses the same bandwidth as 711 and gives significantly better audio. Any device capable of running SRTP is capable of running either 722 or spee= x in my experience. c) A mandate for Opus will limit initial RTCWeb clients to use softwa= re-based codecs (on general purpose processors) where Opus can be implemen= ted and tested easily until it is available on a variety of DSPs. Even the= n, it will likely start on high-cost platforms. This may in turn mean that= RTCWeb clients could consume significantly more battery power than DSP-bas= ed codecs used in many traditional (circuit-switched) voice services, furth= er inhibiting the end-user from choosing RTCWeb over those services. You are confusing mandatory-to-implement and mandatory-to-use. Just because= Opus must be available , you don't have to use it. The devices you mention almost all have AMR in DSP - but unfortunately that is encumbered s= o isn't ideal as a mandatory-to-implememnt codec but may well be used when it is available. d) We do not believe Opus is more versatile than other standardized co= decs, because any measure of versatility should take into account quality a= t a given bitrate. If Opus is not able to deliver superior quality at all = supported bitrates when compared to other codecs, then it cannot be deemed = as being more versatile simply because it supports more bitrates when compa= red to other standardized codecs. Again - making Opus mandatory to implement does not preclude supporting or = using any other codecs. By the way point d) applies to any codec you choose to name - so you are pr= obably arguing for no mandatory-to-implement codec - which would be a mistake I think. It certainly applies to g711 - in spades! In conclusion - the IETF has a strong tradition of starting work with the l= east amount of complexity and specification possible, gaining operational e= xperience, and then refining things with revisions or extensions. So, the = least amount of complexity would be G.711 as the sole audio codec. RTCweb is never going to be a _least_possible_complexity_ project. The requ= irements mean we need SRTP (DTLS?), a video modern codec, Echo cancellatio= n, AGC, etc. Adding a good audio codec will not significantly extend the co= mplexity. _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --_000_CAC8DBE4E9704C41BCB290C2F3CC921A162BAAFEnasanexd01hnaqu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello Tim,

Thank you for your well-t= hought out reply.  Please note that I was using the options presented = in the straw poll conducted on mandatory-to-implement (MTI) audio codecs at the RTCWeb meeting in Vancouver IETF 84 as the basis for this po= sition statement.  Since I have not seen official RTCWeb minutes from = that meeting yet, I will have to reproduce from memory the voting options p= resented to the attendees:  (1) G.711 only for MTI, (2) G.711 and Opus only for MTI, and (3) Opus only for MTI.&= nbsp; Based on Cullen’s email from last week, I assume that the call = for consensus is still around these three options alone.<= /p>

 <= /p>

I made exactly the same argument about H261 and was = told (correctly) that it was unacceptable to mandate a codec that would giv= e users a

poorer than necessary experience. I think what appli= es for video applies for audio.

 

Specifically g711 is a poor codec choice in a wide v= ariety of network situations - e.g. 3g and edge of wifi. In my experience a= lower bandwidth

codec which supports wideband, dynamically vari= able bitrates and error correction / packet loss concealment is required to= give these users audio

that is acceptable to use in the  coffee-shop /= airport scenario. 

 

Can you clarify what you = would suggest as an alternative?  If one is willing to concede that Op= us is not the best audio codec for many lower bandwidth situations (which is depicted in ht= tp://www.opus-codec.org/comparison/), then “poorer than necessary= ” would seem to point to mandating the codec that provides best-in-cl= ass performance at a given operating condition.  This would provide optimal user experience but would also lead to many cod= ecs being designated as MTI.

 <= /p>

There are many codecs which that can be said for. We= happily run speex on low end smartphones. - Heck we even use the java impl= ementation in

applets and get acceptable performance. g722 has rec= ently dropped out of patent, uses the same bandwidth as 711 and gives signi= ficantly better audio.

Any device capable of running SRTP is capable of run= ning either 722 or speex in my experience. 

 <= /p>

Sorry to request clarific= ation again, but do you believe G.722 should be re-examined as an MTI optio= n?  Based on my understanding, .722 is not considered in the current call-for-consensus (although other participants have suggested= it as well).  If we are to open up such a debate, it would be helpful= if you could provide quantitative data backing your position.

 <= /p>

You are confusing mandatory-to-implement and mandato= ry-to-use. Just because Opus must be available , you don't have to use it. = The devices you 

mention almost all have AMR in DSP - but unfortunate= ly that is encumbered so isn't ideal as a mandatory-to-implememnt codec but= may well be 

used when it is available. 

 <= /p>

That was not my intention= – maybe my original wording was unclear.  It is a burden on app= developers to have to provide SW-based Opus libraries if Opus is not available natively on the HW platforms they are targeting.  They will= have to do this if Opus is MTI.  They will also have to optimize thei= r SW-based implementation for each target HW platform, which also is costly= . 

 <= /p>

Again - making Opus mandatory to implement does not = preclude supporting or using any other codecs. 

 

By the way point d) applies to any codec you choose = to name - so you are probably arguing for no mandatory-to-implement codec -= which would be

a mistake I think. It certainly applies to g711= - in spades!

 <= /p>

And not having Opus as MT= I does not preclude its use either.  If we assume the “poorer th= an necessary” criterion over a wide range of operating conditions as a prerequisite for MTI, then neither Opus nor G.711 are adequate.  Wi= th G.711 as the sole MTI audio codec, implementations are free to negotiate= the best possible user experience given the environment at the moment and = what each side supports. 

 <= /p>

From: Tim Pant= on [mailt= o:tim@phonefromhere.com]
Sent: Thursday, August 16, 2012 2:41 AM
To: Mandyam, Giridhar
Cc: rtcweb@iet= f.org
Subject: Re: [rtcweb] Qualcomm's Position on Mandatory-to-Implement = Audio Codecs for RTCWeb

 

 

On 15 Aug 2012, at 14:48, Mandyam, Giridhar wrote:



Hello All,

Qualcomm is in favor of G.711 being the= only mandatory-to-implement codec for RTCWeb.  We do not support havi= ng both Opus and G.711 as mandatory-to-implement codecs.  We state the following reasons:

 

a)<= span style=3D"font-size:7.0pt">      There is no technical need to have an audio codec besides G.711 be designated as= mandatory to implement.  Because RTCWeb uses SDP to negotiate the cod= ecs, the only reason to have anything as mandatory is to make sure there is= always at least one codec that both sides can use, a lowest common denominator.  This allows the market t= o decide which codecs to support, rather than edict from a standards body.&= nbsp; Implementations can base their choice of which codec to support based= on what they are trying to optimize.  For example, better performance for the environment at the time of the session= , such as cell phone or desktop.

 

I made exactly the same argument about H261 and was = told (correctly) that it was unacceptable to mandate a codec that would giv= e users a

poorer than necessary experience. I think what appli= es for video applies for audio.

 

Specifically g711 is a poor codec choice in a wide v= ariety of network situations - e.g. 3g and edge of wifi. In my experience a= lower bandwidth

codec which supports wideband, dynamically vari= able bitrates and error correction / packet loss concealment is required to= give these users audio

that is acceptable to use in the  coffee-shop /= airport scenario. 



b)<= span style=3D"font-size:7.0pt">      G.711 is universal, unencumbered, and widely implemented.    In a= ddition, note that codec implementation and testing is quite costly for chi= p and device manufacturers, and that cost is ultimately reflected in the co= st of the end-user device.  The computational simplicity of G.711 and its long-time availability on a broad range of platforms mean= s that the implementation is available on low/entry-tier devices and testin= g costs have already been amortized over many years, thereby enabling its u= se in low cost end-user devices.  If we want to see widespread use of RTCWeb for voice, than we will reach a= much broader population if the minimum requirements do not prohibit low-co= st devices. 

 

There are many codecs which that can be said for. We= happily run speex on low end smartphones. - Heck we even use the java impl= ementation in

applets and get acceptable performance. g722 has rec= ently dropped out of patent, uses the same bandwidth as 711 and gives signi= ficantly better audio.

Any device capable of running SRTP is capable of run= ning either 722 or speex in my experience. 

 



c)<= span style=3D"font-size:7.0pt">       A mandate for Opus will limit initial RTCWeb clients to use software-based&n= bsp; codecs (on general purpose processors) where Opus can be implemented a= nd tested easily until it is available on a variety of DSPs.  Even the= n, it will likely start on high-cost platforms.  This may in turn mean that RTCWeb clients could consume significantly more= battery power than DSP-based codecs used in many traditional (circuit-swit= ched) voice services, further inhibiting the end-user from choosing RTCWeb = over those services.

 

You are confusing mandatory-to-implement and mandato= ry-to-use. Just because Opus must be available , you don't have to use it. = The devices you 

mention almost all have AMR in DSP - but unfortunate= ly that is encumbered so isn't ideal as a mandatory-to-implememnt codec but= may well be 

used when it is available. 



d)<= span style=3D"font-size:7.0pt">      We do not believe Opus is more versatile than other standardized codecs, beca= use any measure of versatility should take into account quality at a given = bitrate.  If Opus is not able to deliver superior quality at all suppo= rted bitrates when compared to other codecs, then it cannot be deemed as being more versatile simply because it= supports more bitrates when compared to other standardized codecs.

 

 

Again - making Opus mandatory to implement does not = preclude supporting or using any other codecs. 

 

By the way point d) applies to any codec you choose = to name - so you are probably arguing for no mandatory-to-implement codec -= which would be

a mistake I think. It certainly applies to g711= - in spades!



 

In conclusion - the IETF has a strong t= radition of starting work with the least amount of complexity and specifica= tion possible, gaining operational experience, and then refining things with revisions or extensions.  So, the least amount o= f complexity would be G.711 as the sole audio codec.

 

RTCweb is never going to be a _least_possible_comple= xity_ project. The requirements mean we need  SRTP (DTLS?), a video mo= dern codec, Echo cancellation, AGC, etc. Adding a good audio codec will not= significantly extend the complexity.

 

 



_____________________________________= __________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb<= o:p>

 

--_000_CAC8DBE4E9704C41BCB290C2F3CC921A162BAAFEnasanexd01hnaqu_-- From john@jlc.net Mon Aug 20 09:26:27 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CB7521F86F2 for ; Mon, 20 Aug 2012 09:26:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.737 X-Spam-Level: X-Spam-Status: No, score=-105.737 tagged_above=-999 required=5 tests=[AWL=0.862, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DfsTl71BJ1cC for ; Mon, 20 Aug 2012 09:26:26 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 567D221F86E5 for ; Mon, 20 Aug 2012 09:26:26 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 28A6933C27; Mon, 20 Aug 2012 12:26:26 -0400 (EDT) Date: Mon, 20 Aug 2012 12:26:26 -0400 From: John Leslie To: Tim Panton Message-ID: <20120820162626.GE85937@verdi> References: <00DC1626-33DA-469F-9F06-4D59F2141260@phonefromhere.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00DC1626-33DA-469F-9F06-4D59F2141260@phonefromhere.com> User-Agent: Mutt/1.4.1i Cc: "rtcweb@ietf.org" , "Mandyam, Giridhar" Subject: [rtcweb] Mandatory-to-Implement Audio Codecs for RTCWeb X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 20 Aug 2012 16:26:27 -0000 Tim Panton wrote: > On 15 Aug 2012, at 14:48, Mandyam, Giridhar wrote: > >> Qualcomm is in favor of G.711 being the only mandatory-to-implement >> codec for RTCWeb. An otherwise valid argument is mortally wounded by this statement. We participate as individuals in IETF Working Groups; and stating something as a "position" tends to make others consign you to "the rough". >> We do not support having both Opus and G.711 as mandatory-to-implement >> codecs. We state the following reasons: >> >> There is no technical need to have an audio codec besides G.711 be >> designated as mandatory to implement. Because RTCWeb uses SDP to >> negotiate the codecs, the only reason to have anything as mandatory >> is to make sure there is always at least one codec that both sides >> can use, a lowest common denominator. Exactly true! >> This allows the market to decide which codecs to support, rather than >> edict from a standards body. Implementations can base their choice of >> which codec to support based on what they are trying to optimize. For >> example, better performance for the environment at the time of the >> session, such as cell phone or desktop. The intended situation as RTCWEB matures is that the endpoints will choose among a number of codecs which both support, taking into account the characteristics of the link between them. > I made exactly the same argument about H261 and was told (correctly) > that it was unacceptable to mandate a codec that would give users a > poorer than necessary experience. No, that is not "correctly"! It would be unacceptable to mandate the _use_ of a codec giving sub-standard experience; but it is _exactly_ acceptable to mandate the _implementation_ of a codec which gives "poorer than necessary experience" in even a _majority_ of actual conditions. We certainly hope there will be better options available for particular conditions; and we certainly hope that the conditions available will improve. > I think what applies for video applies for audio. Mostly true; but given a century of experience with audio-only telephone use, there is perhaps wiggle-room for failure to agree on a video codec. (What I mean here is that _if_ we can't find any video codec that all RTCWEB stacks "can" implement, we could theoretically fall back to a short list of SHOULD implement.) > Specifically g711 is a poor codec choice in a wide variety of > network situations - e.g. 3g and edge of wifi. True, but that's the wrong consideration. A mandatory-to-implement codec isn't asked to give "good" results in every case. > In my experience a lower bandwidth codec which supports wideband, > dynamically variable bitrates and error correction / packet loss > concealment is required to give these users audio that is acceptable > to use in the coffee-shop / airport scenario. That's a good argument; but it goes beyond the target we're aiming for as "mandatory-to-implement". >> G.711 is universal, unencumbered, and widely implemented. In addition, >> note that codec implementation and testing is quite costly for chip >> and device manufacturers, and that cost is ultimately reflected in >> the cost of the end-user device. The computational simplicity of >> G.711 and its long-time availability on a broad range of platforms >> means that the implementation is available on low/entry-tier devices >> and testing costs have already been amortized over many years, >> thereby enabling its use in low cost end-user devices. This is also a good argument; and it is pretty much on-target. >> If we want to see widespread use of RTCWeb for voice, than we will >> reach a much broader population if the minimum requirements do not >> prohibit low-cost devices. This is a weaker argument, but still appropriate IMHO. > There are many codecs which that can be said for. We happily run > speex on low end smartphones. - Heck we even use the java > implementation in applets and get acceptable performance. g722 has > recently dropped out of patent, uses the same bandwidth as 711 and > gives significantly better audio. Any device capable of running > SRTP is capable of running either 722 or speex in my experience. And this is a good counter-argument... >> A mandate for Opus will limit initial RTCWeb clients to use >> software-based codecs (on general purpose processors) where Opus >> can be implemented and tested easily until it is available on a >> variety of DSPs. Even then, it will likely start on high-cost >> platforms. I find this argument weak. I would expect any RTCWEB device to need to _start_ on this path. >> This may in turn mean that RTCWeb clients could consume >> significantly more battery power than DSP-based codecs used in >> many traditional (circuit-switched) voice services, further >> inhibiting the end-user from choosing RTCWeb over those services. That's a valid argument; but it's about a commercial tradeoff, and I don't see a good reason why we need to optimize for a particular commercial environment. > You are confusing mandatory-to-implement and mandatory-to-use. A lot of us seem to be suffering from that confusion! > Just because Opus must be available, you don't have to use it. You _might_ have to use it... But it's only required as a last resort, and it's perfectly reasonable to warn the end-user that battery life will suffer. > The devices you mention almost all have AMR in DSP - but > unfortunately that is encumbered so isn't ideal as a > mandatory-to-implememnt codec but may well be used when it is > available. > >> We do not believe Opus is more versatile than other standardized >> codecs, because any measure of versatility should take into account >> quality at a given bitrate. If Opus is not able to deliver superior >> quality at all supported bitrates when compared to other codecs, >> then it cannot be deemed as being more versatile simply because it >> supports more bitrates when compared to other standardized codecs. This is a straw-man. :^( > Again - making Opus mandatory to implement does not preclude > supporting or using any other codecs. > >> In conclusion - the IETF has a strong tradition of starting work >> with the least amount of complexity and specification possible, >> gaining operational experience, and then refining things with >> revisions or extensions. That's not as true as it used to be. :^( >> So, the least amount of complexity would be G.711 as the sole >> audio codec. > > RTCweb is never going to be a _least_possible_complexity_ project. > The requirements mean we need SRTP (DTLS?), a video modern codec, > Echo cancellation, AGC, etc. Adding a good audio codec will not > significantly extend the complexity. This thread is full of good arguments! I hope we will contiue it, but hold a little better to what we mean by "mandatory-to-implement". -- John Leslie From ted.ietf@gmail.com Mon Aug 20 11:45:59 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED11521F86B7 for ; Mon, 20 Aug 2012 11:45:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.854 X-Spam-Level: X-Spam-Status: No, score=-3.854 tagged_above=-999 required=5 tests=[AWL=-0.255, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a3xQEziIW1bD for ; Mon, 20 Aug 2012 11:45:59 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 65B6A21F86BE for ; Mon, 20 Aug 2012 11:45:59 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so6083829vcb.31 for ; Mon, 20 Aug 2012 11:45:58 -0700 (PDT) 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=k6hD0953fBU+CT5NJutU+61WW4de06IY5xXGf0Ms8IY=; b=WF6jPyvJdTFlDQv4w33htfAPbtJ2zEkQ+ocWOErd78RExc4lrrS3b6gGnKnh4tvT/Y HpcV9DohmnWYCbohCaptsxO73aBE1K0v1TrCrgWQjp6vSGFI6oCD/oDzVyDVQjBIvbJT v6stoHOnC46/poqWVpmzEmVUPLwQ1iGZT0JQES7ehE2t5lUP/Dq48R8bj/F4U7jtYf2a tdMIq3UPUsT38Mt4XKtDcj6Dt2u/TslYfdjr9YqvwP3ycyV8OKar1GhBvxwB0OMiSKDP 2P638PMnVtl/NpdDc6gS24bIhFXUVnwD2/2EFqve/XylWFL/NQ6i/VyTYPOwm+8GWzKt JOyA== MIME-Version: 1.0 Received: by 10.52.100.33 with SMTP id ev1mr9587944vdb.17.1345488358760; Mon, 20 Aug 2012 11:45:58 -0700 (PDT) Received: by 10.58.228.232 with HTTP; Mon, 20 Aug 2012 11:45:58 -0700 (PDT) In-Reply-To: References: <001501cd7e3b$4fca7150$ef5f53f0$@us> Date: Mon, 20 Aug 2012 11:45:58 -0700 Message-ID: From: Ted Hardie To: Monty Montgomery , Stephan Wenger , Lorenzo Miniero Content-Type: text/plain; charset=ISO-8859-1 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Video codec proposals due October 15th, 2012 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 20 Aug 2012 18:46:00 -0000 Howdy, I just want to remind folks contributing to this thread where we are in the process: getting documents which make *concrete, technical* proposals. Those need to be in by October 15th. Please focus your energy on that. thanks, Ted Hardie From emcho@sip-communicator.org Mon Aug 20 15:12:39 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B4BE21F84D2 for ; Mon, 20 Aug 2012 15:12:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.232 X-Spam-Level: X-Spam-Status: No, score=-2.232 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_05=-1.11, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LicJPralR4sh for ; Mon, 20 Aug 2012 15:12:38 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 885A721F84B9 for ; Mon, 20 Aug 2012 15:12:38 -0700 (PDT) Received: by ghbg16 with SMTP id g16so6031751ghb.31 for ; Mon, 20 Aug 2012 15:12:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type :x-gm-message-state; bh=XGp42DjJRea/GXPk91bHi8Pw3FMg8xd6VpkvC4uAndM=; b=m+5O+d+3fCkdCnEU2FwWWKnfUMcTQOlYW0+uYjDfD0+m5W+xSvokXdFmWnK4EqX6WV 1vo5ch0nv5kIFuMdRFva/q1mhWkTBN7uyJBWAw5RYXy8eFjY24k9BeW+3NAhIHIWSGLZ M1/GyRNfRHwCGaJS5o9tR9VoD0JzR0mr88ggOPFvIBVWkTh/d+RkZLPnRAs5x5Br+HZf wyM2or3+b5W11BawRh7kOq8FDx4tN37k6od2Jt0Hq7Ki9DxQKi3DV8jRigO232lnNo2K n/ULi71PInyhXhapDgpeEIsGhGc5rPthgLpvJBDkz14IzOzdKKGnK4/y9BxADPB/GgBn T9mQ== Received: by 10.236.177.70 with SMTP id c46mr23597114yhm.33.1345500758032; Mon, 20 Aug 2012 15:12:38 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by mx.google.com with ESMTPS id v5sm7962622anj.16.2012.08.20.15.12.37 (version=SSLv3 cipher=OTHER); Mon, 20 Aug 2012 15:12:37 -0700 (PDT) Received: by yenm5 with SMTP id m5so6028098yen.31 for ; Mon, 20 Aug 2012 15:12:37 -0700 (PDT) Received: by 10.50.40.234 with SMTP id a10mr11218935igl.44.1345500756867; Mon, 20 Aug 2012 15:12:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.43.131.194 with HTTP; Mon, 20 Aug 2012 15:12:16 -0700 (PDT) From: Emil Ivov Date: Tue, 21 Aug 2012 00:12:16 +0200 Message-ID: To: rtcweb@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQm8rfyq54VMA+Vd2n2tmkquuFqb+FH6x6YOkS+0fv7oN+VffE7JyXsdXMynm9JYyrBQTuYu Subject: [rtcweb] H.264's freeness for Internet apps X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 20 Aug 2012 22:12:39 -0000 On February 2, 2010 MPEG-LA made an announcemnt that sounded like it would not charge royalties for Internet video: http://www.mpegla.com/main/Pages/Media.aspx Does anyone have an idea as to how the exact licensing text would apply to RTC[web] applications? Emil From xiphmont@gmail.com Mon Aug 20 16:23:05 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8572E21F844E for ; Mon, 20 Aug 2012 16:23:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8BcJUMlkSMYO for ; Mon, 20 Aug 2012 16:23:05 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id D0DC321F8440 for ; Mon, 20 Aug 2012 16:23:04 -0700 (PDT) Received: by eaai11 with SMTP id i11so2028395eaa.31 for ; Mon, 20 Aug 2012 16:23:04 -0700 (PDT) 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=u/DdYWyxI1faLKGeIgTFwMgypqAI+nF5WPFQOUE6kFQ=; b=qMI5Ef4qiUhAtnBh9HK0x7X4B7ABGrQJXxF3IJN0zwJmJzvEkfc5qwPsXA1OxM/HXG AA8L68qipkT/39B0tM8JCJMSTaPDy6SH54pfRIr+Jugir1KyNyjL3TMfLM0eQOBINMQ9 a8uS034BhysXF9e0NfTQcp9jO65o4wcuw57iXiAwHwhm4ruSzHYsRJjCd9AOL1PMHl2t GggKtIVUXzAUBfwJ0GISp5msPHJkonZXpK7SueJPxQ6QByrzN+aXdqks1GXEjMacRBS2 bPCoO61gKD+xO4if2Skh0Sy2CgfSTvXj5io5wd4S7DWo9FiOWh+tph8mXYV2F7g8xUvu zKaw== MIME-Version: 1.0 Received: by 10.14.4.201 with SMTP id 49mr10864025eej.0.1345504983876; Mon, 20 Aug 2012 16:23:03 -0700 (PDT) Received: by 10.14.183.136 with HTTP; Mon, 20 Aug 2012 16:23:03 -0700 (PDT) In-Reply-To: References: Date: Mon, 20 Aug 2012 19:23:03 -0400 Message-ID: From: Monty Montgomery To: Emil Ivov Content-Type: text/plain; charset=ISO-8859-1 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] H.264's freeness for Internet apps X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 20 Aug 2012 23:23:05 -0000 On Mon, Aug 20, 2012 at 6:12 PM, Emil Ivov wrote: > On February 2, 2010 MPEG-LA made an announcemnt that sounded like it > would not charge royalties for Internet video: There had been worry that the h.264 pool would add new royalties to the content streams themselves in 2015; The announcement was that there would be no new royalties in 2015, not that any existing royalties were going away. And yes, the exact wording confused many tech reporters who took it to mean "H.264 is free now!" Monty From stephane.proust@orange.com Tue Aug 21 00:57:55 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D92D21F8549 for ; Tue, 21 Aug 2012 00:57:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.794 X-Spam-Level: X-Spam-Status: No, score=-0.794 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, SARE_MILLIONSOF=0.315, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4HWx+T4vY0R9 for ; Tue, 21 Aug 2012 00:57:51 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 3080D21F8540 for ; Tue, 21 Aug 2012 00:57:51 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 6148B264B97; Tue, 21 Aug 2012 09:57:50 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 4708735C048; Tue, 21 Aug 2012 09:57:50 +0200 (CEST) Received: from PEXCVZYM14.corporate.adroot.infra.ftgroup ([fe80::a42f:c628:bc76:d592]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0298.004; Tue, 21 Aug 2012 09:57:49 +0200 From: To: "Cullen Jennings (fluffy)" , "rtcweb@ietf.org" Thread-Topic: Confirmation of consensus on audio codecs Thread-Index: AQHNe9LENUMF/Hj3nEmo2lnRJlNz25dj6efA Date: Tue, 21 Aug 2012 07:57:49 +0000 Message-ID: <20330_1345535870_50333F7E_20330_3420_1_2842AD9A45C83B44B57635FD4831E60A029156@PEXCVZYM14.corporate.adroot.infra.ftgroup> References: <9E2843EA-EBB9-40B3-898C-6B5216FAE7A5@cisco.com> In-Reply-To: <9E2843EA-EBB9-40B3-898C-6B5216FAE7A5@cisco.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.2] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.8.21.70317 Subject: Re: [rtcweb] Confirmation of consensus on audio codecs X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 21 Aug 2012 07:57:55 -0000 For voice and multimedia communication services as targeted by WebRTC, two = codecs, G.711 and G.722, are fully fitting the conditions to get a mandator= y to implement status: a fully ensured unencumbered status, a wide implemen= tation in devices and legacy networks and a low complexity that ensures the= y can be supported on any types of plate-forms and terminals. So we support both G.711 and G.722 to be specified as "mandatory to impleme= nt" codecs since G.722 will guarantee a much higher voice quality at same b= it rate and almost no additional cost. At a minimum G.722 should be (strong= ly) recommended. With respect to OPUS, it has currently no footprint on the market, its impl= ementation complexity and resulting costs are unknown, including with respe= ct to IPRs issues, and some performance aspects are still to be more deeply= assessed, like for instance quality with packet losses and jitter which is= a key issue for usage over internet.=20 In addition, we believe that two additional requirements are necessary to m= ake WebRTC a future proof technology and suitable for a wide range of appli= cations and environments: Firstly, the optional support of other widely deployed legacy codecs must b= e allowed which includes at least the codecs implemented in millions of mob= ile terminals: AMR and AMR-WB. Secondly, the technology must be open enough to facilitate the usage of any= other codecs supported by the device but external to the browser. -----Message d'origine----- De=A0: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] De la part = de Cullen Jennings (fluffy) Envoy=E9=A0: jeudi 16 ao=FBt 2012 19:16 =C0=A0: rtcweb@ietf.org Objet=A0: [rtcweb] Confirmation of consensus on audio codecs At the last meeting we took a hum on selecting Opus and G.711 as the mediat= ory to implement audio codecs. If there is any new opinions please send the= m to the list by August 30th, after which the chairs will make a determinat= ion of consensus. Thanks, Cullen Please note that the following IPR disclosure have been made on these codec= s. They can be found at=20 http://datatracker.ietf.org/ipr/ 2010-11-07=09 . ID # 1445 "Broadcom Corporation's Statement about IPR related to draft-ietf-codec-opu= s-00 and draft-ietf-codec-description-00 (1)" 2010-11-07=09 . ID # 1446 "Xiph.Org Foundation's Statement about IPR related to draft-ietf-codec-opus= -00" 2010-11-12=09 . ID # 1447 "Broadcom Corporation's Statement about IPR related to draft-ietf-codec-opu= s-00 and draft-ietf-codec-description-00 (2)" 2011-03-23=09 . ID # 1520 "Qualcomm Incorporated's Statement about IPR related to draft-ietf-codec-op= us-05" 2011-03-27=09 . ID # 1524 "Xiph.Org Foundation's Statement about IPR related to draft-ietf-codec-opus= -05" 2011-03-29=09 . ID # 1526 "Broadcom Corporation's Statement about IPR related to draft-ietf-codec-opu= s-05" 2011-03-29=09 . ID # 1525 "Skype Limited's Statement about IPR related to draft-ietf-codec-opus-05" 2011-07-23=09 . ID # 1602 "Skype Limited's Statement about IPR related to draft-ietf-codec-opus-07" 2012-01-25=09 . ID # 1670 "Microsoft Corporation's Statement about IPR related to draft-ietf-codec-op= us-10" 2012-03-12=09 . ID # 1712 "Huawei Technologies Co.,Ltd's Statement about IPR related to draft-ietf-co= dec-opus-11 (1)" 2012-04-02=09 . ID # 1741 "Huawei Technologies Co.,Ltd's Statement about IPR related to draft-ietf-co= dec-opus-11 (2)" _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From randell-ietf@jesup.org Tue Aug 21 08:02:43 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9844921F84A5 for ; Tue, 21 Aug 2012 08:02:43 -0700 (PDT) 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=[AWL=-0.963, BAYES_20=-0.74, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id omc2X4IY0Iim for ; Tue, 21 Aug 2012 08:02:42 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id ACE3F21F8491 for ; Tue, 21 Aug 2012 08:02:42 -0700 (PDT) Received: from pool-173-49-141-60.phlapa.fios.verizon.net ([173.49.141.60] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1T3pyb-0007RO-Ql for rtcweb@ietf.org; Tue, 21 Aug 2012 10:02:41 -0500 Message-ID: <5033A2FF.4000603@jesup.org> Date: Tue, 21 Aug 2012 11:02:23 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <9E2843EA-EBB9-40B3-898C-6B5216FAE7A5@cisco.com> <20330_1345535870_50333F7E_20330_3420_1_2842AD9A45C83B44B57635FD4831E60A029156@PEXCVZYM14.corporate.adroot.infra.ftgroup> In-Reply-To: <20330_1345535870_50333F7E_20330_3420_1_2842AD9A45C83B44B57635FD4831E60A029156@PEXCVZYM14.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [rtcweb] Confirmation of consensus on audio codecs X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 21 Aug 2012 15:02:43 -0000 On 8/21/2012 3:57 AM, stephane.proust@orange.com wrote: > For voice and multimedia communication services as targeted by WebRTC, two codecs, G.711 and G.722, are fully fitting the conditions to get a mandatory to implement status: a fully ensured unencumbered status, a wide implementation in devices and legacy networks and a low complexity that ensures they can be supported on any types of plate-forms and terminals. > > So we support both G.711 and G.722 to be specified as "mandatory to implement" codecs since G.722 will guarantee a much higher voice quality at same bit rate and almost no additional cost. At a minimum G.722 should be (strongly) recommended. I agree G.722 should be a "SHOULD". Note I said "I". While in reality corporations and organizations that IETF contributors are associated with have opinions on IETF activities, officially IETF recognizes individuals as contributors. > With respect to OPUS, it has currently no footprint on the market, its implementation complexity and resulting costs are unknown, including with respect to IPRs issues, and some performance aspects are still to be more deeply assessed, like for instance quality with packet losses and jitter which is a key issue for usage over internet. Opus was designed within the IETF specifically to handle usage over the Internet better than existing codecs. > In addition, we believe that two additional requirements are necessary to make WebRTC a future proof technology and suitable for a wide range of applications and environments: > Firstly, the optional support of other widely deployed legacy codecs must be allowed which includes at least the codecs implemented in millions of mobile terminals: AMR and AMR-WB. The spec does not restrict what codecs can be supported beyond the MTI codecs. You can offer any codecs you support. > Secondly, the technology must be open enough to facilitate the usage of any other codecs supported by the device but external to the browser. This is an implementation detail for browsers and not part of the spec; a browser is free to offer any codecs supported by the platform if it wishes. -- Randell Jesup randell-ietf@jesup.org From ted.ietf@gmail.com Tue Aug 21 08:35:18 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27BA121F87A4 for ; Tue, 21 Aug 2012 08:35:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.764 X-Spam-Level: X-Spam-Status: No, score=-3.764 tagged_above=-999 required=5 tests=[AWL=-0.480, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BUKxpnGgFGgx for ; Tue, 21 Aug 2012 08:35:17 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 57C2621F879F for ; Tue, 21 Aug 2012 08:35:17 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so7181301vcb.31 for ; Tue, 21 Aug 2012 08:35:10 -0700 (PDT) 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=/ePBN3VXF5MYsxp7jw4YO3r1nKvW1bOUWF6q/DVE1So=; b=PvK/jxcLIUtLczLDigTupPpH/XK3gDH5rrma92p2BgsX6axX/AgwtZPZa2+I/IE3Ig ifg5us3vVRFu09P75uWEk04qmlGTkbTL/DD1Zbw0DpY16wl/mgo4mDnWbgSsf9tsyN76 l1g1CiR0oikhMSXdsp3Rp++Q9zEjd1CW9cAuaCs7q8Oj0nT53bpEkWxXM77a2IEw8QXr 0a3GEdPYhcdX19m2NndfD3b/o2TIbAWu7SBjYXfjF0cw0D1z+/lapJGHn6GA/Qj5dfAD jDa3KoZ7pt1J7KnrHt+lNvT2hYa1EiOkkQhEPBwCOS8UQe4fqABQto1h1MU4RGBMPQ7m +SSA== MIME-Version: 1.0 Received: by 10.58.239.232 with SMTP id vv8mr15047378vec.37.1345563309933; Tue, 21 Aug 2012 08:35:09 -0700 (PDT) Received: by 10.58.228.232 with HTTP; Tue, 21 Aug 2012 08:35:09 -0700 (PDT) In-Reply-To: <20330_1345535870_50333F7E_20330_3420_1_2842AD9A45C83B44B57635FD4831E60A029156@PEXCVZYM14.corporate.adroot.infra.ftgroup> References: <9E2843EA-EBB9-40B3-898C-6B5216FAE7A5@cisco.com> <20330_1345535870_50333F7E_20330_3420_1_2842AD9A45C83B44B57635FD4831E60A029156@PEXCVZYM14.corporate.adroot.infra.ftgroup> Date: Tue, 21 Aug 2012 08:35:09 -0700 Message-ID: From: Ted Hardie To: stephane.proust@orange.com Content-Type: text/plain; charset=ISO-8859-1 Cc: "Cullen Jennings \(fluffy\)" , "rtcweb@ietf.org" Subject: Re: [rtcweb] Confirmation of consensus on audio codecs X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 21 Aug 2012 15:35:18 -0000 On Tue, Aug 21, 2012 at 12:57 AM, wrote: > In addition, we believe that two additional requirements are necessary to make WebRTC a future proof technology and suitable for a wide range of applications and environments: > Firstly, the optional support of other widely deployed legacy codecs must be allowed which includes at least the codecs implemented in millions of mobile terminals: AMR and AMR-WB. > Secondly, the technology must be open enough to facilitate the usage of any other codecs supported by the device but external to the browser. > > Stephane, On you first point, the fundamental design of RTCWEB allows for the negotiation of any codec mutually supported. The decision to chose a Mandatory-to-implement was not made to eliminate other choices, but to eliminate interoperability failures by ensuring that at least one common codec is always available. On your second point, the group presumes that codec support does not come from the downloadable Javascript application, but from the application environment into which it is downloaded (commonly a browser or mobile environment using similar technology). Promoting support for those environments to have access to codecs supported by the underlying hardware is the best way to further this goal, at least in my personal opinion. best regards, Ted Hardie From christer.holmberg@ericsson.com Wed Aug 22 13:47:04 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9948821F86E4 for ; Wed, 22 Aug 2012 13:47:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.165 X-Spam-Level: X-Spam-Status: No, score=-6.165 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Op+5cShh-G88 for ; Wed, 22 Aug 2012 13:47:04 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id AF48321F86D7 for ; Wed, 22 Aug 2012 13:47:03 -0700 (PDT) X-AuditID: c1b4fb2d-b7fea6d000002ccb-4b-5035454634b2 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 6C.AC.11467.64545305; Wed, 22 Aug 2012 22:47:02 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.99]) by esessmw0256.eemea.ericsson.se ([153.88.115.96]) with mapi; Wed, 22 Aug 2012 22:47:02 +0200 From: Christer Holmberg To: "rtcweb@ietf.org" Date: Wed, 22 Aug 2012 22:47:01 +0200 Thread-Topic: Codec control and SDP offer/answer frequency Thread-Index: AQHNgKdHrv5YwX3VRkCXvrJSTohPig== Message-ID: <7F2072F1E0DE894DA4B517B93C6A05853409FF2EE3@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrJLMWRmVeSWpSXmKPExsUyM+Jvra6bq2mAwbVGbYu1/9rZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CV0bP7AlvBSc6KjyuXsDQwnmPvYuTkkBAwkZhzeSEzhC0mceHe ejYQW0jgFKPE6sepXYxcQPYCRol5UycANXBwsAlYSHT/0wapERFQl7j88ALYHBYBVYnOlodg vcICphLHv/ayQ9RYSVz4OIsZwtaTeHL+KlicVyBcYtLUdjCbEWjv91NrmEBsZgFxiVtP5jNB 3CMgsWTPeajbRCVePv7HClEvKnGnfT0jRL2exI2pU9ggbG2JZQtfM0PMF5Q4OfMJywRG4VlI xs5C0jILScssJC0LGFlWMQrnJmbmpJcb6qUWZSYXF+fn6RWnbmIEBvfBLb91dzCeOidyiFGa g0VJnJcrab+/kEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBkaLRSeTry9yPMUUeTj7KudZlv8N 2c27o1/a7TLprLC8WX9v8tL1iz9azL8/tc6XX9aj0uLvpRXhbwKtdqye+NhSwbBB/2Xazvon 9dvUNQKO8vh+VnAU/8zuJX+sV1Hl4Pej2RtTVlgmKUx6sGFfYGBC12Xl2oyJ0j1ll298uJpp zX19//oNp2SUWIozEg21mIuKEwEJ/g7BPAIAAA== Subject: [rtcweb] Codec control and SDP offer/answer frequency X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 22 Aug 2012 20:47:04 -0000 Hi, In Vancouver two proposals for codec were presented, one based on COP and o= ne based on the SDP imageattr attribute. The result from the straw poll was= that people preferred to move forward with the SDP based solution. When Harald presented his poker game example, he mentioned that there could= be changes with a few seconds interval. For my clarification, does that mean that a UA would send SDP offer/answers= every few second??? If so, I don't think that would create good results. First, it would cause heavy load on every entity that has to parse the SDP,= as they need to parse the whole message body, and then figure out what has= changed. Second, due to race conditions rules, SIP transaction rules etc, and *other= * usages of SDP offer/answer within the session, there is a high risk that = SDP offers (not only those related to codec control) would be rejected. Off= er/answer is a rather "heavy" mechanism, and I don't think it's intended to= be used in the suggested way. Normally you would send one (or a few) offer= /answer(s) during call establishment, and between zero and a few during the= session. Or, did I missunderstand something? Regards, Christer From harald@alvestrand.no Thu Aug 23 02:00:43 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56ADF21F85FC for ; Thu, 23 Aug 2012 02:00:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.329 X-Spam-Level: X-Spam-Status: No, score=-110.329 tagged_above=-999 required=5 tests=[AWL=0.271, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dhb8pNTTLhoG for ; Thu, 23 Aug 2012 02:00:42 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 5D7C821F85F7 for ; Thu, 23 Aug 2012 02:00:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 46C4539E0CE for ; Thu, 23 Aug 2012 11:00:34 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ho1EDv58-8gc for ; Thu, 23 Aug 2012 11:00:33 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:be30:5bff:fede:bcdc]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 158CA39E031 for ; Thu, 23 Aug 2012 11:00:33 +0200 (CEST) Message-ID: <5035F12F.9000608@alvestrand.no> Date: Thu, 23 Aug 2012 11:00:31 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <7F2072F1E0DE894DA4B517B93C6A05853409FF2EE3@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05853409FF2EE3@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Codec control and SDP offer/answer frequency X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 23 Aug 2012 09:00:43 -0000 On 08/22/2012 10:47 PM, Christer Holmberg wrote: > Hi, > > In Vancouver two proposals for codec were presented, one based on COP and one based on the SDP imageattr attribute. The result from the straw poll was that people preferred to move forward with the SDP based solution. > > When Harald presented his poker game example, he mentioned that there could be changes with a few seconds interval. > > For my clarification, does that mean that a UA would send SDP offer/answers every few second??? > > If so, I don't think that would create good results. I don't quite buy the analysis - details below. The example given (the "poker game") would almost certainly be a very specialized application, with no requirements for interworking (you can't dial into a game from a videophone), and would most likely be implemented via a central server (if nothing else, to take care that nobody's cheating). For this type of application, where the end systems are already doing data exchange that is not representable in SDP (the game itself), I think a sensible architecture would be to pass the SDP offer/answer over the data channel. This means that traffic latency for passing SDP is on the same order as for media. > > First, it would cause heavy load on every entity that has to parse the SDP, as they need to parse the whole message body, and then figure out what has changed. Given that in such a specialized application, the only entity that has to parse SDP is the central node - how much CPU time do you think SDP parsing will take? (number of CPU-milliseconds?) > > Second, due to race conditions rules, SIP transaction rules etc, and *other* usages of SDP offer/answer within the session, there is a high risk that SDP offers (not only those related to codec control) would be rejected. Why, given that it's a point-to-point exchange? Admitted, glare will happen, and will have to be resolved in the usual ways (ROAP gave one mechanism that the game protocol can adopt). > Offer/answer is a rather "heavy" mechanism, and I don't think it's intended to be used in the suggested way. Well.. the Arpanet was originally intended for connecting teletypes to mainframes. It's proved to be useful in a few scenarios it was not originally created for. > Normally you would send one (or a few) offer/answer(s) during call establishment, and between zero and a few during the session. > > Or, did I missunderstand something? A specialized poker game is not intended to be interoperable with a videophone? > > Regards, > > Christer > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From christer.holmberg@ericsson.com Thu Aug 23 02:38:27 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5517121F853E for ; Thu, 23 Aug 2012 02:38:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.17 X-Spam-Level: X-Spam-Status: No, score=-6.17 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f+sfWvSPVIEl for ; Thu, 23 Aug 2012 02:38:26 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 4A52621F854D for ; Thu, 23 Aug 2012 02:38:25 -0700 (PDT) X-AuditID: c1b4fb30-b7f7d6d0000042ea-21-5035fa1088c8 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id D7.E4.17130.01AF5305; Thu, 23 Aug 2012 11:38:25 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.99]) by esessmw0184.eemea.ericsson.se ([10.2.3.53]) with mapi; Thu, 23 Aug 2012 11:38:24 +0200 From: Christer Holmberg To: Harald Alvestrand , "rtcweb@ietf.org" Date: Thu, 23 Aug 2012 11:38:23 +0200 Thread-Topic: [rtcweb] Codec control and SDP offer/answer frequency Thread-Index: Ac2BDck8/H1UFR4HT1KzzKN0xkPZdgAAvwf1 Message-ID: <7F2072F1E0DE894DA4B517B93C6A05853409FF2EF9@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05853409FF2EE3@ESESSCMS0356.eemea.ericsson.se>, <5035F12F.9000608@alvestrand.no> In-Reply-To: <5035F12F.9000608@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrFLMWRmVeSWpSXmKPExsUyM+Jvra7gL9MAgz/v2C2O9XWxWaz9187u wORxZcIVVo8lS34yBTBFcdmkpOZklqUW6dslcGX0rJcoOClTMfPVcpYGxudiXYycHBICJhIL 9u9ggbDFJC7cW8/WxcjFISRwilFiSu95RghnDqPEy32fmboYOTjYBCwkuv9pgzSICARL9D5/ zwhiswioSvx+/hNskLCAk8Sy5/3MEDXOEvfObmUEaRURMJK42ZUEEuYVCJfomDuZCcQWEqiQ +P/5CRuIzSmgK/GnqwmslRHonu+n1oDVMAuIS9x6Mp8J4k4BiSV7zjND2KISLx//Y4WoF5W4 076eEaJeR2LB7k9sELa2xLKFr5kh9gpKnJz5hGUCo+gsJGNnIWmZhaRlFpKWBYwsqxiFcxMz c9LLzfVSizKTi4vz8/SKUzcxAuPj4JbfBjsYN90XO8QozcGiJM6rp7rfX0ggPbEkNTs1tSC1 KL6oNCe1+BAjEwenVAOj99E/jx5/ZkhsjQlU3PExMVZDsMVGVM/j/WmRZEfJ6e16J11Dr9Zz vH1XGBspVRDiuvoO44JThQ3Sl5xlHgntllHa3dR14/ndjnmiXIt00k5875n9dM/0gJWPds4M +dOuelFT4IpnQ89hw11bVxv3if4xsul7wBk9xbKM7bfUdbPSL4H2mxYosRRnJBpqMRcVJwIA bpYVUF0CAAA= Subject: Re: [rtcweb] Codec control and SDP offer/answer frequency X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 23 Aug 2012 09:38:27 -0000 Hi Harald, >> In Vancouver two proposals for codec were presented, one based on COP an= d one based on the SDP imageattr attribute. The result from the straw poll = was that people preferred to move forward with the SDP based solution. >> >> When Harald presented his poker game example, he mentioned that there co= uld be changes with a few seconds interval. >> >> For my clarification, does that mean that a UA would send SDP offer/answ= ers every few second??? >> >> If so, I don't think that would create good results. > > I don't quite buy the analysis - details below. > > The example given (the "poker game") would almost certainly be a very > specialized application, with no requirements for interworking (you > can't dial into a game from a videophone), and would most likely be > implemented via a central server (if nothing else, to take care that > nobody's cheating). > > For this type of application, where the end systems are already doing > data exchange that is not representable in SDP (the game itself), I > think a sensible architecture would be to pass the SDP offer/answer over > the data channel. This means that traffic latency for passing SDP is on > the same order as for media. Offer/answer over the data channel??? Slide 3 of your presentation talks about the signalling channel. Now, if you want to define a datachannel protocol that uses SDP syntax, fin= e, but please don't call it offer/answer :) Also, you would need to describe how the data channel protocol relates to n= egotiating being done on the signalling plane. >> First, it would cause heavy load on every entity that has to parse the S= DP, as they need to parse the whole message body, and then figure out what = has changed. > > Given that in such a specialized application, the only entity that has > to parse SDP is the central node - how much CPU time do you think SDP > parsing will take? (number of CPU-milliseconds?) I don't have numbers, but I can tell you that it is a relatively heavy proc= ess. And, it's not only about the parsing, but also about the processing of= the parsed result. In addition, are you actually negotiating anything, or are you simply "indi= cating"? >> Second, due to race conditions rules, SIP transaction rules etc, and *ot= her* usages of SDP offer/answer within the session, there is a high risk th= at SDP offers (not only those related to codec control) would be rejected. > > Why, given that it's a point-to-point exchange? Admitted, glare will > happen, and will have to be resolved in the usual ways (ROAP gave one > mechanism that the game protocol can adopt). Sure, there are procedures how to handle it. My point is that it may cause = bad user experience - espeically if more critical offers are rejected (e.g.= offers where you are adding new streams, doing un-hold etc). >> Offer/answer is a rather "heavy" mechanism, and I don't think it's inten= ded to be used in the suggested way. >Well.. the Arpanet was originally intended for connecting teletypes to >mainframes. It's proved to be useful in a few scenarios it was not origina= lly created for. >> Normally you would send one (or a few) offer/answer(s) during call estab= lishment, and between zero and a few during the session. >> >> Or, did I missunderstand something? >A specialized poker game is not intended to be interoperable with a >videophone? Let's not get stucked on the poker game use-case then. In general, if we think there will be use-cases which would trigger frequen= t offer/answers, I think it's the wrong approach. Regards, Christer= From harald@alvestrand.no Thu Aug 23 03:40:41 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E617121F8625 for ; Thu, 23 Aug 2012 03:40:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.34 X-Spam-Level: X-Spam-Status: No, score=-110.34 tagged_above=-999 required=5 tests=[AWL=0.259, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ZlBBWHfpAaD for ; Thu, 23 Aug 2012 03:40:41 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id C4FA321F8616 for ; Thu, 23 Aug 2012 03:40:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B419839E0CE; Thu, 23 Aug 2012 12:40:39 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BCrVBwIfbXiq; Thu, 23 Aug 2012 12:40:38 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:be30:5bff:fede:bcdc]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 56C0139E031; Thu, 23 Aug 2012 12:40:38 +0200 (CEST) Message-ID: <503608A5.6090304@alvestrand.no> Date: Thu, 23 Aug 2012 12:40:37 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: Christer Holmberg References: <7F2072F1E0DE894DA4B517B93C6A05853409FF2EE3@ESESSCMS0356.eemea.ericsson.se>, <5035F12F.9000608@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05853409FF2EF9@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05853409FF2EF9@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Codec control and SDP offer/answer frequency X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 23 Aug 2012 10:40:42 -0000 On 08/23/2012 11:38 AM, Christer Holmberg wrote: > Hi Harald, > >>> In Vancouver two proposals for codec were presented, one based on COP and one based on the SDP imageattr attribute. The result from the straw poll was that people preferred to move forward with the SDP based solution. >>> >>> When Harald presented his poker game example, he mentioned that there could be changes with a few seconds interval. >>> >>> For my clarification, does that mean that a UA would send SDP offer/answers every few second??? >>> >>> If so, I don't think that would create good results. >> I don't quite buy the analysis - details below. >> >> The example given (the "poker game") would almost certainly be a very >> specialized application, with no requirements for interworking (you >> can't dial into a game from a videophone), and would most likely be >> implemented via a central server (if nothing else, to take care that >> nobody's cheating). >> >> For this type of application, where the end systems are already doing >> data exchange that is not representable in SDP (the game itself), I >> think a sensible architecture would be to pass the SDP offer/answer over >> the data channel. This means that traffic latency for passing SDP is on >> the same order as for media. > Offer/answer over the data channel??? > > Slide 3 of your presentation talks about the signalling channel. > > Now, if you want to define a datachannel protocol that uses SDP syntax, fine, but please don't call it offer/answer :) > > Also, you would need to describe how the data channel protocol relates to negotiating being done on the signalling plane. The format of the signalling channel is defined to be outside the scope of the specification, so it's perfectly legitimate to use the data channel for that purpose - application decision! > >>> First, it would cause heavy load on every entity that has to parse the SDP, as they need to parse the whole message body, and then figure out what has changed. >> Given that in such a specialized application, the only entity that has >> to parse SDP is the central node - how much CPU time do you think SDP >> parsing will take? (number of CPU-milliseconds?) > I don't have numbers, but I can tell you that it is a relatively heavy process. And, it's not only about the parsing, but also about the processing of the parsed result. > > In addition, are you actually negotiating anything, or are you simply "indicating"? See draft-lennox - there may be negotiation going on, if we change the boundaries. I see the normal use of this feature to be a change in q values only. > > >>> Second, due to race conditions rules, SIP transaction rules etc, and *other* usages of SDP offer/answer within the session, there is a high risk that SDP offers (not only those related to codec control) would be rejected. >> Why, given that it's a point-to-point exchange? Admitted, glare will >> happen, and will have to be resolved in the usual ways (ROAP gave one >> mechanism that the game protocol can adopt). > Sure, there are procedures how to handle it. My point is that it may cause bad user experience - espeically if more critical offers are rejected (e.g. offers where you are adding new streams, doing un-hold etc). All state changes have to be negotiated in a way that makes sure they eventually resolve, no matter what they are. This is not a problem specific to resolution negotiation. > >>> Offer/answer is a rather "heavy" mechanism, and I don't think it's intended to be used in the suggested way. >> Well.. the Arpanet was originally intended for connecting teletypes to >> mainframes. It's proved to be useful in a few scenarios it was not originally created for. >>> Normally you would send one (or a few) offer/answer(s) during call establishment, and between zero and a few during the session. >>> >>> Or, did I missunderstand something? >> A specialized poker game is not intended to be interoperable with a >> videophone? > Let's not get stucked on the poker game use-case then. > > In general, if we think there will be use-cases which would trigger frequent offer/answers, I think it's the wrong approach. And I want to be a lot more specific before worrying. In the interworking case, I see that there can be issues, because existing systems have existing procedures - so I accept the theory that every-few-seconds offer/answer is a problem there. In the WebRTC application case, I want to see a specific problem before I start worrying. > > Regards, > > Christer From christer.holmberg@ericsson.com Thu Aug 23 04:05:24 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B1A121F8630 for ; Thu, 23 Aug 2012 04:05:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.172 X-Spam-Level: X-Spam-Status: No, score=-6.172 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qUNv9oDVjp8D for ; Thu, 23 Aug 2012 04:05:23 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 03AAA21F85FC for ; Thu, 23 Aug 2012 04:05:22 -0700 (PDT) X-AuditID: c1b4fb2d-b7fea6d000002ccb-8c-50360e71ee2b Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 78.E0.11467.17E06305; Thu, 23 Aug 2012 13:05:21 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.99]) by esessmw0247.eemea.ericsson.se ([153.88.115.93]) with mapi; Thu, 23 Aug 2012 13:05:21 +0200 From: Christer Holmberg To: 'Harald Alvestrand' Date: Thu, 23 Aug 2012 13:05:20 +0200 Thread-Topic: [rtcweb] Codec control and SDP offer/answer frequency Thread-Index: Ac2BG7154OESGpwxTXi4axRvR9+XcQAAXCvg Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585340A1E3A73@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05853409FF2EE3@ESESSCMS0356.eemea.ericsson.se>, <5035F12F.9000608@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05853409FF2EF9@ESESSCMS0356.eemea.ericsson.se> <503608A5.6090304@alvestrand.no> In-Reply-To: <503608A5.6090304@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrKLMWRmVeSWpSXmKPExsUyM+JvrW4hn1mAwd8F+hbH+rrYLNb+a2d3 YPK4MuEKq8eSJT+ZApiiuGxSUnMyy1KL9O0SuDK+LL/DVvBQu2LlwTfMDYy9yl2MnBwSAiYS G/4vYISwxSQu3FvP1sXIxSEkcIpR4tPLr8wQzgJGiZ/fzrB0MXJwsAlYSHT/0wZpEBHQk/jQ vAismVlAXeLO4nPsICUsAqoSLe9CQcLCAk4Sy573M0OUO0vcO7uVEaRERMBI4tdlT5Awr0C4 xKrdu1lAbCGBl4wSK5f7gJRwCuhKPD4oAxJmBLrs+6k1TBCLxCVuPZnPBHGxgMSSPeeZIWxR iZeP/7FC1ItK3GlfD3WYjsSC3Z/YIGxtiWULXzNDrBWUODnzCcsERrFZSMbOQtIyC0nLLCQt CxhZVjEK5yZm5qSXG+qlFmUmFxfn5+kVp25iBEbNwS2/dXcwnjoncohRmoNFSZyXK2m/v5BA emJJanZqakFqUXxRaU5q8SFGJg5OqQZG+7mXshomVXCsKD/5hu1p4YPt7zvPbeLXnD7lScSL ntt5rd81v++5vEtqNWPZ73pXY+76yx7idwvtNBXFfx/+Ih7p/SPKfHG07bM5Tx7/SnpqNMPJ 3y0uOGvulIyg+XoHTi/dyRu6VvpiU+rD1UZ+M9LOzOKaFv5uzYPTeR6RbYyl5jy+Fy03KbEU ZyQaajEXFScCAMgj8nZoAgAA Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Codec control and SDP offer/answer frequency X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 23 Aug 2012 11:05:24 -0000 Hi,=20 >>>> In Vancouver two proposals for codec were presented, one based on COP = and one based on the SDP imageattr attribute. The result from the straw pol= l was that people preferred to move forward with the SDP based solution. >>>> >>>> When Harald presented his poker game example, he mentioned that there = could be changes with a few seconds interval. >>>> >>>> For my clarification, does that mean that a UA would send SDP offer/an= swers every few second??? >>>> >>>> If so, I don't think that would create good results. >>>> I don't quite buy the analysis - details below. >>> >>> The example given (the "poker game") would almost certainly be a very=20 >>> specialized application, with no requirements for interworking (you=20 >>> can't dial into a game from a videophone), and would most likely be=20 >>> implemented via a central server (if nothing else, to take care that=20 >>> nobody's cheating). >>> >>> For this type of application, where the end systems are already doing=20 >>> data exchange that is not representable in SDP (the game itself), I=20 >>> think a sensible architecture would be to pass the SDP offer/answer=20 >>> over the data channel. This means that traffic latency for passing=20 >>> SDP is on the same order as for media. >> Offer/answer over the data channel??? >> >> Slide 3 of your presentation talks about the signalling channel. >> >> Now, if you want to define a datachannel protocol that uses SDP=20 >> syntax, fine, but please don't call it offer/answer :) >> >> Also, you would need to describe how the data channel protocol relates t= o negotiating being done on the signalling plane. > The format of the signalling channel is defined to be outside the scope o= f the specification, so it's perfectly legitimate to use the data channel f= or that purpose - application decision! Sure, applications can do whatever they want. But, I think it would be good to have a standardized mechanisms which works= for any application. AFAIK, that was the whole purpose of the discussion i= n Vancouver. >>>> First, it would cause heavy load on every entity that has to parse the= SDP, as they need to parse the whole message body, and then figure out wha= t has changed. >>> Given that in such a specialized application, the only entity that=20 >>> has to parse SDP is the central node - how much CPU time do you think=20 >>> SDP parsing will take? (number of CPU-milliseconds?) >> I don't have numbers, but I can tell you that it is a relatively heavy p= rocess. And, it's not only about the parsing, but also about the processing= of the parsed result. >> >> In addition, are you actually negotiating anything, or are you simply "i= ndicating"? > > See draft-lennox - there may be negotiation going on, if we change the bo= undaries. Sure - for which offer/answer IS a good mechanism, as I assume the boundari= es won't change that often. > I see the normal use of this feature to be a change in q values only. >> >> >>>> Second, due to race conditions rules, SIP transaction rules etc, and *= other* usages of SDP offer/answer within the=20 >>>> session, there is a high risk that SDP offers (not only those related = to codec control) would be rejected. >>> Why, given that it's a point-to-point exchange? Admitted, glare will=20 >>> happen, and will have to be resolved in the usual ways (ROAP gave one=20 >>> mechanism that the game protocol can adopt). >> Sure, there are procedures how to handle it. My point is that it may cau= se bad user experience - espeically if=20 >> more critical offers are rejected (e.g. offers where you are adding new = streams, doing un-hold etc). > All state changes have to be negotiated in a way that makes sure they eve= ntually resolve, no matter what=20 > they are. This is not a problem specific to resolution negotiation. Correct. But, if you can indicate resolution changes without affecting othe= r procedures, that makes the system more flexible. If you need to re-NEGOTIATE something, then I agree you very likely will ne= ed something like offer/answer. And, if you are talking about a data channel protocol, my issues may not be= valid. So, maybe I'm the only one who missunderstood your message in Vanco= uver, then :) >>>> Offer/answer is a rather "heavy" mechanism, and I don't think it's int= ended to be used in the suggested way. >>> Well.. the Arpanet was originally intended for connecting teletypes=20 >>> to mainframes. It's proved to be useful in a few scenarios it was not o= riginally created for. >>>> Normally you would send one (or a few) offer/answer(s) during call est= ablishment, and between zero and a few during the session. >>>> >>>> Or, did I missunderstand something? >>> A specialized poker game is not intended to be interoperable with a=20 >>> videophone? >> Let's not get stucked on the poker game use-case then. >> >> In general, if we think there will be use-cases which would trigger freq= uent offer/answers, I think it's the wrong approach. >> And I want to be a lot more specific before worrying. > In the interworking case, I see that there can be issues, because existin= g systems have existing procedures - so I accept the theory that every-few-= seconds offer/answer is a problem there. > > In the WebRTC application case, I want to see a specific problem before I= start worrying. I belive also CLUE may have usage for this mechanism, eventhough I don't th= ink there is any such formal decission made. Regards, Christer From harald@alvestrand.no Thu Aug 23 04:22:38 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3C0221F866A for ; Thu, 23 Aug 2012 04:22:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.35 X-Spam-Level: X-Spam-Status: No, score=-110.35 tagged_above=-999 required=5 tests=[AWL=0.249, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ygrEH6w3xmF for ; Thu, 23 Aug 2012 04:22:37 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 5023F21F863F for ; Thu, 23 Aug 2012 04:22:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id CF3B539E03B; Thu, 23 Aug 2012 13:22:34 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PPVtL32QQRd8; Thu, 23 Aug 2012 13:22:34 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:be30:5bff:fede:bcdc]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 034E739E031; Thu, 23 Aug 2012 13:22:33 +0200 (CEST) Message-ID: <50361279.3040204@alvestrand.no> Date: Thu, 23 Aug 2012 13:22:33 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: Christer Holmberg References: <7F2072F1E0DE894DA4B517B93C6A05853409FF2EE3@ESESSCMS0356.eemea.ericsson.se>, <5035F12F.9000608@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05853409FF2EF9@ESESSCMS0356.eemea.ericsson.se> <503608A5.6090304@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A0585340A1E3A73@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585340A1E3A73@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Codec control and SDP offer/answer frequency X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 23 Aug 2012 11:22:38 -0000 Clipping to a single issue.... On 08/23/2012 01:05 PM, Christer Holmberg wrote: > Also, you would need to describe how the data channel protocol relates to negotiating being done on the signalling plane. >> The format of the signalling channel is defined to be outside the scope of the specification, so it's perfectly legitimate to use the data channel for that purpose - application decision! > Sure, applications can do whatever they want. > > But, I think it would be good to have a standardized mechanisms which works for any application. AFAIK, that was the whole purpose of the discussion in Vancouver. > Since we've settled on using SDP at the UA/Application interface, representing the data in SDP is a valid way of describing that interface - thus indeed making it available for use by any application written to that interface. The particular worry you raised was how fast applications can do offer/answers - which is dependent on how their signalling channel is implemented, and how many intermediate nodes have to process the data. That's what I'm thinking will be different in the Pokerstars example than in a SIP-telephone-gateway example. From christer.holmberg@ericsson.com Thu Aug 23 08:11:25 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7776421F8517 for ; Thu, 23 Aug 2012 08:11:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.172 X-Spam-Level: X-Spam-Status: No, score=-6.172 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WS7Nik3mwzTf for ; Thu, 23 Aug 2012 08:11:24 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 4539221F84DD for ; Thu, 23 Aug 2012 08:11:23 -0700 (PDT) X-AuditID: c1b4fb25-b7f046d00000644c-c4-5036481a20e4 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 1F.53.25676.A1846305; Thu, 23 Aug 2012 17:11:22 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.99]) by esessmw0184.eemea.ericsson.se ([10.2.3.53]) with mapi; Thu, 23 Aug 2012 17:11:22 +0200 From: Christer Holmberg To: 'Harald Alvestrand' Date: Thu, 23 Aug 2012 17:11:21 +0200 Thread-Topic: [rtcweb] Codec control and SDP offer/answer frequency Thread-Index: Ac2BIZig5K57/dH1SXqcVpd62pSjVAAHuIog Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585340A1E3A7D@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05853409FF2EE3@ESESSCMS0356.eemea.ericsson.se>, <5035F12F.9000608@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05853409FF2EF9@ESESSCMS0356.eemea.ericsson.se> <503608A5.6090304@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A0585340A1E3A73@ESESSCMS0356.eemea.ericsson.se> <50361279.3040204@alvestrand.no> In-Reply-To: <50361279.3040204@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrBLMWRmVeSWpSXmKPExsUyM+Jvra6Uh1mAwYn9ZhbH+rrYLNb+a2d3 YPK4MuEKq8eSJT+ZApiiuGxSUnMyy1KL9O0SuDIunP7FXHCap2LPhs/MDYydXF2MnBwSAiYS 254sZYKwxSQu3FvP1sXIxSEkcIpRYvfiVewQzhxGib4t91m7GDk42AQsJLr/aYM0iAjoSXxo XsQIYjMLqEvcWXyOHcRmEVCVeLlsHthQYQEniWXP+5kh6p0l7p3dyghhG0n8WTobzOYVCJdY cOoZK8SuW0wS7Rcus4Ds4hTQleg66wtSwwh03PdTa5ggdolL3HoyH+poAYkle84zQ9iiEi8f /2OFqBeVuNO+Huo2HYkFuz+xQdjaEssWvmaG2CsocXLmE5YJjGKzkIydhaRlFpKWWUhaFjCy rGIUzk3MzEkvN9JLLcpMLi7Oz9MrTt3ECIydg1t+q+5gvHNO5BCjNAeLkjiv9dY9/kIC6Ykl qdmpqQWpRfFFpTmpxYcYmTg4pRoYC9K2rtCSX12eHdMYIRlhb7X9xc+vSkGP07+4Tu3NO3H2 6WKXO59bfVwtJ7CnsIjatc958sfg+r7Um+ejp+y9cYj5qeDlmNazq9ovbv77fLVP4O1Tb10n MH0zvLPo4p0Du3T3WfBclVbOamRQVemryVg/Q2DhQ8XyFwL1x79aGX4Me7bs73s+UyWW4oxE Qy3mouJEAFeoXgFrAgAA Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Codec control and SDP offer/answer frequency X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 23 Aug 2012 15:11:25 -0000 Hi,=20 >>>> Also, you would need to describe how the data channel protocol relates= to negotiating being done on the signalling plane. >>> The format of the signalling channel is defined to be outside the scope= of the specification, so it's perfectly legitimate to use the data channel= for that purpose - application decision! >> Sure, applications can do whatever they want. >> >> But, I think it would be good to have a standardized mechanisms which wo= rks for any application. AFAIK, that was the whole purpose of the discussio= n in Vancouver. >> > Since we've settled on using SDP at the UA/Application interface, Correct (eventhough someone in Seattle may have a different opinion ;) > representing the data in SDP is a valid way of describing that interface >- thus indeed making it available for use by any application written to th= at interface. Correct. > The particular worry you raised was how fast applications can do offer/an= swers - which is dependent on=20 > how their signalling channel is implemented, and how many intermediate no= des have to process the data. Correct. > That's what I'm thinking will be different in the Pokerstars example than= in a SIP-telephone-gateway example. I agree that the impacts are different - but I'd like to have a solution th= at works in all cases. So, if I understand you correctly: you suggest that the codec control infor= mation is transported using SDP/a=3Dimageattr "internally" (between app and= browser), but then people can send it over the wire however they want? Regards, Christer From harald@alvestrand.no Thu Aug 23 13:36:41 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92AF221F854A for ; Thu, 23 Aug 2012 13:36:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Fdkvh8i4qWq for ; Thu, 23 Aug 2012 13:36:41 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id DD95C21F8549 for ; Thu, 23 Aug 2012 13:36:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6B62439E0CE; Thu, 23 Aug 2012 22:36:39 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T3FUl7peGQnm; Thu, 23 Aug 2012 22:36:38 +0200 (CEST) Received: from [192.168.11.193] (c-56fbe555.03-217-73746f1.cust.bredbandsbolaget.se [85.229.251.86]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 8307439E03B; Thu, 23 Aug 2012 22:36:38 +0200 (CEST) Message-ID: <50369456.90605@alvestrand.no> Date: Thu, 23 Aug 2012 22:36:38 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: Christer Holmberg References: <7F2072F1E0DE894DA4B517B93C6A05853409FF2EE3@ESESSCMS0356.eemea.ericsson.se>, <5035F12F.9000608@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05853409FF2EF9@ESESSCMS0356.eemea.ericsson.se> <503608A5.6090304@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A0585340A1E3A73@ESESSCMS0356.eemea.ericsson.se> <50361279.3040204@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A0585340A1E3A7D@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585340A1E3A7D@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Codec control and SDP offer/answer frequency X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 23 Aug 2012 20:36:41 -0000 On 08/23/2012 05:11 PM, Christer Holmberg wrote: > Hi, > >>>>> Also, you would need to describe how the data channel protocol relates to negotiating being done on the signalling plane. >>>> The format of the signalling channel is defined to be outside the scope of the specification, so it's perfectly legitimate to use the data channel for that purpose - application decision! >>> Sure, applications can do whatever they want. >>> >>> But, I think it would be good to have a standardized mechanisms which works for any application. AFAIK, that was the whole purpose of the discussion in Vancouver. >>> >> Since we've settled on using SDP at the UA/Application interface, > Correct (eventhough someone in Seattle may have a different opinion ;) > >> representing the data in SDP is a valid way of describing that interface >> - thus indeed making it available for use by any application written to that interface. > Correct. > >> The particular worry you raised was how fast applications can do offer/answers - which is dependent on >> how their signalling channel is implemented, and how many intermediate nodes have to process the data. > Correct. > >> That's what I'm thinking will be different in the Pokerstars example than in a SIP-telephone-gateway example. > I agree that the impacts are different - but I'd like to have a solution that works in all cases. > > So, if I understand you correctly: you suggest that the codec control information is transported using SDP/a=imageattr "internally" (between app and browser), but then people can send it over the wire however they want? Yes. I believe that's the model we have agreed on. From Markus.Isomaki@nokia.com Thu Aug 23 14:00:13 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C490F21F859E for ; Thu, 23 Aug 2012 14:00:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nTuwJenwjMQE for ; Thu, 23 Aug 2012 14:00:13 -0700 (PDT) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id F03B221F8582 for ; Thu, 23 Aug 2012 14:00:12 -0700 (PDT) Received: from vaebh102.NOE.Nokia.com (vaebh102.europe.nokia.com [10.160.244.23]) by mgw-sa02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q7NKxx61003236; Thu, 23 Aug 2012 23:59:59 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.57]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 23 Aug 2012 23:59:59 +0300 Received: from 008-AM1MPN1-042.mgdnok.nokia.com ([169.254.2.220]) by 008-AM1MMR1-002.mgdnok.nokia.com ([65.54.30.57]) with mapi id 14.02.0283.004; Thu, 23 Aug 2012 22:59:58 +0200 From: To: , Thread-Topic: [rtcweb] Codec control and SDP offer/answer frequency Thread-Index: AQHNgW8HRNeyJMFktEekoJ61nDHCnJdn4IsA Date: Thu, 23 Aug 2012 20:59:57 +0000 Message-ID: References: <7F2072F1E0DE894DA4B517B93C6A05853409FF2EE3@ESESSCMS0356.eemea.ericsson.se>, <5035F12F.9000608@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05853409FF2EF9@ESESSCMS0356.eemea.ericsson.se> <503608A5.6090304@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A0585340A1E3A73@ESESSCMS0356.eemea.ericsson.se> <50361279.3040204@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A0585340A1E3A7D@ESESSCMS0356.eemea.ericsson.se> <50369456.90605@alvestrand.no> In-Reply-To: <50369456.90605@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.163.24.102] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 23 Aug 2012 20:59:59.0292 (UTC) FILETIME=[41BF3FC0:01CD8172] X-Nokia-AV: Clean Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Codec control and SDP offer/answer frequency X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 23 Aug 2012 21:00:13 -0000 Hi, Harald Alvestrand wrote: > >On 08/23/2012 05:11 PM, Christer Holmberg wrote: >> >> So, if I understand you correctly: you suggest that the codec control >information is transported using SDP/a=3Dimageattr "internally" (between a= pp >and browser), but then people can send it over the wire however they want? > >Yes. I believe that's the model we have agreed on. > I think that is fully in line with how SDP is treated in RTCWeb in general = (at least so far), so there does not seem to be anything special about this= case. Markus From lishitao@huawei.com Thu Aug 23 21:17:35 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E6CA21E8042 for ; Thu, 23 Aug 2012 21:17:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.169 X-Spam-Level: X-Spam-Status: No, score=-3.169 tagged_above=-999 required=5 tests=[AWL=3.430, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ix1EBTa1Eaec for ; Thu, 23 Aug 2012 21:17:34 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id AF2B921E8034 for ; Thu, 23 Aug 2012 21:17:34 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfwdlp03-ep.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath) with ESMTP id AJR01577; Thu, 23 Aug 2012 20:17:34 -0800 (PST) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 23 Aug 2012 21:10:55 -0700 Received: from SZXEML424-HUB.china.huawei.com (10.82.67.163) by dfweml404-hub.china.huawei.com (10.193.5.203) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 23 Aug 2012 21:10:52 -0700 Received: from SZXEML534-MBX.china.huawei.com ([169.254.2.70]) by szxeml424-hub.china.huawei.com ([10.82.67.163]) with mapi id 14.01.0323.003; Fri, 24 Aug 2012 12:10:45 +0800 From: Lishitao To: Randell Jesup , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Confirmation of consensus on audio codecs Thread-Index: AQHNe9LENUMF/Hj3nEmo2lnRJlNz25dj6efA///0R4CABIQsUA== Date: Fri, 24 Aug 2012 04:10:45 +0000 Message-ID: References: <9E2843EA-EBB9-40B3-898C-6B5216FAE7A5@cisco.com> <20330_1345535870_50333F7E_20330_3420_1_2842AD9A45C83B44B57635FD4831E60A029156@PEXCVZYM14.corporate.adroot.infra.ftgroup> <5033A2FF.4000603@jesup.org> In-Reply-To: <5033A2FF.4000603@jesup.org> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.73.37] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [rtcweb] Confirmation of consensus on audio codecs X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 24 Aug 2012 04:17:35 -0000 > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf > Of Randell Jesup > Sent: Tuesday, August 21, 2012 11:02 PM > To: rtcweb@ietf.org > Subject: Re: [rtcweb] Confirmation of consensus on audio codecs >=20 > > With respect to OPUS, it has currently no footprint on the market, its > implementation complexity and resulting costs are unknown, including with > respect to IPRs issues, and some performance aspects are still to be more > deeply assessed, like for instance quality with packet losses and jitter = which is a > key issue for usage over internet. >=20 > Opus was designed within the IETF specifically to handle usage over the > Internet better than existing codecs. > My understanding for choosing the MTI codec is to find the baseline so that= the negotiation can be successful,=20 We are not here to find the best one. If we consider the situation that G.711 has been widely used on the market,= mandating G.711 only as the baseline(MTI) is more appropriate shitao. From christer.holmberg@ericsson.com Thu Aug 23 23:22:39 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CD4821F8581 for ; Thu, 23 Aug 2012 23:22:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.173 X-Spam-Level: X-Spam-Status: No, score=-6.173 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mib6pW+8HG3U for ; Thu, 23 Aug 2012 23:22:38 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 35AF121F8577 for ; Thu, 23 Aug 2012 23:22:37 -0700 (PDT) X-AuditID: c1b4fb30-b7f7d6d0000042ea-b9-50371da8222d Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 62.D7.17130.8AD17305; Fri, 24 Aug 2012 08:22:32 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.99]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Fri, 24 Aug 2012 08:22:32 +0200 From: Christer Holmberg To: "Markus.Isomaki@nokia.com" , "harald@alvestrand.no" Date: Fri, 24 Aug 2012 08:18:37 +0200 Thread-Topic: [rtcweb] Codec control and SDP offer/answer frequency Thread-Index: AQHNgW8HRNeyJMFktEekoJ61nDHCnJdn4IsAgACdL6I= Message-ID: <7F2072F1E0DE894DA4B517B93C6A05853409FF2F11@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05853409FF2EE3@ESESSCMS0356.eemea.ericsson.se>, <5035F12F.9000608@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05853409FF2EF9@ESESSCMS0356.eemea.ericsson.se> <503608A5.6090304@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A0585340A1E3A73@ESESSCMS0356.eemea.ericsson.se> <50361279.3040204@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A0585340A1E3A7D@ESESSCMS0356.eemea.ericsson.se> <50369456.90605@alvestrand.no>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrMLMWRmVeSWpSXmKPExsUyM+Jvre4KWfMAg7Nf9SyO9XWxWZz/u4jN Yu2/dnYHZo8rE66weixZ8pPJ4+6tS0wBzFFcNimpOZllqUX6dglcGd0LtrIWNLFVfPqwg7mB 8TZLFyMnh4SAicSLL/fYIGwxiQv31gPZXBxCAqcYJdb0tjBDOAsYJW6uvcbaxcjBwSZgIdH9 TxukQUQgS+LepX5WEJtZQF3izuJz7CA2i4CqxMSHs8BsYQEniWXP+5kh6p0l7p3dyghhW0n0 Ln0AZvMKhEvsXr8TavE0Fok9s3+DNXMKhEl8aFvPBGIzAl33/dQaJohl4hK3nsxngrhaQGLJ nvPMELaoxMvH/1gh6kUl7rSvZ4So15FYsPsTG4StLbFs4WtmiMWCEidnPmGZwCg2C8nYWUha ZiFpmYWkZQEjyypG4dzEzJz0cnO91KLM5OLi/Dy94tRNjMCIOrjlt8EOxk33xQ4xSnOwKInz 6qnu9xcSSE8sSc1OTS1ILYovKs1JLT7EyMTBKdXAuCc3MOh7rfR2EzOP1mavCc9kOwz4+PN/ nVKR7D2z4d+WK0cCQzz0ZGS/6E6zFPpY/Fj6oe3VDrE160P5+CfP5T/cI89ivLj7UOOftZ/P /D0lnPSvcu2/Fi6lG/9nfw2Y9JvFjKd31VWlblduhVbmAvn+Iu2zq7eE+Lh3WJo9rRHVamX5 Z+OlxFKckWioxVxUnAgAYGItTHYCAAA= Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Codec control and SDP offer/answer frequency X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 24 Aug 2012 06:22:39 -0000 Hi, >>> So, if I understand you correctly: you suggest that the codec control >>information is transported using SDP/a=3Dimageattr "internally" (between = app >>and browser), but then people can send it over the wire however they want= ? >> >>Yes. I believe that's the model we have agreed on. >> > > I think that is fully in line with how SDP is treated in RTCWeb in genera= l (at least so far), so there does not seem to be anything special about th= is case. Fair enough. But, that means that IF we use SDP offer/answer on the wire, and that offer= /answer is not appropriate for codec control, we need to define another mec= hanism. (By "we" I don't necessarily mean the rtcweb wg, but the community in gener= al) Regards, Christer= From neils@vipadia.com Thu Aug 23 23:52:53 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E62F21F8493 for ; Thu, 23 Aug 2012 23:52:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XG0r+gQRywIL for ; Thu, 23 Aug 2012 23:52:53 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id F1EAA21F847D for ; Thu, 23 Aug 2012 23:52:51 -0700 (PDT) Received: by lbky2 with SMTP id y2so162861lbk.31 for ; Thu, 23 Aug 2012 23:52:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=RZkBDOfDbagn+y0TM4oOjTyVqWH6O6JL1SGJ3HMPXBo=; b=M/5APHfoo7N7JcCsxW3BAd3Sz4UZkSCFMkji1rTkIt2UH5+lmyHk2USDlIa38rPCCt 3GEdalYrQez2Y95A4NmrZD+3gpIEvjHxKeF7ianPLBghg5fk5ahD2MxjjpFs8vFXfGnT fNrf2HpKFkgTaPo+OotedT86M+rBpuHFH8U0Lpd2CVqoIoaL1cMnFmhwsBl1of8Heh74 WYhGPwQPrZ8kiiwAX15WDzWjeTz6yqVDnG55gD6iVtaVV+VLAwyv2PlhPnxUakdp7Fjq NCSAUWwtrIW2Z1SKfp2jQr7nfhTLCmpQ1g3XrwLlef8XHWn59abWwlONI/GulsUQFsU1 xo0A== MIME-Version: 1.0 Received: by 10.152.112.136 with SMTP id iq8mr4586896lab.18.1345791170358; Thu, 23 Aug 2012 23:52:50 -0700 (PDT) Sender: neils@vipadia.com Received: by 10.114.0.79 with HTTP; Thu, 23 Aug 2012 23:52:50 -0700 (PDT) In-Reply-To: References: <9E2843EA-EBB9-40B3-898C-6B5216FAE7A5@cisco.com> <20330_1345535870_50333F7E_20330_3420_1_2842AD9A45C83B44B57635FD4831E60A029156@PEXCVZYM14.corporate.adroot.infra.ftgroup> <5033A2FF.4000603@jesup.org> Date: Fri, 24 Aug 2012 07:52:50 +0100 X-Google-Sender-Auth: 64CfutaXPPsRqzvdIZvZnnXJS6w Message-ID: From: Neil Stratford To: Lishitao Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlQSVwNeW8nhFbjR/k6md/drxRyHZx1UOnr844yWrr55Y+qn/AGjswfcWEU42yiAXix3Sg3 Cc: Randell Jesup , "rtcweb@ietf.org" Subject: Re: [rtcweb] Confirmation of consensus on audio codecs X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 24 Aug 2012 06:52:54 -0000 On Fri, Aug 24, 2012 at 5:10 AM, Lishitao wrote: >> -----Original Message----- >> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf >> Of Randell Jesup >> Sent: Tuesday, August 21, 2012 11:02 PM >> To: rtcweb@ietf.org >> Subject: Re: [rtcweb] Confirmation of consensus on audio codecs >> >> > With respect to OPUS, it has currently no footprint on the market, its >> implementation complexity and resulting costs are unknown, including with >> respect to IPRs issues, and some performance aspects are still to be more >> deeply assessed, like for instance quality with packet losses and jitter which is a >> key issue for usage over internet. >> >> Opus was designed within the IETF specifically to handle usage over the >> Internet better than existing codecs. >> > > My understanding for choosing the MTI codec is to find the baseline so that the negotiation can be successful, > We are not here to find the best one. > > If we consider the situation that G.711 has been widely used on the market, mandating G.711 only as the baseline(MTI) is more appropriate > > shitao. This should not be a question purely of interop with legacy devices, but primarily one about what is the minimum level of interop that is acceptable for WebRTC to WebRTC negotiated calls. If G711 is the only MTI codec then we can easily end up in a situation where that is all we have available for cross browser WebRTC to WebRTC calls, which would greatly undermine the effort to replace browser plugins. Neil From ekr@rtfm.com Fri Aug 24 08:15:22 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6395021F86CB for ; Fri, 24 Aug 2012 08:15:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.847 X-Spam-Level: X-Spam-Status: No, score=-102.847 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SD1AWrxEP1Ep for ; Fri, 24 Aug 2012 08:15:21 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4A38621F86C9 for ; Fri, 24 Aug 2012 08:15:21 -0700 (PDT) Received: by eaai11 with SMTP id i11so591974eaa.31 for ; Fri, 24 Aug 2012 08:15:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:from:date:message-id:subject:to :content-type:x-gm-message-state; bh=gYJV6ZAMsPxQnjh9sBFVg8biwu3AHsxCpt+DPS1AonU=; b=UN9n88dPwOGE2eqC515SeJyBtF5rG8ibwc7FjaJ/a1X1ZSxaIS8s7hSftfSuxpZJoN QB9uqmC0Jm/MP2iZOs/nTnyA6snny3iUvvkwyKIaHETlNDXvGGf1qewzlXCRHxPzmU8B Wytbl6/MQPXIlwL1nOgdmFPU0LnCp2TV9/ZilH9Apxv2ahXkmgX0fWTBVbDL6Rx1dKxX avxuEWOzce9Nl/GtO/pECoIvVkkR3Am/15g6fCHXNhqDavRFDBbaA1CWMzNCc5WtzKuh ZFdMne9YMPE/LnzwuzSEDZCdUaxhLbkSqZOfR727SU+yzezHci2xI+InOsMjipGZNVaC jZKA== Received: by 10.14.202.131 with SMTP id d3mr8000342eeo.32.1345821320277; Fri, 24 Aug 2012 08:15:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.14.187.10 with HTTP; Fri, 24 Aug 2012 08:14:39 -0700 (PDT) X-Originating-IP: [74.95.2.173] From: Eric Rescorla Date: Fri, 24 Aug 2012 08:14:39 -0700 Message-ID: To: rtcweb@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQm2eWY4OBBOcweVpER102t+yQrX1MHOTiYMMzjA67Wz9+za6jlMMmqE6j8++NXDvDvZ0s7+ Subject: [rtcweb] Filling in details on "trickle ICE" X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 24 Aug 2012 15:15:22 -0000 I've been working on doing Firefox's trickle ICE implementation and have had to make a bunch of decisions that suggest to me that perhaps we need an update to RFC 5245 to specify exactly how trickle ICE behaves. Here are some of the things we need to resolve. WHEN CHECKS START RFC 5245 currently specifies that connectivity checks start upon receiving the offer/answer (See Section 5): When an agent receives an initial offer, it will check if the offerer supports ICE, determine its own role, gather candidates, prioritize them, choose default candidates, encode and send an answer, and for full implementations, form the check lists and begin connectivity checks. However, if you are trickling all your candidates, then this algorithm is no longer appropriate, since the check list will be empty, so we need a new algorithm here. There seem to be a number of natural algorithms here, including: (a) as soon as any check list is non-empty, start that media stream. (b) as soon as the first media stream has a non-empty check list start that media stream (c) as soon as all check lists are non-empty start the first media stream. Note that S 5.7.4 specifies that you are supposed to start with the first media stream, which is what makes (b) and (c) compelling. WHEN ICE ENDS 7.1.3.3 describes the conditions required to update the check list based on transaction completion: Regardless of whether the check was successful or failed, the completion of the transaction may require updating of check list and timer states. If all of the pairs in the check list are now either in the Failed or Succeeded state: o If there is not a pair in the valid list for each component of the media stream, the state of the check list is set to Failed. Consider the following case: - Alice and Bob are on different addresses which both use RFC 1918 space. - Alice sends Bob the candidate 10.0.0.10 as her first candidate at This just happens to correspond to an existing host on Bob's network. - Bob creates a check list consisting solely of 10.0.0.10 and starts checks. - Because 10.0.0.10 is a real host on Bob's network, it generates an ICMP error and per S 7.1.3.1 Bob marks the transaction as Failed: Unless I have missed something, Given the algorithm above, the check list now consists solely of Failed candidates and the valid list is now empty, so this causes the media stream to be Failed. If this is the only media stream, according to 8.1.2. the entire ICE process is now marked as Failed. What's letting this happen is a race condition between candidates arriving and checks failing. I suspect that there are others, so we probably need some way to handle these cases. WHEN NEW TRICKLE CANDIDATES CAN BE PROCESSED A related question is when new trickle candidates can be processed. Say that a new candidate is received when a stream has a nominated candidate on the valid list? Do we add a new candidate to the list? Note that S 8.1.2 would ordinarily have us stopping checks on all other extant candidates pairs. HOW DO OTHER MEDIA STREAMS GET UNFROZEN Say I finish checks on one stream but another stream successfully. Ordinarily, I would start to unfreeze other check lists, but what if those are empty? How do they get unfrozen when candidates come in? INTERACTION WITH NON-TRICKLE ICE I'm concerned about the potential interactions between trickle ICE and non trickle ICE. Obviously, an extant ICE implementation can only handle getting all the candidates at once, so in order to have interop we need to hold all the candidates until we get the "null" finished candidate indication. But this means that in the case where the non-trickle version is the offerer, then checks aren't performed simultaneously. Consider the following case: - Alice is a non-trickle endpoint - Bob is a trickle endpoint - Alice and Bob are behind standard address-dependent filtering NATs - Bob has two STUN servers but one is down. - The JS holds off on sending Bob's offer to Alice until all the candidates are in. (Which, as I say above, is I think mandatory). I believe we get the following behavior. Alice Alice NAT Bob NAT Bob Bob STUN 1 Bob STUN 2 OFFER ------------------------------------------------------> BINDING REQUEST -> BINDING REQUEST --------------------------> <- BINDING RESPONSE onicecandidate(...) X <----------------------- CONNECTIVITY CHECK BINDING REQUEST (RT) ---------------------> X <------------------ CONNECTIVITY CHECK (RT) ... [Give up on STUN 2] onicecandidate(null) /---------------------- ANSWER / [Give up on CONNECTIVITY CHECK; ICE fails] <------------------------------/ The key thing here is that if the STUN timers for connectivity checks and for initial binding requests are similar, then Bob's checks can fail before Alice has time to open up a pinhole. This doesn't happen in regular ICE because the checks are synched in each direction. I suspect that this list is incomplete, but I think it's enough to suggest that there may be some details in trickle ICE that need to at least be documented and perhaps investigated/resolved. To the chairs: can you provide some guidance as to how to proceed with this discussion, what forum it should be discussed in, etc.? Thanks, -Ekr From fluffy@iii.ca Fri Aug 24 08:26:10 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E813E21F8668 for ; Fri, 24 Aug 2012 08:26:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i17FgpnX1k1O for ; Fri, 24 Aug 2012 08:26:10 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 7787321F85F3 for ; Fri, 24 Aug 2012 08:26:10 -0700 (PDT) Received: from dhcp-171-68-20-44.cisco.com (unknown [171.68.20.44]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id AC3FD50A85; Fri, 24 Aug 2012 11:26:03 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: Cullen Jennings In-Reply-To: Date: Fri, 24 Aug 2012 08:26:07 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <11902D72-E124-4986-96B7-CF61BBF74E21@iii.ca> References: To: Eric Rescorla X-Mailer: Apple Mail (2.1278) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Filling in details on "trickle ICE" - where to do this work X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 24 Aug 2012 15:26:11 -0000 >=20 > To the chairs: can you provide some guidance as to how to proceed with > this discussion, what forum it should be discussed in, etc.? With my chair hat on here=85. this work clearly needs to change some = stuff in RFC 5245 (the ICE spec) which was done in mmusic WG. So I think = the default location for updating it is probably the mmusic WG. I'll = ping the AD's and chairs but I think unless we here something different, = mmusic is the place for this. Cullen From martin.thomson@gmail.com Fri Aug 24 08:55:07 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30FD421F86B0 for ; Fri, 24 Aug 2012 08:55:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.922 X-Spam-Level: X-Spam-Status: No, score=-3.922 tagged_above=-999 required=5 tests=[AWL=-0.323, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tsmI2L9PX6WG for ; Fri, 24 Aug 2012 08:55:03 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id E41FD21F869A for ; Fri, 24 Aug 2012 08:55:02 -0700 (PDT) Received: by lbky2 with SMTP id y2so484753lbk.31 for ; Fri, 24 Aug 2012 08:55:01 -0700 (PDT) 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=P6k/SrDHjIKlhXoe1YKKABY8CRrt6eEUixRBup3uZnM=; b=BkQsdRrAY65o+eYXxtm7v+bBEJ8Ta/xMTI7n45iKvIqil7AOFSJaisbaBz6fWgpXfO mZd91mlraBZS2ZAkzoeD2vTnIhfjLSPHdeeWcEXEysU1nTkZxqhW4LoULuz4lq5Q14/O fcKFwDqtI+g2JtT9QtAbUwF83t2qoP6gjDaG9EcIQVx+m0DRsjJ8kh8k0H6Tr/4JANsv iephty3UJZTG9lLWRFFYqpDOB/pzyUB83MWeJ6HTSkTmO07MTK/MWFAwbWwriJ8wojSS 5oqJ2d/QAbeFmYVgHwbttQLDUgyfOOUKTHT21c15w/Pi1tS7J4aZk/W6pgygLgIl8iQZ Jupg== MIME-Version: 1.0 Received: by 10.152.123.206 with SMTP id mc14mr6328677lab.33.1345823701808; Fri, 24 Aug 2012 08:55:01 -0700 (PDT) Received: by 10.112.41.193 with HTTP; Fri, 24 Aug 2012 08:55:01 -0700 (PDT) In-Reply-To: References: Date: Fri, 24 Aug 2012 08:55:01 -0700 Message-ID: From: Martin Thomson To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Filling in details on "trickle ICE" X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 24 Aug 2012 15:55:07 -0000 On 24 August 2012 08:14, Eric Rescorla wrote: > I've been working on doing Firefox's trickle ICE implementation and > have had to make a bunch of decisions that suggest to me that perhaps > we need an update to RFC 5245 to specify exactly how trickle ICE > behaves. Here are some of the things we need to resolve. These are not necessarily interoperability issues. You can solve all of these problems without creating another RFC. You make the decision to start and stop, succeed or fail, nominate or leave. That decision might be guided by an RFC, but you are responsible for what your code does. ...unless you consider it impossible to take actions unless those actions have the blessing of RFC5245. --Martin From ekr@rtfm.com Fri Aug 24 09:00:16 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F0B121F8735 for ; Fri, 24 Aug 2012 09:00:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.85 X-Spam-Level: X-Spam-Status: No, score=-102.85 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GI5Qghg5Cxhh for ; Fri, 24 Aug 2012 09:00:14 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9A03D21F8752 for ; Fri, 24 Aug 2012 09:00:14 -0700 (PDT) Received: by eekb45 with SMTP id b45so768739eek.31 for ; Fri, 24 Aug 2012 09:00:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=dQFLTH6VPHjmSGUln2KuA6zWvkPx6OJCU7gxZbqPuFU=; b=ikmKh/CBHQIRq6DEsZWClAgMjR781F3kgpTffn1FU7P5PeBvRhWNBTOA6wtDskL7WS qw+GebFjv7wgRO+qrssgbZ16RQj8HkhVc1PHPoMhLSQWIR6TiuYsuwOKXT0OxrThMt13 dSrnUajQCVCRa7i32LUDJN7i0TgpBACKZC6Ed/X9DNeQOsgftf5jaPXipbRqQtr0EdQj wxtRzC8Ho8+GuzWUCjZwxz069BCYTT0Jn5Mv1tzVFMi/bf8bHCyxZY7mvqoGN5Cevo8P ajdryGsfg7Aamd/DLJZwIezHaqtRGsZePy5QqC0nZzz0R/x+HJC3bgauAxy8gZY46NKq 6SXw== Received: by 10.14.202.131 with SMTP id d3mr8193219eeo.32.1345824013636; Fri, 24 Aug 2012 09:00:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.14.187.10 with HTTP; Fri, 24 Aug 2012 08:59:33 -0700 (PDT) X-Originating-IP: [74.95.2.169] In-Reply-To: References: From: Eric Rescorla Date: Fri, 24 Aug 2012 08:59:33 -0700 Message-ID: To: Martin Thomson Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQk+aJBjun90lhB7R+LwLW6hUtoP7w4aS+CpGunHAJD9QNgtKy36LbORNhQqULizEeUkiaOP Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Filling in details on "trickle ICE" X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 24 Aug 2012 16:00:16 -0000 On Fri, Aug 24, 2012 at 8:55 AM, Martin Thomson wrote: > On 24 August 2012 08:14, Eric Rescorla wrote: >> I've been working on doing Firefox's trickle ICE implementation and >> have had to make a bunch of decisions that suggest to me that perhaps >> we need an update to RFC 5245 to specify exactly how trickle ICE >> behaves. Here are some of the things we need to resolve. > > These are not necessarily interoperability issues. You can solve all > of these problems without creating another RFC. > > You make the decision to start and stop, succeed or fail, nominate or > leave. That decision might be guided by an RFC, but you are > responsible for what your code does. I suppose it depends on whether you think it's important for independently developed Web applications and/or softphones to be able to talk to each other. > ...unless you consider it impossible to take actions unless those > actions have the blessing of RFC5245. Not at all. We could take actions blessed by other RFCs. -Ekr From martin.thomson@gmail.com Fri Aug 24 09:12:27 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 440DB21F8686 for ; Fri, 24 Aug 2012 09:12:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.918 X-Spam-Level: X-Spam-Status: No, score=-3.918 tagged_above=-999 required=5 tests=[AWL=-0.319, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p8u0YK3oR3uX for ; Fri, 24 Aug 2012 09:12:26 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7B41F21F8766 for ; Fri, 24 Aug 2012 09:12:26 -0700 (PDT) Received: by lbky2 with SMTP id y2so495564lbk.31 for ; Fri, 24 Aug 2012 09:12:25 -0700 (PDT) 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=3CUatIJrA47Pzr+WJrUeOx5biLvdLc5HRvUuJHQoRmw=; b=KwRWgve4l3ox6AqewPrS4vEds2nnsuh1nIdZlg1ILWsL8dRTITfKBBJMCck+abcVPd tUK4fcWnGasTEr+JGUCifRfaxJbED1wjcnDD6PrlCxVZeKHvJk8AnGQqACxedNornG18 qjAnNyvtJrszmQ4xM7iD/QtWwa5Y0OYT3eMJMRn3CkQWNcBUeb0BVG4lIIJ44luWgMnO TVqBF3yCNRI792x98xBzXCtbza3ZMYbEhEAxuADF4njMMY5ivWdHWnWBQZrAd8myjfcN H3m7sXPIAbBraLnDyYWFjPiiKnUYhAZGGybizZHLBJrAEQyN+U6DCnNpaKmw5LHsMKI+ mgGw== MIME-Version: 1.0 Received: by 10.112.88.34 with SMTP id bd2mr2866482lbb.33.1345824745346; Fri, 24 Aug 2012 09:12:25 -0700 (PDT) Received: by 10.112.41.193 with HTTP; Fri, 24 Aug 2012 09:12:25 -0700 (PDT) In-Reply-To: References: Date: Fri, 24 Aug 2012 09:12:25 -0700 Message-ID: From: Martin Thomson To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Filling in details on "trickle ICE" X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 24 Aug 2012 16:12:27 -0000 On 24 August 2012 08:59, Eric Rescorla wrote: > On Fri, Aug 24, 2012 at 8:55 AM, Martin Thomson > wrote: > I suppose it depends on whether you think it's important for > independently developed Web applications and/or softphones > to be able to talk to each other. Maybe I needed to be clearer: >> These are not necessarily interoperability issues. You can solve all >> of these problems without creating another RFC. I'd be interested in hearing the interoperability reason for, for example, giving up on a particular component instead of waiting for additional candidates. What effect does that have on interoperability. It's fairly clear that if you are trickling candidates out, then an strictly conforming implementation of RFC 5245 on the other end could fail. That's just a reason to not trickle at all. --Martin From ekr@rtfm.com Fri Aug 24 09:43:23 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1BD821F860E for ; Fri, 24 Aug 2012 09:43:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.853 X-Spam-Level: X-Spam-Status: No, score=-102.853 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3QIqKd0gDq-i for ; Fri, 24 Aug 2012 09:43:22 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9296221F85AA for ; Fri, 24 Aug 2012 09:43:21 -0700 (PDT) Received: by eekb45 with SMTP id b45so785382eek.31 for ; Fri, 24 Aug 2012 09:43:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=saEx9CBc8BMjHFglZ6E2PDqbZAJCzCI0RFaInsZathU=; b=Be/egjCghm1VSDOPBEXg0iM0z/wzRU3RMKjPtBeQNnAhBu5VYfVGSvvdl6SCoWM+2b XiwIcjUAETvyoyDl0uUi1H6L+sDY6xZeuLD8BgOBtyxBeUdQ6iacn+yD9emvOis8pIR2 H3KycgEORRcC8pv0DqIUedDEF2V56vcq0rsy5VezC4mU9KwjRfT5YwNoex2dZehVQCbg pdYejE0rkb0sSU+KCrb5X1IS+nota54hCQUJHsmpx5cdfgJjILha1XpylaE8NYXZiM0H ZXulsOSG1+3+lbd7bTW4mkdOMS/zSmB6DBRax+CyB+iP+bONDjkQ+KPr/t1+BQ7gqQbS NcDA== Received: by 10.14.206.201 with SMTP id l49mr8457468eeo.3.1345826600575; Fri, 24 Aug 2012 09:43:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.14.187.10 with HTTP; Fri, 24 Aug 2012 09:42:40 -0700 (PDT) X-Originating-IP: [74.95.2.169] In-Reply-To: References: From: Eric Rescorla Date: Fri, 24 Aug 2012 09:42:40 -0700 Message-ID: To: Martin Thomson Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkY9yGQS5Y/SuJHILhcDToQuf2NuMetF+LVKYkZGzjqdCZOs4kYSbpUaqw5qKla6nBu07KW Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Filling in details on "trickle ICE" X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 24 Aug 2012 16:43:23 -0000 On Fri, Aug 24, 2012 at 9:12 AM, Martin Thomson wrote: > On 24 August 2012 08:59, Eric Rescorla wrote: >> On Fri, Aug 24, 2012 at 8:55 AM, Martin Thomson >> wrote: >> I suppose it depends on whether you think it's important for >> independently developed Web applications and/or softphones >> to be able to talk to each other. > > Maybe I needed to be clearer: > >>> These are not necessarily interoperability issues. You can solve all >>> of these problems without creating another RFC. > > I'd be interested in hearing the interoperability reason for, for > example, giving up on a particular component instead of waiting for > additional candidates. What effect does that have on > interoperability. I'm not following what you are saying here. Ignoring the question of non-trickle (i.e., strict RFC 5245) endpoints, if you are a trickle endpoint that gives up under conditions when RFC 5245 says you should give up, you are likely to have problems. You don't think it's worth writing that down somewhere more permanent/definitive than an email to the mailing list? -Ekr From martin.thomson@gmail.com Fri Aug 24 09:56:12 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 327A921F8705 for ; Fri, 24 Aug 2012 09:56:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.914 X-Spam-Level: X-Spam-Status: No, score=-3.914 tagged_above=-999 required=5 tests=[AWL=-0.315, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AjipVWZGeeWf for ; Fri, 24 Aug 2012 09:56:11 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id CA67C21F86EC for ; Fri, 24 Aug 2012 09:56:10 -0700 (PDT) Received: by lbky2 with SMTP id y2so521484lbk.31 for ; Fri, 24 Aug 2012 09:56:09 -0700 (PDT) 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=TDTV6aOw28vghvfz7L/Qqm+3mRlMvAYJYGENqc9tU5I=; b=UTaTdpvATL0vsO1/3miNk/6zrxQ0/873j4M8YPeeSX25Mpsnq2MHIoRvaM+mgyxyr8 6uMZ5Rrd7LFMLcwf1wGi5Gu+Dw8NhyQXsmmE/X87zzszr6fRBqrAa8pSudyKsV7bmCJR fMtnjOhIE0lBs9euQwRQuLT1OeqHYlnhaKlYf4OmA1PZSgAjMCTr0HFsXBerGXkcUdrB LVR/Hg41tfGjlx6E5Ef50nOUt4D9vtUFB/DEJV7Z+q6Q2Rqf+OuLkXq3SC0hrwoF9o0s UTZv5DSKnBigvxnUMEMu5nfoafzjoyzeGLKJ21tl4iv0/BwwBvk11C/KqAK731vB0UdQ YgLw== MIME-Version: 1.0 Received: by 10.112.83.97 with SMTP id p1mr2966747lby.94.1345827369588; Fri, 24 Aug 2012 09:56:09 -0700 (PDT) Received: by 10.112.41.193 with HTTP; Fri, 24 Aug 2012 09:56:09 -0700 (PDT) In-Reply-To: References: Date: Fri, 24 Aug 2012 09:56:09 -0700 Message-ID: From: Martin Thomson To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Filling in details on "trickle ICE" X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 24 Aug 2012 16:56:12 -0000 On 24 August 2012 09:42, Eric Rescorla wrote: > I'm not following what you are saying here. Ignoring the question of > non-trickle (i.e., strict RFC 5245) endpoints, if you are a trickle endpoint > that gives up under conditions when RFC 5245 says you should give > up, you are likely to have problems. If you are a trickle endpoint, then you are not implementing RFC 5245. RFC 5245 might not explicitly exclude the possibility, but it is certainly implicit, as the problems you cite in your email attest. What I think we want to with trickle is to create a new method. That method is only like RFC 5245 to the extent that it shares some properties: the good parts. > You don't think it's worth writing > that down somewhere more permanent/definitive than an email > to the mailing list? Only if it addresses a specific interoperability need does it need to be in an RFC. From fluffy@iii.ca Fri Aug 24 11:16:43 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EDCE21F85F4 for ; Fri, 24 Aug 2012 11:16:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.469 X-Spam-Level: X-Spam-Status: No, score=-2.469 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LY-+yRk5wM-K for ; Fri, 24 Aug 2012 11:16:40 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id D142321F85B4 for ; Fri, 24 Aug 2012 11:16:40 -0700 (PDT) Received: from sjc-vpn6-639.cisco.com (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id ABEAD22E256; Fri, 24 Aug 2012 14:16:32 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: Date: Fri, 24 Aug 2012 11:16:36 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3B8DB12B-ABB3-4AC2-A0A0-93DC62C619D3@iii.ca> References: To: Martin Thomson X-Mailer: Apple Mail (2.1278) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Filling in details on "trickle ICE" X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 24 Aug 2012 18:16:44 -0000 I'm confused on what you are trying to say. Are you saying=20 1) we don't need trickle ICE 2) we can do trickily ICE but no standards need to be written for two = different devices to do trickle ICE On Aug 24, 2012, at 9:56 , Martin Thomson wrote: > On 24 August 2012 09:42, Eric Rescorla wrote: >> I'm not following what you are saying here. Ignoring the question of >> non-trickle (i.e., strict RFC 5245) endpoints, if you are a trickle = endpoint >> that gives up under conditions when RFC 5245 says you should give >> up, you are likely to have problems. >=20 > If you are a trickle endpoint, then you are not implementing RFC 5245. > RFC 5245 might not explicitly exclude the possibility, but it is > certainly implicit, as the problems you cite in your email attest. >=20 > What I think we want to with trickle is to create a new method. That > method is only like RFC 5245 to the extent that it shares some > properties: the good parts. >=20 >> You don't think it's worth writing >> that down somewhere more permanent/definitive than an email >> to the mailing list? >=20 > Only if it addresses a specific interoperability need does it need to > be in an RFC. > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From martin.thomson@gmail.com Fri Aug 24 14:22:43 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BF1E21F8499 for ; Fri, 24 Aug 2012 14:22:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.91 X-Spam-Level: X-Spam-Status: No, score=-3.91 tagged_above=-999 required=5 tests=[AWL=-0.311, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TkKQq8IEhEsE for ; Fri, 24 Aug 2012 14:22:42 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5772021F8496 for ; Fri, 24 Aug 2012 14:22:42 -0700 (PDT) Received: by lbky2 with SMTP id y2so659023lbk.31 for ; Fri, 24 Aug 2012 14:22:41 -0700 (PDT) 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=3Ldw0lE2v8FgLUhwvkiefAGGxglQwYWLYKx7kxqRqUE=; b=vvLcycYQvqf/rEoriuyl1s+EVkpBVb54UvQ1d/IJ92pZkeB9InvtRtBYPypnuzit8g LpTBNSRKx1yKlD8KRp9yVFiK34se40xAj2EOLahTGz9qu6XAdKY5p5rafzb3rdw9PYtY hGNyt6erL+HVJO4oMBeXB5f6vnjU2DEueb1HTzwb5VhBTFhAwQUs1tdfQuzEtRsSbret 0tdW6N8V3IHMLUX19W1laDdlWpYmE7tx+5Yqp5cQsU4PeB7KtXxtDx+G0zZ4kq/BuPOW mTeVmg9O1hOkQr2sAp+WKrJRwR2PhbHm0N8yQP29amONUQJ8PohJrb+2FALtsz0sy0sj l72w== MIME-Version: 1.0 Received: by 10.152.124.76 with SMTP id mg12mr7158880lab.10.1345843361188; Fri, 24 Aug 2012 14:22:41 -0700 (PDT) Received: by 10.112.41.193 with HTTP; Fri, 24 Aug 2012 14:22:41 -0700 (PDT) In-Reply-To: <3B8DB12B-ABB3-4AC2-A0A0-93DC62C619D3@iii.ca> References: <3B8DB12B-ABB3-4AC2-A0A0-93DC62C619D3@iii.ca> Date: Fri, 24 Aug 2012 14:22:41 -0700 Message-ID: From: Martin Thomson To: Cullen Jennings Content-Type: text/plain; charset=UTF-8 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Filling in details on "trickle ICE" X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 24 Aug 2012 21:22:43 -0000 On 24 August 2012 11:16, Cullen Jennings wrote: > > I'm confused on what you are trying to say. Are you saying > > 1) we don't need trickle ICE > > 2) we can do trickily ICE but no standards need to be written for two different devices to do trickle ICE It's just 2) Trickle candidates is a *new thing*, a new problem that needs to be solved. It's fairly clear that trickling is an optimization that was never considered in the design of ICE. We can solve the problem by writing an RFC, but you can also write fewer standards and enable the same outcome. An RFC would specify how this differs from ICE and what new behaviours are expected from endpoints. That RFC would also describe how implementations would discover if peers support the new behaviour so that they don't do things that would surprise or break implementations that did not. The alternative is to recognize that ICE specifies a number of features that are really, really important, both from an interoperability and a security standpoint: The use of STUN Binding requests to gather server reflexive addresses. The use of TURN to allocate TURN relays. The use of STUN Binding requests to establish connectivity and consent. Constraints over how checks can be sent (which are actually not all suitable in this context for other reasons). A way to resolve the problem of who performs candidate pair selection. Then ICE has a bunch of really useful advice on what implementations might do: gather candidates, prioritize them, check them, retry checks, track those that succeed, etc... None of that is really necessary, just super handy. The signalling stuff in ICE is not relevant to the rtcweb architecture. So we can ignore that part. WebRTC decided to use it, but that's their problem. The most invasive thing that ICE does is describe a specific algorithm in some detail. Implicit in this algorithm is the fact that all candidates have to be signaled together. This is also stuff that we don't *need* in rtcweb. This might have been useful when you use RFCs to describe every facet of your application, but it is in fact unnecessary for applications of the sort that exist in rtcweb. Many of these applications want things like trickle candidates, which can give better session initialization performance. Many of these will have code on both endpoints. Obviously, applications that want to interoperate with ICE implementations will have to play nice with ICE. But this is usually known a priori. Building signaling for this is presumptuous. I understand how someone might conclude that you need to standardize this behaviour. It depends on what preconceptions you have. If you wanted to port trickle candidates to your SIP PBX, then I can see how the standardization option might seem attractive. The Microsoft API proposal makes all of this possible by only taking the really important stuff from RFC 5245. --Martin From ted.ietf@gmail.com Fri Aug 24 15:04:49 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 843F421F85C4 for ; Fri, 24 Aug 2012 15:04:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.903 X-Spam-Level: X-Spam-Status: No, score=-3.903 tagged_above=-999 required=5 tests=[AWL=-0.304, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bd2uN4sRPwlA for ; Fri, 24 Aug 2012 15:04:47 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id AEC7121F8608 for ; Fri, 24 Aug 2012 15:04:47 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so2898083vbb.31 for ; Fri, 24 Aug 2012 15:04:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=jPiNg4P7+Iks+Ih8EamYQSnN0noH61P7iv+LZZOddj8=; b=kOSOPLYAnsyDqB6+AfH5wvDqYwGtDIxng+Gcpi23AS1p0uTMmwjmILnfgW9DY5m+Hb 9akHPpidnxCmYXian/dWQomVJfm2BAndjl9NvKGOB7IAh4zZ/D2lwnH++x31H3hMz2wg A9Q/H54kZ0RBd0Ypksn2oiKMu5YsL0aIWxKnVMd9Q0qMENoJA9kOA6EzHAXP5OinkqWd rgreAnWKfiKfl2qpxzg5wyKn8T7JomAoljO9lq/IMzwTpLH2rcWZBdwGmhawvKBXLHtF aZyr2hyMSG5zpQHRAPmM/pgjuFf3HMzfc6qpsVH2wyJFOsoF5MTQKlHvFL+pU0nrKwss DTWQ== MIME-Version: 1.0 Received: by 10.221.13.72 with SMTP id pl8mr5924677vcb.5.1345845887163; Fri, 24 Aug 2012 15:04:47 -0700 (PDT) Received: by 10.58.228.232 with HTTP; Fri, 24 Aug 2012 15:04:47 -0700 (PDT) Date: Fri, 24 Aug 2012 15:04:47 -0700 Message-ID: From: Ted Hardie To: rtcweb@ietf.org Content-Type: multipart/mixed; boundary=bcaec54d4b0206dd5904c80a2a33 Subject: [rtcweb] Please review: draft minutes X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 24 Aug 2012 22:04:49 -0000 --bcaec54d4b0206dd5904c80a2a33 Content-Type: text/plain; charset=ISO-8859-1 Additions and corrections to these would be welcome; they will be posted (as draft) from Wednesday of next week. Thanks to our note takers: Christer for Day 1 and Brian for Day 2. Ted --bcaec54d4b0206dd5904c80a2a33 Content-Type: text/plain; charset=UTF-8; name="RTCWEBMinutes.txt" Content-Disposition: attachment; filename="RTCWEBMinutes.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_h69tvgbh0 77u/TWludXRlcyBmb3IgUlRDV0VCIElFVEYgODQNClRlZCBIYXJkaWUsIEN1bGxlbiBKZW5uaW5n cywgTWFnbnVzIFdlc3Rlcmx1bmQgQ2hhaXJzDQpBZ2VuZGE6IGh0dHA6Ly93d3cuaWV0Zi5vcmcv cHJvY2VlZGluZ3MvODQvYWdlbmRhL2FnZW5kYS04NC1ydGN3ZWINClByZXNlbnRhdGlvbnM6IGh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbWVldGluZy84NC9tYXRlcmlhbHMuaHRtbCNSVENX RUINCkphYmJlciBsb2dzOiBodHRwOi8vd3d3LmlldGYub3JnL2phYmJlci9sb2dzL3J0Y3dlYi8N ClJlY29yZGluZ3M6IGh0dHA6Ly9pZXRmODQuY29uZi5tZWV0ZWNoby5jb20vaW5kZXgucGhwL1Jl Y29yZGVkX1Nlc3Npb25zI0lFVEY4NF9SVENXRUJfSQ0KaHR0cDovL2lldGY4NC5jb25mLm1lZXRl Y2hvLmNvbS9pbmRleC5waHAvUmVjb3JkZWRfU2Vzc2lvbnMjSUVURjg0X1JUQ1dFQl8yDQpOb3Rl IHRha2VyczogIENocmlzdGVyIEhvbG1iZXJnLCBCcmlhbiBSb3Nlbg0KDQoNCkRheSAxOg0KDQoN CiBUb3BpYzogIENvZGVjIGNvbnRyb2wgDQoNCg0KIFByZXNlbnRlcjogIE1hZ251cyBXZXN0ZXJs dW5kDQogUmVsYXRlZCBkcmFmdDogZHJhZnQtd2VzdGVybHVuZC1hdnRleHQtY29kZWMtb3BlcmF0 aW9uLXBvaW50LTAwDQogDQpOdXRzaGVsbDogdXNlIFNEUCB0byBuZWdvdGlhdGUgdXBwZXIgYm91 bmRhcmllcyAoYmFuZHdpZHRoIGV0YykgZm9yIG1lZGlhLCBhbmQgdGhlbiB1c2UgbWVkaWEgcGxh bmUgc2lnbmFsaW5nLCB1c2luZyB0aGUgQ09QIChkcmFmdC13ZXN0ZXJsdW5kLWF2dGV4dC1jb2Rl Yy1vcGVyYXRpb24tcG9pbnQtMDApIHByb3RvY29sLiBPcGVyYXRpb25zIGFyZSBkb25lIHBlciBT U1JDLg0KDQoNClByZXNlbnRlcjogIEhhcmFsZCBBbHZlc3RyYW5kDQpSZWxhdGVkIGRyYWZ0OiBk cmFmdC1hbHZlc3RyYW5kLXJ0Y3dlYi1yZXNvbHV0aW9uDQoNCg0KTnV0c2hlbGw6IEEgc29sdXRp b24gYmFzZWQgb24gdGhlIFJGQyA2MjM2IChTRFAg4oCcaW1hZ2VhdHRy4oCdIGF0dHJpYnV0ZSkg YW5kIGRyYWZ0LWxlbm5veC1tbXVzaWMtc2RwLXNvdXJjZS1zZWxlY3Rpb24gc3BlY2lmaWNhdGlv bnMuIFRoZSBzY29wZSBvZiB0aGUgc29sdXRpb24gaXMgbW9yZSBuYXJyb3cgdGhhbiBDT1AsIGFu ZCBvbmx5IHRhbGtzIGFib3V0IHZpZGVvIHJlc29sdXRpb24uDQoNCg0KVGhlIGNoYWlycyBhc2tl ZCBob3cgbWFueSBoYXZlIHJlYWQgdGhlIGRyYWZ0cywgYW5kIHdoZXRoZXIgcGVvcGxlIHVuZGVy c3RhbmQgdGhlIGRpZmZlcmVuY2UgaW4gdGhlIHByb3Bvc2VkIG1lY2hhbmlzbXMuIEl0IHdhcyBj b25jbHVkZWQgdGhhdCBlbm91Z2ggcGVvcGxlIGhhdmUgcmVhZCB0aGUgZHJhZnRzLCBhbmQgdW5k ZXJzdGFuZCB0aGUgZGlmZmVyZW5jZSwgaW4gb3JkZXIgdG8gcGVyZm9ybSBhIHN0cmF3IHBvbGwg b24gd2hpY2ggd2F5IHRvIG1vdmUgZm9yd2FyZC4NCg0KDQogUE9MTDoNCg0KDQogMS4gQmFzZSBm dXJ0aGVyIHdvcmsgb24gTWFnbnVz4oCZcyBwcm9wb3NhbCAoQ09QKTogNiw1DQogMi4gQmFzZSBm dXJ0aGVyIHdvcmsgb24gSGFyYWxk4oCZcyBwcm9wb3NhbCAoU0RQIOKAnGltYWdlYXR0cuKAnSBh dHRyaWJ1dGUpOiAyNiw1DQoNCg0KIE91dGNvbWU6IENsZWFyIHN1cHBvcnQgZm9yIEhhcmFsZOKA mXMgcHJvcG9zYWwuDQoNCg0KIEFmdGVyIHRoZSBwb2xsLCB0aGUgY2hhaXJzIGluZGljYXRlZCB0 aGF0IHRoZXkgd2lsbCBkaXNjdXNzIHdpdGggdGhlIGFyZWEgZGlyZWN0b3JzIGFib3V0IHdoZXJl IHRoZSBtZWNoYW5pc20gd29yayB3b3VsZCB0YWtlIHBsYWNlLCBhcyBpdCBtaWdodCBiZSBkb25l IGluIGFub3RoZXIgV0cgdGhlbiBSVENXRUIuDQpUb3BpYzogIE1hbmRhdG9yeSB0byBpbXBsZW1l bnQgYXVkaW8gY29kZWMgc2VsZWN0aW9uDQogUHJlc2VudGVyOiAgVGltIFRlcnJpYmVycnkNCiBS ZWxhdGVkIGRyYWZ0OiBkcmFmdC1jYnJhbi1ydGN3ZWItY29kZWMNCg0KDQpOdXRzaGVsbDogTWFr ZSBhIGRlY2lzaW9uLCB1c2luZyBhIHNldCBvZiBjcml0ZXJpYSwgYWJvdXQgTVRJIChNYW5kYXRv cnkgVG8gSW1wbGVtZW50KSBhdWRpbyBjb2RlYyhzKS4gVGhlcmUgd2lsbCBiZSBubyByZWNvbW1l bmRhdGlvbnMgb2Ygb3RoZXIgY29kZWNzLCBuZWl0aGVyIHdpbGwgcGVvcGxlIGJlIHJlcXVlc3Rl ZCB0byBub3QgaW1wbGVtZW50IGNlcnRhaW4gY29kZWNzLiAgVGhlIHByZXNlbnRlciBsaXN0ZWQg dGhlIGNyaXRlcmlhIHVzZWQgaW4gdGhlIGNvZGVjIGV2YWx1YXRpb24gYnkgdGhlIENPREVDIHdv cmtpbmcgZ3JvdXAsIHRoZW4gcHJlc2VudGVkIGhpcyBldmFsdWF0aW9uIG9mIHRoZSBjb2RlY3Mg YWdhaW5zdCB0aGUgY3JpdGVyaWEuICBIZSB0aGVuIHByb3Bvc2VkIGJvdGggT3B1cyBhbmQgRy43 MTEgY29kZWNzIGFzIE1USSBmb3IgUlRDV0VCLiBJdCB3YXMgY2xhaW1lZCB0aGF0IE9wdXMgaGFu ZGxlcyBhbGwgdXNlLWNhc2VzLCB3aGlsZSBHLjcxMSBoYW5kbGVzIGJhc2ljIGxlZ2FjeSBpbnRl cm9wZXJhYmlsaXR5Lg0KDQoNCiBJdCB3YXMgcXVlc3Rpb25lZCB3aHkgdHdvIGNvZGVjcyBhcmUg cGlja2VkLCBhcyBvbmx5IG9uZSB3b3VsZCBiZSBuZWVkZWQgdG8gYWNoaWV2ZSBpbnRlcm9wZXJh YmlsaXR5LiBJdCB3YXMgaW5kaWNhdGVkIHRoYXQgd2UgbmVlZCBhIG1hbmRhdG9yeSBjb2RlYywg b3IgYSBzZXQgb2YgbWFuZGF0b3J5IGNvZGVjcywgdG8gYWNoaWV2ZSBpbnRlcm9wZXJhYmlsaXR5 IGluIGFsbCBjYXNlcy4gSXQgd2FzIGluZGljYXRlZCB0aGF0IGEgbGVnYWN5IGdhdGV3YXksIGV2 ZW50aG91Z2ggc2VlbiBhcyBhbiBSVENXRUIgZW5kcG9pbnQgZnJvbSBhIGJyb3dzZXIgcGVyc3Bl Y3RpdmUsIG1pZ2h0IG5vdCBpbXBsZW1lbnQgdGhlIE9wdXMgY29kZWMuIEl0IHdhcyBpbmRpY2F0 ZWQgdGhhdCwgZXZlbnRob3VnaCBzb21ldGhpbmcgaXMgbWFuZGF0b3J5IHRvIGltcGxlbWVudCwg aXQgaXMgbm90IG1hbmRhdG9yeSB0byB1c2UsIGlmIG5vdCBuZWVkZWQgZm9yIGNlcnRhaW4gdXNl LWNhc2VzLCBvciBpbiBjZXJ0YWluIGVudGl0aWVzLg0KDQoNCiBQT0xMOg0KDQoNCiAxLiBPcHVz ICYgRy43MTEgIkVudGlyZSByb29tLCBleGNlcHQgdGhlIDUgdGhhdCB3YW50cyBPcHVzIG9ubHki DQogMi4gT3B1czogIDUNCiAzLiBHLjcxMSBvbmx5OiAgMA0KDQoNCiBPdXRjb21lOiBNb3ZlIGZv cndhcmQgd2l0aCBPcHVzIGFuZCBHLjcxMSBhcyBNVEkgKG1hbmRhdG9yeS10by1pbXBsZW1lbnQp IGF1ZGlvIGNvZGVjcy4NCg0KDQogLS0tLS0NCg0KDQogVG9waWM6ICBWaWRlbyBjb2RlYyBpbmZv DQogUHJlc2VudGVyOiAgQ3VsbGVuIEplbm5pbmdzDQogUmVsYXRlZCBkcmFmdDogZHJhZnQtY2Jy YW4tcnRjd2ViLWNvZGVjDQoNCg0KIE51dHNoZWxsOiBSYXRoZXIgdGhhbiB0cnlpbmcgdG8gc2Vs ZWN0IGEgTVRJIHZpZGVvIGNvZGVjLCBhIHN1Z2dlc3RlZCB3YXkgZm9yd2FyZCBpbiBvcmRlciB0 byByZWFjaCBhIHBvaW50IHdoZXJlIHN1Y2ggc2VsZWN0aW9uIGNhbiBiZSBkb25lLiAgVGhlIGFz c3VtcHRpb24gd2FzIHRoYXQgdGhlIGNhbmRpZGF0ZSBjb2RlY3MgYXJlIFZQOCBhbmQgSC4yNjQs IGFuZCB0aGF0IHRoZXJlIGlzIGNvbnNlbnN1cyB0aGF0IHdlIG5lZWQgdG8gY2hvb3NlIGEgTVRJ IHZpZGVvIGNvZGVjLiAgVGhlIHByZXNlbnRlciBzdWdnZXN0ZWQgZGlmZmVyZW50IHRvcGljcyBh bmQgYXJlYXMsIGZvciB3aGljaCB3ZSBzaG91bGQgZ2V0IGluZm9ybWF0aW9uLCBhbmQgYXNrZWQg d2hldGhlciBwZW9wbGUga25vdyBob3cgd2UgY2FuIGdldCBzdWNoIGluZm9ybWF0aW9uLCBhbmQg d2hldGhlciB0aGVyZSBhcmUgdm9sdW50ZWVycyB0byBwcm92aWRlIHN1Y2ggaW5mb3JtYXRpb24u DQoNCg0KQWZ0ZXIgdGhlIHByZXNlbnRhdGlvbiwgcGVvcGxlIHdlcmUgYXNrZWQgdG8gc2VuZCBp bmZvcm1hdGlvbiB0byB0aGUgbWFpbGluZyBsaXN0IGJ5IE9jdG9iZXIgMTV0aCwgdG8gaW5kaWNh dGUgd2hhdCB0eXBlIG9mIGluZm9ybWF0aW9uIHRoZXkgdGhpbmsgaXMgbmVlZGVkIGluIG9yZGVy IHRvIHNlbGVjdCBhIHZpZGVvIGNvZGVjLiBUaGUgcGxhbiBpcyB0byB0cnkgdG8gcmVhY2ggY29u c2Vuc3VzIG9uIGEgTVRJIHZpZGVvIGNvZGVjIGF0IHRoZSBJRVRGIDg1IG1lZXRpbmcuIElmIHRo YXQgZmFpbHMsIGFuIGFsdGVybmF0aXZlIHByb2Nlc3MgbWlnaHQgYmUgbmVlZGVkLiBUaGUgcGxh biBpcyB0bywgYmVmb3JlIHRoZSBJRVRGIDg1IG1lZXRpbmcsIHRyeSB0byByZWFjaCBjb25zZW5z dXMgb24gd2hhdCBhbHRlcm5hdGl2ZSBwcm9jZXNzIHNob3VsZCBiZSB1c2VkLCBpZiBuZWVkZWQu DQoNCg0KIC0tLS0tDQoNCg0KIFRvcGljOiAgQ29uc2VudCBmcmVzaG5lc3MNCiBQcmVzZW50ZXI6 ICBEYW4gV2luZw0KIFJlbGF0ZWQgZHJhZnQ6IGRyYWZ0LW11dGh1LWJlaGF2ZS1jb25zZW50LWZy ZXNobmVzcw0KDQoNCiBOdXRzaGVsbDogQXZvaWQgRG9TIGJ5IHVzaW5nIHJlZ3VsYXIgYXV0aGVu dGljYXRlZCBjb25zZW50IHJlcXVlc3RzLCB1c2luZyBTVFVOLCB0byByZWZyZXNoIHBlcm1pc3Np b24gdG8gY29udGludWUgc2VuZGluZyB0cmFmZmljLiBUcmFmZmljIHNlbmRlciByZXF1ZXN0cyBj b25zZW50IG9mIHRoZSByZWNlaXZlci4gICBJdCB3YXMgaW5kaWNhdGVkIHRoYXQgY29uc2Vuc3Vz IGhhZCBiZWVuIHJlYWNoZWQgb24gYSBudW1iZXIgb2YgdGhlIHRvcGljcyBhdCB0aGUgUlRDV0VC IGludGVyaW0gbWVldGluZyBpbiBTdG9ja2hvbG0sIGFuZCB0aGF0IHRoZSBsYXRlc3QgdmVyc2lv biBvZiB0aGUgYXNzb2NpYXRlZCBkcmFmdCBzaG91bGQgcmVmbGVjdCB0aGUgYWdyZWVtZW50cy4N Cg0KDQpJdCB3YXMgaW5kaWNhdGVkIHRoYXQgSUNFIGxpdGUgZW5kcG9pbnRzLCBhbmQgbGVnYWN5 IGZ1bGwgSUNFIGVuZHBvaW50cywgd2lsbCBub3Qgc2VuZCB0aGUgY29uc2VudCBmcmVzaG5lc3Mg bWVzc2FnZXMsIGFuZCB0aGF0IGl0IHNob3VsZCBiZSBjbGFyaWZpZWQgaW4gdGhlIGRvY3VtZW50 LiAgSXQgd2FzIGluZGljYXRlZCB0aGF0IHdlIG5lZWQgYSBtb3JlIGNsZWFyIGRlZmluaXRpb24s IGFuZCBzZWN1cml0eSBpbXBsaWNhdGlvbnMsIG9mIOKAnGNvbnNlbnTigJ0uDQoNCg0KRGF5IDIN Cg0KDQpUb3BpYzogUW9TIE1hcmtpbmcNClByZXNlbnRlcjogQ3VsbGVuIEplbm5pbmdzIA0KUmVs YXRlZCBkcmFmdDogZHJhZnQtamVubmluZ3MtcnRjd2ViLXFvcw0KDQoNCk51dHNoZWxsOiAgVGhl IGRyYWZ0IHN1Z2dlc3RzIFJGQzQ1OTQgbWFya2luZyB3aXRoIEFQSSByZXF1ZXN0cyBmb3IgcmVs YXRpdmUgcHJpb3JpdGllcyBvZiBtZWRpYSwgYXMgd2VsbCBhcyBhIHdheSB0byBmaW5kIG91dCB3 aGF0IG1hcmtpbmdzIHdlcmUgdXNlZDsgZGlzY3Vzc2lvbiBvZiBob3cgaXQgc2hvdWxkIGJlIHNl dC4gIE1hZ251cyBhbmQgVGVkIGFzIGNoYWlycyBhc2tlZCBmb3IgaW5kaWNhdGlvbnMgb2YgaW50 ZXJlc3QsIHdoaWNoIHNlZW1lZCB0byBiZSBnZW5lcmFsbHkgcG9zaXRpdmUuICBUaGUgY2hhaXJz IHdpbGwgZGlzY3VzcyB3aGV0aGVyIHRvIHB1cnN1ZSBhcyBhbiBpbmRpdmlkdWFsIGZvciBub3cg b3Igbm90LCBidXQgZXZlbnR1YWwgYWRvcHRpb24gc2VlbXMgbGlrZWx5Lg0KICAgICAgICAgIA0K VG9waWM6IFVzYWdlcyBhbmQgY29uc3RyYWludHMNClByZXNlbnRlcjogTWFyY3VzIElzb21ha2kg IA0KUmVsYXRlZCBkcmFmdDogZHJhZnQtaXNvbWFraS1ydGN3ZWItbW9iaWxlDQoNCg0KTnV0c2hl bGw6IFRoZSBwcmVzZW50ZXIgd2VudCB0aHJvdWdoIGhvdyB3aXJlbGVzcyBuZXR3b3JrcyBiZWhh dmUgaW4gdGhlIHByZXNlbmNlIG9mIGtlZXBhbGl2ZXMsIGFuZCB0aGUgaW1wYWN0IG9uIFVEUCB0 aW1lcy4gIFRoZXNlIHNob3VsZCBpbmZvcm0gc29tZSBvZiB0aGUgZGVzaWduIGRlY2lzaW9ucyBi ZWluZyBtYWRlIGJ5IHRoZSBncm91cCwgYnV0IHRoZXJlIHdlcmUgbm8gc3BlY2lmaWMgYWN0aW9u IGl0ZW1zLiAgVGhlIGF1dGhvciB3aWxsIGNvbnRpbnVlIHRvIGtlZXAgdGhpcyB1cC10by1kYXRl IGFzIGFuIGluZm9ybWF0aW9uYWwgZG9jdW1lbnQuDQo8bmljZSBkaXNjdXNzaW9uIG9mIGhvdyB3 aXJlbGVzcyBuZXR3b3JrcyBiZWhhdmUgd2l0aCByZWNvbW1uZW5kYXRpb25zIG9uIHRoaW5ncyBs aWtlIGtlZXBhbGl2ZXM+DQoNCg0KVG9waWM6IFVzYWdlcyBhbmQgY29uc3RyYWludHMNClByZXNl bnRlcjogQmVybmFyZCBBYm9iYSANClJlbGF0ZWQgZHJhZnQ6IGRyYWZ0LWFib2JhLXJ0Y3dlYi1l Y3JpdA0KDQoNCk51dHNoZWxsOiBUaGUgcHJlc2VudGVyIGRpc2N1c3NlZCB0aGUgcmVxdWlyZW1l bnRzIHdoaWNoIGZhbGwgb24gUlRDV0VCIGFwcHMgd2hpY2ggY2hvb3NlIHRvIG9yIHdoaWNoIHdp bGwgYmUgcmVxdWlyZWQgdG8gc3VwcG9ydCBlbWVyZ2VuY3kgY2FsbHMuICBUaGUgY2hhaXJzIHJl cXVlc3QgdGhhdCBmZWVkYmFjayBvbiB0aGlzIGdvIHRvIHRoZSBhdXRob3JzLCBidXQgbm90ZWQg dGhhdCBpdCBkb2VzIG5vdCBzZWVtIGFwcHJvcHJpYXRlIHRvIGFkb3B0IGFzIGEgd29ya2luZyBn cm91cCBkcmFmdCBpbiBSVENXRUIuDQoNCg0KICAgICAgICAgICANClRvcGljOiBGaXJld2FsbCB0 cmF2ZXJzYWw6IA0KUHJlc2VudGVyOiBUaXJ1IFJlZGR5DQpSZWxhdGVkIGRyYWZ0OiBkcmFmdC1y ZWRkeS1ydGN3ZWItc3R1bi1hdXRoLWZ3LXRyYXZlcnNhbA0KDQoNCk51dHNoZWxsOiBUaGUgZ3Jv dXAgZGlzY3Vzc2VkIGhvdyB0aGUgdG9rZW4gaXMgb2J0YWluZWQgYW5kIHdoeSBhIG1vcmUgZ2Vu ZXJhbCBzb2x1dGlvbiB3b3VsZG7igJl0IHdvcmsgYmV0dGVyLiAgQ3VsbGVuIHN1Z2dlc3RlZCB0 aGF0IGVudGVycHJpc2VzIHNvbWV0aW1lcyBhbGxvdyBUQ1AgYnV0IG5vdCBVRFAsIHNvIHRoYXQg bWF5IGJlIGFuIGF2ZW51ZSB3b3J0aCBwdXJzdWluZy4gIFRoZSBjaGFpcnMgYWdyZWVkIHRoYXQg dGhpcyBzZWVtcyB0byBiZSBpbnRlcmVzdGluZywgYnV0IG5vdCBhcHByb3ByaWF0ZSBmb3IgUlRD V0VCIHRvIGJlIHRoZSBsb2N1cyBvZiB3b3JrLiAgR29uemFsbyB3aWxsIHdvcmsgd2l0aCBvdGhl ciBBRHMgYW5kIHdpbGwgYWR2aXNlLg0KICAgICAgICAgIA0KVG9waWM6ICBTZWN1cml0eSBhcmNo aXRlY3J0dXJlOiANClByZXNlbnRlcjogRXJpYyBSZXNjb3JsYQ0KUmVsYXRlZCBkcmFmdDogZHJh ZnQtaWV0Zi1ydGN3ZWItc2VjdXJpdHktYXJjaA0KDQoNCk51dHNoZWxsOiAgTXVjaCBvZiB0aGUg ZGlzY3Vzc2lvbiBmb2N1c2VkIG9uIGNvbnNlbnQgYW5kIGxpdmVuZXNzIGNoZWNrcyBhbmQgd2hl dGhlciBvciBub3QgdGhlc2UgY291bGQgYmUgY29tYmluZWQuICBBZGRpdGlvbmFsIHdvcmsgd2Fz IHN1Z2dlc3RlZCBvbiBzaG9ydGVuaW5nIFNUVU4gdGltZXJzLCBhbmQgdGhlIEFEcyBhZ3JlZSB0 byBoZWxwIGNvbm5lY3QgdGhlc2UgcHJvcG9zYWxzIHRvIG90aGVyIHdvcmsuDQoNCg0KVG9waWM6 IFJUUCB1c2FnZQ0KUHJlc2VudGVyOiBDb2xpbiBQZXJraW5zDQpSZWxhdGVkIGRyYWZ0OiAgZHJh ZnQtaWV0Zi1ydGN3ZWItcnRwLXVzYWdlDQoNCg0KTnV0c2hlbGw6ICBUaGUgZ3JvdXAgYWdyZWVk IHRvIG1vdmluZyB0aGUgUlRQIHRvcG9sb2dpZXMgd29yayB0byBhIHNlcGFyYXRlIGRyYWZ0LCBh cyB3ZWxsIGFzIG1vdmluZyB0aGUgd29yayBpbiBTZWN0aW9uIDEyIChpbXBsZW1lbnRhdGlvbiBj b25zaWRlcmF0aW9ucykgdG8gYSBzZXBhcmF0ZSBkcmFmdC4gIFRoZSBhdXRob3JzIHdpbGwgdXBk YXRlIHRoZSBkcmFmdCB3aXRoIHRoZSBzZWxlY3RlZCBNVEkgYXVkaW8gY29kZWNzIG9uY2UgY29u ZmlybWVkIG9uIHRoZSBsaXN0LiAgVGhlIGdyb3VwIG5lZWRzIHRvIGRyaXZlIHVzZSBjYXNlcyBy ZWxldmFudCBmb3IgUlRDUCBYUiBiZWZvcmUgc3VwcG9ydCBmb3IgdGhlbSB3aWxsIGJlIHJlcXVp cmVkLg== --bcaec54d4b0206dd5904c80a2a33-- From Jim.Barnett@genesyslab.com Fri Aug 24 15:32:24 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83C5121F8593 for ; Fri, 24 Aug 2012 15:32:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UYrgQHw14Xic for ; Fri, 24 Aug 2012 15:32:23 -0700 (PDT) Received: from relay-out1.dc.genesyslab.com (relay-out1.dc.genesyslab.com [198.49.180.220]) by ietfa.amsl.com (Postfix) with ESMTP id E4DDB21F854A for ; Fri, 24 Aug 2012 15:32:23 -0700 (PDT) Received: from g2.genesyslab.com (g2.genesyslab.com [192.168.20.138]) by relay-out1.dc.genesyslab.com (8.13.8+Sun/8.13.8) with ESMTP id q7OMWLGW028556; Fri, 24 Aug 2012 15:32:21 -0700 (PDT) Received: from NAHALD.us.int.genesyslab.com ([192.168.20.93]) by g2.genesyslab.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 24 Aug 2012 15:32:21 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 24 Aug 2012 15:33:16 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] Filling in details on "trickle ICE" Thread-Index: Ac2CPpsrRW3In9tQQKaqjU44C+9/UQACRsyw References: <3B8DB12B-ABB3-4AC2-A0A0-93DC62C619D3@iii.ca> From: "Jim Barnett" To: "Martin Thomson" , "Cullen Jennings" X-OriginalArrivalTime: 24 Aug 2012 22:32:21.0987 (UTC) FILETIME=[53DD2330:01CD8248] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Filling in details on "trickle ICE" X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 24 Aug 2012 22:32:24 -0000 Martin, =20 Just to make sure that I understand your position, I take you to be saying: =20 1) in the case where both endpoints have downloaded their apps from the same server, they can do trickle ICE any way that they want. 2) in the case where an application is talking to an unknown or legacy peer, trickle ICE is a bad idea because there is no standard way to do it. (i.e. try it at your own risk) Is this correct? - Jim=20 -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Martin Thomson Sent: Friday, August 24, 2012 5:23 PM To: Cullen Jennings Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Filling in details on "trickle ICE" On 24 August 2012 11:16, Cullen Jennings wrote: > > I'm confused on what you are trying to say. Are you saying > > 1) we don't need trickle ICE > > 2) we can do trickily ICE but no standards need to be written for two=20 > different devices to do trickle ICE It's just 2) Trickle candidates is a *new thing*, a new problem that needs to be solved. It's fairly clear that trickling is an optimization that was never considered in the design of ICE. We can solve the problem by writing an RFC, but you can also write fewer standards and enable the same outcome. An RFC would specify how this differs from ICE and what new behaviours are expected from endpoints. That RFC would also describe how implementations would discover if peers support the new behaviour so that they don't do things that would surprise or break implementations that did not. The alternative is to recognize that ICE specifies a number of features that are really, really important, both from an interoperability and a security standpoint: The use of STUN Binding requests to gather server reflexive addresses. The use of TURN to allocate TURN relays. The use of STUN Binding requests to establish connectivity and consent. Constraints over how checks can be sent (which are actually not all suitable in this context for other reasons). A way to resolve the problem of who performs candidate pair selection. Then ICE has a bunch of really useful advice on what implementations might do: gather candidates, prioritize them, check them, retry checks, track those that succeed, etc... None of that is really necessary, just super handy. The signalling stuff in ICE is not relevant to the rtcweb architecture. So we can ignore that part. WebRTC decided to use it, but that's their problem. The most invasive thing that ICE does is describe a specific algorithm in some detail. Implicit in this algorithm is the fact that all candidates have to be signaled together. This is also stuff that we don't *need* in rtcweb. This might have been useful when you use RFCs to describe every facet of your application, but it is in fact unnecessary for applications of the sort that exist in rtcweb. Many of these applications want things like trickle candidates, which can give better session initialization performance. Many of these will have code on both endpoints. Obviously, applications that want to interoperate with ICE implementations will have to play nice with ICE. But this is usually known a priori. Building signaling for this is presumptuous. I understand how someone might conclude that you need to standardize this behaviour. It depends on what preconceptions you have. If you wanted to port trickle candidates to your SIP PBX, then I can see how the standardization option might seem attractive. The Microsoft API proposal makes all of this possible by only taking the really important stuff from RFC 5245. --Martin _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From martin.thomson@gmail.com Fri Aug 24 17:08:43 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9BC621F8598 for ; Fri, 24 Aug 2012 17:08:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.907 X-Spam-Level: X-Spam-Status: No, score=-3.907 tagged_above=-999 required=5 tests=[AWL=-0.308, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aBveB1FQUIBe for ; Fri, 24 Aug 2012 17:08:43 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0FBC121F8595 for ; Fri, 24 Aug 2012 17:08:42 -0700 (PDT) Received: by lahm15 with SMTP id m15so1524558lah.31 for ; Fri, 24 Aug 2012 17:08:39 -0700 (PDT) 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=/eaUG+cWTaUVO0sPIBPIrBIfV1Da+5dmfTuw9oYPDmc=; b=NG8eUE8/qF2VDvP4ytGAFaJDmkSMmWbrnQHhhL4ObC6z+6Rt1mElxgvPj7D02CBMS5 EdZYY5f96OqnUeJgmd2DmbkQB8+afHdCoDFlDJMHs+1SdRaLgXU+RTVwnZS/VdK6DDq6 1Npv2uuBEmc1EAOnA8Qa/TIrh6zxrMz2tNcUaU63XDXI8GGPVHDqyNYUp0pH2HGpQQKL bkjkI5W3Za0NjLGSDfUbGTYZlHHSofHYIJqJjsrOMqUMKY+M86WKfx9PB9V0ZiaeVQ87 v80D4kWX3O3ncgn8/Gcpa8xMxbAbp7I4TJF4+cmnY1jR9feHoAVLvmmHHfARJz2ZYq99 qdBQ== MIME-Version: 1.0 Received: by 10.112.25.100 with SMTP id b4mr3392672lbg.55.1345853319719; Fri, 24 Aug 2012 17:08:39 -0700 (PDT) Received: by 10.112.41.193 with HTTP; Fri, 24 Aug 2012 17:08:39 -0700 (PDT) In-Reply-To: References: <3B8DB12B-ABB3-4AC2-A0A0-93DC62C619D3@iii.ca> Date: Fri, 24 Aug 2012 17:08:39 -0700 Message-ID: From: Martin Thomson To: Jim Barnett Content-Type: text/plain; charset=UTF-8 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Filling in details on "trickle ICE" X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 25 Aug 2012 00:08:43 -0000 On 24 August 2012 15:33, Jim Barnett wrote: > Martin, > Just to make sure that I understand your position, I take you to be > saying: > 1) in the case where both endpoints have downloaded their apps from the > same server, they can do trickle ICE any way that they want. > 2) in the case where an application is talking to an unknown or legacy > peer, trickle ICE is a bad idea because there is no standard way to do > it. (i.e. try it at your own risk) > > Is this correct? A fair summation. In 1) they can do whatever they want within the necessary security constraints. From matthew.kaufman@skype.net Mon Aug 27 12:53:57 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8658021F84B3 for ; Mon, 27 Aug 2012 12:53:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S8MZfQ8rRnRd for ; Mon, 27 Aug 2012 12:53:56 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe004.messaging.microsoft.com [216.32.180.14]) by ietfa.amsl.com (Postfix) with ESMTP id 75FD921F8495 for ; Mon, 27 Aug 2012 12:53:56 -0700 (PDT) Received: from mail226-va3-R.bigfish.com (10.7.14.243) by VA3EHSOBE009.bigfish.com (10.7.40.29) with Microsoft SMTP Server id 14.1.225.23; Mon, 27 Aug 2012 19:53:55 +0000 Received: from mail226-va3 (localhost [127.0.0.1]) by mail226-va3-R.bigfish.com (Postfix) with ESMTP id 5D6E89001D5; Mon, 27 Aug 2012 19:53:55 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC104.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -26 X-BigFish: VS-26(zz9371I542Mzz1202hzz1033IL8275dhz2fh2a8h668h839h944hd25hf0ah107ah) Received-SPF: pass (mail226-va3: domain of skype.net designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=matthew.kaufman@skype.net; helo=TK5EX14HUBC104.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail226-va3 (localhost.localdomain [127.0.0.1]) by mail226-va3 (MessageSwitch) id 1346097233234450_27463; Mon, 27 Aug 2012 19:53:53 +0000 (UTC) Received: from VA3EHSMHS041.bigfish.com (unknown [10.7.14.248]) by mail226-va3.bigfish.com (Postfix) with ESMTP id 36A61780045; Mon, 27 Aug 2012 19:53:53 +0000 (UTC) Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (131.107.125.8) by VA3EHSMHS041.bigfish.com (10.7.99.51) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 27 Aug 2012 19:53:53 +0000 Received: from TK5EX14MBXC272.redmond.corp.microsoft.com ([169.254.2.89]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.02.0318.003; Mon, 27 Aug 2012 19:53:51 +0000 From: Matthew Kaufman To: Jim Barnett , Martin Thomson , Cullen Jennings Thread-Topic: [rtcweb] Filling in details on "trickle ICE" Thread-Index: AQHNggtYU4RJsiahn0ePX6kIvBvYA5dpHYyAgAABRICAAAOYgIAACHQAgAADxICAABZ7AIAAM/2AgAATuQCABIcVcA== Date: Mon, 27 Aug 2012 19:53:50 +0000 Message-ID: References: <3B8DB12B-ABB3-4AC2-A0A0-93DC62C619D3@iii.ca> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.76] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: skype.net Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Filling in details on "trickle ICE" X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 27 Aug 2012 19:53:57 -0000 If both ends want to do a full, standards compliant (which also implies *no= t* trickle) ICE, then we can bake that into the browser following the exist= ing RFC as specification. If both ends want to do something that isn't that, then we either need to w= rite down *exactly* how they do that "something else" (which would imply an= RFC or three for things like how trickle ICE works, how it is discovered, = what SDP implications it has, etc.) *or* we need to provide knobs that allo= w the developer, through Javascript, to ensure that both ends do the same (= or compatible) "something elses". Note that the only reason ICE-like STUN connectivity tests are a MUST is th= at it is required for consent verification. There are any number of reasons= why an endpoint might wish to do something other than what a full standard= s-compliant ICE implementation would require... this thread has been about = the issues around trickle candidates, but there's also the case where you'r= e on a webpage of mine and I know I'm going to send your call via a gateway= that has a public IP address. There is no reason to run any of what ICE re= quires *except* the security-considerations-mandated consent verification, = and only in the browser-to-gateway test direction. Again, we could write another RFC covering that case... or we could just do= what our (Microsoft's) proposal suggests and provide the developer with th= e controls necessary to implement *any* of these use cases, including the m= ode that matches the current ICE RFC. As a side effect, the developer then *also* has the flexibility to improve = interoperation with things like pre-final ICE implementations, as long as t= hey meet the requirements around STUN connectivity tests. So to recap, if you want something fancy like ICE with trickle candidates y= ou have two options: X) Give the developer the flexibility to build variations upon ICE within t= he security constraints, or Y) Start writing Internet Drafts describing all the variations upon ICE you= might wish to use and then get every browser vendor to add them Matthew Kaufman -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= Jim Barnett Sent: Friday, August 24, 2012 3:33 PM To: Martin Thomson; Cullen Jennings Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Filling in details on "trickle ICE" Martin, Just to make sure that I understand your position, I take you to be saying: =20 1) in the case where both endpoints have downloaded their apps from the sam= e server, they can do trickle ICE any way that they want. 2) in the case where an application is talking to an unknown or legacy pee= r, trickle ICE is a bad idea because there is no standard way to do it. (i= .e. try it at your own risk) Is this correct? - Jim=20 From Jim.Barnett@genesyslab.com Mon Aug 27 13:14:26 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6B9E21F8514 for ; Mon, 27 Aug 2012 13:14:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V4U3EC4IQZbO for ; Mon, 27 Aug 2012 13:14:25 -0700 (PDT) Received: from relay-out2.dc.genesyslab.com (relay-out2.dc.genesyslab.com [198.49.180.221]) by ietfa.amsl.com (Postfix) with ESMTP id E130021F84F8 for ; Mon, 27 Aug 2012 13:14:25 -0700 (PDT) Received: from g2.genesyslab.com (g2.genesyslab.com [192.168.20.138]) by relay-out2.dc.genesyslab.com (8.13.8+Sun/8.13.8) with ESMTP id q7RKEK8R007641; Mon, 27 Aug 2012 13:14:20 -0700 (PDT) Received: from NAHALD.us.int.genesyslab.com ([192.168.20.93]) by g2.genesyslab.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 27 Aug 2012 13:14:20 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 27 Aug 2012 13:15:06 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] Filling in details on "trickle ICE" Thread-Index: AQHNggtYU4RJsiahn0ePX6kIvBvYA5dpHYyAgAABRICAAAOYgIAACHQAgAADxICAABZ7AIAAM/2AgAATuQCABIcVcIAABc1w References: <3B8DB12B-ABB3-4AC2-A0A0-93DC62C619D3@iii.ca> From: "Jim Barnett" To: "Matthew Kaufman" , "Martin Thomson" , "Cullen Jennings" X-OriginalArrivalTime: 27 Aug 2012 20:14:20.0457 (UTC) FILETIME=[8AED3190:01CD8490] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Filling in details on "trickle ICE" X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 27 Aug 2012 20:14:26 -0000 One question I have is whether we consider the "Browser RTC Trapezoid" to be in scope. In this use case, the two UAs download their applications from different web servers. In such a case, I don't see how we can enable trickle ICE without specifying _exactly_ how it is supposed to work (or, alternatively, specifying a protocol that the two web servers will use to negotiate how to do it). =20 Handling the trapezoid is a _lot_ more work than the case where both UAs download their applications from the same server (or from the case where a single WebRTC UA is talking to a legacy device). Have we made a decision on whether it is in scope? In any case, it would certainly clarify the discussion for me if I knew whether we were considering this use case or not. A number of claims have been and are being made on the list that strike me as obviously false if this use case is in scope - and perfectly sensible if it's not. =20 - Jim P.S. My personal opinion is that it would make sense to defer the trapezoid until a hypothetical version 2. That way it would not inform any immediate decisions about the APIs, but we would have to consider what it would take to extend them to handle it. (I would think that would involve mostly adding more detail, so forward compatibility might not be hard to achieve.) -----Original Message----- From: Matthew Kaufman [mailto:matthew.kaufman@skype.net]=20 Sent: Monday, August 27, 2012 3:54 PM To: Jim Barnett; Martin Thomson; Cullen Jennings Cc: rtcweb@ietf.org Subject: RE: [rtcweb] Filling in details on "trickle ICE" If both ends want to do a full, standards compliant (which also implies *not* trickle) ICE, then we can bake that into the browser following the existing RFC as specification. If both ends want to do something that isn't that, then we either need to write down *exactly* how they do that "something else" (which would imply an RFC or three for things like how trickle ICE works, how it is discovered, what SDP implications it has, etc.) *or* we need to provide knobs that allow the developer, through Javascript, to ensure that both ends do the same (or compatible) "something elses". Note that the only reason ICE-like STUN connectivity tests are a MUST is that it is required for consent verification. There are any number of reasons why an endpoint might wish to do something other than what a full standards-compliant ICE implementation would require... this thread has been about the issues around trickle candidates, but there's also the case where you're on a webpage of mine and I know I'm going to send your call via a gateway that has a public IP address. There is no reason to run any of what ICE requires *except* the security-considerations-mandated consent verification, and only in the browser-to-gateway test direction. Again, we could write another RFC covering that case... or we could just do what our (Microsoft's) proposal suggests and provide the developer with the controls necessary to implement *any* of these use cases, including the mode that matches the current ICE RFC. As a side effect, the developer then *also* has the flexibility to improve interoperation with things like pre-final ICE implementations, as long as they meet the requirements around STUN connectivity tests. So to recap, if you want something fancy like ICE with trickle candidates you have two options: X) Give the developer the flexibility to build variations upon ICE within the security constraints, or Y) Start writing Internet Drafts describing all the variations upon ICE you might wish to use and then get every browser vendor to add them Matthew Kaufman -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Jim Barnett Sent: Friday, August 24, 2012 3:33 PM To: Martin Thomson; Cullen Jennings Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Filling in details on "trickle ICE" Martin, Just to make sure that I understand your position, I take you to be saying: =20 1) in the case where both endpoints have downloaded their apps from the same server, they can do trickle ICE any way that they want. 2) in the case where an application is talking to an unknown or legacy peer, trickle ICE is a bad idea because there is no standard way to do it. (i.e. try it at your own risk) Is this correct? - Jim=20 From matthew.kaufman@skype.net Mon Aug 27 13:42:16 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A53A621F8508 for ; Mon, 27 Aug 2012 13:42:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.899 X-Spam-Level: X-Spam-Status: No, score=-3.899 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cxrr47pZ2Sk3 for ; Mon, 27 Aug 2012 13:42:15 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe003.messaging.microsoft.com [216.32.180.13]) by ietfa.amsl.com (Postfix) with ESMTP id A771021F8505 for ; Mon, 27 Aug 2012 13:42:15 -0700 (PDT) Received: from mail192-va3-R.bigfish.com (10.7.14.252) by VA3EHSOBE007.bigfish.com (10.7.40.11) with Microsoft SMTP Server id 14.1.225.23; Mon, 27 Aug 2012 20:42:14 +0000 Received: from mail192-va3 (localhost [127.0.0.1]) by mail192-va3-R.bigfish.com (Postfix) with ESMTP id C2BED2C0321; Mon, 27 Aug 2012 20:42:14 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC107.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -26 X-BigFish: VS-26(zz9371I542Mzz1202hzz1033IL8275dhz2fh2a8h668h839h944hd25hf0ah107ah) Received-SPF: pass (mail192-va3: domain of skype.net designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=matthew.kaufman@skype.net; helo=TK5EX14HUBC107.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail192-va3 (localhost.localdomain [127.0.0.1]) by mail192-va3 (MessageSwitch) id 1346100133278942_9306; Mon, 27 Aug 2012 20:42:13 +0000 (UTC) Received: from VA3EHSMHS025.bigfish.com (unknown [10.7.14.238]) by mail192-va3.bigfish.com (Postfix) with ESMTP id 366413E004B; Mon, 27 Aug 2012 20:42:13 +0000 (UTC) Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (131.107.125.8) by VA3EHSMHS025.bigfish.com (10.7.99.35) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 27 Aug 2012 20:42:12 +0000 Received: from TK5EX14MBXC272.redmond.corp.microsoft.com ([169.254.2.89]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.02.0318.003; Mon, 27 Aug 2012 20:42:03 +0000 From: Matthew Kaufman To: Jim Barnett , Martin Thomson , Cullen Jennings Thread-Topic: [rtcweb] Filling in details on "trickle ICE" Thread-Index: AQHNggtYU4RJsiahn0ePX6kIvBvYA5dpHYyAgAABRICAAAOYgIAACHQAgAADxICAABZ7AIAAM/2AgAATuQCABIcVcIAABc1wgAAKshA= Date: Mon, 27 Aug 2012 20:42:03 +0000 Message-ID: References: <3B8DB12B-ABB3-4AC2-A0A0-93DC62C619D3@iii.ca> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.76] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: skype.net Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Filling in details on "trickle ICE" X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 27 Aug 2012 20:42:16 -0000 The "two different web servers" "trapezoid" case would require a trunking p= rotocol between these servers, such as SIP or Jingle, which can describe "t= rickle ICE" such that the browsers could be instructed properly by their re= spective web servers. I believe that with Jingle, there is a written spec for that, and for SIP, = there is not (at present). Matthew Kaufman -----Original Message----- From: Jim Barnett [mailto:Jim.Barnett@genesyslab.com]=20 Sent: Monday, August 27, 2012 1:15 PM To: Matthew Kaufman; Martin Thomson; Cullen Jennings Cc: rtcweb@ietf.org Subject: RE: [rtcweb] Filling in details on "trickle ICE" One question I have is whether we consider the "Browser RTC Trapezoid" to be in scope. In this use case, the two UAs download their applications = from different web servers. In such a case, I don't see how we can enable = trickle ICE without specifying _exactly_ how it is supposed to work (or, a= lternatively, specifying a protocol that the two web servers will use to ne= gotiate how to do it). =20 Handling the trapezoid is a _lot_ more work than the case where both UAs do= wnload their applications from the same server (or from the case where a si= ngle WebRTC UA is talking to a legacy device). Have we made a decision on = whether it is in scope? In any case, it would certainly clarify the discus= sion for me if I knew whether we were considering this use case or not. A = number of claims have been and are being made on the list that strike me as= obviously false if this use case is in scope - and perfectly sensible if i= t's not. =20 - Jim P.S. My personal opinion is that it would make sense to defer the trapezoi= d until a hypothetical version 2. That way it would not inform any immedia= te decisions about the APIs, but we would have to consider what it would ta= ke to extend them to handle it. (I would think that would involve mostly ad= ding more detail, so forward compatibility might not be hard to achieve.) -----Original Message----- From: Matthew Kaufman [mailto:matthew.kaufman@skype.net] Sent: Monday, August 27, 2012 3:54 PM To: Jim Barnett; Martin Thomson; Cullen Jennings Cc: rtcweb@ietf.org Subject: RE: [rtcweb] Filling in details on "trickle ICE" If both ends want to do a full, standards compliant (which also implies *not* trickle) ICE, then we can bake that into the browser following the ex= isting RFC as specification. If both ends want to do something that isn't that, then we either need to w= rite down *exactly* how they do that "something else" (which would imply an= RFC or three for things like how trickle ICE works, how it is discovered, = what SDP implications it has, etc.) *or* we need to provide knobs that allo= w the developer, through Javascript, to ensure that both ends do the same (= or compatible) "something elses". Note that the only reason ICE-like STUN connectivity tests are a MUST is th= at it is required for consent verification. There are any number of reasons= why an endpoint might wish to do something other than what a full standard= s-compliant ICE implementation would require... this thread has been about = the issues around trickle candidates, but there's also the case where you'r= e on a webpage of mine and I know I'm going to send your call via a gateway= that has a public IP address. There is no reason to run any of what ICE re= quires *except* the security-considerations-mandated consent verification, = and only in the browser-to-gateway test direction. Again, we could write another RFC covering that case... or we could just do= what our (Microsoft's) proposal suggests and provide the developer with th= e controls necessary to implement *any* of these use cases, including the m= ode that matches the current ICE RFC. As a side effect, the developer then *also* has the flexibility to improve = interoperation with things like pre-final ICE implementations, as long as t= hey meet the requirements around STUN connectivity tests. So to recap, if you want something fancy like ICE with trickle candidates y= ou have two options: X) Give the developer the flexibility to build variations upon ICE within t= he security constraints, or Y) Start writing Internet Drafts describing all the variations upon ICE you= might wish to use and then get every browser vendor to add them Matthew Kaufman -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= Jim Barnett Sent: Friday, August 24, 2012 3:33 PM To: Martin Thomson; Cullen Jennings Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Filling in details on "trickle ICE" Martin, Just to make sure that I understand your position, I take you to be saying: =20 1) in the case where both endpoints have downloaded their apps from the sam= e server, they can do trickle ICE any way that they want. 2) in the case where an application is talking to an unknown or legacy pee= r, trickle ICE is a bad idea because there is no standard way to do it. (i= .e. try it at your own risk) Is this correct? - Jim=20 From stpeter@stpeter.im Mon Aug 27 13:45:43 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7041C21F853E for ; Mon, 27 Aug 2012 13:45:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BELWMrLPhgRs for ; Mon, 27 Aug 2012 13:45:42 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 7C22421F8532 for ; Mon, 27 Aug 2012 13:45:42 -0700 (PDT) Received: from [192.168.1.4] (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 1D4A2404EB; Mon, 27 Aug 2012 14:46:48 -0600 (MDT) Message-ID: <503BDC75.7050008@stpeter.im> Date: Mon, 27 Aug 2012 14:45:41 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Matthew Kaufman References: <3B8DB12B-ABB3-4AC2-A0A0-93DC62C619D3@iii.ca> In-Reply-To: X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Filling in details on "trickle ICE" X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 27 Aug 2012 20:45:43 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 8/27/12 2:42 PM, Matthew Kaufman wrote: > The "two different web servers" "trapezoid" case would require a > trunking protocol between these servers, such as SIP or Jingle, > which can describe "trickle ICE" such that the browsers could be > instructed properly by their respective web servers. > > I believe that with Jingle, there is a written spec for that, and > for SIP, there is not (at present). Correct: http://xmpp.org/extensions/xep-0176.html /psa -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlA73HUACgkQNL8k5A2w/vzzuwCgy6MeJzZVCM8d4RsW4brBP7Qi y8sAoIg6Dv7EEQnn1mcHq7iCPpBr4jjf =DsF9 -----END PGP SIGNATURE----- From bernard_aboba@hotmail.com Mon Aug 27 14:51:59 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1282E21F847F for ; Mon, 27 Aug 2012 14:51:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.349 X-Spam-Level: X-Spam-Status: No, score=-102.349 tagged_above=-999 required=5 tests=[AWL=0.249, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YhFwlKQ9A1bA for ; Mon, 27 Aug 2012 14:51:57 -0700 (PDT) Received: from blu0-omc4-s27.blu0.hotmail.com (blu0-omc4-s27.blu0.hotmail.com [65.55.111.166]) by ietfa.amsl.com (Postfix) with ESMTP id C0B9221F8495 for ; Mon, 27 Aug 2012 14:51:55 -0700 (PDT) Received: from BLU002-W228 ([65.55.111.136]) by blu0-omc4-s27.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 27 Aug 2012 14:51:53 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_1caa062c-84c3-4923-9ffd-9d2939a669ad_" X-Originating-IP: [24.16.96.166] From: Bernard Aboba To: Peter Saint-Andre Date: Mon, 27 Aug 2012 14:51:53 -0700 Importance: Normal In-Reply-To: <503BDC75.7050008@stpeter.im> References: <3B8DB12B-ABB3-4AC2-A0A0-93DC62C619D3@iii.ca>, , , , , <503BDC75.7050008@stpeter.im> MIME-Version: 1.0 X-OriginalArrivalTime: 27 Aug 2012 21:51:53.0207 (UTC) FILETIME=[2B6FF870:01CD849E] Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Filling in details on "trickle ICE" X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 27 Aug 2012 21:51:59 -0000 --_1caa062c-84c3-4923-9ffd-9d2939a669ad_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Right. =20 XEP-0176 Sections 5.5-5.9 does describe how various aspects of "Trickle IC= E" are handled in XMPP/Jingle=2C answering a number of the questions asked = in Eric's original post (see http://www.ietf.org/mail-archive/web/rtcweb/cu= rrent/msg05121.html). These sections are consistent with RFC 5245 with res= pect to STUN/TURN behavior=2C so that it isn't clear to me that a revision = of RFC 5245 is needed. Or am I missing something? Peter St. Andre said: >> I believe that with Jingle=2C there is a written spec for that=2C and f= or SIP=2C there is not (at present). >=20 > Correct: http://xmpp.org/extensions/xep-0176.html >=20 > /psa Eric Rescorla said: I've been working on doing Firefox's trickle ICE implementation and=0A= have had to make a bunch of decisions that suggest to me that perhaps=0A= we need an update to RFC 5245 to specify exactly how trickle ICE=0A= behaves. Here are some of the things we need to resolve..... = --_1caa062c-84c3-4923-9ffd-9d2939a669ad_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Right. =3B

 =3BX= EP-0176 Sections 5.5-5.9 does describe how various aspects of "Trickle ICE"= are handled in XMPP/Jingle=2C answering a number of the questions asked in= Eric's original post (see http://www.ietf.org/mail-archive/web/rtcweb/curr= ent/msg05121.html). =3B These sections are consistent with RFC 5245 wit= h respect to STUN/TURN behavior=2C so that it isn't clear to me that a revi= sion of RFC 5245 is needed. =3B Or am I missing something?

= Peter St. Andre said:

>=3B>=3B =3B I believe that with Jingl= e=2C there is a written spec for that=2C and for SIP=2C there is not (at pr= esent).
>=3B
>=3B Correct: http://xmpp.org/extensions/xep-0176.h= tml
>=3B
>=3B /psa

Eric Rescorla said:

I've b=
een working on doing Firefox's trickle ICE implementation and=0A=
have had to make a bunch of decisions that suggest to me that perhaps=0A=
we need an update to RFC 5245 to specify exactly how trickle ICE=0A=
behaves. Here are some of the things we need to resolve.....


<= /div>
= --_1caa062c-84c3-4923-9ffd-9d2939a669ad_-- From emil@sip-communicator.org Mon Aug 27 15:04:56 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE76711E8091 for ; Mon, 27 Aug 2012 15:04:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.98 X-Spam-Level: X-Spam-Status: No, score=-2.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3uWb1m9uHICJ for ; Mon, 27 Aug 2012 15:04:52 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8FC0021F8462 for ; Mon, 27 Aug 2012 15:04:52 -0700 (PDT) Received: by wicr5 with SMTP id r5so3088354wic.13 for ; Mon, 27 Aug 2012 15:04:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=5qnzLq1ZcaZ07d8VwHZtsSUf2YsAM1elQbYxurncv14=; b=TmTdTanvxpGPzHztNVYV3nlk1LcNPYBDJfcp2105l8nLO2LyjkbvAKtrpKrlaL/ajZ tn1TsFCLB5Hpc23CF98HWZxipYtI9zsw6CYsEKgMYXZYC6qjhqSEJMNDm8fx+6mvGU4M Wc8TjITlGXDqabkw6dta3DwRHa2M+I4jF6ymD2pmQhWvoitsNklbHgj+BaPMOR1DEwVJ L2HhlKW6dv687FqYvZnOvWsoURnj3CGiubR/9PN4Kc+mFWkguwigP/tF64H/hhO/NRtE 63LB/jY50Qwpm52DdlUTBFZxapJCpp5n7NxHv2ButFvZXrmVtfqrQyu1H8qMP3HaHnkw fIgQ== Received: by 10.180.105.6 with SMTP id gi6mr28380935wib.4.1346105087202; Mon, 27 Aug 2012 15:04:47 -0700 (PDT) Received: from camionet.local (93-57-0-240.ip162.fastwebnet.it. [93.57.0.240]) by mx.google.com with ESMTPS id cu1sm1485690wib.6.2012.08.27.15.04.42 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 27 Aug 2012 15:04:45 -0700 (PDT) Message-ID: <503BEEFD.40301@jitsi.org> Date: Tue, 28 Aug 2012 00:04:45 +0200 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Bernard Aboba References: <3B8DB12B-ABB3-4AC2-A0A0-93DC62C619D3@iii.ca>, , , , , <503BDC75.7050008@stpeter.im> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQnP+xkmUkIecfJ6VvdjZ6o8MmVCyTpoIgOpi+E8Mf29DE5CO1LrKeRNZiWWNVXDZYNmRFN/ Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Filling in details on "trickle ICE" X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 27 Aug 2012 22:04:57 -0000 On 27.08.12, 23:51, Bernard Aboba wrote: > Right. > > XEP-0176 Sections 5.5-5.9 does describe how various aspects of "Trickle > ICE" are handled in XMPP/Jingle, answering a number of the questions > asked in Eric's original post (see > http://www.ietf.org/mail-archive/web/rtcweb/current/msg05121.html). > These sections are consistent with RFC 5245 with respect to STUN/TURN > behavior, so that it isn't clear to me that a revision of RFC 5245 is > needed. Or am I missing something? Well an ICE stack that implements trickle as per XEP-0176 would currently not interoperate with a 5245 implementation or, at best, would lead to unpredictable results. The description in XEP-0176 is actually quite perfunctory and can't really be considered a proper specification. A document that describes a proper way of implementing this would hence be quite helpful. Emil > > Peter St. Andre said: > >>> I believe that with Jingle, there is a written spec for that, and > for SIP, there is not (at present). >> >> Correct: http://xmpp.org/extensions/xep-0176.html >> >> /psa > > Eric Rescorla said: > > I've been working on doing Firefox's trickle ICE implementation and > have had to make a bunch of decisions that suggest to me that perhaps > we need an update to RFC 5245 to specify exactly how trickle ICE > behaves. Here are some of the things we need to resolve..... > > > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > -- Emil Ivov, Ph.D. 67000 Strasbourg, Project Lead France Jitsi emcho@jitsi.org PHONE: +33.1.77.62.43.30 http://jitsi.org FAX: +33.1.77.62.47.31 From bernard_aboba@hotmail.com Mon Aug 27 15:29:12 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 056A621F845D for ; Mon, 27 Aug 2012 15:29:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.355 X-Spam-Level: X-Spam-Status: No, score=-102.355 tagged_above=-999 required=5 tests=[AWL=0.244, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g6irI-zt7gk1 for ; Mon, 27 Aug 2012 15:29:11 -0700 (PDT) Received: from blu0-omc4-s37.blu0.hotmail.com (blu0-omc4-s37.blu0.hotmail.com [65.55.111.176]) by ietfa.amsl.com (Postfix) with ESMTP id 798EE21F845C for ; Mon, 27 Aug 2012 15:29:11 -0700 (PDT) Received: from BLU169-DS45 ([65.55.111.137]) by blu0-omc4-s37.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 27 Aug 2012 15:29:10 -0700 X-Originating-IP: [24.16.96.166] X-EIP: [J697KQD/QPXQwjrvm5+jLxmQXniFtL/p] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: Bernard Aboba To: "'Emil Ivov'" References: <3B8DB12B-ABB3-4AC2-A0A0-93DC62C619D3@iii.ca>, , , , , <503BDC75.7050008@stpeter.im> <503BEEFD.40301@jitsi.org> In-Reply-To: <503BEEFD.40301@jitsi.org> Date: Mon, 27 Aug 2012 15:29:19 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH4Z3X5I7zcrx421Sos9AL76IZ9BAJvCnahAdiFK1ACgKa3jAGz5sLXAsrOx68ChET32QJMFXN+AitKuM4CAxiVZgJ/+26+AdDCUrACfNC2awJzCOrgAdiruaeWHX4mcA== Content-Language: en-us X-OriginalArrivalTime: 27 Aug 2012 22:29:10.0426 (UTC) FILETIME=[60EC7FA0:01CD84A3] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Filling in details on "trickle ICE" X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 27 Aug 2012 22:29:12 -0000 Emil Ivov said: Well an ICE stack that implements trickle as per XEP-0176 would currently not interoperate with a 5245 implementation or, at best, would lead to unpredictable results. The description in XEP-0176 is actually quite perfunctory and can't really be considered a proper specification. A document that describes a proper way of implementing this would hence be quite helpful. [BA] You are correct that XMPP/Jingle signaling will not be understood by a SIP UA. However, I don't see anything inherent in the use of STUN/TURN within XEP-0176 that violates RFC 5245. If the issue is lack of clarity in XEP-0176, shouldn't that be brought up in the XSF, which owns the specification? From francois.audet@skype.net Mon Aug 27 17:23:15 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72AFC11E8097 for ; Mon, 27 Aug 2012 17:23:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rkeg-nMEW7Di for ; Mon, 27 Aug 2012 17:23:15 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe003.messaging.microsoft.com [213.199.154.206]) by ietfa.amsl.com (Postfix) with ESMTP id 833A021F84D3 for ; Mon, 27 Aug 2012 17:23:14 -0700 (PDT) Received: from mail42-am1-R.bigfish.com (10.3.201.254) by AM1EHSOBE010.bigfish.com (10.3.204.30) with Microsoft SMTP Server id 14.1.225.23; Tue, 28 Aug 2012 00:23:12 +0000 Received: from mail42-am1 (localhost [127.0.0.1]) by mail42-am1-R.bigfish.com (Postfix) with ESMTP id 060BB1E005F; Tue, 28 Aug 2012 00:23:13 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC106.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -26 X-BigFish: VS-26(zz9371I542Mzz1202hzz1033IL8275dhz2fh2a8h668h839h944hd25hf0ah107ah1155h) Received-SPF: pass (mail42-am1: domain of skype.net designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=francois.audet@skype.net; helo=TK5EX14HUBC106.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail42-am1 (localhost.localdomain [127.0.0.1]) by mail42-am1 (MessageSwitch) id 1346113391181007_26264; Tue, 28 Aug 2012 00:23:11 +0000 (UTC) Received: from AM1EHSMHS016.bigfish.com (unknown [10.3.201.252]) by mail42-am1.bigfish.com (Postfix) with ESMTP id 200234004A; Tue, 28 Aug 2012 00:23:11 +0000 (UTC) Received: from TK5EX14HUBC106.redmond.corp.microsoft.com (131.107.125.8) by AM1EHSMHS016.bigfish.com (10.3.207.154) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 28 Aug 2012 00:23:10 +0000 Received: from TK5EX14MBXC272.redmond.corp.microsoft.com ([169.254.2.89]) by TK5EX14HUBC106.redmond.corp.microsoft.com ([157.54.80.61]) with mapi id 14.02.0318.003; Tue, 28 Aug 2012 00:23:08 +0000 From: Francois Audet To: Bernard Aboba , 'Emil Ivov' Thread-Topic: [rtcweb] Filling in details on "trickle ICE" Thread-Index: AQH4Z3X5I7zcrx421Sos9AL76IZ9BAJvCnahAdiFK1ACgKa3jAGz5sLXAsrOx68ChET32QJMFXN+AitKuM4CAxiVZgJ/+26+AdDCUrACfNC2awJzCOrgAdiruaeWHX4mcIAAIIbw Date: Tue, 28 Aug 2012 00:23:08 +0000 Message-ID: <66F9C712A970F74A8376BBE53013193C0DD0C76C@tk5ex14mbxc272.redmond.corp.microsoft.com> References: <3B8DB12B-ABB3-4AC2-A0A0-93DC62C619D3@iii.ca>, , , , , <503BDC75.7050008@stpeter.im> <503BEEFD.40301@jitsi.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.78] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: skype.net Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Filling in details on "trickle ICE" X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 28 Aug 2012 00:23:15 -0000 Wouldn't the same mechanism as XEP-0176 work with SIP too, by sending new o= ffer/answers with new candidates? In either cases, it is true that the "trapezoid" model makes this process m= ore difficult than with the "triangle" model. But you don't *have* to do trickle ICE don't you, in the trapezoid scenario= (especially when involving protocol mapping). -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= Bernard Aboba Sent: Monday, August 27, 2012 3:29 PM To: 'Emil Ivov' Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Filling in details on "trickle ICE" Emil Ivov said:=20 Well an ICE stack that implements trickle as per XEP-0176 would currently n= ot interoperate with a 5245 implementation or, at best, would lead to unpre= dictable results. The description in XEP-0176 is actually quite perfunctory and can't really = be considered a proper specification. A document that describes a proper way of implementing this would hence be = quite helpful. [BA] You are correct that XMPP/Jingle signaling will not be understood by = a SIP UA. However, I don't see anything inherent in the use of STUN/TURN=20 within XEP-0176 that violates RFC 5245. If the issue is lack of clarity in= XEP-0176, shouldn't that be brought up in the XSF, which owns the specific= ation? _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From kaiduanx@gmail.com Mon Aug 27 18:40:54 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E36D721F8495 for ; Mon, 27 Aug 2012 18:40:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tqghZRFkEJFZ for ; Mon, 27 Aug 2012 18:40:53 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 36E2A21F8493 for ; Mon, 27 Aug 2012 18:40:53 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so10772133obb.31 for ; Mon, 27 Aug 2012 18:40:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=RQDComcINKZtDubGj+kEGv2c/RMYl7SRSpEi3MRljM4=; b=EV1a34Zc0j1Qo3NiU1n0rD2E0paZ6H8ifzRRjBbnzuvdR0JFmAI+kWQmslfpN7ZEpv RlcrySm/UpxdjOinZyKd4BTnmGKO4Db5TsiO3KykZjScsCdb4ykOZK+l7y1/Wkpk0jrC xXdf0NfWGxuRsqKjwsvlPfiwQe/Rgle1W4mWiMGHMwwoCZ8y6Ddqyvgx6QeR5rIzPoTq Bh8pS+7mA0Yb0rfmBCF/g1pH0DI7YqzAwclztSPUlM4qBcx2YIbTXV3NGraaebDfDHsW drVu+N1ChbYpMpinXlBYO1xcAcRyaMS7OV2rAnQ/ML9AYyI8gtWJwVM/SuqpOTKS57IV a1Lg== MIME-Version: 1.0 Received: by 10.60.171.174 with SMTP id av14mr11716566oec.61.1346118052575; Mon, 27 Aug 2012 18:40:52 -0700 (PDT) Received: by 10.76.23.129 with HTTP; Mon, 27 Aug 2012 18:40:52 -0700 (PDT) Date: Mon, 27 Aug 2012 21:40:52 -0400 Message-ID: From: Kaiduan Xie To: rtcweb@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [rtcweb] Clarification on offer/answer in jsep-01 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 28 Aug 2012 01:40:54 -0000 Hi all, I do not understand the statement below from 4.2. Session Descriptions and State Machine "As in [RFC3264], an offerer can send an offer, and update it as long as it has not been answered." However, per rfc3264 http://tools.ietf.org/html/rfc3264 section 4 Protocol Operation, "At any time, either agent MAY generate a new offer that updates the session. However, it MUST NOT generate a new offer if it has received an offer which it has not yet answered or rejected. Furthermore, it MUST NOT generate a new offer if it has generated a prior offer for which it has not yet received an answer or a rejection." Please look the last sentence. Can anyone explain why JSEP introduces something different than RFC3264 please? Best regards, /Kaiduan From bernard_aboba@hotmail.com Mon Aug 27 20:12:55 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ACF821F848B for ; Mon, 27 Aug 2012 20:12:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.359 X-Spam-Level: X-Spam-Status: No, score=-102.359 tagged_above=-999 required=5 tests=[AWL=0.239, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9xuwiZiYDofS for ; Mon, 27 Aug 2012 20:12:54 -0700 (PDT) Received: from blu0-omc1-s28.blu0.hotmail.com (blu0-omc1-s28.blu0.hotmail.com [65.55.116.39]) by ietfa.amsl.com (Postfix) with ESMTP id 72BCB21F842F for ; Mon, 27 Aug 2012 20:12:54 -0700 (PDT) Received: from BLU002-W161 ([65.55.116.7]) by blu0-omc1-s28.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 27 Aug 2012 20:12:53 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_92527f5c-e9ac-4243-b55f-d9c7c3c400f5_" X-Originating-IP: [24.16.96.166] From: Bernard Aboba To: Francois Audet Date: Mon, 27 Aug 2012 20:12:54 -0700 Importance: Normal In-Reply-To: <66F9C712A970F74A8376BBE53013193C0DD0C76C@tk5ex14mbxc272.redmond.corp.microsoft.com> References: <3B8DB12B-ABB3-4AC2-A0A0-93DC62C619D3@iii.ca>, , , , , , , , , , <503BDC75.7050008@stpeter.im> , <503BEEFD.40301@jitsi.org> , <66F9C712A970F74A8376BBE53013193C0DD0C76C@tk5ex14mbxc272.redmond.corp.microsoft.com> MIME-Version: 1.0 X-OriginalArrivalTime: 28 Aug 2012 03:12:53.0685 (UTC) FILETIME=[0393AE50:01CD84CB] Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Filling in details on "trickle ICE" X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 28 Aug 2012 03:12:55 -0000 --_92527f5c-e9ac-4243-b55f-d9c7c3c400f5_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Francois said:=20 > Wouldn't the same mechanism as XEP-0176 work with SIP too=2C by sending n= ew offer/answers with new candidates? >=20 > In either cases=2C it is true that the "trapezoid" model makes this proce= ss more difficult than with the "triangle" model. >=20 > But you don't *have* to do trickle ICE don't you=2C in the trapezoid scen= ario (especially when involving protocol mapping). [BA] Looking at XEP-0176 Section 5.8=2C it does seem possible to use new o= ffer/answers with new candidates to similar effect. Here is what Section 5= .8 says:=20 =0A= =0A= Section 5.8 Negotiating a new candidate =0A= =0A= Even after media has begun to flow=2C either party MAY continue to send =0A= additional candidates to the other party (e.g.=2C because the user agent = =0A= has become aware of a new media proxy or network interface card). Such =0A= candidates are shared by sending a transport-info message.... The =0A= receiving party MUST acknowledge receipt of the candidate. The parties =0A= would check the newly-offered candidate for =0A= connectivity=2C as described previously. If the parties determine that =0A= media can flow over the candidate=2C they MAY then use the new candidate = =0A= in subsequent communications. =20 =0A= =0A= [BA] If ICE completed and media was already flowing=2C the controlling age= nt can generate a RE-INVITE with a candidate from the in-use pair as the de= fault as well as additional candidates. There is no need to do an ICE rest= art. As described in RFC 5245 Section 8.1.2=2C if the additional candidate= ends up in a highest-priority nominated candidate-pair=2C then an updated = offer is sent:=20 =0A= * If an agent is controlling=2C it examines the highest-priority=0A= nominated candidate pair for each component of each media=0A= stream. If any of those candidate pairs differ from the=0A= default candidate pairs in the most recent offer/answer=0A= exchange=2C the controlling agent MUST generate an updated offer= =0A= as described in Section 9. If the controlling agent is using=0A= an aggressive nomination algorithm=2C this may result in several= =0A= updated offers as the pairs selected for media change. An=0A= agent MAY delay sending the offer for a brief interval (one=0A= second is RECOMMENDED) in order to allow the selected pairs to=0A= stabilize.=0A= Details of the updated offer are described in RFC 5245 Section 9.1.2.2: =0A= =0A= If an agent generates an updated offer including a media stream that=0A= was previously established=2C and for which ICE checks are in the=0A= Completed state=2C the agent follows the procedures defined here.=0A= =0A= The default destination for media (i.e.=2C the values of the IP=0A= addresses and ports in the m and c lines used for that media stream)=0A= MUST be the local candidate from the highest-priority nominated pair=0A= in the valid list for each component. This "fixes" the default=0A= destination for media to equal the destination ICE has selected for=0A= media.=0A= =0A= The agent MUST include candidate attributes for candidates matching=0A= the default destination for each component of the media stream=2C and=0A= MUST NOT include any other candidates.=0A= =0A= In addition=2C if the agent is controlling=2C it MUST include the=0A= a=3Dremote-candidates attribute for each media stream whose check list= =0A= is in the Completed state. The attribute contains the remote=0A= candidates from the highest-priority nominated pair in the valid list=0A= for each component of that media stream. It is needed to avoid a=0A= race condition whereby the controlling agent chooses its pairs=2C but=0A= the updated offer beats the connectivity checks to the controlled=0A= agent=2C which doesn't even know these pairs are valid=2C let alone=0A= selected. See Appendix B.6 for elaboration on this race condition. = --_92527f5c-e9ac-4243-b55f-d9c7c3c400f5_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Francois said:

>= =3B Wouldn't the same mechanism as XEP-0176 work with SIP too=2C by sending= new offer/answers with new candidates?
>=3B
>=3B In either case= s=2C it is true that the "trapezoid" model makes this process more difficul= t than with the "triangle" model.
>=3B
>=3B But you don't *have*= to do trickle ICE don't you=2C in the trapezoid scenario (especially when = involving protocol mapping).

[BA] =3B Looking at XEP-0176 Sectio= n 5.8=2C it does seem possible to use new offer/answers with new candidates= to similar effect. =3B Here is what Section 5.8 says:
=0A=
=0A= Section 5.8 Negotiating a new candidate
=0A=
=0A= Even after media has begun to flow=2C either party MAY continue to send =0A= additional candidates to the other party (e.g.=2C because the user agent = =0A= has become aware of a new media proxy or network interface card). Such =0A= candidates are shared by sending a transport-info message.... =3B The = =0A= receiving party MUST acknowledge receipt of the candidate. The parties =0A= would check the newly-offered candidate for =0A= connectivity=2C as described previously. If the parties determine that =0A= media can flow over the candidate=2C they MAY then use the new candidate = =0A= in subsequent communications. =3B
=0A=
=0A= [BA] =3B If ICE completed and media was already flowing=2C the controll= ing agent can generate a RE-INVITE with a candidate from the in-use pair as= the default as well as additional candidates. =3B There is no need to = do an ICE restart. =3B As described in RFC 5245 Section 8.1.2=2C if the= additional candidate ends up in a highest-priority nominated candidate-pai= r=2C then an updated offer is sent:


=0A= 
      *  If an agent is controlling=2C it examines the highest-priorit=
y=0A=
         nominated candidate pair for each component of each media=0A=
         stream.  If any of those candidate pairs differ from the=0A=
         default candidate pairs in the most recent offer/answer=0A=
         exchange=2C the controlling agent MUST generate an updated offer=
=0A=
         as described in Section 9.  If the controlling agent is using=0A=
         an aggressive nomination algorithm=2C this may result in several=
=0A=
         updated offers as the pairs selected for media change.  An=0A=
         agent MAY delay sending the offer for a brief interval (one=0A=
         second is RECOMMENDED) in order to allow the selected pairs to=0A=
         stabilize.
=0A=
Details of the updated offer are described in RFC 5245 Section 9.1.2.2:= 
=0A=
=0A=
   If an agent generates an updated offer including a media stream that=0A=
   was previously established=2C and for which ICE checks are in the=0A=
   Completed state=2C the agent follows the procedures defined here.=0A=
=0A=
   The default destination for media (i.e.=2C the values of the IP=0A=
   addresses and ports in the m and c lines used for that media stream)=0A=
   MUST be the local candidate from the highest-priority nominated pair=0A=
   in the valid list for each component.  This "fixes" the default=0A=
   destination for media to equal the destination ICE has selected for=0A=
   media.=0A=
=0A=
   The agent MUST include candidate attributes for candidates matching=0A=
   the default destination for each component of the media stream=2C and=0A=
   MUST NOT include any other candidates.=0A=
=0A=
   In addition=2C if the agent is controlling=2C it MUST include the=0A=
   a=3Dremote-candidates attribute for each media stream whose check list=
=0A=
   is in the Completed state.  The attribute contains the remote=0A=
   candidates from the highest-priority nominated pair in the valid list=0A=
   for each component of that media stream.  It is needed to avoid a=0A=
   race condition whereby the controlling agent chooses its pairs=2C but=0A=
   the updated offer beats the connectivity checks to the controlled=0A=
   agent=2C which doesn't even know these pairs are valid=2C let alone=0A=
   selected.  See Appendix B.6 for elaboration on this race condition.
= --_92527f5c-e9ac-4243-b55f-d9c7c3c400f5_-- From francois.audet@skype.net Mon Aug 27 21:40:54 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74F9311E80AE for ; Mon, 27 Aug 2012 21:40:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5+G+dnnc+q9r for ; Mon, 27 Aug 2012 21:40:53 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe005.messaging.microsoft.com [216.32.180.31]) by ietfa.amsl.com (Postfix) with ESMTP id 5D74C11E808E for ; Mon, 27 Aug 2012 21:40:53 -0700 (PDT) Received: from mail220-va3-R.bigfish.com (10.7.14.248) by VA3EHSOBE009.bigfish.com (10.7.40.29) with Microsoft SMTP Server id 14.1.225.23; Tue, 28 Aug 2012 04:40:51 +0000 Received: from mail220-va3 (localhost [127.0.0.1]) by mail220-va3-R.bigfish.com (Postfix) with ESMTP id AACDE20314; Tue, 28 Aug 2012 04:40:51 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC104.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: 1 X-BigFish: VS1(zz98dIc85fh1432Izz1202hzz8275bhz2fh2a8h668h839hd25he5bhf0ah107ahbe3k) Received-SPF: pass (mail220-va3: domain of skype.net designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=francois.audet@skype.net; helo=TK5EX14MLTC104.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail220-va3 (localhost.localdomain [127.0.0.1]) by mail220-va3 (MessageSwitch) id 1346128850462057_12110; Tue, 28 Aug 2012 04:40:50 +0000 (UTC) Received: from VA3EHSMHS011.bigfish.com (unknown [10.7.14.239]) by mail220-va3.bigfish.com (Postfix) with ESMTP id 6AA04C00045; Tue, 28 Aug 2012 04:40:50 +0000 (UTC) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (131.107.125.8) by VA3EHSMHS011.bigfish.com (10.7.99.21) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 28 Aug 2012 04:40:50 +0000 Received: from TK5EX14MBXC272.redmond.corp.microsoft.com ([169.254.2.89]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.02.0318.003; Tue, 28 Aug 2012 04:40:48 +0000 From: Francois Audet To: Bernard Aboba Thread-Topic: [rtcweb] Filling in details on "trickle ICE" Thread-Index: AQH4Z3X5I7zcrx421Sos9AL76IZ9BAJvCnahAdiFK1ACgKa3jAGz5sLXAsrOx68ChET32QJMFXN+AitKuM4CAxiVZgJ/+26+AdDCUrACfNC2awJzCOrgAdiruaeWHX4mcIAAIIbwgAAxCgCAABiOOA== Date: Tue, 28 Aug 2012 04:40:47 +0000 Message-ID: References: <3B8DB12B-ABB3-4AC2-A0A0-93DC62C619D3@iii.ca>, , , , , , , , , , <503BDC75.7050008@stpeter.im> , <503BEEFD.40301@jitsi.org> , <66F9C712A970F74A8376BBE53013193C0DD0C76C@tk5ex14mbxc272.redmond.corp.microsoft.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_DDFF5412966F47C8B7773C57E96AD689skypenet_" MIME-Version: 1.0 X-OriginatorOrg: skype.net Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Filling in details on "trickle ICE" X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 28 Aug 2012 04:40:54 -0000 --_000_DDFF5412966F47C8B7773C57E96AD689skypenet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes, this is exactly the section of 5245 I was referring to. Seems to be ef= fectively trickling. On Aug 27, 2012, at 20:12, "Bernard Aboba" > wrote: Francois said: > Wouldn't the same mechanism as XEP-0176 work with SIP too, by sending new= offer/answers with new candidates? > > In either cases, it is true that the "trapezoid" model makes this process= more difficult than with the "triangle" model. > > But you don't *have* to do trickle ICE don't you, in the trapezoid scenar= io (especially when involving protocol mapping). [BA] Looking at XEP-0176 Section 5.8, it does seem possible to use new off= er/answers with new candidates to similar effect. Here is what Section 5.8= says: Section 5.8 Negotiating a new candidate Even after media has begun to flow, either party MAY continue to send addit= ional candidates to the other party (e.g., because the user agent has becom= e aware of a new media proxy or network interface card). Such candidates ar= e shared by sending a transport-info message.... The receiving party MUST = acknowledge receipt of the candidate. The parties would check the newly-off= ered candidate for connectivity, as described previously. If the parties de= termine that media can flow over the candidate, they MAY then use the new c= andidate in subsequent communications. [BA] If ICE completed and media was already flowing, the controlling agent= can generate a RE-INVITE with a candidate from the in-use pair as the defa= ult as well as additional candidates. There is no need to do an ICE restar= t. As described in RFC 5245 Section 8.1.2, if the additional candidate end= s up in a highest-priority nominated candidate-pair, then an updated offer = is sent: * If an agent is controlling, it examines the highest-priority nominated candidate pair for each component of each media stream. If any of those candidate pairs differ from the default candidate pairs in the most recent offer/answer exchange, the controlling agent MUST generate an updated offer as described in Section 9. If the controlling agent is using an aggressive nomination algorithm, this may result in several updated offers as the pairs selected for media change. An agent MAY delay sending the offer for a brief interval (one second is RECOMMENDED) in order to allow the selected pairs to stabilize. Details of the updated offer are described in RFC 5245 Section 9.1.2.2: If an agent generates an updated offer including a media stream that was previously established, and for which ICE checks are in the Completed state, the agent follows the procedures defined here. The default destination for media (i.e., the values of the IP addresses and ports in the m and c lines used for that media stream) MUST be the local candidate from the highest-priority nominated pair in the valid list for each component. This "fixes" the default destination for media to equal the destination ICE has selected for media. The agent MUST include candidate attributes for candidates matching the default destination for each component of the media stream, and MUST NOT include any other candidates. In addition, if the agent is controlling, it MUST include the a=3Dremote-candidates attribute for each media stream whose check list is in the Completed state. The attribute contains the remote candidates from the highest-priority nominated pair in the valid list for each component of that media stream. It is needed to avoid a race condition whereby the controlling agent chooses its pairs, but the updated offer beats the connectivity checks to the controlled agent, which doesn't even know these pairs are valid, let alone selected. See Appendix B.6 for elaboration on this race condition. --_000_DDFF5412966F47C8B7773C57E96AD689skypenet_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Yes, this is exactly the section of 5245 I was referring to. Seems to = be effectively trickling.

On Aug 27, 2012, at 20:12, "Bernard Aboba" <bernard_aboba@hotmail.com> wrote:

Francois said:

> Wouldn't the same mechanism as XEP-0176 work with SIP too, by sen= ding new offer/answers with new candidates?
>
> In either cases, it is true that the "trapezoid" model makes= this process more difficult than with the "triangle" model.
>
> But you don't *have* to do trickle ICE don't you, in the trapezoid sce= nario (especially when involving protocol mapping).

[BA]  Looking at XEP-0176 Section 5.8, it does seem possible to use ne= w offer/answers with new candidates to similar effect.  Here is what S= ection 5.8 says:

Section 5.8 Negotiating a new candidate

Even after media has begun to flow, either party MAY continue to send addit= ional candidates to the other party (e.g., because the user agent has becom= e aware of a new media proxy or network interface card). Such candidates ar= e shared by sending a transport-info message....  The receiving party MUST acknowledge receipt of the cand= idate. The parties would check the newly-offered candidate for connectivity= , as described previously. If the parties determine that media can flow ove= r the candidate, they MAY then use the new candidate in subsequent communications. 

[BA]  If ICE completed and media was already flowing, the controlling = agent can generate a RE-INVITE with a candidate from the in-use pair as the= default as well as additional candidates.  There is no need to do an = ICE restart.  As described in RFC 5245 Section 8.1.2, if the additional candidate ends up in a highest-priority nominated= candidate-pair, then an updated offer is sent: 


      *  If an agent is controlling, it examines the highest-priority
         nominated candidate pair for each component of each media
         stream.  If any of those candidate pairs differ from the
         default candidate pairs in the most recent offer/answer
         exchange, the controlling agent MUST generate an updated offer
         as described in Section 9.  If the controlling agent is using
         an aggressive nomination algorithm, this may result in several
         updated offers as the pairs selected for media change.  An
         agent MAY delay sending the offer for a brief interval (one
         second is RECOMMENDED) in order to allow the selected pairs to
         stabilize.

Details of the updated offer are described in RFC 5245 Section 9.1.2.2:
   If an agent generates an updated offer including a media stream that
   was previously established, and for which ICE checks are in the
   Completed state, the agent follows the procedures defined here.

   The default destination for media (i.e., the values of the IP
   addresses and ports in the m and c lines used for that media stream)
   MUST be the local candidate from the highest-priority nominated pair
   in the valid list for each component.  This "fixes" the defaul=
t
   destination for media to equal the destination ICE has selected for
   media.

   The agent MUST include candidate attributes for candidates matching
   the default destination for each component of the media stream, and
   MUST NOT include any other candidates.

   In addition, if the agent is controlling, it MUST include the
   a=3Dremote-candidates attribute for each media stream whose check list
   is in the Completed state.  The attribute contains the remote
   candidates from the highest-priority nominated pair in the valid list
   for each component of that media stream.  It is needed to avoid a
   race condition whereby the controlling agent chooses its pairs, but
   the updated offer beats the connectivity checks to the controlled
   agent, which doesn't even know these pairs are valid, let alone
   selected.  See Appendix B.6 for elaboration on this race condition.
--_000_DDFF5412966F47C8B7773C57E96AD689skypenet_-- From francois.audet@skype.net Mon Aug 27 21:48:15 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E42A21F8474 for ; Mon, 27 Aug 2012 21:48:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d-proz3IpgjI for ; Mon, 27 Aug 2012 21:48:14 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe003.messaging.microsoft.com [213.199.154.206]) by ietfa.amsl.com (Postfix) with ESMTP id D350A11E808E for ; Mon, 27 Aug 2012 21:48:13 -0700 (PDT) Received: from mail58-am1-R.bigfish.com (10.3.201.248) by AM1EHSOBE010.bigfish.com (10.3.204.30) with Microsoft SMTP Server id 14.1.225.23; Tue, 28 Aug 2012 04:48:11 +0000 Received: from mail58-am1 (localhost [127.0.0.1]) by mail58-am1-R.bigfish.com (Postfix) with ESMTP id D99F260059; Tue, 28 Aug 2012 04:48:11 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC106.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -17 X-BigFish: VS-17(zz98dI1432I14ffIzz1202hzz1033IL8275bh8275dhz2fh2a8h668h839h944hd25he5bhf0ah107ah8f2n1155h) Received-SPF: pass (mail58-am1: domain of skype.net designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=francois.audet@skype.net; helo=TK5EX14HUBC106.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail58-am1 (localhost.localdomain [127.0.0.1]) by mail58-am1 (MessageSwitch) id 1346129289823833_23431; Tue, 28 Aug 2012 04:48:09 +0000 (UTC) Received: from AM1EHSMHS020.bigfish.com (unknown [10.3.201.245]) by mail58-am1.bigfish.com (Postfix) with ESMTP id C70802E0045; Tue, 28 Aug 2012 04:48:09 +0000 (UTC) Received: from TK5EX14HUBC106.redmond.corp.microsoft.com (131.107.125.8) by AM1EHSMHS020.bigfish.com (10.3.207.158) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 28 Aug 2012 04:48:09 +0000 Received: from TK5EX14MBXC272.redmond.corp.microsoft.com ([169.254.2.89]) by TK5EX14HUBC106.redmond.corp.microsoft.com ([157.54.80.61]) with mapi id 14.02.0318.003; Tue, 28 Aug 2012 04:48:07 +0000 From: Francois Audet To: Kaiduan Xie Thread-Topic: [rtcweb] Clarification on offer/answer in jsep-01 Thread-Index: AQHNhL5ATwCPK9RddUyMLXZ9gnO4B5dupybo Date: Tue, 28 Aug 2012 04:48:07 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: skype.net Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Clarification on offer/answer in jsep-01 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 28 Aug 2012 04:48:15 -0000 Indeed, this appear to contradict 3264, and would cause breakage. On Aug 27, 2012, at 18:41, "Kaiduan Xie" wrote: > Hi all, >=20 > I do not understand the statement below from 4.2. Session Descriptions > and State Machine >=20 > "As in [RFC3264], an offerer can send an offer, and update it as long > as it has not been answered." >=20 > However, per rfc3264 http://tools.ietf.org/html/rfc3264 section 4 > Protocol Operation, >=20 > "At any time, either agent MAY generate a new offer that updates the > session. However, it MUST NOT generate a new offer if it has > received an offer which it has not yet answered or rejected. > Furthermore, it MUST NOT generate a new offer if it has generated a > prior offer for which it has not yet received an answer or a > rejection." >=20 > Please look the last sentence. Can anyone explain why JSEP introduces > something different than RFC3264 please? >=20 > Best regards, >=20 > /Kaiduan > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 From emil@sip-communicator.org Mon Aug 27 23:04:06 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E38CB11E809C for ; Mon, 27 Aug 2012 23:04:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.98 X-Spam-Level: X-Spam-Status: No, score=-2.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OVe69wf2csZ7 for ; Mon, 27 Aug 2012 23:04:06 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id CCE6111E809A for ; Mon, 27 Aug 2012 23:04:05 -0700 (PDT) Received: by weyu54 with SMTP id u54so3029348wey.31 for ; Mon, 27 Aug 2012 23:04:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=5gYx42ASn2S1r9kXZV7F0BUqC+Lo8CFDeP7b7b7RrHo=; b=BxC6T5Yhn4lrXbidlamcO7+nJaMfXGlC0C/XCdlpYtBW+1BJNz4gDEwjBLMLbPQpDN sDLz2qPeYT/DXDTuLuV9cdpqC8SsG1Drts2gdifaLUWUZzCXyfX9WBMdVrnW4FkXPlwW R1ggxjmwhUT2bOFXXy8Zvkg3ESTjJ5xIZ8ogNhVstEjeL3EB8WKNn45j6hKC9bGaNOzk SxoSfFQn5aVcTXTcrYxtye9gLoAPpYlFBM/R0/cF6Da0f4JaCQFF5XpojpOhDsWJrk9a K4d4ZrAjvrwbeHV6WFcl3dRfYDnhUcyqGjNDYtS7bmU3nJuAgynagf+BIHnAO1QEw/Al fNUA== Received: by 10.180.77.34 with SMTP id p2mr30557815wiw.0.1346133844852; Mon, 27 Aug 2012 23:04:04 -0700 (PDT) Received: from camionet.local (93-57-0-240.ip162.fastwebnet.it. [93.57.0.240]) by mx.google.com with ESMTPS id eu4sm3202852wib.2.2012.08.27.23.04.00 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 27 Aug 2012 23:04:02 -0700 (PDT) Message-ID: <503C5F54.5000309@jitsi.org> Date: Tue, 28 Aug 2012 08:04:04 +0200 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Bernard Aboba References: <3B8DB12B-ABB3-4AC2-A0A0-93DC62C619D3@iii.ca>, , , , , <503BDC75.7050008@stpeter.im> <503BEEFD.40301@jitsi.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQk9KVWBLvFCK+5DaErIFrzOqb2E17narFNqKrRlt82ucV9UHzKCE51zHf8IaaszuOi1/ly+ Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Filling in details on "trickle ICE" X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 28 Aug 2012 06:04:07 -0000 On 28.08.12, 00:29, Bernard Aboba wrote: > Emil Ivov said: > >> Well an ICE stack that implements trickle as per XEP-0176 would currently >> not interoperate with a 5245 implementation or, at best, would lead to >> unpredictable results. >> >> The description in XEP-0176 is actually quite perfunctory and can't really >> be considered a proper specification. >> >> A document that describes a proper way of implementing this would hence be >> quite helpful. > > [BA] You are correct that XMPP/Jingle signaling will not be understood by a > SIP UA. Right. And of course, I was not referring to signalling. > However, I don't see anything inherent in the use of STUN/TURN > within XEP-0176 that violates RFC 5245. It's more about ICE processing rather than STUN and TURN and the fact that, if an ICE implementation is not prepared to handle trickling it would not work well with one that does. (more below) >From your other mail: > Details of the updated offer are described in RFC 5245 Section 9.1.2.2: I am not sure how 9.1.2.2 would apply here given that it's about sending updated offers once ICE has completed. It even says that: The agent MUST include candidate attributes for candidates matching the default destination for each component of the media stream, and MUST NOT include any other candidates. Did you instead mean to quote section 9.1.2.1 which contains the following: The agent MAY include additional candidates it did not offer previously, but which it has gathered since the last offer/answer exchange, including peer reflexive candidates. 9.1.2.1 does indeed refer to updating ICE for "Existing Media Streams with ICE Running". While I agree that this does look like trickling I am not sure it was intended to be used in exactly the same way that we are discussing here and the text is not enough to cover a proper trickling implementation. The main issue is that there's currently nothing in 5245 that would allow an agent to determine if more candidates are to be expected. If trickling is in use there's no way for a controlled agent to know that (or if) more candidates are to be expected. This creates a race condition which may result in the controlled agent moving into the "ICE Failed" state before it has received all candidates from the controlling agent. Such premature failures can happen very easily if the first offer only contains addresses that can be determined as unusable without even running any checks. This would be the case for an IPv4-only host receiving an offer with IPv6 candidates only (and vice versa). One can probably come up with a few more cases like this one. > If the issue is lack of clarity in > XEP-0176, shouldn't that be brought up in the XSF, which owns the > specification? Nope, XEP-0176 would be crystal clear if the IETF comes up with a document that explains how ICE agents should behave in situations where addresses continue to arrive after the original offer. Emil -- https://jitsi.org From emil@sip-communicator.org Mon Aug 27 23:11:27 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0866021F849A for ; Mon, 27 Aug 2012 23:11:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.68 X-Spam-Level: X-Spam-Status: No, score=-2.68 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5IQivmszMwdT for ; Mon, 27 Aug 2012 23:11:26 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 31BAE21F8497 for ; Mon, 27 Aug 2012 23:11:26 -0700 (PDT) Received: by weyu54 with SMTP id u54so3032773wey.31 for ; Mon, 27 Aug 2012 23:11:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=6bXUTcS+sJ4Ko+kTRC/mmRMsQq2DIrq+BSsmmP53clQ=; b=XyugTv3KZ88+wt8oZDc4v/KE66nx8dcIr28MdmhkOIgI/9NZq8ssH3ws227j+BYvWZ EhJDuIQEdm8SyYzn6WtyOABe9LGNE5wNBY2WVa7yQgyCrJRkr29FBruUgIsIBn+eQSW6 rr6q2ht0VzCDkcg12mBAz+49xs1McJAowhBEAE98CXIzTZL5g0uOYdrLRWfiy/XAdZx8 dO/u37Vl7f43UWLVZLG9R5/SkMbWEX7hQPw9CZMZBSxtLeejPEQ3F7h5qHcJSHFiWxdK ex4qaTGIuzT37EY0vz+AJKMoX0lRCSooHrvLTQ1lnIRU2ZXwVSkvif2/G6tH0tD/HHHH JHYA== Received: by 10.180.109.166 with SMTP id ht6mr30554125wib.11.1346134285221; Mon, 27 Aug 2012 23:11:25 -0700 (PDT) Received: from camionet.local (93-57-0-240.ip162.fastwebnet.it. [93.57.0.240]) by mx.google.com with ESMTPS id fb20sm4974209wid.1.2012.08.27.23.11.21 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 27 Aug 2012 23:11:23 -0700 (PDT) Message-ID: <503C610D.106@jitsi.org> Date: Tue, 28 Aug 2012 08:11:25 +0200 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Bernard Aboba References: <3B8DB12B-ABB3-4AC2-A0A0-93DC62C619D3@iii.ca>, , , , , <503BDC75.7050008@stpeter.im> <503BEEFD.40301@jitsi.org> <503C5F54.5000309@jitsi.org> In-Reply-To: <503C5F54.5000309@jitsi.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQlJdZCSfEk/JILaA36InE7seuQZGK2XQmfma5l+LAQgRs7J7NJkJ2hVFgykS7JGKNJe6QHv Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Filling in details on "trickle ICE" X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 28 Aug 2012 06:11:27 -0000 On 28.08.12, 08:04, Emil Ivov wrote: > The main issue is that there's currently nothing in 5245 that would > allow an agent to determine if more candidates are to be expected. If > trickling is in use there's no way for a controlled agent to know that > (or if) more candidates are to be expected. This creates a race > condition which may result in the controlled agent moving into the "ICE > Failed" state before it has received all candidates from the controlling > agent. I just noticed that this is also what Eric's original mail was about, so I suppose I just second his concern. We had the issue in ice4j and we basically just had to implement and tune it in a way that would work against other common ICE impls. Text that specifies exactly how this is to be done would have been most helpful. Emil -- https://jitsi.org From srikar.rao@wipro.com Tue Aug 28 04:42:54 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14BB711E80F8 for ; Tue, 28 Aug 2012 04:42:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.605 X-Spam-Level: X-Spam-Status: No, score=-5.605 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ij1COiHei9sP for ; Tue, 28 Aug 2012 04:42:53 -0700 (PDT) Received: from wipro-blr-out02.wipro.com (wipro-blr-out02.wipro.com [203.91.198.75]) by ietfa.amsl.com (Postfix) with ESMTP id BF9AA11E80F1 for ; Tue, 28 Aug 2012 04:42:52 -0700 (PDT) X-AuditID: cb5bdd58-b7ca2ae000002fa2-9c-503cae985820 Received: from BLR-OUT-EDG02.wipro.com ( [203.91.193.32]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by wipro-blr-out02.wipro.com (Symantec Mail Security) with SMTP id FF.B2.12194.89EAC305; Tue, 28 Aug 2012 17:12:17 +0530 (IST) Received: from BLR-EC-MBX1.wipro.com (10.208.51.111) by BLR-OUT-EDG02.wipro.com (203.91.193.32) with Microsoft SMTP Server (TLS) id 14.1.289.1; Tue, 28 Aug 2012 17:12:39 +0530 Received: from BLR-EC-MBX5.wipro.com ([169.254.5.227]) by BLR-EC-MBX1.wipro.com ([169.254.1.142]) with mapi id 14.01.0289.001; Tue, 28 Aug 2012 17:07:25 +0530 From: To: Thread-Topic: [rtcweb] Clarification on offer/answer in jsep-01 Thread-Index: AQHNhQZUs0JdTgaNoUW25ohhRySTWQ== Date: Tue, 28 Aug 2012 11:37:25 +0000 Message-ID: <8F7FA418597B9740837816893B77672E453AE0F9@BLR-EC-MBX5.wipro.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.201.51.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [rtcweb] Clarification on offer/answer in jsep-01 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 28 Aug 2012 11:42:54 -0000 > "As in [RFC3264], an offerer can send an offer, and update it as long > as it has not been answered." That statement doesn't comply to [RFC3264] on the same level as PRANSWER do= esn't. PRANSWER may not directly fit in the offer-answer pair model of [RFC= 3264] as indicated in . But it is considered just an API construct to feed-in evolving ans= wers (probably from different sources) to local media elements. =20 Similarly, Offer-updated-before-Answer may be meant as evolving-offer(Can't= imagine a use-case except new ICE candidates). The statement definitely needs clarification, specially because it starts w= ith "As in [RFC3264]...". In general, it looks like JSEP-01 picks up rules pertaining to construction= of Offers/Answers from [RFC3264] but is not exactly in-line with the O/A e= xchange part of [RFC3264]. Regards, Srikar. ------------------------------ --Original Message-- Message: 2 Date: Tue, 28 Aug 2012 04:48:07 +0000 From: Francois Audet To: Kaiduan Xie Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Clarification on offer/answer in jsep-01 Message-ID: Content-Type: text/plain; charset=3D"us-ascii" Indeed, this appear to contradict 3264, and would cause breakage. On Aug 27, 2012, at 18:41, "Kaiduan Xie" wrote: > Hi all, > > I do not understand the statement below from 4.2. Session Descriptions > and State Machine > > "As in [RFC3264], an offerer can send an offer, and update it as long > as it has not been answered." > > However, per rfc3264 http://tools.ietf.org/html/rfc3264 section 4 > Protocol Operation, > > "At any time, either agent MAY generate a new offer that updates the > session. However, it MUST NOT generate a new offer if it has > received an offer which it has not yet answered or rejected. > Furthermore, it MUST NOT generate a new offer if it has generated a > prior offer for which it has not yet received an answer or a > rejection." > > Please look the last sentence. Can anyone explain why JSEP introduces > something different than RFC3264 please? > > Best regards, > > /Kaiduan > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > ------------------------------ From stefan.lk.hakansson@ericsson.com Tue Aug 28 05:36:41 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9113311E80DF for ; Tue, 28 Aug 2012 05:36:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.054 X-Spam-Level: X-Spam-Status: No, score=-6.054 tagged_above=-999 required=5 tests=[AWL=0.195, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7y5EmDOx-BDK for ; Tue, 28 Aug 2012 05:36:37 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 3C49A11E80D3 for ; Tue, 28 Aug 2012 05:36:37 -0700 (PDT) X-AuditID: c1b4fb30-b7f7d6d0000042ea-21-503cbb539edc Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id CE.77.17130.35BBC305; Tue, 28 Aug 2012 14:36:36 +0200 (CEST) Received: from [150.132.142.246] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.264.1; Tue, 28 Aug 2012 14:36:35 +0200 Message-ID: <503CBB52.8070300@ericsson.com> Date: Tue, 28 Aug 2012 14:36:34 +0200 From: Stefan Hakansson LK User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: "rtcweb@ietf.org" References: <9E2843EA-EBB9-40B3-898C-6B5216FAE7A5@cisco.com> In-Reply-To: <9E2843EA-EBB9-40B3-898C-6B5216FAE7A5@cisco.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJJMWRmVeSWpSXmKPExsUyM+JvrW7IbpsAgyXveCzW/mtnd2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxtPr/awFr40qDvb+YGlgPKrZxcjJISFgIrHsy0xmCFtM4sK9 9WxdjFwcQgKnGCWOvrjOCuGsZZS4ue86WBWvgLbExsuL2EBsFgFVicmvmsFsNgEbibXdU5hA bFGBEIk136YwQtQLSpyc+YQFxBYRUJe4/PACO4gtLGAvsfHEf7AaIaDeg/82g83nFLCV2Hvq EFANBwczUM2DrWUgYWYBeYnmrbOZIcp1Jd69vsc6gVFgFpINsxA6ZiHpWMDIvIpRODcxMye9 3FwvtSgzubg4P0+vOHUTIzD4Dm75bbCDcdN9sUOM0hwsSuK8eqr7/YUE0hNLUrNTUwtSi+KL SnNSiw8xMnFwSjUwejXn5mnvjQgT2cVzy+zcZP6I+Y9eHSnYXrRzucS7u2Iz+G8v3NXUmf3D XPmzuAenaALztqCchq2bnnnMfdtVrmWYfFy1VVrj/rFEZvnzh9VjFGKcWzOSzgsl2z5kTyg8 nr8tt+fKK+Zjhf/VDyXzvJ/aciDHpZG3i+9/U0OxQlrw90naH2qVWIozEg21mIuKEwHENI/b DAIAAA== Subject: Re: [rtcweb] Confirmation of consensus on audio codecs X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 28 Aug 2012 12:36:41 -0000 On 08/16/2012 07:15 PM, Cullen Jennings (fluffy) wrote: > > At the last meeting we took a hum on selecting Opus and G.711 as the > mediatory to implement audio codecs. If there is any new opinions > please send them to the list by August 30th, after which the chairs > will make a determination of consensus. As much as I would like to say "I agree", I come to the conclusion it is not that simple. I have two things that concern me: * "Opus" not well enough defined * Opus not mature and proven enough (this is the more important concern) Lets talk about both of these. "Opus" not well enough defined ============================== Just saying "Opus" is a bit vague for me (who has not been in the codec WG). Is a certain version meant? Which one? Or is it a moving target (i.e. always implement the latest version)? What is included (is jitter management, loss concealment part of Opus or something that is up to the implementation)? And how is it judged what is a compliant implementation? Is there a ref implementation that you test against? How do you test? Are there test-vectors that must be conformed to? Or is "Opus" standardized as a wire format (meaning that any implementation that can produce/decode that wire format is compliant)? If the latter is true, implementers have more wiggle room to e.g. reduce complexity or design around IPRs (submarine IPRs may surface). Are implementors required to support all aspects of Opus, or are there sub-sets/profiles that would be sufficient (perhaps for certain classes of devices)? [1] suggests that not all ptime options need to be supported, but are there others things? Many of the answers are probably available, but I think they should be put in front of the WG before making this decision. Opus not mature and proven enough ================================= As far as I understand, Opus is a brand new standard. There are implementations on-going, but yet no deployment, no experience from real world use (and definitely not from use in larger scale over a wide range of conditions, involving a broad range of end user devices). In addition, I've been told that so far Opus has gone through less characterization tests than codecs usually are put through. I don't think it is fair to mandate the implementation of a codec (which is a large and complex piece) under these circumstances. Some real deployment (involving many device types) and experience (including operation in different conditions) should be gained before doing so. It could also be argued that there is a bigger risk from a licensing perspective to mandate a codec that has not been in use. Do I mean we should mandate just G.711? ======================================= No, not necessarily. Looking ahead, I am convinced that new and improved codecs for audio and video will be introduced as they become available. There is a logic in adopting technology that reduces the transmitted number of bits and enhances the end user experience, and the WG is designing a solution that enables new codecs to be introduced and used (and I really hope they can be made use of even if the applications is untouched) IIUC. However, if G.711 would be the only MTI audio codec, services that expect audio BW that goes beyond narrowband could suffer since there is no guarantee that there is any other codec than G.711 supported by both endpoints. In addition G.711 is not that well suited for for challenging network conditions (the most important parts like packet loss concealment and jitter management depends on the implementation - or are we going to standardize those parts?; what I am after is that it is unable to lower the send rate as reaction to congestion - the only method available is to use longer frames to make the IP header overhead lower). I see three possible ways forward: a) Mandate G.711 only, and let the market decide if there will be a universally available codec giving higher quality. b) Postpone the decision for some time. Let Opus (and other new codecs if such are introduced) get deployed, tested, perhaps improved. The drawback with this approach is that the selection is delayed. If this approach is chosen, I would also recommend that the WG spends some time on selection criteria. In the presentation given in Vancouver ([2]) six criteria were used (three of them considered more important). I think they make sense, but can't remember we actually discussed them (or what other criteria that may make sense). c) Mandate some other codec (that is already deployed and in use). Of these approaches, perhaps b) is the most reasonable one. Stefan [1] http://datatracker.ietf.org/doc/draft-cbran-rtcweb-codec/?include_text=1 [2] http://www.ietf.org/proceedings/84/slides/slides-84-rtcweb-6.pdf > > Thanks, Cullen > > Please note that the following IPR disclosure have been made on these > codecs. They can be found at > > http://datatracker.ietf.org/ipr/ > > > 2010-11-07 • ID # 1445 "Broadcom Corporation's Statement about IPR > related to draft-ietf-codec-opus-00 and > draft-ietf-codec-description-00 (1)" 2010-11-07 • ID # 1446 "Xiph.Org > Foundation's Statement about IPR related to > draft-ietf-codec-opus-00" 2010-11-12 • ID # 1447 "Broadcom > Corporation's Statement about IPR related to draft-ietf-codec-opus-00 > and draft-ietf-codec-description-00 (2)" 2011-03-23 • ID # 1520 > "Qualcomm Incorporated's Statement about IPR related to > draft-ietf-codec-opus-05" 2011-03-27 • ID # 1524 "Xiph.Org > Foundation's Statement about IPR related to > draft-ietf-codec-opus-05" 2011-03-29 • ID # 1526 "Broadcom > Corporation's Statement about IPR related to > draft-ietf-codec-opus-05" 2011-03-29 • ID # 1525 "Skype Limited's > Statement about IPR related to draft-ietf-codec-opus-05" 2011-07-23 • > ID # 1602 "Skype Limited's Statement about IPR related to > draft-ietf-codec-opus-07" 2012-01-25 • ID # 1670 "Microsoft > Corporation's Statement about IPR related to > draft-ietf-codec-opus-10" 2012-03-12 • ID # 1712 "Huawei Technologies > Co.,Ltd's Statement about IPR related to draft-ietf-codec-opus-11 > (1)" 2012-04-02 • ID # 1741 "Huawei Technologies Co.,Ltd's Statement > about IPR related to draft-ietf-codec-opus-11 (2)" > > > > _______________________________________________ rtcweb mailing list > rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb > From fluffy@iii.ca Tue Aug 28 05:57:59 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B4DA21F8534 for ; Tue, 28 Aug 2012 05:57:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.478 X-Spam-Level: X-Spam-Status: No, score=-2.478 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GjcPGQRlczTS for ; Tue, 28 Aug 2012 05:57:59 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 1FFBF21F8539 for ; Tue, 28 Aug 2012 05:57:59 -0700 (PDT) Received: from [192.168.4.100] (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 51E0222E25B; Tue, 28 Aug 2012 08:57:51 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Cullen Jennings In-Reply-To: Date: Tue, 28 Aug 2012 06:57:49 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Francois Audet X-Mailer: Apple Mail (2.1486) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Clarification on offer/answer in jsep-01 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 28 Aug 2012 12:57:59 -0000 On Aug 27, 2012, at 10:48 PM, Francois Audet = wrote: >> "As in [RFC3264], an offerer can send an offer, and update it as long >> as it has not been answered." yah that won't work or all the reasons mentioned before and in my = opinion does not represent the WG consensus. BTW - that was added in the = -01 version of the draft and submitted without me ever seeing it - I'd = be happy to fix it but I don't have the source for the draft. Chairs? From fluffy@cisco.com Tue Aug 28 06:05:19 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C18121E8045 for ; Tue, 28 Aug 2012 06:05:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.372 X-Spam-Level: X-Spam-Status: No, score=-110.372 tagged_above=-999 required=5 tests=[AWL=0.227, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mxoFPRJyi2I5 for ; Tue, 28 Aug 2012 06:05:18 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id AAC9F21E8044 for ; Tue, 28 Aug 2012 06:05:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=1240; q=dns/txt; s=iport; t=1346159118; x=1347368718; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=uHoiHI/x2k3nVeoGZhQb4H2OTW3GXGU5w2oOPJ15/dY=; b=HPjmbYkPQbMWVpek529GWFBHIjQNjKBlBRVgg/4X88X4iPGcwQpGD0mO PQMqyeW8HbAzmy/ScUojR/xt/9AGRg83CRBlev4Bv9ftrc/ybesVMKADl J80IHmJy3+G1kazdIqE/Vpj9RS6xmGMYmz8++8n7YTL1zS9FiFujcsooj I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFACbBPFCtJXHB/2dsb2JhbABFqRaRVIEHgiABAQEDARIBJz8FCwIBCDYQMiUCBA4FIodcAwYGmx6gN4olY4V5YAOUBIFSiw6DIIFngmOBYQ X-IronPort-AV: E=Sophos;i="4.80,326,1344211200"; d="scan'208";a="116025696" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-3.cisco.com with ESMTP; 28 Aug 2012 13:05:18 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id q7SD5I7K017053 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 28 Aug 2012 13:05:18 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.72]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0298.004; Tue, 28 Aug 2012 08:05:17 -0500 From: "Cullen Jennings (fluffy)" To: Bernard Aboba Thread-Topic: [rtcweb] Filling in details on "trickle ICE" Thread-Index: AQHNhR3EjLH3wYkFdkyyri9mEjqP4w== Date: Tue, 28 Aug 2012 13:04:53 +0000 Message-ID: References: <3B8DB12B-ABB3-4AC2-A0A0-93DC62C619D3@iii.ca>, , , , , <503BDC75.7050008@stpeter.im> <503BEEFD.40301@jitsi.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.167] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19140.007 x-tm-as-result: No--32.663300-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Filling in details on "trickle ICE" X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 28 Aug 2012 13:05:19 -0000 On Aug 27, 2012, at 4:29 PM, Bernard Aboba wrot= e: > Emil Ivov said:=20 >=20 > Well an ICE stack that implements trickle as per XEP-0176 would currently > not interoperate with a 5245 implementation or, at best, would lead to > unpredictable results. >=20 > The description in XEP-0176 is actually quite perfunctory and can't reall= y > be considered a proper specification. >=20 > A document that describes a proper way of implementing this would hence b= e > quite helpful. >=20 > [BA] You are correct that XMPP/Jingle signaling will not be understood b= y a > SIP UA. However, I don't see anything inherent in the use of STUN/TURN= =20 > within XEP-0176 that violates RFC 5245. If the issue is lack of clarity = in > XEP-0176, shouldn't that be brought up in the XSF, which owns the > specification? >=20 XEP-0176 mostly tells you how to transport the trickle candidates. It does = not answer the questions of ICE works with trickle candidates and there are= a bunch of them as raised in EKR's email and others. Note these are not ne= w concerns - many of these were discussed with Rohan back when he was writi= ng the Jingle stuff. We just never sorted them out. = From matthew.kaufman@skype.net Tue Aug 28 06:47:20 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDE0311E80D3 for ; Tue, 28 Aug 2012 06:47:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.839 X-Spam-Level: X-Spam-Status: No, score=-3.839 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AhnOvhkKUdus for ; Tue, 28 Aug 2012 06:47:20 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe005.messaging.microsoft.com [216.32.180.188]) by ietfa.amsl.com (Postfix) with ESMTP id 205FA11E809C for ; Tue, 28 Aug 2012 06:47:18 -0700 (PDT) Received: from mail31-co1-R.bigfish.com (10.243.78.240) by CO1EHSOBE004.bigfish.com (10.243.66.67) with Microsoft SMTP Server id 14.1.225.23; Tue, 28 Aug 2012 13:47:18 +0000 Received: from mail31-co1 (localhost [127.0.0.1]) by mail31-co1-R.bigfish.com (Postfix) with ESMTP id 41120D000D0; Tue, 28 Aug 2012 13:47:18 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC102.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -27 X-BigFish: VS-27(zz98dI9371I542Mzz1202hzz8275ch1033IL8275dhz2fh2a8h668h839h944hd25hf0ah107ah1155h) Received-SPF: pass (mail31-co1: domain of skype.net designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=matthew.kaufman@skype.net; helo=TK5EX14MLTC102.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail31-co1 (localhost.localdomain [127.0.0.1]) by mail31-co1 (MessageSwitch) id 1346161636363848_1649; Tue, 28 Aug 2012 13:47:16 +0000 (UTC) Received: from CO1EHSMHS032.bigfish.com (unknown [10.243.78.236]) by mail31-co1.bigfish.com (Postfix) with ESMTP id 50DC7C80083; Tue, 28 Aug 2012 13:47:16 +0000 (UTC) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (131.107.125.8) by CO1EHSMHS032.bigfish.com (10.243.66.42) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 28 Aug 2012 13:47:15 +0000 Received: from TK5EX14MBXC272.redmond.corp.microsoft.com ([169.254.2.89]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.02.0318.003; Tue, 28 Aug 2012 13:47:15 +0000 From: Matthew Kaufman To: Cullen Jennings , Francois Audet Thread-Topic: [rtcweb] Clarification on offer/answer in jsep-01 Thread-Index: AQHNhL5ArVdumUDd2EKLRfniiKRa1pdupyWAgACI0oCAAA2wAA== Date: Tue, 28 Aug 2012 13:47:14 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.35] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: skype.net Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Clarification on offer/answer in jsep-01 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 28 Aug 2012 13:47:20 -0000 Isn't this all moot now, given that the API discussion has moved to the W3C= WG? Matthew Kaufman -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= Cullen Jennings Sent: Tuesday, August 28, 2012 5:58 AM To: Francois Audet Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Clarification on offer/answer in jsep-01 On Aug 27, 2012, at 10:48 PM, Francois Audet wro= te: >> "As in [RFC3264], an offerer can send an offer, and update it as long=20 >> as it has not been answered." yah that won't work or all the reasons mentioned before and in my opinion d= oes not represent the WG consensus. BTW - that was added in the -01 version= of the draft and submitted without me ever seeing it - I'd be happy to fix= it but I don't have the source for the draft. Chairs? _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From jmvalin@mozilla.com Tue Aug 28 09:30:33 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E2C221F8576 for ; Tue, 28 Aug 2012 09:30:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C+7DGVffTurA for ; Tue, 28 Aug 2012 09:30:32 -0700 (PDT) Received: from smtp.mozilla.org (mx1.corp.phx1.mozilla.com [63.245.216.69]) by ietfa.amsl.com (Postfix) with ESMTP id 4538421F8575 for ; Tue, 28 Aug 2012 09:30:32 -0700 (PDT) Received: from [192.168.1.15] (modemcable094.20-21-96.mc.videotron.ca [96.21.20.94]) (Authenticated sender: jvalin@mozilla.com) by mx1.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id D0A86F2538; Tue, 28 Aug 2012 09:30:29 -0700 (PDT) Message-ID: <503CF224.5050609@mozilla.com> Date: Tue, 28 Aug 2012 12:30:28 -0400 From: Jean-Marc Valin User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Stefan Hakansson LK References: <9E2843EA-EBB9-40B3-898C-6B5216FAE7A5@cisco.com> <503CBB52.8070300@ericsson.com> In-Reply-To: <503CBB52.8070300@ericsson.com> X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Confirmation of consensus on audio codecs X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 28 Aug 2012 16:30:33 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/28/2012 08:36 AM, Stefan Hakansson LK wrote: > "Opus" not well enough defined ============================== Just > saying "Opus" is a bit vague for me (who has not been in the codec > WG). Is a certain version meant? Which one? Or is it a moving > target (i.e. always implement the latest version)? The exact implementation (or version of that implementation) does not matter as long as the implementation is compliant with (upcoming) RFC 6716. > What is included (is jitter management, loss concealment part of > Opus or something that is up to the implementation)? The jitter buffer is not part of Opus, nor is it part of any other codec I know of. As for loss concealment, the Opus reference implementation proposes one, but implementers can choose what they want because there is no interoperability issue with changing/improving loss concealment. > And how is it judged what is a compliant implementation? Is there a > ref implementation that you test against? How do you test? Are > there test-vectors that must be conformed to? Or is "Opus" > standardized as a wire format (meaning that any implementation that > can produce/decode that wire format is compliant)? If the latter is > true, implementers have more wiggle room to e.g. reduce complexity > or design around IPRs (submarine IPRs may surface). The text in the upcoming RFC 6716 is very clear that only the decoder is standardized. This is similar to how codecs like MP3 and AAC are defined. We also provide a set of test vectors, along with a program that evaluates the decoded output to determine whether the decoder under test is compliant. > Opus not mature and proven enough > ================================= As far as I understand, Opus is a > brand new standard. There are implementations on-going, but yet no > deployment, no experience from real world use (and definitely not > from use in larger scale over a wide range of conditions, involving > a broad range of end user devices). So far, Opus has been deployed in Firefox, GStreamer, FFMpeg, Foobar2000, and a few other applications. This is far more deployment than any ITU-T/MPEG codec has had by the time of standardization. Not only that, but some of the underlying technology has been in use for years now. The original SILK codec (not compatible with Opus but having a lot in common) has been in Skype for about 3 years, while CELT (again, not compatible but sharing a lot of technology) has been deployed in many applications in the past 3 years, including Mumble, which has about half a million users worldwide. > In addition, I've been told that so far Opus has gone through less > characterization tests than codecs usually are put through. When it comes to testing, I recommend reading http://tools.ietf.org/html/draft-valin-codec-results-00 which summarizes the listening tests that were done on Opus. Also, I recommend reading https://www.ietf.org/proceedings/82/slides/codec-4.pdf This describes a whole series of tests we did that other SDOs generally don't do on their codecs. > I don't think it is fair to mandate the implementation of a codec > (which is a large and complex piece) under these circumstances. Well, compared to the rest of webrtc, I find that Opus is so small, simple and well-defined :-) Cheers, Jean-Marc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJQPPIhAAoJEJ6/8sItn9q93vYH/1Q6/dW3ZTkIsMu8y9GOLLNK Agyp8cyfmAREgjP5w5LZw0rmAMGfiPiWKuv7lvTgpivR3HOQbuhnMw9vdQEUJEPw xLHpj5SmZMggA8LFNPcWcmztkUcTnEfKCxPcdFPhA2i3b2cBR/L1b4oLRkUY706c p/EaBVIvOe7Uk54o13V0S671LaaJlX7qGY5Asf3BWLZlGB5xspwtOJvpQ+C6NiTD 94vPId9xKv1BlGIXPbWnUOb3sIAuegGbjkuM36m7DxqVH+zEiXBs8BIDDFdDVSV3 iatsJSeRb1E11/RSEoPjQQE2oiP3R+K2jZhEZeLSfdY75mpAjE11qqfDQMUUCo0= =Otiw -----END PGP SIGNATURE----- From coverdale@sympatico.ca Tue Aug 28 11:47:12 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A11E121F8604 for ; Tue, 28 Aug 2012 11:47:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.307 X-Spam-Level: X-Spam-Status: No, score=-0.307 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, MSGID_FROM_MTA_HEADER=0.803] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kC3+akxxa5wp for ; Tue, 28 Aug 2012 11:47:12 -0700 (PDT) Received: from blu0-omc3-s27.blu0.hotmail.com (blu0-omc3-s27.blu0.hotmail.com [65.55.116.102]) by ietfa.amsl.com (Postfix) with ESMTP id 2686221F8518 for ; Tue, 28 Aug 2012 11:47:11 -0700 (PDT) Received: from BLU0-SMTP92 ([65.55.116.72]) by blu0-omc3-s27.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 28 Aug 2012 11:47:10 -0700 X-Originating-IP: [74.15.62.134] X-EIP: [xgu2fdFcUvUrS4KF5Kpov4Dv1sXaTfTs] X-Originating-Email: [coverdale@sympatico.ca] Message-ID: Received: from PaulNewPC ([74.15.62.134]) by BLU0-SMTP92.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 28 Aug 2012 11:47:08 -0700 From: Paul Coverdale To: "'Jean-Marc Valin'" , "'Stefan Hakansson LK'" References: <9E2843EA-EBB9-40B3-898C-6B5216FAE7A5@cisco.com> <503CBB52.8070300@ericsson.com> <503CF224.5050609@mozilla.com> In-Reply-To: <503CF224.5050609@mozilla.com> Date: Tue, 28 Aug 2012 14:47:03 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 thread-index: Ac2FOn8Qb/Ns0YYdSbmAN0MuS1aBEgAEcLww Content-Language: en-us X-OriginalArrivalTime: 28 Aug 2012 18:47:08.0278 (UTC) FILETIME=[86B7C960:01CD854D] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Confirmation of consensus on audio codecs X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 28 Aug 2012 18:47:12 -0000 >> In addition, I've been told that so far Opus has gone through less >> characterization tests than codecs usually are put through. > >When it comes to testing, I recommend reading >http://tools.ietf.org/html/draft-valin-codec-results-00 which summarizes >the listening tests that were done on Opus. Also, I recommend reading >https://www.ietf.org/proceedings/82/slides/codec-4.pdf >This describes a whole series of tests we did that other SDOs generally >don't do on their codecs. > I think that Stefan was referring to the lack of formal, controlled, characterization tests carried out on Opus, which typically ARE carried out on codecs in other SDOs before approval. ...Paul From Markus.Isomaki@nokia.com Tue Aug 28 12:11:19 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B26221F85F7 for ; Tue, 28 Aug 2012 12:11:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rJvTBZnxMX0v for ; Tue, 28 Aug 2012 12:11:14 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 4B37F21F85B4 for ; Tue, 28 Aug 2012 12:11:13 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (in-mx.nokia.com [10.160.244.31]) by mgw-da01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q7SJB83E011657; Tue, 28 Aug 2012 22:11:09 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.56]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 28 Aug 2012 22:11:07 +0300 Received: from 008-AM1MPN1-042.mgdnok.nokia.com ([169.254.2.220]) by 008-AM1MMR1-001.mgdnok.nokia.com ([65.54.30.56]) with mapi id 14.02.0309.003; Tue, 28 Aug 2012 21:11:06 +0200 From: To: , Thread-Topic: [rtcweb] Confirmation of consensus on audio codecs Thread-Index: AQHNhRnM+dNiTmSGPk2wFICFjlokw5dvlXgg Date: Tue, 28 Aug 2012 19:11:05 +0000 Message-ID: References: <9E2843EA-EBB9-40B3-898C-6B5216FAE7A5@cisco.com> <503CBB52.8070300@ericsson.com> In-Reply-To: <503CBB52.8070300@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.163.23.22] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 28 Aug 2012 19:11:07.0880 (UTC) FILETIME=[E0C99E80:01CD8550] X-Nokia-AV: Clean Subject: Re: [rtcweb] Confirmation of consensus on audio codecs X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 28 Aug 2012 19:11:19 -0000 Hi Stefan, I very much share your views and would like to support especially this opti= on: >b) Postpone the decision for some time. Let Opus (and other new codecs if >such are introduced) get deployed, tested, perhaps improved. The drawback >with this approach is that the selection is delayed. If this approach is c= hosen, I >would also recommend that the WG spends some time on selection criteria. >In the presentation given in Vancouver ([2]) six criteria were used (three= of >them considered more important). I think they make sense, but can't >remember we actually discussed them (or what other criteria that may make >sense). It is always nice to get decisions done early on. However, I don't think th= at leaving the mandatory-to-implement codecs (for either WB audio or video)= open at this point will yet seriously impact the deployment or interoperab= ility of WebRTC. There are still many other things to tackle. We should rev= isit the codec issue when all the other critical things are in a good shape= .=20 I'll post a separate mail on my views shortly. Markus >-----Original Message----- >From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf >Of ext Stefan Hakansson LK >Sent: 28 August, 2012 15:37 >To: rtcweb@ietf.org >Subject: Re: [rtcweb] Confirmation of consensus on audio codecs > >On 08/16/2012 07:15 PM, Cullen Jennings (fluffy) wrote: >> >> At the last meeting we took a hum on selecting Opus and G.711 as the >> mediatory to implement audio codecs. If there is any new opinions >> please send them to the list by August 30th, after which the chairs >> will make a determination of consensus. > >As much as I would like to say "I agree", I come to the conclusion it is n= ot that >simple. > >I have two things that concern me: > >* "Opus" not well enough defined >* Opus not mature and proven enough (this is the more important concern) > >Lets talk about both of these. > >"Opus" not well enough defined >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D >Just saying "Opus" is a bit vague for me (who has not been in the codec WG= ). >Is a certain version meant? Which one? Or is it a moving target (i.e. alwa= ys >implement the latest version)? > >What is included (is jitter management, loss concealment part of Opus or >something that is up to the implementation)? > >And how is it judged what is a compliant implementation? Is there a ref >implementation that you test against? How do you test? Are there test- >vectors that must be conformed to? Or is "Opus" standardized as a wire >format (meaning that any implementation that can produce/decode that wire >format is compliant)? If the latter is true, implementers have more wiggle >room to e.g. reduce complexity or design around IPRs (submarine IPRs may >surface). Are implementors required to support all aspects of Opus, or are >there sub-sets/profiles that would be sufficient (perhaps for certain clas= ses of >devices)? [1] suggests that not all ptime options need to be supported, bu= t >are there others things? > >Many of the answers are probably available, but I think they should be put= in >front of the WG before making this decision. > >Opus not mature and proven enough >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D >As far as I understand, Opus is a brand new standard. There are >implementations on-going, but yet no deployment, no experience from real >world use (and definitely not from use in larger scale over a wide range o= f >conditions, involving a broad range of end user devices). In addition, I'v= e been >told that so far Opus has gone through less characterization tests than co= decs >usually are put through. > >I don't think it is fair to mandate the implementation of a codec (which i= s a >large and complex piece) under these circumstances. Some real deployment >(involving many device types) and experience (including operation in diffe= rent >conditions) should be gained before doing so. It could also be argued that >there is a bigger risk from a licensing perspective to mandate a codec tha= t has >not been in use. > > >Do I mean we should mandate just G.711? >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >No, not necessarily. Looking ahead, I am convinced that new and improved >codecs for audio and video will be introduced as they become available. >There is a logic in adopting technology that reduces the transmitted numbe= r >of bits and enhances the end user experience, and the WG is designing a >solution that enables new codecs to be introduced and used (and I really h= ope >they can be made use of even if the applications is >untouched) IIUC. However, if G.711 would be the only MTI audio codec, >services that expect audio BW that goes beyond narrowband could suffer >since there is no guarantee that there is any other codec than G.711 >supported by both endpoints. > >In addition G.711 is not that well suited for for challenging network cond= itions >(the most important parts like packet loss concealment and jitter >management depends on the implementation - or are we going to >standardize those parts?; what I am after is that it is unable to lower th= e send >rate as reaction to congestion - the only method available is to use longe= r >frames to make the IP header overhead lower). > >I see three possible ways forward: > >a) Mandate G.711 only, and let the market decide if there will be a univer= sally >available codec giving higher quality. > >b) Postpone the decision for some time. Let Opus (and other new codecs if >such are introduced) get deployed, tested, perhaps improved. The drawback >with this approach is that the selection is delayed. If this approach is c= hosen, I >would also recommend that the WG spends some time on selection criteria. >In the presentation given in Vancouver ([2]) six criteria were used (three= of >them considered more important). I think they make sense, but can't >remember we actually discussed them (or what other criteria that may make >sense). > >c) Mandate some other codec (that is already deployed and in use). > >Of these approaches, perhaps b) is the most reasonable one. > >Stefan > >[1] http://datatracker.ietf.org/doc/draft-cbran-rtcweb- >codec/?include_text=3D1 >[2] http://www.ietf.org/proceedings/84/slides/slides-84-rtcweb-6.pdf > > > > >> >> Thanks, Cullen >> >> Please note that the following IPR disclosure have been made on these >> codecs. They can be found at >> >> http://datatracker.ietf.org/ipr/ >> >> >> 2010-11-07 * ID # 1445 "Broadcom Corporation's Statement about IPR >> related to draft-ietf-codec-opus-00 and >> draft-ietf-codec-description-00 (1)" 2010-11-07 * ID # 1446 "Xiph.Org >> Foundation's Statement about IPR related to draft-ietf-codec-opus-00" >> 2010-11-12 * ID # 1447 "Broadcom Corporation's Statement about IPR >> related to draft-ietf-codec-opus-00 and >> draft-ietf-codec-description-00 (2)" 2011-03-23 * ID # 1520 "Qualcomm >> Incorporated's Statement about IPR related to >> draft-ietf-codec-opus-05" 2011-03-27 * ID # 1524 "Xiph.Org >> Foundation's Statement about IPR related to draft-ietf-codec-opus-05" >> 2011-03-29 * ID # 1526 "Broadcom Corporation's Statement about IPR >> related to draft-ietf-codec-opus-05" 2011-03-29 * ID # 1525 "Skype >> Limited's Statement about IPR related to draft-ietf-codec-opus-05" >> 2011-07-23 * ID # 1602 "Skype Limited's Statement about IPR related to >> draft-ietf-codec-opus-07" 2012-01-25 * ID # 1670 "Microsoft >> Corporation's Statement about IPR related to draft-ietf-codec-opus-10" >> 2012-03-12 * ID # 1712 "Huawei Technologies Co.,Ltd's Statement about >> IPR related to draft-ietf-codec-opus-11 (1)" 2012-04-02 * ID # 1741 >> "Huawei Technologies Co.,Ltd's Statement about IPR related to >> draft-ietf-codec-opus-11 (2)" >> >> >> >> _______________________________________________ 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 From Markus.Isomaki@nokia.com Tue Aug 28 12:26:37 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3812D11E80F6 for ; Tue, 28 Aug 2012 12:26:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9vL4XNA+YK69 for ; Tue, 28 Aug 2012 12:26:33 -0700 (PDT) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id 01AF421F8602 for ; Tue, 28 Aug 2012 12:26:32 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (in-mx.nokia.com [10.160.244.32]) by mgw-sa02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q7SJQLEV018854; Tue, 28 Aug 2012 22:26:27 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.57]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 28 Aug 2012 22:26:26 +0300 Received: from 008-AM1MPN1-042.mgdnok.nokia.com ([169.254.2.220]) by 008-AM1MMR1-002.mgdnok.nokia.com ([65.54.30.57]) with mapi id 14.02.0309.003; Tue, 28 Aug 2012 21:26:25 +0200 From: To: , Thread-Topic: Confirmation of consensus on audio codecs Thread-Index: AQHNe9LENUMF/Hj3nEmo2lnRJlNz25dshSCw Date: Tue, 28 Aug 2012 19:26:24 +0000 Message-ID: References: <9E2843EA-EBB9-40B3-898C-6B5216FAE7A5@cisco.com> In-Reply-To: <9E2843EA-EBB9-40B3-898C-6B5216FAE7A5@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.163.23.22] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 28 Aug 2012 19:26:26.0481 (UTC) FILETIME=[04510210:01CD8553] X-Nokia-AV: Clean Subject: Re: [rtcweb] Confirmation of consensus on audio codecs X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 28 Aug 2012 19:26:37 -0000 Hi, I'm having here both my individual thoughs and I'm also conveying the views= of Nokia in more general.=20 (as individual) First of all, my feeling is that we may be trying to make the codec decisio= ns pre-maturely. Codecs are after all a negotiable and well understood comp= onent in RTCWeb. There are more critical things to get right to ensure inte= roperability and success of RTCWeb. By my judgement it will take at least o= ne more year to deliver them in IETF or W3C. So I believe we still have tim= e to make the final call about codecs even for the "1.0" version. With new = codecs such as Opus one more year may bring more information about its qual= ity, IPR status and so on. Many people in the WG seem to consider unencumberment of codecs as essentia= l. Opus does have several non-RF declarations on it, and there are many pla= yers who have not taken part in the IETF Codec WG and thus have no disclosu= re obligation on their potential IPR. So if the WG wants to mandate a wideb= and codec at this point, it seems to me that G.722 is the logical choice. (= Opus is more efficient and if it indeed will enjoy RF status, I'm sure it w= ill become the "de facto" RTCWeb codec in many environments.) So, in summary, I think the WG should either not fix the mandatory codecs y= et, or if that for some reason needs to be done right now, the MTI audio co= decs should be G.711 and G.722. =20 (speaking for Nokia) Nokia thinks that there are complexity issues with the Opus codec. There ar= e also possible IPR risks associated with the "royalty-free" nature of Opus= . We do not recommend Opus to be taken as a mandatory codec for RTCWeb at t= his point. From high quality low bit rate and mobile applications point of = view the 3GPP AMR-WB codec (also known as ITU-T G.722.2) is the most prefer= able for us. For interoperability with implementations restricted to unencu= mbered codecs, we prefer G.711 and G.722.=20 Regards, Markus >-----Original Message----- >From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf >Of ext Cullen Jennings (fluffy) >Sent: 16 August, 2012 20:16 >To: rtcweb@ietf.org >Subject: [rtcweb] Confirmation of consensus on audio codecs > > >At the last meeting we took a hum on selecting Opus and G.711 as the >mediatory to implement audio codecs. If there is any new opinions please >send them to the list by August 30th, after which the chairs will make a >determination of consensus. > >Thanks, >Cullen > >Please note that the following IPR disclosure have been made on these >codecs. They can be found at > >http://datatracker.ietf.org/ipr/ > > >2010-11-07 >* ID # 1445 >"Broadcom Corporation's Statement about IPR related to draft-ietf-codec- >opus-00 and draft-ietf-codec-description-00 (1)" >2010-11-07 >* ID # 1446 >"Xiph.Org Foundation's Statement about IPR related to draft-ietf-codec-opu= s- >00" >2010-11-12 >* ID # 1447 >"Broadcom Corporation's Statement about IPR related to draft-ietf-codec- >opus-00 and draft-ietf-codec-description-00 (2)" >2011-03-23 >* ID # 1520 >"Qualcomm Incorporated's Statement about IPR related to draft-ietf-codec- >opus-05" >2011-03-27 >* ID # 1524 >"Xiph.Org Foundation's Statement about IPR related to draft-ietf-codec-opu= s- >05" >2011-03-29 >* ID # 1526 >"Broadcom Corporation's Statement about IPR related to draft-ietf-codec- >opus-05" >2011-03-29 >* ID # 1525 >"Skype Limited's Statement about IPR related to draft-ietf-codec-opus-05" >2011-07-23 >* ID # 1602 >"Skype Limited's Statement about IPR related to draft-ietf-codec-opus-07" >2012-01-25 >* ID # 1670 >"Microsoft Corporation's Statement about IPR related to draft-ietf-codec- >opus-10" >2012-03-12 >* ID # 1712 >"Huawei Technologies Co.,Ltd's Statement about IPR related to draft-ietf- >codec-opus-11 (1)" >2012-04-02 >* ID # 1741 >"Huawei Technologies Co.,Ltd's Statement about IPR related to draft-ietf- >codec-opus-11 (2)" > > > >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb From stefan.lk.hakansson@ericsson.com Tue Aug 28 14:41:50 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 035FE11E80D9 for ; Tue, 28 Aug 2012 14:41:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.062 X-Spam-Level: X-Spam-Status: No, score=-6.062 tagged_above=-999 required=5 tests=[AWL=0.187, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wAGkFfEc3yiZ for ; Tue, 28 Aug 2012 14:41:49 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 3264521F8512 for ; Tue, 28 Aug 2012 14:41:49 -0700 (PDT) X-AuditID: c1b4fb30-b7f7d6d0000042ea-05-503d3b1c158b Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id CF.EE.17130.C1B3D305; Tue, 28 Aug 2012 23:41:48 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.264.1; Tue, 28 Aug 2012 23:41:47 +0200 Message-ID: <503D3B1A.50309@ericsson.com> Date: Tue, 28 Aug 2012 23:41:46 +0200 From: Stefan Hakansson LK User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <9E2843EA-EBB9-40B3-898C-6B5216FAE7A5@cisco.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNJMWRmVeSWpSXmKPExsUyM+Jvra6MtW2AwfOvIhZr/7WzOzB6LFny kymAMYrLJiU1J7MstUjfLoEr48yGi+wFv5kq2pa0szUwrmbqYuTkkBAwkbj45B8zhC0mceHe erYuRi4OIYFTjBIbvqxjhXCWM0p0LO8Aq+IV0JR4uuweI4jNIqAq8ebNZlYQm03ARmJt9xSw qaICIRJrvk1hhKgXlDg58wkLiC0iICyx9VUvWI2wgL3ExhP/GSEWtDFK3HxxCqiIg4NTIExi 7jYekBpmAVuJC3Ous0DY8hLb384Bu0FIQFfi3et7rBMYBWYhWTELScssJC0LGJlXMQrnJmbm pJeb66UWZSYXF+fn6RWnbmIEBuDBLb8NdjBuui92iFGag0VJnFdPdb+/kEB6YklqdmpqQWpR fFFpTmrxIUYmDk6pBkblWfFHTZxiza66vdf1dE1OC5U2lq/iObHy8LPqlTI9PZnm25TrHp5U ObkxyU/souVPm+B1LRlZa/Y9uKUdWnDEL+eWwIKKO9mcFwquPsiPnh+js1VbLOB4Y2F4yHLz 8zyJO+NkelL+mCgvclvmzv1vRrjCOqNJobpSCVdOd939M9/83RuOP0osxRmJhlrMRcWJANhE Df0OAgAA Subject: Re: [rtcweb] Confirmation of consensus on audio codecs X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 28 Aug 2012 21:41:50 -0000 On 08/28/2012 09:26 PM, Markus.Isomaki@nokia.com wrote: > So, in summary, I think the WG should either not fix the mandatory > codecs yet, or if that for some reason needs to be done right now, > the MTI audio codecs should be G.711 and G.722. I agree, there seem to be no reason why this must be decided right now, but if it must be G.711 and .722 are logical choices. From lishitao@huawei.com Tue Aug 28 18:26:14 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2F7F11E809B for ; Tue, 28 Aug 2012 18:26:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oxe357-hYYyt for ; Tue, 28 Aug 2012 18:26:14 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 9C74B21F84D7 for ; Tue, 28 Aug 2012 18:26:13 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AJC62296; Wed, 29 Aug 2012 01:26:10 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 29 Aug 2012 02:24:13 +0100 Received: from SZXEML431-HUB.china.huawei.com (10.72.61.39) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 29 Aug 2012 02:24:41 +0100 Received: from SZXEML534-MBX.china.huawei.com ([169.254.2.70]) by szxeml431-hub.china.huawei.com ([10.72.61.39]) with mapi id 14.01.0323.003; Wed, 29 Aug 2012 09:24:34 +0800 From: Lishitao To: "rtcweb@ietf.org" Thread-Topic: [rtcweb] Confirmation of consensus on audio codecs Thread-Index: AQHNe9LENUMF/Hj3nEmo2lnRJlNz25dshSCwgALI9gCAAMHooA== Date: Wed, 29 Aug 2012 01:24:33 +0000 Message-ID: References: <9E2843EA-EBB9-40B3-898C-6B5216FAE7A5@cisco.com> <503D3B1A.50309@ericsson.com> In-Reply-To: <503D3B1A.50309@ericsson.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.73.37] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [rtcweb] Confirmation of consensus on audio codecs X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 29 Aug 2012 01:26:14 -0000 Hi all Both as individual and HUAWEI's point of view, We support this option, G.711 and G.722 (or G.711 only) are the best choice= s to be MTI at this moment. shitao > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf > Of Stefan Hakansson LK > Sent: Wednesday, August 29, 2012 5:42 AM > To: rtcweb@ietf.org > Subject: Re: [rtcweb] Confirmation of consensus on audio codecs >=20 > On 08/28/2012 09:26 PM, Markus.Isomaki@nokia.com wrote: >=20 > > So, in summary, I think the WG should either not fix the mandatory > > codecs yet, or if that for some reason needs to be done right now, > > the MTI audio codecs should be G.711 and G.722. > I agree, there seem to be no reason why this must be decided right now, > but if it must be G.711 and .722 are logical choices. > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From lishitao@huawei.com Tue Aug 28 19:51:22 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7605021F8467 for ; Tue, 28 Aug 2012 19:51:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kvS6Wwy576ut for ; Tue, 28 Aug 2012 19:51:22 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 646E421F845F for ; Tue, 28 Aug 2012 19:51:20 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AKA74488; Wed, 29 Aug 2012 02:51:15 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 29 Aug 2012 03:49:38 +0100 Received: from SZXEML423-HUB.china.huawei.com (10.82.67.162) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 29 Aug 2012 03:50:06 +0100 Received: from SZXEML534-MBX.china.huawei.com ([169.254.2.70]) by szxeml423-hub.china.huawei.com ([10.82.67.162]) with mapi id 14.01.0323.003; Wed, 29 Aug 2012 10:50:01 +0800 From: Lishitao To: Cullen Jennings , Francois Audet Thread-Topic: [rtcweb] Clarification on offer/answer in jsep-01 Thread-Index: AQHNhL4us0yFD+FkVkKp1xv1UrfEi5duIQmAgACI0oCAAWwo8A== Date: Wed, 29 Aug 2012 02:50:01 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.73.37] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Clarification on offer/answer in jsep-01 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 29 Aug 2012 02:51:22 -0000 > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf > Of Cullen Jennings > Sent: Tuesday, August 28, 2012 8:58 PM > To: Francois Audet > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] Clarification on offer/answer in jsep-01 >=20 >=20 > On Aug 27, 2012, at 10:48 PM, Francois Audet > wrote: >=20 > >> "As in [RFC3264], an offerer can send an offer, and update it as long > >> as it has not been answered." >=20 > yah that won't work or all the reasons mentioned before and in my opinion= does > not represent the WG consensus. BTW - that was added in the -01 version o= f > the draft and submitted without me ever seeing it - I'd be happy to fix i= t but I > don't have the source for the draft. Chairs? >=20 The next sentence just after this one=20 " The answerer can send back zero or more provisional answers, and finally end the offer-answer exchange by sending a final answer." =20 does not describe quite well either, right? AFAIK , the answerer can send back zero or more provisional answers, but th= ey are not all SDP answers,=20 and I don't find any place in RFC 3264 has the definition about "final answ= er". shitao From alan.b.johnston@gmail.com Tue Aug 28 20:41:50 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85B3F11E808A for ; Tue, 28 Aug 2012 20:41:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.299 X-Spam-Level: X-Spam-Status: No, score=-103.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vuK45rHReNPS for ; Tue, 28 Aug 2012 20:41:50 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id BE28A21F8505 for ; Tue, 28 Aug 2012 20:41:49 -0700 (PDT) Received: by lahm15 with SMTP id m15so106014lah.31 for ; Tue, 28 Aug 2012 20:41:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=sSsTdsUyEaHgrZaAywXw4Pl70uNkqJ4wG+9OysLdF/s=; b=ofdW6rbLW0PfzDT5UwTeBmBuLIdRrwC/3rdegWQldAZDGm2RkrC4wpm34ojdbtDuS0 riAqVfDKrIWZagle6AVzuN0RFf0OJS2fd8nBwBfzGWeBmySNUw9VEiuOcruAHHr70NqT Fwe9IsnHcGXiS6w4ff8Isk5LYsrBw2m1A6tZNbm04N8eBoUotwv70dY4Bmiv0EDnHH9D yDI7dWvQrEB44wJLYJvWtILmVbf1P7rkuKVmK1cARZDmTSPL176gcdeYJPd1YoGX9pSC lD7L4+TWUy36itxR3jZddbH4SNnpI6yCma08ryw3ieSqWFVB6AOurLCjRSrhm2Y3MSCY wFig== MIME-Version: 1.0 Received: by 10.112.104.105 with SMTP id gd9mr150176lbb.36.1346211708783; Tue, 28 Aug 2012 20:41:48 -0700 (PDT) Received: by 10.112.66.49 with HTTP; Tue, 28 Aug 2012 20:41:48 -0700 (PDT) Date: Tue, 28 Aug 2012 22:41:48 -0500 Message-ID: From: Alan Johnston To: rtcweb@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [rtcweb] RTCWEB needs an Internet Codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 29 Aug 2012 03:41:50 -0000 The RTCWEB effort needs an Internet codec. This is why Opus is the right choice. RTCWEB also needs one codec for backwards compatibility with the VoIP world. This is why G.711 is also the right choice. Any G.mumble codec is NOT an Internet codec and will not have the same performance on the Internet as one that was designed for the Internet! If anyone doesn't understand what that means, go back and examine the CODEC Working Group archives to get educated. If someone wants another codec instead of Opus, then they need to propose another Internet codec. Otherwise, we are not serving the Internet. - Alan - From roman@telurix.com Tue Aug 28 21:13:58 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6605C21F84DA for ; Tue, 28 Aug 2012 21:13:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.575 X-Spam-Level: X-Spam-Status: No, score=-2.575 tagged_above=-999 required=5 tests=[AWL=-0.199, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z6zVlrX5e7RC for ; Tue, 28 Aug 2012 21:13:57 -0700 (PDT) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3D60F21F84D8 for ; Tue, 28 Aug 2012 21:13:57 -0700 (PDT) Received: by qan41 with SMTP id 41so2990394qan.10 for ; Tue, 28 Aug 2012 21:13:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=chzS3v7qbFhmEx08BfDkr6hW3gQltiYSb0RSZtYOzho=; b=iy91uBONF2TMXwYnLLaaBjfCJlP+3incUdc6lNurDVagZPp345IXeABAMJQ9oJJySu lkZO5uwAGJgnXyDy9fweoOp4Wl4gQaoe1c7vwbbgBByRLT8CCfN9BtQGIEnNmrRtm6Ob 5FzY7yNi1aLOpQT6eg/bGd0hDwhZiWxHbh0LINxhABMGN3Ocht54XJfqGcSAASBc7wls LIR8aMG3FKwTMu+Mz31bCfoy63hcae8hj1TTvom/PQdKIx6eEJs7+T0ijNJ17ZsdxDJJ oblj1UZlIhsMJeP2jmM9thrSJ8C1Ukf0jvCHcVa2+VzK8emf8pKCSBVcy0SeZnintdg6 z1/w== Received: by 10.224.211.73 with SMTP id gn9mr1143949qab.42.1346213636571; Tue, 28 Aug 2012 21:13:56 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by mx.google.com with ESMTPS id l3sm17234450qan.19.2012.08.28.21.13.55 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 28 Aug 2012 21:13:55 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so158280vcb.31 for ; Tue, 28 Aug 2012 21:13:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.221.72 with SMTP id ib8mr199628vcb.25.1346213635288; Tue, 28 Aug 2012 21:13:55 -0700 (PDT) Received: by 10.58.94.233 with HTTP; Tue, 28 Aug 2012 21:13:55 -0700 (PDT) In-Reply-To: References: Date: Wed, 29 Aug 2012 00:13:55 -0400 Message-ID: From: Roman Shpount To: Alan Johnston Content-Type: multipart/alternative; boundary=14dae9cfc88a85f07604c85fc9f8 X-Gm-Message-State: ALoCoQn4yJ3cdYC2mMnd7ztzorVZaUNQtbmBcwHlJCJ7PHn911T9qFcXfR52wqdo3lY7LoBRiiiC Cc: rtcweb@ietf.org Subject: Re: [rtcweb] RTCWEB needs an Internet Codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 29 Aug 2012 04:13:58 -0000 --14dae9cfc88a85f07604c85fc9f8 Content-Type: text/plain; charset=ISO-8859-1 Not that I have anything against Opus, but what exactly makes Opus an internet codec? What is internet codec anyway? Makes this all kind of a meaningless argument. I would argue that for my broadband internet connection G.722 is a perfect internet codec. I do not care about bandwidth savings of Opus, and quality wise, for the voice conversation, I cannot hear any difference. I would argue G.711 should be the MTI codec. The rest can be left up to browser implementers. We can argue all we want, but the best royalty free low bitrate codec available will be the one everybody supports. We can force it to be Opus, but even if we don't, it will still be Opus on its merit alone. G.722 will probably end up being supported as well, since it is free, pretty good quality, and easy to implement. P.S. Not that I am arguing for it, I am surprised no one made a case for iSAC, since it is also royalty free, low bit rate, and very high quality. It is event named "internet Speech Audio Codec". _____________ Roman Shpount On Tue, Aug 28, 2012 at 11:41 PM, Alan Johnston wrote: > The RTCWEB effort needs an Internet codec. This is why Opus is the > right choice. RTCWEB also needs one codec for backwards compatibility > with the VoIP world. This is why G.711 is also the right choice. > > Any G.mumble codec is NOT an Internet codec and will not have the same > performance on the Internet as one that was designed for the Internet! > If anyone doesn't understand what that means, go back and examine the > CODEC Working Group archives to get educated. > > If someone wants another codec instead of Opus, then they need to > propose another Internet codec. Otherwise, we are not serving the > Internet. > > - Alan - > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --14dae9cfc88a85f07604c85fc9f8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Not that I have anything against Opus, but what exactly makes Opus an inter= net codec? What is internet codec anyway? Makes this all kind of a meaningl= ess argument.

I would argue that for my broadband internet connectio= n G.722 is a perfect internet codec. I do not care about bandwidth savings = of Opus, and quality wise, for the voice conversation, I cannot hear any di= fference.

I would argue G.711 should be the MTI codec. The rest can be left up to= browser implementers. We can argue all we want, but the best royalty free = low bitrate codec available will be the one everybody supports. We can forc= e it to be Opus, but even if we don't, it will still be Opus on its mer= it alone. G.722 will probably end up being supported as well, since it is f= ree, pretty good quality, and easy to implement.

P.S. Not that I am arguing for it, I am surprised no one made a case fo= r iSAC, since it is also royalty free, low bit rate, and very high quality.= It is event named "internet Speech Audio Codec".
_____________
Roman Shpount


On Tue, Aug 28, 2012 at 11:41 PM, Alan J= ohnston <alan.b.johnston@gmail.com> wrote:
The RTCWEB effort needs an Internet codec. =A0This is why Opus is the
right choice. =A0RTCWEB also needs one codec for backwards compatibility with the VoIP world. =A0This is why G.711 is also the right choice.

Any G.mumble codec is NOT an Internet codec and will not have the same
performance on the Internet as one that was designed for the Internet!
=A0If anyone doesn't understand what that means, go back and examine th= e
CODEC Working Group archives to get educated.

If someone wants another codec instead of Opus, then they need to
propose another Internet codec. =A0Otherwise, we are not serving the
Internet.

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

--14dae9cfc88a85f07604c85fc9f8-- From oej@edvina.net Tue Aug 28 23:33:31 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0455211E80EF for ; Tue, 28 Aug 2012 23:33:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eN-cAobR2gjX for ; Tue, 28 Aug 2012 23:33:30 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 4CF1611E80A4 for ; Tue, 28 Aug 2012 23:33:29 -0700 (PDT) Received: from [192.168.40.89] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id B8FBA754A8B3; Wed, 29 Aug 2012 06:33:26 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: "Olle E. Johansson" In-Reply-To: Date: Wed, 29 Aug 2012 08:33:30 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9E2843EA-EBB9-40B3-898C-6B5216FAE7A5@cisco.com> <503D3B1A.50309@ericsson.com> To: Lishitao X-Mailer: Apple Mail (2.1486) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Confirmation of consensus on audio codecs X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 29 Aug 2012 06:33:31 -0000 29 aug 2012 kl. 03:24 skrev Lishitao : > Hi all >=20 > Both as individual and HUAWEI's point of view, >=20 PLEASE. In the IETF we're all individuals. A company's point of view = does not matter here.=20 I don't see the point of any more companies adding their "point of = view". Thanks. /O And that's Edvina's point of view too ;-) From lishitao@huawei.com Tue Aug 28 23:35:03 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30E0111E80A4 for ; Tue, 28 Aug 2012 23:35:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jVQU6j35t3UL for ; Tue, 28 Aug 2012 23:35:02 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id A11C411E80A2 for ; Tue, 28 Aug 2012 23:35:01 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AJC80469; Wed, 29 Aug 2012 06:35:00 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 29 Aug 2012 07:34:28 +0100 Received: from SZXEML428-HUB.china.huawei.com (10.72.61.36) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 29 Aug 2012 14:34:55 +0800 Received: from SZXEML534-MBX.china.huawei.com ([169.254.2.70]) by szxeml428-hub.china.huawei.com ([10.72.61.36]) with mapi id 14.01.0323.003; Wed, 29 Aug 2012 14:34:48 +0800 From: Lishitao To: Emil Ivov , Bernard Aboba Thread-Topic: [rtcweb] Filling in details on "trickle ICE" Thread-Index: AQHNggtM/okNr7r4mEK0m/1/TyZDY5dol3CAgAABRICAAAOYgIAACHQAgAADxICAABZ7AIAAM/2AgAATuQCABIpzAIAABfEAgAAHh4CAAAEEgIAAEn+AgAADmYCAAAbdgIAAfw4AgAIdnDA= Date: Wed, 29 Aug 2012 06:34:48 +0000 Message-ID: References: <3B8DB12B-ABB3-4AC2-A0A0-93DC62C619D3@iii.ca>, , , , , <503BDC75.7050008@stpeter.im> <503BEEFD.40301@jitsi.org> <503C5F54.5000309@jitsi.org> In-Reply-To: <503C5F54.5000309@jitsi.org> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.73.37] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Filling in details on "trickle ICE" X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 29 Aug 2012 06:35:03 -0000 > From your other mail: >=20 > > Details of the updated offer are described in RFC 5245 Section 9.1.2.2: >=20 > I am not sure how 9.1.2.2 would apply here given that it's about sending > updated offers once ICE has completed. It even says that: >=20 > The agent MUST include candidate attributes for candidates matching > the default destination for each component of the media stream, and > MUST NOT include any other candidates. >=20 > Did you instead mean to quote section 9.1.2.1 which contains the followin= g: >=20 > The agent > MAY include additional candidates it did not offer previously, but > which it has gathered since the last offer/answer exchange, including > peer reflexive candidates. >=20 > 9.1.2.1 does indeed refer to updating ICE for "Existing Media Streams > with ICE Running". >=20 > While I agree that this does look like trickling I am not sure it was > intended to be used in exactly the same way that we are discussing here > and the text is not enough to cover a proper trickling implementation. >=20 > The main issue is that there's currently nothing in 5245 that would > allow an agent to determine if more candidates are to be expected. If > trickling is in use there's no way for a controlled agent to know that > (or if) more candidates are to be expected. This creates a race > condition which may result in the controlled agent moving into the "ICE > Failed" state before it has received all candidates from the controlling > agent. Agree, and AFAIK, what described in RFC 5245 is not the exact mechanism as = ICE trickling.=20 Moreover, using SDP for ICE trickling is not a good idea, because, the reas= on by using ICE trickling is to shorten=20 the negotiation time, but the offerer can not send another update SDP offer= which including the new candidates=20 to the answerer unless the offerer has received the first SDP answer, this = cannot increase the negotiation procedure. > Such premature failures can happen very easily if the first offer only > contains addresses that can be determined as unusable without even > running any checks. This would be the case for an IPv4-only host > receiving an offer with IPv6 candidates only (and vice versa). One can > probably come up with a few more cases like this one. >=20 > > If the issue is lack of clarity in > > XEP-0176, shouldn't that be brought up in the XSF, which owns the > > specification? >=20 > Nope, XEP-0176 would be crystal clear if the IETF comes up with a > document that explains how ICE agents should behave in situations where > addresses continue to arrive after the original offer. > Emil >=20 > -- > https://jitsi.org > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From juberti@google.com Wed Aug 29 00:31:47 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB56321F84B3 for ; Wed, 29 Aug 2012 00:31:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.785 X-Spam-Level: X-Spam-Status: No, score=-102.785 tagged_above=-999 required=5 tests=[AWL=0.191, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id blIXrEufpALh for ; Wed, 29 Aug 2012 00:31:47 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id F0E1E21F84AF for ; Wed, 29 Aug 2012 00:31:46 -0700 (PDT) Received: by qcac10 with SMTP id c10so183432qca.31 for ; Wed, 29 Aug 2012 00:31:46 -0700 (PDT) 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:x-system-of-record; bh=dpVDzb+2VSGTOX1wO7GvZlox9cEXmKfaZq5q1PKFT1g=; b=VXNfjvdCrmxuUB09ZojXaTPGE7697BCbipGcrX/jUV9byMq4tvlLO57lqSKE63qy2E /q0x4reK+Avkks8FfdLar39Y58oiS3wC0LG8//wcBN1QIqQP68gA32Ovql3h1xz5TCtr RF59LdWkRVQ1TidpWSjUko3BS5k4u5HmHuRN+Vbg13SH4prZO7pc147e88Pj3zyMddKs ++EO270t3uXziekKhnbvD2GtvmpqPA19d7Wd+Fdw3+DMv70oexfRfskUoruoQc1LvZsM YxiAa7/58MPu5MZzWWNvxuGZk06EWv0pD/TmuhS277CP6OllZ6Hu1tT2Qq/ncFUPEV8f 67HA== X-Google-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:x-system-of-record:x-gm-message-state; bh=dpVDzb+2VSGTOX1wO7GvZlox9cEXmKfaZq5q1PKFT1g=; b=fRkyiHdENXUYzICRlmUm8rTNqykitiZ2L7uBG9iN8grZNRA73Rffayh+6ZP5ejtvkj 350muO7QuhhtzgR6BtTxpwKC07r96sZvFBTTpu/aOCOdycgJp14ZhzDJjMRG0nhIsgB+ IxFebqldjpIEg5KX+7EZ7E84hvtsv9KeMMHISQZ4zi4hbna/46nXDg7G5op2QHrQ+/tU vfvBV2PibIt0/5DdcXOV6nIz//yKQZ41+8BBwY8DC7qFAfDiYvETmBiyVtFkBOTI4RGn CPVEJMuGQSdBPOHctKtqSJ+1rB1T4P5DPwyzhG7piIcI/8HZRSclU6a+ZkfVpyWdOp0T S2AQ== Received: by 10.229.137.72 with SMTP id v8mr279311qct.79.1346225506333; Wed, 29 Aug 2012 00:31:46 -0700 (PDT) Received: by 10.229.137.72 with SMTP id v8mr279306qct.79.1346225506145; Wed, 29 Aug 2012 00:31:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.164.6 with HTTP; Wed, 29 Aug 2012 00:31:24 -0700 (PDT) In-Reply-To: References: From: Justin Uberti Date: Wed, 29 Aug 2012 00:31:24 -0700 Message-ID: To: Cullen Jennings Content-Type: multipart/alternative; boundary=00235452fe2414d7de04c8628daa X-System-Of-Record: true X-Gm-Message-State: ALoCoQnb4w7iqm3K3z4wZG+00/aZl6iC9AmTpbCgBAJn5eXZhnYgmszkBt1/QVaVE46rPPJKX1Fo6k26xzSIVnh6QtmN6JykrOY5Uw+0+b/ICswdMYIzPG5FsX4sr6KSxHfOFrA5QO1/qAvhVz9AO+RlAmoT0U+iTfMmGglqlLnnm6MM3uiqMiZC/R0T1+YAOZ5Z0beArBjj Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Clarification on offer/answer in jsep-01 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 29 Aug 2012 07:31:47 -0000 --00235452fe2414d7de04c8628daa Content-Type: text/plain; charset=UTF-8 The text here is incorrect, this was a mistake on my part. While this usage is technically permissible if you can deal with the complications it introduces, it is not compliant with RFC 3264, as has been pointed out. What I meant to say here was that the local description can be updated even after an initial local description has been specified. There are real-world use cases for this, such as setting an initial local description to tell the ICE Agent the number of m= lines to gather candidates for, followed by a later update when the getUserMedia MediaStream has been obtained. The offer would not actually be sent until after the updated local description has been appliced, so this would not violate 3264. On Tue, Aug 28, 2012 at 5:57 AM, Cullen Jennings wrote: > > On Aug 27, 2012, at 10:48 PM, Francois Audet > wrote: > > >> "As in [RFC3264], an offerer can send an offer, and update it as long > >> as it has not been answered." > > yah that won't work or all the reasons mentioned before and in my opinion > does not represent the WG consensus. BTW - that was added in the -01 > version of the draft and submitted without me ever seeing it - I'd be happy > to fix it but I don't have the source for the draft. Chairs? > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --00235452fe2414d7de04c8628daa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The text here is incorrect, this was a mistake on my part. While this usage= is technically permissible if you can deal with the complications it intro= duces, it is not compliant with RFC 3264, as has been pointed out.

What I meant to say here was that the local description can be u= pdated even after an initial local description has been specified. There ar= e real-world use cases for this, such as setting an initial local descripti= on to tell the ICE Agent the number of m=3D lines to gather candidates for,= followed by a later update when the getUserMedia MediaStream has been obta= ined. The offer would not actually be sent until after the updated local de= scription has been appliced, so this would not violate 3264.


On Tue, Aug 2= 8, 2012 at 5:57 AM, Cullen Jennings <fluffy@iii.ca> wrote:

On Aug 27, 2012, at 10:48 PM, Francois Audet <francois.audet@skype.net> wrote:

>> "As in [RFC3264], an offerer can send an offer, and update it= as long
>> as it has not been answered."

yah that won't work or all the reasons mentioned before and in my= opinion does not represent the WG consensus. BTW - that was added in the -= 01 version of the draft and submitted without me ever seeing it - I'd b= e happy to fix it but I don't have the source for the draft. Chairs?



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

--00235452fe2414d7de04c8628daa-- From stefan.lk.hakansson@ericsson.com Wed Aug 29 02:51:14 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F22321F85AA for ; Wed, 29 Aug 2012 02:51:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.069 X-Spam-Level: X-Spam-Status: No, score=-6.069 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bPn3VOEKQ1fv for ; Wed, 29 Aug 2012 02:51:13 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 9C27121F8610 for ; Wed, 29 Aug 2012 02:51:12 -0700 (PDT) X-AuditID: c1b4fb30-b7f7d6d0000042ea-10-503de60edc92 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id D9.8F.17130.E06ED305; Wed, 29 Aug 2012 11:51:11 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.264.1; Wed, 29 Aug 2012 11:51:10 +0200 Message-ID: <503DE60D.2060706@ericsson.com> Date: Wed, 29 Aug 2012 11:51:09 +0200 From: Stefan Hakansson LK User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: Jean-Marc Valin References: <9E2843EA-EBB9-40B3-898C-6B5216FAE7A5@cisco.com> <503CBB52.8070300@ericsson.com> <503CF224.5050609@mozilla.com> In-Reply-To: <503CF224.5050609@mozilla.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuphluLIzCtJLcpLzFFi42KZGfG3Vpf/mW2AwaqpbBb/p3JYrP3Xzu7A 5LFkyU8mj74DXawBTFFcNimpOZllqUX6dglcGRt2lxV81KnYOPMgawPjVpUuRk4OCQETiVvv z7NB2GISF+6tB7K5OIQETjFKdExbxAzhLGeUeLfgOmMXIwcHr4C2xIp2JZAGFgFVic0/J7GA 2GwCNhJru6cwgdiiAiESa75NYQSxeQUEJU7OfAJWIyKgKXHnxyp2EJtZQF3izuJzYLawgL3E xhP/weqFBKolfnQfAjuIE2jV64ldYGuZgWoebC2DaJWX2P52DjNEua7Eu9f3WCcwCs5Csm0W QscsJB0LGJlXMQrnJmbmpJeb66UWZSYXF+fn6RWnbmIEhujBLb8NdjBuui92iFGag0VJnFdP db+/kEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBsaY8JUPa+Jb67hezGRsnuzBFiSxoSO9UWMd Z8rrH9cPzls9LWO3dc/irFltjsdD86e2vrFQupDO5v+O1eeORvT25TrbyibYrO2Tu2MlWvXo QmesvM2KetcNt9cVhhsGFPmUJwWbfPtRVnzhzMGApZ+uzqrtCz75IiZgS3yi6l+RY2mZRfW2 h5VYijMSDbWYi4oTAcWV8sAfAgAA Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Confirmation of consensus on audio codecs X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 29 Aug 2012 09:51:14 -0000 On 08/28/2012 06:30 PM, Jean-Marc Valin wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 08/28/2012 08:36 AM, Stefan Hakansson LK wrote: >> "Opus" not well enough defined ============================== Just >> saying "Opus" is a bit vague for me (who has not been in the codec >> WG). Is a certain version meant? Which one? Or is it a moving >> target (i.e. always implement the latest version)? > > The exact implementation (or version of that implementation) does not > matter as long as the implementation is compliant with (upcoming) RFC > 6716. > >> What is included (is jitter management, loss concealment part of >> Opus or something that is up to the implementation)? > > The jitter buffer is not part of Opus, nor is it part of any other > codec I know of. As for loss concealment, the Opus reference > implementation proposes one, but implementers can choose what they > want because there is no interoperability issue with > changing/improving loss concealment. > >> And how is it judged what is a compliant implementation? Is there a >> ref implementation that you test against? How do you test? Are >> there test-vectors that must be conformed to? Or is "Opus" >> standardized as a wire format (meaning that any implementation that >> can produce/decode that wire format is compliant)? If the latter is >> true, implementers have more wiggle room to e.g. reduce complexity >> or design around IPRs (submarine IPRs may surface). > > The text in the upcoming RFC 6716 is very clear that only the decoder > is standardized. This is similar to how codecs like MP3 and AAC are > defined. We also provide a set of test vectors, along with a program > that evaluates the decoded output to determine whether the decoder > under test is compliant. Jean-Marc, the info above goes a long way in answering my questions, thanks. I don't know the exact rules for IPR statements so I would like to double check: the fact that the RFC only defines the decoder, does that mean that there can be IPRs known by people in the codec WG that are not declared since they would apply to the encoder only (then there is the risk of IPRs held by those who have not participated in codec WG)? Another question I had was if Opus is atomic, or if you can implement different profiles, and if so what parts should be MTI for rtcweb (and should the profile that is MTI be the same regardless of the device type - there has been issues raised regarding complexity?). > >> Opus not mature and proven enough >> ================================= As far as I understand, Opus is a >> brand new standard. There are implementations on-going, but yet no >> deployment, no experience from real world use (and definitely not >> from use in larger scale over a wide range of conditions, involving >> a broad range of end user devices). > > So far, Opus has been deployed in Firefox, GStreamer, FFMpeg, > Foobar2000, and a few other applications. This is far more deployment > than any ITU-T/MPEG codec has had by the time of standardization. That is great, but sort of underlines that there would be no harm in delaying the decision until there are experiences made from real world use - 'cause it would not be that long till that experience has been made (Markus also brought up the IPR status as a reason for waiting - I have no idea how long it would take to know more about that). > Not > only that, but some of the underlying technology has been in use for > years now. The original SILK codec (not compatible with Opus but > having a lot in common) has been in Skype for about 3 years, while > CELT (again, not compatible but sharing a lot of technology) has been > deployed in many applications in the past 3 years, including Mumble, > which has about half a million users worldwide. > >> In addition, I've been told that so far Opus has gone through less >> characterization tests than codecs usually are put through. > > When it comes to testing, I recommend reading > http://tools.ietf.org/html/draft-valin-codec-results-00 which > summarizes the listening tests that were done on Opus. Also, I > recommend reading > https://www.ietf.org/proceedings/82/slides/codec-4.pdf > This describes a whole series of tests we did that other SDOs > generally don't do on their codecs. As Paul suggested, I was referring to the lack of formal, controlled, characterization tests. That is how other SDOs do it. I don't think that is the only way to do it, but I think we should at least have either such tests conducted or experience from deployment and use (in a wide range of conditions and device types) before making it MTI. > >> I don't think it is fair to mandate the implementation of a codec >> (which is a large and complex piece) under these circumstances. > > Well, compared to the rest of webrtc, I find that Opus is so small, > simple and well-defined :-) Especially if you draw a diagram with all the signaling paths, all components involved, and then make a small box for "codec" (or Opus) :-) > > Cheers, > > Jean-Marc > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.12 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iQEcBAEBAgAGBQJQPPIhAAoJEJ6/8sItn9q93vYH/1Q6/dW3ZTkIsMu8y9GOLLNK > Agyp8cyfmAREgjP5w5LZw0rmAMGfiPiWKuv7lvTgpivR3HOQbuhnMw9vdQEUJEPw > xLHpj5SmZMggA8LFNPcWcmztkUcTnEfKCxPcdFPhA2i3b2cBR/L1b4oLRkUY706c > p/EaBVIvOe7Uk54o13V0S671LaaJlX7qGY5Asf3BWLZlGB5xspwtOJvpQ+C6NiTD > 94vPId9xKv1BlGIXPbWnUOb3sIAuegGbjkuM36m7DxqVH+zEiXBs8BIDDFdDVSV3 > iatsJSeRb1E11/RSEoPjQQE2oiP3R+K2jZhEZeLSfdY75mpAjE11qqfDQMUUCo0= > =Otiw > -----END PGP SIGNATURE----- > From harald@alvestrand.no Wed Aug 29 03:22:33 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C29B521F8629 for ; Wed, 29 Aug 2012 03:22:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.335 X-Spam-Level: X-Spam-Status: No, score=-110.335 tagged_above=-999 required=5 tests=[AWL=0.264, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kMYaAqT9gUZX for ; Wed, 29 Aug 2012 03:22:29 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 82D5321F8567 for ; Wed, 29 Aug 2012 03:22:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4787839E28B for ; Wed, 29 Aug 2012 12:21:58 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ec2bPhRfhbLf for ; Wed, 29 Aug 2012 12:21:54 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:be30:5bff:fede:bcdc]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id E7F6A39E0F0 for ; Wed, 29 Aug 2012 12:21:53 +0200 (CEST) Message-ID: <503DED41.7080906@alvestrand.no> Date: Wed, 29 Aug 2012 12:21:53 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <9E2843EA-EBB9-40B3-898C-6B5216FAE7A5@cisco.com> In-Reply-To: <9E2843EA-EBB9-40B3-898C-6B5216FAE7A5@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [rtcweb] Confirmation of consensus on audio codecs X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 29 Aug 2012 10:22:33 -0000 Since the number of people stating their opinion has been large, I'll just reiterate the opinion I had (and hummed for) in Vancouver: Opus and G.711 should be mandatory to implement for RTCWEB. Since the question of whether there's any value to making the decision now has been raised: The first interoperable products implementing RTCWEB are shipping within a very short timeframe. Those first implementations will shape the market for what's actually used in practice. In order to allow applications requiring high quality sound to be among the first ones developed, those first products need to include a common choice of a high quality codec. Having the RTCWEB WG state as a decision that this codec should be Opus helps in making sure these products ship with Opus. The time to decide is now. Harald [Note - the same logic applies to video codecs, but I've accepted that it's impossible to make a consensus decision at this time on that issue. We'll just live with the consequences of that.] On 08/16/2012 07:15 PM, Cullen Jennings (fluffy) wrote: > At the last meeting we took a hum on selecting Opus and G.711 as the mediatory to implement audio codecs. If there is any new opinions please send them to the list by August 30th, after which the chairs will make a determination of consensus. > > Thanks, > Cullen > > Please note that the following IPR disclosure have been made on these codecs. They can be found at > > http://datatracker.ietf.org/ipr/ > > > 2010-11-07 > • ID # 1445 > "Broadcom Corporation's Statement about IPR related to draft-ietf-codec-opus-00 and draft-ietf-codec-description-00 (1)" > 2010-11-07 > • ID # 1446 > "Xiph.Org Foundation's Statement about IPR related to draft-ietf-codec-opus-00" > 2010-11-12 > • ID # 1447 > "Broadcom Corporation's Statement about IPR related to draft-ietf-codec-opus-00 and draft-ietf-codec-description-00 (2)" > 2011-03-23 > • ID # 1520 > "Qualcomm Incorporated's Statement about IPR related to draft-ietf-codec-opus-05" > 2011-03-27 > • ID # 1524 > "Xiph.Org Foundation's Statement about IPR related to draft-ietf-codec-opus-05" > 2011-03-29 > • ID # 1526 > "Broadcom Corporation's Statement about IPR related to draft-ietf-codec-opus-05" > 2011-03-29 > • ID # 1525 > "Skype Limited's Statement about IPR related to draft-ietf-codec-opus-05" > 2011-07-23 > • ID # 1602 > "Skype Limited's Statement about IPR related to draft-ietf-codec-opus-07" > 2012-01-25 > • ID # 1670 > "Microsoft Corporation's Statement about IPR related to draft-ietf-codec-opus-10" > 2012-03-12 > • ID # 1712 > "Huawei Technologies Co.,Ltd's Statement about IPR related to draft-ietf-codec-opus-11 (1)" > 2012-04-02 > • ID # 1741 > "Huawei Technologies Co.,Ltd's Statement about IPR related to draft-ietf-codec-opus-11 (2)" > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From Markus.Isomaki@nokia.com Wed Aug 29 03:23:20 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A340121F857E for ; Wed, 29 Aug 2012 03:23:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0VsMan+5y-pU for ; Wed, 29 Aug 2012 03:23:20 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 1121721F8493 for ; Wed, 29 Aug 2012 03:23:19 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-da01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q7TAN80S029940; Wed, 29 Aug 2012 13:23:09 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.57]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 29 Aug 2012 13:23:08 +0300 Received: from 008-AM1MPN1-042.mgdnok.nokia.com ([169.254.2.220]) by 008-AM1MMR1-002.mgdnok.nokia.com ([65.54.30.57]) with mapi id 14.02.0309.003; Wed, 29 Aug 2012 12:23:07 +0200 From: To: , Thread-Topic: [rtcweb] Confirmation of consensus on audio codecs Thread-Index: AQHNhbA0+dNiTmSGPk2wFICFjlokw5dwjv7A Date: Wed, 29 Aug 2012 10:23:07 +0000 Message-ID: References: <9E2843EA-EBB9-40B3-898C-6B5216FAE7A5@cisco.com> <503D3B1A.50309@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.21.81.242] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 29 Aug 2012 10:23:08.0709 (UTC) FILETIME=[48F17D50:01CD85D0] X-Nokia-AV: Clean Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Confirmation of consensus on audio codecs X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 29 Aug 2012 10:23:20 -0000 Hi, Olle E. Johansson wrote: > >29 aug 2012 kl. 03:24 skrev Lishitao : > >> Hi all >> >> Both as individual and HUAWEI's point of view, >> >PLEASE. In the IETF we're all individuals. A company's point of view does = not >matter here. >I don't see the point of any more companies adding their "point of view". > I think it's useful to know if companies do have opinions in certain topics= . Many browsers, codecs and other RTCWeb related implementations are going = to happen or not happen based on company decisions. IMHO, more information = is better than less. The main point continues to be that all opinions shoul= d be backed by solid technical arguments before they become relevant. Markus=20 From Martin.Taylor@metaswitch.com Wed Aug 29 04:26:41 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FF6C21F85C0 for ; Wed, 29 Aug 2012 04:26:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_16=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rqqaYZ9T6PIY for ; Wed, 29 Aug 2012 04:26:39 -0700 (PDT) Received: from ENFIRHETS1.metaswitch.com (enfirhets1.metaswitch.com [192.91.191.166]) by ietfa.amsl.com (Postfix) with ESMTP id 66A4521F85AA for ; Wed, 29 Aug 2012 04:26:38 -0700 (PDT) Received: from ENFICSCAS1.datcon.co.uk (172.18.4.13) by ENFIRHETS1.metaswitch.com (172.18.209.22) with Microsoft SMTP Server (TLS) id 14.2.298.4; Wed, 29 Aug 2012 12:26:16 +0100 Received: from ENFICSMBX1.datcon.co.uk ([fe80::d5d5:c683:a3be:3a19]) by ENFICSCAS1.datcon.co.uk ([::1]) with mapi id 14.02.0298.004; Wed, 29 Aug 2012 12:26:37 +0100 From: Martin Taylor To: "rtcweb@ietf.org" Thread-Topic: [rtcweb] RTCWEB needs an Internet Codec Thread-Index: AQHNhZg7p2VbUuK4zUOFs+aV7HoS55dwHXSAgACGQ+A= Date: Wed, 29 Aug 2012 11:26:36 +0000 Message-ID: <185A2074C1DC2342B1514880D000CC1AA7748BD4@ENFICSMBX1.datcon.co.uk> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.18.39.102] Content-Type: multipart/alternative; boundary="_000_185A2074C1DC2342B1514880D000CC1AA7748BD4ENFICSMBX1datco_" MIME-Version: 1.0 Subject: Re: [rtcweb] RTCWEB needs an Internet Codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 29 Aug 2012 11:26:41 -0000 --_000_185A2074C1DC2342B1514880D000CC1AA7748BD4ENFICSMBX1datco_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable An Internet codec is one which was designed specifically to handle a signif= icant level of packet loss. The G.xxx series codecs were designed for circ= uit-switched environments where packet loss is a non-issue. If you are not experiencing voice quality issues with G.722, then you are l= ucky enough to have a very low loss Internet connection. We see frequent i= ssues with G.722 when used for VoIP, especially over WiFi and upstream over= ADSL. Data traffic that competes with voice for bandwidth frequently caus= es choppy voice on these types of connection. We have chosen to use SILK t= o deal with this issue, and this has resulted in major improvements in subj= ective voice quality. SILK is one of the "ingredients" of Opus. I believe that WebRTC applications which use Opus will deliver a far better= user experience in general than those that use G.711 or G.722. Whether th= at means Opus should be mandatory to implement is another matter. In my vi= ew, it is only necessary to specify one MTI codec to ensure that there is a= baseline for interop. The market can decide what codecs it wishes to use = to improve on this baseline interop. Martin From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= Roman Shpount Sent: 29 August 2012 05:14 To: Alan Johnston Cc: rtcweb@ietf.org Subject: Re: [rtcweb] RTCWEB needs an Internet Codec Not that I have anything against Opus, but what exactly makes Opus an inter= net codec? What is internet codec anyway? Makes this all kind of a meaningl= ess argument. I would argue that for my broadband internet connection G.722 is a perfect = internet codec. I do not care about bandwidth savings of Opus, and quality = wise, for the voice conversation, I cannot hear any difference. I would argue G.711 should be the MTI codec. The rest can be left up to bro= wser implementers. We can argue all we want, but the best royalty free low = bitrate codec available will be the one everybody supports. We can force it= to be Opus, but even if we don't, it will still be Opus on its merit alone= . G.722 will probably end up being supported as well, since it is free, pre= tty good quality, and easy to implement. P.S. Not that I am arguing for it, I am surprised no one made a case for iS= AC, since it is also royalty free, low bit rate, and very high quality. It = is event named "internet Speech Audio Codec". _____________ Roman Shpount On Tue, Aug 28, 2012 at 11:41 PM, Alan Johnston > wrote: The RTCWEB effort needs an Internet codec. This is why Opus is the right choice. RTCWEB also needs one codec for backwards compatibility with the VoIP world. This is why G.711 is also the right choice. Any G.mumble codec is NOT an Internet codec and will not have the same performance on the Internet as one that was designed for the Internet! If anyone doesn't understand what that means, go back and examine the CODEC Working Group archives to get educated. If someone wants another codec instead of Opus, then they need to propose another Internet codec. Otherwise, we are not serving the Internet. - Alan - _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --_000_185A2074C1DC2342B1514880D000CC1AA7748BD4ENFICSMBX1datco_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

An Internet codec is one wh= ich was designed specifically to handle a significant level of packet loss.=   The G.xxx series codecs were designed for circuit-switched environments where packet loss is a non-issue.

 

If you are not experiencing= voice quality issues with G.722, then you are lucky enough to have a very = low loss Internet connection.  We see frequent issues with G.722 when used for VoIP, especially over WiFi and upstream over ADSL.&nbs= p; Data traffic that competes with voice for bandwidth frequently causes ch= oppy voice on these types of connection.  We have chosen to use SILK t= o deal with this issue, and this has resulted in major improvements in subjective voice quality.  SILK is one of th= e “ingredients” of Opus.

 

I believe that WebRTC appli= cations which use Opus will deliver a far better user experience in general= than those that use G.711 or G.722.  Whether that means Opus should be mandatory to implement is another matter.  In my view,= it is only necessary to specify one MTI codec to ensure that there is a ba= seline for interop.  The market can decide what codecs it wishes to us= e to improve on this baseline interop.

 

Martin

 

From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.o= rg] On Behalf Of Roman Shpount
Sent: 29 August 2012 05:14
To: Alan Johnston
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] RTCWEB needs an Internet Codec

 

Not that I have anyth= ing against Opus, but what exactly makes Opus an internet codec? What is in= ternet codec anyway? Makes this all kind of a meaningless argument.

I would argue that for my broadband internet connection G.722 is a perfect = internet codec. I do not care about bandwidth savings of Opus, and quality = wise, for the voice conversation, I cannot hear any difference.

I would argue G.711 should be the MTI codec. The rest can be left up to bro= wser implementers. We can argue all we want, but the best royalty free low = bitrate codec available will be the one everybody supports. We can force it= to be Opus, but even if we don't, it will still be Opus on its merit alone. G.722 will probably end up being= supported as well, since it is free, pretty good quality, and easy to impl= ement.

P.S. Not that I am arguing for it, I am surprised no one made a case for iS= AC, since it is also royalty free, low bit rate, and very high quality. It = is event named "internet Speech Audio Codec".
_____________
Roman Shpount

On Tue, Aug 28, 2012 at 11:41 PM, Alan Johnston <= alan.b.johns= ton@gmail.com> wrote:

The RTCWEB effort needs an Internet codec.  Thi= s is why Opus is the
right choice.  RTCWEB also needs one codec for backwards compatibility=
with the VoIP world.  This is why G.711 is also the right choice.

Any G.mumble codec is NOT an Internet codec and will not have the same
performance on the Internet as one that was designed for the Internet!
 If anyone doesn't understand what that means, go back and examine the=
CODEC Working Group archives to get educated.

If someone wants another codec instead of Opus, then they need to
propose another Internet codec.  Otherwise, we are not serving the
Internet.

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

 

--_000_185A2074C1DC2342B1514880D000CC1AA7748BD4ENFICSMBX1datco_-- From harald@alvestrand.no Wed Aug 29 05:11:23 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC97921F8673 for ; Wed, 29 Aug 2012 05:11:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.345 X-Spam-Level: X-Spam-Status: No, score=-110.345 tagged_above=-999 required=5 tests=[AWL=0.254, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n1EtDlZiMzsA for ; Wed, 29 Aug 2012 05:11:22 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 9D73C21F8672 for ; Wed, 29 Aug 2012 05:11:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6C8A539E2A2 for ; Wed, 29 Aug 2012 14:10:51 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wWbp11YN8-gi for ; Wed, 29 Aug 2012 14:10:50 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:be30:5bff:fede:bcdc]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id A7D5039E0F0 for ; Wed, 29 Aug 2012 14:10:50 +0200 (CEST) Message-ID: <503E06C9.6010901@alvestrand.no> Date: Wed, 29 Aug 2012 14:10:49 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] RTCWEB needs an Internet Codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 29 Aug 2012 12:11:24 -0000 On 08/29/2012 06:13 AM, Roman Shpount wrote: > Not that I have anything against Opus, but what exactly makes Opus an > internet codec? What is internet codec anyway? Makes this all kind of > a meaningless argument. > > I would argue that for my broadband internet connection G.722 is a > perfect internet codec. I do not care about bandwidth savings of Opus, > and quality wise, for the voice conversation, I cannot hear any > difference. > > I would argue G.711 should be the MTI codec. The rest can be left up > to browser implementers. We can argue all we want, but the best > royalty free low bitrate codec available will be the one everybody > supports. We can force it to be Opus, but even if we don't, it will > still be Opus on its merit alone. G.722 will probably end up being > supported as well, since it is free, pretty good quality, and easy to > implement. > > P.S. Not that I am arguing for it, I am surprised no one made a case > for iSAC, since it is also royalty free, low bit rate, and very high > quality. It is event named "internet Speech Audio Codec". Google, after considering both, would prefer that Opus be the standard. At high bandwidth / bitrate, Opus is operating in CELT mode, which outperforms iSAC. From jmvalin@mozilla.com Wed Aug 29 05:15:41 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AC9021F8678 for ; Wed, 29 Aug 2012 05:15:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1yOsJ1n-xFQK for ; Wed, 29 Aug 2012 05:15:40 -0700 (PDT) Received: from smtp.mozilla.org (mx1.corp.phx1.mozilla.com [63.245.216.69]) by ietfa.amsl.com (Postfix) with ESMTP id 5694B21F8667 for ; Wed, 29 Aug 2012 05:15:40 -0700 (PDT) Received: from [192.168.1.14] (modemcable094.20-21-96.mc.videotron.ca [96.21.20.94]) (Authenticated sender: jvalin@mozilla.com) by mx1.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 2E249F22C0; Wed, 29 Aug 2012 05:15:36 -0700 (PDT) Message-ID: <503E07E3.3040705@mozilla.com> Date: Wed, 29 Aug 2012 08:15:31 -0400 From: Jean-Marc Valin User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Markus.Isomaki@nokia.com References: <9E2843EA-EBB9-40B3-898C-6B5216FAE7A5@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: fluffy@cisco.com, rtcweb@ietf.org Subject: Re: [rtcweb] Confirmation of consensus on audio codecs X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 29 Aug 2012 12:15:41 -0000 > (speaking for Nokia) > > Nokia thinks that there are complexity issues with the Opus codec. > There are also possible IPR risks associated with the "royalty-free" > nature of Opus. We do not recommend Opus to be taken as a mandatory > codec for RTCWeb at this point. From high quality low bit rate and > mobile applications point of view the 3GPP AMR-WB codec (also known > as ITU-T G.722.2) is the most preferable for us. For interoperability > with implementations restricted to unencumbered codecs, we prefer > G.711 and G.722. Sorry, but I think G.722 (or AMR-WB) is just not enough. Speech-only, AM radio quality is not what we need here. Skype has been shipping a super-wideband codec for about 3 years now, so going back to wideband as the highest guaranteed interoperability would make webrtc irrelevant. Let's look at the options here. On one side we have Opus, that can easily handle all possible rtcweb applications because it does narrowband, wideband, super-wideband and fullband, can handle both speech and music, and scales to high-quality stereo (for music applications). On the other side, if you want the same functionality, you would need at least the following codecs: AMR-NB, AMR-WB, G.722.1C, AAC-LD, HE-AAC, and AAC-LC. And on top of the insane IPR cost of shipping these 6 codecs, you end up with an inflexible solution (hard to switch between 6 codecs in real-time based on the network bandwidth), with slightly lower quality, and that in practice nobody would fully implement. Jean-Marc From jmvalin@mozilla.com Wed Aug 29 06:11:04 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89E1121F8578 for ; Wed, 29 Aug 2012 06:11:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wiF8kztZS1Bm for ; Wed, 29 Aug 2012 06:11:03 -0700 (PDT) Received: from smtp.mozilla.org (mx2.corp.phx1.mozilla.com [63.245.216.70]) by ietfa.amsl.com (Postfix) with ESMTP id 9E67E21F8566 for ; Wed, 29 Aug 2012 06:11:03 -0700 (PDT) Received: from [192.168.1.15] (modemcable094.20-21-96.mc.videotron.ca [96.21.20.94]) (Authenticated sender: jvalin@mozilla.com) by mx2.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id C95F5F2454; Wed, 29 Aug 2012 06:10:58 -0700 (PDT) Message-ID: <503E14E1.6000401@mozilla.com> Date: Wed, 29 Aug 2012 09:10:57 -0400 From: Jean-Marc Valin User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Stefan Hakansson LK References: <9E2843EA-EBB9-40B3-898C-6B5216FAE7A5@cisco.com> <503CBB52.8070300@ericsson.com> <503CF224.5050609@mozilla.com> <503DE60D.2060706@ericsson.com> In-Reply-To: <503DE60D.2060706@ericsson.com> X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Confirmation of consensus on audio codecs X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 29 Aug 2012 13:11:04 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/29/2012 05:51 AM, Stefan Hakansson LK wrote: > the info above goes a long way in answering my questions, thanks. > I don't know the exact rules for IPR statements so I would like to > double check: the fact that the RFC only defines the decoder, does > that mean that there can be IPRs known by people in the codec WG > that are not declared since they would apply to the encoder only > (then there is the risk of IPRs held by those who have not > participated in codec WG)? The RFC includes and describes both the encoder and the decoder. What I was saying is that only the decoder was described normatively, while the encoder was allowed to change. So the IPR rules apply to both the encoder and the decoder. > Another question I had was if Opus is atomic, or if you can > implement different profiles, and if so what parts should be MTI > for rtcweb (and should the profile that is MTI be the same > regardless of the device type - there has been issues raised > regarding complexity?). Opus does not have profiles. That's what ensures that any Opus bitstream can be decoded by any compliant decoder. And that can happen *before* the decoder has even seen the SDP. > That is great, but sort of underlines that there would be no harm > in delaying the decision until there are experiences made from real > world use - 'cause it would not be that long till that experience > has been made (Markus also brought up the IPR status as a reason > for waiting - I have no idea how long it would take to know more > about that). As Harald is pointing out, rtcweb implementations are going to ship pretty soon. I don't see a reason to postpone decisions that can be made now. Are you expecting *another* single, standardized, royalty-free codec that operates over vast ranges of bitrates and operating conditions, from narrowband speech to stereo music, all with low delay, coming out in the next year? If not, what are you really waiting for? > As Paul suggested, I was referring to the lack of formal, > controlled, characterization tests. That is how other SDOs do it. I > don't think that is the only way to do it, but I think we should at > least have either such tests conducted or experience from > deployment and use (in a wide range of conditions and device types) > before making it MTI. Opus has had "ITU-style" testing on English ( http://www.opus-codec.org/comparison/GoogleTest1.pdf ) and Mandarin ( http://www.opus-codec.org/comparison/GoogleTest2.pdf ). And if you don't trust Google on the tests I linked to, it's also been tested by Nokia: http://research.nokia.com/files/public/%5B16%5D_InterSpeech2011_Voice_Quality_Characterization_of_IETF_Opus_Codec.pdf Now, unlike other SDOs, the testing did not stop there. ITU-T codecs generally end up being testing with something in the order of tens of minutes worth of audio. In *addition* to that kind of testing, Opus also had automated testing with hundreds of years worth of audio. If anything, I think other SDOs should learn something here. Jean-Marc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJQPhThAAoJEJ6/8sItn9q9nAcH/0BsXl/FBgMhbYWVALpNmIYi Yj1ezyW8JVSv4io1YIozucl6KiDVi3LwYFteYgl78PlQ7o2muv/lJP9VswRHooH5 Gax+aJUZkz7SlKxn+25wUlLgKQw6GAcUID5sJ0ewWdGOrwZu+SlZgYF3egYmmwyL pEl8BFj7wu3uakRm/BE9LsUDPFdCoZS6uXqXRJOy9P1dZ25edvgaymQvOwhEcXu9 xMq82YPNU2CZpfb88ew/l+U9FjW8c4iGkZYiu+VzmBL8wYOFP5pBhBhWc/bEb0WX 8IUC5PJ0MMp49kb7/kfQj65/Py7u6ytYaO4PA0rjMHJ2V1PzH4EuqtNweYXVzNI= =nwlD -----END PGP SIGNATURE----- From kaiduanx@gmail.com Wed Aug 29 06:42:03 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 223DC21F8673 for ; Wed, 29 Aug 2012 06:42:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WK+49dTHyhM7 for ; Wed, 29 Aug 2012 06:42:02 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8A99321F8668 for ; Wed, 29 Aug 2012 06:42:02 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so1150943obb.31 for ; Wed, 29 Aug 2012 06:42:01 -0700 (PDT) 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=j8tjc+IBLUGtpg8pmcAARp5MBnlwByNNc+V37Ij6B2o=; b=Oa7axUt7CndomQhMldyd+XrDozOU5WQe2uL4UEYer0jnIstiy3/gaOcHhr2zG8ZX3N 4sabQsXV7AIvULvHEuALd5m7BocecHrwwHXEfPfyM1w9bbpkpELLqrpvD+MoGEwkuSV9 Zpy7OvLENNW/JwAHtNF52dbH4Y4Z6IHs6aiRf9v9wGSZTR6Xebu4POV22ZVU5KJ+yDhi TYfXZqWm8rMa6yw8bz2N+AKd2zP8Z9nX/hLv/nu1p2EDzBsgd4ZbvbEEIl2ws9mGnITx A8FcT8AA8I2/m1yztbOCQnpx9lT6QAgRYzoVeR8QiBm0XwT08aoAVZ82xgeD3uVuqGkw CPDw== MIME-Version: 1.0 Received: by 10.182.212.98 with SMTP id nj2mr1233315obc.18.1346247721757; Wed, 29 Aug 2012 06:42:01 -0700 (PDT) Received: by 10.76.23.129 with HTTP; Wed, 29 Aug 2012 06:42:01 -0700 (PDT) In-Reply-To: References: Date: Wed, 29 Aug 2012 09:42:01 -0400 Message-ID: From: Kaiduan Xie To: Justin Uberti Content-Type: text/plain; charset=ISO-8859-1 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Clarification on offer/answer in jsep-01 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 29 Aug 2012 13:42:03 -0000 "The offer would not actually be sent until after the updated local description has been applied, so this would not violate 3264." It makes sense now, please add this sentence to the next draft. /Kaiduan On Wed, Aug 29, 2012 at 3:31 AM, Justin Uberti wrote: > The text here is incorrect, this was a mistake on my part. While this usage > is technically permissible if you can deal with the complications it > introduces, it is not compliant with RFC 3264, as has been pointed out. > > What I meant to say here was that the local description can be updated even > after an initial local description has been specified. There are real-world > use cases for this, such as setting an initial local description to tell the > ICE Agent the number of m= lines to gather candidates for, followed by a > later update when the getUserMedia MediaStream has been obtained. The offer > would not actually be sent until after the updated local description has > been appliced, so this would not violate 3264. > > > On Tue, Aug 28, 2012 at 5:57 AM, Cullen Jennings wrote: >> >> >> On Aug 27, 2012, at 10:48 PM, Francois Audet >> wrote: >> >> >> "As in [RFC3264], an offerer can send an offer, and update it as long >> >> as it has not been answered." >> >> yah that won't work or all the reasons mentioned before and in my opinion >> does not represent the WG consensus. BTW - that was added in the -01 version >> of the draft and submitted without me ever seeing it - I'd be happy to fix >> it but I don't have the source for the draft. Chairs? >> >> >> >> _______________________________________________ >> 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 > From kaiduanx@gmail.com Wed Aug 29 06:58:31 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5520E11E80D1 for ; Wed, 29 Aug 2012 06:58:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uiePIHwPGcdn for ; Wed, 29 Aug 2012 06:58:29 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 92F6011E808E for ; Wed, 29 Aug 2012 06:58:29 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so1195811obb.31 for ; Wed, 29 Aug 2012 06:58:29 -0700 (PDT) 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=PsVr8Sxm5ISSI8FQilW8Z5dYoSLtBZQKnoqK7EuSsRo=; b=cLWt6glMyjk9uKNZQ2M+wA8mf6Ol4UGQPRpCfRp3Hy9pJBhu+mMNELCxSV3/6RYleE x+LLrbeicl0SOZdwP+MmGbFNSLrrDLsYn/K0+QQxYfnVfoVTf6PpA6ImPojjdtLHDhdd ZLBlVAX9/BU0dAZvOv2G09ZNZPZYZPvRY+OeFrDbR19hYwLGhyeAT1Mt6WoS0ZYY1EGS g1N/6dxVxCq4gXj7eVzlWu8cZ5mxoECBbtoCp2j+CpFCfd3Czv5yxc65Cq6XZpW1B8gu 5WtB+DqRTVkV31w8yKLvK9lEmsXxx4I9NrWDAgZc4moEyzDbqr6lJqur5YPTjHrtCLnc 6hjA== MIME-Version: 1.0 Received: by 10.60.171.174 with SMTP id av14mr1295100oec.61.1346248709252; Wed, 29 Aug 2012 06:58:29 -0700 (PDT) Received: by 10.76.23.129 with HTTP; Wed, 29 Aug 2012 06:58:29 -0700 (PDT) In-Reply-To: References: Date: Wed, 29 Aug 2012 09:58:29 -0400 Message-ID: From: Kaiduan Xie To: Lishitao Content-Type: text/plain; charset=ISO-8859-1 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Clarification on offer/answer in jsep-01 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 29 Aug 2012 13:58:31 -0000 > The next sentence just after this one > " The answerer can send back zero or more > provisional answers, and finally end the offer-answer exchange by > sending a final answer." > does not describe quite well either, right? > > AFAIK , the answerer can send back zero or more provisional answers, but they are not all SDP answers, If we look the Section 12.1.1 of RFC5245 (ICE), "If an offer is received in an INVITE request, the answerer SHOULD begin to gather its candidates on receipt of the offer and then generate an answer in a provisional response once it has completed that process. ICE requires that a provisional response with an SDP be transmitted reliably. This can be done through the existing Provisional Response Acknowledgment (PRACK) mechanism [RFC3262] or through an optimization that is specific to ICE ..." Here provisional response carriers answer, but the offer/answer exchange is completed. Offerer can send PRACK with SDP to updates the offer, and the answerer replies answer in 200 of PRACK, but this is a new round of offer/answer exchange. Also from the RFC 6337 (Session Initiation Protocol (SIP) Usage of the Offer/Answer Model ), we can't find the case where the answerer sends multiple different answers for one offer. So it seems that we also need clarification on the following, "The answerer can send back zero or more provisional answers, and finally end the offer-answer exchange by sending a final answer." /Kaiduan On Tue, Aug 28, 2012 at 10:50 PM, Lishitao wrote: > > >> -----Original Message----- >> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf >> Of Cullen Jennings >> Sent: Tuesday, August 28, 2012 8:58 PM >> To: Francois Audet >> Cc: rtcweb@ietf.org >> Subject: Re: [rtcweb] Clarification on offer/answer in jsep-01 >> >> >> On Aug 27, 2012, at 10:48 PM, Francois Audet >> wrote: >> >> >> "As in [RFC3264], an offerer can send an offer, and update it as long >> >> as it has not been answered." >> >> yah that won't work or all the reasons mentioned before and in my opinion does >> not represent the WG consensus. BTW - that was added in the -01 version of >> the draft and submitted without me ever seeing it - I'd be happy to fix it but I >> don't have the source for the draft. Chairs? >> > > The next sentence just after this one > " The answerer can send back zero or more > provisional answers, and finally end the offer-answer exchange by > sending a final answer." > does not describe quite well either, right? > > AFAIK , the answerer can send back zero or more provisional answers, but they are not all SDP answers, > > and I don't find any place in RFC 3264 has the definition about "final answer". > > shitao > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From Bernhard.Feiten@telekom.de Wed Aug 29 07:01:18 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6786411E80D1 for ; Wed, 29 Aug 2012 07:01:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iTzXWvKo74zJ for ; Wed, 29 Aug 2012 07:01:14 -0700 (PDT) Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by ietfa.amsl.com (Postfix) with ESMTP id 2C6B211E809A for ; Wed, 29 Aug 2012 07:01:14 -0700 (PDT) Received: from he111528.emea1.cds.t-internal.com ([10.125.90.87]) by tcmail31.telekom.de with ESMTP/TLS/AES128-SHA; 29 Aug 2012 16:01:11 +0200 Received: from HE111541.emea1.cds.t-internal.com ([169.254.2.25]) by HE111528.EMEA1.CDS.T-INTERNAL.COM ([2002:7cd:5a57::7cd:5a57]) with mapi; Wed, 29 Aug 2012 16:01:11 +0200 From: To: Date: Wed, 29 Aug 2012 16:01:10 +0200 Thread-Topic: Confirmation of consensus on audio codecs Thread-Index: AQHNe9LENUMF/Hj3nEmo2lnRJlNz25dwxSKw Message-ID: References: <9E2843EA-EBB9-40B3-898C-6B5216FAE7A5@cisco.com> In-Reply-To: <9E2843EA-EBB9-40B3-898C-6B5216FAE7A5@cisco.com> Accept-Language: de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [rtcweb] Confirmation of consensus on audio codecs X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 29 Aug 2012 14:01:18 -0000 The mandatory-to implement (MTI) codec for rtcweb should ensure interoperab= ility and good quality.=20 It should be possible to implement the codec without hurdles. The G.722 provides wideband quality at 64 kbit/s. It is easy to implement a= nd causes no additional costs. Hence G.722 should be a MTI codec for rtcweb.=20 It provides also interoperability to other voice communication services. For interoperability reasons to other voice communication services G.711 sh= ould be a MTI codec for rtcweb.=20 It provides only narrow-band quality. But it is easy to implement and cause= s no additional costs. =20 For interoperability reasons to other voice communication services AMR and= AMR-WB should be supported. As these codecs are not that easy to implement and may cause additional cos= ts, they should not be MTI codecs for rtcweb. If rtcweb is used for calls to mobile phones, it is likely that these codec= s will be supported as this guarantees the best quality.=20 =20 Other low bitrate codec may be supported , but should not be MTI codec for= rtcweb. The codecs cause additional hurdles. Interoperability is already g= uaranteed by the MTI codecs. The implementer can decide on its own to suppo= rt the codec. =20 Best regards, Bernhard -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= Cullen Jennings (fluffy) Sent: Donnerstag, 16. August 2012 19:16 To: rtcweb@ietf.org Subject: [rtcweb] Confirmation of consensus on audio codecs At the last meeting we took a hum on selecting Opus and G.711 as the mediat= ory to implement audio codecs. If there is any new opinions please send the= m to the list by August 30th, after which the chairs will make a determinat= ion of consensus. Thanks, Cullen Please note that the following IPR disclosure have been made on these codec= s. They can be found at=20 http://datatracker.ietf.org/ipr/ 2010-11-07=09 * ID # 1445 "Broadcom Corporation's Statement about IPR related to draft-ietf-codec-opu= s-00 and draft-ietf-codec-description-00 (1)" 2010-11-07=09 * ID # 1446 "Xiph.Org Foundation's Statement about IPR related to draft-ietf-codec-opus= -00" 2010-11-12=09 * ID # 1447 "Broadcom Corporation's Statement about IPR related to draft-ietf-codec-opu= s-00 and draft-ietf-codec-description-00 (2)" 2011-03-23=09 * ID # 1520 "Qualcomm Incorporated's Statement about IPR related to draft-ietf-codec-op= us-05" 2011-03-27=09 * ID # 1524 "Xiph.Org Foundation's Statement about IPR related to draft-ietf-codec-opus= -05" 2011-03-29=09 * ID # 1526 "Broadcom Corporation's Statement about IPR related to draft-ietf-codec-opu= s-05" 2011-03-29=09 * ID # 1525 "Skype Limited's Statement about IPR related to draft-ietf-codec-opus-05" 2011-07-23=09 * ID # 1602 "Skype Limited's Statement about IPR related to draft-ietf-codec-opus-07" 2012-01-25=09 * ID # 1670 "Microsoft Corporation's Statement about IPR related to draft-ietf-codec-op= us-10" 2012-03-12=09 * ID # 1712 "Huawei Technologies Co.,Ltd's Statement about IPR related to draft-ietf-co= dec-opus-11 (1)" 2012-04-02=09 * ID # 1741 "Huawei Technologies Co.,Ltd's Statement about IPR related to draft-ietf-co= dec-opus-11 (2)" _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From mandyam@quicinc.com Wed Aug 29 07:31:13 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B75B221F86B5 for ; Wed, 29 Aug 2012 07:31:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.792 X-Spam-Level: X-Spam-Status: No, score=-5.792 tagged_above=-999 required=5 tests=[AWL=0.807, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mNcMIA9gRstP for ; Wed, 29 Aug 2012 07:31:09 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id C06DA21F8527 for ; Wed, 29 Aug 2012 07:31:09 -0700 (PDT) X-IronPort-AV: E=McAfee;i="5400,1158,6818"; a="228407999" Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by wolverine02.qualcomm.com with ESMTP; 29 Aug 2012 07:30:54 -0700 X-IronPort-AV: E=Sophos;i="4.80,334,1344236400"; d="scan'208";a="291435543" Received: from nasanexhc14.na.qualcomm.com ([172.30.48.23]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 29 Aug 2012 07:30:54 -0700 Received: from NASANEXD01H.na.qualcomm.com ([169.254.8.250]) by nasanexhc14.na.qualcomm.com ([172.30.48.23]) with mapi id 14.02.0318.001; Wed, 29 Aug 2012 07:30:53 -0700 From: "Mandyam, Giridhar" To: Stefan Hakansson LK , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Confirmation of consensus on audio codecs Thread-Index: AQHNe9LENUMF/Hj3nEmo2lnRJlNz25dvsTcAgAAjkuA= Date: Wed, 29 Aug 2012 14:30:53 +0000 Message-ID: References: <9E2843EA-EBB9-40B3-898C-6B5216FAE7A5@cisco.com> <503CBB52.8070300@ericsson.com> In-Reply-To: <503CBB52.8070300@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [199.106.115.132] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [rtcweb] Confirmation of consensus on audio codecs X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 29 Aug 2012 14:31:13 -0000 I support a) below. This will allow us to gain operational experience with= various codecs, and an update to the RTCWeb specifications can later manda= te additional codecs as needed. -Giri Mandyam -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= Stefan Hakansson LK Sent: Tuesday, August 28, 2012 5:37 AM To: rtcweb@ietf.org Subject: Re: [rtcweb] Confirmation of consensus on audio codecs On 08/16/2012 07:15 PM, Cullen Jennings (fluffy) wrote: > > At the last meeting we took a hum on selecting Opus and G.711 as the=20 > mediatory to implement audio codecs. If there is any new opinions=20 > please send them to the list by August 30th, after which the chairs=20 > will make a determination of consensus. As much as I would like to say "I agree", I come to the conclusion it is no= t that simple. I have two things that concern me: * "Opus" not well enough defined * Opus not mature and proven enough (this is the more important concern) Lets talk about both of these. "Opus" not well enough defined =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D Just saying "Opus" is a bit vague for me (who has not been in the codec WG)= . Is a certain version meant? Which one? Or is it a moving target (i.e. alw= ays implement the latest version)? What is included (is jitter management, loss concealment part of Opus or so= mething that is up to the implementation)? And how is it judged what is a compliant implementation? Is there a ref imp= lementation that you test against? How do you test? Are there test-vectors = that must be conformed to? Or is "Opus" standardized as a wire format (mean= ing that any implementation that can produce/decode that wire format is com= pliant)? If the latter is true, implementers have more wiggle room to e.g. = reduce complexity or design around IPRs (submarine IPRs may surface). Are i= mplementors required to support all aspects of Opus, or are there sub-sets/= profiles that would be sufficient (perhaps for certain classes of devices)?= [1] suggests that not all ptime options need to be supported, but are ther= e others things? Many of the answers are probably available, but I think they should be put = in front of the WG before making this decision. Opus not mature and proven enough =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D As far as I understand, Opus is a brand new standard. There are implementat= ions on-going, but yet no deployment, no experience from real world use (an= d definitely not from use in larger scale over a wide range of conditions, = involving a broad range of end user devices). In addition, I've been told t= hat so far Opus has gone through less characterization tests than codecs us= ually are put through. I don't think it is fair to mandate the implementation of a codec (which is= a large and complex piece) under these circumstances. Some real deployment= (involving many device types) and experience (including operation in diffe= rent conditions) should be gained before doing so. It could also be argued = that there is a bigger risk from a licensing perspective to mandate a codec= that has not been in use. Do I mean we should mandate just G.711? =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D No, not necessarily. Looking ahead, I am convinced that new and improved co= decs for audio and video will be introduced as they become available.=20 There is a logic in adopting technology that reduces the transmitted number= of bits and enhances the end user experience, and the WG is designing a so= lution that enables new codecs to be introduced and used (and I really hope= they can be made use of even if the applications is untouched) IIUC. However, if G.711 would be the only MTI audio codec, servi= ces that expect audio BW that goes beyond narrowband could suffer since the= re is no guarantee that there is any other codec than G.711 supported by bo= th endpoints. In addition G.711 is not that well suited for for challenging network condi= tions (the most important parts like packet loss concealment and jitter man= agement depends on the implementation - or are we going to standardize thos= e parts?; what I am after is that it is unable to lower the send rate as re= action to congestion - the only method available is to use longer frames to= make the IP header overhead lower). I see three possible ways forward: a) Mandate G.711 only, and let the market decide if there will be a univers= ally available codec giving higher quality. b) Postpone the decision for some time. Let Opus (and other new codecs if s= uch are introduced) get deployed, tested, perhaps improved. The drawback wi= th this approach is that the selection is delayed. If this approach is chos= en, I would also recommend that the WG spends some time on selection criter= ia. In the presentation given in Vancouver ([2]) six criteria were used (th= ree of them considered more important). I think they make sense, but can't = remember we actually discussed them (or what other criteria that may make s= ense). c) Mandate some other codec (that is already deployed and in use). Of these approaches, perhaps b) is the most reasonable one. Stefan [1] http://datatracker.ietf.org/doc/draft-cbran-rtcweb-codec/?include_text= =3D1 [2] http://www.ietf.org/proceedings/84/slides/slides-84-rtcweb-6.pdf > > Thanks, Cullen > > Please note that the following IPR disclosure have been made on these=20 > codecs. They can be found at > > http://datatracker.ietf.org/ipr/ > > > 2010-11-07 * ID # 1445 "Broadcom Corporation's Statement about IPR=20 > related to draft-ietf-codec-opus-00 and > draft-ietf-codec-description-00 (1)" 2010-11-07 * ID # 1446 "Xiph.Org=20 > Foundation's Statement about IPR related to draft-ietf-codec-opus-00"=20 > 2010-11-12 * ID # 1447 "Broadcom Corporation's Statement about IPR=20 > related to draft-ietf-codec-opus-00 and=20 > draft-ietf-codec-description-00 (2)" 2011-03-23 * ID # 1520 "Qualcomm=20 > Incorporated's Statement about IPR related to=20 > draft-ietf-codec-opus-05" 2011-03-27 * ID # 1524 "Xiph.Org=20 > Foundation's Statement about IPR related to draft-ietf-codec-opus-05"=20 > 2011-03-29 * ID # 1526 "Broadcom Corporation's Statement about IPR=20 > related to draft-ietf-codec-opus-05" 2011-03-29 * ID # 1525 "Skype=20 > Limited's Statement about IPR related to draft-ietf-codec-opus-05"=20 > 2011-07-23 * ID # 1602 "Skype Limited's Statement about IPR related to=20 > draft-ietf-codec-opus-07" 2012-01-25 * ID # 1670 "Microsoft=20 > Corporation's Statement about IPR related to draft-ietf-codec-opus-10"=20 > 2012-03-12 * ID # 1712 "Huawei Technologies Co.,Ltd's Statement about=20 > IPR related to draft-ietf-codec-opus-11 (1)" 2012-04-02 * ID # 1741=20 > "Huawei Technologies Co.,Ltd's Statement about IPR related to=20 > draft-ietf-codec-opus-11 (2)" > > > > _______________________________________________ rtcweb mailing list=20 > rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb > _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From petithug@acm.org Wed Aug 29 07:48:44 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B9D921F8530 for ; Wed, 29 Aug 2012 07:48:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.539 X-Spam-Level: X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yDlOAEzEBv+X for ; Wed, 29 Aug 2012 07:48:40 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id B015121F8528 for ; Wed, 29 Aug 2012 07:48:40 -0700 (PDT) Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] (shalmaneser.org [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 3172820550; Wed, 29 Aug 2012 14:48:37 +0000 (UTC) Message-ID: <503E2BC2.1090705@acm.org> Date: Wed, 29 Aug 2012 07:48:34 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.6esrpre) Gecko/20120817 Icedove/10.0.6 MIME-Version: 1.0 To: "Cullen Jennings (fluffy)" References: <9E2843EA-EBB9-40B3-898C-6B5216FAE7A5@cisco.com> In-Reply-To: <9E2843EA-EBB9-40B3-898C-6B5216FAE7A5@cisco.com> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Confirmation of consensus on audio codecs X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 29 Aug 2012 14:48:44 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 I support the selection of Opus and G.711 as mandatory. On 08/16/2012 10:15 AM, Cullen Jennings (fluffy) wrote: > > At the last meeting we took a hum on selecting Opus and G.711 as the > mediatory to implement audio codecs. If there is any new opinions please > send them to the list by August 30th, after which the chairs will make a > determination of consensus. > > Thanks, Cullen > > Please note that the following IPR disclosure have been made on these > codecs. They can be found at > > http://datatracker.ietf.org/ipr/ > > > 2010-11-07 • ID # 1445 "Broadcom Corporation's Statement about IPR related > to draft-ietf-codec-opus-00 and draft-ietf-codec-description-00 (1)" > 2010-11-07 • ID # 1446 "Xiph.Org Foundation's Statement about IPR related > to draft-ietf-codec-opus-00" 2010-11-12 • ID # 1447 "Broadcom > Corporation's Statement about IPR related to draft-ietf-codec-opus-00 and > draft-ietf-codec-description-00 (2)" 2011-03-23 • ID # 1520 "Qualcomm > Incorporated's Statement about IPR related to draft-ietf-codec-opus-05" > 2011-03-27 • ID # 1524 "Xiph.Org Foundation's Statement about IPR related > to draft-ietf-codec-opus-05" 2011-03-29 • ID # 1526 "Broadcom > Corporation's Statement about IPR related to draft-ietf-codec-opus-05" > 2011-03-29 • ID # 1525 "Skype Limited's Statement about IPR related to > draft-ietf-codec-opus-05" 2011-07-23 • ID # 1602 "Skype Limited's > Statement about IPR related to draft-ietf-codec-opus-07" 2012-01-25 • ID # > 1670 "Microsoft Corporation's Statement about IPR related to > draft-ietf-codec-opus-10" 2012-03-12 • ID # 1712 "Huawei Technologies > Co.,Ltd's Statement about IPR related to draft-ietf-codec-opus-11 (1)" > 2012-04-02 • ID # 1741 "Huawei Technologies Co.,Ltd's Statement about IPR > related to draft-ietf-codec-opus-11 (2)" > - -- Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJQPiu8AAoJECnERZXWan7EZOQQAKoO+TkLn1qXif/RkM5B9DzM f7+CqomI5T4gGHVKffVruxYXsx75RKzVmbzyd/T/pJgu6agM8xB5aTscxdobtM+L RY3Rw3bbmy7OESLA6zpU7PW8WJS3AtVXG0CMBrUQ6qe/KQbVfgGJVVb5rk2/LdmV eL9XxzklU6xGa0cPXO7QJlI/ifF26gPJgSqRdL3ct4WI/7jAohmCWKee7/eCjXbH S0sCDiGa0fp41js8q1IR1cOiNbzg0zumL1VwIA2yspKcvtXPzpMe97oMH4Ba2q0k SR1G4qGdkDt7bzHcCFutNuRKVx26ARBWXGRQWfOnLAvpE6kABekc7OnF6m9jom4w OLuAvsZc2NqfCs5DduM3yK9ZWE1tK10kMTDE8whbVLNGgyEfp2UPBIsrGCOreBxJ Y5XEsMQtI8O6F/RM6cOSExtoxzwPliDcdaInuBTtPVHxU5Ob1iCCIJ6oNCB4bowJ YNqPMzPk85kLRE9FjJz7HalhzR1YA3Gco+QlTKzGtRLdva4Q24l1atx+UtJrLJrn jAdsCBbPWV/N0D0VrsKKvvtdwXmgYR9lDn44bizCOajZR5xeaoTaRaYp8v6y5iuU cqwo0j0XNidCmra/ua+McosrTCq5zMqJRMSeCY45MlhiN42Bcgk+2HbFW9w5UEUH 8zIChnAw0MBIC25Gg1YT =Z7tv -----END PGP SIGNATURE----- From randell-ietf@jesup.org Wed Aug 29 08:24:53 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3356221F86CF for ; Wed, 29 Aug 2012 08:24:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.13 X-Spam-Level: X-Spam-Status: No, score=-1.13 tagged_above=-999 required=5 tests=[AWL=-0.945, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HZMlCpyf13cS for ; Wed, 29 Aug 2012 08:24:52 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id ADC8E21F86B6 for ; Wed, 29 Aug 2012 08:24:52 -0700 (PDT) Received: from pool-173-49-141-60.phlapa.fios.verizon.net ([173.49.141.60] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1T6k8R-000Dc9-DD for rtcweb@ietf.org; Wed, 29 Aug 2012 10:24:51 -0500 Message-ID: <503E3422.6010508@jesup.org> Date: Wed, 29 Aug 2012 11:24:18 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <9E2843EA-EBB9-40B3-898C-6B5216FAE7A5@cisco.com> <503E2BC2.1090705@acm.org> In-Reply-To: <503E2BC2.1090705@acm.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [rtcweb] Confirmation of consensus on audio codecs X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 29 Aug 2012 15:24:53 -0000 I support the selection of Opus and G.711 and MTI codecs (as I did in the room, even though I officially proposed Opus only as an option to vote on). I suggest anyone considering suggesting G.711 to examine the slides from Tim's presentation, and if possible watch that section of the video or listen to the audio (which I assume are online). It wasn't an accident that the vote in-room (and there were a LOT of people) was basically "Opus only: ~5 votes; G.711 only: 0 or 1 votes; rest of the room: Opus and G.711" -- Randell Jesup randell-ietf@jesup.org From stpeter@stpeter.im Wed Aug 29 08:40:04 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD47C11E80CC for ; Wed, 29 Aug 2012 08:39:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.574 X-Spam-Level: X-Spam-Status: No, score=-102.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d8inoTDVPo60 for ; Wed, 29 Aug 2012 08:39:49 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 0271611E80BF for ; Wed, 29 Aug 2012 08:39:49 -0700 (PDT) Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id A06F8404EB; Wed, 29 Aug 2012 09:41:00 -0600 (MDT) Message-ID: <503E37C3.1010509@stpeter.im> Date: Wed, 29 Aug 2012 09:39:47 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Randell Jesup References: <9E2843EA-EBB9-40B3-898C-6B5216FAE7A5@cisco.com> <503E2BC2.1090705@acm.org> <503E3422.6010508@jesup.org> In-Reply-To: <503E3422.6010508@jesup.org> X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Confirmation of consensus on audio codecs X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 29 Aug 2012 15:40:04 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 8/29/12 9:24 AM, Randell Jesup wrote: > I support the selection of Opus and G.711 and MTI codecs (as I did > in the room, even though I officially proposed Opus only as an > option to vote on). Yes, that seems like the most reasonable approach. I plan to push for an update to XEP-0266 ("Codecs for Jingle Audio") to align XMPP/Jingle here (we were waiting for draft-ietf-codec-opus to be approved by the IESG). Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlA+N8MACgkQNL8k5A2w/vz8gwCeM5wOz9Cg0LGWKx3SWStoRyz6 Fi4AnA193xS6GO2Sy1SAcGsc8EPrYvDb =cNEn -----END PGP SIGNATURE----- From randy@qualcomm.com Wed Aug 29 09:29:02 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 488BE21F84B2 for ; Wed, 29 Aug 2012 09:29:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.87 X-Spam-Level: X-Spam-Status: No, score=-104.87 tagged_above=-999 required=5 tests=[AWL=-1.729, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_DNSWL_MED=-4, SARE_RAND_1=2, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SeHVZgQOtSqq for ; Wed, 29 Aug 2012 09:29:01 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id 41DF821F84AE for ; Wed, 29 Aug 2012 09:29:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=@qualcomm.com; q=dns/txt; s=qcdkim; t=1346257742; x=1377793742; h=message-id:x-mailer:date:to:from:subject:mime-version: content-type:x-random-sig-tag:x-originating-ip; bh=uGhRfwbTvLM5gN9HlBFZ7jexQay01HNpeoBV3PWf0sc=; b=HJ62vcwWYdZy80HNnp3UvAwjW9edsG2CZ44eKwJ4zV0pnyoVNpluVqEM He1LGSAOZk7v7elV27DKW61/0M4asCxqYxUjcLdwlk5IlYo4//JJT1J9w DVujowVyiWwedU36YV3yPRzOzpms6OjzOeMtIYUoyzWdfQoJEb0HAhSoL 0=; X-IronPort-AV: E=McAfee;i="5400,1158,6819"; a="228451864" Received: from ironmsg02-r.qualcomm.com ([172.30.46.16]) by wolverine02.qualcomm.com with ESMTP; 29 Aug 2012 09:28:59 -0700 X-IronPort-AV: E=Sophos;i="4.80,334,1344236400"; d="scan'208,217";a="160835134" Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by ironmsg02-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 29 Aug 2012 09:28:59 -0700 Received: from [99.111.97.136] (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.17) with Microsoft SMTP Server (TLS) id 14.2.318.1; Wed, 29 Aug 2012 09:28:57 -0700 Message-ID: X-Mailer: Eudora for Mac OS X Date: Wed, 29 Aug 2012 09:25:53 -0700 To: , , From: Randall Gellens MIME-Version: 1.0 Content-Type: text/html; charset="us-ascii" X-Random-Sig-Tag: 1.0b28 X-Originating-IP: [172.30.48.1] Subject: Re: [rtcweb] Confirmation of consensus on audio codecs X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 29 Aug 2012 16:29:02 -0000 Re: [rtcweb] Confirmation of consensus on audio codecs
At 7:26 PM +0000 8/28/12, <Markus.Isomaki@nokia.com> wrote:

We do not recommend Opus to be taken as a mandatory codec for RTCWeb at this point. From high quality low bit rate and mobile applications point of view the 3GPP AMR-WB codec (also known as ITU-T G.722.2) is the most preferable for us. For interoperability with implementations restricted to unencumbered codecs, we prefer G.711 and G.722.

Mandating only G.711 provides a floor to prevent total failure to negotiate codecs, while allowing implementations to support whichever codecs make sense in their environments.


At 8:39 PM -0700 8/21/12, Ted Hardie <ted.ietf at gmail.com> wrote:

the fundamental design of RTCWEB allows for the
negotiation of any codec mutually supported.  The decision to chose a
Mandatory-to-implement was not made to eliminate other choices, but to
eliminate interoperability failures by ensuring that at least one
common codec is always available.

I think this is a key point.  Codecs should be mandated only to prevent negotiation failure, not to guarantee ideal performance, especially in light of Ted's next statement:

At 8:39 PM -0700 8/21/12, Ted Hardie <ted.ietf at gmail.com> wrote:

the group presumes that codec support does not
come from the downloadable Javascript application, but from the
application environment into which it is downloaded (commonly a
browser or mobile environment using similar technology).  Promoting
support for those environments to have access to codecs supported by
the underlying hardware is the best way to further this goal, at least
in my personal opinion.

This makes a lot of sense. Especially on mobile devices, natively supported codecs are likely to have optimized performance within the operating environment (e.g., mobile device and cellular channel).

--
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
#Random Tag
--
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
When you're young, you look at television and think, There's a
conspiracy. The networks have conspired to dumb us down. But when
you get a little older, you realize that's not true. The networks
are in business to give people exactly what they want. That's a
far more depressing thought. Conspiracy is optimistic! You can
shoot the bastards! We can have a revolution! But the networks
are really in business to give people what they want. It's the
truth.              --Steve Jobs, Wired Magazine, February 1996
From randy@qualcomm.com Wed Aug 29 09:32:14 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3AA421F84C2 for ; Wed, 29 Aug 2012 09:32:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.257 X-Spam-Level: X-Spam-Status: No, score=-106.257 tagged_above=-999 required=5 tests=[AWL=-0.258, BAYES_00=-2.599, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SUQzDTYNEdEq for ; Wed, 29 Aug 2012 09:32:14 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by ietfa.amsl.com (Postfix) with ESMTP id 40B6021F84B9 for ; Wed, 29 Aug 2012 09:32:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=@qualcomm.com; q=dns/txt; s=qcdkim; t=1346257935; x=1377793935; h=message-id:x-mailer:date:to:from:subject:mime-version: content-type:x-random-sig-tag:x-originating-ip; bh=kBPC2Qg2M3Rnv3BuVptKxhbr5h8kXt69nZjaqNMp4bk=; b=zVOEZmXMQQHHPKCIwYR7pm1/sJPHaNoEHjBJCXXNMrT1pAcNSmuVaTtM Irx2FuynFufIWWXfJdY8ktcFLfwVDS9sWZIwPBRbKnPu5W6780BlhDRim KMb90UMVobUgn9JdtbvIUCT3EapAFO1d5Y6iNuAxeZAYMNDiLpXxcqViZ 0=; X-IronPort-AV: E=McAfee;i="5400,1158,6819"; a="230774175" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by wolverine01.qualcomm.com with ESMTP; 29 Aug 2012 09:32:14 -0700 X-IronPort-AV: E=Sophos;i="4.80,334,1344236400"; d="scan'208";a="321729730" Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 29 Aug 2012 09:32:14 -0700 Received: from [99.111.97.136] (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.17) with Microsoft SMTP Server (TLS) id 14.2.318.1; Wed, 29 Aug 2012 09:32:13 -0700 Message-ID: X-Mailer: Eudora for Mac OS X Date: Wed, 29 Aug 2012 09:29:33 -0700 To: Alan Johnston , From: Randall Gellens MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Random-Sig-Tag: 1.0b28 X-Originating-IP: [172.30.48.1] Subject: Re: [rtcweb] RTCWEB needs an Internet Codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 29 Aug 2012 16:32:14 -0000 At 10:41 PM -0500 8/28/12, Alan Johnston wrote: > The RTCWEB effort needs an Internet codec. This is why Opus is the > right choice. RTCWEB also needs one codec for backwards compatibility > with the VoIP world. This is why G.711 is also the right choice. > > Any G.mumble codec is NOT an Internet codec and will not have the same > performance on the Internet as one that was designed for the Internet! > If anyone doesn't understand what that means, go back and examine the > CODEC Working Group archives to get educated. > > If someone wants another codec instead of Opus, then they need to > propose another Internet codec. Otherwise, we are not serving the > Internet. We only need one mandatory audio codec. Everything else can be left up to implementations and experience. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- The two most common elements in the universe are hydrogen and stupidity. --Harlan Ellison From randy@qualcomm.com Wed Aug 29 09:32:15 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5F1D21F8610 for ; Wed, 29 Aug 2012 09:32:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.551 X-Spam-Level: X-Spam-Status: No, score=-106.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AX25egg-FWwd for ; Wed, 29 Aug 2012 09:32:15 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id 51E4321F84B9 for ; Wed, 29 Aug 2012 09:32:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=@qualcomm.com; q=dns/txt; s=qcdkim; t=1346257936; x=1377793936; h=message-id:x-mailer:date:to:from:subject:cc:mime-version: content-type:x-random-sig-tag:x-originating-ip; bh=d9TzBLuDdJsQ/rFVVfrfUjHsdAiY7KWZad/EM62lHcg=; b=rhieK/F07aXgj1nQSvzzvhNQil3TNPaaogagWykLoIHlqT0IQYYgqlk6 Am50Ql3K2kTvm3I581D45ZSUMoDpde+4auej6mptQDq96+GA+HQxvQ1ST C4s/wAUPE2xyVsiFwBz8HdI+TC4xBhx200hGZeDLtkI72c7Vc+ib2M7fv 4=; X-IronPort-AV: E=McAfee;i="5400,1158,6819"; a="228453483" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by wolverine02.qualcomm.com with ESMTP; 29 Aug 2012 09:32:16 -0700 X-IronPort-AV: E=Sophos;i="4.80,335,1344236400"; d="scan'208";a="378047115" Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 29 Aug 2012 09:32:15 -0700 Received: from [99.111.97.136] (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.17) with Microsoft SMTP Server (TLS) id 14.2.318.1; Wed, 29 Aug 2012 09:32:14 -0700 Message-ID: X-Mailer: Eudora for Mac OS X Date: Wed, 29 Aug 2012 09:30:15 -0700 To: Roman Shpount , Alan Johnston From: Randall Gellens MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Random-Sig-Tag: 1.0b28 X-Originating-IP: [172.30.48.1] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] RTCWEB needs an Internet Codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 29 Aug 2012 16:32:15 -0000 At 12:13 AM -0400 8/29/12, Roman Shpount wrote: > I would argue G.711 should be the MTI codec. The rest can be left > up to browser implementers. I agree. > We can argue all we want, but the best royalty free low bitrate > codec available will be the one everybody supports. Very good point, and why we should mandate only one audio codec. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- The most likely way for the world to be destroyed, most experts agree, is by accident. That's where we come in; we're computer professionals. We cause accidents. --Nathaniel Borenstein From basilgohar@librevideo.org Wed Aug 29 09:40:40 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E52EE11E80E8 for ; Wed, 29 Aug 2012 09:40:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xOYsUoWg0+r5 for ; Wed, 29 Aug 2012 09:40:38 -0700 (PDT) Received: from mail.zaytoon.hidayahonline.net (zaytoon.hidayahonline.net [173.193.202.83]) by ietfa.amsl.com (Postfix) with ESMTP id D81E111E80E0 for ; Wed, 29 Aug 2012 09:40:38 -0700 (PDT) Received: from [10.10.40.98] (rrcs-98-103-138-67.central.biz.rr.com [98.103.138.67]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: basilgohar@librevideo.org) by mail.zaytoon.hidayahonline.net (Postfix) with ESMTPSA id 63C2B658E50 for ; Wed, 29 Aug 2012 12:40:37 -0400 (EDT) Message-ID: <503E4602.9070509@librevideo.org> Date: Wed, 29 Aug 2012 12:40:34 -0400 From: Basil Mohamed Gohar User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120717 Thunderbird/14.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <9E2843EA-EBB9-40B3-898C-6B5216FAE7A5@cisco.com> <503E2BC2.1090705@acm.org> <503E3422.6010508@jesup.org> In-Reply-To: <503E3422.6010508@jesup.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Confirmation of consensus on audio codecs X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 29 Aug 2012 16:40:41 -0000 On 08/29/2012 11:24 AM, Randell Jesup wrote: > I support the selection of Opus and G.711 and MTI codecs (as I did in > the room, even though I officially proposed Opus only as an option to > vote on). > > I suggest anyone considering suggesting G.711 to examine the slides > from Tim's presentation, and if possible watch that section of the > video or listen to the audio (which I assume are online). It wasn't > an accident that the vote in-room (and there were a LOT of people) was > basically "Opus only: ~5 votes; G.711 only: 0 or 1 votes; rest of the > room: Opus and G.711" > In light of the fact that the proposal is actually rtc*web*, I'm surprised that this discussion has gone on for so long. It's a standard for the web first, and specifically for realtime communication on the web. Interop is important, but it shouldn't be a factor that has such a strong bearing on it that it blocks adoption of a superior standard for one that is less so. I appreciate the sentiment of Opus only as MTI, and the only reason I would give any bearing to G.711 is for including a bear-minimum degree of interop with already existing standards that are *not* web-specific. Again, I reiterate, I fully support Opus as MTI for openness, performance, efficiency, and latency reasons and G.711 as MTI for legacy interop reasons. And I also plainly state that amorphous IPR issues with Opus should be made concrete before they be taken seriously, since the same claims have held-up the wider adoption of other free codecs in a similar vein for years (e.g., Vorbis and Theora, to cite examples) and *nothing* materialized for them despite very juicy targets implementing them. "It hasn't been enough time" should not hold up the standardization process. There will never be enough time for the conditions that have been brought-up again-and-again. If I can go so far as to say that even the Web itself has faced IPR issues, what with the alleged patents on hyperlinking, methods of clicking on a button, and so on. If we waited for the patent landscape on such issues to clear before settling on a standard, there'd *be* no web so to speak. Opus has IPR in it already that has been licensed in an RF manner. This alone is a strong protection, and it's been made widely aware to all interested parties, so factors such as estoppal and what not are in effect that will mitigate any claims at this time. But, and I reiterate, to say it needs to be *clear* of IPR concerns is an impossble condition. I know these are not issues that Randell brought up, but I think this discussion is no longer productive, and the consensus is clear, both to people that attended in Vancouver and those outside. The issues that have been raised are simply not serious and are merely stalling tactics at this point holding-up the rtcweb process. Need I be more explicit than that, considering a former player has already proposed a competing standard to rtcweb about the real factors in play here? From giles@thaumas.net Wed Aug 29 10:20:53 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECD7621F861C for ; Wed, 29 Aug 2012 10:20:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4AaJMfm6s8S3 for ; Wed, 29 Aug 2012 10:20:53 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 63FCC21F8615 for ; Wed, 29 Aug 2012 10:20:53 -0700 (PDT) Received: by ieak13 with SMTP id k13so358650iea.31 for ; Wed, 29 Aug 2012 10:20:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=o1YbwzEQUKw4E37tUqn1rzI6AI9b5rB4810GE2hfqo8=; b=cqwCzEmLFjAbDDtLbnYEIpJz+Tt85/o7viYmZ77SvY1XRcv+PDEVlNvmwOZkYLA9qT RnNKJnuOfYU3Sue9rg2v+v2GENWblk1fGxUX5B1V46d5f52ttQ3aUqUJ1ecKaWZGLaF5 XuJAYVJLVc2cFTeJfcJOSIgRGJbKmQQLfM41qcbjV4ru3rBVheDHJ1Gxb0/cG5bBhQ7o +wrMH7mvw3uoTBHYus7gRm+0oKP/EyK+SIjqeCli0w3IBUkciW8bH0euLG4EwpEeQVyE XYLvYWvYkSACNVqDkLz7DQp54mRpIlEFVYgMpHQSJnQd+A/jjzChYZb06NypGZUsQ1OK zXJA== Received: by 10.50.10.201 with SMTP id k9mr2611463igb.28.1346260852683; Wed, 29 Aug 2012 10:20:52 -0700 (PDT) Received: from snow.thaumas.net ([207.6.217.65]) by mx.google.com with ESMTPS id ch4sm7681086igb.2.2012.08.29.10.20.51 (version=SSLv3 cipher=OTHER); Wed, 29 Aug 2012 10:20:51 -0700 (PDT) Message-ID: <503E4F72.7070104@thaumas.net> Date: Wed, 29 Aug 2012 10:20:50 -0700 From: Ralph Giles User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Randall Gellens References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQl1iihUeM4uw3j4keIZY1ckAXQgjcR/aGOJRnhDQjqxEhxS5AnnAUl5ATcmOKppXJpHjbmz Cc: rtcweb@ietf.org Subject: Re: [rtcweb] RTCWEB needs an Internet Codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 29 Aug 2012 17:20:54 -0000 On 29/08/12 09:29 AM, Randall Gellens wrote: > We only need one mandatory audio codec. Everything else can be left up > to implementations and experience. I am in favour of both G.711 and Opus as MTI codecs. We need Opus to support all the use cases this working group chose to address and to offer a technically compelling standard. In addition, I want G.711 for testing reasons. As an uncompressed format it simplifies debugging interoperability issues and bootstrap implementations, because you can just look at the data. This is especially so for developers not familiar with the details of particular codecs. Having *two* manditory to implement codecs ensures that codec selection is properly tested in even minimal implementations. I think that's a good thing. -r From christer.holmberg@ericsson.com Wed Aug 29 11:54:04 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BB0921F86DB for ; Wed, 29 Aug 2012 11:54:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.158 X-Spam-Level: X-Spam-Status: No, score=-6.158 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IobT1oiIMLEH for ; Wed, 29 Aug 2012 11:54:03 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 7984321F86DA for ; Wed, 29 Aug 2012 11:54:03 -0700 (PDT) X-AuditID: c1b4fb25-b7f046d00000644c-48-503e6549214f Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 4A.21.25676.9456E305; Wed, 29 Aug 2012 20:54:01 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.99]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Wed, 29 Aug 2012 20:54:01 +0200 From: Christer Holmberg To: "public-webrtc@w3.org" , "rtcweb@ietf.org" Date: Wed, 29 Aug 2012 20:50:05 +0200 Thread-Topic: H.264 SVC and BUNDLE Thread-Index: AQHNhhenMhkLi/vCmkGQ1yfqZgaa8g== Message-ID: <7F2072F1E0DE894DA4B517B93C6A05853409FF2F4C@ESESSCMS0356.eemea.ericsson.se> References: <503E0B63.3020708@ericsson.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrFLMWRmVeSWpSXmKPExsUyM+Jvra5nql2AwY9GU4vej0sYLdb+a2d3 YPJYsuQnk8fReftZA5iiuGxSUnMyy1KL9O0SuDJerbrEUrCJuWLugr+MDYyXmboYOTkkBEwk Lhy9xQphi0lcuLeeDcQWEjjFKHGhV6uLkQvIXsAo8Wz1WZYuRg4ONgELie5/2iCmiECExNlJ aiDlLAKqEku7ephBbGEBWYn/Ew8wgtgiAkoSV5ZfZYew9SQ2bm4HG88rEC6xZtlNVohVxRJL J50Bi3MKhEjse3kHrJ4R6Jzvp9aAncksIC5x68l8qJMFJJbsOc8MYYtKvHz8jxWiXlTiTvt6 Roh6PYkbU6ewQdjaEssWvmaG2CsocXLmE5YJjKKzkIydhaRlFpKWWUhaFjCyrGIUzk3MzEkv N9JLLcpMLi7Oz9MrTt3ECIyPg1t+q+5gvHNO5BCjNAeLkjiv9dY9/kIC6YklqdmpqQWpRfFF pTmpxYcYmTg4pRoYlctnKHFwh4v2WdU+kc4sDr8juKlMWaw5bo375Wu/Zh/dz2JYNSVKRskr 4UaPThCL+u4NAcE6gc/FLpbf+ex31XR/5SbGE1emsenFR1dJs/ucsNPRuZnSLuhm3Pgi71Rx r/Kt3hq9hYL8waxlSfP/rvr+ofHt2u9ev15wTF7kutVGOGjvSQslluKMREMt5qLiRABzlRhX XQIAAA== Subject: [rtcweb] H.264 SVC and BUNDLE X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 29 Aug 2012 18:54:04 -0000 Hi, At the telco yesterday one of the Microsoft guys claimed that H.264 SVC doe= s not work with BUNDLE, but he didn't have the details. Could someone please explain the reason why he/she doesn't think H.264 SVC = work with BUNDLE? (Note, that if using the same port for the different codec layers is a prob= lem, then it's not a BUNDLE problem - it's a generic multiplexing problem.) Thanks! Regards, Christer= From richard@shockey.us Wed Aug 29 15:16:36 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71E3411E80EA for ; Wed, 29 Aug 2012 15:16:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.635 X-Spam-Level: X-Spam-Status: No, score=-100.635 tagged_above=-999 required=5 tests=[AWL=-0.140, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13oBINoxxvQX for ; Wed, 29 Aug 2012 15:16:32 -0700 (PDT) Received: from oproxy6-pub.bluehost.com (oproxy6.bluehost.com [IPv6:2605:dc00:100:2::a6]) by ietfa.amsl.com (Postfix) with SMTP id AA80511E809C for ; Wed, 29 Aug 2012 15:16:32 -0700 (PDT) Received: (qmail 12806 invoked by uid 0); 29 Aug 2012 22:16:32 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by cpoproxy3.bluehost.com with SMTP; 29 Aug 2012 22:16:32 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:To:From; bh=bAH+/M1QeDRAMPGPtVDpFR8K3ntM/+T3X5w8qmUZ6PA=; b=gmzxn7++/MXRcyvrOdlxXevMI7FVv0V7xjYcIbIBAkOQJ0llt8EpWIJ8VQhGvq//HPAXKxkFRKEfWKwqrzrtOD5DZFmFmVL/cTy6m+lGRTD2wK08sUQBRXldBAywF7Ml; Received: from [71.191.243.130] (port=63674 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1T6qYp-0002hQ-5R; Wed, 29 Aug 2012 16:16:31 -0600 From: "Richard Shockey" To: "'Harald Alvestrand'" , References: <9E2843EA-EBB9-40B3-898C-6B5216FAE7A5@cisco.com> <503DED41.7080906@alvestrand.no> In-Reply-To: <503DED41.7080906@alvestrand.no> Date: Wed, 29 Aug 2012 18:16:27 -0400 Message-ID: <014401cd8633$efd76fe0$cf864fa0$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac2F0DTZOl5flESQQ8mmAu5kY/5sNwAY2X4Q Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 71.191.243.130 authed with richard@shockey.us} Subject: Re: [rtcweb] Confirmation of consensus on audio codecs X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 29 Aug 2012 22:16:36 -0000 Fine works for me but please 722 WB for SHOULD. Of course none of this will be of any significance if you can't agree on a reasonable offer/answer model that interoperates with public SIP networks ( previously called the PSTN ) -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Harald Alvestrand Sent: Wednesday, August 29, 2012 6:22 AM To: rtcweb@ietf.org Subject: Re: [rtcweb] Confirmation of consensus on audio codecs Since the number of people stating their opinion has been large, I'll just reiterate the opinion I had (and hummed for) in Vancouver: Opus and G.711 should be mandatory to implement for RTCWEB. Since the question of whether there's any value to making the decision now has been raised: The first interoperable products implementing RTCWEB are shipping within a very short timeframe. Those first implementations will shape the market for what's actually used in practice. In order to allow applications requiring high quality sound to be among the first ones developed, those first products need to include a common choice of a high quality codec. Having the RTCWEB WG state as a decision that this codec should be Opus helps in making sure these products ship with Opus. The time to decide is now. Harald [Note - the same logic applies to video codecs, but I've accepted that it's impossible to make a consensus decision at this time on that issue. We'll just live with the consequences of that.] On 08/16/2012 07:15 PM, Cullen Jennings (fluffy) wrote: > At the last meeting we took a hum on selecting Opus and G.711 as the mediatory to implement audio codecs. If there is any new opinions please send them to the list by August 30th, after which the chairs will make a determination of consensus. > > Thanks, > Cullen > > Please note that the following IPR disclosure have been made on these > codecs. They can be found at > > http://datatracker.ietf.org/ipr/ > > > 2010-11-07 > . ID # 1445 > "Broadcom Corporation's Statement about IPR related to draft-ietf-codec-opus-00 and draft-ietf-codec-description-00 (1)" > 2010-11-07 > . ID # 1446 > "Xiph.Org Foundation's Statement about IPR related to draft-ietf-codec-opus-00" > 2010-11-12 > . ID # 1447 > "Broadcom Corporation's Statement about IPR related to draft-ietf-codec-opus-00 and draft-ietf-codec-description-00 (2)" > 2011-03-23 > . ID # 1520 > "Qualcomm Incorporated's Statement about IPR related to draft-ietf-codec-opus-05" > 2011-03-27 > . ID # 1524 > "Xiph.Org Foundation's Statement about IPR related to draft-ietf-codec-opus-05" > 2011-03-29 > . ID # 1526 > "Broadcom Corporation's Statement about IPR related to draft-ietf-codec-opus-05" > 2011-03-29 > . ID # 1525 > "Skype Limited's Statement about IPR related to draft-ietf-codec-opus-05" > 2011-07-23 > . ID # 1602 > "Skype Limited's Statement about IPR related to draft-ietf-codec-opus-07" > 2012-01-25 > . ID # 1670 > "Microsoft Corporation's Statement about IPR related to draft-ietf-codec-opus-10" > 2012-03-12 > . ID # 1712 > "Huawei Technologies Co.,Ltd's Statement about IPR related to draft-ietf-codec-opus-11 (1)" > 2012-04-02 > . ID # 1741 > "Huawei Technologies Co.,Ltd's Statement about IPR related to draft-ietf-codec-opus-11 (2)" > > > > _______________________________________________ > 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 From dwing@cisco.com Wed Aug 29 15:32:55 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABFE521F844E for ; Wed, 29 Aug 2012 15:32:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.499 X-Spam-Level: X-Spam-Status: No, score=-110.499 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3r5k4fQnet0C for ; Wed, 29 Aug 2012 15:32:55 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 0400321F844D for ; Wed, 29 Aug 2012 15:32:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=1485; q=dns/txt; s=iport; t=1346279574; x=1347489174; h=from:to:references:in-reply-to:subject:date:message-id: mime-version:content-transfer-encoding; bh=93thDVW9PpsVg+1h79oIgDp2QIiSLzxvtp0DgY9US9g=; b=AZYwy86ik7AcQu1LtxiAaO0wWeGGLxJGg5EKSH3PTEQRAHswEHeYrJJ7 hv1OFcHB7VWlSgVomvIvjTlwqvepPi7KSaB2a59diBDF+/PScWOvgfVji 6EJBelK+nYw/c/X0CWZXYkrq2uT5drc3aRxBmAlmfIZbIHgF5GmL9qKv1 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FALqXPlCrRDoJ/2dsb2JhbABFqwaPbIEHgiABAQEDAQEBAQUKARcQNBAHAQMCCQ8CBAEBKAcZDhUKCQgCBAESCxeHZQUMm1mgPQSLCIZZA4hPhQ2WKIFngwM X-IronPort-AV: E=Sophos;i="4.80,335,1344211200"; d="scan'208";a="53513948" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-1.cisco.com with ESMTP; 29 Aug 2012 22:32:54 +0000 Received: from dwingWS ([10.154.161.179]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q7TMWs5A012629; Wed, 29 Aug 2012 22:32:54 GMT From: "Dan Wing" To: "'Christer Holmberg'" , , References: <503E0B63.3020708@ericsson.com>, <7F2072F1E0DE894DA4B517B93C6A05853409FF2F4C@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05853409FF2F4C@ESESSCMS0356.eemea.ericsson.se> Date: Wed, 29 Aug 2012 15:32:54 -0700 Message-ID: <035101cd8636$3b654160$b22fc420$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHNhhenMhkLi/vCmkGQ1yfqZgaa8pdxXxaw Content-Language: en-us Subject: Re: [rtcweb] H.264 SVC and BUNDLE X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 29 Aug 2012 22:32:55 -0000 > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > Behalf Of Christer Holmberg > Sent: Wednesday, August 29, 2012 11:50 AM > To: public-webrtc@w3.org; rtcweb@ietf.org > Subject: [rtcweb] H.264 SVC and BUNDLE > > Hi, > > At the telco yesterday one of the Microsoft guys claimed that H.264 SVC > does not work with BUNDLE, but he didn't have the details. > > Could someone please explain the reason why he/she doesn't think H.264 > SVC work with BUNDLE? > > (Note, that if using the same port for the different codec layers is a > problem, then it's not a BUNDLE problem - it's a generic multiplexing > problem.) The general multiplexing of layers onto the same 5-tuple is a problem, *if* we want the layers to have different DSCP values. This is because we cannot successfully and reliably set different DSCP values for packets belonging to a 5-tuple over the Internet -- too many things rewrite the DSCP field (to a different value) or simply clear the DSCP field. This makes it impossible to restore the per-packet DSCP values later (e.g., using RSVP, or using any other better/stronger/faster signaling method). If, however, each 5-tuple has its own DSCP value then that DSCP value could be restored. -d > Thanks! > > Regards, > > Christer > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From randy@qualcomm.com Wed Aug 29 17:44:53 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2A6121E803A for ; Wed, 29 Aug 2012 17:44:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.552 X-Spam-Level: X-Spam-Status: No, score=-106.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bkX6jnVmaqOZ for ; Wed, 29 Aug 2012 17:44:52 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id E605E11E8102 for ; Wed, 29 Aug 2012 17:44:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=@qualcomm.com; q=dns/txt; s=qcdkim; t=1346287493; x=1377823493; h=message-id:in-reply-to:references:x-mailer:date:to:from: subject:mime-version:content-type:x-random-sig-tag: x-originating-ip; bh=TeSoPcv6N/Loc1LJ0P7nEK93QTpL2frNUfplUZkVuUU=; b=EzRJDN0+zQX7yE7NNF2A87HZuFwn6Wkvruci0THbRPl077fLM0GPoTk/ 9aaZ1gk+uXK4b/ndb+Hf7wnWuisxD7jhtD/o6ib8kJpzwOxGRF+mDd61a TRW1eASZWPNKNh7V/uDHA5A3mkT6z7VWfKlKs/opH9xjwn0vB9FoUZ/jO A=; X-IronPort-AV: E=McAfee;i="5400,1158,6819"; a="228650557" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by wolverine02.qualcomm.com with ESMTP; 29 Aug 2012 17:44:53 -0700 X-IronPort-AV: E=Sophos;i="4.80,336,1344236400"; d="scan'208";a="378352152" Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 29 Aug 2012 17:44:53 -0700 Received: from [99.111.97.136] (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.17) with Microsoft SMTP Server (TLS) id 14.2.318.1; Wed, 29 Aug 2012 17:44:51 -0700 Message-ID: In-Reply-To: <503E4602.9070509@librevideo.org> References: <9E2843EA-EBB9-40B3-898C-6B5216FAE7A5@cisco.com> <503E2BC2.1090705@acm.org> <503E3422.6010508@jesup.org> <503E4602.9070509@librevideo.org> X-Mailer: Eudora for Mac OS X Date: Wed, 29 Aug 2012 17:43:39 -0700 To: Basil Mohamed Gohar , From: Randall Gellens MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Random-Sig-Tag: 1.0b28 X-Originating-IP: [172.30.48.1] Subject: Re: [rtcweb] Confirmation of consensus on audio codecs X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 30 Aug 2012 00:44:53 -0000 At 12:40 PM -0400 8/29/12, Basil Mohamed Gohar wrote: > I know these are not issues that Randell brought up, but I think this > discussion is no longer productive, and the consensus is clear, both to > people that attended in Vancouver and those outside. The issues that > have been raised are simply not serious and are merely stalling tactics > at this point holding-up the rtcweb process. Need I be more explicit > than that, considering a former player has already proposed a competing > standard to rtcweb about the real factors in play here? I find the assertion that those who disagree with you are merely attempting to delay things to be false, unfair, and insulting. There have been several viewpoints expressed, all backed by solid technical grounds. Some of these views support Opus plus G.711, some support G.711 only, some support G.711 plus G.722, some support no MTI audio codec at this time. None of these would prevent rtcweb from advancing. Any of these views would allow implementations to support Opus as well as G.722, AMR and AMR-WB. The nice thing about using SDP to negotiate a codec is that it allows any codec to be used. The fact that a codec is not MTI doesn't mean it won't or shouldn't be supported (far from it). It's a normal part of the IETF process that different views are expressed, each with technical reasoning. Different participants are free to assign different weights to each reason, and this is also expected. What's not a normal part of the process is to accuse other participants of bad intent. That poisons the dialog and creates mistrust, especially of you. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- A long-forgotten loved one will appear soon. Buy the negatives at any price. From harald@alvestrand.no Wed Aug 29 22:49:38 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3605011E8106 for ; Wed, 29 Aug 2012 22:49:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.149 X-Spam-Level: X-Spam-Status: No, score=-110.149 tagged_above=-999 required=5 tests=[AWL=0.450, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ruWhuIEDldas for ; Wed, 29 Aug 2012 22:49:34 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id AAC5311E8105 for ; Wed, 29 Aug 2012 22:49:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8C01F39E207; Thu, 30 Aug 2012 07:49:01 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QMqXqeSTvars; Thu, 30 Aug 2012 07:48:57 +0200 (CEST) Received: from [192.168.11.107] (c-56fbe555.03-217-73746f1.cust.bredbandsbolaget.se [85.229.251.86]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 4919939E04C; Thu, 30 Aug 2012 07:48:57 +0200 (CEST) Message-ID: <503EFECA.1070407@alvestrand.no> Date: Thu, 30 Aug 2012 07:48:58 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: Richard Shockey References: <9E2843EA-EBB9-40B3-898C-6B5216FAE7A5@cisco.com> <503DED41.7080906@alvestrand.no> <014401cd8633$efd76fe0$cf864fa0$@us> In-Reply-To: <014401cd8633$efd76fe0$cf864fa0$@us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Confirmation of consensus on audio codecs X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 30 Aug 2012 05:49:38 -0000 On 08/30/2012 12:16 AM, Richard Shockey wrote: > Fine works for me but please 722 WB for SHOULD. Of course none of this will > be of any significance if you can't agree on a reasonable offer/answer model > that interoperates with public SIP networks ( previously called the PSTN ) We've already got people writing Javascript that interworks with Asterisk, so I don't think this is going to be a problem (unless someone decides to start over again). > > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of > Harald Alvestrand > Sent: Wednesday, August 29, 2012 6:22 AM > To: rtcweb@ietf.org > Subject: Re: [rtcweb] Confirmation of consensus on audio codecs > > Since the number of people stating their opinion has been large, I'll just > reiterate the opinion I had (and hummed for) in Vancouver: > > Opus and G.711 should be mandatory to implement for RTCWEB. > > Since the question of whether there's any value to making the decision now > has been raised: > > The first interoperable products implementing RTCWEB are shipping within a > very short timeframe. Those first implementations will shape the market for > what's actually used in practice. > In order to allow applications requiring high quality sound to be among the > first ones developed, those first products need to include a common choice > of a high quality codec. > > Having the RTCWEB WG state as a decision that this codec should be Opus > helps in making sure these products ship with Opus. > > The time to decide is now. > > Harald > > [Note - the same logic applies to video codecs, but I've accepted that it's > impossible to make a consensus decision at this time on that issue. > We'll just live with the consequences of that.] > > On 08/16/2012 07:15 PM, Cullen Jennings (fluffy) wrote: >> At the last meeting we took a hum on selecting Opus and G.711 as the > mediatory to implement audio codecs. If there is any new opinions please > send them to the list by August 30th, after which the chairs will make a > determination of consensus. >> Thanks, >> Cullen >> >> Please note that the following IPR disclosure have been made on these >> codecs. They can be found at >> >> http://datatracker.ietf.org/ipr/ >> >> >> 2010-11-07 >> . ID # 1445 >> "Broadcom Corporation's Statement about IPR related to > draft-ietf-codec-opus-00 and draft-ietf-codec-description-00 (1)" >> 2010-11-07 >> . ID # 1446 >> "Xiph.Org Foundation's Statement about IPR related to > draft-ietf-codec-opus-00" >> 2010-11-12 >> . ID # 1447 >> "Broadcom Corporation's Statement about IPR related to > draft-ietf-codec-opus-00 and draft-ietf-codec-description-00 (2)" >> 2011-03-23 >> . ID # 1520 >> "Qualcomm Incorporated's Statement about IPR related to > draft-ietf-codec-opus-05" >> 2011-03-27 >> . ID # 1524 >> "Xiph.Org Foundation's Statement about IPR related to > draft-ietf-codec-opus-05" >> 2011-03-29 >> . ID # 1526 >> "Broadcom Corporation's Statement about IPR related to > draft-ietf-codec-opus-05" >> 2011-03-29 >> . ID # 1525 >> "Skype Limited's Statement about IPR related to draft-ietf-codec-opus-05" >> 2011-07-23 >> . ID # 1602 >> "Skype Limited's Statement about IPR related to draft-ietf-codec-opus-07" >> 2012-01-25 >> . ID # 1670 >> "Microsoft Corporation's Statement about IPR related to > draft-ietf-codec-opus-10" >> 2012-03-12 >> . ID # 1712 >> "Huawei Technologies Co.,Ltd's Statement about IPR related to > draft-ietf-codec-opus-11 (1)" >> 2012-04-02 >> . ID # 1741 >> "Huawei Technologies Co.,Ltd's Statement about IPR related to > draft-ietf-codec-opus-11 (2)" >> >> >> _______________________________________________ >> 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 > From christer.holmberg@ericsson.com Thu Aug 30 00:51:48 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 531D021F859E for ; Thu, 30 Aug 2012 00:51:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.171 X-Spam-Level: X-Spam-Status: No, score=-6.171 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pJiFk4q23vb1 for ; Thu, 30 Aug 2012 00:51:47 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 3B78A21F858F for ; Thu, 30 Aug 2012 00:51:46 -0700 (PDT) X-AuditID: c1b4fb25-b7f046d00000644c-e7-503f1b910dad Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 50.63.25676.19B1F305; Thu, 30 Aug 2012 09:51:45 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.99]) by esessmw0247.eemea.ericsson.se ([153.88.115.93]) with mapi; Thu, 30 Aug 2012 09:51:45 +0200 From: Christer Holmberg To: Dan Wing , "public-webrtc@w3.org" , "rtcweb@ietf.org" Date: Thu, 30 Aug 2012 09:50:35 +0200 Thread-Topic: [rtcweb] H.264 SVC and BUNDLE Thread-Index: AQHNhhenMhkLi/vCmkGQ1yfqZgaa8pdxXxawgACdAhc= Message-ID: <7F2072F1E0DE894DA4B517B93C6A05853409FF2F5C@ESESSCMS0356.eemea.ericsson.se> References: <503E0B63.3020708@ericsson.com>, <7F2072F1E0DE894DA4B517B93C6A05853409FF2F4C@ESESSCMS0356.eemea.ericsson.se>, <035101cd8636$3b654160$b22fc420$@com> In-Reply-To: <035101cd8636$3b654160$b22fc420$@com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGLMWRmVeSWpSXmKPExsUyM+Jvre5EafsAg6MnFSwuXnvIZNH7cQmj xdp/7ewOzB5Tfm9k9Viy5CeTx9F5+1kDmKO4bFJSczLLUov07RK4Mq7MFSk4yFfxsGceawPj C+4uRk4OCQETiS09h5kgbDGJC/fWs3UxcnEICZxilDj28hozhLOAUWJT002WLkYODjYBC4nu f9ogDSICJRKNJyexg9gsAqoSq2Y/YQaxhQW0JC4d2sMKUaMtcff2c3YI20piw6WHYDW8AuES iw5NhVr2ilFi/dQJYAlOASOJP1s+MYLYjEAXfT+1Buw6ZgFxiVtP5kNdKiCxZM95ZghbVOLl 43+sEPWiEnfa1zNC1OtILNj9iQ3C1pZYtvA11GJBiZMzn7BMYBSdhWTsLCQts5C0zELSsoCR ZRWjcG5iZk56uZFealFmcnFxfp5eceomRmDcHNzyW3UH451zIocYpTlYlMR5rbfu8RcSSE8s Sc1OTS1ILYovKs1JLT7EyMTBKdXA2Nq/YqFWlKLdx9Ut8a6Br44n9PCG3T3ppWV1/9XZnTnV z/sYn5067Xxnp2ZM/SG+/mXp1u8zDvsImX1ofi3oYjJdtJ1VrfH5LV07IcHenOiHDQUaTXUH T4bZ7jlvXdLPa/XgOd+OXPM8x3233s09eS3F4GrJp00uDUXF0Q5ZN78cNtM04dVXYinOSDTU Yi4qTgQAti8mcWkCAAA= Subject: Re: [rtcweb] H.264 SVC and BUNDLE X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 30 Aug 2012 07:51:48 -0000 Hi Dan, Thanks for the information! The issue you raise is of course not related to BUNDLE, but to multiplexing= in general. Regards, Christer ________________________________________ From: Dan Wing [dwing@cisco.com] Sent: Thursday, August 30, 2012 1:32 AM To: Christer Holmberg; public-webrtc@w3.org; rtcweb@ietf.org Subject: RE: [rtcweb] H.264 SVC and BUNDLE > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > Behalf Of Christer Holmberg > Sent: Wednesday, August 29, 2012 11:50 AM > To: public-webrtc@w3.org; rtcweb@ietf.org > Subject: [rtcweb] H.264 SVC and BUNDLE > > Hi, > > At the telco yesterday one of the Microsoft guys claimed that H.264 SVC > does not work with BUNDLE, but he didn't have the details. > > Could someone please explain the reason why he/she doesn't think H.264 > SVC work with BUNDLE? > > (Note, that if using the same port for the different codec layers is a > problem, then it's not a BUNDLE problem - it's a generic multiplexing > problem.) The general multiplexing of layers onto the same 5-tuple is a problem, *if* we want the layers to have different DSCP values. This is because we cannot successfully and reliably set different DSCP values for packets belonging to a 5-tuple over the Internet -- too many things rewrite the DSCP field (to a different value) or simply clear the DSCP field. This makes it impossible to restore the per-packet DSCP values later (e.g., using RSVP, or using any other better/stronger/faster signaling method). If, however, each 5-tuple has its own DSCP value then that DSCP value could be restored. -d > Thanks! > > Regards, > > Christer > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From ron.even.tlv@gmail.com Thu Aug 30 01:56:32 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C23A21F8528 for ; Thu, 30 Aug 2012 01:56:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PxOgdyVrwaVd for ; Thu, 30 Aug 2012 01:56:32 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id A410B21F852B for ; Thu, 30 Aug 2012 01:56:31 -0700 (PDT) Received: by bkty12 with SMTP id y12so685559bkt.31 for ; Thu, 30 Aug 2012 01:56:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language; bh=ej6tG9FvJf2prhhhm7ZqYVknPex+jSPMJ+Vp10KEvbQ=; b=jpZ+StA2/psn5ad218X+egIQedHAxlm4O9qWF4dLhjG/cLYZOgtJujXX8zE8JTY57a jgcQ53rSJIM+eKNxUpBFXcAyXUuzhkOnVpu8avMen5fky9zcAP4iUt7wYwUvQTgNxmXS +vuEjs1OLexJKozQimi+d78k3cjBEMhSMGXtTVKS0QAWSpojV51be8vpVzAAKLmeMHuW 3rtY2fRRg5IcYA0eKQDxq/FAQ6tpJyFSFjNchbQxdyqg4ivx7C6ANDR2Bx4K9f7zeyzD kG8lvL4f2jx6RehWEM3q5c5U/jDFD8bfuHOVjxD/Zn7OvC2UyBI33G3Z4ct1jOn2RZcJ kq3Q== Received: by 10.204.129.16 with SMTP id m16mr2345601bks.136.1346316990549; Thu, 30 Aug 2012 01:56:30 -0700 (PDT) Received: from RoniE (bzq-79-181-188-119.red.bezeqint.net. [79.181.188.119]) by mx.google.com with ESMTPS id 25sm575270bkx.9.2012.08.30.01.56.26 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 30 Aug 2012 01:56:29 -0700 (PDT) From: "Roni Even" To: "'Christer Holmberg'" , "'Dan Wing'" , , References: <503E0B63.3020708@ericsson.com>, <7F2072F1E0DE894DA4B517B93C6A05853409FF2F4C@ESESSCMS0356.eemea.ericsson.se>, <035101cd8636$3b654160$b22fc420$@com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2F5C@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05853409FF2F5C@ESESSCMS0356.eemea.ericsson.se> Date: Thu, 30 Aug 2012 11:55:02 +0200 Message-ID: <01ec01cd8695$8d9e18d0$a8da4a70$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIzoVsTffJikefIEe0h9tDJmRrw2QFxiOsLAm1vqdkBzS0U/QJ+6QqqlmSO4hA= Content-Language: en-us Subject: Re: [rtcweb] H.264 SVC and BUNDLE X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 30 Aug 2012 08:56:32 -0000 Christer, This is about the multiple session support in MST, look at the example in section 7.3.3 of RFC6190, using the DDP grouping attribute from RFC5583. I assume that you can solve it using RFC5576 ssrc-group but you will need to define the DDP to be used also for ssrc-group Roni -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Christer Holmberg Sent: 30 August, 2012 9:51 AM To: Dan Wing; public-webrtc@w3.org; rtcweb@ietf.org Subject: Re: [rtcweb] H.264 SVC and BUNDLE Hi Dan, Thanks for the information! The issue you raise is of course not related to BUNDLE, but to multiplexing in general. Regards, Christer ________________________________________ From: Dan Wing [dwing@cisco.com] Sent: Thursday, August 30, 2012 1:32 AM To: Christer Holmberg; public-webrtc@w3.org; rtcweb@ietf.org Subject: RE: [rtcweb] H.264 SVC and BUNDLE > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > Behalf Of Christer Holmberg > Sent: Wednesday, August 29, 2012 11:50 AM > To: public-webrtc@w3.org; rtcweb@ietf.org > Subject: [rtcweb] H.264 SVC and BUNDLE > > Hi, > > At the telco yesterday one of the Microsoft guys claimed that H.264 > SVC does not work with BUNDLE, but he didn't have the details. > > Could someone please explain the reason why he/she doesn't think H.264 > SVC work with BUNDLE? > > (Note, that if using the same port for the different codec layers is a > problem, then it's not a BUNDLE problem - it's a generic multiplexing > problem.) The general multiplexing of layers onto the same 5-tuple is a problem, *if* we want the layers to have different DSCP values. This is because we cannot successfully and reliably set different DSCP values for packets belonging to a 5-tuple over the Internet -- too many things rewrite the DSCP field (to a different value) or simply clear the DSCP field. This makes it impossible to restore the per-packet DSCP values later (e.g., using RSVP, or using any other better/stronger/faster signaling method). If, however, each 5-tuple has its own DSCP value then that DSCP value could be restored. -d > Thanks! > > 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 From harald@alvestrand.no Thu Aug 30 03:56:10 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F9EC21F8551 for ; Thu, 30 Aug 2012 03:56:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.353 X-Spam-Level: X-Spam-Status: No, score=-110.353 tagged_above=-999 required=5 tests=[AWL=0.246, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FziG1+5Wdxj1 for ; Thu, 30 Aug 2012 03:56:09 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 57CEB21F853D for ; Thu, 30 Aug 2012 03:56:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A011A39E170 for ; Thu, 30 Aug 2012 12:56:06 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kg-7LUUA15w3 for ; Thu, 30 Aug 2012 12:56:06 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:be30:5bff:fede:bcdc]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id E401139E15B for ; Thu, 30 Aug 2012 12:56:05 +0200 (CEST) Message-ID: <503F46C5.2090607@alvestrand.no> Date: Thu, 30 Aug 2012 12:56:05 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] RTCWEB needs an Internet Codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 30 Aug 2012 10:56:10 -0000 The counterpoint is that having G.711 as the only MTI means that you get interoperability failure for any application in which G.711 sound quality is not acceptable. This includes all applications involving music. On 08/29/2012 06:30 PM, Randall Gellens wrote: > At 12:13 AM -0400 8/29/12, Roman Shpount wrote: > >> I would argue G.711 should be the MTI codec. The rest can be left up >> to browser implementers. > > I agree. > >> We can argue all we want, but the best royalty free low bitrate >> codec available will be the one everybody supports. > > Very good point, and why we should mandate only one audio codec. > From stefan.lk.hakansson@ericsson.com Thu Aug 30 04:58:18 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0DD521F859C for ; Thu, 30 Aug 2012 04:58:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.076 X-Spam-Level: X-Spam-Status: No, score=-6.076 tagged_above=-999 required=5 tests=[AWL=0.173, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CkTpCEBCKOCK for ; Thu, 30 Aug 2012 04:58:17 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id C797021F859E for ; Thu, 30 Aug 2012 04:58:16 -0700 (PDT) X-AuditID: c1b4fb25-b7f046d00000644c-f6-503f55566166 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 84.60.25676.6555F305; Thu, 30 Aug 2012 13:58:14 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.264.1; Thu, 30 Aug 2012 13:58:13 +0200 Message-ID: <503F5555.5040303@ericsson.com> Date: Thu, 30 Aug 2012 13:58:13 +0200 From: Stefan Hakansson LK User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: Jean-Marc Valin References: <9E2843EA-EBB9-40B3-898C-6B5216FAE7A5@cisco.com> <503CBB52.8070300@ericsson.com> <503CF224.5050609@mozilla.com> <503DE60D.2060706@ericsson.com> <503E14E1.6000401@mozilla.com> In-Reply-To: <503E14E1.6000401@mozilla.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuplluLIzCtJLcpLzFFi42KZGfG3Vjcs1D7A4Px8TYv/Uzks1v5rZ3dg 8liy5CeTR9+BLtYApigum5TUnMyy1CJ9uwSujFcPrzAX3FOumLnoKksD4yTZLkZODgkBE4mp rV9ZIWwxiQv31rOB2EICpxglHvTkQ9jLGSXaLwuC2LwC2hJ3Jl1hB7FZBFQldh1ZzAJiswnY SKztnsIEYosKhEis+TaFEaJeUOLkzCdgNSICmhJ3fqwC62UWUJe4s/gcmC0sYC+x8cR/oHou oF27GCWmbG8CG8QJtOzQqWlACQ6gBnuJB1vLIHrlJba/ncMMcZuuxLvX91gnMArOQrJuFkLH LCQdCxiZVzEK5yZm5qSXG+mlFmUmFxfn5+kVp25iBAbpwS2/VXcw3jkncohRmoNFSZzXeuse fyGB9MSS1OzU1ILUovii0pzU4kOMTBycUg2MgvOTfjycmL4sZxHL2sknnHNFfKQCBRnll3/q z545m+PYfZFEzStiWbsbo+0M7tfcW/vb4Hnx04KjpVbrY603vbtVYnxvxezoM6dDzzgv2ct0 b2bLtn2Ve4LMrz89b/rMdLLljTi76pLM9eX3C0plwjJenM049OG+XU1eva3COS9G78cOZ8yT lViKMxINtZiLihMBBqH64CACAAA= Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Confirmation of consensus on audio codecs X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 30 Aug 2012 11:58:18 -0000 On 08/29/2012 03:10 PM, Jean-Marc Valin wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 08/29/2012 05:51 AM, Stefan Hakansson LK wrote: ... > >> That is great, but sort of underlines that there would be no harm >> in delaying the decision until there are experiences made from real >> world use - 'cause it would not be that long till that experience >> has been made (Markus also brought up the IPR status as a reason >> for waiting - I have no idea how long it would take to know more >> about that). > > As Harald is pointing out, rtcweb implementations are going to ship > pretty soon. If that is the case (and I think and hope so), why would we need to make it MTI before seeing it in action? [...] > Are you expecting *another* single, standardized, > royalty-free codec that operates over vast ranges of bitrates and > operating conditions, from narrowband speech to stereo music, all with > low delay, coming out in the next year? If not, what are you really > waiting for? No, I'm not expecting that. I would just prefer us to see that Opus does indeed deliver as promised before making it MTI. If it does, fine. If not, we'd have to discuss what to do then. To me it is like if you're going to place a bet, for an upcoming big race, on a horse that has never been in an actual race, but shows great promise. If you know that the horse is going to participate in a few practice races soon, would you not prefer to wait and see how it fares in those before placing the bet (given that the odds would not change)? Anyway, that's my view. Let's see what the chairs say. > >> As Paul suggested, I was referring to the lack of formal, >> controlled, characterization tests. That is how other SDOs do it. I >> don't think that is the only way to do it, but I think we should at >> least have either such tests conducted or experience from >> deployment and use (in a wide range of conditions and device types) >> before making it MTI. > > Opus has had "ITU-style" testing on English ( > http://www.opus-codec.org/comparison/GoogleTest1.pdf ) and Mandarin ( > http://www.opus-codec.org/comparison/GoogleTest2.pdf ). And if you > don't trust Google on the tests I linked to, it's also been tested by > Nokia: > http://research.nokia.com/files/public/%5B16%5D_InterSpeech2011_Voice_Quality_Characterization_of_IETF_Opus_Codec.pdf Come on, those tests are very limited compared to a formal characterization test. (Example: www.itu.int/dms_pub/itu-t/opb/tut/T-TUT-ASC-2010-MSW-E.docx). There is very little info on the material used, the environment, processing and scripts and so on. And there seems to be no tests whatsoever (at least not involving humans) with actual channels introducing jitter and losses. Note: I am in no way proposing that a formal characterization test is needed, or even the right thing to do. It is a costly and time consuming process, and alternative approaches could prove to be more efficient. What I am saying is that I think we should not mandate a codec that has neither gone through that kind of formal characterization testing nor has any field experience from actual use on a reasonable scale (covering different conditions and device types). It just seems wrong, especially given that we will soon have field experience. > > Now, unlike other SDOs, the testing did not stop there. ITU-T codecs > generally end up being testing with something in the order of tens of > minutes worth of audio. In *addition* to that kind of testing, Opus > also had automated testing with hundreds of years worth of audio. If > anything, I think other SDOs should learn something here. This may very well be true. I guess this comes down to how much you trust that the quality assessment models (e.g. PEAQ, POLQA) give the same result as human test subjects would. But I think this sounds like a really good thing. > > Jean-Marc > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.12 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iQEcBAEBAgAGBQJQPhThAAoJEJ6/8sItn9q9nAcH/0BsXl/FBgMhbYWVALpNmIYi > Yj1ezyW8JVSv4io1YIozucl6KiDVi3LwYFteYgl78PlQ7o2muv/lJP9VswRHooH5 > Gax+aJUZkz7SlKxn+25wUlLgKQw6GAcUID5sJ0ewWdGOrwZu+SlZgYF3egYmmwyL > pEl8BFj7wu3uakRm/BE9LsUDPFdCoZS6uXqXRJOy9P1dZ25edvgaymQvOwhEcXu9 > xMq82YPNU2CZpfb88ew/l+U9FjW8c4iGkZYiu+VzmBL8wYOFP5pBhBhWc/bEb0WX > 8IUC5PJ0MMp49kb7/kfQj65/Py7u6ytYaO4PA0rjMHJ2V1PzH4EuqtNweYXVzNI= > =nwlD > -----END PGP SIGNATURE----- > From keith.drage@alcatel-lucent.com Thu Aug 30 05:38:25 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB14521F8514 for ; Thu, 30 Aug 2012 05:38:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.791 X-Spam-Level: X-Spam-Status: No, score=-109.791 tagged_above=-999 required=5 tests=[AWL=0.458, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IcLqe1w+Vx8z for ; Thu, 30 Aug 2012 05:38:24 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by ietfa.amsl.com (Postfix) with ESMTP id EBAAE21F84F5 for ; Thu, 30 Aug 2012 05:38:22 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q7UCbtlc024770 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 30 Aug 2012 14:38:19 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.44]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Thu, 30 Aug 2012 14:38:10 +0200 From: "DRAGE, Keith (Keith)" To: Harald Alvestrand , "rtcweb@ietf.org" Date: Thu, 30 Aug 2012 14:38:09 +0200 Thread-Topic: [rtcweb] RTCWEB needs an Internet Codec Thread-Index: Ac2Gnhdit1wVn4oLSem1d8AH/KcrCAADe1Rw Message-ID: References: <503F46C5.2090607@alvestrand.no> In-Reply-To: <503F46C5.2090607@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.13 Subject: Re: [rtcweb] RTCWEB needs an Internet Codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 30 Aug 2012 12:38:25 -0000 Surely that argument extends to every possible codec. If the codecs supported by both endpoints do not supply the characteristics= needed for the communication, then you will get interoperability failure. If I want more bandwidth or quality than OPUS supplies, then I will also ge= t interoperability failure. Keith > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf > Of Harald Alvestrand > Sent: 30 August 2012 11:56 > To: rtcweb@ietf.org > Subject: Re: [rtcweb] RTCWEB needs an Internet Codec >=20 > The counterpoint is that having G.711 as the only MTI means that you get > interoperability failure for any application in which G.711 sound > quality is not acceptable. >=20 > This includes all applications involving music. >=20 > On 08/29/2012 06:30 PM, Randall Gellens wrote: > > At 12:13 AM -0400 8/29/12, Roman Shpount wrote: > > > >> I would argue G.711 should be the MTI codec. The rest can be left up > >> to browser implementers. > > > > I agree. > > > >> We can argue all we want, but the best royalty free low bitrate > >> codec available will be the one everybody supports. > > > > Very good point, and why we should mandate only one audio codec. > > >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From neils@vipadia.com Thu Aug 30 05:46:24 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6842621F85F7 for ; Thu, 30 Aug 2012 05:46:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id obOIyzVr8dRf for ; Thu, 30 Aug 2012 05:46:24 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9886B21F8565 for ; Thu, 30 Aug 2012 05:46:23 -0700 (PDT) Received: by lbky2 with SMTP id y2so573749lbk.31 for ; Thu, 30 Aug 2012 05:46:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=HiGxiK9JRvwzBeCrrGbp2jtzcjT5GUOFGVOicCRc57w=; b=fLr3FlPhWnqxtJY82BU5uPwMK+AobHUbhNMfHtAbykjSMEyGus/98J0SAdzkJXQFqb 57YynmcgEBF5CoyPD5AfLaeVaQJe2pq92mhjH7uCqW8eXQ2b5PFFUiveWEzbodqxA8PA U6HBlvlm/fKEbi7ah9loAa00puIN7c41M3l3D4MkN+PL8cIoRFZOBhgpHVUDxw4UI887 g1aCmGOhDcgoPdZr8O3nAZPD7ZpAMECY7muYCNmBKt9vDqKwbBEskClyWuqwO/gBekjU LN1yb6ocMKMEiNKAV70Vrevkw12eiv34Cjl8FtFryOqU58E+Q0yQKyfi903SXC97sXty skug== MIME-Version: 1.0 Received: by 10.112.51.201 with SMTP id m9mr1284284lbo.2.1346330782082; Thu, 30 Aug 2012 05:46:22 -0700 (PDT) Sender: neils@vipadia.com Received: by 10.114.0.79 with HTTP; Thu, 30 Aug 2012 05:46:21 -0700 (PDT) In-Reply-To: <9E2843EA-EBB9-40B3-898C-6B5216FAE7A5@cisco.com> References: <9E2843EA-EBB9-40B3-898C-6B5216FAE7A5@cisco.com> Date: Thu, 30 Aug 2012 13:46:21 +0100 X-Google-Sender-Auth: OFqbGkLi6JWWKTUP1H4TBKBPOtc Message-ID: From: Neil Stratford To: "Cullen Jennings (fluffy)" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnh9zoxmyce+X3ltkJr2qNWczAz09h/A6ITyXHoUsgovY5yNJf+2j9H1M2IqO0UrscoQi00 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Confirmation of consensus on audio codecs X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 30 Aug 2012 12:46:24 -0000 On Thu, Aug 16, 2012 at 6:15 PM, Cullen Jennings (fluffy) wrote: > At the last meeting we took a hum on selecting Opus and G.711 as the mediatory to implement audio codecs. If there is any new opinions please send them to the list by August 30th, after which the chairs will make a determination of consensus. I support both G.711 and Opus as mandatory to implement. G.711 alone does not meet the rtcweb goal of producing a viable alternative to browser plugins as it will be impossible for an application developer to guarantee an acceptable audio quality (defined as at least as good as when using plugins) for browser to browser calls. Neil From harald@alvestrand.no Thu Aug 30 05:51:28 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE40F21F8617 for ; Thu, 30 Aug 2012 05:51:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.362 X-Spam-Level: X-Spam-Status: No, score=-110.362 tagged_above=-999 required=5 tests=[AWL=0.237, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dRGxKxkhjShr for ; Thu, 30 Aug 2012 05:51:28 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 09DFF21F8607 for ; Thu, 30 Aug 2012 05:51:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 18F2739E2B4; Thu, 30 Aug 2012 14:51:26 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PvXSTiwQd4Sb; Thu, 30 Aug 2012 14:51:25 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:be30:5bff:fede:bcdc]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id DA22739E170; Thu, 30 Aug 2012 14:51:24 +0200 (CEST) Message-ID: <503F61CC.1010709@alvestrand.no> Date: Thu, 30 Aug 2012 14:51:24 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: "DRAGE, Keith (Keith)" References: <503F46C5.2090607@alvestrand.no> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] RTCWEB needs an Internet Codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 30 Aug 2012 12:51:28 -0000 On 08/30/2012 02:38 PM, DRAGE, Keith (Keith) wrote: > Surely that argument extends to every possible codec. The set of MTI codecs should cover the set of use cases that have been identified. Additional MTI codecs that don't cover new use cases shouldn't be added. I believe the use case "distributed music band" in draft-ietf-rtcweb-use-cases-and-requirements can't be satisified with G.711. > > If the codecs supported by both endpoints do not supply the characteristics needed for the communication, then you will get interoperability failure. > > If I want more bandwidth or quality than OPUS supplies, then I will also get interoperability failure. > > Keith > >> -----Original Message----- >> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf >> Of Harald Alvestrand >> Sent: 30 August 2012 11:56 >> To: rtcweb@ietf.org >> Subject: Re: [rtcweb] RTCWEB needs an Internet Codec >> >> The counterpoint is that having G.711 as the only MTI means that you get >> interoperability failure for any application in which G.711 sound >> quality is not acceptable. >> >> This includes all applications involving music. >> >> On 08/29/2012 06:30 PM, Randall Gellens wrote: >>> At 12:13 AM -0400 8/29/12, Roman Shpount wrote: >>> >>>> I would argue G.711 should be the MTI codec. The rest can be left up >>>> to browser implementers. >>> I agree. >>> >>>> We can argue all we want, but the best royalty free low bitrate >>>> codec available will be the one everybody supports. >>> Very good point, and why we should mandate only one audio codec. >>> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb From Markus.Isomaki@nokia.com Thu Aug 30 06:14:21 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F421521F85AC for ; Thu, 30 Aug 2012 06:14:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wxt022P0Bn+A for ; Thu, 30 Aug 2012 06:14:19 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 19F0E21F8499 for ; Thu, 30 Aug 2012 06:14:18 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-da01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q7UDD3C1023834; Thu, 30 Aug 2012 16:14:12 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.26]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 30 Aug 2012 16:14:08 +0300 Received: from 008-AM1MPN1-041.mgdnok.nokia.com ([169.254.1.69]) by 008-AM1MMR1-010.mgdnok.nokia.com ([65.54.30.26]) with mapi id 14.02.0309.003; Thu, 30 Aug 2012 15:14:07 +0200 From: To: , Thread-Topic: Opus over the Internet? Thread-Index: Ac2Gr8HzJ/6oA0BvSY28PJ4c6WjX7A== Date: Thu, 30 Aug 2012 13:14:06 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.163.22.219] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 30 Aug 2012 13:14:08.0306 (UTC) FILETIME=[568D8120:01CD86B1] X-Nokia-AV: Clean Cc: rtcweb@ietf.org Subject: [rtcweb] Opus over the Internet? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 30 Aug 2012 13:14:21 -0000 Hi, Stefan Hakansson wrote: > >And there seems to be no tests whatsoever (at least not involving >humans) with actual channels introducing jitter and losses. > Are there any tests that actually compare different codecs, say Opus vs. G.= 722 vs. AMR-WB, in typical Internet use, meaning some loss and jitter? I su= ppose the performance is only partially related to the codec, and partially= to other implementation decisions, so it might be difficult to compare app= les-with-apples. But since people are arguing that Opus is an "Internet cod= ec", it would be actually nice to see some results in this sense. Or does "= Internet codec" mean something else?=20 Markus >-----Original Message----- >From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf >Of ext Stefan Hakansson LK >Sent: 30 August, 2012 14:58 >To: Jean-Marc Valin >Cc: rtcweb@ietf.org >Subject: Re: [rtcweb] Confirmation of consensus on audio codecs > >On 08/29/2012 03:10 PM, Jean-Marc Valin wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> On 08/29/2012 05:51 AM, Stefan Hakansson LK wrote: >... >> >>> That is great, but sort of underlines that there would be no harm in >>> delaying the decision until there are experiences made from real >>> world use - 'cause it would not be that long till that experience has >>> been made (Markus also brought up the IPR status as a reason for >>> waiting - I have no idea how long it would take to know more about >>> that). >> >> As Harald is pointing out, rtcweb implementations are going to ship >> pretty soon. > >If that is the case (and I think and hope so), why would we need to make i= t >MTI before seeing it in action? > >[...] > >> Are you expecting *another* single, standardized, royalty-free codec >> that operates over vast ranges of bitrates and operating conditions, >> from narrowband speech to stereo music, all with low delay, coming out >> in the next year? If not, what are you really waiting for? > >No, I'm not expecting that. I would just prefer us to see that Opus does >indeed deliver as promised before making it MTI. If it does, fine. If not,= we'd >have to discuss what to do then. > >To me it is like if you're going to place a bet, for an upcoming big race,= on a >horse that has never been in an actual race, but shows great promise. If y= ou >know that the horse is going to participate in a few practice races soon, = would >you not prefer to wait and see how it fares in those before placing the be= t >(given that the odds would not change)? > >Anyway, that's my view. Let's see what the chairs say. >> >>> As Paul suggested, I was referring to the lack of formal, controlled, >>> characterization tests. That is how other SDOs do it. I don't think >>> that is the only way to do it, but I think we should at least have >>> either such tests conducted or experience from deployment and use (in >>> a wide range of conditions and device types) before making it MTI. >> >> Opus has had "ITU-style" testing on English ( >> http://www.opus-codec.org/comparison/GoogleTest1.pdf ) and Mandarin ( >> http://www.opus-codec.org/comparison/GoogleTest2.pdf ). And if you >> don't trust Google on the tests I linked to, it's also been tested by >> Nokia: >> >http://research.nokia.com/files/public/%5B16%5D_InterSpeech2011_Voice_ >> Quality_Characterization_of_IETF_Opus_Codec.pdf >Come on, those tests are very limited compared to a formal characterizatio= n >test. (Example: >www.itu.int/dms_pub/itu-t/opb/tut/T-TUT-ASC-2010-MSW-E.docx). There is >very little info on the material used, the environment, processing and scr= ipts >and so on. And there seems to be no tests whatsoever (at least not involvi= ng >humans) with actual channels introducing jitter and losses. > >Note: I am in no way proposing that a formal characterization test is need= ed, >or even the right thing to do. It is a costly and time consuming process, = and >alternative approaches could prove to be more efficient. >What I am saying is that I think we should not mandate a codec that has >neither gone through that kind of formal characterization testing nor has = any >field experience from actual use on a reasonable scale (covering different >conditions and device types). It just seems wrong, especially given that w= e will >soon have field experience. > >> >> Now, unlike other SDOs, the testing did not stop there. ITU-T codecs >> generally end up being testing with something in the order of tens of >> minutes worth of audio. In *addition* to that kind of testing, Opus >> also had automated testing with hundreds of years worth of audio. If >> anything, I think other SDOs should learn something here. > >This may very well be true. I guess this comes down to how much you trust >that the quality assessment models (e.g. PEAQ, POLQA) give the same result >as human test subjects would. But I think this sounds like a really good t= hing. > >> >> Jean-Marc >> >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.12 (GNU/Linux) >> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ >> >> >iQEcBAEBAgAGBQJQPhThAAoJEJ6/8sItn9q9nAcH/0BsXl/FBgMhbYWVALpNmI >Yi >> Yj1ezyW8JVSv4io1YIozucl6KiDVi3LwYFteYgl78PlQ7o2muv/lJP9VswRHooH5 >> >Gax+aJUZkz7SlKxn+25wUlLgKQw6GAcUID5sJ0ewWdGOrwZu+SlZgYF3egYmm >wyL >> >pEl8BFj7wu3uakRm/BE9LsUDPFdCoZS6uXqXRJOy9P1dZ25edvgaymQvOwhEcX >u9 >> >xMq82YPNU2CZpfb88ew/l+U9FjW8c4iGkZYiu+VzmBL8wYOFP5pBhBhWc/bEb >0WX >> >8IUC5PJ0MMp49kb7/kfQj65/Py7u6ytYaO4PA0rjMHJ2V1PzH4EuqtNweYXVzNI >=3D >> =3DnwlD >> -----END PGP SIGNATURE----- >> > >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb From stephane.proust@orange.com Thu Aug 30 07:12:00 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E00DC21F84CE for ; Thu, 30 Aug 2012 07:12:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.096 X-Spam-Level: X-Spam-Status: No, score=-1.096 tagged_above=-999 required=5 tests=[AWL=0.302, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_16=0.6, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fVnYHZnc3KJ6 for ; Thu, 30 Aug 2012 07:12:00 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id F276321F8528 for ; Thu, 30 Aug 2012 07:11:59 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 8DEF32DC3EB; Thu, 30 Aug 2012 16:11:58 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 6E58D2380BE; Thu, 30 Aug 2012 16:11:58 +0200 (CEST) Received: from PEXCVZYM14.corporate.adroot.infra.ftgroup ([fe80::a42f:c628:bc76:d592]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0298.004; Thu, 30 Aug 2012 16:11:58 +0200 From: To: Martin Taylor , "rtcweb@ietf.org" Thread-Topic: [rtcweb] RTCWEB needs an Internet Codec Thread-Index: AQHNhZg7VAle8mPeRUCAmEaNdk1WoZdwDLGAgAB45ACAAdmicA== Date: Thu, 30 Aug 2012 14:11:56 +0000 Message-ID: <16529_1346335918_503F74AE_16529_311_1_2842AD9A45C83B44B57635FD4831E60A02A679@PEXCVZYM14.corporate.adroot.infra.ftgroup> References: <185A2074C1DC2342B1514880D000CC1AA7748BD4@ENFICSMBX1.datcon.co.uk> In-Reply-To: <185A2074C1DC2342B1514880D000CC1AA7748BD4@ENFICSMBX1.datcon.co.uk> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.6.19.115414 Subject: Re: [rtcweb] RTCWEB needs an Internet Codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 30 Aug 2012 14:12:01 -0000 >An Internet codec is one which was designed specifically to handle a signi= ficant level of packet loss. The G.xxx series codecs were designed for cir= cuit-switched environments where packet loss is a non-issue. Looking at the draft "Summary of Opus listening test results" which is supp= osed to "examine listening test results obtained for the Opus codec and how= they relate to the requirements" I cannot see unfortunately any result on = OPUS performance with packet losses and jitter nor any other result on any = real measured usage over internet, especially for the intended usage in "fu= ll band"... So, I don't know exactly to what extent and with respect to wha= t test results and what related requirement OPUS would be more an "internet= codec" than other G.xxx codecs that have been already and successfully exp= erienced over internet for years (at least with respect to this "packet los= s" robustness criterion). Furthermore, some key features that enhance any v= oice codec performance for usage over internet are anyway outside the codec= itself. Stephane De=A0: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] De la part = de Martin Taylor Envoy=E9=A0: mercredi 29 ao=FBt 2012 13:27 =C0=A0: rtcweb@ietf.org Objet=A0: Re: [rtcweb] RTCWEB needs an Internet Codec An Internet codec is one which was designed specifically to handle a signif= icant level of packet loss.=A0 The G.xxx series codecs were designed for ci= rcuit-switched environments where packet loss is a non-issue. If you are not experiencing voice quality issues with G.722, then you are l= ucky enough to have a very low loss Internet connection.=A0 We see frequent= issues with G.722 when used for VoIP, especially over WiFi and upstream ov= er ADSL.=A0 Data traffic that competes with voice for bandwidth frequently = causes choppy voice on these types of connection.=A0 We have chosen to use = SILK to deal with this issue, and this has resulted in major improvements i= n subjective voice quality.=A0 SILK is one of the "ingredients" of Opus. I believe that WebRTC applications which use Opus will deliver a far better= user experience in general than those that use G.711 or G.722.=A0 Whether = that means Opus should be mandatory to implement is another matter.=A0 In m= y view, it is only necessary to specify one MTI codec to ensure that there = is a baseline for interop.=A0 The market can decide what codecs it wishes t= o use to improve on this baseline interop. Martin From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= Roman Shpount Sent: 29 August 2012 05:14 To: Alan Johnston Cc: rtcweb@ietf.org Subject: Re: [rtcweb] RTCWEB needs an Internet Codec Not that I have anything against Opus, but what exactly makes Opus an inter= net codec? What is internet codec anyway? Makes this all kind of a meaningl= ess argument. I would argue that for my broadband internet connection G.722 is a perfect = internet codec. I do not care about bandwidth savings of Opus, and quality = wise, for the voice conversation, I cannot hear any difference. I would argue G.711 should be the MTI codec. The rest can be left up to bro= wser implementers. We can argue all we want, but the best royalty free low = bitrate codec available will be the one everybody supports. We can force it= to be Opus, but even if we don't, it will still be Opus on its merit alone= . G.722 will probably end up being supported as well, since it is free, pre= tty good quality, and easy to implement. P.S. Not that I am arguing for it, I am surprised no one made a case for iS= AC, since it is also royalty free, low bit rate, and very high quality. It = is event named "internet Speech Audio Codec". _____________ Roman Shpount On Tue, Aug 28, 2012 at 11:41 PM, Alan Johnston = wrote: The RTCWEB effort needs an Internet codec. =A0This is why Opus is the right choice. =A0RTCWEB also needs one codec for backwards compatibility with the VoIP world. =A0This is why G.711 is also the right choice. Any G.mumble codec is NOT an Internet codec and will not have the same performance on the Internet as one that was designed for the Internet! =A0If anyone doesn't understand what that means, go back and examine the CODEC Working Group archives to get educated. If someone wants another codec instead of Opus, then they need to propose another Internet codec. =A0Otherwise, we are not serving the Internet. - Alan - _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From stefan.lk.hakansson@ericsson.com Thu Aug 30 07:15:13 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7156221F8535 for ; Thu, 30 Aug 2012 07:15:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.082 X-Spam-Level: X-Spam-Status: No, score=-6.082 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 883okNFFCr-w for ; Thu, 30 Aug 2012 07:15:12 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 8ABC021F8528 for ; Thu, 30 Aug 2012 07:15:12 -0700 (PDT) X-AuditID: c1b4fb30-b7f7d6d0000042ea-5e-503f756f0295 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id A3.80.17130.F657F305; Thu, 30 Aug 2012 16:15:11 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.264.1; Thu, 30 Aug 2012 16:15:09 +0200 Message-ID: <503F756B.40102@ericsson.com> Date: Thu, 30 Aug 2012 16:15:07 +0200 From: Stefan Hakansson LK User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <503F46C5.2090607@alvestrand.no> <503F61CC.1010709@alvestrand.no> In-Reply-To: <503F61CC.1010709@alvestrand.no> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNJMWRmVeSWpSXmKPExsUyM+JvrW5+qX2AwZ4nchZr/7WzOzB6LFny kymAMYrLJiU1J7MstUjfLoEr4/T8b4wFM9krPhyeytzA+Jq1i5GDQ0LAROL+JZYuRk4gU0zi wr31bF2MXBxCAqcYJX6c+A7lLGeU+D11BTNIFa+ApsSed/tYQWwWAVWJ+9c3MIHYbAI2Emu7 p4DZogIhEmu+TWGEqBeUODnzCdgGEQFhia2vesFqhIEWn/r2jhViwXFGiXWNk8CKOAV0JR5+ nMsGYjML2EpcmHOdBcKWl9j+dg7YEUJANe9e32OdwCgwC8mOWUhaZiFpWcDIvIpRODcxMye9 3FwvtSgzubg4P0+vOHUTIzAAD275bbCDcdN9sUOM0hwsSuK8eqr7/YUE0hNLUrNTUwtSi+KL SnNSiw8xMnFwSjUw5j6z2RnXlvnCIyr5SQ5byv8X5+vYr++xCbU8FRGZ/W3bnwoWcXu1JfWK xcp5G2uSrzz/kC0s2x30UWvaYvGJh7aeEq/Z0q14/HrV8UW2AlFCB599nsc/b2f4hhtf35St Ml89TUk6Qz6y0+Tc1YYnywwTe9YstX2gYDQht8f0vMA+Hm2xlZ8qlFiKMxINtZiLihMBxqDG XA4CAAA= Subject: Re: [rtcweb] RTCWEB needs an Internet Codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 30 Aug 2012 14:15:13 -0000 On 08/30/2012 02:51 PM, Harald Alvestrand wrote: > On 08/30/2012 02:38 PM, DRAGE, Keith (Keith) wrote: >> Surely that argument extends to every possible codec. > The set of MTI codecs should cover the set of use cases that have > been identified. Additional MTI codecs that don't cover new use cases > shouldn't be added. > > I believe the use case "distributed music band" in > draft-ietf-rtcweb-use-cases-and-requirements can't be satisified with > G.711. I would argue that for most of the use cases (except those where the browser is used to interop with PSTN) the expected quality can't be satisfied with G.711. A wideband capable codec at the very least is needed. Another story is that I think that this is not the right time to mandate a codec that meets the quality expectations (and I said why I think so in [1]). [1] http://www.ietf.org/mail-archive/web/rtcweb/current/msg05148.html From christer.holmberg@ericsson.com Thu Aug 30 07:22:02 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9546B21F8610 for ; Thu, 30 Aug 2012 07:22:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.172 X-Spam-Level: X-Spam-Status: No, score=-6.172 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a-MAm0IVCG+D for ; Thu, 30 Aug 2012 07:22:00 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id C50BB21F8607 for ; Thu, 30 Aug 2012 07:21:59 -0700 (PDT) X-AuditID: c1b4fb2d-b7fea6d000002ccb-7f-503f77063346 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 0D.BB.11467.6077F305; Thu, 30 Aug 2012 16:21:58 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.99]) by esessmw0247.eemea.ericsson.se ([153.88.115.93]) with mapi; Thu, 30 Aug 2012 16:21:58 +0200 From: Christer Holmberg To: Harald Alvestrand , "DRAGE, Keith (Keith)" Date: Thu, 30 Aug 2012 16:21:56 +0200 Thread-Topic: [rtcweb] RTCWEB needs an Internet Codec Thread-Index: Ac2Gri+4hzHOmoPMT7mccN53hLwz2gADIVKg Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585340A3DCA98@ESESSCMS0356.eemea.ericsson.se> References: <503F46C5.2090607@alvestrand.no> <503F61CC.1010709@alvestrand.no> In-Reply-To: <503F61CC.1010709@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrELMWRmVeSWpSXmKPExsUyM+JvrS5buX2AweXpehbH+rrYLJ42nmW0 WPuvnd2B2aP12V5WjysTrrB6LFnykymAOYrLJiU1J7MstUjfLoEro+XaHNaCbzwV3c2XmRoY L3F1MXJySAiYSPTtPc8OYYtJXLi3nq2LkYtDSOAUo8TK5QdYIJwFjBKTuq8AORwcbAIWEt3/ tEEaRATSJZ60/WEEsZkF1CXuLD4HNohFQFXiya5PbCC2MNCCSb9uM0HUm0p8aVrABmEbSVw9 +IEZZCSvQLjEqjW+EKvOMkqc+LkVbA6ngK7Ew49zweoZgY77fmoNE8QucYlbT+YzQRwtILFk z3lmCFtU4uXjf6wQ9aISd9rXQ92mI7FgN8Q9zALaEssWvgar5xUQlDg58wnLBEaxWUjGzkLS MgtJyywkLQsYWVYxCucmZuaklxvqpRZlJhcX5+fpFaduYgTG08Etv3V3MJ46J3KIUZqDRUmc lytpv7+QQHpiSWp2ampBalF8UWlOavEhRiYOTqkGxil8jJef/3Y5JRBmGJ5lF/VtO/8kp6RN O9ex/U3ckPlURXRZyYmN3y8cMzj02aB11gTJdaZtbsWJKrnm507u/3XyUwJL4zuuBOZqDo0X Rfm8axbpXRdWcl+pOKnHrq3uf0h29mkP1/jTXSF8caueHEvm13acqPxB7bOD0EHD2nyFKKsZ NfUKSizFGYmGWsxFxYkAFxe+6HUCAAA= Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] RTCWEB needs an Internet Codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 30 Aug 2012 14:22:02 -0000 >> Surely that argument extends to every possible codec. >The set of MTI codecs should cover the set of use cases that have been ide= ntified. >Additional MTI codecs that don't cover new use cases shouldn't be added. > >I believe the use case "distributed music band" in draft-ietf-rtcweb-use-c= ases-and-requirements can't be satisified with G.711. Maybe dubstep was invented that way ;) Regards, Christer >> -----Original Message----- >> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On=20 >> Behalf Of Harald Alvestrand >> Sent: 30 August 2012 11:56 >> To: rtcweb@ietf.org >> Subject: Re: [rtcweb] RTCWEB needs an Internet Codec >> >> The counterpoint is that having G.711 as the only MTI means that you=20 >> get interoperability failure for any application in which G.711 sound=20 >> quality is not acceptable. >> >> This includes all applications involving music. >> >> On 08/29/2012 06:30 PM, Randall Gellens wrote: >>> At 12:13 AM -0400 8/29/12, Roman Shpount wrote: >>> >>>> I would argue G.711 should be the MTI codec. The rest can be left=20 >>>> up to browser implementers. >>> I agree. >>> >>>> We can argue all we want, but the best royalty free low bitrate=20 >>>> codec available will be the one everybody supports. >>> Very good point, and why we should mandate only one audio codec. >>> >> _______________________________________________ >> 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 From Martin.Taylor@metaswitch.com Thu Aug 30 07:36:02 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CCA021F8617 for ; Thu, 30 Aug 2012 07:36:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_16=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tsMz1hI+U2jW for ; Thu, 30 Aug 2012 07:36:01 -0700 (PDT) Received: from ENFIRHETS1.metaswitch.com (enfirhets1.metaswitch.com [192.91.191.166]) by ietfa.amsl.com (Postfix) with ESMTP id 2569121F84D4 for ; Thu, 30 Aug 2012 07:36:01 -0700 (PDT) Received: from ENFIRHCAS1.datcon.co.uk (172.18.4.12) by ENFIRHETS1.metaswitch.com (172.18.209.22) with Microsoft SMTP Server (TLS) id 14.2.298.4; Thu, 30 Aug 2012 15:35:33 +0100 Received: from ENFICSMBX1.datcon.co.uk ([fe80::d5d5:c683:a3be:3a19]) by ENFIRHCAS1.datcon.co.uk ([fe80::85a7:aa4e:2516:c2ad%11]) with mapi id 14.02.0298.004; Thu, 30 Aug 2012 15:35:56 +0100 From: Martin Taylor To: "stephane.proust@orange.com" , "rtcweb@ietf.org" Thread-Topic: [rtcweb] RTCWEB needs an Internet Codec Thread-Index: AQHNhZg7p2VbUuK4zUOFs+aV7HoS55dwHXSAgACGQ+CAAbMnAIAAFoRw Date: Thu, 30 Aug 2012 14:35:55 +0000 Message-ID: <185A2074C1DC2342B1514880D000CC1AA774A001@ENFICSMBX1.datcon.co.uk> References: <185A2074C1DC2342B1514880D000CC1AA7748BD4@ENFICSMBX1.datcon.co.uk> <16529_1346335918_503F74AE_16529_311_1_2842AD9A45C83B44B57635FD4831E60A02A679@PEXCVZYM14.corporate.adroot.infra.ftgroup> In-Reply-To: <16529_1346335918_503F74AE_16529_311_1_2842AD9A45C83B44B57635FD4831E60A02A679@PEXCVZYM14.corporate.adroot.infra.ftgroup> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.18.39.102] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [rtcweb] RTCWEB needs an Internet Codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 30 Aug 2012 14:36:02 -0000 > I cannot see unfortunately any result on OPUS performance with packet los= ses I suggest you read section 2.1 of http://tools.ietf.org/html/draft-valin-co= dec-results-00 Admittedly this test related to SILK rather than to Opus, but Opus inherits= the characteristics of SILK as it relates to performance under conditions = of packet loss. Martin -----Original Message----- From: stephane.proust@orange.com [mailto:stephane.proust@orange.com]=20 Sent: 30 August 2012 15:12 To: Martin Taylor; rtcweb@ietf.org Subject: RE: [rtcweb] RTCWEB needs an Internet Codec >An Internet codec is one which was designed specifically to handle a signi= ficant level of packet loss. The G.xxx series codecs were designed for cir= cuit-switched environments where packet loss is a non-issue. Looking at the draft "Summary of Opus listening test results" which is supp= osed to "examine listening test results obtained for the Opus codec and how= they relate to the requirements" I cannot see unfortunately any result on = OPUS performance with packet losses and jitter nor any other result on any = real measured usage over internet, especially for the intended usage in "fu= ll band"... So, I don't know exactly to what extent and with respect to wha= t test results and what related requirement OPUS would be more an "internet= codec" than other G.xxx codecs that have been already and successfully exp= erienced over internet for years (at least with respect to this "packet los= s" robustness criterion). Furthermore, some key features that enhance any v= oice codec performance for usage over internet are anyway outside the codec= itself. Stephane De=A0: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] De la part = de Martin Taylor Envoy=E9=A0: mercredi 29 ao=FBt 2012 13:27 =C0=A0: rtcweb@= ietf.org Objet=A0: Re: [rtcweb] RTCWEB needs an Internet Codec An Internet codec is one which was designed specifically to handle a signif= icant level of packet loss.=A0 The G.xxx series codecs were designed for ci= rcuit-switched environments where packet loss is a non-issue. If you are not experiencing voice quality issues with G.722, then you are l= ucky enough to have a very low loss Internet connection.=A0 We see frequent= issues with G.722 when used for VoIP, especially over WiFi and upstream ov= er ADSL.=A0 Data traffic that competes with voice for bandwidth frequently = causes choppy voice on these types of connection.=A0 We have chosen to use = SILK to deal with this issue, and this has resulted in major improvements i= n subjective voice quality.=A0 SILK is one of the "ingredients" of Opus. I believe that WebRTC applications which use Opus will deliver a far better= user experience in general than those that use G.711 or G.722.=A0 Whether = that means Opus should be mandatory to implement is another matter.=A0 In m= y view, it is only necessary to specify one MTI codec to ensure that there = is a baseline for interop.=A0 The market can decide what codecs it wishes t= o use to improve on this baseline interop. Martin From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= Roman Shpount Sent: 29 August 2012 05:14 To: Alan Johnston Cc: rtcweb@ietf.org Subject: Re: [rtcweb] RTCWEB needs an Internet Codec Not that I have anything against Opus, but what exactly makes Opus an inter= net codec? What is internet codec anyway? Makes this all kind of a meaningl= ess argument. I would argue that for my broadband internet connection G.722 is a perfect = internet codec. I do not care about bandwidth savings of Opus, and quality = wise, for the voice conversation, I cannot hear any difference. I would argue G.711 should be the MTI codec. The rest can be left up to bro= wser implementers. We can argue all we want, but the best royalty free low = bitrate codec available will be the one everybody supports. We can force it= to be Opus, but even if we don't, it will still be Opus on its merit alone= . G.722 will probably end up being supported as well, since it is free, pre= tty good quality, and easy to implement. P.S. Not that I am arguing for it, I am surprised no one made a case for iS= AC, since it is also royalty free, low bit rate, and very high quality. It = is event named "internet Speech Audio Codec". _____________ Roman Shpount On Tue, Aug 28, 2012 at 11:41 PM, Alan Johnston = wrote: The RTCWEB effort needs an Internet codec. =A0This is why Opus is the right= choice. =A0RTCWEB also needs one codec for backwards compatibility with th= e VoIP world. =A0This is why G.711 is also the right choice. Any G.mumble codec is NOT an Internet codec and will not have the same perf= ormance on the Internet as one that was designed for the Internet! =A0If anyone doesn't understand what that means, go back and examine the CO= DEC Working Group archives to get educated. If someone wants another codec instead of Opus, then they need to propose a= nother Internet codec. =A0Otherwise, we are not serving the Internet. - Alan - _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou = copies sans autorisation. Si vous avez recu ce message par erreur, veuillez= le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Le= s messages electroniques etant susceptibles d'alteration, France Telecom - = Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used= or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From dwing@cisco.com Thu Aug 30 08:28:58 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF8CE21F858A for ; Thu, 30 Aug 2012 08:28:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.5 X-Spam-Level: X-Spam-Status: No, score=-110.5 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TScxLxn9lFF1 for ; Thu, 30 Aug 2012 08:28:58 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 3030521F8567 for ; Thu, 30 Aug 2012 08:28:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=2333; q=dns/txt; s=iport; t=1346340538; x=1347550138; h=from:to:references:in-reply-to:subject:date:message-id: mime-version:content-transfer-encoding; bh=ZHkbAkGU/uxKTTyImXorl7BBuSRDMsBLihy2cYVDyHg=; b=gvHL17jiHFTNX80zANIMEKoiynMmZUjdZ2IGtv0+crnZkS8QH9rj4Nal CyM02xjRiUT1LuI/n4vnavopxwk3K1mRAvCJgRRkSHAa4lvPCD23v2vjU toU9yoICdCsDkTGcvlCrWmJAc51cA3XGpRjM6K+w0haK0NZxzSFo5EUSn M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAGuGP1CrRDoH/2dsb2JhbABFqxGPdIEHgiABAQEDAQEBAQUKARcQNBAHAQMCCQ8CBAEBKAcZDhUKCQgCBAESCxeHZQUMnDmgEwSLCIZZA4hPhQ2WLYFngwM X-IronPort-AV: E=Sophos;i="4.80,341,1344211200"; d="scan'208";a="54183325" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-3.cisco.com with ESMTP; 30 Aug 2012 15:28:57 +0000 Received: from dwingWS ([10.32.240.194]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q7UFSvQ8016351; Thu, 30 Aug 2012 15:28:57 GMT From: "Dan Wing" To: "'Christer Holmberg'" , , References: <503E0B63.3020708@ericsson.com>, <7F2072F1E0DE894DA4B517B93C6A05853409FF2F4C@ESESSCMS0356.eemea.ericsson.se>, <035101cd8636$3b654160$b22fc420$@com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2F5C@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05853409FF2F5C@ESESSCMS0356.eemea.ericsson.se> Date: Thu, 30 Aug 2012 08:28:57 -0700 Message-ID: <04c101cd86c4$2c48c150$84da43f0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHNhhenMhkLi/vCmkGQ1yfqZgaa8pdxXxawgACdAheAAH/40A== Content-Language: en-us Subject: Re: [rtcweb] H.264 SVC and BUNDLE X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 30 Aug 2012 15:28:59 -0000 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Thursday, August 30, 2012 12:51 AM > To: Dan Wing; public-webrtc@w3.org; rtcweb@ietf.org > Subject: RE: [rtcweb] H.264 SVC and BUNDLE > > > Hi Dan, > > Thanks for the information! > > The issue you raise is of course not related to BUNDLE, but to > multiplexing in general. Yes, of course. That's why I answered in-line, after your question about general multiplexing. -d > Regards, > > Christer > ________________________________________ > From: Dan Wing [dwing@cisco.com] > Sent: Thursday, August 30, 2012 1:32 AM > To: Christer Holmberg; public-webrtc@w3.org; rtcweb@ietf.org > Subject: RE: [rtcweb] H.264 SVC and BUNDLE > > > -----Original Message----- > > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > > Behalf Of Christer Holmberg > > Sent: Wednesday, August 29, 2012 11:50 AM > > To: public-webrtc@w3.org; rtcweb@ietf.org > > Subject: [rtcweb] H.264 SVC and BUNDLE > > > > Hi, > > > > At the telco yesterday one of the Microsoft guys claimed that H.264 > SVC > > does not work with BUNDLE, but he didn't have the details. > > > > Could someone please explain the reason why he/she doesn't think > H.264 > > SVC work with BUNDLE? > > > > (Note, that if using the same port for the different codec layers is > a > > problem, then it's not a BUNDLE problem - it's a generic multiplexing > > problem.) > > The general multiplexing of layers onto the same 5-tuple is a problem, > *if* we want the layers to have different DSCP values. This is because > we cannot successfully and reliably set different DSCP values for > packets > belonging to a 5-tuple over the Internet -- too many things rewrite > the DSCP field (to a different value) or simply clear the DSCP field. > This makes it impossible to restore the per-packet DSCP values later > (e.g., using RSVP, or using any other better/stronger/faster signaling > method). If, however, each 5-tuple has its own DSCP value then that > DSCP value could be restored. > > -d > > > Thanks! > > > > Regards, > > > > Christer > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb From lars@netapp.com Thu Aug 30 10:00:07 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65A3C21F8575 for ; Thu, 30 Aug 2012 10:00:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.455 X-Spam-Level: X-Spam-Status: No, score=-10.455 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5HcvGHbYwfoH for ; Thu, 30 Aug 2012 10:00:05 -0700 (PDT) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by ietfa.amsl.com (Postfix) with ESMTP id E98CD21F855E for ; Thu, 30 Aug 2012 10:00:05 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,341,1344236400"; d="p7s'?scan'208";a="683816670" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 30 Aug 2012 10:00:05 -0700 Received: from vmwexceht03-prd.hq.netapp.com (vmwexceht03-prd.hq.netapp.com [10.106.76.241]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id q7UH04Pm002276; Thu, 30 Aug 2012 10:00:05 -0700 (PDT) Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.212]) by vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) with mapi id 14.02.0309.002; Thu, 30 Aug 2012 10:00:04 -0700 From: "Eggert, Lars" To: "Markus.Isomaki@nokia.com" Thread-Topic: [rtcweb] Opus over the Internet? Thread-Index: Ac2Gr8HzJ/6oA0BvSY28PJ4c6WjX7AAW88CA Date: Thu, 30 Aug 2012 17:00:09 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.104.60.115] Content-Type: multipart/signed; boundary="Apple-Mail=_C4486F33-F483-4388-A545-93459B49E956"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: "" Subject: Re: [rtcweb] Opus over the Internet? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 30 Aug 2012 17:00:07 -0000 --Apple-Mail=_C4486F33-F483-4388-A545-93459B49E956 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Aug 30, 2012, at 15:14, Markus.Isomaki@nokia.com wrote: > Are there any tests that actually compare different codecs, say Opus = vs. G.722 vs. AMR-WB, in typical Internet use, meaning some loss and = jitter? ... > But since people are arguing that Opus is an "Internet codec", it = would be actually nice to see some results in this sense.=20 +1 Lars= --Apple-Mail=_C4486F33-F483-4388-A545-93459B49E956 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMQDCCBUow ggQyoAMCAQICEFcfSRTG0jNknqb9LV9GuFkwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMTEyMTAwMDAwMDBaFw0x MjEyMDkyMzU5NTlaMIIBDTEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2 aWNlMRQwEgYDVQQDFAtMYXJzIEVnZ2VydDEeMBwGCSqGSIb3DQEJARYPbGFyc0BuZXRhcHAuY29t MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAokrhJTcXt6J/VEpZOicLoguBlYTjXP9v Ze4HuuhXnURUS8YouAfgaqA0zYbt5yd6fh4PBMdAaEWr5yJyHuFykXlrCumjUWSpLuqTS2A+pt4q cZaAQk9iLDN/UVd3SpkUuvWbxXlqzG7/BSqa3VNObBzCmyh+V7aXxri+30CT//DSsNRC4VFy6sn6 dMgSaFenXLwe/FBwY0qTMfICT1PrrX6Sw1S8OfH9rykLlZXbmfkFExxQngp1DJH9xMHeODHGbCv/ ty5gdxMOrLe+vENxFEcy1YQWBZd1kNL4UObugF8A/jE/s+Oa3H1VFH8ghqZTdqGDysVxmtKHuNFx 6jIBSQIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXATAqMCgG CCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIFoDAdBgNV HSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDovL2luZGMx ZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20vSW5kQzFEaWdpdGFsSUQtRzMuY3JsMA0GCSqG SIb3DQEBBQUAA4IBAQBA7q6tR92qpd7xo7VBsrOfGCWzoxIVfTc7t0RhB/Oz/+c3lnhYnNScIuKN JmyZvznmVxqB9BJ72+NkvmdB/hnILSBTRawL2tyLo9PkBtN0nRt4gS6wjpWnD8G83hlJLE7r25jk 7HkRev61dTIXsANFpJKF02C4XSoDfEzNV6MpuEvHvcgHCqMrlwWwfKc7+NoDnE8PBuRzwSXvlD5L mswCY2iiOsd7ImNO4OzTCxETvKTDu92+FTIbRJJpYjVNv1UF7e3w9Kq65BkZJErUH19beUeQl0Wh 2BJQE6/15rQyCnP0iJ/Nmx2/kI6M0PWunEsI6FMs0MbosreaWGHlQmomMIIG7jCCBdagAwIBAgIQ cRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQL EzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYD VQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9y aXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkwNDMwMjM1OTU5WjCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP6bGNQU4099oL42r6ZYggCxET6ZvgSU6Lb9UB 0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYHr54UGAdPWr2f0jGyVBlzRmoZQhHsEnMhjfXc MM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50ABMN0Ibak2f4MwOuGjxraXj2wCyO4YM/d/mZ //6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yxBF6+wbaULZeQLSfSux7pg2qE9sSyriMGZSal J1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ6/tu1ULEvkHH9QIDAQABo4ICuTCCArUwNAYI KwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC52ZXJpc2lnbi5jb20wEgYDVR0T AQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CGSAGG+EUBBxcBMFYwKAYIKwYBBQUHAgEWHGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYIKwYBBQUHAgIwHhocaHR0cHM6Ly93d3cudmVy aXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9w Y2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYIKwYBBQUHAQwEYjBgoV6gXDBaMFgwVhYJaW1h Z2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQUjibKaxLB4shBRgwJhYkaHR0cDovL2xvZ28u dmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRl TGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EIQf04BKJL57XM9UP2SSsR+DCB8QYDVR0jBIHp MIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNV BAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDEg UHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHM4IRAItbdVaEVIULAM+v OEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZgbWpBbVSOOk5hIls5DSoWufYbAlMJBq6WaSH O3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v8dKBl8pUWkO/N4t6jhmND0OojPKvYLMVirOV nDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM61a4ScAjr+zvid+zoK2Q1ds262uDRyxTWcVib vtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/XLJtSd5lUkL7DojS7Uodv0vj+Mxy+kgOZY5J yNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4VRaMxmgD5yKocwuxvKDaUljdCg5/wYIxggSL MIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0 cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFs aWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBD QSAtIEczAhBXH0kUxtIzZJ6m/S1fRrhZMAkGBSsOAwIaBQCgggJtMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDgzMDE3MDAwMVowIwYJKoZIhvcNAQkEMRYEFN4f MuIBdf77MXtMrdn8/vCMhDzaMIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEX MBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsx OzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChj KTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENs YXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEFcfSRTG0jNknqb9LV9GuFkwggEF BgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEczAhBXH0kUxtIzZJ6m/S1fRrhZMA0GCSqGSIb3DQEBAQUABIIBAAQebbZP oU2TBGjjYIqZAN58FcEAmDb5iJoM1WOeiywUUatqhMrGFt/H/3s/nXEuhPc5roooI8SrUGis+/G/ 2iOqxep/DdQBF6DwL4g/eKJlRwqVlnETWbiRIgZqtUAOM74FkKIoV3ynToKNCOnIb4FAMmJsPmIX fRyIHogunEYtGLaCkqvfFOE55DyhOaXbxrT4YJEgPuYzhze/ZaBsMMxIhSHJRsWorMyHWT+/bc3H 3tMHM1bcaF/mN3lqkoRABCoMDpak8ixYiJ/vd/eePQOPEnRWBzK2kVZpHrFrkQRfI53HEhnqKOkL 5zHT5+0ALZ0lPOhqIuD23KpQMKc7ppgAAAAAAAA= --Apple-Mail=_C4486F33-F483-4388-A545-93459B49E956-- From randy@qualcomm.com Thu Aug 30 10:29:55 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B9B821F8527 for ; Thu, 30 Aug 2012 10:29:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.553 X-Spam-Level: X-Spam-Status: No, score=-106.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5johD+HTUZ9c for ; Thu, 30 Aug 2012 10:29:54 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by ietfa.amsl.com (Postfix) with ESMTP id 7891B21F851E for ; Thu, 30 Aug 2012 10:29:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=@qualcomm.com; q=dns/txt; s=qcdkim; t=1346347794; x=1377883794; h=message-id:in-reply-to:references:x-mailer:date:to:from: subject:cc:mime-version:content-type:x-random-sig-tag: x-originating-ip; bh=QoBc9nRudz/KoHgkSnmpuF3RGDW82wVGdCm0O57TMQY=; b=DR+9gey0G7kYlMhTNHra0SlCyik4rQTzST/bflHU/eYIDNK7IumrfVEJ u78emoTbYqxSstSkxMV6LBgmS0158nqqAR94v1a7NXsmVnE7fkQ/a05bv +Wj4mljkOmIxLYdnXp1NWAvoyarv0r18FoC8wlrfE/hDZFK3RmcJqvOoV o=; X-IronPort-AV: E=McAfee;i="5400,1158,6820"; a="231269046" Received: from ironmsg02-r.qualcomm.com ([172.30.46.16]) by wolverine01.qualcomm.com with ESMTP; 30 Aug 2012 10:29:52 -0700 X-IronPort-AV: E=Sophos;i="4.80,341,1344236400"; d="scan'208";a="160912736" Received: from nasanexhc07.na.qualcomm.com ([172.30.39.190]) by ironmsg02-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 30 Aug 2012 10:29:51 -0700 Received: from [99.111.97.136] (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.190) with Microsoft SMTP Server (TLS) id 14.2.318.1; Thu, 30 Aug 2012 10:29:51 -0700 Message-ID: In-Reply-To: <503F5555.5040303@ericsson.com> References: <9E2843EA-EBB9-40B3-898C-6B5216FAE7A5@cisco.com> <503CBB52.8070300@ericsson.com> <503CF224.5050609@mozilla.com> <503DE60D.2060706@ericsson.com> <503E14E1.6000401@mozilla.com> <503F5555.5040303@ericsson.com> X-Mailer: Eudora for Mac OS X Date: Thu, 30 Aug 2012 10:26:38 -0700 To: Stefan Hakansson LK , Jean-Marc Valin From: Randall Gellens MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Random-Sig-Tag: 1.0b28 X-Originating-IP: [172.30.39.5] Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Confirmation of consensus on audio codecs X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 30 Aug 2012 17:29:55 -0000 At 1:58 PM +0200 8/30/12, Stefan Hakansson LK wrote: >> As Harald is pointing out, rtcweb implementations are going to ship >> pretty soon. > > If that is the case (and I think and hope so), why would we need to > make it MTI before seeing it in action? Good point. We can hold off on mandating codecs until we see some initial implementations. We might not need to mandate anything. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Why was I born with such contemporaries? --Oscar Wilde From randy@qualcomm.com Thu Aug 30 10:31:54 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0FE321F854E for ; Thu, 30 Aug 2012 10:31:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.554 X-Spam-Level: X-Spam-Status: No, score=-106.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7XfY8vNJ-wJy for ; Thu, 30 Aug 2012 10:31:54 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by ietfa.amsl.com (Postfix) with ESMTP id 5253621F854D for ; Thu, 30 Aug 2012 10:31:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=@qualcomm.com; q=dns/txt; s=qcdkim; t=1346347914; x=1377883914; h=message-id:in-reply-to:references:x-mailer:date:to:from: subject:cc:mime-version:content-type:x-random-sig-tag: x-originating-ip; bh=BCHq+WgSLRumduPdYLuezmFf3wjJ8fHEnCg27dvSrDI=; b=nNTQmAZoycP6b16T1vwDD9VpRLajpGd41x7RyPbhHOcaQ6zKS8l7lSKZ 9+XLEztO0fbG0Lj063coOKwYX4HCaQC6DX3gvVQlgY8cKdyIZpyHuu3M1 3Y/W0Fu3AmjmaNQXti0NQfOCwuK2CPHDXVgxQcJT2bJyB7Pmmkwa83SMZ 8=; X-IronPort-AV: E=McAfee;i="5400,1158,6820"; a="231270644" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by wolverine01.qualcomm.com with ESMTP; 30 Aug 2012 10:31:54 -0700 X-IronPort-AV: E=Sophos;i="4.80,341,1344236400"; d="scan'208";a="322407420" Received: from nasanexhc07.na.qualcomm.com ([172.30.39.190]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 30 Aug 2012 10:31:53 -0700 Received: from [99.111.97.136] (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.190) with Microsoft SMTP Server (TLS) id 14.2.318.1; Thu, 30 Aug 2012 10:31:53 -0700 Message-ID: In-Reply-To: <503F61CC.1010709@alvestrand.no> References: <503F46C5.2090607@alvestrand.no> <503F61CC.1010709@alvestrand.no> X-Mailer: Eudora for Mac OS X Date: Thu, 30 Aug 2012 10:31:08 -0700 To: Harald Alvestrand , "DRAGE, Keith (Keith)" From: Randall Gellens MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Random-Sig-Tag: 1.0b28 X-Originating-IP: [172.30.39.5] Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] RTCWEB needs an Internet Codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 30 Aug 2012 17:31:54 -0000 At 2:51 PM +0200 8/30/12, Harald Alvestrand wrote: > The set of MTI codecs should cover the set of use cases that have > been identified. That may be too many mandated codecs. This business of mandating specific codecs is difficult and contentious, since there are so many competing interests involving different implementation platforms and operating environments. It may also be unnecessary since, obviously, implementers want to interoperate and the spectrum of supported codecs will reflect this. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- To err is human, to moo bovine. From ted.ietf@gmail.com Thu Aug 30 10:47:21 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD60421F84A6 for ; Thu, 30 Aug 2012 10:47:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.87 X-Spam-Level: X-Spam-Status: No, score=-3.87 tagged_above=-999 required=5 tests=[AWL=-0.271, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BUD4Z3djzWdZ for ; Thu, 30 Aug 2012 10:47:21 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2AA0621F8555 for ; Thu, 30 Aug 2012 10:47:21 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so2628308vcb.31 for ; Thu, 30 Aug 2012 10:47:20 -0700 (PDT) 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=fAJnPk6wttWMQcCM9Z+x2eG1Bq7orhkLS+PN0C8PhwU=; b=c5xiOXeBSM1cNYbvgQrc2uicDwpxI9q/BqjewsFmIgCmZa5ECTXDJDZ6FeU3pGBLwO f6fUEtoIaea8CjaIjzu9UFz+CdYkKRdPI6uEyKrs8YSJRI+9GPvzh6FJtOtXslI1syJN BTVgn9ZsAeyC9e1zo9HTHrBUKcOHIeHPg4kHViWUuQCWeVHQwq6mOwOoi4lDt9lrok4B gMLgI09adJqY7EbKWJuDuXhNaBvD8dbaQ5iwri20tfejSlyCvaJ+yVTsK/ikjbKmUhIZ 3VEMotTqkalZkvB9VnwFADl26bHSG3gAc/bvB8EPvyTG7D6J4tQh8JfOTw3GfXvJySOR xPyA== MIME-Version: 1.0 Received: by 10.52.32.99 with SMTP id h3mr3049042vdi.108.1346348840633; Thu, 30 Aug 2012 10:47:20 -0700 (PDT) Received: by 10.58.228.232 with HTTP; Thu, 30 Aug 2012 10:47:20 -0700 (PDT) In-Reply-To: References: <9E2843EA-EBB9-40B3-898C-6B5216FAE7A5@cisco.com> <503CBB52.8070300@ericsson.com> <503CF224.5050609@mozilla.com> <503DE60D.2060706@ericsson.com> <503E14E1.6000401@mozilla.com> <503F5555.5040303@ericsson.com> Date: Thu, 30 Aug 2012 10:47:20 -0700 Message-ID: From: Ted Hardie To: Randall Gellens Content-Type: text/plain; charset=ISO-8859-1 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Confirmation of consensus on audio codecs X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 30 Aug 2012 17:47:21 -0000 On Thu, Aug 30, 2012 at 10:26 AM, Randall Gellens wrote: >> If that is the case (and I think and hope so), why would we need to make >> it MTI before seeing it in action? > > > Good point. We can hold off on mandating codecs until we see some initial > implementations. We might not need to mandate anything. As chair: The decision to mandate codecs as a way of avoiding interoperability failures in negotiation has already been taken by the working group. regards, Ted Hardie From jmvalin@mozilla.com Thu Aug 30 12:07:22 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE15521F85AF for ; Thu, 30 Aug 2012 12:07:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5jAxc8+scphY for ; Thu, 30 Aug 2012 12:07:21 -0700 (PDT) Received: from smtp.mozilla.org (mx1.corp.phx1.mozilla.com [63.245.216.69]) by ietfa.amsl.com (Postfix) with ESMTP id DE70921F85AA for ; Thu, 30 Aug 2012 12:07:21 -0700 (PDT) Received: from [192.168.1.14] (modemcable094.20-21-96.mc.videotron.ca [96.21.20.94]) (Authenticated sender: jvalin@mozilla.com) by mx1.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id A2945F20B8; Thu, 30 Aug 2012 12:07:17 -0700 (PDT) Message-ID: <503FB9CE.2080000@mozilla.com> Date: Thu, 30 Aug 2012 15:06:54 -0400 From: Jean-Marc Valin User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Markus.Isomaki@nokia.com References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Opus over the Internet? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 30 Aug 2012 19:07:22 -0000 On 12-08-30 09:14 AM, Markus.Isomaki@nokia.com wrote: > Are there any tests that actually compare different codecs, say Opus > vs. G.722 vs. AMR-WB, in typical Internet use, meaning some loss and > jitter? I suppose the performance is only partially related to the > codec, and partially to other implementation decisions, so it might > be difficult to compare apples-with-apples. But since people are > arguing that Opus is an "Internet codec", it would be actually nice > to see some results in this sense. Or does "Internet codec" mean > something else? The term "Internet codec" means different things to different people, but to me this means more than "having good packet loss concealment". Sure we have PLC (though it was never compared to G.722 or AMR-WB) and we also have (optional) low bit-rate embedded redundancy (also called FEC) and (also optional) independent frames, but that's just one aspect. One of the first things we've been asked when designing Opus was to make the rate *really* adaptable because we never know what kind of rates will be available. This not only meant having a wide range of bitrates, but also being able to vary in small increments. This is why Opus scales from about 6 kb/s to 512 kb/s, in increments of 0.4 kb/s (one byte with 20 ms frames). Compare that to AMR-WB, which scales from 6.6 to 23.85 in (on average) ~2.5 kb/s increments. The reason Opus can have more than 1200 possible bitrates is because on the Internet, other layers in the protocol stack provide octet granularity framing/sizing. We don't need to spend 11 bits signalling the bitrate because UDP already encodes the packet size. There's also practical aspects. If you look at the rates supported by AMR-WB, you see that *none* of them represents an integer number of bytes per frame. For example, 23.85 kb/s is 59 bytes plus 5 bits per frame. It's definitely not the only cause, but the bottom line is that the payload format for AMR-WB (rfc4867) is quite complex. Now compare this with the Opus RTP payload (http://tools.ietf.org/html/draft-spittka-payload-rtp-opus). Although it's not complete, it's not only much simpler, but it also makes it possible to decode RTP packets without having even seen the SDP or any out-of-band signalling. People may have other definitions, but that's what *I* mean by Opus being an "Internet codec". Cheers, Jean-Marc >> -----Original Message----- From: rtcweb-bounces@ietf.org >> [mailto:rtcweb-bounces@ietf.org] On Behalf Of ext Stefan Hakansson >> LK Sent: 30 August, 2012 14:58 To: Jean-Marc Valin Cc: >> rtcweb@ietf.org Subject: Re: [rtcweb] Confirmation of consensus on >> audio codecs >> >> On 08/29/2012 03:10 PM, Jean-Marc Valin wrote: > On 08/29/2012 05:51 AM, Stefan Hakansson LK wrote: >>> ... > >>>>> That is great, but sort of underlines that there would be no >>>>> harm in delaying the decision until there are experiences >>>>> made from real world use - 'cause it would not be that long >>>>> till that experience has been made (Markus also brought up >>>>> the IPR status as a reason for waiting - I have no idea how >>>>> long it would take to know more about that). > > As Harald is pointing out, rtcweb implementations are going to ship > pretty soon. >>> >>> If that is the case (and I think and hope so), why would we need >>> to make it MTI before seeing it in action? >>> >>> [...] >>> > Are you expecting *another* single, standardized, royalty-free codec > that operates over vast ranges of bitrates and operating conditions, > from narrowband speech to stereo music, all with low delay, coming > out in the next year? If not, what are you really waiting for? >>> >>> No, I'm not expecting that. I would just prefer us to see that >>> Opus does indeed deliver as promised before making it MTI. If it >>> does, fine. If not, we'd have to discuss what to do then. >>> >>> To me it is like if you're going to place a bet, for an upcoming >>> big race, on a horse that has never been in an actual race, but >>> shows great promise. If you know that the horse is going to >>> participate in a few practice races soon, would you not prefer to >>> wait and see how it fares in those before placing the bet (given >>> that the odds would not change)? >>> >>> Anyway, that's my view. Let's see what the chairs say. > >>>>> As Paul suggested, I was referring to the lack of formal, >>>>> controlled, characterization tests. That is how other SDOs do >>>>> it. I don't think that is the only way to do it, but I think >>>>> we should at least have either such tests conducted or >>>>> experience from deployment and use (in a wide range of >>>>> conditions and device types) before making it MTI. > > Opus has had "ITU-style" testing on English ( > http://www.opus-codec.org/comparison/GoogleTest1.pdf ) and Mandarin > ( http://www.opus-codec.org/comparison/GoogleTest2.pdf ). And if you > don't trust Google on the tests I linked to, it's also been tested > by Nokia: > >>> http://research.nokia.com/files/public/%5B16%5D_InterSpeech2011_Voice_ > >>> Quality_Characterization_of_IETF_Opus_Codec.pdf >>> Come on, those tests are very limited compared to a formal >>> characterization test. (Example: >>> www.itu.int/dms_pub/itu-t/opb/tut/T-TUT-ASC-2010-MSW-E.docx). >>> There is very little info on the material used, the environment, >>> processing and scripts and so on. And there seems to be no tests >>> whatsoever (at least not involving humans) with actual channels >>> introducing jitter and losses. >>> >>> Note: I am in no way proposing that a formal characterization >>> test is needed, or even the right thing to do. It is a costly and >>> time consuming process, and alternative approaches could prove to >>> be more efficient. What I am saying is that I think we should not >>> mandate a codec that has neither gone through that kind of formal >>> characterization testing nor has any field experience from actual >>> use on a reasonable scale (covering different conditions and >>> device types). It just seems wrong, especially given that we >>> will soon have field experience. >>> > > Now, unlike other SDOs, the testing did not stop there. ITU-T codecs > generally end up being testing with something in the order of tens > of minutes worth of audio. In *addition* to that kind of testing, > Opus also had automated testing with hundreds of years worth of > audio. If anything, I think other SDOs should learn something here. >>> >>> This may very well be true. I guess this comes down to how much >>> you trust that the quality assessment models (e.g. PEAQ, POLQA) >>> give the same result as human test subjects would. But I think >>> this sounds like a really good thing. >>> > > Jean-Marc > >>> >> >> _______________________________________________ rtcweb mailing >> list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From mandyam@quicinc.com Thu Aug 30 12:13:11 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1272F21F84EC for ; Thu, 30 Aug 2012 12:13:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.859 X-Spam-Level: X-Spam-Status: No, score=-5.859 tagged_above=-999 required=5 tests=[AWL=0.740, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id abMKbGlZ6CQK for ; Thu, 30 Aug 2012 12:13:10 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by ietfa.amsl.com (Postfix) with ESMTP id 17F3121F84D2 for ; Thu, 30 Aug 2012 12:13:09 -0700 (PDT) X-IronPort-AV: E=McAfee;i="5400,1158,6820"; a="231318519" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by wolverine01.qualcomm.com with ESMTP; 30 Aug 2012 12:13:07 -0700 X-IronPort-AV: E=Sophos;i="4.80,342,1344236400"; d="scan'208";a="322454855" Received: from nasanexhc06.na.qualcomm.com ([172.30.48.21]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 30 Aug 2012 12:13:07 -0700 Received: from NASANEXHC15.na.qualcomm.com (172.30.48.1) by nasanexhc06.na.qualcomm.com (172.30.48.21) with Microsoft SMTP Server (TLS) id 14.2.318.1; Thu, 30 Aug 2012 12:13:06 -0700 Received: from NASANEXD01H.na.qualcomm.com ([169.254.8.250]) by nasanexhc15.na.qualcomm.com ([129.46.52.215]) with mapi id 14.02.0309.002; Thu, 30 Aug 2012 12:13:06 -0700 From: "Mandyam, Giridhar" To: Harald Alvestrand , "DRAGE, Keith (Keith)" Thread-Topic: [rtcweb] RTCWEB needs an Internet Codec Thread-Index: AQHNhgORyuEFfQzQ3keG1dHHPO9QYpdypWyAgAAchICAAAO0AP//n3uw Date: Thu, 30 Aug 2012 19:13:06 +0000 Message-ID: References: <503F46C5.2090607@alvestrand.no> <503F61CC.1010709@alvestrand.no> In-Reply-To: <503F61CC.1010709@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.30.48.1] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] RTCWEB needs an Internet Codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 30 Aug 2012 19:13:11 -0000 Hello Harald, Can you clarify this viewpoint? If we use the criterion that any MTI codec= has to be suitable for all use cases as currently documented, then it seem= s neither Opus nor G.711 can suffice. =20 For instance, use case 4.2.7 - "... the user's provider of cellular access = has QoS support enabled. The user is able to take advantage of the QoS sup= port both when accessing via the residential router and when using cellular= ." If the guaranteed bit rate (GBR, part of the QoS Class Indicator in 3GP= P defined networks) falls outside of the operating range where Opus is the = best performing codec (e.g. the sub-8kbps part of the 'Quality vs Bitrate' = curve in http://www.opus-codec.org/comparison/), another codec would be req= uired. The study available at http://research.nokia.com/files/public/%5B16%5D_Inte= rSpeech2011_Voice_Quality_Characterization_of_IETF_Opus_Codec.pdf clearly s= hows a significant advantage in MOS scores at 5.9 kbps for AMR-NB as compa= red to Opus (Silk). The initial conclusion from my end is that using Opus = when cellular QoS support results in a guaranteed bit rate less than 8 kbps= would not result in the user being "able to take advantage of the QoS supp= ort" as per the use case. I think we shouldn't try to mandate codecs to try to cover every single use= case. Rather we should mandate as few as necessary to avoid codec negotia= tion failure. -Giri -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= Harald Alvestrand Sent: Thursday, August 30, 2012 5:51 AM To: DRAGE, Keith (Keith) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] RTCWEB needs an Internet Codec On 08/30/2012 02:38 PM, DRAGE, Keith (Keith) wrote: > Surely that argument extends to every possible codec. The set of MTI codecs should cover the set of use cases that have been iden= tified. Additional MTI codecs that don't cover new use cases shouldn't be added. I believe the use case "distributed music band" in draft-ietf-rtcweb-use-ca= ses-and-requirements can't be satisified with G.711. > > If the codecs supported by both endpoints do not supply the characteristi= cs needed for the communication, then you will get interoperability failure= . > > If I want more bandwidth or quality than OPUS supplies, then I will also = get interoperability failure. > > Keith > >> -----Original Message----- >> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On=20 >> Behalf Of Harald Alvestrand >> Sent: 30 August 2012 11:56 >> To: rtcweb@ietf.org >> Subject: Re: [rtcweb] RTCWEB needs an Internet Codec >> >> The counterpoint is that having G.711 as the only MTI means that you=20 >> get interoperability failure for any application in which G.711 sound=20 >> quality is not acceptable. >> >> This includes all applications involving music. >> >> On 08/29/2012 06:30 PM, Randall Gellens wrote: >>> At 12:13 AM -0400 8/29/12, Roman Shpount wrote: >>> >>>> I would argue G.711 should be the MTI codec. The rest can be left=20 >>>> up to browser implementers. >>> I agree. >>> >>>> We can argue all we want, but the best royalty free low bitrate=20 >>>> codec available will be the one everybody supports. >>> Very good point, and why we should mandate only one audio codec. >>> >> _______________________________________________ >> 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 From tterriberry@mozilla.com Thu Aug 30 12:32:13 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4910A21F860B for ; Thu, 30 Aug 2012 12:32:13 -0700 (PDT) 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_05=-1.11, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9WLs7DZ21XG8 for ; Thu, 30 Aug 2012 12:32:12 -0700 (PDT) Received: from smtp.mozilla.org (mx1.corp.phx1.mozilla.com [63.245.216.69]) by ietfa.amsl.com (Postfix) with ESMTP id C885C21F8575 for ; Thu, 30 Aug 2012 12:32:12 -0700 (PDT) Received: from [172.16.1.197] (LRouen-152-83-11-227.w80-13.abo.wanadoo.fr [80.13.74.227]) (Authenticated sender: tterriberry@mozilla.com) by mx1.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 27126F25B8 for ; Thu, 30 Aug 2012 12:32:09 -0700 (PDT) Message-ID: <503FBFB8.30509@mozilla.com> Date: Thu, 30 Aug 2012 12:32:08 -0700 From: "Timothy B. Terriberry" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120625 SeaMonkey/2.10.1 MIME-Version: 1.0 To: "rtcweb@ietf.org" References: <9E2843EA-EBB9-40B3-898C-6B5216FAE7A5@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Confirmation of consensus on audio codecs X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 30 Aug 2012 19:32:13 -0000 Neil Stratford wrote: > G.711 alone does not meet the rtcweb goal of producing a viable > alternative to browser plugins as it will be impossible for an > application developer to guarantee an acceptable audio quality > (defined as at least as good as when using plugins) for browser to > browser calls. And, for those who do not know, this is what plugins are capable of today: https://plus.google.com/u/0/117107600391040942348/posts/ZYw4j21RjUL From jmvalin@mozilla.com Thu Aug 30 12:40:16 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E72321F859C for ; Thu, 30 Aug 2012 12:40:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SqkQ6RHJ+E4y for ; Thu, 30 Aug 2012 12:40:15 -0700 (PDT) Received: from smtp.mozilla.org (mx1.corp.phx1.mozilla.com [63.245.216.69]) by ietfa.amsl.com (Postfix) with ESMTP id AA5AA21F8599 for ; Thu, 30 Aug 2012 12:40:15 -0700 (PDT) Received: from [192.168.1.14] (modemcable094.20-21-96.mc.videotron.ca [96.21.20.94]) (Authenticated sender: jvalin@mozilla.com) by mx1.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id C09D3F2695; Thu, 30 Aug 2012 12:40:14 -0700 (PDT) Message-ID: <503FC188.5050003@mozilla.com> Date: Thu, 30 Aug 2012 15:39:52 -0400 From: Jean-Marc Valin User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: "Mandyam, Giridhar" References: <503F46C5.2090607@alvestrand.no> <503F61CC.1010709@alvestrand.no> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] RTCWEB needs an Internet Codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 30 Aug 2012 19:40:16 -0000 On 12-08-30 03:13 PM, Mandyam, Giridhar wrote: > The study available at > http://research.nokia.com/files/public/%5B16%5D_InterSpeech2011_Voice_Quality_Characterization_of_IETF_Opus_Codec.pdf > clearly shows a significant advantage in MOS scores at 5.9 kbps for > AMR-NB as compared to Opus (Silk). The initial conclusion from my > end is that using Opus when cellular QoS support results in a > guaranteed bit rate less than 8 kbps would not result in the user > being "able to take advantage of the QoS support" as per the use > case. So because Opus is better except around 6 kb/s means that we have negotiation failure and that we should instead use G.711 at 64 kb/s? Also, keep in mind that browser-to-browser means RTP, which typically means 16 kb/s worth of overhead anyway (with 20 ms frames). Even though Opus is not optimal at 6 kb/s, we still have something that works and we avoid interop failure. And what are the alternatives anyway? If we only decide on G.711, then we not only have embarrassingly bad quality, but we also have interop failure below 64 kb/s. If you want guaranteed good quality without Opus, you can also make AMR-NB, AMR-WB, G.722.1C, AAC-LD, HE-AAC, and AAC-LC all MTI. Then you'll have (on average) quality that's almost as good as Opus alone can do, you'll cover almost as many use cases, and as a bonus, you get all the negotiation and switching nightmares involved. Jean-Marc > -----Original Message----- From: rtcweb-bounces@ietf.org > [mailto:rtcweb-bounces@ietf.org] On Behalf Of Harald Alvestrand Sent: > Thursday, August 30, 2012 5:51 AM To: DRAGE, Keith (Keith) Cc: > rtcweb@ietf.org Subject: Re: [rtcweb] RTCWEB needs an Internet Codec > > On 08/30/2012 02:38 PM, DRAGE, Keith (Keith) wrote: >> Surely that argument extends to every possible codec. > The set of MTI codecs should cover the set of use cases that have > been identified. Additional MTI codecs that don't cover new use cases > shouldn't be added. > > I believe the use case "distributed music band" in > draft-ietf-rtcweb-use-cases-and-requirements can't be satisified with > G.711. > >> >> If the codecs supported by both endpoints do not supply the >> characteristics needed for the communication, then you will get >> interoperability failure. >> >> If I want more bandwidth or quality than OPUS supplies, then I will >> also get interoperability failure. >> >> Keith >> >>> -----Original Message----- From: rtcweb-bounces@ietf.org >>> [mailto:rtcweb-bounces@ietf.org] On Behalf Of Harald Alvestrand >>> Sent: 30 August 2012 11:56 To: rtcweb@ietf.org Subject: Re: >>> [rtcweb] RTCWEB needs an Internet Codec >>> >>> The counterpoint is that having G.711 as the only MTI means that >>> you get interoperability failure for any application in which >>> G.711 sound quality is not acceptable. >>> >>> This includes all applications involving music. >>> >>> On 08/29/2012 06:30 PM, Randall Gellens wrote: >>>> At 12:13 AM -0400 8/29/12, Roman Shpount wrote: >>>> >>>>> I would argue G.711 should be the MTI codec. The rest can be >>>>> left up to browser implementers. >>>> I agree. >>>> >>>>> We can argue all we want, but the best royalty free low >>>>> bitrate codec available will be the one everybody supports. >>>> Very good point, and why we should mandate only one audio >>>> codec. >>>> >>> _______________________________________________ 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 > _______________________________________________ rtcweb mailing list > rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb > From harald@alvestrand.no Thu Aug 30 12:41:26 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE6E221F85A4 for ; Thu, 30 Aug 2012 12:41:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.069 X-Spam-Level: X-Spam-Status: No, score=-110.069 tagged_above=-999 required=5 tests=[AWL=-0.070, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VXwE3VrVPNEZ for ; Thu, 30 Aug 2012 12:41:25 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 9BA2221F859C for ; Thu, 30 Aug 2012 12:41:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3F42739E2BE; Thu, 30 Aug 2012 21:40:50 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5VG76N1gErLi; Thu, 30 Aug 2012 21:40:48 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:be30:5bff:fede:bcdc]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 72AB439E170; Thu, 30 Aug 2012 21:40:48 +0200 (CEST) Message-ID: <503FC1BF.5020004@alvestrand.no> Date: Thu, 30 Aug 2012 21:40:47 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: "Mandyam, Giridhar" References: <503F46C5.2090607@alvestrand.no> <503F61CC.1010709@alvestrand.no> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] RTCWEB needs an Internet Codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 30 Aug 2012 19:41:26 -0000 On 08/30/2012 09:13 PM, Mandyam, Giridhar wrote: > Hello Harald, > Can you clarify this viewpoint? If we use the criterion that any MTI codec has to be suitable for all use cases as currently documented, then it seems neither Opus nor G.711 can suffice. That's not what I said. I said that the *set* of MTI codecs should cover the use cases. We have a requirement (F21) that explicitly mentions commonly supported codecs in telephony services; there's no way Opus can cover that case. > > > For instance, use case 4.2.7 - "... the user's provider of cellular access has QoS support enabled. The user is able to take advantage of the QoS support both when accessing via the residential router and when using cellular." You're not reading the latest draft. That section is now 4.2.6. > If the guaranteed bit rate (GBR, part of the QoS Class Indicator in 3GPP defined networks) falls outside of the operating range where Opus is the best performing codec (e.g. the sub-8kbps part of the 'Quality vs Bitrate' curve in http://www.opus-codec.org/comparison/), another codec would be required. Section 4.1 of the draft defines "narrowband" to be "10s to 100s of Kbits/sec". > > The study available at http://research.nokia.com/files/public/%5B16%5D_InterSpeech2011_Voice_Quality_Characterization_of_IETF_Opus_Codec.pdf clearly shows a significant advantage in MOS scores at 5.9 kbps for AMR-NB as compared to Opus (Silk). Respectfully ..... the slight advantage in quality that AMR-NB seems to offer over Opus at 8 kbps is very different from the advantage that Opus enjoys over G.711 at 64 Kbits and above. > The initial conclusion from my end is that using Opus when cellular QoS support results in a guaranteed bit rate less than 8 kbps would not result in the user being "able to take advantage of the QoS support" as per the use case. Neither does it cover the case where there's not enough bits to carry an IP+RTP header every 20 milliseconds. There are cases where WebRTC won't work. > > I think we shouldn't try to mandate codecs to try to cover every single use case. Rather we should mandate as few as necessary to avoid codec negotiation failure. Yes. And failure to negotiate an usable codec is a negotiation failure. > > -Giri > > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Harald Alvestrand > Sent: Thursday, August 30, 2012 5:51 AM > To: DRAGE, Keith (Keith) > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] RTCWEB needs an Internet Codec > > On 08/30/2012 02:38 PM, DRAGE, Keith (Keith) wrote: >> Surely that argument extends to every possible codec. > The set of MTI codecs should cover the set of use cases that have been identified. > Additional MTI codecs that don't cover new use cases shouldn't be added. > > I believe the use case "distributed music band" in draft-ietf-rtcweb-use-cases-and-requirements can't be satisified with G.711. > >> If the codecs supported by both endpoints do not supply the characteristics needed for the communication, then you will get interoperability failure. >> >> If I want more bandwidth or quality than OPUS supplies, then I will also get interoperability failure. >> >> Keith >> >>> -----Original Message----- >>> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On >>> Behalf Of Harald Alvestrand >>> Sent: 30 August 2012 11:56 >>> To: rtcweb@ietf.org >>> Subject: Re: [rtcweb] RTCWEB needs an Internet Codec >>> >>> The counterpoint is that having G.711 as the only MTI means that you >>> get interoperability failure for any application in which G.711 sound >>> quality is not acceptable. >>> >>> This includes all applications involving music. >>> >>> On 08/29/2012 06:30 PM, Randall Gellens wrote: >>>> At 12:13 AM -0400 8/29/12, Roman Shpount wrote: >>>> >>>>> I would argue G.711 should be the MTI codec. The rest can be left >>>>> up to browser implementers. >>>> I agree. >>>> >>>>> We can argue all we want, but the best royalty free low bitrate >>>>> codec available will be the one everybody supports. >>>> Very good point, and why we should mandate only one audio codec. >>>> >>> _______________________________________________ >>> 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 From richard.ejzak@alcatel-lucent.com Thu Aug 30 13:07:55 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12A8C21F8497 for ; Thu, 30 Aug 2012 13:07:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.902 X-Spam-Level: X-Spam-Status: No, score=-7.902 tagged_above=-999 required=5 tests=[AWL=-1.653, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JcuhDiZTWiEO for ; Thu, 30 Aug 2012 13:07:54 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [62.23.212.57]) by ietfa.amsl.com (Postfix) with ESMTP id 1B5FB21F848F for ; Thu, 30 Aug 2012 13:07:53 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q7UK7bSU008128 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Thu, 30 Aug 2012 22:07:50 +0200 Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (135.5.2.36) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (135.120.45.63) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 30 Aug 2012 22:07:47 +0200 Received: from US70UWXCHMBA04.zam.alcatel-lucent.com ([169.254.12.110]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.02.0247.003; Thu, 30 Aug 2012 16:07:44 -0400 From: "Ejzak, Richard P (Richard)" To: "rtcweb@ietf.org" Thread-Topic: [rtcweb] H.264 SVC and BUNDLE Thread-Index: AQHNhhfAiyhaIO3vJU6HglhL+lp/Z5dxo1QAgAEeYkA= Date: Thu, 30 Aug 2012 20:07:40 +0000 Message-ID: <03FBA798AC24E3498B74F47FD082A92F177393B8@US70UWXCHMBA04.zam.alcatel-lucent.com> References: <503E0B63.3020708@ericsson.com>, <7F2072F1E0DE894DA4B517B93C6A05853409FF2F4C@ESESSCMS0356.eemea.ericsson.se> <035101cd8636$3b654160$b22fc420$@com> In-Reply-To: <035101cd8636$3b654160$b22fc420$@com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 Subject: Re: [rtcweb] H.264 SVC and BUNDLE X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 30 Aug 2012 20:07:55 -0000 Dan Wing wrote: > The general multiplexing of layers onto the same 5-tuple is a problem, > *if* we want the layers to have different DSCP values. This is because > we cannot successfully and reliably set different DSCP values for packets > belonging to a 5-tuple over the Internet -- too many things rewrite > the DSCP field (to a different value) or simply clear the DSCP field. > This makes it impossible to restore the per-packet DSCP values later > (e.g., using RSVP, or using any other better/stronger/faster signaling > method). If, however, each 5-tuple has its own DSCP value then that > DSCP value could be restored. Dan, You make a claim that is not necessarily true. If packets within a 5-tuple= have different DSCP values that are then erased by the network, why would = it be "impossible" to restore those values later? Within the context of mu= ltiplexing of RTP streams, each RTP stream within a 5-tuple would of necess= ity need to still use a single DSCP value. If signaling can be used to inf= orm a node of some means of identifying each RTP stream then the original D= SCP markings could be restored. While I agree that it would be easier to assign the same DSCP value to all = packets in a 5-tuple, it would still be "possible" to filter on, for exampl= e, the SSRC value used for each stream (in addition to the 5-tuple) to reas= sign the original DSCP value (or a mapped value with appropriate meaning in= the target network) for each stream. Richard From harald@alvestrand.no Thu Aug 30 13:19:15 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5361A21F84C2 for ; Thu, 30 Aug 2012 13:19:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.367 X-Spam-Level: X-Spam-Status: No, score=-110.367 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6AoEiFbAixeR for ; Thu, 30 Aug 2012 13:19:14 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 8349C21F8495 for ; Thu, 30 Aug 2012 13:19:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9DC3239E2BE for ; Thu, 30 Aug 2012 22:18:43 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pdza4PMjjXWV for ; Thu, 30 Aug 2012 22:18:42 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:be30:5bff:fede:bcdc]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id EF0A539E170 for ; Thu, 30 Aug 2012 22:18:41 +0200 (CEST) Message-ID: <503FCAA1.5080500@alvestrand.no> Date: Thu, 30 Aug 2012 22:18:41 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <503E0B63.3020708@ericsson.com>, <7F2072F1E0DE894DA4B517B93C6A05853409FF2F4C@ESESSCMS0356.eemea.ericsson.se> <035101cd8636$3b654160$b22fc420$@com> <03FBA798AC24E3498B74F47FD082A92F177393B8@US70UWXCHMBA04.zam.alcatel-lucent.com> In-Reply-To: <03FBA798AC24E3498B74F47FD082A92F177393B8@US70UWXCHMBA04.zam.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] H.264 SVC and BUNDLE X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 30 Aug 2012 20:19:15 -0000 My assumption has always been that if you were operating on a network that could only apply diffserv to separate 5-tuples, you would allocate the SSRCs comprising a multilayer encoding to different 5-tuples. If you were operating on a network that preserved DSCP values, or on one that did stateful resource reservation based on SSRC values, you would be able to use the same 5-tuple, if desirable. This choice seems to be a choice that the application writer should take before deciding whether or not to use BUNDLE, so it's a little hard to see what the relationship to BUNDLE is. One size does not fit all. Sometimes bundling is not what people want to do. On 08/30/2012 10:07 PM, Ejzak, Richard P (Richard) wrote: > Dan Wing wrote: >> The general multiplexing of layers onto the same 5-tuple is a problem, >> *if* we want the layers to have different DSCP values. This is because >> we cannot successfully and reliably set different DSCP values for packets >> belonging to a 5-tuple over the Internet -- too many things rewrite >> the DSCP field (to a different value) or simply clear the DSCP field. >> This makes it impossible to restore the per-packet DSCP values later >> (e.g., using RSVP, or using any other better/stronger/faster signaling >> method). If, however, each 5-tuple has its own DSCP value then that >> DSCP value could be restored. > Dan, > You make a claim that is not necessarily true. If packets within a 5-tuple have different DSCP values that are then erased by the network, why would it be "impossible" to restore those values later? Within the context of multiplexing of RTP streams, each RTP stream within a 5-tuple would of necessity need to still use a single DSCP value. If signaling can be used to inform a node of some means of identifying each RTP stream then the original DSCP markings could be restored. > > While I agree that it would be easier to assign the same DSCP value to all packets in a 5-tuple, it would still be "possible" to filter on, for example, the SSRC value used for each stream (in addition to the 5-tuple) to reassign the original DSCP value (or a mapped value with appropriate meaning in the target network) for each stream. > > Richard > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From jmvalin@mozilla.com Thu Aug 30 13:24:05 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1660F21F8585 for ; Thu, 30 Aug 2012 13:24:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hq1IPgfMdvCl for ; Thu, 30 Aug 2012 13:24:00 -0700 (PDT) Received: from smtp.mozilla.org (mx1.corp.phx1.mozilla.com [63.245.216.69]) by ietfa.amsl.com (Postfix) with ESMTP id 7109821F857D for ; Thu, 30 Aug 2012 13:24:00 -0700 (PDT) Received: from [192.168.1.14] (modemcable094.20-21-96.mc.videotron.ca [96.21.20.94]) (Authenticated sender: jvalin@mozilla.com) by mx1.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 96DEBF22EB; Thu, 30 Aug 2012 13:23:59 -0700 (PDT) Message-ID: <503FCBC8.40506@mozilla.com> Date: Thu, 30 Aug 2012 16:23:36 -0400 From: Jean-Marc Valin User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: "DRAGE, Keith (Keith)" References: <503F46C5.2090607@alvestrand.no> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] RTCWEB needs an Internet Codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 30 Aug 2012 20:24:05 -0000 On 12-08-30 08:38 AM, DRAGE, Keith (Keith) wrote: > If the codecs supported by both endpoints do not supply the > characteristics needed for the communication, then you will get > interoperability failure. > > If I want more bandwidth or quality than OPUS supplies, then I will > also get interoperability failure. Care to provide an example of use case to which Opus does not scale? It starts from about 6 kb/s, which is certainly low enough (and far less than the RTP overhead anyway). From there, it can scale to 512 kb/s stereo, which is more than twice as much as the highest bitrate at which anyone was ever able to ABX the coded audio against the original. There's also multi-channel (>2) mappings if needed. Well, we don't cover dogs, but I think I can live with that. Jean-Marc > Keith > >> -----Original Message----- From: rtcweb-bounces@ietf.org >> [mailto:rtcweb-bounces@ietf.org] On Behalf Of Harald Alvestrand >> Sent: 30 August 2012 11:56 To: rtcweb@ietf.org Subject: Re: >> [rtcweb] RTCWEB needs an Internet Codec >> >> The counterpoint is that having G.711 as the only MTI means that >> you get interoperability failure for any application in which G.711 >> sound quality is not acceptable. >> >> This includes all applications involving music. >> >> On 08/29/2012 06:30 PM, Randall Gellens wrote: >>> At 12:13 AM -0400 8/29/12, Roman Shpount wrote: >>> >>>> I would argue G.711 should be the MTI codec. The rest can be >>>> left up to browser implementers. >>> >>> I agree. >>> >>>> We can argue all we want, but the best royalty free low >>>> bitrate codec available will be the one everybody supports. >>> >>> Very good point, and why we should mandate only one audio codec. >>> >> >> _______________________________________________ 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 > From gmaxwell@juniper.net Thu Aug 30 13:59:24 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2911B21F8552 for ; Thu, 30 Aug 2012 13:59:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aG8RRhEBYVi2 for ; Thu, 30 Aug 2012 13:59:23 -0700 (PDT) Received: from exprod7og115.obsmtp.com (exprod7og115.obsmtp.com [64.18.2.217]) by ietfa.amsl.com (Postfix) with ESMTP id 8D0CD21F854F for ; Thu, 30 Aug 2012 13:59:23 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP ID DSNKUD/UKXF44qlwEEUnj6w2zwr6UJ8id1q3@postini.com; Thu, 30 Aug 2012 13:59:23 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([fe80::3c95:ce07:f642:ecd2%10]) with mapi; Thu, 30 Aug 2012 13:58:41 -0700 From: Gregory Maxwell To: Jean-Marc Valin , "DRAGE, Keith (Keith)" Date: Thu, 30 Aug 2012 13:58:41 -0700 Thread-Topic: [rtcweb] RTCWEB needs an Internet Codec Thread-Index: Ac2G7W5wEXrQSmc+SRKB5FW1h9UBqQAA0j35 Message-ID: References: <503F46C5.2090607@alvestrand.no> , <503FCBC8.40506@mozilla.com> In-Reply-To: <503FCBC8.40506@mozilla.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] RTCWEB needs an Internet Codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 30 Aug 2012 20:59:24 -0000 Jean-Marc Valin [jmvalin@mozilla.com] wrote: > Well, we don't cover > dogs, but I think I can live with that. But on the internet no one can tell you're a dog. Fortunately preserving the anonymity of dogs was not an enumerated applicat= ion. Including Opus as MTI should be the most straightforward way to ensure inte= roperability for all the enumerated applications, and covering the space of= human perception is also important for all the ones the working group inev= itably forgot to enumerate. Codecs are boring. It's important to have good infrastructure uniformly ava= ilable so that the authors of applications that will build on the browsers = that implement rtcweb won't have to worry about codecs and can spend their = attention on the real innovation that will happen on top of this low level = infrastructure.= From bernard_aboba@hotmail.com Thu Aug 30 14:19:24 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB1F421F8516 for ; Thu, 30 Aug 2012 14:19:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.373 X-Spam-Level: X-Spam-Status: No, score=-102.373 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sQWqLcIGA45a for ; Thu, 30 Aug 2012 14:19:24 -0700 (PDT) Received: from blu0-omc1-s1.blu0.hotmail.com (blu0-omc1-s1.blu0.hotmail.com [65.55.116.12]) by ietfa.amsl.com (Postfix) with ESMTP id F238221F8513 for ; Thu, 30 Aug 2012 14:19:23 -0700 (PDT) Received: from BLU002-W21 ([65.55.116.9]) by blu0-omc1-s1.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 30 Aug 2012 14:19:21 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_4617ccfe-a700-48b7-989b-165a0b84ff40_" X-Originating-IP: [24.16.96.166] From: Bernard Aboba To: Harald Alvestrand Date: Thu, 30 Aug 2012 14:19:21 -0700 Importance: Normal In-Reply-To: <503FCAA1.5080500@alvestrand.no> References: <503E0B63.3020708@ericsson.com>, , , <7F2072F1E0DE894DA4B517B93C6A05853409FF2F4C@ESESSCMS0356.eemea.ericsson.se>, <035101cd8636$3b654160$b22fc420$@com>, <03FBA798AC24E3498B74F47FD082A92F177393B8@US70UWXCHMBA04.zam.alcatel-lucent.com>, <503FCAA1.5080500@alvestrand.no> MIME-Version: 1.0 X-OriginalArrivalTime: 30 Aug 2012 21:19:21.0656 (UTC) FILETIME=[1F762B80:01CD86F5] Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] H.264 SVC and BUNDLE X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 30 Aug 2012 21:19:24 -0000 --_4617ccfe-a700-48b7-989b-165a0b84ff40_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Harald said:=20 > My assumption has always been that if you were operating on a network=20 > that could only apply diffserv to separate 5-tuples=2C you would allocate= =20 > the SSRCs comprising a multilayer encoding to different 5-tuples. [BA] RFC 6190 Section 1 says: This memo defines two basic modes for transmission of SVC data=2C=0A= single-session transmission (SST) and multi-session transmission=0A= (MST). In SST=2C a single RTP session is used for the transmission of= =0A= all scalability layers comprising an SVC bitstream=3B in MST=2C the=0A= scalability layers are transported on different RTP sessions. =20 [BA] So it is possible either to use multiple 5-tuples (MST) or a single 5-= tuple (SST). However=2C my understanding=20 is that the SST approach is more popular than MST.=20 > This choice seems to be a choice that the application writer should take= =20 > before deciding whether or not to use BUNDLE=2C so it's a little hard to= =20 > see what the relationship to BUNDLE is. [BA] The open question has been how to indicate the desire for both layered= coding and BUNDLE in SDP=2C=20 given the backward compatibility issues we have talked about. For example= =2C if it is desired to do SST and BUNDLE=2C do you signal MST and BUNDLE on different ports in the offer and = then if SST and BUNDLE are supported by the answer=2C have the answer respond with BUNDLE as well as d= ependency groups using=20 the same port? That would seem to imply an assumption that every MST imple= mentation can also do SST. =20 Or do do you signal SST and BUNDLE on the same port=2C and then if the resp= onse indicates that the SDP was rejected=2C formulate an alternative offer (MST with BUNDLE? H.264/AVC= with BUNDLE?=20 SST without BUNDLE??) =20 > One size does not fit all. Sometimes bundling is not what people want to = do. [BA] Or sometimes it is=2C but implementations might not be clear how to ne= gotiate it :) = --_4617ccfe-a700-48b7-989b-165a0b84ff40_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Harald said:

>=3B= My assumption has always been that if you were operating on a network
= >=3B that could only apply diffserv to separate 5-tuples=2C you would all= ocate
>=3B the SSRCs comprising a multilayer encoding to different 5-= tuples.

[BA] RFC 6190 Section 1 says:

=
   This memo defines two basic modes for transmission of SVC data=2C=0A=
   single-session transmission (SST) and multi-session transmission=0A=
   (MST).  In SST=2C a single RTP session is used for the transmission of=
=0A=
   all scalability layers comprising an SVC bitstream=3B in MST=2C the=0A=
   scalability layers are transported on different RTP sessions.
[BA] So it is possible either to use multiple 5-tuples (MST) or a single 5= -tuple (SST). =3B However=2C my understanding
is that the SST appro= ach is more popular than MST.

>=3B This choice seems to be a choi= ce that the application writer should take
>=3B before deciding wheth= er or not to use BUNDLE=2C so it's a little hard to
>=3B see what the= relationship to BUNDLE is.

[BA] The open question has been how to i= ndicate the desire for both layered coding and BUNDLE in SDP=2C
given t= he backward compatibility issues we have talked about. =3B For example= =2C if it is desired to do SST and
BUNDLE=2C do you signal MST and BUNDL= E on different ports in the offer and then if SST and BUNDLE are
support= ed by the answer=2C have the answer respond with BUNDLE as well as dependen= cy groups using
the same port? =3B That would seem to imply an assu= mption that every MST implementation can also do SST. =3B
Or do do = you signal SST and BUNDLE on the same port=2C and then if the response indi= cates that the SDP
was rejected=2C formulate an alternative offer (MST w= ith BUNDLE? =3B H.264/AVC with BUNDLE?
SST without BUNDLE??) = =3B

>=3B One size does not fit all. Sometimes bundling is not wha= t people want to do.

[BA] Or sometimes it is=2C but implementations = might not be clear how to negotiate it :)


= --_4617ccfe-a700-48b7-989b-165a0b84ff40_-- From harald@alvestrand.no Thu Aug 30 14:31:18 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5487921F8526 for ; Thu, 30 Aug 2012 14:31:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.299 X-Spam-Level: X-Spam-Status: No, score=-110.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p2ZEpkBjbHgN for ; Thu, 30 Aug 2012 14:31:17 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 194E421F851B for ; Thu, 30 Aug 2012 14:31:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id BA14739E170; Thu, 30 Aug 2012 23:31:14 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qj7ddQgrBxvE; Thu, 30 Aug 2012 23:31:13 +0200 (CEST) Received: from [192.168.11.193] (c-56fbe555.03-217-73746f1.cust.bredbandsbolaget.se [85.229.251.86]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id AC94039E125; Thu, 30 Aug 2012 23:31:13 +0200 (CEST) Message-ID: <503FDBA1.9000003@alvestrand.no> Date: Thu, 30 Aug 2012 23:31:13 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: Bernard Aboba References: <503E0B63.3020708@ericsson.com>, , , <7F2072F1E0DE894DA4B517B93C6A05853409FF2F4C@ESESSCMS0356.eemea.ericsson.se>, <035101cd8636$3b654160$b22fc420$@com>, <03FBA798AC24E3498B74F47FD082A92F177393B8@US70UWXCHMBA04.zam.alcatel-lucent.com>, <503FCAA1.5080500@alvestrand.no> In-Reply-To: Content-Type: multipart/alternative; boundary="------------020601060207030902090407" Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] H.264 SVC and BUNDLE X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 30 Aug 2012 21:31:18 -0000 This is a multi-part message in MIME format. --------------020601060207030902090407 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 08/30/2012 11:19 PM, Bernard Aboba wrote: > Harald said: > > > My assumption has always been that if you were operating on a network > > that could only apply diffserv to separate 5-tuples, you would allocate > > the SSRCs comprising a multilayer encoding to different 5-tuples. > > [BA] RFC 6190 Section 1 says: > > This memo defines two basic modes for transmission of SVC data, > single-session transmission (SST) and multi-session transmission > (MST). In SST, a single RTP session is used for the transmission of > all scalability layers comprising an SVC bitstream; in MST, the > scalability layers are transported on different RTP sessions. > > [BA] So it is possible either to use multiple 5-tuples (MST) or a > single 5-tuple (SST). However, my understanding > is that the SST approach is more popular than MST. > > > This choice seems to be a choice that the application writer should > take > > before deciding whether or not to use BUNDLE, so it's a little hard to > > see what the relationship to BUNDLE is. > > [BA] The open question has been how to indicate the desire for both > layered coding and BUNDLE in SDP, > given the backward compatibility issues we have talked about. For > example, if it is desired to do SST and > BUNDLE, do you signal MST and BUNDLE on different ports in the offer > and then if SST and BUNDLE are > supported by the answer, have the answer respond with BUNDLE as well > as dependency groups using > the same port? That would seem to imply an assumption that every MST > implementation can also do SST. > Or do do you signal SST and BUNDLE on the same port, and then if the > response indicates that the SDP > was rejected, formulate an alternative offer (MST with BUNDLE? > H.264/AVC with BUNDLE? > SST without BUNDLE??) I lack the background to think about this... in existing equipment, if you want to do SST, but would be willing to do MST if the other end did not support SST, how would your offer look (without BUNDLE)? My head hurts a little when trying to guess, but from your question it sounds like you've done it, so it's better if you just paste an example. (BTW, this is really an MMUSIC discussion) --------------020601060207030902090407 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 08/30/2012 11:19 PM, Bernard Aboba wrote:
Harald said:

> My assumption has always been that if you were operating on a network
> that could only apply diffserv to separate 5-tuples, you would allocate
> the SSRCs comprising a multilayer encoding to different 5-tuples.

[BA] RFC 6190 Section 1 says:

   This memo defines two basic modes for transmission of SVC data,
   single-session transmission (SST) and multi-session transmission
   (MST).  In SST, a single RTP session is used for the transmission of
   all scalability layers comprising an SVC bitstream; in MST, the
   scalability layers are transported on different RTP sessions.

[BA] So it is possible either to use multiple 5-tuples (MST) or a single 5-tuple (SST).  However, my understanding
is that the SST approach is more popular than MST.

> This choice seems to be a choice that the application writer should take
> before deciding whether or not to use BUNDLE, so it's a little hard to
> see what the relationship to BUNDLE is.

[BA] The open question has been how to indicate the desire for both layered coding and BUNDLE in SDP,
given the backward compatibility issues we have talked about.  For example, if it is desired to do SST and
BUNDLE, do you signal MST and BUNDLE on different ports in the offer and then if SST and BUNDLE are
supported by the answer, have the answer respond with BUNDLE as well as dependency groups using
the same port?  That would seem to imply an assumption that every MST implementation can also do SST. 
Or do do you signal SST and BUNDLE on the same port, and then if the response indicates that the SDP
was rejected, formulate an alternative offer (MST with BUNDLE?  H.264/AVC with BUNDLE?
SST without BUNDLE??) 
I lack the background to think about this... in existing equipment, if you want to do SST, but would be willing to do MST if the other end did not support SST, how would your offer look (without BUNDLE)?

My head hurts a little when trying to guess, but from your question it sounds like you've done it, so it's better if you just paste an example.

(BTW, this is really an MMUSIC discussion)

--------------020601060207030902090407-- From mandyam@quicinc.com Thu Aug 30 17:18:31 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E98F11E80D5 for ; Thu, 30 Aug 2012 17:18:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.916 X-Spam-Level: X-Spam-Status: No, score=-5.916 tagged_above=-999 required=5 tests=[AWL=0.683, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BUZYlEOfJ757 for ; Thu, 30 Aug 2012 17:18:30 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id 017EA11E80A2 for ; Thu, 30 Aug 2012 17:18:29 -0700 (PDT) X-IronPort-AV: E=McAfee;i="5400,1158,6820"; a="229143444" Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by wolverine02.qualcomm.com with ESMTP; 30 Aug 2012 17:18:29 -0700 X-IronPort-AV: E=Sophos;i="4.80,344,1344236400"; d="scan'208";a="292449621" Received: from nasanexhc12.na.qualcomm.com ([172.30.39.187]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 30 Aug 2012 17:18:29 -0700 Received: from NASANEXD01H.na.qualcomm.com ([169.254.8.250]) by nasanexhc12.na.qualcomm.com ([172.30.39.187]) with mapi id 14.02.0318.001; Thu, 30 Aug 2012 17:18:29 -0700 From: "Mandyam, Giridhar" To: Jean-Marc Valin Thread-Topic: [rtcweb] RTCWEB needs an Internet Codec Thread-Index: AQHNhgORyuEFfQzQ3keG1dHHPO9QYpdypWyAgAAchICAAAO0AP//n3uwgADSpQD//6kqkA== Date: Fri, 31 Aug 2012 00:18:28 +0000 Message-ID: References: <503F46C5.2090607@alvestrand.no> <503F61CC.1010709@alvestrand.no> <503FC188.5050003@mozilla.com> In-Reply-To: <503FC188.5050003@mozilla.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.139.227] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] RTCWEB needs an Internet Codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 31 Aug 2012 00:18:31 -0000 > So because Opus is better except around 6 kb/s means that we have negotia= tion failure and that we should instead use G.711 at 64 kb/s? I don't follow. If both parties in the call support a codec suitable for 6 = kb/s (e.g. AMR-NB) then there should be no negotiation failure. MTI still = allows for non-MTI codecs to be used on a WebRTC call. The point I was try= ing to make was that Opus does not satisfy the use case as specified. I ne= ver said that G.711 satisfied this use case. I believe it is unrealistic t= o require that the set of MTI audio codecs (whatever they may be) satisfy e= very single use case as currently outlined. =20 > Also, keep in mind that browser-to-browser means RTP, which typically mea= ns 16 kb/s worth of overhead anyway (with 20 ms frames). All the more reason to achieve toll quality at codec data rates below 8 kbp= s when operating in a cellular environment. Just because there is substant= ial overhead for IP/UDP/RTP when compared to that for a circuit-switched ca= ll does not mean we shouldn't strive for the best quality at the lowest dat= a rate. Keep in mind that there are codecs that exhibit suitable performan= ce at even lower data rates than AMR-NB (e.g. EVRC-B at approximately 4 kbp= s). If we assume Opus has operate at 8 kbps to exhibit suitable voice qual= ity (which still needs to be verified under codec performance testing as pe= r industry standards), that is still a significant increase in required dat= a rate even accounting for the IP/UDP/RTP header overhead. Going from Opus= at approx.. 8 kbps to EVRC-B at approx. 4 kbps gives near 20% savings in r= equired bitrate even when considering 16 kbps overhead. This is a significa= nt savings for cellular access. =20 For any interested parties, EVRC-B characterization tests have been present= ed previously in the 3GPP2, e.g. the document "Characterization Test Report= for EVRC-Release B" (A. Sharpley and I. Panzer, 3GPP2 Document 3GPP2- C11-= 20060327-015, March 27-31, 2006). > If you want guaranteed good quality without Opus, you can also make AMR-N= B, AMR-WB, G.722.1C, AAC-LD, HE-AAC, and AAC-LC all MTI. Then you'll have (= on average) quality that's almost as good as Opus alone can do, you'll cove= r almost as many use cases, and as a bonus, you get all the negotiation and= switching nightmares involved. I've already stated my position on MTI audio codecs on this mailing list. = I never advocated making every codec that is optimal given a particular ope= rating condition as MTI. I also think the performance loss due to the use = of Opus at sub 10 kbps is not trivial, and it is worth leveraging other cod= ecs at these lower data rates.=20 -----Original Message----- From: Jean-Marc Valin [mailto:jmvalin@mozilla.com]=20 Sent: Thursday, August 30, 2012 12:40 PM To: Mandyam, Giridhar Cc: Harald Alvestrand; DRAGE, Keith (Keith); rtcweb@ietf.org Subject: Re: [rtcweb] RTCWEB needs an Internet Codec On 12-08-30 03:13 PM, Mandyam, Giridhar wrote: > The study available at > http://research.nokia.com/files/public/%5B16%5D_InterSpeech2011_Voice_ > Quality_Characterization_of_IETF_Opus_Codec.pdf > clearly shows a significant advantage in MOS scores at 5.9 kbps for=20 > AMR-NB as compared to Opus (Silk). The initial conclusion from my end=20 > is that using Opus when cellular QoS support results in a guaranteed=20 > bit rate less than 8 kbps would not result in the user being "able to=20 > take advantage of the QoS support" as per the use case. So because Opus is better except around 6 kb/s means that we have negotiati= on failure and that we should instead use G.711 at 64 kb/s? Also, keep in mind that browser-to-browser means RTP, which typically means= 16 kb/s worth of overhead anyway (with 20 ms frames). Even though Opus is = not optimal at 6 kb/s, we still have something that works and we avoid inte= rop failure. And what are the alternatives anyway? If we only decide on G.7= 11, then we not only have embarrassingly bad quality, but we also have inte= rop failure below 64 kb/s. If you want guaranteed good quality without Opus= , you can also make AMR-NB, AMR-WB, G.722.1C, AAC-LD, HE-AAC, and AAC-LC al= l MTI. Then you'll have (on average) quality that's almost as good as Opus = alone can do, you'll cover almost as many use cases, and as a bonus, you ge= t all the negotiation and switching nightmares involved. Jean-Marc > -----Original Message----- From: rtcweb-bounces@ietf.org=20 > [mailto:rtcweb-bounces@ietf.org] On Behalf Of Harald Alvestrand Sent: > Thursday, August 30, 2012 5:51 AM To: DRAGE, Keith (Keith) Cc: > rtcweb@ietf.org Subject: Re: [rtcweb] RTCWEB needs an Internet Codec >=20 > On 08/30/2012 02:38 PM, DRAGE, Keith (Keith) wrote: >> Surely that argument extends to every possible codec. > The set of MTI codecs should cover the set of use cases that have been=20 > identified. Additional MTI codecs that don't cover new use cases=20 > shouldn't be added. >=20 > I believe the use case "distributed music band" in=20 > draft-ietf-rtcweb-use-cases-and-requirements can't be satisified with=20 > G.711. >=20 >>=20 >> If the codecs supported by both endpoints do not supply the=20 >> characteristics needed for the communication, then you will get=20 >> interoperability failure. >>=20 >> If I want more bandwidth or quality than OPUS supplies, then I will=20 >> also get interoperability failure. >>=20 >> Keith >>=20 >>> -----Original Message----- From: rtcweb-bounces@ietf.org=20 >>> [mailto:rtcweb-bounces@ietf.org] On Behalf Of Harald Alvestrand >>> Sent: 30 August 2012 11:56 To: rtcweb@ietf.org Subject: Re: >>> [rtcweb] RTCWEB needs an Internet Codec >>>=20 >>> The counterpoint is that having G.711 as the only MTI means that you=20 >>> get interoperability failure for any application in which >>> G.711 sound quality is not acceptable. >>>=20 >>> This includes all applications involving music. >>>=20 >>> On 08/29/2012 06:30 PM, Randall Gellens wrote: >>>> At 12:13 AM -0400 8/29/12, Roman Shpount wrote: >>>>=20 >>>>> I would argue G.711 should be the MTI codec. The rest can be left=20 >>>>> up to browser implementers. >>>> I agree. >>>>=20 >>>>> We can argue all we want, but the best royalty free low bitrate=20 >>>>> codec available will be the one everybody supports. >>>> Very good point, and why we should mandate only one audio codec. >>>>=20 >>> _______________________________________________ rtcweb mailing list=20 >>> rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb >=20 > _______________________________________________ rtcweb mailing list=20 > rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb > _______________________________________________ rtcweb mailing list=20 > rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb >=20 From mandyam@quicinc.com Thu Aug 30 17:20:44 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41F0B11E80D5 for ; Thu, 30 Aug 2012 17:20:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.665 X-Spam-Level: X-Spam-Status: No, score=-5.665 tagged_above=-999 required=5 tests=[AWL=0.334, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hm9j-ai+dY6n for ; Thu, 30 Aug 2012 17:20:38 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by ietfa.amsl.com (Postfix) with ESMTP id 7305411E80A2 for ; Thu, 30 Aug 2012 17:20:38 -0700 (PDT) X-IronPort-AV: E=McAfee;i="5400,1158,6820"; a="231445865" Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by wolverine01.qualcomm.com with ESMTP; 30 Aug 2012 17:20:23 -0700 X-IronPort-AV: E=Sophos;i="4.80,344,1344236400"; d="scan'208";a="317735932" Received: from nasanexhc12.na.qualcomm.com ([172.30.39.187]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 30 Aug 2012 17:20:22 -0700 Received: from NASANEXD01H.na.qualcomm.com ([169.254.8.250]) by nasanexhc12.na.qualcomm.com ([172.30.39.187]) with mapi id 14.02.0318.001; Thu, 30 Aug 2012 17:20:22 -0700 From: "Mandyam, Giridhar" To: Harald Alvestrand Thread-Topic: [rtcweb] RTCWEB needs an Internet Codec Thread-Index: AQHNhgORyuEFfQzQ3keG1dHHPO9QYpdypWyAgAAchICAAAO0AP//n3uwgADS5oD//6CkIA== Date: Fri, 31 Aug 2012 00:20:21 +0000 Message-ID: References: <503F46C5.2090607@alvestrand.no> <503F61CC.1010709@alvestrand.no> <503FC1BF.5020004@alvestrand.no> In-Reply-To: <503FC1BF.5020004@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.139.227] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] RTCWEB needs an Internet Codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 31 Aug 2012 00:20:44 -0000 >That's not what I said. I said that the *set* of MTI codecs should cover t= he use cases. >We have a requirement (F21) that explicitly mentions commonly supported co= decs in telephony services; there's no way Opus can cover that case. Apologies - inaccurate wording on my part. I still think it is unrealistic= for any suite of MTI codecs to cover all use cases. I think the QoS-based= use case still stands as an example of why this is unrealistic. > You're not reading the latest draft. That section is now 4.2.6. The version I linked to from the RTCWEB status pages is -09, which has the = relevant use case as 4.2.7 (see http://tools.ietf.org/html/draft-ietf-rtcwe= b-use-cases-and-requirements-09#section-4.2.7). If the doc is rapidly evol= ving, then the use case doc may not be suitable for evaluation of codecs fo= r MTI at this point in time. > Section 4.1 of the draft defines "narrowband" to be "10s to 100s of Kbits= /sec". The full text states "Clients can be on narrowband (10s to 100s of Kbits/s= ec)". Does this definition refer to codecs or the underlying access techno= logy? I think in the context one could reasonably conclude that "narrowban= d" refers to dial-up or low data rate cellular (e.g. GPRS, GSM HSCSD, 1X). = The text in 4.1 says nothing about bandlimiting of the input voice signal = to a codec. Moreover, the ensuing text states "Clients can be on variable= -media-quality networks (wireless)". To me, this means that the sub-10 kbp= s case for voice codecs is still relevant. > Respectfully ..... the slight advantage in quality that AMR-NB seems to o= ffer over Opus at 8 kbps is very different from the advantage that Opus enj= oys over G.711 at 64 Kbits and above. I don't view the quality advantage as 6 kbps as slight, and implementers st= ill have the option of using Opus at any all data rates without designating= it as MTI. Just as implementers can use AMR-WB, G.722 and so on. Moreove= r, the study I cited did not consider codecs such as EVRC-B that can operat= e in the sub 5 kbps range. =20 >> The initial conclusion from my end is that using Opus when cellular Q= oS support results in a guaranteed bit rate less than 8 kbps would not resu= lt in the user being "able to take advantage of the QoS support" as per the= use case. >Neither does it cover the case where there's not enough bits to carry an I= P+RTP header every 20 milliseconds. There are cases where WebRTC won't work= . I'm not sure what you are trying to say. Do you believe the use of Opus wi= ll not satisfy the QoS use case? Or do you believe that the QoS use case i= s one where WebRTC will simply not work? -----Original Message----- From: Harald Alvestrand [mailto:harald@alvestrand.no]=20 Sent: Thursday, August 30, 2012 12:41 PM To: Mandyam, Giridhar Cc: DRAGE, Keith (Keith); rtcweb@ietf.org Subject: Re: [rtcweb] RTCWEB needs an Internet Codec On 08/30/2012 09:13 PM, Mandyam, Giridhar wrote: > Hello Harald, > Can you clarify this viewpoint? If we use the criterion that any MTI cod= ec has to be suitable for all use cases as currently documented, then it se= ems neither Opus nor G.711 can suffice. That's not what I said. I said that the *set* of MTI codecs should cover th= e use cases. We have a requirement (F21) that explicitly mentions commonly supported cod= ecs in telephony services; there's no way Opus can cover that case. > =20 > > For instance, use case 4.2.7 - "... the user's provider of cellular acces= s has QoS support enabled. The user is able to take advantage of the QoS s= upport both when accessing via the residential router and when using cellul= ar." You're not reading the latest draft. That section is now 4.2.6. > If the guaranteed bit rate (GBR, part of the QoS Class Indicator in 3G= PP defined networks) falls outside of the operating range where Opus is the= best performing codec (e.g. the sub-8kbps part of the 'Quality vs Bitrate'= curve in http://www.opus-codec.org/comparison/), another codec would be re= quired. Section 4.1 of the draft defines "narrowband" to be "10s to 100s of=20 Kbits/sec". > > The study available at http://research.nokia.com/files/public/%5B16%5D_In= terSpeech2011_Voice_Quality_Characterization_of_IETF_Opus_Codec.pdf clearly= shows a significant advantage in MOS scores at 5.9 kbps for AMR-NB as com= pared to Opus (Silk). Respectfully ..... the slight advantage in quality that AMR-NB seems to=20 offer over Opus at 8 kbps is very different from the advantage that Opus=20 enjoys over G.711 at 64 Kbits and above. > The initial conclusion from my end is that using Opus when cellular Qo= S support results in a guaranteed bit rate less than 8 kbps would not resul= t in the user being "able to take advantage of the QoS support" as per the = use case. Neither does it cover the case where there's not enough bits to carry an=20 IP+RTP header every 20 milliseconds. There are cases where WebRTC won't=20 work. > > I think we shouldn't try to mandate codecs to try to cover every single u= se case. Rather we should mandate as few as necessary to avoid codec negot= iation failure. Yes. And failure to negotiate an usable codec is a negotiation failure. > > -Giri > > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf = Of Harald Alvestrand > Sent: Thursday, August 30, 2012 5:51 AM > To: DRAGE, Keith (Keith) > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] RTCWEB needs an Internet Codec > > On 08/30/2012 02:38 PM, DRAGE, Keith (Keith) wrote: >> Surely that argument extends to every possible codec. > The set of MTI codecs should cover the set of use cases that have been id= entified. > Additional MTI codecs that don't cover new use cases shouldn't be added. > > I believe the use case "distributed music band" in draft-ietf-rtcweb-use-= cases-and-requirements can't be satisified with G.711. > >> If the codecs supported by both endpoints do not supply the characterist= ics needed for the communication, then you will get interoperability failur= e. >> >> If I want more bandwidth or quality than OPUS supplies, then I will also= get interoperability failure. >> >> Keith >> >>> -----Original Message----- >>> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On >>> Behalf Of Harald Alvestrand >>> Sent: 30 August 2012 11:56 >>> To: rtcweb@ietf.org >>> Subject: Re: [rtcweb] RTCWEB needs an Internet Codec >>> >>> The counterpoint is that having G.711 as the only MTI means that you >>> get interoperability failure for any application in which G.711 sound >>> quality is not acceptable. >>> >>> This includes all applications involving music. >>> >>> On 08/29/2012 06:30 PM, Randall Gellens wrote: >>>> At 12:13 AM -0400 8/29/12, Roman Shpount wrote: >>>> >>>>> I would argue G.711 should be the MTI codec. The rest can be left >>>>> up to browser implementers. >>>> I agree. >>>> >>>>> We can argue all we want, but the best royalty free low bitrate >>>>> codec available will be the one everybody supports. >>>> Very good point, and why we should mandate only one audio codec. >>>> >>> _______________________________________________ >>> 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 From jmvalin@mozilla.com Thu Aug 30 18:43:11 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B6C111E80E4 for ; Thu, 30 Aug 2012 18:43:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4HEn9j1IuzNz for ; Thu, 30 Aug 2012 18:43:10 -0700 (PDT) Received: from smtp.mozilla.org (mx2.corp.phx1.mozilla.com [63.245.216.70]) by ietfa.amsl.com (Postfix) with ESMTP id 43E2921F8450 for ; Thu, 30 Aug 2012 18:43:08 -0700 (PDT) Received: from [192.168.1.15] (modemcable094.20-21-96.mc.videotron.ca [96.21.20.94]) (Authenticated sender: jvalin@mozilla.com) by mx2.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 6D3CFF2634; Thu, 30 Aug 2012 18:43:06 -0700 (PDT) Message-ID: <504016A9.5000805@mozilla.com> Date: Thu, 30 Aug 2012 21:43:05 -0400 From: Jean-Marc Valin User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: "Mandyam, Giridhar" References: <503F46C5.2090607@alvestrand.no> <503F61CC.1010709@alvestrand.no> <503FC188.5050003@mozilla.com> In-Reply-To: X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] RTCWEB needs an Internet Codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 31 Aug 2012 01:43:11 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/30/2012 08:18 PM, Mandyam, Giridhar wrote: > I don't follow. If both parties in the call support a codec > suitable for 6 kb/s (e.g. AMR-NB) then there should be no > negotiation failure. MTI still allows for non-MTI codecs to be used > on a WebRTC call. The point I was trying to make was that Opus > does not satisfy the use case as specified. I never said that > G.711 satisfied this use case. I believe it is unrealistic to > require that the set of MTI audio codecs (whatever they may be) > satisfy every single use case as currently outlined. Here's the thing. I'm not trying to prevent you from including AMR-NB or any other codec. If all you have is 6 kb/s and you have AMR-NB on both ends, then by all means use that. But what if that's not the case and only one side supports it? If only G.711 is MTI, then the negotiation *fails*. And it won't just fail at 6 kb/s. It'll fail all the way up to 64 kb/s and that's unacceptable. OTOH, if you have Opus as MTI, you'll still be able to talk, which is big improvement, even if the quality isn't nearly as good as AMR-NB or EVRC-B at these ridiculously low bitrates. Essentially, I've yet to understand your reasoning that because Opus is "only" optimal for 99% of the use cases, then we should use something (G.711) that's highly suboptimal in all use cases. The way I see this shaping up, it seems highly likely that > All the more reason to achieve toll quality at codec data rates > below 8 kbps when operating in a cellular environment. Sure, go as low as you like. There's even codecs that work at 2 kb/s and below if you like. If both sides support it, it's all good. But when all we have in common are the MTI codecs, then please let's make webrtc not suck or (worse) fail completely. > I've already stated my position on MTI audio codecs on this > mailing list. I never advocated making every codec that is optimal > given a particular operating condition as MTI. I also think the > performance loss due to the use of Opus at sub 10 kbps is not > trivial, and it is worth leveraging other codecs at these lower > data rates. So here's the options we're looking at in the cases where all you have in common are MTI codecs (and it seems that those will be common): 1) Optimal quality at almost all rates, but sub-optimal below 10 kb/s; or 2) Highly sub-optimal at 64 kb/s and above, with completely failure below 64 kb/s. I'm sure most people prefer 1) and I still don't understand why you would prefer option 2). Option 2) essentially means "we have a really crappy standard which can only work decently if you have extensions". Jean-Marc > -----Original Message----- From: Jean-Marc Valin > [mailto:jmvalin@mozilla.com] Sent: Thursday, August 30, 2012 12:40 > PM To: Mandyam, Giridhar Cc: Harald Alvestrand; DRAGE, Keith > (Keith); rtcweb@ietf.org Subject: Re: [rtcweb] RTCWEB needs an > Internet Codec > > On 12-08-30 03:13 PM, Mandyam, Giridhar wrote: >> The study available at >> http://research.nokia.com/files/public/%5B16%5D_InterSpeech2011_Voice_ >> >> >> Quality_Characterization_of_IETF_Opus_Codec.pdf >> clearly shows a significant advantage in MOS scores at 5.9 kbps >> for AMR-NB as compared to Opus (Silk). The initial conclusion >> from my end is that using Opus when cellular QoS support results >> in a guaranteed bit rate less than 8 kbps would not result in the >> user being "able to take advantage of the QoS support" as per the >> use case. > > So because Opus is better except around 6 kb/s means that we have > negotiation failure and that we should instead use G.711 at 64 > kb/s? Also, keep in mind that browser-to-browser means RTP, which > typically means 16 kb/s worth of overhead anyway (with 20 ms > frames). Even though Opus is not optimal at 6 kb/s, we still have > something that works and we avoid interop failure. And what are the > alternatives anyway? If we only decide on G.711, then we not only > have embarrassingly bad quality, but we also have interop failure > below 64 kb/s. If you want guaranteed good quality without Opus, > you can also make AMR-NB, AMR-WB, G.722.1C, AAC-LD, HE-AAC, and > AAC-LC all MTI. Then you'll have (on average) quality that's almost > as good as Opus alone can do, you'll cover almost as many use > cases, and as a bonus, you get all the negotiation and switching > nightmares involved. > > Jean-Marc > >> -----Original Message----- From: rtcweb-bounces@ietf.org >> [mailto:rtcweb-bounces@ietf.org] On Behalf Of Harald Alvestrand >> Sent: Thursday, August 30, 2012 5:51 AM To: DRAGE, Keith (Keith) >> Cc: rtcweb@ietf.org Subject: Re: [rtcweb] RTCWEB needs an >> Internet Codec >> >> On 08/30/2012 02:38 PM, DRAGE, Keith (Keith) wrote: >>> Surely that argument extends to every possible codec. >> The set of MTI codecs should cover the set of use cases that >> have been identified. Additional MTI codecs that don't cover new >> use cases shouldn't be added. >> >> I believe the use case "distributed music band" in >> draft-ietf-rtcweb-use-cases-and-requirements can't be satisified >> with G.711. >> >>> >>> If the codecs supported by both endpoints do not supply the >>> characteristics needed for the communication, then you will get >>> interoperability failure. >>> >>> If I want more bandwidth or quality than OPUS supplies, then I >>> will also get interoperability failure. >>> >>> Keith >>> >>>> -----Original Message----- From: rtcweb-bounces@ietf.org >>>> [mailto:rtcweb-bounces@ietf.org] On Behalf Of Harald >>>> Alvestrand Sent: 30 August 2012 11:56 To: rtcweb@ietf.org >>>> Subject: Re: [rtcweb] RTCWEB needs an Internet Codec >>>> >>>> The counterpoint is that having G.711 as the only MTI means >>>> that you get interoperability failure for any application in >>>> which G.711 sound quality is not acceptable. >>>> >>>> This includes all applications involving music. >>>> >>>> On 08/29/2012 06:30 PM, Randall Gellens wrote: >>>>> At 12:13 AM -0400 8/29/12, Roman Shpount wrote: >>>>> >>>>>> I would argue G.711 should be the MTI codec. The rest >>>>>> can be left up to browser implementers. >>>>> I agree. >>>>> >>>>>> We can argue all we want, but the best royalty free low >>>>>> bitrate codec available will be the one everybody >>>>>> supports. >>>>> Very good point, and why we should mandate only one audio >>>>> codec. >>>>> >>>> _______________________________________________ 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 >> _______________________________________________ rtcweb mailing >> list rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQEcBAEBAgAGBQJQQBapAAoJEJ6/8sItn9q9pioH/iR6CTa6iLdN3wkuK5O1XbsI /2JY3zqUaqlokaivWZzl0imCN5Rnkfl9Y7l3kyeBPXv6P++VJ5HG/9xTX9Pm+OKE HNEI4nE5npiA+A5FoDqR2rcHprj2hPjRM3J62uFgxk9Kof4onQTMG87AUCAUciyN aBfrzDVBiSz68Ha51yYM5oOHiZzBHRW9Ysccbf6DrkzzcuKoavs+OJ7bVaKSuc2I 4TsEdP33qJa+NHsOzCeFIZ6xmC/wSpF5/3oXNEaV/Mz5zUoTA2I1Cfr4G/vP/YIW r4JMzPh+kwXJQ4Aawiv6eyP5KRI4hRkSkXoP7brfG+ZoVr44HKyGCnNywXYtXac= =jjKQ -----END PGP SIGNATURE----- From harald@alvestrand.no Thu Aug 30 23:05:21 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9673D21F852E for ; Thu, 30 Aug 2012 23:05:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.074 X-Spam-Level: X-Spam-Status: No, score=-110.074 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uJDYBtRNR2bH for ; Thu, 30 Aug 2012 23:05:21 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 96CAA21F852D for ; Thu, 30 Aug 2012 23:05:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8366C39E0CE; Fri, 31 Aug 2012 08:05:19 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ELswltPyDwuy; Fri, 31 Aug 2012 08:05:16 +0200 (CEST) Received: from [192.168.11.107] (c-56fbe555.03-217-73746f1.cust.bredbandsbolaget.se [85.229.251.86]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id AC3C239E020; Fri, 31 Aug 2012 08:05:16 +0200 (CEST) Message-ID: <5040541C.5020008@alvestrand.no> Date: Fri, 31 Aug 2012 08:05:16 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: "Mandyam, Giridhar" References: <503F46C5.2090607@alvestrand.no> <503F61CC.1010709@alvestrand.no> <503FC1BF.5020004@alvestrand.no> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] RTCWEB needs an Internet Codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 31 Aug 2012 06:05:21 -0000 On 08/31/2012 02:20 AM, Mandyam, Giridhar wrote: >> That's not what I said. I said that the *set* of MTI codecs should cover the use cases. >> We have a requirement (F21) that explicitly mentions commonly supported codecs in telephony services; there's no way Opus can cover that case. > Apologies - inaccurate wording on my part. I still think it is unrealistic for any suite of MTI codecs to cover all use cases. I think the QoS-based use case still stands as an example of why this is unrealistic. I still think you are constructing an unrealistic use case, and one that isn't in the document. If necessary, we should make the document more explicit to say that we don't solve for use cases where less than 10s of kilobits of Internet bandwidth is available; I believe the speech quality of Opus is not your biggest problem in that scenario. The purpose of an use case document is to describe the problems we're solving so that we can separate them from the problems we don't solve. I'd be fine with ruling sustained sub-10-Kbits/sec available Internet bandwidth explicitly out of scope. >> You're not reading the latest draft. That section is now 4.2.6. > The version I linked to from the RTCWEB status pages is -09, which has the relevant use case as 4.2.7 (see http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-09#section-4.2.7). If the doc is rapidly evolving, then the use case doc may not be suitable for evaluation of codecs for MTI at this point in time. Yes, apologies; I was the one with an unrefreshed archive. > >> Section 4.1 of the draft defines "narrowband" to be "10s to 100s of Kbits/sec". > The full text states "Clients can be on narrowband (10s to 100s of Kbits/sec)". Does this definition refer to codecs or the underlying access technology? I think in the context one could reasonably conclude that "narrowband" refers to dial-up or low data rate cellular (e.g. GPRS, GSM HSCSD, 1X). The text in 4.1 says nothing about bandlimiting of the input voice signal to a codec. Moreover, the ensuing text states "Clients can be on variable-media-quality networks (wireless)". To me, this means that the sub-10 kbps case for voice codecs is still relevant. > >> Respectfully ..... the slight advantage in quality that AMR-NB seems to offer over Opus at 8 kbps is very different from the advantage that Opus enjoys over G.711 at 64 Kbits and above. > I don't view the quality advantage as 6 kbps as slight, and implementers still have the option of using Opus at any all data rates without designating it as MTI. Just as implementers can use AMR-WB, G.722 and so on. Moreover, the study I cited did not consider codecs such as EVRC-B that can operate in the sub 5 kbps range. > >>> The initial conclusion from my end is that using Opus when cellular QoS support results in a guaranteed bit rate less than 8 kbps would not result in the user being "able to take advantage of the QoS support" as per the use case. >> Neither does it cover the case where there's not enough bits to carry an IP+RTP header every 20 milliseconds. There are cases where WebRTC won't work. > I'm not sure what you are trying to say. Do you believe the use of Opus will not satisfy the QoS use case? Or do you believe that the QoS use case is one where WebRTC will simply not work? I believe we'll have a hard time getting the QoS use case working, not because of what you say, but because the QoS APIs on the Internet are still quite difficult to use. But this is entirely orthogonal to the codec question. From tterriberry@mozilla.com Thu Aug 30 23:15:06 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B082B21F845F for ; Thu, 30 Aug 2012 23:15:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.933 X-Spam-Level: X-Spam-Status: No, score=-0.933 tagged_above=-999 required=5 tests=[AWL=0.745, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W3nxLslTXRIV for ; Thu, 30 Aug 2012 23:15:06 -0700 (PDT) Received: from smtp.mozilla.org (mx1.corp.phx1.mozilla.com [63.245.216.69]) by ietfa.amsl.com (Postfix) with ESMTP id 4169721F853C for ; Thu, 30 Aug 2012 23:15:06 -0700 (PDT) Received: from [172.16.1.197] (LRouen-152-83-11-227.w80-13.abo.wanadoo.fr [80.13.74.227]) (Authenticated sender: tterriberry@mozilla.com) by mx1.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id CE7E8F256A for ; Thu, 30 Aug 2012 23:15:02 -0700 (PDT) Message-ID: <50405665.6050801@mozilla.com> Date: Thu, 30 Aug 2012 23:15:01 -0700 From: "Timothy B. Terriberry" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120625 SeaMonkey/2.10.1 MIME-Version: 1.0 To: "rtcweb@ietf.org" References: <503F46C5.2090607@alvestrand.no> <503F61CC.1010709@alvestrand.no> <503FC1BF.5020004@alvestrand.no> <5040541C.5020008@alvestrand.no> In-Reply-To: <5040541C.5020008@alvestrand.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] RTCWEB needs an Internet Codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 31 Aug 2012 06:15:06 -0000 Harald Alvestrand wrote: > If necessary, we should make the document more explicit to say that we > don't solve for use cases where less than 10s of kilobits of Internet > bandwidth is available; I believe the speech quality of Opus is not your > biggest problem in that scenario. Agreed. Even if it was, as Jean-Marc points out elsewhere, making Opus non-MTI does not magically solve that problem. It just means that you may only be left with G.711 to solve that problem. That doesn't exactly seem like an improvement. From lars@netapp.com Thu Aug 30 23:49:11 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B34C521F852A for ; Thu, 30 Aug 2012 23:49:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.758 X-Spam-Level: X-Spam-Status: No, score=-9.758 tagged_above=-999 required=5 tests=[AWL=-0.555, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zGd+jus3Spq5 for ; Thu, 30 Aug 2012 23:49:10 -0700 (PDT) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by ietfa.amsl.com (Postfix) with ESMTP id 636C321F8460 for ; Thu, 30 Aug 2012 23:49:10 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,345,1344236400"; d="p7s'?scan'208";a="684089008" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 30 Aug 2012 23:49:09 -0700 Received: from vmwexceht02-prd.hq.netapp.com (vmwexceht02-prd.hq.netapp.com [10.106.76.240]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id q7V6n9ax004733; Thu, 30 Aug 2012 23:49:09 -0700 (PDT) Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.212]) by vmwexceht02-prd.hq.netapp.com ([10.106.76.240]) with mapi id 14.02.0309.002; Thu, 30 Aug 2012 23:49:08 -0700 From: "Eggert, Lars" To: Jean-Marc Valin Thread-Topic: [rtcweb] Opus over the Internet? Thread-Index: Ac2Gr8HzJ/6oA0BvSY28PJ4c6WjX7AAbYi0AABiF3AA= Date: Fri, 31 Aug 2012 06:49:11 +0000 Message-ID: <63E8802C-308D-43EF-B891-3F3A5D34B850@netapp.com> References: <503FB9CE.2080000@mozilla.com> In-Reply-To: <503FB9CE.2080000@mozilla.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Content-Type: multipart/signed; micalg=sha1; boundary="Apple-Mail-9B6F1AF0-C034-41D0-8839-C9C1A2DD9038"; protocol="application/pkcs7-signature" MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Opus over the Internet? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 31 Aug 2012 06:49:11 -0000 --Apple-Mail-9B6F1AF0-C034-41D0-8839-C9C1A2DD9038 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii That's all great, but is there any qualitative comparison data of the differ= ent codecs available? --=20 Sent from a mobile device; please excuse typos. On Aug 30, 2012, at 21:07, "Jean-Marc Valin" wrote: > On 12-08-30 09:14 AM, Markus.Isomaki@nokia.com wrote: >> Are there any tests that actually compare different codecs, say Opus >> vs. G.722 vs. AMR-WB, in typical Internet use, meaning some loss and >> jitter? I suppose the performance is only partially related to the >> codec, and partially to other implementation decisions, so it might >> be difficult to compare apples-with-apples. But since people are >> arguing that Opus is an "Internet codec", it would be actually nice >> to see some results in this sense. Or does "Internet codec" mean >> something else? >=20 > The term "Internet codec" means different things to different people, > but to me this means more than "having good packet loss concealment". > Sure we have PLC (though it was never compared to G.722 or AMR-WB) and > we also have (optional) low bit-rate embedded redundancy (also called > FEC) and (also optional) independent frames, but that's just one aspect. >=20 > One of the first things we've been asked when designing Opus was to make > the rate *really* adaptable because we never know what kind of rates > will be available. This not only meant having a wide range of bitrates, > but also being able to vary in small increments. This is why Opus scales > from about 6 kb/s to 512 kb/s, in increments of 0.4 kb/s (one byte with > 20 ms frames). Compare that to AMR-WB, which scales from 6.6 to 23.85 in > (on average) ~2.5 kb/s increments. The reason Opus can have more than > 1200 possible bitrates is because on the Internet, other layers in the > protocol stack provide octet granularity framing/sizing. We don't need > to spend 11 bits signalling the bitrate because UDP already encodes the > packet size. >=20 > There's also practical aspects. If you look at the rates supported by > AMR-WB, you see that *none* of them represents an integer number of > bytes per frame. For example, 23.85 kb/s is 59 bytes plus 5 bits per > frame. It's definitely not the only cause, but the bottom line is that > the payload format for AMR-WB (rfc4867) is quite complex. Now compare > this with the Opus RTP payload > (http://tools.ietf.org/html/draft-spittka-payload-rtp-opus). Although > it's not complete, it's not only much simpler, but it also makes it > possible to decode RTP packets without having even seen the SDP or any > out-of-band signalling. >=20 > People may have other definitions, but that's what *I* mean by Opus > being an "Internet codec". >=20 > Cheers, >=20 > Jean-Marc >=20 >>> -----Original Message----- From: rtcweb-bounces@ietf.org >>> [mailto:rtcweb-bounces@ietf.org] On Behalf Of ext Stefan Hakansson >>> LK Sent: 30 August, 2012 14:58 To: Jean-Marc Valin Cc: >>> rtcweb@ietf.org Subject: Re: [rtcweb] Confirmation of consensus on >>> audio codecs >>>=20 >>> On 08/29/2012 03:10 PM, Jean-Marc Valin wrote: >> On 08/29/2012 05:51 AM, Stefan Hakansson LK wrote: >>>> ... >>=20 >>>>>> That is great, but sort of underlines that there would be no >>>>>> harm in delaying the decision until there are experiences >>>>>> made from real world use - 'cause it would not be that long >>>>>> till that experience has been made (Markus also brought up >>>>>> the IPR status as a reason for waiting - I have no idea how >>>>>> long it would take to know more about that). >>=20 >> As Harald is pointing out, rtcweb implementations are going to ship=20 >> pretty soon. >>>>=20 >>>> If that is the case (and I think and hope so), why would we need >>>> to make it MTI before seeing it in action? >>>>=20 >>>> [...] >>>>=20 >> Are you expecting *another* single, standardized, royalty-free codec=20 >> that operates over vast ranges of bitrates and operating conditions,=20 >> from narrowband speech to stereo music, all with low delay, coming >> out in the next year? If not, what are you really waiting for? >>>>=20 >>>> No, I'm not expecting that. I would just prefer us to see that >>>> Opus does indeed deliver as promised before making it MTI. If it >>>> does, fine. If not, we'd have to discuss what to do then. >>>>=20 >>>> To me it is like if you're going to place a bet, for an upcoming >>>> big race, on a horse that has never been in an actual race, but >>>> shows great promise. If you know that the horse is going to >>>> participate in a few practice races soon, would you not prefer to >>>> wait and see how it fares in those before placing the bet (given >>>> that the odds would not change)? >>>>=20 >>>> Anyway, that's my view. Let's see what the chairs say. >>=20 >>>>>> As Paul suggested, I was referring to the lack of formal, >>>>>> controlled, characterization tests. That is how other SDOs do >>>>>> it. I don't think that is the only way to do it, but I think >>>>>> we should at least have either such tests conducted or >>>>>> experience from deployment and use (in a wide range of >>>>>> conditions and device types) before making it MTI. >>=20 >> Opus has had "ITU-style" testing on English (=20 >> http://www.opus-codec.org/comparison/GoogleTest1.pdf ) and Mandarin >> ( http://www.opus-codec.org/comparison/GoogleTest2.pdf ). And if you=20 >> don't trust Google on the tests I linked to, it's also been tested >> by Nokia: >>=20 >>>> http://research.nokia.com/files/public/%5B16%5D_InterSpeech2011_Voice_ >>=20 >>>>=20 > Quality_Characterization_of_IETF_Opus_Codec.pdf >>>> Come on, those tests are very limited compared to a formal >>>> characterization test. (Example:=20 >>>> www.itu.int/dms_pub/itu-t/opb/tut/T-TUT-ASC-2010-MSW-E.docx). >>>> There is very little info on the material used, the environment, >>>> processing and scripts and so on. And there seems to be no tests >>>> whatsoever (at least not involving humans) with actual channels >>>> introducing jitter and losses. >>>>=20 >>>> Note: I am in no way proposing that a formal characterization >>>> test is needed, or even the right thing to do. It is a costly and >>>> time consuming process, and alternative approaches could prove to >>>> be more efficient. What I am saying is that I think we should not >>>> mandate a codec that has neither gone through that kind of formal >>>> characterization testing nor has any field experience from actual >>>> use on a reasonable scale (covering different conditions and >>>> device types). It just seems wrong, especially given that we >>>> will soon have field experience. >>>>=20 >>=20 >> Now, unlike other SDOs, the testing did not stop there. ITU-T codecs=20 >> generally end up being testing with something in the order of tens >> of minutes worth of audio. In *addition* to that kind of testing, >> Opus also had automated testing with hundreds of years worth of >> audio. If anything, I think other SDOs should learn something here. >>>>=20 >>>> This may very well be true. I guess this comes down to how much >>>> you trust that the quality assessment models (e.g. PEAQ, POLQA) >>>> give the same result as human test subjects would. But I think >>>> this sounds like a really good thing. >>>>=20 >>=20 >> Jean-Marc >>=20 >>>>=20 >>>=20 >>> _______________________________________________ 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 --Apple-Mail-9B6F1AF0-C034-41D0-8839-C9C1A2DD9038 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFTjCCBUow ggQyoAMCAQICEFcfSRTG0jNknqb9LV9GuFkwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMTEyMTAwMDAwMDBaFw0x MjEyMDkyMzU5NTlaMIIBDTEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2 aWNlMRQwEgYDVQQDFAtMYXJzIEVnZ2VydDEeMBwGCSqGSIb3DQEJARYPbGFyc0BuZXRhcHAuY29t MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAokrhJTcXt6J/VEpZOicLoguBlYTjXP9v Ze4HuuhXnURUS8YouAfgaqA0zYbt5yd6fh4PBMdAaEWr5yJyHuFykXlrCumjUWSpLuqTS2A+pt4q cZaAQk9iLDN/UVd3SpkUuvWbxXlqzG7/BSqa3VNObBzCmyh+V7aXxri+30CT//DSsNRC4VFy6sn6 dMgSaFenXLwe/FBwY0qTMfICT1PrrX6Sw1S8OfH9rykLlZXbmfkFExxQngp1DJH9xMHeODHGbCv/ ty5gdxMOrLe+vENxFEcy1YQWBZd1kNL4UObugF8A/jE/s+Oa3H1VFH8ghqZTdqGDysVxmtKHuNFx 6jIBSQIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXATAqMCgG CCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIFoDAdBgNV HSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDovL2luZGMx ZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20vSW5kQzFEaWdpdGFsSUQtRzMuY3JsMA0GCSqG SIb3DQEBBQUAA4IBAQBA7q6tR92qpd7xo7VBsrOfGCWzoxIVfTc7t0RhB/Oz/+c3lnhYnNScIuKN JmyZvznmVxqB9BJ72+NkvmdB/hnILSBTRawL2tyLo9PkBtN0nRt4gS6wjpWnD8G83hlJLE7r25jk 7HkRev61dTIXsANFpJKF02C4XSoDfEzNV6MpuEvHvcgHCqMrlwWwfKc7+NoDnE8PBuRzwSXvlD5L mswCY2iiOsd7ImNO4OzTCxETvKTDu92+FTIbRJJpYjVNv1UF7e3w9Kq65BkZJErUH19beUeQl0Wh 2BJQE6/15rQyCnP0iJ/Nmx2/kI6M0PWunEsI6FMs0MbosreaWGHlQmomMYIEizCCBIcCAQEwgfIw gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQVx9J FMbSM2Sepv0tX0a4WTAJBgUrDgMCGgUAoIICbTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0xMjA4MzEwNjQ5MDVaMCMGCSqGSIb3DQEJBDEWBBTd+dLWpKjJYJTy9a7O GuS1a5TD/zCCAQMGCSsGAQQBgjcQBDGB9TCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZl cmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJU ZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UE CxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2 aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczAhBXH0kUxtIzZJ6m/S1fRrhZMIIBBQYLKoZIhvcNAQkQ AgsxgfWggfIwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBz Oi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlk YXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0Eg LSBHMwIQVx9JFMbSM2Sepv0tX0a4WTANBgkqhkiG9w0BAQEFAASCAQBQg7QkDYF4fVNCnbGW1jv4 gliz+alnifFErEv7S5wY+zN5LjVr/P5/Op+b47u9x7O8roPn0NTQ1/i73YmIcFfiyq5Hq6R0R8rq C8Se4AOFBJcetsU9FI8mY/x+7McyNWh0WYqb1gXKfprQqyoc4FyJs++O2/KNMQJFW+oBYLCQApEa rAWiP7gwhXqi/sIRMk7e03H7UEryWt2ryT2GMokvGR8tQn67YvZHKnF5MYDsEnveSN2YkTRd8Ny3 BCRVrMkvipuo+nIdS7YocGQBHq8jlAK861H/UdFVKjPN8hW/JBtqIZCXmWx+7lClkhHRSlVVlbzi 4W15aRxWkgZN6tGEAAAAAAAA --Apple-Mail-9B6F1AF0-C034-41D0-8839-C9C1A2DD9038-- From john@jlc.net Fri Aug 31 06:38:47 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ED8021F851B for ; Fri, 31 Aug 2012 06:38:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.792 X-Spam-Level: X-Spam-Status: No, score=-105.792 tagged_above=-999 required=5 tests=[AWL=0.807, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cBFdbCMyHKJE for ; Fri, 31 Aug 2012 06:38:46 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 6B6DA21F8505 for ; Fri, 31 Aug 2012 06:38:46 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id F0EBE33C29; Fri, 31 Aug 2012 09:38:45 -0400 (EDT) Date: Fri, 31 Aug 2012 09:38:45 -0400 From: John Leslie To: Harald Alvestrand Message-ID: <20120831133845.GW72831@verdi> References: <503F46C5.2090607@alvestrand.no> <503F61CC.1010709@alvestrand.no> <503FC1BF.5020004@alvestrand.no> <5040541C.5020008@alvestrand.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5040541C.5020008@alvestrand.no> User-Agent: Mutt/1.4.1i Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] RTCWEB needs an Internet Codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 31 Aug 2012 13:38:47 -0000 Harald Alvestrand wrote: > > If necessary, we should make the document more explicit to say that we > don't solve for use cases where less than 10s of kilobits of Internet > bandwidth is available... +1 There are today some use-cases with less than 56Kbps; but they're dying, and the infrastructure for them isn't being built anywhere (including third-world countries, if you must ask). I'm very glad there _are_ codecs that can operate in such an environment; but that's not where our effort belongs. We want something optimized for 5-10 years down the road. -- John Leslie From koen.vos@skype.net Fri Aug 31 07:38:20 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4485221F8634 for ; Fri, 31 Aug 2012 07:38:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TCwO-Uc-YxSe for ; Fri, 31 Aug 2012 07:38:18 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe001.messaging.microsoft.com [216.32.180.184]) by ietfa.amsl.com (Postfix) with ESMTP id 6217721F8628 for ; Fri, 31 Aug 2012 07:38:18 -0700 (PDT) Received: from mail89-co1-R.bigfish.com (10.243.78.231) by CO1EHSOBE013.bigfish.com (10.243.66.76) with Microsoft SMTP Server id 14.1.225.23; Fri, 31 Aug 2012 14:38:17 +0000 Received: from mail89-co1 (localhost [127.0.0.1]) by mail89-co1-R.bigfish.com (Postfix) with ESMTP id 6E65F6801AA for ; Fri, 31 Aug 2012 14:38:17 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC105.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -39 X-BigFish: VS-39(zzbb2dI98dI9371I936eI146fI542Mc85dh1432I328cMzz1202hzz1033IL8275bh8275dh5eeeKz2fh2a8h668h839hd25hf0ah107ah1155h) Received-SPF: pass (mail89-co1: domain of skype.net designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=koen.vos@skype.net; helo=TK5EX14HUBC105.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail89-co1 (localhost.localdomain [127.0.0.1]) by mail89-co1 (MessageSwitch) id 1346423894443745_27988; Fri, 31 Aug 2012 14:38:14 +0000 (UTC) Received: from CO1EHSMHS008.bigfish.com (unknown [10.243.78.246]) by mail89-co1.bigfish.com (Postfix) with ESMTP id 5DA0E2C007E for ; Fri, 31 Aug 2012 14:38:14 +0000 (UTC) Received: from TK5EX14HUBC105.redmond.corp.microsoft.com (131.107.125.8) by CO1EHSMHS008.bigfish.com (10.243.66.18) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 31 Aug 2012 14:38:12 +0000 Received: from TK5EX14MBXC254.redmond.corp.microsoft.com ([169.254.2.17]) by TK5EX14HUBC105.redmond.corp.microsoft.com ([157.54.80.48]) with mapi id 14.02.0318.003; Fri, 31 Aug 2012 14:37:57 +0000 From: Koen Vos To: "rtcweb@ietf.org" Thread-Topic: [rtcweb] Opus over the Internet? Thread-Index: Ac2HfMsr5I6cHStDRl6nZRUBJnCOJAACCdSk Date: Fri, 31 Aug 2012 14:37:57 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.37] Content-Type: multipart/alternative; boundary="_000_D79146E3783B6942A3E8BC43352BBB460579F16DTK5EX14MBXC254r_" MIME-Version: 1.0 X-OriginatorOrg: skype.net Subject: Re: [rtcweb] Opus over the Internet? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 31 Aug 2012 14:38:20 -0000 --_000_D79146E3783B6942A3E8BC43352BBB460579F16DTK5EX14MBXC254r_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Lars Eggert wrote: > That's all great, but is there any qualitative comparison data of the dif= ferent codecs available? Please have a look at the test Dynastat did with SILK: http://developer.sky= pe.com/resources/SILKDataSheet.pdf Note that SILK in Opus is quite similar to the old SILK tested by Dynastat.= All changes were thoroughly tested to not degrade performance, and in mos= t cases improved it. So the SILK Dynastat results give a lower bound on th= e performance of a subset of the Opus modes. While these plots don't show G.722, it was in fact included in the test for= clean input signals without packet loss. According to the test results: - SILK at 8.85 kbps is outperformed by G.722 at 64 kbps with statistical si= gnificance - SILK at 12.65 kbps is a statistical tie with G.722 at 64 kbps - SILK at 18.85 kbps and above outperforms G.722 at 64 kbps with statistica= l significance. The packet loss in that test was maximally random (ie not bursty). While t= hat may not perfectly mimic real networks, I can think of no reason why the= results would be reversed or very different in practice. To give one more measure of suitability for the Internet: Skype has used SI= LK to deliver 100s of billions of Skype-to-Skype voice minutes over the Int= ernet, and our users are very satisfied with it. Hope this helps, koen. Lars Eggert wrote: That's all great, but is there any qualitative comparison data of the diffe= rent codecs available? -- Sent from a mobile device; please excuse typos. On Aug 30, 2012, at 21:07, "Jean-Marc Valin" wrote= : > On 12-08-30 09:14 AM, Markus.Isomaki at nokia.com wrote: >> Are there any tests that actually compare different codecs, say Opus >> vs. G.722 vs. AMR-WB, in typical Internet use, meaning some loss and >> jitter? I suppose the performance is only partially related to the >> codec, and partially to other implementation decisions, so it might >> be difficult to compare apples-with-apples. But since people are >> arguing that Opus is an "Internet codec", it would be actually nice >> to see some results in this sense. Or does "Internet codec" mean >> something else? > > The term "Internet codec" means different things to different people, > but to me this means more than "having good packet loss concealment". > Sure we have PLC (though it was never compared to G.722 or AMR-WB) and > we also have (optional) low bit-rate embedded redundancy (also called > FEC) and (also optional) independent frames, but that's just one aspect. > > One of the first things we've been asked when designing Opus was to make > the rate *really* adaptable because we never know what kind of rates > will be available. This not only meant having a wide range of bitrates, > but also being able to vary in small increments. This is why Opus scales > from about 6 kb/s to 512 kb/s, in increments of 0.4 kb/s (one byte with > 20 ms frames). Compare that to AMR-WB, which scales from 6.6 to 23.85 in > (on average) ~2.5 kb/s increments. The reason Opus can have more than > 1200 possible bitrates is because on the Internet, other layers in the > protocol stack provide octet granularity framing/sizing. We don't need > to spend 11 bits signalling the bitrate because UDP already encodes the > packet size. > > There's also practical aspects. If you look at the rates supported by > AMR-WB, you see that *none* of them represents an integer number of > bytes per frame. For example, 23.85 kb/s is 59 bytes plus 5 bits per > frame. It's definitely not the only cause, but the bottom line is that > the payload format for AMR-WB (rfc4867) is quite complex. Now compare > this with the Opus RTP payload > (http://tools.ietf.org/html/draft-spittka-payload-rtp-opus). Although > it's not complete, it's not only much simpler, but it also makes it > possible to decode RTP packets without having even seen the SDP or any > out-of-band signalling. > > People may have other definitions, but that's what *I* mean by Opus > being an "Internet codec". > > Cheers, > > Jean-Marc > >>> -----Original Message----- From: rtcweb-bounces at ietf.org >>> [mailto:rtcweb-bounces at ietf.org] On Behalf Of ext Stefan Hakansson >>> LK Sent: 30 August, 2012 14:58 To: Jean-Marc Valin Cc: >>> rtcweb at ietf.org Subject: Re: [rtcweb] Confirmation of consensus on >>> audio codecs >>> >>> On 08/29/2012 03:10 PM, Jean-Marc Valin wrote: >> On 08/29/2012 05:51 AM, Stefan Hakansson LK wrote: >>>> ... >> >>>>>> That is great, but sort of underlines that there would be no >>>>>> harm in delaying the decision until there are experiences >>>>>> made from real world use - 'cause it would not be that long >>>>>> till that experience has been made (Markus also brought up >>>>>> the IPR status as a reason for waiting - I have no idea how >>>>>> long it would take to know more about that). >> >> As Harald is pointing out, rtcweb implementations are going to ship >> pretty soon. >>>> >>>> If that is the case (and I think and hope so), why would we need >>>> to make it MTI before seeing it in action? >>>> >>>> [...] >>>> >> Are you expecting *another* single, standardized, royalty-free codec >> that operates over vast ranges of bitrates and operating conditions, >> from narrowband speech to stereo music, all with low delay, coming >> out in the next year? If not, what are you really waiting for? >>>> >>>> No, I'm not expecting that. I would just prefer us to see that >>>> Opus does indeed deliver as promised before making it MTI. If it >>>> does, fine. If not, we'd have to discuss what to do then. >>>> >>>> To me it is like if you're going to place a bet, for an upcoming >>>> big race, on a horse that has never been in an actual race, but >>>> shows great promise. If you know that the horse is going to >>>> participate in a few practice races soon, would you not prefer to >>>> wait and see how it fares in those before placing the bet (given >>>> that the odds would not change)? >>>> >>>> Anyway, that's my view. Let's see what the chairs say. >> >>>>>> As Paul suggested, I was referring to the lack of formal, >>>>>> controlled, characterization tests. That is how other SDOs do >>>>>> it. I don't think that is the only way to do it, but I think >>>>>> we should at least have either such tests conducted or >>>>>> experience from deployment and use (in a wide range of >>>>>> conditions and device types) before making it MTI. >> >> Opus has had "ITU-style" testing on English ( >> http://www.opus-codec.org/comparison/GoogleTest1.pdf ) and Mandarin >> ( http://www.opus-codec.org/comparison/GoogleTest2.pdf ). And if you >> don't trust Google on the tests I linked to, it's also been tested >> by Nokia: >> >>>> http://research.nokia.com/files/public/%5B16%5D_InterSpeech2011_Voice_ >> >>>> > Quality_Characterization_of_IETF_Opus_Codec.pdf >>>> Come on, those tests are very limited compared to a formal >>>> characterization test. (Example: >>>> www.itu.int/dms_pub/itu-t/opb/tut/T-TUT-ASC-2010-MSW-E.docx). >>>> There is very little info on the material used, the environment, >>>> processing and scripts and so on. And there seems to be no tests >>>> whatsoever (at least not involving humans) with actual channels >>>> introducing jitter and losses. >>>> >>>> Note: I am in no way proposing that a formal characterization >>>> test is needed, or even the right thing to do. It is a costly and >>>> time consuming process, and alternative approaches could prove to >>>> be more efficient. What I am saying is that I think we should not >>>> mandate a codec that has neither gone through that kind of formal >>>> characterization testing nor has any field experience from actual >>>> use on a reasonable scale (covering different conditions and >>>> device types). It just seems wrong, especially given that we >>>> will soon have field experience. >>>> >> >> Now, unlike other SDOs, the testing did not stop there. ITU-T codecs >> generally end up being testing with something in the order of tens >> of minutes worth of audio. In *addition* to that kind of testing, >> Opus also had automated testing with hundreds of years worth of >> audio. If anything, I think other SDOs should learn something here. >>>> >>>> This may very well be true. I guess this comes down to how much >>>> you trust that the quality assessment models (e.g. PEAQ, POLQA) >>>> give the same result as human test subjects would. But I think >>>> this sounds like a really good thing. >>>> >> >> Jean-Marc >> >>>> >>> >>> _______________________________________________ rtcweb mailing >>> list rtcweb at ietf.org https://www.ietf.org/mailman/listinfo/rtcweb > _______________________________________________ > rtcweb mailing list > rtcweb at ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --_000_D79146E3783B6942A3E8BC43352BBB460579F16DTK5EX14MBXC254r_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Lars Eggert wrote:
> That's all great, but is there any qua= litative comparison data of the different codecs available?

Please have a look at the test Dynastat did with SILK: http://developer.skype.com/resources/SILKDataSheet.= pdf

Note that SILK in Opus is quite similar to the old SILK tested by Dynastat.=   All changes were thoroughly tested to not degrade performance, and i= n most cases improved it.  So the SILK Dynastat results give a lower b= ound on the performance of a subset of the Opus modes.

While these plots don't show G.722, it was in fact included in the test for= clean input signals without packet loss.  According to the test resul= ts:
- SILK at 8.85 kbps is outperformed by G.722 at 64 kbps with statistical si= gnificance
- SILK at 12.65 kbps is a statistical tie with G.722 at 64 kbps
- SILK at 18.85 kbps and above outperforms G.722 at 64 kbps with statistica= l significance.

The packet loss in that test was maximally random (ie not bursty).  Wh= ile that may not perfectly mimic real networks, I can think of no reason wh= y the results would be reversed or very different in practice.

To give one more measure of suitability for the Internet: Skype has used SI= LK to deliver 100s of billions of Skype-to-Skype voice minutes over the Int= ernet, and our users are very satisfied with it.

Hope this helps,
koen.


 
Lars Eggert wrote:
That's all great, but is there any qualitative comparison data=
 of the different codecs available?=0A=
=0A=
-- =0A=
Sent from a mobile device; please excuse typos.=0A=
=0A=
On Aug 30, 2012, at 21:07, "Jean-Marc Valin" <jmvalin at mozil=
la.com> wrote:=0A=
=0A=
> On 12-08-30 09:14 AM, Markus.Isomaki at nokia.com wrote:=0A=
>> Are there any tests that actually compare different codecs, say Op=
us=0A=
>> vs. G.722 vs. AMR-WB, in typical Internet use, meaning some loss a=
nd=0A=
>> jitter? I suppose the performance is only partially related to the=
=0A=
>> codec, and partially to other implementation decisions, so it migh=
t=0A=
>> be difficult to compare apples-with-apples. But since people are=
=0A=
>> arguing that Opus is an "Internet codec", it would be ac=
tually nice=0A=
>> to see some results in this sense. Or does "Internet codec&qu=
ot; mean=0A=
>> something else?=0A=
> =0A=
> The term "Internet codec" means different things to differen=
t people,=0A=
> but to me this means more than "having good packet loss concealme=
nt".=0A=
> Sure we have PLC (though it was never compared to G.722 or AMR-WB) and=
=0A=
> we also have (optional) low bit-rate embedded redundancy (also called=
=0A=
> FEC) and (also optional) independent frames, but that's just one aspec=
t.=0A=
> =0A=
> One of the first things we've been asked when designing Opus was to ma=
ke=0A=
> the rate *really* adaptable because we never know what kind of rates=
=0A=
> will be available. This not only meant having a wide range of bitrates=
,=0A=
> but also being able to vary in small increments. This is why Opus scal=
es=0A=
> from about 6 kb/s to 512 kb/s, in increments of 0.4 kb/s (one byte wit=
h=0A=
> 20 ms frames). Compare that to AMR-WB, which scales from 6.6 to 23.85 =
in=0A=
> (on average) ~2.5 kb/s increments. The reason Opus can have more than=
=0A=
> 1200 possible bitrates is because on the Internet, other layers in the=
=0A=
> protocol stack provide octet granularity framing/sizing. We don't need=
=0A=
> to spend 11 bits signalling the bitrate because UDP already encodes th=
e=0A=
> packet size.=0A=
> =0A=
> There's also practical aspects. If you look at the rates supported by=
=0A=
> AMR-WB, you see that *none* of them represents an integer number of=0A=
> bytes per frame. For example, 23.85 kb/s is 59 bytes plus 5 bits per=
=0A=
> frame. It's definitely not the only cause, but the bottom line is that=
=0A=
> the payload format for AMR-WB (rfc4867) is quite complex. Now compare=
=0A=
> this with the Opus RTP payload=0A=
> (http://tools.ietf.org/html/draft-spittk=
a-payload-rtp-opus). Although=0A=
> it's not complete, it's not only much simpler, but it also makes it=0A=
> possible to decode RTP packets without having even seen the SDP or any=
=0A=
> out-of-band signalling.=0A=
> =0A=
> People may have other definitions, but that's what *I* mean by Opus=0A=
> being an "Internet codec".=0A=
> =0A=
> Cheers,=0A=
> =0A=
>    Jean-Marc=0A=
> =0A=
>>> -----Original Message----- From: rtcweb-bounces at ietf.org=0A=
>>> [mailto:rtcweb-bounces at ietf.org] On Behalf Of ext Stefan Haka=
nsson=0A=
>>> LK Sent: 30 August, 2012 14:58 To: Jean-Marc Valin Cc:=0A=
>>> rtcweb at ietf.org Subject: Re: [rtcweb] Confirmation of conse=
nsus on=0A=
>>> audio codecs=0A=
>>> =0A=
>>> On 08/29/2012 03:10 PM, Jean-Marc Valin wrote:=0A=
>> On 08/29/2012 05:51 AM, Stefan Hakansson LK wrote:=0A=
>>>> ...=0A=
>> =0A=
>>>>>> That is great, but sort of underlines that there w=
ould be no=0A=
>>>>>> harm in delaying the decision until there are expe=
riences=0A=
>>>>>> made from real world use - 'cause it would not be =
that long=0A=
>>>>>> till that experience has been made (Markus also br=
ought up=0A=
>>>>>> the IPR status as a reason for waiting - I have no=
 idea how=0A=
>>>>>> long it would take to know more about that).=0A=
>> =0A=
>> As Harald is pointing out, rtcweb implementations are going to shi=
p =0A=
>> pretty soon.=0A=
>>>> =0A=
>>>> If that is the case (and I think and hope so), why would w=
e need=0A=
>>>> to make it MTI before seeing it in action?=0A=
>>>> =0A=
>>>> [...]=0A=
>>>> =0A=
>> Are you expecting *another* single, standardized, royalty-free cod=
ec =0A=
>> that operates over vast ranges of bitrates and operating condition=
s, =0A=
>> from narrowband speech to stereo music, all with low delay, coming=
=0A=
>> out in the next year? If not, what are you really waiting for?=0A=
>>>> =0A=
>>>> No, I'm not expecting that. I would just prefer us to see =
that=0A=
>>>> Opus does indeed deliver as promised before making it MTI.=
 If it=0A=
>>>> does, fine. If not, we'd have to discuss what to do then.=
=0A=
>>>> =0A=
>>>> To me it is like if you're going to place a bet, for an up=
coming=0A=
>>>> big race, on a horse that has never been in an actual race=
, but=0A=
>>>> shows great promise. If you know that the horse is going t=
o=0A=
>>>> participate in a few practice races soon, would you not pr=
efer to=0A=
>>>> wait and see how it fares in those before placing the bet =
(given=0A=
>>>> that the odds would not change)?=0A=
>>>> =0A=
>>>> Anyway, that's my view. Let's see what the chairs say.=0A=
>> =0A=
>>>>>> As Paul suggested, I was referring to the lack of =
formal,=0A=
>>>>>> controlled, characterization tests. That is how ot=
her SDOs do=0A=
>>>>>> it. I don't think that is the only way to do it, b=
ut I think=0A=
>>>>>> we should at least have either such tests conducte=
d or=0A=
>>>>>> experience from deployment and use (in a wide rang=
e of=0A=
>>>>>> conditions and device types) before making it MTI.=
=0A=
>> =0A=
>> Opus has had "ITU-style" testing on English ( =0A=
>> http://www.opus-codec.org/comparison/Goog=
leTest1.pdf ) and Mandarin=0A=
>> ( http://www.opus-codec.org/comparison/Go=
ogleTest2.pdf ). And if you =0A=
>> don't trust Google on the tests I linked to, it's also been tested=
=0A=
>> by Nokia:=0A=
>> =0A=
>>>> http://research=
.nokia.com/files/public/%5B16%5D_InterSpeech2011_Voice_=0A=
>> =0A=
>>>> =0A=
> Quality_Characterization_of_IETF_Opus_Codec.pdf=0A=
>>>> Come on, those tests are very limited compared to a formal=
=0A=
>>>> characterization test. (Example: =0A=
>>>> www.itu.int/dms_pub/itu-t/opb/tut/T-TUT-ASC-2010-MSW-E.doc=
x).=0A=
>>>> There is very little info on the material used, the enviro=
nment,=0A=
>>>> processing and scripts and so on. And there seems to be no=
 tests=0A=
>>>> whatsoever (at least not involving humans) with actual cha=
nnels=0A=
>>>> introducing jitter and losses.=0A=
>>>> =0A=
>>>> Note: I am in no way proposing that a formal characterizat=
ion=0A=
>>>> test is needed, or even the right thing to do. It is a cos=
tly and=0A=
>>>> time consuming process, and alternative approaches could p=
rove to=0A=
>>>> be more efficient. What I am saying is that I think we sho=
uld not=0A=
>>>> mandate a codec that has neither gone through that kind of=
 formal=0A=
>>>> characterization testing nor has any field experience from=
 actual=0A=
>>>> use on a reasonable scale (covering different conditions a=
nd=0A=
>>>> device types). It just seems wrong, especially given that =
we=0A=
>>>> will soon have field experience.=0A=
>>>> =0A=
>> =0A=
>> Now, unlike other SDOs, the testing did not stop there. ITU-T code=
cs =0A=
>> generally end up being testing with something in the order of tens=
=0A=
>> of minutes worth of audio. In *addition* to that kind of testing,=
=0A=
>> Opus also had automated testing with hundreds of years worth of=0A=
>> audio. If anything, I think other SDOs should learn something here=
.=0A=
>>>> =0A=
>>>> This may very well be true. I guess this comes down to how=
 much=0A=
>>>> you trust that the quality assessment models (e.g. PEAQ, P=
OLQA)=0A=
>>>> give the same result as human test subjects would. But I t=
hink=0A=
>>>> this sounds like a really good thing.=0A=
>>>> =0A=
>> =0A=
>> Jean-Marc=0A=
>> =0A=
>>>> =0A=
>>> =0A=
>>> _______________________________________________ rtcweb mailing=
=0A=
>>> list rtcweb at ietf.org https://www.ietf.org/=
mailman/listinfo/rtcweb=0A=
> _______________________________________________=0A=
> rtcweb mailing list=0A=
> rtcweb at ietf.org=0A=
> https://www.ietf.org/mailman/listinfo/rtcweb

--_000_D79146E3783B6942A3E8BC43352BBB460579F16DTK5EX14MBXC254r_-- From randell-ietf@jesup.org Fri Aug 31 07:46:47 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF4CF21F8661 for ; Fri, 31 Aug 2012 07:46:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, J_CHICKENPOX_55=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kd575oNjCNG7 for ; Fri, 31 Aug 2012 07:46:47 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 32B4921F8639 for ; Fri, 31 Aug 2012 07:46:47 -0700 (PDT) Received: from pool-173-49-141-60.phlapa.fios.verizon.net ([173.49.141.60] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1T7SUf-0007OD-Vy for rtcweb@ietf.org; Fri, 31 Aug 2012 09:46:46 -0500 Message-ID: <5040CE32.5050003@jesup.org> Date: Fri, 31 Aug 2012 10:46:10 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <503F46C5.2090607@alvestrand.no> <503F61CC.1010709@alvestrand.no> <503FC1BF.5020004@alvestrand.no> <5040541C.5020008@alvestrand.no> <20120831133845.GW72831@verdi> In-Reply-To: <20120831133845.GW72831@verdi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [rtcweb] RTCWEB needs an Internet Codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 31 Aug 2012 14:46:48 -0000 On 8/31/2012 9:38 AM, John Leslie wrote: > Harald Alvestrand wrote: >> If necessary, we should make the document more explicit to say that we >> don't solve for use cases where less than 10s of kilobits of Internet >> bandwidth is available... > +1 Agreed. > There are today some use-cases with less than 56Kbps; but they're > dying, and the infrastructure for them isn't being built anywhere > (including third-world countries, if you must ask). > > I'm very glad there _are_ codecs that can operate in such an > environment; but that's not where our effort belongs. We want something > optimized for 5-10 years down John Leslie If you're talking audio-only calls, I agree - but for audio+video, you want a lot of bandwidth available for video. If the user has 128Kbps, I don't want 56K of that devoted to audio; I probably want 15-25K for audio (which can give good wideband or better performance with Opus), and the rest for video. I probably wouldn't open audio up to 56 or 64K (using Opus) below 300-500K of total bandwidth, because of diminishing rate of improvement over ~25K. Having a *good* low-bitrate (and adaptable) audio codec is *critical* to having a good solution for video. Without that all the cases that involve video are blown below 100's of Kbps; with a good low-bandwidth codec you can do video calls with 100Kbps or even less. This is why I support Opus (+G.711 for legacy interop and testing) for MTI. -- Randell Jesup randell-ietf@jesup.org From mandyam@quicinc.com Fri Aug 31 08:04:27 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7AD321F865B for ; Fri, 31 Aug 2012 08:04:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.687 X-Spam-Level: X-Spam-Status: No, score=-5.687 tagged_above=-999 required=5 tests=[AWL=0.312, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B89o21LjbnA1 for ; Fri, 31 Aug 2012 08:04:27 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by ietfa.amsl.com (Postfix) with ESMTP id F16C421F861E for ; Fri, 31 Aug 2012 08:04:26 -0700 (PDT) X-IronPort-AV: E=McAfee;i="5400,1158,6820"; a="231673584" Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by wolverine01.qualcomm.com with ESMTP; 31 Aug 2012 08:03:56 -0700 X-IronPort-AV: E=Sophos;i="4.80,347,1344236400"; d="scan'208";a="318168077" Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 31 Aug 2012 08:03:56 -0700 Received: from NASANEXHC03.na.qualcomm.com (172.30.48.26) by nasanexhc04.na.qualcomm.com (172.30.48.17) with Microsoft SMTP Server (TLS) id 14.2.318.1; Fri, 31 Aug 2012 08:03:55 -0700 Received: from NASANEXD01H.na.qualcomm.com ([169.254.8.250]) by NASANEXHC03.na.qualcomm.com ([172.30.48.26]) with mapi id 14.02.0318.001; Fri, 31 Aug 2012 08:03:55 -0700 From: "Mandyam, Giridhar" To: Harald Alvestrand Thread-Topic: [rtcweb] RTCWEB needs an Internet Codec Thread-Index: AQHNhgORyuEFfQzQ3keG1dHHPO9QYpdypWyAgAAchICAAAO0AP//n3uwgADS5oD//6CkIIABDdcAgAAa3pA= Date: Fri, 31 Aug 2012 15:03:55 +0000 Message-ID: References: <503F46C5.2090607@alvestrand.no> <503F61CC.1010709@alvestrand.no> <503FC1BF.5020004@alvestrand.no> <5040541C.5020008@alvestrand.no> In-Reply-To: <5040541C.5020008@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.45.230.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] RTCWEB needs an Internet Codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 31 Aug 2012 15:04:27 -0000 Harald,=20 I don't think your suggestion is going to work. As Jean-Marc pointed out i= n a separate email, RTP transmission imposes a floor of 16 kbps assuming 20= ms framing. I agree with him. Moreover even though the transmission rate= has to be greater than 10 kbps, the need to use a bandwidth-efficient code= c does not go away. If you want to eliminate the cellular QoS use case altogether, I think you = should explicitly state so. I think this "moves the goalposts" for the Web= RTC effort however, and needs significantly more discussion among the group= . -Giri -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= Harald Alvestrand Sent: Thursday, August 30, 2012 11:05 PM To: Mandyam, Giridhar Cc: rtcweb@ietf.org Subject: Re: [rtcweb] RTCWEB needs an Internet Codec On 08/31/2012 02:20 AM, Mandyam, Giridhar wrote: >> That's not what I said. I said that the *set* of MTI codecs should cover= the use cases. >> We have a requirement (F21) that explicitly mentions commonly supported = codecs in telephony services; there's no way Opus can cover that case. > Apologies - inaccurate wording on my part. I still think it is unrealist= ic for any suite of MTI codecs to cover all use cases. I think the QoS-bas= ed use case still stands as an example of why this is unrealistic. I still think you are constructing an unrealistic use case, and one that is= n't in the document. If necessary, we should make the document more explicit to say that we don'= t solve for use cases where less than 10s of kilobits of Internet bandwidth= is available; I believe the speech quality of Opus is not your biggest pro= blem in that scenario. The purpose of an use case document is to describe the problems we're solvi= ng so that we can separate them from the problems we don't solve.=20 I'd be fine with ruling sustained sub-10-Kbits/sec available Internet bandw= idth explicitly out of scope. >> You're not reading the latest draft. That section is now 4.2.6. > The version I linked to from the RTCWEB status pages is -09, which has th= e relevant use case as 4.2.7 (see http://tools.ietf.org/html/draft-ietf-rtc= web-use-cases-and-requirements-09#section-4.2.7). If the doc is rapidly ev= olving, then the use case doc may not be suitable for evaluation of codecs = for MTI at this point in time. Yes, apologies; I was the one with an unrefreshed archive. > >> Section 4.1 of the draft defines "narrowband" to be "10s to 100s of Kbit= s/sec". > The full text states "Clients can be on narrowband (10s to 100s of Kbits= /sec)". Does this definition refer to codecs or the underlying access tech= nology? I think in the context one could reasonably conclude that "narrowb= and" refers to dial-up or low data rate cellular (e.g. GPRS, GSM HSCSD, 1X)= . The text in 4.1 says nothing about bandlimiting of the input voice signa= l to a codec. Moreover, the ensuing text states "Clients can be on variab= le-media-quality networks (wireless)". To me, this means that the sub-10 k= bps case for voice codecs is still relevant. > >> Respectfully ..... the slight advantage in quality that AMR-NB seems to = offer over Opus at 8 kbps is very different from the advantage that Opus en= joys over G.711 at 64 Kbits and above. > I don't view the quality advantage as 6 kbps as slight, and implementers = still have the option of using Opus at any all data rates without designati= ng it as MTI. Just as implementers can use AMR-WB, G.722 and so on. Moreo= ver, the study I cited did not consider codecs such as EVRC-B that can oper= ate in the sub 5 kbps range. > >>> The initial conclusion from my end is that using Opus when cellular= QoS support results in a guaranteed bit rate less than 8 kbps would not re= sult in the user being "able to take advantage of the QoS support" as per t= he use case. >> Neither does it cover the case where there's not enough bits to carry an= IP+RTP header every 20 milliseconds. There are cases where WebRTC won't wo= rk. > I'm not sure what you are trying to say. Do you believe the use of Opus = will not satisfy the QoS use case? Or do you believe that the QoS use case= is one where WebRTC will simply not work? I believe we'll have a hard time getting the QoS use case working, not beca= use of what you say, but because the QoS APIs on the Internet are still qui= te difficult to use. But this is entirely orthogonal to the codec question. _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From john@jlc.net Fri Aug 31 08:12:48 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F163A21F84E4 for ; Fri, 31 Aug 2012 08:12:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.511 X-Spam-Level: X-Spam-Status: No, score=-105.511 tagged_above=-999 required=5 tests=[AWL=0.488, BAYES_00=-2.599, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X2oW1-pG02vZ for ; Fri, 31 Aug 2012 08:12:48 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 2EBE721F84E6 for ; Fri, 31 Aug 2012 08:12:48 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id DE26C33C24; Fri, 31 Aug 2012 11:12:47 -0400 (EDT) Date: Fri, 31 Aug 2012 11:12:47 -0400 From: John Leslie To: Randell Jesup Message-ID: <20120831151247.GY72831@verdi> References: <503F46C5.2090607@alvestrand.no> <503F61CC.1010709@alvestrand.no> <503FC1BF.5020004@alvestrand.no> <5040541C.5020008@alvestrand.no> <20120831133845.GW72831@verdi> <5040CE32.5050003@jesup.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5040CE32.5050003@jesup.org> User-Agent: Mutt/1.4.1i Cc: rtcweb@ietf.org Subject: Re: [rtcweb] RTCWEB needs an Internet Codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 31 Aug 2012 15:12:49 -0000 Randell Jesup wrote: > > If you're talking audio-only calls, I agree - but for audio+video, you > want a lot of bandwidth available for video. If the user has 128Kbps, I > don't want 56K of that devoted to audio; I probably want 15-25K for > audio (which can give good wideband or better performance with Opus), > and the rest for video. I probably wouldn't open audio up to 56 or 64K > (using Opus) below 300-500K of total bandwidth, because of diminishing > rate of improvement over ~25K. 128Kbps is marginal for audio+video, yes. However, I don't believe it wise for us to try to standardize anything about the audio-vs-video tradeoff. I will state my opinion that good audio plus one frame per second is better in a conferencing environment than bad audio plus 128Kbps of video; but I'd never impose that choice on anyone else. The point is: G.711 is suboptimal, yes, but not unusable. Our issue here is Mandatory-to-Implement. It is very important to have at least one MTI audio codec. I could live with that being G.711, because I trust the market to _actually_ implement others. > Having a *good* low-bitrate (and adaptable) audio codec is *critical* > to having a good solution for video. I'm not sure I agree, though it is certainly _very_ helpful. > Without that all the cases that involve video are blown below 100's > of Kbps; with a good low-bandwidth codec you can do video calls > with 100Kbps or even less. I'm not sure even this will remain true for five years. But I am sure that the market will implement Opus or something like it within five years without our needing to call it MTI. > This is why I support Opus (+G.711 for legacy interop and testing) > for MTI. This _is_ a good argument: I don't mean to ridicule it. But we need to reach closure on this. If enough people are scared of the IPR questions of Opus, I'm willing to retreat to a SHOULD implement Opus. -- John Leslie From mandyam@quicinc.com Fri Aug 31 08:16:42 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EC8E21F8525 for ; Fri, 31 Aug 2012 08:16:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.006 X-Spam-Level: X-Spam-Status: No, score=-6.006 tagged_above=-999 required=5 tests=[AWL=0.592, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id beFYnMMEVAcq for ; Fri, 31 Aug 2012 08:16:36 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by ietfa.amsl.com (Postfix) with ESMTP id D4CEB21F8645 for ; Fri, 31 Aug 2012 08:16:35 -0700 (PDT) X-IronPort-AV: E=McAfee;i="5400,1158,6820"; a="231678852" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by wolverine01.qualcomm.com with ESMTP; 31 Aug 2012 08:16:31 -0700 X-IronPort-AV: E=Sophos;i="4.80,347,1344236400"; d="scan'208,217";a="379384373" Received: from nasanexhc09.na.qualcomm.com ([172.30.39.8]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 31 Aug 2012 08:16:31 -0700 Received: from NASANEXD01H.na.qualcomm.com ([169.254.8.250]) by nasanexhc09.na.qualcomm.com ([172.30.39.8]) with mapi id 14.02.0318.001; Fri, 31 Aug 2012 08:16:31 -0700 From: "Mandyam, Giridhar" To: Koen Vos , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Opus over the Internet? Thread-Index: Ac2HfMsrJ/6oA0BvSY28PJ4c6WjX7AACCdSkAAC8HqA= Date: Fri, 31 Aug 2012 15:16:30 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.45.230.6] Content-Type: multipart/alternative; boundary="_000_CAC8DBE4E9704C41BCB290C2F3CC921A162D2D09nasanexd01hnaqu_" MIME-Version: 1.0 Subject: Re: [rtcweb] Opus over the Internet? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 31 Aug 2012 15:16:42 -0000 --_000_CAC8DBE4E9704C41BCB290C2F3CC921A162D2D09nasanexd01hnaqu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thank you for pointing out these results. I think these results represent a very good start, but the results as provi= ded may not be sufficient to characterize Opus. I've already cited the Dyn= astat study in 3GPP2 for EVRC-B characterization in a separate email. In a= ddition to packet loss (in the 3GPP2 study, the analog would be frame error= rate), background noise conditions were varied (based on MNRU, street nois= e, car noise). This is the kind of testing that is typical for codecs stan= dardized in 3GPP and 3GPP2. There are several details missing. For instance, Was only office noise tested? If so, why? How many listeners were used? What was the mix of talkers (e.g. no. of female, no. of male)? If you can point to more details of the testing, that would be very helpful= for members of the group. -Giri Mandyam From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= Koen Vos Sent: Friday, August 31, 2012 7:38 AM To: rtcweb@ietf.org Subject: Re: [rtcweb] Opus over the Internet? Lars Eggert wrote: > That's all great, but is there any qualitative comparison data of the dif= ferent codecs available? Please have a look at the test Dynastat did with SILK: http://developer.sky= pe.com/resources/SILKDataSheet.pdf Note that SILK in Opus is quite similar to the old SILK tested by Dynastat.= All changes were thoroughly tested to not degrade performance, and in mos= t cases improved it. So the SILK Dynastat results give a lower bound on th= e performance of a subset of the Opus modes. While these plots don't show G.722, it was in fact included in the test for= clean input signals without packet loss. According to the test results: - SILK at 8.85 kbps is outperformed by G.722 at 64 kbps with statistical si= gnificance - SILK at 12.65 kbps is a statistical tie with G.722 at 64 kbps - SILK at 18.85 kbps and above outperforms G.722 at 64 kbps with statistica= l significance. The packet loss in that test was maximally random (ie not bursty). While t= hat may not perfectly mimic real networks, I can think of no reason why the= results would be reversed or very different in practice. To give one more measure of suitability for the Internet: Skype has used SI= LK to deliver 100s of billions of Skype-to-Skype voice minutes over the Int= ernet, and our users are very satisfied with it. Hope this helps, koen. Lars Eggert wrote: That's all great, but is there any qualitative comparison data of the diffe= rent codecs available? -- Sent from a mobile device; please excuse typos. On Aug 30, 2012, at 21:07, "Jean-Marc Valin" wrote= : > On 12-08-30 09:14 AM, Markus.Isomaki at nokia.com wrote: >> Are there any tests that actually compare different codecs, say Opus >> vs. G.722 vs. AMR-WB, in typical Internet use, meaning some loss and >> jitter? I suppose the performance is only partially related to the >> codec, and partially to other implementation decisions, so it might >> be difficult to compare apples-with-apples. But since people are >> arguing that Opus is an "Internet codec", it would be actually nice >> to see some results in this sense. Or does "Internet codec" mean >> something else? > > The term "Internet codec" means different things to different people, > but to me this means more than "having good packet loss concealment". > Sure we have PLC (though it was never compared to G.722 or AMR-WB) and > we also have (optional) low bit-rate embedded redundancy (also called > FEC) and (also optional) independent frames, but that's just one aspect. > > One of the first things we've been asked when designing Opus was to make > the rate *really* adaptable because we never know what kind of rates > will be available. This not only meant having a wide range of bitrates, > but also being able to vary in small increments. This is why Opus scales > from about 6 kb/s to 512 kb/s, in increments of 0.4 kb/s (one byte with > 20 ms frames). Compare that to AMR-WB, which scales from 6.6 to 23.85 in > (on average) ~2.5 kb/s increments. The reason Opus can have more than > 1200 possible bitrates is because on the Internet, other layers in the > protocol stack provide octet granularity framing/sizing. We don't need > to spend 11 bits signalling the bitrate because UDP already encodes the > packet size. > > There's also practical aspects. If you look at the rates supported by > AMR-WB, you see that *none* of them represents an integer number of > bytes per frame. For example, 23.85 kb/s is 59 bytes plus 5 bits per > frame. It's definitely not the only cause, but the bottom line is that > the payload format for AMR-WB (rfc4867) is quite complex. Now compare > this with the Opus RTP payload > (http://tools.ietf.org/html/draft-spittka-payload-rtp-opus). Although > it's not complete, it's not only much simpler, but it also makes it > possible to decode RTP packets without having even seen the SDP or any > out-of-band signalling. > > People may have other definitions, but that's what *I* mean by Opus > being an "Internet codec". > > Cheers, > > Jean-Marc > >>> -----Original Message----- From: rtcweb-bounces at ietf.org >>> [mailto:rtcweb-bounces at ietf.org] On Behalf Of ext Stefan Hakansson >>> LK Sent: 30 August, 2012 14:58 To: Jean-Marc Valin Cc: >>> rtcweb at ietf.org Subject: Re: [rtcweb] Confirmation of consensus on >>> audio codecs >>> >>> On 08/29/2012 03:10 PM, Jean-Marc Valin wrote: >> On 08/29/2012 05:51 AM, Stefan Hakansson LK wrote: >>>> ... >> >>>>>> That is great, but sort of underlines that there would be no >>>>>> harm in delaying the decision until there are experiences >>>>>> made from real world use - 'cause it would not be that long >>>>>> till that experience has been made (Markus also brought up >>>>>> the IPR status as a reason for waiting - I have no idea how >>>>>> long it would take to know more about that). >> >> As Harald is pointing out, rtcweb implementations are going to ship >> pretty soon. >>>> >>>> If that is the case (and I think and hope so), why would we need >>>> to make it MTI before seeing it in action? >>>> >>>> [...] >>>> >> Are you expecting *another* single, standardized, royalty-free codec >> that operates over vast ranges of bitrates and operating conditions, >> from narrowband speech to stereo music, all with low delay, coming >> out in the next year? If not, what are you really waiting for? >>>> >>>> No, I'm not expecting that. I would just prefer us to see that >>>> Opus does indeed deliver as promised before making it MTI. If it >>>> does, fine. If not, we'd have to discuss what to do then. >>>> >>>> To me it is like if you're going to place a bet, for an upcoming >>>> big race, on a horse that has never been in an actual race, but >>>> shows great promise. If you know that the horse is going to >>>> participate in a few practice races soon, would you not prefer to >>>> wait and see how it fares in those before placing the bet (given >>>> that the odds would not change)? >>>> >>>> Anyway, that's my view. Let's see what the chairs say. >> >>>>>> As Paul suggested, I was referring to the lack of formal, >>>>>> controlled, characterization tests. That is how other SDOs do >>>>>> it. I don't think that is the only way to do it, but I think >>>>>> we should at least have either such tests conducted or >>>>>> experience from deployment and use (in a wide range of >>>>>> conditions and device types) before making it MTI. >> >> Opus has had "ITU-style" testing on English ( >> http://www.opus-codec.org/comparison/GoogleTest1.pdf ) and Mandarin >> ( http://www.opus-codec.org/comparison/GoogleTest2.pdf ). And if you >> don't trust Google on the tests I linked to, it's also been tested >> by Nokia: >> >>>> http://research.nokia.com/files/public/%5B16%5D_InterSpeech2011_Voice_ >> >>>> > Quality_Characterization_of_IETF_Opus_Codec.pdf >>>> Come on, those tests are very limited compared to a formal >>>> characterization test. (Example: >>>> www.itu.int/dms_pub/itu-t/opb/tut/T-TUT-ASC-2010-MSW-E.docx). >>>> There is very little info on the material used, the environment, >>>> processing and scripts and so on. And there seems to be no tests >>>> whatsoever (at least not involving humans) with actual channels >>>> introducing jitter and losses. >>>> >>>> Note: I am in no way proposing that a formal characterization >>>> test is needed, or even the right thing to do. It is a costly and >>>> time consuming process, and alternative approaches could prove to >>>> be more efficient. What I am saying is that I think we should not >>>> mandate a codec that has neither gone through that kind of formal >>>> characterization testing nor has any field experience from actual >>>> use on a reasonable scale (covering different conditions and >>>> device types). It just seems wrong, especially given that we >>>> will soon have field experience. >>>> >> >> Now, unlike other SDOs, the testing did not stop there. ITU-T codecs >> generally end up being testing with something in the order of tens >> of minutes worth of audio. In *addition* to that kind of testing, >> Opus also had automated testing with hundreds of years worth of >> audio. If anything, I think other SDOs should learn something here. >>>> >>>> This may very well be true. I guess this comes down to how much >>>> you trust that the quality assessment models (e.g. PEAQ, POLQA) >>>> give the same result as human test subjects would. But I think >>>> this sounds like a really good thing. >>>> >> >> Jean-Marc >> >>>> >>> >>> _______________________________________________ rtcweb mailing >>> list rtcweb at ietf.org https://www.ietf.org/mailman/listinfo/rtcweb > _______________________________________________ > rtcweb mailing list > rtcweb at ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --_000_CAC8DBE4E9704C41BCB290C2F3CC921A162D2D09nasanexd01hnaqu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thank you for pointing ou= t these results.

 <= /p>

I think these results rep= resent a very good start, but the results as provided may not be sufficient= to characterize Opus.  I’ve already cited the Dynastat study in 3GPP2 for EVRC-B characterization in a separate email.  In a= ddition to packet loss (in the 3GPP2 study, the analog would be frame error= rate), background noise conditions were varied (based on MNRU, street nois= e, car noise).  This is the kind of testing that is typical for codecs standardized in 3GPP and 3GPP2.

 <= /p>

There are several details= missing.  For instance,

 <= /p>

Was only office noise tes= ted? If so, why?   

How many listeners were u= sed? 

What was the mix of talke= rs (e.g. no. of female, no. of male)?

 <= /p>

If you can point to more = details of the testing, that would be very helpful for members of the group= .

 <= /p>

-Giri Mandyam<= /span>

 <= /p>

From: rtcweb-b= ounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Koen Vos
Sent: Friday, August 31, 2012 7:38 AM
To: rtcweb@ietf.org
Subject: Re: [rtcweb] Opus over the Internet?

 

Lars Eggert wrote:

> That's all= great, but is there any qualitative comparison data of the different codec= s available?

Please have a look at the test Dynastat did with SILK: http://developer.skype.com/resources/SILKDataSheet.pdf

Note that SILK in Opus is quite similar to the old SILK tested by Dynastat.=   All changes were thoroughly tested to not degrade performance, and i= n most cases improved it.  So the SILK Dynastat results give a lower b= ound on the performance of a subset of the Opus modes.

While these plots don't show G.722, it was in fact included in the test for= clean input signals without packet loss.  According to the test resul= ts:
- SILK at 8.85 kbps is outperformed by G.722 at 64 kbps with statistical si= gnificance
- SILK at 12.65 kbps is a statistical tie with G.722 at 64 kbps
- SILK at 18.85 kbps and above outperforms G.722 at 64 kbps with statistica= l significance.

The packet loss in that test was maximally random (ie not bursty).  Wh= ile that may not perfectly mimic real networks, I can think of no reason wh= y the results would be reversed or very different in practice.

To give one more measure of suitability for the Internet: Skype has used SI= LK to deliver 100s of billions of Skype-to-Skype voice minutes over the Int= ernet, and our users are very satisfied with it.

Hope this helps,
koen.

Lars Eggert wrote:
That's all great, bu=
t is there any qualitative comparison data of the different codecs availabl=
e?
 
-- 
Sent from a mobile device; please excuse t=
ypos.
 
On Aug 30, 2012, at 21:07, "Jean-Marc=
 Valin" <jmvalin at mozilla.com> wrote:
 
> On 12-08-30 09:14 AM, Markus.Isomaki =
at nokia.com wrote:
>> Are there any tests that actually=
 compare different codecs, say Opus
>> vs. G.722 vs. AMR-WB, in typical =
Internet use, meaning some loss and
>> jitter? I suppose the performance=
 is only partially related to the
>> codec, and partially to other imp=
lementation decisions, so it might
>> be difficult to compare apples-wi=
th-apples. But since people are
>> arguing that Opus is an "Int=
ernet codec", it would be actually nice
>> to see some results in this sense=
. Or does "Internet codec" mean
>> something else?=

> 
> The term "Internet codec" m=
eans different things to different people,
> but to me this means more than "=
having good packet loss concealment".
> Sure we have PLC (though it was never=
 compared to G.722 or AMR-WB) and
> we also have (optional) low bit-rate =
embedded redundancy (also called
> FEC) and (also optional) independent =
frames, but that's just one aspect.
> 
> One of the first things we've been as=
ked when designing Opus was to make
> the rate *really* adaptable because w=
e never know what kind of rates
> will be available. This not only mean=
t having a wide range of bitrates,
> but also being able to vary in small =
increments. This is why Opus scales
> from about 6 kb/s to 512 kb/s, in inc=
rements of 0.4 kb/s (one byte with
> 20 ms frames). Compare that to AMR-WB=
, which scales from 6.6 to 23.85 in
> (on average) ~2.5 kb/s increments. Th=
e reason Opus can have more than
> 1200 possible bitrates is because on =
the Internet, other layers in the
> protocol stack provide octet granular=
ity framing/sizing. We don't need
> to spend 11 bits signalling the bitra=
te because UDP already encodes the
> packet size.
> 
> There's also practical aspects. If yo=
u look at the rates supported by
> AMR-WB, you see that *none* of them r=
epresents an integer number of
> bytes per frame. For example, 23.85 k=
b/s is 59 bytes plus 5 bits per
> frame. It's definitely not the only c=
ause, but the bottom line is that
> the payload format for AMR-WB (rfc486=
7) is quite complex. Now compare
> this with the Opus RTP payload
> (http://tools.ietf.org/h=
tml/draft-spittka-payload-rtp-opus). Although
> it's not complete, it's not only much=
 simpler, but it also makes it
> possible to decode RTP packets withou=
t having even seen the SDP or any
> out-of-band signalling.
> 
> People may have other definitions, bu=
t that's what *I* mean by Opus
> being an "Internet codec".<=
o:p>
> 
> Cheers,
> 
>    Jean-Marc
> 
>>> -----Original Message----- Fr=
om: rtcweb-bounces at ietf.org
>>> [mailto:rtcweb-bounces at ietf.org] On Behalf Of=
 ext Stefan Hakansson
>>> LK Sent: 30 August, 2012 14:5=
8 To: Jean-Marc Valin Cc:
>>> rtcweb at ietf.org Subject: R=
e: [rtcweb] Confirmation of consensus on
>>> audio codecs
>>> 
>>> On 08/29/2012 03:10 PM, Jean-=
Marc Valin wrote:
>> On 08/29/2012 05:51 AM, Stefan Ha=
kansson LK wrote:
>>>> ...

>> 


>>>>>> That is great, bu=
t sort of underlines that there would be no


>>>>>> harm in delaying =
the decision until there are experiences


>>>>>> made from real wo=
rld use - 'cause it would not be that long


>>>>>> till that experie=
nce has been made (Markus also brought up


>>>>>> the IPR status as=
 a reason for waiting - I have no idea how


>>>>>> long it would tak=
e to know more about that).


>> 


>> As Harald is pointing out, rtcweb=
 implementations are going to ship 


>> pretty soon.

>>>> 


>>>> If that is the case (and =
I think and hope so), why would we need


>>>> to make it MTI before see=
ing it in action?


>>>> 


>>>> [...]

>>>> 


>> Are you expecting *another* singl=
e, standardized, royalty-free codec 


>> that operates over vast ranges of=
 bitrates and operating conditions, 


>> from narrowband speech to stereo =
music, all with low delay, coming


>> out in the next year? If not, wha=
t are you really waiting for?


>>>> 


>>>> No, I'm not expecting tha=
t. I would just prefer us to see that


>>>> Opus does indeed deliver =
as promised before making it MTI. If it


>>>> does, fine. If not, we'd =
have to discuss what to do then.


>>>> 


>>>> To me it is like if you'r=
e going to place a bet, for an upcoming


>>>> big race, on a horse that=
 has never been in an actual race, but


>>>> shows great promise. If y=
ou know that the horse is going to


>>>> participate in a few prac=
tice races soon, would you not prefer to


>>>> wait and see how it fares=
 in those before placing the bet (given


>>>> that the odds would not c=
hange)?


>>>> 


>>>> Anyway, that's my view. L=
et's see what the chairs say.


>> 


>>>>>> As Paul suggested=
, I was referring to the lack of formal,


>>>>>> controlled, chara=
cterization tests. That is how other SDOs do


>>>>>> it. I don't think=
 that is the only way to do it, but I think


>>>>>> we should at leas=
t have either such tests conducted or


>>>>>> experience from d=
eployment and use (in a wide range of


>>>>>> conditions and de=
vice types) before making it MTI.


>> 


>> Opus has had "ITU-style"=
; testing on English ( 


>> http://www.opus-codec.org=
/comparison/GoogleTest1.pdf ) and Mandarin


>> ( http://www.opus-codec.o=
rg/comparison/GoogleTest2.pdf ). And if you 


>> don't trust Google on the tests I=
 linked to, it's also been tested


>> by Nokia:


>> 


>>>> http://research.nokia.com/files/public/%5B16%5D_InterSpeech2011_Voice_=



>> 


>>>> 


> Quality_Characterization_of_IETF_Opus=
_Codec.pdf


>>>> Come on, those tests are =
very limited compared to a formal


>>>> characterization test. (E=
xample: 


>>>> www.itu.int/dms_pub/i=
tu-t/opb/tut/T-TUT-ASC-2010-MSW-E.docx).


>>>> There is very little info=
 on the material used, the environment,


>>>> processing and scripts an=
d so on. And there seems to be no tests


>>>> whatsoever (at least not =
involving humans) with actual channels


>>>> introducing jitter and lo=
sses.


>>>> 


>>>> Note: I am in no way prop=
osing that a formal characterization


>>>> test is needed, or even t=
he right thing to do. It is a costly and


>>>> time consuming process, a=
nd alternative approaches could prove to


>>>> be more efficient. What I=
 am saying is that I think we should not


>>>> mandate a codec that has =
neither gone through that kind of formal


>>>> characterization testing =
nor has any field experience from actual


>>>> use on a reasonable scale=
 (covering different conditions and


>>>> device types). It just se=
ems wrong, especially given that we


>>>> will soon have field expe=
rience.


>>>> 


>> 


>> Now, unlike other SDOs, the testi=
ng did not stop there. ITU-T codecs 


>> generally end up being testing wi=
th something in the order of tens


>> of minutes worth of audio. In *ad=
dition* to that kind of testing,


>> Opus also had automated testing w=
ith hundreds of years worth of


>> audio. If anything, I think other=
 SDOs should learn something here.


>>>> 


>>>> This may very well be tru=
e. I guess this comes down to how much


>>>> you trust that the qualit=
y assessment models (e.g. PEAQ, POLQA)


>>>> give the same result as h=
uman test subjects would. But I think


>>>> this sounds like a really=
 good thing.


>>>> 


>> 


>> Jean-Marc


>> 


>>>> 


>>> 


>>> _____________________________=
__________________ rtcweb mailing


>>> list rtcweb at ietf.org https=
://www.ietf.org/mailman/listinfo/rtcweb


> _____________________________________=
__________


> rtcweb mailing list=



> rtcweb at ietf.org<=
/pre>

> https://www.ietf.org/mailman/listinfo=
/rtcweb


 
--_000_CAC8DBE4E9704C41BCB290C2F3CC921A162D2D09nasanexd01hnaqu_-- From harald@alvestrand.no Fri Aug 31 08:32:45 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A136D21F8604 for ; Fri, 31 Aug 2012 08:32:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EnN49kz4sOhk for ; Fri, 31 Aug 2012 08:32:44 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 8265521F85B4 for ; Fri, 31 Aug 2012 08:32:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D23BD39E106; Fri, 31 Aug 2012 17:32:42 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JjBSOuwk3gph; Fri, 31 Aug 2012 17:32:42 +0200 (CEST) Received: from [192.168.1.107] (unknown [188.113.88.47]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 4494739E020; Fri, 31 Aug 2012 17:32:42 +0200 (CEST) Message-ID: <5040D91A.9030202@alvestrand.no> Date: Fri, 31 Aug 2012 17:32:42 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: "Mandyam, Giridhar" References: <503F46C5.2090607@alvestrand.no> <503F61CC.1010709@alvestrand.no> <503FC1BF.5020004@alvestrand.no> <5040541C.5020008@alvestrand.no> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] RTCWEB needs an Internet Codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 31 Aug 2012 15:32:45 -0000 On 08/31/2012 05:03 PM, Mandyam, Giridhar wrote: > Harald, > I don't think your suggestion is going to work. As Jean-Marc pointed out in a separate email, RTP transmission imposes a floor of 16 kbps assuming 20 ms framing. I agree with him. Moreover even though the transmission rate has to be greater than 10 kbps, the need to use a bandwidth-efficient codec does not go away. > > If you want to eliminate the cellular QoS use case altogether, I think you should explicitly state so. I think this "moves the goalposts" for the WebRTC effort however, and needs significantly more discussion among the group. > I think you're the one moving the goalposts.... if you want to introduce an use case with audio communcation with an available Internet bit rate significantly below 10 Kbits/second, be my guest. The QoS case is about interacting with QoS mechanisms (bandwidth reservation, DSCP, what have you). Reading it as mandating support for extremely low bandwidths is a stretch. From cb.list6@gmail.com Fri Aug 31 08:40:47 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF03221F8652 for ; Fri, 31 Aug 2012 08:40:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.115 X-Spam-Level: X-Spam-Status: No, score=-3.115 tagged_above=-999 required=5 tests=[AWL=-0.117, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bA0rmKk4b4rR for ; Fri, 31 Aug 2012 08:40:46 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 123F721F8666 for ; Fri, 31 Aug 2012 08:40:45 -0700 (PDT) Received: by lbky2 with SMTP id y2so1587833lbk.31 for ; Fri, 31 Aug 2012 08:40:44 -0700 (PDT) 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=3HbgXL+Ne4LxM0Hv/Dil3X8vWkdb6Bidvwe9pr3dVsQ=; b=CtXnNd4kOq1ySK+WxagH0xMQVMAcMR/h+9rjTRZ5rR4Wkh8w5C621BWJhCPLave7QJ 3bxzJm90/1U3m2plfySPwYioYJ7Nf2n2bCHyMHK6RvP7K+ho27MfVhXK3Iaopq2OoiJt Yn/r/N7Qo9v0vNA9UhZemMz7Xi2NDeQSI0F/2BhrJREuLwcdxFe0FM4pFOc1Ljr++mYv /I0wQj6Gr+d0fAoBch7wD8oMoXmO8vfy02LCvhIebpgSRsq7rnUjFnfdTWx4xfgqDGGq VnPITH1rS1UNaAWxZ1kPwe8q1FsWOoiAPUkBPCMFn7xaOI9ChJ/IVDyVjFjo/Tk8eXrj dPMg== MIME-Version: 1.0 Received: by 10.152.112.233 with SMTP id it9mr6819450lab.40.1346427644797; Fri, 31 Aug 2012 08:40:44 -0700 (PDT) Received: by 10.112.49.66 with HTTP; Fri, 31 Aug 2012 08:40:43 -0700 (PDT) Received: by 10.112.49.66 with HTTP; Fri, 31 Aug 2012 08:40:43 -0700 (PDT) In-Reply-To: <20120831151247.GY72831@verdi> References: <503F46C5.2090607@alvestrand.no> <503F61CC.1010709@alvestrand.no> <503FC1BF.5020004@alvestrand.no> <5040541C.5020008@alvestrand.no> <20120831133845.GW72831@verdi> <5040CE32.5050003@jesup.org> <20120831151247.GY72831@verdi> Date: Fri, 31 Aug 2012 08:40:43 -0700 Message-ID: From: Cameron Byrne To: John Leslie Content-Type: multipart/alternative; boundary=f46d040838d37be4b104c8919dcf Cc: Randell Jesup , rtcweb@ietf.org Subject: Re: [rtcweb] RTCWEB needs an Internet Codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 31 Aug 2012 15:40:47 -0000 --f46d040838d37be4b104c8919dcf Content-Type: text/plain; charset=ISO-8859-1 On Aug 31, 2012 8:13 AM, "John Leslie" wrote: > > Randell Jesup wrote: > > > > If you're talking audio-only calls, I agree - but for audio+video, you > > want a lot of bandwidth available for video. If the user has 128Kbps, I > > don't want 56K of that devoted to audio; I probably want 15-25K for > > audio (which can give good wideband or better performance with Opus), > > and the rest for video. I probably wouldn't open audio up to 56 or 64K > > (using Opus) below 300-500K of total bandwidth, because of diminishing > > rate of improvement over ~25K. > > 128Kbps is marginal for audio+video, yes. > > However, I don't believe it wise for us to try to standardize anything > about the audio-vs-video tradeoff. > > I will state my opinion that good audio plus one frame per second is > better in a conferencing environment than bad audio plus 128Kbps of > video; but I'd never impose that choice on anyone else. > > The point is: G.711 is suboptimal, yes, but not unusable. > > Our issue here is Mandatory-to-Implement. It is very important to > have at least one MTI audio codec. I could live with that being G.711, > because I trust the market to _actually_ implement others. > Agree with the above. G.711 for mti only. I want to push Opus and promote its use, but MTI is not the right method for that. CB > > Having a *good* low-bitrate (and adaptable) audio codec is *critical* > > to having a good solution for video. > > I'm not sure I agree, though it is certainly _very_ helpful. > > > Without that all the cases that involve video are blown below 100's > > of Kbps; with a good low-bandwidth codec you can do video calls > > with 100Kbps or even less. > > I'm not sure even this will remain true for five years. > > But I am sure that the market will implement Opus or something > like it within five years without our needing to call it MTI. > > > This is why I support Opus (+G.711 for legacy interop and testing) > > for MTI. > > This _is_ a good argument: I don't mean to ridicule it. > > But we need to reach closure on this. If enough people are scared > of the IPR questions of Opus, I'm willing to retreat to a SHOULD > implement Opus. > > -- > John Leslie > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --f46d040838d37be4b104c8919dcf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Aug 31, 2012 8:13 AM, "John Leslie" <john@jlc.net> wrote:
>
> Randell Jesup <randell-ie= tf@jesup.org> wrote:
> >
> > If you're talking audio-only calls, I agree - but for audio+v= ideo, you
> > want a lot of bandwidth available for video. =A0If the user has 1= 28Kbps, I
> > don't want 56K of that devoted to audio; I probably want 15-2= 5K for
> > audio (which can give good wideband or better performance with Op= us),
> > and the rest for video. =A0I probably wouldn't open audio up = to 56 or 64K
> > (using Opus) below 300-500K of total bandwidth, because of dimini= shing
> > rate of improvement over ~25K.
>
> =A0 =A0128Kbps is marginal for audio+video, yes.
>
> =A0 =A0However, I don't believe it wise for us to try to standardi= ze anything
> about the audio-vs-video tradeoff.
>
> =A0 =A0I will state my opinion that good audio plus one frame per seco= nd is
> better in a conferencing environment than bad audio plus 128Kbps of > video; but I'd never impose that choice on anyone else.
>
> =A0 =A0The point is: G.711 is suboptimal, yes, but not unusable.
>
> =A0 =A0Our issue here is Mandatory-to-Implement. It is very important = to
> have at least one MTI audio codec. I could live with that being G.711,=
> because I trust the market to _actually_ implement others.
>

Agree with the above. G.711 for mti only.

I want to push Opus and promote its use, but MTI is not the right method= for that.

CB

> > Having a *good* low-bitrate (and adaptable) audio codec is *cr= itical*
> > to having a good solution for video.
>
> =A0 =A0I'm not sure I agree, though it is certainly _very_ helpful= .
>
> > Without that all the cases that involve video are blown below 100= 's
> > of Kbps; with a good low-bandwidth codec you can do video calls > > with 100Kbps or even less.
>
> =A0 =A0I'm not sure even this will remain true for five years.
>
> =A0 =A0But I am sure that the market will implement Opus or something<= br> > like it within five years without our needing to call it MTI.
>
> > This is why I support Opus (+G.711 for legacy interop and testing= )
> > for MTI.
>
> =A0 =A0This _is_ a good argument: I don't mean to ridicule it.
>
> =A0 =A0But we need to reach closure on this. If enough people are scar= ed
> of the IPR questions of Opus, I'm willing to retreat to a SHOULD > implement Opus.
>
> --
> John Leslie <john@jlc.net> > _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.i= etf.org/mailman/listinfo/rtcweb

--f46d040838d37be4b104c8919dcf-- From mandyam@quicinc.com Fri Aug 31 08:58:21 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE71421F849B for ; Fri, 31 Aug 2012 08:58:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.041 X-Spam-Level: X-Spam-Status: No, score=-6.041 tagged_above=-999 required=5 tests=[AWL=0.558, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GirTOuu6pFKO for ; Fri, 31 Aug 2012 08:58:02 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by ietfa.amsl.com (Postfix) with ESMTP id E681F21F8497 for ; Fri, 31 Aug 2012 08:58:02 -0700 (PDT) X-IronPort-AV: E=McAfee;i="5400,1158,6820"; a="231698759" Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by wolverine01.qualcomm.com with ESMTP; 31 Aug 2012 08:57:47 -0700 X-IronPort-AV: E=Sophos;i="4.80,347,1344236400"; d="scan'208";a="318194471" Received: from nasanexhc14.na.qualcomm.com ([172.30.48.23]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 31 Aug 2012 08:57:47 -0700 Received: from NASANEXD01H.na.qualcomm.com ([169.254.8.250]) by nasanexhc14.na.qualcomm.com ([172.30.48.23]) with mapi id 14.02.0318.001; Fri, 31 Aug 2012 08:57:47 -0700 From: "Mandyam, Giridhar" To: Harald Alvestrand Thread-Topic: [rtcweb] RTCWEB needs an Internet Codec Thread-Index: AQHNhgORyuEFfQzQ3keG1dHHPO9QYpdypWyAgAAchICAAAO0AP//n3uwgADS5oD//6CkIIABDdcAgAAa3pCAAIOsAP//itOg Date: Fri, 31 Aug 2012 15:57:46 +0000 Message-ID: References: <503F46C5.2090607@alvestrand.no> <503F61CC.1010709@alvestrand.no> <503FC1BF.5020004@alvestrand.no> <5040541C.5020008@alvestrand.no> <5040D91A.9030202@alvestrand.no> In-Reply-To: <5040D91A.9030202@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.45.230.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] RTCWEB needs an Internet Codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 31 Aug 2012 15:58:21 -0000 Hi Harald, > I think you're the one moving the goalposts.... if you want to introduce = an use case with audio communcation with an available Internet bit rate sig= nificantly below 10 Kbits/second, be my guest. What are you defining as "available internet bit rate"? Is it the bps prov= ided by the access technology to IP? If so, I concede that an IP/UDP/RTP s= ession will require more than 10 kbps from the underlying access technology= . There can be an explicit mention in the document as such if it helps. I= f you are referring to the data rate available to a WebRTC application over= RTP (i.e. the codec rate), then I don't agree that we should limit ourselv= es to only 10 kbps codec settings or greater. =20 > The QoS case is about interacting with QoS mechanisms (bandwidth reservat= ion, DSCP, what have you). Reading it as mandating support for extremely lo= w bandwidths is a stretch. The use case text states "In addition, the user's provider of cellular acce= ss has QoS support enabled." QoS with respect to cellular access is well-un= derstood in the industry, and is not restricted to reservation or DSCP sett= ings. This includes access-network settings for guaranteed bit rate, maxim= um packet delay, acceptable packet loss rate.=20 To clarify, when we mention "low bandwidth" do we mean low bandwidth from a= codec perspective or from an access perspective? =20 -----Original Message----- From: Harald Alvestrand [mailto:harald@alvestrand.no]=20 Sent: Friday, August 31, 2012 8:33 AM To: Mandyam, Giridhar Cc: rtcweb@ietf.org Subject: Re: [rtcweb] RTCWEB needs an Internet Codec On 08/31/2012 05:03 PM, Mandyam, Giridhar wrote: > Harald, > I don't think your suggestion is going to work. As Jean-Marc pointed out= in a separate email, RTP transmission imposes a floor of 16 kbps assuming = 20 ms framing. I agree with him. Moreover even though the transmission ra= te has to be greater than 10 kbps, the need to use a bandwidth-efficient co= dec does not go away. > > If you want to eliminate the cellular QoS use case altogether, I think yo= u should explicitly state so. I think this "moves the goalposts" for the W= ebRTC effort however, and needs significantly more discussion among the gro= up. > I think you're the one moving the goalposts.... if you want to introduce an= use case with audio communcation with an available Internet bit rate signi= ficantly below 10 Kbits/second, be my guest. The QoS case is about interacting with QoS mechanisms (bandwidth reservatio= n, DSCP, what have you). Reading it as mandating support for extremely low = bandwidths is a stretch. From jmvalin@mozilla.com Fri Aug 31 09:34:50 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E43821F8598 for ; Fri, 31 Aug 2012 09:34:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yqa8PMQUIzzk for ; Fri, 31 Aug 2012 09:34:49 -0700 (PDT) Received: from smtp.mozilla.org (mx2.corp.phx1.mozilla.com [63.245.216.70]) by ietfa.amsl.com (Postfix) with ESMTP id 20BC021F849D for ; Fri, 31 Aug 2012 09:34:49 -0700 (PDT) Received: from [192.168.1.15] (modemcable094.20-21-96.mc.videotron.ca [96.21.20.94]) (Authenticated sender: jvalin@mozilla.com) by mx2.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id ADBEDF2625; Fri, 31 Aug 2012 09:34:46 -0700 (PDT) Message-ID: <5040E7A5.50406@mozilla.com> Date: Fri, 31 Aug 2012 12:34:45 -0400 From: Jean-Marc Valin User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: John Leslie References: <503F46C5.2090607@alvestrand.no> <503F61CC.1010709@alvestrand.no> <503FC1BF.5020004@alvestrand.no> <5040541C.5020008@alvestrand.no> <20120831133845.GW72831@verdi> <5040CE32.5050003@jesup.org> <20120831151247.GY72831@verdi> In-Reply-To: <20120831151247.GY72831@verdi> X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Randell Jesup , rtcweb@ietf.org Subject: Re: [rtcweb] RTCWEB needs an Internet Codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 31 Aug 2012 16:34:50 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/31/2012 11:12 AM, John Leslie wrote: > The point is: G.711 is suboptimal, yes, but not unusable. Not necessarily unusable, but it'll pretty much guarantee that nobody will *want* to use webrtc with that kind of quality. Not to mention *actually* unusable below 64 kb/s (+overhead). > Our issue here is Mandatory-to-Implement. It is very important to > have at least one MTI audio codec. I could live with that being > G.711, because I trust the market to _actually_ implement others. Oh, I'm absolutely certain they'd implement other codecs. But how do you know they'll all implement the *same* codec? That's the whole point of MTI. Otherwise we might as well say that the standard is "tin cans with string" and then tell people to add whatever extension is needed to get decent quality. That's not a standard and that's no better than the current situation with plugins. The current situation is this: there's existing platforms from Skype, Google, and others that provide wideband and super-wideband speech at low enough rates for pretty much everyone. And if you use (e.g.) Skype, you know that you can always get super-wideband quality (assuming enough bandwidth). What some here are proposing is a huge step backwards. Why would I use WebRTC over Skype/Google if I'm likely to end up with high bit-rate narrowband just because the person I'm talking to uses a different vendor. Let's at least make sure that WebRTC will be better or equal to other offerings at all time. Otherwise what's the point? And it's not like this is really hard, is it? We have Opus here that's standardized by the IETF (well, in a few days anyway), and it's an improvement on top of what Skype currently ships. I've yet to see a valid reason to settle for less. Jean-Marc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQEcBAEBAgAGBQJQQOelAAoJEJ6/8sItn9q9yuUIAI1NZvZZmwAr2vjrifQUecz2 Zkx4EVPmeDqpmbtt8kCGLozS33w1+TLG8npNPb05Gwndo4Jpv8cgVAH1LFVqJyj3 0278+fYnYGZP6Xa8LEqveQzAaZgNrPEBmVp4ZbwjH9U35j7xuSLw3qbs3dkuE4pt QJshSTiW9ZjoC26O6SBM101EgisLoTkdSIEjKOs46epb6SsIrm/VOhcCc0Gt1xhR /grzxONeiKnOX/uS0bUDMEAMfobrDQxRwakiCFEIxBa7JLvcoLj18t1IeHhQ6vNU /K+IV3a0a8COc0HiVETznarAOgHSNLH/Vww9hZf+dO2R2cIxASGiVoDFQzdkxWc= =w4qQ -----END PGP SIGNATURE----- From roman@telurix.com Fri Aug 31 10:23:22 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FA7A21F85B4 for ; Fri, 31 Aug 2012 10:23:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.862 X-Spam-Level: X-Spam-Status: No, score=-2.862 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H7s9OjweUG7X for ; Fri, 31 Aug 2012 10:23:20 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3527621F859A for ; Fri, 31 Aug 2012 10:23:20 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so4976455pbb.31 for ; Fri, 31 Aug 2012 10:23:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=gN9f7gUXtSNndhVwe/bw51WIyKVX2KC7oXBX4S5ywFo=; b=d3aClQZorHqZLYUYhrFA1IFaqAF/r0EzS4BFIQ769UbXHFJ3CZpe20cApmZ0oDOvIA 3qb5dcW64PcXxlLudjWql8fnNXAKOG8OYPvGvPMGIx//k4vEPCvf+POzNeMgw5tiePlN VD0Iq296FDHdzmZvCKvelpj6wR4N8ZmiBzC3yEe2OCjNzVWyEcA9sPhRuHxZnshxtZ9U 8Bbbkn/ovwevNepg3Lb+28W6vjliKmlLsjOv6opMzRmzcojAALaLrW5eSDAeb2T8JyL0 /bcVhDDhspuUIoEoJ2TNNJd01xfkiVSB8tyvHORlFLl1L1BPxYLlz6r4TmT2dcs+4HJS qzIg== Received: by 10.68.129.168 with SMTP id nx8mr18291526pbb.112.1346433799742; Fri, 31 Aug 2012 10:23:19 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by mx.google.com with ESMTPS id tt6sm1423162pbc.51.2012.08.31.10.23.17 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 31 Aug 2012 10:23:18 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so4976377pbb.31 for ; Fri, 31 Aug 2012 10:23:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.203.98 with SMTP id kp2mr18263198pbc.132.1346433796424; Fri, 31 Aug 2012 10:23:16 -0700 (PDT) Received: by 10.68.47.8 with HTTP; Fri, 31 Aug 2012 10:23:15 -0700 (PDT) In-Reply-To: <5040E7A5.50406@mozilla.com> References: <503F46C5.2090607@alvestrand.no> <503F61CC.1010709@alvestrand.no> <503FC1BF.5020004@alvestrand.no> <5040541C.5020008@alvestrand.no> <20120831133845.GW72831@verdi> <5040CE32.5050003@jesup.org> <20120831151247.GY72831@verdi> <5040E7A5.50406@mozilla.com> Date: Fri, 31 Aug 2012 20:23:15 +0300 Message-ID: From: Roman Shpount To: Jean-Marc Valin Content-Type: multipart/alternative; boundary=047d7b10cdd52644f904c8930cde X-Gm-Message-State: ALoCoQn08pSNGkjLZmS655oxJiSyCIS44yiXUBNbqupnGgmCn8dHtNaEvmVqG93wJcGe2Xly+/C3 Cc: Randell Jesup , rtcweb@ietf.org Subject: Re: [rtcweb] RTCWEB needs an Internet Codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 31 Aug 2012 17:23:22 -0000 --047d7b10cdd52644f904c8930cde Content-Type: text/plain; charset=ISO-8859-1 One issue I want to bring into consideration is computation complexity of Opus. It is normally acceptable for end user devices in point-to-point calls (I do not want to start all the mobile device CPU vs battery live discussion. It is irrelevant), but in cases where you need to process all the calls on some sort of central server (such as conferencing, or virtual reality, or massive multi-player games) the additional processing cost of supporting Opus can be significant. In such cases G.722 (ideally in combination with PLC and CN to save bandwidth) can be a valid compromise, since it can provide quality better then G.711 with CPU processing requirements order of magnitude less then Opus. My point is I see no downside of making G.722 an MTI codec in addition to G.711 and Opus. Additional code is minimal and well understood, there are no royalties. On the upside there are at least two significant use cases (conferencing or other central audio processing scenarious and interop with enterprise equipment) that will justify this. _____________ Roman Shpount On Fri, Aug 31, 2012 at 7:34 PM, Jean-Marc Valin wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 08/31/2012 11:12 AM, John Leslie wrote: > > The point is: G.711 is suboptimal, yes, but not unusable. > > Not necessarily unusable, but it'll pretty much guarantee that nobody > will *want* to use webrtc with that kind of quality. Not to mention > *actually* unusable below 64 kb/s (+overhead). > > > Our issue here is Mandatory-to-Implement. It is very important to > > have at least one MTI audio codec. I could live with that being > > G.711, because I trust the market to _actually_ implement others. > > Oh, I'm absolutely certain they'd implement other codecs. But how do > you know they'll all implement the *same* codec? That's the whole > point of MTI. Otherwise we might as well say that the standard is "tin > cans with string" and then tell people to add whatever extension is > needed to get decent quality. That's not a standard and that's no > better than the current situation with plugins. > > The current situation is this: there's existing platforms from Skype, > Google, and others that provide wideband and super-wideband speech at > low enough rates for pretty much everyone. And if you use (e.g.) > Skype, you know that you can always get super-wideband quality > (assuming enough bandwidth). What some here are proposing is a huge > step backwards. Why would I use WebRTC over Skype/Google if I'm likely > to end up with high bit-rate narrowband just because the person I'm > talking to uses a different vendor. Let's at least make sure that > WebRTC will be better or equal to other offerings at all time. > Otherwise what's the point? And it's not like this is really hard, is > it? We have Opus here that's standardized by the IETF (well, in a few > days anyway), and it's an improvement on top of what Skype currently > ships. I've yet to see a valid reason to settle for less. > > Jean-Marc > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.12 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ > > iQEcBAEBAgAGBQJQQOelAAoJEJ6/8sItn9q9yuUIAI1NZvZZmwAr2vjrifQUecz2 > Zkx4EVPmeDqpmbtt8kCGLozS33w1+TLG8npNPb05Gwndo4Jpv8cgVAH1LFVqJyj3 > 0278+fYnYGZP6Xa8LEqveQzAaZgNrPEBmVp4ZbwjH9U35j7xuSLw3qbs3dkuE4pt > QJshSTiW9ZjoC26O6SBM101EgisLoTkdSIEjKOs46epb6SsIrm/VOhcCc0Gt1xhR > /grzxONeiKnOX/uS0bUDMEAMfobrDQxRwakiCFEIxBa7JLvcoLj18t1IeHhQ6vNU > /K+IV3a0a8COc0HiVETznarAOgHSNLH/Vww9hZf+dO2R2cIxASGiVoDFQzdkxWc= > =w4qQ > -----END PGP SIGNATURE----- > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --047d7b10cdd52644f904c8930cde Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable One issue I want to bring into consideration is computation complexity of O= pus. It is normally acceptable for end user devices in point-to-point calls= (I do not want to start all the mobile device CPU vs battery live discussi= on. It is irrelevant), but in cases where you need to process all the calls= on some sort of central server (such as conferencing, or virtual reality, = or massive multi-player games) the additional processing cost of supporting= Opus can be significant. In such cases G.722 (ideally in combination with= =A0 PLC=A0and=A0CN to save bandwidth) can be a valid compromise, since it can p= rovide quality better then G.711 with CPU processing requirements order of = magnitude less then Opus.

My point is I see no downside = of making G.722 an MTI codec in addition to G.711 and Opus. Additional code= is minimal and well understood, there are no royalties. On the upside ther= e are at least two significant use cases (conferencing or other central aud= io processing scenarious and interop with enterprise equipment) that will j= ustify this.
_____________
Roman Shpount


On Fri, Aug 31, 2012 at 7:34 PM, Jean-Ma= rc Valin <jmvalin@mozilla.com> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 08/31/2012 11:12 AM, John Leslie wrote:
> The point is: G.711 is suboptimal, yes, but not unusable.

Not necessarily unusable, but it'll pretty much guarantee that no= body
will *want* to use webrtc with that kind of quality. Not to mention
*actually* unusable below 64 kb/s (+overhead).

> Our issue here is Mandatory-to-Implement. It is very important to
> have at least one MTI audio codec. I could live with that being
> G.711, because I trust the market to _actually_ implement others.

Oh, I'm absolutely certain they'd implement other codecs. But= how do
you know they'll all implement the *same* codec? That's the whole point of MTI. Otherwise we might as well say that the standard is "tin=
cans with string" and then tell people to add whatever extension is needed to get decent quality. That's not a standard and that's no better than the current situation with plugins.

The current situation is this: there's existing platforms from Skype, Google, and others that provide wideband and super-wideband speech at
low enough rates for pretty much everyone. And if you use (e.g.)
Skype, you know that you can always get super-wideband quality
(assuming enough bandwidth). What some here are proposing is a huge
step backwards. Why would I use WebRTC over Skype/Google if I'm likely<= br> to end up with high bit-rate narrowband just because the person I'm
talking to uses a different vendor. Let's at least make sure that
WebRTC will be better or equal to other offerings at all time.
Otherwise what's the point? And it's not like this is really hard, = is
it? We have Opus here that's standardized by the IETF (well, in a few days anyway), and it's an improvement on top of what Skype currently ships. I've yet to see a valid reason to settle for less.

=A0 =A0 =A0 =A0 Jean-Marc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iQEcBAEBAgAGBQJQQOelAAoJEJ6/8sItn9q9yuUIAI1NZvZZmwAr2vjrifQUecz2
Zkx4EVPmeDqpmbtt8kCGLozS33w1+TLG8npNPb05Gwndo4Jpv8cgVAH1LFVqJyj3
0278+fYnYGZP6Xa8LEqveQzAaZgNrPEBmVp4ZbwjH9U35j7xuSLw3qbs3dkuE4pt
QJshSTiW9ZjoC26O6SBM101EgisLoTkdSIEjKOs46epb6SsIrm/VOhcCc0Gt1xhR
/grzxONeiKnOX/uS0bUDMEAMfobrDQxRwakiCFEIxBa7JLvcoLj18t1IeHhQ6vNU
/K+IV3a0a8COc0HiVETznarAOgHSNLH/Vww9hZf+dO2R2cIxASGiVoDFQzdkxWc=3D
=3Dw4qQ
-----END PGP SIGNATURE-----
___________________________________= ____________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb

--047d7b10cdd52644f904c8930cde-- From mandyam@quicinc.com Fri Aug 31 10:25:36 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCCD121F8629 for ; Fri, 31 Aug 2012 10:25:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.072 X-Spam-Level: X-Spam-Status: No, score=-6.072 tagged_above=-999 required=5 tests=[AWL=0.527, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23tHkub6plGB for ; Fri, 31 Aug 2012 10:25:35 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id 7940121F8627 for ; Fri, 31 Aug 2012 10:25:35 -0700 (PDT) X-IronPort-AV: E=McAfee;i="5400,1158,6821"; a="229440768" Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by wolverine02.qualcomm.com with ESMTP; 31 Aug 2012 10:25:34 -0700 X-IronPort-AV: E=Sophos;i="4.80,348,1344236400"; d="scan'208";a="318248905" Received: from nasanexhc10.na.qualcomm.com ([172.30.48.3]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 31 Aug 2012 10:25:34 -0700 Received: from NASANEXD01H.na.qualcomm.com ([169.254.8.250]) by nasanexhc10.na.qualcomm.com ([172.30.48.3]) with mapi id 14.02.0318.001; Fri, 31 Aug 2012 10:25:34 -0700 From: "Mandyam, Giridhar" To: Jean-Marc Valin Thread-Topic: [rtcweb] RTCWEB needs an Internet Codec Thread-Index: AQHNhgORyuEFfQzQ3keG1dHHPO9QYpdypWyAgAAchICAAAO0AP//n3uwgADSpQD//6kqkIAAvFGA//+OK5A= Date: Fri, 31 Aug 2012 17:25:33 +0000 Message-ID: References: <503F46C5.2090607@alvestrand.no> <503F61CC.1010709@alvestrand.no> <503FC188.5050003@mozilla.com> <504016A9.5000805@mozilla.com> In-Reply-To: <504016A9.5000805@mozilla.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.45.230.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] RTCWEB needs an Internet Codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 31 Aug 2012 17:25:36 -0000 >Here's the thing. I'm not trying to prevent you from including AMR-NB or a= ny other codec. If all you have is 6 kb/s and you have AMR-NB on both ends,= then by all means use that. But what if that's not the case and only one s= ide supports it? If only G.711 is >MTI, then the negotiation *fails*. And i= t won't just fail at 6 kb/s. It'll fail all the way up to 64 kb/s and that'= s unacceptable. OTOH, if you have Opus as MTI, you'll still be able to talk= , which is big improvement, even if the quality isn't nearly as good as AMR= ->NB or EVRC-B at these ridiculously low bitrates. Essentially, I've yet to= understand your reasoning that because Opus is "only" optimal for 99% of t= he use cases, then we should use something (G.711) that's highly suboptimal= in all use cases. I'm not sure I understand your logic either. You could make the same argum= ent in favor of having AMR-NB or EVRC-B as MTI. Why not do so and cover 10= 0% of the use cases? In addition, I don't view all use cases as being of equal importance (at le= ast with initial implementations). Conversational voice over cellular must= work for WebRTC. =20 Moreover, I don't believe the standardization process for any codec suitabl= e for conversational voice is complete without a characterization under los= sy conditions and with human listeners (true MOS score). This is the appro= ach that standards bodies such as 3GPP and 3GPP2 have taken towards codec s= tandardization. I think the studies you pointed to in a separate email (fr= om Google and Nokia) are a good start, but until we see testing like the Dy= nastat study I referenced in my previous email then to say Opus satisfies a= ny of the conversational voice use cases is premature. Implementers that choose not to use the best possible codec under common op= erating conditions (e.g. ridiculously low bitrates, which happens frequentl= y in cellular environments) will suffer in the marketplace as a result. Bu= t this is not an issue for standardization. > Sure, go as low as you like. There's even codecs that work at 2 kb/s and = below if you like. If both sides support it, it's all good. But when all we= have in common are the MTI codecs, then please let's make webrtc not suck = or (worse) fail completely. No, it's not good. 2 kb/s codecs such as MELP are not toll quality. Intel= ligibility alone may be OK for military applications, but toll quality is a= requirement for consumer apps. > I'm sure most people prefer 1) and I still don't understand why you would= prefer option 2). Option 2) essentially means "we have a really crappy sta= ndard which can only work decently if you have extensions". Implementers are expected to support more codecs than just whatever is MTI.= As Ted mentioned in another email, one of the goals of RTCWeb is promotin= g support for native codecs: At 8:39 PM -0700 8/21/12, Ted Hardie wrote: > the fundamental design of RTCWEB allows for the negotiation of any=20 > codec mutually supported. The decision to chose a =20 > Mandatory-to-implement was not made to eliminate other choices, but to =20 > eliminate interoperability failures by ensuring that at least one =20 > common codec is always available. Codecs should be MTI only to prevent negotiation failure, not to guarantee = ideal performance, especially in light of Ted's next statement: At 8:39 PM -0700 8/21/12, Ted Hardie wrote: > the group presumes that codec support does not come from the=20 > downloadable Javascript application, but from the application=20 > environment into which it is downloaded (commonly a browser or mobile=20 > environment using similar technology). Promoting support for those=20 > environments to have access to codecs supported by the underlying=20 > hardware is the best way to further this goal, at least in my=20 > personal opinion. Moreover, claiming that access to codecs such as AMR is only possible with = software extensions ignores the installed base in the handheld market. Dev= elopers can certainly have access to such implementations, and shouldn't ha= ve to burden themselves with implementing more codecs than minimally necess= ary because of MTI requirements. -----Original Message----- From: Jean-Marc Valin [mailto:jmvalin@mozilla.com]=20 Sent: Thursday, August 30, 2012 6:43 PM To: Mandyam, Giridhar Cc: Harald Alvestrand; DRAGE, Keith (Keith); rtcweb@ietf.org Subject: Re: [rtcweb] RTCWEB needs an Internet Codec -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/30/2012 08:18 PM, Mandyam, Giridhar wrote: > I don't follow. If both parties in the call support a codec suitable=20 > for 6 kb/s (e.g. AMR-NB) then there should be no negotiation failure.=20 > MTI still allows for non-MTI codecs to be used on a WebRTC call. The=20 > point I was trying to make was that Opus does not satisfy the use case=20 > as specified. I never said that > G.711 satisfied this use case. I believe it is unrealistic to require=20 > that the set of MTI audio codecs (whatever they may be) satisfy every=20 > single use case as currently outlined. Here's the thing. I'm not trying to prevent you from including AMR-NB or an= y other codec. If all you have is 6 kb/s and you have AMR-NB on both ends, = then by all means use that. But what if that's not the case and only one si= de supports it? If only G.711 is MTI, then the negotiation *fails*. And it = won't just fail at 6 kb/s. It'll fail all the way up to 64 kb/s and that's = unacceptable. OTOH, if you have Opus as MTI, you'll still be able to talk, = which is big improvement, even if the quality isn't nearly as good as AMR-N= B or EVRC-B at these ridiculously low bitrates. Essentially, I've yet to un= derstand your reasoning that because Opus is "only" optimal for 99% of the = use cases, then we should use something (G.711) that's highly suboptimal in= all use cases. The way I see this shaping up, it seems highly likely that > All the more reason to achieve toll quality at codec data rates below=20 > 8 kbps when operating in a cellular environment. Sure, go as low as you like. There's even codecs that work at 2 kb/s and be= low if you like. If both sides support it, it's all good. But when all we h= ave in common are the MTI codecs, then please let's make webrtc not suck or= (worse) fail completely. > I've already stated my position on MTI audio codecs on this mailing=20 > list. I never advocated making every codec that is optimal given a=20 > particular operating condition as MTI. I also think the performance=20 > loss due to the use of Opus at sub 10 kbps is not trivial, and it is=20 > worth leveraging other codecs at these lower data rates. So here's the options we're looking at in the cases where all you have in c= ommon are MTI codecs (and it seems that those will be common): 1) Optimal quality at almost all rates, but sub-optimal below 10 kb/s; or 2) Highly sub-optimal at 64 kb/s and above, with completely failure below 6= 4 kb/s. I'm sure most people prefer 1) and I still don't understand why you would p= refer option 2). Option 2) essentially means "we have a really crappy stand= ard which can only work decently if you have extensions". Jean-Marc > -----Original Message----- From: Jean-Marc Valin=20 > [mailto:jmvalin@mozilla.com] Sent: Thursday, August 30, 2012 12:40 PM=20 > To: Mandyam, Giridhar Cc: Harald Alvestrand; DRAGE, Keith (Keith);=20 > rtcweb@ietf.org Subject: Re: [rtcweb] RTCWEB needs an Internet Codec >=20 > On 12-08-30 03:13 PM, Mandyam, Giridhar wrote: >> The study available at >> http://research.nokia.com/files/public/%5B16%5D_InterSpeech2011_Voice >> _ >> >> >>=20 Quality_Characterization_of_IETF_Opus_Codec.pdf >> clearly shows a significant advantage in MOS scores at 5.9 kbps for=20 >> AMR-NB as compared to Opus (Silk). The initial conclusion from my=20 >> end is that using Opus when cellular QoS support results in a=20 >> guaranteed bit rate less than 8 kbps would not result in the user=20 >> being "able to take advantage of the QoS support" as per the use=20 >> case. >=20 > So because Opus is better except around 6 kb/s means that we have=20 > negotiation failure and that we should instead use G.711 at 64 kb/s?=20 > Also, keep in mind that browser-to-browser means RTP, which typically=20 > means 16 kb/s worth of overhead anyway (with 20 ms frames). Even=20 > though Opus is not optimal at 6 kb/s, we still have something that=20 > works and we avoid interop failure. And what are the alternatives=20 > anyway? If we only decide on G.711, then we not only have=20 > embarrassingly bad quality, but we also have interop failure below 64=20 > kb/s. If you want guaranteed good quality without Opus, you can also=20 > make AMR-NB, AMR-WB, G.722.1C, AAC-LD, HE-AAC, and AAC-LC all MTI.=20 > Then you'll have (on average) quality that's almost as good as Opus=20 > alone can do, you'll cover almost as many use cases, and as a bonus,=20 > you get all the negotiation and switching nightmares involved. >=20 > Jean-Marc >=20 >> -----Original Message----- From: rtcweb-bounces@ietf.org=20 >> [mailto:rtcweb-bounces@ietf.org] On Behalf Of Harald Alvestrand >> Sent: Thursday, August 30, 2012 5:51 AM To: DRAGE, Keith (Keith) >> Cc: rtcweb@ietf.org Subject: Re: [rtcweb] RTCWEB needs an Internet=20 >> Codec >>=20 >> On 08/30/2012 02:38 PM, DRAGE, Keith (Keith) wrote: >>> Surely that argument extends to every possible codec. >> The set of MTI codecs should cover the set of use cases that have=20 >> been identified. Additional MTI codecs that don't cover new use cases=20 >> shouldn't be added. >>=20 >> I believe the use case "distributed music band" in=20 >> draft-ietf-rtcweb-use-cases-and-requirements can't be satisified with=20 >> G.711. >>=20 >>>=20 >>> If the codecs supported by both endpoints do not supply the=20 >>> characteristics needed for the communication, then you will get =20 >>> interoperability failure. >>>=20 >>> If I want more bandwidth or quality than OPUS supplies, then I will=20 >>> also get interoperability failure. >>>=20 >>> Keith >>>=20 >>>> -----Original Message----- From: rtcweb-bounces@ietf.org=20 >>>> [mailto:rtcweb-bounces@ietf.org] On Behalf Of Harald Alvestrand=20 >>>> Sent: 30 August 2012 11:56 To: rtcweb@ietf.org >>>> Subject: Re: [rtcweb] RTCWEB needs an Internet Codec >>>>=20 >>>> The counterpoint is that having G.711 as the only MTI means that=20 >>>> you get interoperability failure for any application in which G.711=20 >>>> sound quality is not acceptable. >>>>=20 >>>> This includes all applications involving music. >>>>=20 >>>> On 08/29/2012 06:30 PM, Randall Gellens wrote: >>>>> At 12:13 AM -0400 8/29/12, Roman Shpount wrote: >>>>>=20 >>>>>> I would argue G.711 should be the MTI codec. The rest can be left=20 >>>>>> up to browser implementers. >>>>> I agree. >>>>>=20 >>>>>> We can argue all we want, but the best royalty free low bitrate=20 >>>>>> codec available will be the one everybody supports. >>>>> Very good point, and why we should mandate only one audio codec. >>>>>=20 >>>> _______________________________________________ rtcweb mailing list=20 >>>> rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb >>=20 >> _______________________________________________ rtcweb mailing list=20 >> rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb >> _______________________________________________ rtcweb mailing list=20 >> rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb >>=20 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQEcBAEBAgAGBQJQQBapAAoJEJ6/8sItn9q9pioH/iR6CTa6iLdN3wkuK5O1XbsI /2JY3zqUaqlokaivWZzl0imCN5Rnkfl9Y7l3kyeBPXv6P++VJ5HG/9xTX9Pm+OKE HNEI4nE5npiA+A5FoDqR2rcHprj2hPjRM3J62uFgxk9Kof4onQTMG87AUCAUciyN aBfrzDVBiSz68Ha51yYM5oOHiZzBHRW9Ysccbf6DrkzzcuKoavs+OJ7bVaKSuc2I 4TsEdP33qJa+NHsOzCeFIZ6xmC/wSpF5/3oXNEaV/Mz5zUoTA2I1Cfr4G/vP/YIW r4JMzPh+kwXJQ4Aawiv6eyP5KRI4hRkSkXoP7brfG+ZoVr44HKyGCnNywXYtXac=3D =3DjjKQ -----END PGP SIGNATURE----- From tim@phonefromhere.com Fri Aug 31 12:43:13 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 856F621F84B5 for ; Fri, 31 Aug 2012 12:43:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uEUNYHYaLnT7 for ; Fri, 31 Aug 2012 12:43:13 -0700 (PDT) Received: from zimbra.westhawk.co.uk (zimbra.westhawk.co.uk [192.67.4.167]) by ietfa.amsl.com (Postfix) with ESMTP id AAB0921F847F for ; Fri, 31 Aug 2012 12:43:12 -0700 (PDT) Received: from [10.0.2.85] (unknown [65.161.207.100]) by zimbra.westhawk.co.uk (Postfix) with ESMTP id E768037A902; Fri, 31 Aug 2012 20:52:09 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_5E40EA51-2ADD-4BAA-AF50-2C0995FEA138" From: Tim Panton In-Reply-To: Date: Fri, 31 Aug 2012 12:42:57 -0700 Message-Id: References: <503F46C5.2090607@alvestrand.no> <503F61CC.1010709@alvestrand.no> <503FC188.5050003@mozilla.com> <504016A9.5000805@mozilla.com> To: "Mandyam, Giridhar" X-Mailer: Apple Mail (2.1278) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] RTCWEB needs an Internet Codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 31 Aug 2012 19:43:13 -0000 --Apple-Mail=_5E40EA51-2ADD-4BAA-AF50-2C0995FEA138 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 31 Aug 2012, at 10:25, Mandyam, Giridhar wrote: > In addition, I don't view all use cases as being of equal importance = (at least with initial implementations). Conversational voice over = cellular must work for WebRTC.=20 All use cases are equal, but some are more equal than others ? I think it is a _huge_ mistake to assume we know what will be important = use cases for webRTC.=20 The use case you cite is _very_ well served by adding a tel: url to a = mobile web page and placing a 2g gsm call. Tim. --Apple-Mail=_5E40EA51-2ADD-4BAA-AF50-2C0995FEA138 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
In addition, = I don't view all use cases as being of equal importance (at least with = initial implementations).  Conversational voice over cellular must = work for WebRTC. 
All= use cases are equal, but some are more equal than others = ?

I think it is a _huge_ mistake to assume we know = what will be important use cases for webRTC. 
The use = case you cite is _very_ well served by adding a tel: url to a mobile web = page and placing a 2g gsm = call.

Tim.

= --Apple-Mail=_5E40EA51-2ADD-4BAA-AF50-2C0995FEA138-- From koen.vos@skype.net Fri Aug 31 13:30:23 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4947221F8527 for ; Fri, 31 Aug 2012 13:30:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u4sxFqpbFeQh for ; Fri, 31 Aug 2012 13:30:21 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe006.messaging.microsoft.com [216.32.181.186]) by ietfa.amsl.com (Postfix) with ESMTP id B128421F8517 for ; Fri, 31 Aug 2012 13:30:20 -0700 (PDT) Received: from mail159-ch1-R.bigfish.com (10.43.68.247) by CH1EHSOBE014.bigfish.com (10.43.70.64) with Microsoft SMTP Server id 14.1.225.23; Fri, 31 Aug 2012 20:30:19 +0000 Received: from mail159-ch1 (localhost [127.0.0.1]) by mail159-ch1-R.bigfish.com (Postfix) with ESMTP id DD31F440348; Fri, 31 Aug 2012 20:30:19 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC102.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -39 X-BigFish: VS-39(zzbb2dI98dI9371I936eI146fIc85eh542M1432I328cMzz1202hzz1033IL8275bh8275dh5eeeKz2fh2a8h668h839hd25hf0ah107ah1155h) Received-SPF: pass (mail159-ch1: domain of skype.net designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=koen.vos@skype.net; helo=TK5EX14MLTC102.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail159-ch1 (localhost.localdomain [127.0.0.1]) by mail159-ch1 (MessageSwitch) id 1346445016865973_10694; Fri, 31 Aug 2012 20:30:16 +0000 (UTC) Received: from CH1EHSMHS022.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.234]) by mail159-ch1.bigfish.com (Postfix) with ESMTP id C5ABB200048; Fri, 31 Aug 2012 20:30:16 +0000 (UTC) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (131.107.125.8) by CH1EHSMHS022.bigfish.com (10.43.70.22) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 31 Aug 2012 20:30:13 +0000 Received: from TK5EX14MBXC254.redmond.corp.microsoft.com ([169.254.2.17]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.02.0318.003; Fri, 31 Aug 2012 20:30:12 +0000 From: Koen Vos To: "Mandyam, Giridhar" , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Opus over the Internet? Thread-Index: Ac2HfMsr5I6cHStDRl6nZRUBJnCOJAACCdSkAAGpngAACce2rA== Date: Fri, 31 Aug 2012 20:30:11 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.33] Content-Type: multipart/alternative; boundary="_000_D79146E3783B6942A3E8BC43352BBB460579F1EDTK5EX14MBXC254r_" MIME-Version: 1.0 X-OriginatorOrg: skype.net Subject: Re: [rtcweb] Opus over the Internet? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 31 Aug 2012 20:30:23 -0000 --_000_D79146E3783B6942A3E8BC43352BBB460579F1EDTK5EX14MBXC254r_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Giri, Dynastat's subjective test involved the following design parameters: - subjects: 32, four panels of eight subjects, native speakers of North Ame= rican English - randomizations: one per listening panel - talkers: eight (four males, four females), native speakers of North Ameri= can English - speech samples: four 8 sec. sentence-pairs per talker - experimental design: partially-balanced, randomized-blocks Dynastat constructed the randomizations (i.e., pseudo-randomized presentati= on sequences) for each listening panel. Each randomization included 256 tri= als (i.e., 8 talkers x 32 test conditions). We tested only office noise at 15 dB SNR because we didn't have more condit= ions available. As web browsers are commonly used in an office, knowledge of a codec's perf= ormance in that kind of environment would seem helpful to this working grou= p. Do I understand correctly that the 3GPP and 3GPP2 tests did not include= any office noise conditions? best, koen. ________________________________ From: Mandyam, Giridhar [mandyam@quicinc.com] Sent: Friday, August 31, 2012 8:16 AM To: Koen Vos; rtcweb@ietf.org Subject: RE: [rtcweb] Opus over the Internet? Thank you for pointing out these results. I think these results represent a very good start, but the results as provi= ded may not be sufficient to characterize Opus. I=92ve already cited the D= ynastat study in 3GPP2 for EVRC-B characterization in a separate email. In= addition to packet loss (in the 3GPP2 study, the analog would be frame err= or rate), background noise conditions were varied (based on MNRU, street no= ise, car noise). This is the kind of testing that is typical for codecs st= andardized in 3GPP and 3GPP2. There are several details missing. For instance, Was only office noise tested? If so, why? How many listeners were used? What was the mix of talkers (e.g. no. of female, no. of male)? If you can point to more details of the testing, that would be very helpful= for members of the group. -Giri Mandyam From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= Koen Vos Sent: Friday, August 31, 2012 7:38 AM To: rtcweb@ietf.org Subject: Re: [rtcweb] Opus over the Internet? Lars Eggert wrote: > That's all great, but is there any qualitative comparison data of the dif= ferent codecs available? Please have a look at the test Dynastat did with SILK: http://developer.sky= pe.com/resources/SILKDataSheet.pdf Note that SILK in Opus is quite similar to the old SILK tested by Dynastat.= All changes were thoroughly tested to not degrade performance, and in mos= t cases improved it. So the SILK Dynastat results give a lower bound on th= e performance of a subset of the Opus modes. While these plots don't show G.722, it was in fact included in the test for= clean input signals without packet loss. According to the test results: - SILK at 8.85 kbps is outperformed by G.722 at 64 kbps with statistical si= gnificance - SILK at 12.65 kbps is a statistical tie with G.722 at 64 kbps - SILK at 18.85 kbps and above outperforms G.722 at 64 kbps with statistica= l significance. The packet loss in that test was maximally random (ie not bursty). While t= hat may not perfectly mimic real networks, I can think of no reason why the= results would be reversed or very different in practice. To give one more measure of suitability for the Internet: Skype has used SI= LK to deliver 100s of billions of Skype-to-Skype voice minutes over the Int= ernet, and our users are very satisfied with it. Hope this helps, koen. Lars Eggert wrote: That's all great, but is there any qualitative comparison data of the diffe= rent codecs available? -- Sent from a mobile device; please excuse typos. On Aug 30, 2012, at 21:07, "Jean-Marc Valin" wrote= : > On 12-08-30 09:14 AM, Markus.Isomaki at nokia.com wrote: >> Are there any tests that actually compare different codecs, say Opus >> vs. G.722 vs. AMR-WB, in typical Internet use, meaning some loss and >> jitter? I suppose the performance is only partially related to the >> codec, and partially to other implementation decisions, so it might >> be difficult to compare apples-with-apples. But since people are >> arguing that Opus is an "Internet codec", it would be actually nice >> to see some results in this sense. Or does "Internet codec" mean >> something else? > > The term "Internet codec" means different things to different people, > but to me this means more than "having good packet loss concealment". > Sure we have PLC (though it was never compared to G.722 or AMR-WB) and > we also have (optional) low bit-rate embedded redundancy (also called > FEC) and (also optional) independent frames, but that's just one aspect. > > One of the first things we've been asked when designing Opus was to make > the rate *really* adaptable because we never know what kind of rates > will be available. This not only meant having a wide range of bitrates, > but also being able to vary in small increments. This is why Opus scales > from about 6 kb/s to 512 kb/s, in increments of 0.4 kb/s (one byte with > 20 ms frames). Compare that to AMR-WB, which scales from 6.6 to 23.85 in > (on average) ~2.5 kb/s increments. The reason Opus can have more than > 1200 possible bitrates is because on the Internet, other layers in the > protocol stack provide octet granularity framing/sizing. We don't need > to spend 11 bits signalling the bitrate because UDP already encodes the > packet size. > > There's also practical aspects. If you look at the rates supported by > AMR-WB, you see that *none* of them represents an integer number of > bytes per frame. For example, 23.85 kb/s is 59 bytes plus 5 bits per > frame. It's definitely not the only cause, but the bottom line is that > the payload format for AMR-WB (rfc4867) is quite complex. Now compare > this with the Opus RTP payload > (http://tools.ietf.org/html/draft-spittka-payload-rtp-opus). Although > it's not complete, it's not only much simpler, but it also makes it > possible to decode RTP packets without having even seen the SDP or any > out-of-band signalling. > > People may have other definitions, but that's what *I* mean by Opus > being an "Internet codec". > > Cheers, > > Jean-Marc > >>> -----Original Message----- From: rtcweb-bounces at ietf.org >>> [mailto:rtcweb-bounces at ietf.org] On Behalf Of ext Stefan Hakansson >>> LK Sent: 30 August, 2012 14:58 To: Jean-Marc Valin Cc: >>> rtcweb at ietf.org Subject: Re: [rtcweb] Confirmation of consensus on >>> audio codecs >>> >>> On 08/29/2012 03:10 PM, Jean-Marc Valin wrote: >> On 08/29/2012 05:51 AM, Stefan Hakansson LK wrote: >>>> ... >> >>>>>> That is great, but sort of underlines that there would be no >>>>>> harm in delaying the decision until there are experiences >>>>>> made from real world use - 'cause it would not be that long >>>>>> till that experience has been made (Markus also brought up >>>>>> the IPR status as a reason for waiting - I have no idea how >>>>>> long it would take to know more about that). >> >> As Harald is pointing out, rtcweb implementations are going to ship >> pretty soon. >>>> >>>> If that is the case (and I think and hope so), why would we need >>>> to make it MTI before seeing it in action? >>>> >>>> [...] >>>> >> Are you expecting *another* single, standardized, royalty-free codec >> that operates over vast ranges of bitrates and operating conditions, >> from narrowband speech to stereo music, all with low delay, coming >> out in the next year? If not, what are you really waiting for? >>>> >>>> No, I'm not expecting that. I would just prefer us to see that >>>> Opus does indeed deliver as promised before making it MTI. If it >>>> does, fine. If not, we'd have to discuss what to do then. >>>> >>>> To me it is like if you're going to place a bet, for an upcoming >>>> big race, on a horse that has never been in an actual race, but >>>> shows great promise. If you know that the horse is going to >>>> participate in a few practice races soon, would you not prefer to >>>> wait and see how it fares in those before placing the bet (given >>>> that the odds would not change)? >>>> >>>> Anyway, that's my view. Let's see what the chairs say. >> >>>>>> As Paul suggested, I was referring to the lack of formal, >>>>>> controlled, characterization tests. That is how other SDOs do >>>>>> it. I don't think that is the only way to do it, but I think >>>>>> we should at least have either such tests conducted or >>>>>> experience from deployment and use (in a wide range of >>>>>> conditions and device types) before making it MTI. >> >> Opus has had "ITU-style" testing on English ( >> http://www.opus-codec.org/comparison/GoogleTest1.pdf ) and Mandarin >> ( http://www.opus-codec.org/comparison/GoogleTest2.pdf ). And if you >> don't trust Google on the tests I linked to, it's also been tested >> by Nokia: >> >>>> http://research.nokia.com/files/public/%5B16%5D_InterSpeech2011_Voice_ >> >>>> > Quality_Characterization_of_IETF_Opus_Codec.pdf >>>> Come on, those tests are very limited compared to a formal >>>> characterization test. (Example: >>>> www.itu.int/dms_pub/itu-t/opb/tut/T-TUT-ASC-2010-MSW-E.docx). >>>> There is very little info on the material used, the environment, >>>> processing and scripts and so on. And there seems to be no tests >>>> whatsoever (at least not involving humans) with actual channels >>>> introducing jitter and losses. >>>> >>>> Note: I am in no way proposing that a formal characterization >>>> test is needed, or even the right thing to do. It is a costly and >>>> time consuming process, and alternative approaches could prove to >>>> be more efficient. What I am saying is that I think we should not >>>> mandate a codec that has neither gone through that kind of formal >>>> characterization testing nor has any field experience from actual >>>> use on a reasonable scale (covering different conditions and >>>> device types). It just seems wrong, especially given that we >>>> will soon have field experience. >>>> >> >> Now, unlike other SDOs, the testing did not stop there. ITU-T codecs >> generally end up being testing with something in the order of tens >> of minutes worth of audio. In *addition* to that kind of testing, >> Opus also had automated testing with hundreds of years worth of >> audio. If anything, I think other SDOs should learn something here. >>>> >>>> This may very well be true. I guess this comes down to how much >>>> you trust that the quality assessment models (e.g. PEAQ, POLQA) >>>> give the same result as human test subjects would. But I think >>>> this sounds like a really good thing. >>>> >> >> Jean-Marc >> >>>> >>> >>> _______________________________________________ rtcweb mailing >>> list rtcweb at ietf.org https://www.ietf.org/mailman/listinfo/rtcweb > _______________________________________________ > rtcweb mailing list > rtcweb at ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --_000_D79146E3783B6942A3E8BC43352BBB460579F1EDTK5EX14MBXC254r_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hi Giri,

Dynastat's subjective tes= t involved the following design parameters:

- subjects: 32, four pane= ls of eight subjects, native speakers of North American English

- randomizations: one per listening panel
- talkers: eight (four males, four females), native speakers of North Ameri= can English
- speech samples: four 8 sec. sentence-pairs per talker
- experimental design: partially-balanced, randomized-blocks
Dynastat constructed the randomizations (i.e., pseudo-randomized presentati= on sequences) for each listening panel. Each randomization included 256 tri= als (i.e., 8 talkers x 32 test conditions).

We tested only office noise at 15 dB SNR because we didn't have more condit= ions available. 

As web browsers are commonly used in an office, knowledge of a codec's perf= ormance in that kind of environment would seem helpful to this working grou= p.  Do I understand correctly that the 3GPP and 3GPP2 tests did not in= clude any office noise conditions? 

best,
koen.

From: Mandyam, Giridhar [mandyam@quicinc.= com]
Sent: Friday, August 31, 2012 8:16 AM
To: Koen Vos; rtcweb@ietf.org
Subject: RE: [rtcweb] Opus over the Internet?

Thank you for pointing = out these results.

 

I think these results r= epresent a very good start, but the results as provided may not be sufficie= nt to characterize Opus.  I=92ve already cited the Dynastat study in 3GPP2 for EVRC-B characterization in a separate email.  In a= ddition to packet loss (in the 3GPP2 study, the analog would be frame error= rate), background noise conditions were varied (based on MNRU, street nois= e, car noise).  This is the kind of testing that is typical for codecs standardized in 3GPP and 3GPP2.

 

There are several detai= ls missing.  For instance,

 

Was only office noise t= ested? If so, why?   

How many listeners were= used? 

What was the mix of tal= kers (e.g. no. of female, no. of male)?

 

If you can point to mor= e details of the testing, that would be very helpful for members of the gro= up.

 

-Giri Mandyam

 

From: rtcweb= -bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Koen Vos
Sent: Friday, August 31, 2012 7:38 AM
To: rtcweb@ietf.org
Subject: Re: [rtcweb] Opus over the Internet?

 

Lars Eggert wrote:

> That's a= ll great, but is there any qualitative comparison data of the different cod= ecs available?

Please have a look at the test Dynastat did with SILK: http://developer.skype.com/resources/SILKDataSheet.pdf

Note that SILK in Opus is quite similar to the old SILK tested by Dynastat.=   All changes were thoroughly tested to not degrade performance, and i= n most cases improved it.  So the SILK Dynastat results give a lower b= ound on the performance of a subset of the Opus modes.

While these plots don't show G.722, it was in fact included in the test for= clean input signals without packet loss.  According to the test resul= ts:
- SILK at 8.85 kbps is outperformed by G.722 at 64 kbps with statistical si= gnificance
- SILK at 12.65 kbps is a statistical tie with G.722 at 64 kbps
- SILK at 18.85 kbps and above outperforms G.722 at 64 kbps with statistica= l significance.

The packet loss in that test was maximally random (ie not bursty).  Wh= ile that may not perfectly mimic real networks, I can think of no reason wh= y the results would be reversed or very different in practice.

To give one more measure of suitability for the Internet: Skype has used SI= LK to deliver 100s of billions of Skype-to-Skype voice minutes over the Int= ernet, and our users are very satisfied with it.

Hope this helps,
koen.

Lars Eggert wrote:
That's all great, bu=
t is there any qualitative comparison data of the different codecs availabl=
e?
 
-- 
Sent from a mobile device; please excuse t=
ypos.
 
On Aug 30, 2012, at 21:07, "Jean-Marc=
 Valin" <jmvalin at mozilla.com> wrote:
 
> On 12-08-30 09:14 AM, Markus.Isomaki =
at nokia.com wrote:
>> Are there any tests that actually=
 compare different codecs, say Opus
>> vs. G.722 vs. AMR-WB, in typical =
Internet use, meaning some loss and
>> jitter? I suppose the performance=
 is only partially related to the
>> codec, and partially to other imp=
lementation decisions, so it might
>> be difficult to compare apples-wi=
th-apples. But since people are
>> arguing that Opus is an "Int=
ernet codec", it would be actually nice
>> to see some results in this sense=
. Or does "Internet codec" mean
>> something else?
> 
> The term "Internet codec" m=
eans different things to different people,
> but to me this means more than "=
having good packet loss concealment".
> Sure we have PLC (though it was never=
 compared to G.722 or AMR-WB) and
> we also have (optional) low bit-rate =
embedded redundancy (also called
> FEC) and (also optional) independent =
frames, but that's just one aspect.
> 
> One of the first things we've been as=
ked when designing Opus was to make
> the rate *really* adaptable because w=
e never know what kind of rates
> will be available. This not only mean=
t having a wide range of bitrates,
> but also being able to vary in small =
increments. This is why Opus scales
> from about 6 kb/s to 512 kb/s, in inc=
rements of 0.4 kb/s (one byte with
> 20 ms frames). Compare that to AMR-WB=
, which scales from 6.6 to 23.85 in
> (on average) ~2.5 kb/s increments. Th=
e reason Opus can have more than
> 1200 possible bitrates is because on =
the Internet, other layers in the
> protocol stack provide octet granular=
ity framing/sizing. We don't need
> to spend 11 bits signalling the bitra=
te because UDP already encodes the
> packet size.
> 
> There's also practical aspects. If yo=
u look at the rates supported by
> AMR-WB, you see that *none* of them r=
epresents an integer number of
> bytes per frame. For example, 23.85 k=
b/s is 59 bytes plus 5 bits per
> frame. It's definitely not the only c=
ause, but the bottom line is that
> the payload format for AMR-WB (rfc486=
7) is quite complex. Now compare
> this with the Opus RTP payload=

> (http://tools.ietf.org/h=
tml/draft-spittka-payload-rtp-opus). Although
> it's not complete, it's not only much=
 simpler, but it also makes it
> possible to decode RTP packets withou=
t having even seen the SDP or any
> out-of-band signalling.
> 
> People may have other definitions, bu=
t that's what *I* mean by Opus
> being an "Internet codec".<=
/span>
> 
> Cheers,
> 
>    Jean-Marc

> 


>>> -----Original Message----- Fr=
om: rtcweb-bounces at ietf.org


>>> [mailto:rtcweb-bounces at ietf.org] On Behalf Of=
 ext Stefan Hakansson


>>> LK Sent: 30 August, 2012 14:5=
8 To: Jean-Marc Valin Cc:


>>> rtcweb at ietf.org Subject: R=
e: [rtcweb] Confirmation of consensus on


>>> audio codecs


>>> 


>>> On 08/29/2012 03:10 PM, Jean-=
Marc Valin wrote:


>> On 08/29/2012 05:51 AM, Stefan Ha=
kansson LK wrote:


>>>> ...


>> 


>>>>>> That is great, bu=
t sort of underlines that there would be no


>>>>>> harm in delaying =
the decision until there are experiences


>>>>>> made from real wo=
rld use - 'cause it would not be that long


>>>>>> till that experie=
nce has been made (Markus also brought up


>>>>>> the IPR status as=
 a reason for waiting - I have no idea how


>>>>>> long it would tak=
e to know more about that).


>> 


>> As Harald is pointing out, rtcweb=
 implementations are going to ship 


>> pretty soon.


>>>> 


>>>> If that is the case (and =
I think and hope so), why would we need


>>>> to make it MTI before see=
ing it in action?


>>>> 


>>>> [...]


>>>> 


>> Are you expecting *another* singl=
e, standardized, royalty-free codec 


>> that operates over vast ranges of=
 bitrates and operating conditions, 


>> from narrowband speech to stereo =
music, all with low delay, coming


>> out in the next year? If not, wha=
t are you really waiting for?


>>>> 


>>>> No, I'm not expecting tha=
t. I would just prefer us to see that


>>>> Opus does indeed deliver =
as promised before making it MTI. If it


>>>> does, fine. If not, we'd =
have to discuss what to do then.


>>>> 


>>>> To me it is like if you'r=
e going to place a bet, for an upcoming


>>>> big race, on a horse that=
 has never been in an actual race, but


>>>> shows great promise. If y=
ou know that the horse is going to


>>>> participate in a few prac=
tice races soon, would you not prefer to


>>>> wait and see how it fares=
 in those before placing the bet (given


>>>> that the odds would not c=
hange)?


>>>> 


>>>> Anyway, that's my view. L=
et's see what the chairs say.


>> 


>>>>>> As Paul suggested=
, I was referring to the lack of formal,


>>>>>> controlled, chara=
cterization tests. That is how other SDOs do


>>>>>> it. I don't think=
 that is the only way to do it, but I think


>>>>>> we should at leas=
t have either such tests conducted or


>>>>>> experience from d=
eployment and use (in a wide range of


>>>>>> conditions and de=
vice types) before making it MTI.


>> 


>> Opus has had "ITU-style"=
; testing on English ( 


>> http://www.opus-codec.org=
/comparison/GoogleTest1.pdf ) and Mandarin


>> ( http://www.opus-codec.o=
rg/comparison/GoogleTest2.pdf ). And if you 


>> don't trust Google on the tests I=
 linked to, it's also been tested


>> by Nokia:


>> 


>>>> http://research.nokia.com/files/public/%5B16%5D_InterSpeech2011_Voice_=



>> 


>>>> 


> Quality_Characterization_of_IETF_Opus=
_Codec.pdf


>>>> Come on, those tests are =
very limited compared to a formal


>>>> characterization test. (E=
xample: 


>>>> www=
.itu.int/dms_pub/itu-t/opb/tut/T-TUT-ASC-2010-MSW-E.docx).


>>>> There is very little info=
 on the material used, the environment,


>>>> processing and scripts an=
d so on. And there seems to be no tests


>>>> whatsoever (at least not =
involving humans) with actual channels


>>>> introducing jitter and lo=
sses.


>>>> 


>>>> Note: I am in no way prop=
osing that a formal characterization


>>>> test is needed, or even t=
he right thing to do. It is a costly and


>>>> time consuming process, a=
nd alternative approaches could prove to


>>>> be more efficient. What I=
 am saying is that I think we should not


>>>> mandate a codec that has =
neither gone through that kind of formal


>>>> characterization testing =
nor has any field experience from actual


>>>> use on a reasonable scale=
 (covering different conditions and


>>>> device types). It just se=
ems wrong, especially given that we


>>>> will soon have field expe=
rience.


>>>> 


>> 


>> Now, unlike other SDOs, the testi=
ng did not stop there. ITU-T codecs 


>> generally end up being testing wi=
th something in the order of tens


>> of minutes worth of audio. In *ad=
dition* to that kind of testing,


>> Opus also had automated testing w=
ith hundreds of years worth of


>> audio. If anything, I think other=
 SDOs should learn something here.


>>>> 


>>>> This may very well be tru=
e. I guess this comes down to how much


>>>> you trust that the qualit=
y assessment models (e.g. PEAQ, POLQA)


>>>> give the same result as h=
uman test subjects would. But I think


>>>> this sounds like a really=
 good thing.


>>>> 


>> 


>> Jean-Marc


>> 


>>>> 


>>> 


>>> _____________________________=
__________________ rtcweb mailing


>>> list rtcweb at ietf.org https=
://www.ietf.org/mailman/listinfo/rtcweb


> _____________________________________=
__________


> rtcweb mailing list


> rtcweb at ietf.org


> https://www.ietf.org/mailman/listinfo=
/rtcweb


 
--_000_D79146E3783B6942A3E8BC43352BBB460579F1EDTK5EX14MBXC254r_-- From jmvalin@mozilla.com Fri Aug 31 13:33:12 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2596021F8469 for ; Fri, 31 Aug 2012 13:33:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5a+JTk41WHRn for ; Fri, 31 Aug 2012 13:33:11 -0700 (PDT) Received: from smtp.mozilla.org (mx2.corp.phx1.mozilla.com [63.245.216.70]) by ietfa.amsl.com (Postfix) with ESMTP id 0B38321F8467 for ; Fri, 31 Aug 2012 13:33:11 -0700 (PDT) Received: from [192.168.1.15] (modemcable094.20-21-96.mc.videotron.ca [96.21.20.94]) (Authenticated sender: jvalin@mozilla.com) by mx2.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 20ED2F269F; Fri, 31 Aug 2012 13:33:10 -0700 (PDT) Message-ID: <50411F84.4010108@mozilla.com> Date: Fri, 31 Aug 2012 16:33:08 -0400 From: Jean-Marc Valin User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: Roman Shpount References: <503F46C5.2090607@alvestrand.no> <503F61CC.1010709@alvestrand.no> <503FC1BF.5020004@alvestrand.no> <5040541C.5020008@alvestrand.no> <20120831133845.GW72831@verdi> <5040CE32.5050003@jesup.org> <20120831151247.GY72831@verdi> <5040E7A5.50406@mozilla.com> In-Reply-To: X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Randell Jesup , rtcweb@ietf.org Subject: Re: [rtcweb] RTCWEB needs an Internet Codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 31 Aug 2012 20:33:12 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/31/2012 01:23 PM, Roman Shpount wrote: > One issue I want to bring into consideration is computation > complexity of Opus. It is normally acceptable for end user devices > in point-to-point calls (I do not want to start all the mobile > device CPU vs battery live discussion. It is irrelevant), but in > cases where you need to process all the calls on some sort of > central server (such as conferencing, or virtual reality, or > massive multi-player games) the additional processing cost of > supporting Opus can be significant. In such cases G.722 (ideally in > combination with PLC and CN to save bandwidth) can be a valid > compromise, since it can provide quality better then G.711 with CPU > processing requirements order of magnitude less then Opus. Actually, you're making a really good point about complexity on the server side. One important feature in Opus is scalable complexity. Sure you can use it in ways that eat a lot of CPU to fully optimize quality, but you can also get good enough quality at much lower complexity. I just ran a quick test on my two year-old laptop. Using the unoptimized C reference implementation with a single core, I can encode and decode at 40 kb/s (higher quality than G.722) 150 channels in real-time. Using architecture-specific optimizations and both cores, we should be able to handle about 500 channels on my poor laptop. And that's assuming that we're actually decoding and re-encoding all streams, which we'd never do. In a mixing case where we're decoding all channels, but only encoding one, we end up with 1000 channels. Oh, one feature I forgot to mention about Opus is that (unlike G722) it's *really* cheap to figure out which channels are active without having to decode everything. That alone should provide at least a 2x saving (more for larger conferences). So we're now at 2000 channels on my poor old laptop. I think a recent multi-core server should have about 10x that power. Conclusion, the audio codec complexity will just *not* be a problem. Jean-Marc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQEcBAEBAgAGBQJQQR+EAAoJEJ6/8sItn9q9I7kH/05UHgmakBitdPghhvE4TYQC /2t9VNNPkyBCNbHIsxskkDazZae7pgi0SVFe1me3xDdhIatrEtIK4wF8Y5ML6/sW 5HyxTTpoyeYJvbt4j8NZTf5MR6Nj6CEYWoWuZAdVdZRC4+Y0xjyFcu4DCP3xFg8D SN1AsWZkM4SkMI9Ioa1EFiQUH+FPhRK2GPtLsqba8DGQ4ZeBbe8C9I52ECQAOdgA 2u2Kd8mqH1f7lellXWL5VKh3BVazJOEDXa7JGEExpRTlpUbicyguu2hNrYTUj+yP itqyhRge02E7tYRQRuGnQg+s2N2GPvpFEr6k3a9XAdMAykX2xlIrZVgGaWEtru4= =J6Nz -----END PGP SIGNATURE----- From jmvalin@mozilla.com Fri Aug 31 13:50:37 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 012AB21F8530 for ; Fri, 31 Aug 2012 13:50:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.804 X-Spam-Level: X-Spam-Status: No, score=-0.804 tagged_above=-999 required=5 tests=[AWL=-0.873, BAYES_00=-2.599, FUZZY_XPILL=1.746, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id siqWknQVjr58 for ; Fri, 31 Aug 2012 13:50:35 -0700 (PDT) Received: from smtp.mozilla.org (mx1.corp.phx1.mozilla.com [63.245.216.69]) by ietfa.amsl.com (Postfix) with ESMTP id 5162021F8533 for ; Fri, 31 Aug 2012 13:50:35 -0700 (PDT) Received: from [192.168.1.15] (modemcable094.20-21-96.mc.videotron.ca [96.21.20.94]) (Authenticated sender: jvalin@mozilla.com) by mx1.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id B90BFF278B; Fri, 31 Aug 2012 13:50:32 -0700 (PDT) Message-ID: <50412397.8090306@mozilla.com> Date: Fri, 31 Aug 2012 16:50:31 -0400 From: Jean-Marc Valin User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: "Mandyam, Giridhar" References: In-Reply-To: X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Opus vs AMR-WB for packet loss X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 31 Aug 2012 20:50:37 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 OK, here's something concrete for comparing Opus to AMR-WB in packet loss conditions. I've simulated 30% bursty packet loss in the following conditions: 1) AMR-WB mode 8 (23.85 kb/s) 2) Opus at 24 kb/s (no FEC) 3) Opus at 24 kb/s with FEC (24 kb/s is the total including FEC) I've uploaded the results at: http://jmvalin.ca/plc/ I think everyone will agree that even without FEC, Opus sounds much better than AMR-WB. And when you turn FEC on, then you barely even notice the losses. Jean-Marc On 08/31/2012 11:16 AM, Mandyam, Giridhar wrote: > Thank you for pointing out these results. > > > > I think these results represent a very good start, but the results > as provided may not be sufficient to characterize Opus. I’ve > already cited the Dynastat study in 3GPP2 for EVRC-B > characterization in a separate email. In addition to packet loss > (in the 3GPP2 study, the analog would be frame error rate), > background noise conditions were varied (based on MNRU, street > noise, car noise). This is the kind of testing that is typical for > codecs standardized in 3GPP and 3GPP2. > > > > There are several details missing. For instance, > > > > Was only office noise tested? If so, why? > > How many listeners were used? > > What was the mix of talkers (e.g. no. of female, no. of male)? > > > > If you can point to more details of the testing, that would be > very helpful for members of the group. > > > > -Giri Mandyam > > > > *From:*rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] > *On Behalf Of *Koen Vos *Sent:* Friday, August 31, 2012 7:38 AM > *To:* rtcweb@ietf.org *Subject:* Re: [rtcweb] Opus over the > Internet? > > > > Lars Eggert wrote: > >> That's all great, but is there any qualitative comparison data of >> the different codecs available? > > Please have a look at the test Dynastat did with SILK: > http://developer.skype.com/resources/SILKDataSheet.pdf > > Note that SILK in Opus is quite similar to the old SILK tested by > Dynastat. All changes were thoroughly tested to not degrade > performance, and in most cases improved it. So the SILK Dynastat > results give a lower bound on the performance of a subset of the > Opus modes. > > While these plots don't show G.722, it was in fact included in the > test for clean input signals without packet loss. According to the > test results: - SILK at 8.85 kbps is outperformed by G.722 at 64 > kbps with statistical significance - SILK at 12.65 kbps is a > statistical tie with G.722 at 64 kbps - SILK at 18.85 kbps and > above outperforms G.722 at 64 kbps with statistical significance. > > The packet loss in that test was maximally random (ie not bursty). > While that may not perfectly mimic real networks, I can think of > no reason why the results would be reversed or very different in > practice. > > To give one more measure of suitability for the Internet: Skype has > used SILK to deliver 100s of billions of Skype-to-Skype voice > minutes over the Internet, and our users are very satisfied with > it. > > Hope this helps, koen. > > Lars Eggert wrote: That's all great, but is there any qualitative > comparison data of the different codecs available? > > > > -- > > Sent from a mobile device; please excuse typos. > > > > On Aug 30, 2012, at 21:07, "Jean-Marc Valin" mozilla.com> wrote: > > > >> On 12-08-30 09:14 AM, Markus.Isomaki at nokia.com wrote: > >>> Are there any tests that actually compare different codecs, say >>> Opus > >>> vs. G.722 vs. AMR-WB, in typical Internet use, meaning some >>> loss and > >>> jitter? I suppose the performance is only partially related to >>> the > >>> codec, and partially to other implementation decisions, so it >>> might > >>> be difficult to compare apples-with-apples. But since people >>> are > >>> arguing that Opus is an "Internet codec", it would be actually >>> nice > >>> to see some results in this sense. Or does "Internet codec" >>> mean > >>> something else? > >> > >> The term "Internet codec" means different things to different >> people, > >> but to me this means more than "having good packet loss >> concealment". > >> Sure we have PLC (though it was never compared to G.722 or >> AMR-WB) and > >> we also have (optional) low bit-rate embedded redundancy (also >> called > >> FEC) and (also optional) independent frames, but that's just one >> aspect. > >> > >> One of the first things we've been asked when designing Opus was >> to make > >> the rate *really* adaptable because we never know what kind of >> rates > >> will be available. This not only meant having a wide range of >> bitrates, > >> but also being able to vary in small increments. This is why Opus >> scales > >> from about 6 kb/s to 512 kb/s, in increments of 0.4 kb/s (one >> byte with > >> 20 ms frames). Compare that to AMR-WB, which scales from 6.6 to >> 23.85 in > >> (on average) ~2.5 kb/s increments. The reason Opus can have more >> than > >> 1200 possible bitrates is because on the Internet, other layers >> in the > >> protocol stack provide octet granularity framing/sizing. We don't >> need > >> to spend 11 bits signalling the bitrate because UDP already >> encodes the > >> packet size. > >> > >> There's also practical aspects. If you look at the rates >> supported by > >> AMR-WB, you see that *none* of them represents an integer number >> of > >> bytes per frame. For example, 23.85 kb/s is 59 bytes plus 5 bits >> per > >> frame. It's definitely not the only cause, but the bottom line is >> that > >> the payload format for AMR-WB (rfc4867) is quite complex. Now >> compare > >> this with the Opus RTP payload > >> (http://tools.ietf.org/html/draft-spittka-payload-rtp-opus). >> Although > >> it's not complete, it's not only much simpler, but it also makes >> it > >> possible to decode RTP packets without having even seen the SDP >> or any > >> out-of-band signalling. > >> > >> People may have other definitions, but that's what *I* mean by >> Opus > >> being an "Internet codec". > >> > >> Cheers, > >> > >> Jean-Marc > >> > >>>> -----Original Message----- From: rtcweb-bounces at ietf.org > >>>> [mailto:rtcweb-bounces at ietf.org] On Behalf Of ext Stefan >>>> Hakansson > >>>> LK Sent: 30 August, 2012 14:58 To: Jean-Marc Valin Cc: > >>>> rtcweb at ietf.org Subject: Re: [rtcweb] Confirmation of >>>> consensus on > >>>> audio codecs > >>>> > >>>> On 08/29/2012 03:10 PM, Jean-Marc Valin wrote: > >>> On 08/29/2012 05:51 AM, Stefan Hakansson LK wrote: > >>>>> ... > >>> > >>>>>>> That is great, but sort of underlines that there would >>>>>>> be no > >>>>>>> harm in delaying the decision until there are >>>>>>> experiences > >>>>>>> made from real world use - 'cause it would not be that >>>>>>> long > >>>>>>> till that experience has been made (Markus also brought >>>>>>> up > >>>>>>> the IPR status as a reason for waiting - I have no idea >>>>>>> how > >>>>>>> long it would take to know more about that). > >>> > >>> As Harald is pointing out, rtcweb implementations are going to >>> ship > >>> pretty soon. > >>>>> > >>>>> If that is the case (and I think and hope so), why would we >>>>> need > >>>>> to make it MTI before seeing it in action? > >>>>> > >>>>> [...] > >>>>> > >>> Are you expecting *another* single, standardized, royalty-free >>> codec > >>> that operates over vast ranges of bitrates and operating >>> conditions, > >>> from narrowband speech to stereo music, all with low delay, >>> coming > >>> out in the next year? If not, what are you really waiting for? > >>>>> > >>>>> No, I'm not expecting that. I would just prefer us to see >>>>> that > >>>>> Opus does indeed deliver as promised before making it MTI. >>>>> If it > >>>>> does, fine. If not, we'd have to discuss what to do then. > >>>>> > >>>>> To me it is like if you're going to place a bet, for an >>>>> upcoming > >>>>> big race, on a horse that has never been in an actual race, >>>>> but > >>>>> shows great promise. If you know that the horse is going >>>>> to > >>>>> participate in a few practice races soon, would you not >>>>> prefer to > >>>>> wait and see how it fares in those before placing the bet >>>>> (given > >>>>> that the odds would not change)? > >>>>> > >>>>> Anyway, that's my view. Let's see what the chairs say. > >>> > >>>>>>> As Paul suggested, I was referring to the lack of >>>>>>> formal, > >>>>>>> controlled, characterization tests. That is how other >>>>>>> SDOs do > >>>>>>> it. I don't think that is the only way to do it, but I >>>>>>> think > >>>>>>> we should at least have either such tests conducted or > >>>>>>> experience from deployment and use (in a wide range of > >>>>>>> conditions and device types) before making it MTI. > >>> > >>> Opus has had "ITU-style" testing on English ( > >>> http://www.opus-codec.org/comparison/GoogleTest1.pdf ) and >>> Mandarin > >>> ( http://www.opus-codec.org/comparison/GoogleTest2.pdf ). And >>> if you > >>> don't trust Google on the tests I linked to, it's also been >>> tested > >>> by Nokia: > >>> > >>>>> http://research.nokia.com/files/public/%5B16%5D_InterSpeech2011_Voice_ > >>>>> >>> > >>>>> > >> Quality_Characterization_of_IETF_Opus_Codec.pdf > >>>>> Come on, those tests are very limited compared to a formal > >>>>> characterization test. (Example: > >>>>> www.itu.int/dms_pub/itu-t/opb/tut/T-TUT-ASC-2010-MSW-E.docx >>>>> ). > >>>>> There is very little info on the material used, the >>>>> environment, > >>>>> processing and scripts and so on. And there seems to be no >>>>> tests > >>>>> whatsoever (at least not involving humans) with actual >>>>> channels > >>>>> introducing jitter and losses. > >>>>> > >>>>> Note: I am in no way proposing that a formal >>>>> characterization > >>>>> test is needed, or even the right thing to do. It is a >>>>> costly and > >>>>> time consuming process, and alternative approaches could >>>>> prove to > >>>>> be more efficient. What I am saying is that I think we >>>>> should not > >>>>> mandate a codec that has neither gone through that kind of >>>>> formal > >>>>> characterization testing nor has any field experience from >>>>> actual > >>>>> use on a reasonable scale (covering different conditions >>>>> and > >>>>> device types). It just seems wrong, especially given that >>>>> we > >>>>> will soon have field experience. > >>>>> > >>> > >>> Now, unlike other SDOs, the testing did not stop there. ITU-T >>> codecs > >>> generally end up being testing with something in the order of >>> tens > >>> of minutes worth of audio. In *addition* to that kind of >>> testing, > >>> Opus also had automated testing with hundreds of years worth >>> of > >>> audio. If anything, I think other SDOs should learn something >>> here. > >>>>> > >>>>> This may very well be true. I guess this comes down to how >>>>> much > >>>>> you trust that the quality assessment models (e.g. PEAQ, >>>>> POLQA) > >>>>> give the same result as human test subjects would. But I >>>>> think > >>>>> this sounds like a really good thing. > >>>>> > >>> > >>> Jean-Marc > >>> > >>>>> > >>>> > >>>> _______________________________________________ rtcweb >>>> mailing > >>>> list rtcweb at ietf.org >>>> https://www.ietf.org/mailman/listinfo/rtcweb > >> _______________________________________________ > >> rtcweb mailing list > >> rtcweb at ietf.org > >> https://www.ietf.org/mailman/listinfo/rtcweb > > > > > > _______________________________________________ rtcweb mailing > list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQEcBAEBAgAGBQJQQSOXAAoJEJ6/8sItn9q9hpEIAL0XKKrLJBb4AfUH7700lkYH JS60S/XFmwBOOZ55q+AUHEprvtIcsTD3XE1Yrqn0O5xWvpIA8Rhb93g5kT+zaUNl VcXZ4OsB9Yt8ahqy0yVdtXHxo//nIffiqNnQlyAschiIXONGxBCkwvyU21XnrPL0 oEtcnx3Y9sG5eFJMuJJt3k9NBpvL1TzmHQOVuYNMNvCgCNHYQIhS9RHplJmAJnp4 XIaz63JrKpmw+jgsQeqJNfyf8G3+JrvWYouA5aoHMkFhzg3dKatjaN2bctp/fNNE 4jzjPlegTS4eSR3cqyqkv1lW+StIxEcwWEhKYqc2vK3S4lUpbWKFAC2t83L/wSQ= =4iDk -----END PGP SIGNATURE----- From mandyam@quicinc.com Fri Aug 31 13:59:51 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC0F721F8523 for ; Fri, 31 Aug 2012 13:59:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.1 X-Spam-Level: X-Spam-Status: No, score=-6.1 tagged_above=-999 required=5 tests=[AWL=0.498, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RRhidzjg9kh0 for ; Fri, 31 Aug 2012 13:59:43 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id 82ADA21F8505 for ; Fri, 31 Aug 2012 13:59:43 -0700 (PDT) X-IronPort-AV: E=McAfee;i="5400,1158,6821"; a="229543068" Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by wolverine02.qualcomm.com with ESMTP; 31 Aug 2012 13:59:43 -0700 X-IronPort-AV: E=Sophos;i="4.80,349,1344236400"; d="scan'208,217";a="292905884" Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 31 Aug 2012 13:59:42 -0700 Received: from NASANEXD01H.na.qualcomm.com ([169.254.8.250]) by nasanexhc04.na.qualcomm.com ([172.30.48.17]) with mapi id 14.02.0318.001; Fri, 31 Aug 2012 13:59:42 -0700 From: "Mandyam, Giridhar" To: Koen Vos , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Opus over the Internet? Thread-Index: Ac2HfMsrJ/6oA0BvSY28PJ4c6WjX7AACCdSkAAC8HqAAGo0kgAAOkVBA Date: Fri, 31 Aug 2012 20:59:42 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.45.230.6] Content-Type: multipart/alternative; boundary="_000_CAC8DBE4E9704C41BCB290C2F3CC921A162D308Enasanexd01hnaqu_" MIME-Version: 1.0 Subject: Re: [rtcweb] Opus over the Internet? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 31 Aug 2012 20:59:51 -0000 --_000_CAC8DBE4E9704C41BCB290C2F3CC921A162D308Enasanexd01hnaqu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks for getting back to me. It looks like the assembled speaker panels = and the mix of talkers followed a similar methodology to PP and PP2. 3GPP TR 26.935 (Packet Switched (PS) conversational multimedia applications= ; Performance characterisation of default codecs) lists in Table 12 three t= ypes of background noise conditions for AMR-WB: car, street and cafeteria.= Cafeteria is the closest to office IMO - it includes background babble i= n an open environment. -Giri From: Koen Vos [mailto:koen.vos@skype.net] Sent: Friday, August 31, 2012 1:30 PM To: Mandyam, Giridhar; rtcweb@ietf.org Subject: RE: [rtcweb] Opus over the Internet? Hi Giri, Dynastat's subjective test involved the following design parameters: - subjects: 32, four panels of eight subjects, native speakers of North Ame= rican English - randomizations: one per listening panel - talkers: eight (four males, four females), native speakers of North Ameri= can English - speech samples: four 8 sec. sentence-pairs per talker - experimental design: partially-balanced, randomized-blocks Dynastat constructed the randomizations (i.e., pseudo-randomized presentati= on sequences) for each listening panel. Each randomization included 256 tri= als (i.e., 8 talkers x 32 test conditions). We tested only office noise at 15 dB SNR because we didn't have more condit= ions available. As web browsers are commonly used in an office, knowledge of a codec's perf= ormance in that kind of environment would seem helpful to this working grou= p. Do I understand correctly that the 3GPP and 3GPP2 tests did not include= any office noise conditions? best, koen. ________________________________ From: Mandyam, Giridhar [mandyam@quicinc.com] Sent: Friday, August 31, 2012 8:16 AM To: Koen Vos; rtcweb@ietf.org Subject: RE: [rtcweb] Opus over the Internet? Thank you for pointing out these results. I think these results represent a very good start, but the results as provi= ded may not be sufficient to characterize Opus. I've already cited the Dyn= astat study in 3GPP2 for EVRC-B characterization in a separate email. In a= ddition to packet loss (in the 3GPP2 study, the analog would be frame error= rate), background noise conditions were varied (based on MNRU, street nois= e, car noise). This is the kind of testing that is typical for codecs stan= dardized in 3GPP and 3GPP2. There are several details missing. For instance, Was only office noise tested? If so, why? How many listeners were used? What was the mix of talkers (e.g. no. of female, no. of male)? If you can point to more details of the testing, that would be very helpful= for members of the group. -Giri Mandyam From: rtcweb-bounces@ietf.org [mailto:rtcwe= b-bounces@ietf.org] On Behalf Of K= oen Vos Sent: Friday, August 31, 2012 7:38 AM To: rtcweb@ietf.org Subject: Re: [rtcweb] Opus over the Internet? Lars Eggert wrote: > That's all great, but is there any qualitative comparison data of the dif= ferent codecs available? Please have a look at the test Dynastat did with SILK: http://developer.sky= pe.com/resources/SILKDataSheet.pdf Note that SILK in Opus is quite similar to the old SILK tested by Dynastat.= All changes were thoroughly tested to not degrade performance, and in mos= t cases improved it. So the SILK Dynastat results give a lower bound on th= e performance of a subset of the Opus modes. While these plots don't show G.722, it was in fact included in the test for= clean input signals without packet loss. According to the test results: - SILK at 8.85 kbps is outperformed by G.722 at 64 kbps with statistical si= gnificance - SILK at 12.65 kbps is a statistical tie with G.722 at 64 kbps - SILK at 18.85 kbps and above outperforms G.722 at 64 kbps with statistica= l significance. The packet loss in that test was maximally random (ie not bursty). While t= hat may not perfectly mimic real networks, I can think of no reason why the= results would be reversed or very different in practice. To give one more measure of suitability for the Internet: Skype has used SI= LK to deliver 100s of billions of Skype-to-Skype voice minutes over the Int= ernet, and our users are very satisfied with it. Hope this helps, koen. Lars Eggert wrote: That's all great, but is there any qualitative comparison data of the diffe= rent codecs available? -- Sent from a mobile device; please excuse typos. On Aug 30, 2012, at 21:07, "Jean-Marc Valin" wrote= : > On 12-08-30 09:14 AM, Markus.Isomaki at nokia.com wrote: >> Are there any tests that actually compare different codecs, say Opus >> vs. G.722 vs. AMR-WB, in typical Internet use, meaning some loss and >> jitter? I suppose the performance is only partially related to the >> codec, and partially to other implementation decisions, so it might >> be difficult to compare apples-with-apples. But since people are >> arguing that Opus is an "Internet codec", it would be actually nice >> to see some results in this sense. Or does "Internet codec" mean >> something else? > > The term "Internet codec" means different things to different people, > but to me this means more than "having good packet loss concealment". > Sure we have PLC (though it was never compared to G.722 or AMR-WB) and > we also have (optional) low bit-rate embedded redundancy (also called > FEC) and (also optional) independent frames, but that's just one aspect. > > One of the first things we've been asked when designing Opus was to make > the rate *really* adaptable because we never know what kind of rates > will be available. This not only meant having a wide range of bitrates, > but also being able to vary in small increments. This is why Opus scales > from about 6 kb/s to 512 kb/s, in increments of 0.4 kb/s (one byte with > 20 ms frames). Compare that to AMR-WB, which scales from 6.6 to 23.85 in > (on average) ~2.5 kb/s increments. The reason Opus can have more than > 1200 possible bitrates is because on the Internet, other layers in the > protocol stack provide octet granularity framing/sizing. We don't need > to spend 11 bits signalling the bitrate because UDP already encodes the > packet size. > > There's also practical aspects. If you look at the rates supported by > AMR-WB, you see that *none* of them represents an integer number of > bytes per frame. For example, 23.85 kb/s is 59 bytes plus 5 bits per > frame. It's definitely not the only cause, but the bottom line is that > the payload format for AMR-WB (rfc4867) is quite complex. Now compare > this with the Opus RTP payload > (http://tools.ietf.org/html/draft-spittka-payload-rtp-opus). Although > it's not complete, it's not only much simpler, but it also makes it > possible to decode RTP packets without having even seen the SDP or any > out-of-band signalling. > > People may have other definitions, but that's what *I* mean by Opus > being an "Internet codec". > > Cheers, > > Jean-Marc > >>> -----Original Message----- From: rtcweb-bounces at ietf.org >>> [mailto:rtcweb-bounces at ietf.org] On Behalf Of ext Stefan Hakansson >>> LK Sent: 30 August, 2012 14:58 To: Jean-Marc Valin Cc: >>> rtcweb at ietf.org Subject: Re: [rtcweb] Confirmation of consensus on >>> audio codecs >>> >>> On 08/29/2012 03:10 PM, Jean-Marc Valin wrote: >> On 08/29/2012 05:51 AM, Stefan Hakansson LK wrote: >>>> ... >> >>>>>> That is great, but sort of underlines that there would be no >>>>>> harm in delaying the decision until there are experiences >>>>>> made from real world use - 'cause it would not be that long >>>>>> till that experience has been made (Markus also brought up >>>>>> the IPR status as a reason for waiting - I have no idea how >>>>>> long it would take to know more about that). >> >> As Harald is pointing out, rtcweb implementations are going to ship >> pretty soon. >>>> >>>> If that is the case (and I think and hope so), why would we need >>>> to make it MTI before seeing it in action? >>>> >>>> [...] >>>> >> Are you expecting *another* single, standardized, royalty-free codec >> that operates over vast ranges of bitrates and operating conditions, >> from narrowband speech to stereo music, all with low delay, coming >> out in the next year? If not, what are you really waiting for? >>>> >>>> No, I'm not expecting that. I would just prefer us to see that >>>> Opus does indeed deliver as promised before making it MTI. If it >>>> does, fine. If not, we'd have to discuss what to do then. >>>> >>>> To me it is like if you're going to place a bet, for an upcoming >>>> big race, on a horse that has never been in an actual race, but >>>> shows great promise. If you know that the horse is going to >>>> participate in a few practice races soon, would you not prefer to >>>> wait and see how it fares in those before placing the bet (given >>>> that the odds would not change)? >>>> >>>> Anyway, that's my view. Let's see what the chairs say. >> >>>>>> As Paul suggested, I was referring to the lack of formal, >>>>>> controlled, characterization tests. That is how other SDOs do >>>>>> it. I don't think that is the only way to do it, but I think >>>>>> we should at least have either such tests conducted or >>>>>> experience from deployment and use (in a wide range of >>>>>> conditions and device types) before making it MTI. >> >> Opus has had "ITU-style" testing on English ( >> http://www.opus-codec.org/comparison/GoogleTest1.pdf ) and Mandarin >> ( http://www.opus-codec.org/comparison/GoogleTest2.pdf ). And if you >> don't trust Google on the tests I linked to, it's also been tested >> by Nokia: >> >>>> http://research.nokia.com/files/public/%5B16%5D_InterSpeech2011_Voice_ >> >>>> > Quality_Characterization_of_IETF_Opus_Codec.pdf >>>> Come on, those tests are very limited compared to a formal >>>> characterization test. (Example: >>>> www.itu.int/dms_pub/itu-t/opb/tut/T-TUT-ASC-2010-MSW-E.docx). >>>> There is very little info on the material used, the environment, >>>> processing and scripts and so on. And there seems to be no tests >>>> whatsoever (at least not involving humans) with actual channels >>>> introducing jitter and losses. >>>> >>>> Note: I am in no way proposing that a formal characterization >>>> test is needed, or even the right thing to do. It is a costly and >>>> time consuming process, and alternative approaches could prove to >>>> be more efficient. What I am saying is that I think we should not >>>> mandate a codec that has neither gone through that kind of formal >>>> characterization testing nor has any field experience from actual >>>> use on a reasonable scale (covering different conditions and >>>> device types). It just seems wrong, especially given that we >>>> will soon have field experience. >>>> >> >> Now, unlike other SDOs, the testing did not stop there. ITU-T codecs >> generally end up being testing with something in the order of tens >> of minutes worth of audio. In *addition* to that kind of testing, >> Opus also had automated testing with hundreds of years worth of >> audio. If anything, I think other SDOs should learn something here. >>>> >>>> This may very well be true. I guess this comes down to how much >>>> you trust that the quality assessment models (e.g. PEAQ, POLQA) >>>> give the same result as human test subjects would. But I think >>>> this sounds like a really good thing. >>>> >> >> Jean-Marc >> >>>> >>> >>> _______________________________________________ rtcweb mailing >>> list rtcweb at ietf.org https://www.ietf.org/mailman/listinfo/rtcweb > _______________________________________________ > rtcweb mailing list > rtcweb at ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --_000_CAC8DBE4E9704C41BCB290C2F3CC921A162D308Enasanexd01hnaqu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks for getting back t= o me.  It looks like the assembled speaker panels and the mix of talke= rs followed a similar methodology to PP and PP2. 

 <= /p>

3GPP TR 26.935 (Packet Sw= itched (PS) conversational multimedia applications; Performance characteris= ation of default codecs) lists in Table 12 three types of background noise conditions for AMR-WB:  car, street and cafeteria.&n= bsp; Cafeteria is the closest to office IMO -  it includes background = babble in an open environment. 

 <= /p>

-Giri

 <= /p>

 <= /p>

From: Koen Vos= [mailto:koen.vos@skype.net]
Sent: Friday, August 31, 2012 1:30 PM
To: Mandyam, Giridhar; rtcweb@ietf.org
Subject: RE: [rtcweb] Opus over the Internet?

 

Hi Giri,

Dynastat's subjective test involved the foll= owing design parameters:

- subjects: 32, four panels of eight subject= s, native speakers of North American English

- randomizations: one per listening panel
- talkers: eight (four males, four females), native speakers of North Ameri= can English
- speech samples: four 8 sec. sentence-pairs per talker
- experimental design: partially-balanced, randomized-blocks
Dynastat constructed the randomizations (i.e., pseudo-randomized presentati= on sequences) for each listening panel. Each randomization included 256 tri= als (i.e., 8 talkers x 32 test conditions).

We tested only office noise at 15 dB SNR because we didn't have more condit= ions available. 

As web browsers are commonly used in an office, knowledge of a codec's perf= ormance in that kind of environment would seem helpful to this working grou= p.  Do I understand correctly that the 3GPP and 3GPP2 tests did not in= clude any office noise conditions? 

best,
koen.

From: Mandyam, Giridhar [mandyam@q= uicinc.com]
Sent: Friday, August 31, 2012 8:16 AM
To: Koen Vos; rtcweb@ietf.org=
Subject: RE: [rtcweb] Opus over the Internet?

Thank you for pointing ou= t these results.

 

I think these results rep= resent a very good start, but the results as provided may not be sufficient= to characterize Opus.  I’ve already cited the Dynastat study in 3GPP2 for EVRC-B characterization in a separate email.  In a= ddition to packet loss (in the 3GPP2 study, the analog would be frame error= rate), background noise conditions were varied (based on MNRU, street nois= e, car noise).  This is the kind of testing that is typical for codecs standardized in 3GPP and 3GPP2.

 

There are several details= missing.  For instance,=

 

Was only office noise tes= ted? If so, why?   =

How many listeners were u= sed? 

What was the mix of talke= rs (e.g. no. of female, no. of male)?

 

If you can point to more = details of the testing, that would be very helpful for members of the group= .

 

-Giri Mandyam

 

From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Koen Vos
Sent: Friday, August 31, 2012 7:38 AM
To: rtcweb@ietf.org
Subject: Re: [rtcweb] Opus over the Internet?

 =

Lars Eggert wrote:

> That's all= great, but is there any qualitative comparison data of the different codec= s available?

Please have a look at the test Dynastat did with SILK: http://developer.skype.com/resources/SILKDataSheet.pdf

Note that SILK in Opus is quite similar to the old SILK tested by Dynastat.=   All changes were thoroughly tested to not degrade performance, and i= n most cases improved it.  So the SILK Dynastat results give a lower b= ound on the performance of a subset of the Opus modes.

While these plots don't show G.722, it was in fact included in the test for= clean input signals without packet loss.  According to the test resul= ts:
- SILK at 8.85 kbps is outperformed by G.722 at 64 kbps with statistical si= gnificance
- SILK at 12.65 kbps is a statistical tie with G.722 at 64 kbps
- SILK at 18.85 kbps and above outperforms G.722 at 64 kbps with statistica= l significance.

The packet loss in that test was maximally random (ie not bursty).  Wh= ile that may not perfectly mimic real networks, I can think of no reason wh= y the results would be reversed or very different in practice.

To give one more measure of suitability for the Internet: Skype has used SI= LK to deliver 100s of billions of Skype-to-Skype voice minutes over the Int= ernet, and our users are very satisfied with it.

Hope this helps,
koen.

Lars Eggert wrote:
That's all great, bu=
t is there any qualitative comparison data of the different codecs availabl=
e?
 
-- 
Sent from a mobile device; please excuse t=
ypos.
 
On Aug 30, 2012, at 21:07, "Jean-Marc=
 Valin" <jmvalin at mozilla.com> wrote:
 
> On 12-08-30 09:14 AM, Markus.Isomaki =
at nokia.com wrote:
>> Are there any tests that actually=
 compare different codecs, say Opus
>> vs. G.722 vs. AMR-WB, in typical =
Internet use, meaning some loss and
>> jitter? I suppose the performance=
 is only partially related to the
>> codec, and partially to other imp=
lementation decisions, so it might
>> be difficult to compare apples-wi=
th-apples. But since people are
>> arguing that Opus is an "Int=
ernet codec", it would be actually nice
>> to see some results in this sense=
. Or does "Internet codec" mean
>> something else?=

> 
> The term "Internet codec" m=
eans different things to different people,
> but to me this means more than "=
having good packet loss concealment".
> Sure we have PLC (though it was never=
 compared to G.722 or AMR-WB) and
> we also have (optional) low bit-rate =
embedded redundancy (also called
> FEC) and (also optional) independent =
frames, but that's just one aspect.
> 
> One of the first things we've been as=
ked when designing Opus was to make
> the rate *really* adaptable because w=
e never know what kind of rates
> will be available. This not only mean=
t having a wide range of bitrates,
> but also being able to vary in small =
increments. This is why Opus scales
> from about 6 kb/s to 512 kb/s, in inc=
rements of 0.4 kb/s (one byte with
> 20 ms frames). Compare that to AMR-WB=
, which scales from 6.6 to 23.85 in
> (on average) ~2.5 kb/s increments. Th=
e reason Opus can have more than
> 1200 possible bitrates is because on =
the Internet, other layers in the
> protocol stack provide octet granular=
ity framing/sizing. We don't need
> to spend 11 bits signalling the bitra=
te because UDP already encodes the
> packet size.
> 
> There's also practical aspects. If yo=
u look at the rates supported by
> AMR-WB, you see that *none* of them r=
epresents an integer number of
> bytes per frame. For example, 23.85 k=
b/s is 59 bytes plus 5 bits per
> frame. It's definitely not the only c=
ause, but the bottom line is that
> the payload format for AMR-WB (rfc486=
7) is quite complex. Now compare
> this with the Opus RTP payload
> (http://tools.ietf.org/h=
tml/draft-spittka-payload-rtp-opus). Although
> it's not complete, it's not only much=
 simpler, but it also makes it
> possible to decode RTP packets withou=
t having even seen the SDP or any
> out-of-band signalling.
> 
> People may have other definitions, bu=
t that's what *I* mean by Opus
> being an "Internet codec".<=
o:p>
> 
> Cheers,
> 
>    Jean-Marc
> 
>>> -----Original Message----- Fr=
om: rtcweb-bounces at ietf.org
>>> [mailto:rtcweb-bounces at ietf.org] On Behalf Of=
 ext Stefan Hakansson
>>> LK Sent: 30 August, 2012 14:5=
8 To: Jean-Marc Valin Cc:
>>> rtcweb at ietf.org Subject: R=
e: [rtcweb] Confirmation of consensus on
>>> audio codecs
>>> 
>>> On 08/29/2012 03:10 PM, Jean-=
Marc Valin wrote:
>> On 08/29/2012 05:51 AM, Stefan Ha=
kansson LK wrote:
>>>> ...

>> 


>>>>>> That is great, bu=
t sort of underlines that there would be no


>>>>>> harm in delaying =
the decision until there are experiences


>>>>>> made from real wo=
rld use - 'cause it would not be that long


>>>>>> till that experie=
nce has been made (Markus also brought up


>>>>>> the IPR status as=
 a reason for waiting - I have no idea how


>>>>>> long it would tak=
e to know more about that).


>> 


>> As Harald is pointing out, rtcweb=
 implementations are going to ship 


>> pretty soon.

>>>> 


>>>> If that is the case (and =
I think and hope so), why would we need


>>>> to make it MTI before see=
ing it in action?


>>>> 


>>>> [...]

>>>> 


>> Are you expecting *another* singl=
e, standardized, royalty-free codec 


>> that operates over vast ranges of=
 bitrates and operating conditions, 


>> from narrowband speech to stereo =
music, all with low delay, coming


>> out in the next year? If not, wha=
t are you really waiting for?


>>>> 


>>>> No, I'm not expecting tha=
t. I would just prefer us to see that


>>>> Opus does indeed deliver =
as promised before making it MTI. If it


>>>> does, fine. If not, we'd =
have to discuss what to do then.


>>>> 


>>>> To me it is like if you'r=
e going to place a bet, for an upcoming


>>>> big race, on a horse that=
 has never been in an actual race, but


>>>> shows great promise. If y=
ou know that the horse is going to


>>>> participate in a few prac=
tice races soon, would you not prefer to


>>>> wait and see how it fares=
 in those before placing the bet (given


>>>> that the odds would not c=
hange)?


>>>> 


>>>> Anyway, that's my view. L=
et's see what the chairs say.


>> 


>>>>>> As Paul suggested=
, I was referring to the lack of formal,


>>>>>> controlled, chara=
cterization tests. That is how other SDOs do


>>>>>> it. I don't think=
 that is the only way to do it, but I think


>>>>>> we should at leas=
t have either such tests conducted or


>>>>>> experience from d=
eployment and use (in a wide range of


>>>>>> conditions and de=
vice types) before making it MTI.


>> 


>> Opus has had "ITU-style"=
; testing on English ( 


>> http://www.opus-codec.org=
/comparison/GoogleTest1.pdf ) and Mandarin


>> ( http://www.opus-codec.o=
rg/comparison/GoogleTest2.pdf ). And if you 


>> don't trust Google on the tests I=
 linked to, it's also been tested


>> by Nokia:


>> 


>>>> http://research.nokia.com/files/public/%5B16%5D_InterSpeech2011_Voice_=



>> 


>>>> 


> Quality_Characterization_of_IETF_Opus=
_Codec.pdf


>>>> Come on, those tests are =
very limited compared to a formal


>>>> characterization test. (E=
xample: 


>>>> www=
.itu.int/dms_pub/itu-t/opb/tut/T-TUT-ASC-2010-MSW-E.docx).


>>>> There is very little info=
 on the material used, the environment,


>>>> processing and scripts an=
d so on. And there seems to be no tests


>>>> whatsoever (at least not =
involving humans) with actual channels


>>>> introducing jitter and lo=
sses.


>>>> 


>>>> Note: I am in no way prop=
osing that a formal characterization


>>>> test is needed, or even t=
he right thing to do. It is a costly and


>>>> time consuming process, a=
nd alternative approaches could prove to


>>>> be more efficient. What I=
 am saying is that I think we should not


>>>> mandate a codec that has =
neither gone through that kind of formal


>>>> characterization testing =
nor has any field experience from actual


>>>> use on a reasonable scale=
 (covering different conditions and


>>>> device types). It just se=
ems wrong, especially given that we


>>>> will soon have field expe=
rience.


>>>> 


>> 


>> Now, unlike other SDOs, the testi=
ng did not stop there. ITU-T codecs 


>> generally end up being testing wi=
th something in the order of tens


>> of minutes worth of audio. In *ad=
dition* to that kind of testing,


>> Opus also had automated testing w=
ith hundreds of years worth of


>> audio. If anything, I think other=
 SDOs should learn something here.


>>>> 


>>>> This may very well be tru=
e. I guess this comes down to how much


>>>> you trust that the qualit=
y assessment models (e.g. PEAQ, POLQA)


>>>> give the same result as h=
uman test subjects would. But I think


>>>> this sounds like a really=
 good thing.


>>>> 


>> 


>> Jean-Marc


>> 


>>>> 


>>> 


>>> _____________________________=
__________________ rtcweb mailing


>>> list rtcweb at ietf.org https=
://www.ietf.org/mailman/listinfo/rtcweb


> _____________________________________=
__________


> rtcweb mailing list=



> rtcweb at ietf.org<=
/pre>

> https://www.ietf.org/mailman/listinfo=
/rtcweb


 
--_000_CAC8DBE4E9704C41BCB290C2F3CC921A162D308Enasanexd01hnaqu_-- From jmvalin@mozilla.com Fri Aug 31 14:00:53 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 927B321F8523 for ; Fri, 31 Aug 2012 14:00:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.615 X-Spam-Level: X-Spam-Status: No, score=-1.615 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4wxDbKb5cFdj for ; Fri, 31 Aug 2012 14:00:52 -0700 (PDT) Received: from smtp.mozilla.org (mx1.corp.phx1.mozilla.com [63.245.216.69]) by ietfa.amsl.com (Postfix) with ESMTP id D91BE21F851E for ; Fri, 31 Aug 2012 14:00:52 -0700 (PDT) Received: from [192.168.1.15] (modemcable094.20-21-96.mc.videotron.ca [96.21.20.94]) (Authenticated sender: jvalin@mozilla.com) by mx1.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id B9E7EF278B; Fri, 31 Aug 2012 14:00:51 -0700 (PDT) Message-ID: <50412602.7040609@mozilla.com> Date: Fri, 31 Aug 2012 17:00:50 -0400 From: Jean-Marc Valin User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: "Mandyam, Giridhar" References: <503F46C5.2090607@alvestrand.no> <503F61CC.1010709@alvestrand.no> <503FC188.5050003@mozilla.com> <504016A9.5000805@mozilla.com> In-Reply-To: X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] RTCWEB needs an Internet Codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 31 Aug 2012 21:00:53 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/31/2012 01:25 PM, Mandyam, Giridhar wrote: > I'm not sure I understand your logic either. You could make the > same argument in favor of having AMR-NB or EVRC-B as MTI. Why not > do so and cover 100% of the use cases? Problem is that adding AMR-NB or EVRC-B would only prevent failure below 64 kb/s, but still leave us with embarrassingly bad quality. On the other hand, Opus will work (i.e. not fail) for all use cases, and actually be optimal or near-optimal for the vast majority of these use cases. Want slightly lower quality below 10 kb/s, go ahead and implement AMR/EVRC, but at least you're guarantee the call will not fail if it's not implemented. Jean-Marc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQEcBAEBAgAGBQJQQSYCAAoJEJ6/8sItn9q9MAEH/RAaU+MxFGOfoXdYvvkDwPTX 6mq2Xg31UMRnsv0x4EA+w0nAYNUfuvKVbWDapZXng1i4rs1A7mW8/7uH7wiCeXnH KA5dONXEXtAZcT0uNcsod42NvygIPQtvA0trN/YqGKNXXqnKsaI55BdEFD3t4JuD SKu+gaOe/k+HDkOCSbgeYlRWs14myVyIRJNy4LdbwZnMQLVry8Qo0Wnn69v85fdI MENndNt9x17UuyfH2tmlggs6REcPHRl79Kh6Uuvil/HmskO2NRNxmkemTabYT0tm l1k6ifPEhnAWsuOAlA62I8Q83xcvNmZE5dBBwuEqQ6hzm9zDK29CQVW04vD+rYE= =pYlC -----END PGP SIGNATURE----- From randell-ietf@jesup.org Fri Aug 31 14:18:42 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B513C21F8489 for ; Fri, 31 Aug 2012 14:18:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=-0.559, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u-xVzNFNBAM5 for ; Fri, 31 Aug 2012 14:18:41 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id B68D121F847F for ; Fri, 31 Aug 2012 14:18:41 -0700 (PDT) Received: from pool-173-49-141-60.phlapa.fios.verizon.net ([173.49.141.60] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1T7Ybx-0004FV-2H for rtcweb@ietf.org; Fri, 31 Aug 2012 16:18:41 -0500 Message-ID: <50412A0D.3020305@jesup.org> Date: Fri, 31 Aug 2012 17:18:05 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <50412397.8090306@mozilla.com> In-Reply-To: <50412397.8090306@mozilla.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [rtcweb] Opus vs AMR-WB for packet loss X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 31 Aug 2012 21:18:43 -0000 On 8/31/2012 4:50 PM, Jean-Marc Valin wrote: > OK, here's something concrete for comparing Opus to AMR-WB in packet > loss conditions. I've simulated 30% bursty packet loss in the > following conditions: > 1) AMR-WB mode 8 (23.85 kb/s) > 2) Opus at 24 kb/s (no FEC) > 3) Opus at 24 kb/s with FEC (24 kb/s is the total including FEC) > > I've uploaded the results at: http://jmvalin.ca/plc/ > > I think everyone will agree that even without FEC, Opus sounds much > better than AMR-WB. And when you turn FEC on, then you barely even > notice the losses. That's really, really good. :-) Especially with FEC. -- Randell Jesup randell-ietf@jesup.org From randy@qualcomm.com Fri Aug 31 15:19:02 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9618111E80E6 for ; Fri, 31 Aug 2012 15:19:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.571 X-Spam-Level: X-Spam-Status: No, score=-106.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fKjHsnTJbUjq for ; Fri, 31 Aug 2012 15:19:01 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by ietfa.amsl.com (Postfix) with ESMTP id AC4A211E808D for ; Fri, 31 Aug 2012 15:19:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=@qualcomm.com; q=dns/txt; s=qcdkim; t=1346451541; x=1377987541; h=message-id:in-reply-to:references:x-mailer:date:to:from: subject:cc:mime-version:content-type:x-random-sig-tag: x-originating-ip; bh=ZqATFr9IAWgAWzxxO3IrBa0sZ+86CbFwkCZq+RNLF+Q=; b=MxwZT4vqF/wBJoPHj/PajNQYEbwm/BgA2i9mGNi0azNu7tstpZffenpO uy/qed7kEnMyfFp8fWOAw0ltOBvqWqmTuALzgolInuJdSEMTwxBbAbrGB pIcAbtYo29Ju0ZBuoZBj8vIoSoLvHSCNxu5ySHJpLBaCnS772y2gSB+oz 8=; X-IronPort-AV: E=McAfee;i="5400,1158,6821"; a="231875661" Received: from ironmsg02-r.qualcomm.com ([172.30.46.16]) by wolverine01.qualcomm.com with ESMTP; 31 Aug 2012 15:19:01 -0700 X-IronPort-AV: E=Sophos;i="4.80,349,1344236400"; d="scan'208";a="160998118" Received: from nasanexhc08.na.qualcomm.com ([172.30.39.7]) by ironmsg02-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 31 Aug 2012 15:19:00 -0700 Received: from [99.111.97.136] (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.7) with Microsoft SMTP Server (TLS) id 14.2.318.1; Fri, 31 Aug 2012 15:19:00 -0700 Message-ID: In-Reply-To: <20120831151247.GY72831@verdi> References: <503F46C5.2090607@alvestrand.no> <503F61CC.1010709@alvestrand.no> <503FC1BF.5020004@alvestrand.no> <5040541C.5020008@alvestrand.no> <20120831133845.GW72831@verdi> <5040CE32.5050003@jesup.org> <20120831151247.GY72831@verdi> X-Mailer: Eudora for Mac OS X Date: Fri, 31 Aug 2012 15:09:10 -0700 To: John Leslie , Randell Jesup From: Randall Gellens MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Random-Sig-Tag: 1.0b28 X-Originating-IP: [172.30.39.5] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] RTCWEB needs an Internet Codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 31 Aug 2012 22:19:02 -0000 At 11:12 AM -0400 8/31/12, John Leslie wrote: > Our issue here is Mandatory-to-Implement. It is very important to > have at least one MTI audio codec. I could live with that being G.711, > because I trust the market to _actually_ implement others. Exactly. The discussion has been going in my view off-track into debates about which codec is best for which environments. The real issue is mandatory versus recommended. We can pick G.711 as MTI and rely on implementers to support others. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- One never sits in hotel lobby chairs, my dear. One never knows whom has been sitting in them before one. --unknown From hacker.stefan@gmail.com Fri Aug 31 15:36:23 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEEF921F846C for ; Fri, 31 Aug 2012 15:36:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.853 X-Spam-Level: X-Spam-Status: No, score=-1.853 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FUZZY_XPILL=1.746, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wUmmWmQjsYYt for ; Fri, 31 Aug 2012 15:36:22 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id C91D421F8448 for ; Fri, 31 Aug 2012 15:36:21 -0700 (PDT) Received: by bkty12 with SMTP id y12so1513436bkt.31 for ; Fri, 31 Aug 2012 15:36:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=8hX3icSyd+a+KImPozzdXMO0ext1rmwAvNRhcMA8w7E=; b=j2rpt8f7Rj6QBi6CKTHPsAIRJAjgq5bcYKYsV+N51ib2hUsmxsF0+9svKcQR0zKoSE /E8e4ugE3PCq+u2rg+S0uyQprF+AsPBEb5kXkryC98WaEHpPGqVaF70ghqSR3zGrMsfY jy0D1zrjPOvJ4O11sul3/Og6LkslcRJpot7CTOMo7TmLd8Jg+CrFUoETBzAmeOgCKH1D BDCTIC3Peg5oZxZcLcOTL5qu2ePmADLaEMhdfNU+kJPgoSVjbq1E+mml9J6ktvBFdw04 I2N8Xnw2DWlv2551zroTeSNOLbQdvTsrIUGwnPa39LMwptE9tHSkaBS1fMVOiG9Cb0Sj q76w== Received: by 10.204.5.144 with SMTP id 16mr4679059bkv.128.1346452580445; Fri, 31 Aug 2012 15:36:20 -0700 (PDT) Received: from [192.168.178.21] (dslb-092-075-111-053.pools.arcor-ip.net. [92.75.111.53]) by mx.google.com with ESMTPS id 14sm4301371bkw.15.2012.08.31.15.36.16 (version=SSLv3 cipher=OTHER); Fri, 31 Aug 2012 15:36:19 -0700 (PDT) Message-ID: <50413C5B.4060809@gmail.com> Date: Sat, 01 Sep 2012 00:36:11 +0200 From: Stefan Hacker User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <50412397.8090306@mozilla.com> In-Reply-To: <50412397.8090306@mozilla.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [rtcweb] Opus vs AMR-WB for packet loss X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 31 Aug 2012 22:36:23 -0000 We have made similar experiences when testing PLC behavior for Mumble. Opus handles package loss very gracefully even without FEC (which is what we are using). There are audible artifacts for sure, however they don't stand out like with many other codecs. Regards, Stefan On 31/08/2012 22:50, Jean-Marc Valin wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > OK, here's something concrete for comparing Opus to AMR-WB in packet > loss conditions. I've simulated 30% bursty packet loss in the > following conditions: > 1) AMR-WB mode 8 (23.85 kb/s) > 2) Opus at 24 kb/s (no FEC) > 3) Opus at 24 kb/s with FEC (24 kb/s is the total including FEC) > > I've uploaded the results at: http://jmvalin.ca/plc/ > > I think everyone will agree that even without FEC, Opus sounds much > better than AMR-WB. And when you turn FEC on, then you barely even > notice the losses. > > Jean-Marc > > On 08/31/2012 11:16 AM, Mandyam, Giridhar wrote: >> Thank you for pointing out these results. >> >> >> >> I think these results represent a very good start, but the results >> as provided may not be sufficient to characterize Opus. I’ve >> already cited the Dynastat study in 3GPP2 for EVRC-B >> characterization in a separate email. In addition to packet loss >> (in the 3GPP2 study, the analog would be frame error rate), >> background noise conditions were varied (based on MNRU, street >> noise, car noise). This is the kind of testing that is typical for >> codecs standardized in 3GPP and 3GPP2. >> >> >> >> There are several details missing. For instance, >> >> >> >> Was only office noise tested? If so, why? >> >> How many listeners were used? >> >> What was the mix of talkers (e.g. no. of female, no. of male)? >> >> >> >> If you can point to more details of the testing, that would be >> very helpful for members of the group. >> >> >> >> -Giri Mandyam >> >> >> >> *From:*rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] >> *On Behalf Of *Koen Vos *Sent:* Friday, August 31, 2012 7:38 AM >> *To:* rtcweb@ietf.org *Subject:* Re: [rtcweb] Opus over the >> Internet? >> >> >> >> Lars Eggert wrote: >> >>> That's all great, but is there any qualitative comparison data of >>> the different codecs available? >> Please have a look at the test Dynastat did with SILK: >> http://developer.skype.com/resources/SILKDataSheet.pdf >> >> Note that SILK in Opus is quite similar to the old SILK tested by >> Dynastat. All changes were thoroughly tested to not degrade >> performance, and in most cases improved it. So the SILK Dynastat >> results give a lower bound on the performance of a subset of the >> Opus modes. >> >> While these plots don't show G.722, it was in fact included in the >> test for clean input signals without packet loss. According to the >> test results: - SILK at 8.85 kbps is outperformed by G.722 at 64 >> kbps with statistical significance - SILK at 12.65 kbps is a >> statistical tie with G.722 at 64 kbps - SILK at 18.85 kbps and >> above outperforms G.722 at 64 kbps with statistical significance. >> >> The packet loss in that test was maximally random (ie not bursty). >> While that may not perfectly mimic real networks, I can think of >> no reason why the results would be reversed or very different in >> practice. >> >> To give one more measure of suitability for the Internet: Skype has >> used SILK to deliver 100s of billions of Skype-to-Skype voice >> minutes over the Internet, and our users are very satisfied with >> it. >> >> Hope this helps, koen. >> >> Lars Eggert wrote: That's all great, but is there any qualitative >> comparison data of the different codecs available? >> >> >> >> -- >> >> Sent from a mobile device; please excuse typos. >> >> >> >> On Aug 30, 2012, at 21:07, "Jean-Marc Valin"> mozilla.com> wrote: >> >> >> >>> On 12-08-30 09:14 AM, Markus.Isomaki at nokia.com wrote: >>>> Are there any tests that actually compare different codecs, say >>>> Opus >>>> vs. G.722 vs. AMR-WB, in typical Internet use, meaning some >>>> loss and >>>> jitter? I suppose the performance is only partially related to >>>> the >>>> codec, and partially to other implementation decisions, so it >>>> might >>>> be difficult to compare apples-with-apples. But since people >>>> are >>>> arguing that Opus is an "Internet codec", it would be actually >>>> nice >>>> to see some results in this sense. Or does "Internet codec" >>>> mean >>>> something else? >>> The term "Internet codec" means different things to different >>> people, >>> but to me this means more than "having good packet loss >>> concealment". >>> Sure we have PLC (though it was never compared to G.722 or >>> AMR-WB) and >>> we also have (optional) low bit-rate embedded redundancy (also >>> called >>> FEC) and (also optional) independent frames, but that's just one >>> aspect. >>> One of the first things we've been asked when designing Opus was >>> to make >>> the rate *really* adaptable because we never know what kind of >>> rates >>> will be available. This not only meant having a wide range of >>> bitrates, >>> but also being able to vary in small increments. This is why Opus >>> scales >>> from about 6 kb/s to 512 kb/s, in increments of 0.4 kb/s (one >>> byte with >>> 20 ms frames). Compare that to AMR-WB, which scales from 6.6 to >>> 23.85 in >>> (on average) ~2.5 kb/s increments. The reason Opus can have more >>> than >>> 1200 possible bitrates is because on the Internet, other layers >>> in the >>> protocol stack provide octet granularity framing/sizing. We don't >>> need >>> to spend 11 bits signalling the bitrate because UDP already >>> encodes the >>> packet size. >>> There's also practical aspects. If you look at the rates >>> supported by >>> AMR-WB, you see that *none* of them represents an integer number >>> of >>> bytes per frame. For example, 23.85 kb/s is 59 bytes plus 5 bits >>> per >>> frame. It's definitely not the only cause, but the bottom line is >>> that >>> the payload format for AMR-WB (rfc4867) is quite complex. Now >>> compare >>> this with the Opus RTP payload >>> (http://tools.ietf.org/html/draft-spittka-payload-rtp-opus). >>> Although >>> it's not complete, it's not only much simpler, but it also makes >>> it >>> possible to decode RTP packets without having even seen the SDP >>> or any >>> out-of-band signalling. >>> People may have other definitions, but that's what *I* mean by >>> Opus >>> being an "Internet codec". >>> Cheers, >>> Jean-Marc >>>>> -----Original Message----- From: rtcweb-bounces at ietf.org >>>>> [mailto:rtcweb-bounces at ietf.org] On Behalf Of ext Stefan >>>>> Hakansson >>>>> LK Sent: 30 August, 2012 14:58 To: Jean-Marc Valin Cc: >>>>> rtcweb at ietf.org Subject: Re: [rtcweb] Confirmation of >>>>> consensus on >>>>> audio codecs >>>>> On 08/29/2012 03:10 PM, Jean-Marc Valin wrote: >>>> On 08/29/2012 05:51 AM, Stefan Hakansson LK wrote: >>>>>> ... >>>>>>>> That is great, but sort of underlines that there would >>>>>>>> be no >>>>>>>> harm in delaying the decision until there are >>>>>>>> experiences >>>>>>>> made from real world use - 'cause it would not be that >>>>>>>> long >>>>>>>> till that experience has been made (Markus also brought >>>>>>>> up >>>>>>>> the IPR status as a reason for waiting - I have no idea >>>>>>>> how >>>>>>>> long it would take to know more about that). >>>> As Harald is pointing out, rtcweb implementations are going to >>>> ship >>>> pretty soon. >>>>>> If that is the case (and I think and hope so), why would we >>>>>> need >>>>>> to make it MTI before seeing it in action? >>>>>> [...] >>>> Are you expecting *another* single, standardized, royalty-free >>>> codec >>>> that operates over vast ranges of bitrates and operating >>>> conditions, >>>> from narrowband speech to stereo music, all with low delay, >>>> coming >>>> out in the next year? If not, what are you really waiting for? >>>>>> No, I'm not expecting that. I would just prefer us to see >>>>>> that >>>>>> Opus does indeed deliver as promised before making it MTI. >>>>>> If it >>>>>> does, fine. If not, we'd have to discuss what to do then. >>>>>> To me it is like if you're going to place a bet, for an >>>>>> upcoming >>>>>> big race, on a horse that has never been in an actual race, >>>>>> but >>>>>> shows great promise. If you know that the horse is going >>>>>> to >>>>>> participate in a few practice races soon, would you not >>>>>> prefer to >>>>>> wait and see how it fares in those before placing the bet >>>>>> (given >>>>>> that the odds would not change)? >>>>>> Anyway, that's my view. Let's see what the chairs say. >>>>>>>> As Paul suggested, I was referring to the lack of >>>>>>>> formal, >>>>>>>> controlled, characterization tests. That is how other >>>>>>>> SDOs do >>>>>>>> it. I don't think that is the only way to do it, but I >>>>>>>> think >>>>>>>> we should at least have either such tests conducted or >>>>>>>> experience from deployment and use (in a wide range of >>>>>>>> conditions and device types) before making it MTI. >>>> Opus has had "ITU-style" testing on English ( >>>> http://www.opus-codec.org/comparison/GoogleTest1.pdf ) and >>>> Mandarin >>>> ( http://www.opus-codec.org/comparison/GoogleTest2.pdf ). And >>>> if you >>>> don't trust Google on the tests I linked to, it's also been >>>> tested >>>> by Nokia: >>>>>> http://research.nokia.com/files/public/%5B16%5D_InterSpeech2011_Voice_ >>> Quality_Characterization_of_IETF_Opus_Codec.pdf >>>>>> Come on, those tests are very limited compared to a formal >>>>>> characterization test. (Example: >>>>>> www.itu.int/dms_pub/itu-t/opb/tut/T-TUT-ASC-2010-MSW-E.docx >>>>>> ). >>>>>> There is very little info on the material used, the >>>>>> environment, >>>>>> processing and scripts and so on. And there seems to be no >>>>>> tests >>>>>> whatsoever (at least not involving humans) with actual >>>>>> channels >>>>>> introducing jitter and losses. >>>>>> Note: I am in no way proposing that a formal >>>>>> characterization >>>>>> test is needed, or even the right thing to do. It is a >>>>>> costly and >>>>>> time consuming process, and alternative approaches could >>>>>> prove to >>>>>> be more efficient. What I am saying is that I think we >>>>>> should not >>>>>> mandate a codec that has neither gone through that kind of >>>>>> formal >>>>>> characterization testing nor has any field experience from >>>>>> actual >>>>>> use on a reasonable scale (covering different conditions >>>>>> and >>>>>> device types). It just seems wrong, especially given that >>>>>> we >>>>>> will soon have field experience. >>>> Now, unlike other SDOs, the testing did not stop there. ITU-T >>>> codecs >>>> generally end up being testing with something in the order of >>>> tens >>>> of minutes worth of audio. In *addition* to that kind of >>>> testing, >>>> Opus also had automated testing with hundreds of years worth >>>> of >>>> audio. If anything, I think other SDOs should learn something >>>> here. >>>>>> This may very well be true. I guess this comes down to how >>>>>> much >>>>>> you trust that the quality assessment models (e.g. PEAQ, >>>>>> POLQA) >>>>>> give the same result as human test subjects would. But I >>>>>> think >>>>>> this sounds like a really good thing. >>>> Jean-Marc >>>>> _______________________________________________ rtcweb >>>>> mailing >>>>> list rtcweb at ietf.org >>>>> https://www.ietf.org/mailman/listinfo/rtcweb >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb at ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >> >> >> >> >> _______________________________________________ rtcweb mailing >> list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb >> > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.12 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ > > iQEcBAEBAgAGBQJQQSOXAAoJEJ6/8sItn9q9hpEIAL0XKKrLJBb4AfUH7700lkYH > JS60S/XFmwBOOZ55q+AUHEprvtIcsTD3XE1Yrqn0O5xWvpIA8Rhb93g5kT+zaUNl > VcXZ4OsB9Yt8ahqy0yVdtXHxo//nIffiqNnQlyAschiIXONGxBCkwvyU21XnrPL0 > oEtcnx3Y9sG5eFJMuJJt3k9NBpvL1TzmHQOVuYNMNvCgCNHYQIhS9RHplJmAJnp4 > XIaz63JrKpmw+jgsQeqJNfyf8G3+JrvWYouA5aoHMkFhzg3dKatjaN2bctp/fNNE > 4jzjPlegTS4eSR3cqyqkv1lW+StIxEcwWEhKYqc2vK3S4lUpbWKFAC2t83L/wSQ= > =4iDk > -----END PGP SIGNATURE----- > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From gmaxwell@juniper.net Fri Aug 31 15:37:12 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B48B21F846F for ; Fri, 31 Aug 2012 15:37:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L5TMMLXRPGd8 for ; Fri, 31 Aug 2012 15:37:11 -0700 (PDT) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by ietfa.amsl.com (Postfix) with ESMTP id F22E921F846B for ; Fri, 31 Aug 2012 15:37:10 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKUEE8lELWRYvgL2dDNBBrlWqcrj/Nj0v+@postini.com; Fri, 31 Aug 2012 15:37:11 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Fri, 31 Aug 2012 15:36:10 -0700 From: Gregory Maxwell To: Randall Gellens , John Leslie , Randell Jesup Date: Fri, 31 Aug 2012 15:35:02 -0700 Thread-Topic: [rtcweb] RTCWEB needs an Internet Codec Thread-Index: Ac2HxqJFXnIEwzpIRoyYCJDAgxxCWQAAjo6D Message-ID: References: <503F46C5.2090607@alvestrand.no> <503F61CC.1010709@alvestrand.no> <503FC1BF.5020004@alvestrand.no> <5040541C.5020008@alvestrand.no> <20120831133845.GW72831@verdi> <5040CE32.5050003@jesup.org> <20120831151247.GY72831@verdi>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] RTCWEB needs an Internet Codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 31 Aug 2012 22:37:12 -0000 Randall Gellens [randy@qualcomm.com] wrote: > We can pick G.711 as MTI and rely on implementers to support others. And then end up with a specification which is not actually interoperable fo= r but a fraction of the well known intended applications. From hacker.stefan@gmail.com Fri Aug 31 16:15:40 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AA4021F8471 for ; Fri, 31 Aug 2012 16:15:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.726 X-Spam-Level: X-Spam-Status: No, score=-2.726 tagged_above=-999 required=5 tests=[AWL=0.873, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V2P6skq30dCi for ; Fri, 31 Aug 2012 16:15:39 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 44D1E21F846F for ; Fri, 31 Aug 2012 16:15:39 -0700 (PDT) Received: by bkty12 with SMTP id y12so1520217bkt.31 for ; Fri, 31 Aug 2012 16:15:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=GYClhUN3doJXGCwpZQ5j1m1Q70c7K1s0D1l5Y24Eh3I=; b=sb+O1ZdIv7b9SPMODvX2Pbo2RoCZgKZNxbJZO/URwgmPTtJoSS8AwqrcGEP09d7pOa 57Dfk3UM66y4ASPAt/21DXkod5/oSV0CfSuaOOlIOUFlo6Z5tGOHJXXF/PcsNiwICB5i VvCbC2ACkwn0x1z9F2ZRihhQJPyzg4UwPc/7B6gyytLb5VH4F4MTYFHkex9K64GVp5zd nvcWO9xUhb/ir2Wau8PS8fht6NCVAsT1UG4Mk10bYaF+KeqEbND8/QBFefPaetq0rOiQ cqivfiAFDRPe3NegyhsMMrzioojIgZhiFI4M5LmZ627Fih6X/vsaIMlHfm/d2jgF8zk2 bliQ== Received: by 10.204.129.14 with SMTP id m14mr4771791bks.7.1346454938255; Fri, 31 Aug 2012 16:15:38 -0700 (PDT) Received: from [192.168.178.21] (dslb-092-075-111-053.pools.arcor-ip.net. [92.75.111.53]) by mx.google.com with ESMTPS id 14sm4324866bkq.12.2012.08.31.16.15.36 (version=SSLv3 cipher=OTHER); Fri, 31 Aug 2012 16:15:37 -0700 (PDT) Message-ID: <50414593.2040607@gmail.com> Date: Sat, 01 Sep 2012 01:15:31 +0200 From: Stefan Hacker User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <503F46C5.2090607@alvestrand.no> <503F61CC.1010709@alvestrand.no> <503FC1BF.5020004@alvestrand.no> <5040541C.5020008@alvestrand.no> <20120831133845.GW72831@verdi> <5040CE32.5050003@jesup.org> <20120831151247.GY72831@verdi> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] RTCWEB needs an Internet Codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 31 Aug 2012 23:15:40 -0000 On 01/09/2012 00:09, Randall Gellens wrote: > Exactly. The discussion has been going in my view off-track into > debates about which codec is best for which environments. The real > issue is mandatory versus recommended. > > We can pick G.711 as MTI and rely on implementers to support others. > Imho this would be a big mistake. Even if implementers were to pick up Opus as quasi MTI after the fact, which I'm not convinced would reliably happen, this would critically damage the abilities of RTCWEB at launch. Remember that the first implementations are not likely to venture far into "recommended" territory and for many Opus is still an unknown no matter its credentials and advantages. Opus as an MTI offers the chance to make RTCWEB worth, even desirable, using Out-Of-The-Box for the majority of the intended use-cases. It ensures implementers have a codec at their hands that not only guarantees interoperability but also lets them pick the best possible quality, be it for low/high bandwidth or CPU or latency. Regards, Stefan From ron@debian.org Fri Aug 31 20:32:06 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0548621F84B9 for ; Fri, 31 Aug 2012 20:32:06 -0700 (PDT) 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_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gv7fhH2gqlDP for ; Fri, 31 Aug 2012 20:32:05 -0700 (PDT) Received: from ipmail05.adl6.internode.on.net (ipmail05.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:5]) by ietfa.amsl.com (Postfix) with ESMTP id 3049821F84B8 for ; Fri, 31 Aug 2012 20:32:04 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAKWAQVB5LWvi/2dsb2JhbABEuyCBCIIgAQEFOg0PMwsYLhQYDYhDq3COdYsJg2WCPGADiE2FKIdiAZAagnM Received: from ppp121-45-107-226.lns20.adl6.internode.on.net (HELO audi.shelbyville.oz) ([121.45.107.226]) by ipmail05.adl6.internode.on.net with ESMTP; 01 Sep 2012 13:02:02 +0930 Received: from localhost (localhost [127.0.0.1]) by audi.shelbyville.oz (Postfix) with ESMTP id 8AF154F8F3 for ; Sat, 1 Sep 2012 12:49:56 +0930 (CST) X-Virus-Scanned: Debian amavisd-new at audi.shelbyville.oz Received: from audi.shelbyville.oz ([127.0.0.1]) by localhost (audi.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id J3ScTxp2jvae for ; Sat, 1 Sep 2012 12:49:55 +0930 (CST) Received: by audi.shelbyville.oz (Postfix, from userid 1000) id BDB814F902; Sat, 1 Sep 2012 12:49:55 +0930 (CST) Date: Sat, 1 Sep 2012 12:49:55 +0930 From: Ron To: rtcweb@ietf.org Message-ID: <20120901031955.GF23434@audi.shelbyville.oz> References: <503F61CC.1010709@alvestrand.no> <503FC1BF.5020004@alvestrand.no> <5040541C.5020008@alvestrand.no> <20120831133845.GW72831@verdi> <5040CE32.5050003@jesup.org> <20120831151247.GY72831@verdi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: [rtcweb] RTCWEB needs an Internet Codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 01 Sep 2012 03:32:06 -0000 On Fri, Aug 31, 2012 at 08:40:43AM -0700, Cameron Byrne wrote: > Agree with the above. G.711 for mti only. > > I want to push Opus and promote its use, but MTI is not the right method > for that. I haven't got the impression from this discussion that anybody thinks it is about "pushing Opus" at all. The question is what is best for rtcweb. Since the charter of this group is to produce a standard that facilitates "direct interactive rich communication", using things that already exist as much as possible - I thought it was clear that the only important point is that all this engineering work to produce rtcweb should not be a complete waste of time for the people actually implementing it, and produce something that gives such a poor experience in its baseline configuration that nobody would ever actually want to use it for any of its intended purposes. That Opus is a very obvious choice of existing technology, which no other single codec comes anywhere close to matching for this purpose, stands out like an elephant in the room. Blind men might argue about whether it is a pillar or a brush, or whether enough double blinded men have yet touched it to be sure of this, but no amount of "pushing" is going to realistically move it from that position one way or the other. Pretending that other much-poorer codecs could fill this role is abandoning the "rich communication" part of the charter, and condemning this group to an embarrassing failure to achieve its goals in any meaningful way. Let's not do that shall we. It seems quite clear that many people have an intense interest in its success. Delaying this indefinitely, or selecting poorer options than are already available today do not seem like the choices that rational people who actually do want this to succeed would make. Interoperability requires an adequate MTI codec. Nobody has proposed an alternative codec that is not clearly inadequate by comparison to Opus. In a room full of clever engineers who want rtcweb to excel as a best of breed specification, this decision should be a total no-brainer. This time would be much better spent on the Actually Hard questions that still remain for rtcweb. Best, Ron From basilgohar@librevideo.org Fri Aug 31 20:42:26 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82D8921F84C2 for ; Fri, 31 Aug 2012 20:42:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6NTwCFl6mOuv for ; Fri, 31 Aug 2012 20:42:25 -0700 (PDT) Received: from mail.zaytoon.hidayahonline.net (zaytoon.hidayahonline.net [173.193.202.83]) by ietfa.amsl.com (Postfix) with ESMTP id B2FAA21F84BF for ; Fri, 31 Aug 2012 20:42:25 -0700 (PDT) Received: from [192.168.2.100] (cpe-75-180-52-231.columbus.res.rr.com [75.180.52.231]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: basilgohar@librevideo.org) by mail.zaytoon.hidayahonline.net (Postfix) with ESMTPSA id 955BF6596FD for ; Fri, 31 Aug 2012 23:42:17 -0400 (EDT) Message-ID: <50418416.8030008@librevideo.org> Date: Fri, 31 Aug 2012 23:42:14 -0400 From: Basil Mohamed Gohar User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120828 Thunderbird/15.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <503F61CC.1010709@alvestrand.no> <503FC1BF.5020004@alvestrand.no> <5040541C.5020008@alvestrand.no> <20120831133845.GW72831@verdi> <5040CE32.5050003@jesup.org> <20120831151247.GY72831@verdi> <20120901031955.GF23434@audi.shelbyville.oz> In-Reply-To: <20120901031955.GF23434@audi.shelbyville.oz> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] RTCWEB needs an Internet Codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 01 Sep 2012 03:42:26 -0000 On 08/31/2012 11:19 PM, Ron wrote: > On Fri, Aug 31, 2012 at 08:40:43AM -0700, Cameron Byrne wrote: >> Agree with the above. G.711 for mti only. >> >> I want to push Opus and promote its use, but MTI is not the right method >> for that. > I haven't got the impression from this discussion that anybody thinks it > is about "pushing Opus" at all. The question is what is best for rtcweb. > > Since the charter of this group is to produce a standard that facilitates > "direct interactive rich communication", using things that already exist > as much as possible - I thought it was clear that the only important point > is that all this engineering work to produce rtcweb should not be a complete > waste of time for the people actually implementing it, and produce something > that gives such a poor experience in its baseline configuration that nobody > would ever actually want to use it for any of its intended purposes. > > That Opus is a very obvious choice of existing technology, which no other > single codec comes anywhere close to matching for this purpose, stands out > like an elephant in the room. Blind men might argue about whether it is a > pillar or a brush, or whether enough double blinded men have yet touched it > to be sure of this, but no amount of "pushing" is going to realistically > move it from that position one way or the other. > > Pretending that other much-poorer codecs could fill this role is abandoning > the "rich communication" part of the charter, and condemning this group to > an embarrassing failure to achieve its goals in any meaningful way. > > Let's not do that shall we. It seems quite clear that many people have an > intense interest in its success. Delaying this indefinitely, or selecting > poorer options than are already available today do not seem like the choices > that rational people who actually do want this to succeed would make. > > Interoperability requires an adequate MTI codec. Nobody has proposed an > alternative codec that is not clearly inadequate by comparison to Opus. > In a room full of clever engineers who want rtcweb to excel as a best of > breed specification, this decision should be a total no-brainer. > > This time would be much better spent on the Actually Hard questions that > still remain for rtcweb. > > Best, > Ron +1, I couldn't have expressed myself any better than this, personally. -- Libre Video http://librevideo.org From ron@debian.org Fri Aug 31 20:43:12 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3D0511E80A4 for ; Fri, 31 Aug 2012 20:43:12 -0700 (PDT) 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_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oEt3Qt2yHa1j for ; Fri, 31 Aug 2012 20:43:12 -0700 (PDT) Received: from ipmail05.adl6.internode.on.net (ipmail05.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:5]) by ietfa.amsl.com (Postfix) with ESMTP id D276711E80A3 for ; Fri, 31 Aug 2012 20:43:11 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EACyDQVB5LWvi/2dsb2JhbABFuyCBCIIgAQEFOhwzCxguFBgNN4gMum2LCYNlgxwDiE2FKIdiAZAagnM Received: from ppp121-45-107-226.lns20.adl6.internode.on.net (HELO audi.shelbyville.oz) ([121.45.107.226]) by ipmail05.adl6.internode.on.net with ESMTP; 01 Sep 2012 13:13:11 +0930 Received: from localhost (localhost [127.0.0.1]) by audi.shelbyville.oz (Postfix) with ESMTP id 7B2214F8F3 for ; Sat, 1 Sep 2012 13:13:10 +0930 (CST) X-Virus-Scanned: Debian amavisd-new at audi.shelbyville.oz Received: from audi.shelbyville.oz ([127.0.0.1]) by localhost (audi.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id YEyZjLBuDSjl for ; Sat, 1 Sep 2012 13:13:09 +0930 (CST) Received: by audi.shelbyville.oz (Postfix, from userid 1000) id 4894B4F902; Sat, 1 Sep 2012 13:13:09 +0930 (CST) Date: Sat, 1 Sep 2012 13:13:09 +0930 From: Ron To: rtcweb@ietf.org Message-ID: <20120901034309.GG23434@audi.shelbyville.oz> References: <9E2843EA-EBB9-40B3-898C-6B5216FAE7A5@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: [rtcweb] Confirmation of consensus on audio codecs X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 01 Sep 2012 03:43:12 -0000 On Thu, Aug 30, 2012 at 01:46:21PM +0100, Neil Stratford wrote: > On Thu, Aug 16, 2012 at 6:15 PM, Cullen Jennings (fluffy) > wrote: > > At the last meeting we took a hum on selecting Opus and G.711 as the mediatory to implement audio codecs. If there is any new opinions please send them to the list by August 30th, after which the chairs will make a determination of consensus. > > I support both G.711 and Opus as mandatory to implement. > > G.711 alone does not meet the rtcweb goal of producing a viable > alternative to browser plugins as it will be impossible for an > application developer to guarantee an acceptable audio quality > (defined as at least as good as when using plugins) for browser to > browser calls. Indeed. +1 for Opus and G.711 as MTI. Ron From cb.list6@gmail.com Fri Aug 31 21:38:14 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CFBC21F8444 for ; Fri, 31 Aug 2012 21:38:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.413 X-Spam-Level: X-Spam-Status: No, score=-3.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XxSyjcv+R-Ih for ; Fri, 31 Aug 2012 21:38:13 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 485DE21F842D for ; Fri, 31 Aug 2012 21:38:13 -0700 (PDT) Received: by lbky2 with SMTP id y2so1977436lbk.31 for ; Fri, 31 Aug 2012 21:38:12 -0700 (PDT) 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=P+7T7YrnP1j9u/HblBXBoqwUZFZfUcomOEMLgtOwQn0=; b=TQewQ/0lLBuJSXOGcIhfJq3400xAEmzXgX0FllqzH8IoFu5+oICnHLljMXx2IDlfg4 PJCn/dg/9ut6/4zF9TYyECXD/OC7ZllAYuRqm7GVWLJOkzmRFRKY7ZsOye2M5ay91nNj ddQNKdMPN/8nh3j3MN1Tq8fv8Xm6yXpp9RfHEO7AoaRJ4Up5+tOczjLUGNoByyKGFNrz QcRS2rU/tRaC0y8nTUn/k0gEhBhKNT6fV/wT8QvEPRclv6vWnBevK9m32e1wUKUR5h9/ 0vae731s6AqJ8mcei4j1f1x/wZduGwmuPbWygpScYctLPi02RPzjtDeFCUi3bb+M4jGI /Eow== MIME-Version: 1.0 Received: by 10.152.122.9 with SMTP id lo9mr662552lab.41.1346474292256; Fri, 31 Aug 2012 21:38:12 -0700 (PDT) Received: by 10.112.49.66 with HTTP; Fri, 31 Aug 2012 21:38:11 -0700 (PDT) In-Reply-To: <20120901031955.GF23434@audi.shelbyville.oz> References: <503F61CC.1010709@alvestrand.no> <503FC1BF.5020004@alvestrand.no> <5040541C.5020008@alvestrand.no> <20120831133845.GW72831@verdi> <5040CE32.5050003@jesup.org> <20120831151247.GY72831@verdi> <20120901031955.GF23434@audi.shelbyville.oz> Date: Fri, 31 Aug 2012 21:38:11 -0700 Message-ID: From: Cameron Byrne To: Ron Content-Type: text/plain; charset=ISO-8859-1 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] RTCWEB needs an Internet Codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 01 Sep 2012 04:38:14 -0000 On Fri, Aug 31, 2012 at 8:19 PM, Ron wrote: > On Fri, Aug 31, 2012 at 08:40:43AM -0700, Cameron Byrne wrote: >> Agree with the above. G.711 for mti only. >> >> I want to push Opus and promote its use, but MTI is not the right method >> for that. > > I haven't got the impression from this discussion that anybody thinks it > is about "pushing Opus" at all. The question is what is best for rtcweb. > > Since the charter of this group is to produce a standard that facilitates > "direct interactive rich communication", using things that already exist > as much as possible - I thought it was clear that the only important point > is that all this engineering work to produce rtcweb should not be a complete > waste of time for the people actually implementing it, and produce something > that gives such a poor experience in its baseline configuration that nobody > would ever actually want to use it for any of its intended purposes. > > That Opus is a very obvious choice of existing technology, which no other > single codec comes anywhere close to matching for this purpose, stands out > like an elephant in the room. Blind men might argue about whether it is a > pillar or a brush, or whether enough double blinded men have yet touched it > to be sure of this, but no amount of "pushing" is going to realistically > move it from that position one way or the other. > > Pretending that other much-poorer codecs could fill this role is abandoning > the "rich communication" part of the charter, and condemning this group to > an embarrassing failure to achieve its goals in any meaningful way. > > Let's not do that shall we. It seems quite clear that many people have an > intense interest in its success. Delaying this indefinitely, or selecting > poorer options than are already available today do not seem like the choices > that rational people who actually do want this to succeed would make. > > Interoperability requires an adequate MTI codec. Nobody has proposed an > alternative codec that is not clearly inadequate by comparison to Opus. > In a room full of clever engineers who want rtcweb to excel as a best of > breed specification, this decision should be a total no-brainer. > MTI is not about a room full of clever engineers, this thread and the position statements from XYZ companies should make that clear. MTI is about the least common denominator for a series of latent issues, including IPR FUD and legacy baggage. Consenting adults are free to offer and answer whatever codecs they like. CB > This time would be much better spent on the Actually Hard questions that > still remain for rtcweb. > > Best, > Ron > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From ron@debian.org Fri Aug 31 23:12:42 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9C2121F84AE for ; Fri, 31 Aug 2012 23:12:42 -0700 (PDT) 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_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NC3oo23VlZft for ; Fri, 31 Aug 2012 23:12:42 -0700 (PDT) Received: from ipmail05.adl6.internode.on.net (ipmail05.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:5]) by ietfa.amsl.com (Postfix) with ESMTP id B8A8D21F84A1 for ; Fri, 31 Aug 2012 23:12:40 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlkHAK6lQVB5LWvi/2dsb2JhbABFtnmEJYEIgiABAQQBOg0PIwULCw4KLhQYDSQTiAcFq2mOZIsNhyMDiE2FKIdiAZAagnM Received: from ppp121-45-107-226.lns20.adl6.internode.on.net (HELO audi.shelbyville.oz) ([121.45.107.226]) by ipmail05.adl6.internode.on.net with ESMTP; 01 Sep 2012 15:42:38 +0930 Received: from localhost (localhost [127.0.0.1]) by audi.shelbyville.oz (Postfix) with ESMTP id 6B6F04F8F3; Sat, 1 Sep 2012 15:42:37 +0930 (CST) X-Virus-Scanned: Debian amavisd-new at audi.shelbyville.oz Received: from audi.shelbyville.oz ([127.0.0.1]) by localhost (audi.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id oBaMXF5qemcm; Sat, 1 Sep 2012 15:42:36 +0930 (CST) Received: by audi.shelbyville.oz (Postfix, from userid 1000) id 4FB9B4F902; Sat, 1 Sep 2012 15:42:36 +0930 (CST) Date: Sat, 1 Sep 2012 15:42:36 +0930 From: Ron To: Cameron Byrne Message-ID: <20120901061236.GH23434@audi.shelbyville.oz> References: <503FC1BF.5020004@alvestrand.no> <5040541C.5020008@alvestrand.no> <20120831133845.GW72831@verdi> <5040CE32.5050003@jesup.org> <20120831151247.GY72831@verdi> <20120901031955.GF23434@audi.shelbyville.oz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] RTCWEB needs an Internet Codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 01 Sep 2012 06:12:43 -0000 On Fri, Aug 31, 2012 at 09:38:11PM -0700, Cameron Byrne wrote: > On Fri, Aug 31, 2012 at 8:19 PM, Ron wrote: > > On Fri, Aug 31, 2012 at 08:40:43AM -0700, Cameron Byrne wrote: > >> Agree with the above. G.711 for mti only. > >> > >> I want to push Opus and promote its use, but MTI is not the right method > >> for that. > > > > I haven't got the impression from this discussion that anybody thinks it > > is about "pushing Opus" at all. The question is what is best for rtcweb. > > > > Since the charter of this group is to produce a standard that facilitates > > "direct interactive rich communication", using things that already exist > > as much as possible - I thought it was clear that the only important point > > is that all this engineering work to produce rtcweb should not be a complete > > waste of time for the people actually implementing it, and produce something > > that gives such a poor experience in its baseline configuration that nobody > > would ever actually want to use it for any of its intended purposes. > > > > That Opus is a very obvious choice of existing technology, which no other > > single codec comes anywhere close to matching for this purpose, stands out > > like an elephant in the room. Blind men might argue about whether it is a > > pillar or a brush, or whether enough double blinded men have yet touched it > > to be sure of this, but no amount of "pushing" is going to realistically > > move it from that position one way or the other. > > > > Pretending that other much-poorer codecs could fill this role is abandoning > > the "rich communication" part of the charter, and condemning this group to > > an embarrassing failure to achieve its goals in any meaningful way. > > > > Let's not do that shall we. It seems quite clear that many people have an > > intense interest in its success. Delaying this indefinitely, or selecting > > poorer options than are already available today do not seem like the choices > > that rational people who actually do want this to succeed would make. > > > > Interoperability requires an adequate MTI codec. Nobody has proposed an > > alternative codec that is not clearly inadequate by comparison to Opus. > > In a room full of clever engineers who want rtcweb to excel as a best of > > breed specification, this decision should be a total no-brainer. > > > > MTI is not about a room full of clever engineers, this thread and the > position statements from XYZ companies should make that clear. MTI is > about the least common denominator for a series of latent issues, Yes, and least common denominator here doesn't mean "the worst possible codec that we can think of which might be called a codec". Nobody has proposed any credible alternative to Opus that might reasonably be seen as a plausible common denominator to a broad spectrum of the use cases. Opus doesn't just simply cover that range. It trounces pretty much every other codec across the whole spectrum, except for a tiny little corner of the extreme low-bandwidth case, where it's marginally worse than something which already sounds terrible. When your least common denominator also happens to be the best of breed across that whole range, that's a Good Thing right? Something to thank your lucky engineering stars for, not something to prevaricate about. > including IPR FUD and legacy baggage. FUD has no place here whatsoever, however popular it might be. Legacy baggage is a "will consider" item in the group charter, not a "will be stupidly constrained by to the detriment of the project". > Consenting adults are free to offer and answer whatever codecs they like. Yes. Yes, they are. And nobody has said or is saying they can't do so. It's also not the question here. The question is what is the minimum guarantee that any rtcweb user will have when talking to any other rtcweb user, without first needing to sign consent forms and download optional extras (possibly for a reasonably non-discriminatory fee, and even possibly trojaned). If the answer to that is "something terrible", then it's like suggesting that "Consenting adults are free to put wheels on their car". Of course they are, but it will be pretty useless for its intended purpose without them - and nobody in their right mind would make something like that deliberately. hth, Ron