From ekr@rtfm.com Wed Jan 2 07:13:43 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6255721F85C6 for ; Wed, 2 Jan 2013 07:13:43 -0800 (PST) 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.123, 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 dSAfgfTnZnT7 for ; Wed, 2 Jan 2013 07:13:38 -0800 (PST) Received: from mail-ob0-f171.google.com (mail-ob0-f171.google.com [209.85.214.171]) by ietfa.amsl.com (Postfix) with ESMTP id 0EE3721F85C8 for ; Wed, 2 Jan 2013 07:13:38 -0800 (PST) Received: by mail-ob0-f171.google.com with SMTP id dn14so12813904obc.2 for ; Wed, 02 Jan 2013 07:13:37 -0800 (PST) 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:cc :content-type:x-gm-message-state; bh=7U891h5iOTQsCnnyw77pEaeyzSBnD0e+jf+S8jTyIsw=; b=c4YSmvpWiCL6+4fAGEQT/JRASV66vXzGHd6LBhRnwoyr5dB4ogGrpcLLNue2ZyIFhA Cws3PvjDsh8nE9Ldrw65oevC2W0o8WSrELkWZyinqG19KiSIKo9yqneQVF63E4uBRbLP KIUKJ45oS/qa9EV32SOa+DJtBFYTz0pilWhUZ3dJypXjnb/2wqxr6cPFHISqG/xbC5xs EzpgymOqCmO8jGRs2Fl+zSYTbM0VinE2OKVZvhouj8fPSMKZRuqKCEb6vrXEh2ZDcIv3 Eoojhit1PIBNEj8TeDK7jhEx3ugBYtt9Ud9BSDnqPUMsmBOOve4tlKXL9iIo+NXICsHd IXHw== Received: by 10.60.168.198 with SMTP id zy6mr26391955oeb.89.1357139617557; Wed, 02 Jan 2013 07:13:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.77.225 with HTTP; Wed, 2 Jan 2013 07:12:57 -0800 (PST) X-Originating-IP: [74.95.2.173] From: Eric Rescorla Date: Wed, 2 Jan 2013 07:12:57 -0800 Message-ID: To: rtcweb-chairs@tools.ietf.org Content-Type: multipart/alternative; boundary=bcaec54c502ed0acf304d24fb03e X-Gm-Message-State: ALoCoQmCzLHeoq2+p//T7VuW0fF0W0/ZxG35rO5YnPWMYvbOAW0vPntqazX7K4MOR8rBvtvi/2O+ Cc: rtcweb@ietf.org Subject: [rtcweb] Proposed Agenda for Interim X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 02 Jan 2013 15:13:43 -0000 --bcaec54c502ed0acf304d24fb03e Content-Type: text/plain; charset=ISO-8859-1 Chairs, I've spent some time thinking about the agenda for the interim, and thought it might be helpful if I sent you a strawman based on the items that are blocking progress in terms of implementation and interoperability. Note: I am assuming 4 hours each day. The times have been selected with the objective of giving us enough time to really resolve the open issues. Honestly, we might even add more time for the issues on day 1. Hope this is helpful. Day 1 2:00 Bundle [Holmberg] Objective: select an approach and work out enough details that the editors can work to produce a suitable draft. Drafts: - http://tools.ietf.org/html/draft-ietf-mmusic-sdp-bundle-negotiation - http://tools.ietf.org/html/draft-alvestrand-one-rtp - http://tools.ietf.org/html/draft-holmberg-mmusic-sdp-mmt-negotiation 2:00 Multiple flow SDP representation [Jennings, Alvestrand] Objective: decide on an architecture for large numbers of similar streams (e.g., multiple video streams). Drafts: - http://tools.ietf.org/html/draft-alvestrand-rtcweb-msid - http://tools.ietf.org/html/draft-alvestrand-mmusic-msid - Do we have a "master" document for the single m-line case? - Multiple m-lines doesn't have a document Day 2 1:30 Mapping stream/track label concepts SDP identifiers [Alvestrand] Objective: determine requirements 1:30 Trickle ICE open issues [Ivov(?), Uberti, Rescorla] - Starting checks - Termination conditions - Error handling Drafts: http://tools.ietf.org/html/draft-rescorla-mmusic-ice-trickle 1:00 SDP for Datachannels open issues [Jesup, Loreto] Objective: resolve open issues (post WGLC?) Drafts: http://tools.ietf.org/html/draft-ietf-mmusic-sctp-sdp-02 Day 3 1:00 Other recommended audio codecs [Roach] Objective: identify what other audio codecs we intend to recommend. 1:00 Process WGLC comments on documents [authors] 0:30 Other business 0:30 Wrapup/next steps [Chairs] Best, -Ekr --bcaec54c502ed0acf304d24fb03e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Chairs,

I've spent some time thinking abo= ut the agenda for the interim, and
thought it might be helpful if= I sent you a strawman based on the
items that are blocking progr= ess in terms of implementation and
interoperability.

Note:
I am assumi= ng 4 hours each day. The times have been selected with
the object= ive of giving us enough time to really resolve the
open issues. H= onestly, we might even add more time for
the issues on day 1.

Hope this is helpful.

Day 1
2:00 =A0 =A0Bundle =A0 [Holmberg]
Ob= jective: select an approach and work out enough
detai= ls that the editors can work to produce a
suitable draft.

Drafts:


2:00 =A0 =A0Multiple flow SDP representa= tion [Jennings, Alvestrand]
Objective: decide on an architecture for large= numbers
of si= milar streams (e.g., multiple video streams).

Drafts:
<= div> - http://tools.i= etf.org/html/draft-alvestrand-rtcweb-msid
- Do = we have a "master" document for the single m-line case?
- Multipl= e m-lines doesn't have a document


Day 2
1:30 =A0 =A0Mapping stre= am/track label concepts SDP identifiers [Alvestrand]
Objective: determine = requirements
1:30 =A0 =A0Trickle ICE open issues [Ivov(?), Uberti, Rescorla]
- Sta= rting checks
- Termination conditions
- Error handling
Draf= ts:

1:00 =A0 =A0SDP for Datachannels open issues [Jesup, Lo= reto]
<= /span>Objective: resolve open issues (post WGLC?)

= Drafts:

= Day 3
1:00 =A0 =A0Other recommended audio codecs [Roach]
Objective: identif= y what other audio codecs we intend to
recom= mend.

1:00 =A0 =A0Process WGLC comments on documents [author= s]

0:30 =A0 =A0Other business

0:3= 0 =A0 =A0Wrapup/next steps [Chairs]


Best,
-Ekr

--bcaec54c502ed0acf304d24fb03e-- From stefan.lk.hakansson@ericsson.com Wed Jan 2 09:15:52 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4E8521F865B for ; Wed, 2 Jan 2013 09:15:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.009 X-Spam-Level: X-Spam-Status: No, score=-6.009 tagged_above=-999 required=5 tests=[AWL=-0.060, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, 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 nuMMeYJA8plb for ; Wed, 2 Jan 2013 09:15:51 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 6462F21F8635 for ; Wed, 2 Jan 2013 09:15:51 -0800 (PST) X-AuditID: c1b4fb25-b7fb26d000006129-04-50e46b45343b Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id DD.42.24873.54B64E05; Wed, 2 Jan 2013 18:15:50 +0100 (CET) Received: from [153.88.62.103] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.279.1; Wed, 2 Jan 2013 18:15:49 +0100 Message-ID: <50E46B45.6080100@ericsson.com> Date: Wed, 2 Jan 2013 18:15:49 +0100 From: =?windows-1252?Q?Stefan_H=E5kansson_LK?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <7594FB04B1934943A5C02806D1A2204B06E211@ESESSMB209.ericsson.se> In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDJMWRmVeSWpSXmKPExsUyM+Jvja5b9pMAg0kPOSzW/mtnd2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxo8r15gKTotW/Jx+lbGBsVuwi5GTQ0LARGLVlYdsELaYxIV7 64FsLg4hgZOMEjPnb2aBcFYxSuxvnMMCUsUroC0x+fxsRhCbRUBFYtKGDaxdjBwcbALBEjOm GIGERQVCJK5/f8QIUS4ocXLmE7BWEQFhia2veplAbGEBR4k/1xeA2UIClRLreiaC1XMKWElM O3GRHWQks4C9xIOtZSBhZgF5ieats5khynUl3r2+xzqBUWAWkg2zEDpmIelYwMi8ipE9NzEz J73caBMjMMQObvmtuoPxzjmRQ4zSHCxK4rzhrhcChATSE0tSs1NTC1KL4otKc1KLDzEycXBK NTCySXZkMHXdfPtdkf1Z/eP2B4IZVds3/Ra6o/3xTqHhfePNGfsSYlcw/OvLDV9++dBJ7ojD kSpRFzvfqriEqXK83sS7ccqmfJ9/j3anLb61cIWdLFOwxSV1vcBMWe0JbHu5nHXmnXkwa+3k Z9+/S5xVkHd4bdb6LUOPTXmr1YUqe73gcm8zs0lKLMUZiYZazEXFiQBfb/Fy/wEAAA== Subject: Re: [rtcweb] Support of video with different resolutions X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 02 Jan 2013 17:15:52 -0000 On 2012-12-21 16:40, Bernard Aboba wrote: > Christer said: > > "If we want to support content sent in different resolutions, the > question is whether we need to mandate the browser to support a specific > > mechanism. As shown in the note, there are basically 3 mechanisms: SVC, > simulcast and “local transcoding”." > > > [BA] One of the reasons that "no MTI codec proposal supports SVC" is > that by definition mandates apply to a wide range of situations, from a > browser on a mobile device to a desktop scenario involving exchange of > multiple streams at high bandwidth. This leads to mandates focusing on > the "lowest common denominator", which may make it difficult mandate > browser support for encoding of SVC or simulcast. > > > SVC supports multiple scalability mechanisms: temporal, spatial and > quality. Temporal is the most widely implemented in software (at least > for H.264/SVC), although there is an open source implementation that > supports all modes. In hardware, support for spatial or quality scaling > is not common. As a result, a browser on a mobile device could have > difficulty complying with a mandate to support spatial scaling within > the encoder. > > > Although cameras on mobile devices are growing increasingly capable, > unlimited usage LTE plans are still not ubiquitous, which puts a damper > on sending of simulcast from mobile devices. I think differently. If you don't support simulcast, you'd send just the high resolution stream. Sending a low resolution version of the same content does not add that much in terms of transmitted bits. And, if we get some nice way to signal pause/resume with really short latency simulcast could even save bandwidth since it might be quite common that only the low resolution version is actually being streamed for a large portion of the session. Another way to look at this is that we already have the following requirement: "F11 The browser MUST be able to transmit streams and data to several peers concurrently.", and presumably there would be independent rate control for these streams (since they may experience different network conditions), simulcast is in sense just a special case (the two other peer's are the same endpoint). I would like to see support for simulcast (which in combination with processing such as that Randell talks about would enable a nice multiparty experience even if SVC is not used). > > > Given the above, it seems hard to mandate any of the above options. > > > > > > > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From fluffy@cisco.com Wed Jan 2 10:18:25 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5784321F87E0; Wed, 2 Jan 2013 10:18:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.549 X-Spam-Level: X-Spam-Status: No, score=-110.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 Es-KU2TqV854; Wed, 2 Jan 2013 10:18:24 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 2316721F87D2; Wed, 2 Jan 2013 10:18:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3813; q=dns/txt; s=iport; t=1357150703; x=1358360303; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=FMQEbzm5lpeppxQaEs3Vn1qUZzxvAP9MfcnLR+/9UDs=; b=mQaAMispodFCqwuMYUiJsyKI0tIAHQNOc/GAqAhmt2PgI1vLXRY6gBEV cKv1UG+L9Qz19ZA3XyqdpJv35xHpJVYC6QW21JmOI3OEwduXrJrcvheqR 4RR39VUHym72NJ83eOM2X9i+0AUmOeCz4t/WdPMtOboQg4Vb8PkSX/PlQ U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ajg6AHh55FCtJV2d/2dsb2JhbAA7CoF/qHuSRxZzgh4BAQEDAQEBATc0CwULAgEIEgYKFBAnCxcOAgQOBQgTh2YDCQYMuQiLbXUGCoNHYQOUN4JxihuFEYJ0gXE1 X-IronPort-AV: E=Sophos;i="4.84,397,1355097600"; d="scan'208";a="157931308" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-1.cisco.com with ESMTP; 02 Jan 2013 18:18:22 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r02IIMgH001565 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 2 Jan 2013 18:18:22 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.230]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.02.0318.004; Wed, 2 Jan 2013 12:18:22 -0600 From: "Cullen Jennings (fluffy)" To: Bernard Aboba Thread-Topic: [MMUSIC] [rtcweb] Proposed Agenda for Interim Thread-Index: AQHN6RWLwHg6h8loV0m39uFY3MM6iQ== Date: Wed, 2 Jan 2013 18:18:21 +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.20.249.164] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" , "mmusic@ietf.org" Subject: Re: [rtcweb] [MMUSIC] Proposed Agenda for Interim X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 02 Jan 2013 18:18:25 -0000 I'm not really sure what to do here - given a key role of the chairs is lar= gely to facilitate the discussions and meetings that Wg participants want t= o have, guidance from participants of both MMUSIC and rtcweb is really imp= ortant here.=20 I agree that=20 1) the items in EKR's email do look like the a bunch of the high runner ite= ms that need to be resolved soon=20 2) the solutions of these problems are likely in to be mostly MMUSIC though= , as Ted has pointed out, some amount of the requirements, architecture and= other discussion can happen in rtcweb.=20 3) if we are going to have an MMUSIC face to face interim meeting, it would= need AD approval and 4 weeks notices which puts us very close do the deadl= ine so this needs to get sort out real soon.=20 Cullen On Jan 2, 2013, at 8:24 AM, Bernard Aboba wrote= : > This is a good agenda - for an MMUSIC WG interim (only day 3 has any RTCW= EB items on it). >=20 > Since there is a notice requirement, can we get MMUSIC on board so the in= terim can actually take place? >=20 > On Jan 2, 2013, at 7:13, "Eric Rescorla" wrote: >=20 >> Chairs, >>=20 >> I've spent some time thinking about the agenda for the interim, and >> thought it might be helpful if I sent you a strawman based on the >> items that are blocking progress in terms of implementation and >> interoperability. >>=20 >> Note: >> I am assuming 4 hours each day. The times have been selected with >> the objective of giving us enough time to really resolve the >> open issues. Honestly, we might even add more time for >> the issues on day 1. >>=20 >> Hope this is helpful. >>=20 >> Day 1 >> 2:00 Bundle [Holmberg] >> Objective: select an approach and work out enough >> details that the editors can work to produce a >> suitable draft. >>=20 >> Drafts: >> - http://tools.ietf.org/html/draft-ietf-mmusic-sdp-bundle-negotiation >> - http://tools.ietf.org/html/draft-alvestrand-one-rtp >> - http://tools.ietf.org/html/draft-holmberg-mmusic-sdp-mmt-negotiation >>=20 >>=20 >> 2:00 Multiple flow SDP representation [Jennings, Alvestrand] >> Objective: decide on an architecture for large numbers >> of similar streams (e.g., multiple video streams). >>=20 >> Drafts: >> - http://tools.ietf.org/html/draft-alvestrand-rtcweb-msid >> - http://tools.ietf.org/html/draft-alvestrand-mmusic-msid >> - Do we have a "master" document for the single m-line case? >> - Multiple m-lines doesn't have a document >>=20 >>=20 >> Day 2 >> 1:30 Mapping stream/track label concepts SDP identifiers [Alvestrand] >> Objective: determine requirements >> =09 >> =09 >> 1:30 Trickle ICE open issues [Ivov(?), Uberti, Rescorla] >> =09 >> - Starting checks >> - Termination conditions >> - Error handling >> =09 >> Drafts: >> http://tools.ietf.org/html/draft-rescorla-mmusic-ice-trickle =09 >>=20 >> 1:00 SDP for Datachannels open issues [Jesup, Loreto] >> Objective: resolve open issues (post WGLC?) >>=20 >> Drafts: >> http://tools.ietf.org/html/draft-ietf-mmusic-sctp-sdp-02 >>=20 >> Day 3 >> 1:00 Other recommended audio codecs [Roach] >> =09 >> Objective: identify what other audio codecs we intend to >> recommend.=09 >>=20 >> 1:00 Process WGLC comments on documents [authors] >>=20 >> 0:30 Other business >>=20 >> 0:30 Wrapup/next steps [Chairs] >>=20 >>=20 >> Best, >> -Ekr >>=20 >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From fluffy@cisco.com Wed Jan 2 10:19:35 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E0D621F87ED; Wed, 2 Jan 2013 10:19:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.137 X-Spam-Level: X-Spam-Status: No, score=-105.137 tagged_above=-999 required=5 tests=[AWL=-5.377, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_BAD_ID=2.837, UNPARSEABLE_RELAY=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 xZIAtMI3Vxay; Wed, 2 Jan 2013 10:19:34 -0800 (PST) Received: from WIN-CDPOO5N337C (gw.ntelia.co.kr [175.196.232.146]) by ietfa.amsl.com (Postfix) with ESMTP id F090821F87E3; Wed, 2 Jan 2013 10:19:33 -0800 (PST) Received: from mail pickup service by WIN-CDPOO5N337C with Microsoft SMTPSVC; Thu, 3 Jan 2013 03:18:36 +0900 Content-Transfer-Encoding: 7bit Content-ID: Content-Language: en-US x-sender: fluffy@cisco.com x-receiver: hongkee67@gmail.com Received: from mail.ietf.org ([64.170.98.30]) by WIN-CDPOO5N337C with Microsoft SMTPSVC(7.5.7601.17514); Thu, 3 Jan 2013 03:18:28 +0900 Received: from ietfa.amsl.com (localhost [127.0.0.1])by ietfa.amsl.com (Postfix) with ESMTP id 3B91C21F87E0;Wed, 2 Jan 2013 10:18:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1357150707; bh=NUlb3t2l9TyEAx0Bc/tfn1Q5eVtN/AT69B6DoliHFtA=; h=From:To:Date:Message-ID:References:In-Reply-To:Content-ID: MIME-Version:Cc:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:Content-Type: Content-Transfer-Encoding:Sender; b=ebsx1JF4UR/VT3V1eDWtvI+MdMpRsQ2Ot3RDfc9W2veYwIFS7BGTATHkGWSv6hhTL zwpA3nH3Ujtm5FeFm35a/+F6aLRggNgLwiK+b7wtwv1Rz3KI1vnVbOniLdYLxrPB5I hJMae54/PTg4yERbdFKftUjyu4TVCffuKrDSdQCM= X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1])by ietfa.amsl.com (Postfix) with ESMTP id 5784321F87E0;Wed, 2 Jan 2013 10:18:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 Es-KU2TqV854; Wed, 2 Jan 2013 10:18:24 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72])by ietfa.amsl.com (Postfix) with ESMTP id 2316721F87D2; Wed, 2 Jan 2013 10:18:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3813; q=dns/txt; s=iport;t=1357150703; x=1358360303; h=from:to:cc:subject:date:message-id:references:in-reply-to:content-id:content-transfer-encoding: mime-version; bh=FMQEbzm5lpeppxQaEs3Vn1qUZzxvAP9MfcnLR+/9UDs=; b=mQaAMispodFCqwuMYUiJsyKI0tIAHQNOc/GAqAhmt2PgI1vLXRY6gBEVcKv1UG+L9Qz19ZA3XyqdpJv35xHpJVYC6QW21JmOI3OEwduXrJrcvheqR4RR39VUHym72NJ83eOM2X9i+0AUmOeCz4t/WdPMtOboQg4Vb8PkSX/PlQ U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ajg6AHh55FCtJV2d/2dsb2JhbAA7CoF/qHuSRxZzgh4BAQEDAQEBATc0CwULAgEIEgYKFBAnCxcOAgQOBQgTh2YDCQYMuQiLbXUGCoNHYQOUN4JxihuFEYJ0gXE1 X-IronPort-AV: E=Sophos;i="4.84,397,1355097600"; d="scan'208";a="157931308" Received: from rcdn-core-6.cisco.com ([173.37.93.157])by rcdn-iport-1.cisco.com with ESMTP; 02 Jan 2013 18:18:22 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84])by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r02IIMgH001565(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 2 Jan 2013 18:18:22 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.230]) byxhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.02.0318.004; Wed, 2 Jan 2013 12:18:22 -0600 From: "Cullen Jennings (fluffy)" To: "Bernard Aboba" Thread-Topic: [MMUSIC] [rtcweb] Proposed Agenda for Interim Thread-Index: AQHN6RWLwHg6h8loV0m39uFY3MM6iQ== Date: Wed, 2 Jan 2013 18:18:21 +0000 Message-ID: <1.aa0f2c26065fe34bccbd@cisco.com> References: In-Reply-To: Accept-Language: en-US x-originating-ip: [10.20.249.164] MIME-Version: 1.0 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-OriginalArrivalTime: 02 Jan 2013 18:18:28.0514 (UTC) FILETIME=[901EE020:01CDE915] Content-Type: multipart/alternative; boundary="----=_NextPart_000_FBF7_654FCBE2.884D5ED6" Cc: "rtcweb@ietf.org" , "mmusic@ietf.org" Subject: Re: [rtcweb] [MMUSIC] Proposed Agenda for Interim X-BeenThere: rtcweb@ietf.org List-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, 02 Jan 2013 18:19:35 -0000 ------=_NextPart_000_FBF7_654FCBE2.884D5ED6 Content-Language: en-US Content-ID: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I'm not really sure what to do here - given a key role of the chairs is largely to facilitate the discussions and meetings that Wg participants want to have, guidance from participants of both MMUSIC and rtcweb is really important here. I agree that 1) the items in EKR's email do look like the a bunch of the high runner items that need to be resolved soon 2) the solutions of these problems are likely in to be mostly MMUSIC though, as Ted has pointed out, some amount of the requirements, architecture and other discussion can happen in rtcweb. 3) if we are going to have an MMUSIC face to face interim meeting, it would need AD approval and 4 weeks notices which puts us very close do the deadline so this needs to get sort out real soon. Cullen On Jan 2, 2013, at 8:24 AM, Bernard Aboba wrote: > This is a good agenda - for an MMUSIC WG interim (only day 3 has any RTCWEB items on it). > > Since there is a notice requirement, can we get MMUSIC on board so the interim can actually take place? > > On Jan 2, 2013, at 7:13, "Eric Rescorla" wrote: > >> Chairs, >> >> I've spent some time thinking about the agenda for the interim, and >> thought it might be helpful if I sent you a strawman based on the >> items that are blocking progress in terms of implementation and >> interoperability. >> >> Note: >> I am assuming 4 hours each day. The times have been selected with >> the objective of giving us enough time to really resolve the >> open issues. Honestly, we might even add more time for >> the issues on day 1. >> >> Hope this is helpful. >> >> Day 1 >> 2:00 Bundle [Holmberg] >> Objective: select an approach and work out enough >> details that the editors can work to produce a >> suitable draft. >> >> Drafts: >> - http://tools.ietf.org/html/draft-ietf-mmusic-sdp-bundle-negotiation >> - http://tools.ietf.org/html/draft-alvestrand-one-rtp >> - http://tools.ietf.org/html/draft-holmberg-mmusic-sdp-mmt-negotiation >> >> >> 2:00 Multiple flow SDP representation [Jennings, Alvestrand] >> Objective: decide on an architecture for large numbers >> of similar streams (e.g., multiple video streams). >> >> Drafts: >> - http://tools.ietf.org/html/draft-alvestrand-rtcweb-msid >> - http://tools.ietf.org/html/draft-alvestrand-mmusic-msid >> - Do we have a "master" document for the single m-line case? >> - Multiple m-lines doesn't have a document >> >> >> Day 2 >> 1:30 Mapping stream/track label concepts SDP identifiers [Alvestrand] >> Objective: determine requirements >> >> >> 1:30 Trickle ICE open issues [Ivov(?), Uberti, Rescorla] >> >> - Starting checks >> - Termination conditions >> - Error handling >> >> Drafts: >> http://tools.ietf.org/html/draft-rescorla-mmusic-ice-trickle >> >> 1:00 SDP for Datachannels open issues [Jesup, Loreto] >> Objective: resolve open issues (post WGLC?) >> >> Drafts: >> http://tools.ietf.org/html/draft-ietf-mmusic-sctp-sdp-02 >> >> Day 3 >> 1:00 Other recommended audio codecs [Roach] >> >> Objective: identify what other audio codecs we intend to >> recommend. >> >> 1:00 Process WGLC comments on documents [authors] >> >> 0:30 Other business >> >> 0:30 Wrapup/next steps [Chairs] >> >> >> Best, >> -Ekr >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic ------=_NextPart_000_FBF7_654FCBE2.884D5ED6 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I'm not really sure what to do here - given a key role of the chairs is lar= gely to facilitate the discussions and meetings that Wg participants want t= o have, guidance from participants of both MMUSIC and rtcweb is really imp= ortant here.

I agree that

1) the items in EKR's email do look like the a bunch of the high runner ite= ms that need to be resolved soon

2) the solutions of these problems are likely in to be mostly MMUSIC though= , as Ted has pointed out, some amount of the requirements, architecture and= other discussion can happen in rtcweb.

3) if we are going to have an MMUSIC face to face interim meeting, it would= need AD approval and 4 weeks notices which puts us very close do the deadl= ine so this needs to get sort out real soon.

Cullen



On Jan 2, 2013, at 8:24 AM, Bernard Aboba <bernard_aboba@hotmail.com>= wrote:

> This is a good agenda - for an MMUSIC WG interim (only day 3 has any R= TCWEB items on it).
>
> Since there is a notice requirement, can we get MMUSIC on board so the= interim can actually take place?
>
> On Jan 2, 2013, at 7:13, "Eric Rescorla" <ekr@rtfm.com>= ; wrote:
>
>> Chairs,
>>
>> I've spent some time thinking about the agenda for the interim, and
>> thought it might be helpful if I sent you a strawman based on the
>> items that are blocking progress in terms of implementation and
>> interoperability.
>>
>> Note:
>> I am assuming 4 hours each day. The times have been selected with
>> the objective of giving us enough time to really resolve the
>> open issues. Honestly, we might even add more time for
>> the issues on day 1.
>>
>> Hope this is helpful.
>>
>> Day 1
>> 2:00 Bundle [Holmberg]
>> Objective: select an approach and work out enough
>> details that the editors can work to produce a
>> suitable draft.
>>
>> Drafts:
>> - http://tools.ietf.org/html/draft-ietf-mmusic-sdp-bundle-negotia= tion
>> - http://tools.ietf.org/html/draft-alvestrand-one-rtp
>> - http://tools.ietf.org/html/draft-holmberg-mmusic-sdp-mmt-negoti= ation
>>
>>
>> 2:00 Multiple flow SDP representation [Jennings, Alvestrand]
>> Objective: decide on an architecture for large numbers
>> of similar streams (e.g., multiple video streams).
>>
>> Drafts:
>> - http://tools.ietf.org/html/draft-alvestrand-rtcweb-msid
>> - http://tools.ietf.org/html/draft-alvestrand-mmusic-msid
>> - Do we have a "master" document for the single m-line = case?
>> - Multiple m-lines doesn't have a document
>>
>>
>> Day 2
>> 1:30 Mapping stream/track label concepts SDP identifiers [Alves= trand]
>> Objective: determine requirements
>>
>>
>> 1:30 Trickle ICE open issues [Ivov(?), Uberti, Rescorla]
>>
>> - Starting checks
>> - Termination conditions
>> - Error handling
>>
>> Drafts:
>> http://tools.ietf.org/html/draft-rescorla-mmusic-ice-trickle
>>
>> 1:00 SDP for Datachannels open issues [Jesup, Loreto]
>> Objective: resolve open issues (post WGLC?)
>>
>> Drafts:
>> http://tools.ietf.org/html/draft-ietf-mmusic-sctp-sdp-02
>>
>> Day 3
>> 1:00 Other recommended audio codecs [Roach]
>>
>> Objective: identify what other audio codecs we intend to
>> recommend.
>>
>> 1:00 Process WGLC comments on documents [authors]
>>
>> 0:30 Other business
>>
>> 0:30 Wrapup/next steps [Chairs]
>>
>>
>> Best,
>> -Ekr
>>
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
> <Mail Attachment.txt>___________________________________________= ____
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic

_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic
------=_NextPart_000_FBF7_654FCBE2.884D5ED6-- From ted.ietf@gmail.com Wed Jan 2 10:32:22 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEAD121F87FA for ; Wed, 2 Jan 2013 10:32:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.31 X-Spam-Level: X-Spam-Status: No, score=-3.31 tagged_above=-999 required=5 tests=[AWL=-0.012, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 iAzY-iWvRHDu for ; Wed, 2 Jan 2013 10:32:22 -0800 (PST) Received: from mail-ie0-f182.google.com (mail-ie0-f182.google.com [209.85.223.182]) by ietfa.amsl.com (Postfix) with ESMTP id 60E8E21F8206 for ; Wed, 2 Jan 2013 10:32:22 -0800 (PST) Received: by mail-ie0-f182.google.com with SMTP id s9so17060665iec.41 for ; Wed, 02 Jan 2013 10:32:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gVjm5c5hGmSX9jmbHwMsdXiWXGR9FdQKd1M4aXHeHK0=; b=aVrcxVMO9lS8i1Q99O1wYhy6rNy/cVcxbBS3pJXmiv4aXxuDLlS15KForqgL7hBOs8 gtJ1dvv5qWtOqxF+wyuRYR5OuwuYajUoogZDIAcCY4kRdzi9k4IWVQ5YjyUHwPBYmbfL 2gdeEKJz284lEabx6pG1G0ZRQi6882emdYeF+zrq5eVSEWcTxfJ1iz3yjXlFy16PwwsX GeZ0/oLKUfJH9UZu214n/L80xwBxB9jSWYQQDjxPNlDtXEsuhqX0lonWuyhikYSYI6yX lY8ub5G/Jd9IzF2Zn6JrhXtKB6W3OAm98KaYuJkFayetHxgx26Fe0Nw8RFGMu5dxi0e5 Lg/g== MIME-Version: 1.0 Received: by 10.50.236.104 with SMTP id ut8mr41036618igc.20.1357151541930; Wed, 02 Jan 2013 10:32:21 -0800 (PST) Received: by 10.43.94.5 with HTTP; Wed, 2 Jan 2013 10:32:21 -0800 (PST) In-Reply-To: <50E46B45.6080100@ericsson.com> References: <7594FB04B1934943A5C02806D1A2204B06E211@ESESSMB209.ericsson.se> <50E46B45.6080100@ericsson.com> Date: Wed, 2 Jan 2013 10:32:21 -0800 Message-ID: From: Ted Hardie To: =?ISO-8859-1?Q?Stefan_H=E5kansson_LK?= Content-Type: multipart/alternative; boundary=14dae9340343902c7b04d25277e8 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Support of video with different resolutions X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 02 Jan 2013 18:32:23 -0000 --14dae9340343902c7b04d25277e8 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Jan 2, 2013 at 9:15 AM, Stefan H=E5kansson LK < stefan.lk.hakansson@ericsson.com> wrote: > > Another way to look at this is that we already have the following > requirement: > > "F11 The browser MUST be able to transmit streams and > data to several peers concurrently.", > > and presumably there would be independent rate control for these streams > (since they may experience different network conditions), > > simulcast is in sense just a special case (the two other peer's are the > same endpoint). > > While I agree that you could model it this way, I think it may be more appropriate to treat simulcast as its own case, rather than as a special case of the multiple peer. Consider this pair of scenarios: Case one: There is one endpoint, Zelda, which is sending media via Turn service to two hosts behind the same NAT (let's call them Scott and Edouard). There is independent rate control for the streams sending this media. Case two: There is an endpoint, Zelda, which is sending simulcast media to Scott, which is using a Turn service and is behind a NAT. Isn't managing fairness going to be potentially very different between case one and case two? regards, Ted --14dae9340343902c7b04d25277e8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Jan 2, 2013 at 9:15 AM, Stefan H=E5kansson LK <= ;stef= an.lk.hakansson@ericsson.com> wrote:

Another way to look at this is that we already have the following requireme= nt:

"F11 =A0 =A0 =A0 =A0 =A0 =A0 The browser MUST be able to transmit stre= ams and
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0data to several peers concurrently.&= quot;,

and presumably there would be independent rate control for these streams (s= ince they may experience different network conditions),

simulcast is in =A0sense just a special case (the two other peer's are = the same endpoint).


While I agree that you could model it this way, I= think it may be more appropriate to treat simulcast as its own case, rathe= r than as a special case of the multiple peer.=A0

Consider this pai= r of scenarios:

Case one:
There is one endpoint, Zelda, which is sending media via T= urn service to two hosts behind the same NAT (let's call them Scott and= Edouard).=A0=A0 There is independent rate control for the streams sending = this media.

Case two:
There is an endpoint, Zelda, which is sending simulcast me= dia to Scott, which is using a Turn service and is behind a NAT.

Isn= 't managing fairness going to be potentially very different between cas= e one and case two?=A0

regards,

Ted
--14dae9340343902c7b04d25277e8-- From ted.ietf@gmail.com Wed Jan 2 10:39:54 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9211821F842D; Wed, 2 Jan 2013 10:39:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.459 X-Spam-Level: X-Spam-Status: No, score=-3.459 tagged_above=-999 required=5 tests=[AWL=0.139, 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 acPp7YV5Db6s; Wed, 2 Jan 2013 10:39:53 -0800 (PST) Received: from mail-ia0-f182.google.com (mail-ia0-f182.google.com [209.85.210.182]) by ietfa.amsl.com (Postfix) with ESMTP id 865AB21F882C; Wed, 2 Jan 2013 10:39:53 -0800 (PST) Received: by mail-ia0-f182.google.com with SMTP id x2so12149004iad.13 for ; Wed, 02 Jan 2013 10:39:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=9zcC0yH3yAyzhR8CR+FxtJRvB3M3PQus43EUA3qmTR8=; b=0y2xVDmm1QbEddiPQIwowav64yW11UME1AX9x5kUHmZ2n/JA6EJ1dbHfdrvZzOxakT ivyIpR9Nn6DkTsxvrkmaYDJYNWzyNKEF9hMe0Os/kzSD6FNrvurvnxcJnxZTtvimx8Uf aXAgrOUuwOPvorjA65rENEuCzcwboBN85FF+LHzokayKNezVHWv5AeR1Hi27KIxPqBZz 0+zX2f2gEhHmJ7pqnsOxX/oOrU4iqN3jIOE1gVE96WmtpY1W1gSbSTRxxveZUTqMVzQW uXebon9WB4a5u+ZNPjWi4pgQbgHujO461bwGBlN9Djpe817RsL+FB6qnjA23bFcSbN6X w+sg== MIME-Version: 1.0 Received: by 10.42.48.147 with SMTP id s19mr35287128icf.18.1357151993111; Wed, 02 Jan 2013 10:39:53 -0800 (PST) Received: by 10.43.94.5 with HTTP; Wed, 2 Jan 2013 10:39:53 -0800 (PST) In-Reply-To: References: Date: Wed, 2 Jan 2013 10:39:53 -0800 Message-ID: From: Ted Hardie To: "Cullen Jennings (fluffy)" Content-Type: multipart/alternative; boundary=90e6ba1efbc274a4e504d2529282 Cc: "rtcweb@ietf.org" , "mmusic@ietf.org" Subject: Re: [rtcweb] [MMUSIC] Proposed Agenda for Interim X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 02 Jan 2013 18:39:54 -0000 --90e6ba1efbc274a4e504d2529282 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jan 2, 2013 at 10:18 AM, Cullen Jennings (fluffy) wrote: > > 2) the solutions of these problems are likely in to be mostly MMUSIC > though, as Ted has pointed out, some amount of the requirements, > architecture and other discussion can happen in rtcweb. > > I actually believe it can go beyond requirements and architecture; I believe that if RTCWEB can come to a firm understanding of what solutions are best for its use cases, it can communicate that to MMUSIC. That doesn't mean the final decision doesn't rest with MMUSIC--it does--but it does mean that RTCWEB doesn't have to leave the technology discussion completely off the table. A good analysis can go to MMUSIC for discussion and potential resolution in/by Orlando. 3) if we are going to have an MMUSIC face to face interim meeting, it would > need AD approval and 4 weeks notices which puts us very close do the > deadline so this needs to get sort out real soon. > > There is also the option of a virtual interim, which is (somewhat) less of a logistical issue. Ted > Cullen > > > > On Jan 2, 2013, at 8:24 AM, Bernard Aboba > wrote: > > > This is a good agenda - for an MMUSIC WG interim (only day 3 has any > RTCWEB items on it). > > > > Since there is a notice requirement, can we get MMUSIC on board so the > interim can actually take place? > > > > On Jan 2, 2013, at 7:13, "Eric Rescorla" wrote: > > > >> Chairs, > >> > >> I've spent some time thinking about the agenda for the interim, and > >> thought it might be helpful if I sent you a strawman based on the > >> items that are blocking progress in terms of implementation and > >> interoperability. > >> > >> Note: > >> I am assuming 4 hours each day. The times have been selected with > >> the objective of giving us enough time to really resolve the > >> open issues. Honestly, we might even add more time for > >> the issues on day 1. > >> > >> Hope this is helpful. > >> > >> Day 1 > >> 2:00 Bundle [Holmberg] > >> Objective: select an approach and work out enough > >> details that the editors can work to produce a > >> suitable draft. > >> > >> Drafts: > >> - > http://tools.ietf.org/html/draft-ietf-mmusic-sdp-bundle-negotiation > >> - http://tools.ietf.org/html/draft-alvestrand-one-rtp > >> - > http://tools.ietf.org/html/draft-holmberg-mmusic-sdp-mmt-negotiation > >> > >> > >> 2:00 Multiple flow SDP representation [Jennings, Alvestrand] > >> Objective: decide on an architecture for large numbers > >> of similar streams (e.g., multiple video streams). > >> > >> Drafts: > >> - http://tools.ietf.org/html/draft-alvestrand-rtcweb-msid > >> - http://tools.ietf.org/html/draft-alvestrand-mmusic-msid > >> - Do we have a "master" document for the single m-line case? > >> - Multiple m-lines doesn't have a document > >> > >> > >> Day 2 > >> 1:30 Mapping stream/track label concepts SDP identifiers [Alvestrand] > >> Objective: determine requirements > >> > >> > >> 1:30 Trickle ICE open issues [Ivov(?), Uberti, Rescorla] > >> > >> - Starting checks > >> - Termination conditions > >> - Error handling > >> > >> Drafts: > >> http://tools.ietf.org/html/draft-rescorla-mmusic-ice-trickle > >> > >> 1:00 SDP for Datachannels open issues [Jesup, Loreto] > >> Objective: resolve open issues (post WGLC?) > >> > >> Drafts: > >> http://tools.ietf.org/html/draft-ietf-mmusic-sctp-sdp-02 > >> > >> Day 3 > >> 1:00 Other recommended audio codecs [Roach] > >> > >> Objective: identify what other audio codecs we intend to > >> recommend. > >> > >> 1:00 Process WGLC comments on documents [authors] > >> > >> 0:30 Other business > >> > >> 0:30 Wrapup/next steps [Chairs] > >> > >> > >> Best, > >> -Ekr > >> > >> _______________________________________________ > >> rtcweb mailing list > >> rtcweb@ietf.org > >> https://www.ietf.org/mailman/listinfo/rtcweb > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www.ietf.org/mailman/listinfo/mmusic > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > --90e6ba1efbc274a4e504d2529282 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Jan 2, 2013 at 10:18 AM, Cullen Jennings (fluffy) <fluffy@cisco.com= > wrote:

2) the solutions of these problems are likely in to be mostly MMUSIC though= , as Ted has pointed out, some amount of the requirements, architecture and= other discussion can happen in rtcweb.


I actually believe it can go beyond requirements = and architecture; I believe that if RTCWEB can come to a firm understanding= of what solutions are best for its use cases, it can communicate that to M= MUSIC.=A0 That doesn't mean the final decision doesn't rest with MM= USIC--it does--but it does mean that RTCWEB doesn't have to leave the t= echnology discussion completely off the table.=A0 A good analysis can go to= MMUSIC for discussion and potential resolution in/by Orlando.

3) if we are going to have an MMUSIC face to face interim meeting, it would= need AD approval and 4 weeks notices which puts us very close do the deadl= ine so this needs to get sort out real soon.


There is also the option of a virtual interim, wh= ich is (somewhat) less of a logistical issue.

Ted

=A0
Cullen



On Jan 2, 2013, at 8:24 AM, Bernard Aboba <bernard_aboba@hotmail.com> wrote:

> This is a good agenda - for an MMUSIC WG interim (only day 3 has any R= TCWEB items on it).
>
> Since there is a notice requirement, can we get MMUSIC on board so the= interim can actually take place?
>
> On Jan 2, 2013, at 7:13, "Eric Rescorla" <ekr@rtfm.com> wrote:
>
>> Chairs,
>>
>> I've spent some time thinking about the agenda for the interim= , and
>> thought it might be helpful if I sent you a strawman based on the<= br> >> items that are blocking progress in terms of implementation and >> interoperability.
>>
>> Note:
>> I am assuming 4 hours each day. The times have been selected with<= br> >> the objective of giving us enough time to really resolve the
>> open issues. Honestly, we might even add more time for
>> the issues on day 1.
>>
>> Hope this is helpful.
>>
>> Day 1
>> 2:00 =A0 =A0Bundle =A0 [Holmberg]
>> =A0 =A0 =A0Objective: select an approach and work out enough
>> =A0 =A0 =A0details that the editors can work to produce a
>> =A0 =A0 =A0suitable draft.
>>
>> =A0 =A0 =A0Drafts:
>> =A0 =A0 =A0- http://tools.ietf.org/html/dra= ft-ietf-mmusic-sdp-bundle-negotiation
>> =A0 =A0 =A0- http://tools.ietf.org/html/draft-alvestrand-on= e-rtp
>> =A0 =A0 =A0- http://tools.ietf.org/html/dr= aft-holmberg-mmusic-sdp-mmt-negotiation
>>
>>
>> 2:00 =A0 =A0Multiple flow SDP representation [Jennings, Alvestrand= ]
>> =A0 =A0 =A0Objective: decide on an architecture for large numbers<= br> >> =A0 =A0 =A0of similar streams (e.g., multiple video streams).
>>
>> =A0 =A0 =A0Drafts:
>> =A0 =A0 =A0- http://tools.ietf.org/html/draft-alvestran= d-rtcweb-msid
>> =A0 =A0 =A0- http://tools.ietf.org/html/draft-alvestran= d-mmusic-msid
>> =A0 =A0 =A0- Do we have a "master" document for the sing= le m-line case?
>> =A0 =A0 =A0- Multiple m-lines doesn't have a document
>>
>>
>> Day 2
>> 1:30 =A0 =A0Mapping stream/track label concepts SDP identifiers [A= lvestrand]
>> =A0 =A0 =A0Objective: determine requirements
>>
>>
>> 1:30 =A0 =A0Trickle ICE open issues [Ivov(?), Uberti, Rescorla] >>
>> =A0 =A0 =A0- Starting checks
>> =A0 =A0 =A0- Termination conditions
>> =A0 =A0 =A0- Error handling
>>
>> =A0 =A0 =A0Drafts:
>> =A0 =A0 =A0http://tools.ietf.org/html/draft-rescor= la-mmusic-ice-trickle
>>
>> 1:00 =A0 =A0SDP for Datachannels open issues [Jesup, Loreto]
>> =A0 =A0 =A0Objective: resolve open issues (post WGLC?)
>>
>> =A0 =A0 =A0Drafts:
>> =A0 =A0 =A0http://tools.ietf.org/html/draft-ietf-mmusi= c-sctp-sdp-02
>>
>> Day 3
>> 1:00 =A0 =A0Other recommended audio codecs [Roach]
>>
>> =A0 =A0 =A0Objective: identify what other audio codecs we intend t= o
>> =A0 =A0 =A0recommend.
>>
>> 1:00 =A0 =A0Process WGLC comments on documents [authors]
>>
>> 0:30 =A0 =A0Other business
>>
>> 0:30 =A0 =A0Wrapup/next steps [Chairs]
>>
>>
>> Best,
>> -Ekr
>>
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
> <Mail Attachment.txt>_______________________________= ________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic

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

--90e6ba1efbc274a4e504d2529282-- From bernard_aboba@hotmail.com Wed Jan 2 11:44:55 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18F3B21F8599; Wed, 2 Jan 2013 11:44:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.455 X-Spam-Level: X-Spam-Status: No, score=-102.455 tagged_above=-999 required=5 tests=[AWL=0.143, 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 xXpAS1CwqfTv; Wed, 2 Jan 2013 11:44:54 -0800 (PST) Received: from blu0-omc4-s8.blu0.hotmail.com (blu0-omc4-s8.blu0.hotmail.com [65.55.111.147]) by ietfa.amsl.com (Postfix) with ESMTP id 7E35321F8586; Wed, 2 Jan 2013 11:44:54 -0800 (PST) Received: from BLU002-W7 ([65.55.111.136]) by blu0-omc4-s8.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 2 Jan 2013 11:44:53 -0800 X-EIP: [NyO8EK/9r68p5QizMTZGDvctraal+VAi] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_b4c74f88-3437-42e5-bbaf-f211f88f3d32_" From: Bernard Aboba To: "Cullen Jennings (fluffy)" Date: Wed, 2 Jan 2013 11:44:53 -0800 Importance: Normal In-Reply-To: References: , , MIME-Version: 1.0 X-OriginalArrivalTime: 02 Jan 2013 19:44:53.0584 (UTC) FILETIME=[A2A9C500:01CDE921] Cc: "rtcweb@ietf.org" , "mmusic@ietf.org" Subject: Re: [rtcweb] [MMUSIC] Proposed Agenda for Interim X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 02 Jan 2013 19:44:55 -0000 --_b4c74f88-3437-42e5-bbaf-f211f88f3d32_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Cullen said: "3) if we are going to have an MMUSIC face to face interim meeting=2C it wo= uld need AD approval and 4 weeks notices which puts us very close do the de= adline so this needs to get sort out real soon. " [BA] I see no particularly good reason why this can't happen quickly. In = fact=2C why not schedule two MMUSIC interims=2C 4-6 weeks apart from each o= ther? If travel is an issue=2C they can be virtual. EKR's=0A= issue list is a fine starting point=2C and there is an informal IESG =0A= telechat tomorrow (3-Jan) as well as one on 10-Jan-2013. =20 Ted's suggestion (to cover this in the RTCWEB interim) might do in a pinch= =2C but really=2C MMUSIC WG has to develop a sense of urgency on this. If = things keep going as they have=2C by the time we get published RFCs out of = MMUSIC=2C implementations will have been in the field for years. =20 If MMUSIC were a Hollywood Celebrity=2C we'd be *way* past the time for "to= ugh love" and on the front page of the National Enquirer for the Nth time.= =20 = --_b4c74f88-3437-42e5-bbaf-f211f88f3d32_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Cullen said:

"3) if we ar= e going to have an MMUSIC face to face interim meeting=2C it would need AD = approval and 4 weeks notices which puts us very close do the deadline so th= is needs to get sort out real soon. "

[BA] I see no particularl= y good reason why this can't =3B happen quickly. =3B In fact=2C why= not schedule two MMUSIC interims=2C 4-6 weeks apart from each other? = =3B If travel is an issue=2C they can be virtual. =3B EKR's=0A= issue list is a fine starting point=2C and there is an informal IESG =0A= telechat tomorrow (3-Jan) as well as one on 10-Jan-2013. =3B

Te= d's suggestion (to cover this in the RTCWEB interim) might do in a pinch=2C= but really=2C MMUSIC WG has to develop a sense of urgency on this. =3B= If things keep going as they have=2C by the time we get published RFCs out= of MMUSIC=2C =3B implementations will have been in the field for years= . =3B

If MMUSIC were a Hollywood Celebrity=2C we'd be *way* pas= t the time for "tough love" and on the front page of the National Enquirer = for the Nth time.



= --_b4c74f88-3437-42e5-bbaf-f211f88f3d32_-- From ekr@rtfm.com Wed Jan 2 14:26:13 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7BC521F86D2 for ; Wed, 2 Jan 2013 14:26:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.867 X-Spam-Level: X-Spam-Status: No, score=-102.867 tagged_above=-999 required=5 tests=[AWL=0.109, 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 l5x2TPhc+nF0 for ; Wed, 2 Jan 2013 14:26:13 -0800 (PST) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id E90AA21F867E for ; Wed, 2 Jan 2013 14:26:12 -0800 (PST) Received: by mail-ob0-f172.google.com with SMTP id za17so13347057obc.3 for ; Wed, 02 Jan 2013 14:26:12 -0800 (PST) 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=REwDfsEi54hEVPDRga3PPXIyCZ5fHORLFfFRPcNdGpA=; b=fzspHhsblyTkdoQLbegJX/pZgI+q2B41ZYSABgZ5z8UVsfc7xGAmzC3V16EmVWvJZi d4djCUZjn0AEnOIeQbrqAT+Lrvmnv2AcMFHN87yVljkZn7wK6aWJAYzs8FT3puqbacl8 jTkwu4HytWoX9pVY87DQst01CYi3F2aveqLVLnL44gt12Jv6IVtaRSujYv8wUfj1l57s 5Z35IJBHz6Ll2BQ6VnS1sogQEQCCz6N1dFsyMrQxZqhH3d2/Y8BVomPi7Du0WOYBsN9o f45j8Zzd2V5AWj6+93yOXhQYViPsJshm+cRaDrGtezWhUCacwjr1QO0efuxG12Wani+D Ah/w== Received: by 10.182.164.103 with SMTP id yp7mr38041024obb.74.1357165572474; Wed, 02 Jan 2013 14:26:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.77.225 with HTTP; Wed, 2 Jan 2013 14:25:32 -0800 (PST) X-Originating-IP: [74.95.2.173] In-Reply-To: References: From: Eric Rescorla Date: Wed, 2 Jan 2013 14:25:32 -0800 Message-ID: To: Bernard Aboba Content-Type: multipart/alternative; boundary=e89a8f643556d946dd04d255bb0a X-Gm-Message-State: ALoCoQkRCvub1n+dnzuQKPB4eN4+viOM/YpRmAoIKbZelMYHA55fGDsLIgerqVuHtHT3lgNsi7UC Cc: "Cullen Jennings \(fluffy\)" , "rtcweb@ietf.org" , "mmusic@ietf.org" Subject: Re: [rtcweb] [MMUSIC] Proposed Agenda for Interim X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 02 Jan 2013 22:26:13 -0000 --e89a8f643556d946dd04d255bb0a Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jan 2, 2013 at 11:44 AM, Bernard Aboba wrote: > Cullen said: > > "3) if we are going to have an MMUSIC face to face interim meeting, it > would need AD approval and 4 weeks notices which puts us very close do the > deadline so this needs to get sort out real soon. " > > [BA] I see no particularly good reason why this can't happen quickly. In > fact, why not schedule two MMUSIC interims, 4-6 weeks apart from each > other? If travel is an issue, they can be virtual. EKR's issue list is a > fine starting point, and there is an informal IESG telechat tomorrow > (3-Jan) as well as one on 10-Jan-2013. > I'm not in principle opposed to "virtual" interims, but my general feeling is that we should be using face-to-face time to cover the most important and intractable issues. ISTM that those are the ones that I listed in my email. Accordingly, I don't think it makes sense to have virtual MMUSIC interims to discuss the important stuff and a F2F RTCWEB interim to discuss the rest... -Ekr Ted's suggestion (to cover this in the RTCWEB interim) might do in a pinch, > but really, MMUSIC WG has to develop a sense of urgency on this. If things > keep going as they have, by the time we get published RFCs out of MMUSIC, > implementations will have been in the field for years. > > If MMUSIC were a Hollywood Celebrity, we'd be *way* past the time for > "tough love" and on the front page of the National Enquirer for the Nth > time. > > > > --e89a8f643556d946dd04d255bb0a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, Jan 2, 2013 at 11:44 AM, Bernard= Aboba <bernard_aboba@hotmail.com> wrote:
Cullen said:

"3) if we = are going to have an MMUSIC face to face interim meeting, it would need AD = approval and 4 weeks notices which puts us very close do the deadline so th= is needs to get sort out real soon. "

[BA] I see no particularly good reason why this can't=A0= happen quickly.=A0 In fact, why not schedule two MMUSIC interims, 4-6 week= s apart from each other?=A0 If travel is an issue, they can be virtual.=A0 = EKR's issue list is a fine starting point, and there is an informal IESG=20 telechat tomorrow (3-Jan) as well as one on 10-Jan-2013.=A0
=

I'm not in principle opposed to = "virtual" interims, but my general feeling is
that we s= hould be using face-to-face time to cover the most important and
intractable issues. ISTM that those are the ones that I listed in my e= mail.

Accordingly, I don't think it makes sens= e to have virtual MMUSIC interims
to discuss the important stuff = and a F2F RTCWEB interim to discuss the
rest...

-Ekr


Ted's sugg= estion (to cover this in the RTCWEB interim) might do in a pinch, but reall= y, MMUSIC WG has to develop a sense of urgency on this.=A0 If things keep g= oing as they have, by the time we get published RFCs out of MMUSIC,=A0 impl= ementations will have been in the field for years.=A0

If MMUSIC were a Hollywood Celebrity, we'd be *way* past the time f= or "tough love" and on the front page of the National Enquirer fo= r the Nth time.




--e89a8f643556d946dd04d255bb0a-- From stefan.lk.hakansson@ericsson.com Wed Jan 2 15:50:12 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50F9A21F843F for ; Wed, 2 Jan 2013 15:50:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, 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 Qny8w1zSo+7Q for ; Wed, 2 Jan 2013 15:50:11 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id D4D5B21F843E for ; Wed, 2 Jan 2013 15:50:10 -0800 (PST) X-AuditID: c1b4fb30-b7f736d0000010de-df-50e4c7b1806a Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 69.F3.04318.1B7C4E05; Thu, 3 Jan 2013 00:50:09 +0100 (CET) Received: from [153.88.49.5] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.279.1; Thu, 3 Jan 2013 00:50:00 +0100 Message-ID: <50E4C7A7.4000400@ericsson.com> Date: Thu, 3 Jan 2013 00:49:59 +0100 From: =?ISO-8859-1?Q?Stefan_H=E5kansson_LK?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Ted Hardie References: <7594FB04B1934943A5C02806D1A2204B06E211@ESESSMB209.ericsson.se> <50E46B45.6080100@ericsson.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphluLIzCtJLcpLzFFi42KZGfG3Rnfj8ScBBq+Py1qs/dfObtE4186B yWPnrLvsHkuW/GQKYIrisklJzcksSy3St0vgyvj0uJGpoJ2/4k7jX7YGxv3cXYycHBICJhLv 1vxngbDFJC7cW8/WxcjFISRwklFib/9yJghnBaPExZvXgKo4OHgFtCXWTmMFaWARUJE4cHUn M4jNJhAocf3/LyYQW1QgROL690eMIDavgKDEyZlPwBaICChL7L2ygw3EZhYQlthwsQ0sLizg KPHn+gKoXfcYJWY++g5WxAk0tG/6CUaIBluJC3Ous0DY8hLNW2eDLRYS0JV49/oe6wRGwVlI 9s1C0jILScsCRuZVjOy5iZk56eXmmxiBIXlwy2+DHYyb7osdYpTmYFES5w13vRAgJJCeWJKa nZpakFoUX1Sak1p8iJGJg1OqgTG8U17wVMR1xW09et82sEzWj2bMPCUSLniq+uW5qauU9pXJ Kv240Lby0C39P5Vmy+aX2L1cOlXrWVXd61drVphqrjm9/ee34wdDgk/vMlqcJj3v5ufG53Ka B+Nf1T09YjbzYZxPmeBS62u5N3nKb7x42Dv1iVkv87HX5w2b/R5u+76V79mFv0LFSizFGYmG WsxFxYkAJtTR5RcCAAA= Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Support of video with different resolutions X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 02 Jan 2013 23:50:12 -0000 On 2013-01-02 19:32, Ted Hardie wrote: > On Wed, Jan 2, 2013 at 9:15 AM, Stefan Hĺkansson LK > > wrote: > > > Another way to look at this is that we already have the following > requirement: > > "F11 The browser MUST be able to transmit streams and > data to several peers concurrently.", > > and presumably there would be independent rate control for these > streams (since they may experience different network conditions), > > simulcast is in sense just a special case (the two other peer's are > the same endpoint). > > > While I agree that you could model it this way, I think it may be more > appropriate to treat simulcast as its own case, rather than as a special > case of the multiple peer. I agree fully. I was just trying to say that we already have requirements covering a large part of what is needed for simulcast, so simulcast would not require much more in terms of implementation than what we already have agreement on. But it should be its own case. Apart from the point you make about rate control, there is also a tighter requirement on synchronization between two versions of the same stream in a simulcast case than what would (likely) be needed in a multiple peer case. > > Consider this pair of scenarios: > > Case one: > There is one endpoint, Zelda, which is sending media via Turn service to > two hosts behind the same NAT (let's call them Scott and Edouard). > There is independent rate control for the streams sending this media. > > Case two: > There is an endpoint, Zelda, which is sending simulcast media to Scott, > which is using a Turn service and is behind a NAT. > > Isn't managing fairness going to be potentially very different between > case one and case two? > > regards, > > Ted From prvs=571579afea=aallen@rim.com Thu Jan 3 09:25:08 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC2EC21F8A71 for ; Thu, 3 Jan 2013 09:25:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.181 X-Spam-Level: X-Spam-Status: No, score=-2.181 tagged_above=-999 required=5 tests=[MIME_QP_LONG_LINE=1.819, 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 qzubGrgaVe31 for ; Thu, 3 Jan 2013 09:25:07 -0800 (PST) Received: from mhs061cnc.rim.net (mhs061cnc.rim.net [208.65.73.35]) by ietfa.amsl.com (Postfix) with ESMTP id A428921F8652 for ; Thu, 3 Jan 2013 09:25:04 -0800 (PST) X-AuditID: 0a412830-b7f646d0000038d1-88-50e5bee4de2d Received: from XCT101ADS.rim.net (xct101ads.rim.net [10.67.111.42]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by mhs061cnc.rim.net (SBG) with SMTP id 30.ED.14545.5EEB5E05; Thu, 3 Jan 2013 11:24:53 -0600 (CST) Received: from XMB104ADS.rim.net ([fe80::2494:a63d:e3:723b]) by XCT101ADS.rim.net ([fe80::2c7e:1215:d554:35b5%20]) with mapi id 14.02.0318.001; Thu, 3 Jan 2013 11:24:52 -0600 From: Andrew Allen To: Harald Alvestrand , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Call for Consensus Regarding Selecting Recommended Audio Codecs Thread-Index: AQHN5E/V+IaWIiAHjEiWJfuSRtT+RJg34eLQ Date: Thu, 3 Jan 2013 17:24:51 +0000 Message-ID: References: <50D2CC6A.4090500@ericsson.com> <50DC7830.1010206@alvestrand.no> In-Reply-To: <50DC7830.1010206@alvestrand.no> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.67.110.251] Content-Type: text/plain; charset="iso-8859-1" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrMKsWRmVeSWpSXmKPExsXC5Zyvpft039MAg29feC2O9XWxWaz9187u wORxZcIVVo8lS34yBTBFNTDaJCWWlAVnpufp29kk5uXllySWpCqkpBYn2yr5pKYn5igEFGWW JSZXKrhkFifnJGbmphYpKWSm2CqZKCkU5CQmp+am5pXYKiUWFKTmpSjZcSlgABugssw8hdS8 5PyUzLx0WyXPYH9dCwtTS11DJTvdhE6ejGuLt7MUPJWouNO6kamBca5IFyMnh4SAicTWp69Z IWwxiQv31rN1MXJxCAm0MUlsWdQElhAS2MQoMemZMYjNJqAssfz3DEYQW0QgWKL3+XswW1gg XKK3sw0qHiGx6skLIJsDyDaS+LCCDyTMIqAi8XZlEwuIzSvgIbF+4SZ2iPE+Ejfb3rKClHMK 6EosuSgMEmYUkJXYffY6E4jNLCAucevJfCaIMwUkluw5zwxhi0q8fPwP6nxFiRl75rNC1OtJ 3Jg6hQ3C1pZYtvA1M8RaQYmTM5+wTGAUnYVk7CwkLbOQtMxC0rKAkWUVo2BuRrGBmWFyXrJe UWauXl5qySZGUCpw1DDYwfj+vcUhRgEORiUe3tWLngYIsSaWFVfmHmKU4GBWEuHlXAEU4k1J rKxKLcqPLyrNSS0+xOgKDJSJzFLcyfnANJVXEm9sYICboyTOK9l7OUBIIB2YeLJTUwtSi2Dm MHFwguzhkhIpBqaP1KLE0pKMeFCSiy8GpjmpBsa8S5xrpHynhDafCJfO4b7EmN1jI8AZleBf 3eNfvr2Qa2avee4ticuW+3q2JnaeSwjnsowUd/z0WVbqy+apDP+Yl3NM/9mn0W205taam4kC fu2Leb69bpux7LnN3rIjEmIxfDv85k+IuWxU/WGH6Qa/nI9lS1/7lleY3oqMnL76UeVt43m/ JJRYijMSDbWYi4oTAVM4nO9GAwAA Subject: Re: [rtcweb] Call for Consensus Regarding Selecting Recommended 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, 03 Jan 2013 17:25:08 -0000 I also support 2) I really don't think it helps much to describe what other codecs are out the= re that you might want to think about implementing if you want to interopera= te with certain other non RTCweb deployments. I think anybody who is serious= ly thinking about developing such a product can easily find this out for the= mselves - if you want to interoperate with 3GPP devices then take a look at= the CURRENT 3GPP Codec specifications! It should be realized that the codec life cycle tends to be somewhat shorter= than that of the signaling technology so the codec information is likely to= become out of date long before the signaling specifications become obsolete= (possibly already dated by the time the RFC is published) - 3GPP is already= working on a new codec for LTE! As everyone has a favorite codec they would like to see deployed the downsid= e of this is that this will likely become a distraction that generates a lot= of discussion and consumes a lot of cycles that would be better spent on ad= dressing the basic interoperability issues facing RTCweb. So I think the MTI audio codecs already agreed is enough to ensure interoper= ability. Andrew -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= Harald Alvestrand Sent: Thursday, December 27, 2012 11:33 AM To: rtcweb@ietf.org Subject: Re: [rtcweb] Call for Consensus Regarding Selecting Recommended Aud= io Codecs Speaking as an individual: I am putting my name on 2), because I believe RECOMMENDED is too strong for= secondary codecs. On 12/20/2012 09:29 AM, Magnus Westerlund wrote: > WG, > > As an outcome of the Vancouver IETF meeting codec discussions we did > promise to run a call for consensus regarding if the WG was interested > in specifying a small set of recommended audio codecs. We are sorry > this has been delayed until now. > > The question for the call of consensus is between two options. > > 1) Run a process in the WG to select and specify a small set of > audio/speech codecs that would be RECOMMNEDED to implement by a WebRTC > end-points > > 2) Do nothing and let the already specified Mandatory to Implement > Audio codecs be the only audio codecs mentioned in the WebRTC specificatio= n. > > Please indicate your position by January 16th 2013. > > Regards > > Magnus Westerlund > > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > _______________________________________________ > 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 --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From fandreas@cisco.com Thu Jan 3 18:03:53 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4099421F8D59; Thu, 3 Jan 2013 18:03:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.889 X-Spam-Level: X-Spam-Status: No, score=-7.889 tagged_above=-999 required=5 tests=[AWL=2.709, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 gGzc9zQ9VNWV; Thu, 3 Jan 2013 18:03:52 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 5E01D21F8D74; Thu, 3 Jan 2013 18:03:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5071; q=dns/txt; s=iport; t=1357265032; x=1358474632; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=qVSRLUGGndTkzfigXqbFS/Hh7ijRMs+pJh0mGaPkfeU=; b=FQ+C0Tpedurwmr+epotNy5DivhBeredBLO3pHTfVwVJNroMXNtX6S4hV yge6oNiGFvvcCsNP+ILTM8mJGAgKJddObtqvJpEaOSBWUZ2YLJ3yN1/Sr vGHpG92ahmeCVRi413cDKm1EOMiptf2emzrMI9BwAjECvyUisHVUy9z3X E=; X-IronPort-AV: E=Sophos;i="4.84,406,1355097600"; d="scan'208,217";a="158711080" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-7.cisco.com with ESMTP; 04 Jan 2013 02:03:52 +0000 Received: from rtp-fandreas-8719.cisco.com (rtp-fandreas-8719.cisco.com [10.117.7.90]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r0423pPf001653; Fri, 4 Jan 2013 02:03:51 GMT Message-ID: <50E63886.3020406@cisco.com> Date: Thu, 03 Jan 2013 21:03:50 -0500 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Bernard Aboba References: , , In-Reply-To: Content-Type: multipart/alternative; boundary="------------040806000000070002020905" Cc: "Cullen Jennings \(fluffy\)" , "rtcweb@ietf.org" , "mmusic@ietf.org" Subject: Re: [rtcweb] [MMUSIC] Proposed Agenda for Interim X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 04 Jan 2013 02:03:53 -0000 This is a multi-part message in MIME format. --------------040806000000070002020905 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 1/2/13 2:44 PM, Bernard Aboba wrote: > Cullen said: > > "3) if we are going to have an MMUSIC face to face interim meeting, it > would need AD approval and 4 weeks notices which puts us very close do > the deadline so this needs to get sort out real soon. " > > [BA] I see no particularly good reason why this can't happen > quickly. In fact, why not schedule two MMUSIC interims, 4-6 weeks > apart from each other? If travel is an issue, they can be virtual. > EKR's issue list is a fine starting point, and there is an informal > IESG telechat tomorrow (3-Jan) as well as one on 10-Jan-2013. > > Ted's suggestion (to cover this in the RTCWEB interim) might do in a > pinch, but really, MMUSIC WG has to develop a sense of urgency on > this. If things keep going as they have, by the time we get published > RFCs out of MMUSIC, implementations will have been in the field for > years. > The MMUSIC WG is driven by the contributions, discussions, and ultimately rough consensus of its participants, just like any other WG. The active participants on the topics of interest here seem to be largely the same in the two groups, so I'm not sure exactly what you are looking for or proposing here, but constructive suggestions are always welcome. Thanks -- Flemming (MMUSIC co-chair) > If MMUSIC were a Hollywood Celebrity, we'd be *way* past the time for > "tough love" and on the front page of the National Enquirer for the > Nth time. > > > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic --------------040806000000070002020905 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 1/2/13 2:44 PM, Bernard Aboba wrote:
Cullen said:

"3) if we are going to have an MMUSIC face to face interim meeting, it would need AD approval and 4 weeks notices which puts us very close do the deadline so this needs to get sort out real soon. "

[BA] I see no particularly good reason why this can't  happen quickly.  In fact, why not schedule two MMUSIC interims, 4-6 weeks apart from each other?  If travel is an issue, they can be virtual.  EKR's issue list is a fine starting point, and there is an informal IESG telechat tomorrow (3-Jan) as well as one on 10-Jan-2013. 

Ted's suggestion (to cover this in the RTCWEB interim) might do in a pinch, but really, MMUSIC WG has to develop a sense of urgency on this.  If things keep going as they have, by the time we get published RFCs out of MMUSIC,  implementations will have been in the field for years. 

The MMUSIC WG is driven by the contributions, discussions, and ultimately rough consensus of its participants, just like any other WG. The active participants on the topics of interest here seem to be largely the same in the two groups, so I'm not sure exactly what you are looking for or proposing here, but constructive suggestions are always welcome.

Thanks

-- Flemming (MMUSIC co-chair)


If MMUSIC were a Hollywood Celebrity, we'd be *way* past the time for "tough love" and on the front page of the National Enquirer for the Nth time. 





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

--------------040806000000070002020905-- From fandreas@cisco.com Thu Jan 3 18:51:11 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC70D21F8E57; Thu, 3 Jan 2013 18:51:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.792 X-Spam-Level: X-Spam-Status: No, score=-8.792 tagged_above=-999 required=5 tests=[AWL=1.806, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 WenhmECbAJxK; Thu, 3 Jan 2013 18:51:09 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id A29E321F8E07; Thu, 3 Jan 2013 18:51:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8311; q=dns/txt; s=iport; t=1357267869; x=1358477469; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=GeDz2+H6qbuFV3nFNdvSwXknIvOAV0Y1/XUZmx/kUio=; b=FyauE838ovbu03WN88JoHxfZccuuEHY7Y+PD2AROu+mi5i17sOIVx/br 72tD/UHkVRFdO87+NwKIUnXht16MJYSWZ7DcInxa8nk3vZYygeO4wIGhb v99gjERweOi1ikWoq7zfpWqz7unfaco9RD8e7lFiIXkNWVayeJSJWuqKV s=; X-IronPort-AV: E=Sophos;i="4.84,406,1355097600"; d="scan'208,217";a="158506525" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-1.cisco.com with ESMTP; 04 Jan 2013 02:51:09 +0000 Received: from rtp-fandreas-8719.cisco.com (rtp-fandreas-8719.cisco.com [10.117.7.90]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r042p8Gs001720; Fri, 4 Jan 2013 02:51:08 GMT Message-ID: <50E6439B.1050901@cisco.com> Date: Thu, 03 Jan 2013 21:51:07 -0500 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Eric Rescorla References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------020306090106000302040102" Cc: "Cullen Jennings \(fluffy\)" , "rtcweb@ietf.org" , "mmusic@ietf.org" Subject: Re: [rtcweb] [MMUSIC] Proposed Agenda for Interim X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 04 Jan 2013 02:51:11 -0000 This is a multi-part message in MIME format. --------------020306090106000302040102 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 1/2/13 5:25 PM, Eric Rescorla wrote: > > > On Wed, Jan 2, 2013 at 11:44 AM, Bernard Aboba > > wrote: > > Cullen said: > > "3) if we are going to have an MMUSIC face to face interim > meeting, it would need AD approval and 4 weeks notices which puts > us very close do the deadline so this needs to get sort out real > soon. " > > [BA] I see no particularly good reason why this can't happen > quickly. In fact, why not schedule two MMUSIC interims, 4-6 weeks > apart from each other? If travel is an issue, they can be > virtual. EKR's issue list is a fine starting point, and there is > an informal IESG telechat tomorrow (3-Jan) as well as one on > 10-Jan-2013. > > > I'm not in principle opposed to "virtual" interims, but my general > feeling is > that we should be using face-to-face time to cover the most important and > intractable issues. ISTM that those are the ones that I listed in my > email. > > Accordingly, I don't think it makes sense to have virtual MMUSIC interims > to discuss the important stuff and a F2F RTCWEB interim to discuss the > rest... > While I agree it would be helpful with more face-to-face time, I don't believe in relying on this as a mechanism for making continuous progress. These types of meetings are generally most productive when coupled with regular interaction among a core set of people that represent the different points of view in a particular matter and hence I would suggest formation of one or more design teams on select topics with regular conference calls (we'll need dedicated volunteers for those) - of course the output of these design teams will still need to be discussed in the WG at large. One particular area to start with on the bundle/mmt discussion for example is to look at how the different proposals handle all existing SDP parameters and attributes to see how important their different approach really is. Thanks -- Flemming (as Individual) > -Ekr > > > Ted's suggestion (to cover this in the RTCWEB interim) might do in > a pinch, but really, MMUSIC WG has to develop a sense of urgency > on this. If things keep going as they have, by the time we get > published RFCs out of MMUSIC, implementations will have been in > the field for years. > > If MMUSIC were a Hollywood Celebrity, we'd be *way* past the time > for "tough love" and on the front page of the National Enquirer > for the Nth time. > > > > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic --------------020306090106000302040102 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 1/2/13 5:25 PM, Eric Rescorla wrote:


On Wed, Jan 2, 2013 at 11:44 AM, Bernard Aboba <bernard_aboba@hotmail.com> wrote:
Cullen said:

"3) if we are going to have an MMUSIC face to face interim meeting, it would need AD approval and 4 weeks notices which puts us very close do the deadline so this needs to get sort out real soon. "

[BA] I see no particularly good reason why this can't  happen quickly.  In fact, why not schedule two MMUSIC interims, 4-6 weeks apart from each other?  If travel is an issue, they can be virtual.  EKR's issue list is a fine starting point, and there is an informal IESG telechat tomorrow (3-Jan) as well as one on 10-Jan-2013. 

I'm not in principle opposed to "virtual" interims, but my general feeling is
that we should be using face-to-face time to cover the most important and
intractable issues. ISTM that those are the ones that I listed in my email.

Accordingly, I don't think it makes sense to have virtual MMUSIC interims
to discuss the important stuff and a F2F RTCWEB interim to discuss the
rest...

While I agree it would be helpful with more face-to-face time, I don't believe in relying on this as a mechanism for making continuous progress. These types of meetings are generally most productive when coupled with regular interaction among a core set of people that represent the different points of view in a particular matter and hence I would suggest formation of one or more design teams on select topics with regular conference calls (we'll need dedicated volunteers for those) - of course the output of these design teams will still need to be discussed in the WG at large.

One particular area to start with on the bundle/mmt discussion for example is to look at how the different proposals handle all existing SDP parameters and attributes to see how important their different approach really is.

Thanks

-- Flemming (as Individual)

-Ekr


Ted's suggestion (to cover this in the RTCWEB interim) might do in a pinch, but really, MMUSIC WG has to develop a sense of urgency on this.  If things keep going as they have, by the time we get published RFCs out of MMUSIC,  implementations will have been in the field for years. 

If MMUSIC were a Hollywood Celebrity, we'd be *way* past the time for "tough love" and on the front page of the National Enquirer for the Nth time. 






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

--------------020306090106000302040102-- From ibc@aliax.net Fri Jan 4 02:24:57 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A894E21F8EA7 for ; Fri, 4 Jan 2013 02:24:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.077 X-Spam-Level: X-Spam-Status: No, score=-2.077 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_55=0.6, MIME_8BIT_HEADER=0.3, 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 1E3nxMkAKGbs for ; Fri, 4 Jan 2013 02:24:57 -0800 (PST) Received: from mail-qc0-f170.google.com (mail-qc0-f170.google.com [209.85.216.170]) by ietfa.amsl.com (Postfix) with ESMTP id 2C84521F8E23 for ; Fri, 4 Jan 2013 02:24:56 -0800 (PST) Received: by mail-qc0-f170.google.com with SMTP id d42so8702570qca.1 for ; Fri, 04 Jan 2013 02:24:56 -0800 (PST) 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=T1ecNeS7alKPKmZ3y5CjfGqj8eCPYWxtXOvVREuP7Mo=; b=okM9BxrPACR3YO2lhRsh3678XCBKnZs3A0u88p3vjUTFTOjZ5RG8+LETk6Ve8P6w72 6sYARpu+GUqCSWJOeA95N/TijCBHqLY3QxpGNbzKLRyDUM39yxeFv9wngBI9HPnaDMJe BFAR9eGSBySzjPboGwtg9196Em8WezZTItsF+vU4C3vXgOPMSN5fZrAzqqrNQmulgMrf QDz07uCKFqRW9DJgKKP1N7ciOZSAbvNqn3j/pS4eb8wzjZ1w8mUXSzIVXMdT9vG8q/O+ cPS3KSVfTXxuyJF3jx30fkAQCqtiM7AsOT29Gut0RIY9npV2K5dvcmgC2RrkKgNeV+wF vG9Q== Received: by 10.49.71.178 with SMTP id w18mr36783371qeu.11.1357295096447; Fri, 04 Jan 2013 02:24:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.49.94.193 with HTTP; Fri, 4 Jan 2013 02:24:36 -0800 (PST) From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Fri, 4 Jan 2013 11:24:36 +0100 Message-ID: To: rtcweb@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkMfJb/a0gOcUzQP7xYuhcg9LnfRMxpbDG9b1f5zZRoEfe6gqwuq6E3S22sY5e3rrElIbNI Subject: [rtcweb] Inspect a received SDP *before* using it X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 04 Jan 2013 10:24:57 -0000 Hi, the WebRTC JavaScript API does not define a mechanism for parsing/inspecting a received SDP (a string), so there are two "solutions": 1) Manually parse de SDP at JS level, which is ugly taking into account that the browser includes a tested SDP parser. 2) Call to RTCPeerconnection.setRemoteDescription(RECEIVED_SDP), which means that the media stream begins. The point here is to know what the remote peer is offering to us (audio? audio+video?) before calling to getUserMedia(), so we (the web application) can tell the user about which kind of media session the remote peer is offering to him. Do I miss something? As said above the specs don't seem to provide this funcionality at JS API. Thanks a lot. --=20 I=C3=B1aki Baz Castillo From andrew.hutton@siemens-enterprise.com Fri Jan 4 02:48:36 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E62F721F8EE7 for ; Fri, 4 Jan 2013 02:48:36 -0800 (PST) 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 Sx2THA16C9R9 for ; Fri, 4 Jan 2013 02:48:32 -0800 (PST) Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 838B521F8EDE for ; Fri, 4 Jan 2013 02:48:32 -0800 (PST) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id C75041EB8519; Fri, 4 Jan 2013 11:48:30 +0100 (CET) Received: from MCHP04MSX.global-ad.net ([169.254.1.13]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.02.0318.001; Fri, 4 Jan 2013 11:48:30 +0100 From: "Hutton, Andrew" To: Andrew Allen , Harald Alvestrand , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Call for Consensus Regarding Selecting Recommended Audio Codecs Thread-Index: AQHN6mkI830GitSbMUylOQqXGrZCbQ== Date: Fri, 4 Jan 2013 10:47:59 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF013A1025@MCHP04MSX.global-ad.net> References: <50D2CC6A.4090500@ericsson.com> <50DC7830.1010206@alvestrand.no> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [rtcweb] Call for Consensus Regarding Selecting Recommended 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, 04 Jan 2013 10:48:37 -0000 I previously indicate support for 1) but I note the arguments put forward b= y Adam Roach and agree that normative recommendations for additional codec'= s are not necessary here. However I think it would be helpful to have some non normative text describ= ing how the implementation of particular codec's would improve interoperabi= lity in specific environments (E.g. mobile) and although this could be left= to browser vendors to work out for themselves I don't think that is a good= argument for not doing it. We are here to promote interoperability after a= ll. I also disagree that the MTI codec's already agreed are sufficient to ensur= e interoperability with non RTCWEB environments which according to the rtcw= eb charter should be considered. Regards Andy > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > Behalf Of Andrew Allen > Sent: 03 January 2013 17:25 > To: Harald Alvestrand; rtcweb@ietf.org > Subject: Re: [rtcweb] Call for Consensus Regarding Selecting > Recommended Audio Codecs >=20 > I also support 2) >=20 > I really don't think it helps much to describe what other codecs are > out there that you might want to think about implementing if you want > to interoperate with certain other non RTCweb deployments. I think > anybody who is seriously thinking about developing such a product can > easily find this out for themselves - if you want to interoperate with > 3GPP devices then take a look at the CURRENT 3GPP Codec specifications! >=20 > It should be realized that the codec life cycle tends to be somewhat > shorter than that of the signaling technology so the codec information > is likely to become out of date long before the signaling > specifications become obsolete (possibly already dated by the time the > RFC is published) - 3GPP is already working on a new codec for LTE! >=20 > As everyone has a favorite codec they would like to see deployed the > downside of this is that this will likely become a distraction that > generates a lot of discussion and consumes a lot of cycles that would > be better spent on addressing the basic interoperability issues facing > RTCweb. >=20 > So I think the MTI audio codecs already agreed is enough to ensure > interoperability. >=20 > Andrew >=20 > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > Behalf Of Harald Alvestrand > Sent: Thursday, December 27, 2012 11:33 AM > To: rtcweb@ietf.org > Subject: Re: [rtcweb] Call for Consensus Regarding Selecting > Recommended Audio Codecs >=20 > Speaking as an individual: >=20 > I am putting my name on 2), because I believe RECOMMENDED is too strong > for secondary codecs. >=20 > On 12/20/2012 09:29 AM, Magnus Westerlund wrote: > > WG, > > > > As an outcome of the Vancouver IETF meeting codec discussions we did > > promise to run a call for consensus regarding if the WG was > interested > > in specifying a small set of recommended audio codecs. We are sorry > > this has been delayed until now. > > > > The question for the call of consensus is between two options. > > > > 1) Run a process in the WG to select and specify a small set of > > audio/speech codecs that would be RECOMMNEDED to implement by a > WebRTC > > end-points > > > > 2) Do nothing and let the already specified Mandatory to Implement > > Audio codecs be the only audio codecs mentioned in the WebRTC > specification. > > > > Please indicate your position by January 16th 2013. > > > > Regards > > > > Magnus Westerlund > > > > --------------------------------------------------------------------- > - > > Multimedia Technologies, Ericsson Research EAB/TVM > > --------------------------------------------------------------------- > - > > Ericsson AB | Phone +46 10 7148287 > > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > > --------------------------------------------------------------------- > - > > > > _______________________________________________ > > 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 >=20 > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential > information, privileged material (including material protected by the > solicitor-client or other applicable privileges), or constitute non- > public information. Any use of this information by anyone other than > the intended recipient is prohibited. If you have received this > transmission in error, please immediately reply to the sender and > delete this information from your system. Use, dissemination, > distribution, or reproduction of this transmission by unintended > recipients is not authorized and may be unlawful. > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From harald@alvestrand.no Fri Jan 4 02:53:38 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9747421F8EFA for ; Fri, 4 Jan 2013 02:53:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.999 X-Spam-Level: X-Spam-Status: No, score=-109.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_55=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 4f-03ZvtIQqi for ; Fri, 4 Jan 2013 02:53:37 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 7E3A521F8EFB for ; Fri, 4 Jan 2013 02:53:37 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1687A39E13F for ; Fri, 4 Jan 2013 11:53:35 +0100 (CET) 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 W2KrCyF96LKj for ; Fri, 4 Jan 2013 11:53:34 +0100 (CET) Received: from [IPv6:2001:470:de0a:27:4134:bf42:7a46:3571] (unknown [IPv6:2001:470:de0a:27:4134:bf42:7a46:3571]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 1DC7E39E0A7 for ; Fri, 4 Jan 2013 11:53:34 +0100 (CET) Message-ID: <50E6B4AD.6080309@alvestrand.no> Date: Fri, 04 Jan 2013 11:53:33 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [rtcweb] Inspect a received SDP *before* using it X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 04 Jan 2013 10:53:38 -0000 Since this is strictly an API issue, I believe it belongs on the public-webrtc@w3.org list. On 01/04/2013 11:24 AM, Iñaki Baz Castillo wrote: > Hi, the WebRTC JavaScript API does not define a mechanism for > parsing/inspecting a received SDP (a string), so there are two > "solutions": > > > 1) Manually parse de SDP at JS level, which is ugly taking into > account that the browser includes a tested SDP parser. > > 2) Call to RTCPeerconnection.setRemoteDescription(RECEIVED_SDP), which > means that the media stream begins. > > > The point here is to know what the remote peer is offering to us > (audio? audio+video?) before calling to getUserMedia(), so we (the web > application) can tell the user about which kind of media session the > remote peer is offering to him. This relationship is of course highly application dependent. It's also likely that you will want to call setRemoteDescription before calling getUserMedia, so that if setRemoteDescription fails, you won't bother to call getUserMedia at all. Again, app dependent. > > > Do I miss something? As said above the specs don't seem to provide > this funcionality at JS API. They don't. This has been mostly deemed not strictly necessary for version 1, and experience will be gathered on what we really need to get out of the SDP by some real life experience. > > > Thanks a lot. > > From harald@alvestrand.no Fri Jan 4 03:32:23 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39AB021F8696 for ; Fri, 4 Jan 2013 03:32:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.399 X-Spam-Level: X-Spam-Status: No, score=-109.399 tagged_above=-999 required=5 tests=[AWL=-0.601, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_45=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 WthLAmh2YJFh for ; Fri, 4 Jan 2013 03:32:22 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 59F1321F8671 for ; Fri, 4 Jan 2013 03:32:22 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2F25E39E1BD for ; Fri, 4 Jan 2013 12:32:18 +0100 (CET) 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 AJWkf5VNBJkM for ; Fri, 4 Jan 2013 12:32:17 +0100 (CET) Received: from [IPv6:2001:470:de0a:27:4134:bf42:7a46:3571] (unknown [IPv6:2001:470:de0a:27:4134:bf42:7a46:3571]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 06CFF39E13F for ; Fri, 4 Jan 2013 12:32:16 +0100 (CET) Message-ID: <50E6BDC0.4060803@alvestrand.no> Date: Fri, 04 Jan 2013 12:32:16 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <-3846863114415000908@unknownmsgid> In-Reply-To: Content-Type: multipart/alternative; boundary="------------060102070202000404040108" Subject: [rtcweb] Signalling for simulcast (Re: Support of video with different resolutions) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 04 Jan 2013 11:32:23 -0000 This is a multi-part message in MIME format. --------------060102070202000404040108 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 01/01/2013 12:45 AM, Bernard Aboba wrote: > Out of curiosity, is there a proposal for how to signal this in VP8? > (E.g. RFC 5888 + something akin to > draft-westerlund-avtcore-multistream-and-simulcast) I don't think this signalling should be codec specific; one could even imagine simulcasting on 2 different codecs in some scenarios (mixes of hardware clients). (Do we have simulcast, as opposed to SVC, signalling defined for any other codec?) Off the top of my head, I'd use a=msid with a new semantic tag, since I don't believe in having different mechanisms for m-line-level and ssrc-level multiplexing. Something like: a=msid-semantic:SIM abcde m=video a=ssrc:12345 msid:abcde a=ssrc:12377 msid:abcde (if needed, use the "appdata" field of msid to indicate something about each stream) The alternative (for ssrc multiplexing) is of course straight RFC 5576: a=ssrc-group:SIM 12345 12377 m=video ... other declarations as appropriate and for m-line level multiplexing, straight RFC 5888: a=group:SIM 1 2 m=video a=mid:1 m=video a=mid:2 With the fast work we're making on other topic, it shouldn't take more than a year or so to agree on these choices. --------------060102070202000404040108 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 01/01/2013 12:45 AM, Bernard Aboba wrote:
Out of curiosity, is there a proposal for how to signal this in VP8? (E.g. RFC 5888 + something akin to draft-westerlund-avtcore-multistream-and-simulcast)
I don't think this signalling should be codec specific; one could even imagine simulcasting on 2 different codecs in some scenarios (mixes of hardware clients).
(Do we have simulcast, as opposed to SVC, signalling defined for any other codec?)

Off the top of my head, I'd use a=msid with a new semantic tag, since I don't believe in having different mechanisms for m-line-level and ssrc-level multiplexing.

Something like:

a=msid-semantic:SIM abcde
m=video
a=ssrc:12345 msid:abcde
a=ssrc:12377 msid:abcde

(if needed, use the "appdata" field of msid to indicate something about each stream)

The alternative (for ssrc multiplexing) is of course straight RFC 5576:

a=ssrc-group:SIM 12345 12377
m=video
... other declarations as appropriate

and for m-line level multiplexing, straight RFC 5888:

a=group:SIM 1 2
m=video
a=mid:1
m=video
a=mid:2

With the fast work we're making on other topic, it shouldn't take more than a year or so to agree on these choices.



--------------060102070202000404040108-- From harald@alvestrand.no Fri Jan 4 03:39:34 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34AD321F8EA6 for ; Fri, 4 Jan 2013 03:39:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.999 X-Spam-Level: X-Spam-Status: No, score=-109.999 tagged_above=-999 required=5 tests=[AWL=0.600, 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 wq9nV-Ybqasq for ; Fri, 4 Jan 2013 03:39:33 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id A178021F8EA3 for ; Fri, 4 Jan 2013 03:39:33 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2C54739E1BD for ; Fri, 4 Jan 2013 12:39:32 +0100 (CET) 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 pUlClQgqRaw1 for ; Fri, 4 Jan 2013 12:39:30 +0100 (CET) Received: from [IPv6:2001:470:de0a:27:4134:bf42:7a46:3571] (unknown [IPv6:2001:470:de0a:27:4134:bf42:7a46:3571]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 2D6DB39E13F for ; Fri, 4 Jan 2013 12:39:29 +0100 (CET) Message-ID: <50E6BF6E.8080507@alvestrand.no> Date: Fri, 04 Jan 2013 12:39:26 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.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] [MMUSIC] Proposed Agenda for Interim X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 04 Jan 2013 11:39:34 -0000 (cutting back to RTCWEB) On 01/02/2013 07:18 PM, Cullen Jennings (fluffy) wrote: > I'm not really sure what to do here - given a key role of the chairs is largely to facilitate the discussions and meetings that Wg participants want to have, guidance from participants of both MMUSIC and rtcweb is really important here. I have to disagree on principle - the role of the chairs is to drive the WG to complete its charter. So the chairs have to set the agenda that allows us to make the maximum progress towards completing the charter; this is not a debating society. The chairs serve at the pleasure of the AD, not the WG. > > I agree that > > 1) the items in EKR's email do look like the a bunch of the high runner items that need to be resolved soon > > 2) the solutions of these problems are likely in to be mostly MMUSIC though, as Ted has pointed out, some amount of the requirements, architecture and other discussion can happen in rtcweb. > > 3) if we are going to have an MMUSIC face to face interim meeting, it would need AD approval and 4 weeks notices which puts us very close do the deadline so this needs to get sort out real soon. I think that due to the inaction on this topic in MMUSIC, this ship (for physical interims) has sailed. RTCWEB needs to make its plans for completing its charter accordingly. From uwe.rauschenbach@nsn.com Mon Jan 7 09:18:07 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2F7B21F85B3 for ; Mon, 7 Jan 2013 09:18:06 -0800 (PST) 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 8u+S++--nYVL for ; Mon, 7 Jan 2013 09:18:06 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 8A11F21F85C6 for ; Mon, 7 Jan 2013 09:18:05 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id r07HI3Nj017820 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 7 Jan 2013 18:18:04 +0100 Received: from DEMUEXC047.nsn-intra.net ([10.159.32.93]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id r07HI3Of024184; Mon, 7 Jan 2013 18:18:03 +0100 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by DEMUEXC047.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 7 Jan 2013 18:18:03 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 7 Jan 2013 18:18:02 +0100 Message-ID: <7CBFD4609D19C043A4AC4FD8381C6E26022F759E@DEMUEXC014.nsn-intra.net> In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF013A1025@MCHP04MSX.global-ad.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] Call for Consensus Regarding Selecting Recommended Audio Codecs Thread-Index: AQHN6mkI830GitSbMUylOQqXGrZCbZg+Gm5Q References: <50D2CC6A.4090500@ericsson.com> <50DC7830.1010206@alvestrand.no> <9F33F40F6F2CD847824537F3C4E37DDF013A1025@MCHP04MSX.global-ad.net> From: "Rauschenbach, Uwe (NSN - DE/Munich)" To: "ext Hutton, Andrew" , X-OriginalArrivalTime: 07 Jan 2013 17:18:03.0721 (UTC) FILETIME=[F3A41B90:01CDECFA] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 6499 X-purgate-ID: 151667::1357579084-00003C02-360A149A/0-0/0-0 Subject: Re: [rtcweb] Call for Consensus Regarding Selecting Recommended 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: Mon, 07 Jan 2013 17:18:07 -0000 My thoughts are in line with the ones from Andrew. Using normative = language may be too strong, but we should document the ecosystem to = allow interoperability with terminals not implementing=20 RTCWeb MTI codecs without introducing too big transcoding needs in = RTCWeb gateways in the network.=20 E.g., a mobile terminal natively implementing codecs such as AMR-WB = anyway could offer them in addition to the MTI codecs in RTCWeb session = set-ups. A gateway connecting such a terminal to non-RTCWeb terminals in = the mobile network would prefer such a mobile-specific codec over the = MTI ones, as this decreases the use of the transcoding resources in the = gateway. Guidelines of that kind could be part of the text to be written, too.=A0 Kind regards, Uwe=20 -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf = Of ext Hutton, Andrew Sent: Friday, January 04, 2013 11:48 AM To: Andrew Allen; Harald Alvestrand; rtcweb@ietf.org Subject: Re: [rtcweb] Call for Consensus Regarding Selecting Recommended = Audio Codecs I previously indicate support for 1) but I note the arguments put = forward by Adam Roach and agree that normative recommendations for = additional codec's are not necessary here. However I think it would be helpful to have some non normative text = describing how the implementation of particular codec's would improve = interoperability in specific environments (E.g. mobile) and although = this could be left to browser vendors to work out for themselves I don't = think that is a good argument for not doing it. We are here to promote = interoperability after all. I also disagree that the MTI codec's already agreed are sufficient to = ensure interoperability with non RTCWEB environments which according to = the rtcweb charter should be considered. Regards Andy > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > Behalf Of Andrew Allen > Sent: 03 January 2013 17:25 > To: Harald Alvestrand; rtcweb@ietf.org > Subject: Re: [rtcweb] Call for Consensus Regarding Selecting > Recommended Audio Codecs >=20 > I also support 2) >=20 > I really don't think it helps much to describe what other codecs are > out there that you might want to think about implementing if you want > to interoperate with certain other non RTCweb deployments. I think > anybody who is seriously thinking about developing such a product can > easily find this out for themselves - if you want to interoperate with > 3GPP devices then take a look at the CURRENT 3GPP Codec = specifications! >=20 > It should be realized that the codec life cycle tends to be somewhat > shorter than that of the signaling technology so the codec information > is likely to become out of date long before the signaling > specifications become obsolete (possibly already dated by the time the > RFC is published) - 3GPP is already working on a new codec for LTE! >=20 > As everyone has a favorite codec they would like to see deployed the > downside of this is that this will likely become a distraction that > generates a lot of discussion and consumes a lot of cycles that would > be better spent on addressing the basic interoperability issues facing > RTCweb. >=20 > So I think the MTI audio codecs already agreed is enough to ensure > interoperability. >=20 > Andrew >=20 > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > Behalf Of Harald Alvestrand > Sent: Thursday, December 27, 2012 11:33 AM > To: rtcweb@ietf.org > Subject: Re: [rtcweb] Call for Consensus Regarding Selecting > Recommended Audio Codecs >=20 > Speaking as an individual: >=20 > I am putting my name on 2), because I believe RECOMMENDED is too = strong > for secondary codecs. >=20 > On 12/20/2012 09:29 AM, Magnus Westerlund wrote: > > WG, > > > > As an outcome of the Vancouver IETF meeting codec discussions we did > > promise to run a call for consensus regarding if the WG was > interested > > in specifying a small set of recommended audio codecs. We are sorry > > this has been delayed until now. > > > > The question for the call of consensus is between two options. > > > > 1) Run a process in the WG to select and specify a small set of > > audio/speech codecs that would be RECOMMNEDED to implement by a > WebRTC > > end-points > > > > 2) Do nothing and let the already specified Mandatory to Implement > > Audio codecs be the only audio codecs mentioned in the WebRTC > specification. > > > > Please indicate your position by January 16th 2013. > > > > Regards > > > > Magnus Westerlund > > > > = --------------------------------------------------------------------- > - > > Multimedia Technologies, Ericsson Research EAB/TVM > > = --------------------------------------------------------------------- > - > > Ericsson AB | Phone +46 10 7148287 > > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > > = --------------------------------------------------------------------- > - > > > > _______________________________________________ > > 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 >=20 > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential > information, privileged material (including material protected by the > solicitor-client or other applicable privileges), or constitute non- > public information. Any use of this information by anyone other than > the intended recipient is prohibited. If you have received this > transmission in error, please immediately reply to the sender and > delete this information from your system. Use, dissemination, > distribution, or reproduction of this transmission by unintended > recipients is not authorized and may be unlawful. > _______________________________________________ > 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 iesg-secretary@ietf.org Mon Jan 7 09:30:19 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CB2121F890E; Mon, 7 Jan 2013 09:30:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.334 X-Spam-Level: X-Spam-Status: No, score=-102.334 tagged_above=-999 required=5 tests=[AWL=0.265, 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 UDvDVS3ptI-J; Mon, 7 Jan 2013 09:30:18 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD3ED21F88F5; Mon, 7 Jan 2013 09:30:18 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IESG Secretary To: IETF Announcement List X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130107173018.14035.3471.idtracker@ietfa.amsl.com> Date: Mon, 07 Jan 2013 09:30:18 -0800 Cc: rtcweb@ietf.org, mmusic@ietf.org Subject: [rtcweb] RTCWEB & MMUSIC WG Joint Interim Meeting, February 5-7, 2013 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 07 Jan 2013 17:30:19 -0000 The RTCWEB and MMUSIC working groups would like to announce an upcoming joint interim meeting. The meeting will be held in the Boston, Massachusetts area on February 5-7th, 2013, in conjunction with meetings of the W3C WEBRTC working group. Full details, including meeting site, nearby hotels, and other logistics have been posted to both the rtcweb and mmusic mailing lists = (http://www.ietf.org/mail-archive/web/rtcweb/current/maillist.html, = http://www.ietf.org/mail-archive/web/mmusic/current/maillist.html). From ted.ietf@gmail.com Mon Jan 7 10:13:39 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFF4D21F890E for ; Mon, 7 Jan 2013 10:13:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.788 X-Spam-Level: X-Spam-Status: No, score=-2.788 tagged_above=-999 required=5 tests=[AWL=0.810, 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 dH2V-MJz0Ql1 for ; Mon, 7 Jan 2013 10:13:39 -0800 (PST) Received: from mail-ia0-f180.google.com (mail-ia0-f180.google.com [209.85.210.180]) by ietfa.amsl.com (Postfix) with ESMTP id E1BD321F88D8 for ; Mon, 7 Jan 2013 10:13:30 -0800 (PST) Received: by mail-ia0-f180.google.com with SMTP id t4so16401622iag.39 for ; Mon, 07 Jan 2013 10:13:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=EDFRGb2DK88ojdXrNmkPjiOEvjUHmsqHCoArmv4FP5o=; b=lhF3vgH05gIbqXt7Idd6jo4OfcEAqcgaUz1PeEdF+ecnrqiQV7kSlEsF1xchtUdW2h qeHZKYBEpxfRG5jUas2vvVLZADtPhNNDcU+p5kZ327dJ/K94rxvSgQJjGdl5ELUIYqVM VkrhZ0s0CUub/8vHJJj2F7lWHWyc+bRjqeHi5zO4a7eVyEUuyGCQ6d4oJ41p3Dc2tUCK DTkgaYCI0M4vgMMGiOprDQA2SnOuLYqJdH+L2hSH+R/Z3Zj8uvN4fTunPn3NMEhD1VUb Xwan35vgcnUCLBQm67UX+CUb+NZ6JHUEK6K1slz2Cycpd22Kw7ivoQCu3StNlS1jgGPr yI8Q== MIME-Version: 1.0 X-Received: by 10.50.170.102 with SMTP id al6mr6358262igc.70.1357582410489; Mon, 07 Jan 2013 10:13:30 -0800 (PST) Received: by 10.43.94.5 with HTTP; Mon, 7 Jan 2013 10:13:30 -0800 (PST) In-Reply-To: <20130107173018.14035.3471.idtracker@ietfa.amsl.com> References: <20130107173018.14035.3471.idtracker@ietfa.amsl.com> Date: Mon, 7 Jan 2013 10:13:30 -0800 Message-ID: From: Ted Hardie To: rtcweb@ietf.org Content-Type: multipart/alternative; boundary=e89a8f3bb067549fea04d2b6c9b8 Subject: Re: [rtcweb] RTCWEB & MMUSIC WG Joint Interim Meeting, February 5-7, 2013 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 07 Jan 2013 18:13:40 -0000 --e89a8f3bb067549fea04d2b6c9b8 Content-Type: text/plain; charset=ISO-8859-1 Hi folks, As you can see from the updated announcement below, we've had an expansion of scope in the upcoming interim. Reacting to some of the discussion on the work to be done, Gonzalo recently reached out to the MMUSIC and RTCWEB chairs to discuss this. Because of the tight deadline to get this recognized as an MMUSIC interim, we did not have a lot of time to make this decision, and there are some details on agenda to work out. Our current thinking is that the IETF meetings would all be joint MMUSIC/RTCWEB meetings, with the possibility that some of the agenda items might be slightly less relevant to MMUSIC. Further agenda suggestions are, of course, welcome, but expect some agenda elaboration from the chairs soon. regards, Ted On Mon, Jan 7, 2013 at 9:30 AM, IESG Secretary wrote: > The RTCWEB and MMUSIC working groups would like to announce an upcoming > joint interim meeting. > > The meeting will be held in the Boston, Massachusetts area on February > 5-7th, 2013, in conjunction with meetings of the W3C WEBRTC working > group. Full details, including meeting site, nearby hotels, and other > logistics have been posted to both the rtcweb and mmusic mailing lists > (http://www.ietf.org/mail-archive/web/rtcweb/current/maillist.html, > http://www.ietf.org/mail-archive/web/mmusic/current/maillist.html). > --e89a8f3bb067549fea04d2b6c9b8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi folks,

As you can see from the updated announcement below, we'= ;ve had an expansion of scope in the upcoming interim.=A0 Reacting to some = of the discussion on the work to be done, Gonzalo recently reached out to t= he MMUSIC and RTCWEB chairs to discuss this.=A0 Because of the tight deadli= ne to get this recognized as an MMUSIC interim, we did not have a lot of ti= me to make this decision, and there are some details on agenda to work out.= =A0 Our current thinking is that the IETF meetings would all be joint MMUSI= C/RTCWEB meetings, with the possibility that some of the agenda items might= be slightly less relevant to MMUSIC.=A0=A0

Further agenda suggestions are, of course, welcome, but expect some age= nda elaboration from the chairs soon.

regards,

Ted

On Mon, Jan 7, 2013 at 9:30 AM, IESG Secretary <iesg-secretary@ietf.org> wrote:
The RTCWEB and MMUSIC working groups would l= ike to announce an upcoming
joint interim meeting.

The meeting will be held in the Boston, Massachusetts area on February
5-7th, 2013, in conjunction with meetings of the W3C WEBRTC working
group. Full details, including meeting site, nearby hotels, and other
logistics have been posted to both the rtcweb and mmusic mailing lists
(http://www.ietf.org/mail-archive/web/rtcweb/current/m= aillist.html,
http://www.ietf.org/mail-archive/web/mmusic/current/ma= illist.html).

--e89a8f3bb067549fea04d2b6c9b8-- From stefan.lk.hakansson@ericsson.com Tue Jan 8 02:28:00 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E31621F8AD4 for ; Tue, 8 Jan 2013 02:28:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, 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 noRwogoESKXN for ; Tue, 8 Jan 2013 02:27:59 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 25A6921F8ABD for ; Tue, 8 Jan 2013 02:27:58 -0800 (PST) X-AuditID: c1b4fb25-b7fb26d000006129-61-50ebf4ad5afe Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 8C.11.24873.DA4FBE05; Tue, 8 Jan 2013 11:27:57 +0100 (CET) Received: from [150.132.141.90] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.279.1; Tue, 8 Jan 2013 11:27:57 +0100 Message-ID: <50EBF4AD.2000006@ericsson.com> Date: Tue, 8 Jan 2013 11:27:57 +0100 From: =?ISO-8859-1?Q?Stefan_H=E5kansson_LK?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: rtcweb@ietf.org, "public-webrtc@w3.org" References: In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJJMWRmVeSWpSXmKPExsUyM+Jvje7aL68DDOZMM7Po/biE0WLtv3Z2 ByaPJUt+MnkcnbefNYApissmJTUnsyy1SN8ugSvjYet5poI1ohUzbt9ibGBcJtjFyMkhIWAi 8fX3SyYIW0ziwr31bF2MXBxCAicZJc7e/M0I4axmlDj9+x4LSBWvgLbE5bk32EFsFgEVieau E2wgNptAoMT1/7/AJokKhEhc//6IEaJeUOLkzCdgvSICThJnbpwEiwsLGEpMOrQBLC4kECBx 8vNrsDmcQHOubvwONp9ZwFbiwpzrLBC2vMT2t3OYIep1Jd69vsc6gVFgFpIVs5C0zELSsoCR eRUje25iZk56udEmRmDwHdzyW3UH451zIocYpTlYlMR5w10vBAgJpCeWpGanphakFsUXleak Fh9iZOLglGpg5HB6kZ347Gb08W2fVp13kd6/842D0L8lBmvf883423IjJLtgvZHnrnUCm1/u Yoz7wBby+svSq4vnBiwx95m9Kdpnh12b/+PrBQX/m1/ZfhFz/bpAZv6vqM7f756HG7a0i1wI OMK9JfbNE97MMyzCL7rcq7WOnBL1OG8d+bLQuqB6G2O7xPf2OUosxRmJhlrMRcWJACRRWwYM AgAA Subject: Re: [rtcweb] Proposed Agenda for Interim X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 08 Jan 2013 10:28:00 -0000 (Sorry for cross-posting). On 2013-01-02 16:12, Eric Rescorla wrote: > Chairs, > > I've spent some time thinking about the agenda for the interim, and > thought it might be helpful if I sent you a strawman based on the > items that are blocking progress in terms of implementation and > interoperability. > > Note: > I am assuming 4 hours each day. The times have been selected with > the objective of giving us enough time to really resolve the > open issues. Honestly, we might even add more time for > the issues on day 1. > > Hope this is helpful. One thing that I think we should discuss when there are protocol _and_ API people in the same room is call flows. We touched on it in the Lyon W3C meeting, but it was apparent that not everyone had the same view. Perhaps this could be folded into the "accept/reject" discussion proposed in [1]. [1] http://lists.w3.org/Archives/Public/public-webrtc/2013Jan/0000.html > > Day 1 > 2:00 Bundle [Holmberg] > Objective: select an approach and work out enough > details that the editors can work to produce a > suitable draft. > > Drafts: > - http://tools.ietf.org/html/draft-ietf-mmusic-sdp-bundle-negotiation > - http://tools.ietf.org/html/draft-alvestrand-one-rtp > - http://tools.ietf.org/html/draft-holmberg-mmusic-sdp-mmt-negotiation > > > 2:00 Multiple flow SDP representation [Jennings, Alvestrand] > Objective: decide on an architecture for large numbers > of similar streams (e.g., multiple video streams). > > Drafts: > - http://tools.ietf.org/html/draft-alvestrand-rtcweb-msid > - http://tools.ietf.org/html/draft-alvestrand-mmusic-msid > - Do we have a "master" document for the single m-line case? > - Multiple m-lines doesn't have a document > > > Day 2 > 1:30 Mapping stream/track label concepts SDP identifiers [Alvestrand] > Objective: determine requirements > 1:30 Trickle ICE open issues [Ivov(?), Uberti, Rescorla] > - Starting checks > - Termination conditions > - Error handling > Drafts: > http://tools.ietf.org/html/draft-rescorla-mmusic-ice-trickle > > 1:00 SDP for Datachannels open issues [Jesup, Loreto] > Objective: resolve open issues (post WGLC?) > > Drafts: > http://tools.ietf.org/html/draft-ietf-mmusic-sctp-sdp-02 > > Day 3 > 1:00 Other recommended audio codecs [Roach] > Objective: identify what other audio codecs we intend to > recommend. > > 1:00 Process WGLC comments on documents [authors] > > 0:30 Other business > > 0:30 Wrapup/next steps [Chairs] > > > Best, > -Ekr > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From kaiduanx@gmail.com Wed Jan 9 13:08:53 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D051A21F8581 for ; Wed, 9 Jan 2013 13:08:53 -0800 (PST) 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 dvaj9KvY5eJq for ; Wed, 9 Jan 2013 13:08:53 -0800 (PST) Received: from mail-oa0-f50.google.com (mail-oa0-f50.google.com [209.85.219.50]) by ietfa.amsl.com (Postfix) with ESMTP id 3010221F84BC for ; Wed, 9 Jan 2013 13:08:53 -0800 (PST) Received: by mail-oa0-f50.google.com with SMTP id n16so1544368oag.9 for ; Wed, 09 Jan 2013 13:08:52 -0800 (PST) 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=5iq98hHwazl9SqdD8BXVABnFNTRHSzbHm2oF5Y6U7dI=; b=NgbKc6dDdK6gnYzE8C7MOWamQpV68qExmwD0lhyP09Ch8PuYMLeRflej22y626FmWe b9uTZWJnfR+6ZNBhY9tCCGAy9BCbDLfNxC/qGJYwybM/XISrh12AaGMhsMQdXL0qXHIO BT2I8OIJP9hq3hi8M/hLN4kImIkpwB26utiGO1SMIoMjCYSQFVqwX5NTpCY7aZ9szDRC PewnzB/5kmWMmihQDfDWAVMdqDcYLF1kTYbbP/Sjh0DhLhOnYt2/gfZM9SpOTZ8S4qt0 RMem2i7m6rVqnWaIyXyLvrOtjj7z/jBkODLM3naWJY69hNTbX5/y7Vci3u2mplffeYBc MkOQ== MIME-Version: 1.0 Received: by 10.182.51.66 with SMTP id i2mr50987111obo.43.1357765732330; Wed, 09 Jan 2013 13:08:52 -0800 (PST) Received: by 10.76.113.5 with HTTP; Wed, 9 Jan 2013 13:08:52 -0800 (PST) Date: Wed, 9 Jan 2013 16:08:52 -0500 Message-ID: From: Kaiduan Xie To: rtcweb@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [rtcweb] RTP Payload Format for H.264 video X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 09 Jan 2013 21:08:54 -0000 Hi, This may seems off-topic of webrtc, but I need some advice from someone with knowledge on H.264/RTP. For H.264, do we MUST follow RFC 3984/6184 to encapsulate H.264 encoded video frame into RTP packet? Thanks, /Kaiduan From harald@alvestrand.no Thu Jan 10 03:57:59 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A00FF21F862E for ; Thu, 10 Jan 2013 03:57:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.359 X-Spam-Level: X-Spam-Status: No, score=-110.359 tagged_above=-999 required=5 tests=[AWL=0.240, 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 NNledVQZkzw8 for ; Thu, 10 Jan 2013 03:57:57 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 6F66E21F8634 for ; Thu, 10 Jan 2013 03:57:57 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id AEFCE39E240; Thu, 10 Jan 2013 12:57:49 +0100 (CET) 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 KnSZFPA6qsMV; Thu, 10 Jan 2013 12:57:48 +0100 (CET) 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 488DE39E1C9; Thu, 10 Jan 2013 12:57:48 +0100 (CET) Message-ID: <50EEACBB.2040802@alvestrand.no> Date: Thu, 10 Jan 2013 12:57:47 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Kaiduan Xie References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rtcweb@ietf.org Subject: Re: [rtcweb] RTP Payload Format for H.264 video X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 10 Jan 2013 11:57:59 -0000 On 01/09/2013 10:08 PM, Kaiduan Xie wrote: > Hi, > > This may seems off-topic of webrtc, but I need some advice from > someone with knowledge on H.264/RTP. > > For H.264, do we MUST follow RFC 3984/6184 to encapsulate H.264 > encoded video frame into RTP packet? Generic codec questions for RTP should probably be addressed to the payload@ietf.org list, not here. (I think the answer is yes, if you want to claim that you're implementing H.264 that can interoperate with others, but I haven't tried to parse those RFCs.) > > Thanks, > > /Kaiduan > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From stephane.proust@orange.com Fri Jan 11 04:33:06 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 479C321F8870 for ; Fri, 11 Jan 2013 04:33:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.283 X-Spam-Level: X-Spam-Status: No, score=-2.283 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 LMiRck01eGI6 for ; Fri, 11 Jan 2013 04:33:05 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 4242721F886D for ; Fri, 11 Jan 2013 04:33:05 -0800 (PST) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id DEC7B3B47B8; Fri, 11 Jan 2013 13:33:03 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id C277E2380DA; Fri, 11 Jan 2013 13:33:03 +0100 (CET) Received: from PEXCVZYM14.corporate.adroot.infra.ftgroup ([fe80::a42f:c628:bc76:d592]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0318.004; Fri, 11 Jan 2013 13:33:03 +0100 From: To: Magnus Westerlund , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Call for Consensus Regarding Selecting Recommended Audio Codecs Thread-Index: AQHN3owmqyZHJi4FC0mpFMH1fvMMAZhEMJww Date: Fri, 11 Jan 2013 12:33:02 +0000 Message-ID: <6515_1357907583_50F0067F_6515_1738_1_2842AD9A45C83B44B57635FD4831E60A0747CC@PEXCVZYM14.corporate.adroot.infra.ftgroup> References: <50D2CC6A.4090500@ericsson.com> In-Reply-To: <50D2CC6A.4090500@ericsson.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.10.24.110314 Subject: Re: [rtcweb] Call for Consensus Regarding Selecting Recommended 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, 11 Jan 2013 12:33:06 -0000 It is clear from the discussions on the rtcweb e-mail reflector that the on= ly additional codecs to be considered are limited to the following very sma= ll subset of 3 codecs: AMR, AMR-WB and G.722.=20 In addition to G.711, these 3 codecs cover almost all legacy devices dedica= ted to voice services. They are consequently needed and sufficient to be su= pported by WebRTC to make it an attractive and future proof technology for = usage in all environments including mobile and for interoperability use cas= es with most of all legacy voice terminals. AMR and AMR-WB are indeed the most widely supported voice codecs in hundred= s of millions of legacy mobile devices. G.722 is royalty free (including a Packet Loss Concealment solution provide= d in ITU-T Software Tool Library) and is the codec used for HD Voice / DECT= -Cat IQ fixed devices Furthermore, considering that the reason for excluding AMR and AMR-WB from = WebRTC was the licensing issue, there is no reason to NOT support AMR-WB an= d AMR at WebRTC level if these codecs are already implemented on the device. Therefore I support option 1 and propose the following specification accord= ing this: AMR-WB, AMR and G.722 are RECOMMENDED TO IMPLEMENT by WebRTC end-points AMR and AMR-WB MUST BE supported at WebRTC level by WebRTC end-points on 3G= PP mobile devices already implementing AMR and AMR-WB (*) (*) note that the way these codecs are supported at RTC Web level is left o= pen to implementors: either by a WebRTC specific software implementation of= these codecs or by using APIs to access hardward implementation.=20 -----Message d'origine----- De=A0: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] De la part = de Magnus Westerlund Envoy=E9=A0: jeudi 20 d=E9cembre 2012 09:30 =C0=A0: rtcweb@ietf.org Objet=A0: [rtcweb] Call for Consensus Regarding Selecting Recommended Audio= Codecs WG, As an outcome of the Vancouver IETF meeting codec discussions we did promise to run a call for consensus regarding if the WG was interested in specifying a small set of recommended audio codecs. We are sorry this has been delayed until now. The question for the call of consensus is between two options. 1) Run a process in the WG to select and specify a small set of audio/speech codecs that would be RECOMMNEDED to implement by a WebRTC end-points 2) Do nothing and let the already specified Mandatory to Implement Audio codecs be the only audio codecs mentioned in the WebRTC specification. Please indicate your position by January 16th 2013. Regards Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 F=E4r=F6gatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ 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 stephane.proust@orange.com Fri Jan 11 05:18:00 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E16C21F87AD for ; Fri, 11 Jan 2013 05:18:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.441 X-Spam-Level: X-Spam-Status: No, score=-2.441 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, 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 Yw5FQFM5CjMI for ; Fri, 11 Jan 2013 05:17:59 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 0841921F86EA for ; Fri, 11 Jan 2013 05:17:59 -0800 (PST) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 52BD0324756; Fri, 11 Jan 2013 14:17:58 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 3505A4C0F8; Fri, 11 Jan 2013 14:17:58 +0100 (CET) Received: from PEXCVZYM14.corporate.adroot.infra.ftgroup ([fe80::a42f:c628:bc76:d592]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0318.004; Fri, 11 Jan 2013 14:17:57 +0100 From: To: Koen Vos , Steve Sokol , "Cullen Jennings (fluffy)" Thread-Topic: [rtcweb] Call for Consensus Regarding Selecting Recommended Audio Codecs Thread-Index: AQHN5GDMPl1xM1Ggh020kmnmmFWlsZhEMRvA Date: Fri, 11 Jan 2013 13:17:57 +0000 Message-ID: <18530_1357910278_50F01106_18530_10607_1_2842AD9A45C83B44B57635FD4831E60A074866@PEXCVZYM14.corporate.adroot.infra.ftgroup> References: , <7daabbec-07cc-421e-b6d4-5292b9c063b5@zimbra> <720e6883d7994faf9b3d415fcc88eca5@DFM-CO1MBX15-04.exchange.corp.microsoft.com> In-Reply-To: <720e6883d7994faf9b3d415fcc88eca5@DFM-CO1MBX15-04.exchange.corp.microsoft.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: 2013.1.11.125417 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Call for Consensus Regarding Selecting Recommended 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, 11 Jan 2013 13:18:00 -0000 Koen Vos wrote: > In short: there are IPR issues with the PLC required for using G.722 on t= he Internet. NO, PLC solutions for G.722 with no IPR issues are publicly available in IT= U-T Software Tool Library http://www.itu.int/rec/T-REC-G.191-201003-I 8. G.722: The ITU-T 64, 56, and 48 kbit/s wideband speech coding algorithm = 73 8.1.3 Functional description of the basic Packet Loss Concealment functiona= lity 80 St=E9phane De=A0: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] De la part = de Koen Vos Envoy=E9=A0: jeudi 27 d=E9cembre 2012 19:34 =C0=A0: Steve Sokol; Cullen Jennings (fluffy) Cc=A0: rtcweb@ietf.org Objet=A0: Re: [rtcweb] Call for Consensus Regarding Selecting Recommended A= udio Codecs Steve Sokol wrote: > G.722 has no known IPR issues. This is inaccurate.=A0=20 While the basic codec has no such issues, the various Packet Loss Concealme= nt methods that were later added to the standard are patented.=A0 This matt= ers because G.722 uses ADPCM and is unusually sensitive to packet loss.=A0 = For instance, without PLC the codec will sometimes generate a full-scale os= cillating output after a loss.=A0 Since a traditional PLC doesn't work for = this kind of behavior, there was a need to invent a PLC specifically for G.= 722. In short: there are IPR issues with the PLC required for using G.722 on the= Internet. koen. ________________________________________ From: rtcweb-bounces@ietf.org on behalf of Steve Sokol Sent: Thursday, December 27, 2012 9:05 AM To: Cullen Jennings (fluffy) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Call for Consensus Regarding Selecting Recommended Au= dio Codecs Per Cullen's request, here is the very short list of audio codecs that seem= to have received some interest and the associated benefit of including the= m in the standard: G.722 - The de facto standard for "HD audio", G.722 has the advantage of wi= de deployment in both hard and soft endpoints. G.722 has no known IPR issue= s. It consumes a relatively modest 64 Kbps which covers most use cases (tho= ugh not Edge). Inclusion of G.722 would arguably simplify interoperability = with HD-capable legacy endpoints and gateways. AMR,=A0AMR-WB - The official standards for mobile telephony. Adding support= for the AMR codecs would arguably simplify the process of interoperation w= ith mobile endpoints. Licenses would be required as both include patented t= echnology. None - Several group members have argued that the standard should not inclu= de SHOULD or RECOMMENDED codecs for various reasons. Speaking for myself, I don't see much reason to include any of these. With = mandatory encryption, media stream bundling and various other divergences f= rom the way most legacy endpoints operate, I don't see unmediated legacy in= teroperability as likely to happen -- you will always need something to act= as a gateway. =A0That being the case, why clutter up the standard with "SH= OULD" or "RECOMMENDED" directives? The best thing about WebRTC is that it is (thus far) not an attempt to re-b= uild the PSTN on yet another IP platform. Keep is simple.=A0 ___________________________________________________________________________= ______________________________________________ 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 harald@alvestrand.no Fri Jan 11 06:18:31 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B83421F894D for ; Fri, 11 Jan 2013 06:18:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.427 X-Spam-Level: X-Spam-Status: No, score=-110.427 tagged_above=-999 required=5 tests=[AWL=0.172, 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 bJKSDbwoLX7D for ; Fri, 11 Jan 2013 06:18:30 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 0B5E521F894C for ; Fri, 11 Jan 2013 06:18:30 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 705DA39E2BE for ; Fri, 11 Jan 2013 15:18:27 +0100 (CET) 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 9W5cgZYAUXfY for ; Fri, 11 Jan 2013 15:18:24 +0100 (CET) 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 B596B39E241 for ; Fri, 11 Jan 2013 15:18:24 +0100 (CET) Message-ID: <50F01F30.4010006@alvestrand.no> Date: Fri, 11 Jan 2013 15:18:24 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: , <7daabbec-07cc-421e-b6d4-5292b9c063b5@zimbra> <720e6883d7994faf9b3d415fcc88eca5@DFM-CO1MBX15-04.exchange.corp.microsoft.com> <18530_1357910278_50F01106_18530_10607_1_2842AD9A45C83B44B57635FD4831E60A074866@PEXCVZYM14.corporate.adroot.infra.ftgroup> In-Reply-To: <18530_1357910278_50F01106_18530_10607_1_2842AD9A45C83B44B57635FD4831E60A074866@PEXCVZYM14.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [rtcweb] Call for Consensus Regarding Selecting Recommended 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, 11 Jan 2013 14:18:31 -0000 On 01/11/2013 02:17 PM, stephane.proust@orange.com wrote: > Koen Vos wrote: >> In short: there are IPR issues with the PLC required for using G.722 on the Internet. > NO, PLC solutions for G.722 with no IPR issues are publicly available in ITU-T Software Tool Library > > http://www.itu.int/rec/T-REC-G.191-201003-I > > 8. G.722: The ITU-T 64, 56, and 48 kbit/s wideband speech coding algorithm 73 > > 8.1.3 Functional description of the basic Packet Loss Concealment functionality 80 > > Stéphane Not speaking to the suitability of G.722, but on the "are there patents" issue: G.191 (the software tools library) has no IPR statements in the ITU-T IPR database: http://www.itu.int/ipr/IPRSearch.aspx?iprtype=PS G.722 has 47 such statements against it, the first filed in 1996, the last filed in 2012. Figuring out if any of those patent claims apply to the PLC part, whether those claims (if any) also apply to the G.191 implementation, and guessing at the reasons why they are filed against G.722 and not against G.191, is something I don't want to venture into at all. I'll leave that to the proponents to sort out. > > > > De : rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] De la part de Koen Vos > Envoyé : jeudi 27 décembre 2012 19:34 > Ŕ : Steve Sokol; Cullen Jennings (fluffy) > Cc : rtcweb@ietf.org > Objet : Re: [rtcweb] Call for Consensus Regarding Selecting Recommended Audio Codecs > > Steve Sokol wrote: >> G.722 has no known IPR issues. > This is inaccurate. > > While the basic codec has no such issues, the various Packet Loss Concealment methods that were later added to the standard are patented. This matters because G.722 uses ADPCM and is unusually sensitive to packet loss. For instance, without PLC the codec will sometimes generate a full-scale oscillating output after a loss. Since a traditional PLC doesn't work for this kind of behavior, there was a need to invent a PLC specifically for G.722. > > In short: there are IPR issues with the PLC required for using G.722 on the Internet. > > koen. > > ________________________________________ > From: rtcweb-bounces@ietf.org on behalf of Steve Sokol > Sent: Thursday, December 27, 2012 9:05 AM > To: Cullen Jennings (fluffy) > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] Call for Consensus Regarding Selecting Recommended Audio Codecs > Per Cullen's request, here is the very short list of audio codecs that seem to have received some interest and the associated benefit of including them in the standard: > > G.722 - The de facto standard for "HD audio", G.722 has the advantage of wide deployment in both hard and soft endpoints. G.722 has no known IPR issues. It consumes a relatively modest 64 Kbps which covers most use cases (though not Edge). Inclusion of G.722 would arguably simplify interoperability with HD-capable legacy endpoints and gateways. > > AMR, AMR-WB - The official standards for mobile telephony. Adding support for the AMR codecs would arguably simplify the process of interoperation with mobile endpoints. Licenses would be required as both include patented technology. > > None - Several group members have argued that the standard should not include SHOULD or RECOMMENDED codecs for various reasons. > > Speaking for myself, I don't see much reason to include any of these. With mandatory encryption, media stream bundling and various other divergences from the way most legacy endpoints operate, I don't see unmediated legacy interoperability as likely to happen -- you will always need something to act as a gateway. That being the case, why clutter up the standard with "SHOULD" or "RECOMMENDED" directives? > > The best thing about WebRTC is that it is (thus far) not an attempt to re-build the PSTN on yet another IP platform. Keep is simple. > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles 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 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 information 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 delete this message and its attachments. > As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified. > Thank you. > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From coverdale@sympatico.ca Fri Jan 11 07:57:08 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A0FB21F8770 for ; Fri, 11 Jan 2013 07:57:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.481 X-Spam-Level: X-Spam-Status: No, score=-1.481 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803, 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 VHCWsGeQmMe9 for ; Fri, 11 Jan 2013 07:57:07 -0800 (PST) Received: from blu0-omc3-s21.blu0.hotmail.com (blu0-omc3-s21.blu0.hotmail.com [65.55.116.96]) by ietfa.amsl.com (Postfix) with ESMTP id 732E121F8734 for ; Fri, 11 Jan 2013 07:57:07 -0800 (PST) Received: from BLU0-SMTP88 ([65.55.116.74]) by blu0-omc3-s21.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 11 Jan 2013 07:57:05 -0800 X-EIP: [lNRwi1nzspooD5pCaH857wFVP9OlHlXm] X-Originating-Email: [coverdale@sympatico.ca] Message-ID: Received: from PaulNewPC ([74.12.63.149]) by BLU0-SMTP88.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 11 Jan 2013 07:57:03 -0800 From: Paul Coverdale To: , "'Magnus Westerlund'" , References: <50D2CC6A.4090500@ericsson.com> <6515_1357907583_50F0067F_6515_1738_1_2842AD9A45C83B44B57635FD4831E60A0747CC@PEXCVZYM14.corporate.adroot.infra.ftgroup> In-Reply-To: <6515_1357907583_50F0067F_6515_1738_1_2842AD9A45C83B44B57635FD4831E60A0747CC@PEXCVZYM14.corporate.adroot.infra.ftgroup> Date: Fri, 11 Jan 2013 10:56:59 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHN3owmqyZHJi4FC0mpFMH1fvMMAZhEMJwwgAAfv6A= Content-Language: en-us X-OriginalArrivalTime: 11 Jan 2013 15:57:04.0066 (UTC) FILETIME=[4CB69A20:01CDF014] Subject: Re: [rtcweb] Call for Consensus Regarding Selecting Recommended 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, 11 Jan 2013 15:57:08 -0000 I support Stephane's proposal for option 1. It makes good sense, particularly for the case where AMR and AMR-WB are already implemented = in mobile devices - there are no additional licensing issues and it = simplifies interoperability. ...Paul >-----Original Message----- >From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On = Behalf >Of stephane.proust@orange.com >Sent: Friday, January 11, 2013 7:33 AM >To: Magnus Westerlund; rtcweb@ietf.org >Subject: Re: [rtcweb] Call for Consensus Regarding Selecting = Recommended >Audio Codecs > >It is clear from the discussions on the rtcweb e-mail reflector that = the >only additional codecs to be considered are limited to the following >very small subset of 3 codecs: AMR, AMR-WB and G.722. >In addition to G.711, these 3 codecs cover almost all legacy devices >dedicated to voice services. They are consequently needed and = sufficient >to be supported by WebRTC to make it an attractive and future proof >technology for usage in all environments including mobile and for >interoperability use cases with most of all legacy voice terminals. > >AMR and AMR-WB are indeed the most widely supported voice codecs in >hundreds of millions of legacy mobile devices. >G.722 is royalty free (including a Packet Loss Concealment solution >provided in ITU-T Software Tool Library) and is the codec used for HD >Voice / DECT-Cat IQ fixed devices > >Furthermore, considering that the reason for excluding AMR and AMR-WB >from WebRTC was the licensing issue, there is no reason to NOT support >AMR-WB and AMR at WebRTC level if these codecs are already implemented >on the device. > >Therefore I support option 1 and propose the following specification >according this: >AMR-WB, AMR and G.722 are RECOMMENDED TO IMPLEMENT by WebRTC end-points >AMR and AMR-WB MUST BE supported at WebRTC level by WebRTC end-points = on >3GPP mobile devices already implementing AMR and AMR-WB (*) > >(*) note that the way these codecs are supported at RTC Web level is >left open to implementors: either by a WebRTC specific software >implementation of these codecs or by using APIs to access hardward >implementation. > > >-----Message d'origine----- >De=A0: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] De la = part >de Magnus Westerlund Envoy=E9=A0: jeudi 20 d=E9cembre 2012 09:30 = =C0=A0: >rtcweb@ietf.org Objet=A0: [rtcweb] Call for Consensus Regarding = Selecting >Recommended Audio Codecs > >WG, > >As an outcome of the Vancouver IETF meeting codec discussions we did >promise to run a call for consensus regarding if the WG was interested >in specifying a small set of recommended audio codecs. We are sorry = this >has been delayed until now. > >The question for the call of consensus is between two options. > >1) Run a process in the WG to select and specify a small set of >audio/speech codecs that would be RECOMMNEDED to implement by a WebRTC >end-points > >2) Do nothing and let the already specified Mandatory to Implement = Audio >codecs be the only audio codecs mentioned in the WebRTC specification. > >Please indicate your position by January 16th 2013. > >Regards > >Magnus Westerlund > >---------------------------------------------------------------------- >Multimedia Technologies, Ericsson Research EAB/TVM >---------------------------------------------------------------------- >Ericsson AB | Phone +46 10 7148287 >F=E4r=F6gatan 6 | Mobile +46 73 0949079 >SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com >---------------------------------------------------------------------- > >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb > >________________________________________________________________________= >_________________________________________________ > >Ce message et ses pieces jointes peuvent contenir des informations >confidentielles 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 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 >information 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 >delete this message and its attachments. >As emails may be altered, France Telecom - Orange is not liable for >messages that have been modified, changed or falsified. >Thank you. > >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb From coverdale@sympatico.ca Fri Jan 11 08:46:46 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA6CC21F8971 for ; Fri, 11 Jan 2013 08:46:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.639 X-Spam-Level: X-Spam-Status: No, score=-1.639 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599, 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 PBsjaLTgfTIn for ; Fri, 11 Jan 2013 08:46:46 -0800 (PST) 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 032B421F8996 for ; Fri, 11 Jan 2013 08:46:45 -0800 (PST) Received: from BLU0-SMTP59 ([65.55.116.72]) by blu0-omc3-s27.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 11 Jan 2013 08:46:45 -0800 X-EIP: [gKuJ6GPFLt61DV0unMb2E9H8UL/WvOSz] X-Originating-Email: [coverdale@sympatico.ca] Message-ID: Received: from PaulNewPC ([74.12.63.149]) by BLU0-SMTP59.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 11 Jan 2013 08:46:43 -0800 From: Paul Coverdale To: "'Harald Alvestrand'" , References: , <7daabbec-07cc-421e-b6d4-5292b9c063b5@zimbra> <720e6883d7994faf9b3d415fcc88eca5@DFM-CO1MBX15-04.exchange.corp.microsoft.com> <18530_1357910278_50F01106_18530_10607_1_2842AD9A45C83B44B57635FD4831E60A074866@PEXCVZYM14.corporate.adroot.infra.ftgroup> <50F01F30.4010006@alvestrand.no> In-Reply-To: <50F01F30.4010006@alvestrand.no> Date: Fri, 11 Jan 2013 11:46:39 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac3wBo//0rZ/CoxrQCSz6hTjelyNGwADcbPw Content-Language: en-us X-OriginalArrivalTime: 11 Jan 2013 16:46:43.0445 (UTC) FILETIME=[3C8FC250:01CDF01B] Subject: Re: [rtcweb] Call for Consensus Regarding Selecting Recommended 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, 11 Jan 2013 16:46:47 -0000 Just to clarify, of the 47 IPR statements against G.722 in the ITU IPR database, only 13 refer to "vanilla G.722". The rest relate to other flavours, such as G.722.1, G.722.2 (essentially AMR-WB anyway), = G.722-SWB and various Appendices. Of these 13, 5 were filed in 1986, 1 in 2006 and = 7 in 2012. As for the accompanying ITU-T PLC algorithms, bear in mind that these = are Appendices, and hence not a normative part of G.722. Implementors are = free to do what they like about PLC. ...Paul >-----Original Message----- >From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On = Behalf >Of Harald Alvestrand >Sent: Friday, January 11, 2013 9:18 AM >To: rtcweb@ietf.org >Subject: Re: [rtcweb] Call for Consensus Regarding Selecting = Recommended >Audio Codecs > >On 01/11/2013 02:17 PM, stephane.proust@orange.com wrote: >> Koen Vos wrote: >>> In short: there are IPR issues with the PLC required for using G.722 >on the Internet. >> NO, PLC solutions for G.722 with no IPR issues are publicly available >> in ITU-T Software Tool Library >> >> http://www.itu.int/rec/T-REC-G.191-201003-I >> >> 8. G.722: The ITU-T 64, 56, and 48 kbit/s wideband speech coding >> algorithm 73 >> >> 8.1.3 Functional description of the basic Packet Loss Concealment >> functionality 80 >> >> St=E9phane > >Not speaking to the suitability of G.722, but on the "are there = patents" >issue: > >G.191 (the software tools library) has no IPR statements in the ITU-T >IPR database: >http://www.itu.int/ipr/IPRSearch.aspx?iprtype=3DPS > >G.722 has 47 such statements against it, the first filed in 1996, the >last filed in 2012. > >Figuring out if any of those patent claims apply to the PLC part, >whether those claims (if any) also apply to the G.191 implementation, >and guessing at the reasons why they are filed against G.722 and not >against G.191, is something I don't want to venture into at all. > >I'll leave that to the proponents to sort out. > >> >> >> >> De : rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] De la >> part de Koen Vos Envoy=E9 : jeudi 27 d=E9cembre 2012 19:34 =C0 : = Steve >> Sokol; Cullen Jennings (fluffy) Cc : rtcweb@ietf.org Objet : Re: >> [rtcweb] Call for Consensus Regarding Selecting Recommended Audio >> Codecs >> >> Steve Sokol wrote: >>> G.722 has no known IPR issues. >> This is inaccurate. >> >> While the basic codec has no such issues, the various Packet Loss >Concealment methods that were later added to the standard are patented. >This matters because G.722 uses ADPCM and is unusually sensitive to >packet loss. For instance, without PLC the codec will sometimes >generate a full-scale oscillating output after a loss. Since a >traditional PLC doesn't work for this kind of behavior, there was a = need >to invent a PLC specifically for G.722. >> >> In short: there are IPR issues with the PLC required for using G.722 >on the Internet. >> >> koen. >> From prvs=072473467c=aallen@rim.com Sat Jan 12 10:53:08 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4299E21F8749 for ; Sat, 12 Jan 2013 10:53:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.692 X-Spam-Level: X-Spam-Status: No, score=-3.692 tagged_above=-999 required=5 tests=[AWL=1.511, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 dNj7XGuLvaCa for ; Sat, 12 Jan 2013 10:53:07 -0800 (PST) Received: from mhs060cnc.rim.net (mhs060cnc.rim.net [208.65.73.34]) by ietfa.amsl.com (Postfix) with ESMTP id BFF2B21F8731 for ; Sat, 12 Jan 2013 10:53:06 -0800 (PST) X-AuditID: 0a41282f-b7f8c6d000004b29-f8-50f1b10174e0 Received: from XCT104ADS.rim.net (xct104ads.rim.net [10.67.111.45]) by mhs060cnc.rim.net (SBG) with SMTP id 0E.10.19241.101B1F05; Sat, 12 Jan 2013 12:52:49 -0600 (CST) Received: from XMB104ADS.rim.net ([fe80::2494:a63d:e3:723b]) by XCT104ADS.rim.net ([fe80::90f9:3b89:1d94:aa9b%22]) with mapi id 14.02.0318.001; Sat, 12 Jan 2013 12:52:49 -0600 From: Andrew Allen To: "andrew.hutton@siemens-enterprise.com" , "harald@alvestrand.no" , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Call for Consensus Regarding Selecting Recommended Audio Codecs Thread-Index: AQHN5E/V+IaWIiAHjEiWJfuSRtT+RJg34eLQgAGL/4CADLWGAw== Date: Sat, 12 Jan 2013 18:52:48 +0000 Message-ID: In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF013A1025@MCHP04MSX.global-ad.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.67.110.253] Content-Type: text/plain; charset="iso-8859-1" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrCKsWRmVeSWpSXmKPExsXC5Zyvq8u48WOAwc8FxhZn+7rYLY71dbFZ rP3Xzu7A7HFlwhVWjyVLfjJ53Lj9njmAOaqB0SYpsaQsODM9T9/OJjEvL78ksSRVISW1ONlW ySc1PTFHIaAosywxuVLBJbM4OScxMze1SEkhM8VWyURJoSAnMTk1NzWvxFYpsaAgNS9FyY5L AQPYAJVl5imk5iXnp2TmpdsqeQb761pYmFrqGirZ6SZ08mQcePiRueCDXcXujwfYGxh7jLsY OTkkBEwk7hw7xgJhi0lcuLeerYuRi0NIYCWjxKuFt1kgnM2MEidbDjCDVLEJKEss/z2DESQh AlL1aP8FIIeDQ1ggXOLVi2yQGhGBCIlVT14wQthOEtf+tTGB2CwCqhI7N8wAi/MKeEjMnNcI FucU8Jdom7MBbD4j0BXfT60BizMLiEvcejKfCeI6AYkle84zQ9iiEi8f/2OFsBUl/u79zgpR rydxY+oUNghbW2LZwtfMELsEJU7OfMIygVFkFpKxs5C0zELSMgtJywJGllWMgrkZxQZmBsl5 yXpFmbl6eaklmxhBycBRQ38H49v3FocYBTgYlXh4Z6z4GCDEmlhWXJl7iFGCg1lJhPcISIg3 JbGyKrUoP76oNCe1+BCjKzAkJjJLcSfnAxNVXkm8sYEBbo6SOK9k7+UAIYF0YJrJTk0tSC2C mcPEwQmyh0tKpBiYLFKLEktLMuJBKS2+GJjUpBoYl7H8O5R4cl65Wjz7Mh/2kw+z4ksifQU4 zrXWF37bzSy/OtfrMFPr+y1vTn2atKzk9NTmr9cLypYH/hVJiFgpJJ7of2Pjg+UZxj2Fdv3/ fnaLnhC/zn3s6rUn62afPqgikZU5PXgH96dJMlcuCBkurPq99NoCm/QKc8mtC/fOZah1DJVn PRpzXYmlOCPRUIu5qDgRAFJGTM1HAwAA Subject: Re: [rtcweb] Call for Consensus Regarding Selecting Recommended 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, 12 Jan 2013 18:53:08 -0000 I really still don't see what the value is as part of RTCweb in describing t= he other codecs that are used by other VoIP and audio over IP and other digi= tal audio systems and the perceived pros and cons of each. This information is commonly available - just type codecs on wikipedia and y= ou will get a large list of many of the commonly used audio codecs and where= they are used and what the perceived royalty situation is. For the real inf= ormation you will have to go to the organisations that specify the codecs in= any case. I think it should be obvious that if the device is a 3GPP mobile device then= it will also support the 3GPP codecs and IETF doesn't need to tell RTCweb i= mplementors that. It should also be obvious that if you want to interoperate= without transcoding with 3GPP devices then you should take a look at the 3G= PP codec specifications. I don't think IETF and certainly not RTCweb should embark on duplicating inf= ormation that is available elsewhere from the organisations that own and hav= e the expertise on those codecs. Any information documented in IETF on this= even if accurate to begin with is likely to become rapidly out dated as new= codecs are developed and as patents expire. Also I doubt very much this will end up being limited to just AMR-NB, AMR-WB= and G.722. Once we go down the path of saying RTCweb is going to document t= he other codecs that implementations should consider supporting for optimal= interoperability I expect many more wil be added to the list as most of the= codecs still in use have legacy terminals in some deployment somewhere that= someone will think it is a good idea to interoperate with. I think this wil= l get out of hand and either will become a long list of codecs or become a h= uge discussion about which are important and which are not. I think this is a waste of time and a distraction from solving the real inte= roperability issues like agreeing a common video codec and making sure JSEP= and SIP/SDP interoperate well together. I think its enough in RTCweb just to state that for best interoperability al= so supporting additional codecs commonly used in other deployments that ther= e is a desire to interoperate with is a good thing in order to avoid the iss= ues of transcoding. Then let implementors and the market decide which other codecs are important= to implement. Andrew ----- Original Message ----- From: Hutton, Andrew [mailto:andrew.hutton@siemens-enterprise.com] Sent: Friday, January 04, 2013 04:47 AM Central Standard Time=0A= To: Andrew Allen; Harald Alvestrand ; rtcweb@ietf.org= Subject: RE: [rtcweb] Call for Consensus Regarding Selecting Recommended Aud= io Codecs I previously indicate support for 1) but I note the arguments put forward by= Adam Roach and agree that normative recommendations for additional codec's= are not necessary here. However I think it would be helpful to have some non normative text describi= ng how the implementation of particular codec's would improve interoperabili= ty in specific environments (E.g. mobile) and although this could be left to= browser vendors to work out for themselves I don't think that is a good arg= ument for not doing it. We are here to promote interoperability after all. I also disagree that the MTI codec's already agreed are sufficient to ensure= interoperability with non RTCWEB environments which according to the rtcweb= charter should be considered. Regards Andy > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > Behalf Of Andrew Allen > Sent: 03 January 2013 17:25 > To: Harald Alvestrand; rtcweb@ietf.org > Subject: Re: [rtcweb] Call for Consensus Regarding Selecting > Recommended Audio Codecs > > I also support 2) > > I really don't think it helps much to describe what other codecs are > out there that you might want to think about implementing if you want > to interoperate with certain other non RTCweb deployments. I think > anybody who is seriously thinking about developing such a product can > easily find this out for themselves - if you want to interoperate with > 3GPP devices then take a look at the CURRENT 3GPP Codec specifications! > > It should be realized that the codec life cycle tends to be somewhat > shorter than that of the signaling technology so the codec information > is likely to become out of date long before the signaling > specifications become obsolete (possibly already dated by the time the > RFC is published) - 3GPP is already working on a new codec for LTE! > > As everyone has a favorite codec they would like to see deployed the > downside of this is that this will likely become a distraction that > generates a lot of discussion and consumes a lot of cycles that would > be better spent on addressing the basic interoperability issues facing > RTCweb. > > So I think the MTI audio codecs already agreed is enough to ensure > interoperability. > > Andrew > > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > Behalf Of Harald Alvestrand > Sent: Thursday, December 27, 2012 11:33 AM > To: rtcweb@ietf.org > Subject: Re: [rtcweb] Call for Consensus Regarding Selecting > Recommended Audio Codecs > > Speaking as an individual: > > I am putting my name on 2), because I believe RECOMMENDED is too strong > for secondary codecs. > > On 12/20/2012 09:29 AM, Magnus Westerlund wrote: > > WG, > > > > As an outcome of the Vancouver IETF meeting codec discussions we did > > promise to run a call for consensus regarding if the WG was > interested > > in specifying a small set of recommended audio codecs. We are sorry > > this has been delayed until now. > > > > The question for the call of consensus is between two options. > > > > 1) Run a process in the WG to select and specify a small set of > > audio/speech codecs that would be RECOMMNEDED to implement by a > WebRTC > > end-points > > > > 2) Do nothing and let the already specified Mandatory to Implement > > Audio codecs be the only audio codecs mentioned in the WebRTC > specification. > > > > Please indicate your position by January 16th 2013. > > > > Regards > > > > Magnus Westerlund > > > > --------------------------------------------------------------------- > - > > Multimedia Technologies, Ericsson Research EAB/TVM > > --------------------------------------------------------------------- > - > > Ericsson AB | Phone +46 10 7148287 > > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > > --------------------------------------------------------------------- > - > > > > _______________________________________________ > > 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 > > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential > information, privileged material (including material protected by the > solicitor-client or other applicable privileges), or constitute non- > public information. Any use of this information by anyone other than > the intended recipient is prohibited. If you have received this > transmission in error, please immediately reply to the sender and > delete this information from your system. Use, dissemination, > distribution, or reproduction of this transmission by unintended > recipients is not authorized and may be unlawful. > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From bernard_aboba@hotmail.com Sat Jan 12 12:24:15 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A49A21F873E for ; Sat, 12 Jan 2013 12:24:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.511 X-Spam-Level: X-Spam-Status: No, score=-102.511 tagged_above=-999 required=5 tests=[AWL=0.087, 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 xhqRB4L61lnk for ; Sat, 12 Jan 2013 12:24:14 -0800 (PST) Received: from blu0-omc4-s19.blu0.hotmail.com (blu0-omc4-s19.blu0.hotmail.com [65.55.111.158]) by ietfa.amsl.com (Postfix) with ESMTP id AD97121F86D3 for ; Sat, 12 Jan 2013 12:24:14 -0800 (PST) Received: from BLU002-W90 ([65.55.111.136]) by blu0-omc4-s19.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 12 Jan 2013 12:24:12 -0800 X-EIP: [Bjzdq0KbR7JNJWqVIfokJntHyx1NCSAD] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_0cb08a18-aa25-4ccc-820a-2814ce0e0e60_" From: Bernard Aboba To: Andrew Allen , "harald@alvestrand.no" , "rtcweb@ietf.org" Date: Sat, 12 Jan 2013 12:24:12 -0800 Importance: Normal In-Reply-To: References: <9F33F40F6F2CD847824537F3C4E37DDF013A1025@MCHP04MSX.global-ad.net>, MIME-Version: 1.0 X-OriginalArrivalTime: 12 Jan 2013 20:24:12.0209 (UTC) FILETIME=[C8A4E210:01CDF102] Subject: Re: [rtcweb] Call for Consensus Regarding Selecting Recommended 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, 12 Jan 2013 20:24:15 -0000 --_0cb08a18-aa25-4ccc-820a-2814ce0e0e60_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Andrew Allen said: > I really still don't see what the value is as part of RTCweb in describin= g the other codecs that are used by other VoIP and audio over IP and other = digital audio systems and the perceived pros and cons of each. [BA] I agree.=20 > I think this is a waste of time and a distraction from solving the real i= nteroperability issues like agreeing a common video codec and making sure J= SEP and SIP/SDP interoperate well together. [BA] Also agree that the WG can better spend its time on other things.=20 Onn reviewing the RFC 2119 definition and previous uses=2C I agree with Ada= m that the threshold for SHOULD is not met here:=20 3. SHOULD This word=2C or the adjective "RECOMMENDED"=2C mean that there= =0A= may exist valid reasons in particular circumstances to ignore a=0A= particular item=2C but the full implications must be understood and=0A= carefully weighed before choosing a different course.Since we have alrea= dy mandated support for G.711 and OPUS=2C other audio codecs such as G.722= are more "might be useful in some circumstances" category rather than the = "full implications must be understood" if not implementing. That's not a S= HOULD=2C it's a MAY. If we are only talking about a MAY there is little po= int in devoting time to the issue=2C since every codec other than G.711 and= OPUS would fall into that category. I especially would not want to delay = publication of documents while we haggle about the text to be associated wi= th various codecs.=20 Count me in favor of Option 2.=20 = --_0cb08a18-aa25-4ccc-820a-2814ce0e0e60_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Andrew Allen said:

<= div id=3D"SkyDrivePlaceholder">

>=3B I really still don't see wh= at the value is as part of RTCweb in describing the other codecs that are u= sed by other VoIP and audio over IP and other digital audio systems and the= perceived pros and cons of each.

[BA] I agree.

>=3B I thi= nk this is a waste of time and a distraction from solving the real interope= rability issues like agreeing a common video codec and making sure JSEP and= SIP/SDP interoperate well together.

[BA] Also agree that the WG can= better spend its time on other things.

Onn reviewing the RFC 2119 = definition and previous uses=2C I agree with Adam that the threshold for SH= OULD is not met here: 

3. SHOULD   This word=2C or the adjectiv=
e "RECOMMENDED"=2C mean that there=0A=
   may exist valid reasons in particular circumstances to ignore a=0A=
   particular item=2C but the full implications must be understood and=0A=
   carefully weighed before choosing a different course.
Since we have= already mandated support for G.711 and OPUS=2C =3B other audio codecs = such as G.722 are more "might be useful in some circumstances" category rat= her than the "full implications must be understood" if not implementing.&nb= sp=3B That's not a SHOULD=2C it's a MAY. =3B If we are only talking abo= ut a MAY there is little point in devoting time to the issue=2C since every= codec other than G.711 and OPUS would fall into that category. =3B I e= specially would not want to delay publication of documents while we haggle = about the text to be associated with various =3B codecs.

Count = me in favor of Option 2.






= --_0cb08a18-aa25-4ccc-820a-2814ce0e0e60_-- From dromasca@avaya.com Sun Jan 13 00:56:59 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A88E821F85E7 for ; Sun, 13 Jan 2013 00:56:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.918 X-Spam-Level: X-Spam-Status: No, score=-102.918 tagged_above=-999 required=5 tests=[AWL=-0.320, 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 eH1EfjDsF9E7 for ; Sun, 13 Jan 2013 00:56:58 -0800 (PST) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id CE84721F85D7 for ; Sun, 13 Jan 2013 00:56:57 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhoFAAEvoFDGmAcF/2dsb2JhbABEgX9KI8BpgQiCHgEBAQECARILEFELAgEIDQQEAQELHQcyFAkIAgQBEggah2IGAZ4wnAGRfmEDkkqJP4o2gm+CGQ X-IronPort-AV: E=Sophos;i="4.80,759,1344225600"; d="scan'208,217";a="44146115" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 13 Jan 2013 03:45:41 -0500 Received: from unknown (HELO AZ-FFEXHC01.global.avaya.com) ([135.64.58.11]) by co300216-co-erhwest-out.avaya.com with ESMTP; 13 Jan 2013 03:52:22 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC01.global.avaya.com ([135.64.58.11]) with mapi id 14.02.0318.004; Sun, 13 Jan 2013 03:57:06 -0500 From: "Romascanu, Dan (Dan)" To: Bernard Aboba , Andrew Allen , "harald@alvestrand.no" , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Call for Consensus Regarding Selecting Recommended Audio Codecs Thread-Index: AQHN5E/V+IaWIiAHjEiWJfuSRtT+RJg34eLQgAGL/4CADLWGA4AAbVwAgAB9AeA= Date: Sun, 13 Jan 2013 08:57:05 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA05F320@AZ-FFEXMB04.global.avaya.com> References: <9F33F40F6F2CD847824537F3C4E37DDF013A1025@MCHP04MSX.global-ad.net>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.45] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA05F320AZFFEXMB04globala_" MIME-Version: 1.0 Subject: Re: [rtcweb] Call for Consensus Regarding Selecting Recommended 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, 13 Jan 2013 08:56:59 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA05F320AZFFEXMB04globala_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I agree with Bernard's position here. Describing other codecs than the mand= atory ones with their pros and cons will not progress implementations or ad= option of RTCWeb. This will just confuse and complicate codec negotiation (= codec order etc) and will slow down the adoption of the mandatory codecs wh= ich already reached the WG consensus. I support option 2. Regards, Dan From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= Bernard Aboba Sent: Saturday, January 12, 2013 10:24 PM To: Andrew Allen; harald@alvestrand.no; rtcweb@ietf.org Subject: Re: [rtcweb] Call for Consensus Regarding Selecting Recommended Au= dio Codecs Andrew Allen said: > I really still don't see what the value is as part of RTCweb in describin= g the other codecs that are used by other VoIP and audio over IP and other = digital audio systems and the perceived pros and cons of each. [BA] I agree. > I think this is a waste of time and a distraction from solving the real i= nteroperability issues like agreeing a common video codec and making sure J= SEP and SIP/SDP interoperate well together. [BA] Also agree that the WG can better spend its time on other things. Onn reviewing the RFC 2119 definition and previous uses, I agree with Adam = that the threshold for SHOULD is not met here: 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. Since we have already mandated support for G.711 and OPUS, other audio cod= ecs such as G.722 are more "might be useful in some circumstances" category= rather than the "full implications must be understood" if not implementing= . That's not a SHOULD, it's a MAY. If we are only talking about a MAY the= re is little point in devoting time to the issue, since every codec other t= han G.711 and OPUS would fall into that category. I especially would not w= ant to delay publication of documents while we haggle about the text to be = associated with various codecs. Count me in favor of Option 2. --_000_9904FB1B0159DA42B0B887B7FA8119CA05F320AZFFEXMB04globala_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 <= /p>

I agree with Bernard̵= 7;s position here. Describing other codecs than the mandatory ones with the= ir pros and cons will not progress implementations or adoption of RTCWeb. This will just confuse and co= mplicate codec negotiation (codec order etc) and will slow down the adoptio= n of the mandatory codecs which already reached the WG consensus.

 <= /p>

I support option 2.

 <= /p>

Regards,

 <= /p>

Dan

 <= /p>

 <= /p>

 <= /p>

From: rtcweb-b= ounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Bernard Aboba
Sent: Saturday, January 12, 2013 10:24 PM
To: Andrew Allen; harald@alvestrand.no; rtcweb@ietf.org
Subject: Re: [rtcweb] Call for Consensus Regarding Selecting Recomme= nded Audio Codecs

 

Andrew Allen said:


> I really still don't see what the value is as part of RTCweb in descri= bing the other codecs that are used by other VoIP and audio over IP and oth= er digital audio systems and the perceived pros and cons of each.

[BA] I agree.

> I think this is a waste of time and a distraction from solving the rea= l interoperability issues like agreeing a common video codec and making sur= e JSEP and SIP/SDP interoperate well together.

[BA] Also agree that the WG can better spend its time on other things.

Onn reviewing the RFC 2119 definition and previous uses, I agree with Adam = that the threshold for SHOULD is not met here: 

3. SHOULD   This word, or the adjective "RECOMMENDED&qu=
ot;, mean that there
   may exist valid reasons in particular circumstances to ig=
nore a
   particular item, but the full implications must be unders=
tood and
   carefully weighed before choosing a different course.

Since we have already man= dated support for G.711 and OPUS,  other audio codecs such as G.722 ar= e more "might be useful in some circumstances" category rather than the "full implications must be understood" if not implement= ing.  That's not a SHOULD, it's a MAY.  If we are only talking ab= out a MAY there is little point in devoting time to the issue, since every = codec other than G.711 and OPUS would fall into that category.  I especially would not want to delay publication of docume= nts while we haggle about the text to be associated with various  code= cs.

Count me in favor of Option 2.





--_000_9904FB1B0159DA42B0B887B7FA8119CA05F320AZFFEXMB04globala_-- From shida@ntt-at.com Sun Jan 13 13:34:40 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 906A521F85CE for ; Sun, 13 Jan 2013 13:34:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.95 X-Spam-Level: X-Spam-Status: No, score=-101.95 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, SARE_MILLIONSOF=0.315, 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 4hFlBetwU-0I for ; Sun, 13 Jan 2013 13:34:40 -0800 (PST) Received: from gator465.hostgator.com (gator465.hostgator.com [69.56.174.130]) by ietfa.amsl.com (Postfix) with ESMTP id E36E221F84E6 for ; Sun, 13 Jan 2013 13:34:39 -0800 (PST) Received: from [107.25.22.208] (port=59325 helo=[192.168.0.32]) by gator465.hostgator.com with esmtpa (Exim 4.80) (envelope-from ) id 1TuVCQ-0006CY-Gd; Sun, 13 Jan 2013 15:34:39 -0600 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Shida Schubert In-Reply-To: Date: Sun, 13 Jan 2013 11:34:36 -1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <50D2CC6A.4090500@ericsson.com> <6515_1357907583_50F0067F_6515_1738_1_2842AD9A45C83B44B57635FD4831E60A0747CC@PEXCVZYM14.corporate.adroot.infra.ftgroup> To: Paul Coverdale X-Mailer: Apple Mail (2.1283) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator465.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ntt-at.com X-BWhitelist: yes X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([192.168.0.32]) [107.25.22.208]:59325 X-Source-Auth: shida.schubert+tingle.jp X-Email-Count: 1 X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQ2NS5ob3N0Z2F0b3IuY29t Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Call for Consensus Regarding Selecting Recommended 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, 13 Jan 2013 21:34:40 -0000 +1 On Jan 11, 2013, at 5:56 AM, Paul Coverdale wrote: > I support Stephane's proposal for option 1. It makes good sense, > particularly for the case where AMR and AMR-WB are already implemented = in > mobile devices - there are no additional licensing issues and it = simplifies > interoperability. >=20 > ...Paul >=20 >> -----Original Message----- >> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On = Behalf >> Of stephane.proust@orange.com >> Sent: Friday, January 11, 2013 7:33 AM >> To: Magnus Westerlund; rtcweb@ietf.org >> Subject: Re: [rtcweb] Call for Consensus Regarding Selecting = Recommended >> Audio Codecs >>=20 >> It is clear from the discussions on the rtcweb e-mail reflector that = the >> only additional codecs to be considered are limited to the following >> very small subset of 3 codecs: AMR, AMR-WB and G.722. >> In addition to G.711, these 3 codecs cover almost all legacy devices >> dedicated to voice services. They are consequently needed and = sufficient >> to be supported by WebRTC to make it an attractive and future proof >> technology for usage in all environments including mobile and for >> interoperability use cases with most of all legacy voice terminals. >>=20 >> AMR and AMR-WB are indeed the most widely supported voice codecs in >> hundreds of millions of legacy mobile devices. >> G.722 is royalty free (including a Packet Loss Concealment solution >> provided in ITU-T Software Tool Library) and is the codec used for HD >> Voice / DECT-Cat IQ fixed devices >>=20 >> Furthermore, considering that the reason for excluding AMR and AMR-WB >> from WebRTC was the licensing issue, there is no reason to NOT = support >> AMR-WB and AMR at WebRTC level if these codecs are already = implemented >> on the device. >>=20 >> Therefore I support option 1 and propose the following specification >> according this: >> AMR-WB, AMR and G.722 are RECOMMENDED TO IMPLEMENT by WebRTC = end-points >> AMR and AMR-WB MUST BE supported at WebRTC level by WebRTC end-points = on >> 3GPP mobile devices already implementing AMR and AMR-WB (*) >>=20 >> (*) note that the way these codecs are supported at RTC Web level is >> left open to implementors: either by a WebRTC specific software >> implementation of these codecs or by using APIs to access hardward >> implementation. >>=20 >>=20 >> -----Message d'origine----- >> De : rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] De la = part >> de Magnus Westerlund Envoy=E9 : jeudi 20 d=E9cembre 2012 09:30 =C0 : >> rtcweb@ietf.org Objet : [rtcweb] Call for Consensus Regarding = Selecting >> Recommended Audio Codecs >>=20 >> WG, >>=20 >> As an outcome of the Vancouver IETF meeting codec discussions we did >> promise to run a call for consensus regarding if the WG was = interested >> in specifying a small set of recommended audio codecs. We are sorry = this >> has been delayed until now. >>=20 >> The question for the call of consensus is between two options. >>=20 >> 1) Run a process in the WG to select and specify a small set of >> audio/speech codecs that would be RECOMMNEDED to implement by a = WebRTC >> end-points >>=20 >> 2) Do nothing and let the already specified Mandatory to Implement = Audio >> codecs be the only audio codecs mentioned in the WebRTC = specification. >>=20 >> Please indicate your position by January 16th 2013. >>=20 >> Regards >>=20 >> Magnus Westerlund >>=20 >> = ---------------------------------------------------------------------- >> Multimedia Technologies, Ericsson Research EAB/TVM >> = ---------------------------------------------------------------------- >> Ericsson AB | Phone +46 10 7148287 >> F=E4r=F6gatan 6 | Mobile +46 73 0949079 >> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com >> = ---------------------------------------------------------------------- >>=20 >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >>=20 >> = ________________________________________________________________________ >> _________________________________________________ >>=20 >> Ce message et ses pieces jointes peuvent contenir des informations >> confidentielles 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 electroniques etant susceptibles >> d'alteration, France Telecom - Orange decline toute responsabilite si = ce >> message a ete altere, deforme ou falsifie. Merci. >>=20 >> This message and its attachments may contain confidential or = privileged >> information 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 >> delete this message and its attachments. >> As emails may be altered, France Telecom - Orange is not liable for >> messages that have been modified, changed or falsified. >> Thank you. >>=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 R.Jesske@telekom.de Mon Jan 14 00:21:18 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD89E21F8862 for ; Mon, 14 Jan 2013 00:21:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.091 X-Spam-Level: X-Spam-Status: No, score=-3.091 tagged_above=-999 required=5 tests=[AWL=-0.157, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 gLts0jAgFt4Z for ; Mon, 14 Jan 2013 00:21:17 -0800 (PST) Received: from tcmail23.telekom.de (tcmail23.telekom.de [80.149.113.243]) by ietfa.amsl.com (Postfix) with ESMTP id 2C18721F885C for ; Mon, 14 Jan 2013 00:21:16 -0800 (PST) Received: from he111631.emea1.cds.t-internal.com ([10.134.93.23]) by tcmail21.telekom.de with ESMTP/TLS/AES128-SHA; 14 Jan 2013 09:21:15 +0100 Received: from HE111648.emea1.cds.t-internal.com ([10.134.93.17]) by HE111631.emea1.cds.t-internal.com ([::1]) with mapi; Mon, 14 Jan 2013 09:21:15 +0100 From: To: , Date: Mon, 14 Jan 2013 09:21:13 +0100 Thread-Topic: [rtcweb] Call for Consensus Regarding Selecting Recommended Audio Codecs Thread-Index: Ac3x1dKlpkFLgZ9ISsGCSu4hltCUAAAWiMZA Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D16813E56EC@HE111648.emea1.cds.t-internal.com> References: <50D2CC6A.4090500@ericsson.com> <6515_1357907583_50F0067F_6515_1738_1_2842AD9A45C83B44B57635FD4831E60A0747CC@PEXCVZYM14.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Call for Consensus Regarding Selecting Recommended 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: Mon, 14 Jan 2013 08:21:18 -0000 I also support Stephane's proposal. > -----Urspr=FCngliche Nachricht----- > Von: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] > Im Auftrag von Shida Schubert > Gesendet: Sonntag, 13. Januar 2013 22:35 > An: Paul Coverdale > Cc: rtcweb@ietf.org > Betreff: Re: [rtcweb] Call for Consensus Regarding Selecting > Recommended Audio Codecs > > > +1 > > On Jan 11, 2013, at 5:56 AM, Paul Coverdale wrote: > > > I support Stephane's proposal for option 1. It makes good sense, > > particularly for the case where AMR and AMR-WB are already > implemented > > in mobile devices - there are no additional licensing issues and it > > simplifies interoperability. > > > > ...Paul > > > >> -----Original Message----- > >> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > >> Behalf Of stephane.proust@orange.com > >> Sent: Friday, January 11, 2013 7:33 AM > >> To: Magnus Westerlund; rtcweb@ietf.org > >> Subject: Re: [rtcweb] Call for Consensus Regarding Selecting > >> Recommended Audio Codecs > >> > >> It is clear from the discussions on the rtcweb e-mail > reflector that > >> the only additional codecs to be considered are limited to the > >> following very small subset of 3 codecs: AMR, AMR-WB and G.722. > >> In addition to G.711, these 3 codecs cover almost all > legacy devices > >> dedicated to voice services. They are consequently needed and > >> sufficient to be supported by WebRTC to make it an attractive and > >> future proof technology for usage in all environments including > >> mobile and for interoperability use cases with most of all > legacy voice terminals. > >> > >> AMR and AMR-WB are indeed the most widely supported voice > codecs in > >> hundreds of millions of legacy mobile devices. > >> G.722 is royalty free (including a Packet Loss Concealment > solution > >> provided in ITU-T Software Tool Library) and is the codec > used for HD > >> Voice / DECT-Cat IQ fixed devices > >> > >> Furthermore, considering that the reason for excluding AMR > and AMR-WB > >> from WebRTC was the licensing issue, there is no reason to NOT > >> support AMR-WB and AMR at WebRTC level if these codecs are already > >> implemented on the device. > >> > >> Therefore I support option 1 and propose the following > specification > >> according this: > >> AMR-WB, AMR and G.722 are RECOMMENDED TO IMPLEMENT by WebRTC > >> end-points AMR and AMR-WB MUST BE supported at WebRTC > level by WebRTC > >> end-points on 3GPP mobile devices already implementing AMR > and AMR-WB > >> (*) > >> > >> (*) note that the way these codecs are supported at RTC > Web level is > >> left open to implementors: either by a WebRTC specific software > >> implementation of these codecs or by using APIs to access hardward > >> implementation. > >> > >> > >> -----Message d'origine----- > >> De : rtcweb-bounces@ietf.org > [mailto:rtcweb-bounces@ietf.org] De la > >> part de Magnus Westerlund Envoy=E9 : jeudi 20 d=E9cembre 2012 09:30 = =C0 : > >> rtcweb@ietf.org Objet : [rtcweb] Call for Consensus Regarding > >> Selecting Recommended Audio Codecs > >> > >> WG, > >> > >> As an outcome of the Vancouver IETF meeting codec > discussions we did > >> promise to run a call for consensus regarding if the WG was > >> interested in specifying a small set of recommended audio > codecs. We > >> are sorry this has been delayed until now. > >> > >> The question for the call of consensus is between two options. > >> > >> 1) Run a process in the WG to select and specify a small set of > >> audio/speech codecs that would be RECOMMNEDED to implement by a > >> WebRTC end-points > >> > >> 2) Do nothing and let the already specified Mandatory to Implement > >> Audio codecs be the only audio codecs mentioned in the > WebRTC specification. > >> > >> Please indicate your position by January 16th 2013. > >> > >> Regards > >> > >> Magnus Westerlund > >> > >> > --------------------------------------------------------------------- > >> - Multimedia Technologies, Ericsson Research EAB/TVM > >> > ---------------------------------------------------------------------- > >> Ericsson AB | Phone +46 10 7148287 > >> F=E4r=F6gatan 6 | Mobile +46 73 0949079 > >> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > >> > --------------------------------------------------------------------- > >> - > >> > >> _______________________________________________ > >> rtcweb mailing list > >> rtcweb@ietf.org > >> https://www.ietf.org/mailman/listinfo/rtcweb > >> > >> > _____________________________________________________________________ > >> ___ _________________________________________________ > >> > >> Ce message et ses pieces jointes peuvent contenir des informations > >> confidentielles 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 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 information 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 delete this message and its attachments. > >> As emails may be altered, France Telecom - Orange is not > liable for > >> messages that have been modified, changed or falsified. > >> Thank you. > >> > >> _______________________________________________ > >> 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 tim@phonefromhere.com Mon Jan 14 03:22:49 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E84A21F84CA for ; Mon, 14 Jan 2013 03:22:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.284 X-Spam-Level: X-Spam-Status: No, score=-2.284 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 qn9LfzdXnhNr for ; Mon, 14 Jan 2013 03:22:48 -0800 (PST) Received: from smtp003.apm-internet.net (smtp003.apm-internet.net [85.119.248.52]) by ietfa.amsl.com (Postfix) with ESMTP id 30BB221F84C9 for ; Mon, 14 Jan 2013 03:22:47 -0800 (PST) Received: (qmail 57944 invoked from network); 14 Jan 2013 11:22:45 -0000 X-AV-Scan: clean Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp003.apm-internet.net with SMTP; 14 Jan 2013 11:22:45 -0000 Received: from [192.67.4.33] (unknown [192.67.4.33]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id 71DB318A0B0A; Mon, 14 Jan 2013 11:22:45 +0000 (GMT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Tim Panton In-Reply-To: <6515_1357907583_50F0067F_6515_1738_1_2842AD9A45C83B44B57635FD4831E60A0747CC@PEXCVZYM14.corporate.adroot.infra.ftgroup> Date: Mon, 14 Jan 2013 11:22:44 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <161DAF1D-E35A-4D75-9155-18E70F66EE77@phonefromhere.com> References: <50D2CC6A.4090500@ericsson.com> <6515_1357907583_50F0067F_6515_1738_1_2842AD9A45C83B44B57635FD4831E60A0747CC@PEXCVZYM14.corporate.adroot.infra.ftgroup> To: X-Mailer: Apple Mail (2.1283) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Call for Consensus Regarding Selecting Recommended 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: Mon, 14 Jan 2013 11:22:49 -0000 On 11 Jan 2013, at 12:33, = wrote: > It is clear from the discussions on the rtcweb e-mail reflector that = the only additional codecs to be considered are limited to the following = very small subset of 3 codecs: AMR, AMR-WB and G.722.=20 > In addition to G.711, these 3 codecs cover almost all legacy devices = dedicated to voice services. They are consequently needed and sufficient = to be supported by WebRTC to make it an attractive and future proof = technology for usage in all environments including mobile and for = interoperability use cases with most of all legacy voice terminals. >=20 > AMR and AMR-WB are indeed the most widely supported voice codecs in = hundreds of millions of legacy mobile devices. > G.722 is royalty free (including a Packet Loss Concealment solution = provided in ITU-T Software Tool Library) and is the codec used for HD = Voice / DECT-Cat IQ fixed devices >=20 > Furthermore, considering that the reason for excluding AMR and AMR-WB = from WebRTC was the licensing issue, there is no reason to NOT support = AMR-WB and AMR at WebRTC level if these codecs are already implemented = on the device. >=20 > Therefore I support option 1 and propose the following specification = according this: > AMR-WB, AMR and G.722 are RECOMMENDED TO IMPLEMENT by WebRTC = end-points > AMR and AMR-WB MUST BE supported at WebRTC level by WebRTC end-points = on 3GPP mobile devices already implementing AMR and AMR-WB (*) >=20 > (*) note that the way these codecs are supported at RTC Web level is = left open to implementors: either by a WebRTC specific software = implementation of these codecs or by using APIs to access hardward = implementation.=20 I'm against this sort of statement in general, it only serves to = fragment the webRTC landscape. If we do end up making this sort of statement it needs to say: "AMR and AMR-WB MUST BE supported at WebRTC level by WebRTC end-points = on 3GPP mobile devices already implementing AMR and AMR-WB provided no = additional license or agreements are needed for their use in this way." The point being that just because the codec is in the silicon, it does = not mean it is licensed for just any use, the license may be limited by = channel count or direction. (I've seen phones where AMR decode is = permitted but not encode). I strongly encourage anyone who wants to mandate g722 to make a call = over 722 from their laptop in starbucks before dragging rtcWEB back a = decade or two. Tim. From roman@telurix.com Mon Jan 14 03:29:36 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7865221F85FD for ; Mon, 14 Jan 2013 03:29:36 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8amtwCs2doyQ for ; Mon, 14 Jan 2013 03:29:35 -0800 (PST) Received: from mail-wg0-f54.google.com (mail-wg0-f54.google.com [74.125.82.54]) by ietfa.amsl.com (Postfix) with ESMTP id 4ABA221F858A for ; Mon, 14 Jan 2013 03:29:35 -0800 (PST) Received: by mail-wg0-f54.google.com with SMTP id fg15so2012927wgb.9 for ; Mon, 14 Jan 2013 03:29:34 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=TxnQnkkSfT25+pmG6FMIygCl1+mUwCemTnGlZUQic/c=; b=UilfhZuQAZKFbnavT+3YTAtRpeTMel1TGT3EoSbRC2RXmCTDwv6yCg/La65e7+AxrS 4o3whB/Okt2QOAdmT7jsD5v+8s4oz+Vv7Xo7HpC4WrRxTBKxLW0bmTIag7g5LcSHP6UT kcrdkBxNkczuuX1b1Af3Ew9nhBlUawNK/gIoc9vpNam0oA1yZ8B0W20qHxpONwl3Nqqk PGfiZKUiPUOWSYXRipQqo7LPYD7klEuU7mg7EGPvQOJobYvXBhY8cZ23hPvBDzKBBPhv uk3WtniQh3eAzCsX3aq0cUF9+liYWycSnItijDpG8HB+894imVo5SOPtNP9WtQ8jvrVp AePw== X-Received: by 10.180.86.39 with SMTP id m7mr11828096wiz.1.1358162974437; Mon, 14 Jan 2013 03:29:34 -0800 (PST) Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) by mx.google.com with ESMTPS id hu8sm12340862wib.6.2013.01.14.03.29.32 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 14 Jan 2013 03:29:33 -0800 (PST) Received: by mail-wi0-f176.google.com with SMTP id hm6so1166842wib.9 for ; Mon, 14 Jan 2013 03:29:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.180.82.41 with SMTP id f9mr11741792wiy.25.1358162971427; Mon, 14 Jan 2013 03:29:31 -0800 (PST) Received: by 10.216.16.134 with HTTP; Mon, 14 Jan 2013 03:29:31 -0800 (PST) In-Reply-To: <161DAF1D-E35A-4D75-9155-18E70F66EE77@phonefromhere.com> References: <50D2CC6A.4090500@ericsson.com> <6515_1357907583_50F0067F_6515_1738_1_2842AD9A45C83B44B57635FD4831E60A0747CC@PEXCVZYM14.corporate.adroot.infra.ftgroup> <161DAF1D-E35A-4D75-9155-18E70F66EE77@phonefromhere.com> Date: Mon, 14 Jan 2013 06:29:31 -0500 Message-ID: From: Roman Shpount To: Tim Panton Content-Type: multipart/alternative; boundary=f46d041826e67583bc04d33df556 X-Gm-Message-State: ALoCoQmjHZuYA/QxnUKC6YMQ6PK/Z4TcCXN44aCJmG10q888Dy4XqBdObnVgOwLmcqiEN4ELd76G Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Call for Consensus Regarding Selecting Recommended 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: Mon, 14 Jan 2013 11:29:36 -0000 --f46d041826e67583bc04d33df556 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jan 14, 2013 at 6:22 AM, Tim Panton wrote: > I strongly encourage anyone who wants to mandate g722 to make a call over > 722 from their laptop in starbucks before dragging rtcWEB back a decade or > two. I am doing this regularly. With good jitter buffer and PLC implementation it sounds great. _____________ Roman Shpount --f46d041826e67583bc04d33df556 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Jan 14, 2013 at 6:22 AM, Tim Panton = <tim@phonefromhere.com> wrote:
I strongly encourage anyone who wants to mandate g722 to make a call over 7= 22 from their laptop in starbucks before dragging rtcWEB back a decade or t= wo.

I am doing this regularly. With good jitter buffe= r and PLC implementation it sounds great.
_____________
Roman Shpount
--f46d041826e67583bc04d33df556-- From bernard_aboba@hotmail.com Mon Jan 14 06:34:45 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA82C21F88B2 for ; Mon, 14 Jan 2013 06:34:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.528 X-Spam-Level: X-Spam-Status: No, score=-102.528 tagged_above=-999 required=5 tests=[AWL=0.070, 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 o+CS-sR-xCSm for ; Mon, 14 Jan 2013 06:34:45 -0800 (PST) Received: from blu0-omc2-s33.blu0.hotmail.com (blu0-omc2-s33.blu0.hotmail.com [65.55.111.108]) by ietfa.amsl.com (Postfix) with ESMTP id 1CA0621F888E for ; Mon, 14 Jan 2013 06:34:45 -0800 (PST) Received: from BLU002-W63 ([65.55.111.71]) by blu0-omc2-s33.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 14 Jan 2013 06:34:34 -0800 X-EIP: [0SCFNffhdtebqvpqNBM1/hXY1mCV1yUa] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_6c7d0852-319f-43ba-b9fe-26a9bd3f05d1_" From: Bernard Aboba To: "stephane.proust@orange.com" Date: Mon, 14 Jan 2013 06:34:34 -0800 Importance: Normal In-Reply-To: <161DAF1D-E35A-4D75-9155-18E70F66EE77@phonefromhere.com> References: <50D2CC6A.4090500@ericsson.com>, <6515_1357907583_50F0067F_6515_1738_1_2842AD9A45C83B44B57635FD4831E60A0747CC@PEXCVZYM14.corporate.adroot.infra.ftgroup>, <161DAF1D-E35A-4D75-9155-18E70F66EE77@phonefromhere.com> MIME-Version: 1.0 X-OriginalArrivalTime: 14 Jan 2013 14:34:34.0650 (UTC) FILETIME=[45DEE7A0:01CDF264] Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Call for Consensus Regarding Selecting Recommended 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: Mon, 14 Jan 2013 14:34:45 -0000 --_6c7d0852-319f-43ba-b9fe-26a9bd3f05d1_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Stephane said: "In addition to G.711=2C these 3 codecs cover almost all legacy devices ded= icated to voice services. They are consequently needed and sufficient to be= supported by WebRTC to make it an attractive and future proof technology" [BA] The use of the terms "legacy" and "future proof" here is puzzling. "= Future proof" would seem to imply the ability to adapt to future developmen= ts=2C whereas "legacy" relates to compatibility with what has gone before. = Unless the "past" is the same as the "future" (which implies no progress = at all)=2C those two objectives are distinct (and possibly conflicting). = --_6c7d0852-319f-43ba-b9fe-26a9bd3f05d1_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Stephane said:

"In additi= on to G.711=2C these 3 codecs cover almost all legacy devices dedicated to = voice services. They are consequently needed and sufficient to be supported= by WebRTC to make it an attractive and future proof technology"

[BA= ] The use of the terms "legacy" and "future proof" here is puzzling. = =3B =3B "Future proof" would seem to imply the ability to adapt to futu= re developments=2C whereas "legacy" relates to compatibility with what has = gone before. =3B =3B Unless the "past" is the same as the "future" = (which implies no progress at all)=2C those two objectives are distinct (an= d possibly conflicting).




= --_6c7d0852-319f-43ba-b9fe-26a9bd3f05d1_-- From tireddy@cisco.com Mon Jan 14 06:35:45 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60BD721F8803 for ; Mon, 14 Jan 2013 06:35:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 aaGdJldc50CO for ; Mon, 14 Jan 2013 06:35:44 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 7092421F89B9 for ; Mon, 14 Jan 2013 06:35:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10296; q=dns/txt; s=iport; t=1358174144; x=1359383744; h=from:to:cc:subject:date:message-id:mime-version; bh=UyOJUAfGqTlSKNmw/2W40Jf3dTXnOWZoNeXGn6da74E=; b=XjCpAnMRt/hyDYWIKjtOozueHw9Uh5ktp8gGFDK5a8YiwfRe+57AmBTo sgOUtoXT/Y3kCuKaiotCFSB3duQ8QPuQ4lW3TFlZYxlN+y2X/14HXT0d4 kaEJ2cSNam9NSlIxBV1gsrLBsSlyi992fZt2DFIAdy9I53ek71hP6UZkv Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiMFAJQW9FCtJV2c/2dsb2JhbABEgkiDcq4gAYgudhZzgh4BAQEEIwpKAgwGAQgRBAEBCx0DAgQwFAcBAQUFBA4FCAGIEAykRJAhkBsyYQOXJ48tgnWCJA X-IronPort-AV: E=Sophos;i="4.84,468,1355097600"; d="scan'208,217";a="162138866" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-5.cisco.com with ESMTP; 14 Jan 2013 14:35:35 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r0EEZZkn029717 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 14 Jan 2013 14:35:35 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.229]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0318.004; Mon, 14 Jan 2013 08:35:34 -0600 From: "Tirumaleswar Reddy (tireddy)" To: "rtcweb@ietf.org" Thread-Topic: New Version Notification for draft-reddy-rtcweb-mobile-00.txt Thread-Index: AQHN8i6P0JlBJStRlku4X+YQ5S8cZZhIyWCw Date: Mon, 14 Jan 2013 14:35:33 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A148E07CB@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.76.13] Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A148E07CBxmbrcdx10ciscoc_" MIME-Version: 1.0 Cc: John Kaippallimalil , "bpatil@ovi.com" Subject: [rtcweb] FW: New Version Notification for draft-reddy-rtcweb-mobile-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: Mon, 14 Jan 2013 14:35:45 -0000 --_000_913383AAA69FF945B8F946018B75898A148E07CBxmbrcdx10ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgYWxsLCcNCg0KDQoNClRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGEgc2V0IG9mIHNjZW5hcmlv cyBpbiB3aGljaCBXZWJSVEMgYXBwbGljYXRpb25zIGhhdmUgcHJvYmxlbXMgaW4gTW9iaWxlIE5l dHdvcmtzIHJlbGF0ZWQgdG8gUU9TLCBNb2JpbGl0eSAoU0lQVE8pLiBUaGFua3MgdG8gTWFnbnVz LCBNYXJrdXMsIERhbiBhbmQgQmFzYXZyYWogZm9yIHRoZWlyIGhlbHAgYW5kIGNvbW1lbnRzLiBU aGUgVVJMIG9mIHRoZSBuZXcgZHJhZnQ6DQoNCg0KDQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1yZWRkeS1ydGN3ZWItbW9iaWxlLTAwDQoNCg0KDQpjb21tZW50cyBhbmQgc3VnZ2Vz dGlvbnMgYXJlIHdlbGNvbWUuDQoNCg0KDQpCZXN0IFJlZ2FyZHMsDQoNCi0tYXV0aG9ycy4NCg0K DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0 Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddDQpTZW50OiBNb25kYXksIEph bnVhcnkgMTQsIDIwMTMgMTo0MCBQTQ0KVG86IFRpcnVtYWxlc3dhciBSZWRkeSAodGlyZWRkeSkN CkNjOiBqb2huLmthaXBwYWxsaW1hbGlsQGh1YXdlaS5jb207IFJhbSBNb2hhbiBSIChybW9oYW5y KQ0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1yZWRkeS1ydGN3 ZWItbW9iaWxlLTAwLnR4dA0KDQoNCg0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1y ZWRkeS1ydGN3ZWItbW9iaWxlLTAwLnR4dA0KDQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0 dGVkIGJ5IFRpcnVtYWxlc3dhciBSZWRkeSBhbmQgcG9zdGVkIHRvIHRoZQ0KDQpJRVRGIHJlcG9z aXRvcnkuDQoNCg0KDQpGaWxlbmFtZTogICBkcmFmdC1yZWRkeS1ydGN3ZWItbW9iaWxlDQoNClJl dmlzaW9uOiAgIDAwDQoNClRpdGxlOiAgICAgICAgICAgIFByb2JsZW1zIHdpdGggV2ViUlRDIGlu IE1vYmlsZSBOZXR3b3Jrcw0KDQpDcmVhdGlvbiBkYXRlOiAgICAyMDEzLTAxLTE0DQoNCldHIElE OiAgICAgICAgICAgIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KDQpOdW1iZXIgb2YgcGFnZXM6IDE0 DQoNClVSTDogICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMv ZHJhZnQtcmVkZHktcnRjd2ViLW1vYmlsZS0wMC50eHQNCg0KU3RhdHVzOiAgICAgICAgICBodHRw Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXJlZGR5LXJ0Y3dlYi1tb2JpbGUNCg0K SHRtbGl6ZWQ6ICAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1yZWRkeS1y dGN3ZWItbW9iaWxlLTAwDQoNCg0KDQoNCg0KQWJzdHJhY3Q6DQoNCiAgIFRoaXMgZG9jdW1lbnQg ZGVzY3JpYmVzIGEgc2V0IG9mIHNjZW5hcmlvcyBpbiB3aGljaCBXZWJSVEMNCg0KICAgYXBwbGlj YXRpb25zIGhhdmUgcHJvYmxlbXMgaW4gTW9iaWxlIE5ldHdvcmtzLg0KDQoNCg0KDQoNCg0KDQoN Cg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0KDQo= --_000_913383AAA69FF945B8F946018B75898A148E07CBxmbrcdx10ciscoc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl Pg0KPCEtLQ0KIC8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCiBAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZv bnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q29uc29sYXM7DQoJcGFub3NlLTE6 MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KIC8qIFN0eWxlIERlZmluaXRpb25zICovDQogcC5Nc29O b3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdp bi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l O30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0K cC5Nc29QbGFpblRleHQsIGxpLk1zb1BsYWluVGV4dCwgZGl2Lk1zb1BsYWluVGV4dA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQgQ2hhciI7DQoJ bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjVwdDsN Cglmb250LWZhbWlseTpDb25zb2xhczt9DQpzcGFuLlBsYWluVGV4dENoYXINCgl7bXNvLXN0eWxl LW5hbWU6IlBsYWluIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z dHlsZS1saW5rOiJQbGFpbiBUZXh0IjsNCglmb250LWZhbWlseTpDb25zb2xhczt9DQouTXNvQ2hw RGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBTZWN0aW9uMQ0K CXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0K ZGl2LlNlY3Rpb24xDQoJe3BhZ2U6U2VjdGlvbjE7fQ0KLS0+DQo8L3N0eWxlPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KIDxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEw MjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCiA8bzpz aGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQogIDxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIx IiAvPg0KIDwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5 IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IlNl Y3Rpb24xIj4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkhpIGFsbCwnPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPlRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGEgc2V0IG9mIHNjZW5hcmlv cyBpbiB3aGljaCBXZWJSVEMgYXBwbGljYXRpb25zIGhhdmUgcHJvYmxlbXMgaW4gTW9iaWxlIE5l dHdvcmtzIHJlbGF0ZWQgdG8gUU9TLCBNb2JpbGl0eSAoU0lQVE8pLiBUaGFua3MgdG8gTWFnbnVz LCBNYXJrdXMsIERhbiBhbmQgQmFzYXZyYWogZm9yIHRoZWlyIGhlbHAgYW5kIGNvbW1lbnRzLiBU aGUgVVJMIG9mIHRoZSBuZXcgZHJhZnQ6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxh IGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXJlZGR5LXJ0Y3dlYi1tb2Jp bGUtMDAiPmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXJlZGR5LXJ0Y3dlYi1tb2Jp bGUtMDA8L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPmNvbW1lbnRzIGFuZCBzdWdn ZXN0aW9ucyBhcmUgd2VsY29tZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+QmVzdCBS ZWdhcmRzLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+LS1hdXRob3Jz LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LTxicj4NCkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRy YWZ0c0BpZXRmLm9yZ10gPGJyPg0KU2VudDogTW9uZGF5LCBKYW51YXJ5IDE0LCAyMDEzIDE6NDAg UE08YnI+DQpUbzogVGlydW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5KTxicj4NCkNjOiBqb2huLmth aXBwYWxsaW1hbGlsQGh1YXdlaS5jb207IFJhbSBNb2hhbiBSIChybW9oYW5yKTxicj4NClN1Ympl Y3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtcmVkZHktcnRjd2ViLW1vYmls ZS0wMC50eHQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5BIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQt cmVkZHktcnRjd2ViLW1vYmlsZS0wMC50eHQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgVGlydW1hbGVzd2Fy IFJlZGR5IGFuZCBwb3N0ZWQgdG8gdGhlPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij5JRVRGIHJlcG9zaXRvcnkuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkZp bGVuYW1lOiZuYnNwOyZuYnNwOyBkcmFmdC1yZWRkeS1ydGN3ZWItbW9iaWxlPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5SZXZpc2lvbjombmJzcDsmbmJzcDsgMDA8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlRpdGxlOiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBQcm9i bGVtcyB3aXRoIFdlYlJUQyBpbiBNb2JpbGUgTmV0d29ya3M8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPkNyZWF0aW9uIGRhdGU6Jm5ic3A7Jm5ic3A7Jm5ic3A7IDIwMTMt MDEtMTQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPldHIElEOiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBJbmRpdmlkdWFsIFN1Ym1pc3Npb248bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPk51bWJlciBvZiBwYWdlczogMTQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPlVSTDombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRl cm5ldC1kcmFmdHMvZHJhZnQtcmVkZHktcnRjd2ViLW1vYmlsZS0wMC50eHQ8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlN0YXR1czombmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaHR0cDovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9kcmFmdC1yZWRkeS1ydGN3ZWItbW9iaWxlPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij5IdG1saXplZDombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcmVkZHktcnRjd2Vi LW1vYmlsZS0wMDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkFic3RyYWN0OjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IFRoaXMgZG9jdW1lbnQgZGVzY3Jp YmVzIGEgc2V0IG9mIHNjZW5hcmlvcyBpbiB3aGljaCBXZWJSVEM8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyBhcHBsaWNhdGlvbnMgaGF2ZSBwcm9i bGVtcyBpbiBNb2JpbGUgTmV0d29ya3MuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+VGhlIElF VEYgU2VjcmV0YXJpYXQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_913383AAA69FF945B8F946018B75898A148E07CBxmbrcdx10ciscoc_-- From adam@nostrum.com Mon Jan 14 07:00:41 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 488B121F8935 for ; Mon, 14 Jan 2013 07:00:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.797 X-Spam-Level: X-Spam-Status: No, score=-101.797 tagged_above=-999 required=5 tests=[AWL=-0.804, BAYES_00=-2.599, MISSING_HEADERS=1.292, SARE_MILLIONSOF=0.315, SPF_PASS=-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 kovj9JU0In5E for ; Mon, 14 Jan 2013 07:00:40 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 4180B21F88AC for ; Mon, 14 Jan 2013 07:00:40 -0800 (PST) Received: from Orochi.local (99-152-144-32.lightspeed.dllstx.sbcglobal.net [99.152.144.32]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r0EF0dfj076879 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 14 Jan 2013 09:00:39 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <50F41D97.1030508@nostrum.com> Date: Mon, 14 Jan 2013 09:00:39 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 CC: rtcweb@ietf.org References: <50D2CC6A.4090500@ericsson.com> <6515_1357907583_50F0067F_6515_1738_1_2842AD9A45C83B44B57635FD4831E60A0747CC@PEXCVZYM14.corporate.adroot.infra.ftgroup> <580BEA5E3B99744AB1F5BFF5E9A3C67D16813E56EC@HE111648.emea1.cds.t-internal.com> In-Reply-To: <580BEA5E3B99744AB1F5BFF5E9A3C67D16813E56EC@HE111648.emea1.cds.t-internal.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Received-SPF: pass (nostrum.com: 99.152.144.32 is authenticated by a trusted mechanism) Subject: [rtcweb] Consensus vs. Voting (was Re: Call for Consensus Regarding Selecting Recommended 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: Mon, 14 Jan 2013 15:00:41 -0000 This thread has been going on for quite some time now, and I wouldn't be surprised if there is some pressure for the chairs to call consensus in the next week or two. I know it's tempting to think they might simply grab the relevant messages and tally the support for each position, calling the issue for those with the larger number of proponents. In short, simple majority voting. Many bodies work this way -- governments, corporations, and other SDOs, just to name a few. We don't. As Dave Crocker[1] is fond of pointing out, it is possible to have 99 people in support of a position and one standing against, and still fail to meet the IETF's standard for "rough consensus." All it takes is the failure of those 99 people to engage the arguments put forth by the one outlier. Correspondingly, you can have 50 people on one side of an issue, 50 on the other, and still have a clear consensus if one side is merely stating a position, while the other is offering up unanswered arguments. To be clear, I'm not saying that "+1" is never a valid response when attempting to reach consensus. However, it does not, in and of itself, comprise a counter-argument to points raised by supporters of the opposing position. To the issue at hand: roughly grouping those proponents of option 1 into one voice (A), and those boosting option 2 in to another (B), the conversation so far can be roughly summarized as: A: We'd like to see SHOULD-level support for codecs x, y, and/or z because gee, wouldn't it be nice? B: "Wouldn't it be nice" doesn't meet the criteria for RFC 2119 SHOULD. A: *crickets* [time passes] A: We'd like to see SHOULD-level support for codecs x, y, and/or z because gee, wouldn't it be nice? B: "Wouldn't it be nice" doesn't meet the criteria for RFC 2119 SHOULD. A: *crickets* That's the _exact_ kind of failure to engage that I would expect would cause experienced chairs to call clear consensus for supporters of option 2. This isn't a vote, it's a discussion, and discussions need to go beyond blindly repeating your opening arguments. If you have any interest in option 1 being considered further, you need to listen and respond to the opposing position. /a [1] For those of you unfamiliar with Dave Crocker's tenure in the IETF, I call your attention to the date and attendee list on the following proceedings: http://www.ietf.org/proceedings/04.pdf On 1/14/13 02:21, R.Jesske@telekom.de wrote: > I also support Stephane's proposal. > > >> -----Ursprüngliche Nachricht----- >> Von: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] >> Im Auftrag von Shida Schubert >> Gesendet: Sonntag, 13. Januar 2013 22:35 >> An: Paul Coverdale >> Cc: rtcweb@ietf.org >> Betreff: Re: [rtcweb] Call for Consensus Regarding Selecting >> Recommended Audio Codecs >> >> >> +1 >> >> On Jan 11, 2013, at 5:56 AM, Paul Coverdale wrote: >> >>> I support Stephane's proposal for option 1. It makes good sense, >>> particularly for the case where AMR and AMR-WB are already >> implemented >>> in mobile devices - there are no additional licensing issues and it >>> simplifies interoperability. >>> >>> ...Paul >>> >>>> -----Original Message----- >>>> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On >>>> Behalf Of stephane.proust@orange.com >>>> Sent: Friday, January 11, 2013 7:33 AM >>>> To: Magnus Westerlund; rtcweb@ietf.org >>>> Subject: Re: [rtcweb] Call for Consensus Regarding Selecting >>>> Recommended Audio Codecs >>>> >>>> It is clear from the discussions on the rtcweb e-mail >> reflector that >>>> the only additional codecs to be considered are limited to the >>>> following very small subset of 3 codecs: AMR, AMR-WB and G.722. >>>> In addition to G.711, these 3 codecs cover almost all >> legacy devices >>>> dedicated to voice services. They are consequently needed and >>>> sufficient to be supported by WebRTC to make it an attractive and >>>> future proof technology for usage in all environments including >>>> mobile and for interoperability use cases with most of all >> legacy voice terminals. >>>> AMR and AMR-WB are indeed the most widely supported voice >> codecs in >>>> hundreds of millions of legacy mobile devices. >>>> G.722 is royalty free (including a Packet Loss Concealment >> solution >>>> provided in ITU-T Software Tool Library) and is the codec >> used for HD >>>> Voice / DECT-Cat IQ fixed devices >>>> >>>> Furthermore, considering that the reason for excluding AMR >> and AMR-WB >>>> from WebRTC was the licensing issue, there is no reason to NOT >>>> support AMR-WB and AMR at WebRTC level if these codecs are already >>>> implemented on the device. >>>> >>>> Therefore I support option 1 and propose the following >> specification >>>> according this: >>>> AMR-WB, AMR and G.722 are RECOMMENDED TO IMPLEMENT by WebRTC >>>> end-points AMR and AMR-WB MUST BE supported at WebRTC >> level by WebRTC >>>> end-points on 3GPP mobile devices already implementing AMR >> and AMR-WB >>>> (*) >>>> >>>> (*) note that the way these codecs are supported at RTC >> Web level is >>>> left open to implementors: either by a WebRTC specific software >>>> implementation of these codecs or by using APIs to access hardward >>>> implementation. >>>> >>>> >>>> -----Message d'origine----- >>>> De : rtcweb-bounces@ietf.org >> [mailto:rtcweb-bounces@ietf.org] De la >>>> part de Magnus Westerlund Envoyé : jeudi 20 décembre 2012 09:30 Ŕ : >>>> rtcweb@ietf.org Objet : [rtcweb] Call for Consensus Regarding >>>> Selecting Recommended Audio Codecs >>>> >>>> WG, >>>> >>>> As an outcome of the Vancouver IETF meeting codec >> discussions we did >>>> promise to run a call for consensus regarding if the WG was >>>> interested in specifying a small set of recommended audio >> codecs. We >>>> are sorry this has been delayed until now. >>>> >>>> The question for the call of consensus is between two options. >>>> >>>> 1) Run a process in the WG to select and specify a small set of >>>> audio/speech codecs that would be RECOMMNEDED to implement by a >>>> WebRTC end-points >>>> >>>> 2) Do nothing and let the already specified Mandatory to Implement >>>> Audio codecs be the only audio codecs mentioned in the >> WebRTC specification. >>>> Please indicate your position by January 16th 2013. >>>> >>>> Regards >>>> >>>> Magnus Westerlund >>>> >>>> >> --------------------------------------------------------------------- >>>> - Multimedia Technologies, Ericsson Research EAB/TVM >>>> >> ---------------------------------------------------------------------- >>>> Ericsson AB | Phone +46 10 7148287 >>>> Färögatan 6 | Mobile +46 73 0949079 >>>> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com >>>> >> --------------------------------------------------------------------- >>>> - >>>> >>>> _______________________________________________ >>>> rtcweb mailing list >>>> rtcweb@ietf.org >>>> https://www.ietf.org/mailman/listinfo/rtcweb >>>> >>>> >> _____________________________________________________________________ >>>> ___ _________________________________________________ >>>> >>>> Ce message et ses pieces jointes peuvent contenir des informations >>>> confidentielles 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 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 information 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 delete this message and its attachments. >>>> As emails may be altered, France Telecom - Orange is not >> liable for >>>> messages that have been modified, changed or falsified. >>>> Thank you. >>>> >>>> _______________________________________________ >>>> 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 roman@telurix.com Mon Jan 14 07:21:15 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DE8221F8AC8 for ; Mon, 14 Jan 2013 07:21:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.986 X-Spam-Level: X-Spam-Status: No, score=-1.986 tagged_above=-999 required=5 tests=[AWL=-0.990, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666, 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 djBrhY9A+Obe for ; Mon, 14 Jan 2013 07:21:14 -0800 (PST) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by ietfa.amsl.com (Postfix) with ESMTP id 271E221F888A for ; Mon, 14 Jan 2013 07:21:12 -0800 (PST) Received: by mail-we0-f182.google.com with SMTP id u54so2111177wey.41 for ; Mon, 14 Jan 2013 07:21:12 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=0+LWHOr/o+/wpBQzTteKwgnzqCKB8Prz4Zxqm+kmSwk=; b=Esy5hATuAGxkJ8runXvAV8lQ2VzKKVqxpmuZY+CaE3IbycpJcLSMbFkJVe2wrRwz/k 3cvcDTDl5HKu6x7cFoqYMSQ66hDZPKnZlNq/7JC+oD4cHufAkBIEJr3n5LLUORs12aD5 kZdbC01XoR/SyK3YdOzp3bkPEO9JVJjVxFk0Lgbec5KGgz72StPKe9VcOeDI6+U9Gvib IHf6nZ6xwVL4q8ETlNs5LutqiM4hyjgWD31C0yO7nzyQIu6VRyVz1uBpulQFKRAyY6jt Cur+M46N9bu4s8SQxVhGwukBRoGlHZpTUs0t2a4uK6in6OTJRAcjEjygwGZB5UkDYnBf W8lQ== X-Received: by 10.180.92.36 with SMTP id cj4mr13148720wib.23.1358176872032; Mon, 14 Jan 2013 07:21:12 -0800 (PST) Received: from mail-wi0-f171.google.com (mail-wi0-f171.google.com [209.85.212.171]) by mx.google.com with ESMTPS id i2sm13206887wiw.3.2013.01.14.07.21.10 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 14 Jan 2013 07:21:11 -0800 (PST) Received: by mail-wi0-f171.google.com with SMTP id hn14so1321257wib.16 for ; Mon, 14 Jan 2013 07:21:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.78.207 with SMTP id d15mr135845870wjx.52.1358176869360; Mon, 14 Jan 2013 07:21:09 -0800 (PST) Received: by 10.216.16.134 with HTTP; Mon, 14 Jan 2013 07:21:09 -0800 (PST) In-Reply-To: <50F41D97.1030508@nostrum.com> References: <50D2CC6A.4090500@ericsson.com> <6515_1357907583_50F0067F_6515_1738_1_2842AD9A45C83B44B57635FD4831E60A0747CC@PEXCVZYM14.corporate.adroot.infra.ftgroup> <580BEA5E3B99744AB1F5BFF5E9A3C67D16813E56EC@HE111648.emea1.cds.t-internal.com> <50F41D97.1030508@nostrum.com> Date: Mon, 14 Jan 2013 10:21:09 -0500 Message-ID: From: Roman Shpount To: Adam Roach Content-Type: multipart/alternative; boundary=047d7bfcf91ad7245304d341318e X-Gm-Message-State: ALoCoQn/uA8HmkAdR/Nz+6sMrqbcXcxxjJS9jZd0deGvQWxjkg+st4ABPoV5jTe9ftMalNRosVjs Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Consensus vs. Voting (was Re: Call for Consensus Regarding Selecting Recommended 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: Mon, 14 Jan 2013 15:21:15 -0000 --047d7bfcf91ad7245304d341318e Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I know that I would sound like I am repeating myself, but my initial argument was that in order to interoperate with majority of legacy HD Audio deployments without transcoding WebRTC implementations SHOULD support G.722. The main argument that I heard against this was that interoperability with legacy is not a justification enough for a SHOULD. Other arguments, such as that OPUS is better sounding and more resilient to packet loss then G.722 are irrelevant since it was never argued this way. The fact that the list of supported codecs in 5-10 years will change drastically is also not very relevant, since the specification can be updated to reflect this in the future. So the only thing that we have to discuss here is if interop deserves a SHOULD or should we just assume that implementers will do the right thing. To be honest all I've heard so far (and unfortunately I realize that this applies to some degree to my own argument) was that people feel one way or the other, which is not very helpful in reaching consensus. _____________ Roman Shpount On Mon, Jan 14, 2013 at 10:00 AM, Adam Roach wrote: > This thread has been going on for quite some time now, and I wouldn't be > surprised if there is some pressure for the chairs to call consensus in t= he > next week or two. > > I know it's tempting to think they might simply grab the relevant message= s > and tally the support for each position, calling the issue for those with > the larger number of proponents. In short, simple majority voting. Many > bodies work this way -- governments, corporations, and other SDOs, just t= o > name a few. > > We don't. > > As Dave Crocker[1] is fond of pointing out, it is possible to have 99 > people in support of a position and one standing against, and still fail = to > meet the IETF's standard for "rough consensus." All it takes is the failu= re > of those 99 people to engage the arguments put forth by the one outlier. > Correspondingly, you can have 50 people on one side of an issue, 50 on th= e > other, and still have a clear consensus if one side is merely stating a > position, while the other is offering up unanswered arguments. > > To be clear, I'm not saying that "+1" is never a valid response when > attempting to reach consensus. However, it does not, in and of itself, > comprise a counter-argument to points raised by supporters of the opposin= g > position. > > To the issue at hand: roughly grouping those proponents of option 1 into > one voice (A), and those boosting option 2 in to another (B), the > conversation so far can be roughly summarized as: > > A: We'd like to see SHOULD-level support for codecs x, y, and/or z becaus= e > gee, wouldn't it be nice? > B: "Wouldn't it be nice" doesn't meet the criteria for RFC 2119 SHOULD. > A: *crickets* > > [time passes] > > A: We'd like to see SHOULD-level support for codecs x, y, and/or z becaus= e > gee, wouldn't it be nice? > B: "Wouldn't it be nice" doesn't meet the criteria for RFC 2119 SHOULD. > A: *crickets* > > That's the _exact_ kind of failure to engage that I would expect would > cause experienced chairs to call clear consensus for supporters of option= 2. > > This isn't a vote, it's a discussion, and discussions need to go beyond > blindly repeating your opening arguments. If you have any interest in > option 1 being considered further, you need to listen and respond to the > opposing position. > > /a > > > [1] For those of you unfamiliar with Dave Crocker's tenure in the IETF, I > call your attention to the date and attendee list on the following > proceedings: http://www.ietf.org/**proceedings/04.pdf > > > On 1/14/13 02:21, R.Jesske@telekom.de wrote: > >> I also support Stephane's proposal. >> >> >> -----Urspr=FCngliche Nachricht----- >>> Von: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.**org >>> ] >>> Im Auftrag von Shida Schubert >>> Gesendet: Sonntag, 13. Januar 2013 22:35 >>> An: Paul Coverdale >>> Cc: rtcweb@ietf.org >>> Betreff: Re: [rtcweb] Call for Consensus Regarding Selecting >>> Recommended Audio Codecs >>> >>> >>> +1 >>> >>> On Jan 11, 2013, at 5:56 AM, Paul Coverdale wrote: >>> >>> I support Stephane's proposal for option 1. It makes good sense, >>>> particularly for the case where AMR and AMR-WB are already >>>> >>> implemented >>> >>>> in mobile devices - there are no additional licensing issues and it >>>> simplifies interoperability. >>>> >>>> ...Paul >>>> >>>> -----Original Message----- >>>>> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.**org] >>>>> On >>>>> Behalf Of stephane.proust@orange.com >>>>> Sent: Friday, January 11, 2013 7:33 AM >>>>> To: Magnus Westerlund; rtcweb@ietf.org >>>>> Subject: Re: [rtcweb] Call for Consensus Regarding Selecting >>>>> Recommended Audio Codecs >>>>> >>>>> It is clear from the discussions on the rtcweb e-mail >>>>> >>>> reflector that >>> >>>> the only additional codecs to be considered are limited to the >>>>> following very small subset of 3 codecs: AMR, AMR-WB and G.722. >>>>> In addition to G.711, these 3 codecs cover almost all >>>>> >>>> legacy devices >>> >>>> dedicated to voice services. They are consequently needed and >>>>> sufficient to be supported by WebRTC to make it an attractive and >>>>> future proof technology for usage in all environments including >>>>> mobile and for interoperability use cases with most of all >>>>> >>>> legacy voice terminals. >>> >>>> AMR and AMR-WB are indeed the most widely supported voice >>>>> >>>> codecs in >>> >>>> hundreds of millions of legacy mobile devices. >>>>> G.722 is royalty free (including a Packet Loss Concealment >>>>> >>>> solution >>> >>>> provided in ITU-T Software Tool Library) and is the codec >>>>> >>>> used for HD >>> >>>> Voice / DECT-Cat IQ fixed devices >>>>> >>>>> Furthermore, considering that the reason for excluding AMR >>>>> >>>> and AMR-WB >>> >>>> from WebRTC was the licensing issue, there is no reason to NOT >>>>> support AMR-WB and AMR at WebRTC level if these codecs are already >>>>> implemented on the device. >>>>> >>>>> Therefore I support option 1 and propose the following >>>>> >>>> specification >>> >>>> according this: >>>>> AMR-WB, AMR and G.722 are RECOMMENDED TO IMPLEMENT by WebRTC >>>>> end-points AMR and AMR-WB MUST BE supported at WebRTC >>>>> >>>> level by WebRTC >>> >>>> end-points on 3GPP mobile devices already implementing AMR >>>>> >>>> and AMR-WB >>> >>>> (*) >>>>> >>>>> (*) note that the way these codecs are supported at RTC >>>>> >>>> Web level is >>> >>>> left open to implementors: either by a WebRTC specific software >>>>> implementation of these codecs or by using APIs to access hardward >>>>> implementation. >>>>> >>>>> >>>>> -----Message d'origine----- >>>>> De : rtcweb-bounces@ietf.org >>>>> >>>> [mailto:rtcweb-bounces@ietf.**org ] De la >>> >>>> part de Magnus Westerlund Envoy=E9 : jeudi 20 d=E9cembre 2012 09:30 = =C0 : >>>>> rtcweb@ietf.org Objet : [rtcweb] Call for Consensus Regarding >>>>> Selecting Recommended Audio Codecs >>>>> >>>>> WG, >>>>> >>>>> As an outcome of the Vancouver IETF meeting codec >>>>> >>>> discussions we did >>> >>>> promise to run a call for consensus regarding if the WG was >>>>> interested in specifying a small set of recommended audio >>>>> >>>> codecs. We >>> >>>> are sorry this has been delayed until now. >>>>> >>>>> The question for the call of consensus is between two options. >>>>> >>>>> 1) Run a process in the WG to select and specify a small set of >>>>> audio/speech codecs that would be RECOMMNEDED to implement by a >>>>> WebRTC end-points >>>>> >>>>> 2) Do nothing and let the already specified Mandatory to Implement >>>>> Audio codecs be the only audio codecs mentioned in the >>>>> >>>> WebRTC specification. >>> >>>> Please indicate your position by January 16th 2013. >>>>> >>>>> Regards >>>>> >>>>> Magnus Westerlund >>>>> >>>>> >>>>> ------------------------------**------------------------------** >>> --------- >>> >>>> - Multimedia Technologies, Ericsson Research EAB/TVM >>>>> >>>>> ------------------------------**------------------------------** >>> ---------- >>> >>>> Ericsson AB | Phone +46 10 7148287 >>>>> F=E4r=F6gatan 6 | Mobile +46 73 0949079 >>>>> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com >>>>> >>>>> ------------------------------**------------------------------** >>> --------- >>> >>>> - >>>>> >>>>> ______________________________**_________________ >>>>> rtcweb mailing list >>>>> rtcweb@ietf.org >>>>> https://www.ietf.org/mailman/**listinfo/rtcweb >>>>> >>>>> >>>>> ______________________________**______________________________** >>> _________ >>> >>>> ___ ______________________________**___________________ >>>>> >>>>> Ce message et ses pieces jointes peuvent contenir des informations >>>>> confidentielles 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 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 information 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 delete this message and its attachments. >>>>> As emails may be altered, France Telecom - Orange is not >>>>> >>>> liable for >>> >>>> messages that have been modified, changed or falsified. >>>>> Thank you. >>>>> >>>>> ______________________________**_________________ >>>>> 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 >> > > ______________________________**_________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/**listinfo/rtcweb > --047d7bfcf91ad7245304d341318e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I know that I would sound like I am repeating myself, but my initial argume= nt was that in order to interoperate with majority of legacy HD Audio deplo= yments without transcoding WebRTC implementations SHOULD support G.722. The= main argument that I heard against this was that interoperability with leg= acy is not a justification enough for a SHOULD. Other arguments, such as th= at OPUS is better sounding and more resilient to packet loss then G.722 are= irrelevant since it was never argued this way. The fact that the list of s= upported codecs in 5-10 years will change drastically is also not very rele= vant, since the specification can be updated to reflect this in the future.= So the only thing that we have to discuss here is if interop deserves a SH= OULD or should we just assume that implementers will do the right thing. To= be honest all I've heard so far (and unfortunately I realize that this= applies to some degree to my own argument) was that people feel one way or= the other, which is not very helpful in reaching consensus.
_____________
Roman Shpount


On Mon, Jan 14, 2013 at 10:00 AM, Adam R= oach <adam@nostrum.com> wrote:
This thread has been going on for quite some time now, and I wouldn't b= e surprised if there is some pressure for the chairs to call consensus in t= he next week or two.

I know it's tempting to think they might simply grab the relevant messa= ges and tally the support for each position, calling the issue for those wi= th the larger number of proponents. In short, simple majority voting. Many = bodies work this way -- governments, corporations, and other SDOs, just to = name a few.

We don't.

As Dave Crocker[1] is fond of pointing out, it is possible to have 99 peopl= e in support of a position and one standing against, and still fail to meet= the IETF's standard for "rough consensus." All it takes is t= he failure of those 99 people to engage the arguments put forth by the one = outlier. Correspondingly, you can have 50 people on one side of an issue, 5= 0 on the other, and still have a clear consensus if one side is merely stat= ing a position, while the other is offering up unanswered arguments.

To be clear, I'm not saying that "+1" is never a valid respon= se when attempting to reach consensus. However, it does not, in and of itse= lf, comprise a counter-argument to points raised by supporters of the oppos= ing position.

To the issue at hand: roughly grouping those proponents of option 1 into on= e voice (A), and those boosting option 2 in to another (B), the conversatio= n so far can be roughly summarized as:

A: We'd like to see SHOULD-level support for codecs x, y, and/or z beca= use gee, wouldn't it be nice?
B: "Wouldn't it be nice" doesn't meet the criteria for RF= C 2119 SHOULD.
A: *crickets*

[time passes]

A: We'd like to see SHOULD-level support for codecs x, y, and/or z beca= use gee, wouldn't it be nice?
B: "Wouldn't it be nice" doesn't meet the criteria for RF= C 2119 SHOULD.
A: *crickets*

That's the _exact_ kind of failure to engage that I would expect would = cause experienced chairs to call clear consensus for supporters of option 2= .

This isn't a vote, it's a discussion, and discussions need to go be= yond blindly repeating your opening arguments. If you have any interest in = option 1 being considered further, you need to listen and respond to the op= posing position.

/a


[1] For those of you unfamiliar with Dave Crocker's tenure in the IETF,= I call your attention to the date and attendee list on the following proce= edings: http://www.ietf.org/proceedings/04.pdf


On 1/14/13 02:21, = R.Jesske@telekom.de wrote:
I also support Stephane's proposal.


-----Urspr=FCngliche Nachricht-----
Von: rtcweb-bo= unces@ietf.org [mailto:rtcweb-bounces@ietf.org]
Im Auftrag von Shida Schubert
Gesendet: Sonntag, 13. Januar 2013 22:35
An: Paul Coverdale
Cc: rtcweb@ietf.org
Betreff: Re: [rtcweb] Call for Consensus Regarding Selecting
Recommended Audio Codecs


+1

On Jan 11, 2013, at 5:56 AM, Paul Coverdale wrote:

I support Stephane's proposal for option 1. It makes good sense,
particularly for the case where AMR and AMR-WB are already
implemented
in mobile devices - there are no additional licensing issues and it
simplifies interoperability.

...Paul

-----Original Message-----
From: rtcweb-b= ounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On
Behalf Of s= tephane.proust@orange.com
Sent: Friday, January 11, 2013 7:33 AM
To: Magnus Westerlund; rtcweb@ietf.org
Subject: Re: [rtcweb] Call for Consensus Regarding Selecting
Recommended Audio Codecs

It is clear from the discussions on the rtcweb e-mail
reflector that
the only additional codecs to be considered are limited to the
following very small subset of 3 codecs: AMR, AMR-WB and G.722.
In addition to G.711, these 3 codecs cover almost all
legacy devices
dedicated to voice services. They are consequently needed and
sufficient to be supported by WebRTC to make it an attractive and
future proof technology for usage in all environments including
mobile and for interoperability use cases with most of all
legacy voice terminals.
AMR and AMR-WB are indeed the most widely supported voice
codecs in
hundreds of millions of legacy mobile devices.
G.722 is royalty free (including a Packet Loss Concealment
solution
provided in ITU-T Software Tool Library) and is the codec
used for HD
Voice / DECT-Cat IQ fixed devices

Furthermore, considering that the reason for excluding AMR
and AMR-WB
from WebRTC was the licensing issue, there is no reason to NOT
support AMR-WB and AMR at WebRTC level if these codecs are already
implemented on the device.

Therefore I support option 1 and propose the following
specification
according this:
AMR-WB, AMR and G.722 are RECOMMENDED TO IMPLEMENT by WebRTC
end-points AMR and AMR-WB MUST BE supported at WebRTC
level by WebRTC
end-points on 3GPP mobile devices already implementing AMR
and AMR-WB
(*)

(*) note that the way these codecs are supported at RTC
Web level is
left open to implementors: either by a WebRTC specific software
implementation of these codecs or by using APIs to access hardward
implementation.


-----Message d'origine-----
De : rtcweb-bo= unces@ietf.org
[mailto:rtcweb= -bounces@ietf.org] De la
part de Magnus Westerlund Envoy=E9 : jeudi 20 d=E9cembre 2012 09:30 =C0 : rtcweb@ietf.org Ob= jet : [rtcweb] Call for Consensus Regarding
Selecting Recommended Audio Codecs

WG,

As an outcome of the Vancouver IETF meeting codec
discussions we did
promise to run a call for consensus regarding if the WG was
interested in specifying a small set of recommended audio
codecs. We
are sorry this has been delayed until now.

The question for the call of consensus is between two options.

1) Run a process in the WG to select and specify a small set of
audio/speech codecs that would be RECOMMNEDED to implement by a
WebRTC end-points

2) Do nothing and let the already specified Mandatory to Implement
Audio codecs be the only audio codecs mentioned in the
WebRTC specification.
Please indicate your position by January 16th 2013.

Regards

Magnus Westerlund


-------------------------------------------------------------= --------
- Multimedia Technologies, Ericsson Research EAB/TVM

-------------------------------------------------------------= ---------
Ericsson AB =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Phone =A0+46 10 7148287=
F=E4r=F6gatan 6 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com

-------------------------------------------------------------= --------
-

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


_____________________________________________________________= ________
___ _________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations
confidentielles 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 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 information 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 delete this message and its attachments.
As emails may be altered, France Telecom - Orange is not
liable for
messages that have been modified, changed or falsified.
Thank you.

_______________________________________________
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

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

--047d7bfcf91ad7245304d341318e-- From tim@phonefromhere.com Mon Jan 14 07:54:59 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B431621F894C for ; Mon, 14 Jan 2013 07:54:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.442 X-Spam-Level: X-Spam-Status: No, score=-2.442 tagged_above=-999 required=5 tests=[AWL=0.158, 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 nTvvV47BRZ77 for ; Mon, 14 Jan 2013 07:54:59 -0800 (PST) Received: from smtp003.apm-internet.net (smtp003.apm-internet.net [85.119.248.52]) by ietfa.amsl.com (Postfix) with ESMTP id BB06E21F8919 for ; Mon, 14 Jan 2013 07:54:57 -0800 (PST) Received: (qmail 59511 invoked from network); 14 Jan 2013 15:54:56 -0000 X-AV-Scan: clean Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp003.apm-internet.net with SMTP; 14 Jan 2013 15:54:56 -0000 Received: from [192.67.4.33] (unknown [192.67.4.33]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id 69D9A18A0B07; Mon, 14 Jan 2013 15:54:56 +0000 (GMT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Tim Panton In-Reply-To: Date: Mon, 14 Jan 2013 15:54:54 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <2327AE82-FC1E-4D09-B6B4-E87F01BD3527@phonefromhere.com> References: <50D2CC6A.4090500@ericsson.com> <6515_1357907583_50F0067F_6515_1738_1_2842AD9A45C83B44B57635FD4831E60A0747CC@PEXCVZYM14.corporate.adroot.infra.ftgroup> <580BEA5E3B99744AB1F5BFF5E9A3C67D16813E56EC@HE111648.emea1.cds.t-internal.com> <50F41D97.1030508@nostrum.com> To: Roman Shpount X-Mailer: Apple Mail (2.1283) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Consensus vs. Voting (was Re: Call for Consensus Regarding Selecting Recommended 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: Mon, 14 Jan 2013 15:54:59 -0000 On 14 Jan 2013, at 15:21, Roman Shpount wrote: > I know that I would sound like I am repeating myself, but my initial = argument was that in order to interoperate with majority of legacy HD = Audio deployments without transcoding WebRTC implementations SHOULD = support G.722. The main argument that I heard against this was that = interoperability with legacy is not a justification enough for a SHOULD.=20= It's slightly more nuanced than that. More like: "the additional ease = of interoperability with legacy is not a justification enough for a = SHOULD" . Even without 722 we can interop with legacy HD , just not as easily - is = that added convenience enough to justify the SHOULD? Conversely=20 having 722 doesn't solve the whole interop problem, which further = reduces the 'win' from adding it. Tim. From roman@telurix.com Mon Jan 14 08:07:34 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BA1C21F8853 for ; Mon, 14 Jan 2013 08:07:34 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nBOn3Z3jFvMk for ; Mon, 14 Jan 2013 08:07:33 -0800 (PST) Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.177]) by ietfa.amsl.com (Postfix) with ESMTP id EF7C121F87C8 for ; Mon, 14 Jan 2013 08:07:32 -0800 (PST) Received: by mail-wi0-f177.google.com with SMTP id hm2so1356910wib.10 for ; Mon, 14 Jan 2013 08:07:31 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=OKaIw476qvMci71VnW0wVeDzmCDbpdUU2Qw9pzrNb/g=; b=Zo92P/OizhtH6hejs+GhUBBLM9NLNruUxhkqk/sYm96MxYCK8BHX3tlytBccCKZOV5 MzyzqREZkeAgTEv5XLRaQXSO7mCt4QJrXiDR+9HKq1z4fut7oU7ZYjfkmDqcZODI9QgH ASvuleHgVXzj6UGSEqjvjV60qwjaxGcJHfA4pZ/8E08Hz9nYRz0vPzVtHfgaGlTg55Vx 50FWg6gQFPJ3FpNkoJghUdq4g0i/Qzl9Bp4AfBL17V0Mx6+Yde6j9E6G3NxfT4TowXDM WGDN68XG4BglIynrdPmO4+xmgE35V0fGvYp6fZy6NrlSbJdfRVBdASTXSN/eAflFthJ4 f9NA== X-Received: by 10.194.58.113 with SMTP id p17mr6849670wjq.27.1358179651436; Mon, 14 Jan 2013 08:07:31 -0800 (PST) Received: from mail-we0-f175.google.com (mail-we0-f175.google.com [74.125.82.175]) by mx.google.com with ESMTPS id bd6sm13370070wib.10.2013.01.14.08.07.29 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 14 Jan 2013 08:07:30 -0800 (PST) Received: by mail-we0-f175.google.com with SMTP id z53so2180889wey.34 for ; Mon, 14 Jan 2013 08:07:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.180.101.99 with SMTP id ff3mr13640229wib.21.1358179648825; Mon, 14 Jan 2013 08:07:28 -0800 (PST) Received: by 10.216.16.134 with HTTP; Mon, 14 Jan 2013 08:07:28 -0800 (PST) In-Reply-To: <2327AE82-FC1E-4D09-B6B4-E87F01BD3527@phonefromhere.com> References: <50D2CC6A.4090500@ericsson.com> <6515_1357907583_50F0067F_6515_1738_1_2842AD9A45C83B44B57635FD4831E60A0747CC@PEXCVZYM14.corporate.adroot.infra.ftgroup> <580BEA5E3B99744AB1F5BFF5E9A3C67D16813E56EC@HE111648.emea1.cds.t-internal.com> <50F41D97.1030508@nostrum.com> <2327AE82-FC1E-4D09-B6B4-E87F01BD3527@phonefromhere.com> Date: Mon, 14 Jan 2013 11:07:28 -0500 Message-ID: From: Roman Shpount To: Tim Panton Content-Type: multipart/alternative; boundary=f46d044280e882699004d341d7be X-Gm-Message-State: ALoCoQn+jlmi24xn5LrKw1DWFoCCLZFQ87RBLwD3qMmhAhyLNEMpRHmiAudr1JDZAp0ODVnkZ867 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Consensus vs. Voting (was Re: Call for Consensus Regarding Selecting Recommended 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: Mon, 14 Jan 2013 16:07:34 -0000 --f46d044280e882699004d341d7be Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jan 14, 2013 at 10:54 AM, Tim Panton wrote: > On 14 Jan 2013, at 15:21, Roman Shpount wrote: > > > I know that I would sound like I am repeating myself, but my initial > argument was that in order to interoperate with majority of legacy HD Audio > deployments without transcoding WebRTC implementations SHOULD support > G.722. The main argument that I heard against this was that > interoperability with legacy is not a justification enough for a SHOULD. > > > It's slightly more nuanced than that. More like: "the additional ease of > interoperability with legacy is not a justification enough for a SHOULD" . > > Even without 722 we can interop with legacy HD , just not as easily - is > that added convenience enough to justify the SHOULD? Conversely > having 722 doesn't solve the whole interop problem, which further reduces > the 'win' from adding it. To follow this more nuanced approach, would cost of transcoding from OPUS to G.722 (or other codecs) justify a SHOULD? G.722 is very cheap to transcode to/from. I know that I can build a gateway that handles SRTP encryption and responds to all the ICE messages with density of few thousand channels per modern server CPU. I am not sure I can do this in combination with OPUS to G.722 transcoding. _____________ Roman Shpount --f46d044280e882699004d341d7be Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Jan 14, 2013 at 10:54 AM, Tim Panton= <tim@phonefromhere.com> wrote:
On 14 Jan 2013, at 15:21, Roman Shpount wrote:

> I know that I would sound like I am repeating myself, but my initial a= rgument was that in order to interoperate with majority of legacy HD Audio = deployments without transcoding WebRTC implementations SHOULD support G.722= . The main argument that I heard against this was that interoperability wit= h legacy is not a justification enough for a SHOULD.


It's slightly more nuanced than that. More like: =A0"the add= itional ease of interoperability with legacy is not a justification enough = for a SHOULD" .

Even without 722 we can interop with legacy HD , just not as easily - is th= at added convenience enough to justify the SHOULD? Conversely
having 722 doesn't solve the whole interop problem, which further reduc= es the 'win' from adding it.


To follow th= is more nuanced approach, would cost of transcoding from OPUS to G.722 (or = other codecs) justify a SHOULD? G.722 is very cheap to transcode to/from. I= know that I can build a gateway that handles SRTP encryption and responds = to all the ICE messages with density of few thousand channels per modern se= rver CPU. I am not sure I can do this in combination with OPUS to G.722 tra= nscoding.
_____________
Roman Shpount
--f46d044280e882699004d341d7be-- From tim@phonefromhere.com Mon Jan 14 08:26:18 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B32ED21F8790 for ; Mon, 14 Jan 2013 08:26:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.52 X-Spam-Level: X-Spam-Status: No, score=-2.52 tagged_above=-999 required=5 tests=[AWL=0.078, 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 IgxNObV1c4cs for ; Mon, 14 Jan 2013 08:26:18 -0800 (PST) Received: from smtp004.apm-internet.net (smtp004.apm-internet.net [85.119.248.54]) by ietfa.amsl.com (Postfix) with ESMTP id B1EF021F8788 for ; Mon, 14 Jan 2013 08:26:17 -0800 (PST) Received: (qmail 78568 invoked from network); 14 Jan 2013 16:26:15 -0000 X-AV-Scan: clean Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp004.apm-internet.net with SMTP; 14 Jan 2013 16:26:15 -0000 Received: from [192.67.4.33] (unknown [192.67.4.33]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id A8FBB18A0A07; Mon, 14 Jan 2013 16:26:15 +0000 (GMT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_549D6858-C3E5-4B6F-B235-647555C21060" From: Tim Panton In-Reply-To: Date: Mon, 14 Jan 2013 16:26:15 +0000 Message-Id: <00D8DD68-DB4D-450F-8787-8C32BD459937@phonefromhere.com> References: <50D2CC6A.4090500@ericsson.com> <6515_1357907583_50F0067F_6515_1738_1_2842AD9A45C83B44B57635FD4831E60A0747CC@PEXCVZYM14.corporate.adroot.infra.ftgroup> <580BEA5E3B99744AB1F5BFF5E9A3C67D16813E56EC@HE111648.emea1.cds.t-internal.com> <50F41D97.1030508@nostrum.com> <2327AE82-FC1E-4D09-B6B4-E87F01BD3527@phonefromhere.com> To: Roman Shpount X-Mailer: Apple Mail (2.1283) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Consensus vs. Voting (was Re: Call for Consensus Regarding Selecting Recommended 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: Mon, 14 Jan 2013 16:26:18 -0000 --Apple-Mail=_549D6858-C3E5-4B6F-B235-647555C21060 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 14 Jan 2013, at 16:07, Roman Shpount wrote: >=20 > On Mon, Jan 14, 2013 at 10:54 AM, Tim Panton = wrote: > On 14 Jan 2013, at 15:21, Roman Shpount wrote: >=20 > > I know that I would sound like I am repeating myself, but my initial = argument was that in order to interoperate with majority of legacy HD = Audio deployments without transcoding WebRTC implementations SHOULD = support G.722. The main argument that I heard against this was that = interoperability with legacy is not a justification enough for a SHOULD. >=20 >=20 > It's slightly more nuanced than that. More like: "the additional ease = of interoperability with legacy is not a justification enough for a = SHOULD" . >=20 > Even without 722 we can interop with legacy HD , just not as easily - = is that added convenience enough to justify the SHOULD? Conversely > having 722 doesn't solve the whole interop problem, which further = reduces the 'win' from adding it. >=20 >=20 > To follow this more nuanced approach, would cost of transcoding from = OPUS to G.722 (or other codecs) justify a SHOULD? G.722 is very cheap to = transcode to/from. I know that I can build a gateway that handles SRTP = encryption and responds to all the ICE messages with density of few = thousand channels per modern server CPU. I am not sure I can do this in = combination with OPUS to G.722 transcoding. Probably not. Is it worth a SHOULD ? I suppose that depends on how = important we collectively feel that use-case to be. I could live with a SHOULD on 722 - provided that it MUST include a PLC = (assuming a royalty free one exists) and MUST be offered at a lower priority than Opus.=20 T. --Apple-Mail=_549D6858-C3E5-4B6F-B235-647555C21060 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1
On 14 Jan 2013, at 16:07, Roman Shpount wrote:


On Mon, Jan 14, 2013 at 10:54 AM, Tim Panton <tim@phonefromhere.com> wrote:
On 14 Jan 2013, at 15:21, Roman Shpount wrote:

> I know that I would sound like I am repeating myself, but my initial argument was that in order to interoperate with majority of legacy HD Audio deployments without transcoding WebRTC implementations SHOULD support G.722. The main argument that I heard against this was that interoperability with legacy is not a justification enough for a SHOULD.


It's slightly more nuanced than that. More like:  "the additional ease of interoperability with legacy is not a justification enough for a SHOULD" .

Even without 722 we can interop with legacy HD , just not as easily - is that added convenience enough to justify the SHOULD? Conversely
having 722 doesn't solve the whole interop problem, which further reduces the 'win' from adding it.


To follow this more nuanced approach, would cost of transcoding from OPUS to G.722 (or other codecs) justify a SHOULD? G.722 is very cheap to transcode to/from. I know that I can build a gateway that handles SRTP encryption and responds to all the ICE messages with density of few thousand channels per modern server CPU. I am not sure I can do this in combination with OPUS to G.722 transcoding.

Probably not. Is it worth a SHOULD ? I suppose that depends on how important we collectively feel that use-case to be.

I could live with a SHOULD on 722 - provided that it MUST  include a PLC (assuming a royalty free one exists)
and MUST be offered at a lower priority than Opus. 

T.

--Apple-Mail=_549D6858-C3E5-4B6F-B235-647555C21060-- From roman@telurix.com Mon Jan 14 08:31:50 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C39A821F86BA for ; Mon, 14 Jan 2013 08:31:50 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MhdPSgiH4USL for ; Mon, 14 Jan 2013 08:31:50 -0800 (PST) Received: from mail-wg0-f52.google.com (mail-wg0-f52.google.com [74.125.82.52]) by ietfa.amsl.com (Postfix) with ESMTP id 1327721F8550 for ; Mon, 14 Jan 2013 08:31:49 -0800 (PST) Received: by mail-wg0-f52.google.com with SMTP id 12so2124678wgh.19 for ; Mon, 14 Jan 2013 08:31:49 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=vjp84sTlSo/2JmaQg6S/8/YbJvCYXGeqCFe+HzUia8k=; b=IYACgL4vo1U5OfhHLKUwuqy14MtTWBaeKQFqMyC3YrzhEn5OpPuKAUJstcoBDyrS66 +edD4/jbg0QOdeyfXZVv3pcdvEcycEEvyoTGRC4UekrPbfbfRadPal0e5yZL1Pyya2ug S1Y1HabvQeYcBqFkeB5sowLtVLOAkoBCadzFDws2o10D+0OTzL9GMPNbh0Pes5EklUuD kVeFFaE3+cPZcsU8fK0FlcTNZIi3AbsPgw3EHFBV+QIxMQJct/xuPcJEwLLOIEOv/Rqn huxst9DWYuWj+7G4gsmrylARY5B36JKgHJ/QmygB1XQcBjBM+FBNdXRD/ydWcXFIM4ut uSUg== X-Received: by 10.180.106.34 with SMTP id gr2mr13527190wib.18.1358181109253; Mon, 14 Jan 2013 08:31:49 -0800 (PST) Received: from mail-wg0-f43.google.com (mail-wg0-f43.google.com [74.125.82.43]) by mx.google.com with ESMTPS id eo10sm14774875wib.9.2013.01.14.08.31.47 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 14 Jan 2013 08:31:48 -0800 (PST) Received: by mail-wg0-f43.google.com with SMTP id e12so2057473wge.34 for ; Mon, 14 Jan 2013 08:31:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.180.82.41 with SMTP id f9mr13438997wiy.25.1358181106819; Mon, 14 Jan 2013 08:31:46 -0800 (PST) Received: by 10.216.16.134 with HTTP; Mon, 14 Jan 2013 08:31:46 -0800 (PST) In-Reply-To: <00D8DD68-DB4D-450F-8787-8C32BD459937@phonefromhere.com> References: <50D2CC6A.4090500@ericsson.com> <6515_1357907583_50F0067F_6515_1738_1_2842AD9A45C83B44B57635FD4831E60A0747CC@PEXCVZYM14.corporate.adroot.infra.ftgroup> <580BEA5E3B99744AB1F5BFF5E9A3C67D16813E56EC@HE111648.emea1.cds.t-internal.com> <50F41D97.1030508@nostrum.com> <2327AE82-FC1E-4D09-B6B4-E87F01BD3527@phonefromhere.com> <00D8DD68-DB4D-450F-8787-8C32BD459937@phonefromhere.com> Date: Mon, 14 Jan 2013 11:31:46 -0500 Message-ID: From: Roman Shpount To: Tim Panton Content-Type: multipart/alternative; boundary=f46d041826e669a3d604d3422e75 X-Gm-Message-State: ALoCoQksQTW/aGIz2wxgpS85c1RcqcKPT+Bb3mGL2GS91c+Achq+CKWt+9zaloV1pkj/M+qCD4sc Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Consensus vs. Voting (was Re: Call for Consensus Regarding Selecting Recommended 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: Mon, 14 Jan 2013 16:31:50 -0000 --f46d041826e669a3d604d3422e75 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jan 14, 2013 at 11:26 AM, Tim Panton wrote: > I could live with a SHOULD on 722 - provided that it MUST include a PLC > (assuming a royalty free one exists) > and MUST be offered at a lower priority than Opus. > I would agree with this as well, except that I would suggest that all supported audio codecs SHOULD include PLC. _____________ Roman Shpount --f46d041826e669a3d604d3422e75 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Jan 14, 2013 at 11:26 AM, Tim Panton= <tim@phonefromhere.com> wrote:
I could live with a SHOULD on 722 - provided that it MUST =A0include a= PLC (assuming a royalty free one exists)
and MUST be offered at = a lower priority than Opus.=A0

I would agree wi= th this as well, except that I would suggest that all supported audio codec= s SHOULD include PLC.
_____________
Roman Shpount
--f46d041826e669a3d604d3422e75-- From adam@nostrum.com Mon Jan 14 09:05:15 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C998F21F892C for ; Mon, 14 Jan 2013 09:05:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.399 X-Spam-Level: X-Spam-Status: No, score=-102.399 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599, SPF_PASS=-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 rvYFp3R3WS2c for ; Mon, 14 Jan 2013 09:05:15 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 3C71A21F8919 for ; Mon, 14 Jan 2013 09:05:15 -0800 (PST) Received: from Orochi.local (99-152-144-32.lightspeed.dllstx.sbcglobal.net [99.152.144.32]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r0EH5EiH090206 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 14 Jan 2013 11:05:14 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <50F43ACA.80206@nostrum.com> Date: Mon, 14 Jan 2013 11:05:14 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Roman Shpount References: <50D2CC6A.4090500@ericsson.com> <6515_1357907583_50F0067F_6515_1738_1_2842AD9A45C83B44B57635FD4831E60A0747CC@PEXCVZYM14.corporate.adroot.infra.ftgroup> <580BEA5E3B99744AB1F5BFF5E9A3C67D16813E56EC@HE111648.emea1.cds.t-internal.com> <50F41D97.1030508@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 99.152.144.32 is authenticated by a trusted mechanism) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Consensus vs. Voting (was Re: Call for Consensus Regarding Selecting Recommended 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: Mon, 14 Jan 2013 17:05:15 -0000 On 1/14/13 09:21, Roman Shpount wrote: > I know that I would sound like I am repeating myself, but my initial > argument was that in order to interoperate with majority of legacy HD > Audio deployments without transcoding WebRTC implementations SHOULD > support G.722. The main argument that I heard against this was that > interoperability with legacy is not a justification enough for a SHOULD. And I think that's what this question turns on. > So the only thing that we have to discuss here is if interop deserves > a SHOULD or should we just assume that implementers will do the right > thing. I make no assumptions. I propose guidance. > To be honest all I've heard so far (and unfortunately I realize that > this applies to some degree to my own argument) was that people feel > one way or the other, which is not very helpful in reaching consensus. What has been directly posed is the following form: given the RFC 2119 definition of "SHOULD" below, do you earnestly believe that support of G.722 actually warrants this level of specification: 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. ... Imperatives of the type defined in this memo must be used with care and sparingly. In particular, they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmisssions) For example, they must not be used to try to impose a particular method on implementors where the method is not required for interoperability. So far, no one has come forth and said anything equivalent to "yes, I believe that the severity implied by the RFC 2119 definition of 'SHOULD' is appropriate for G.722 (or AMR/AMR-WB) support." I suspect the reason is that anyone who follows the passage I quote above with such a claim realizes that they'll look a little out of touch with reality by doing so. /a From jmvalin@mozilla.com Mon Jan 14 09:05:22 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEDE521F89CE for ; Mon, 14 Jan 2013 09:05:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, 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 j75rrqZOmuJU for ; Mon, 14 Jan 2013 09:05:21 -0800 (PST) Received: from smtp.mozilla.org (mx1.corp.phx1.mozilla.com [63.245.216.69]) by ietfa.amsl.com (Postfix) with ESMTP id AB55F21F8956 for ; Mon, 14 Jan 2013 09:05:21 -0800 (PST) Received: from [192.168.16.26] (pool-96-241-176-56.washdc.fios.verizon.net [96.241.176.56]) (Authenticated sender: jvalin@mozilla.com) by mx1.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 11886F20E0; Mon, 14 Jan 2013 09:05:20 -0800 (PST) Message-ID: <50F43AD0.3030404@mozilla.com> Date: Mon, 14 Jan 2013 12:05:20 -0500 From: Jean-Marc Valin User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Roman Shpount References: <50D2CC6A.4090500@ericsson.com> <6515_1357907583_50F0067F_6515_1738_1_2842AD9A45C83B44B57635FD4831E60A0747CC@PEXCVZYM14.corporate.adroot.infra.ftgroup> <580BEA5E3B99744AB1F5BFF5E9A3C67D16813E56EC@HE111648.emea1.cds.t-internal.com> <50F41D97.1030508@nostrum.com> <2327AE82-FC1E-4D09-B6B4-E87F01BD3527@phonefromhere.com> <00D8DD68-DB4D-450F-8787-8C32BD459937@phonefromhere.com> In-Reply-To: X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Consensus vs. Voting (was Re: Call for Consensus Regarding Selecting Recommended 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: Mon, 14 Jan 2013 17:05:22 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/14/2013 11:31 AM, Roman Shpount wrote: > I would agree with this as well, except that I would suggest that > all supported audio codecs SHOULD include PLC. "SHOULD include a PLC" only makes sense if you specify minimum quality requirements. Otherwise "repeat previous packet" or "fill with zeros" all count as PLC. Personally, I really don't feel like getting into a PLC quality spec. Jean-Marc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJQ9DrPAAoJEJ6/8sItn9q9ViIH/2qI6us49ZH9OYSzM8BIzpbp rMAIpF3mzY9rVGagt2wwu+ndw1gQbTsgIgb/2R3o8OMsA0QElqKNSMMHWwS5r8Wa vaG6pDs2BrVPiSnexrYxGd/KW0JGC4iHTT8EC8kxmtmOziH3D14EZK9POAqEr8VL Z+s4eN0bLcet749AgoYxGL9fzNJNQ+0zDaDAUFvYrbytJjsBD5H7kmC+8Ee8mLgS Sxk2fE6bJc7XXE/fF4z6oQrV4KAD8iLOFyXXv+H7gqfPQA4AgOVaeSUFG1dSVfaA 0F3wyf3ft+cZdCdAiaWjOd3UMTOExGkNK1e9fUabBl8w7Eo1W46/M1dlEFWET9U= =B1n6 -----END PGP SIGNATURE----- From ted.ietf@gmail.com Mon Jan 14 09:41:30 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 666FD21F8841; Mon, 14 Jan 2013 09:41:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.194 X-Spam-Level: X-Spam-Status: No, score=-3.194 tagged_above=-999 required=5 tests=[AWL=0.405, 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 ZLmsmNTfHczK; Mon, 14 Jan 2013 09:41:29 -0800 (PST) Received: from mail-ie0-f182.google.com (mail-ie0-f182.google.com [209.85.223.182]) by ietfa.amsl.com (Postfix) with ESMTP id BA53321F8953; Mon, 14 Jan 2013 09:41:29 -0800 (PST) Received: by mail-ie0-f182.google.com with SMTP id s9so5406250iec.27 for ; Mon, 14 Jan 2013 09:41:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to:cc :content-type; bh=yKv5GxgAovOXPYnhQiYXqRURyRp0LeG/f0I6Rhh01AA=; b=VMu2U+6VulA8n6W3dmUyb7TUT2fdOnTv1u67s3A6cMDCzWSQoF2e3/s/lhWFnqQ0HL EjoRwxUvLtJB92s9u/qOActYOcLm0iyMa69XF+bWDh2SCkQssLGhecqcrd/yxV81R9JB u1pra2jyTcc/OFqiMMsWPdG2QfjcjCA84VAOqoZ7afU/G2+C3zA1feIyZWFy5Akw4BfF QBIlZXUy7XOxwR8iUkPp6O0NBrIxSs7AX7cOiDOdb2+8uuzBY1iVUfFyWYsHMI3uOoo1 FV4uv0b7EkklqXsUlsEt5zG3pw3xD8DQyVCBxs99w3tajfrxh13k8CxYkUbxxqZ/B+D1 n5nA== MIME-Version: 1.0 X-Received: by 10.50.170.102 with SMTP id al6mr7544813igc.70.1358185289401; Mon, 14 Jan 2013 09:41:29 -0800 (PST) Received: by 10.43.94.5 with HTTP; Mon, 14 Jan 2013 09:41:29 -0800 (PST) Date: Mon, 14 Jan 2013 09:41:29 -0800 Message-ID: From: Ted Hardie To: rtcweb@ietf.org, mmusic@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Cullen Jennings , =?ISO-8859-1?Q?Ari_Ker=E4nen?= Subject: [rtcweb] Proposed agenda for the joint MMUSIC/RTCWEB inteirm meeting X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 14 Jan 2013 17:41:30 -0000 Below is a proposed agenda which has been discussed among the RTCWEB and MMUSIC chairs; comments welcome. Ted Hardie Day 1 (February 5th, 2013) Multiple Flow SDP representation 90 minutes: Framing discussion (Magnus is working on text) 120 minutes: drafts discussion Objective: decide on architecture for large numbers of similar streams SDP for Data channels 60 minutes: resolve open issues Day 2 (February 6, 2013) SDP Grouping (Bundle/MMT/one-rtp) 60 Minutes: framing discussion 120 Minutes: drafts discussion Objective: select an approach and provide direction to editors Mapping stream/track label concepts to SDP identifiers 60 minutes Objective: determine requirements Day 3: (February 7, 2013) Trickle ICE 120 minutes Objective: review offer/answer semantic impact; establish initiation, termination and error handling JSEP 120 minutes Objective: review and resolve open issues with the document From roman@telurix.com Mon Jan 14 10:00:59 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A3E221F88C7 for ; Mon, 14 Jan 2013 10:00:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.481 X-Spam-Level: X-Spam-Status: No, score=-2.481 tagged_above=-999 required=5 tests=[AWL=0.495, 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 ohwHcrDBImiU for ; Mon, 14 Jan 2013 10:00:59 -0800 (PST) Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) by ietfa.amsl.com (Postfix) with ESMTP id BB62A21F88BE for ; Mon, 14 Jan 2013 10:00:58 -0800 (PST) Received: by mail-wi0-f180.google.com with SMTP id hj13so1467940wib.7 for ; Mon, 14 Jan 2013 10:00:57 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=KUWoTsBtpvfsKqUFb4cCXadsgtqEt11meq7kxBlHQIo=; b=QDYLmmedHV6dnpGRs4AhnLN2QTDyollMMZXgo/54o2shra4qzLjCUQbCoNGCcUZGoy pmaMn+ansUR9QbbB+iI26EHLjq2RvnK4+FvgHBprOxbXePhbWeDDSXz3CjErBEzQWmjT BX8ne/EPNXSsFDJ9uK7VVPH/uw73n8LkfbZQFFmyu4m18zu8G+aKPUuU3idrLwtP8mns TurUyXau0/y8QJqi6MyJ6CFlvCfACz1Mtj6RXCIbf2RldkPeUo2xKG5txsU4/TxLzAMx ZsvxuKgiaD4FbWdsdkiQU1Ksuo2y/c4fsv5Ur3OOIbUvbtePAYUDuD+TYNp3bOJcuTgL 7uAg== X-Received: by 10.194.240.129 with SMTP id wa1mr44130875wjc.21.1358186457675; Mon, 14 Jan 2013 10:00:57 -0800 (PST) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by mx.google.com with ESMTPS id hg17sm13816352wib.1.2013.01.14.10.00.55 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 14 Jan 2013 10:00:56 -0800 (PST) Received: by mail-wi0-f172.google.com with SMTP id o1so1471318wic.11 for ; Mon, 14 Jan 2013 10:00:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.80.73 with SMTP id p9mr36169875wjx.4.1358186455087; Mon, 14 Jan 2013 10:00:55 -0800 (PST) Received: by 10.216.16.134 with HTTP; Mon, 14 Jan 2013 10:00:54 -0800 (PST) In-Reply-To: <50F43ACA.80206@nostrum.com> References: <50D2CC6A.4090500@ericsson.com> <6515_1357907583_50F0067F_6515_1738_1_2842AD9A45C83B44B57635FD4831E60A0747CC@PEXCVZYM14.corporate.adroot.infra.ftgroup> <580BEA5E3B99744AB1F5BFF5E9A3C67D16813E56EC@HE111648.emea1.cds.t-internal.com> <50F41D97.1030508@nostrum.com> <50F43ACA.80206@nostrum.com> Date: Mon, 14 Jan 2013 13:00:54 -0500 Message-ID: From: Roman Shpount To: Adam Roach Content-Type: multipart/alternative; boundary=047d7bb04dae31ba9804d3436d2d X-Gm-Message-State: ALoCoQlN5Bm7GWOzE5q/GAILo6X7vbJnEGI4xA6xMBMyysaNbAk4DOykTYPGRSiFLOwsAlXLpdSw Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Consensus vs. Voting (was Re: Call for Consensus Regarding Selecting Recommended 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: Mon, 14 Jan 2013 18:00:59 -0000 --047d7bb04dae31ba9804d3436d2d Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jan 14, 2013 at 12:05 PM, Adam Roach wrote: > What has been directly posed is the following form: given the RFC 2119 > definition of "SHOULD" below, do you earnestly believe that support of > G.722 actually warrants this level of specification: I actually believe that G.722 warrants an RFC 2119 MUST, but this was voted against with the main reason (at least from my point of view) being desire to promote OPUS. I do agree that webrtc should express its preference for OPUS, but I do not see what valid reasons or circumstances can exist that will prevent G.722 implementation. I think that interoperability is a valid enough reason that G.722 support should be required. _____________ Roman Shpount --047d7bb04dae31ba9804d3436d2d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Jan 14, 2013 at 12:05 PM, Adam Roach= <adam@nostrum.com> wrote:
What has been directly posed is the following form: given the RFC 2119 defi= nition of "SHOULD" below, do you earnestly believe that support o= f G.722 actually warrants this level of specification:

I actually believe that G.722 warrants an RFC 2119 MUST, but this was = voted against with the main reason (at least from my point of view) being d= esire to promote OPUS. I do agree that webrtc should express its preference= for OPUS, but I do not see what valid reasons or circumstances can exist t= hat will prevent G.722 implementation. I think that interoperability is a v= alid enough reason that G.722 support should be required.

_____________
Roman Shpount
--047d7bb04dae31ba9804d3436d2d-- From adam@nostrum.com Mon Jan 14 10:14:10 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF4E921F8910 for ; Mon, 14 Jan 2013 10:14:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.439 X-Spam-Level: X-Spam-Status: No, score=-102.439 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_00=-2.599, SPF_PASS=-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 KvGmXQsE67pO for ; Mon, 14 Jan 2013 10:14:10 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 4AC7C21F888C for ; Mon, 14 Jan 2013 10:14:10 -0800 (PST) Received: from Orochi.local (99-152-144-32.lightspeed.dllstx.sbcglobal.net [99.152.144.32]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r0EIE8mc097590 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 14 Jan 2013 12:14:09 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <50F44AF0.4060304@nostrum.com> Date: Mon, 14 Jan 2013 12:14:08 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Roman Shpount References: <50D2CC6A.4090500@ericsson.com> <6515_1357907583_50F0067F_6515_1738_1_2842AD9A45C83B44B57635FD4831E60A0747CC@PEXCVZYM14.corporate.adroot.infra.ftgroup> <580BEA5E3B99744AB1F5BFF5E9A3C67D16813E56EC@HE111648.emea1.cds.t-internal.com> <50F41D97.1030508@nostrum.com> <50F43ACA.80206@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 99.152.144.32 is authenticated by a trusted mechanism) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Consensus vs. Voting (was Re: Call for Consensus Regarding Selecting Recommended 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: Mon, 14 Jan 2013 18:14:10 -0000 On 1/14/13 12:00, Roman Shpount wrote: > I think that interoperability is a valid enough reason that G.722 > support should be required. Interoperability with G.722 is not just possible without such a requirement; it's already implemented: http://code.google.com/p/webrtc2sip/#Media_Coder You vastly overstate your case when you claim that G.722 support in WebRTC clients is *required* to interwork with some legacy clients. The facts on the ground are that such support simply makes it easier. It really is a "gee, wouldn't it be nice" feature. And that is *way* outside what we use "SHOULD" for. /a From harald@alvestrand.no Mon Jan 14 10:37:24 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC88A21F88AC for ; Mon, 14 Jan 2013 10:37:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.449 X-Spam-Level: X-Spam-Status: No, score=-110.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 26-0CHgbvu9O for ; Mon, 14 Jan 2013 10:37:24 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 3BF2421F8893 for ; Mon, 14 Jan 2013 10:37:24 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 23D6639E262 for ; Mon, 14 Jan 2013 19:37:16 +0100 (CET) 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 WpEKnrA3OR4h for ; Mon, 14 Jan 2013 19:37:15 +0100 (CET) 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 C378B39E25C for ; Mon, 14 Jan 2013 19:37:14 +0100 (CET) Message-ID: <50F45059.4090308@alvestrand.no> Date: Mon, 14 Jan 2013 19:37:13 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <50D2CC6A.4090500@ericsson.com> <6515_1357907583_50F0067F_6515_1738_1_2842AD9A45C83B44B57635FD4831E60A0747CC@PEXCVZYM14.corporate.adroot.infra.ftgroup> <580BEA5E3B99744AB1F5BFF5E9A3C67D16813E56EC@HE111648.emea1.cds.t-internal.com> <50F41D97.1030508@nostrum.com> In-Reply-To: <50F41D97.1030508@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Consensus vs. Voting (was Re: Call for Consensus Regarding Selecting Recommended 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: Mon, 14 Jan 2013 18:37:25 -0000 On 01/14/2013 04:00 PM, Adam Roach wrote: > This thread has been going on for quite some time now, and I wouldn't > be surprised if there is some pressure for the chairs to call > consensus in the next week or two. > > I know it's tempting to think they might simply grab the relevant > messages and tally the support for each position, calling the issue > for those with the larger number of proponents. In short, simple > majority voting. Many bodies work this way -- governments, > corporations, and other SDOs, just to name a few. > > We don't. While agreeing with your general point...... I do like to list (not count; list gives you not only the numbers, but the names, which is much more information) the proponents of each side, and look at the length of the lists as well as the names on it. What this often tells me is "there's no way in hell we're ever going to come to consensus on A, but there is a chance that we could declare rough consensus on B, and people will be living to live with it". The result is often suspiciously like what happens with vote counting, but the logic is slightly different. But all this is advice to the chairs when their announced period of consensus call ends in 2 days. It's really up to them. Harald From roman@telurix.com Mon Jan 14 10:52:02 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A1CE21F89E5 for ; Mon, 14 Jan 2013 10:51:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.646 X-Spam-Level: X-Spam-Status: No, score=-2.646 tagged_above=-999 required=5 tests=[AWL=0.330, 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 54AT-knga7Yx for ; Mon, 14 Jan 2013 10:51:51 -0800 (PST) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8D60721F8818 for ; Mon, 14 Jan 2013 10:51:49 -0800 (PST) Received: by mail-wg0-f44.google.com with SMTP id dr12so2147820wgb.23 for ; Mon, 14 Jan 2013 10:51:48 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=MMsi21gn/Pui6BXLFSD5gWVk5whgYP4QmPMY6YnB7LY=; b=e8RUlxtAHavt+B4pBza7UpCeLEuGT9o3qdv8MrzqZXI+TY/g2r+gyhPSSEiESLE/xz u4PJv4tC0v1CHz7mv5ZCyLBnHWYxsKuPzVby7cDwOkdzm5eewyqgfHXz/2Rtfqs231bn fJhaCEh1nzES6lfqXQiWFzA8aifhC3YpWNvwuN++AU2+DiNCoRzoqeM/bNex8ShVX9dF LkKZ/FUqtp72STZJyfsLxg+TwHziqilNULTH1H2zPYsQkZG0JMUyTzAhLdwMHy0+KRQF jgSlOPen6atkE2r8A9uZwyniNU6kAltz73BG+NP5fJaUlJTEahyjryt/wsMEkGSPN7Vb kZAA== X-Received: by 10.180.101.104 with SMTP id ff8mr14254125wib.11.1358189508446; Mon, 14 Jan 2013 10:51:48 -0800 (PST) Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) by mx.google.com with ESMTPS id s16sm158145wii.0.2013.01.14.10.51.46 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 14 Jan 2013 10:51:47 -0800 (PST) Received: by mail-wi0-f173.google.com with SMTP id hn17so1524636wib.0 for ; Mon, 14 Jan 2013 10:51:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.180.82.41 with SMTP id f9mr14163487wiy.25.1358189505778; Mon, 14 Jan 2013 10:51:45 -0800 (PST) Received: by 10.216.16.134 with HTTP; Mon, 14 Jan 2013 10:51:45 -0800 (PST) In-Reply-To: <50F44AF0.4060304@nostrum.com> References: <50D2CC6A.4090500@ericsson.com> <6515_1357907583_50F0067F_6515_1738_1_2842AD9A45C83B44B57635FD4831E60A0747CC@PEXCVZYM14.corporate.adroot.infra.ftgroup> <580BEA5E3B99744AB1F5BFF5E9A3C67D16813E56EC@HE111648.emea1.cds.t-internal.com> <50F41D97.1030508@nostrum.com> <50F43ACA.80206@nostrum.com> <50F44AF0.4060304@nostrum.com> Date: Mon, 14 Jan 2013 13:51:45 -0500 Message-ID: From: Roman Shpount To: Adam Roach Content-Type: multipart/alternative; boundary=f46d041826e607929e04d344232a X-Gm-Message-State: ALoCoQlHPYj5AR/X4mJEx/rtgWyTb0Ixh3WwFR9sz6sqpSTV5x+fAJ1ue91GznlUUaU/ByMk1u9o Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Consensus vs. Voting (was Re: Call for Consensus Regarding Selecting Recommended 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: Mon, 14 Jan 2013 18:52:03 -0000 --f46d041826e607929e04d344232a Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jan 14, 2013 at 1:14 PM, Adam Roach wrote: > You vastly overstate your case when you claim that G.722 support in WebRTC > clients is *required* to interwork with some legacy clients. The facts on > the ground are that such support simply makes it easier. It really is a > "gee, wouldn't it be nice" feature. > The question is the question of cost of transcoding. It is not insignificant or not a simple "gee, wouldn't it be nice". As I've mentioned earlier it is possible to build a media gateway that will handle encryption and ICE with the density of a few thousand calls per server CPU. It would not be possible if G.722 to OPUS transcoding is required. So, the argument to support G.722 is that it removes the need for transcoding (and subsequently need for jitter buffering, which introduces delays and requires even more resources on the media gateway). What is the argument against it? _____________ Roman Shpount --f46d041826e607929e04d344232a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Jan 14, 2013 at 1:14 PM, Adam Roach = <adam@nostrum.com> wrote:
You vastly overstate your case when you claim that G.722 s= upport in WebRTC clients is *required* to interwork with some legacy client= s. The facts on the ground are that such support simply makes it easier. It= really is a "gee, wouldn't it be nice" feature.

The question is the question of cost of transc= oding. It is not insignificant or not a simple "gee, wouldn't it b= e nice". As I've mentioned earlier it is possible to build a media= gateway that will handle encryption and ICE with the density of a few thou= sand calls per server CPU. It would not be possible if G.722 to OPUS transc= oding is required. So, the argument to support G.722 is that it removes the= need for transcoding (and subsequently need for jitter buffering, which in= troduces delays and requires even more resources on the media gateway). Wha= t is the argument against it?

_____________
Roman Shpount
--f46d041826e607929e04d344232a-- From adam@nostrum.com Mon Jan 14 11:51:03 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A6A321F8B06 for ; Mon, 14 Jan 2013 11:51:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.466 X-Spam-Level: X-Spam-Status: No, score=-102.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-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 TVDajrvBwpsm for ; Mon, 14 Jan 2013 11:51:02 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 33F3221F8AE0 for ; Mon, 14 Jan 2013 11:51:01 -0800 (PST) Received: from Orochi.local (99-152-144-32.lightspeed.dllstx.sbcglobal.net [99.152.144.32]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r0EJotaY007999 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 14 Jan 2013 13:50:56 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <50F4619F.7040208@nostrum.com> Date: Mon, 14 Jan 2013 13:50:55 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Roman Shpount References: <50D2CC6A.4090500@ericsson.com> <6515_1357907583_50F0067F_6515_1738_1_2842AD9A45C83B44B57635FD4831E60A0747CC@PEXCVZYM14.corporate.adroot.infra.ftgroup> <580BEA5E3B99744AB1F5BFF5E9A3C67D16813E56EC@HE111648.emea1.cds.t-internal.com> <50F41D97.1030508@nostrum.com> <50F43ACA.80206@nostrum.com> <50F44AF0.4060304@nostrum.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------030205010103070507040003" Received-SPF: pass (nostrum.com: 99.152.144.32 is authenticated by a trusted mechanism) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Consensus vs. Voting (was Re: Call for Consensus Regarding Selecting Recommended 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: Mon, 14 Jan 2013 19:51:03 -0000 This is a multi-part message in MIME format. --------------030205010103070507040003 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 1/14/13 12:51, Roman Shpount wrote: > > On Mon, Jan 14, 2013 at 1:14 PM, Adam Roach > wrote: > > You vastly overstate your case when you claim that G.722 support > in WebRTC clients is *required* to interwork with some legacy > clients. The facts on the ground are that such support simply > makes it easier. It really is a "gee, wouldn't it be nice" feature. > > > The question is the question of cost of transcoding. It is not > insignificant or not a simple "gee, wouldn't it be nice". As I've > mentioned earlier it is possible to build a media gateway that will > handle encryption and ICE with the density of a few thousand calls per > server CPU. It would not be possible if G.722 to OPUS transcoding is > required. Not only do I agree; I've actually made very similar (and related) points: > So, the argument to support G.722 is that it removes the need for > transcoding (and subsequently need for jitter buffering, which > introduces delays and requires even more resources on the media gateway). I think we agree more than we disagree. The distinction to make is that I believe that implementations would benefit from supporting G.722, while you think they SHOULD (RFC 2119 term) support G.722. > What is the argument against it? I am not making an argument supporting G.722 per se, and I think its merits and/or drawbacks are red herrings in this conversation. The argument is against *normatively* specifying support of *any* additional codecs. I don't think it was a good idea to have 2 MTIs to start with. A single MTI gets us interop. Anything beyond that rises to the level of "MAY," and no higher. I would be making the exact same set of arguments if G.722 were MTI, and the ongoing discussion were on whether Opus "SHOULD be supported." /a --------------030205010103070507040003 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 1/14/13 12:51, Roman Shpount wrote:

On Mon, Jan 14, 2013 at 1:14 PM, Adam Roach <adam@nostrum.com> wrote:
You vastly overstate your case when you claim that G.722 support in WebRTC clients is *required* to interwork with some legacy clients. The facts on the ground are that such support simply makes it easier. It really is a "gee, wouldn't it be nice" feature.

The question is the question of cost of transcoding. It is not insignificant or not a simple "gee, wouldn't it be nice". As I've mentioned earlier it is possible to build a media gateway that will handle encryption and ICE with the density of a few thousand calls per server CPU. It would not be possible if G.722 to OPUS transcoding is required.

Not only do I agree; I've actually made very similar (and related) points: <http://www.ietf.org/mail-archive/web/rtcweb/current/msg06013.html>

So, the argument to support G.722 is that it removes the need for transcoding (and subsequently need for jitter buffering, which introduces delays and requires even more resources on the media gateway).

I think we agree more than we disagree. The distinction to make is that I believe that implementations would benefit from supporting G.722, while you think they SHOULD (RFC 2119 term) support G.722.

What is the argument against it?

I am not making an argument supporting G.722 per se, and I think its merits and/or drawbacks are red herrings in this conversation. The argument is against *normatively* specifying support of *any* additional codecs. I don't think it was a good idea to have 2 MTIs to start with. A single MTI gets us interop. Anything beyond that rises to the level of "MAY," and no higher.

I would be making the exact same set of arguments if G.722 were MTI, and the ongoing discussion were on whether Opus "SHOULD be supported."

/a
--------------030205010103070507040003-- From roman@telurix.com Mon Jan 14 12:15:05 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C23E21F8B4C for ; Mon, 14 Jan 2013 12:15:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.728 X-Spam-Level: X-Spam-Status: No, score=-2.728 tagged_above=-999 required=5 tests=[AWL=0.248, 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 S7K93I3AZwzB for ; Mon, 14 Jan 2013 12:15:04 -0800 (PST) Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com [209.85.212.181]) by ietfa.amsl.com (Postfix) with ESMTP id 59E6C21F8B49 for ; Mon, 14 Jan 2013 12:15:04 -0800 (PST) Received: by mail-wi0-f181.google.com with SMTP id hq4so1594060wib.2 for ; Mon, 14 Jan 2013 12:15:03 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=HKRYycHPkapI1erRnAeuUVf3VXohNm/m29Ou/eu3YU8=; b=H7dO4oj2axyDFbPbO7FUixoH1eJpaioGjPeivkuQhnJ+DGqk8VPFTAIZZjil6S2Guh jSxTj8yQ7vKa1khFKE3m8k+8uAlxgsYDa+Hu5yBedXqhV8ktD9dEweDOQs8qMdImyjEN VyCvBbyL9sK0xHfwvXfnWU2NZdMcS8TGM/r4iK95hpQYPDVG7D3O9PW1Sqpo83cevFrH 0hdAXSzPGXjbCNBrx86950Cysji9HoIzao8PTEWUA8+5/SpxY0zFpllaIT4/zlNR46U+ 6XMlPyvdr15Ay9mYVsGp9j4SRhphAHXdfr9MyaLGaRqECqgGu39vX8v6ooPbhe8lxJYQ KT4A== X-Received: by 10.194.240.233 with SMTP id wd9mr19270557wjc.54.1358194503569; Mon, 14 Jan 2013 12:15:03 -0800 (PST) Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) by mx.google.com with ESMTPS id ex6sm311883wid.3.2013.01.14.12.15.01 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 14 Jan 2013 12:15:02 -0800 (PST) Received: by mail-wi0-f173.google.com with SMTP id hn17so1598614wib.12 for ; Mon, 14 Jan 2013 12:15:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.80.73 with SMTP id p9mr36805393wjx.4.1358194500916; Mon, 14 Jan 2013 12:15:00 -0800 (PST) Received: by 10.216.16.134 with HTTP; Mon, 14 Jan 2013 12:15:00 -0800 (PST) In-Reply-To: <50F4619F.7040208@nostrum.com> References: <50D2CC6A.4090500@ericsson.com> <6515_1357907583_50F0067F_6515_1738_1_2842AD9A45C83B44B57635FD4831E60A0747CC@PEXCVZYM14.corporate.adroot.infra.ftgroup> <580BEA5E3B99744AB1F5BFF5E9A3C67D16813E56EC@HE111648.emea1.cds.t-internal.com> <50F41D97.1030508@nostrum.com> <50F43ACA.80206@nostrum.com> <50F44AF0.4060304@nostrum.com> <50F4619F.7040208@nostrum.com> Date: Mon, 14 Jan 2013 15:15:00 -0500 Message-ID: From: Roman Shpount To: Adam Roach Content-Type: multipart/alternative; boundary=047d7bb04daec3567f04d3454c47 X-Gm-Message-State: ALoCoQmRxMnuwD1SKPPAsD3YwYqqLIZ1YG9CGjsDgP4JxMDZik0Lj1+gH2ykQxBdXDPeCMvf05SG Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Consensus vs. Voting (was Re: Call for Consensus Regarding Selecting Recommended 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: Mon, 14 Jan 2013 20:15:05 -0000 --047d7bb04daec3567f04d3454c47 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jan 14, 2013 at 2:50 PM, Adam Roach wrote: > I am not making an argument supporting G.722 per se, and I think its > merits and/or drawbacks are red herrings in this conversation. The argument > is against *normatively* specifying support of *any* additional codecs. I > don't think it was a good idea to have 2 MTIs to start with. A single MTI > gets us interop. Anything beyond that rises to the level of "MAY," and no > higher. > > I would be making the exact same set of arguments if G.722 were MTI, and > the ongoing discussion were on whether Opus "SHOULD be supported." > We already have two MTI OPUS and G.711. From my point of view OPUS gets us all the future end points; G.711 gets us PSTN; and G.722 would get us legacy HD Audio. AMR-WB (as well as AMR and GSM) from my point of view deserve some mention in the specification but do not warrant a SHOULD. AMR-WB would be nice to have to connect to mobile networks but there are serious IPR related issues preventing its support. Furthermore, even though AMR-WB is supported by a significant number mobile phones, AMR-WB network interconnects are virtually non-existent, so, from practical point of view, support for this codecs is a lot less critical. _____________ Roman Shpount --047d7bb04daec3567f04d3454c47 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Jan 14, 2013 at 2:50 PM, Adam Roach = <adam@nostrum.com> wrote:
I am not making an argument suppo= rting G.722 per se, and I think its merits and/or drawbacks are red herrings in this conversation. The argument is against *normatively* specifying support of *any* additional codecs. I don't think it was a good idea to have 2 MTIs to start with. A single MTI gets us interop. Anything beyond that rises to the level of "MAY," and no higher.

I would be making the exact same set of arguments if G.722 were MTI, and the ongoing discussion were on whether Opus "SHOULD be supported."

We already have two MTI OP= US and G.711. From my point of view OPUS gets us all the future end points;= G.711 gets us PSTN; and G.722 would get us legacy HD Audio.

AMR-WB = (as well as AMR and GSM) from my point of view deserve some mention in the = specification but do not warrant a SHOULD. AMR-WB would be nice to have to = connect to mobile networks but there are serious IPR related issues prevent= ing its support. Furthermore, even though AMR-WB is supported by a signific= ant number mobile phones, AMR-WB network interconnects are virtually non-ex= istent, so, from practical point of view, support for this codecs is a lot = less critical.
_____________
Roman Shpount
--047d7bb04daec3567f04d3454c47-- From stefan.lk.hakansson@ericsson.com Tue Jan 15 06:48:19 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E38DD21F8635 for ; Tue, 15 Jan 2013 06:48:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, 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 e4Om3V5HUFfy for ; Tue, 15 Jan 2013 06:48:14 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 00CF821F85CE for ; Tue, 15 Jan 2013 06:48:13 -0800 (PST) X-AuditID: c1b4fb2d-b7f316d0000028db-a3-50f56c2cf820 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 1E.0B.10459.C2C65F05; Tue, 15 Jan 2013 15:48:13 +0100 (CET) Received: from [150.132.141.90] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.279.1; Tue, 15 Jan 2013 15:48:12 +0100 Message-ID: <50F56C2C.9070209@ericsson.com> Date: Tue, 15 Jan 2013 15:48:12 +0100 From: =?ISO-8859-1?Q?Stefan_H=E5kansson_LK?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: rtcweb@ietf.org References: <50D2CC6A.4090500@ericsson.com> In-Reply-To: <50D2CC6A.4090500@ericsson.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPJMWRmVeSWpSXmKPExsUyM+Jvja5uztcAg9PHmC3W/mtnd2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxqSH+1gKFshUHN57kLmB8bdYFyMnh4SAicTKhY8YIWwxiQv3 1rN1MXJxCAmcZJSYvfIuO4SzhlFi0tYfTCBVvALaEjem72EBsVkEVCX+N39iBrHZBAIlrv// BVYjKhAl8f5qEzNEvaDEyZlPwOpFBIQltr7qBasRFgiXWLftNlhcCGhmT8cWsHpOAR2JZTvW soPYzAK2EhfmXGeBsOUlmrfOZoao15V49/oe6wRGgVlIVsxC0jILScsCRuZVjOy5iZk56eWG mxiBgXZwy2/dHYynzokcYpTmYFES5w1zvRAgJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgXHq an2zy+saEtK/bFe6yb74L7P5nBvKewNfHAv76x1w+rDncfEJCmb1C/75aM5598RZN1q2rsvV ntvkfcz3FwmH+lamc4YmHLMpXFXC9H2Bk5ndvwlW2geWLVugs+hE+CX3j/eCzOZc/sSxb1pZ Ybn3f49301ju/po8pfZ/Y25f266Ni1U/W+1WYinOSDTUYi4qTgQAT6SrjAICAAA= Subject: Re: [rtcweb] Call for Consensus Regarding Selecting Recommended 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, 15 Jan 2013 14:48:20 -0000 On 2012-12-20 09:29, Magnus Westerlund wrote: > WG, > > As an outcome of the Vancouver IETF meeting codec discussions we did > promise to run a call for consensus regarding if the WG was interested > in specifying a small set of recommended audio codecs. We are sorry this > has been delayed until now. > > The question for the call of consensus is between two options. > > 1) Run a process in the WG to select and specify a small set of > audio/speech codecs that would be RECOMMNEDED to implement by a WebRTC > end-points > > 2) Do nothing and let the already specified Mandatory to Implement Audio > codecs be the only audio codecs mentioned in the WebRTC specification. > > Please indicate your position by January 16th 2013. I see the following important reasons for creating a RECOMMENDED category: 1. interoperability without quality degradations due to transcoding with large installed legacy and existing services. Typical examples are interconnection cases to major mobile or fixed communication systems. Clearly interop with 3GPP voice services and HD Voice in 3GPP and fixed networks is very important. The option with transcoding should be avoided as - besides the equipment costs - it is affecting the communication quality in terms of more coding distortions and delay. 2. take advantage of deep codec specific integrations/optimizations. Typical examples are interconnection cases to major mobile systems which bearers are highly optimized for a given codec specified for these systems. For these systems operating with their 'native' codecs is beneficial not only in terms of system capacity and efficiency but also from end-user perspective as it will allow least battery consumption in the mobile devices (due to that hardware implementations for the codecs are often used) and provide best robustness/coverage. At least interop to such native codecs in 3GPP mobile networks is essential. This point partly overlaps with the previous but also covers cases where new codecs will get a deep system integration. The alternative with transcoding in a GW should be avoided for the reasons given above (avoiding extra distortions and delay). 3. future-proofness of specifications allowing to recommend new codecs that turn out to be better/more efficient than existing mandatory codecs. As history has proven, even the best mandatory codec has a best-before date. We should foresee the possibility to at least recommend such a better codec at some stage when felt appropriate. At the same time, when creating a RECOMMENDED category, I think that it should be strictly limited to very few codecs only. At present I see a reasonable limit of 3 recommended codecs related to particular interop scenarios. However, this number could be increased if new and better codecs are deemed would in the future enter this category. So, my vote goes for option 1. Stefan > > Regards > > Magnus Westerlund > > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > Färögatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From uwe.rauschenbach@nsn.com Tue Jan 15 09:40:32 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32DA421F85D0 for ; Tue, 15 Jan 2013 09:40:32 -0800 (PST) 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 ZkmmL0IWVCYy for ; Tue, 15 Jan 2013 09:40:31 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 49F6121F8561 for ; Tue, 15 Jan 2013 09:40:30 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id r0FHeTHV004976 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 15 Jan 2013 18:40:29 +0100 Received: from DEMUEXC047.nsn-intra.net ([10.159.32.93]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id r0FHeSYi028824 for ; Tue, 15 Jan 2013 18:40:29 +0100 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by DEMUEXC047.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 15 Jan 2013 18:40:11 +0100 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, 15 Jan 2013 18:40:10 +0100 Message-ID: <7CBFD4609D19C043A4AC4FD8381C6E2602386636@DEMUEXC014.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] Consensus vs. Voting (was Re: Call for Consensus Regarding Selecting Recommended Audio Codecs) Thread-Index: Ac3yk942P44BqwSKSXWPBDHefyatGgAsyVGQ References: <50D2CC6A.4090500@ericsson.com><6515_1357907583_50F0067F_6515_1738_1_2842AD9A45C83B44B57635FD4831E60A0747CC@PEXCVZYM14.corporate.adroot.infra.ftgroup><580BEA5E3B99744AB1F5BFF5E9A3C67D16813E56EC@HE111648.emea1.cds.t-internal.com><50F41D97.1030508@nostrum.com><50F43ACA.80206@nostrum.com><50F44AF0.4060304@nostrum.com><50F4619F.7040208@nostrum.com> From: "Rauschenbach, Uwe (NSN - DE/Munich)" To: X-OriginalArrivalTime: 15 Jan 2013 17:40:11.0176 (UTC) FILETIME=[5E2BAA80:01CDF347] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 2819 X-purgate-ID: 151667::1358271629-00003C02-FEAC5984/0-0/0-0 Subject: Re: [rtcweb] Consensus vs. Voting (was Re: Call for Consensus Regarding Selecting Recommended 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, 15 Jan 2013 17:40:32 -0000 From: rtcweb-bounces@ietf.org on behalf of ext Roman Shpount =20 > On Mon, Jan 14, 2013 at 2:50 PM, Adam Roach wrote: > > > I am not making an argument supporting G.722 per se, and I think its merits and/or drawbacks are red herrings in this conversation. The argument is against *normatively* specifying support of *any* additional codecs. I don't think it was a good idea to have 2 MTIs to start with. A single MTI gets us interop. Anything beyond that rises to the level of "MAY," and no higher. >=09 > I would be making the exact same set of arguments if G.722 were MTI, and the ongoing discussion were on whether Opus "SHOULD be supported." > > > We already have two MTI OPUS and G.711. From my point of view OPUS gets us all the future end points; G.711 gets us PSTN; and G.722 would get us legacy HD Audio. > > AMR-WB (as well as AMR and GSM) from my point of view deserve some mention in the specification but do not warrant a SHOULD. AMR-WB would be nice to have to connect to mobile networks but there are serious IPR related issues preventing its support. Furthermore, even though AMR-WB is supported by a significant number mobile phones, AMR-WB network interconnects are virtually non-existent, so, from practical point of view, support for this codecs is a lot less critical. I do see AMR / AMR-WB at the same level as G.722 - to support interoperability with legacy networks without the need for transcoding. I believe saving transcoding cycles is important for the success of RTCWeb, as it allows building bridges to the legacy world of real-time communications (i.e. fixed and mobile communication networks) at a reasonable cost. Hence, I consider it not just "nice to have". It may be true that the G.711 is most widespread today at NNI interfaces due to the PSTN legacy and support in the fixed network world, but SIP NNI interfaces are only now being rolled out, and as codec negotiation is an integral part of SIP, I do expect that they will support multiple codecs (at least in the medium term).=20 More or less all of today's mobile phones support AMR-WB. If we can connect to them and support AMR-WB, transcoding won't be needed for getting HD audio from mobiles. G.722 is not available in mobile phones. If the WebRTC gateway connects directly to the mobile core network (be it VoIP-based or circuit switched), then the network interconnects mentioned above are not even needed, and AMR/AMR-WB audio can be passed through directly.=20 To support the deployment scenarios related to mobile networks, I propose to include a recommendation for AMR/AMR-WB, i.e. I prefer option 1.=20 Details of how to exactly do the recommendation can be worked out in the process. =20 Kind regards, Uwe Rauschenbach =20 From jmvalin@mozilla.com Tue Jan 15 09:55:52 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D942421F8712 for ; Tue, 15 Jan 2013 09:55:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.527 X-Spam-Level: X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, MIME_8BIT_HEADER=0.3, 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 tPtGekeB5XgM for ; Tue, 15 Jan 2013 09:55:52 -0800 (PST) Received: from smtp.mozilla.org (mx2.corp.phx1.mozilla.com [63.245.216.70]) by ietfa.amsl.com (Postfix) with ESMTP id 0A55821F8715 for ; Tue, 15 Jan 2013 09:55:52 -0800 (PST) Received: from [192.168.16.26] (pool-96-241-176-56.washdc.fios.verizon.net [96.241.176.56]) (Authenticated sender: jvalin@mozilla.com) by mx2.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 9C7C2F2031; Tue, 15 Jan 2013 09:55:50 -0800 (PST) Message-ID: <50F59825.5070002@mozilla.com> Date: Tue, 15 Jan 2013 12:55:49 -0500 From: Jean-Marc Valin User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: =?UTF-8?B?U3RlZmFuIEjDpWthbnNzb24gTEs=?= References: <50D2CC6A.4090500@ericsson.com> <50F56C2C.9070209@ericsson.com> In-Reply-To: <50F56C2C.9070209@ericsson.com> X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Call for Consensus Regarding Selecting Recommended 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, 15 Jan 2013 17:55:53 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/15/2013 09:48 AM, Stefan H￥kansson LK wrote: > 1. interoperability without quality degradations due to transcoding > with large installed legacy and existing services. Typical examples > are interconnection cases to major mobile or fixed communication > systems. Clearly interop with 3GPP voice services and HD Voice in > 3GPP and fixed networks is very important. The option with > transcoding should be avoided as - besides the equipment costs - it > is affecting the communication quality in terms of more coding > distortions and delay. I'm still in favor of Option 2 (no SHOULD), but if we had to pick a codec for legacy interop, I think Speex would be a good candidate. It's included in Flash 10 and up, which is currently installed (according to Adobe) on 500 million machines. This could provide WebRTC interop for all the users who don't have a WebRTC-capable browser. Jean-Marc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJQ9ZglAAoJEJ6/8sItn9q9jCIIAJ9i6Vr1AP17EJBAMlM+1J8p 59r/SRgkK5x3rlIEKC+WD1zb2ByxlWgBQ+Z5QOQ+kcdMxPt3I9LXsXWJmU8EcSRI jGrZm0vHU72vUgvD6vMdbS2aojfhOQP8LjGXGJIFDlxzreT4Ag0JXvgk1ZCCpca6 TTCk4xfVUV3ZzY+g2BfZrOz41im7AnGDBFROwrUUmPayU49tLRHP5huSDlxAkZil vkRAbk5VISSgjaRvt4YgquGK0S5n6txEPuYrgDoRDLYMlClhvcMHBZd+T+/0oYU4 f60FSBF8syQ9EAWp1by7HlaeZRr4Xj49vvrpGszVgR6ENe1CkEp179vSYZzpDJc= =9fNa -----END PGP SIGNATURE----- From adam@nostrum.com Tue Jan 15 11:00:35 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD02F11E80E5 for ; Tue, 15 Jan 2013 11:00:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.485 X-Spam-Level: X-Spam-Status: No, score=-102.485 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, SPF_PASS=-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 Pb+2AtjUb1LF for ; Tue, 15 Jan 2013 11:00:35 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 18FB511E80DC for ; Tue, 15 Jan 2013 11:00:35 -0800 (PST) Received: from Orochi.local (99-152-144-32.lightspeed.dllstx.sbcglobal.net [99.152.144.32]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r0FJ0SHa058839 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 15 Jan 2013 13:00:29 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <50F5A74C.3030203@nostrum.com> Date: Tue, 15 Jan 2013 13:00:28 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "Rauschenbach, Uwe (NSN - DE/Munich)" References: <50D2CC6A.4090500@ericsson.com><6515_1357907583_50F0067F_6515_1738_1_2842AD9A45C83B44B57635FD4831E60A0747CC@PEXCVZYM14.corporate.adroot.infra.ftgroup><580BEA5E3B99744AB1F5BFF5E9A3C67D16813E56EC@HE111648.emea1.cds.t-internal.com><50F41D97.1030508@nostrum.com><50F43ACA.80206@nostrum.com><50F44AF0.4060304@nostrum.com><50F4619F.7040208@nostrum.com> <7CBFD4609D19C043A4AC4FD8381C6E2602386636@DEMUEXC014.nsn-intra.net> In-Reply-To: <7CBFD4609D19C043A4AC4FD8381C6E2602386636@DEMUEXC014.nsn-intra.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 99.152.144.32 is authenticated by a trusted mechanism) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Consensus vs. Voting (was Re: Call for Consensus Regarding Selecting Recommended 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, 15 Jan 2013 19:00:36 -0000 On 1/15/13 11:40, Rauschenbach, Uwe (NSN - DE/Munich) wrote: > To support the deployment scenarios related to mobile networks, I > propose to include a recommendation for AMR/AMR-WB, i.e. I prefer option > 1. > Details of how to exactly do the recommendation can be worked out in the > process. I think what's getting lost here is whether people think these codecs should be "recommended" (English word, consult your dictionary) or "RECOMMENDED" (unfortunate IETF-specific term of art, consult RFC 2119). I agree with the former sentiment, but completely disagree with the latter. Which are you supporting? /a From Gerry.Flynn@VerizonWireless.com Wed Jan 16 09:37:30 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BE5221F8B69 for ; Wed, 16 Jan 2013 09:37:30 -0800 (PST) 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 DdpqUkSzP3td for ; Wed, 16 Jan 2013 09:37:29 -0800 (PST) Received: from vanguard.verizonwireless.com (vanguard.verizonwireless.com [162.115.35.70]) by ietfa.amsl.com (Postfix) with ESMTP id 3725E21F8B58 for ; Wed, 16 Jan 2013 09:37:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verizonwireless.com; i=@verizonwireless.com; l=0; q=dns/txt; s=prodmail; t=1358357062; x=1389893062; h=from:to:cc:date:subject:references:in-reply-to: content-transfer-encoding:mime-version; bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=; b=QuDm6s1crpzlkoXCjSO3AjUqXRptXU11WpAygSdF21EBFi0wqW6S24tK Z87VZOFAzNCNmv4gQtO/ww8T5gWJKpKaG2jirZhmjMRgwINS1V3ZROzZZ GZhSVR1iyhmLCqW; Received: from ohdub02exhub01.uswin.ad.vzwcorp.com ([10.97.42.201]) by vanguard.verizonwireless.com with ESMTP; 16 Jan 2013 09:24:09 -0800 Received: from OHDUB02EXCV33.uswin.ad.vzwcorp.com ([10.97.42.179]) by OHDUB02EXHUB01.uswin.ad.vzwcorp.com ([10.97.42.201]) with mapi; Wed, 16 Jan 2013 12:36:24 -0500 From: "Flynn, Gerry J" To: "rtcweb@ietf.org" Date: Wed, 16 Jan 2013 12:36:23 -0500 Thread-Topic: [rtcweb] Call for Consensus Regarding Selecting Recommended Audio Codecs Thread-Index: Ac3zL3pmQ21KI6lHRG+ADs05bk33QQA4FOQw References: <50D2CC6A.4090500@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 Message-Id: <20130116173729.3725E21F8B58@ietfa.amsl.com> Subject: Re: [rtcweb] Call for Consensus Regarding Selecting Recommended 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, 16 Jan 2013 17:37:30 -0000 Dear Colleagues It has been challenging to absorb all the excellent ideas and inputs aiming= to reach consensus around one of the two proposed options as there are val= id considerations for each. A degree of compromise is encouraged with reco= gnition of the extensive current and future deployment of AMR and AMR-WB as= well as the need for interoperability with new audio codecs and minimizati= on of transcoding. As such, Verizon endorses the e-mail by Magnus and supp= orts option 1. Gerry Flynn Verizon -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= Stefan H=E5kansson LK Sent: Tuesday, January 15, 2013 9:48 AM To: rtcweb@ietf.org Subject: Re: [rtcweb] Call for Consensus Regarding Selecting Recommended Au= dio Codecs On 2012-12-20 09:29, Magnus Westerlund wrote: > WG, > > As an outcome of the Vancouver IETF meeting codec discussions we did=20 > promise to run a call for consensus regarding if the WG was interested=20 > in specifying a small set of recommended audio codecs. We are sorry=20 > this has been delayed until now. > > The question for the call of consensus is between two options. > > 1) Run a process in the WG to select and specify a small set of=20 > audio/speech codecs that would be RECOMMNEDED to implement by a WebRTC=20 > end-points > > 2) Do nothing and let the already specified Mandatory to Implement=20 > Audio codecs be the only audio codecs mentioned in the WebRTC specificati= on. > > Please indicate your position by January 16th 2013. I see the following important reasons for creating a RECOMMENDED category: 1. interoperability without quality degradations due to transcoding with la= rge installed legacy and existing services. Typical examples are interconnection cases to major mobile or fixed comm= unication systems. Clearly interop with 3GPP voice services and HD Voice in= 3GPP and fixed networks is very important. The option with transcoding sho= uld be avoided as - besides the equipment costs - it is affecting the commu= nication quality in terms of more coding distortions and delay. 2. take advantage of deep codec specific integrations/optimizations. Typical examples are interconnection cases to major mobile systems which= bearers are highly optimized for a given codec specified for these systems= . For these systems operating with their 'native' codecs is beneficial not = only in terms of system capacity and efficiency but also from end-user pers= pective as it will allow least battery consumption in the mobile devices (d= ue to that hardware implementations for the codecs are often used) and prov= ide best robustness/coverage. At least interop to such native codecs in 3GP= P mobile networks is essential. This point partly overlaps with the previou= s but also covers cases where new codecs will get a deep system integration= . The alternative with transcoding in a GW should be avoided for the reason= s given above (avoiding extra distortions and delay). 3. future-proofness of specifications allowing to recommend new codecs that= turn out to be better/more efficient than existing mandatory codecs. As history has proven, even the best mandatory codec has a best-before d= ate. We should foresee the possibility to at least recommend such a better = codec at some stage when felt appropriate. At the same time, when creating a RECOMMENDED category, I think that it sho= uld be strictly limited to very few codecs only. At present I see a reasona= ble limit of 3 recommended codecs related to particular interop scenarios. = However, this number could be increased if new and better codecs are deemed= would in the future enter this category. So, my vote goes for option 1. Stefan > > Regards > > Magnus Westerlund > > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > _______________________________________________ > 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 rjsparks@nostrum.com Wed Jan 16 10:08:34 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52A1321F8A56 for ; Wed, 16 Jan 2013 10:08:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-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 5482y6fVM10G for ; Wed, 16 Jan 2013 10:08:33 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 98BE621F894E for ; Wed, 16 Jan 2013 10:08:33 -0800 (PST) Received: from unnumerable.local (pool-173-57-99-236.dllstx.fios.verizon.net [173.57.99.236]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r0GI8WUf018290 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Wed, 16 Jan 2013 12:08:32 -0600 (CST) (envelope-from rjsparks@nostrum.com) Message-ID: <50F6ECA0.3050104@nostrum.com> Date: Wed, 16 Jan 2013 12:08:32 -0600 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: rtcweb@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 173.57.99.236 is authenticated by a trusted mechanism) Subject: [rtcweb] RTCWeb testing at SIPit30 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 16 Jan 2013 18:08:34 -0000 We have set multiparty test time aside on Tuesday Feb 19 at SIPit 30 for testing with RTCWeb implementations. We'll focus on whatever the implementations show up can do, but we will at the very least work towards media interoperability. We are not requiring RTCWeb implementations to register for the full week (but you are certainly welcome to do so if you want to test for the full week). For more information, see www.sipit.net, or send me email. Thanks, RjS From uwe.rauschenbach@nsn.com Wed Jan 16 13:35:01 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C4B711E80FE for ; Wed, 16 Jan 2013 13:35:01 -0800 (PST) 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 jgiw6ERaFW2d for ; Wed, 16 Jan 2013 13:35:01 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id D7B5711E80FD for ; Wed, 16 Jan 2013 13:35:00 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id r0GLYxH6009272 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 16 Jan 2013 22:34:59 +0100 Received: from DEMUEXC047.nsn-intra.net ([10.159.32.93]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id r0GLYw7P021930; Wed, 16 Jan 2013 22:34:58 +0100 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by DEMUEXC047.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 16 Jan 2013 22:34:58 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 16 Jan 2013 22:34:57 +0100 Message-ID: <7CBFD4609D19C043A4AC4FD8381C6E2604798F@DEMUEXC014.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] Consensus vs. Voting (was Re: Call for Consensus Regarding Selecting Recommended Audio Codecs) Thread-Index: Ac3zUputkaJU8KaEQl6xBmFCqe97dgA2JI0g References: <50D2CC6A.4090500@ericsson.com><6515_1357907583_50F0067F_6515_1738_1_2842AD9A45C83B44B57635FD4831E60A0747CC@PEXCVZYM14.corporate.adroot.infra.ftgroup><580BEA5E3B99744AB1F5BFF5E9A3C67D16813E56EC@HE111648.emea1.cds.t-internal.com><50F41D97.1030508@nostrum.com><50F43ACA.80206@nostrum.com><50F44AF0.4060304@nostrum.com><50F4619F.7040208@nostrum.com> <7CBFD4609D19C043A4AC4FD8381C6E2602386636@DEMUEXC014.nsn-intra.net> <50F5A74C.3030203@nostrum.com> From: "Rauschenbach, Uwe (NSN - DE/Munich)" To: "ext Adam Roach" X-OriginalArrivalTime: 16 Jan 2013 21:34:58.0821 (UTC) FILETIME=[55797350:01CDF431] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 1304 X-purgate-ID: 151667::1358372099-0000215D-6924D2BB/0-0/0-0 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Consensus vs. Voting (was Re: Call for Consensus Regarding Selecting Recommended 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, 16 Jan 2013 21:35:01 -0000 > From: ext Adam Roach [mailto:adam@nostrum.com] > > On 1/15/13 11:40, Rauschenbach, Uwe (NSN - DE/Munich) wrote: > > To support the deployment scenarios related to mobile networks, I > > propose to include a recommendation for AMR/AMR-WB, i.e. I prefer > option > > 1. > > Details of how to exactly do the recommendation can be worked out in > the > > process. > > I think what's getting lost here is whether people think these codecs > should be "recommended" (English word, consult your dictionary) or > "RECOMMENDED" (unfortunate IETF-specific term of art, consult RFC > 2119). > > I agree with the former sentiment, but completely disagree with the > latter. > > Which are you supporting? > > /a I want to make the point that w.r.t. easy interworking with legacy = telephony clients, there's value in writing spec text that guides = developers w.r.t. additional non-MTI audio codecs. Being aware that there seem to be concerns regarding the use of RFC 2119 = terminology for that, I suggest that we take this in two steps: 1) get consensus to produce spec text for the inclusion of = additional non-MTI audio codecs (such as AMR, AMR-WB, G.722), 2) subsequently, work out whether we "RECOMMEND" or "recommend" = these codecs. Kind regards, Uwe From martin.thomson@gmail.com Wed Jan 16 15:29:23 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE77811E809C for ; Wed, 16 Jan 2013 15:29:23 -0800 (PST) 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 kF0yOK5DBT9k for ; Wed, 16 Jan 2013 15:29:23 -0800 (PST) Received: from mail-la0-f52.google.com (mail-la0-f52.google.com [209.85.215.52]) by ietfa.amsl.com (Postfix) with ESMTP id 9733121F8828 for ; Wed, 16 Jan 2013 15:29:22 -0800 (PST) Received: by mail-la0-f52.google.com with SMTP id fq12so1993207lab.25 for ; Wed, 16 Jan 2013 15:29:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=Zyayigo75w8haeLZn437k6rfcFMZSUaIckTckLuk2QQ=; b=NV5nJzb9yr+KYQReVZr3XTBRA7AZbguFeSq1ucjXuuUsMYWZMk6aResIQ9qV8K38Dr ml9286sUUvxtoSqyvC0DtjJrc5QPkF++gJfYrMOig9Sz+erxjMiqwF1ErXfL0fugsGUZ oFjpjRZbuFICjIwT31qXtQ8dtpCIWAmauSQcOitzd7KzRYorgsbCfcpBe5Ebjl+PgRCX OutzAEobrrcjkZfxM00dAM/tIk8e7TmbrP+b8yGADLfl5jTC8+pYGsWq/+lY0WrEiHih Uew3+rBv0yJZbvVOfPUbZo/zWMn1ofmLZXec/C0ts2b1J3KInQVWlqIbIYhBdlyb2Jb7 q1QQ== MIME-Version: 1.0 X-Received: by 10.152.127.202 with SMTP id ni10mr2896938lab.6.1358378961152; Wed, 16 Jan 2013 15:29:21 -0800 (PST) Received: by 10.112.57.20 with HTTP; Wed, 16 Jan 2013 15:29:21 -0800 (PST) In-Reply-To: <913383AAA69FF945B8F946018B75898A148E07CB@xmb-rcd-x10.cisco.com> References: <913383AAA69FF945B8F946018B75898A148E07CB@xmb-rcd-x10.cisco.com> Date: Wed, 16 Jan 2013 15:29:21 -0800 Message-ID: From: Martin Thomson To: "Tirumaleswar Reddy (tireddy)" Content-Type: text/plain; charset=UTF-8 Cc: John Kaippallimalil , "rtcweb@ietf.org" , "bpatil@ovi.com" Subject: Re: [rtcweb] FW: New Version Notification for draft-reddy-rtcweb-mobile-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: Wed, 16 Jan 2013 23:29:23 -0000 There are many characteristics of mobile networks that make poorly designed applications perform poorly. Honestly, WebRTC isn't special in this regard. I'd prefer to see something that is less negatively worded that instead aims to improve awareness of the limitations of the network and how a well-designed application might avoid the problems that these cause. See: http://developer.android.com/training/efficient-downloads/efficient-network-access.html#RadioStateMachine For example, I find the assertion that is made here, namely multiplexing will degrade the quality of experiences, to be specious. The assertion is true, but it presumes that multiplexing is or must be used. --Martin On 14 January 2013 06:35, Tirumaleswar Reddy (tireddy) wrote: > Hi all,' > > > > This document describes a set of scenarios in which WebRTC applications have > problems in Mobile Networks related to QOS, Mobility (SIPTO). Thanks to > Magnus, Markus, Dan and Basavraj for their help and comments. The URL of the > new draft: > > > > http://tools.ietf.org/html/draft-reddy-rtcweb-mobile-00 > > > > comments and suggestions are welcome. > > > > Best Regards, > > --authors. > > > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Monday, January 14, 2013 1:40 PM > To: Tirumaleswar Reddy (tireddy) > Cc: john.kaippallimalil@huawei.com; Ram Mohan R (rmohanr) > Subject: New Version Notification for draft-reddy-rtcweb-mobile-00.txt > > > > > > A new version of I-D, draft-reddy-rtcweb-mobile-00.txt > > has been successfully submitted by Tirumaleswar Reddy and posted to the > > IETF repository. > > > > Filename: draft-reddy-rtcweb-mobile > > Revision: 00 > > Title: Problems with WebRTC in Mobile Networks > > Creation date: 2013-01-14 > > WG ID: Individual Submission > > Number of pages: 14 > > URL: > http://www.ietf.org/internet-drafts/draft-reddy-rtcweb-mobile-00.txt > > Status: http://datatracker.ietf.org/doc/draft-reddy-rtcweb-mobile > > Htmlized: http://tools.ietf.org/html/draft-reddy-rtcweb-mobile-00 > > > > > > Abstract: > > This document describes a set of scenarios in which WebRTC > > applications have problems in Mobile Networks. > > > > > > > > > > The IETF Secretariat > > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From martin.thomson@gmail.com Wed Jan 16 16:03:44 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B46621F876E for ; Wed, 16 Jan 2013 16:03:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2, 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 aARw6fre0hsg for ; Wed, 16 Jan 2013 16:03:43 -0800 (PST) Received: from mail-la0-f53.google.com (mail-la0-f53.google.com [209.85.215.53]) by ietfa.amsl.com (Postfix) with ESMTP id 4920421F875C for ; Wed, 16 Jan 2013 16:03:40 -0800 (PST) Received: by mail-la0-f53.google.com with SMTP id fn20so2066811lab.12 for ; Wed, 16 Jan 2013 16:03:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=o6m3LVeM85PaH+BwA+2zC65BkZyWY4H8vF8civQlC84=; b=1DY08SZKbwTwYzgwLu5wawE+VMsvsGlIHF13Mo1PETLBNry46AQnTsmjlORdOyN9sg wKQDih/74nqSefyV/xXw4NCJurPlmf5EWJKA6uFZ639P8IY5slWR6Ti8RlCwWaeCfGhL bbZPF1kHG0Z++rpRM5czSl6sp6zVa6ybn+/atH8XbrDr7BxjlQVQCjfPQNxlcKixhjfC PpN7jwifZGhhAwJF6VQqAjyKcTpz7ocL/6VUVBKVgy5GeOQTbslVfirzXACteH+esQhh vEO13cXsl2WQOpkUz+jAA6PqvbBlM65brN7fqzfmfcMnyPsF1l9YLXokKs6EfRWbSXsX 8rWA== MIME-Version: 1.0 X-Received: by 10.112.98.232 with SMTP id el8mr1346010lbb.121.1358381019012; Wed, 16 Jan 2013 16:03:39 -0800 (PST) Received: by 10.112.57.20 with HTTP; Wed, 16 Jan 2013 16:03:38 -0800 (PST) In-Reply-To: <50F5A74C.3030203@nostrum.com> References: <50D2CC6A.4090500@ericsson.com> <6515_1357907583_50F0067F_6515_1738_1_2842AD9A45C83B44B57635FD4831E60A0747CC@PEXCVZYM14.corporate.adroot.infra.ftgroup> <580BEA5E3B99744AB1F5BFF5E9A3C67D16813E56EC@HE111648.emea1.cds.t-internal.com> <50F41D97.1030508@nostrum.com> <50F43ACA.80206@nostrum.com> <50F44AF0.4060304@nostrum.com> <50F4619F.7040208@nostrum.com> <7CBFD4609D19C043A4AC4FD8381C6E2602386636@DEMUEXC014.nsn-intra.net> <50F5A74C.3030203@nostrum.com> Date: Wed, 16 Jan 2013 16:03:38 -0800 Message-ID: From: Martin Thomson To: Adam Roach Content-Type: text/plain; charset=UTF-8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Consensus vs. Voting (was Re: Call for Consensus Regarding Selecting Recommended 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, 17 Jan 2013 00:03:44 -0000 On 15 January 2013 11:00, Adam Roach wrote: > what's getting lost here is whether people think these codecs should be > "recommended" (English word, consult your dictionary) or "RECOMMENDED" > (unfortunate IETF-specific term of art, consult RFC 2119). Since Adam is having so much luck, I'd like to get a clearer answer to this questions from the proponents of the 2119 SHOULD: If we don't say "webrtc implementations SHOULD implement G.722/AMR/AMR-WB", what is the failure mode for your application? Keeping in mind that - because this isn't 2119 MUST - you have to expect that some non-negligible proportion of clients will not support this no matter how much extra ink we using in printing large letters, how much pain does this really cause you? I expect that the transcoding costs are what this come down to. Does anyone care to quantify this? From matthew.kaufman@skype.net Wed Jan 16 16:25:31 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA0F211E80EA for ; Wed, 16 Jan 2013 16:25:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2] 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 8082G-ZWcPXm for ; Wed, 16 Jan 2013 16:25:31 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (na01-bl2-obe.ptr.protection.outlook.com [65.55.169.29]) by ietfa.amsl.com (Postfix) with ESMTP id D93F511E80E5 for ; Wed, 16 Jan 2013 16:25:30 -0800 (PST) Received: from BY2FFO11FD005.protection.gbl (10.1.15.203) by BY2FFO11HUB012.protection.gbl (10.1.14.83) with Microsoft SMTP Server (TLS) id 15.0.596.13; Thu, 17 Jan 2013 00:25:21 +0000 Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD005.mail.protection.outlook.com (10.1.14.126) with Microsoft SMTP Server (TLS) id 15.0.596.13 via Frontend Transport; Thu, 17 Jan 2013 00:25:21 +0000 Received: from TK5EX14MBXC274.redmond.corp.microsoft.com ([169.254.3.144]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.02.0318.003; Thu, 17 Jan 2013 00:24:23 +0000 From: Matthew Kaufman To: Martin Thomson , Adam Roach Thread-Topic: [rtcweb] Consensus vs. Voting (was Re: Call for Consensus Regarding Selecting Recommended Audio Codecs) Thread-Index: AQHN81KfpB57SfiuGUmjZvYBMt3d/5hMpY4AgAAFJBA= Date: Thu, 17 Jan 2013 00:24:22 +0000 Message-ID: References: <50D2CC6A.4090500@ericsson.com> <6515_1357907583_50F0067F_6515_1738_1_2842AD9A45C83B44B57635FD4831E60A0747CC@PEXCVZYM14.corporate.adroot.infra.ftgroup> <580BEA5E3B99744AB1F5BFF5E9A3C67D16813E56EC@HE111648.emea1.cds.t-internal.com> <50F41D97.1030508@nostrum.com> <50F43ACA.80206@nostrum.com> <50F44AF0.4060304@nostrum.com> <50F4619F.7040208@nostrum.com> <7CBFD4609D19C043A4AC4FD8381C6E2602386636@DEMUEXC014.nsn-intra.net> <50F5A74C.3030203@nostrum.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.35] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(79102001)(16406001)(51856001)(23726001)(59766001)(55846006)(74502001)(74662001)(44976002)(77982001)(47446002)(54356001)(76482001)(31966008)(53806001)(47776002)(4396001)(49866001)(47976001)(50466001)(50986001)(56776001)(47736001)(54316002)(56816002)(46102001)(33656001)(5343655001)(46406002); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB012; H:TK5EX14HUBC104.redmond.corp.microsoft.com; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0729050452 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Consensus vs. Voting (was Re: Call for Consensus Regarding Selecting Recommended 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, 17 Jan 2013 00:25:31 -0000 From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= Martin Thomson > Since Adam is having so much luck, I'd like to get a clearer answer to th= is questions from the proponents of the 2119 SHOULD: > If we don't say "webrtc implementations SHOULD implement G.722/AMR/AMR-WB= ", what is the failure mode for your application? > Keeping in mind that - because this isn't 2119 MUST - you have to expect = that some non-negligible proportion of clients will not support this no mat= ter how > much extra ink we using in printing large letters, how much pain does thi= s really cause you? Actually, as there's only a small finite number of browser vendors, all of = them with their own constraints about which codecs they can/will include, a= nd several of them will ship before the spec is anywhere near final either = here or in W3C, it wouldn't matter even if it *was* a 2119 MUST, would it? Matthew Kaufman From keith.drage@alcatel-lucent.com Wed Jan 16 16:27:18 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62DF311E80E7 for ; Wed, 16 Jan 2013 16:27:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.816 X-Spam-Level: X-Spam-Status: No, score=-109.816 tagged_above=-999 required=5 tests=[AWL=2.433, BAYES_00=-2.599, GB_I_LETTER=-2, 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 UZb6fgiRvNK4 for ; Wed, 16 Jan 2013 16:27:17 -0800 (PST) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by ietfa.amsl.com (Postfix) with ESMTP id 9435511E80E5 for ; Wed, 16 Jan 2013 16:27:17 -0800 (PST) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r0H0RFwH017504 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 17 Jan 2013 01:27:15 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Thu, 17 Jan 2013 01:27:15 +0100 From: "DRAGE, Keith (Keith)" To: Martin Thomson , Adam Roach Date: Thu, 17 Jan 2013 01:27:13 +0100 Thread-Topic: [rtcweb] Consensus vs. Voting (was Re: Call for Consensus Regarding Selecting Recommended Audio Codecs) Thread-Index: Ac30RiHDIN4HPxgmQ0WVkri8v0U+rwAApB3g Message-ID: References: <50D2CC6A.4090500@ericsson.com> <6515_1357907583_50F0067F_6515_1738_1_2842AD9A45C83B44B57635FD4831E60A0747CC@PEXCVZYM14.corporate.adroot.infra.ftgroup> <580BEA5E3B99744AB1F5BFF5E9A3C67D16813E56EC@HE111648.emea1.cds.t-internal.com> <50F41D97.1030508@nostrum.com> <50F43ACA.80206@nostrum.com> <50F44AF0.4060304@nostrum.com> <50F4619F.7040208@nostrum.com> <7CBFD4609D19C043A4AC4FD8381C6E2602386636@DEMUEXC014.nsn-intra.net> <50F5A74C.3030203@nostrum.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.84 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Consensus vs. Voting (was Re: Call for Consensus Regarding Selecting Recommended 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, 17 Jan 2013 00:27:18 -0000 I do not think transcoding is the only issue. If you refer back to the earlier mail from Stephane, there was also the poi= nt, which I agree with, that if you have a licensed version of any codec on= your device, ideally you want your browser to support that codec. You don'= t want to be told that you cannot talk to another user who only has codec B= , when you have already paid the license fee to use codec B, just because y= our browser vendor decides it is not its favourite codec. There are an awful lot of licensed AMR codecs out there that people still w= ant to use. Regards Keith > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf > Of Martin Thomson > Sent: 17 January 2013 00:04 > To: Adam Roach > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] Consensus vs. Voting (was Re: Call for Consensus > Regarding Selecting Recommended Audio Codecs) >=20 > On 15 January 2013 11:00, Adam Roach wrote: > > what's getting lost here is whether people think these codecs should be > > "recommended" (English word, consult your dictionary) or "RECOMMENDED" > > (unfortunate IETF-specific term of art, consult RFC 2119). >=20 > Since Adam is having so much luck, I'd like to get a clearer answer to > this questions from the proponents of the 2119 SHOULD: >=20 > If we don't say "webrtc implementations SHOULD implement > G.722/AMR/AMR-WB", what is the failure mode for your application? > Keeping in mind that - because this isn't 2119 MUST - you have to > expect that some non-negligible proportion of clients will not support > this no matter how much extra ink we using in printing large letters, > how much pain does this really cause you? >=20 > I expect that the transcoding costs are what this come down to. Does > anyone care to quantify this? > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From martin.thomson@gmail.com Wed Jan 16 16:38:56 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB3EC11E80E7 for ; Wed, 16 Jan 2013 16:38:56 -0800 (PST) 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 q1ZnX24iBfWd for ; Wed, 16 Jan 2013 16:38:56 -0800 (PST) Received: from mail-wg0-f54.google.com (mail-wg0-f54.google.com [74.125.82.54]) by ietfa.amsl.com (Postfix) with ESMTP id 1612811E80E5 for ; Wed, 16 Jan 2013 16:38:55 -0800 (PST) Received: by mail-wg0-f54.google.com with SMTP id fg15so1247149wgb.21 for ; Wed, 16 Jan 2013 16:38:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=Kh/X1MAlV5wD/ClBqxU4tg2AAO2XsmNlhgJVVrF/8+E=; b=pO3dT2D9msvTTlGAaJSDhHZRJUAeG6sINt8EMEgx5vFus0Q6CpMqc9rakaBiJXLX5+ 1inBPg6k/Pftqts6sgww9DUeJlQ53OoOQsoSK3qM2r14R3QMo1wvrfe2lWEpeaQWMpYw a9IwLpKXVndh94BjN63ZRqC2fqfIL1ei5R5lxFmGzwI98+3FXTlgU0j4xkUu5PtcLfw3 mDduxp0L0bAf5EjvbSbtbWJZ37n067sa6TjyTcKJqSgXx8J3lF+ZT/DC2ZRqt52XYJRp WIBOT10CqIAN3I7HE4riqD8og/FTaG40PLD0Usn+ljeoPE9pSagj+fN2EQ9fQnV7YG5F TIAA== MIME-Version: 1.0 X-Received: by 10.194.108.101 with SMTP id hj5mr5407531wjb.6.1358383135166; Wed, 16 Jan 2013 16:38:55 -0800 (PST) Received: by 10.180.164.174 with HTTP; Wed, 16 Jan 2013 16:38:54 -0800 (PST) In-Reply-To: References: <50D2CC6A.4090500@ericsson.com> <6515_1357907583_50F0067F_6515_1738_1_2842AD9A45C83B44B57635FD4831E60A0747CC@PEXCVZYM14.corporate.adroot.infra.ftgroup> <580BEA5E3B99744AB1F5BFF5E9A3C67D16813E56EC@HE111648.emea1.cds.t-internal.com> <50F41D97.1030508@nostrum.com> <50F43ACA.80206@nostrum.com> <50F44AF0.4060304@nostrum.com> <50F4619F.7040208@nostrum.com> <7CBFD4609D19C043A4AC4FD8381C6E2602386636@DEMUEXC014.nsn-intra.net> <50F5A74C.3030203@nostrum.com> Date: Wed, 16 Jan 2013 16:38:54 -0800 Message-ID: From: Martin Thomson To: "DRAGE, Keith (Keith)" Content-Type: text/plain; charset=UTF-8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Consensus vs. Voting (was Re: Call for Consensus Regarding Selecting Recommended 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, 17 Jan 2013 00:38:57 -0000 On 16 January 2013 16:27, DRAGE, Keith (Keith) wrote: > there was also the point, which I agree with, that if you have a licensed version of any codec on your device, ideally you want your browser to support that codec I think that misses the point of my question. I asked about what specifically do you consider to be the cost of this particular failure? However much we might want these things to not happen, I want to know what the consequences are. As Matthew observes, even MUST might be insufficient to convince an implementation to support a codec because the most effective (and perhaps only) way to convince someone to implement something is to show that it increases ROI. So, I want to know the cost that you incur if this is not SHOULD. Ideally, what fails to interoperate in this scenario? From adam@nostrum.com Wed Jan 16 18:28:09 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B640321F861A for ; Wed, 16 Jan 2013 18:28:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.5 X-Spam-Level: X-Spam-Status: No, score=-102.5 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, SPF_PASS=-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 TkLVBGE2ASEP for ; Wed, 16 Jan 2013 18:28:09 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 2549821F857C for ; Wed, 16 Jan 2013 18:28:08 -0800 (PST) Received: from Orochi.local (99-152-144-32.lightspeed.dllstx.sbcglobal.net [99.152.144.32]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r0H2RxfB073453 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 16 Jan 2013 20:27:59 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <50F761AE.9080408@nostrum.com> Date: Wed, 16 Jan 2013 20:27:58 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "DRAGE, Keith (Keith)" References: <50D2CC6A.4090500@ericsson.com> <6515_1357907583_50F0067F_6515_1738_1_2842AD9A45C83B44B57635FD4831E60A0747CC@PEXCVZYM14.corporate.adroot.infra.ftgroup> <580BEA5E3B99744AB1F5BFF5E9A3C67D16813E56EC@HE111648.emea1.cds.t-internal.com> <50F41D97.1030508@nostrum.com> <50F43ACA.80206@nostrum.com> <50F44AF0.4060304@nostrum.com> <50F4619F.7040208@nostrum.com> <7CBFD4609D19C043A4AC4FD8381C6E2602386636@DEMUEXC014.nsn-intra.net> <50F5A74C.3030203@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 99.152.144.32 is authenticated by a trusted mechanism) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Consensus vs. Voting (was Re: Call for Consensus Regarding Selecting Recommended 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, 17 Jan 2013 02:28:09 -0000 On 1/16/13 18:27, DRAGE, Keith (Keith) wrote: > If you refer back to the earlier mail from Stephane, there was also the point, which I agree with, that if you have a licensed version of any codec on your device, ideally you want your browser to support that codec. You don't want to be told that you cannot talk to another user who only has codec B, when you have already paid the license fee to use codec B, just because your browser vendor decides it is not its favourite codec. That's not an argument for "implementations SHOULD implement codec X," which is the question at hand (where X is a set of one or more specific, named codecs). What you're putting forth is a vaguely related argument for "implementations SHOULD make use of all codecs provided by the underlying platform on which they are deployed." But that's a very different question. And, to be clear, if the other device that you're talking to "only has codec B," where B is not "the set of both G.711 and Opus," then we're already wandering off into the realm of fully non-compliant implementations. /a From fluffy@cisco.com Wed Jan 16 22:30:15 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FC1E21F8AD4 for ; Wed, 16 Jan 2013 22:30:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.411 X-Spam-Level: X-Spam-Status: No, score=-110.411 tagged_above=-999 required=5 tests=[AWL=0.188, 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 f+IZXt1dwoFI for ; Wed, 16 Jan 2013 22:30:14 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 27E1221F87E0 for ; Wed, 16 Jan 2013 22:30:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=410; q=dns/txt; s=iport; t=1358404214; x=1359613814; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=IY+aDpEoCe6nBw5337zx3i+6IoublY3dr5hqGvRrOJU=; b=Or27TMb8MwarbwA486HkSStoQHPAoyyHajmW+vei9T6bSlZKCcVYgK6Z vWHI8Hmo2JLr6aGBJbkW5QuteZkBDEEYYwGNz6YEj1FP7XfwtBCQkZ4rH LuYIhmwCsVZYQb1mHm+K+KpK2nky4pwTSM6YNwSeJdMcH5I7+KeBiLLiZ 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap0FAFmZ91CtJV2c/2dsb2JhbABEhXe4ERZzgh4BAQEDATo9AgULAgEIIhQQIRElAgQOBQiHfwMJBrETDYgdjAiET2EDlDaNDYUSgnWCJA X-IronPort-AV: E=Sophos;i="4.84,484,1355097600"; d="scan'208";a="163407433" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-1.cisco.com with ESMTP; 17 Jan 2013 06:30:13 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r0H6UDED023586 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 17 Jan 2013 06:30:13 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.197]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0318.004; Thu, 17 Jan 2013 00:30:13 -0600 From: "Cullen Jennings (fluffy)" To: Martin Thomson Thread-Topic: [rtcweb] New Version Notification for draft-reddy-rtcweb-mobile-00.txt Thread-Index: AQHN9Hwb5M4Q+gzQ+0yqZExdDQjulQ== Date: Thu, 17 Jan 2013 06:30:13 +0000 Message-ID: References: <913383AAA69FF945B8F946018B75898A148E07CB@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.20.249.164] Content-Type: text/plain; charset="us-ascii" Content-ID: <337456CB08F6EE42ADD27EFC9AB7244F@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] New Version Notification for draft-reddy-rtcweb-mobile-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: Thu, 17 Jan 2013 06:30:15 -0000 On Jan 16, 2013, at 4:29 PM, Martin Thomson wrot= e: > For example, I find the assertion that is made here, namely > multiplexing will degrade the quality of experiences, to be specious. > The assertion is true, but it presumes that multiplexing is or must be > used. agree, to go one step further, I don't even agree that it will degrade expe= rience on many networks From roman@telurix.com Thu Jan 17 02:31:50 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37ADE21F86CA for ; Thu, 17 Jan 2013 02:31:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.778 X-Spam-Level: X-Spam-Status: No, score=-3.778 tagged_above=-999 required=5 tests=[AWL=1.198, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2, 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 cKMZcEwhqtGO for ; Thu, 17 Jan 2013 02:31:49 -0800 (PST) Received: from mail-wi0-x229.google.com (wi-in-x0229.1e100.net [IPv6:2a00:1450:400c:c05::229]) by ietfa.amsl.com (Postfix) with ESMTP id 0D9AA21F87C8 for ; Thu, 17 Jan 2013 02:31:48 -0800 (PST) Received: by mail-wi0-f169.google.com with SMTP id hq12so4445222wib.2 for ; Thu, 17 Jan 2013 02:31:47 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-received:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=PTVfEzZZoL4OTi4PbXhDuL7cKCX2lbApol5i9w/YqD4=; b=b48x1IOwF01eGclLqGj8JjJyJ9h4qyGyozzcPwS/2gnJdi0R3dfPidHnUh8+CLyiG0 Oa7/etCO7zVmGPq2+ZM5atvp/1SGaaUNJu+dW8VC7Krg1DF3heGUKbsgEJEF4hBFtLm7 GbgKwzBLHxrJb7xNRuzMZuJn4iJKArATjnRhC9AeozELfRDK4HlCYPdl1TdHoN/94bIn X1/xudzqsP+lokEfAtc/NP1JATw36wzzz4J+cRaJImfWr2ZMCa34qlaxucjl34fsNkFW LiBgWuSX8ye5k+xrdAr29AJWQHy5bdP66H1YsJ+rvS5PXz106pozZFwPFN2wokO3NnvM FuUw== X-Received: by 10.194.77.13 with SMTP id o13mr7288376wjw.58.1358418707772; Thu, 17 Jan 2013 02:31:47 -0800 (PST) Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) by mx.google.com with ESMTPS id l5sm1634650wia.10.2013.01.17.02.31.46 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 17 Jan 2013 02:31:46 -0800 (PST) Received: by mail-wi0-f176.google.com with SMTP id hm6so4347757wib.3 for ; Thu, 17 Jan 2013 02:31:45 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.181.13.75 with SMTP id ew11mr7301633wid.9.1358418705212; Thu, 17 Jan 2013 02:31:45 -0800 (PST) Received: by 10.216.16.134 with HTTP; Thu, 17 Jan 2013 02:31:44 -0800 (PST) In-Reply-To: References: <50D2CC6A.4090500@ericsson.com> <6515_1357907583_50F0067F_6515_1738_1_2842AD9A45C83B44B57635FD4831E60A0747CC@PEXCVZYM14.corporate.adroot.infra.ftgroup> <580BEA5E3B99744AB1F5BFF5E9A3C67D16813E56EC@HE111648.emea1.cds.t-internal.com> <50F41D97.1030508@nostrum.com> <50F43ACA.80206@nostrum.com> <50F44AF0.4060304@nostrum.com> <50F4619F.7040208@nostrum.com> <7CBFD4609D19C043A4AC4FD8381C6E2602386636@DEMUEXC014.nsn-intra.net> <50F5A74C.3030203@nostrum.com> Date: Thu, 17 Jan 2013 05:31:44 -0500 Message-ID: From: Roman Shpount To: Martin Thomson Content-Type: multipart/alternative; boundary=f46d04388e1b6166c804d379807b X-Gm-Message-State: ALoCoQnRqsuD68uRY8OSDd7gYMBhBP2s/89/HOdCIb4kWVZRih4Rey0d+hoFDInDy+8uegJjPhnh Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Consensus vs. Voting (was Re: Call for Consensus Regarding Selecting Recommended 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, 17 Jan 2013 10:31:50 -0000 --f46d04388e1b6166c804d379807b Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jan 16, 2013 at 7:03 PM, Martin Thomson wrote: > If we don't say "webrtc implementations SHOULD implement > G.722/AMR/AMR-WB", what is the failure mode for your application? > Keeping in mind that - because this isn't 2119 MUST - you have to > expect that some non-negligible proportion of clients will not support > this no matter how much extra ink we using in printing large letters, > how much pain does this really cause you? > > I expect that the transcoding costs are what this come down to. Does > anyone care to quantify this? > If common codecs are not implemented in the browser this would mean transcoding will need to be performed on some sort of server-side media gateway. There are three distinct issues we need to take into account when dealing with transcoding. I would list them in what, at least from my point of view, is the order of importance: 1. If you need to do trancoding, you will need to implement a jitter buffer on the transcoding media gateway. ICE processing and SRTP en/decoding can be performed on out of order packets as they are received. You cannot transcode out of order audio. This means audio packets would need to be delayed by the jitter buffer size. In cases of good internet connection this means 40 ms jitter buffer delay. In cases of consumer internet in US (somebody sitting on a DSL connection at home behind a WiFi router) you are typically looking at 60-80 ms jitter buffer delay. If you are dealing with international internet connections jitter of 150 ms to 200 ms is not unheard of. This means an additional delay due to jitter buffering of 40 ms (best case) to 200 ms. This is in addition to any other delays that are already present on the audio path. Adding an extra 100 ms of delay can make audio conversions very awkward or unusable. On the other hand, if the gateway were performing just ICE and SRTP, it would introduce 1-2 ms of delay at most (In this case I am talking about a software based implementation running on generic server hardware. A dedicated DSP solution would probably be even faster). 2. Audio artifacts due to transcoding. Apart from usual audio degradation due to transcoding (OPUS transcoded to AMR would sound worse then OPUS or AMR), we would also deal with double packet loss concealment. Media gateway will conceal lost packets when transcoding. Client will conceal lost packet received from the gateway. This would actually sound worse then PLC performed in one place. 3. Scalability of the transcoding gateway. Gateway which just deals with ICE processing and SRTP en/decoding can handle from 2000 to 10000 concurrent call when running on a generic server CPU (different scalability is due to differences in CPU performance and presence of AES specific instructions). Gateway that would do G.722 to OPUS transcoding would most likely handle from 500 to 1000 concurrent calls. We are looking at 10x difference in performance. If we need to transcode AMR to OPUS the difference would be even higher. This translates in 10x difference in hardware, data center, power, and operations costs. _____________ Roman Shpount --f46d04388e1b6166c804d379807b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Jan 16, 2013 at 7:03 PM, Martin Thom= son <martin.thomson@gmail.com> wrote:
If we don't say "webrtc implementations SHOULD im= plement
G.722/AMR/AMR-WB", what is the failure mode for your application?
Keeping in mind that - because this isn't 2119 MUST - you have to
expect that some non-negligible proportion of clients will not support
this no matter how much extra ink we using in printing large letters,
how much pain does this really cause you?

I expect that the transcoding costs are what this come down to. =A0Does
anyone care to quantify this?

If common codecs = are not implemented in the browser this would mean transcoding will need to= be performed on some sort of server-side media gateway. There are three di= stinct issues we need to take into account when dealing with transcoding. I= would list them in what, at least from my point of view, is the order of i= mportance:

1. If you need to do trancoding, you will need to implement a jitter bu= ffer on the transcoding media gateway. ICE processing and SRTP en/decoding = can be performed on out of order packets as they are received. You cannot t= ranscode out of order audio. This means audio packets would need to be dela= yed by the jitter buffer size. In cases of good internet connection this me= ans 40 ms jitter buffer delay. In cases of consumer internet in US (somebod= y sitting on a DSL connection at home behind a WiFi router) you are typical= ly looking at 60-80 ms jitter buffer delay. If you are dealing with interna= tional internet connections jitter of 150 ms to 200 ms is not unheard of. T= his means an additional delay due to jitter buffering of 40 ms (best case) = to 200 ms. This is in addition to any other delays that are already present= on the audio path. Adding an extra 100 ms of delay can make audio conversi= ons very awkward or unusable. On the other hand, if the gateway were perfor= ming just ICE and SRTP, it would introduce 1-2 ms of delay at most (In this= case I am talking about a software based implementation running on generic= server hardware. A dedicated DSP solution would probably be even faster).<= br>
2. Audio artifacts due to transcoding. Apart from usual audio degradati= on due to transcoding (OPUS transcoded to AMR would sound worse then OPUS o= r AMR), we would also deal with double packet loss concealment. Media gatew= ay will conceal lost packets when transcoding. Client will conceal lost pac= ket received from the gateway. This would actually sound worse then PLC per= formed in one place.

3. Scalability of the transcoding gateway. Gateway which just deals wit= h ICE processing and SRTP en/decoding can handle from 2000 to 10000 concurr= ent call when running on a generic server CPU (different scalability is due= to differences in CPU performance and presence of AES specific instruction= s). Gateway that would do G.722 to OPUS transcoding would most likely handl= e from 500 to 1000 concurrent calls. We are looking at 10x difference in pe= rformance. If we need to transcode AMR to OPUS the difference would be even= higher. This translates in 10x difference in hardware, data center, power,= and operations costs.
_____________
Roman Shpount
--f46d04388e1b6166c804d379807b-- From radhika.r.roy.civ@mail.mil Thu Jan 17 04:12:39 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAF7B21F8B19 for ; Thu, 17 Jan 2013 04:12:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2] 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 lR74cp1m4wM5 for ; Thu, 17 Jan 2013 04:12:38 -0800 (PST) Received: from edge-cols.mail.mil (edge-cols.mail.mil [131.64.100.6]) by ietfa.amsl.com (Postfix) with ESMTP id 91D9921F8AE6 for ; Thu, 17 Jan 2013 04:12:38 -0800 (PST) Received: from UCOLHP3M.easf.csd.disa.mil (131.64.100.152) by UCOLHP4Z.easf.csd.disa.mil (131.64.100.6) with Microsoft SMTP Server (TLS) id 14.2.309.2; Thu, 17 Jan 2013 12:13:52 +0000 Received: from UCOLHP9L.easf.csd.disa.mil ([169.254.2.136]) by UCOLHP3M.easf.csd.disa.mil ([131.64.100.152]) with mapi id 14.02.0309.003; Thu, 17 Jan 2013 12:13:51 +0000 From: "Roy, Radhika R CIV USARMY (US)" To: Roman Shpount , Martin Thomson Thread-Topic: [rtcweb] Consensus vs. Voting (was Re: Call for Consensus Regarding Selecting Recommended Audio Codecs) (UNCLASSIFIED) Thread-Index: AQHN9EY34EcSa43+0UCb5kw4I+PsEphNUyQAgAAbPuA= Date: Thu, 17 Jan 2013 12:13:50 +0000 Message-ID: <8486C8728176924BAF5BDB2F7D7EEDDF4907E630@ucolhp9l.easf.csd.disa.mil> References: <50D2CC6A.4090500@ericsson.com> <6515_1357907583_50F0067F_6515_1738_1_2842AD9A45C83B44B57635FD4831E60A0747CC@PEXCVZYM14.corporate.adroot.infra.ftgroup> <580BEA5E3B99744AB1F5BFF5E9A3C67D16813E56EC@HE111648.emea1.cds.t-internal.com> <50F41D97.1030508@nostrum.com> <50F43ACA.80206@nostrum.com> <50F44AF0.4060304@nostrum.com> <50F4619F.7040208@nostrum.com> <7CBFD4609D19C043A4AC4FD8381C6E2602386636@DEMUEXC014.nsn-intra.net> <50F5A74C.3030203@nostrum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [131.64.62.4] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0006_01CDF481.F6819B60" MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Consensus vs. Voting (was Re: Call for Consensus Regarding Selecting Recommended Audio Codecs) (UNCLASSIFIED) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 17 Jan 2013 12:12:39 -0000 ------=_NextPart_000_0006_01CDF481.F6819B60 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Classification: UNCLASSIFIED Caveats: NONE Hi, all: A good assessment - thanks to Roman. So, the transcoding cost is enormous from both performance and HW/SW implementation point of view. In the end it may so appear that we are not hearing each other. BR/Radhika -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Roman Shpount Sent: Thursday, January 17, 2013 5:32 AM To: Martin Thomson Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Consensus vs. Voting (was Re: Call for Consensus Regarding Selecting Recommended Audio Codecs) On Wed, Jan 16, 2013 at 7:03 PM, Martin Thomson wrote: If we don't say "webrtc implementations SHOULD implement G.722/AMR/AMR-WB", what is the failure mode for your application? Keeping in mind that - because this isn't 2119 MUST - you have to expect that some non-negligible proportion of clients will not support this no matter how much extra ink we using in printing large letters, how much pain does this really cause you? I expect that the transcoding costs are what this come down to. Does anyone care to quantify this? If common codecs are not implemented in the browser this would mean transcoding will need to be performed on some sort of server-side media gateway. There are three distinct issues we need to take into account when dealing with transcoding. I would list them in what, at least from my point of view, is the order of importance: 1. If you need to do trancoding, you will need to implement a jitter buffer on the transcoding media gateway. ICE processing and SRTP en/decoding can be performed on out of order packets as they are received. You cannot transcode out of order audio. This means audio packets would need to be delayed by the jitter buffer size. In cases of good internet connection this means 40 ms jitter buffer delay. In cases of consumer internet in US (somebody sitting on a DSL connection at home behind a WiFi router) you are typically looking at 60-80 ms jitter buffer delay. If you are dealing with international internet connections jitter of 150 ms to 200 ms is not unheard of. This means an additional delay due to jitter buffering of 40 ms (best case) to 200 ms. This is in addition to any other delays that are already present on the audio path. Adding an extra 100 ms of delay can make audio conversions very awkward or unusable. On the other hand, if the gateway were performing just ICE and SRTP, it would introduce 1-2 ms of delay at most (In this case I am talking about a software based implementation running on generic server hardware. A dedicated DSP solution would probably be even faster). 2. Audio artifacts due to transcoding. Apart from usual audio degradation due to transcoding (OPUS transcoded to AMR would sound worse then OPUS or AMR), we would also deal with double packet loss concealment. Media gateway will conceal lost packets when transcoding. Client will conceal lost packet received from the gateway. This would actually sound worse then PLC performed in one place. 3. Scalability of the transcoding gateway. Gateway which just deals with ICE processing and SRTP en/decoding can handle from 2000 to 10000 concurrent call when running on a generic server CPU (different scalability is due to differences in CPU performance and presence of AES specific instructions). Gateway that would do G.722 to OPUS transcoding would most likely handle from 500 to 1000 concurrent calls. We are looking at 10x difference in performance. If we need to transcode AMR to OPUS the difference would be even higher. This translates in 10x difference in hardware, data center, power, and operations costs. _____________ Roman Shpount Classification: UNCLASSIFIED Caveats: NONE ------=_NextPart_000_0006_01CDF481.F6819B60 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISizCCA3Aw ggJYoAMCAQICAQUwDQYJKoZIhvcNAQEFBQAwWzELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4g R292ZXJubWVudDEMMAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxFjAUBgNVBAMTDURvRCBSb290 IENBIDIwHhcNMDQxMjEzMTUwMDEwWhcNMjkxMjA1MTUwMDEwWjBbMQswCQYDVQQGEwJVUzEYMBYG A1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEWMBQGA1UE AxMNRG9EIFJvb3QgQ0EgMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMAswfaNO6z/ PzzWcb64dCIH7HBBFfyrQOMHqsHD2J/+2kw6vz/I2Ch7SzYBwKxFJcPSDgqPhRhkED0aE3Aqb47X 3I2Ts0EPOCHNravCPSoF01cRNw3NjFH5k+PMRkkhjhS0zcsUPjjNcjHuqxLyZeo0LlZd/+5jdctt upE0/J7z9C0cvlDEQt9ZiP9qs/qobD3LVnFxBZa7n4DlgEVZZ0Gw68OtYKSAdQYXnA70Q+CZDhv7 f/WzzLKBgrH9MsG4vkGkZLVgOlpRMIzO3kEsGUdcSRBkuXSph0GvfW66wbihv2UxOgRn+bW7jpKK AGO4seaMOF+D/1DVO6Jda7IQzGMCAwEAAaM/MD0wHQYDVR0OBBYEFEl0uwxeunr+AlTve6DGlcYJ gHCWMAsGA1UdDwQEAwIBhjAPBgNVHRMBAf8EBTADAQH/MA0GCSqGSIb3DQEBBQUAA4IBAQCYkY0/ ici79cBpcyk7Nay6swh2PXAJkumERCEBfRR2G+5RbB2NFTctezFp9JpEuK9GzDT6I8sDJxnSgyF1 K+fgG5km3IRAleio0sz2WFxm7z9KlxCCHboKot1bBiudp2RO6y4BNaS0PxOtVeTVc6hpmxHxmPIx Hm9A1Ph4n46RoG9wBJBmqgYrzuF6krV94eDRluehOi3MsZ0fBUTth5nTTRpwOcEEDOV+2fGv1yAO 8SJ6JaRzmcw/pAcnlqiile2CuRbTnguHwsHyiPVi32jfx7xpUe2xXNxUVCkPCTmarAPB2wxNrm8K ehZJ8b+R0jiU0/aVLLdsyUK2jcqQjYXZMIIEtzCCA5+gAwIBAgIDHzzKMA0GCSqGSIb3DQEBBQUA MF0xCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEM MAoGA1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwgQ0EtMjkwHhcNMTIwOTIwMDAwMDAwWhcN MTUwOTE5MjM1OTU5WjB5MQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQww CgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEMMAoGA1UECxMDVVNBMSYwJAYDVQQDEx1ST1kuUkFE SElLQS5SQU5KQU4uMTI5MTkzOTgwMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKw9 ymde30NtacDt8neYCBWDyA+Hlsk3dNwV23IVgH7vSWJx4zCFT5ojDHACm3lthvOOtJ0CzkjwQy8V hEHvL0eK03hZy0hJrZxQSYcao7Y0Yv9yDAFvxa6LJ1fUImUj9edMf1l08LZkjh3ybs20Bk+MLySR 9F/flRzjtCwVUeqq8NS3to4nPXSIgViP6H0YJrBjf9IDZQGgcO8LxLbNENOWrXILeCCCngnHBgHV lJWak9YndpMOs+CeLXk5oUV8xUAM/UjyS+/gFCjABBRt30VJVN6pqARmIht850iK8TDeqlWwF3O9 eQBBwKQPJ7nVl0kmGItYGoYb+4t2Mkwalh8CAwEAAaOCAWIwggFeMB8GA1UdIwQYMBaAFLhDg2Qh eu5wgd6l3gxgKId4rl54MDoGA1UdHwQzMDEwL6AtoCuGKWh0dHA6Ly9jcmwuZGlzYS5taWwvY3Js L0RPREVNQUlMQ0FfMjkuY3JsMA4GA1UdDwEB/wQEAwIFIDAjBgNVHSAEHDAaMAsGCWCGSAFlAgEL CTALBglghkgBZQIBCxMwHQYDVR0OBBYEFGRWf703swy+9hvoDujsb+ZPwC9MMGgGCCsGAQUFBwEB BFwwWjA2BggrBgEFBQcwAoYqaHR0cDovL2NybC5kaXNhLm1pbC9zaWduL0RPREVNQUlMQ0FfMjku Y2VyMCAGCCsGAQUFBzABhhRodHRwOi8vb2NzcC5kaXNhLm1pbDAkBgNVHREEHTAbgRlyYWRoaWth LnIucm95QHVzLmFybXkubWlsMBsGA1UdCQQUMBIwEAYIKwYBBQUHCQQxBBMCVVMwDQYJKoZIhvcN AQEFBQADggEBAE9PU63Rc/bneYoxI6sAZi+oXBiwneOiI03+J3pSZWIbwrOnj7qGoH5ZoeO+dZ8E wvKszd+vacYnO8SqEXsvIKvBGPchKg1oV5b24+tCSeiCXtcX5EDtpJQGS4W9G+7r7f+mdEHU0NuF NI7HNHRY/q4C+FGhchPoKPcKeyWxJMwp+9NJQsx1AoC5isvydZHHlNkV917dLMuMEqyCCAAbJAOp 8SDQTiiIVa1I7NlMSlkzNRUtFoO9nsEttMH699V9JH5jcwWPlWdyb5B6yRzoM/iFsI/hA9pHHukh iWVul3FX/6Ez8Jt/A1j/CFsl3S2y2TBRCdqIQEP+/H6j4RFxa9MwggUCMIID6qADAgECAgMfPMkw DQYJKoZIhvcNAQEFBQAwXTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEM MAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxGDAWBgNVBAMTD0RPRCBFTUFJTCBDQS0yOTAeFw0x MjA5MjAwMDAwMDBaFw0xNTA5MTkyMzU5NTlaMHkxCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMu IEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJMQwwCgYDVQQLEwNVU0ExJjAk BgNVBAMTHVJPWS5SQURISUtBLlJBTkpBTi4xMjkxOTM5ODAxMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEAyr7Ttduf1mHx22erLvkwPOZL02imdiimrmXITVrdUHsynK383NY6a4ye07Jm b0spr8hzmfM6JSCEgtbZevWfJg4NmNDjEEe53+7EvEMRHfh46GGxOckj98QmQwngbQaAIcKI1gJd Do2vB3mOtFp5hNKqsxibZAvpPb3OsR762vrx2QYQX+p8+psLwe95CSt56IfC39GZD+Otus3Sq1Ma 9e0NdRhqg5ch8FYpL2ONbmEw9+DTqk24Zh2lQuOvpo4FhpvXnNghCS4CfuiE6YgvKdombc1BGT5u rkDFep5IH7Rk7EnK4CVVzNq3gxT0B+hDoJT0AuQfrkxI9223mUJoywIDAQABo4IBrTCCAakwHwYD VR0jBBgwFoAUuEODZCF67nCB3qXeDGAoh3iuXngwOgYDVR0fBDMwMTAvoC2gK4YpaHR0cDovL2Ny bC5kaXNhLm1pbC9jcmwvRE9ERU1BSUxDQV8yOS5jcmwwDgYDVR0PAQH/BAQDAgbAMCMGA1UdIAQc MBowCwYJYIZIAWUCAQsJMAsGCWCGSAFlAgELEzAdBgNVHQ4EFgQUrV8KnskfJHURS19In/mX0d2y 9pgwaAYIKwYBBQUHAQEEXDBaMDYGCCsGAQUFBzAChipodHRwOi8vY3JsLmRpc2EubWlsL3NpZ24v RE9ERU1BSUxDQV8yOS5jZXIwIAYIKwYBBQUHMAGGFGh0dHA6Ly9vY3NwLmRpc2EubWlsMEQGA1Ud EQQ9MDuBGXJhZGhpa2Euci5yb3lAdXMuYXJteS5taWygHgYKKwYBBAGCNxQCA6AQDA4xMjkxOTM5 ODAxQG1pbDAbBgNVHQkEFDASMBAGCCsGAQUFBwkEMQQTAlVTMCkGA1UdJQQiMCAGCisGAQQBgjcU AgIGCCsGAQUFBwMCBggrBgEFBQcDBDANBgkqhkiG9w0BAQUFAAOCAQEAggVw28drobHRF6Zr7wQZ G/ShO0BE6jEddlmlqj9ln2mC5HoTTXkl2ZOqjUoh2Wq2d55KvbZk9b73bIzWK+RnnoU+zOHagyB/ VnEbSpdofTm50zJYISK7Ws92KCt8viNetFkS2CTNSc302cqmwejpTwKAxkLDM0wU7ECNopN87F0O vPU2AJnITH32PrAvTVOeCxsDdEnzzXYxvKtNE5K6zBVVumSOGLMfnyFAq+4dlhg7i25B8Goh+fIF eRGiwxsXOyEMPalWHt5wWDDmUlIK0Qmg95mZ7f6UJCmj15zzSxgliR+JyVlFGH6/HYzIAU4lv8b5 uU5qyxANtVCvuGDruDCCBVIwggQ6oAMCAQICAgG4MA0GCSqGSIb3DQEBBQUAMFsxCzAJBgNVBAYT AlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJ MRYwFAYDVQQDEw1Eb0QgUm9vdCBDQSAyMB4XDTExMDkwODE2MDIxNFoXDTE3MDkwODE2MDIxNFow XTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEMMAoGA1UECxMDRG9EMQww CgYDVQQLEwNQS0kxGDAWBgNVBAMTD0RPRCBFTUFJTCBDQS0yOTCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAJJiL0HCIAAWBlVkn72niBVugptIwYV3vQKrDNnxK2CBAbo+dXCOEqanOISQ s+lAgBLcaspRza0thhDMRLwOxVg4GbIUMiVBVFhcQw7IbHMPwwwYGBYEmlI9gaJxzjwyAJ9xVbr4 zjZ3HiG3KJTnPT6m9sB6MWCRKJd3IlDyxpNushvFQcb5oTf7EL/aVqb7Uk1fv+/Elnco5TL/6OEY zENSGKyNd5pyTOidA16wou/k3dLn5qemUq3hmAiWSkPMcz1Loo2J79yCTLhKgCRlKx6RgvUE9nIf VxhAF/A5UbaP84k7Z/dYTkq82vkOwcAMvfMIcfiDD8kugJX0hQ7OrqkCAwEAAaOCAhwwggIYMA4G A1UdDwEB/wQEAwIBhjAfBgNVHSMEGDAWgBRJdLsMXrp6/gJU73ugxpXGCYBwljAdBgNVHQ4EFgQU uEODZCF67nCB3qXeDGAoh3iuXngwEgYDVR0TAQH/BAgwBgEB/wIBADAMBgNVHSQEBTADgAEAMGYG A1UdIARfMF0wCwYJYIZIAWUCAQsFMAsGCWCGSAFlAgELCTALBglghkgBZQIBCxEwCwYJYIZIAWUC AQsSMAsGCWCGSAFlAgELEzAMBgpghkgBZQMCAQMaMAwGCmCGSAFlAwIBAxswNwYDVR0fBDAwLjAs oCqgKIYmaHR0cDovL2NybC5kaXNhLm1pbC9jcmwvRE9EUk9PVENBMi5jcmwwggEBBggrBgEFBQcB AQSB9DCB8TA6BggrBgEFBQcwAoYuaHR0cDovL2NybC5kaXNhLm1pbC9pc3N1ZWR0by9ET0RST09U Q0EyX0lULnA3YzAgBggrBgEFBQcwAYYUaHR0cDovL29jc3AuZGlzYS5taWwwgZAGCCsGAQUFBzAC hoGDbGRhcDovL2NybC5nZHMuZGlzYS5taWwvY24lM2REb0QlMjBSb290JTIwQ0ElMjAyJTJjb3Ul M2RQS0klMmNvdSUzZERvRCUyY28lM2RVLlMuJTIwR292ZXJubWVudCUyY2MlM2RVUz9jcm9zc0Nl cnRpZmljYXRlUGFpcjtiaW5hcnkwDQYJKoZIhvcNAQEFBQADggEBACxrLHk12/AeHId7q+HoaWo3 i9t6T1VgaZUvU53GykO21DeR1gNdflqxuB33noHTrlBUMKRvSy67FBsXqlwQ05R6MTmWpFR59elW LlXDGxbqqgLIz1H3MoEixjQ6qc2aqkiTx+n7HjJ+ccR28EVUEh1V6r1cMoc6rpOabpkiX6hRNe6y U2Bf9k9FuBaEHWVVzRXKEAEfqdKcp1eRo9fnsIY9LfSJOtjJd3BQxmzv8uuY+BCqPdrIXCmtzrhz SUyhkrvm7c26ghpjIRll9AYZv4Oqc+XTG7GY/0Xf+0nMc+ji5weWADHpf9kkCOfKRHpIBsNC2D/5 eYelN5IWqYQgkmMxggMyMIIDLgIBATBkMF0xCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdv dmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwg Q0EtMjkCAx88yTAJBgUrDgMCGgUAoIIBozAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xMzAxMTcxMjEyMDhaMCMGCSqGSIb3DQEJBDEWBBTu+9VcJ8vd1FED1uQk+z6+ ts5aCDBYBgkqhkiG9w0BCQ8xSzBJMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMC BzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG9w0CBTBzBgkrBgEEAYI3EAQxZjBkMF0x CzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoG A1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwgQ0EtMjkCAx88yjB1BgsqhkiG9w0BCRACCzFm oGQwXTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEMMAoGA1UECxMDRG9E MQwwCgYDVQQLEwNQS0kxGDAWBgNVBAMTD0RPRCBFTUFJTCBDQS0yOQIDHzzKMA0GCSqGSIb3DQEB AQUABIIBAA8jY6NAf2DJsLqEnSJ7DQcWxM/+UP55b5bkex5nLKEiQDtX9ZYoWnr0aGi2Zz+LLJHC lcxbYS2jI81F1gSYXXJlw7UpNMnnss3xUXsI0wHYECoKDiDt+YVSf64RG/oix9uQWwy6PnEr0vmi Hvu1k0xCHhARTsQwjkiQl8MCnrDjWpSHh3ou8e1Q6iiuUuYCqTUiaD/+Mt8WgeysPWEbjek2DmGL IRTPdg9Yb2NdJaM3oo649b6m7TwtYLumnCqAZmo4rRhS9qbQcn13cxrmidS7pCHxi+I/Xy+7phcc 4W44CRk/5hEekoeJ25qZqJwiggg3JUBNDVxWZBvnOiugx80AAAAAAAA= ------=_NextPart_000_0006_01CDF481.F6819B60-- From prvs=97290e39eb=aallen@rim.com Thu Jan 17 04:54:19 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70CEF21F894C for ; Thu, 17 Jan 2013 04:54:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.447 X-Spam-Level: X-Spam-Status: No, score=-5.447 tagged_above=-999 required=5 tests=[AWL=1.756, BAYES_00=-2.599, GB_I_LETTER=-2, MIME_QP_LONG_LINE=1.396, 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 HB8cQkL7pjOv for ; Thu, 17 Jan 2013 04:54:18 -0800 (PST) Received: from mhs060cnc.rim.net (mhs060cnc.rim.net [208.65.73.34]) by ietfa.amsl.com (Postfix) with ESMTP id 65D1121F895B for ; Thu, 17 Jan 2013 04:54:18 -0800 (PST) X-AuditID: 0a41282f-b7f8c6d000004b29-cd-50f7f46d4b97 Received: from XCT104ADS.rim.net (xct104ads.rim.net [10.67.111.45]) by mhs060cnc.rim.net (SBG) with SMTP id F9.7C.19241.D64F7F05; Thu, 17 Jan 2013 06:54:05 -0600 (CST) Received: from XMB104ADS.rim.net ([fe80::2494:a63d:e3:723b]) by XCT104ADS.rim.net ([fe80::90f9:3b89:1d94:aa9b%22]) with mapi id 14.02.0318.001; Thu, 17 Jan 2013 06:54:04 -0600 From: Andrew Allen To: "radhika.r.roy.civ@mail.mil" , "roman@telurix.com" , "martin.thomson@gmail.com" Thread-Topic: [rtcweb] Consensus vs. Voting (was Re: Call for Consensus Regarding Selecting Recommended Audio Codecs) (UNCLASSIFIED) Thread-Index: AQHN9Kv2LO2vpjF/Sk2uonpkHFQeHZhNehux Date: Thu, 17 Jan 2013 12:54:03 +0000 Message-ID: In-Reply-To: <8486C8728176924BAF5BDB2F7D7EEDDF4907E630@ucolhp9l.easf.csd.disa.mil> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.67.110.253] Content-Type: text/plain; charset="iso-8859-1" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrJKsWRmVeSWpSXmKPExsXC5Zyvq5v75XuAQf8hbYtrZ/4xWqxq/cVu MePCVGaLtf/a2R1YPHbOusvusWTJTyaP9fffM3rcmlIQwBLVwGiTlFhSFpyZnqdvZ5OYl5df kliSqpCSWpxsq+STmp6YoxBQlFmWmFyp4JJZnJyTmJmbWqSkkJliq2SipFCQk5icmpuaV2Kr lFhQkJqXomTHpYABbIDKMvMUUvOS81My89JtlTyD/XUtLEwtdQ2V7HQTOnkyrvVdZS+YpVux 4s0NlgbG6ypdjBwcEgImEusmuXUxcgKZYhIX7q1nA7GFBFYySrz+btzFyAVkb2aU2LN8H1iC TUBZYvnvGYwgCRGBhYwSDcvmgiWYBdQl7iw+xw6SEBZoZZS40reFCaKqjVHi7f4ZrCDrRASM JM5PAGtgEVCV+H1yOwuIzSvgITHt0VxGEJtTIEji65e97CA2I9BJ30+tYYJYIC5x68l8JohT BSSW7DnPDGGLSrx8/I8VwlaU+Lv3OytEvZ7EjalToI7Tlli28DUzxC5BiZMzn7BMYBSdhWTs LCQts5C0zELSsoCRZRWjYG5GsYGZQXJesl5RZq5eXmrJJkZQ2nDU0N/B+Pa9xSFGAQ5GJR7e 0nffA4RYE8uKK3MPMUpwMCuJ8H74ABTiTUmsrEotyo8vKs1JLT7E6AoMiYnMUtzJ+cCUllcS b2xggJujJM4r2Xs5QEggHZh+slNTC1KLYOYwcXCC7OGSEikGJpHUosTSkox4UKqLLwYmO6kG xpl9+qZ3exrVtMIbfvJxhrmuT1j4JuSewkt/5ofTdDy/RQb/UvrMn1/2qjAt8GrGdeY7zmJP 3ktOytRykLBTf6R1fovryrf371XfCGyO9TFSemoXYv+yxNV/QufyvyEfax+fvSDCwDdn43m3 XuVfrlqst1b9nizxOmKeV5DHS9bXChnMqps9lFiKMxINtZiLihMBN258jVwDAAA= Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Consensus vs. Voting (was Re: Call for Consensus Regarding Selecting Recommended Audio Codecs) (UNCLASSIFIED) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 17 Jan 2013 12:54:19 -0000 As I recall during the MTI discussion it was claimed that OPUS was intended= for interoperability between RTCweb endoints and G.711 for interoperability= with legacy. That's why we selected 2 MTI Codecs. Transcoding between G.711 and something else like G.722 will not have anythi= ng like the transcoding cost as between OPUS and G.722 - basically the compl= exity of a media gateway. Of course you will not get the full fidelity of e= ither OPUS or G.722 but basic audio communications will work fine which is a= ll I think we can guarantee with legacy. If platforms already have other codecs (such as AMR on mobile devices) that= are usable by the browser then it makes perfect sense that they be included= in the offer but I don't think IETF should start recommending other codecs= to implement other than the 2 MTI. This should be left as product decisions= based on commercial needs and not recommendations made by IETF the driver f= or which I suspect has more to do with the interests of some legacy products= /deployments than those of RTCweb. Since almost every computing platform has a browser (including most mobile p= hones) within a few years every computing platform will have RTCweb and OPUS= so the need for high fidelity legacy codec interoperability will I think be= come a mute point. I think the inteoperability concerns should be more focussed on the video is= sue where we seem to have a real problem. Andrew ----- Original Message ----- From: Roy, Radhika R CIV USARMY (US) [mailto:radhika.r.roy.civ@mail.mil] Sent: Thursday, January 17, 2013 06:13 AM Central Standard Time=0A= To: Roman Shpount ; Martin Thomson Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Consensus vs. Voting (was Re: Call for Consensus Regar= ding Selecting Recommended Audio Codecs) (UNCLASSIFIED) Classification: UNCLASSIFIED Caveats: NONE Hi, all: A good assessment - thanks to Roman. So, the transcoding cost is enormous from both performance and HW/SW implementation point of view. In the end it may so appear that we are not hearing each other. BR/Radhika -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Roman Shpount Sent: Thursday, January 17, 2013 5:32 AM To: Martin Thomson Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Consensus vs. Voting (was Re: Call for Consensus Regarding Selecting Recommended Audio Codecs) On Wed, Jan 16, 2013 at 7:03 PM, Martin Thomson wrote: If we don't say "webrtc implementations SHOULD implement G.722/AMR/AMR-WB", what is the failure mode for your application? Keeping in mind that - because this isn't 2119 MUST - you have to expect that some non-negligible proportion of clients will not support this no matter how much extra ink we using in printing large letters, how much pain does this really cause you? I expect that the transcoding costs are what this come down to. Does anyone care to quantify this? If common codecs are not implemented in the browser this would mean transcoding will need to be performed on some sort of server-side media gateway. There are three distinct issues we need to take into account when dealing with transcoding. I would list them in what, at least from my point of view, is the order of importance: 1. If you need to do trancoding, you will need to implement a jitter buffer on the transcoding media gateway. ICE processing and SRTP en/decoding can be performed on out of order packets as they are received. You cannot transcode out of order audio. This means audio packets would need to be delayed by the jitter buffer size. In cases of good internet connection this means 40 ms jitter buffer delay. In cases of consumer internet in US (somebody sitting on a DSL connection at home behind a WiFi router) you are typically looking at 60-80 ms jitter buffer delay. If you are dealing with international internet connections jitter of 150 ms to 200 ms is not unheard of. This means an additional delay due to jitter buffering of 40 ms (best case) to 200 ms. This is in addition to any other delays that are already present on the audio path. Adding an extra 100 ms of delay can make audio conversions very awkward or unusable. On the other hand, if the gateway were performing just ICE and SRTP, it would introduce 1-2 ms of delay at most (In this case I am talking about a software based implementation running on generic server hardware. A dedicated DSP solution would probably be even faster). 2. Audio artifacts due to transcoding. Apart from usual audio degradation due to transcoding (OPUS transcoded to AMR would sound worse then OPUS or AMR), we would also deal with double packet loss concealment. Media gateway will conceal lost packets when transcoding. Client will conceal lost packet received from the gateway. This would actually sound worse then PLC performed in one place. 3. Scalability of the transcoding gateway. Gateway which just deals with ICE processing and SRTP en/decoding can handle from 2000 to 10000 concurrent call when running on a generic server CPU (different scalability is due to differences in CPU performance and presence of AES specific instructions). Gateway that would do G.722 to OPUS transcoding would most likely handle from 500 to 1000 concurrent calls. We are looking at 10x difference in performance. If we need to transcode AMR to OPUS the difference would be even higher. This translates in 10x difference in hardware, data center, power, and operations costs. _____________ Roman Shpount Classification: UNCLASSIFIED Caveats: NONE --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From stefan.lk.hakansson@ericsson.com Thu Jan 17 05:14:15 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0407D21F8844 for ; Thu, 17 Jan 2013 05:14:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.949 X-Spam-Level: X-Spam-Status: No, score=-6.949 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, 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 OVLA9sHvDzGu for ; Thu, 17 Jan 2013 05:14:10 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 3356421F8840 for ; Thu, 17 Jan 2013 05:14:10 -0800 (PST) X-AuditID: c1b4fb2d-b7f316d0000028db-bb-50f7f9217586 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 8F.E5.10459.129F7F05; Thu, 17 Jan 2013 14:14:09 +0100 (CET) Received: from [150.132.141.90] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.279.1; Thu, 17 Jan 2013 14:14:09 +0100 Message-ID: <50F7F920.2010403@ericsson.com> Date: Thu, 17 Jan 2013 14:14:08 +0100 From: =?ISO-8859-1?Q?Stefan_H=E5kansson_LK?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: rtcweb@ietf.org References: <50D2CC6A.4090500@ericsson.com> <6515_1357907583_50F0067F_6515_1738_1_2842AD9A45C83B44B57635FD4831E60A0747CC@PEXCVZYM14.corporate.adroot.infra.ftgroup> <580BEA5E3B99744AB1F5BFF5E9A3C67D16813E56EC@HE111648.emea1.cds.t-internal.com> <50F41D97.1030508@nostrum.com> <50F43ACA.80206@nostrum.com> <50F44AF0.4060304@nostrum.com> <50F4619F.7040208@nostrum.com> <7CBFD4609D19C043A4AC4FD8381C6E2602386636@DEMUEXC014.nsn-intra.net> <50F5A74C.3030203@nostrum.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrAJMWRmVeSWpSXmKPExsUyM+Jvja7iz+8BBvs7pCzW/mtnd2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxqQ1GxkL/stVzH50mr2B8aFEFyMnh4SAicSVQ9eZIWwxiQv3 1rN1MXJxCAmcZJTo2HmFGcJZwyjx6+9hVpAqXgFtiY5Vt9lAbBYBVYkrf/aDdbMJBEpc//+L CcQWFYiSeH+1iRmiXlDi5MwnLCC2iICwxNZXvWA1wgJlEl3T/zJCLDjHLrGxdTkjSIITaFDL kilgzcwCthIX5lxngbDlJba/nQMWFxLQlXj3+h7rBEaBWUh2zELSMgtJywJG5lWM7LmJmTnp 5YabGIGhdnDLb90djKfOiRxilOZgURLnDXO9ECAkkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qB sdPunc6bY9IqOzdO3xTtW2Vy+MOd9Pa3TYfmr/y6tvtK2BWfGI0dqz3y26/Jzg5Zqt1Uu/Jj ktNNnpdsUxM6/i5tsHcrNr14LS8gOfH8Gnn/E5wWgbeue4rKtyx+21LUdEisr+//vBCPpkub yzlDDr3dvUrFZXNzxN6/Wz+d6fzM89VES7akUYmlOCPRUIu5qDgRAEjveYUDAgAA Subject: Re: [rtcweb] Consensus vs. Voting (was Re: Call for Consensus Regarding Selecting Recommended 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, 17 Jan 2013 13:14:15 -0000 On 2013-01-17 11:31, Roman Shpount wrote: > > On Wed, Jan 16, 2013 at 7:03 PM, Martin Thomson > > wrote: > > If we don't say "webrtc implementations SHOULD implement > G.722/AMR/AMR-WB", what is the failure mode for your application? > Keeping in mind that - because this isn't 2119 MUST - you have to > expect that some non-negligible proportion of clients will not support > this no matter how much extra ink we using in printing large letters, > how much pain does this really cause you? > > I expect that the transcoding costs are what this come down to. Does > anyone care to quantify this? > > > If common codecs are not implemented in the browser this would mean > transcoding will need to be performed on some sort of server-side media > gateway. There are three distinct issues we need to take into account > when dealing with transcoding. I would list them in what, at least from > my point of view, is the order of importance: > > 1. If you need to do trancoding, you will need to implement a jitter > buffer on the transcoding media gateway. ICE processing and SRTP > en/decoding can be performed on out of order packets as they are > received. You cannot transcode out of order audio. This means audio > packets would need to be delayed by the jitter buffer size. In cases of > good internet connection this means 40 ms jitter buffer delay. In cases > of consumer internet in US (somebody sitting on a DSL connection at home > behind a WiFi router) you are typically looking at 60-80 ms jitter > buffer delay. If you are dealing with international internet connections > jitter of 150 ms to 200 ms is not unheard of. This means an additional > delay due to jitter buffering of 40 ms (best case) to 200 ms. This is in > addition to any other delays that are already present on the audio path. > Adding an extra 100 ms of delay can make audio conversions very awkward > or unusable. On the other hand, if the gateway were performing just ICE > and SRTP, it would introduce 1-2 ms of delay at most (In this case I am > talking about a software based implementation running on generic server > hardware. A dedicated DSP solution would probably be even faster). > > 2. Audio artifacts due to transcoding. Apart from usual audio > degradation due to transcoding (OPUS transcoded to AMR would sound worse > then OPUS or AMR), we would also deal with double packet loss > concealment. Media gateway will conceal lost packets when transcoding. > Client will conceal lost packet received from the gateway. This would > actually sound worse then PLC performed in one place. > > 3. Scalability of the transcoding gateway. Gateway which just deals with > ICE processing and SRTP en/decoding can handle from 2000 to 10000 > concurrent call when running on a generic server CPU (different > scalability is due to differences in CPU performance and presence of AES > specific instructions). Gateway that would do G.722 to OPUS transcoding > would most likely handle from 500 to 1000 concurrent calls. We are > looking at 10x difference in performance. If we need to transcode AMR to > OPUS the difference would be even higher. This translates in 10x > difference in hardware, data center, power, and operations costs. This was a good summary. I'm mostly concerned with the quality degradations experienced by the end user and less about the cost (on the other hand, I guess this would in the end hit the end users as well). I think having a 'SHOULD' for a few additional codecs would reduce the number of end users impacted by the degradations (and cost) mentioned, and I think that would make a lot of sense. Stefan > _____________ > Roman Shpount > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From uwe.rauschenbach@nsn.com Thu Jan 17 05:16:55 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE5E921F884B for ; Thu, 17 Jan 2013 05:16:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.599 X-Spam-Level: X-Spam-Status: No, score=-7.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2, 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 np7wT49snNLR for ; Thu, 17 Jan 2013 05:16:55 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 6F7ED21F8840 for ; Thu, 17 Jan 2013 05:16:54 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id r0HDGpqL030374 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 17 Jan 2013 14:16:52 +0100 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id r0HDGlml010485; Thu, 17 Jan 2013 14:16:51 +0100 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 17 Jan 2013 14:16:50 +0100 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: Thu, 17 Jan 2013 14:16:49 +0100 Message-ID: <7CBFD4609D19C043A4AC4FD8381C6E26023CF7B3@DEMUEXC014.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] Consensus vs. Voting (was Re: Call for Consensus Regarding Selecting Recommended Audio Codecs) (UNCLASSIFIED) Thread-Index: AQHN9Kv2LO2vpjF/Sk2uonpkHFQeHZhNehuxgAADuOA= References: <8486C8728176924BAF5BDB2F7D7EEDDF4907E630@ucolhp9l.easf.csd.disa.mil> From: "Rauschenbach, Uwe (NSN - DE/Munich)" To: "ext Andrew Allen" , , , X-OriginalArrivalTime: 17 Jan 2013 13:16:50.0451 (UTC) FILETIME=[E907DE30:01CDF4B4] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 6323 X-purgate-ID: 151667::1358428612-00003C02-B258BE4E/0-0/0-0 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Consensus vs. Voting (was Re: Call for Consensus Regarding Selecting Recommended Audio Codecs) (UNCLASSIFIED) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 17 Jan 2013 13:16:56 -0000 > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > Behalf Of ext Andrew Allen >=20 > Since almost every computing platform has a browser (including most > mobile phones) within a few years every computing platform will have > RTCweb and OPUS so the need for high fidelity legacy codec > interoperability will I think become a mute point. >=20 This is not the point. The use case is to enable a user of an RTCWeb service to reach another user via the legacy telephone network, be it mobile or fixed. The fact whether or not the browser on the mobile phone is capable of RTCWeb is of no relevance for this use case, because it may well be that the two call parties use different RTCWeb services with no interconnection, and the only way to reach each other is via the telephone network. Kind regards, Uwe =20 > ----- Original Message ----- > From: Roy, Radhika R CIV USARMY (US) > [mailto:radhika.r.roy.civ@mail.mil] > Sent: Thursday, January 17, 2013 06:13 AM Central Standard Time > To: Roman Shpount ; Martin Thomson > > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] Consensus vs. Voting (was Re: Call for Consensus > Regarding Selecting Recommended Audio Codecs) (UNCLASSIFIED) >=20 > Classification: UNCLASSIFIED > Caveats: NONE >=20 > Hi, all: >=20 > A good assessment - thanks to Roman. >=20 > So, the transcoding cost is enormous from both performance and HW/SW > implementation point of view. >=20 > In the end it may so appear that we are not hearing each other. >=20 > BR/Radhika >=20 > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > Behalf Of > Roman Shpount > Sent: Thursday, January 17, 2013 5:32 AM > To: Martin Thomson > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] Consensus vs. Voting (was Re: Call for Consensus > Regarding Selecting Recommended Audio Codecs) >=20 >=20 > On Wed, Jan 16, 2013 at 7:03 PM, Martin Thomson > > wrote: >=20 >=20 > If we don't say "webrtc implementations SHOULD implement > G.722/AMR/AMR-WB", what is the failure mode for your application? > Keeping in mind that - because this isn't 2119 MUST - you have to > expect that some non-negligible proportion of clients will not > support > this no matter how much extra ink we using in printing large > letters, > how much pain does this really cause you? >=20 > I expect that the transcoding costs are what this come down to. > Does > anyone care to quantify this? >=20 >=20 > If common codecs are not implemented in the browser this would mean > transcoding will need to be performed on some sort of server-side media > gateway. There are three distinct issues we need to take into account > when > dealing with transcoding. I would list them in what, at least from my > point > of view, is the order of importance: >=20 > 1. If you need to do trancoding, you will need to implement a jitter > buffer > on the transcoding media gateway. ICE processing and SRTP en/decoding > can be > performed on out of order packets as they are received. You cannot > transcode > out of order audio. This means audio packets would need to be delayed > by the > jitter buffer size. In cases of good internet connection this means 40 > ms > jitter buffer delay. In cases of consumer internet in US (somebody > sitting > on a DSL connection at home behind a WiFi router) you are typically > looking > at 60-80 ms jitter buffer delay. If you are dealing with international > internet connections jitter of 150 ms to 200 ms is not unheard of. This > means an additional delay due to jitter buffering of 40 ms (best case) > to > 200 ms. This is in addition to any other delays that are already > present on > the audio path. Adding an extra 100 ms of delay can make audio > conversions > very awkward or unusable. On the other hand, if the gateway were > performing > just ICE and SRTP, it would introduce 1-2 ms of delay at most (In this > case > I am talking about a software based implementation running on generic > server > hardware. A dedicated DSP solution would probably be even faster). >=20 > 2. Audio artifacts due to transcoding. Apart from usual audio > degradation > due to transcoding (OPUS transcoded to AMR would sound worse then OPUS > or > AMR), we would also deal with double packet loss concealment. Media > gateway > will conceal lost packets when transcoding. Client will conceal lost > packet > received from the gateway. This would actually sound worse then PLC > performed in one place. >=20 > 3. Scalability of the transcoding gateway. Gateway which just deals > with ICE > processing and SRTP en/decoding can handle from 2000 to 10000 > concurrent > call when running on a generic server CPU (different scalability is due > to > differences in CPU performance and presence of AES specific > instructions). > Gateway that would do G.722 to OPUS transcoding would most likely > handle > from 500 to 1000 concurrent calls. We are looking at 10x difference in > performance. If we need to transcode AMR to OPUS the difference would > be > even higher. This translates in 10x difference in hardware, data > center, > power, and operations costs. >=20 > _____________ > Roman Shpount >=20 > Classification: UNCLASSIFIED > Caveats: NONE >=20 >=20 >=20 > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential > information, privileged material (including material protected by the > solicitor-client or other applicable privileges), or constitute non- > public information. Any use of this information by anyone other than > the intended recipient is prohibited. If you have received this > transmission in error, please immediately reply to the sender and > delete this information from your system. Use, dissemination, > distribution, or reproduction of this transmission by unintended > recipients is not authorized and may be unlawful. > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From eburger@cs.georgetown.edu Thu Jan 17 05:17:29 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2049B21F8868 for ; Thu, 17 Jan 2013 05:17:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2] 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 RaQRWJyqobu3 for ; Thu, 17 Jan 2013 05:17:28 -0800 (PST) Received: from karma.cs.georgetown.edu (karma.cs.georgetown.edu [141.161.20.3]) by ietfa.amsl.com (Postfix) with ESMTP id 451E521F8846 for ; Thu, 17 Jan 2013 05:17:28 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by karma.cs.georgetown.edu (Postfix) with ESMTP id 8264242D74 for ; Thu, 17 Jan 2013 08:17:27 -0500 (EST) X-Virus-Scanned: by amavisd-new at cs.georgetown.edu Received: from karma.cs.georgetown.edu ([127.0.0.1]) by localhost (karma.cs.georgetown.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7wFIWF4OjzBf for ; Thu, 17 Jan 2013 08:17:25 -0500 (EST) Received: from [192.168.15.177] (ip68-100-199-8.dc.dc.cox.net [68.100.199.8]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by karma.cs.georgetown.edu (Postfix) with ESMTP id A4E114134E for ; Thu, 17 Jan 2013 08:17:25 -0500 (EST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Burger Eric In-Reply-To: <50F7F920.2010403@ericsson.com> Date: Thu, 17 Jan 2013 08:17:29 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <5DCD8270-4DBD-413F-961F-3BFA20686A60@cs.georgetown.edu> References: <50D2CC6A.4090500@ericsson.com> <6515_1357907583_50F0067F_6515_1738_1_2842AD9A45C83B44B57635FD4831E60A0747CC@PEXCVZYM14.corporate.adroot.infra.ftgroup> <580BEA5E3B99744AB1F5BFF5E9A3C67D16813E56EC@HE111648.emea1.cds.t-internal.com> <50F41D97.1030508@nostrum.com> <50F43ACA.80206@nostrum.com> <50F44AF0.4060304@nostrum.com> <50F4619F.7040208@nostrum.com> <7CBFD4609D19C043A4AC4FD8381C6E2602386636@DEMUEXC014.nsn-intra.net> <50F5A74C.3030203@nostrum.com> <50F7F920.20104 03@ericsson.com> To: "rtcweb@ietf.org" X-Mailer: Apple Mail (2.1499) Subject: Re: [rtcweb] Consensus vs. Voting (was Re: Call for Consensus Regarding Selecting Recommended 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, 17 Jan 2013 13:17:29 -0000 So the argument here is the cost to the user is USD 0.0000001/call = instead of USD 0.00000001/call? On Jan 17, 2013, at 8:14 AM, Stefan H=E5kansson LK = wrote: > On 2013-01-17 11:31, Roman Shpount wrote: >>=20 >> On Wed, Jan 16, 2013 at 7:03 PM, Martin Thomson >> > wrote: >>=20 >> If we don't say "webrtc implementations SHOULD implement >> G.722/AMR/AMR-WB", what is the failure mode for your application? >> Keeping in mind that - because this isn't 2119 MUST - you have to >> expect that some non-negligible proportion of clients will not = support >> this no matter how much extra ink we using in printing large = letters, >> how much pain does this really cause you? >>=20 >> I expect that the transcoding costs are what this come down to. = Does >> anyone care to quantify this? >>=20 >>=20 >> If common codecs are not implemented in the browser this would mean >> transcoding will need to be performed on some sort of server-side = media >> gateway. There are three distinct issues we need to take into account >> when dealing with transcoding. I would list them in what, at least = from >> my point of view, is the order of importance: >>=20 >> 1. If you need to do trancoding, you will need to implement a jitter >> buffer on the transcoding media gateway. ICE processing and SRTP >> en/decoding can be performed on out of order packets as they are >> received. You cannot transcode out of order audio. This means audio >> packets would need to be delayed by the jitter buffer size. In cases = of >> good internet connection this means 40 ms jitter buffer delay. In = cases >> of consumer internet in US (somebody sitting on a DSL connection at = home >> behind a WiFi router) you are typically looking at 60-80 ms jitter >> buffer delay. If you are dealing with international internet = connections >> jitter of 150 ms to 200 ms is not unheard of. This means an = additional >> delay due to jitter buffering of 40 ms (best case) to 200 ms. This is = in >> addition to any other delays that are already present on the audio = path. >> Adding an extra 100 ms of delay can make audio conversions very = awkward >> or unusable. On the other hand, if the gateway were performing just = ICE >> and SRTP, it would introduce 1-2 ms of delay at most (In this case I = am >> talking about a software based implementation running on generic = server >> hardware. A dedicated DSP solution would probably be even faster). >>=20 >> 2. Audio artifacts due to transcoding. Apart from usual audio >> degradation due to transcoding (OPUS transcoded to AMR would sound = worse >> then OPUS or AMR), we would also deal with double packet loss >> concealment. Media gateway will conceal lost packets when = transcoding. >> Client will conceal lost packet received from the gateway. This would >> actually sound worse then PLC performed in one place. >>=20 >> 3. Scalability of the transcoding gateway. Gateway which just deals = with >> ICE processing and SRTP en/decoding can handle from 2000 to 10000 >> concurrent call when running on a generic server CPU (different >> scalability is due to differences in CPU performance and presence of = AES >> specific instructions). Gateway that would do G.722 to OPUS = transcoding >> would most likely handle from 500 to 1000 concurrent calls. We are >> looking at 10x difference in performance. If we need to transcode AMR = to >> OPUS the difference would be even higher. This translates in 10x >> difference in hardware, data center, power, and operations costs. >=20 > This was a good summary. I'm mostly concerned with the quality = degradations experienced by the end user and less about the cost (on the = other hand, I guess this would in the end hit the end users as well). >=20 > I think having a 'SHOULD' for a few additional codecs would reduce the = number of end users impacted by the degradations (and cost) mentioned, = and I think that would make a lot of sense. >=20 > Stefan >=20 >> _____________ >> Roman Shpount >>=20 >>=20 >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >>=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From stefan.lk.hakansson@ericsson.com Thu Jan 17 05:24:49 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AE1F21F8868 for ; Thu, 17 Jan 2013 05:24:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.282 X-Spam-Level: X-Spam-Status: No, score=-7.282 tagged_above=-999 required=5 tests=[AWL=0.667, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, 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 lrU1KnVCAeZl for ; Thu, 17 Jan 2013 05:24:48 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 6DDD421F887F for ; Thu, 17 Jan 2013 05:24:47 -0800 (PST) X-AuditID: c1b4fb2d-b7f316d0000028db-15-50f7fb9e3011 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 77.97.10459.E9BF7F05; Thu, 17 Jan 2013 14:24:47 +0100 (CET) Received: from [150.132.141.90] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.279.1; Thu, 17 Jan 2013 14:24:46 +0100 Message-ID: <50F7FB9E.9060907@ericsson.com> Date: Thu, 17 Jan 2013 14:24:46 +0100 From: =?ISO-8859-1?Q?Stefan_H=E5kansson_LK?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: rtcweb@ietf.org References: <50D2CC6A.4090500@ericsson.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D16813E56EC@HE111648.emea1.cds.t-internal.com> <50F41D97.1030508@nostrum.com> <50F43ACA.80206@nostrum.com> <50F44AF0.4060304@nostrum.com> <50F4619F.7040208@nostrum.com> <7CBFD4609D19C043A4AC4FD8381C6E2602386636@DEMUEXC014.nsn-intra.net> <50F5A74C.3030203@nostrum.com> <50F7F920.20104 03@ericsson.com> <5DCD8270-4DBD-413F-961F-3BFA20686A60@cs.georgetown.edu> In-Reply-To: <5DCD8270-4DBD-413F-961F-3BFA20686A60@cs.georgetown.edu> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHJMWRmVeSWpSXmKPExsUyM+Jvje78398DDD4sZbVY+6+d3YHRY8mS n0wBjFFcNimpOZllqUX6dglcGYcmPGUsuKta8fuuaAPjTbkuRk4OCQETibUzNjJD2GISF+6t Z+ti5OIQEjjJKPHj3mp2CGcNo8SZ1lNsIFW8AtoS3+e+Z+1i5OBgEVCV2LdcDSTMJhAocf3/ LyYQW1QgSuL91SZmiHJBiZMzn7CA2CICwhJbX/WC1QgLlEl0Tf/LCDF/A7vEye3/wBo4BVwl Xk96CGYzC9hKXJhznQXClpdo3jobLC4koCvx7vU91gmMArOQ7JiFpGUWkpYFjMyrGNlzEzNz 0ssNNzECw+zglt+6OxhPnRM5xCjNwaIkzhvmeiFASCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dU A6Ou5bRu+WCfxc3vX//6Ntn8yJGihO9/qydxVvjJWCa9lIleZ6J94NfanQW1tnWfn87dLCX8 98DGxKYjOpfnaftI96eVpUYklDfymbX37gqMVdHkW3SgP+1V8PzjYY/YtN6VyxSI6XgsKzfr u7poK2+Zd7nVD9dJffev8chnLfrGKX9kXfxbdyWW4oxEQy3mouJEAJwpetcBAgAA Subject: Re: [rtcweb] Consensus vs. Voting (was Re: Call for Consensus Regarding Selecting Recommended 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, 17 Jan 2013 13:24:49 -0000 On 2013-01-17 14:17, Burger Eric wrote: > So the argument here is the cost to the user is USD 0.0000001/call > instead of USD 0.00000001/call? I explicitly said my concern was the quality experienced by the end user, not the cost. At least that is what I wanted to say, and I don't think I was unclear. > > On Jan 17, 2013, at 8:14 AM, Stefan Hĺkansson LK > wrote: > >> On 2013-01-17 11:31, Roman Shpount wrote: >>> >>> On Wed, Jan 16, 2013 at 7:03 PM, Martin Thomson >>> > >>> wrote: >>> >>> If we don't say "webrtc implementations SHOULD implement >>> G.722/AMR/AMR-WB", what is the failure mode for your >>> application? Keeping in mind that - because this isn't 2119 MUST >>> - you have to expect that some non-negligible proportion of >>> clients will not support this no matter how much extra ink we >>> using in printing large letters, how much pain does this really >>> cause you? >>> >>> I expect that the transcoding costs are what this come down to. >>> Does anyone care to quantify this? >>> >>> >>> If common codecs are not implemented in the browser this would >>> mean transcoding will need to be performed on some sort of >>> server-side media gateway. There are three distinct issues we >>> need to take into account when dealing with transcoding. I would >>> list them in what, at least from my point of view, is the order >>> of importance: >>> >>> 1. If you need to do trancoding, you will need to implement a >>> jitter buffer on the transcoding media gateway. ICE processing >>> and SRTP en/decoding can be performed on out of order packets as >>> they are received. You cannot transcode out of order audio. This >>> means audio packets would need to be delayed by the jitter buffer >>> size. In cases of good internet connection this means 40 ms >>> jitter buffer delay. In cases of consumer internet in US >>> (somebody sitting on a DSL connection at home behind a WiFi >>> router) you are typically looking at 60-80 ms jitter buffer >>> delay. If you are dealing with international internet >>> connections jitter of 150 ms to 200 ms is not unheard of. This >>> means an additional delay due to jitter buffering of 40 ms (best >>> case) to 200 ms. This is in addition to any other delays that are >>> already present on the audio path. Adding an extra 100 ms of >>> delay can make audio conversions very awkward or unusable. On the >>> other hand, if the gateway were performing just ICE and SRTP, it >>> would introduce 1-2 ms of delay at most (In this case I am >>> talking about a software based implementation running on generic >>> server hardware. A dedicated DSP solution would probably be even >>> faster). >>> >>> 2. Audio artifacts due to transcoding. Apart from usual audio >>> degradation due to transcoding (OPUS transcoded to AMR would >>> sound worse then OPUS or AMR), we would also deal with double >>> packet loss concealment. Media gateway will conceal lost packets >>> when transcoding. Client will conceal lost packet received from >>> the gateway. This would actually sound worse then PLC performed >>> in one place. >>> >>> 3. Scalability of the transcoding gateway. Gateway which just >>> deals with ICE processing and SRTP en/decoding can handle from >>> 2000 to 10000 concurrent call when running on a generic server >>> CPU (different scalability is due to differences in CPU >>> performance and presence of AES specific instructions). Gateway >>> that would do G.722 to OPUS transcoding would most likely handle >>> from 500 to 1000 concurrent calls. We are looking at 10x >>> difference in performance. If we need to transcode AMR to OPUS >>> the difference would be even higher. This translates in 10x >>> difference in hardware, data center, power, and operations >>> costs. >> >> This was a good summary. I'm mostly concerned with the quality >> degradations experienced by the end user and less about the cost >> (on the other hand, I guess this would in the end hit the end users >> as well). >> >> I think having a 'SHOULD' for a few additional codecs would reduce >> the number of end users impacted by the degradations (and cost) >> mentioned, and I think that would make a lot of sense. >> >> Stefan >> >>> _____________ Roman Shpount >>> >>> >>> _______________________________________________ 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 eburger@cs.georgetown.edu Thu Jan 17 05:31:54 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB29F21F86BE for ; Thu, 17 Jan 2013 05:31:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2] 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 2MKnu-meQlBv for ; Thu, 17 Jan 2013 05:31:53 -0800 (PST) Received: from karma.cs.georgetown.edu (karma.cs.georgetown.edu [141.161.20.3]) by ietfa.amsl.com (Postfix) with ESMTP id 70CD021F86AF for ; Thu, 17 Jan 2013 05:31:53 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by karma.cs.georgetown.edu (Postfix) with ESMTP id 0F05442D74 for ; Thu, 17 Jan 2013 08:31:53 -0500 (EST) X-Virus-Scanned: by amavisd-new at cs.georgetown.edu Received: from karma.cs.georgetown.edu ([127.0.0.1]) by localhost (karma.cs.georgetown.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y52FNWpUqU4i for ; Thu, 17 Jan 2013 08:31:51 -0500 (EST) Received: from [192.168.15.177] (ip68-100-199-8.dc.dc.cox.net [68.100.199.8]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by karma.cs.georgetown.edu (Postfix) with ESMTP id 2F6A542CDF for ; Thu, 17 Jan 2013 08:31:51 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Burger Eric In-Reply-To: Date: Thu, 17 Jan 2013 08:31:54 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "rtcweb@ietf.org" X-Mailer: Apple Mail (2.1499) Subject: Re: [rtcweb] Consensus vs. Voting (was Re: Call for Consensus Regarding Selecting Recommended Audio Codecs) (UNCLASSIFIED) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 17 Jan 2013 13:31:54 -0000 People, let's be real: I get the impression that people think that if their favorite codec does = not become mandatory to implement or at least = implement-under-threat-of-SHOULD, then no one will implement their = favorite codec. Let us look at the real world. All of those mobile phones with AMR-WB? = They are statistically likely to be calling other mobile phones with = AMR-WB. Unless I missed something, RTCweb still lets the offer include = AMR-WB and the answer select AMR-WB. Your precious AMR-WB codec will = still get used, and you can leverage all of the silicon and pre-paid IPR = licenses. What about all of those Flash implementations with speex? They = are statistically likely to be calling other implementations with speex. = I am again only just guessing that the offer will contain speed and the = answer will contain speex. What about the poor slob on a mobile with AMR-WB that wants to call that = Flash buddy with speex? Last I looked, the specification has a MTI of = opus. They will connect with opus. If the client is RTCweb compliant, = THERE WILL BE NO AMR-WB/SPEEX/G.722/MUMBLE/FOO TO OPUS/G.711 = TRANSCODING. Now, what about the really poor slob on a non-RTCweb device? Well, they = are, ahem, on a non-RTCweb device. That is way out of scope. But wait, = you will say -- what about the 1.1 billion 3G subscribers with AMR-WB = but no RTCweb? Well, first off, the mobile-based RTCweb device will = almost certainly have AMR-WB. While some folks like to pick on mobile = phone manufacturers, I doubt some product manager is going to say, "Gee, = the IETF specification does not even mention AMR-WB, so I suppose I will = not enable the silicon I already paid for or use the license I already = paid for, and I will spend my engineering budget to take out AMR-WB." = Duh - AMR-WB will be there already, no transcoding, life is good. What = about fixed-line or broadband interoperability with some wireless user, = when they only have G.722? Well, while we are not making the situation = any better, THE SITUATION IS NO WORSE. Transcoding would happen ANYWAY. = It happens TODAY. So get with the program. Let us fill in the rat-hole and just move on. Two MTI codecs and a = SEPARATE implementation guide listing why you MIGHT want to implement = your favorite codec. [Hmmmm. "MIGHT". Perhaps a new 2119 term, meaning "You might consider = this, and if you don't do it, may may get cooties."] On Jan 17, 2013, at 7:54 AM, Andrew Allen wrote: >=20 > As I recall during the MTI discussion it was claimed that OPUS was = intended for interoperability between RTCweb endoints and G.711 for = interoperability with legacy. That's why we selected 2 MTI Codecs. >=20 > Transcoding between G.711 and something else like G.722 will not have = anything like the transcoding cost as between OPUS and G.722 - basically = the complexity of a media gateway. Of course you will not get the full = fidelity of either OPUS or G.722 but basic audio communications will = work fine which is all I think we can guarantee with legacy. >=20 > If platforms already have other codecs (such as AMR on mobile devices) = that are usable by the browser then it makes perfect sense that they be = included in the offer but I don't think IETF should start recommending = other codecs to implement other than the 2 MTI. This should be left as = product decisions based on commercial needs and not recommendations made = by IETF the driver for which I suspect has more to do with the interests = of some legacy products/deployments than those of RTCweb.=20 >=20 > Since almost every computing platform has a browser (including most = mobile phones) within a few years every computing platform will have = RTCweb and OPUS so the need for high fidelity legacy codec = interoperability will I think become a mute point. >=20 > I think the inteoperability concerns should be more focussed on the = video issue where we seem to have a real problem. >=20 > Andrew >=20 > ----- Original Message ----- > From: Roy, Radhika R CIV USARMY (US) = [mailto:radhika.r.roy.civ@mail.mil] > Sent: Thursday, January 17, 2013 06:13 AM Central Standard Time > To: Roman Shpount ; Martin Thomson = > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] Consensus vs. Voting (was Re: Call for Consensus = Regarding Selecting Recommended Audio Codecs) (UNCLASSIFIED) >=20 > Classification: UNCLASSIFIED > Caveats: NONE >=20 > Hi, all: >=20 > A good assessment - thanks to Roman.=20 >=20 > So, the transcoding cost is enormous from both performance and HW/SW > implementation point of view. >=20 > In the end it may so appear that we are not hearing each other. >=20 > BR/Radhika >=20 > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On = Behalf Of > Roman Shpount > Sent: Thursday, January 17, 2013 5:32 AM > To: Martin Thomson > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] Consensus vs. Voting (was Re: Call for Consensus > Regarding Selecting Recommended Audio Codecs) >=20 >=20 > On Wed, Jan 16, 2013 at 7:03 PM, Martin Thomson = > wrote: >=20 >=20 > If we don't say "webrtc implementations SHOULD implement > G.722/AMR/AMR-WB", what is the failure mode for your = application? > Keeping in mind that - because this isn't 2119 MUST - you have = to > expect that some non-negligible proportion of clients will not > support > this no matter how much extra ink we using in printing large > letters, > how much pain does this really cause you? > =09 > I expect that the transcoding costs are what this come down to. > Does > anyone care to quantify this? >=20 >=20 > If common codecs are not implemented in the browser this would mean > transcoding will need to be performed on some sort of server-side = media > gateway. There are three distinct issues we need to take into account = when > dealing with transcoding. I would list them in what, at least from my = point > of view, is the order of importance: >=20 > 1. If you need to do trancoding, you will need to implement a jitter = buffer > on the transcoding media gateway. ICE processing and SRTP en/decoding = can be > performed on out of order packets as they are received. You cannot = transcode > out of order audio. This means audio packets would need to be delayed = by the > jitter buffer size. In cases of good internet connection this means 40 = ms > jitter buffer delay. In cases of consumer internet in US (somebody = sitting > on a DSL connection at home behind a WiFi router) you are typically = looking > at 60-80 ms jitter buffer delay. If you are dealing with international > internet connections jitter of 150 ms to 200 ms is not unheard of. = This > means an additional delay due to jitter buffering of 40 ms (best case) = to > 200 ms. This is in addition to any other delays that are already = present on > the audio path. Adding an extra 100 ms of delay can make audio = conversions > very awkward or unusable. On the other hand, if the gateway were = performing > just ICE and SRTP, it would introduce 1-2 ms of delay at most (In this = case > I am talking about a software based implementation running on generic = server > hardware. A dedicated DSP solution would probably be even faster). >=20 > 2. Audio artifacts due to transcoding. Apart from usual audio = degradation > due to transcoding (OPUS transcoded to AMR would sound worse then OPUS = or > AMR), we would also deal with double packet loss concealment. Media = gateway > will conceal lost packets when transcoding. Client will conceal lost = packet > received from the gateway. This would actually sound worse then PLC > performed in one place. >=20 > 3. Scalability of the transcoding gateway. Gateway which just deals = with ICE > processing and SRTP en/decoding can handle from 2000 to 10000 = concurrent > call when running on a generic server CPU (different scalability is = due to > differences in CPU performance and presence of AES specific = instructions). > Gateway that would do G.722 to OPUS transcoding would most likely = handle > from 500 to 1000 concurrent calls. We are looking at 10x difference in > performance. If we need to transcode AMR to OPUS the difference would = be > even higher. This translates in 10x difference in hardware, data = center, > power, and operations costs. >=20 > _____________ > Roman Shpount >=20 > Classification: UNCLASSIFIED > Caveats: NONE >=20 >=20 >=20 > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential = information, privileged material (including material protected by the = solicitor-client or other applicable privileges), or constitute = non-public information. Any use of this information by anyone other than = the intended recipient is prohibited. If you have received this = transmission in error, please immediately reply to the sender and delete = this information from your system. Use, dissemination, distribution, or = reproduction of this transmission by unintended recipients is not = authorized and may be unlawful. > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From radhika.r.roy.civ@mail.mil Thu Jan 17 06:10:21 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C625A21F8765 for ; Thu, 17 Jan 2013 06:10:21 -0800 (PST) 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=-1.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 2T58zNhUjYmv for ; Thu, 17 Jan 2013 06:10:16 -0800 (PST) Received: from edge-cols.mail.mil (edge-cols.mail.mil [131.64.100.11]) by ietfa.amsl.com (Postfix) with ESMTP id 1BC2321F868F for ; Thu, 17 Jan 2013 06:10:15 -0800 (PST) Received: from UCOLHP3H.easf.csd.disa.mil (131.64.100.149) by ucolhp3l.easf.csd.disa.mil (131.64.100.11) with Microsoft SMTP Server (TLS) id 14.2.309.2; Thu, 17 Jan 2013 14:11:25 +0000 Received: from UCOLHP9L.easf.csd.disa.mil ([169.254.2.136]) by UCOLHP3H.easf.csd.disa.mil ([131.64.100.149]) with mapi id 14.02.0309.003; Thu, 17 Jan 2013 14:11:25 +0000 From: "Roy, Radhika R CIV USARMY (US)" To: Burger Eric , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Consensus vs. Voting (was Re: Call for Consensus Regarding Selecting Recommended Audio Codecs) (UNCLASSIFIED) Thread-Index: AQHN9LdFwwF57GbTP0W99XrAuOQrqZhNh17w Date: Thu, 17 Jan 2013 14:11:23 +0000 Message-ID: <8486C8728176924BAF5BDB2F7D7EEDDF4907E6F7@ucolhp9l.easf.csd.disa.mil> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [131.64.62.4] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0011_01CDF492.652FB3C0" MIME-Version: 1.0 Subject: Re: [rtcweb] Consensus vs. Voting (was Re: Call for Consensus Regarding Selecting Recommended Audio Codecs) (UNCLASSIFIED) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 17 Jan 2013 14:10:21 -0000 ------=_NextPart_000_0011_01CDF492.652FB3C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Classification: UNCLASSIFIED Caveats: NONE Folks: If transcoding is happening today in real-life situations and people are happy with the quality (assuming transcoding cost is negligible), we should not even need negotiations for the codec. Life will be simpler (if not simplest). Let us explore the audio codec options as stated below. If people want negotiations as far as practicable for a common codec before going for transcoding, then the question comes as follows: "At what point of negotiations, people will decide that we have to go for transcoding?" It appears that we should not go both ways (negotiations + transcoding). On the other hand, we can mandate two audio codecs: one for wired network and another for mobile wireless network. In this way, transcoding may occur only once for the calls that go between the wired and the wireless (mobile) network. If we want only one codec without any transcoding for both wireless (mobile) and wired network, we need to go for a single codec whose quality is reasonably acceptable for both wired and wireless (mobile) network. If we make more than two (wired + wireless) codecs mandatory, we can do so if the implementation cost is negligible. BR/Radhika -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Burger Eric Sent: Thursday, January 17, 2013 8:32 AM To: rtcweb@ietf.org Subject: Re: [rtcweb] Consensus vs. Voting (was Re: Call for Consensus Regarding Selecting Recommended Audio Codecs) (UNCLASSIFIED) People, let's be real: I get the impression that people think that if their favorite codec does not become mandatory to implement or at least implement-under-threat-of-SHOULD, then no one will implement their favorite codec. Let us look at the real world. All of those mobile phones with AMR-WB? They are statistically likely to be calling other mobile phones with AMR-WB. Unless I missed something, RTCweb still lets the offer include AMR-WB and the answer select AMR-WB. Your precious AMR-WB codec will still get used, and you can leverage all of the silicon and pre-paid IPR licenses. What about all of those Flash implementations with speex? They are statistically likely to be calling other implementations with speex. I am again only just guessing that the offer will contain speed and the answer will contain speex. What about the poor slob on a mobile with AMR-WB that wants to call that Flash buddy with speex? Last I looked, the specification has a MTI of opus. They will connect with opus. If the client is RTCweb compliant, THERE WILL BE NO AMR-WB/SPEEX/G.722/MUMBLE/FOO TO OPUS/G.711 TRANSCODING. Now, what about the really poor slob on a non-RTCweb device? Well, they are, ahem, on a non-RTCweb device. That is way out of scope. But wait, you will say -- what about the 1.1 billion 3G subscribers with AMR-WB but no RTCweb? Well, first off, the mobile-based RTCweb device will almost certainly have AMR-WB. While some folks like to pick on mobile phone manufacturers, I doubt some product manager is going to say, "Gee, the IETF specification does not even mention AMR-WB, so I suppose I will not enable the silicon I already paid for or use the license I already paid for, and I will spend my engineering budget to take out AMR-WB." Duh - AMR-WB will be there already, no transcoding, life is good. What about fixed-line or broadband interoperability with some wireless user, when they only have G.722? Well, while we are not making the situation any better, THE SITUATION IS NO WORSE. Transcoding would happen ANYWAY. It happens TODAY. So get with the program. Let us fill in the rat-hole and just move on. Two MTI codecs and a SEPARATE implementation guide listing why you MIGHT want to implement your favorite codec. [Hmmmm. "MIGHT". Perhaps a new 2119 term, meaning "You might consider this, and if you don't do it, may may get cooties."] On Jan 17, 2013, at 7:54 AM, Andrew Allen wrote: > > As I recall during the MTI discussion it was claimed that OPUS was intended for interoperability between RTCweb endoints and G.711 for interoperability with legacy. That's why we selected 2 MTI Codecs. > > Transcoding between G.711 and something else like G.722 will not have anything like the transcoding cost as between OPUS and G.722 - basically the complexity of a media gateway. Of course you will not get the full fidelity of either OPUS or G.722 but basic audio communications will work fine which is all I think we can guarantee with legacy. > > If platforms already have other codecs (such as AMR on mobile devices) that are usable by the browser then it makes perfect sense that they be included in the offer but I don't think IETF should start recommending other codecs to implement other than the 2 MTI. This should be left as product decisions based on commercial needs and not recommendations made by IETF the driver for which I suspect has more to do with the interests of some legacy products/deployments than those of RTCweb. > > Since almost every computing platform has a browser (including most mobile phones) within a few years every computing platform will have RTCweb and OPUS so the need for high fidelity legacy codec interoperability will I think become a mute point. > > I think the inteoperability concerns should be more focussed on the video issue where we seem to have a real problem. > > Andrew > > ----- Original Message ----- > From: Roy, Radhika R CIV USARMY (US) > [mailto:radhika.r.roy.civ@mail.mil] > Sent: Thursday, January 17, 2013 06:13 AM Central Standard Time > To: Roman Shpount ; Martin Thomson > > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] Consensus vs. Voting (was Re: Call for Consensus > Regarding Selecting Recommended Audio Codecs) (UNCLASSIFIED) > > Classification: UNCLASSIFIED > Caveats: NONE > > Hi, all: > > A good assessment - thanks to Roman. > > So, the transcoding cost is enormous from both performance and HW/SW > implementation point of view. > > In the end it may so appear that we are not hearing each other. > > BR/Radhika > Classification: UNCLASSIFIED Caveats: NONE ------=_NextPart_000_0011_01CDF492.652FB3C0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISizCCA3Aw ggJYoAMCAQICAQUwDQYJKoZIhvcNAQEFBQAwWzELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4g R292ZXJubWVudDEMMAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxFjAUBgNVBAMTDURvRCBSb290 IENBIDIwHhcNMDQxMjEzMTUwMDEwWhcNMjkxMjA1MTUwMDEwWjBbMQswCQYDVQQGEwJVUzEYMBYG A1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEWMBQGA1UE AxMNRG9EIFJvb3QgQ0EgMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMAswfaNO6z/ PzzWcb64dCIH7HBBFfyrQOMHqsHD2J/+2kw6vz/I2Ch7SzYBwKxFJcPSDgqPhRhkED0aE3Aqb47X 3I2Ts0EPOCHNravCPSoF01cRNw3NjFH5k+PMRkkhjhS0zcsUPjjNcjHuqxLyZeo0LlZd/+5jdctt upE0/J7z9C0cvlDEQt9ZiP9qs/qobD3LVnFxBZa7n4DlgEVZZ0Gw68OtYKSAdQYXnA70Q+CZDhv7 f/WzzLKBgrH9MsG4vkGkZLVgOlpRMIzO3kEsGUdcSRBkuXSph0GvfW66wbihv2UxOgRn+bW7jpKK AGO4seaMOF+D/1DVO6Jda7IQzGMCAwEAAaM/MD0wHQYDVR0OBBYEFEl0uwxeunr+AlTve6DGlcYJ gHCWMAsGA1UdDwQEAwIBhjAPBgNVHRMBAf8EBTADAQH/MA0GCSqGSIb3DQEBBQUAA4IBAQCYkY0/ ici79cBpcyk7Nay6swh2PXAJkumERCEBfRR2G+5RbB2NFTctezFp9JpEuK9GzDT6I8sDJxnSgyF1 K+fgG5km3IRAleio0sz2WFxm7z9KlxCCHboKot1bBiudp2RO6y4BNaS0PxOtVeTVc6hpmxHxmPIx Hm9A1Ph4n46RoG9wBJBmqgYrzuF6krV94eDRluehOi3MsZ0fBUTth5nTTRpwOcEEDOV+2fGv1yAO 8SJ6JaRzmcw/pAcnlqiile2CuRbTnguHwsHyiPVi32jfx7xpUe2xXNxUVCkPCTmarAPB2wxNrm8K ehZJ8b+R0jiU0/aVLLdsyUK2jcqQjYXZMIIEtzCCA5+gAwIBAgIDHzzKMA0GCSqGSIb3DQEBBQUA MF0xCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEM MAoGA1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwgQ0EtMjkwHhcNMTIwOTIwMDAwMDAwWhcN MTUwOTE5MjM1OTU5WjB5MQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQww CgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEMMAoGA1UECxMDVVNBMSYwJAYDVQQDEx1ST1kuUkFE SElLQS5SQU5KQU4uMTI5MTkzOTgwMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKw9 ymde30NtacDt8neYCBWDyA+Hlsk3dNwV23IVgH7vSWJx4zCFT5ojDHACm3lthvOOtJ0CzkjwQy8V hEHvL0eK03hZy0hJrZxQSYcao7Y0Yv9yDAFvxa6LJ1fUImUj9edMf1l08LZkjh3ybs20Bk+MLySR 9F/flRzjtCwVUeqq8NS3to4nPXSIgViP6H0YJrBjf9IDZQGgcO8LxLbNENOWrXILeCCCngnHBgHV lJWak9YndpMOs+CeLXk5oUV8xUAM/UjyS+/gFCjABBRt30VJVN6pqARmIht850iK8TDeqlWwF3O9 eQBBwKQPJ7nVl0kmGItYGoYb+4t2Mkwalh8CAwEAAaOCAWIwggFeMB8GA1UdIwQYMBaAFLhDg2Qh eu5wgd6l3gxgKId4rl54MDoGA1UdHwQzMDEwL6AtoCuGKWh0dHA6Ly9jcmwuZGlzYS5taWwvY3Js L0RPREVNQUlMQ0FfMjkuY3JsMA4GA1UdDwEB/wQEAwIFIDAjBgNVHSAEHDAaMAsGCWCGSAFlAgEL CTALBglghkgBZQIBCxMwHQYDVR0OBBYEFGRWf703swy+9hvoDujsb+ZPwC9MMGgGCCsGAQUFBwEB BFwwWjA2BggrBgEFBQcwAoYqaHR0cDovL2NybC5kaXNhLm1pbC9zaWduL0RPREVNQUlMQ0FfMjku Y2VyMCAGCCsGAQUFBzABhhRodHRwOi8vb2NzcC5kaXNhLm1pbDAkBgNVHREEHTAbgRlyYWRoaWth LnIucm95QHVzLmFybXkubWlsMBsGA1UdCQQUMBIwEAYIKwYBBQUHCQQxBBMCVVMwDQYJKoZIhvcN AQEFBQADggEBAE9PU63Rc/bneYoxI6sAZi+oXBiwneOiI03+J3pSZWIbwrOnj7qGoH5ZoeO+dZ8E wvKszd+vacYnO8SqEXsvIKvBGPchKg1oV5b24+tCSeiCXtcX5EDtpJQGS4W9G+7r7f+mdEHU0NuF NI7HNHRY/q4C+FGhchPoKPcKeyWxJMwp+9NJQsx1AoC5isvydZHHlNkV917dLMuMEqyCCAAbJAOp 8SDQTiiIVa1I7NlMSlkzNRUtFoO9nsEttMH699V9JH5jcwWPlWdyb5B6yRzoM/iFsI/hA9pHHukh iWVul3FX/6Ez8Jt/A1j/CFsl3S2y2TBRCdqIQEP+/H6j4RFxa9MwggUCMIID6qADAgECAgMfPMkw DQYJKoZIhvcNAQEFBQAwXTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEM MAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxGDAWBgNVBAMTD0RPRCBFTUFJTCBDQS0yOTAeFw0x MjA5MjAwMDAwMDBaFw0xNTA5MTkyMzU5NTlaMHkxCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMu IEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJMQwwCgYDVQQLEwNVU0ExJjAk BgNVBAMTHVJPWS5SQURISUtBLlJBTkpBTi4xMjkxOTM5ODAxMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEAyr7Ttduf1mHx22erLvkwPOZL02imdiimrmXITVrdUHsynK383NY6a4ye07Jm b0spr8hzmfM6JSCEgtbZevWfJg4NmNDjEEe53+7EvEMRHfh46GGxOckj98QmQwngbQaAIcKI1gJd Do2vB3mOtFp5hNKqsxibZAvpPb3OsR762vrx2QYQX+p8+psLwe95CSt56IfC39GZD+Otus3Sq1Ma 9e0NdRhqg5ch8FYpL2ONbmEw9+DTqk24Zh2lQuOvpo4FhpvXnNghCS4CfuiE6YgvKdombc1BGT5u rkDFep5IH7Rk7EnK4CVVzNq3gxT0B+hDoJT0AuQfrkxI9223mUJoywIDAQABo4IBrTCCAakwHwYD VR0jBBgwFoAUuEODZCF67nCB3qXeDGAoh3iuXngwOgYDVR0fBDMwMTAvoC2gK4YpaHR0cDovL2Ny bC5kaXNhLm1pbC9jcmwvRE9ERU1BSUxDQV8yOS5jcmwwDgYDVR0PAQH/BAQDAgbAMCMGA1UdIAQc MBowCwYJYIZIAWUCAQsJMAsGCWCGSAFlAgELEzAdBgNVHQ4EFgQUrV8KnskfJHURS19In/mX0d2y 9pgwaAYIKwYBBQUHAQEEXDBaMDYGCCsGAQUFBzAChipodHRwOi8vY3JsLmRpc2EubWlsL3NpZ24v RE9ERU1BSUxDQV8yOS5jZXIwIAYIKwYBBQUHMAGGFGh0dHA6Ly9vY3NwLmRpc2EubWlsMEQGA1Ud EQQ9MDuBGXJhZGhpa2Euci5yb3lAdXMuYXJteS5taWygHgYKKwYBBAGCNxQCA6AQDA4xMjkxOTM5 ODAxQG1pbDAbBgNVHQkEFDASMBAGCCsGAQUFBwkEMQQTAlVTMCkGA1UdJQQiMCAGCisGAQQBgjcU AgIGCCsGAQUFBwMCBggrBgEFBQcDBDANBgkqhkiG9w0BAQUFAAOCAQEAggVw28drobHRF6Zr7wQZ G/ShO0BE6jEddlmlqj9ln2mC5HoTTXkl2ZOqjUoh2Wq2d55KvbZk9b73bIzWK+RnnoU+zOHagyB/ VnEbSpdofTm50zJYISK7Ws92KCt8viNetFkS2CTNSc302cqmwejpTwKAxkLDM0wU7ECNopN87F0O vPU2AJnITH32PrAvTVOeCxsDdEnzzXYxvKtNE5K6zBVVumSOGLMfnyFAq+4dlhg7i25B8Goh+fIF eRGiwxsXOyEMPalWHt5wWDDmUlIK0Qmg95mZ7f6UJCmj15zzSxgliR+JyVlFGH6/HYzIAU4lv8b5 uU5qyxANtVCvuGDruDCCBVIwggQ6oAMCAQICAgG4MA0GCSqGSIb3DQEBBQUAMFsxCzAJBgNVBAYT AlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJ MRYwFAYDVQQDEw1Eb0QgUm9vdCBDQSAyMB4XDTExMDkwODE2MDIxNFoXDTE3MDkwODE2MDIxNFow XTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEMMAoGA1UECxMDRG9EMQww CgYDVQQLEwNQS0kxGDAWBgNVBAMTD0RPRCBFTUFJTCBDQS0yOTCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAJJiL0HCIAAWBlVkn72niBVugptIwYV3vQKrDNnxK2CBAbo+dXCOEqanOISQ s+lAgBLcaspRza0thhDMRLwOxVg4GbIUMiVBVFhcQw7IbHMPwwwYGBYEmlI9gaJxzjwyAJ9xVbr4 zjZ3HiG3KJTnPT6m9sB6MWCRKJd3IlDyxpNushvFQcb5oTf7EL/aVqb7Uk1fv+/Elnco5TL/6OEY zENSGKyNd5pyTOidA16wou/k3dLn5qemUq3hmAiWSkPMcz1Loo2J79yCTLhKgCRlKx6RgvUE9nIf VxhAF/A5UbaP84k7Z/dYTkq82vkOwcAMvfMIcfiDD8kugJX0hQ7OrqkCAwEAAaOCAhwwggIYMA4G A1UdDwEB/wQEAwIBhjAfBgNVHSMEGDAWgBRJdLsMXrp6/gJU73ugxpXGCYBwljAdBgNVHQ4EFgQU uEODZCF67nCB3qXeDGAoh3iuXngwEgYDVR0TAQH/BAgwBgEB/wIBADAMBgNVHSQEBTADgAEAMGYG A1UdIARfMF0wCwYJYIZIAWUCAQsFMAsGCWCGSAFlAgELCTALBglghkgBZQIBCxEwCwYJYIZIAWUC AQsSMAsGCWCGSAFlAgELEzAMBgpghkgBZQMCAQMaMAwGCmCGSAFlAwIBAxswNwYDVR0fBDAwLjAs oCqgKIYmaHR0cDovL2NybC5kaXNhLm1pbC9jcmwvRE9EUk9PVENBMi5jcmwwggEBBggrBgEFBQcB AQSB9DCB8TA6BggrBgEFBQcwAoYuaHR0cDovL2NybC5kaXNhLm1pbC9pc3N1ZWR0by9ET0RST09U Q0EyX0lULnA3YzAgBggrBgEFBQcwAYYUaHR0cDovL29jc3AuZGlzYS5taWwwgZAGCCsGAQUFBzAC hoGDbGRhcDovL2NybC5nZHMuZGlzYS5taWwvY24lM2REb0QlMjBSb290JTIwQ0ElMjAyJTJjb3Ul M2RQS0klMmNvdSUzZERvRCUyY28lM2RVLlMuJTIwR292ZXJubWVudCUyY2MlM2RVUz9jcm9zc0Nl cnRpZmljYXRlUGFpcjtiaW5hcnkwDQYJKoZIhvcNAQEFBQADggEBACxrLHk12/AeHId7q+HoaWo3 i9t6T1VgaZUvU53GykO21DeR1gNdflqxuB33noHTrlBUMKRvSy67FBsXqlwQ05R6MTmWpFR59elW LlXDGxbqqgLIz1H3MoEixjQ6qc2aqkiTx+n7HjJ+ccR28EVUEh1V6r1cMoc6rpOabpkiX6hRNe6y U2Bf9k9FuBaEHWVVzRXKEAEfqdKcp1eRo9fnsIY9LfSJOtjJd3BQxmzv8uuY+BCqPdrIXCmtzrhz SUyhkrvm7c26ghpjIRll9AYZv4Oqc+XTG7GY/0Xf+0nMc+ji5weWADHpf9kkCOfKRHpIBsNC2D/5 eYelN5IWqYQgkmMxggMyMIIDLgIBATBkMF0xCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdv dmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwg Q0EtMjkCAx88yTAJBgUrDgMCGgUAoIIBozAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xMzAxMTcxNDA5NDZaMCMGCSqGSIb3DQEJBDEWBBSFPQuGwBuTDtZ+uiX/rT4F G6yB3jBYBgkqhkiG9w0BCQ8xSzBJMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMC BzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG9w0CBTBzBgkrBgEEAYI3EAQxZjBkMF0x CzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoG A1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwgQ0EtMjkCAx88yjB1BgsqhkiG9w0BCRACCzFm oGQwXTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEMMAoGA1UECxMDRG9E MQwwCgYDVQQLEwNQS0kxGDAWBgNVBAMTD0RPRCBFTUFJTCBDQS0yOQIDHzzKMA0GCSqGSIb3DQEB AQUABIIBAJDF5HLEntorXHusvkuPiYP2m9ke6FheycKv6/dBhXUQyqMsX7BkVDp/cKFXYCd/pLpa fnR1EaJtN/+27s2qO0Lh60ma85U1v66rrc0ImqieSccWF3GeJRlVWnxdoKbDLxUrWepYjXdsmWTN cnRUpYL2q7Ul7kOH/hJWG9zqFfZ3LBxuo5D6YC5cdzv2qggMtj10NobS7lXEbMMytdpY6DkVmyzD BxevhCscvUbUn+BND5m6YKTuz9VmVV2ImUR8ZrCL5w5gM9I4vR7aoOj3sBwux3DXSMb7Xjis1dFO bT6uCj8sH7h6Od7AvNV7vA2F+NAp62IPqnShP1IAr/2mdncAAAAAAAA= ------=_NextPart_000_0011_01CDF492.652FB3C0-- From tim@phonefromhere.com Thu Jan 17 06:16:18 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B3AC21F8754 for ; Thu, 17 Jan 2013 06:16:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.046 X-Spam-Level: X-Spam-Status: No, score=-1.046 tagged_above=-999 required=5 tests=[AWL=-1.448, BAYES_00=-2.599, GB_I_LETTER=-2, GB_SUMOF=5, 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 TsqCdMlZ6DbQ for ; Thu, 17 Jan 2013 06:16:17 -0800 (PST) Received: from smtp004.apm-internet.net (smtp004.apm-internet.net [85.119.248.54]) by ietfa.amsl.com (Postfix) with ESMTP id B363B21F8753 for ; Thu, 17 Jan 2013 06:16:15 -0800 (PST) Received: (qmail 53090 invoked from network); 17 Jan 2013 14:16:14 -0000 X-AV-Scan: clean Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp004.apm-internet.net with SMTP; 17 Jan 2013 14:16:14 -0000 Received: from [192.67.4.33] (unknown [192.67.4.33]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id 2A1E218A0B02; Thu, 17 Jan 2013 14:16:14 +0000 (GMT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_1A07EA54-84BB-4791-B636-3E7A4FC15E8E" From: Tim Panton In-Reply-To: Date: Thu, 17 Jan 2013 14:16:12 +0000 Message-Id: <9BA7D840-480D-4883-B170-303305376698@phonefromhere.com> References: <50D2CC6A.4090500@ericsson.com> <6515_1357907583_50F0067F_6515_1738_1_2842AD9A45C83B44B57635FD4831E60A0747CC@PEXCVZYM14.corporate.adroot.infra.ftgroup> <580BEA5E3B99744AB1F5BFF5E9A3C67D16813E56EC@HE111648.emea1.cds.t-internal.com> <50F41D97.1030508@nostrum.com> <50F43ACA.80206@nostrum.com> <50F44AF0.4060304@nostrum.com> <50F4619F.7040208@nostrum.com> <7CBFD4609D19C043A4AC4FD8381C6E2602386636@DEMUEXC014.nsn-intra.net> <50F5A74C.3030203@nostrum.com> To: Roman Shpount X-Mailer: Apple Mail (2.1283) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Consensus vs. Voting (was Re: Call for Consensus Regarding Selecting Recommended 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, 17 Jan 2013 14:16:18 -0000 --Apple-Mail=_1A07EA54-84BB-4791-B636-3E7A4FC15E8E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 17 Jan 2013, at 10:31, Roman Shpount wrote: >=20 > On Wed, Jan 16, 2013 at 7:03 PM, Martin Thomson = wrote: > If we don't say "webrtc implementations SHOULD implement > G.722/AMR/AMR-WB", what is the failure mode for your application? > Keeping in mind that - because this isn't 2119 MUST - you have to > expect that some non-negligible proportion of clients will not support > this no matter how much extra ink we using in printing large letters, > how much pain does this really cause you? >=20 > I expect that the transcoding costs are what this come down to. Does > anyone care to quantify this? >=20 > If common codecs are not implemented in the browser this would mean = transcoding will need to be performed on some sort of server-side media = gateway. There are three distinct issues we need to take into account = when dealing with transcoding. I would list them in what, at least from = my point of view, is the order of importance: >=20 > 1. If you need to do trancoding, you will need to implement a jitter = buffer on the transcoding media gateway. ICE processing and SRTP = en/decoding can be performed on out of order packets as they are = received. You cannot transcode out of order audio. This means audio = packets would need to be delayed by the jitter buffer size. In cases of = good internet connection this means 40 ms jitter buffer delay. In cases = of consumer internet in US (somebody sitting on a DSL connection at home = behind a WiFi router) you are typically looking at 60-80 ms jitter = buffer delay. If you are dealing with international internet connections = jitter of 150 ms to 200 ms is not unheard of. This means an additional = delay due to jitter buffering of 40 ms (best case) to 200 ms. This is in = addition to any other delays that are already present on the audio path. = Adding an extra 100 ms of delay can make audio conversions very awkward = or unusable. On the other hand, if the gateway were performing just ICE = and SRTP, it would introduce 1-2 ms of delay at most (In this case I am = talking about a software based implementation running on generic server = hardware. A dedicated DSP solution would probably be even faster). Wait, you run the risk of double counting (at least to some extent). The = overall jitter from Alice to Bob isn't changed by transcoding.=20 I think you are implying that because we transcode in the middle, there = will be 2 jitterbuffers and the sum of the depth of these jitterbuffers = will exceed the depth of the single jitterbuffer that would be needed if = there was no transcoding. I agree, but I dispute that the sum of these 2 = jitterbuffers would be more than 20ms greater than the individual = jitterbuffer that Bob would run anyway.=20 If you look at the typical deployment scenario for 722 - Bob is either a = conference mixer engine or using a desktop phone on a wire to a reliable = low loss company network. Most of the packet jitter (and loss) occurs in = the first couple of hops from Alice's browser through the wifi and the = cafe's DSL,=20 so the jitterbuffer in the middle is probably the right place to put it. =20 >=20 > 2. Audio artifacts due to transcoding. Apart from usual audio = degradation due to transcoding (OPUS transcoded to AMR would sound worse = then OPUS or AMR), we would also deal with double packet loss = concealment. Media gateway will conceal lost packets when transcoding. = Client will conceal lost packet received from the gateway. This would = actually sound worse then PLC performed in one place. This is true, but I'd need to hear examples to be convinced it is = significant. My informal experiments calling 722 endpoints from opus = sound pretty good. People live with gsm610 transcoded to g729 all the time and that sounds = horrible. >=20 > 3. Scalability of the transcoding gateway. Gateway which just deals = with ICE processing and SRTP en/decoding can handle from 2000 to 10000 = concurrent call when running on a generic server CPU (different = scalability is due to differences in CPU performance and presence of AES = specific instructions). Gateway that would do G.722 to OPUS transcoding = would most likely handle from 500 to 1000 concurrent calls. We are = looking at 10x difference in performance. If we need to transcode AMR to = OPUS the difference would be even higher. This translates in 10x = difference in hardware, data center, power, and operations costs. This is fair comment, but I'm afraid it isn't enough to convince me we = SHOULD RECOMMEND G722. > _____________ > Roman Shpount > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --Apple-Mail=_1A07EA54-84BB-4791-B636-3E7A4FC15E8E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1

On Wed, Jan 16, 2013 at 7:03 PM, Martin Thomson = <martin.thomson@gmail.com> = wrote:
If we don't say "webrtc implementations SHOULD = implement
G.722/AMR/AMR-WB", what is the failure mode for your application?
Keeping in mind that - because this isn't 2119 MUST - you have to
expect that some non-negligible proportion of clients will not = support
this no matter how much extra ink we using in printing large = letters,
how much pain does this really cause you?

I expect that the transcoding costs are what this come down to. =  Does
anyone care to quantify this?

If common = codecs are not implemented in the browser this would mean transcoding = will need to be performed on some sort of server-side media gateway. = There are three distinct issues we need to take into account when = dealing with transcoding. I would list them in what, at least from my = point of view, is the order of importance:

1. If you need to do trancoding, you will need to implement a jitter = buffer on the transcoding media gateway. ICE processing and SRTP = en/decoding can be performed on out of order packets as they are = received. You cannot transcode out of order audio. This means audio = packets would need to be delayed by the jitter buffer size. In cases of = good internet connection this means 40 ms jitter buffer delay. In cases = of consumer internet in US (somebody sitting on a DSL connection at home = behind a WiFi router) you are typically looking at 60-80 ms jitter = buffer delay. If you are dealing with international internet connections = jitter of 150 ms to 200 ms is not unheard of. This means an additional = delay due to jitter buffering of 40 ms (best case) to 200 ms. This is in = addition to any other delays that are already present on the audio path. = Adding an extra 100 ms of delay can make audio conversions very awkward = or unusable. On the other hand, if the gateway were performing just ICE = and SRTP, it would introduce 1-2 ms of delay at most (In this case I am = talking about a software based implementation running on generic server = hardware. A dedicated DSP solution would probably be even = faster).

Wait, you run the risk of double = counting (at least to some extent). The overall jitter from Alice to Bob = isn't changed by transcoding. 
I think you are implying = that because we transcode in the middle, there will be 2 jitterbuffers = and the sum of the depth of these jitterbuffers will
exceed = the depth of the single jitterbuffer that would be needed if there was = no transcoding. I agree, but I dispute that the sum of these 2 = jitterbuffers would be more than 20ms greater than the individual = jitterbuffer that Bob would run = anyway. 

If you look at the typical = deployment scenario for 722 - Bob is either a conference mixer engine or = using a desktop phone on a wire to a reliable low loss company network. = Most of the packet jitter (and loss) occurs in the first couple of hops = from Alice's browser through the wifi and the cafe's = DSL, 
so the jitterbuffer in the middle is probably the = right place to put it.
 

2. Audio artifacts due to transcoding. Apart from usual audio = degradation due to transcoding (OPUS transcoded to AMR would sound worse = then OPUS or AMR), we would also deal with double packet loss = concealment. Media gateway will conceal lost packets when transcoding. = Client will conceal lost packet received from the gateway. This would = actually sound worse then PLC performed in one = place.

This is true, but I'd need to = hear examples to be convinced it is significant. My informal experiments = calling 722 endpoints from opus sound pretty good.
People live = with gsm610 transcoded to g729 all the time and that sounds = horrible.


3. Scalability of the transcoding gateway. Gateway which just deals = with ICE processing and SRTP en/decoding can handle from 2000 to 10000 = concurrent call when running on a generic server CPU (different = scalability is due to differences in CPU performance and presence of AES = specific instructions). Gateway that would do G.722 to OPUS transcoding = would most likely handle from 500 to 1000 concurrent calls. We are = looking at 10x difference in performance. If we need to transcode AMR to = OPUS the difference would be even higher. This translates in 10x = difference in hardware, data center, power, and operations costs.

This is fair comment, but = I'm afraid it isn't enough to convince me we SHOULD RECOMMEND = G722.


_____________
Roman Shpount
_______________________________________________
rtcweb mailing = list
rtcweb@ietf.org
https://www.ietf.or= g/mailman/listinfo/rtcweb

= --Apple-Mail=_1A07EA54-84BB-4791-B636-3E7A4FC15E8E-- From adam@nostrum.com Thu Jan 17 06:18:58 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22ECB21F85A0 for ; Thu, 17 Jan 2013 06:18:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.511 X-Spam-Level: X-Spam-Status: No, score=-102.511 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, SPF_PASS=-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 Xbcm6eX8daX4 for ; Thu, 17 Jan 2013 06:18:57 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 8B05921F859B for ; Thu, 17 Jan 2013 06:18:57 -0800 (PST) Received: from Orochi.local (99-152-144-32.lightspeed.dllstx.sbcglobal.net [99.152.144.32]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r0HEIkN8057973 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 17 Jan 2013 08:18:47 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <50F80846.5030300@nostrum.com> Date: Thu, 17 Jan 2013 08:18:46 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "Rauschenbach, Uwe (NSN - DE/Munich)" References: <8486C8728176924BAF5BDB2F7D7EEDDF4907E630@ucolhp9l.easf.csd.disa.mil> <7CBFD4609D19C043A4AC4FD8381C6E26023CF7B3@DEMUEXC014.nsn-intra.net> In-Reply-To: <7CBFD4609D19C043A4AC4FD8381C6E26023CF7B3@DEMUEXC014.nsn-intra.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 99.152.144.32 is authenticated by a trusted mechanism) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Consensus vs. Voting (was Re: Call for Consensus Regarding Selecting Recommended Audio Codecs) (UNCLASSIFIED) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 17 Jan 2013 14:18:58 -0000 On 1/17/13 07:16, Rauschenbach, Uwe (NSN - DE/Munich) wrote: >> -----Original Message----- >> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On >> Behalf Of ext Andrew Allen >> >> Since almost every computing platform has a browser (including most >> mobile phones) within a few years every computing platform will have >> RTCweb and OPUS so the need for high fidelity legacy codec >> interoperability will I think become a mute point. >> > This is not the point. The use case is to enable a user of an RTCWeb > service to reach another user via the legacy telephone network, be it > mobile or fixed. The fact whether or not the browser on the mobile phone > is capable of RTCWeb is of no relevance for this use case, because it > may well be that the two call parties use different RTCWeb services with > no interconnection, and the only way to reach each other is via the > telephone network. > If you're using the existing PSTN as your lowest-common-denominator interconnect, then the call *is* going to be G.711 at some point in its life. And given that the WebRTC endpoints can talk G.711 to the PSTN gateway -- G.711 being MTI -- this use case is already addressed. /a From uwe.rauschenbach@nsn.com Thu Jan 17 06:24:26 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADE4A21F86AC for ; Thu, 17 Jan 2013 06:24:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.849 X-Spam-Level: X-Spam-Status: No, score=-6.849 tagged_above=-999 required=5 tests=[AWL=-0.250, 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 wMkf2FOmI+ls for ; Thu, 17 Jan 2013 06:24:26 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id E197F21F862D for ; Thu, 17 Jan 2013 06:24:25 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id r0HEOOHV027137 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 17 Jan 2013 15:24:24 +0100 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id r0HEONSN028135; Thu, 17 Jan 2013 15:24:23 +0100 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 17 Jan 2013 15:24:23 +0100 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: Thu, 17 Jan 2013 15:24:22 +0100 Message-ID: <7CBFD4609D19C043A4AC4FD8381C6E26023CF832@DEMUEXC014.nsn-intra.net> In-Reply-To: <50F80846.5030300@nostrum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] Consensus vs. Voting (was Re: Call for Consensus Regarding Selecting Recommended Audio Codecs) (UNCLASSIFIED) Thread-Index: Ac30vZpjgcZ1oRrZQAGqXjxy3A+MtAAAC+PA References: <8486C8728176924BAF5BDB2F7D7EEDDF4907E630@ucolhp9l.easf.csd.disa.mil> <7CBFD4609D19C043A4AC4FD8381C6E26023CF7B3@DEMUEXC014.nsn-intra.net> <50F80846.5030300@nostrum.com> From: "Rauschenbach, Uwe (NSN - DE/Munich)" To: "ext Adam Roach" X-OriginalArrivalTime: 17 Jan 2013 14:24:23.0447 (UTC) FILETIME=[58CDFA70:01CDF4BE] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 1491 X-purgate-ID: 151667::1358432664-0000215D-86D9D778/0-0/0-0 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Consensus vs. Voting (was Re: Call for Consensus Regarding Selecting Recommended Audio Codecs) (UNCLASSIFIED) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 17 Jan 2013 14:24:26 -0000 > -----Original Message----- > From: ext Adam Roach [mailto:adam@nostrum.com] >=20 > On 1/17/13 07:16, Rauschenbach, Uwe (NSN - DE/Munich) wrote: > >> -----Original Message----- > >> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > >> Behalf Of ext Andrew Allen > >> > >> Since almost every computing platform has a browser (including most > >> mobile phones) within a few years every computing platform will have > >> RTCweb and OPUS so the need for high fidelity legacy codec > >> interoperability will I think become a mute point. > >> > > This is not the point. The use case is to enable a user of an RTCWeb > > service to reach another user via the legacy telephone network, be it > > mobile or fixed. The fact whether or not the browser on the mobile > phone > > is capable of RTCWeb is of no relevance for this use case, because it > > may well be that the two call parties use different RTCWeb services > with > > no interconnection, and the only way to reach each other is via the > > telephone network. > > >=20 > If you're using the existing PSTN as your lowest-common-denominator > interconnect, then the call *is* going to be G.711 at some point in its > life. And given that the WebRTC endpoints can talk G.711 to the PSTN > gateway -- G.711 being MTI -- this use case is already addressed. >=20 > /a I subsume under "legacy telephone network" both the fixed network (G.711) and the mobile network (AMR-WB). =20 Uwe From tim@phonefromhere.com Thu Jan 17 06:24:35 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A0AA21F862D for ; Thu, 17 Jan 2013 06:24:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.184 X-Spam-Level: X-Spam-Status: No, score=-2.184 tagged_above=-999 required=5 tests=[AWL=0.414, 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 hrtw6VeuTyaI for ; Thu, 17 Jan 2013 06:24:34 -0800 (PST) Received: from smtp003.apm-internet.net (smtp003.apm-internet.net [85.119.248.52]) by ietfa.amsl.com (Postfix) with ESMTP id 4C72E21F86B6 for ; Thu, 17 Jan 2013 06:24:34 -0800 (PST) Received: (qmail 50353 invoked from network); 17 Jan 2013 14:24:33 -0000 X-AV-Scan: clean Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp003.apm-internet.net with SMTP; 17 Jan 2013 14:24:33 -0000 Received: from [192.67.4.33] (unknown [192.67.4.33]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id CF32618A0AEA; Thu, 17 Jan 2013 14:24:32 +0000 (GMT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_C9153602-426F-4A16-80CF-F35ABB1C7219" From: Tim Panton In-Reply-To: <8486C8728176924BAF5BDB2F7D7EEDDF4907E6F7@ucolhp9l.easf.csd.disa.mil> Date: Thu, 17 Jan 2013 14:24:32 +0000 Message-Id: <8D255425-56DA-4771-9A8F-38E6FBDF9884@phonefromhere.com> References: <8486C8728176924BAF5BDB2F7D7EEDDF4907E6F7@ucolhp9l.easf.csd.disa.mil> To: "Roy, Radhika R CIV USARMY (US)" X-Mailer: Apple Mail (2.1283) Cc: Burger Eric , "rtcweb@ietf.org" Subject: Re: [rtcweb] Consensus vs. Voting (was Re: Call for Consensus Regarding Selecting Recommended Audio Codecs) (UNCLASSIFIED) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 17 Jan 2013 14:24:35 -0000 --Apple-Mail=_C9153602-426F-4A16-80CF-F35ABB1C7219 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 17 Jan 2013, at 14:11, Roy, Radhika R CIV USARMY (US) wrote: > On the other hand, we can mandate two audio codecs: one for wired = network > and another for mobile wireless network. >=20 > In this way, transcoding may occur only once for the calls that go = between > the wired and the wireless (mobile) network. You seem to be assuming there are 2 separate networks with separate use = cases. If I use my android device over wifi to a base station that is connected = over DSL to talk to my office, am I a wireless user or a wired one? What if I = continue the session=20 as I walk out of the house and the device switches to 3g ? Tim. --Apple-Mail=_C9153602-426F-4A16-80CF-F35ABB1C7219 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On the other = hand, we can mandate two audio codecs: one for wired network
and = another for mobile wireless network.

In this way, transcoding may = occur only once for the calls that go between
the wired and the = wireless (mobile) network.

You = seem to be assuming there are 2 separate networks with separate use = cases.

If I use my android device over wifi to a base = station that is connected over DSL
to talk to my office, = am I a wireless user or a wired one? What if I continue the = session 
as I walk out of the house and the device = switches to 3g = ?

Tim.

= --Apple-Mail=_C9153602-426F-4A16-80CF-F35ABB1C7219-- From tim@phonefromhere.com Thu Jan 17 06:27:46 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 147B821F8479 for ; Thu, 17 Jan 2013 06:27:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.267 X-Spam-Level: X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[AWL=0.331, 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 mNUnQ1-EG8g5 for ; Thu, 17 Jan 2013 06:27:45 -0800 (PST) Received: from smtp004.apm-internet.net (smtp004.apm-internet.net [85.119.248.54]) by ietfa.amsl.com (Postfix) with ESMTP id 3E69A21F8477 for ; Thu, 17 Jan 2013 06:27:45 -0800 (PST) Received: (qmail 67955 invoked from network); 17 Jan 2013 14:27:44 -0000 X-AV-Scan: clean Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp004.apm-internet.net with SMTP; 17 Jan 2013 14:27:44 -0000 Received: from [192.67.4.33] (unknown [192.67.4.33]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id 222A618A0ADB; Thu, 17 Jan 2013 14:27:44 +0000 (GMT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_BD45E2DA-ACDE-4208-9E7F-8DDDFD181EE9" From: Tim Panton In-Reply-To: <7CBFD4609D19C043A4AC4FD8381C6E26023CF832@DEMUEXC014.nsn-intra.net> Date: Thu, 17 Jan 2013 14:27:43 +0000 Message-Id: References: <8486C8728176924BAF5BDB2F7D7EEDDF4907E630@ucolhp9l.easf.csd.disa.mil> <7CBFD4609D19C043A4AC4FD8381C6E26023CF7B3@DEMUEXC014.nsn-intra.net> <50F80846.5030300@nostrum.com> <7CBFD4609D19C043A4AC4FD8381C6E26023CF832@DEMUEXC014.nsn-intra.net> To: "Rauschenbach, Uwe (NSN - DE/Munich)" X-Mailer: Apple Mail (2.1283) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Consensus vs. Voting (was Re: Call for Consensus Regarding Selecting Recommended Audio Codecs) (UNCLASSIFIED) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 17 Jan 2013 14:27:46 -0000 --Apple-Mail=_BD45E2DA-ACDE-4208-9E7F-8DDDFD181EE9 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On 17 Jan 2013, at 14:24, Rauschenbach, Uwe (NSN - DE/Munich) wrote: > > I subsume under "legacy telephone network" both the fixed network > (G.711) and the mobile network (AMR-WB). I guess that more calls are made with GSM.610 than AMR-WB AMR-WB is 'future legacy' ;-) T. --Apple-Mail=_BD45E2DA-ACDE-4208-9E7F-8DDDFD181EE9 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
On 17 Jan 2013, at 14:24, Rauschenbach, Uwe (NSN - DE/Munich) wrote:

I subsume under "legacy telephone network" both the fixed network
(G.711) and the mobile network (AMR-WB).

I guess that more calls are made with GSM.610 than AMR-WB

AMR-WB is 'future legacy' ;-)

T.
--Apple-Mail=_BD45E2DA-ACDE-4208-9E7F-8DDDFD181EE9-- From roman@telurix.com Thu Jan 17 06:31:20 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D320C21F850B for ; Thu, 17 Jan 2013 06:31:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.478 X-Spam-Level: X-Spam-Status: No, score=-0.478 tagged_above=-999 required=5 tests=[AWL=-2.502, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_SUMOF=5, 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 46+KRYoVkYe3 for ; Thu, 17 Jan 2013 06:31:20 -0800 (PST) Received: from mail-we0-x22b.google.com (we-in-x022b.1e100.net [IPv6:2a00:1450:400c:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id D98D321F84ED for ; Thu, 17 Jan 2013 06:31:19 -0800 (PST) Received: by mail-we0-f171.google.com with SMTP id u3so270080wey.2 for ; Thu, 17 Jan 2013 06:31:19 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-received:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=BHsUhib+S6U5N7VMJ40n8uFfcCKfemg+NV3nQihSb1o=; b=gTSJrjC1PcDUqHIQ//U+9uHK0PaCMtiy6TWRyLpJpf3tWd8gfrZb8/9hDGdyCQmS2K XBktiY0n8Q4gpDSreNASZOcbBL1XYThKJjFLwnqI74+cv4r3cM34V0LoZhJTG7Pg/qlg BZyY3WceooZx50FoB1RfY0KHAg6Fa7YFHu7VQF2DCy3Dq/WN18EyHGNKho7xceG8zFvf ePBW+Ak/sHlaxH6uE6l11f3/aBJWEbn3tjQuhsi523tCl2v3PXckLghSOEW7rEDbeLEL YmByBIBbCVsQMaUxJVQwMS8xlCeRZp6EGyInvLrbos5Zn0UdUjDDNQD5mk5e73rkv/sI qS+w== X-Received: by 10.194.58.175 with SMTP id s15mr8791095wjq.31.1358433079006; Thu, 17 Jan 2013 06:31:19 -0800 (PST) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by mx.google.com with ESMTPS id hu8sm13134630wib.6.2013.01.17.06.31.17 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 17 Jan 2013 06:31:18 -0800 (PST) Received: by mail-wi0-f172.google.com with SMTP id o1so4530061wic.17 for ; Thu, 17 Jan 2013 06:31:16 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.194.80.73 with SMTP id p9mr8955154wjx.4.1358433076408; Thu, 17 Jan 2013 06:31:16 -0800 (PST) Received: by 10.216.16.134 with HTTP; Thu, 17 Jan 2013 06:31:16 -0800 (PST) In-Reply-To: <9BA7D840-480D-4883-B170-303305376698@phonefromhere.com> References: <50D2CC6A.4090500@ericsson.com> <6515_1357907583_50F0067F_6515_1738_1_2842AD9A45C83B44B57635FD4831E60A0747CC@PEXCVZYM14.corporate.adroot.infra.ftgroup> <580BEA5E3B99744AB1F5BFF5E9A3C67D16813E56EC@HE111648.emea1.cds.t-internal.com> <50F41D97.1030508@nostrum.com> <50F43ACA.80206@nostrum.com> <50F44AF0.4060304@nostrum.com> <50F4619F.7040208@nostrum.com> <7CBFD4609D19C043A4AC4FD8381C6E2602386636@DEMUEXC014.nsn-intra.net> <50F5A74C.3030203@nostrum.com> <9BA7D840-480D-4883-B170-303305376698@phonefromhere.com> Date: Thu, 17 Jan 2013 09:31:16 -0500 Message-ID: From: Roman Shpount To: Tim Panton Content-Type: multipart/alternative; boundary=047d7bb04daef8704404d37cd83b X-Gm-Message-State: ALoCoQmhz5t3YaY1rBWKgqQ/n3AV44VObSg7f3LA+yoYHQs8FR7LLrm4/YRzmTKP7wUOGieYlr73 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Consensus vs. Voting (was Re: Call for Consensus Regarding Selecting Recommended 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, 17 Jan 2013 14:31:20 -0000 --047d7bb04daef8704404d37cd83b Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jan 17, 2013 at 9:16 AM, Tim Panton wrote: > > Wait, you run the risk of double counting (at least to some extent). The > overall jitter from Alice to Bob isn't changed by transcoding. > I think you are implying that because we transcode in the middle, there > will be 2 jitterbuffers and the sum of the depth of these jitterbuffers will > exceed the depth of the single jitterbuffer that would be needed if there > was no transcoding. I agree, but I dispute that the sum of these 2 > jitterbuffers would be more than 20ms greater than the individual > jitterbuffer that Bob would run anyway. > > If you look at the typical deployment scenario for 722 - Bob is either a > conference mixer engine or using a desktop phone on a wire to a reliable > low loss company network. Most of the packet jitter (and loss) occurs in > the first couple of hops from Alice's browser through the wifi and the > cafe's DSL, > so the jitterbuffer in the middle is probably the right place to put it. > Well not exactly double counting. If jitter on both calls legs are independently normally distributed and if we have jitter of X from webrtc client to transcoder, and jitter Y from transcoder to the end client, then in case of jitter buffer in the middle the total delay is X+Y, in case of end-to-end transmission it is sqrt(X^2 + Y^2). So in case of two 100 ms jitters the difference is 200 ms of overall delay vs 141 ms of overall delay. Regarding the deployment scenarios, you are correct in some cases where transcoder is sitting on the edge of well configured VoIP network. In such cases your penalty is essentially equal to jitter within the VoIP network. Unfortunately, there is still a use case when both end points are on consumer IP connections, for instance, when you add webrtc client to a hosted PBX service. Your legacy phones are located at homes or small offices and your WebRTC clients are on similar connections. You would see significant jitter on both. _____________ Roman Shpount --047d7bb04daef8704404d37cd83b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Jan 17, 2013 at 9:16 AM, Tim Panton = <tim@phonefromhere.com> wrote:

Wait, you run the risk of doubl= e counting (at least to some extent). The overall jitter from Alice to Bob = isn't changed by transcoding.=A0
I think you are implying tha= t because we transcode in the middle, there will be 2 jitterbuffers and the= sum of the depth of these jitterbuffers will
exceed the depth of the single jitterbuffer that would be needed if th= ere was no transcoding. I agree, but I dispute that the sum of these 2 jitt= erbuffers would be=A0more than 20ms greater than the individual jitterbuffe= r that Bob would run anyway.=A0

If you look at the typical deployment scenario for 722 = - Bob is either a conference mixer engine or using a desktop phone on a wir= e to a reliable low loss company network. Most of the packet jitter (and lo= ss) occurs in the first couple of hops from Alice's browser through the= wifi and the cafe's DSL,=A0
so the jitterbuffer in the middle is probably the right place to put i= t.


Well not exactly double counting. If jit= ter on both calls legs are independently normally distributed and if we hav= e jitter of X from webrtc client to transcoder, and jitter Y from transcode= r to the end client, then in case of jitter buffer in the middle the total = delay is X+Y, in case of end-to-end transmission it is sqrt(X^2 + Y^2). So = in case of two 100 ms jitters the difference is 200 ms of overall delay vs = 141 ms of overall delay.

Regarding the deployment scenarios, you are correct in some cases where= transcoder is sitting on the edge of well configured VoIP network. In such= cases your penalty is essentially equal to jitter within the VoIP network.= Unfortunately, there is still a use case when both end points are on consu= mer IP connections, for instance, when you add webrtc client to a hosted PB= X service. Your legacy phones are located at homes or small offices and you= r WebRTC clients are on similar connections. You would see significant jitt= er on both.
_____________
Roman Shpount
--047d7bb04daef8704404d37cd83b-- From radhika.r.roy.civ@mail.mil Thu Jan 17 06:32:20 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3362721F8558 for ; Thu, 17 Jan 2013 06:32:20 -0800 (PST) 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 0pbC61jqlkQG for ; Thu, 17 Jan 2013 06:32:19 -0800 (PST) Received: from edge-cols.mail.mil (edge-cols.mail.mil [131.64.100.11]) by ietfa.amsl.com (Postfix) with ESMTP id 7CE7721F8545 for ; Thu, 17 Jan 2013 06:32:19 -0800 (PST) Received: from UCOLHP3O.easf.csd.disa.mil (131.64.100.154) by ucolhp3l.easf.csd.disa.mil (131.64.100.11) with Microsoft SMTP Server (TLS) id 14.2.309.2; Thu, 17 Jan 2013 14:33:53 +0000 Received: from UCOLHP9L.easf.csd.disa.mil ([169.254.2.136]) by UCOLHP3O.easf.csd.disa.mil ([131.64.100.154]) with mapi id 14.02.0309.003; Thu, 17 Jan 2013 14:33:52 +0000 From: "Roy, Radhika R CIV USARMY (US)" To: Tim Panton Thread-Topic: [rtcweb] Consensus vs. Voting (was Re: Call for Consensus Regarding Selecting Recommended Audio Codecs) (UNCLASSIFIED) Thread-Index: AQHN9LdFwwF57GbTP0W99XrAuOQrqZhNh17wgAAL7wCAAADYsA== Date: Thu, 17 Jan 2013 14:33:51 +0000 Message-ID: <8486C8728176924BAF5BDB2F7D7EEDDF4907E74F@ucolhp9l.easf.csd.disa.mil> References: <8486C8728176924BAF5BDB2F7D7EEDDF4907E6F7@ucolhp9l.easf.csd.disa.mil> <8D255425-56DA-4771-9A8F-38E6FBDF9884@phonefromhere.com> In-Reply-To: <8D255425-56DA-4771-9A8F-38E6FBDF9884@phonefromhere.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [131.64.62.4] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0016_01CDF495.891D5DC0" MIME-Version: 1.0 Cc: Burger Eric , "rtcweb@ietf.org" Subject: Re: [rtcweb] Consensus vs. Voting (was Re: Call for Consensus Regarding Selecting Recommended Audio Codecs) (UNCLASSIFIED) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 17 Jan 2013 14:32:20 -0000 ------=_NextPart_000_0016_01CDF495.891D5DC0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Classification: UNCLASSIFIED Caveats: NONE It does not matter whether you are in wired or wireless network. Devices will have at least two codecs and people can choose anyone without being afraid of quality and the calls will not fail. RRR -----Original Message----- From: Tim Panton [mailto:tim@phonefromhere.com] Sent: Thursday, January 17, 2013 9:25 AM To: Roy, Radhika R CIV USARMY (US) Cc: Burger Eric; rtcweb@ietf.org Subject: Re: [rtcweb] Consensus vs. Voting (was Re: Call for Consensus Regarding Selecting Recommended Audio Codecs) (UNCLASSIFIED) On 17 Jan 2013, at 14:11, Roy, Radhika R CIV USARMY (US) wrote: On the other hand, we can mandate two audio codecs: one for wired network and another for mobile wireless network. In this way, transcoding may occur only once for the calls that go between the wired and the wireless (mobile) network. You seem to be assuming there are 2 separate networks with separate use cases. If I use my android device over wifi to a base station that is connected over DSL to talk to my office, am I a wireless user or a wired one? What if I continue the session as I walk out of the house and the device switches to 3g ? Tim. Classification: UNCLASSIFIED Caveats: NONE ------=_NextPart_000_0016_01CDF495.891D5DC0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISizCCA3Aw ggJYoAMCAQICAQUwDQYJKoZIhvcNAQEFBQAwWzELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4g R292ZXJubWVudDEMMAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxFjAUBgNVBAMTDURvRCBSb290 IENBIDIwHhcNMDQxMjEzMTUwMDEwWhcNMjkxMjA1MTUwMDEwWjBbMQswCQYDVQQGEwJVUzEYMBYG A1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEWMBQGA1UE AxMNRG9EIFJvb3QgQ0EgMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMAswfaNO6z/ PzzWcb64dCIH7HBBFfyrQOMHqsHD2J/+2kw6vz/I2Ch7SzYBwKxFJcPSDgqPhRhkED0aE3Aqb47X 3I2Ts0EPOCHNravCPSoF01cRNw3NjFH5k+PMRkkhjhS0zcsUPjjNcjHuqxLyZeo0LlZd/+5jdctt upE0/J7z9C0cvlDEQt9ZiP9qs/qobD3LVnFxBZa7n4DlgEVZZ0Gw68OtYKSAdQYXnA70Q+CZDhv7 f/WzzLKBgrH9MsG4vkGkZLVgOlpRMIzO3kEsGUdcSRBkuXSph0GvfW66wbihv2UxOgRn+bW7jpKK AGO4seaMOF+D/1DVO6Jda7IQzGMCAwEAAaM/MD0wHQYDVR0OBBYEFEl0uwxeunr+AlTve6DGlcYJ gHCWMAsGA1UdDwQEAwIBhjAPBgNVHRMBAf8EBTADAQH/MA0GCSqGSIb3DQEBBQUAA4IBAQCYkY0/ ici79cBpcyk7Nay6swh2PXAJkumERCEBfRR2G+5RbB2NFTctezFp9JpEuK9GzDT6I8sDJxnSgyF1 K+fgG5km3IRAleio0sz2WFxm7z9KlxCCHboKot1bBiudp2RO6y4BNaS0PxOtVeTVc6hpmxHxmPIx Hm9A1Ph4n46RoG9wBJBmqgYrzuF6krV94eDRluehOi3MsZ0fBUTth5nTTRpwOcEEDOV+2fGv1yAO 8SJ6JaRzmcw/pAcnlqiile2CuRbTnguHwsHyiPVi32jfx7xpUe2xXNxUVCkPCTmarAPB2wxNrm8K ehZJ8b+R0jiU0/aVLLdsyUK2jcqQjYXZMIIEtzCCA5+gAwIBAgIDHzzKMA0GCSqGSIb3DQEBBQUA MF0xCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEM MAoGA1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwgQ0EtMjkwHhcNMTIwOTIwMDAwMDAwWhcN MTUwOTE5MjM1OTU5WjB5MQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQww CgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEMMAoGA1UECxMDVVNBMSYwJAYDVQQDEx1ST1kuUkFE SElLQS5SQU5KQU4uMTI5MTkzOTgwMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKw9 ymde30NtacDt8neYCBWDyA+Hlsk3dNwV23IVgH7vSWJx4zCFT5ojDHACm3lthvOOtJ0CzkjwQy8V hEHvL0eK03hZy0hJrZxQSYcao7Y0Yv9yDAFvxa6LJ1fUImUj9edMf1l08LZkjh3ybs20Bk+MLySR 9F/flRzjtCwVUeqq8NS3to4nPXSIgViP6H0YJrBjf9IDZQGgcO8LxLbNENOWrXILeCCCngnHBgHV lJWak9YndpMOs+CeLXk5oUV8xUAM/UjyS+/gFCjABBRt30VJVN6pqARmIht850iK8TDeqlWwF3O9 eQBBwKQPJ7nVl0kmGItYGoYb+4t2Mkwalh8CAwEAAaOCAWIwggFeMB8GA1UdIwQYMBaAFLhDg2Qh eu5wgd6l3gxgKId4rl54MDoGA1UdHwQzMDEwL6AtoCuGKWh0dHA6Ly9jcmwuZGlzYS5taWwvY3Js L0RPREVNQUlMQ0FfMjkuY3JsMA4GA1UdDwEB/wQEAwIFIDAjBgNVHSAEHDAaMAsGCWCGSAFlAgEL CTALBglghkgBZQIBCxMwHQYDVR0OBBYEFGRWf703swy+9hvoDujsb+ZPwC9MMGgGCCsGAQUFBwEB BFwwWjA2BggrBgEFBQcwAoYqaHR0cDovL2NybC5kaXNhLm1pbC9zaWduL0RPREVNQUlMQ0FfMjku Y2VyMCAGCCsGAQUFBzABhhRodHRwOi8vb2NzcC5kaXNhLm1pbDAkBgNVHREEHTAbgRlyYWRoaWth LnIucm95QHVzLmFybXkubWlsMBsGA1UdCQQUMBIwEAYIKwYBBQUHCQQxBBMCVVMwDQYJKoZIhvcN AQEFBQADggEBAE9PU63Rc/bneYoxI6sAZi+oXBiwneOiI03+J3pSZWIbwrOnj7qGoH5ZoeO+dZ8E wvKszd+vacYnO8SqEXsvIKvBGPchKg1oV5b24+tCSeiCXtcX5EDtpJQGS4W9G+7r7f+mdEHU0NuF NI7HNHRY/q4C+FGhchPoKPcKeyWxJMwp+9NJQsx1AoC5isvydZHHlNkV917dLMuMEqyCCAAbJAOp 8SDQTiiIVa1I7NlMSlkzNRUtFoO9nsEttMH699V9JH5jcwWPlWdyb5B6yRzoM/iFsI/hA9pHHukh iWVul3FX/6Ez8Jt/A1j/CFsl3S2y2TBRCdqIQEP+/H6j4RFxa9MwggUCMIID6qADAgECAgMfPMkw DQYJKoZIhvcNAQEFBQAwXTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEM MAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxGDAWBgNVBAMTD0RPRCBFTUFJTCBDQS0yOTAeFw0x MjA5MjAwMDAwMDBaFw0xNTA5MTkyMzU5NTlaMHkxCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMu IEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJMQwwCgYDVQQLEwNVU0ExJjAk BgNVBAMTHVJPWS5SQURISUtBLlJBTkpBTi4xMjkxOTM5ODAxMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEAyr7Ttduf1mHx22erLvkwPOZL02imdiimrmXITVrdUHsynK383NY6a4ye07Jm b0spr8hzmfM6JSCEgtbZevWfJg4NmNDjEEe53+7EvEMRHfh46GGxOckj98QmQwngbQaAIcKI1gJd Do2vB3mOtFp5hNKqsxibZAvpPb3OsR762vrx2QYQX+p8+psLwe95CSt56IfC39GZD+Otus3Sq1Ma 9e0NdRhqg5ch8FYpL2ONbmEw9+DTqk24Zh2lQuOvpo4FhpvXnNghCS4CfuiE6YgvKdombc1BGT5u rkDFep5IH7Rk7EnK4CVVzNq3gxT0B+hDoJT0AuQfrkxI9223mUJoywIDAQABo4IBrTCCAakwHwYD VR0jBBgwFoAUuEODZCF67nCB3qXeDGAoh3iuXngwOgYDVR0fBDMwMTAvoC2gK4YpaHR0cDovL2Ny bC5kaXNhLm1pbC9jcmwvRE9ERU1BSUxDQV8yOS5jcmwwDgYDVR0PAQH/BAQDAgbAMCMGA1UdIAQc MBowCwYJYIZIAWUCAQsJMAsGCWCGSAFlAgELEzAdBgNVHQ4EFgQUrV8KnskfJHURS19In/mX0d2y 9pgwaAYIKwYBBQUHAQEEXDBaMDYGCCsGAQUFBzAChipodHRwOi8vY3JsLmRpc2EubWlsL3NpZ24v RE9ERU1BSUxDQV8yOS5jZXIwIAYIKwYBBQUHMAGGFGh0dHA6Ly9vY3NwLmRpc2EubWlsMEQGA1Ud EQQ9MDuBGXJhZGhpa2Euci5yb3lAdXMuYXJteS5taWygHgYKKwYBBAGCNxQCA6AQDA4xMjkxOTM5 ODAxQG1pbDAbBgNVHQkEFDASMBAGCCsGAQUFBwkEMQQTAlVTMCkGA1UdJQQiMCAGCisGAQQBgjcU AgIGCCsGAQUFBwMCBggrBgEFBQcDBDANBgkqhkiG9w0BAQUFAAOCAQEAggVw28drobHRF6Zr7wQZ G/ShO0BE6jEddlmlqj9ln2mC5HoTTXkl2ZOqjUoh2Wq2d55KvbZk9b73bIzWK+RnnoU+zOHagyB/ VnEbSpdofTm50zJYISK7Ws92KCt8viNetFkS2CTNSc302cqmwejpTwKAxkLDM0wU7ECNopN87F0O vPU2AJnITH32PrAvTVOeCxsDdEnzzXYxvKtNE5K6zBVVumSOGLMfnyFAq+4dlhg7i25B8Goh+fIF eRGiwxsXOyEMPalWHt5wWDDmUlIK0Qmg95mZ7f6UJCmj15zzSxgliR+JyVlFGH6/HYzIAU4lv8b5 uU5qyxANtVCvuGDruDCCBVIwggQ6oAMCAQICAgG4MA0GCSqGSIb3DQEBBQUAMFsxCzAJBgNVBAYT AlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJ MRYwFAYDVQQDEw1Eb0QgUm9vdCBDQSAyMB4XDTExMDkwODE2MDIxNFoXDTE3MDkwODE2MDIxNFow XTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEMMAoGA1UECxMDRG9EMQww CgYDVQQLEwNQS0kxGDAWBgNVBAMTD0RPRCBFTUFJTCBDQS0yOTCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAJJiL0HCIAAWBlVkn72niBVugptIwYV3vQKrDNnxK2CBAbo+dXCOEqanOISQ s+lAgBLcaspRza0thhDMRLwOxVg4GbIUMiVBVFhcQw7IbHMPwwwYGBYEmlI9gaJxzjwyAJ9xVbr4 zjZ3HiG3KJTnPT6m9sB6MWCRKJd3IlDyxpNushvFQcb5oTf7EL/aVqb7Uk1fv+/Elnco5TL/6OEY zENSGKyNd5pyTOidA16wou/k3dLn5qemUq3hmAiWSkPMcz1Loo2J79yCTLhKgCRlKx6RgvUE9nIf VxhAF/A5UbaP84k7Z/dYTkq82vkOwcAMvfMIcfiDD8kugJX0hQ7OrqkCAwEAAaOCAhwwggIYMA4G A1UdDwEB/wQEAwIBhjAfBgNVHSMEGDAWgBRJdLsMXrp6/gJU73ugxpXGCYBwljAdBgNVHQ4EFgQU uEODZCF67nCB3qXeDGAoh3iuXngwEgYDVR0TAQH/BAgwBgEB/wIBADAMBgNVHSQEBTADgAEAMGYG A1UdIARfMF0wCwYJYIZIAWUCAQsFMAsGCWCGSAFlAgELCTALBglghkgBZQIBCxEwCwYJYIZIAWUC AQsSMAsGCWCGSAFlAgELEzAMBgpghkgBZQMCAQMaMAwGCmCGSAFlAwIBAxswNwYDVR0fBDAwLjAs oCqgKIYmaHR0cDovL2NybC5kaXNhLm1pbC9jcmwvRE9EUk9PVENBMi5jcmwwggEBBggrBgEFBQcB AQSB9DCB8TA6BggrBgEFBQcwAoYuaHR0cDovL2NybC5kaXNhLm1pbC9pc3N1ZWR0by9ET0RST09U Q0EyX0lULnA3YzAgBggrBgEFBQcwAYYUaHR0cDovL29jc3AuZGlzYS5taWwwgZAGCCsGAQUFBzAC hoGDbGRhcDovL2NybC5nZHMuZGlzYS5taWwvY24lM2REb0QlMjBSb290JTIwQ0ElMjAyJTJjb3Ul M2RQS0klMmNvdSUzZERvRCUyY28lM2RVLlMuJTIwR292ZXJubWVudCUyY2MlM2RVUz9jcm9zc0Nl cnRpZmljYXRlUGFpcjtiaW5hcnkwDQYJKoZIhvcNAQEFBQADggEBACxrLHk12/AeHId7q+HoaWo3 i9t6T1VgaZUvU53GykO21DeR1gNdflqxuB33noHTrlBUMKRvSy67FBsXqlwQ05R6MTmWpFR59elW LlXDGxbqqgLIz1H3MoEixjQ6qc2aqkiTx+n7HjJ+ccR28EVUEh1V6r1cMoc6rpOabpkiX6hRNe6y U2Bf9k9FuBaEHWVVzRXKEAEfqdKcp1eRo9fnsIY9LfSJOtjJd3BQxmzv8uuY+BCqPdrIXCmtzrhz SUyhkrvm7c26ghpjIRll9AYZv4Oqc+XTG7GY/0Xf+0nMc+ji5weWADHpf9kkCOfKRHpIBsNC2D/5 eYelN5IWqYQgkmMxggMyMIIDLgIBATBkMF0xCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdv dmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwg Q0EtMjkCAx88yTAJBgUrDgMCGgUAoIIBozAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xMzAxMTcxNDMyMTVaMCMGCSqGSIb3DQEJBDEWBBT09PYnF07/cj7tvlo/kqjT eqtF4jBYBgkqhkiG9w0BCQ8xSzBJMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMC BzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG9w0CBTBzBgkrBgEEAYI3EAQxZjBkMF0x CzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoG A1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwgQ0EtMjkCAx88yjB1BgsqhkiG9w0BCRACCzFm oGQwXTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEMMAoGA1UECxMDRG9E MQwwCgYDVQQLEwNQS0kxGDAWBgNVBAMTD0RPRCBFTUFJTCBDQS0yOQIDHzzKMA0GCSqGSIb3DQEB AQUABIIBAH8E9vvoV37UakJHV6Q/ZUakT53ybiQ4lNLIXgT4zcu8UJdSXsUV7bF9Z8AE/fRSR+6B qJr+9SAISUFeuc9mV3P12rDcBrqQSGLc3vQVoBm3rvoxgRVIMTWAGeGevvBv4loW7X6WEbsb1u4f z5seVpVJuDhK+zJH2ULOvtC6kKtKVTd5LzDQGHtfwwFK8gVSSuU2yJb7PV7+j/FCHqdGdv0/9Eg1 DkQ4QI3lAGI96My4KaLd58/4vi38A2XZH12FquFaHkuA3FwKbAx832R0cwnsQ/ulcu39Mfi5qfky b07zE299K6QvKrNyaVaRI5lLODr3pf+35VQjUCjDyk0A8v0AAAAAAAA= ------=_NextPart_000_0016_01CDF495.891D5DC0-- From prvs=97290e39eb=aallen@rim.com Thu Jan 17 06:37:50 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9FD421F84C6 for ; Thu, 17 Jan 2013 06:37:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.73 X-Spam-Level: X-Spam-Status: No, score=-5.73 tagged_above=-999 required=5 tests=[AWL=0.868, 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 7flZgm30R0Oy for ; Thu, 17 Jan 2013 06:37:50 -0800 (PST) Received: from mhs060cnc.rim.net (mhs060cnc.rim.net [208.65.73.34]) by ietfa.amsl.com (Postfix) with ESMTP id BF4C521F8464 for ; Thu, 17 Jan 2013 06:37:49 -0800 (PST) X-AuditID: 0a41282f-b7f8c6d000004b29-74-50f80cb4ee77 Received: from XCT102ADS.rim.net (xct102ads.rim.net [10.67.111.43]) by mhs060cnc.rim.net (SBG) with SMTP id D9.5F.19241.4BC08F05; Thu, 17 Jan 2013 08:37:40 -0600 (CST) Received: from XMB104ADS.rim.net ([fe80::2494:a63d:e3:723b]) by XCT102ADS.rim.net ([fe80::4806:2e1d:2b7c:cfdf%22]) with mapi id 14.02.0318.001; Thu, 17 Jan 2013 08:37:39 -0600 From: Andrew Allen To: "tim@phonefromhere.com" , "uwe.rauschenbach@nsn.com" Thread-Topic: [rtcweb] Consensus vs. Voting (was Re: Call for Consensus Regarding Selecting Recommended Audio Codecs) (UNCLASSIFIED) Thread-Index: AQHN9MAy+U9bDHic2UuJtamxdN7zcQ== Date: Thu, 17 Jan 2013 14:37:38 +0000 Message-ID: In-Reply-To: Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.67.110.253] Content-Type: multipart/alternative; boundary="_000_BBF5DDFE515C3946BC18D733B20DAD2338CF2BE8XMB104ADSrimnet_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrKKsWRmVeSWpSXmKPExsXC5ZyvrbuF50eAwddzqhZr/7WzW1zcfovR 4u7hOcwOzB5Llvxk8vi5/iq7x5JJjWwBzFENjDZJiSVlwZnpefp2Nol5efkliSWpCimpxcm2 Sj6p6Yk5CgFFmWWJyZUKLpnFyTmJmbmpRUoKmSm2SiZKCgU5icmpual5JbZKiQUFqXkpSnZc ChjABqgsM08hNS85PyUzL91WyTPYX9fCwtRS11DJTjehkydjy8vZ7AVzNCquz+9jbWBsUe9i 5OSQEDCROH/mIwuELSZx4d56ti5GLg4hgZWMEks//IJyNjNKNDyZzApSxSagLLH89wxGEFtE IEei490vsG5mAXWJO4vPsYM0CAu0Mkp0TJgB1i0i0MYocefLMmaIDj2Jf58vg3WwCKhKtHyf BhTn4OAV8JCYedACJMwp4Cqx4XcfE4jNKCArsfvsdSaIBeISt57MZ4I4VUBiyZ7zzBC2qMTL x/9YIWxFib97v7NC1OdLHFs9A8zmFRCUODnzCcsERpFZSEbNQlI2C0nZLKCLmAU0Jdbv0oco UZSY0v2QHcLWkGidM5cdWXwBI/sqRsHcjGIDM4PkvGS9osxcvbzUkk2MoKTiqKG/g/Hte4tD jAIcjEo8vE8ZfwQIsSaWFVfmHmKU4GBWEuF9xQIU4k1JrKxKLcqPLyrNSS0+xBgEDJ+JzFLc yfnAhJdXEm9sYEAkR0mcV7L3coCQQDowkWWnphakFsEMZeLgBFnKJSVSDExHqUWJpSUZ8aCk GV8MTJtSDYzKnu94mS+HlXgu6SufYCISv+js40xvoc+t8zprVi27ztr7Yu8ky7jtv0tz03iX lEjx/Nu9OtTFIbJR6ME5s0qZS4UqaZoS89gPr0l7HlN3dmXmv/6jripP698vEU7j/X78ySrP //wzGnqeel345JvyNVlR3p3fVll365HcO5+XTHK0jSq82qfEUpyRaKjFXFScCADlLedXeAMA AA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Consensus vs. Voting (was Re: Call for Consensus Regarding Selecting Recommended Audio Codecs) (UNCLASSIFIED) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 17 Jan 2013 14:37:51 -0000 --_000_BBF5DDFE515C3946BC18D733B20DAD2338CF2BE8XMB104ADSrimnet_ Content-Type: text/plain; charset="utf-8" content-transfer-encoding: base64 DQpTaW5jZSAzR1BQIGlzIGFscmVhZHkgd29ya2luZyBvbiBhIGZ1dHVyZSBjb2RlYyBmb3Ig TFRFIEFNUi1XQiBtYXkgYmUgYSBxdWl0ZSBuZWFyIGZ1dHVyZSBsZWdhY3kuDQoNClRoYXQn cyBwYXJ0IG9mIG15IHJlYXNvbmluZyAtIHRoaW5ncyBtb3ZlIHF1aXRlIGZhc3Qgd2l0aCBD b2RlYyBkZXZlbG9wbWVudCBhbmQgd2hhdGV2ZXIgd2UgdGhpbmsgYXJlIHRoZSBpbXBvcnRh bnQgY29kZWNzIHdpbGwgbGlrZWx5IGJlIG91dGRhdGVkIHZlcnkgc29vbi4NCg0KUlRDd2Vi IHNob3VsZCBqdXN0IGVuc3VyZSB0aGF0IGl0IGhhcyBnb29kIGludGVvcGVyYWJpbGl0eSBi ZXR3ZWVuIFJUQ3dlYiBlbmRwb2ludHMgKGFjaGlldmVkIHdpdGggT1BVUykgYW5kIHRoZSBh YmlsaXR5IHRocm91Z2ggZ2F0ZXdheXMgdG8gYWNoaWV2ZSBiYXNpYyBpbnRlcm9wZXJhYmls aXR5IHdpdGggZXZlcnl0aGluZyBlbHNlIChhY2hpZXZlZCB3aXRoIEcuNzExKS4gSm9iIGRv bmUhDQoNCkV2ZXJ5dGhpbmcgZWxzZSBJTUhPIGlzIGEgcmF0IGhvbGUgb2YgbXkgY29kZWMg aXMgYmV0dGVyIHRoYW4geW91cnMgb3IgdGhpcyBpcyB3aGF0IHlvdSBuZWVkIHRvIHN1cHBv cnQgd2hlcmUgLSBhIHNpdHVhdGlvbiB3aGljaCBpcyB2ZXJ5IGZhciBmcm9tIHN0YXRpYy4N Cg0KQW5kcmV3DQoNCg0KDQpGcm9tOiBUaW0gUGFudG9uIFttYWlsdG86dGltQHBob25lZnJv bWhlcmUuY29tXQ0KU2VudDogVGh1cnNkYXksIEphbnVhcnkgMTcsIDIwMTMgMDg6MjcgQU0g Q2VudHJhbCBTdGFuZGFyZCBUaW1lDQpUbzogUmF1c2NoZW5iYWNoLCBVd2UgKE5TTiAtIERF L011bmljaCkgPHV3ZS5yYXVzY2hlbmJhY2hAbnNuLmNvbT4NCkNjOiBydGN3ZWJAaWV0Zi5v cmcgPHJ0Y3dlYkBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbcnRjd2ViXSBDb25zZW5zdXMg dnMuIFZvdGluZyAod2FzIFJlOiBDYWxsIGZvciBDb25zZW5zdXMgUmVnYXJkaW5nIFNlbGVj dGluZyBSZWNvbW1lbmRlZCBBdWRpbyBDb2RlY3MpIChVTkNMQVNTSUZJRUQpDQoNCg0KT24g MTcgSmFuIDIwMTMsIGF0IDE0OjI0LCBSYXVzY2hlbmJhY2gsIFV3ZSAoTlNOIC0gREUvTXVu aWNoKSB3cm90ZToNCg0KSSBzdWJzdW1lIHVuZGVyICJsZWdhY3kgdGVsZXBob25lIG5ldHdv cmsiIGJvdGggdGhlIGZpeGVkIG5ldHdvcmsNCihHLjcxMSkgYW5kIHRoZSBtb2JpbGUgbmV0 d29yayAoQU1SLVdCKS4NCg0KSSBndWVzcyB0aGF0IG1vcmUgY2FsbHMgYXJlIG1hZGUgd2l0 aCBHU00uNjEwIHRoYW4gQU1SLVdCDQoNCkFNUi1XQiBpcyAnZnV0dXJlIGxlZ2FjeScgOy0p DQoNClQuDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KVGhpcyB0cmFuc21pc3Npb24gKGluY2x1ZGlu ZyBhbnkgYXR0YWNobWVudHMpIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBpbmZvcm1hdGlv biwgcHJpdmlsZWdlZCBtYXRlcmlhbCAoaW5jbHVkaW5nIG1hdGVyaWFsIHByb3RlY3RlZCBi eSB0aGUgc29saWNpdG9yLWNsaWVudCBvciBvdGhlciBhcHBsaWNhYmxlIHByaXZpbGVnZXMp LCBvciBjb25zdGl0dXRlIG5vbi1wdWJsaWMgaW5mb3JtYXRpb24uIEFueSB1c2Ugb2YgdGhp cyBpbmZvcm1hdGlvbiBieSBhbnlvbmUgb3RoZXIgdGhhbiB0aGUgaW50ZW5kZWQgcmVjaXBp ZW50IGlzIHByb2hpYml0ZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgdHJhbnNtaXNz aW9uIGluIGVycm9yLCBwbGVhc2UgaW1tZWRpYXRlbHkgcmVwbHkgdG8gdGhlIHNlbmRlciBh bmQgZGVsZXRlIHRoaXMgaW5mb3JtYXRpb24gZnJvbSB5b3VyIHN5c3RlbS4gVXNlLCBkaXNz ZW1pbmF0aW9uLCBkaXN0cmlidXRpb24sIG9yIHJlcHJvZHVjdGlvbiBvZiB0aGlzIHRyYW5z bWlzc2lvbiBieSB1bmludGVuZGVkIHJlY2lwaWVudHMgaXMgbm90IGF1dGhvcml6ZWQgYW5k IG1heSBiZSB1bmxhd2Z1bC4NCg== --_000_BBF5DDFE515C3946BC18D733B20DAD2338CF2BE8XMB104ADSrimnet_ Content-Type: text/html; charset="utf-8" content-transfer-encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3 b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtp dC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgIj4NCjxmb250IHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48YnI+DQpTaW5jZSAzR1BQIGlzIGFscmVh ZHkgd29ya2luZyBvbiBhIGZ1dHVyZSBjb2RlYyBmb3IgTFRFIEFNUi1XQiBtYXkgYmUgYSBx dWl0ZSBuZWFyIGZ1dHVyZSBsZWdhY3kuPGJyPg0KPGJyPg0KVGhhdCdzIHBhcnQgb2YgbXkg cmVhc29uaW5nIC0gdGhpbmdzIG1vdmUgcXVpdGUgZmFzdCB3aXRoIENvZGVjIGRldmVsb3Bt ZW50IGFuZCB3aGF0ZXZlciB3ZSB0aGluayBhcmUgdGhlIGltcG9ydGFudCBjb2RlY3Mgd2ls bCBsaWtlbHkgYmUgb3V0ZGF0ZWQgdmVyeSBzb29uLg0KPGJyPg0KPGJyPg0KUlRDd2ViIHNo b3VsZCBqdXN0IGVuc3VyZSB0aGF0IGl0IGhhcyBnb29kIGludGVvcGVyYWJpbGl0eSBiZXR3 ZWVuIFJUQ3dlYiBlbmRwb2ludHMgKGFjaGlldmVkIHdpdGggT1BVUykgYW5kIHRoZSBhYmls aXR5IHRocm91Z2ggZ2F0ZXdheXMgdG8gYWNoaWV2ZSBiYXNpYyBpbnRlcm9wZXJhYmlsaXR5 IHdpdGggZXZlcnl0aGluZyBlbHNlIChhY2hpZXZlZCB3aXRoIEcuNzExKS4gSm9iIGRvbmUh PGJyPg0KPGJyPg0KRXZlcnl0aGluZyBlbHNlIElNSE8gaXMgYSByYXQgaG9sZSBvZiBteSBj b2RlYyBpcyBiZXR0ZXIgdGhhbiB5b3VycyBvciB0aGlzIGlzIHdoYXQgeW91IG5lZWQgdG8g c3VwcG9ydCB3aGVyZSAtIGEgc2l0dWF0aW9uIHdoaWNoIGlzIHZlcnkgZmFyIGZyb20gc3Rh dGljLjxicj4NCjxicj4NCkFuZHJldzxicj4NCjxicj4NCjwvZm9udD48YnI+DQombmJzcDs8 YnI+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYg MS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8Zm9udCBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+PGI+RnJvbTwvYj46IFRpbSBQYW50b24gW21haWx0bzp0aW1AcGhvbmVm cm9taGVyZS5jb21dDQo8YnI+DQo8Yj5TZW50PC9iPjogVGh1cnNkYXksIEphbnVhcnkgMTcs IDIwMTMgMDg6MjcgQU0gQ2VudHJhbCBTdGFuZGFyZCBUaW1lPGJyPg0KPGI+VG88L2I+OiBS YXVzY2hlbmJhY2gsIFV3ZSAoTlNOIC0gREUvTXVuaWNoKSAmbHQ7dXdlLnJhdXNjaGVuYmFj aEBuc24uY29tJmd0OyA8YnI+DQo8Yj5DYzwvYj46IHJ0Y3dlYkBpZXRmLm9yZyAmbHQ7cnRj d2ViQGlldGYub3JnJmd0OyA8YnI+DQo8Yj5TdWJqZWN0PC9iPjogUmU6IFtydGN3ZWJdIENv bnNlbnN1cyB2cy4gVm90aW5nICh3YXMgUmU6IENhbGwgZm9yIENvbnNlbnN1cyBSZWdhcmRp bmcgU2VsZWN0aW5nIFJlY29tbWVuZGVkIEF1ZGlvIENvZGVjcykgKFVOQ0xBU1NJRklFRCkN Cjxicj4NCjwvZm9udD4mbmJzcDs8YnI+DQo8L2Rpdj4NCjxicj4NCjxkaXY+DQo8ZGl2Pk9u IDE3IEphbiAyMDEzLCBhdCAxNDoyNCwgUmF1c2NoZW5iYWNoLCBVd2UgKE5TTiAtIERFL011 bmljaCkgd3JvdGU6PC9kaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxkaXY+PGZv bnQgY2xhc3M9IkFwcGxlLXN0eWxlLXNwYW4iIGNvbG9yPSIjMDAwMDAwIj48YnI+DQo8L2Zv bnQ+SSBzdWJzdW1lIHVuZGVyICZxdW90O2xlZ2FjeSB0ZWxlcGhvbmUgbmV0d29yayZxdW90 OyBib3RoIHRoZSBmaXhlZCBuZXR3b3JrPGJyPg0KKEcuNzExKSBhbmQgdGhlIG1vYmlsZSBu ZXR3b3JrIChBTVItV0IpLjxicj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj48YnI+ DQo8L2Rpdj4NCjxkaXY+SSBndWVzcyB0aGF0IG1vcmUgY2FsbHMgYXJlIG1hZGUgd2l0aCBH U00uNjEwIHRoYW4mbmJzcDtBTVItV0I8L2Rpdj4NCjwvZGl2Pg0KPGJyPg0KPGRpdj5BTVIt V0IgaXMgJ2Z1dHVyZSBsZWdhY3knIDstKTwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxk aXY+VC48L2Rpdj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSA8YnI+DQpUaGlzIHRyYW5zbWlzc2lvbiAo aW5jbHVkaW5nIGFueSBhdHRhY2htZW50cykgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGlu Zm9ybWF0aW9uLCBwcml2aWxlZ2VkIG1hdGVyaWFsIChpbmNsdWRpbmcgbWF0ZXJpYWwgcHJv dGVjdGVkIGJ5IHRoZSBzb2xpY2l0b3ItY2xpZW50IG9yIG90aGVyIGFwcGxpY2FibGUgcHJp dmlsZWdlcyksIG9yIGNvbnN0aXR1dGUgbm9uLXB1YmxpYyBpbmZvcm1hdGlvbi4gQW55IHVz ZSBvZiB0aGlzIGluZm9ybWF0aW9uIGJ5IGFueW9uZSBvdGhlciB0aGFuIHRoZSBpbnRlbmRl ZCByZWNpcGllbnQgaXMgcHJvaGliaXRlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyB0 cmFuc21pc3Npb24gaW4gZXJyb3IsIHBsZWFzZSBpbW1lZGlhdGVseSByZXBseSB0byB0aGUg c2VuZGVyIGFuZCBkZWxldGUgdGhpcyBpbmZvcm1hdGlvbiBmcm9tIHlvdXIgc3lzdGVtLiBV c2UsIGRpc3NlbWluYXRpb24sIGRpc3RyaWJ1dGlvbiwgb3IgcmVwcm9kdWN0aW9uIG9mIHRo aXMgdHJhbnNtaXNzaW9uIGJ5IHVuaW50ZW5kZWQgcmVjaXBpZW50cyBpcyBub3QgYXV0aG9y aXplZCBhbmQgbWF5IGJlIHVubGF3ZnVsLg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_BBF5DDFE515C3946BC18D733B20DAD2338CF2BE8XMB104ADSrimnet_-- From cb.list6@gmail.com Thu Jan 17 06:38:30 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8465821F8518 for ; Thu, 17 Jan 2013 06:38:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.449 X-Spam-Level: X-Spam-Status: No, score=-4.449 tagged_above=-999 required=5 tests=[AWL=1.149, BAYES_00=-2.599, GB_I_LETTER=-2, 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 EDhFTLryh8HY for ; Thu, 17 Jan 2013 06:38:29 -0800 (PST) Received: from mail-la0-f50.google.com (mail-la0-f50.google.com [209.85.215.50]) by ietfa.amsl.com (Postfix) with ESMTP id 4561921F84C6 for ; Thu, 17 Jan 2013 06:38:28 -0800 (PST) Received: by mail-la0-f50.google.com with SMTP id er20so979613lab.23 for ; Thu, 17 Jan 2013 06:38:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=2Bnq5PyvJO9BS6X89RQMannla2/brma1idLE3V17xAo=; b=iD+o4/XwwaolxcJ79O/Kf3kQ+mU0KbLVKdRVA9iQpQNozbDT+4AZkws3nmKeNPwrjJ z1Iu9yosnoVEQyJoa3sC42wgcj+xvu/AevlG3nDWd4Sh9oih7NnAwkfOs2DC0kkSy281 DpVhnDBUNQdJjTrgd/MUTfNl/2h2IZe4BUEEFLfub75DGCNtIykHLdWg6cNt9PwgioB3 ytWShq7QI8H0YcJrcVsak7a3k4ssf9mW7GkCZvMnwPkw414yhwfDCTIRp6llIQDe9J6x i5SA/LUU65qOpcQVdpmKU4qIxVT/Sr4jNHwYia4AlWT6Dc2uiwBOPpijMTZgVtpMkgYR AYPw== MIME-Version: 1.0 X-Received: by 10.152.124.15 with SMTP id me15mr5172078lab.5.1358433506922; Thu, 17 Jan 2013 06:38:26 -0800 (PST) Received: by 10.112.44.36 with HTTP; Thu, 17 Jan 2013 06:38:26 -0800 (PST) Received: by 10.112.44.36 with HTTP; Thu, 17 Jan 2013 06:38:26 -0800 (PST) In-Reply-To: References: Date: Thu, 17 Jan 2013 06:38:26 -0800 Message-ID: From: Cameron Byrne To: Burger Eric Content-Type: multipart/alternative; boundary=f46d04374581a18f2b04d37cf25f Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Consensus vs. Voting (was Re: Call for Consensus Regarding Selecting Recommended Audio Codecs) (UNCLASSIFIED) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 17 Jan 2013 14:38:30 -0000 --f46d04374581a18f2b04d37cf25f Content-Type: text/plain; charset=ISO-8859-1 Sent from ipv6-only Android On Jan 17, 2013 5:32 AM, "Burger Eric" wrote: > > People, let's be real: +1. Seriously, this is a candidate for the longest rat hole I have seen on the ietf ever. I normally just delete this thread unread since it is so unproductive. > I get the impression that people think that if their favorite codec does not become mandatory to implement or at least implement-under-threat-of-SHOULD, then no one will implement their favorite codec. > > Let us look at the real world. All of those mobile phones with AMR-WB? They are statistically likely to be calling other mobile phones with AMR-WB. Unless I missed something, RTCweb still lets the offer include AMR-WB and the answer select AMR-WB. Your precious AMR-WB codec will still get used, and you can leverage all of the silicon and pre-paid IPR licenses. What about all of those Flash implementations with speex? They are statistically likely to be calling other implementations with speex. I am again only just guessing that the offer will contain speed and the answer will contain speex. > > What about the poor slob on a mobile with AMR-WB that wants to call that Flash buddy with speex? Last I looked, the specification has a MTI of opus. They will connect with opus. If the client is RTCweb compliant, THERE WILL BE NO AMR-WB/SPEEX/G.722/MUMBLE/FOO TO OPUS/G.711 TRANSCODING. > > Now, what about the really poor slob on a non-RTCweb device? Well, they are, ahem, on a non-RTCweb device. That is way out of scope. But wait, you will say -- what about the 1.1 billion 3G subscribers with AMR-WB but no RTCweb? Well, first off, the mobile-based RTCweb device will almost certainly have AMR-WB. While some folks like to pick on mobile phone manufacturers, I doubt some product manager is going to say, "Gee, the IETF specification does not even mention AMR-WB, so I suppose I will not enable the silicon I already paid for or use the license I already paid for, and I will spend my engineering budget to take out AMR-WB." Duh - AMR-WB will be there already, no transcoding, life is good. What about fixed-line or broadband interoperability with some wireless user, when they only have G.722? Well, while we are not making the situation any better, THE SITUATION IS NO WORSE. Transcoding would happen ANYWAY. It happens TODAY. So get with the program. > > Let us fill in the rat-hole and just move on. Two MTI codecs and a SEPARATE implementation guide listing why you MIGHT want to implement your favorite codec. > Yep. Seems we decided this months ago but certain people don't want to hear it. CB > [Hmmmm. "MIGHT". Perhaps a new 2119 term, meaning "You might consider this, and if you don't do it, may may get cooties."] > > On Jan 17, 2013, at 7:54 AM, Andrew Allen wrote: > > > > > As I recall during the MTI discussion it was claimed that OPUS was intended for interoperability between RTCweb endoints and G.711 for interoperability with legacy. That's why we selected 2 MTI Codecs. > > > > Transcoding between G.711 and something else like G.722 will not have anything like the transcoding cost as between OPUS and G.722 - basically the complexity of a media gateway. Of course you will not get the full fidelity of either OPUS or G.722 but basic audio communications will work fine which is all I think we can guarantee with legacy. > > > > If platforms already have other codecs (such as AMR on mobile devices) that are usable by the browser then it makes perfect sense that they be included in the offer but I don't think IETF should start recommending other codecs to implement other than the 2 MTI. This should be left as product decisions based on commercial needs and not recommendations made by IETF the driver for which I suspect has more to do with the interests of some legacy products/deployments than those of RTCweb. > > > > Since almost every computing platform has a browser (including most mobile phones) within a few years every computing platform will have RTCweb and OPUS so the need for high fidelity legacy codec interoperability will I think become a mute point. > > > > I think the inteoperability concerns should be more focussed on the video issue where we seem to have a real problem. > > > > Andrew > > > > ----- Original Message ----- > > From: Roy, Radhika R CIV USARMY (US) [mailto:radhika.r.roy.civ@mail.mil] > > Sent: Thursday, January 17, 2013 06:13 AM Central Standard Time > > To: Roman Shpount ; Martin Thomson < martin.thomson@gmail.com> > > Cc: rtcweb@ietf.org > > Subject: Re: [rtcweb] Consensus vs. Voting (was Re: Call for Consensus Regarding Selecting Recommended Audio Codecs) (UNCLASSIFIED) > > > > Classification: UNCLASSIFIED > > Caveats: NONE > > > > Hi, all: > > > > A good assessment - thanks to Roman. > > > > So, the transcoding cost is enormous from both performance and HW/SW > > implementation point of view. > > > > In the end it may so appear that we are not hearing each other. > > > > BR/Radhika > > > > -----Original Message----- > > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of > > Roman Shpount > > Sent: Thursday, January 17, 2013 5:32 AM > > To: Martin Thomson > > Cc: rtcweb@ietf.org > > Subject: Re: [rtcweb] Consensus vs. Voting (was Re: Call for Consensus > > Regarding Selecting Recommended Audio Codecs) > > > > > > On Wed, Jan 16, 2013 at 7:03 PM, Martin Thomson < martin.thomson@gmail.com> > > wrote: > > > > > > If we don't say "webrtc implementations SHOULD implement > > G.722/AMR/AMR-WB", what is the failure mode for your application? > > Keeping in mind that - because this isn't 2119 MUST - you have to > > expect that some non-negligible proportion of clients will not > > support > > this no matter how much extra ink we using in printing large > > letters, > > how much pain does this really cause you? > > > > I expect that the transcoding costs are what this come down to. > > Does > > anyone care to quantify this? > > > > > > If common codecs are not implemented in the browser this would mean > > transcoding will need to be performed on some sort of server-side media > > gateway. There are three distinct issues we need to take into account when > > dealing with transcoding. I would list them in what, at least from my point > > of view, is the order of importance: > > > > 1. If you need to do trancoding, you will need to implement a jitter buffer > > on the transcoding media gateway. ICE processing and SRTP en/decoding can be > > performed on out of order packets as they are received. You cannot transcode > > out of order audio. This means audio packets would need to be delayed by the > > jitter buffer size. In cases of good internet connection this means 40 ms > > jitter buffer delay. In cases of consumer internet in US (somebody sitting > > on a DSL connection at home behind a WiFi router) you are typically looking > > at 60-80 ms jitter buffer delay. If you are dealing with international > > internet connections jitter of 150 ms to 200 ms is not unheard of. This > > means an additional delay due to jitter buffering of 40 ms (best case) to > > 200 ms. This is in addition to any other delays that are already present on > > the audio path. Adding an extra 100 ms of delay can make audio conversions > > very awkward or unusable. On the other hand, if the gateway were performing > > just ICE and SRTP, it would introduce 1-2 ms of delay at most (In this case > > I am talking about a software based implementation running on generic server > > hardware. A dedicated DSP solution would probably be even faster). > > > > 2. Audio artifacts due to transcoding. Apart from usual audio degradation > > due to transcoding (OPUS transcoded to AMR would sound worse then OPUS or > > AMR), we would also deal with double packet loss concealment. Media gateway > > will conceal lost packets when transcoding. Client will conceal lost packet > > received from the gateway. This would actually sound worse then PLC > > performed in one place. > > > > 3. Scalability of the transcoding gateway. Gateway which just deals with ICE > > processing and SRTP en/decoding can handle from 2000 to 10000 concurrent > > call when running on a generic server CPU (different scalability is due to > > differences in CPU performance and presence of AES specific instructions). > > Gateway that would do G.722 to OPUS transcoding would most likely handle > > from 500 to 1000 concurrent calls. We are looking at 10x difference in > > performance. If we need to transcode AMR to OPUS the difference would be > > even higher. This translates in 10x difference in hardware, data center, > > power, and operations costs. > > > > _____________ > > Roman Shpount > > > > Classification: UNCLASSIFIED > > Caveats: NONE > > > > > > > > --------------------------------------------------------------------- > > This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. > > _______________________________________________ > > 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 --f46d04374581a18f2b04d37cf25f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Sent from ipv6-only Android
On Jan 17, 2013 5:32 AM, "Burger Eric" <eburger@cs.georgetown.edu> wrote:
>
> People, let's be real:

+1.=A0 Seriously,=A0 this is a candidate for the longest=A0 = rat hole I have seen on the ietf ever.=A0

I normally just delete this thread unread since it is so unp= roductive.

> I get the impression that people think that if their fa= vorite codec does not become mandatory to implement or at least implement-u= nder-threat-of-SHOULD, then no one will implement their favorite codec.
>
> Let us look at the real world. All of those mobile phones with AMR-WB?= They are statistically likely to be calling other mobile phones with AMR-W= B. Unless I missed something, RTCweb still lets the offer include AMR-WB an= d the answer select AMR-WB. Your precious AMR-WB codec will still get used,= and you can leverage all of the silicon and pre-paid IPR licenses. What ab= out all of those Flash implementations with speex? They are statistically l= ikely to be calling other implementations with speex. I am again only just = guessing that the offer will contain speed and the answer will contain spee= x.
>
> What about the poor slob on a mobile with AMR-WB that wants to call th= at Flash buddy with speex? Last I looked, the specification has a MTI of op= us. They will connect with opus. If the client is RTCweb compliant, THERE W= ILL BE NO AMR-WB/SPEEX/G.722/MUMBLE/FOO TO OPUS/G.711 TRANSCODING.
>
> Now, what about the really poor slob on a non-RTCweb device? Well, the= y are, ahem, on a non-RTCweb device. That is way out of scope. But wait, yo= u will say -- what about the 1.1 billion 3G subscribers with AMR-WB but no = RTCweb? Well, first off, the mobile-based RTCweb device will almost certain= ly have AMR-WB. While some folks like to pick on mobile phone manufacturers= , I doubt some product manager is going to say, "Gee, the IETF specifi= cation does not even mention AMR-WB, so I suppose I will not enable the sil= icon I already paid for or use the license I already paid for, and I will s= pend my engineering budget to take out AMR-WB." Duh - AMR-WB will be t= here already, no transcoding, life is good. What about fixed-line or broadb= and interoperability with some wireless user, when they only have G.722? We= ll, while we are not making the situation any better, THE SITUATION IS NO W= ORSE. Transcoding would happen ANYWAY. It happens TODAY. So get with the pr= ogram.
>
> Let us fill in the rat-hole and just move on. Two MTI codecs and a SEP= ARATE implementation guide listing why you MIGHT want to implement your fav= orite codec.
>

Yep.=A0 Seems we decided this months ago but certain people = don't want to hear it.

CB

> [Hmmmm. "MIGHT". =A0Perhaps a new 2119 term, = meaning "You might consider this, and if you don't do it, may may = get cooties."]
>
> On Jan 17, 2013, at 7:54 AM, Andrew Allen <aallen@rim.com> wrote:
>
> >
> > As I recall during the MTI discussion it was claimed that OPUS wa= s intended for interoperability between RTCweb endoints and G.711 for inter= operability with legacy. That's why we selected 2 MTI Codecs.
> >
> > Transcoding between G.711 and something else like G.722 will not = have anything like the transcoding cost as between OPUS and G.722 - basical= ly the complexity of a media gateway. =A0Of course you will not get the ful= l fidelity of either OPUS or G.722 but basic audio communications will work= fine which is all I think we can guarantee with legacy.
> >
> > If platforms already have other codecs (such as AMR on mobile dev= ices) that are usable by the browser then it makes perfect sense that they = be included in the offer but I don't think IETF should start recommendi= ng other codecs to implement other than the 2 MTI. This should be left as p= roduct decisions based on commercial needs and not recommendations made by = IETF the driver for which I suspect has more to do with the interests of so= me legacy products/deployments than those of RTCweb.
> >
> > Since almost every computing platform has a browser (including mo= st mobile phones) within a few years every computing platform will have RTC= web and OPUS so the need for high fidelity legacy codec interoperability wi= ll I think become a mute point.
> >
> > I think the inteoperability concerns should be more focussed on t= he video issue where we seem to have a real problem.
> >
> > Andrew
> >
> > ----- Original Message -----
> > From: Roy, Radhika R CIV USARMY (US) [mailto:radhika.r.roy.civ@mail.mil]
> > Sent: Thursday, January 17, 2013 06:13 AM Central Standard Time > > To: Roman Shpount <roman@= telurix.com>; Martin Thomson <martin.thomson@gmail.com>
> > Cc: rtcweb@ietf.org <rtcweb@ietf.org>
> > Subject: Re: [rtcweb] Consensus vs. Voting (was Re: Call for Cons= ensus Regarding Selecting Recommended Audio Codecs) (UNCLASSIFIED)
> >
> > Classification: UNCLASSIFIED
> > Caveats: NONE
> >
> > Hi, all:
> >
> > A good assessment - thanks to Roman.
> >
> > So, the transcoding cost is enormous from both performance and HW= /SW
> > implementation point of view.
> >
> > In the end it may so appear that we are not hearing each other. > >
> > BR/Radhika
> >
> > -----Original Message-----
> > From: rtcweb-bounces@i= etf.org [mailto:rtcweb-bounc= es@ietf.org] On Behalf Of
> > Roman Shpount
> > Sent: Thursday, January 17, 2013 5:32 AM
> > To: Martin Thomson
> > Cc: rtcweb@ietf.org
> > Subject: Re: [rtcweb] Consensus vs. Voting (was Re: Call for Cons= ensus
> > Regarding Selecting Recommended Audio Codecs)
> >
> >
> > On Wed, Jan 16, 2013 at 7:03 PM, Martin Thomson <martin.thomson@gmail.com>
> > wrote:
> >
> >
> > =A0 =A0 =A0 If we don't say "webrtc implementations SHOU= LD implement
> > =A0 =A0 =A0 G.722/AMR/AMR-WB", what is the failure mode for = your application?
> > =A0 =A0 =A0 Keeping in mind that - because this isn't 2119 MU= ST - you have to
> > =A0 =A0 =A0 expect that some non-negligible proportion of clients= will not
> > support
> > =A0 =A0 =A0 this no matter how much extra ink we using in printin= g large
> > letters,
> > =A0 =A0 =A0 how much pain does this really cause you?
> >
> > =A0 =A0 =A0 I expect that the transcoding costs are what this com= e down to.
> > Does
> > =A0 =A0 =A0 anyone care to quantify this?
> >
> >
> > If common codecs are not implemented in the browser this would me= an
> > transcoding will need to be performed on some sort of server-side= media
> > gateway. There are three distinct issues we need to take into acc= ount when
> > dealing with transcoding. I would list them in what, at least fro= m my point
> > of view, is the order of importance:
> >
> > 1. If you need to do trancoding, you will need to implement a jit= ter buffer
> > on the transcoding media gateway. ICE processing and SRTP en/deco= ding can be
> > performed on out of order packets as they are received. You canno= t transcode
> > out of order audio. This means audio packets would need to be del= ayed by the
> > jitter buffer size. In cases of good internet connection this mea= ns 40 ms
> > jitter buffer delay. In cases of consumer internet in US (somebod= y sitting
> > on a DSL connection at home behind a WiFi router) you are typical= ly looking
> > at 60-80 ms jitter buffer delay. If you are dealing with internat= ional
> > internet connections jitter of 150 ms to 200 ms is not unheard of= . This
> > means an additional delay due to jitter buffering of 40 ms (best = case) to
> > 200 ms. This is in addition to any other delays that are already = present on
> > the audio path. Adding an extra 100 ms of delay can make audio co= nversions
> > very awkward or unusable. On the other hand, if the gateway were = performing
> > just ICE and SRTP, it would introduce 1-2 ms of delay at most (In= this case
> > I am talking about a software based implementation running on gen= eric server
> > hardware. A dedicated DSP solution would probably be even faster)= .
> >
> > 2. Audio artifacts due to transcoding. Apart from usual audio deg= radation
> > due to transcoding (OPUS transcoded to AMR would sound worse then= OPUS or
> > AMR), we would also deal with double packet loss concealment. Med= ia gateway
> > will conceal lost packets when transcoding. Client will conceal l= ost packet
> > received from the gateway. This would actually sound worse then P= LC
> > performed in one place.
> >
> > 3. Scalability of the transcoding gateway. Gateway which just dea= ls with ICE
> > processing and SRTP en/decoding can handle from 2000 to 10000 con= current
> > call when running on a generic server CPU (different scalability = is due to
> > differences in CPU performance and presence of AES specific instr= uctions).
> > Gateway that would do G.722 to OPUS transcoding would most likely= handle
> > from 500 to 1000 concurrent calls. We are looking at 10x differen= ce in
> > performance. If we need to transcode AMR to OPUS the difference w= ould be
> > even higher. This translates in 10x difference in hardware, data = center,
> > power, and operations costs.
> >
> > _____________
> > Roman Shpount
> >
> > Classification: UNCLASSIFIED
> > Caveats: NONE
> >
> >
> >
> > -----------------------------------------------------------------= ----
> > This transmission (including any attachments) may contain confide= ntial information, privileged material (including material protected by the= solicitor-client or other applicable privileges), or constitute non-public= information. Any use of this information by anyone other than the intended= recipient is prohibited. If you have received this transmission in error, = please immediately reply to the sender and delete this information from you= r system. Use, dissemination, distribution, or reproduction of this transmi= ssion by unintended recipients is not authorized and may be unlawful.
> > _______________________________________________
> > 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

--f46d04374581a18f2b04d37cf25f-- From xavier.marjou@gmail.com Thu Jan 17 06:41:02 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C9AD21F8523 for ; Thu, 17 Jan 2013 06:41:02 -0800 (PST) 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 DiMZa6LtaO8b for ; Thu, 17 Jan 2013 06:41:01 -0800 (PST) Received: from mail-qa0-f54.google.com (mail-qa0-f54.google.com [209.85.216.54]) by ietfa.amsl.com (Postfix) with ESMTP id 8C34421F84E4 for ; Thu, 17 Jan 2013 06:41:01 -0800 (PST) Received: by mail-qa0-f54.google.com with SMTP id p6so458709qad.13 for ; Thu, 17 Jan 2013 06:41:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=HGkhP60TEvkIarYtgbiHxW6QQWwHkYd37YeREsynr0U=; b=ivbUd21YYNFiV93QZI92dig6247CfO01+CXhWoC+OxOUbPe3kWhZHWAjjY+IOZpgBQ k0Gz5HtqBOLOyUw4paCXUNR3PUJL+6rcPEeCntDl5jIgLu22qU6x1m50fE1So3ctAcvZ 18T9zLORGltea3jPOEvi9DrP1NCibokYaP0h1qrdhV3FVEo6BwQxo8q1YsTqUHl3c69l TD0zlaRwJFsQ82FPmNW+L24ZJ3vdm0ckY5Ywth+LaoER3aISYz1q9HOqGfsG3wTPFX2/ XZrzvmoFEJ8DNo3EZnRW1b7huou8hzG53R2dNtFP9WyrqfkmngGpu2fzKW2FQ3bf/hfb rB8A== MIME-Version: 1.0 X-Received: by 10.229.174.199 with SMTP id u7mr1323311qcz.80.1358433660987; Thu, 17 Jan 2013 06:41:00 -0800 (PST) Sender: xavier.marjou@gmail.com Received: by 10.49.63.227 with HTTP; Thu, 17 Jan 2013 06:41:00 -0800 (PST) In-Reply-To: <50F80846.5030300@nostrum.com> References: <8486C8728176924BAF5BDB2F7D7EEDDF4907E630@ucolhp9l.easf.csd.disa.mil> <7CBFD4609D19C043A4AC4FD8381C6E26023CF7B3@DEMUEXC014.nsn-intra.net> <50F80846.5030300@nostrum.com> Date: Thu, 17 Jan 2013 15:41:00 +0100 X-Google-Sender-Auth: fz-ASGn73NzvOaTN935Cf1ftWV8 Message-ID: From: Xavier Marjou To: Adam Roach , rtcweb@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [rtcweb] Consensus vs. Voting (was Re: Call for Consensus Regarding Selecting Recommended Audio Codecs) (UNCLASSIFIED) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 17 Jan 2013 14:41:02 -0000 Regarding audio codecs, it is a common misconception that existing voice networks only support G.711. For the sake of clarity, let's say that there is the PSTN (circuit switched networks) and the "PSTN" (a set of networks made of the PSTN, PLMN but also H.323 and SIP based networks...). In the "PSTN", there is sometimes the real need to use a codec of lower-bandwidth than G.711, and sometimes the opportunity to use WB codecs. WebRTC must interoperate with the "PSTN", not only the PSTN. Cheers, Xavier On Thu, Jan 17, 2013 at 3:18 PM, Adam Roach wrote: > > If you're using the existing PSTN as your lowest-common-denominator > interconnect, then the call *is* going to be G.711 at some point in its > life. And given that the WebRTC endpoints can talk G.711 to the PSTN gateway > -- G.711 being MTI -- this use case is already addressed. > From stephane.proust@orange.com Thu Jan 17 06:41:20 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD6C521F84E4 for ; Thu, 17 Jan 2013 06:41:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.519 X-Spam-Level: X-Spam-Status: No, score=-2.519 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, 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 UczF7cwE7kqQ for ; Thu, 17 Jan 2013 06:41:20 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id A9FD521F8425 for ; Thu, 17 Jan 2013 06:41:19 -0800 (PST) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 6A80F2DC216; Thu, 17 Jan 2013 15:41:18 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 4E17E238079; Thu, 17 Jan 2013 15:41:18 +0100 (CET) Received: from PEXCVZYM14.corporate.adroot.infra.ftgroup ([fe80::a42f:c628:bc76:d592]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0318.004; Thu, 17 Jan 2013 15:41:17 +0100 From: To: Tim Panton , "Rauschenbach, Uwe (NSN - DE/Munich)" Thread-Topic: [rtcweb] Consensus vs. Voting (was Re: Call for Consensus Regarding Selecting Recommended Audio Codecs) (UNCLASSIFIED) Thread-Index: AQHN9L5d2aco9FXWy0qHvMzvdhbM1JhNg1+AgAASqeA= Date: Thu, 17 Jan 2013 14:41:17 +0000 Message-ID: <18441_1358433678_50F80D8E_18441_583_1_2842AD9A45C83B44B57635FD4831E60A075F80@PEXCVZYM14.corporate.adroot.infra.ftgroup> References: <8486C8728176924BAF5BDB2F7D7EEDDF4907E630@ucolhp9l.easf.csd.disa.mil> <7CBFD4609D19C043A4AC4FD8381C6E26023CF7B3@DEMUEXC014.nsn-intra.net> <50F80846.5030300@nostrum.com> <7CBFD4609D19C043A4AC4FD8381C6E26023CF832@DEMUEXC014.nsn-intra.net> In-Reply-To: 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.10.24.110314 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Consensus vs. Voting (was Re: Call for Consensus Regarding Selecting Recommended Audio Codecs) (UNCLASSIFIED) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 17 Jan 2013 14:41:21 -0000 > AMR-WB is 'future legacy' ;-) It seems we already live in the future: Currently HD voice with AMR-WB is l= aunched in more than 50 mobile networks all over the world (more than 35 co= untries) with more than 130 WB-AMR enabled mobile devices Probably at present time a little bit more AMR-WB codecs deployed than OPUS= codecs. Just check on the GSA Web site http://www.gsacom.com/news/gsa_358.php Stephane De=A0: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] De la part = de Tim Panton Envoy=E9=A0: jeudi 17 janvier 2013 15:28 =C0=A0: Rauschenbach, Uwe (NSN - DE/Munich) Cc=A0: rtcweb@ietf.org Objet=A0: Re: [rtcweb] Consensus vs. Voting (was Re: Call for Consensus Reg= arding Selecting Recommended Audio Codecs) (UNCLASSIFIED) On 17 Jan 2013, at 14:24, Rauschenbach, Uwe (NSN - DE/Munich) wrote: I subsume under "legacy telephone network" both the fixed network (G.711) and the mobile network (AMR-WB). I guess that more calls are made with GSM.610 than=A0AMR-WB AMR-WB is 'future legacy' ;-) T. ___________________________________________________________________________= ______________________________________________ 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 tim@phonefromhere.com Thu Jan 17 06:48:03 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B40521F85EA for ; Thu, 17 Jan 2013 06:48:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.322 X-Spam-Level: X-Spam-Status: No, score=-2.322 tagged_above=-999 required=5 tests=[AWL=0.277, 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 Z6uCFkdUDdmq for ; Thu, 17 Jan 2013 06:48:02 -0800 (PST) Received: from smtp003.apm-internet.net (smtp003.apm-internet.net [85.119.248.52]) by ietfa.amsl.com (Postfix) with ESMTP id BFC2621F8613 for ; Thu, 17 Jan 2013 06:48:01 -0800 (PST) Received: (qmail 76899 invoked from network); 17 Jan 2013 14:48:00 -0000 X-AV-Scan: clean Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp003.apm-internet.net with SMTP; 17 Jan 2013 14:48:00 -0000 Received: from [192.67.4.33] (unknown [192.67.4.33]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id B8E7F18A0A72; Thu, 17 Jan 2013 14:48:00 +0000 (GMT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Tim Panton In-Reply-To: <18441_1358433678_50F80D8E_18441_583_1_2842AD9A45C83B44B57635FD4831E60A075F80@PEXCVZYM14.corporate.adroot.infra.ftgroup> Date: Thu, 17 Jan 2013 14:48:00 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <7F17D6EC-A402-4D5B-B323-9BF04843F1F9@phonefromhere.com> References: <8486C8728176924BAF5BDB2F7D7EEDDF4907E630@ucolhp9l.easf.csd.disa.mil> <7CBFD4609D19C043A4AC4FD8381C6E26023CF7B3@DEMUEXC014.nsn-intra.net> <50F80846.5030300@nostrum.com> <7CBFD4609D19C043A4AC4FD8381C6E26023CF832@DEMUEXC014.nsn-intra.net> <18441_1358433678_50F80D8E_18441_583_1_2842AD9A45C83B44B57635FD4831E60A075F80@PEXCVZYM14.corporate.adroot.infra.ftgroup> To: X-Mailer: Apple Mail (2.1283) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Consensus vs. Voting (was Re: Call for Consensus Regarding Selecting Recommended Audio Codecs) (UNCLASSIFIED) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 17 Jan 2013 14:48:03 -0000 On 17 Jan 2013, at 14:41, wrote: >> AMR-WB is 'future legacy' ;-) >=20 > It seems we already live in the future: Currently HD voice with AMR-WB = is launched in more than 50 mobile networks all over the world (more = than 35 countries) with more than 130 WB-AMR enabled mobile devices >=20 > Probably at present time a little bit more AMR-WB codecs deployed than = OPUS codecs. >=20 > Just check on the GSA Web site >=20 > http://www.gsacom.com/news/gsa_358.php At the risk of worsening the rat hole, I will bet you that more wideband = minutes are carried over opus on Mumble than AMR-WB over the entire GSMA.=20 I'll also bet that there are more chrome users (with opus enabled) than = Gsm handsets with AMR-WB enabled. T. From stephane.proust@orange.com Thu Jan 17 06:53:54 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32D5A21F84E6 for ; Thu, 17 Jan 2013 06:53:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.546 X-Spam-Level: X-Spam-Status: No, score=-2.546 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, 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 Yz7UU1Mkfs2L for ; Thu, 17 Jan 2013 06:53:52 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id D6AE421F84DA for ; Thu, 17 Jan 2013 06:53:50 -0800 (PST) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id C5A0D3245B8; Thu, 17 Jan 2013 15:53:49 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id AA8EE4C06C; Thu, 17 Jan 2013 15:53:49 +0100 (CET) Received: from PEXCVZYM14.corporate.adroot.infra.ftgroup ([fe80::a42f:c628:bc76:d592]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0318.004; Thu, 17 Jan 2013 15:53:49 +0100 From: To: Bernard Aboba Thread-Topic: [rtcweb] Call for Consensus Regarding Selecting Recommended Audio Codecs Thread-Index: AQHN8mRGZY1W6U1DAUi/t6Ni15di/5hNnNKw Date: Thu, 17 Jan 2013 14:53:48 +0000 Message-ID: <30709_1358434429_50F8107D_30709_442_1_2842AD9A45C83B44B57635FD4831E60A075FBC@PEXCVZYM14.corporate.adroot.infra.ftgroup> References: <50D2CC6A.4090500@ericsson.com>, <6515_1357907583_50F0067F_6515_1738_1_2842AD9A45C83B44B57635FD4831E60A0747CC@PEXCVZYM14.corporate.adroot.infra.ftgroup>, <161DAF1D-E35A-4D75-9155-18E70F66EE77@phonefromhere.com> In-Reply-To: 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.10.24.110314 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Call for Consensus Regarding Selecting Recommended 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, 17 Jan 2013 14:53:54 -0000 Please consider that the AMR-WB codec is the mandatory codec for HD Voice V= oLTE terminals and that first VoLTE deployments in the world from Korean Te= lcos (SKT and LGU) are HD Voice with AMR-WB (And with respect to your past/= future categories, I think we can say that VoLTE is more on future side tha= t "past") But AMR-WB is also already deployed in the 2G and 3G networks of more than = 50 Mobile Network Operators So I agree that interop. with legacy are two objectives distinct and fortun= ately, supporting AMR-WB is sufficient to reach both in the same time ! De=A0: Bernard Aboba [mailto:bernard_aboba@hotmail.com]=20 Envoy=E9=A0: lundi 14 janvier 2013 15:35 =C0=A0: PROUST Stephane OLNC/OLPS Cc=A0: rtcweb@ietf.org Objet=A0: RE: [rtcweb] Call for Consensus Regarding Selecting Recommended A= udio Codecs Stephane said: "In addition to G.711, these 3 codecs cover almost all legacy devices dedic= ated to voice services. They are consequently needed and sufficient to be s= upported by WebRTC to make it an attractive and future proof technology" [BA] The use of the terms "legacy" and "future proof" here is puzzling.=A0= =A0 "Future proof" would seem to imply the ability to adapt to future devel= opments, whereas "legacy" relates to compatibility with what has gone befor= e.=A0=A0 Unless the "past" is the same as the "future" (which implies no pr= ogress at all), those two objectives are distinct (and possibly conflicting= ). ___________________________________________________________________________= ______________________________________________ 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 cb.list6@gmail.com Thu Jan 17 07:11:48 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16B1521F869E for ; Thu, 17 Jan 2013 07:11:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.832 X-Spam-Level: X-Spam-Status: No, score=-3.832 tagged_above=-999 required=5 tests=[AWL=-0.234, 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 Bvmb5NIgqzEG for ; Thu, 17 Jan 2013 07:11:47 -0800 (PST) Received: from mail-la0-f50.google.com (mail-la0-f50.google.com [209.85.215.50]) by ietfa.amsl.com (Postfix) with ESMTP id C35BF21F869F for ; Thu, 17 Jan 2013 07:11:46 -0800 (PST) Received: by mail-la0-f50.google.com with SMTP id er20so1048780lab.37 for ; Thu, 17 Jan 2013 07:11:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=/yQl9IrnYgn4y1uxxh+KBOKyUYWCN8XjgRgJvtdTFrI=; b=WCyZlW1AeCBWHeHW/F7DI4ZJa5pvzqYOgdc1IDcTfxR6h6mc8we7oNAue8CcRKfkSv gA/3GZXNj9tGCzjAZ3WKY096m9UBsXjwznz8ZeIoW4V/UmexWhf198hy+vGAcb+ZaKc9 ppQAmH/8Pu01qfOZFumEOajyt6Thj7aEbB/CAOqNCFoFlYy9KtEd6IKBKuKekdqb8Wfs AH3n4g5McbQsgyoux2L/Xm/PKF7EBpONY6HOYJcdsGXCLYU4wrbAlZQPWYQmEF5uco42 bJoByouc7OOEa1mIetlsTkJ1rVenRlmcJuYPmiDhIIIlJCt9VrFeschcGkV75b75dpal udIQ== MIME-Version: 1.0 X-Received: by 10.112.46.199 with SMTP id x7mr2328927lbm.109.1358435505738; Thu, 17 Jan 2013 07:11:45 -0800 (PST) Received: by 10.112.44.36 with HTTP; Thu, 17 Jan 2013 07:11:45 -0800 (PST) Received: by 10.112.44.36 with HTTP; Thu, 17 Jan 2013 07:11:45 -0800 (PST) In-Reply-To: <30709_1358434429_50F8107D_30709_442_1_2842AD9A45C83B44B57635FD4831E60A075FBC@PEXCVZYM14.corporate.adroot.infra.ftgroup> References: <50D2CC6A.4090500@ericsson.com> <6515_1357907583_50F0067F_6515_1738_1_2842AD9A45C83B44B57635FD4831E60A0747CC@PEXCVZYM14.corporate.adroot.infra.ftgroup> <161DAF1D-E35A-4D75-9155-18E70F66EE77@phonefromhere.com> <30709_1358434429_50F8107D_30709_442_1_2842AD9A45C83B44B57635FD4831E60A075FBC@PEXCVZYM14.corporate.adroot.infra.ftgroup> Date: Thu, 17 Jan 2013 07:11:45 -0800 Message-ID: From: Cameron Byrne To: stephane.proust@orange.com Content-Type: multipart/alternative; boundary=bcaec5540568c5154604d37d698c Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Call for Consensus Regarding Selecting Recommended 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, 17 Jan 2013 15:11:48 -0000 --bcaec5540568c5154604d37d698c Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sent from ipv6-only Android On Jan 17, 2013 6:54 AM, wrote: > > Please consider that the AMR-WB codec is the mandatory codec for HD Voice VoLTE terminals and that first VoLTE deployments in the world from Korean Telcos (SKT and LGU) are HD Voice with AMR-WB (And with respect to your past/future categories, I think we can say that VoLTE is more on future side that "past") > > But AMR-WB is also already deployed in the 2G and 3G networks of more than 50 Mobile Network Operators > > So I agree that interop. with legacy are two objectives distinct and fortunately, supporting AMR-WB is sufficient to reach both in the same time ! > > Please accept that the ipr terms of amr-wb pose a huge barrier for the ietf. I really believe you are wasting your time. Please focus your efforts on ensuring your offer/answer supports the codec you want you want in your implementation. Your efforts would be better spent getting the 3gpp to accept Opus as their default, it is royalty free and mti for all web browsers. Br, CB > De : Bernard Aboba [mailto:bernard_aboba@hotmail.com] > Envoy=E9 : lundi 14 janvier 2013 15:35 > =C0 : PROUST Stephane OLNC/OLPS > Cc : rtcweb@ietf.org > Objet : RE: [rtcweb] Call for Consensus Regarding Selecting Recommended Audio Codecs > > Stephane said: > > "In addition to G.711, these 3 codecs cover almost all legacy devices dedicated to voice services. They are consequently needed and sufficient to be supported by WebRTC to make it an attractive and future proof technology= " > > [BA] The use of the terms "legacy" and "future proof" here is puzzling. "Future proof" would seem to imply the ability to adapt to future developments, whereas "legacy" relates to compatibility with what has gone before. Unless the "past" is the same as the "future" (which implies no progress at all), those two objectives are distinct (and possibly conflicting). > > > > > ___________________________________________________________________________= ______________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles 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 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 information 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 delete this message and its attachments. > As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified. > Thank you. > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --bcaec5540568c5154604d37d698c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Sent from ipv6-only Android
On Jan 17, 2013 6:54 AM, <= stephane.proust@orange.com> wrote:
>
> Please consider that the AMR-WB codec is the mandatory codec for HD Vo= ice VoLTE terminals and that first VoLTE deployments in the world from Kore= an Telcos (SKT and LGU) are HD Voice with AMR-WB (And with respect to your = past/future categories, I think we can say that VoLTE is more on future sid= e that "past")
>
> But AMR-WB is also already deployed in the 2G and 3G networks of more = than 50 Mobile Network Operators
>
> So I agree that interop. with legacy are two objectives distinct and f= ortunately, supporting AMR-WB is sufficient to reach both in the same time = !
>
>

Please accept that the ipr terms of amr-wb pose a huge barri= er for the ietf. I really believe you are wasting your time. Please focus y= our efforts on ensuring your offer/answer supports the codec you want you w= ant in your implementation.

Your efforts would be better spent getting the 3gpp to accep= t Opus as their default,=A0 it is royalty free and mti for all web browsers= .

Br,

CB

> De=A0: Bernard Aboba [mailto:bernard_aboba@hotmail.com]
> Envoy=E9=A0: lundi 14 janvier 2013 15:35
> =C0=A0: PROUST Stephane OLNC/OLPS
> Cc=A0: rtcweb@ietf.org
> Objet=A0: RE: [rtcweb] Call for Consensus Regarding Selecting Recommen= ded Audio Codecs
>
> Stephane said:
>
> "In addition to G.711, these 3 codecs cover almost all legacy dev= ices dedicated to voice services. They are consequently needed and sufficie= nt to be supported by WebRTC to make it an attractive and future proof tech= nology"
>
> [BA] The use of the terms "legacy" and "future proof&qu= ot; here is puzzling.=A0=A0 "Future proof" would seem to imply th= e ability to adapt to future developments, whereas "legacy" relat= es to compatibility with what has gone before.=A0=A0 Unless the "past&= quot; is the same as the "future" (which implies no progress at a= ll), those two objectives are distinct (and possibly conflicting).
>
>
>
>
> ______________________________________________________________________= ___________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations con= fidentielles 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 me= ssages electroniques etant susceptibles d'alteration,
> France Telecom - Orange decline toute responsabilite si ce message a e= te altere, deforme ou falsifie. Merci.
>
> This message and its attachments may contain confidential or privilege= d information that may be protected by law;
> they should not be distributed, used or copied without authorisation.<= br> > If you have received this email in error, please notify the sender and= delete this message and its attachments.
> As emails may be altered, France Telecom - Orange is not liable for me= ssages that have been modified, changed or falsified.
> Thank you.
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.i= etf.org/mailman/listinfo/rtcweb

--bcaec5540568c5154604d37d698c-- From stephane.proust@orange.com Thu Jan 17 07:16:06 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 313D021F8586 for ; Thu, 17 Jan 2013 07:16:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.401 X-Spam-Level: X-Spam-Status: No, score=-2.401 tagged_above=-999 required=5 tests=[AWL=-0.118, BAYES_00=-2.599, 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 h310zaViDR2g for ; Thu, 17 Jan 2013 07:16:05 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id D8C6721F8581 for ; Thu, 17 Jan 2013 07:16:04 -0800 (PST) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 438C53B411E; Thu, 17 Jan 2013 16:16:04 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 23D6535C06B; Thu, 17 Jan 2013 16:16:04 +0100 (CET) Received: from PEXCVZYM14.corporate.adroot.infra.ftgroup ([fe80::a42f:c628:bc76:d592]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0318.004; Thu, 17 Jan 2013 16:16:03 +0100 From: To: Magnus Westerlund , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Call for Consensus Regarding Selecting Recommended Audio Codecs Thread-Index: AQHN3owmqyZHJi4FC0mpFMH1fvMMAZhEMJwwgAmHIeA= Date: Thu, 17 Jan 2013 15:16:03 +0000 Message-ID: <24103_1358435764_50F815B4_24103_9252_1_2842AD9A45C83B44B57635FD4831E60A076013@PEXCVZYM14.corporate.adroot.infra.ftgroup> References: <50D2CC6A.4090500@ericsson.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: 2013.1.17.131820 Subject: Re: [rtcweb] Call for Consensus Regarding Selecting Recommended 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, 17 Jan 2013 15:16:06 -0000 Hello all Considering all the discussions on the list, it is clear that a way must be= found to address from codec perspective both the interoperability issue an= d the license cost issues with a good compromise spirit Ensuring interoperability of Web RTC technology across various types of env= ironment and devices (e.g. fixed/PC, mobile, tablets..) is a must. Strictly sticking to the current situation with only OPUS and G.711 will no= t solve properly the issue especially because this would mean to fail to ad= dress correctly the biggest market of hundreds of millions of mobiles termi= nals that currently support neither G.711 nor OPUS.=20 =20 The lack of support & use of AMR and AMR-WB codecs in Web-RTC will then re= quire transcoding and degrade the user experience: lower end to end voice q= uality and increased latency. The lack of support of these codecs would als= o increase the costs on network side to implement codec transcoding functio= ns. =20 Hence, it is needed to also consider the support & use of these additional = codecs (AMR, AMR-WB) by Web-RTC. =20 It is recognized however that the support of these additional codecs by Web= RTC would add some costs on browsers, part of these costs coming from codec= license fees. However, from technical perspective, browser implementation = of these codecs is not needed, when these codecs are already natively imple= mented by the hardware platform (e.g. by mobile phone). =20 Considering this very reduced set of additional codecs which has to be take= n into account and considering, in addition, that these codecs are already = supported by many devices, a way forward can surely be found like by ensuri= ng that RTC Web give access to these codecs at reasonable costs whenever po= ssible. And this could be especially the case when these codecs are already= implemented on the devices. =20 Such way forward would require however more than just e-mail discussion bet= ween different options. We think that some more detailed inputs for next me= eting would be needed to address properly this interoperability topic by co= nsidering priority use cases and compromise ways forward like proposed in t= his e-mail. We intent to provide a draft on this issue at next meeting. -----Message d'origine----- De=A0: PROUST Stephane OLNC/OLPS=20 Envoy=E9=A0: vendredi 11 janvier 2013 13:33 =C0=A0: 'Magnus Westerlund'; rtcweb@ietf.org Objet=A0: RE: [rtcweb] Call for Consensus Regarding Selecting Recommended A= udio Codecs It is clear from the discussions on the rtcweb e-mail reflector that the on= ly additional codecs to be considered are limited to the following very sma= ll subset of 3 codecs: AMR, AMR-WB and G.722.=20 In addition to G.711, these 3 codecs cover almost all legacy devices dedica= ted to voice services. They are consequently needed and sufficient to be su= pported by WebRTC to make it an attractive and future proof technology for = usage in all environments including mobile and for interoperability use cas= es with most of all legacy voice terminals. AMR and AMR-WB are indeed the most widely supported voice codecs in hundred= s of millions of legacy mobile devices. G.722 is royalty free (including a Packet Loss Concealment solution provide= d in ITU-T Software Tool Library) and is the codec used for HD Voice / DECT= -Cat IQ fixed devices Furthermore, considering that the reason for excluding AMR and AMR-WB from = WebRTC was the licensing issue, there is no reason to NOT support AMR-WB an= d AMR at WebRTC level if these codecs are already implemented on the device. Therefore I support option 1 and propose the following specification accord= ing this: AMR-WB, AMR and G.722 are RECOMMENDED TO IMPLEMENT by WebRTC end-points AMR and AMR-WB MUST BE supported at WebRTC level by WebRTC end-points on 3G= PP mobile devices already implementing AMR and AMR-WB (*) (*) note that the way these codecs are supported at RTC Web level is left o= pen to implementors: either by a WebRTC specific software implementation of= these codecs or by using APIs to access hardward implementation.=20 -----Message d'origine----- De=A0: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] De la part = de Magnus Westerlund Envoy=E9=A0: jeudi 20 d=E9cembre 2012 09:30 =C0=A0: rtcweb@ietf.org Objet=A0: [rtcweb] Call for Consensus Regarding Selecting Recommended Audio= Codecs WG, As an outcome of the Vancouver IETF meeting codec discussions we did promise to run a call for consensus regarding if the WG was interested in specifying a small set of recommended audio codecs. We are sorry this has been delayed until now. The question for the call of consensus is between two options. 1) Run a process in the WG to select and specify a small set of audio/speech codecs that would be RECOMMNEDED to implement by a WebRTC end-points 2) Do nothing and let the already specified Mandatory to Implement Audio codecs be the only audio codecs mentioned in the WebRTC specification. Please indicate your position by January 16th 2013. Regards Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 F=E4r=F6gatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ 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 roman@telurix.com Thu Jan 17 07:27:45 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDEB721F8487 for ; Thu, 17 Jan 2013 07:27:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[AWL=0.356, 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 81MYZpRkLtKj for ; Thu, 17 Jan 2013 07:27:45 -0800 (PST) Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 08F8021F8484 for ; Thu, 17 Jan 2013 07:27:44 -0800 (PST) Received: by mail-we0-f181.google.com with SMTP id u7so156407wey.12 for ; Thu, 17 Jan 2013 07:27:44 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-received:in-reply-to:references:date :message-id:subject:from:to:content-type:x-gm-message-state; bh=0cxLBxaeQZAY2HYurFZo+kERA3cbzV+xhvaxhZhxYaE=; b=CRYdOp8n21rUSFOlAm3Q5cVcw2xIMBG97jQsWxKDDGnt2AMnlSQoeTkBKtAFOl4LCR EbqDZUdjAqpGob5JQdosnltD3IxtOonH+0JzfXe1so/QFGqRx06FawcgeLUMwntoPw84 xzXJn9M1NQC+aE1HFksW2A3evthDu3CGrMs4KYS1SwMow+r50d4Ju9QTSb4CgLSuPnj7 IQO0nwMw8cW2XnsL6zUCyaB6ma6fYdiua6rL6M9zZqA4sqejOBg6pWQ6OPKd2CF1HqdX DdKEIeCqCjgcM/zvcd1jdhe8b1wuhKWGo8amo3Q6dJ7DowPikmrCXM/i30+9UUzKx6AP Oc5w== X-Received: by 10.180.19.136 with SMTP id f8mr9020849wie.0.1358436464135; Thu, 17 Jan 2013 07:27:44 -0800 (PST) Received: from mail-wi0-f171.google.com (mail-wi0-f171.google.com [209.85.212.171]) by mx.google.com with ESMTPS id hu8sm13330718wib.6.2013.01.17.07.27.42 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 17 Jan 2013 07:27:42 -0800 (PST) Received: by mail-wi0-f171.google.com with SMTP id hn14so4576317wib.10 for ; Thu, 17 Jan 2013 07:27:41 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.194.78.207 with SMTP id d15mr9092625wjx.52.1358436461369; Thu, 17 Jan 2013 07:27:41 -0800 (PST) Received: by 10.216.16.134 with HTTP; Thu, 17 Jan 2013 07:27:40 -0800 (PST) In-Reply-To: References: <50D2CC6A.4090500@ericsson.com> <6515_1357907583_50F0067F_6515_1738_1_2842AD9A45C83B44B57635FD4831E60A0747CC@PEXCVZYM14.corporate.adroot.infra.ftgroup> <161DAF1D-E35A-4D75-9155-18E70F66EE77@phonefromhere.com> <30709_1358434429_50F8107D_30709_442_1_2842AD9A45C83B44B57635FD4831E60A075FBC@PEXCVZYM14.corporate.adroot.infra.ftgroup> Date: Thu, 17 Jan 2013 10:27:40 -0500 Message-ID: From: Roman Shpount To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=047d7bfcf91abada1104d37da2a1 X-Gm-Message-State: ALoCoQma+aUaM9Gv+8Kqp5d8ZSAzt5wKyHRuEDBDGTxdM6H5NkWafBIY3dDJB3Dg5TnMI5YHM38G Subject: Re: [rtcweb] Call for Consensus Regarding Selecting Recommended 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, 17 Jan 2013 15:27:45 -0000 --047d7bfcf91abada1104d37da2a1 Content-Type: text/plain; charset=ISO-8859-1 I guess I will continue to contribute to hole digging... This question is to web browser implementers which are present on the list: Can you tell us if you are planning to include G.722 in the WebRTC browser releases? If not, then for what reason? Regards, _____________ Roman Shpount --047d7bfcf91abada1104d37da2a1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I guess I will continue to contribute to hole digging...

This questi= on is to web browser implementers which are present on the list: Can you te= ll us if you are planning to include G.722 in the WebRTC browser releases? = If not, then for what reason?

Regards,
_____________
Roman Shpount

--047d7bfcf91abada1104d37da2a1-- From markybox@gmail.com Thu Jan 17 07:59:46 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E196721F86CD for ; Thu, 17 Jan 2013 07:59:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.284 X-Spam-Level: X-Spam-Status: No, score=-3.284 tagged_above=-999 required=5 tests=[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 GmhM1hTdNbpU for ; Thu, 17 Jan 2013 07:59:46 -0800 (PST) Received: from mail-bk0-f42.google.com (mail-bk0-f42.google.com [209.85.214.42]) by ietfa.amsl.com (Postfix) with ESMTP id 21DE321F85AE for ; Thu, 17 Jan 2013 07:59:45 -0800 (PST) Received: by mail-bk0-f42.google.com with SMTP id ji2so1463906bkc.29 for ; Thu, 17 Jan 2013 07:59:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=R/XP2Lyt8xY6KpF1lDiRTy2c/c5VUKeC44bsQEduMfw=; b=MzyavVjWbbo+Jo2JQHgmwd+YLAdbQO/UmiSv+R6+toBQbdE8LoAP9xun//SmXw4bv4 6VrpWd+w2s3p2Ax0EaBO+X1Zv37Ombo38BqGmI9675DYWw8b4UdhKeG6C3YJZb/szaD7 4IlTeNmsRrjvrDQwS/iznxIakwpd/wwnexPmZNvQ1JNRHNlFvggUuz6FBSSNyUSBcF7H wHcBpwaNUgg6Rmog0hn8S/L1g8Cjx4JFS4A0rp+3NjkfK9C+sd75lvGXjB/oyVcr7xc1 pCyxt2U030b3yLurUwGx7+NBEUbX4Ydb7pwf/l3tas6UQjYD6l1VVy5cwDZGhW8XsjVp FqHw== X-Received: by 10.204.147.85 with SMTP id k21mr1676780bkv.24.1358438385188; Thu, 17 Jan 2013 07:59:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.205.80.15 with HTTP; Thu, 17 Jan 2013 07:59:25 -0800 (PST) In-Reply-To: <24103_1358435764_50F815B4_24103_9252_1_2842AD9A45C83B44B57635FD4831E60A076013@PEXCVZYM14.corporate.adroot.infra.ftgroup> References: <50D2CC6A.4090500@ericsson.com> <24103_1358435764_50F815B4_24103_9252_1_2842AD9A45C83B44B57635FD4831E60A076013@PEXCVZYM14.corporate.adroot.infra.ftgroup> From: Mark Rejhon Date: Thu, 17 Jan 2013 10:59:25 -0500 Message-ID: To: "rtcweb@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [rtcweb] Call for Consensus Regarding Selecting Recommended 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, 17 Jan 2013 15:59:47 -0000 On Thu, Jan 17, 2013 at 10:16 AM, wrote: > Strictly sticking to the current situation with only OPUS and G.711 will = not solve properly the issue especially because this would mean to fail to = address correctly the biggest market of hundreds of millions of mobiles ter= minals that currently support neither G.711 nor OPUS. I have a suggestion, from the perspective of an outsider (mainly due to real-time text). There's a way to call AMR "OPTIONAL", while automatically making it almost "REQUIRED"!!! This is accomplished by using "SHOULD" from a different perspective. -- This is a better direction for IPR solution -- This is a better direction for long term (codecs become obsolete, new codecs become available). ***** STAGE 1 ***** "Implementors SHOULD include codecs (that are otherwise OPTIONAL) if they are already provided on the platform that the implementation runs on. For example, a mobile phone implementation would likely have easy access to AMR codecs, and therefore SHOULD implement these codecs on this platform. This also anticipate that available codecs are always evolving, including future codecs not yet developed at this time of writing." (not final wording, but you get the spirit) ***** STAGE 2 ***** Now that mobile WebKit browsers would tend to standardize WebRTC on including access to the device's own built-in AMR codecs. These mobile Webkit implementations start calling everybody else who has WebRTC. This can provide incentive for implementers on non-mobile platforms (who wish to maximize interoperability without transcoding issues and degradation concerns) to add AMR -- they now have an economic incentive as a result of the indirect "SHOULD" in STAGE 1. They can either live with the disadvantages of the standard codecs, or live with the advantages of native AMR support (at least while AMR is still popular, and become obsoleted by other codecs in newer phones, and the cycle starts over again). ***** BOTTOM LINE ***** -- We've effectively mandated a "SHOULD", while dodging the IPR issues. -- We've effectively future-proofed ourselves -- We've provided proper incentive -- We still at least make interop possible to at least say "hello" to someone, making only a couple codecs REQUIRED Sincerely, Mark Rejhon From markybox@gmail.com Thu Jan 17 08:13:59 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B972D21F8512 for ; Thu, 17 Jan 2013 08:13:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.442 X-Spam-Level: X-Spam-Status: No, score=-3.442 tagged_above=-999 required=5 tests=[AWL=0.158, 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 BEBxNhcyXVZg for ; Thu, 17 Jan 2013 08:13:58 -0800 (PST) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by ietfa.amsl.com (Postfix) with ESMTP id 9906721F8554 for ; Thu, 17 Jan 2013 08:13:58 -0800 (PST) Received: by mail-bk0-f54.google.com with SMTP id je9so1489034bkc.13 for ; Thu, 17 Jan 2013 08:13:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:content-type; bh=/X62ja4YW3qa72UeAvzdeHsOq2jrKMY7z7dRoJT6ghc=; b=Sx7cyR31phCNtmR1WQML9HitMxzPE+2GKl72aD1EBikeVHga1N5/Ia4EUHVs1LKKti rUK/Ulhbku+CrzxH5BH3R9y+RpsFip6kgNQcPuy4bB045fHCYELVEa4V7KD5bPN/9dBX PRb+TMbbhdcpkcCHrgd2Azo1plOXapqgFTLjGnp52N02lZkeAJ8uQcfNEniL11u8uWiW AepxHfVWRcTfVxiLb5QCT/sh9zDW/F4lIHevpmmfBcoRT+E2kF7FAPyZ5M4DCjDs7wTT XG39t5b032DfDzFN4xiGUP6MbSjeC0lm8DII/Vv+fIi5+F7poAtu7lbbXJtBPQGY+nmf r/9Q== X-Received: by 10.204.157.26 with SMTP id z26mr1707208bkw.101.1358439234731; Thu, 17 Jan 2013 08:13:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.205.80.15 with HTTP; Thu, 17 Jan 2013 08:13:34 -0800 (PST) In-Reply-To: References: <50D2CC6A.4090500@ericsson.com> <24103_1358435764_50F815B4_24103_9252_1_2842AD9A45C83B44B57635FD4831E60A076013@PEXCVZYM14.corporate.adroot.infra.ftgroup> From: Mark Rejhon Date: Thu, 17 Jan 2013 11:13:34 -0500 Message-ID: To: "rtcweb@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [rtcweb] Call for Consensus Regarding Selecting Recommended 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, 17 Jan 2013 16:13:59 -0000 > ***** STAGE 1 ***** > > "Implementors SHOULD include codecs (that are otherwise OPTIONAL) if > they are already provided on the platform that the implementation runs > on. For example, a mobile phone implementation would likely have easy > access to AMR codecs, and therefore SHOULD implement these codecs on > this platform. This also anticipate that available codecs are always > evolving, including future codecs not yet developed at this time of > writing." > (not final wording, but you get the spirit) Precedent: Mozilla's support of H.264 on platforms that have hardware H.264 built in. -- We remember how Mozilla is famously against IPR-encumbered codecs, but they've managed to find a way to support it while satisfying most of the issues. It is not a 100% solution, but lessons from the HTML5
= --=_0005d53d-c407-44ac-99da-4e49f5153088-- From prvs=97290e39eb=aallen@rim.com Thu Jan 17 10:17:06 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5384121F8839 for ; Thu, 17 Jan 2013 10:17:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.208 X-Spam-Level: X-Spam-Status: No, score=-6.208 tagged_above=-999 required=5 tests=[AWL=0.995, BAYES_00=-2.599, GB_I_LETTER=-2, MIME_QP_LONG_LINE=1.396, 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 qCjhJ9+epJvQ for ; Thu, 17 Jan 2013 10:17:02 -0800 (PST) Received: from mhs060cnc.rim.net (mhs060cnc.rim.net [208.65.73.34]) by ietfa.amsl.com (Postfix) with ESMTP id D53A421F8830 for ; Thu, 17 Jan 2013 10:17:01 -0800 (PST) X-AuditID: 0a41282f-b7f8c6d000004b29-14-50f84011e265 Received: from XCT104ADS.rim.net (xct104ads.rim.net [10.67.111.45]) by mhs060cnc.rim.net (SBG) with SMTP id DD.99.19241.11048F05; Thu, 17 Jan 2013 12:16:49 -0600 (CST) Received: from XMB104ADS.rim.net ([fe80::2494:a63d:e3:723b]) by XCT104ADS.rim.net ([fe80::90f9:3b89:1d94:aa9b%22]) with mapi id 14.02.0318.001; Thu, 17 Jan 2013 12:16:48 -0600 From: Andrew Allen To: "uwe.rauschenbach@nsn.com" , "radhika.r.roy.civ@mail.mil" , "roman@telurix.com" , "martin.thomson@gmail.com" Thread-Topic: [rtcweb] Consensus vs. Voting (was Re: Call for Consensus Regarding Selecting Recommended Audio Codecs) (UNCLASSIFIED) Thread-Index: AQHN9Kv2LO2vpjF/Sk2uonpkHFQeHZhNehuxgAADuOCAAFZ1+A== Date: Thu, 17 Jan 2013 18:16:48 +0000 Message-ID: In-Reply-To: <7CBFD4609D19C043A4AC4FD8381C6E26023CF7B3@DEMUEXC014.nsn-intra.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.67.110.253] Content-Type: text/plain; charset="iso-8859-1" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrCKsWRmVeSWpSXmKPExsXC5Zyvqyvo8CPA4MZLaYtrZ/4xWqxq/cVu MePCVGaLtf/a2S3uHp7D7MDqsXPWXXaPJUt+Mnmsv/+e0ePn+qvsHremFASwRjUw2iQllpQF Z6bn6dvZJObl5ZcklqQqpKQWJ9sq+aSmJ+YoBBRlliUmVyq4ZBYn5yRm5qYWKSlkptgqmSgp FOQkJqfmpuaV2ColFhSk5qUo2XEpYAAboLLMPIXUvOT8lMy8dFslz2B/XQsLU0tdQyU73YRO noyF57uYC76aViw549fA+Ey7i5GTQ0LAROL1y2vsELaYxIV769m6GLk4hARWMkr83TeVGSQh JLCZUeLz33AQm01AWWL57xmMIEUiArcYJdavOQ3WzSygLnFn8Tl2kISwQCujxJW+LUwQVW2M Em/3z2AFqRIRcJJ4e6aHEcRmEVCV6PrWC7aCV8BD4uj1GSwgNqdAgMSivmlgUxmBbvp+ag0T xAZxiVtP5jNB3CogsWTPeWYIW1Ti5eN/rBC2osTfvd9ZIer1JG5MncIGYWtLLFv4GmqXoMTJ mU9YJjCKzkIydhaSlllIWmYhaVnAyLKKUTA3o9jAzCA5L1mvKDNXLy+1ZBMjKJk4aujvYHz7 3uIQowAHoxIP7yHzHwFCrIllxZW5hxglOJiVRHhfsQCFeFMSK6tSi/Lji0pzUosPMboCQ2Ii sxR3cj4w0eWVxBsbGODmKInzSvZeDhASSAcmoOzU1ILUIpg5TBycIHu4pESKgWkktSixtCQj HpTs4ouB6U6qgZGxIuf6udD+M7MyVjee9K2etNXoF2/ikesJDn8tZ2Snruady5rxgrPz0Zpt N7w3rtN4KCznx6pzljmk8M2nTxbd+Xsr8k+LuSbFyLsmPD79Qy3ljKKsjVOz/Pld2zM8JHzE I/keXWhRu7RmvxPHAw7f6fMCJq2fbh581d186YYtkwRZWVykFJRYijMSDbWYi4oTAViMwtFn AwAA Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Consensus vs. Voting (was Re: Call for Consensus Regarding Selecting Recommended Audio Codecs) (UNCLASSIFIED) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 17 Jan 2013 18:17:06 -0000 G.711 allows interoperability with the PSTN. ----- Original Message ----- From: Rauschenbach, Uwe (NSN - DE/Munich) [mailto:uwe.rauschenbach@nsn.com] Sent: Thursday, January 17, 2013 07:16 AM Central Standard Time=0A= To: Andrew Allen; radhika.r.roy.civ@mail.mil ; r= oman@telurix.com ; martin.thomson@gmail.com Cc: rtcweb@ietf.org Subject: RE: [rtcweb] Consensus vs. Voting (was Re: Call for Consensus Regar= ding Selecting Recommended Audio Codecs) (UNCLASSIFIED) > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > Behalf Of ext Andrew Allen > > Since almost every computing platform has a browser (including most > mobile phones) within a few years every computing platform will have > RTCweb and OPUS so the need for high fidelity legacy codec > interoperability will I think become a mute point. > This is not the point. The use case is to enable a user of an RTCWeb service to reach another user via the legacy telephone network, be it mobile or fixed. The fact whether or not the browser on the mobile phone is capable of RTCWeb is of no relevance for this use case, because it may well be that the two call parties use different RTCWeb services with no interconnection, and the only way to reach each other is via the telephone network. Kind regards, Uwe > ----- Original Message ----- > From: Roy, Radhika R CIV USARMY (US) > [mailto:radhika.r.roy.civ@mail.mil] > Sent: Thursday, January 17, 2013 06:13 AM Central Standard Time > To: Roman Shpount ; Martin Thomson > > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] Consensus vs. Voting (was Re: Call for Consensus > Regarding Selecting Recommended Audio Codecs) (UNCLASSIFIED) > > Classification: UNCLASSIFIED > Caveats: NONE > > Hi, all: > > A good assessment - thanks to Roman. > > So, the transcoding cost is enormous from both performance and HW/SW > implementation point of view. > > In the end it may so appear that we are not hearing each other. > > BR/Radhika > > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > Behalf Of > Roman Shpount > Sent: Thursday, January 17, 2013 5:32 AM > To: Martin Thomson > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] Consensus vs. Voting (was Re: Call for Consensus > Regarding Selecting Recommended Audio Codecs) > > > On Wed, Jan 16, 2013 at 7:03 PM, Martin Thomson > > wrote: > > > If we don't say "webrtc implementations SHOULD implement > G.722/AMR/AMR-WB", what is the failure mode for your application? > Keeping in mind that - because this isn't 2119 MUST - you have to > expect that some non-negligible proportion of clients will not > support > this no matter how much extra ink we using in printing large > letters, > how much pain does this really cause you? > > I expect that the transcoding costs are what this come down to. > Does > anyone care to quantify this? > > > If common codecs are not implemented in the browser this would mean > transcoding will need to be performed on some sort of server-side media > gateway. There are three distinct issues we need to take into account > when > dealing with transcoding. I would list them in what, at least from my > point > of view, is the order of importance: > > 1. If you need to do trancoding, you will need to implement a jitter > buffer > on the transcoding media gateway. ICE processing and SRTP en/decoding > can be > performed on out of order packets as they are received. You cannot > transcode > out of order audio. This means audio packets would need to be delayed > by the > jitter buffer size. In cases of good internet connection this means 40 > ms > jitter buffer delay. In cases of consumer internet in US (somebody > sitting > on a DSL connection at home behind a WiFi router) you are typically > looking > at 60-80 ms jitter buffer delay. If you are dealing with international > internet connections jitter of 150 ms to 200 ms is not unheard of. This > means an additional delay due to jitter buffering of 40 ms (best case) > to > 200 ms. This is in addition to any other delays that are already > present on > the audio path. Adding an extra 100 ms of delay can make audio > conversions > very awkward or unusable. On the other hand, if the gateway were > performing > just ICE and SRTP, it would introduce 1-2 ms of delay at most (In this > case > I am talking about a software based implementation running on generic > server > hardware. A dedicated DSP solution would probably be even faster). > > 2. Audio artifacts due to transcoding. Apart from usual audio > degradation > due to transcoding (OPUS transcoded to AMR would sound worse then OPUS > or > AMR), we would also deal with double packet loss concealment. Media > gateway > will conceal lost packets when transcoding. Client will conceal lost > packet > received from the gateway. This would actually sound worse then PLC > performed in one place. > > 3. Scalability of the transcoding gateway. Gateway which just deals > with ICE > processing and SRTP en/decoding can handle from 2000 to 10000 > concurrent > call when running on a generic server CPU (different scalability is due > to > differences in CPU performance and presence of AES specific > instructions). > Gateway that would do G.722 to OPUS transcoding would most likely > handle > from 500 to 1000 concurrent calls. We are looking at 10x difference in > performance. If we need to transcode AMR to OPUS the difference would > be > even higher. This translates in 10x difference in hardware, data > center, > power, and operations costs. > > _____________ > Roman Shpount > > Classification: UNCLASSIFIED > Caveats: NONE > > > > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential > information, privileged material (including material protected by the > solicitor-client or other applicable privileges), or constitute non- > public information. Any use of this information by anyone other than > the intended recipient is prohibited. If you have received this > transmission in error, please immediately reply to the sender and > delete this information from your system. Use, dissemination, > distribution, or reproduction of this transmission by unintended > recipients is not authorized and may be unlawful. > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From adam@nostrum.com Thu Jan 17 11:07:21 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43CA621F8634 for ; Thu, 17 Jan 2013 11:07:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.527 X-Spam-Level: X-Spam-Status: No, score=-102.527 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, SPF_PASS=-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 tKiOW8HXAlyn for ; Thu, 17 Jan 2013 11:07:18 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 9536721F8587 for ; Thu, 17 Jan 2013 11:07:17 -0800 (PST) Received: from Orochi.local (99-152-144-32.lightspeed.dllstx.sbcglobal.net [99.152.144.32]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r0HJ7Esj090744 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 17 Jan 2013 13:07:14 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <50F84BE1.1010404@nostrum.com> Date: Thu, 17 Jan 2013 13:07:13 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Steve Sokol References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 99.152.144.32 is authenticated by a trusted mechanism) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Call for Consensus Regarding Selecting Recommended 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, 17 Jan 2013 19:07:21 -0000 On 1/17/13 12:00, Steve Sokol wrote: > > While it is not an optimal "internet codec", it costs nothing to to > include G.722, so perhaps we can all agree that it should be included > unless there is some reason not to do so. > By which you mean it adds nothing to the licensing cost. Integration, testing, and perpetual maintenance are not free. /a From ssokol@digium.com Thu Jan 17 11:23:06 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FD9A21F8767 for ; Thu, 17 Jan 2013 11:23:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[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 BaZ+pZeLj3UZ for ; Thu, 17 Jan 2013 11:23:06 -0800 (PST) Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by ietfa.amsl.com (Postfix) with ESMTP id 2D35F21F8754 for ; Thu, 17 Jan 2013 11:23:06 -0800 (PST) Received: from [10.24.55.203] (helo=zimbra.hsv.digium.com) by mail.digium.com with esmtp (Exim 4.69) (envelope-from ) id 1Tvv3J-00007r-AJ; Thu, 17 Jan 2013 13:23:05 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.hsv.digium.com (Postfix) with ESMTP id 4FD59D8881; Thu, 17 Jan 2013 13:23:05 -0600 (CST) 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 km9A2mJXQ4dy; Thu, 17 Jan 2013 13:23:05 -0600 (CST) Received: from zimbra.hsv.digium.com (zimbra.hsv.digium.com [10.24.55.203]) by zimbra.hsv.digium.com (Postfix) with ESMTP id 0D6CAD887B; Thu, 17 Jan 2013 13:23:05 -0600 (CST) Date: Thu, 17 Jan 2013 13:23:05 -0600 (CST) From: Steve Sokol To: Adam Roach Message-ID: In-Reply-To: <50F84BE1.1010404@nostrum.com> Content-Type: multipart/alternative; boundary="=_03015df1-d51a-4d42-9bc6-3c6c8aac1db7" MIME-Version: 1.0 X-Mailer: Zimbra 7.1.3_GA_3346 (ZimbraWebClient - GC25 (Mac)/7.1.3_GA_3346) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Call for Consensus Regarding Selecting Recommended 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, 17 Jan 2013 19:23:06 -0000 --=_03015df1-d51a-4d42-9bc6-3c6c8aac1db7 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit > By which you mean it adds nothing to the licensing cost. Integration, > testing, and perpetual maintenance are not free. > /a Agreed. --=_03015df1-d51a-4d42-9bc6-3c6c8aac1db7 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

By which you mean it adds nothing to the licensing cost. Integration,
testing, and perpetual maintenance are not free.

/a
Agreed.
--=_03015df1-d51a-4d42-9bc6-3c6c8aac1db7-- From eburger@standardstrack.com Thu Jan 17 16:06:30 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD54821F8895 for ; Thu, 17 Jan 2013 16:06:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.142 X-Spam-Level: X-Spam-Status: No, score=-101.142 tagged_above=-999 required=5 tests=[AWL=1.142, BAYES_00=-2.599, SARE_MILLIONSOF=0.315, 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 kqyxjniNdQgU for ; Thu, 17 Jan 2013 16:06:27 -0800 (PST) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.15]) by ietfa.amsl.com (Postfix) with ESMTP id 34CB821F8A0D for ; Thu, 17 Jan 2013 16:06:27 -0800 (PST) Received: from ip68-100-199-8.dc.dc.cox.net ([68.100.199.8]:62524 helo=[192.168.15.177]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1TvzTV-00038B-HM; Thu, 17 Jan 2013 16:06:25 -0800 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Eric Burger In-Reply-To: <24103_1358435764_50F815B4_24103_9252_1_2842AD9A45C83B44B57635FD4831E60A076013@PEXCVZYM14.corporate.adroot.infra.ftgroup> Date: Thu, 17 Jan 2013 19:06:24 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <50D2CC6A.4090500@ericsson.com> <24103_1358435764_50F815B4_24103_9252_1_2842AD9A45C83B44B57635FD4831E60A076013@PEXCVZYM14.corporate.adroot.infra.ftgroup> To: stephane.proust@orange.com X-Mailer: Apple Mail (2.1499) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Source: X-Source-Args: X-Source-Dir: Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Call for Consensus Regarding Selecting Recommended 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, 18 Jan 2013 00:06:30 -0000 So this says that hundreds of millions of mobile telephones do not = support SIP, either. Therefore, should we care if we do not support this = proprietary network? I don't. On Jan 17, 2013, at 10:16 AM, stephane.proust@orange.com wrote: > Strictly sticking to the current situation with only OPUS and G.711 = will not solve properly the issue especially because this would mean to = fail to address correctly the biggest market of hundreds of millions of = mobiles terminals that currently support neither G.711 nor OPUS.=20 From eburger@cs.georgetown.edu Thu Jan 17 16:07:23 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF9CE21F8AA6 for ; Thu, 17 Jan 2013 16:07:23 -0800 (PST) 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=-1.001, 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 35o1vkvMVuft for ; Thu, 17 Jan 2013 16:07:23 -0800 (PST) Received: from karma.cs.georgetown.edu (karma.cs.georgetown.edu [141.161.20.3]) by ietfa.amsl.com (Postfix) with ESMTP id 4385F21F8AA3 for ; Thu, 17 Jan 2013 16:07:23 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by karma.cs.georgetown.edu (Postfix) with ESMTP id BCAB742DA7 for ; Thu, 17 Jan 2013 19:07:22 -0500 (EST) X-Virus-Scanned: by amavisd-new at cs.georgetown.edu Received: from karma.cs.georgetown.edu ([127.0.0.1]) by localhost (karma.cs.georgetown.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q8dY-+9EXZEv for ; Thu, 17 Jan 2013 19:07:20 -0500 (EST) Received: from [192.168.15.177] (ip68-100-199-8.dc.dc.cox.net [68.100.199.8]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by karma.cs.georgetown.edu (Postfix) with ESMTP id ADFB342D16 for ; Thu, 17 Jan 2013 19:07:20 -0500 (EST) From: Burger Eric Content-Type: multipart/alternative; boundary="Apple-Mail=_F7D3F4F5-B4C7-4462-9556-587A4BA0D00F" Message-Id: <5340780E-47E2-4213-865E-8EA02678A3F5@cs.georgetown.edu> Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Date: Thu, 17 Jan 2013 19:07:20 -0500 References: To: "rtcweb@ietf.org" In-Reply-To: X-Mailer: Apple Mail (2.1499) Subject: Re: [rtcweb] Call for Consensus Regarding Selecting Recommended 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, 18 Jan 2013 00:07:23 -0000 --Apple-Mail=_F7D3F4F5-B4C7-4462-9556-587A4BA0D00F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Note that "Agreed" can cost way more than the IPR from the vendor's = perspective. Just about a non-starter for anyone selling systems with = support. On Jan 17, 2013, at 2:23 PM, Steve Sokol wrote: >=20 > By which you mean it adds nothing to the licensing cost. Integration,=20= > testing, and perpetual maintenance are not free. >=20 > /a > Agreed. > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --Apple-Mail=_F7D3F4F5-B4C7-4462-9556-587A4BA0D00F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Note that "Agreed" can cost way = more than the IPR from the vendor's perspective. Just about a = non-starter for anyone selling systems with = support.

On Jan 17, 2013, at 2:23 PM, Steve Sokol = <ssokol@digium.com> = wrote:


By which you mean it adds nothing to = the licensing cost. Integration, 
testing, and perpetual = maintenance are not free.

/a
Agreed.
To: Adam Roach , Steve Sokol Date: Fri, 18 Jan 2013 01:11:47 +0100 Thread-Topic: [rtcweb] Call for Consensus Regarding Selecting Recommended Audio Codecs Thread-Index: Ac305ehAhPq/Fn1tRTqthNkDXj3jeAAKlk6A Message-ID: References: <50F84BE1.1010404@nostrum.com> In-Reply-To: <50F84BE1.1010404@nostrum.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-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Call for Consensus Regarding Selecting Recommended 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, 18 Jan 2013 00:12:03 -0000 Integration, testing, and perpetual maintenance have absolutely nothing to = do with the IPR question. I don't see any mention of any of Integration,=20 testing, and perpetual maintenance in any of the statements about WG respon= sibilities in IPR. You are adopting the policy of saying everything you input is relevant to t= he argument and everything anybody else says in irrelevant. Regards Keith > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf > Of Adam Roach > Sent: 17 January 2013 19:07 > To: Steve Sokol > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] Call for Consensus Regarding Selecting Recommended > Audio Codecs >=20 > On 1/17/13 12:00, Steve Sokol wrote: > > > > While it is not an optimal "internet codec", it costs nothing to to > > include G.722, so perhaps we can all agree that it should be included > > unless there is some reason not to do so. > > >=20 > By which you mean it adds nothing to the licensing cost. Integration, > testing, and perpetual maintenance are not free. >=20 > /a > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From martin.thomson@gmail.com Thu Jan 17 16:25:07 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E81A21F8972 for ; Thu, 17 Jan 2013 16:25:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.199 X-Spam-Level: X-Spam-Status: No, score=-5.199 tagged_above=-999 required=5 tests=[AWL=-1.600, 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 Po7WAt4wicRH for ; Thu, 17 Jan 2013 16:25:06 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id F2F0921F8955 for ; Thu, 17 Jan 2013 16:25:05 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id n8so538711lbj.3 for ; Thu, 17 Jan 2013 16:25:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=UTL6h1XBoF1b7XSkE7cKoha+zPCNUvv962JKu555Mto=; b=GbZyzDzmC8T1MtRas6GNsqERDxbJa68gGXKSmAqdfnmtBzE8ckxhuQ3zdkw5FlxyLL ltKWkPL84LUUXVmmZsPAgswWUwXDcDPNbc2EUHHslFq0FmoFsZFjPPgOVfB1XBMHsgRW TePlt4rZP19OK1xkHHPsw248jamdEC6dHdk+04nDeEDLvFh1507oQ0cq0mcpET1T7RTv X2n6USHBWXFkbNNxaaQdhDLTTzIsDg1DcvvZA2ELzrvGxFo9XzWAO4NVhxsWp1orzaTg 440eYeMn9hxgG4kDnPc24X2CB+WjxnAl6oSUOiQUFRNp38pfZkSYgbA0fGM61p2EQ5Va 8Hbg== MIME-Version: 1.0 X-Received: by 10.152.124.226 with SMTP id ml2mr6530907lab.46.1358468704755; Thu, 17 Jan 2013 16:25:04 -0800 (PST) Received: by 10.112.57.20 with HTTP; Thu, 17 Jan 2013 16:25:04 -0800 (PST) In-Reply-To: References: <50F84BE1.1010404@nostrum.com> Date: Thu, 17 Jan 2013 16:25:04 -0800 Message-ID: From: Martin Thomson To: "DRAGE, Keith (Keith)" Content-Type: text/plain; charset=UTF-8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Call for Consensus Regarding Selecting Recommended 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, 18 Jan 2013 00:25:07 -0000 On 17 January 2013 16:11, DRAGE, Keith (Keith) wrote: > Integration, testing, and perpetual maintenance have absolutely nothing to do with the IPR question. I wasn't aware that this was a decision that relied solely on IPR concerns, only that IPR concerns were relevant (even if they are less relevant for SHOULD/should than for MUST). > You are adopting the policy of saying everything you input is relevant to the argument and everything anybody else says in irrelevant. So what? That seems to be fairly common in this forum. In fairness, I don't think that Adam is making such a blanket statement, only that certain key points are irrelevant. For instance, the the cost of transcoding (in quality and $$) seems relevant. However, given that it doesn't result in interoperability failure, the argument Adam puts forward is that this line of argument and all other "wouldn't it be nice" arguments aren't especially convincing. That doesn't invalidate other lines of argument based on cost to implementers. From prvs=1730224c61=aallen@rim.com Thu Jan 17 16:32:56 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16CF721F86C8 for ; Thu, 17 Jan 2013 16:32:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.35 X-Spam-Level: X-Spam-Status: No, score=-5.35 tagged_above=-999 required=5 tests=[AWL=-0.147, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 ihP7JnuGI+10 for ; Thu, 17 Jan 2013 16:32:55 -0800 (PST) Received: from mhs060cnc.rim.net (mhs060cnc.rim.net [208.65.73.34]) by ietfa.amsl.com (Postfix) with ESMTP id 2939921F8667 for ; Thu, 17 Jan 2013 16:32:55 -0800 (PST) X-AuditID: 0a41282f-b7f8c6d000004b29-12-50f8982f319e Received: from XCT103ADS.rim.net (xct103ads.rim.net [10.67.111.44]) by mhs060cnc.rim.net (SBG) with SMTP id 1E.73.19241.F2898F05; Thu, 17 Jan 2013 18:32:47 -0600 (CST) Received: from XMB104ADS.rim.net ([fe80::2494:a63d:e3:723b]) by XCT103ADS.rim.net ([fe80::c8f6:ae2e:c42b:3614%21]) with mapi id 14.02.0318.001; Thu, 17 Jan 2013 18:32:46 -0600 From: Andrew Allen To: "DRAGE, Keith (Keith)" , Adam Roach , Steve Sokol Thread-Topic: [rtcweb] Call for Consensus Regarding Selecting Recommended Audio Codecs Thread-Index: AQHN9RB0oSCotGod0UC2ZdQqv/8CMZhOOm0w Date: Fri, 18 Jan 2013 00:32:46 +0000 Message-ID: References: <50F84BE1.1010404@nostrum.com> In-Reply-To: Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.67.110.254] Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrKKsWRmVeSWpSXmKPExsXC5Zyvo6s/40eAwbHzEhZ7/i5it3jaeJbR Yu2/dnaLb1e/sTiweLQ+28vqcaF7GZPHkiU/mTxm7XzCEsAS1cBok5RYUhacmZ6nb2eTmJeX X5JYkqqQklqcbKvkk5qemKMQUJRZlphcqeCSWZyck5iZm1qkpJCZYqtkoqRQkJOYnJqbmldi q5RYUJCal6Jkx6WAAWyAyjLzFFLzkvNTMvPSbZU8g/11LSxMLXUNlex0Ezp5MqYfmcBa8Eew YuELoQbGW3xdjJwcEgImErN+bmCGsMUkLtxbz9bFyMUhJLCSUaLp5Wx2kISQwGZGib875EBs NgFlieW/ZzCC2CICtRKX9n5jBbGZBdQl7iw+B1YvLBAucXzfdFaImgiJWztmskDYRhKvG/rA 4iwCqhKN96+CzeEV8JA49vYwC8TiDYwSv89ANHAKJEhsufmWDcRmFJCV2H32OhPEMnGJW0/m M0FcLSCxZM95qA9EJV4+/scKYStKLDtxkg2iXkdiwe5PULa2xLKFr5khFgtKnJz5hGUCo9gs JGNnIWmZhaRlFpKWBYwsqxgFczOKDcwMkvOS9Yoyc/XyUks2MYLSiaOG/g7Gt+8tDjEKcDAq 8fAezf0RIMSaWFZcmXuIUYKDWUmEV6kMKMSbklhZlVqUH19UmpNafIjRFRgsE5mluJPzgaku ryTe2MAAN0dJnFey93KAkEA6MCllp6YWpBbBzGHi4ATZwyUlUgxMLalFiaUlGfGgBBhfDEyB Ug2MJtpRcfOuLp0WfDtj/7b7UZWyN78rp9d93P327qeW9VNSkvxM2Hdrvsu9mpVSvElGwsNg Iptw0HG+9X8mmr8XZJHv2xQT57zrmIahy26uOTIijyNfqOy5p8h2ZPe3PTf6Dvfu/NWRzLl1 mWarmoLXPoUdNQxfQ0xFu2cVxOVsSFIrz0kvOyinxFKckWioxVxUnAgAfJe0Q2gDAAA= Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Call for Consensus Regarding Selecting Recommended 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, 18 Jan 2013 00:32:56 -0000 Keith I think Adam is just saying there is no free lunch - everything has a cost. Some people have suggested that these codecs are FREE - nothing is for free. Once we achieve basic interoperability additional nice to have features (eve= n if they are perceived to be an improvement) that will involve costs to imp= lement should be determined by implementers based on their commercial merits= . In my view G.711 is enough to ensure basic interoperability with legacy cod= ecs - it's at least as good as interoperability between the PSTN and these l= egacy systems. Andrew -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= DRAGE, Keith (Keith) Sent: Thursday, January 17, 2013 7:12 PM To: Adam Roach; Steve Sokol Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Call for Consensus Regarding Selecting Recommended Aud= io Codecs Integration, testing, and perpetual maintenance have absolutely nothing to d= o with the IPR question. I don't see any mention of any of Integration, test= ing, and perpetual maintenance in any of the statements about WG responsibil= ities in IPR. You are adopting the policy of saying everything you input is relevant to th= e argument and everything anybody else says in irrelevant. Regards Keith > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > Behalf Of Adam Roach > Sent: 17 January 2013 19:07 > To: Steve Sokol > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] Call for Consensus Regarding Selecting > Recommended Audio Codecs > > On 1/17/13 12:00, Steve Sokol wrote: > > > > While it is not an optimal "internet codec", it costs nothing to to > > include G.722, so perhaps we can all agree that it should be > > included unless there is some reason not to do so. > > > > By which you mean it adds nothing to the licensing cost. Integration, > testing, and perpetual maintenance are not free. > > /a > _______________________________________________ > 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 --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From dwing@cisco.com Thu Jan 17 17:06:22 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECF2021F8AB8 for ; Thu, 17 Jan 2013 17:06:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.614 X-Spam-Level: X-Spam-Status: No, score=-109.614 tagged_above=-999 required=5 tests=[AWL=0.985, 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 wU9AWTiXTuUy for ; Thu, 17 Jan 2013 17:06:22 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 5D33C21F8AE5 for ; Thu, 17 Jan 2013 17:06:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=794; q=dns/txt; s=iport; t=1358471182; x=1359680782; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=acOxIat4V8zIOfjYzlNcbUcWB6BcS+bG5uCSBr+95pQ=; b=HOcGF29nu5jOCxQ/mh7x91/j3//amSRbz0Pt5XEfZy76imLcoCxTNeil WbTBLO8pVJdqHVlTct/vDagtMH664CB1Z/cGFgaTgzNfwsA4uQKQghGA9 UhQ4lkfSA7P1Jx5ywwJTzkcKaMq3PPiyV0AVAgFFQTYqkC2l0/yZVrQjs E=; X-IronPort-AV: E=Sophos;i="4.84,488,1355097600"; d="scan'208";a="68975808" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-4.cisco.com with ESMTP; 18 Jan 2013 01:06:19 +0000 Received: from DWINGWS01 ([10.156.17.137]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r0I16IeK014309; Fri, 18 Jan 2013 01:06:18 GMT From: "Dan Wing" To: "'Cullen Jennings \(fluffy\)'" , "'Martin Thomson'" References: <913383AAA69FF945B8F946018B75898A148E07CB@xmb-rcd-x10.cisco.com> In-Reply-To: Date: Thu, 17 Jan 2013 17:06:18 -0800 Message-ID: <06f401cdf518$05dca960$1195fc20$@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQK0kDVMRlPjz6il0gTRWhC2B04n5gFPScnnAirVttCWZT4C0A== Content-Language: en-us Cc: rtcweb@ietf.org Subject: Re: [rtcweb] New Version Notification for draft-reddy-rtcweb-mobile-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, 18 Jan 2013 01:06:23 -0000 > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf > Of Cullen Jennings (fluffy) > Sent: Wednesday, January 16, 2013 10:30 PM > To: Martin Thomson > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] New Version Notification for draft-reddy-rtcweb- > mobile-00.txt > > > On Jan 16, 2013, at 4:29 PM, Martin Thomson > wrote: > > > For example, I find the assertion that is made here, namely > > multiplexing will degrade the quality of experiences, to be specious. > > The assertion is true, but it presumes that multiplexing is or must be > > used. > > agree, to go one step further, I don't even agree that it will degrade > experience on many networks Many networks don't build queues? -d From adam@nostrum.com Thu Jan 17 20:12:02 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42E8321F8C06 for ; Thu, 17 Jan 2013 20:12:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.533 X-Spam-Level: X-Spam-Status: No, score=-102.533 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, SPF_PASS=-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 5-g4R5KPGzGQ for ; Thu, 17 Jan 2013 20:12:01 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id B508621F8C05 for ; Thu, 17 Jan 2013 20:12:01 -0800 (PST) Received: from Orochi.local (99-152-144-32.lightspeed.dllstx.sbcglobal.net [99.152.144.32]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r0I4BYUc049372 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 17 Jan 2013 22:11:35 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <50F8CB76.3070801@nostrum.com> Date: Thu, 17 Jan 2013 22:11:34 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "DRAGE, Keith (Keith)" References: <50F84BE1.1010404@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 99.152.144.32 is authenticated by a trusted mechanism) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Call for Consensus Regarding Selecting Recommended 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, 18 Jan 2013 04:12:02 -0000 Keith: I've written and discarded three rather long missives in response to your goading, but found none of them to be as concise and lucid as Martin and Andrew's responses. I'm going to let their messages stand in for my clarification, as they both get it right. /a On 1/17/13 18:11, DRAGE, Keith (Keith) wrote: > Integration, testing, and perpetual maintenance have absolutely nothing to do with the IPR question. I don't see any mention of any of Integration, > testing, and perpetual maintenance in any of the statements about WG responsibilities in IPR. > > You are adopting the policy of saying everything you input is relevant to the argument and everything anybody else says in irrelevant. > > Regards > > Keith > >> -----Original Message----- >> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf >> Of Adam Roach >> Sent: 17 January 2013 19:07 >> To: Steve Sokol >> Cc: rtcweb@ietf.org >> Subject: Re: [rtcweb] Call for Consensus Regarding Selecting Recommended >> Audio Codecs >> >> On 1/17/13 12:00, Steve Sokol wrote: >>> While it is not an optimal "internet codec", it costs nothing to to >>> include G.722, so perhaps we can all agree that it should be included >>> unless there is some reason not to do so. >>> >> By which you mean it adds nothing to the licensing cost. Integration, >> testing, and perpetual maintenance are not free. >> >> /a >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb From andrew.hutton@siemens-enterprise.com Fri Jan 18 03:31:25 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E276B21F88FB for ; Fri, 18 Jan 2013 03:31:25 -0800 (PST) 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 KnAIGbXwKYw0 for ; Fri, 18 Jan 2013 03:31:25 -0800 (PST) Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 4A75221F88B1 for ; Fri, 18 Jan 2013 03:31:25 -0800 (PST) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id ECF1E1EB84EF; Fri, 18 Jan 2013 12:31:23 +0100 (CET) Received: from MCHP04MSX.global-ad.net ([169.254.1.175]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.02.0318.001; Fri, 18 Jan 2013 12:31:23 +0100 From: "Hutton, Andrew" To: Andrew Allen , Mark Rejhon , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Call for Consensus Regarding Selecting Recommended Audio Codecs Thread-Index: AQHN9MuurLbfXCCKTkues+O2TLjeQZhNzHbQgAEnLVA= Date: Fri, 18 Jan 2013 11:31:23 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF013BD3C3@MCHP04MSX.global-ad.net> References: <50D2CC6A.4090500@ericsson.com> <24103_1358435764_50F815B4_24103_9252_1_2842AD9A45C83B44B57635FD4831E60A076013@PEXCVZYM14.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [rtcweb] Call for Consensus Regarding Selecting Recommended 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, 18 Jan 2013 11:31:26 -0000 On 17 January 2013 18:00 Andrew Allen wrote: >=20 > I would propose: : >=20 > "If other suitable audio codecs are available to the browser to use it > is recommended that they are also included in the offer in order to > maximize the possibility to establish the session without the need for > audio transcoding" >=20 > This is enough to make implementers think about the transcoding issue. >=20 I think this is a very sensible proposal as we need to say something that i= ndicates that just implementing the mandatory codec's is not the best solut= ion and it seems that mentioning particular codec's is going to be take us = down another rat hole. Andy From oej@edvina.net Fri Jan 18 04:25:35 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CABEE21F888A for ; Fri, 18 Jan 2013 04:25:35 -0800 (PST) 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 NCuODqNG-Iaf for ; Fri, 18 Jan 2013 04:25:35 -0800 (PST) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 785B621F84D8 for ; Fri, 18 Jan 2013 04:25:34 -0800 (PST) Received: from [192.168.40.11] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id BF44A754A8DC; Fri, 18 Jan 2013 12:25:33 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: "Olle E. Johansson" In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF013BD3C3@MCHP04MSX.global-ad.net> Date: Fri, 18 Jan 2013 13:25:30 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <661C13EE-261B-43ED-B75C-C1F013A02DFB@edvina.net> References: <50D2CC6A.4090500@ericsson.com> <24103_1358435764_50F815B4_24103_9252_1_2842AD9A45C83B44B57635FD4831E60A076013@PEXCVZYM14.corporate.adroot.infra.ftgroup> <9F33F40F6F2CD847824537F3C4E37DDF013BD3C3@MCHP04MSX.global-ad.net> To: "Hutton, Andrew" X-Mailer: Apple Mail (2.1499) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Call for Consensus Regarding Selecting Recommended 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, 18 Jan 2013 12:25:35 -0000 18 jan 2013 kl. 12:31 skrev "Hutton, Andrew" = : > On 17 January 2013 18:00 Andrew Allen wrote: >>=20 >> I would propose: : >>=20 >> "If other suitable audio codecs are available to the browser to use = it >> is recommended that they are also included in the offer in order to >> maximize the possibility to establish the session without the need = for >> audio transcoding" >>=20 >> This is enough to make implementers think about the transcoding = issue. >>=20 >=20 > I think this is a very sensible proposal as we need to say something = that indicates that just implementing the mandatory codec's is not the = best solution and it seems that mentioning particular codec's is going = to be take us down another rat hole. Agree fully. Not having G.722 as a mandatory codec for SIP hasn't = stopped the usage of it. /O= From magnus.westerlund@ericsson.com Fri Jan 18 08:04:32 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE69921F8884 for ; Fri, 18 Jan 2013 08:04:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.171 X-Spam-Level: X-Spam-Status: No, score=-106.171 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 a3+I4dMznYTZ for ; Fri, 18 Jan 2013 08:04:32 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id EFFC921F8880 for ; Fri, 18 Jan 2013 08:04:31 -0800 (PST) X-AuditID: c1b4fb25-b7f366d000004d10-95-50f9728e1f69 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 2D.DF.19728.E8279F05; Fri, 18 Jan 2013 17:04:31 +0100 (CET) Received: from [127.0.0.1] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.279.1; Fri, 18 Jan 2013 17:04:30 +0100 Message-ID: <50F9728E.6000206@ericsson.com> Date: Fri, 18 Jan 2013 17:04:30 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: "rtcweb@ietf.org" X-Enigmail-Version: 1.5 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrEJMWRmVeSWpSXmKPExsUyM+JvjW5/0c8Ag97J7BZr/7WzOzB6LFny kymAMYrLJiU1J7MstUjfLoEr48fvHewFP9gqrixYzNbAeJ+1i5GTQ0LARKK/o4sdwhaTuHBv PVsXIxeHkMBJRomlrxoZIZzljBLX93SAdfAKaEt8nTGTBcRmEVCV6Hx5F6ybTcBC4uaPRjYQ W1QgWGLDwVVMEPWCEidnPgGrFxFQl7j88AJYvTDQ5udb+oFsDqDN4hJr3nCAhJkF9CSmXG1h hLDlJZq3zmYGsYWA1jY0dbBOYOSfhWTqLCQts5C0LGBkXsXInpuYmZNebrSJERhOB7f8Vt3B eOecyCFGaQ4WJXHecNcLAUIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoYNzW4Zep80f1xY3HW N++nd08K3Z6dXeW4dcLdl//l/kSbr/2aMT/Re3ZMleVT8fWTS2KKatcU9ETzHe6X6V53RVWE OeLSnscrX0ySXzjNO4sx+ZSihuIiG6+FhVozjoU/fBMVe2PjlktTFjJ77pzal8m+9rHE8XVP 86r/qnPzOzw6csaY48+PZUosxRmJhlrMRcWJAIBxNYj1AQAA Subject: [rtcweb] WG Last Call: draft-ietf-rtcweb-overview-05 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 18 Jan 2013 16:04:32 -0000 WG, I would here by like to announce a two week WG last call that ends on the 1st of February. Please review this, we chairs do acknowledge that some references will be required to be updated before submitting for publication, but we do need determine if this is ready for publication and can consider it done. Document is available here: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-overview/ Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From magnus.westerlund@ericsson.com Fri Jan 18 08:06:29 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9FC521F88B5 for ; Fri, 18 Jan 2013 08:06:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.177 X-Spam-Level: X-Spam-Status: No, score=-106.177 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 bM+lwl-apuxe for ; Fri, 18 Jan 2013 08:06:29 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id D552721F8880 for ; Fri, 18 Jan 2013 08:06:28 -0800 (PST) X-AuditID: c1b4fb30-b7f0d6d000007e61-49-50f97303d65d Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id F0.CB.32353.30379F05; Fri, 18 Jan 2013 17:06:28 +0100 (CET) Received: from [127.0.0.1] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.279.1; Fri, 18 Jan 2013 17:06:27 +0100 Message-ID: <50F97303.4070906@ericsson.com> Date: Fri, 18 Jan 2013 17:06:27 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: "rtcweb@ietf.org" X-Enigmail-Version: 1.5 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrAJMWRmVeSWpSXmKPExsUyM+JvjS5L8c8Ag219TBZr/7WzOzB6LFny kymAMYrLJiU1J7MstUjfLoEr493mXSwFG1krFmzazdjAuJeli5GTQ0LAROLLzd/sELaYxIV7 69lAbCGBk4wSKxcHdDFyAdnLGSV2zrwGVMTBwSugLfHxFgdIDYuAqsSTHavB5rAJWEjc/NEI 1isqECyx4eAqJhCbV0BQ4uTMJ2A1IgLqEpcfXgDbJSzgJrFj21SwkRIC4hJr3oCNZBbQk5hy tYURwpaXaN46mxniHG2JhqYO1gmM/LOQTJ2FpGUWkpYFjMyrGNlzEzNz0svNNzECQ+nglt8G Oxg33Rc7xCjNwaIkzhvueiFASCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dUA6OpXWxawfyJ07Kb gmw3SDplr84++col6EL/2x+GM77yZvI33+gSYk/lqLwwh0NydrNAy3rmXTvzJ704/+LU0TTG p5wbpV7ZC+4Iq4hK5j7FuSHqp0mmy54fN5211O458s97uDVy8mw5K6FIx6OBfqxBOoZf7328 81Pg4MfJ62Rd/3dasGsdmaDEUpyRaKjFXFScCAD/LuH18wEAAA== Subject: [rtcweb] WG Last Call: draft-ietf-rtcweb-use-cases-and-requirements-10 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 18 Jan 2013 16:06:29 -0000 WG, I would here by like to announce a two week WG last call that ends on the 1st of February. Document is available here: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-use-cases-and-requirements/ Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From lars@netapp.com Fri Jan 18 08:19:33 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C4D321F87E7 for ; Fri, 18 Jan 2013 08:19:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.489 X-Spam-Level: X-Spam-Status: No, score=-10.489 tagged_above=-999 required=5 tests=[AWL=0.110, 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 IakrVFrG2y1T for ; Fri, 18 Jan 2013 08:19:33 -0800 (PST) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id F3CA321F8780 for ; Fri, 18 Jan 2013 08:19:32 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,493,1355126400"; d="scan'208";a="9107569" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx12-out.netapp.com with ESMTP; 18 Jan 2013 08:19:32 -0800 Received: from vmwexceht03-prd.hq.netapp.com (exchsmtp.hq.netapp.com [10.106.76.241]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r0IGJWXx005548; Fri, 18 Jan 2013 08:19:32 -0800 (PST) Received: from VMWEXCEHT06-PRD.hq.netapp.com (10.106.77.104) by vmwexceht03-prd.hq.netapp.com (10.106.76.241) with Microsoft SMTP Server (TLS) id 14.2.328.9; Fri, 18 Jan 2013 08:19:32 -0800 Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.51]) by vmwexceht06-prd.hq.netapp.com ([10.106.77.104]) with mapi id 14.02.0328.009; Fri, 18 Jan 2013 08:19:32 -0800 From: "Eggert, Lars" To: Magnus Westerlund Thread-Topic: [rtcweb] WG Last Call: draft-ietf-rtcweb-use-cases-and-requirements-10 Thread-Index: AQHN9ZXIqmZmbzAk0kq5QGnE0q62WJhPyiGA Date: Fri, 18 Jan 2013 16:19:31 +0000 Message-ID: References: <50F97303.4070906@ericsson.com> In-Reply-To: <50F97303.4070906@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.51] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <4C83F9404B15C94891F6274F391A988D@tahoe.netapp.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] WG Last Call: draft-ietf-rtcweb-use-cases-and-requirements-10 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 18 Jan 2013 16:19:33 -0000 Hi, a few quick comments: > F3 Transmitted streams and data MUST be rate > controlled. Would like to add something along the lines of "and the send rate MUST be r= educed when network congestion is detected." I guess that's implied but it = doesn't hurt to make it explicit. RMCAT will take care of this eventually, = but until then, it's the browser's job. > F5 The browser MUST be able to render good quality > audio and video even in the presence of > reasonable levels of jitter and packet losses. >=20 > TBD: What is a reasonable level? I'd suggest "a few percent." Internet protocols in general don't do well wh= en loss is higher than 10% or so. > F23 The browser must be able to send short > latency unreliable datagram traffic to a > peer browser. It may be a good idea to point to RFC5404 here, which has further guideline= s about such traffic. Lars= From lars@netapp.com Fri Jan 18 08:23:17 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43D3621F87FB for ; Fri, 18 Jan 2013 08:23:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.49 X-Spam-Level: X-Spam-Status: No, score=-10.49 tagged_above=-999 required=5 tests=[AWL=0.109, 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 cjpzyu-V6q6e for ; Fri, 18 Jan 2013 08:23:12 -0800 (PST) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by ietfa.amsl.com (Postfix) with ESMTP id 06DDB21F868B for ; Fri, 18 Jan 2013 08:23:12 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,493,1355126400"; d="scan'208";a="5226087" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 18 Jan 2013 08:23:11 -0800 Received: from vmwexceht05-prd.hq.netapp.com (vmwexceht05-prd.hq.netapp.com [10.106.77.35]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r0IGNBrq017579; Fri, 18 Jan 2013 08:23:11 -0800 (PST) Received: from VMWEXCEHT06-PRD.hq.netapp.com (10.106.77.104) by vmwexceht05-prd.hq.netapp.com (10.106.77.35) with Microsoft SMTP Server (TLS) id 14.2.328.9; Fri, 18 Jan 2013 08:23:11 -0800 Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.51]) by vmwexceht06-prd.hq.netapp.com ([10.106.77.104]) with mapi id 14.02.0328.009; Fri, 18 Jan 2013 08:23:11 -0800 From: "Eggert, Lars" To: Magnus Westerlund Thread-Topic: [rtcweb] WG Last Call: draft-ietf-rtcweb-use-cases-and-requirements-10 Thread-Index: AQHN9Zgb8QRGrgxoFUeQRf17I5FPNg== Date: Fri, 18 Jan 2013 16:23:10 +0000 Message-ID: References: <50F97303.4070906@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.51] Content-Type: text/plain; charset="us-ascii" Content-ID: <8169C6BE87DF8C4980DA194D9D19ADF9@tahoe.netapp.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] WG Last Call: draft-ietf-rtcweb-use-cases-and-requirements-10 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 18 Jan 2013 16:23:17 -0000 5405 On Jan 18, 2013, at 17:19, "Eggert, Lars" wrote: > RFC5404 From tim@phonefromhere.com Fri Jan 18 08:43:42 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E21CC21F8863 for ; Fri, 18 Jan 2013 08:43:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.392 X-Spam-Level: X-Spam-Status: No, score=-2.392 tagged_above=-999 required=5 tests=[AWL=0.207, 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 fdeWGVwTds1W for ; Fri, 18 Jan 2013 08:43:42 -0800 (PST) Received: from smtp004.apm-internet.net (smtp004.apm-internet.net [85.119.248.54]) by ietfa.amsl.com (Postfix) with ESMTP id EA36F21F884C for ; Fri, 18 Jan 2013 08:43:41 -0800 (PST) Received: (qmail 84957 invoked from network); 18 Jan 2013 16:43:39 -0000 X-AV-Scan: clean Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp004.apm-internet.net with SMTP; 18 Jan 2013 16:43:39 -0000 Received: from [192.67.4.33] (unknown [192.67.4.33]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id AE4A218A0AC2; Fri, 18 Jan 2013 16:43:39 +0000 (GMT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Tim Panton In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF013BD3C3@MCHP04MSX.global-ad.net> Date: Fri, 18 Jan 2013 16:43:38 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <50D2CC6A.4090500@ericsson.com> <24103_1358435764_50F815B4_24103_9252_1_2842AD9A45C83B44B57635FD4831E60A076013@PEXCVZYM14.corporate.adroot.infra.ftgroup> <9F33F40F6F2CD847824537F3C4E37DDF013BD3C3@MCHP04MSX.global-ad.net> To: "Hutton, Andrew" X-Mailer: Apple Mail (2.1283) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Call for Consensus Regarding Selecting Recommended 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, 18 Jan 2013 16:43:43 -0000 On 18 Jan 2013, at 11:31, Hutton, Andrew wrote: > On 17 January 2013 18:00 Andrew Allen wrote: >>=20 >> I would propose: : >>=20 >> "If other suitable audio codecs are available to the browser to use = it >> is recommended that they are also included in the offer in order to >> maximize the possibility to establish the session without the need = for >> audio transcoding" >>=20 >> This is enough to make implementers think about the transcoding = issue. >>=20 >=20 > I think this is a very sensible proposal as we need to say something = that indicates that just implementing the mandatory codec's is not the = best solution and it seems that mentioning particular codec's is going = to be take us down another rat hole. Just for clarity, lets make that=20 "If other suitable audio codecs are available to the browser to use it is beneficial that they are also included in the offer but at a lower = priority than the MTI codecs in order to maximize the possibility to establish the session without = the need for audio transcoding" Tim.= From keith.drage@alcatel-lucent.com Fri Jan 18 12:44:14 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF07A21F86D3 for ; Fri, 18 Jan 2013 12:44:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.299 X-Spam-Level: X-Spam-Status: No, score=-109.299 tagged_above=-999 required=5 tests=[AWL=0.950, 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 VlLuK3qNE5yx for ; Fri, 18 Jan 2013 12:44:14 -0800 (PST) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by ietfa.amsl.com (Postfix) with ESMTP id E9EFD21F86CA for ; Fri, 18 Jan 2013 12:44:13 -0800 (PST) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r0IKhlfV019230 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 18 Jan 2013 21:44:11 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Fri, 18 Jan 2013 21:44:06 +0100 From: "DRAGE, Keith (Keith)" To: Tim Panton , "Hutton, Andrew" Date: Fri, 18 Jan 2013 21:39:12 +0100 Thread-Topic: [rtcweb] Call for Consensus Regarding Selecting Recommended Audio Codecs Thread-Index: Ac31mwJRRF21gTrTTfSMRU4gDiJFOgAIBB0A Message-ID: References: <50D2CC6A.4090500@ericsson.com> <24103_1358435764_50F815B4_24103_9252_1_2842AD9A45C83B44B57635FD4831E60A076013@PEXCVZYM14.corporate.adroot.infra.ftgroup> <9F33F40F6F2CD847824537F3C4E37DDF013BD3C3@MCHP04MSX.global-ad.net> 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-Scanned-By: MIMEDefang 2.69 on 155.132.188.84 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Call for Consensus Regarding Selecting Recommended 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, 18 Jan 2013 20:44:14 -0000 As stated that says that any additional wideband codec should have a lower = priority than the mandatory to implement G.711. I'd also suggest that that amendment if included in no way overrides an exp= licit statement by the user of their preferences. Regard Keith > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf > Of Tim Panton > Sent: 18 January 2013 16:44 > To: Hutton, Andrew > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] Call for Consensus Regarding Selecting Recommended > Audio Codecs >=20 >=20 > On 18 Jan 2013, at 11:31, Hutton, Andrew wrote: >=20 > > On 17 January 2013 18:00 Andrew Allen wrote: > >> > >> I would propose: : > >> > >> "If other suitable audio codecs are available to the browser to use it > >> is recommended that they are also included in the offer in order to > >> maximize the possibility to establish the session without the need for > >> audio transcoding" > >> > >> This is enough to make implementers think about the transcoding issue. > >> > > > > I think this is a very sensible proposal as we need to say something > that indicates that just implementing the mandatory codec's is not the > best solution and it seems that mentioning particular codec's is going to > be take us down another rat hole. >=20 > Just for clarity, lets make that > "If other suitable audio codecs are available to the browser to use it > is beneficial that they are also included in the offer but at a lower > priority than the MTI codecs > in order to maximize the possibility to establish the session without the > need for > audio transcoding" >=20 > Tim. > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From martin.thomson@gmail.com Fri Jan 18 13:13:44 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84C6921F878F for ; Fri, 18 Jan 2013 13:13:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.474 X-Spam-Level: X-Spam-Status: No, score=-5.474 tagged_above=-999 required=5 tests=[AWL=-1.875, 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 h16v1ah90aUv for ; Fri, 18 Jan 2013 13:13:44 -0800 (PST) Received: from mail-la0-f47.google.com (mail-la0-f47.google.com [209.85.215.47]) by ietfa.amsl.com (Postfix) with ESMTP id 9845921F8788 for ; Fri, 18 Jan 2013 13:13:43 -0800 (PST) Received: by mail-la0-f47.google.com with SMTP id fh20so4373641lab.34 for ; Fri, 18 Jan 2013 13:13:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=1oDTzCQi0eyqLQXZTg3KjYiwJ5mi+wD9avwZFYEuZD8=; b=Oq/iH3UBBTd40hALEHfL1cBfCWSKgkM7KnKODGKyxWGVbCezy4BD9USROJ9FqtnYxR u40l20xlkRu/2s89JhibgFys7mN8xJSNnJ66hTxwWKuU+lSQM1XfV3v1Ouuc9ZMqJVGJ S6gNtjD3MXqZJuGVpW1srLuw8VJs1nf9hMCX5pgx3i38k+bZO0+hWuk0x+wJoBKvs88K hXcoK/gcO9NZTnEVYSFAwjrrriMF6Q1eDUv6K7SowSi6anvTUrTvfz0ShNNXZfYnE7qh Fu7rqd90W1Q0ucbnud7R5+VfVWIaxbwmWtXPYdk/9Caf/nON3DY3vvq19j59YKBA/Skd Z8fA== MIME-Version: 1.0 X-Received: by 10.152.145.8 with SMTP id sq8mr9781589lab.21.1358543622555; Fri, 18 Jan 2013 13:13:42 -0800 (PST) Received: by 10.112.57.20 with HTTP; Fri, 18 Jan 2013 13:13:42 -0800 (PST) In-Reply-To: References: <50D2CC6A.4090500@ericsson.com> <24103_1358435764_50F815B4_24103_9252_1_2842AD9A45C83B44B57635FD4831E60A076013@PEXCVZYM14.corporate.adroot.infra.ftgroup> <9F33F40F6F2CD847824537F3C4E37DDF013BD3C3@MCHP04MSX.global-ad.net> Date: Fri, 18 Jan 2013 13:13:42 -0800 Message-ID: From: Martin Thomson To: "DRAGE, Keith (Keith)" Content-Type: text/plain; charset=UTF-8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Call for Consensus Regarding Selecting Recommended 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, 18 Jan 2013 21:13:44 -0000 On 18 January 2013 12:39, DRAGE, Keith (Keith) wrote: > As stated that says that any additional wideband codec should have a lower priority than the mandatory to implement G.711. Yes. Let the implementation (or the user) make any decisions on priority. We don't need to force the negotiation of Opus, its quality should ensure that happens. From duerst@it.aoyama.ac.jp Fri Jan 18 22:31:50 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E66321F8600 for ; Fri, 18 Jan 2013 22:31:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.709 X-Spam-Level: X-Spam-Status: No, score=-104.709 tagged_above=-999 required=5 tests=[AWL=-0.919, 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PFcp8k4ePMG3 for ; Fri, 18 Jan 2013 22:31:49 -0800 (PST) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id 1531E21F87EA for ; Fri, 18 Jan 2013 22:31:48 -0800 (PST) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id r0J6VhGX028122 for ; Sat, 19 Jan 2013 15:31:43 +0900 Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 7efb_c96b_e4238436_6201_11e2_8d2c_001d096c5782; Sat, 19 Jan 2013 15:31:43 +0900 Received: from [IPv6:::1] ([133.2.210.1]:32859) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Sat, 19 Jan 2013 15:31:44 +0900 Message-ID: <50FA3DC7.9070708@it.aoyama.ac.jp> Date: Sat, 19 Jan 2013 15:31:35 +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: Tim Panton References: <50D2CC6A.4090500@ericsson.com> <24103_1358435764_50F815B4_24103_9252_1_2842AD9A45C83B44B57635FD4831E60A076013@PEXCVZYM14.corporate.adroot.infra.ftgroup> <9F33F40F6F2CD847824537F3C4E37DDF013BD3C3@MCHP04MSX.global-ad.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Call for Consensus Regarding Selecting Recommended 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, 19 Jan 2013 06:31:50 -0000 First, for the chairs: Please, please close this Call for Consensus, to avoid further email avalanches on this topic. I'd expect the chairs to potentially follow up with a more narrow call (e.g. centering on wording as below), but that's their decision of course. On 2013/01/19 1:43, Tim Panton wrote: > > On 18 Jan 2013, at 11:31, Hutton, Andrew wrote: > >> On 17 January 2013 18:00 Andrew Allen wrote: >>> >>> I would propose: : >>> >>> "If other suitable audio codecs are available to the browser to use it >>> is recommended that they are also included in the offer in order to >>> maximize the possibility to establish the session without the need for >>> audio transcoding" >>> >>> This is enough to make implementers think about the transcoding issue. >>> >> >> I think this is a very sensible proposal as we need to say something that indicates that just implementing the mandatory codec's is not the best solution and it seems that mentioning particular codec's is going to be take us down another rat hole. > > Just for clarity, lets make that > "If other suitable audio codecs are available to the browser to use it > is beneficial that they are also included in the offer but at a lower priority than the MTI codecs > in order to maximize the possibility to establish the session without the need for > audio transcoding" I was thinking about the priority issue a few days ago, and came to the conclusion that this may be too specific. Assume that I have a mobile phone with MTI codec in software and another codec in hardware, and the later is significantly more power efficient. Assume I'm talking with another user on a similar phone. Then given these assumptions, I guess we both would prefer to use our hardware codecs, but that doesn't happen if the MTI codecs have priority. So I'd leave out the priority issue, and just keep the rest of the text. Regards, Martin. From btv1==7306b30e559==HKaplan@acmepacket.com Fri Jan 18 11:33:27 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E4C821F862A for ; Fri, 18 Jan 2013 11:33:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.486 X-Spam-Level: X-Spam-Status: No, score=-2.486 tagged_above=-999 required=5 tests=[AWL=0.113, 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 Q-imER5Y+YUj for ; Fri, 18 Jan 2013 11:33:27 -0800 (PST) Received: from mx1.acmepacket.com (mx1.acmepacket.com [216.41.24.33]) by ietfa.amsl.com (Postfix) with ESMTP id C661321F8626 for ; Fri, 18 Jan 2013 11:33:26 -0800 (PST) X-ASG-Debug-ID: 1358537603-03fc200e92d8a740001-4f8tJD Received: from Mail1.acmepacket.com (mail1.acmepacket.com [10.0.0.21]) by mx1.acmepacket.com with ESMTP id ifc5lQ2tX36mIX55 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NO); Fri, 18 Jan 2013 14:33:23 -0500 (EST) X-Barracuda-Envelope-From: HKaplan@acmepacket.com Received: from MAIL2.acmepacket.com ([169.254.2.67]) by Mail1.acmepacket.com ([169.254.1.214]) with mapi id 14.02.0283.003; Fri, 18 Jan 2013 14:33:23 -0500 From: Hadriel Kaplan To: "rtcweb@ietf.org" , "public-webrtc@w3.org" , "mmusic@ietf.org (E-mail)" , "public-media-capture@w3.org" Thread-Topic: February Interim registration and logistics X-ASG-Orig-Subj: February Interim registration and logistics Thread-Index: AQHN9bKtJlsqwRqOpESjXFiKxPyc6Q== Date: Fri, 18 Jan 2013 19:33:23 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.0.0.30] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Barracuda-Connect: mail1.acmepacket.com[10.0.0.21] X-Barracuda-Start-Time: 1358537603 X-Barracuda-Encrypted: AES128-SHA X-Barracuda-URL: http://spam.acmepacket.com:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at acmepacket.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=BSF_SC0_MISMATCH_TO X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.120227 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header X-Mailman-Approved-At: Sat, 19 Jan 2013 08:26:31 -0800 Cc: "rai-ads@tools.ietf.org" , "rtcweb-chairs@tools.ietf.org" , Harald Alvestrand , "" Subject: [rtcweb] February Interim registration and logistics X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 18 Jan 2013 19:37:27 -0000 Howdy, We're pleased to host the upcoming interim meetings of IETF RTCWeb, IETF MM= USIC, W3C WebRTC and W3C Media Capture groups, on February 5-7, 2013, at ou= r Corporate Galactic Headquarters in Bedford, Massachusetts.=20 Please register at the following page if you plan to attend: http://info.acmepacket.com/acme-packet-hosting-ietf-and-w3c The logistics/venue info page is here: http://info.acmepacket.com/acme-packet-hosting-ietf-and-w3c/logistics You should NOT register if you're only going to attend remotely. Details f= or remote participation will be sent out later on the relevant mailing list= s. We hope to see you here! And bring warm clothing - it's slightly chilly. ;) -hadriel p.s. We've tested the registration page on several browsers and it works ge= nerally, except for on Lynx, Links, or Elinks. (Lynx and Links because they= don't support Javascript, but why it doesn't work on Elinks w/SpiderMonkey= I haven't looked into) The logistics page seems to work on all browsers.= =20 :) From btv1==73173e7f7d1==HKaplan@acmepacket.com Sat Jan 19 12:09:07 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC3FA21F8472 for ; Sat, 19 Jan 2013 12:09:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.518 X-Spam-Level: X-Spam-Status: No, score=-2.518 tagged_above=-999 required=5 tests=[AWL=0.081, 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 mu1lhgVP2vOB for ; Sat, 19 Jan 2013 12:09:07 -0800 (PST) Received: from mx1.acmepacket.com (mx1.acmepacket.com [216.41.24.33]) by ietfa.amsl.com (Postfix) with ESMTP id 2A88421F8449 for ; Sat, 19 Jan 2013 12:09:06 -0800 (PST) X-ASG-Debug-ID: 1358626145-03fc200e92dec920001-4f8tJD Received: from Mail1.acmepacket.com (mail1.acmepacket.com [10.0.0.21]) by mx1.acmepacket.com with ESMTP id v1ERgcNJM2rCVWdv (version=TLSv1 cipher=AES128-SHA bits=128 verify=NO); Sat, 19 Jan 2013 15:09:05 -0500 (EST) X-Barracuda-Envelope-From: HKaplan@acmepacket.com Received: from MAIL2.acmepacket.com ([169.254.2.67]) by Mail1.acmepacket.com ([169.254.1.214]) with mapi id 14.02.0283.003; Sat, 19 Jan 2013 15:09:04 -0500 From: Hadriel Kaplan To: Tim Panton Thread-Topic: [rtcweb] Call for Consensus Regarding Selecting Recommended Audio Codecs X-ASG-Orig-Subj: Re: [rtcweb] Call for Consensus Regarding Selecting Recommended Audio Codecs Thread-Index: AQHN9oDTMnJJYh519k2qtBiddTGTvQ== Date: Sat, 19 Jan 2013 20:09:03 +0000 Message-ID: <7C539609-8D49-4C81-9236-071CC077EBE8@acmepacket.com> References: <50D2CC6A.4090500@ericsson.com> <24103_1358435764_50F815B4_24103_9252_1_2842AD9A45C83B44B57635FD4831E60A076013@PEXCVZYM14.corporate.adroot.infra.ftgroup> <9F33F40F6F2CD847824537F3C4E37DDF013BD3C3@MCHP04MSX.global-ad.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [216.41.24.34] Content-Type: text/plain; charset="us-ascii" Content-ID: <690B4AF6A220A84895134BBA6EEA38B5@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Barracuda-Connect: mail1.acmepacket.com[10.0.0.21] X-Barracuda-Start-Time: 1358626145 X-Barracuda-Encrypted: AES128-SHA X-Barracuda-URL: http://spam.acmepacket.com:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at acmepacket.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.120324 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Call for Consensus Regarding Selecting Recommended 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, 19 Jan 2013 20:41:34 -0000 On Jan 18, 2013, at 11:43 AM, Tim Panton wrote: >=20 > Just for clarity, lets make that=20 > "If other suitable audio codecs are available to the browser to use it > is beneficial that they are also included in the offer but at a lower pri= ority than the MTI codecs > in order to maximize the possibility to establish the session without the= need for > audio transcoding" Umm... but then two endpoints both implementing a better non-MTI codec woul= d pick the MTI one instead of the better one. Generally you don't need to muck with the order to get transcoder-free oper= ation - as long as both sides support at least one common one, they'll pick= it if they follow the preference rules in RFC 3264. That's because the ga= teway in the middle will usually add the additional codecs it can transcode= for, later in the SDP m-line preference order (ie, make them lower prefere= nce in the offer).[1] -hadriel [1] I say "usually" because of course this is not always the case, because = sometimes they change the pref order for other reasons; nor is it the case = that gateways in the middle always add codecs for transcoding, but rather s= ometimes they let the INVITE fail first and then re-send it with additional= codecs (though that's a far less common model). From sdhesika@cisco.com Sat Jan 19 22:22:53 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D73221F84FC for ; Sat, 19 Jan 2013 22:22:53 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bZxL142KKAOK for ; Sat, 19 Jan 2013 22:22:51 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 3380C21F84F8 for ; Sat, 19 Jan 2013 22:22:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4078; q=dns/txt; s=iport; t=1358662971; x=1359872571; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=YRXe9nNmZrbKwWxq+DFrBwh1q85pexrrwXelZ1SnRXM=; b=k+hWSyCxJUX4TTCy9BW9/sM4Sf0UZ25QnnbEBwrznedOBSRMk+a0Wjod EGuJRIXYsh1ahhX8HNg0UhECf4Eu9uBLGhyTJfg8N/4VPlRz25A6MkVey LjQfJVdea0/pHvjGPHg5SzscgZgMXAjtHtnJH2HlWrPI5AkK0LCY6vk4k 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFALyM+1CtJV2d/2dsb2JhbABEvjkWc4IeAQEBBAEBATc0BgMCDAQCAQgRBAEBAQoUCQcnCxQIAQgCBAENBQgBE4d9DLsJkFhhA5cojy2CdYIk X-IronPort-AV: E=Sophos;i="4.84,500,1355097600"; d="scan'208";a="165111564" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-3.cisco.com with ESMTP; 20 Jan 2013 06:22:50 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r0K6Mo0F021662 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 20 Jan 2013 06:22:50 GMT Received: from xmb-aln-x10.cisco.com ([169.254.5.78]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0318.004; Sun, 20 Jan 2013 00:22:49 -0600 From: "Subha Dhesikan (sdhesika)" To: Martin Thomson , "Tirumaleswar Reddy (tireddy)" Thread-Topic: [rtcweb] FW: New Version Notification for draft-reddy-rtcweb-mobile-00.txt Thread-Index: AQHN8i6P0JlBJStRlku4X+YQ5S8cZZhIyWCwgAQ5d4CABMV9IA== Date: Sun, 20 Jan 2013 06:22:48 +0000 Message-ID: References: <913383AAA69FF945B8F946018B75898A148E07CB@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.19.165.182] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: John Kaippallimalil , "rtcweb@ietf.org" , "bpatil@ovi.com" Subject: Re: [rtcweb] FW: New Version Notification for draft-reddy-rtcweb-mobile-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: Sun, 20 Jan 2013 06:22:53 -0000 Inline as SD: -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= Martin Thomson Sent: Wednesday, January 16, 2013 3:29 PM To: Tirumaleswar Reddy (tireddy) Cc: John Kaippallimalil; rtcweb@ietf.org; bpatil@ovi.com Subject: Re: [rtcweb] FW: New Version Notification for draft-reddy-rtcweb-m= obile-00.txt There are many characteristics of mobile networks that make poorly designed= applications perform poorly. Honestly, WebRTC isn't special in this regar= d. I'd prefer to see something that is less negatively worded that instead= aims to improve awareness of the limitations of the network and how a well= -designed application might avoid the problems that these cause. See: http://developer.android.com/training/efficient-downloads/efficient-network= -access.html#RadioStateMachine For example, I find the assertion that is made here, namely multiplexing wi= ll degrade the quality of experiences, to be specious. The assertion is true, but it presumes that multiplexing is or must be used= . SD: the question is what assumption is made regarding DSCP values for the s= ingle UDP flow which has multiplexed RTP flows? - If the assumption is that multiple DSCP is used for the single flow, then= the document states that it does not work in the 3G network. However, the = assumption is premature at this stage as it is not a foregone conclusion. O= n the other hand with this assumption, the user experience should not degra= de because it is no different from different flows with their own DSCPs. - If the assumption is that a single DSCP for a multiplexed flow, then ther= e is a chance that the experience will degrade but then it should not be a = problem since the DSCP value in TFT for the bearer should match with the DS= CP value in the RTP packets sent by the UE.=20 However, if the mobile elements turn down the multiplexing as is suggested = by the rtcweb usage draft then either of the above scenarios ceases to exis= t. Regards, Subha --Martin On 14 January 2013 06:35, Tirumaleswar Reddy (tireddy) = wrote: > Hi all,' > > > > This document describes a set of scenarios in which WebRTC=20 > applications have problems in Mobile Networks related to QOS, Mobility=20 > (SIPTO). Thanks to Magnus, Markus, Dan and Basavraj for their help and=20 > comments. The URL of the new draft: > > > > http://tools.ietf.org/html/draft-reddy-rtcweb-mobile-00 > > > > comments and suggestions are welcome. > > > > Best Regards, > > --authors. > > > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Monday, January 14, 2013 1:40 PM > To: Tirumaleswar Reddy (tireddy) > Cc: john.kaippallimalil@huawei.com; Ram Mohan R (rmohanr) > Subject: New Version Notification for draft-reddy-rtcweb-mobile-00.txt > > > > > > A new version of I-D, draft-reddy-rtcweb-mobile-00.txt > > has been successfully submitted by Tirumaleswar Reddy and posted to=20 > the > > IETF repository. > > > > Filename: draft-reddy-rtcweb-mobile > > Revision: 00 > > Title: Problems with WebRTC in Mobile Networks > > Creation date: 2013-01-14 > > WG ID: Individual Submission > > Number of pages: 14 > > URL: > http://www.ietf.org/internet-drafts/draft-reddy-rtcweb-mobile-00.txt > > Status: http://datatracker.ietf.org/doc/draft-reddy-rtcweb-mobil= e > > Htmlized: http://tools.ietf.org/html/draft-reddy-rtcweb-mobile-00 > > > > > > Abstract: > > This document describes a set of scenarios in which WebRTC > > applications have problems in Mobile Networks. > > > > > > > > > > The IETF Secretariat > > > > > _______________________________________________ > 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 tireddy@cisco.com Sun Jan 20 02:22:28 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B810F21F8523 for ; Sun, 20 Jan 2013 02:22:28 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8R4QmVukzuvF for ; Sun, 20 Jan 2013 02:22:27 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 888AB21F8501 for ; Sun, 20 Jan 2013 02:22:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6341; q=dns/txt; s=iport; t=1358677347; x=1359886947; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=UbqqZdRWnnmEqNDknmGfKYZlKaFa06QHp5Uu/DD2tsM=; b=eKBN+5A/qy9CBAZivhwKRJWWIpRwR8RXDrknXuypdlO8/bGureXJnhKy wa+9F9oWnZ076gHs6aZwY4Hpz9w622RhLVQgkTM75e03rrdA84fWNOv6c w6rVuYw6dAdWyDHaBtQYgiVIEgQH36UXaeK/LUQJDHnhpZDhNRZiv7Yog M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFANDD+1CtJXG8/2dsb2JhbAA6Cr45FnOCHgEBAQMBAQEBNzQGAwIFBwQCAQgRBAEBAQoUCQcnCxQIAQgCBAENBQgBE4d3Bgy7E40HC4NGYQOXKI8tgnWCJA X-IronPort-AV: E=Sophos;i="4.84,500,1355097600"; d="scan'208";a="165117964" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-5.cisco.com with ESMTP; 20 Jan 2013 10:22:27 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r0KAMQbx013615 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 20 Jan 2013 10:22:26 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.229]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0318.004; Sun, 20 Jan 2013 04:22:26 -0600 From: "Tirumaleswar Reddy (tireddy)" To: "Subha Dhesikan (sdhesika)" , Martin Thomson Thread-Topic: [rtcweb] FW: New Version Notification for draft-reddy-rtcweb-mobile-00.txt Thread-Index: AQHN9taSzlaHh2ZBGEy0isZnjKvGOZhR0nwQ Date: Sun, 20 Jan 2013 10:22:25 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A148E8567@xmb-rcd-x10.cisco.com> References: <913383AAA69FF945B8F946018B75898A148E07CB@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.71.5] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: John Kaippallimalil , "rtcweb@ietf.org" , "bpatil@ovi.com" Subject: Re: [rtcweb] FW: New Version Notification for draft-reddy-rtcweb-mobile-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: Sun, 20 Jan 2013 10:22:28 -0000 Hi Subha/Martin, Thanks for the comments. Please see inline [TR]. > -----Original Message----- > From: Subha Dhesikan (sdhesika) > Sent: Sunday, January 20, 2013 11:53 AM > To: Martin Thomson; Tirumaleswar Reddy (tireddy) > Cc: John Kaippallimalil; rtcweb@ietf.org; bpatil@ovi.com > Subject: RE: [rtcweb] FW: New Version Notification for draft-reddy-rtcweb= - > mobile-00.txt >=20 > Inline as SD: >=20 > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf = Of > Martin Thomson > Sent: Wednesday, January 16, 2013 3:29 PM > To: Tirumaleswar Reddy (tireddy) > Cc: John Kaippallimalil; rtcweb@ietf.org; bpatil@ovi.com > Subject: Re: [rtcweb] FW: New Version Notification for draft-reddy-rtcweb= - > mobile-00.txt >=20 > There are many characteristics of mobile networks that make poorly design= ed > applications perform poorly. Honestly, WebRTC isn't special in this rega= rd. > I'd prefer to see something that is less negatively worded that instead a= ims > to improve awareness of the limitations of the network and how a well-des= igned > application might avoid the problems that these cause. See: > http://developer.android.com/training/efficient-downloads/efficient-netwo= rk- > access.html#RadioStateMachine >=20 > For example, I find the assertion that is made here, namely multiplexing = will > degrade the quality of experiences, to be specious. > The assertion is true, but it presumes that multiplexing is or must be us= ed. >=20 > SD: the question is what assumption is made regarding DSCP values for the > single UDP flow which has multiplexed RTP flows ? > - If the assumption is that multiple DSCP is used for the single flow, th= en > the document states that it does not work in the 3G network. However, the= assumption is premature at this stage as it is not a foregone conclusion.= =20 This is not a problem of just setting DSCP values. 3GPP uses the concept of bearer. Each bearer is associated with a QCI value= . For example if we consider a media session with Audio and video media str= eams. 3GPP has explicit QCI values for each stream :=20 [1] QCI value 1 means packet priority (2), packet delay (100ms), packet los= s (10 to the power -2) and used for Voice [2] QCI value 2 means packet priority (2), packet delay (150ms), packet los= s (10 to the power -3) and used for Video In the above scenario two bearers would be required one for audio and the o= ther for video. Each bearer would have to be associated with packet filters= (5-tuple) to identify the audio and video media streams. This needs WebRTC= application to be aware of QCI/GBR values associated with each stream. The= 3GPP network based on the available resources may or may not permit the be= arer resource modification request triggered by the UE. If the network does= not permit the bearer resource modification then it does not make any diff= erence by setting DSCP values. These QCI values are mapped by the network to relevant DSCP values. Hence w= e have recommended in the draft that Mobile devices in 3GPP network should = not prefer RTP Multiplexing. =20 > On the other hand with this assumption, the user experience should not de= grade > because it is no different from different flows with their own DSCPs. > - If the assumption is that a single DSCP for a multiplexed flow, then th= ere > is a chance that the experience will degrade but then it should not be a > problem since the DSCP value in TFT for the bearer should match with the = DSCP > value in the RTP packets sent by the UE. I did not understand your argument. Are you saying though that WebRTC appli= cation would request bearer allocation for audio or video stream only but m= ultiplex audio and video streams on the same 5-tuple ? If so please explai= n how would it work in this case ? --Tiru. >=20 > However, if the mobile elements turn down the multiplexing as is suggeste= d by > the rtcweb usage draft then either of the above scenarios ceases to exist= . > Regards, > Subha >=20 > --Martin >=20 > On 14 January 2013 06:35, Tirumaleswar Reddy (tireddy) > wrote: > > Hi all,' > > > > > > > > This document describes a set of scenarios in which WebRTC > > applications have problems in Mobile Networks related to QOS, Mobility > > (SIPTO). Thanks to Magnus, Markus, Dan and Basavraj for their help and > > comments. The URL of the new draft: > > > > > > > > http://tools.ietf.org/html/draft-reddy-rtcweb-mobile-00 > > > > > > > > comments and suggestions are welcome. > > > > > > > > Best Regards, > > > > --authors. > > > > > > > > -----Original Message----- > > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > > Sent: Monday, January 14, 2013 1:40 PM > > To: Tirumaleswar Reddy (tireddy) > > Cc: john.kaippallimalil@huawei.com; Ram Mohan R (rmohanr) > > Subject: New Version Notification for draft-reddy-rtcweb-mobile-00.txt > > > > > > > > > > > > A new version of I-D, draft-reddy-rtcweb-mobile-00.txt > > > > has been successfully submitted by Tirumaleswar Reddy and posted to > > the > > > > IETF repository. > > > > > > > > Filename: draft-reddy-rtcweb-mobile > > > > Revision: 00 > > > > Title: Problems with WebRTC in Mobile Networks > > > > Creation date: 2013-01-14 > > > > WG ID: Individual Submission > > > > Number of pages: 14 > > > > URL: > > http://www.ietf.org/internet-drafts/draft-reddy-rtcweb-mobile-00.txt > > > > Status: http://datatracker.ietf.org/doc/draft-reddy-rtcweb-mob= ile > > > > Htmlized: http://tools.ietf.org/html/draft-reddy-rtcweb-mobile-0= 0 > > > > > > > > > > > > Abstract: > > > > This document describes a set of scenarios in which WebRTC > > > > applications have problems in Mobile Networks. > > > > > > > > > > > > > > > > > > > > The IETF Secretariat > > > > > > > > > > _______________________________________________ > > 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 ron.even.tlv@gmail.com Mon Jan 21 21:52:01 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3CD721F87F3; Mon, 21 Jan 2013 21:52:01 -0800 (PST) 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 m6SW-O0MMl8h; Mon, 21 Jan 2013 21:52:00 -0800 (PST) Received: from mail-ea0-f172.google.com (mail-ea0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9882121F87EE; Mon, 21 Jan 2013 21:51:59 -0800 (PST) Received: by mail-ea0-f172.google.com with SMTP id f13so2839424eaa.3 for ; Mon, 21 Jan 2013 21:51:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-type:content-transfer-encoding :x-mailer:thread-index:content-language; bh=6cHenttU8V4siuJsLZ+k5EUcmfq3KW6DnOhb39MI1fM=; b=b4bY3hLqwEt5mMpmoD16E7HqYdFA7NCGywXK8GcDOjf2GSzZKat6R0T8IKYxxcFxpA LetwmxeQGcIv0CDoI92wQk35dRqyZId30Y1mCFoRtFrWgWbJhzr5WZ/ijYZV5DTqKlyf qay2uIKobyWkiB6M8ZQpXDY0jyjWZCc77TJqlqQ/18qhIbECLOrWxZDC6m+9UIqEJ9Ke m10g1PQHms1bl4rgw0Te4Mukz49HbsZ/qQxfwcJyIuO30/waB1BcjtyzjM+6MlhggdGN uW+Kr1QA6OasRskAlxko6RZMb8YhzPRnltSdSOGoMCEgjbFDbWk3TQmwo3rsiDNUCN3s N1ag== X-Received: by 10.14.213.134 with SMTP id a6mr69068759eep.45.1358833918716; Mon, 21 Jan 2013 21:51:58 -0800 (PST) Received: from RoniE (bzq-79-181-179-229.red.bezeqint.net. [79.181.179.229]) by mx.google.com with ESMTPS id t44sm25496694eeo.2.2013.01.21.21.51.54 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 21 Jan 2013 21:51:57 -0800 (PST) From: "Roni Even" To: "'Ted Hardie'" , , References: In-Reply-To: Date: Tue, 22 Jan 2013 07:49:04 +0200 Message-ID: <004801cdf864$325287e0$96f797a0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKCYsEIPwdLZ6w2lmT6EdTEcbci6JbsAgcg Content-Language: en-us Cc: 'Cullen Jennings' , =?ISO-8859-1?Q?'Ari_Ker=E4nen'?= Subject: Re: [rtcweb] [MMUSIC] Proposed agenda for the joint MMUSIC/RTCWEB inteirm meeting X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 22 Jan 2013 05:52:02 -0000 Hi, I am not sure what will be discussed in multiple flow SDP representation = and Mapping stream/track label concepts to SDP identifiers. Are there drafts = or is it an open discussion. What about the relation of these two topics to CLUE? Thanks Roni Even -----Original Message----- From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf = Of Ted Hardie Sent: 14 January, 2013 7:41 PM To: rtcweb@ietf.org; mmusic@ietf.org Cc: Cullen Jennings; Magnus Westerlund; Ari Ker=E4nen; Gonzalo = Camarillo; Flemming Andreasen Subject: [MMUSIC] Proposed agenda for the joint MMUSIC/RTCWEB inteirm meeting Below is a proposed agenda which has been discussed among the RTCWEB and MMUSIC chairs; comments welcome. Ted Hardie Day 1 (February 5th, 2013) Multiple Flow SDP representation 90 minutes: Framing discussion (Magnus is working on text) 120 minutes: drafts discussion Objective: decide on architecture for large numbers of similar = streams SDP for Data channels 60 minutes: resolve open issues Day 2 (February 6, 2013) SDP Grouping (Bundle/MMT/one-rtp) 60 Minutes: framing discussion 120 Minutes: drafts discussion Objective: select an approach and provide direction to = editors Mapping stream/track label concepts to SDP identifiers 60 minutes Objective: determine requirements Day 3: (February 7, 2013) Trickle ICE 120 minutes Objective: review offer/answer semantic impact; establish initiation, termination and error handling JSEP 120 minutes Objective: review and resolve open issues with the = document _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From magnus.westerlund@ericsson.com Tue Jan 22 00:16:10 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 867BD21F856F; Tue, 22 Jan 2013 00:16:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.038 X-Spam-Level: X-Spam-Status: No, score=-101.038 tagged_above=-999 required=5 tests=[AWL=-5.146, BAYES_00=-2.599, FS_BROKEN_MEETING=10.357, HELO_EQ_SE=0.35, 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 oxTzJ9Xxal-3; Tue, 22 Jan 2013 00:16:10 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 4206421F84B6; Tue, 22 Jan 2013 00:16:09 -0800 (PST) X-AuditID: c1b4fb30-b7f0d6d000007e61-3d-50fe4ac8268f Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 9A.0D.32353.8CA4EF05; Tue, 22 Jan 2013 09:16:08 +0100 (CET) Received: from [127.0.0.1] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.279.1; Tue, 22 Jan 2013 09:16:07 +0100 Message-ID: <50FE4AC7.4010508@ericsson.com> Date: Tue, 22 Jan 2013 09:16:07 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Roni Even References: <1.e0d2fbab2393f09b6fda@gmail.com> In-Reply-To: <1.e0d2fbab2393f09b6fda@gmail.com> X-Enigmail-Version: 1.5 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrGLMWRmVeSWpSXmKPExsUyM+Jvre4Jr38BBhs+Cli8v6Br0TGZzWLq 8scsFn/bmS3W/mtnt2ica+fA5jHl90ZWj52z7rJ7LFnykymAOYrLJiU1J7MstUjfLoEr49HC iUwFk6Urrryfy9jA+FC0i5GTQ0LARGLOwlmsELaYxIV769m6GLk4hAROMkrMWDqXHcJZziix 5fVJFpAqXgFtictvr4LZLAKqEl97VzGD2GwCFhI3fzSygdiiAsESGw6uYoKoF5Q4OfMJWL2I gJrE67WfwTYwC8xkknh07DhYkbBAgMS6T7vBbCGBYokF/36BDeUU0Jf4uPsEUAMH0HniEmve cICEmQX0JKZcbWGEsOUlmrfOZoZo1ZZoaOpgncAoNAvJ6llIWmYhaVnAyLyKkT03MTMnvdx8 EyMwrA9u+W2wg3HTfbFDjNIcLErivOGuFwKEBNITS1KzU1MLUovii0pzUosPMTJxcEo1MM4M ZHIr3xMraLJoR1gzm/bRzE9qdacK3kpu3S0u/9tabrX6ouI3Jyeye2+TDv7d/FzkvZzvgg9d 0ktSP+Vc8f2ldX9ib2q9/f3j5exXOyanOghvk/aS3P/9r25xSH4sW4f10w/Tis2339Moe3J/ 3s6QcPFjU9ln6zj9cPCs//7Cr0vQaTZjhhJLcUaioRZzUXEiAEgFYYY5AgAA Cc: 'Cullen Jennings' , =?ISO-8859-1?Q?=27Ari_Ker=E4nen=27?= , mmusic@ietf.org, rtcweb@ietf.org Subject: Re: [rtcweb] [MMUSIC] Proposed agenda for the joint MMUSIC/RTCWEB inteirmmeeting X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 22 Jan 2013 08:16:10 -0000 On 2013-01-22 06:49, Roni Even wrote: > Hi, > I am not sure what will be discussed in multiple flow SDP representation > and This is a very fundamental choice of how SDP is going to deal with RTP sessions that include multiple media streams, i.e. SSRCs carrying different media sources and negotiation of media stream related information and parameters. I understand some drafts are under preparation here. This is definitely something that will impact CLUE also. > Mapping stream/track label concepts to SDP identifiers. Are there drafts or > is it an open discussion. This is more an WebRTC focused issues, but it has clearly overlap with the relations discussion on how you identify media sources, different encodings of the same media stream (in simulcast and scalable coding) their repair streams all the way up to WebRTC specific concepts of MediaStream. For this my colleagues and I are preparing a draft. I don't expect it to be available before second half of next week. I think this is relevant for CLUE in the perspective of trying to understand what is common abstractions and what is not. Cheers Magnus > What about the relation of these two topics to CLUE? > > Thanks > Roni Even > > > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of > Ted Hardie > Sent: 14 January, 2013 7:41 PM > To: rtcweb@ietf.org; mmusic@ietf.org > Cc: Cullen Jennings; Magnus Westerlund; Ari Keränen; Gonzalo Camarillo; > Flemming Andreasen > Subject: [MMUSIC] Proposed agenda for the joint MMUSIC/RTCWEB inteirm > meeting > > Below is a proposed agenda which has been discussed among the RTCWEB and > MMUSIC chairs; comments welcome. > > Ted Hardie > > > Day 1 (February 5th, 2013) > > Multiple Flow SDP representation > > 90 minutes: Framing discussion (Magnus is working on text) > > 120 minutes: drafts discussion > > > Objective: decide on architecture for large numbers of similar streams > > SDP for Data channels > > 60 minutes: resolve open issues > > Day 2 (February 6, 2013) > > SDP Grouping (Bundle/MMT/one-rtp) > > 60 Minutes: framing discussion > > 120 Minutes: drafts discussion > > Objective: select an approach and provide direction to editors > > Mapping stream/track label concepts to SDP identifiers > > 60 minutes > > Objective: determine requirements > > Day 3: (February 7, 2013) > > Trickle ICE > > 120 minutes > > Objective: review offer/answer semantic impact; establish > initiation, termination and error handling > > JSEP > > 120 minutes > > Objective: review and resolve open issues with the document > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From prvs=07349a02ec=aallen@rim.com Tue Jan 22 01:55:22 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 657EB21F8726; Tue, 22 Jan 2013 01:55:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.203 X-Spam-Level: X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 PrnKXIo7Fnwo; Tue, 22 Jan 2013 01:55:21 -0800 (PST) Received: from mhs061cnc.rim.net (mhs061cnc.rim.net [208.65.73.35]) by ietfa.amsl.com (Postfix) with ESMTP id 719B321F871D; Tue, 22 Jan 2013 01:55:21 -0800 (PST) X-AuditID: 0a412830-b7f646d0000038d1-82-50fe61fd1525 Received: from XCT101ADS.rim.net (xct101ads.rim.net [10.67.111.42]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by mhs061cnc.rim.net (SBG) with SMTP id 30.E2.14545.DF16EF05; Tue, 22 Jan 2013 03:55:09 -0600 (CST) Received: from XMB104ADS.rim.net ([fe80::2494:a63d:e3:723b]) by XCT101ADS.rim.net ([fe80::2c7e:1215:d554:35b5%20]) with mapi id 14.02.0318.001; Tue, 22 Jan 2013 03:55:09 -0600 From: Andrew Allen To: Roni Even , 'Ted Hardie' , "rtcweb@ietf.org" , "mmusic@ietf.org" Thread-Topic: [MMUSIC] Proposed agenda for the joint MMUSIC/RTCWEB inteirm meeting Thread-Index: AQHN+GSeGNSqJdYUWUGV+w3VmBsFRZhVGrbA Date: Tue, 22 Jan 2013 09:55:08 +0000 Message-ID: References: <004801cdf864$325287e0$96f797a0$@gmail.com> In-Reply-To: <004801cdf864$325287e0$96f797a0$@gmail.com> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.67.110.251] Content-Type: text/plain; charset="iso-8859-1" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNKsWRmVeSWpSXmKPExsXC5Zyvpfs38V+Awczz1hbXrv1ns3h/Qdei YzKbxablK5ksLq2/x2QxdfljFou/7cwWa/+1s1s0zrVz4PSY8nsjq8evr1fZPHbOusvusWTJ T6YAlqgGRpukxJKy4Mz0PH07m8S8vPySxJJUhZTU4mRbJZ/U9MQchYCizLLE5EoFl8zi5JzE zNzUIiWFzBRbJRMlhYKcxOTU3NS8ElulxIKC1LwUJTsuBQxgA1SWmaeQmpecn5KZl26r5Bns r2thYWqpa6hkp5vQyZOx+NhcpoIW8YqXs5+xNTA+FOxi5OSQEDCRWHKohxXCFpO4cG89Wxcj F4eQQBuTxKZVB1khnM2MEhOeb2UHqWITUJZY/nsGI0hCRGAqo8SN3u1g7cwgLROOy3cxcnAI CwRLLJpuBBIWEQiR2HD9ATOEbSTx7k8fC4jNIqAq0T9/KpjNK+Ahce3vIUYQW0igTqL3fhtY PaeAhcThuzvBxjMKyErsPnudCWKVuMStJ/OZIK4WkFiy5zwzhC0q8fLxP6hvFCVm7JkPdZqe xI2pU9ggbG2JZQtfM0PsFZQ4OfMJywRGsVlIxs5C0jILScssJC0LGFlWMQrmZhQbmBkm5yXr FWXm6uWllmxiBKUeRw2DHYzv31scYhTgYFTi4c0CpiQh1sSy4srcQ4wSHMxKIryCwUAh3pTE yqrUovz4otKc1OJDjK7AUJnILMWdnA9Mi3kl8cYGBrg5SuK8/P1/A4QE0oFpKTs1tSC1CGYO EwcnyB4uKZFiYHJJLUosLcmIB6XA+GJgEpRqYFx69XZ/D8ep/vtmBdsCk5b03ir3mxlYN4Xh kY7HwylJClHhddOvTv8VXJyzPNr+f6pECfdnpqPfp3apRFumPPORWtdnxVTDrLRqd9Tjzs5t LK77l7+Q+Pb3oNHm96lxscf/H314I/LGbS7tx9OurHMx5tq0MyBmvdKWEPbXnjtzbdPO9a+J tlFiKc5INNRiLipOBADcqoNKfgMAAA== Cc: 'Cullen Jennings' , =?iso-8859-1?Q?=27Ari_Ker=E4nen=27?= Subject: Re: [rtcweb] [MMUSIC] Proposed agenda for the joint MMUSIC/RTCWEB inteirm meeting X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 22 Jan 2013 09:55:22 -0000 I think it would be better if the JSEP discussion could take place on the ei= ther day 1 or day 2 so there is some time for offline discussion before the= end of the of the meeting. I think there are some important concerns here w= hich we need to reach resolution on. What are the times for the start and end schedule each day? Adding up the hours it seems that it should be possible to fit more into Day= 1 and Day 2 and still only do a full "IETF work day". Andrew -----Original Message----- From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of= Roni Even Sent: Tuesday, January 22, 2013 12:49 AM To: 'Ted Hardie'; rtcweb@ietf.org; mmusic@ietf.org Cc: 'Cullen Jennings'; 'Magnus Westerlund'; 'Ari Ker=E4nen'; 'Gonzalo Camari= llo'; 'Flemming Andreasen' Subject: Re: [MMUSIC] Proposed agenda for the joint MMUSIC/RTCWEB inteirm me= eting Hi, I am not sure what will be discussed in multiple flow SDP representation and= Mapping stream/track label concepts to SDP identifiers. Are there drafts or= is it an open discussion. What about the relation of these two topics to CLUE? Thanks Roni Even -----Original Message----- From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of= Ted Hardie Sent: 14 January, 2013 7:41 PM To: rtcweb@ietf.org; mmusic@ietf.org Cc: Cullen Jennings; Magnus Westerlund; Ari Ker=E4nen; Gonzalo Camarillo; Fl= emming Andreasen Subject: [MMUSIC] Proposed agenda for the joint MMUSIC/RTCWEB inteirm meetin= g Below is a proposed agenda which has been discussed among the RTCWEB and MMU= SIC chairs; comments welcome. Ted Hardie Day 1 (February 5th, 2013) Multiple Flow SDP representation 90 minutes: Framing discussion (Magnus is working on text) 120 minutes: drafts discussion Objective: decide on architecture for large numbers of similar streams SDP for Data channels 60 minutes: resolve open issues Day 2 (February 6, 2013) SDP Grouping (Bundle/MMT/one-rtp) 60 Minutes: framing discussion 120 Minutes: drafts discussion Objective: select an approach and provide direction to editors Mapping stream/track label concepts to SDP identifiers 60 minutes Objective: determine requirements Day 3: (February 7, 2013) Trickle ICE 120 minutes Objective: review offer/answer semantic impact; establish initia= tion, termination and error handling JSEP 120 minutes Objective: review and resolve open issues with the document __= _____________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From ron.even.tlv@gmail.com Tue Jan 22 02:44:52 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9668321F8464; Tue, 22 Jan 2013 02:44:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.58 X-Spam-Level: * X-Spam-Status: No, score=1.58 tagged_above=-999 required=5 tests=[AWL=-5.178, BAYES_00=-2.599, FS_BROKEN_MEETING=10.357, 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 NSbngufe1oCo; Tue, 22 Jan 2013 02:44:52 -0800 (PST) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by ietfa.amsl.com (Postfix) with ESMTP id 6772621F8461; Tue, 22 Jan 2013 02:44:51 -0800 (PST) Received: by mail-ee0-f54.google.com with SMTP id c41so3435529eek.13 for ; Tue, 22 Jan 2013 02:44:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-type:content-transfer-encoding :x-mailer:thread-index:content-language; bh=2D/vyBdfThW//9yWAfDx1SXCVW6BXlLM/TuV7fl61AQ=; b=I3OR7HrYBup2RlblZfH+HgfOw5Np7qveetGHo7WxXzYLTE9avsxNSUGu+Hx2qV/laN JwcDnxg3puLs+nXS66ygEDZgdsBL7HH9RZHbNrXZHuElZ1HzdsYfj7uHdxDsaPIoftZa SePOvnbLkrq+Cw/iPKHAlsFVT+fcFXACOmW+jhR04whk9v8FPR/oKKtyAypNoTHgbg0f hAwamc9Wz62vCLqEfaizngSBUMuQH9kPp6Aest2mVYICB1/ntdx3X631+F15wNxHWXRn jvJTX+jANAbbM/G/0AgawlfumPJZyqGPbLIP7pXZqO+sEgS71qCPoSXcPW+PVWyMOV3d hhXg== X-Received: by 10.14.202.3 with SMTP id c3mr71863115eeo.4.1358851490500; Tue, 22 Jan 2013 02:44:50 -0800 (PST) Received: from RoniE (bzq-79-181-179-229.red.bezeqint.net. [79.181.179.229]) by mx.google.com with ESMTPS id k4sm26500384eep.15.2013.01.22.02.44.45 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 22 Jan 2013 02:44:48 -0800 (PST) From: "Roni Even" To: "'Magnus Westerlund'" References: <1.e0d2fbab2393f09b6fda@gmail.com> <50FE4AC7.4010508@ericsson.com> In-Reply-To: <50FE4AC7.4010508@ericsson.com> Date: Tue, 22 Jan 2013 12:41:54 +0200 Message-ID: <007d01cdf88d$1b4f2020$51ed6060$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKCYsEIPwdLZ6w2lmT6EdTEcbci6ADpB3QcAxbfwFiWzE+GoA== Content-Language: en-us Cc: 'Cullen Jennings' , =?ISO-8859-1?Q?'Ari_Ker=E4nen'?= , mmusic@ietf.org, rtcweb@ietf.org Subject: Re: [rtcweb] [MMUSIC] Proposed agenda for the joint MMUSIC/RTCWEB inteirmmeeting X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 22 Jan 2013 10:44:52 -0000 Hi Magnus, My concern is that it is not easy to provide a proposal to a subject = that is not clear. I also have views about these topics but seeing no = requirements or use cases it is difficult to write a draft. I believe that the actual syntax depends on the bundle decision so any = work now need to assume a bundle architecture. Are there any requirements for a solution even if we are looking for a = new way or to leverage existing mechanisms like RFC 5576. I will try to write something based on the CLUE RTP mapping draft we are discussing that tries to address a similar problem as far as I = understand. BTW: will these drafts be MMUSIC drafts or RTCweb? Thanks Roni Even -----Original Message----- From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]=20 Sent: 22 January, 2013 10:16 AM To: Roni Even Cc: 'Ted Hardie'; rtcweb@ietf.org; mmusic@ietf.org; 'Cullen Jennings'; = 'Ari Ker=E4nen'; 'Gonzalo Camarillo'; 'Flemming Andreasen' Subject: Re: [MMUSIC] Proposed agenda for the joint MMUSIC/RTCWEB inteirmmeeting On 2013-01-22 06:49, Roni Even wrote: > Hi, > I am not sure what will be discussed in multiple flow SDP=20 > representation and This is a very fundamental choice of how SDP is going to deal with RTP sessions that include multiple media streams, i.e. SSRCs carrying = different media sources and negotiation of media stream related information and parameters. I understand some drafts are under preparation here. This is definitely something that will impact CLUE also. > Mapping stream/track label concepts to SDP identifiers. Are there=20 > drafts or is it an open discussion. This is more an WebRTC focused issues, but it has clearly overlap with = the relations discussion on how you identify media sources, different = encodings of the same media stream (in simulcast and scalable coding) their repair streams all the way up to WebRTC specific concepts of MediaStream. For this my colleagues and I are preparing a draft. I don't expect it to = be available before second half of next week. I think this is relevant for CLUE in the perspective of trying to = understand what is common abstractions and what is not. Cheers Magnus > What about the relation of these two topics to CLUE? >=20 > Thanks > Roni Even >=20 >=20 > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On=20 > Behalf Of Ted Hardie > Sent: 14 January, 2013 7:41 PM > To: rtcweb@ietf.org; mmusic@ietf.org > Cc: Cullen Jennings; Magnus Westerlund; Ari Ker=E4nen; Gonzalo=20 > Camarillo; Flemming Andreasen > Subject: [MMUSIC] Proposed agenda for the joint MMUSIC/RTCWEB inteirm=20 > meeting >=20 > Below is a proposed agenda which has been discussed among the RTCWEB=20 > and MMUSIC chairs; comments welcome. >=20 > Ted Hardie >=20 >=20 > Day 1 (February 5th, 2013) >=20 > Multiple Flow SDP representation >=20 > 90 minutes: Framing discussion (Magnus is working on text) >=20 > 120 minutes: drafts discussion >=20 >=20 > Objective: decide on architecture for large numbers of similar streams >=20 > SDP for Data channels >=20 > 60 minutes: resolve open issues >=20 > Day 2 (February 6, 2013) >=20 > SDP Grouping (Bundle/MMT/one-rtp) >=20 > 60 Minutes: framing discussion >=20 > 120 Minutes: drafts discussion >=20 > Objective: select an approach and provide direction to editors >=20 > Mapping stream/track label concepts to SDP identifiers >=20 > 60 minutes >=20 > Objective: determine requirements >=20 > Day 3: (February 7, 2013) >=20 > Trickle ICE >=20 > 120 minutes >=20 > Objective: review offer/answer semantic impact; establish initiation,=20 > termination and error handling >=20 > JSEP >=20 > 120 minutes >=20 > Objective: review and resolve open issues with the document=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic --=20 Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 F=E4r=F6gatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From magnus.westerlund@ericsson.com Tue Jan 22 03:01:18 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1A4121F86EF; Tue, 22 Jan 2013 03:01:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.009 X-Spam-Level: X-Spam-Status: No, score=-100.009 tagged_above=-999 required=5 tests=[AWL=-4.117, BAYES_00=-2.599, FS_BROKEN_MEETING=10.357, HELO_EQ_SE=0.35, 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 TlMn6xZd9o6r; Tue, 22 Jan 2013 03:01:18 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 8DE2621F8650; Tue, 22 Jan 2013 03:01:17 -0800 (PST) X-AuditID: c1b4fb30-b7f0d6d000007e61-d7-50fe717c1401 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 7B.FD.32353.C717EF05; Tue, 22 Jan 2013 12:01:16 +0100 (CET) Received: from [127.0.0.1] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.279.1; Tue, 22 Jan 2013 12:01:16 +0100 Message-ID: <50FE717A.7080302@ericsson.com> Date: Tue, 22 Jan 2013 12:01:14 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Roni Even References: <1.e0d2fbab2393f09b6fda@gmail.com> <50FE4AC7.4010508@ericsson.com> <007d01cdf88d$1b4f2020$51ed6060$@gmail.com> In-Reply-To: <007d01cdf88d$1b4f2020$51ed6060$@gmail.com> X-Enigmail-Version: 1.5 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrGLMWRmVeSWpSXmKPExsUyM+JvrW5N4b8Ag5WzdC3eX9C16JjMZjF1 +WMWi7/tzBZr/7WzWzTOtXNg85jyeyOrx85Zd9k9liz5yRTAHMVlk5Kak1mWWqRvl8CV0ftY rmCeaMXZGa+ZGxi/CHQxcnJICJhIHN7znBnCFpO4cG89WxcjF4eQwElGiSnT+lghnOWMEofX tDCCVPEKaEtcuvaGFcRmEVCVmNWxnA3EZhOwkLj5oxHMFhUIlthwcBUTRL2gxMmZT1hAbBEB NYnXaz+DbWAWmMkk8ejYcbAiYYEAiXWfdjNBbNvPKLH2zmGwDZxAU/d/2sHexcgBdJ+4xJo3 HCBhZgE9iSlXIQ5iFpCXaN46G+wFIaDjGpo6WCcwCs1CsnsWkpZZSFoWMDKvYmTPTczMSS83 38QIDOuDW34b7GDcdF/sEKM0B4uSOG+464UAIYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYzL VaTyLRedYT8va9SikGnJ6f18x0bxlxWTnVrco58+MD1tZx0sd6wiln/eRc6t0QFr6mujbpl9 UBfxOGTLu8qPS6Ose/XlytNTS4pCYz4p5v1RzHKIcp6fae9tfKu7c9vFq067Kn+/N5V3Ka2+ cl74SFWwff+9uTyNaWuXLNDZPE0tSKe+VYmlOCPRUIu5qDgRAE7PMK45AgAA Cc: 'Cullen Jennings' , =?ISO-8859-1?Q?=27Ari_Ker=E4nen=27?= , mmusic@ietf.org, rtcweb@ietf.org Subject: Re: [rtcweb] [MMUSIC] Proposed agenda for the joint MMUSIC/RTCWEB inteirmmeeting X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 22 Jan 2013 11:01:18 -0000 On 2013-01-22 11:41, Roni Even wrote: > Hi Magnus, > My concern is that it is not easy to provide a proposal to a subject that is > not clear. I also have views about these topics but seeing no requirements > or use cases it is difficult to write a draft. > I believe that the actual syntax depends on the bundle decision so any work > now need to assume a bundle architecture. And I think the question of how one deals with multiple media streams in an RTP session is an important input into the BUNDLE discussion. > Are there any requirements for a solution even if we are looking for a new > way or to leverage existing mechanisms like RFC 5576. To my understanding what we are trying to achieve is making progress into three different subjects. 1) How multiple media streams are handled in SDP. I think there exist two proposal from the MMUSIC discussion: A) One media description per RTP session and media type. Each media stream are identified and provided with additional information using stream specific parameters. B) Each media description is a media stream and RTP sessions are then expressed as Bundle of media descriptions. 2) How "Bundle" is going to be done. Which of the three proposals do we really believe in. Note that direction of 1) will affect how commonly required the usage of "Bundle" will be. Thus affect the trade-off concerns. 3) What is common relations exist between concepts in WebRTC, CLUE and other multi-media communication contexts that needs to be identified and signalled and at what scopes. This influences the solution for MediaStream identities, our SRCNAME proposal in AVTEXT and CLUE work. There are a number of commonalities here that should be considered. > > I will try to write something based on the CLUE RTP mapping draft we are > discussing that tries to address a similar problem as far as I understand. Please do, the more informed everyone is, the better. > > BTW: will these drafts be MMUSIC drafts or RTCweb? > I don't know . I think ours is likely MMUSIC. I can't answer for the other contributions I expect. I guess the important is that all contributions are announced to the relevant WGs. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From ron.even.tlv@gmail.com Tue Jan 22 05:21:42 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 980CF21F85B1; Tue, 22 Jan 2013 05:21:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.879 X-Spam-Level: *** X-Spam-Status: No, score=3.879 tagged_above=-999 required=5 tests=[AWL=-4.738, BAYES_20=-0.74, FS_BROKEN_MEETING=10.357, 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 jLRwAuo4sTyv; Tue, 22 Jan 2013 05:21:42 -0800 (PST) Received: from mail-ee0-f47.google.com (mail-ee0-f47.google.com [74.125.83.47]) by ietfa.amsl.com (Postfix) with ESMTP id 4463621F84E7; Tue, 22 Jan 2013 05:21:41 -0800 (PST) Received: by mail-ee0-f47.google.com with SMTP id e52so3359447eek.6 for ; Tue, 22 Jan 2013 05:21:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-type:content-transfer-encoding :x-mailer:thread-index:content-language; bh=DfByt1f/ETAPxKL9GHgD9ZjN+0ndDWCIyiQPuPtnAgI=; b=f81RNNqSCOMfO7RVZ6lRcq5FmGOZ6HLnoC7RIVStF/PWUkKYX6xZ/3+lx9TCSi+ZVb XfdKWqf6adllG1k4vsyvzayWVE6zoVb+MGpZIau08OrFuZzOaklm7EYz5jmSez29AZaf 6ErNbkioLZTrYRj7WiqnaZYwiQqjeQufRS4r7JDVsd7LK5f5JKe+mYph37qdi07/I/El 36s9Jjtn4dEoZ2Ar8P4n/JYXWbXrZJn97jrjb0IiypyPXZ8bi+tsEPjMVqa3CZL9ZaIW YpKjam29rqBIv6lFbvAc+VaqguALP5bQ501ebxZwpcIkDvVN0V2DwqcSX4cJWYa4GrM5 +FUQ== X-Received: by 10.14.213.134 with SMTP id a6mr72754712eep.45.1358860900096; Tue, 22 Jan 2013 05:21:40 -0800 (PST) Received: from RoniE (bzq-79-181-179-229.red.bezeqint.net. [79.181.179.229]) by mx.google.com with ESMTPS id q44sm26988975eep.5.2013.01.22.05.21.36 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 22 Jan 2013 05:21:38 -0800 (PST) From: "Roni Even" To: "'Magnus Westerlund'" References: <1.e0d2fbab2393f09b6fda@gmail.com> <50FE4AC7.4010508@ericsson.com> <007d01cdf88d$1b4f2020$51ed6060$@gmail.com> <50FE717A.7080302@ericsson.com> In-Reply-To: <50FE717A.7080302@ericsson.com> Date: Tue, 22 Jan 2013 15:18:45 +0200 Message-ID: <008c01cdf8a3$047b7590$0d7260b0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKCYsEIPwdLZ6w2lmT6EdTEcbci6ADpB3QcAxbfwFgDRvVEFQJzmxlRlp6rPeA= Content-Language: en-us Cc: 'Cullen Jennings' , =?ISO-8859-1?Q?'Ari_Ker=E4nen'?= , mmusic@ietf.org, rtcweb@ietf.org Subject: Re: [rtcweb] [MMUSIC] Proposed agenda for the joint MMUSIC/RTCWEB inteirmmeeting X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 22 Jan 2013 13:21:42 -0000 Hi Magnus, Thanks, I think that the first subject is what we were also discussing = in CLUE when looking at RTP mapping and we considered the also the = individual drafts on maxssrc, and srcname. As for the two options I am not sure that we must chose. The first one = "A" is the current practice and I agree it is under specified today. The second on "B" depends on how we define bundle. Looking at option "B" = was suggested also for RTP mapping in CLUE (for example with regards to simulcast) Roni=20 -----Original Message----- From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]=20 Sent: 22 January, 2013 1:01 PM To: Roni Even Cc: 'Ted Hardie'; rtcweb@ietf.org; mmusic@ietf.org; 'Cullen Jennings'; = 'Ari Ker=E4nen'; 'Gonzalo Camarillo'; 'Flemming Andreasen' Subject: Re: [MMUSIC] Proposed agenda for the joint MMUSIC/RTCWEB inteirmmeeting On 2013-01-22 11:41, Roni Even wrote: > Hi Magnus, > My concern is that it is not easy to provide a proposal to a subject=20 > that is not clear. I also have views about these topics but seeing no=20 > requirements or use cases it is difficult to write a draft. > I believe that the actual syntax depends on the bundle decision so any = > work now need to assume a bundle architecture. And I think the question of how one deals with multiple media streams in = an RTP session is an important input into the BUNDLE discussion. > Are there any requirements for a solution even if we are looking for a = > new way or to leverage existing mechanisms like RFC 5576. To my understanding what we are trying to achieve is making progress = into three different subjects. 1) How multiple media streams are handled in SDP. I think there exist = two proposal from the MMUSIC discussion: A) One media description per RTP session and media type. Each media stream are identified and provided with additional information using stream specific parameters. B) Each media description is a media stream and RTP sessions are then expressed as Bundle of media descriptions. 2) How "Bundle" is going to be done. Which of the three proposals do we really believe in. Note that direction of 1) will affect how commonly required the usage of "Bundle" will be. Thus affect the trade-off concerns. 3) What is common relations exist between concepts in WebRTC, CLUE and = other multi-media communication contexts that needs to be identified and = signalled and at what scopes. This influences the solution for MediaStream = identities, our SRCNAME proposal in AVTEXT and CLUE work. There are a number of commonalities here that should be considered. >=20 > I will try to write something based on the CLUE RTP mapping draft we=20 > are discussing that tries to address a similar problem as far as I understand. Please do, the more informed everyone is, the better. >=20 > BTW: will these drafts be MMUSIC drafts or RTCweb? >=20 I don't know . I think ours is likely MMUSIC. I can't answer for the = other contributions I expect. I guess the important is that all contributions = are announced to the relevant WGs. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 F=E4r=F6gatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From internet-drafts@ietf.org Tue Jan 22 15:13:09 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1F9521F8753; Tue, 22 Jan 2013 15:13:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.46 X-Spam-Level: X-Spam-Status: No, score=-102.46 tagged_above=-999 required=5 tests=[AWL=0.139, 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 x580I2Tc06XP; Tue, 22 Jan 2013 15:13:07 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E1D521F8765; Tue, 22 Jan 2013 15:13:03 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130122231303.8371.82083.idtracker@ietfa.amsl.com> Date: Tue, 22 Jan 2013 15:13:03 -0800 Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-security-arch-06.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, 22 Jan 2013 23:13:09 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Real-Time Communication in WEB-browsers W= orking Group of the IETF. Title : RTCWEB Security Architecture Author(s) : Eric Rescorla Filename : draft-ietf-rtcweb-security-arch-06.txt Pages : 42 Date : 2013-01-22 Abstract: The Real-Time Communications on the Web (RTCWEB) working group is tasked with standardizing protocols for enabling real-time communications within user-agents using web technologies (e.g JavaScript). The major use cases for RTCWEB technology are real-time audio and/or video calls, Web conferencing, and direct data transfer. Unlike most conventional real-time systems (e.g., SIP-based soft phones) RTCWEB communications are directly controlled by some Web server, which poses new security challenges. For instance, a Web browser might expose a JavaScript API which allows a server to place a video call. Unrestricted access to such an API would allow any site which a user visited to "bug" a user's computer, capturing any activity which passed in front of their camera. [I-D.ietf-rtcweb- security] defines the RTCWEB threat model. This document defines an architecture which provides security within that threat model. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-security-arch There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcweb-security-arch-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Tue Jan 22 15:20:33 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55B3121F8A89; Tue, 22 Jan 2013 15:20:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.466 X-Spam-Level: X-Spam-Status: No, score=-102.466 tagged_above=-999 required=5 tests=[AWL=0.133, 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 zJysJOvdV2A0; Tue, 22 Jan 2013 15:20:31 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DEB821F85B4; Tue, 22 Jan 2013 15:20:27 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130122232026.32214.43008.idtracker@ietfa.amsl.com> Date: Tue, 22 Jan 2013 15:20:26 -0800 Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-security-04.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, 22 Jan 2013 23:20:34 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Real-Time Communication in WEB-browsers W= orking Group of the IETF. Title : Security Considerations for RTC-Web Author(s) : Eric Rescorla Filename : draft-ietf-rtcweb-security-04.txt Pages : 22 Date : 2013-01-22 Abstract: The Real-Time Communications on the Web (RTC-Web) working group is tasked with standardizing protocols for real-time communications between Web browsers. The major use cases for RTC-Web technology are real-time audio and/or video calls, Web conferencing, and direct data transfer. Unlike most conventional real-time systems (e.g., SIP- based soft phones) RTC-Web communications are directly controlled by some Web server, which poses new security challenges. For instance, a Web browser might expose a JavaScript API which allows a server to place a video call. Unrestricted access to such an API would allow any site which a user visited to "bug" a user's computer, capturing any activity which passed in front of their camera. This document defines the RTC-Web threat model and defines an architecture which provides security within that threat model. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-security There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-rtcweb-security-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcweb-security-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From richard.ejzak@alcatel-lucent.com Wed Jan 23 14:50:16 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67EC021F874F for ; Wed, 23 Jan 2013 14:50:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 DedoKjI6ccs8 for ; Wed, 23 Jan 2013 14:50:15 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id D847121F8786 for ; Wed, 23 Jan 2013 14:50:14 -0800 (PST) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r0NMncEJ009636 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 23 Jan 2013 23:50:11 +0100 Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (135.5.2.35) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (135.120.45.61) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 23 Jan 2013 23:49:59 +0100 Received: from US70UWXCHMBA04.zam.alcatel-lucent.com ([169.254.12.105]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.02.0247.003; Wed, 23 Jan 2013 17:49:48 -0500 From: "Ejzak, Richard P (Richard)" To: "rtcweb@ietf.org" Thread-Topic: [rtcweb] FW: New Version Notification for draft-reddy-rtcweb-mobile-00.txt Thread-Index: AQHN9taXNfHQivedK0yp8mNO4jCwcJhSVjmAgANJCXA= Date: Wed, 23 Jan 2013 22:49:48 +0000 Message-ID: <03FBA798AC24E3498B74F47FD082A92F36EA12C6@US70UWXCHMBA04.zam.alcatel-lucent.com> References: <913383AAA69FF945B8F946018B75898A148E07CB@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A148E8567@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A148E8567@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] 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.83 Subject: Re: [rtcweb] FW: New Version Notification for draft-reddy-rtcweb-mobile-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: Wed, 23 Jan 2013 22:50:16 -0000 I have various comments on section 4 of draft-reddy-rtcweb-mobile. First of all, thanks for this draft as it highlights some issues that will = be very important in deployment of WebRTC in LTE and related mobile network= s. I will comment on section 4.2 out of order to avoid forward references = in the comments. 4.2: This section makes the assertion that only UE initiated bearer modific= ation procedures are available to a "public WebRTC server". While this is a= n option in the specification (not necessarily always used), there is also = a network API available for the public WebRTC server to be able (if allowed= by the mobile network provider) to request QoS for specific flows. There i= s a Parlay X API for QoS and also plans to develop a RESTful API. 4.1 RTP session multiplexing: This section is very pessimistic about the ability to assign different bear= ers to multiplexed flows. I think that solutions do exist, which I describe= below. First, I find the discussion of DSCP markings in the text to be confusing, = but I think this is because the text assumes that there is no coordination = between the network and the WebRTC application with regard to DSCP markings= . While this is strictly true when using UE initiated bearer modification p= rocedures, the situation is a bit more nuanced. I will discuss handling of the uplink and downlink flows separately. There should be no problem for either a UE or network initiated bearer modi= fication procedure to specify uplink TFTs including five-tuple and TOS (DSC= P). There is no reason to apply network policy to the selection of DSCP val= ues in the uplink TFTs since they will just be remapped in the network anyw= ay. Uplink packets with the corresponding marking will be assigned to the d= esired bearer for transport over the radio. This assumes that the markings = survive transit from the browser to the modem, which should not be a proble= m within a device or small network. This also assumes that there is no bloc= king at intermediate queues between the browser and the modem, which might = occur, e.g., if different priority flows share a queue for a five-tuple. A = proper design will avoid this potential problem. The network will remark th= e uplink packets according to policy before forwarding them into the backbo= ne to the remote peer, so the design cannot depend on the markings survivin= g transit through the network. In general, priority treatment on the radio = is much more important than priority treatment in the backbone. Without some additional effort, this approach will fail in the downlink sin= ce it is not possible to know how the packets transiting through the networ= k will be marked. The packets can be remarked at any point on the path from= their source, so even knowledge of access network marking policies will no= t help without additional procedures. There are two possible solutions to this problem, and both require that som= e mechanism is available to identify the packets belonging to any one flow = so that they can be passed to the correct bearer for handling. Fortunately,= rtcweb requires that the SSRC(s) for each flow be explicitly signaled in t= he SDP, thus providing a way of identifying each flow (i.e., filtering on f= ive-tuple and SSRC value). The two options for using SSRC to direct each downlink flow to the correct = bearer are: 1) insert a gateway node within the access network with the exp= licit purpose of identifying each downlink flow and remarking the packets t= o match the DSCP value specified in the corresponding downlink TFT; or 2) e= xtend the TFT filtering mechanism to also support matching on SSRC values. Option 1) requires that the rtcweb application coordinate the markings with= the network to ensure that the downlink markings conform to network policy= . This will require some interaction between the rtcweb application and the= mobile network, potentially using the network initiated bearer modificatio= n procedure. Note that the downlink markings can be defined by network poli= cy and the uplink markings can be defined by rtcweb/browser policy, which c= an be different. Option 2) requires a modification to the 3GPP specifications to extend the = TFT mechanism but is certainly the technically preferred solution since it = eliminates the need to be aware of network marking policies and eliminates = the need to insert a gateway just for the purpose of remarking packets. Not= e also that when this extension is available, the uplink TFTs can be based = on SSRC as well to eliminate any dependence on packet markings. Thus there are two workable solutions to providing QoS treatment to multipl= exed media flows, one available with existing specifications and one requir= ing some small 3GPP spec enhancements. The only requirement relevant to rtc= web is that the SSRC values used for different media flows must be explicit= ly signaled in SDP so that they are available to identify each flow. 4.3, first bullet: What is the practical implication, if any, of delaying t= he interaction with the PCRF until the 2nd offer/answer? 4.3, second bullet: There should probably be a definition of "WebRTC server= " in the document. It's not clear from the text why this and no other entit= y must have an "Rx" like interface to a PCRF. It's also not clear why the = interface is "Rx" like and not Rx. There is no question that some entity o= n the signaling path needs to interact directly or indirectly with the PCRF= . Richard =20 From fluffy@cisco.com Thu Jan 24 08:46:54 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BCAA21F8506 for ; Thu, 24 Jan 2013 08:46:54 -0800 (PST) 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 SsdPYb0C1eLr for ; Thu, 24 Jan 2013 08:46:54 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id DE1E021F8503 for ; Thu, 24 Jan 2013 08:46:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=895; q=dns/txt; s=iport; t=1359046014; x=1360255614; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=dAAo+sR4o0qOUS4KYIctmvcU21cO6rbgyLQkV1AwkKQ=; b=BbFuGwIPOY0OIu/eGPuUWFc4mXSpDMYehyU5zc992/EP+L4Ca9nUTmY1 5VoNEa1vZrjn7DQIylPrtYx4QIgJskWd93TAWyL6bkZIAAYgAfKObWnTV moiDP6vpn5y6ijRZZFLIsXzhWT5D6edyWyDq+JL/WzVbqvHmUL4djKQKy E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAKhkAVGtJV2c/2dsb2JhbABEvkgWc4IfAQEEHVwQAgEIIiQyJQIEDg2IEr4ckBphA4gsniiCeIIk X-IronPort-AV: E=Sophos;i="4.84,530,1355097600"; d="scan'208";a="164532657" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-9.cisco.com with ESMTP; 24 Jan 2013 16:46:47 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r0OGkleM025798 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 24 Jan 2013 16:46:47 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.197]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0318.004; Thu, 24 Jan 2013 10:46:46 -0600 From: "Cullen Jennings (fluffy)" To: "rtcweb@ietf.org" Thread-Topic: Conclusion statement for Recommended Audio Codecs call Thread-Index: AQHN+lJlS8xNYunZw0yrsQtXbpVqGg== Date: Thu, 24 Jan 2013 16:46:45 +0000 Message-ID: References: <50FD4C4B.9020700@ericsson.com> <50FEB1EC.9060803@ericsson.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.164] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <1306B79B29E5A1428A35DC7E55E18B23@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [rtcweb] Conclusion statement for Recommended Audio Codecs call X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 24 Jan 2013 16:46:54 -0000 We have been running a call for consensus regarding Selecting Recommended A= udio Codecs. At this point the chairs are calling this as "no WG consensus".=20 We can however note a strong interest in a non-normative listing of potenti= ally important codecs including a description why they should be considered= to be supported in WebRTC implementations.=20 In lieu of additional normative text, we believe the WG discussion supports= the inclusion of a new section on "Additional Relevant Codecs". That can = contain a list of codecs which are relevant in specific contexts, along wit= h a short description of the context for each. Specifically there seems to = be interest in understanding the advantages and costs of G.722, AMR, and AM= R-WB. We hope that text would broaden understanding of the WebRTC use case = contexts. The WG chairs Magnus, Ted and Cullen=20 From stefan.lk.hakansson@ericsson.com Fri Jan 25 05:11:13 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E879421F866D for ; Fri, 25 Jan 2013 05:11:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, 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 6X0gC4MjL+51 for ; Fri, 25 Jan 2013 05:11:13 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id F294321F844F for ; Fri, 25 Jan 2013 05:11:12 -0800 (PST) X-AuditID: c1b4fb25-b7f366d000004d10-67-5102846f656d Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 1F.F1.19728.F6482015; Fri, 25 Jan 2013 14:11:11 +0100 (CET) Received: from [150.132.141.90] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.279.1; Fri, 25 Jan 2013 14:11:11 +0100 Message-ID: <5102846E.7070805@ericsson.com> Date: Fri, 25 Jan 2013 14:11:10 +0100 From: =?ISO-8859-1?Q?Stefan_H=E5kansson_LK?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: rtcweb@ietf.org References: <50F97303.4070906@ericsson.com> In-Reply-To: <50F97303.4070906@ericsson.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHJMWRmVeSWpSXmKPExsUyM+JvrW5+C1OgwaE96hZr/7WzOzB6LFny kymAMYrLJiU1J7MstUjfLoErY+aF3cwFZwUqth7qYm9g3MPbxcjJISFgIvH1ziN2CFtM4sK9 9WxdjFwcQgInGSXuL7rABOGsYZR41bsDrIpXQFvidO9RZhCbRUBV4svT1UwgNptAoMT1/7/A bFGBKIn3V5uYIeoFJU7OfMICYosICEtsfdULViMsECyxcuIXRhBbCGjmpO33gWwODk4BHYmj V0NBwswCthIX5lxngbDlJZq3zmaGKNeVePf6HusERoFZSDbMQtIyC0nLAkbmVYzsuYmZOenl RpsYgWF2cMtv1R2Md86JHGKU5mBREucNd70QICSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoGR 2ZVtzsRFq3ax7LihpaSSJ+7LKxp+PHmaZolZ6U6XoP+NPv5O13++rZ5/O+BxRt+r0LRZMh+k zROvsmvcUV0XLl+xl9VXxNVPz6nzbeINLq1S63WS+TtPdMg9X3dLZ88TiUOXxWJfzDw6/2mc 0OMJj1deVTOZeitA5pFTn1Cw+srfF6yPs2QosRRnJBpqMRcVJwIAgoiTKwECAAA= Subject: Re: [rtcweb] WG Last Call: draft-ietf-rtcweb-use-cases-and-requirements-10 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 25 Jan 2013 13:11:14 -0000 On 2013-01-18 17:06, Magnus Westerlund wrote: > WG, > > I would here by like to announce a two week WG last call that ends on > the 1st of February. > > Document is available here: > > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-use-cases-and-requirements/ As discussed in an earlier thread, I think that it should be clarified how the streams for the small/big video displays in use-case 4.3.3 are generated. To recap, the use case is about a multiparty video (and audio of course) communication session using a central node. At the screen of each endpoint/user, one video is displayed on a large surface, with other videos are shown as (live) thumbnails. Which video to show at the large display surface is depending on speech activity; the video form the endpoint with currently talking user(s) is shown on the large surface - and this will usually change frequently during the session. This selection is handled by the central node which has access to all video and audio streams. I think this is a quite common model, used by many services. The current draft list three ways to support this use-case (use scalable video codecs, transcode in the central node, or use simulcast), but there are no requirements that back this up. We should pick one solution that must be supported, and then derive the corresponding requirements. As said before, I am a proponent for simulcast as solution to this use-case. Stefan > > Cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > Färögatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From ted.ietf@gmail.com Fri Jan 25 08:47:55 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D2C621F893E; Fri, 25 Jan 2013 08:47:55 -0800 (PST) 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 rQJAcpfhO30x; Fri, 25 Jan 2013 08:47:55 -0800 (PST) Received: from mail-ob0-f181.google.com (mail-ob0-f181.google.com [209.85.214.181]) by ietfa.amsl.com (Postfix) with ESMTP id AE80621F88BF; Fri, 25 Jan 2013 08:47:54 -0800 (PST) Received: by mail-ob0-f181.google.com with SMTP id wc18so668609obb.12 for ; Fri, 25 Jan 2013 08:47:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=ZlIvhBX4rBIPBD9aqA4mHcwHqhFWYzmq23B8S5v6g9A=; b=XSLpVnIkPXJEx1kXqhqQx/tuku0PaFi4bR6QtcIWWWFENhqZWAbCBgKuJHVA/YHyAU sWO3WVQSiU3h5Qh0qetpDTAlFQMJWWWs0RKaBSXRxnPkGOdoMuIZWjuseMN+XaUm439l pPucQpNAnuEHj82lOiuwaW1R5rWFf2CeSqaZFyevKoNA49dbVMj0I98tDqutr/ZaN0YI Jb1bkfNYmaz0bM19vDyROJ6jcA7YjsUiLEjKAWpqIQaftWl+z01+T6s3+LhfOtNNSaTu T/fpj4/uGN63BoPG+Np4paQ7zlk01VHTAG7scnfVr4NZpTX4fjEnpKLXVs36qvtSGq4V EMwA== MIME-Version: 1.0 X-Received: by 10.50.91.168 with SMTP id cf8mr4597586igb.20.1359132474170; Fri, 25 Jan 2013 08:47:54 -0800 (PST) Received: by 10.43.135.202 with HTTP; Fri, 25 Jan 2013 08:47:54 -0800 (PST) In-Reply-To: References: Date: Fri, 25 Jan 2013 08:47:54 -0800 Message-ID: From: Ted Hardie To: mmusic@ietf.org, rtcweb@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [rtcweb] Start of a reading list for the IETF MMUSIC/RTCWEB interim X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 25 Jan 2013 16:47:55 -0000 http://tools.ietf.org/html/draft-ietf-mmusic-sdp-bundle-negotiation http://tools.ietf.org/html/draft-alvestrand-mmusic-msid http://tools.ietf.org/html/draft-holmberg-mmusic-sdp-mmt-negotiation http://tools.ietf.org/html/draft-ietf-mmusic-sctp-sdp http://tools.ietf.org/html/draft-rescorla-mmusic-ice-trickle http://tools.ietf.org/html/draft-ietf-rtcweb-jsep You may also want to look at the proceedings from the Atlanta meeting; in particular, this was suggested as good background reading: http://www.ietf.org/proceedings/85/slides/slides-85-mmusic-7.ppt regards, Ted Hardie From gunnar.hellstrom@omnitor.se Fri Jan 25 13:28:10 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98AE921F8442 for ; Fri, 25 Jan 2013 13:28:10 -0800 (PST) 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 sKyg95jmUEjg for ; Fri, 25 Jan 2013 13:28:10 -0800 (PST) Received: from vsp-authed-02-02.binero.net (vsp-authed02.binero.net [195.74.38.226]) by ietfa.amsl.com (Postfix) with SMTP id AE9D121F8428 for ; Fri, 25 Jan 2013 13:28:09 -0800 (PST) Received: from smtp01.binero.se (unknown [195.74.38.28]) by vsp-authed-02-02.binero.net (Halon Mail Gateway) with ESMTP for ; Fri, 25 Jan 2013 22:28:02 +0100 (CET) Received: from [192.168.2.42] (h79n2fls31o933.telia.com [212.181.137.79]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-09-01.atm.binero.net (Postfix) with ESMTPA id 512083A11B for ; Fri, 25 Jan 2013 22:28:02 +0100 (CET) Message-ID: <5102F8E4.3030501@omnitor.se> Date: Fri, 25 Jan 2013 22:28:04 +0100 From: Gunnar Hellstrom User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: rtcweb@ietf.org References: <50F97303.4070906@ericsson.com> In-Reply-To: <50F97303.4070906@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] WG Last Call: draft-ietf-rtcweb-use-cases-and-requirements-10 - 4.3.2.1 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 25 Jan 2013 21:28:10 -0000 On 2013-01-18 17:06, Magnus Westerlund wrote: > WG, > > I would here by like to announce a two week WG last call that ends on > the 1st of February. > > Document is available here: > > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-use-cases-and-requirements/ In section 4.3.2.1 it is said " Alice uses her web browser with a service something like Skype to be able to phone PSTN numbers. " I think it is a habit of IETF to not reference brand names. It can be replaced with " Alice uses her web browser with a service that enables her to phone PSTN numbers." /Gunnar From gunnar.hellstrom@omnitor.se Fri Jan 25 13:57:19 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25D5C21F886E for ; Fri, 25 Jan 2013 13:57:19 -0800 (PST) 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 iKiksA3Va26D for ; Fri, 25 Jan 2013 13:57:18 -0800 (PST) Received: from vsp-authed-01-02.binero.net (vsp-authed02.binero.net [195.74.38.226]) by ietfa.amsl.com (Postfix) with SMTP id E434421F886C for ; Fri, 25 Jan 2013 13:57:17 -0800 (PST) Received: from smtp01.binero.se (unknown [195.74.38.28]) by vsp-authed-01-02.binero.net (Halon Mail Gateway) with ESMTP for ; Fri, 25 Jan 2013 22:51:56 +0100 (CET) Received: from [192.168.2.42] (h79n2fls31o933.telia.com [212.181.137.79]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-08-01.atm.binero.net (Postfix) with ESMTPA id 5A6193A1EF for ; Fri, 25 Jan 2013 22:51:56 +0100 (CET) Message-ID: <5102FE7E.5000109@omnitor.se> Date: Fri, 25 Jan 2013 22:51:58 +0100 From: Gunnar Hellstrom User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: rtcweb@ietf.org References: <50F97303.4070906@ericsson.com> In-Reply-To: <50F97303.4070906@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] WG Last Call: draft-ietf-rtcweb-use-cases-and-requirements-10 - real-time text X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 25 Jan 2013 21:57:19 -0000 On 2013-01-18 17:06, Magnus Westerlund wrote: > WG, > > I would here by like to announce a two week WG last call that ends on > the 1st of February. > > Document is available here: > > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-use-cases-and-requirements/ > We had a good discussion in December on inclusion of the real-time text medium. It was decided to document three alternative implementations with pros and cons and after that decide which one to standardize together with the two already mentioned media in rtcweb. The three alternatives were: 1.) An RTP medium similar to audio and video, using RFC 4103 transport. 2.) A semi-reliable data channel with a standardized label. 3.) A web service based protocol, such as BOSH and XEP-0301 for real-time text in XMPP with a well specified integration with rtcweb in a common application. For all three cases, there is a need to have a specification for how calls with audio, video and real-time text are exchanged with SIP based environments, e.g. for interaction with RFC 6443 based emergency services. Text is a natural part of today's video and audio applications, so all use cases look quite meager without it. I suggest that we make a rapid mini-investigation on the real-time text alternatives and decide which variant to include in a use case. /Gunnar From gunnar.hellstrom@omnitor.se Fri Jan 25 14:30:52 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FCD621F87F5 for ; Fri, 25 Jan 2013 14:30:52 -0800 (PST) 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 UQX1C32ePS2z for ; Fri, 25 Jan 2013 14:30:51 -0800 (PST) Received: from vsp-authed-01-02.binero.net (vsp-authed02.binero.net [195.74.38.226]) by ietfa.amsl.com (Postfix) with SMTP id C7B0A21F87F3 for ; Fri, 25 Jan 2013 14:30:50 -0800 (PST) Received: from smtp01.binero.se (unknown [195.74.38.28]) by vsp-authed-01-02.binero.net (Halon Mail Gateway) with ESMTP for ; Fri, 25 Jan 2013 23:30:13 +0100 (CET) Received: from [192.168.2.42] (h79n2fls31o933.telia.com [212.181.137.79]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-08-01.atm.binero.net (Postfix) with ESMTPA id 5A6193A1EF for ; Fri, 25 Jan 2013 22:51:56 +0100 (CET) Message-ID: <5102FE7E.5000109@omnitor.se> Date: Fri, 25 Jan 2013 22:51:58 +0100 From: Gunnar Hellstrom User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: rtcweb@ietf.org References: <50F97303.4070906@ericsson.com> In-Reply-To: <50F97303.4070906@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] WG Last Call: draft-ietf-rtcweb-use-cases-and-requirements-10 - real-time text X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 25 Jan 2013 22:30:52 -0000 On 2013-01-18 17:06, Magnus Westerlund wrote: > WG, > > I would here by like to announce a two week WG last call that ends on > the 1st of February. > > Document is available here: > > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-use-cases-and-requirements/ > We had a good discussion in December on inclusion of the real-time text medium. It was decided to document three alternative implementations with pros and cons and after that decide which one to standardize together with the two already mentioned media in rtcweb. The three alternatives were: 1.) An RTP medium similar to audio and video, using RFC 4103 transport. 2.) A semi-reliable data channel with a standardized label. 3.) A web service based protocol, such as BOSH and XEP-0301 for real-time text in XMPP with a well specified integration with rtcweb in a common application. For all three cases, there is a need to have a specification for how calls with audio, video and real-time text are exchanged with SIP based environments, e.g. for interaction with RFC 6443 based emergency services. Text is a natural part of today's video and audio applications, so all use cases look quite meager without it. I suggest that we make a rapid mini-investigation on the real-time text alternatives and decide which variant to include in a use case. /Gunnar From harald@alvestrand.no Sat Jan 26 00:53:24 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ACFC21F86F4 for ; Sat, 26 Jan 2013 00:53:24 -0800 (PST) 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 88z+XlfnJbTs for ; Sat, 26 Jan 2013 00:53:23 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id A883F21F86B8 for ; Sat, 26 Jan 2013 00:53:21 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4CEB839E1DB; Sat, 26 Jan 2013 09:53:19 +0100 (CET) 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 HeEeNAaXDtk4; Sat, 26 Jan 2013 09:53:11 +0100 (CET) Received: from [IPv6:2001:470:de0a:27:31e1:81c4:c6a6:8ee9] (unknown [IPv6:2001:470:de0a:27:31e1:81c4:c6a6:8ee9]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 3156F39E0C8; Sat, 26 Jan 2013 09:53:11 +0100 (CET) Message-ID: <51039976.1000600@alvestrand.no> Date: Sat, 26 Jan 2013 09:53:10 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Gunnar Hellstrom References: <50F97303.4070906@ericsson.com> <5102FE7E.5000109@omnitor.se> In-Reply-To: <5102FE7E.5000109@omnitor.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rtcweb@ietf.org Subject: Re: [rtcweb] WG Last Call: draft-ietf-rtcweb-use-cases-and-requirements-10 - real-time text X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 26 Jan 2013 08:53:24 -0000 On 01/25/2013 10:51 PM, Gunnar Hellstrom wrote: > On 2013-01-18 17:06, Magnus Westerlund wrote: >> WG, >> >> I would here by like to announce a two week WG last call that ends on >> the 1st of February. >> >> Document is available here: >> >> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-use-cases-and-requirements/ >> >> > > We had a good discussion in December on inclusion of the real-time > text medium. > > It was decided to document three alternative implementations with pros > and cons and after that decide which one to standardize together with > the two already mentioned media in rtcweb. > > The three alternatives were: > 1.) An RTP medium similar to audio and video, using RFC 4103 transport. > > 2.) A semi-reliable data channel with a standardized label. > > 3.) A web service based protocol, such as BOSH and XEP-0301 for > real-time text in XMPP with a well specified integration with rtcweb > in a common application. > > For all three cases, there is a need to have a specification for how > calls with audio, video and real-time text are exchanged with SIP > based environments, e.g. for interaction with RFC 6443 based emergency > services. > > Text is a natural part of today's video and audio applications, so all > use cases look quite meager without it. > > I suggest that we make a rapid mini-investigation on the real-time > text alternatives and decide which variant to include in a use case. I disagree with this summary on two points: - I think it's broken to choose between implementation strategies in an use case. The use case needs to specify the function that we want to achieve. - I don't recall a declaration by the chairs that text would be included in the use cases for RTCWEB. My memory is flaky, so if you can find the declaration by the chairs, I'm happy to let the last point pass. From dromasca@avaya.com Sun Jan 27 01:14:11 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0ED321F8621 for ; Sun, 27 Jan 2013 01:14:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.899 X-Spam-Level: X-Spam-Status: No, score=-102.899 tagged_above=-999 required=5 tests=[AWL=-0.300, 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 LMlcF1Ubc-mg for ; Sun, 27 Jan 2013 01:14:10 -0800 (PST) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id 9F8AE21F84F8 for ; Sun, 27 Jan 2013 01:14:10 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAP0QA1HGmAcF/2dsb2JhbABFgmu7ZxZzgh4BAQEBAgEBAQEPCx00EAcEAgEIDQQEAQELFAkHJwsUCQgCBAESCBqHZwYBC6FYnHAEkF5hA5waijuCd4Ik X-IronPort-AV: E=Sophos;i="4.84,541,1355115600"; d="scan'208";a="46102694" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 27 Jan 2013 04:13:39 -0500 Received: from unknown (HELO AZ-FFEXHC02.global.avaya.com) ([135.64.58.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 27 Jan 2013 04:13:36 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC02.global.avaya.com ([135.64.58.12]) with mapi id 14.02.0328.009; Sun, 27 Jan 2013 04:14:24 -0500 From: "Romascanu, Dan (Dan)" To: "Cullen Jennings (fluffy)" , "rtcweb@ietf.org" Thread-Topic: Conclusion statement for Recommended Audio Codecs call Thread-Index: AQHN+lJlS8xNYunZw0yrsQtXbpVqGphc6GWg Date: Sun, 27 Jan 2013 09:14:23 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA076D1E@AZ-FFEXMB04.global.avaya.com> References: <50FD4C4B.9020700@ericsson.com> <50FEB1EC.9060803@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.45] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [rtcweb] Conclusion statement for Recommended Audio Codecs call X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 27 Jan 2013 09:14:12 -0000 Hi WG chairs, Clarification question:=20 > In lieu of additional normative text, we believe the WG discussion > supports the inclusion of a new section on "Additional Relevant Codecs". Inclusion where?=20 Thanks and Regards, Dan > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf > Of Cullen Jennings (fluffy) > Sent: Thursday, January 24, 2013 6:47 PM > To: rtcweb@ietf.org > Subject: Re: [rtcweb] Conclusion statement for Recommended Audio Codecs > call >=20 >=20 > We have been running a call for consensus regarding Selecting > Recommended Audio Codecs. >=20 > At this point the chairs are calling this as "no WG consensus". >=20 > We can however note a strong interest in a non-normative listing of > potentially important codecs including a description why they should be > considered to be supported in WebRTC implementations. >=20 > In lieu of additional normative text, we believe the WG discussion > supports the inclusion of a new section on "Additional Relevant Codecs". > That can contain a list of codecs which are relevant in specific > contexts, along with a short description of the context for each. > Specifically there seems to be interest in understanding the advantages > and costs of G.722, AMR, and AMR-WB. We hope that text would broaden > understanding of the WebRTC use case contexts. >=20 > The WG chairs > Magnus, Ted and Cullen >=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From eburger@cs.georgetown.edu Sun Jan 27 11:38:47 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF37121F86EC for ; Sun, 27 Jan 2013 11:38:47 -0800 (PST) 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 N9FigTjtTUmo for ; Sun, 27 Jan 2013 11:38:47 -0800 (PST) Received: from karma.cs.georgetown.edu (karma.cs.georgetown.edu [141.161.20.3]) by ietfa.amsl.com (Postfix) with ESMTP id 2041221F86E8 for ; Sun, 27 Jan 2013 11:38:47 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by karma.cs.georgetown.edu (Postfix) with ESMTP id 27E6F43052; Sun, 27 Jan 2013 14:38:42 -0500 (EST) X-Virus-Scanned: by amavisd-new at cs.georgetown.edu Received: from karma.cs.georgetown.edu ([127.0.0.1]) by localhost (karma.cs.georgetown.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P+2OIiFGJCds; Sun, 27 Jan 2013 14:38:40 -0500 (EST) Received: from [192.168.15.177] (ip68-100-199-8.dc.dc.cox.net [68.100.199.8]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by karma.cs.georgetown.edu (Postfix) with ESMTP id 3B1A342C24; Sun, 27 Jan 2013 14:38:40 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Burger Eric In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA076D1E@AZ-FFEXMB04.global.avaya.com> Date: Sun, 27 Jan 2013 14:38:39 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <50FD4C4B.9020700@ericsson.com> <50FEB1EC.9060803@ericsson.com> <9904FB1B0159DA42B0B887B7FA8119CA076D1E@AZ-FFEXMB04.global.avaya.com> To: "Cullen Jennings (fluffy)" X-Mailer: Apple Mail (2.1499) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Conclusion statement for Recommended Audio Codecs call X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 27 Jan 2013 19:38:47 -0000 A different document would be good. No need to to have an argument over = non-normative text hold up publication. On Jan 27, 2013, at 4:14 AM, "Romascanu, Dan (Dan)" = wrote: > Hi WG chairs, >=20 > Clarification question:=20 >=20 >> In lieu of additional normative text, we believe the WG discussion >> supports the inclusion of a new section on "Additional Relevant = Codecs". >=20 > Inclusion where?=20 >=20 > Thanks and Regards, >=20 > Dan >=20 >=20 >=20 >=20 >> -----Original Message----- >> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On = Behalf >> Of Cullen Jennings (fluffy) >> Sent: Thursday, January 24, 2013 6:47 PM >> To: rtcweb@ietf.org >> Subject: Re: [rtcweb] Conclusion statement for Recommended Audio = Codecs >> call >>=20 >>=20 >> We have been running a call for consensus regarding Selecting >> Recommended Audio Codecs. >>=20 >> At this point the chairs are calling this as "no WG consensus". >>=20 >> We can however note a strong interest in a non-normative listing of >> potentially important codecs including a description why they should = be >> considered to be supported in WebRTC implementations. >>=20 >> In lieu of additional normative text, we believe the WG discussion >> supports the inclusion of a new section on "Additional Relevant = Codecs". >> That can contain a list of codecs which are relevant in specific >> contexts, along with a short description of the context for each. >> Specifically there seems to be interest in understanding the = advantages >> and costs of G.722, AMR, and AMR-WB. We hope that text would broaden >> understanding of the WebRTC use case contexts. >>=20 >> The WG chairs >> Magnus, Ted and Cullen >>=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 From prvs=37390435f7=aallen@rim.com Sun Jan 27 11:54:47 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1A0A21F8583 for ; Sun, 27 Jan 2013 11:54:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.203 X-Spam-Level: X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 T0JS3yBoeVTP for ; Sun, 27 Jan 2013 11:54:47 -0800 (PST) Received: from mhs061cnc.rim.net (mhs061cnc.rim.net [208.65.73.35]) by ietfa.amsl.com (Postfix) with ESMTP id D605521F8581 for ; Sun, 27 Jan 2013 11:54:46 -0800 (PST) X-AuditID: 0a412830-b7f646d0000038d1-28-510585fcc7b1 Received: from XCT104ADS.rim.net (xct104ads.rim.net [10.67.111.45]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by mhs061cnc.rim.net (SBG) with SMTP id DF.A7.14545.DF585015; Sun, 27 Jan 2013 13:54:37 -0600 (CST) Received: from XMB104ADS.rim.net ([fe80::2494:a63d:e3:723b]) by XCT104ADS.rim.net ([fe80::90f9:3b89:1d94:aa9b%22]) with mapi id 14.02.0318.001; Sun, 27 Jan 2013 13:54:36 -0600 From: Andrew Allen To: "eburger@cs.georgetown.edu" , "fluffy@cisco.com" Thread-Topic: [rtcweb] Conclusion statement for Recommended Audio Codecs call Thread-Index: AQHN+lJlS8xNYunZw0yrsQtXbpVqGphc6GWggAETWoD//5/fyg== Date: Sun, 27 Jan 2013 19:54:35 +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.67.110.253] Content-Type: text/plain; charset="iso-8859-1" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrPKsWRmVeSWpSXmKPExsXC5Zyvq/u3lTXQoLFP2OJM13p2i47JbBZr /7WzOzB7TPm9kdXj9sHdzB5LlvxkCmCOamC0SUosKQvOTM/Tt7NJzMvLL0ksSVVISS1OtlXy SU1PzFEIKMosS0yuVHDJLE7OSczMTS1SUshMsVUyUVIoyElMTs1NzSuxVUosKEjNS1Gy41LA ADZAZZl5Cql5yfkpmXnptkqewf66FhamlrqGSna6CZ08Gb/vrmIreCFR8eX4P6YGxt0iXYyc HBICJhItE74wQdhiEhfurWfrYuTiEBJoY5J4cmIJC4SzmVHix7sHbCBVbALKEst/z2AEsUUE UiTWrvzACmIzC6hL3Fl8jh3EFhbwkbj5YxMbRI2vxJWbU5khbCeJo6d+g9WzCKhK7L60CqyG V8BDYuuHS2C9nAKuEvufnQerZwS66PupNUwQ88Ulbj2ZD3WpgMSSPRA1EgKiEi8f/2OFsBUl /u79DnWPnsSNqVPYIGxtiWULXzND7BKUODnzCcsERtFZSMbOQtIyC0nLLCQtCxhZVjEK5mYU G5gZJucl6xVl5urlpZZsYgSlCEcNgx2M799bHGIU4GBU4uFNBaYOIdbEsuLK3EOMEhzMSiK8 8ytZAoV4UxIrq1KL8uOLSnNSiw8xugJDYiKzFHdyPjB95ZXEGxsY4OYoifOe/vUvQEggHZh+ slNTC1KLYOYwcXCC7OGSEikGJpHUosTSkox4UKqLLwYmO6kGxkTRTxYisw94RLD8WKXgMcs5 k2m75HYFduH2d/deqP0xL1gc1smwyPHow1sHjxpn7DGX22WV9aPVWFWonefBpxOHJ17d+XH6 JpXr3zt1VK/vdv4gkHbvfnXSNhZOveM3SwQZz/u6JDOdzykuvxKs7SFkosfN7NETWLzsuMR8 tuBLFW/27XW+q8RSnJFoqMVcVJwIAMl4gdZSAwAA Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Conclusion statement for Recommended Audio Codecs call X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 27 Jan 2013 19:54:47 -0000 Eric I totally agree. I think this document as well as being purely informational is also likely t= o become obsolete long before the mandatory to implement codecs are no longe= r required to be implemented. As a result making this part of the normative= document will likely mean regular updates or obsoletions of the normative d= ocument. I also think such information with a scope as defined by Cullen discussing w= hat codecs are currently used in other deployments and what the costs are is= not just relevant to RTCweb but also SIP and MMUSIC as well so maybe this s= hould be RAI area director sponsored and not a RTCweb WG document. Andrew ----- Original Message ----- From: Burger Eric [mailto:eburger@cs.georgetown.edu] Sent: Sunday, January 27, 2013 01:38 PM Central Standard Time=0A= To: Cullen Jennings (fluffy) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Conclusion statement for Recommended Audio Codecs call A different document would be good. No need to to have an argument over non-= normative text hold up publication. On Jan 27, 2013, at 4:14 AM, "Romascanu, Dan (Dan)" wro= te: > Hi WG chairs, > > Clarification question: > >> In lieu of additional normative text, we believe the WG discussion >> supports the inclusion of a new section on "Additional Relevant Codecs". > > Inclusion where? > > Thanks and Regards, > > Dan > > > > >> -----Original Message----- >> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf >> Of Cullen Jennings (fluffy) >> Sent: Thursday, January 24, 2013 6:47 PM >> To: rtcweb@ietf.org >> Subject: Re: [rtcweb] Conclusion statement for Recommended Audio Codecs >> call >> >> >> We have been running a call for consensus regarding Selecting >> Recommended Audio Codecs. >> >> At this point the chairs are calling this as "no WG consensus". >> >> We can however note a strong interest in a non-normative listing of >> potentially important codecs including a description why they should be >> considered to be supported in WebRTC implementations. >> >> In lieu of additional normative text, we believe the WG discussion >> supports the inclusion of a new section on "Additional Relevant Codecs". >> That can contain a list of codecs which are relevant in specific >> contexts, along with a short description of the context for each. >> Specifically there seems to be interest in understanding the advantages >> and costs of G.722, AMR, and AMR-WB. We hope that text would broaden >> understanding of the WebRTC use case contexts. >> >> The WG chairs >> Magnus, Ted and Cullen >> >> >> _______________________________________________ >> 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 --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From dromasca@avaya.com Sun Jan 27 12:08:13 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EED5421F87F7 for ; Sun, 27 Jan 2013 12:08:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.407 X-Spam-Level: X-Spam-Status: No, score=-103.407 tagged_above=-999 required=5 tests=[AWL=0.192, BAYES_00=-2.599, 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 uMFyy7nP46zS for ; Sun, 27 Jan 2013 12:08:13 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id 0644821F853E for ; Sun, 27 Jan 2013 12:08:12 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAP0QA1HGmAcF/2dsb2JhbABFDoJdu2cWc4IeAQEBAQMBAQEPCx00CwwEAgEIDQEDBAEBAQoUCQcnCxQJCAIEAQ0FCBqHbQELoViccASQXmEDnBqKO4I5PoIk X-IronPort-AV: E=Sophos;i="4.84,541,1355115600"; d="scan'208";a="341284664" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 27 Jan 2013 15:08:06 -0500 Received: from unknown (HELO AZ-FFEXHC03.global.avaya.com) ([135.64.58.13]) by co300216-co-erhwest-out.avaya.com with ESMTP; 27 Jan 2013 15:07:36 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC03.global.avaya.com ([135.64.58.13]) with mapi id 14.02.0328.009; Sun, 27 Jan 2013 15:08:27 -0500 From: "Romascanu, Dan (Dan)" To: Burger Eric , "Cullen Jennings (fluffy)" Thread-Topic: [rtcweb] Conclusion statement for Recommended Audio Codecs call Thread-Index: AQHN+lJlS8xNYunZw0yrsQtXbpVqGphc6GWggAECl4D//7RrQA== Date: Sun, 27 Jan 2013 20:08:26 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA0786E3@AZ-FFEXMB04.global.avaya.com> References: <50FD4C4B.9020700@ericsson.com> <50FEB1EC.9060803@ericsson.com> <9904FB1B0159DA42B0B887B7FA8119CA076D1E@AZ-FFEXMB04.global.avaya.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.45] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Conclusion statement for Recommended Audio Codecs call X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 27 Jan 2013 20:08:14 -0000 +1 Dan > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf > Of Burger Eric > Sent: Sunday, January 27, 2013 9:39 PM > To: Cullen Jennings (fluffy) > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] Conclusion statement for Recommended Audio Codecs > call >=20 > A different document would be good. No need to to have an argument over > non-normative text hold up publication. >=20 > On Jan 27, 2013, at 4:14 AM, "Romascanu, Dan (Dan)" > wrote: >=20 > > Hi WG chairs, > > > > Clarification question: > > > >> In lieu of additional normative text, we believe the WG discussion > >> supports the inclusion of a new section on "Additional Relevant > Codecs". > > > > Inclusion where? > > > > Thanks and Regards, > > > > Dan > > > > > > > > > >> -----Original Message----- > >> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > >> Behalf Of Cullen Jennings (fluffy) > >> Sent: Thursday, January 24, 2013 6:47 PM > >> To: rtcweb@ietf.org > >> Subject: Re: [rtcweb] Conclusion statement for Recommended Audio > >> Codecs call > >> > >> > >> We have been running a call for consensus regarding Selecting > >> Recommended Audio Codecs. > >> > >> At this point the chairs are calling this as "no WG consensus". > >> > >> We can however note a strong interest in a non-normative listing of > >> potentially important codecs including a description why they should > >> be considered to be supported in WebRTC implementations. > >> > >> In lieu of additional normative text, we believe the WG discussion > >> supports the inclusion of a new section on "Additional Relevant > Codecs". > >> That can contain a list of codecs which are relevant in specific > >> contexts, along with a short description of the context for each. > >> Specifically there seems to be interest in understanding the > >> advantages and costs of G.722, AMR, and AMR-WB. We hope that text > >> would broaden understanding of the WebRTC use case contexts. > >> > >> The WG chairs > >> Magnus, Ted and Cullen > >> > >> > >> _______________________________________________ > >> 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 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From bernard_aboba@hotmail.com Sun Jan 27 13:02:40 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 361F021F869E for ; Sun, 27 Jan 2013 13:02:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.319 X-Spam-Level: X-Spam-Status: No, score=-102.319 tagged_above=-999 required=5 tests=[AWL=0.280, 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 Q9khoK5C4Xbt for ; Sun, 27 Jan 2013 13:02:39 -0800 (PST) Received: from blu0-omc3-s16.blu0.hotmail.com (blu0-omc3-s16.blu0.hotmail.com [65.55.116.91]) by ietfa.amsl.com (Postfix) with ESMTP id 8C64821F87A5 for ; Sun, 27 Jan 2013 13:02:39 -0800 (PST) Received: from BLU405-EAS409 ([65.55.116.72]) by blu0-omc3-s16.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 27 Jan 2013 13:02:38 -0800 X-EIP: [4x/RBxfda9H3/wQ3DmReaN9OiyhttFkz] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit References: <50FD4C4B.9020700@ericsson.com> <50FEB1EC.9060803@ericsson.com> <9904FB1B0159DA42B0B887B7FA8119CA076D1E@AZ-FFEXMB04.global.avaya.com> <9904FB1B0159DA42B0B887B7FA8119CA0786E3@AZ-FFEXMB04.global.avaya.com> From: Bernard Aboba MIME-Version: 1.0 (1.0) In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA0786E3@AZ-FFEXMB04.global.avaya.com> Date: Sun, 27 Jan 2013 13:04:21 -0800 To: "Romascanu, Dan (Dan)" X-OriginalArrivalTime: 27 Jan 2013 21:02:38.0624 (UTC) FILETIME=[A3922200:01CDFCD1] Cc: "Cullen Jennings \(fluffy\)" , Burger Eric , "rtcweb@ietf.org" Subject: Re: [rtcweb] Conclusion statement for Recommended Audio Codecs call X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 27 Jan 2013 21:02:40 -0000 I agree. On Jan 27, 2013, at 12:08, "Romascanu, Dan (Dan)" wrote: > +1 > > Dan > > > >> -----Original Message----- >> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf >> Of Burger Eric >> Sent: Sunday, January 27, 2013 9:39 PM >> To: Cullen Jennings (fluffy) >> Cc: rtcweb@ietf.org >> Subject: Re: [rtcweb] Conclusion statement for Recommended Audio Codecs >> call >> >> A different document would be good. No need to to have an argument over >> non-normative text hold up publication. >> >> On Jan 27, 2013, at 4:14 AM, "Romascanu, Dan (Dan)" >> wrote: >> >>> Hi WG chairs, >>> >>> Clarification question: >>> >>>> In lieu of additional normative text, we believe the WG discussion >>>> supports the inclusion of a new section on "Additional Relevant >> Codecs". >>> >>> Inclusion where? >>> >>> Thanks and Regards, >>> >>> Dan >>> >>> >>> >>> >>>> -----Original Message----- >>>> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On >>>> Behalf Of Cullen Jennings (fluffy) >>>> Sent: Thursday, January 24, 2013 6:47 PM >>>> To: rtcweb@ietf.org >>>> Subject: Re: [rtcweb] Conclusion statement for Recommended Audio >>>> Codecs call >>>> >>>> >>>> We have been running a call for consensus regarding Selecting >>>> Recommended Audio Codecs. >>>> >>>> At this point the chairs are calling this as "no WG consensus". >>>> >>>> We can however note a strong interest in a non-normative listing of >>>> potentially important codecs including a description why they should >>>> be considered to be supported in WebRTC implementations. >>>> >>>> In lieu of additional normative text, we believe the WG discussion >>>> supports the inclusion of a new section on "Additional Relevant >> Codecs". >>>> That can contain a list of codecs which are relevant in specific >>>> contexts, along with a short description of the context for each. >>>> Specifically there seems to be interest in understanding the >>>> advantages and costs of G.722, AMR, and AMR-WB. We hope that text >>>> would broaden understanding of the WebRTC use case contexts. >>>> >>>> The WG chairs >>>> Magnus, Ted and Cullen >>>> >>>> >>>> _______________________________________________ >>>> 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 magnus.westerlund@ericsson.com Mon Jan 28 00:13:24 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B30E21F8901 for ; Mon, 28 Jan 2013 00:13:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.906 X-Spam-Level: X-Spam-Status: No, score=-104.906 tagged_above=-999 required=5 tests=[AWL=1.343, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 aEDukhegRgiO for ; Mon, 28 Jan 2013 00:13:24 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id AB9C521F88A2 for ; Mon, 28 Jan 2013 00:13:16 -0800 (PST) X-AuditID: c1b4fb25-b7f366d000004d10-b9-510632d244be Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 15.E6.19728.2D236015; Mon, 28 Jan 2013 09:12:02 +0100 (CET) Received: from [127.0.0.1] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.279.1; Mon, 28 Jan 2013 09:12:02 +0100 Message-ID: <510632D1.4020704@ericsson.com> Date: Mon, 28 Jan 2013 09:12:01 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" References: <50FD4C4B.9020700@ericsson.com> <50FEB1EC.9060803@ericsson.com> <9904FB1B0159DA42B0B887B7FA8119CA076D1E@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA076D1E@AZ-FFEXMB04.global.avaya.com> X-Enigmail-Version: 1.5 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprBLMWRmVeSWpSXmKPExsUyM+Jvra6EMVugwddH4hZff/5gteiYzGax 9l87uwOzx8GVc9g9pvzeyOqxZMlPpgDmKC6blNSczLLUIn27BK6M2wt/MxVsEa/4fOAYYwNj t3AXIyeHhICJxMX2r4wQtpjEhXvr2boYuTiEBE4ySnzb/pMJwlnOKLF+wX0WkCpeAW2JRev/ sncxcnCwCKhKvF5gBxJmE7CQuPmjkQ3EFhUIlthwcBUTRLmgxMmZT8BaRQT0JT7OWMMMYjML REr8PfgYrEZYwAeodxNYr5DAXGaJxw/lQWxOgSCJloO/GUFWSQiIS6x5wwHRqicx5WoLI4Qt L9G8dTYzRKu2RENTB+sERqFZSDbPQtIyC0nLAkbmVYzsuYmZOenlRpsYgaF7cMtv1R2Md86J HGKU5mBREucNd70QICSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoFxyf8Pwbwf5/Xbhz+zue+z 3aXkTe72rX1pl/Pmqeauv1F/iD1ZUCPghF7X0vtud+cfad03oeH9/oVqrsslrlw8NqmoMOXr r44pO0OelRTeS2OZ8KJEvDd6x7JFAWm+zN+LzZ9V2q1bycc6c4lwf+kN197mf5/7nvbm9R/R /OcfPXGW5+Wv5+bcV2Ipzkg01GIuKk4EAC7mhxErAgAA Cc: "Cullen Jennings \(fluffy\)" , "rtcweb@ietf.org" Subject: Re: [rtcweb] Conclusion statement for Recommended Audio Codecs call X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 28 Jan 2013 08:13:24 -0000 Hi, We chairs was considering inclusion in draft-ietf-webrtc-audio, but we didn't have any strong opinions on this. Based on that several WG participants thinks this should be an independent document, I thus decided that we will start out with an independent document. If the WG feels differently later we can always fold the text into the audio codec and processing requirements document. I would recommend that the individuals interested in contributing a codec writes an independent submission with focus on the codec considerations around the codec(s) they are interested in. Then we can merge this into a common WG document. Cheers Magnus On 2013-01-27 10:14, Romascanu, Dan (Dan) wrote: > Hi WG chairs, > > Clarification question: > >> In lieu of additional normative text, we believe the WG discussion >> supports the inclusion of a new section on "Additional Relevant Codecs". > > Inclusion where? > > Thanks and Regards, > > Dan > > > > >> -----Original Message----- >> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf >> Of Cullen Jennings (fluffy) >> Sent: Thursday, January 24, 2013 6:47 PM >> To: rtcweb@ietf.org >> Subject: Re: [rtcweb] Conclusion statement for Recommended Audio Codecs >> call >> >> >> We have been running a call for consensus regarding Selecting >> Recommended Audio Codecs. >> >> At this point the chairs are calling this as "no WG consensus". >> >> We can however note a strong interest in a non-normative listing of >> potentially important codecs including a description why they should be >> considered to be supported in WebRTC implementations. >> >> In lieu of additional normative text, we believe the WG discussion >> supports the inclusion of a new section on "Additional Relevant Codecs". >> That can contain a list of codecs which are relevant in specific >> contexts, along with a short description of the context for each. >> Specifically there seems to be interest in understanding the advantages >> and costs of G.722, AMR, and AMR-WB. We hope that text would broaden >> understanding of the WebRTC use case contexts. >> >> The WG chairs >> Magnus, Ted and Cullen >> >> >> _______________________________________________ >> 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 > > -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From fluffy@iii.ca Mon Jan 28 06:20:11 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E460921F8865 for ; Mon, 28 Jan 2013 06:20:10 -0800 (PST) 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 MkySVA7yWLxo for ; Mon, 28 Jan 2013 06:20:09 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 5087621F884B for ; Mon, 28 Jan 2013 06:20:07 -0800 (PST) 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 CE41322E200 for ; Mon, 28 Jan 2013 09:20:00 -0500 (EST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Cullen Jennings In-Reply-To: <510632D1.4020704@ericsson.com> Date: Mon, 28 Jan 2013 07:19:58 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <50FD4C4B.9020700@ericsson.com> <50FEB1EC.9060803@ericsson.com> <9904FB1B0159DA42B0B887B7FA8119CA076D1E@AZ-FFEXMB04.global.avaya.com> <510632D1.4020704@ericsson.com> To: "rtcweb@ietf.org" X-Mailer: Apple Mail (2.1499) Subject: Re: [rtcweb] Conclusion statement for Recommended Audio Codecs call X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 28 Jan 2013 14:20:11 -0000 I've received a bunch of emails on this. So just to try and be clear, = what the chairs sent out was there was "no consensus" on the questions = we asked. The question of what, if any additional MTI audio codecs might = get added is not resolved in any way.=20 On Jan 28, 2013, at 1:12 AM, Magnus Westerlund = wrote: > Hi, >=20 > We chairs was considering inclusion in draft-ietf-webrtc-audio, but we > didn't have any strong opinions on this. Based on that several WG > participants thinks this should be an independent document, I thus > decided that we will start out with an independent document. If the WG > feels differently later we can always fold the text into the audio = codec > and processing requirements document. >=20 > I would recommend that the individuals interested in contributing a > codec writes an independent submission with focus on the codec > considerations around the codec(s) they are interested in. Then we can > merge this into a common WG document. >=20 > Cheers >=20 > Magnus >=20 >=20 > On 2013-01-27 10:14, Romascanu, Dan (Dan) wrote: >> Hi WG chairs, >>=20 >> Clarification question:=20 >>=20 >>> In lieu of additional normative text, we believe the WG discussion >>> supports the inclusion of a new section on "Additional Relevant = Codecs". >>=20 >> Inclusion where?=20 >>=20 >> Thanks and Regards, >>=20 >> Dan >>=20 >>=20 >>=20 >>=20 >>> -----Original Message----- >>> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On = Behalf >>> Of Cullen Jennings (fluffy) >>> Sent: Thursday, January 24, 2013 6:47 PM >>> To: rtcweb@ietf.org >>> Subject: Re: [rtcweb] Conclusion statement for Recommended Audio = Codecs >>> call >>>=20 >>>=20 >>> We have been running a call for consensus regarding Selecting >>> Recommended Audio Codecs. >>>=20 >>> At this point the chairs are calling this as "no WG consensus". >>>=20 >>> We can however note a strong interest in a non-normative listing of >>> potentially important codecs including a description why they should = be >>> considered to be supported in WebRTC implementations. >>>=20 >>> In lieu of additional normative text, we believe the WG discussion >>> supports the inclusion of a new section on "Additional Relevant = Codecs". >>> That can contain a list of codecs which are relevant in specific >>> contexts, along with a short description of the context for each. >>> Specifically there seems to be interest in understanding the = advantages >>> and costs of G.722, AMR, and AMR-WB. We hope that text would broaden >>> understanding of the WebRTC use case contexts. >>>=20 >>> The WG chairs >>> Magnus, Ted and Cullen >>>=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 >>=20 >>=20 >=20 >=20 > --=20 >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From keith.drage@alcatel-lucent.com Mon Jan 28 07:30:13 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AA3221F87C4 for ; Mon, 28 Jan 2013 07:30:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.249 X-Spam-Level: X-Spam-Status: No, score=-109.249 tagged_above=-999 required=5 tests=[AWL=1.000, 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 TSleRHsdfMUM for ; Mon, 28 Jan 2013 07:30:10 -0800 (PST) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by ietfa.amsl.com (Postfix) with ESMTP id A1B5621F8763 for ; Mon, 28 Jan 2013 07:30:10 -0800 (PST) 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 r0SFTcji029140 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 28 Jan 2013 16:29:58 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.48]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Mon, 28 Jan 2013 16:29:48 +0100 From: "DRAGE, Keith (Keith)" To: Bernard Aboba , "Romascanu, Dan (Dan)" Date: Mon, 28 Jan 2013 16:29:48 +0100 Thread-Topic: [rtcweb] Conclusion statement for Recommended Audio Codecs call Thread-Index: Ac380ai0MiLuUkreRIyK3/kLOuaWqAAEwlTg Message-ID: References: <50FD4C4B.9020700@ericsson.com> <50FEB1EC.9060803@ericsson.com> <9904FB1B0159DA42B0B887B7FA8119CA076D1E@AZ-FFEXMB04.global.avaya.com> <9904FB1B0159DA42B0B887B7FA8119CA0786E3@AZ-FFEXMB04.global.avaya.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.13 Cc: "Cullen Jennings \(fluffy\)" , Burger Eric , "rtcweb@ietf.org" Subject: Re: [rtcweb] Conclusion statement for Recommended Audio Codecs call X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 28 Jan 2013 15:30:13 -0000 Tell me how that does not take us back to a position where you have already= failed to obtain consensus. Keith > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf > Of Bernard Aboba > Sent: 27 January 2013 21:04 > To: Romascanu, Dan (Dan) > Cc: Cullen Jennings (fluffy); Burger Eric; rtcweb@ietf.org > Subject: Re: [rtcweb] Conclusion statement for Recommended Audio Codecs > call >=20 > I agree. >=20 > On Jan 27, 2013, at 12:08, "Romascanu, Dan (Dan)" > wrote: >=20 > > +1 > > > > Dan > > > > > > > >> -----Original Message----- > >> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > Behalf > >> Of Burger Eric > >> Sent: Sunday, January 27, 2013 9:39 PM > >> To: Cullen Jennings (fluffy) > >> Cc: rtcweb@ietf.org > >> Subject: Re: [rtcweb] Conclusion statement for Recommended Audio Codec= s > >> call > >> > >> A different document would be good. No need to to have an argument ove= r > >> non-normative text hold up publication. > >> > >> On Jan 27, 2013, at 4:14 AM, "Romascanu, Dan (Dan)" > > >> wrote: > >> > >>> Hi WG chairs, > >>> > >>> Clarification question: > >>> > >>>> In lieu of additional normative text, we believe the WG discussion > >>>> supports the inclusion of a new section on "Additional Relevant > >> Codecs". > >>> > >>> Inclusion where? > >>> > >>> Thanks and Regards, > >>> > >>> Dan > >>> > >>> > >>> > >>> > >>>> -----Original Message----- > >>>> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > >>>> Behalf Of Cullen Jennings (fluffy) > >>>> Sent: Thursday, January 24, 2013 6:47 PM > >>>> To: rtcweb@ietf.org > >>>> Subject: Re: [rtcweb] Conclusion statement for Recommended Audio > >>>> Codecs call > >>>> > >>>> > >>>> We have been running a call for consensus regarding Selecting > >>>> Recommended Audio Codecs. > >>>> > >>>> At this point the chairs are calling this as "no WG consensus". > >>>> > >>>> We can however note a strong interest in a non-normative listing of > >>>> potentially important codecs including a description why they should > >>>> be considered to be supported in WebRTC implementations. > >>>> > >>>> In lieu of additional normative text, we believe the WG discussion > >>>> supports the inclusion of a new section on "Additional Relevant > >> Codecs". > >>>> That can contain a list of codecs which are relevant in specific > >>>> contexts, along with a short description of the context for each. > >>>> Specifically there seems to be interest in understanding the > >>>> advantages and costs of G.722, AMR, and AMR-WB. We hope that text > >>>> would broaden understanding of the WebRTC use case contexts. > >>>> > >>>> The WG chairs > >>>> Magnus, Ted and Cullen > >>>> > >>>> > >>>> _______________________________________________ > >>>> 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 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From stephane.proust@orange.com Mon Jan 28 08:03:04 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECEDB21F870E for ; Mon, 28 Jan 2013 08:03:04 -0800 (PST) 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, 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 fkU8h6p7-DLK for ; Mon, 28 Jan 2013 08:03:04 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 0DEDB21F86FA for ; Mon, 28 Jan 2013 08:02:58 -0800 (PST) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 81064324279; Mon, 28 Jan 2013 17:02:57 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 634202380A6; Mon, 28 Jan 2013 17:02:57 +0100 (CET) Received: from PEXCVZYM14.corporate.adroot.infra.ftgroup ([fe80::a42f:c628:bc76:d592]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0318.004; Mon, 28 Jan 2013 17:02:56 +0100 From: To: Magnus Westerlund , "Romascanu, Dan (Dan)" Thread-Topic: [rtcweb] Conclusion statement for Recommended Audio Codecs call Thread-Index: AQHN/S8mkLzfDqN6Ck6wzddU0ym4y5he2MLw Date: Mon, 28 Jan 2013 16:02:56 +0000 Message-ID: <29466_1359388977_5106A131_29466_1646_1_2842AD9A45C83B44B57635FD4831E60A079E39@PEXCVZYM14.corporate.adroot.infra.ftgroup> References: <50FD4C4B.9020700@ericsson.com> <50FEB1EC.9060803@ericsson.com> <9904FB1B0159DA42B0B887B7FA8119CA076D1E@AZ-FFEXMB04.global.avaya.com> <510632D1.4020704@ericsson.com> In-Reply-To: <510632D1.4020704@ericsson.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.10.24.110314 Cc: "Cullen Jennings \(fluffy\)" , "rtcweb@ietf.org" Subject: Re: [rtcweb] Conclusion statement for Recommended Audio Codecs call X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 28 Jan 2013 16:03:05 -0000 Hello, > We chairs was considering inclusion in draft-ietf-webrtc-audio, but we di= dn't have any strong opinions on this > I thus decided that we will start out with an independent document If the Chairs have still no strong opinion about this, I would request to l= eave this somewhat editorial issue still open. It makes more sense that all the relevant information for audio and especia= lly the relevant codecs with their different status be clearly listed in th= e same "webrtc audio" specification. Especially because we want to address = the same interoperability issue. This will be more consistent and readable. Then, if more informative text on additional codecs is needed, a separate d= ocument can be considered to avoid overloading this webrtc audio document w= ith purely informative text. St=E9phane=09 -----Message d'origine----- De=A0: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] De la part = de Magnus Westerlund Envoy=E9=A0: lundi 28 janvier 2013 09:12 =C0=A0: Romascanu, Dan (Dan) Cc=A0: Cullen Jennings (fluffy); rtcweb@ietf.org Objet=A0: Re: [rtcweb] Conclusion statement for Recommended Audio Codecs ca= ll Hi, We chairs was considering inclusion in draft-ietf-webrtc-audio, but we didn= 't have any strong opinions on this. Based on that several WG participants = thinks this should be an independent document, I thus decided that we will = start out with an independent document. If the WG feels differently later w= e can always fold the text into the audio codec and processing requirements= document. I would recommend that the individuals interested in contributing a codec w= rites an independent submission with focus on the codec considerations arou= nd the codec(s) they are interested in. Then we can merge this into a commo= n WG document. Cheers Magnus On 2013-01-27 10:14, Romascanu, Dan (Dan) wrote: > Hi WG chairs, >=20 > Clarification question:=20 >=20 >> In lieu of additional normative text, we believe the WG discussion=20 >> supports the inclusion of a new section on "Additional Relevant Codecs". >=20 > Inclusion where?=20 >=20 > Thanks and Regards, >=20 > Dan >=20 >=20 >=20 >=20 >> -----Original Message----- >> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On=20 >> Behalf Of Cullen Jennings (fluffy) >> Sent: Thursday, January 24, 2013 6:47 PM >> To: rtcweb@ietf.org >> Subject: Re: [rtcweb] Conclusion statement for Recommended Audio=20 >> Codecs call >> >> >> We have been running a call for consensus regarding Selecting=20 >> Recommended Audio Codecs. >> >> At this point the chairs are calling this as "no WG consensus". >> >> We can however note a strong interest in a non-normative listing of=20 >> potentially important codecs including a description why they should=20 >> be considered to be supported in WebRTC implementations. >> >> In lieu of additional normative text, we believe the WG discussion=20 >> supports the inclusion of a new section on "Additional Relevant Codecs". >> That can contain a list of codecs which are relevant in specific=20 >> contexts, along with a short description of the context for each. >> Specifically there seems to be interest in understanding the=20 >> advantages and costs of G.722, AMR, and AMR-WB. We hope that text=20 >> would broaden understanding of the WebRTC use case contexts. >> >> The WG chairs >> Magnus, Ted and Cullen >> >> >> _______________________________________________ >> 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 >=20 --=20 Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 F=E4r=F6gatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ 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 magnus.westerlund@ericsson.com Mon Jan 28 08:11:04 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A63FF21F870E for ; Mon, 28 Jan 2013 08:11:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.055 X-Spam-Level: X-Spam-Status: No, score=-105.055 tagged_above=-999 required=5 tests=[AWL=1.194, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 shguAuKQOsfs for ; Mon, 28 Jan 2013 08:11:03 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 5AE9421F84F9 for ; Mon, 28 Jan 2013 08:11:03 -0800 (PST) X-AuditID: c1b4fb25-b7f366d000004d10-68-5106a3165d79 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id FD.FC.19728.613A6015; Mon, 28 Jan 2013 17:11:02 +0100 (CET) Received: from [127.0.0.1] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.279.1; Mon, 28 Jan 2013 17:11:02 +0100 Message-ID: <5106A315.3080502@ericsson.com> Date: Mon, 28 Jan 2013 17:11:01 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: stephane.proust@orange.com References: <50FD4C4B.9020700@ericsson.com> <50FEB1EC.9060803@ericsson.com> <9904FB1B0159DA42B0B887B7FA8119CA076D1E@AZ-FFEXMB04.global.avaya.com> <510632D1.4020704@ericsson.com> <29466_1359388977_5106A131_29466_1646_1_2842AD9A45C83B44B57635FD4831E60A079E39@PEXCVZYM14.corporate.adroot.infra.ftgroup> In-Reply-To: <29466_1359388977_5106A131_29466_1646_1_2842AD9A45C83B44B57635FD4831E60A079E39@PEXCVZYM14.corporate.adroot.infra.ftgroup> X-Enigmail-Version: 1.5 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKLMWRmVeSWpSXmKPExsUyM+Jvra7YYrZAg1kzFS2+/vzBatExmc1i 7b92dovWGVfYHFg8Dq6cw+4x5fdGVo8lS34yebQ8O8kWwBLFZZOSmpNZllqkb5fAlXH193/m gv8qFVM63jE2ME6U62Lk5JAQMJGYvLebDcIWk7hwbz2QzcUhJHCSUaJz/UJmCGc5o8SsC5uZ QKp4BbQllr5ZzgxiswioSqw8sQMsziZgIXHzRyPYJFGBYIkNB1dB1QtKnJz5hAXEFhGQk5jy 6DcLyFBmgQ5GiRfzfoENEhbwAWreBNYsJLCdRaJ5oxpIEadAG6PEqf1LgDo4gO4Tl1jzhgOk hllAT2LK1RZGCFteonnrbGaIXm2JhqYO1gmMQrOQ7J6FpGUWkpYFjMyrGNlzEzNz0suNNjEC g/rglt+qOxjvnBM5xCjNwaIkzhvueiFASCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dUA2NR4DSH m/Jf2xb8/7hvzqdtTtp8kjd+bv9x8uHanWslnOYx2/24IJV+7X7AlAvl9l8VLq1kahMPT7xV ftdaWFdC3yeKeeI3r2nHzC7Y5jpuW3i7cdG3slTZ3S9rhVRs/z9q8uowvS6bFl9bZ+rjdHJD 7ledvInVkaed4+/evjxP9vk5401Zz34rsRRnJBpqMRcVJwIAHsDqlzgCAAA= Cc: "Cullen Jennings \(fluffy\)" , "rtcweb@ietf.org" Subject: Re: [rtcweb] Conclusion statement for Recommended Audio Codecs call X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 28 Jan 2013 16:11:04 -0000 Hi Stéphane, Fair points, however, I am strongly believe that what is most relevant now is that the people interested in this actually generate some text. Thus having people submit text in individual documents. Then based on what we have and the WG's reaction to such text(s) we can decide if it makes more sense to fold it into the existing audio WG document or create a new WG document. Cheers Magnus On 2013-01-28 17:02, stephane.proust@orange.com wrote: > Hello, > >> We chairs was considering inclusion in draft-ietf-webrtc-audio, but we didn't have any strong opinions on this >> I thus decided that we will start out with an independent document > > If the Chairs have still no strong opinion about this, I would request to leave this somewhat editorial issue still open. > > It makes more sense that all the relevant information for audio and especially the relevant codecs with their different status be clearly listed in the same "webrtc audio" specification. Especially because we want to address the same interoperability issue. > This will be more consistent and readable. > > Then, if more informative text on additional codecs is needed, a separate document can be considered to avoid overloading this webrtc audio document with purely informative text. > > Stéphane > > > > -----Message d'origine----- > De : rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] De la part de Magnus Westerlund > Envoyé : lundi 28 janvier 2013 09:12 > Ŕ : Romascanu, Dan (Dan) > Cc : Cullen Jennings (fluffy); rtcweb@ietf.org > Objet : Re: [rtcweb] Conclusion statement for Recommended Audio Codecs call > > Hi, > > We chairs was considering inclusion in draft-ietf-webrtc-audio, but we didn't have any strong opinions on this. Based on that several WG participants thinks this should be an independent document, I thus decided that we will start out with an independent document. If the WG feels differently later we can always fold the text into the audio codec and processing requirements document. > > I would recommend that the individuals interested in contributing a codec writes an independent submission with focus on the codec considerations around the codec(s) they are interested in. Then we can merge this into a common WG document. > > Cheers > > Magnus > > > On 2013-01-27 10:14, Romascanu, Dan (Dan) wrote: >> Hi WG chairs, >> >> Clarification question: >> >>> In lieu of additional normative text, we believe the WG discussion >>> supports the inclusion of a new section on "Additional Relevant Codecs". >> >> Inclusion where? >> >> Thanks and Regards, >> >> Dan >> >> >> >> >>> -----Original Message----- >>> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On >>> Behalf Of Cullen Jennings (fluffy) >>> Sent: Thursday, January 24, 2013 6:47 PM >>> To: rtcweb@ietf.org >>> Subject: Re: [rtcweb] Conclusion statement for Recommended Audio >>> Codecs call >>> >>> >>> We have been running a call for consensus regarding Selecting >>> Recommended Audio Codecs. >>> >>> At this point the chairs are calling this as "no WG consensus". >>> >>> We can however note a strong interest in a non-normative listing of >>> potentially important codecs including a description why they should >>> be considered to be supported in WebRTC implementations. >>> >>> In lieu of additional normative text, we believe the WG discussion >>> supports the inclusion of a new section on "Additional Relevant Codecs". >>> That can contain a list of codecs which are relevant in specific >>> contexts, along with a short description of the context for each. >>> Specifically there seems to be interest in understanding the >>> advantages and costs of G.722, AMR, and AMR-WB. We hope that text >>> would broaden understanding of the WebRTC use case contexts. >>> >>> The WG chairs >>> Magnus, Ted and Cullen >>> >>> >>> _______________________________________________ >>> 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 >> >> > > -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From cb.list6@gmail.com Mon Jan 28 08:54:51 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F67021F87C3 for ; Mon, 28 Jan 2013 08:54:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.379 X-Spam-Level: X-Spam-Status: No, score=-3.379 tagged_above=-999 required=5 tests=[AWL=0.220, 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 vuYT7QF3Y8X1 for ; Mon, 28 Jan 2013 08:54:51 -0800 (PST) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by ietfa.amsl.com (Postfix) with ESMTP id A7DC221F87E0 for ; Mon, 28 Jan 2013 08:54:50 -0800 (PST) Received: by mail-lb0-f182.google.com with SMTP id gg6so4215807lbb.27 for ; Mon, 28 Jan 2013 08:54:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=yfzPAE0Ie5mmy+7QKfmJsNf5mrClmwW+byy+l/pGbHo=; b=af5mqcF9o1CxDAnelF3yx0tGy0SqScIf5XXRKr8+SDyfyAJdtUgzdWLWyhZIONGvKZ +9FxNjTh+gmysRhHNESxnEg5FnBxzx6IS9n4Yq4OKWmv5I1+NYkrQRLMh4eDlDHSK/M/ NdCxkFgQVOidSvljpb59S2UozHU8i3Sl9K8554RjBlrIqMGGWbP4TKyrGU9zSy6q/qYh c0aW32digxZspVMReYRgNLrFjiMFFa3UDPvLqerQejzEch4WsWOyUdovHwb5m2pyNyv3 3cnH/EgF52rI8O/NLWZmBRLy8qAQffwE+RbyRBsXodSVs2gEIpNqtCzyZZSmq1gajDZb TIiA== MIME-Version: 1.0 X-Received: by 10.152.144.130 with SMTP id sm2mr13797765lab.49.1359392089438; Mon, 28 Jan 2013 08:54:49 -0800 (PST) Received: by 10.112.7.165 with HTTP; Mon, 28 Jan 2013 08:54:49 -0800 (PST) In-Reply-To: References: <50FD4C4B.9020700@ericsson.com> <50FEB1EC.9060803@ericsson.com> <9904FB1B0159DA42B0B887B7FA8119CA076D1E@AZ-FFEXMB04.global.avaya.com> Date: Mon, 28 Jan 2013 08:54:49 -0800 Message-ID: From: Cameron Byrne To: Burger Eric Content-Type: text/plain; charset=ISO-8859-1 Cc: "Cullen Jennings \(fluffy\)" , rtcweb@ietf.org Subject: Re: [rtcweb] Conclusion statement for Recommended Audio Codecs call X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 28 Jan 2013 16:54:51 -0000 On Sun, Jan 27, 2013 at 11:38 AM, Burger Eric wrote: > A different document would be good. No need to to have an argument over non-normative text hold up publication. > +1 for a different informational document that can wax poetically about all the possible codecs that MAY be used.. And as always, you can use whatever codec your peers choose too use. CB From fluffy@cisco.com Tue Jan 29 07:14:24 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87B6121F885B for ; Tue, 29 Jan 2013 07:14:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.449 X-Spam-Level: X-Spam-Status: No, score=-110.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 iFOzBcFvPV5B for ; Tue, 29 Jan 2013 07:14:23 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id A190121F87EE for ; Tue, 29 Jan 2013 07:14:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=251; q=dns/txt; s=iport; t=1359472463; x=1360682063; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=1MMeK9PnA9fkxL69UgoIa0Vh/KdjZ9HQA038cHGJaj4=; b=AIl29VdH82Zx9oXyC+RShnRbKzve8nDtq8Jp9lciA7pgQBvc7ocHIfwt nuV1NlGk9tArc/q7jRr7RWcuNYVVVpKb0A4UFaC9D2l9hY69EbgKnqmlt gL47OdrX6c/dd4IFkCDijIL6xka/nyXVBby6YPMMZXxJh4k3BS6rdFKIr g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmUFAPfmB1GtJV2d/2dsb2JhbABEDoVxuF8Wc4IeAQEBAwEdXAULAgEIIiQyJQIEDgUIiAMGsQSQNI0OgxphA4gsniyCOT6BbzU X-IronPort-AV: E=Sophos;i="4.84,561,1355097600"; d="scan'208";a="169894417" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-4.cisco.com with ESMTP; 29 Jan 2013 15:14:23 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r0TFENav029708 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 29 Jan 2013 15:14:23 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.197]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0318.004; Tue, 29 Jan 2013 09:14:22 -0600 From: "Cullen Jennings (fluffy)" To: =?iso-8859-1?Q?Martin_J=2E_D=FCrst?= Thread-Topic: [rtcweb] Call for Consensus Regarding Selecting Recommended Audio Codecs Thread-Index: AQHN/jNRRXy9wi6NGU2Mbb+Yf5gnwQ== Date: Tue, 29 Jan 2013 15:14:03 +0000 Message-ID: References: <50D2CC6A.4090500@ericsson.com> <24103_1358435764_50F815B4_24103_9252_1_2842AD9A45C83B44B57635FD4831E60A076013@PEXCVZYM14.corporate.adroot.infra.ftgroup> <9F33F40F6F2CD847824537F3C4E37DDF013BD3C3@MCHP04MSX.global-ad.net> <50FA3DC7.9070708@it.aoyama.ac.jp> In-Reply-To: <50FA3DC7.9070708@it.aoyama.ac.jp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.164] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Call for Consensus Regarding Selecting Recommended 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, 29 Jan 2013 15:14:24 -0000 On Jan 18, 2013, at 11:31 PM, Martin J. D=FCrst wr= ote: > Please, please close this Call for Consensus, to avoid further email aval= anches on this topic.=20 It was closed and the conclusion was "no consensus".=20 From fluffy@cisco.com Tue Jan 29 08:49:48 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FD5A21F894D; Tue, 29 Jan 2013 08:49:48 -0800 (PST) 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 kR61fe1qOADe; Tue, 29 Jan 2013 08:49:47 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id C076C21F892F; Tue, 29 Jan 2013 08:49:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=869; q=dns/txt; s=iport; t=1359478187; x=1360687787; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=0ZP8xWjVbK3Afd3RGKzg8vLuzKpH3HefkdpjQhZpOY4=; b=A5j1cnZLr9ETEqG9Ck064UwD1Ft3OR6uWIoSy3hdyJcnhdbbaSXRaNtu On2B+Ckh3IVBFdrcikI3RY6xTDnpNabn8dNQVQVZD7i43HzwC42x/lLFG 7ya/TjyxMJff3eXbTKTkdbSe1QkF7PGfYDBXhtOMliLngCx84QuS4bLz5 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmUFADj8B1GtJXHB/2dsb2JhbABEhX+4XxZzgh8BAQQ6RAsCAQgiFBAhESUCBAESCAGHdgMPDLB+hlENiVWMFIQUYQOUN4Jyih2FEoJ3giQ X-IronPort-AV: E=Sophos;i="4.84,561,1355097600"; d="scan'208";a="166925213" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-9.cisco.com with ESMTP; 29 Jan 2013 16:49:47 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r0TGnlBq018140 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 29 Jan 2013 16:49:47 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.197]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0318.004; Tue, 29 Jan 2013 10:49:47 -0600 From: "Cullen Jennings (fluffy)" To: "mmusic@ietf.org WG" , "rtcweb@ietf.org" Thread-Topic: [MMUSIC] Start of a reading list for the IETF MMUSIC/RTCWEB interim Thread-Index: AQHN/kClnHEZs7eINEKHatjXJ9cqoQ== Date: Tue, 29 Jan 2013 16:49:27 +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.20.249.164] Content-Type: text/plain; charset="us-ascii" Content-ID: <13120A061F414D438181B47449205B03@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [rtcweb] [MMUSIC] Start of a reading list for the IETF MMUSIC/RTCWEB interim X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 29 Jan 2013 16:49:48 -0000 On Jan 25, 2013, at 9:47 AM, Ted Hardie wrote: > http://tools.ietf.org/html/draft-ietf-mmusic-sdp-bundle-negotiation > http://tools.ietf.org/html/draft-alvestrand-mmusic-msid > http://tools.ietf.org/html/draft-holmberg-mmusic-sdp-mmt-negotiation > http://tools.ietf.org/html/draft-ietf-mmusic-sctp-sdp > http://tools.ietf.org/html/draft-rescorla-mmusic-ice-trickle > http://tools.ietf.org/html/draft-ietf-rtcweb-jsep >=20 > You may also want to look at the proceedings from the Atlanta meeting; > in particular, this was suggested as good background reading: > http://www.ietf.org/proceedings/85/slides/slides-85-mmusic-7.ppt Some more background reading that is useful context=20 draft-ietf-rtcweb-rtp-usage-05 draft-ietf-rtcweb-overview-05 draft-ietf-rtcweb-use-cases-and-requirements-10 Thanks,=20 =20 From fluffy@cisco.com Tue Jan 29 08:51:08 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D2C421F890D; Tue, 29 Jan 2013 08:51:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.179 X-Spam-Level: X-Spam-Status: No, score=-105.179 tagged_above=-999 required=5 tests=[AWL=-5.420, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_BAD_ID=2.837, UNPARSEABLE_RELAY=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 2eB+G8oUaaR0; Tue, 29 Jan 2013 08:51:07 -0800 (PST) Received: from WIN-CDPOO5N337C (gw.ntelia.co.kr [175.196.232.146]) by ietfa.amsl.com (Postfix) with ESMTP id E2C0121F891D; Tue, 29 Jan 2013 08:51:06 -0800 (PST) Received: from mail pickup service by WIN-CDPOO5N337C with Microsoft SMTPSVC; Wed, 30 Jan 2013 01:50:14 +0900 Content-Transfer-Encoding: 7bit Content-ID: <13120A061F414D438181B47449205B03@cisco.com> Content-Language: en-US x-sender: fluffy@cisco.com x-receiver: hongkee67@gmail.com Received: from mail.ietf.org ([64.170.98.30]) by WIN-CDPOO5N337C with Microsoft SMTPSVC(7.5.7601.17514); Wed, 30 Jan 2013 01:50:05 +0900 Received: from ietfa.amsl.com (localhost [127.0.0.1])by ietfa.amsl.com (Postfix) with ESMTP id B98CD21F8992;Tue, 29 Jan 2013 08:49:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1359478191; bh=ryMvM+YOFIlYnaInVkXu8qu4ZvTvo2Sue9yXE2Sj7ZY=; h=From:To:Date:Message-ID:References:In-Reply-To:Content-ID: MIME-Version:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:Content-Type: Content-Transfer-Encoding:Sender; b=d7iV+hp+RmOi/8Es/JyUbq1gmh1LqJEKKKEUKsb408UEzwS8sK9xvrLNro+2X33T5 of/BYcS/UtOiUlmMEKfrS+SIlWIy4C3SMKC418b3BtNyofTvnm3mkjmR4HSRmu3qcD HXE70NFhho/4uu7AZCJgPbMkXH5VdTM5KD8/G7Xg= X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1])by ietfa.amsl.com (Postfix) with ESMTP id 4FD5A21F894D;Tue, 29 Jan 2013 08:49:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 kR61fe1qOADe; Tue, 29 Jan 2013 08:49:47 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80])by ietfa.amsl.com (Postfix) with ESMTP id C076C21F892F; Tue, 29 Jan 2013 08:49:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=869; q=dns/txt; s=iport;t=1359478187; x=1360687787; h=from:to:subject:date:message-id:references:in-reply-to:content-id:content-transfer-encoding:mime-version; bh=0ZP8xWjVbK3Afd3RGKzg8vLuzKpH3HefkdpjQhZpOY4=; b=A5j1cnZLr9ETEqG9Ck064UwD1Ft3OR6uWIoSy3hdyJcnhdbbaSXRaNtuOn2B+Ckh3IVBFdrcikI3RY6xTDnpNabn8dNQVQVZD7i43HzwC42x/lLFG7ya/TjyxMJff3eXbTKTkdbSe1QkF7PGfYDBXhtOMliLngCx84QuS4bLz5 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmUFADj8B1GtJXHB/2dsb2JhbABEhX+4XxZzgh8BAQQ6RAsCAQgiFBAhESUCBAESCAGHdgMPDLB+hlENiVWMFIQUYQOUN4Jyih2FEoJ3giQ X-IronPort-AV: E=Sophos;i="4.84,561,1355097600"; d="scan'208";a="166925213" Received: from rcdn-core2-6.cisco.com ([173.37.113.193])by rcdn-iport-9.cisco.com with ESMTP; 29 Jan 2013 16:49:47 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83])by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r0TGnlBq018140(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 29 Jan 2013 16:49:47 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.197]) byxhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0318.004; Tue, 29 Jan 2013 10:49:47 -0600 From: "Cullen Jennings (fluffy)" To: "mmusic@ietf.org WG" , "rtcweb@ietf.org" Thread-Topic: [MMUSIC] Start of a reading list for the IETF MMUSIC/RTCWEBinterim Thread-Index: AQHN/kClnHEZs7eINEKHatjXJ9cqoQ== Date: Tue, 29 Jan 2013 16:49:27 +0000 Message-ID: <1.a80a4afa979e98293e1b@cisco.com> References: In-Reply-To: Accept-Language: en-US x-originating-ip: [10.20.249.164] MIME-Version: 1.0 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-OriginalArrivalTime: 29 Jan 2013 16:50:05.0877 (UTC) FILETIME=[B0A7EE50:01CDFE40] Content-Type: multipart/alternative; boundary="----=_NextPart_000_BB71_2EF291BF.2798B26C" Subject: Re: [rtcweb] [MMUSIC] Start of a reading list for the IETF MMUSIC/RTCWEB interim X-BeenThere: rtcweb@ietf.org List-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, 29 Jan 2013 16:51:08 -0000 ------=_NextPart_000_BB71_2EF291BF.2798B26C Content-Language: en-US Content-ID: <13120A061F414D438181B47449205B03@cisco.com> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Jan 25, 2013, at 9:47 AM, Ted Hardie wrote: > http://tools.ietf.org/html/draft-ietf-mmusic-sdp-bundle-negotiation > http://tools.ietf.org/html/draft-alvestrand-mmusic-msid > http://tools.ietf.org/html/draft-holmberg-mmusic-sdp-mmt-negotiation > http://tools.ietf.org/html/draft-ietf-mmusic-sctp-sdp > http://tools.ietf.org/html/draft-rescorla-mmusic-ice-trickle > http://tools.ietf.org/html/draft-ietf-rtcweb-jsep > > You may also want to look at the proceedings from the Atlanta meeting; > in particular, this was suggested as good background reading: > http://www.ietf.org/proceedings/85/slides/slides-85-mmusic-7.ppt Some more background reading that is useful context draft-ietf-rtcweb-rtp-usage-05 draft-ietf-rtcweb-overview-05 draft-ietf-rtcweb-use-cases-and-requirements-10 Thanks, _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic ------=_NextPart_000_BB71_2EF291BF.2798B26C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
On Jan 25, 2013, at 9:47 AM, Ted Hardie <ted.ietf@gmail.com> wrote:

> http://tools.ietf.org/html/draft-ietf-mmusic-sdp-bundle-negotiation
> http://tools.ietf.org/html/draft-alvestrand-mmusic-msid
> http://tools.ietf.org/html/draft-holmberg-mmusic-sdp-mmt-negotiation
> http://tools.ietf.org/html/draft-ietf-mmusic-sctp-sdp
> http://tools.ietf.org/html/draft-rescorla-mmusic-ice-trickle
> http://tools.ietf.org/html/draft-ietf-rtcweb-jsep
>
> You may also want to look at the proceedings from the Atlanta meeting;
> in particular, this was suggested as good background reading:
> http://www.ietf.org/proceedings/85/slides/slides-85-mmusic-7.ppt


Some more background reading that is useful context

draft-ietf-rtcweb-rtp-usage-05
draft-ietf-rtcweb-overview-05
draft-ietf-rtcweb-use-cases-and-requirements-10

Thanks,
<Many chairs>



_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic
------=_NextPart_000_BB71_2EF291BF.2798B26C-- From fluffy@cisco.com Tue Jan 29 10:00:49 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E532921F8A22 for ; Tue, 29 Jan 2013 10:00:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.549 X-Spam-Level: X-Spam-Status: No, score=-110.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 LRpBWAwL4dxh for ; Tue, 29 Jan 2013 10:00:49 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id E5D1221F8A03 for ; Tue, 29 Jan 2013 10:00:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=456; q=dns/txt; s=iport; t=1359482449; x=1360692049; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=bPxKt+bno//X28kPRJu8QAkuzcyBeiVNyAJvVwxLzws=; b=Khk44QPPHOLa8RET4Xkz4qT3UFmRWUVnYvcoVb6sELNlSCcYI6cFvP7V RTk/fYp73sOEXb9BDFpCEksIxW8N+LwAcVFdIrr3W8jojSudSCYyzxxid XgFF1e9b8jZBNUC3XfQAP3C17tD4EP3mRuXNboieL7TTtrxdJby9UHj89 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmUFAPULCFGtJXG8/2dsb2JhbABEhX+4XxZzgh8BAQQdHT8QAgEIIhQFCzIlAgQOBQiICbEVkCyQKGEDpliCd4Ik X-IronPort-AV: E=Sophos;i="4.84,561,1355097600"; d="scan'208";a="170015252" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-4.cisco.com with ESMTP; 29 Jan 2013 18:00:48 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r0TI0mA3018366 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 29 Jan 2013 18:00:48 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.197]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.004; Tue, 29 Jan 2013 12:00:48 -0600 From: "Cullen Jennings (fluffy)" To: Jean-Marc Valin Thread-Topic: [rtcweb] Consensus vs. Voting (was Re: Call for Consensus Regarding Selecting Recommended Audio Codecs) Thread-Index: AQHN/kqRD8YvyoUl+k+L5pmTswZT0Q== Date: Tue, 29 Jan 2013 18:00:28 +0000 Message-ID: References: <50D2CC6A.4090500@ericsson.com> <6515_1357907583_50F0067F_6515_1738_1_2842AD9A45C83B44B57635FD4831E60A0747CC@PEXCVZYM14.corporate.adroot.infra.ftgroup> <580BEA5E3B99744AB1F5BFF5E9A3C67D16813E56EC@HE111648.emea1.cds.t-internal.com> <50F41D97.1030508@nostrum.com> <2327AE82-FC1E-4D09-B6B4-E87F01BD3527@phonefromhere.com> <00D8DD68-DB4D-450F-8787-8C32BD459937@phonefromhere.com> <50F43AD0.3030404@mozilla.com> In-Reply-To: <50F43AD0.3030404@mozilla.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.164] 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] Consensus vs. Voting (was Re: Call for Consensus Regarding Selecting Recommended 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, 29 Jan 2013 18:00:50 -0000 On Jan 14, 2013, at 10:05 AM, Jean-Marc Valin wrote: > "SHOULD include a PLC" only makes sense if you specify minimum quality > requirements. Otherwise "repeat previous packet" or "fill with zeros" > all count as PLC. Personally, I really don't feel like getting into a > PLC quality spec. Oh, the irony of we are fine with saying SHOULD do AEC (already in a WG dra= ft) but we are not fine with saying SHOULD do PLC.=20 From jmvalin@mozilla.com Tue Jan 29 10:42:27 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C6BE21F85EA for ; Tue, 29 Jan 2013 10:42:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, 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 PVrVXrmKBROZ for ; Tue, 29 Jan 2013 10:42:26 -0800 (PST) Received: from smtp.mozilla.org (mx2.corp.phx1.mozilla.com [63.245.216.70]) by ietfa.amsl.com (Postfix) with ESMTP id 6863E21F85D4 for ; Tue, 29 Jan 2013 10:42:26 -0800 (PST) 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 6A9FAF217C; Tue, 29 Jan 2013 10:42:25 -0800 (PST) Message-ID: <51081810.8040304@mozilla.com> Date: Tue, 29 Jan 2013 13:42:24 -0500 From: Jean-Marc Valin User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: "Cullen Jennings (fluffy)" References: <50D2CC6A.4090500@ericsson.com> <6515_1357907583_50F0067F_6515_1738_1_2842AD9A45C83B44B57635FD4831E60A0747CC@PEXCVZYM14.corporate.adroot.infra.ftgroup> <580BEA5E3B99744AB1F5BFF5E9A3C67D16813E56EC@HE111648.emea1.cds.t-internal.com> <50F41D97.1030508@nostrum.com> <2327AE82-FC1E-4D09-B6B4-E87F01BD3527@phonefromhere.com> <00D8DD68-DB4D-450F-8787-8C32BD459937@phonefromhere.com> <50F43AD0.3030404@mozilla.com> In-Reply-To: X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Consensus vs. Voting (was Re: Call for Consensus Regarding Selecting Recommended 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, 29 Jan 2013 18:42:27 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/29/2013 01:00 PM, Cullen Jennings (fluffy) wrote: >> "SHOULD include a PLC" only makes sense if you specify minimum >> quality requirements. Otherwise "repeat previous packet" or >> "fill with zeros" all count as PLC. Personally, I really don't >> feel like getting into a PLC quality spec. > > Oh, the irony of we are fine with saying SHOULD do AEC (already in > a WG draft) but we are not fine with saying SHOULD do PLC. I mean I'm fine with "SHOULD do PLC", but unless you specify the minimum performance, it becomes meaningless. As for AEC, it's not clearly stated in the current version draft, but as far as I'm concerned, the minimum performance is "keep return gain below unity". Of course, it's still nice to be better than that... Jean-Marc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRCBgQAAoJEJ6/8sItn9q9aZcH/2yPn9BQvKs3pCDLFDbNuNee 0uVtN20HyotUsAZ+3f+MSDZIuT6YIOkTeb0u71eWGgqSRN7612hJ8+aKxLyZoXEX f0iR4bDGssZVIxtrYXlNS9NGPPZs8Xmo2TfX6meYRdJqniuE/wJaomGnkOI6Llv4 OwssdEAtocarZi2WmV0hE0UhGAnlbviQTLKifk1Lv8RPTE7M21BphIXVwVWY8wQu im8/5l5xMqkKBwgHauy/rCQrMO2Iwux9sFOky/XEmqR170/+GSrlh17bjluoJwo0 Slsgr2l32p7brm9J2YGhkhVOyOBAB6Iht7JlNfAruW4E+nEcrPytu/r0PqhTo1Q= =0CRZ -----END PGP SIGNATURE----- From fluffy@cisco.com Tue Jan 29 10:51:24 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94F2321F894D for ; Tue, 29 Jan 2013 10:51:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.106 X-Spam-Level: X-Spam-Status: No, score=-110.106 tagged_above=-999 required=5 tests=[AWL=0.493, 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 nWiLx6WkUq0h for ; Tue, 29 Jan 2013 10:51:24 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id D9E4B21F8846 for ; Tue, 29 Jan 2013 10:51:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1196; q=dns/txt; s=iport; t=1359485484; x=1360695084; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=JaEvP3rXRmfC8JQSW2BBQ7wMHDBuWvrdDg9PkhSEhoc=; b=fbuaRXA5F5NB010QcDFmD1OoYyczTBdXxMtq6UNPIaKPPuoRosIDvO9n 4hRRO4fR8kw+v380R1b9zUShVIRlikhMGcWmVmgY6fNpVAOMJNuyC5fQm BoX/6MD/ozMB7YuVxngtMdyctLsEOxHHUxE82gz0F6+ivIsU8Mc4QF8YW Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EANAZCFGtJV2b/2dsb2JhbABEvl8Wc4IeAQEBAwEBAQEJYhAJAgIBCCIdBxsMCxQRAgQTCIgDBgyxGZAyBASQJGEDiCyeLIJ3giQ X-IronPort-AV: E=Sophos;i="4.84,561,1355097600"; d="scan'208";a="170041808" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-3.cisco.com with ESMTP; 29 Jan 2013 18:51:20 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r0TIpKbW004722 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 29 Jan 2013 18:51:20 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.197]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0318.004; Tue, 29 Jan 2013 12:51:20 -0600 From: "Cullen Jennings (fluffy)" To: "rtcweb@ietf.org" Thread-Topic: [rtcweb] WG Last Call: draft-ietf-rtcweb-use-cases-and-requirements-10 Thread-Index: AQHN/lGgu2lkJAPp+ESDMUA0gXUKhQ== Date: Tue, 29 Jan 2013 18:51:00 +0000 Message-ID: References: <50F97303.4070906@ericsson.com> In-Reply-To: <50F97303.4070906@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.164] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <4B26EFDB65AE494E9B2A9B04668C83AF@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [rtcweb] WG Last Call: draft-ietf-rtcweb-use-cases-and-requirements-10 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 29 Jan 2013 18:51:24 -0000 The combination of getting ready for the interim meeting and being sick, I = am sorry but won't be able to get this done by deadline but I will still ge= t a review done at later.=20 Sorry, Cullen=20 On Jan 18, 2013, at 9:06 AM, Magnus Westerlund wrote: > WG, >=20 > I would here by like to announce a two week WG last call that ends on > the 1st of February. >=20 > Document is available here: >=20 > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-use-cases-and-requirem= ents/ >=20 > Cheers >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From fluffy@cisco.com Tue Jan 29 10:51:27 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EDE421F8A8B for ; Tue, 29 Jan 2013 10:51:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.147 X-Spam-Level: X-Spam-Status: No, score=-110.147 tagged_above=-999 required=5 tests=[AWL=0.452, 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 sbU9REFI8KAV for ; Tue, 29 Jan 2013 10:51:27 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id F31C821F8A54 for ; Tue, 29 Jan 2013 10:51:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1394; q=dns/txt; s=iport; t=1359485487; x=1360695087; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=xljrSZURusTpKJA5bb9mPcEu9ZinczZbplMDj56Q8i0=; b=C8KoXI8XSEPtXAzL0s1mD8jAt5y1q859GH7TmiQqJsBlLyC2nJpwnNik RCjy02L+WH7rlTOworJSxVvLRmiVaICaAEqQD7J1n2BYb2Tu27bERi6MD EuJXOaIs4uZA/q/TwnnkdiDMr2o5glQJeoZ8KhrjKzhg5cJe+PZJ0rWmz 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EANAZCFGtJXG//2dsb2JhbABEvl8Wc4IeAQEBAwEBAQEJYhAJAgIBCCIdBxsMCxQRAgQTCIgDBgyxGZAyBASQJGEDiCyeLIJ3giQ X-IronPort-AV: E=Sophos;i="4.84,561,1355097600"; d="scan'208";a="170051045" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-4.cisco.com with ESMTP; 29 Jan 2013 18:51:26 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r0TIpQU8020808 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 29 Jan 2013 18:51:26 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.197]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.004; Tue, 29 Jan 2013 12:51:26 -0600 From: "Cullen Jennings (fluffy)" To: "rtcweb@ietf.org" Thread-Topic: [rtcweb] WG Last Call: draft-ietf-rtcweb-overview-05 Thread-Index: AQHN/lGjbzSX4OeWckuvaIsOzbiASg== Date: Tue, 29 Jan 2013 18:51:06 +0000 Message-ID: References: <50F9728E.6000206@ericsson.com> In-Reply-To: <50F9728E.6000206@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.164] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <5FA03C020BCFF946845C477AA2150C30@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [rtcweb] WG Last Call: draft-ietf-rtcweb-overview-05 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 29 Jan 2013 18:51:27 -0000 The combination of getting ready for the interim meeting and being sick, I = am sorry but won't be able to get this done by deadline but I will still ge= t a review done at later.=20 Sorry, Cullen=20 On Jan 18, 2013, at 9:04 AM, Magnus Westerlund wrote: > WG, >=20 > I would here by like to announce a two week WG last call that ends on > the 1st of February. Please review this, we chairs do acknowledge that > some references will be required to be updated before submitting for > publication, but we do need determine if this is ready for publication > and can consider it done. >=20 > Document is available here: > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-overview/ >=20 > Cheers >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From martin.thomson@gmail.com Tue Jan 29 13:46:48 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8806C21F87C4 for ; Tue, 29 Jan 2013 13:46:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_19=0.6, NO_RELAYS=-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 RawgHLyn-MLd for ; Tue, 29 Jan 2013 13:46:47 -0800 (PST) Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 48D6521F86D4 for ; Tue, 29 Jan 2013 13:46:46 -0800 (PST) Received: by mail-we0-f182.google.com with SMTP id t57so693305wey.41 for ; Tue, 29 Jan 2013 13:46:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=bMMIygKIBeUehoFDpLNcksOx0QSF2pSbC++Auq71Fno=; b=ArViM3ykJ8Owz3RQM1hpt3bmgKr4hgkx+RfkxhpPKYyuMweiPQDz9a+nP0ZyIZ9N5n vNgR7FlAsjmkj9zsXFaiUkvdEKhDgbhGaThxK6rX2FxMeyGSn+cG4oHfkv7DvLzqTc2H HvyrjcLzlNqoMkocs+6kKprtyVcU70Bw0zS6Lw6A1klEI5c3XdjhHI6d89szPOOH9Hbi LbN5H+osN9qHPvjrVZ/K3ab/w8XDctSKJh5swnFH1/1iy2QSAIIQXrKDbn1tVOSoL5hr c6borBJSCF0ybs7c2j2jCs0eXUl5syAt3PWnsYrwBJ3EsCxx21rpGw9pVYyuQzOmn49j zNAA== MIME-Version: 1.0 X-Received: by 10.194.123.105 with SMTP id lz9mr5026680wjb.43.1359496006284; Tue, 29 Jan 2013 13:46:46 -0800 (PST) Received: by 10.194.161.230 with HTTP; Tue, 29 Jan 2013 13:46:46 -0800 (PST) In-Reply-To: <50F97303.4070906@ericsson.com> References: <50F97303.4070906@ericsson.com> Date: Wed, 30 Jan 2013 06:46:46 +0900 Message-ID: From: Martin Thomson To: Magnus Westerlund Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] WG Last Call: draft-ietf-rtcweb-use-cases-and-requirements-10 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 29 Jan 2013 21:46:48 -0000 I have read this document in the past, but never really reviewed it. It's something of a mess. Sure, it could use a fairly thorough going over from an editorial perspective, but that's not what bothers me. There is just a lot of stuff in here that we haven't resolved. Some of this stuff we haven't even discussed, not to mention have concrete proposals on the table for. There are a number of open questions in relation to this document. I wont repeat those that are actually in the text, which clearly need to be addressed. I'm more concerned about those features/requirements that the working group(s) has/have not shown any signs of providing answers for. Here I speak primarily of the items that are on the agenda at the upcoming interim meeting. Stream rejection, for example. I would suggest that these documents be held in abeyance until we know the outcome of the interim. Specifically, whether we are going to provide technical solutions to the problems under discussion. (Yes, I know that it is not uncommon for use case documents to be published with requirements that are impossible, but it's only 2 weeks.) Specific comments: The requirements are all over the place. They almost look like they have been shuffled. For instance, F33 and F23 are almost identical, but use different wording. Same for F19 and F29. F24 and F34. Oh, I get it, you are grouping based on the last digit! Not the most obvious choice for ordering, or the easiest to review. F13 The browser MUST be able to apply spatialization effects to audio streams. So...this is either pointless in the same vein as the requirement "the browser MUST be able to control the volume of audio" or it is not addressed. I see A13, but that's not happening. Given where we've directed effort, I am tempted to suggest that this be removed. F14 The browser MUST be able to measure the level in audio streams. (also A14) As written, this is pointless. If the audio can be played, the level can be measured. Unless the intent is that the browser provide this information to the application. In which case, we have the security implications to consider, when streams are marked as "tainted", this should not be possible. F15 The browser MUST be able to change the level in audio streams. This is a problem for the same reason as above. AGC is one thing, but this is unspecific. Does this apply to inbound and outbound streams? Is this level control provided to the application or is this a pointless requirement on browser chrome? This also has implications for "tainted" streams, in which case I believe that even level control should be prevented. F7 The browser MUST support fast stream switches. What does this mean? There are a number of factors that could be at play h= ere: 1. There are two live streams (inbound or locally sourced) and the browser must be able to switch from playback of one to the other quickly. This should be trivial to implement. Even then, we need to be careful that switching can't be to fast for tainted streams. 2. There are two live streams sourced locally and the browser must be able to switch from transmission of one to the other quickly. This does have some limitations if the two streams have different properties such that this requires signaling. 3. There are two streams where the stream that is being switched in is remotely sourced and currently inactive. The browser needs to activate and begin playback of that stream quickly. This is what is implied by the use case in Section 4.3.3. F19 Streams and data MUST be able to pass through restrictive firewalls. Suggest rewording, perhaps to use of the term "limited middleboxes" rather than "restrictive firewalls". Otherwise, this could be interpreted as a *requirement* to circumvent local network policy. F29 seems like a better model, though I note that it is a duplicate of this. F37 The browser MUST be able to send streams and data to a peer in the presence of FWs that only allows http(s) traffic. This is a more specific version of F19, for which my same comment applies. I haven't seen any attempt to provide a solution. Can this be removed? F22 There should be a way to navigate a DTMF based IVR Expand on first use: IVR and DTMF. F26 It MUST be possible to move from one network interface to another one For whom must this be possible? Certainly, the browser is able to make this choice, but the application has only limited ability to control this in the current application. I can imagine perhaps changing priority values on a=3Dcandidate lines based on some guessing about what interfaces are what, but I have a strong expectation that this would have zero effect in any ICE implementation. F28 The browser MUST support a baseline audio and video codec No comment. F32 There browser MUST support that STUN and TURN servers to use are supplied by other entities than the service provided (i.e. the network provider). I'm not sure what the "service provided" is in this case. There is an application and the browser. The discovery of local STUN/TURN servers is surely a browser issue outside of the scope of these requirements. A note in a solution document that makes the observation that browser-provided STUN/TURN servers be used in addition to any provided by the application would be more appropriate. A17 For each stream generated, the Web API MUST provide an identifier that is accessible by the application. The identifier MUST be accessible also for a peer receiving that stream and MUST be unique relative to all other stream identifiers in use by either party. This seems overly specific. I presume that the intent was to ensure that streams that originate on a sending browser be identifiable on a receiving browser. This actually specifies a solution to that problem rather than the requirement. Suggest: The Web API MUST provide a way to identify streams such that an application is able to match streams on a sending peer with the same stream on all receiving peers. Identifier uniqueness requirements derive from that requirement, plus any additional constraints that you choose to apply (read: SDP). A25 It must be possible for the application to refrain from exposing the IP address Missing something. "the" IP address. Which one specifically? Oh, you must (MUST) be able to refrain from revealing that information. Editorial: A19 is missing: "to", " ". A20 not only anthropomorphizes the browser, it assigns a gender; how can be sure it's not a "she"? Fix the IANA Considerations section, it's not hard. On 19 January 2013 01:06, Magnus Westerlund wrote: > WG, > > I would here by like to announce a two week WG last call that ends on > the 1st of February. > > Document is available here: > > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-use-cases-and-requirem= ents/ > > Cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=C3=A4r=C3=B6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From bernard_aboba@hotmail.com Tue Jan 29 14:36:05 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0627921F851E for ; Tue, 29 Jan 2013 14:36:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.364 X-Spam-Level: X-Spam-Status: No, score=-102.364 tagged_above=-999 required=5 tests=[AWL=0.234, 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 M2Hu+a3B5JcQ for ; Tue, 29 Jan 2013 14:36:04 -0800 (PST) Received: from blu0-omc3-s12.blu0.hotmail.com (blu0-omc3-s12.blu0.hotmail.com [65.55.116.87]) by ietfa.amsl.com (Postfix) with ESMTP id 3F09421F8521 for ; Tue, 29 Jan 2013 14:36:04 -0800 (PST) Received: from BLU002-W17 ([65.55.116.72]) by blu0-omc3-s12.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 29 Jan 2013 14:36:03 -0800 X-EIP: [WF3KjNECNj3q1VuIoDnCw4HByLwPanyS] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_35fab46c-7e0c-4c39-92d4-d591a028d3b5_" From: Bernard Aboba To: Magnus Westerlund Date: Tue, 29 Jan 2013 14:36:03 -0800 Importance: Normal In-Reply-To: References: <50F97303.4070906@ericsson.com>, MIME-Version: 1.0 X-OriginalArrivalTime: 29 Jan 2013 22:36:03.0935 (UTC) FILETIME=[056C36F0:01CDFE71] Cc: "rtcweb@ietf.org" Subject: [rtcweb] Review of draft-ietf-rtcweb-use-cases-and-requirements-10 (Part I) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 29 Jan 2013 22:36:05 -0000 --_35fab46c-7e0c-4c39-92d4-d591a028d3b5_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I have a very fundamental question about this document: What are the Browser and API requirements going to be used for?=20 Is the goal to document things we thought might have been nice at the time? In many cases=2C the requirements are too vague to easily determine whether= subsequent IETF protocol profiles or W3C API documents actually satisfy the requirements. = But even if they were made more specific=2C is there really any intent to evaluate IETF and W3C w= ork based on these requirements? Section 2 states that normative keywords are to be interpretted as describe= d in RFC 2119. Since this isn't a protocol specification=2C does that really make sense? As an example=2C requirement F3 states: "Transmitted streams and data MUST be rate controlled." While the statement above might make some sense in the context of the "circ= uit breakers" document=2C or perhaps one of the congestion control documents=2C I don't understand what = the MUST means in the context of this document.=20 Does it mean that the specifications are required to define a rate control = feature?=20 Assuming such a feature is defined=2C does it mean that browsers are requir= ed to implement the feature?=20 If implementation is required=2C is it required that the feature be used?=20 Personally=2C my guess is that the meaning probably does not correspond to = any of the above=2C because this=20 is only a use case document=2C not a protocol or API specification. But if that is true=2C why point to the RFC 2119 definition of normative te= rms?=20 In the past=2C a number of requirements documents have tackled this problem= by explicitly stating that how normative language is to be interpretted=2C rather than bl= indly inserting a=20 reference to RFC 2119. For example=2C RFC 2989 states: Please note that the requirements specified in this document are to be used in evaluating... protocol submissions. As such=2C the requirements language refers to capabilities of these protocols=3B the protocol documents will specify whether these features are required=2C recommended=2C or optional. For example=2C requiring that a protocol support confidentiality is NOT the same thing as requiring that all protocol traffic be encrypted. = --_35fab46c-7e0c-4c39-92d4-d591a028d3b5_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I have a very fundamental questi= on about this document:

What are the Browser and API requirements go= ing to be used for?

Is the goal to document things we thought might= have been nice at the time?

In many cases=2C the requirements are t= oo vague to easily determine whether subsequent IETF
protocol profiles o= r W3C API documents actually satisfy the requirements. =3B But even if = they were
made more specific=2C is there really any intent to evaluate I= ETF and W3C work based on these requirements?

Section 2 states that = normative keywords are to be interpretted as described in RFC 2119.
Sinc= e this isn't a protocol specification=2C does that really make sense?
As an example=2C requirement F3 states:

"Transmitted streams and d= ata MUST be rate controlled."

While the statement above might make s= ome sense in the context of the "circuit breakers" document=2C or
perhap= s one of the congestion control documents=2C I don't understand what the MU= ST means in the context of
this document.

Does it mean that the = specifications are required to define a rate control feature?
Assuming = such a feature is defined=2C does it mean that browsers are required to imp= lement the feature?
If implementation is required=2C is it required tha= t the feature be used?

Personally=2C my guess is that the meaning p= robably does not correspond to any of the above=2C because this
is only= a use case document=2C not a protocol or API specification.

But if = that is true=2C why point to the RFC 2119 definition of normative terms?
In the past=2C a number of requirements documents have tackled this p= roblem by explicitly
stating that how normative language is to be interp= retted=2C rather than blindly inserting a
reference to RFC 2119. = =3B For example=2C RFC 2989 states:

 =3B =3B Please note tha= t the requirements specified in this document are to
 =3B =3B be= used in evaluating... protocol submissions. =3B As such=2C the
&nbs= p=3B =3B requirements language refers to capabilities of these protocol= s=3B the
 =3B =3B protocol documents will specify whether these = features are required=2C
 =3B =3B recommended=2C or optional.&nb= sp=3B For example=2C requiring that a protocol
 =3B =3B support = confidentiality is NOT the same thing as requiring that all
 =3B&nbs= p=3B protocol traffic be encrypted.


= --_35fab46c-7e0c-4c39-92d4-d591a028d3b5_-- From bernard_aboba@hotmail.com Tue Jan 29 15:04:14 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3DDA21F87D1 for ; Tue, 29 Jan 2013 15:04:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.382 X-Spam-Level: X-Spam-Status: No, score=-102.382 tagged_above=-999 required=5 tests=[AWL=0.216, 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 yWKq+KZXR6Ft for ; Tue, 29 Jan 2013 15:04:13 -0800 (PST) Received: from blu0-omc3-s16.blu0.hotmail.com (blu0-omc3-s16.blu0.hotmail.com [65.55.116.91]) by ietfa.amsl.com (Postfix) with ESMTP id 5DCC821F87BB for ; Tue, 29 Jan 2013 15:04:13 -0800 (PST) Received: from BLU002-W210 ([65.55.116.73]) by blu0-omc3-s16.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 29 Jan 2013 15:04:13 -0800 X-EIP: [5iLuBbYouwtilgjW/IVPThyVx5QH2IKG] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_abba502f-0f8e-4892-8e0f-205fdc54e894_" From: Bernard Aboba To: Magnus Westerlund Date: Tue, 29 Jan 2013 15:04:12 -0800 Importance: Normal In-Reply-To: References: <50F97303.4070906@ericsson.com>, , , MIME-Version: 1.0 X-OriginalArrivalTime: 29 Jan 2013 23:04:13.0035 (UTC) FILETIME=[F4346BB0:01CDFE74] Cc: "rtcweb@ietf.org" Subject: [rtcweb] Review of draft-ietf-rtcweb-use-cases-and-requirements-10 (Part II) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 29 Jan 2013 23:04:14 -0000 --_abba502f-0f8e-4892-8e0f-205fdc54e894_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Putting aside the meaning of the normative language in the document=2C and= the purpose of the document=2C here are some thoughts on the requirements = contained therein: REQ-ID DESCRIPTION=0A= ---------------------------------------------------------------=0A= F1 The browser MUST be able to use microphones and=0A= cameras as input devices to generate streams. [BA] Can I assume that the use of the plural implies a requirement to be ab= le to support multiple sources? ----------------------------------------------------------------=0A= F2 The browser MUST be able to send streams and=0A= data to a peer in the presence of NATs. [BA] Is this really only about sending streams=2C but not receiving?? ----------------------------------------------------------------=0A= F3 Transmitted streams and data MUST be rate=0A= controlled. [BA] I think we need to be more specific. Are we talking about support for= "congestion control"=2C and if so=2C are we saying this should be mandatory to implement or use? Or is this about "consent"? = Or maybe preventing congestive collapse in some circumstances=20 (e.g. circuit breakers)?=20 ----------------------------------------------------------------=0A= F4 The browser MUST be able to receive=2C process and=0A= render streams and data ("render" does not=0A= apply for data) from peers.=0A= ----------------------------------------------------------------=0A= F5 The browser MUST be able to render good quality=0A= audio and video even in the presence of=0A= reasonable levels of jitter and packet losses.=0A= =0A= TBD: What is a reasonable level? [BA] I am not sure what this means. Is it implying the need for a strategy= to deal with loss in the MTI codec? For example=2C is this implying a requirement for codec adaption=2C or FEC or re-transmission? I don't see the purpose of letting the TBD rema= in here.=20 ----------------------------------------------------------------=0A= F6 The browser MUST be able to handle high loss and=0A= jitter levels in a graceful way. [BA] What does "graceful" mean?? Is this referring to the resilience of the= codec and loss-strategy (see above)=2C or to enabling the application to adapt to los= s? =20 ----------------------------------------------------------------=0A= F7 The browser MUST support fast stream switches. [BA] I really am not sure what is meant here. Are we talking about the abi= lity of a sender to change=20 transmission rate quickly (e.g. removing a layer in SVC)? Or about adding/= removing a stream?=20 =0A= ----------------------------------------------------------------=0A= F9 When there are both incoming and outgoing audio=0A= streams=2C echo cancellation MUST be made=0A= available to avoid disturbing echo during=0A= conversation.=0A= =0A= QUESTION: How much control should be left to the=0A= web application? [BA] Hadriel's API requirements document talks about the ability to control= echo cancellation=2C which=20 makes more sense to me than the above. Remove the question.=20 ----------------------------------------------------------------=0A= F10 The browser MUST support synchronization of=0A= audio and video.=0A= =0A= =0A= QUESTION: How much control should be left to the=0A= web application? [BA] Synchronization is not necessarily possible or even desirable in all c= ircumstances. For example=2C if the video experiences substantial loss=2C do you really w= ant to delay the audio to sync with it? So I can understand why it is desirable to support the capability= =2C but is this=20 really a MUST? I would not bother to attempt to answer the question=3B del= ete it.=20 =0A= ----------------------------------------------------------------=0A= F13 The browser MUST be able to apply spatialization=0A= effects to audio streams. [BA] What does this mean in practical terms? ----------------------------------------------------------------=0A= F14 The browser MUST be able to measure the level=0A= in audio streams. [BA] See Martin's comments.=20 ----------------------------------------------------------------=0A= F15 The browser MUST be able to change the level=0A= in audio streams. [BA] See Martin's comments. =0A= =0A= ----------------------------------------------------------------=0A= F18 The browser MUST be able to process and mix=0A= sound objects (media that is retrieved from=0A= another source than the established media=0A= stream(s) with the peer(s) with audio streams. [BA] If this is done=2C isn't it important to make clear to the user (and p= erhaps the peer) what is happening?=20 Confusing live and recorded media seems like a potential vector for mischie= f.=20 ----------------------------------------------------------------=0A= F19 Streams and data MUST be able to pass through=0A= restrictive firewalls. [BA] Do we need this requirement=2C given that we also have requirements F2= 9 and F37? ----------------------------------------------------------------=0A= F20 It MUST be possible to protect streams and data=0A= from wiretapping. [BA] "Wiretapping" is too vague a phrase to be of much use. It might make = more sense to talk about security services that should be provided (e.g. confidentiality = of media).=20 ----------------------------------------------------------------=0A= F21 The browser MUST support an audio media format=0A= (codec) that is commonly supported by existing=0A= telephony services.=0A= =0A= QUESTION: G.711? [BA] The Question: line should probably be removed. =20 =0A= ----------------------------------------------------------------=0A= F26 It MUST be possible to move from one network=0A= interface to another one [BA] Are we talking about the ability of an application to control this=2C = or the ability of an application to react to it=2C or something else? =0A= ----------------------------------------------------------------=0A= F29 The browser MUST be able to send streams and=0A= data to a peer in the presence of NATs that=0A= block UDP traffic. [BA] Is this just about sending and not receiving? =0A= ----------------------------------------------------------------=0A= F35 The browser MUST enable verification=2C given=0A= the right circumstances and by use of other=0A= trusted communication=2C of that streams and=0A= data received have not been manipulated by=0A= any party. [BA] I do not see how such a verification is possible.=20 ----------------------------------------------------------------=0A= F36 The browser MUST reject incoming media and=0A= data=2C either modified=2C created or injected=2C=0A= by any entity not trusted by the site. [BA] Do we really mean "trusted by the site" or "trusted by the browser"?=20 ----------------------------------------------------------------=0A= F37 The browser MUST be able to send streams and=0A= data to a peer in the presence of FWs that only=0A= allows http(s) traffic.=0A= ----------------------------------------------------------------=0A= F38 The browser MUST be able to collect statistics=2C=0A= related to the transport of audio and video=0A= between peers=2C needed to estimate quality of=0A= service. [BA] Do we mean "Quality of Service" or "Quality of Experience?" ----------------------------------------------------------------=0A= = --_abba502f-0f8e-4892-8e0f-205fdc54e894_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Putting aside the meaning of the=  =3B normative language in the document=2C and the purpose of the docum= ent=2C here are some thoughts on the requirements contained therein:
 REQ-ID          DESCRIPTION=0A=
   ---------------------------------------------------------------=0A=
   F1              The browser MUST be able to use microphones and=0A=
                   cameras as input devices to generate streams.

[BA=
] Can I assume that the use of the plural implies a requirement to be able =
to support multiple sources?
 =3B-----------------------------------=
-----------------------------=0A=
   F2              The browser MUST be able to send streams and=0A=
                   data to a peer in the presence  of NATs.

[BA] Is =
this really only about sending streams=2C but not receiving??

 =
=3B----------------------------------------------------------------=0A=
   F3              Transmitted streams and data MUST be rate=0A=
                   controlled.

[BA] I think we need to be more speci=
fic.  Are we talking about support for "congestion control"=2C and if so=2C=
 are we saying
this should be mandatory to implement or use?  Or is this=
 about "consent"?  Or maybe preventing congestive collapse in some circumst=
ances 
(e.g. circuit breakers)? 
 =3B----------------------------=
------------------------------------=0A=
   F4              The browser MUST be able to receive=2C process and=0A=
                   render streams and data ("render" does not=0A=
                   apply for data) from peers.=0A=
   ----------------------------------------------------------------=0A=
   F5              The browser MUST be able to render good quality=0A=
                   audio and video even in the presence of=0A=
                   reasonable levels of jitter and packet losses.=0A=
=0A=
                   TBD: What is a reasonable level?

[BA] I am not su=
re what this means.  Is it implying the need for a strategy to deal with lo=
ss in the MTI codec?
For example=2C is this implying a requirement for c=
odec adaption=2C
or FEC or re-transmission?  I don't see the purpose of =
letting the TBD remain here. 
 -----------------------------------------=
-----------------------=0A=
   F6              The browser MUST be able to handle high loss and=0A=
                   jitter levels in a graceful way.

[BA] What does "=
graceful" mean?? Is this referring to the resilience of the codec and
lo=
ss-strategy (see above)=2C or to enabling the application to adapt to loss?=
  

 =3B---------------------------------------------------------=
-------=0A=
   F7              The browser MUST support fast stream switches.

[B=
A] I really am not sure what is meant here.  Are we talking about the abili=
ty of a sender to change 
transmission rate quickly (e.g. removing a lay=
er in SVC)?  Or about adding/removing a stream? 
=0A=
   ----------------------------------------------------------------=0A=
   F9              When there are both incoming and outgoing audio=0A=
                   streams=2C echo cancellation MUST be made=0A=
                   available to avoid disturbing echo during=0A=
                   conversation.=0A=
=0A=
                   QUESTION: How much control should be left to the=0A=
                   web application?

[BA] Hadriel's API requirements =
document talks about the ability to control echo cancellation=2C which 
=
makes more sense to me than the above.  Remove the question. 

 =
=3B----------------------------------------------------------------=0A=
   F10             The browser MUST support synchronization of=0A=
                   audio and video.=0A=
=0A=
=0A=
                   QUESTION: How much control should be left to the=0A=
                   web application?

[BA] Synchronization is not nece=
ssarily possible or even desirable in all circumstances.
For example=2C =
if the video experiences substantial loss=2C do you really want to delay th=
e audio to sync
with it? So I can understand why it is desirable to supp=
ort the capability=2C but is this 
really a MUST?  I would not bother to=
 attempt to answer the question=3B delete it. 
=0A=
   ----------------------------------------------------------------=0A=
   F13             The browser MUST be able to apply spatialization=0A=
                   effects to audio streams.

[BA] What does this mea=
n in practical terms?
 =3B------------------------------------------=
----------------------=0A=
   F14             The browser MUST be able to measure the level=0A=
                   in audio streams.

[BA] See Martin's comments.  =3B----------------------------------------------------------------=
=0A=
   F15             The browser MUST be able to change the level=0A=
                   in audio streams.
[BA] See Martin's comments. =0A=
=0A=
   ----------------------------------------------------------------=0A=
   F18             The browser MUST be able to process and mix=0A=
                   sound objects (media that is retrieved from=0A=
                   another source than the established media=0A=
                   stream(s) with the peer(s) with audio streams.

[B=
A] If this is done=2C isn't it important to make clear to the user (and per=
haps the peer) what is happening? 
Confusing live and recorded media see=
ms like a potential vector for mischief. 

 =3B------------------=
----------------------------------------------=0A=
   F19             Streams and data MUST be able to pass through=0A=
                   restrictive firewalls.

[BA] Do we need this requi=
rement=2C given that we also have requirements F29 and F37?

   =
=3B----------------------------------------------------------------=0A=
   F20             It MUST be possible to protect streams and data=0A=
                   from wiretapping.

[BA] "Wiretapping" is too vague=
 a phrase to be of much use.  It might make more sense to
talk about sec=
urity services that should be provided (e.g. confidentiality of media). 
 =3B--------------------------------------------------------------=
--=0A=
   F21             The browser MUST support an audio media format=0A=
                   (codec) that is commonly supported by existing=0A=
                   telephony services.=0A=
=0A=
                   QUESTION: G.711?

[BA] The Question: line should p=
robably be removed.  
=0A=
   ----------------------------------------------------------------=0A=
   F26             It MUST be possible to move from one network=0A=
                   interface to another one
[BA] Are we talking about th=
e ability of an application to control this=2C or the ability of an applica=
tion to react to it=2C or something else?

=0A=
   ----------------------------------------------------------------=0A=
   F29             The browser MUST be able to send streams and=0A=
                   data to a peer in the presence of NATs that=0A=
                   block UDP traffic.

[BA] Is this just about sendin=
g and not receiving?
=0A=
   ----------------------------------------------------------------=0A=
   F35             The browser MUST enable verification=2C given=0A=
                   the right circumstances and by use of other=0A=
                   trusted communication=2C of that  streams and=0A=
                   data received have not been manipulated by=0A=
                   any party.
[BA] I do not see how such a verification =
is possible. 

 =3B----------------------------------------------=
------------------=0A=
   F36             The browser MUST reject incoming media and=0A=
                   data=2C either modified=2C created or injected=2C=0A=
                   by any entity not trusted by the site.

[BA] Do we=
 really mean "trusted by the site" or "trusted by the browser"? 

&nb=
sp=3B----------------------------------------------------------------=0A=
   F37             The browser MUST be able to send streams and=0A=
                   data to a peer in the presence of FWs that only=0A=
                   allows http(s) traffic.=0A=
   ----------------------------------------------------------------=0A=
   F38             The browser MUST be able to collect statistics=2C=0A=
                   related to the transport of audio and video=0A=
                   between peers=2C needed to estimate quality of=0A=
                   service.

[BA] Do we mean "Quality of Service" or =
"Quality of Experience?"

 =3B-----------------------------------=
-----------------------------=0A=

= --_abba502f-0f8e-4892-8e0f-205fdc54e894_-- From magnus.westerlund@ericsson.com Wed Jan 30 01:50:49 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1402A21F85E8 for ; Wed, 30 Jan 2013 01:50:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.174 X-Spam-Level: X-Spam-Status: No, score=-105.174 tagged_above=-999 required=5 tests=[AWL=1.075, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 NkvImeForRCo for ; Wed, 30 Jan 2013 01:50:48 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 6075921F85E7 for ; Wed, 30 Jan 2013 01:50:47 -0800 (PST) X-AuditID: c1b4fb2d-b7f316d0000028db-a2-5108ecf27b33 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 06.64.10459.2FCE8015; Wed, 30 Jan 2013 10:50:43 +0100 (CET) Received: from [127.0.0.1] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.279.1; Wed, 30 Jan 2013 10:50:43 +0100 Message-ID: <5108ECF2.9000407@ericsson.com> Date: Wed, 30 Jan 2013 10:50:42 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: "Cullen Jennings (fluffy)" References: <50F9728E.6000206@ericsson.com> In-Reply-To: X-Enigmail-Version: 1.5 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnluLIzCtJLcpLzFFi42KZGfG3VvfzG45Ag2VHxS06JrNZrP3Xzu7A 5DHl90ZWjyVLfjIFMEVx2aSk5mSWpRbp2yVwZVzsusdWcF2wYumnp6wNjPv5uhg5OSQETCS2 dx5mgrDFJC7cW8/WxcjFISRwklHiyNvT7BDOckaJB7+Os4FU8QpoS1y7dhTMZhFQlZh34REr iM0mYCFx80cjWFxUIFhiw8FVTBD1ghInZz5hAbFFBAwlmvbMA4szC6hL3Fl8jh3EFhZwlNjS twCsV0ggR2Lq9yNgNZwCvhLH5m1k7GLkALpOXGLNGw6IVj2JKVdbGCFseYnmrbOZIVq1JRqa OlgnMArNQrJ5FpKWWUhaFjAyr2Jkz03MzEkvN9zECAzUg1t+6+5gPHVO5BCjNAeLkjhvmOuF ACGB9MSS1OzU1ILUovii0pzU4kOMTBycUg2MNhIm7+Y9W5YmrXDhQiTv3wOnj6sLTnwrGtk5 49Knrxe+mVdc4P+3Ykb2tL9HcnPkjn8xbRCpzrz+4M+VdRuf9F4+2Bh0+Z/KuT9ZezbOzzms nFVzwol124mUlp9Sup8X5+tqfdryoCr5rv/+bKnd+Q03Ey94h7sf4wycr38nKNX+9pFghg3c UkosxRmJhlrMRcWJAJjzwYsiAgAA Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] WG Last Call: draft-ietf-rtcweb-overview-05 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 30 Jan 2013 09:50:49 -0000 WG, We still haven't gotten any reviews for this document. We need reviews to be able to determine how to proceed with the document. Please review this. Cheers Magnus On 2013-01-29 19:51, Cullen Jennings (fluffy) wrote: > > The combination of getting ready for the interim meeting and being sick, I am sorry but won't be able to get this done by deadline but I will still get a review done at later. > > Sorry, Cullen > > On Jan 18, 2013, at 9:04 AM, Magnus Westerlund wrote: > >> WG, >> >> I would here by like to announce a two week WG last call that ends on >> the 1st of February. Please review this, we chairs do acknowledge that >> some references will be required to be updated before submitting for >> publication, but we do need determine if this is ready for publication >> and can consider it done. >> >> Document is available here: >> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-overview/ >> >> Cheers >> >> Magnus Westerlund >> >> ---------------------------------------------------------------------- >> Multimedia Technologies, Ericsson Research EAB/TVM >> ---------------------------------------------------------------------- >> Ericsson AB | Phone +46 10 7148287 >> Färögatan 6 | Mobile +46 73 0949079 >> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com >> ---------------------------------------------------------------------- >> >> _______________________________________________ >> 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 > > -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From stefan.lk.hakansson@ericsson.com Wed Jan 30 01:51:00 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3157221F85E8; Wed, 30 Jan 2013 01:51:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, 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 vbvXEtJZZ19O; Wed, 30 Jan 2013 01:50:59 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 77AB721F85E7; Wed, 30 Jan 2013 01:50:58 -0800 (PST) X-AuditID: c1b4fb25-b7f366d000004d10-42-5108ed01b4ad Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 57.0F.19728.10DE8015; Wed, 30 Jan 2013 10:50:57 +0100 (CET) Received: from [150.132.141.90] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.279.1; Wed, 30 Jan 2013 10:50:56 +0100 Message-ID: <5108ED00.9090605@ericsson.com> Date: Wed, 30 Jan 2013 10:50:56 +0100 From: =?windows-1252?Q?Stefan_H=E5kansson_LK?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: mmusic@ietf.org, rtcweb@ietf.org, "public-webrtc@w3.org" , "public-media-capture@w3.org" Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrJJMWRmVeSWpSXmKPExsUyM+JvrS7jW45Ag4YPChZTlz9msbi6eBeL Re/HJYwWa/+1szuweCxZ8pPJ4+i8/awBTFFcNimpOZllqUX6dglcGc8/nmIsWMdXcX36cfYG xq/cXYycHBICJhJLzi5hh7DFJC7cW8/WxcjFISRwklGi+0I/lLOGUWLflNPMIFW8AtoSL06c B+tgEVCVWNh5CyjOwcEmECwxY4oRSFhUIEri/dUmqHJBiZMzn7CAzBERmMoo8WDPZyaQhLCA nMS640/ZQHqZBewlHmwtAwkzC8hLNG+dDdYrJKAr8e71PdYJjHyzkIyahdAxC0nHAkbmVYzs uYmZOenlRpsYgcF1cMtv1R2Md86JHGKU5mBREucNd70QICSQnliSmp2aWpBaFF9UmpNafIiR iYNTqoHRePXiR23i0+bpdflXv7LS3uafY7dlc3d/0aKvM8o/OS5k/n4m2PGyxAyTH3JXb0TO m+vb9VNQKSL5+gIb3y9/onnvKR7ZuJgnfEeGoOfOomkybHb1XZsOZh0pypuxuWTHGpsS+cqI D/nG3l8Nr2X1HSl7Wsy10dCWe1KKJMPW09ZuNUHzl5YqsRRnJBpqMRcVJwIAKVISWfwBAAA= Subject: [rtcweb] Boston meeting agenda X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 30 Jan 2013 09:51:00 -0000 All, below is a merged agenda covering both W3C and IETF parts of the meeting. Details are likely to change - the main message is that W3C meetings will be before lunch, and IETF after. Before lunch could mean 8:30 - 12:30, after lunch 13:30 - 17:30; but the exact times are TBC. A hard stop is planned for 17:00 on Feb 7th as many have planes to catch. (The sources used to assemble the agenda below are the W3C meeting wiki's, [1][2], and the mail sent to mmusic and rtcweb Jan 14th [3]). --Stefan (for all involved chairs) Feb 5th ======= Morning session: W3C Media Capture TF ------------------------------------- * device enumeration * error handling * “immediate stream” gUM * Resource reservation Afternoon session: IETF mmusic and rtcweb WGs --------------------------------------------- * Multiple Flow SDP representation * SDP for Data channels Feb 6th ======= Morning session: W3C Media Capture TF + WebRTC WG ------------------------------------------------- * Identity aspects of MediaStreams (MediaCap) * Settings/constraints (MediaCap) * Recording (MediaCap) * Call flow (WebRTC) Afternoon session: IETF mmusic and rtcweb WGs --------------------------------------------- * SDP Grouping (Bundle/MMT/one-rtp) * Mapping stream/track label concepts to SDP identifiers Feb 7th ======= Morning session: W3C WebRTC WG ------------------------------ * MediaStream and MediaStreamTrack - SDP interface * Error handling * Data channel * Stats Afternoon session: IETF mmusic and rtcweb WGs --------------------------------------------- * Trickle ICE * JSEP [1] http://www.w3.org/wiki/Media_Capture/Feb_5-6_2013 [2] http://www.w3.org/2011/04/webrtc/wiki/February_6_-_February_7_2013 [3] http://www.ietf.org/mail-archive/web/rtcweb/current/msg06069.html From andrew.hutton@siemens-enterprise.com Wed Jan 30 01:58:15 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F0C221F87C5 for ; Wed, 30 Jan 2013 01:58:15 -0800 (PST) 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 szBqpyaiSJeS for ; Wed, 30 Jan 2013 01:58:14 -0800 (PST) Received: from senmx12-mx.siemens-enterprise.com (senmx12-mx.siemens-enterprise.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 9D1B121F87AA for ; Wed, 30 Jan 2013 01:58:14 -0800 (PST) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id 3844523F05D1 for ; Wed, 30 Jan 2013 10:58:13 +0100 (CET) Received: from MCHP04MSX.global-ad.net ([169.254.1.175]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.02.0318.001; Wed, 30 Jan 2013 10:58:13 +0100 From: "Hutton, Andrew" To: "rtcweb@ietf.org" Thread-Topic: [rtcweb] WG Last Call: draft-ietf-rtcweb-overview-05 Thread-Index: AQHN/lGjbzSX4OeWckuvaIsOzbiASphhojsg Date: Wed, 30 Jan 2013 09:58:12 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF013C85C2@MCHP04MSX.global-ad.net> References: <50F9728E.6000206@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.29.42.225] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [rtcweb] WG Last Call: draft-ietf-rtcweb-overview-05 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 30 Jan 2013 09:58:15 -0000 I am wondering whether this is really the right time to be calling last cal= l on this document and don't see the harm in leaving this in draft status u= ntil we have made some progress on more important issues and in the mean ti= me this document may need updating to keep up to date with decisions made r= egarding SDP issues etc. I also have reviewing this draft on my list of things to do but probably pr= eparing for the interim is more important. Regards Andy > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > Behalf Of Cullen Jennings (fluffy) > Sent: 29 January 2013 18:51 > To: rtcweb@ietf.org > Subject: Re: [rtcweb] WG Last Call: draft-ietf-rtcweb-overview-05 >=20 >=20 > The combination of getting ready for the interim meeting and being > sick, I am sorry but won't be able to get this done by deadline but I > will still get a review done at later. >=20 > Sorry, Cullen >=20 > On Jan 18, 2013, at 9:04 AM, Magnus Westerlund > wrote: >=20 > > WG, > > > > I would here by like to announce a two week WG last call that ends on > > the 1st of February. Please review this, we chairs do acknowledge > that > > some references will be required to be updated before submitting for > > publication, but we do need determine if this is ready for > publication > > and can consider it done. > > > > Document is available here: > > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-overview/ > > > > Cheers > > > > Magnus Westerlund > > > > --------------------------------------------------------------------- > - > > Multimedia Technologies, Ericsson Research EAB/TVM > > --------------------------------------------------------------------- > - > > Ericsson AB | Phone +46 10 7148287 > > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > > --------------------------------------------------------------------- > - > > > > _______________________________________________ > > 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 harald@alvestrand.no Wed Jan 30 02:02:07 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6272D21F867E for ; Wed, 30 Jan 2013 02:02:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v5yzt+PeE9VN for ; Wed, 30 Jan 2013 02:02:06 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id C9EA521F87EA for ; Wed, 30 Jan 2013 02:02:05 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8F73939E18D for ; Wed, 30 Jan 2013 11:02:02 +0100 (CET) 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 2iSIlp6ybaw2 for ; Wed, 30 Jan 2013 11:02:01 +0100 (CET) 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 5981C39E125 for ; Wed, 30 Jan 2013 11:02:01 +0100 (CET) Message-ID: <5108EF98.5010003@alvestrand.no> Date: Wed, 30 Jan 2013 11:02:00 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: rtcweb@ietf.org References: <50F97303.4070906@ericsson.com>, In-Reply-To: Content-Type: multipart/alternative; boundary="------------020100000805070900070508" Subject: [rtcweb] 2119 language in requirements (Re: Review of draft-ietf-rtcweb-use-cases-and-requirements-10 (Part I)) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 30 Jan 2013 10:02:07 -0000 This is a multi-part message in MIME format. --------------020100000805070900070508 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Bernard, with your IAB hat on - didn't we do a document describing how to do 2119 language in requirements at one time? (Since the word "requirements" occurs so often in 2119 itself, it's hard to google for it) Failing that, I support adapting the language of RFC 2928 (needs adapting, because we're expecting to develop a single specification suite rather than evaluating multiple submissions) and inserting it here. On 01/29/2013 11:36 PM, Bernard Aboba wrote: > I have a very fundamental question about this document: > > What are the Browser and API requirements going to be used for? > > Is the goal to document things we thought might have been nice at the > time? > > In many cases, the requirements are too vague to easily determine > whether subsequent IETF > protocol profiles or W3C API documents actually satisfy the > requirements. But even if they were > made more specific, is there really any intent to evaluate IETF and > W3C work based on these requirements? > > Section 2 states that normative keywords are to be interpretted as > described in RFC 2119. > Since this isn't a protocol specification, does that really make sense? > > As an example, requirement F3 states: > > "Transmitted streams and data MUST be rate controlled." > > While the statement above might make some sense in the context of the > "circuit breakers" document, or > perhaps one of the congestion control documents, I don't understand > what the MUST means in the context of > this document. > > Does it mean that the specifications are required to define a rate > control feature? > Assuming such a feature is defined, does it mean that browsers are > required to implement the feature? > If implementation is required, is it required that the feature be used? > > Personally, my guess is that the meaning probably does not correspond > to any of the above, because this > is only a use case document, not a protocol or API specification. > > But if that is true, why point to the RFC 2119 definition of normative > terms? > > In the past, a number of requirements documents have tackled this > problem by explicitly > stating that how normative language is to be interpretted, rather than > blindly inserting a > reference to RFC 2119. For example, RFC 2989 states: > > Please note that the requirements specified in this document are to > be used in evaluating... protocol submissions. As such, the > requirements language refers to capabilities of these protocols; the > protocol documents will specify whether these features are required, > recommended, or optional. For example, requiring that a protocol > support confidentiality is NOT the same thing as requiring that all > protocol traffic be encrypted. > > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --------------020100000805070900070508 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Bernard, with your IAB hat on - didn't we do a document describing how to do 2119 language in requirements at one time?
(Since the word "requirements" occurs so often in 2119 itself, it's hard to google for it)

Failing that, I support adapting the language of RFC 2928 (needs adapting, because we're expecting to develop a single specification suite rather than evaluating multiple submissions) and inserting it here.


On 01/29/2013 11:36 PM, Bernard Aboba wrote:
I have a very fundamental question about this document:

What are the Browser and API requirements going to be used for?

Is the goal to document things we thought might have been nice at the time?

In many cases, the requirements are too vague to easily determine whether subsequent IETF
protocol profiles or W3C API documents actually satisfy the requirements.  But even if they were
made more specific, is there really any intent to evaluate IETF and W3C work based on these requirements?

Section 2 states that normative keywords are to be interpretted as described in RFC 2119.
Since this isn't a protocol specification, does that really make sense?

As an example, requirement F3 states:

"Transmitted streams and data MUST be rate controlled."

While the statement above might make some sense in the context of the "circuit breakers" document, or
perhaps one of the congestion control documents, I don't understand what the MUST means in the context of
this document.

Does it mean that the specifications are required to define a rate control feature?
Assuming such a feature is defined, does it mean that browsers are required to implement the feature?
If implementation is required, is it required that the feature be used?

Personally, my guess is that the meaning probably does not correspond to any of the above, because this
is only a use case document, not a protocol or API specification.

But if that is true, why point to the RFC 2119 definition of normative terms?

In the past, a number of requirements documents have tackled this problem by explicitly
stating that how normative language is to be interpretted, rather than blindly inserting a
reference to RFC 2119.  For example, RFC 2989 states:

   Please note that the requirements specified in this document are to
   be used in evaluating... protocol submissions.  As such, the
   requirements language refers to capabilities of these protocols; the
   protocol documents will specify whether these features are required,
   recommended, or optional.  For example, requiring that a protocol
   support confidentiality is NOT the same thing as requiring that all
   protocol traffic be encrypted.




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

--------------020100000805070900070508-- From harald@alvestrand.no Wed Jan 30 02:11:09 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECC5F21F886B for ; Wed, 30 Jan 2013 02:11:09 -0800 (PST) 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, J_CHICKENPOX_19=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 Rctn1WgBdiCm for ; Wed, 30 Jan 2013 02:11:09 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id A138821F8767 for ; Wed, 30 Jan 2013 02:11:08 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id EBF7E39E194 for ; Wed, 30 Jan 2013 11:11:07 +0100 (CET) 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 jQsbLqTsAL0S for ; Wed, 30 Jan 2013 11:11:06 +0100 (CET) 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 046D539E125 for ; Wed, 30 Jan 2013 11:11:05 +0100 (CET) Message-ID: <5108F1B9.9020709@alvestrand.no> Date: Wed, 30 Jan 2013 11:11:05 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: rtcweb@ietf.org References: <50F97303.4070906@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [rtcweb] WG Last Call: draft-ietf-rtcweb-use-cases-and-requirements-10 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 30 Jan 2013 10:11:10 -0000 On 01/29/2013 10:46 PM, Martin Thomson wrote: > I have read this document in the past, but never really reviewed it. > It's something of a mess. Sure, it could use a fairly thorough going > over from an editorial perspective, but that's not what bothers me. > > There is just a lot of stuff in here that we haven't resolved. Some > of this stuff we haven't even discussed, not to mention have concrete > proposals on the table for. I know that you know this, but just so everyone else remembers: The requirements document is a requirements document for both the RTCWEB and the WEBRTC work. So some requirements are addressed only in WEBRTC, others in RTCWEB. > > There are a number of open questions in relation to this document. I > wont repeat those that are actually in the text, which clearly need to > be addressed. I'm more concerned about those features/requirements > that the working group(s) has/have not shown any signs of providing > answers for. Here I speak primarily of the items that are on the > agenda at the upcoming interim meeting. Stream rejection, for > example. > > I would suggest that these documents be held in abeyance until we know > the outcome of the interim. Specifically, whether we are going to > provide technical solutions to the problems under discussion. (Yes, I > know that it is not uncommon for use case documents to be published > with requirements that are impossible, but it's only 2 weeks.) I'd prefer not to formally do this (Last Calls need to close), but the normal procedure is that comments raised during Last Call are addressed after the WG Last Call closes. If addressing comments cause major changes, a new WG Last Call might be in order. > > Specific comments: > > The requirements are all over the place. They almost look like they > have been shuffled. For instance, F33 and F23 are almost identical, > but use different wording. Same for F19 and F29. F24 and F34. Oh, I > get it, you are grouping based on the last digit! Not the most > obvious choice for ordering, or the easiest to review. > > F13 The browser MUST be able to apply spatialization > effects to audio streams. > > So...this is either pointless in the same vein as the requirement "the > browser MUST be able to control the volume of audio" or it is not > addressed. I see A13, but that's not happening. Given where we've > directed effort, I am tempted to suggest that this be removed. In the WEBRTC WG, we've assumed that this is satisfied by saying "audio can be sent to the WebAudio API". > > F14 The browser MUST be able to measure the level > in audio streams. (also A14) > > As written, this is pointless. If the audio can be played, the level > can be measured. Unless the intent is that the browser provide this > information to the application. In which case, we have the security > implications to consider, when streams are marked as "tainted", this > should not be possible. Agree that this is relatively pointless; if it can do A14 (report level), it can do F14. > > F15 The browser MUST be able to change the level > in audio streams. > > This is a problem for the same reason as above. AGC is one thing, but > this is unspecific. Does this apply to inbound and outbound streams? > Is this level control provided to the application or is this a > pointless requirement on browser chrome? This also has implications > for "tainted" streams, in which case I believe that even level control > should be prevented. I think you're wrong about tainting, but I wonder if this is trivially satisfied by the fact that output elements have volume controls (and there's always WebAudio as a backup). > > F7 The browser MUST support fast stream switches. > > What does this mean? There are a number of factors that could be at play here: > 1. There are two live streams (inbound or locally sourced) and the > browser must be able to switch from playback of one to the other > quickly. This should be trivial to implement. Even then, we need to > be careful that switching can't be to fast for tainted streams. > 2. There are two live streams sourced locally and the browser must be > able to switch from transmission of one to the other quickly. This > does have some limitations if the two streams have different > properties such that this requires signaling. > 3. There are two streams where the stream that is being switched in is > remotely sourced and currently inactive. The browser needs to > activate and begin playback of that stream quickly. This is what is > implied by the use case in Section 4.3.3. Not clear what you intend to say - does it need to be specified further, or removed? The scenario that derives this requirement is 4.3.3.1 "Video conferencing system with central server". "As the video streams to display can change quite frequently (as the conversation flows) it is important that the delay from when a video stream is selected for display until the video can be displayed is short." "Short" is not specified further, but in the common case of voice activated switching, I think one assumes that you want to see the speaker before he's finished his first word. > > F19 Streams and data MUST be able to pass through > restrictive firewalls. > > Suggest rewording, perhaps to use of the term "limited middleboxes" > rather than "restrictive firewalls". Otherwise, this could be > interpreted as a *requirement* to circumvent local network policy. > F29 seems like a better model, though I note that it is a duplicate of > this. I saw a note the other day about "we have to specify a limited source port range so that our firewall admin will not laugh in our face when we ask for enough privilleges to use WebRTC through the firewall". I think this section needs to be rethought as "it should be possible to behave in a way that will make restrictive firewall admins let things through" - this might be as simple(?) as specifying that TURN/TCP MUST be supported (and you whitelist the TURN addresses with the firewall admin), or might be more complex. Given the pushing-on-string nature of the requirement, I think it should be a SHOULD. > > F37 The browser MUST be able to send streams and > data to a peer in the presence of FWs that only > allows http(s) traffic. > > This is a more specific version of F19, for which my same comment > applies. I haven't seen any attempt to provide a solution. Can this > be removed? TURN/TLS will satisfy this requirement. > > F22 There should be a way to navigate > a DTMF based IVR > > Expand on first use: IVR and DTMF. > > F26 It MUST be possible to move from one network > interface to another one > > For whom must this be possible? Certainly, the browser is able to > make this choice, but the application has only limited ability to > control this in the current application. I can imagine perhaps > changing priority values on a=candidate lines based on some guessing > about what interfaces are what, but I have a strong expectation that > this would have zero effect in any ICE implementation. ICE restart satisfies this requirement for the "break before make" case. > > F28 The browser MUST support a baseline audio and > video codec > > No comment. > > F32 There browser MUST support that STUN and TURN > servers to use are supplied by other entities > than the service provided (i.e. the network > provider). > > I'm not sure what the "service provided" is in this case. There is an > application and the browser. The discovery of local STUN/TURN servers > is surely a browser issue outside of the scope of these requirements. > A note in a solution document that makes the observation that > browser-provided STUN/TURN servers be used in addition to any provided > by the application would be more appropriate. I think that's in JSEP somewhere. I don't see the need to change the requirement (although defining or changing the term "the service provided" would be good). > > A17 For each stream generated, the Web API MUST > provide an identifier that is accessible by the > application. The identifier MUST be accessible > also for a peer receiving that stream and MUST > be unique relative to all other stream > identifiers in use by either party. > > This seems overly specific. I presume that the intent was to ensure > that streams that originate on a sending browser be identifiable on a > receiving browser. This actually specifies a solution to that problem > rather than the requirement. Suggest: The Web API MUST provide a way > to identify streams such that an application is able to match streams > on a sending peer with the same stream on all receiving peers. > Identifier uniqueness requirements derive from that requirement, plus > any additional constraints that you choose to apply (read: SDP). I like the reformulation. > > A25 It must be possible for the application to > refrain from exposing the IP address > > Missing something. "the" IP address. Which one specifically? Oh, > you must (MUST) be able to refrain from revealing that information. > > Editorial: > A19 is missing: "to", " ". > A20 not only anthropomorphizes the browser, it assigns a gender; how > can be sure it's not a "she"? > Fix the IANA Considerations section, it's not hard. > > > > > > On 19 January 2013 01:06, Magnus Westerlund > wrote: >> WG, >> >> I would here by like to announce a two week WG last call that ends on >> the 1st of February. >> >> Document is available here: >> >> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-use-cases-and-requirements/ >> >> Cheers >> >> Magnus Westerlund >> >> ---------------------------------------------------------------------- >> Multimedia Technologies, Ericsson Research EAB/TVM >> ---------------------------------------------------------------------- >> Ericsson AB | Phone +46 10 7148287 >> Färögatan 6 | Mobile +46 73 0949079 >> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com >> ---------------------------------------------------------------------- >> >> _______________________________________________ >> 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 derhoermi@gmx.net Wed Jan 30 04:23:47 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6A5D21F88C7 for ; Wed, 30 Jan 2013 04:23:47 -0800 (PST) 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 4srfZN1JmeDi for ; Wed, 30 Jan 2013 04:23:46 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id 695F121F88B6 for ; Wed, 30 Jan 2013 04:23:46 -0800 (PST) Received: from mailout-de.gmx.net ([10.1.76.34]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0LmQiS-1UaPgZ24AM-00Zxrp for ; Wed, 30 Jan 2013 13:23:45 +0100 Received: (qmail invoked by alias); 30 Jan 2013 12:23:45 -0000 Received: from p5B0625B3.dip.t-dialin.net (EHLO netb.Speedport_W_700V) [91.6.37.179] by mail.gmx.net (mp034) with SMTP; 30 Jan 2013 13:23:45 +0100 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX1/TzCtqpIfTUOID2ikSb+pj1Nf9hH7a1K0GfH4+sR ddJOmmJ1YaVISz From: Bjoern Hoehrmann To: rtcweb@ietf.org Date: Wed, 30 Jan 2013 13:23:46 +0100 Message-ID: X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Subject: [rtcweb] Comments on draft-ietf-rtcweb-overview-05 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 30 Jan 2013 12:23:48 -0000 Hi, http://tools.ietf.org/html/draft-ietf-rtcweb-overview-05 claims that it is an "overview" in title and abstract, but it also references RFC 2119 and uses RFC 2119 keywords and has normative references making the role of the document unclear. Either the RFC 2119 reference and keywords have to be removed, or Abstract and perhaps title have to be changed to make it clear who or what would conform to this specification. I understand the Chairs are already aware some of the references need to be updated. The `[getusermedia]` reference should point to some proper publication of the W3C, under `http://www.w3.org/TR/` most likely. There are various parts that have placeholder text, e.g. section 9 has "" and '', and Appendix A has 'The draft referred to as "transport and middle boxes" in Section 4 has not been written yet.' That seems to indicate that the draft is not ready for publication yet. In section 12 is a typo "ad to" which should probably be "and to". Also in section 12, "The number of people who have taken part in the discussions surrounding this draft are too numerous to list". Ordinarily people would not be acknowledged simply for having taken part in some discussion surrounding a document, and it's usually not true that there have been "too many to list"; I think it would be better to remove the quoted text. As noted in http://www.w3.org/2001/06/manual/#Translations the document should not use "we" as that is hard to translate and usually it's not very clear who the pronoun refers to (authors, editors, working group, the IETF at large, or someone else). There seem to be many phrases used in the document that are not very suitable for a general audience, examples are "communications event", "communications partnership", and "a strong changer of the marketplace of deployment". (Two of the phrases there come from the last paragraph in 2.3. which as a whole is not very comprehensible and probably needs to be re-written). regards, -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From stefan.lk.hakansson@ericsson.com Wed Jan 30 05:31:16 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0B9121F8AD0 for ; Wed, 30 Jan 2013 05:31:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.649 X-Spam-Level: X-Spam-Status: No, score=-5.649 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_19=0.6, MIME_8BIT_HEADER=0.3, 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 gDMn7vPBgDuA for ; Wed, 30 Jan 2013 05:31:15 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 12FE621F8AB2 for ; Wed, 30 Jan 2013 05:31:14 -0800 (PST) X-AuditID: c1b4fb30-b7f0d6d000007e61-d5-510920a1ac17 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id F6.DE.32353.1A029015; Wed, 30 Jan 2013 14:31:13 +0100 (CET) Received: from [150.132.141.90] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.279.1; Wed, 30 Jan 2013 14:31:12 +0100 Message-ID: <510920A0.6090704@ericsson.com> Date: Wed, 30 Jan 2013 14:31:12 +0100 From: =?UTF-8?B?U3RlZmFuIEjDpWthbnNzb24gTEs=?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: rtcweb@ietf.org References: <50F97303.4070906@ericsson.com> In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHJMWRmVeSWpSXmKPExsUyM+Jvre5CBc5Ag2sHpS3W/mtnd2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxsJr/9kL7gRW/JnzhbGB8YJtFyMnh4SAicSzvoVMELaYxIV7 69m6GLk4hAROMkpM2tDNDuGsYZT4+XM/C0gVr4C2xPtbX4ASHBwsAqoScxZog4TZBIIl9i8H aebkEBWIknh/tYkZolxQ4uTMJ2CtIgLCEltf9YItEwaqXznxCyOILSRQIHF/x1Wwek6BQInX dzeD2cwCFhKL3xxkh7DlJZq3zmaGqNeVePf6HusERoFZSFbMQtIyC0nLAkbmVYzsuYmZOenl 5psYgWF2cMtvgx2Mm+6LHWKU5mBREucNd70QICSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoGx ekrEF7ao1W82HyxW+Re36eBK3+u3qzdETsp9UPFj6/209LU6f2y4vJ8XfVro+0xMfclGv4pp tb5eLh6r+j4WPe6oTjx993NkjfWGoOvbF03slT/xwOkv/86EybERkj9eKNwN4V6euGrmw/06 b+6HbX/3Z3r0bWvz14GXrnz//HJP3o9Fl2Y9KldiKc5INNRiLipOBADSkLNdAQIAAA== Subject: Re: [rtcweb] WG Last Call: draft-ietf-rtcweb-use-cases-and-requirements-10 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 30 Jan 2013 13:31:16 -0000 On 2013-01-29 22:46, Martin Thomson wrote: > I have read this document in the past, but never really reviewed it. > It's something of a mess. Sure, it could use a fairly thorough going > over from an editorial perspective, but that's not what bothers me. > > There is just a lot of stuff in here that we haven't resolved. Some > of this stuff we haven't even discussed, not to mention have concrete > proposals on the table for. > > There are a number of open questions in relation to this document. I > wont repeat those that are actually in the text, which clearly need to > be addressed. I'm more concerned about those features/requirements > that the working group(s) has/have not shown any signs of providing > answers for. Here I speak primarily of the items that are on the > agenda at the upcoming interim meeting. Stream rejection, for > example. > > I would suggest that these documents be held in abeyance until we know > the outcome of the interim. Specifically, whether we are going to > provide technical solutions to the problems under discussion. (Yes, I > know that it is not uncommon for use case documents to be published > with requirements that are impossible, but it's only 2 weeks.) > > Specific comments: > > The requirements are all over the place. They almost look like they > have been shuffled. For instance, F33 and F23 are almost identical, > but use different wording. Same for F19 and F29. F24 and F34. Oh, I > get it, you are grouping based on the last digit! Not the most > obvious choice for ordering, or the easiest to review. :-). Fair comment. > > F13 The browser MUST be able to apply spatialization > effects to audio streams. > > So...this is either pointless in the same vein as the requirement "the > browser MUST be able to control the volume of audio" or it is not > addressed. I see A13, but that's not happening. Given where we've > directed effort, I am tempted to suggest that this be removed. > > F14 The browser MUST be able to measure the level > in audio streams. (also A14) > > As written, this is pointless. If the audio can be played, the level > can be measured. Unless the intent is that the browser provide this > information to the application. In which case, we have the security > implications to consider, when streams are marked as "tainted", this > should not be possible. This was written well before the "tainted" stuff started to appear; it may be that it should not be possible for "tainted" streams (or rather: the browser should in any case not be allowed to report to the app). Many of the reqs have a similar structure: there is an "F" requirement on functionality in the browser, and a corresponding "A" requirement that exposes this functionality to the application. I'm not sure changing that structure would be a big gain. > > F15 The browser MUST be able to change the level > in audio streams. > > This is a problem for the same reason as above. AGC is one thing, but > this is unspecific. Does this apply to inbound and outbound streams? > Is this level control provided to the application or is this a > pointless requirement on browser chrome? This also has implications > for "tainted" streams, in which case I believe that even level control > should be prevented. This (as F14) is intended for the application, as it is associated with A15. And the intention was to not limit it to local or remote streams, but to allow it for any stream. > > F7 The browser MUST support fast stream switches. > > What does this mean? There are a number of factors that could be at play here: > 1. There are two live streams (inbound or locally sourced) and the > browser must be able to switch from playback of one to the other > quickly. This should be trivial to implement. Even then, we need to > be careful that switching can't be to fast for tainted streams. > 2. There are two live streams sourced locally and the browser must be > able to switch from transmission of one to the other quickly. This > does have some limitations if the two streams have different > properties such that this requires signaling. > 3. There are two streams where the stream that is being switched in is > remotely sourced and currently inactive. The browser needs to > activate and begin playback of that stream quickly. This is what is > implied by the use case in Section 4.3.3. This requirement is derived from the "Video conferencing system with central server" use-case. The intention was to say something like "if the central node asks for an intraframe, the browser should insert it". > > F19 Streams and data MUST be able to pass through > restrictive firewalls. > > Suggest rewording, perhaps to use of the term "limited middleboxes" > rather than "restrictive firewalls". Otherwise, this could be > interpreted as a *requirement* to circumvent local network policy. > F29 seems like a better model, though I note that it is a duplicate of > this. > > F37 The browser MUST be able to send streams and > data to a peer in the presence of FWs that only > allows http(s) traffic. > > This is a more specific version of F19, for which my same comment > applies. I haven't seen any attempt to provide a solution. Can this > be removed? I agree that the reqs related to traversal of different FWs and NATs is a mess. I think that there originally was only one of them, and that we've added more as people have asked for it along the way. > > F22 There should be a way to navigate > a DTMF based IVR > > Expand on first use: IVR and DTMF. Yes. > > F26 It MUST be possible to move from one network > interface to another one > > For whom must this be possible? Certainly, the browser is able to > make this choice, but the application has only limited ability to > control this in the current application. I can imagine perhaps > changing priority values on a=candidate lines based on some guessing > about what interfaces are what, but I have a strong expectation that > this would have zero effect in any ICE implementation. The requirement does not go into what is done in the application and what is done in the browser. But requirement comes from the use-case "Simple Video Communication Service, access change" where the user unplugs the Ethernet cable. The session is then supposed to continue on WiFi (or cellular). I think that is a fair requirement. > > F28 The browser MUST support a baseline audio and > video codec > > No comment. > > F32 There browser MUST support that STUN and TURN > servers to use are supplied by other entities > than the service provided (i.e. the network > provider). > > I'm not sure what the "service provided" is in this case. There is an > application and the browser. The discovery of local STUN/TURN servers > is surely a browser issue outside of the scope of these requirements. > A note in a solution document that makes the observation that > browser-provided STUN/TURN servers be used in addition to any provided > by the application would be more appropriate. "service porvided" should be "(communication) service provider". Yes perhaps this should be moved to a solution document. I think it was Cullen who pushed for this requirement, but I don't remember the reasoning. > > A17 For each stream generated, the Web API MUST > provide an identifier that is accessible by the > application. The identifier MUST be accessible > also for a peer receiving that stream and MUST > be unique relative to all other stream > identifiers in use by either party. > > This seems overly specific. I presume that the intent was to ensure > that streams that originate on a sending browser be identifiable on a > receiving browser. This actually specifies a solution to that problem > rather than the requirement. Suggest: The Web API MUST provide a way > to identify streams such that an application is able to match streams > on a sending peer with the same stream on all receiving peers. > Identifier uniqueness requirements derive from that requirement, plus > any additional constraints that you choose to apply (read: SDP). Agree. > > A25 It must be possible for the application to > refrain from exposing the IP address > > Missing something. "the" IP address. Which one specifically? Oh, > you must (MUST) be able to refrain from revealing that information. Reformulation needed. > > Editorial: > A19 is missing: "to", " ". > A20 not only anthropomorphizes the browser, it assigns a gender; how > can be sure it's not a "she"? > Fix the IANA Considerations section, it's not hard. Thanks. > > > > > > On 19 January 2013 01:06, Magnus Westerlund > wrote: >> WG, >> >> I would here by like to announce a two week WG last call that ends on >> the 1st of February. >> >> Document is available here: >> >> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-use-cases-and-requirements/ >> >> Cheers >> >> Magnus Westerlund >> >> ---------------------------------------------------------------------- >> Multimedia Technologies, Ericsson Research EAB/TVM >> ---------------------------------------------------------------------- >> Ericsson AB | Phone +46 10 7148287 >> Färögatan 6 | Mobile +46 73 0949079 >> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com >> ---------------------------------------------------------------------- >> >> _______________________________________________ >> 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 stefan.lk.hakansson@ericsson.com Wed Jan 30 05:55:48 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFB5321F8B0F for ; Wed, 30 Jan 2013 05:55:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.849 X-Spam-Level: X-Spam-Status: No, score=-5.849 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, 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 k8yx8xHdAzDW for ; Wed, 30 Jan 2013 05:55:48 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 4023721F8B0E for ; Wed, 30 Jan 2013 05:55:47 -0800 (PST) X-AuditID: c1b4fb2d-b7f316d0000028db-c8-51092660222c Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 2F.E8.10459.06629015; Wed, 30 Jan 2013 14:55:44 +0100 (CET) Received: from [150.132.141.90] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.279.1; Wed, 30 Jan 2013 14:55:44 +0100 Message-ID: <5109265F.6040106@ericsson.com> Date: Wed, 30 Jan 2013 14:55:43 +0100 From: =?ISO-8859-1?Q?Stefan_H=E5kansson_LK?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: rtcweb@ietf.org References: <50F97303.4070906@ericsson.com>, , , In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPJMWRmVeSWpSXmKPExsUyM+JvrW6CGmegwYrvihZr/7WzOzB6LFny kymAMYrLJiU1J7MstUjfLoErY+72FUwFvSEVM6YuYGtgXGbTxcjJISFgIrGj+SkThC0mceHe erYuRi4OIYGTjBLvti5jhnDWMEqc2dnNCFLFK6Atsf37DVYQm0VAVWLd2pfMIDabQKDE9f+/ wCaJCkRJvL/axAxRLyhxcuYTFhBbREBYYuurXrAaYYFoiZ51EHOEBC4ySnzcZwBicwpYS6x5 Nh8szixgK3FhznUWCFteYvvbOcwQ9boS717fY53AKDALyYpZSFpmIWlZwMi8ipE9NzEzJ73c cBMjMNAObvmtu4Px1DmRQ4zSHCxK4rxhrhcChATSE0tSs1NTC1KL4otKc1KLDzEycXBKNTDK O3b8UeK1NK8W798Z+a/rQPkFxS22SzS3Xv7x0mO1k1qk0tyTcntYXOb82WeX8Lrpivvq9x9a DH9mz+i/W7XsGNOxPX+6fMJu6Yl4iFt+nXBCRCtcP6Do7YSenp2OK9yCuzflrvRYftI55k3Y sfsz5p+fuoBZZLaqMdvbrUsnrtvVF3qkR9hciaU4I9FQi7moOBEAhpZlvgICAAA= Subject: Re: [rtcweb] Review of draft-ietf-rtcweb-use-cases-and-requirements-10 (Part II) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 30 Jan 2013 13:55:49 -0000 On 2013-01-30 00:04, Bernard Aboba wrote: > Putting aside the meaning of the normative language in the document, > and the purpose of the document, here are some thoughts on the > requirements contained therein: > > REQ-ID DESCRIPTION > --------------------------------------------------------------- > F1 The browser MUST be able to use microphones and > cameras as input devices to generate streams. > > [BA] Can I assume that the use of the plural implies a requirement to be able to support multiple sources? Yes. And in the use-case "Hockey Game Viewer" multiple cameras are used. > ---------------------------------------------------------------- > F2 The browser MUST be able to send streams and > data to a peer in the presence of NATs. > > [BA] Is this really only about sending streams, but not receiving?? Of course it is both, but it is split up in F2 saying that the browser must be able to send to a peer (even if there is NAT('s) present in the path and F4 (be able to receive, process and render). > > ---------------------------------------------------------------- > F3 Transmitted streams and data MUST be rate > controlled. > > [BA] I think we need to be more specific. Are we talking about support for "congestion control", and if so, are we saying > this should be mandatory to implement or use? Or is this about "consent"? Or maybe preventing congestive collapse in some circumstances > (e.g. circuit breakers)? The intention was to put a MUST requirement on that the browser should not create congestion (regardless of what the app does). > ---------------------------------------------------------------- > F4 The browser MUST be able to receive, process and > render streams and data ("render" does not > apply for data) from peers. > ---------------------------------------------------------------- > F5 The browser MUST be able to render good quality > audio and video even in the presence of > reasonable levels of jitter and packet losses. > > TBD: What is a reasonable level? > > [BA] I am not sure what this means. Is it implying the need for a strategy to deal with loss in the MTI codec? > For example, is this implying a requirement for codec adaption, > or FEC or re-transmission? I don't see the purpose of letting the TBD remain here. The TBD could go; my interpretation is that at the very least there should be some PLC implemented. > ---------------------------------------------------------------- > F6 The browser MUST be able to handle high loss and > jitter levels in a graceful way. > > [BA] What does "graceful" mean?? Is this referring to the resilience of the codec and > loss-strategy (see above), or to enabling the application to adapt to loss? I agree. This is very vague. I think that what was in mind at the time was that the browser should not be worse than existing native clients during bad network conditions (e.g. strange high level audio sounds that comes from decoding erroneous data should not be played). I think this req could go. > > ---------------------------------------------------------------- > F7 The browser MUST support fast stream switches. > > [BA] I really am not sure what is meant here. Are we talking about the ability of a sender to change > transmission rate quickly (e.g. removing a layer in SVC)? Or about adding/removing a stream? This requirement is derived from the "Video conferencing system with central server" use-case. The intention was to say something like "if the central node asks for an intraframe, the browser should insert it". > > ---------------------------------------------------------------- > F9 When there are both incoming and outgoing audio > streams, echo cancellation MUST be made > available to avoid disturbing echo during > conversation. > > QUESTION: How much control should be left to the > web application? > > [BA] Hadriel's API requirements document talks about the ability to control echo cancellation, which > makes more sense to me than the above. Remove the question. OK. > > ---------------------------------------------------------------- > F10 The browser MUST support synchronization of > audio and video. > > > QUESTION: How much control should be left to the > web application? > > [BA] Synchronization is not necessarily possible or even desirable in all circumstances. > For example, if the video experiences substantial loss, do you really want to delay the audio to sync > with it? So I can understand why it is desirable to support the capability, but is this > really a MUST? I would not bother to attempt to answer the question; delete it. You're right: in some cases it is better to not synchronize. But I still think the browser MUST support it (even if not used in certain cases). > > ---------------------------------------------------------------- > F13 The browser MUST be able to apply spatialization > effects to audio streams. > > [BA] What does this mean in practical terms? In practical terms this is already solved by the Web Audio API. > ---------------------------------------------------------------- > F14 The browser MUST be able to measure the level > in audio streams. > > [BA] See Martin's comments. > ---------------------------------------------------------------- > F15 The browser MUST be able to change the level > in audio streams. > [BA] See Martin's comments. > > ---------------------------------------------------------------- > F18 The browser MUST be able to process and mix > sound objects (media that is retrieved from > another source than the established media > stream(s) with the peer(s) with audio streams. > > [BA] If this is done, isn't it important to make clear to the user (and perhaps the peer) what is happening? > Confusing live and recorded media seems like a potential vector for mischief. This is derived from the use-case "Multiparty on-line game with voice communication". Are you saying that the browser should inform the user that the "boom" sound comes from the explosion on the game scene, while the voice comes from his friend that is playing the same game? I don't see that need. > > ---------------------------------------------------------------- > F19 Streams and data MUST be able to pass through > restrictive firewalls. > > [BA] Do we need this requirement, given that we also have requirements F29 and F37? I agree that the traversal related reqs are messy. > > ---------------------------------------------------------------- > F20 It MUST be possible to protect streams and data > from wiretapping. > > [BA] "Wiretapping" is too vague a phrase to be of much use. It might make more sense to > talk about security services that should be provided (e.g. confidentiality of media). This was discussed a bit, and someone (Harald?) pointed out that wiretapping is well defined and can be used. > > ---------------------------------------------------------------- > F21 The browser MUST support an audio media format > (codec) that is commonly supported by existing > telephony services. > > QUESTION: G.711? > > [BA] The Question: line should probably be removed. Yes. > > ---------------------------------------------------------------- > F26 It MUST be possible to move from one network > interface to another one > [BA] Are we talking about the ability of an application to control this, or the ability of an application to react to it, or something else? It is not split up between application, browser, STUN/TURN server, it is just a requirement on that it should work. > > > ---------------------------------------------------------------- > F29 The browser MUST be able to send streams and > data to a peer in the presence of NATs that > block UDP traffic. > > [BA] Is this just about sending and not receiving? See discussion above. > > ---------------------------------------------------------------- > F35 The browser MUST enable verification, given > the right circumstances and by use of other > trusted communication, of that streams and > data received have not been manipulated by > any party. > [BA] I do not see how such a verification is possible. I was under the impression that DTLS allowed this. > > ---------------------------------------------------------------- > F36 The browser MUST reject incoming media and > data, either modified, created or injected, > by any entity not trusted by the site. > > [BA] Do we really mean "trusted by the site" or "trusted by the browser"? I need to think a bit more about this one. > > ---------------------------------------------------------------- > F37 The browser MUST be able to send streams and > data to a peer in the presence of FWs that only > allows http(s) traffic. > ---------------------------------------------------------------- > F38 The browser MUST be able to collect statistics, > related to the transport of audio and video > between peers, needed to estimate quality of > service. > > [BA] Do we mean "Quality of Service" or "Quality of Experience?" Perhaps Experience is better. > > ---------------------------------------------------------------- > > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From stefan.lk.hakansson@ericsson.com Wed Jan 30 06:01:47 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56EE021F8AA3 for ; Wed, 30 Jan 2013 06:01:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.874 X-Spam-Level: X-Spam-Status: No, score=-5.874 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, 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 BIzK7Q7hY8-V for ; Wed, 30 Jan 2013 06:01:46 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 02CF521F8A98 for ; Wed, 30 Jan 2013 06:01:44 -0800 (PST) X-AuditID: c1b4fb2d-b7f316d0000028db-3a-510927c59282 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id B8.D9.10459.5C729015; Wed, 30 Jan 2013 15:01:41 +0100 (CET) Received: from [150.132.141.90] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.279.1; Wed, 30 Jan 2013 15:01:41 +0100 Message-ID: <510927C4.60808@ericsson.com> Date: Wed, 30 Jan 2013 15:01:40 +0100 From: =?ISO-8859-1?Q?Stefan_H=E5kansson_LK?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: rtcweb@ietf.org References: <50F97303.4070906@ericsson.com>, In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPJMWRmVeSWpSXmKPExsUyM+Jvre5Rdc5Ag4aJShZr/7WzOzB6LFny kymAMYrLJiU1J7MstUjfLoEr49m8GywFZ8UqTr6bx97A+E6wi5GTQ0LAROJn60QWCFtM4sK9 9WxdjFwcQgInGSVat/xihnDWMEp0/3/NCFLFK6Ap8efLJDYQm0VAVWL6xf1gNptAoMT1/7+Y QGxRgSiJ91ebmCHqBSVOznwCtkFEQFhi66tesBphoJrGr0vBeoUE5jNK7DnlAGJzClhJnH7Q BbaLWcBW4sKc6ywQtrzE9rdzmCHqdSXevb7HOoFRYBaSFbOQtMxC0rKAkXkVI3tuYmZOernh JkZgoB3c8lt3B+OpcyKHGKU5WJTEecNcLwQICaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYGz5 xp58apY3yyrriYJ+y280730gfV7wYfOTfxe6sr8qCla2s2+ImXVVLmHFwkW77q57Udx5ZNu/ 4InO8gbtn0UdF5ore4V8ZpGaO/XHbvkrl5uT1swVrdA0ePtE+v6jw/56TIc3zDOfc3t90Is2 g7kiz03NmO/en7tKSnH3AZ0/vMcqc6wDheKVWIozEg21mIuKEwFGpdIbAgIAAA== Subject: Re: [rtcweb] Review of draft-ietf-rtcweb-use-cases-and-requirements-10 (Part I) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 30 Jan 2013 14:01:47 -0000 On 2013-01-29 23:36, Bernard Aboba wrote: > I have a very fundamental question about this document: > > What are the Browser and API requirements going to be used for? This is a very good question. > > Is the goal to document things we thought might have been nice at the time? > > In many cases, the requirements are too vague to easily determine > whether subsequent IETF > protocol profiles or W3C API documents actually satisfy the > requirements. The requirements are quite vague, but I think that if you read them in conjunction with the use-case that introduced them they get a bit more specific. > But even if they were > made more specific, is there really any intent to evaluate IETF and W3C > work based on these requirements? > > Section 2 states that normative keywords are to be interpretted as > described in RFC 2119. > Since this isn't a protocol specification, does that really make sense? > > As an example, requirement F3 states: > > "Transmitted streams and data MUST be rate controlled." > > While the statement above might make some sense in the context of the > "circuit breakers" document, or > perhaps one of the congestion control documents, I don't understand what > the MUST means in the context of > this document. To me it means that the browser should not congest the network (and this is regardless of what the possibly malicious app does). > > Does it mean that the specifications are required to define a rate > control feature? > Assuming such a feature is defined, does it mean that browsers are > required to implement the feature? > If implementation is required, is it required that the feature be used? > > Personally, my guess is that the meaning probably does not correspond to > any of the above, because this > is only a use case document, not a protocol or API specification. > > But if that is true, why point to the RFC 2119 definition of normative > terms? > > In the past, a number of requirements documents have tackled this > problem by explicitly > stating that how normative language is to be interpretted, rather than > blindly inserting a > reference to RFC 2119. For example, RFC 2989 states: > > Please note that the requirements specified in this document are to > be used in evaluating... protocol submissions. As such, the > requirements language refers to capabilities of these protocols; the > protocol documents will specify whether these features are required, > recommended, or optional. For example, requiring that a protocol > support confidentiality is NOT the same thing as requiring that all > protocol traffic be encrypted. This makes a lot of sense. > > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From matthew.kaufman@skype.net Wed Jan 30 08:21:45 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F82621F8945 for ; Wed, 30 Jan 2013 08:21:45 -0800 (PST) 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 7Z-I36870Tih for ; Wed, 30 Jan 2013 08:21:44 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (na01-by2-obe.ptr.protection.outlook.com [207.46.100.28]) by ietfa.amsl.com (Postfix) with ESMTP id 8914621F88CA for ; Wed, 30 Jan 2013 08:21:44 -0800 (PST) Received: from BL2FFO11FD010.protection.gbl (10.173.161.201) by BL2FFO11HUB030.protection.gbl (10.173.161.54) with Microsoft SMTP Server (TLS) id 15.0.596.13; Wed, 30 Jan 2013 16:21:36 +0000 Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD010.mail.protection.outlook.com (10.173.161.16) with Microsoft SMTP Server (TLS) id 15.0.596.13 via Frontend Transport; Wed, 30 Jan 2013 16:21:35 +0000 Received: from TK5EX14MBXC272.redmond.corp.microsoft.com ([169.254.2.197]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi id 14.02.0318.003; Wed, 30 Jan 2013 16:21:07 +0000 From: "Matthew Kaufman (SKYPE)" To: Harald Alvestrand , "rtcweb@ietf.org" Thread-Topic: [rtcweb] WG Last Call: draft-ietf-rtcweb-use-cases-and-requirements-10 Thread-Index: AQHN9ZXKVt89oCOmB0a8awoEAnUu1Jhg6RkAgADP9YCAAGcYEA== Date: Wed, 30 Jan 2013 16:21:07 +0000 Message-ID: References: <50F97303.4070906@ericsson.com> <5108F1B9.9020709@alvestrand.no> In-Reply-To: <5108F1B9.9020709@alvestrand.no> 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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(377454001)(199002)(189002)(13464002)(51856001)(50466001)(47776003)(74502001)(16406001)(59766001)(63696002)(77982001)(50986001)(54356001)(4396001)(47976001)(56816002)(53806001)(47736001)(54316002)(44976002)(55846006)(46102001)(20776003)(47446002)(33656001)(74662001)(79102001)(49866001)(5343655001)(56776001)(76482001)(31966008)(23676001); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB030; H:TK5EX14HUBC103.redmond.corp.microsoft.com; RD:; A:3; MX:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0742443479 Subject: Re: [rtcweb] WG Last Call: draft-ietf-rtcweb-use-cases-and-requirements-10 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 30 Jan 2013 16:21:45 -0000 SSBmaW5kIHRoZSBiZWxvdyBzdGF0ZW1lbnQgc3RyYW5nZSwgYXMgdGhlcmUgaXMgYSBwcm9jZXNz IGZvciBwdWJsaXNoaW5nIHJlcXVpcmVtZW50cyBkb2N1bWVudHMgd2l0aGluIHRoZSBXM0MsIGFu ZCB0aGlzIGlzbid0IGl0Lg0KDQpNYXR0aGV3IEthdWZtYW4NCg0KLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCkZyb206IHJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86cnRjd2ViLWJv dW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBIYXJhbGQgQWx2ZXN0cmFuZA0KU2VudDogV2Vk bmVzZGF5LCBKYW51YXJ5IDMwLCAyMDEzIDI6MTEgQU0NClRvOiBydGN3ZWJAaWV0Zi5vcmcNClN1 YmplY3Q6IFJlOiBbcnRjd2ViXSBXRyBMYXN0IENhbGw6IGRyYWZ0LWlldGYtcnRjd2ViLXVzZS1j YXNlcy1hbmQtcmVxdWlyZW1lbnRzLTEwDQoNCi4uLg0KSSBrbm93IHRoYXQgeW91IGtub3cgdGhp cywgYnV0IGp1c3Qgc28gZXZlcnlvbmUgZWxzZSByZW1lbWJlcnM6IFRoZSByZXF1aXJlbWVudHMg ZG9jdW1lbnQgaXMgYSByZXF1aXJlbWVudHMgZG9jdW1lbnQgZm9yIGJvdGggdGhlIFJUQ1dFQiBh bmQgdGhlIFdFQlJUQyB3b3JrLiBTbyBzb21lIHJlcXVpcmVtZW50cyBhcmUgYWRkcmVzc2VkIG9u bHkgaW4gV0VCUlRDLCBvdGhlcnMgaW4gUlRDV0VCLg0KLi4uDQoNCg== From mary.ietf.barnes@gmail.com Wed Jan 30 08:32:07 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FC3421F845D for ; Wed, 30 Jan 2013 08:32:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.473 X-Spam-Level: X-Spam-Status: No, score=-103.473 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, 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 2TWvzCRf9H6m for ; Wed, 30 Jan 2013 08:32:06 -0800 (PST) Received: from mail-qa0-f46.google.com (mail-qa0-f46.google.com [209.85.216.46]) by ietfa.amsl.com (Postfix) with ESMTP id 902B021F841E for ; Wed, 30 Jan 2013 08:32:06 -0800 (PST) Received: by mail-qa0-f46.google.com with SMTP id o13so2137611qaj.19 for ; Wed, 30 Jan 2013 08:32:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=vhkSx5K1bp4PYhF8BkJVfXgUaHnqz4SGZA41HA8CvuA=; b=tUkHkjiZmSgqsKJwePLpE3aPNSWX4w1ClRawbeNWZn1dfpVnujxrbS7dcuoLG49dN+ 5AjqQF232Y8pW3mpYqs9RFXyjWM2XTUKMo8MBWtpTeFFTkgLjwQA3+e1oe8AGGtwyK+G F6heXS7Dy5FDYBsTRU1rX/a65G4HO2jm+4/1SDYUQT7MMYOvo/4uzSP0BJp559NUNnPw TgKgOzlkmxjP+mnJhEGTLrSM3gOZCtU4VFqlfuHU5/snMQEStL6fZNTJTKZyOstqZ0fg sZwSdjejPp5reT4BNpNrWVNeftZC00klCRsFC28SeU7xP24DbgQOp0DX1rDxv4v63wEb nEiQ== MIME-Version: 1.0 X-Received: by 10.224.181.20 with SMTP id bw20mr5701753qab.72.1359563525826; Wed, 30 Jan 2013 08:32:05 -0800 (PST) Received: by 10.49.131.199 with HTTP; Wed, 30 Jan 2013 08:32:05 -0800 (PST) In-Reply-To: References: <50F97303.4070906@ericsson.com> <5108F1B9.9020709@alvestrand.no> Date: Wed, 30 Jan 2013 10:32:05 -0600 Message-ID: From: Mary Barnes To: "Matthew Kaufman (SKYPE)" Content-Type: text/plain; charset=ISO-8859-1 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] WG Last Call: draft-ietf-rtcweb-use-cases-and-requirements-10 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 30 Jan 2013 16:32:07 -0000 I agree with Matthew. The RTCWEB solution documents should be able to satisfy all the requirements defined in an RTCWEB requirements document (or there needs to be a clear explanation as to why a specific requirement isn't satisfied). I would suggest to at least put the W3C requirements in an appendix. Mary. On Wed, Jan 30, 2013 at 10:21 AM, Matthew Kaufman (SKYPE) wrote: > I find the below statement strange, as there is a process for publishing requirements documents within the W3C, and this isn't it. > > Matthew Kaufman > > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Harald Alvestrand > Sent: Wednesday, January 30, 2013 2:11 AM > To: rtcweb@ietf.org > Subject: Re: [rtcweb] WG Last Call: draft-ietf-rtcweb-use-cases-and-requirements-10 > > ... > I know that you know this, but just so everyone else remembers: The requirements document is a requirements document for both the RTCWEB and the WEBRTC work. So some requirements are addressed only in WEBRTC, others in RTCWEB. > ... > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From emil@sip-communicator.org Wed Jan 30 08:57:42 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71D1A21F871D for ; Wed, 30 Jan 2013 08:57:42 -0800 (PST) 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 cLBTwFvvvadF for ; Wed, 30 Jan 2013 08:57:41 -0800 (PST) Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) by ietfa.amsl.com (Postfix) with ESMTP id 7F32F21F8722 for ; Wed, 30 Jan 2013 08:57:41 -0800 (PST) Received: by mail-wi0-f176.google.com with SMTP id hm14so2809534wib.9 for ; Wed, 30 Jan 2013 08:57:40 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=GqxxgnpcYxbVruc7fJgJqXkNG5el0j5HWYSIsUwGD0k=; b=aFMH4N3khzbDRuyeB933W2hW3GYzEqCm/LP6lon9fMFCqEKKVlD7jHfNn8/FeZBtdM YeQ5QGg9k7pYfeCuPi93bR0MXzgHo6Dpc9AWtHaYvcUjOBkmX3v8MZvUqPWRq05qmmF7 ZlcS84GO8ydarDhlae/sp9aP+3C/PkSvl7FtpuL6whJRHnAvodEVPEmC6VjoQ9IpgqbQ YSeO98w0yeV0KmkjepB/CG3lzjHx66NKOJs67e5LSd9q1xczHsrCbz4wykweBFcpi2wd prJe3IKXxmtUvT0gvcYnkhX1qU9kM3S0OxXwbBfCyy/2EK7Phk8IO70hci+ncr/xcf/z WNOw== X-Received: by 10.180.101.104 with SMTP id ff8mr10216915wib.11.1359565060276; Wed, 30 Jan 2013 08:57:40 -0800 (PST) Received: from camionet.local (shm67-5-88-165-90-188.fbx.proxad.net. [88.165.90.188]) by mx.google.com with ESMTPS id q13sm10080764wie.0.2013.01.30.08.57.38 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 30 Jan 2013 08:57:39 -0800 (PST) Message-ID: <51095101.3030903@jitsi.org> Date: Wed, 30 Jan 2013 17:57:37 +0100 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: rtcweb@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQm8grm3veaCToQgdyZRpA2X0pssN2SysIKaOF1y0WzONyA8nlHKRcZ+iMbYlbepKpnVcWRf Subject: Re: [rtcweb] [MMUSIC] Start of a reading list for the IETF MMUSIC/RTCWEB interim X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 30 Jan 2013 16:57:42 -0000 Hello all, On 25.01.13, 17:47, Ted Hardie wrote: > http://tools.ietf.org/html/draft-ietf-mmusic-sdp-bundle-negotiation > http://tools.ietf.org/html/draft-alvestrand-mmusic-msid > http://tools.ietf.org/html/draft-holmberg-mmusic-sdp-mmt-negotiation > http://tools.ietf.org/html/draft-ietf-mmusic-sctp-sdp > http://tools.ietf.org/html/draft-rescorla-mmusic-ice-trickle Just a quick note to let you know that the trickle ICE draft has been updated as per the discussions in Atlanta's MMUSIC session. A new draft describing trickle ICE's usage with SIP has also been submitted: http://www.ietf.org/mail-archive/web/mmusic/current/msg10169.html Cheers, Emil -- https://jitsi.org From eckelcu@cisco.com Wed Jan 30 09:30:13 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C21FF21F888B for ; Wed, 30 Jan 2013 09:30:13 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 87ezNyGgEozA for ; Wed, 30 Jan 2013 09:30:11 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id F0C0A21F889C for ; Wed, 30 Jan 2013 09:30:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6885; q=dns/txt; s=iport; t=1359567011; x=1360776611; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=T0w2eL2Uqf9WdFwbxHVwieFnW8+vVb8fNYGodpoyRMg=; b=P7kuTOXsuybVOINz5GThnsUWXMPOD/cAC43OhYWz1aa4q65VOdLmoK7A AZMAKgWOYC5G5ajSL20d/WvET0oCmg/ZRtNnRKkyvVAgCnK3WUhI6Pr8L KcnjMykGrN0CKlwFCsQrgTQswvUllOTAJA1P5lnxk9UBBDjYxk5fTEZ6v c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFABVYCVGtJV2d/2dsb2JhbAA7Cr8OFnOCHgEBAQMBAQEBNy4GCQ4EAgEIEQQBAQsUCQcnCxQIAQgCBAESCBOHcAUBDMILBIYuhmkEgxBhA5Jak36Cd4FmPg X-IronPort-AV: E=Sophos;i="4.84,569,1355097600"; d="scan'208";a="170599977" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-5.cisco.com with ESMTP; 30 Jan 2013 17:30:10 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r0UHUAJn011664 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 30 Jan 2013 17:30:10 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.107]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.004; Wed, 30 Jan 2013 11:30:10 -0600 From: "Charles Eckel (eckelcu)" To: "Ejzak, Richard P (Richard)" , "rtcweb@ietf.org" Thread-Topic: [rtcweb] FW: New Version Notification for draft-reddy-rtcweb-mobile-00.txt Thread-Index: AQHN+bwJqPh8ieT7eka/zkcS4JfAPZhiKGxg Date: Wed, 30 Jan 2013 17:30:09 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C088280476278A@xmb-aln-x08.cisco.com> References: <913383AAA69FF945B8F946018B75898A148E07CB@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A148E8567@xmb-rcd-x10.cisco.com> <03FBA798AC24E3498B74F47FD082A92F36EA12C6@US70UWXCHMBA04.zam.alcatel-lucent.com> In-Reply-To: <03FBA798AC24E3498B74F47FD082A92F36EA12C6@US70UWXCHMBA04.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.68.16.69] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [rtcweb] FW: New Version Notification for draft-reddy-rtcweb-mobile-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: Wed, 30 Jan 2013 17:30:13 -0000 Sorry for the delay in responding on this thread. Please see comments inlin= e. > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > Behalf Of Ejzak, Richard P (Richard) > Sent: Wednesday, January 23, 2013 2:50 PM > To: rtcweb@ietf.org > Subject: Re: [rtcweb] FW: New Version Notification for draft-reddy-rtcweb= - > mobile-00.txt >=20 > I have various comments on section 4 of draft-reddy-rtcweb-mobile. >=20 > First of all, thanks for this draft as it highlights some issues that wil= l be very > important in deployment of WebRTC in LTE and related mobile networks. I > will comment on section 4.2 out of order to avoid forward references in t= he > comments. >=20 > 4.2: This section makes the assertion that only UE initiated bearer > modification procedures are available to a "public WebRTC server". While > this is an option in the specification (not necessarily always used), the= re is > also a network API available for the public WebRTC server to be able (if > allowed by the mobile network provider) to request QoS for specific flows= . > There is a Parlay X API for QoS and also plans to develop a RESTful API. >=20 > 4.1 RTP session multiplexing: >=20 > This section is very pessimistic about the ability to assign different be= arers > to multiplexed flows. I think that solutions do exist, which I describe b= elow. >=20 > First, I find the discussion of DSCP markings in the text to be confusing= , but I > think this is because the text assumes that there is no coordination > between the network and the WebRTC application with regard to DSCP > markings. While this is strictly true when using UE initiated bearer > modification procedures, the situation is a bit more nuanced. >=20 > I will discuss handling of the uplink and downlink flows separately. >=20 > There should be no problem for either a UE or network initiated bearer > modification procedure to specify uplink TFTs including five-tuple and TO= S > (DSCP). There is no reason to apply network policy to the selection of DS= CP > values in the uplink TFTs since they will just be remapped in the network > anyway. Uplink packets with the corresponding marking will be assigned to > the desired bearer for transport over the radio. This assumes that the > markings survive transit from the browser to the modem, which should not > be a problem within a device or small network. This also assumes that the= re > is no blocking at intermediate queues between the browser and the > modem, which might occur, e.g., if different priority flows share a queue= for > a five-tuple. A proper design will avoid this potential problem. The netw= ork > will remark the uplink packets according to policy before forwarding them > into the backbone to the remote peer, so the design cannot depend on the > markings surviving transit throu > gh the network. In general, priority treatment on the radio is much more > important than priority treatment in the backbone. >=20 > Without some additional effort, this approach will fail in the downlink s= ince > it is not possible to know how the packets transiting through the network > will be marked. The packets can be remarked at any point on the path from > their source, so even knowledge of access network marking policies will n= ot > help without additional procedures. >=20 > There are two possible solutions to this problem, and both require that > some mechanism is available to identify the packets belonging to any one > flow so that they can be passed to the correct bearer for handling. > Fortunately, rtcweb requires that the SSRC(s) for each flow be explicitly > signaled in the SDP, thus providing a way of identifying each flow (i.e., > filtering on five-tuple and SSRC value). >=20 > The two options for using SSRC to direct each downlink flow to the correc= t > bearer are: 1) insert a gateway node within the access network with the > explicit purpose of identifying each downlink flow and remarking the > packets to match the DSCP value specified in the corresponding downlink > TFT; or 2) extend the TFT filtering mechanism to also support matching on > SSRC values. >=20 > Option 1) requires that the rtcweb application coordinate the markings wi= th > the network to ensure that the downlink markings conform to network > policy. This will require some interaction between the rtcweb application > and the mobile network, potentially using the network initiated bearer > modification procedure. Note that the downlink markings can be defined by > network policy and the uplink markings can be defined by rtcweb/browser > policy, which can be different. >=20 > Option 2) requires a modification to the 3GPP specifications to extend th= e > TFT mechanism but is certainly the technically preferred solution since i= t > eliminates the need to be aware of network marking policies and > eliminates the need to insert a gateway just for the purpose of remarking > packets. Note also that when this extension is available, the uplink TFTs= can > be based on SSRC as well to eliminate any dependence on packet markings. >=20 > Thus there are two workable solutions to providing QoS treatment to > multiplexed media flows, one available with existing specifications and o= ne > requiring some small 3GPP spec enhancements. The only requirement > relevant to rtcweb is that the SSRC values used for different media flows > must be explicitly signaled in SDP so that they are available to identify= each > flow. I don't think this is a realistic requirement. It may be feasible in some c= ases, but it won't work well in others, such as large switched conferences.= I recall this subject being discussed in previous meetings. Fortunately I = do not find such a requirement in the requirements draft. Setting that aside, we have media types beyond audio and video for which SS= RC are not applicable. I suppose you could assume some default treatment fo= r such media types, but that is pretty limited. =20 Cheers, Charles >=20 > 4.3, first bullet: What is the practical implication, if any, of delaying= the > interaction with the PCRF until the 2nd offer/answer? >=20 > 4.3, second bullet: There should probably be a definition of "WebRTC > server" in the document. It's not clear from the text why this and no oth= er > entity must have an "Rx" like interface to a PCRF. It's also not clear w= hy the > interface is "Rx" like and not Rx. There is no question that some entity= on > the signaling path needs to interact directly or indirectly with the PCRF= . >=20 > Richard >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From harald@alvestrand.no Wed Jan 30 09:34:01 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A40D721F8702 for ; Wed, 30 Jan 2013 09:34:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.524 X-Spam-Level: X-Spam-Status: No, score=-110.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 Orzb65YY2Dkf for ; Wed, 30 Jan 2013 09:34:01 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 0F46121F8700 for ; Wed, 30 Jan 2013 09:34:01 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id EBDEB39E197; Wed, 30 Jan 2013 18:33:58 +0100 (CET) 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 EVQkcgbY5H0E; Wed, 30 Jan 2013 18:33:58 +0100 (CET) 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 F18DF39E125; Wed, 30 Jan 2013 18:33:57 +0100 (CET) Message-ID: <51095985.2010702@alvestrand.no> Date: Wed, 30 Jan 2013 18:33:57 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Mary Barnes References: <50F97303.4070906@ericsson.com> <5108F1B9.9020709@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] WG Last Call: draft-ietf-rtcweb-use-cases-and-requirements-10 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 30 Jan 2013 17:34:01 -0000 On 01/30/2013 05:32 PM, Mary Barnes wrote: > I agree with Matthew. The RTCWEB solution documents should be able to > satisfy all the requirements defined in an RTCWEB requirements > document (or there needs to be a clear explanation as to why a > specific requirement isn't satisfied). I would suggest to at least > put the W3C requirements in an appendix. The split between "F" requirements and "A" requirements was intended for that purpose. I see it's not very well explained in the text (to put it mildly). -overview- has more text about the relationship between those two parts; luckily, this is in Last Call at the same time, so if that text is not sufficient, it's a good time to fix it. > > Mary. > > On Wed, Jan 30, 2013 at 10:21 AM, Matthew Kaufman (SKYPE) > wrote: >> I find the below statement strange, as there is a process for publishing requirements documents within the W3C, and this isn't it. >> >> Matthew Kaufman >> >> -----Original Message----- >> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Harald Alvestrand >> Sent: Wednesday, January 30, 2013 2:11 AM >> To: rtcweb@ietf.org >> Subject: Re: [rtcweb] WG Last Call: draft-ietf-rtcweb-use-cases-and-requirements-10 >> >> ... >> I know that you know this, but just so everyone else remembers: The requirements document is a requirements document for both the RTCWEB and the WEBRTC work. So some requirements are addressed only in WEBRTC, others in RTCWEB. >> ... >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb From bernard_aboba@hotmail.com Wed Jan 30 11:30:24 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D07F521F888E for ; Wed, 30 Jan 2013 11:30:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.292 X-Spam-Level: X-Spam-Status: No, score=-102.292 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 QOQhMKn4ZOVL for ; Wed, 30 Jan 2013 11:30:24 -0800 (PST) Received: from blu0-omc3-s30.blu0.hotmail.com (blu0-omc3-s30.blu0.hotmail.com [65.55.116.105]) by ietfa.amsl.com (Postfix) with ESMTP id 006E821F886C for ; Wed, 30 Jan 2013 11:30:23 -0800 (PST) Received: from BLU002-W124 ([65.55.116.72]) by blu0-omc3-s30.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 30 Jan 2013 11:30:23 -0800 X-EIP: [cK5W8K5Cp7YPf1iBk3y60jrE1LiOgWM0] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_de0a5f5b-f200-42f9-9f23-b65818c897d4_" From: Bernard Aboba To: =?iso-8859-1?B?U3RlZmFuIEjla2Fuc3NvbiBMSw==?= , "rtcweb@ietf.org" Date: Wed, 30 Jan 2013 11:30:22 -0800 Importance: Normal In-Reply-To: <510927C4.60808@ericsson.com> References: <50F97303.4070906@ericsson.com>, , , , <510927C4.60808@ericsson.com> MIME-Version: 1.0 X-OriginalArrivalTime: 30 Jan 2013 19:30:23.0685 (UTC) FILETIME=[3FBAB750:01CDFF20] Subject: Re: [rtcweb] Review of draft-ietf-rtcweb-use-cases-and-requirements-10 (Part I) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 30 Jan 2013 19:30:24 -0000 --_de0a5f5b-f200-42f9-9f23-b65818c897d4_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > To me it means that the browser should not congest the network (and this= =20 > is regardless of what the possibly malicious app does). [BA] Today we have three potential approaches that might be relevant to th= is general concern: a. Consent. If a receiver is being inundated=2C they can refuse to respons= e to ICE keepalives=2C thereby causing a compliant sender to stop sending.= =20 b. Circuit breakers. As I understood it=2C the goal of this document was t= o prevent congestive collapse in a number of situations. However=2C circu= it breakers aren't a complete solution to congestion control=2C so the resu= lting behavior might not be considered "fair" and also it wasn't clear to m= e that high packet loss/low throughput would be avoided in all situations.= =20 c. Congestion control (RMCAT). This is a solution to the congestion contro= l problem=2C not just DDOS or worst-case congestive collapse. Since it cov= ers more ground it is more of a long-term solution than a or b.=20 I would like the requirement to be a bit more specific so that we can be cl= ear which of a=2C b and/or c address the concern. Solution a is more of a= response to DDOS issues than congestion control per se. Solution b is de= signed to address some worst case outcomes=2C though not necessarily all of= them. Solution c is the long-term solution=2C but it may not be availabl= e within the same time frame as a or b. =20 > > Please note that the requirements specified in this document are to > > be used in evaluating... protocol submissions. As such=2C the > > requirements language refers to capabilities of these protocols=3B = the > > protocol documents will specify whether these features are required= =2C > > recommended=2C or optional. For example=2C requiring that a protoc= ol > > support confidentiality is NOT the same thing as requiring that all > > protocol traffic be encrypted. >=20 > This makes a lot of sense. [BA] Feel free to tweak the wording above to the needs of RTCWEB. IETF Req= uirements documents are often used for different purposes=2C so one size do= esn't necessarily fit all. For example=2C the RFC 2989 language above was = created to provide guidelines for selection between competing protocol prop= osals. In that particular situation=2C meeting more requirements was "bett= er" but it wasn't necessarily expected that the "winner" would meet all req= uirements. Other WGs have created requirements documents to guide protocol= development and enable identification of missing work. In those situation= s=2C it isn't necessarily expected that an initial document set will cover = all the bases=2C though there may be an expectation that major holes will g= et covered somehow at some point.=20 = --_de0a5f5b-f200-42f9-9f23-b65818c897d4_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
>=3B To me it means that the b= rowser should not congest the network (and this
>=3B is regardle= ss of what the possibly malicious app does).

[BA] =3B Today we h= ave three potential approaches that might be relevant to this general conce= rn:

a. Consent. =3B If a receiver is being inundated=2C they can= refuse to response to ICE keepalives=2C thereby causing a compliant sender= to stop sending.
b. Circuit breakers. =3B As I understood it=2C th= e goal of this document was to prevent congestive collapse in a number of s= ituations. =3B =3B However=2C circuit breakers aren't a complete so= lution to congestion control=2C so the resulting behavior might not be cons= idered "fair" and also it wasn't clear to me that high packet loss/low thro= ughput would be avoided in all situations.
c. Congestion control (RMCAT= ). =3B This is a solution to the congestion control problem=2C not just= DDOS or worst-case congestive collapse. =3B Since it covers more groun= d it is more of a long-term solution than a or b.

I would like the = requirement to be a bit more specific so that we can be clear which of a=2C= b and/or c address the concern. =3B =3B Solution a is more of a re= sponse to DDOS issues than congestion control per se. =3B =3B Solut= ion b is designed to address some worst case outcomes=2C though not necessa= rily all of them. =3B =3B Solution c is the long-term solution=2C b= ut it may not be available within the same time frame as a or b. =3B
>=3B >=3B Please note that the requirements specified in this= document are to
>=3B >=3B be used in evaluating... protocol sub= missions. As such=2C the
>=3B >=3B requirements language refers= to capabilities of these protocols=3B the
>=3B >=3B protocol do= cuments will specify whether these features are required=2C
>=3B >= =3B recommended=2C or optional. For example=2C requiring that a protoc= ol
>=3B >=3B support confidentiality is NOT the same thing as re= quiring that all
>=3B >=3B protocol traffic be encrypted.
>= =3B
>=3B This makes a lot of sense.

[BA] Feel free to tweak th= e wording above to the needs of RTCWEB. =3B IETF Requirements documents= are often used for different purposes=2C so one size doesn't necessarily f= it all. =3B For example=2C the RFC 2989 language above was created to p= rovide guidelines for selection between competing protocol proposals. = =3B In that particular situation=2C meeting more requirements was "better" = but it wasn't necessarily expected that the "winner" would meet all require= ments. =3B Other WGs have created requirements documents to guide proto= col development and enable identification of missing work. =3B In those= situations=2C it isn't necessarily expected that an initial document set w= ill cover all the bases=2C though there may be an expectation that major ho= les will get covered somehow at some point.
= --_de0a5f5b-f200-42f9-9f23-b65818c897d4_-- From bernard_aboba@hotmail.com Wed Jan 30 12:02:37 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E32221F8689 for ; Wed, 30 Jan 2013 12:02:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.292 X-Spam-Level: X-Spam-Status: No, score=-102.292 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 hzZcYivLN0K8 for ; Wed, 30 Jan 2013 12:02:36 -0800 (PST) Received: from blu0-omc3-s19.blu0.hotmail.com (blu0-omc3-s19.blu0.hotmail.com [65.55.116.94]) by ietfa.amsl.com (Postfix) with ESMTP id 021F121F8230 for ; Wed, 30 Jan 2013 12:02:35 -0800 (PST) Received: from BLU002-W123 ([65.55.116.73]) by blu0-omc3-s19.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 30 Jan 2013 12:02:35 -0800 X-EIP: [B7EVT5yjx5LjUqBPcNFnk9Wi2V9GDyM9] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_9428edd1-56a2-450b-a432-abbcbb2ed417_" From: Bernard Aboba To: =?iso-8859-1?B?U3RlZmFuIEjla2Fuc3NvbiBMSw==?= , "rtcweb@ietf.org" Date: Wed, 30 Jan 2013 12:02:35 -0800 Importance: Normal In-Reply-To: <5109265F.6040106@ericsson.com> References: <50F97303.4070906@ericsson.com>, , , , , , , <5109265F.6040106@ericsson.com> MIME-Version: 1.0 X-OriginalArrivalTime: 30 Jan 2013 20:02:35.0540 (UTC) FILETIME=[BF346540:01CDFF24] Subject: Re: [rtcweb] Review of draft-ietf-rtcweb-use-cases-and-requirements-10 (Part II) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 30 Jan 2013 20:02:37 -0000 --_9428edd1-56a2-450b-a432-abbcbb2ed417_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > > [BA] Can I assume that the use of the plural implies a requirement to b= e able to support multiple sources? >=20 > Yes. And in the use-case "Hockey Game Viewer" multiple cameras are used. [BA] OK. General question: is this something that needs to be supported i= n v1.0 (e.g. we need to figure out how multiple source negotiation works im= mediately) or can it wait until later? For me=2C that question is helpful = in distinguishing MUSTs (things we need to have to either provide basic cap= abilities=2C avoid damage to the Internet=2C or attain interoperability) fr= om lesser levels like SHOULD (things it would be very useful to have=2C but= perhaps are not needed immediately).=20 > > [BA] I am not sure what this means. Is it implying the need for a stra= tegy to deal with loss in the MTI codec? > > For example=2C is this implying a requirement for codec adaption=2C > > or FEC or re-transmission? I don't see the purpose of letting the TBD = remain here. >=20 > The TBD could go=3B my interpretation is that at the very least there sho= uld be some PLC implemented. [BA] OK. It might be helpful to be a bit more specific about what might ad= dress this requirement=2C assuming we can come to agreement on it.=20 > > [BA] What does "graceful" mean?? Is this referring to the resilience of= the codec and > > loss-strategy (see above)=2C or to enabling the application to adapt to= loss? >=20 > I agree. This is very vague. I think that what was in mind at the time=20 > was that the browser should not be worse than existing native clients=20 > during bad network conditions (e.g. strange high level audio sounds that= =20 > comes from decoding erroneous data should not be played). I think this=20 > req could go. [BA] I think that this requirement is probably covered adequately by other = ones so it can be omitted.=20 > > [BA] I really am not sure what is meant here. Are we talking about the= ability of a sender to change > > transmission rate quickly (e.g. removing a layer in SVC)? Or about add= ing/removing a stream? >=20 > This requirement is derived from the "Video conferencing system with=20 > central server" use-case. The intention was to say something like "if=20 > the central node asks for an intraframe=2C the browser should insert it". > > [BA] Synchronization is not necessarily possible or even desirable in a= ll circumstances. > > For example=2C if the video experiences substantial loss=2C do you real= ly want to delay the audio to sync > > with it? So I can understand why it is desirable to support the capabil= ity=2C but is this > > really a MUST? I would not bother to attempt to answer the question=3B= delete it. >=20 > You're right: in some cases it is better to not synchronize. But I still= =20 > think the browser MUST support it (even if not used in certain cases). [BA] I agree with the "MUST support" formulation. > > ---------------------------------------------------------------- > > F18 The browser MUST be able to process and mix > > sound objects (media that is retrieved from > > another source than the established media > > stream(s) with the peer(s) with audio streams. > > > > [BA] If this is done=2C isn't it important to make clear to the user (a= nd perhaps the peer) what is happening? > > Confusing live and recorded media seems like a potential vector for mis= chief. >=20 > This is derived from the use-case "Multiparty on-line game with voice=20 > communication". Are you saying that the browser should inform the user=20 > that the "boom" sound comes from the explosion on the game scene=2C while= =20 > the voice comes from his friend that is playing the same game? I don't=20 > see that need. [BA] I agree that it is silly in a game scenario. But in an emergency call= =2C knowing that the video of a hostage situation isn't live would be prett= y important.=20 > > [BA] "Wiretapping" is too vague a phrase to be of much use. It might m= ake more sense to > > talk about security services that should be provided (e.g. confidential= ity of media). >=20 > This was discussed a bit=2C and someone (Harald?) pointed out that=20 > wiretapping is well defined and can be used. [BA] If we can refer to a definition this would be helpful in clarifying th= e requirement. > > ---------------------------------------------------------------- > > F26 It MUST be possible to move from one network > > interface to another one > > [BA] Are we talking about the ability of an application to control this= =2C or the ability of an application to react to it=2C or something else? >=20 > It is not split up between application=2C browser=2C STUN/TURN server=2C = it is=20 > just a requirement on that it should work. [BA] My question is whether existing ICE/STUN/TURN RFCs are sufficient or w= hether extensions such as ICE Mobility are required to meet this requiremen= t. > > ---------------------------------------------------------------- > > F35 The browser MUST enable verification=2C given > > the right circumstances and by use of other > > trusted communication=2C of that streams and > > data received have not been manipulated by > > any party. > > [BA] I do not see how such a verification is possible. >=20 > I was under the impression that DTLS allowed this. [BA] DTLS/SRTP can verify that there is no man-in-the-middle. But it doesn= 't address modification by an endpoint that is a media gateway. Also=2C t= here is the replay vs. live issue. =20 > > ---------------------------------------------------------------- > > F36 The browser MUST reject incoming media and > > data=2C either modified=2C created or injected=2C > > by any entity not trusted by the site. > > > > [BA] Do we really mean "trusted by the site" or "trusted by the browser= "? >=20 > I need to think a bit more about this one. [BA] While the security document advises the use of HTTPS for signaling=2C = it doesn't prohibit use of HTTP. Also=2C for media there probably will be = scenarios where the client is unauthenticated=2C even if the server is auth= enticated (e.g. DTLS/SRTP with asymmetric trust). My advice is to reformu= late this as a requirement for support of {media=2C signaling} authenticati= on/integrity protection=2C rather than use.=20 One last question=2C about A25: A25 It must be possible for the application to=0A= refrain from exposing the IP address [BA] I am assuming we are talking about exposing the originating IP address= of media=2C which can be addressed via TURN. =20 If so=2C this is more of a protocol than an API requirement. Since the ICE= candidates need to exposed in the API in order to allow them to be signaled=2C I am not sure how we can avoid exposi= ng those to the application. Similarly=2C the HTTP server can obtain the IP address used by the HTTP client. Even within= SIP=2C there are VIA headers and contact headers=2C so it is not easy to avoid disclosure of the IP address to every= one. So I think we need to be more clear=20 about what we are trying to avoid exposing=2C and to whom.=20 = --_9428edd1-56a2-450b-a432-abbcbb2ed417_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
>=3B >=3B [BA] Can I assume = that the use of the plural implies a requirement to be able to support mult= iple sources?
>=3B
>=3B Yes. And in the use-case "Hockey Ga= me Viewer" multiple cameras are used.

[BA] OK. =3B General quest= ion: =3B is this something that needs to be supported in v1.0 (e.g. we = need to figure out how multiple source negotiation works immediately) or ca= n it wait until later? =3B For me=2C that question is helpful in distin= guishing MUSTs (things we need to have to either provide basic capabilities= =2C avoid damage to the Internet=2C or attain interoperability) from lesser= levels like SHOULD (things it would be very useful to have=2C but perhaps = are not needed immediately).

>=3B >=3B [BA] I am not sure what = this means. Is it implying the need for a strategy to deal with loss in th= e MTI codec?
>=3B >=3B For example=2C is this implying a requirement= for codec adaption=2C
>=3B >=3B or FEC or re-transmission? I don't= see the purpose of letting the TBD remain here.
>=3B
>=3B The T= BD could go=3B my interpretation is that at the very least there should be = some PLC implemented.

[BA] OK. =3B It might be helpful to be a b= it more specific about what might address this requirement=2C assuming we c= an come to agreement on it.

>=3B >=3B [BA] What does "graceful"= mean?? Is this referring to the resilience of the codec and
>=3B >= =3B loss-strategy (see above)=2C or to enabling the application to adapt to= loss?
>=3B
>=3B I agree. This is very vague. I think that what = was in mind at the time
>=3B was that the browser should not be worse= than existing native clients
>=3B during bad network conditions (e.g= . strange high level audio sounds that
>=3B comes from decoding erron= eous data should not be played). I think this
>=3B req could go.
<= br>[BA] I think that this requirement is probably covered adequately by oth= er ones so it can be omitted.

>=3B >=3B [BA] I really am not su= re what is meant here. Are we talking about the ability of a sender to cha= nge
>=3B >=3B transmission rate quickly (e.g. removing a layer in SV= C)? Or about adding/removing a stream?
>=3B
>=3B This requireme= nt is derived from the "Video conferencing system with
>=3B central s= erver" use-case. The intention was to say something like "if
>=3B the= central node asks for an intraframe=2C the browser should insert it".
<= br>>=3B >=3B [BA] Synchronization is not necessarily possible or even d= esirable in all circumstances.
>=3B >=3B For example=2C if the video= experiences substantial loss=2C do you really want to delay the audio to s= ync
>=3B >=3B with it? So I can understand why it is desirable to su= pport the capability=2C but is this
>=3B >=3B really a MUST? I woul= d not bother to attempt to answer the question=3B delete it.
>=3B
= >=3B You're right: in some cases it is better to not synchronize. But I s= till
>=3B think the browser MUST support it (even if not used in cert= ain cases).

[BA] I agree with the "MUST support" formulation.
>=3B >=3B --------------------------------------------------------= --------
>=3B >=3B F18 The browser MUST be able to p= rocess and mix
>=3B >=3B sound objects (media th= at is retrieved from
>=3B >=3B another source th= an the established media
>=3B >=3B stream(s) wit= h the peer(s) with audio streams.
>=3B >=3B
>=3B >=3B [BA] If= this is done=2C isn't it important to make clear to the user (and perhaps = the peer) what is happening?
>=3B >=3B Confusing live and recorded m= edia seems like a potential vector for mischief.
>=3B
>=3B This = is derived from the use-case "Multiparty on-line game with voice
>=3B= communication". Are you saying that the browser should inform the user >=3B that the "boom" sound comes from the explosion on the game scene=2C= while
>=3B the voice comes from his friend that is playing the same = game? I don't
>=3B see that need.

[BA] I agree that it is sill= y in a game scenario. =3B But in an emergency call=2C knowing that the = video of a hostage situation isn't live would be pretty important.

= >=3B >=3B [BA] "Wiretapping" is too vague a phrase to be of much use. = It might make more sense to
>=3B >=3B talk about security services t= hat should be provided (e.g. confidentiality of media).
>=3B
>= =3B This was discussed a bit=2C and someone (Harald?) pointed out that
= >=3B wiretapping is well defined and can be used.

[BA] If we can r= efer to a definition this would be helpful in clarifying the requirement.
>=3B >=3B ---------------------------------------------------= -------------
>=3B >=3B F26 It MUST be possible to m= ove from one network
>=3B >=3B interface to anot= her one
>=3B >=3B [BA] Are we talking about the ability of an applic= ation to control this=2C or the ability of an application to react to it=2C= or something else?
>=3B
>=3B It is not split up between applica= tion=2C browser=2C STUN/TURN server=2C it is
>=3B just a requirement = on that it should work.

[BA] My question is whether existing ICE/STU= N/TURN RFCs are sufficient or whether extensions such as ICE Mobility are r= equired to meet this requirement.

>=3B >=3B ----------------= ------------------------------------------------
>=3B >=3B F35 = The browser MUST enable verification=2C given
>=3B >=3B = the right circumstances and by use of other
>=3B &g= t=3B trusted communication=2C of that streams and
&= gt=3B >=3B data received have not been manipulated by=
>=3B >=3B any party.
>=3B >=3B [BA] I do= not see how such a verification is possible.
>=3B
>=3B I was un= der the impression that DTLS allowed this.

[BA] DTLS/SRTP can verify= that there is no man-in-the-middle. =3B But it doesn't address modific= ation by an endpoint that is a media gateway.  =3B Also=2C there is the= replay vs. live issue. =3B

>=3B >=3B -------------------= ---------------------------------------------
>=3B >=3B F36 = The browser MUST reject incoming media and
>=3B >=3B = data=2C either modified=2C created or injected=2C
>=3B &g= t=3B by any entity not trusted by the site.
>=3B &= gt=3B
>=3B >=3B [BA] Do we really mean "trusted by the site" or "tru= sted by the browser"?
>=3B
>=3B I need to think a bit more about= this one.

[BA] While the security document advises the use of HTTPS= for signaling=2C it doesn't prohibit use of HTTP. =3B Also=2C for medi= a there probably will be scenarios where the client is unauthenticated=2C e= ven if the server is authenticated (e.g. DTLS/SRTP with asymmetric trust).&= nbsp=3B =3B My advice is to reformulate this as a requirement for suppo= rt of {media=2C signaling} authentication/integrity protection=2C rather th= an use.

One last question=2C about A25:

   A25             It must be possible for the application to=0A=
                   refrain from exposing the IP address

[BA] I am as=
suming we are talking about exposing the originating IP address of media=2C=
 which can be addressed via TURN.  
If so=2C this is more of a protocol =
than an API requirement.  Since the ICE candidates need to exposed in the A=
PI in
order to allow them to be signaled=2C I am not sure how we can avo=
id exposing those to the application.  Similarly=2C the
HTTP server can =
obtain the IP address used by the HTTP client.  Even within SIP=2C there ar=
e VIA headers and contact
headers=2C so it is not easy to avoid disclosu=
re of the IP address to everyone.  So I think we need to be more clear 
=
about what we are trying to avoid exposing=2C and to whom.

= --_9428edd1-56a2-450b-a432-abbcbb2ed417_-- From richard.ejzak@alcatel-lucent.com Wed Jan 30 12:34:15 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03F2721F8871 for ; Wed, 30 Jan 2013 12:34:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.249 X-Spam-Level: X-Spam-Status: No, score=-8.249 tagged_above=-999 required=5 tests=[AWL=-2.000, 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 coJithjhVyLI for ; Wed, 30 Jan 2013 12:34:14 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [62.23.212.56]) by ietfa.amsl.com (Postfix) with ESMTP id 7ED2A21F886C for ; Wed, 30 Jan 2013 12:34:12 -0800 (PST) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r0UKXuDV018381 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 30 Jan 2013 21:34:05 +0100 Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (135.5.2.35) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (135.120.45.63) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 30 Jan 2013 21:33:58 +0100 Received: from US70UWXCHMBA04.zam.alcatel-lucent.com ([169.254.12.105]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.02.0247.003; Wed, 30 Jan 2013 15:33:56 -0500 From: "Ejzak, Richard P (Richard)" To: "Charles Eckel (eckelcu)" , "rtcweb@ietf.org" Thread-Topic: [rtcweb] FW: New Version Notification for draft-reddy-rtcweb-mobile-00.txt Thread-Index: AQHN+bwNhpL+DUgDYE6jnyalY8WXyphif0CA//+twLA= Date: Wed, 30 Jan 2013 20:33:55 +0000 Message-ID: <03FBA798AC24E3498B74F47FD082A92F36EA3916@US70UWXCHMBA04.zam.alcatel-lucent.com> References: <913383AAA69FF945B8F946018B75898A148E07CB@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A148E8567@xmb-rcd-x10.cisco.com> <03FBA798AC24E3498B74F47FD082A92F36EA12C6@US70UWXCHMBA04.zam.alcatel-lucent.com> <92B7E61ADAC1BB4F941F943788C088280476278A@xmb-aln-x08.cisco.com> In-Reply-To: <92B7E61ADAC1BB4F941F943788C088280476278A@xmb-aln-x08.cisco.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.83 Subject: Re: [rtcweb] FW: New Version Notification for draft-reddy-rtcweb-mobile-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: Wed, 30 Jan 2013 20:34:15 -0000 > From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > > Behalf Of Ejzak, Richard P (Richard) > > > > Thus there are two workable solutions to providing QoS treatment to > > multiplexed media flows, one available with existing specifications and > one > > requiring some small 3GPP spec enhancements. The only requirement > > relevant to rtcweb is that the SSRC values used for different media > flows > > must be explicitly signaled in SDP so that they are available to > identify each > > flow. >=20 > I don't think this is a realistic requirement. It may be feasible in some > cases, but it won't work well in others, such as large switched > conferences. I recall this subject being discussed in previous meetings. > Fortunately I do not find such a requirement in the requirements draft. Well, at least in rtcweb with the explicit signaling of each MSID this requ= irement is satisfied. I have suggested a more general solution based on re= stricted SSRC assignment that I think could work quite well but this was no= t well received. =20 Do you have an alternative solution that does not require some means of sig= naling how to identify each flow? And why is it not feasible to add the op= tion to explicitly signal such additional information with an extra offer/a= nswer exchange WHEN necessary to assure proper QoS in the presence of media= multiplexing? =20 I doubt that it makes sense to use media multiplexing (bundle) for large sw= itched conferences anyway. If you need complete freedom to create new stre= ams at will then each (unbundled) media type should probably have its own f= ive-tuple and QoS treatment. This would not preclude the multiplexing of m= ultiple streams of the same media type within a five-tuple, where you get m= ost of the advantages of multiplexing in this case. But in the vast majori= ty of the cases, users will not have the need for this and could benefit fr= om the benefits of both media multiplexing and QoS. > Setting that aside, we have media types beyond audio and video for which > SSRC are not applicable. I suppose you could assume some default treatmen= t > for such media types, but that is pretty limited. >=20 > Cheers, > Charles With regard to other media types, only data channels are relevant in rtcweb= . I am not aware of a general solution to differentiating among data chann= els outside of the browser since all the SCTP frames are encrypted. The br= owser will bear the brunt of the responsibility for differentiating among t= he transmitted data channels within a five-tuple. For reasons already disc= ussed, DSCP is at best a partial solution (if even applicable to different = flows within an SCTP association, which I have not studied). As you say, t= he data channels will receive the same treatment in the network. And "defa= ult" treatment for the data channels can be defined on a five-tuple basis a= nd is not necessarily just "best effort", so this is not as limited as it m= ight seem. =20 In the case of other media transport options, we could potentially define y= et other filters based on other protocol fields, but clearly that would be = out of scope of rtcweb, and arguably much less important than audio and vid= eo, particularly since media multiplexing can be disabled for these flows i= f necessary to request special QoS treatment. I hope you are not suggesting that since there are difficulties in achievin= g a 100% general solution that attempts to solve the most important use cas= es should be abandoned? Thanks for your comments! Richard From martin.thomson@gmail.com Wed Jan 30 12:54:42 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 069B821F88A5 for ; Wed, 30 Jan 2013 12:54:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.649 X-Spam-Level: X-Spam-Status: No, score=-2.649 tagged_above=-999 required=5 tests=[AWL=0.350, BAYES_00=-2.599, J_CHICKENPOX_19=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 ljJiqCM5LQL5 for ; Wed, 30 Jan 2013 12:54:40 -0800 (PST) Received: from mail-wg0-f51.google.com (mail-wg0-f51.google.com [74.125.82.51]) by ietfa.amsl.com (Postfix) with ESMTP id 7DF6521F888B for ; Wed, 30 Jan 2013 12:54:38 -0800 (PST) Received: by mail-wg0-f51.google.com with SMTP id 8so1492073wgl.18 for ; Wed, 30 Jan 2013 12:54:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=uVWt71ovxkj4SBziMk2xaTxsS+DXVINnK5JLLbnEVi4=; b=fk1M6v8PA3yHshTsGbAmU+qKy6rbAaCnByq2iW5xBtTDP68554dJntBCcCH/gTIMgZ Laez3zHkaFq0ft5D3pzeWoyHDG8zTqMw1EXVBmqCodomKcvGhZ1nusFJexHREgKH2eo1 F2F8IpuShaPSUN+TWg/kcRaGsKVpP6XY5FZ5kjNvEXRwe+Q6ICO5X5WbxesTQ/2j4uNu Gro20VTvTv0wIHwotpJj2vXgmh4AeIcFIDVWuUZ49YfcLydxHYvQS+oI6Cvh1PevQdR5 pgXC9/DjAtDm/FjHs8wd1EMSElyqbAb1bgNud0TyCPjGLQJ3VQhsJfRpQISXgD/MToZF eDiw== MIME-Version: 1.0 X-Received: by 10.180.97.4 with SMTP id dw4mr11184831wib.16.1359579276859; Wed, 30 Jan 2013 12:54:36 -0800 (PST) Received: by 10.194.161.230 with HTTP; Wed, 30 Jan 2013 12:54:36 -0800 (PST) In-Reply-To: <5108F1B9.9020709@alvestrand.no> References: <50F97303.4070906@ericsson.com> <5108F1B9.9020709@alvestrand.no> Date: Thu, 31 Jan 2013 05:54:36 +0900 Message-ID: From: Martin Thomson To: Harald Alvestrand Content-Type: text/plain; charset=UTF-8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] WG Last Call: draft-ietf-rtcweb-use-cases-and-requirements-10 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 30 Jan 2013 20:54:42 -0000 On 30 January 2013 19:11, Harald Alvestrand wrote: > I'd prefer not to formally do this (Last Calls need to close), but the > normal procedure is that comments raised during Last Call are addressed > after the WG Last Call closes. If addressing comments cause major changes, a > new WG Last Call might be in order. In which case I would suggest that the last call be concluded with a decision not to send this document to the IESG. >> F13 The browser MUST be able to apply spatialization >> effects to audio streams. >> >> So...this is either pointless in the same vein as the requirement "the >> browser MUST be able to control the volume of audio" or it is not >> addressed. I see A13, but that's not happening. Given where we've >> directed effort, I am tempted to suggest that this be removed. > > > In the WEBRTC WG, we've assumed that this is satisfied by saying "audio can > be sent to the WebAudio API". Yeah, that doesn't connect with the text of the requirement in any meaningful fashion. I do prefer that requirements are testable. What test does the above text produce? >> F15 The browser MUST be able to change the level >> in audio streams. >> >> This is a problem for the same reason as above. AGC is one thing, but >> this is unspecific. Does this apply to inbound and outbound streams? >> Is this level control provided to the application or is this a >> pointless requirement on browser chrome? This also has implications >> for "tainted" streams, in which case I believe that even level control >> should be prevented. > > > I think you're wrong about tainting, but I wonder if this is trivially > satisfied by the fact that output elements have volume controls (and there's > always WebAudio as a backup). If that's the case, it's not clear why this even exists. BTW, with tainting, I'm concerned about the granularity of level control available to applications and mixing of tainted with untainted sources. >> >> F7 The browser MUST support fast stream switches. >> >> What does this mean? There are a number of factors that could be at play >> here: > > Not clear what you intend to say - does it need to be specified further, or > removed? Yes. > "Short" is not specified further, but in the common case of voice activated > switching, I think one assumes that you want to see the speaker before he's > finished his first word. Again, as long as it's testable. (Given reasonable assumptions about background knowledge, we don't need the full legalese version.) >> F37 The browser MUST be able to send streams and >> data to a peer in the presence of FWs that only >> allows http(s) traffic. >> >> This is a more specific version of F19, for which my same comment >> applies. I haven't seen any attempt to provide a solution. Can this >> be removed? > > TURN/TLS will satisfy this requirement. This is not always true :) >> F26 It MUST be possible to move from one network >> interface to another one >> >> For whom must this be possible? Certainly, the browser is able to >> make this choice, but the application has only limited ability to >> control this in the current application. I can imagine perhaps >> changing priority values on a=candidate lines based on some guessing >> about what interfaces are what, but I have a strong expectation that >> this would have zero effect in any ICE implementation. > > ICE restart satisfies this requirement for the "break before make" case. I know that this happens *in some cases*, but I did not read "break before make" anywhere. I happen to be using a device with multiple interfaces that can operate both in tandem quite happily. For those, it's possible to make before break. From martin.thomson@gmail.com Wed Jan 30 13:00:13 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2044221F8828 for ; Wed, 30 Jan 2013 13:00:13 -0800 (PST) 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 XSKPpvVujbwF for ; Wed, 30 Jan 2013 13:00:12 -0800 (PST) Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) by ietfa.amsl.com (Postfix) with ESMTP id ABED721F87E4 for ; Wed, 30 Jan 2013 13:00:11 -0800 (PST) Received: by mail-wi0-f176.google.com with SMTP id hm14so3057023wib.9 for ; Wed, 30 Jan 2013 13:00:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=832gD9PIkr9xTWQga+5D0SYDdmhQE8GRwkktZLd8eww=; b=EXvN/gZMaPhirQSqQ35AwxLg6Xsh48JW2DHLFOnRIqBUYHGvvicbfAaXWi0X33cOY8 Eo+i+N0sTYGeR7Vs+evIeVLm3e0TSct644s8oPML78h+q2fwuawQdyJdCfPDBTJHHiax CfSbpKL5HDJJygu6So9EwvlEvkyQ9K68Zx/QrNe7Pgdg9CUHXYoBplxWoevnUYkWeRHK VjmhKeovJ5962sVq/cspWC7HIYrvYxE6a0aCwtTeiwxluOsV+l0fL1CEQQU2CNoB7mVW cwYUpLBCsUszTQSotEDifjYWai5NFftsUyS8B0jaMUFY6vBXRyyAN42K62H10Q6cFBiZ pJcA== MIME-Version: 1.0 X-Received: by 10.180.97.4 with SMTP id dw4mr11203084wib.16.1359579609851; Wed, 30 Jan 2013 13:00:09 -0800 (PST) Received: by 10.194.161.230 with HTTP; Wed, 30 Jan 2013 13:00:09 -0800 (PST) In-Reply-To: <50F97303.4070906@ericsson.com> References: <50F97303.4070906@ericsson.com> Date: Thu, 31 Jan 2013 06:00:09 +0900 Message-ID: From: Martin Thomson To: Magnus Westerlund Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] WG Last Call: draft-ietf-rtcweb-use-cases-and-requirements-10 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 30 Jan 2013 21:00:13 -0000 Regarding requirements on the browser, which I think bears further discussi= on: Many requirements are stipulated as "The browser MUST be able to ..." There is a clear confusion about what these requirements actually mean from the perspective of where the controls to achieve the requirement exist. Some of these are assumed to surface UI such that a user can control browser behavior, others assume a form of autonomous action on the part of the browser, and yet others assume that controls are presented to the application. This needs to be clarified. On 19 January 2013 01:06, Magnus Westerlund wrote: > WG, > > I would here by like to announce a two week WG last call that ends on > the 1st of February. > > Document is available here: > > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-use-cases-and-requirem= ents/ > > Cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=C3=A4r=C3=B6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From gunnar.hellstrom@omnitor.se Wed Jan 30 13:15:52 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDADD21F8865 for ; Wed, 30 Jan 2013 13:15:52 -0800 (PST) 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, 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 Q0AnhXT69Ze4 for ; Wed, 30 Jan 2013 13:15:51 -0800 (PST) Received: from vsp-authed-01-02.binero.net (vsp-authed02.binero.net [195.74.38.226]) by ietfa.amsl.com (Postfix) with SMTP id 9830D21F8803 for ; Wed, 30 Jan 2013 13:15:49 -0800 (PST) Received: from smtp01.binero.se (unknown [195.74.38.28]) by vsp-authed-01-02.binero.net (Halon Mail Gateway) with ESMTP for ; Wed, 30 Jan 2013 22:15:07 +0100 (CET) Received: from [192.168.2.42] (h79n2fls31o933.telia.com [212.181.137.79]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-02-01.atm.binero.net (Postfix) with ESMTPA id E1EE33A293 for ; Wed, 30 Jan 2013 22:15:06 +0100 (CET) Message-ID: <51098D5A.4040009@omnitor.se> Date: Wed, 30 Jan 2013 22:15:06 +0100 From: Gunnar Hellstrom User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: rtcweb@ietf.org References: <50F97303.4070906@ericsson.com> <5102FE7E.5000109@omnitor.se> <51039976.1000600@alvestrand.no> In-Reply-To: <51039976.1000600@alvestrand.no> Content-Type: multipart/alternative; boundary="------------080708050109010406070208" Subject: Re: [rtcweb] WG Last Call: draft-ietf-rtcweb-use-cases-and-requirements-10 - real-time text X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 30 Jan 2013 21:15:53 -0000 This is a multi-part message in MIME format. --------------080708050109010406070208 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 2013-01-26 09:53, Harald Alvestrand wrote: > On 01/25/2013 10:51 PM, Gunnar Hellstrom wrote: >> On 2013-01-18 17:06, Magnus Westerlund wrote: >>> WG, >>> >>> I would here by like to announce a two week WG last call that ends on >>> the 1st of February. >>> >>> Document is available here: >>> >>> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-use-cases-and-requirements/ >>> >>> >> >> We had a good discussion in December on inclusion of the real-time >> text medium. >> >> It was decided to document three alternative implementations with >> pros and cons and after that decide which one to standardize together >> with the two already mentioned media in rtcweb. >> >> The three alternatives were: >> 1.) An RTP medium similar to audio and video, using RFC 4103 transport. >> >> 2.) A semi-reliable data channel with a standardized label. >> >> 3.) A web service based protocol, such as BOSH and XEP-0301 for >> real-time text in XMPP with a well specified integration with rtcweb >> in a common application. >> >> For all three cases, there is a need to have a specification for how >> calls with audio, video and real-time text are exchanged with SIP >> based environments, e.g. for interaction with RFC 6443 based >> emergency services. >> >> Text is a natural part of today's video and audio applications, so >> all use cases look quite meager without it. >> >> I suggest that we make a rapid mini-investigation on the real-time >> text alternatives and decide which variant to include in a use case. > > I disagree with this summary on two points: > > - I think it's broken to choose between implementation strategies in > an use case. The use case needs to specify the function that we want > to achieve. Yes, I totally agree, I did not mean to have the discussion on solution in the use case document. > > > - I don't recall a declaration by the chairs that text would be > included in the use cases for RTCWEB. I repeat my proposal to do so. This time with a shortened, generally expressed use case that is intended to allows any one of the three implementation alternatives to be selected. > > > My memory is flaky, so if you can find the declaration by the chairs, > I'm happy to let the last point pass. > Yes, I am on my way to do the last point as well. But timing requires the addition to the use cases to be handled now. Thus: Proposal for adding real-time text to the use cases, adjusted to be general and minimal: --------------------------Add real-time text in a general way in use case draft------------------------------------------- 4.2.15.Simple Total Conversation service 4.2.15.1.Description This use-case has the audio and video communication of the Simple Video Communication Service use-case (Section 4.2.1 ). In addition to this, the users can send and receive real-time text in the same call. While one user types in the real-time text area, it is nearly immediately presented to the other user. By providing these three media together, the Total Conversation service is provided. Interworking with SIP calls with the same media set, and with SIP based emergency services is also in scope of this use case. 4.2.15.2 <#section-4.3.1.2>. Derived Requirements F1, F2, F3, F4, F5, F6, F8, F9, F10, F20, F21, F39,F40, F41 A1, A2, A3, A4, A7, A8, A9, A10, A11, A12, A27 .............. F39 The browser MUST be able to handle text entry via applications to generate real-time text streams to be included in Total Conversation calls. Real-time text and Total Conversation Services are defined in ITU-T F.700 and F.703. ---------------------------------------------------------------- F40 The browser MUST be able to send real-time text streams to a peer. ---------------------------------------------------------------- F41 The browser MUST be able to receive, process and convey real-time text streams from peers to applications. ---------------------------------------------------------------- ..... A27 The Web API MUST provide a mechanisms for handling real-time text among the streams. ---------------------------------------------------------------- /Gunnar --------------080708050109010406070208 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 2013-01-26 09:53, Harald Alvestrand wrote:
On 01/25/2013 10:51 PM, Gunnar Hellstrom wrote:
On 2013-01-18 17:06, Magnus Westerlund wrote:
WG,

I would here by like to announce a two week WG last call that ends on
the 1st of February.

Document is available here:

https://datatracker.ietf.org/doc/draft-ietf-rtcweb-use-cases-and-requirements/


We had a good discussion in December on inclusion of the real-time text medium.

It was decided to document three alternative implementations with pros and cons and after that decide which one to standardize together with the two already mentioned media in rtcweb.

The three alternatives were:
1.) An RTP medium similar to audio and video, using RFC 4103 transport.

2.) A semi-reliable data channel with a standardized label.

3.) A web service based protocol, such as BOSH and XEP-0301 for real-time text in XMPP with a well specified integration with rtcweb in a common application.

For all three cases, there is a need to have a specification for how calls with audio, video and real-time text are exchanged with SIP based environments, e.g. for interaction with RFC 6443 based emergency services.

Text is a natural part of today's video and audio applications, so all use cases look quite meager without it.

 I suggest that we make a rapid mini-investigation on the real-time text alternatives and decide which variant to include in a use case.

I disagree with this summary on two points:

- I think it's broken to choose between implementation strategies in an use case. The use case needs to specify the function that we want to achieve.
Yes, I totally agree, I did not mean to have the discussion on solution in the use case document.


- I don't recall a declaration by the chairs that text would be included in the use cases for RTCWEB.
I repeat my proposal to do so. This time with a shortened, generally expressed use case that is intended to allows any one of the three implementation alternatives to be selected.


My memory is flaky, so if you can find the declaration by the chairs, I'm happy to let the last point pass.

Yes, I am on my way to do the last point as well. But timing requires the addition to the use cases to be handled now.


Thus: Proposal for adding real-time text to the use cases, adjusted to be general and minimal:

--------------------------Add real-time text in a general way in use case draft-------------------------------------------

4.2.15.  Simple Total Conversation service

4.2.15.1.  Description
 
 
   This use-case has the audio and video communication of the Simple
   Video Communication Service use-case (Section 4.2.1).
 
   In addition to this, the users can send and receive real-time text
   in the same call. While one user types in the real-time text area, it
   is nearly immediately presented to the other user.

   By providing these three media together, the Total Conversation
   service is provided.

   Interworking with SIP calls with the same media set, and with SIP
   based emergency services is also in scope of this use case. 
 
4.2.15.2.  Derived Requirements
 
   F1, F2, F3, F4, F5, F6, F8, F9, F10, F20, F21,
 
   F39,F40, F41
 
   A1, A2, A3, A4, A7, A8, A9, A10, A11, A12, A27
 
..............

   F39             The browser MUST be able to handle text entry
                   via applications to generate real-time 
                   text streams to be included in Total Conversation
                   calls. Real-time text and Total Conversation
                   Services are defined in ITU-T F.700 and F.703. 
   ----------------------------------------------------------------
   F40              The browser MUST be able to send real-time text 
                   streams to a peer.
 
   ----------------------------------------------------------------
   F41              The browser MUST be able to receive, process and
                    convey real-time text streams from peers to 
                    applications.
   ----------------------------------------------------------------
   
 

.....

   A27             The Web API MUST provide a mechanisms for  
                   handling real-time text among the streams. 
 ----------------------------------------------------------------


/Gunnar
--------------080708050109010406070208-- From bernard_aboba@hotmail.com Wed Jan 30 20:39:28 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C55BA21F8625 for ; Wed, 30 Jan 2013 20:39:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.442 X-Spam-Level: X-Spam-Status: No, score=-102.442 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=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 Qe-Q628wxkEa for ; Wed, 30 Jan 2013 20:39:28 -0800 (PST) Received: from blu0-omc3-s20.blu0.hotmail.com (blu0-omc3-s20.blu0.hotmail.com [65.55.116.95]) by ietfa.amsl.com (Postfix) with ESMTP id F24F421F85E8 for ; Wed, 30 Jan 2013 20:39:27 -0800 (PST) Received: from BLU002-W135 ([65.55.116.72]) by blu0-omc3-s20.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 30 Jan 2013 20:39:27 -0800 X-EIP: [AINpfFS6urFd2Nc2EKMyHJmRHx39NhnQ] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_658e6361-49c0-4fc5-9a77-a1fac38aedd8_" From: Bernard Aboba To: "rtcweb@ietf.org" Date: Wed, 30 Jan 2013 20:39:26 -0800 Importance: Normal In-Reply-To: <51094C89.7020302@jitsi.org> References: <20130128193921.20420.53308.idtracker@ietfa.amsl.com>, <51094C89.7020302@jitsi.org> MIME-Version: 1.0 X-OriginalArrivalTime: 31 Jan 2013 04:39:27.0149 (UTC) FILETIME=[F39065D0:01CDFF6C] Subject: Re: [rtcweb] Trickle ICE update and a new SIP usage 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: Thu, 31 Jan 2013 04:39:28 -0000 --_658e6361-49c0-4fc5-9a77-a1fac38aedd8_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > During the MMUSIC presentation and the mailing list discussions it was =0A= > also pointed out that it is important for this work to happen in =0A= > parallel with a SIP usage for trickle ICE. Enrico=2C Christer and I have =0A= > therefore submitted the following document: =0A= > =0A= > http://tools.ietf.org/html/draft-ivov-mmusic-trickle-ice-sip-00 =0A= > =0A= > As always=2C comments are welcome! =0A= =0A= Is my reading of the draft (see below) correct? =0A= =0A= 1. "half trickle" offers the possibility of backward compatibility=2C if=0A= the capabilities of the answerer aren't known and an RFC 5245 compliant=0A= offer is made=2C since the Recv-Info: trickle-ice header is included =0A= in the Offer per RFC 6086=2C as well as in a reliable 18x/2xx response. =20 =0A= =0A= 2. Section 3 suggests that the Offer in "half trickle" contains all =0A= candidates. The Answer presumably includes host candidates (including just= =0A= 0.0.0.0 would not make much sense) in the response. There seems to be no = need for the Offerer to send a "trickle-ice" =0A= Info-Package since it sent all the candidates in the initial Offer. =20 3. After the response is sent=2C then the Answerer starts the trickling via= the "trickle-ice" INFO packages. The Offerer knows to expect this since a= Recv-Info trickle-ice header was included in the response.=20 4. If a pair is selected that includes a candidate obtained from a "trickle= -ice" Info-Package=2C is a =0A= conventional RFC 5245 offer/answer exchange (not using INFO) required to co= nfirm it? =0A= = --_658e6361-49c0-4fc5-9a77-a1fac38aedd8_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
>=3B During the MMUSIC = presentation and the mailing list discussions it was
=0A= >=3B also pointed out that it is important for this work to happen in
= =0A= >=3B parallel with a SIP usage for trickle ICE. Enrico=2C Christer and I = have
=0A= >=3B therefore submitted the following document:
=0A= >=3B
=0A= >=3B http://tools.ietf.org/html/draft-ivov-mmusic-trickle-i= ce-sip-00
=0A= >=3B
=0A= >=3B As always=2C comments are welcome!
=0A=
=0A= Is my reading of the draft (see be= low) correct?
=0A=
=0A= 1. "half trickle" offe= rs the possibility of backward compatibility=2C if=0A= the capabilities of the answerer aren't known and an RFC 5245 compliant=0A= offer is made=2C since the Recv-Info: trickle-ice header is inclu= ded =0A= in the Offer per RFC 6086=2C as well as in a reliable 18x/2xx r= esponse.  =3B
=0A=
=0A= 2. Section 3 suggests that the Offer in "half trickle" contains all =0A= candidates. =3B The Answer presumably in= cludes host candidates (including just=0A= 0.0.0.0 would not make much sense) in the response. =3B There seems to be no need fo= r the Offerer to send a "trickle-ice" =0A= Info-Package since it sent all the candidates in the initial Offer. =3B=

3. After the = response is sent=2C then the Answerer starts the trickling via the "trickle-ic= e" INFO packages. =3B The= Offerer knows to expect this since a Recv-Info trickle-ice header was included in the response. =

4.<= /font> If a pair is selected = that includes a candidate obtained from a "trickle-ice" Info-Package=2C is = a =0A= conventional RFC 5245 offer/answer exchange (not using INFO) required to confirm it?
=0A=

= --_658e6361-49c0-4fc5-9a77-a1fac38aedd8_-- From emil@sip-communicator.org Wed Jan 30 20:52:06 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D59921F8415 for ; Wed, 30 Jan 2013 20:52:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.367 X-Spam-Level: X-Spam-Status: No, score=-2.367 tagged_above=-999 required=5 tests=[AWL=-1.233, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, J_CHICKENPOX_52=0.6, 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 3x-2mkkHGNbs for ; Wed, 30 Jan 2013 20:52:05 -0800 (PST) Received: from mail-wi0-x229.google.com (wi-in-x0229.1e100.net [IPv6:2a00:1450:400c:c05::229]) by ietfa.amsl.com (Postfix) with ESMTP id 42A1321F875F for ; Wed, 30 Jan 2013 20:52:04 -0800 (PST) Received: by mail-wi0-f169.google.com with SMTP id hq12so140887wib.4 for ; Wed, 30 Jan 2013 20:52:04 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received: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=Df6kLsaIpSE0BsBLHEzL77sJpdCverJ3xdj0QUL1ZpA=; b=XCD01pduo1d1Xq0zWQPjSAF97YbxfcwQTtMZK9VSKoxexS1dWkiWasnq/FJNwpQ1Om J+3mCnXmX46BPvEsyZk2VHzn07MICvezhXcz3AdbiVo5lHwJ3HGNJG8L/x75CcUdX2vu rtfAMMIs+9Rqy0dCzFM2gnGCAt169tNbliXmQndVnbBzdGgbg9R39TYJGU8kvnJUb+DU DmckZlYDBseJicJkE7+RkjUx+kmEIFo35vhWnfD4+vT6d1BlyAg4WImc2XxFZWDy5LlJ nOwehPU6YMQz0LihxXHN/seZCWzUi2HXBzqpSFasZdFWkcuN7oTWvcNyLyOXdrW+O7BF 5oXA== X-Received: by 10.194.76.165 with SMTP id l5mr12796994wjw.14.1359607923875; Wed, 30 Jan 2013 20:52:03 -0800 (PST) Received: from camionet.local (shm67-5-88-165-90-188.fbx.proxad.net. [88.165.90.188]) by mx.google.com with ESMTPS id bz12sm6772075wib.5.2013.01.30.20.52.01 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 30 Jan 2013 20:52:02 -0800 (PST) Message-ID: <5109F86F.6010600@jitsi.org> Date: Thu, 31 Jan 2013 05:51:59 +0100 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Bernard Aboba References: <20130128193921.20420.53308.idtracker@ietfa.amsl.com>, <51094C89.7020302@jitsi.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQkiKR2cJXezAvoW4Wz/V1iz0+pRlfw958gfnUGezAZ+3GwrDh0iKDc49bcT+xlW76n3leLb Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Trickle ICE update and a new SIP usage 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: Thu, 31 Jan 2013 04:52:06 -0000 Hey Bernard, On 31.01.13, 05:39, Bernard Aboba wrote: >> During the MMUSIC presentation and the mailing list discussions it was >> also pointed out that it is important for this work to happen in >> parallel with a SIP usage for trickle ICE. Enrico, Christer and I have >> therefore submitted the following document: >> >> http://tools.ietf.org/html/draft-ivov-mmusic-trickle-ice-sip-00 > >> >> As always, comments are welcome! > > Is my reading of the draft (see below) correct? > > 1. "half trickle" offers the possibility of backward compatibility, Yes. > if > the capabilities of the answerer aren't known and an RFC 5245 compliant > offer is made, sincethe Recv-Info: trickle-ice header is included in the > Offerper RFC 6086, as well as in a reliable 18x/2xx response. I am not sure I understand this part of the sentence. Note that there's also the 'trickle' token in both the offer and the answer (in the ice-options attribute). > 2. Section 3 suggests that the Offer in "half trickle" contains all > candidates. The Answer presumably includes host candidates (including > just 0.0.0.0 would not make much sense)in the response. Why not? > There seems to > be no need for the Offerer to send a "trickle-ice" Info-Package since it > sent all the candidates in the initial Offer. Sending the 'trickle' token in the offer allows the answerer to trickle even if the offerer didn't. Note that subsequent offer/answers from either side, that belong to the same session, would be full trickle since both agents have confirmed support. > 3. After the response is sent, then the Answerer starts the trickling > via the "trickle-ice" INFO packages. The Offerer knows to expect this > since a Recv-Info trickle-ice header was included in the response. Yes. And again, there's also the "trickle" token in the answer. I suppose we should require both to be present. > 4. If a pair is selected that includes a candidate obtained from a > "trickle-ice" Info-Package, is a conventional RFC 5245 offer/answer > exchange (not using INFO) requiredto confirm it? I suppose it would be, yes: it wouldn't match the default candidate in the o/a so ... Emil -- https://jitsi.org From magnus.westerlund@ericsson.com Thu Jan 31 02:46:26 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47FB421F86B2; Thu, 31 Jan 2013 02:46:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.854 X-Spam-Level: X-Spam-Status: No, score=-102.854 tagged_above=-999 required=5 tests=[AWL=-1.605, BAYES_00=-2.599, GB_SUMOF=5, HELO_EQ_SE=0.35, 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 FZY4Upxj+m9j; Thu, 31 Jan 2013 02:46:23 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 1B79221F8678; Thu, 31 Jan 2013 02:46:21 -0800 (PST) X-AuditID: c1b4fb2d-b7f316d0000028db-59-510a4b7dfbb2 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 63.D0.10459.D7B4A015; Thu, 31 Jan 2013 11:46:21 +0100 (CET) Received: from [127.0.0.1] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.279.1; Thu, 31 Jan 2013 11:46:21 +0100 Message-ID: <510A4B7C.3000009@ericsson.com> Date: Thu, 31 Jan 2013 11:46:20 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: "mmusic (E-mail)" , "rtcweb@ietf.org" X-Enigmail-Version: 1.5 Content-Type: multipart/mixed; boundary="------------080706010305080101000300" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuplluLIzCtJLcpLzFFi42KZGfG3VrfWmyvQYEUfv8XU5Y9ZLNb+a2d3 YPJYsuQnUwBjFJdNSmpOZllqkb5dAlfG950rmAuWn2Ou2NO2jKmB8fYVpi5GTg4JAROJc/eu MkLYYhIX7q1n62Lk4hASOMkosaznG5SznFFi161PYFW8AtoSc4/9YAexWQRUJfbtfMkCYrMJ WEjc/NHIBmKLCgRLbDi4igmiXlDi5MwnYDUiAv4STfO7wOYICzhIrN4+DaieA2izuMSaNxwg YWaBAIlHbe1gJUJAqxqaOlgnMPLNQjJpFpIyCFtPYsrVFihbXqJ562xmCDtHYu7nNlaY+Pa3 c6Di8RJ/1+5mX8DIvoqRPTcxMye93HATIzBID275rbuD8dQ5kUOM0hwsSuK8Ya4XAoQE0hNL UrNTUwtSi+KLSnNSiw8xMnFwSjUwVp/e45LHaRrTp+TSdH/FpNP5s5ymJFUYBR4R3LZE5g5L R1stX0tR6E4B3b9qefvriz0uff12xW7Tf4XcjHlNezUNuhOK722R0meNNlo3re1zptifWdsc rvo9/p9g0us68UDav9+e0YXLP6//tpyBL5HR5DLzigWeE27/6PBb5F1XerlG99djJZbijERD Leai4kQADkzA5iACAAA= Subject: [rtcweb] Draft on Multimedia concepts and relations for Intermim X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 31 Jan 2013 10:46:26 -0000 --------------080706010305080101000300 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit Hi, Attached is a draft on multimedia concepts and relations that we believe relevant for the upcoming interim. This includes commonalties between WebRTC and CLUE and other RTP usages. Sorry for the late submission, i do hope you have time to review it. At will also be properly submitted to IETF as soon as we figure out why the submission tools refuses to process it. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- --------------080706010305080101000300 Content-Type: text/plain; charset="windows-1252"; name="draft-burman-rtcweb-mmusic-media-structure-00.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-burman-rtcweb-mmusic-media-structure-00.txt" Network Working Group B. Burman Internet-Draft M. Westerlund Intended status: Informational Ericsson Expires: August 4, 2013 January 31, 2013 Multi-Media Concepts and Relations draft-burman-rtcweb-mmusic-media-structure-00 Abstract There are currently significant efforts ongoing in IETF regarding more advanced multi-media functionalities, such as the work related to RTCWEB and CLUE. This work includes use cases for both multi- party communication and multiple media streams from an individual end-point. The usage of scalable encoding or simulcast encoding as well as different types of transport mechanisms have created additional needs to correctly identify different types of resources and describe their relations to achieve intended functionalities. The different usages have both commonalities and differences in needs and behavior. This document attempts to review some usages and identify commonalities and needs. It then continues to highlight important aspects that need to be considered in the definition of these usages. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on August 4, 2013. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. Burman & Westerlund Expires August 4, 2013 [Page 1] Internet-Draft Media Concepts and Relations January 2013 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Existing RTP Usages . . . . . . . . . . . . . . . . . . . 4 3.1.1. Basic VoIP call . . . . . . . . . . . . . . . . . . . 4 3.1.2. Audio and Video Conference . . . . . . . . . . . . . . 5 3.1.3. Audio and Video Switched Conference . . . . . . . . . 7 3.2. WebRTC . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.2.1. Mesh-based Multi-party . . . . . . . . . . . . . . . . 9 3.2.2. Multi-source Endpoints . . . . . . . . . . . . . . . . 10 3.2.3. Media Relaying . . . . . . . . . . . . . . . . . . . . 11 3.2.4. Usage of Simulcast . . . . . . . . . . . . . . . . . . 11 3.3. CLUE Telepresence . . . . . . . . . . . . . . . . . . . . 13 3.3.1. Telepresence Functionality . . . . . . . . . . . . . . 13 3.3.2. Distributed Endpoint . . . . . . . . . . . . . . . . . 14 4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.1. Commonalities in Use Cases . . . . . . . . . . . . . . . . 14 4.1.1. Media Source . . . . . . . . . . . . . . . . . . . . . 14 4.1.2. Encodings . . . . . . . . . . . . . . . . . . . . . . 16 4.1.3. Synchronization contexts . . . . . . . . . . . . . . . 17 4.1.4. Distributed Endpoints . . . . . . . . . . . . . . . . 18 4.2. Identified WebRTC issues . . . . . . . . . . . . . . . . . 18 4.3. Relevant to SDP evolution . . . . . . . . . . . . . . . . 19 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 6. Security Considerations . . . . . . . . . . . . . . . . . . . 21 7. Informative References . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 Burman & Westerlund Expires August 4, 2013 [Page 2] Internet-Draft Media Concepts and Relations January 2013 1. Introduction This document concerns itself with the conceptual structures that can be found in different logical levels of a multi-media communication, from transport aspects to high-level needs of the communication application. The intention is to provide considerations and guidance that can be used when discussing how to resolve issues in the RTCWEB and CLUE related standardization. Typical use cases for those WG have commonalities that likely should be addressed similarly and in a way that allows to align them. The document starts with going deeper in the motivation why this has become an important problem at this time. This is followed by studies of some use cases and what concepts they contain, and concludes with a discussion of observed commonalities and important aspects to consider. 2. Motivation There has arisen a number of new needs and requirements lately from work such as WebRTC/RTCWEB [I-D.ietf-rtcweb-overview] and CLUE [I-D.ietf-clue-framework]. The applications considered in those WG has surfaced new requirements on the usage of both RTP [RFC3550] and existing signalling solutions. The main application aspects that have created new needs are: o Multiple Media Streams from an end-point. The fact that an end- point may have multiple media capture devices, such as cameras or microphone mixes. o Group communications involving multiple end-points. This is realized using both mesh based connections as well as centralized conference nodes. These creating a need for dealing with multiple endpoints and/or multiple streams with different origins from a transport peer. o Media Stream Adaptation, both to adjust network resource consumption as well as to handle varying end-point capabilities in group communication. o Transport mechanisms including both higher levels of aggregation [I-D.ietf-mmusic-sdp-bundle-negotiation] [I-D.ietf-avtcore-multi-media-rtp-session] and the use of application-level transport repair mechanisms such as forward error correction (FEC) and/or retransmission. Burman & Westerlund Expires August 4, 2013 [Page 3] Internet-Draft Media Concepts and Relations January 2013 The presence of multiple media resources or components creates a need to identify, handle and group those resources across multiple different instantiations or alternatives. 3. Use Cases 3.1. Existing RTP Usages There are many different existing RTP usages. This section brings up some that we deem interesting in comparison to the other use cases. 3.1.1. Basic VoIP call This use case is intended to function as a base-line to contrast against the rest of the use cases. The communication context is an audio-only bi-directional communication between two users, Alice and Bob. This communication uses a single multi-media session that can be established in a number of ways, but let's assume SIP/SDP [RFC3261][RFC3264]. This multi- media session contains two end-points, one for Alice and one for Bob. Each end-point has an audio capture device that is used to create a single audio media source at each end-point. +-------+ +-------+ | Alice |<------->| Bob | +-------+ +-------+ Figure 1: Point-to-point Audio The session establishment (SIP/SDP) negotiates the intent to communicate over RTP using only the audio media type. Inherent in the application is an assumption of only a single media source in each direction. The boundaries for the encodings are represented using RTP Payload types in conjunction with the SDP bandwidth parameter (b=). The session establishment is also used to negotiate that RTP will be used, thus resulting in that an RTP session will be created for the audio. The underlying transport flows, in this case a single bi-directional UDP flow for RTP, another for RTCP, is configured by each end-point providing its' IP address and port, which becomes source or destination depending on in which direction the packet is sent. The RTP session will have two RTP media streams, one in each direction, which carries the encoding of the media source the sending implementation has chosen based on the boundaries established by the RTP payload types and other SDP parameters, e.g. codec, and bit- Burman & Westerlund Expires August 4, 2013 [Page 4] Internet-Draft Media Concepts and Relations January 2013 rates. The streams are in the RTP context identified by their SSRCs. 3.1.2. Audio and Video Conference This use case is a multi-party use case with a central conference node performing media mixing. It also includes two media types, both audio and video. The high level topology of the communication session is the following: +-------+ +------------+ +-------+ | |<-Audio->| |<--Audio-->| | | Alice | | | | Bob | | |<-Video->| |<--Video-->| | +-------+ | | +-------+ | Mixer | +-------+ | | +-------+ | |<-Audio->| |<--Audio-->| | |Charlie| | | | David | | |<-Video->| |<--Video-->| | +-------+ +------------+ +-------+ Figure 2: Audio and Video Conference with Centralized Mixing The communication session is a multi-party conference including the four users Alice, Bob, Charlie, and David. This communication session contains four end-points and one middlebox (the Mixer). The communication session is established using four different multi-media sessions; one each between the user's endpoints and the middlebox. Each of these multi-media sessions uses a session establishment method, like SIP/SDP. Looking at a single multi-media session between a user, e.g. Alice, and the Mixer, there exist two media types, audio and video. Alice has two capture devices, one video camera giving her a video media source, and an audio capture device giving an audio media source. These two media sources are captured in the same room by the same end-point and thus have a strong timing relationship, requiring inter-media synchronization at playback to provide the correct fidelity. Thus Alice's endpoint has a synchronization context that both her media sources use. These two media sources are encoded using encoding parameters within the boundaries that has been agreed between the end-point and the Mixer using the session establishment. As has been common practice, each media type will use its own RTP session between the end-point and the mixer. Thus a single audio stream using a single SSRC will flow from Alice to the Mixer in the Audio RTP session and a single video stream will flow in the Video RTP session. Using this division Burman & Westerlund Expires August 4, 2013 [Page 5] Internet-Draft Media Concepts and Relations January 2013 in separate RTP sessions, the bandwidth of both audio and video can be unambiguously and separately negotiated by the SDP bandwidth attributes exchanged between the end-points and the mixer. Each RTP session is using its own Transport Flows. The common synchronization context across Alice's two media streams is identified by binding both streams to the same CNAME, generated by Alice's endpoint. The mixer does not have any physical capture devices, instead it creates conceptual media sources. It provides two media sources towards Alice; one audio being a mix of the audio from Bob, Charlie and David, the second one being a conceptual video source that contains a selection of one of the other video sources received from Bob, Charlie, or David depending on who is speaking. The Mixer's audio and video sources are provided in an encoding using a codec that is supported by both Alice's endpoint and the mixer. These streams are identified by a single SSRC in the respective RTP session. The mixer will have its own synchronization context and it will inject the media from Bob, Charlie and David in a synchronized way into the mixer's synchronization context to maintain the inter-media synchronization of the original media sources. The mixer establishes independent multimedia sessions with each of the participant's endpoints. The mixer will in most cases also have unique conceptual media sources for each of the endpoints. This as audio mixes and video selections typically exclude media sources originating from the receiving end-point. For example, Bob's audio mix will be a mix of Alice, Charlie and David, and will not contain Bob's own audio. This use case may need unique user identities across the whole communication session. An example functionality of this is a participant list which includes audio energy levels showing who is speaking within the audio mix. If that information is carried in RTP using the RTP header extension for Mixer to audio clients [RFC6465] then contributing source identities in the form of CSRC need to be bound to the other end-point's media sources or user identities. This despite the fact that each RTP session towards a particular user's endpoint is terminated in the RTP mixer. This points out the need for identifiers that exist in multiple multi-media session contexts. In most cases this can easily be solved by the application having identities tailored specifically for its own needs, but some applications will benefit from having access to some commonly defined structure for media source identities. Burman & Westerlund Expires August 4, 2013 [Page 6] Internet-Draft Media Concepts and Relations January 2013 3.1.3. Audio and Video Switched Conference This use case is similar to the one above (Section 3.1.2), with the difference that the mixer does not mix media streams by decoding, mixing and re-encoding them, but rather switches a selection of received media more or less unmodified towards receiving end-points. This difference may not be very apparent to the end-user, but the main motivations to eliminate the mixing operation and switch rather than mix are: o Lower processing requirements in the mixer. o Lower complexity in the mixer. o Higher media quality at the receiver given a certain media bitrate. o Lower end-to-end media delay. Without the mixing operation, the mixer has limited ability to create conceptual media sources that are customized for each receiver. The reasons for such customizations comes from sender and receiver differences in available resources and preferences: o Presenting multiple conference users simultaneously, like in a video mosaic. o Alignment of sent media quality to receivers presentation needs. o Alignment of codec type and configuration between sender and receiver. o Alignment of encoded bitrate to the available end-to-end link bandwidth. To enable elimination of the mixing operation, media sent to the mixer must sufficiently well meet the above constraints for all intended receivers. There are several ways to achieve this. One way is to, by some system-wide design, ensure that all senders and receivers are basically identical in all the above aspects. This may however prove unrealistic when variations in conditions and end- points are too large. Another way is to let a sender provide a (small) set of alternative representations for each sent media source, enough to sufficiently well cover the expected range of variation. If those media source representations, encodings, are independent from one another, they constitute a Simulcast of the media source. If an encoding is instead dependent on and thus requires reception of one or more other encodings, the representation Burman & Westerlund Expires August 4, 2013 [Page 7] Internet-Draft Media Concepts and Relations January 2013 of the media source jointly achieved by all dependent encodings is said to be Scalable. Simulcast and Scalable encoding can also be combined. Both Simulcast and Scalable encodings result in that a single media source generates multiple RTP media streams of the same media type. The division of bandwidth between the Simulcast or Scalable streams for a single media source is application specific and will vary. The total bandwidth for a Simulcast or a Scalable source is the sum of all included RTP media streams. Since all streams in a Simulcast or Scalable source originate from the same capture device, they are closely related and should thus share synchronization context. The first and second customizations listed above, presenting multiple conference users simultaneously, aligned with the presentation needs in the receiver, can also be achieved without mixing operation by simply sending appropriate quality media from those users individually to each receiver. The total bandwidth of this user presentation aggregate is the sum of all included RTP media streams. Audio and video from a single user share synchronization context and can be synchronized. Streams that originate from different users do not have the same synchronization context, which is acceptable since they do not need to be synchronized, but just presented jointly. An actual mixer device need not be either mixing-only or switching- only, but may implement both mixing and switching and may also choose dynamically what to do for a specific media and a specific receiving user on a case-by-case basis or based on some policy. 3.2. WebRTC This section brings up two different instantiations of WebRTC [ref-webrtc10] that stresses different aspects. But let's start with reviewing some important aspects of WebRTC and the MediaStream [ref-media-capture] API. In WebRTC, an application gets access to a media source by calling getUserMedia(), which creates a MediaStream [ref-media-capture] (note the capitalization). A MediaStream consists of zero or more MediaStreamTracks, where each MediaStreamTrack is associated with a media source. These locally generated MediaStreams and their tracks are connected to local media sources, which can be media devices such as video cameras or microphones, but can also be files. An WebRTC PeerConnection (PC) is an association between two endpoints that is capable of communicating media from one end to the other. The PC concept includes establishment procedures, including media negotiation. Thus a PC is an instantiation of a Multimedia Session. Burman & Westerlund Expires August 4, 2013 [Page 8] Internet-Draft Media Concepts and Relations January 2013 When one end-point adds a MediaStream to a PC, the other endpoint will by default receive an encoded representation of the MediaStream and the active MediaStreamTracks. 3.2.1. Mesh-based Multi-party This is a use case of WebRTC which establishes a multi-party communication session by establishing an individual PC with each participant in the communication session. +---+ +---+ | A |<---->| B | +---+ +---+ ^ ^ \ / \ / v v +---+ | C | +---+ Figure 3: WebRTC Mesh-based Multi-party Users A, B and C want to have a joint communication session. This communication session is created using a Web-application without any central conference functionality. Instead, it uses a mesh of PeerConnections to connect each participant's endpoint with the other endpoints. In this example, three double-ended connections are required to connect the three participants, and each endpoint has two PCs. This is an audio and video communication and each end-point has one video camera and one microphone as media sources. Each endpoint creates its own MediaStream with one video MediaStreamTrack and one audio MediaStreamTrack. The endpoints add their MediaStream to both of their PCs. Let's now focus on a single PC; in this case the one established between A and B. During the establishment of this PC, the two endpoints agree to use only a single transport flow for all media types, thus a single RTP session is created between A and B. A's MediaStream has one audio media source that is encoded according to the boundaries established by the PeerConnection establishment signalling, which includes the RTP payload types and thus Codecs supported as well as bit-rate boundaries. The encoding of A's media source is then sent in an RTP stream identified by a unique SSRC. In this case, as there are two media sources at A, two encodings will be created which will be transmitted using two different RTP streams Burman & Westerlund Expires August 4, 2013 [Page 9] Internet-Draft Media Concepts and Relations January 2013 with their respective SSRC. Both these streams will reference the same synchronization context through a common CNAME identifier used by A. B will have the same configuration, thus resulting in at least four SSRC being used in the RTP session part of the A-B PC. Depending on the configuration of the two PCs that A has, i.e. the A-B and the A-C ones, A could potentially reuse the encoding of a media source in both contexts, under certain conditions. First, a common codec and configuration needs to exist and the boundaries for these configurations must allow a common work point. In addition, the required bandwidth capacity needs to be available over the paths used by the different PCs. Both of those conditions are not always true. Thus it is quite likely that the endpoint will sometimes instead be required to produce two different encodings of the same media source. If an application needs to reference the media from a particular endpoint, it can use the MediaStream and MediaStreamTrack as they point back to the media sources at a particular endpoint. This as the MediaStream has a scope that is not PeerConnection specific. The programmer can however implement this differently while supporting the same use case. In this case the programmer creates two MediaStreams that each have MediaStreamTracks that share common media sources. This can be done either by calling getUserMedia() twice, or by cloning the MediaStream obtained by the only getUserMedia() call. In this example the result is two MediaStreams that are connected to different PCs. From an identity perspective, the two MediaStreams are different but share common media sources. This fact is currently not made explicit in the API. 3.2.2. Multi-source Endpoints This section concerns itself with endpoints that have more than one media source for a particular media type. A straightforward example would be a laptop with a built in video camera used to capture the user and a second video camera, for example attached by USB, that is used to capture something else the user wants to show. Both these cameras are typically present in the same sound field, so it will be common to have only a single audio media source. A possible way of representing this is to have two MediaStreams, one with the built in camera and the audio, and a second one with the USB camera and the audio. Each MediaStream is intended to be played with audio and video synchronized, but the user (local or remote) or application is likely to switch between the two captures. It becomes important for a receiving endpoint that it can determine Burman & Westerlund Expires August 4, 2013 [Page 10] Internet-Draft Media Concepts and Relations January 2013 that the audio in the two MediaStreams have the same synchronization context. Otherwise a receiver may playback the same media source twice, with some time overlap, at a switch between playing the two MediaStreams. Being able to determine that they are the same media source further allow for removing redundancy by having a single encoding if appropriate for both MediaStreamTracks. 3.2.3. Media Relaying WebRTC endpoints can relay a received MediaStream from one PC to another by the simple API level maneuver of adding the received MediaStream to the other PC. To realize this in the implementation is more complex. This can also cause some issues from a media perspective. If an application spanning across multiple endpoints that relay media between each other makes a mistake, a media loop can be created. Media Loops could become a significant issue. For example could an audio echo be created, i.e. an endpoint receives its own media without detecting that it is its own media and plays it back with some delay. In case a WebRTC endpoint produces a conceptual media source by mixing incoming MediaStreams, if there is no loop detection, a feedback loop can be created. RTP has loop detection to detect and handle such cases within a single RTP session. However, in the context of WebRTC, the RTP session is local to the PC and thus cannot rely on the RTP level loop detection. Instead, if this protection is needed on the WebRTC MediaStream level, it could for example be achieved by having media source identifiers that can be preserved between the different MediaStreams in the PCs. When relaying media and in case one receives multiple encodings of the same source it is beneficial to know that. For example, if one encoding arrives with a delay of 80 ms and another with 450 ms, being able to choose the one with 80 ms and not be forced to delay all media sources from the same synchronization context to the most delayed source improves performance. 3.2.4. Usage of Simulcast In this section we look at a use case applying simulcast from each user's endpoint to a central conference node to avoid the need for an individual encoding to each receiving endpoint. Instead, the central node chooses which of the available encodings that is forwarded to a particular receiver, like in Section 3.1.3. Burman & Westerlund Expires August 4, 2013 [Page 11] Internet-Draft Media Concepts and Relations January 2013 +-----------+ +------------+ Enc2 +---+ | A +-Enc1|----->| |----->| B | | | | | | +---+ | Src-+-Enc2|----->| | Enc1 +---+ +-----------+ | Mixer |----->| C | | | +---+ | | Enc2 +---+ | |----->| D | +------------+ +---+ Figure 4 In this Communication Session there are four users with endpoints and one middlebox (The Mixer). This is an audio and video communication session. The audio source is not simulcasted and the endpoint only needs to produce a single encoding. For the video source, each endpoint will produce multiple encodings (Enc1 and Enc2 in Figure 4) and transfer them simultaneously to the mixer. The mixer picks the most appropriate encoding for the path from the mixer to each receiving client. Currently there exists no specified way in WebRTC to realise the above, although use-cases and requirements discuss simulcast functionality. The authors believe there exist two possible solution alternatives in the WebRTC context: Multiple Encodings within a PeerConnection: The endpoint that wants to provide a simulcast creates one or more MediaStreams with the media sources it wants to transmit over a particular PC. The WebRTC API provides functionality to enable multiple encodings to be produced for a particular MediaStreamTrack and have possibility to configure the desired quality levels and/or differences for each of the encodings. Using Multiple PeerConnections: There exist capabilities to both negotiate and control the codec, bit-rate, video resolution, frame-rate, etc of a particular MediaStreamTrack in the context of one PeerConnection. Thus one method to provide multiple encodings is to establish multiple PeerConnections between A and the Mixer, where each PC is configured to provide the desired quality. Note that this solution comes in two flavors from an application perspective. One is that the same MediaStream object is added to the two PeerConnections. The second is that two different MediaStream objects, with the same number of MediaStreamTracks and representing the same sources, are created (e.g by cloning), one of them added to the first PeerConnection and the second one to the second PeerConnection. Burman & Westerlund Expires August 4, 2013 [Page 12] Internet-Draft Media Concepts and Relations January 2013 Both of these solutions share a common requirement, the need to separate the received RTP streams not only based on media source, but also on the encoding. However, on an API level the solutions appear different. For Multiple Encodings within the context of a PC, the receiver will need new access methods for accessing and manipulating the different encodings. Using multiple PC instead requires that one can easily determine the shared (simulcasted) media source despite receiving it in multiple MediaStreams on different PCs. If the same MediaStream is added to both PC's the id's of the MediaStream and MediaStreamTracks will be the same, while they will be different if different MediaStream's (but representing the same sources) are added to the two PC's. 3.3. CLUE Telepresence The CLUE framework [I-D.ietf-clue-framework] and use case [I-D.ietf-clue-telepresence-use-cases] documents make use of most, if not all, media concepts that were already discussed in previous sections, and adds a few more. 3.3.1. Telepresence Functionality A communicating CLUE Endpoint can, compared to other types of Endpoints, be characterized by using multiple media resources: o Multiple capture devices, such as cameras or microphones, generating the media for a media source. o Multiple render devices, such as displays or speakers. o Multiple Media Types, such as audio, video and presentation streams. o Multiple remote Endpoints, since conference is a typical use case. o Multiple Encodings (encoded representations) of a media source. o Multiple Media Streams representing multiple media sources. To make the multitude of resources more manageable, CLUE introduces some additional structures. For example, related media sources in a multimedia session are grouped into Scenes, which can generally be represented in different ways, described by alternative Scene Entries. CLUE explicitly separates the concept of a media source from the encoded representations of it and a single media source can be used to create multiple Encodings. It is also possible in CLUE to account for constraints in resource handling, like limitations in possible Encoding combinations due to physical device implementation. Burman & Westerlund Expires August 4, 2013 [Page 13] Internet-Draft Media Concepts and Relations January 2013 The number of media resources typically differ between Endpoints. Specifically, the number of available media resources of a certain type used for sending at the sender side typically does not match the number of corresponding media resources used for receiving at the receiver side. Some selection process must thus be applied either at the sender or the receiver to select a subset of resources to be used. Hence, each resource that need to be part of that selection process must have some identification and characterization that can be understood by the selecting party. In the CLUE model, the sender (Provider) announces available resources and the receiver (Consumer) chooses what to receive. This choice is made independently in the two directions of a bi-directional communication. 3.3.2. Distributed Endpoint The definition of a single CLUE Endpoint in the framework [I-D.ietf-clue-framework] says it can consist of several physical devices with source and sink media streams. This means that each logical node of such distributed Endpoint can have a separate transport interface, and thus that media sources originating from the same Endpoint can have different transport addresses. 4. Discussion This section discusses some conclusions the authors make based on the use cases. First we will discuss commonalities between use cases. Secondly we will provide a summary of issues we see affect WebRTC. Lastly we consider aspects that need to be considered in the SDP evolution that is ongoing. 4.1. Commonalities in Use Cases The above use cases illustrate a couple of concepts that are not well defined, nor have they fully specified standard mechanisms or behaviors. This section contains a discussion of such concepts, which the authors believe are useful in more than one context and thus should be defined to provide a common function when needed by multi-media communication applications. 4.1.1. Media Source In several of the above use cases there exist a need for a separation between the media source, the particular encoding and its transport stream. In vanilla RTP there exist a one-to-one mapping between these; one media source is encoded in one particular way and transported as one RTP stream using a single SSRC in a particular RTP session. Burman & Westerlund Expires August 4, 2013 [Page 14] Internet-Draft Media Concepts and Relations January 2013 The reason for not keeping a strict one-to-one mapping, allowing the media source to be identified separately from the RTP media stream (SSRC), varies depending on the application's needs and the desired functionalities: Simulcast: Simulcast is a functionality to provide multiple simultaneous encodings of the same media source. As each encoding is independent of the other, in contrast to scalable encoding, independent transport streams for each encoding is needed. The receiver of a simulcast stream will need to be able to explicitly identify each encoding upon reception, as well as which media source it is an encoding of. This is especially important in a context of multiple media sources being provided from the same endpoint. Mesh-based communication: When a communication application implements multi-party communication through a mesh of transport flows, there exist a need for tracking the original media source, especially when relaying between nodes is possible. It is likely that the encodings provided over the different transports are different. If an application uses relaying between different transports, an endpoint may, intentionally or not, receive multiple encodings of the same media source over the same or different transports. Some applications can handle the needed identification, but some can benefit from a standardized method to identify sources. The second argument above can be generalized into a common need in applications that utilize multiple multimedia sessions, such as multiple PeerConnections or multiple SIP/SDP-established RTP sessions, to form a larger communication session between multiple endpoints. These applications commonly need to track media sources that occur in more than one multimedia session. Looking at both CLUE and WebRTC, they appear to contain their own variants of the concept that was above denoted a media source. In CLUE it is called Media Capture. In WebRTC each MediaStreamTrack is identifiable, however, several MediaStreamTracks can share the actual source, and there is no way for the application to realize this currently. The identification of sources is being discussed, and there is a proposal [ref-leithead] that introduces the concept 'Track Source'. Thus, in this document we see the media source as the generalized commonality between these two concepts. Giving each media source a unique identifier in the communication session/context that is reused in all the PeerConnections or SIP/SDP-established RTP sessions would enable loop detection, correctly associate alternative encodings and provide a common name across the endpoints for application logic to reference the actual media source rather than a Burman & Westerlund Expires August 4, 2013 [Page 15] Internet-Draft Media Concepts and Relations January 2013 particular encoding or transport stream. It is arguable if the application should really know a long term persistent source identification, such as based on hardware identities, for example due to fingerprinting issues, and it would likely be better to use an anonymous identification that is still unique in a sufficiently wide context, for example within the communication application instance. 4.1.2. Encodings An Encoding is a particular encoded representation of a particular media source. In the context of RTP and Signalling, a particular encoding must fit the established parameters, such as RTP payload types, media bandwidths, and other more or less codec-specific media constraints such as resolution, frame-rate, fidelity, audio bandwidth, etc. In the context of an application, it appears that there are primarily two considerations around the use of multiple encodings. The first is how many and what their defining parameters are. This may require to be negotiated, something the existing signalling solutions, like SDP, currently lack support for. For example in SDP, there exist no way to express that you would like to receive three different encodings of a particular video source. In addition, if you for example prefer these three encodings to be 720p/25 Hz, 360p/25 Hz and 180p/12.5 Hz, and even if you could define RTP payload types with these constraints, they must be linked to RTP streams carrying the encodings of the particular source. Also, for some RTP payload types there exist difficulties to express encoding characteristics with the desired granularity. The number of RTP payload types that can be used for a particular potential encoding can also be a constraint, especially as a single RTP payload type could well be used for all three target resolutions and frame rates in the example. Using multiple encodings might even be desirable for multi-party conferences that switches video, rather than composites and re-encodes it. It might be that SDP is not the most suitable place to negotiate this. From an application perspective, utilizing clients that have standardized APIs or protocols to control them, there exist a need for the application to express what it prefers in number of encodings as well as what their primary target parameters are. Secondly, some applications may need explicit indication of what encoding a particular stream represents. In some cases this can be deduced based on information such as RTP payload types and parameters received in the media stream, but such implicit information will not Burman & Westerlund Expires August 4, 2013 [Page 16] Internet-Draft Media Concepts and Relations January 2013 always be detailed enough and it may also be time-consuming to extract. For example, in SDP there is currently limitations for binding the relevant information about a particular encoding to the corresponding RTP stream, unless only a single RTP stream is defined per media description (m= line). The CLUE framework explicitly discusses encodings as constraints that are applied when transforming a media source (capture) into what CLUE calls a capture encoding. This includes both explicit identification as well as a set of boundary parameters such as maximum width, height, frame rate as well as bandwidth. In WebRTC nothing related has yet been defined, and we note this as an issue that needs to be resolved. This as the authors expect that support for multiple encodings will be required to enable simulcast and scalability. 4.1.3. Synchronization contexts The shortcomings around synchronization contexts appears rather limited. In RTP, each RTP media stream is associated with a particular synchronization context through the CNAME session description item. The main concerns here are likely twofold. The first concern is to avoid unnecessary creation of new contexts, and rather correctly associate with the contexts that actually exist. For example, WebRTC MediaStreams are defined so that all MediaStreamTracks within a particular MediaStream shall be synchronized. An easy method for meeting this would be to assign a new CNAME for each MediaStream. However, that would ignore the fact that several media sources from the same synchronization context may appear in different combinations across several MediaStreams. Thus all these MediaStreams should share synchronization context to avoid playback glitches, like playing back different instantiations of a single media source out of sync because the media source was shared between two different MediaStreams. The second problem is that synchronization context identification in RTP, i.e. CNAME, is overloaded as an endpoint identifier. As an example, consider an endpoint that has two synchronization contexts; one for audio and video in the room and another for an audio and video presentation stream, like the output of an DVD player. Relying on that an endpoint has only a single synchronization context and CNAME may be incorrect and could create issues that an application designer as well as RTP and signalling extension specifications need to watch out for. CLUE discusses so far quite little about synchronization, but clearly intends to enable lip synchronization between captures that have that relation. The second issue is however quite likely to be encountered Burman & Westerlund Expires August 4, 2013 [Page 17] Internet-Draft Media Concepts and Relations January 2013 in CLUE due to explicit inclusion of the Scene concept, where different Scenes do not require to share the same synchronization context, but is rather intended for situations where Scenes cannot share synchronization context. 4.1.4. Distributed Endpoints When an endpoint consists of multiple nodes, the added complexity is often local to that endpoint, which is appropriate. However, some few properties of distributed endpoints needs to be tolerated by all entities in a multimedia communication session. The main item is to not assume that a single endpoint will only use a single network address. This is a dangerous assumption even for non-distributed endpoints due to multi-homing and the common deployment of NATs, especially large scale NATs which in worst case uses multiple addresses for a single endpoint's transport flows. Distributed endpoints are brought up in the CLUE context. They are not specifically discussed in the WebRTC context, instead the desire for transport level aggregation makes such endpoints problematic. However, WebRTC does allow for fallback to media type specific transport flows and can thus without issues support distributed endpoints. 4.2. Identified WebRTC issues In the process of identifying commonalities and differences between the different use cases we have identified what to us appears to be issues in the current specification of WebRTC that needs to be reviewed. 1. If simulcast or scalability are to be supported at all, the WebRTC API will need to find a method to deal more explicitly with the existence of different encodings and how these are configured, accessed and referenced. For simulcast, the authors see a quite straightforward solution where each PeerConnection is only allowed to contain a single encoding for a specific media source and the desired quality level can be negotiated for the full PeerConnection. When multiple encodings are desired, multiple PeerConnections with differences in configuration are established. That would only require that the underlying media source can explicitly be indicated and tracked by the receiver. 2. The current API structure allows to have multiple MediaStreams with fully or partially overlapping media sources. This, combined with multiple PeerConnections and the likely possibility to do relaying, there appears to exist a significant need to determine the underlying media source, despite receiving Burman & Westerlund Expires August 4, 2013 [Page 18] Internet-Draft Media Concepts and Relations January 2013 different MediaStreams with particular media sources encoded in different ways. It is proposed that MediaSources are made possible to identify uniquely across multiple PeerConnections in the context of the communication application. It is however likely that while being unique in a sufficiently large context, the identification should also be anonymous to avoid fingerprinting issues, similar to the situation discussed in Section 4.1.1. 3. Implementations of the MediaStream API must be careful in how they name and deal with synchronization contexts, so that the actual underlying synchronization context is preserved when possible. It should be noted that cannot be done when a MediaStream is created that contains media sources from multiple synchronization contexts. This will instead require resynchronization of contributing sources, creation of a new synchronization context, and inserting the sources into that synchronization context. These issues need to be discussed and an appropriate way to resolve them must be chosen. 4.3. Relevant to SDP evolution The joint MMUSIC / RTCWeb WGs interim meeting in February 2013 will discuss a number of SDP related issues around the handling of multiple sources; the aggregation of multiple media types over the same RTP session as well as RTP sharing its transport flow not only with ICE/STUN but also with the WebRTC data channel using SCTP/DTLS/ UDP. These issues will potentially result in a significant impact on SDP. It may also impact other ongoing work as well as existing usages and applications, making these discussions difficult. The above use cases and discussion points to the existence of a number of commonalities between WebRTC and CLUE, and that a solution should preferably be usable by both. It is a very open question how much functionality CLUE requires from SDP, as CLUE WG plans to develop a protocol with a different usage model. The appropriate division in functionality between SDP and this protocol is currently unknown. Based on this document, it is possible to express some protocol requirements when negotiating multimedia sessions and their media configurations. Note that this is written as requirements to consider, given that one believes this functionality is needed in SDP. The Requirements: Burman & Westerlund Expires August 4, 2013 [Page 19] Internet-Draft Media Concepts and Relations January 2013 Encoding negotiation: For Simulcast and Scalability in applications, it must be possible to negotiate the number and the boundary conditions for the desired encodings created from a particular media source. Media Resource Identification: SDP-based applications that need explicit information about media sources, multiple encodings and their related RTP media streams could benefit from a common way of providing this information. This need can result in multiple different actual requirements. Some require a common, explicit identification of media sources across multiple signalling contexts. Some may require explicit indication of which set of encodings that has the same media source and thus which sets of RTP media streams (SSRCs) that are related to a particular media source. RTP media stream parameters: With a greater heterogeneity of the possible encodings and their boundary conditions, situations may arise where some or sets of RTP media streams will need to have specific sets of parameters associated with them, compared to other (sets of) RTP media streams. The above are general requirements and in some cases the appropriate point to address the requirement may not even be SDP. For example, media source identification could primarily be put in an RTCP Session Description (SDES) item, and only when so required by the application also be included in the signalling. The discussion in this document has impact on the high level decision regarding how to relate RTP media streams to SDP media descriptions. However, as it is currently presenting concepts rather than giving concrete proposals on how to enable these concepts as extensions to SDP or other protocols, it is difficult to determine the actual impact that a high level solution will have. However, the authors are convinced that neither of the directions will prevent the definition of suitable concepts in SDP. 5. IANA Considerations This document makes no request of IANA. Note to RFC Editor: this section may be removed on publication as an RFC. Burman & Westerlund Expires August 4, 2013 [Page 20] Internet-Draft Media Concepts and Relations January 2013 6. Security Considerations The realization of the proposed concepts and the resolution will have security considerations. However, at this stage it is unclear if any has not already common considerations regarding preserving privacy, confidentiality and ensure integrity to prevent denial of service or quality degradations. 7. Informative References [I-D.ietf-avtcore-multi-media-rtp-session] Westerlund, M., Perkins, C., and J. Lennox, "Multiple Media Types in an RTP Session", draft-ietf-avtcore-multi-media-rtp-session-01 (work in progress), October 2012. [I-D.ietf-clue-framework] Duckworth, M., Pepperell, A., and S. Wenger, "Framework for Telepresence Multi-Streams", draft-ietf-clue-framework-08 (work in progress), December 2012. [I-D.ietf-clue-telepresence-use-cases] Romanow, A., Botzko, S., Duckworth, M., Even, R., and I. Communications, "Use Cases for Telepresence Multi- streams", draft-ietf-clue-telepresence-use-cases-04 (work in progress), August 2012. [I-D.ietf-mmusic-sdp-bundle-negotiation] Holmberg, C. and H. Alvestrand, "Multiplexing Negotiation Using Session Description Protocol (SDP) Port Numbers", draft-ietf-mmusic-sdp-bundle-negotiation-01 (work in progress), August 2012. [I-D.ietf-rtcweb-overview] Alvestrand, H., "Overview: Real Time Protocols for Brower- based Applications", draft-ietf-rtcweb-overview-05 (work in progress), December 2012. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002. Burman & Westerlund Expires August 4, 2013 [Page 21] Internet-Draft Media Concepts and Relations January 2013 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. [RFC6465] Ivov, E., Marocco, E., and J. Lennox, "A Real-time Transport Protocol (RTP) Header Extension for Mixer-to- Client Audio Level Indication", RFC 6465, December 2011. [ref-leithead] Microsoft, "Proposal: Media Capture and Streams Settings API v6, https://dvcs.w3.org/hg/dap/raw-file/tip/ media-stream-capture/proposals/ SettingsAPI_proposal_v6.html", December 2012. [ref-media-capture] "Media Capture and Streams, http://dev.w3.org/2011/webrtc/editor/getusermedia.html", December 2012. [ref-webrtc10] "WebRTC 1.0: Real-time Communication Between Browsers, http://dev.w3.org/2011/webrtc/editor/webrtc.html", January 2013. Authors' Addresses Bo Burman Ericsson Farogatan 6 SE-164 80 Kista Sweden Phone: +46 10 714 13 11 Email: bo.burman@ericsson.com Magnus Westerlund Ericsson Farogatan 6 SE-164 80 Kista Sweden Phone: +46 10 714 82 87 Email: magnus.westerlund@ericsson.com Burman & Westerlund Expires August 4, 2013 [Page 22] --------------080706010305080101000300-- From harald@alvestrand.no Thu Jan 31 04:30:24 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 823E621F8759 for ; Thu, 31 Jan 2013 04:30:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.239 X-Spam-Level: X-Spam-Status: No, score=-110.239 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, J_CHICKENPOX_19=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 dhBTtS81oX73 for ; Thu, 31 Jan 2013 04:30:23 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 3791221F8795 for ; Thu, 31 Jan 2013 04:30:23 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8C9D839E1B7; Thu, 31 Jan 2013 13:30:20 +0100 (CET) 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 tXf7BvHexgaI; Thu, 31 Jan 2013 13:30:19 +0100 (CET) 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 14B8339E149; Thu, 31 Jan 2013 13:30:19 +0100 (CET) Message-ID: <510A63DA.3080301@alvestrand.no> Date: Thu, 31 Jan 2013 13:30:18 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Martin Thomson References: <50F97303.4070906@ericsson.com> <5108F1B9.9020709@alvestrand.no> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] WG Last Call: draft-ietf-rtcweb-use-cases-and-requirements-10 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 31 Jan 2013 12:30:24 -0000 On 01/30/2013 09:54 PM, Martin Thomson wrote: > On 30 January 2013 19:11, Harald Alvestrand wrote: >> I'd prefer not to formally do this (Last Calls need to close), but the >> normal procedure is that comments raised during Last Call are addressed >> after the WG Last Call closes. If addressing comments cause major changes, a >> new WG Last Call might be in order. > In which case I would suggest that the last call be concluded with a > decision not to send this document to the IESG. > >>> F13 The browser MUST be able to apply spatialization >>> effects to audio streams. >>> >>> So...this is either pointless in the same vein as the requirement "the >>> browser MUST be able to control the volume of audio" or it is not >>> addressed. I see A13, but that's not happening. Given where we've >>> directed effort, I am tempted to suggest that this be removed. >> >> In the WEBRTC WG, we've assumed that this is satisfied by saying "audio can >> be sent to the WebAudio API". > Yeah, that doesn't connect with the text of the requirement in any > meaningful fashion. I do prefer that requirements are testable. What > test does the above text produce? I can think of a reasonably easy test that generates the signal (read a mono sound from a file to a mediastream using the MediaSource interface, feed it to the WebAudio API, apply spatialization effects using the WebAudio API), but I'm not sure how you test whether spatialization is actually performed correctly. But writing that test should be a W3C matter. > >>> F15 The browser MUST be able to change the level >>> in audio streams. >>> >>> This is a problem for the same reason as above. AGC is one thing, but >>> this is unspecific. Does this apply to inbound and outbound streams? >>> Is this level control provided to the application or is this a >>> pointless requirement on browser chrome? This also has implications >>> for "tainted" streams, in which case I believe that even level control >>> should be prevented. >> >> I think you're wrong about tainting, but I wonder if this is trivially >> satisfied by the fact that output elements have volume controls (and there's >> always WebAudio as a backup). > If that's the case, it's not clear why this even exists. BTW, with > tainting, I'm concerned about the granularity of level control > available to applications and mixing of tainted with untainted > sources. I don't think I understand the problem fully from this description. Can you write up a note on this issue and send it to the Media Capture task force? That issue seems to belong there. > >>> F7 The browser MUST support fast stream switches. >>> >>> What does this mean? There are a number of factors that could be at play >>> here: >> Not clear what you intend to say - does it need to be specified further, or >> removed? > Yes. Specified further (yes) or removed (yes)? > >> "Short" is not specified further, but in the common case of voice activated >> switching, I think one assumes that you want to see the speaker before he's >> finished his first word. > Again, as long as it's testable. (Given reasonable assumptions about > background knowledge, we don't need the full legalese version.) > >>> F37 The browser MUST be able to send streams and >>> data to a peer in the presence of FWs that only >>> allows http(s) traffic. >>> >>> This is a more specific version of F19, for which my same comment >>> applies. I haven't seen any attempt to provide a solution. Can this >>> be removed? >> TURN/TLS will satisfy this requirement. > This is not always true :) What's the case when it isn't? > >>> F26 It MUST be possible to move from one network >>> interface to another one >>> >>> For whom must this be possible? Certainly, the browser is able to >>> make this choice, but the application has only limited ability to >>> control this in the current application. I can imagine perhaps >>> changing priority values on a=candidate lines based on some guessing >>> about what interfaces are what, but I have a strong expectation that >>> this would have zero effect in any ICE implementation. >> ICE restart satisfies this requirement for the "break before make" case. > I know that this happens *in some cases*, but I did not read "break > before make" anywhere. I happen to be using a device with multiple > interfaces that can operate both in tandem quite happily. For those, > it's possible to make before break. I don't read "make before break" either, but that's obviously preferable. Now that I dig further back into my memory, I think ICE restart is supposed to support make-before-break; you don't have to turn off the old path before the new has checked out usable. From harald@alvestrand.no Thu Jan 31 07:08:02 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A972121F8586 for ; Thu, 31 Jan 2013 07:08:02 -0800 (PST) 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.100, 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 TXWe1z7vBE6b for ; Thu, 31 Jan 2013 07:08:01 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 5F37921F857E for ; Thu, 31 Jan 2013 07:08:01 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6DF3B39E1BE for ; Thu, 31 Jan 2013 16:08:00 +0100 (CET) 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 pxwfngoOY+30 for ; Thu, 31 Jan 2013 16:07:58 +0100 (CET) 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 A252939E1B7 for ; Thu, 31 Jan 2013 16:07:58 +0100 (CET) Message-ID: <510A88CD.9090602@alvestrand.no> Date: Thu, 31 Jan 2013 16:07:57 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 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] Comments on draft-ietf-rtcweb-overview-05 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 31 Jan 2013 15:08:02 -0000 On 01/30/2013 01:23 PM, Bjoern Hoehrmann wrote: > Hi, > > http://tools.ietf.org/html/draft-ietf-rtcweb-overview-05 claims that > it is an "overview" in title and abstract, but it also references RFC > 2119 and uses RFC 2119 keywords and has normative references making the > role of the document unclear. Either the RFC 2119 reference and keywords > have to be removed, or Abstract and perhaps title have to be changed to > make it clear who or what would conform to this specification. The original intent was that an application that claims conformance to the RTCWEB specification could specify only that it conforms to this document, pulling the normative references in by reference. It is up to the chairs to determine if this purpose is a) desirable and b) achievable. > > I understand the Chairs are already aware some of the references need to > be updated. The `[getusermedia]` reference should point to some proper > publication of the W3C, under `http://www.w3.org/TR/` most likely. (speaking with W3C WG chair hat on) These documents are not finished. It is up to the IETF whether it wishes to refer to them as work-in-progress or hold publication until publications exist. > > There are various parts that have placeholder text, e.g. section 9 has > " only>" and '', and Appendix A > has 'The draft referred to as "transport and middle boxes" in Section 4 > has not been written yet.' That seems to indicate that the draft is not > ready for publication yet. Noted. These are important to get right. > > In section 12 is a typo "ad to" which should probably be "and to". > > Also in section 12, "The number of people who have taken part in the > discussions surrounding this draft are too numerous to list". Ordinarily > people would not be acknowledged simply for having taken part in some > discussion surrounding a document, and it's usually not true that there > have been "too many to list"; I think it would be better to remove the > quoted text. > > As noted in http://www.w3.org/2001/06/manual/#Translations the document > should not use "we" as that is hard to translate and usually it's not > very clear who the pronoun refers to (authors, editors, working group, > the IETF at large, or someone else). Seven occurences found, five of them in appendix A, which the text says should be moved to a different document, and one in the change log. > > There seem to be many phrases used in the document that are not very > suitable for a general audience, examples are "communications event", > "communications partnership", and "a strong changer of the marketplace > of deployment". (Two of the phrases there come from the last paragraph > in 2.3. which as a whole is not very comprehensible and probably needs > to be re-written). While the readers of this document are not a "general" audience, this paragraph was not easy to write, and does seem hard to read. Alternative suggestions are welcome. > > regards, From harald@alvestrand.no Thu Jan 31 07:17:58 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5AB121F8596 for ; Thu, 31 Jan 2013 07:17:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.513 X-Spam-Level: X-Spam-Status: No, score=-110.513 tagged_above=-999 required=5 tests=[AWL=0.086, 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 UmthbBiSDkPT for ; Thu, 31 Jan 2013 07:17:58 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 1F5C321F84F9 for ; Thu, 31 Jan 2013 07:17:58 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D744439E1BE; Thu, 31 Jan 2013 16:17:56 +0100 (CET) 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 EeA27QShGKjS; Thu, 31 Jan 2013 16:17:56 +0100 (CET) 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 055A939E1B7; Thu, 31 Jan 2013 16:17:55 +0100 (CET) Message-ID: <510A8B23.8060600@alvestrand.no> Date: Thu, 31 Jan 2013 16:17:55 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Bernard Aboba References: <50F97303.4070906@ericsson.com>, , , , , , , <5109265F.6040106@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "rtcweb@ietf.org" Subject: [rtcweb] Wiretapping (Re: Review of draft-ietf-rtcweb-use-cases-and-requirements-10 (Part II)) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 31 Jan 2013 15:17:58 -0000 On 01/30/2013 09:02 PM, Bernard Aboba wrote: > > > [BA] "Wiretapping" is too vague a phrase to be of much use. It > might make more sense to > > > talk about security services that should be provided (e.g. > confidentiality of media). > > > > This was discussed a bit, and someone (Harald?) pointed out that > > wiretapping is well defined and can be used. > > [BA] If we can refer to a definition this would be helpful in > clarifying the requirement. RFC 2804 section 3 spends quite a few words on defining the term. From eckelcu@cisco.com Thu Jan 31 11:41:35 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD53221F84D7 for ; Thu, 31 Jan 2013 11:41:35 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sPXAqMtddF8Z for ; Thu, 31 Jan 2013 11:41:34 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id B655F21F865B for ; Thu, 31 Jan 2013 11:41:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5080; q=dns/txt; s=iport; t=1359661295; x=1360870895; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=ZxJB4mBizOVigucpyeFE3T+4o2IU6KCkfYfKO7LtCY4=; b=MBjc0Dx/rTCOyqgoKHl1/fEG/wADddLouUdDap6GEPeovIsM1TILLQ2z h3NfxD3gLAueZX0ty8sUb8/UBJ80c94asYe13Sw8IiZ1RZcnW+3f5W3vv dQt+v/uKgViionFva/zuvsHgSVcTKqxU6wvnv5ZkcDix5u5DBNkmsrZzt c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAH/HClGtJXG+/2dsb2JhbAA7Cr8mFnOCHgEBAQMBOi4PBwcEAgEIEQQBAQsUCQcyFAgBCAIEARIIE4dwBQHCKY0XBIMQYQOmXoJ7gWY+ X-IronPort-AV: E=Sophos;i="4.84,579,1355097600"; d="scan'208";a="171330916" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-8.cisco.com with ESMTP; 31 Jan 2013 19:41:34 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r0VJfYKJ029813 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 31 Jan 2013 19:41:34 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.107]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.02.0318.004; Thu, 31 Jan 2013 13:41:34 -0600 From: "Charles Eckel (eckelcu)" To: "Ejzak, Richard P (Richard)" , "rtcweb@ietf.org" Thread-Topic: [rtcweb] FW: New Version Notification for draft-reddy-rtcweb-mobile-00.txt Thread-Index: AQHN+bwJqPh8ieT7eka/zkcS4JfAPZhiKGxggACa8ICAARt5AA== Date: Thu, 31 Jan 2013 19:41:33 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C0882804767088@xmb-aln-x08.cisco.com> References: <913383AAA69FF945B8F946018B75898A148E07CB@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A148E8567@xmb-rcd-x10.cisco.com> <03FBA798AC24E3498B74F47FD082A92F36EA12C6@US70UWXCHMBA04.zam.alcatel-lucent.com> <92B7E61ADAC1BB4F941F943788C088280476278A@xmb-aln-x08.cisco.com> <03FBA798AC24E3498B74F47FD082A92F36EA3916@US70UWXCHMBA04.zam.alcatel-lucent.com> In-Reply-To: <03FBA798AC24E3498B74F47FD082A92F36EA3916@US70UWXCHMBA04.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.68.16.69] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [rtcweb] FW: New Version Notification for draft-reddy-rtcweb-mobile-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: Thu, 31 Jan 2013 19:41:35 -0000 > -----Original Message----- > From: Ejzak, Richard P (Richard) [mailto:richard.ejzak@alcatel-lucent.com= ] > Sent: Wednesday, January 30, 2013 12:34 PM > To: Charles Eckel (eckelcu); rtcweb@ietf.org > Subject: RE: [rtcweb] FW: New Version Notification for draft-reddy-rtcweb= - > mobile-00.txt >=20 > > From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] >=20 > > > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > > > Behalf Of Ejzak, Richard P (Richard) > > > > > > Thus there are two workable solutions to providing QoS treatment to > > > multiplexed media flows, one available with existing specifications a= nd > > one > > > requiring some small 3GPP spec enhancements. The only requirement > > > relevant to rtcweb is that the SSRC values used for different media > > flows > > > must be explicitly signaled in SDP so that they are available to > > identify each > > > flow. > > > > I don't think this is a realistic requirement. It may be feasible in so= me > > cases, but it won't work well in others, such as large switched > > conferences. I recall this subject being discussed in previous meetings= . > > Fortunately I do not find such a requirement in the requirements draft. >=20 > Well, at least in rtcweb with the explicit signaling of each MSID this > requirement is satisfied. I have suggested a more general solution based= on > restricted SSRC assignment that I think could work quite well but this wa= s > not well received. >=20 > Do you have an alternative solution that does not require some means of > signaling how to identify each flow? And why is it not feasible to add t= he > option to explicitly signal such additional information with an extra > offer/answer exchange WHEN necessary to assure proper QoS in the > presence of media multiplexing? I think a level of abstraction is required. For example, if you have 3 vide= o streams, and you want to prioritize the first one over the second and thi= rd, the QoS provided could be independent of the SSRC the source of the str= eam happened to be using at that time. As the SSRC and/or source changes ov= er time (e.g. an active speaker switch or an SSRC collision), the QoS for t= he first stream remains constant. This seems desirable and does not require= explicit signaling of SSRCs.=20 If I have a conference with 1000 participants, I do not want to have an off= er/answer exchange between the conference server and each participant each = time a new participant joins, changes SSRC, or starts/ends being an active = speaker). Just imagine how many offer/answer exchanges that would be while = the conference was starting up and how large your SDP specifying all those = SSRCs would be. =20 > I doubt that it makes sense to use media multiplexing (bundle) for large > switched conferences anyway. If you need complete freedom to create > new streams at will then each (unbundled) media type should probably > have its own five-tuple and QoS treatment. This would not preclude the > multiplexing of multiple streams of the same media type within a five- > tuple, where you get most of the advantages of multiplexing in this case. > But in the vast majority of the cases, users will not have the need for t= his > and could benefit from the benefits of both media multiplexing and QoS. Agreed. Cheers, Charles > > Setting that aside, we have media types beyond audio and video for whic= h > > SSRC are not applicable. I suppose you could assume some default > treatment > > for such media types, but that is pretty limited. > > > > Cheers, > > Charles >=20 > With regard to other media types, only data channels are relevant in rtcw= eb. > I am not aware of a general solution to differentiating among data channe= ls > outside of the browser since all the SCTP frames are encrypted. The > browser will bear the brunt of the responsibility for differentiating amo= ng > the transmitted data channels within a five-tuple. For reasons already > discussed, DSCP is at best a partial solution (if even applicable to diff= erent > flows within an SCTP association, which I have not studied). As you say,= the > data channels will receive the same treatment in the network. And > "default" treatment for the data channels can be defined on a five-tuple > basis and is not necessarily just "best effort", so this is not as limite= d as it > might seem. >=20 > In the case of other media transport options, we could potentially define > yet other filters based on other protocol fields, but clearly that would = be > out of scope of rtcweb, and arguably much less important than audio and > video, particularly since media multiplexing can be disabled for these fl= ows > if necessary to request special QoS treatment. >=20 > I hope you are not suggesting that since there are difficulties in achiev= ing a > 100% general solution that attempts to solve the most important use cases > should be abandoned? >=20 > Thanks for your comments! > Richard From mandyam@quicinc.com Thu Jan 31 11:55:32 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2549221F8880 for ; Thu, 31 Jan 2013 11:55:32 -0800 (PST) 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 65IN86wa1wlW for ; Thu, 31 Jan 2013 11:55:31 -0800 (PST) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) by ietfa.amsl.com (Postfix) with ESMTP id 865BC21F886F for ; Thu, 31 Jan 2013 11:55:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=quicinc.com; i=@quicinc.com; q=dns/txt; s=qcdkim; t=1359660199; x=1391196199; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=zK2nGdmkRmPUJUuhOLOlZwiDzdn6KcK80yFpKPLu9O0=; b=FYnH3rfvJHINe2L6efDszpz/iGpvFTKnIJ8FSaQHp/LH3UZ21Uv1rDQi ffG05dYBePoAWVFu1YuxYSifirz1bWgwvZdj6w5MRNiUGJ9Xe/4mNIz7U dxbbAClBIFeKTerVBVCKSf8pbZz3dNaTyyfg/5LWTINE66Cb0XerDX2o7 M=; X-IronPort-AV: E=Sophos;i="4.84,579,1355126400"; d="scan'208";a="19623846" Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by sabertooth02.qualcomm.com with ESMTP; 31 Jan 2013 11:23:18 -0800 X-IronPort-AV: E=Sophos;i="4.84,578,1355126400"; d="scan'208";a="389092993" Received: from nasanexhc01.na.qualcomm.com ([172.30.48.25]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 31 Jan 2013 11:55:30 -0800 Received: from NASANEXD01H.na.qualcomm.com ([169.254.8.132]) by NASANEXHC01.na.qualcomm.com ([172.30.48.25]) with mapi id 14.02.0318.004; Thu, 31 Jan 2013 11:55:30 -0800 From: "Mandyam, Giridhar" To: "rtcweb@ietf.org" Thread-Topic: Draft on FEC FRAME for RTCWEB Thread-Index: Ac3/7MMVi+EVj0WeTAGyazptcqiOvg== Date: Thu, 31 Jan 2013 19:55:29 +0000 Message-ID: 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [rtcweb] Draft on FEC FRAME 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, 31 Jan 2013 19:55:32 -0000 Hello All, Please note the I.-D. which can be found at http://datatracker.ietf.org/doc= /draft-mandyam-rtcweb-fecframe/. We welcome any feedback/suggestions/corre= ctions. Thanks, -Giri Mandyam From matthew.kaufman@skype.net Thu Jan 31 13:26:38 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72F9B21F8840 for ; Thu, 31 Jan 2013 13:26:38 -0800 (PST) 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 o6dBO74VoFGV for ; Thu, 31 Jan 2013 13:26:38 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (na01-bl2-obe.ptr.protection.outlook.com [65.55.169.24]) by ietfa.amsl.com (Postfix) with ESMTP id ACE6D21F87D3 for ; Thu, 31 Jan 2013 13:26:37 -0800 (PST) Received: from BY2FFO11FD006.protection.gbl (10.1.15.200) by BY2FFO11HUB036.protection.gbl (10.1.14.179) with Microsoft SMTP Server (TLS) id 15.0.596.13; Thu, 31 Jan 2013 21:26:29 +0000 Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD006.mail.protection.outlook.com (10.1.14.127) with Microsoft SMTP Server (TLS) id 15.0.596.13 via Frontend Transport; Thu, 31 Jan 2013 21:26:28 +0000 Received: from TK5EX14MBXC272.redmond.corp.microsoft.com ([169.254.2.197]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.02.0318.003; Thu, 31 Jan 2013 21:25:57 +0000 From: "Matthew Kaufman (SKYPE)" To: "Charles Eckel (eckelcu)" , "Ejzak, Richard P (Richard)" , "rtcweb@ietf.org" Thread-Topic: [rtcweb] FW: New Version Notification for draft-reddy-rtcweb-mobile-00.txt Thread-Index: AQHN/w96Nb3NO2Z/iEyGsrRJidqYsJhiVB+AgAGDtICAABuBUA== Date: Thu, 31 Jan 2013 21:25:56 +0000 Message-ID: References: <913383AAA69FF945B8F946018B75898A148E07CB@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A148E8567@xmb-rcd-x10.cisco.com> <03FBA798AC24E3498B74F47FD082A92F36EA12C6@US70UWXCHMBA04.zam.alcatel-lucent.com> <92B7E61ADAC1BB4F941F943788C088280476278A@xmb-aln-x08.cisco.com> <03FBA798AC24E3498B74F47FD082A92F36EA3916@US70UWXCHMBA04.zam.alcatel-lucent.com> <92B7E61ADAC1BB4F941F943788C0882804767088@xmb-aln-x08.cisco.com> In-Reply-To: <92B7E61ADAC1BB4F941F943788C0882804767088@xmb-aln-x08.cisco.com> 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-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(189002)(377454001)(199002)(47736001)(49866001)(63696002)(56816002)(77982001)(54356001)(47976001)(16406001)(47776003)(74502001)(53806001)(5343655001)(55846006)(50986001)(46102001)(44976002)(4396001)(33656001)(20776003)(47446002)(76482001)(23726001)(74662001)(51856001)(59766001)(54316002)(79102001)(50466001)(56776001)(31966008)(46406002); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB036; H:TK5EX14HUBC107.redmond.corp.microsoft.com; RD:; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0743E8D0A6 Subject: Re: [rtcweb] FW: New Version Notification for draft-reddy-rtcweb-mobile-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: Thu, 31 Jan 2013 21:26:38 -0000 From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= Charles Eckel (eckelcu) Sent: Thursday, January 31, 2013 11:42 AM To: Ejzak, Richard P (Richard); rtcweb@ietf.org Subject: Re: [rtcweb] FW: New Version Notification for draft-reddy-rtcweb-m= obile-00.txt > If I have a conference with 1000 participants, I do not want to have an o= ffer/answer exchange between the conference server > and each participant each time a new participant joins, changes SSRC, or = starts/ends being an active speaker).=20 > Just imagine how many offer/answer exchanges that would be while the conf= erence was starting up and how large your=20 > SDP specifying all those SSRCs would be. =20 If only there were a way to create an API that didn't require SDP exchanges= in order to tell a browser what media to send and with what parameters... Matthew Kaufman From btdingle@gmail.com Thu Jan 31 14:24:03 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 102E921F8446 for ; Thu, 31 Jan 2013 14:23:58 -0800 (PST) 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, HTML_MESSAGE=0.001, NO_RELAYS=-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 oOUqjveBW2Mc for ; Thu, 31 Jan 2013 14:23:57 -0800 (PST) Received: from mail-we0-x22e.google.com (we-in-x022e.1e100.net [IPv6:2a00:1450:400c:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id AA59921F842C for ; Thu, 31 Jan 2013 14:23:55 -0800 (PST) Received: by mail-we0-f174.google.com with SMTP id r6so2505430wey.5 for ; Thu, 31 Jan 2013 14:23:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=B/BbLa76YNu8fS5dAOg5pwAtvXCz/96VXyt9ts4kJPA=; b=oWCEtdLQvyd2Bk2wWwmy60uQRvigUTKz6Z6v7Bi6CsKz2p3656n+kgselJWzEz0QTS DbfKdXucNuZh+NkztQIdcL0Z5rpEvxrlGROo1ScfuCyiMFfkemVay4g6FOJpH6sz5+Ma xHdpr0pZgbxB9rrjUUstE5id4R8Q29fqXrKkqH3W9h4l2brhZ/XJ0aph0Hq3lqU/1d3R 4eEME29dPPGCV8zXnLUB7f/1A4H4wGvtjH/bagb3A28B++waDvW/Rw1g7nCwXHS+M56z wFtlYKwLJksMP4wbL/aoCCAxIgtO2v9/d/e3SdvXNpWX7EujdE3WrnrL6qySZpR2qZdJ sjug== X-Received: by 10.180.102.7 with SMTP id fk7mr11003990wib.27.1359671034656; Thu, 31 Jan 2013 14:23:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.82.133 with HTTP; Thu, 31 Jan 2013 14:23:34 -0800 (PST) In-Reply-To: <51098D5A.4040009@omnitor.se> References: <50F97303.4070906@ericsson.com> <5102FE7E.5000109@omnitor.se> <51039976.1000600@alvestrand.no> <51098D5A.4040009@omnitor.se> From: Barry Dingle Date: Fri, 1 Feb 2013 09:23:34 +1100 Message-ID: To: Gunnar Hellstrom Content-Type: multipart/alternative; boundary=f46d0444e7d70838d204d49d15a1 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] WG Last Call: draft-ietf-rtcweb-use-cases-and-requirements-10 - real-time text X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 31 Jan 2013 22:24:04 -0000 --f46d0444e7d70838d204d49d15a1 Content-Type: text/plain; charset=UTF-8 The email discussion regarding Real-time Text (RTT) in December last year showed a real interest in the need to support it in WebRTC/rtcweb. In addition, there are draft regulations in the USA and in Europe REQUIRING RTT be supported wherever there is voice communication. We need to find a way to include RTT in the Use cases and Gunnar's proposal is a very good start. It does not change any of the existing Use cases as it is an Additional feature. I strongly support the inclusion of RTT in the Use cases and Requirements. Cheers, /Barry Dingle On Thu, Jan 31, 2013 at 8:15 AM, Gunnar Hellstrom < gunnar.hellstrom@omnitor.se> wrote: > On 2013-01-26 09:53, Harald Alvestrand wrote: > > On 01/25/2013 10:51 PM, Gunnar Hellstrom wrote: > > On 2013-01-18 17:06, Magnus Westerlund wrote: > > WG, > > I would here by like to announce a two week WG last call that ends on > the 1st of February. > > Document is available here: > > > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-use-cases-and-requirements/ > > > We had a good discussion in December on inclusion of the real-time text > medium. > > It was decided to document three alternative implementations with pros and > cons and after that decide which one to standardize together with the two > already mentioned media in rtcweb. > > The three alternatives were: > 1.) An RTP medium similar to audio and video, using RFC 4103 transport. > > 2.) A semi-reliable data channel with a standardized label. > > 3.) A web service based protocol, such as BOSH and XEP-0301 for real-time > text in XMPP with a well specified integration with rtcweb in a common > application. > > For all three cases, there is a need to have a specification for how calls > with audio, video and real-time text are exchanged with SIP based > environments, e.g. for interaction with RFC 6443 based emergency services. > > Text is a natural part of today's video and audio applications, so all use > cases look quite meager without it. > > I suggest that we make a rapid mini-investigation on the real-time text > alternatives and decide which variant to include in a use case. > > > I disagree with this summary on two points: > > - I think it's broken to choose between implementation strategies in an > use case. The use case needs to specify the function that we want to > achieve. > > Yes, I totally agree, I did not mean to have the discussion on solution in > the use case document. > > > > - I don't recall a declaration by the chairs that text would be included > in the use cases for RTCWEB. > > I repeat my proposal to do so. This time with a shortened, generally > expressed use case that is intended to allows any one of the three > implementation alternatives to be selected. > > > > My memory is flaky, so if you can find the declaration by the chairs, I'm > happy to let the last point pass. > > Yes, I am on my way to do the last point as well. But timing requires the > addition to the use cases to be handled now. > > > Thus: Proposal for adding real-time text to the use cases, adjusted to be > general and minimal: > > --------------------------Add real-time text in a general way in use case > draft------------------------------------------- > > 4.2.15. Simple Total Conversation service**** > > 4.2.15.1. Description**** > > ** ** > > This use-case has the audio and video communication of the Simple**** > > Video Communication Service use-case (Section 4.2.1 ).**** > > ** ** > > In addition to this, the users can send and receive real-time text > in the same call.**** While one user types in the real-time text area, it**** > > is nearly immediately presented to the other user. > > By providing these three media together, the Total Conversation > service is provided. > > Interworking with SIP calls with the same media set, and with SIP > based emergency services is also in scope of this use case. **** > > ** ** > > 4.2.15.2 <#13c8d510f5a08297_section-4.3.1.2>. Derived Requirements**** > > ** ** > > F1, F2, F3, F4, F5, F6, F8, F9, F10, F20, F21,**** > > ** ** > > F39,F40, F41**** > > ** ** > > A1, A2, A3, A4, A7, A8, A9, A10, A11, A12, A27**** > > ** ** > > .............. > > F39 The browser MUST be able to handle text entry**** > > via applications to generate real-time text streams to be included in Total Conversation > calls. Real-time text and Total Conversation > Services are defined in ITU-T F.700 and F.703. **** > > ----------------------------------------------------------------**** > > F40 The browser MUST be able to send real-time text **** > > streams to a peer.**** > > ** ** > > ----------------------------------------------------------------**** > > F41 The browser MUST be able to receive, process and**** > > convey real-time text streams from peers to > applications.**** > > ----------------------------------------------------------------**** > > **** > > ** > > ..... > ** A27 The Web API MUST provide a mechanisms for **** > handling real-time text among the streams.**** > ----------------------------------------------------------------**** > > > > /Gunnar > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --f46d0444e7d70838d204d49d15a1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The email discussion regarding Real-time Text (RTT) in December last year s= howed a real interest in the need to support it in WebRTC/rtcweb.

In= addition, there are draft regulations in the USA and in Europe REQUIRING R= TT be supported wherever there is voice communication.=C2=A0

We need to find a way to include RTT in the Use cases and Gunnar's = proposal is a very good start. It does not change any of the existing Use c= ases as it is an Additional feature.

I strongly support the inclusi= on of RTT in the Use cases and Requirements.

Cheers,
/Barry Dingle




On Thu, Jan 31, 2013 at 8:15 AM, Gunnar = Hellstrom <gunnar.hellstrom@omnitor.se> wrote:
=
=20 =20 =20
On 2013-01-26 09:53, Harald Alvestrand wrote:
On 01/25/2013 10:51 PM, Gunnar Hellstrom wrote:
On 2013-01-18 17:06, Magnus Westerlund wrote:
WG,

I would here by like to announce a two week WG last call that ends on
the 1st of February.

Document is available here:

https://datatracker.ietf.org/do= c/draft-ietf-rtcweb-use-cases-and-requirements/


We had a good discussion in December on inclusion of the real-time text medium.

It was decided to document three alternative implementations with pros and cons and after that decide which one to standardize together with the two already mentioned media in rtcweb.

The three alternatives were:
1.) An RTP medium similar to audio and video, using RFC 4103 transport.

2.) A semi-reliable data channel with a standardized label.

3.) A web service based protocol, such as BOSH and XEP-0301 for real-time text in XMPP with a well specified integration with rtcweb in a common application.

For all three cases, there is a need to have a specification for how calls with audio, video and real-time text are exchanged with SIP based environments, e.g. for interaction with RFC 6443 based emergency services.

Text is a natural part of today's video and audio applications, so all use cases look quite meager without it.

=C2=A0I suggest that we make a rapid mini-investigation on the real-time text alternatives and decide which variant to include in a use case.

I disagree with this summary on two points:

- I think it's broken to choose between implementation strategies in an use case. The use case needs to specify the function that we want to achieve.
Yes, I totally agree, I did not mean to have the discussion on solution in the use case document.



- I don't recall a declaration by the chairs that text would be included in the use cases for RTCWEB.
I repeat my proposal to do so. This time with a shortened, generally expressed use case that is intended to allows any one of the three implementation alternatives to be selected.


My memory is flaky, so if you can find the declaration by the chairs, I'm happy to let the last point pass.

Yes, I am on my way to do the last point as well. But timing requires the addition to the use cases to be handled now.


Thus: Proposal for adding real-time text to the use cases, adjusted to be general and minimal:

--------------------------Add real-time text in a general way in use case draft-------------------------------------------
=20
4.2.15.=C2=A0 Simple Total Conversation service

4.2.15.1.=C2=A0 Description 
=C2=A0
=C2=A0=C2=A0 This use-case has the audio and video co=
mmunication of the Simple
=C2=A0=C2=A0 Video Communication Service use-case (Section 4.2.1).
=C2=A0
=C2=A0=C2=A0 In addition to this, the users can send =
and receive real-time text
   in the same call. While one user types in the=
 real-time text area, it
=C2=A0 =C2=A0is nearly immediately presented to the other u=
ser.

   By providing these three media together, the Total Conversation
  =C2=A0service is provided.

   Interworking with SIP calls with the same media set, and with SIP
  =C2=A0based emergency services is also in scope of this use case. =

=C2=A0<=
/span>
4.2.15.2.=C2=A0 Derived Requirements
=C2=A0
=C2=A0=C2=A0 F1, F2, F3, F4, F5, F6=
, F8, F9, F10, F20, F21,
=C2=A0
=C2=A0=C2=A0 F39,F40, F41=

=C2=A0
=C2=A0=C2=A0 A1, A2, A3, A4, A7, A8=
, A9, A10, A11, A12, A27
=C2=A0
..............

=20 
=C2=A0=C2=A0 F39=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The bro=
wser MUST be able to handle text entry
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 v=
ia applications to generate real-time=20
                   text streams to be included in=
 Total Conversation
                   calls. Real-time text and Total Conversation
                   Services are defined in ITU-T F.700 and F.703. 
=C2=A0=C2=A0 ----------------------=
------------------------------------------
=C2=A0=C2=A0 F40=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 T=
he browser MUST be able to send real-time text 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0streams to a peer.
=C2=A0
=C2=A0=C2=A0 ----------------------=
------------------------------------------
=C2=A0=C2=A0 F41=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 T=
he browser MUST be able to receive, process and
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <=
span>=C2=A0convey real-time text streams from peers to=20
                    applications.
=C2=A0=C2=A0 ----------------------=
------------------------------------------
=C2=A0=C2=A0 <=
/pre>
    
=C2=A0

.....

=C2=A0=C2=A0 A27=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 T=
he Web API MUST provide a mechanisms for =20
 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 handling real-time text among the str=
eams.=20
=C2=A0--------------------------------------------------------------=
--


   =20
   =20
   =20
   =20
   =20
   =20
   =20
   =20
    

    

    /Gunnar

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


--f46d0444e7d70838d204d49d15a1-- From harald@alvestrand.no Thu Jan 31 15:07:39 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4683D21F8888 for ; Thu, 31 Jan 2013 15:07:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.373 X-Spam-Level: X-Spam-Status: No, score=-109.373 tagged_above=-999 required=5 tests=[AWL=-1.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_OFF=2.3, 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 sgAYuL+LHUH9 for ; Thu, 31 Jan 2013 15:07:38 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 73B1D21F8887 for ; Thu, 31 Jan 2013 15:07:37 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3660239E1C4 for ; Fri, 1 Feb 2013 00:07:35 +0100 (CET) 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 xLz4lqHWNIgs for ; Fri, 1 Feb 2013 00:07:33 +0100 (CET) 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 6A8A939E1B7 for ; Fri, 1 Feb 2013 00:07:33 +0100 (CET) Message-ID: <510AF934.2030800@alvestrand.no> Date: Fri, 01 Feb 2013 00:07:32 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: rtcweb@ietf.org References: <50F97303.4070906@ericsson.com> <5102FE7E.5000109@omnitor.se> <51039976.1000600@alvestrand.no> <51098D5A.4040009@omnitor.se> In-Reply-To: <51098D5A.4040009@omnitor.se> Content-Type: multipart/alternative; boundary="------------080809080004090005050306" Subject: Re: [rtcweb] WG Last Call: draft-ietf-rtcweb-use-cases-and-requirements-10 - real-time text X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 31 Jan 2013 23:07:39 -0000 This is a multi-part message in MIME format. --------------080809080004090005050306 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit FWIW, I strongly object to a couple of formalities here: - I object to making normative reference to F.700 and F.703. - I object to requiring interworking with emergency services. If there's strong support in the WG for including the use case, I'm willing to go along with that. (The reason for not wanting to normatively reference F.700 and F.703 is that they're very large balls of string, and I have no idea where the string may lead; for instance, the definition of "Total Conversation" in section A.3.2.3 of F.700 requires font support for all characters in ISO-10646-1; I doubt somewhat that the person who wrote that paragraph has studied the task of providing such font support - I found that particular linkage in a few minutes of scanning the docs.) On 01/30/2013 10:15 PM, Gunnar Hellstrom wrote: > 4.2.15.Simple Total Conversation service > > 4.2.15.1.Description > > This use-case has the audio and video communication of the Simple > Video Communication Service use-case (Section 4.2.1 ). > > In addition to this, the users can send and receive real-time text > in the same call. While one user types in the real-time text area, it > is nearly immediately presented to the other user. > > By providing these three media together, the Total Conversation > service is provided. > > Interworking with SIP calls with the same media set, and with SIP > based emergency services is also in scope of this use case. > > 4.2.15.2 . Derived Requirements > > F1, F2, F3, F4, F5, F6, F8, F9, F10, F20, F21, > > F39,F40, F41 > > A1, A2, A3, A4, A7, A8, A9, A10, A11, A12, A27 > > .............. > > F39 The browser MUST be able to handle text entry > via applications to generate real-time > text streams to be included in Total Conversation > calls. Real-time text and Total Conversation > Services are defined in ITU-T F.700 and F.703. > ---------------------------------------------------------------- > F40 The browser MUST be able to send real-time text > streams to a peer. > > ---------------------------------------------------------------- > F41 The browser MUST be able to receive, process and > convey real-time text streams from peers to > applications. > ---------------------------------------------------------------- > > > > ..... > > A27 The Web API MUST provide a mechanisms for > handling real-time text among the streams. > ---------------------------------------------------------------- --------------080809080004090005050306 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
FWIW, I strongly object to a couple of formalities here:

- I object to making normative reference to F.700 and F.703.
- I object to requiring interworking with emergency services.

If there's strong support in the WG for including the use case, I'm willing to go along with that.

(The reason for not wanting to normatively reference F.700 and F.703 is that they're very large balls of string, and I have no idea where the string may lead; for instance, the definition of "Total Conversation" in section A.3.2.3 of F.700 requires font support for all characters in ISO-10646-1; I doubt somewhat that the person who wrote that paragraph has studied the task of providing such font support - I found that particular linkage in a few minutes of scanning the docs.)

On 01/30/2013 10:15 PM, Gunnar Hellstrom wrote:
4.2.15.  Simple Total Conversation service

4.2.15.1.  Description
 
 
   This use-case has the audio and video communication of the Simple
   Video Communication Service use-case (Section 4.2.1).
 
   In addition to this, the users can send and receive real-time text
   in the same call. While one user types in the real-time text area, it
   is nearly immediately presented to the other user.

   By providing these three media together, the Total Conversation
   service is provided.

   Interworking with SIP calls with the same media set, and with SIP
   based emergency services is also in scope of this use case. 
 
4.2.15.2.  Derived Requirements
 
   F1, F2, F3, F4, F5, F6, F8, F9, F10, F20, F21,
 
   F39,F40, F41
 
   A1, A2, A3, A4, A7, A8, A9, A10, A11, A12, A27
 
..............

   F39             The browser MUST be able to handle text entry
                   via applications to generate real-time 
                   text streams to be included in Total Conversation
                   calls. Real-time text and Total Conversation
                   Services are defined in ITU-T F.700 and F.703. 
   ----------------------------------------------------------------
   F40              The browser MUST be able to send real-time text 
                   streams to a peer.
 
   ----------------------------------------------------------------
   F41              The browser MUST be able to receive, process and
                    convey real-time text streams from peers to 
                    applications.
   ----------------------------------------------------------------
   
 

.....

   A27             The Web API MUST provide a mechanisms for  
                   handling real-time text among the streams. 
 ----------------------------------------------------------------

--------------080809080004090005050306-- From csp@csperkins.org Thu Jan 31 15:19:31 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F32521F886D for ; Thu, 31 Jan 2013 15:19:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[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 ogl47Ngq4grH for ; Thu, 31 Jan 2013 15:19:30 -0800 (PST) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [93.93.130.6]) by ietfa.amsl.com (Postfix) with ESMTP id 2F30B21F87DF for ; Thu, 31 Jan 2013 15:19:30 -0800 (PST) Received: from [80.176.158.71] (helo=[192.168.0.11]) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1U13Pk-0006Qy-Ih; Thu, 31 Jan 2013 23:19:28 +0000 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Colin Perkins In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF013C85C2@MCHP04MSX.global-ad.net> Date: Thu, 31 Jan 2013 23:19:25 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <50F9728E.6000206@ericsson.com> <9F33F40F6F2CD847824537F3C4E37DDF013C85C2@MCHP04MSX.global-ad.net> To: "Hutton, Andrew" X-Mailer: Apple Mail (2.1283) X-BlackCat-Spam-Score: -13 X-Mythic-Debug: Threshold = On = Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] WG Last Call: draft-ietf-rtcweb-overview-05 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 31 Jan 2013 23:19:31 -0000 =46rom a relatively quick re-read of this draft, I tend to agree that it = seems premature to last call it now. While the work seems to be along = the right lines, there's little benefit in having this draft published = before the referenced protocol drafts, and publishing it earlier than = those runs that risk that it's obsoleted by later working group = decisions. I'd think it better to delay this last call until the group = is ready to send this, the use cases and requirements, and the core = protocol drafts to the IESG together, as one consistent set of = documents. Also, the statement that the chairs "do acknowledge that some references = will be required to be updated before submitting for publication" seems = a concern, given that a major point of this draft is to provide a = roadmap to other RTCWeb specification documents. It would seem important = for this draft to include an up-to-date list of references for the = working group to check, to ensure the roadmap is correct, before issuing = a last call for review.=20 Colin On 30 Jan 2013, at 09:58, Hutton, Andrew wrote: > I am wondering whether this is really the right time to be calling = last call on this document and don't see the harm in leaving this in = draft status until we have made some progress on more important issues = and in the mean time this document may need updating to keep up to date = with decisions made regarding SDP issues etc. >=20 > I also have reviewing this draft on my list of things to do but = probably preparing for the interim is more important. >=20 > Regards > Andy >=20 >=20 >=20 >=20 >=20 >> -----Original Message----- >> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On >> Behalf Of Cullen Jennings (fluffy) >> Sent: 29 January 2013 18:51 >> To: rtcweb@ietf.org >> Subject: Re: [rtcweb] WG Last Call: draft-ietf-rtcweb-overview-05 >>=20 >>=20 >> The combination of getting ready for the interim meeting and being >> sick, I am sorry but won't be able to get this done by deadline but I >> will still get a review done at later. >>=20 >> Sorry, Cullen >>=20 >> On Jan 18, 2013, at 9:04 AM, Magnus Westerlund >> wrote: >>=20 >>> WG, >>>=20 >>> I would here by like to announce a two week WG last call that ends = on >>> the 1st of February. Please review this, we chairs do acknowledge >> that >>> some references will be required to be updated before submitting for >>> publication, but we do need determine if this is ready for >> publication >>> and can consider it done. >>>=20 >>> Document is available here: >>> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-overview/ >>>=20 >>> Cheers >>>=20 >>> Magnus Westerlund >>>=20 >>> = --------------------------------------------------------------------- >> - >>> Multimedia Technologies, Ericsson Research EAB/TVM >>> = --------------------------------------------------------------------- >> - >>> Ericsson AB | Phone +46 10 7148287 >>> F=E4r=F6gatan 6 | Mobile +46 73 0949079 >>> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com >>> = --------------------------------------------------------------------- >> - >>>=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 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --=20 Colin Perkins http://csperkins.org/ From martin.thomson@gmail.com Thu Jan 31 16:16:49 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AD6321F89B2 for ; Thu, 31 Jan 2013 16:16:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-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 QU-wnLxhYyrs for ; Thu, 31 Jan 2013 16:16:49 -0800 (PST) Received: from mail-we0-x22c.google.com (we-in-x022c.1e100.net [IPv6:2a00:1450:400c:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 9BBFD21F89A4 for ; Thu, 31 Jan 2013 16:16:48 -0800 (PST) Received: by mail-we0-f172.google.com with SMTP id x10so2522313wey.31 for ; Thu, 31 Jan 2013 16:16:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=5ZK9BYPpnLDTwT0evjagJ3czlZvQocuU2ExpuaIWYiQ=; b=gojRP5x3reqIKyrl2IskSObNGIflrlWoKjqKHaJoy9X3xmIiqKPX+C/4z7iTGDaEq3 yJF8V60pMnF+tFWZtzDAB9Th/f+Ou58QryEsifTRlb4BjwsTj8XnX2RTPGoj0BPwvXj4 aPdUDdg1xI2hy5JXIx1Q5RPyfzAiTFJAAkgXkpQm2G35ZbfjUFoJcvOFf272nf6jUxUq 8wX/iw1sFCiVgdSLsLTTHlL5GkNGGk8ol9EGjL80M4qOW7x2SR9wLZyJszDrANU3Fb+o cMHDV14RiSkUyNXYRgwulRb3hahUZKULnXaw+gyRlSPUlvD8LPRffolZN9l04V0zxwnT F85g== MIME-Version: 1.0 X-Received: by 10.180.90.147 with SMTP id bw19mr18249142wib.28.1359677807702; Thu, 31 Jan 2013 16:16:47 -0800 (PST) Received: by 10.194.161.234 with HTTP; Thu, 31 Jan 2013 16:16:47 -0800 (PST) In-Reply-To: <510A63DA.3080301@alvestrand.no> References: <50F97303.4070906@ericsson.com> <5108F1B9.9020709@alvestrand.no> <510A63DA.3080301@alvestrand.no> Date: Fri, 1 Feb 2013 09:16:47 +0900 Message-ID: From: Martin Thomson To: Harald Alvestrand Content-Type: text/plain; charset=UTF-8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] WG Last Call: draft-ietf-rtcweb-use-cases-and-requirements-10 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 01 Feb 2013 00:16:49 -0000 On 31 January 2013 21:30, Harald Alvestrand wrote: > I can think of a reasonably easy test that generates the signal (read a mono > sound from a file to a mediastream using the MediaSource interface, feed it > to the WebAudio API, apply spatialization effects using the WebAudio API), > but I'm not sure how you test whether spatialization is actually performed > correctly. But writing that test should be a W3C matter. Maybe I'm reading too much into this, but spatialization effects are used for several reasons: for arrangements of multiple microphones in the same room, they can be necessary to get proper stereo audio. In order to do this based on microphone configuration, you need signaling. If all you are looking for is the ability to spatially separate different speakers, that clarification might help. >>>> F7 The browser MUST support fast stream switches. ... > Specified further (yes) or removed (yes)? Yes. As in pick one and I care little which that is. >>> TURN/TLS will satisfy this requirement. >> This is not always true :) > What's the case when it isn't? Some firewalls use traffic analysis to identify real-time data that has been tunneled over HTTP CONNECT. > I don't read "make before break" either, but that's obviously preferable. > Now that I dig further back into my memory, I think ICE restart is supposed > to support make-before-break; you don't have to turn off the old path before > the new has checked out usable. ICE restart can do that, but there is no guarantee that triggering a restart will result in a change of network interface. Further clarity on the requirement may be necessary to say that it be *possible* to do this.